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
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 mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
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.
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.
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
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? http://wiki.openstreetmap.org/wiki/Mkgmap/help/Tags Or is it too early?
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
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.
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.
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.
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.
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.
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
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
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 mkgmap-dev@lists.mkgmap.org.uk 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").
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 mkgmap-dev@lists.mkgmap.org.uk 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...
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...
okay, finally I managed to rewrite my style -- woohaa - neded about 10 hours of CTRL-H and controlling the results....
Wow, you seem to have an epic style :-)
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.
The branch is more accurate with merging. The patch merged some roads that should not be merged... I do not expect better rendering speed because merging is applied to roads only. All other ways are merged by the merge-lines option which is the default since r2586.
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.
Ways are not merged if the angle ([-180;180]) between them is greater than 130° or lower than -130°. I can add an mkgmap option for the angle but the number of merges that are restricted by the angle is quite small. We had the approach to remove some options so I think adding a new option is not very good. But you can play with it. You can change the max angle and enable a log message in line 265 and 266 of the RoadMerger class.
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.
Ways are merged only if their garmin type, road class/speed and a special list of tags are identical. The special list of tags contains all tags that are evaluated by mkgmap after the style processing.
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...
Nonroutable lines are not merged by the new merger. They are merged by the --merge-lines option.
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...
Current behaviour is: 1. mkgmap:access=no? => Set all garmin access flags to no. Ignore all other mkgmap:* access tags like mkgmap:bike. 2. mkgmap:carpool=yes? => Set only the hardcoded garmin access flags carpool, emergency and bus to yes, all others to no. Ignore all other mkgmap:* access tags. 3. Else: Set all garmin access flags to yes unless the mkgmap:* tag is set to no. I am thinking about that especially in rule 1 ignoring all other tags might not be useful for style implementors. Would it be better to have mkgmap:access=yes/no as a default? So if mkgmap:access=no all garmin flags are set to no. But if mkgmap:bike is set to yes the garmin access flag for bikes is also set to yes. WanMil
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 mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
On 13.09.2013 22:52, WanMil wrote:
okay, finally I managed to rewrite my style -- woohaa - neded about 10 hours of CTRL-H and controlling the results....
Wow, you seem to have an epic style :-) well that happens if you always add rules as mkgmap gains features, maybe at some point I should take a week to rewrite it in cleaner form....
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.
The branch is more accurate with merging. The patch merged some roads that should not be merged... I do not expect better rendering speed because merging is applied to roads only. All other ways are merged by the merge-lines option which is the default since r2586. okay, I'll check it anyhow sometimes.
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.
Ways are not merged if the angle ([-180;180]) between them is greater than 130° or lower than -130°. I can add an mkgmap option for the angle but the number of merges that are restricted by the angle is quite small. We had the approach to remove some options so I think adding a new option is not very good.
But you can play with it. You can change the max angle and enable a log message in line 265 and 266 of the RoadMerger class. great.
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.
Ways are merged only if their garmin type, road class/speed and a special list of tags are identical. The special list of tags contains all tags that are evaluated by mkgmap after the style processing.
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...
Nonroutable lines are not merged by the new merger. They are merged by the --merge-lines option.
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...
Current behaviour is: 1. mkgmap:access=no? => Set all garmin access flags to no. Ignore all other mkgmap:* access tags like mkgmap:bike. 2. mkgmap:carpool=yes? => Set only the hardcoded garmin access flags carpool, emergency and bus to yes, all others to no. Ignore all other mkgmap:* access tags. 3. Else: Set all garmin access flags to yes unless the mkgmap:* tag is set to no.
I am thinking about that especially in rule 1 ignoring all other tags might not be useful for style implementors. Would it be better to have mkgmap:access=yes/no as a default? So if mkgmap:access=no all garmin flags are set to no. But if mkgmap:bike is set to yes the garmin access flag for bikes is also set to yes. if I don't understand your concern for 1. That's what one can use add for, isn't it? well in my opinion the most important is order - because that's how the style-file worked so far. So if I would expect the following behavior (based on the assumption of no previous rules):
highway=track, tracktype=grade2, bicycle=no, foot=private 1. highway=* tracktype=grade2 {set mkgmap:bicycle=yes} highway=* & bicycle=no {add mkgmap:access=no} --- result bicycle=yes - foot=yes, all other set to no (there is no rule for foot = private, value is set, so add cannot overwrite it) 1.1 highway=* tracktype=grade2 {set mkgmap:bicycle=yes} highway=* & bicycle=no {set mkgmap:access=no} --- result all access types no, as the second rule comes later and set should always overrule. 1.2 highway=* tracktype=grade2 {add mkgmap:bicycle=yes} highway=* & bicycle=no {set mkgmap:access=no} --- result all access types no, as the second rule comes later and set should always overrule. As bicycle is only add command - it would be no anyhow. 1.3 highway=* & bicycle=no {set mkgmap:access=no} highway=* tracktype=grade2 {set mkgmap:bicycle=yes} -- bicycle=yes, all other access types no. later rule overrules earlier 1.4a highway=* tracktype=grade2 {set mkgmap:access=no;set mkgmap:bicycle=yes; } -- Does mkgmap keep track of order of commands set within one bracket?? Well here the case is quite clear anyhow. Set access=no but bicycle=yes 1.4b - heavily conflicting: highway=* tracktype=grade2 {set mkgmap:bicycle=yes; set mkgmap:access=no} -- Does mkgmap keep track of order of commands set within one bracket?? If yes the logical answer would be to set all types to no. If not, then bicycle=yes and all other =no would be expected. 1.5 bicycle=* {set mkgmap:bicycle='${bicycle}' } foot=* {set mkgmap:bicycle='${foot}' } highway=* & tracktype=grade2 {add mkgmap:access=yes} -- foot = no (there is no rule to convert private to no); bicycle = no; all other types set to yes. 1.6 bicycle=* {set mkgmap:bicycle='${bicycle}' } foot=* {set mkgmap:bicycle='${foot}' } highway=* & tracktype=grade2 {set mkgmap:access=yes} -- well last rule is set all to yes, so previous rules don't apply. All types to no.
WanMil
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 mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Well to make styles easier, maybe we could have a third command which works like a in between add and set. That command would only set mkgmap: tags, in case they are not default, therefore you could later on in the style run rules with differentiation between set explicitely by set, and other set implicitely... Example 2. (to keep in order with the previous email). highway=track, bicycle=yes, foot=no 2.1 bicycle=* {setdifferent mkgmap:bicycle='${bicycle}' } foot=* {setdifferent mkgmap:foot='${foot}' } -- result: mkgmap:foot=no; mkgmap:bicycle=UNSET 2.2. bicycle=* {set mkgmap:bicycle='${bicycle}' } foot=* {set mkgmap:foot='${foot}' } -- result: mkgmap:foot=no; mkgmap:bicycle=yes 2.3 bicycle=* {adddifferent mkgmap:bicycle='${bicycle}' } foot=* {adddifferent mkgmap:foot='${foot}' } -- result: mkgmap:foot=no; mkgmap:bicycle=UNSET However I'm not so sure this is really needed. My main problem when rewriting the style was that I have different road_class or road_speed if an access type like bicycle or motorcar or foot is private / designated / .... Therefore I couldn't just simply replace my old set / add commands, as in the branch only NO matters. Everything else is effectively trashed. Previously I knew that private would mean no, So I could write different rules for it somewhere in the style, while still having the outcome of private meaning no is set. Now I have to make sure that I look in rules at the original bicycle or foot values, but write all {] content for both bicycle and mkgmap:bicycle as example, because otherwise the result is different than before. As private is not NO anymore, getting old behavior meant rewriting quite a lot of lines manually instead of simple CRTL-H exchanging. The setdiffferent idea is not really related to the mergeroads branch it's rather something that I already in past had to write a bit more complex rules and replicate tags to achieve the wanted result of knowing original value of a tag, while setting it to something new.
Thanks Felix, I have to think about your proposals. WanMil
Well to make styles easier, maybe we could have a third command which works like a in between add and set. That command would only set mkgmap: tags, in case they are not default, therefore you could later on in the style run rules with differentiation between set explicitely by set, and other set implicitely... Example 2. (to keep in order with the previous email). highway=track, bicycle=yes, foot=no
2.1 bicycle=* {setdifferent mkgmap:bicycle='${bicycle}' } foot=* {setdifferent mkgmap:foot='${foot}' }
-- result: mkgmap:foot=no; mkgmap:bicycle=UNSET
2.2. bicycle=* {set mkgmap:bicycle='${bicycle}' } foot=* {set mkgmap:foot='${foot}' }
-- result: mkgmap:foot=no; mkgmap:bicycle=yes
2.3 bicycle=* {adddifferent mkgmap:bicycle='${bicycle}' } foot=* {adddifferent mkgmap:foot='${foot}' }
-- result: mkgmap:foot=no; mkgmap:bicycle=UNSET
However I'm not so sure this is really needed. My main problem when rewriting the style was that I have different road_class or road_speed if an access type like bicycle or motorcar or foot is private / designated / .... Therefore I couldn't just simply replace my old set / add commands, as in the branch only NO matters. Everything else is effectively trashed. Previously I knew that private would mean no, So I could write different rules for it somewhere in the style, while still having the outcome of private meaning no is set. Now I have to make sure that I look in rules at the original bicycle or foot values, but write all {] content for both bicycle and mkgmap:bicycle as example, because otherwise the result is different than before. As private is not NO anymore, getting old behavior meant rewriting quite a lot of lines manually instead of simple CRTL-H exchanging. The setdiffferent idea is not really related to the mergeroads branch it's rather something that I already in past had to write a bit more complex rules and replicate tags to achieve the wanted result of knowing original value of a tag, while setting it to something new. _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
well only implement if you see it really needed. I don't think it's that important and the same result can be achieved with little more code. More important is the rule to treat any rule by order, and if two rules are given in the same command, go from unspecific to specific (mkgmap:foot overrules mkgmap:access in same command). It is however important that the rule order - if given in several commands is executed in order, or directly. E.g. based on some tags one might disallow a certain kind of transport - let's say: tracktype=grade5 {add mkgmap:bicycle=no} however later on you check for highway=* & route=bicycle {mkgmap:access=yes} if your map only addresses cyclist, you clearly want that the routing uses this way, even though it could be in very bad condition - because it is part of a route, and probably there is no better alternative nearby - or the actual more common problem - some tags are simply plain wrong - and you therefore want to change it. Later rules should always overwrite earlier rules - no matter what. (that's also the only possibility to make two oneway ways which have each direction different class/speed - out of a single way). On 15.09.2013 19:44, WanMil wrote:
Thanks Felix,
I have to think about your proposals.
WanMil
Well to make styles easier, maybe we could have a third command which works like a in between add and set. That command would only set mkgmap: tags, in case they are not default, therefore you could later on in the style run rules with differentiation between set explicitely by set, and other set implicitely... Example 2. (to keep in order with the previous email). highway=track, bicycle=yes, foot=no
2.1 bicycle=* {setdifferent mkgmap:bicycle='${bicycle}' } foot=* {setdifferent mkgmap:foot='${foot}' }
-- result: mkgmap:foot=no; mkgmap:bicycle=UNSET
2.2. bicycle=* {set mkgmap:bicycle='${bicycle}' } foot=* {set mkgmap:foot='${foot}' }
-- result: mkgmap:foot=no; mkgmap:bicycle=yes
2.3 bicycle=* {adddifferent mkgmap:bicycle='${bicycle}' } foot=* {adddifferent mkgmap:foot='${foot}' }
-- result: mkgmap:foot=no; mkgmap:bicycle=UNSET
However I'm not so sure this is really needed. My main problem when rewriting the style was that I have different road_class or road_speed if an access type like bicycle or motorcar or foot is private / designated / .... Therefore I couldn't just simply replace my old set / add commands, as in the branch only NO matters. Everything else is effectively trashed. Previously I knew that private would mean no, So I could write different rules for it somewhere in the style, while still having the outcome of private meaning no is set. Now I have to make sure that I look in rules at the original bicycle or foot values, but write all {] content for both bicycle and mkgmap:bicycle as example, because otherwise the result is different than before. As private is not NO anymore, getting old behavior meant rewriting quite a lot of lines manually instead of simple CRTL-H exchanging. The setdiffferent idea is not really related to the mergeroads branch it's rather something that I already in past had to write a bit more complex rules and replicate tags to achieve the wanted result of knowing original value of a tag, while setting it to something new. _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Well to make styles easier, maybe we could have a third command which works like a in between add and set. That command would only set mkgmap: tags, in case they are not default, therefore you could later on in the style run rules with differentiation between set explicitely by set, and other set implicitely... Example 2. (to keep in order with the previous email). highway=track, bicycle=yes, foot=no
2.1 bicycle=* {setdifferent mkgmap:bicycle='${bicycle}' } foot=* {setdifferent mkgmap:foot='${foot}' }
-- result: mkgmap:foot=no; mkgmap:bicycle=UNSET
2.2. bicycle=* {set mkgmap:bicycle='${bicycle}' } foot=* {set mkgmap:foot='${foot}' }
-- result: mkgmap:foot=no; mkgmap:bicycle=yes
2.3 bicycle=* {adddifferent mkgmap:bicycle='${bicycle}' } foot=* {adddifferent mkgmap:foot='${foot}' }
-- result: mkgmap:foot=no; mkgmap:bicycle=UNSET
However I'm not so sure this is really needed. My main problem when rewriting the style was that I have different road_class or road_speed if an access type like bicycle or motorcar or foot is private / designated / .... Therefore I couldn't just simply replace my old set / add commands, as in the branch only NO matters. Everything else is effectively trashed. Previously I knew that private would mean no, So I could write different rules for it somewhere in the style, while still having the outcome of private meaning no is set. Now I have to make sure that I look in rules at the original bicycle or foot values, but write all {] content for both bicycle and mkgmap:bicycle as example, because otherwise the result is different than before. As private is not NO anymore, getting old behavior meant rewriting quite a lot of lines manually instead of simple CRTL-H exchanging. The setdiffferent idea is not really related to the mergeroads branch it's rather something that I already in past had to write a bit more complex rules and replicate tags to achieve the wanted result of knowing original value of a tag, while setting it to something new.
Hi Felix, first start with the easiest thing: I think the setdifferent action is superfluous. You could easily change your rules to
2.1 bicycle=no {set mkgmap:bicycle='no' } foot=no {set mkgmap:foot='no' }
-- result: mkgmap:foot=no; mkgmap:bicycle=UNSET
2.2. bicycle=* {set mkgmap:bicycle='${bicycle}' } foot=* {set mkgmap:foot='${foot}' }
-- result: mkgmap:foot=no; mkgmap:bicycle=yes
2.3 bicycle=no {add mkgmap:bicycle='no' } foot=no {add mkgmap:foot='no' }
-- result: mkgmap:foot=no; mkgmap:bicycle=UNSET
Regarding that in the branch only the value 'no' matters: Would it help if I add an option "nonaccessvalues" where you can define which values are read as "no access"? So to have the same behaviour as the trunk you would set the option --nonaccessvalues=no,private Anyhow I haven't fully understood why you couldn't add rules to the start of your style: access=private { set mkgmap:access='no' } bicycle=private { set mkgmap:bike='no' } ... So you still have access to the original values and you have set the access flag to 'no'. WanMil
On 03.10.2013 20:50, WanMil wrote:
Well to make styles easier, maybe we could have a third command which works like a in between add and set. That command would only set mkgmap: tags, in case they are not default, therefore you could later on in the style run rules with differentiation between set explicitely by set, and other set implicitely... Example 2. (to keep in order with the previous email). highway=track, bicycle=yes, foot=no
2.1 bicycle=* {setdifferent mkgmap:bicycle='${bicycle}' } foot=* {setdifferent mkgmap:foot='${foot}' }
-- result: mkgmap:foot=no; mkgmap:bicycle=UNSET
2.2. bicycle=* {set mkgmap:bicycle='${bicycle}' } foot=* {set mkgmap:foot='${foot}' }
-- result: mkgmap:foot=no; mkgmap:bicycle=yes
2.3 bicycle=* {adddifferent mkgmap:bicycle='${bicycle}' } foot=* {adddifferent mkgmap:foot='${foot}' }
-- result: mkgmap:foot=no; mkgmap:bicycle=UNSET
However I'm not so sure this is really needed. My main problem when rewriting the style was that I have different road_class or road_speed if an access type like bicycle or motorcar or foot is private / designated / .... Therefore I couldn't just simply replace my old set / add commands, as in the branch only NO matters. Everything else is effectively trashed. Previously I knew that private would mean no, So I could write different rules for it somewhere in the style, while still having the outcome of private meaning no is set. Now I have to make sure that I look in rules at the original bicycle or foot values, but write all {] content for both bicycle and mkgmap:bicycle as example, because otherwise the result is different than before. As private is not NO anymore, getting old behavior meant rewriting quite a lot of lines manually instead of simple CRTL-H exchanging. The setdiffferent idea is not really related to the mergeroads branch it's rather something that I already in past had to write a bit more complex rules and replicate tags to achieve the wanted result of knowing original value of a tag, while setting it to something new.
Hi Felix,
first start with the easiest thing: I think the setdifferent action is superfluous. You could easily change your rules to
2.1 bicycle=no {set mkgmap:bicycle='no' } foot=no {set mkgmap:foot='no' }
-- result: mkgmap:foot=no; mkgmap:bicycle=UNSET
2.2. bicycle=* {set mkgmap:bicycle='${bicycle}' } foot=* {set mkgmap:foot='${foot}' }
-- result: mkgmap:foot=no; mkgmap:bicycle=yes
2.3 bicycle=no {add mkgmap:bicycle='no' } foot=no {add mkgmap:foot='no' }
-- result: mkgmap:foot=no; mkgmap:bicycle=UNSET
Regarding that in the branch only the value 'no' matters: Would it help if I add an option "nonaccessvalues" where you can define which values are read as "no access"? So to have the same behaviour as the trunk you would set the option --nonaccessvalues=no,private yes - that would help and simplify a lot.
Anyhow I haven't fully understood why you couldn't add rules to the start of your style: access=private { set mkgmap:access='no' } bicycle=private { set mkgmap:bike='no' } ... So you still have access to the original values and you have set the access flag to 'no'. the problem is that other rules "further down the lines" file check on whether mgmap:access=no is set or not set. Currently with private not being no, I would need to check on both private and no, which makes the style-file longer/more complicated. The main problem arises due to access=private being set wrong in OSM in at least 50% of its use cases (my guess).
Signs like the German "Privatstraße - Zufahrt verboten" (Private Road, Drive in no allowed) are tagged as access=private, while they should actually be vehicle or motor_vehicle=private. Also people interprete the simple sign "Privatstraße (Private Road)" as access=private - even if access is allowed, because they confuse ownership with access rights. In other cases there might actually be bicycle=no signs, but in reality no-one cares because they are not executed, and so on... So just translating what is in OSM to mkgmap:access doesn't work. On the other hand we also need to make sure that physical hinderance (e.g. tracktype, sac_scale, mtb:scale, and so on) are translated into mkgmap:access. So yes - having a table which keys are read as no, would be great. Then one could also set mkgmap:access=impossible (in order to separate it from "not allowed") for checks, and in the end end up with both being unroutable.
WanMil
Hi, I'm simplifying these things just in the beginning for all needed cases. Eg. bicycle=designated | bicycle=official {set bicycle=yes} bicycle=private | ( access=private & bicycle!=yes) { set access=no } and so on. If you'll need the original values, you can use a namespace. But I only care about "Are bicycles allowed or not". Don't know if you do the same. So in the end of this process all ways with common access-tags have an access=yes or access=no. These two values are used in the style afterwards. Henning
well for me it's a bit more complicated, because I often run checks on the set values (and whether they were set because of physical inabilities or legal). Therefore I already run one set of alternative name scheme for access values - but the branch meant I needed to ammend/change about 500 lines of code. If it was only about changing the access value it would have been easy, the problematic part was that simply replacing bicycle= and bicycle!= was impossible due to other keys which would have conflicted - so I ended up manually going through everything using CTRL-H reading each line before changing - instead of CTRL-H and "change all"... the fact that private would mean yes made it even more difficult - as I had quite a few checks for & bicycle=private or bicycle!=private that needed to be replaced with an alternative keyscheme (and hencefort adding a check for each of them further down the lines file)... On 04.10.2013 20:16, Henning Scholland wrote:
Hi, I'm simplifying these things just in the beginning for all needed cases. Eg.
bicycle=designated | bicycle=official {set bicycle=yes} bicycle=private | ( access=private & bicycle!=yes) { set access=no }
and so on. If you'll need the original values, you can use a namespace. But I only care about "Are bicycles allowed or not". Don't know if you do the same. So in the end of this process all ways with common access-tags have an access=yes or access=no. These two values are used in the style afterwards.
Henning
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 mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
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 mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
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 mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 08.09.2013 14:01, schrieb WanMil: Hi
* 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.
I've made a test with this style rules, but with a enabled inc/roadspeed i got this error java.lang.AssertionError: value is null at uk.me.parabola.mkgmap.reader.osm.Tags.put(Tags.java:73) at uk.me.parabola.mkgmap.reader.osm.Element.addTag(Element.java:44) at uk.me.parabola.mkgmap.osmstyle.function.CachedFunction.value(CachedFunction.java:62) at uk.me.parabola.mkgmap.osmstyle.eval.NumericOp.eval(NumericOp.java:47) at uk.me.parabola.mkgmap.osmstyle.eval.AndOp.eval(AndOp.java:34) at uk.me.parabola.mkgmap.osmstyle.ActionRule.resolveType(ActionRule.java:59) at uk.me.parabola.mkgmap.osmstyle.RuleSet.resolveType(RuleSet.java:68) at uk.me.parabola.mkgmap.osmstyle.StyledConverter.convertWay(StyledConverter.java:214) at uk.me.parabola.mkgmap.reader.osm.ElementSaver.convert(ElementSaver.java:239) at uk.me.parabola.mkgmap.reader.osm.o5m.O5mBinMapDataSource.load(O5mBinMapDataSource.java:53) at uk.me.parabola.mkgmap.reader.osm.OsmMapDataSource.load(OsmMapDataSource.java:127) at uk.me.parabola.mkgmap.main.MapMaker.loadFromFile(MapMaker.java:167) at uk.me.parabola.mkgmap.main.MapMaker.makeMap(MapMaker.java:63) at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:243) at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:239) at java.util.concurrent.FutureTask.run(FutureTask.java:262) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:724) This happened with most, but not all, tiles created from splitter, 30 of 32 tiles around Bonn + 100 km, print out this error, 2 tiles are ok Maybe i forgot to delete some of my old rules, but i can't find anything Bernd -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlI0a5gACgkQwCMdlf933K+NlQCgkOg+DD1UiE7kl2ynXAzaIn8t VpQAoJqefMrGn1tSo0Yn2szIL63UyUz+ =hTz1 -----END PGP SIGNATURE-----
Thanks! I've comitted a fix. WanMil
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Am 08.09.2013 14:01, schrieb WanMil: Hi
* 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.
I've made a test with this style rules, but with a enabled inc/roadspeed i got this error
java.lang.AssertionError: value is null at uk.me.parabola.mkgmap.reader.osm.Tags.put(Tags.java:73) at uk.me.parabola.mkgmap.reader.osm.Element.addTag(Element.java:44) at uk.me.parabola.mkgmap.osmstyle.function.CachedFunction.value(CachedFunction.java:62) at uk.me.parabola.mkgmap.osmstyle.eval.NumericOp.eval(NumericOp.java:47) at uk.me.parabola.mkgmap.osmstyle.eval.AndOp.eval(AndOp.java:34) at uk.me.parabola.mkgmap.osmstyle.ActionRule.resolveType(ActionRule.java:59) at uk.me.parabola.mkgmap.osmstyle.RuleSet.resolveType(RuleSet.java:68) at uk.me.parabola.mkgmap.osmstyle.StyledConverter.convertWay(StyledConverter.java:214) at uk.me.parabola.mkgmap.reader.osm.ElementSaver.convert(ElementSaver.java:239) at uk.me.parabola.mkgmap.reader.osm.o5m.O5mBinMapDataSource.load(O5mBinMapDataSource.java:53) at uk.me.parabola.mkgmap.reader.osm.OsmMapDataSource.load(OsmMapDataSource.java:127) at uk.me.parabola.mkgmap.main.MapMaker.loadFromFile(MapMaker.java:167) at uk.me.parabola.mkgmap.main.MapMaker.makeMap(MapMaker.java:63) at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:243) at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:239) at java.util.concurrent.FutureTask.run(FutureTask.java:262) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:724)
This happened with most, but not all, tiles created from splitter, 30 of 32 tiles around Bonn + 100 km, print out this error, 2 tiles are ok
Maybe i forgot to delete some of my old rules, but i can't find anything
Bernd
-----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux)
iEYEARECAAYFAlI0a5gACgkQwCMdlf933K+NlQCgkOg+DD1UiE7kl2ynXAzaIn8t VpQAoJqefMrGn1tSo0Yn2szIL63UyUz+ =hTz1 -----END PGP SIGNATURE----- _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 15.09.2013 19:07, schrieb WanMil:
Thanks! I've comitted a fix. thank you, too
it works now Bernd -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlI1+v8ACgkQwCMdlf933K8dAwCdG7riv8/UKkz3ZHRqomtIgSgl tUAAn1a88z9lfmB8P7F6R/hsJlL+nZua =fq/M -----END PGP SIGNATURE-----
Hi WanMil, I tested a few routes and see nice improvements regarding the calculation time on the device staying at home, so I have no idea if it also improves the turn left/right messages. Regarding the changes in the source code please check: The method mergeRoads() is called before the other routines that manipulate lines. If I got that right this can cause trouble with the continue statement in the style which produces overlaid lines and the loop in StyledConverter following this line: // make sure that copies of modified roads are have equal points Not sure, but I think the roads which were merged should somehow appear in the deletedRoads or modifiedRoads ? Gerd -- View this message in context: http://gis.19327.n5.nabble.com/mergeroads-branch-tp5776711p5778221.html Sent from the Mkgmap Development mailing list archive at Nabble.com.
Hi WanMil,
I tested a few routes and see nice improvements regarding the calculation time on the device staying at home, so I have no idea if it also improves the turn left/right messages.
Regarding the changes in the source code please check: The method mergeRoads() is called before the other routines that manipulate lines. If I got that right this can cause trouble with the continue statement in the style which produces overlaid lines and the loop in StyledConverter following this line: // make sure that copies of modified roads are have equal points
Not sure, but I think the roads which were merged should somehow appear in the deletedRoads or modifiedRoads ?
Thanks for the hint! I will check that. WanMil
Gerd
Regarding the changes in the source code please check: The method mergeRoads() is called before the other routines that manipulate lines. If I got that right this can cause trouble with the continue statement in the style which produces overlaid lines and the loop in StyledConverter following this line: // make sure that copies of modified roads are have equal pointshe
Not sure, but I think the roads which were merged should somehow appear in the deletedRoads or modifiedRoads ?
Thanks for the hint! I will check that.
Mmmh, after a quick check I think there is no easy solution. And it's a bug too :-( The modifiedRoads contains all way ids that are modified in the removeShortArcs handling. The deletedRoads contains all ids that have been removed by removeShortArcs. Assume the following: Way-Id: 4711 Tags: highway=motorway; bridge=yes Way-Id: 4712 Tags: highway=motorway 4711 and 4712 are connected. Style: highway=motorway & bride=yes [ 0x2222 continue ] highway=motorway [ 0x01 ] 0x2222 is used for drawing a bridge on top of the motorway. The result are three garmin objects: 0x01 (4711) -- 0x2222 (4711) == 0x01 (4712) --- The RoadMerger merges the 0x01 4711 and 4712 garmin objects. So we have 0x01 (4711) ------ 0x2222 (4711) == If the removeShortArcs modified the 0x01 way the id 4711 is added to the modifiedRoads list. That means that the points of 0x2222 are copied to the 0x2222 object. Maybe the merge routine has to be moved after the removeShortArcs handling. WanMil
Hi WanMil, WanMil wrote
Maybe the merge routine has to be moved after the removeShortArcs handling.
yes, I think it should be moved after the loop that copies the points. Gerd -- View this message in context: http://gis.19327.n5.nabble.com/mergeroads-branch-tp5776711p5778258.html Sent from the Mkgmap Development mailing list archive at Nabble.com.
Hi Gerd, I have moved the merging after the short arcs handling. I modified the merging in that way that the highway count at the merged point is decreased. Now I get several warnings about routing problems: possible routing problem: road end-points not both coordNodes: (http://www.openstreetmap.org/browse/way/157720528) Do you have any idea why there is a problem when decreasing the highway count by one for the merged point? WanMil
Hi WanMil,
WanMil wrote
Maybe the merge routine has to be moved after the removeShortArcs handling.
yes, I think it should be moved after the loop that copies the points.
Gerd
-- View this message in context: http://gis.19327.n5.nabble.com/mergeroads-branch-tp5776711p5778258.html Sent from the Mkgmap Development mailing list archive at Nabble.com. _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi WanMil, I think I found a few special cases where the highway count is not correctly maintained when ways are split. Maybe this happens now more often because the merging produces longer roads. Please check my patch posted here: http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2013q2/018344.html Gerd WanMil wrote
Hi Gerd,
I have moved the merging after the short arcs handling.
I modified the merging in that way that the highway count at the merged point is decreased. Now I get several warnings about routing problems:
possible routing problem: road end-points not both coordNodes: (http://www.openstreetmap.org/browse/way/157720528)
Do you have any idea why there is a problem when decreasing the highway count by one for the merged point?
WanMil
Hi WanMil,
WanMil wrote
Maybe the merge routine has to be moved after the removeShortArcs handling.
yes, I think it should be moved after the loop that copies the points.
Gerd
-- View this message in context: http://gis.19327.n5.nabble.com/mergeroads-branch-tp5776711p5778258.html Sent from the Mkgmap Development mailing list archive at Nabble.com. _______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- View this message in context: http://gis.19327.n5.nabble.com/mergeroads-branch-tp5776711p5778328.html Sent from the Mkgmap Development mailing list archive at Nabble.com.
Hi Gerd, with the patch no more error messages are generated. So it seem to fix the problem. Great :-) I took a glimpse at the patch and I am wondering why the removeShortArcs method now makes a difference between "foot-only" ways and other ways. (The isFootOnlyAccess(Way way) catched my attention during merging the patch). Can you explain that? The removeShortArcs method is too complicate now to get a quick understanding... WanMil
Hi WanMil,
I think I found a few special cases where the highway count is not correctly maintained when ways are split. Maybe this happens now more often because the merging produces longer roads. Please check my patch posted here: http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2013q2/018344.html
Gerd
WanMil wrote
Hi Gerd,
I have moved the merging after the short arcs handling.
I modified the merging in that way that the highway count at the merged point is decreased. Now I get several warnings about routing problems:
possible routing problem: road end-points not both coordNodes: (http://www.openstreetmap.org/browse/way/157720528)
Do you have any idea why there is a problem when decreasing the highway count by one for the merged point?
WanMil
Hi WanMil,
WanMil wrote
Maybe the merge routine has to be moved after the removeShortArcs handling.
yes, I think it should be moved after the loop that copies the points.
Gerd
-- View this message in context: http://gis.19327.n5.nabble.com/mergeroads-branch-tp5776711p5778258.html Sent from the Mkgmap Development mailing list archive at Nabble.com. _______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- View this message in context: http://gis.19327.n5.nabble.com/mergeroads-branch-tp5776711p5778328.html Sent from the Mkgmap Development mailing list archive at Nabble.com. _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi WanMil, I have to look at it again. I think you will need only a small part of the patch to solve your problem, and the other part will not work with the latest changes regarding the styles and access. Gerd WanMil wrote
Hi Gerd,
with the patch no more error messages are generated. So it seem to fix the problem. Great :-)
I took a glimpse at the patch and I am wondering why the removeShortArcs method now makes a difference between "foot-only" ways and other ways. (The isFootOnlyAccess(Way way) catched my attention during merging the patch). Can you explain that? The removeShortArcs method is too complicate now to get a quick understanding...
WanMil
Hi WanMil,
I think I found a few special cases where the highway count is not correctly maintained when ways are split. Maybe this happens now more often because the merging produces longer roads. Please check my patch posted here: http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2013q2/018344.html
Gerd
WanMil wrote
Hi Gerd,
I have moved the merging after the short arcs handling.
I modified the merging in that way that the highway count at the merged point is decreased. Now I get several warnings about routing problems:
possible routing problem: road end-points not both coordNodes: (http://www.openstreetmap.org/browse/way/157720528)
Do you have any idea why there is a problem when decreasing the highway count by one for the merged point?
WanMil
Hi WanMil,
WanMil wrote
Maybe the merge routine has to be moved after the removeShortArcs handling.
yes, I think it should be moved after the loop that copies the points.
Gerd
-- View this message in context: http://gis.19327.n5.nabble.com/mergeroads-branch-tp5776711p5778258.html Sent from the Mkgmap Development mailing list archive at Nabble.com. _______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- View this message in context: http://gis.19327.n5.nabble.com/mergeroads-branch-tp5776711p5778328.html Sent from the Mkgmap Development mailing list archive at Nabble.com. _______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- View this message in context: http://gis.19327.n5.nabble.com/mergeroads-branch-tp5776711p5778369.html Sent from the Mkgmap Development mailing list archive at Nabble.com.
Hi, GerdP wrote
Hi WanMil,
I have to look at it again. I think you will need only a small part of the patch to solve your problem, and the other part will not work with the latest changes regarding the styles and access.
ok, here is what I remember: I created the patch because I observed a lot of problems with the --link-pois-to-ways option in combination with the short arc removal. This option changes Coord to CoordPOI instances and therefore adds a lot of short arcs to rather iunimportant ways, e.g. small ways ending on big roads, blocked with bollards or barriers: RRRRRRRRR | b | As the short-arc-removal algo doesn't care about importance of the road, it might move points of the big road towards the bollards to remove a short arc in the small "unimportant" way. The irony is that many of the small ways are tagged as footways, so the bollards or barriers should be IMHO ignored reg. routing. So, I tried to filter those CoordPOI which are added to footways. While working on the patch I found the errors reg. the maintenance of the highway count and also some outaged comments. It would have been better to separate them from the rest of the patch :-( Gerd -- View this message in context: http://gis.19327.n5.nabble.com/mergeroads-branch-tp5776711p5778385.html Sent from the Mkgmap Development mailing list archive at Nabble.com.
Hi,
GerdP wrote
Hi WanMil,
I have to look at it again. I think you will need only a small part of the patch to solve your problem, and the other part will not work with the latest changes regarding the styles and access.
ok, here is what I remember: I created the patch because I observed a lot of problems with the --link-pois-to-ways option in combination with the short arc removal. This option changes Coord to CoordPOI instances and therefore adds a lot of short arcs to rather iunimportant ways, e.g. small ways ending on big roads, blocked with bollards or barriers: RRRRRRRRR | b |
Bingo! That's exactly what I observed. One example is way http://www.openstreetmap.org/browse/way/25344551 (the east end).
As the short-arc-removal algo doesn't care about importance of the road, it might move points of the big road towards the bollards to remove a short arc in the small "unimportant" way. The irony is that many of the small ways are tagged as footways, so the bollards or barriers should be IMHO ignored reg. routing. So, I tried to filter those CoordPOI which are added to footways. While working on the patch I found the errors reg. the maintenance of the highway count and also some outaged comments. It would have been better to separate them from the rest of the patch :-(
I think we should reimplement the --link-pois-to-ways option. Maybe the following algorithm would work: Before the removeShortArcs removal check all POIs and create a list which ways need to be changed due to the POIs and at which point (Coord and/or distance from start/end point). After the removeShortArcs option apply the changes. Due to the information stored in the list before the removeShortArcs option it should be possible to ensure that changes are applied only to correct ways and not to coord merged ways. WanMil
Gerd
Hi WanMil,
I think we should reimplement the --link-pois-to-ways option. Maybe the following algorithm would work: Before the removeShortArcs removal check all POIs and create a list which ways need to be changed due to the POIs and at which point (Coord and/or distance from start/end point). After the removeShortArcs option apply the changes. Due to the information stored in the list before the removeShortArcs option it should be possible to ensure that changes are applied only to correct ways and not to coord merged ways.
I saw that you finally used the patch. Did you change your opinion? Gerd
Hi WanMil,
I think we should reimplement the --link-pois-to-ways option. Maybe the following algorithm would work: Before the removeShortArcs removal check all POIs and create a list which ways need to be changed due to the POIs and at which point (Coord and/or distance from start/end point). After the removeShortArcs option apply the changes. Due to the information stored in the list before the removeShortArcs option it should be possible to ensure that changes are applied only to correct ways and not to coord merged ways.
I saw that you finally used the patch. Did you change your opinion?
No, but using the patch is better than using it not :-) You wrote: "The irony is that *many* of the small ways are tagged as footways, so the bollards or barriers should be IMHO ignored reg. routing." So your patch is a workaround which fixes many problems (great!) but which is not a general solution. So later on we should rethink the --link-pois-to-ways option to find a general solution. WanMil
Gerd
Hi WanMil, WanMil wrote
So your patch is a workaround which fixes many problems (great!) but which is not a general solution. So later on we should rethink the --link-pois-to-ways option to find a general solution.
yes, I agree. I always have the feeling that some of the many loops regarding routing are not at the right place, as we join and split ways for so many different reasons. Gerd -- View this message in context: http://gis.19327.n5.nabble.com/mergeroads-branch-tp5776711p5778642.html Sent from the Mkgmap Development mailing list archive at Nabble.com.
participants (7)
-
Bernd Weigelt -
Felix Hartmann -
Gerd Petermann -
GerdP
-
Henning Scholland -
Manfred Brenneisen -
WanMil