Proposed features/Left-right things

From OpenStreetMap Wiki
Jump to navigation Jump to search
Left/right things
Status: Abandoned (inactive)
Proposed by: *
Tagging: side=l/r

For coastlines

  • side=left means that water is on the left of the segment, and land is on the right
  • side=right means that water is on the right of the segment, and land is on the left

This will allow renderers to draw water on the outside of coastal segments

Leftright coastlines.png

Note that this value will not be automatically populated by almien coastlines

For roads

  • side=left means that you drive on the left
  • side=right means that you drive on the right

This will allow renderers to "push" lanes outwards from the centre of a road, allowing multi-carriageway roads to be displayed stylistically ("with exaggerated width").

Leftright roads.png

This would also be useful on large-scale maps, where the renderer wants to draw a motorway carriageway as central reservation, some lanes, a hard shoulder, and a fence or embankment, but the OSM data has only one segment representing the road position. To calculate road edges, it needs to know whether the segment represents the left or the right of that carriageway.

Leftright roadlabels.png

Leftright roadfurniture.png

Other things which use left and right

(note: these don't require the "side=" tag unless they're applied to dual-carriageway roads, motorways, etc.)

  • Embankments
  • Cuttings
  • Hedgerows
  • Fences
  • Abutters
  • Cycle path attached to road
  • Sidewalk
  • Towpaths attached to river or canal
  • Boundary

For canals and rivers

[Discussion moved from Proposed features/ Large Rivers]

Rivers and most canals have a water flow direction which can be represented by the direction of the segments in the linear feature. This comes for free with only a little effort is needed to make sure it done right. It makes locks (where the direction is important and missing from the current recommendation) easily represented by an additional way, probably single segment. It also allows shorthand representation of canal towpaths, which by their very nature are usually adjacent and parallel to the canal and a pain to represent as separate features. They are a resource which, if you are interested in walking or cycling, cannot be neglected.

<way id="yyyyy">
 <tag k="waterway" v="canal" />
 <tag k="towpath" v="left" />

The obvious direction is that of the water flow, but locks are conventionally represented by an arrow in the opposite direction. There may have been good reasons for this - (start at the definite mouth of a river rather than the undefinable head?) - but I think the water flow direction is more easily remembered. Chrismorl 15:00, 6 Jul 2006 (UTC)

Sounds good. Many canals have a summit level (i.e. where the direction changes from uphill to downhill), but that's easily catered for by drawing two ways. As for the lock symbol pointing uphill, it's not actually an arrow, but a representation of the mitre gates on the lock. If it pointed downhill, the current would force the gates open! --Richard 15:22, 6 Jul 2006 (UTC)

For abutters

Buildings of various types on one side only of a road could be represented compactly using the form, for example:

  • abutter_left = residential

Rendering would use the same technique as the towpath above - if I knew how to do it. Drawing a parallel line on one side only of a path in xsl/svg seems more challenging than I was expecting - but I'm a novice and may be missing the obvious. Any suggestions not using trigonometry? Chrismorl 15:01, 3 Sep 2006 (BST)

I think you are working around a fundamental problem that you have 3 pieces of data but only two places to put them: k and v. I'd guess it raise a storm of protest but a much simpler solution would be:
<way id="yyyyy">
 <tag k="highway" v="primary" />
 <tag k="abutters" side="left" v="residential" />
 <tag k="abutters" side="right" v="park" />
 <tag k="lanes" side="left" v="2" />
 <tag k="lanes" side="right" v="1" />
This might also apply to some of the other left/right issues you are looking at. Ewmjc 03:58, 19 September 2006 (BST)