Re: [Talk-us] Recent Trunk road edits

[Albert Pundt]

It seems another editor by the name of Fluffy89502 is going around doing
similar edits all over the US, even demoting divided, multi-lane roads.
Other users have commented on his changesets and he cites the wiki's
wording.

On Mon, Sep 28, 2020 at 8:54 PM Mike N  wrote:

> Based on some likely Wiki-Fiddling, I'd like to see the Trunk road
> comments about the US tagging cleaned up to match reality.   (I realize
> that is harder than just reverting to a previous point in time).
>
>
>
> ___
> 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

[Albert Pundt]

"Tagging freeway ending/beginnings with this scheme is definitely not
standard practice in the US"

By "this scheme," do you mean motorway up to intersection or motorway only
up to last ramp merge? The former is almost everywhere in the US and I very
rarely see the latter. Even after browsing the west and central US just
now, I only saw a handful of motorways ending at the last ramp merge,
including the examples around Tulsa from the original message. From what
I've seen, this practice is almost nonexistent on the east coast, which has
not only more freeways but also more fragmented freeways to serve as
examples.

On Thu, Nov 29, 2018 at 10:09 PM Bradley White 
wrote:

> > 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.
>
> I know I'm not going to change your mind, but I'd like to agree with
> the other voices here that this scheme is overly pedantic without any
> real justification for being so. No-one is saying that the motorway
> has an at-grade intersection as you assert; the motorway simply
> begins/ends *at* that intersection. Tagging freeway ending/beginnings
> with this scheme is definitely not standard practice in the US, and I
> don't see how changing this just to split hairs over freeway
> definitions would benefit anyone.
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>


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

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

[Albert Pundt]

I always tag based on the actual access control. At the end of a clear
freeway, continue the motorway tagging to the first intersection or
driveway, or if the road becomes single-carriageway and isn't a super-2 (a
controlled-access freeway in which only one carriageway is constructed with
accommodation for the second later). There is no "except for the
intersections."

If a road like that has enough intersections spaced throughout its length,
it should be tagged as trunk, perhaps with expressway=yes. Though with just
two or three intersections nearby in the middle of a freeway (for example
the handful of remaining intersections in the mostly-freeway section of US
29 in Maryland), I'd tag it as trunk only between the intersections and
make the rest motorway.

The Tisdale Parkway should absolutely be tagged as motorway starting from
the Gilcrease intersection southward. Gilcrease should be motorway as well
from where it becomes dual-carriageway. The remaining sections of each of
these roads should be tagged as trunk.

On Thu, Nov 29, 2018 at 12:31 AM Nathan Mills  wrote:

> I think this is a good general rule. In the instant case, the tagging
> should change at the point where the grass median ends northbound, IMO.
> That marks a definite change in the physical character of the road. I
> believe it was tagged like that when the carriageways were first split
> after the TIGER import, but I might be misremembering.
>
> -Nathan
>
>
>
> On November 29, 2018 12:01:58 AM EST, Evin Fairchild 
> wrote:
>>
>> What?! I haven't contradicted myself at all. I already said in my initial
>> response (the one that I sent to only you by mistake) that in cases where
>> there's an at grade intersection sandwiched in between two interchanges,
>> the road should be marked as trunk in between. Other than that case, a road
>> should be motorway all the way to the at-grade intersection, as is the case
>> with the Tisdale Parkway.
>>
>> On Wed, Nov 28, 2018 at 8:11 PM Paul Johnson  wrote:
>>
>>> On Wed, Nov 28, 2018 at 10:02 PM Evin Fairchild 
>>> wrote:
>>>
>>>> Nobody is saying that we should tag as motorways a road with a surface
>>>> intersection. I don't understand what it is that we're saying that's
>>>> causing you to come to that conclusion. We are simply saying that the
>>>> first surface intersection that a road comes across is where the motorway
>>>> should change to trunk.
>>>>
>>>
>>> You've contradicted yourself in that statement.
>>>
>>
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>


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

Re: [Talk-us] Thoughts on a standard "ref" abbreviation for PA Turnpike?

[Albert Pundt]

I didn't mean put network=* on the way; I meant the route relation. I
presume that's already how it differentiates Interstates, US routes, state
routes, etc. I don't know how else it could be done from the relation.

I certainly agree now with adding PATP as a ref on the ways for the reasons
you've described.

On Sun, Nov 11, 2018 at 7:54 PM Kevin Kenny  wrote:

> An aside (off list for reasons that will become obvious):
>
> It's unlikely that OSM-Carto will ever support the shaped shields and
> relation-driven support for route concurrencies that I'm doing. The support
> requires changes pretty much all up and down the rendering toolchain, and
> the development teams for several of the tools (most notably osm2pgsql)
> have pretty much conclusively rejected the changes that I proposed to
> implement. Without them, it's pretty much impossible to provide proper
> support for concurrency among route relations.
>
> Essentially, I'm foiled at every step because the dev teams don't agree
> with my approach. For instance, the osm2pgsql team rejects any inclusion of
> relations (rather than constructing ways from the relations) in the
> rendering database. They predict various performance and maintainability
> problems that warrant rejecting the changes out of hand, even if they
> provide functionality that cannot be done otherwise. (Actually, pnorman
> believes that it *can* be done - but has yet to offer a coherent path to
> *how* to do it in a way that he'd accept - and I've not been able to find
> one.)
>
> At one point, the openstreetmap.us team was accepting of Phil! Gold's
> rendering of shielded ways and concurrent routes, which has several issues
> that I've fixed (requiring a read/write connection to the PostGIS database,
> and access as well to the native file system underlying it). I have hopes
> that if I can refine this system enough, I might convince someone to accept
> this as a national map, even though the main opensteetmap.org server will
> never have it.
>
> I've got things to where I can run with an unpatched mapnik, and I'm
> looking at pulling a switch at some point from osm2pgsql to imposm3. Once
> I'm to that point, I can start looking at integrating a tile cache and
> incremental updates. But my development time at this point is limited. Life
> keeps getting in the way. For instance, at the moment, I'm recovering from
> retinal surgery, and have a lot to catch up on once I'm back to full
> function, so OSM will be on hold for a while longer.
>
>
>

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

Re: [Talk-us] Thoughts on a standard "ref" abbreviation for PA Turnpike?

[Albert Pundt]

This would not involve adding ref=PATP to the PA Turnpike route relation.
However, thinking about it now, I think it should be added to the ways for
the sake of the Carto renderer. (I know, I know, tagging for the renderer,
but isn't Carto's use of ref tags for route markers the only reason the
tags remain on ways?) We'd need to be careful where we use PATP in
destination:ref tags, since the Turnpike shield is very rarely used once on
the Turnpike. For example, the ramps from the mainline Turnpike (I-276) to
the northbound Northeast Extension (I-476) should remain tagged as
destination:ref=I
476 and not destination:ref=I 476;PATP since that shield does not appear on
the signs. The only such use of a Turnpike shield that I know of is the
aforementioned example eastbound at Willow Grove.

"PA Turnpike XX" routes are an established type in Pennsylvania. Three
examples currently exist: 66 (New Stanton to Delmont), 43 (WV to Fairchance
and Uniontown to Jefferson Hills), and 576 (entire length, US 22 to Pgh
Int'l Airport). A relation tagged with network=US:PA:Turnpike and a
numerical ref value should trigger the use of the PA Turnpike XX
shield. This isn't simply a fancy label for a standard state route like the
yellow TOLL banners on I-376. They are treated as separate routes by
PennDOT and the PTC. Exiting US 22 near Delmont, signs say "PA 66 South, TO
PA Turnpike 66." Occasionally, an erroneous PA Turnpike XX shield pops up
for I-76, 276, or 476, but that's inaccurate. Also, the oldest part of PA
43 and the tolled part of I-376 (once PA 60) were in the past signed with a
white keystone simply saying "TOLL" at the top, but there are no remaining
routes signed this way.

On an unrelated note, thanks for linking that renderer. I used it to find
and fix some holes in PA's US 119 relation where it defaulted to using a
plain text rectangle since only the ref tag was present.

I'll start adding PATP to destination:ref tags now, but will only retag the
mainline ways if no one else has any objections.

On Sun, Nov 11, 2018 at 3:17 PM Kevin Kenny  wrote:

> The Turnpike already has a series of relations, which renderers that are
> aware of concurrent road routes are able to render.
>
> It's network=US:PA:Turnpike, and the relation has no ref=* since the road
> markings are unique.
>
> https://www.openstreetmap.org/relation/3075582
>
> It appears to render correctly on
> https://kbk.is-a-geek.net/catskills/test4.html?la=40.1101=-75.3106=11
> which shows the Pike overlaid on Interstates 76, 276 and 476.
>
> I'd have no objection to putting ref=PATP on either the relation or the
> ways, but please let me know if you plan to change the network since my
> code needs to be aware of that.
>
> You might also want to consider what to do about the unusually signed
> PA-Turnpike-66 from New Stanton to Belmont.
> https://kbk.is-a-geek.net/catskills/test4.html?la=40.2748=-79.6186=11
> shows what I'm doing with it at the moment. I'd need to check to see
> whether I put in an override or whether the network tag is different. PA 43
> from Jefferson Hills to Uniontowm
> https://kbk.is-a-geek.net/catskills/test4.html?la=40.1043=-79.9194=11
> is another one that has Turnpike-overlaid-on-state-highway.
>
>
> On Sat, Nov 10, 2018 at 7:52 PM Albert Pundt  wrote:
>
>> Does anyone object to the use of "PATP" as the ref equivalent for the PA
>> Turnpike? Particularly for destination:ref tags, as the Turnpike
>> keystone shield is used on most guide signs for ramps onto the Turnpike.
>> However, since it's not used as a reassurance marker*, I don't think it
>> should be added as a ref tag on the ways (i.e. ref=I 76;PATP) as is done
>> on the New Jersey Turnpike, which does have its shield on pull-through
>> signs and similar.
>>
>> This sort of abbreviation is already standard practice in New Jersey (for
>> the NJTP, GSP, and ACE) and New York (all the parkways), which have
>> standard shields used on guide signs.
>>
>> This would apply to the mainline (I-76 and I-276) and the Northeast
>> Extension (I-476), but not the newer four extensions (PA Tpke 43, 66, 576,
>> and I-376).
>>
>> *There is now one set of signs eastbound on the mainline PA Turnpike
>> approaching the Willow Grove (PA 611) interchange that has the PA Turnpike
>> shield on the pull-through side. However, this was put up within the past
>> two months and is not nearly common enough to base system-wide practice on.
>>
>> —Albert Pundt
>> ___
>> Talk-us mailing list
>> Talk-us@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-us
>>
>

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

[Talk-us] Thoughts on a standard "ref" abbreviation for PA Turnpike?

[Albert Pundt]

Does anyone object to the use of "PATP" as the ref equivalent for the PA
Turnpike? Particularly for destination:ref tags, as the Turnpike keystone
shield is used on most guide signs for ramps onto the Turnpike. However,
since it's not used as a reassurance marker*, I don't think it should be
added as a ref tag on the ways (i.e. ref=I 76;PATP) as is done on the New
Jersey Turnpike, which does have its shield on pull-through signs and
similar.

This sort of abbreviation is already standard practice in New Jersey (for
the NJTP, GSP, and ACE) and New York (all the parkways), which have
standard shields used on guide signs.

This would apply to the mainline (I-76 and I-276) and the Northeast
Extension (I-476), but not the newer four extensions (PA Tpke 43, 66, 576,
and I-376).

*There is now one set of signs eastbound on the mainline PA Turnpike
approaching the Willow Grove (PA 611) interchange that has the PA Turnpike
shield on the pull-through side. However, this was put up within the past
two months and is not nearly common enough to base system-wide practice on.

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

Re: [Talk-us] Possible roundabouts?

[Albert Pundt]

Roundabouts are somewhat common nowadays in the US and follow the same
rules as European roundabouts: entering traffic yields to circle traffic.
Many intersections, such as the rotaries in Massachusetts, follow these
rules despite not being signed as "roundabouts."

We do, however, still have many oldschool traffic circles with odd yielding
rules, or just nothing signed at all. These are typically tagged with
junction=circular.

On Fri, Sep 7, 2018 at 2:37 PM Marian Poara 
wrote:

> Hi all,
>
> We have a short but important question: should we tag with
> “junction=roundabout”  the circular intersections in US where there is a
> physical center you can’t drive over and there is more than one way
> entering, based on satellite imagery? (some examples here: 40.5234202,
> -111.8762446, 35.8497728, -86.4547473, 42.6811136, -73.6987507, 40.22109,
> -76.874981). And if we have OSC or Mapillary street level images and it is
> confirmed that they don’t have any roundabout sign? In many residential
> areas (but not only), there isn’t any one way sign inside the small
> “roundabouts” and it seems that both directions are used.
>
>
>
> Thanks and regards!
>
> Marian Poara
>
>
>
> Marian Poară
>
> Map Analyst
>
> www.telenav.com
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>


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

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

[Albert Pundt]

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] Lincoln, NE South/East Beltway

[Albert Pundt]

I noticed someone had mapped the Lincoln South and East Beltway segments as
under construction. However, I could find no word of either segment going
to construction yet. The South appears to be planned for construction
sooner, but will smoothly tie into Route 2 until the East section is built.
Should I (or someone more local) just switch all the tags over to proposed?

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

Re: [Talk-us] DigitalGlobe Premium Imagery: Invalid Token?

[Albert Pundt]

Thank you Bryan, it worked!

DG Premium is extremely useful in many city ares since it has incredibly
high resolution imagery, so high you can distinguish each line of the
double yellow center line on a road, and is only about a year or so out of
date at the worst.

However, I realized since I sent the original message that the old Mapbox
Satellite layer seems to have the same imagery as DG Premium in the Lehigh
Valley area, though, which is where I'm mapping now. In this case it's even
better, since it doesn't switch to the much blurrier, slightly misaligned
imagery on lower zoom levels like DG Premium does. Is there a way to set
*minimum* zoom level for an imagery layer in JOSM? I'd imagine not, since
zooming out would cause a *lot* of tiles to need to be loaded.

On Sat, Mar 10, 2018 at 5:19 PM, Bryan Housel <br...@7thposition.com> wrote:

> I updated the tokens, per DG request, in this commit:
> https://github.com/osmlab/editor-layer-index/commit/
> 034ac3910fc2fe118394bc953d3ca4ca2212b71c
>
> I don’t know how to update the imagery that JOSM uses, but usually
> whenever we change these, somebody will update the JOSM sources pretty
> quickly.
>
> Thanks, Bryan
>
>
>
> On Mar 10, 2018, at 4:54 PM, Paul Johnson <ba...@ursamundi.org> wrote:
>
> Ive run into the same program since yesterday, and it's basically ground
> me to a halt, since Bing is badly out of date stateside in Oklahoma.
>
> On Mar 10, 2018 14:54, "Albert Pundt" <roadsgu...@gmail.com> wrote:
>
>> For the past several days, the DigitalGlobe Premium and Standard Imagery
>> have both given HTTP 401 errors when trying to use them in JOSM. Manually
>> going to the tile URL tells me that the access token is invalid. Since this
>> is the token in the TMS URL in JOSM by default, it seems as though it needs
>> updating. How do I get a valid updated token?
>>
>> —Albert
>>
>> ___
>> 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
>
>
>


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

[Talk-us] DigitalGlobe Premium Imagery: Invalid Token?

[Albert Pundt]

For the past several days, the DigitalGlobe Premium and Standard Imagery
have both given HTTP 401 errors when trying to use them in JOSM. Manually
going to the tile URL tells me that the access token is invalid. Since this
is the token in the TMS URL in JOSM by default, it seems as though it needs
updating. How do I get a valid updated token?

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

Re: [Talk-us] Satus CDP

[Albert Pundt]

Many towns and suburbs in my area are only CDPs, and having proper
boundaries for them seems like it'd be useful, especially in more densely
populated  areas. It's not like there's any fuzziness with them either,
since they're defined by the Census Bureau and could only change once every
10 years. Only one U.S. census has occurred in OSM history, so it's not
like we'd be constantly updating them.

On Wed, Feb 28, 2018, 17:40 OSM Volunteer stevea 
wrote:

> Brian Stromberg  writes:
> > As someone who does research with Census data, it would be helpful to
> keep all Census geographies in place (at least until Census decides to get
> rid of them). Someone will use them at some point. Additionally, they're an
> official component of Census geographies, as bureaucratic as that might be.
> That alone seems to make them significant enough to keep. Deleting them
> because they appear useless seems short sighted. It's not like roads are
> deleted from OSM just because nobody uses them.
>
> Brian, Wolfgang, Clifford, Michael, talk-us:
>
> Census boundaries were imported, then, after these data were already in
> our map, consensus was reached that these were statistical areas, not
> administrative areas of government.  Specific consensus was reached (in
> talk-us, if I recall correctly) on the following:
>
> • admin_level=8 was simply incorrect and should be deleted as a tag on
> these imported census boundaries,
> • boundary=administrative was also incorrect in all cases and should be
> changed to boundary=census as a tag on these.
>
> It is also specifically noted in our wiki[1] that in Alaska, as these
> boundaries were achieved with the cooperation of the Alaska state
> government in addition to the US (federal) Census Bureau, census boundaries
> in Alaska's Unorganized Borough are believed to be useful enough to keep in
> OSM, but, again, specifically without any admin_level tag, as (to repeat),
> census areas are not administrative boundaries.
>
> This consensus has resulted in most (all?) of these admin_level=8 tags
> (some were 7, likely from subsequent edits) being (correctly) removed and
> the boundary=administrative tag being (correctly) changed to a
> boundary=census tag, though this work to correct these Census Bureau import
> data may not be complete.  The result is that what data do remain in OSM
> (what Brian says would be helpful to keep in place) are of marginal value
> (except in Alaska and perhaps a very few other places).  If/as Brian finds
> these data useful, I caution him to keep all of this in mind and perhaps
> find another methodology to "do research" with these data of questionable
> value than by using them as they presently exist in OSM.  I politely
> disagree with him that "someone will use (these data) at some point," for
> several reasons:  the data age and are not updated, they do not "map" (in a
> language or mathematical sense) well onto specifically-rendered entities in
> any OSM renderer I know of, and (imo, I could be wrong) they only serve to
> add some sense of accuracy to perhaps geocoding or place-name lookups in
> what amounts to "hacked" corner cases.  OSM can do much better here and
> indeed should do so without these census data in OSM whatsoever.
>
> So, except for in Alaska, census boundaries in OSM appear to have marginal
> or even no value to any present or future conceivable use case.  While
> deleting them (except in Alaska) or "converting them to place=* nodes" may
> be the eventually correct solution(s), no organized effort to do so, or
> examination of the history or use-case-based arguments to keep them has
> emerged or presently exists.  (We do document the situation in our wikis,
> footnoted below).  I would like to see either the deletion of
> boundary=census entities entirely (except in Alaska) after a more-complete
> discussion of why and how they are presently used (perhaps in geocoding
> algorithms) and how better tagging on "more real" and/or "more stable"
> objects can and should supersede them.  Virtually always (if not always), a
> node with tag place= with a consensus-sane value[2] completely suffices.
> Such cleanup (garbage-y, rapidly obsoleted polygons become a node) is very
> much in OSM's interest.
>
> Complicating this is the major issue of Indian Reservation boundaries.
> What has emerged as a stopgap[3] is to tag these with either
> boundary=aboriginal_lands or boundary=protected_area + protect_class=24,
> omitting the admin_level=* tag in either case.  Please read our wiki as
> footnoted here, as this may suffice to persuade you to remove the Satus
> census object, replacing it with a node tagged place=* with little or no
> affront to your sense of correctness within OSM.
>
> These issues may seem complicated, though I posit that it is their history
> clouded by misunderstanding and poor introduction of US Census Bureau data
> into OSM that are to blame.  This makes the bottom line 

Re: [Talk-us] Rural US: Correcting Original TIGER Imported Ways

[Albert Pundt]

I concur that deleting unnamed and untouched TIGER ways is the way (no pun
intended) to go. From my experience editing, many rural driveways mapped in
TIGER were converted to highway=service with access=private (though rarely
with service=driveway), though there are many more that are still just
highway=residential. If these are all deleted, it's not like we can't just
go through and map more driveways. (Driveway mapping doesn't often seem to
be much of a focus for a lot of people anyway, though they should still get
mapped eventually.)

For many of these roads around Pennsylvania, I generally set what appear to
be unpaved roads that go and piddle out in someone's field to highway=track,
and roads connecting to houses and buildings to highway=service. Sometimes
I'll fix alignment, but most of the time these fixes are sidelined in favor
of my main editing goal. I don't often go and edit random TIGER roads;
instead, I focus on the numbered routes in my state.

On Sun, Feb 25, 2018 at 9:14 PM, Nick Hocking 
wrote:

> Paul wrote  "Or maybe the unedited original TIGER that's still around
> dropped to
> highway=road.  "
>
>
> Given that the *vast* majority of these (with no name) are completely
> fictional, and even those that aren't, are so out of position and so
> wrongly connected as to render them worse than useless, I believe that
> deletion is the only sensible option.
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>
>


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

[Talk-us] rayman 765

[Albert Pundt]

A user by the name of rayman 765 has been making some... interesting edits.
He seems to be mapping some fictitious road "80/erie highway", in bits and
pieces with various classifications (everything from secondary to
motorway). He's also been adding and naming streets with abbreviated names
and no capitalization whatsoever.

Every single one of his edits has the comment "breezwood pa", even though
hardly any of his edits are around Breezewood.

What's the proper thing to do here? Obviously I can't just mass-undo every
single one of his edits, but obviously this "Route 80" is complete BS.

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

Re: [Talk-us] Old Bing/ESRI satellite imagery?

[Albert Pundt]

I concur, thanks for sharing that, Richard! Also reminded me I need to
update my imagery source list in JOSM...

As for me saying my original post was dumb, I didn't mean the very idea of
pointing out the inferior elements of the various imagery sources, I meant
more it appearing to come off as forgetting that, like Ian said, access to
these sources is a privilege and not a right, and I thought it was sounding
like the kind of attitude of entitlement that I'd make fun of in other
contexts...

On Wed, Jan 31, 2018 at 5:24 PM, EthnicFood IsGreat <
ethnicfoodisgr...@gmail.com> wrote:

>
> Message: 1
>> Date: Wed, 31 Jan 2018 03:30:14 -0600 (CST)
>> From: Richard Fairhurst 
>> To: talk-us@openstreetmap.org
>> Subject: Re: [Talk-us] Old Bing/ESRI satellite imagery?
>>
>>
>> The previous ESRI imagery has just been restored to the imagery list (by
>> ESRI, so 100% legit) under the name “Clarity”.
>>
>> Richard
>>
>>
>>
> Great!  I'm glad to hear that.  I use that imagery more than any other.
> Thanks for sharing that news.
>
> Mark
>
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>



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

Re: [Talk-us] Old Bing/ESRI satellite imagery?

[Albert Pundt]

Yeah, that wasn't right of me... I've been using the other sources for a
bit now and it's really not as bad as I thought it was, plus there's more
of the old imagery still available than I thought through
Mapbox/Digitalglobe Standard all over Pennsylvania, just not where I'm
currently working on. I guess the relatively high quality (albeit very
outdated by the time it was updated) imagery for the whole country spoiled
me a little too much. :P

Ignore my previous post, it was dumb.

On Tue, Jan 30, 2018 at 7:55 PM, Ian Dees <ian.d...@gmail.com> wrote:

> Hi Albert,
>
> Please keep in mind that all of this data you're complaining about is
> donated to the OSM community and it's a privilege to have access to it.
> Please don't take your frustrations out on the providers that are letting
> us use their service for free.
>
> All of the providers that donate their imagery are constantly adding or
> improving imagery. Since it takes a lot of work to make these imagery
> layers, the "previous iteration" is probably not out there in any way. The
> best you can do is go to the provider and ask them to improve the imagery
> so that the next imagery update can have better imagery.
>
> Also, keep an eye out for local imagery from the state (through NAIP, for
> example), your county, or city. Governments in the US frequently post their
> imagery online for you to use.
>
> -Ian
>
> On Tue, Jan 30, 2018 at 6:46 PM, Albert Pundt <roadsgu...@gmail.com>
> wrote:
>
>> With the exception of the higher-resolution imagery in cities, the
>> current Bing/ESRI World Imagery is worse than the previous iteration in
>> every way except for being newer. It's blurry, often distorted, and
>> frequently has clouds covering it. The previous imagery was crisper and
>> rarely if ever had clouds, and what little distortion there was was obvious
>> and avoidable.
>>
>> Is there any way to still access this imagery, or at least a better
>> alternative to the current Bing/ESRI imagery? If the former, then the
>> outdatedness of it could be easily worked around by comparing to the other
>> imagery available. It must exist "out there" in some capacity, since the
>> Mapbox/Digitalglobe Standard imagery still uses it in western Pennsylvania,
>> and even in some low zoom levels on Bing.
>>
>> I would use some of the other nationwide imagery options available in
>> JOSM, but most of them are   either low-resolution or with color so bright
>> and washed out it's often difficult to map with.
>>
>> —Albert
>>
>> ___
>> Talk-us mailing list
>> Talk-us@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-us
>>
>>
>


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

[Talk-us] Old Bing/ESRI satellite imagery?

[Albert Pundt]

With the exception of the higher-resolution imagery in cities, the current
Bing/ESRI World Imagery is worse than the previous iteration in every way
except for being newer. It's blurry, often distorted, and frequently has
clouds covering it. The previous imagery was crisper and rarely if ever had
clouds, and what little distortion there was was obvious and avoidable.

Is there any way to still access this imagery, or at least a better
alternative to the current Bing/ESRI imagery? If the former, then the
outdatedness of it could be easily worked around by comparing to the other
imagery available. It must exist "out there" in some capacity, since the
Mapbox/Digitalglobe Standard imagery still uses it in western Pennsylvania,
and even in some low zoom levels on Bing.

I would use some of the other nationwide imagery options available in JOSM,
but most of them are   either low-resolution or with color so bright and
washed out it's often difficult to map with.

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

Re: [Talk-us] TIGER 2017 Pennsylvania county line import?

[Albert Pundt]

> > I noticed many of the county lines in Pennsylvania are off by quite a
> > bit. I took the county lines from TIGER 2017 and imported them into
> > JOSM, and am ready to begin switching out the existing county lines

> Do you mean you'll keep the relations intact and just replace the member
> ways, or do you intend to delete the relations wholesale and introduce
> new ones?

> Where county boundaries are shared "upwards" by the state boundary, or
> "downwards" by a city boundary, will you ensure that these links are
> kept? County boundaries often don't exist in a vacuum and hence when the
> county bondary changes, the city/state boundaries need to change too,
> else you'll end up with cities straddling a county border or counties
> straddling a state border...

> Depending on what exactly you're planning to do, the JOSM "utilsplugin2"
> function "replace geometry" might be useful; it would try to keep the
> existing objects in OSM and just refine their geometry, rather than
> deleting and re-creating stuff.

I certainly don't intend to delete and recreate any relations for no
reason. Links with other boundary types will of course also be kept. The
state boundary itself will likely be redone as well to match the more
accurate newer TIGER data, though along the Mason-Dixon Line the border is
defined by boundary stones which are already mapped, so I won't touch that
part.

I'll definitely take a look at that plugin, it could help quite a bit. I
also know not to delete member ways either in order to preserve history.
What I've been doing as I edit roads is reduce the original way to a short
segment, merge that in with the new way, and then just delete the last node
to fully roll the old history in with the new way. If that plugin removes
the need to do this for every single boundary way, that's great!

—Albert

On Tue, Jan 23, 2018 at 7:31 PM, Frederik Ramm <frede...@remote.org> wrote:

> Hi,
>
> On 01/24/2018 12:46 AM, Albert Pundt wrote:
> > I noticed many of the county lines in Pennsylvania are off by quite a
> > bit. I took the county lines from TIGER 2017 and imported them into
> > JOSM, and am ready to begin switching out the existing county lines
>
> Do you mean you'll keep the relations intact and just replace the member
> ways, or do you intend to delete the relations wholesale and introduce
> new ones?
>
> Where county boundaries are shared "upwards" by the state boundary, or
> "downwards" by a city boundary, will you ensure that these links are
> kept? County boundaries often don't exist in a vacuum and hence when the
> county bondary changes, the city/state boundaries need to change too,
> else you'll end up with cities straddling a county border or counties
> straddling a state border...
>
> Depending on what exactly you're planning to do, the JOSM "utilsplugin2"
> function "replace geometry" might be useful; it would try to keep the
> existing objects in OSM and just refine their geometry, rather than
> deleting and re-creating stuff.
>
> Bye
> Frederik
>
> --
> Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"
>
> ___
> 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] TIGER 2017 Pennsylvania county line import?

[Albert Pundt]

I noticed many of the county lines in Pennsylvania are off by quite a bit.
I took the county lines from TIGER 2017 and imported them into JOSM, and am
ready to begin switching out the existing county lines in OSM. However, I
know to discuss before attempting any import, especially one of this scale.
What do you guys think?

I should add that with this import, I won't be attempting to add townships
to counties that don't already have them, nor will I be improving the
accuracy of existing town boundaries in said counties, except where they
are adjacent to the county lines.

I do have experience with this type of import, as I added township lines to
Lebanon County a few months ago.

Any objections?

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

Re: [Talk-us] Changing

[Albert Pundt]

It also allows for ref:legislative to be used (much like ref:penndot
throughout Pennsylvania) in states that still use these separate
legislative routes.

On Fri, Dec 29, 2017 at 8:49 PM, OSM Volunteer stevea <
stevea...@softworkers.com> wrote:

> BTW, I'm all for your old_ref_legislative -> old_ref:legislative
> proposal.  It seems it would harmonize tags in the East and West (of the
> USA).
>
> Briefly (my reasoning is):  combining tagging conventions with tagging
> conventions growth = growth in OSM.  It is surprising how resolving small
> syntax and semantics blurs like these truly helps everything!
>
> Steve




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

[Talk-us] old_ref_legislative vs. old_ref:legislative

[Albert Pundt]

Shouldn't the tag old_ref_legislative (used primarily in Pennsylvania but
applicable elsewhere) be old_ref:legislative according to current key
naming conventions? According to taginfo, old_ref_legislative
 is used by
far mostly in Pennsylvania to mark the pre-1987 legislative numbers, but a
few uses exist in California and England. In all there are over 40,000 uses
of this key. old_ref:legislative
 on the
other hand is used only in California, but still with over 18,000 uses.

Does anyone think it might be worth it to attempt to change all the
old_ref_legislative values to old_ref:legislative in line with current
tagging conventions, much like what was already done with the creation of
ref:penndot to replace using ref and penndot_ref for PA's state-owned
routes?

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

Re: [Talk-us] Talk-us Digest, Vol 116, Issue 44

[Albert Pundt]

Perhaps this <https://en.wikipedia.org/wiki/Township_(Pennsylvania)>
Wikipedia entry will help clarify things. Pennsylvania's townships are
incorporated and exist on a level equivalent with boroughs (towns), cities,
etc.

On Fri, Jul 28, 2017 at 5:07 PM, OSM Volunteer stevea <
stevea...@softworkers.com> wrote:

> On Jul 28, 2017, at 1:12 PM, Albert Pundt <roadsgu...@gmail.com> wrote:
>
> Yes, rereading what I said, it does sound a lot like "This is the way it
> is because of the way that it is."
>
> Firstly, "towns" ("town" in quotes here referring to anything that would
> be generically called a town in everyday language) in Pennsylvania are
> almost never incorporated as towns. Only one is: Bloomsburg. Every other
> "town" that is incorporated is actually a borough (and I'm not aware of any
> boroughs that aren't "towns"), a township (e.g. Annville Township in
> Lebanon County, Mt. Lebanon Township in Allegheny County), or a small city.
> Most townships, however, are just wide rural area and not really based
> around any real settlement like my two examples are.
>
> These "towns" (i.e. boroughs, etc.) aren't part of the surrounding
> township, much like Philadelphia isn't part of any of the surrounding
> counties. It's a "county" all its own (actually a consolidated city-county,
> so the analogy isn't perfect). They're all isolated from each other on the
> same equivalent level directly below the county. For the purposes of admin
> level, these various boundaries (township, borough, town, etc.) are
> interchangeable. I don't know how things are set up on a sub-county level
> in other states, but in Pennsylvania, this is all a single level of
> boundary.
>
> On Jul 27, 2017, at 9:19 PM, Albert Pundt <roadsgu...@gmail.com> wrote:
>
> No, I meant that townships, boroughs, cities, etc. should all  be mapped
> with admin level 8, which they seem to already be, but the information from
> the wiki seemed to contradict that.
>
>
> Thanks, Albert:  we are both doing well at keeping our tone civil and
> generating more light than heat.  This can be hard work, but it's worth it!
>
> If I may paraphrase/simplify what you say above:
>
> 1)  Towns are not incorporated (as opposed to cities, which are), unless
> they really are incorporated small cities, but are colloquially called
> "towns."
> 2)  If what is colloquially called a town IS incorporated, (as above), it
> could be a small city, or it is possible that its true name is "borough."
> 3)  If what is colloquially called a town is NOT incorporated, its true
> name is "township."
>
> When you say that "most townships are just wide rural area," I ask you to
> note that admin_level rather exactly denotes NOT how rural or (un)populated
> an area is, but rather how an administrative (governmental) organization
> subordinates to a higher level (and has lower levels subordinate to it).
> So while I do pay heed to "wide rural area" (because you make that
> observation to me, and I wish to respect it), for purposes of assigning the
> correct value to admin_level in OSM, I steer focus instead directly to the
> proper question of "townships subordinate to what government?"  In that
> light, I do believe (though I continue to listen) that "township" (in
> Pennsylvania, like all other states) is a set of subdivisions which
> completely subdivide counties — directly.  (Some might be "organized" with
> a government, some might not).  And as county is 6, township, because of
> the DIRECT subordination, must be 7.  This is consistent with all other 19
> states which have townships, though, again, if Pennsylvania's townships
> truly aren't like this, I'm listening.  I don't think you can make a case
> that a township should be an 8 because of this "direct subordination
> coupled with complete subdivision:"  as county is 6, township must be 7,
> not 8.
>
> It may seem that a "single level of boundary" is below county, but as
> township is a legal division of a county, I don't think this is possible.
>
> Continuing my paraphrasing:
>
> 4)  Boroughs are not part of surrounding townships.  (I do note with you
> that Philadelphia is a Consolidated City County, which OSM maps as two
> coterminous boundary relations, one tagged admin_level=6 for the county,
> another tagged admin_level=8 for the city.  Yes, it does make Philadelphia
> a confusing example, so we should erase it from the set of examples as a
> confusing special-case).
>
> I consider https://en.wikipedia.org/wiki/Pennsylvania#Municipalities an
> authoritative source.  (It happens to agree with you a

Re: [Talk-us] Pittsburgh neighborhood boundaries mapped with admin level 9?

[Albert Pundt]

Why are townships, boroughs, towns, and cities in PA mapped with separate
admin levels, or at least "supposed to be" mapped that way according to
that page? As far as I know they're always only ever one level below
county, and never overlap. i.e. you never have a town in the middle of some
other township. There are plenty of smaller towns and villages that are
unincorporated and just census-designated places, but these aren't
administrative divisions and are mapped with boundary=census. So why should
the various county subdivisions get differing admin levels? Plus, from what
I've seen they seem to only ever be admin_level=8 anyway.

On Thu, Jul 27, 2017 at 3:53 PM, OSM Volunteer stevea <
stevea...@softworkers.com> wrote:

> OK, three topics shake out from this, two Pennsylvania, one Boston.  I'll
> try (and likely fail) to be brief:
>
> 1)  Pittsburgh's neighborhoods, now entered and tagged admin_level=9, seem
> like they are better entered as admin_level=10, to harmonize with
> neighborhoods in many other states.  Boundaries with value 9 are "something
> else," emerging as consensus (not necessarily fully entered into OSM,
> though they could be in, say, New Orleans) for a city with BOTH wards as 9
> AND neighborhoods as 10, since we need to preserve the hierarchy between
> the two.  I propose that the Pittsburgh neighborhood polygons be changed
> from 9 to 10 and that a "Neighborhood" entry at 10 be entered into
> Pennsylvania's row in US_admin_level wiki's "Big Table" (I could change
> them with a quick Overpass query-to-JOSM edit).  Yes?
>
> 2)  Pennsylvania's structure in the Big Table (the above notwithstanding)
> is now:
>
> Pennsylvania-4, County-6, with City-8 directly subordinate to County-6,
> Pennsylvania-4, County-6, Township-7, Village-8/Hamlet-8,
> Pennsylvania-4, County-6, Borough/Boro-7, Town-8.
>
> However, we'll need to add Neighborhood-10 (assuming the answer to 1)
> above IS "Yes") somewhere, at least to the City-8 sub-row as Pittsburgh is
> a City.  I doubt we need to add Neighborhood-10 to the Township-7,
> Village-8/Hamlet-8 sub-row, but I could be wrong.  What about the
> Borough/Boro-7, Town-8 sub-row?  Do THOSE have Neighborhood-10?  (I doubt
> it, but I could be wrong).  City, yes.  The others?  Let's leave those
> "N/A" for now.
>
> 3)
> > On Jul 27, 2017, at 11:02 AM, Bill Ricker  wrote:
> > Massachusetts looks correct in the small table to my eye in terms of
> legal entities, Wards and Precincts are primary fine-scale legal entities.
> I know my Ward and Precint numbers in Boston, so can confirm they exist.
> >
> > OTOH there are no "signs on the ground" for Wards or Precincts.
> >
> > As noted in Talk, there are also Council Districts but their mapping
> onto Wards/Precincts will *change* for re-gerrymandering after each census
> (which in Boston is an on-going process, we don't wait for Federal census
> to count noses!)  and could be easily abolished if we opted for all
> city-wide seats again.  Wards and Precinct boundaries are less flexible;
> deeds reference them; Precincts are  the fundamental unit that City, State
> House, State Senate, US House district gerrymanders are built from; but
> still even Ward boundaries are adjusted periodically if a precinct
> suddenly is built up or industrialized.
> >
> > Neighborhoods are also formally defined by city planning dept in Boston.
>
> So, Bill, Massachusetts' entry in the Big Table is a bit of a hack, since
> we have:
> Massachusetts-4, County-6, Town-8, Precinct-9
> Massachusetts-4, County-6, City-8, Ward-9, Precinct-10
> but in Ward-9 we say "Boston has Districts and Wards."
>
> As you say you can confirm that Boston has Ward and Precinct (which we
> capture without Boston's exceptional mention), and (Council) Districts are
> "mapped onto Wards/Precincts," can you clarify whether the Big Table needs
> an entry for Boston for (Council) Districts?  Where would that go?  9?
> 10?  Are there other cities in Massachusetts which do this?  And as you say
> that Neighborhoods are also in Boston, where do those fit into Boston being
> 8, having 9 as Ward and Precinct as 10 (with perhaps Districts as a
> "different 9" and perhaps Neighborhoods as a "different 10")?  Or, perhaps
> because these are so changeable (with regular re-districting) we simply do
> not enter them, or enter them and perhaps leave them alone.  Whew!
>
> Regarding signs:  admin boundaries sometimes do have signs on the ground,
> often do not, especially for 9 and 10 entities.  OSM consensus seems to be
> OK with saying that an admin boundary not clearly being delineated "in real
> life" or being marked by signage everywhere "on the ground" is not really
> sufficient reason to suppress these important map objects from OSM's
> database.  While it may seem controversial, I believe a strong argument can
> be made that if we are defining and mapping admin_level=2, 4, 6 and 8,
> because we also define 10, we might as well map 10 where it really 

[Talk-us] Pittsburgh neighborhood boundaries mapped with admin level 9?

[Albert Pundt]

I noticed that the neighborhoods in Pittsburgh are mapped as administrative
boundaries with admin_level=9. Is this proper? The wiki page
 for U.S.
admin levels doesn't list any use for admin level 9 in Pennsylvania, though
this seems appropriate if Pittsburgh neighborhoods are true administrative
divisions. It just needs to be documented, or perhaps used elsewhere in the
state, like with the fairly distinct neighborhoods in Philadelphia.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

[Talk-us] Directions as route relation roles

[Albert Pundt]

The wiki page Highway Directions In The United States lists a method of
tagging directions in route relation roles that sets the role as the posted
direction of the way in OSM's forward direction. For single-carriageway
roads, this means that backwards is the opposite cardinal direction.
Presumably two-way roads carrying only one direction of a route (which only
exist in brief segments, but are common nationwide) are still given just
"forward" and "backward". Or would multiple values be used, e.g.
"north;forward"?

My question is whether this is actually commonly used. I haven't seen this
method used anywhere, but then again I haven't really looked either. How
widespread is this practice?
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] No updates on zoom level 12?

[Albert Pundt]

I think that zoom levels 12 and below just take a really long time to
update. One road classification change I made over a month ago has still
not yet updated on these lower zoom levels. Another edit made several
months ago took a similarly long time to update there, though it has long
since been updated.

--Roadsguy

On Tue, Apr 4, 2017 at 11:45 AM, Kevin Kenny 
wrote:

> http://www.openstreetmap.org/relation/7083920#map=12/41.3995/-74.0276 for
> one! My experience is that it can be weeks before I see level 12 tiles,
> unless I catch the render queue just right.
>
> On Apr 4, 2017 10:35 AM, "Clifford Snow"  wrote:
>
>>
>> On Tue, Apr 4, 2017 at 1:52 AM, Wolfgang Zenker <
>> wolfg...@lyxys.ka.sub.org> wrote:
>>
>>> is there a known problem with tile updates for zoom level 12?
>>> That zoom level is not updating for the area around Harlowton MT for
>>> about two months now, despite marking tiles dirty several times
>>> in the last 8 weeks.
>>>
>>
>> I haven't heard of any issues - what is missing?
>>
>>
>> --
>> @osm_seattle
>> osm_seattle.snowandsnow.us
>> OpenStreetMap: Maps with a human touch
>>
>> ___
>> Talk-us mailing list
>> Talk-us@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-us
>>
>>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] NJ mass road demotions?

[Albert Pundt]

The user is granpueblo <https://www.openstreetmap.org/user/granpueblo> and
he's made a lot more than one changeset
<https://www.openstreetmap.org/user/granpueblo/history>...

--Roadsguy

On Tue, Apr 4, 2017 at 11:00 AM, Albert Pundt <roadsgu...@gmail.com> wrote:

> Recently somebody went around and bulk-"demoted" many northern NJ roads.
> Granted, some of these were marked as trunk and primary that would probably
> be better as primary and secondary, respectively, but this person made
> various trunk routes secondary (including major arterials such as US 206,
> NJ 15, US 46, NJ 31, etc. that should be no lower than primary), primary
> routes tertiary, and demoted most if not all secondary and tertiary routes
> to residential/unclassified. This seems like a way overboard change. I
> started to fix the more obvious errors here, but it seems like it would be
> way quicker and easier to revert the changeset and start over with fewer
> and more conservative reclassifications. What are your thoughts on this?
>
> --Roadsguy
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

[Talk-us] NJ mass road demotions?

[Albert Pundt]

Recently somebody went around and bulk-"demoted" many northern NJ roads.
Granted, some of these were marked as trunk and primary that would probably
be better as primary and secondary, respectively, but this person made
various trunk routes secondary (including major arterials such as US 206,
NJ 15, US 46, NJ 31, etc. that should be no lower than primary), primary
routes tertiary, and demoted most if not all secondary and tertiary routes
to residential/unclassified. This seems like a way overboard change. I
started to fix the more obvious errors here, but it seems like it would be
way quicker and easier to revert the changeset and start over with fewer
and more conservative reclassifications. What are your thoughts on this?

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

[Talk-us] highway=trunk for NHS routes?

[Albert Pundt]

As a general rule, should highway=trunk be used for routes on the National 
Highway System? Considering that those routes are generally more backbone 
routes, more important than a lot of primary routes, it makes sense that they 
should be tagged with trunk.
--Roadsguy___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

[Talk-us] Relation roles: Clockwise and Counterclockwise route directions? (e.g. Pittsburgh's Belts)

[Albert Pundt]

I know that north/south/east/west directions are preferred for relation roles 
of one-way route segments (e.g. one-way pairs or divided highways), but what 
about clockwise and counterclockwise? Often beltways, like D.C.'s Capital 
Beltway, are signed such that they abruptly go from north/south to east/west, 
but then you have routes like Pittsburgh's Belt System, where the Belts aren't 
signed with directions at all. These seem to be given "CW" (clockwise) and 
"CCW" (counterclockwise) roles. Is this correct, or does "forward" or some 
other role need to be used?
--Roadsguy___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

[Talk-us] Relation roles for two-way way segments carrying routes in a single direction

[Albert Pundt]

So I understand that one-way ways carrying a route (e.g. a one-way pair or 
divided highway) should have relation roles of north/south/east/west, but say 
you have a situation like this. Say you have an east-west route that follows 
the primary roads in that picture. The eastbound direction follows the 
channelized right turn slip ramp, marked with a red arrow. The westbound 
direction follows the blue-arrow way, before turning left onto the green-arrow 
way.
How should relation memberships and roles be assigned here? I would think that 
the slip ramp would be part of the relation, since right-turning traffic must 
follow it. Ideally, that would be given the role "east", but what about the 
green and blue ways? It might seem right to give them the role "west", but how 
then is it differentiated which direction is westbound for it? Since all the 
ways in this picture are arranged "pointing" north or east, the green and blue 
ways would need to be given the role "backward", which is the older way of 
doing things that can't specify cardinal direction. Is replacing the single 
relation with separate relations for each direction the only good way to do 
this, or are such two-way segments the only times that "forward" and "backward" 
roles should be used?
I checked the wiki page, but it doesn't seem to specify. Instead, it just says 
such cases are very rare (which is only true relatively speaking, as routes 
very commonly turn at intersections with channelized right turns, making 
situations like the linked example very common.
--Roadsguy___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us