Re: [Talk-us] admin_level and COGs, MPOs, SPDs, Home Rule
I don't recall ever having been asked to put down county of residence on a federal form, though if I was I would have named the county I lived in rather than leaving it blank. State forms ask for town of residence if they ask for any such thing, since there are administrative reasons why this matters (e.g. when you register a vehicle, the DMV needs to know what town will be charging you property tax on it). The state is divided into 13 districts for courts, 4 of which exactly line up with 4 of CT's 8 counties: https://jud.ct.gov/directory/maps/JD/default.htm These courts are run by the state, though, so the court districts are not government entities any more than something like a DOT district would be. As you might guess, you report for jury duty only in the district where you live. The federal government definitely uses CT's counties for statistical purposes. Their borders are shown on census maps. Not sure about the GIS source you're referring to specifically. Connecticut's GIS data (https://portal.ct.gov/DEEP/GIS-and-Maps/Data/GIS-DATA) offers boundaries for both towns and counties, though they're separate shapefiles so I'm not sure how you'd say one is "between" the other and the state. It is worth noting though that maps published by the state often show town boundaries but not county boundaries (here's one example: https://portal.ct.gov/-/media/DOT/documents/dpolicy/policymaps/ref/hwymap18ps-Final.pdf?la=en) - which makes since administratively speaking, the towns are more important. On Tue, Jun 2, 2020 at 10:36 AM Greg Troxel wrote: > > Anthony Costanzo writes: > > > county. CT's counties have no associated government (anymore) but they > > are still commonly used for statistical purposes and they still have > > cultural relevance as well - you will hear references in casual > > conversations to Fairfield and Litchfield counties. Meanwhile ask any > > Connecticutter what COG they live in and most of them will probably > > answer "what's a COG". > > (t's nice to hear from someone in CT, as I have not really understood > things there, expect that it's obvious that the National Weather Service > thinks countries still exist.) > > Do you, as a CT resident, have to put down your county of residence on > any government paperwork, either state or federal? > > Or is there some notion that if a federal form asks for your county, you > can answer "That's a ridiculous question - CT has no counties" and that > is considered an OK answer? > > Do state forms uniformly decline to ask the question about county? > > How does jury duty work? When you are called, how are you sorted into > which courts you might ahve to go to? If you only have to go to courts > near you, vs the whole state, does that region align with historical > county boundaries? > > Does the federal government believe that there are no counties? Are CT > counties represented on the National Map and in the federal GIS > databases? > > Does the state of Connecticut publish maps or geodaata, and do they > think counties exist as an administrative thing between state and town? > > > (In MA, you are expected to put down a county, and jury duty is along > county lines - but we already established that MA still has counties > after talking about district attorneys, sherriffs etc.) ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] admin_level and COGs, MPOs, SPDs, Home Rule
Going to chime in here as someone who has lived the majority of his life in CT. I am quite familiar with CT's 8 counties and their geographic forms. But I only have a vague idea what a COG is and couldn't have told you offhand anything about where the boundaries between them are. I support the idea that counties in CT should be tagged the same as they are in other states. On the most basic level, this is simply consistent - why should CT be tagged differently than elsewhere? But even on a more nuanced level... the average person isn't concerned about what government functions are or aren't associated with a county. CT's counties have no associated government (anymore) but they are still commonly used for statistical purposes and they still have cultural relevance as well - you will hear references in casual conversations to Fairfield and Litchfield counties. Meanwhile ask any Connecticutter what COG they live in and most of them will probably answer "what's a COG". Great current example of this, look at the state's reporting on covid cases: https://portal.ct.gov/-/media/Coronavirus/CTDPHCOVID19summary5132020.pdf?la=en Page 2 shows current hospitalizations by county. No reference to COGs to be found. Thus, counties should retain their admin level tags, and COGs should be tagged less prominently. ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Alaska Highway AK-2 tagging
On Mon, Dec 16, 2019 at 7:45 PM Paul Johnson wrote: > On Mon, Dec 16, 2019 at 6:35 PM Anthony Costanzo wrote: >> >> All of AK 2 between Fairbanks and the Canadian border is paved. I can >> vouch for this personally. > > OK, so that's kinda putting more weight on the "primary" idea. Is most of it > a single carriageway freeway or a dual carriageway expressway? It's > been a long time since I've been there but i can't imagine it being more than > your typical middle-of-nowhere two-lane uncontrolled single > carriageway today. If that's the case, I feel like primary is the highest it > should be, and we should be considering more whether or not such a road > rises to primary instead of secondary (the lowest it should be, given it's > part of the primary state highway network in Alaska). Most of it is uncontrolled two-lane single carriageway. I don't have a strong opinion on whether the road is tagged as trunk or primary based on its own merits, however I do think the tags for the single-carriageway parts of AK 2 and YT 1 (and BC 97 for that matter) should match, whichever it is. These roads are functionally equivalent and physically similar. Given how these and other major single-carriageway roads in northern and western Canada are tagged as Trunk, tagging AK 2 as such would seem to be the option that defers to regional precedent. ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Talk-us Digest, Vol 145, Issue 6
> Date: Mon, 16 Dec 2019 18:21:59 -0600 > From: Paul Johnson > To: Joseph Eisenberg > Cc: "Eric H. Christensen" , "talk-us@openstreetmap.org" > > Subject: Re: [Talk-us] Alaska Highway AK-2 tagging > Message-ID: > > Content-Type: text/plain; charset="utf-8" > > On Mon, Dec 16, 2019 at 6:18 PM Joseph Eisenberg > wrote: > > > I would use highway=trunk the whole way for consistency. In Canada the > > connecting highway is also highway=trunk. This makes sense because AK 2 is > > linking Fairbanks, the largest city in this part of Alaska, with All the > > cities in Canada and the lower 48 States. > > > > That's kind of my thinking as to why it should be primary instead of > secondary (as typical for the US for state highways). Almost all of it's > not even paved, it'd be a hard stretch to call it an expressway (trunk). All of AK 2 between Fairbanks and the Canadian border is paved. I can vouch for this personally. ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Talk-us Digest, Vol 141, Issue 22
> Date: Thu, 29 Aug 2019 07:09:25 -0500 > From: Paul Johnson > > On Thu, Aug 29, 2019 at 6:40 AM Joseph Eisenberg > wrote: > > > That's probably not relevant for anywhere in the USA (even in Alaska > > the main highways between cities are paved... right?) but it's a > > reminder that we can certainly choose to do things in a way that makes > > sense for mapping the USA; we don't have to use the British or German > > standards. > > > > The larger cities in southern Alaska. Most are gravel, including a paper > interstate. I think Alaska's the last state to still have gravel state > highways. Alaska does have gravel state highways, but the main road between Fairbanks and Anchorage (Parks Highway, AK 3) is entirely paved, as is the entirety of the Alaska Highway itself and the roads connecting it to Fairbanks and Anchorage. So the statement "the main highways between cities are paved" is still true. That said, no, Alaska is not the last state to still have gravel state highways. Vermont still has a couple (part of VT 121 is gravel, for example). Montana has quite a few, including one section of a primary route (MT 38 over Skalkaho Pass). Utah has at least one (UT 261's Moki Dugway segment). Further examples likely exist. As for the original subject that spurred this discussion... I agree with the general sentiment that for any classifications other than motorway (which for US purposes is treated as being equal to "freeway"), the road's network importance matters more than its geometry. It may be fine for some sections of former US 66 to be tagged as trunk if they still function as major through roads, but since most sections do not function as such their classification should be lowered to the level appropriate for the given segment. ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] U turn restrictions in areas
On Tue, Aug 18, 2015 at 1:03 PM, Paul Johnson ba...@ursamundi.org wrote: That'd have to be some super-script, aware of sightlines What would you need besides elevation information in order to be able to more or less do that? ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Neighborhoods / Zillow
On 2013-06-15 6:51 PM, Serge Wroclawski wrote: There is a growing number of OSM folks in the United States (myself included) who believe that government provided boundry data should be used for data products such as rendered maps and geocoders, but do not belong in OSM's core dataset (which is built around the idea of improvements based on local, verifiable observation). Stevea replied: Again, this is not a one solution fits all situations problem, in this thread we have seen that over and over. Let's continue to allow OSM to capture observable data (including aerial and satellite imagery) and local government-produced data alike, whether as nodes or polygons, as appropriate. Many other features allow for both types of data structures, neighborhoods really are no different. One thing that seems to be missing from Serge's analysis is that much of government collected data is based on local, verifiable observation. If the government decides that Blah Neighborhood consists of the blocks bounded by Foo Street, Bar Road, Whatever River, and Whichamajig Railroad, and then they create a polygon geocoding that, the government has used local, verifiable observation to create that polygon. And they aren't going to get it exactly right. OSM mappers very well might come along and fix the border which corresponds to Whatever River, for instance. I'm not aware of any government node, way, or polygon data in OSM, whose presence is not disputed, where there isn't some tie to local, verifiable, observable, on-the-ground features. State borders are not truly defined by latitudes and longitudes. That is to say, even in places where a border is historically defined as the 40th parallel or some specific latitude, the true legal border does not lie exactly in that location. Someone may have historically measured the border incorrectly, and that measurement sticks as the legal definition. The latitude of the border may have shifted over time due to movements in the underlying ground or continental plate. I can't think of any border which is legally defined in terms of latitude and longitude. And any border which isn't legally defined in terms of latitude and longitude can be surveyed based on local, verifiable observation. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Neighborhoods / Zillow
It's not about mapping the sign, it's about mapping the neighborhood based on the sign. We don't map speed limit signs, we map the speed limits on the roads based on the signs. We don't map interstate signs, we map the name of the interstate. We don't map individual trees, we map forests. We don't map keep out, military area signs, we map military areas. On Mon, Jun 17, 2013 at 3:05 AM, Bryce Nesbitt bry...@obviously.com wrote: On Sat, Jun 15, 2013 at 7:22 PM, Nathan Mills nat...@nwacg.net wrote: The sort of signs in the link below are precisely the sort of thing we put in OSM, or at least have historically. https://www.cityoftulsa.org/**community-programs/** neighborhoods/neighborhood-**sign-guide.aspxhttps://www.cityoftulsa.org/community-programs/neighborhoods/neighborhood-sign-guide.aspx There is certainly no problem mapping the *sign*. The sign is verifiable objective. And the data is indexable and useful to map users, not just to mappers. ___ 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] Neighborhoods / Zillow
On Tue, Jun 11, 2013 at 2:58 PM, Martijn van Exel m...@rtijn.org wrote: Could we use either Geonames or Zillow to drive improvement to neighborhood name coverage in OSM? Using Zillow wouldn't be an improvement. Where I live, Zillow has the same incorrect information as the TIGER CDP (which I removed from OSM). I'd bet Geonames has equally inaccurate information. If you want large quantities of terrible neighbourhood information, just import the latest TIGER CDPs. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] parcel data next steps
On Fri, Feb 22, 2013 at 8:55 AM, Greg Troxel g...@ir.bbn.com wrote: Brian May b...@mapwise.com writes: I also think we need a little bit more sophisticated Data Catalog than a google spreadsheet. Email and a wiki page sounds good to me for coordination. Maybe we can bring it up in a Mappy Hour as well. And if there's enough of a need, we could do a separate parcels / address oriented Google Hangout. I always find it boggling that open data projects are willing to use google docs and google hangouts. It would be really nice to at least have the data in a free software/free culture compatible place like an OSM foundation server. I'm sure if someone puts a Google Docs or Google Hangout clone on an OSM foundation server that people would be happy to do this. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Turn restriction dispute
I would suggest inviting him back on the mailing lists, with the knowledge that being banned from the mailing lists means being banned from OSM. This situation where he is allowed to edit, but he isn't allowed to join the mailing lists to discuss his edits, is an utter failure. On Sun, Feb 10, 2013 at 12:30 AM, stevea stevea...@softworkers.com wrote: Russ, I second your vote/motion, not that anybody called for a second, or even that I am able to offer it. What I AM able to do is be civil and use the talk-us list, as it is our nationwide forum to discuss. There are plenty of other consensus understandings that might be loosely called rules which make up the fabric of OSM as a community. NE2 has again proven that he is either unwilling or unable to abide by those. Consequently, I think we should inform him that serious discussion of permanently banning him from OSM (this thread) is underway, and his behavior can either change for the better, or he can count on eventually being permanently banned. He has had plenty of opportunities to do so, and so I am not optimistic he will be around much longer. But if the community wants him, that can emerge as a consensus as well. His better (than nothing) edits are in a clear minority compared to the usual messes he makes. He DOES, for better or worse, stir controversy, which is why we discuss, which is part of the community. If, for that reason alone (that he is controversial), there are those who do not wish to ban him, speak up now, as you may (may) be able to make the case that we need somebody like him as an example of what to do with difficult contributors. I think it is unanimous that he is that, at least. I wouldn't miss him if he were gone, either. SteveA California He's banned from (at least) this list. Consequently, you cannot expect him to discuss this issue here. We had a discussion of whether to ban him from editing in the past, which never really got resolved. It just died out. Yes, he's done a lot of editing, and yes, some of his edits have been fruitful, but no, some of his edits have been less than helpful. I wouldn't miss him if he were gone. I vote, not that anybody called for a vote, to ask him to leave. -russ ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Addresses with no house number
This and many other annoying addressing schemes used to be common, but I thought the enhanced 911 system did away with this sort of thing. I did a quick google search and I can't find any address for that school though. On Fri, Jan 25, 2013 at 10:21 AM, Paul Johnson ba...@ursamundi.org wrote: A PO Box doesn't work for navigation purposes, which is what I thought we were focusing on. Oddly enough, the school does have a mailbox on Third near Pine. House numbers don't appear to be a thing in Council Hill, I didn't see anything there (though I was pushing a deadline and running behind, hence only focusing on Midway Schools, so I might have missed it; the schools were definitely was unnumbered). ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] Fwd: Anyone ever talked about adding more Land Ownership data to OSM?
On Mon, Jan 7, 2013 at 11:19 PM, Serge Wroclawski emac...@gmail.com wrote: That doesn't mean it can't be used alongside it. This land ownership data (assuming it's licensed properly) can be rendered on the same map as OSM data (there are many examples of using TileMill to mix data sources in just this way) and if the data is imported into a database, there can be queries made against the two sets, so it would be possible to see the land owner for a given POI, for example. [] In addition, much of the US has duplicate boundaries (places represented by areas, and nodes), arguments about the definition of spaces, disagreements in the data between municipal and census data, etc. Wouldn't the latter be precisely an argument as to why we *can't* just mix data sources? If the municipal data is sometimes right, and the census data is sometimes right, then doesn't OSM benefit by having people doing local surveys then taking the best of the municipal data, and the best of the census data, and merging it into a single data source? This idea that we can't improve government surveyed data is so obviously wrong. Importing and then improving upon government surveyed data is in fact *exactly* what we have been successfully doing in the US at least since the TIGER import. Sure, we aren't going to do a good job of putting individual owners of residences in OSM. But I don't think anyone is suggesting that. In fact, one probably useful compromise would be to not even include the property lines between individual residences. But the property lines between right of way and residences or parks or military areas or whatever, are useful, and represent something on-the-ground. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Difficult USA mapper(s)
On Fri, Nov 2, 2012 at 2:43 PM, Dave Hansen d...@sr71.net wrote: On 11/02/2012 09:09 AM, Anthony wrote: Might this not be part of the problem? Why do we allow someone to edit but not to contribute to the mailing list? Doesn't that promote exactly the type of behavior that some people are criticizing (i.e. editing without discussion). No, I don't think so. These problems persisted during times when Nathan was fully welcomed to this list. His presence on the list did not help avoid or resolve them. I don't get it. If the problem is that you don't like the way he edits, how is blocking him from the mailing list, but allowing him to edit, the proper solution? ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Difficult USA mapper(s)
On Fri, Nov 2, 2012 at 4:16 PM, Dave Hansen d...@sr71.net wrote: On 11/02/2012 01:11 PM, Anthony wrote: I don't get it. If the problem is that you don't like the way he edits, how is blocking him from the mailing list, but allowing him to edit, the proper solution? The times that I have moderated folks on this list it was for their behavior on this list. It had nothing to do with their editing except that the list discussions tended to have _originated_ from editing problems. Moderation is one thing. Important messages can still go through, if someone is moderated. But in this case he apparently was kicked off the list completely. I'm not sure what behavior caused such a severe sanction, but if it was warranted, then the person shouldn't be allowed to edit either. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Difficult USA mapper(s)
On Wed, Oct 31, 2012 at 10:11 AM, Richard Weait rich...@weait.com wrote: DWG has the administrative tools to block an account. What we don't have is a clear rule stating that we can block an account for being difficult. Questions for the US mapping community: 1) Do you want DWG to act on your behalf on this matter and or similar matters? No. DWG should act on behalf of OSMF. It's their servers, not ours. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Difficult USA mapper(s)
On Wed, Oct 31, 2012 at 7:52 PM, Russ Nelson nel...@crynwr.com wrote: So, as a generalized example of a specific instance that I have in mind, I added some tags to some ways which reflected data that anybody could verify from multiple sources with a little bit of research. I didn't put a source= tag because the source was from USGS topo data -- unquestionably public domain, backed up positionally with USGS ortho photos. Sometimes the data came from research, other times from site visits. A reasonably safe, uncontroversial edit. DUM felt it necessary to change the key of the tag to a different key, thus violating rule #1 by *changing* rather than *adding* a new tag with e's new key and the value I put into the tag. To make matters worse, this key is one that e invented and seems to be the sole user of. DUM has made this change to hundreds of ways that I know of, and probably thousands or more across the country, and without any consultation with others as far as I can find. That's a little bit too general. The key question is, which key was right? ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Difficult USA mapper(s)
I'm not sure there is anyone *banned* from the lists. On moderation, maybe, but so long as the emails are eventually going through that seems okay. On Wed, Oct 31, 2012 at 9:16 PM, James Mast rickmastfa...@hotmail.com wrote: If I think I know who this is all about, maybe he should be un-banned from talk-us so he might be able to defend himself at least? --James ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Difficult USA mapper(s)
On Thu, Nov 1, 2012 at 8:23 PM, Russ Nelson nel...@crynwr.com wrote: Anthony writes: The key question is, which key was right? No. Without getting too specific, my key was one of the most commonly-used keys, while e's key was one e invented. Without getting specific, how can we figure out who was right? ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Tags for Emergency Interstate
On Thu, Aug 2, 2012 at 5:29 PM, Brad Neuhauser brad.neuhau...@gmail.com wrote: http://en.wikipedia.org/wiki/Special_route#Emergency_detour_routes Also http://en.wikipedia.org/wiki/Detour#Permanent_detours ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Discardable TIGER tags
On Sun, Jul 29, 2012 at 1:21 PM, william skora skorasau...@gmail.com wrote: Tiger:tlid - Could be removed. I've had newbies ask me at mapping parties what it means, I haven't been able to answer them. I haven't seen any use for its inclusion at this point. FWIW, I strongly support removing tiger:tlid. However, I remember having a disagreement with others in the past about this, so I didn't bring it up. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Discardable TIGER tags
I'm all for upload_uuid being removed automatically. As for tiger:separated, is it possible to remove the tag only if it's set to no? The 1.4% that are set to something else should probably be reviewed manually. On Sat, Jul 28, 2012 at 3:33 AM, Toby Murray toby.mur...@gmail.com wrote: Some people may not even be aware of this but JOSM silently discards the created_by tag if it exists on any object you change and upload to the API. This tag was deemed unnecessary and counterproductive a long time ago and this is just a way of cleaning it out of the database as people edit. Not sure if Potlatch does anything like this. What do you think about adding a couple of TIGER tags to be silently dropped? As more attributes get added to things in OSM the tag list can get kind of big and annoying to look through, especially when some of them are of no real value. Specifically, I try to always do a modified search in JOSM before I upload and remove the tiger:separated and tiger:upload_uuid tags from things I have touched. I believe the tiger:separated tag was set on all residential or higher roads. 98.6% of the values are no and most of them are on minor streets where it is not really an interesting value. On the remaining roads it seems, in my experience, to be wrong a majority of the time anyway. So I see no value in this tag. I believe Dave Hansen said the UUID tag was useful during the TIGER import process to verify things and fix problems but I see no value in it now. It is such a large value that it takes up about 1 GB of space in the (uncompressed XML) planet file according to my calculations. As stated above, this would only delete the tags on objects that you have already modified in some way, not on everything you download. Are there any other tags that people feel should be automatically discarded? tiger:tlid and tiger:county seem mildly useful. What about tiger:cfcc and tiger:source? I don't currently remove those from my changesets but don't really see too much use for them either. Not really sure about the zip code tags. They seem like they could be useful but I am not aware of anything that actually uses them. If there is agreement, I will submit a patch to the JOSM devs and reference this thread. Toby ___ 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] Discardable TIGER tags
On Sat, Jul 28, 2012 at 3:54 PM, Toby Murray toby.mur...@gmail.com wrote: On Sat, Jul 28, 2012 at 2:16 PM, Anthony o...@inbox.org wrote: I'm all for upload_uuid being removed automatically. As for tiger:separated, is it possible to remove the tag only if it's set to no? The 1.4% that are set to something else should probably be reviewed manually. Might be possible but not the way I was hoping to implement it to match existing code. I'd say keep it, then. Has anyone ever used a tiger:separated tag to guide them to something that needs review? Yes. I have found a few yes values that were incorrect. The rest were pretty obviously dual carriageway on aerial imagery and the tag didn't really help me... And once it is mapped as dual carriageway in OSM the tag is misleading. That way no longer needs to be marked as separated since it now has two parallel ways representing it. I agree with removing ones that are marked incorrectly. I think it's harmful to remove ones that are marked correctly, though. And I don't see any way to automatically distinguish between the two. Anyway, that's my opinion. I think it's useful information. And the fact that it is sometimes incorrect is, in my opinion, a reason to keep it. I support removing tiger:uuid precisely because there is no definition of what the correct value should be. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Fwd: [OSM-dev] Licence redaction ready to begin
On Wed, Jul 11, 2012 at 10:20 AM, Kevin Kenny kken...@nycap.rr.com wrote: The culture of OSM seems to be veering from bad data happens, and when it does, other mappers fix it, to we have to protect the map from the mappers. Not from mappers, from disruptive bots. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Rails with trails
On Tue, Jul 3, 2012 at 4:43 PM, Nathan Edgars II nerou...@gmail.com wrote: On 7/3/2012 4:11 PM, Anthony wrote: What if it's an abandoned railway which is adjacent to a not-abandoned railway? Then it's already tagged as a rail trail. Which tag should be used, though? ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] Duplicate GNIS points
What's the proper thing to do when there are multiple GNIS ids for the same node? For instance: http://www.openstreetmap.org/?lat=35.131959lon=-106.516827zoom=18layers=M There are two identical nodes with identical coordinates: Saint Stephens United Methodist Church, gnis:feature_id=939399 Saint Stephen's United Methodist Church, gnis:feature_id=914456 Obviously these are meant to be the same point. What's the proper way to merge these together, since a node can't have two gnis:feature_id tags? Is it okay to just delete one? Another example has three entries: http://www.openstreetmap.org/?lat=35.081997lon=-106.61987zoom=18layers=M University Art Museum (gnis:feature_id=929517) Jonson Gallery of the University Art Museum (gnis:feature_id=929518) Jonson Gallery (gnis:feature_id=933296) -- Anthony J. Bentley ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] TIGER road expansion code
On Fri, May 11, 2012 at 11:20 PM, Serge Wroclawski emac...@gmail.com wrote: W and W Industrial Rd expands to West and W Industrial Road, since W is the direction_prefix, but the second W is unaccounted for, the script doesn't know if that is supposed to be W or West (and neither do I). The old script would have punted (since it's ambiguous which W should be expanded) the new one expands the first, since W is the direction_prefix. I think instead of focusing on these odd edge cases, we focus on the fact that we're now hitting the .0001% of roads that can't be expanded and accept that we're going to have to accept some small error rate, and so instead of focusing on fixing them, decide how we want to identify them). What percentage of roads, where the old script would have punted, are now being expanded correctly? What error rate is acceptable? ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] TIGER road expansion code
On Sat, May 12, 2012 at 12:41 PM, Serge Wroclawski emac...@gmail.com wrote: On Sat, May 12, 2012 at 7:05 AM, Anthony o...@inbox.org wrote: What percentage of roads, where the old script would have punted, are now being expanded correctly? The new script is up now. I used Maryland as a test case In Maryland the number went from 21 roads it couldn't expand to 1. But that's 20 out of the ~70k it *was* able to expand, so either you could say it handles 99.5% of all previously unexpandable roads, or it handled .0003% of all total roads. By roads you mean unique names? In any case, if it's only 20 for Maryland, it's probably a low enough number for the country that they can all be manually reviewed. What error rate is acceptable? As low as possible So any error rate is acceptable? ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Fixing TIGER street name abbreviations
On Sat, May 12, 2012 at 4:21 PM, andrzej zaborowski balr...@gmail.com wrote: It checks suffixes starting from the end, so if you have St something St E or St something St East, it'll only check E or East and then St and then stop because something is not a known suffix. So Calle Ave Maria will be expanded to Calle Avenue Maria? ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Fixing TIGER street name abbreviations
On Sat, May 12, 2012 at 4:47 PM, Anthony o...@inbox.org wrote: On Sat, May 12, 2012 at 4:21 PM, andrzej zaborowski balr...@gmail.com wrote: It checks suffixes starting from the end, so if you have St something St E or St something St East, it'll only check E or East and then St and then stop because something is not a known suffix. So Calle Ave Maria will be expanded to Calle Avenue Maria? Nevermind. No. It won't. Because Maria is not a known suffix, right? ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] TIGER road expansion code
On Sat, May 12, 2012 at 5:27 PM, Nathan Edgars II nerou...@gmail.com wrote: It's worth noting that any errors are already there as errors in the TIGER tags. So, had the TIGER import been done properly in the first place, these errors would be in the name tags as well. This seems to be the case. The code checks for tiger:name_base, and if it can't find it, then it doesn't make any changes. (Can someone confirm this? http://www.openstreetmap.org/browse/way/16011770 will be untouched, right?) If so, this is good, but it does mean that road names are going to get out of sync, if, for instance, tiger:name_base was removed from some of the ways and not removed from others. This will complicate later fixes/enhancements. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] TIGER road expansion code
On Sat, May 12, 2012 at 6:01 PM, Mike N nice...@att.net wrote: On 5/12/2012 5:54 PM, Anthony wrote: If so, this is good, but it does mean that road names are going to get out of sync, if, for instance, tiger:name_base was removed from some of the ways and not removed from others. This will complicate later fixes/enhancements. This also happens long term as people create roads from scratch and don't know about the abbreviation rule when starting. Yeah, it does, but we're not discussing that right now. If we can avoid adding tens of thousands of more of these cases, we should. And it seems we can. Even a simple rule like assuming that two connected ways with the same name are the road would be a useful addition. Something more complicated, especially something that looks at the history, would be even better. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Fixing TIGER street name abbreviations
On Thu, May 10, 2012 at 11:45 PM, Dale Puch dale.p...@gmail.com wrote: Clarity! The abbreviations are just that, they mean the full word, and are spoken that way, but written and displayed as the abbreviation. I also disagree I have never know anyone that said whatever A V E they do not spell it out, they say the word the abbreviation stands for. Same for St, Dr ect. What are you disagreeing with? I've known streets that were called Whatever Ave (Rhymes with Whatever Have). Not Whatever Avenue. And certainly not Whatever A V E. It is a LOT easier to abbreviate from the full word than to go the other way. Not really. Is 1515 South West Shore Boulevard, Tampa abbreviated 1515 S West Shore Blvd, Tampa, or is it abbreviated 1515 S W Shore Blvd, Tampa? If you want the answer, ask usps.com. The only way to capture the full information is to have additional tags telling you what the base is. And if you do that, abbreviating or not abbreviating doesn't matter. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Fixing TIGER street name abbreviations
On Fri, May 11, 2012 at 9:45 AM, Anthony o...@inbox.org wrote: The only way to capture the full information is to have additional tags telling you what the base is. And if you do that, abbreviating or not abbreviating doesn't matter. And if you want to avoid tremendous redundancy, the way to that is with some sort of street relations. Each way should contain information about the way, the whole way, and *nothing but the way*. Including base_name information in every instance of the way fails 3NF. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Fixing TIGER street name abbreviations
On Fri, May 11, 2012 at 12:26 PM, Minh Nguyen m...@1ec5.org wrote: On 2012-05-11 6:45 AM, Anthony wrote: The only way to capture the full information is to have additional tags telling you what the base is. And if you do that, abbreviating or not abbreviating doesn't matter. That's similar to how the tiger:* tags are structured, and it's the subject of a proposal on the wiki: http://wiki.openstreetmap.org/wiki/Proposed_features/Directional_Prefix_%26_Suffix_Indication Well, yes, we should find a way to separate out the parts of the name. In addition to facilitating abbreviation, it also facilitates translation. We also should include pronunciation information. But first we need street relations. It turns out some people already did research into ways to structure a database which minimizes the inconsistencies we currently have in the OSM database. It's called database normalization. As it turns out, the current method of putting names on ways already fails to even be in first normal form. Some ways represent more than one road. The solution is to use relations. http://wiki.openstreetmap.org/wiki/Relations/Proposed/Street is somewhat of a good proposal, though I have a little bit of trouble with the wording. We shouldn't include Any Tag that applies to all parts of the road, but only to those tags which apply to the entire road as a whole. In other words, we'd include goods=no if there were a law saying no commercial vehicles are allowed on Whatever Parkway, but not just because all the ways happen to have goods=no tags. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Fixing TIGER street name abbreviations
On Fri, May 11, 2012 at 1:35 PM, Alan Mintz alan_mintz+...@earthlink.net wrote: At 2012-05-10 19:40, Anthony wrote: On Thu, May 10, 2012 at 10:25 PM, Mike N nice...@att.net wrote: The only question is what to do about those cases where it's only referred to locally as 'Ave', and the postal service would refuse letters addressed to 'Avenue'. The postal service would refuse letters addressed to Avenue in some instances? Unless this quote is out of context, that seems ridiculous (in the US). I very well may have misquoted Mike North. I'm not sure what he was trying to say. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Fixing TIGER street name abbreviations
On Thu, May 10, 2012 at 3:28 PM, Dale Puch dale.p...@gmail.com wrote: As a quick and dirty test I took Florida and Illinois road data from cloudmade. A simple replace of the top 7 or so suffixes at the end of the name an with a space in front of it resulted in over 700,000 name changes for those 2 states alone, and that did not include all the names with cardinals (prefix and suffix) that need expanding. It was well over 80% of the names. Anyone arguing that not scripting these changes should spend a day or two trying to do that by hand and get back to us how they feel afterwards. You seem to be assuming all the changes are positive. What happened to the on the ground rule, anyway? ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Fixing TIGER street name abbreviations
On Thu, May 10, 2012 at 10:25 PM, Mike N nice...@att.net wrote: On 5/10/2012 10:19 PM, Anthony wrote: What I'm questioning is why it doesn't apply. If the people call it Whatever Ave, shouldn't the data read Whatever Ave? Most of the US wouldn't call it 'Whatever Ave'; when spoken, it would be 'Avenue'. Having it expanded makes programs with spoken directions much more accurate. Depends on what street you're talking about. I've certainly lived in places where the vast majority of the locals called it Whatever Ave, and not Whatever Avenue. Most of the US...wouldn't talk about the street at all. The only question is what to do about those cases where it's only referred to locally as 'Ave', and the postal service would refuse letters addressed to 'Avenue'. The postal service would refuse letters addressed to Avenue in some instances? ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Fixing TIGER street name abbreviations
On Wed, May 2, 2012 at 7:28 AM, Mike N nice...@att.net wrote: On 5/1/2012 11:49 PM, Anthony wrote: That assumes that the TIGER tags will always be present to assist with proper automatic expansion. I'm not sure what you mean, because I am not making that assumption at all. You mentioned use of the history to access the TIGER tags. Yes, I said if a bot is smart enough to go through the history tags, then this *does* provide an advantage over data consumers doing it themselves. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Fixing TIGER street name abbreviations
On Wed, May 2, 2012 at 12:01 PM, Serge Wroclawski emac...@gmail.com wrote: 2) My human error rate estimation of 1/1000 seems entirely reasonable. Think typos, or misreading. I'm sure we see error rates that high now in OSM and we find them acceptable. A computer that's acting conservatively will actually produce far lower error rates! But its error rates are potentially much more annoying. Doctor Martin Luther King Bolevard is one thing. Drive Martin Luther King Boulevard is another. The latter will be much more difficult to find at a later date and flag for review. Maybe you won't make that particular error, but you're going to have to be really careful to avoid making any errors like it. And relying on the TIGER tags may or may not help. I wouldn't be surprised if many of the TIGER tags themselves are screwed up, based on the kinds of mistakes I've seen in TIGER data. Anthony ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Fixing TIGER street name abbreviations
On Tue, May 8, 2012 at 11:31 PM, Anthony o...@inbox.org wrote: Doctor Martin Luther King Bolevard is one thing. Drive Martin Luther King Boulevard is another. And if we're going to make so many mistakes (1/1000 means thousands of mistakes), I'd rather it just be left as Dr Martin Luther King Blvd. Yes, we can't stop people from making mistakes. But we can refuse to allow thousands of mistakes to be added, for the sake of removing abbreviations which aren't hurting anyone in the first place. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Fixing TIGER street name abbreviations
On Mon, Apr 30, 2012 at 11:28 PM, Serge Wroclawski emac...@gmail.com wrote: On Mon, Apr 30, 2012 at 8:14 PM, Paul Johnson ba...@ursamundi.org wrote: There have been some limited automated expansions, though they can be problematic, because abbreviations can mean many possible things. Expanding abbreviations requires a bit of a human touch. Creating abbreviations in the renderer when so desired, not so much. This is true, but if one is talking about the TIGER data, there are a number of hints that can make this problem virtually nil. There's a tag tiger:name_type key that contains the value of the expandable name section, eg. St or Ln or Pky. AFAIK these are always expandable to Street, Lane and Parkway. And of course one must only expand the name_tag value if it's the last component of the name string, eg. Ln Ln should be Ln Lane. This should be fairly easy to construct in a regex, but one should be careful of it. Those two rules should eliminate a vast majority of expansion issues. If we only expand TIGER data, then it should be a fairly straightforward process. Of course such a script should be peer reviewed and tested, but I'm confident that the error rate will be very low. I guess this would be okay, so long as it gets peer reviewed and tested by a group including you. And for those few exceptions where the expansion is wrong, a human review process will turn this up and make it fairly correctable. In fact, I'd argue that the problems won't be subtle, making them easy to spot and fix. How would the human review process work? Isn't it better to do the review *before* editing the database? In return, we'll save hundreds, maybe thousands of man hours doing expansions. Useless expansions, though. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Fixing TIGER street name abbreviations
On Tue, May 1, 2012 at 1:06 PM, Serge Wroclawski emac...@gmail.com wrote: The other point that's being missed is that we as a community already accept an error rate in our data that's far larger than any potential mistake rate on a well written script. If the script makes one error in 1000 streets, it will be doing a better job than a vast majority of manual mappers, and like manual mappers, they can be corrected. If someone manually expanded 1,000,000 street name abbreviations, and made 1,000 mistakes, it would not be acceptable. If they were doing something more useful than expanding street name abbreviations, fine. But expanding street name abbreviations, according to a very simple heuristic which can easily be done at the preprocessing stage, is not very useful. If this is going to be done, I hope the error rate is much smaller than 1 in 1,000. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Fixing TIGER street name abbreviations
On Tue, May 1, 2012 at 1:18 PM, Nathan Edgars II nerou...@gmail.com wrote: On 5/1/2012 12:59 PM, Anthony wrote: Automatically expanding abbreviations is a terrible idea. If an abbreviation is unambiguous, then it can be expanded during the preprocessing step. If, on the other hand, it is ambiguous, then you are turning ambiguous data into incorrect data, which certainly diminishes the data. Not quite. We have various TIGER tags that break the name into pieces, and allow automated expansion where the name field may be ambiguous. (Though occasionally these tags are wrong.) I'm not sure what you're disagreeing with. Either it is unambiguous (due to TIGER tags or whatever), and therefore can be done during the preprocessing step. Or it is ambiguous, and needs human intervention/review. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Fixing TIGER street name abbreviations
On Tue, May 1, 2012 at 1:26 PM, Nathan Edgars II nerou...@gmail.com wrote: On 5/1/2012 1:23 PM, Anthony wrote: On Tue, May 1, 2012 at 1:18 PM, Nathan Edgars IInerou...@gmail.com wrote: On 5/1/2012 12:59 PM, Anthony wrote: Automatically expanding abbreviations is a terrible idea. If an abbreviation is unambiguous, then it can be expanded during the preprocessing step. If, on the other hand, it is ambiguous, then you are turning ambiguous data into incorrect data, which certainly diminishes the data. Not quite. We have various TIGER tags that break the name into pieces, and allow automated expansion where the name field may be ambiguous. (Though occasionally these tags are wrong.) I'm not sure what you're disagreeing with. Either it is unambiguous (due to TIGER tags or whatever), and therefore can be done during the preprocessing step. Or it is ambiguous, and needs human intervention/review. The TIGER tags are not exactly standard OSM tags that belong in the database. Better that we get rid of them at the same time as we expand abbreviations. On that point, I strongly agree. And actually, if the bot is going to be smart enough to look at the history, to find deleted TIGER tags, then maybe there is some advantage to doing this during the preprocessing step (which would often not have access to history data). ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Fixing TIGER street name abbreviations
On Tue, May 1, 2012 at 1:31 PM, Anthony o...@inbox.org wrote: And actually, if the bot is going to be smart enough to look at the history, to find deleted TIGER tags, then maybe there is some advantage to doing this during the preprocessing step (which would often not have access to history data). What I mean is that, if the bot is going to look at the history, then there would be an advantage to letting the bot run. But I am assuming this could be done with much less than a 1/1000 error rate. 1/10,000 would maybe be acceptable. 1/100,000 would be okay. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Fixing TIGER street name abbreviations
On Tue, May 1, 2012 at 1:36 PM, Mike N nice...@att.net wrote: On 5/1/2012 1:21 PM, Anthony wrote: The preprocessing step between downloading the data from OSM and doing something with it. That assumes that the TIGER tags will always be present to assist with proper automatic expansion. I'm not sure what you mean, because I am not making that assumption at all. And I'd rather have the US data in line with the world-wide OSM data where it makes sense. That way the US can consume OSM US data with tools developed worldwide, without the tool writers needing to implement US-specific rules. After analysis, most of the US opinions fall on the side of no abbreviations. I don't think anyone in this thread is arguing against expanding abbreviations. The question is whether or not it's okay for a bot to expand abbreviations. And to a large extent that depends on how accurate the bot will be. If the bot is sure to be 100% accurate, then hey, no problem. But I don't believe that is the case. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Fixing TIGER street name abbreviations
On Tue, May 1, 2012 at 1:41 PM, Ian Dees ian.d...@gmail.com wrote: On Tue, May 1, 2012 at 12:26 PM, Nathan Edgars II nerou...@gmail.com wrote: The TIGER tags are not exactly standard OSM tags that belong in the database. Better that we get rid of them at the same time as we expand abbreviations. Although the tiger:* keys aren't standard, the information they store is very useful. There are plenty of people that might want to know the different parts of a road name, so we should simply rename these tags instead of completely blowing the data away. I guess that's okay too, though personally I get so annoyed by the redundant data (*) that I couldn't be bothered. Why street relations never caught on is beyond me. (*) I.E. adding base_name=Main to the 100 different ways that Main Street is split up into. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] [OSM-talk] Check my junctions - looking for someone to review my plates of spaghetti -- responding to feedback
On Tue, Jan 24, 2012 at 7:31 AM, Nathan Edgars II nerou...@gmail.com wrote: I don't know about Pennsylvania, but here in Florida a single white line does not legally prevent crossing. But even if it did, we don't map a double yellow as a median. *You* don't map a double yellow (I assume you mean a double double yellow) as a median. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] [OSM-talk] Check my junctions - looking for someone to review my plates of spaghetti
On Mon, Jan 23, 2012 at 11:20 PM, Nathan Edgars II nerou...@gmail.com wrote: On 1/23/2012 9:52 PM, dies38...@mypacks.net wrote: Yuck. A separate way should not be used for a turn lane (unless that lane is separated by barriers or maybe a wide striped-off area). Corollary: a separated right-turn lane begins and ends approximately where the traffic island begins and ends, not where the separate lane begins and ends. Better fix this: http://www.openstreetmap.org/?lat=27.987056lon=-82.5464zoom=18layers=M ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] [OSM-talk] Check my junctions - looking for someone to review my plates of spaghetti -- responding to feedback
On Tue, Jan 24, 2012 at 8:45 AM, Nathan Edgars II nerou...@gmail.com wrote: On 1/24/2012 8:33 AM, Anthony wrote: On Tue, Jan 24, 2012 at 7:31 AM, Nathan Edgars IInerou...@gmail.com wrote: I don't know about Pennsylvania, but here in Florida a single white line does not legally prevent crossing. But even if it did, we don't map a double yellow as a median. *You* don't map a double yellow (I assume you mean a double double yellow) as a median. No, I mean a double yellow. As in do not pass. That doesn't legally prevent crossing either. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] [OSM-talk] Check my junctions - looking for someone to review my plates of spaghetti -- responding to feedback
On Tue, Jan 24, 2012 at 10:32 AM, Nathan Edgars II nerou...@gmail.com wrote: On 1/24/2012 10:24 AM, Paul Johnson wrote: Florida's driver's manual says that crossing any double-white line is prohibited. You're confusing double white with single white. No, I'm not. And I agree with Mikel that this sort of reply is unproductive. The fact that double yellow means crossing the centerline markings for passing is prohibited and not crossing the centerline markings is prohibited is quite significant. You can, if it is safe and not otherwise prohibited, make a left turn across a double yellow. You can, if it is safe and not otherwise prohibited, make a U-turn across a double yellow. The only sense in which a double yellow prevents crossing if there are no intersections nearby, is if any place where someone might turn is called an intersection. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Address improvement through imports?
Voter records are a good idea. And business registration records / business tax records also. I think getting the business addresses is going to be the harder task. But maybe if we merge data from multiple sources we can get a decent portion of it. On Mon, Nov 14, 2011 at 10:22 PM, Metcalf, Calvin (DOT) calvin.metc...@state.ma.us wrote: To suplimnett it you could use the voter file, it'll have all the residential addresses, while not usefull on its own it'll give you fairly acurate ranges for residential streets. in america its public domain, getting it can be tricky and usually involves requesting it from towns Sent with Verizon Mobile Email ---Original Message--- From: Anthony o...@inbox.org Sent: 11/14/2011 9:36 pm To: Bryce Nesbitt bry...@obviously.com Cc: talk-us@openstreetmap.org Subject: Re: [Talk-us] Address improvement through imports? On Sun, Nov 13, 2011 at 10:45 PM, Bryce Nesbitt bry...@obviously.com wrote: The parcel data is a superset of address data... Not when there's more than one address to a parcel, which around here unfortunately is a common occurrence in exactly the places where address information is most useful (strip malls and such). ___ 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] Address improvement through imports?
On Sun, Nov 13, 2011 at 10:45 PM, Bryce Nesbitt bry...@obviously.com wrote: The parcel data is a superset of address data... Not when there's more than one address to a parcel, which around here unfortunately is a common occurrence in exactly the places where address information is most useful (strip malls and such). ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Address improvement through imports?
On Mon, Nov 7, 2011 at 10:25 AM, Steven Johnson sejohns...@gmail.com wrote: The Census Bureau, through their partnerships and liaisons with state local govt, are acutely aware of the need and importance of address data. They are in fact open to finding ways to make the data available and still protect the privacy of individuals. It will likely take a while to get a change in policy, stand up some mechanism to provide data, create protocols for privacy protection, etc. but the fact that they're seriously considering these changes is progress. The problem is not the policies, the problem is the law. If the problem were the policies, then an FOIA request would work. A list of all addresses does not violate the privacy of individuals. If that were all the law said, then I would try the request. But the law goes further than saying the Census Bureau cannot violate the privacy of individuals. It says the Census Bureau cannot distribute raw data reported by or on behalf of individuals. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Address improvement through imports?
On Sun, Nov 6, 2011 at 2:56 PM, Steven Johnson sejohns...@gmail.com wrote: Doubt very seriously a FOIA request would work. Since the data are subject to Title XIII restrictions, it will likely take an act of Congress to make them available. What exactly are the restrictions? I don't see how a list of all addresses, without any additional information, is a privacy issue. The fact of the matter is such a list *is already published by the USPS*, but *that* version of it isn't public domain. I'm tempted to give it a try, and even appeal if my request gets denied. Any idea where I would send the request? ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Address improvement through imports?
On Sun, Nov 6, 2011 at 8:19 PM, Anthony o...@inbox.org wrote: On Sun, Nov 6, 2011 at 2:56 PM, Steven Johnson sejohns...@gmail.com wrote: Doubt very seriously a FOIA request would work. Since the data are subject to Title XIII restrictions, it will likely take an act of Congress to make them available. What exactly are the restrictions? I don't see how a list of all addresses, without any additional information, is a privacy issue. The fact of the matter is such a list *is already published by the USPS*, but *that* version of it isn't public domain. I'm tempted to give it a try, and even appeal if my request gets denied. Any idea where I would send the request? Actually my biggest worry is that they'll approve the request, and then tell me it's going to cost tens of thousands of dollars in fees to get it. Maybe I'll start with just a small portion of the state. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Address improvement through imports?
Hmm... Baldridge v Shapiro, a Supreme Court ruling: The unambiguous language of the confidentiality provisions of the Census Act -- focusing on the information or data that constitutes the statistical computation -- as well as the Act's legislative history, indicates that Congress contemplated that raw data reported by or on behalf of individuals, not just the identity of the individuals, was to be held confidential, and not available for disclosure. The master address list sought by Essex County is part of the raw census data intended by Congress to be protected under the Act. And under the Act's clear language, it is not relevant that municipalities seeking data will use it only for statistical purposes. This case was over something a little different...but that's some strong dicta. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Address improvement through imports?
On Sun, Nov 6, 2011 at 9:52 PM, Mike Thompson miketh...@gmail.com wrote: Any idea where I would send the request? http://www.census.gov/po/www/foia/foiaweb.htm Good luck. Census will fight the request. Earlier comments about Title XIII apply. Based on that Supreme Court ruling, and the actual text of the law, I'm not going to bother. Thank you, though. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Address improvement through imports?
On Fri, Nov 4, 2011 at 1:04 AM, Val Kartchner val...@gmail.com wrote: As long as we have all of the addresses, we could use satellite data to align them with houses. Is this the type of data we have in TIGER? It isn't, but I wonder whether or not a FOIA request for a list of all addresses (*without* geolocation information) would be possible. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Address improvement through imports?
On Wed, Nov 2, 2011 at 11:36 PM, Serge Wroclawski emac...@gmail.com wrote: Anthony, my recollection is you're banned from editing our map, so don't worry about how we split or don't split the roads. I still edit the map. I am not banned. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Address improvement through imports?
On Wed, Nov 2, 2011 at 11:40 PM, Michal Migurski m...@stamen.com wrote: I'm not a fan of splitting ways Maybe we should remove the ability from the editors, then. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Address improvement through imports?
On Wed, Nov 2, 2011 at 12:02 AM, Richard Welty rwe...@averillpark.net wrote: On 11/1/11 11:50 PM, Martijn van Exel wrote: Is there a way for mapnik to only render features of a certain class if there's not more than a certain density of them? i don't know about that, but i certainly think that the current default mapnik rendering for openstreetmap.org is showing us too much addressing detail. i'm not sure what showing the address interpolation ways here really adds to the mapnik rendering for the average visitor to OSM It lets them know the address interpolation ways are there in the data. Isn't the average visitor to OSM a mapper? ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Address improvement through imports?
On Wed, Nov 2, 2011 at 9:35 AM, Steven Johnson sejohns...@gmail.com wrote: Up to now, we've been talking largely about addresses as point features. However, one thing I think would be good to have is block ranges on streets. What I mean is a tag that indicates this is the 1000 block, the 1100 block, the 1200 block, etc. Rather than being a point feature attached to buildings, it would be a tag associated with the way. It would be much easier to implement, make the map renderings much more presentable at small scales, and provide better address utility than presently exists. addr:inclusion=potential - The complete range of all possible address numbers on a block, although there may not physically be enough room on the block for that range of house numbers. Interpolation data from US TIGER is an example where Geo-location would only be as near as one block. http://wiki.openstreetmap.org/wiki/Key:addr:interpolation ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Address improvement through imports?
On Wed, Nov 2, 2011 at 11:24 AM, Ian Dees ian.d...@gmail.com wrote: Address range information can be derived from existing TIGER data quite simply. I'm not sure how simple it is. It's simple in cases where TIGER data matches up very closely with OSM data. But that isn't universally true. And where it doesn't match up very closely, chances are high that the TIGER data is out of date or incorrect. Which brings me to the conclusion that there's no point in importing TIGER address information. A geocoder can simply try to find the address in OSM, and fall back to TIGER if the address isn't in OSM. Then, once the lat/lon is obtained (possibly from the external TIGER database), it can simply pass the lat/lon back into OSM for routing purposes (possibly along with a warning that TIGER data was used, which is quite likely to be be out of date and/or inaccurate. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Address improvement through imports?
On Wed, Nov 2, 2011 at 10:38 AM, John F. Eldredge j...@jfeldredge.com wrote: This idea, of tagging address ranges within blocks, sounds like a good idea to me. Some cities, such as Louisville, KY, put address ranges on street signs, which would make gathering such information easy in those cities. Sounds good to me. Use addr:inclusion=potential. And put the info on separate ways which cover the actual address locations, not on the roads. If you're going to be surveying street signs by hand, it's really not that much extra work. (But hey, even if you insist on putting the address information on the streets themselves, you can still use addr:inclusion=potential, and it still won't cause any harm.) ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Address improvement through imports?
On Wed, Nov 2, 2011 at 12:19 PM, Martijn van Exel m...@rtijn.org wrote: I'm all for not importing data where there's existing data people can use, but in the case of TIGER addresses you could actually make a point for importing: OSM could be a platform for improving that address data (like it should be for the GNIS points). 'All we need' is a suitable microtasking platform. I can't speak for other locations, but here in Florida there is much better address information available from the counties than that available from TIGER. So if you're going to build a suitable microtasking platform for Florida, use the county data, not TIGER :). ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Address improvement through imports?
On Wed, Nov 2, 2011 at 3:17 PM, Toby Murray toby.mur...@gmail.com wrote: On Wed, Nov 2, 2011 at 11:14 AM, Anthony o...@inbox.org wrote: Which brings me to the conclusion that there's no point in importing TIGER address information. A geocoder can simply try to find the address in OSM, and fall back to TIGER if the address isn't in OSM. Then, once the lat/lon is obtained (possibly from the external TIGER database), it can simply pass the lat/lon back into OSM for routing purposes (possibly along with a warning that TIGER data was used, which is quite likely to be be out of date and/or inaccurate. I believe this is exactly what Nominatim currently does, minus the warning part. So address ranges are already a solved problem. All we're talking about here is importing *better* address data so that Nominatim doesn't have to fall back to TIGER. Excellent. Looking back it seems like I might have been the one who brought up TIGER (although in a quotation, where it was used as an example). I checked out the page, and the source I know of for Florida is already listed. It's especially good for single family residences, but it is parcel-based data, so it is of limited use in locations where there is more than one address at a parcel (which, unfortunately, is the case for many of the business locations which people are likely to be looking for). It's more exact than TIGER, but I still think it should be imported manually if at all. And really you can use the same arguments against importing it as you can use for importing TIGER. Nominatim (et al) could just use the Florida county data as a separate database. There's only an advantage to integrating it into OSM as is unless you're going to manually verify it as you import it. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Address improvement through imports?
On Wed, Nov 2, 2011 at 4:26 PM, Serge Wroclawski emac...@gmail.com wrote: Folks, Do you realize: 1. We already have a method for address interpolation. It's called addr:interpolation There's no need for new tags. Yes. In fact, I mentioned it above along with a link (http://wiki.openstreetmap.org/wiki/Key:addr:interpolation). addr:inclusion=potential can be used with addr:interpolation to indicate the that the range represents *potential* addresses, and not actual addresses. 2. Cutting ways into blocks would make for bedlam. Why? ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Address improvement through imports?
On Wed, Nov 2, 2011 at 6:44 PM, Ian Dees ian.d...@gmail.com wrote: I think it's reasonable to take a small bite out of that huge task by using data that was previously crowdsourced (via taxpayer money) and ask as many members of the current OSM community in the US to manually add the data and verify it. I don't think that's an import in the sense of CanVec or TIGER or NHD or coastlines. I think that's a computer-assisted manual edit. I agree. Actually, I'd say it's not an import at all. I'm opposed to imports of address data. But I'm not at all opposed to computer-assisted manual edits. On the other hand, I don't think you're going to get very far with computer-assisted manual edits. As you said, even after we celebrate our 10,000th US-based active editor we'd still have to convince every single one of them to go survey 17,000 addresses. But hey, prove me wrong :). ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Address improvement through imports?
On Wed, Nov 2, 2011 at 9:59 PM, Anthony o...@inbox.org wrote: On Wed, Nov 2, 2011 at 9:55 PM, Mike N nice...@att.net wrote: On 11/2/2011 9:46 PM, Anthony wrote: 2. Cutting ways into blocks would make for bedlam. Why? If there's no difference between the blocks except for addressing, it adds a needless extra step to map corrections. Instead of selecting an entire street with a single click to correct the name, change attributes etc, each block would need to be selected, one at a time while checking that the selection is correct by verifying that names within the selection all match. I guess, but there are already so many reasons to split ways that I think you're fighting a losing battle. A better solution would be to adopt something like street relations, so that the name of a road isn't duplicated on every single way in the first place. On the other hand, this does raise a problem in the opposite direction. If you put the potential address information on the way, what happens when you need to split the way? So, I guess I agree that putting the address information on the way is not a good solution, but for the opposite reason as the one given :). ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] One of the strangest TIGER screwups I've seen
On Sun, Oct 23, 2011 at 3:32 PM, Richard Welty rwe...@averillpark.net wrote: On 10/23/11 3:02 PM, Nathan Edgars II wrote: On 10/23/2011 2:59 PM, Richard Welty wrote: from Mike's comment, the name appears to likely be correct local usage. Mike's link is from Wisconsin; the way is in Connecticut. ok, fine, but you're still making an assumption that may turn out to be wrong. In this case it seems to be a safe assumption, though. Can someone check TIGER 2010 to see what it currently says? ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] One of the strangest TIGER screwups I've seen
On Sun, Oct 23, 2011 at 3:42 PM, Anthony o...@inbox.org wrote: Can someone check TIGER 2010 to see what it currently says? I just did. It's TLID 611694054. The name has been removed. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Signed shared roadway
On Sat, Oct 22, 2011 at 9:13 PM, Richard Welty rwe...@averillpark.net wrote: On 10/22/11 8:33 PM, Metcalf, Calvin (DOT) wrote: This is something that I've been wondering in ma, would on road sign posted routes (there is a sign on a post next to the road) be tagged differently the on road shared use (there is a picture of bicycle in the lane but cars also use it) Sent with Verizon Mobile Email i think they should be tagged differently. if there's just a black on yellow sign saying share the road then cyclists should stay to the right. Only if the outside lane is about 14 feet wide or wider, and has no parking to the right of it (i.e. not very often). ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Signed shared roadway
On Sat, Oct 22, 2011 at 9:30 PM, Richard Welty rwe...@averillpark.net wrote: this text may be found in section 1234 on this page: https://www.nysdot.gov/divisions/operating/opdm/local-programs-bureau/repository/bicycle/safety-and-laws/laws.html Hmm, I just looked at the text. Did you intentionally leave out the part that says Conditions to be taken into consideration include [...] traffic lanes too narrow for a bicycle and a vehicle to travel safely side-by-side within the lane. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Signed shared roadway
On Sat, Oct 22, 2011 at 9:58 PM, Nathan Edgars II nerou...@gmail.com wrote: On 10/22/2011 9:13 PM, Richard Welty wrote: if there's just a black on yellow sign saying share the road then cyclists should stay to the right. Not at all. http://commuteorlando.com/wordpress/on-the-road/sharing-the-road/ http://commuteorlando.com/wordpress/2010/11/29/helping-motorists-with-lane-positioning/ *Nod*. I would guess that the places where they tend to put share the road signs tend to be exactly the types of roads where it is *not* safe for a bicycle and a vehicle to travel side-by-side within the outside lane. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Signed shared roadway
On Sat, Oct 22, 2011 at 10:06 PM, Richard Welty rwe...@averillpark.net wrote: not intentionally, and i did include the link so people could read it, so perhaps we could drop the confrontational bit. Sorry. you will note that i didn't come back at you about the fact that there are no specs anywhere about 14' lane widths or parallel parking in the NYS law either. you might want to provide a reference on where you got those. 8 feet for the car, 3 feet for the bike, 3 feet between the two. And I said about. http://en.wikipedia.org/wiki/Wide_outside_lane ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Interstate Crossovers
On Fri, Oct 7, 2011 at 9:16 PM, Phil! Gold phi...@pobox.com wrote: * Anthony o...@inbox.org [2011-10-07 16:36 -0400]: access=private is wrong if it is not private property. I understand access=private to mean, You cannot go here without express permission from the property owner. The land is owned by whatever government owns it, and the sign says you can't go there unless you have their permission. By that rationale, all government owned land is access=private. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Interstate Crossovers
On Sat, Oct 8, 2011 at 9:09 AM, Nathan Mills nat...@nwacg.net wrote: On Sat, 8 Oct 2011 08:44:04 -0400, Anthony wrote: By that rationale, all government owned land is access=private. No. In a park, for example, you have a right of access by default. I'm not sure what you mean that it is by default. You're only allowed in the park between dawn and dusk, which is less than 50% of the day. In any case, I was thinking about highways here. I agree that access=private doesn't make intuitive sense for government owned land. We do all own it, after all. Having said that, it's pretty silly to use a different tag just because the land is government owned/controlled when the message is otherwise the same. The message isn't the same, though. A private road is not the same as a public road with restricted access. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Interstate Crossovers
On Sat, Oct 8, 2011 at 9:40 AM, John F. Eldredge j...@jfeldredge.com wrote: The access=emergency tag is documented in the wiki as meaning that access is permitted for emergency vehicles, and would seem to ideally fit this situation. Where is it in the wiki? I did a search for emergency, and all I found is http://wiki.openstreetmap.org/wiki/Key:emergency which is about emergency=*, not access=emergency. There is also an abandoned proposal, http://wiki.openstreetmap.org/wiki/Proposed_features/emergency_vehicle_access It's not ideal for this situation, as I described above, emergency=yes is better. (But really both are redundant in the jurisdictions I know of - emergency vehicles, at least when responding to an emergency, are exempt from access restrictions.) ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Interstate Crossovers
On Sat, Oct 8, 2011 at 7:10 PM, John F. Eldredge j...@jfeldredge.com wrote: Anthony o...@inbox.org wrote: On Sat, Oct 8, 2011 at 9:40 AM, John F. Eldredge j...@jfeldredge.com wrote: The access=emergency tag is documented in the wiki as meaning that access is permitted for emergency vehicles, and would seem to ideally fit this situation. Where is it in the wiki? I did a search for emergency, and all I found is http://wiki.openstreetmap.org/wiki/Key:emergency which is about emergency=*, not access=emergency. The first bullet point in the above page describes the use of emergency in regards to access. Did you try reading the page? Yes, I read the page. The emergency tag is used as an access restriction on roads to indicate that it is usable by emergency vehicles - see access=* Did you read it? If so, try again. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Interstate Crossovers
On Fri, Oct 7, 2011 at 10:43 AM, Phil! Gold phi...@pobox.com wrote: * John F. Eldredge j...@jfeldredge.com [2011-10-07 06:51 -0500]: James Mast rickmastfa...@hotmail.com wrote: Hey guys, I'm curious, but how have you guys been tagging them when you add them? Define what you mean by an Interstate crossover. I believe he means the tiny bits of road that are put in periodically between the two sides of a divided highway so that ambulances and such can switch between sides more easily. They don't connect to anything except for the two directions of the freeway and in my area are usually signed For authorized and emergency vehicles only. highway=service, access=no ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Interstate Crossovers
On Fri, Oct 7, 2011 at 4:23 PM, Anthony o...@inbox.org wrote: On Fri, Oct 7, 2011 at 10:43 AM, Phil! Gold phi...@pobox.com wrote: * John F. Eldredge j...@jfeldredge.com [2011-10-07 06:51 -0500]: James Mast rickmastfa...@hotmail.com wrote: Hey guys, I'm curious, but how have you guys been tagging them when you add them? highway=service, access=no I suppose you could also add emergency=yes. access=private is wrong if it is not private property. access=official is wrong, that's not what it means. access=emergency isn't in the wiki, and there are already too many access=* tags anyway (*). Also, access=emergency would be redundant with emergency=yes. (*) We should be keeping the number of access=* tags to a minimum, so that routers don't have to handle lots of different access tags. If a router doesn't know what emergency=* means, the router will have to use a default, which for highway=service is probably access=yes. A tag like emergency=yes along with access=no, on the other hand, is safe for a router (of anything except emergency traffic) to ignore, if the router doesn't know what it means. ___ 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 Fri, Sep 30, 2011 at 3:07 PM, Frederik Ramm frede...@remote.org wrote: Hi, On 09/30/2011 08:36 PM, Mike N wrote: Really? Are there people who say I'd rather not map because there is no consensus on the roads tagging? Are those people the 20,000 missing mappers in the US? It is more like I don't see anyone using the map except for Skobbler, so why should I invest my time? And what are the obstacles to usage? inconsistent tagging. Yes,but are the only meaningful uses of the map really those that depend on cross-state consistent road tagging? I find that hard to believe. And even if it were so - it may be that Greece and Norway are different countries, and they certainly have different authorities responsible for road naming and design, but you can simply grab your car and go from Greece to Norway without even having to show an ID to anybody - and yet nobody in Greece has claimed that inconsistent road tagging within Europe was an obstacle to usage. If every state in the US had its own consistent tagging scheme, that might be a valid analogy. However, that's not the case. There's no reason that a US chapter can't working on a tagging scheme which has nuances specific to each of the states. In fact, I would think that a consistent US-wide tagging scheme necessarily *would* have differences between states. I assume by consistent we mean compatible, not identical. On Fri, Sep 30, 2011 at 1:28 PM, Peter Dobratz pe...@dobratz.us wrote: Yes, OSMF US shouldn't mandate a certain tagging scheme, but they could certainly help to facilitate a consensus among the community. No one can mandate a certain tagging scheme. However, OSMF US (or any other group of editors) *could* come up with a well thought out, consistent tagging scheme, implement stylesheets and/or scripts to make that tagging scheme work in Mapnik, and then map it in a few wide-ranging example areas. I guess you could call that facilitating a consensus. But it's not what came to mind when I first heard that phrase. The tagging scheme in the US is inconsistent. Patches welcome. ___ 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 Fri, Sep 16, 2011 at 9:07 PM, Greg Troxel g...@ir.bbn.com wrote: So we could take the existing tags, where =customer is perhasp not existing, and have a hierarchy: access=yes access=destination access=permissive (no legal right, but not objected to) *access=customers access=private (no right, permission not granted to the public) access=no (hard to tell what this means - doesn't make sense) I look at it this way: public rights of way (including privately owned land on which a public right of way is granted): *access=yes (no legal restrictions) *access=destination (no through traffic) *access=no (traffic generally not allowed, e.g. road closed) These are all rights of way, but except for access=yes, there are traffic laws barring at least some access. private property with no right of way: *access=permissive (private property, not a public right of way, but the public regularly uses it without asking permission, there are no signs barring free use, and the owner does not seem to object - I would think most parking lots would fall under this) *access=private (private property, and the owner has in some manner marked the property as such, either with a barrier or some sort of sign or marking) **access=customers (private property, and the owner has in some manner marked the property with a sign saying something similar to customers only or a barrier/gate/guard meant to enforce the same; note that this is actually a subset of access=private; also note that many but not all instances of access=customers are probably really access=customers,_employees,_or_by_invitation) These access restrictions are not traffic laws. A violation of them is trespassing, with notice. The real question is what routers should do. Probably the best that can be done is to put a high cost on access=destination and even higher on access_permission=private and note this on the results. Typically you'd only be routed over those when going someplace where you have permission. One major problem is that access=destination tags really should be directional, as the signs that restrict traffic are generally directional. The access=destination tag typically applies when *entering* the development or other area, but it typically doesn't apply when *leaving* that area. Another major problem is that the legal definition of the signs themselves are sometimes ambiguous. What constitutes local traffic? What constitutes thru traffic? Apparently this is highly jurisdiction specific. Here in Florida, according to that link which Nathan provided, the signs are apparently legally meaningless. I'd be tempted, when writing a router, to just treat them equivalent to access=yes. ___ 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 Fri, Sep 16, 2011 at 9:17 AM, Anthony o...@inbox.org wrote: As I've said on the wiki, I'd rather see access=restricted plus access:restriction=customers_only, this way we can give routers general information (that the way is restricted to a particular category) without having them understand access=customers and access=employees and access=judges and access=expectant_mothers, etc. The way I envision it, a router could see access=restricted, access:restriction=X, and would pop up a dialog your route includes a restricted area, the restriction is X, would you like to include this area in your route? ___ 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 Fri, Sep 16, 2011 at 8:33 AM, Phil! Gold phi...@pobox.com wrote: The US doesn't seem to have the strict legal categories for rights-of-way that the UK does I'm not sure what you mean by that, as I'm not familiar with UK law. But the US definitely has a concept of public right of way vs. private property. The access=destination key/value was clearly meant for the former. There is still a note in the source of the wiki which explains what access=destination means in the US - no thru traffic or local traffic only (USA). That is completely different from customers only. ___ 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 Wed, Sep 14, 2011 at 10:50 PM, Bill Ricker bill.n1...@gmail.com wrote: So this could be access=destination , which should allow routing at ends but not for thru traffic. Well, that's not at all what the sign says. ___ 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 Thu, Sep 15, 2011 at 11:55 AM, Nathan Edgars II nerou...@gmail.com wrote: 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. [snip] But that's an interesting point about cast members (AKA employees) being allowed to use it even when their destination is not Disney. Actually my comment was about cast members using it when their destination *is* Disney, just not a place in Disney in which the use of Vista Blvd is necessary. I'm not even sure what access=destination is supposed to mean with regard to that section of Vista Blvd. But my guess is that it would mean you can only use this road to get to Fort Wilderness, and using it to go between World Drive and Bonnet Creek Parkway would not be allowed. 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. Incidenally, for some reason Lulu-Ann put the example of customer parking lots in the wiki for access=destination, but I'd say this completely changes the original intent of access=destination. Only a few months ago the wiki said access=destination The public has right of access only if this is the only road to your destination. In December 2007 it said destination (The public has right of access only if this is the only road to your destination, in Dutch: bestemmingsverkeer, in German: Anlieger frei / ausgenommen Anrainer) The definition in the wiki today is very different from what was for years. The definition from at least December 2007 until July 2011 implied that access=destination is to be used for public (or at least quasi-public) roads, not private roads. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] Disney (was Re: access=destination vs access=private)
On Tue, Sep 13, 2011 at 4:29 AM, Nathan Edgars II nerou...@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? Did you check the previous owners? When was the road first built? Who built it? When did Disney purchase the land? ___ 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 Tue, Sep 13, 2011 at 8:58 AM, Bill Ricker bill.n1...@gmail.com 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. What is the goal here ? We're trying to figure out whether this sign restricts the use of the road, or if it's BS: 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 ___ 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 Tue, Sep 13, 2011 at 8:58 AM, Bill Ricker bill.n1...@gmail.com wrote: Waste/Submerged would be correct status in 1960 prior to Disney development, not current status. Sounds like that website is not current source for Reedy Creek documents. By the way, the particular parcel of land being referred to *is* undeveloped, except for the highway. (http://paarcgis.ocpafl.org/Webmap4/default.aspx?pin=28241700017) ___ 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 Tue, Sep 13, 2011 at 10:05 AM, Nathan Edgars II nerou...@gmail.com wrote: There was a guard booth on Vista Boulevard near the present location of the sign until about 2005. And now I get it. This road could be used to bypass the main entrance toll booth on World Drive, and doesn't seem to be particularly useful as a thru way anyway (as it doesn't connect easily with World Drive going south - you'd have to circle all the way around the parking lot to get out of Disney World property). ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] access=destination vs access=private
On Mon, Sep 12, 2011 at 4:43 AM, Nathan Edgars II nerou...@gmail.com wrote: 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. 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 ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] access=destination vs access=private
On Sun, Sep 11, 2011 at 3:33 AM, Nathan Edgars II nerou...@gmail.com wrote: On 9/11/2011 3:12 AM, 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 ... So you turn into the driveway and switch to pedestrian mode at the instant you cross the sidewalk, and are therefore no longer upon a roadway :) Seriously, I'd say this is probably a very gray area of the law. I'm sure there are many streets that are marked 'no thru traffic' but are inventoried if not signed as parts of a medium-distance bike route. So a bike router is probably better-off ignoring access=destination in general, unless the user specifies that he wants to follow the letter of the law. 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. In any case, if access=destination only applies to motor vehicles, it should be motor_vehicle=destination. If it only applies to vehicles, it should be vehicle=destination. Routers may want to cheat and assume access=destination means [motor_]vehicle=destination, but if you're going to tag it, you should tag it correctly. As for whether no thru traffic is even supposed to be meant to apply to bicycles, I don't know. Personally I'd certainly fight any ticket I received for failure to obey such a sign. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] access=destination vs access=private
On Sun, Sep 11, 2011 at 10:59 AM, Nathan Edgars II nerou...@gmail.com wrote: 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. I'd be tempted to mark such ways as access=no_thru_traffic, and let the routers figure out what it means. It seems a bit too much to ask mappers to interpret legal statutes and precedents. But really, I don't have a good answer. (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.) Enforceable as trespass, I assume. But access=destination wouldn't be accurate there. Using access=destination implies that anyone may (in fact, has a right to) use that way, if they need it to get to their destination. But the sign says that only guests, cast, and business invitees may use the way. As I commented on the wiki, I'd rather see access=restricted for these types of situations. (In this case with access:restriction=guests, cast, and business invitees only.) Or access=customers, if you think that tag is acceptable (but personally I'd rather see a very small number of access tags). Again, personally, I'd use access=private before I'd use 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 Sun, Sep 11, 2011 at 10:59 AM, Nathan Edgars II nerou...@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? ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] access=destination vs access=private
On Fri, Sep 9, 2011 at 11:00 PM, Peter Dobratz pe...@dobratz.us wrote: Do you think it makes more sense to tag the apartment complexes as access=destination or access=private? The complexes are not usually private. I'd even consider not putting access restrictions on them at all, unless there is some rule that you shouldn't be using them as a through street. What if you are walking or on a bicycle? What about jurisdictions like New Jersey, which have this law: New Jersey 39:4-66.2 Except for emergency vehicles and motor vehicles being operated at the direction of a law enforcement officer, no person shall drive a motor vehicle on public property, except public roads or highways, or private property, with or without the permission of the owner, for the purpose of avoiding a traffic control signal or sign. Would such private ways, which could be used to avoid a stop sign, be access=permissive, motor_vehicle=destination? I don't know. I thought access=destination was only to be used for rights of way. And I think if I were coding a router I'd avoid using an access=permissive as a through street anyway. But maybe that's my learned-to-drive-in-New-Jersey bias. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] access=destination vs access=private
On Fri, Sep 9, 2011 at 11:52 PM, Paul Johnson ba...@ursamundi.org wrote: On Fri, 2011-09-09 at 23:43 -0400, Anthony wrote: On Fri, Sep 9, 2011 at 11:00 PM, Peter Dobratz pe...@dobratz.us wrote: Do you think it makes more sense to tag the apartment complexes as access=destination or access=private? The complexes are not usually private. I'd even consider not putting access restrictions on them at all, unless there is some rule that you shouldn't be using them as a through street. What if you are walking or on a bicycle? What about jurisdictions like New Jersey, which have this law: New Jersey 39:4-66.2 Except for emergency vehicles and motor vehicles being operated at the direction of a law enforcement officer, no person shall drive a motor vehicle on public property, except public roads or highways, or private property, with or without the permission of the owner, for the purpose of avoiding a traffic control signal or sign. That's a pretty normal consideration and most routers avoid cutting through service/living_street situations as is (though explicit tagging is never bad). Would such private ways, which could be used to avoid a stop sign, be access=permissive, motor_vehicle=destination? I don't know. I thought access=destination was only to be used for rights of way. And I think if I were coding a router I'd avoid using an access=permissive as a through street anyway. But maybe that's my learned-to-drive-in-New-Jersey bias. I wouldn't consider it permissive by bicycle in such a circumstance, because most (all?) places in the US consider bicycles vehicles except when operated in extremely limited circumstances (effectively making a cyclist act like a pedestrian), since pedestrians are normally exempt from intersection signals if their trip takes them down a contiguous sidewalk that doesn't cross the street. The NJ law in question is regarding driving a *motor* vehicle on public property, though. That law doesn't apply to bicycles, though I can't say for certain that there isn't another law which does. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] access=destination vs access=private
On Fri, Sep 9, 2011 at 11:55 PM, Paul Johnson ba...@ursamundi.org wrote: On Fri, 2011-09-09 at 23:25 -0400, Anthony wrote: On Fri, Sep 9, 2011 at 7:36 PM, PJ Houser stephanie.jean.hou...@gmail.com wrote: Do you think it makes more sense to tag the apartment complexes as access=destination or access=private? Shouldn't they generally be access=permissive? At least in the states I've been in, in general it seems to be in a commercial setting, it would be. In residential settings, these ways tend to be closed to everyone except visitors/clients of residents (couriers, plumbers, pizza delivery, garbage removal, etc) that have have been invited in, and trespassing charges can be pressed against everyone else. Without warning? Where in the US can you be charged with trespass without any warning (no sign, no fence, no marked trees, no building, no verbal warning)? ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
