On Fri, Oct 15, 2010 at 12:08 PM, Phil! Gold <phi...@pobox.com> wrote: > == "Some of OSM’s Roads Look Like State Borders" == > > He points to some areas in Iowa and Ohio where there are roads that > alternate between motorway and trunk classification. This is correct. See the states' official hgihway maps: http://www.iowadotmaps.com/msp/pdf/current/stmapmain.pdf http://www.dot.state.oh.us/maps/Pages/20072009TransMap.aspx
> Without going too > deeply into specific criteria for road classification, are the different > sections of those really that distinct from each other? Should there be a > rule of thumb that if a road seems to alternate between classifications > that it's better to tag the whole thing at the lower classification? No, since that would be tagging incorrectly. In some places (Californai at least) you'll have signs marking the beginning and ending of the freeway. > What would be a good cutoff for that? (If a road is downgraded as it goes > through a city but there's a high-grade bypass, it makes sense to tag the > two areas separately. If it goes back and forth every few miles, maybe > it's not worth recording the higher classification.) The one edge case I can think of is a road like US 395 in Washington (between I-182 and I-90). It's all built to the same standards - four lanes with very few intersections. Sometimes two interchanges are adjacent. But there's no place where you can say it changes from freeway to surface expressway. > == "Hyphens" == > We now have route relations with very good, specific rules that separate > road network and road numbers in easily parseable ways. Does it make > sense to keep the "always spaces" rule (and possibly use the route > relations to update all the routes to match that rule)? Should we go with > the way that people usually write the routes (dashes in Interstates, > spaces in US Highways and state roads)? In some places a hyphen is normal in all classes of road. We need to start rendering shields before the issue goes away. > == "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 use no prefix for state roads to make shield adoption easier. We place everything in a generic shape unless it has a prefix; since state roads would be in a generic shape anyway, it's pointless to add a prefix. > == "No Prefix" == > > Some roads only have their number in the ref= tag. I think a standard of > "don't do that; always put network information in the ref= tag, too" > should be uncontroversial, especially since the route relations should > have the network and number information separated for any data consumers > that want that. See above. Adding the prefix just to remove it during rendering is silly. (No, this isn't tagging incorrectly for the renderer, since there's nothing incorrect about using ref=50 for SR 50.) > > == "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. See above. If IL 56 is ref=56, an overlap of I-88 and IL 56 would be I 88;56. > > == "Colons" == > > He shows a road tagged "US:OH 18". This is really about what to use for > state prefixes, which is discussed above. I wonder if any roads in the UK are tagged UK:GB M1. Doubtful. > == "Parentheses" == > > Hw shows a road tagged "(36)". This is also about prefixes (or not) for > state roads and should be discussed above. This is an older standard for county roads, which I recently mass-changed in Florida to CR x after agreement on this list. Such changes should always be done en masse to avoid typos. > == "Acronym Markers" == > > I haven't seen this around me, but apparently there are roads that use the > initials of the road's name as a ref=. Is this in keeping with the other > uses of ref=, i.e. that the road is a member of a particular network and > this is the road's designation within that network? If not, if it's just > the initials of a major road, my opinion is that it probably shouldn't > have a ref= tag. These are signed with special shields. Some do have the text in a shield (http://commons.wikimedia.org/wiki/File:Meadowbrook_Pkwy_Shield.svg would be ref=M) while others have more complicated shields (http://en.wikipedia.org/wiki/File:Garden_State_Parkway_shield.png would be GSP). > > == "Some Interstates Show Exits—Others Don't" == > > This is really just a problem with map coverage, not tagging convention, > but I'd like to ask about consensus on name= and ref= tags for > motorway_junctions. ref= is pretty obviously the exit number, but > although some wiki pages (Interstate Highways, in particular) say or imply > that everything on the exit sign should go into the name= tag (including > the junction road but also further destinations like towns and distant > roads). I think it makes more sense to just have the junctioned road (or > really significant destination road, like when the junctioned road is > almost always just a means to get to another major road) in the name= tag > and use the destination sign relation for the other information. > Thoughts? I believe exit_to is for the text on the sign, and name is for an actual name *if one exists*. Often a toll road will have named interchanges, but this is rare otherwise. > > == "Coming Up" == > > There are more posts coming, but he mentions "City Boundaries" which made > me think about the TIGER CDPs. Is it worthwhile to keep administrative > boundaries based on TIGER CDPs? They're usually used for areas with > significant population density but no incorporated towns, so at best they > represent a very fuzzy idea of where a particular town's borders are and > at worst extend a town's boundaries well beyond what any residents would > consider appropriate. I recently retagged the CDPs in Florida as boundary=census, since they're not administrative boundaries. The administrative boundaries in the Orlando area were horribly outdated and inaccurate too, so I "commented them out" until I can get better-quality data. _______________________________________________ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
