lookup & acces=service

[EssBee59]

Hello,

I dicovered today a weekness in my profile: The tag "access=service" was not checked, and the calculated route was not usable..
But as currently the lookup value "acces=service" is not known, a change in the profile is not possible.

Is it possible to add this tag in a future version of the lookup? Regards

[EssBee59]

I checked with overpass-turbo the number of OSM objects with this tag "acces=service": Only 6 objects in the region Hesse (Germany), very very low !!!!!!! It was a misfortune to be confronted with this situation... But for a better routing, I think an extention (with low priority) of the "access=" possibilities in lookup would help

[EssBee59]

The OSM-mapper who had set "access=service" agreed to change to "access=no"... So, I close this issue yet! Regards EssBee

[EssBee59]

see above!

[poutnikl]

Hmm, but it is not the best approach to bend OSM mapping to fix routing, if access=service fits better than access=no. Perhaps better would be to consider all but explicit no access tags as access=yes ( explicitly or as a "grey zone" ). "Allowed if not forbidden" approach.

[EssBee59]

Hi Poutnikl, I agree, a precise tagging would be better as a generic yes/n0 ... but the tag "access=service" was used only once in Hesse, so I had a bad feeling to request a change for that! Anyway: If the change is possible, an extention of the lookup (and the corresponding .RD5 maps!) should be initiated. Regards EssBee

[poutnikl]

I had rather in mind the profile side of a custom profile

if access=no|other_no|yet_other_no>    
     then    <value_for_no_access>
     else    <value_for_granted_access>

so access=service would fall into But if =service should be treated as =no, then I agree, it should be included to lookups.dat and rd5 files. For built in profiles used as they are, it should be fixed on BRouter side.

[EssBee59]

Yes, a change in ALL profiles would be necessary! But as explained, also an extention of the lookup is necessary, as "access=service" is not supported yet... Yes a risk exists: -if more OSM-Mappers uses in future the full set of "access" tags (service and more...), and no change is made (in lookup AND in the profiles) the situation I encontered some days will occur again and again.

[EssBee59]

The risk described above should be discussed and a decision made for change or not to change the behaviour of brouter with the "access" tag

[polyscias]

Is it clear what access=service is (always) used for?

Without that clear I think the unknown category (i.e. not adding it to lookups.dat) is the only correct one. If it is clear adding it to another tag like access=destination/visitors, access=delivery or access=customers would make sense to me.

[EssBee59]

Hello, actually not every thing is clear for me: I had the problem last year, and as you can see with overpass-turbo, the value is used in germany:

/ This is an example Overpass query. Try it out by pressing the Run button above! You can find more examples with the Load tool. / [out:csv(::"id", "highway","access",::count)]; area[name="Deutschland"]->.a; way(area.a)[access=service]; out; out count;

Strange is, the value "service" is not proposed as "standard" value for the access tag, but it is used...

Now I have no perfect recommendation, and let you decide

[polyscias]

I had a look at for access=service in the Netherlands:

• two ways after a gate with access=private
• a pumping station that would fit access=private or no
• two ways giving access to a building where you could drive with your car but no normal person would do that. highway=pedestrian would make more sense to me

So two times no/private and one time yes but only for pedestrians it would make sense

I had the problem last year

I am not sure why you would like to add handling for access=service at all in your profile given the inconsistent meaning.

If you really like to handle this I think you better edit the OSM data and give it an appropriate documented access value. With the search done and the data reviewed I will update the 3 occurrences I found.

Doing so I found that access to that building was not clear to me and I found on Key:access access=unknown is actually defined and I decided to use that with "foot=yes"

I see that access=unknown is >3000 times mapped in Germany, do you already know how you will handle that in your profile? ;-)

[EssBee59]

I thought, "service" means "only for "service" staff (and this was in fact the case I had to face by a motorway in germany), and I intended to consider in the same way as "access=no" in my MTB profile.

But it do not seam "clear" world wide. (I do not consider "=unknown", but I had considered "=sevice" as definitly forbidden).

If I get a new routing error in future, I will inform the creator of the OSM object.

[polyscias]

Contacting the OSM author is not a bad idea but if you know the actual situation I think updating OSM yourself is an easier and faster way to do it.

If I get a new routing error in future

I am wondering, do you get this error after adding access=service handing to your profile or ??

If it is helpful for you, my scripts to help update lookups.dat also output the not supported tags per key. Based on that some tags were added but if you want to have a look also, I can share that.

[EssBee59]

I am wondering, do you get this error after adding access=service handing to your profile or ??

No, the path was tagged with access=service. As there was noway to check this value in the profile, the created route used the strictly forbidden path... (and I had to return several kilometers). Checking acces=unknown do not help really, as "unknown" is not the same as "service" or forbidden or "no"

Not really urgent, but I would be nice to have a solution

[polyscias]

Okay, such a routing error, clear! Updating OSM would also benefit others.

In this light it is good to know that all tags not known for keys in looksup.dat end up in unknown, so you could have updated the profile deny access for access=unknown.

The trekking profile is "optimistic", by not handling it access=unknown is ignored, if you better like a "pessimistic" approach it is, like said, a matter of denying access for access=unknown in your profile.