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 #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 #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 #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.

[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 #371 (comment):

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 #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 #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 Render bicycle=designated on highway=track #4321.
• addressing Render bicycle=designated on highway=track #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 Render bicycle=designated on highway=track #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.

[Gazer75]

The highway=track use is a mess if you ask me. It has often been used instead of the surface tag to map gravel roads.

In Norway tracktype 1 and 2 is not really in use and those get the highway=service or unclassified tag with an appropriate surface value. Tracks are mostly grade 4-5 farmland access intended for tractors and other farming equipment and should not be considered for normal car use. Would most likely require a taller 4WD vehicle.

[imagico]

The whole highway=track use is a mess talk is not really that helpful - unless the conclusion is to stop rendering highway=track completely. For tracktype we have #4322.

The problem here is:

Currently we render:

• highway=track + access=no/private with a light signature
• all other highway=track with a dark signature

Possible ways to go from here suggested so far are:

• continue doing that while solving this issue for other roads

  • would be an incomplete solution
  • should be done technically in a way that allow to be extended to highway=track easily
  • would not allow properly addressing Render bicycle=designated on highway=track #4321 as is

• treating highway=track as primary mode motorcar (i.e. rendering motorcar/motor_vehicle/access=no/private/agricultural/forestry as no and things like access=private + motorcar=yes as yes)

  • would solve this issue for highway=track
  • would be a starting point for addressing Render bicycle=designated on highway=track #4321 (by modifying the rendering in the int_access=no case depending on presence of bicycle=*/foot=*).

Further ideas for other options are welcome.

Regarding motorcar vs. motor_vehicle - that distinction is practically not really that meaningful - both in terms of tagging practice and in terms of real world access restriction on tracks. And note that in practical use motorcar=* almost always means double_tracked_motor_vehicle=* (and highway=track is by definition at least in principle suitable for a double tracked vehicle).

Keep in mind that access restrictions are about the legal status, not the technical feasibility of using a road.

[Gazer75]

The point is that the default for tracks vary depending on country. Primary use in Norway for track is agricultural, not motorcar or motor_vehicle.

[imagico]

I should probably explain the concept of primary mode of use a bit better.

This is not meant to be the primary mode of de facto use or the primary mode the road is designed for in the real world. What this is meant to reflect is the primary mode of use relevant for the target map user. The vast majority of those are not farmers, agricultural use does not apply to them. For them the relevant question is: Am i allowed to drive here with my car. And for those tracks, where this is not the case (which in many countries is a significant percentage) the interesting question is if you can go there with a bicycle or on foot (which is often the case for tracks where normal car traffic is banned) - hence #4321.

Indicating if tracks are open for agricultural/forestry traffic or not is probably something out of scope for this style.

That the default access restrictions on roads vary from country to country is known. But taking care of such differences in design is clearly out of scope for this issue. So far we do not make any per-country differentiation in rendering, despite there being systematic differences in tagging semantics, in particular for roads. This could be re-considered (in a separate issue) - thought the more pressing field of per-country styling differentiation would be labeling (#2208).

Also note that specifically w.r.t. the implicit default access restrictions on highway=track - Norway is the only country where this is actually documented to be motorcar=no on https://wiki.openstreetmap.org/wiki/OSM_tags_for_routing/Access_restrictions.

[hungerburg]

Default No for motor vehicles is also specified for Tyrol, a province of Austria. Recent efforts by a small number of people from the local community shows, that indeed, the number of tracks that are generally accessible for motorized traffic is very low. BTW. forestry tracks alone nearly double the road network in Austria. and by law, they must be signed accessible, otherwise they are forbidden.

[pnorman]

I can't see us doing rendering differently for different countries and particularly not for smaller regions.