[Tagging] decide on a meaning for what is not documented [way: Expressway=yes/no versus new tags "dual_carriageway=yes/no", "limited_access=", "grade_separated"=?]

[Martin Koppenhoefer]

Am Do., 20. Feb. 2020 um 13:47 Uhr schrieb Joseph Eisenberg <
joseph.eisenberg at gmail.com>:

> Often it looks similar to the current highway=trunk rendering at in
> the German map style used at openstreetmap.de - and I believe
> "highway=trunk" is always for dual-carriageway "expressways" there.
>
>
yes, in Germany, but also in other countries like Italy, trunk is used for
roads which are similar to motorways, but are not legally classified as
motorways (different signs) and may or may not have access restrictions for
slower vehicles and pedestrians (expressed with the motorroad property).



> Also, a dual carriageway road might be preferred in routing when all
> else is equal.
>


if the road is oneway, but the counter direction is not served (in
proximity), it does not make a difference effectively. (This situation
sometimes occurs e.g. in mountain areas, where the tunnels and viaducts are
distant even several kilometers, so it isn't (I guess) strictly speaking a
dual carriageway). Usually for routing, highway=trunk with oneway=yes can
be treated the same, regardless of a carriageway for the other direction.



>
> > limited_access
>
> I should explain this further. In American traffic literature at
> least, we talk about whether a road has frequent access to adjacent
> properties and parking lots. Sometime this is called "controlled
> access".
>

> If there are lots of service roads entering, that will increase the
> risk of collisions and slow down traffic. Roads called "expressways"
> usually have no or very few service roads entering, so they have
> "partial access control"  and most motorways have "full access
> control" - you can only merge on to the motorway from a link
> (on-ramp).
>



I see, around here, this is implicit with highway=trunk. Whether there is
full access control, or almost full access control, is already present in
the grid information (in OSM you can see whether there are generally
accessible non-link roads that enter the highway or not, and how many of
them ).




>
>
> My understanding is that not all highway=trunk roads have full or even
> partial access control in most countries. Certainly in the United
> States this varies greatly.
>


not sure about many countries, I was only aware of the UK where trunk had a
different meaning than "in the rest of the world", but you could be right
that the situations that I know are actually the exception, I have not
checked it.




> > replacing "expressway" with "trunk"
>
> Do you mean retagging all ways with key:expressway as highway=trunk?
>


yes, if they aren't motorways.



>
> That would be treating highway=trunk in the German way, as a property
> which combines a number of characteristics.



"expressway" is also combining a number of characteristics, from what I
thought, the same, no?



> But in Alaska, Oregon,
> California etc, many mappers prefer to use highway=trunk for the top
> level of intercity roads which are not motorways, without considering
> number of lanes, access control, etc



That's where we use "primary" around here. There is still plenty of
hierarchy with secondary, tertiary, unclassified, so that it wasn't
perceived as a problem so far. My guess is that the reason is that
rendering rules are optimized for European situation, so in less
dense/vaster areas, the zoom level when primary is displayed, is too late,
and trunk was chosen because it rendered earlier.



> - in remote forest areas even the
> busiest road does not need grade separations.

And also, expressway=*
> is used differently in some States, as mentioned on the wiki page:
> sometimes it is about limited access, other times it's about grade
> separation.
>


this is something that should be worked on, having the same tag with
different meaning is generally a problem.

Cheers
Martin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20200220/b2fc8b33/attachment.htm>