Re: [Talk-us] Recent Trunk road edits

[Evin Fairchild]

I totally support reverting Floridaeditor's changes in order to restore all
these divided highways to trunk status. I believe that floridaeditor has
been given the opportunity to participate in this discussion, right?

On Mon, Sep 28, 2020, 3:54 PM Jack Burke  wrote:

> On Mon, Sep 28, 2020 at 3:15 PM Evin Fairchild 
> wrote:
> >
> > We've always tagged non interstate freeways as motorways. They are often
> designed to interstate standards and there is literally no distinction
> between them and interstate freeways except that there's no interstate
> shield.
> >
> > As for Floridaeditor's edits, I noticed him doing this awhile ago, but
> didn't really feel like doing anything. Glad someone is sending him and
> trying to get this resolved. Many of his downgrading from Trump to primary
> were completely unjustified.
>
>
> Throughout this entire discussion, it sounds like there's pretty good
> agreement that trunk is perfectly acceptable to use as a road
> classification in OSM for the eastern US, and at least some general
> agreement that the examples I cited are reasonable examples of trunk
> roads?  Am I mis-interpreting anyone?
>
> And also, that I'm not the only one who's very much disturbed by
> floridaeditor's changes?
>
> Does anyone have a strong problem if I continue going through Georgia
> and reversing most of his trunk-to-primary changes?
>
> --jack
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Recent Trunk road edits

[Evin Fairchild]

Oh lol, I didn't even realize my phone autocorrected trunk to Trump. Oops!
xD

On Mon, Sep 28, 2020, 12:21 PM Kevin Kenny  wrote:

> On Mon, Sep 28, 2020 at 3:15 PM Evin Fairchild 
> wrote:
> > Many of his downgrading from Trump to primary were completely
> unjustified.
>
> Oh, $LC_DEITY, autocorrupt in 2020!  (I'd have loved to have
> downgraded Trump in the primary, but this year he was unopposed.)
>
> Yeah, I know, you meant 'trunk'.
> --
> 73 de ke9tv/2, Kevin
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Recent Trunk road edits

[Evin Fairchild]

We've always tagged non interstate freeways as motorways. They are often
designed to interstate standards and there is literally no distinction
between them and interstate freeways except that there's no interstate
shield.

As for Floridaeditor's edits, I noticed him doing this awhile ago, but
didn't really feel like doing anything. Glad someone is sending him and
trying to get this resolved. Many of his downgrading from Trump to primary
were completely unjustified.

On Mon, Sep 28, 2020, 11:57 AM Matthew Woehlke 
wrote:

> On 28/09/2020 12.27, Paul Johnson wrote:
> > On Mon, Sep 28, 2020 at 11:07 AM Matthew Woehlke wrote:
> >> On 28/09/2020 11.42, Jack Burke wrote:
> >>> I'm willing to bet that most OSM editors who drive on either of those
> two
> >>> will think "this is a great freeway, just with occasional traffic
> >> signals."
> >>
> >> That's an oxymoron. Freeways are, by definition, limited access (no
> >> crossing intersections, period) and do not have (permanent¹) signs or
> >> signals to halt traffic. IMNSHO, if it has traffic lights, stop signs,
> >> or the possibility of vehicles suddenly driving *across* the way, it
> >> isn't a freeway.
> >
> > True, but highway=trunk can mean either expressways (think like freeways
> > that have some or all at-grade intersections; note that having
> > freeway-style ramps in between junctions doesn't make it a
> > highway=motorway), or single-carriageway freeways.  In both cases, they
> > tend to get built as an incremental case to building a full motorway, but
> > are not yet motorways.
>
> We're getting dangerously into the territory of words with ambiguous
> meanings. Note https://en.wiktionary.org/wiki/freeway, especially the
> first definition. Note also my point was about "freeways", not
> highway=trunk. Many in the US would consider "freeway" and
> highway=motorway to be nearly synonymous. (The "nearly" is when we start
> talking about non-interstate limited access.)
>
> I did later state that limited access is *not* a requirement for
> highway=trunk.
>
> Also, Jack has clarified his usage as "artistic"...
>
> > That's not to say there aren't non-interstate highways that meet these
> >> definitions.
> >>
> >> But... is it a highway=trunk? *I* don't see where the wiki excludes the
> >> possibility. (It does, however, seem to me that only *actual* interstate
> >> freeways should be highway=motorway in the US.)
> >
> > That's not true at all...
>
> Citation needed. I don't think that's been established (although we're
> getting pretty off-topic...). The *converse*, sure (interstate =/>
> motorway), I'll concede that.
>
> > [...] the transitions to where an interstate ends and it continues as
> > another kind of highway past the last exit before a junction,
> I would question whether those should be highway=motorway. (Yes, I'm
> looking at https://www.openstreetmap.org/way/98245488 and surrounding,
> possibly as far north as https://www.openstreetmap.org/node/41485037.)
>
> --
> Matthew
>
> ___
> 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] place=neighborhood on subdivisions?

[Evin Fairchild]

I totally agree with Minh here. I always thought that it was standard
parctice in OSM to add the name tag to a landuse=residential way that
encompasses the subdivision. Subdivision names aren't always used in common
parlance (especially if it's a smaller subdivision) so most people wouldn't
necessarily consider the subdivision name to be the name of the
neighborhood that they live in.

On Thu, Sep 24, 2020, 12:44 AM Minh Nguyen 
wrote:

> Vào lúc 18:40 2020-09-22, Paul Johnson đã viết:
> >
> >
> > On Tue, Sep 22, 2020 at 8:36 PM Mike N
> >  > > wrote:
> >
> > On 9/22/2020 9:26 PM, Paul Johnson wrote:
> >  > The extra hamlet nodes are import remainders that haven't
> > yet been
> >  > converted to landuse areas.   The general landuse zones for
> > that area
> >  > have been identified, but do not exactly correspond to the
> named
> >  > subdivisions.   As I get a chance to survey, I divide the
> > landuse into
> >  > subdivisions and convert the node to a named area for the
> > subdivision.
> >  >
> >  >
> >  > Please don't expand these as landuse, please expand them as
> >  > place=neighborhood instead.  Landuse polygons should be congruent
> > to the
> >  > actual land use.
> >
> > That's a good point: the subdivisions often contain one or more
> landuse
> > basins, clusters of trees, etc.   I've been thinking of them as one
> big
> > blob, but it seem correct on a more micromap level to mark them as
> > place=, and identify the smaller landuse areas (which are sometimes
> all
> > residential).
> >
> >
> > Exactly.  My rule of thumb is if you're thinking about putting a name on
> > it, and it's not a shopping center, apartment complex or similar large
> > but contiguous landuse, then landuse=* probably isn't what your polygon
> > should be.
>
> It's common, intuitive, and IMO beneficial to map a planned,
> suburban-style residential development as a single named
> landuse=residential area. These developments have well-defined
> boundaries and are primarily residential in character. If there are some
> wooded lots in the subdivision, it's perfectly fine to map a
> natural=wood area inside of or partially overlapping the
> landuse=residential area, ideally without being connected to it. This
> approach is supported by longstanding documentation [1], old threads
> [2], and good support in both renderers [3] and search engines.
>
> There have also been old discussions where folks have conflated the
> concept of landcover with landuse. [4] But I find this approach overly
> academic. Taking it to the logical extreme, landuse=residential would
> only be coincident to each house in a subdivision, given that the yards
> are non-dwellings.
>
> I don't see the need for a fundamental distinction between planned
> residential developments consisting of multi-family apartments and those
> consisting of single-family houses, such that the former would be mapped
> as a coherent landuse area but the latter would be a shapeless place
> point. Where there's no such distinction, the landuse areas lend
> themselves to ab intuitive rendering that's good for navigating suburban
> sprawl. [5]
>
> If a planned development truly is actually mixed-use, and not only in a
> garden-level micromapping sense, then something other than landuse=*
> would be reasonable, since a particular landuse doesn't characterize
> that development anyways. Named landuse=residential areas also don't
> tend to make as much sense in urban areas, older inner suburbs, and
> rural areas. But the areas in changeset 91255294 aren't mixed-use
> developments; they're residential areas in a suburban setting.
>
> [1] https://wiki.openstreetmap.org/wiki/Special:Diff/1087300
> [2] I previously wrote on this topic in
> 
> and
> it seemed like other respondents were taking the same approach.
> [3] https://github.com/gravitystorm/openstreetmap-carto/issues/351
> [4]
> https://lists.openstreetmap.org/pipermail/talk-gb/2017-January/019811.html
> [5] https://osm.org/go/ZTVSa4OB
>
> --
> m...@nguyen.cincinnati.oh.us
>
>
> ___
> 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] National Forest refs/names

[Evin Fairchild]

I'm also in favor of this change. It's a route number, so it only should be
in the ref tag. This will make Forest service roads more consistent with
other numbered routes. Even though most, if not all, Forest service roads
don't have a name but just a number, I still am in favor of this. I was a
bit surprised that the wiki was saying to keep the road number in the name.

In fact, the names that most of these forest service roads have don't even
match common parlance. Most people refer to them as "Forest Service Road
XX" whereas the TIGER import called them "National Forest Development Road
XX," which might be the official name, but not the most common name.

-Evin


On Wed, Jul 29, 2020, 6:47 AM Mike Thompson  wrote:

>
>
> On Tue, Jul 28, 2020 at 1:33 PM Paul Johnson  wrote:
>
>>
>>
>> Could we get the US Road Tagging page updated to reflect common name
>> practice instead of encouraging the duplication of the ref in the name?  Or
>> is that going to spark drama?
>>
> I am in favor of the change.  The name tag should be for the name only.
>
> 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] fake mapping

[Evin Fairchild]

Could you provide a link to the area you're referring to?

Thanks, Evin

On Mon, Jun 8, 2020, 3:27 PM 80hnhtv4agou--- via Talk-us <
talk-us@openstreetmap.org> wrote:

> just to be safe i went to a pre-edit location, less than 5 miles 2 hours
> by public transportation.
>
> the satellite view was wrong, the river area were ponds because of the
> dam, which was not there in 1969
>
> when we went down the river in cement tubs, and the golf cart paths were
> all marked unmaintained track road.
>
> there are pologons around the greens, holes and fairways not the whole
> property, where natural woods
>
> that have separate pologons.
>
> the point is there is to much there to fix.
>
>
> ___
> 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] Relation template for an honorary/memorial highway?

[Evin Fairchild]

Totally agree, memorial highway names should be under the official_name=*
tag. Usually nobody calls roads by their memorial name.

-Evin

On Tue, May 26, 2020, 1:56 PM Joseph Eisenberg 
wrote:

> Only real, current features should be mapped, but it's possible to add
> "official names" even if they are not the commonly used name, as long as
> they are documented on signs.
>
> It looks like some of these are historic only:
> https://en.wikipedia.org/wiki/Theodore_Roosevelt_International_Highway -
> historic, no longer exists
>
> And the Pan-American Highway system officially includes all the
> Interstates in the United States, but has no signage. So there is not an
> appropriate way to map this in OpenStreetMap:
> https://en.wikipedia.org/wiki/Pan-American_Highway#Contiguous_48_states_of_the_United_States
>
> But these can probably be tagged as "official_name=Ronald Reagan Highway":
> https://en.wikipedia.org/wiki/Ronald_Reagan_Highway
>
> – Joseph Eisenberg
>
> On Tue, May 26, 2020 at 12:15 PM Jack Armstrong 
> wrote:
> >
> > More than once in the past, users have attempted to “name” highways in
> Colorado as the “CanAm Highway”, the “Pan-American Highway”, the “Ronald
> Reagan Memorial Highway” and the “Theodore Roosevelt International
> Highway”, to name a few. There are other honorary/memorial highway
> designations in the area.
> >
> >
> > In order to satisfy persons who want to map these and other memorial
> highways that aren’t actually named “on the ground” here, I’m thinking
> relations might be created. This way, when this situation undoubtedly comes
> up again, I can point the user to the relation and more easily resolve any
> conflicts.
> >
> >
> > Any suggestions as to the relation template I should use? I looked at
> the interstate highway relation wiki and it doesn’t seem to be quite right.
> For example, it requires a ref - number only.
> >
> >
> > I suppose, where appropriate, a different relation should be created for
> each state the memorial highway passes through? Which network relation or
> super relation should these memorial route relations be tied into?
> >
> >
> > Any feedback is welcome. Thanks :)
> >
> >
> >
> >
> > ___
> > 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
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Trunk VS primary,

[Evin Fairchild]

Okay, this is going to be a long message, but I’d strongly suggest you read ALL 
of it before responding.

I’d first like to address the assumption that some people seem to have that 
those who support using trunk on roads other than divided highways are “tagging 
for the renderer” because we allegedly just want to see these roads appear at 
lower zoom levels. For me, that is NOT the case at all.

In reality, I support having trunk for major intercity highways because there 
needs to be more levels of indicating importance for US highways than just 
primary. For example, in Nevada, US 50 and US 6 are very lightly-traveled roads 
that only connect a few small towns in Nevada, and are known for having very 
little traffic. Tagging them as primary is perfectly fine IMO. However, US 95 
connects the two biggest cities in Nevada—Las Vegas and Reno—but it’s also 
tagged as primary. Surely US 95 between Vegas and Reno is more important than 
US 6 and US 50, right?

In my home state of Washington, there are two US routes that cross the Cascade 
Mountains, US 12 and US 2, both currently tagged as primary. Both of these 
roads are kept open in winter thru the Cascades. However, there is another road 
that crosses the Cascades, WA 20, that is also currently tagged as primary 
(which makes sense given that it is a very important cross-state highway), but 
it is NOT kept open in the winter. It doesn’t make any sense that a road that 
is not open in the winter is tagged at the same importance level as other roads 
that are kept open in the winter!

Secondly, I think some things from the wiki need to be pointed out here. On the 
wiki page for Key:highway, [1] the definition of highway=trunk is “The most 
important roads in a country's system that aren't motorways. (Need not 
necessarily be a divided highway.)” Those who say “Trunk roads should ONLY be 
divided highways, no ifs, ands, or buts” are going against what is explicitly 
stated on the wiki page for key:highway. 

Also, at the bottom of the aforementioned wiki page, there is a section 
entitled "Assumptions,” which states in the first paragraph: 

“Only highway=motorway/motorway_link implies anything about quality. Other road 
types, from highway=trunk through highway=tertiary to 
highway=residential=residential/service or highway=path/footway/cycleway/track 
do not imply anything about road quality.” 

These words speak for themselves. 

Now, if we want to indicate road quality in some way (e.g. whether a road is 
divided or not), we ought to use the expressway=* tag like others have 
suggested rather than using the highway=trunk tag just for that. 

Even if you don’t use the expressway tag, you can still tell if a trunk road is 
divided or not because the default render shows divided roads as having a 
thicker line than undivided roads. A good example can be seen by looking at 
western Canada, where the most important intercity roads are tagged as trunk 
regardless of whether they’re divided or not. [3] You can clearly tell if a 
road is divided or not even if undivided roads are tagged as trunk because the 
divided roads have a thicker line than the undivided. Therefore, it is not 
necessary to reserve highway=trunk for divided roads only.

TL;DR I support tagging undivided roads as trunk because 1) some US routes are 
more important than others and lumping them all as primary doesn’t make any 
sense; 2) the wiki says that only the motorway designation implies anything 
about quality of the road; and 3) the renderer shows divided roads with a 
thicker line than undivided roads. 

[1] https://wiki.openstreetmap.org/wiki/Key:highway#Roads
[2] https://wiki.openstreetmap.org/wiki/Key:highway#Assumptions
[3] https://www.openstreetmap.org/#map=7/51.618/-112.972

From: Greg Troxel
Sent: Tuesday, December 17, 2019 1:16 PM
To: Paul Johnson
Cc: Mike N; talk-us@openstreetmap.org
Subject: Re: [Talk-us] Trunk VS primary,

Paul Johnson  writes:

> On Tue, Dec 17, 2019 at 7:24 AM Mike N  wrote:
>
>>
>>I think many of the trunk VS motorway VS primary conflicts come from
>> 2 points of view:  on the one hand, people like to zoom out and see a
>> coherent network of interconnected roads.
>
> In which case, rendering based on network on the route relations would be
> more appropriate.

This is the crux of the matter.  Calling things trunk so they render is
tagging for the renderer in a bad way.

___
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] Alaska Highway AK-2 tagging

[Evin Fairchild]

Those roads in northern CA were tagged as trunk long after NE2 was banned
from editing OSM. Also US 101 in Washington was tagged as trunk two years
ago, and it doesn't bother me enough for me to change it back to primary.

On Mon, Dec 16, 2019, 4:58 PM Paul Johnson  wrote:

>
>
> On Mon, Dec 16, 2019 at 6:47 PM Joseph Eisenberg <
> joseph.eisenb...@gmail.com> wrote:
>
>> Alaska is not attached to the rest of the USA, so consistency with the
>> Yukon Territory and British Columbia is equally important.
>>
>> In the western USA, highway=trunk is not limited to expressways like it
>> is in Germany and France
>>
>> On the West Coast, several important State highways are tagged as trunks
>> even though they are not full expressways, because they are the main road
>> for a large region. For example, see US 199, US 101, CA 99 and CA 299 on
>> this map of far Northern California:
>>
>
> Are we sure that's not leftover tagging from before NE2 torqued things on
> a continental level?  101 in parts of California I could potentially see,
> and maybe parts of 99 where the freeway is ending in central california but
> the other examples probably should be secondary in most cases for the state
> highways and primary for the US ones.
> ___
> 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] Alaska Highway AK-2 tagging

[Evin Fairchild]

Well I think Alaska is kind of an exception to the rest of the US given
that there are no intercity freeways due to lack of demand. It's more
equivalent to western Canada in that regard.

Personally I think US highways should be tagged as trunk roads in most
cases but that's an entirely different discussion so if we want to discuss
that, we should probably start a new email thread.

On Mon, Dec 16, 2019, 4:31 PM Paul Johnson  wrote:

>
>
> On Mon, Dec 16, 2019 at 6:26 PM Joseph Eisenberg <
> joseph.eisenb...@gmail.com> wrote:
>
>> Trunks are rarely expressways in remote parts of the world. In Britain,
>> where this tag started, many highway=trunk roads are not expressways or
>> motorroads.
>>
>
> Are we not trying to remain internally consistent with the rest of the US?
> ___
> 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] Alaska Highway AK-2 tagging

[Evin Fairchild]

Totally agree. Since Alaska doesn't have any freeways outside of Anchorage,
these roads are the most important roads in the state and should be tagged
as trunk.

-Evin (compdude)

On Mon, Dec 16, 2019, 4:20 PM Joseph Eisenberg 
wrote:

> I would use highway=trunk the whole way for consistency. In Canada the
> connecting highway is also highway=trunk. This makes sense because AK 2 is
> linking Fairbanks, the largest city in this part of Alaska, with All the
> cities in Canada and the lower 48 States.
>
> -Joseph
>
> On Tue, Dec 17, 2019 at 7:37 AM Eric H. Christensen via Talk-us <
> talk-us@openstreetmap.org> wrote:
>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA256
>>
>> I've noticed that there is some mixed tagging of the Alaska Highway AK-2
>> from the Canadian border through Delta Junction to where it becomes a
>> divided highway just south and east of Fairbanks at Eielson Air Force
>> Base.  Some of the non-divided portions are tagged as trunk while the other
>> (majority) is tagged as primary.  The definitions of these two tags are
>> similar enough in the U.S. to almost be interchangeable.  Being that this
>> highway links many villages with Canada and the City of Fairbanks and the
>> speed limit is 65 MPH, I would lean towards this highway being tagged as
>> trunk.  By the same definition, I'd probably argue the same for the 
>> Richardson
>> Highway AK-4
>> 
>> .
>>
>> Thoughts?
>>
>> R,
>> Eric "Sparks"
>>
>>
>>
>>
>> -BEGIN PGP SIGNATURE-
>> Version: ProtonMail
>>
>> wsFcBAEBCAAGBQJd+BStAAoJEIB2q94CS7PR7d4QAMWWtHe8EB3ALRrczWY/
>> f3kpdRyYqP8QYVvc1vdvu+j/hAP8NdFGb+aDLx2YLMerDEu4Lt7B0BMN78vT
>> LD5629ujwkViIpv8AQt97iWLlruEZOczn44Yhr7KIV6itzmmd9VXfXMs8Kzj
>> gOVFdmABwgJd3S/7/tDavgsM49Bh1nvYHkzdUdBwoZ9MuCQbFpoIdj2EPc/W
>> Z/XDDssBUcxDIzWaa8kDWB/FlizE+5v6QkgULiB4c7grEbg/7fNziisdYAWp
>> lwAqkirEFLsYInrtc80bfkHX0pgb8AtFFZnyDyrY3ijU23Y2Qz5o1qn+4jbS
>> PwFCgO6z771vGw3J+RCmKuhOG3fjyW//X0OmtUkAPdiSWKNsPabLlG4/FWib
>> phl+2IDx0wlHqYITBEGRGw6pq96chIinlHzdWNmC82/fGI0IXo1Ic9/r3S2v
>> Uzr8bwATdLl6mRhYZjAvcLg8yHKblG0PvINjwN4exAthSi+qGsoM5bYDBi8V
>> sccUBA0pypUPWCnOVtck4EmMdIJ63b++EoKQ0DUNMGDkpaac6ErKOXDdVt97
>> ySbzNzfkkAyproGrwmDLeVQ8gt8aoc0vjlQUZpOoKDcuXgZ7mIhWmwn+4kLL
>> WTYYuZn02MVoAsdfbfPB3IyNy9eqmadymFlyNL8AfJC69/0S1TAGLtQFoJjv
>> wQlY
>> =oEIv
>> -END PGP SIGNATURE-
>>
>>
>> ___
>> 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
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Historic 66 as highway=trunk in OK

[Evin Fairchild]

I totally agree with this! As I've stated before, I've long thought that
most US highways should be tagged as trunk roads. Heck, someone recently
tagged US 101 in Washington as trunk but I have no interest in changing it
back because I agree with the way it's tagged. That would be more in line
with the definition of a trunk road as started on the wiki. And I totally
support the use of the expressway tag.

-Evin

On Wed, Aug 28, 2019, 7:06 PM Joseph Eisenberg 
wrote:

> I don't have any local knowledge about old route 66 in OK, but I'd
> like to address the use of highway=trunk in general.
>
> I'm in favor of using a secondary tags like motorroad=yes and
> expressway=yes, along with other details like lanes=, surface=,
> maxspeed=, etc, to specify expressways, rather than using
> highway=trunk for this.
>
> Like the distinctions between primary/secondary/tertiary, trunk was
> originally intended to describe the role of a road in the network.
> While most trunk highways are divided and have more than 1 lane in
> each direction in densely-populated areas, it's quite normal for to
> have narrower roads as the main route between 2 cities, in
> sparsely-populated parts of the country.
>
> For example, US Hwy 101 is the main route connecting the cities (e.g.
> Eureka) and towns along the coast of northern California. Right now
> only some segments are tagged as highway=trunk. I would like to
> upgrade all of it to highway=trunk, up to Hwy 199, where most traffic
> leaves 101 and heads to I-5, at Crescent City.
>
> The segments that are divided and wider can be tagged expressway=yes,
> lanes=4, maxspeed=, etc, so if people want to render these differently
> they can (routers are probably more interested in the number of
> intersections, traffic signals, lanes, maxspeed, and surface, so the
> expressway=* tag isn't really needed).
>
> On 8/29/19, Paul Johnson  wrote:
> > On Wed, Aug 28, 2019 at 7:04 AM stevea 
> wrote:
> >
> >> Hi Paul, Hi Volker, Hi talk-us:
> >>
> >> The topic begs the question as to what such (usually very) old,
> >> poor-condition (where they ARE poor) roads should be tagged (we limit
> >> ourselves to US roads here because this is talk-us), and at what
> >> granularity.  (Volker COULD do detailed tagging, but I hear loud and
> >> clear
> >> he prefers high-granularity tagging, as do I, though we all recognize
> how
> >> tedious this can be).  And "old 66" is a quintessential example, many
> >> segments are a century old or older:  it is known as "the Mother road"
> by
> >> many.  BTW, many public agencies under the umbrella of Southern
> >> California
> >> Association of Governments are working on developing USBR 66 in
> >> California
> >> for cyclists (the route number choice is no coincidence as some
> >> alignments
> >> follow the old Mother road).  This was actually in OSM as an early
> >> proposed
> >> route, but was removed to conform to USBRS proposed route conventions.
> >> If/as USBR 66 turns into a Caltrans (DOT) route proposal to AASHTO, OSM
> >> will re-enter these data.  It makes sense to pay close attention to the
> >> underlying infrastructure tagging (tertiary, surface, smoothness...) as
> >> we
> >> do so since these are important to cyclists.
> >>
> >
> > So, the segment in question given in the example to me (I don't think the
> > response was intended only for me, so I'm not quoting the whole thing) is
> > https://www.openstreetmap.org/way/14678570/.  OpenStreetCam has footage
> > from November 2018 on it at
> > https://openstreetcam.org/details/1305935/3747/track-info, showing it's
> a
> > pretty typical Oklahoma expressway, 55 MPH speed limit for most of it,
> > slowing towards its eastern end, and is currently a part of OK 66.
> >
> > I think a better argument for downgrading from trunk exists in Southern
> > California if it hasn't been downgraded already.  There's some decent
> > chunks east of Indio in San Bernardino County off the top of my head that
> > were clearly constructed as trunks, have since left Caltrans inventory
> and
> > are now county roads, and SB County has just let one side of the road rot
> > off, running both directions undivided on the other (usually the former
> > westbound-only carriageway, from memory, as last I drove it I was going
> > eastbound, the center divider was on my right, and it looked like the
> other
> > side hadn't been usable for at least a decade with weeds and huge cracks
> > growing out of the abandoned carriageway).
> >
> > A case can be made for highway=trunk (for connectivity reasons) yet I do
> >> resonate with "secondary at best" for such old, poor roads.  Tagging
> >> highway=trunk is about as high a classification as the very best
> portions
> >> of this road will ever get, and only on its highest-speed segments which
> >> are divided.  This implies highway=tertiary (MAYBE secondary) where the
> >> road is NOT dual carriageway, as highway=trunk in the USA means "with a
> >> barrier or median separating each direction 

Re: [Talk-us] Is there any value at all in tiger:MTFCC and tiger:FUNCSTAT tags?

[Evin Fairchild]

Weird. I've never seem any of these TIGER tags in Washington state.

-Evin

On Mon, Mar 25, 2019, 8:58 AM Mateusz Konieczny 
wrote:

>
>
>
> Mar 25, 2019, 4:19 PM by matkoni...@tutanota.com:
>
> I encountered this tags some time ago and seem to be popular, imported,
> useless
> and without clear meaning.
>
> Therefore I think it would be a good idea to add them to discardable tags
> (tags not displayed
> by editors and silently removed if mapper edited object with it).
>
> I created documentation pages for them at
>
> https://wiki.openstreetmap.org/wiki/Key:tiger:MTFCC
> and
> https://wiki.openstreetmap.org/wiki/Key:tiger:FUNCSTAT
>
> Is anyone aware about meaning or use of this tags or supports their
> continued
> presence?
>
> https://wiki.openstreetmap.org/wiki/Key:tiger:MTFCC is now documented
>
> Any info about meaning or use of
> https://wiki.openstreetmap.org/wiki/Key:tiger:FUNCSTAT
> would be useful.
> ___
> 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] Trunk versus motorway

[Evin Fairchild]

Links please?

On Sun, Dec 2, 2018, 3:06 PM Paul Johnson 
>
> On Sun, Dec 2, 2018 at 5:04 PM Evin Fairchild  wrote:
>
>> You are proving my point once again re misrepresentation of what we're
>> saying. It would only be accurate for you to say that we're going against
>> federal guidelines is if we were to say that the motorway should continue
>> thru the at grade intersection. None of us are saying that!
>>
>
> Sure, if the federal guidelines actually said that.  But they exclude all
> surface intersections.
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Trunk versus motorway

[Evin Fairchild]

Can you provide changesets showing where NE2 mass edited motorways in the
way you're describing?

On Sun, Dec 2, 2018, 3:02 PM Paul Johnson 
>
> On Sun, Dec 2, 2018 at 4:58 PM Thomas Silas  wrote:
>
>> As for the situation in question: I agree with the vast majority of the
>> posters both in the changeset and in talk-us. There are countless examples
>> of the motorway tag extending to the first intersection (or to a visible
>> change in road geometry, for that matter), but I haven't been able to find
>> any examples of what Paul is proposing, except for the ones he has edited
>> himself.
>>
>
> Are there any that don't date back to either the TIGER import or NE2's tag
> torquing?
> ___
> 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] Trunk versus motorway

[Evin Fairchild]

You are proving my point once again re misrepresentation of what we're
saying. It would only be accurate for you to say that we're going against
federal guidelines is if we were to say that the motorway should continue
thru the at grade intersection. None of us are saying that!

I'm really getting frustrated with the way you're deliberately
misrepresenting this discussion, so frankly I'm going to bow out since I
don't know what else to say to convince you to change your opinion on this
issue.

On Sun, Dec 2, 2018, 2:55 PM Paul Johnson  On Sun, Dec 2, 2018 at 4:30 PM Evin Fairchild  wrote:
>
>> Once again, I see you're misrepresenting the discussion and trying to
>> make us look like a bunch of idiots for not accepting your way of doing
>> things. There's no way you're so dense as to assume that because we pretty
>> much all want the motorway designation to extend all the way to the first
>> at grade intersection, we think roads with at grade intersections can be
>> classified as motorways.
>>
>
>  There's no reason to get personally derogatory on this.  Where's the
> problem with limiting motorway to what generally meets federal guidelines
> on what constitutes a freeway?
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Trunk versus motorway

[Evin Fairchild]

Once again, I see you're misrepresenting the discussion and trying to make
us look like a bunch of idiots for not accepting your way of doing things.
There's no way you're so dense as to assume that because we pretty much all
want the motorway designation to extend all the way to the first at grade
intersection, we think roads with at grade intersections can be classified
as motorways.

-Evin (compdude)

On Sun, Dec 2, 2018, 2:05 PM Paul Johnson  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
>> https://lists.openstreetmap.org/listinfo/talk-us
>>
> ___
> 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] Fwd: Trunk versus motorway

[Evin Fairchild]

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.
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

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

[Evin Fairchild]

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.

-Evin

On Nov 28, 2018 7:42 PM, "Paul Johnson"  wrote:

On Wed, Nov 28, 2018 at 9:36 PM Nathan Mills  wrote:

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

Right, but where are we getting that motorways have surface intersections
now?
___
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

[Talk-us] Fwd: Trunk versus motorway

[Evin Fairchild]

-- Forwarded message -
From: Evin Fairchild 
Date: Wed, Nov 28, 2018, 6:42 PM
Subject: Re: [Talk-us] Trunk versus motorway
To: Paul Johnson 


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.

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. Frankly,
I've wanted to change this road from trunk to motorway in the past, but
I've avoided doing so because this is Paul's home turf and I felt I'd just
be shaking a hornet's nest.


-Evin (compdude)

On Wed, Nov 28, 2018, 6:19 PM Paul Johnson  Can I get some voice of reason in
> https://www.openstreetmap.org/changeset/64919426?  There seems to be
> quite a few people (and one AARoads forum troll egging it on) that are
> trying to propel the idea that motorways have at-grade intersections, which
> is obviously incorrect.
> ___
> 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] Forest Routes

[Evin Fairchild]

Worth noting that most people just call them forest service roads. I've
never heard anyone call them "forest highways."

On Tue, Nov 20, 2018, 9:27 AM Max Erickson  As other have mentioned, there are many numbered roads managed by the
> USFS. They range in development from closed, abandoned log roads to
> well maintained pavement. I map them using the FS prefix.
>
> For the general public one of the main uses is the publication of
> motor vehicle access conditions:
>
> https://www.fs.fed.us/recreation/programs/ohv/ohv_maps.shtml
>
>
> Max
>
> ___
> 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] Naming numbered roads as "State Route X", "Interstate X", etc.

[Evin Fairchild]

Yeah, I agree, it is redundant and thus completely unnecessary to put the
highway number in the name tag. Have you informed SSR_317 about this
discussion?



On Fri, Aug 31, 2018 at 7:09 PM Albert Pundt  wrote:

> I notice the user SSR_317 has been adding the route numbers of unnamed
> roads to the name=* tag of roads around Indianapolis. For example, 
> name=Interstate
> 465, name=US 31, name=State Route 37, etc. Isn't this practice frowned
> upon as being redundant and not reflecting the lack of a proper name to the
> road? This seems to be the case around the country. All route numbers were
> listed in alternate names of the roads in the original TIGER data, but the
> vast majority of these have been removed in favor of route relations and
> ref=* tags.
>
> I removed these name tags from the affected roads, but the user has since
> re-added them.
>
> —Albert Pundt
> ___
> 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] ref=* tags on links

[Evin Fairchild]

Hey, I totally agree that we need to fix the rendering so that the renderer
will show ref tags on route relations. But until then, it's impractical to
expect people to avoid putting the ref tags on the ways. I do agree with
not tagging for the renderer, but I was merely pointing out that it's
impractical to expect EVERYONE to follow it in this case until the renderer
is fixed.

There's always gonna be people who will be like "I want to see the route
numbers so I'm just gonna circumvent tagging convention and tag the ref
tags on the ways instead of just the relation." As an example, I remember
back before Andy Allan created Carto, the code for the Mapnik stylesheet
was super complex and so there were a lot of bugs that took forever to get
fixed, including one where river names were not being displayed, so people
would tag rivers as streams to get the name to show up, even though that's
tagging for the renderer. I never fixed those things as I could totally
understand why people would do that and expecting people to follow the
"don't tag for the renderer" rule in that case is overly legalistic.
Instead of being annoyed that people tag for the renderer, turn your
annoyance at the renderer itself and push for it to get fixed or help fix
it if you have the expertise.

Hopefully we can get actual route shields implemented too. That's what got
me to create route relations for all of WA's state routes several years ago
when Phil Gold was working on making the shields. OSM would look awesome in
the US if we had those route shields!

Anyway, to get back on topic, I don't agree with tagging the ref tags on
link roads, as long as it's part of the route relation. I have seen
instances, though, where people tag what should be a motorway link as a
motorway when a route exits off a freeway to get the route number to
render, and I'm not exactly fond of that practice.

-Evin (compdude)

On Fri, Aug 24, 2018, 10:57 AM OSM Volunteer stevea <
stevea...@softworkers.com> wrote:

> > Evin Fairchild  wrote
> > The only way you can get people to stop putting reg tags on ways and
> only put them on relations is if the renderer actually rendered reg tags
> from relations. Currently it doesn't do this, so
>
> All good and correct so far...
>
> > it's impractical for people to do what you're suggesting.
>
> By "you" Evin means Paul Johnson and by "do what you're suggesting" —
> eliminating ref=* tags on ways — (as they are 100% redundant if the way is
> part of the appropriate route relations) Paul's suggestion is excellent.
> It is correct, not impractical.
>
> Continuing to put ref=* tags on ways is called a "workaround."  Like a
> bandage on a wound, workarounds can be decent short-term solutions, but the
> real healing which OSM must complete is for renderers to respect route
> relation tags.  All else is folly.
>
> > Yeah, yeah, yeah, I know, don't tag for the renderer,
>
> OSM's tenet of "don't tag for the renderer" is something I respect.  Yet
> (especially in this case) it has qualities of "magical thinking" whereby
> the wound is artificially babied along by pretending away that the real
> work renderers must (MUST!) do is to fully respect long-established data
> structures renderers purport to represent.  If that is hard work
> (evidently, it is), well, let's roll up our sleeves and code (FIX!) our
> renderers so they properly visually represent our data.
>
> Babying along wounds, pretending away and magical thinking are elements of
> sad, broken, amateurish projects:  they'll "get you through the night," and
> for too long in OSM, they have.  But as OSM matures into a happy, working,
> professional-grade project (we have, we do) that simply doesn't cut it any
> longer.  Someone has to say this — again and again, apparently — until the
> real solution of "this is hard work, but we must do it" is completed.
>
> > but I'd you don't have route numbers show up at all, them this really
> reduces the usability of the map.
>
> What a fantastic incentive to fix renderers:  evidence of "tag like we say
> we should tag" means "hm, renderers don't respect that!"  We can no longer
> say "don't code for the renderer," wink at those who do and continue to say
> and do this while "rendering incompletely."  It is disingenuous and shows
> that something is fundamentally broken in our project.  We MUST fix
> renderers or we DESERVE monikers of "sad, broken, amateurish."
>
> > It's such an important thing that there's no way you can get people to
> stop putting the reg tags on ways unless the renderer rendered the ref tags
> for the whole relation.
>
> It is circular logic (explained) and circular logic is broken.  We mu

Re: [Talk-us] Shaped highway shields - trying to revive

[Evin Fairchild]

Really glad to see that someone is reviving this and actually taking the
step to get it rendered. Frankly, I never understood why Phil didn't do
this in the first place. I even mentioned this to him at the time (can't
remember his response though).

-Evin (compdude)

On Wed, Aug 22, 2018, 2:21 PM Kevin Kenny  wrote:

> (I apologize in advance to the tile-serving community if this message
> is inappropriate. I see that traffic on that list is largely limited
> to highly specific technical discussions, but couldn't see a more
> appropriate forum.)
>
> For several years now, I've been using the support code for shaped
> shields in OSM, originally developed by Phil! Gold and Richard Weait,
> to render North American-style maps. A typical example can be found at
> https://kbk.is-a-geek.net/catskills/test4.html?la=41.4143=-74.4233=14
> In that view, you can see distinct shields for Interstate, US, New
> York, and county routes, and at least one concurrence (New York 17M
> aligned with US 6). Incidentally, Phil's is the only renderer that
> I've seen that can make sense of cases like West Virginia's bizarre
> double route numbers, as seen in
> https://kbk.is-a-geek.net/catskills/test4.html?la=41.4143=-74.4233=14
> .
>
> The visual distinction among highway shields is really necessary in
> North America, where there are so many different route networks
> overlaid.
>
> In the course of working with the code, I've made a number of changes
> and become seriously out of sync with the main development line, which
> appears to be moribund. (Phil! and Richard have not answered recent
> queries; I suspect that I have obsolete contact information, but the
> messages also have not been returned undelivered.)
>
> Accordingly, I've (quite reluctantly) created my own repository -
> https://github.com/kennykb/osm-shields - with material from the
> project. The shield templates to be found there are mostly those of
> Phil! (I added only a handful), but the code to manage shields is
> almost entirely new. Some significant changes are:
>
> The list of shields to be rendered is obtained from the database
> itself, rather than being predetermined by a configuration file for
> each network. This has the disadvantage that refs that are known to be
> problematic may be rendered (but in most cases they ought to be
> unsigned_ref). On the other hand, it has the distinct advantage that
> as mappers continue to create the route relations, the corresponding
> shields appear virtually automatically.
>
> The composition of shield clusters, rather than being handled by a
> stored procedure in the database, is done using a GroupSymbolizer in
> Mapnik. I suspect, given the dearth of discussion that I find in a
> Google query, that I'm the first user to attempt to use
> GroupSymbolizer with actual open-ended shield clusters, and therefore
> that I've trodden new ground in the path from database to renderer. I
> encourage developers who are interested in the GroupSymbolizer to read
> at least
> https://github.com/kennykb/osm-shields/wiki/Using-the-GroupSymbolizer
> - it has a number of tricks to structure the results in a way that the
> GroupSymbolizer can consume and that renders well. The disadvantage to
> using the GroupSymbolizer is that Phil!'s shield clusters were rather
> more attractive visually, since they were aligned to lie in the
> direction of a way. The advantage is that the current approach can run
> on an unpatched Mapnik, as opposed to Phil!'s original, which requires
> at least patching Mapnik to use a read/write connection to the
> database.
>
> Managing, reliably, the association between ways and the routes in
> which they participate requires a couple of database tables that a
> stock osm2pgsql does not produce. I would very much appreciate any
> commentary from developers of osm2pgsql and Mapnik, particularly,
> about the issues discussed in
>
> https://github.com/kennykb/osm-shields/wiki/Maintaining-the-association-between-ways-and-routes
> What I'm currently doing works well for my own use, which is driven by
> daily updates to extracts at Geofabrik, but will obviously not scale
> to a whole planet and minutely updates.
>
> Finally, I'd really like to invite anyone with the necessary SVG
> skills to contribute shield graphics for the missing networks. If
> you're also a programmer and want to take a whack at the rest of the
> procedure in
> https://github.com/kennykb/osm-shields/wiki/Adding-new-networks,
> and give me a pull request or ask for help, that would be even better,
> but even the artwork would be a time-saver.
>
> If you've got this far in reading, thanks! I know this was a long
> message, and I hope that I've not wasted too much of anyone's time.
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>
___
Talk-us mailing list
Talk-us@openstreetmap.org

Re: [Talk-us] ref=* tags on links

[Evin Fairchild]

The only way you can get people to stop putting reg tags on ways and only
put them on relations is if the renderer actually rendered reg tags from
relations. Currently it doesn't do this, so it's impractical for people to
do what you're suggesting. Yeah, yeah, yeah, I know, don't tag for the
renderer, but I'd you don't have route numbers show up at all, them this
really reduces the usability of the map. It's such an important thing that
there's no way you can get people to stop putting the reg tags on ways
unless the renderer rendered the ref tags for the whole relation.

-Evin (compdude)

On Fri, Aug 24, 2018, 9:56 AM Paul Johnson  wrote:

> The ref=* tag on ways is already 100% redundant if the way is already a
> part of the appropriate route relations and should be phased out so ref can
> be used to actually describe the way's ref, where applicable.
>
> Also, can we kill this dinosaur entirely already?  Route relations have
> been a widely accepted thing for a decade now, if you're not using route
> relations for your primary source of route information (instead of
> expecting tags on some other non route object to tell you), then you're
> doing it wrong and you don't matter.
>
> On Fri, Aug 24, 2018, 07:38 Mihai Iepure  wrote:
>
>> Hey everyone!
>>
>>
>>
>> We’re looking for your opinion on the existence of ref tags on links –
>> should it be there? Is it redundant if the link is already in a route
>> relation that has the ref tag?
>>
>>
>>
>> We’ve created a Github ticket
>>  to let
>> us know what you think, so feel free to post your thoughts there.
>>
>>
>>
>> Thanks in advance!
>>
>>
>>
>> Mihai Iepure
>> Map Analyst
>>
>> [image: Description: cid:image002.png@01CCCAE5.664FA940]
>>
>> www.telenav.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
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] named links

[Evin Fairchild]

There are some cases where naming link roads makes sense. For example, I
tag the roads coming out of roundabouts as link roads (especially if it's
something like a residential road intersecting, a note important road like
a secondary road, and I tag the slip roads for that leg of the roundabout
as secondary_link), and it is pretty helpful for routing purposes to name
the link roads in that case. Also helpful if the link roads represent a
RIRO (right-in, right-out) intersection.

-Evin (compdude)

On Tue, Jul 3, 2018, 9:28 AM OSM Volunteer stevea 
wrote:

> While I don't have "a dog in this fight," I also read our wiki which says
> "Link roads NORMALLY do not have names."  (Emphasis mine).  In the unusual
> (abnormal?) cases where they do (and I trust Paul wouldn't have added them
> unless they do), there is no contradiction with our wiki, rather an unusual
> case which isn't "normal."  In my opinion, that's OK.
>
> We should follow what our wiki says, in this case it leave a bit of
> "wiggle room" to name a link road.  Paul has named some link roads where it
> appears they do have such names in the real world, and I see no
> inconsistency.
>
> Sometimes a datum in OSM will LACK all the tags it should, because some
> are not known.  That's not great, but it's OK:  mappers who come along
> later can add these (and improve this and other features in our map), this
> is called "growing our map."  Sometimes an ADDITIONAL datum exists in the
> real world and is added to a feature even when this is unusual (though not
> incorrect) as many other similar data do not have this additional datum.
> That's OK; I see no inconsistency.
>
> Our wiki strives to hit the sweet spot of accommodating what is in the
> real world and how we should tag such data in our map.  It is a guide, not
> absolutely strict doctrine.  I say this because we have "plastic tagging"
> that encourages us to tag accurately while allowing flexibility.
> Especially in early versions, we may not always write our wiki as 100%
> correct, and so wikis grow, change and evolve to accomplish this.  If the
> wiki needs updating to note that unusually, but in certain parts of the
> world, link roads sometimes get names, I encourage you to update it:  we'll
> all benefit.
>
> Writing/contributing to wiki is easy, though it can be tricky:  you want
> to channel consensus without being too strictly doctrinaire in a direction
> which would hobble contributions or just plain encourage/teach others to
> enter them wrongly.  It is meant to guide us, not preach to us as an
> absolute.  Where it is wrong, or one or more believe it wrong or
> out-of-date with real world data, please use the Discussion page built into
> each wiki to discuss with others any potential changes to existing wiki.
> The "right thing" (better written wiki) usually happens soon after such
> discussion.
>
> SteveA
> California
> OSM Volunteer since 2009 and serious contributor to not only our map's
> data, but our wiki, too
> ___
> 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] Prospect Mountain Interchange Reconfiguration, Binghamton NY

[Evin Fairchild]

You're welcome. I don't think that was the I-81/I-86 interchange that
NYSDOT was referring to, but yeah, I figured it ought to be fixed. I'm
pretty sure NYSDOT is referring to the T-interchange a few miles NW of the
one I just edited. Since I live on the other side of the country, fixing
that one is going to be beyond my knowledge or ability to survey.

-compdude

On Fri, May 18, 2018, 12:51 PM Kevin Kenny  wrote:

> On Fri, May 18, 2018 at 2:06 PM, Kevin Kenny 
> wrote:
>
>> I'm kind of in a crunch at work, so my time is quite limited at the
>> moment. Moreover, I'm in the Capital Region, not down near Binghamton, so I
>> don't anticipate having any opportunity to survey this in the field in the
>> near future, unless the occasion arises for me to visit my brother in the
>> upper Delaware valley.
>>
>> Nevertheless, if nobody else steps forward, I'm willing to do what I can.
>>
>
> I see that in the last hour or so, OSM user 'compdude' has done at least
> some repairs to the I-81/I-86 interchange so that now at least the ramps
> connect. Thanks, 'compdude'! If that's the interchange in question, it now
> matches the aerials in NYS Orthos Online pretty closely. Anything else
> would need either data from the DOT or else more field work that I'm not in
> a position to do right now.
>
> ___
> 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] note to armchair mappers about NYS routes & ref tags

[Evin Fairchild]

These unsigned reference route numbers probably should use the
unsigned_ref=* tag. Seems like the best compromise.

-Evin (compdude)

On Nov 29, 2017 6:24 PM, "Richard Welty"  wrote:

> i have spotted what appears to be an armchair mapper making an
> inappropriate
> set of edits to some NYS routes this past summer; i have sent the mapper
> a note
> through the OSM message system but thought this could use a broader
> audience,
> so that certain inappropriate ref tag settings _don't_ get made.
>
> NY state has a not-quite-secret route numbering system called reference
> routes.
> these routes have numbers in the 900 range, and have a single character
> suffix.
> Examples are 910F, 914V and so forth and so on.
>
> these route numbers never, with 4 well documented exceptions, _never_
> appear on
> conventional highway signage (the exceptions are 961F, 962J, 990L and
> 990V).
>
> an example of incorrectly setting a ref tag to 910F is here:
>
> https://www.openstreetmap.org/way/68519517
>
> there are no black-and-white NYS route signs carrying the number 910F, so
> convention dictates that if these designations are to be tagged at all, it
> should be in unsigned_ref or other similar tag.
>
> i haven't heard back from the mapper who added these yet, but am giving it
> a little more time before i go and fix this up myself.
>
> so anyway, it's fun to learn about things like this numbering system, but
> please don't screw up the map by putting these numbers in the ref tags.
> they don't belong there.
>
> for anyone who cares, the entire list of these numbers appears here:
>
> https://en.wikipedia.org/wiki/List_of_reference_routes_in_New_York
>
> 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] Multipolygonizing

[Evin Fairchild]

Yeah, using multipolygons for everything is quite overkill, and it
certainly does overcomplicate things, and not just for new users, but for
experienced users as well. I mean, if it requires some plugin that I've
never heard of in JOSM to easily edit it, then it's too complicated. I
typically prefer using Potlatch 2 to edit OSM because I find JOSM to be
really user-unfriendly, (I couldn't for the life of me figure out how to
add a way to a relation!) so I prefer that things are kept simple as
possible for idiots like me.

-Evin (compdude)

On Nov 20, 2017 9:59 AM, "OSM Volunteer stevea" 
wrote:

> I very much agree with Douglas and Rihards that glebius' mapping is
> (around here) unusual, "terrible" and difficult to parse, even for
> experienced mappers who have been mapping for most of the history of OSM,
> like me.  Glebius is right in my backyard and I've found his coastal
> "restructurings" (e.g. http://www.osm.org/changeset/46756097) to be
> bizarre and unnecessary, often overwriting correct official (county GIS
> imported) data simply to not "share some nodes" or "improve the mess."  He
> claims that "the consensus in Russia is that advanced polygons is the way
> to go."  Well, not here, I assure both Glebuis and the talk-us list of that
> unequivocally.
>
> Glebius uses a JOSM plugin (and it AMAZES him that this functionality has
> not yet been built into JOSM's base code!) called "reltoolbox."  It
> promulgates what he calls "advanced multipolygons" and in the below-noted
> changeset acknowledges that he believes these "became a world wide
> consensus," but of course, they have not.  Glebius has glibly assumed
> reltoolbox and its resulting data is widespread, when in fact it is not:
> neither locally, regionally, nor continentally.  He further says the
> "quality of OSM data in USA is much worse than in other countries" when in
> fact, my small county of Santa Cruz (through a wiki-documented process of
> both importing local government landuse polygons and painfully though
> lovingly improving them over three revisions and many years) actually won a
> Gold Star Award at BestOfOSM.org for "nearly perfect landuse."  Well,
> before glebius snarled up a perfectly geometrically valid coastline and
> many of its landuse polygons, amenities, parks, marinas and recreation
> areas in Santa Cruz before I manually reverted a good number of his "fixes."
>
> Glebius may believe he is "saving data" by "reducing overlapping nodes,"
> but the added complexity to do this in multipolygons is distinctly
> confusing to many (most) OSM volunteers, especially beginners who find
> multipolygons confusing or intimidating.  I'm not saying glebius' practices
> or resulting data are wrong, but rather that when they overwrite perfectly
> already-correct data, his time is likely better spent on other OSM tasks.
> Especially when he rudely calls correct and even award-winning data "a
> mess."
>
> Please, glebius, don't do this here.  Everybody else in our community find
> your submissions to be confusing and difficult to maintain, this practice
> is ANYTHING BUT widespread (here in North America), you are overwriting
> valid data in a way that makes it nearly impossible to update with better
> data (especially when part of import updates) and whatever small cost you
> believe you are saving in either elegance or the amount of data in the map
> is very much outweighed by "simpler is better."  Simple, while it may share
> a few nodes or overlap some ways, isn't wrong, it is far easier to
> understand and maintain, especially for novice mappers, and ESPECIALLY when
> updates to imported data essentially rely on the "simple polygon" paradigm
> which already works so well in our map.
>
> With respect,
> SteveA
> California
>
>
> Douglas Hembry  writes:
> > Greetings everyone,
> > I've just had a short changeset discussion with mapper glebius prompted
> > by changeset 46612750 "Properly multipolygonize Monterey coast line". My
> > understanding is that the map of this stretch of coastline has been
> > restructured to avoid adjacent ways that share nodes. Accordingly, only
> > a single way ever connects any set of nodes, and the single way
> > participates, if necessary, in multiple relations. A result of this is
> > that in a high density area like downtown Monterey Bay many small areas
> > like building footprints or pedestrian areas are defined as distinct
> > multipolygons, with several ways (outers) making up the outline. An
> > example at:
> >
> > https://www.openstreetmap.org/#map=18/36.61726/-121.90045
> >
> > (look at Hovden Way near the top, or the outline of 700 Cannery Row,
> > further down near Bubba Gump, comprised of seven outer ways)
> >
> > glebius believes that this approach (with the help of the reltoolbox
> > JOSM plugin) is easier and less error-prone than having multiple simple
> > closed ways (eg, a building footprint and an adjacent pedestrian area)
> > 

Re: [Talk-us] Trunk

[Evin Fairchild]

You clearly haven't driven on US 97. It's a fairly busy road with a good
amount of truck traffic and lots of little towns along it. That was my
experience when I drove it. It goes thru central Oregon, which is arid, but
not totally desolate. There was PLENTY of cars going in the other
direction. We drove it between OR 138 and OR 58, and drove back to Eugene
via OR 58, another road that had LOTS of truck traffic, and IMO is fairly
analogous in terms of traffic to US 2 over Stevens Pass.

On Sat, Oct 14, 2017 at 9:47 PM, Paul Johnson  wrote:

> On Sat, Oct 14, 2017 at 11:23 PM, Nathan Mills  wrote:
>
>> 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.
>>
>
> Funding, mostly.  I'd consider Bend Parkway a trunk (the dual carriageway
> section between County Road 40 and US Route 20) But even then, the best
> Oregon's ever going to do with the rest of the US 97 route is a 2-lane
> single carriageway.  It's a desert road where you can go a decent amount of
> time without encountering anyone else in either direction, almost a road to
> go to of last resort if you're lost on foot as a last resort (and I realize
> most of the roads that cross it are posted "No bicycles, no pedestrians, no
> water available beyond this point", most of Oregon's open freaking desert
> with no features for dozens to hundreds of kilometers if terrain doesn't
> end the road far sooner).  That's totally a primary where it's not trunk.
>
>
>> 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.
>
>
>  Same here.  Bend Parkway's a solid trunk.  Milwaukie Expressway, too.
> Oklahoma City's Northwest Expressway's either a large primary or a bitty
> trunk; Tulsa's Riverside Parkway is a large primary.
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Trunk

[Evin Fairchild]

I think primary ought to be used for major state routes and minor US
routes, secondary for minor state routes, and tertiary for collector
arterials.

On Oct 14, 2017 9:23 PM, "Nathan Mills" <nat...@nwacg.net> wrote:

> 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 <evindf...@gmail.com>
> 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 <ba...@ursamundi.org>
>> wrote:
>>
>>>
>>>
>>> On Sat, Oct 14, 2017 at 9:43 PM, Evin Fairchild <evindf...@gmail.com>
>>> wrote:
>>>
>>>>
>>>>
>>>> On Oct 14, 2017 5:41 PM, "Paul Johnson" <ba...@ursamundi.org> wrote:
>>>>
>>>>
>>>>
>>>> On Sat, Oct 14, 2017 at 7:28 PM, Evin Fairchild <evindf...@gmail.com>
>>>> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Oct 14, 2017 4:25 PM, "Paul Johnson" <ba...@ursamundi.org> wrote:
>>>>>
>>>>>
>>>>>
>>>>> On Sat, Oct 14, 2017 at 6:08 PM, Evin Fairchild <evindf...@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> On Oct 14, 2017 2:04 PM, "Wolfgang Zenker" <wolfg...@lyxys.ka.sub.org>
>>>>>> 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

[Evin Fairchild]

That can be easily rectified by tagging trunk roads in accordance with the
wiki. They should be the most important non-motorway roads. Tagging most US
highways as such fulfills this.

On Sat, Oct 14, 2017 at 8:03 PM, Paul Johnson <ba...@ursamundi.org> wrote:

>
>
> On Sat, Oct 14, 2017 at 9:43 PM, Evin Fairchild <evindf...@gmail.com>
> wrote:
>
>>
>>
>> On Oct 14, 2017 5:41 PM, "Paul Johnson" <ba...@ursamundi.org> wrote:
>>
>> Or, map it cleanly to limited access expressways and super2s.  I really
>> think people are trying to overthink this a bit; being a little less
>> subjective isn't necessarily a bad thing.
>>
>>
>> No, just no. I don't like looking at the US at a low zoom and seeing
>> disjointed bits of trunk that aren't connected to anything. Makes the US
>> map look bad.
>>
>
> That's a osm-carto problem, not a tagging problem.  Let's work out the
> tagging situation first, then we can worry about carto.
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Trunk

[Evin Fairchild]

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 <ba...@ursamundi.org> wrote:

>
>
> On Sat, Oct 14, 2017 at 9:43 PM, Evin Fairchild <evindf...@gmail.com>
> wrote:
>
>>
>>
>> On Oct 14, 2017 5:41 PM, "Paul Johnson" <ba...@ursamundi.org> wrote:
>>
>>
>>
>> On Sat, Oct 14, 2017 at 7:28 PM, Evin Fairchild <evindf...@gmail.com>
>> wrote:
>>
>>>
>>>
>>> On Oct 14, 2017 4:25 PM, "Paul Johnson" <ba...@ursamundi.org> wrote:
>>>
>>>
>>>
>>> On Sat, Oct 14, 2017 at 6:08 PM, Evin Fairchild <evindf...@gmail.com>
>>> wrote:
>>>
>>>> On Oct 14, 2017 2:04 PM, "Wolfgang Zenker" <wolfg...@lyxys.ka.sub.org>
>>>> 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.
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Trunk

[Evin Fairchild]

On Oct 14, 2017 5:41 PM, "Paul Johnson" <ba...@ursamundi.org> wrote:



On Sat, Oct 14, 2017 at 7:28 PM, Evin Fairchild <evindf...@gmail.com> wrote:

>
>
> On Oct 14, 2017 4:25 PM, "Paul Johnson" <ba...@ursamundi.org> wrote:
>
>
>
> On Sat, Oct 14, 2017 at 6:08 PM, Evin Fairchild <evindf...@gmail.com>
> wrote:
>
>> On Oct 14, 2017 2:04 PM, "Wolfgang Zenker" <wolfg...@lyxys.ka.sub.org>
>> 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.



>
>
>> The definition of "trunk" that I have used so far: A highway that is of
>> the same network importance as a primary, but specifically constructed
>> for fast traffic.
>>
>>
>> I like this definition. There are quite a few two lane roads that are
>> built for speed, but may still have some at grade intersections.
>>
>
> There's still a fundamental difference between a controlled or limited
> access route that isn't a freeway, and a two lane road without hard
> shoulders that has a 70 mph speed limit.
>
>
> Yeah, true. It's probably a more subjective definition. I think we ought
> to set a population of a city that should be connected to other places by
> trunk roads.
>

Or, map it cleanly to limited access expressways and super2s.  I really
think people are trying to overthink this a bit; being a little less
subjective isn't necessarily a bad thing.


No, just no. I don't like looking at the US at a low zoom and seeing
disjointed bits of trunk that aren't connected to anything. Makes the US
map look bad.

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

Re: [Talk-us] Trunk

[Evin Fairchild]

On Oct 14, 2017 4:25 PM, "Paul Johnson" <ba...@ursamundi.org> wrote:



On Sat, Oct 14, 2017 at 6:08 PM, Evin Fairchild <evindf...@gmail.com> wrote:

> On Oct 14, 2017 2:04 PM, "Wolfgang Zenker" <wolfg...@lyxys.ka.sub.org>
> 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?



> The definition of "trunk" that I have used so far: A highway that is of
> the same network importance as a primary, but specifically constructed
> for fast traffic.
>
>
> I like this definition. There are quite a few two lane roads that are
> built for speed, but may still have some at grade intersections.
>

There's still a fundamental difference between a controlled or limited
access route that isn't a freeway, and a two lane road without hard
shoulders that has a 70 mph speed limit.


Yeah, true. It's probably a more subjective definition. I think we ought to
set a population of a city that should be connected to other places by
trunk roads.

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

Re: [Talk-us] Trunk

[Evin Fairchild]

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.


The definition of "trunk" that I have used so far: A highway that is of
the same network importance as a primary, but specifically constructed
for fast traffic.

Wolfgang

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


I like this definition. There are quite a few two lane roads that are built
for speed, but may still have some at grade intersections.

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

Re: [Talk-us] Trunk

[Evin Fairchild]

As I said previously, and I think it bears repeating, it's very easy to
tell if a trunk is divided or undivided when you look at US or Canada at
zoom 5 on the standard layer. Divided trunks show up as a thicker line than
undivided trunks.

Also worth noting that Google maps doesn't display divided highways any
different than undivided highways. They all are colored yellow.

-Evin (compdude)

On Oct 14, 2017 1:20 PM, "Bradley White"  wrote:

> On Sat, Oct 14, 2017 at 12:53 PM, Nathan Mills  wrote:
> > 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.
>
> Could you show me an example of a US road atlas that explicitly
> demarcates expressways? I have legitimately tried to find one but have
> not been able to. Most US maps I've seen show freeways & toll roads
> explicitly, but not expressways. Some maps might use a different
> casing style to denote a divided highway, but the underlying color of
> the line still represents the importance of the road. Which is the
> point I'm trying to get at, that a highway being divided or not is
> orthogonal to its importance.
>
> > 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)
>
> This is incorrect. 'Tag:highway=primary' gives "A highway linking
> large towns". 'Tag:highway=trunk' gives "Important roads that are not
> motorways", and explicitly lists in the US tagging application that "a
> major intercity highway" is a correct use of the trunk tag in the US.
> 'Highway:international_equivalence' as well as 'Key:highway' give the
> same set of definitions. Where are you seeing that primary is "the
> most important non-motorway route between two cities"?
>
> ___
> 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] Trunk

[Evin Fairchild]

Still don't agree about osmand making trunks look like a divided highway/
expressway but whatever. Either way, if we tag only divided highways as
trunk just because a certain renderer makes trunk roads look like divided
highways (BTW, this is a better term to use here than expressway because it
causes less confusion), that actually is a textbook example of tagging for
the renderer.

-Evin (compdude)

On Oct 14, 2017 10:57 AM, "Bradley White" <theangrytom...@gmail.com> wrote:

> I use Osmand frequently; the point of the cased-line style of the
> trunk & motorway tags is, agreeing with Paul here, to show some degree
> of access control. This is in-line with many paper road atlases,
> especially older ones. My point was that third-party applications
> choosing to use this style is their own pejorative, and we should not
> be basing tagging definitions on how third-party apps use the data. In
> regard to the trunk debate, I understand and fully respect Paul's
> position, but I personally disagree. I'm hoping the debate here will
> encourage the US OSM community in getting closer to an agreeable
> definition for trunk.
>
> On Sat, Oct 14, 2017 at 10:49 AM, Evin Fairchild <evindf...@gmail.com>
> wrote:
> > To add onto what Bradley was saying about third-party applications, I
> just
> > want to add that I've done some fact-checking about a claim that Paul
> made
> > in a previous email about how Osmand renders trunks under the assumption
> > that they are expressways (to be clear, by this I mean divided highways
> w/
> > at-grade intersections). After some fact-checking, this claim receives a
> > truth rating of completely FALSE.
> >
> > Anyway, I looked at how Osmand renders motorways versus trunk and I don't
> > know how it is that you, Paul, can say that trunk is assumed to be like
> an
> > expressway  in Osmand's render. That is simply not true. The motorway in
> > Osmand, for those who are unfamiliar, is red with a thin blue outline
> around
> > it, whereas trunk is just an orange-red line without any other color
> > outlining it. This makes it look more like a single-carriageway road and
> > less like an expressway like Paul falsely claims. All it looks like is a
> > road that is of higher-importance than primary, and does NOT at all look
> > like it could be an expressway. Usually, when maps show a divided
> highway w/
> > at-grade intersections, it looks similar to a freeway, but a different
> > color, whereas an undivided two-lane road typically looks nothing like an
> > expressway or freeway. Thus, it is complete and utter lie to say that
> Osmand
> > makes the assumption that trunk roads are expressways. I don't know how
> > mkgmap shows trunk vs. motorway since I don't have a Garmin and thus
> cannot
> > test it out, but I don't trust that Paul is telling the truth here
> either.
> >
> > It's important to make truthful claims here, Paul; from now on, I will
> have
> > a VERY difficult time trusting anything you say. I know what I brought up
> > was kind of a side point, but I think it's important to call out BS when
> I
> > see it.
> >
> > -Evin (compdude)
> >
> >
> > On Sat, Oct 14, 2017 at 10:23 AM, Bradley White <
> theangrytom...@gmail.com>
> > 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 ro

Re: [Talk-us] Trunk

[Evin Fairchild]

To add onto what Bradley was saying about third-party applications, I just
want to add that I've done some fact-checking about a claim that Paul made
in a previous email about how Osmand renders trunks under the assumption
that they are expressways (to be clear, by this I mean divided highways w/
at-grade intersections). After some fact-checking, this claim receives a
truth rating of *completely FALSE*.

Anyway, I looked at how Osmand renders motorways versus trunk and I don't
know how it is that you, Paul, can say that trunk is assumed to be like an
expressway  in Osmand's render. That is simply not true. The motorway in
Osmand, for those who are unfamiliar, is red with a thin blue outline
around it, whereas trunk is just an orange-red line without any other color
outlining it. This makes it look more like a single-carriageway road and
less like an expressway like Paul falsely claims. All it looks like is a
road that is of higher-importance than primary, and does NOT at all look
like it could be an expressway. Usually, when maps show a divided highway
w/ at-grade intersections, it looks similar to a freeway, but a different
color, whereas an undivided two-lane road typically looks nothing like an
expressway or freeway. Thus, it is complete and utter lie to say that
Osmand makes the assumption that trunk roads are expressways. I don't know
how mkgmap shows trunk vs. motorway since I don't have a Garmin and thus
cannot test it out, but I don't trust that Paul is telling the truth here
either.

It's important to make truthful claims here, Paul; from now on, I will have
a VERY difficult time trusting anything you say. I know what I brought up
was kind of a side point, but I think it's important to call out BS when I
see it.

-Evin (compdude)


On Sat, Oct 14, 2017 at 10:23 AM, 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
> construction. It would be absurd to me to tag them as being second in
> importance only to motorways just because they are well-built roads,
> because they're unimportant outside of getting around the relatively
> small Reno-Sparks metropolitan area.
>
> The "highway" key is about importance. The only category we have
> full-stop made equivalent with a type of road design is "motorway".
> From trunk on down, it is just different grades of importance. These
> are how the definitions are listed on the 'Key:highway' page, which I
> consider to be definitive. The fact that the words "trunk", "primary",
> "secondary", ... are used is an artifact of the UK roots of OSM. Had
> this project started in the US, the keys would probably be "freeway",
> "principal_artery", "major_artery", "minor_artery", "major_collector",
> ... leaving UK users scratching their heads trying to figure out how
> to adapt these definitions to their own network. In countries with
> signposted expressway systems, it is meaningful in understanding the
> road network to equate trunk with expressway, so they do that. I don't
> think doing the same is meaningful in the U.S. given how much
> variability and inconsistency there is with how and where expressways
> are constructed.
>
> > Even a lot of renderers make this same assumption:  mkgmap 

Re: [Talk-us] Trunk

[Evin Fairchild]

The concept of expressway is not as well known as a freeway. Many people,
especially in places like NYC, might consider expressways and freeways to
be interchangeable terms. Heck, even in Tulsa, you have the Broken Arrow
Expressway, and the Sand Springs Expressway, which, despite being called
expressways, have full access control and no at-grade intersections and no
places where one crosses into oncoming traffic.

Also, as for super-twos, let's not discuss that right now. I'd prefer us to
stick to talking about trunk roads *only*, since that's the topic of this
thread. Let's not go on that tangent, and I'd like to know what you think
about how the standard Mapnik render differentiates between undivided and
divided trunk roads. It's a pretty obvious distinction to me, and you can
*easily* tell the two apart. If anything, I think that that helps us out
here.

On Fri, Oct 13, 2017 at 9:26 PM, Paul Johnson <ba...@ursamundi.org> wrote:

> On Fri, Oct 13, 2017 at 11:00 PM, Evin Fairchild <evindf...@gmail.com>
> wrote:
>
>> Another thing worth adding is that if we do decide to tag two-lane roads
>> as trunk, you will still be able to tell the undivided two-lane roads apart
>> from the divided four-lane roads, even at zoom 5. I'm sure many of you have
>> noticed if you've looked at Canada at zoom 5, you can see that some of the
>> trunks are thicker than others. If you zoom in more, you'll notice that
>> said thicker roads are divided/ dual carriageway, whereas the thinner ones
>> are undivided roads. Also, the same is true with motorways, so we could
>> theoretically tag super-twos as motorways and still tell them apart from
>> actual Interstate freeways. This has been done extensively in New Brunswick
>> and Nova Scotia, and I quite like it. But we probably shouldn't go down
>> that rabbit hole at this point...
>>
>
> I also disagree with the idea that (at least in the US, though also
> relevant to the rest of North America to a lesser extent) a super-2
> qualifies as a motorway.  I generally consider the minimum requirements for
> motorway as dual carriageway, with each carriageway having a minimum of two
> lanes, barring temporary traffic controls (such as a reduction to one lane
> each way, undivided, very common when a DOT needs to restrict access
> completely to one motorway for routine maintenance or immediately after a
> major disaster; most frequently personally experienced in California,
> Oklahoma and Kansas, and routinely planned for to the extent that permanent
> crossover "X" links are installed regularly in Kansas and Oklahoma).
>
> ___
> 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] Trunk

[Evin Fairchild]

Another thing worth adding is that if we do decide to tag two-lane roads as
trunk, you will still be able to tell the undivided two-lane roads apart
from the divided four-lane roads, even at zoom 5. I'm sure many of you have
noticed if you've looked at Canada at zoom 5, you can see that some of the
trunks are thicker than others. If you zoom in more, you'll notice that
said thicker roads are divided/ dual carriageway, whereas the thinner ones
are undivided roads. Also, the same is true with motorways, so we could
theoretically tag super-twos as motorways and still tell them apart from
actual Interstate freeways. This has been done extensively in New Brunswick
and Nova Scotia, and I quite like it. But we probably shouldn't go down
that rabbit hole at this point...

-Evin (Compdude)

On Fri, Oct 13, 2017 at 8:41 PM, Dave Swarthout 
wrote:

> >Can you explain what your goal/desire is for these non-divided highways
> >to be labeled trunk?  Is it about a small-scale render showing them,
> >when if they are primary, Alaska looks empty when it shouldn't?  Some
> >sense of hierarchical views of road networks?  Something else?
>
> @Bradley - I didn't tag them originally and don't particularly care how
> they're tagged. Routing in rural Alaska is pretty simple because there's
> only one way to get from Anchorage to Fairbanks and to Homer, where I live
> LOL. That's why I prefaced my comment by saying I have no stake in the
> outcome of this conversation. I only want to stay tuned in so I can
> understand any changes to our rationale.
>
> Dave
>
> On Sat, Oct 14, 2017 at 10:19 AM, Bradley White 
> wrote:
>
>> > Message: 4
>> > Date: Fri, 13 Oct 2017 21:24:20 -0500
>> > From: Paul Johnson 
>> > To: OpenStreetMap talk-us list 
>> > Subject: Re: [Talk-us] Trunk
>> > Message-ID:
>> > 

Re: [Talk-us] Trunk

[Evin Fairchild]

On Oct 13, 2017 7:11 PM, "Bradley White"  wrote:

Lots of words ahead, you have been warned...

I disagree with trying to use the "highway=" tag to describe what
"kind" of road a given way is in the US, except for freeways. The
"highway" key is for importance, or, how prominently a road should
show on the map. We have other tags to describe completely the
physical attributes of a road. If there existed an "if-then" algorithm
to determine how prominently a road should show on the map only from
physical attributes, we wouldn't need this tag at all.

But we do. The U.S. needs this tag because form often does not follow
function. There are many plain-old two-lane roads that are important
enough for cross-country navigation that they should show at low zoom
along with the interstate system. There are also countless high-speed,
high-access-control (no driveways, limited intersections), multi-lane,
divided arteries that do little more than connect suburbs to more
important roads. These roads do NOT need to show at low zoom, despite
being a high-quality road.

Consider instead that we trade off "highway=motorway" with
"highway=1", "highway=trunk" with "highway=2", etc., which represents
only the importance of a road in the network. In the US, it is fair to
take freeways as an entire class to be the most important roads. A
freeway has strict & verifiable physical criteria (aside from a small
fringe set of exceptions), they are signposted and unambiguous, it is
a term well-understood in common vernacular that the average map
consumer would expect to see shown on a map, and they are nearly
always THE most important roads in the area. It is easy to say both
that "this is a freeway" and that "these are the most important kinds
of roads". In fact, this is the case in nearly all developed countries
on the planet. So, we instead define "highway=1" to just be
"highway=motorway" since it is nearly always the same thing.

In Europe, it would also be fair to use "highway=2" to simply
represent expressways as a class. Expressways (in the countries that
have expressway systems) are built to a verifiable design criteria,
are signposted and unambiguous (see:
https://en.wikipedia.org/wiki/Limited-access_road), are something the
average map consumer in the area is both familiar with and would
expect to see on a map, and are nearly always second in importance to
the motorway system. Again, it is easy to say both that "this is an
expressway" and "this is the second most important kind of roads". So,
in countries that have designated expressway systems, they define
"highway=2" to just be "highway=trunk" since it is nearly always the
same thing.

This situation is NOT the case for the majority of the US, and trying
to use this definition is what has been leading to unresolved
confusion about the purpose of the trunk tag. MUTCD gives a definition
of "divided highway with partial control of access". This is rather
vague, and as stated above, means countless unimportant suburban
arteries would now be considered the second most important roads in
the country. Many states haven't even adopted usage of this term at
all. I have seen planning documents of some counties that have
multiple grades of "expressways" depending on intersection distance,
speed limits, etc. Outside of bona-fide urban expressway systems like
the Santa Clara Expressway system, I think it's a nearly meaningless
term.

I have heard two kinds of attempts to describe what constitutes an
expressway and thus a trunk road in the US. The first attempt is the
"it's like a freeway but only kind of" definition. I don't like this
definition because if we're going to trade off an entire class of
importance with an entire class of road design, we should at least be
perfectly clear about what kinds of roads we are talking about, as we
are with freeways. The second attempt is to establish some kind of
verifiable physical criteria: divided, minimum 45 mph speed limit,
limited intersections, maybe has grade-separated interchanges. There
are also many problems with this approach. As discussed above, it
grades swaths of overbuilt roads as being more important that they
actually are. It makes roads that are crucial for navigation but don't
meet an arbitrary checklist difficult to pick out from the sea of
primary roads that the rural US currently exhibits. Furthermore, it
leads to the current situation of random splotches of deep-orange
lines visible at the same level as the interstate system scattered
across the US, which provides absolutely no meaning to the average
US-based map consumer. Being frank, I can't understand at all why
anyone considers the current state of trunk road tagging in rural
parts of the US desirable or useful or illuminating at all.

I propose defining trunk in the US to mean, formally, "The most
important non-motorway roads in the country". An extended definition
for the US follows below:

--
Trunk roads are the 

Re: [Talk-us] South Carolina State Highways - primary overload

[Evin Fairchild]

I think the reason why things like this happen is because the highway
tagging scheme in OSM was modeled off of UK's road-classification system
and really isn't compatible with the road-classification system in the US.
When I was new here three years ago, I found it kind of odd that there
wasn't a way to distinguish state highways from other arterials. Perhaps
this user feels like all state highways should be tagged as primary to
distinguish them from other roads. That's kind of how I felt when I first
joined OSM, but I didn't go around unilaterally changing all of the state
highways in Washington to primary.

However, I cannot explain why that one road you mentioned is marked as
trunk.


On Sun, Dec 8, 2013 at 9:42 PM, James Mast rickmastfa...@hotmail.comwrote:

 Is it just me, or are there way too many primary state highways when some
 of them should really be secondary instead?  The US Highways should
 normally be the primary/trunk highways and only a few select State
 Highways should be primary or trunk.  To be honest, it seems that 98% of
 all the State highways segments in SC are marked as primary right now.

 There is no way almost all of the State Highways in SC can be primary.
 Just look at almost any other state.  None are overloaded with primaries.
 One of the major routes that sticks out to me is SC-64 near the Savannah
 River Site where it's marked as trunk going to the security gate [1].
 Now, if the Savannah River Site didn't exist and the highway was still open
 to the public past that point, I wouldn't agrue the point of it being trunk
 or primary.  But since that segment of state highway goes nowhere anymore
 after leaving US-278 going West, this would be a classic case of it having
 to be secondary, or maybe even being tertiary.

 So, does anybody else agree with me on this subject of primary overload
 in South Carolina?  If so, how do we go about fixing this with a reasonable
 approach?  Looking at some of the history of some of the ways, it seems
 that only one user was doing the upgrade from secondary to primary/trunk
 over the past 4+ months.  He also did some of this in Georgia, but not to
 the extent as in South Carolina.  Unfortunately, this user did it over 200+
 changesets, so, if reverting was the option, it would take forever I would
 think.

 -James

 [1] - http://www.openstreetmap.org/#map=14/33.2388/-81.4205layers=N

 ___
 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] a reminder for armchair mappers

[Evin Fairchild]

Putting notes in the tags may be helpful, but in the simple tagging mode
in P2 (does anyone still use that? I do, b/c I don't like iD), you can't
see them and some mapper might not get the message in the note. Personally,
pretty much all my edits are armchair mapping, but it's generally in my
local area, so I often have knowledge of things on the ground before I go
adding or deleting it from OSM.

-Compdude


On Fri, Dec 6, 2013 at 10:01 AM, Natfoot natf...@gmail.com wrote:

 I also agree that putting notes in the tags are helpful to some of us that
 are armchair mappers.  I will see the tags sooner than the history data. I
 tend to map around railroads using the imagery and Tiger data and tags.
 -Nathan


 On Fri, Dec 6, 2013 at 9:29 AM, Martijn van Exel m...@rtijn.org wrote:

 That is a great point and something I feel strongly about, having
 created armchair mapper's tools like Battle Grid and Maproulette.

 I will make some time to put in a warning notice into these tools that
 would pop up the first time folks use it. What would a good, concise,
 cautionary note look like?

 On Fri, Dec 6, 2013 at 9:08 AM, Richard Welty rwe...@averillpark.net
 wrote:
  if you see a discrepancy between aerial imagery and OSM, before you
  go adding/changing stuff, check on the history of the stuff that's there
  and see if another mapper has worked on things recently (for some
  value of recently.) i have done a bunch of work in the past month
  adding in a new traffic circle on US 4 in Rensselaer County, NY,
  using GPS traces. as part of the process,  i removed a slip ramp
  from I-90 that was taken out by DOT when they built the new
  circle. i just now discovered that another mapper added the slip
  ramp back in, presumably because it's in the Bing imagery, which
  is at this point 2 or 3 years old.
 
  this isn't the first time i've been through this; a year or so back
  a couple of armchair mappers repeatedly changed a part of Troy
  to match obsolete imagery and i kept having to ask them not to
  and put back in the recent changes. i now put README tags on
  the ways but if i delete something i have no place to put a
  README tag.
 
  imagery goes out of date. armchair mappers must never forget
  that. if the imagery doesn't match the map, contact a local mapper
  if you can identify one. you could be fixing something that wasn't
  actually broken.
 
  thanks,
 richard
 
 
 
  ___
  Talk-us mailing list
  Talk-us@openstreetmap.org
  https://lists.openstreetmap.org/listinfo/talk-us
 



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

 ___
 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


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

[Evin Fairchild]

Re the comment by  Nathan: “I'm still confused as to why the consumers of a 
relation can't use the forward/backward roles…” The forward/backward roles only 
make sense on one-way roads. Other than that, which way is forward and which 
way is backward? Depends on which way you’re driving down the road. The same 
thing is true about the left/right thing used in some tags. When I created 
relations for the WA state routes, I put the cardinal directions in the role 
for each way. I only used forward in the role when there were separate 
relations for each direction of the way.

 

In general, I don’t agree with this proposal unless the highway is divided for 
its entire length. There are only three state highways in Washington that I can 
think of where this is true. I know for sure that one of them (WA 512) has a 
separate relation for each direction, but I don’t know about the other two.

 

-Compdude

 

From: Nathan Mills [mailto:nat...@nwacg.net] 
Sent: Monday, November 18, 2013 12:28 PM
To: OpenStreetMap U.S.
Subject: Re: [Talk-us] Separate relations for each direction of US  State 
highways.

 

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.com wrote:

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] Ferries

[Evin Fairchild]

Shouldn't we be discussing this on the tagging mailing list rather than the
talk-us mailing list? After all, ferries are all around the world, so we
should discuss this at the tagging mailing list rather than here if we want
to introduce a new highway=ferry_link tag.

 

-Compdude

 

From: Ivan Komarov [mailto:jkoma...@gmail.com] 
Sent: Friday, November 8, 2013 9:16 AM
To: Paul Johnson
Cc: talk-us
Subject: Re: [Talk-us] Ferries

 

I'd vote for introducing a new tag, that is highway=ferry_link, rather than
trying to use an existing one that does not describe the object correctly.
There used to be and there will be disputes on this topic unless we have it
fixed. Introducing a new tagging scheme will cause some issues for a while,
but on the long run it would work better, I believe. 

On 8 Nov 2013 07:04, Paul Johnson ba...@ursamundi.org wrote:

I think highway=unclassified works, particularly if it's the fire lane used
for exiting the ferry that's always kept free of the ferry queue; not sure
how I'd tag the queue lot.

 

On Fri, Nov 8, 2013 at 8:56 AM, Greg Troxel g...@ir.bbn.com wrote:


Martijn van Exel marti...@telenav.com writes:

 It's the other way around, really. We're adjusting our routing logic
 to adapt to OSM. Referring to the wiki, a service road is 'Generally
 for access to a building, motorway service station, beach, campsite,
 industrial estate, business park, etc.' - so by that definition, a
 service road would typically only occur at the beginning or the end of
 the route, and that's what we tell our routing engine to do. If it
 were to turn out that this definition of what a service road is, is in
 fact not how it is generally used in mapping, then we'd need to
 revisit the wiki (and our routing rules) - but from what I have seen
 in my pretty extensive mapping experience in the U.S., the definition
 generally holds. So it makes sense to me to suggest a different
 tagging for these ferry access routes, not only (and not even
 primarily) to satisfy our or any third party logic using the data, but
 to bring more consistency to OSM in general.

That's fair enough.  I got the wrong impression earlier (perhaps my
misreading) that this was about a particular routing engine rather than
the documented semantics.

So perhaps highway=ferry_link, or perhaps the roads should just be
highway=unclassified.



___
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

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

Re: [Talk-us] Ferries

[Evin Fairchild]

But let's not forget that there's lots of ferries in Europe too! This would
not just be a tag for use here on ferry routes here in the Salish Sea, but
also ones in other parts of the world.

 

-Compdude

 

From: Paul Johnson [mailto:ba...@ursamundi.org] 
Sent: Friday, November 8, 2013 6:20 PM
To: talk-us
Subject: Re: [Talk-us] Ferries

 

Probably, but in this conversation's defense, Washington State has the
world's largest ferry fleet by far, so it's much more a Washingtonism than
anything.

 

On Fri, Nov 8, 2013 at 7:17 PM, Evin Fairchild evindf...@gmail.com wrote:

Shouldn't we be discussing this on the tagging mailing list rather than the
talk-us mailing list? After all, ferries are all around the world, so we
should discuss this at the tagging mailing list rather than here if we want
to introduce a new highway=ferry_link tag.

 

-Compdude

 

From: Ivan Komarov [mailto:jkoma...@gmail.com] 
Sent: Friday, November 8, 2013 9:16 AM
To: Paul Johnson
Cc: talk-us
Subject: Re: [Talk-us] Ferries

 

I'd vote for introducing a new tag, that is highway=ferry_link, rather than
trying to use an existing one that does not describe the object correctly.
There used to be and there will be disputes on this topic unless we have it
fixed. Introducing a new tagging scheme will cause some issues for a while,
but on the long run it would work better, I believe. 

On 8 Nov 2013 07:04, Paul Johnson ba...@ursamundi.org wrote:

I think highway=unclassified works, particularly if it's the fire lane used
for exiting the ferry that's always kept free of the ferry queue; not sure
how I'd tag the queue lot.

 

On Fri, Nov 8, 2013 at 8:56 AM, Greg Troxel g...@ir.bbn.com wrote:


Martijn van Exel marti...@telenav.com writes:

 It's the other way around, really. We're adjusting our routing logic
 to adapt to OSM. Referring to the wiki, a service road is 'Generally
 for access to a building, motorway service station, beach, campsite,
 industrial estate, business park, etc.' - so by that definition, a
 service road would typically only occur at the beginning or the end of
 the route, and that's what we tell our routing engine to do. If it
 were to turn out that this definition of what a service road is, is in
 fact not how it is generally used in mapping, then we'd need to
 revisit the wiki (and our routing rules) - but from what I have seen
 in my pretty extensive mapping experience in the U.S., the definition
 generally holds. So it makes sense to me to suggest a different
 tagging for these ferry access routes, not only (and not even
 primarily) to satisfy our or any third party logic using the data, but
 to bring more consistency to OSM in general.

That's fair enough.  I got the wrong impression earlier (perhaps my
misreading) that this was about a particular routing engine rather than
the documented semantics.

So perhaps highway=ferry_link, or perhaps the roads should just be
highway=unclassified.



___
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

 

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

Re: [Talk-us] Complex intersection mapping

[Evin Fairchild]

Agreed, it's really important that when people make a road be
dual-carriageway that they change the lane count and make sure both
directions have the applicable route relations.

 

-Compdude

 

From: James Mast [mailto:rickmastfa...@hotmail.com] 
Sent: Friday, November 8, 2013 6:47 PM
To: Martijn van Exel; OSM US Talk
Cc: ste...@telenav.com; krist...@telenav.com; Stack, Robert;
chr...@telenav.com
Subject: Re: [Talk-us] Complex intersection mapping

 

Martijn (and other telenav workers),

I just happened to see some intersections in my area tweaked today.  If
you're going to be changing the intersections, can you at least please
update the lane count on said ways if it's already been added at the same
time?  I mean, if a way is on one side 4 lanes, and you split it into two
separate ways, odds are both of them are 2 lanes each.  Yet, the lane count
on them is still 4, which can also play screwy with the routing engines.

Also, can you please update any relations that are attached to the highways?
I'm going to bring up Changeset 18789658
http://www.openstreetmap.org/browse/changeset/18789658  as an example,
which is the intersection of US-22 Business, PA-48,  the Orange Belt in
Monroeville, PA.  The two numbered routes were broken today (amazingly the
Orange Belt wasn't) with the change from a 1-point intersection to a 4-point
intersection.  I personally think that a 1-point intersection was completely
justified for this intersection because of only two directions being divided
when exiting it.  Anyways, US-22 Business now has a gap because of the new
ways for it, and PA-48 now doesn't end @ the intersection anymore because of
the divided highway from the North being extended outside the main
intersection.  And, to be honest, I'm also toying with the idea of reverting
said changeset to repair the relations and make it a 1-point intersection
again, but wanted to bring it up here on the list first before doing that to
prevent an edit war.

So, if you keep doing it that way, can you please keep the collateral damage
to a minimum when it comes to lane counts and highway relations?  I would
really appreciate it when stuff like that was already tagged correctly
doesn't need to be fixed again. :)


-James (rickmastfan67)



 From: marti...@telenav.com
 Date: Mon, 14 Oct 2013 11:42:53 -0600
 To: talk-us@openstreetmap.org
 CC: ste...@telenav.com; krist...@telenav.com; robe...@telenav.com;
chr...@telenav.com
 Subject: [Talk-us] Complex intersection mapping
 
 Hi all,
 
 Here at Telenav we have been looking at complex intersections and we
 have set about editing some of these intersections in a way we feel
 represents the situation on the ground better than their original
 state, and because of that, works better for us. We have received some
 feedback on our edits so we wanted to take a step back and see what we
 (as the OSM community) think is the preferred way to map these
 intersections.
 
 So what are we talking about? Intersections like this one, where one
 or more dual carriageways come together at an at-grade intersection:
 

https://www.evernote.com/shard/s9/sh/6438c196-bb92-4f66-81dc-9b75186286ba/0e
8f07ff527c6a85c0dec426b9b79f1e
 
 One of my colleagues at Telenav has remapped this intersection as follows:
 

https://www.evernote.com/shard/s9/sh/3491f1fe-6afa-4571-bc43-7cb31c9c2625/9d
d47d1445fdcf03d3f0bbd93b8e0f92
 
 The main difference, and the source of some feedback we have received
 over the past few days, is that the dual carriageway roads are
 straightened out, creating multiple intersection nodes (4 in this
 case) instead of the original single intersection node that connects
 all the incoming and outgoing ways. That technique turns out to yield
 more reliable and correct routing and guidance ('keep left, turn
 right') through these intersections in our testing. But of course,
 that cannot dictate how we map as a community, so let's discuss.
 
 Some of the feedback we have received about these edits points to a
 statement on this wiki page:
 https://wiki.openstreetmap.org/wiki/TIGER_fixup#Braided_streets: 'It
 is a reasonable and well-used technique to bring the ways of dual
 carriageways back to a single point at intersections to facilitate and
 simplify the mapping of control devices and turn restrictions.' In my
 mapping across the US, my personal experience has been that this
 technique is in fact used, but the 'after' technique with straightened
 out ways is actually much more common. I personally prefer that
 technique as well - I think it is more pleasing to the eye, represents
 what is on the ground better, and is and easier to read. So my feeling
 was that this mapping practice would not be disputed. It turns out I
 was wrong, so I want to see what the consensus is on mapping
 intersections of this type - or perhaps there is none and we can work
 together to get there?
 
 Thanks,
 Martijn
 --
 Martijn van Exel
 OSM data specialist
 Telenav
 http://www.osm.org/user/mvexel
 

Re: [Talk-us] Ferries

[Evin Fairchild]

Re the ferry waiting areas, I've been tagging each lane as an individual way
with the tags highway=service, the lane # in the name=* tag, and have made
it be one-way. I have also done this for each lane going into the
tollbooths. See the Mukilteo ferry terminal [1] and Edmonds ferry terminal
[2] for examples. I was not the first to do this; it was previously done at
some of BC Ferries' terminals, for example take a look at the Tsawwassen
terminal [3] and the Horseshoe Bay terminal. [4] What do you guys think of
this way of mapping ferry terminals. I know it's kinda going off on a
tangent, but I just thought it would be good to bring up.

 

Also, what is the proper way of mapping ferry routes when the ferries have
multiple berths/ docks at a terminal (and they use whatever one they feel
like), like in the Horseshoe Bay example, and many BC Ferries' major
terminals for that matter? Martijn, could you do a routing test on these
ferry routes and tell me how it works? The wiki says to connect ferry routes
directly to a road on land rather than another ferry route way in order to
ensure proper routing.

 

-Compdude

 

Links:

[1] http://www.openstreetmap.org/#map=18/47.94864/-122.30474

[2] http://www.openstreetmap.org/#map=17/47.81123/-122.38429
http://www.openstreetmap.org/#map=17/47.81123/-122.38429layers=N 

[3] http://www.openstreetmap.org/#map=16/49.0074/-123.1309

[4] http://www.openstreetmap.org/#map=16/49.3721/-123.2745

 

 

From: Clifford Snow [mailto:cliff...@snowandsnow.us] 
Sent: Friday, November 8, 2013 7:19 PM
To: Paul Johnson
Cc: talk-us
Subject: Re: [Talk-us] Ferries

 

If we have consensus on what the US thinks is appropriate, then I agree that
it belongs on the tag list. 

 

Does anyone have objection to bringing a proposal to create a
highway=ferry_link tag? I'd especially like to hear from people working with
routing (that's you Telenav)

 

Is ferry_link the appropriate tag? The ferries I ride all have a queue area.
Do we tag the queues like parking lots with a way through the queue? 

 

On Fri, Nov 8, 2013 at 6:19 PM, Paul Johnson ba...@ursamundi.org wrote:

Probably, but in this conversation's defense, Washington State has the
world's largest ferry fleet by far, so it's much more a Washingtonism than
anything.

 

On Fri, Nov 8, 2013 at 7:17 PM, Evin Fairchild evindf...@gmail.com wrote:

Shouldn't we be discussing this on the tagging mailing list rather than the
talk-us mailing list? After all, ferries are all around the world, so we
should discuss this at the tagging mailing list rather than here if we want
to introduce a new highway=ferry_link tag.

 

-Compdude

 

From: Ivan Komarov [mailto:jkoma...@gmail.com] 
Sent: Friday, November 8, 2013 9:16 AM
To: Paul Johnson
Cc: talk-us
Subject: Re: [Talk-us] Ferries

 

I'd vote for introducing a new tag, that is highway=ferry_link, rather than
trying to use an existing one that does not describe the object correctly.
There used to be and there will be disputes on this topic unless we have it
fixed. Introducing a new tagging scheme will cause some issues for a while,
but on the long run it would work better, I believe. 

On 8 Nov 2013 07:04, Paul Johnson ba...@ursamundi.org wrote:

I think highway=unclassified works, particularly if it's the fire lane used
for exiting the ferry that's always kept free of the ferry queue; not sure
how I'd tag the queue lot.

 

On Fri, Nov 8, 2013 at 8:56 AM, Greg Troxel g...@ir.bbn.com wrote:


Martijn van Exel marti...@telenav.com writes:

 It's the other way around, really. We're adjusting our routing logic
 to adapt to OSM. Referring to the wiki, a service road is 'Generally
 for access to a building, motorway service station, beach, campsite,
 industrial estate, business park, etc.' - so by that definition, a
 service road would typically only occur at the beginning or the end of
 the route, and that's what we tell our routing engine to do. If it
 were to turn out that this definition of what a service road is, is in
 fact not how it is generally used in mapping, then we'd need to
 revisit the wiki (and our routing rules) - but from what I have seen
 in my pretty extensive mapping experience in the U.S., the definition
 generally holds. So it makes sense to me to suggest a different
 tagging for these ferry access routes, not only (and not even
 primarily) to satisfy our or any third party logic using the data, but
 to bring more consistency to OSM in general.

That's fair enough.  I got the wrong impression earlier (perhaps my
misreading) that this was about a particular routing engine rather than
the documented semantics.

So perhaps highway=ferry_link, or perhaps the roads should just be
highway=unclassified.



___
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

Re: [Talk-us] Ferries

[Evin Fairchild]

On Mon, Oct 21, 2013 at 11:45 AM, Martijn van Exel marti...@telenav.comwrote:

 Evin - a footway would not affect our routing results as those would
 only include ways navigable by motorized vehicles. Or perhaps I am not
 understanding what you did.  Clifford - this would hopefully also
 answer your question about walking routing: currently, we don't.)


Oh, I thought that your routing tests were involving walking routes, too,
rather than just routing with a car. That's why I mentioned that I added
the footways on the ferry docks.

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

Re: [Talk-us] Ferries

[Evin Fairchild]

If you already tried routing through those two ferry routes, I'd suggest
trying again, since I just added a footway onto the passenger terminals.
Previous routing tests would have produced inaccurate results.

-Compdude


On Fri, Oct 18, 2013 at 8:56 AM, Clifford Snow cliff...@snowandsnow.uswrote:


 On Fri, Oct 18, 2013 at 8:15 AM, Evin Fairchild evindf...@gmail.comwrote:

 Interesting idea, but since there's not a whole ton of ferry terminals
 worldwide, I don't know if it would be worthwhile to create a whole new
 highway=* tag just for this. I don't really mind the service=ferry tag; it
 would be less complicated in getting it to render.


 If service=ferry tag is acceptable to everyone, what about passenger only
 ferries? For example, http://osm.org/go/WIdFBwTUx-- includes both car
 ferry, and passenager only ferries here in Seattle. How does Telenav do
 walking routing?




 --
 Clifford

 OpenStreetMap: Maps with a human touch

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

Re: [Talk-us] Ferries

[Evin Fairchild]

Interesting idea, but since there's not a whole ton of ferry terminals
worldwide, I don't know if it would be worthwhile to create a whole new
highway=* tag just for this. I don't really mind the service=ferry tag; it
would be less complicated in getting it to render.

-Compdude


On Thu, Oct 17, 2013 at 7:45 PM, Clifford Snow cliff...@snowandsnow.uswrote:


 On Thu, Oct 17, 2013 at 2:44 PM, Evin Fairchild evindf...@gmail.comwrote:

 When I made relations for all the state highways in Washington, I
 included the ferry routes and the ferry access roads in the highway route
 relation. I also have done some edits to ferry terminals, adding a way for
 each lane in the ferry waiting lot. This was previously done at some ferry
 terminals in BC.

 I agree with tagging the ferry terminal roads with service=ferry.


 The service=ferry works for me, but I'd like to point out that it isn't
 consistent with other highway tags linking different road segments. The
 wiki describes motorway_link, primary_link, etc. Rather than describe the
 normally short road segment as a service road, why not highway=ferry_link?

 service=ferry does have the advantage that the render wouldn't stumble.



 --
 Clifford

 OpenStreetMap: Maps with a human touch

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

Re: [Talk-us] Freeway directions

[Evin Fairchild]

This is not a concern in WA, there's no state highways that have the same
number as US or Interstate highways.

-compdude


On Thu, Oct 17, 2013 at 10:31 PM, Eric Fischer e...@pobox.com wrote:

 California gives State, US, and Interstate roads unique signed numbers
 within the state, but not all states do. Interstate 64 in southern Indiana
 is close enough to State Road 64 to cause frequent confusion.

 Eric


 On Thu, Oct 17, 2013 at 8:52 PM, Tod Fitch t...@fitchdesign.com wrote:

 On Oct 17, 2013, at 6:11 PM, Nathan Mills wrote:

  On 10/17/2013 1:03 PM, Richard Welty wrote:
 
  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.
 

 I can't say for the urban auxiliary (three digit) freeways, but the
 single and double digit Interstates all seem to have on ramp signs that use
 their nominal direction rather than the compass direction at that
 particular location. At least that is my understanding from what I've read
 about the rules and conventions that are supposed to be used and I have
 never noticed an exception.

 For what it is worth, it is my understanding that within a state the use
 of a particular number, at least outside of triple digit urban beltways and
 penetration Interstates, is supposed to be unique. So if I-10 goes through
 your state, there will be no US10 nor a state highway 10. I haven't paid
 much attention to this in other states I've visited but it seems to hold
 true for California. If true throughout the US then it could be used to
 help validate highway route numbers.

 Confusion in California comes in two flavors: In Southern California
 there is a popular tendency to call freeways by a name (e.g. The Ventura)
 and use the actual direction the road goes for that named segment
 (east/west for the Ventura) when giving directions. But the named segment
 might be on a US or Interstate with a different nominal direction. This bit
 me years ago when we were mailing out wedding directions and I assumed the
 on ramp from the hotel area would be labeled for the eastbound Ventura
 Freeway when, upon checking, it turned out to be labeled for southbound
 US101.

 In the San Francisco Bay Area the confusion comes from the fact that the
 only Interstate to enter the area is I-80. So all the urban auxiliary
 (three digit) freeways have to have a suffix of 80 (even number implying
 east/west) even if the road is north/south. So we have 280, 580, 680, 880,
 etc. all going in different directions. Southern California avoids this by
 having I-5, I-8, I-10 and I-15 enter the area, so I-210 is basically
 east/west while I-405 and I-215 are basically north/south.

 -Tod
 ___
 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


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

Re: [Talk-us] Ferries

[Evin Fairchild]

When I made relations for all the state highways in Washington, I included
the ferry routes and the ferry access roads in the highway route relation.
I also have done some edits to ferry terminals, adding a way for each lane
in the ferry waiting lot. This was previously done at some ferry terminals
in BC.

I agree with tagging the ferry terminal roads with service=ferry.

-Compdude


On Thu, Oct 17, 2013 at 9:31 AM, Martijn van Exel marti...@telenav.comwrote:

 Clifford,

 I actually raised that possibility in the discussion we had as well! I
 would prefer (and think it's more elegant) if there were a route
 relation covering both the access roads and the ferry route itself, as
 we use route relations extensively already. Is there an established
 place in the route relation network= hierarchy for ferry routes? It
 looks like they are at the same level as land-based state highways, so
 they would be route=ferry, network=US:WA?

 Martijn

 On Wed, Oct 16, 2013 at 10:57 PM, Clifford Snow cliff...@snowandsnow.us
 wrote:
  I check one of Seattle's ferry terminals. service roads connect city
 streets
  to the ferry route. Washington State assigns these routes as highways
 with a
  number. Each of the service roads has an ref (eg. ref: WA 305) associated
  with the routes. I wonder how this impacts routing? For example,
  http://osm.org/go/WIdFBesd9--
 
 
  --
  Clifford
 
  OpenStreetMap: Maps with a human touch
 
  ___
  Talk-us mailing list
  Talk-us@openstreetmap.org
  https://lists.openstreetmap.org/listinfo/talk-us
 



 --
 --
 Martijn van Exel
 OSM data specialist
 Telenav
 http://www.osm.org/user/mvexel
 http://wiki.openstreetmap.org/wiki/User:Mvexel
 http://hdyc.neis-one.org/?mvexel

 ___
 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] Complex intersection mapping

[Evin Fairchild]

I too prefer the after pattern since it is easier to do, especially when
you are making a road be dual-carriageway by using the parallel way
feature in Potlatch 2. Also, it matches the way it is on the ground better.
Since there seems to be unanimous agreement to map intersections this way,
then I'll change other intersections to match.

-Compdude


On Mon, Oct 14, 2013 at 10:42 AM, Martijn van Exel marti...@telenav.comwrote:

 Hi all,

 Here at Telenav we have been looking at complex intersections and we
 have set about editing some of these intersections in a way we feel
 represents the situation on the ground better than their original
 state, and because of that, works better for us. We have received some
 feedback on our edits so we wanted to take a step back and see what we
 (as the OSM community) think is the preferred way to map these
 intersections.

 So what are we talking about? Intersections like this one, where one
 or more dual carriageways come together at an at-grade intersection:


 https://www.evernote.com/shard/s9/sh/6438c196-bb92-4f66-81dc-9b75186286ba/0e8f07ff527c6a85c0dec426b9b79f1e

 One of my colleagues at Telenav has remapped this intersection as follows:


 https://www.evernote.com/shard/s9/sh/3491f1fe-6afa-4571-bc43-7cb31c9c2625/9dd47d1445fdcf03d3f0bbd93b8e0f92

 The main difference, and the source of some feedback we have received
 over the past few days, is that the dual carriageway roads are
 straightened out, creating multiple intersection nodes (4 in this
 case) instead of the original single intersection node that connects
 all the incoming and outgoing ways. That technique turns out to yield
 more reliable and correct routing and guidance ('keep left, turn
 right') through these intersections in our testing. But of course,
 that cannot dictate how we map as a community, so let's discuss.

 Some of the feedback we have received about these edits points to a
 statement on this wiki page:
 https://wiki.openstreetmap.org/wiki/TIGER_fixup#Braided_streets: 'It
 is a reasonable and well-used technique to bring the ways of dual
 carriageways back to a single point at intersections to facilitate and
 simplify the mapping of control devices and turn restrictions.' In my
 mapping across the US, my personal experience has been that this
 technique is in fact used, but the 'after' technique with straightened
 out ways is actually much more common. I personally prefer that
 technique as well - I think it is more pleasing to the eye, represents
 what is on the ground better, and is and easier to read. So my feeling
 was that this mapping practice would not be disputed. It turns out I
 was wrong, so I want to see what the consensus is on mapping
 intersections of this type - or perhaps there is none and we can work
 together to get there?

 Thanks,
 Martijn
 --
 Martijn van Exel
 OSM data specialist
 Telenav
 http://www.osm.org/user/mvexel
 http://wiki.openstreetmap.org/wiki/User:Mvexel
 http://hdyc.neis-one.org/?mvexel

 ___
 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] Current status with highway shields?

[Evin Fairchild]

Okay, but isn't the ultimate goal of this to get the shields on the map,
for the whole world to see? I mean, if I was the one doing this, I wouldn't
consider this a finished project until it was on the Standard (Mapnik)
layer on openstreetmap.org, integrated into the Carto stylesheet. To be
honest, I really hate not seeing the shields on osm.org, especially
considering that the tiles for the shield renderings (and even the
bl.ocks.org site that you mentioned) take so long to load compared to
osm.org. This is why I really want to see you guys get it on the main map.

I'm sure Andy Allan would be more than willing to help you guys with this;
I mean, he ported the *whole* old XML stylesheet to the new CartoCSS
format. Surely he can help you do the same with the code for the shields.
You should talk to him about this.

I commend you guys on coming this far on the shield project, just as much
as I commend Andy Allan for making the Mapnik stylesheet 10 gazillion times
easier to work with. I really can't wait to see them on the main map. The
current shields look inferior to the real ones that you guys made.

-Compdude


On Wed, Oct 9, 2013 at 10:40 PM, Toby Murray toby.mur...@gmail.com wrote:


 The tiles on the OSM-US server are up and running. The preview was on
 Phil's home server that had limited bandwidth. A better UI to the tile
 layer can be found here with standard map controls and a simple search
 feature to jump to locations:

 http://bl.ocks.org/ToeBee/raw/6119134/

 I have talked to Ian about getting that HTML up at a more memorable URL on
 openstreetmap.us and maybe linking to it somewhere on the site. I'll bug
 him about it again.

 No progress has been made on porting the style to carto.

 I might be able to fix the bannered routes. I know there are some New York
 county issues I need to look at as well.

 Toby



 On Wed, Oct 9, 2013 at 11:03 PM, Martijn van Exel m...@rtijn.org wrote:

 (sorry if this makes it twice - I tried posting from my other account
 but got flak from Outlook)
 Yes that would be really interesting to push forward. To my mind this
 should be a default tile layer on osm.us (not that we have a slippy
 map on there today at all – but we should).
 The layer still works --

 http://tile.openstreetmap.us/osmus_shields/preview.html#13/40.7292/-111.8467
 (pro tip: shift double click to zoom out…)
 I don't remember very clearly but I think my main concern is that this
 operates on a pre-carto Mapnik stylesheet – which would make it
 difficult to keep in sync with style tweaks to osm.org – and more
 difficult to maintain in general.

 On Wed, Oct 9, 2013 at 9:52 PM, Clifford Snow cliff...@snowandsnow.us
 wrote:
  +1
 
  In a conversation with a King County (Washington) employee, we
 discussed his
  project to create tiles from OSM to use as basemaps for King County and
  hopefully others. While he doesn't need our tile server, the shields
 would
  really enhance the basemaps.
 
 
  On Wed, Oct 9, 2013 at 7:54 PM, Evin Fairchild evindf...@gmail.com
 wrote:
 
  Hello,
 
  I was just wondering what's been going on with rendering the highway
  shields. I haven't heard anything about it for a while. The last time
  anything was mentioned about this was in late-July when it was
 announced
  that the tiles were put up on the OSM-US server--and that was only
 meant to
  be a preview. I know that the code has to be changed to work with the
 new
  Carto stylesheet, but I didn't expect that to take so long. Sorry if I
 sound
  impatient, but I've been waiting patiently for the past two months.
 
  Also, I have noticed that the shields for bannered WA State routes
 (Spur,
  Alternate) are not rendering. I emailed Phil Gold (creator of the
 awesome
  shield rendering) about this almost a month ago, but he never
 responded so
  this hasn't been fixed. Anyway, I'd appreciate it if this can get
 addressed.
 
  Thanks for coming up with the whole highway shield rendering. I really
  appreciate the effort, because the shields are a 154% improvement over
 the
  current way of displaying highway numbers. I appreciate your efforts on
  getting this whole project completed. Unfortunately I'm not a
 programmer,
  but if there's anything I can help with, let me know.
 
  All WA State Hwys. are now ready for shields (that is, they all have
  relations), but are the shields ready for display on the slippy map? I
 hope
  they will be soon.
 
  Thanks, Compdude
 
  ___
  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
 



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

 ___
 Talk-us mailing list
 Talk-us@openstreetmap.org

Re: [Talk-us] Current status with highway shields?

[Evin Fairchild]

I don't think the extra complexity of the shields slows down the time it
takes to render them. But the tiles themselves on the shield map take way
longer to load than on osm.org (which is why I really want the shields on
the main OSM website), which I guess is because of a slower tileserver.

Also, would it be possible to render the shields on ferry routes? In the
state of WA, many of the ferry routes are legally part of the highway
system and as such, I've added them to the route relations. If this isn't
possible, that's okay. I was just wondering.

I appreciate your efforts in all this. Best luck in getting all the county
highway shields to render; be glad you won't have any from my corner of
this great nation!


On Thu, Oct 10, 2013 at 10:04 AM, Phil! Gold phi...@pobox.com wrote:

 * Evin Fairchild evindf...@gmail.com [2013-10-10 09:22 -0700]:
  Okay, thanks for letting me know. So, your ultimate plan *is* to get the
  highway shields showing up on osm.org?

 Well, we'll have to see.  The shield rendering adds a fair bit of
 additional complexity to the overall rendering process, and I don't know
 if the osm.org admins would be willing to commit to maintaining the
 additional complexity.  It's possible that they'd prefer to leave it on
 openstreetmap.us, since the admins there (Ian Dees, mostly) *are* willing
 to manage the extra stuff.

 I have a lot more I want to do with the rendering, so its possible I may
 be able to get it into a state the is more easily integrated into various
 rendering stacks.

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

[Talk-us] Current status with highway shields?

[Evin Fairchild]

Hello,

I was just wondering what's been going on with rendering the highway
shields. I haven't heard anything about it for a while. The last time
anything was mentioned about this was in late-July when it was announced
that the tiles were put up on the OSM-US server--and that was only meant to
be a preview. I know that the code has to be changed to work with the new
Carto stylesheet, but I didn't expect that to take so long. Sorry if I
sound impatient, but I've been waiting patiently for the past two months.

Also, I have noticed that the shields for bannered WA State routes (Spur,
Alternate) are not rendering. I emailed Phil Gold (creator of the awesome
shield rendering) about this almost a month ago, but he never responded so
this hasn't been fixed. Anyway, I'd appreciate it if this can get addressed.

Thanks for coming up with the whole highway shield rendering. I really
appreciate the effort, because the shields are a 154% improvement over the
current way of displaying highway numbers. I appreciate your efforts on
getting this whole project completed. Unfortunately I'm not a programmer,
but if there's anything I can help with, let me know.

All WA State Hwys. are now ready for shields (that is, they all have
relations), but are the shields ready for display on the slippy map? I hope
they will be soon.

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

Re: [Talk-us] the Battle Grid

[Evin Fairchild]

How do I get involved in this Editathon? I would really like to participate.

Thanks, Compdude


On Sun, Sep 8, 2013 at 12:45 PM, Clifford Snow cliff...@snowandsnow.uswrote:

 Martijn,
 For the upcoming #Editathon, we plan to fix road alignment in Washington
 State. Eric Fischer pointed me to your Battle Grid website. I plan
 introduce it at the #Editathon. Originally I was just going to list cities
 and ask people to work on a city. However, you tool is much better. I'd
 like to make one request of you. Is it possible to increase the size of the
 color tiles? When opening in iD, they seem too small. You end up working on
 surrounding areas before you know it. Since iD automatically brings in new
 data as you scroll around, it's easy to be working in adjacent tiles. This
 isn't a show stopper by any means. If it's too much work or doesn't make
 any sense to you, just tell me to take a flying leap!

 Thanks,
 --
 Clifford

 OpenStreetMap: Maps with a human touch

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


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

Re: [Talk-us] osm data on boston.com, perhaps, definitely not atttributed

[Evin Fairchild]

Seems like this is something that really needs to be fixed. It sure seems
dumb that there no attribution to OSM when you embed an OSM map on another
webpage.

-Compdude


On Fri, Aug 30, 2013 at 8:19 PM, Tod Fitch t...@fitchdesign.com wrote:

 I've changed a web page from using an embedded Google map using the
 Share with HTML option from http://www.openstreetmap.org/ having
 selected the tiles to be from Mapquest and found that it embeds exactly
 like that, without the OSM attribution. Seems like if you do it from OSM
 the attribution should just be there.

 For example, plop this into a web page and look to see what you get:

 iframe width=425 height=350 frameborder=0 scrolling=no
 marginheight=0 marginwidth=0 src=
 http://www.openstreetmap.org/export/embed.html?bbox=-119.1426,34.7812,-119.0945,34.8394amp;layer=mapquestamp;marker=34.81261,-119.12715;
 style=border: 1px solid black
 /iframe

 I guess I could futz with the HTML and setup my own server to be in the
 middle and have it add the attribution but that is way more than you can
 expect the average user to do.

 -Tod



 On Aug 30, 2013, at 4:06 PM, Greg Troxel wrote:

 
  Greg Troxel g...@ir.bbn.com writes:
 
 
 http://www.boston.com/yourtown/specials/truck_crashes_storrow_memorial_drive/
 
  The data looks like osm, and zooming in near Kendall Square and MGH
  certainly makes it look like OSM.
 
  Compare page 3 with:
 
  http://www.openstreetmap.org/#map=18/42.36197/-71.07089layers=N
 
  I talked with someone at boston.com/globe.com, and now there is
  attribution.  Apparently this is tricky because people use mapquest open
  tiles without realizing that they have to attribute osm when doing so.
  This case was fixed within hours of being pointed out, which is great.
  ___
  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 mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Adventure Cycling article (OSM in the media)

[Evin Fairchild]

That's nice. If I had never read that article in the paper about OSM three
years ago, I would not be here!

-Compdude


On Wed, Sep 4, 2013 at 12:39 PM, stevea stevea...@softworkers.com wrote:

 Well, this newsletter/blog entry by Adventure Cycling Association is
 pretty cool:

 http://wiki.openstreetmap.org/**wiki/OpenStreetMap_in_the_**
 media#Septemberhttp://wiki.openstreetmap.org/wiki/OpenStreetMap_in_the_media#September
 (points to)
 http://www.adventurecycling.**org/resources/blog/**
 openstreetmap-the-web-based-**mapping-projecthttp://www.adventurecycling.org/resources/blog/openstreetmap-the-web-based-mapping-project

 Not shy to toot OSM's horn,

 SteveA
 California

 __**_
 Talk-us mailing list
 Talk-us@openstreetmap.org
 http://lists.openstreetmap.**org/listinfo/talk-ushttp://lists.openstreetmap.org/listinfo/talk-us

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

Re: [Talk-us] Shields are up!

[Evin Fairchild]

It seems like shields for spur Washington State Hwys aren't rendering. I
thought they were, but now it seems that they aren't. For example, WA 110
has a spur route that goes to the north of Quillayute (Quileute) River, but
the shield for the spur route isn't showing up. (see link below) I created
the relation for the spur route 16 hours ago, it should've rendered by now.
I'm pretty sure I tagged everything right. Could someone have a look and
tell me if I'm doing anything wrong?

Link is here: http://bl.ocks.org/ToeBee/raw/6119134/#15/47.9151/-124.6000

Thanks, Compdude


On Sun, Jul 28, 2013 at 8:38 PM, Toby Murray toby.mur...@gmail.com wrote:

 We finally managed to get Phil's highway shield rendering up on the OSM-US
 server today! You can see the tiles here:

 http://tile.openstreetmap.us/osmus_shields/preview.html

 This is a pretty basic preview for now. I'll look at getting the tiles set
 up in a pretty leaflet UI or something.

 Toby

 ___
 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] Shields are up!

[Evin Fairchild]

These shields look really great! They're much better than what we had
before. Now this will give me a good reason to create relations for
highways, since many highways in Washington state are lacking in relations.

And, sorry if I sound impatient, but when will the shields be up on the
main OSM map?

-Compdude


On Tue, Jul 30, 2013 at 1:59 PM, stevea stevea...@softworkers.com wrote:

 On 2013-07-29 11:12 AM, Richard Welty wrote:

 can someone please explain to me where to find documentation on the trick
 that's being used to generate customized SVG files for each of the
 counties
 based on the pentagonal shields?


 There's no trick, unfortunately. I'm just embedding images that I created
 and uploaded to Wikimedia Commons and linking the images to the templates
 that the slippy map would likely use.


 This is a ridiculously well-written how-to guide.  Thank you kindly, and
 nice job, Minh!

 SteveA
 California


 __**_
 Talk-us mailing list
 Talk-us@openstreetmap.org
 http://lists.openstreetmap.**org/listinfo/talk-ushttp://lists.openstreetmap.org/listinfo/talk-us

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

Re: [Talk-us] Tagging a super-two highway (trunk or motorway?)

[Evin Fairchild]

So basically, these super-2 roads should be tagged as motorways instead of
primary or trunk? That would be fine with me. Even though I have changed
roads like these back to primary when someone had changed them to motorway,
I only did that because I thought motorway was not supposed to be used
there. But if motorway is to be used, that's okay with me.

-Compdude


On Thu, Jun 27, 2013 at 8:49 PM, Chris Lawrence lordsu...@gmail.com wrote:

 On Wed, Jun 26, 2013 at 2:36 PM, Paul Johnson ba...@ursamundi.org wrote:
  That would mean most freeways including interstates in the west, with the
  exception of limited sections in the bay area, southwestern California,
  central Portland and urban Seattle wouldn't be motorways, as restricting
  pedestrians and bicycles is unusual in 34 states.

 To clarify, I meant that most states have some practice that involves
 specially marking freeways; for example, California uses the Freeway
 Entrance sign, as I believe is also the case in Nevada, Washington,
 and a few other states, while in many other states the restrictions
 are spelled out on a sign at the beginning of controlled access and
 on-ramps.  Of course, there are states that don't post these
 restriction signs (like Mississippi), and there are states that allow
 certain categories of vehicle on some or all freeways that are
 forbidden on other states' freeways.  But as a guide for figuring out
 if a stretch of road is a freeway (and thus in OSM tagging a
 highway=motorway) knowing field signing practices for freeways is a
 helpful indicator, along with the legal designation of the route (if
 the state makes a legal distinction between partial and full control
 of access, regardless of the terminology).

 And this isn't tagging for the renderer.  It's tagging based on the
 western hemisphere translation of the concept of a motorway, which
 includes the possibility of undivided routes with full access control.
  Tagging for the renderer would be tagging undivided freeways as
 trunks because we want them to be visually distinct from divided
 freeways tagged as motorways in Mapnik's default style.

 TLDR version: if there are signs at each end saying the road is a
 freeway, and we have it tagged as a primary rather than a motorway
 (the super two freeway section of US 101 in Washington State is
 apparently an example, based on what He Who Shall Not Be Named says in
 another forum), that's a problem. We can haggle over more ambiguous
 cases like (presumably) MD 60 - I've never driven it and haven't done
 any research with the state authorities, so I have no particular
 expertise there.


 Chris

 ___
 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] Route relation pages

[Evin Fairchild]

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

Re: [Talk-us] Google Maps being praised for removing I-5 colasped bridge quickly

[Evin Fairchild]

Yeah, and you guys beat me to it!

 

-Compdude

 

From: Clifford Snow [mailto:cliff...@snowandsnow.us] 
Sent: Monday, May 27, 2013 4:37 PM
Cc: t...@openstreetmap.org; talk-us@openstreetmap.org
Subject: Re: [Talk-us] Google Maps being praised for removing I-5 colasped
bridge quickly

 

Let's forget about Google Maps for a moment that give thanks to the
contributors who updated I-5 on OpenStreetMap. Alan, rickmastfan67, Sundance
and katpatuka have all contributed to the update. 

 

It is dedicated mappers like these that make OSM great.



-- 

Clifford

 

OpenStreetMap: Maps with a human touch

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

Re: [Talk-us] King County, Washington authorization

[Evin Fairchild]

So what data does this include exactly?  Parks? Roads?  What?

 

-Compdude

 

From: Jeff Meyer [mailto:j...@gwhat.org] 
Sent: Monday, December 10, 2012 12:42 PM
To: OpenStreetMap US Talk; impo...@openstreetmap.org;
osm-seat...@googlegroups.com
Subject: [Talk-us] King County, Washington authorization

 

All - 

 

FYI - King County Washington has authorized the use of their data in
OpenStreetMap.

 

No imports using this data (beyond possibly the Seattle Import) are
currently planned, afaik.

 

http://wiki.openstreetmap.org/wiki/Contributors#King_County.2C_Washington

 

Regards,

Jeff

 

 

-- Forwarded message --
From: Horning, George george.horn...@kingcounty.gov
Date: Mon, Dec 10, 2012 at 12:05 PM
Subject: RE: Recent Inquiry to King County Regarding King County's Data
Policy
To: Jeff Meyer j...@gwhat.org, Moses, Ann ann.mo...@kingcounty.gov
Cc: Smith, Nick nick.sm...@kingcounty.gov

Jeff -

Yes, including the King County data disclaimers in the same manner as you
are doing for the city of Seattle would be fine.  Thanks for being
conscientious about using the county's data.  When you have set up please
send along a link.

George W. Horning 
King County GIS Center Manager 
___
King County GIS Center 
Department of King County Information Technology 
201 South Jackson Street, Suite 706 
Seattle, WA  98104-3855 
206-263-4801  FAX 206-263-3145 
george.horn...@kingcounty.gov

From: Jeff Meyer [mailto:j...@gwhat.org] 
Sent: Friday, December 07, 2012 10:26 AM
To: Moses, Ann
Cc: Smith, Nick; Horning, George
Subject: Re: Recent Inquiry to King County Regarding King County's Data
Policy

Hi Ann -

Thanks for your persistence on this topic! We (the local OSM group were just
discussing the status of this request in email this morning. : )

Mr. Horning -

Pleased to meet you.

Regarding item #7, would including that statement on the OpenStreetMap
contributors page meet that requirement? Here's a link to this page - you'll
see the City of Seattle is using this page to meet their requirements for
attribution.

http://wiki.openstreetmap.org/wiki/Contributors#City_of_Seattle.2C_Washingto
n

There is a vibrant OpenStreetMap community in King County and we are all
excited about the possibility for increasing the use of this public data. We
just want to make sure we're doing it the right way. Any help you can
provide with our efforts is greatly appreciated!

Thanks,

Jeff

On Fri, Dec 7, 2012 at 10:04 AM, Moses, Ann ann.mo...@kingcounty.gov
wrote:

Dear Mr. Meyer,

Based on your additional information, I was able to reach out to George
Horning, King County's GIS Center Manager.  Mr. Horning recommended that I
share the following link with you, which is available on the King County's
GIS Data Portal (http://www5.kingcounty.gov/gisdataportal/), and shows the
King County GIS Center's Terms and Conditions, which must be accepted by the
user before they can download any data.  Item 7 may be of particular
interest in your situation.

I have also included these terms and conditions at the end of this e-mail.

While I am not sure if it would be applicable in your situation, I have also
attached a copy of the form that is used by the King County GIS Center for
individuals to request a custom data order. 

I hope this additional information helps!   Note that I have included Mr.
Horning as a cc on this e-mail.  Please feel free to follow up directly
with him regarding any additional questions you might have.

Sincerely,

Ann Moses

King County Information Technology

 

 

Terms and Conditions

By accessing any data posted by King County (Data), you agree to these
Terms of Use (Terms). These Terms may be updated or modified by King
County at any time at its sole discretion. If you do not agree to these
Terms, do not access the Data or download any material from it.

1. King County grants you a limited, revocable license to use, reproduce,
and redistribute the Data in accordance with these Terms.

2. The Data is collected from various sources and will change over time and
without notice.

3. The Data is provided to you on an AS IS and AS AVAILABLE and WITH
ALL FAULTS basis without any warranty of any kind, express or implied,
including without limitation the implied warranties of merchantability,
fitness for a particular purpose, accuracy and non-infringement, nor shall
the distribution of this information constitute any warranty.

4. The Data is not intended to constitute advice nor is it to be used as a
substitute for specific advice from a professional. You should not act (or
refrain from acting) based upon information in the Data without
independently verifying the information and, as necessary, obtaining
professional advice regarding your particular facts and circumstances.

5. You use the Data at your own risk, and you assume the risk that the Data
may provide incorrect information to you, as well as the risk that any
material downloaded by you may cause loss of data or 

Re: [Talk-us] redundant tagging on relations and member ways

[Evin Fairchild]

My guess is that people are doing that because in Potlatch 2, when you put tags 
into just a relation, it doesn’t render in Potlatch the same way that it does 
if you put the same tags into a way.  Let me explain what I mean.  For example 
if you want to make multipolygon relation for a lake, when you put the 
natural=water tag in the relation but don’t put it in for the member, Potlatch 
won’t display the lake in blue.  You have to put a natural=water tag into a way 
for it to be displayed blue.  But whether the member way has the appropriate 
tags or not doesn’t affect how it’s actually rendered on the map.  What I’m 
saying is that some users might think that the fact that the lake isn’t blue 
when you put the natural=water tag in the relation means that it might not 
display properly on the map.  Potlatch needs to be changed so that this doesn’t 
happen.

 

-Compdude

 

From: Ian Villeda [mailto:vill...@mapbox.com] 
Sent: Wednesday, October 31, 2012 1:10 PM
To: talk-us@openstreetmap.org
Subject: [Talk-us] redundant tagging on relations and member ways

 

 

Hi, 

 

I've noticed a few instances where members of multipolygon relations have the 
same tags as the relations. This seems redundant and I wondering why we 
wouldn't / haven't moved the tags to the relations. Specifically I'm thinking 
of cases like this:

http://www.openstreetmap.org/browse/relation/135822 vs 

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

 

Of course we wouldn't want to remove way-specific tags (i.e. district=* tags), 
but I wanted to make sure there was a reason the name=, landuse=, and leisure= 
tags haven't already been deleted in favor of tagging the relation. Happy to 
make the edits so long as I'm not stepping on any toes / missing something 
obvious. 

 

saludos, 

 

-- 

ian villeda (ian29 http://www.openstreetmap.org/user/ian29 )

mapbox | developmentseed

https://twitter.com/ian_villeda

 

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

Re: [Talk-us] Duplicate state parks in California

[Evin Fairchild]

The way I see it is that a state park ought to be tagged as a plain-old
park, not a national park.  The national park tag is for national parks.
Pretty self-explanatory.

-Compdude

-Original Message-
From: AJ Ashton [mailto:aj.ash...@gmail.com] 
Sent: Tuesday, August 14, 2012 3:54 PM
To: talk-us@openstreetmap.org
Subject: [Talk-us] Duplicate state parks in California

I've seen state parks in California that are in the database twice each with
slightly different tags.
Here is an example changeset that added two of everything:
http://www.openstreetmap.org/browse/changeset/2020128

Two relations containing the same way(s): one relation is 'type=boundary,
boundary=national_park' and the other is 'type=multipolygon, leisure=park'.
Are both of these really necessary?
To me it seems a bit redundant, especially when multiple relations are
involved. (Among other things it causes multiple results for the same entity
in Nominatum.)

This data is the result of an import[1] some years ago, but don't see any
detailed info on the tagging approach that was taken. Does anyone have more
info on this, or on tagging state parks in general?

(There is also the confusion of state/regional parks being tagged as
'national' parks, but I take it that's just how things are done.)

[1]: http://wiki.openstreetmap.org/wiki/California/Import

--
AJ Ashton

___
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] Fwd: [OSM-dev] Licence redaction ready to begin

[Evin Fairchild]

The newer TIGER 2011 data is a BIG improvement over the original TIGER data
that was put in the US.  When the roads for Columbia, SC are deleted by the
license bot, someone could go in and upload the TIGER 2011 data for
Columbia.  Of course, things like footways and parks may be deleted as well,
but at least having the roads in there is better than nothing.

-Compdude

-Original Message-
From: Frederik Ramm [mailto:frede...@remote.org] 
Sent: Wednesday, July 11, 2012 6:31 AM
To: talk-us@openstreetmap.org
Subject: Re: [Talk-us] Fwd: [OSM-dev] Licence redaction ready to begin

Hi,

On 07/11/12 15:20, Nathan Edgars II wrote:
The state capital region of Columbia, South Carolina will be a 
 prime test of the Do empty areas attract contributors? theory for 
 some time to come.

 Why, is someone planning to remove the TIGER import in that area?

 Yes, wherever those TIGER ways were either outright deleted or 
 combined with other ways.

Obviously my comment was a bit tongue-in-cheek; I am personally convinced
that the unedited TIGER landscape - i.e. a map of which virtually nothing is
correct and once you start to work somewhere you have to touch almost every
single object if you want an acceptable result - is the worst situation for
attracting mappers. Therefore, returning an area to how it was after TIGER
(and deleting selected objects for good measure) is certainly not creating
an empty area in the sense of the do empty areas attract contributors
theory.

Bye
Frederik

--
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09 E008°23'33



___
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] TIGER fixup and mapping more

[Evin Fairchild]

If people don't want to do the TIGER fixup all over again, they could import
the TIGER 2011 data which is of MUCH better quality than the TIGER data that
was originally imported into OSM (though not quite perfect).  In fact, I
sometimes use the TIGER data overlay to get the names of roads that have
been built recently after having traced them from the satellite image.  This
uploading of new TIGER 2011 data would be a much better use of peoples' time
than having to do the TIGER fixup all over again.  Just an idea...

Compdude

-Original Message-
From: Richard Weait [mailto:rich...@weait.com] 
Sent: Wednesday, July 11, 2012 8:19 AM
To: talk-us@openstreetmap.org
Subject: [Talk-us] TIGER fixup and mapping more

On Wed, Jul 11, 2012 at 10:20 AM, Kevin Kenny kken...@nycap.rr.com wrote:

 I'd be fine with trying to clean up unedited TIGER - or even a 
 horrible mess of half-deleted TIGER - if the expectations of the 
 results weren't quite so daunting.
[ ... ]

Larger cleanups can be imposing at first glance.  Other mappers will
understand that a single mapper can't do everything at once, so you
shouldn't be criticized if you fix a few things but not others.

 How do other mappers deal with the perfectionism that pervades the 
 community?

Treasure it  :-)

Of course we may have as many different flavours of perfectionism as we have
mappers.  Some will have an unnatural interest in baseball diamonds and
others in bicycle amenities.  Each of those mappers might consider the home
range of the other to be imperfect.  That diversity is a strength of OSM,
overall.

If you are finding it overwhelming to consider a large repair, start with a
few easy bits, or those bits that most-interest you. For example, if the
road network in your town is badly aligned, start perhaps with fixing just
the main street that bisects it.  Now, rather than one large problem, you
have two smaller problem areas, with a good baseline between.  Then perhaps
sub-divide it further into manageable bites.

Back before we had good aerial imagery in my area, it seems that new mappers
popped up and started contributing when a framework of arterial roads was
mapped.  Those provided a boundary of neighbourhoods for new mappers to
adopt and map.  Perhaps you'll see something similar.

___
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