[Talk-us] Route Tagging Consensus

[Phil! Gold]

By far the most discussed topics concerned the tagging of numbered
routes.  The discussion split into a couple of different subtopics.


== How to designate routes ==

First was just how route information should be represented.  Almost
everyone agreed on two things: that route shields should be rendered with
network-appropriate shield shapes, not the textual prefixes we have now;
and route relations are the best source of route information.  (NE2 was
the sole dissenter on the last point; he feels that route relations are
too easily broken.  I counted at least Ian Dees, Peter Budny, Anthony,
Paul Johnson, and myself as explicitly voicing support for the use of
route relations.  Anthony went so far as to advocate removing ref= tags on
the roads themselves, though no one else agreed with that and Alex Mauer
argued with him quite vociferously.)

For the ref= tags on ways, Val Kartchner offered the opinion that the tags
should be unambiguously machine parseable, suggesting something like
"US:UT:SR-67".  NE2 seems okay with "I " and "US " prefixes for
Interstates and US Highways, respectively, but suggested no prefix for
state roads and one of "CR ", "CH ", or "CTH " for county roads.  Several
people (Ian Dees and Richard Welty, at least) wanted separate network= and
ref= tags, where ref= only contains the route number and network= works
like the network= tag on route relations.  I don't think I saw a
description of how to handle ref= and network= tags on roads that are
members of multiple routes.  Finally, Craig Hinners suggests having a
separate tag for each network, so US 10 would be tagged
network:country[US]:unitedStatesHighway=10.  (Ian Dees and Val Kartchner
were very opposed to this suggestion, arguing (broadly) that it makes
things harder to deal with.)

Ian Dees also mentioned that he and Lars Ahlzen have been working on
rendering road shields from route relations with Mapnik.

It seems that most people agree that we should be rendering
network-appropriate shields from route relations, and some people are
actively working on that.  In the meantime, I think we should have some
sort of standard for ref= tags and the rendering we have now (or can
easily implement, in contrast to the 100% solution).  There seem to be a
few different options for a consistent, nationwide standard that will fit
in with current European tag usage:

 * "I ", "US ", two-letter state abbreviation, and something for county
   roads (see next section for counties) as prefixes for the route number
   in the ref= tag.  Multiple routes separated by semicolons.
   e.g. 'I 95', 'US 10', 'UT 67'

 * "I ", "US ", "SR ", and something for counties as prefixes for the
   route number in the ref= tag.  Multiple routes separated by semicolons.
   e.g. 'I 95', 'US 10', 'SR 67'

 * "I ", "US ", and something for counties as prefixes for the route
   number in the ref= tag, where state routes don't have a prefix.
   Multiple routes separated by semicolons.
   e.g. 'I 95', 'US 10', '67'

 * Use the textual reference format generally used in the state that
   contains the road to be tagged, preferably as standardized by state
   governments.  This would be "I-nn" for Interstates, except in Texas,
   which would be "IH nn"; "US nn" for US Highways in most states, and the
   state's preferred prefix for state routes (usually either the
   two-letter postal abbreviation or "SR").

 * Only the route number in the ref= tag, and network information in a
   network= tag.  I'm not sure how multiple routes would be represented.
   e.g "ref=95 network=US:I", "ref=10 network=US:US",
   "ref=67 network=US:UT"

 * Separate tags for each network, with the values being the route
   numbers.  Multiple routes in the same network separated by semicolons.
   e.g. "network:country[US]:interstate=95",
   "network:country[US]:unitedStatesHighway=10",
   "network:country[US]:state[UT]=67"

 * Alternately, as above but with appreviated names.
   e.g. "network:US:I=95", "network:US:US=10", "network:US:UT=67".

Keeping in mind that this is a stopgap approach to give us something until
we have proper shield rendering, how much support (or opposition) is there
for each of the options listed above?


== Hyphens ==

Only Val Kartchner offered an opinion on hyphen use, and that was to use
them on Interstates, since that's how they're otherwise written.

Are their objections to changing the wiki to use hyphens for Interstate
ref= tags while continuing to use spaces for other prefixes (assuming we
don't switch to a separate tagging approach entirely)?


== County Prefixes ==

There are two questions here: what sort of prefixes to use in the
prefix-based ref= tagging schemes above, and how to represent county roads
in route relations.

On the question of what to put in way ref= tags, NE2 suggested "CTH" or
possibly "CR" or "CH".  Alex Mauer liked "CTH" because it can't be
confused with a state abbreviation.  Ian Dees suggested "US:ST:CO", where
"ST" is the two-character state abbr

Re: [Talk-us] Route Tagging Consensus

[Ian Dees]

On Sun, Oct 24, 2010 at 6:03 PM, Phil! Gold  wrote:

> Since there's more agreement around the "US:ST:County" approach, are there
> objections to just documenting that in the wiki?


I disagree that there is agreement about this approach. As I've mentioned a
couple times, we need to have at least two tags to store this kind of
information rather than shoving everything into the ref=* or network=* tag.
Essentially it boils down to one issue: I don't want to write a string
parser to figure out what kind of shield to render on the route. To solve
the problem I need a tag to specify if it's a interstate, US route, state
road, or county road. I view this kind of tag along the same lines as the
highway=* tag. I don't know what to call it, but values would be interstate,
us_route, state_route, county_route, etc. The specific information about
what county/state it's in, the human readable name, the prefix, etc. should
all be stored in different tags (and not stuffed into one long network=*
tag).
___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Route Tagging Consensus

[Zeke Farwell]

On Sun, Oct 24, 2010 at 9:37 PM, Ian Dees  wrote:

> I don't know what to call it, but values would be interstate, us_route,
> state_route, county_route, etc. The specific information about what
> county/state it's in, the human readable name, the prefix, etc. should all
> be stored in different tags (and not stuffed into one long network=* tag).
>


This sounds like a great use for the network tag to me.  There are basically
4 highway networks in this country:  Interstate, US, State, and County.  I
know that technically each state and county has it's own separate network,
but most renderers are just going to display generic shields for state &
county.  For those who do want to render different shields for each state
and/or county routes why not use sub tags as we commonly do for many other
osm features:

For Michigan route 12:
ref=12
network=state
state=michigan

For Bennington County route 16 in Vermont:
ref=16
network=county
state=vermont
county=bennington


Zeke
___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Route Tagging Consensus

[Andrew S. J. Sawyer]

I like Zeke's approach.

Andrew


On 10/25/2010, Zeke Farwell  wrote:
> On Sun, Oct 24, 2010 at 9:37 PM, Ian Dees  wrote:
>
>> I don't know what to call it, but values would be interstate, us_route,
>> state_route, county_route, etc. The specific information about what
>> county/state it's in, the human readable name, the prefix, etc. should all
>> be stored in different tags (and not stuffed into one long network=* tag).
>>
>
>
> This sounds like a great use for the network tag to me.  There are basically
> 4 highway networks in this country:  Interstate, US, State, and County.  I
> know that technically each state and county has it's own separate network,
> but most renderers are just going to display generic shields for state &
> county.  For those who do want to render different shields for each state
> and/or county routes why not use sub tags as we commonly do for many other
> osm features:
>
> For Michigan route 12:
> ref=12
> network=state
> state=michigan
>
> For Bennington County route 16 in Vermont:
> ref=16
> network=county
> state=vermont
> county=bennington
>
>
> Zeke
>

___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Route Tagging Consensus

[Phil! Gold]

* Zeke Farwell  [2010-10-25 09:43 -0400]:
> For those who do want to render different shields for each state and/or
> county routes why not use sub tags as we commonly do for many other
> osm features

Ian has suggested the established is_in= tag for this purpose, and Alex
Mauer has suggested a relation that contains all the routes for a (state
or lower) network.

Personally, of those two, I think I prefer is_in=.

> For Michigan route 12:
> ref=12
> network=state
> state=michigan

Keep in mind that any tagging we do needs to be compatible with global
usage, and network= is already in use.  I'd suggest something along the
lines of "US:State" and "US:County" to fit in with "US:I" and "US:US".
(And also to continue keeping our own namespace for values.)

-- 
...computer contrarian of the first order... / http://aperiodic.net/phil/
PGP: 026A27F2  print: D200 5BDB FC4B B24A 9248  9F7A 4322 2D22 026A 27F2
--- --
  "Quick, you must come with me," she said.  You're in great danger!"
  "Why?"
  "Because I will kill you if you don't."
   -- _Sourcery_, Terry Pratchett
 --- --

___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Route Tagging Consensus

[Andrew S. J. Sawyer]

I also agree with Phil. The operative tag is the "network" tag. Which
should refer to either country, state, county as found in the "is_in"
tags, without having to have a "new" tag. I think this is the way to
go.

Andrew

On 10/25/2010, Phil! Gold  wrote:
> * Zeke Farwell  [2010-10-25 09:43 -0400]:
>> For those who do want to render different shields for each state and/or
>> county routes why not use sub tags as we commonly do for many other
>> osm features
>
> Ian has suggested the established is_in= tag for this purpose, and Alex
> Mauer has suggested a relation that contains all the routes for a (state
> or lower) network.
>
> Personally, of those two, I think I prefer is_in=.
>
>> For Michigan route 12:
>> ref=12
>> network=state
>> state=michigan
>
> Keep in mind that any tagging we do needs to be compatible with global
> usage, and network= is already in use.  I'd suggest something along the
> lines of "US:State" and "US:County" to fit in with "US:I" and "US:US".
> (And also to continue keeping our own namespace for values.)
>
> --
> ...computer contrarian of the first order... / http://aperiodic.net/phil/
> PGP: 026A27F2  print: D200 5BDB FC4B B24A 9248  9F7A 4322 2D22 026A 27F2
> --- --
>   "Quick, you must come with me," she said.  You're in great danger!"
>   "Why?"
>   "Because I will kill you if you don't."
>-- _Sourcery_, Terry Pratchett
>  --- --
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-us
>

___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Route Tagging Consensus

[Leroy E Leonard]

Are we talking a single "is_in" tag, which will bring back the string
parsing problem, or multiple tags like "is_in:state" and "is_in:county"?

 -- Lee

On Mon, Oct 25, 2010 at 11:22 AM, Andrew S. J. Sawyer wrote:

> I also agree with Phil. The operative tag is the "network" tag. Which
> should refer to either country, state, county as found in the "is_in"
> tags, without having to have a "new" tag. I think this is the way to
> go.
>
> Andrew
>
> On 10/25/2010, Phil! Gold  wrote:
> > * Zeke Farwell  [2010-10-25 09:43 -0400]:
> >> For those who do want to render different shields for each state and/or
> >> county routes why not use sub tags as we commonly do for many other
> >> osm features
> >
> > Ian has suggested the established is_in= tag for this purpose, and Alex
> > Mauer has suggested a relation that contains all the routes for a (state
> > or lower) network.
> >
> > Personally, of those two, I think I prefer is_in=.
> >
> >> For Michigan route 12:
> >> ref=12
> >> network=state
> >> state=michigan
> >
> > Keep in mind that any tagging we do needs to be compatible with global
> > usage, and network= is already in use.  I'd suggest something along the
> > lines of "US:State" and "US:County" to fit in with "US:I" and "US:US".
> > (And also to continue keeping our own namespace for values.)
> >
> > --
> > ...computer contrarian of the first order... /
> http://aperiodic.net/phil/
> > PGP: 026A27F2  print: D200 5BDB FC4B B24A 9248  9F7A 4322 2D22 026A 27F2
> > --- --
> >   "Quick, you must come with me," she said.  You're in great danger!"
> >   "Why?"
> >   "Because I will kill you if you don't."
> >-- _Sourcery_, Terry Pratchett
> >  --- --
> >
> > ___
> > Talk-us mailing list
> > Talk-us@openstreetmap.org
> > http://lists.openstreetmap.org/listinfo/talk-us
> >
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-us
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Route Tagging Consensus

[Ian Dees]

Multiple is_in=* tags. I think this is the consensus for the rest of the
world (at least I've seen it on a few other geometries around the world).

On Mon, Oct 25, 2010 at 9:14 AM, Leroy E Leonard wrote:

> Are we talking a single "is_in" tag, which will bring back the string
> parsing problem, or multiple tags like "is_in:state" and "is_in:county"?
>
>  -- Lee
>
>
> On Mon, Oct 25, 2010 at 11:22 AM, Andrew S. J. Sawyer 
> wrote:
>
>> I also agree with Phil. The operative tag is the "network" tag. Which
>> should refer to either country, state, county as found in the "is_in"
>> tags, without having to have a "new" tag. I think this is the way to
>> go.
>>
>> Andrew
>>
>> On 10/25/2010, Phil! Gold  wrote:
>> > * Zeke Farwell  [2010-10-25 09:43 -0400]:
>> >> For those who do want to render different shields for each state and/or
>> >> county routes why not use sub tags as we commonly do for many other
>> >> osm features
>> >
>> > Ian has suggested the established is_in= tag for this purpose, and Alex
>> > Mauer has suggested a relation that contains all the routes for a (state
>> > or lower) network.
>> >
>> > Personally, of those two, I think I prefer is_in=.
>> >
>> >> For Michigan route 12:
>> >> ref=12
>> >> network=state
>> >> state=michigan
>> >
>> > Keep in mind that any tagging we do needs to be compatible with global
>> > usage, and network= is already in use.  I'd suggest something along the
>> > lines of "US:State" and "US:County" to fit in with "US:I" and "US:US".
>> > (And also to continue keeping our own namespace for values.)
>> >
>> > --
>> > ...computer contrarian of the first order... /
>> http://aperiodic.net/phil/
>> > PGP: 026A27F2  print: D200 5BDB FC4B B24A 9248  9F7A 4322 2D22 026A 27F2
>> > --- --
>> >   "Quick, you must come with me," she said.  You're in great danger!"
>> >   "Why?"
>> >   "Because I will kill you if you don't."
>> >-- _Sourcery_, Terry Pratchett
>> >  --- --
>> >
>> > ___
>> > Talk-us mailing list
>> > Talk-us@openstreetmap.org
>> > http://lists.openstreetmap.org/listinfo/talk-us
>> >
>>
>> ___
>> Talk-us mailing list
>> Talk-us@openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/talk-us
>>
>
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-us
>
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Route Tagging Consensus

[Nathan Edgars II]

On Sun, Oct 24, 2010 at 9:03 PM, Phil! Gold  wrote:
> First was just how route information should be represented.  Almost
> everyone agreed on two things: that route shields should be rendered with
> network-appropriate shield shapes, not the textual prefixes we have now;
> and route relations are the best source of route information.  (NE2 was
> the sole dissenter on the last point; he feels that route relations are
> too easily broken.)

My main point was that relations should not be the sole source; refs
on ways should be kept for redundancy. But I have no objection to
relations being the primary source for the renderers.

___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Route Tagging Consensus

[Mike N.]

> Multiple is_in=* tags.

   How is this different from the normal argument that is_in is obsolete 
because the object is contained within an admin boundary and the applicable 
is_in can be derived during a geo-query?
___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Route Tagging Consensus

[Emilie Laffray]

On 25 October 2010 12:49, Mike N.  wrote:

>  > Multiple is_in=* tags.
>
>How is this different from the normal argument that is_in is obsolete
> because the object is contained within an admin boundary and the applicable
> is_in can be derived during a geo-query?
>

+1
If a polygon exists, the is_in information can be inferred easily through a
small preprocessing.

Emily Laffray
___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Route Tagging Consensus

[Nathan Edgars II]

is_in doesn't work; part of New York State Route 17 is in Pennsylvania.

___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Route Tagging Consensus

[Richard Welty]

On 10/25/10 2:58 PM, Emilie Laffray wrote:



On 25 October 2010 12:49, Mike N. > wrote:


> Multiple is_in=* tags.

   How is this different from the normal argument that is_in is
obsolete because the object is contained within an admin boundary
and the applicable is_in can be derived during a geo-query?


+1
If a polygon exists, the is_in information can be inferred easily 
through a small preprocessing.

it's not small preprocessing if you're trying to do some bulk operation.

computing geometric intersections/containment is no big deal for small
data sets, but scales damn poorly.

richard

___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Route Tagging Consensus

[Andrew S. J. Sawyer]

What about using "network:country" "network:state" etc for routes and
the example of the NY route running into PA would be solved. If you
wanted an "is_in" tag that route would have to be split into two
relations.

Andrew


On 10/25/2010, Nathan Edgars II  wrote:
> is_in doesn't work; part of New York State Route 17 is in Pennsylvania.
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-us
>

___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Route Tagging Consensus

[Paul Johnson]

On 10/25/2010 08:43 AM, Zeke Farwell wrote:

> For Michigan route 12:
> ref=12
> network=state
> state=michigan
> 
> For Bennington County route 16 in Vermont:
> ref=16
> network=county
> state=vermont
> county=bennington

I like it, though it should be pointed out that this is more difficult
unless we're talking about route relations.



signature.asc
Description: OpenPGP digital signature
___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Route Tagging Consensus

[Toby Murray]

On Tue, Oct 26, 2010 at 12:43 AM, Paul Johnson  wrote:
> On 10/25/2010 08:43 AM, Zeke Farwell wrote:
>
>> For Michigan route 12:
>> ref=12
>> network=state
>> state=michigan
>>
>> For Bennington County route 16 in Vermont:
>> ref=16
>> network=county
>> state=vermont
>> county=bennington
>
> I like it, though it should be pointed out that this is more difficult
> unless we're talking about route relations.

I kind of like this system as well. It is clear and easy to
understand. The only problem (as pointed out before) is that it breaks
the network tag compared to the rest of the world. Can we use it
anyway? :)

Toby

___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Route Tagging Consensus

[Peter Budny]

Toby Murray  writes:

> On Tue, Oct 26, 2010 at 12:43 AM, Paul Johnson  wrote:
>> On 10/25/2010 08:43 AM, Zeke Farwell wrote:
>>
>>> For Michigan route 12:
>>> ref=12
>>> network=state
>>> state=michigan
>>>
>>> For Bennington County route 16 in Vermont:
>>> ref=16
>>> network=county
>>> state=vermont
>>> county=bennington
>>
>> I like it, though it should be pointed out that this is more difficult
>> unless we're talking about route relations.
>
> I kind of like this system as well. It is clear and easy to
> understand. The only problem (as pointed out before) is that it breaks
> the network tag compared to the rest of the world. Can we use it
> anyway? :)

What about making it "network=US:state" or "network=US:county"?  That
way it's easy to tell US states apart from states in other countries.
Does that ruin its simplicity and elegance?
-- 
Peter Budny  \
Georgia Tech  \
CS PhD student \

___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Route Tagging Consensus

[Andrew S. J. Sawyer]

Is there a reason to have the network tag with "networkUS:state:county"
instead of three separate tags for "network:country" "network:state" and
"network:county" in the case of county roads and two in the case of state,
etc. Having a "network:country=" tag will clear up any confusion in which
country the route is in.

I don't think a simple US:state:county tag will suffice as people have
complained about parsing. Such a tag would likely have to be tagged
"network:location=US:state:county" as you would have to differentiate
between interstates, highways, etc. easily. By having a network and location
tags you could know the location and type of road. Additionally this would
allow for rendering of shields or determining the type route for other
rendering differentiation purposes.

I think because other tags break out location based on country, state,
county, etc it would be wise to also do so with network tagging. There are
many counties that have the same name that are in different locations. Other
OSM users have expressed issues with relying on pre-possessing to gather
location data.

Andrew

On Tue, Oct 26, 2010 at 09:57, Peter Budny  wrote:

> Toby Murray  writes:
>
> > On Tue, Oct 26, 2010 at 12:43 AM, Paul Johnson 
> wrote:
> >> On 10/25/2010 08:43 AM, Zeke Farwell wrote:
> >>
> >>> For Michigan route 12:
> >>> ref=12
> >>> network=state
> >>> state=michigan
> >>>
> >>> For Bennington County route 16 in Vermont:
> >>> ref=16
> >>> network=county
> >>> state=vermont
> >>> county=bennington
> >>
> >> I like it, though it should be pointed out that this is more difficult
> >> unless we're talking about route relations.
> >
> > I kind of like this system as well. It is clear and easy to
> > understand. The only problem (as pointed out before) is that it breaks
> > the network tag compared to the rest of the world. Can we use it
> > anyway? :)
>
> What about making it "network=US:state" or "network=US:county"?  That
> way it's easy to tell US states apart from states in other countries.
> Does that ruin its simplicity and elegance?
> --
> Peter Budny  \
> Georgia Tech  \
> CS PhD student \
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-us
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Route Tagging Consensus

[Peter Budny]

"Andrew S. J. Sawyer"  writes:

> Is there a reason to have the network tag with "networkUS:state:county"
> instead of three separate tags for "network:country" "network:state" and
> "network:county" in the case of county roads and two in the case of state,
> etc. Having a "network:country=" tag will clear up any confusion in which
> country the route is in. 
>
> I don't think a simple US:state:county tag will suffice as people have
> complained about parsing. Such a tag would likely have to be tagged
> "network:location=US:state:county" as you would have to differentiate between
> interstates, highways, etc. easily. By having a network and location tags you
> could know the location and type of road. Additionally this would allow for
> rendering of shields or determining the type route for other
> rendering differentiation purposes.
>
> I think because other tags break out location based on country, state, county,
> etc it would be wise to also do so with network tagging. There are many
> counties that have the same name that are in different locations. Other OSM
> users have expressed issues with relying on pre-possessing to gather location
> data.

I may not have been very clear... if that's the case I apologize.

What I meant was, is there a way to include just a little more
information so that we can distinguish between, say, US states and
Mexican states.  If the tags only say "network=state" and "state=*" we
lose some information.

My proposal was to have "network=US:state" (literally, not putting the
state name there) and "state=*".

However, I think your idea may be a better one. It would give us
network=state
network:country=US
network:state=California

or
network=county
network:country=US
network:state=California
network:county=Orange

I support something like this because it gives us enough information
that we can pretty easily convert to another format (relations, or some
other tag representation) later with automated tools.  And it makes
querying easier, since you don't have to do polygon searches to figure
out whether e.g. the route it part of a US state or a Mexican state.
-- 
Peter Budny  \
Georgia Tech  \
CS PhD student \

___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Route Tagging Consensus

[Richard Weait]

It feels like we have been going around in circles on this for almost
two years.  I wrote this in March 2009.

http://weait.com/content/badges-badges

Can we reset just a bit?  Rather than jumping to an answer "The tags
shall be this!" can we look at what our ideal goals would be?  So from
a superficial viewpoint, I want highway shields to be "right", and
perhaps even to be "cool".  But what else?

Looking at the history of shields in OSM, I think Lars did Interstate
shields first in TopOSM, where he appears to use the same size shields
for 2-digit and 3-digit Interstates.[1]
http://tile1.toposm.com/ma/?zoom=12&lat=42.19384&lon=-71.85007&layers=B000

I don't recall anything else having shields until the MapQuest style.
They appear to use both the 2-digit and the wider 3-digit Interstate
shields. This is a nice improvement.
http://open.mapquest.co.uk/link/h/2-JkAgnnyn

The cartographers that made these shields work at all are to be congratulated.

Goals. My goals for shields are the following.  I'd like your help too.

0) Don't break the database with my ego.  I can be right or wrong or
somewhere in between, but I won't apply mass changes to the DB as part
of my argument.  Whatever is decided, local mappers can "fix it" by
adjusting to the consensus solution over time.

1) Fall back to the default OSM "lozenge" shields.  If tagging is
incorrect or incomplete try to do something sensible without breaking
existing renderers that might not understand real shield rendering.
For instance, the main osm style is unlikely to adopt shields. I can
accept that.  Let's not break what they currently do with the
lozenges.

2) Make it easy on mappers.  They are the ones doing the work.  Let's
keep this as simple as possible, but no simpler.  ;-)

3) Make it inclusive and extensible. The US isn't the only place with
highway shields.  Once we get this right, others will want to play as
well.

4) Once we have simple shields working for everybody, wouldn't nice
multiple-shield rendering be awesome?

Suggestions. And I have some suggestions.  Again, your suggestions are
welcome too!

First, we should call this one "undecided" for now.  We've been going
back and forth for a week (and two years) and we still aren't
universally thrilled with any of the proposed solutions.  No problem.
We don't have to solve it today.

Second, we should resist the temptation to make further suggestions
without a working example to go with it.  Yes, that will reduce the
number of participants in the discussion.  No, that isn't fair.  But
perhaps the current discussion could be better focused with a small
dose of, "and here is how I made it work." Yes, I know that tagging
for the renderer is bad. I'm not suggesting tagging for the renderer,
I'm suggesting "tag in some way that can demonstrably work."  ;-)

Can we just name the shield we see?  It would be mapping what's on the
ground.  It would be verifiable.  I don't mean name it to the point of
compulsive detail like, "2-digit Interstate Shield that is kind of
sun-bleached and has two bullet holes (lower-right) and a bit of rust
on the left."

I'm not suggesting that we describe every highway sign.  "30-ft wide
blue sign with white reflective text, 'Huntington State Park \n Next
Exit'" just seems too much.  But at some level of abstraction, to get
shields right, are we not just describing the shield?

Oh, and here is an improvement over the brutal hack I put in the old
article. This DB is not getting minutely updates.

http://weait.com:8080/map/shield.html?zoom=8&lat=43.39891&lon=-80.33629&layers=BFT

[1] Lars has US Route shields and MA, rectangular MA state road
shields as well.  Nice work.  I'm a huge fan of TopOSM.  Go see it if
you haven't had a look before.

___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Route Tagging Consensus

[Val Kartchner]

On Fri, 2010-10-29 at 23:57 -0400, Richard Weait wrote:
> It feels like we have been going around in circles on this for almost
> two years.  I wrote this in March 2009.

I concur.  Discussions here go round and round, with no decision being
reached.  They die then come up a few years later.

Sounds like a haunted house. ;-)

- Val -


___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Route Tagging Consensus

[Mike N.]

Second, we should resist the temptation to make further suggestions
without a working example to go with it.


  To be honest, that will help - I think I have been trying to follow the 
discussions, but cannot follow what the proposals are applied to and how.




___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Route Tagging Consensus

[Anthony]

On Fri, Oct 29, 2010 at 11:57 PM, Richard Weait  wrote:
> Rather than jumping to an answer "The tags
> shall be this!" can we look at what our ideal goals would be?

Sure, in this order:  Avoid ambiguity.  Avoid subjectivity.  Avoid
redundancy.  Add detail.  Try to maintain as much backward
compatibility as possible.

___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Route Tagging Consensus

[Richard Welty]

On 10/30/10 8:32 AM, Anthony wrote:

On Fri, Oct 29, 2010 at 11:57 PM, Richard Weait  wrote:

Rather than jumping to an answer "The tags
shall be this!" can we look at what our ideal goals would be?

Sure, in this order:  Avoid ambiguity.  Avoid subjectivity.  Avoid
redundancy.  Add detail.  Try to maintain as much backward
compatibility as possible.

make the lives of authors of data consumers (renderers, routers,
etc) easier rather than harder

richard


___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Route Tagging Consensus

[Anthony]

On Sat, Oct 30, 2010 at 8:42 AM, Richard Welty  wrote:
> On 10/30/10 8:32 AM, Anthony wrote:
>>
>> On Fri, Oct 29, 2010 at 11:57 PM, Richard Weait  wrote:
>>>
>>> Rather than jumping to an answer "The tags
>>> shall be this!" can we look at what our ideal goals would be?
>>
>> Sure, in this order:  Avoid ambiguity.  Avoid subjectivity.  Avoid
>> redundancy.  Add detail.  Try to maintain as much backward
>> compatibility as possible.
>
> make the lives of authors of data consumers (renderers, routers,
> etc) easier rather than harder

Yes, that would be a good summary of my 5 goals.

___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us