[Talk-us] ref tags

Minh Nguyen mxn at 1ec5.org
Tue Feb 12 10:03:52 GMT 2013


On 2013-02-11 11:30 AM, Chris Lawrence wrote:
> I'd actually been kicking around proposing a bulk edit of ref=* tags
> to conform them with the quasi-standard of "two-letter USPS state
> prefix + space + route number (+ one-char suffix)?(+ space + any long
> modifiers)" but didn't want things to devolve into a pissing match.
> Since Mapquest seems to need ref tags to include the proper state
> shield, and this standard is valid, even if alternative styles might
> also be valid including the USPS prefix would seem to help.
> Personally I'd prefer downstream consumers like MQ just use the
> relations, like on the shield renderer at
> http://elrond.aperiodic.net/shields/ (they also can encode proper
> directional information, which would be very useful if OSRM understood
> route relations) but baby steps.
>
> The only drawback I can see is that many of the route numbers in
> Georgia would disappear from the default Mapnik style, due to GDOT's
> insistence on cosigning virtually every US-designated highway with a
> visible state designation, which would make the shields too big to
> render.  But this problem wouldn't affect most of the states where the
> bare number and "SR" plague has set in.

The "SR 123" format has been the consensus in Ohio for years. Forget 
NE2; you'll have to change the local mappers' minds first. We arrived at 
this choice not only because "US:OH 123" (the wiki's suggestion 
originally) was too long for Mapnik in most cases, but also because "SR 
123" is the predominant abbreviation format on plain-text signage 
(variable message signs, the occasional blade sign) and in writing 
(traffic reports, state documents, ODOT schematics, county engineers' 
websites, Wikipedia, etc.).

This isn't just an Ohio thing. In the Dallas/Ft. Worth area, blade signs 
at intersections with on-ramps often say "SH 123", even where the 
highway is commonly known by a name.

On 2013-02-11 12:30 PM, Chris Lawrence wrote:
 > As far as the blade sign issue goes, I expect that directions are more
 > likely to use street names rather than the ref tags for routes that
 > have both, and that the average driver is unlikely to be confused by a
 > reference to "Florida xx" or "Florida Highway xx" instead of "State
 > Road xx," even if it's not the local vernacular, especially since the
 > shield in most of these cases - Florida, Georgia, and Alabama -
 > actually looks like the state itself* (and certainly less likely to be
 > confused by "Florida xx" than "xx" - "Turn left on 46? 46 what?") -
 > after all, I don't think anyone has seriously proposed renaming the
 > ref tags on US 101 in Los Angeles as "The 101."

This a poor analogy, because "The 101" is a colloquial designation -- it 
belongs in `loc_name`. (Plus, you'd spark an edit war between Northern 
and Southern Californians over the "The".) Caltrans, on the other hand, 
tends to use "US 101" or less commonly "Hwy 101" (which would be just as 
ambiguous as the bare numbers in Florida).

I map where Ohio, Kentucky, and Indiana meet. Conforming to official and 
local usage, both Ohio and Indiana use "SR 123", while Kentucky uses "KY 
123". The usability problem here is the lack of any route shields at 
all, not the presence of dual formats.

To me, an insistence on nationwide consistency would only serve to delay 
adoption of route relations by renderers and routers. It leads data 
consumers to assume that a route network can be determined based solely 
on a prefix in `ref`. But `ref=CA 130` could be California State Route 
130, or it could be Carretera Primaria 130 de Cantabria. [1] The green 
spade shield would seem quite out of place in Spain, no? We should be 
treating the `ref` tag as human-readable, not necessarily 
machine-parsable. That's what route relations are for. Imagine if we 
still insisted on machine-readable `is_in` tags!

[1] http://osm.org/browse/way/4843509

-- 
Minh Nguyen <mxn at 1ec5.org>
Jabber: mxn at 1ec5.org; Blog: http://notes.1ec5.org/




More information about the Talk-us mailing list