[Talk-us] ref tags

Martijn van Exel m at rtijn.org
Mon Jun 17 20:03:10 UTC 2013


Hi all,

I wanted to get an opinion on the right place for 'ref' tags on numbered
routes.

>From what I understand, osm2pgsql and the downstream rendering process uses
the ref tags on the way object to render highway 'shields'.

The following example corroborates this. Consider this (long) way:

http://www.openstreetmap.org/browse/way/13649057

See how this segment has no 'shields' on the map because the way itself has
no ref tag:

http://www.openstreetmap.org/?lat=32.5419&lon=-89.4744&zoom=13&layers=M

Even though the way is part of the properly tagged relation

http://www.openstreetmap.org/browse/relation/23246

I see two issues here:

1) Information already present in the relation object being duplicated on
the way to satisfy the renderer
2) Incomplete coverage of ref information on ways

I don't think we can solve 1) in the short term. There are likely many,
many numbered route networks in the world that are poorly covered by
relations, because the renderer does not encourage it, because relations
were introduced after a lot of numbered routes were already tagged before
the arrival of relations, because the wiki is ambiguous, perhaps other
reasons.

There are perhaps a few thousand ways in the U.S. that are part of a
numbered route, yet do not have ref tags on the way. My question is: how
should we deal with these?

My proposal is to 'fill the gaps' by manually tagging these ways using the
existing conventions for route relation ref tagging ('US 98', 'I 20', 'MS
467', etc.) wherever this information can be derived from an existing route
relation. We have folks here at Telenav willing to spend some cycles on
this, but I want to see if this is a sane approach before we do anything.
-- 
Martijn van Exel
http://oegeo.wordpress.com/
http://openstreetmap.us/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-us/attachments/20130617/f277e4e7/attachment-0001.html>


More information about the Talk-us mailing list