[OSM-talk] The Highway tags and other junk strikes back

[guy at graviles-reynolds.org]

Quoting Ben Robbins <ben_robbins_ at hotmail.com>:

> Asuiming I hadn't made a single suggestion.  Please tell me how to tag the 
> following.
> 
> 1) A track that is a footway, and has gravel all the way a long
This is a coincident feature, since tracks are generaly bigger than footways, 
this is a highway=track with the appropriate property tags relating to the 
footway and the surface (if they exist). However do expect any detail other 
than paved/unpaved to be rendered otherwise you end up with a visual 
information overload on the rendered map. What you then get rendered is 
equivalent to what you see, a track, but the underlying detail about the 
footway and the surface is available for interpretation by navigation software.

> 2) A hedge
At present you can go not further using standard tags than adding nodes and 
segments to which you add a note tag to indicating to you self and other 
editors that the feature is a hedge. When a boundary way tag is approved then 
you create a way and tag it accordingly. The notes are not normally rendered 
but they could be in an electronic environment as popups, however they do serve 
as personal reminders and to inform others as to what the incomplete feature is 
and so prevent in advertent deletion
 
> 3) A set of 3 gates in a row, with no hedging between
Here we must take map makers licence and use our judgement. The feature that 
needs to be rendered is three adjacent ways pasing through gates. This you 
place the central way with its gate node on the GPS data, then layin the 
adjacent tracks at a spacing such that when rendered at an appropriate zoom 
level they appear as three adjacent gated ways, rather than a singe one, if 
tagging is available you could add segments between the nodes and render them 
as a boundary way. Whilst the data is not strictly 'accurate', it producess an 
approrpiate rendering, and gives navigation software the appropriate 
information about the ways.

> 4) A bridge, wich has many other featuers apon it, as in first example.

If the features are co-incident you pick the predominent feature and lay it in 
as a single way and use properties for the rest of the information (as in 1) 
above). If they are vertically above one another as in a multideck bridge you 
lay in mulitiple ways one on top of another with layer information. If they are 
adjacent you lay them in as adjacent ways and currently live with the fact that 
you will potentially have two adjacent bridges rendered rather than a single 
one. If the bridge is wider than it is long and has several ways over it then 
consider creating it as a tunnel.

> 5) A sheering pen, wich is made up of many gates, and a footway goes down 
> the center, then left, then right and up the lane. (this is a real example,
> 
> although isnt mapped)

You assess whether:
1) the feature is permanent enough to be rendered, ie will it still be there 
within the reasonable usable life of the data.
2) is the feature significant enough to warrent mapping in the context of the 
map data.
3) is it physically large enough to be mapped, and if so will it be rendered or 
will it be obliterated by other features. ie in this instance will the footway 
because it is rendered oversize for reasons of legibility, actually obliterate 
the pen. If obliteration is a possibility then one needs to consider, either 
mapping the feature oversize, mapping it a node which can either be rendered as 
an icon or as text (once such tags are approved).
6) all the aspects of the feature need to be recorded or whether you can 
simplify. In the case of the pen, we are potenitally only interested in the 
gates which interset the footpath as these are the only ones which impact on 
our progress, thus the others could be rendered as boundaries.

However if you decide to go ahead and the pen is a square, I would proceed as 
follows:

Lay in 8 nodes, one in each corner and one in the middle of each side, 
link the nodes with 8 segments, and tag the nodes in the centre of the sides as 
gates, tag the feature with a note as a reminder and to inform others that this 
is a sheering pen, and when the boundary tag is approved come back and convert 
the segments into a boundary way with the type fence. Lay in the 
highway=footway way using the requisite gate nodes where the features intersect 
and on to a node on the highway=track way repesenting the lane. The result will 
be something like:

             footpath
                |
              *-g-*
              | | |
              g | g
              | | |
              *-g-*
                |
        --------*--------- lane

Whilst the data is not strictly 'accurate' the resultant rendering will be an 
appropriate approximation, and the underlying data will be correct for any 
navigation software. At no time have I used non-standard tagging, and where 
tagging does not exist I have left notes for myself and others in the data so 
that:

1) people will know what the feature is, and will not inadvertantly delete it.
2) the data is not susceptible to automated deletion because the tags are non-
standard
3) I can come back and update the feature when appropriate tags become 
available.

Guy