[Talk-us] More road name expansion thoughts

[Serge Wroclawski]

Hi all,

After reading about the issues with Scout and problems with name
expansion, I decided to do a little thinking on this issue.

The short answer is that Scout (as well as other text to speech
engines) should not need to be expanding values, ie E -> East. The
reason for this is that practice is error prone. We can (and largely
have) solved this problem through expanding names in the raw values.

A couple of years ago, I ran a bot that expanded hundreds of
thousands of names in OSM. The bot was very conservative about what it
expanded, which was good, but it also meant that we had a lot of names
that were left unexpanded- and as we know, if there are enough
exceptions, we have to treat those exceptions as the norm. That leads
to exactly the kind of problem Scout is experiencing now. From their
perspective, if there's a large number of unexpanded names, then they
have to do the expansion themselves, so I decided to look at the scope
fo the problem.

I took an extract of OSM of North America and looked at the last words
in road names and looked for words that looked like contractions I
found the following words that look like abbreviations:

Dr, Rd, St, Ave, Ln, Blvd, Cir, Pl and Hwy.

The total number of instance of finding one of those at the end of a
road name was 71100.

In addition, I found a bunch of directional prefixes that are probably
directional abbreviations, "NE", "NE", "SW" and "SE". There were
29,130 instances of those.

And then for "N", "S", "E", "W", there were a total of of 13,494

When you look at the total of these values, the number becomes pretty
scary- over 100,000 objects, which is just about 10% of all roads.
That means that if you're parsing OSM data, 1 in 10 roads you find
will have contractions. The numbers get worse when you realize  that
this analysis only covered the last word in a road name, not any other
word in it. I suspect the real number would be much higher.

I think we (the US OSM community) should try to make it easier for our
data consumers to work with our data by making it more consistent.

So here's what I'm thinking, and I'd really like a dialog about this:

1. I think for the first case, for "Rd" as the last word, we can be
reasonably sure that this is a contraction for "Road" and we can
expand it. This won't trigger the "Saint" problem because ot would
only trigger if St was the last word in the name.


2. I think we can do the same thing for NW/NE, etc. Those seem safe to me.

3. We could probably do the same type of expansion of NE, NW, SE, SW
if it's the first word in a name.

4. We work on some better ways of detecting these contractions and
decide what to do with them in the future (maybe find a way to expand
them automatically, maybe use MapRoulette, maybe use notes, etc.)

I'm not saying I'm going to do this. I'm not even officially proposing
it yet. I'm pointing out a problem and potential solution. My feeling
is that if we can drop the number of problems in our dataset by 90%
without much effort, then we should do that.

I really want to hear people's thoughts on this.

- Serge

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] More road name expansion thoughts

[Dale Puch]

My 2 cents.

I reviewed a script for expanding names a year or two ago (yours I think),
and thought it worked very well.  I do not recall finding any false
positives.  If we have over 100,000 new names that it would catch then it
sounds like we need to run it on a regular basis.  Or are there so many
because the script only ran on tiger entries by default?

I say retest the script detection and use it regularly for the start/end
abbreviations.  Expand it to other detection if it can be shown to be
reliable.
Throw in a semi regular MapRoulette task to look for more complicated or
vague abbreviations and the problem can be kept under control.  This can
also be used to verify advanced scripts reliability by offering a suggested
expansion on the harder names.

If there is still any concern of incorrect expansion, output logs with
old/new names, links to the ways and a link for revert and tag not to
expand in the future.  MapRoulette should also have a checkbox to block
further expanding a name in future checks.


Dale Puch


On Sat, Jul 19, 2014 at 12:27 PM, Serge Wroclawski 
wrote:

> Hi all,
>
> After reading about the issues with Scout and problems with name
> expansion, I decided to do a little thinking on this issue.
>
> The short answer is that Scout (as well as other text to speech
> engines) should not need to be expanding values, ie E -> East. The
> reason for this is that practice is error prone. We can (and largely
> have) solved this problem through expanding names in the raw values.
>
> A couple of years ago, I ran a bot that expanded hundreds of
> thousands of names in OSM. The bot was very conservative about what it
> expanded, which was good, but it also meant that we had a lot of names
> that were left unexpanded- and as we know, if there are enough
> exceptions, we have to treat those exceptions as the norm. That leads
> to exactly the kind of problem Scout is experiencing now. From their
> perspective, if there's a large number of unexpanded names, then they
> have to do the expansion themselves, so I decided to look at the scope
> fo the problem.
>
> I took an extract of OSM of North America and looked at the last words
> in road names and looked for words that looked like contractions I
> found the following words that look like abbreviations:
>
> Dr, Rd, St, Ave, Ln, Blvd, Cir, Pl and Hwy.
>
> The total number of instance of finding one of those at the end of a
> road name was 71100.
>
> In addition, I found a bunch of directional prefixes that are probably
> directional abbreviations, "NE", "NE", "SW" and "SE". There were
> 29,130 instances of those.
>
> And then for "N", "S", "E", "W", there were a total of of 13,494
>
> When you look at the total of these values, the number becomes pretty
> scary- over 100,000 objects, which is just about 10% of all roads.
> That means that if you're parsing OSM data, 1 in 10 roads you find
> will have contractions. The numbers get worse when you realize  that
> this analysis only covered the last word in a road name, not any other
> word in it. I suspect the real number would be much higher.
>
> I think we (the US OSM community) should try to make it easier for our
> data consumers to work with our data by making it more consistent.
>
> So here's what I'm thinking, and I'd really like a dialog about this:
>
> 1. I think for the first case, for "Rd" as the last word, we can be
> reasonably sure that this is a contraction for "Road" and we can
> expand it. This won't trigger the "Saint" problem because ot would
> only trigger if St was the last word in the name.
>
>
> 2. I think we can do the same thing for NW/NE, etc. Those seem safe to me.
>
> 3. We could probably do the same type of expansion of NE, NW, SE, SW
> if it's the first word in a name.
>
> 4. We work on some better ways of detecting these contractions and
> decide what to do with them in the future (maybe find a way to expand
> them automatically, maybe use MapRoulette, maybe use notes, etc.)
>
> I'm not saying I'm going to do this. I'm not even officially proposing
> it yet. I'm pointing out a problem and potential solution. My feeling
> is that if we can drop the number of problems in our dataset by 90%
> without much effort, then we should do that.
>
> I really want to hear people's thoughts on this.
>
> - Serge
>
> ___
> Talk-us mailing list
> 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

Re: [Talk-us] More road name expansion thoughts

[Mike N]

On 7/19/2014 2:38 PM, Dale Puch wrote:

I say retest the script detection and use it regularly for the start/end
abbreviations.  Expand it to other detection if it can be shown to be
reliable.


  I think the idea of some additional automated expansion is a good 
idea.  Let's circulate the idea for a while to see if anyone knows of 
cases which will fail.


  For the end cases Dr, Rd, St, Ave, Ln, Blvd, Cir, Pl and Hwy - I 
believe it will work better than 99.9%.


  But in the starting position, I already know of 2 cases that will 
produce a false directional and false prefix type.Perhaps the edge 
cases can be tagged to eliminate them from any automated expansion.



Throw in a semi regular MapRoulette task to look for more complicated or
vague abbreviations and the problem can be kept under control.  This can
also be used to verify advanced scripts reliability by offering a
suggested expansion on the harder names.


  St / Saint on a prefix can be so specialized that only a local could 
sort it out.   I suspect that most of the unusual cases would be too 
complicated for MapRoulette because of the need to consult with a 
governmental reference.



___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] More road name expansion thoughts

[Paul Norman]

On 2014-07-19 2:46 PM, Mike N wrote:
I suspect that most of the unusual cases would be too complicated for 
MapRoulette because of the need to consult with a governmental reference. 
Or actually survey them. Aside from first-hand knowledge being superior, 
there tends to be a high error rate in "official" databases for the 
unusual cases.


___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] More road name expansion thoughts

[Mike N]

On 7/19/2014 6:06 PM, Paul Norman wrote:

On 2014-07-19 2:46 PM, Mike N wrote:

I suspect that most of the unusual cases would be too complicated for
MapRoulette because of the need to consult with a governmental reference.

Or actually survey them. Aside from first-hand knowledge being superior,
there tends to be a high error rate in "official" databases for the
unusual cases.


  In my case, if I see "Ext" on a sign - does it stand for Extension or 
Extended?   Only the local authority or convention would tell me.



___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] More road name expansion thoughts

[Serge Wroclawski]

Thanks to all the folks who've commented on this thread and also to
the folks who contacted me off list about this. A majority of the
feedback I received was very positive, which I'm thankful about. I
attribute much of this to the very conservative approach that was
taken last time, because there were so few problems, people are more
open to more of the same kind of work.

I want to give a comprehensive answer to a lot of your questions.

* Problems with bad TIGER data

I heard that there were a few questions raised about the last bot
expansion. It turns out that there were problems last time related to
bad TIGER data. So for example, the TIGER data may have included
something indicating that the road had a directional suffix for East,
and the road name was Foo T E, since the road had a TIGER tag
indicating the directional suffix, the name was changed to Foo T East.

The previous bot used the TIGER data to do the name expansions. If
TIGER was wrong, so was the name expansion.

* Missed contractions in the previous name expansion

I received some feedback about lesser used contractions not getting
expanded. This should probably be addressed. I'm collecting these and
will likely propose just quickly running through them, outside of this
expansion.

* Common contractions

People seemed pretty to agree that for a majority of cases, if the
contraction is either a prefix or suffix and is relatively
unambiguous, like "Rd" or "Blvd", we can just expand it. I think this
also extends to "NW" and other two letter directions.

* Concerns about ambiguous contractions and local editing

A few people brought up a concern about words which could be
contractions but aren't always, such as "E" or "S". I agree with this
concern and I think we need to put the plain ordinals into a separate
cateogry.

I agree and I also agree with people who expressed concerns that the
only way to solve these problems is through direct survey. Maybe the
solution here is to create notes?

* Continually running bot

There was discussion about a continually running bot that would go
around and fix these, as well as other problems. This is something
that OSM has has in the past with fixbot, xybot and currently has with
WALL-E in Germany. I think it might make sense for us to have
something similar here in the US  to address common problems, like
expanding Rd to Road, or "road" to "Road".

I'm in favor of this idea, but I'd like to hear more feedback about
this. If we did it, I'd want the process to be as transparent as
possible.

- Serge

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] More road name expansion thoughts

[Minh Nguyen]

On 2014-07-19 14:46, Mike N wrote:

   St / Saint on a prefix can be so specialized that only a local could
sort it out.   I suspect that most of the unusual cases would be too
complicated for MapRoulette because of the need to consult with a
governmental reference.


Or a historian. In the Midwest, "St. Clair" could either refer to the 
saint or to Arthur St. Clair, whose name wasn't "Arthur Saint Clair". 
(See [1].) I often put the "Saint" misspelling in alt_name, since the 
etymology isn't always clear to people searching the map. Unfortunately, 
that still leaves an ambiguous name for text-to-speech. Too bad there 
isn't software support for name:pronunciation or name:ipa.


[1] https://en.wikipedia.org/wiki/Sinclair_%28surname%29

--
m...@nguyen.cincinnati.oh.us


___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] More road name expansion thoughts

[Mikel Maron]

Hi

There are cases where expansion is far from standard, according to local
convention.

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.

For spoken navigation systems, this is probably the easiest situation to
identify and handle, without ambiguity.

OSM maps of DC now just look a bit bizarre.

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. I think
it's also a good idea for DC mappers to reconsider the suffix expansion in
our special case.

Thanks
Mikel
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] More road name expansion thoughts

[Serge Wroclawski]

On Mon, Jul 21, 2014 at 9:01 AM, Mikel Maron  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'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. 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
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] More road name expansion thoughts

[Alex Barth]

On Mon, Jul 21, 2014 at 3:45 PM, Serge Wroclawski  wrote:

>
> > 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.


Mapbox has an exception for DC that contracts names.

While I agree with the paradigm to manage data in a way that is conducive
for consuming it, you can use it to construe the argument for _and_ against
expansion of DC-like abbreviations (NW, NE, SW, SE quadrants).

- If you expand DC-like abbreviations, then you need to contract them when
making a map. Now how do you find out systematically which ones are the
DC-like abbreviations you need to contract on a global map?
- Say you contracted DC-like abbreviations, now you need to somehow find
out how to feed them into text to speech.

Agreed that DC map looks odd now on OSM.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] More road name expansion thoughts

[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  wrote:

> On Mon, Jul 21, 2014 at 9:01 AM, Mikel Maron 
> 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'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. 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
> https://lists.openstreetmap.org/listinfo/talk-us
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] More road name expansion thoughts

[Simon Poole]

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  > wrote:
> 
> On Mon, Jul 21, 2014 at 9:01 AM, Mikel Maron  > 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 '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 .
> 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 
> 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

Re: [Talk-us] More road name expansion thoughts

[Serge Wroclawski]

Hi folks,

Received lots more comments on list and off list- a robust discussion
about data uniformity vs localism, words vs signage, the importance of
rendering (be it visual or auditory), etc.

These are really interesting and important topics, but I think we're going to
get bogged down if we try to address it all at once, so here's what
I'm suggesting:

1. The issue raised about DC contractions is clearly one where people
   have strong views. I think it deserves its own
   discussion. So if the DC folks want to discuss DC's road expansion
   separately, I say go for it. It wouldn't be very hard to contract
   the names there based on the same TIGER tags that we used to expand
   them. I don't personally think that's what we should do, but I'm
   happy to participate in the discussion.

2. I haven't seen anyone on this list disagree with the OSM general
   method of expanding road identifiers (Street, Lane, Boulevard,
   etc.). So we can agree on that and I think move forward with the
   general proposal around name expansion.

3. There seems to be interest in automated edits happening on a
   continuing basis. I'm cautiously in favor. I think it's something
   that if we do, we need to do very carefully, as a community, with
   lots of input and community oversight.

4. I think there's some really good discussion about
   tagging. Utilizing short_name might be a good idea. I also like the
   idea sign_name tag. If you build a routing engine, you might want
   to show the sign name as it appears on the street, for example,
   which isn't always going to be how one might think it is. There
   will inevitably will be some odd exceptions, but that's the nature
   of this kind of data.

   By the same token, I'd really love to see us have pronunciation
   data associated with road names to deal with the fact that a
   name doesn't always get pronounced how you think it does. For
   example, "Houston" is pronounced one way for the city "Hew-ston"
   but the street in NYC is pronounced "How-ston". It'd be great if
   we have those exception pronunciations in OSM.

   So it might be interesting and worthwhile to explore some of these
   ideas on a new thread.

In a moment of over-sharing, I'm probably going to postpone any work
on this for a few weeks. It turns out that a surgery I had needs to be
re-done, so that's happening Friday- I'll be out for another seven to
ten days after that in recovery. Sadly that's on top of the ~3 weeks of
recovery I've just come out of, so my schedule is very backed
up. There's nothing in this discussion which strikes me as time
critical, so I see it as more time to discuss and contemplate.

- Serge

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] More road name expansion thoughts

[Martin Koppenhoefer]

> Am 23/lug/2014 um 05:10 schrieb Serge Wroclawski :
> 
> I also like the
>   idea sign_name tag. If you build a routing engine, you might want
>   to show the sign name as it appears on the street,



as a side note there are already few occurrences of signed_name but none of 
sign_name
It is worth considering that there might be more than one sign, sometimes with 
different text (multivalue on the highway and/or map it on nodes at the sign 
location)

cheers,
Martin
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] More road name expansion thoughts

[Jake Wasserman]

>
>
> 2. I haven't seen anyone on this list disagree with the OSM general
>method of expanding road identifiers (Street, Lane, Boulevard,
>etc.). So we can agree on that and I think move forward with the
>general proposal around name expansion.
>

Could we also apply this to exit_to=* or destination=* for exit signs?

We want to make sure text-to-speech engines don't have to do the expansion
manually, and it's equally important to speak the road names correctly when
exiting highways too. If the names on the ways are expanded but the exits
remain abbreviated, we'd have to implement all the expansion code anyway -
subject to all the errors this is trying to avoid.

Thanks,
Jake
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us