Render more specific access tags i.e. bicycle, motor_vehicle etc

[joakimfors]

More specific access tags such as bicycle=, motor_vehicle= etc should be rendered.

[matkoniecz]

I think that it is overrendering and I would implement it in separate layers (like Cyclemap).

[matthijsmelissen]

In addition, we also should access restrictions for the car and vehicle keys.

[matthijsmelissen]

See also https://trac.openstreetmap.org/ticket/1651 and https://trac.openstreetmap.org/ticket/3764.

[simonpoole]

I've done some more thinking about this specific can of worms and would suggest that we apply some nomalisation on import to the access tags, likely via LUA transforms. .

This naturally opens another, different can of worms, and, will, to be effective require a reimport, but that is going to be unavoidable anyway.

The alternatives: adding specific columns or using hstore seem to be overkill given that without going in to a multi-color-pattern frenzy there is no way to render the detailed individual access values anyway.

I believe doing normalisation on import is likely to be the the lightest weight way of doing this and doesn't require changes to the actual style.

Roughly this would imply mapping access, vehicle, motor_vehicle and motorcar to access some thought needs to be given to both key and value precedence.

[dieterdreist]

Am 21.03.2015 um 13:47 schrieb simonpoole notifications@github.com:

The alternatives: adding specific columns or using hstore seem to be overkill

I propose using hstore, it might be overkill for this particular problem, but there are lots of other opportunities that such a move would bring us, including support for the alternative public transport scheme, tower types, cuisine types, landuse refinements and basically all more details for objects we already render or can currently not reasonably render because of missing information.

[simonpoole]

Am 21.03.2015 um 18:06 schrieb dieterdreist:

Am 21.03.2015 um 13:47 schrieb simonpoole notifications@github.com:

The alternatives: adding specific columns or using hstore seem to be overkill

I propose using hstore,

Why do you then give us lots of reasons why we would want to avoid enabling hstore in any circumstances?

[matkoniecz]

After attempting to show this kind of data in a different map style I reached conclusion that it is not doable in a readable way, without making it primary data presented on the map.

[kocio-pl]

I also don't believe we have a space for showing such features - even such simple feature as general surface rendering is still not done (see https://github.com/gravitystorm/openstreetmap-carto/pull/2640), so i will close this ticket.

[simonpoole]

@kocio-pl I think we would all be happy if correct access tags would simply be treated the same as wrong ones, see https://github.com/gravitystorm/openstreetmap-carto/pull/371 So either don'r render them at all or all the same.

[kocio-pl]

Could you be more specific what is wrong currently and should be fixed? I'm not aware of access tag problems.

[simonpoole]

See the https://github.com/gravitystorm/openstreetmap-carto/pull/371 an oldie but goldie. To be clear that issue is not about giving every possible access combination its own rendering, which is likely hopeless, just about being consistent.

[matthijsmelissen]

Reopening.

[jeisenbe]

If I understand @simonpoole correctly, the request is to render motorcar=no, and motor_vehicle=no the same as access=no, and motorcar=destination, motor_vehicle=destination the same as access=destinaton, and so on. Is that right?

"it would seem to be sensible to render at least the most of the time correct motorcar=destination and motor_vehicle=destination the same" - from PR #371

Also see #3304, #1312 (duplicate), #1308 (might render motor_vehicle=agricultural/forestry the same as destination or private)

[simonpoole]

Is that right?

Yes, and there are two ways to do that, either by using the same rendering, or not rendering at all.

[imagico]

One possible guiding principle could be to render access restrictions w.r.t. the primary mode of transport of the road class in question.

That would mean render motorway to unclassified plus residential and service based on

access, vehicle, motor_vehicle, motorcar

with priorities according to the usual scheme with the more specific tags overriding the more general ones. Implementation could look like:

CASE
    (CASE 
      WHEN (tags->'motorcar' IN ('yes', 'designated', 'permissive', 'no', 'private', 'destination', 'customers', 'delivery')) THEN tags->'motorcar'
      WHEN (tags->'motor_vehicle' IN ('yes', 'designated', 'permissive', 'no', 'private', 'destination', 'customers', 'delivery')) THEN tags->'motor_vehicle'
      WHEN (tags->'vehicle' IN ('yes', 'designated', 'permissive', 'no', 'private', 'destination', 'customers', 'delivery')) THEN tags->'vehicle'
      ELSE tags->'access'
    END)
  WHEN 'destination' THEN 'destination'::text
  WHEN 'customers' THEN 'destination'::text
  WHEN 'delivery' THEN 'destination'::text
  WHEN 'no' THEN 'no'::text
  WHEN 'private' THEN 'no'::text
  ELSE NULL
END AS access

In this case that could be considered to be sufficiently simple and strait-forward to be intuitively understandable for the mapper.

The more difficult part is the other road types, in particular highway=track. Here the primary mode of transport is less clear and #3304 is a serious issue.

Not rendering access restrictions at all could be problematic because completely closed roads (like for example because of serious damage) would not be indicated as such on the map.

[jeisenbe]

@simonpoole - do you have the time to submit a PR which fixes this issue? I know you are busy with some other Openstreetmap projects, but the code should not be complicated.

[matkoniecz]

I would discuss first how it would work conceptually, I am not sure how to do this in way that will be either more readable or would encourage better tagging than now.

[jeisenbe]

The plan would be to only add the motorcar and motor_vehicle tags to the current access= rendering style for highway=motorway through highway=unclassified and =residential

render motorcar=no, and motor_vehicle=no the same as access=no, and motorcar=destination, motor_vehicle=destination the same as access=destinaton, and so on.

@matkoniecz would you want to see a PR testing that idea?

[Gazer75]

This needs fixing IMO. Been an issue for years where people tag access=destination + foot=yes + bicycle=yes to make it render properly. This could potentially leave out other modes of traffic. And it adds unnecessary tagging that could be just a simple motor_vehicle=destination. In Norway these are signed with the "no motor vehicles" sign: https://en.wikipedia.org/wiki/Prohibitory_traffic_sign#No_motor_vehicles with a subsign stating that it applies to through traffic. The subsign may say "gjelder gjennomkjøring" and/or "gjelder ikke buss i rute" as some examples. The latter exempts bus in service and quite often they exempt other PSV as well.

[imagico]

For info - i have shown a way to solve this and other access tag rendering issues in:

http://blog.imagico.de/rethinking-road-access-restrictions-rendering/

based essentially on the idea shown above in https://github.com/gravitystorm/openstreetmap-carto/issues/214#issuecomment-524550810

[aceman444]

This needs fixing IMO. Been an issue for years where people tag access=destination + foot=yes + bicycle=yes to make it render properly. This could potentially leave out other modes of traffic. And it adds unnecessary tagging that could be just a simple motor_vehicle=destination.

This is not just unnecessary tagging, but also wrong. If the sign only limits motor vehicles, then the tagging is overrestricting here, e.g. it also limits e.g. inline skates or other non-motor vehicle means of transport (except foot and bicycle) to 'destination only'.

I agree this issue should be fixed in some way, but these people are inputting wrong data for tagging for the renderer and should be educated.

[dch0ph]

There isn't going to be One True Solution for rendering access tagging, since there are so many tags involved, A good step forward would be an overall framework which addresses the most obvious problems with the current rendering (essentially only considering the access tag and ignoring the others).

I've worked up a solution/framework for my own Carto-derived style. It is indebted to @imagico's demonstration, but is deliberately limited to the most obvious cases as a starting point.

Examples

Above is a current Carto rendering. Below new access marking in a Carto-derived personal style (ignore the non-access related differences):

PSV access Bus only road on bridge. access=no, bicycle=yes, bus=yes, foot=yes.

The presence of bus=yes means the access=no restriction is rendered in pale blue.

Honouring motor_vehicle

Residential highway tagged with motor_vehicle=destination.

Honouring foot

North-south footway tagged with highway=footway, foot=private

More tagging normalisation

Cycleway tagged as highway=path, foot=yes, bicycle=yes

(Carto currently only accepts bicycle=designated. )

[imagico]

It is good to see someone working on this - a few comments based on a quick read:

1. the SQL code seems very cryptic to me, i could not follow its logic on a quick look. Keep in mind that being able to work with nested SQL queries is already a requirement for style developers while working with plpgsql is not. The introduction of an intermediate numerical encoding for the ternary classification of access restrictions (yes, no, light) seems unnecessarily obfuscated. The primary design goal should be the ease for the style developer to (a) understand the tag interpretation logic when reading the code and (b) make targeted adjustments to this logic as necessary. The AC-Style version is not ideal either (in particular because of the use of numbered parameters) - but it is much more strait away to read and understand i think.
2. Adding generated columns to osm2pgsql tables is a concept that would require a principal discussion. In this specific case i would also ask for evidence that this it is actually necessary to pre-compute this (i.e. that it provides a meaningful performance benefit).
3. Style specific in place manipulation of tag values in the database at import time would be a big no-no for me. Style designers should be able to expect in the database all the tags as they have been set by the mappers. If computation of additional data is required at import time that should go into additional columns with names clearly indicating they are generated data. I do not see such a necessity here (except for potentially the previous point if there is evidence for that).

I can't really comment on the styling ideas demonstrated without the larger context. Coming up with a suitable styling would be much easier if the blue/purple color issues were resolved first of course. Overloading blue further for bus infrastructure will, however, likely not work.

[dch0ph]

Keep in mind that being able to work with nested SQL queries is already a requirement for style developers while working with plpgsql is not. [...] The AC-Style version is not ideal either (in particular because of the use of numbered parameters) - but it is much more strait away to read and understand i think.

Personally I find nested SQL much harder to parse than more procedural, step-wise code. If somebody wants to re-write in terms of nested SQL, be my guest!

The introduction of an intermediate numerical encoding for the ternary classification of access restrictions (yes, no, light) seems unnecessarily obfuscated.

This is linked to finding the "most severe" access restriction out of an approximately equivalent set. I feel this is better than prioritising one tag over another (e.g. use motor_vehicle if set, then try motorcar etc.).

In this specific case i would also ask for evidence that this it is actually necessary to pre-compute this (i.e. that it provides a meaningful performance benefit).

I'm not in a position to do this. I just work on my style with regional extracts. More serious developers would be in a better position to comment.

The alternative (which would also avoid introducing PLPGSQL) is to create the column in Lua, but this is much less flexible. That said, a drawback of the generated column is that it is killed every time the database is important, so the SQL needs to be re-run. So I agree that this may not be the time for a generated column. It would be trivial to move to the column generation into the SQL queries. I just worry that we would be introducing a lot of computation every a highway is pulled from the database. Pre-computing int_access seems a no-brainer.

Style specific in place manipulation of tag values in the database at import time would be a big no-no for me. Style designers should be able to expect in the database all the tags as they have been set by the mappers. If computation of additional data is required at import time that should go into additional columns with names clearly indicating they are generated data. I do not see such a necessity here (except for potentially the previous point if there is evidence for that).

Fully agree. The int_access column does not overwrite access. I was being a bit lazy in not rewriting the MSS to refer to int_access. I've tweaked my notes to reflect this.

That said, I do think there is a useful role of "normalising" tagging in Lua on import. As nobody knows the distinction between foot=yes and foot=designated, it makes sense to merge these. The Lua file is still part of the style, and any designer who wants to distinguish the two is free to remove the normalisation.

Overloading blue further for bus infrastructure will, however, likely not work.

Yes, I agree that the blue is too close to cycleway etc.

[pnorman]

Calculating the access restrictions for various modes is pretty easy in SQL - just use COALESCE to fall through the various tags to a default. The problem has always been the cartography - which access restrictions do we use where? How do we find cartography that is clear and distinct for them?

[imagico]

This is linked to finding the "most severe" access restriction out of an approximately equivalent set. I feel this is better than prioritising one tag over another (e.g. use motor_vehicle if set, then try motorcar etc.).

This is not the consensus interpretation of access tags. If you have a road tagged:

• motor_vehicle=no
• motorcar=yes

that translates to accessible by motorcar because the more specific tag always overrides the more general tag.

As nobody knows the distinction between foot=yes and foot=designated

That is not correct. Even for things like natural=wood/landuse=forest there are plenty of regions where mapping does make a consistent distinction.

it makes sense to merge these.

That is a subjective design decision. There are mainly two reasons why you might want to implement design decisions at import rather than at render time:

• a personal preference for procedural programming in LUA compared to functional programming in SQL - that is entirely subjective.
• a desire to impose the design decisions on others - like derivative styles that want to use the same database schema as OSM-Carto or other OSM-Carto designers for whom the hurdle to do a different tag interpretation would be substantially raised. IMO that is incompatible with our goals.

@pnorman - i consider this issue to be primarily about changing tag interpretation to display the de facto restrictions for the primary mode of transport rather than merely looking at access=*, i.e. looking at vehicle=*/motor_vehicle=*/motorcar=* for roads, bicycle=* for cycleways etc. That does not require any modifications in map design, we could keep the current yes/no/destination classification.

An additional idea would be to visualize cases of restricted, except for ... in a dedicated form. Like roads being restricted except for bicycles or except for buses. That would require new design concepts. But this can be looked at independently from the first part.

[simonpoole]

The problem has always been the cartography

I would beg to differ, that has never been the issue. Even the current two variants could be condensed in to one that simply indicates that there is a use/access restriction on the way. While that wouldn't be perfect, nobody has asked for perfection, just for something that is better than the decade plus rendering that gets it totally wrong, and that would be a better by a couple of order of magnitude.

[imagico]

just use COALESCE to fall through the various tags to a default.

To be clear: A simple COALESCE is not going to work because we need to ignore invalid values:

• access=yes + motorcar=foo would need to mean yes
• access=no + motorcar=foo would need to mean no

because foo is an invalid access value and means neither yes nor no.

You could still use COALESCE but would need a construction like we use for the feature columns:

https://github.com/gravitystorm/openstreetmap-carto/blob/9fc6ed454169555b7b2f8a2ee4cc40d5ba67bffd/project.mml#L1559-L1623

[dch0ph]

I would beg to differ, that has never been the issue. Even the current two variants could be condensed in to one that simply indicates that there is a use/access restriction on the way.

Yes, this is what I have been aiming at. We can't possibly illustrate the nuances of access tagging in a general purpose map. It would be very useful to have a overlay / JOSM paint style that showed access tagging in all its glory. The only viable approach that I've seen is @imagico's "display the de facto restrictions for the primary mode of transport".

This is not the consensus interpretation of access tags. If you have a road tagged:

motor_vehicle=no motorcar=yes that translates to accessible by motorcar because the more specific tag always overrides the more general tag.

I think we have to distinguish between the full interpretation of the tags (as above) and what we show on the map to indicate that there is some sort of access restriction. I would argue (with Simon) that the most appropriate thing to show in this example would be an access=no rendering to show that there is some "no-like restriction". This is what lead me to the "maximum severity" approach as an even-handed way to consider multiple tags.

That is not correct. Even for things like natural=wood/landuse=forest there are plenty of regions where mapping does make a consistent distinction.

OK, perhaps this is region-specific thing. My threshold for normalising tagging to simplify rendering is lower as I'm working with data extracts. I've removed the designated > yes merger. This leaves the dissolution of highway=path in Lua, but again, this is only out of antipathy for path and to reduce the volume of XML generated. It would be easy enough to retain highway=path and use the path_type approach of imagico's demonstration.

I should point out that the "promotion" of say highway=path + horse=designated|yes is not how Carto currently works and does need discussion too.

[imagico]

So far the only concrete suggestion of how to interpret more specific access tags has been to indicate the de facto restriction for the primary mode of transport for the road class in question. If you want to suggest a different interpretation please explain it and the reasoning behind it.

If your suggestion means to interpret access=no + motorcar=yes as no on roads - what would be the reasoning behind that interpretation? Since such roads exist in substantial numbers in many countries (usually also with motorcycle=yes of course) you'd nudge mappers to instead tag foot=no + bicycle=no + moped=no + mofa=no + horse=no + carriage=no + anything else that is not a motorcar/motorcycle if they want to avoid the road being shown as not usable. What would be the justification for that?

I should point out that the "promotion" of say highway=path + horse=designated|yes is not how Carto currently works and does need discussion too.

The current treatment of highway=path (that highway=path alone is shown as footway while highway=path + foot=designated + bicycle=designated is shown as cycleway) is not very consistent and should be improved. But this should be done on either the SQL or MSS level IMO.

[pnorman]

To be clear: A simple COALESCE is not going to work because we need to ignore invalid values:

• access=yes + motorcar=foo would need to mean yes

I am fine with that becoming foo and it being regarded as an unknown value.

[dch0ph]

If your suggestion means to interpret access=no + motorcar=yes as no on roads - what would be the reasoning behind that interpretation?

No, I'm not saying this. There is just a subtle change to the logic of combining vehicle, motor_vehicle and motorcar. In your code:

       (CASE
        WHEN ($5 IN ('yes', 'designated', 'permissive', 'no', 'private', 'destination', 'customers', 'delivery')) THEN $5
        WHEN ($4 IN ('yes', 'designated', 'permissive', 'no', 'private', 'destination', 'customers', 'delivery')) THEN $4
        WHEN ($3 IN ('yes', 'designated', 'permissive', 'no', 'private', 'destination', 'customers', 'delivery')) THEN $3
        ELSE $2
      END)

[where $5 is motorcar, $4 is motor_vehicle, $3 is vehicle]

The access restriction marking is determined by motorcar if set to a valid value, motor_vehicle if this isn't set (to a valid value), then vehicle.

In my code, the combination is set by the most restrictive of these 3 tags. The rest of the logic is exactly the same as yours.

So access=no + motorcar = yes would (or should!) translate to int_access=yes.

motor_vehicle=no + motorcar=yes would translate to int_access=no, but would correspond to yes for your code because you prioritise motorcar.

motor_vehicle=yes + motorcar=no would also translate to int_access=no, but would correspond to no in your code.

P.S. For the avoidance of doubt, I'm not saying this is the way to do it - I would be just as happy to see your code being adopted. I just felt more comfortable with an "even handed" approach to combining the vehicle tags.

[imagico]

I see. If you special case access=* there are less practically common cases where this would lead to problematic results. The question remains: Why would you prefer such logic? Why do you consider it more even handed considering the access tags form a clear hierarchy and tag documentation explicitly mentions the possibility to override with more specific tags?

Opinions and arguments of others would be equally appreciated.

• access=yes + motorcar=foo would need to mean yes

I am fine with that becoming foo and it being regarded as an unknown value.

But that would mean access=no + motorcar=foo is interpreted as yes because the default access is yes. Is that desirable?

[dch0ph]

The question remains: Why would you prefer such logic? Why do you consider it more even handed considering the access tags form a clear hierarchy and tag documentation explicitly mentions the possibility to override with more specific tags?

As, I say, I'm not going to die on hill over the two ways of combining the motorcar, motor_vehicle, vehicle tags: PRIORITISE SPECIFIC(motorcar > motor_vehicle > vehicle) vs MOST RESTRICTIVE(motorcar, motor_vehicle, vehicle) since they only differ in a few cases, and any vaguely logical rendering is better than none.

Ultimately we are combining three tags to basically YES / NO on showing an access restriction (ignoring destination-type access). So there cannot be a scheme that "interprets" the tags to give an unambiguous result.

The presence of an "no (vehicle) access" on a road is going to be ambiguous. So it is useful to think what we would put in any legend for "no (vehicle) access". The render should be intuitive for the user.

I was unhappy with PRIORITISE SPECIFIC, since it is hard to articulate what the presence of "no (vehicle) access" marking on the final map means [EITHER motorcar is NO, or if motorcase is not set, motor_vehicle is NO, or if neither are set, vehicle is NO, or if none are set then access is NO]

I suggested "MOST RESTRICTIVE" since the legend would read "A no (vehicle) access restriction is present".

PRIORITISE SPECIFIC has the advantage of being straightforwardly expressed in nested SQL of course.

Yes, we definitely want views / some semblance of agreement, not least because how to render access restrictions is not a Carto-specific issue.

[I've removed the Lua transformations from the gist.]

[imagico]

I suggested "MOST RESTRICTIVE" since the legend would read "A no (vehicle) access restriction is present".

But would that actually be meaningful for the map user?

You could tag

• access=no + motorcar=yes + motorcycle=yes or
• vehicle=no + foot=no + horse=no + motorcar=yes + motorcycle=yes

and both would be practically identical for the vast majority of map users and both would be considered valid tagging. But - as i understand your concept - they would be shown differently in the map.

Ultimately we are combining three tags to basically YES / NO on showing an access restriction (ignoring destination-type access). So there cannot be a scheme that "interprets" the tags to give an unambiguous result.

There is if our goal is to show the usability for a specific mode of transport. That is the whole point of the hierarchical access tagging system in OSM with more specific tags overriding the more general ones.

For normal road classes the suggested primary mode of transport is the four wheeled passenger automobile.

[dch0ph]

OK. I'm convinced!

For normal road classes the suggested primary mode of transport is the four wheeled passenger automobile.

This is the key aspect. I was coming from the angle of pedestrian-oriented maps and was looking to indicate quieter roads with any vehicle restriction, and was uneasy about prioritising motorcar. If we accept that the "legend" would read "no access for motor cars", then we can indeed leverage the hierarchy of vehicle > motor_vehicle > motorcar. The differences are minor (the case of motorcar=yes, motor_vehicle=no is rather far fetched).

[Gazer75]

I don't know how things work across the world, but aren't most restrictions aimed at motorized traffic on public roads? Key is to stop silly tagging like access=no/destination + a whole bunch of overriding tags to make routing work. As I've said before, like it or not, people unfortunately tag for the renderer a lot.

Most common sign used here is https://upload.wikimedia.org/wikipedia/commons/thumb/3/32/NO_road_sign_306.1.svg/240px-NO_road_sign_306.1.svg.png with a sign below basically saying it applies for through-traffic. Often used on residential roads.

A simple motor_vehicle=destination is enough for this and ideally should also show up on the map.

[simonpoole]

The main issue is and has been for the last decade, that the conclusion that a perfect solution isn't possible serves as an argument to continue doing the totally broken thing. Instead of either not rendering the restrictions at all, or adopting the not perfect, but still an order of magnitude better alternative.

[imagico]

I don't know how things work across the world, but aren't most restrictions aimed at motorized traffic on public roads?

That depends on regional/national particularities. In Germany the motor_vehicle=no sign is probably less common than the vehicle=no sign - thought the latter frequently has exceptions (like for bicycles).

Globally

• vehicle=no has 150k uses
• vehicle=yes has 47k uses
• motor_vehicle=no has 1M uses
• motor_vehicle=yes has 360k uses
• motorcar=no has 289k uses
• motorcar=yes has 194k uses

but this is not all that meaningful (a) because of the different ways to tag the same access restrictions and the preferential interpretation of access=* by many data users (including us) leading to specific preferences in tagging and (b) because it is not uncommon to have redundant tagging of access restriction (like both vehicle=no and motor_vehicle=no or explicitly adding bicycle=yes to a highway=residential where implicitly bicycles are already allowed). What would be potentially helpful to know the prevalence of different access restrictions is an analysis of the de facto restrictions resulting from tagging. But also note the implicit restrictions on different road types differ in different parts of the world, making a consistent interpretation world wide more difficult.

A simple motor_vehicle=destination is enough for this and ideally should also show up on the map.

That would be the case for any of the strategies we are discussing here at the moment.

The main issue is and has been for the last decade, that the conclusion that a perfect solution isn't possible serves as an argument to continue doing the totally broken thing.

Emphatically no.

Back in 2014 @matthijsmelissen wrote in https://github.com/gravitystorm/openstreetmap-carto/pull/371#issuecomment-36442712:

I think it might indeed be better to have an overall strategy on this topic (semantics, rendering) rather than to make ad-hoc changes.

And this has been our approach to this issue since then. That back then we should have removed the existing access restriction rendering until a viable strategy could be found (which took about five years) is something i'd probably agree on in retrospect. But that this did not happen is owed to (a) the well known phenomenon that feature removals are much more difficult to get support for than feature additions - a general struggle we have had in community map design since the beginning and (b) the fact that we all knew that drafting and implementing such a strategy would not be rocket science (and it also turned out five years later that it indeed is not) so with all the really hard problems in road rendering (like the unpaved roads) we simply did not consider it to take so long until someone would take on this relatively minor intellectual effort.

If you are of the opinion that requesting an overall strategy to be devised is a mistake and improving things through ad hoc changes like the one you suggested in 2014 is the only viable way then i can respect that. But i also have to disagree - largely because we have tried that approach from 2017 to late 2018 here and watched it fail.

The more recent timeline of this issue is:

• 2019: first suggestion of a concrete strategy for comprehensive rendering of access restrictions, call from @jeisenbe for developing a concrete implementation.
• 2021: first implementation of that strategy (combined with other features) - AFAIK not only the first within OSM-Carto based styles but also the first comprehensive access restriction rendering within OSM map styles in general.
• 2024: suggestion of an alternative strategy + implementation sketch by @dch0ph. Discussing the merits of the different strategies and implementation aspects.

So, yes, overall we are slow - but more recent developments are promising so i see a realistic chance of this issue finally getting solved if people concentrate on constructive comments and finalizing consensus building on the overall strategy and practical implementation aspects.

[simonpoole]

LoL https://github.com/gravitystorm/openstreetmap-carto/pull/371

[imagico]

I explicitly mentioned your pull request from back in 2014 so i am not sure what you are trying to tell us.

[dch0ph]

Here is a version 2, taking into account the comments on version 1, and which, I think, is pretty much feature complete. As mentioned previously, it is essentially following @imagico's strategy/insight of a "primary mode" for a given highway type. I've renamed the functions to make this more explicit.

In visual terms, there are no changes to the examples above.

The addition of highway=pedestrian does create an extra "feature":

Here Side is a pedestrian route tagged with psv=yes. Note that, as currently, the implicit motor vehicle restriction with highway=pedestrian is not marked.

(Again ignore the overall stylistic differences)

There are a number of implementation / design choices that need to be aired:

The 3-fold division for road access marking between no marking (no restrictions), no/private access and "destination only" seems a sound one, but involves choices about how the final access tags are allocated to the 3 categories. Here I have included permit as a valid access tag under the intermediate "access restrictions apply" category, but not customers. Many service roads in car parks with customer access are tagged with access=customers, and I feel it would add a lot of unhelpful clutter to show these as access restricted.

The role of carto_path_primary_mode is to determine whether highway=path should be rendered as a footway or some other highway type. Currently Carto only "promotes" highway=path with bicycle=designated to a cycleway. In terms of the cycle-oriented front page renderers, CycleOSM doesn't seem to ever render highway=path as cycleways, while Andy Allan's Cycle Map seems to consider highway=path with any of yes|designated|permissive as a cycleway. I think if we are to promote path, then it would make sense to consider all 3 bicycle = "yes" tags. It is common to find bicycle=permissive used for bike trails / multi-user paths in forests open to the public for recreation:

Note how the named bike trail currently appears as a footway with tagging highway=path, bicycle=permissive.

Note that in this example: where a path now appears as cycleway because of a bicycle=yes tag, the bicycle=yes is almost certainly wrong (it is a public footpath, with no cycle access). Wider interpretation of access tags will help to show up these problems, consistent with the role of providing mapper feedback.

[imagico]

The SQL code looks much clearer to me now. There are some remaining specifics in access tag interpretation that would need to be discussed, but that is adjustment details. I would probably try to use this on the fly during rendering and see if this leads to an acceptable performance. Testing this is not something you need a full planet import for, it can be done with a regional extract just as well. Once we have a viable PR this is relatively easy: Test the PR and for comparison test with a dummy carto_highway_int_access()function and see if there is a substantial speedup.

I would probably not pass the hstore to the SQL functions but the individual access tags - this way the code would become independent of which tags have columns and which are in hstore and would not need to be adjusted if we change the database layout.

You currently have two changes in your draft that go beyond what has been discussed so far as addressing this issue by just modifying the tag interpretation logic. That is:

• indication of exemptions in access tags (psv=yes/bus=yes on highway=pedestrian) through a new design feature of colored access dashing.
• changing the interpretation of access tags on highway=path to adjust rendering as footway/cycleway/bridleway. You have not shown the MSS implementation for that yet, but it is clear that your sketch intends to make changes here.

Although i am - as indicated - not opposed to making further changes here i would suggest to limit the initial PR to not include either of these two changes. This would make it easier to review and to achieve consensus. It is of course prudent to see early on how highway=path interpretation can be implemented in the access tag interpretation framework so having it in the sketch is a good idea.

highway=track handling will be something that needs to be looked at. You suggest keeping those out and continuing to just interpret access=* on them. In the AC-Style i treated them like roads (i.e. motorcar as primary mode of transport) - except for also interpreting agricultural, forestry and agricultural;forestry as valid access values. I don't know if this is the best approach. But it is important to keep in mind that many highway=track with access=no/private are de facto probably either vehicle=no/private of motor_vehicle=no/private (or need a foot=yes/designated and possibly bicycle=yes/designated in addition). The whole matter should be looked at with #4321 in mind.

[dch0ph]

Although i am - as indicated - not opposed to making further changes here i would suggest to limit the initial PR to not include either of these two changes. This would make it easier to review and to achieve consensus. It is of course prudent to see early on how highway=path interpretation can be implemented in the access tag interpretation framework so having it in the sketch is a good idea.

Yes, it would make sense to break down the review into these chunks, although from the user viewpoint, we probably want to avoid multiple changes/additions of SQL functions. I'm also conscious that we would be adding a new step to the style installation (adding / updating SQL functions), and this might break things like CI testing, not to mention docker builds. Perhaps a PR to new branch?

I would probably not pass the hstore to the SQL functions but the individual access tags - this way the code would become independent of which tags have columns and which are in hstore and would not need to be adjusted if we change the database layout.

I feel the longer term direction is moving minor access tags such as foot, bicycle and horse to hstore, which would make passing hstore the cleaner route (and make changes trivial - reloading functions without even re-running carto). Postgres copes fine with added functions with different argument signatures (although it would be cleaner for any install / update scripts to DROP IF EXISTS old function signatures).

highway=track handling will be something that needs to be looked at. [...] The whole matter should be looked at with https://github.com/gravitystorm/openstreetmap-carto/issues/4321 in mind.

I don't see good useful / options for track given the current rendering. I think that the "primary mode" route gets us to the 80:20 rule and leaves the rest in the hard / messy bucket, given that the "primary mode" for most tracks are agricultural vehicles. I address this issue of foot/bicycle access over track in my own mapping by merging track and service (based on surface / tracktype) and adding right of way markings. This is a very UK-specific solution and wouldn't generalise.

Note that I interpreted agricultural / forestry as a "top level" access tag only, e.g. access=forestry, rather than say motor_vehicle=agricultural, and, in principle, they could be used on a variety of road types rather than just track?

[dch0ph]

Currently testing a potential PR for the core issue of road access on master OSMCarto. Looking good:

I was mistaken in thinking that paths were only "upgraded" to cycleways (comments above edited to correct). Bridleways can also be created in the current style sheet, although it is not so obvious what will happen if horse/bicycle are both set. A function would make this clearer.

[Gazer75]

If specific rendering of foot- and/or cycleway is considered you have to be aware of the different way these are tagged depending on country.

Norway only use the highway=path on natural formed trails, while constructed paths not signposted with blue sign get the footway value. So that means either highway=footway/cycleway depending on sign.

These foot- and cyleways can often get a motor_vehicle=destination or yes because they act as access to properties part of the way.

[dch0ph]

Thanks for the input.

I don't see any problems here. The initial PR is deliberately narrowly focussed on "correctly using mode-specific access tags" that have previously been ignored. A follow-up, to ensure more consistent use of mode-specific tags, might result in highway=path, bicycle=yes being rendered as a cycleway. This should be helpful in your context, as it would highlight paths that have potentially been mistagged.

These foot- and cyleways can often get a motor_vehicle=destination or yes because they act as access to properties part of the way.

The overall proposal will have no implications, since only the foot and bicycle access tags are considered for footway and cycleway respectively; motor_vehicle is ignored for these highway types.

The tagging is a bit curious to me; I would have expected highway=service, service=driveway, motor_vehicle=destination|private. As a result of the current PR, the service road would then be shown with the vehicle access restriction. Showing that this road was accessible for bicycle or foot traffic would be a possible extension (as imagico has previously demonstrated), but this isn't part of the current PR.

[imagico]

Some further comments on highway=track:

At the moment acces restrictions on highway=track exist in the following numbers (lower cutoff at 75k):

• access=private: 595k
• foot=yes: 497k
• bicycle=yes 495k
• motor_vehicle=no 165k
• horse=yes: 158k
• access=agricultural 108k
• access=yes 99k
• motor_vehicle=agricultural: 97k
• motor_vehicle=yes: 93k
• motor_vehicle=forestry: 93k
• access=no: 89k
• motorcar=no: 82k

I also looked at combinations:

tag 1	tag 2	count
foot=yes	access=private	7k
bicycle=yes	access=private	4.1k
horse=yes	access=private	1.5k
----	----	----
foot=yes	access=no	17k
bicycle=yes	access=no	12k
horse=yes	access=no	6.8k
----	----	----
foot=yes	motor_vehicle=no	75k
bicycle=yes	motor_vehicle=no	63k
horse=yes	motor_vehicle=no	29k
----	----	----
foot=yes	access=agricultural	16k
bicycle=yes	access=agricultural	19k
horse=yes	access=agricultural	2.3k
----	----	----
foot=yes	motor_vehicle=agricultural	18k
bicycle=yes	motor_vehicle=agricultural	23k
horse=yes	motor_vehicle=agricultural	5.6k
----	----	----
foot=yes	motor_vehicle=forestry	22k
bicycle=yes	motor_vehicle=forestry	21k
horse=yes	motor_vehicle=forestry	8.8k

In summary it seems quite clear that:

• the primary mode of transport mappers tag on highway=track is the same as on roads.
• there is a lot of distinct mapping for foot=yes/bicycle=yes on tracks restricted for motorized traffic - hence a need for addressing #4321.
• addressing #4321 in a comprehensive fashion will require interpreting motor_vehicle=*/motorcar=* in addition to access=*, i.e. considering cars as the primary mode of transport for tracks. That does not necessarily need to happing in the first step of solving this issue w.r.t. roads and paths, but it is needed as a prerequisite for #4321.

[Gazer75]

The tagging is a bit curious to me; I would have expected highway=service, service=driveway, motor_vehicle=destination|private. As a result of the current PR, the service road would then be shown with the vehicle access restriction. Showing that this road was accessible for bicycle or foot traffic would be a possible extension (as imagico has previously demonstrated), but this isn't part of the current PR.

Bit off topic, but these roads are signposted as foot and cycleway + a text sign below stating it is legal to drive to properties. A streetview link as its easiest to use as example: https://maps.app.goo.gl/BgtDFjNoZvCzpnKu9 Same spot in OSM: https://www.openstreetmap.org/#map=19/61.56180/6.43232 The service=driveway is only used for the short drive into someones house in residential areas here.

[dch0ph]

Many thanks for this careful analysis of highway=track.

It does seem that mappers are reluctant to use say access=no, foot=yes and prefer motor_vehicle=no, foot=yes. I worry that this tagging is being preferred precisely because it doesn't currently "hide" tracks that have foot access (tracks with access=no are very faint).

They also seem keen on motor_vehicle=forestry even if the Wiki implies that forestry is only a "top-level" access tag, and is not attached to specific transport modes...

Personally I would argue based on usage that the "primary mode" for tracks was "motor_vehicle" (rather than motorcar); I wouldn't want to drive an ordinary car down anything I tagged as track!

I just think track is just very difficult because (at least in the UK), there is no standardised signage, whereas vehicle, motor_vehicle and motorcar all have specific signs for roadways. This makes track a Wild West for tagging.