Open joakimfors opened 10 years ago
I think that it is overrendering and I would implement it in separate layers (like Cyclemap).
In addition, we also should access restrictions for the car and vehicle keys.
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.
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.
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?
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.
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.
@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.
Could you be more specific what is wrong currently and should be fixed? I'm not aware of access tag problems.
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.
Reopening.
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)
Is that right?
Yes, and there are two ways to do that, either by using the same rendering, or not rendering at all.
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.
@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.
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.
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?
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.
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
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.
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
. )
It is good to see someone working on this - a few comments based on a quick read:
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.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.
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.
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?
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:
@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.
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.
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:
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.
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.
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 meanyes
I am fine with that becoming foo
and it being regarded as an unknown value.
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.
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 meanyes
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?
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.]
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
orvehicle=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.
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).
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.
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.
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 usesvehicle=yes
has 47k usesmotor_vehicle=no
has 1M usesmotor_vehicle=yes
has 360k usesmotorcar=no
has 289k usesmotorcar=yes
has 194k usesbut 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:
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.
I explicitly mentioned your pull request from back in 2014 so i am not sure what you are trying to tell us.
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.
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:
psv=yes
/bus=yes
on highway=pedestrian
) through a new design feature of colored access dashing.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.
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?
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.
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.
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.
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
: 595kfoot=yes
: 497kbicycle=yes
495kmotor_vehicle=no
165khorse=yes
: 158kaccess=agricultural
108kaccess=yes
99kmotor_vehicle=agricultural
: 97kmotor_vehicle=yes
: 93kmotor_vehicle=forestry
: 93kaccess=no
: 89kmotorcar=no
: 82kI 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:
highway=track
is the same as on roads.foot=yes
/bicycle=yes
on tracks restricted for motorized traffic - hence a need for addressing #4321.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.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.
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.
More specific access tags such as bicycle=, motor_vehicle= etc should be rendered.