mergeroads branch

classic Classic list List threaded Threaded
45 messages Options
123
Reply | Threaded
Open this post in threaded view
|

mergeroads branch

WanMil
Hi,

the mergeroads branch should be stable now so I invite all to test it.

Here are the changes compared to trunk:

* Roads now become merged before the routing network is created. This
might improve routing on long distances (I have seen some). The number
of roads in the routing network is reduced by 10-20% (in germany).

* refs are now composed in the style sheet and not in java code. The new
tag mkgmap:ref is used for that (see inc/refs in default style).

* access restrictions are now also handled in the style sheet and not in
java code. There are some new tags for that:
mkgmap:access:emergency
mkgmap:access:delivery
mkgmap:access:car
mkgmap:access:bus
mkgmap:access:taxi
mkgmap:access:foot
mkgmap:access:bike
mkgmap:access:truck
mkgmap:access:carpool
If a tag is set to 'no' the given access type is restricted in the map.
All other values are mapped to 'yes'.
I have tried to convert the java code to the style sheet. This was quite
complicated but I hope it's rather correct. See new include file inc/access.

* Instead of using hardcoded rules for maxspeed it is now possible to
control that via style file. Set the mkgmap:road-speed-class tag to the
desired class value (0 to 7) and use the new functions maxspeedkmh() and
maxspeedmph() to parse the maxspeed tag.

* Two new actions that seems useful to me:
echotags 'Hello'
prints out the OSM element id plus all tags of the element plus the
text. This seems to be useful for style debugging.

deletealltags
removes all tags from an element and therefore stops its processing.


I would be happy to get a lot of feedback!

Have fun!
WanMil
_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: mergeroads branch

WanMil
> Hi,
>
> the mergeroads branch should be stable now so I invite all to test it.
>
> Here are the changes compared to trunk:
>
> * Roads now become merged before the routing network is created. This
> might improve routing on long distances (I have seen some). The number
> of roads in the routing network is reduced by 10-20% (in germany).
>
> * refs are now composed in the style sheet and not in java code. The new
> tag mkgmap:ref is used for that (see inc/refs in default style).
>
> * access restrictions are now also handled in the style sheet and not in
> java code. There are some new tags for that:
> mkgmap:access:emergency
> mkgmap:access:delivery
> mkgmap:access:car
> mkgmap:access:bus
> mkgmap:access:taxi
> mkgmap:access:foot
> mkgmap:access:bike
> mkgmap:access:truck
> mkgmap:access:carpool

I have forgotten one:
mkgmap:access:throughroute

> If a tag is set to 'no' the given access type is restricted in the map.
> All other values are mapped to 'yes'.
> I have tried to convert the java code to the style sheet. This was quite
> complicated but I hope it's rather correct. See new include file inc/access.
>
> * Instead of using hardcoded rules for maxspeed it is now possible to
> control that via style file. Set the mkgmap:road-speed-class tag to the
> desired class value (0 to 7) and use the new functions maxspeedkmh() and
> maxspeedmph() to parse the maxspeed tag.
>
> * Two new actions that seems useful to me:
> echotags 'Hello'
> prints out the OSM element id plus all tags of the element plus the
> text. This seems to be useful for style debugging.
>
> deletealltags
> removes all tags from an element and therefore stops its processing.
>
>
> I would be happy to get a lot of feedback!
>
> Have fun!
> WanMil
> _______________________________________________
> mkgmap-dev mailing list
> [hidden email]
> http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>

_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: mergeroads branch

Felix Hartmann-2
I didn't use it yet - need to find enough time to adapt my style - but I
find the access handling a bit clumsy on the last step:

bicycle=*    { set mkgmap:access:bike='${bicycle}' }
carpool=*    { set mkgmap:access:carpool='${carpool}' }
foot=*       { set mkgmap:access:foot='${foot}' }
hgv=*        { set mkgmap:access:truck='${hgv}' }
motorcar=*   { set mkgmap:access:car='${motorcar}' }
motorcycle=* { set mkgmap:access:car='${motorcycle}'s }
psv=*        { set mkgmap:access:bus='${psv}' }
taxi=*       { set mkgmap:access:taxi='${taxi}' }
emergency=*  { set mkgmap:access:emergency='${emergency}' }
delivery=*   { set mkgmap:access:delivery='${delivery}' }
goods=*      { set mkgmap:access:delivery='${goods}' }


Is this really needed or could we skip that step in the style files? I
use set access=.... very often, so it would make the style-file a bit
more difficult to read by instead always using set mkgmap:access:.....=....

I'm fine with this however too, just find it a bit clumsy why this
additional step is really needed. Is it to keep the handling of special
actions with the same syntax everywhere?
If so good.


Besides everything looks fine to me.
_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: mergeroads branch

WanMil
> I didn't use it yet - need to find enough time to adapt my style - but I
> find the access handling a bit clumsy on the last step:
>
> bicycle=*    { set mkgmap:access:bike='${bicycle}' }
> carpool=*    { set mkgmap:access:carpool='${carpool}' }
> foot=*       { set mkgmap:access:foot='${foot}' }
> hgv=*        { set mkgmap:access:truck='${hgv}' }
> motorcar=*   { set mkgmap:access:car='${motorcar}' }
> motorcycle=* { set mkgmap:access:car='${motorcycle}'s }
> psv=*        { set mkgmap:access:bus='${psv}' }
> taxi=*       { set mkgmap:access:taxi='${taxi}' }
> emergency=*  { set mkgmap:access:emergency='${emergency}' }
> delivery=*   { set mkgmap:access:delivery='${delivery}' }
> goods=*      { set mkgmap:access:delivery='${goods}' }
>
>
> Is this really needed or could we skip that step in the style files? I
> use set access=.... very often, so it would make the style-file a bit
> more difficult to read by instead always using set mkgmap:access:.....=....
>
> I'm fine with this however too, just find it a bit clumsy why this
> additional step is really needed. Is it to keep the handling of special
> actions with the same syntax everywhere?
> If so good.
>

The goal of the branch is to give complete control to the style
implementor. So we need the new tags mkgmap:access:bike,
mkgmap:access:foot etc.

As a style developer you can decide to use the new tags directly or you
can still use the OSM access tags and include the access handling at a
later point in your style.
Maybe it's easier for you if you know that only the value no is
evaluated for the mkgmap:access:* tags. So setting them to yes or
designated or whatever is the same like not setting the tag.

I am happy if you have any good ideas to make it simpler.

>
> Besides everything looks fine to me.

_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: mergeroads branch

Manfred Brenneisen-2
 
Maybe it's easier for you if you know that only the value no is
evaluated for the mkgmap:access:* tags. So setting them to yes or
designated or whatever is the same like not setting the tag.
 
 
 
Good hint.
Shall I put this into the wiki?
http://wiki.openstreetmap.org/wiki/Mkgmap/help/Tags
 
Or is it too early?

_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: mergeroads branch

WanMil
> Maybe it's easier for you if you know that only the value no is
> evaluated for the mkgmap:access:* tags. So setting them to yes or
> designated or whatever is the same like not setting the tag.
> Good hint.
> Shall I put this into the wiki?
> http://wiki.openstreetmap.org/wiki/Mkgmap/help/Tags
> Or is it too early?
>

It makes no sense to document it before merging the branch to trunk.
I will add some documentation to the mkgmap internal documentation
(http://www.mkgmap.org.uk/doc/index.html) when merging to trunk. I think
the wiki is mostely unmaintained and all useful information should be
transferred to the mkgmap internal documentation.

WanMil

_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: mergeroads branch

Felix Hartmann-2
In reply to this post by WanMil

On 09.09.2013 20:47, WanMil wrote:

>>
>>
>
> The goal of the branch is to give complete control to the style
> implementor. So we need the new tags mkgmap:access:bike,
> mkgmap:access:foot etc.
>
> As a style developer you can decide to use the new tags directly or
> you can still use the OSM access tags and include the access handling
> at a later point in your style.
> Maybe it's easier for you if you know that only the value no is
> evaluated for the mkgmap:access:* tags. So setting them to yes or
> designated or whatever is the same like not setting the tag.
>
> I am happy if you have any good ideas to make it simpler.
>
>>
>>
that only no matters I know of course. I didn't know however that the
text block can also be added at the very end of the lines file (I
assumed it needs to be set before an 0x?? routable line is handled in
the style). That's perfect - in that case my style-file will stay easier
to read and I'll just add the block as last line in my lines/point files.

_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: mergeroads branch

Felix Hartmann-2
In reply to this post by Manfred Brenneisen-2
setting it to something however means it is set.

So the result of
& access!=*
will of course return a different result compared to the tag not existing. Quite often in styles the nonexistance of access tags, or the existence of "yes" is needed to be checked.
E.g.

highway=footway & bicycle=yes
if bicycle=yes - usually you treat it like highway=path, if not then it's a real footway. Hence watch out implications further down your style if you set yes/no.

As for the final treatment only no matters - that's more or less already the case (currently there is a treatment which decides which becomes no, which becomes yes).
On 09.09.2013 20:58, Manfred Brenneisen wrote:
 
Maybe it's easier for you if you know that only the value no is
evaluated for the mkgmap:access:* tags. So setting them to yes or
designated or whatever is the same like not setting the tag.
 
 
 
Good hint.
Shall I put this into the wiki?
 
Or is it too early?


_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev


_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: mergeroads branch

WanMil
In reply to this post by Felix Hartmann-2
>>>
>>>
>>
>> The goal of the branch is to give complete control to the style
>> implementor. So we need the new tags mkgmap:access:bike,
>> mkgmap:access:foot etc.
>>
>> As a style developer you can decide to use the new tags directly or
>> you can still use the OSM access tags and include the access handling
>> at a later point in your style.
>> Maybe it's easier for you if you know that only the value no is
>> evaluated for the mkgmap:access:* tags. So setting them to yes or
>> designated or whatever is the same like not setting the tag.
>>
>> I am happy if you have any good ideas to make it simpler.
>>
>>>
>>>
> that only no matters I know of course. I didn't know however that the
> text block can also be added at the very end of the lines file (I
> assumed it needs to be set before an 0x?? routable line is handled in
> the style). That's perfect - in that case my style-file will stay easier
> to read and I'll just add the block as last line in my lines/point files.
>

That's a misunderstanding. The rules need to be assigned before setting
the garmin type. I meant that you might be able to move the include
directive to the point just before you start with assigning the garmin
types. That's what I have done in the default style.

_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: mergeroads branch

Felix Hartmann-2

On 11.09.2013 21:15, WanMil wrote:

>>>>
>> that only no matters I know of course. I didn't know however that the
>> text block can also be added at the very end of the lines file (I
>> assumed it needs to be set before an 0x?? routable line is handled in
>> the style). That's perfect - in that case my style-file will stay easier
>> to read and I'll just add the block as last line in my lines/point
>> files.
>>
>
> That's a misunderstanding. The rules need to be assigned before
> setting the garmin type. I meant that you might be able to move the
> include directive to the point just before you start with assigning
> the garmin types. That's what I have done in the default style.

Okay - that's how I thought it would work.
Could maybe maybe the syntax be changed from mkgmap:access:MODE=YES/NO
to mkgmap:MODE=YES/NO -- till now it was MODE=YES/NO so
mkgmap:MODE=YES/NO would be enough. I don't think it's confusing, but it
saves space in the lines/pois file without being ambiguous - I think
:access is a bit superfluous.
_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: mergeroads branch

Felix Hartmann-2
In reply to this post by WanMil
Okay I've worked through my way of all the new features/implementations needed for the mergeroads branch,
but I get really stuck at the access treatment.

It's basically impossible for me to implement it.
I (and I know many other people using mkgmap do it too) often have conditions in the lines file, like the following:

highway=path & tracktype=5 {set access=no}

with the new notation that line becomes simply crazy:

(highway=path & tracktype=5) {set mkgmap:access:emergency=no; set mkgmap:access:delivery=no; set mkgmap:access:car=no; set mkgmap:access:bus=no; set mkgmap:access:taxi=no; set mkgmap:access:foot=no; set mkgmap:access:bike=no; set mkgmap:access:truck=no; set mkgmap:access:carpool=no }


So clearly a function "set mkgmap:access=no" is needed for the lines file that is afterwards reworded to the long line above....
that would fit well with "set mkgmap:MODE=no" as proposed in the previous email.


I won't be able to test the branch before the set mkgmap:access=no is implemented, because I simply cannot rewrite my style otherwise (it would mean that the character count of my lines file would double to triple, rendering the lines file very difficult to read).

I think it's perfectly alright to move the current defaults of treating routable features into the style-file. It actually makes mkgmap behaviour much clearer, but there must be simple syntax which currently is missing.


Felix


P.S. I have currently 347 times "set access=no" in my lines file, only 10 or so before the first [0x??] so replacing that each time with "set mkgmap:access:emergency=no; set mkgmap:access:delivery=no; set mkgmap:access:car=no; set mkgmap:access:bus=no; set mkgmap:access:taxi=no; set mkgmap:access:foot=no; set mkgmap:access:bike=no; set mkgmap:access:truck=no; set mkgmap:access:carpool=no"
is crazy.


(it's too bad that garmin couples the layout to the routing. If we had complete separation from routing and layout - it would be much much easier and allow for much simpler lines files - sadly this is not changeable at all. In that case we could have a routing file, and a lines_layout file both completely independent )


On 11.09.2013 21:15, WanMil wrote:



The goal of the branch is to give complete control to the style
implementor. So we need the new tags mkgmap:access:bike,
mkgmap:access:foot etc.

As a style developer you can decide to use the new tags directly or
you can still use the OSM access tags and include the access handling
at a later point in your style.
Maybe it's easier for you if you know that only the value no is
evaluated for the mkgmap:access:* tags. So setting them to yes or
designated or whatever is the same like not setting the tag.

I am happy if you have any good ideas to make it simpler.



that only no matters I know of course. I didn't know however that the
text block can also be added at the very end of the lines file (I
assumed it needs to be set before an 0x?? routable line is handled in
the style). That's perfect - in that case my style-file will stay easier
to read and I'll just add the block as last line in my lines/point files.


That's a misunderstanding. The rules need to be assigned before setting the garmin type. I meant that you might be able to move the include directive to the point just before you start with assigning the garmin types. That's what I have done in the default style.



_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: mergeroads branch

WanMil
In reply to this post by Felix Hartmann-2
>>> that only no matters I know of course. I didn't know however that the
>>> text block can also be added at the very end of the lines file (I
>>> assumed it needs to be set before an 0x?? routable line is handled in
>>> the style). That's perfect - in that case my style-file will stay easier
>>> to read and I'll just add the block as last line in my lines/point
>>> files.
>>>
>>
>> That's a misunderstanding. The rules need to be assigned before
>> setting the garmin type. I meant that you might be able to move the
>> include directive to the point just before you start with assigning
>> the garmin types. That's what I have done in the default style.
>
> Okay - that's how I thought it would work.
> Could maybe maybe the syntax be changed from mkgmap:access:MODE=YES/NO
> to mkgmap:MODE=YES/NO -- till now it was MODE=YES/NO so
> mkgmap:MODE=YES/NO would be enough. I don't think it's confusing, but it
> saves space in the lines/pois file without being ambiguous - I think
> :access is a bit superfluous.

Ok, I don't mind renaming that.

_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: mergeroads branch

WanMil
In reply to this post by Felix Hartmann-2
> Okay I've worked through my way of all the new features/implementations
> needed for the mergeroads branch,
> but I get really stuck at the access treatment.
>
> It's basically impossible for me to implement it.
> I (and I know many other people using mkgmap do it too) often have
> conditions in the lines file, like the following:
>
> highway=path & tracktype=5 {set access=no}
>
> with the new notation that line becomes simply crazy:
>
> /(highway=path & tracktype=5) {set mkgmap:access:emergency=no; set
> mkgmap:access:delivery=no; set mkgmap:access:car=no; set
> mkgmap:access:bus=no; set mkgmap:access:taxi=no; set
> mkgmap:access:foot=no; set mkgmap:access:bike=no; set
> mkgmap:access:truck=no; set mkgmap:access:carpool=no }/
>
>
> So clearly a function "set mkgmap:access=no" is needed for the lines
> file that is afterwards reworded to the long line above....
> that would fit well with "set mkgmap:MODE=no" as proposed in the
> previous email.
>
>
> I won't be able to test the branch before the set mkgmap:access=no is
> implemented, because I simply cannot rewrite my style otherwise (it
> would mean that the character count of my lines file would double to
> triple, rendering the lines file very difficult to read).
>
> I think it's perfectly alright to move the current defaults of treating
> routable features into the style-file. It actually makes mkgmap
> behaviour much clearer, but there must be simple syntax which currently
> is missing.
>
>
> Felix
>
>
> P.S. I have currently 347 times "set access=no" in my lines file, only
> 10 or so before the first [0x??] so replacing that each time with/"set
> mkgmap:access:emergency=no; set mkgmap:access:delivery=no; set
> mkgmap:access:car=no; set mkgmap:access:bus=no; set
> mkgmap:access:taxi=no; set mkgmap:access:foot=no; set
> mkgmap:access:bike=no; set mkgmap:access:truck=no; set
> mkgmap:access:carpool=no"/
> is crazy.
>
>
> (it's too bad that garmin couples the layout to the routing. If we had
> complete separation from routing and layout - it would be much much
> easier and allow for much simpler lines files - sadly this is not
> changeable at all. In that case we could have a routing file, and a
> lines_layout file both completely independent )
>

Felix, you're welcome :-)
Getting such comments is the reason to implement and test these new
features in a branch.
I can easily add handling for mkgmap:access=no into the java sources.

That requires to cleary define an order the access tags are handled. The
order is defined as follows:

1. mkgmap:access=no
   => all access fields in the map are set to no
2. mkgmap:carpool=yes
   => all access fiels are set to no, except carpool, emergency and bus.
      The through route bit is set to no.
      This rule already existed in the java source code before my changes
3. In all other cases all mkgmap:* access tags are evaluated.

WanMil
_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: mergeroads branch

WanMil
>> Okay I've worked through my way of all the new features/implementations
>> needed for the mergeroads branch,
>> but I get really stuck at the access treatment.
>>
>> It's basically impossible for me to implement it.
>> I (and I know many other people using mkgmap do it too) often have
>> conditions in the lines file, like the following:
>>
>> highway=path & tracktype=5 {set access=no}
>>
>> with the new notation that line becomes simply crazy:
>>
>> /(highway=path & tracktype=5) {set mkgmap:access:emergency=no; set
>> mkgmap:access:delivery=no; set mkgmap:access:car=no; set
>> mkgmap:access:bus=no; set mkgmap:access:taxi=no; set
>> mkgmap:access:foot=no; set mkgmap:access:bike=no; set
>> mkgmap:access:truck=no; set mkgmap:access:carpool=no }/
>>
>>
>> So clearly a function "set mkgmap:access=no" is needed for the lines
>> file that is afterwards reworded to the long line above....
>> that would fit well with "set mkgmap:MODE=no" as proposed in the
>> previous email.
>>
>>
>> I won't be able to test the branch before the set mkgmap:access=no is
>> implemented, because I simply cannot rewrite my style otherwise (it
>> would mean that the character count of my lines file would double to
>> triple, rendering the lines file very difficult to read).
>>
>> I think it's perfectly alright to move the current defaults of treating
>> routable features into the style-file. It actually makes mkgmap
>> behaviour much clearer, but there must be simple syntax which currently
>> is missing.
>>
>>
>> Felix
>>
>>
>> P.S. I have currently 347 times "set access=no" in my lines file, only
>> 10 or so before the first [0x??] so replacing that each time with/"set
>> mkgmap:access:emergency=no; set mkgmap:access:delivery=no; set
>> mkgmap:access:car=no; set mkgmap:access:bus=no; set
>> mkgmap:access:taxi=no; set mkgmap:access:foot=no; set
>> mkgmap:access:bike=no; set mkgmap:access:truck=no; set
>> mkgmap:access:carpool=no"/
>> is crazy.
>>
>>
>> (it's too bad that garmin couples the layout to the routing. If we had
>> complete separation from routing and layout - it would be much much
>> easier and allow for much simpler lines files - sadly this is not
>> changeable at all. In that case we could have a routing file, and a
>> lines_layout file both completely independent )
>>
>
> Felix, you're welcome :-)
> Getting such comments is the reason to implement and test these new
> features in a branch.
> I can easily add handling for mkgmap:access=no into the java sources.
>
> That requires to cleary define an order the access tags are handled. The
> order is defined as follows:
>
> 1. mkgmap:access=no
>     => all access fields in the map are set to no
> 2. mkgmap:carpool=yes
>     => all access fiels are set to no, except carpool, emergency and bus.
>        The through route bit is set to no.
>        This rule already existed in the java source code before my changes
> 3. In all other cases all mkgmap:* access tags are evaluated.
>
> WanMil

I have comitted the changes. So you can start with adapting your style
and with testing.

WanMil

_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: mergeroads branch

Felix Hartmann-2

On 12.09.2013 20:58, WanMil wrote:

>> Felix, you're welcome :-)
>> Getting such comments is the reason to implement and test these new
>> features in a branch.
>> I can easily add handling for mkgmap:access=no into the java sources.
>>
>> That requires to cleary define an order the access tags are handled. The
>> order is defined as follows:
>>
>> 1. mkgmap:access=no
>>      => all access fields in the map are set to no
>> 2. mkgmap:carpool=yes
>>      => all access fiels are set to no, except carpool, emergency and bus.
>>         The through route bit is set to no.
>>         This rule already existed in the java source code before my changes
>> 3. In all other cases all mkgmap:* access tags are evaluated.
>>
>> WanMil
> I have comitted the changes. So you can start with adapting your style
> and with testing.
>
> WanMil
>
> _______________________________________________
> mkgmap-dev mailing list
> [hidden email]
> http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Very good, however....

I should have been more clear. I not only need mkgmap:access=no, but
also mkgmap:access=yes...
For some special circumstances I want to make sure, that access rights
set to no beforehand, are reset to yes.
I assumed the implementation would be done anyhow for yes and no -
however I think if I read the changed passage, only no will work.

as for carpool - setting mkgmap:carpool=no is not logical regarding the
way garmin implements this. So maybe there should be a little note in
the inc/access that due to the way mkgmap:carpool works, setting it to
no is not possible (it wouldn't be clear what access rights to set).

Oh yeah, I hope not only set but also add works for
mkgmap:access=yes/no.... (in order to set something explicit for further
treatment - as yes is not the same as "default/unset" while working down
the lines file (of course in the end in the garmin .img yes is identical
to default/unset - but before explicit vs implicit could make a difference).

Also the default inc/access should use that mkgmap:access=no IMHO (or at
least include a line "# you could also replace the following block with
mkgmap:access=no").

_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: mergeroads branch

Felix Hartmann-2

On 13.09.2013 08:46, Felix Hartmann wrote:

>
> On 12.09.2013 20:58, WanMil wrote:
>
>>> Felix, you're welcome :-)
>>> Getting such comments is the reason to implement and test these new
>>> features in a branch.
>>> I can easily add handling for mkgmap:access=no into the java sources.
>>>
>>> That requires to cleary define an order the access tags are handled.
>>> The
>>> order is defined as follows:
>>>
>>> 1. mkgmap:access=no
>>>      => all access fields in the map are set to no
>>> 2. mkgmap:carpool=yes
>>>      => all access fiels are set to no, except carpool, emergency
>>> and bus.
>>>         The through route bit is set to no.
>>>         This rule already existed in the java source code before my
>>> changes
>>> 3. In all other cases all mkgmap:* access tags are evaluated.
>>>
>>> WanMil
>> I have comitted the changes. So you can start with adapting your style
>> and with testing.
>>
>> WanMil
>>
>> _______________________________________________
>> mkgmap-dev mailing list
>> [hidden email]
>> http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> Very good, however....
>
> I should have been more clear. I not only need mkgmap:access=no, but
> also mkgmap:access=yes...
> For some special circumstances I want to make sure, that access rights
> set to no beforehand, are reset to yes.
> I assumed the implementation would be done anyhow for yes and no -
> however I think if I read the changed passage, only no will work.
>
> as for carpool - setting mkgmap:carpool=no is not logical regarding
> the way garmin implements this. So maybe there should be a little note
> in the inc/access that due to the way mkgmap:carpool works, setting it
> to no is not possible (it wouldn't be clear what access rights to set).
>
> Oh yeah, I hope not only set but also add works for
> mkgmap:access=yes/no.... (in order to set something explicit for
> further treatment - as yes is not the same as "default/unset" while
> working down the lines file (of course in the end in the garmin .img
> yes is identical to default/unset - but before explicit vs implicit
> could make a difference).
>
> Also the default inc/access should use that mkgmap:access=no IMHO (or
> at least include a line "# you could also replace the following block
> with mkgmap:access=no").
>
oh what happens if I do
{delete mkgmap:access=no/yes}  -- will it only delete the tag per se, or
will it set mkgmap:bicycle or mkgmap:motorcar as well? I hope it does
the same as until now, namely just deleting the tag (as the
actions/consequences of the tag should only be evaluated once the 0x??
part is handled.....


what happens if I have the following line
bicycle=* {set mkgmap:bicycle='${bicycle}' }
will only bicycle=no be regarded, or will bicycle=private also be set as no?
will mkgmap crash/produce an error if bicycle=dismount or any other non
recognised values is present?


I must say, the new access handling is really complicated - at least on
my style. I'm trying to rewrite it to produce the old behaviour since
well 3-4 hours, but still not near halfway...

_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: mergeroads branch

Felix Hartmann-2
okay, finally I managed to rewrite my style -- woohaa - neded about 10
hours of CTRL-H and controlling the results....

I just noticed that versus the patched version of mkgmap trunk filesize
increased by about 1%. Overall the rendering speed made no difference or
maybe even increased 1-2% (well I used ignore-maxspeeds all the time,
maybe for some the branch is actually faster - even though I now only
look at bicycle, access, foot tags, and in some cases motorcar - leaving
all other access tags untreated). I deem the size increase is due to
looking at the turn angle which was not done in the available patch.

Actually, could the turn angle and merge road setting be adjustable
somewhere (or quick explanation?). I think I don't want to have any
angle restrictions - except no merging of roads where another road
crosses with at least 3° to max 177° angle (and 183-357°), but I would
have to play around with it to see implications on (long-distance)-routing.

I would like that all possible highways should be joined if no other
highway is crossing it / junction. However as I often use copies of the
same way, with different road_class/road_speed restrictions , I hope
that theese unreal junctions do not stop the merging of roads. Also
nonroutable lines shouldn't be looked at all when merging roads (so you
can have the same amount of merge no matter if you use a second line for
display and another line for routing, or add a line for a bridge).
I will try to check that with gpsmapedit in the following days...


As for mapping private to no, I could implement that without too much
hassle.
As for the other values like destination, permissive, and so on - I just
hope mkgmap ignores them just like yes is ignored.

I do hope that setting { add mkgmap:access=yes } works by setting all
not yet set access values to yes.
while {set mkgmap:access=yes} should overwrite all previously set
mkgmap:access; mkgmap:motorcycle, mkgmap:bicycle and so on...

Then it would be in line with previous workflow. Actually the above
mechanism is pretty essential - else I will have to spend days if not
weeks to completely rewrite access handling....



Felix (will go to bed now, local time is 1AM  and no more time to check
the resulting map about routing quality).
On 13.09.2013 10:41, Felix Hartmann wrote:

> oh what happens if I do
> {delete mkgmap:access=no/yes}  -- will it only delete the tag per se,
> or will it set mkgmap:bicycle or mkgmap:motorcar as well? I hope it
> does the same as until now, namely just deleting the tag (as the
> actions/consequences of the tag should only be evaluated once the 0x??
> part is handled.....
>
>
> what happens if I have the following line
> bicycle=* {set mkgmap:bicycle='${bicycle}' }
> will only bicycle=no be regarded, or will bicycle=private also be set
> as no?
> will mkgmap crash/produce an error if bicycle=dismount or any other
> non recognised values is present?
>
>
> I must say, the new access handling is really complicated - at least
> on my style. I'm trying to rewrite it to produce the old behaviour
> since well 3-4 hours, but still not near halfway...


_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

commit 2691 -- really needed?

Felix Hartmann-2
In reply to this post by WanMil
I didn't see any speed improvement. Could you recheck if there is really
any improvment - and only if so, implement it?
Or at least have Yes and yes and YES all valid, for true, which is
usually never the correct value in OSM, maybe we could be case sensitive
(but actually I would prefer to keep True valid too when searching for
true explicitely in lines file ---> i.e. oneway=yes | oneway=true should
also be valid if oneway=True is tagged...
On 08.09.2013 14:01, WanMil wrote:

> Hi,
>
> the mergeroads branch should be stable now so I invite all to test it.
>
> Here are the changes compared to trunk:
>
> * Roads now become merged before the routing network is created. This
> might improve routing on long distances (I have seen some). The number
> of roads in the routing network is reduced by 10-20% (in germany).
>
> * refs are now composed in the style sheet and not in java code. The new
> tag mkgmap:ref is used for that (see inc/refs in default style).
>
> * access restrictions are now also handled in the style sheet and not in
> java code. There are some new tags for that:
> mkgmap:access:emergency
> mkgmap:access:delivery
> mkgmap:access:car
> mkgmap:access:bus
> mkgmap:access:taxi
> mkgmap:access:foot
> mkgmap:access:bike
> mkgmap:access:truck
> mkgmap:access:carpool
> If a tag is set to 'no' the given access type is restricted in the map.
> All other values are mapped to 'yes'.
> I have tried to convert the java code to the style sheet. This was quite
> complicated but I hope it's rather correct. See new include file inc/access.
>
> * Instead of using hardcoded rules for maxspeed it is now possible to
> control that via style file. Set the mkgmap:road-speed-class tag to the
> desired class value (0 to 7) and use the new functions maxspeedkmh() and
> maxspeedmph() to parse the maxspeed tag.
>
> * Two new actions that seems useful to me:
> echotags 'Hello'
> prints out the OSM element id plus all tags of the element plus the
> text. This seems to be useful for style debugging.
>
> deletealltags
> removes all tags from an element and therefore stops its processing.
>
>
> I would be happy to get a lot of feedback!
>
> Have fun!
> WanMil
> _______________________________________________
> mkgmap-dev mailing list
> [hidden email]
> http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: mergeroads branch

Felix Hartmann-2
In reply to this post by WanMil
okay, I quickly checked out some routes - but so far only in Mapsource.
Seems the long distance routing on the branch is quite a lot better than
with the old patch.
E.g. same route calculated but on 1. try instead of 3. try. And 165
instead of 181 intersections (or better directions in Mapsource routing
list). Other times different ways chosen - in general same way but less
intersections.

On the unpatched trunk ,the routing was even a little worse. So far -
but this is really no decent analysis - good work.
On 08.09.2013 14:01, WanMil wrote:

> Hi,
>
> the mergeroads branch should be stable now so I invite all to test it.
>
> Here are the changes compared to trunk:
>
> * Roads now become merged before the routing network is created. This
> might improve routing on long distances (I have seen some). The number
> of roads in the routing network is reduced by 10-20% (in germany).
>
> * refs are now composed in the style sheet and not in java code. The new
> tag mkgmap:ref is used for that (see inc/refs in default style).
>
> * access restrictions are now also handled in the style sheet and not in
> java code. There are some new tags for that:
> mkgmap:access:emergency
> mkgmap:access:delivery
> mkgmap:access:car
> mkgmap:access:bus
> mkgmap:access:taxi
> mkgmap:access:foot
> mkgmap:access:bike
> mkgmap:access:truck
> mkgmap:access:carpool
> If a tag is set to 'no' the given access type is restricted in the map.
> All other values are mapped to 'yes'.
> I have tried to convert the java code to the style sheet. This was quite
> complicated but I hope it's rather correct. See new include file inc/access.
>
> * Instead of using hardcoded rules for maxspeed it is now possible to
> control that via style file. Set the mkgmap:road-speed-class tag to the
> desired class value (0 to 7) and use the new functions maxspeedkmh() and
> maxspeedmph() to parse the maxspeed tag.
>
> * Two new actions that seems useful to me:
> echotags 'Hello'
> prints out the OSM element id plus all tags of the element plus the
> text. This seems to be useful for style debugging.
>
> deletealltags
> removes all tags from an element and therefore stops its processing.
>
>
> I would be happy to get a lot of feedback!
>
> Have fun!
> WanMil
> _______________________________________________
> mkgmap-dev mailing list
> [hidden email]
> http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: commit 2691 -- really needed?

WanMil
In reply to this post by Felix Hartmann-2
Having a look at taginfo I guess that non case sensitive checking is not
required:
http://taginfo.openstreetmap.org/keys/oneway#values
http://taginfo.openstreetmap.org/keys/bridge#values
http://taginfo.openstreetmap.org/keys/tunnel#values
http://taginfo.openstreetmap.org/keys/access#values
http://taginfo.openstreetmap.org/keys/area#values

Is taginfo case sensitive?
WanMil

> I didn't see any speed improvement. Could you recheck if there is really
> any improvment - and only if so, implement it?
> Or at least have Yes and yes and YES all valid, for true, which is
> usually never the correct value in OSM, maybe we could be case sensitive
> (but actually I would prefer to keep True valid too when searching for
> true explicitely in lines file ---> i.e. oneway=yes | oneway=true should
> also be valid if oneway=True is tagged...
> On 08.09.2013 14:01, WanMil wrote:
>> Hi,
>>
>> the mergeroads branch should be stable now so I invite all to test it.
>>
>> Here are the changes compared to trunk:
>>
>> * Roads now become merged before the routing network is created. This
>> might improve routing on long distances (I have seen some). The number
>> of roads in the routing network is reduced by 10-20% (in germany).
>>
>> * refs are now composed in the style sheet and not in java code. The new
>> tag mkgmap:ref is used for that (see inc/refs in default style).
>>
>> * access restrictions are now also handled in the style sheet and not in
>> java code. There are some new tags for that:
>> mkgmap:access:emergency
>> mkgmap:access:delivery
>> mkgmap:access:car
>> mkgmap:access:bus
>> mkgmap:access:taxi
>> mkgmap:access:foot
>> mkgmap:access:bike
>> mkgmap:access:truck
>> mkgmap:access:carpool
>> If a tag is set to 'no' the given access type is restricted in the map.
>> All other values are mapped to 'yes'.
>> I have tried to convert the java code to the style sheet. This was quite
>> complicated but I hope it's rather correct. See new include file inc/access.
>>
>> * Instead of using hardcoded rules for maxspeed it is now possible to
>> control that via style file. Set the mkgmap:road-speed-class tag to the
>> desired class value (0 to 7) and use the new functions maxspeedkmh() and
>> maxspeedmph() to parse the maxspeed tag.
>>
>> * Two new actions that seems useful to me:
>> echotags 'Hello'
>> prints out the OSM element id plus all tags of the element plus the
>> text. This seems to be useful for style debugging.
>>
>> deletealltags
>> removes all tags from an element and therefore stops its processing.
>>
>>
>> I would be happy to get a lot of feedback!
>>
>> Have fun!
>> WanMil
>> _______________________________________________
>> mkgmap-dev mailing list
>> [hidden email]
>> http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>
> _______________________________________________
> mkgmap-dev mailing list
> [hidden email]
> http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>

_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
123