Felix Hartmann <extremecarver@gmail.com> writes:

However I don't really no how we could properly handle access=private - knowing new Basecamp/GPS devices ignore all "no" settings except motorcar=no (which is actually the reason carpool seamingly works).

I think the really hard thing about access=private is that if you don't have permission (most people, presumably) you can't use it, but if you do you can, and there's no good way to tell the GPSr or any routing program what you have permission for. But, while it's probably true that for any given way most people don't have permission, it's probably also true that most people navigating to a point which has to use that way do have permission, so it seems sensible to treat access=private as access=destination.

On Wed, Aug 15, 2012 at 10:27:59PM +0200, Felix Hartmann wrote:

well to be more correct, *=destination should be handled like no.

When it comes to my commit r2314, it is. The action {delete access} is performed neither on access=no nor on access=destination (nor on access=private, for that matter). There is another rule that removes tunnels with access=no or access=private (but keeps access=destination). The idea of this is to hide various service tunnels, which could be mistaken for useable roads on the map (mostly an issue for bicycling and walking; motorists are more likely to use routing). Best regards, Marko

On Thu, Aug 16, 2012 at 10:31:41AM +0200, Minko wrote:

What about foot=permissive? If it is tagged on highway=footway (or path or cycleways), at the moment, it is blocked for walking:

The rule "add foot=yes" is not possible because it is already taken by foot=permissive. Garmin doesnt recognize foot=permissive and access=no will block everything.

Same for all other forms of vehicles (motorcar=permissive, bicycle=permissive etc)

I think that the simplest fix to this would be to ensure that the mkgmap core (which interprets the access tags after the style file processing) maps 'permissive', 'designated' and 'official' to 'yes'. Is that not already the case? I have not studied the code. Best regards, Marko

On Thu, Aug 16, 2012 at 11:08:01AM +0200, aighes wrote:

Won't it be better to leave this part completely in style-file? mkgmap just looks to mkgmap:access=yes|no and some other mkgmap:*=yes|no (which are understood) and in which case someone set one of this parameter is completely in style-file.

Advantage would be, that stlye-creator can set access, as he would like to and is not surprised/confused about changes made by mkgmap afterwards.

That advantage would still exist. What I am proposing is: (1) style file can set or delete access/motorcar/foot/bicycle/whatever tags (2) mkgmap core will map the following access tag values: no,private,destination => no, yes,permissive,official,designated = yes I am not entirely sure about the 'destination'; this is something I understood between the lines in the recent discussions. The mapping of the values in the mkgmap core would allow the style file to be simple. But, the style file could still do some mapping on its own. Here are some examples. They are not very sensible, but I hope you got the idea. I guess you would only have one of these in the style file: foot=private|foot=destination { delete foot; } foot=private|foot=destination { set foot=yes; } foot=official { set foot=no; } The mkgmap core would see the foot=* values after this mapping, so you could override the internal mapping. Marko

I prefer to move the access tag handling completely to the style file. We need to document it properly but then an mkgmap:access=no|yes could be used by each style dev to set its own rule without any tricks. The default access handling might be put into a separate file which can be included. WanMil

Of course it's possible to make some access-changes in style-file. The "problem" is, that mkgmap does something "unknown" afterwards. It would be more transparent for style-devs, if there are only 2 values (yes and no) accepted by mkgmap and Garmin.

Now I have to do something, to ignore an access-value. This is a little bit strange. ;)

Henning

Am 16.08.2012 12:01, schrieb Marko Mäkelä:

...

On Thu, Aug 16, 2012 at 11:08:01AM +0200, aighes wrote:

...

Won't it be better to leave this part completely in style-file? mkgmap just looks to mkgmap:access=yes|no and some other mkgmap:*=yes|no (which are understood) and in which case someone set one of this parameter is completely in style-file.

Advantage would be, that stlye-creator can set access, as he would like to and is not surprised/confused about changes made by mkgmap afterwards. That advantage would still exist. What I am proposing is:

(1) style file can set or delete access/motorcar/foot/bicycle/whatever tags (2) mkgmap core will map the following access tag values: no,private,destination => no, yes,permissive,official,designated = yes

I am not entirely sure about the 'destination'; this is something I understood between the lines in the recent discussions.

The mapping of the values in the mkgmap core would allow the style file to be simple.

But, the style file could still do some mapping on its own. Here are some examples. They are not very sensible, but I hope you got the idea. I guess you would only have one of these in the style file:

foot=private|foot=destination { delete foot; } foot=private|foot=destination { set foot=yes; } foot=official { set foot=no; }

The mkgmap core would see the foot=* values after this mapping, so you could override the internal mapping.

Marko _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Good question. AFAIK, in Basecamp 3 or later access=no and motorcar=no only work when carpool avoidance is active. Carpool avoidance is by default "on" in the bicycle activity, which means cycling is blocked by default on cycleways :-( bicycle=no/yes, foot=no/yes etc don't work anymore. In Mapsource and the firmware of units without activity routing this is not an issue. Marko wrote:

Now, which access modes and values does the Garmin format support?

On 22.08.2012 11:38, Chris66 wrote:

Am 15.08.2012 22:27, schrieb Felix Hartmann:

...

well to be more correct, *=destination should be handled like no. No, it's not the same. "destination" is less strict than "no".

Example:

++++++++++++++++++++++++++++ + - + - +------- - + - - + - - + - - + ----B----- + f + f +++++++++++++++++++++++++++A

+ : Main Road - : Destination Road (motorcar=destination) f : Footway (motorcar=no) A : route from B : route to

If you would replace the 'destination' by 'no', Garmin would route a car over the footway.

Chris

of course in this little example using current mkgmap strategy you're correct! ---- BUT NOT because it behaves the way it should, but because motorcar=destination is currently simply dropped!! +++++++++++++++++++++++++B + - + - + - + - + - + - +++++++++++++++++++++++++A In this example an mkgmap created map, routes happily over the motorcar=destination way. You can quickly check that motorcar=destination is not present in the map data, by having a look at it with gpsmapedit (or looking into the sourcecode of mkgmap to see, that there is no possibility to make difference between no and destination on the implementation side with keeping the way routable). (D) +++++++++++++++++++++++++B f f f - (C) - - - +++++++++++++++++++++++++A In this case, garmin shouldn't route you over at all. However it does, because motorcar=destination doesn't matter, and motorcar=no will not be respected. (C) and (D) is explained below. And that's also why the current approach, is fundamentally flawed. If you would build a map only for motorcar users, then all ways/streets where motorcars are not allowed, shouldn't be routable at all (equals true=no), while all motocar=destination should receive the "no" flag as of right now. Garmin doesn't make any separation betweeen no and destination. What for Garmin means no, is actually equal to what we in OSM consider as "destination". So what would happen if we made those ways unroutable and treat destination as no? In the first of my examples, routing would be correct. In the second of my examples, routing would either go "straight line // Garmin-Speak=direct routing" from A to B, or if the distance from - to B is shorter, it would route from A to (C), and then straight line to B. or it would route "straight line from (C) to (D) and then continue to B; this depends a bit on the device/Mapsource/Basecamp version. Now the situation is however even more difficult, as Basecamp v3.1 or higher, as well as GPS with firmwares including activity routing, only respect motorcar=no as access condition. Foot=no, bicycle=no or others are not respected anymore. Hence we create a universal map anymore, that routes legally correct for different types of transport. What we could do however, is not including any routing information for ways, with access=no/access=private without exception; while setting access=destination to do, what we currently consider as access=no. -- keep on biking and discovering new trails Felix openmtbmap.org & www.velomap.org