Bloody typical, you wait around for ages hoping for a new routing capability to be added to mkgmap and then two come along on the same day. I've been trying to discover how unpavedness is encoded for at least 6 months. Every now and again, I return to think about it some more. Check and re-check the same old data structures. Very frustrating, no progress. Damn those cunning bastards at Garmin.... However, a month or two ago, I discovered that Table C contains more than just turn restrictions. I still don't know many of it's little secrets but, today, having exhausted all other possibilities, I finally twigged that Table C contains the key to understanding "unpavedness". Gotcha! The attached patch allows you to add either unpaved=yes/true/1 or paved=no/false/0 to a way and then it will be ignored for routing purposes when the GPS has been told to avoid unpaved roads. Not sure if those are the best tags to use - any thoughts? BTW - the unpaved road line type 0x0a has nothing to do with unpavedness, it's just a routable way that gets drawn as a dashed line (default rendering). Feedback, etc. Mark
On 07.12.2009 22:36, Mark Burton wrote:
Bloody typical, you wait around for ages hoping for a new routing capability to be added to mkgmap and then two come along on the same day.
I've been trying to discover how unpavedness is encoded for at least 6 months. Every now and again, I return to think about it some more. Check and re-check the same old data structures. Very frustrating, no progress. Damn those cunning bastards at Garmin....
However, a month or two ago, I discovered that Table C contains more than just turn restrictions. I still don't know many of it's little secrets but, today, having exhausted all other possibilities, I finally twigged that Table C contains the key to understanding "unpavedness". Gotcha!
The attached patch allows you to add either unpaved=yes/true/1 or paved=no/false/0 to a way and then it will be ignored for routing purposes when the GPS has been told to avoid unpaved roads.
Not sure if those are the best tags to use - any thoughts?
BTW - the unpaved road line type 0x0a has nothing to do with unpavedness, it's just a routable way that gets drawn as a dashed line (default rendering).
Feedback, etc.
Mark
I have problems compiling with that patch: compile: [javac] Compiling 317 source files to d:\Garmin\mkgmap_svn_trunk3\build\classes [javac] d:\Garmin\mkgmap_svn_trunk3\src\uk\me\parabola\mkgmap\osmstyle\StyledConverter.java:1418: illegal start of expression [javac] if(way.isBoolTag("unpaved") || way.isNotBoolTag("paved"))) [javac] ^ [javac] 1 error Will try again against a clean trunk but I am not using many patches currently (basicly only the blacklist/whitelist patch plus some simple value changes that should not affect anything). BTW I think the blacklist / whitelist tag file patch would be good to include as no-one noticed anything broken (I don't need it and just used it for testing - but I think it can be useful for some mapmakers).
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Nope, also against clean trunk the patch does not compile for me: prepare: [mkdir] Created dir: d:\Garmin\mkgmap_svn_trunk\build\classes compile: [javac] Compiling 317 source files to d:\Garmin\mkgmap_svn_trunk\build\classes [javac] d:\Garmin\mkgmap_svn_trunk\src\uk\me\parabola\mkgmap\osmstyle\StyledConverter.java:1431: illegal start of expression [javac] if(way.isBoolTag("unpaved") || way.isNotBoolTag("paved"))) [javac] ^ [javac] 1 error BUILD FAILED d:\Garmin\mkgmap_svn_trunk\build.xml:71: Compile failed; see the compiler error output for details. On 07.12.2009 22:36, Mark Burton wrote:
Bloody typical, you wait around for ages hoping for a new routing capability to be added to mkgmap and then two come along on the same day.
I've been trying to discover how unpavedness is encoded for at least 6 months. Every now and again, I return to think about it some more. Check and re-check the same old data structures. Very frustrating, no progress. Damn those cunning bastards at Garmin....
However, a month or two ago, I discovered that Table C contains more than just turn restrictions. I still don't know many of it's little secrets but, today, having exhausted all other possibilities, I finally twigged that Table C contains the key to understanding "unpavedness". Gotcha!
The attached patch allows you to add either unpaved=yes/true/1 or paved=no/false/0 to a way and then it will be ignored for routing purposes when the GPS has been told to avoid unpaved roads.
Not sure if those are the best tags to use - any thoughts?
BTW - the unpaved road line type 0x0a has nothing to do with unpavedness, it's just a routable way that gets drawn as a dashed line (default rendering).
Feedback, etc.
Mark
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Mark Burton schrieb:
The attached patch allows you to add either unpaved=yes/true/1 or paved=no/false/0 to a way and then it will be ignored for routing purposes when the GPS has been told to avoid unpaved roads.
Not sure if those are the best tags to use - any thoughts?
I think the most used tag is surface=unpaved, but as usual we can do this in the style file. highway=* & (surface=unpaved | surface=dirt | surface=sand | surface=ground | surface=gravel) {add unpaved=yes} Chris
On 08.12.2009 00:17, Chris-Hein Lunkhusen wrote:
Mark Burton schrieb:
The attached patch allows you to add either unpaved=yes/true/1 or paved=no/false/0 to a way and then it will be ignored for routing purposes when the GPS has been told to avoid unpaved roads.
Not sure if those are the best tags to use - any thoughts?
I think the most used tag is surface=unpaved, but as usual we can do this in the style file.
highway=*& (surface=unpaved | surface=dirt | surface=sand | surface=ground | surface=gravel) {add unpaved=yes}
Chris
Well I prefer if it it is kept like right now, and surface=* is not automatically considered as unpaved avoidance and the tag itself is not present in OSM database. This leaves more choice in the style-file to abuse the unpaved tag (and allows the choice if for example tracktype=grade2 is considered to be avoided or not via "avoid unpaved roads". The default style-file of course should have something like below: highway=*& (surface=unpaved | surface=dirt | surface=sand | surface=ground | surface=gravel | tracktype=grade2 | tracktype=grade3 | tracktype=grade4 | tracktype=grade5 | sac_scale=* | smothness= ........) {add unpaved=yes}
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Not sure if those are the best tags to use - any thoughts?
I think the most used tag is surface=unpaved, but as usual we can do this in the style file.
highway=*& (surface=unpaved | surface=dirt | surface=sand | surface=ground | surface=gravel) {add unpaved=yes}
Chris
Well I prefer if it it is kept like right now, and surface=* is not automatically considered as unpaved avoidance and the tag itself is not present in OSM database. This leaves more choice in the style-file to abuse the unpaved tag (and allows the choice if for example tracktype=grade2 is considered to be avoided or not via "avoid unpaved roads".
The default style-file of course should have something like below:
highway=*& (surface=unpaved | surface=dirt | surface=sand | surface=ground | surface=gravel | tracktype=grade2 | tracktype=grade3 | tracktype=grade4 | tracktype=grade5 | sac_scale=* | smothness= ........) {add unpaved=yes}
Felix echoes my thoughts exactly. There's lot's of surface values that imply unpavedness so using surface=unpaved isn't the way to go. I did wonder about using a mkgmap specific tag, e.g. mkgmap:unpaved=yes but as unpaved=yes (or paved=no) do not obviously conflict with existing OSM tags, I thought I would not use the mkgmap: prefix. If people are happy with that, I will commit the patch soon as it is. Mark
Hi Mark,
The default style-file of course should have something like below:
highway=*& (surface=unpaved | surface=dirt | surface=sand | surface=ground | surface=gravel | tracktype=grade2 | tracktype=grade3 | tracktype=grade4 | tracktype=grade5 | sac_scale=* | smothness= ........) {add unpaved=yes}
Felix echoes my thoughts exactly. There's lot's of surface values that imply unpavedness so using surface=unpaved isn't the way to go. I did wonder about using a mkgmap specific tag, e.g. mkgmap:unpaved=yes but as unpaved=yes (or paved=no) do not obviously conflict with existing OSM tags, I thought I would not use the mkgmap: prefix.
http://wiki.openstreetmap.org/wiki/Proposed_features/surface_unification suggests surface:material, but then again, surface:material=asphalt, surface:condition!=maintained can be worse than some surface:material=gravel. It seems best to introduce a mkgmap:paved tag that can be translated into by style files.
If people are happy with that, I will commit the patch soon as it is.
For what it is worth, I tried your v2 patch with the following, but I was unable to convince my Edge 705 to suggest using a forest path that it used to suggest until some weeks ago. (In other words, it avoided the unpaved roads no matter what the routing preference was.) Index: resources/styles/default/points =================================================================== --- resources/styles/default/points (revision 1420) +++ resources/styles/default/points (working copy) @@ -1,3 +1,6 @@ +surface=unpaved|surface=ground|surface=grass|surface=gravel|surface=sand|surface=unsurfaced|mtb:scale=* { add paved=no } +surface=paved|surface=asphalt { add paved=yes } + #aeroway=airport [0x5900 resolution 20] aeroway=airport [0x2f04 resolution 20] aeroway=aerodrome [0x2f04 resolution 20] Best regards, Marko
On 08.12.2009 10:42, Marko Mäkelä wrote:
Hi Mark,
The default style-file of course should have something like below:
highway=*& (surface=unpaved | surface=dirt | surface=sand | surface=ground | surface=gravel | tracktype=grade2 | tracktype=grade3 | tracktype=grade4 | tracktype=grade5 | sac_scale=* | smothness= ........) {add unpaved=yes}
Felix echoes my thoughts exactly. There's lot's of surface values that imply unpavedness so using surface=unpaved isn't the way to go. I did wonder about using a mkgmap specific tag, e.g. mkgmap:unpaved=yes but as unpaved=yes (or paved=no) do not obviously conflict with existing OSM tags, I thought I would not use the mkgmap: prefix.
http://wiki.openstreetmap.org/wiki/Proposed_features/surface_unification suggests surface:material, but then again, surface:material=asphalt, surface:condition!=maintained can be worse than some surface:material=gravel.
It seems best to introduce a mkgmap:paved tag that can be translated into by style files.
If people are happy with that, I will commit the patch soon as it is.
For what it is worth, I tried your v2 patch with the following, but I was unable to convince my Edge 705 to suggest using a forest path that it used to suggest until some weeks ago. (In other words, it avoided the unpaved roads no matter what the routing preference was.)
-- It makes not much sense to test like you do. You should build a testmap in JOSM and then do the testing to check whether it works or not. If a road is added as paved=no, then it will not be choosen at all even if it is much much shorter if you block it. Just like toll=yes. This is different to blocking something with motorcar=no, here it will block less strictly (only blocks as via, no blocking as terminal road). See for example this this picture. If I add the unpaved tag to a ferry (or the toll tag, both works) it will be avoided at all cost (yellow). If not it is a mere 511m trip (I put in a little difference so it is easier to differentiate the routes): Now here it is able to calculate a different route. If this were not possible, and only blocked via motorcar=no it would be used nevertheless. As toll or unpaved it will never be used if prohibited so no route at all will be found if no detour is possible.
Index: resources/styles/default/points =================================================================== --- resources/styles/default/points (revision 1420) +++ resources/styles/default/points (working copy) @@ -1,3 +1,6 @@ +surface=unpaved|surface=ground|surface=grass|surface=gravel|surface=sand|surface=unsurfaced|mtb:scale=* { add paved=no } +surface=paved|surface=asphalt { add paved=yes } + #aeroway=airport [0x5900 resolution 20] aeroway=airport [0x2f04 resolution 20] aeroway=aerodrome [0x2f04 resolution 20]
Best regards,
Marko _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Mark, congratulations to your success with the unpaved bit. For the keyword I would use mkgamp:unpaved, as some others has suggested too. In my opinion most if not all tags used by mkgmap should start with this prefix and should be translated in the style file. Regards, Johann Mark Burton schrieb:
Not sure if those are the best tags to use - any thoughts?
I think the most used tag is surface=unpaved, but as usual we can do this in the style file.
highway=*& (surface=unpaved | surface=dirt | surface=sand | surface=ground | surface=gravel) {add unpaved=yes}
Chris
Well I prefer if it it is kept like right now, and surface=* is not automatically considered as unpaved avoidance and the tag itself is not present in OSM database. This leaves more choice in the style-file to abuse the unpaved tag (and allows the choice if for example tracktype=grade2 is considered to be avoided or not via "avoid unpaved roads".
The default style-file of course should have something like below:
highway=*& (surface=unpaved | surface=dirt | surface=sand | surface=ground | surface=gravel | tracktype=grade2 | tracktype=grade3 | tracktype=grade4 | tracktype=grade5 | sac_scale=* | smothness= ........) {add unpaved=yes}
Felix echoes my thoughts exactly. There's lot's of surface values that imply unpavedness so using surface=unpaved isn't the way to go. I did wonder about using a mkgmap specific tag, e.g. mkgmap:unpaved=yes but as unpaved=yes (or paved=no) do not obviously conflict with existing OSM tags, I thought I would not use the mkgmap: prefix.
If people are happy with that, I will commit the patch soon as it is.
Mark _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev .
Hello all,
congratulations to your success with the unpaved bit.
Thanks Johann.
For the keyword I would use mkgamp:unpaved, as some others has suggested too. In my opinion most if not all tags used by mkgmap should start with this prefix and should be translated in the style file.
I agree. Therefore, I propose that we use: mkgmap:unpaved to tag ways that are "unpaved" mkgmap:ferry to tag ways that are "ferries" Mapping from OSM tags can be done in the style file. Is everyone happy with that? If so, I will make the change and commit it. Has anyone confirmed that the ferry part works yet? Mark
On 08.12.2009 18:46, Mark Burton wrote:
Hello all,
congratulations to your success with the unpaved bit.
Thanks Johann.
For the keyword I would use mkgamp:unpaved, as some others has suggested too. In my opinion most if not all tags used by mkgmap should start with this prefix and should be translated in the style file.
I agree. Therefore, I propose that we use:
mkgmap:unpaved to tag ways that are "unpaved"
mkgmap:ferry to tag ways that are "ferries"
Mapping from OSM tags can be done in the style file.
Is everyone happy with that? If so, I will make the change and commit it.
Has anyone confirmed that the ferry part works yet?
Yes works splendidly. No matter what 0x* type one chooses. Still did not get around doing the carpool stuff.
Mark _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Mark Burton schreef:
Is everyone happy with that? If so, I will make the change and commit it.
Shouldn't the default style then have a mkgmap:ferry so the default works as the regular Garmin map?
Has anyone confirmed that the ferry part works yet?
Works as expected. Thanks! V. -- Durgerdamstraat 29, 1507 JL Zaandam; telefoon 075-7074579
On Wed, Dec 09, 2009 at 09:09:28AM +0100, Valentijn Sessink wrote:
Mark Burton schreef:
Is everyone happy with that? If so, I will make the change and commit it.
Shouldn't the default style then have a mkgmap:ferry so the default works as the regular Garmin map?
Revision 1425 introduces that in addition to style rules for unpavedness. My poor Edge 705 cannot avoid ferries, only highway/toll/u-turns/unpaved, so I did not test that style change. Marko
Mark Burton wrote:
Hello all,
congratulations to your success with the unpaved bit.
Thanks Johann.
For the keyword I would use mkgamp:unpaved, as some others has suggested too. In my opinion most if not all tags used by mkgmap should start with this prefix and should be translated in the style file.
I agree. Therefore, I propose that we use:
mkgmap:unpaved to tag ways that are "unpaved"
mkgmap:ferry to tag ways that are "ferries"
Mapping from OSM tags can be done in the style file.
Is everyone happy with that? If so, I will make the change and commit it.
I disapprove. The trouble with the "mkgmap:unpaved=???" approach is that it duplicates existing functionality in OSM. We should strive to get the existing functionality better specified if it doesn't already do the job for us. Otherwise, mapping effort will be spent on adding a set of tags to OSM which only benefit the Garmin routable maps project. What about the TomTom people? Or the AndNav2 users? They'll want to know about routeable or unrouteable unpaved roads too. Unrouteable unpaved roads are a real-world fact, not a 'mkgmap' feature. I do agree though that OSM's tagging for road surfaces is a bit of a mess, but it needs an OSM-level cleanup if that's a problem, not at mkgmap-level. AFAIK there are "surface=???" "smoothness=???" "mtb:scale=???" "sac_scale=???" "rtc_rate=???" tags in OSM, all of which (sometimes in combinations) ought to be enough to give mkgmap the clues needed to set the routeability of a given way. Plus "access=???" and "<vehicle>=no" of course. Not just that, but those tags already exist. We should be using them. Steve
On 09.12.2009 11:27, Steve Hosgood wrote:
Mark Burton wrote:
Hello all,
congratulations to your success with the unpaved bit.
Thanks Johann.
For the keyword I would use mkgamp:unpaved, as some others has suggested too. In my opinion most if not all tags used by mkgmap should start with this prefix and should be translated in the style file.
I agree. Therefore, I propose that we use:
mkgmap:unpaved to tag ways that are "unpaved"
mkgmap:ferry to tag ways that are "ferries"
Mapping from OSM tags can be done in the style file.
Is everyone happy with that? If so, I will make the change and commit it.
I disapprove.
The trouble with the "mkgmap:unpaved=???" approach is that it duplicates existing functionality in OSM. We should strive to get the existing functionality better specified if it doesn't already do the job for us. Otherwise, mapping effort will be spent on adding a set of tags to OSM which only benefit the Garmin routable maps project. What about the TomTom people? Or the AndNav2 users? They'll want to know about routeable or unrouteable unpaved roads too.
Unrouteable unpaved roads are a real-world fact, not a 'mkgmap' feature.
I do agree though that OSM's tagging for road surfaces is a bit of a mess, but it needs an OSM-level cleanup if that's a problem, not at mkgmap-level.
AFAIK there are "surface=???" "smoothness=???" "mtb:scale=???" "sac_scale=???" "rtc_rate=???" tags in OSM, all of which (sometimes in combinations) ought to be enough to give mkgmap the clues needed to set the routeability of a given way. Plus "access=???" and "<vehicle>=no" of course.
Not just that, but those tags already exist. We should be using them. Steve
You don't seem to understand. You can use them and the default style should use some of them. However there is no clear borderline of what is paved and what is unpaved, therefore it is best to use a new key. You can then use rules like highway=* & .... {set mkgmap:unpaved=1} to have the street recognised as unpaved. Noone will ever put than key into the osm database. As all of the keys are based on different objectives this is up to the style-file to put the rules for what is considered paved and what not. highway)* & ( mtb:scale>1 | tracktype=grade2 | tracktpye=grade3 | tracktype=grade4 | tracktype=grade5 | smoothness=bad .....) {add mkgmap:unpaved=1} The goal of the mkgmap:.... key is that it DOES NOT exist in OSM database. And the decision which should be avoided or not, should be left to the style-file instead of being hardcoded somewhere into mkgamp.
Felix Hartmann wrote:
I do agree though that OSM's tagging for road surfaces is a bit of a mess, but it needs an OSM-level cleanup if that's a problem, not at mkgmap-level.
AFAIK there are "surface=???" "smoothness=???" "mtb:scale=???" "sac_scale=???" "rtc_rate=???" tags in OSM, all of which (sometimes in combinations) ought to be enough to give mkgmap the clues needed to set the routeability of a given way. Plus "access=???" and "<vehicle>=no" of course.
Not just that, but those tags already exist. We should be using them. Steve
You don't seem to understand.
No - I understand fine, thanks. I just disagree with the idea that this proposed new tag should be mkgmap-specific.
You can use them and the default style should use some of them. However there is no clear borderline of what is paved and what is unpaved, therefore it is best to use a new key.
Well, a new key is one option, getting the entire OSM community to tidy up a bit on the use of existing keys is another option. IMHO, if use of the existing keys isn't feasable, then any new key should be more like "autorouter=avoid" or something. This is not mkgmap-specific, it would apply to all the other projects looking to use OSM data for in-car GPS navigators, and the browser-driven computer navigators too. But before adding a new key, we should be able to "prove" that no combination of the existing keys does it for us. Steve
On 09.12.2009 12:45, Steve Hosgood wrote:
Felix Hartmann wrote:
I do agree though that OSM's tagging for road surfaces is a bit of a mess, but it needs an OSM-level cleanup if that's a problem, not at mkgmap-level.
AFAIK there are "surface=???" "smoothness=???" "mtb:scale=???" "sac_scale=???" "rtc_rate=???" tags in OSM, all of which (sometimes in combinations) ought to be enough to give mkgmap the clues needed to set the routeability of a given way. Plus "access=???" and "<vehicle>=no" of course.
Not just that, but those tags already exist. We should be using them. Steve
You don't seem to understand.
No - I understand fine, thanks. I just disagree with the idea that this proposed new tag should be mkgmap-specific. No, sorry to be so direct, but you clearly don't understand. There is no bloody new key or tag. There is just an mkgmap internal command for conversion. There will never be a universal understanding of what is paved and what not (or whether you can go there with your car, foot, bicycle or not). Therefore we have so many keys. Now it is only a question of how to convert it to Garmin .img. And that is what the style file is used for.
Noone wants that you add this key to OSM data! The same is true for ferries. Noone want you to add mkgmap:ferry=1 to osm data, but by using it like this one could for example only exclude gondolas or other features on avoid ferries, but not block ferries themselves. Garmin format is limited (or can you show me an avoid "cablecar" or avoid "drag_lift" key?) - therefore many mappers add actions to commands that are not what they tell you they are - so e.g. by clicking avoid ferries, you will actually avoid cablecars and other aerialways. Some other people might find this useful to block/enable public transport routing. The same goes for unpaved. Not everyone will use it to block unpaved ways. Some people will want to convert this function to something completly different. E.g. if I want to create a public transport only map for Garmin I could avoid toll=yes to avoid bus lines and tramways, avoid unpaved roads to avoid tubes and regional trains, and avoid ferries to avoid long distance trains.
You can use them and the default style should use some of them. However there is no clear borderline of what is paved and what is unpaved, therefore it is best to use a new key.
Well, a new key is one option, getting the entire OSM community to tidy up a bit on the use of existing keys is another option.
IMHO, if use of the existing keys isn't feasable, then any new key should be more like "autorouter=avoid" or something. This is not mkgmap-specific, it would apply to all the other projects looking to use OSM data for in-car GPS navigators, and the browser-driven computer navigators too.
But before adding a new key, we should be able to "prove" that no combination of the existing keys does it for us.
Steve
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Felix Hartmann wrote:
You don't seem to understand.
No - I understand fine, thanks. I just disagree with the idea that this proposed new tag should be mkgmap-specific. No, sorry to be so direct, but you clearly don't understand. Ah - no need to apologise! I clearly didn't understand!
There is no bloody new key or tag. There is just an mkgmap internal command for conversion. [...]
Noone wants that you add this key to OSM data!
Look - I'll just wear a paper bag over my head for the rest of the day, OK? :-) Steve
On Wed, Dec 09, 2009 at 12:12:47PM +0000, Steve Hosgood wrote:
Look - I'll just wear a paper bag over my head for the rest of the day, OK? :-)
No harm done, except some time spent in discussions. Remember, there are no stupid questions, but there may be stupid answers. The world is not black and white (is paving_stones or cobblestone paved?), and not everything is like it first looks like. The computer science solution to all this is adding one level of abstraction, which the mkgmap: family of attributes is all about. Marko
Quoting Steve Hosgood <steve@tallyho.bc.nu>:
Felix Hartmann wrote:
I do agree though that OSM's tagging for road surfaces is a bit of a mess, but it needs an OSM-level cleanup if that's a problem, not at mkgmap-level.
AFAIK there are "surface=???" "smoothness=???" "mtb:scale=???" "sac_scale=???" "rtc_rate=???" tags in OSM, all of which (sometimes in combinations) ought to be enough to give mkgmap the clues needed to set the routeability of a given way. Plus "access=???" and "<vehicle>=no" of course.
Not just that, but those tags already exist. We should be using them. Steve
You don't seem to understand.
No - I understand fine, thanks. I just disagree with the idea that this proposed new tag should be mkgmap-specific.
You can use them and the default style should use some of them. However there is no clear borderline of what is paved and what is unpaved, therefore it is best to use a new key.
Well, a new key is one option, getting the entire OSM community to tidy up a bit on the use of existing keys is another option.
IMHO, if use of the existing keys isn't feasable, then any new key should be more like "autorouter=avoid" or something. This is not mkgmap-specific, it would apply to all the other projects looking to use OSM data for in-car GPS navigators, and the browser-driven computer navigators too.
But before adding a new key, we should be able to "prove" that no combination of the existing keys does it for us.
Steve I think you're talking at crossed porpoises. The suggestion is that a mkgmap internal key is developed that takes existing OSM keys and simplifies them down to a specific tag in the style file rules that can in turn be used to help with routing. No new keys are being introduced to OSM, nothing is being duplicated and nothing is being done that harms the efforts of other map projects (TomTom etc). The new key only "exists" in mkgmap style file rules, and then only virtually during the compilation process whilst OSM tags are used to generate Garmin routable (or non-routable) objects.
Your suggestion of "autorouter=avoid" doesn't help because this key would never make it into the wider world of OSM data. And therefore won't be of use to any other projects. Hope that helps. -- Charlie
Hi Steve, On Wed, 09 Dec 2009 10:27:33 +0000 Steve Hosgood <steve@tallyho.bc.nu> wrote:
Mark Burton wrote:
Hello all,
congratulations to your success with the unpaved bit.
Thanks Johann.
For the keyword I would use mkgamp:unpaved, as some others has suggested too. In my opinion most if not all tags used by mkgmap should start with this prefix and should be translated in the style file.
I agree. Therefore, I propose that we use:
mkgmap:unpaved to tag ways that are "unpaved"
mkgmap:ferry to tag ways that are "ferries"
Mapping from OSM tags can be done in the style file.
Is everyone happy with that? If so, I will make the change and commit it.
I disapprove.
The trouble with the "mkgmap:unpaved=???" approach is that it duplicates existing functionality in OSM. We should strive to get the existing functionality better specified if it doesn't already do the job for us. Otherwise, mapping effort will be spent on adding a set of tags to OSM which only benefit the Garmin routable maps project. What about the TomTom people? Or the AndNav2 users? They'll want to know about routeable or unrouteable unpaved roads too.
The whole point of using a mkgmap: prefix is that it does not force a particular OSM tag to be used for a garmin gps specific purpose. When an "approved" OSM tag (is there such a thing?) has a "meaning" that coincides with a garmin gps capability (e.g. oneway) then it makes sense for mkgmap's behaviour to be controlled by the OSM blessed tag. Otherwise, it's better not to pollute the OSM tag namespace or overload the meaning of existing OSM tags.
Unrouteable unpaved roads are a real-world fact, not a 'mkgmap' feature.
I do agree though that OSM's tagging for road surfaces is a bit of a mess, but it needs an OSM-level cleanup if that's a problem, not at mkgmap-level.
AFAIK there are "surface=???" "smoothness=???" "mtb:scale=???" "sac_scale=???" "rtc_rate=???" tags in OSM, all of which (sometimes in combinations) ought to be enough to give mkgmap the clues needed to set the routeability of a given way. Plus "access=???" and "<vehicle>=no" of course.
Not just that, but those tags already exist. We should be using them. Steve
Isn't that one job of the style file, to transform the OSMish tags into garmin specific tags? Cheers, Mark PS - I do now wonder if the carpool tag should be changed to mkgmap:carpool?
Mark Burton wrote:
The trouble with the "mkgmap:unpaved=???" approach is that it duplicates existing functionality in OSM. We should strive to get the existing functionality better specified if it doesn't already do the job for us. Otherwise, mapping effort will be spent on adding a set of tags to OSM which only benefit the Garmin routable maps project. What about the TomTom people? Or the AndNav2 users? They'll want to know about routeable or unrouteable unpaved roads too.
The whole point of using a mkgmap: prefix is that it does not force a particular OSM tag to be used for a garmin gps specific purpose.
But this isn't Garmin-specific. It's the choice of whether a way should be considered "routeable" or not. That's useful info for all the autoroute programs and GPS navigators. Steve
On 12/09/2009 12:48 PM, Steve Hosgood wrote:
But this isn't Garmin-specific. It's the choice of whether a way should be considered "routeable" or not. That's useful info for all the autoroute programs and GPS navigators.
I think it is even end-user specific. Someone who makes a Garmin map for car use might find "unroutable" is everything that is gravel. Someone with a mountainbike map might think that gravel is just fine, but other properties of ways/tracks/paths should be avoided. There is no need to dictate the OSM people what I want for my map.
Hi, I'm not sure I understand the mkgmap:tag stuff after all. The "mkgmap:ferry" is an internal mkgmap tag, isn't it? I.e. it's a sort of intermediate tag, meaning the OSM input map should *never* have the mkgmap:whatever tags present? As far as I read Steve Hosgood's remarks, it looks like anyone could be tempted into adding mkgmap:ferry tags to OSM, but that sounds at least a bit odd to me. Or don't I understand Steve's remarks here? Best regards, Valentijn
On 12/09/2009 12:57 PM, Valentijn Sessink wrote:
The "mkgmap:ferry" is an internal mkgmap tag, isn't it? I.e. it's a sort of intermediate tag, meaning the OSM input map should *never* have the mkgmap:whatever tags present?
That's how it should be done.
As far as I read Steve Hosgood's remarks, it looks like anyone could be tempted into adding mkgmap:ferry tags to OSM
No, these tags are temporary only and should not be used in the OSM database.
Hi Valentijn, Steve, Felix, all, On Wed, Dec 09, 2009 at 12:57:34PM +0100, Valentijn Sessink wrote:
Hi,
I'm not sure I understand the mkgmap:tag stuff after all.
The "mkgmap:ferry" is an internal mkgmap tag, isn't it? I.e. it's a sort of intermediate tag, meaning the OSM input map should *never* have the mkgmap:whatever tags present?
The map data on the OpenStreetMap server should never have any mkgmap: tags set. That would be like "mapping for a renderer", a practice that is frowned upon. The mkgmap: tags can be added by mkgmap itself (for example, when a style file contains { add mkgmap:whatever=whatever }) or to the *.osm input files by a custom preprocessor.
As far as I read Steve Hosgood's remarks, it looks like anyone could be tempted into adding mkgmap:ferry tags to OSM, but that sounds at least a bit odd to me. Or don't I understand Steve's remarks here?
Steve, was this just a misunderstanding? As of r1425, the mkgmap default line style adds mkgmap:unpaved and mkgmap:ferry attributes. I see that Felix (extremecarver) suggested some further attributes that indicate unpavedness. I will probably incorporate those to the default style. Best regards, Marko
Marko Mäkelä wrote:
As far as I read Steve Hosgood's remarks, it looks like anyone could be tempted into adding mkgmap:ferry tags to OSM, but that sounds at least a bit odd to me. Or don't I understand Steve's remarks here?
Steve, was this just a misunderstanding? As of r1425, the mkgmap default line style adds mkgmap:unpaved and mkgmap:ferry attributes. I see that Felix (extremecarver) suggested some further attributes that indicate unpavedness. I will probably incorporate those to the default style.
Yeah - it's a misunderstanding. Felix was quite right in an earlier post, it just took me a bit longer to catch up! I obviously have no objection to temporary tags used during the rewriting process in mkgmap's style-file handling. Steve
Hello team, On Wed, 9 Dec 2009 14:04:34 +0200 Marko Mäkelä <marko.makela@iki.fi> wrote:
Hi Valentijn, Steve, Felix, all,
On Wed, Dec 09, 2009 at 12:57:34PM +0100, Valentijn Sessink wrote:
Hi,
I'm not sure I understand the mkgmap:tag stuff after all.
The "mkgmap:ferry" is an internal mkgmap tag, isn't it? I.e. it's a sort of intermediate tag, meaning the OSM input map should *never* have the mkgmap:whatever tags present?
The map data on the OpenStreetMap server should never have any mkgmap: tags set. That would be like "mapping for a renderer", a practice that is frowned upon.
I don't see that there's anything wrong with adding mkgmap: tags to the OSM database. After all, the wiki plainly says that you can put any tag you like on a node/way/relation. I have been tagging roads that look like flare roads but are not actually flare roads with mkgmap:flare-check. This stops mkgmap whining about them. I also use mkgmap:dir-check to tag roundabout segments that would otherwise show up as having the wrong direction. The presence of those tags doesn't have any affect on how the roads are rendered/edited. The only "crime" I have committed is that I have yet to document the tags. But those test disabling tags are quite different in concept to tags like mkgmap:unpaved or mkgmap:ferry. I agree that those tags do not need to be added to OSM data. Cheers, Mark
Mark Burton <markb@ordern.com> writes:
The attached patch allows you to add either unpaved=yes/true/1 or paved=no/false/0 to a way and then it will be ignored for routing purposes when the GPS has been told to avoid unpaved roads.
Not sure if those are the best tags to use - any thoughts?
In the massgis import, there is surface=unpaved and this seems sensible. In general I would say that mkgmap as a 'renderer' should adapt to conventional tagging practice. I am not clueful on using tagwatch, but I would bet there is some paved=no. http://wiki.openstreetmap.org/wiki/Key:surface
BTW - the unpaved road line type 0x0a has nothing to do with unpavedness, it's just a routable way that gets drawn as a dashed line (default rendering).
Interesting - I had found that and wondered by this was so hard :-) There's a bit of mess in tagging and interestingly similarly in garmin-land. A road's proper label is in theory separate from paved/unpaved - I have seen roads I'd call tertiary or at least unclassified in Finger Lakes that aren't paved. So I wonder if two rules that map unpaved surface (however tagged) ==> set unpaved bit in Table C together with unpaved surface and roadtype is less than secondary -> use 0x0a so the routing restrictions always work, and so the user can see unpaved roads. Perhaps in the glorious future when we have a standard TYP file we can have unpavd versions of the various roads. I suspect there are a lot of places in the world where there are roads that you'd call primary or certainly secondary that are unpaved.
participants (10)
-
charlie＠cferrero.net -
Chris-Hein Lunkhusen -
Felix Hartmann -
Greg Troxel -
Johann Gail -
Mark Burton -
Marko Mäkelä -
Ralf Kleineisel -
Steve Hosgood -
Valentijn Sessink