Re: [Talk-us] OSM inspector routing layer now also available in the US
On 10/3/2011 9:06 PM, Kai Krueger wrote: Hi everyone, I have just seen on the blog of Geofabrik ( http://blog.geofabrik.de/?p=96 ) that the awesome OSM-Inspector routing debug layer is now available for the US as well. It can be found at http://tools.geofabrik.de/osmi/debug.html?view=routing_non_eulon=-97.93506lat=37.41729zoom=6opacity=0.98 Ah, the county line dupe problem. It would be nice if http://josm.openstreetmap.de/ticket/5867 were fixed. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] East Coast Greenway
On 10/1/2011 7:53 PM, Nathan Edgars II wrote: On 10/1/2011 6:22 PM, Paul Johnson wrote: Isn't this NCN 1? No. They're pretty close in NH-Maine, but differ in several places (the ECG uses unpaved trails while USBR 1 sticks with paved roads). The bike rendering has (mostly) updated, so you can now see the difference: http://www.openstreetmap.org/?lat=45.004lon=-67.279zoom=11layers=Crelation=1770874 ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] East Coast Greenway
On 10/1/2011 6:22 PM, Paul Johnson wrote: Isn't this NCN 1? No. They're pretty close in NH-Maine, but differ in several places (the ECG uses unpaved trails while USBR 1 sticks with paved roads). The routings are very different in Virginia and North Carolina (compare the cycle map rendering with http://www.greenway.org/images/VA.jpg and http://www.greenway.org/images/NC.jpg). ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] East Coast Greenway
On 9/30/2011 7:51 AM, Metcalf, Calvin (DOT) wrote: I'm actually in the process of doing this for MA and was trying to figure out the correct tagging, I take it in the US we don't use the local regional national bike route scheme? We do, but I don't know if I'd say that the ECG fits into it. US Bike Route 1 is ncn and the signed Boston to Provincetown route 1 is rcn. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] What does the community want from a US local chapter?
On 9/30/2011 7:37 PM, Martijn van Exel wrote: What if anything can we learn from Wikipedia? That consensus is very hard to reach :) http://en.wikipedia.org/wiki/Wikipedia:State_route_naming_conventions_poll/Account ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] East Coast Greenway
On 9/29/2011 11:20 PM, Peter Dobratz wrote: Has anyone attempted to start mapping the East Coast Greenway as a cycle route? http://www.greenway.org/ This is a project to create a bicycle route along the east coast from Florida to Maine. I think the goal is to get everything off-road, but currently they have a designated route that follows bicycle friendly roads where trails have not been built. I believe some sections of the route are signed, but most of it is not. I did a portion in Florida: http://www.openstreetmap.org/browse/relation/1225400 A XAPI query also gives portions in Maine, Rhode Island, and Pennsylvania: http://www.openstreetmap.org/browse/relation/1687751 http://www.openstreetmap.org/browse/relation/1326133 http://www.openstreetmap.org/browse/relation/1658400 ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] OpenMetaMap
On 9/22/2011 4:11 PM, Dale Puch wrote: land use admin boundaries These two will generally share nodes (if mapped properly, e.g. http://www.openstreetmap.org/?lat=28.6015lon=-81.419zoom=16layers=M rather than TIGER's horrible approximations) and so should be combined. Most of the others you mentioned can occasionally intersect (e.g. a building going right up to the property line, a road going through a building with covered=yes) but should not cause any real problems if split. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Disney (was Re: access=destination vs access=private)
On 9/16/2011 9:07 PM, Greg Troxel wrote: The disney employee discussion points out that while access_permission=customer is a relatively straightforward concept, access_permission=private conveys only If you don't have some special agreement, you can't go here. but doesn't encode the set of people that have permission. I think it's madness to put that in the map, and people should perhaps have a side database of what they've been granted permission to do, or gasp just look at the map and figure it out. One big problem with marking these as access=private is that there are also roads marked service authorized vehicles only. So you couldn't just look at the map to distinguish between the two. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Disney (was Re: access=destination vs access=private)
On 9/15/2011 10:19 PM, Anthony wrote: Also, I couldn't find any such sign going in the other direction. Even if this were access=destination, it would be a unidirectional access=destination. If you go the other direction you have to either pass through the main gate on World Drive or pass one of these signs at Reams Road and Center Drive. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Disney (was Re: access=destination vs access=private)
On 9/14/2011 10:50 PM, Bill Ricker wrote: And the sweep of Victory makes it not a useful shortcut to anywhere. I assume you mean Vista? Anyway, it could be used as a shortcut, but not much shorter than CR 535: http://g.co/maps/6uzx9 ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Disney (was Re: access=destination vs access=private)
On 9/15/2011 8:25 AM, Bill Ricker wrote: Right, from almost everywhere to almost everywhere, 535 would be better than Vista. As long as the marked cast-member-only section of World Blvd is access=private, routing should avoid it. Is this still marked cast only? I haven't been on World Drive there in years, but I do know that as of last weekend the entrance from Reams is marked the same as Vista (allowing guests). It may be a de facto one-way restriction, like Vista east of Live Oak (marked service and authorized vehicles only, only in the eastbound direction) and Sherberth (marked as private property - guests etc. allowed northbound at the county line but with no such signage southbound). ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Disney (was Re: access=destination vs access=private)
On 9/15/2011 9:50 AM, Anthony wrote: The sign does not say you may use the road so long as you need it to get to your destination (access=destination). That would preclude cast members as using it as a cut-through alternative to World Drive. And it would permit its use by solicitors, non-customers trying to avoid parking fees, and Michael Moore. It doesn't say that you may use the road long as you are not uninvited (access=permissive). That would allow all those same things as access=destination and more.It says Walt Disney World Resort Guest, Cast, and Business Invitees Only. That's access=private, or (kinda sorta) access=customers. It's a proper superset of customers (Disney calls its customers guests). So access=customers is true but incomplete. But that's an interesting point about cast members (AKA employees) being allowed to use it even when their destination is not Disney. There may however be something in their employment contract that prohibits them from doing this. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Brainstorm: What should a US map of OSM data look like
On 9/12/2011 10:04 PM, Metcalf, Calvin (DOT) wrote: - more road colors just because its a state highway tthat could mean something unpaved or divided limited acces If it's divided limited access it should be trunk or motorway. If it's unpaved it should probably be tertiary unless unpaved is the norm in the area. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Disney (was Re: access=destination vs access=private)
On 9/13/2011 8:34 AM, Anthony wrote: On Tue, Sep 13, 2011 at 4:29 AM, Nathan Edgars IInerou...@gmail.com wrote: On 9/12/2011 7:17 PM, Anthony wrote: The fact that the land is owned by Walt Disney Parks does not preclude the fact that they have granted a right of way through it. According to Orange County property records, the 65.13 acres of land is owned by Walt Disney Parks and Resorts US Inc. However, 11 acres of it is under the land use right of way (the rest is wasteland or submerged). http://beta.ocpafl.org/searches/ParcelSearch.aspx?pid=28241700017 I don't know how this figure was calculated. But I've looked at records from Disney's beginning to the present day and no easement was ever granted to the public for this road. How exhaustive of a search have you done? A complete search for all easements assigned by Disney and predecessors. Did you check the previous owners? In part. When was the road first built? Who built it? It predates Disney as a dirt road: http://cartweb.geography.ua.edu:9001/StyleServer/calcrgn?browser=genx=898y=356cat=Special+Topicsitem=Soil+Surveys%2FFlorida%2FOrange+Co+FL+1919.sidrgn=-0.0137506741%2C0.7489159377%2C0.201956%2C0.9923545075style=simple%2Fview.xslwid=1600hei=800oif=jpegprops=item%28Name%2CDescription%29%2Ccat%28Name%29cmd=zoomin When did Disney purchase the land? 1965 (through what was then a secret subsidiary): http://or.occompt.com/recorder/eagleweb/viewDoc.jsp?node=DOCC596204 Absent any evidence of a public right-of-way, and given the fact that there was a guard booth at the location of this sign until about 2005, I conclude that it is a private road. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Disney (was Re: access=destination vs access=private)
On 9/13/2011 8:58 AM, Bill Ricker wrote: The thru-roads across WDW property might or might not be registered as Public Right of Way against the deeds, but have been open to the public for up to 40 years. Not this one. There was a guard booth on Vista Boulevard near the present location of the sign until about 2005. (Earlier, probably in the 1980s, the guard booth was between Bonnet Creek Parkway and Bonnet Creek Road; wide spots can be seen in the road at both locations.) Most through roads on Disney property that are accessible to the public are actually owned by RCID. This includes everything that is above tertiary on OSM, with the exception of some links, World Drive north of Epcot Center Drive, and Osceola Parkway west of the bridge over Reedy Creek. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Brainstorm: What should a US map of OSM data look like
On 9/13/2011 12:47 PM, Toby Murray wrote: Hmm I think that page on the wiki has changed since I last looked at it. The county seat bit is probably a good idea. But even then, there have been a couple of previous discussions about place name renderings in the US so I think we can still leave it on the brainstorming list for things to consider for a US specific rendering. I like how Florida seems to have worked out, using the metro area populations: http://lists.openstreetmap.org/pipermail/talk-us/2010-October/004644.html ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] access=destination vs access=private
On 9/11/2011 6:12 PM, Anthony wrote: On Sun, Sep 11, 2011 at 10:59 AM, Nathan Edgars IInerou...@gmail.com wrote: (As opposed to http://maps.google.com/maps?q=orlandohl=enll=28.394553,-81.549518spn=0.0168,0.041199t=mz=16vpsrc=6layer=ccbll=28.394524,-81.549396panoid=f638RcwkM8_a-3tntIJmRgcbp=12,335.79,,1,3.19 which is on private property and hence presumably enforceable.) Hmm, I just looked at the Orlando Property Appraisers map, and it looks to me like it's right of way. What makes you say it is private property? You must be looking at the wrong road. Except for the intersection with Bonnet Creek Parkway and the crossing of Canal C-1, Vista Boulevard is entirely on land owned by WALT DISNEY PARKS AND RESORTS U S INC. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] What should a US map of OSM data look like
On 9/12/2011 5:57 PM, Richard Weait wrote: A few of us were just asking on irc what a US-style tile theme would look like? Many printed US maps emphasize divided highways (often including undivided multilane highways). Perhaps a thicker line style at low zooms where lanes=4 or oneway=yes -lanes=1. A separate color for toll=yes (like MapQuest does, but also for toll non-motorways). Fix bloody Georgia and the way the trunks (and other highways) blend into the trees. Render shields at lower resolutions, since the US is not as dense as the UK. De-emphasize railways at lower zooms. Label motorways with both name and number where both are tagged (this would be useful even in Europe). Ian Dees liked the idea of fewer different colors for roads, blue / motorway, green / trunk, red / primary ... I'm not sure what the point of this would be - there's definitely enough variation in importance for all these classifications to be useful. For extra credit, can it also look good in Canada and Mexico? Canada and the US have rather similar road systems, so what works in one should be good for the other. I believe Mexico has a fair number of rural non-motorway toll roads. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] access=destination vs access=private
On 9/11/2011 3:26 AM, Paul Johnson wrote: On Sun, 2011-09-11 at 02:12 -0500, Toby Murray wrote: Re: Kansas Every person riding a bicycle upon a roadway shall be granted all of the rights and shall be subject to all of the duties applicable to the driver of a vehicle ... Interesting...where did you find that? Kansas Cyclist seems to be under a different impression. http://www.kansascyclist.com/kansas_cycling_laws.html ? ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] access=destination vs access=private
On 9/11/2011 4:25 AM, Paul Johnson wrote: Beaverton, Oregon, in all their wisdom, likes to post roads as DEAD END or NO OUTLET when it clearly does have an outlet, just not for motor vehicles. I'm not sure what this has to do with access tags, since these are advisory (yellow) signs. Only a regulatory (white) no thru traffic would be access=destination. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] access=destination vs access=private
On 9/11/2011 7:53 AM, Anthony wrote: The no thru traffic sign is nonstandard and very jurisdiction specific. In general there is no letter of the law, as the law generally does not mention such signs. You seem to be right (at least in Florida): http://myfloridalegal.com/ago.nsf/Opinions/B762787E37D4A3CD85256E620055999C So the question is whether access=destination should be used where the sign exists but has no legal meaning. (As opposed to http://maps.google.com/maps?q=orlandohl=enll=28.394553,-81.549518spn=0.0168,0.041199t=mz=16vpsrc=6layer=ccbll=28.394524,-81.549396panoid=f638RcwkM8_a-3tntIJmRgcbp=12,335.79,,1,3.19 which is on private property and hence presumably enforceable.) ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] access=destination vs access=private
On 9/9/2011 7:36 PM, PJ Houser wrote: In OpenTripPlanner's case (http://opentripplanner.com/), if it is given a starting destination within an apartment complex tagged with access=private, the router will try to snap that location to the nearest permitted road, which in some cases, may be an irrelevant or disconnected road to the origin. But this also happens for a gated community, which is definitely access=private. I think Google handles it by routing you along it but warning you that you're starting or ending on a private road. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] [Tagging] RFC: place=neighbourhood
(crossposted to talk-us) On 9/2/2011 3:30 AM, Bryce Nesbitt wrote: On 09/01/2011 12:01 AM, Stephen Hope wrote: On 1 September 2011 11:41, Nathan Edgars IInerou...@gmail.com wrote: In the US, the problem is that address place names depend on which post office serves the area, and there is no freely available accurate data showing this. Many suburban areas outside Orlando city limits have Orlando in the address, and there are some cases where a place in city A uses an address that is not city A. That's interesting, and a bit weird to me. Here, post offices open, close, move around, merge and split - and it makes no difference to my address. I've lived to places in the USA where I could not be called to Jury duty... because the Court sent notices based a naive address match, but the property was actually in a different jurisdiction. Note that the USPS recently lost a freedom of information act fight, and was forced to share post box data. Perhaps other data can be FOI'ed out of them. As far as I know, FOIA has nothing to do with copyright, and since the USPS is not technically part of the government, its data is copyrighted by default. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] [Tagging] RFC: place=neighbourhood
On 9/8/2011 8:34 AM, Carl Anderson wrote: In the US if you get records through a FOIA they are public records of the US Govt. I don't think so: http://www.justice.gov/oip/foia_updates/Vol_IV_4/page3.htm http://www.cdc.gov/od/foia/policies/copyr-f.htm ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] access=no with exceptions
On 9/8/2011 6:19 PM, PJ Houser wrote: In Portland, Oregon, we have been tagging certain ways with access restrictions as access=no and then explicit exceptions, like psv=yes, foot=yes, bicycle=yes. In the wiki, for the access key, it states Use the *access*=* key to describe a general access restriction that applies to all transport modes.Where different restrictions apply to different modes of transport then mode specific tags can be used. Here's an example of our work http://www.openstreetmap.org/browse/way/30288157 Is this an appropriate use of access=no or does access=no imply all transport modes are not allowed? We have been using access=no with specific mode exceptions as *=yes because it reduces the number of tags needed. What does everyone else think? In this case, I'd say it's fine. Personally I'd use access=private (since supervisors etc. are presumably allowed to drive their cars there) and bus=yes (since psv includes taxis). I don't think it's correct to give these ways a name. On the other hand, I wouldn't expect to see a cycleway tagged access=no bicycle=yes. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] update: Florida maxspeed import
I've completed the import outside the Tampa area. I noticed when working on it that it seems to not include recent changes. So it's as if someone surveyed the roads for OSM several years ago. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] update: Florida maxspeed import
I've finished with the mainline U.S. Highways and Interstates and the major grid of state roads (1-2 digit and multiples of 100). You can see progress (lagged by a bit over a day) here: http://www.itoworld.com/product/data/ito_map/main?view=5lat=29lon=-83zoom=8 The one area I'm skipping is Tampa, because of Frederik Ramm's damage when he dirty-reverted Anthony and the possibility of a second round of damage due to the OSMF's license change. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] [KS] anyone familiar with this area?
On 9/3/2011 3:39 PM, Martijn van Exel wrote: Hi all, I just stumbled upon this rail yard (?) near Eudora, KS. http://www.openstreetmap.org/?lat=38.9233lon=-95.0096zoom=14layers=M Does anyone know what this is? Bing imagery shows most of the tracks (long) gone. I'd delete them if I knew more about the local situation. Much of the TIGER data comes from USGS topos, including this: http://mapper.acme.com/?ll=38.92299,-95.01328z=15t=T ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] OpenTripPlanner Final Report
On 9/3/2011 11:23 PM, Josh Doe wrote: 58: have you considered putting an RFC out on cycleway=shared_lane to get some discussion going around the tag? Every main lane where bikes are allowed is a shared lane. Presumably the intent is the indicate where there's a shared lane *marking*, i.e. a sharrow. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Planning to import speed limit data for Florida
On 9/1/2011 2:16 AM, Toby Murray wrote: http://ni.kwsn.net/~toby/OSM/FL_maxspeed.osm.gz If you have trouble dealing with the extra spaces I can clean it up tomorrow. Bed time now. But it looks like it is just putting in the same number of spaces in front of the numbers for some reason. Thanks. I should be able to clean it up in TextPad or JOSM. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Planning to import speed limit data for Florida
On 9/1/2011 2:23 AM, Toby Murray wrote: Hmm I just noticed that it was a little eager about creating relations so some ways don't have any tags but are only members of a relation which is tagged. Not sure if this will work with the routes plugin or not. It actually works fine. There are ways that are members of multiple relations with different maxspeeds, but this is because the data is flawed and has two overlapping ways in these places. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] Planning to import speed limit data for Florida
http://www.dot.state.fl.us/planning/statistics/gis/roaddata.shtm This is public domain per Microdecisions, Inc. v. Skinner (though I'm waiting on a reply from FDOT confirming that they agree). After checking all current maxspeed tags against the data to ensure accuracy, I plan to use this as a background layer in JOSM and manually split existing ways at speed limit changes. Tags added will be maxspeed=* and source:maxspeed=FDOT Maximum Speed Limits GIS data, updated August 27, 2011: http://www.dot.state.fl.us/planning/statistics/gis/roaddata.shtm I will only do this for state roads, as a quick look shows that it cannot be relied on for county roads. I may in the future add other tags from the same data, such as access management. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Planning to import speed limit data for Florida
On 8/31/2011 9:57 PM, Dale Puch wrote: Anyways that is why I am interested in how you plan to attack it. I haven't started, but I plan to convert to .osm using gpsbabel and then use the JOSM 'routes' plugin to color the maxspeed values of the background. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Planning to import speed limit data for Florida
On 8/31/2011 9:57 PM, Dale Puch wrote: For me it was partly an issue of the data covering a large land area, then only able to download small chunks from OSM to edit. For this, a xapi query of relation[network=US:FL] gets all the state road relations. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Planning to import speed limit data for Florida
On 9/1/2011 1:02 AM, Dale Puch wrote: If a way with [network=US:FL] is NOT in a relation, will it be returned by this? I don't think any ways have this tag. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Planning to import speed limit data for Florida
On 9/1/2011 1:19 AM, Toby Murray wrote: On Wed, Aug 31, 2011 at 8:58 PM, Nathan Edgars IInerou...@gmail.com wrote: On 8/31/2011 9:57 PM, Dale Puch wrote: Anyways that is why I am interested in how you plan to attack it. I haven't started, but I plan to convert to .osm using gpsbabel and then use the JOSM 'routes' plugin to color the maxspeed values of the background. This seems like an interesting project. I didn't think using the routes plugin would work at first but looking again, that actually seems like a neat way of doing it. I was envisioning having to export to a georeferenced image file and loading it into JOSM as an imagery layer. However I don't think gpsbabel is the right tool to convert the shapefile. From what I can see, gpsbabel just creates tagless ways. You can hard-code tags to add but I don't see any options to pull attributes out of the shapefile and put them into tags. I think you will need to use shp2osm or ogr2osm or something like that. It lets you export one tag using -i shape,name=SPEED. 5 minutes later... In fact, it had been too long since I fired up ArcMap so I played around with the file a bit and ended up reprojecting it to WGS84 and running it through ogr2osm. It put extra spaces in the tag values and all the keys are upper case but other than that it seems like a usable file. I can get it to you if you want. This would probably be best since I'll have to deal with the ROAD_SIDE field as well. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Use of ref-tag on state highways
On 8/24/2011 6:25 PM, Craig Hinners wrote: FWIW, I agree with all of Jason's suggestions, below, for the relation-level network tag values. It mirrors my thinking on the matter exactly. I disagree with putting alternate and business in the network. These modifiers are part of the designation, and some states (Arkansas in particular) treat them as lettered suffixes rather than separate plates. Original Message Subject: Re: [Talk-us] Use of ref-tag on state highways From: Jason Straub strau...@yahoo.com mailto:strau...@yahoo.com Date: Wed, August 24, 2011 3:37 pm To: talk-us@openstreetmap.org mailto:talk-us@openstreetmap.org talk-us@openstreetmap.org mailto:talk-us@openstreetmap.org As the person that just got done labelling each TX state highway, I'll chime in here with some comments. For the network tag, I think that the labelling should be (country : state network : network within the state : subnetwork in state), while the ref is JUST the number for that highway. So: US:I - Interstate US:I:BUS - Business Interstate US:US - US Route US:US:BUS - Business US Route US:US:ALT:BUS - Business Alt US Route US:TX - Texas State Highway US:TX:FM - Farm to Market US:TX:RM - Ranch To Market US:TX:FM:Bus - Business Farm to Market ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Use of ref-tag on state highways
On 8/24/2011 7:25 PM, Craig Hinners wrote: I see what you're saying about Arkansas, in that their treatment of US business routes on signage feels more like a different designation. On the other hand, Maryland uses a totatally different shield design for business US routes (basically a green-on-white US shield), which is more of a distinct network feel. Business routes, yes (similar to Interstate business routes). But other types (alternate, scenic) get the normal treatment. Alternate routes, especially, are intended as equal parts of the U.S. Highway system. For example, US 41 used to be split into US 41E and US 41W between Nashville and Hopkinsville, KY. AASHO decided in the 1930s that split routes were confusing, and so in the 1940s US 41W became US 41 Alternate. US 45 Alternate in Mississippi was never a 'mainline' route, but improvements have made it the better route for through traffic between Meridian and Tupelo. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Use of ref-tag on state highways
On 8/22/2011 12:05 PM, Richard Fairhurst wrote: Nathan Edgars II wrote: Exactly my point. Great Britain is fine with ref=M1 despite there being an M1 in many other countries - and even in Northern Ireland, part of the same country. There are some little-known fields in OSM data called latitude and longitude, which allow you to find out what country an object is in. :) And what state, despite the implications of some here. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Use of ref-tag on state highways
On 8/21/2011 4:34 PM, Ian Dees wrote: I really don't understand this logic. I have never run into a case where JOSM has broken a relation in a way that wasn't obvious to me. Obviously I don't get around as much as you, Nathan, but can you remind me of a specific case where a relation breaks over the course of normal editing? OK, here's an example I just found: http://www.openstreetmap.org/browse/way/126665601 and http://www.openstreetmap.org/browse/way/126665603 are (as of this writing) not part of http://www.openstreetmap.org/browse/relation/386256 or http://www.openstreetmap.org/browse/relation/386272 . User maxolasersquad dualled a portion of the road, and presumably copied tags to the ways, but didn't copy relation membership. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Use of ref-tag on state highways
On 8/22/2011 5:47 PM, Richard Weait wrote: If there is no overlap, a single network / ref pair will work just fine. Why wouldn't it? What breaks is multi-values in network / ref tags. Don't do that. We have better ways to do this; relations. Relations break. Hence ref tags are there as a backup to repair relations. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Use of ref-tag on state highways
On 8/22/2011 5:53 PM, Ian Dees wrote: Ways break too, it's just that editors sometimes remember to fix them during their edit session (e.g. by copying the tags when they dual-carriage a way). If we get people to fix the relations too, then they won't break. So how will we do this? I've proposed one partial solution: http://lists.openstreetmap.org/pipermail/tagging/2011-August/008204.html (By the way, conflicts are a big problem for relations, in that if two people simultaneously split different ways on the same route, it causes a relation conflict but not a way conflict. Until this is fixed, relations will be strictly inferior with respect to damage control.) ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] A proposal to improve relation handling
I and some other mappers have noticed that relations are more prone to breaking than equivalent tags on ways. (For a simple example, imagine two people simultaneously editing different parts of a route and each splitting a way, e.g. to add a maxspeed to a portion. If the route is stored as a relation, the second one to upload will get a conflict, and relation member conflicts are rather difficult to resolve. On the other hand, if the route is stored as ref tags on the ways, no conflict will result.) Another problem is that relations are harder for new mappers to work with than tags. If you want to say that a way is part of Vermont Route 9 with tags, you simply add ref=VT 9. But if you want to use a relation, you first need to find the relation ID or a way that already has it, then add the way to it. I am going to propose improvements to the API and to editing software that will make relations easier to work with and less prone to breakage. (Note that I am not a coder and the rather rude response to 'write a patch' will get you nowhere.) ;API changes 1. Handle conflicts better. Treat the relation members as a comma-separated list, and apply each diff independently (this would probably need some checking that they are not too close to each other). Similarly, if one person only changes the tags and the other the members, do not throw a conflict. (This sort of thing could also help minimize conflicts on ways.) 2. Treat relation membership as a characteristic of the members. Each revision of each member includes a separate field that stores what relations it is a part of. When an object is downloaded, the list of relation IDs it is a part of is included (and perhaps so is the type of relation - route, multipolygon, etc. - this needs more thought). On uploading a change in membership, the editor will send this field (if nothing else is changed, the other tags do not need to be uploaded) and a conflict can occur on this field. Perhaps, for backwards compatibility, a relation change can be uploaded without this field, but it will always 'lose' a conflict even if saved before a change that contains the field. ;Editor changes 1. Handle conflicts better. If a conflict still happens, make it easier to see what members are added or removed without caring about the order. Perhaps use the field from API change 2 to improve the process. 2. Treat relation membership as a characteristic of the members. Put the relation among the other tags with only a minor notation that it is not a standard tag, and with three columns instead of two (e.g. network, ref, role). Make the process of adding an object to a relation essentially the same as that of adding a tag. For example, the following could be the method in which a way is added to the relation for Vermont Route 9 with role east (the relation will have tags network=US:VT and ref=9): *Select the way. *Click the same button or press the same key as when adding a normal tag. *Fill in the first field as US:VT. (Perhaps the editor realizes that this is a relation network, but more likely a box will have to be checked that a relation is being used, absent a regional plugin that will recognize certain networks.) *Fill in the second field as 9. *A third field will appear; fill in east. *Now the editor finds a relation with network=US:VT ref=9. If none is loaded, a new type of API call will be made to find it. If none is found, a new one will be created. It's possible that this will need regional presets to work properly. 3. Change uploading to comply with API change 2. Editor change 2 is most important for making relations easier to work with. The other changes are important for making conflicts less frequent and easier to handle when they do appear. Any comments? ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Use of ref-tag on state highways
On 8/21/2011 1:57 PM, Henk Hoff wrote: Putting every single route-label in the ref-tag is not a good idea. Putting every single route-label in the ref-tag is the way we do things. If you don't like it, you can always find a different country to armchair-map (most countries don't have route overlaps). ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Use of ref-tag on state highways
On 8/21/2011 2:22 PM, Alan Mintz wrote: As someone pointed out, once you put them in a relation, the tags on the ways become duplicative. While this is generally bad database design, it's also true that many consumers don't deal with relations, and so we need the duplication and the problems that go with it. It's also true that relations break very easily. Serge put it better than I could: http://lists.openstreetmap.org/pipermail/tagging/2011-August/008199.html I proposed a solution: http://lists.openstreetmap.org/pipermail/tagging/2011-August/008204.html ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Use of ref-tag on state highways
Sent again; sorry to people who receive multiple copies due to moderation. On 8/21/2011 4:34 PM, Ian Dees wrote: I really don't understand this logic. I have never run into a case where JOSM has broken a relation in a way that wasn't obvious to me. Obviously I don't get around as much as you, Nathan, but can you remind me of a specific case where a relation breaks over the course of normal editing? The real problem is that there's no way to show the former state of a relation, and I tend to fix errors whenever I find them. I know I've recently fixed US 10 in the Minneapolis-St. Paul area, mostly where it overlaps with Interstates. If you're better than me at figuring out the history, see: http://www.openstreetmap.org/browse/changeset/5247114 The most common problem I see is when someone splits a way to create a bridge, and for whatever reason the newly-created ways aren't part of the relation. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Use of ref-tag on state highways
On 8/20/2011 12:01 PM, Val Kartchner wrote: What about another field for the network. For instance US:UT:SR for Utah State Routes then the ref tag will be just the number. I'd like to put it all into the ref field, but the renderers just don't parse this field and render the whole string. What happens when a state route overlaps a U.S. Route? ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Use of ref-tag on state highways
On 8/20/2011 6:04 AM, Henk Hoff wrote: User Nathan Edgars is now changing all State Highway ref-tags in Arkansas from AR ## to Hwy ## False. I'm using Hwy x on ways that lacked ref tags. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Use of ref-tag on state highways
On 8/20/2011 12:42 PM, Metcalf, Calvin (DOT) wrote: It doesn't matter if a state like MA uses SR internally we just use that because we deal with only one states routes. Postal code prefixes for all routes makes the most sense. So how do you distinguish California from Canada? Or Delaware from Germany? And do you support putting an abbreviation of the county name in the ref tag for a county route? Or are those fine with the ambiguous CR? ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Use of ref-tag on state highways
On 8/20/2011 1:29 PM, Metcalf, Calvin (DOT) wrote: From: Nathan Edgars IInerou...@gmail.com On 8/20/2011 12:42 PM, Metcalf, Calvin (DOT) wrote: It doesn't matter if a state like MA uses SR internally we just use that because we deal with only one states routes. Postal code prefixes for all routes makes the most sense. So how do you distinguish California from Canada? Or Delaware from Germany? And do you support putting an abbreviation of the county name in the ref tag for a county route? Or are those fine with the ambiguous CR? We don't deal with other states so we don't distinguish so in a international contect you'd need to add more detail Meaning? How would you add more detail? US:MA:2? US:FL:ORA:535? UK:GB:M1? ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Use of ref-tag on state highways
On 8/20/2011 1:50 PM, Val Kartchner wrote: On Sat, 2011-08-20 at 13:39 -0400, Nathan Edgars II wrote: Meaning? How would you add more detail? US:MA:2? US:FL:ORA:535? UK:GB:M1? And once we set our standard here in the US, how do we get it adopted world-wide? Exactly my point. Great Britain is fine with ref=M1 despite there being an M1 in many other countries - and even in Northern Ireland, part of the same country. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Use of ref-tag on state highways
On 8/20/2011 2:13 PM, Henk Hoff wrote: The difference with the UK example is that there is a consistency: M1 = M1. In the case of Arkansas we're talking about AR 26, Hwy 26 and possibly in the future also 26. All being a ref for the same State Highway. That is the problem. I agree with this, and will abide by any reasonable consistent convention. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Use of ref-tag on state highways
On 8/20/2011 2:41 PM, Toby Murray wrote: I still see a lot of messages coming through about a network tag. This tag is already used on route relations so I'm not sure why it is still being discussed. The ref=* tag on ways is primarily just duplicating data from the relation and tagging for the renderer anyway because most current renderers don't use route relations. It's also tagging for redundancy because relations break easily, and repairing them is much easier when ref tags exist. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Use of ref-tag on state highways
On 8/20/2011 2:56 PM, Phil! Gold wrote: * Nathan Edgars IInerou...@gmail.com [2011-08-20 14:24 -0400]: I agree with this, and will abide by any reasonable consistent convention. The wiki has long recommended using the two-letter state abbreviation, a space, and the number. Is there any problem with continuing to use this approach? The wiki has long been inconsistent. It probably still recommends the US:ST approach somewhere. It's not what the states themselves use. I know I'm not the only one who believes this; I've noticed, for example, a number of UT changed to SR with a comment like there's no such thing as UT x. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Use of ref-tag on state highways
On 8/20/2011 3:29 PM, Val Kartchner wrote: Because some states officially designate the road as SR-26, for instance. Not to mention states like Texas, which have, for example: State Highway (SH) 121 Loop 12 Spur 408 Beltway 8 Farm to Market Road (FM) 1960 Park Road (PR) 27 and probably a few more types. All of these are maintained and numbered by the state. There are also, I believe, signed county routes in some counties. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Use of ref-tag on state highways
I created a table of most of the different state-level route markers (not counting West Virginia's county routes, which are actually state-maintained): http://wiki.openstreetmap.org/wiki/User:NE2/routes This can be used as a basis for a table of abbreviations. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Oknoname reservoirs
On 8/13/2011 6:58 PM, Carl Anderson wrote: They appear to be descriptive names in general use within Oklohoma. Oknoname reservoirs are referenced in these, so the names are at least in use. [snip] Interesting. Yes, the names do appear to have become used. I wonder if the bureaucrat responsible for labeling them expected this :) ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Safe Routes to School Mapping Toolkit concept
This will require objective criteria for grading a route. Does SRTS ignore complications, such as badly-designed bike lanes and especially sidepaths decreasing safety, and kids choosing the sidewalk over even well-designed bike lanes? How is safety of crossing a street determined? How about safety of walking in the street? One thing that might be useful in OSM would be marking crosswalks (or intersections?) where a crossing guard operates during school commuting hours. As a suburban example for discussion, I volunteer the local elementary school: http://www.openstreetmap.org/?lat=28.41182lon=-81.49269zoom=17layers=M Buena Vista Woods Boulevard has bike lanes, but kids generally ride on the sidewalk. There is a crossing guard at the west end of BVW, helping kids cross Apopka Vineland Road into the gated community. The path to the east (through the park) is open during school hours, and allows kids from the two subdivisions to the northeast to reach the school (I don't know if anyone from Sand Lake Point, the northern one of the two, does, but I often see kids and parents riding on the sidewalks of Sand Lake Cove and onto the path). ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] Another case of JOSM ignoring US tagging standards
https://josm.openstreetmap.de/ticket/6601 https://josm.openstreetmap.de/ticket/6667 ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Another case of JOSM ignoring US tagging standards
On 8/8/2011 2:17 PM, Frederik Ramm wrote: Hi, Nathan Edgars II wrote: https://josm.openstreetmap.de/ticket/6601 https://josm.openstreetmap.de/ticket/6667 Now that this one has been cleared up, No it hasn't. It's possible for an individual mapper to set additional values (assuming they find this thread) but not to set it to not warn for any route relation. what are the other cases you mention in the subject line? https://josm.openstreetmap.de/ticket/5109 ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Boundary Relation and Tagging
On 8/4/2011 7:06 PM, Mike Thompson wrote: Here is another, somewhat related, question. Fort Collins CO is represented by two separate relations: 112524 and 253754, neither of which matches the 2008 TIGER data that they claim to be derived from, although 253754 is a much closer match. What is going on here? There is only one Fort Collins, CO and in my mind it should only be represented by one relation in the data. The TIGER boundary data is a huge mess, and is very rarely precise. We probably would have been better off not importing it. As for the two relations, it seems that when there are inner ways there will be one relation with no tags and outer and inner roles, and another with all the ways but no roles. This may be a remnant of the old days before multipolygon support was good. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] Best way of tagging split between electronic toll and cash lanes?
Many toll plazas now have high-speed electronic toll lanes. Tagging seems haphazard. As I see it, the choices are: *What gets tagged as motorway vs. motorway_link? *What gets the name, ref, and relation membership? Note that some plazas have the cash lanes marked like an exit: http://en.wikipedia.org/wiki/File:SR_417_University_Toll_Plaza.jpg while others have the cash lanes in the middle and the high-speed lanes as an exit. There may also be some where it's more of an equal split, with neither marked as the main route. So the question is whether to use motorway_link for what's signed as an exit, or to consistently use motorway for either cash or for high-speed. There's also a question of what access restrictions go on the high-speed lanes. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] SR-96 partially gone
On 7/16/2011 4:04 PM, Val Kartchner wrote: Hello, I've been mapping Scofield Reservoir in Utah. I've also been aligning roads with satellite images. SR-96 has partially disappeared after my edit. It was there before. http://www.openstreetmap.org/?lat=39.78855lon=-111.12483zoom=17layers=M This is the area with the problem. If you zoom out one level you will see SR-96 appear again. What is wrong? I fixed this a while ago (someone had joined two ways badly, creating something like highway=secondary;residential, hence the name partly visible). Must have never been rerendered at that zoom. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] MassGIS import: condition tag
The MassGIS import included a condition tag: http://www.openstreetmap.org/browse/way/9602415 Presumably this is something in their data, but what use is it to us? There's no definition of what 'intolerable' means, and no way to know what value to use if the road is repaved. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] MassGIS import: condition tag
On 7/15/2011 8:15 PM, Greg Troxel wrote: Nathan Edgars IInerou...@gmail.com writes: The MassGIS import included a condition tag: http://www.openstreetmap.org/browse/way/9602415 Presumably this is something in their data, but what use is it to us? There's no definition of what 'intolerable' means, and no way to know what value to use if the road is repaved. At first glance, a highway condition classification, apparently from the state department of transportation, is more useful than osm's smoothness tag. But there's nothing about when it applied. If I know a road has been repaved in the last few years, should I remove the tag or leave it inaccurate? ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] MassGIS import: condition tag
On 7/15/2011 9:13 PM, Greg Troxel wrote: I would say that if you know a road has been repaved, you might set it to 'good' or whatever the appropriate value is. This has pointers to the mass spec, I think: http://www.mass.gov/mgis/eotroads.htm According to the linked PDF, the field measures *structural* condition. Does this mean that it actually represents the quality of the grading as well as the pavement? If so, it's something that can't be updated by us and shouldn't be in the database. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] NOAA Composite Shoreline
On 7/13/2011 2:47 PM, Josh Doe wrote: Has anyone looked at the NOAA Composite Shoreline? It seems to have much better accuracy (as in orders of magnitude better) than the PGS shoreline that was imported, at least for the small portion I checked in Virginia. Unless there are better sources, I'll probably use this to fixup Virginia's coast piece by piece in JOSM at some point. Is it better than the NHD shoreline? ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] New orthoimagery for NC
On 6/10/2011 5:31 PM, James Umbanhowar wrote:
The state of North Carolina has released 6 inch resolution orthoimagery for
the entire state that was taken during leaf off time in 2010. These are great
quality for all types of mapping. The information about the service is at:
http://data.nconemap.com/geoportal/catalog/search/resource/details.page?uuid={B7B32EE4-9B96-4FE5-88DF-255DA7FDA98C}
The following url works in JOSM:
http://imagery.nconemap.com/arcgis/services/2010_Orthoimagery/ImageServer/WMSServer?FORMAT=image/jpegVERSION=1.1.1SERVICE=WMSREQUEST=GetMapLayers=Orthos2010;
I finally had a look at this in JOSM. Thanks; it's good for filling in
the gaps in Bing coverage (Bing is actually newer in some places, such
as I-74 construction near Randleman).
___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] Relation roles
I've started using forward/backward roles rather than north/south/east/west on relations for state highways, due to JOSM's relation editor supporting sorting by them and Nakor's tool (which was already less convenient, given that you had to upload to OSM and get the relation number) being down. I've been leaving U.S. Highways alone (Interstates don't matter either way because they're almost always dual carriageway), but this means that there's no way to check for completeness of a relation. How much uproar would there be if I started changing to forward/backward roles in conjunction with checking for completeness? Is there any benefit to the slightly increased amount of information provided by the directional roles? Are there any other solutions? It appears from http://josm.openstreetmap.de/ticket/5109 that the JOSM devs are not interested in supporting directional roles. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Relation roles
On 6/29/2011 2:49 PM, Nathan Mills wrote: My personal preference is to use directional roles so that they match what is written on signage. It also avoids the inevitable which way is forward and which is backward question. How would you suggest ensuring that relations are and remain complete? ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Relation roles
On 6/29/2011 2:49 PM, Nathan Mills wrote: It also avoids the inevitable which way is forward and which is backward question. Forward is the direction of the way. If a way carries both directions of the route, it gets no role (as with directional roles). ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Relation roles
On 6/29/2011 3:28 PM, Josh Doe wrote: On Wed, Jun 29, 2011 at 3:06 PM, Nathan Edgars II nerou...@gmail.com mailto:nerou...@gmail.com wrote: On 6/29/2011 2:49 PM, Nathan Mills wrote: It also avoids the inevitable which way is forward and which is backward question. Forward is the direction of the way. If a way carries both directions of the route, it gets no role (as with directional roles). I'm a little slow here; forward means the route follows the direction of the way (order of nodes), so for dual carriageways if the ways are in: * opposite directions: they would both have oneway=yes and both use the forward role? * same direction: one would have oneway=yes and the forward role, the other with oneway=-1 and the backward role? I find it a little confusing... Yes. This is the standard for bus and bike routes, as well as highway routes in most countries. JOSM makes it easy to sort a relation this way. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Relation roles
On 6/29/2011 3:47 PM, Toby Murray wrote: For bike/bus routes that makes sense since they may go against the directionality of the way. For highway routes this doesn't seem to make sense and as Josh pointed out is just duplicating oneway information whereas the signed direction of the highway provides new information. Except for cases where a highway is signed only one way on a two-way street. I have come across a few so-called one-way pairs where both streets are two-way. To determine which way the route goes you need to download the entire relation and see which end is east or north of the other. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Relation roles
On 6/29/2011 4:50 PM, Richard Weait wrote: On Wed, Jun 29, 2011 at 1:44 PM, Nathan Edgars IInerou...@gmail.com wrote: I've started using forward/backward roles rather than north/south/east/west on relations for state highways, due to JOSM's relation editor supporting sorting by them and Nakor's tool Nakor's tool for ... ? Link? Formerly at http://toolserver.org/~nakor/relation.fcgi?relation= , and used to update http://wiki.openstreetmap.org/wiki/User:Nakor/Interstate_relations_check and http://wiki.openstreetmap.org/wiki/User:Nakor/US_relations_check . How much uproar would there be if I started changing to forward/backward roles in conjunction with checking for completeness? Is there any benefit to the slightly increased amount of information provided by the directional roles? Are there any other solutions? It appears from http://josm.openstreetmap.de/ticket/5109 that the JOSM devs are not interested in supporting directional roles. I'd expect that we need a much stronger argument in favour of removing the additional information provided by the directional roles. It is dead simple to reverse the direction of a way and break your proposed forward-role, while directional roles would be fine. JOSM automatically changes forward to reverse if you reverse a way, and if Potlatch doesn't it would be simple to have it do so. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Relation roles
On 6/29/2011 5:03 PM, Richard Fairhurst wrote: FWIW, and you should absolutely not listen to me because I'm a long way away and it's up to you guys to sort yourselves out... but I'd create a separate relation for each direction (i.e. one northbound relation, one southbound relation) and not bother with roles at all. It's simpler conceptually, simpler for the newbie to edit, simpler to process. (If you wanted to, you could then have a super-relation for the two relations, though personally I wouldn't see the need.) This is simpler for dual carriageways, but certainly not when the road is primarily single-carriageway. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] US highway classification (trunk)
On 6/2/2011 3:17 PM, Nathan Edgars II wrote: To this end, I've been systematically going through trunks in the US and adding lanes=* tags. This is of course useful even if nothing is done rendering-wise. Thanks to PeterIto, we can see the fruits of this: http://www.itoworld.com/product/data/ito_map/main?view=128lat=38lon=-97zoom=6 red=2 lanes, green=4 lanes, blue=6 lanes... Trunk and motorway are wider than primary, so thick red are two-lane trunks (or motorways where they exist). ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] New orthoimagery for NC
On 6/10/2011 5:31 PM, James Umbanhowar wrote:
The state of North Carolina has released 6 inch resolution orthoimagery for
the entire state that was taken during leaf off time in 2010. These are great
quality for all types of mapping. The information about the service is at:
http://data.nconemap.com/geoportal/catalog/search/resource/details.page?uuid={B7B32EE4-9B96-4FE5-88DF-255DA7FDA98C}
Have you confirmed that this is usable for tracing?
___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] FYI - user going around changing highway refs just to put in the - and /
On 6/9/2011 3:54 PM, David ``Smith'' wrote: On Sun, May 29, 2011 at 4:08 AM, James Mast rickmastfa...@hotmail.com mailto:rickmastfa...@hotmail.com wrote: I just happened to notice this guy tonight was going around and editing the ref tags on highways in the US just to replace the space and put in the hyphen. There's actually a sensible reason for this, at least for Interstate highways: http://mutcd.fhwa.dot.gov/htm/2009/part2/part2a.htm Manual on Uniform Traffic Control Devices, Section 2A.13, guidance paragraph 9: When an Interstate route is displayed in text form instead of using the route shield, a hyphen should be used for clarity, such as I-50. Of course, this applies to road signs and not maps, but I still count this as precedence. Renderers should ideally tolerate ref tags of the form I-50. Yes, I think we all recognize that I-x is the common form outside OSM. But for whatever reason we've been using I x in OSM for a long time. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] East end of I-44 (Re: shields and overlaps)
On 6/8/2011 2:29 PM, Lord-Castillo, Brett wrote: This shot shows the road as all 4 interstates and US-40 at once. http://maps.google.com/?ie=UTF8ll=38.617642,-90.181049spn=0.00824,0.013078z=17layer=ccbll=38.617746,-90.181461panoid=etjY4kn9oqoecsdYSjoXqwcbp=12,285.92,,0,5.98 (This shot is actually from during the realignment, as shown by the I-64 detour sign.) As soon as you hit the end of the bridge, the 4 Interstates start splitting up. Is there any reassurance signage for I-44 in either direction here? This is close enough to the I-44/55 junction that the exit 40C overhead could easily be implying that it's 'TO' I-44, like exit 1C on I-255 westbound is signed US 50/61/67 despite not leading directly to the latter two. The mileposts display I-55 rather than I-44; is it MoDOT policy to always use the lowest number (if both are the same network)? ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] FYI - user going around changing highway refs just to put in the - and /
On 5/29/2011 4:08 AM, James Mast wrote: I just happened to notice this guy tonight was going around and editing the ref tags on highways in the US just to replace the space and put in the hyphen. (I noticed this when going to load the I-77 NC relation to add in speed limits I saw and wrote down on a recent trip to Charlotte because he changed a name of a way.) He's done in this in several places recently. It *seems* that all he does in the changesets is change the ref tags or expands the name tags fully (AVE Avenue). Of course, it's one of those guys that uses Potlatch2 and doesn't even put in a comment.. (I really hate those kinds of people). The user is 'chdr'. http://www.openstreetmap.org/user/chdr Another real doozy: http://www.openstreetmap.org/browse/way/33263209/history ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Huge erroneous military landuse
On 6/7/2011 12:55 AM, Dion Dock wrote: On 6/3/2011 9:43 PM, Nathan Edgars II wrote: Oh wow. http://www.openstreetmap.org/user/SimonSquare/edits contains the following: landuse=military on the US border religion=christian denomination=anglican landuse=cemetery on the UK leisure=park on France landuse=forest on Canada All fixed. Could this have been accidental, or is it likely to be deliberate vandalism? I'm curious. a) How did you find this particular change? I noticed that it stopped at the international boundary, so I checked the boundary relation. b) How did you fix? I reverted his changesets (JOSM reverter plugin). ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] shields and overlaps
On 6/7/2011 9:30 AM, Lord-Castillo, Brett wrote: I-64, I-70, I-55, I-44, US-40 AKA, the Poplar St Bridge in St Louis, MO. It is the only quad Interstate route in existence. I-70 will reroute in 2015 and it will go down to a tri route. It also carries the designation Historic Route 66 and has the Historic 66 shield on it as well. (Even weirder, I-44 ends at the Illinois state bridge halfway across the bridge, so the west half of the bridge is I-64/70/55/44 US-40 while the east half is only I-64/70/55 US-40 Unfortunately, I-44 is missing from this part of St Louis, so it is not on the way right now. http://www.openstreetmap.org/browse/way/32333977 I-44, at least according to signage in 2008, ends at I-55. http://www.interstate-guide.com/images044/i-044_et_04a.jpg ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] Unsigned routes (Re: shields and overlaps)
On 6/4/2011 7:06 PM, Chris Lawrence wrote: Reminds me, we need to add some notation for unsigned routes in relations (the only approaches I can think of are either to tag it as roles on each member, with things like unsigned;west sometimes - which is icky but would work - or having separate relations for unsigned routes). This is one area OSM could really be an improvement over Google Maps etc that direct people to follow FL 600 and the like. I've been creating separate relations with unsigned_ref=* and using unsigned_ref on the ways (example: http://www.openstreetmap.org/browse/relation/23154). This of course doesn't work so well when a piece in the middle is unsigned (Arkansas and US 63, yuck). It also fails when the state doesn't have a good source for where the unsigned route goes (Florida and SR 35 through Bartow). As for Florida, I never tagged the unsigned routes in the first place. I'd certainly be willing to add them, but as mentioned the routing isn't always clear. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] shields and overlaps
On 6/4/2011 9:46 PM, James Mast wrote: Also, are you going to try to add proper Future Interstate shields? Currently in Google, they just show a normal Interstate shield. It might give people a proper reason to tag these posted Future Interstate correctly instead of without the Future tag. I've noticed a lot of I-73/I-74 that is posted as Future in the field tagged as normal Interstates would shouldn't be the case.. Since the only difference is that the word INTERSTATE is replaced by FUTURE, I don't see how we could show the difference. See the photos on http://web.duke.edu/~rmalme/i73seg7.html - in the first one it's almost impossible to tell that it's future. I'm also not sure that there's any benefit in distinguishing. Note: this is different from the occasional 'future corridor' signs like in http://web.duke.edu/~rmalme/i74seg14.html - those should be marked with fut_ref=*. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Unsigned routes (Re: shields and overlaps)
On 6/5/2011 12:15 AM, nat...@nwacg.net wrote: In Arkansas, routes are not unsigned or (except in very rare cases) cosigned. The route ends where it meets a route of higher priority and begins again as a new segment elsewhere. There are a lot of states that do this internally. But most sign them properly as overlaps, even if they don't have overlaps 'behind the scenes'. Arkansas does have some (partly?) signed overlaps, like US 65-167 on I-30 and I-530 near Little Rock. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Unsigned routes (Re: shields and overlaps)
On 6/5/2011 12:22 AM, Richard Welty wrote: however, there are unsigned routes in NY; state maintained routes which have designations but which do not have signage, and some county routes. Three states - Florida, Alabama, and Tennessee - have an unsigned state designation for every segment of U.S. Route (and Interstate in Florida). For example, Interstate 4 is also State Road 400, which appears on some maps but is not signed along I-4. But after I-4 ends at I-95 (SR 9), SR 400 continues as a short signed route to the end at US 1 (SR 5). ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] FYI - user going around changing highway refs just to put in the - and /
On 5/29/2011 4:08 AM, James Mast wrote: I just happened to notice this guy tonight was going around and editing the ref tags on highways in the US just to replace the space and put in the hyphen. (I noticed this when going to load the I-77 NC relation to add in speed limits I saw and wrote down on a recent trip to Charlotte because he changed a name of a way.) He's done in this in several places recently. It *seems* that all he does in the changesets is change the ref tags or expands the name tags fully (AVE Avenue). Of course, it's one of those guys that uses Potlatch2 and doesn't even put in a comment.. (I really hate those kinds of people). The user is 'chdr'. http://www.openstreetmap.org/user/chdr Oh Jesus Christ. http://www.openstreetmap.org/browse/way/11806201/history ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] Huge erroneous military landuse
http://www.openstreetmap.org/?lat=41.722lon=-75.094zoom=10layers=M I'm currently looking for the source; please report here if you find and fix it first. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Huge erroneous military landuse
On 6/3/2011 9:43 PM, Nathan Edgars II wrote: http://www.openstreetmap.org/?lat=41.722lon=-75.094zoom=10layers=M I'm currently looking for the source; please report here if you find and fix it first. Oh wow. http://www.openstreetmap.org/user/SimonSquare/edits contains the following: landuse=military on the US border religion=christian denomination=anglican landuse=cemetery on the UK leisure=park on France landuse=forest on Canada All fixed. Could this have been accidental, or is it likely to be deliberate vandalism? ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] US highway classification (trunk)
On 5/29/2011 3:32 AM, Nathan Mills wrote: On Sun, 29 May 2011 03:00:03 -0400, Nathan Edgars II wrote: Perhaps the best way to handle it would be to render a wider line if oneway=yes and not lanes=1 or if oneway=no/unset and lanes=4 or more. Thus divided highways would not need a lane count to be wider, but undivided roads would need to be tagged as having four lanes. That seems like it would be a reasonable way to handle it. I'm no mapnik expert, but I can see what I can figure out with the installation I have locally. Thank you. To this end, I've been systematically going through trunks in the US and adding lanes=* tags. This is of course useful even if nothing is done rendering-wise. By the way, if anyone wants to do some armchair mapping and needs suggestions, http://jxapi.openstreetmap.org/xapi/api/0.6/*[FIXME=dual carriageway] is a good starting point. Just make sure to correctly modify the lane count, relation roles, and anything else. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] is it just me
On 5/30/2011 4:06 PM, Steve Coast wrote: ... or does this map look like an older Texas osmarender layer screenshot plus a tilt-shift blur added? http://www.wm.com/contact-us.jsp The use of name=Interstate Highway 45;Gulf Freeway is a dead giveaway: http://www.openstreetmap.org/browse/way/46620267/history ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] US highway classification
On 5/29/2011 1:50 AM, Nathan Mills wrote: On Sun, 29 May 2011 01:00:25 -0400, Nathan Edgars II wrote: On 5/29/2011 12:37 AM, Nathan Mills wrote: US-441 between St. Cloud and Yeehaw Junction could easily be trunk by NE2's definition Nope, since any through traffic will be on the Turnpike. US 441 serves mainly only local and toll-avoiding traffic, and the latter is better-off cutting east to I-95 via US 192. It's actually faster to take 441 to Yeehaw and get on the turnpike there when traveling from eastern and southeastern Orlando to points south of Port St. Lucie. Even with the four-laning of 192? That's still a relatively small amount of traffic - people from a certain part of Orlando (eastern but not too far east) who want to go south. The principal route from Orlando to Miami is obviously the Turnpike, even if a there's a better route from a few parts of the Orlando area. Speaking of misclassification around Orlando, why on did you make Alafaya Trail south of Curry Ford primary? To distinguish it from the adjacent secondaries, which are similarly more major than the tertiaries. It's a balancing act, not an exact science. We're obviously getting nowhere here. You think trunk should be used for certain physical characteristics, and other people think it should be used for a slightly different set. I think a more systematic approach makes sense, classifying the most major routes in the system as trunk. Again, even under that view, there will be disagreement over where the line is drawn. But you seem to be rejecting that it's even a valid option, like if someone were to insist that primaries must have at least four lanes, or that tertiaries must have a centerline. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] US highway classification
On 5/29/2011 2:30 AM, Nathan Mills wrote: I think that trunk is more useful if it's prescriptive, more along the lines of a motorway than primary and below. If we aren't going to do that, we need to come up with another value for highway and get it rendered by default. It's something that map users expect, and we should therefore deliver. How many maps actually show these with a separate symbol, though? Looking through my 1990s road atlases, AAA and National Geographic (MapQuest) simply modify the symbol, keeping the color of the two-lane segments, while Rand McNally and Gousha (RIP) use one symbol for all divided highways, no matter how important (in Orlando, this includes Colonial, 17-92, OBT, and Michigan). (All four count center turn lanes as medians - see South OBT.) Unless you're proposing to mark all divided highways, rural and urban, as trunk, map users accustomed to road atlases won't expect your criteria. Perhaps the best way to handle it would be to render a wider line if oneway=yes and not lanes=1 or if oneway=no/unset and lanes=4 or more. Thus divided highways would not need a lane count to be wider, but undivided roads would need to be tagged as having four lanes. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] US highway classification
On 5/29/2011 5:16 PM, Paul Johnson wrote: subtle mass vandalism This is why I ignore Paul. Though I really wonder about this edit: http://www.openstreetmap.org/browse/way/14751094/history ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] US highway classification
On 5/29/2011 8:09 PM, Nathan Mills wrote: FSM knows the aerial imagery around here is outdated, to put it mildly. Try the NAIP imagery: http://wiki.openstreetmap.org/wiki/National_Agriculture_Imagery_Program ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] US highway classification
On 5/28/2011 3:39 PM, Nathan Mills wrote: On Sat, 28 May 2011 15:19:03 -0400, Anthony wrote: In my experience the difference between primary and trunk is generally very minor, to the point where I'm not sure there'd be any advantage at all in a router using it as a hint. But maybe that's just because the places where I use OSM are mapped wrong. Using NE2's criteria, trunk is not really any different from a routing standpoint than primary. No, trunk is to primary as primary is to secondary. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] US highway classification
On 5/28/2011 9:13 PM, Nathan Mills wrote: So you continue to assert that trunk is most useful if it essentially a duplicate of primary? Maybe a duplicate of your version of primary, but not mine. Take, as an example, US 84 in western Alabama. Why on earth did you change it to trunk when it's a terribly substandard road that isn't even a major route between cities of any real size? It's been rebuilt as a good-quality four-lane in Mississippi, eastern Alabama, and Georgia. Alabama has been a little slower at four-laning than its neighbors, but US 84 in western Alabama is still a direct route connecting the four-laned portions. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] US highway classification
On 5/28/2011 9:47 PM, Nathan Mills wrote: Another example is US-71 between Fort Smith and Texarkana. It is in fact the fastest route between Fort Smith and Texarkana, but it is terribly slow going. The fact that it is the fastest route between those two regionally important cities is adequately described by primary. Why, then, are we wasting trunk on something like that? I could ask you the same question: why are we wasting primary on what can be adequately described by trunk? ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] US highway classification
On 5/28/2011 10:52 PM, Nathan Mills wrote: Only if trunk has a meaning that implies that a road tagged trunk is somehow better than a road tagged primary, which it apparently does not, at least in some people's minds. If you're going to waste trunk on curvy two lane roads, a router may as well use distance or maxspeed as a better metric. As it stands, some of us are using trunk as more of a 'I know it when I see it' thing than something useful for routing purposes like motorway. Your same argument applies to the difference between primary and secondary, and that between secondary and tertiary. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] US highway classification
On 5/27/2011 12:32 AM, Nathan Mills wrote: Would I be correct in stating that tagging an undivided 2 lane (one lane in each direction) highways would be improper, even if a state calls the highway a trunk for planning purposes? Especially if it's in the middle of a town with a low speed limit. I understood trunk to be divided and limited access (but not fully grade-separated). No, trunk is also used for a major intercity highway that's not a freeway. Take a look at the UK and their network of trunks. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
