Re: [Talk-us] Feature proposal: proposed expanded address tagging scheme for US
On Tue, Nov 20, 2012 at 10:05 PM, Carl Anderson carl.ander...@vadose.org 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
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
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
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 rwe...@averillpark.netwrote: 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-ushttp://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
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 mark-os...@hspf.com 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
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
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
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
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
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 ascho...@gmail.comwrote: 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 mark-os...@hspf.com 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
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 sejohns...@gmail.comwrote: 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
* Steven Johnson sejohns...@gmail.com [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, 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 dygitulju...@gmail.comwrote: 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 sejohns...@gmail.com 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.75139lon=-81.35898zoom=17layers=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 rwe...@averillpark.netwrote: 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-ushttp://lists.openstreetmap.org/listinfo/talk-us ___ Talk-us mailing list Talk-us@openstreetmap.org
Re: [Talk-us] Feature proposal: proposed expanded address tagging scheme for US
Steven, Thanks for the reply. More inline. On Sun, Nov 18, 2012 at 3:08 PM, Steven Johnson sejohns...@gmail.com 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.75139lon=-81.35898zoom=17layers=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
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 sejohns...@gmail.comwrote: 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
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
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 penor...@mac.com 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
