[Talk-us] Highway Tagging Consensus to Improve OSM (and address some of 41 latitude's concerns)
val42k at gmail.com
Fri Oct 15 17:47:26 BST 2010
On Fri, 2010-10-15 at 12:08 -0400, Phil! Gold wrote:
> == "Hyphens" ==
> There's a lot of inconsistency in tagging in road's ref= tags. The main
> wiki pages (Interstate Highways, United States road tagging) specifically
> call for using spaces between the network designation and the network
> number. A lot of people still use dashes for Interstates, because thet's
> how they're commonly written (and because "I-5" is more obvious than
> "I 5", which might be read as "15").
At least here in the US, the dash is convention so it should be used in
> == "Inconsistent State Prefixes" ==
> This is another very inconsistent area. The main US wiki page (United
> States road tagging) says to use the state's two-letter postal code
> (optionally with a US: prefix). In practice, usage varies wildly,
> generally based on how individual states prefer to represent their routes:
> in states like Maryland that use their postal code, usage is pretty
> uniform; in states like Ohio that use a "SR" prefix, usage is mixed
> between local customs and the postal code standard.
> A further complication is the presence of county roads. The wiki doesn't
> mention any standard for those. From what I've seen, they mostly end up
> as "CR" or whatever the local nomenclature is.
> Should we use the postal code everywhere for nationwide consistency or
> should we use the prefixes that locals use? If we use postal codes, what
> should we do about county or town roads?
We should find some consistent way to do it such that it is easy for a
renderer to parse. Then the renderers will need to be changed to use
them. Once this is done, people will be more likely to enter them
properly since they will show up in a special way.
So, for instance, in Utah the state routes are designated (without
abbreviation) State Route 67 (for instance). This is abbreviated as
SR-67. However, a sign with this designation is not used very much.
The much more commonly used signage is "67" is the state highway shield
(a white beehive on a black background). This is how the renderers
should put it on the state highways. (Wikipedia does it this way on
I haven't seen any county road signs (on physical roads), but I've heard
the renderers will draw the number in a circle.
The standard should be something easy to parse. Perhaps, for the above
example, it would be "US:UT:SR-67". This would allow an easy way to
parse which shield to use. For instance, a made-up Canadian route would
be "CA:BC:12". The colons would designate a field, and a space or dash
would indicate a subfield. The renderer could just use all but the last
field to figure out which shield to use ("US:UT" or "CA:BC"), then use
the last subfield of the last field to draw the shield. This would work
for an instance I've seen in New Hampshire which would be "US:NH:3A".
I'm sure that there are some exceptions, to using the last subfield to
draw the shield. Let's hear about them.
> == "Semi-Colons" ==
> He shows a road that has a ref= of "I 88;56". I think it should be
> completely uncontroversial to say that each part of a
> semicolon-delimited ref should have the appropriate network
> information in it.
I agree with your solution. Again, the renderer needs to draw the
highway shields. If there is no special treatment by the renderer for
doing things in the proper way, then it is less likely that things will
be tagged correctly. I'm reminded of the truism, "What gets rewarded
- Val -
More information about the Talk-us