Re: [Talk-us] Street Naming Conventions
* David ``Smith'' vidthe...@gmail.com [2010-05-14 23:58 -0400]: 5) The value of addr:street=* should contain the abbreviated form of the street name according to USPS standards, regardless of the way the street name is signed. The point of addr:street is to associate the address to a particular road, so its value needs to match the name of the road. (There's also the associatedStreet relation, but more people use the addr:street tag.) -- ...computer contrarian of the first order... / http://aperiodic.net/phil/ PGP: 026A27F2 print: D200 5BDB FC4B B24A 9248 9F7A 4322 2D22 026A 27F2 --- -- I believe there are 15,747,724,136,275,002,577,605,653,961,181,555,468, 044,717,914,527,116,709,366,231,425,076,185,631,031,296 protons in the universe and the same number of electrons. -- Sir Arthur Eddington --- -- ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Street Naming Conventions
Hi, Phil! Gold wrote: * David ``Smith'' vidthe...@gmail.com [2010-05-14 23:58 -0400]: 5) The value of addr:street=* should contain the abbreviated form of the street name according to USPS standards, regardless of the way the street name is signed. The point of addr:street is to associate the address to a particular road, No. The point of addr:street is always related to addressing. If a building happens to be on road A but for some strange reason the postal address of the building uses road B, then addr:street should always have road B. The whole point of addr:* is postal addresses. Sometimes people seem to forget or ignore that, and issue addr:street even for things that do not have addresses (a tree an be on X road but it will not usually have a postal address so it should never have an addr:street tag). Bye Frederik ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Street Naming Conventions
Do Old Olive Street Rd and Old Olive St Rd have overlapping street numbers? No, then the street number distinguishes location. If Yes then do the rest of the address match up? No this time then the rest of the address distinguishes location. If Yes again, someone messed up the street naming. Unless someone messed up, either one should work. If it is a continous road, I would standardize on one name. Personally I would use Old Olive Street Rd As far as searches go, the engine just needs to be smart enough to try matching the various full words and abbreviations, and offer a choice if more than one results turn up. Dale On Mon, May 17, 2010 at 8:29 PM, Nathan Oliver oliver.nat...@gmail.comwrote: I happen to know the answer to this one. I'll save Brett the trouble of replying again, and point you to an earlier explanation in this thread. (Though being so long, I don't blame you for not seeing it the first time around.) http://lists.openstreetmap.org/pipermail/talk-us/2010-April/003087.html It seems really odd to me, too, but it's not the first time customs have developed in odd ways... Nathan Oliver On 5/17/2010 7:01 PM, Nathan Edgars II wrote: Dale Puch wrote: On Mon, May 17, 2010 at 4:44 PM, Nathan Edgars II neroute2 at gmail.comwrote: Lord-Castillo, Brett wrote: But another good one close to us is Old Olive Street Rd and Old Olive St Rd (both official names for different sections of the road). These two streets run parallel to Olive St, Olive Street Rd, and Olive Blvd (all three of these are different roads). So if Old Olive Street Rd and Old Olive St Rd are different, how do you distinguish them in speech? Or are they actually interchangeable names, as would seem logical (in other words, one or the other may be official, but both are unambiguous and correct for all practical purposes)? If Old Olive Street Rd and Old Olive St Rd are one road, ie. connected and not and a corner. Then things that may explain it are different addresses where they intersect, or if they are in different jurisdictions. Like where two cities meet. But if the addressing continues between the different names, then it seem one sign is wrong. I personally think Old Olive Street Rd should be used, and only cardinal direction prefix and type suffix abbreviated. The rest being the core name. I'm not sure what you mean - if you tell someone I live at 50 Old Olive Street Rd, how is that any different from I live at 50 Old Olive St Rd? (Obviously one would need to specify which city the address is in, if the official name changes at the city line. But, without the city name, neither of those statements, even written, would be truly unambiguous, since the reader can't assume the chosen Street or St is identical to the official usage. In fact, if we do name these segments differently, it could cause more confusion, since someone typing one might be taken to the official match when they wanted the other one and didn't realize they were officially different.) As for abbreviations, there's no consistent way to abbreviate. Around here, you'll see Parkway, Pkwy, Pky, and Py all used for the same road. And directional prefixes are part of the address, appearing above the block number in a separate square on street signs. ___ 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] Street Naming Conventions
On Tue, May 18, 2010 at 10:39 AM, Phil! Gold phi...@pobox.com wrote: * David ``Smith'' vidthe...@gmail.com [2010-05-14 23:58 -0400]: 5) The value of addr:street=* should contain the abbreviated form of the street name according to USPS standards, regardless of the way the street name is signed. The point of addr:street is to associate the address to a particular road, so its value needs to match the name of the road. (There's also the associatedStreet relation, but more people use the addr:street tag.) As Frederik already asserted, that's incorrect. But if for some reason you need to associate an object with a street without using an AssociatedStreet relation, you could always give the street its own addr:street tag with the same value as all of the objects along it, which uses the same USPS-based abbreviation. But I'm not sure what is accomplished by associating objects with the street they're on. (As far as I know, the original point of the associatedStreet relation was to automatically imply addr:street values for all of the objects by using the street's name or addr:street value. What you said is kind of backwards from that.) -- David Smith a.k.a. Vid the Kid a.k.a. Bír'd'in Does this font make me look fat? ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Street Naming Conventions
I always go with my classic example (which all of the major online map services currently render incorrectly): North Outer 40 Road (which runs adjacent to and parallel to interstate 64). The name of the road is North Outer 40. The type is Road. It is named this because Interstate 64 used to be US Highway 40, and the road was set up to run parallel to Highway 40 on both side of the highway when it was a highway. The highway is now an interstate, but the reference to 40 was kept (so Forty is incorrect and it is not an address number). The road runs east-west mostly, but also runs north-south for an extensive stretch. South Outer 40 Rd runs alongside the south side of the interstate. As for parsing type, I've always liked the street that our EOC is on (see below). Depending on which part of the address you get, you might think the street type was Dr, Xing, Blfs or even the ever popular Xing Dr. But another good one close to us is Old Olive Street Rd and Old Olive St Rd (both official names for different sections of the road). These two streets run parallel to Olive St, Olive Street Rd, and Olive Blvd (all three of these are different roads). If you have street name by itself and full name, then I could see possibly deriving all of these correctly. The problem comes when people interpret the street name incorrectly (e.g. North Outer 40, Outer 40, 40, Outer, North Outer; Ladue, Ladue Bluffs, Ladue Bluffs Crossing; Olive, Olive Street, Olive St, Old Olive, Old Olive St, Old Olive Street. Not sure if four separate fields will create more data entry errors, or will create more attention to detail. Brett Lord-Castillo Information Systems Designer/GIS Programmer St. Louis County Police Office of Emergency Management 14847 Ladue Bluffs Crossing Drive Chesterfield, MO 63017 Office: 314-628-5400 Fax: 314-628-5508 Direct: 314-628-5407 -Original Message- Message: 1 Date: Fri, 14 May 2010 13:16:22 -0700 From: Richard Finegold goldfndr+...@gmail.com Subject: Re: [Talk-us] Street Naming Conventions To: val...@gmail.com Cc: OSM Talk US talk-us@openstreetmap.org Message-ID: aanlktilw2noozfia8jd4eftva07ucytpfe73dt_pu...@mail.gmail.com Content-Type: text/plain; charset=ISO-8859-1 On Mon, May 10, 2010 at 20:18, Val Kartchner val...@gmail.com wrote: This topic has been dropped without it having been resolved. ?We still need some way of addressing the issues summarized in http://vidthekid.info/misc/osm-abbr.html;. ?This can be summarized as needing to create fields for: ?direction prefix ?street name ?street type ?direction suffix This is needed for exactly the same reason that no abbreviations are supposed to be used in OSM: There is no automated way to fix the parts of a street name. For instance, here are some actual addresses which occur in this area: ?Number ?Prefix ?Street Name ? ? ? ? ?Type ? ?Suffix ?200 ? ? West ? ?North Temple ? ? ? ? Street ?200 ? ? East ? ?South Temple ? ? ? ? Street ?200 ? ? North ? West Temple ? ? ? ? ?Street ?50 ? ? ?East ? ?North Lakeview ? ? ? Drive ?50 ? ? ?East ? ?South Lakeview ? ? ? Drive ?2450 ? ?North ? E ? ? ? ? ? ? ? ? ? ?Street ?300 ? ? ? ? ? ? Southgate ? ? ? ? ? ?Drive ?4700 ? ?West ? ?3300 ? ? ? ? ? ? ? ? Street ?South These are just samples, but others on this list have come up with other examples that demonstrate the problems with the current way of doing things. ?Also, in the last example given above, the Type and Suffix would be swapped, but in most written addresses the Type would be dropped. I'll again claim that just one field would be enough -- the street name -- and the other three can be derived from their offsets; trivial for direction prefix, and slightly more complicated (requiring a dictionary/list of directions, anything left over goes into the street type field) for the latter two. Can you offer any examples where these three would be difficult to derive if one was provided only full name and street name? ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Street Naming Conventions
If Old Olive Street Rd and Old Olive St Rd are one road, ie. connected and not and a corner. Then things that may explain it are different addresses where they intersect, or if they are in different jurisdictions. Like where two cities meet. But if the addressing continues between the different names, then it seem one sign is wrong. I personally think Old Olive Street Rd should be used, and only cardinal direction prefix and type suffix abbreviated. The rest being the core name. That said, someone really liked to use Olive in the naming Dale On Mon, May 17, 2010 at 4:44 PM, Nathan Edgars II nerou...@gmail.comwrote: Lord-Castillo, Brett wrote: But another good one close to us is Old Olive Street Rd and Old Olive St Rd (both official names for different sections of the road). These two streets run parallel to Olive St, Olive Street Rd, and Olive Blvd (all three of these are different roads). So if Old Olive Street Rd and Old Olive St Rd are different, how do you distinguish them in speech? Or are they actually interchangeable names, as would seem logical (in other words, one or the other may be official, but both are unambiguous and correct for all practical purposes)? ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us -- Dale Puch ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Street Naming Conventions
I happen to know the answer to this one. I'll save Brett the trouble of replying again, and point you to an earlier explanation in this thread. (Though being so long, I don't blame you for not seeing it the first time around.) http://lists.openstreetmap.org/pipermail/talk-us/2010-April/003087.html It seems really odd to me, too, but it's not the first time customs have developed in odd ways... Nathan Oliver On 5/17/2010 7:01 PM, Nathan Edgars II wrote: Dale Puch wrote: On Mon, May 17, 2010 at 4:44 PM, Nathan Edgars II neroute2 at gmail.comwrote: Lord-Castillo, Brett wrote: But another good one close to us is Old Olive Street Rd and Old Olive St Rd (both official names for different sections of the road). These two streets run parallel to Olive St, Olive Street Rd, and Olive Blvd (all three of these are different roads). So if Old Olive Street Rd and Old Olive St Rd are different, how do you distinguish them in speech? Or are they actually interchangeable names, as would seem logical (in other words, one or the other may be official, but both are unambiguous and correct for all practical purposes)? If Old Olive Street Rd and Old Olive St Rd are one road, ie. connected and not and a corner. Then things that may explain it are different addresses where they intersect, or if they are in different jurisdictions. Like where two cities meet. But if the addressing continues between the different names, then it seem one sign is wrong. I personally think Old Olive Street Rd should be used, and only cardinal direction prefix and type suffix abbreviated. The rest being the core name. I'm not sure what you mean - if you tell someone I live at 50 Old Olive Street Rd, how is that any different from I live at 50 Old Olive St Rd? (Obviously one would need to specify which city the address is in, if the official name changes at the city line. But, without the city name, neither of those statements, even written, would be truly unambiguous, since the reader can't assume the chosen Street or St is identical to the official usage. In fact, if we do name these segments differently, it could cause more confusion, since someone typing one might be taken to the official match when they wanted the other one and didn't realize they were officially different.) As for abbreviations, there's no consistent way to abbreviate. Around here, you'll see Parkway, Pkwy, Pky, and Py all used for the same road. And directional prefixes are part of the address, appearing above the block number in a separate square on street signs. ___ 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] Street Naming Conventions
Hi, On 15 May 2010 05:58, David ``Smith'' vidthe...@gmail.com wrote: I now believe that it is /also/ acceptable for the name=* tag to specify the full, unabbreviated name -- however, if abbreviation of that name is used commonly and consistently, then that abbreviated form should go in another tag. (I've been using abbr_name=* for that.) 2) I've heard there's a bot that's automatically expanding names from the TIGER import. To the operator of that bot: proceed with caution if you will, and /PLEASE/ preserve the abbreviated name in some other tag(s). I've also been using abbr_name where there's a non-obvious way to abbreviate the name, but actually there's no reason why it couldn't be used always for commonly used abbreviated versions, other than it's a bit of work to add. In case of TIGER (I'm the person that ran the bot) it can be done automatically to some extent so I can make another run to re-add the original shortened names as abbr_name. The original names, however, were shortened according to some rules documented in the TIGER docs, regardless of how common or consistent their usage was (following the USPS rules, for example, they would be different in some small percentage), so I'm not sure if that name should ever appear in a tag that is not namespaced as a tiger tag. On the other hand it may be a good start for the abbr_name values, in 90% cases it should just be correct. In the remaining cases they can be fixed manually (rather than having to add *all* abbr_names manually) and specially if we can get mapnik to use the value of that tag when there isn't enough space for the full name, then mappers would probably put some care in maintaining the values correct. Cheers ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Street Naming Conventions
On Mon, May 10, 2010 at 20:18, Val Kartchner val...@gmail.com wrote: This topic has been dropped without it having been resolved. We still need some way of addressing the issues summarized in http://vidthekid.info/misc/osm-abbr.html;. This can be summarized as needing to create fields for: direction prefix street name street type direction suffix This is needed for exactly the same reason that no abbreviations are supposed to be used in OSM: There is no automated way to fix the parts of a street name. For instance, here are some actual addresses which occur in this area: Number Prefix Street Name Type Suffix 200 West North Temple Street 200 East South Temple Street 200 North West Temple Street 50 East North Lakeview Drive 50 East South Lakeview Drive 2450 North E Street 300 Southgate Drive 4700 West 3300 Street South These are just samples, but others on this list have come up with other examples that demonstrate the problems with the current way of doing things. Also, in the last example given above, the Type and Suffix would be swapped, but in most written addresses the Type would be dropped. I'll again claim that just one field would be enough -- the street name -- and the other three can be derived from their offsets; trivial for direction prefix, and slightly more complicated (requiring a dictionary/list of directions, anything left over goes into the street type field) for the latter two. Can you offer any examples where these three would be difficult to derive if one was provided only full name and street name? ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Street Naming Conventions
This topic has been dropped without it having been resolved. We still need some way of addressing the issues summarized in http://vidthekid.info/misc/osm-abbr.html;. This can be summarized as needing to create fields for: direction prefix street name street type direction suffix This is needed for exactly the same reason that no abbreviations are supposed to be used in OSM: There is no automated way to fix the parts of a street name. For instance, here are some actual addresses which occur in this area: Number Prefix Street Name TypeSuffix 200 WestNorth Temple Street 200 EastSouth Temple Street 200 North West Temple Street 50 EastNorth Lakeview Drive 50 EastSouth Lakeview Drive 2450North EStreet 300 SouthgateDrive 4700West3300 Street South These are just samples, but others on this list have come up with other examples that demonstrate the problems with the current way of doing things. Also, in the last example given above, the Type and Suffix would be swapped, but in most written addresses the Type would be dropped. - Val - ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Street Naming Conventions (was Admin boundaries tied to roads)
At 2010-04-21 19:24, Alan Mintz wrote: I just had a machine crash as I was trying to find stats, but I'll bet that at least 90% of the cases are St... For further reference, in this area of LA: minlat=33.75 minlon=-119.00 maxlat=34.00 maxlon=-114.50, on 2010-02-11, I count: 35988 unique name values on highway=* (except service), of which there were the following suffixes: 6076 Dr 5747 St 5161 Ave 3090 Ln 2825 Ct 2630 Rd 2478 Cir 2186 Way 2121 Pl 256 Blvd 175 Trl 32745 Total well understood abbrevs (91%) Additionally, Spanish prefixes, which my tag proposal did not address (road_type_prefix, and road_type becomes road_type_suffix?): 690 Via 234 Calle 169 Avenida 104 Camino 68 [NEWS] Via 40 [NEWS] Calle 36 [NEWS] Avenida 22 [NEWS] Camino Some of these also had suffixes above. It seems that the prefix would be part of the root name in these cases, instead of a prefix. -- Alan Mintz alan_mintz+...@earthlink.net ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Street Naming Conventions
First of all, I've renamed the subject to what it is really discussing.
On Wed, 2010-04-21 at 19:24 -0700, Alan Mintz wrote:
name: The pre-balrog name
name_direction_prefix: The 1-2 char cardinal direction before the root
use_name_direction_prefix: {yes|no} Yes indicates that the
name_direction_prefix should be rendered/spoken
name_root: The actual root of the name
name_direction_suffix: The 1-2 char cardinal direction after the root
name_type: {St|Ave|Blvd|etc.} Common, documented abbreviations allowed
render_name: The name to be rendered on a map (if not name for some reason)
spoken_name: The complete expanded name, ready for text-2-speech
The post-balrog name should go into spoken_name for now. The pre-balrog
name would be restored to the name tag and also split up into the name_* tags.
I think that your proposal would cover both of the address forms covered
in http://vidthekid.info/misc/osm-abbr.html;. Would this still hold
for the rest of the world, or have we decided to dump the global
thing?
- Val -
___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Street Naming Conventions
The traffic has calmed down. I still want some things resolved before I agree with expanding street names. 1) Be useful to the user. (This is mostly done via programs.) 2) Be simple for automated processing (programs) a) Render in an uncluttered way on the maps c) Look up addresses on maps b) Processed for GPS use 3) Be easy to enter data a) As simple as possible b) Consider above goals as higher priority If you want these things stated in a different way then look at this link: http://vidthekid.info/misc/osm-abbr.html;. Right now, by putting everything into name, we lose utility. I mean that we compromise between making it easy for users and easy for programs. - Val - ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Street Naming Conventions
On 8 April 2010 01:09, andrzej zaborowski balr...@gmail.com wrote: As for the different segments of the name, there are already fields for them which we inherited from TIGER, you'll find the middle of the name is unmodified in the tiger:base_name= tag, the cardinal direction in tiger:directional_prefix= and tiger:directional_suffix and the feature type (Street, Ave etc) in type:name_type. Going back to the segmenting discussion, I have been manually reviewing great numbers of TIGER streets, confirming some of riskier changes done by the bot and can say with a good confidence that all or majority of the name_direction_prefix, name_direction_suffix, name_base and name_type attributes have been automatically generated from the full name. It can be seen in the types of errors found in the segmentation. One of the more interesting errors is that in areas where there are only English names, if the name starts or ends with O, TIGER removed it from name_base and put it in the prefix or suffix. That must be because TIGER is adapted to both English and Spanish, so for it the cardinal directions are all of N, E, W, S, O, SE, SW, SO, NE, NW, NO. I've been correcting the ones I found so that the tiger tags can be used as basis for some unified tags. Cheers ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Street Naming Conventions
andrzej zaborowski balr...@gmail.com writes: On 9 April 2010 15:30, Matthias Julius li...@julius-net.net wrote: Val Kartchner val...@gmail.com writes: 3) Prefix, body, suffix is available from the TIGER data, but what about streets that have already been added (or corrected) by users? As we've seen, a bot won't always be able to correctly make these separations (as in the example of Southbay vs. South Bay given previously) How do we make it so that it meets the goals I've given? I would say: - assemble the name out of the tiger:name_* tags - if that matches the name tag re-assemble the name while expanding tiger:name_direction_prefix and tiger:name_direction_prefix and replace the name tag. Ok, added the check in r20882 although I'd say the script is useful for data from sources other than TIGER too. That may be. But, I would start with the easy stuff. It just requires a lot more scrutiny and special case handling if you are only parsing name tags. All I am arguing is that if you have the components separate like in the TIGER data then you should simply use them. Name suffixes in TIGER are a limited set. Who knows what 'St' at the end of a street name can possibly mean. I don't think that only the direction_prefix/suffix should be expanded, basically all name should be the way it is pronounced to avoid ambiguity. The East Doctor Martin Luther King, Junior Boulevard is an example that I think shows that the direction parts of the name are the least of the problems. On the signage the name appears as E DR MLKjr BLVD or similar. Question is how it appears in TIGER or other imported datasets. It is probably impossible to write a script that handles every possible case correctly. That's why I think the script should stick to the things that are unambiguous and leave the rest to humans. It is far better to leave a couple of cases untreated than to screw up good data. Matthias ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Street Naming Conventions
On 9 April 2010 15:30, Matthias Julius li...@julius-net.net wrote: Val Kartchner val...@gmail.com writes: 3) Prefix, body, suffix is available from the TIGER data, but what about streets that have already been added (or corrected) by users? As we've seen, a bot won't always be able to correctly make these separations (as in the example of Southbay vs. South Bay given previously) How do we make it so that it meets the goals I've given? I would say: - assemble the name out of the tiger:name_* tags - if that matches the name tag re-assemble the name while expanding tiger:name_direction_prefix and tiger:name_direction_prefix and replace the name tag. Ok, added the check in r20882 although I'd say the script is useful for data from sources other than TIGER too. I don't think that only the direction_prefix/suffix should be expanded, basically all name should be the way it is pronounced to avoid ambiguity. The East Doctor Martin Luther King, Junior Boulevard is an example that I think shows that the direction parts of the name are the least of the problems. On the signage the name appears as E DR MLKjr BLVD or similar. Cheers ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Street Naming Conventions
On 10 April 2010 11:07, Richard Finegold goldfndr+...@gmail.com wrote: On Thu, Apr 8, 2010 at 20:32, Val Kartchner val...@gmail.com wrote: On Thu, 2010-04-08 at 00:59 +0200, andrzej zaborowski wrote: On 7 April 2010 20:12, Mike Thompson miketh...@gmail.com wrote: Having said that, I think it is a bad idea to have a bot going through and attempting to expand abbreviations. I agree. If a bot can do this then that is evidence that a renderer or other data consumer can expand them if desired. But is the bot supplying its source of heightened accuracy? Surely the bot isn't checking physical signage. No, its only useful piece of knowledge is that the TIGER ruleset applies to this data here. If you had to incorporate in your renderer such a bot for every one of the 200 countries this wouldn't be fun, that's why the consensus (according to wiki and discussions on t...@.. and irc) is not to use abbrevs at all. (with some exceptions) So it really shou;d have done as part of the conversion from TIGER to osm format. but not at lower zooms. There's a claim of This will allow a renderer to introduce abbreviations as necessary. in the wiki, but is it true? Does andrzej or someone else have an algorithm that can work with the examples in the essay at http://vidthekid.info/misc/osm-abbr.html No, but it's a good idea, on some weekend I'll set up a mapnik and see how to get it to display shortened names in US at lower zoom levels. Cheers ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Street Naming Conventions
On Thu, Apr 8, 2010 at 20:32, Val Kartchner val...@gmail.com wrote: On Thu, 2010-04-08 at 00:59 +0200, andrzej zaborowski wrote: On 7 April 2010 20:12, Mike Thompson miketh...@gmail.com wrote: Having said that, I think it is a bad idea to have a bot going through and attempting to expand abbreviations. I agree. If a bot can do this then that is evidence that a renderer or other data consumer can expand them if desired. But is the bot supplying its source of heightened accuracy? Surely the bot isn't checking physical signage. I ran the bot ([1]) over the west half of the US [...] [...] After Oregon I ran the bot on the other states because of the comments I got from mappers on IRC. This was what prompted Val to start the discussion here. I'm going to hold off with it according to your comment. Funnily in an IRC discussion we concluded that it was nice that at least one thing had been agreed on in OSM :) After the brief but lively discussion on this topic that I started, I am almost convinced to go with the expanded (unabbreviated) names. I see these goals, in no particular order but numbered for reference: 1) Be easy to enter data 2) Be easy for automated parsing 3) Be rendered in an uncluttered way on the maps Regarding 3: Some abbreviation expansion seems conclusively counterproductive. For example, http://osm.org/go/WIdHmwyRJ-- -- which has SE 3rd St on its signage -- has its name rendered at Z18 but not at lower zooms. There's a claim of This will allow a renderer to introduce abbreviations as necessary. in the wiki, but is it true? Does andrzej or someone else have an algorithm that can work with the examples in the essay at http://vidthekid.info/misc/osm-abbr.html (linked from http://wiki.openstreetmap.org/wiki/Talk:Key:name#Abbreviation_.28don.27t_do_it.29_._Abbreviations_on_street_signs.21)? [snip] 4) Should the issue of making it easy to enter expanded street names be pushed off onto the data entry programs? I daresay that NE is quicker to type than Northeast. But I don't have a keyboard with dedicated macro keys. 6) Should the direction prefix even be part of the street name since it (mostly) isn't on the sign? a) Commercial maps provide it as (for example) W 3300 S. However, I was using the OSM and Garmin routable maps on my GPS today and noticed that the Garmin maps show 3300 S (not 3300 South) for a street name. Should this be an issue that is pushed off onto the program that generates routable maps (with suggestions from OSM how to process the data)? What does the signage say? Here, when they cross Main or an equivalent meridian division they lose their direction. Or if they're in a central district. For example, http://www.openstreetmap.org/browse/node/53125765 has signage saying 116th Avenue, but it's NE to the North and SE to the South; similarly, see http://www.openstreetmap.org/browse/node/53224246 that has West Lake Sammamish Parkway as its base name. I'm guessing that the lack of direction prefix was a data mistake. b) I have used the alternate names (name, name_1, name_2, etc.) for alternates which would include expansions of the abbreviations. Should we establish a standard for how these are used and their order? For instance, north of 200 North, Washington Blvd is also 400 East and State Route 235 (though I know that routes are now tagged by relations). Maybe abbr_name and/or unabbr_name, as that would allow for other languages. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Street Naming Conventions
On Sat, Apr 10, 2010 at 04:51, Alex S. m...@swavely.com wrote: Richard Finegold wrote: see http://www.openstreetmap.org/browse/node/53224246 that has West Lake Sammamish Parkway as its base name. I'm guessing that the lack of direction prefix was a data mistake. East... And no, (IMHO, anyway) it's not a data mistake, though including it on West Lk Sam Pkwy (http://www.openstreetmap.org/browse/node/53223662) *is* (again, IMHO). The 'East' and 'West' in this case are really part of the name. There are numerous similar examples at the other end of the same county. Thanks for catching my mistake; at first I was going to use 53223662 as the example, but switched. The data mistake I attempted to refer to was Val's example of W 3300 S. Alas, Val didn't specify a city, but an example I found is http://www.openstreetmap.org/browse/node/83553388; the signage might have 3300 S at the intersection with S Main Street, but it'd only be at that intersection as a cost-saving measure, and signs naming W 3300 S for the westbound branch of that intersection and E 3300 S for eastbound would be equally valid. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Street Naming Conventions
On Sat, 2010-04-10 at 07:42 -0700, Richard Finegold wrote: On Sat, Apr 10, 2010 at 04:51, Alex S. m...@swavely.com wrote: Richard Finegold wrote: see http://www.openstreetmap.org/browse/node/53224246 that has West Lake Sammamish Parkway as its base name. I'm guessing that the lack of direction prefix was a data mistake. East... And no, (IMHO, anyway) it's not a data mistake, though including it on West Lk Sam Pkwy (http://www.openstreetmap.org/browse/node/53223662) *is* (again, IMHO). The 'East' and 'West' in this case are really part of the name. There are numerous similar examples at the other end of the same county. Thanks for catching my mistake; at first I was going to use 53223662 as the example, but switched. The data mistake I attempted to refer to was Val's example of W 3300 S. Alas, Val didn't specify a city, but an example I found is http://www.openstreetmap.org/browse/node/83553388; the signage might have 3300 S at the intersection with S Main Street, but it'd only be at that intersection as a cost-saving measure, and signs naming W 3300 S for the westbound branch of that intersection and E 3300 S for eastbound would be equally valid. I think that I specified Ogden, Utah somewhere, but it got lost somewhere in the conversation. The specific place that I was playing with my Garmin routable map and the OSM routable map was along 3300 S both sides of Midland Drive. (http://www.openstreetmap.org/?lat=41.20421lon=-112.02395zoom=16) The E Avenue that I've also mentioned is about a mile northeast of here, on the other side of the freeway. The E Street isn't too far away, http://www.openstreetmap.org/?lat=41.17035lon=-112.00271zoom=17 here. I think that http://vidthekid.info/misc/osm-abbr.html (that Richard brought up) provides a pretty good summary of the issues that we've got to deal with. One of the most important that I see is making sure that the core name can be separated from the rest of the entered name. How do we go about doing this? We also have to be able to do this for streets that have multiple aliases, such as Washington Blvd and 400 E that I mentioned before. What I want to have eventually is for OSM data to be able to totally replace the functionality provided by GPS maker's data. When I enter an address on my Garmin, it first wants city and state (which it assumes from my current location). Next it want the address number. Next it wants the base street name (no directional prefix, suffix or street-type). Finally, it provides a list of complete addresses (prefix, suffix and street-type) from which to select an address. I know that part of this is done by those preparing the data for the GPS, but we need to provide the capabilities to that this can be done by a program. Here's my list again, modified and now ordered with the most important stuff at the top: 1) Be useful to the user (This is mostly done by programs) 2) Be simple for automated processing a) Render in an uncluttered way on the maps c) Look up addresses on maps b) Processed for GPS use 3) Be easy to enter data a) As simple as possible b) Consider above goals as higher priority - Val - ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Street Naming Conventions
Val Kartchner val...@gmail.com writes: On Thu, 2010-04-08 at 12:23 -0400, Richard Welty wrote: i don't think anyone would argue with this. it's why having a bot rampage through fixing things is probably a Real Bad Idea unless it's extremely well thought out and comprehensively tested beforehand. While I didn't like what the bot was doing (at the time), What was the bot doing? I don't thing rampage is the correct word to use. That implies malice, which wasn't what was attempted. However, it did have a beneficial side effect: this topic. ;-) In the special case of TIGER data there is a tag tiger:name_type=Rd|Ct|Dr|... I would have thought it should be fairly save to reconstruct the name from the tiger:name_* tags while expanding tiger:name_type - IF the name is still the original one. Matthias ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Street Naming Conventions
On 9 April 2010 15:06, Matthias Julius li...@julius-net.net wrote: Val Kartchner val...@gmail.com writes: On Thu, 2010-04-08 at 12:23 -0400, Richard Welty wrote: i don't think anyone would argue with this. it's why having a bot rampage through fixing things is probably a Real Bad Idea unless it's extremely well thought out and comprehensively tested beforehand. While I didn't like what the bot was doing (at the time), What was the bot doing? I don't thing rampage is the correct word to use. That implies malice, which wasn't what was attempted. However, it did have a beneficial side effect: this topic. ;-) In the special case of TIGER data there is a tag tiger:name_type=Rd|Ct|Dr|... I would have thought it should be fairly save to reconstruct the name from the tiger:name_* tags while expanding tiger:name_type - IF the name is still the original one. Except for a few caveats the bot follows the TIGER documentation and expands everything listed there (taking into account the suffix/prefix requirements), it only touches name and name_1, 2 and so on, leaving alone other tags. I did a dry run on a piece of Canada and the ruleset applies pretty well there too, the streets there were from Geobase. Cheers ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Street Naming Conventions
Val Kartchner val...@gmail.com writes: 3) Prefix, body, suffix is available from the TIGER data, but what about streets that have already been added (or corrected) by users? As we've seen, a bot won't always be able to correctly make these separations (as in the example of Southbay vs. South Bay given previously) How do we make it so that it meets the goals I've given? I would say: - assemble the name out of the tiger:name_* tags - if that matches the name tag re-assemble the name while expanding tiger:name_direction_prefix and tiger:name_direction_prefix and replace the name tag. Matthias ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Street Naming Conventions
On 04/08/2010 10:32 PM, Val Kartchner wrote: 6) Should the direction prefix even be part of the street name since it (mostly) isn't on the sign? That’s not true in all areas. I’m in Wisconsin, and in most cities I’ve been to, if the street has a direction prefix it’s on the sign (abbreviated of course). —Alex Mauer “hawke” signature.asc Description: OpenPGP digital signature ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Street Naming Conventions
andrzej zaborowski balr...@gmail.com writes: On 9 April 2010 15:06, Matthias Julius li...@julius-net.net wrote: Val Kartchner val...@gmail.com writes: On Thu, 2010-04-08 at 12:23 -0400, Richard Welty wrote: i don't think anyone would argue with this. it's why having a bot rampage through fixing things is probably a Real Bad Idea unless it's extremely well thought out and comprehensively tested beforehand. While I didn't like what the bot was doing (at the time), What was the bot doing? I don't thing rampage is the correct word to use. That implies malice, which wasn't what was attempted. However, it did have a beneficial side effect: this topic. ;-) In the special case of TIGER data there is a tag tiger:name_type=Rd|Ct|Dr|... I would have thought it should be fairly save to reconstruct the name from the tiger:name_* tags while expanding tiger:name_type - IF the name is still the original one. Except for a few caveats the bot follows the TIGER documentation and expands everything listed there (taking into account the suffix/prefix requirements), it only touches name and name_1, 2 and so on, leaving alone other tags. I did a dry run on a piece of Canada and the ruleset applies pretty well there too, the streets there were from Geobase. But, I think it is probably safer to not parse the name and instead reassemble the name from the (expanded) tiger:name_* tags Matthias ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Street Naming Conventions
Alex Mauer wrote: On 04/08/2010 10:32 PM, Val Kartchner wrote: 6) Should the direction prefix even be part of the street name since it (mostly) isn't on the sign? That’s not true in all areas. I’m in Wisconsin, and in most cities I’ve been to, if the street has a direction prefix it’s on the sign (abbreviated of course). That's done in WA state, too. There's even more on signs in certain cities around here - in small letters across the bottom, they often say 'Historic: old street name' with date of change... ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Street Naming Conventions
Hi Val, you send the mail to me only, you might want to resend to list. On 8 April 2010 08:31, Val Kartchner val...@gmail.com wrote: 5) Should suggestions be given to renderers to use the USPS abbreviations? Another possibility is to use the TIGER guidelines, if the USPS list has issues related to copyright. b) I have used the alternate names (name, name_1, name_2, etc.) for alternates which would include expansions of the abbreviations. Should we establish a standard for how these are used and their order? For instance, north of 200 North, Washington Blvd is also 400 East and State Route 235 (though I know that routes are now tagged by relations). There's also some confusion with what name_N tags are used for in TIGER imports vs. the rest of OSM. There are different tags for the different names according to their type: loc_name= for a not-necessarily official name, but used by locals, official_name=, alt_name= int_name= (I'm not sure what this one is for) ref= reg_ref= while in TIGER all of these are stuffed into name_N= tags as same level citizens in seemingly random order. I think maybe the _N convention should only be used for different possible spellings of the same name, while things like National Forest Development Road 0160 should be put in ref= or reg_ref=, and things like US Highway 30 removed completely and moved to relation's name. And things like Cemetery Road into loc_name unless name is empty. Cheers, Andrew ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Street Naming Conventions
On 4/8/10 9:48 AM, Lord-Castillo, Brett wrote: One issue with using unabbreviated names, is sometimes the abbreviations are part of the official name. Examples here: 1st Community CU Dr (First Community Credit Union goes to a -different- address) River City Blvd/River City Casino Blvd; many people think the first is an abbreviation of the former. It isn't, two different streets that will route mail (and traffic) to two different sets of addresses St Louis Street, which is different from Rue St Louis, which is different from Saint Louis Street and Saint Louis Boulevard, which is still different from The Boulevard St Louis. In each of those cases, the non-type abbreviations are part of the name and expanding the abbreviations can turn them into different streets. i don't think anyone would argue with this. it's why having a bot rampage through fixing things is probably a Real Bad Idea unless it's extremely well thought out and comprehensively tested beforehand. the thing i think most of us are arguing for is in cases where we know that ST == Street, Rd == Road, Blvd == Boulevard, we should be storing the full string, and treating abbreviations as a rendering problem. how we get there is an implementation issue to be resolved. right now, i fix them by hand when editing in josm because the josm validator whines about it. richard ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Street Naming Conventions
Some of the examples comma separated into the 4 field format: South, ,1000 East, Street Paul Johnson mentioned on IRC today the case of East Doctor Martin Luther King, Junior Boulevard, which wouldn't work with this schema I don't think *storing* them as comma separated was the suggested scheme; it was just data samples in the email. Storing them could/would be done as 4 fields, like TIGER. In which case this street name works just fine. I think the tag like name= should really be consistent so tools can rely on it without adapting to every single country. Definitely. If implemented, the 4-field breakdown should be in addition to the name= field. As for the different segments of the name, there are already fields for them which we inherited from TIGER, you'll find the middle of the name is unmodified in the tiger:base_name= tag, the cardinal direction in tiger:directional_prefix= and tiger:directional_suffix and the feature type (Street, Ave etc) in type:name_type. Sure. I think the suggestion was really just to take that structure and make it available/standard for all streets, not just tiger imports in the tiger namespace. So the example above would be directional_prefix=East base_name=Doctor Martin Luther King, Junior name_type=Boulevard directional_suffix= name=East Doctor Martin Luther King, Junior Boulevard Is it redundant? Mostly. Is it maximally informative and flexible? Yes. I wonder if all areas that use a directional suffix put them after the name type (Maple Street SouthEast), or if some put them before the name type (Maple SouthEast Street)? In which case, the full name is not actually redundant but holds proper ordering info not in the separated fields. - Alan ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Street Naming Conventions
On 8 Apr 2010, at 9:42 , am12 wrote: Some of the examples comma separated into the 4 field format: South, ,1000 East, Street Paul Johnson mentioned on IRC today the case of East Doctor Martin Luther King, Junior Boulevard, which wouldn't work with this schema I don't think *storing* them as comma separated was the suggested scheme; it was just data samples in the email. Storing them could/would be done as 4 fields, like TIGER. In which case this street name works just fine. I think the tag like name= should really be consistent so tools can rely on it without adapting to every single country. Definitely. If implemented, the 4-field breakdown should be in addition to the name= field. As for the different segments of the name, there are already fields for them which we inherited from TIGER, you'll find the middle of the name is unmodified in the tiger:base_name= tag, the cardinal direction in tiger:directional_prefix= and tiger:directional_suffix and the feature type (Street, Ave etc) in type:name_type. Sure. I think the suggestion was really just to take that structure and make it available/standard for all streets, not just tiger imports in the tiger namespace. So the example above would be directional_prefix=East base_name=Doctor Martin Luther King, Junior name_type=Boulevard directional_suffix= name=East Doctor Martin Luther King, Junior Boulevard Is it redundant? Mostly. Is it maximally informative and flexible? Yes. I wonder if all areas that use a directional suffix put them after the name type (Maple Street SouthEast), or if some put them before the name type (Maple SouthEast Street)? In which case, the full name is not actually redundant but holds proper ordering info not in the separated fields. my experience is that directional is a prefix not a suffix as this discussion shows there is no definitive rule and the only way this could be done is to have full name on the name tag and and name:abbrev tag with the abbreviation used locally. your tagging scheme is well meant but might be overly complicated to use. I think converting existing names with a bot to name=fullname name:abbrev=abbrev name is quite safe. as alternative it wouldn't be bad to keep the current abbrev names on the main tag because all geocoders use them instead the full name. and use this instead name:nonabbrev=fullname name=abbrev name advatage is that rendering doesn't need to change and will use same stryle as all existing commercial maps. - Alan ___ 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] Street Naming Conventions
my experience is that directional is a prefix not a suffix I have seen directionals as suffixes, and in some cases a street will have both a prefix and suffix directional ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Street Naming Conventions
my experience is that directional is a prefix not a suffix Portland OR is full of prefixes. Seattle WA is full of suffixes. Certainly TIGER has them because they occur plenty of places in the US. name:nonabbrev=fullname name=abbrev name advatage is that rendering doesn't need to change and will use same stryle as all existing commercial maps. Actually, I think this idea of all existing commercial maps is an oversimplification. People remember the ones they looked at, which is never all. I was in Google Maps yesterday, and saw SW in one place for a prefix and Southwest in another nearby. They have the same issues as the rest of us. And I would bet money that the map makers that have it consistent, do it by having fields broken out like the recent suggestion and TIGER. We can't be the only country with this issue. What are the others doing? - Alan ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Street Naming Conventions
On 8 April 2010 15:48, Lord-Castillo, Brett blord-casti...@stlouisco.com wrote: One issue with using unabbreviated names, is sometimes the abbreviations are part of the official name. Examples here: 1st Community CU Dr (First Community Credit Union goes to a -different- address) River City Blvd/River City Casino Blvd; many people think the first is an abbreviation of the former. It isn't, two different streets that will route mail (and traffic) to two different sets of addresses St Louis Street, which is different from Rue St Louis, which is different from Saint Louis Street and Saint Louis Boulevard, which is still different from The Boulevard St Louis. In each of those cases, the non-type abbreviations are part of the name and expanding the abbreviations can turn them into different streets. In 1st Community CU Dr when you read it out, I guess you do say ... CU Drive. But the St Louis Street vs. Saint Louis Street? They're pronounced exactly same way and I'm sure 90% people will write both of them as St Louis Street in rush, are there seriously cases where these are different addresses? What do the people living at St Louis St say on the phone when asked for address? Cheers ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Street Naming Conventions
They say 'Rue Saint Louis', which is an alternate name for the street (but not the official postal name) or they say 'S T Louis Street'. I think the post office uses the different zip codes to sort things out; but that doesn't help with street routing which can get pretty screwed up depending on your device. People here are actually pretty used to saying S T Louis for different uses (for example, my email address). The street signs on St Louis St actually say Rue St Louis (with no street abbreviation). Brett Lord-Castillo Information Systems Designer/GIS Programmer St. Louis County Police Office of Emergency Management 14847 Ladue Bluffs Crossing Drive Chesterfield, MO 63017 Office: 314-628-5400 Fax: 314-628-5508 Direct: 314-628-5407 -Original Message- From: andrzej zaborowski [mailto:balr...@gmail.com] Sent: Thursday, April 08, 2010 12:23 PM To: Lord-Castillo, Brett Cc: talk-us@openstreetmap.org Subject: Re: [Talk-us] Street Naming Conventions On 8 April 2010 15:48, Lord-Castillo, Brett blord-casti...@stlouisco.com wrote: One issue with using unabbreviated names, is sometimes the abbreviations are part of the official name. Examples here: 1st Community CU Dr (First Community Credit Union goes to a -different- address) River City Blvd/River City Casino Blvd; many people think the first is an abbreviation of the former. It isn't, two different streets that will route mail (and traffic) to two different sets of addresses St Louis Street, which is different from Rue St Louis, which is different from Saint Louis Street and Saint Louis Boulevard, which is still different from The Boulevard St Louis. In each of those cases, the non-type abbreviations are part of the name and expanding the abbreviations can turn them into different streets. In 1st Community CU Dr when you read it out, I guess you do say ... CU Drive. But the St Louis Street vs. Saint Louis Street? They're pronounced exactly same way and I'm sure 90% people will write both of them as St Louis Street in rush, are there seriously cases where these are different addresses? What do the people living at St Louis St say on the phone when asked for address? Cheers attachment: Lord-Castillo, Brett.vcf___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Street Naming Conventions
my experience is that directional is a prefix not a suffix Portland OR is full of prefixes. Seattle WA is full of suffixes. Certainly TIGER has them because they occur plenty of places in the US. In Washington DC * S Capitol St SW * S Capitol St SE * N Capitol St NW * N Capitol St NE * E Capitol St SE * E Capitol St NE ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Street Naming Conventions
all over upstate NY, you will see Fred Street in town, and Fred Street Road extending out into the county... richard On 4/8/10 4:20 PM, Brad Neuhauser wrote: For another oddball example, there are some names like Upper 35th St Cir or McKusick Rd Ct (which are offshoots of Upper 35th St and McKusick Rd, respectively) in some Minnesota suburbs. Brad On Thu, Apr 8, 2010 at 1:15 PM, Mike Thompsonmiketh...@gmail.com wrote: my experience is that directional is a prefix not a suffix Portland OR is full of prefixes. Seattle WA is full of suffixes. Certainly TIGER has them because they occur plenty of places in the US. In Washington DC * S Capitol St SW * S Capitol St SE * N Capitol St NW * N Capitol St NE * E Capitol St SE * E Capitol St NE ___ 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] Street Naming Conventions
Using a bot for specific well know Suffix abbreviations only should be reasonably safe. IE never change ST to street if it is a prefix sort of rules. Dale On Thu, Apr 8, 2010 at 12:23 PM, Richard Welty rwe...@averillpark.netwrote: On 4/8/10 9:48 AM, Lord-Castillo, Brett wrote: One issue with using unabbreviated names, is sometimes the abbreviations are part of the official name. Examples here: 1st Community CU Dr (First Community Credit Union goes to a -different- address) River City Blvd/River City Casino Blvd; many people think the first is an abbreviation of the former. It isn't, two different streets that will route mail (and traffic) to two different sets of addresses St Louis Street, which is different from Rue St Louis, which is different from Saint Louis Street and Saint Louis Boulevard, which is still different from The Boulevard St Louis. In each of those cases, the non-type abbreviations are part of the name and expanding the abbreviations can turn them into different streets. i don't think anyone would argue with this. it's why having a bot rampage through fixing things is probably a Real Bad Idea unless it's extremely well thought out and comprehensively tested beforehand. the thing i think most of us are arguing for is in cases where we know that ST == Street, Rd == Road, Blvd == Boulevard, we should be storing the full string, and treating abbreviations as a rendering problem. how we get there is an implementation issue to be resolved. right now, i fix them by hand when editing in josm because the josm validator whines about it. 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] Street Naming Conventions
Perhaps we should take a look at what a bot would match. Run a bot that finds and counts the various matches and outputs a report only. pre, mid and suffix counts the abbreviations. and what the bot would expand each abbreviation to. Abbreviations in the middle should be located, but probably not changed by the bot. The pre and suffix ones should be pretty safe. Then start to decide which would be safe to run based on the results. If this can be done by state or perhaps even county all the better to minimize issues with local standards. Anything that might be questionable we would want to manually look at the current names and results. Having a link to a potlatch view or josm shortcut would be all the better. Let the bot run on the safer choices, the rest we would have a list to manually check and edit if needed. Similar to what was done with motorway links. Yes there will be mistakes, but stuff like having two streets with 'saint louis street' and 'st louis street' names is only going to be fixable by locals IMO Then again how much different is that from two streets with the same name in adjacent towns? Unless the city and zip are the same, what will it really matter? Dale On Thu, Apr 8, 2010 at 4:35 PM, Richard Welty rwe...@averillpark.netwrote: all over upstate NY, you will see Fred Street in town, and Fred Street Road extending out into the county... richard On 4/8/10 4:20 PM, Brad Neuhauser wrote: For another oddball example, there are some names like Upper 35th St Cir or McKusick Rd Ct (which are offshoots of Upper 35th St and McKusick Rd, respectively) in some Minnesota suburbs. Brad On Thu, Apr 8, 2010 at 1:15 PM, Mike Thompsonmiketh...@gmail.com wrote: my experience is that directional is a prefix not a suffix Portland OR is full of prefixes. Seattle WA is full of suffixes. Certainly TIGER has them because they occur plenty of places in the US. In Washington DC * S Capitol St SW * S Capitol St SE * N Capitol St NW * N Capitol St NE * E Capitol St SE * E Capitol St NE ___ 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 ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Street Naming Conventions
On 8 April 2010 22:40, Dale Puch dale.p...@gmail.com wrote: Using a bot for specific well know Suffix abbreviations only should be reasonably safe. IE never change ST to street if it is a prefix sort of rules. TIGER specifies which qualifiers can appear as prefixes and which as suffixes. Unfortunately a lot of data is inconsistent with the docs, for example for National Forest Development Road I counted about 30 different variations of the short version, the documentation only list one. Cheers ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Street Naming Conventions
Since I raised the issue at some point in this thread of whether a bot should be used for fixing abbreviations I will respond. What Dale is proposing makes a lot of sense. On Thu, Apr 8, 2010 at 3:09 PM, Dale Puch dale.p...@gmail.com wrote: Perhaps we should take a look at what a bot would match. Run a bot that finds and counts the various matches and outputs a report only. pre, mid and suffix counts the abbreviations. and what the bot would expand each abbreviation to. Abbreviations in the middle should be located, but probably not changed by the bot. The pre and suffix ones should be pretty safe. Then start to decide which would be safe to run based on the results. If this can be done by state or perhaps even county all the better to minimize issues with local standards. Anything that might be questionable we would want to manually look at the current names and results. Having a link to a potlatch view or josm shortcut would be all the better. Let the bot run on the safer choices, the rest we would have a list to manually check and edit if needed. Similar to what was done with motorway links. Yes there will be mistakes, but stuff like having two streets with 'saint louis street' and 'st louis street' names is only going to be fixable by locals IMO Then again how much different is that from two streets with the same name in adjacent towns? Unless the city and zip are the same, what will it really matter? Dale On Thu, Apr 8, 2010 at 4:35 PM, Richard Welty rwe...@averillpark.net wrote: all over upstate NY, you will see Fred Street in town, and Fred Street Road extending out into the county... richard On 4/8/10 4:20 PM, Brad Neuhauser wrote: For another oddball example, there are some names like Upper 35th St Cir or McKusick Rd Ct (which are offshoots of Upper 35th St and McKusick Rd, respectively) in some Minnesota suburbs. Brad On Thu, Apr 8, 2010 at 1:15 PM, Mike Thompsonmiketh...@gmail.com wrote: my experience is that directional is a prefix not a suffix Portland OR is full of prefixes. Seattle WA is full of suffixes. Certainly TIGER has them because they occur plenty of places in the US. In Washington DC * S Capitol St SW * S Capitol St SE * N Capitol St NW * N Capitol St NE * E Capitol St SE * E Capitol St NE ___ 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 ___ 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] Street Naming Conventions
On Thu, 2010-04-08 at 00:59 +0200, andrzej zaborowski wrote: Hi, On 7 April 2010 20:12, Mike Thompson miketh...@gmail.com wrote: Having said that, I think it is a bad idea to have a bot going through and attempting to expand abbreviations. I ran the bot ([1]) over the west half of the US [...] [...] After Oregon I ran the bot on the other states because of the comments I got from mappers on IRC. This was what prompted Val to start the discussion here. I'm going to hold off with it according to your comment. Funnily in an IRC discussion we concluded that it was nice that at least one thing had been agreed on in OSM :) After the brief but lively discussion on this topic that I started, I am almost convinced to go with the expanded (unabbreviated) names. I see these goals, in no particular order but numbered for reference: 1) Be easy to enter data 2) Be easy for automated parsing 3) Be rendered in an uncluttered way on the maps These goals and the discussions so far have brought up some further issues for discussion. These are not all OSM issues may be issues for OSM consumers. 1) Are these even good goals to work towards? 2) An issue that I brought up with Andrzej in email, the bot has expanded E Ave (in Ogden, Utah) to East Avenue when this is a range of avenues from A - H. There is another local instance (in Riverdale, Utah) that the bot hasn't yet expanded where streets are named A - K. The bot could leave such instances and flag them for manual review. 3) Prefix, body, suffix is available from the TIGER data, but what about streets that have already been added (or corrected) by users? As we've seen, a bot won't always be able to correctly make these separations (as in the example of Southbay vs. South Bay given previously) How do we make it so that it meets the goals I've given? 4) Should the issue of making it easy to enter expanded street names be pushed off onto the data entry programs? 5) Should suggestions be given to renderers to use the USPS abbreviations? This brings up my previous example of South A Avenue burying the important part of the street name. a) Should we develop our own guidelines for abbreviations (as brought up by someone else)? 6) Should the direction prefix even be part of the street name since it (mostly) isn't on the sign? a) Commercial maps provide it as (for example) W 3300 S. However, I was using the OSM and Garmin routable maps on my GPS today and noticed that the Garmin maps show 3300 S (not 3300 South) for a street name. Should this be an issue that is pushed off onto the program that generates routable maps (with suggestions from OSM how to process the data)? b) I have used the alternate names (name, name_1, name_2, etc.) for alternates which would include expansions of the abbreviations. Should we establish a standard for how these are used and their order? For instance, north of 200 North, Washington Blvd is also 400 East and State Route 235 (though I know that routes are now tagged by relations). - Val - ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Street Naming Conventions
On Thu, 2010-04-08 at 12:23 -0400, Richard Welty wrote: i don't think anyone would argue with this. it's why having a bot rampage through fixing things is probably a Real Bad Idea unless it's extremely well thought out and comprehensively tested beforehand. While I didn't like what the bot was doing (at the time), I don't thing rampage is the correct word to use. That implies malice, which wasn't what was attempted. However, it did have a beneficial side effect: this topic. ;-) - Val - ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Street Naming Conventions
With regards to E Ave Check for a base name if all is matched. If nothing is left, leave the name alone. I'm not sure what you asking about with Southbay vs South bay Are you trying to figure out if the bot should add or remove the space? If so, leave that for manual edits. Dale On Thu, Apr 8, 2010 at 11:32 PM, Val Kartchner val...@gmail.com wrote: On Thu, 2010-04-08 at 00:59 +0200, andrzej zaborowski wrote: Hi, On 7 April 2010 20:12, Mike Thompson miketh...@gmail.com wrote: Having said that, I think it is a bad idea to have a bot going through and attempting to expand abbreviations. I ran the bot ([1]) over the west half of the US [...] [...] After Oregon I ran the bot on the other states because of the comments I got from mappers on IRC. This was what prompted Val to start the discussion here. I'm going to hold off with it according to your comment. Funnily in an IRC discussion we concluded that it was nice that at least one thing had been agreed on in OSM :) After the brief but lively discussion on this topic that I started, I am almost convinced to go with the expanded (unabbreviated) names. I see these goals, in no particular order but numbered for reference: 1) Be easy to enter data 2) Be easy for automated parsing 3) Be rendered in an uncluttered way on the maps These goals and the discussions so far have brought up some further issues for discussion. These are not all OSM issues may be issues for OSM consumers. 1) Are these even good goals to work towards? 2) An issue that I brought up with Andrzej in email, the bot has expanded E Ave (in Ogden, Utah) to East Avenue when this is a range of avenues from A - H. There is another local instance (in Riverdale, Utah) that the bot hasn't yet expanded where streets are named A - K. The bot could leave such instances and flag them for manual review. 3) Prefix, body, suffix is available from the TIGER data, but what about streets that have already been added (or corrected) by users? As we've seen, a bot won't always be able to correctly make these separations (as in the example of Southbay vs. South Bay given previously) How do we make it so that it meets the goals I've given? 4) Should the issue of making it easy to enter expanded street names be pushed off onto the data entry programs? 5) Should suggestions be given to renderers to use the USPS abbreviations? This brings up my previous example of South A Avenue burying the important part of the street name. a) Should we develop our own guidelines for abbreviations (as brought up by someone else)? 6) Should the direction prefix even be part of the street name since it (mostly) isn't on the sign? a) Commercial maps provide it as (for example) W 3300 S. However, I was using the OSM and Garmin routable maps on my GPS today and noticed that the Garmin maps show 3300 S (not 3300 South) for a street name. Should this be an issue that is pushed off onto the program that generates routable maps (with suggestions from OSM how to process the data)? b) I have used the alternate names (name, name_1, name_2, etc.) for alternates which would include expansions of the abbreviations. Should we establish a standard for how these are used and their order? For instance, north of 200 North, Washington Blvd is also 400 East and State Route 235 (though I know that routes are now tagged by relations). - Val - ___ 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] Street Naming Conventions
On Thu, 2010-04-08 at 23:43 -0400, Dale Puch wrote: With regards to E Ave Check for a base name if all is matched. If nothing is left, leave the name alone. I'm not sure what you asking about with Southbay vs South bay Are you trying to figure out if the bot should add or remove the space? If so, leave that for manual edits. Dale Dale, For E Ave, I don't know if you're addressing me or the bot's master (Andrew), but I'll answer for me. The tiger:name_base is actually E (the quotes are used as delimiters). Tonight, I was actually in the area and I looked at several of the street signs, but not E Ave. The actual signs of the two that I noted are A Ave and B Ave, though I noted E Ave when I originally surveyed the area. It should be expanded to E Avenue, but no more. The Southbay vs South Bay is something that someone else mentioned in this discussion. He said that his actual street name is Southbay Drive, but some mail arrives with the address of South Bay Drive (which is incorrect). This is something else that we need to avoid. - Val - ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Street Naming Conventions
Err, well you brought them up ;) But yes I guess this would largly be directed towards the bot master. E Ave example the bot needs to not change E to east despite it being the first item. The logic would be that there is no base name if E is changed to east ans Ave changed to Avenue. Deciding the suffix is the one to change and leaving the E as the base name is a little harder to be sure about when programming the bot. The southbay example... Well were talking about expanding abbreviations. So as long as we don't remove spaces when doing so there should not be any problems. Southbay has no abbreviations, and S Bay would be expanded to South Bay While the names are confusing, they would remain correct. Dale On Fri, Apr 9, 2010 at 12:08 AM, Val Kartchner val...@gmail.com wrote: On Thu, 2010-04-08 at 23:43 -0400, Dale Puch wrote: With regards to E Ave Check for a base name if all is matched. If nothing is left, leave the name alone. I'm not sure what you asking about with Southbay vs South bay Are you trying to figure out if the bot should add or remove the space? If so, leave that for manual edits. Dale Dale, For E Ave, I don't know if you're addressing me or the bot's master (Andrew), but I'll answer for me. The tiger:name_base is actually E (the quotes are used as delimiters). Tonight, I was actually in the area and I looked at several of the street signs, but not E Ave. The actual signs of the two that I noted are A Ave and B Ave, though I noted E Ave when I originally surveyed the area. It should be expanded to E Avenue, but no more. The Southbay vs South Bay is something that someone else mentioned in this discussion. He said that his actual street name is Southbay Drive, but some mail arrives with the address of South Bay Drive (which is incorrect). This is something else that we need to avoid. - Val - ___ 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] Street Naming Conventions
At 2010-04-06 22:36, Val Kartchner wrote: ... Using USPS abbreviations is the convention used by all commercial online mapping providers that I've seen. (i.e.: maps.google.com, maps.yahoo.com, www.bing.com/maps ) I think that OSM should adopt the same convention. What do people think? Yes! This has been one of those things that's been bothering me for a long time. In southern California, where I live and have mapped extensively, the cardinal direction in front of the street name is wrong. It's not part of the name on the signs, on the assessor's maps, tract/parcel maps, survey records, local legislation, etc. My general read is that it is more appropriate as a suffix to the housenumber. There are some exceptions, however: 1. Some road right-of-ways were widened and then split into two one-way streets to accommodate a new light-rail track down the middle. In some cases these streets are then named with a cardinal direction as a prefix or suffix. An example is Vermont Ave in Compton, which was split into Vermont Ave East and Vermont Ave West. 2. Another typically occurs in residential areas with roads that are circular. Example: West Liberty Pkwy and East Liberty Pkwy in Fontana. Note that the direction prefix/suffix is usually perpendicular to the main direction of the way in these cases, whereas the housenumber suffix direction is normally parallel to it (i.e. North/South on a North/South street). I've taken care to spell out the direction in these cases, in preparation for the day I could bring up this issue and hopefully get agreement to start stripping these prefixes away when they are not appropriate. Unfortunately, now, someone is running a bot that is expanding all the suffixes, so that distinction will be lost :( With regard to the street-type suffixes (e.g. St, Dr, Ct), I don't understand the reasoning behind expanding these either. As Val said, they are almost never spelled out on any sign, nor many types of records, websites, etc. Also, while it is technically a tagging for the renderer argument, I only see harm and no benefit to cluttering the rendered map with all those extra characters. Lastly, there are some exceptions (although inconceivably poorly planned) where the word may actually be part of the name (e.g. North Mainstreet and South Mainstreet) in Rancho Cucamonga). I propose that it be acceptable for someone who is familiar with a particular area to be able to move the leading cardinal direction to another tag (maybe direction=*) on streets when they know it is not appropriate in that area and specific case. I'd also like to see the changesets from this expansion bot reverted so as to allow one to make the distinction between the special cases noted above and the ones that are inappropriate. -- \Alan Mintz alan_mintz+...@earthlink.net ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Street Naming Conventions
On 04/07/2010 03:20 AM, Gregory Arenius wrote: I would also like to note though that the USPS abbreviations list is copyright the USPS. We'd probably have to recreate a similar list if we really wanted to make it our own just so that our standard is something we can put in our own documentation. Greg, Just wanted to point out that the US Government cannot hold a copyright. --Eric ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Street Naming Conventions
andrzej zaborowski balr...@gmail.com writes: Hi, On 7 April 2010 07:36, Val Kartchner val...@gmail.com wrote: The Editing Standards and Conventions (http://wiki.openstreetmap.org/wiki/Editing_Standards_and_Conventions;) page says: In the name tag, enter the full name as it appears on the street name signs. [...] Do not abbreviate words. Some sample ACTUAL street signs around here say 14th Street, 1400 South, A Ave, Bee Ct, Cheyenne Dr. If we expand the abbreviations, this still doesn't carry the other directional identifier. (e.g.: W 1400 S) However, if the directional identifer is added and expanded then A Ave becomes South A Avenue which really buries the most important part of the street name A. (Two areas I've mapped have single-letter street names, one A-H Ave and the other A-K Street.) Even expanding the local convention (for instance) of S 1000 E should be expanded to South 1000 East Street (according to the wiki), again burying the most important part. Using USPS abbreviations is the convention used by all commercial online mapping providers that I've seen. (i.e.: maps.google.com, maps.yahoo.com, www.bing.com/maps ) I think that OSM should adopt the same convention. What do people think? I'd like to see them as separate tags, but I'd really like the name= tag to remain consistent across the world, i.e. have an unabbreviated name in it, that can be passed to something like a text-to-speech system without having to keep a list of possible abbreviations for every language in the database. Especially names like St Park St (State Park Street) or St Tropez St (Saint Tropez Street) would be difficult to deal with. Changing from unabbreviated to abbreviated in a renderer or another tool is much easier on the other hand, with less space for ambiguity. Yes, this is exactly my view, too. It is much easier for tools to abbreviate the string than to expand it without ambiguity. Because in the latter case it has to make assumptions. Matthias ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Street Naming Conventions
What do people think? It is easy (I think) to know what St, Ave, and Blvd mean at the end of the name. The rest of them aren't always clear. I recently had to figure out what a Lp was (Loop - this one was new to me). I used to live on Southbay Drive. I would get mail addressed as South Bay Drive, even though there were no north/south address prefixes used anywhere nearby. The strangest was when I would get mail addressed as S Bay Drive. Fortunately there was no Bay Drive in my zipcode. - Alan ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Street Naming Conventions
I have worked with these issues for a number of years in my professional life. We have found that it is better to spell out street names. As Matthias pointed out, it is far easier to convert a named that is spelled out to one that is abbreviated than the other way around. I have seen far too many problems with going the other way. Cases where Dr was expanded to Doctor, St was expanded to Saint, etc (and vise versa) when that was not the intention. By spelling out the names we make it easier for the application consuming the data (e.g. a renderer) to make its own decision as to whether to abbreviate or not. If we use abbreviations, we lock the application into using abbreviations (and using the same abbreviations), or at the very least, make it difficult to do otherwise. Having said that, I think it is a bad idea to have a bot going through and attempting to expand abbreviations. Mike On Wed, Apr 7, 2010 at 11:27 AM, am12 a...@bolis.com wrote: What do people think? It is easy (I think) to know what St, Ave, and Blvd mean at the end of the name. The rest of them aren't always clear. I recently had to figure out what a Lp was (Loop - this one was new to me). I used to live on Southbay Drive. I would get mail addressed as South Bay Drive, even though there were no north/south address prefixes used anywhere nearby. The strangest was when I would get mail addressed as S Bay Drive. Fortunately there was no Bay Drive in my zipcode. - Alan ___ 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] Street Naming Conventions
It would probably be best to have both the 'as displayed' name, and 'as spoken' in the tags. Anything else you have to make assumptions that may or may not be right. If both are not stored, the next best alternative seems to be having the full spoken name in the tags, but have seprate prefix(directional), name and suffix fields. That way the prefix and suffix can be abbreviated while leaving the actual name alone where the odd ones might be matched to an abbreviation. This wold not cover things like the saint prefix to St. abbreviation without adding a 4th field directional, prefix, name, suffix Personally I like the 3 field, or event the 4 field storage of the name. Yes that means there is not a single field that has the full name, but I do not think a lookup and concat of 4 fields vs 1 field is much different in an indexed database. Perhaps a DB admin can shed some light on the best approach from a design and system resources standpoint. This may be a problem for apps, but if it is the best way to manage the data, the apps just need to be changed. And it would not be that hard to make the programming change if I can figure out how to do it with my limited knowledge. Some of the examples comma separated into the 4 field format: South, ,1000 East, Street ,State, Park, Street ,Saint, Tropez, Street As per the wiki, the translation to abbreviated names is a program or renderer issue, but using the USPS (for the US) as a guideline/reference seems like a good idea. The other two problems, are converting the existing names and getting everyone to input the fields correctly. A bot is always an issue. There are ways to minimize the problems though. Start with the easy ones to process automatically. Probably referencing external data to assure correct conversions by checking if similar names are in the same geographic region, and skip any that might get mixed up. Flag those for later bots, or manual correction. Dale On Wed, Apr 7, 2010 at 2:12 PM, Mike Thompson miketh...@gmail.com wrote: I have worked with these issues for a number of years in my professional life. We have found that it is better to spell out street names. As Matthias pointed out, it is far easier to convert a named that is spelled out to one that is abbreviated than the other way around. I have seen far too many problems with going the other way. Cases where Dr was expanded to Doctor, St was expanded to Saint, etc (and vise versa) when that was not the intention. By spelling out the names we make it easier for the application consuming the data (e.g. a renderer) to make its own decision as to whether to abbreviate or not. If we use abbreviations, we lock the application into using abbreviations (and using the same abbreviations), or at the very least, make it difficult to do otherwise. Having said that, I think it is a bad idea to have a bot going through and attempting to expand abbreviations. Mike On Wed, Apr 7, 2010 at 11:27 AM, am12 a...@bolis.com wrote: What do people think? It is easy (I think) to know what St, Ave, and Blvd mean at the end of the name. The rest of them aren't always clear. I recently had to figure out what a Lp was (Loop - this one was new to me). I used to live on Southbay Drive. I would get mail addressed as South Bay Drive, even though there were no north/south address prefixes used anywhere nearby. The strangest was when I would get mail addressed as S Bay Drive. Fortunately there was no Bay Drive in my zipcode. - Alan ___ 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] Street Naming Conventions
Hi, On 7 April 2010 20:12, Mike Thompson miketh...@gmail.com wrote: Having said that, I think it is a bad idea to have a bot going through and attempting to expand abbreviations. I ran the bot ([1]) over the west half of the US because me and another mapper in Portland, OR were tired of correcting the names manually when a lot of the work could really be automated. Abbreviations in the TIGER dataset are documented, both English and Spanish, and the bot bases on the list from TIGER docs (I believe this should have been done before the import as it has been done in case of other imports elsewhere in the world). After Oregon I ran the bot on the other states because of the comments I got from mappers on IRC. This was what prompted Val to start the discussion here. I'm going to hold off with it according to your comment. Funnily in an IRC discussion we concluded that it was nice that at least one thing had been agreed on in OSM :) I need to mention that the script is not fully automatic and a lot of names have been reviewed manually with note= tags added here and there, where stuff was abbreviated/misspelled beyond recognition. The current version knows about a lot of undocumented abbreviations that appear a lot in TIGER and the most common misspellings -- TIGER is really bad about consistency. Surely there are cases of erroneously expanded names and I'll be fixing them as they're found. Cheers 1. http://svn.openstreetmap.org/applications/utils/import/tiger2osm/expand/ ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Street Naming Conventions
On Tue, 06 Apr 2010 23:36:11 -0600, Val Kartchner wrote: Using USPS abbreviations is the convention used by all commercial online mapping providers that I've seen. (i.e.: maps.google.com, maps.yahoo.com, www.bing.com/maps ) I think that OSM should adopt the same convention. That's a rendering issue, not a base-data issue. Data should be entered into the database complete, not abbreviated. If you want abbreviations on your renderings, create a stylesheet that creates appropriate abbreviations. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Street Naming Conventions
On 8 April 2010 00:13, Dale Puch dale.p...@gmail.com wrote: Personally I like the 3 field, or event the 4 field storage of the name. Yes that means there is not a single field that has the full name, but I do not think a lookup and concat of 4 fields vs 1 field is much different in an indexed database. Perhaps a DB admin can shed some light on the best approach from a design and system resources standpoint. This may be a problem for apps, but if it is the best way to manage the data, the apps just need to be changed. And it would not be that hard to make the programming change if I can figure out how to do it with my limited knowledge. Some of the examples comma separated into the 4 field format: South, ,1000 East, Street ,State, Park, Street ,Saint, Tropez, Street Paul Johnson mentioned on IRC today the case of East Doctor Martin Luther King, Junior Boulevard, which wouldn't work with this schema and I don't even want to imagine how the schema would be adapted to the 200 other languages used in the database :) I think the tag like name= should really be consistent so tools can rely on it without adapting to every single country. As for the different segments of the name, there are already fields for them which we inherited from TIGER, you'll find the middle of the name is unmodified in the tiger:base_name= tag, the cardinal direction in tiger:directional_prefix= and tiger:directional_suffix and the feature type (Street, Ave etc) in type:name_type. Cheers ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
