Re: [Talk-us] Trunk versus motorway

[Nathan Mills]

The reason you don't get it is because you are not listening. Nobody has said 
the motorway tagging should continue through the intersection. The debate is 
entirely about where the classification change takes place. There are several 
instances in Arkansas where a motorway ends similarly. In AHTD's highway log, 
they cease to be a motorway wherever legal access control or the character of 
the road changes. Sometimes they do make the demarcation at an interchange 
(usually at the point where the intersecting roadway crosses) when the 
continuation is a short distance.

Given Arkansas law, the state's view is nearly always easily seen from speed 
limit signs thanks to very specific per se speed limits based on highway 
classification. Sadly (for this particular discussion), Oklahoma doesn't, 
though speed limit changes do often accompany clear changes in roadway 
classification.

The overall point being that there are in fact times when classification 
changes at a place other than an interchange.

It's been many years, but I recall there being a speed limit reduction 
northbound coming down the hill to the intersection in question. And again, I 
fail to see how adding an intersection magically changed the 3/4 of a mile 
between Apache and where the median disappears to accommodate the Gilcrease 
intersection. (I incorrectly called the extension past the Tisdale Apache in a 
previous message. I forget the actual name, west of the Tisdale, but it has one 
that is not Gilcrease)

It would be nice if you would stop acting as if there is no room for reasonable 
people to have differing opinions on this since even various state governments 
have differing opinions on the matter. It's mildly rude to pretend that yours 
is the only logical possibility, especially when several people have considered 
your argument and still don't agree.

All that said, at the moment you're the only person currently local to the 
instant case, so given the guideline that encourages us to defer to local 
mappers if their edits aren't broken in some technical way or obviously depart 
from reality, you're more than welcome to tag it the way you did if you like.

Still, it was a change from what another local had tagged originally. The TIGER 
import became irrelevant in relation to this discussion when someone took the 
time to add the other carriageway. This isn't a situation where the edit in 
question was being made to a way that was created by the TIGER import and not 
touched by anybody except a few bots since, so the norms surrounding that 
scenario aren't applicable.

-Nathan

On December 2, 2018 5:03:31 PM EST, Paul Johnson  wrote:
>The commonly accepted definition of freeways in the US excludes surface
>junctions, whereas expressways (trunks) does include intersections.  I
>honestly am surprised a group of roadgeeks isn't more attuned to this
>distinction.
>
>On Sun, Dec 2, 2018 at 3:15 PM Adam Franco 
>wrote:
>
>> On Sun, Dec 2, 2018 at 1:36 AM Paul Johnson 
>wrote:
>>
>>>
>>> On Sun, Dec 2, 2018 at 12:30 AM Bryan Housel 
>wrote:
>>>
 I do understand your point, but a dozen or so people on talk-us and
>the
 six or so people on that changeset 64919426

>>>
>>> Well, 1 person, an AA roads troll and like 5 sockpuppets.  There's
>also a
>>> number of people in this thread that do agree with me.
>>>
>>>
 discussion all disagree with you.  Is there nothing that would make
>you
 reconsider?

>>>
>>> Get the commonly used definition of a freeway changed to include
>>> intersections.  Good luck!
>>>
>>
>> Since you are asking for more declaration of support/opposition, I'm
>a
>> relatively disinterested-in-motorways mapper that has been following
>along
>> with this thread. Paul, I think your read of a motorway definition is
>> overly rigid and I agree with Richie, Bryan, and the others that a
>motorway
>> classification may continue beyond the last interchange.
>>
>> If one is traveling past the last interchange one may be traveling in
>a
>> "motorway zone" where high speeds, grade separation of crossing
>roads, dual
>> carriageway, etc all continue to exist. As Richie pointed out, there
>will
>> be some place where "caution freeway ends", "intersection ahead" or
>slowing
>> speed limit signage indicates a transition out of the motorway zone
>to
>> something else. That seems like a vastly more appropriate place to
>change
>> the tagging from motorway to trunk/primary. Choosing the point of the
>last
>> interchange doesn't make sense as there may be many miles on both
>sides of
>> the last interchange where the roadway is functionally the same --
>where
>> standing and looking at the road it shows all of the characteristics
>of a
>> motorway. It is confusing to think that an at-grade intersection far
>over
>> the horizon would force a long final segment of road to change
>> classification.
>> ___
>> Talk-us mailing list
>> Talk-us@openstreetmap.org
>> 

Re: [Talk-us] Fwd: Trunk versus motorway

[Nathan Mills]

I think this is a good general rule. In the instant case, the tagging should 
change at the point where the grass median ends northbound, IMO. That marks a 
definite change in the physical character of the road. I believe it was tagged 
like that when the carriageways were first split after the TIGER import, but I 
might be misremembering.

-Nathan



On November 29, 2018 12:01:58 AM EST, Evin Fairchild  
wrote:
>What?! I haven't contradicted myself at all. I already said in my
>initial
>response (the one that I sent to only you by mistake) that in cases
>where
>there's an at grade intersection sandwiched in between two
>interchanges,
>the road should be marked as trunk in between. Other than that case, a
>road
>should be motorway all the way to the at-grade intersection, as is the
>case
>with the Tisdale Parkway.
>
>On Wed, Nov 28, 2018 at 8:11 PM Paul Johnson 
>wrote:
>
>> On Wed, Nov 28, 2018 at 10:02 PM Evin Fairchild 
>> wrote:
>>
>>> Nobody is saying that we should tag as motorways a road with a
>surface
>>> intersection. I don't understand what it is that we're saying that's
>>> causing you to come to that conclusion. We are simply saying that
>the
>>> first surface intersection that a road comes across is where the
>motorway
>>> should change to trunk.
>>>
>>
>> You've contradicted yourself in that statement.
>>

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Fwd: Trunk versus motorway

[Nathan Mills]

Unless there have been significant changes since I moved away, it should be 
tagged motorway between the IDL and the light at Apache/Gilcrease Extension. 
Before the Gilcrease was extended west of US-75, the Tisdale should have been 
tagged entirely as motorway. Adding the intersection did not change the 
character of the road south of the Gilcrease extension or the rights of 
adjacent landowners, so I don't see any particular reason to reclassify that 
segment.

North of that, either trunk or primary would be equally reasonable.

-Nathan

On November 28, 2018 10:21:41 PM EST, Paul Johnson  wrote:
>On Wed, Nov 28, 2018 at 9:00 PM Evin Fairchild 
>wrote:
>
>> I think you're misrepresenting the discussion. People are simply
>saying
>> that the motorway destination should extend all the way to the first
>at
>> grade intersection, rather than the interchange prior to the at grade
>> intersection. Personally, I agree with this. The only exception would
>be if
>> there's an at grade intersection sandwiched between two interchanges.
>In
>> that case there should be a stretch of trunk in between the two
>> interchanges.
>>
>
>Right, but motorways are grade-separated, fully controlled, dual
>carriageways.  Throw in an at grade intersection, that's no longer
>grade
>separated.  That's not a freeway anymore, that's an expressway.
>Expressways are semi-controlled and do have surface intersections,
>though
>some or even most may be grade separated.
>
>
>> Further, I strongly disagree with the way the Tisdale was originally
>> tagged, (the entire thing, even the obvious freeway sections were
>> originally trunk) because if we followed Paul's logic everywhere,
>most odd
>> numbered 3 digit interstates would have to be tagged as trunk.
>>
>
>Well, let's talk about that.  There's quite a few out there that
>probably
>shouldn't be motorways, but instead motorway_link or trunk.  I 90 west
>of I
>5 is mapped a motorway right now but it's just a spiderweb of ramps to
>the
>Seattle Bus Tunnel, 5th Avenue, Seattle Boulevard, 4th Avenue, and
>Martinez.  Rationale for going from the US 412 interchange being that's
>the
>last (only, really) major junction along Tisdale with an unambiguous
>motorway.

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Naming numbered roads as "State Route X", "Interstate X", etc.

[Nathan Mills]

The New Sapulpa Road situation is in practice a road with a secondary name. 
Just like Flagler Street in part of Miami (FL, not OK) is defined by the state 
legislature as being "Natan A Rok Boulevard" (or similar, working from memory 
here).

My personal opinion is that if local practice and the USPS continue to use the 
old name, that name should stay in the name tag, while the Legislature's 
political name should be tagged as an alt_name. That said, there are situations 
in which most/all signage refers to the new name, in which case switching them 
makes sense. (Martin Luther King Jr. Boulevard in Fayetteville, AR being an 
example. Most still call it 6th Street, but the city, nearly all signage, and 
the USPS' preferred name are all "Martin Luther King Jr Boulevard," and they 
are going to keep it up until everyone gets with the program)

Sometimes, the name really is "Highway 66" or "Route 22." Admittedly, it can 
sometimes be hard to tell for sure without local knowledge. As long as people 
do their best and aren't dogmatic about it when someone who knows better comes 
along in the future it will all work out in the end. 

-Nathan

On September 1, 2018 5:28:11 PM EDT, Paul Johnson  wrote:
>On Sat, Sep 1, 2018 at 12:01 PM Peter Dobratz  wrote:
>
>To cite a specific example of how we might map something, consider the
>town
>> of Waldport, Oregon.
>>
>> https://www.openstreetmap.org/#map=18/44.42718/-124.06667
>>
>> As you can see, there is a US Route 101 running north-south through
>town.
>> Roads north of Northwest Hemlock Street include Northwest as part of
>their
>> names and roads south of Northwest Hemlock Street include Southwest
>as part
>> of their name.  US Route 101 is currently mapped in OSM with
>> "name=Northwest Highway 101" for the portions north of Northwest
>Hemlock
>> Street and "name="Southwest Highway 101" for the portions south of
>> Northwest Hemlock Street.  If we drop the name tag from this road in
>OSM,
>> then we lose the Northwest and Southwest directional prefix.  I think
>we
>> should retain the name tags on roads like this.
>>
>
>I don't.  While it is uncommon, there's other ways of handling this. 
>The
>way should still be noname=yes in this case.
>
>
>> Here is an examples of a POI along this route:
>>
>> https://www.grand-central-pizza.com/
>> Grand Central Pizza
>> 245 SW Hwy 101
>> Waldport, OR 97394
>>
>> USPS standard format of the address:
>> 245 SW HIGHWAY 101
>> WALDPORT, OR 97394-3036
>>
>> https://www.openstreetmap.org/way/463377211
>> addr:housenumber=245
>> addr:street=Southwest Highway 101
>> addr:city=Waldport
>> addr:state=OR
>> addr:postcode=97394
>>
>
>And this is how you would handle addresses along such a highway.  This
>also
>comes up (uncommon but still happens) where the USPS has decided to
>consider addresses with a different name than the street that frontages
>it.  In an extreme example, there's a road in my region that has the
>name
>"Officer Larry W. Cantrell and Mister Charles L. Cantrell Memorial
>Highway".  The addresses along it are all "New Sapulpa Road", the
>road's
>old name, presumably due to brevity.

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] [Imports] Durham and Chatham County Address Imports (North Carolina, USA)

[Nathan Mills]

To the extent that the address points are not duplicates of existing address 
nodes, unconflated address nodes are a perfectly legitimate means of mapping 
and do not need to be "fixed." Even if the address exists on a poly, it's still 
fine as long as the node is marking something meaningful, like the front door 
of the building. Some have in the past gone so far to say that nodes are 
preferable since it allows routers for the differently abled to provide 
door-to-door guidance.

-Nathan


On July 21, 2018 2:39:36 PM EDT, James Umbanhowar  wrote:
>Sorry, I just saw this.  Please do not upload this, yet.  You have not
>responded to any of the feedback that I have given.  Instead you have
>chosen to just upload all the points into the database and then correct
>the database afterwards.
>
>Please, instead, break this into smaller areas and then conflate the
>points with existing objects and then upload. From what I can tell,
>this would be easiest done with the Tasking Manager.
>
>Also, I have already signalled my willingness to help with this task
>and using the tasking manager would allow me and possibly others to
>help.
>
>Thank you,
>
>James
>
>
>
>On Thu, 2018-07-19 at 23:42 -0400, Leif Rasmussen wrote:
>> Hi everyone!
>I have finally verified the license on the Chatham
>> County, NC address data which includes about 44,000 address points. 
>> It is public domain except for that it has a "no direct resale"
>> policy that allows indirect resale (includes other data), which is
>> compatible with OSM.  Durham County, which uses the ODbL has also
>> produced address data.  I will be completing both the imports this
>> weekend.  Some discussion has taken place about adding buildings in
>> Durham at the same time as the import, but to keep everything more
>> simple, I have decided on just adding nodes for now and then merging
>> with buildings later.  This would reduce complexity and help
>> everything run more smoothly.  I will upload all of the data alone. 
>> This helps keep everything more simple, leading to fewer mistakes.  I
>> do not see very much benefit to having several account all importing
>> the data.
>
>Details:
>Size of both imports combined: 190,000 addresses
>Date of upload: Saterday and Sunday, 21st and 22nd of July, 2018
>Type of import:  One time with JOSM in 20 changesets.
>Account:  LeifRasmussen_import
>
>Wiki pages:
>Durham County
>Chatham County
>
>Please let me know of any concerns of ideas!  I would love to improve
>the import as much as I can.
>Thanks!
>Leif Rasmussen
>
>___
>Imports mailing list
>impo...@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/imports

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Comparing Tiger 2017 dataset with OSM in a automatedway.

[Nathan Mills]

The tree cover issue is precisely why many states that have seasons have a 
recurrent leaf-off (sometimes even in IR) imaging program. 

Arkansas has their imagery, along with a raft of other open data, available on 
Geostor as a WMS service that should be usable in JOSM and also as downloadable 
data in your choice of extent and format. Oklahoma's is also available 
somewhere, but I'm not sure where. They lack a statewide data repository, so 
their data is scattered about various state and university sites.

I know the wiki has a list of imagery sources, but I don't think it has any 
listed specifically as leaf off. Maybe someday I'll find some time to compile 
one.

-Nathan


On October 26, 2017 1:00:05 PM EDT, OSM Volunteer stevea 
 wrote:
>I don't know where all of this is going, and wanted to see for myself,
>so I downloaded the California file (the largest one of all) and zoomed
>in on where I live and am most familiar with, Santa Cruz County.  Thank
>you for providing the ten states worth of translated data for us to
>take a look.
>
>What I found was, um, "interesting."  In urban areas, there were indeed
>a few highway=service, service=alley ways which Bing confirms are
>either there, mostly there, or "almost there," as in "slightly offset
>by a meter or three."  However, many of these were also clearly
>service=driveway instead of alley, a subtle distinction, but a crucial
>one, in my opinion (driveway implies access=private).  In more rural
>areas (and by no means is this a hard-and-fast delineation), there were
>many similar entries, but tree cover (2/3 of my county) made these
>impossible to distinguish via Bing.  Also, many had a name= tag with an
>empty value.  I'd rather that simply be no name tag at all, so that
>should be an easy improvement to make in any future/additional
>translations.
>
>There are literally thousands of these in my little county (2nd
>smallest geographically in the state) and it would take many hours
>(days) to go through them one by one and Bing compare, which certainly
>would improve OSM's data here.  (I've done similar tedious visual
>comparisons for thousands of polygons and TIGER review before, it is a
>labor of love!)  However, much or even most of these data would need an
>on-the-ground verification, simply because aerial/satellite data,
>whether fresh or not, have too much tree cover to allow such armchair
>mapping.  And, most of these additional data are very likely in highly
>rural areas which are not only difficult to get to, but are obviously
>on private property and (as is very typical around here on those)
>behind gates or "No Trespassing" signs (which I respect).
>
>So, while I find these a potentially rich source of new and/or better
>additional data, it is with great tedium and difficulty that they might
>be vetted/verified in a proper OSM way (cursory, via Bing, and/or fully
>and correctly, "on the ground").  I'm delighted the exercise to
>translate them into an easily-usable-by-OSM way has taken place, but it
>is with a great deal of caution and indeed trepidation that I approach
>and/or allow any new TIGER dataset "easy entry" into our map.
>
>In short:  eyes very wide open, slow going (if any going at all) ahead.
>If your state is included in the list, and you can zoom into your
>county or city, I'd be curious to hear what others might say after they
>take the half-hour or so I did to look and offer similar impressions of
>these data.
>
>SteveA
>California
>___
>Talk-us mailing list
>Talk-us@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/talk-us

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Trunk

[Nathan Mills]

In the US, we've always treated primary/secondary/tertiary as a way to tag 
importance to the road network, while physical construction was secondary. 
Motorway, of course, was and still is treated differently. Trunk has always 
been stuck in the middle between people who like me and Paul want to use it 
more like motorway but for divided highways and people who want it to mean more 
primary than primary.

That's why we're still taking about it now, long after the usage of other 
highway tag values has long been settled. The closest thing to a decision that 
was ever made was NE2's unilateral mass edit, some of which has been reverted, 
some of which hasn't. Without consensus that the tagging is wrong and not just 
the unilateral decision, I'm not going to go out of my way to revert his trunk 
changes on ways I'm not otherwise editing large portions of. It's not a nice 
thing to do. It's got nothing to do with thinking that things should be that 
way and everything to do with not being a jackass who unilaterally imposes 
their will on the whole community.

-Nathan

On October 15, 2017 1:40:16 AM EDT, Bradley White  
wrote:
>If we can determine importance (which is what the 'highway=' tag
>fundamentally represents per the wiki) solely by what's on the ground,
>why not just tag what's physically there, ditch the 'highway' tag
>altogether, and let the renders handle it with their own algorithms?
>
>>On Sun, Oct 15, 2017 at 12:19 AM, Paul Johnson ursamundi.org> wrote:
>>>
>>> The US is pretty well known for overbuilding highways.  Are we
>trying to
>>> document how things are on the ground or how things are actually
>>> connected?  If we're going for the former, then yeah, only Bend
>Parkway and
>>> a brief streak through Klamath Falls is a trunk part of US 97.  If
>we're
>>> going for the latter, then go ahead with NE2's idea and smash almost
>>> everything into trunk.
>>>
>>
>>
>>Keep hitting send too soon.  Personally, I find what's on the ground
>to be
>>more useful than the connections.  Game theory and any routing engine
>can
>>figure out the connections.  But knowing what's a stupid rural road
>with an
>>overly generous speed limit and what's almost but not quite a freeway
>is
>>more useful.  If I'm driving a big rig going from southwestern Canada
>or
>>Alaska to somewhere in Nevada, I don't give two shakes what some
>toolbag
>>things is the most prominent road.  I care more about what *actually
>is a
>>big road*.  Calling a two leg segment of US 97 30km outside of East
>>Butthump, Oregon a trunk is a great disservice when it's basically on
>par
>>with County Road Number Who Even Cares tracing off to Outer
>>Smalltownsville, other than the fact that it goes through.  Calling it
>a
>>trunk when it's not is going to set an unreasonably high expectation
>for
>>what is otherwise an overtravelled, glorified two digit National
>Forest
>>route through the east Cascades frontier.  Primary is definitely ample
>for
>>that road, even if you're going a more obscure minor haul route like
>Salem
>>to Reno.
>
>___
>Talk-us mailing list
>Talk-us@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/talk-us

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Trunk

[Nathan Mills]

Yes, on more than one occasion back in the mists of time before armchair 
mappers had spread the lanes and other condition tags widely I found some 
pretty shitty US highways labeled as trunk, not because they are better roads, 
but because they happen to be long distance through routes. US412 should not be 
trunk across most of the state of Arkansas. It's mostly a crappy winding route 
that is actively dangerous for trucks, who should be taking I-49 to I-40 or 
US71 north to 44 unless their destination is directly along the route.

By the network definition, it solidly deserves trunk, but by any other measure 
it does not, and calling it so drives traffic to places it shouldn't be and 
makes the map harder to use effectively at a glance.

Yesterday(ish) someone asked which maps differentiate expressway vs freeway vs 
everything else that is paved in their inking styles. I'll answer that with a 
question. Have you ever seen a US paper map? Until the digital road atlases 
with topo shading and/or overlays started becoming common in the late 90s 
basically every official state highway map, chamber of commerce map, gas 
station map, and road atlas differentiated divided, limited access, undivided 
paved, and unpaved with styles and paved/unpaved with weight. Sometimes you'd 
get numbered highways in red and other roads in black (with light grey or 
dashed lines to mean unpaved, depending on the map)

It's long been how US road maps are drawn, so map users here expect that 
differentiation to exist. Of course, we also expect toll roads to be colored 
green, but OSM doesn't do that either. (And I'm fine with that, TBH. I don't 
consider it as important as being able to differentiate between divided and 
undivided in a relatively simple way.)

If someone could explain why primary is insufficient to denote a paved rural 
road that connects minor population centers far from other routes. Why should 
US-71 south of Witcherville in Arkansas not be tagged as primary once the 
divided segment ends? There aren't many US highways of that size with more 
traffic, but it seems solidly primary to me. Some might make the whole thing a 
trunk since the route goes through several states and is important enough to be 
being replaced as money becomes available with I-49. Never mind the four plus 
hours of driving through little towns on a windy mountain road involved. I'd 
have gotten in an edit war over it if someone had tried to tag the part north 
of I-40 a trunk before the freeway was built to Fayetteville and beyond.

-Nathan

On October 15, 2017 1:27:42 AM EDT, Paul Johnson  wrote:
>On Sun, Oct 15, 2017 at 12:19 AM, Paul Johnson 
>wrote:
>>
>> The US is pretty well known for overbuilding highways.  Are we trying
>to
>> document how things are on the ground or how things are actually
>> connected?  If we're going for the former, then yeah, only Bend
>Parkway and
>> a brief streak through Klamath Falls is a trunk part of US 97.  If
>we're
>> going for the latter, then go ahead with NE2's idea and smash almost
>> everything into trunk.
>>
>
>
>Keep hitting send too soon.  Personally, I find what's on the ground to
>be
>more useful than the connections.  Game theory and any routing engine
>can
>figure out the connections.  But knowing what's a stupid rural road
>with an
>overly generous speed limit and what's almost but not quite a freeway
>is
>more useful.  If I'm driving a big rig going from southwestern Canada
>or
>Alaska to somewhere in Nevada, I don't give two shakes what some
>toolbag
>things is the most prominent road.  I care more about what *actually is
>a
>big road*.  Calling a two leg segment of US 97 30km outside of East
>Butthump, Oregon a trunk is a great disservice when it's basically on
>par
>with County Road Number Who Even Cares tracing off to Outer
>Smalltownsville, other than the fact that it goes through.  Calling it
>a
>trunk when it's not is going to set an unreasonably high expectation
>for
>what is otherwise an overtravelled, glorified two digit National Forest
>route through the east Cascades frontier.  Primary is definitely ample
>for
>that road, even if you're going a more obscure minor haul route like
>Salem
>to Reno.

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Trunk

[Nathan Mills]

I guess my question is why primary isn't good enough for the primary route 
between places that don't have higher grade roads connecting them? These 
important mostly two lane roads are perfectly fine as primary.

In many cases primary routes happen to be divided, but in many cases they 
aren't. Having a simple distinction between the two by using trunk to mean 
non-motorway divided (or similar) preserves long-standing practice and 
generally seems like a good thing to me.

-Nathan

On October 14, 2017 11:18:43 PM EDT, Evin Fairchild  wrote:
>I'm amazed that NE2's definition hasn't been removed after 7 years. It
>must
>not have been that controversial or else someone would have removed it.
>Seems like you just don't agree with his opinion and just really have
>some
>personal problems with that guy. I know he engaged in some really dumb
>stuff like unilaterally changing all the US highways to trunk and he
>ultimately got banned for a turn restriction dispute with you over a
>parclo
>interchange in Florida, but he's not the only one who believes that
>many US
>highways are deserving of trunk status given the amount of traffic they
>receive and their importance in a region's highway network.
>
>On Sat, Oct 14, 2017 at 8:02 PM, Paul Johnson 
>wrote:
>
>>
>>
>> On Sat, Oct 14, 2017 at 9:43 PM, Evin Fairchild 
>> wrote:
>>
>>>
>>>
>>> On Oct 14, 2017 5:41 PM, "Paul Johnson"  wrote:
>>>
>>>
>>>
>>> On Sat, Oct 14, 2017 at 7:28 PM, Evin Fairchild
>
>>> wrote:
>>>


 On Oct 14, 2017 4:25 PM, "Paul Johnson" 
>wrote:



 On Sat, Oct 14, 2017 at 6:08 PM, Evin Fairchild
>
 wrote:

> On Oct 14, 2017 2:04 PM, "Wolfgang Zenker"
>
> wrote:
>
> Hi,
>
> it looks to me that this discussion is going in circles, not
>forward
> at the moment. IMHO it does not make a lot of sense to argue what
>might
> be the true meaning of "trunk". Instead, we should concentrate on
>what
> it should mean, document this meaning if we can agree on one and
>don't
> worry to much about what other maps or different parts of the
>world
> think a "trunk" is.
>
>
> Yeah, the whole reason why this discussion hasn't resulted in a
> consensus for 7+ years is because people have dug in their heels
>so much
> and said "trunk roads can only be divided highways, no its, ands,
>or buts."
> I support what is written on the wiki that says that it is the
>second most
> important road after motorway. I haven't seen a single compelling
>reason to
> believe that trunk should only apply to divided highways. You can
>still
> tell whether a trunk is divided at low zooms based on how thick
>the line is.
>

 I'm OK with single carriageway trunks, if they're controlled
>access,
 like, say, the Chickasaw Turnpike, and similarly constructed roads.
> The
 single carriageway parts of US 395 or US 97 in eastern Oregon, US
>400 in
 Kansas or US 75 in Oklahoma, though?  They're all solid primaries.


 You actually think that US 97, the main artery thru Central Oregon
>that
 passes thru the Bend area which has a 75K population and a metro
>population
 of 100K shouldn't be connected to the outside world with a trunk
>road?

>>>
>>> Yes.  Because for the majority of that length that isn't between US
>20
>>> and County Road 40 is, for all practical purposes, the same generic
>two
>>> lane, shoulderless ribbon of pavement that pretty much any two lane
>Texas
>>> FM or RM road, or pretty much any other similar road in the American
>west.
>>> Primary is more than ample for such a road.
>>>
>>>
>>> That's not accurate to compare a US highway to some podunk FM/RM
>road out
>>> in the middle of nowhere in Texas. US 97 has way more traffic and
>very
>>> deserving of its trunk road designation. Most US highways are,
>except in
>>> places where they parallel an interstate or other freeway. BTW, this
>is
>>> what is written on the wiki.
>>>
>>
>>  Which was updated by NE2 to skew towards his view of the situation. 
>Any
>> edits by him have negative value at this point.  Disconnect his
>reality
>> from actual reality.
>>

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Trunk

[Nathan Mills]

I think I've said this before, but I'm mostly in agreement with Paul's 
position. Trunk should apply to divided, limited but not controlled access 
highways. Other uses should be exceptions in the same vein as rural interstates 
with a few at-grade intersections keeping their motorway status.

Expressways may often not be of more than local importance, though they often 
are. US 412 in Arkansas is an example which should be part trunk part primary, 
IMO. Even when they are of only local importance, they should still get the 
trunk tag, same as a short motorway still being a motorway despite being 
completely irrelevant to the overall national road network.

Road maps in the US have long differentiated between freeway/expressway and has 
had both of those clearly different than US and state highways we'd be tagging 
as primary. Map users expect to see expressways shown differently. We have the 
tag, it already renders more like motorway in a similar style to other maps, so 
it makes sense to me to work like other maps since it's what end users expect. 
Given that the tag is already there and is fit for purpose. Unless someone can 
show me a situation in which critical information can't be conveyed if an 
important, but undivided, road is tagged primary rather than trunk (Assuming 
the undivided section is not a short interruption in an otherwise continuous 
expressway) I just don't see the benefit of using it to mean "more important 
than primary" rather than "divided but not fully access controlled"

In short, both maps and common use in the US have historically had three main 
classes of paved road. Freeways/motorways, expressways/trunks, and everything 
else. The visual difference between the lower class roads was either based on 
network importance or whether it is a US or state highway, but the higher class 
(faster) roads have long been classified apart from everything else in a way 
that maps very well to motorway/trunk as it has generally used by most US 
mappers aside from NE2 thus far.

It's less work on so many levels also. Creating a new tag requires significant 
work on the render side, but doesn't really gain us much over just using 
primary for roads that some think are important enough to be a trunk but are 
undivided. The wiki definition for primary is already "the most important 
non-motorway route between two cities" (essentially, and ignoring the variation 
in use between rural and urban areas) I don't think any backend work is worth 
the insignificant increase in expressiveness of the map we'd get from using 
trunk as a better primary and introducing a separate tag to denote an 
expressway.

As far as Alaska goes, it's different enough I don't think it's at all 
unreasonable to adjust the rules a bit there, just like there is already some 
variation between states and countries on how to differentiate between 
primary/secondary/etc.

If the issue is the low zoom rendering of short trunk and motorway segments, 
that's a misfeature in carto, not a tagging issue. And not even so hard to fix 
now that route relations are so prevalent.

-Nathan


On October 14, 2017 1:23:39 PM EDT, Bradley White  
wrote:
>> The concept of expressway and freeway are reasonably well known
>concepts;
>> it makes a lot of sense to map trunk and motorway to those concepts.
>
>I agree with freeways but not with expressways. I have no data to back
>this claim up, but I'm fairly convinced that, while the average
>citizen could easily differentiate between "freeway" and "not
>freeway", they would be hard pressed to do the same with an
>expressway. Anecdotal, but even when I spent time in the Santa Clara
>area which has a robust expressway system, I never heard a single
>person say "and then get on the expressway...", or even the word
>'expressway' mentioned outside of it being the suffix of a road name.
>You're right that it's not a terribly difficult concept to understand
>and thus map, but I disagree that it's an important concept in
>explaining the road hierarchy in the US, so much so that we can equate
>an entire class of importance with them. We have a robust, clearly
>signposted freeway network in the US. We do not have the same with
>expressways. Roads tend to go in and out of "expressway" qualification
>depending on context, traffic levels of connecting roads, and highway
>budget & design policy. A road being built as an expressway is
>suggestive of its importance at best, and certainly not indicative.
>
>Edmonton has many roads around the east and west of the downtown area
>that are clearly built as expressways. However, they are only tagged
>secondary because, fundamentally, you only really need to use them to
>get around the immediate vicinity. Despite being very high quality
>roads, they aren't all that important in the grand scheme. I can point
>to many examples of urban roads that likely meet an expressway
>definition in my current home city of Reno, including one under

Re: [Talk-us] Texas - redacted roads.

[Nathan Mills]

The problem as I understand it is less copyright violation (in the US, so long 
as what you see in Google isn't ever put into the OSM database), and more 
database licensing difficulty in the rest of the world where the law is less 
permissive and even using Google to identify possible errors in to be corrected 
by survey or open data could be legally questionable in terms of sublicensing 
the work as a whole.

Best to stay well on the correct side of the line just to avoid any possible 
issues since we have to be legal globally, not just in the US or UK or the EU.

-Nathan

On October 12, 2017 6:04:37 AM EDT, Nick Hocking  wrote:
>richlv wrote "just a quick reminder that we should try not to use
>google
>maps or
>streetview, the legal status of "just looking" is also fuzzy :)"
>
>
>Ok, so I if want to find out what a road is called, I'm not allowed to
>use
>a street directory to do this?  This would be extremely weird.
>
>If I am allowed to use a street directory for this, then I'm not
>allowed to
>tell anybody else what I think the name of the road is.  Also extremely
>weird.
>
>I don't believe that writing what someone else thinks is the name of
>the
>roads constitutes republishing their proprietary work and I'm certainly
>not
>putting this information into any other work or database. (Mind you
>IANAL).
>
>A few years ago this topic came up and IIRC Google said that it was ok
>to
>look at "some" amount of their published data but not systematically
>trawl
>through a LOT of it.
>All very subjective, I know.

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Trunk

[Nathan Mills]

On October 8, 2017 3:46:07 PM EDT, Paul Johnson  wrote:

>
>County and rural roads, particularly of the 3- and 4-digit National
>Forest
>routes and...really pick an unpaved section line almost anywhere in an
>area
>bounded by the Rocky Mountain frontier, the Appalachian frontier, the
>Rio
>Grande River, and the permafrost line in Canada.  Unclassified could
>mean
>anything from so steep and unmaintained as to be barely passable by a
>4x4
>in otherwise pristine weather, to a 15 meter wide, graded-and-packed
>gravel
>road allowing a city car to rip along at 80+ km/h without trouble; a
>beat-up, worse-than-unpaved gravel-and-tar car-rolled tarmac to a
>smooth-as-glass concrete surface.  

Seems like some of those would be more properly tagged as a track. I was 
thinking more in terms of network classification for the primary and lesser 
highways. In that sense, while tertiary (for example) may be different quality 
in different areas, it serves the same purpose in the road network. Not too 
long ago many primary and lesser routes were unpaved or poorly maintained 
between cities, after all, especially out west and still today in some 
mountainous and particularly rural areas in the US. That said, if a family car 
can't safely navigate it, it should be a track given my understanding. 
Regardless, there is already a wide variation in what a primary, secondary, etc 
looks like between cities and suburbs/exurbs/rural areas. Obviously, they will 
vary even more in the wilderness.

There aren't a whole lot of through roads that are unusable in a sedan in good 
weather that I've seen in the lower 48, though. My standards are pretty low on 
that count, so maybe my opinion on that differs from others. I've been down a 
lot of barely maintained mountainous forest roads in small sedans without much 
incident. You just have to be prepared and know when to turn back. ;)

And just a minor bit of Tulsa history pedantry: The Riverside expressway plan 
never actually went beyond paper due to opposition from people living in Maple 
Ridge near the north end of Riverside, who had the clout in city hall to keep 
it from happening. The closest to it is the part between 71st and 91st, but 
that is the way it is because it wasn't built until well after the rest of it 
so the adjacent properties were mostly already developed with access to the 
east, thus the lack of intersections and driveways except at the section lines 
and the few developments that have been allowed between Riverside and the river 
itself.

-Nathan
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

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

Re: [Talk-us] Trunk

[Nathan Mills]

Riverside in Tulsa is fairly clearly a primary for most of its length. It isn't 
part of a larger trunk route nor is it an expressway.

Personally, I think of trunk as more like motorway than like the other highway 
values. Motorway is clearly used only for controlled access freeways (excepting 
short sections in extremely rural areas where an Interstate doesn't quite meet 
the standard). I think of trunk as the same thing, but for expressways. For 
routes that are not primarily expressway, I think primary is a better 
classification. That assumes it otherwise meets the standard for primary.

I can't think of any situations off the top of my head where 
unclassified/residential/tertiary/secondary/primary don't provide enough 
differentiation between sub-expressway roads. Using trunk to mean "more primary 
than primary" seems to reduce the usefulness of the map to simple data 
consumers that don't/can't take into account lanes and similar tags. Using 
trunk and motorway to mean "limited access expressway" and "controlled access 
freeway," respectively, seems to express the US road network better than 
conflating primary and trunk as NE2's edits often did. (And still are, in many 
places)

-Nathan

On October 8, 2017 2:29:26 PM EDT, Paul Johnson  wrote:
>On Sun, Oct 8, 2017 at 1:25 AM, Shawn K. Quinn 
>wrote:
>
>> On 10/05/2017 05:30 PM, Martijn van Exel wrote:
>> > Question for you all:
>> >
>> > What make Michigan state routes 5 and 10[1] trunks rather than
>> primaries?
>> >
>> > To my mind these are highway=primary mainly because of at-grade
>> > intersections.. I am still confused about what makes a trunk road
>in the
>> > US. To my mind it's roads with no at-grade intersections but not
>built
>> > to interstate standards / not having an interstate designation...
>I'm
>> > not looking to open up a can of worms but I would really like to
>> understand.
>>
>> On a related note, I recently downgraded Allen Parkway in Houston
>from
>> trunk to primary, based on the somewhat recent reconfiguration,
>adding
>> traffic signals and lowering the speed limit (which I removed without
>> adding a replacement, knowing only that it's no longer 40 mph but I
>> forgot if they made it 35 mph or 30 mph). It's possible the western
>part
>> (closer to where it changes names to Kirby Drive) may still
>technically
>> qualify as trunk, but it is kind of an edge case even then.
>>
>> Thoughts?
>>
>
>Looks fair to me, I could see the argument going either direction on
>that
>one, falling into a similar situation to Tulsa's Riverside Parkway
>(which
>could a small trunk being a cancelled freeway or a large primary; I'm
>legitimately on the fence on that one myself).

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] wtsp.com using OSM for detour maps

[Nathan Mills]

I've seen several other uses in local media as well, but no links since I'm 
stuck on my phone for a good long while..

-Nathan 

On September 14, 2017 12:06:38 AM EDT, James Mast  
wrote:
>http://www.wtsp.com/news/flooding-could-close-i-75-as-floridians-try-to-get-home/474415152
>[http://content.wtsp.com/photo/2017/09/13/map_1505321021730_10880901_ver1.0.PNG]
>
>Flooding could close I-75 as Floridians try to get
>home
>www.wtsp.com
>"The Santa Fe River under I-75 has rapidly risen 15 feet within the
>past 36 hours due to the heavy rainfall over North Florida from
>Hurricane Irma," Highway Patrol Spokesman Steve Gaskins said.
>
>
>
>Thought this was kinda cool.

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] [HOT] Surveys and studies

[Nathan Mills]

I'm sorry, but the closest thing to toxicity I've seen are the overly vehement 
objections to the mere gathering of data. It might be worth examining why 
someone gathering demographic data is causing such a strong reaction.

I sincerely cannot comprehend why anyone would be against this. I can see 
"meh," I can see how someone might find it interesting or maybe even useful, 
and I can even understand finding it totally useless and asking why someone 
else finds it interesting. I can't find any reasonable objection to the 
voluntary collection of demographic data regarding OSM editors and I especially 
can't find any basis to say that it is in any way divisive or "gender-baiting."

If you don't like it, maybe just ignore it since it doesn't affect you in any 
way except receiving an extra email.

-Nathan

On September 5, 2017 2:32:33 PM EDT, Joel Holdsworth  
wrote:
>On 05/09/17 12:07, Charlotte Wolter wrote:
>> If someone named Allessanbdro were in charge, a study,
>> such as Zoe's, never would happen, Clearly, from the reactions
>> on the email lists, a gender topic is very threatening to a number
>> of members.
>
>That's a quite a toxic statement.
>
>It's hard to think of a project more egalitarian than OSM. Which is why
>
>people object to the gender-baiting. It's not because they feel 
>threatened, it's because it's so divisive.
>
>Joel
>
>___
>Talk-us mailing list
>Talk-us@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/talk-us

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] MO Stare Road Classifications.

[Nathan Mills]

Typically state DOT functional classification freeway and expressway both imply 
limited, but not necessarily fully controlled, access, so trunk is a good first 
approximation. However, the DOT classification diverges enough from OSM tagging 
standards/consensus (such as it is in the US, anyway) that using it as anything 
more than a basic reference where decent satellite imagery and ground truth 
observations are unavailable is a bad idea.

It's better than nothing when looking at unreviewed stuff from the TIGER 
import, for sure, but that's about it.

-Nathan

On March 6, 2017 11:13:28 AM EST, Paul Johnson  wrote:
>On Mar 5, 2017 13:35, "OSM Volunteer stevea"
>
>wrote:
>
>
>I would say "almost, but not quite."  Interstate and Freeway, both
>highway=motorway.  Expressway, highway=trunk.
>
>
>If it's semi limited access (few to no driveways, a mix of at grade and
>grade separated junctions), I would call that a trunk.  Just a highway
>that
>isn't limited access? Not a motorway or trunk.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Caliparks re-tagging paths?

[Nathan Mills]

Had it been discussed beforehand so that other consumers would be aware of the 
meaning of the new tag, I wouldn't personally have a problem with it. access=no 
is also a decent suggestion (and would not require discussion with the 
community beforehand), but there is likely a quantitative difference between 
these informal trails and the official ones, so it makes sense to have a 
different tag value.

-Nathan

On March 24, 2016 2:05:22 PM EDT, Mike Thompson  wrote:
>On Thu, Mar 24, 2016 at 9:50 AM, James Umbanhowar 
>wrote:
>
>> Regardless of the community's eventual solution, I think the most
>> important part of this event was the lack of engagement of Caliparks
>> and Stamen with the community.  Is there a similar process for
>> institutional (business, government, non-profit) editing of data as
>> there is for imports?  There should be.  I think institutional
>> engagement with OSM can bring many benefits, but has similar dangers
>as
>> imports.
>
>Regardless of who is editing (individual or institution), removing well
>accepted tags (highway=path) and substituting newly created tags
>(highway=social_path) shouldn't take place without community
>discussion.
>
>Mike
>
>
>
>
>___
>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] DOT construction updates

[Nathan Mills]

OKDOT provides updates on Twitter as well as posts weekly (and occasionally 
more often when warranted) "Traffax" PDF updates on their website that has a 
list of all scheduled roadwork and closures on state highways. Back in the 
olden days Traffax was blasted via fax to all the news outlets in the state, 
hence the name.

When I was still in Oklahoma, Traffax was the primary source I used to update 
OSM with road closures, construction zones, and reopenings. (When I didn't have 
direct personal knowledge of such from my travels)

-Nathan

On March 16, 2016 2:20:57 PM EDT, Martijn van Exel  wrote:
>Hi all, 
>
>I was thinking about a good way for the community to get a feed of
>construction updates from state DOTs. Has anyone ever attempted this? A
>good start should be a list of state DOTs (I found
>http://www.dot.state.ak.us/transpo_resources.shtml
>, not sure if it’s
>100% current). But where to go from there? Every state DOT has its own
>mechanism / format to distribute updates. Do they all have an RSS feed?
>Or twitter?
>
>At this point I am just curious to hear if anyone else has thought
>about this already and if so what you have come up with so far.
>
>(What triggered this again for me: I heard someone mention that the
>work on the I-96/US-23 interchange in Michigan was complete, but could
>not find any confirmation. See this pretty cool video from MDOT for
>what they are doing there: https://youtu.be/K9wQoIc2cLc?t=75
>.) The situation on OSM reflects the
>pre-construction reality —>
>https://www.openstreetmap.org/relation/359765#map=15/42.5227/-83.7526
>)
>
>Martijn
>
>
>
>___
>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] mapRe: (Second attempt) Potential data source: Adirondack Park Freshwater Wetlands

[Nathan Mills]

Personally, I think using TIGER as an example of an import gone wrong is not 
accurate. Knowing what we know now, things certainly could have been done 
better. If nothing else, waiting for TIGER 2010 would have been prudent, as the 
accuracy was much improved. But that wasn't something that was knowable at the 
time, so it makes no sense to second guess based on that.

That said, without TIGER, OSM would have been useless (and still would be!) in 
large swaths of the US. Thanks to the import, routing clear across the US was 
possible many years before it otherwise would have been. I was able to do a lot 
more work in Tulsa than would have been possible from GPS traces alone thanks 
to the import. As a newbie at the time, correcting geometry was much more 
doable than mapping completely from scratch.

If you want an example of a bad import, GNIS is a much better example, IMO. The 
data was largely 30 years out of date at the time of the import. I still find 
myself outright deleting many of those nodes when I come across them. (On the 
rare occasion I have the time and motivation to map these days, anyway)

By no means is this to say that any data set one comes across is appropriate 
for OSM or that many of the controls or improved processes put in place in the 
last several years are in any way a bad thing. However, I feel like some people 
want to throw the baby out with the bathwater.

-Nathan

On March 14, 2016 11:57:19 PM EDT, Tod Fitch  wrote:
>Ditto to Mike’s comments.
>
>I’ve been dealing with the clean up of bad imports, usually TIGER but
>others too, where ever I map so I think I understand where people like
>Frederick are coming from.
>
>But I also see the reality in the U.S. of huge geographical areas with
>very few OSM mappers. An all volunteer map will always be years behind
>other offerings here unless we allow and even encourage carefully
>importing high quality data.
>
>The U.S. might be unique in that there are vast quantities of excellent
>geographical data that are public domain. Unfortunately there is also a
>vast quantity of public domain map data of, shall we say, lesser
>quality. Had the original U.S. highway import data come from the USGS
>rather than the census bureau, people probably would have a very
>different opinion about imports.
>
>At least the experience with bad imports has shown there can be issues.
>And there is now a lot better understanding of how the data and import
>procedures need to be vetted. So we are in a better place to do imports
>and we should not shy away from importing high quality data when the
>stars line up (good data, appropriate copyright, competent OSM mappers
>available, documented and tested work flows, etc.).
>
>Tod
>
>> On Mar 14, 2016, at 8:36 PM, Mike Thompson 
>wrote:
>> 
>> I support the careful import of high quality data whose license is
>compatible with OSM. Those appears to be one of those cases. I believe
>the existence of high quality data will aid in the recruitment of new
>mappers and will encourage high quality contributions from those
>mappers. It is much easier, and less daunting,  to add  additional
>detail from an on-the-ground  survey to some high quality data than it
>is to start from scratch. People also like to be associated with
>successful projects, and the more high quality data we have the more
>successful we will be in the eyes of potential new mappers.
>> 
>> Mike
>> 
>> 
>> On Mon, Mar 14, 2016 at 8:46 PM, Kevin Kenny > wrote:
>> Since I received only a total of three comments about this idea, one
>strongly negative (from Frederik Ramm) and two only lukewarm in
>support, I'm forced to conclude that this proposal has no chance of
>gaining a broad community support. Consider it withdrawn.
>> 
>> I find myself somewhat frustrated about the question of how to
>recruit mappers when it appears that the map has such a paucity of data
>that it will never become useful solely through the effort of volunteer
>mappers. I can demonstrate the map at
>http://kbk.is-a-geek.net/catskills/test3.html
>, and state that OSM is
>one of many data sources that go into it, but when people go to
>openstreetmap.org  and look at it, my
>experience is that they lose the connection entirely between the data
>that OSM has and the map that OSM enables. The huge blank area is too
>intimidating for my friends, it appears!
>> 
>> The fact that we apparently cannot use data that are not our own in
>presenting our public face, together with the fact that we do not wish
>to import data for which OSM will not become the authoritative source,
>leaves us with an impoverished public appearance outside the cities
>where streets are sparse. Perhaps this is outside OSM's ambit. It is,
>after all, Open STREET Map. It seems to leave, however, very limited
>pathways for citizen mappers to build on 

Re: [Talk-us] San Diego Address Import Update

[Nathan Mills]

This is how I have always used addr:city. It reflects the postal address since 
it is a property of the address and not the parcel itself. People once used the 
is_in tag to capture the other meaning, but it seems unnecessary to me since 
one can simply check for an enclosing admin boundary.

On November 10, 2015 10:48:20 AM EST, Tod Fitch  wrote:
>

>So what is a good definition for what should go in the addr:city tag?
>If it is based on being within a formal administrative boundary then we
>may not need the tag at all as it should be easy for a data consumer to
>detect that. I have come to the conclusion that the addr:city is best
>to indicate what the locals feel their town name is. In the western US
>my impression is that has a high correlation with the USPS designation.
>Further, when dealing with any financial or government entity, it seems
>the city they want to hear about is the one the post office delivers
>to, not some subset or superset defined by a formal boundary of an
>incorporated town or city. So equating the post office town name with
>the OSM addr:city value seems proper to me.


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

Re: [Talk-us] Current Texas State Highway ref is incorrect

[Nathan Mills]

At least with regard to the ref tag on a way, there has seemed to be be a lack 
of consensus as to whether the state DOT should be followed or whether to use 
the postal abbreviation to prefix state routes. Different states are tagged 
differently.

I personally prefer the state code in the ref tag applied to the way itself, as 
it makes life easier on simple data consumers that don't deal with relations 
when there are ways that are on a state line or the more rare case where a 
given state's highway route is actually not in that state. (There is an example 
of this in far NE Oklahoma, where there is a multiplex of OK/AR routes on a 
roadway that deviates fully into Oklahoma for a while)

In relations, I thought the bare number was to be used in the ref tag, with the 
disambiguation being in the network tag (e.g. network=US:TX:SH, ref=60), but it 
has been a while since I've looked at the docs.

-Nathan

On November 5, 2015 7:47:13 PM EST, Sam Iacullo  wrote:
>The current setup for Texas State Highway ref tagging (See:
>http://wiki.openstreetmap.org/wiki/United_States_roads_tagging#Texas)
>There
>has already been some discussion as to what exists on the map (
>https://lists.openstreetmap.org/pipermail/talk-us/2014-September/013604.html),
>but this was based on the majority of relations being incorrectly added
>into OSM. As per the Texas Department of Transportation, the ref should
>be
>"ref=SH ##" instead of the current "ref=TX ##".
>
>
>Existing documentation supporting this change:
>http://txdot.gov/inside-txdot/search-results.html?q=TX_section=main
>
>*(WRONG
>TAG)   
> *
>http://txdot.gov/inside-txdot/search-results.html?q=SH_section=main
>
>*(CORRECT TAG)*
>If there is no opposition to correcting this tagging error, I will
>change
>the appropriate page over.
>
>
>
>
>___
>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] Request revert on Changeset #33669446

[Nathan Mills]

I can't speak to this specific instance, but based on Paul's usual criteria, 
I'd take what he has to say on the topic with a grain of salt. I gave up trying 
to convince him OK11 between I-244 and US-75 in Tulsa should be tagged as a 
motorway a long time ago, even though it has zero at grade intersections.

I also think the LL Tisdale between downtown and Pine should be classified 
motorway, but that one is at least arguable to my mind since it is very short 
and has only three interchanges, one of which is directional.

On September 2, 2015 12:25:11 PM EDT, Paul Johnson  wrote:
>I'm kind of seeing that as abuse of classification and classification
>creep
>as well.  I'd probably have gone with trunk for the entire length of KS
>7
>from KS 32 to KS 10 rather than spin the wheel and creep it upwards. 
>I'm
>not really seeing a significant difference in characteristic in the WA
>500
>example or the KS 7 example from the 70 MPH sections of OK 33 or US 75
>between Tulsa and Bartlesville, OK.  All four are surface freeways with
>regular intersections.  This one doesn't "go to 11", folks; if you
>think
>you need a mix of motorway and trunk, it's probably just a trunk.
>
>On Wed, Sep 2, 2015 at 11:10 AM, Richie Kennedy
>
>wrote:
>
>> Revert request opposed. At best, there needs to be additional
>discussion
>> within talk-us regarding this before DWG takes any action.
>>
>> I am not one of the participants that have edited WA 500 recently;
>> however, those that have have brought this up on the AARoads forum.
>It is
>> the opinion of the AA posters that significant segments of upgradable
>> expressways that have been upgraded to fully controlled access should
>be
>> tagged as motorway.
>>
>> I offer as an example this stretch of Kansas Highway 7 between Bonner
>> Springs and Olathe:
>>
>> http://www.openstreetmap.org/changeset/33634149
>>
>> It is 4 lane divided from Lansing to Olathe, and KDOT’s future plan
>is to
>> eventually bring the entire roadway up to freeway standards. I am
>also
>> personally familiar with this roadway. I have verified and marked the
>> controlled access segments of K-7 as motorway, and the partially
>controlled
>> access roads as Trunk.
>>
>> Of note: the interchange at 83rd Street is marked as trunk. There is
>a
>> at-grade intersection with a service road between the 83rd and
>Prairie Star
>> Parkway interchanges. This intersection has, in fact, been overlooked
>by
>> OSM mappers, myself included, in the past.
>>
>> Richie Kennedy
>> McLouth, KS
>>
>> 
>> From: Paul Johnson
>> Sent: Wednesday, September 2, 2015 2:36 AM
>> To: d...@osmfoundation.org ; OpenStreetMap talk-us list
>> Subject: [Talk-us] Request revert on Changeset #33669446
>>
>> This is regarding WA 500 in Vancouver, Washington.  This is a surface
>> expressway that will be later upgraded to a motorway, but currently
>has a
>> mix of surface intersections and ramp style interchanges.  It appears
>there
>> is a small but vocal minority of people who are attempting to start
>an edit
>> war regarding this issue.
>>
>
>
>
>
>___
>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] zip-city mappings

[Nathan Mills]

Just keep in mind that some ZIPs cover multiple cities. The one I'm standing in 
now is found in parts of at least 3 different cities that I know of. Others 
cover both (parts of) cities and unincorporated areas outside of the city whose 
name they are associated with.

-Nathan


On November 9, 2014 11:00:42 AM EST, Richard Welty rwe...@averillpark.net 
wrote:
actually, it wouldn't be terribly hard for me to knock together a
simple web page for looking up/entering zip code to city mappings,
so i think i'll look into doing that. anyone who wants to save up
shopping/credit card receipts so that they can enter the data should
feel encouraged to do so. it may not happen right away because i'm
pretty busy with other admin boundary stuff, but i'll try to have it
in a week or two.

if i include existing OSM zip-city mappings, it would need to be ODbL.
some geocoder projects insist on public domain data (will CC0 do for
these geocoders?) this is a detail that would need to be worked out.

richard

-- 
rwe...@averillpark.net
  Averill Park Networking - GIS  IT Consulting
  OpenStreetMap - PostgreSQL - Linux
  Java - Web Applications - Search


___
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] Separate relations for each direction of US State highways.

[Nathan Mills]

I'm still confused as to why the consumers of a relation can't use the 
forward/backward roles of the ways referenced therein rather than requiring 
completely separate relations. Why do we need two or more relations plus a 
super relation per road route even for undivided highways? Even for a somewhat 
experienced mapper like myself, it makes the editing process that much more 
error prone.

-Nathan

Chris Lawrence lordsu...@gmail.com wrote:
On Mon, Nov 18, 2013 at 10:52 AM, Paul Johnson ba...@ursamundi.org
wrote:

 Not a fan.  It greatly complicates things for information that can
either
 be gleaned obviously or is a nice to have.  Having 3+ relations for
 something that isn't fully divided just complicates things, with the
 exception edge case of a relation that starts or ends on a divided
highway.


 On Sun, Nov 17, 2013 at 9:30 AM, James Mast
rickmastfa...@hotmail.comwrote:

 I'm just curious, but what's everybody's opinion on this?  I know
it's
 acceptable for the Interstates (some are setup this way, some
aren't) since
 they are all divided, but what about for US Highways and State
Highways?  I
 know that we want to eventually have the cardinal directions in OSM
for the
 routers so they can properly tell people which direction the of the
highway
 they need to turn onto (like turn left onto Westbound US-30).
 
 Also, on a side note, do you guys think we should remove the
symbol
 tags in the relations from all the Interstates/US highways they show
up in
 at the same time?

 So, let's get this discussion going!


IMO direction-based relations, with correct forward/backward tagging,
are
borderline necessary for directions based on relations to work
correctly in
the US and Canada. That's something that's sorely lacking (along with
exit
numbers and usage of destination tags) in OSRM today.

All we should need is a single super relation for each route, along
with
reasonable numbers of directional relations with way members - since
each
directional relation will have 1/2ish the number of members, there's no
reason to confine them to one per state unless we're doing that to
match up
with Wikipedia articles.

As for symbol tags, I'd vote to transition them to the wiki:symbol
namespace if possible.


Chris
-- 
Chris Lawrence lordsu...@gmail.com

Website: http://www.cnlawrence.com/




___
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] Separate relations for each direction of US State highways.

[Nathan Mills]

They're not at all hard to find in the US. I would wager that fewer than 50% of 
the actual on the ground road routes in the US have any divided segment 
whatsoever.

What exactly is captured by two relations that is not captured by one, however? 
That's the part I'm not understanding. We have tools that (seem to) work fine 
with a single relation for both ways. They can just as easily check a single 
relation for the existence and completeness of component ways with forward and 
backward (or cardinal direction) roles as they can check for the existence and 
completeness of two separate relations and a super relation.

Maybe I missed some earlier discussions on the advantages of the multiple 
relation model?


-Nathan

Martin Koppenhoefer dieterdre...@gmail.com wrote:
2013/11/18 Nathan Mills nat...@nwacg.net

 I'm still confused as to why the consumers of a relation can't use
the
 forward/backward roles of the ways referenced therein rather than
requiring
 completely separate relations. Why do we need two or more relations
plus a
 super relation per road route even for undivided highways? Even for a
 somewhat experienced mapper like myself, it makes the editing process
that
 much more error prone.


if the highway is never divided a single route would be sufficient
(rather
hard to find this situation probably), but if you have routes that even
for
a short way do not share the same geometry it will be easier to
maintain
and to check if every direction has its own relation (and IMHO less
error
prone).

cheers,
Martin




___
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] Locations for State of the Map US 2014

[Nathan Mills]

Sorry, the center of the universe is in Tulsa on the pedestrian bridge across 
the railroad tracks downtown. 

Also, Postgres tells me that the geographic center of the lower 48 is at 
39.5359,-99.1558 (ish)

Yours in precision,
-Nathan

Clifford Snow cliff...@snowandsnow.us wrote:
Just to remind everyone, we have a sign in the Fremont neighborhood of
Seattle that claims it is the Center of the Universe.


On Fri, Nov 15, 2013 at 3:23 PM, Paul Johnson ba...@ursamundi.org
wrote:

 On Friday, November 15, 2013, wrote:

  Seeing as how the “official” location of the lower 48’s centroid is
in
 north-central Kansas, I’d have to dispute your claim that Tulsa is
the
 closest major metro area. Looks to me that Lincoln, Nebraska would
be the
 closest.  There’s also Wichita, Omaha, Topeka, and Kansas City.


 Just going by the claims of some random KDOT sign along US 169
nearish
 Caney, stating it's at the geographic center of the lower 48th.

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




-- 
Clifford

OpenStreetMap: Maps with a human touch




___
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] Freeway directions

[Nathan Mills]

On 10/17/2013 1:03 PM, Richard Welty wrote:

hmmm. we're using exit_to (i think) for off ramps, maybe we need
entrance_to for on ramps

the value would be more or less exactly the text visible on the
signage.



This makes the most sense to me as the solution for the specific use 
case Martijn is asking about, where the tag value will be used as the 
basis for generating directions which the user will expect to be 
consistent with signage. The directional tag on a wayfinding sign at the 
motorway entrance may or may not correspond to the bannered direction of 
the route or route segment.


If my GPS tells me to turn right at the entrance to East Interstate 
Whatever and the sign says North Interstate Whatever, I'm going to be 
confused and wonder if I'm actually making the correct turn. Even more 
so if it's a printed list of directions.


Being able to include control cities as well as cardinality is a nice 
bonus, also.


FWIW, I have in the past typically done one relation for both directions 
with the bannered cardinal direction in the segments' role tag, if it is 
bannered, or forward/reverse otherwise. I settled on that for my own 
work because it plays well with non-motorways that are sometimes divided 
and sometimes not. There's not really any logical reason two relations 
and a super relation couldn't be used in that scenario. It just seems 
somehow less elegant to me to have the extra relations when most of the 
route is undivided.


-Nathan

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

Re: [Talk-us] Route relation pages

[Nathan Mills]

Route relation tagging is explained on the wiki:

http://wiki.openstreetmap.org/wiki/Relation:route#Road_routes

On 6/22/2013 7:21 PM, Evin Fairchild wrote:

I get that you say that keeping wiki pages up to date with the status of
route relations is a pain, but I do hope that this new form of tagging
routes will get explained on the wiki. The wiki is really useful (even
with experienced mappers like me) as documentation for how to use tags,
and it’s very important that it’s explained there. Besides, there are
probably many mappers that may not be aware of this discussion, let
alone the fact that these mailing lists even /exist/.

-Compdude

*From:*Martijn van Exel [mailto:m...@rtijn.org]
*Sent:* Friday, June 21, 2013 8:35 PM
*To:* OSM US Talk
*Subject:* [Talk-us] Route relation pages

Hi,

A few of us were talking about setting up custom highway shield
rendering on the US tile server earlier this week. Because this
rendering relies heavily on route relations (rather than ref tags on the
way, as the default mapnik stylesheet does) we need a better way to
track the status of numbered route relations. The wiki pages are a PITA
to maintain and thus not very reliable.

So I spent a little time on pages that always show the current status of
US numbered route relations, plus some handy links to relation tools.
See for example the interstate relations page here:

http://maproulette.org/relationpages/interstates.html

There is no nice index page yet, for now you have to look for your state
of interest in here:

http://maproulette.org/relationpages/

There are pages for each state, for the US routes, and for the Interstates.

Code (pretty messy) is on github, here:
https://github.com/mvexel/relationpages - if you want to help out and
make this more useful, fork away.

The pages are currently being refreshed every four hours. This could be
increased.

Let me know what you think, how this could be improved, and so on.

--
Martijn van Exel
http://oegeo.wordpress.com/
http://openstreetmap.us/



___
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] Neighborhoods / Zillow

[Nathan Mills]

My city kindly places identification signs along the borders of many of the 
defined neighborhoods. Other neighborhoods are coterminous with a particular 
subdivision.

Still others like midtown are mean whatever the person saying it wants it to 
mean.

The former are reasonable to map. The latter is not.

Ian Dees ian.d...@gmail.com wrote:

On Sat, Jun 15, 2013 at 2:10 PM, Bryce Cogswell bryc...@yahoo.com
wrote:

 Your entire argument is based on the premise that neighborhood
boundaries
 are subjective and unverifiable, and while that may be true for your
 neighborhood it is not true for mine. So why shouldn't I map what I
can
 easily verify on the ground?


What are you using to verify your neighborhood boundaries? Is there
literally a line on the pavement showing the boundaries?




___
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] Removing US Bicycle Route tags

[Nathan Mills]

If we're going for accuracy, corridor proposals should be mapped as a polygon. 
They are area features which may someday become linear.

That said, I don't think that such early proposals belong in the database at 
all.

Paul Johnson ba...@ursamundi.org wrote:

On Fri, Jun 7, 2013 at 5:35 PM, KerryIrons
irons54vor...@sbcglobal.netwrote:

 Again Paul I don’t understand what you are saying: you state “if
AASHTO is
 already referring to them in proposals.”  AASHTO has prepared a
corridor
 plan.  AASHTO does not develop routes.  Route development takes place
at
 the state level by the DOTs, advocates, or other agencies and this is
 always done in partnership with the respective DOTs.  The DOTs are
the only
 ones who can submit an application to AASHTO for USBR route
designation so
 there is no point in “proposing” a route if you are not in
communication
 with the DOTs or at least with the project team developing a route.

[moved a paragraph to better frame my response]


 I am not familiar with the details of all the options for placing a
route
 in OSM but I don’t see how you can put a route into OSM without
choosing
 specific roads.  And just for reference, neither the OpenCycleMap key
nor
 the OpenStreetMap key shows the meaning of the dashed line as
“proposed” so
 there is no way for the general public to know that these routes are
in
 OSM/OCM as proposed.


[and again]


 It would be great if OSM mappers would communicate with state project
 teams when an actual route development project is underway so that
any map
 they generate would be in synch with the project.  I would suggest
that OSM
 mappers contact Adventure Cycling and we can put them in contact with
 project teams.  Otherwise the OSM mapping looks more like “advocacy
 mapping” where an individual mapper is putting out their ideas of a
USBR
 route, not connected with actual efforts to develop and designate a
USBR.


I don't think we disagree for when proposals get past their infancy. 
Where
we do seem to have a disconnect is on corridor proposals, where it
hasn't
narrowed down beyond a broad corridor. This still sounds like a
rendering
issue, not a tagging issue, since the center of the corridor is
presumably
close to or congruent with the routes tagged in this case.  In which I
would really prefer this be addressed as a rendering issue.  I believe
that's the reasonable compromise, to highlight a margin-of-error area
defined by another tag (perhaps corridor_width=* or something
similar).
The way I understand it, the crux of the problem you're pointing out
with
the situation is that the route relations in network=ncn state=proposed
are
too specific.  So, let's address the margin of error issue.  How can we
resolve this amicably so such proposals can be mapped?


 The OSM routes I am asking to be removed are strictly the opinion of
a
 now-banned OSM mapper.  That I can find this person had no
communication
 with local, regional, or state level advocates or government
agencies.  He
 took existing state bike routes and entered them into OSM as proposed
USBRs
 and tagged them with USBR numbers.  Does this meet your definition of
a
 “proposed” route Paul?


Now, anybody who has been following the situation with NE2 for the last
couple years is probably going to be picking up their jaws when I say
this,
but I don't think he was operating entirely in a vacuum, based on the
publicly available information about these proposed corridors in the
areas
I follow (since bicycle tagging is something I do try to help keep
straight
in the areas I follow, odds are I would have been one of the first to
raise
a red flag).  Not every edit needs to come to a consensus, but disputes
do
need to come to something reasonably close to a consensus.  In my view,
this would be one such dispute, and I'd rather not see the solution be
let's tag for the renderer.




___
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] Removing US Bicycle Route tags

[Nathan Mills]

On topic, it seems silly to map (in OSM; obviously maps of such corridors are 
useful in their own right) a proposed route that is nothing more than a 50 mile 
wide corridor in which a route may eventually be routed, prospective USBR 
number or no.

Ian Dees ian.d...@gmail.com wrote:

Let's bring this thread back on topic please.

This isn't a cycle route ownership discussion list, this is an OSM
community in the US discussion list.

Further off-topic posts to this thread will result in moderation.


On Thu, Jun 6, 2013 at 2:37 PM, KerryIrons
irons54vor...@sbcglobal.netwrote:

 Paul I don’t understand what you are saying.  You keep referring to
“have
 it both ways” and “playing both sides of this coin.”  It appears to
be
 insinuating some sort of duplicitousness or nefarious behavior on the
part
 of Adventure Cycling.

 ** **

 Adventure Cycling did not propose the USBR route numbers.  The route
 numbering system and the corridor plan came from AASHTO.  We had
 representation on the AASHTO Task Force but were only one of many
members
 on that group.  You say that trying to provide a clear message to
local
 jurisdictions constitutes censorship.  Based on most of the comments
I have
 seen the OSM community has agreed that bicycle routes should not be
tagged
 as USBRs if they are not USBRs.  Do you disagree with that
consensus?

 ** **

 There is no federal funding for signing USBRs and there never has
been.
 Blaming Adventure Cycling for not securing funding that does not
exist
 seems unfair.  We (and many other national level advocates) did
manage to
 get language inserted into a draft Transportation Bill but then the
2010
 election happened and federal funds for bicycling were cut
significantly.*
 ***

 ** **

 The MUTCD is not the jurisdiction of Adventure Cycling, and they are
the
 ones who came up with the new USBR sign.  All the state DOTs are part
of
 AASHTO and have the ability to comment on new sign designs.  There is
often
 tension between states and national level sign design specifications,
but
 Adventure Cycling played a minimal role in the new M1-9 sign design. 
You
 appear to blame Adventure Cycling for something in which we have no
control.
 

 ** **

 We are working closely with the Oklahoma Bicycling Coalition in
trying to
 get USBR 66 approved, as we are with New Mexico, Arizona, California,
 Missouri, and Illinois.  We’ve had numerous conference calls and
provided
 extensive information to OK (DOT and state level advocates) and have
a good
 relationship with them.  You seem to believe otherwise.

 ** **

 Do you believe that putting maps in the public domain that represent
the
 views and desires of individual mappers is a better approach to
 implementing USBRs than working with the ongoing project teams in the
 individual states?  This appears to be your message.  Adventure
Cycling is
 trying to coordinate with those state level teams and you seem to
view this
 as a power grab.

 ** **

 ** **

 Kerry Irons

 ** **

 *From:* Paul Johnson [mailto:ba...@ursamundi.org]
 *Sent:* Thursday, June 06, 2013 11:16 AM
 *To:* OpenStreetMap talk-us list; Andy Allen
 *Subject:* Re: [Talk-us] Removing US Bicycle Route tags

 ** **

 On Thu, Jun 6, 2013 at 9:49 AM, KerryIrons
irons54vor...@sbcglobal.net
 wrote:

 Actually Paul, people have disagreed.  There are those who have taken
the
 position in this exchange that Who does AASHTO think they are?  I
and
 others have tried to clarify that.

 Then I have to wonder why ACA is playing both sides of this coin, by
 proposing these numbers, then trying to censor them when other people
come
 across proposals.

 The fact that local jurisdictions are confused and distracted by the
 meaning of proposed means that we can reduce confusion by not
tagging
 proposed routes with USBR numbers.  It sounds like you want to blame
those
 who are confused rather than help reduce the confusion.  If we know
from
 experience how best to approach local jurisdictions for their
approval, why
 would we engage in behavior that makes more work in that process?

 Maybe it's not the best approach, since ultimately you're trying to
get
 the proposals retagged for one specific renderer.  Rather than
removing
 information that is useful for people working on the map or trying to
 follow these proposals, we need another tag that hints to renderers
some
 sort of margin of error for proposed routes.  Hopefully Andy Allen
could
 chime in since he's maintaining the OpenCycleMap renderer.

 Adventure Cycling does not seek to monopolize the process, and there
are a
 number of states that have proceeded in gaining USBR designation on
their
 own.  However they do come to Adventure Cycling for advice since few
states
 can claim to be ‘experienced” in the process.  I got involved in this
 because a state group came to me and asked what was going on with a
bunch
 of USBRs tagged in their state on OSM about which they knew nothing. 
That
 does not 

Re: [Talk-us] ref tags

[Nathan Mills]

On 2/13/2013 6:27 AM, Paul Johnson wrote:


Considering that there's nearly 40 in the area within relation 161645 
(Oklahoma), I'd honestly be surprised if there aren't at least 
50-something just within states starting with O.




AFAIK, all of the reservations in Oklahoma were allotted before 
statehood. There is, obviously, some land that has been taken into trust 
by BIA for the casinos. Osage County is the closest thing we have to a 
reservation, but even there only mineral rights are fully native owned. 
There are tribal governments here, but no reservations.


-Nathan

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

Re: [Talk-us] Turn restriction dispute

[Nathan Mills]

On 2/10/2013 10:32 AM, Russ Nelson wrote:

So I have resigned myself to allowing OSM to be a little bit worse
because of him. How many other people have made the same decision? How
much worse is OSM because of NE2? Does this outweigh his positive
accomplishments?


I don't think I'm the only person who decided to basically stop 
contributing and do other things that don't involve butting heads with 
people who think they know ground truth better than people who have 
actually been there.


-Nathan

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

Re: [Talk-us] First bona fide mini-roundabout spotted

[Nathan Mills]

So this is not/should not be a mini_roundabout? It seems a little silly 
to call it anything else, since the city just dug a hole in the center 
of the existing intersection, built a circular curb, and planted a tree:


http://g.co/maps/e2gsv

What about this one? Also a full on roundabout?

http://g.co/maps/d6n74

This looks more like a roundabout to me:

http://g.co/maps/hnbp9

-Nathan

On 5/7/2012 8:46 AM, Paul Johnson wrote:

This one surprised me, was pretty sure that the US didn't have real
mini roundabouts, but I just spotted one in Burien, WA.
http://g.co/maps/afh8m

___
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] First bona fide mini-roundabout spotted

[Nathan Mills]

On 5/7/2012 3:30 PM, Paul Johnson wrote:

On Mon, May 7, 2012 at 1:28 PM, Nathan Millsnat...@nwacg.net  wrote:

http://g.co/maps/hnbp9

All three are roundabouts, yes.


How are you going to properly map the first one? There is no 
channelization or anything that makes the intersection circular. The 
curbs at the four corners have the typical intersection radius. It's a 
square with a circle in the middle. It's also designed for fire trucks 
to roll over the edges, since they can't otherwise fit. (also the one in 
the second link, but it at least pretends to be a ring of driving 
surface around a central point)


-Nathan

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

Re: [Talk-us] Fresno castradal imports

[Nathan Mills]

On 5/4/2012 4:21 PM, Ian Dees wrote:
To the contrary, this whole conversation started because we received 
multiple complaints about this area from mappers who wanted to create 
data in this area but couldn't because of too much data. In that 
sense, this data is already handicapping the usefulness of OSM because 
it's deterring mappers from adding data to the area.


That's a tooling problem, not a data problem.

As an aside, parcel data is completely verifiable. Yes, it's a terrible 
pain in the butt, but it is perfectly possible to look up land records 
and survey the points or do it using a map. I've occasionally thought it 
would be nice to have a plugin for JOSM that could turn a metes and 
bounds description into a polygon.


-Nathan

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

Re: [Talk-us] Addition of building footprints in selected U.S. and Canadian cities

[Nathan Mills]

On 4/2/2012 12:06 PM, Nathan Edgars II wrote:
I offer TIGER as counterevidence. It's imperfect but a great starting 
point for local mappers, especially those without a GPS setup.


This is definitely true for those of us in areas with few mappers. OSM 
would be largely useless here without the TIGER import. Not completely, 
mind you, but it's not much good if it's only got Interstates and US 
highways.


-Nathan

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

Re: [Talk-us] suburban superblocks that nobody wants to survey

[Nathan Mills]

On 3/17/2012 10:20 AM, Reiser, John J. wrote:

What about using county or state-wide parcel data for address points?
Centroid of each real property lot. There's many problems with doing this
for a whole state; NJ has many cases of one house sitting on multiple lots
(old subdivisions of 25'x60', later built as 75'x60' or so without
consolidation of the lots) but for newer subdivisions this would work
fine. NJ data is public domain, don't know about other states and counties.


Where I map, the address point data is indeed public domain (when it's 
available), but it takes ages for the public sites to be updated and 
nobody's terribly interested in fixing that given the budget situation 
they're dealing with. I did an import of address point data for four 
counties in Arkansas, but I couldn't really get consensus that it was 
what the community wanted so I didn't continue beyond that.


-Nathan

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

Re: [Talk-us] suburban superblocks that nobody wants to survey

[Nathan Mills]

On 3/15/2012 4:59 PM, Nathan Edgars II wrote:
lots of driving and all you get is street names, since everything else 
is single-family houses.


And address points, amenities, water features, gates, and whatever else 
might be around, maybe a bridge or a stream or something. Oh, and don't 
forget the streets themselves if aerial imagery is outdated. It's not 
terribly exciting, but it's not terribly hard, either. A few hundred 
house subdivision only takes a couple of hours at most to map and input.


If all I wanted was street names, I'd ask the planning commission.

Besides, there's some amount of fun that comes from beating Google. ;)

-Nathan

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

Re: [Talk-us] suburban superblocks that nobody wants to survey

[Nathan Mills]

On 3/15/2012 6:10 PM, Nathan Edgars II wrote:
How does this work? Do you stop at every house and write down the 
address?


I mount a camera on the windshield and use JOSM's image plugin to place 
them on the track, then it's just a matter of looking at the images and 
identifying addresses, then estimating the position for the address 
point based on the picture and the GPS track.


I first tried to do this with my cell phone camera, but the aperture 
control and dynamic range were poor enough that I could only get about 
half the addresses.  It turns out even a cheap PS works a lot better. 
Obviously the points aren't going to be perfectly placed on the entrance 
to the house, but it's as accurate as anything else those of us without 
pro equipment can really do.


My original tactic was to write down the addresses at the end of each 
block and use interpolation ways. In a lot of subdivisions around here 
that works really well because the city forces them to address (mostly) 
correctly. In other cities where the addressing is less regular it 
doesn't work so well, in that not all addresses in the range actually 
exist. The problem with this method becomes apparent when you find that 
the subdivision you've mapped is too new to have aerial coverage. Too 
much guessing for me.


The really sad thing is when you get to a new subdivision before there 
are any houses. No address points at all in that case. ;)


-Nathan

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

Re: [Talk-us] Problem with an Armchair user

[Nathan Mills]

On 1/17/2012 1:50 PM, Josh Doe wrote:


NE2 is a well known and prolific user. Please be more specific on what
he's doing that you disagree with, and link to specific changesets
and/or objects. I'm assuming you've already discussed this issue with
him and can't come to an agreement.


A well known and prolific user who thinks he knows better than locals do 
how roads they've actually seen in person and he hasn't should be 
tagged. It can be pretty demoralizing to have your hard work messed with 
when the change is the result of something we all agree is a matter of 
opinion.


Personally, I think in those cases without consensus the person who has 
actually been there ought to be the one whose opinion stays in the 
database, but that's just me.


-Nathan

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

Re: [Talk-us] Address improvement through imports?

[Nathan Mills]

On Wed, 2 Nov 2011 09:35:58 -0400, Steven Johnson wrote:

Up to now, weve been talking largely about addresses as point
features. However, one thing I think would be good to have is block
ranges on streets. What I mean is a tag that indicates this is the
1000 block, the 1100 block, the 1200 block, etc. Rather than being a
point feature attached to buildings, it would be a tag associated 
with
the way. It would be much easier to implement, make the map 
renderings

much more presentable at small scales, and provide better address
utility than presently exists.


Do we really want to go down the road of breaking up every way every 
block? It's bad enough trying to make changes to tags for long roads 
thanks to bridges and other breaks.


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

Re: [Talk-us] Address improvement through imports?

[Nathan Mills]

On Wed, 2 Nov 2011 23:12:09 +0100, Frederik Ramm wrote:


Importing more and more data will not make OSM strong. It might make
OSM look useful in the short term but that's cheap usefulness


So you're saying that if I don't go out and spend thousands of dollars 
and countless hours driving every road in the State of Arkansas, I'm 
hurting the community by importing authoritative data? Even though those 
thousands of dollars and countless hours could be spent doing something 
more useful, something for which there is not an existing free and 
accurate data set, like points of interest, bike paths, parks, or 
individual buildings?


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

Re: [Talk-us] Address improvement through imports?

[Nathan Mills]

On Tue, 1 Nov 2011 17:16:11 -0600, Martijn van Exel wrote:

By the way, if that page looks empty, that's because I just did not
find very many resources on the state level which is where I looked.
But at least I put in a link to what appears to be the central
clearinghouse / catalog for geospatial data for each state.


FWIW, the Arkansas address points are supposed to correspond to a 
specific structure (and sometimes even specific units). However, since 
each county collects the data on its own, accuracy varies somewhat, 
although it's generally very good.


I haven't heard any objections over my previous import of three 
counties, so I'll import more if I ever get some free time. It would 
help if upload.py wasn't so finicky at times.


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

Re: [Talk-us] Address improvement through imports?

[Nathan Mills]

On Tue, 1 Nov 2011 19:40:27 -0500, Toby Murray wrote:


It is also data that is time consuming and, for a lot of people,
boring to collect and enter. If you're mapping a shop or restaurant
that you are visiting it's one thing to add in a couple of addr:* 
tags

but to get truly good coverage including residential areas is much,
much harder.


Capturing individual points is rather tedious, but I've had pretty good 
luck getting myself to write down start/end addresses for each side of a 
street I'm driving and do interpolation. With a better camera solution, 
it wouldn't be too hard to do points, but I haven't come up with 
something that's easy, has good resolution, and has good automatic 
exposure. And small.


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

Re: [Talk-us] Address improvement through imports?

[Nathan Mills]

On Wed, 02 Nov 2011 00:02:13 -0400, Richard Welty wrote:

i don't know about that, but i certainly think that the current 
default
mapnik rendering for openstreetmap.org is showing us too much 
addressing
detail. i'm not sure what showing the address interpolation ways here 
really

adds to the mapnik rendering for the average visitor to OSM:


I think it's nice to have, especially at the closest zoom, but I'm not 
entirely sure it's worth the visual clutter.


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

Re: [Talk-us] Interstate Crossovers

[Nathan Mills]

On Sat, 8 Oct 2011 08:44:04 -0400, Anthony wrote:


By that rationale, all government owned land is access=private.


No. In a park, for example, you have a right of access by default. Or 
the flood
control structures around here, where it's perfectly legal to wander 
around all
you like, so long as you don't do it in/on a motorized vehicle. Or the 
vast
majority of BLM land, along with lots of land owned by other 
agencies, at the

federal level.

I agree that access=private doesn't make intuitive sense for government 
owned
land. We do all own it, after all. Having said that, it's pretty silly 
to use
a different tag just because the land is government owned/controlled 
when the

message is otherwise the same.

-Nathan

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

Re: [Talk-us] Interstate Crossovers

[Nathan Mills]

On Sat, 08 Oct 2011 08:40:51 -0500, John F. Eldredge wrote:


The access=emergency tag is documented in the wiki as meaning that
access is permitted for emergency vehicles, and would seem to ideally
fit this situation.  Admittedly, it is documented only if you search
for the word emergency, rather than on the page for the access tag.


I don't think access=emergency maps very well to official use only 
which includes the turnpike authority's maintenance vehicles in my area. 
The locked gates leading into several private-access subdivisions around 
here do have signs posted specifically stating emergency vehicles 
only, and would be more appropriate for that tag, IMO. There are other 
states where the crossovers are signed emergency vehicles only (I'm 
pretty sure I've seen them signed that way before). In those cases, 
access=emergency would also seem appropriate.


This is one of the more annoying aspects of mapping in the US. The 
rules are oftendifferent in every state.


-Nathan


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

Re: [Talk-us] FYI - user Justinb in western GA

[Nathan Mills]

On Sat, 08 Oct 2011 09:28:32 -0500, John F. Eldredge wrote:


That would also work, although causeway implies that the roadway is
raised higher than the terrain to either side of the roadway, whereas
embankment=yes might imply that only one side had an embankment (as 
in

a road built along a cross-slope).  Perhaps we should have
embankment=left, embankment=right, and embankment=both?


Shouldn't an embankment be its own linear feature?

-Nathan

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

Re: [Talk-us] Announcement: Address Improvement project

[Nathan Mills]

On Tue, 04 Oct 2011 22:39:24 -0700, Paul Norman wrote:

In this case the A was part of the house number and 112A had no 
connection

to 112.

What I see around here more often is suite numbers (e.g. 101, 102) 
that are
placed in front of the number when written out, but sometimes are 
placed
after on forms. Eg 
http://www.openstreetmap.org/browse/node/1052967131 where

I mapped it as addr:housenumber=#104-7885


I just use the building's address number in addr:housenumber and write 
something
like 112 West Center Street Suite 700 in addr:full if all the 
entrances are
to the same building and have the same street address but different 
suite numbers,

prefixes, or postfixes.

-Nathan



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

Re: [Talk-us] What does the community want from a US local chapter?

[Nathan Mills]

On Sun, 02 Oct 2011 15:05:22 -0400, Lars Ahlzen wrote:


I completely agree with you, though. The trace from my cellphone is
horrifically bad compared to that of my GPSMap60, so I still use the
latter a lot for mapping.


What phones are you guys using? The TI chips Nokia uses seem to usually
get within about 10 feet or better anywhere where there's a reasonable
view of the sky. That's not to say it's never off, but the outliers are
usually plainly obvious when looking at the track in JOSM.

When I go out and map new subdivisions, there is often dirt work shown
on the aerial imagery that can be used as a reference, along with the
pictures from the phone taken at 5 second intervals, so I can be pretty
certain it's close at worst.

I could do better with a better GPS, I'm sure, but for your typical
suburban-style development the phone seems as good as anything that
doesn't involve post-processing.

If I were trying to map individual structures, it probably wouldn't
be good enough. However, for getting the roads on the map, my N900
works (or more accurately worked, given my recent output) just fine.

-Nathan

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

Re: [Talk-us] Use of ref-tag on state highways

[Nathan Mills]

On Mon, 22 Aug 2011 13:31:51 -0400, Nathan Edgars II wrote:


And what state, despite the implications of some here.


Other than the cases where a state maintains a road as part of their 
route network which is not actually in that state. Or the more common 
case where a state highway is directly atop the state line.


-Nathan

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

Re: [Talk-us] Use of ref-tag on state highways

[Nathan Mills]

On Mon, 22 Aug 2011 15:08:22 -0400, Nathan Edgars II wrote:


In both those (literally) edge cases, the relation will tell all.


So are you volunteering to make relations for every route that has this 
complication?


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

Re: [Talk-us] Use of ref-tag on state highways

[Nathan Mills]

On Mon, 22 Aug 2011 16:52:48 -0400, Nathan Edgars II wrote:


But the same problem exists with county routes along county lines. Do
you think the ref tag for a county route should contain a county
abbreviation?


FIPS codes would be better, as they are a completely unique identifier 
for US counties (and states, but postal codes are more user friendly in 
that case).


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

Re: [Talk-us] Use of ref-tag on state highways

[Nathan Mills]

Before I was too swamped with other stuff to do much OSM work, I was 
using AR XX and OK XX. We've had this discussion before, though. My 
contention is and was  that the state prefix is necessary because there 
are cases of ways belonging to two different networks in (not 
physically, but logically) two different states.


NE2's reasoning here is suspect, anyway. AHTD refers to highways using 
the bare number on their road conditions page. (except for interstates, 
which get an I- prefix)


I'd go on a long rant about how annoying it is that certain people feel 
like they know better than locals how things should be tagged, but we've 
been down that road before and nothing good comes of it.


On Sat, 20 Aug 2011 12:04:26 +0200, Henk Hoff wrote:

Hi all,

To my understanding our tagging-standard for State Highways is 
[STATE]

[NUMBER]

http://wiki.openstreetmap.org/wiki/United_States_roads_tagging#State_Highways
[1]

User Nathan Edgars is now changing all State Highway ref-tags in
Arkansas from AR ## to Hwy ##
Examples:

http://www.openstreetmap.org/?lat=35.4239lon=-93.0561zoom=13layers=M
[2]
 
http://www.openstreetmap.org/?lat=34.015lon=-93.4598zoom=13layers=M

[3]

Ive had contact with NE2 about this, and he basicly responds that the
Arkansas Highway Department calls them Highway ### (or Hwy ###) and
that is how we should tag them. And not AR ###, because thats not
what the routes are actually called.

Well, Im not convinced. Apparently these website also have it wrong
according to NE2:
 http://www.magnoliachamber.com/community/transportation.php [4]
 http://en.wikipedia.org/wiki/Arkansas_Highway_29 [5]

So, what is our (OSM) standard? Do we want to ref-label Arkansas 
State

Highway 27 as AR 27 or Hwy 27?

Cheers,
Henk


Links:
--
[1]

http://wiki.openstreetmap.org/wiki/United_States_roads_tagging#State_Highways
[2]

http://www.openstreetmap.org/?lat=35.4239|+|amp|+|lon=-93.0561|+|amp|+|zoom=13|+|amp|+|layers=M
[3]

http://www.openstreetmap.org/?lat=34.015|+|amp|+|lon=-93.4598|+|amp|+|zoom=13|+|amp|+|layers=M
[4] http://www.magnoliachamber.com/community/transportation.php
[5] http://en.wikipedia.org/wiki/Arkansas_Highway_29



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

Re: [Talk-us] Relation roles

[Nathan Mills]

My personal preference is to use directional roles so that they match 
what is written on signage. It also avoids the inevitable which way is 
forward and which is backward question.


On Wed, 29 Jun 2011 13:44:45 -0400, Nathan Edgars II wrote:

I've started using forward/backward roles rather than
north/south/east/west on relations for state highways, due to JOSM's
relation editor supporting sorting by them and Nakor's tool (which 
was

already less convenient, given that you had to upload to OSM and get
the relation number) being down. I've been leaving U.S. Highways 
alone

(Interstates don't matter either way because they're almost always
dual carriageway), but this means that there's no way to check for
completeness of a relation.

How much uproar would there be if I started changing to
forward/backward roles in conjunction with checking for completeness?
Is there any benefit to the slightly increased amount of information
provided by the directional roles? Are there any other solutions? It
appears from http://josm.openstreetmap.de/ticket/5109 that the JOSM
devs are not interested in supporting directional roles.

___
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] Huge erroneous military landuse

[Nathan Mills]

Sounds like someone's idea of a joke to me. I put the chance of accident at 
about 1 in 1
- Original message -
 On 6/3/2011 9:43 PM, Nathan Edgars II wrote:
  http://www.openstreetmap.org/?lat=41.722lon=-75.094zoom=10layers=M
  I'm currently looking for the source; please report here if you find
  and fix it first.
 
 Oh wow. http://www.openstreetmap.org/user/SimonSquare/edits contains the 
 following:
 landuse=military on the US border
 religion=christian denomination=anglican landuse=cemetery on the UK
 leisure=park on France
 landuse=forest on Canada
 
 All fixed. Could this have been accidental, or is it likely to be 
 deliberate vandalism?
 
 ___
 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 highway classification

[Nathan Mills]

On Sun, 29 May 2011 02:18:09 -0400, Nathan Edgars II wrote:

On 5/29/2011 1:50 AM, Nathan Mills wrote:


It's actually faster to take 441 to Yeehaw and get on the turnpike 
there
when traveling from eastern and southeastern Orlando to points south 
of

Port St. Lucie.

Even with the four-laning of 192?


Yes. That more people don't do it is just them being silly. Good for 
me, I suppose.



Speaking of misclassification around Orlando, why on did you make
Alafaya Trail south of Curry Ford primary?

To distinguish it from the adjacent secondaries, which are similarly
more major than the tertiaries. It's a balancing act, not an exact
science.


Indeed, but by any standard Lake Underhill and Curry Ford are both more 
heavily trafficked and more important than that segment of Alafaya. (for 
now)



We're obviously getting nowhere here. You think trunk should be used
for certain physical characteristics, and other people think it 
should

be used for a slightly different set. I think a more systematic
approach makes sense, classifying the most major routes in the system
as trunk. Again, even under that view, there will be disagreement 
over
where the line is drawn. But you seem to be rejecting that it's even 
a

valid option, like if someone were to insist that primaries must have
at least four lanes, or that tertiaries must have a centerline.


I think that trunk is more useful if it's prescriptive, more along the 
lines of a motorway than primary and below. If we aren't going to do 
that, we need to come up with another value for highway and get it 
rendered by default. It's something that map users expect, and we should 
therefore deliver. Even with your view, physical characteristics are 
part of what makes a particular route important within the network. TBH, 
I think you overuse the trunk tag regardless of physical 
characteristics.


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

Re: [Talk-us] US highway classification

[Nathan Mills]

On Sun, 29 May 2011 03:00:03 -0400, Nathan Edgars II wrote:


Perhaps the best way to handle it would be to render a wider line if
oneway=yes and not lanes=1 or if oneway=no/unset and lanes=4 or more.
Thus divided highways would not need a lane count to be wider, but
undivided roads would need to be tagged as having four lanes.


That seems like it would be a reasonable way to handle it. I'm no 
mapnik expert, but I can see what I can figure out with the installation 
I have locally. I don't think that tagging all divided highways that 
aren't motorways trunk would be a terribly bad idea at first blush, 
though.



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

Re: [Talk-us] US highway classification

[Nathan Mills]

On Sun, 29 May 2011 12:09:30 -0700, Paul Johnson wrote:


I'm thinking the differences between motorways and trunks are minor.
Trunks may have intersections, motorways don't.


That's the simple way to state my opinion. It also seemed to be the 
thrust of most of the discussion on the talk page of the wiki page 
referenced previously as closest to consensus (the page itself just 
references the existence of the two camps and leaves it at that).


In short, my position is simply that an end user expects a trunk road 
to be identifiably different than primary or secondary. That's how it's 
done on other maps, so I don't see why that's such a bad thing here.


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

Re: [Talk-us] US highway classification

[Nathan Mills]

On Sun, 29 May 2011 20:00:33 -0400, Nathan Edgars II wrote:

On 5/29/2011 5:16 PM, Paul Johnson wrote:

subtle mass vandalism


This is why I ignore Paul.

Though I really wonder about this edit:
http://www.openstreetmap.org/browse/way/14751094/history


Using your standard, there's nothing to wonder about. OK-66 is fairly 
heavily traveled by people who don't want to pay the exorbitant tolls to 
get in/out of Tulsa every day. I don't specifically recall if it's an 
expressway that far north or not; it is at least up to Claremore. I 
wouldn't call it a trunk if it's not divided, but it's been the better 
part of a decade since I've driven it past Claremore, so I defer to 
people who have actually been on the road in question more recently than 
I. FSM knows the aerial imagery around here is outdated, to put it 
mildly.


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

Re: [Talk-us] US highway classification

[Nathan Mills]

On Sat, 28 May 2011 01:36:00 -0400, Nathan Edgars II wrote:



I mean best route, period. There's no diagonal Interstate there.


US-71 to I-44 to I-40 is faster. Not really a route I'd enjoy, but 
still faster.


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

Re: [Talk-us] US highway classification

[Nathan Mills]

On Sat, 28 May 2011 15:19:03 -0400, Anthony wrote:

In my experience the difference between primary and trunk is 
generally

very minor, to the point where I'm not sure there'd be any advantage
at all in a router using it as a hint.

But maybe that's just because the places where I use OSM are mapped 
wrong.


Using NE2's criteria, trunk is not really any different from a routing 
standpoint than primary. Using mine, trunk is something that would be 
primary if it weren't a physically better sort of road, so should be 
preferred over a nearby primary if the distances are similar. I'm 
harping on physical characteristics for this one particular tag because 
I think without that as a differentiator, it's basically useless fluff 
we shouldn't be using at all because primary already covers that usage.


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

Re: [Talk-us] US highway classification

[Nathan Mills]

On Sat, 28 May 2011 20:54:07 -0400, Nathan Edgars II wrote:


You described your criteria, but did not explain how trunk is more
appropriate than primary for a two lane rural highway between two
small-to-tiny cities. If you use trunk for that, there is no way to
describe (in a way that shows up on the tiles) a road which is not a
motorway but is better than the typical rural highway.


There are many types of roads that it's not possible to describe. How
do you tag an unpaved classified road so the map shows that it's
unpaved (this is very common in the third world, but also occurs in
extremely rural areas of the US)? You don't.


Don't let the perfect be the enemy of the good, my friend. It's 
nonsensical to say that just because there are other roads that can't be 
adequately described (few and far between in my experience, but perhaps 
more common out west than I'm aware) we should waste trunk on US 
highways that could be adequately described with primary.





I also upgrade major state-numbered highways from secondary to
primary. This leaves more breathing room in secondary and tertiary 
for

the lesser roads.


As makes sense if the highway is the most direct non-Interstate,
non-trunk route between two regionally important cities. Why would 
trunk

be used for the same thing? That's what I've been trying (apparently
rather poorly) to get at.


I understand your assumption - that trunk is only to be used for
surface expressways. I simply disagree.


So you continue to assert that trunk is most useful if it essentially a 
duplicate of primary?


Take, as an example, US 84 in western Alabama. Why on earth did you 
change it to trunk when it's a terribly substandard road that isn't even 
a major route between cities of any real size? The westernmost couple of 
miles in Alabama were being upgraded last I was there, but the rest of 
it from Elba on west is pretty bad, excluding the bypasses, of course. 
There is no reasonable standard that could have it classified the same 
as 231 between Dothan and Montgomery or even 280 between Birmingham and 
Columbus, GA, now that it's almost 100% upgraded and almost all of the 
towns are bypassed. It makes zero sense to a user of the map. (of which 
I count myself..I've been eating my own dog food for a few years now, 
which is why I care in more than an abstract way)


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

Re: [Talk-us] US highway classification

[Nathan Mills]

On Sat, 28 May 2011 21:30:50 -0400, Anthony wrote:


Say, Dothan, Alabama to Hattiesburg, Mississippi, avoid motorways.
What should the router take?


In that particular case, it should in fact take US-84. (US-231 to I-10 
to US-98 would in fact be faster; I know this having taken both routes, 
but you said avoid motorways) But US-84 ought to be tagged primary for 
the reasons I previously stated. Trunk is useless if it describes the 
same thing that primary does. Primary means (at least according to most 
of the wiki pages) the primary non-motorway route between two cities. It 
does not imply any particular quality of road. That seems perfectly 
applicable to US-84 in most of central and western Alabama.


Another example is US-71 between Fort Smith and Texarkana. It is in 
fact the fastest route between Fort Smith and Texarkana, but it is 
terribly slow going. The fact that it is the fastest route between those 
two regionally important cities is adequately described by primary. Why, 
then, are we wasting trunk on something like that? Trunk seems more 
appropriate for OK-51 between I-35 and Stillwater or the non-turnpike 
(and non-city) sections of US-412 between Tulsa, OK and Springdale, AR 
where it has a meaning above and beyond what primary means.


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

Re: [Talk-us] US highway classification

[Nathan Mills]

On Sat, 28 May 2011 21:51:31 -0400, Nathan Edgars II wrote:


It's been rebuilt as a good-quality four-lane in Mississippi, eastern
Alabama, and Georgia. Alabama has been a little slower at four-laning
than its neighbors, but US 84 in western Alabama is still a direct
route connecting the four-laned portions.


More than a little slower. There's perhaps 20 miles of four lane in 
Alabama west of Enterprise. Maybe 30 if they've completed the far 
western section they were working on last time I was through there. As I 
mentioned in another post, it's faster to detour to I-10. And once 
again, the 'direct route' issue is adequately communicated with the 
primary tag.


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

Re: [Talk-us] US highway classification

[Nathan Mills]

On Sat, 28 May 2011 22:39:51 -0400, Anthony wrote:
On Sat, May 28, 2011 at 9:47 PM, Nathan Mills nat...@nwacg.net 
wrote:

Primary means (at least according to most of the wiki pages)
the primary non-motorway route between two cities.


Any wiki pages that say that are clearly wrong.  Trunk is the primary
non-motorway route between two cities.  Yes, it's dumb terminology,
but it's too late to fix that.


If it were clearly wrong, we wouldn't be having this discussion.

Another example is US-71 between Fort Smith and Texarkana. It is in 
fact the
fastest route between Fort Smith and Texarkana, but it is terribly 
slow
going. The fact that it is the fastest route between those two 
regionally
important cities is adequately described by primary. Why, then, are 
we

wasting trunk on something like that?


Do you agree that a road which would be a trunk in one area of the
world might not be a trunk in another area?  Or do I first have to
convince you of that?


I said as much previously. Obviously, I'm only considering the US, 
given that this is talk-us. I guess I'm just failing to see what use 
trunk is if it's essentially interchangeable with primary.


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

Re: [Talk-us] US highway classification

[Nathan Mills]

You agree that if a router has two possible roads to take between two
cities, and one is a trunk, and one is a primary, and all other 
things

are equal, that the router should choose the trunk, right?  Doesn't
that make trunk, by definition, the primary non-motorway route 
between

two cities?


Only if trunk has a meaning that implies that a road tagged trunk is 
somehow better than a road tagged primary, which it apparently does not, 
at least in some people's minds. If you're going to waste trunk on curvy 
two lane roads, a router may as well use distance or maxspeed as a 
better metric. As it stands, some of us are using trunk as more of a 'I 
know it when I see it' thing than something useful for routing purposes 
like motorway.


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

Re: [Talk-us] US highway classification

[Nathan Mills]

On Sat, 28 May 2011 23:00:11 -0400, Anthony wrote:


Instead of giving me hypothetical if..then answers, can you give me a
straightforward answer?


You're trying to get an exact answer to something that isn't an exact 
science, so no. I'm allowing for the fact that there may be a situation 
in which trunk should be applied to a two lane road because not doing so 
would misrepresent the area to viewers of the map and routing engines 
more than not using it would. I don't have personal experience with 
every road in the US, after all. In the cases I've personally seen, I 
think the roads could have been adequately described with primary.


Obviously, my preference would be that trunk only be used for roads 
with more than two lanes and a barely-existent shoulder, but barring 
that I would like it to mean 'very important road that is not a 
motorway.'


And yes, as it presently stands, a routing engine would probably be 
better off using the two foot shorter primary than the two foot longer 
trunk, given that we have a bunch of roads tagged as trunk that are no 
more suitable for long distance travel than most roads tagged as 
primary.


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

Re: [Talk-us] US highway classification

[Nathan Mills]

On Sun, 29 May 2011 00:13:33 -0400, Anthony wrote:


If you want to get people to tag more than two lanes and a
barely-existent shoulder, I think you'd have much more success
creating tags for those features than convincing people that their
area of the country isn't allowed to have any trunks.


That's quite the misrepresentation of what I'm saying. Again, my point 
is that trunk is much more useful (especially to people using rendered 
mapnik tiles) if it is mainly restricted to four lane divided sorts of 
roads here in the US. You can bring up all the corner cases you want, 
but that doesn't change the fact that using trunk to describe roads that 
can adequately handled with primary (for all purposes, no less!) means 
that it's simply not possible to represent that with any tagging simple 
enough to be reliably used everywhere.


US-441 between St. Cloud and Yeehaw Junction could easily be trunk by 
NE2's definition (and apparently yours, although you haven't really 
indicated how exactly it should be used), but is also adequately 
described by primary, and handily enough renders rather well.


Yeah, we shouldn't tag specifically for the renderer, but we shouldn't 
waste tags either. Nor should we avoid being mindful of how things are 
rendered.


Perhaps if you explain it very slowly, you can help me understand why 
primary isn't emphatic enough in the cases that have been mentioned. Or 
how it is that a routing engine would be confused by them being tagged 
as primary rather than trunk (as many of them were for years before NE2 
went off and changed them). As I said, I see those changes as making the 
map less useful to someone reading it, not more useful.


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

Re: [Talk-us] US highway classification

[Nathan Mills]

On Sun, 29 May 2011 00:13:33 -0400, Anthony wrote:


convincing people that their
area of the country isn't allowed to have any trunks.


Also, why is this any worse than not having a motorway? I don't think 
the folks in Newton County Arkansas care a whit whether the main road 
through their very rural county is trunk or primary or secondary or even 
tertiary. The roads in that county just aren't major roads. That's not 
disparaging the people, it's just a statement of what is.


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

Re: [Talk-us] US highway classification

[Nathan Mills]

On Sun, 29 May 2011 00:57:30 -0400, Anthony wrote:


That's quite the misrepresentation of what I'm saying.


It was an exact quote.


You may have heard of the concept of the pull quote. It describes 
using partial quotations to misrepresent someone else's position.



Again, my point is
that trunk is much more useful (especially to people using rendered 
mapnik
tiles) if it is mainly restricted to four lane divided sorts of 
roads here

in the US.


And my point is 1) that you aren't going to convince people to do
that; and 2) that if you could convince people to tag the number of
lanes, you'd be better off having them use a tag which says the 
number

of lanes.


I find it difficult to believe that you object so strenuously to making 
it simple to tag one of the main things an end user of a road map 
desires to know when looking at said map. Is it a practical you can't 
get people to agree to that objection, or a I don't think it should be 
done that way objection?


Once again, there is, to most non-mapgeeks a class of road which is 
less than a motorway, but better than all other classes of road. In my 
part of the country, most people call it an expressway. This should be 
easy to tag, so that the map is most useful to end users (and simple to 
edit for casual editors, who you're almost certainly not going to 
convince to tag width and lane count on every edit). Trunk seems to fit 
that bill, and is used that way already in many areas. It was used that 
way in a lot more areas until one specific editor decided he wanted to 
edit roads in places he's never even been to use that designation. I 
can't think of a downside to using it that way.


What advantage does trunk have over primary in any of the mentioned 
examples?


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

Re: [Talk-us] US highway classification

[Nathan Mills]

On Sun, 29 May 2011 01:04:24 -0400, Anthony wrote:
On Sun, May 29, 2011 at 12:59 AM, Nathan Mills nat...@nwacg.net 
wrote:

On Sun, 29 May 2011 00:13:33 -0400, Anthony wrote:


convincing people that their
area of the country isn't allowed to have any trunks.


Also, why is this any worse than not having a motorway?


Why is what worse than not having a motorway?


Not having any trunks. Why is that worse than not having any motorways?


I don't think the
folks in Newton County Arkansas care a whit whether the main road 
through
their very rural county is trunk or primary or secondary or even 
tertiary.


They do if they're looking at a map, and none of the roads are drawn,
because tertiaries aren't drawn at that zoom level.


I don't think it's a problem if rural areas have a low density of roads 
drawn at low zoom. That's how most every map made is drawn. (Yes, 
tertiary may have been taking it too far, but for reasons of rendering, 
not the importance of the road)


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

Re: [Talk-us] US highway classification

[Nathan Mills]

On Sun, 29 May 2011 01:00:25 -0400, Nathan Edgars II wrote:

On 5/29/2011 12:37 AM, Nathan Mills wrote:
US-441 between St. Cloud and Yeehaw Junction could easily be trunk 
by

NE2's definition

Nope, since any through traffic will be on the Turnpike. US 441
serves mainly only local and toll-avoiding traffic, and the latter is
better-off cutting east to I-95 via US 192.


It's actually faster to take 441 to Yeehaw and get on the turnpike 
there when traveling from eastern and southeastern Orlando to points 
south of Port St. Lucie. Once again, this is a drive I take 
semi-regularly. Similarly, from northeast Orlando out to Cocoa, 520 is 
faster than slogging all the way down to 528 on 417, although almost 
nobody goes that way. (or at least they didn't when I was driving it 
somewhat regularly..it's been some years at this point)


On all the roads I've mentioned until this post (exclusive of US-71), 
most of the traffic seemed to be local and there was very little 
traffic, local or through. So that's not really something you can point 
to to say aha, this should be trunk because it's an important through 
route on the particular roads I'm discussing. I don't claim to know 
about roads I haven't personally driven since I haven't actually been on 
them. If you can divine from the Internet that a given road has lots of 
through traffic, that's fantastic for you.


Speaking of misclassification around Orlando, why on did you make 
Alafaya Trail south of Curry Ford primary? Even with the extension 
(Innovation way) to 528, it's still mostly local traffic. Curry Ford and 
Lake Underhill are much more important (and busy) roads in that part of 
Orlando and carry more through traffic. That may change if they ever get 
the 2 lane segment 4 laned, but that hasn't happened yet, unless it was 
the fastest construction project evar. (I have friends that live in 
Stoneybrook whom I visit at least once a year; last time was admittedly 
last Christmas. I can only put so many miles on the car every year :P)


On Sun, 29 May 2011 01:16:17 -0400, Nathan Edgars II wrote:


Try expressway=yes or access_control=partial. But make sure it's an
expressway, not just a four-lane with unlimited driveway access. You
may have to look through DOT records to find out which one it is.


I don't think most road map users care whether it's a literal 
expressway in the sense of limited access or not, so long as it is 
practically-speaking indistinguishable from an actual limited access 
road. This is why I'm agitating for a tag that captures that use. More 
technical tagging is, of course, quite welcome, but we need a way to 
represent something as basic as this on the map. I think the easiest way 
is to use the trunk tag because I don't see the way you're using it as 
particularly useful since the same information could be conveyed with 
primary, even if a nearby road has to be demoted to secondary, as most 
state highways already are or should be, IMO.


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

Re: [Talk-us] US highway classification

[Nathan Mills]

On Fri, 27 May 2011 12:17:53 -0400, Nathan Edgars II wrote:

The 'major intercity' road ought to be tagged as primary unless 
there's
a specific reason to upgrade, IMO. That leaves the data more useful 
to

end users.


Actually that leaves it less useful for users in cities, as then
there are only two classifications for non-intercity highways,
secondary and tertiary.


Uh, what are you on about? Motorway itself doesn't necessarily imply 
intercity or intracity, and neither do any of the other classifications. 
I can think of several intercity county roads that ought not qualify for 
anything beyond unclassified (they're old routes with several bypasses) 
and several intracity routes that definitely ought to be classified as 
trunk or motorway. It comes down to how the highway is built and what 
the highway is.


Also, I don't know how major a road between Dumas, TX and Texline, 
TX
really is. If it weren't a US highway, I'd probably demote it all 
the

way to secondary.


It's on the National Highway System, meaning the FHWA considers it to
be a major road. It's probably the best route between Kansas City and
Albuquerque.


I'm going to assume you mean 'best non-Interstate route'. Most of it 
isn't even four laned yet, although Texas has some of it under 
construction. Same goes for the segment between Clayton, NM and I-25, 
although there New Mexico is upgrading the road to four lane divided in 
one whack. Which, as an aside, makes for one incredibly long 
construction zone.


Talking solely about relatively rural areas, it seems to me that by 
default the best non-motorway route between two regionally important 
cities should be tagged primary unless there's a reason to upgrade it to 
trunk based on the physical characteristics of the road. To me, trunk 
implies a divided 4 lane at worst, or arguably including a true super 2, 
of which I've seen a couple in Kansas (I think one of Oklahoma's 
turnpikes might also be a true super 2, but I haven't driven it 
personally). It just makes sense to me based on the way we build our 
roads here in the US.


I maintain that tagging both two lane and four lane divided roads as 
trunk (not to mention the cases where it's used for a 
not-quite-a-motorway) makes the map much less useful for planning a 
route at a glance. Obviously, software can take the maxspeed and lanes 
tags into account when available but if I'm, for example, looking at 
some rendered tiles, that information is not available.


We already have four other tags to indicate importance in a route 
network, so I don't see the downside to limiting trunk to roads where 
the physical characteristics imply a higher classification, as we 
already do with motorway.


-wierdo

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

Re: [Talk-us] US highway classification

[Nathan Mills]

On Fri, 27 May 2011 21:26:53 -0500, John F. Eldredge wrote:


I have driven on quite a few highways here in the USA that vary, mile
by mile, in the number of lanes, how well they are graded, whether or
not driveways connect directly to the highway, etc.  This usually
reflects their having been upgraded one piece at a time.  Sections
that pass through difficult terrain are often the last to be 
upgraded.

Of course, whether or not a local politician has friends or relatives
in the road-construction business makes a difference as well.

If you classify these highways according to their importance to the
transportation grid, then long sections, with variable physical
characteristics, will be classified the same.


Obviously some element of judgment is required no matter what. As you 
correctly point out, there is substantial variability in how roads are 
built in the US. If the substandard section is small, one could perhaps 
overlook it. If the upgraded section is small relative to the rest of 
the highway, perhaps it should not be used in determining the 
classification of the road. The intent here is not to classify solely on 
physical characteristics, but there is clearly a difference in the 
suitability of a road for long distance travel depending on whether it 
is 2 lane or 4 lane divided, and that should be reflected on the map, 
not just in tags.


I wouldn't downgrade a rural Interstate from motorway just because 
there are two driveways in three hundred miles that might see use three 
or four times a year. Nor would I upgrade a hundred miles of US highway 
from primary merely because of a mile of divided highway and one grade 
separated interchange.


Besides, if importance to the route network is the only consideration, 
we ought not be using trunk at all or all US highways ought to be 
classed as trunk. It seems obvious to me that neither can possibly be 
the sole consideration.


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

Re: [Talk-us] County road network relations

[Nathan Mills]

On Mon, 11 Apr 2011 13:47:02 -0400, Phil! Gold wrote:

In my opinion, there's too much variation in how each state organizes 
and

numbers its state-and-lower roads to make a uniform, US-wide rule.  I
would say that state highways should be network=US:ST (where ST is 
the

two-letter state abbreviation), and anything further (county roads,
Pennsylvania's primary and secondary state roads, California's
multi-county roads, etc.) would be US:ST:whatever, where the
whatever is up to the mappers in that state (and, hopefully,
documented on that state's page on the wiki).


Without some sort of general agreement between areas (as much as is 
possible, anyway) it will be very difficult for renderers to do useful 
things with county road relations. It would be nice if it could be 
boiled down to a few different classes of tag for various states. 
California and any states with similar schemes might use US:ST:[A-Z]. 
States with single-county road networks would all use US:ST:County. That 
way we can at least say that all states that number county roads in the 
same way should be tagged in the same way.


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

Re: [Talk-us] School bus routes?

[Nathan Mills]

On Sun, 10 Apr 2011 20:06:06 +, j...@jfeldredge.com wrote:

How would deleting a way that wasn't part of a relation damage a
relation linked to some other way?  Using that logic, every time a 
way

is deleted, every relation not linked to that way would be damaged,
regardless of where in the world the relation was located.


Combining the two ways would cause the relation to no longer reflect 
reality.


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

Re: [Talk-us] School bus routes?

[Nathan Mills]

On Sun, 10 Apr 2011 20:19:19 +, j...@jfeldredge.com wrote:

You had stated that the two ways were identical, other than the
relation, so deleting the way that wasn't linked to the relation 
would

still leave the relation referring to the same way, in the same
location, as before.  So, the relation would still have the same
correspondence to reality that it had before the non-linked way was
deleted.



I didn't state anything of the sort. NE2 did. ;)

If you combine two ways, the combined way is longer than the original 
way. If said original way is part of a relation, that relation will then 
be incorrect, as it will extend too far in some direction.


This actually happens pretty regularly with ref tags.

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

Re: [Talk-us] School bus routes?

[Nathan Mills]

Assume that there is a state highway routed through a city. At an 
intersection within the city, the route turns in some direction or 
another. For that to be accurately reflected, the ways must end at the 
intersection. If the constituent ways extend through the intersection, 
as they might if someone combined ways without realizing the relation 
was there, the data will be incorrect as to the routing of the state 
highway. It would have stubs.


On Sun, 10 Apr 2011 20:29:47 +, j...@jfeldredge.com wrote:

How would the insertion of these new nodes cause a relation already
linked to the way to no longer reflect reality?  Does a relation
include a list of all of the nodes in the related section of the way?
Does any insertion of a new node, say to make a roadway curve on the
map correspond more accurately to reality, break any relations linked
to that way?


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

Re: [Talk-us] County road network relations

[Nathan Mills]

On Sun, 10 Apr 2011 20:14:18 -0400, Nathan Edgars II wrote:


It's almost like they defined super-groups of counties identified by
those letters. I'll have to crunch that table to see if that's the 
case

so we could have network=US:CA:S + ref=CR S18. Maybe add an
is_in:county tag to the individual segments to avoid losing that
important info.


How about simply network=US:CA:CR?


That's all well and good for California, but what about states like 
Arkansas (and Florida, IIRC) where the county road system is not unique 
to the entire state. I suppose in that case, US:AR:[County] would be the 
appropriate network value? US:AR:CR would be meaningless.


___
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] Bike / Pedestrian directions on the MQ Open sites

[Nathan Mills]

Paul Johnson wrote:
 I'd be more inclined to believe this if you weren't the only one arguing
 this and you had some local knowledge, and similar local/express
 arrangements are tagged in the same manner in Texas when I was looking
 for how to tag that section.
As you're aware, I disagree with the motorway_link tagging, just not strongly 
enough to start an edit war over it. In the specific area under discussion, 
most of Skelly is not in fact used functionally as a motorway_link.
Also, I have seen several locations in Dallas that have a similar real-world 
use that are not tagged motorway_link.
JMHO,
-Nathan___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] [Imports] Arkansas address point import

[Nathan Mills]

On Wed, 2011-01-26 at 19:56 -0500, Mike N wrote: 
 On 1/25/2011 12:14 PM, Nathan Mills wrote:
  I propose to import the situs address points available from Geostor
 
 In considering future synchronization cycles with point data, 
 several cases can be seen:

Yes, future synchronization could get hairy, especially if for some
reason I'm not around to make the future updates. I plan to keep a copy
of the current dataset around and also make a note of the largest
objectid thus far uploaded, so that when counties are added in the
future, it should be trivial to create an OSM file for the new points.

I checked for existing Karlsruhe schema address points in Arkansas.
Presuming the Cloudmade extract is not missing any, there are precisely
10, of which only 6 are overlapping, all in Pulaski County.

One is missing from the database on GeoStor, oddly enough.

Anyway, it's a small enough number that I can deal with those manually.

If there are no objections, I'm going to go ahead and upload points for
Washington County later tonight or tomorrow and see how it goes. If
nobody finds any problems, I'll upload the rest as time permits.


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

[Talk-us] Arkansas address point import

[Nathan Mills]

I propose to import the situs address points available from Geostor
(http://www.geostor.arkansas.gov/G6/Home.html?q=situs+address). I have
confirmed with that this data is public domain, and spot checks of its
accuracy in areas I'm personally familiar with show that the vast
majority of the points are of high accuracy.

There are some in rural areas that could use realignment, but those that
I've seen all fall on the correct property, even if the point is not
directly on the structure, so they're still useful for most purposes.

I've created a translation for ogr2osm and processed a couple of
counties into osm files as a test:

Washington County: http://www.nwacg.net/washar_addresses.zip (2.6MB
zipped, 36MB expanded)
Sebastian County: http://www.nwacg.net/sebar_addresses.zip (2MB zipped,
25MB expanded)

I'm open to suggestions as to how to better tag the points if anyone has
any ideas.


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

Re: [Talk-us] [Imports] Arkansas address point import

[Nathan Mills]

On Tue, 2011-01-25 at 13:46 -0500, Mike N wrote:

I'd recommend creating a page on the Wiki for this import - link to 
 it from the base Arkansas page 
 http://wiki.openstreetmap.org/wiki/Arkansas ; new local mappers should 
 arrive here to learn about past and future mapping projects.

Done
http://wiki.openstreetmap.org/wiki/Arkansas_Situs_Address_Points_Import
and done.

It's handy to use a dedicated OSM account for import - this can help 
 with troubleshooting or syncing future imports.
 

I'll create one and use it for any import, and will document that on the
wiki page after creation.

The address points will be more accurate than many of the roads. 
 This could result in confusion for beginners when roads drift through a 
 line of address points, but they should be able to see from aerial 
 imagery that the road needs to be realigned.   And there will be an 
 ongoing effort to update and align the roads based on either TIGER 2010 
 or the Arksanas geo clearinghouse.

I could do a mass import of the roads from the Arkansas Centerline File,
which is also public domain. ;) (I'm not serious, that would be a
nightmare)

  I'm open to suggestions as to how to better tag the points if anyone has
  any ideas.
 
I spot checked in one location, and I'd say it is tagged correctly. 
   One point for discussion:
 
 source= for each data point.   One might argue that the source= is 
 only required on the changeset comment.   This avoids the confusion  of 
 someone correcting an address point but not updating the source= tag. 
 That also saves space in the database.   The changeset comment can 
 contain a link to the import page.

That works for me.

I see that the addr:street names have been un-abbreviated, so that 
 they should match the new roads when they are updated.



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

Re: [Talk-us] Minimum standards for motorways?

[Nathan Mills]

So if a motorway became sub-standard through a small city with a low speed 
limit, but still limited access, you think tagging it as secondary or tertiary 
would be appropriate? Seems to me that it's functioning as a motorway 
regardless of the speed limit.
I-93 is a pathological case, and since it doesn't even maintain 4 lanes, I'd 
argue that it should be tagged trunk in that case. US-78 through tupelo is a 
case where dropping below motorway wouldn't make sense, as it maintains grade 
separation and all other aspects of a motorway except shoulder width and a 
lower than expected speed limit.
- Original message -
 On 1/1/11 5:47 AM, Nathan Edgars II wrote:
  Question: what do people think about minimum standards for tagging
  something highway=motorway? In other words, would it be reasonable to
  tag a highway as trunk rather than motorway because it has no
  shoulders or a low speed limit (40 mph)?
 with the low limit, it might even be sub-trunk.

 richard


 ___
 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

[Talk-us] help mapping construction

[Nathan Mills]

I ran into a situation today that I can't figure out how to correctly
map. The westbound carriageway of I-40 in the easternmost few miles of
Oklahoma is closed for construction and the westbound lanes are now
routed on the eastbound carriageway.

What's the best way to map this? Leave both carriageways alone and just
mark them as construction=minor? Or should the westbound carriageway be
marked as highway=construction and construction=motorway, the oneway tag
removed from the eastbound carriageway, and the existing ramps mapped?

Something else entirely? Any help would be appreciated.


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