[Talk-us] Admin boundaries tied to roads

Apollinaris Schoell aschoell at gmail.com
Thu Apr 22 17:41:36 BST 2010


On 21 Apr 2010, at 19:24 , Alan Mintz wrote:
>>> 
> 
> Exactly. Many places in Orange County have the bad habit of leaving the 
> suffix off the large street signs at intersections, perhaps as a way of 
> saving space to reduce sign size and cost. Just because the big sign says 
> just Orange doesn't mean that the street's real name is Orange Street, nor 
> that it shouldn't be entered into any reasonable database or map that way. 
> "map what's on the ground" is the wrong thing to do so often that I don't 
> really understand why it was decided upon, nor why people continue hold it 
> up on a pedestal, despite continuing problems with it.
> 

there is a reason for "map what is on the ground" this is the only thing we can verify.
And this is the strength of crowd sourcing. trying to compete with google and others in their ability to collect and merge PD data is a waste of time. 
We need to add value to osm otherwise we are on a dead end.

Sure in many cases street signs are wrong, incomplete and inconsistent but this is what a visitor will see and should be able to compare to a map. A navi system is more useful if the instructions and signs match. If you get a chance try the google navi and they must have filmed all direction signs and will announce exactly what signs to follow. This is value and I couldn't care less what is written in a Tiger DB or USPS or anywhere else.

> 
>> For the record street signs on different ends of the same street often
>> use different forms and you'll sometimes find really strange
>> conventions, so while I agree mapping what's on the ground is good
>> because stuff can be confirmed, in this case it's not a solution.  In
>> many places you'll find the names are all caps on the signs but in a
>> local newspaper they're capitalized the usual way.
> 
> And the signs are sometimes wrong. In the thousands of streets I've 
> photographed and mapped, I've corrected hundreds of signage 
> errors/inconsistencies, often requiring substantial research into records, 
> and resulting in notification of the appropriate authority to fix the 
> records and/or signs (for free :( ).
> 

sure this is the case and if authorities will fix the signs this is good to do. But maybe authorities may decide and fix their records instead. One can always argue that the sign created a fact and people adopted to the wrong names 

> 
>>> - many geocding engines do not find expanded names. even google doesn't in
>>> many cases. To me it looks like nearly anyone doesn't use the expanded name
>>> at all. So my question is is the expanded name really the correct name?
> 
> Exactly! Sounds like it's only useful purpose is text-2-speech. Here's what 
> I'd like to see:
> 
> name: The pre-balrog name
> name_direction_prefix: The 1-2 char cardinal direction before the root
> use_name_direction_prefix: {yes|no} Yes indicates that the 
> name_direction_prefix should be rendered/spoken
> name_root: The actual root of the name
> name_direction_suffix: The 1-2 char cardinal direction after the root
> name_type: {St|Ave|Blvd|etc.} Common, documented abbreviations allowed
> render_name: The name to be rendered on a map (if not name for some reason)
> spoken_name: The complete expanded name, ready for text-2-speech
> 
> The post-balrog name should go into spoken_name for now. The pre-balrog 
> name would be restored to the name tag and also split up into the name_* tags.
> 

this is the right direction. maybe can be simplified because much is redundant and can be easily calculated by some simple rules as a fallback when a specific tag doesn't exist.


> In areas where the name_direction_prefix is really an address suffix, and 
> does not appear in front of the name in written or spoken addresses or in 
> official records, it could then be removed from the name, render_name, and 
> spoken_name tags by someone who has verified this, where appropriate.
> 

agreed, the direction prefix is a pain and not useful. some navi systems treat is as part of a name and address search is a complete mess because most people will write address without it.

> A bot and/or editor functionality to populate any missing tags, so you're 
> not forcing anyone to input in one way or the other. Personally, I would 
> mostly populate the component tags with "the truth" and let the 
> editors/bots do whatever else.
> 
> 

where it's simply enough for a bot we can as well let the consumer of the data do it as a processing step not need to fill the planet with data which can be easily calculated

> 
>> I don't know but it seems it's the only unambiguous form.  If you look
>> at the names in TIGER, Bing, Google and USPS-abbreviated then they're
>> all different and the only common trace is they're somehow derived
>> from the full version.
> 
> That seems like a rendering issue, something you would always see in trying 
> to reconstruct the correct underlying data from a rendering (including OSM 
> now, which seems to be re-abbreviating in the renderers, thankfully). That 
> doesn't mean we shouldn't try to understand the correct schema for the 
> underlying data and model it correctly.
> 

yes one can blame it on the renderer but keep in mind asking for a special implementation on the main renderer just for a local speciality will be ignored for good reasons. wide use of abbreviations and direction prefix are not common in other countries. The main Mapnik, T at h rendering can't be changed 


> 
>>>> The reason it was done with a script is that doing it manually was
>>>> taking a lot of time and mappers were spending that time doing this
>>>> instead of going out mapping. Â And it's always been on the wiki about
>>>> not using abbreviated names, even when the original import was done,
>>>> ignoring this.
> 
> So what most newbies, including myself, did, was to follow the style of the 
> majority of the data, instead of the often-outdated, incomplete, and 
> inaccurate wiki, which is often not even self-consistent.
> 

did the same when I started and I think this is the best approach to converge to a consistent and useful database


> 
> I don't know about "a lot". I mostly just hear people regurgitate the 
> "don't abbreviate" mantra without justification. Admittedly, maybe it's 
> because it's already been hashed out to death and I'm late to the party. 
> Regardless, maybe I'm not alone, and it deserves some re-thinking.
> 

fully agreed
Don't know where this mantra comes from. Can just guess it's from different countries where abbrev is rare and indeed bad to do. Since it is the standard in US why not stick with it? 

> Do people that are actually mapping (not bulk-importers) really want to 
> type in "North Martin Luther King, Junior Boulevard Southwest" and then 
> proofread that to make sure they didn't typo anything? Do people really 
> want to follow around some of the more active, but less detail-oriented (or 
> perhaps dyslexic) mappers to correct all those additional mistakes?
> 

and do we really want to see this names on a map? or anywhere else?

> --
> Alan Mintz <Alan_Mintz+OSM at Earthlink.net>
> 
> 
> _______________________________________________
> Talk-us mailing list
> Talk-us at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-us





More information about the Talk-us mailing list