[Talk-us] State ref tags on ways

Tue Mar 11 22:33:19 UTC 2014

We currently contract with 12 state DOTs that include and are spread
between CA and ME, and have in the past 10 years contracted with over 20
states that are spread from (and include) AK and FL, in respect of 511
information systems.  All of them accept the consistent use of *2-letter
ISO codes *for naming their state (non-US and Interstate) routes. The
2-letter codes are part of 2+2-character ISO codes from ISO standard 3166-1
or 3166-2. The identical 2-letter codes are also an ANSI standard INCITS
38:2009.  Finally, the same 2-letter codes are used by the United States
Postal Service and are well known to most Americans who still send letters
and parcels.  Only the US Coastguard uses different codes, and not many
people have ever heard of them.

If you label routes as "SH" or "SR" or "TH" (i.e. Truck Highway) then you
create duplicate routes in adjacent states.  Occasionally states number
state routes consistently across state lines, but mostly they do not. So
"SR nn" is ambiguous on regional maps. This is a potentially big problem
for info systems and navigation systems.  If we send out an alert for "SH
20" over a national or regional channel, we can spread disinformation very
easily.  So please don't imagine that OSM is just about map rendering.  We
live in an age of electronics, texts, tweets, emails, etc., and not just
colored images of maps on paper or screens.  PLEASE can't we use the
official ISO and ANSI codes rather than following sloppy, ambiguous local
customs?

If we follow local habits, CA residents refer to "Route 5" rather than I-5,
"Route 50" rather than US 50, and "Route 99" rather than CA 99.  But our
customer in Sacramento (who has worked for Caltrans for many years) does
not advocate dumping "I " or "US" or "CA" prefixes, which make each route
unique.

I can make an analogy with people's use of "St."  We don't accept "St." in
OSM even though it's used by almost everyone because it's sloppy and
ambiguous.  Does St. Paul have a St. Paul St.?  I don't know, but if it did
we would write it unambiguously in OSM as Saint Paul Street.  PLEASE do not
use ambiguous naming of state highways then!  Find all the SH and SR s etc
and make them unambiguous.  Please?

I have no idea why the convention of leaving out half the ref in the
relation has been adopted. Just writing "5" instead of "I 5" is in my view
pointlessly inconsistent.  Most states have an "SH 5".  Why create
relations that are fundamentally confusing because of laziness?  Can anyone
tell me a reason why ref contains a different value at the way and relation
levels?  PLEASE state writing refs properly in relations, too.  Properly in
this sense means uniquely. "I 5" not "5".

CR and CH s are troubling.  Minnesota has numerous CH 1 s or CR 1 s.  So do
most states.  So whether we write CR 1, CH 1, or 1 it won't be unique even
in the state, let alone between states.  I do not have a unique solution to
propose. Fortunately most regional traffic events happen on state routes
(e.g., CA, US, I ) and most CR events are of local interest only.  But I
would request that we use a consistent labeling for CR s, for which I would
propose "CR n" so at least we know it's not a state route.

I guess I feel strongly about this ...  :)

Peter Davies
Castle Rock Associates, Portland OR
www.crc-corp.com

On Tue, Mar 11, 2014 at 11:41 AM, Richard Welty <rwelty at averillpark.net>wrote:

> On 3/11/14 3:22 PM, stevea wrote:
> >
> > Offering my two cents, I'd like to see a move towards consistency in
> > each of the fifty states.  In California, there was a move within OSM
> > to prefix County Roads with "CR " (and then the county road route ref,
> > like "G2") as well as prefixing State Routes with "SR" or "CA"
> > (federal Buck Act abbreviation for California).  This was done
> > inconsistently, and in mapnik, makes CR and CA almost
> > indistinguishable unless I squint.  Please don't make me squint, and
> > please don't needlessly lengthen ref tags, which in some cases
> > (California a good example) makes them hard to distinguish, not to
> > mention ugly, too long and just plain wrong.
> >
> > A ref tag like "G2" says all it needs to say to anybody familiar with
> > how California breaks apart its County Road system into several
> > multiple county regions, grouping these with a letter, then suffixing
> > with an integer anywhere from a few to a couple dozen routes within
> > that lettered system; there is no need to prefix with "CR " as it is
> > redundant (factually) and ugly (in my opinion).  Plus, signs say "G2"
> > or "S19" not "CR G2" or "CR S19".  I can only guess these latter
> > shields/ref tags are helpful for those "not from around here."  For
> > those who are, these are just plain wrong.
> >
> > Plus, if I see simply "9" or "17" on a mapnik shield (small circle or
> > oval), I know those to be State Routes (highways) and I don't need "CA
> > " to prefix them.  I believe it to be polite and correct for "I-5" or
> > "I-210" to appear on Interstates, even though all fifty states do not
> > have any number collisions between their state highways and (federal)
> > Interstates.
> >
> problem is that we end up inconsistent in that there are routes with
> prefixes
> and routes w/o prefixes. looking at it from the viewpoint of a data
> consumer
> which is a program, this means headaches in developing parsers. Mapnik
> doesn't
> have a problem, it just renders whatever is in the ref tag, but other data
> consumers may encounter issues.
>
> what you're really making a case for is a California specific style sheet
> for current mapnik, or for completing the shield project which would
> take care of all these issues in a pretty conclusive way. states are all
> different; in Florida where i grew up, prefixing state routes with SR is
> very natural. in NY where i live now, prefixing state routes with NY is
> something familiar to all New York residents (or at least, upstaters.)
>
> one thing that is important to remember that there are data consumers
> beyond the map displayed on www.openstreetmap.org. we say that you
> should not tag for the renderer. i suggest that this formulation is
> incorrect;
> we need to tag taking into account the vast ecosystem of renderers
> and other data consumers that exist out there. so don't tag for one
> specific renderer (aka mapnik.) tag for all of them as best as you can.
> turn relations and speed limits for routers, include POIs that mapnik
> doesn't display by default but which OsmAnd can, and so forth.
>
> richard
>
> --
> rwelty at averillpark.net
>  Averill Park Networking - GIS & IT Consulting
>  OpenStreetMap - PostgreSQL - Linux
>  Java - Web Applications - Search
>
>
>
> _______________________________________________
> Talk-us mailing list
> Talk-us at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-us/attachments/20140311/9cf64f2d/attachment-0001.html>