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
