Re: [Talk-us] Feature proposal: proposed expanded address tagging scheme for US

[Bill R. WASHBURN]

How would this proposal treat The By Way NE (way 9186730)? Would it be
completely broken down with "By" being by itself? Would it treat it like
TIGER does, with "The By" separate from "Way"? Neither case makes sense for
the local colloquial or for GPS device name searches.

I can see strict adherence to the proposal leading to complete butchering
the recognition of the road name if the search engine isn't updated to
recognize that there are additional fields. If the name is left as complete
in the name and addr:street fields, I'm not sure that I understand the
utility of the proposal (but I'm not personally opposed to an overabundance
of data, as long as the burden to maintain that data doesn't outweigh it's
utility).

Here's a thought: how would this differ from just leaving the TIGER data
tags attached to the way? (In which my earlier example of North Decatur
Road is incorrectly broken down as "N" "Decatur" and "Rd" ... see way
80428428)

I think I'm echoing an earlier call to more clearly state the problem in
the proposal so that we understand what the proposal aims to solve. I think
I'm also echoing calls for the proposal to more clearly define how existing
data is to be treated, for the sake of clarity.




On Thu, Nov 22, 2012 at 1:40 PM, Alan Millar  wrote:

> There are two fundamental questions (to me) in this issue which have not
> been explicitly asked or answered, either on the list or the wiki:
>
> - Will the "addr:street" tag on the address node or way have the exact
> same value as the "name" tag on the street way?
>
> - Are you proposing to remove directional prefixes and suffixes from the
> "addr:street" and "name" tags, or leave it with the fully-qualified
> complete value?
>
> I will start by saying that, to the first question, any proposal to put
> different values on "addr:street" on address nodes and "name" on the
> road is just plain stupid.  That will make no end of trouble in trying
> to do anything useful like routing.  So for this proposal, the stance
> should be state clearly.
>
> To the second question:  I absolutely, fundamentally disagree that these
> prefixes and suffixes should be removed from the "name" and
> "addr:street" tags.  Doing so is exactly what WILL make the names
> ambiguous.  The name and addr:street tags should be full and complete
> with all prefixes, suffixes, and qualifiers.
>
> But the name and addr:street needs to be COMPLETE, since it is the
> universal lowest common denominator.  The proposal to redefine the
> "name" tag as something less than the complete full name is not new.
> Kevin Atkinson has been redefining the name tag by removing prefixes
> from street names all over Salt Lake City for a while now.
>
> I'm really not understanding the arguments about naming ambiguity.  I
> looked at Hickory NC.  Two streets named "10th Street Place Northwest"
> and "10th Street Drive Northwest" are clearly different.  What is
> ambiguous there?  Four streets named either "10th" or "10th Street" with
> other tags to differentiate them will DEFINITELY be ambiguous.
>
> I think it is a great idea to add additional tags to specify prefixes,
> suffixes, or base names.  I personally would like to see those added (or
> left/converted from Tiger tags).  It would be great to see mkgmap
> enhanced to optimize prefixes and suffixes, for example.
>
> HOWEVER, having said all of this, I think the basic proposal for these
> address tags is just a bad idea.  Let me explain why.  All of the values
> for the street name components, on every address node, should be the
> same for all address nodes on the street.  That could be dozens or
> hundreds for every single street in the country.  Why duplicate these
> tags on every address node?  You can GUARANTEE that the nodes will not
> be consistent; some users will maintain them one way, and some will
> maintain them another.
>
> A better way to do all of this is to have all of these new supplemental
> tags on the street way, and simply have the addr:street tag use the same
> value as the "name" tag on the street way.  Or, use the associatedStreet
> relation.
>
> I know the hope is that some yet-to-be conjured tools will encourage or
> enforce the consistency across all the address nodes on a street.  Such
> yet-to-be-created tool could just as well ensure that the values go with
> a proper street way, or an associatedStreet relation.
>
> Please, Please, PLEASE do not change or redefine the "name" and
> "addr:street" tags.  They aren't overloaded, they are COMPLETE and
> UNAMBIGUOUS.
>
> Add whatever tags in addition you want.  If you really want to add a
> million new tags on address nodes everywhere, I won't stop anyone, but I
> think it is redundancy that would be better handled on the street way.
>
> - Alan
>
>
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-us
>
___
Talk-us mailing lis

Re: [Talk-us] Feature proposal: proposed expanded address tagging scheme for US

[Alan Millar]

There are two fundamental questions (to me) in this issue which have not
been explicitly asked or answered, either on the list or the wiki:

- Will the "addr:street" tag on the address node or way have the exact
same value as the "name" tag on the street way?

- Are you proposing to remove directional prefixes and suffixes from the
"addr:street" and "name" tags, or leave it with the fully-qualified
complete value?

I will start by saying that, to the first question, any proposal to put
different values on "addr:street" on address nodes and "name" on the
road is just plain stupid.  That will make no end of trouble in trying
to do anything useful like routing.  So for this proposal, the stance
should be state clearly.

To the second question:  I absolutely, fundamentally disagree that these
prefixes and suffixes should be removed from the "name" and
"addr:street" tags.  Doing so is exactly what WILL make the names
ambiguous.  The name and addr:street tags should be full and complete
with all prefixes, suffixes, and qualifiers.

But the name and addr:street needs to be COMPLETE, since it is the
universal lowest common denominator.  The proposal to redefine the
"name" tag as something less than the complete full name is not new.
Kevin Atkinson has been redefining the name tag by removing prefixes
from street names all over Salt Lake City for a while now.

I'm really not understanding the arguments about naming ambiguity.  I
looked at Hickory NC.  Two streets named "10th Street Place Northwest"
and "10th Street Drive Northwest" are clearly different.  What is
ambiguous there?  Four streets named either "10th" or "10th Street" with
other tags to differentiate them will DEFINITELY be ambiguous.

I think it is a great idea to add additional tags to specify prefixes,
suffixes, or base names.  I personally would like to see those added (or
left/converted from Tiger tags).  It would be great to see mkgmap
enhanced to optimize prefixes and suffixes, for example.  

HOWEVER, having said all of this, I think the basic proposal for these
address tags is just a bad idea.  Let me explain why.  All of the values
for the street name components, on every address node, should be the
same for all address nodes on the street.  That could be dozens or
hundreds for every single street in the country.  Why duplicate these
tags on every address node?  You can GUARANTEE that the nodes will not
be consistent; some users will maintain them one way, and some will
maintain them another.

A better way to do all of this is to have all of these new supplemental
tags on the street way, and simply have the addr:street tag use the same
value as the "name" tag on the street way.  Or, use the associatedStreet
relation.

I know the hope is that some yet-to-be conjured tools will encourage or
enforce the consistency across all the address nodes on a street.  Such
yet-to-be-created tool could just as well ensure that the values go with
a proper street way, or an associatedStreet relation.

Please, Please, PLEASE do not change or redefine the "name" and
"addr:street" tags.  They aren't overloaded, they are COMPLETE and
UNAMBIGUOUS.

Add whatever tags in addition you want.  If you really want to add a
million new tags on address nodes everywhere, I won't stop anyone, but I
think it is redundancy that would be better handled on the street way.

- Alan



___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Feature proposal: proposed expanded address tagging scheme for US

[Steven Johnson]

I understand what you're saying. It is a nice solution, but it's not
without trade offs.  In the very short run, relations are difficult for new
mappers, both conceptually and using the existing tools to create and
maintain them. In the longer run, I think our editing tools will improve,
hopefully in ways that remove the barriers for new users and make relations
less brittle.

-- SEJ
-- twitter: @geomantic
-- skype: sejohnson8

"Common sense is the collection of prejudices acquired by age eighteen." --
Einstein



On Wed, Nov 21, 2012 at 4:51 PM, Apollinaris Schöll wrote:

> relations seem to be a elegant solution for people with technology
> background. And all your arguments are good ones
>
> BUT they have quite some disadvantages. Too many non techies have problems
> to get the concept right. As a result they break existing relations or they
> are scared away from editing osm. osm should be easy to use for many and
> creating a technology barrier for newcomers is dangerous.
> On top of that many editors have limited or broken support. As far as I
> know only JOSM and P2 have solid and well tested relation support.
>
> For a data consumer it's a challenge too. relations are a lot harder to
> process. And even if an application adds relation support it still can't
> drop the other scheme(s)
>
>
> On Wed, Nov 21, 2012 at 12:19 PM, Mark Gray  wrote:
>
>> The discussion about how to tag a street name is important
>> whether the tags are on the street or in an address.
>>
>> Can we move toward using relations instead of tagging the street
>> name in each address?
>>
>> Copying the street name into each address is problematic.
>> If we hope to some day have all addresses in OSM, I hope we can
>> come up with a more efficient and consistent way to store a street
>> name, however many tags are used for it, only once per section of
>> same-named street.
>>
>> There are some proposals for how to do this with relations:
>>
>> http://wiki.openstreetmap.org/wiki/Relation:associatedStreet
>> http://wiki.openstreetmap.org/wiki/Relations/Proposed/Street
>> http://wiki.openstreetmap.org/wiki/Relations/Proposed/Collected_Ways
>>
>> All of these solve the street name duplication in each address and some
>> also may solve name duplication across different ways of the street.
>>
>> In taginfo, I see there is already some use:
>> 86023 instances of associatedStreet
>> 14921 instances of Street
>> This is still small compared with:
>> 15461897 addr:street
>>
>> Every time I tag addr:street, I wonder how well it works. What
>> will happen when someone decides to expand the name of the street
>> or edit a prefix or suffix? How does an address stay associated
>> with a street when the link between them, the name, can be edited
>> in either place while no change is made to all the other things on
>> this street? Each addr:street could contain its own unintentional
>> variation of the street name.
>>
>> Now that we have embraced relations for highway routes, can we do
>> something similar for street names in addresses?
>>
>> --
>> Mark Gray
>> http://code.google.com/p/vataviamap/
>>
>> ___
>> 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
>
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Feature proposal: proposed expanded address tagging scheme for US

[Richard Welty]

On 11/21/12 4:16 PM, Steven Johnson wrote:

Second, Richard, please see Carl's post which talks about the proposal from
the standpoint of emergency services. Carl could likely say what the pros &
cons are of splitting the tags vs loading everything in the addr:street tag.

i did read Carl's post. it's good on the philosophical issue, but i'm 
interested

in realistic use cases.

what specific problems in emergency response are addressed by this?
problems in the 911 call center? problems in dispatch? problems in the
actual response on the street?

what real world processes are broken now that are fixed/improved by this 
change?


richard


___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Feature proposal: proposed expanded address tagging scheme for US

[Paul Norman]

> From: Mark Gray [mailto:mark-os...@hspf.com]
> Subject: Re: [Talk-us] Feature proposal: proposed expanded address
> tagging scheme for US
> 
> In taginfo, I see there is already some use:
> 86023 instances of associatedStreet
> 14921 instances of Street
> This is still small compared with:
> 15461897 addr:street
> 
> Every time I tag addr:street, I wonder how well it works. What will
> happen when someone decides to expand the name of the street or edit a
> prefix or suffix? How does an address stay associated with a street when
> the link between them, the name, can be edited in either place while no
> change is made to all the other things on this street? Each addr:street
> could contain its own unintentional variation of the street name.

Having talked to people who process the data for use with geocoding,
addr:street is a lot more robust than associatedStreet relations and a lot
easier to process.

Auto-complete helps with name consistency. 

I think the reason is that addr:street can be broken each time the name of a
road changes while associatedStreet can be broken each time someone edits
the street or address for any reason.

Although addresses aren't fixed in practice streets aren't often renamed and
every way split has a good chance of breaking the relation.


___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Feature proposal: proposed expanded address tagging scheme for US

[Richard Welty]

On 11/21/12 5:48 PM, Frederik Ramm wrote:

Hi,

On 21.11.2012 22:51, Apollinaris Schöll wrote:

relations seem to be a elegant solution for people with technology
background. And all your arguments are good ones

BUT they have quite some disadvantages. Too many non techies have
problems to get the concept right. As a result they break existing
relations or they are scared away from editing osm.


It is very common for "IT types" to request dropping of addr:street & 
co in favour of an "associatedStreet" relation or similar - it makes 
perfect sense from the perspective of a database designer. But every 
time we respond essentially with Apo's words above - nothing beats 
addr:street in terms of sheer simplicity for everyone involved.
i concur. theoretically i like the notion of associatedStreet, but with 
current editors
(both the human editors and the tools they use), it's more than a little 
fragile, much

more likely to get broken than a route relation.

richard


___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Feature proposal: proposed expanded address tagging scheme for US

[Frederik Ramm]

Hi,

On 21.11.2012 22:51, Apollinaris Schöll wrote:

relations seem to be a elegant solution for people with technology
background. And all your arguments are good ones

BUT they have quite some disadvantages. Too many non techies have
problems to get the concept right. As a result they break existing
relations or they are scared away from editing osm. osm should be easy
to use for many and creating a technology barrier for newcomers is
dangerous.
On top of that many editors have limited or broken support. As far as I
know only JOSM and P2 have solid and well tested relation support.

For a data consumer it's a challenge too. relations are a lot harder to
process. And even if an application adds relation support it still can't
drop the other scheme(s)


+1.

It is very common for "IT types" to request dropping of addr:street & co 
in favour of an "associatedStreet" relation or similar - it makes 
perfect sense from the perspective of a database designer. But every 
time we respond essentially with Apo's words above - nothing beats 
addr:street in terms of sheer simplicity for everyone involved.


Bye
Frederik

--
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Feature proposal: proposed expanded address tagging scheme for US

[Apollinaris Schöll]

relations seem to be a elegant solution for people with technology
background. And all your arguments are good ones

BUT they have quite some disadvantages. Too many non techies have problems
to get the concept right. As a result they break existing relations or they
are scared away from editing osm. osm should be easy to use for many and
creating a technology barrier for newcomers is dangerous.
On top of that many editors have limited or broken support. As far as I
know only JOSM and P2 have solid and well tested relation support.

For a data consumer it's a challenge too. relations are a lot harder to
process. And even if an application adds relation support it still can't
drop the other scheme(s)

On Wed, Nov 21, 2012 at 12:19 PM, Mark Gray  wrote:

> The discussion about how to tag a street name is important
> whether the tags are on the street or in an address.
>
> Can we move toward using relations instead of tagging the street
> name in each address?
>
> Copying the street name into each address is problematic.
> If we hope to some day have all addresses in OSM, I hope we can
> come up with a more efficient and consistent way to store a street
> name, however many tags are used for it, only once per section of
> same-named street.
>
> There are some proposals for how to do this with relations:
>
> http://wiki.openstreetmap.org/wiki/Relation:associatedStreet
> http://wiki.openstreetmap.org/wiki/Relations/Proposed/Street
> http://wiki.openstreetmap.org/wiki/Relations/Proposed/Collected_Ways
>
> All of these solve the street name duplication in each address and some
> also may solve name duplication across different ways of the street.
>
> In taginfo, I see there is already some use:
> 86023 instances of associatedStreet
> 14921 instances of Street
> This is still small compared with:
> 15461897 addr:street
>
> Every time I tag addr:street, I wonder how well it works. What
> will happen when someone decides to expand the name of the street
> or edit a prefix or suffix? How does an address stay associated
> with a street when the link between them, the name, can be edited
> in either place while no change is made to all the other things on
> this street? Each addr:street could contain its own unintentional
> variation of the street name.
>
> Now that we have embraced relations for highway routes, can we do
> something similar for street names in addresses?
>
> --
> Mark Gray
> http://code.google.com/p/vataviamap/
>
> ___
> 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] Feature proposal: proposed expanded address tagging scheme for US

[Steven Johnson]

Hi all,

Two things:

First, thanks Mark, for a very useful suggestion. I need to think about it,
but I think it has merit from the standpoint of streamlining the address
assignment process, as well as keeping address points in sync with their
associated streets.

Second, Richard, please see Carl's post which talks about the proposal from
the standpoint of emergency services. Carl could likely say what the pros &
cons are of splitting the tags vs loading everything in the addr:street tag.

Happy Thanksgiving, everyone,

-- SEJ
-- twitter: @geomantic
-- skype: sejohnson8

"Common sense is the collection of prejudices acquired by age eighteen." --
Einstein



On Wed, Nov 21, 2012 at 3:19 PM, Richard Welty wrote:

> ok, thanks, carl. this helps. i'm working on an emergency services related
> project
> right now and it's helpful to learn about these things.
>
> the next question is this. supposing we implement Steven's proposal, how
> does
> this help in emergency services mapping projects, that is, what does this
> breakout
> facilitate for us?
>
> richard
>
>
> On 11/20/12 10:05 PM, Carl Anderson wrote:
>
>> All,
>>
>> This proposal is a good thing, provided that it does not deprecate current
>> tagging uses.
>>
>> >From my experiences in emergency services (911), emergency management
>> (FEMA
>> and State/County EMA), and location finding I find that it is often very
>> important to know what the colloquial core phrase of an address is.
>>
>> A "Colloquial core phrase" is something we all use everyday.  We shorten
>> names down to a useful, but still meaningful, core.
>> If I were to say that I was at 14th and K, many of my DC friends would
>> know
>> that I was at the intersection of 14 St NW and K St NW.
>> My friends who are not familiar with DC could guess the location given a
>> bit of prompting.
>>
>> In easy cases it is easy to determine the "colloquial core phrase" of an
>> address.
>> Sometimes however, it is not easy to guess the correct local use for a
>> street name or address.
>>
>> For instance my friends in Alpharetta, GA all know that North Point Mall
>> Blvd is not the North version of Point Mall Blvd, but instead is the Blvd
>> at North Point Mall.  My friends farther away from Alpharetta, GA probably
>> don't know this.
>>
>> Additionally, many times I have seen St. Lo Dr. mangled by well
>> intentioned
>> people into Street Lo Drive or once and a while into Street Lo Doctor.  Of
>> course Saint-Lô is is a well known place in France with a name derived
>> from
>> Saint Laud.
>> Consider how often people mangle the intersection roads "Boulevard" and
>> "Boulevard Drive" in Atlanta, GA.  It is about even how well intentioned
>> people convert both names into one of the two valid choices.
>>
>> Steven's proposal creates a mechanism for local knowledge and local
>> colloquial use to be added into OSM.  In turn this data, when present,
>> will
>> allow people who interact with the public to better understand the intent
>> of the public in a more precise fashion.
>>
>> The parsing steps move the bits that are not part of the core into well
>> known tags that can be unambiguously dealt with.
>> The unambiguous aspect is equally important as abbreviation usage is often
>> lossy.  For instance some US jurisdictions use BL as an abbreviation for
>> Boulevard and others use BL for Bluff.  (In the emergency services world
>> hilarity does not ensue).  If OSM had such names as "Braided Blanket
>> Bluff"
>> in the proposed tagging scheme
>>
>>
>> If we were to use the proposal as additional tags to the current existing
>> tags people could add to OSM data to the limit of their local knowledge
>> and
>> when they knew the common local usage could, correctly, completely and
>> unambiguously fill out the parsed tags that Steven has proposed.
>>
>> C.
>>
>>
>>
>>
>>
>
> __**_
> 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] Feature proposal: proposed expanded address tagging scheme for US

[Richard Welty]

ok, thanks, carl. this helps. i'm working on an emergency services 
related project

right now and it's helpful to learn about these things.

the next question is this. supposing we implement Steven's proposal, how 
does
this help in emergency services mapping projects, that is, what does 
this breakout

facilitate for us?

richard

On 11/20/12 10:05 PM, Carl Anderson wrote:

All,

This proposal is a good thing, provided that it does not deprecate current
tagging uses.

>From my experiences in emergency services (911), emergency management (FEMA
and State/County EMA), and location finding I find that it is often very
important to know what the colloquial core phrase of an address is.

A "Colloquial core phrase" is something we all use everyday.  We shorten
names down to a useful, but still meaningful, core.
If I were to say that I was at 14th and K, many of my DC friends would know
that I was at the intersection of 14 St NW and K St NW.
My friends who are not familiar with DC could guess the location given a
bit of prompting.

In easy cases it is easy to determine the "colloquial core phrase" of an
address.
Sometimes however, it is not easy to guess the correct local use for a
street name or address.

For instance my friends in Alpharetta, GA all know that North Point Mall
Blvd is not the North version of Point Mall Blvd, but instead is the Blvd
at North Point Mall.  My friends farther away from Alpharetta, GA probably
don't know this.

Additionally, many times I have seen St. Lo Dr. mangled by well intentioned
people into Street Lo Drive or once and a while into Street Lo Doctor.  Of
course Saint-Lô is is a well known place in France with a name derived from
Saint Laud.
Consider how often people mangle the intersection roads "Boulevard" and
"Boulevard Drive" in Atlanta, GA.  It is about even how well intentioned
people convert both names into one of the two valid choices.

Steven's proposal creates a mechanism for local knowledge and local
colloquial use to be added into OSM.  In turn this data, when present, will
allow people who interact with the public to better understand the intent
of the public in a more precise fashion.

The parsing steps move the bits that are not part of the core into well
known tags that can be unambiguously dealt with.
The unambiguous aspect is equally important as abbreviation usage is often
lossy.  For instance some US jurisdictions use BL as an abbreviation for
Boulevard and others use BL for Bluff.  (In the emergency services world
hilarity does not ensue).  If OSM had such names as "Braided Blanket Bluff"
in the proposed tagging scheme


If we were to use the proposal as additional tags to the current existing
tags people could add to OSM data to the limit of their local knowledge and
when they knew the common local usage could, correctly, completely and
unambiguously fill out the parsed tags that Steven has proposed.

C.







___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Feature proposal: proposed expanded address tagging scheme for US

[Mark Gray]

The discussion about how to tag a street name is important
whether the tags are on the street or in an address.

Can we move toward using relations instead of tagging the street
name in each address?

Copying the street name into each address is problematic.
If we hope to some day have all addresses in OSM, I hope we can
come up with a more efficient and consistent way to store a street 
name, however many tags are used for it, only once per section of
same-named street.

There are some proposals for how to do this with relations:

http://wiki.openstreetmap.org/wiki/Relation:associatedStreet
http://wiki.openstreetmap.org/wiki/Relations/Proposed/Street
http://wiki.openstreetmap.org/wiki/Relations/Proposed/Collected_Ways

All of these solve the street name duplication in each address and some
also may solve name duplication across different ways of the street.

In taginfo, I see there is already some use:
86023 instances of associatedStreet
14921 instances of Street
This is still small compared with:
15461897 addr:street

Every time I tag addr:street, I wonder how well it works. What
will happen when someone decides to expand the name of the street
or edit a prefix or suffix? How does an address stay associated
with a street when the link between them, the name, can be edited
in either place while no change is made to all the other things on
this street? Each addr:street could contain its own unintentional
variation of the street name.

Now that we have embraced relations for highway routes, can we do
something similar for street names in addresses?

-- 
Mark Gray
http://code.google.com/p/vataviamap/

___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Feature proposal: proposed expanded address tagging scheme for US

[Serge Wroclawski]

On Tue, Nov 20, 2012 at 10:05 PM, Carl Anderson
 wrote:

> A "Colloquial core phrase" is something we all use everyday.  We shorten
> names down to a useful, but still meaningful, core.
> If I were to say that I was at 14th and K, many of my DC friends would know
> that I was at the intersection of 14 St NW and K St NW.
> My friends who are not familiar with DC could guess the location given a bit
> of prompting.

> Steven's proposal creates a mechanism for local knowledge and local
> colloquial use to be added into OSM.  In turn this data, when present, will
> allow people who interact with the public to better understand the intent of
> the public in a more precise fashion.
>
> The parsing steps move the bits that are not part of the core into well
> known tags that can be unambiguously dealt with.
> The unambiguous aspect is equally important as abbreviation usage is often
> lossy.  For instance some US jurisdictions use BL as an abbreviation for
> Boulevard and others use BL for Bluff.  (In the emergency services world
> hilarity does not ensue).  If OSM had such names as "Braided Blanket Bluff"
> in the proposed tagging scheme

Carl,

First, in your example of "14th and K", there is no such address as
14th and K, but rather this is a geocoded location. This is important,
but not related to the proposal. In other words, the proposal doesn't
change this fact (nor does it address the fact that OSM doesn't have a
geocoder that can handle intersections).

Secondly, regarding street names, we have existing extensive support
for multiple names, including local names, international names,
previous names, etc:

http://wiki.openstreetmap.org/wiki/Names

In fact this proposal would complicate the addresses by taking each
name's street and breaking it up into many more tags.

> If we were to use the proposal as additional tags to the current existing
> tags people could add to OSM data to the limit of their local knowledge and
> when they knew the common local usage could, correctly, completely and
> unambiguously fill out the parsed tags that Steven has proposed.

After weeks working with the OSM data in the US, looking specifically
at the interaction of TIGER tags with the "name" tag, I can say
definitively that this is a bad idea.

On the one hand, Steven's proposal is saying that the "name" tag is
derived data- that it is the result of a summation of different
components (the direction prefix, the name base, the road type, the
direction suffix). And on the other, you're suggesting that the
existing use of "name" could be preserved.

We have an existing test case for this using the TIGER dataset in the
US, and the fact is that people do not keep the two synchronized. We
have tiger  tags which have not been touched, but the name is updated,
and we have tiger tags which have been changed, but are changed
incorrectly.

- Serge

___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Feature proposal: proposed expanded address tagging scheme for US

[Carl Anderson]

All,

This proposal is a good thing, provided that it does not deprecate current
tagging uses.

>From my experiences in emergency services (911), emergency management (FEMA
and State/County EMA), and location finding I find that it is often very
important to know what the colloquial core phrase of an address is.

A "Colloquial core phrase" is something we all use everyday.  We shorten
names down to a useful, but still meaningful, core.
If I were to say that I was at 14th and K, many of my DC friends would know
that I was at the intersection of 14 St NW and K St NW.
My friends who are not familiar with DC could guess the location given a
bit of prompting.

In easy cases it is easy to determine the "colloquial core phrase" of an
address.
Sometimes however, it is not easy to guess the correct local use for a
street name or address.

For instance my friends in Alpharetta, GA all know that North Point Mall
Blvd is not the North version of Point Mall Blvd, but instead is the Blvd
at North Point Mall.  My friends farther away from Alpharetta, GA probably
don't know this.

Additionally, many times I have seen St. Lo Dr. mangled by well intentioned
people into Street Lo Drive or once and a while into Street Lo Doctor.  Of
course Saint-Lô is is a well known place in France with a name derived from
Saint Laud.
Consider how often people mangle the intersection roads "Boulevard" and
"Boulevard Drive" in Atlanta, GA.  It is about even how well intentioned
people convert both names into one of the two valid choices.

Steven's proposal creates a mechanism for local knowledge and local
colloquial use to be added into OSM.  In turn this data, when present, will
allow people who interact with the public to better understand the intent
of the public in a more precise fashion.

The parsing steps move the bits that are not part of the core into well
known tags that can be unambiguously dealt with.
The unambiguous aspect is equally important as abbreviation usage is often
lossy.  For instance some US jurisdictions use BL as an abbreviation for
Boulevard and others use BL for Bluff.  (In the emergency services world
hilarity does not ensue).  If OSM had such names as "Braided Blanket Bluff"
in the proposed tagging scheme


If we were to use the proposal as additional tags to the current existing
tags people could add to OSM data to the limit of their local knowledge and
when they knew the common local usage could, correctly, completely and
unambiguously fill out the parsed tags that Steven has proposed.

C.






On Sat, Nov 17, 2012 at 6:45 PM, Steven Johnson wrote:

> Hi all,
> Following up on an action from SotM-PDX, I've posted a proposal for
> expanded tagging for addresses, primarily in the US (though it may have
> application in other countries). The intent of the tags is to 1) improve
> the description of US addresses, and 2) provide greater flexibility for
> local mappers. These tags are necessary because unlike other countries, the
> US has no nationwide house numbering/street naming standard. These tags
> provide more granularity for local mappers and hopefully, will reduce much
> of the ambiguity and confusion with addresses in localities with widely
> varying address schemes.
>
> I invite your comments and discussion on the proposed tags. Thanks.
>
>
> http://wiki.openstreetmap.org/wiki/Proposed_features/House_numbers/UnitedStates
>
> -- SEJ
> -- twitter: @geomantic
> -- skype: sejohnson8
>
> "Common sense is the collection of prejudices acquired by age eighteen."
> -- Einstein
>
>
> ___
> 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] Feature proposal: proposed expanded address tagging scheme for US

[Phil! Gold]

* Steven Johnson  [2012-11-17 18:45 -0500]:
> http://wiki.openstreetmap.org/wiki/Proposed_features/House_numbers/UnitedStates

>From my perspective, addr:street_prefix and addr:street_type don't seem
that useful, since I don't see how they add information that's useful to
data consumers and they require extra work from data contributers.
If I understand things, the proposal would take a way tagged with
"name=Old Frederick Road" and add "addr:street_prefix=Old,
addr:street_type=Road".  What benefit is there to that?  (Put differently,
what motivation can you give to convince mappers that it's worth their
time to add those tags on every road whose name they modify?)

It's also worth considering how a tagging scheme can be broken.  It's not
uncommon for contributors to edit one tag and fail to notice related tags
on the same object.  How would you suggest handling, say, "name=Wentworh
Avenue, addr:street_type=Road"?

I do think there's a use case for directional prefixes that are not
strictly part of the road name, but are instead for addressing.  Many
parts of the US have roads with addresses of the form "10 North Something
Street" where the road signs emphasize "Something Street" and the "North"
or "South" parts are less visible.  (I've seen many roads in my area where
the signs for such roads are not even consistent in terms of whather it's
a prefix or suffix; adjacent signs might show both "N Something St" and
"Something St N".)  In these cases, I think it would be beneficial to have
tagging of the form "name=Something Street, addr:direction=North" so
routers can tell people things like, "Turn left on Something Street,"
which reflects the signage, but geocoders can figure out where addresses
are likely to be even in the absence of complete address information.
(This sort of usage would require proposing changes to address tagging, as
well as road tagging.)

___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Feature proposal: proposed expanded address tagging scheme for US

[Bill R. WASHBURN]

Since my email client sent my messages direct to the OP and not to the
list, I'm going to resend them:

First response:
-

We have to be careful that the availability of this granularity doesn't
insecure the road names, specifically in cases where part of the road name
could be confused as a prefix or suffix. Let me throw a few usage cases for
the metro Atlanta area out to illustrate.

Cobb county uses the quadrant suffix system where everything in the part of
the county closest to the city of Atlanta gets a SW suffix. Most of the
time, locals ignore the suffix. Separating the suffix makes sense in this
context since it is treated as secondary information by locals.

One place where I can see a non-invasive goofing up our local roads is
North Decatur Road. That road is named after the North Decatur area through
which it runs, as best I can tell from my local knowledge, therefore making
"North" part of the name of the road and not a prefix. Locals, when giving
directions, treat the name as North Decatur, always including, North as
part of the name. You'll never hear a local send someone to Decatur Road.
Breaking North away from Decatur does not make sense in this context (and
the local transit agency confuses locals, me included, by making this
mistake on the time table charts on their website).

Similarly, The By Way is a road for which separating the prefix, "The," the
name, "By," and the road type, "Way," doesn't make grammatical sense and
the road is not mentioned without the while name. As a local mapper, I
would not want this name broken up since, in our hyper-local context, it
does not make sense to do so.

(Compare the second and third cases to East Ponce de Leon Avenue, locally
shortened to Ponce or Ponce de Leon. The directional prefix and road type
are treated as secondary, discardable information in local speech.)

--

Second response:
--

I'm less than enthusiastic about regionally specific tags but it's feasible
to me that other areas may find this proposal useful.

Would you be opposed to just splitting off the directional prefixes and
suffixes, thereby leaving the road type and name prefix combined with the
name? I think, to me, that it's important to leave the information that
uniquely identified the road together. In my never-humble opinion, only
splitting out the directional would balance my concern for keeping the name
as complete as possible and splitting out the information which is,
contextually, secondary information.

-

And now an inline response:

On Sun, Nov 18, 2012 at 6:35 PM, Paul Norman  wrote:
>
> My understanding from the SOTM-US talk is that he proposes redefining what
> the name tag means and that for a street like "K Street NW" the name of
> that
> street is simply K.


If this is the reason for the change, I'm going to argue against it: to me,
the full official street name is the one with all of the prefixes and
suffixes. I can see cases, as I quoted in my first two responses, where a
distant armchair mapper with decent intentions might override local
knowledge about the word "North" in the road name "North Decatur Road." I
think that I'm of the opinion that, if this is implemented as supplementary
tags, we can display this like the tiger import tags did, breaking down the
street name into it's techical parts. The problems that this proposal might
introduce include reprogramming the navigation packages to recognize the
old way and the proposed way of structuring street names; the last thing I
need, while listening to my navigation software give directions, is to be
told, "Turn right on to By," when the correct direction is, "Turn right on
to The By Way."

I think that it's an interesting way of looking at the data, but I don't
think the current way of writing the street name introduces ambiguity.
Actually, I think the proposed way could add ambiguity for software which
is not programmed for the proposed method. Try navigating around the Metro
Atlanta area with the road name "Peachtree" separated from the road type
"Street" or "Place" or one of the other oodles of Peachtree-something
combinations (again, from software not adapted to this proposal).
___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Feature proposal: proposed expanded address tagging scheme for US

[Paul Norman]

> From: Serge Wroclawski [mailto:emac...@gmail.com]
> Subject: Re: [Talk-us] Feature proposal: proposed expanded address
> tagging scheme for US
> 
> > Since local conditions vary so
> > widely across the US, having more tags gives mappers more flexibility
> > to tag what they see.
> 
> How does it give them more flexibility to tag what they see? Are you
> suggesting that this replace (rather than supplement) the "name" tag?

My understanding from the SOTM-US talk is that he proposes redefining what
the name tag means and that for a street like "K Street NW" the name of that
street is simply K.


___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Feature proposal: proposed expanded address tagging scheme for US

[Clifford Snow]

Steve,
I suggest you start your proposal with a problem statement and then explain
how your solution solves the problem. Otherwise it looks to me to be a
solution looking for a problem. Do we have any data to suggest that the
current street addresses do not work? Why is it just a US problem?

If you provide a problem statement then we can have a discussion about 1)
is it a real problem and how big is it and 2) what is the best way to solve
the problem.

Clifford


On Sat, Nov 17, 2012 at 3:45 PM, Steven Johnson wrote:

> Hi all,
> Following up on an action from SotM-PDX, I've posted a proposal for
> expanded tagging for addresses, primarily in the US (though it may have
> application in other countries). The intent of the tags is to 1) improve
> the description of US addresses, and 2) provide greater flexibility for
> local mappers. These tags are necessary because unlike other countries, the
> US has no nationwide house numbering/street naming standard. These tags
> provide more granularity for local mappers and hopefully, will reduce much
> of the ambiguity and confusion with addresses in localities with widely
> varying address schemes.
>
> I invite your comments and discussion on the proposed tags. Thanks.
>
>
> http://wiki.openstreetmap.org/wiki/Proposed_features/House_numbers/UnitedStates
>
> -- SEJ
> -- twitter: @geomantic
> -- skype: sejohnson8
>
> "Common sense is the collection of prejudices acquired by age eighteen."
> -- Einstein
>
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-us
>
>


-- 
Clifford

I have promised to cut down on my swearing and drinking, which I have.
 Unfortunately, this has left me dim-witted and nearly speechless. Adapted
from *The Lion* by Nelson DeMille

-or-

If you can't explain it simply, you don't understand it well enough.
 Albert Einstein
___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Feature proposal: proposed expanded address tagging scheme for US

[Serge Wroclawski]

Steven,

Thanks for the reply.

More inline.

On Sun, Nov 18, 2012 at 3:08 PM, Steven Johnson  wrote:
> Richard & Serge,
>
> Thanks for the comments. Let me see if I can clarify...
>
> The problem: Unlike other (mostly European) countries, there are at least 4
> street naming schemes, and 2 property numbering schemes in the US. This
> makes a set of one-size-fits-all tags for addresses both unwieldy,
> imprecise, and ambiguous.
>
> It forces local mappers to overload the
> addr:street tag with directional prefixes, suffixes, and street types. It
> perpetuates ambiguity and lessens the value of the data, as well as
> constraining mappers from adequately describing local conditions.

You gave one example, which I'll address later in the mail, but more
examples makes your case more salient.

> The solution: splitting out the tags has several advantages:
> 1) Increase the descriptive power of the tags. Specific tags make the parts
> of the address absolutely clear, and make it easier to distinguish places
> with similar addresses.

This is one I'm not sure I get, so let's discuss it.

Let's use a real world example (other than the one you use later):

Are you saying it reduces the ambiguity between K Street NW and K
Street SE (in Washington, DC)?

If this would be your example (and I don't know if it is) then I don't
see how it reduces ambiguity, since the name of the street will be
different.

> 2) Provide local mappers with greater specificity and ability to accurately
> tag local conditions. Lumping directionals and street types into addr:street
> obscures local characteristics of addresses.

What kind of local characteristics?

> Since local conditions vary so
> widely across the US, having more tags gives mappers more flexibility to tag
> what they see.

How does it give them more flexibility to tag what they see? Are you
suggesting that this replace (rather than supplement) the "name" tag?

> 3) Remove ambiguity. Look closely at these streets in Hickory, NC and you'll
> see what I mean by ambiguous names and types:
> http://www.openstreetmap.org/?lat=35.75139&lon=-81.35898&zoom=17&layers=M

You keep using the word "ambiguity" but the names appear to be unique
to me- strange, but unique.

> 4) Facilitates supervised imports of address data. I know imports are
> fraught with difficulty (and I'm not explicitly advocating address imports),
> but it is important to note that agencies that manage address data almost
> certainly will have prefix, name, type, suffix broken out.

How does it facilitate import of address data?

And please address the issues #2- users actually using this format.

That's the key feature- will human beings do it?

- Serge

___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Feature proposal: proposed expanded address tagging scheme for US

[Steven Johnson]

Bill,
That's good info; nice to have some local examples. There are numerous
examples like, "South East Lake Drive" where directionals could be confused
with names. A couple more that come to me off the top of my head...

1) Charlotte, NC has a road called, "The Plaza".
2) Richmond, VA has a road called simply, "Boulevard".

No, you wouldn't want those names broken up either, but you'd want the
ability to unambiguously specify whatever local convention happens to be.

Thanks for weighing in,


-- SEJ
-- twitter: @geomantic
-- skype: sejohnson8

"Common sense is the collection of prejudices acquired by age eighteen." --
Einstein



On Sun, Nov 18, 2012 at 3:55 PM, Bill R. WASHBURN wrote:

> We have to be careful that the availability of this granularity doesn't
> insecure the road names, specifically in cases where part of the road name
> could be confused as a prefix or suffix. Let me throw a few usage cases for
> the metro Atlanta area out to illustrate.
>
> Cobb county uses the quadrant suffix system where everything in the part
> of the county closest to the city of Atlanta gets a SW suffix. Most of the
> time, locals ignore the suffix. Separating the suffix makes sense in this
> context since it is treated as secondary information by locals.
>
> One place where I can see a non-invasive goofing up our local roads is
> North Decatur Road. That road is named after the North Decatur area through
> which it runs, as best I can tell from my local knowledge, therefore making
> "North" part of the name of the road and not a prefix. Locals, when giving
> directions, treat the name as North Decatur, always including, North as
> part of the name. You'll never hear a local send someone to Decatur Road.
> Breaking North away from Decatur does not make sense in this context (and
> the local transit agency confuses locals, me included, by making this
> mistake on the time table charts on their website).
>
> Similarly, The By Way is a road for which separating the prefix, "The,"
> the name, "By," and the road type, "Way," doesn't make grammatical sense
> and the road is not mentioned without the while name. As a local mapper, I
> would not want this name broken up since, in our hyper-local context, it
> does not make sense to do so.
>
> (Compare the second and third cases to East Ponce de Leon Avenue, locally
> shortened to Ponce or Ponce de Leon. The directional prefix and road type
> are treated as secondary, discardable information in local speech.)
> On Nov 18, 2012 3:09 PM, "Steven Johnson"  wrote:
>
>> Richard & Serge,
>>
>> Thanks for the comments. Let me see if I can clarify...
>>
>> The problem: Unlike other (mostly European) countries, there are at least
>> 4 street naming schemes, and 2 property numbering schemes in the US. This
>> makes a set of one-size-fits-all tags for addresses both unwieldy,
>> imprecise, and ambiguous. It forces local mappers to overload the
>> addr:street tag with directional prefixes, suffixes, and street types. It
>> perpetuates ambiguity and lessens the value of the data, as well as
>> constraining mappers from adequately describing local conditions.
>>
>> The solution: splitting out the tags has several advantages:
>> 1) Increase the descriptive power of the tags. Specific tags make the
>> parts of the address absolutely clear, and make it easier to distinguish
>> places with similar addresses.
>>
>> 2) Provide local mappers with greater specificity and ability to
>> accurately tag local conditions. Lumping directionals and street types into
>> addr:street obscures local characteristics of addresses. Since local
>> conditions vary so widely across the US, having more tags gives mappers
>> more flexibility to tag what they see.
>>
>> 3) Remove ambiguity. Look closely at these streets in Hickory, NC and
>> you'll see what I mean by ambiguous names and types:
>> http://www.openstreetmap.org/?lat=35.75139&lon=-81.35898&zoom=17&layers=M
>>
>>
>> 4) Facilitates supervised imports of address data. I know imports are
>> fraught with difficulty (and I'm not explicitly advocating address
>> imports), but it is important to note that agencies that manage address
>> data almost certainly will have prefix, name, type, suffix broken out.
>>
>> Thanks again for the comments. Hopes these comments help make the case
>> for expanded tagging.
>>
>> -- SEJ
>> -- twitter: @geomantic
>> -- skype: sejohnson8
>>
>> "Common sense is the collection of prejudices acquired by age eighteen."
>> -- Einstein
>>
>>
>>
>> On Sun, Nov 18, 2012 at 12:41 PM, Richard Welty 
>> wrote:
>>
>>> i'm sort of on the fence here. perhaps Steven could outline the use
>>> cases for this expanded format;
>>> what becomes possible with it that is not possible or is more difficult
>>> with the current schema?
>>>
>>> richard
>>>
>>>
>>> __**_
>>> Talk-us mailing list
>>> Talk-us@openstreetmap.org
>>> http://lists.openstreetmap.**org/listinfo/talk-us

Re: [Talk-us] Feature proposal: proposed expanded address tagging scheme for US

[Steven Johnson]

Richard & Serge,

Thanks for the comments. Let me see if I can clarify...

The problem: Unlike other (mostly European) countries, there are at least 4
street naming schemes, and 2 property numbering schemes in the US. This
makes a set of one-size-fits-all tags for addresses both unwieldy,
imprecise, and ambiguous. It forces local mappers to overload the
addr:street tag with directional prefixes, suffixes, and street types. It
perpetuates ambiguity and lessens the value of the data, as well as
constraining mappers from adequately describing local conditions.

The solution: splitting out the tags has several advantages:
1) Increase the descriptive power of the tags. Specific tags make the parts
of the address absolutely clear, and make it easier to distinguish places
with similar addresses.

2) Provide local mappers with greater specificity and ability to accurately
tag local conditions. Lumping directionals and street types into
addr:street obscures local characteristics of addresses. Since local
conditions vary so widely across the US, having more tags gives mappers
more flexibility to tag what they see.

3) Remove ambiguity. Look closely at these streets in Hickory, NC and
you'll see what I mean by ambiguous names and types:
http://www.openstreetmap.org/?lat=35.75139&lon=-81.35898&zoom=17&layers=M

4) Facilitates supervised imports of address data. I know imports are
fraught with difficulty (and I'm not explicitly advocating address
imports), but it is important to note that agencies that manage address
data almost certainly will have prefix, name, type, suffix broken out.

Thanks again for the comments. Hopes these comments help make the case for
expanded tagging.

-- SEJ
-- twitter: @geomantic
-- skype: sejohnson8

"Common sense is the collection of prejudices acquired by age eighteen." --
Einstein



On Sun, Nov 18, 2012 at 12:41 PM, Richard Welty wrote:

> i'm sort of on the fence here. perhaps Steven could outline the use cases
> for this expanded format;
> what becomes possible with it that is not possible or is more difficult
> with the current schema?
>
> richard
>
>
> __**_
> 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] Feature proposal: proposed expanded address tagging scheme for US

[Richard Welty]

i'm sort of on the fence here. perhaps Steven could outline the use 
cases for this expanded format;
what becomes possible with it that is not possible or is more difficult 
with the current schema?


richard


___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Feature proposal: proposed expanded address tagging scheme for US

[Serge Wroclawski]

Steven,

Thanks for writing this proposal out. I'm one of the people who asked
you to write it up. I think you've given us all a lot to think about.
And while I appreciate the work you've put into this, I don't think
this proposal should become a tagging standard, and I hope that my
explanation rises to the same level as your thoughtful proposal:

I have a few minor points of question, but really, after having looked
at the US roads, I wonder two things about this proposal:

1. Does it add value?

And maybe more importantly:

2. Will individuals contribute data in this new, proposed format?

It's important, when we think about tagging,to consider both issues,
and the second over the first.

1. What is a street name?

To most of us, it's a unique identifier. While in some places, street
types have meaning (eg in Manhattan, streets run east<->west, avenues
north<->south), in most places, the street types themselves do not
contain any additional information about the road.

And even in places where the road type label is meaningful, this
meaning has to be entered, and there's nothing in the proposal to
address this meaning, which makes it "interesting" but not "useful".

The direction tags are somewhat interesting, but I wonder what their
utility is. In a place like Manhattan, the direction tag lets you know
whether you're east or west of 5th Avenue (or Central Park), and in
DC, it lets you know the quadrant you're in. But for this to be useful
to, say a geocoder, it needs additional information which the proposal
does not provide.

So then why separate out the values?

2. Will this proposal be used?

This is the more important of the two questions.

Right now, the biggest source of this information comes from the TIGER
tags. The TIGER tags match this proposal nearly tag for tag, so a
conversion would be very simple.

But the question in my mind is "Will this be used outside TIGER?" - ie
by users (and potentially by an import process).

The OSM tagging community has a history of proscriptive tagging,
whereas if you look at the tags which actually get used and adopted,
most of them are the ones which are in use first, then get documented,
or which get used, and then get put in an editor and used by a larger
community.

What these tags have in common is simplicity- providing information in
the most simple way possible, even if its at the expense of detail.
The other thing they have in common is they provide information that's
not already captured.

This proposal takes one field "name" and split it into six fields.

It would seem that people would be disinclined to fill out this many
fields vs the one field.

So maybe you can give some more of your thinking in your proposal
about why this needs to be there, and if we see any usage outside
TIGER/the US[1].

- Serge

[1] If it's just TIGER, then we already have this data in TIGER fields[2]

[2] Except where people have edited the TIGER fields, which you see
more than you might expect.

___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us