Re: [Talk-us] Admin boundaries tied to roads
-Original Message- From: Apollinaris Schoell [mailto:ascho...@gmail.com] Sent: Friday, April 23, 2010 9:47 AM To: Lord-Castillo, Brett Cc: 'talk-us@openstreetmap.org' Subject: Re: [Talk-us] Admin boundaries tied to roads On 23 Apr 2010, at 7:13 , Lord-Castillo, Brett wrote: On 19 Apr 2010, at 20:24, Apollinaris Schoell wrote: On 19 Apr 2010, at 20:07 , Alan Mintz wrote: Not to mention that merging them will result in the inability to hide these boundaries. When doing a bunch of editing on a road that follows one, in the past, I've taken the time to verify that the boundary doesn't share any nodes with anything and then remove it from my local OSM file manually so I don't have to constantly deal with it. If it shares nodes with anything else, this is no longer possible. fully agree, the good thing is these boundaries are tiger data and bad data anyway and should be replaced with better boundaries While I understand the mantra of TIGER=Bad because of the state of the road data, this is not true for the boundary data. Most of the boundary data comes directly from recorded surveys (something not available for roads) and is not bad data for most of the United States. The rural areas would be the one exception (mostly because they did not have surveys converted to digital layers in 2000), but rural areas are also highly likely to have realigned boundary roads that no longer correspond to the original boundaries. I can tell for sure that they are completely wrong in California. They are not even close to USGS 24k, don't align with official county borders from official sources and don't align with natural features, fences which are sometimes visible on Yahoo. Yes, California is one of the well-known exceptions. Their LUCA program fell apart (and this time around has been split into two separate regions as a result). If you take the Midwest states though, like Iowa, Minnesota, Missouri with their 300+ counties between them, the TIGER lines are directly from official sources, especially the 2009 updates. Brett Lord-Castillo Information Systems Designer/GIS Programmer St. Louis County Police Office of Emergency Management 14847 Ladue Bluffs Crossing Drive Chesterfield, MO 63017 Office: 314-628-5400 Fax: 314-628-5508 Direct: 314-628-5407 ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Admin boundaries tied to roads
I'd agree with Brett on the boundaries. The Census data is not perfect by any means, but it's pretty good, at least in my area--Minnesota. (and orders of magnitude better than it was in 2000!) And if it's not good in your area, you should talk to your local government and make sure they're participating in the Census' yearly Boundary Annexation Survey. http://www.census.gov/geo/www/bas/bashome.html I can tell for sure that they are completely wrong in California. They are not even close to USGS 24k, don't align with official county borders from official sources and don't align with natural features, fences which are sometimes visible on Yahoo. To further respond to this, there is no claim by the Census that it's survey accuracy, or that it aligns with other data. Fundamentally, it is created by the Census for internal purposes, and all TIGER boundary data is relative to the other TIGER data. (just like a lot of traced OSM data is relative to the Yahoo imagery) Everybody gets access to it for free and you can use it when its good or ignore it when its bad or modify it when its in between. The bigger issue with it being imported into OSM is the currency, because municipal boundaries are always changing, and as has been mentioned, boundaries are not usually something that is easily verifiable on the ground Cheers, Brad On Fri, Apr 23, 2010 at 9:54 AM, Lord-Castillo, Brett blord-casti...@stlouisco.com wrote: -Original Message- From: Apollinaris Schoell [mailto:ascho...@gmail.com] Sent: Friday, April 23, 2010 9:47 AM To: Lord-Castillo, Brett Cc: 'talk-us@openstreetmap.org' Subject: Re: [Talk-us] Admin boundaries tied to roads On 23 Apr 2010, at 7:13 , Lord-Castillo, Brett wrote: On 19 Apr 2010, at 20:24, Apollinaris Schoell wrote: On 19 Apr 2010, at 20:07 , Alan Mintz wrote: Not to mention that merging them will result in the inability to hide these boundaries. When doing a bunch of editing on a road that follows one, in the past, I've taken the time to verify that the boundary doesn't share any nodes with anything and then remove it from my local OSM file manually so I don't have to constantly deal with it. If it shares nodes with anything else, this is no longer possible. fully agree, the good thing is these boundaries are tiger data and bad data anyway and should be replaced with better boundaries While I understand the mantra of TIGER=Bad because of the state of the road data, this is not true for the boundary data. Most of the boundary data comes directly from recorded surveys (something not available for roads) and is not bad data for most of the United States. The rural areas would be the one exception (mostly because they did not have surveys converted to digital layers in 2000), but rural areas are also highly likely to have realigned boundary roads that no longer correspond to the original boundaries. I can tell for sure that they are completely wrong in California. They are not even close to USGS 24k, don't align with official county borders from official sources and don't align with natural features, fences which are sometimes visible on Yahoo. Yes, California is one of the well-known exceptions. Their LUCA program fell apart (and this time around has been split into two separate regions as a result). If you take the Midwest states though, like Iowa, Minnesota, Missouri with their 300+ counties between them, the TIGER lines are directly from official sources, especially the 2009 updates. Brett Lord-Castillo Information Systems Designer/GIS Programmer St. Louis County Police Office of Emergency Management 14847 Ladue Bluffs Crossing Drive Chesterfield, MO 63017 Office: 314-628-5400 Fax: 314-628-5508 Direct: 314-628-5407 ___ 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] Admin boundaries tied to roads
On Fri, Apr 23, 2010 at 11:01 AM, Brad Neuhauser brad.neuhau...@gmail.comwrote: The bigger issue with it being imported into OSM is the currency, because municipal boundaries are always changing, and as has been mentioned, boundaries are not usually something that is easily verifiable on the ground I'd say the biggest issue is the fact that, when the census bureau couldn't find data on municipalities, they decided to just make shit up. They picked some arbitrary boundary which had roughly the right number of people in it, and then named it after an actual place which happened to be nearby. The CDPs are horrible when used for any purpose other than interpreting census data. I really wish the census bureau had named them CDP 1283, CDP 1284, CDP 1285, etc. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Admin boundaries tied to roads
At 2010-04-23 18:11, Anthony wrote: A navi system is more useful if the instructions and signs match. Depends on your purpose. If you're trying to navigate to the missigned street (e.g. California Street, where the sign reads Carolina Street), you don't want to get a response of street not found. For most other purposes you'd rather have the incorrect name (at least until it gets fixed). Yeah - this is always a quandary. In my experience, the street sign usually ends up being right anyway, so I'm usually asking the responsible authority to fix their GIS and/or the source map (yes, even tract maps that are decades old :) ). I don't really consider this as original research, since it's really a matter of reconciling sources, but it's admittedly time consuming and requires additional research that many mappers (understandably) may not want to do. Still, I think it's value that I can add, not only to OSM, but also for my fellow citizens. When the sign is wrong, I notify the signing authority and, if it seems that they intend to fix it soon (the usual case), I put the correct value in the name tag and the signed value in the alt_name tag, with a note tag describing the situation. If there is no easy contact with the authority, or it seems they may not fix it soon, I reverse the tagging. Either way, there are notes/FIXMEs there to remind me (or others) to survey again in the future. BTW, technically, I would call surveying/photographing, and then mapping based on it, original research :) P.S. http://www.openstreetmap.org/browse/way/56123368 is one of those strange cases where it's been signed and likely known wrong according to the cited docs, because the signed name is more logical in context. I name'd it as signed and put the recorded name in the official_name tag instead. If there's anyone nearby that would like to have a look, It'd be useful to know how it's signed at the intersection with Outer Traffic Circle here: http://www.openstreetmap.org/browse/node/122696036 . -- Alan Mintz alan_mintz+...@earthlink.net ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Admin boundaries tied to roads
At 2010-04-23 07:47, Apollinaris Schoell wrote: While I understand the mantra of TIGER=Bad because of the state of the road data, this is not true for the boundary data. Most of the boundary data comes directly from recorded surveys (something not available for roads) and is not bad data for most of the United States. The rural areas would be the one exception (mostly because they did not have surveys converted to digital layers in 2000), but rural areas are also highly likely to have realigned boundary roads that no longer correspond to the original boundaries. I can tell for sure that they are completely wrong in California. They are not even close to USGS 24k, don't align with official county borders from official sources and don't align with natural features, fences which are sometimes visible on Yahoo. I don't know about completely. The parts of the Kern/LA/Orange/San Bernardino/Riverside/San Diego borders that I have surveyed are at least close to the signage at important points (admittedly a weak standard), but I've also gone hunting for detail in law in some spots and found that the borders were right as of their date of creation in the source data. I remember manually fixing a little bit of the OC/LA border in La Habra from some sort of change description - maybe something out the BAS project. What a pain that was. Is anyone working on borders currently? Is the BAS a reasonable source? -- Alan Mintz alan_mintz+...@earthlink.net ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Admin boundaries tied to roads
At 2010-04-22 13:33, andrzej zaborowski wrote: On 22 April 2010 17:40, Apollinaris Schoell ascho...@gmail.com wrote: On 21 Apr 2010, at 17:12 , andrzej zaborowski wrote: The signs are posted there by authorities so this is similar to having access to a tiny piece of a map or database made by these authorities. For maps people usually agreed on this list that we don't trust them. are you saying authorities are wrong and we should correct what they are doing and follow tiger or USPS standards instead? I'm saying we should name the objects what they're called, not what it is written as in somebody's database. what they're called, though, may indeed be from somebody's database, when that database is the county recorder's or assessor's. The recorder, in particular, should be the truth by definition, except when you can see that there's an obvious mistake and can confirm it with them. -- Alan Mintz alan_mintz+...@earthlink.net ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Admin boundaries tied to roads
On 23 Apr 2010, at 19:46 , Alan Mintz wrote: At 2010-04-23 07:47, Apollinaris Schoell wrote: I don't know about completely. The parts of the Kern/LA/Orange/San Bernardino/Riverside/San Diego borders that I have surveyed are at least close to the signage at important points (admittedly a weak standard), but I've also gone hunting for detail in law in some spots and found that the borders were right as of their date of creation in the source data. I remember manually fixing a little bit of the OC/LA border in La Habra from some sort of change description - maybe something out the BAS project. What a pain that was. depends on the definition, for me a difference of 100-200m is too bad. any GPS or verbal description is better if matched with Yahoo. In some corners even worse complex edges have been entirely clipped. USGS is pretty good and matches county borders. County borders are from official state data and are high accuracy. Also Sat matches well when borders follow natural features. USGS tracing is very difficult because borders are often hard to identify among other features. Is anyone working on borders currently? Is the BAS a reasonable source? what is BAS? any better source will be useful -- Alan Mintz alan_mintz+...@earthlink.net ___ 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] Admin boundaries tied to roads
At 2010-04-22 13:09, andrzej zaborowski wrote: On 22 April 2010 04:24, Alan Mintz alan_mintz+...@earthlink.net wrote: At 2010-04-21 17:12, andrzej zaborowski wrote: On 22 April 2010 01:18, Apollinaris Schoell ascho...@gmail.com wrote: On Wed, Apr 21, 2010 at 3:36 PM, andrzej zaborowski balr...@gmail.com wrote: Where's damage in that -- is it in that you can now read the name out without checking the documentation for what that funny string means in that particular database that is TIGER? I just had a machine crash as I was trying to find stats, but I'll bet that at least 90% of the cases are St, Ave/Av, and Blvd/Bl, with the occasional Ln and Cir/Cr thrown in. When there's a lone N, S, E, or W as a prefix to a street name, it's clear to everyone what that means. These are the same abbreviations that _everyone_ uses every day - children, adults, businesses, governments, etc. Well, you just gave examples of the obvious ones, I'm not claiming any of these are not known. But the list has 672 different forms. My point, though, was that we were going to a lot of trouble for a small percentage of real-world cases that _might_ (see below) present a problem for someone to understand. (but even the easy ones are hard for non-human consumers because St has at least three possible meanings, all three quite popular across the db). I'm sorry, but as a suffix (i.e. for the regex / St$/), what else does St mean but Street? And I will do so again. My problem is mostly that this was done without a safety net. You clobbered existing data with no easy way to walk it back... Well, the way to walk it back is pretty easy, all the names can be taken from version-1 or reassembled from the tiger tags, so no worries there. This doesn't work for streets that were edited by users. Again, my problem is that, in thousands of edits, I specifically only expanded, for example, the prefix N to North when it is logically part of the root name. When it is logically a housenumber suffix, as it is in the majority of southern CA, I left the prefix alone. The road name may have been otherwise edited, though (to correct spelling, rename completely, etc.) This was to be used in the future when we could agree on a way to correctly separate these component parts of the name, as they are and must be in any database to be used with routing and street addressing in the real world. To walk it back, we will have to query the history of the way and find the version before the bot, to see what was done. It's not just v1, or TIGER, because it may have been otherwise edited. It's not even v[last-1] any more because there may have been other edits since the bot (I've done many myself). ...Then TIGER also includes Spanish names and the list has abbreviations for those too, which rarely anyone in US can read, while they can cope with unabbreviated ok. I don't agree. Much of the US speaks Spanish. Many more possess the tremendous brainpower and enoUGH grade-school Spanish required to know that Cl. in front of a street name might mean Calle or Cam. might mean Camino, or that S means Sur and N means Norte. But do you remember the 600 abbreviations used in tiger? It's neither practical or useful or helps anyone, they're much like numerical codes. The one single thing they may be good for is for rendering at lower zoom levels. I don't understand. Why do I have to remember them? Am I not capable of inferring their meaning? Do I have to infer anything anyway, since they are likely to be similar/identical to signage? Also, to me lower zoom levels is almost any level at which I want to see a map. Anything more than a small neighborhood, and it's all we can do just to fit the root of the name in - we don't need any _more_ characters. name: The pre-balrog name 99% percent of the cases this was an arbitrary version of name, taken from a database which was chosen only on the basis of its license, not because it was more correct or anything. So I don't see any reason to hang on to it. If I understand you correctly, I disagree completely. In my experience in southern CA, 90% of the time, TIGER is correct with the exception of the presence of the directional prefix. The real problem was the geometry[1]. In the Los Angeles area, I rarely saw expanded names (which is why I continue to abbreviate), except for those rare instances where someone drew a street from scratch before TIGER (apparently), and not even all of those. BTW, from my previously cited data chunk (35988 unique names in about 4400 sq mi (11000 sq km) of southern CA) , I can now say that only ~0.2% of suffixes were present in their expanded form (i.e. Street, Avenue, etc.). You could surely change the wiki but it's a conclusion that a lot of people individually seem to come to so I'm sure you wouldn't even need a bot before someone would add a phrase to that effect. I don't know
