Users:cmuelle8/multiple way tagging on single geometry

From OpenStreetMap Wiki
Jump to navigation Jump to search

This forms some research into all current proposals (I could find on osm wiki) on how to tag physical ways/lanes/tracks alongside a main way. Since it is convenient to not enter geometry of related ways twice or even more times, we need a good concept to describe ways that are nearby another of which actually has geometry in the database. Several proposals have been made.


Consider current proposals

Proposed_features/right_left
Proposed_features/lane_and_lane_group
Proposed_features/Advanced_footway_and_cycleway
Proposed_features/Footway (obsoleted by Proposed_features/Advanced_footway_and_cycleway)
  • There is one thing that all of these proposals have in common. They want to describe multiple ways (speak: different lanes, cycleways, footways, etc.) that are too close together to have each of them drawn separately (Note: "too close" is simply not possible, you just have to zoom in more...). While it is convenient and visually appealing to not repeat drawing street furniture (extra-drawn way per sidewalk, etc.), we realize the difficulty in organizing tags in a fashion, that is human readable/editable and at the same time universal to cover special cases.
  • All of the proposals above merge information about multiple physically existing ways into the metadata of one logical osm way - this desire is brought up by the natural relation of these ways: they are seamlessly connected, follow the same course and have only minor (kerbs) if none obstacles in between them.
  • By dropping exact geographic information (this is what happens if multiple physically existing ways are represented by one logical osm way) we are left with tagging topological relation and qualitative aspects of those physically existing ways (function, state, etc.) with respect to a singe set of geometry primitives (given by the logical osm way).
  • So let's call all parts of a logical osm way lanes - this adheres to existing concepts and prevents disambiguity. Then, to be generic, we need the possibility to use almost each tag that could be used to tag a way, also for a lane. The tag option set for a lane would have to be the same as for normal osm ways, since a lane is, metadata-wise an atomic self with a shared geometry, while a normal osm way is metadata with a non-shared geometry.
  • This is why, e.g., Proposed_features/cycleway:surface is obsolete. IMHO this leads to unnecessary tag duplication, since the tags needed are already there, they are just not applicable to a lane concept (yet).
  • Let's evaluate the four proposals mentioned above that attempt to solve the multilane problem. (It should be noted, that this is eventually not the primary goal of all proposals considered here. Nonetheless they have at least some potential in doing so.)
  • right_left looses lot's of information if there is more than one lane/feature per side of street - it's impossible to tell the topological layout of a, e.g., parking lane, cycle lane and a footway to the right of a street. It practically restricts you to one feature per street side. It's a simple thing that quickly becomes messy if you try to tag more than one feature per street side. It's design suffices if the street layout is simple engough.
  • lane_and_lane_group (also: Example_01) seems to be a full-blown solution, but it's probably not the simplest thing possible. Having multiple lanes that share the same geometry brings us to using relations. Roughly explained, we create a highway=* as usual, then for every lane create a relation with the way as member. After having created a relation for every lane, we create yet another relation, a lane group. The lane group tells us, how all the lanes topologically relate to each other - i.e. which position the lanes take on the way from left (role numbers <0) to right (role numbers >0). This concept is flexible, but more difficult to implement - this solution probably adds to the code of renderers/editors/routers/etc.
  • Advanced_footway_and_cycleway tries to unify the current usage of cycleway=* and footway=* which at the moment have inconsistent value options but are semantically used in the same places - they both denote sidewalks/cycleways alongside streets. While this tag unification is a step in the right direction, the proposal also suggests using path=* and permits values left/right/both/none for each of the keys. Realizing it lacks decent topological information of more than one feature per side of street, it has the same shortcomings as right_left, a proposal it tries to harmonize with.
The more ugly thing (tm) about this proposal is the attempt to code further details of path/cycleway/footway with dots, thus repeating common tags, e.g. path.surface=* or cycleway.type=* - the latter to reflect the current use of cycleway=*.
  • footway seems to be in use already, if this could be harmonized with the values of cycleway=*, we have a quick and consistent way of describing simple street layouts, but it will not suffice for complex situations or detailed information of a lane. It should be noted that having left/right/both/none in the value field is not a good practice. It quickly let's us define that there is something to the left or right, but trying to be more specific about details will create a mess. E.g. surface=* cannot be given twice, so we would eventually have to construct something like surface=paved;left:cobblestone;right:ground - this is ugly and it's a mess to parse programmatically.

There is an upcoming proposal

  • it describes topology
  • it's easy and understandable for newbies
  • it might clutter your tag/way properties dialog ;-)
  • prefixing with rightX/leftY groups tags automagically
  • prefixing allows for using almost all tags that are used without the prefix
  • it is more or less a simple deviation from right_left
  • it does not use relations
  • imho there is more elegance in lane_and_lane_group, but the implementation is a more complex one
I tried to combine some features of different proposals by use of relations. Perhaps you'll have a look at it.
--Ömmes 21:28, 18 December 2009 (UTC)

Reversing ways issue

As I've read this many, many times: "The semantics left and right don't work well, if a mapper reverses ways." This is a non-issue, left and right can easily be exchanged by an editor if someone reverses a way and josm already provides for that since some time - try it out.

  • JOSM supports reversing all occurences of left or right if they are part of a keyname when reversing a way, it does not process occurences in valuefields (as of 2186 SVN).


Further links


Other Ideas to solve similar issues

Retrieved from "https://wiki.openstreetmap.org/w/index.php?title=Users:cmuelle8/multiple_way_tagging_on_single_geometry&oldid=611988"