Re: [Talk-us] Abbreviation Police
I'm not really speaking for/against abbreviations in general, just adding information. It would definitely be Pkwy and Blvd. The USPS has documented standards for prefixes, suffixes and any other fixes you may want. 208 pages worth: http://pe.usps.com/cpim/ftp/pubs/pub28/pub28.pdf Toby On Tue, Aug 3, 2010 at 1:18 AM, Nathan Edgars II nerou...@gmail.com wrote: On Mon, Aug 2, 2010 at 5:56 PM, Alan Mintz alan_mintz+...@earthlink.net wrote: Yes. Last time, a couple of us (or maybe just me - I forget) argued that it was OK to use common abbreviations for some well-known street types - at least St, Ave, Blvd, Pl, etc. - but the opposition was significant, and no change could be agreed upon. (OT - I wish that recognition of similar opposition in the tiger tag removal were given the same weight) How do you abbreviate Boulevard? Blvd or Bv? How about Parkway? Pkwy, Pky, or Py? The same road (Central Florida Parkway) has all three on signs near its west end. ___ 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] Abbreviation Police
On Tue, Aug 3, 2010 at 2:49 AM, Toby Murray toby.mur...@gmail.com wrote: On Tue, Aug 3, 2010 at 1:18 AM, Nathan Edgars II nerou...@gmail.com wrote: How do you abbreviate Boulevard? Blvd or Bv? How about Parkway? Pkwy, Pky, or Py? The same road (Central Florida Parkway) has all three on signs near its west end. I'm not really speaking for/against abbreviations in general, just adding information. It would definitely be Pkwy and Blvd. The USPS has documented standards for prefixes, suffixes and any other fixes you may want. 208 pages worth: http://pe.usps.com/cpim/ftp/pubs/pub28/pub28.pdf That pretty much negates the reasoning that we should use abbreviations because it's what's on the signs though. I don't have any strong feelings on one side or the other, except that I am opposed to an 'in-between' state of abbreviating some (street, avenue) and not others (parkway, circle) because signs are inconsistent about the latter. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Directional Prefix/Postfix Proposal
One more specific question below: On Mon, 2 Aug 2010, Kevin Atkinson wrote: On Mon, 2 Aug 2010, Alan Mintz wrote: See below for general comments: Some Examples) To encode South 700 East in Salt Lake City: name = S. 700 East name_prefix = included alt_name = South 700 East I would use name = South 700 East name_prefix = S name_prefix_included = yes name_root = 700 name_suffix = E Note, I would not consider East a suffix. name continues to be used for the full expanded name name_prefix_included indicates that the name_prefix is normally given on the signage in front of the name_root, and used in naming a place or giving directions verbally. I don't think the distinction needs to be made between the suffix's inclusion in the name or not (at least I can't think of an example in the places I know to use them - DC and UT). That is, it is always considered in the same way. If that's not the case, name_suffix_included could be used. K Street NW in Washington DC, name = K Street NW name_suffix = included alt_name = K Street Northwest (would anyone really write this?) I'd use: name = K Street Northwest (or is it K Street NorthWest?) name_root = K name_type = St name_suffix = NW Note splitting out the type of street into name_type while we're at it. alt_name = K Street Northwest (would anyone really write this?) I agree, but the abbreviation police held their ground last time we tried this, so... Some examples from southern CA: 1. Most places do not include the directional prefix as part of the signed name. If it is present, it is thought of more as a suffix to the address. It may be shown next to the address range on the signs in that smaller font, not in front of the name in larger font. Current value of name = North Euclid Avenue name = Euclid Avenue name_prefix = N name_root = Euclid name_type = Ave Note that, in many places, TIGER had these prefixes and they were imported as part of the name because TIGER made no distiction between this and case #2 (below). They were then expanded to the incorrect form North Euclid Ave. In this example, the prefix isn't even really a prefix to the name, but instead a suffix to the housenumber, though I'm OK with using the name_prefix tag to avoid confusion. An addr:direction tag would be OK instead. I look forward to being able to fix these once we settle on the schema. 2. Some, however, do use the prefix on the signs and in verbal. The direction appears in front of the name in the same font: name = West 17th Street name_prefix = W name_prefix_included = yes name_root = 17th name_type = St So what does the sign really say: W 17th St, West 17th St, etc? 3. In Rancho Cucamonga, the Victoria Gardens mall has two major streets running through it, named and signed North Mainstreet and South Mainstreet. In this case, North and South, as well as street, are really part of the name root, and not directions or type. This is because they are aligned E/W (90 degrees true) and an address-suffix-style name_prefix would be E or W on such a street, not N or S, and you would expect them to meet at the point where N turns to S, and for the numbering to reverse direction at that point, none of which is true: name = North Mainstreet name_root = North Mainstreet 4. In Rancho Cucamonga, directional prefixes are not used at all. There are no north/south or east/west inflection points. Addresses increase southward and eastward, often through adjoining cities who don't use directions either. Thus, we have a lot of 5-digit addresses. name = Foothill Boulevard name_root = Foothill name_type = Blvd Note that this structure is necessary for example 3, or there would be confusion over having two directional prefixes in an address. 5. Similar to #3 is part of Vermont Avenue, a major N/S artery in Los Angeles. They installed light-rail tracks down the middle of it and turned it into two one-way streets, signed West Vermont Ave and East Vermont Ave. name = West Vermont Avenue name_root = West Vermont name_type = Ave I think it is too many tags. No user is going to enter in all those tags when adding names. I wanted to keep it simple with only two new tags. Most of your other tags can fairly easily be derived using my two tags. I use included rather than yet another tag, to simplify entry and it does not significantly complicate programs which want to make use of the tag. (If the word is included it is fairly simple to extract it from the name.), but I'm not dead set on this. ___ 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] Abbreviation Police
On Tue, Aug 3, 2010 at 2:57 AM, Nathan Edgars II nerou...@gmail.com wrote: On Tue, Aug 3, 2010 at 2:49 AM, Toby Murray toby.mur...@gmail.com wrote: On Tue, Aug 3, 2010 at 1:18 AM, Nathan Edgars II nerou...@gmail.com wrote: How do you abbreviate Boulevard? Blvd or Bv? How about Parkway? Pkwy, Pky, or Py? The same road (Central Florida Parkway) has all three on signs near its west end. I'm not really speaking for/against abbreviations in general, just adding information. It would definitely be Pkwy and Blvd. The USPS has documented standards for prefixes, suffixes and any other fixes you may want. 208 pages worth: http://pe.usps.com/cpim/ftp/pubs/pub28/pub28.pdf That pretty much negates the reasoning that we should use abbreviations because it's what's on the signs though. I don't have any strong feelings on one side or the other, except that I am opposed to an 'in-between' state of abbreviating some (street, avenue) and not others (parkway, circle) because signs are inconsistent about the latter. Inconsistent use on signs, one type of rendering, reinforces that we should use the full name in the database. Other types of rendering, text to speech, Braille, map tiles, high resolution print, may rely on the uniform and full name. Or, at the discretion of that renderer may choose to convert the long form to the short form of their choosing. I see these abbreviation errors in other map products. I have a navigation device that announces County Road 33 as Co-Road Thirty-three Surely we can aspire to do better than propagating the errors of other projects? ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Abbreviation Police
On Tue, Aug 3, 2010 at 9:11 AM, Richard Weait rich...@weait.com wrote: I see these abbreviation errors in other map products. I have a navigation device that announces County Road 33 as Co-Road Thirty-three Surely we can aspire to do better than propagating the errors of other projects? I've heard county aitch double-you why four twenty-three from in-car navigation. I've also seen TIGER errors such as Cord (one word) for County Road, or Logging Road for LR (a Legislative Route system that existed in Pennsylvania until 1987). (The latter is of course an improper expansion; we need to be careful when expanding.) ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Would Like To Clean Salt Lake City Street Names
I'm almost done with this script. It's not a full bot, but instead modifies an osm file which I will read back into JOSM and upload the changed parts (or if that doesn't work use one of the upload scripts). Changes in what It will do noted below. On Sat, 31 Jul 2010, Kevin Atkinson wrote: Salt Lake City street names are a bit of a mess. They are often several redundant names: name = South 900 East name_1 = 900 East name_2 = South 900 East (an extra space) and sometimes: name_3 = 9th East I would like to write a bot (or semi-automated plugin for JOSM) to clean up Sale Lake City Street Names so that they follow the following convention: 1) The name tag shall include the primary street name as signed, _without_ the directional prefix, but with the direction (really part of the street name and not a suffix) spelled out, for example 900 East. The street signs do not generally include the directional prefix, and the prefix is generally not considered part of the name. They are only used when forming an address. Unchanged. I know the prefix may make forming addresses easier, but they are _not_ part of the name and _not_ signed that way in Salt Lake City, so I am removing the prefix. Also, most printed maps _do not_ include the prefix. 2) A new tag name_prefix, shall contain the directional prefix as one of N, S, E, or W. (I will document this tag on the wiki) Changed to name.prefix after noticing a proposal to use the . to specify prop. of a tag. This will be very easy to fix if a different convention is agreed upon. 3) The alt_name tag shall include the full name with prefix, for example South 900 East. This is primary to aid the name finder, I'm assuming it won't get displayed on the map. This is now name.full 4) The loc_name tag shall the #th name (ie 9th East) when the street is a multiple of 100, as that form of the name is also very commonly used. Unchanged. 5) The name_1 tag shell include the other signed named for a street (for example Broadway for 300 South) when one exists. 6) The alt_name_* tags shall include any other names found in the name_* tags which I can't make sense of. These can be hand checked later. I'm not going to do this. Instead I am going to simply remove variants on name (for example all other names in the 900 East example). And than leave all other name_* and *_name alone (i.e. name_1, alt_name, etc). When the alternate name is a numbered street, it will get the .prefix and .full tags. For example: name: Lorna Circle name_1: 3805 South name_1.prefix: W name_1.full: West 3805 South ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Would Like To Clean Salt Lake City Street Names
On Tue, Aug 3, 2010 at 4:05 PM, Kevin Atkinson ke...@atkinson.dhs.org wrote: I'm almost done with this script. It's not a full bot, but instead modifies an osm file which I will read back into JOSM and upload the changed parts (or if that doesn't work use one of the upload scripts). Changes in what It will do noted below. [ ... ] I'm not going to do this. Instead I am going to simply remove variants on name (for example all other names in the 900 East example). And than leave all other name_* and *_name alone (i.e. name_1, alt_name, etc). When the alternate name is a numbered street, it will get the .prefix and .full tags. For example: name: Lorna Circle name_1: 3805 South name_1.prefix: W name_1.full: West 3805 South Whoa. Are you considering adding a period . to the key? Might that mess up postgres? From http://www.postgresql.org/docs/8.2/static/sql-syntax-lexical.html The period (.) is used in numeric constants, and to separate schema, table, and column names. Perhaps bounce some of these ideas around on dev? ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Would Like To Clean Salt Lake City Street Names
On Tue, Aug 3, 2010 at 3:57 PM, Richard Weait rich...@weait.com wrote: On Tue, Aug 3, 2010 at 4:05 PM, Kevin Atkinson ke...@atkinson.dhs.org wrote: I'm almost done with this script. It's not a full bot, but instead modifies an osm file which I will read back into JOSM and upload the changed parts (or if that doesn't work use one of the upload scripts). Changes in what It will do noted below. [ ... ] I'm not going to do this. Instead I am going to simply remove variants on name (for example all other names in the 900 East example). And than leave all other name_* and *_name alone (i.e. name_1, alt_name, etc). When the alternate name is a numbered street, it will get the .prefix and .full tags. For example: name: Lorna Circle name_1: 3805 South name_1.prefix: W name_1.full: West 3805 South Whoa. Are you considering adding a period . to the key? Might that mess up postgres? From http://www.postgresql.org/docs/8.2/static/sql-syntax-lexical.html The period (.) is used in numeric constants, and to separate schema, table, and column names. Perhaps bounce some of these ideas around on dev? I imagine the Ruby code is doing the proper escaping for text like this, but you're right: definitely worth a message to the dev list. Not that it matters too much to the majority of the OSM community, but a period in the key name is invalid for most NoSQL-based systems (MongoDB in particular). ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Would Like To Clean Salt Lake City Street Names
On Tue, 3 Aug 2010, Richard Weait wrote: Whoa. Are you considering adding a period . to the key? Might that mess up postgres? From http://www.postgresql.org/docs/8.2/static/sql-syntax-lexical.html The period (.) is used in numeric constants, and to separate schema, table, and column names. Perhaps bounce some of these ideas around on dev? I just asked and it won't create a problem anywhere. But, . is never used anywhere. So for now I am going to use ':' instead. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Would Like To Clean Salt Lake City Street Names
On Tue, 3 Aug 2010, Val Kartchner wrote: On Tue, 2010-08-03 at 14:05 -0600, Kevin Atkinson wrote: I'm almost done with this script. It's not a full bot, but instead modifies an osm file which I will read back into JOSM and upload the changed parts (or if that doesn't work use one of the upload scripts). Changes in what It will do noted below. Go ahead and finish the script, but don't run it until we get a consensus here. No one really objected that strongly and I am specially limited the scope of what it does. I plan to run it tomorrow unless I get some strong objections. The only slightly controversial part might be the removal of the directional prefix. But this is very easy to undue. 6) The alt_name_* tags shall include any other names found in the name_* tags which I can't make sense of. These can be hand checked later. I'm not going to do this. Instead I am going to simply remove variants on name (for example all other names in the 900 East example). And than leave all other name_* and *_name alone (i.e. name_1, alt_name, etc). When the alternate name is a numbered street, it will get the .prefix and .full tags. For example: name: Lorna Circle name_1: 3805 South name_1.prefix: W name_1.full: West 3805 South Here is an instance where there are several names for a street: Antelope Drive is also 1700 South. East of 2000 West it is also State Highway 108, and west it is State Highway 127. Also, through Syracuse it is signed as Syracuse Road. (I'm still investigating the signs to see exactly what portions should be so labeled.) This means that some sort of numbered alternatives need to be in the OSM database. So, which set of tags do we use: name_* or alt_name_*? Whichever it is, it needs to be standardized. This should be done worldwide. As I was trying to get at, my script specially does not address this. I leave the name tags alone for the most part. I saw a lot of this in the data I was working with and most of it will require manual cleanup. Perhaps a more specific example of what it does would help. Something is clearly wrong with this tagging. But since i don't know what to do with out I just clean it up a little. http://www.openstreetmap.org/browse/way/10128991 IN: name: South 6130 West name_1: South 2nd West name_2: South 200 West OUT: name: 6130 West name:prefix: S name:full: South 6130 West name_1: 200 West name_1:prefix: S name_1:full: South 200 West Notice how name_2 is gone, as that is redundant. To really fix it the way most likely it needs to be split in two. Here is another mess: http://www.openstreetmap.org/browse/way/10140212 IN: name: East Ninth South Circle name_1: 9th South Circle name_2: East 900 South name_3: East 9th South name_4: East 900 South OUT: name: East Ninth South Circle name_1: 9th South Circle name_2: 900 South name_2:prefix: E name_2:full: East 900 South So here, more could be done, but that can always be cleaned up better later. And finally here is a nice clean case: IN: name: East 900 South name_1: East 900 South name_2: East 9th South OUT: name: 900 South name:prefix: E name:full: East 900 South loc_name: 9th South ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Abbreviation Police
OK. So There is clearly no agreement on the abbreviation of road types (Street, Way, etc). So what about these specific exceptions. I will assume silence means agreement :) Rather than United Stated Highway 29 Frontage Road just U.S. 29 Frontage Road or maybe US 29 Frontage Road. Why. Because no will say the formal out load. Rather than Interstate 95 Frontage Road, just I-95 Frontage Road. Why? Even though some will say the formal, most just say the letter I. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Abbreviation Police
On 3 Aug 2010, at 22:32 , Kevin Atkinson wrote: OK. So There is clearly no agreement on the abbreviation of road types (Street, Way, etc). So what about these specific exceptions. I will assume silence means agreement :) Rather than United Stated Highway 29 Frontage Road just U.S. 29 Frontage Road or maybe US 29 Frontage Road. Why. Because no will say the formal out load. most of the times I see it name=Frontage Road ref=US 29 this will be rendered in similar way as on other maps. Name is on the street and US, I, is on a shield. Doesn't make sense to duplicate the ref on the name. for the rest of the proposed changes in previos mails of the thread I'd say go ahead and do the changes. Rather than Interstate 95 Frontage Road, just I-95 Frontage Road. Why? Even though some will say the formal, most just say the letter I. ___ 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] Abbreviation Police
On Tue, 3 Aug 2010, Kevin Atkinson wrote: OK. So There is clearly no agreement on the abbreviation of road types (Street, Way, etc). So what about these specific exceptions. I will assume silence means agreement :) So to be clear. This mail has nothing to do with my proposed changes, or any of my other mail. I am just trying to figure out where we stand on the abbreviation issue. Rather than United Stated Highway 29 Frontage Road just U.S. 29 Frontage Road or maybe US 29 Frontage Road. Why. Because no will say the formal out load. Rather than Interstate 95 Frontage Road, just I-95 Frontage Road. Why? Even though some will say the formal, most just say the letter I. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
