[Talk-us] Admin boundaries tied to roads
>From an old message: > I take the point that 'road realignment' may > require the boundary also to move, but the word is MAY and so what ever > happens > to the road, the location of the boundary needs to be checked separately! > It is > quite surprising in the UK how many roads are being moved, but that does > not > also move the original boundary. I see that the separate VS tangled argument has been settled in the US by the "Duplicate Node attack bots", who have blindly merged all duplicate nodes. http://www.openstreetmap.org/browse/way/38855677 ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Admin boundaries tied to roads
On Mon, Apr 19, 2010 at 12:45 PM, Mike N. wrote: > From an old message: > > > I take the point that 'road realignment' may > > require the boundary also to move, but the word is MAY and so what ever > > happens > > to the road, the location of the boundary needs to be checked separately! > > It is > > quite surprising in the UK how many roads are being moved, but that does > > not > > also move the original boundary. > > I see that the separate VS tangled argument has been settled in the US by > the "Duplicate Node attack bots", who have blindly merged all duplicate > nodes. > > http://www.openstreetmap.org/browse/way/38855677 > > When I imported GNIS last year, a fairly significant portion of the data (2-5%) had POI with coordinates exactly the same as another POI (e.g. a post office inside a town hall building). I wonder what these duplicate nod bots are doing with those nodes... ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Admin boundaries tied to roads
On 4/19/10 1:45 PM, Mike N. wrote: > > From an old message: > > >> I take the point that 'road realignment' may >> require the boundary also to move, but the word is MAY and so what ever >> happens >> to the road, the location of the boundary needs to be checked separately! >> It is >> quite surprising in the UK how many roads are being moved, but that does >> not >> also move the original boundary. >> >I see that the separate VS tangled argument has been settled in the US by > the "Duplicate Node attack bots", who have blindly merged all duplicate > nodes. > > http://www.openstreetmap.org/browse/way/38855677 > i don't know if settled is the word for it, the debate is still open, but currently the josm validator reports duplicate nodes as errors, and provides a "fix" button that merges them. it's not fully automated like a bot, but the result is effectively the same. richard ___ 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-19 10:45, Mike N. wrote: > I see that the separate VS tangled argument has been settled in the US by >the "Duplicate Node attack bots", who have blindly merged all duplicate >nodes. > >http://www.openstreetmap.org/browse/way/38855677 Is this really happening? Can someone describe exactly what criteria are being used, and just how it was decided that this was a good idea? Seems like the wrong thing to do - city and county boundaries are often defined in law, or by survey, and do not necessarily keep up with changes in road alignment. I have resisted editing most of these boundaries until/unless I take the time to research the true definition of the boundary. 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. Sounds a lot like the IMO ill-considered road name expansion that was apparently agreed upon by a small group of people without input from the majority of active mappers whose work has been damaged. -- Alan Mintz ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Admin boundaries tied to roads
On 19 Apr 2010, at 20:07 , Alan Mintz wrote: > At 2010-04-19 10:45, Mike N. wrote: >> I see that the separate VS tangled argument has been settled in the US by >> the "Duplicate Node attack bots", who have blindly merged all duplicate >> nodes. >> >> http://www.openstreetmap.org/browse/way/38855677 > > Is this really happening? Can someone describe exactly what criteria are > being used, and just how it was decided that this was a good idea? Seems > like the wrong thing to do - city and county boundaries are often defined > in law, or by survey, and do not necessarily keep up with changes in road > alignment. I have resisted editing most of these boundaries until/unless I > take the time to research the true definition of the boundary. > > 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 > > Sounds a lot like the IMO ill-considered road name expansion that was > apparently agreed upon by a small group of people without input from the > majority of active mappers whose work has been damaged. agreed, no idea why this was done. it's a change without much benefit but lot's of damage. > > -- > Alan Mintz > > > ___ > 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
Hi, Alan Mintz wrote: > At 2010-04-19 10:45, Mike N. wrote: >> I see that the separate VS tangled argument has been settled in the US by >> the "Duplicate Node attack bots", who have blindly merged all duplicate >> nodes. >> >> http://www.openstreetmap.org/browse/way/38855677 > > Is this really happening? Can someone describe exactly what criteria are > being used, and just how it was decided that this was a good idea? It seems that someone is, more or less blindly, using the JOSM validator de-duplication. Doesn't look like a bot but, as Richard said, has similar results. For the record, the proper way of aligning a boundary with a road (at least if the alignment runs for more than a few nodes) is NOT to have the boundary use the same nodes as the road, but instead to create a multipolygon which, on one side, uses the road itself as part of the "outer" ring. (This would also be a very clear expression, data model wise, of the fact that the boundary is defined by the road, instead of accidentally happening to coincide with the road.) This is especially important if you create a mesh of boundaries: There should only ever be *one* way connecting any two nodes, and neighbouring boundary multipolygons would then both use the boundary way as part of their "outer" ring. Of course if you have a very small mesh-like structure like a patch of adjoining buildings then you would probably not make the effort of creating a multipolygon relation for each. But as soon as you are dealing with larger structure, this makes a lot of sense. Bye Frederik ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Admin boundaries tied to roads
On 4/20/10 3:44 AM, Frederik Ramm wrote: > Hi, > > Alan Mintz wrote: > >> At 2010-04-19 10:45, Mike N. wrote: >> >>>I see that the separate VS tangled argument has been settled in the US by >>> the "Duplicate Node attack bots", who have blindly merged all duplicate >>> nodes. >>> >>> http://www.openstreetmap.org/browse/way/38855677 >>> >> Is this really happening? Can someone describe exactly what criteria are >> being used, and just how it was decided that this was a good idea? >> > It seems that someone is, more or less blindly, using the JOSM validator > de-duplication. Doesn't look like a bot but, as Richard said, has > similar results. > given the way that it is currently set up, i'll wager that a lot of less experienced josm users are doing this, because the validator, in its current form, leads them down this path. richard ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Admin boundaries tied to roads
* Frederik Ramm [2010-04-20 09:44 +0200]: > For the record, the proper way of aligning a boundary with a road (at > least if the alignment runs for more than a few nodes) is NOT to have > the boundary use the same nodes as the road, but instead to create a > multipolygon which, on one side, uses the road itself as part of the > "outer" ring. (This would also be a very clear expression, data model > wise, of the fact that the boundary is defined by the road, instead of > accidentally happening to coincide with the road.) How common is it for people to do this? I've seen the idea mentioned in various discussions on the wiki (and I think it's the cleanest approach), but it usually gets people arguing against it on the grounds that it makes the boundary less visible and more vulnerable if, for example, someone makes changes to the road without realizing it's part of the relation. -- ...computer contrarian of the first order... / http://aperiodic.net/phil/ PGP: 026A27F2 print: D200 5BDB FC4B B24A 9248 9F7A 4322 2D22 026A 27F2 --- -- And remember, this fix is only temporary, unless it works. -- Red Green --- -- ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Admin boundaries tied to roads
On 20 April 2010 05:24, Apollinaris Schoell wrote: >> Sounds a lot like the IMO ill-considered road name expansion that was >> apparently agreed upon by a small group of people without input from the >> majority of active mappers whose work has been damaged. > > agreed, no idea why this was done. it's a change without much benefit but > lot's of damage. 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? You can now also write an intelligent search engine that will understand both forms, you can pipe the names through text-to-speach and do a lot more. 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. Cheers ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Admin boundaries tied to roads
On Wed, Apr 21, 2010 at 3:36 PM, andrzej zaborowski wrote: > On 20 April 2010 05:24, Apollinaris Schoell wrote: > >> Sounds a lot like the IMO ill-considered road name expansion that was > >> apparently agreed upon by a small group of people without input from the > >> majority of active mappers whose work has been damaged. > > > > agreed, no idea why this was done. it's a change without much benefit but > lot's of damage. > > 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? You can now also write an > intelligent search engine that will understand both forms, you can > pipe the names through text-to-speach and do a lot more. > > there is damage by doing it wrong, others have pointed to it already. I am not deep enough into the history of the abbreviations used and who defined them. But I am pretty sure there is a lot of errors. - in the city I live there is no street sign with street, avenue, boulevard, and even more surprising there are no abbreviations either. osm principle is to map what's on the ground. So tiger import is definitely wrong and expanding the names is also wrong. on the other hand postal address usually use it in one or the other form so it's not completely fiction. - 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? - all rendered maps use the abbrev names - only text to speech uses full name now all applications except text to speech have to change, where is the advantage? in summary is replacing something "wrong" with something else and still "wrong" a good idea? > 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. > can you provide any stats that mappers spent time on it instead doing anything better? Is the wiki any better as a reference than what is in the osm DB? I could change the wiki and then will someone write a bot to reverse it? Is the wiki written with the situation in US in mind? I am not entirely opposing the bot. But it hasn't been communicated there is no consensus that and how this should be done. osm is a community project and not the playground for one following some wiki page advise. When Frederick came up with the idea of deleting useless tags of tiger import it was discussed and refined until it was what mappers agreed. there was not a single voice opposing it. shoot first ask later is really bad practice > > Cheers > ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Admin boundaries tied to roads
On 22 April 2010 01:18, Apollinaris Schoell wrote: > On Wed, Apr 21, 2010 at 3:36 PM, andrzej zaborowski > 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? You can now also write an >> intelligent search engine that will understand both forms, you can >> pipe the names through text-to-speach and do a lot more. >> > > there is damage by doing it wrong, others have pointed to it already. > I am not deep enough into the history of the abbreviations used and who > defined them. But I am pretty sure there is a lot of errors. I don't know who defined the ones used in TIGER but this is not the only way to abbreviate the names, that is proven by USPS having their own list that is not identical. The most popular words will be the same in both lists but some are really cryptic and arbitrary, could as well be numeric codes. 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. > - in the city I live there is no street sign with street, avenue, boulevard, > and even more surprising there are no abbreviations either. osm > principle is to map what's on the ground. So tiger import is definitely > wrong and expanding the names is also wrong. on the other hand postal > address usually use it in one or the other form so it's not completely > fiction. 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. 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. > - 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? 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. >> 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. > > can you provide any stats that mappers spent time on it instead doing > anything better? Only as an inditaction, I spent a while doing that whenever I visited a place and at least another two people on IRC asked if there was any way to do it automatically, in JOSM or otherwise and we tried to find a way to do it in JOSM or with simple regexes on the .osm file but it seemed a much better idea to do it consistently for the whole area and according to actual documentation that accompanies TIGER. > Is the wiki any better as a reference than what is in the osm DB? I could > change the wiki and then will someone write a bot to reverse it? Is the wiki > written with the situation in US in mind? Well one good rule is if there should be any rules then they should be global. 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. Cheers ___ 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-21 17:12, andrzej zaborowski wrote:
>On 22 April 2010 01:18, Apollinaris Schoell wrote:
> > On Wed, Apr 21, 2010 at 3:36 PM, andrzej zaborowski
> > 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.
Even when travelling to another country, it takes me very little time to
understand what common abbreviations are used for in addresses.
> > there is damage by doing it wrong, others have pointed to it already.
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".
The existing name value should have been put in a foo_name tag so we could
at least see what used to be. I would at least encourage that a bot be run
to find these edits, find the previous version in history, and do this, if
we can't soon agree on a better schema to split the name up into components
at the same time.
> > I am not deep enough into the history of the abbreviations used and who
> > defined them. But I am pretty sure there is a lot of errors.
Errors that I, and a lot of other mappers, painstakingly fixed by hand,
based on ground surveys and research into public records. In particular,
I'm worried about the cases where I spelled out North because it was
actually part of the name, as opposed to a cardinal direction related to
addresses, which I left alone, hoping to later move the latter directions
to a addr:direction_prefix tag, while leaving the former along. I can no
longer distinguish between the two.
>I don't know who defined the ones used in TIGER but this is not the
>only way to abbreviate the names, that is proven by USPS having their
>own list that is not identical. The most popular words will be the
>same in both lists but some are really cryptic and arbitrary, could as
>well be numeric codes. 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.
> > - in the city I live there is no street sign with street, avenue,
> boulevard,
> > and even more surprising there are no abbreviations either. osm
> > principle is to map what's on the ground. So tiger import is definitely
> > wrong and expanding the names is also wrong. on the other hand postal
> > address usually use it in one or the other form so it's not completely
> > fiction.
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.
>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 :( ).
> > - 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 t
Re: [Talk-us] Admin boundaries tied to roads
On Wed, Apr 21, 2010 at 19:24, Alan Mintz wrote:
> 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.
>
> 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.
I'm thinking that most of these proposed fields could be computed if
one has only name_root (currently stored in the database as
tiger:name_base) and spoken_name; if name_root (or root_name or
base_name or whatever) is not a substring of spoken_name then a
Quality Assurance tool could flag it. If andrzej limited changes to
ways with tiger:name_base and kept that field then I don't think any
information was lost.
use_name_direction_prefix seems uncomputable. Also, it suggests that
spoken_name might not coincide with a "full" expansion of name. Are
there examples that tourists from a neighboring state would use? "I-5
North" could be phrased as "Northbound I-5", but I'm guessing you have
other examples in mind.
> 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.
___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Admin boundaries tied to roads
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? > >>> 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. >> >> can you provide any stats that mappers spent time on it instead doing >> anything better? > > Only as an inditaction, I spent a while doing that whenever I visited > a place and at least another two people on IRC asked if there was any > way to do it automatically, in JOSM or otherwise and we tried to find > a way to do it in JOSM or with simple regexes on the .osm file but it > seemed a much better idea to do it consistently for the whole area and > according to actual documentation that accompanies TIGER. > I am impressed 3 people agreed on this process! >> Is the wiki any better as a reference than what is in the osm DB? I could >> change the wiki and then will someone write a bot to reverse it? Is the wiki >> written with the situation in US in mind? > > Well one good rule is if there should be any rules then they should be global. > no not at all. US is very different in many aspects and has to be done different. several countries don't use abbrev names on maps or addresses. Most street names don't even have a st/ave/blvd/ct … postfix at all and so there is no reason to even discuss this topic. And in case they use abbrev it's only when there is a need to shorten. But all official use will be expanded. But in US it looks very much it's the opposite. abbrev is the standard use model and expanded name is the exception > 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. the wiki often has as much agreement as your decision to run this bot. in case you didn't see the irony in my comment again in detail. the wiki isn't a reference in any way. It's just a document and not any better than a message on this list or on IRC or the hard fact of existing data in the planet. everyone can change it, very few people care about the wiki except in germany and it's completely out of sync with real data in planet. > > Cheers ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Admin boundaries tied to roads
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
Re: [Talk-us] Admin boundaries tied to roads
On 22 April 2010 04:24, Alan Mintz wrote: > At 2010-04-21 17:12, andrzej zaborowski wrote: >>On 22 April 2010 01:18, Apollinaris Schoell wrote: >> > On Wed, Apr 21, 2010 at 3:36 PM, andrzej zaborowski >> > 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. (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). > 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". > The existing name value should have been put in a foo_name tag so we could > at least see what used to be. I would at least encourage that a bot be run > to find these edits, find the previous version in history, and do this, if > we can't soon agree on a better schema to split the name up into components > at the same time. 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. > >>I don't know who defined the ones used in TIGER but this is not the >>only way to abbreviate the names, that is proven by USPS having their >>own list that is not identical. The most popular words will be the >>same in both lists but some are really cryptic and arbitrary, could as >>well be numeric codes. 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. > > > > 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. > >> >> 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. The "majority of the data" in this case was an imported dataset that hasn't even been fully reviewed by a human, so while I agree learning by example is a good way to make a quick start, it doesn't mean if you followed the example then it's the only correct way to go. I'm not using wiki as an argument to tell you what you should do, but I think it's a good way to see what others were thinking. I have never edited the Key:name page, and I had never read it before noticing that using abbreviations in a dataset that is supposed to be parseable is a recipe for problems. > > > 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. > > >>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 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. > > 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
Re: [Talk-us] Admin boundaries tied to roads
On 22 April 2010 17:40, Apollinaris Schoell 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. > >>> Is the wiki any better as a reference than what is in the osm DB? I could >>> change the wiki and then will someone write a bot to reverse it? Is the wiki >>> written with the situation in US in mind? >> >> Well one good rule is if there should be any rules then they should be >> global. >> > > no not at all. US is very different in many aspects and has to be done > different. several countries don't use abbrev names on maps or addresses. > Most street names don't even have a st/ave/blvd/ct … postfix at all and so > there is no reason to even discuss this topic. And in case they use abbrev > it's only when there is a need to shorten. But all official use will be > expanded. But in US it looks very much it's the opposite. abbrev is the > standard use model and expanded name is the exception Seriously? I can't think of a single place in Europe where the "street" part is not commonly abbreviated just like what you describe (maybe Germany, but I wouldn't know). Just look at some paper maps or postal addresses, or google, you will very rarely find the names spelled out in full. In the UK it's pretty much like in the US with regard to the feature type suffix (St/Ave...) ([1]) but people have been fixing it in OSM for some time, in Germany I think they use Str. though not sure how commonly. In all the slavic countries "Street" is abbreviated as "ul." prefix and "Avenue" as "al." practically always (just look at Belarus in OSM), in Hungary it's a "Ut." prefix, in Spain "C/" (although the OSM community there agreed to not go with the popular forms and spell everything out and put in any optional articles someone might possibly squeeze in when referring to the street -- basically use the longest form, to avoid ambiguity. So you won't find C/ in OSM even though it's on the signs), in Turkey it's "Sk." for sokak, in Greece it's something like "Od", I don't remember exactly. Someone on IRC yesterday asked whether they should put the Greek names in all caps because the street signs are in all caps. I guess your anwser would be yes, they should? Cheers 1. http://osm.org/go/erdGBcIdM- ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Admin boundaries tied to roads
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. --Brett 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 -Original Message- Date: Mon, 19 Apr 2010 20:24:47 -0700 From: Apollinaris Schoell Subject: Re: [Talk-us] Admin boundaries tied to roads To: Alan Mintz Cc: talk-us@openstreetmap.org Message-ID: Content-Type: text/plain; charset=us-ascii On 19 Apr 2010, at 20:07 , Alan Mintz wrote: > At 2010-04-19 10:45, Mike N. wrote: >> I see that the separate VS tangled argument has been settled in the US by >> the "Duplicate Node attack bots", who have blindly merged all duplicate >> nodes. >> >> http://www.openstreetmap.org/browse/way/38855677 > > Is this really happening? Can someone describe exactly what criteria are > being used, and just how it was decided that this was a good idea? Seems > like the wrong thing to do - city and county boundaries are often defined > in law, or by survey, and do not necessarily keep up with changes in road > alignment. I have resisted editing most of these boundaries until/unless I > take the time to research the true definition of the boundary. > > 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 > > Sounds a lot like the IMO ill-considered road name expansion that was > apparently agreed upon by a small group of people without input from the > majority of active mappers whose work has been damaged. agreed, no idea why this was done. it's a change without much benefit but lot's of damage. > > -- > Alan Mintz ___ 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 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. > --Brett > 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 > > > > -Original Message- > Date: Mon, 19 Apr 2010 20:24:47 -0700 > From: Apollinaris Schoell > Subject: Re: [Talk-us] Admin boundaries tied to roads > To: Alan Mintz > Cc: talk-us@openstreetmap.org > Message-ID: > Content-Type: text/plain; charset=us-ascii > > > On 19 Apr 2010, at 20:07 , Alan Mintz wrote: > >> At 2010-04-19 10:45, Mike N. wrote: >>> I see that the separate VS tangled argument has been settled in the US by >>> the "Duplicate Node attack bots", who have blindly merged all duplicate >>> nodes. >>> >>> http://www.openstreetmap.org/browse/way/38855677 >> >> Is this really happening? Can someone describe exactly what criteria are >> being used, and just how it was decided that this was a good idea? Seems >> like the wrong thing to do - city and county boundaries are often defined >> in law, or by survey, and do not necessarily keep up with changes in road >> alignment. I have resisted editing most of these boundaries until/unless I >> take the time to research the true definition of the boundary. >> >> 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 >> >> Sounds a lot like the IMO ill-considered road name expansion that was >> apparently agreed upon by a small group of people without input from the >> majority of active mappers whose work has been damaged. > > agreed, no idea why this was done. it's a change without much benefit but > lot's of damage. > >> >> -- >> Alan Mintz > > ___ > 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
-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 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 Wed, Apr 21, 2010 at 10:24 PM, Alan Mintz > wrote: > "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. > It's the OSM equivalent of Wikipedia's "no original research" policy. It often gets in the way, and sometimes just has to be ignored, but for a massively collaborative project like OSM it's hard to see how you can do without it. On Thu, Apr 22, 2010 at 12:41 PM, Apollinaris Schoell wrote: > there is a reason for "map what is on the ground" this is the only thing we > can verify. > The term "map what's on the ground" is almost always used in a way which is more restrictive than "map what can be verified". There are plenty of things which can be verified by looking through the legal code or official records, but don't constitute "what's on the ground". The main problem with allowing people to input such information is that it's easily misinterpreted by the average OSM contributor. This is why I see it as analogous to Wikipedia's "no original research". In a perfect world, we wouldn't need it. But in a real world massively collaborative project, unless you're going to have some sort of hierarchy or voting system or something, it often proves to be necessary. 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). ___ 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 10:13 AM, Lord-Castillo, Brett < blord-casti...@stlouisco.com> 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. I assume you're talking about the county/state boundaries, which I can't vouch for one way or the other. The CDPs are mostly horrible. They should have never been added, and now that they have been added they should be removed. ___ 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 wrote: > 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 ___ 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 ___ 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 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 ___ 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 > > > ___ > 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 wrote: >> At 2010-04-21 17:12, andrzej zaborowski wrote: >>>On 22 April 2010 01:18, Apollinaris Schoell wrote: >>> > On Wed, Apr 21, 2010 at 3:36 PM, andrzej zaborowski >>> > 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
Re: [Talk-us] Admin boundaries tied to roads
At 2010-04-23 21:07, Apollinaris Schoell wrote: >what is BAS? any better source will be useful http://www.census.gov/geo/www/bas/bashome.html -- Alan Mintz ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Admin boundaries tied to roads
Hi Alan, On 24 April 2010 06:33, Alan Mintz wrote: > At 2010-04-22 13:09, andrzej zaborowski wrote: > >On 22 April 2010 04:24, Alan Mintz wrote: > >> At 2010-04-21 17:12, andrzej zaborowski wrote: > >>>On 22 April 2010 01:18, Apollinaris Schoell wrote: > >>> > On Wed, Apr 21, 2010 at 3:36 PM, andrzej zaborowski > >>> > 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. Right, but we don't want to be inconsistent or we again have to keep lists of exception to the "normal" rules in every tool. Even if we just wanted to document that on the wiki (or elsewhere, really doesn't need to be wiki) for new mappers, then it would have to say something like "Don't use abbreviations in name=, except final St in English speaking countries and Foo in Bar speaking countries and... and.. and so on..". Let's just avoid this area completely. > > > >(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? Sure you can have a regex for every allowed abbreviation, perhaps a few regexes for some of the more complicated ones like St before names of saints, and then for every language and every source of data, at which point you start having to look at the source= tag or other tags before you can fully interpret name=, because in TIGER data "Stra" at the end is for "Stravenue" while in other places (nominatim's current list of abbreviations) "Stra" at the end is for "Straight". > > > >> 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). Well I can provide you a list of the original names before I touched them with the script along with their id's and versions so you can check if the name has been edited afterwards, if you need to revert these edits. Note the edits also contain hundreds if not thousands of my manual fixes for some frequent typos in TIGER and for some cases of wrong segmentation into "direction_prefix", "base_name" etc. > 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? You have to if you want to give the name to somebody on the phone or find a name someone gave you on the phone. Cheers ___ 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-25 21:14, andrzej zaborowski wrote: >Hi Alan, > >On 24 April 2010 06:33, Alan Mintz wrote: > > At 2010-04-22 13:09, andrzej zaborowski wrote: > > Â >On 22 April 2010 04:24, Alan Mintz wrote: > > Â >> At 2010-04-21 17:12, andrzej zaborowski wrote: > > Â >>>On 22 April 2010 01:18, Apollinaris Schoell > wrote: > > Â >>> > On Wed, Apr 21, 2010 at 3:36 PM, andrzej zaborowski > > > Â >>> > 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. > >Right, but we don't want to be inconsistent or we again have to keep >lists of exception to the "normal" rules in every tool. Even if we >just wanted to document that on the wiki (or elsewhere, really doesn't >need to be wiki) for new mappers, then it would have to say something >like "Don't use abbreviations in name=, except final St in English >speaking countries and Foo in Bar speaking countries and... and.. and >so on..". Let's just avoid this area completely. I'm saying that abbreviations are part of every day life, and locals know what to abbreviate and what not to. The only tool I can see having an issue is text-2-speech in routing, which has to know how to translate some abbreviations, just like existing commercial routing software does. > > Â >(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? > >Sure you can have a regex for every allowed abbreviation, perhaps a >few regexes for some of the more complicated ones like St before names >of saints, and then for every language and every source of data, at >which point you start having to look at the source= tag or other tags >before you can fully interpret name=, because in TIGER data "Stra" at >the end is for "Stravenue" while in other places (nominatim's current >list of abbreviations) "Stra" at the end is for "Straight". How does commercial text-2-speech handle this? I think that forcing non-abbreviation just to handle the few cases of unusual names like these is unnecessary, not to mention that, if I were to review a street with such an unusual abbreviation, I'd probably expand it myself to avoid confusion. I have to look at the wiki all the time to find out what (sometimes peculiar) tag name has been used for a particular feature. Is it really that much to expect mappers in a country to define and/or look at the wiki very occasionally for just a handful of the most common abbreviations that cover >90% of the cases - abbreviations that they already know? They don't even have to do that if they don't want to - they can still use the unabbreviated form. >Well I can provide you a list of the original names before I touched >them with the script along with their id's and versions so you can >check if the name has been edited afterwards, if you need to revert >these edits. Good. We also need to settle on a set of component tags to make best use of the information present in those edits - particularly to separate out cardinal directions from those that are really part of the name. Can we agree for now that, with appropriate local knowledge, it will be acceptable to strip just these prefixes out of the name tag into another tag? Should I propose a set of component tags for a (hopefully quick) vote? The suffixes and root tags could then be populated at the same time (without stripping them from the name). > Note the edits also contain hundreds if not thousands of >my manual fixes for some frequent typos in TIGER and for some cases of >wrong segmentation into "direction_prefix", "base_name" etc. Yup - me too. > > 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? > >You have to if you want to give the name to somebody on the phone or
Re: [Talk-us] Admin boundaries tied to roads
On Mon, 2010-04-26 at 16:31 -0700, Alan Mintz wrote: > Good. We also need to settle on a set of component tags to make best use of > the information present in those edits - particularly to separate out > cardinal directions from those that are really part of the name. Can we > agree for now that, with appropriate local knowledge, it will be acceptable > to strip just these prefixes out of the name tag into another tag? Should I > propose a set of component tags for a (hopefully quick) vote? The suffixes > and root tags could then be populated at the same time (without stripping > them from the name). I second you proposing this. We need to separate out the prefix, suffix and root. Though you need to remember these things when you make your proposal: http://vidthekid.info/misc/osm-abbr.html - Val - ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Admin boundaries tied to roads
I understand that this is a collaborative project, where standards are as much defined by what somebody decides to do as anything else. Neither the wiki pages nor mailing list opinions (or votes) are definitive mandates. Given that, I'll toss my opinion out here. > I'm saying that abbreviations are part of every day life, and locals know > what to abbreviate and what not to. Sure, according to their local usage, which will be inconsistent with local usage in other places. What one local thinks is an obvious abbreviation usage because "everyone knows it" will not be obvious to a map user from elsewhere. > How does commercial text-2-speech handle this? Unabbreviated, better-structured data. > Can we > agree for now that, with appropriate local knowledge, it will be acceptable > to strip just these prefixes out of the name tag into another tag? Supplemental tags are great, but don't remove it from the name tag. Accepted OSM usage is the "name" tag is the complete full name. There are other variations like "local_name" or "alt_name" for the shortened version. > There would have to be both a "Something XYZ" and a "Something > ABC" in the same general area for you to get lost. Apparently you don't have many of these in your local area so you don't seem too concerned about it. My local area? I have them, and it's a pain. > Multiply this by the > already small percentage of both ABC and XYZ being uncommon abbreviations, > and you have a really small set. And keeping unabbreviated data still eliminates this problem completely. To me, it's pretty simple: you can go from more data to less easily (full to abbreviated), but when you extrapolate backwards from less to more you will lose somewhere. Remember the mantra about "don't tag for the renderer"? It's there for a reason. OSM, in philosophy, is not about creating a pretty map. It is about creating an underlying map data set, and creating a pretty map is one of the key uses of it, but not the only one. Printing abbreviations is a job for the renderer. I understand the feeling that "I can't change the renderer myself, but I can change the data entry myself, so that's the right thing for me to do". But it still doesn't make it the best solution. Let's make the data as clear and unambiguous as possible, and if the renderer needs fixing, work on it there. That's my free opinion, worth every penny :-) - Alan Millar ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Admin boundaries tied to roads
Anthony--In MN, it is usually the case that Census MCDs = CDPs = the municipal (legal) boundaries. So, maybe it's best to think of it on a state-by-state basis. Brad On Fri, Apr 23, 2010 at 8:36 PM, Anthony wrote: > On Fri, Apr 23, 2010 at 11:01 AM, Brad Neuhauser > wrote: >> >> 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
On Tue, 2010-04-27 at 10:57 -0700, am12 wrote: > > I'm saying that abbreviations are part of every day life, and locals know > > > what to abbreviate and what not to. > > Sure, according to their local usage, which will be inconsistent with local > usage in other places. What one local thinks is an obvious abbreviation > usage because "everyone knows it" will not be obvious to a map user from > elsewhere. > > > How does commercial text-2-speech handle this? > > Unabbreviated, better-structured data. So, does that mean that street names like "40th Street", for instance should be expanded to "Fortieth Street"? - Val - ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
