[Talk-us] MapQuest release 3 new APIs / tools - XAPI, NPI (new!), Broken Poly tool (new!)

[Antony Pegg]

Hello all,

MapQuest has pushed out three new developer tools for OSM.  Hopefully 
you will find them useful.


Full details are here on the developer blog:
http://devblog.mapquest.com/2011/04/07/xapi-npi-broken_polygons/

but to summarize:

http://open.mapquest.com/xapi
 - A running copy of Ian Dees' JXAPI plus a simple GUI based on Serge's 
UIXAPI - hopefully this will help spread the load and add one more XAPI 
instance to the pool


http://open.mapquestapi.com/npi
 - This is something new. NPI stands for Nominatim Pre-Indexed.  Its 
basically a "minutely mapnik" system for Nominatim.  We dump the 
pre-indexed Nominatim database once a month here - so if you set up your 
own nominatim version, you no longer have to wait for days or weeks 
while your computer crunches through all the indexing.  Then you can 
hookup your nominatim instance to NPI, and get the pre-indexed diffs..so 
once again you dont have the CPU load of doing the indexing, and can 
keep your nominatim instance up to date.  We believe you should now be 
able to run nominatim on a reasonably powerful home-machine or a low end 
server.


http://open.mapquestapi.com/brokenpoly
 - Nominatim has to check for broken polygons when it gets changes from 
OSM, and not ingest them. Twain has made Nominatim output the broken 
polygons to a list with messages as to what was wrong, and links to go 
fix them in the editors (JOSM & P2).  once someone fixes a poly, it 
comes back into Nominatim a few minutes later, and then it gets removed 
from the list.  Hopefully this will help people pinpoint erroneous polys 
and fix them quickly!


Feedback always appreciated, by email or on our forums. Hope these tools 
are useful!


Cheers
Ant (the limey)



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

[Talk-us] MapQuest release 3 new APIs / tools - XAPI (JXAPI), NPI (new!), Broken Poly tool (new!)

[Antony Pegg]

Hello all,

MapQuest has pushed out three new developer tools for OSM.  Hopefully 
you will find them useful.


Full details are here on the developer blog:
http://devblog.mapquest.com/2011/04/07/xapi-npi-broken_polygons/

but to summarize:

http://open.mapquest.com/xapi
 - A running copy of Ian Dees' JXAPI plus a simple GUI based on Serge's 
UIXAPI - hopefully this will help spread the load and add one more XAPI 
instance to the pool


http://open.mapquestapi.com/npi
 - This is something new. NPI stands for Nominatim Pre-Indexed.  Its 
basically a "minutely mapnik" system for Nominatim.  We dump the 
pre-indexed Nominatim database once a month here - so if you set up your 
own nominatim version, you no longer have to wait for days or weeks 
while your computer crunches through all the indexing.  Then you can 
hookup your nominatim instance to NPI, and get the pre-indexed diffs..so 
once again you dont have the CPU load of doing the indexing, and can 
keep your nominatim instance up to date.  We believe you should now be 
able to run nominatim on a reasonably powerful home-machine or a low end 
server.


http://open.mapquestapi.com/brokenpoly
 - Nominatim has to check for broken polygons when it gets changes from 
OSM, and not ingest them. Twain has made Nominatim output the broken 
polygons to a list with messages as to what was wrong, and links to go 
fix them in the editors (JOSM & P2).  once someone fixes a poly, it 
comes back into Nominatim a few minutes later, and then it gets removed 
from the list.  Hopefully this will help people pinpoint erroneous polys 
and fix them quickly!


Feedback always appreciated, by email or on our forums. Hope these tools 
are useful!


Cheers
Ant (the limey)

--
Aut viam invenium aut facium


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

Re: [Talk-us] US Interstate exit junction exit_to tag

[Alan Mintz]

At 2011-04-07 13:31, Nathan Edgars II wrote:

On 4/7/2011 4:09 PM, Alan Mintz wrote:

"Exit 183 / SR-247 South / Barstow Road"
is tagged
ref="183" +
exit_to="CA-247;Barstow Road" +
exit_dir="South;"

Does anyone have examples of places where my suggested model does not work?


It's not backwards-compatible with anything that uses exit_to. To get the 
text of the sign you have to piece together the exit_to and exit_to_dir fields.


It's the way it was done with the street name split a while back, though I 
acknowledge that it isn't an identical situation, since we ultimately 
decided the direction was not part of the street name. In this case, the 
direction is an important part.


I would not be averse to something like:

exit_to="CA-247 South"

OR

exit_to_root="CA-247"
exit_to_dir="South"

Consumers that have evolved can use the second form if it is found, or the 
first if it is not. Older consumers can use the first form. Users that 
choose not to use the second form can use the first form and it will work 
with both old and new consumers.


--
Alan Mintz 


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

Re: [Talk-us] US Interstate exit junction exit_to tag

[Nathan Edgars II]

On 4/8/2011 12:47 PM, Alan Mintz wrote:

At 2011-04-07 13:31, Nathan Edgars II wrote:

On 4/7/2011 4:09 PM, Alan Mintz wrote:

"Exit 183 / SR-247 South / Barstow Road"
is tagged
ref="183" +
exit_to="CA-247;Barstow Road" +
exit_dir="South;"

Does anyone have examples of places where my suggested model does not
work?


It's not backwards-compatible with anything that uses exit_to. To get
the text of the sign you have to piece together the exit_to and
exit_to_dir fields.


It's the way it was done with the street name split a while back, though
I acknowledge that it isn't an identical situation, since we ultimately
decided the direction was not part of the street name. In this case, the
direction is an important part.


It's not even close to identical. It's very rare to have two parallel 
streets with the same name except for a different directional prefix 
(and in those cases the directional prefix should be part of the name). 
On the other hand, it's very common to have two consecutive exits for 
each direction of a road.


The question is still what benefit there would be to splitting it.

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

Re: [Talk-us] US Interstate exit junction exit_to tag

[Alan Mintz]

At 2011-04-07 13:47, Mike N wrote:

On 4/7/2011 4:09 PM, Alan Mintz wrote:


Case 2. Very occasionally, there will be more than one street name
shown, usually when the ramp ends at or near a point where a street
changes name. Use semicolons to place multiple values in the exit_to and
exit_to_dir tags. e.g.:

"Exit 73 / Diamond Drive / Railroad Canyon Road"
is tagged
ref="73" +
exit_to="Diamond Drive;Railroad Canyon Road"

"Exit 183 / SR-247 South / Barstow Road"
is tagged
ref="183" +
exit_to="CA-247;Barstow Road" +
exit_dir="South;"


  Does exit direction refer to the compass direction of the intersecting 
road, or the signed direction, and if so which road in the list?


Compass direction of the road, usually for intersections with primary or 
higher category roads where there are multiple ramps to reduce 
intersections (e.g. cloverleafs).




  Sign:  I77 North; US 44 East; NC 56 East; Charlotte; Rock Hill; York


Assuming that Charlotte, Rock Hill, and York were aligned with I77, US44, 
and NC56, respectively on the sign:


exit_to="I-77 North;US-44 East;NC-56 East"
towards="Charlotte;Rock Hill;York"

OR

exit_to_root="I-77;US-44;NC-56"
exit_to_dir="North;East;East"
towards="Charlotte;Rock Hill;York"

(See note [0])



  So someone has to parse the sign to be able to properly enter the 
information?   And I'm still not clear on the benefit of having it 
separated if the first thing the data consumer does is string it back together.


Not all consumers are for the purpose of navigation or map rendering. It 
might be useful, for example, to be able to query


select * from  where exit_to_root="Rosemead Blvd"

to get both ramps from CA-60 to Rosemead Blvd, instead of having to use 
'exit_to like "Rosemead Blvd%"'.




[0]: You may have been alluding to some ambiguities in the way ; can be 
interpreted. Here's what I've done when the number of values in one tag is 
not the same as the number of values in another related tag. I'm hoping 
that consumers follow suit:


- Each value consists of fields that are separated by semicolons.
- Empty fields in the beginning or middle of the value are indicated by 
just the separator (semicolon). This also means that you use a trailing ';' 
to indicate that the last field in a value is empty.
- If valueA and valueB are related, you parse them from left to right to 
get the correct A/B pairs. If you run out of fields in one before the 
other, the last value is repeated for the one that is short - otherwise the 
user should have just used empty fields to indicate there were no values 
there. e.g.:


A-B pairs 1-2, 3-4, 5-, 7-8, 9-10, 11-10, and 12-10 would be 
encoded as:


A=1;3;5;7;9;11;12
B=2;4;;8;10

If you add another pair 13-14 to the end, you would have to encode it:

A=1;3;5;7;9;11;12;13
B=2;4;;8;10;10;10;14

Yes, this can be complicated. If the user chooses not to use the unequal 
count feature, just ensure you put the same number of fields in each value, 
repeating or using an empty field as necessary.


--
Alan Mintz 


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

Re: [Talk-us] US Interstate exit junction exit_to tag

[Nathan Edgars II]

On 4/8/2011 1:16 PM, Alan Mintz wrote:

Not all consumers are for the purpose of navigation or map rendering. It
might be useful, for example, to be able to query

select * from  where exit_to_root="Rosemead Blvd"

to get both ramps from CA-60 to Rosemead Blvd, instead of having to use
'exit_to like "Rosemead Blvd%"'.


You'd still have to do the latter to find exits that are signed as 
leading to Rosemead Boulevard and another road (and of course neither 
would find cases where mappers correctly expanded Blvd to Boulevard).


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

Re: [Talk-us] US Interstate exit junction exit_to tag

[Alan Mintz]

At 2011-04-08 09:55, Nathan Edgars II wrote:

On 4/8/2011 12:47 PM, Alan Mintz wrote:

At 2011-04-07 13:31, Nathan Edgars II wrote:

On 4/7/2011 4:09 PM, Alan Mintz wrote:

"Exit 183 / SR-247 South / Barstow Road"
is tagged
ref="183" +
exit_to="CA-247;Barstow Road" +
exit_dir="South;"

Does anyone have examples of places where my suggested model does not
work?


It's not backwards-compatible with anything that uses exit_to. To get
the text of the sign you have to piece together the exit_to and
exit_to_dir fields.


It's the way it was done with the street name split a while back, though
I acknowledge that it isn't an identical situation, since we ultimately
decided the direction was not part of the street name. In this case, the
direction is an important part.


It's not even close to identical.


Ack'd, as I wrote.


 It's very rare to have two parallel streets with the same name except 
for a different directional prefix (and in those cases the directional 
prefix should be part of the name).


Agreed, though I can think of two immediately, one of which is just a 
couple miles from me (North and South Mainstreet), and the other in LA 
(East and West Vermont St. running N/S). In the direction prefix 
discussion, all agreed that the directions in these _are_ part of the name, 
and should/would not be separated out. They should not be separated in this 
case either.



 On the other hand, it's very common to have two consecutive exits for 
each direction of a road.

The question is still what benefit there would be to splitting it.


I gave an admittedly weak example in my last response to Mike N. My point 
is still that there does not necessarily have to be an existing use case to 
support modeling the data in this way. It's part of an experienced DBA's 
skillset to be able to guess at what might be needed in the future when 
modeling data today to reduce rework in the future. In the OSM environment, 
where there is no formal schema, versioning, practices to sync consumers 
and providers on the same spec, etc., it's particularly heinous to have to 
re-work things later.



--
Alan Mintz 


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

[Talk-us] REF tags for State Highways on ways

[James Mast]

I just thought I would throw this out there so this can be settled once and for 
all.  Which ref tag setup do you think should be used for State Highways on 
ways (not relations)? "PA-44" or "44".  The reason I'm asking is because I've 
seen several people put the state abbreviation in the ref field and some people 
don't.  Heck, I'm guilty of doing it both ways myself.  In some states you see 
it both ways (NY;KY), some states you see just the number (FL), and some states 
have the state abbreviation + number (CA).

So, we really need to all come to an agreement on which way we should use in 
all the states.  Because it doesn't look good having two different ways to do 
it and it should be standardized.  ___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] REF tags for State Highways on ways

[Nathan Edgars II]

On 4/8/2011 2:00 PM, James Mast wrote:

I just thought I would throw this out there so this can be settled once
and for all. Which ref tag setup do you think should be used for State
Highways on ways (not relations)? "PA-44" or "44".
There's a third way: use the correct abbreviation. So Florida, if a 
prefix is used, would have SR, not FL. Pennsylvania, on the other hand, 
would use PA.


> The reason I'm asking

is because I've seen several people put the state abbreviation in the
ref field and some people don't. Heck, I'm guilty of doing it both ways
myself. In some states you see it both ways (NY;KY), some states you see
just the number (FL), and some states have the state abbreviation +
number (CA).

So, we really need to all come to an agreement on which way we should
use in all the states.

Good luck. I tried a year ago.

> Because it doesn't look good having two different

ways to do it and it should be standardized.


It looks fine on Mapquest, which removes the prefix. (This however 
causes issues with county routes, forest routes, and other such systems.)


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

Re: [Talk-us] MapQuest release 3 new APIs / tools - XAPI (JXAPI), NPI (new!), Broken Poly tool (new!)

[Mike N]

On 4/8/2011 11:58 AM, Antony Pegg wrote:

Hello all,

MapQuest has pushed out three new developer tools for OSM. Hopefully you
will find them useful.


   Yes!   Thanks for the new tools - some interesting stuff there.

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

Re: [Talk-us] REF tags for State Highways on ways

[Nathan Mills]

On Fri, 08 Apr 2011 14:11:49 -0400, Nathan Edgars II wrote:

On 4/8/2011 2:00 PM, James Mast wrote:
I just thought I would throw this out there so this can be settled 
once
and for all. Which ref tag setup do you think should be used for 
State

Highways on ways (not relations)? "PA-44" or "44".

There's a third way: use the correct abbreviation. So Florida, if a
prefix is used, would have SR, not FL. Pennsylvania, on the other
hand, would use PA.


IMO, the state's postal abbreviation followed by the route number 
should be used. This makes them easily distinguished from US or other 
route refs. You can't always go by the state the road is in. For 
example, in NE Oklahoma and NW Arkansas, AR-42 and OK-20 are cosigned 
along a way that runs along the border and is part of both state's 
highway network. In fact, some of the road is completely in Oklahoma yet 
is still cosigned AR-42.


I think ref=OK 20;AR 42 (or equally ref=AR 42;OK 20) is the appropriate 
tag there.


The "SR" naming leads to ambiguity as to which state's route number is 
being referenced.


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

Re: [Talk-us] REF tags for State Highways on ways

[Kristian M Zoerhoff]

On Fri, Apr 08, 2011 at 02:03:25PM -0500, Nathan Mills wrote:
> On Fri, 08 Apr 2011 14:11:49 -0400, Nathan Edgars II wrote:
> >On 4/8/2011 2:00 PM, James Mast wrote:
> >>I just thought I would throw this out there so this can be
> >>settled once
> >>and for all. Which ref tag setup do you think should be used for
> >>State
> >>Highways on ways (not relations)? "PA-44" or "44".
> >There's a third way: use the correct abbreviation. So Florida, if a
> >prefix is used, would have SR, not FL. Pennsylvania, on the other
> >hand, would use PA.
> 
> IMO, the state's postal abbreviation followed by the route number
> should be used. This makes them easily distinguished from US or

But this is not always correct. In Michigan, for example, all state highways 
are named M-nn, with M- being part of the road's actual name in many places. 
It is never, ever, written MI-nn.

States like Wisconsin get tricky, too. "Wis nn" is common, but so is the 
much older "STH nn" (for State Trunk Highway). 

-- 

Kristian Zoerhoff
kristian.zoerh...@gmail.com

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

Re: [Talk-us] REF tags for State Highways on ways

[Nathan Edgars II]

On 4/8/2011 3:03 PM, Nathan Mills wrote:

The "SR" naming leads to ambiguity as to which state's route number is
being referenced.

Just like name=Main Street leads to ambiguity as to which city's main 
street it is.


I understand the overlap between 20 and 42, but here the solution is to 
make sure the relations for both are correct.


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

Re: [Talk-us] REF tags for State Highways on ways

[Nathan Mills]

On Fri, 8 Apr 2011 14:11:57 -0500, Kristian M Zoerhoff wrote:


IMO, the state's postal abbreviation followed by the route number
should be used. This makes them easily distinguished from US or


But this is not always correct. In Michigan, for example, all state 
highways
are named M-nn, with M- being part of the road's actual name in many 
places.

It is never, ever, written MI-nn.


Shouldn't the ref tag be an unambiguous reference to a given road in a 
route network? Clearly, one should not put name=MI XX on a Michigan 
state route (unless there is a road sign reading "MI XX"), but ref=MI XX 
provides said unambiguous reference and can be easily translated into 
the canonical name of the route. A name should go in the name tag, 
anyway. Sometimes the name and ref are identical, sometimes they're not.


Seems to me that the ref tag is much less useful when it's ambiguous.

Yes, we all ought to be using relations, but there's a lot of state 
routes that don't yet have relations.


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

Re: [Talk-us] REF tags for State Highways on ways

[Nathan Edgars II]

On 4/8/2011 3:35 PM, Nathan Mills wrote:

Shouldn't the ref tag be an unambiguous reference to a given road in a
route network? Clearly, one should not put name=MI XX on a Michigan
state route (unless there is a road sign reading "MI XX"), but ref=MI XX
provides said unambiguous reference and can be easily translated into
the canonical name of the route. A name should go in the name tag,
anyway. Sometimes the name and ref are identical, sometimes they're not.

Seems to me that the ref tag is much less useful when it's ambiguous.


The UK has two M1 motorways, one heading north from London and the other 
in Northern Ireland. Both are tagged ref=M1.


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

Re: [Talk-us] REF tags for State Highways on ways

[Richard Welty]

On 4/8/11 3:35 PM, Nathan Mills wrote:


Shouldn't the ref tag be an unambiguous reference to a given road in a 
route network? Clearly, one should not put name=MI XX on a Michigan 
state route (unless there is a road sign reading "MI XX"), but ref=MI 
XX provides said unambiguous reference and can be easily translated 
into the canonical name of the route. A name should go in the name 
tag, anyway. Sometimes the name and ref are identical, sometimes 
they're not.


Seems to me that the ref tag is much less useful when it's ambiguous.

Yes, we all ought to be using relations, but there's a lot of state 
routes that don't yet have relations.
the ref tags on the ways, in their current form, get used directly by 
the rendering systems.
i wish that this weren't true, but it is, and we have to deal with that 
reality. we shouldn't
do off doing anything radical without a migration plan for the data 
consumers that makes

sense.

most of the state highway pages for individual states in the wiki 
specify a pattern for the
particular state, and many (most?) of these specify the postal code 
approach, or at least,
they did the last time i looked. this approach dpes permit a state that 
has its own
convention about what goes on the sign (like michigan) to set a 
different standard for

the state.

i know NE2 likes to make the prefix go away for state ref tags, but i 
have never agreed
with this practice. in particular, it's not great on the garmin displays 
from

maps made with mkgmap.

richard


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

Re: [Talk-us] REF tags for State Highways on ways

[Nathan Edgars II]

On 4/8/2011 3:58 PM, Richard Welty wrote:

i know NE2 likes to make the prefix go away for state ref tags


For Florida, yes, since that's the statewide standard. For other states, 
I usually don't tag without a prefix. I certainly don't "make it go 
away" en masse.


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

Re: [Talk-us] REF tags for State Highways on ways

[Richard Welty]

On 4/8/11 4:02 PM, Nathan Edgars II wrote:

On 4/8/2011 3:58 PM, Richard Welty wrote:

i know NE2 likes to make the prefix go away for state ref tags


For Florida, yes, since that's the statewide standard. For other 
states, I usually don't tag without a prefix. I certainly don't "make 
it go away" en masse.

no, you don't make it go away en masse, but you have deleted the prefixes
somewhat randomly in NY.

richard


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

Re: [Talk-us] REF tags for State Highways on ways

[Nathan Edgars II]

On 4/8/2011 4:18 PM, Richard Welty wrote:

On 4/8/11 4:02 PM, Nathan Edgars II wrote:

On 4/8/2011 3:58 PM, Richard Welty wrote:

i know NE2 likes to make the prefix go away for state ref tags


For Florida, yes, since that's the statewide standard. For other
states, I usually don't tag without a prefix. I certainly don't "make
it go away" en masse.

no, you don't make it go away en masse, but you have deleted the prefixes
somewhat randomly in NY.


Do you have an example of that outside my first few months of editing?

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

Re: [Talk-us] US Interstate exit junction exit_to tag

[Alan Mintz]

At 2011-04-07 22:57, James Mast wrote:
You know guys, we should also
figure out right here and now how to deal with "left" exits at
Interstate splits where both ways are "motorways". Here's such
an example:
http://www.openstreetmap.org/?lat=36.49591&lon=-80.74103&zoom=16&layers=M
It's the I-77/I-74 split in NC. I-74 splits off to the left using an I-77
exit number (Exit #101). Something like this would need an extra tag on
the node where the highways split.
Looks mostly right as is, except I capitalize East (and want it in its
own tag), hyphenate I-74 (because it is in a name field, not a ref), and
would move the destinations to the towards tag:
exit_to="I-74 East"
towards="Mount Airy / Winston Salem"
ref=101
OR
exit_to_root="I-74"
exit_to_dir="East"
towards="Mount Airy / Winston Salem"
ref=101
Because it is the start of the motorway, I see no reason to call it a
motorway_link. I just continue the new motorway right up to the
motorway_junction.

--
Alan Mintz 



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

Re: [Talk-us] REF tags for State Highways on ways

[Richard Welty]

On 4/8/11 4:26 PM, Nathan Edgars II wrote:

On 4/8/2011 4:18 PM, Richard Welty wrote:

On 4/8/11 4:02 PM, Nathan Edgars II wrote:

On 4/8/2011 3:58 PM, Richard Welty wrote:

i know NE2 likes to make the prefix go away for state ref tags


For Florida, yes, since that's the statewide standard. For other
states, I usually don't tag without a prefix. I certainly don't "make
it go away" en masse.
no, you don't make it go away en masse, but you have deleted the 
prefixes

somewhat randomly in NY.


Do you have an example of that outside my first few months of editing?

this changeset:

http://www.openstreetmap.org/browse/changeset/5223229

from 7/2010, in which the ref tag for

http://www.openstreetmap.org/browse/way/48124268

was changed to 9H;23 is an example. the others i've looked at are also
from that period. maybe that was in your first few months, but i thought
you'd been mapping longer than that.

richard


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

Re: [Talk-us] REF tags for State Highways on ways

[Nathan Edgars II]

On 4/8/2011 4:46 PM, Richard Welty wrote:

On 4/8/11 4:26 PM, Nathan Edgars II wrote:

Do you have an example of that outside my first few months of editing?

this changeset:

http://www.openstreetmap.org/browse/changeset/5223229

from 7/2010, in which the ref tag for

http://www.openstreetmap.org/browse/way/48124268

was changed to 9H;23 is an example. the others i've looked at are also
from that period. maybe that was in your first few months, but i thought
you'd been mapping longer than that.


Oh yes, I have changed from the horrible "US:[state] [number]" format. 
There's no reason to put the country name in the ref tag.


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

Re: [Talk-us] REF tags for State Highways on ways

[Richard Welty]

On 4/8/11 4:50 PM, Nathan Edgars II wrote:

On 4/8/2011 4:46 PM, Richard Welty wrote:

On 4/8/11 4:26 PM, Nathan Edgars II wrote:

Do you have an example of that outside my first few months of editing?

this changeset:

http://www.openstreetmap.org/browse/changeset/5223229

from 7/2010, in which the ref tag for

http://www.openstreetmap.org/browse/way/48124268

was changed to 9H;23 is an example. the others i've looked at are also
from that period. maybe that was in your first few months, but i thought
you'd been mapping longer than that.


Oh yes, I have changed from the horrible "US:[state] [number]" format. 
There's no reason to put the country name in the ref tag.

well, yes, i change those when i notice them, but within NY, you ought
to be changing them to NY xx, not xx.

richard


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

Re: [Talk-us] US Interstate exit junction exit_to tag

[Mike N]

On 4/8/2011 1:16 PM, Alan Mintz wrote:

So someone has to parse the sign to be able to properly enter the
information? And I'm still not clear on the benefit of having it
separated if the first thing the data consumer does is string it back
together.


Not all consumers are for the purpose of navigation or map rendering. It
might be useful, for example, to be able to query

select * from  where exit_to_root="Rosemead Blvd"

to get both ramps from CA-60 to Rosemead Blvd, instead of having to use
'exit_to like "Rosemead Blvd%"'.


  As Nathan has noted, you still need a fuzzy search to find Blvd or 
Boulevard.  Also spelling mismatch searches are useful to find 'Rosmead' 
/ 'Rosemede' as either the search term or the typo'd OSM entry.   This 
is something that computers are good at.   Mapper resources should be 
reserved for surveying and geo creation, not pre-parsing queries. 
While I agree that we need to make sure that whatever we come up with is 
not awkward to use, exit_to doesn't qualify as awkward.  There are only 
52,000-some motorway_junctions tagged in the world, and I'm pretty sure 
that 70% of the US motorway junctions have been entered.   That number 
of entries is easy to handle even if you have to perform a search-query 
on all.


>I would not be averse to something like:
>
>exit_to="CA-247 South"
>
>OR
>
>exit_to_root="CA-247"
>exit_to_dir="South"
>
>Consumers that have evolved can use the second form if it is found, or 
>the first if it is not. Older consumers can use the first form. Users 
>that choose not to use the second form can use the first form and it 
>will work with both old and new consumers.


   The point of the most recent change was standardization - consumers 
should not need to code 2 routines to handle both forms.  Our tagging 
guides should be as simple as possible.   There is already a good 1 page 
on motorway_junction.   If a non-programmer were to try to enter their 
information and saw a full second page just to cover parsing rules, they 
would simply abandon their efforts as too complicated.  (That already 
happens too often today with the existing OSM guidelines)


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

Re: [Talk-us] US Interstate exit junction exit_to tag

[Alan Mintz]

At 2011-03-28 12:19, Ian Dees wrote:
In this picture:
http://www.nomadchallenge.com/wp-content/uploads/2008/08/likelike-highway-honolulu.jpg
What is the proposed tag for the highway=motorway_junction node?
Are we tagging the node with exactly what is on the sign or are we
looking down the road and coming up with text on our
own?
Because Likelike Hwy. is the name of HI-63, I would like to 
tag:
ref="20A"
exit_to_root="Likelike Highway (HI-63)"
exit_to_dir="North"

--
Alan Mintz 



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

Re: [Talk-us] US Interstate exit junction exit_to tag

[Alan Mintz]

At 2011-04-08 14:06, Mike N wrote:

On 4/8/2011 1:16 PM, Alan Mintz wrote:

>I would not be averse to something like:
>
>exit_to="CA-247 South"
>
>OR
>
>exit_to_root="CA-247"
>exit_to_dir="South"
>
>Consumers that have evolved can use the second form if it is found, 
or >the first if it is not. Older consumers can use the first form. 
Users >that choose not to use the second form can use the first form and 
it >will work with both old and new consumers.


   The point of the most recent change was standardization - consumers 
should not need to code 2 routines to handle both forms.


One "if" does not two routines make.



  Our tagging guides should be as simple as possible.


Agreed. Like turn restriction relations. And destination sign 
relations. And traffic camera relations.



   There is already a good 1 page on motorway_junction.   If a 
non-programmer were to try to enter their information and saw a full 
second page just to cover parsing rules, they would simply abandon their 
efforts as too complicated.


If that were the case, I'd agree that a better solution should be found. Is 
it a full page? Not even close. Perhaps you were referring to my departure 
from the thread regarding semicolons, which is not at all specific to this 
group of tags?




  (That already happens too often today with the existing OSM guidelines)


That is hardly the only reason.

--
Alan Mintz 


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

Re: [Talk-us] US Interstate exit junction exit_to tag

[Nathan Edgars II]

On 4/8/2011 6:22 PM, Alan Mintz wrote:

At 2011-03-28 12:19, Ian Dees wrote:

In this picture:
http://www.nomadchallenge.com/wp-content/uploads/2008/08/likelike-highway-honolulu.jpg

What is the proposed tag for the highway=motorway_junction node?
Are we tagging the node with exactly what is on the sign or are we
looking down the road and coming up with text on our own?



Because Likelike Hwy. is the name of HI-63, I would like to tag:

ref="20A"
exit_to_root="Likelike Highway (HI-63)"
exit_to_dir="North"


Better to actually put what's on the sign: exit_to=HI 63 north; Likelike 
Highway, since a router would then say "take the exit to [whatever, 
should be Route] 63 north, Likelike Highway".


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

Re: [Talk-us] US Interstate exit junction exit_to tag

[Alan Mintz]

At 2011-04-08 15:34, Nathan Edgars II wrote:

On 4/8/2011 6:22 PM, Alan Mintz wrote:

At 2011-03-28 12:19, Ian Dees wrote:

In this picture:
http://www.nomadchallenge.com/wp-content/uploads/2008/08/likelike-highway-honolulu.jpg

What is the proposed tag for the highway=motorway_junction node?
Are we tagging the node with exactly what is on the sign or are we
looking down the road and coming up with text on our own?



Because Likelike Hwy. is the name of HI-63, I would like to tag:

ref="20A"
exit_to_root="Likelike Highway (HI-63)"
exit_to_dir="North"


Better to actually put what's on the sign: exit_to=HI 63 north; Likelike 
Highway, since a router would then say "take the exit to [whatever, should 
be Route] 63 north, Likelike Highway".


I disagree. They are not two different values, which is what the semicolon 
is supposed to do when encountered in a value. What's wrong with speaking 
"Likelike Highway  HI-63  North"?


This conversation could really use some input from other mappers and data 
consumers. Hasn't anyone noticed that the names of many exits on some 
freeways disappeared from the map?


--
Alan Mintz 


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

Re: [Talk-us] US Interstate exit junction exit_to tag

[Mike N]

On 4/8/2011 6:34 PM, Alan Mintz wrote:

The point of the most recent change was standardization - consumers
should not need to code 2 routines to handle both forms.


One "if" does not two routines make.


  Recent software uses test cases to ensure that quality levels are 
maintained through the life of the software.  Although consumption can 
be placed in an if, there are 2 cases to extract from the specification 
and 2 cases to test for.The benefit is negligible.



  Our tagging guides should be as simple as possible.


Agreed. Like turn restriction relations. And destination sign
relations. And traffic camera relations.


  I'll agree that those are overly complicated, but that doesn't mean 
that all future tagging schemes need to be of maximal complexity.



   There is already a good 1 page on motorway_junction.   If a
non-programmer were to try to enter their information and saw a full
second page just to cover parsing rules, they would simply abandon
their efforts as too complicated.


If that were the case, I'd agree that a better solution should be found.
Is it a full page? Not even close. Perhaps you were referring to my
departure from the thread regarding semicolons, which is not at all
specific to this group of tags?


  All common cases would need examples, otherwise you have inconsistent 
tagging,  not conforming to any rules,  which is a fate worse than no 
information - bits taking up space but having no meaning or wrong meaning.


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

Re: [Talk-us] update to MQ critical address file for US, CA and GB (4Apr2011)

[Alan Mintz]

Just a reminder - please don't blindly import these - they have been shown 
to be of limited accuracy.


Example from the current file:

18175 Chatsworth Avenue,US,CA,Granada Hills,91344,34.263971,-118.528055
a. It's actually Chatsworth Street, not Avenue, according to LA 
County assessor's map 2715-012, Parcel Map 161-009, and USPS
b. The location given is, at best, over 250 ft from the driveway 
of, and on the other side of the street from, the actual location of this 
self-storage business.


Also, note that many points have 3 entries, each with varying amounts of 
abbreviation.


--
Alan Mintz 


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

Re: [Talk-us] REF tags for State Highways on ways

[Toby Murray]

Yeah... consensus would be great but seems to be rather elusive.

Here is a case in point. Another mapper has been tagging ways on
Kansas highways as "K-xx" which is how people usually pronounce it.
Street signs usually just have the number inside of the sunflower logo
without any kind of lettering like this:

http://farm4.static.flickr.com/3412/3667822945_b4606af872.jpg

I have been tagging them as "KS xx" which on Mapquest gets rendered as
just the number. The "K-xx" ways don't get the K stripped off though
so it is inconsistent. You can see both versions here:

http://open.mapquest.com/link/4-OcIUELMD

Highway 14 was tagged by me and 171 was done by the other mapper.

I personally prefer "KS xx" and if this were applied consistently,
data consumers could count on that format and strip things off,
replace them with "SR" or whatever they want to do.

Toby

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

[Talk-us] Peculiar addressing in Burr Ridge, IL

[Alan Mintz]

In Burr Ridge, IL: 
http://www.openstreetmap.org/?lat=41.7504&lon=-87.92916&zoom=16&layers=M


I-55 runs approximately E/W and there are frontage roads on either side of 
it, apparently named North Frontage Road and South Frontage Road.


Along them, there are businesses with addresses like "16W561 South Frontage 
Rd" and "601 South Frontage Road" (on the next block). If you feed the 
16W561 address to http://zip4.usps.com/zip4/welcome.jsp, it confirms it is 
deliverable*. If you leave off the 16W prefix, it gives the same error that 
it gives for addresses where it does not know of that particular address, 
but it does fall within an acceptable range for that street.


Perhaps conversely, it accepts "601 South Frontage Road" as deliverable, 
but if you give it 16W601... instead, it converts it to 601 and confirms it 
is deliverable. This conversion is normally seen where there are naming 
discrepancies for a street (like St. vs. Ave., or during the transition 
time of an old name to a new name).


Any clue what these inconsistent 16W prefixes are? It's not a PLSS 
designation because the area is around T38N/R11E.



*"deliverable" means it does not give an error, which, in my experience, 
means it is a valid address point in their database.




--
Alan Mintz 


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

Re: [Talk-us] Peculiar addressing in Burr Ridge, IL

[Nathan Edgars II]

On 4/8/2011 8:47 PM, Alan Mintz wrote:

Any clue what these inconsistent 16W prefixes are? It's not a PLSS
designation because the area is around T38N/R11E.


http://www.burr-ridge.gov/E-Services/GIS/GIS.html shows that they don't 
appear only on the frontage roads, but are all over the area. Random 
guess: could they be from an old rural free delivery route?


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

Re: [Talk-us] Peculiar addressing in Burr Ridge, IL

[Kristian Zoerhoff]

Ah, rural Chicago addresses.

Kane and DuPage counties use an arcane system based on the number of miles
you are from State & Madison in Chicago. In this case, you in the 16th mile
west of State. Within a given mile, addresses increase from 000 to 999,
inclusive.

What's truly maddening is that this is only for unincorporated areas, and a
few incorporated municipalities that never created their own grids, so wild
jumps like you describe usually involve a village/city limit.

I happen to live in Kane County, so I'm used to this weirdness by now.

--
Kristian M Zoerhoff
On Apr 8, 2011 7:48 PM, "Alan Mintz"  wrote:
> In Burr Ridge, IL:
> http://www.openstreetmap.org/?lat=41.7504&lon=-87.92916&zoom=16&layers=M
>
> I-55 runs approximately E/W and there are frontage roads on either side of

> it, apparently named North Frontage Road and South Frontage Road.
>
> Along them, there are businesses with addresses like "16W561 South
Frontage
> Rd" and "601 South Frontage Road" (on the next block). If you feed the
> 16W561 address to http://zip4.usps.com/zip4/welcome.jsp, it confirms it is

> deliverable*. If you leave off the 16W prefix, it gives the same error
that
> it gives for addresses where it does not know of that particular address,
> but it does fall within an acceptable range for that street.
>
> Perhaps conversely, it accepts "601 South Frontage Road" as deliverable,
> but if you give it 16W601... instead, it converts it to 601 and confirms
it
> is deliverable. This conversion is normally seen where there are naming
> discrepancies for a street (like St. vs. Ave., or during the transition
> time of an old name to a new name).
>
> Any clue what these inconsistent 16W prefixes are? It's not a PLSS
> designation because the area is around T38N/R11E.
>
>
> *"deliverable" means it does not give an error, which, in my experience,
> means it is a valid address point in their database.
>
>
>
> --
> Alan Mintz 
>
>
> ___
> 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] MapQuest release 3 new APIs / tools - XAPI, NPI (new!), Broken Poly tool (new!)

[Michal Migurski]

On Apr 8, 2011, at 8:43 AM, Antony Pegg wrote:

> http://open.mapquest.com/xapi
> - A running copy of Ian Dees' JXAPI plus a simple GUI based on Serge's UIXAPI 
> - hopefully this will help spread the load and add one more XAPI instance to 
> the pool


Greatest thing ever, just as I was getting discouraged when seeing this:

http://lists.openstreetmap.org/pipermail/tilesathome/2011-February/006596.html

Keep it up!

-mike.


michal migurski- m...@stamen.com
 415.558.1610




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

Re: [Talk-us] US Interstate exit junction exit_to tag

[James Mast]

Well, I was just testing MapQuest and it thinks that I-74's split there from 
I-77 is the main highway (somewhat).
http://open.mapquest.com/?le=t&hk=7-OEgrKIB6&vs=
It says "Stay STRAIGHT to go onto I-74 E."  The problem is it's a "Left" exit.
The line should say something like: "Take Left Exit #101 to continue on I-74 
East towards Mt Airy/Winston-Salem."  This is what Google says on their map: 
"Slight left at I-74 E (signs for Mt Airy/Winston - Salem)".  Heck, I've been 
fighting with Google trying to get them to mention the Exit number for that 
step as well, but haven't had much luck.
This is what we need to work with MapQuest to fix.  Maybe a special 
"exit_left=yes" or "left_exit=yes" tag?
 


Date: Fri, 8 Apr 2011 13:42:16 -0700
To: talk-us@openstreetmap.org
From: alan_mintz+...@earthlink.net
Subject: Re: [Talk-us] US Interstate exit junction exit_to tag

At 2011-04-07 22:57, James Mast wrote:

You know guys, we should also figure out right here and now how to deal with 
"left" exits at Interstate splits where both ways are "motorways". Here's such 
an example:
http://www.openstreetmap.org/?lat=36.49591&lon=-80.74103&zoom=16&layers=M
It's the I-77/I-74 split in NC. I-74 splits off to the left using an I-77 exit 
number (Exit #101). Something like this would need an extra tag on the node 
where the highways split.
Looks mostly right as is, except I capitalize East (and want it in its own 
tag), hyphenate I-74 (because it is in a name field, not a ref), and would move 
the destinations to the towards tag:

exit_to="I-74 East"
towards="Mount Airy / Winston Salem"
ref=101

OR

exit_to_root="I-74"
exit_to_dir="East"
towards="Mount Airy / Winston Salem"
ref=101

Because it is the start of the motorway, I see no reason to call it a 
motorway_link. I just continue the new motorway right up to the 
motorway_junction.

--
Alan Mintz 

___ 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] US Interstate exit junction exit_to tag

[Nathan Edgars II]

On 4/8/2011 10:31 PM, James Mast wrote:

Well, I was just testing MapQuest and it thinks that I-74's split there
from I-77 is the main highway (somewhat).
http://open.mapquest.com/?le=t&hk=7-OEgrKIB6&vs
=
It says "Stay STRAIGHT to go onto I-74 E." The problem is it's a "Left"
exit.
The line should say something like: "Take Left Exit #101 to continue on
I-74 East towards Mt Airy/Winston-Salem." This is what Google says on
their map: "Slight left at *I-74 E* (signs for *Mt Airy/Winston -
Salem*)". Heck, I've been fighting with Google trying to get them to
mention the Exit number for that step as well, but haven't had much luck.
This is what we need to work with MapQuest to fix. Maybe a special
"exit_left=yes" or "left_exit=yes" tag?


There's also a problem when a highway ends and both directions at the 
end have an exit number. Here we might need to use a relation.


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