[Talk-us] State ref tags on ways: Use of unique ISO/ANSI/USPS 2-letter state codes in RELATIONS as well as WAYS?

Peter Davies peter.davies at crc-corp.com
Tue Mar 11 23:04:31 UTC 2014


I thought I would make my proposal stand out a bit more by adding words to
the title.  :-O

There are some weird things, like Nebraska's state law that requires NDOR
to have a state road link to every community of a 100 people or more. I've
changed some "Link 80F" ref tags to "NE 80F Link" and "Spur nnX" tags to
"NE nnX Spur" without having time to do the whole state.

AZ has its "Loop 101" and "Loop 202" freeways for which I would advocate
refs "AZ Loop 101" and "AZ Loop 202".

Texas also has many weird qualifiers on minor state routes but as I've
never contracted there for 511 I'm not totally familiar with them.

Peter
peter.davies at crc-corp.com



On Tue, Mar 11, 2014 at 3:33 PM, Peter Davies <peter.davies at crc-corp.com>wrote:

> 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/8468ec3e/attachment.html>


More information about the Talk-us mailing list