Just a quick remark: there is already a tag "short_name" that is supported for example by nominatim that can be used for storing a contracted version of name for rendering and other purposes if necessary.
Simon PS: these discussions are not unique to the states, even though the use of contractions is likely to be highest there. Am 22.07.2014 01:55, schrieb Dale Puch: > I see the reason for all this work is to make the data un-ambigious. To > that end expanding all the contractions. This is needed for text to > speech, consistent searches, and probably a few other issues. From the > expanded data names can be contracted a lot easier without mistakes. > > Raw data: northwest 15th drive > spoken data: northwest fifteenth drive > Map data: NW 15th Dr. > > I don't think we need to store 2 or 3 copies for 99.9% of the names, but > some will break the rules the rest follow and need some kind of "don't > expand" flag or alt name(s) stored because of that. > > > Dale Puch > > > On Mon, Jul 21, 2014 at 9:45 AM, Serge Wroclawski <emac...@gmail.com > <mailto:emac...@gmail.com>> wrote: > > On Mon, Jul 21, 2014 at 9:01 AM, Mikel Maron <mikel.ma...@gmail.com > <mailto:mikel.ma...@gmail.com>> wrote: > > > Here in Washington DC, the street names are all suffixed with the > quadrant > > (NW, SE, SW, NE) the road lies in. The official names of the > streets kept by > > the DC city government all use the contraction. Historically, I > could find > > no maps that used the expansion. > > The city maps may use the same contractions as TIGER, etc. but we know > they're contractions, which is distinct from being words, so I don't > the city maps as being a reason for changing the way the entire OSM > project handles contractions. > > BTW, for anyone who isn't aware, I lived in DC from 1996-2012, which > is both a long time, and also a recent time. I consider myself > essentially a local in this matter. > > > For spoken navigation systems, this is probably the easiest > situation to > > identify and handle, without ambiguity. > > The real issue is trying to standardize the OSM data for data > consumers, which text-to-speech systems will benefit from, but they're > not the only ones. > > > OSM maps of DC now just look a bit bizarre. > > The MapBox folks seemed to have figued this out US-wide and > re-contract the road names and the directional identifiers. This is a > rendering problem- one which I agree with you 100% that it should be > fixed, not just for directions but also for road identifiers, because > we in the US are used to seeing contractions. > > Another proposal I've seen which seemed interesting (though not free > of problems) is the idea of a new tag that was basically the name of > the road exactly as it appears on a road sign. > > I agree with you 100% that we should strive for a map that looks > "American" for US map users. The MapBox folks seem to have done it, so > really this is a problem with osm.org <http://osm.org>'s map. Their > map is really > British-Euro centric in many ways, and it would really be nice if we > had a good, solid alternative, much like osm.fr <http://osm.fr>. > Maybe MapBox can > share some of their style with us, or if not, we have our work cut out > for us, but I'm sure we can do it. > > > So I don't recommend we apply this expansion without consideration of > > regional variation. Before any expansion scripts are run, in DC or > anywhere, > > the local community needs to be consulted sufficiently. > > Can you elaborate on this? > > - Serge > > _______________________________________________ > Talk-us mailing list > Talk-us@openstreetmap.org <mailto:Talk-us@openstreetmap.org> > https://lists.openstreetmap.org/listinfo/talk-us > > > > > _______________________________________________ > Talk-us mailing list > Talk-us@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-us >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
