Re: [Talk-us] name expansion bot (Re: Imports information on the wiki)

[Alan Mintz]

At 2012-01-15 05:35, Mike N wrote:

On 1/15/2012 8:28 AM, Nathan Edgars II wrote:

Actually the script also expanded the W to West. But my point is that it
is a TIGER entry error, and any future script needs to take into account
that these exist and people may have already fixed them to the correct
names.


 Agreed- if we're thinking of a bot that periodically fixes everything, 
we need a special tag that says "abbreviation_bot=back_off" (but perhaps 
not so verbose) - something that tells the bot not to touch the name 
because it is unusual and has been manually checked.


I hope there is no such bot being contemplated again. The last one created 
lots of issues. In any case, a tag shouldn't be necessary - if the name has 
been edited by a human, it should not be updated by a bot, or even another 
human unless they are willing to prove their edit. I've edited thousands of 
names based on photo surveys and official record research and wouldn't want 
that high-quality data corrupted.


My experience is that TIGER is generally of poor quality with regard to 
names, and is actually getting worse. I routinely see streets that are made 
up of multiple segments where the spelling or suffix is not consistent 
among them. Some of these were even correct in the original TIGER05 import, 
and were corrupted since by a TIGER editor!


--
Alan Mintz 


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

Re: [Talk-us] Remapping tips

[Alan Mintz]

At 2012-02-06 16:19, Paul Johnson wrote:

On Mon, 2012-02-06 at 17:14 -0600, Martijn van Exel wrote:
> On Mon, Feb 6, 2012 at 5:06 PM, Nick Hocking  
wrote:

> >
> > [..]and copy in the TIGER 2011 name from the TMS overlay (remembering 
to un-abreviate as you go).

>
> As a reminder: the JOSM URL for that is
> 
http://{switch:a,b,c}.tile.openstreetmap.us/tiger2011_roads/{zoom}/{x}/{y}.png

>
> > Some roads are (unfortunately) glued to landuse polygons. For these
> > you need to unglue first to make room for the road replacement. These
> > take a lot more time but, hopefully, there are not too many of these.
>
> That's really bad practice IMO, but I find it practised here in Salt
> Lake too. Quick way to unglue: Select the way, shift-select the glued
> point(s), press g.

Ideally, these should be shifted to the border of the land use, rather
than another location within the right of way.


Exactly. As a technical matter, in almost all cases of a public roads in 
the US, if you look at the tract map, you will see a permanent dedication 
of an easement/right-of-way for the road, and that land cannot be built on. 
For the most part, these ROWs are even wider than the road itself has been 
built on. The residential and commercial landuse ways should definitely 
extend no further than the sidewalk in this vast majority of the scenarios.


Even if it were possible for someone to build in the middle of a street, 
unless they actually have done so, it shouldn't be mapped that way, since 
we aim to map what we see now, not duplicate a zoning map of what could be.


--
Alan Mintz 


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

Re: [Talk-us] TIGER 2011 Road Tiles

[Alan Mintz]

At 2012-01-15 10:11, Ian Dees wrote:
In order to assist with road name checking I've set up a Mapnik layer 
rendering from TIGER 2011 ROADS data.



I also stumbled across the fact that the Census is making some of TIGER 
available as a WMS, too: http://wiki.openstreetmap.org/wiki/TIGER_2011#WMS


As I said earlier, one should not necessarily use TIGER11 to correct 
earlier TIGER05 names when the two differ. Positioning has improved 
tremendously in urban and sub-urban areas, but I'm finding lots of naming 
discrepancies. Better quality will result if we verify from additional 
sources, like those available from many counties. Note that the Census's 
BAS maps seem to be from the same source database as TIGER, though maybe 
extracted at different times.


--
Alan Mintz 


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

Re: [Talk-us] TIGER 2011 Road Tiles

[Toby Murray]

On Fri, Feb 17, 2012 at 7:14 AM, Alan Mintz
 wrote:
>
> Better quality will result if we verify from additional sources, like those
> available from many counties.

The best quality will result if we grab a GPS unit and a camera and GO
there ourselves. Just sayin' :)

(yes, I have used TIGER 2011 myself and it is a decent resource. Just
making sure OSM's primary strength isn't lost in all this talk of
external data sources!)

Toby

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

Re: [Talk-us] name expansion bot (Re: Imports information on the wiki)

[Bill Ricker]

On Mon, Jan 16, 2012 at 6:34 PM, Val Kartchner  wrote:

> In my area I know of two separate streets named "E Avenue" and an "E
> Street".
>

Boston has E St, intersecting W 1st St, between D St and F St as you'd
expect. But W 1st St *crosses*  E 1st St at the grid discontinuity (extends
one block east of the oblique intersection with).

When a street further onto made-land than W 1st St was built, it was named
New Cypher St of course (cypher being an old word for zero).

http://osm.org/go/ZfIvnWyD

(I'd love to get planning approval for Negative One St beyond New Cypher
St, but  the new Convention Center fills the space.)

We also have a St James St, less well known since Greyhound moved their
terminal from there into a shared multi-mode hub.

-- 
Bill
@n1vux bill.n1...@gmail.com
___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] TIGER 2011 Road Tiles

[Martijn van Exel]

On Fri, Feb 17, 2012 at 8:35 AM, Toby Murray  wrote:
> On Fri, Feb 17, 2012 at 7:14 AM, Alan Mintz
>  wrote:
>>
>> Better quality will result if we verify from additional sources, like those
>> available from many counties.
>
> The best quality will result if we grab a GPS unit and a camera and GO
> there ourselves. Just sayin' :)
>
> (yes, I have used TIGER 2011 myself and it is a decent resource. Just
> making sure OSM's primary strength isn't lost in all this talk of
> external data sources!)
>
> Toby
>

Good point Toby. You are right, there has not been too much talk on
this list about actual mapping lately. I haven't done much beyond
remapping SLC lately... And I forgot to bring my GPS when I went
skiing in Alta[1] the other day.

On the topic of TIGER layers: Harry Wood made an interesting
suggestion in the comments section of my blog post on road analysis
(see other post): wouldn't it be interesting to crowdsource
particularly problematic (in terms of alignment) areas of TIGER data?
What do you think? (How) could that work?

[1] http://osm.org/go/T0HHvKaZ-
-- 
martijn van exel
geospatial omnivore
1109 1st ave #2
salt lake city, ut 84103
801-550-5815
http://oegeo.wordpress.com

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

Re: [Talk-us] Shootout in Vegas

[Alan Mintz]

At 2012-01-18 13:43, Nick Hocking wrote:
 
http://www.openstreetmap.org/?lat=35.996927&lon=-114.925865&zoom=18&layers=M
 
TIGER 2011, google maps, and some other sources show the intersection
as
Shootout Place and Cattle Ranch Place. However TIGER 2010 and
Google Streetview indicate the inersection is between Gold Camp Street
and
Cattle Ranch Place.   I have put TIGER 2011 into
OSM.
I'm seeing something different than you are.
TIGER11 shows the intersection at 35.9967094, -114.9276717 is between
Cattle Ranch Place and Gold Camp Street.
Gold Camp Street (TLID 20213) heads ~NE for ~40m and then turns ~N
(as TLID 20215) at the intersection with Shootout Place at
35.9969776, -114.9273722.
Using GISMO
(http://gisgate.co.clark.nv.us/openweb/),
we can look at other official sources. The assessor's map (179-34-5), as
expected, doesn't show anything conclusive, since there are no parcels on
this short street. Digging further, in PL105-70 page 2
(http://gisgate.co.clark.nv.us/assessor/webimages/default.asp),
the segment is unlabeled. Based on TIGER11, I changed it back to Gold
Camp.
If one were able to use Google's Street View as a source (which we are
not!), one could just make out that the street sign at the first
intersection looks more like Gold Camp than Shootout.
... [time passes]
I missed a detail in PL105-70. On page 5, there are details of the
corners in question, clearly showing the short segment as being named
Shootout Place. Given that this is the only official record, I would name
it as such (and did). Someone should verify the signage, which may be
incorrect.
FWIW, after working on thousands of similar intersections, I would think
it more likely to be named Shootout than Gold Camp, given the
geometry.

Also just South of this, it appears
that Pistol Perry Parkway is gated.
Looks gated to me too. PL106-61 also reserves that and other streets
within as private streets, which generally means it's a gated
community.

Bing imagery is not conclusive so
if a real mapper could verify this, that would
be great.
 
 
Nick
 
 
___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

--
Alan Mintz 



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

Re: [Talk-us] TIGER 2011 Road Tiles

[Mike N]

On 2/17/2012 10:05 AM, Martijn van Exel wrote:

On the topic of TIGER layers: Harry Wood made an interesting
suggestion in the comments section of my blog post on road analysis
(see other post): wouldn't it be interesting to crowdsource
particularly problematic (in terms of alignment) areas of TIGER data?
What do you think? (How) could that work?


  I don't think that would lend itself to 'Mechanical Turk' general 
solutions in the way that turning circles would for example.   It takes 
a bit of analysis to sort out - in many of the cases I've seen, 
intersecting roads must be untangled, changing the order at which they 
intersect the road in question.   It would require that the crowds be 
well trained the the use of the OSM editor they are using.


  That being said, this could be done by armchair mappers, provided 
that there is enough 'armchair labor' available.


  Another aspect is use of improved geometry from another layer via a 
conflation plugin.   This has been discussed several times before but I 
haven't had time to work on it.   I've used the concept on a small scale 
against Mapdust reports, bringing in new TIGER data from another layer, 
then from JOSM's UtilsPlugin2, 'More tools' / Replace Geometry.


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

Re: [Talk-us] TIGER 2011 Road Tiles

[Alan Mintz]

At 2012-02-17 06:35, Toby Murray wrote:

On Fri, Feb 17, 2012 at 7:14 AM, Alan Mintz
 wrote:
>
> Better quality will result if we verify from additional sources, like those
> available from many counties.

The best quality will result if we grab a GPS unit and a camera and GO
there ourselves. Just sayin' :)


Of course. I've spent a great deal of money and time doing so. But again, 
it only proves what is signed. I've been responsible for getting bad 
signage replaced when I saw conflicts between it and the official record.


I'd welcome financial support for continued field surveys if anyone knows 
of a source.


--
Alan Mintz 


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

Re: [Talk-us] Shootout in Vegas

[Alan Mintz]

Found some more evidence.

In GISMO, if you zoom far enough in, the segment in question gets a label - 
Shootout Pl.


I also found street centerlines at 
http://gisgate.co.clark.nv.us/gismo/freedataNEW.htm in crscl-shp.zip 
(streets_l dated 2012-01-27) which confirms the name Shootout Place.


--
Alan Mintz 


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

Re: [Talk-us] name expansion bot (Re: Imports information on the wiki)

[Paul Johnson]

On Fri, Feb 17, 2012 at 12:02 AM, Alan Mintz
wrote:

> At 2012-01-15 05:35, Mike N wrote:
>
>> On 1/15/2012 8:28 AM, Nathan Edgars II wrote:
>>
>>> Actually the script also expanded the W to West. But my point is that it
>>> is a TIGER entry error, and any future script needs to take into account
>>> that these exist and people may have already fixed them to the correct
>>> names.
>>>
>>
>>  Agreed- if we're thinking of a bot that periodically fixes everything,
>> we need a special tag that says "abbreviation_bot=back_off" (but perhaps
>> not so verbose) - something that tells the bot not to touch the name
>> because it is unusual and has been manually checked.
>>
>
> I hope there is no such bot being contemplated again. The last one created
> lots of issues.


Sounds like it would be better to come up with a more comprehensive
algorithm for the bot, not outright deny the need for it altogether.
 Granted, it did make minor messes in Oregon (where names with "St."
meaning "Saint," "Santa/o" or "Sainte" are slightly more common) and
Oklahoma (where single-letter street names are slightly more common), but
overall, the automation saved countless hours of manual name expansion for
the minor cost of having to deal with a very small number of largely
regionally-isolated edge cases.
___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] name expansion bot (Re: Imports information on the wiki)

[Rich]

On 02/17/12 22:01, Paul Johnson wrote:


On Fri, Feb 17, 2012 at 12:02 AM, Alan Mintz
mailto:alan_mintz%2b...@earthlink.net>>
wrote:

At 2012-01-15 05:35, Mike N wrote:

On 1/15/2012 8:28 AM, Nathan Edgars II wrote:

Actually the script also expanded the W to West. But my
point is that it
is a TIGER entry error, and any future script needs to take
into account
that these exist and people may have already fixed them to
the correct
names.


  Agreed- if we're thinking of a bot that periodically fixes
everything, we need a special tag that says
"abbreviation_bot=back_off" (but perhaps not so verbose) -
something that tells the bot not to touch the name because it is
unusual and has been manually checked.


I hope there is no such bot being contemplated again. The last one
created lots of issues.


Sounds like it would be better to come up with a more comprehensive
algorithm for the bot, not outright deny the need for it altogether.
  Granted, it did make minor messes in Oregon (where names with "St."
meaning "Saint," "Santa/o" or "Sainte" are slightly more common) and
Oklahoma (where single-letter street names are slightly more common),
but overall, the automation saved countless hours of manual name
expansion for the minor cost of having to deal with a very small number
of largely regionally-isolated edge cases.


i would agree. on my usa visit, i'm doing some minor edits, and they 
have been in florida & chicago mainly. those street names are quite 
painful to deal with.


first, i suspect the damage done would still be way lower than the time 
spent on manual fixing. second, it should be possible to run the 
algorithm and throw out the results for people to review. fix things 
spotted, run it again and again, until no problems are reported, then 
just attack the data.


this is similar to what we did with komzpa for latvia (albeit on a much 
smaller scale, of course). there were a lot of problems like 
capitalisation mistakes, some common spelling mistakes, some common 
mistakes/silly approaches (like name=gas station - but not in english, 
of course :) ). we also had a couple of persons who took josm warning 
about unnamed objects way too seriously, thus we had loads of roads, 
lakes, power substations and other objects with name=. name=a name=l 
name=u nd so on.
komzpa prepared first batch run with his automated script, which was 
mostly tested in belarus, as far as i recall, and had some lithuanian 
changs as well. results were disastrous :)

if he had submitted that, i'd probably report him as a vandal ;D
so i took the xml and reviewed every single change in it, reported all 
the problems i found. he applied some fixes and run the script again. i 
reviewed it again and reported (smaller amount) of problems. he spent 
quite some time on those scripts, i spent probably 6-8 hours in total 
for all the review cycles. but the time spent manually to find and fix 
all those problems would be way, way more (or, more likely, most of the 
problems would be never fixed).


so, generate the change xmls, attack them in group, fix mistakes and do 
an automated edit once nobody can find any problems.

--
 Rich

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

Re: [Talk-us] name expansion bot (Re: Imports information on the wiki)

[Mike N]

On 2/17/2012 3:02 AM, Alan Mintz wrote:

if the name has been edited by a human, it should not be updated by a
bot, or even another human unless they are willing to prove their edit.
I've edited thousands of names based on photo surveys and official
record research and wouldn't want that high-quality data corrupted.


For myself, I don't know how to determine what the "correct name" would 
be ... if it doesn't match the street sign, I'd be inclined to change it 
to agree with the sign, unless there's a 'note' tag to other mappers. 
Similarly, an 'anti-abbreviation-bot' tag would prevent bots from 
undoing your research.


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

Re: [Talk-us] name expansion bot (Re: Imports information on the wiki)

[TC Haddad]

On Fri, Feb 17, 2012 at 12:01 PM, Paul Johnson  wrote:

 but overall, the automation saved countless hours of manual name expansion
> for the minor cost of having to deal with a very small number of largely
> regionally-isolated edge cases.
>
>
Can someone explain the original point of name expansion? Is it so that
devices that give audio directions using text-to-speech can read fluently?
Or was it really all about "saving time"?

Because there are other use cases where expanded names are not desirable,
particularly in cartography. When map or screen real estate is minimal,
expanded names can be downright detrimental to utility.

For example: in Portland all the expanded quadrant names (NE,NW, SE, SW)
really detract from the experience of using osm extracts on handheld GPS.
All the streets in an area of interest end up looking like they have the
same name because all that fits on the street segments is the first word of
the expanded quadrant label and not the "real" part of the name. So "NE
Tillamook" and "NE Hancock" both just label as "Northeast"... and that is
separate from the issue that people don't actually write addresses here as
"Northeast Tillamook".

Anyway, maybe that is an edge case example, but I guess it bugs me.
___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] name expansion bot (Re: Imports information on the wiki)

[Alan Mintz]

At 2012-02-17 12:50, Mike N wrote:

On 2/17/2012 3:02 AM, Alan Mintz wrote:

if the name has been edited by a human, it should not be updated by a
bot, or even another human unless they are willing to prove their edit.
I've edited thousands of names based on photo surveys and official
record research and wouldn't want that high-quality data corrupted.


For myself, I don't know how to determine what the "correct name" would be 
... if it doesn't match the street sign, I'd be inclined to change it to 
agree with the sign, unless there's a 'note' tag to other mappers. 
Similarly, an 'anti-abbreviation-bot' tag would prevent bots from undoing 
your research.


When I edit, I populate the source and source_ref with the appropriate 
values to cite my source(s) and remove the tiger:reviewed tag if present. 
The fact that the object has been edited by a human should be sufficient to 
keep the bot from touching it.


--
Alan Mintz 


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

Re: [Talk-us] name expansion bot (Re: Imports information on the wiki)

[Nathan Edgars II]

On 2/17/2012 4:41 PM, TC Haddad wrote:

For example: in Portland all the expanded quadrant names (NE,NW, SE, SW)
really detract from the experience of using osm extracts on handheld
GPS. All the streets in an area of interest end up looking like they
have the same name because all that fits on the street segments is the
first word of the expanded quadrant label and not the "real" part of the
name. So "NE Tillamook" and "NE Hancock" both just label as
"Northeast"... and that is separate from the issue that people don't
actually write addresses here as "Northeast Tillamook".


If the directional prefixes are not generally used as part of the name, 
they should probably not be in the name tag, but instead as an address 
tag (I've used addr:direction e.g. 
http://www.openstreetmap.org/browse/way/140789671).


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

Re: [Talk-us] name expansion bot (Re: Imports information on the wiki)

[Paul Johnson]

On Fri, Feb 17, 2012 at 1:41 PM, TC Haddad  wrote:

> On Fri, Feb 17, 2012 at 12:01 PM, Paul Johnson wrote:
>
>  but overall, the automation saved countless hours of manual name
>> expansion for the minor cost of having to deal with a very small number of
>> largely regionally-isolated edge cases.
>>
>>
> Can someone explain the original point of name expansion? Is it so that
> devices that give audio directions using text-to-speech can read fluently?
> Or was it really all about "saving time"?
>
> Because there are other use cases where expanded names are not desirable,
> particularly in cartography. When map or screen real estate is minimal,
> expanded names can be downright detrimental to utility.
>
>
Sounds like a problem for the renderer to solve.  It's possible for
renderers to easily create abbreviations when full words are not desired,
but impossible for automated translation and renderers to expand
abbreviations accurately.
___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] name expansion bot (Re: Imports information on the wiki)

[Paul Johnson]

On Fri, Feb 17, 2012 at 2:32 PM, Nathan Edgars II wrote:
>
> If the directional prefixes are not generally used as part of the name,
> they should probably not be in the name tag, but instead as an address tag
> (I've used addr:direction e.g. http://www.openstreetmap.org/**
> browse/way/140789671 ).


Is that even in live use on any significant level?  I'm not finding
any precedent of real consequence.
___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Talk-us Digest, Vol 51, Issue 19

[Dion Dock]

You're assuming the street signs make sense.  Do you preserve signs with 
mistakes or omissions?

In Wilsonville, OR, there are some signs for "St Moritz Loop" and "St. Moritz 
Loop".  Yes, with and without the period, and both expand to "Saint".  There 
are also plenty of signs that leave out the "Southwest" entirely, although it 
really is the correct designation for the street.  There's even "Southwest 
Villebois Drive South".

-Dion

> From: Mike N 
> 
> On 2/17/2012 3:02 AM, Alan Mintz wrote:
>> if the name has been edited by a human, it should not be updated by a
>> bot, or even another human unless they are willing to prove their edit.
>> I've edited thousands of names based on photo surveys and official
>> record research and wouldn't want that high-quality data corrupted.
> 
> For myself, I don't know how to determine what the "correct name" would 
> be ... if it doesn't match the street sign, I'd be inclined to change it 
> to agree with the sign, unless there's a 'note' tag to other mappers. 
> Similarly, an 'anti-abbreviation-bot' tag would prevent bots from 
> undoing your research.

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

Re: [Talk-us] Talk-us Digest, Vol 51, Issue 19

[Paul Johnson]

"Southwest Town Center Loop West" comes to mind as a great example of just
plain brain damaged street naming Wilsonville tends to have.

On Fri, Feb 17, 2012 at 2:55 PM, Dion Dock  wrote:

> You're assuming the street signs make sense.  Do you preserve signs with
> mistakes or omissions?
>
> In Wilsonville, OR, there are some signs for "St Moritz Loop" and "St.
> Moritz Loop".  Yes, with and without the period, and both expand to
> "Saint".  There are also plenty of signs that leave out the "Southwest"
> entirely, although it really is the correct designation for the street.
>  There's even "Southwest Villebois Drive South".
>
> -Dion
>
> > From: Mike N 
> >
> > On 2/17/2012 3:02 AM, Alan Mintz wrote:
> >> if the name has been edited by a human, it should not be updated by a
> >> bot, or even another human unless they are willing to prove their edit.
> >> I've edited thousands of names based on photo surveys and official
> >> record research and wouldn't want that high-quality data corrupted.
> >
> > For myself, I don't know how to determine what the "correct name" would
> > be ... if it doesn't match the street sign, I'd be inclined to change it
> > to agree with the sign, unless there's a 'note' tag to other mappers.
> > Similarly, an 'anti-abbreviation-bot' tag would prevent bots from
> > undoing your research.
>
> ___
> 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] name expansion bot (Re: Imports information on the wiki)

[John F. Eldredge]

Nathan Edgars II  wrote:

> On 2/17/2012 4:41 PM, TC Haddad wrote:
> > For example: in Portland all the expanded quadrant names (NE,NW, SE,
> SW)
> > really detract from the experience of using osm extracts on handheld
> > GPS. All the streets in an area of interest end up looking like they
> > have the same name because all that fits on the street segments is
> the
> > first word of the expanded quadrant label and not the "real" part of
> the
> > name. So "NE Tillamook" and "NE Hancock" both just label as
> > "Northeast"... and that is separate from the issue that people don't
> > actually write addresses here as "Northeast Tillamook".
> 
> If the directional prefixes are not generally used as part of the
> name, 
> they should probably not be in the name tag, but instead as an address
> 
> tag (I've used addr:direction e.g. 
> http://www.openstreetmap.org/browse/way/140789671).
> 

Does he mean that people don't use the prefix at all when referring to the 
street, or does he mean that people use the abbreviated form of the prefix, 
rather than the spelled-out prefix?  The statement could be interpreted either 
way.

-- 
John F. Eldredge --  j...@jfeldredge.com
"Reserve your right to think, for even to think wrongly is better than not to 
think at all." -- Hypatia of Alexandria

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

Re: [Talk-us] name expansion bot (Re: Imports information on the wiki)

[TC Haddad]

On Fri, Feb 17, 2012 at 2:42 PM, Paul Johnson  wrote:

> On Fri, Feb 17, 2012 at 1:41 PM, TC Haddad  wrote:
>
>> On Fri, Feb 17, 2012 at 12:01 PM, Paul Johnson wrote:
>>
>>  but overall, the automation saved countless hours of manual name
>>> expansion for the minor cost of having to deal with a very small number of
>>> largely regionally-isolated edge cases.
>>>
>>>
>> Can someone explain the original point of name expansion? Is it so that
>> devices that give audio directions using text-to-speech can read fluently?
>> Or was it really all about "saving time"?
>>
>> Because there are other use cases where expanded names are not desirable,
>> particularly in cartography. When map or screen real estate is minimal,
>> expanded names can be downright detrimental to utility.
>>
>>
> Sounds like a problem for the renderer to solve.  It's possible for
> renderers to easily create abbreviations when full words are not desired,
> but impossible for automated translation and renderers to expand
> abbreviations accurately.
>
>
I *guess*, but that seems unrealistic expectation to put on GPS hardware
manufacturers. Particularly if name expansion is inappropriate in one town,
but perfectly appropriate in another, and usual practice is to load a large
area (like a whole state or region) into a GPS device. How woud a device
renderer know to even try to distinguish across community lines?

>From the user perspective it would be nicer if the names in the data set
correspond to the actual street sign names. In Portland the street name is
"Tillamook" and if I am on "NE Tillamook" that just helps me know the
quadrant of town. "Northeast" on it's own doesn't tell me anything if I
can't see the rest of the street name.

This example feels more like "tag for reality", vs "tag for the renderer"
argument, and the short prefixes feel more like reality in Portland, but
maybe that's just me...

I do see the value if text-to-speech is the real reason this was done
though.
___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] name expansion bot (Re: Imports information on the wiki)

[Rich]

On 02/18/12 01:43, TC Haddad wrote:

On Fri, Feb 17, 2012 at 2:42 PM, Paul Johnson mailto:ba...@ursamundi.org>> wrote:

On Fri, Feb 17, 2012 at 1:41 PM, TC Haddad mailto:tchad...@gmail.com>> wrote:

On Fri, Feb 17, 2012 at 12:01 PM, Paul Johnson
mailto:ba...@ursamundi.org>> wrote:

  but overall, the automation saved countless hours of
manual name expansion for the minor cost of having to deal
with a very small number of largely regionally-isolated edge
cases.


Can someone explain the original point of name expansion? Is it
so that devices that give audio directions using text-to-speech
can read fluently? Or was it really all about "saving time"?

Because there are other use cases where expanded names are not
desirable, particularly in cartography. When map or screen real
estate is minimal, expanded names can be downright detrimental
to utility.


Sounds like a problem for the renderer to solve.  It's possible for
renderers to easily create abbreviations when full words are not
desired, but impossible for automated translation and renderers to
expand abbreviations accurately.


I *guess*, but that seems unrealistic expectation to put on GPS hardware
manufacturers. Particularly if name expansion is inappropriate in one
town, but perfectly appropriate in another, and usual practice is to
load a large area (like a whole state or region) into a GPS device. How
woud a device renderer know to even try to distinguish across community
lines?


it wouldn't be the device renderer (in most cases) but the the tools 
used to process the data - for example, mkgmap would do the shortening 
for garmin maps



 From the user perspective it would be nicer if the names in the data
set correspond to the actual street sign names. In Portland the street
name is "Tillamook" and if I am on "NE Tillamook" that just helps me
know the quadrant of town. "Northeast" on it's own doesn't tell me
anything if I can't see the rest of the street name.

This example feels more like "tag for reality", vs "tag for the
renderer" argument, and the short prefixes feel more like reality in
Portland, but maybe that's just me...

I do see the value if text-to-speech is the real reason this was done
though.

--
 Rich

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

Re: [Talk-us] name expansion bot (Re: Imports information on the wiki)

[Nathan Edgars II]

On 2/17/2012 5:44 PM, Paul Johnson wrote:

On Fri, Feb 17, 2012 at 2:32 PM, Nathan Edgars II mailto:nerou...@gmail.com>> wrote:

If the directional prefixes are not generally used as part of the
name, they should probably not be in the name tag, but instead as an
address tag (I've used addr:direction e.g.
http://www.openstreetmap.org/__browse/way/140789671
).


Is that even in live use on any significant level?  I'm not finding
any precedent of real consequence.


If there's something else that's used more, it should be changed. 
Otherwise leave it alone.


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

Re: [Talk-us] name expansion bot (Re: Imports information on the wiki)

[Rich]

On 02/18/12 02:28, TC Haddad wrote:


On Fri, Feb 17, 2012 at 4:10 PM, Rich mailto:ric...@nakts.net>> wrote:

it wouldn't be the device renderer (in most cases) but the the tools
used to process the data - for example, mkgmap would do the
shortening for garmin maps


Thanks - I agree that makes the most sense to me too. But (forgive my
ignorant question here) is it appropriate to create geographically
specific exceptions to the data processing rules?


in general, it's up to the data processing clients - one example might 
be http://mapq.st/wDMF7O or http://mapq.st/xzhceF



So if Portland Garmin users wanted to alter mkgmap so that the data for
the Portland metro area was processed to render as the more customary
(for here) short quadrant abbreviation labels, that would be an
acceptable proposal?


i guess it wouldn't be that much about altering mkgmap as it's 
stylesheets/whatever is the correct name :)


other proposals suggested have included additional tags that would hold 
shortened versions (multiple of them, as some entities could be 
shortened either a bit, or a lot, depending on how much space is 
available - and there is no way for automated solutions to figure out 
how to shorten some of them in a decent way)



Note I'm talking about field GPS here, and not the PND type of devices
that talk to the user. So I see that this is viewed as an edge case.

--
 Rich

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

Re: [Talk-us] name expansion bot (Re: Imports information on the wiki)

[andrzej zaborowski]

On 18 February 2012 00:43, TC Haddad  wrote:
> On Fri, Feb 17, 2012 at 2:42 PM, Paul Johnson  wrote:
>> Sounds like a problem for the renderer to solve.  It's possible for
>> renderers to easily create abbreviations when full words are not desired,
>> but impossible for automated translation and renderers to expand
>> abbreviations accurately.
>>
>
> I *guess*, but that seems unrealistic expectation to put on GPS hardware
> manufacturers. Particularly if name expansion is inappropriate in one town,
> but perfectly appropriate in another, and usual practice is to load a large
> area (like a whole state or region) into a GPS device. How woud a device
> renderer know to even try to distinguish across community lines?
>
> From the user perspective it would be nicer if the names in the data set
> correspond to the actual street sign names. In Portland the street name is
> "Tillamook" and if I am on "NE Tillamook" that just helps me know the
> quadrant of town. "Northeast" on it's own doesn't tell me anything if I
> can't see the rest of the street name.
>
> This example feels more like "tag for reality", vs "tag for the renderer"
> argument, and the short prefixes feel more like reality in Portland, but
> maybe that's just me...
>
> I do see the value if text-to-speech is the real reason this was done
> though.

I think the other benefit is the consistency.  If you decide to
abbreviate in some areas, skip prefixes in other areas, use full words
in yet other areas, the edit wars are never going to end.  I don't see
much value in following the street signs too closely because those are
a very specific use case, where, depending most likely only on someone
in highways management and the manufacturer of the signage AND
circumstances like there being only a limited space to mount the signs
at some crossings, segments of the name can be skipped, abbreviated,
reordered.  There's no requirement that the signage be consistent
along a single street.  In the end it has little to do with what
people call the street.

I also want state, for the record, that the name expansion I ran over
the western states, in general should have dealt with distinguishing
between Saints/States/Streets, single letter streets, and other
ambiguities correctly.  There were cases where it failed for various
reasons (e.g. poor metadata in TIGER) but in general it worked fine.
There were also cases in the first two states I worked on, where the
script had a bug that I fixed only after uploading the first changeset
and had to send a second correcting changeset.  The script has also
flagged a number of cases as too ambiguous and those I dealt with
manually.  Some errors surely still remain.  But all in all the
technical side of the name expansion should not be a problem.

Cheers

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

Re: [Talk-us] name expansion bot (Re: Imports information on the wiki)

[andrzej zaborowski]

On 15 January 2012 14:35, Mike N  wrote:
> On 1/15/2012 8:28 AM, Nathan Edgars II wrote:
>> Actually the script also expanded the W to West. But my point is that it
>> is a TIGER entry error, and any future script needs to take into account
>> that these exist and people may have already fixed them to the correct
>> names.
>
>  Agreed- if we're thinking of a bot that periodically fixes everything, we
> need a special tag that says "abbreviation_bot=back_off" (but perhaps not so
> verbose) - something that tells the bot not to touch the name because it is
> unusual and has been manually checked.

Running a bot periodically would be a really bad idea IMHO.  Even if
you add such a tag, the average mapper is not going to know about it.
An edit war between an unsuspecting human and a script is something
that shouldn't happen even if the mapper turns out to be wrong.

It only makes sense where there's a huge import that has simply not
considered the abbreviations.  Such an import will also affect what
first-time local mappers think is the agreed way of doing things in
OSM so imho it made sense to do a one-time name expansion over all
highways.

Cheers

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

Re: [Talk-us] name expansion bot (Re: Imports information on the wiki)

[Alan Mintz]

At 2012-02-17 13:41, TC Haddad wrote:
Can someone explain the original point of name expansion? Is it so that 
devices that give audio directions using text-to-speech can read fluently? 
Or was it really all about "saving time"?


Because there are other use cases where expanded names are not desirable, 
particularly in cartography. When map or screen real estate is minimal, 
expanded names can be downright detrimental to utility.


+1, though there is significant argument on both sides, and the 
non-abbreviators have so far managed to keep the status quo.



For example: in Portland all the expanded quadrant names (NE,NW, SE, SW) 
really detract from the experience of using osm extracts on handheld GPS.
 All the streets in an area of interest end up looking like they have the 
same name because all that fits on the street segments is the first word 
of the expanded quadrant label and not the "real" part of the name. So 
"NE Tillamook" and "NE Hancock" both just label as "Northeast"... and 
that is separate from the issue that people don't actually write 
addresses here as "Northeast Tillamook".



Theoretically, the consumers of the data (renderers, etc.) are supposed to 
do the work of re-abbreviating where necessary, but that seems to have 
gotten lost in the design of some/most of them.


--
Alan Mintz 


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

Re: [Talk-us] name expansion bot (Re: Imports information on the wiki)

[Alan Mintz]

At 2012-02-17 14:32, Nathan Edgars II wrote:

If the directional prefixes are not generally used as part of the name, 
they should probably not be in the name tag, but instead as an address tag 
(I've used addr:direction e.g. 
http://www.openstreetmap.org/browse/way/140789671).


and I've used addr:street_direction_prefix, though if I had to defend it, 
it's probably more accurately named addr:housenumber_direction_suffix .


I am a proponent of separating each part of the "street" into a separate 
field, the way it is done in most other addressing databases - separate 
fields for the number direction, street root, street type, and street 
direction suffix.


While it is abnormal, I would not be opposed to a concatenated street field 
alongside it. If the user enters that field only, the editor could split it 
up and populate the separate fields for the user to see and approve. If the 
user enters the separate fields, it could populate the concatenated field.


The bot being discussed could populate these separate fields too, since it 
needs to get some sense of which part goes where in order to correctly do 
any expansion.


--
Alan Mintz 


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