[OSM-talk] Name Finder and abbreviations

[Karl Newman]

On Dec 3, 2007 9:55 AM, Andrew MacKinnon <andrewpmk at gmail.com> wrote:
> > I realize it's quite late in the game for this, but it would be nice
> > to have fully componentized names: prefix, base_name, type, suffix
> > (i.e., NW Main Street would be prefix=NW, base_name=Main,
> > type=Street). Then the renderers could do more intelligent things with
> > the names without having to guess, such as creating abbreviations
> > without having to determine if it's a type or part of the base name
> > (isn't there a Street Street somewhere?), or showing less of the name
> > at lower zooms (i.e., in Garmin GPS maps, you can limit the parts of
> > the full name that are shown at lower zooms).
> >
> > This would be a nice addition to the standard "name" tag.
>
> For the TIGER and AND data we already have this information so it
> could be added easily (fairly easily anyway). For other data I think
> that it would be possible to create a bot that parses the street name
> data and separates the full name into its appropriate parts; it would
> need to understand multiple languages and it would need to flag any
> ambiguous cases for human review.
>
I thought the TIGER data had that already, but I looked and couldn't
find the answer quickly. For TIGER, we'd need a "abbreviation
expansion" table to get back from "St" to "Street". Since the TLIDs
are stored with the ways, it should be easy enough to get that data in
there.

Is there any support for this idea? I realize there could be a
synchronization (parallel update) problem between the name tag and the
componentized version, but is that going to be a significant problem?
How often does the name tag change? I guess there's also the issue of
multiple names per way...

Karl