Re: [mkgmap-dev] mkgmap build greater than 3113 routes through barriers with access=no
Well, it can be dafaulted to on, but sometimes one may want to not translate node properties to ways. For example: a map may have barriers and one may want to have such as POIs in an alert file for Garmin POI Loader instead of them interfering with routing. It all depends on map purpose. 2014-08-06 8:44 GMT-03:00 Greg Troxel <gdt@ir.bbn.com>:
Paulo Carvalho <paulo.r.m.carvalho@gmail.com> writes:
Just checking: did you remember to use the --link-pois-to-ways option in your compile command? Also, did you place the barrier node apart from the way or did you format a way node as a barrier? (the latter is preferable, I think.)
As I understand it, the semantics of OSM are that a barrier node in a way does control access. So it's a bug if mkgmap by default does not produce a map that respects that. Essentially, I'm arguing that --link-pois-to-ways should default to on, following the principle that there is a correct garmin representation of OSM semantics and that this correct representation should be the default.
Paulo Carvalho <paulo.r.m.carvalho@gmail.com> writes:
Well, it can be dafaulted to on, but sometimes one may want to not translate node properties to ways. For example: a map may have barriers and one may want to have such as POIs in an alert file for Garmin POI Loader instead of them interfering with routing. It all depends on map purpose.
I can see what you mean, but there are standard semantics in the osm representation, and therefore a map which does not follow those isn't a proper representation of the osm data. I did not mean to suggest removing the option to turn it off; I was only really suggesting that it default to producing correct maps. In general I have felt that mkgmap accumulates options that one needs to give to get the right answer, and that they should all default to on. I think this is just an artifact of them being experimental for a while.
participants (2)
-
Greg Troxel -
Paulo Carvalho