Re: [Talk-us] Recent Trunk road edits

[Jack Burke]

On Tue, Sep 29, 2020 at 2:35 AM Mateusz Konieczny via Talk-us
 wrote:
>
> 29 wrz 2020, 02:02 od b...@mapwise.com:
>
> An example unhelpful comment:
>
> "YES GEORGIA IS BADLY-TAGGED TRUNK FREE! Control is provided by 
> floridaeditor; i.e., if anybody tries to change one back I will review the 
> edit and keep/revert as needed."
>
> WTF
>
> Brian aka grouper
>
> Can you link to changeset where it happened?
>
> This alone is enough to involve DWG
> and I would expect at least 0-time block
> (message displayed on login).

Mateusz,

The specific one that Brian quoted is here:
https://www.openstreetmap.org/changeset/87987046

--jack

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

Re: [Talk-us] Recent Trunk road edits

[Jack Burke]

On Mon, Sep 28, 2020 at 8:02 PM Brian May  wrote:
>
> I'm Florida based, have seen Floridaeditor's changes and noticed an eagerness 
> to change a lot of road classifications. I didn't pay a lot of attention 
> until now. Of course, trunk can be a tricky one, but if you got one lone guy 
> on a mission who is arguing with everyone along the path, reverting any 
> differences of opinion, etc - that is getting abusive and needs to stop. It 
> is certainly NE2ish behavior. Other than NE2s behavior towards people who 
> didn't agree and subsequent banning, he taught me a good bit, did a lot of 
> good for FL and was actually inspirational in the beginning of my OSM journey 
> showing what was possible and the impact a prolific editor could have. Sucks 
> that he couldn't play well with others. Pretty sure he was based out of 
> Orlando. Floridaeditor started editing in the Melbourne area not far from 
> Orlando. His editing behavior is somewhat similar to NE2 in that they are / 
> was editing a fairly wide variety of feature types. Also a focus on highway 
> types in many other states and forcefully arguing with others in other states 
> / local stomping grounds.
>
> Anywho, seems like collective wisdom should rule the day with most things 
> OSM, right? Especially long-time editors who have been through the wilderness 
> and put a lot of thought into how features be mapped and tagged. And 
> importantly are engaging with others in a respectful way.
>
> An example unhelpful comment:
>
> "YES GEORGIA IS BADLY-TAGGED TRUNK FREE! Control is provided by 
> floridaeditor; i.e., if anybody tries to change one back I will review the 
> edit and keep/revert as needed."
>
> WTF
>
> Brian aka grouper

That is one of several of his comments that convinces me he doesn't
really want to work with the community.


> On 9/28/2020 7:29 PM, Evin Fairchild wrote:
>
> 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?

He has been invited here, to Slack, and the OSM web forum by no less
than 3 different people (and maybe more--I haven't examined all of his
changesets).

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

Re: [Talk-us] Recent Trunk road edits

[Jack Burke]

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

[Jack Burke]

On Mon, Sep 28, 2020 at 12:02 PM Paul Johnson  wrote:
>
> On Mon, Sep 28, 2020 at 10:42 AM Jack Burke  wrote:
>>
>> On Monday, September 28, 2020, Paul Johnson  wrote:
>>
>> Georgia 400 is a grade-separated, divided, high-speed freeway from its 
>> southern endpoint at I 85, all the way to where it meets GA 369 near Coal 
>> Mountain, 37 miles later. From there, it's an at-grade, divided, high-speed 
>> (mostly 65mph, with short sections of 55mph in denser areas) highway with 
>> extremely long straight sections and other sections with high-speed curves, 
>> until it ends at GA 60 just outside Dahlonega, 16 miles past Coal Mountain.
>
>
> Yeah, not looking very hard at this so don't know if I missed any at-grade 
> intersections looking at Maxar/Mapbox. I'd call that a motorway pretty 
> solidly from I 85 to GA 306 and a trunk north of that to GA 60.  Looks like 
> it turns into GA 115 at GA 60, didn't trace that further but I'd call GA 60 a 
> secondary.

I would call your assessment spot-on, except with a disagreement that
the motorway should end at GA 306 (I think it's fine classified that
way all the way to GA 369).  But that really comes down to individual
preference.  I'm certainly not going to try to argue with someone over
it.  (For reference, my rational for choosing 396 is because that's
where the overhead sign is declaring "signal ahead, prepare to stop.")


>> GA 515 begins life where I 575 ends, at Ball Ground. From there, it is a 
>> grade-separated, divided, high-speed (mostly 65mph, with a few sections of 
>> 55mph, and a couple of 45mph when it passes through Ellijay and Blue Ridge) 
>> freeway that travels north to Blue Ridge, almost at the Tennessee border, 
>> where it arcs eastward and continues to Blairsville.  That's 63 miles of 
>> divided high-speed goodness. There it finally becomes an undivided highway 
>> that continues on to Young Harris, "ending" a few miles past there. GA 515 
>> was upgraded to its dual-carriageway status about 30 years ago as part of 
>> the Appalachian development highway program.
>
>
> Looking at the same imagery as above, yeah, I'd call I 575 a trunk north of 
> Howell Bridge Road and GA 515 a trunk from I 575 until the south end of Blue 
> Ridge, where the single carriageway through town is primary (it stops being 
> an expressway and becomes a boulevard for a bit), and then picks back up as 
> trunk on the north end of town before going primary again at Blairsville.

Again, spot-on, except I'd leave the undivided section through Blue
Ridge as trunk.  (Why?  Because it's so short, and is there really a
need to classify it lower there?)


>> All of these, and others, were highway=trunk until floridaeditor decided to 
>> downgrade them (and challenge anyone to change them back)
>
>
> So far it seems like floridaeditor is the exact opposite of NE2 (who smashed 
> everything in network=US:US to highway=trunk even if it's not an expressway 
> or super-two freeway, something we're still cleaning up particularly in the 
> midwest and Texas).  Given NE2 was also in Flordia, I wouldn't rule out it's 
> the same person.

I never dealt with NE2 directly, since I started after his banishment,
but I have come across a lot of his work.  Some of it I do have to
tilt my head sideways at, but there have been quite a few things he
did that I thought were pretty good.  But that notwithstanding, this
person is going the exact opposite direction with his edits.  Can they
really be the same person?

--jack

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

Re: [Talk-us] Recent Trunk road edits

[Jack Burke]

On Mon, Sep 28, 2020 at 1:21 PM Shawn K. Quinn  wrote:
>
> On 9/28/20 11:00, Paul Johnson wrote:
> > Given NE2 was also in Flordia, I wouldn't rule out it's the same person.
>
> I was considering the same possibility. Given he's been indefinitely
> banned from editing, if we find out it is him doing this, should the
> project consider legal action? This is rather wide-scale vandalism from
> the looks of it.

I started editing post-NE2, so I never had the pleasure of
encountering him.  If it *is* him, then he's doing the exact opposite
of what I've heard about him in terms of road classifications.  For
that reason, it just doesn't sound like him to me, but like I said, I
never worked with him, so I can't really speak to his "touch" when it
comes to how his edits look.

I was hoping someone else would come out and use the "V" word before I
did--thank you, Shawn.  It helps reassure me that I'm not way off base
with my assessment of what is going on.

--jack

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

Re: [Talk-us] Recent Trunk road edits

[Jack Burke]

On Monday, September 28, 2020, 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.
>
> 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...heck, not all sections of Interstates qualify for
> highway=motorway, there's at least a couple dozen spots where this is true,
> like pretty much any customs checkpoint, the transitions to where an
> interstate ends and it continues as another kind of highway past the last
> exit before a junction,
>
>
>> Related: if it's I-## or I-###, shouldn't it be a highway=motorway,
>> period? (Unless those, for some reason, are ever *not* freeways?)
>>
>
> No.  Very much not, in fact.  Network and classification are, relative to
> the UK, quite disconnected.  Most of the Interstate network that is
> bannered as Detour (more common in disaster prone areas where getting
> around a freeway closure isn't obvious and yet happens frequently enough to
> have permanently signposted detour routes for such occasions) or Business
> tends to be trunk at most (I can think of a couple places where a Business
> Interstate runs down expressway sections that used to be US 66) but usually
> is *extremely* not a freeway (usually boulevards and two lane roads).
> Get up to Alaska and mainline interstates aren't freeways and usually
> aren't even signposted (I'd be surprised if anything outside Fairbanks and
> Anchorage warrants higher than a secondary tag realistically, but the US
> loves to creep everything upwards, overstating connectivity).  Some cities
> operate full blown freeways, some interstates are gravel barely-a-road.
>
>
Matthew and Paul, hang on!

I am *not* trying to say that the roads in question should be
highway=motorway (except for the part of Georgia 400 that is, in fact, a
motorway).  I *am* trying to say that they should be highway=trunk.  My use
of the term "freeway" to describe them was artistic in nature, to describe
how it feels actually driving on them.   That's all.

Now back to our regularly scheduled program.

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

Re: [Talk-us] Recent Trunk road edits

[Jack Burke]

On Monday, September 28, 2020, Paul Johnson  wrote:

> On Sun, Sep 27, 2020 at 8:35 PM Jack Burke  wrote:
>
>> Recently, someone has taken it on himself to downgrade most (all?)
>> highway=trunk roads in the eastern U.S. to just primary.  The odd
>> thing is that the very wiki page he cites as his reason fully supports
>> keeping them as trunk.  Many of them I'm personally familiar with, and
>> even absent the wiki's definition, they actually make more sense as
>> trunk from a driving perspective.
>
>
> The wiki's pretty inconsistent but the generally accepted standard is
> "it'd be a motorway if it didn't have intersections" or "it'd be a motorway
> if it was dual carriageway".  I think some context would help.
>

How about a pair of highways that "would be motorways if they didn't have
intersections" for context?

Georgia 400 is a grade-separated, divided, high-speed freeway from its
southern endpoint at I 85, all the way to where it meets GA 369 near Coal
Mountain, 37 miles later. From there, it's an at-grade, divided, high-speed
(mostly 65mph, with short sections of 55mph in denser areas) highway with
extremely long straight sections and other sections with high-speed curves,
until it ends at GA 60 just outside Dahlonega, 16 miles past Coal Mountain.

GA 515 begins life where I 575 ends, at Ball Ground. From there, it is a
grade-separated, divided, high-speed (mostly 65mph, with a few sections of
55mph, and a couple of 45mph when it passes through Ellijay and Blue Ridge)
freeway that travels north to Blue Ridge, almost at the Tennessee border,
where it arcs eastward and continues to Blairsville.  That's 63 miles of
divided high-speed goodness. There it finally becomes an undivided highway
that continues on to Young Harris, "ending" a few miles past there. GA 515
was upgraded to its dual-carriageway status about 30 years ago as part of
the Appalachian development highway program.

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

And then there's US 27/GA 1, a highway that was upgraded as part of the
GRIP initiative a bunch of years ago.  It's a north-south highway in west
Georgia that connects Chattanooga to Tallahassee. It's a mixture of divided
and undivided sections (far more divided than undivided), that switches
between 65mph (in most of the divided sections) and 55 mph (many of the
undivided sections) except when it passes through Rome and a couple of
other cities. And there are several other highways that meet this
description, too.

When all of these were upgraded to their current configuration, they were
built specifically to provide smooth, high-speed highway access to more
rural areas of the state, with the possibility of being upgraded further to
Interstate-level one day (think the new I 22).

All of these, and others, were highway=trunk until floridaeditor decided to
downgrade them (and challenge anyone to change them back).

Does that help any, Paul?

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

Re: [Talk-us] Recent Trunk road edits

[Jack Burke]

Clifford,

If I'm going to name names, I may as well include a few relevant links, too.

The editor in question is "floridaeditor"
https://www.openstreetmap.org/user/floridaeditor and he has a diary
entry about what he's doing (in addition to what he has on his profile
page about it).  He changed *every single* trunk road in Georgia to
primary, and from what I can tell, in Florida, too.  I haven't yet
expanded my examination into other states yet.

One example changeset comment can be found here:
https://www.openstreetmap.org/changeset/87987046
Another (where he reverted someone's reversal of his edits) is:
https://www.openstreetmap.org/changeset/88299504

I myself haven't added any comments to some of his changesets yet
because of his borderline belligerent attitude in his remarks.  He
essentially sets himself up as the judge and jury about whether or not
he will "accept" any requests for a change back to trunk.  A few other
people have (one of whom did so in a less than helpful manner, even
though he's local and from what I can tell, should likely be familiar
with the roads in question), but I'm just being an observer on that
for now.

I'm on Slack, and I originally posted a comment about this editor on
some roads in Florida (that I'm familiar with), but the responses I
saw seemed to be somewhat "meh" so I didn't pursue it.  If there's
another thread about it there, I'd love to read it, because (1) I
missed it, and (2) if it's about the same person, y'all weren't very
successful in reverting the changes.

--jack

On Sun, Sep 27, 2020 at 10:21 PM Clifford Snow  wrote:
>
> Jack,
> First off - lets name names. Who is this person? We did have a discussion on 
> Slack a while back about an editor changing trunk to something other than 
> trunk. As far as I know we were successful in reverting many of those.
>
> Not everyone is comfortable using Slack and I understand. However, they 
> should respond to changeset comments. Especially from someone familiar with 
> the road. If they ignore you, then I would recommend involving DWG. If they 
> just want to argue then but won't join Slack, then I'd invite them to to this 
> mailing list discuss why they feel a particular road should be changed from 
> trunk to primary.
>
> Best,
> Clifford
>
> On Sun, Sep 27, 2020 at 6:35 PM Jack Burke  wrote:
>>
>> Hi all,
>>
>> Recently, someone has taken it on himself to downgrade most (all?)
>> highway=trunk roads in the eastern U.S. to just primary.  The odd
>> thing is that the very wiki page he cites as his reason fully supports
>> keeping them as trunk.  Many of them I'm personally familiar with, and
>> even absent the wiki's definition, they actually make more sense as
>> trunk from a driving perspective.
>>
>> A few other editors have been getting involved in discussions with
>> him, some helpfully, others not quite.  He was specifically invited to
>> join this mailing list (and tagging), to discuss things, but as far as
>> I can tell hasn't done so yet.  Andy from DWG also suggested that he
>> join the OSMUS Slack channel, but I can't tell that he's done that,
>> either.
>>
>> Of particular concern to me isn't just his downgrades, but his
>> attitude about them.  Some of his changeset comments basically tell
>> anyone who disagrees with him to appeal his decision to him, and he'll
>> decide if the appellant is right or not, and if he catches anyone
>> reversing his changes, he'll just revert it back.  Given his
>> already-posted attitude about his edits, I'm not sure that trying to
>> message him privately will do much good.
>>
>> I'm going to go ahead and put out here that I've gone ahead and
>> changed some of them back to highway=trunk anyway, because as I said,
>> they just make more sense that way, *and* meet the wiki's definition.
>> And I'm quite sure that he'll revert them as soon as he notices.
>>
>> Does anyone have any suggestions, comments, questions, jokes, etc.,
>> about the situation?
>>
>> Regards,
>> Jack
>>
>> ___
>> Talk-us mailing list
>> Talk-us@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-us
>
>
>
> --
> @osm_washington
> www.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] Recent Trunk road edits

[Jack Burke]

Hi all,

Recently, someone has taken it on himself to downgrade most (all?)
highway=trunk roads in the eastern U.S. to just primary.  The odd
thing is that the very wiki page he cites as his reason fully supports
keeping them as trunk.  Many of them I'm personally familiar with, and
even absent the wiki's definition, they actually make more sense as
trunk from a driving perspective.

A few other editors have been getting involved in discussions with
him, some helpfully, others not quite.  He was specifically invited to
join this mailing list (and tagging), to discuss things, but as far as
I can tell hasn't done so yet.  Andy from DWG also suggested that he
join the OSMUS Slack channel, but I can't tell that he's done that,
either.

Of particular concern to me isn't just his downgrades, but his
attitude about them.  Some of his changeset comments basically tell
anyone who disagrees with him to appeal his decision to him, and he'll
decide if the appellant is right or not, and if he catches anyone
reversing his changes, he'll just revert it back.  Given his
already-posted attitude about his edits, I'm not sure that trying to
message him privately will do much good.

I'm going to go ahead and put out here that I've gone ahead and
changed some of them back to highway=trunk anyway, because as I said,
they just make more sense that way, *and* meet the wiki's definition.
And I'm quite sure that he'll revert them as soon as he notices.

Does anyone have any suggestions, comments, questions, jokes, etc.,
about the situation?

Regards,
Jack

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

Re: [Talk-us] Underground railways, indoor mapping, and overlapping features

[Jack Burke]

Hi Clay. 

I would use the layer=* tag to reflect the various elevations of the tracks in 
question, and probably offset them slightly from each other to make future 
editing easier. 

-jack
-- 
Typos courtesy of fancy auto spell technology.

On May 4, 2020 2:15:07 PM EDT, Clay Smalley  wrote:
>Hi all,
>
>Lately I've been tasking myself with mapping underground railway tracks
>across the US, adding features like parallel tracks, crossovers, and
>platforms wherever I can. My work includes the Market Street Subway in
>downtown San Francisco and various lines in Philadelphia. I recently
>began
>doing this work on the NYC Subway—a huge system and a daunting task.
>Fortunately, a local contributor (IsStatenIsland) has been working on
>it as
>well and we've had some friendly collaborative discussion.
>
>We're stumped on how to properly handle railways directly on top of
>each
>other. I've been able to avoid this issue for the most part, as it's
>rare
>in Philly (save some bits of non-revenue trackage) and the
>double-decker
>subway in San Francisco supports two railways with different gauges,
>making
>their centerlines differ by a few inches. But railways with identical
>centerlines are a frequent occurrence in New York, with its various
>configurations of local and express tracks.
>
>For example, the IRT Lexington Avenue Line (supporting 4, 5, 6, and <6>
>trains) between 42nd and 103rd Streets, a length of about 3 miles, was
>constructed as a double-decker cut-and-cover tunnel. In this case, the
>express tracks lie directly beneath the local tracks. Currently this
>segment is mapped on OSM as a single track with minimal detail [1]. How
>should we go about adding these details?
>
>We've come up with some potential solutions, each of which seems to
>have
>its own drawbacks:
>
>1. Sharing nodes between levels, as in the Simple Indoor Tagging
>schema.
>This is the approach IsStatenIsland has taken, with a working example
>at
>the West 4th Street–Washington Square station [2].
>2. Duplicate nodes with identical positions.
>3. Duplicate nodes, but positions scooched off-center a negligible
>distance. This is how I mapped out Grand Central Terminal [3], with the
>lower level mapped a foot or so away from where it should be.
>
>Personally, I'm leaning more towards #2. My qualm with #1 is that it
>adds
>intersections to the two overlapping levels of railways, which I find
>misleading. And with #3 I worry that I'm mapping for the renderer.
>
>Thoughts?
>
>-Clay
>
>[1] https://www.openstreetmap.org/way/569345492
>[2] https://www.openstreetmap.org/node/597928309
>[3] https://www.openstreetmap.org/node/7099182377
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Tagging "Junior College" or "Community College"?

[Jack Burke]

I've been using amenity=college for those. They fit the meaning of "further 
education" to me, and I didn't see the need for yet another category. 

-jack

-- 
Typos courtesy of fancy auto spell technology.

On February 17, 2020 10:20:56 PM EST, Joseph Eisenberg 
 wrote:
>How are people tagging places known as "junior colleges" or "community
>colleges?" Usually these offer 1 or 2 year associates degrees and
>diplomas in specific trades or work fields, or general higher
>education courses which make it possible to transfer to a 4-year
>University.
>
>Is it proper to use amenity=college? That tag was originally developed
>for insitutes of "Further Education" in the UK, which are a bit
>different than North American junior/community colleges. Is anyone
>using amenity=university instead?
>
>- Joseph Eisenberg
>
>___
>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] The San Jose / Santa Clara border

[Jack Burke]

Does anyone know someone who lives in the "disputed" area? If so, then one 
definitive information point is what local government elections he/she can vote 
in. 

-jack 
-- 
Typos courtesy of fancy auto spell technology

On January 26, 2019 8:50:39 PM EST, Joseph Eisenberg 
 wrote:
>Do the latest NGS topographical maps show the city limits properly?
>Those
>are public domain
>On Sun, Jan 27, 2019 at 10:16 AM OSM Volunteer stevea <
>stevea...@softworkers.com> wrote:
>
>> On Jan 26, 2019, at 4:00 AM, Andy Townsend  wrote:
>> > A mapper has recently changed this to "cut the corner off" north of
>the
>> 880 between San Jose airport and Stevens Creek Mall / Westfield
>Valley
>> Fair.  You can see the change at
>>
>http://overpass-api.de/achavi/?changeset=66619223=18=37.33883=-121.93327=B0TTTFT
>> .
>> >
>> > Some of this mapper's previous changes have had to be undone, so I
>did
>> check the node change made here to see if it might be one of them.
>> However, according to the node history
>>
>https://www.openstreetmap.org/node/373647840/history#map=13/37.3600/-121.9066
>> the original source of this node was a changeset quite a while ago
>with a
>> description "adjust boundaries based on san jose city map, bing, and
>common
>> sense ".  It therefore would be great if a local could check it if
>possible.
>>
>> I'm fairly local (SJC is my "home airport") yet I'm not finding
>> easily-available San José City Limit boundaries in an ODbL-compatible
>> format which I could use to relatively quickly repair the damage. 
>(The
>> user mk408 has a history of "making it up as he sees fit" OSM data
>entry
>> which many have disputed or redacted, for example, many years ago he
>made
>> MANY roads in the entire South Bay region — Campbell, Los Gatos,
>Monte
>> Sereno, southern San José —into highway=tertiary roads, and that
>remained
>> very questionable until it slowly but surely "healed itself," again,
>this
>> took months-to-years).  There are some geo data at
>> http://csj-landzoning.appspot.com/index.html which indicate the
>present
>> OSM data are "largely correct," the exception being that the area
>directly
>> over the northern part of the airport do not include the "leg" that
>> "covers" runway 12L/30R and that the acute angle over taxiways V, W
>and W1
>> is more like "aligned with these taxiways, rather than cutting across
>> them."  You really have to see them rather than expect that I can
>describe
>> them with text.  They are, again, "mostly correct" but could use some
>> rather minor correction.
>>
>> As I bumped into somebody on a plane on my way back from SOTM-US
>Seattle
>> (2016) who works in the San José City Hall and when she met me was
>bowled
>> over at the coincidence that I was the very person sitting next to
>her
>> drinking gin and tonic who entered into OSM most of Santa Clara
>County's
>> bikeways/bicycle infrastructure and network=lcn routing (which the
>city
>> office found "extremely helpful" — her words), it's conceivable that
>I
>> might be able to use that to sway release of some data which could be
>> forthcoming.  While I don't know quite who to call, exactly, if
>somebody
>> wants to "release to me" ODbL-compatible data which need to be
>harmonized
>> with what are now in OSM, I'll volunteer to be the "nexus of citizen
>entry"
>> to assure they find their way into our wonderful map.  Send me a
>pointer to
>> the data, assure me they are ODbL-OK and I'll "merge" these into OSM.
>>
>> SteveA
>> California
>> ___
>> 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

[Jack Burke]

As Paul said, it depends on the type of road.  In Georgia, the signage
has been the brown keystone one for roads that mere mortal cars can
drive on:
https://www.mapillary.com/map/im/HD_cjbQunrGWEQCViX-Now

And the vertical ones with FS on them for people with more advanced vehicles:
https://www.mapillary.com/map/im/3Il7nk3S4MuMX9jR_SIQnw

And, as I said, their IVR map uses NF for all of them

--jack

On Thu, Nov 29, 2018 at 3:36 PM Paul Johnson  wrote:
>
> On Thu, Nov 29, 2018, 14:14 Kevin Broderick >
>> Doesn't the Forest Service use FR for "Forest Road" at the reference? I'd 
>> think that, or NFR to distinguish from state forest roads, would be the more 
>> appropriate ref, as FS is ambiguous (it doesn't distinguish between a forest 
>> road and a forest trail).
>
>
> Maybe on visitor brochures, but on signage they get keystone shields for two 
> digit routes and either a vertical or horizontal rectangle sign (depending on 
> whether or not motor vehicles are expected to travel) for minor routes, and 
> the numbers all constitute a single network regardless of if it's a road or a 
> trail.
>
> I seem to recall when I lived near a national forest that TIGER and the USGS 
> would use Forest Service XX when spelling out major routes, and National 
> Forest Development XXX or NFD  on the minors.
>
> In either case, most people that travel in or near national forests regularly 
> will find FS and NFD immediately recognizable.
>
> ___
> 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

[Jack Burke]

Oh I am so happy that Frederik brought this up.  I've been thinking
about this topic for a while, but just haven't said anything.  I love
the ensuing discussion, too.

So, first, the wiki page on now to tag the refs
https://wiki.openstreetmap.org/wiki/United_States_roads_tagging#National_Forest_Road_System
says to use NFR and NFH, as Kevin Kenny does.  I use neither.  As
others are doing, I use FS for Forest Service.  I'll note that on the
wiki page's Discussion tab, there are several people who question the
use of NFR/NFH, which seems to have been arbitrarily selected by one
person and added to the wiki without any real discussion about it.

Just to pick nits, Martijn, I'd like to point out that the example
sign for forest road 858 on that page you linked to has "National
Forest" on it, not FS or Forest Service.  If we were to go purely by
the sign, we should be using NF.  The National Forest Service
website's Interactive Visitor's Map at https://www.fs.fed.us/ivm/ uses
exactly that in an underlay layer for those maps.

That said, I still prefer FS because that's generally how most people
seem to refer to them (forest service).

Side note:  there are several forest service roads in north Georgia
that are represented on Mapillary and OpenStreetCam, if anyone wants
to "drive" one of them from the comfort of your living room.  (More
are apparent on Mapillary than OSC because of the different ways those
two services process sequences that don't have a matching OSM road.)

--jack

On Wed, Nov 28, 2018 at 4:03 PM Paul Johnson  wrote:
>
> On Wed, Nov 28, 2018 at 2:51 PM Eric H. Christensen  wrote:
>>
>> On Wednesday, November 28, 2018 9:49 AM, Martijn van Exel  
>> wrote:
>>
>> > I think you are right. It would be good if we can arrive at a common
>> > prefix and document it on the wiki. 'FS' makes sense. Perhaps even a new
>> > page dedicated to roads that are maintained directly by federal agencies
>> > (NPS, USDA, others?) would make sense. I'd be happy to help set it up.
>>
>> I've noticed that some of these "roads" are showing FS, FT, and another F 
>> something when they were imported.  Should all these ways use 'FS' or should 
>> they use the different prefix based upon what type of way they are (outside 
>> of the proper tagging for the way)?
>
>
> Note that the Forest Service uses the same numbering scheme for trails, with 
> 2 digit Forest Service routes being the main routes (be it a hiking trail or 
> a road), 3 digit and 4 digit routes being of lesser importance in the overall 
> network and usually being referred to as National Forest Development or NFD 
> trails/roads.
> ___
> 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] USPS Post Boxes

[Jack Burke]

Because they are labeled "United States Postal Service" with big stickers, 
that's how I've been tagging them. 

-jack

-- 
Typos courtesy of fancy auto spell technology

On August 28, 2018 4:02:40 PM EDT, Jmapb  wrote:
>On 8/28/2018 3:31 PM, Leif Rasmussen wrote:
>> Hi everyone,
>> A couple of days ago, I noticed that different post boxes in the 
>> United States had different ways of tagging that they were part of
>the 
>> USPS system.  Roughly 60% had "operator"="USPS", 40% 
>> "operator"="United States Postal Service", and about 15 similar to 
>> "operator"="United States Post Services" or "United States Post 
>> Office".  I wanted to make them all the same, so I asked on the OSMUS
>
>> Slack group about the tags, and most people supported "USPS".  I then
>
>> proceeded to upload a changeset manually converting 1500 "United 
>> States Postal Service" or similar to "USPS".  I should have waited 
>> longer before uploading.
>> https://www.openstreetmap.org/changeset/62020302
>> https://overpass-turbo.eu/s/Boq
>> All post boxes in the USPS system now have "operator"="USPS".
>> After uploading, people expressed concern about the choice of "USPS" 
>> over "United States Postal Service".  The wiki states that 
>> abbreviations should be expanded, "USPS" could be confused with other
>
>> agencies 
>> , and 
>> this counted as an automated edit, which should have had better 
>> planning with the OSM community.
>> I would now like to propose converting all post boxes with the tag 
>> "operator"="USPS" to "operator"="United States Postal Service".  I 
>> would also like to add the tag "operator:wikidata"="Q668687" to the 
>> post boxes that currently have "operator"="USPS".  Please reply with 
>> any feedback or concerns you have with this proposal.
>
>Thanks for looping us in, Leif. Haven't made it to the slack group yet,
>
>but when I noticed that change I thought to myself "thank the Lord,
>it's 
>over!" Every time I've tagged a post box I've managed to convince
>myself 
>that I did it wrong the previous time. So I rotated between "USPS", 
>"usps" and "United States Postal Service" and figured I'd get around to
>
>fixing them when my brain settled down. Seeing someone else take the 
>initiative was a relief, despite the understandable grumbling about 
>automated edits.
>
>Now that it's done, I'm in favor of making an exception to the 
>no-abbreviations rule for a fixed set of couriers, so sticking with 
>USPS. It's easy to tag and read, and I don't think it's truly 
>ambiguous... if the United States Power Squadrons start a courier 
>service, *they* should be tagged with the fully expanded name.
>
>Another reason is that there are plenty of private company post boxes, 
>and I'd like the tagging style to be consistent as possible, with the 
>commonly-used compact versions of their names. I feel operator=UPS, 
>operator=FedEx, operator=DHL will be easier to write, maintain, and
>read 
>than operator=United Parcel Service, operator=Federal Express, 
>operator=.. well, I still can't figure out what DHL actually stands
>for.
>
>Also -- not an issue for postboxes per se, but I've found occasion to 
>tag some some shops with the shipping companies they offer, and the
>idea 
>of a semicolon-seperated list of fully expanded shipping company names 
>makes me weary.
>
>(No problem with adding the operator:wikidata tag.)
>
>Thanks, Jason
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Proposition for changing the common name tag

[Jack Burke]

I am opposed to this suggestion, because there are two countries called "United 
States" in North America: the United States of America, and the United States 
of Mexico.

Yes, when people say "United States" they typically mean America and not 
Mexico, but the USA is just as often referred to as "America" as it is "United 
States," which is another reason not to proceed with the change. 

-jack

-- 
Typos courtesy of fancy auto spell technology

On August 16, 2018 12:51:27 PM EDT, "Daniel Koć"  wrote:
>Hi,
>
>I wanted to let you know about proposed change in tagging the name of
>USA and I seek for the feedback about it - see the proposition here:
>
>https://forum.openstreetmap.org/viewtopic.php?id=63384
>
>
>
>
>
>-- 
>"My method is uncertain/ It's a mess but it's working" [F. Apple]
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

[Talk-us] Clarke County, Mississippi, county road signs and OSM name tags

[Jack Burke]

Asking for thoughts & opinions...

While some counties just attach a number to a pole (e.g., many counties in
Georgia), there are some that put up signs saying "CR 123" (Jasper County,
Mississippi) for unnamed county roads.  However, Clarke County, Mississippi
signs (with shiny new green-signs-on-a-stick) county roads as "Clarke Co.
123".  What are everyone's thoughts on how to name these roads in OSM for
Clarke County?  We can just leave the name field blank and use ref=CR 123,
we can do the ref tag and also include name=County Road 123, or we can do
ref=CR 123 and name=Clarke County 123.  Or even ref=CR 123, name=Clarke
County 123, alt_name=County Road 123.  Or swap the name= and alt_name=
values.

Keep in mind that a lot of county roads in OSM already have name=County
Road 123 from a bulk import many moons ago.

Clarke County, MS, example:
https://www.mapillary.com/map/im/l9YS7slPwIDc-3Qw8IQaqg

Jasper County, MS, example:
https://www.mapillary.com/map/im/_mZvHi1tX9ddTJKS5DLiFg

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

Re: [Talk-us] Drop the tiger:reviewed tag from roads

[Jack Burke]

I kinda object to any type of mechanical removal of this tag, mainly
because I do still use it.  I've modified JOSM's settings to show the
yellow highlight, and I periodically go on a TIGER editing spree,
especially in the county I live in.  It has been very valuable in finding
and fixing misnamed roads and other errors.

One of my main objections to a mechanical removal is that there are
numerous rural-area roads where the only edit I've done is to add the
county road number as a ref tag (often I will document these as a voice
note in OsmAnd as I drive past them on a higher-priority road).  I won't
necessarily have verified the road name, surface, or any other attributes
at the time.

--jack


On Fri, May 11, 2018 at 1:05 PM, Martijn van Exel  wrote:

> I was thinking about this some more. I do still actually use the visual
> cue (yellow) in JOSM to see which roads I want to double-check when editing
> in an area. I don't know if this is still enabled in JOSM by default but
> it's available as one of the default paint styles.
> --
>   Martijn van Exel
>   m...@rtijn.org
>
> On Fri, May 11, 2018, at 10:59, Steve Friedl wrote:
> > > I believe folks still use it in places to indicate that no-one has
> reviewed it on the ground, but I cannot find the thread(s) where that was
> brought up.
> >
> > I’m exactly one of those users: once I’ve confirmed or fixed the object,
> > I delete the tag, so this is still useful for me as a kind of to-do
> > list.
> >
> > I also delete tiger:reviewed=yes tags when otherwise editing an object.
> >
> > Steve
> >
> >
> > From: Martijn van Exel [mailto:m...@rtijn.org]
> > Sent: Friday, May 11, 2018 9:56 AM
> > To: talk-us@openstreetmap.org
> > Subject: Re: [Talk-us] Drop the tiger:reviewed tag from roads
> >
> > I believe folks still use it in places to indicate that no-one has
> > reviewed it on the ground, but I cannot find the thread(s) where that
> > was brought up.
> >
> > I think a mechanical removal may be a bit overzealous, even though I
> > personally wouldn't shed a tear. As long as there is at least one tag
> > left that would indicate TIGER as the original source, so we can
> > continue to detect 'unmodified TIGER' roads.
> > --
> >   Martijn van Exel
> >   mailto:m...@rtijn.org
> >
> >
> >
> > On Fri, May 11, 2018, at 10:25, Clifford Snow wrote:
> > The tag, tiger:reviewed that is left over from the 2006/7 import of
> > TIGER roads has lost any meaning. For example, look at 196th Avenue
> > Southwest [1] in Thurston County WA. It's on version 6 yet still has
> > tiger:reviewed=no. Note I picked this street at random from a overpass
> > query [2]. I see this tag all the time. It's time to get rid of it. Not
> > through a mechanical edit, but by editors making changes to roads.
> >
> > I'm proposing to open a ticket for JOSM to add this tag to the list of
> > discarded tags. I'd like to hear if there are any objects or think this
> > is a good idea.
> >
> > I did learn from Toby Murray this morning that you can add
> > tiger:reviewed to the list of discarded tags in JOSM by going to
> > preferences->Advanced Preferences and adding tiger:reviewed to
> > tags.discardable. Then just reload JOSM for the changed to be active.
> >
> > [1] http://www.openstreetmap.org/way/173554611
> > [2] http://overpass-turbo.eu/s/yJh
> >
> > Clifford
> >
> > --
> > @osm_seattle
> > http://osm_seattle.snowandsnow.us
> > OpenStreetMap: Maps with a human touch
> > ___
> > Talk-us mailing list
> > mailto: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] Maximum number of tasks on US tasker

[Jack Burke]

I add lanes=2 (or other, as appropriate) even when they aren't striped.  If
striping is going to be a requirement, how "fresh" does it have to be?  I
see quite a few roads where you can tell that striping once existed because
of some barely-visible remnants in spots

On Tue, May 8, 2018 at 10:00 PM, Paul Johnson <ba...@ursamundi.org> wrote:

> Right, we're only counting striped lanes.
>
> On Tue, May 8, 2018 at 7:43 PM, Jack Burke <burke...@gmail.com> wrote:
>
>> But they *are* lanes. They just aren't striped.
>>
>> -jack
>> --
>> Typos courtesy of fancy auto spell technology
>>
>>
>> On May 8, 2018 3:24:08 PM EDT, Paul Johnson <ba...@ursamundi.org> wrote:
>>>
>>> The tag you're looking for is width, not lanes.
>>>
>>> On Tue, May 8, 2018, 13:29 Tod Fitch <t...@fitchdesign.com> wrote:
>>>
>>>> Most residential roads in my area are unstriped but are definitely
>>>> built for two lanes of traffic (one in each direction). It seems perfectly
>>>> reasonable to me to tag them with lanes=2 as they are designed to take two
>>>> lanes of traffic.
>>>>
>>>> In fact, as part of some traffic calming measures a number of
>>>> residential roads are having the lane striping removed. They claim that
>>>> people tend to drive slower if there is no marking showing the boundary for
>>>> oncoming traffic. I certainly will not be removing lanes=2 from those 
>>>> roads.
>>>>
>>>>
>>>> > On May 8, 2018, at 11:20 AM, Mike N <nice...@att.net> wrote:
>>>> >
>>>> > On 5/8/2018 11:55 AM, Paul Johnson wrote:
>>>> >> Then with residential streets where there are no lanes, often
>>>> lanes=2 would get tagged anyway despite nothing on the ground suggesting
>>>> that was actually the case.
>>>> >
>>>> >  I hadn't considered that unstriped roads shouldn't have lane
>>>> tagging, but at least this doesn't cause bad effects for map data users.
>>>> >
>>>> > ___
>>>> > 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] Maximum number of tasks on US tasker

[Jack Burke]

But they *are* lanes. They just aren't striped.

-jack
-- 
Typos courtesy of fancy auto spell technology

On May 8, 2018 3:24:08 PM EDT, Paul Johnson  wrote:
>The tag you're looking for is width, not lanes.
>
>On Tue, May 8, 2018, 13:29 Tod Fitch  wrote:
>
>> Most residential roads in my area are unstriped but are definitely
>built
>> for two lanes of traffic (one in each direction). It seems perfectly
>> reasonable to me to tag them with lanes=2 as they are designed to
>take two
>> lanes of traffic.
>>
>> In fact, as part of some traffic calming measures a number of
>residential
>> roads are having the lane striping removed. They claim that people
>tend to
>> drive slower if there is no marking showing the boundary for oncoming
>> traffic. I certainly will not be removing lanes=2 from those roads.
>>
>>
>> > On May 8, 2018, at 11:20 AM, Mike N  wrote:
>> >
>> > On 5/8/2018 11:55 AM, Paul Johnson wrote:
>> >> Then with residential streets where there are no lanes, often
>lanes=2
>> would get tagged anyway despite nothing on the ground suggesting that
>was
>> actually the case.
>> >
>> >  I hadn't considered that unstriped roads shouldn't have lane
>tagging,
>> but at least this doesn't cause bad effects for map data users.
>> >
>> > ___
>> > 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] Spam account

[Jack Burke]

I would forward the account link and your explanation to d...@openstreetmap.org

-jack

-- 
Typos courtesy of fancy auto spell technology

On April 28, 2018 10:39:23 PM EDT, Ian Nicholson  wrote:
>What's the process for reporting a spam account?  I'm fairly certain 
>that 
>https://www.openstreetmap.org/user/Payday%20Loans%20in%20Winona%20MN is
>
>not a legitimate mapper.
>
>
>___
>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] Gravel roads and surface tags in the US

[Jack Burke]

Keep in mind that OSM apparently uses "compacted" to refer to macadamized 
roads, which is a specific process for building roads. 

Maybe they wiki should be updated to say that roads with loose pieces of gravel 
scattered around but a hardened underlying surface is compacted, not gravel?

-jack

-- 
Typos courtesy of fancy auto spell technology

On April 19, 2018 9:22:15 AM EDT, James Umbanhowar  wrote:
>I grew up in an area with these kinds of roads and I don't think
>they're technically compacted.  The gravel, which is crushed
>limerstone, is laid down and due to its chemical properties creates a
>smooth surface after several months of traffic.
>
>I've used surface=gravel; gravel=crushed_limestone in my area.  I don't
>get the gravel being 4-8 cm, that seems a wikierror.
>
>James
>
>On Wed, 2018-04-18 at 17:19 -0500, Toby Murray wrote:
>> I recently bought a gravel bicycle to ride on the many gravel roads
>> in
>> Kansas. Like this one:
>> https://www.mapillary.com/app/?pKey=nYO4JI46L0SWzNAQlLT4kA=phot
>> o
>> 
>> First question: What would you call this road? Obviously I am calling
>> it a "gravel road" but a couple of people have said they would call
>> it
>> a "dirt road" so I'm curious if there are any other common terms to
>> describe this type of road in different regions of the US.
>> 
>> Second question: How would you tag this road? There is a
>> surface=gravel tag that is in pretty common usage in Kansas and
>> neighboring states. However looking at the wiki page for the surface
>> tag[1], this is not wiki-correct. According to that page
>> surface=gravel is to be used for large rocks (4-8cm) that are laid
>> down loosely like those typically used as ballast on railroad beds. I
>> believe The Mapillary picture I linked to would be considered
>> surface=compacted according to the wiki because the rocks are much
>> smaller and the surface is stabilized with a binding agent. There is
>> a
>> big difference between the two when it comes to bicycle riding.
>> Railroad ballast is bone jarring and flat tire inducing whereas
>> gravel
>> roads are pretty manageable on the right kind of bike.
>> 
>> But If you call something a "gravel road" and there is a "gravel"
>> option in the editor preset for the surface tag, people are going to
>> choose the gravel option and not look for "compacted" since that is
>> not a common term here. I assume it is a more common term in the UK
>> and that is why it is used in OSM.
>> 
>> And lastly there are trails that are surfaced with a similar material
>> but crushed to a smaller size like here:
>> https://www.mapillary.com/app/?pKey=iQNqP-dfQ-Rm6AD9REMsgQ=phot
>> o
>> 
>> I'm trying to decide if that is better as surface=compacted or
>> surface=fine_gravel although fine_gravel seems to be a slightly
>> different process from what I see on the wiki.
>> 
>> Maybe this should be directed at the tagging list but I thought I
>> would get thoughts from the US community since we seem to be the ones
>> using the tag incorrectly (according to the wiki)
>> 
>> [1] https://wiki.openstreetmap.org/wiki/Key:surface
>> 
>> Toby
>> 
>> ___
>> 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] Gravel roads and surface tags in the US

[Jack Burke]

I've been tagging roads like that as compacted, once I learned more about the 
surfacing tech.

-jack

-- 
Typos courtesy of fancy auto spell technology

On April 18, 2018 6:19:07 PM EDT, Toby Murray  wrote:
>I recently bought a gravel bicycle to ride on the many gravel roads in
>Kansas. Like this one:
>https://www.mapillary.com/app/?pKey=nYO4JI46L0SWzNAQlLT4kA=photo
>
>First question: What would you call this road? Obviously I am calling
>it a "gravel road" but a couple of people have said they would call it
>a "dirt road" so I'm curious if there are any other common terms to
>describe this type of road in different regions of the US.
>
>Second question: How would you tag this road? There is a
>surface=gravel tag that is in pretty common usage in Kansas and
>neighboring states. However looking at the wiki page for the surface
>tag[1], this is not wiki-correct. According to that page
>surface=gravel is to be used for large rocks (4-8cm) that are laid
>down loosely like those typically used as ballast on railroad beds. I
>believe The Mapillary picture I linked to would be considered
>surface=compacted according to the wiki because the rocks are much
>smaller and the surface is stabilized with a binding agent. There is a
>big difference between the two when it comes to bicycle riding.
>Railroad ballast is bone jarring and flat tire inducing whereas gravel
>roads are pretty manageable on the right kind of bike.
>
>But If you call something a "gravel road" and there is a "gravel"
>option in the editor preset for the surface tag, people are going to
>choose the gravel option and not look for "compacted" since that is
>not a common term here. I assume it is a more common term in the UK
>and that is why it is used in OSM.
>
>And lastly there are trails that are surfaced with a similar material
>but crushed to a smaller size like here:
>https://www.mapillary.com/app/?pKey=iQNqP-dfQ-Rm6AD9REMsgQ=photo
>
>I'm trying to decide if that is better as surface=compacted or
>surface=fine_gravel although fine_gravel seems to be a slightly
>different process from what I see on the wiki.
>
>Maybe this should be directed at the tagging list but I thought I
>would get thoughts from the US community since we seem to be the ones
>using the tag incorrectly (according to the wiki)
>
>[1] https://wiki.openstreetmap.org/wiki/Key:surface
>
>Toby
>
>___
>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] Rural US: Correcting Original TIGER Imported Ways

[Jack Burke]

I've been leaving all the TIGER tags and just changing reviewed from no to 
yes

The main reason I've been leaving them is I don't know who might want to make 
use of that information. 

-jack

-- 
Typos courtesy of fancy auto spell technology

On February 13, 2018 5:13:16 AM EST, Mark Wagner  wrote:
>On Mon, 12 Feb 2018 13:25:02 -0800
>OSM Volunteer stevea  wrote:
>
>> On Feb 12, 2018, at 1:07 PM, Tod Fitch  wrote:
>
>> > Anyway, what is the current best practice dealing with TIGER tags
>> > once the road has been surveyed and corrected? Remove all TIGER
>> > tags or just the reviewed tag?  
>> 
>> As I am not familiar with the "things you've read," while also
>> wondering myself whether additional TIGER tags (tiger:cfcc,
>> tiger:zip, etc.) should remain or be deleted, I also pose this
>> question to the greater talk-us community.  What DO we do with these
>> additional TIGER tags as we endeavor to "clean up TIGER" in the USA?
>> Is there consensus on a definitive "best practice" for removing or
>> leaving them?  (Consensus is clear that we remove tiger:reviewed=no
>> after we've reviewed the way).
>> 
>> Our wiki https://wiki.osm.org/wiki/TIGER_fixup is silent on this
>> particular issue (of removing or leaving additional tags).  BTW
>> another wiki of ours, https://wiki.osm.org/wiki/TIGER_Edited_Map
>> gives a nice overview/documentation of the Ito map.
>> 
>> We might create a new thread or keep it in this one:  but even as a
>> seasoned TIGER cleanup volunteer, I don't know what to do with
>> additional TIGER tags, and I guarantee everybody reading this that
>> I'm not alone there!
>
>I find the "tiger:county" tag to be useful as a quick way to figure out
>where I am when looking at a changeset or otherwise am zoomed in on the
>map while editing.  "tiger:zip" would be useful when adding addresses
>if
>I could trust it, but it's wrong too often.  The rest of the tags
>aren't useful because either they can be derived from the OSM-relevant
>tags on the road, or they're wrong/outdated.
>
>-- 
>Mark
>
>___
>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] Leonia, NJ doesn't want you to navigate through

[Jack Burke]

Someone on the osmus Slack channel pointed out that this would affect routing 
for people who are in the town and want to go somewhere else in town, where 
that route wouldn't normally involve travelling on the major through roads. 

-jack 


On January 9, 2018 4:31:22 PM EST, Paul Norman <penor...@mac.com> wrote:
>On 1/8/2018 10:53 AM, Jack Burke wrote:
>> I'll leave it to others to decide what, if anything, we should do 
>> about this.
>>
>>
>http://newyork.cbslocal.com/2018/01/05/leonia-streets-off-navigational-apps/
>
>If they actually go through with it, access=destination on the 
>applicable streets, or motor_vehicle=destination if it's motor vehicles
>
>only.
>
>I think what they're doing is a bad idea and unlikely to achieve their 
>stated goals, but that's a problem of the city, not us. We just need to
>
>map what they do accurately.
>
>___
>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] Leonia, NJ doesn't want you to navigate through

[Jack Burke]

I'll leave it to others to decide what, if anything, we should do about this. 

http://newyork.cbslocal.com/2018/01/05/leonia-streets-off-navigational-apps/

--jack

-- 
Typos courtesy of fancy auto spell technology___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] I 85 Express Lane (Atlanta, Georgia)

[Jack Burke]

gure it
out.


> Extending this somewhat: I’ve traditionally mapped on and off ramps with
the link leaving/joining the main way where
> the painted line becomes solid. With the relatively recent addition of
change:lanes=*, I am wondering if the ramps should
> join the freeway at the actual physical point and the short lengths of
acceleration/deceleration lanes which are physically
> part of the main traveled way be shown as another lane with change:lanes
tagging to indicate where you are not supposed to cross.

This discussion came up on the Slack channel not too long ago.  I don't
think the conversation went on long enough to give a true consensus, but
the general attitude I interpreted from the conversation is that the latter
is the way to go now.

On Sun, Sep 24, 2017 at 8:47 PM, Tod Fitch <t...@fitchdesign.com> wrote:

>
> > On Sep 24, 2017, at 5:22 PM, Minh Nguyen <m...@nguyen.cincinnati.oh.us>
> wrote:
> >
> > On 22/09/2017 09:46, Jack Burke wrote:
> >> My questions are:
> >> * Should this lane be drawn as a separate way?  Legally, you cannot
> enter or exit the lane except at the designated sections, so drawing it
> separately makes things simpler for routers.  If it's drawn separately, a
> pair of motorway_link roads would need to be added at several places (the
> dashed-stripe sections).  The Lanes wiki page[4] seems to say that it
> should be drawn separately:  "If one or more lanes of the road are
> restricted to high-occupancy vehicles (typically vehicles with 2+
> occupants, although this varies by jurisdiction). Most useful if
> entrance/egress is permitted at any point along the route; if entering or
> exiting the HOV lane(s) is only permitted at certain locations, modeling
> the HOV lane(s) as separate ways is preferable."  (Even though that says
> HOV, the same reasoning appears relevant for toll.)  Does everyone concur
> with this construction?
> >
> > I might be inclined to map the lane as a separate way, but only because
> I don't know of any routers that currently recognize the change:lanes tag.
> [1] Either way, it makes sense to treat HOV and toll lanes similarly.
> >
> > [1] https://wiki.openstreetmap.org/wiki/Key:change
> >
>
> I strongly recommend mapping them as one way with the hov:lanes=* and
> change:lanes=* showing the restrictions and where you can transition
> between the lanes. That is the best tagging I know of to accurately reflect
> the actual configuration.
>
> The reason I feel strongly about it is that many miles of HOV lanes in my
> are were mapped as separate lanes (done before I moved to the area). And
> now CalTrans is repainting those to allow entry and exit at anyplace
> (change from a variety of old paint styles to broad dashed white striping).
> If the HOV lanes had been tagged as a single way with change:lanes showing
> the restrictions on moving to and from the non-HOV lanes it would have been
> trivial to change the mapping to conform to the current paint. Mapped as
> separate ways you have to go back and remove the separate ways then the
> paint changes which is a pain.
>
> When there is a solid line (I’ve seen white, yellow and a variety of
> parallel white/yellow versions of the “don’t change lanes here striping),
> there are generally designated areas for transitioning between HOV and
> non-HOV lanes. If you map the HOV as a separate way then you need to add
> any number of virtual cross over ways. I wondered why OsmAnd and Maps.me
> were always telling me to do slight rights or slight lefts in those areas
> until I looked at the mapping and saw the separate HOV lanes with virtual
> link ways connecting it to the non-HOV lanes. In essence putting in
> separate HOV ways where they don’t actually exist doesn’t always help the
> router.
>
> FWIW, the JOSM plug-in that deals with change:lanes shows things nicely.
> And I suspect that routers like OsmAnd will be supporting it soon (if not
> already) as they support turn:lanes pretty well.
>
> Extending this somewhat: I’ve traditionally mapped on and off ramps with
> the link leaving/joining the main way where the painted line becomes solid.
> With the relatively recent addition of change:lanes=*, I am wondering if
> the ramps should join the freeway at the actual physical point and the
> short lengths of acceleration/deceleration lanes which are physically part
> of the main traveled way be shown as another lane with change:lanes tagging
> to indicate where you are not supposed to cross.
> ___
> 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] I 85 Express Lane (Atlanta, Georgia)

[Jack Burke]

Howdy folks,

I'm looking for advice on how to tag properly a complex lane condition.

I 85 northeast of Atlanta (both NB and SB) has an express lane[1][2] that
extends for many miles (sample section located here:
https://osm.org/go/ZSAYLN0I0-?m= ).  The lane is not barrier separated from
the normal traffic lanes; a solid double white paint stripe is the legal
"barrier" for the lane, with dashed sections every few miles representing
the "entrance/exit" section (visible in Mapillary imagery for the above
linked segment).

Legally allowed to use the lane are:
* vehicles with electronic toll cards (PeachPass [GA], SunPass [FL],
QuickPass [NC]), except those in the prohibited categories
* vehicles with 3 or more occupants, with or without a toll card
* motorcycles, with or without a toll card
* emergency vehicles (ambulances, etc.)
* Alternative fuel vehicles WITH the special AFV license plate (does not
include hybrids), with or without a toll card

Specifically prohibited from the lane are:
* vehicles with more than 2 axles
* vehicles with more than 6 wheels

So, it is both a toll lane and[3] an HOV lane.


To add to the fun, at GA 316, there is an express-lane-only on/off ramp set.

Someone has added the following FIXME tag to the relevant section of I 85:
 "add separated HOT lanes, adjust lane count"


My questions are:

* Should this lane be drawn as a separate way?  Legally, you cannot enter
or exit the lane except at the designated sections, so drawing it
separately makes things simpler for routers.  If it's drawn separately, a
pair of motorway_link roads would need to be added at several places (the
dashed-stripe sections).  The Lanes wiki page[4] seems to say that it
should be drawn separately:  "If one or more lanes of the road are
restricted to high-occupancy vehicles (typically vehicles with 2+
occupants, although this varies by jurisdiction). Most useful if
entrance/egress is permitted at any point along the route; if entering or
exiting the HOV lane(s) is only permitted at certain locations, modeling
the HOV lane(s) as separate ways is preferable."  (Even though that says
HOV, the same reasoning appears relevant for toll.)  Does everyone concur
with this construction?

* How should access tags be set?  Assume for the discussion that the
express lane is NOT drawn separately (the current case); it is easy to
visualize how the tags would look if it's drawn separately.  Right now,
there is only a "hov:lanes=designated|yes|yes|yes|yes|yes" tag.
Considering that tolled non-HOV vehicles can use the lane, should that tag
be left or removed?  If it's left, then
"access:lanes=no|yes|yes|yes|yes|yes"[5],
"motorcycle:lanes=designated|yes|yes|yes|yes|yes",
"afv:lanes=designated|yes|yes|yes|yes|yes" and probably
"hgv:lanes=no|yes|yes|yes|yes|yes" should be added.  Just how do you tag
access restrictions for something that is "Toll OR HOV OR motorcycle OR
AFV"[6]?  (And, do we need a separate HOV tag for high-passenger counts?
HOV:count=3?)


As a separate item, in my spare time, I'm going to try to put together wiki
page proposals for AFV (Alternative fuel vehicle) and PTV (Personal
transportation vechile; i.e., golf carts and similar that can be driven on
public streets) if I can find the time.

Feedback, comments, questions: all are welcome.
--Jack


[1] http://peachpass.com/peach-pass-toll-facilities/about-i-85-express-lanes
[2] https://dps.georgia.gov/i-85-expres-lanes-hot-lanes
[3] A grammatical "and," not a logical one.
[4] https://wiki.openstreetmap.org/wiki/Lanes
[5] https://wiki.openstreetmap.org/wiki/Tag:access%3Ddesignated  in the
"only hov=* vehicles" example.  But perhaps this tag should be left out?
[6] A logical "or," not a grammatical one.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] The Republic of Molossia (and other micro-nations)

[Jack Burke]

I would call this map vandalism and delete. 

-jack
-- 
Typos courtesy of fancy auto spell technology

On September 3, 2017 6:51:27 PM EDT, Bradley White  
wrote:
>Something a little bit different:
>
>The Republic of Molossia is a self-declared "micro-nation" located
>near Dayton, NV, landlocked by the United States. The nation claims
>full sovereignty from the United States; however, it is recognized by
>neither the United States, nor any other country on Earth, as an
>independent nation. You have probably heard about it before, since it
>is one of the best-known examples of such a micro-nation in the US.
>
>Within the past few months, this "nation" has popped into OSM,
>complete with sloppily implemented "admin_level=2" and
>"boundary=national" tags, view-able here:
>http://www.openstreetmap.org/#map=18/39.32281/-119.53908. My
>discussion point is whether this is a valid use of these tags. A
>handful of quick searches about this topic didn't turn up anything for
>me, so I'm assuming no precedent has been set yet. It is worth noting
>that this is not the only micro-nation in the US.
>
>I'm not inclined to think these tags are valid. Otherwise, there's
>nothing stopping me from calling my backyard its own nation, slapping
>together a wikipedia article, and entering it into OSM as a
>full-fledged nation. However, since they are still geographically
>based entities of interest to the public, I think they are worth
>mapping
>
>There is a proposal for disputed boundaries, but I don't think that's
>valid either since there isn't really a dispute. The nation has gone
>unacknowledged by the United States, and nothing has gone through the
>legal process between the two nations (that I'm aware of) that could
>constitute a "dispute". No other boundary tag is really applicable,
>maybe a new "boundary=micronation" would work? De facto, US law still
>applies in these "micronations", along with the law of whatever
>jurisdictions the micronation belongs to, so I don't think an
>admin_level tag is applicable.
>
>___
>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] Best practice in Lane Editing 3

[Jack Burke]

According to one Georgia lawyer's website[1] as well as the Indiana
driver's handbook[2], it is illegal to cross a solid white line between
lanes.  Having said that, I would map Case 1 as shown in A, because I don't
think any police officer is going to bother writing a ticket if someone
does so when entering a turn lane, as well as for the reasons Marc
outlined.  I come across turn lanes mapped as separate ways all the time,
especially when the lane has a median separation at the point of the turn.
I change them so that the _link road separates from the main road just
before where the median is.  I will note that in some construction zones,
particularly where the lanes have been shifted temporarily, they do put
down solid white lines between lanes sometimes, specifically because they
don't want vehicles changing lanes in that section of road.

A *double* solid white line, however, would almost certainly draw police
attention if you were to cross it, so those probably should be mapped
separately.

A turn lane that has a painted median, however, I do map as a separate
_link because it is technically illegal to drive on the median, and routing
software needs to be able to alert drivers before the turn lane separates
from the main road.

Regarding case 2, I'm reasonably sure that it would be illegal for someone
coming from the south to make those turns.  I seem to recall hearing that
there is a legal minimum distance you're supposed to drive before changing
lanes, although I can't find it in the Georgia driver's manual.  I
periodically run into some local police officers who can probably answer
that for me, at least as the law is in Georgia.  I think every state does
have a minimum legal distance, which varies from state to state, that
you're supposed to signal your turn before making it, and there is simply
no way a driver coming from the south would be able to meet that
requirement.  In the picture provided, I would actually "cheat" the link
road a little so that it connects to the main road just before where the
side road comes in.  It looks like a difference of only a few feet in the
picture, so I don't think that's a critical enough distance where cheating
the connection point is an issue.  (If it were more than just a few feet,
then no, I wouldn't cheat the connection point.)

--jack

[1]
http://www.lawofficeofscottmiller.com/faqs/is-it-legal-for-my-vehicle-to-cross-a-solid-white-line-.cfm
[2] https://www.in.gov/bmv/files/Drivers_Manual_Chapter_5.pdf



On Fri, Jul 14, 2017 at 4:02 PM, Marc Gemis  wrote:

> On Thu, Jul 13, 2017 at 10:14 PM, Eric Ladner 
> wrote:
> > Just to play Devil's advocate:  B is probably more TECHNICALLY correct
> since
> > a solid white line indicates "lane change discouraged, but not illegal"
> and
> > you'd probably want the routing software to indicate where the turn lane
> > starts, not 200 feet later (esp. in heavy traffic and the lane's already
> > full of cars).
>
> In Belgium (and other European countries), it is illegal to cross a
> solid white line under normal circumstances.
>
> An OSM way represents a separate street, not a lane. When you start
> representing lanes as ways, you break data consumers that count ways,
> or that really need to know whether the physical divider is. Emergency
> vehicles are not interested in solid white lines, but are interested
> in physical dividers that they cannot cross.
>
> For all those reasons, I will not map a separate way for a lane
> separated by a solid line. I do hope that the  but routing apps should
> start implementing change:lane, which is the proper way to map it
> IMHO.
>
> regards
>
> m
>
> (*) in some special case
>
> ___
> 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] Differences with USA admin_level tagging

[Jack Burke]

*begins reading*

*minutes later, eyes begin watering*

*starts reading from the beginning*

*gives up*

TL;DR

So...what exactly are you asking? 

-- 
Typos courtesy of fancy auto spell technology___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

[Talk-us] ref-Tagging forest service roads: NFR vs. FS vs. FSR?

[Jack Burke]

What is the preferred ref tag shorthand for forest service roads?  I found
one wiki page[1] that specifies NFR is to be used, which I don't think I've
ever heard before.  I can't find any supporting documentation, including
discussions, mailing list threads, votes, etc.  That info appears to have
been added last year.

I'm used to hearing them called FS ## (e.g., FS 13).  In the discussion
page for that wiki, there is one single post devoted to the subject, which
suggests FS, FR, and FSR as candidates.  The same post links to a Colorado
GIS group's Google Group thread on the subject, which includes feedback
from actual US Forest Service people, and NFR is nowhere to be found in
their comments.

My query is more than just an intellectual exercise; recently I've begun
seeking out various forest roads to investigate and improve the mapping of,
both for personal reasons and to get them right on the map.  As many
OSM-based routers and map utilities work offline, they are the ideal tool
to use if you want to go camping, fishing, or just exploring in the woods,
since many of these areas are without cell coverage (at least in north
Georgia).

Any thoughts, feedback, comments, or criticism would be appreciated.

--jack

[1] https://wiki.openstreetmap.org/wiki/United_States_roads_tagging
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] "toll" related tags appropriate for park entrances?

[Jack Burke]

Thanks for the feedback, Steve!  That's kinda what I was thinking, but
wanted another opinion.

--jack


On Tue, Mar 21, 2017 at 12:56 PM, OSM Volunteer stevea <
stevea...@softworkers.com> wrote:

> I tagged barrier=toll_booth on numerous "exit lanes" at the parking
> facility at San Diego International Airport.  I also used this tag at a
> state park near me which has exactly the same sort of entrance attendant
> you mention collecting what is really a "park usage fee for those who drive
> in" but it is called a "parking fee."
>
> It seems to perfectly capture the semantic we wish to express.
>
> SteveA
> California
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

[Talk-us] looking for advice on complex parking lot tagging for new baseball stadium

[Jack Burke]

The new SunTrust Park baseball stadium is about to open, with the first
game just before Easter.  In addition to on-grounds parking lots (the easy
ones), many businesses and offices around the area have a parking agreement
with the county and team to provide parking for games.  However, most of
these off-site parking lots have restricted hours for game attendees; the
rest of the time, they're reserved for people who work in those buildings.

Is there a suggested way to provide values for access, opening_hours and
other tags to reflect the various time windows that access is allowed for
the differing groups?

Or just don't even bother?

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

[Talk-us] "toll" related tags appropriate for park entrances?

[Jack Burke]

Are the various "toll" related tags appropriate for park entrances where
you have to stop and pay a fee?  For example, most state parks in Georgia
have a "parking fee" that you have to pay to an attendant when you enter
the park, so it seems appropriate to tag the collection point as
barrier=toll_booth, because you can't pass through if you don't pay.

I realize that "fee" (or parking_fee) is a more appropriate term to use,
but "barrier=fee_booth" (or fee anything) doesn't appear to have any usage
whatsoever according to taginfo, and I don't think inventing a new value is
necessary.

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

Re: [Talk-us] reporting Pokemon Go related vandalism

[Jack Burke]

No one has called for my head yet, so I guess everything is ok :-)

-jack

-- 
Typos courtesy of fancy auto spell technology

On March 15, 2017 2:31:16 AM EDT, OSM Volunteer stevea 
 wrote:
>My apologies to you, Jack, for putting your name in my Subject line.  A
>simple copy-paste error; I'll be more careful in the future.
>SteveA
>___
>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] reporting Pokemon Go related vandalism

[Jack Burke]

I just came across this OSM user diary which links to yet another article
on how to manipulate OSM for Pokemon:
https://www.openstreetmap.org/user/-karlos-/diary/40684

The bothersome part is the replies to the diary entry where people bring up
the new edits they've made for the game.  Since I'm nowhere near any of
them, I don't know if they're good or bad edits.

On the plus side, the linked article (
http://pokemongoinformer.com/create-your-own-nest-in-pokemon-go/) very
clearly and specifically says that OSM is used for a lot of things and for
people NOT to create items near their homes just for their own use, and to
only create things that exist in the real world.

--jack


On Mon, Jan 30, 2017 at 10:34 PM, Brian May  wrote:

> Been following the thread - my two cents on what I'm seeing around
> Florida.
>
> 1) Seems like a major increase in new mappers and edits in just the past
> two weeks, and before that an increase overall since the pokemon / osm
> connection was publicized.
> 2) Many /most of the influx of new mappers are adding footways, parks,
> meadows, and water.
> 3) A decent number of are completely fake - 15%?
> 4) Some are a mixture of real and fake.
> 5) Most are small edits, like adding a few features in one or two
> changesets, but some are very prolific adding hundreds of features in many
> changesets.
> 6) Many edits are not very spatially accurate, but some are really great.
> 7) A few mappers are breaking every rule in the book and making really bad
> edits.
> 8) Overall its a net gain, but its a lot of work to try and review these
> edits, make contact, do reverts if necessary, cleanup, etc.
>
> In some cases, I'm not sure what to do. For example, one mapper is really
> prolific, but just mostly wrong in they way they are mapping things.
>
> Another case, looks like a mapper mapped a large paved area next to a road
> as a park, and named it whatever he wanted (he has also named many paths
> and lakes what appear to be fantasy / fake names). I asked him if there was
> really a park there and the reply was there was street art displayed there,
> so its a park.
>
> Another mapper converted a section of a primary road running through South
> Beach Miami to a footpath and extended a park to cover it. The changeset
> comment was something like "making the park look more like it does in real
> life." Another mapper and I commented on his changeset, he didn't respond,
> I reverted and cleaned it up, and he appears to be doing more edits that
> are tied to reality.
>
> Another one said "a park is here" and put the park over relatively new
> single family houses.
>
> Overall, its really interesting to see such a large and focused group
> descending on (embracing?) OSM so quickly. So now I'm thinking how do we
> get large numbers of other sub-groups as interested in adding to the map as
> the pokemon people? Is this a one off random thing? Or is it possible to
> influence and steer large focused groups towards OSM? And at the same time
> provide enough guidance so these new groups are adding useful features to
> the map with a minimal amount of mistakes and fake features.
>
> Brian
>
>
> On 1/30/2017 7:09 PM, Will Senechal wrote:
>
> I do in fact know one of the areas that he edited quite well.  He added
> "Mission Koi Pond" at a location that contained a large building (shown on
> the Bing imagery) that I can confirm was still there yesterday.  It is the
> site of Mission Neurology, at 890 Hendersonville Rd #200, Asheville, NC
> 28803, see http://www.mission-health.org/the-nervous-system.php#locations.
> I would guess the edits are this person's home and work addresses, again to
> try to cheat at Pokemon Go.
>
> On Mon, Jan 30, 2017 at 2:16 PM, Andy Townsend  wrote:
>
>> On 27/01/2017 22:49, ajt1...@gmail.com wrote:
>>
>>> On 27/01/2017 06:20, Will Senechal wrote:
>>>
   I'll try to keep an eye on activity around here, and will try to
 continue updating my area.

>>>
>>> They've just "edited" again, and I've blocked in
>>> http://www.openstreetmap.org/user_blocks/1169 , so I'd be grateful if
>>> people could keep an eye out for other problematical edits in the area from
>>> other names too...
>>>
>>
>> The Data Working Group have just had a mail from the mapper saying that
>> although the _previous_ ones were fake, their _last_ edit
>> http://www.openstreetmap.org/changeset/45573753 was actually valid (and
>> said "If there needs to be photographs taken I will gladly"). I replied
>> suggesting that they might want to post here to explain what happened, and
>> accepted their offer of photgraphic evidence.  I have to say I'm still
>> somewhat sceptical - the features in http://www.openstreetmap.org/c
>> hangeset/45573753 were remarkably Pokemon-friendly, and the "cars parked
>> in something now mapped as a duck pond" made it seem even more unlikely.
>>
>> I'd be delighted to be wrong of course - it'd be great if this really was
>> someone 

[Talk-us] Samsung"s Find My Mobile

[Jack Burke]

Maybe I'm the last to know this, but Samsung"s Find My Mobile service lets you 
switch between HERE and OSM maps. (And yes, they do correctly note "(c) 
OpenStreetMap contributors".)

-jack 
-- 
Typos courtesy of fancy auto spell technology___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Blue Ridge Parkway

[Jack Burke]

I, for one, loved the points you made about sovereignty. 

-jack 
-- 
Typos courtesy of fancy auto spell technology

On January 30, 2017 11:23:25 PM EST, OSM Volunteer stevea 
 wrote:
>Apologies, Ian.  I did mention that my VERY brief digression into state
>sovereignty was recognizably "not on a political forum" and
>intentionally brought the topic back to "OSM and tagging standards."
>
>The intent was to clarify that states (New York, California...) do
>designate wilderness areas, and that we can tag similarly (to how
>nation-states do so) with "states" as we know them in the USA.  And I
>think I, Kenny and the list largely got there.
>
>SteveA
>California
>___
>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] Michigan speed limit changes coming soon

[Jack Burke]

Hey, Michigan folks, keep an eye out for some speed limit changes

http://www.mlive.com/news/index.ssf/2017/01/75-mph_speed_limits_officially.html

-- 
Typos courtesy of fancy auto spell technology___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] [OSM-talk] Beware Pokemon users

[Jack Burke]

They're using the same map they used in Ingress, a game they launched when 
still part of Google. That one is known to have come from Google. It makes 
sense that any map databases they had when the break happened would still be 
owned by the company; they just wouldn't have maps that included changes since 
then. 

A co-worker plays that game, and he and I compared Pokémon places in our area 
with the ones in that game, and they're identical. 

-jack 
-- 
Typos courtesy of fancy auto spell technology

On December 30, 2016 9:40:56 AM EST, Paul Johnson  wrote:
>On Tue, Dec 27, 2016 at 7:14 PM, Warin <61sundow...@gmail.com> wrote:
>
>> Targeting Pokemon contributors falls into a trap... the assumption
>that a
>> particular activity/group are all inclined to vandalism.
>
>
>Another trap, too:  Assuming that Niantic and/or Nintendo are using
>OpenStreetMap for this game.  And if they are, then they're doing so
>without attribution.  Without any attribution and with Niantic no
>longer
>part of Alphabet (Google's parent company), it's not clear where
>they're
>getting their map from.
>
>
>
>
>___
>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] HOV lane tagging

[Jack Burke]

I also thought that it would contradict the other tags.  But, the wiki page
http://wiki.openstreetmap.org/wiki/Tag:access%3Ddesignated seems to pretty
much say we're both wrong on that score:

"The value *designated* is not meant to imply that OpenStreetMap access
<http://wiki.openstreetmap.org/wiki/Key:access>=* permissions have been
automatically 'designated' *only* to that transport mode! If an element is
meant *only* to be used by specific designated transport methods
(overriding whatever defaults may exist for that way), use access
<http://wiki.openstreetmap.org/wiki/Key:access>=no
<http://wiki.openstreetmap.org/wiki/Tag:access%3Dno> in addition of the *
<http://wiki.openstreetmap.org/wiki/Key:*>=designated value."

I say "seems to," which is why I wanted to ask for clarification.  With
respect to the HOV lanes, it matters greatly, because there are certain
interstate exits that are HOV-only which a router shouldn't choose those to
get somewhere if you're not carrying multiple passengers in your car (which
is pretty much the default in the U.S.).

--jack


On Tue, Nov 15, 2016 at 6:13 PM, Elliott Plack <elliott.pl...@gmail.com>
wrote:

> Jack,
>
> Good question. I am curious about the answer as well, specifically
> regarding bicycle lanes, which can be added using this method.
>
> Setting a right side bike lane to ...yes|designated doesn't preclude other
> vehicles from accessing the right lane, as you said.
>
> I thought about adding |no for regular access, but wouldn't that general
> access contradict the other tags?
>
> The Mapbox data team has been doing lots of turn lane tagging around the
> US [1], so perhaps a member of the team there can provide insight on this.
>
> Elliott
>
> [1] = https://www.mapbox.com/blog/la-turn-lanes-map/
>
> On Tue, Nov 15, 2016 at 6:01 PM Jack Burke <burke...@gmail.com> wrote:
>
>> Something about some HOV access tags I've seen have been bothering me.
>>
>> Some of the interstates through Atlanta have designated HOV-only lanes.
>> In looking at the attributes on them, someone has added
>> hov:lanes=designated|yes|yes|yes|yes {etc.} to them.
>>
>> However, after reviewing the wiki for the "designated" tag, it doesn't
>> appear to _exclude_ other modes of transport--just using the
>> hov:lanes=designated tag on the leftmost lane still implies that non-HOV
>> transportation is allowed.  For example, motorcycles are allowed, but
>> single-passenger cars are not, but the current tagging doesn't appear to
>> prohibit single-passenger cars, if I'm reading the wiki right.
>>
>> Reading up on the access tag leads me to think that it would be better to
>> include access:lanes=no|yes|yes|yes|yes {etc.} to preclude non-HOV
>> traffic, as well as add motorcycle:lanes=yes|yes|yes|yes|yes {etc.}
>>
>>
>> For example, the section of northbound I-75/I-85 under this marker
>>
>> http://osm.org/go/ZQqq80Lkl-?layers=N=
>>
>>
>> currently has the tag
>>
>> hov:lanes=designated|yes|yes|yes|yes|yes|yes
>>
>> Am I correct in thinking that it would be right to add these tags, too:
>>
>> access:lanes=no|yes|yes|yes|yes|yes|yes
>> motorcycle:lanes=yes|yes|yes|yes|yes|yes|yes
>>
>> Thanks for any feedback!
>>
>> --jack
>>
>> ___
>> Talk-us mailing list
>> Talk-us@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-us
>>
> --
> Elliott Plack
> http://elliottplack.me
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

[Talk-us] HOV lane tagging

[Jack Burke]

Something about some HOV access tags I've seen have been bothering me.

Some of the interstates through Atlanta have designated HOV-only lanes.  In
looking at the attributes on them, someone has added
hov:lanes=designated|yes|yes|yes|yes {etc.} to them.

However, after reviewing the wiki for the "designated" tag, it doesn't
appear to _exclude_ other modes of transport--just using the
hov:lanes=designated tag on the leftmost lane still implies that non-HOV
transportation is allowed.  For example, motorcycles are allowed, but
single-passenger cars are not, but the current tagging doesn't appear to
prohibit single-passenger cars, if I'm reading the wiki right.

Reading up on the access tag leads me to think that it would be better to
include access:lanes=no|yes|yes|yes|yes {etc.} to preclude non-HOV traffic,
as well as add motorcycle:lanes=yes|yes|yes|yes|yes {etc.}


For example, the section of northbound I-75/I-85 under this marker

http://osm.org/go/ZQqq80Lkl-?layers=N=


currently has the tag

hov:lanes=designated|yes|yes|yes|yes|yes|yes

Am I correct in thinking that it would be right to add these tags, too:

access:lanes=no|yes|yes|yes|yes|yes|yes
motorcycle:lanes=yes|yes|yes|yes|yes|yes|yes

Thanks for any feedback!

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

Re: [Talk-us] Bar vs Pub vs Restaurant in the US?

[Jack Burke]

I think that was a discussion on one of the mailing lists. And, where you order 
was also what I understand the (very fine)  distinction to be. 

-jack 

-- 
Typos courtesy of fancy auto spell technology

On September 29, 2016 2:00:04 PM EDT, Greg Troxel  wrote:
>
>Harald Kliems  writes:
>
>> On Thu, Sep 29, 2016 at 12:17 PM Greg Troxel  wrote:
>>
>>>
>>> That's not what the OSM tag means; it's more european.  In OSM,
>"cafe"
>>> means (usually) that there is real food, but (always) that you order
>at
>>> a counter and then either take it yourself or have the staff bring
>it to
>>> you.  However, a coffee shop is very probably a cafe under this
>>> definition.  But so is a place that has real food cooked by a chef,
>>> except that you don't get waited on.
>
>> Where do you get the order-at-the-counter vs table service part from?
>I
>> don't see that in the wiki, and the picture on the amenity=cafe page
>shows
>> a waiter in an Austrian cafe, who most likely will take your order at
>the
>> table. https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dcafe
>Furthermore,
>> there is a separate tag for self service
>> https://wiki.openstreetmap.org/wiki/Key:self_service
>
>I really do not remember clearly where I read this; it would have been
>about 5 years ago.
>
>
>
>
>___
>Talk-us mailing list
>Talk-us@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/talk-us
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Freeway exit tagging

[Jack Burke]

Tagging maxspeed is purely for a router.  So are turn restrictions.

As for turn:lanes meant for complex intersectionsthe examples in the
wiki show very simple uses.  I can't see anything in it, or the discussion
page, indicating that it is only for complex intersections.  Certainly
there is a lot of talk about how to use it with some complex roads, but
overall it appears to be intended for exactly this type of situation
(namely, indicating lane guidance for exits).

--jack


On Fri, Sep 2, 2016 at 1:23 PM, Paul Johnson  wrote:

> On Fri, Sep 2, 2016 at 12:18 PM, David Mease  wrote:
>
>> I thing my reservations about this type of tagging is that this may be
>> "tagging for the router".
>>
>
> On some level, all of it is.
>
>
>> I still view the turn:lanes scheme as a (probably incomplete) way of
>> describing complex intersections. Tagging simple intersections with this
>> scheme just to get a routing engine to display the correct arrow icon is a
>> waste of time.
>>
>
> A sufficiently smart router could potentially use the info to determine
> whether or not it's plausible to make Y number of lane changes of X
> distance to make a turn and route accordingly.
>
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Freeway exit tagging

[Jack Burke]

Would love to compare notes on that, but it'll have to be later next week.

If you want to look at what I do for exits, feel free to examine pretty
much all of them on I 75 south of Atlanta, as well as through downtown.

--jack


On Mon, Aug 29, 2016 at 4:25 PM, Paul Johnson  wrote:

> I've given it a little minor tag-completion update if anybody wants to
> compare notes.
>
> On Mon, Aug 29, 2016 at 11:00 AM, Duane Gearhart  wrote:
>
>> FYI - the exit 78 interchange information has been updated. The Mapzen
>> directions are calling out the exit as you expected
>> http://www.openstreetmap.org/directions?engine=mapzen_car
>> ute=31.67026%2C-83.61169%3B31.66674%2C-83.61442#map=18/31.66803/-83.61124
>>
>>
>> On Fri, Aug 26, 2016 at 12:06 AM, David Mease  wrote:
>>
>>> My interpretation:
>>>
>>> What is the proper method to use turn:lanes to tag freeway lanes
> approaching an exit, where the exit branches directly from an edge lane
> without being part of the freeway itself, but the freeway lanes are not
> signed with an arrow, such as this one?
>  http://mapillary.com/map/im/7igAGXSa6EsUYlTIujXchw
>

>>> This exit has no turn lane. There is no staging lane prior to the exit
>>> where tags could be placed, one should not be created just so that there is
>>> a place to put tags. This freeway should not be split. You said yourself
>>> that the exit is not part of the freeway itself, so tags should not be
>>> placed on the freeway. This intersection is a candidate for the destination
>>> tag.
>>>
>>>
 mapping the road markings seems extremely strange - what if they are
 very faded, when do we map them ? is there a threshold of % of the paint
 left ?

>>> what is there are no road markings but there are signs ?

>>>
>>> Same difference. But the arrow in the above example is pointing to where
>>> the exit is, not describing a turn lane preceding the exit.
>>>
>>>
 do we remove those tags during the winter in some regions ?

>>>
>>> Do we remove the name tag from roads when the street signs get iced over
>>> or overgrown with vegetation?
>>>
>>> mapping of markings separately also seems to have no functional benefit.
 the information should be useful for navigation
>>>
>>>
>>> Road markings are both beneficial and useful for navigation. Cities and
>>> governments have paid a lot of money installing them all over globe
>>> precisely for these reasons. OSM would be well served to include them
>>> exactly as is. I don't hear a lot of people complaining about how those
>>> arrows on the roads led them astray.
>>>
>>> In the above example, I would not expect navigation software to direct
>>> me to get into the lane marked with a slight right arrow. In fact, I would
>>> be miffed when I found there was no such lane. All I would expect is a
>>> simple "In x distance take exit 78 towards Sycamore/Ocilla"
>>>
>>>
>>> ___
>>> 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] Freeway exit tagging

[Jack Burke]

> This exit has no turn lane. There is no staging lane prior to the exit
where tags could be placed, one should not be created just so that there is
a place to put tags.
> This freeway should not be split. You said yourself that the exit is not
part of the freeway itself, so tags should not be placed on the freeway.

That's not entirely true.  The exit ramp technically begins in the middle
of the far-right travel lane.  If you were to imagine the highway as a
train track instead, the exit ramp would have to physically connect to the
rail in the lane.  The same concept applies here, and although I've never
actually asked one, I'll bet a highway engineer would agree.


On Fri, Aug 26, 2016 at 12:06 AM, David Mease  wrote:

> My interpretation:
>
> What is the proper method to use turn:lanes to tag freeway lanes
>>> approaching an exit, where the exit branches directly from an edge lane
>>> without being part of the freeway itself, but the freeway lanes are not
>>> signed with an arrow, such as this one?
>>>  http://mapillary.com/map/im/7igAGXSa6EsUYlTIujXchw
>>>
>>
> This exit has no turn lane. There is no staging lane prior to the exit
> where tags could be placed, one should not be created just so that there is
> a place to put tags. This freeway should not be split. You said yourself
> that the exit is not part of the freeway itself, so tags should not be
> placed on the freeway. This intersection is a candidate for the destination
> tag.
>
>
>> mapping the road markings seems extremely strange - what if they are very
>> faded, when do we map them ? is there a threshold of % of the paint left ?
>>
> what is there are no road markings but there are signs ?
>>
>
> Same difference. But the arrow in the above example is pointing to where
> the exit is, not describing a turn lane preceding the exit.
>
>
>> do we remove those tags during the winter in some regions ?
>>
>
> Do we remove the name tag from roads when the street signs get iced over
> or overgrown with vegetation?
>
> mapping of markings separately also seems to have no functional benefit.
>> the information should be useful for navigation
>
>
> Road markings are both beneficial and useful for navigation. Cities and
> governments have paid a lot of money installing them all over globe
> precisely for these reasons. OSM would be well served to include them
> exactly as is. I don't hear a lot of people complaining about how those
> arrows on the roads led them astray.
>
> In the above example, I would not expect navigation software to direct me
> to get into the lane marked with a slight right arrow. In fact, I would be
> miffed when I found there was no such lane. All I would expect is a simple
> "In x distance take exit 78 towards Sycamore/Ocilla"
>
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Freeway exit tagging

[Jack Burke]

So it sounds like the general consensus is that I should probably be using
"through;right" at places like shown in my original pic, instead of
"none;right", based on the usage rather than the signage (presuming, of
course, my tagging doesn't conflict with a sign, which shouldn't happen
since everyone should be driving like the signs say in the first place).

On Fri, Aug 26, 2016 at 4:17 PM, Jesse B. Crawford <je...@jbcrawford.us>
wrote:

> Where I live (San Francisco, CA, USA), lane arrows are generally added
> for one of two reasons:
>
> 1) It isn't obvious what the authorized use of a lane is, when there is
> e.g. a right, slight right, and through option with various lanes for
> each - especially when there are multiple slight_rights as sometimes
> happens.
> 2) To provide advanced warning that a lane you're in will have limited
> options in the future (such as "HWY ONLY" written in lanes). The
> location of these warnings varies, they're sometimes just yards before
> the intersection and sometimes a block or two back - presumably
> depending on how easy a traffic engineer thinks it will be to change lanes.
>
> Lane arrows are only present in some cases though - and in my
> cross-country driving experience, I have found California to be
> unusually thorough about lane arrows, so they're probably present more
> of the time here than they are in much of the rest of the country. For
> example, lane arrows to indicate a merge_to_left are virtually never
> used in the state of Oregon (this may even be ODOT policy?), but are
> almost always present in California.
>
> This is just a difference between two neighboring states in a country
> with a reasonably precise traffic control manual. Lane arrow practices
> are presumably even more different between countries (e.g. in the parts
> of Mexico I visit, I don't think I've ever seen one).
>
> My point is this: the practice of marking lanes with arrows varies by
> jurisdiction and by how recently the intersection has been painted. In
> many cases, in the US at least, it depends on whether the intersection
> is straightforward to navigate for humans or not. It probably also
> depends on whether or not violations have been observed there - here, at
> least, they sometimes respond to too many accidents at an intersection
> by putting in physically larger stop signs. I suspect the same is done
> with land arrows.
>
> Do any of these factors in road markings change the actual ground truth
> of the intersection and its navigation?
>
> I think this is the point that Rihards was getting at, somewhat
> hyperbolically. Road markings like lane use arrows and signs are usually
> themselves representations of the intersection to come, much like a map.
> When we produce a map, we shouldn't be making a map of someone else's
> map of the intersection. We should be reflecting the way the
> intersection actually is. Which, yes, is sometimes designated only by
> restricting signs, but often it is not, and is instead restricted by
> standard rules about the usage of lanes (i.e. no right turns from a lane
> other than the right curb lane, UNLESS markings indicate otherwise).
> These rules, too, vary by jurisdiction, so if the map is going to be
> general for global use it should express them.
>
> --
> Jesse B. Crawford
>
> https://jbcrawford.us
> je...@jbcrawford.us
> GPG 0x4085BDC1
>
> On 08/25/2016 11:30 PM, Paul Johnson wrote:
> >
> >
> > On Thu, Aug 25, 2016 at 4:28 PM, Rihards <ric...@nakts.net
> > <mailto:ric...@nakts.net>> wrote:
> >
> > On 2016.08.26. 00 <tel:2016.08.26.%2000>:15, Jack Burke wrote:
> >
> > Freeway exit tagging
> >
> >
> > I am totally confused.
> >
> > What is the proper method to use turn:lanes to tag freeway lanes
> > approaching an exit, where the exit branches directly from an
> > edge lane
> > without being part of the freeway itself, but the freeway lanes
> > are not
> > signed with an arrow, such as this one?
> >  http://mapillary.com/map/im/7igAGXSa6EsUYlTIujXchw
> > <http://mapillary.com/map/im/7igAGXSa6EsUYlTIujXchw>
> >
> > Through examples[1], the wiki shows that when the freeway lanes
> > *are*
> > signed, then "through;slight_right" appears to be the correct
> value.
> > The wiki examples also appear to indicate that "through" is
> *only*
> > appropriate when there is corresponding signage.  The wiki is
> > also very
> >
> >
> > referencing the previous topic in talk-us about ho

[Talk-us] Freeway exit tagging

[Jack Burke]

Freeway exit tagging


I am totally confused.

What is the proper method to use turn:lanes to tag freeway lanes
approaching an exit, where the exit branches directly from an edge lane
without being part of the freeway itself, but the freeway lanes are not
signed with an arrow, such as this one?
http://mapillary.com/map/im/7igAGXSa6EsUYlTIujXchw

Through examples[1], the wiki shows that when the freeway lanes *are*
signed, then "through;slight_right" appears to be the correct value.  The
wiki examples also appear to indicate that "through" is *only* appropriate
when there is corresponding signage.  The wiki is also very clear what to
do when an edge lane is an exit-only lane ("slight_right"), and what to do
when a lane is signed for both through and right turn ("through;right").
So what's the right thing to use when there is no "through" indicator, yet
there is an upcoming branching exit?  By inference from what's contained in
the wiki, "none;slight_right" appears to be the appropriate value, but it
looks like a lot of people are disagreeing with that[2], even though it
appears to be the only logical conclusion.  Others think that
"through;slight_right" should be used because it's the reality on the
ground[2] despite the lack of paint/signs.

I'm bringing this up because I'm trying to get exits on I 75 in Georgia and
Florida tagged with destination and lane guidance (though only one
navigation app processes lane guidance AFAIK, but I hope that by adding the
data, others will take it up, too), and don't want to waste my time tagging
it incorrectly.  One helpful group trying to fix what they consider
incorrect lane counts & tags, turned a bunch of my continue-or-exit lanes
tagged with "none;slight_right" into exit-only lanes[3] with just
"slight_right".  I'm worried about switching to "through;slight_right"
because I don't want some *other* do-gooder coming along later and
similarly breaking lane guidance because there's no arrow on the ground or
on a sign.  Thus, I am now at a standstill because there doesn't appear to
be any correct tagging scheme for this incredibly common situation.

Note:  I am intentionally leaving the proposal for "transit:lanes" out of
this, both because it hasn't been voted on, as well as it doesn't appear to
cover this situation any better than turn:lanes does.

--jack



References:

[1] http://wiki.openstreetmap.org/wiki/Key:turn

[2] https://lists.openstreetmap.org/pipermail/tagging/2016-June/029335.html

[3]
https://lists.openstreetmap.org/pipermail/talk-us/2016-August/016643.html
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Check your turn:lanes

[Jack Burke]

Paul, your examples are pretty much exactly what I've been doing, with the
exception that for the last one I was using:

turn:lanes=none|none|none;slight_right

because of the aforementioned discussion of whether or not to use "through"
without signage.

--jack

On Thu, Aug 25, 2016 at 1:38 PM, Paul Johnson <ba...@ursamundi.org> wrote:

> On Thu, Aug 25, 2016 at 12:09 PM, Jack Burke <burke...@gmail.com> wrote:
>
>> So I take it that at least you and I are in agreement that the wiki is
>> deficient for branching exits like this one:
>> http://mapillary.com/map/im/7igAGXSa6EsUYlTIujXchw
>>
>
> Yes, that's correct.  Moving a couple frames closer to
> http://mapillary.com/map/im/MsMAW3HKVNYxEVCtkRneBg, here's how I would
> tag three segments based on what's visible there and no other context:
>
> Ahead of camera after diverging ramp:
>
> highway=motorway
> oneway=yes
> lanes=3
> ref=I 75
> hgv:lanes=no|yes|yes
>
> The ramp from the physical gore (next to the exit sign) to the tip of the
> theoretical (painted) gore (with the node for the intersection being even
> with the theoretical gore):
>
> highway=motorway_link
> oneway=yes
> placement=transition
> lanes=1
> destination=Sycamore;Ocilla
> destination:ref=GA 32  (also, damn, had to check the minimap on that, I
> almost said MO 32 based on the shape).
> junction:ref=78
>
> Behind the camera:
>
> highway=motorway
> oneway=yes
> lanes=3
> ref=I 75
> hgv:lanes=no|yes|yes
> turn:lanes=through|through|through;slight_right
>
> Your Osmand "invention" example is a perfect case-study of what I'm
>> working on.  I'm trying to get exits on I 75 in Georgia and Florida tagged
>> with destination and lane guidance so that Osmand can show proper guidance,
>> and hopefully other OSM-based navigation apps will add that feature, too.
>> As it stands, I use Osmand to test my tags.
>>
>
> I've been testing this, as well.  I'm fortunate enough to live in a city
> that has nearly every kind of interchange to play with (except for some of
> the newer CFI styles, but OKC and...for like, no reason, rural interchanges
> with basically no traffic on I 40 leading into the Ouachitas are getting
> those) and well enough aware of the tagging in play to have seen what works
> and what doesn't, now.
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Check your turn:lanes

[Jack Burke]

Fixing where the motorway_link branches out is also one of the things I'm
working on fixing with this project.

But as to why...so that a navigation app can provide proper lane guidance.
I selected this particular example because it's very simple, without other
details to clutter up the discussion.  But in large cities, such as Atlanta
where we have a lot of freeway exits just around a curve and you can't see
them in time, it can be incredibly important to know what lane you need to
be in well ahead of time--especially in periods of heavy traffic, were you
can't get into the correct lane at the last minute.

On Thu, Aug 25, 2016 at 1:42 PM, Toby Murray <toby.mur...@gmail.com> wrote:

> On Thu, Aug 25, 2016 at 12:09 PM, Jack Burke <burke...@gmail.com> wrote:
> > So I take it that at least you and I are in agreement that the wiki is
> > deficient for branching exits like this one:
> > http://mapillary.com/map/im/7igAGXSa6EsUYlTIujXchw
>
> Why does this example even need any special lane tagging? I would map
> this as lanes=3 on the motorway and then draw the motorway_link with a
> lanes=1 tag out to right in front of where that picture is. Right now
> the motorway_link doesn't branch off of the main way until WAY past
> where the white solid line starts and where you must commit to the
> exit.
>
> Toby
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Check your turn:lanes

[Jack Burke]

Thus my problem.  The wiki doesn't consider what to do when there's a
branching exit.  It's a complete hole in the tagging schema, even though
it's probably the most common type of freeway exit in the U.S.

So, since there is no "through" indication, I resorted to
"none;slight_right" even though the usage of "none" is technically
incorrect because there *is* a signed indication of a slight_right.  But
being incorrect that way seemed better than being incorrect by using
"through;slight_right".

On Thu, Aug 25, 2016 at 12:58 PM, David Mease <meas...@gmail.com> wrote:

>
> From the wiki:
>
> The *turn*=* key can be used to specify the *indicated* direction in
> which a way or a lane will lead. It is used on the way segment from the
> first indication via *road markings*, *signposts* or similar indications
> to the junction or completion of merge. If you instead want to specify
> legal turning restrictions please see the article about the restriction
> relation <http://wiki.openstreetmap.org/wiki/Restriction>.
>
> The turn:lanes schema is for identifying the painted/signed lane marking
> arrows, not for describing where you can legally go from that lane. That's
> what the turn restriction relation is for.
>
> Putting "through" on a lane means that there is a straight arrow painted
> on it. Putting "none" on a lane means that there is no marking.
>
> On Thu, Aug 25, 2016 at 9:04 AM, Jack Burke <burke...@gmail.com> wrote:
>
>> Even if the road isn't signed that way?  The use of "through" when there
>> is no explicit marking to that effect seems to be contraindicated by the
>> wiki.
>>
>> Don't get me wrong--I don't see why we _couldn't_ use it when that is the
>> obvious traffic direction, even with the lack of explicit signage.  But if
>> that's how we want to use "through" then shouldn't we update the wiki to be
>> more clear?
>>
>>
>>
>> On Thu, Aug 25, 2016 at 10:58 AM, Paul Johnson <ba...@ursamundi.org>
>> wrote:
>>
>>> On Wed, Aug 24, 2016 at 5:19 PM, Jack Burke <burke...@gmail.com> wrote:
>>>
>>>> An active OSM group (leaving names, etc. out while they check out what
>>>> I reported) is running a script or plug-in or challenge called "to-fix"
>>>> that is apparently supposed to help fix incorrect turn:lanes values (and
>>>> maybe other things, I haven't investigated deeply enough).
>>>>
>>>> The problem is, it's breaking the values instead.  I found a section of
>>>> road that I'd added turn:lanes to in order to provide lane guidance at an
>>>> exit.  My original value of "none|none|none|none|none;slight_right"
>>>> was replaced by "slight_right".
>>>>
>>>
>>> You may want to try through|through|through|through|through;slight_right
>>> as the value; I've noticed routers that actually use this data struggle
>>> with null or none values, which isn't *entirely* unreasonable, but the
>>> former does describe the allowed movements even if the DOT doesn't feel the
>>> need to explicitly paint it out.
>>>
>>
>>
>> ___
>> 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] Check your turn:lanes

[Jack Burke]

So I take it that at least you and I are in agreement that the wiki is
deficient for branching exits like this one:  http://mapillary.com/map/im/
7igAGXSa6EsUYlTIujXchw

Your Osmand "invention" example is a perfect case-study of what I'm working
on.  I'm trying to get exits on I 75 in Georgia and Florida tagged with
destination and lane guidance so that Osmand can show proper guidance, and
hopefully other OSM-based navigation apps will add that feature, too.  As
it stands, I use Osmand to test my tags.




On Thu, Aug 25, 2016 at 12:55 PM, Paul Johnson <ba...@ursamundi.org> wrote:

> On Thu, Aug 25, 2016 at 11:04 AM, Jack Burke <burke...@gmail.com> wrote:
>
>> Even if the road isn't signed that way?  The use of "through" when there
>> is no explicit marking to that effect seems to be contraindicated by the
>> wiki.
>>
>
> I'm considering the ground truth in this case to be how the lane can
> actually be legally used, since (at least in North America where the
> direction of travel is obviated by the yellow centerline) lane arrows are
> much less common than in some other parts in the world.  Otherwise most
> intersections with turn pockets would end up as none|none|none|none instead
> of left|through|through|right.  Low-angle intersections are especially
> tricky for routing engines; in absense of anything other than a lane count,
> for example, Osmand will "invent" a new lane for the departing ramp
> (indicating say, the right most of through|through|through) instead of the
> correct through|through;slight_right (with the slight_right highlighted).
>
>
>> Don't get me wrong--I don't see why we _couldn't_ use it when that is the
>> obvious traffic direction, even with the lack of explicit signage.  But if
>> that's how we want to use "through" then shouldn't we update the wiki to be
>> more clear?
>>
>
> I think the wiki should be updated, yes, since the wiki's not describing
> how it's been implemented in the real world right now.  Though, to be fair,
> the only consumer I know that's actually doing anything with this data
> right now is Osmand.
>
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Check your turn:lanes

[Jack Burke]

Even if the road isn't signed that way?  The use of "through" when there is
no explicit marking to that effect seems to be contraindicated by the wiki.

Don't get me wrong--I don't see why we _couldn't_ use it when that is the
obvious traffic direction, even with the lack of explicit signage.  But if
that's how we want to use "through" then shouldn't we update the wiki to be
more clear?



On Thu, Aug 25, 2016 at 10:58 AM, Paul Johnson <ba...@ursamundi.org> wrote:

> On Wed, Aug 24, 2016 at 5:19 PM, Jack Burke <burke...@gmail.com> wrote:
>
>> An active OSM group (leaving names, etc. out while they check out what I
>> reported) is running a script or plug-in or challenge called "to-fix" that
>> is apparently supposed to help fix incorrect turn:lanes values (and maybe
>> other things, I haven't investigated deeply enough).
>>
>> The problem is, it's breaking the values instead.  I found a section of
>> road that I'd added turn:lanes to in order to provide lane guidance at an
>> exit.  My original value of "none|none|none|none|none;slight_right" was
>> replaced by "slight_right".
>>
>
> You may want to try through|through|through|through|through;slight_right
> as the value; I've noticed routers that actually use this data struggle
> with null or none values, which isn't *entirely* unreasonable, but the
> former does describe the allowed movements even if the DOT doesn't feel the
> need to explicitly paint it out.
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Check your turn:lanes

[Jack Burke]

I have to disagree. If that's how to interpret  the tags, then the tagging 
definition is deficient. 

Under that interpretation, how do you tag a lane that both continues and 
branches off as an exit, but doesn't have signage that it continues? 


-- 
Typos courtesy of fancy auto spell technology

On August 25, 2016 1:22:58 AM EDT, David Mease <meas...@gmail.com> wrote:
>According to the wiki, "none" means that there are no indications on
>the lane. The value "none;slight_right" says that there are both no
>indications and a slight right indication on the lane, which is of
>course impossible. These "scripted" edits are therefore a correct
>interpretation of the original tagging. The problem here is that the
>original tagging was incorrect.
>
>> On Aug 24, 2016, at 7:24 PM, Jack Burke <burke...@gmail.com> wrote:
>> 
>> And I, too, have a preference for using "none" instead of leaving and
>endless line of "|" to try to parse.  My eyesight isn't getting
>better as I get older.
>> 
>> Having said that, if that had been the only thing they did, I
>wouldn't have bothered saying anything.  But when their edits turned
>continuing lanes into exit-only lanes...well, then it became a
>*problem*.
>> 
>>> On Wed, Aug 24, 2016 at 8:20 PM, Tod Fitch <t...@fitchdesign.com>
>wrote:
>>> I’m of half a mind to use a script to find the edits in my area
>where they changed something like “left|none|none|” to “left||” and
>then revert them manually.
>>> 
>>> I know they are both officially acceptable variations but for those
>of us editing by hand counting the occurrences of “|none” to make sure
>the lane count is correct and matches what is on the ground is harder
>than counting the “|” occurrences. At least it is for me and I’ve had
>decades of practice counting open and close parens to make sure
>compilers wouldn’t squawk at me because they weren’t balanced.
>>> 
>>> And while I haven’t seen a “none;slight_right”, it looks syntacticly
>correct and I can imagine cases where it might be used and would defer
>to the local mapper who used it. (The ones in my area are much more
>likely to be “through;slight_right”.)
>>> 
>>> 
>>> 
>>>> On Aug 24, 2016, at 4:52 PM, Jack Burke <burke...@gmail.com> wrote:
>>>> 
>>>> No, it's https://github.com/mapbox/mapping/issues/193
>>>> 
>>>> And they appear to be telling me that the combination
>"none;slight_right" isn't valid.
>>>> 
>>>> Also, in their reply to me, they do specifically mention that they
>know none is valid, yet they're replacing it anyway.  And the worst
>part of it is that while they're using a script to *find* what they
>think is invalid, they're *manually* making the changes.
>>>> 
>>>> --jack
>>>> 
>>>>> On Wed, Aug 24, 2016 at 7:31 PM, Hans De Kryger
><hans.dekryge...@gmail.com> wrote:
>>>>> The link Jack's talking about,
>>>>> 
>>>>> https://github.com/mapbox/mapping/issues/180
>>>>> 
>>>>> Regards,
>>>>> Hans
>>>>> 
>>>>> 
>>>>>> On Aug 24, 2016 4:09 PM, "Toby Murray" <toby.mur...@gmail.com>
>wrote:
>>>>>> Mind sharing the link to the GitHub issue?
>>>>>> 
>>>>>> Do they think that "none" is an invalid option and are replacing
>it
>>>>>> with a blank globally? If so, this should be shut down
>immediately.
>>>>>> "none" and blank are both valid values and while I wouldn't mind
>>>>>> seeing it be consistent, any such edit would need to be discussed
>>>>>> before it is done.
>>>>>> 
>>>>>> Toby
>>>>>> 
>>>>>> On Wed, Aug 24, 2016 at 5:19 PM, Jack Burke <burke...@gmail.com>
>wrote:
>>>>>> > An active OSM group (leaving names, etc. out while they check
>out what I
>>>>>> > reported) is running a script or plug-in or challenge called
>"to-fix" that
>>>>>> > is apparently supposed to help fix incorrect turn:lanes values
>(and maybe
>>>>>> > other things, I haven't investigated deeply enough).
>>>>>> >
>>>>>> > The problem is, it's breaking the values instead.  I found a
>section of road
>>>>>> > that I'd added turn:lanes t

Re: [Talk-us] friendly notice: Atlanta road construction rendering imagery out-of-date

[Jack Burke]

I never thought of that.  When they get around to rerouting Windy Hill over
the Interstate, I might have to try that.

On Wed, Aug 24, 2016 at 9:29 PM, Mike N <nice...@att.net> wrote:

> On 8/24/2016 9:14 PM, Jack Burke wrote:
>
>> Since I'm on e-mail tonight, I thought I'd bring folks up-to-date on
>> some ongoing road construction north and south of Atlanta that is
>> rendering some pretty important imagery out-of-date.  So before you go
>> about trying to "fix" something that doesn't match the spy photos,
>> please check around to be sure that what you're trying to change isn't
>> already right.
>>
>
>   Thanks for the information!  On local projects here, I always add an
> empty way matching the old image with a note stating that aerials before
>  are out of date.
>
>   I suppose that will be the next frontier in cleanup projects after
> imagery receives the next major update.   On the plus side, since the new
> projects are often 1 or 2 GPS traces, removing them will remind me to
> compare with new aerials.
>
>
> ___
> 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] friendly notice: Atlanta road construction rendering imagery out-of-date

[Jack Burke]

Since I'm on e-mail tonight, I thought I'd bring folks up-to-date on some
ongoing road construction north and south of Atlanta that is rendering some
pretty important imagery out-of-date.  So before you go about trying to
"fix" something that doesn't match the spy photos, please check around to
be sure that what you're trying to change isn't already right.

First up, we have the new I-75 South Metro Express Lanes.  Due to open in
early 2017, these are reversible toll lanes being installed in the median
between the northbound and southbound Interstate roadways.  Because these
are fairly simple lanes, I've recently started drawing in the construction
so that we can quickly convert it to a usable roadway once it opens (and
I'll try to do GPS traces as soon after that as I can).  I've been using
numerous Mapillary sequences that have been made as a helper.

http://www.dot.ga.gov/DS/GEL/I75ExpressLanes


Next, we have the Northwest Corridor project.  Because it's more
technically complex (huge portions are having to be built as elevated
roadway), this reversible toll road won't open until 2018, and it's also
harder to draw in, but I'm working on it bit by bit (more by taking really
good looks at sections as I drive by than using Mapillary, but that also
helps).  This one extends up I-75 all the way from the Perimeter, up both
I-75 and I-575 a considerable distance.

http://www.dot.ga.gov/DS/GEL/NWC


Finally, we have the *5* projects all happening to poor Windy Hill Road at
the same time, mostly because of the new Atlanta Braves baseball stadium
nearby (which ended up costing the county commission chairman his
reelection bid, by the way).

The part of Windy Hill Road heading east from I-75 to Powers Ferry Road is
pretty much done, and I have corrected the lane counts and alignment.

The Windy Hill Road bridge and interchange is being rebuilt as a diverging
diamond, which has also affected a few other nearby roads, some of which
have been rerouted (done in OSM), and others of which are closed for
rerouting (also done in OSM).

The section of Windy Hill Road west from I-75 to US 41 is having the center
turn lane replaced with a raised median.  That project started this week,
and I've also already (mostly) divided the road in OSM,  (Even though the
entire section hasn't had the center turn lane dug up yet, I've gone ahead
and divided it in OSM because the destruction part will be done fairly
quickly.)

http://cobbcounty.org/index.php?option=com_content=article=2758:windy-hill-road-projects=130=596


If anyone has any questions, comments, or complaints, feel free to ask me.

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

Re: [Talk-us] Check your turn:lanes

[Jack Burke]

And I, too, have a preference for using "none" instead of leaving and
endless line of "|" to try to parse.  My eyesight isn't getting
better as I get older.

Having said that, if that had been the only thing they did, I wouldn't have
bothered saying anything.  But when their edits turned continuing lanes
into exit-only lanes...well, then it became a *problem*.

On Wed, Aug 24, 2016 at 8:20 PM, Tod Fitch <t...@fitchdesign.com> wrote:

> I’m of half a mind to use a script to find the edits in my area where they
> changed something like “left|none|none|” to “left||” and then revert them
> manually.
>
> I know they are both officially acceptable variations but for those of us
> editing by hand counting the occurrences of “|none” to make sure the lane
> count is correct and matches what is on the ground is harder than counting
> the “|” occurrences. At least it is for me and I’ve had decades of practice
> counting open and close parens to make sure compilers wouldn’t squawk at me
> because they weren’t balanced.
>
> And while I haven’t seen a “none;slight_right”, it looks syntacticly
> correct and I can imagine cases where it might be used and would defer to
> the local mapper who used it. (The ones in my area are much more likely to
> be “through;slight_right”.)
>
>
>
> On Aug 24, 2016, at 4:52 PM, Jack Burke <burke...@gmail.com> wrote:
>
> No, it's https://github.com/mapbox/mapping/issues/193
>
> And they appear to be telling me that the combination "none;slight_right"
> isn't valid.
>
> Also, in their reply to me, they do specifically mention that they know
> none is valid, yet they're replacing it anyway.  And the worst part of it
> is that while they're using a script to *find* what they think is invalid,
> they're *manually* making the changes.
>
> --jack
>
> On Wed, Aug 24, 2016 at 7:31 PM, Hans De Kryger <hans.dekryge...@gmail.com
> > wrote:
>
>> The link Jack's talking about,
>>
>> https://github.com/mapbox/mapping/issues/180
>>
>> Regards,
>> Hans
>>
>> On Aug 24, 2016 4:09 PM, "Toby Murray" <toby.mur...@gmail.com> wrote:
>>
>>> Mind sharing the link to the GitHub issue?
>>>
>>> Do they think that "none" is an invalid option and are replacing it
>>> with a blank globally? If so, this should be shut down immediately.
>>> "none" and blank are both valid values and while I wouldn't mind
>>> seeing it be consistent, any such edit would need to be discussed
>>> before it is done.
>>>
>>> Toby
>>>
>>> On Wed, Aug 24, 2016 at 5:19 PM, Jack Burke <burke...@gmail.com> wrote:
>>> > An active OSM group (leaving names, etc. out while they check out what
>>> I
>>> > reported) is running a script or plug-in or challenge called "to-fix"
>>> that
>>> > is apparently supposed to help fix incorrect turn:lanes values (and
>>> maybe
>>> > other things, I haven't investigated deeply enough).
>>> >
>>> > The problem is, it's breaking the values instead.  I found a section
>>> of road
>>> > that I'd added turn:lanes to in order to provide lane guidance at an
>>> exit.
>>> > My original value of "none|none|none|none|none;slight_right" was
>>> replaced by
>>> > "slight_right".
>>> >
>>> > While, per the wiki, there's nothing particularly wrong with a null
>>> value
>>> > for a field vs. specifying "none" as the value, it *does* make a
>>> difference
>>> > when there are two values in the field, as in my example above.  They
>>> turned
>>> > a continue-on-or-exit lane into an exit-only lane.
>>> >
>>> > So if you find broken lane guidance like that, with empty fields where
>>> > "none" would also be appropriate, that's probably what happened.
>>> Check the
>>> > history on the way and see if you can backtrack what happened
>>> (fortunately,
>>> > the group involved here included a url to a github issue where they are
>>> > tracking what they're doing).
>>> >
>>> > Now I have 200 miles of Interstate to go back through and re-check.
>>> >
>>> > --jack
>>> >
>>> >
>>> > ___
>>> > 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
>
>
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Check your turn:lanes

[Jack Burke]

No, it's https://github.com/mapbox/mapping/issues/193

And they appear to be telling me that the combination "none;slight_right"
isn't valid.

Also, in their reply to me, they do specifically mention that they know
none is valid, yet they're replacing it anyway.  And the worst part of it
is that while they're using a script to *find* what they think is invalid,
they're *manually* making the changes.

--jack

On Wed, Aug 24, 2016 at 7:31 PM, Hans De Kryger <hans.dekryge...@gmail.com>
wrote:

> The link Jack's talking about,
>
> https://github.com/mapbox/mapping/issues/180
>
> Regards,
> Hans
>
> On Aug 24, 2016 4:09 PM, "Toby Murray" <toby.mur...@gmail.com> wrote:
>
>> Mind sharing the link to the GitHub issue?
>>
>> Do they think that "none" is an invalid option and are replacing it
>> with a blank globally? If so, this should be shut down immediately.
>> "none" and blank are both valid values and while I wouldn't mind
>> seeing it be consistent, any such edit would need to be discussed
>> before it is done.
>>
>> Toby
>>
>> On Wed, Aug 24, 2016 at 5:19 PM, Jack Burke <burke...@gmail.com> wrote:
>> > An active OSM group (leaving names, etc. out while they check out what I
>> > reported) is running a script or plug-in or challenge called "to-fix"
>> that
>> > is apparently supposed to help fix incorrect turn:lanes values (and
>> maybe
>> > other things, I haven't investigated deeply enough).
>> >
>> > The problem is, it's breaking the values instead.  I found a section of
>> road
>> > that I'd added turn:lanes to in order to provide lane guidance at an
>> exit.
>> > My original value of "none|none|none|none|none;slight_right" was
>> replaced by
>> > "slight_right".
>> >
>> > While, per the wiki, there's nothing particularly wrong with a null
>> value
>> > for a field vs. specifying "none" as the value, it *does* make a
>> difference
>> > when there are two values in the field, as in my example above.  They
>> turned
>> > a continue-on-or-exit lane into an exit-only lane.
>> >
>> > So if you find broken lane guidance like that, with empty fields where
>> > "none" would also be appropriate, that's probably what happened.  Check
>> the
>> > history on the way and see if you can backtrack what happened
>> (fortunately,
>> > the group involved here included a url to a github issue where they are
>> > tracking what they're doing).
>> >
>> > Now I have 200 miles of Interstate to go back through and re-check.
>> >
>> > --jack
>> >
>> >
>> > ___
>> > 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

[Talk-us] Check your turn:lanes

[Jack Burke]

An active OSM group (leaving names, etc. out while they check out what I
reported) is running a script or plug-in or challenge called "to-fix" that
is apparently supposed to help fix incorrect turn:lanes values (and maybe
other things, I haven't investigated deeply enough).

The problem is, it's breaking the values instead.  I found a section of
road that I'd added turn:lanes to in order to provide lane guidance at an
exit.  My original value of "none|none|none|none|none;slight_right" was
replaced by "slight_right".

While, per the wiki, there's nothing particularly wrong with a null value
for a field vs. specifying "none" as the value, it *does* make a difference
when there are two values in the field, as in my example above.  They
turned a continue-on-or-exit lane into an exit-only lane.

So if you find broken lane guidance like that, with empty fields where
"none" would also be appropriate, that's probably what happened.  Check the
history on the way and see if you can backtrack what happened (fortunately,
the group involved here included a url to a github issue where they are
tracking what they're doing).

Now I have 200 miles of Interstate to go back through and re-check.

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

Re: [Talk-us] Mappers in Idaho!

[Jack Burke]

The errors in OSM must be worse than we thought if Martijn can't tell which 
state he's in! 

-jack

-- 
Typos courtesy of fancy auto spell technology

On August 8, 2016 1:19:32 PM EDT, "Shawn K. Quinn"  wrote:
>On Mon, 2016-08-08 at 11:15 -0600, Martijn van Exel wrote:
>> Ahem. Teton County is in Wyoming not Idaho. This is emberrassing!
>
>Actually, there is a Teton County, Idaho:
>
>http://tetoncountyidaho.gov/
>
>
>
>-- 
>Shawn K. Quinn 
>
>
>___
>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] Map spam

[Jack Burke]

Is anyone else starting to see map spam popping up in their areas?

Over the past few months, I've seen 3 OSM entries that I'm calling map spam
for lack of a better term.  I know that doesn't seem like a lot, but it
could be a new trend.

Specifically, what I'm finding is a well-formed node for a small business,
complete with phone number and (on 2 of them) websites.  The problem is
that the node is miles away from the address in question.  I didn't
investigate or document the first couple of them too well, but the most
recent one that I found today was by a user who has exactly 1 edit (the
spam one), and the user account's comment is the URL for the business,
too.  The *name* of the user doesn't match the county's property owner
records.

Because the entry was so well-formed, I'm going to assume that the person
is familiar with OSM and the account was created specifically to make this
one entry.  Also, because it was a single node in an otherwise
mostly-complete area, I'm going to assume that the person made a reasonable
guess that the node wouldn't be noticed.  I'm also going to guess that the
person in question runs some sort of "get your business listed on 100's of
websites!" thing and this is one way he gets that done (by adding it to
OSM, it also gets added to Where2GetIt and all of the other sites that use
OSM data).

I deleted the node.

My reasons for the deletion are:
1) The address is in a residential neighborhood.  I am going to _assume_
that were I to drive by it (which I might be able to do next weekend), I
will not see any signage for the business at the address.
2) The business website does not have that address (or ANY address)
anywhere on it.
3) The node was well out-of-location for the contained address.
4) The user account appears to be nothing more than a spam account, since
it has only the one edit and the URL of the business.

The node in question is:

https://www.openstreetmap.org/node/3787125448/history


So I pose this to the assembled horde:

Has anyone else noticed random spammy nodes in their area?  Does anyone
disagree with my reasoning or actions?  And if not, is there a standard
process for reporting suspected spam user accounts?

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

Re: [Talk-us] shop=chemist as "Drugstore" for Walgreens, CVS, Rite Aid, etc.

[Jack Burke]

Interesting. I've been tagging most large pharmacies as shop=convenience and 
amenity=pharmacy since I tend to think of them as convenience stores as much as 
pharmacies. 

-jack

-- 
Typos courtesy of fancy auto spell technology

On July 5, 2016 1:08:26 PM EDT, Peter Dobratz  wrote:
>After arriving at a local drugstore chain with a prescription in hand,
>walking past the shampoo aisle, only to find that the pharmacy counter
>is
>closed for the day, I've been updating tagging of drugstores and
>pharmacies
>as described here.
>
>For example, there is a Walgreens:
>
>http://www.openstreetmap.org/way/266495943
>
>The building outline has shop=chemist.
>
>Inside the building, there are 2 Nodes, one for the pharmacy and one
>for a
>clinic:
>
>amenity=pharmacy
>dispensing=yes
>drive_through=yes
>http://www.openstreetmap.org/node/4064469934
>
>amenity=doctors
>http://www.openstreetmap.org/node/4064469933
>
>In this case, all of these entities have different opening hours. 
>Other
>contact info like phone and website may be different as well.
>
>
>For the older style independent pharmacy, I do still use
>amenity=pharmacy
>on the building outline:
>
>http://www.openstreetmap.org/way/218176300
>
>They do sell a few items like bandages without a prescription, but they
>don't have the extensive personal hygiene section of typical of the
>drugstore chains.  The pharmacist is also on duty for the entire time
>this
>shop is open, so it doesn't feel like there are two separate entities
>operating in the space.
>
>Peter
>
>
>On Tue, Jul 5, 2016 at 8:45 AM, Minh Nguyen
>
>wrote:
>
>> Recently, iD was changed so that shop=chemist is labeled as
>"Drugstore"
>> for American English users (and continues to be labeled "Chemist" for
>> British English users). [1] An American mapping a Walgreens, CVS, or
>Rite
>> Aid who searches for "drugs" will see the following choices, in
>order:
>>
>> * Drugstore (shop=chemist, marked with a shopping cart icon)
>> * Pharmacy (amenity=pharmacy, marked with a pill bottle)
>>
>> Meanwhile, searching for "pharmacy" -- a synonym of "drugstore" in
>> American English -- produces only the amenity=pharmacy preset.
>>
>> The rationale is that amenity=pharmacy should be used only for
>pharmacy
>> counters (which can be found at both drugstores and inside
>supermarkets),
>> while shop=chemist should be used for full-service drugstores that
>*may*
>> contain pharmacy counters. Currently, this is at odds with the wiki
>and
>> longstanding practice, which stipulates that a shop=chemist *may not*
>fill
>> prescriptions.
>>
>> This change to iD came about due to a discussion in the Name
>Suggestion
>> Index project, which is the component in iD that suggests tags when
>you
>> fill in a commonly used name. [2] I happened to notice the change
>because
>> it caused Transifex to prompt me to update iD's Vietnamese
>localization. To
>> my knowledge, there has been no discussion on the mailing lists or
>formal
>> proposal on the wiki, though the iD maintainer intends to edit the
>wiki to
>> match iD's interpretation. iD is the only software that has made this
>> change.
>>
>> On the one hand, I've come around to liking the proposal, because it
>makes
>> it easier for data consumers to distinguish between pharmacy counters
>and
>> full-fledged drugstores. On the other hand, I think it's problematic
>> because an American mapping a Walgreens or CVS could potentially tag
>a
>> "drugstore" and be unaware that they'd need to separately map the
>pharmacy
>> counter in order to indicate that prescriptions may be filled
>on-site.
>>
>> Currently, amenity=pharmacy is far and away more common than
>shop=chemist
>> in the U.S. as a way to tag drugstores. Certainly anyone retagging
>> amenity=pharmacy to shop=chemist would be careful to add an
>additional
>> amenity=pharmacy POI where the pharmacy counter would be. (For a
>typical
>> Walgreens or CVS, it'd be next to the drive-through canopy.) However,
>I
>> have little faith that the average iD user would know to do the same,
>since
>> the word "drugstore", like "pharmacy", implies the sale of
>prescription
>> drugs.
>>
>> I've hashed out many of these points in [3], but I think the
>discussion
>> needs to involve the wider OSM community now. There's little chance
>of data
>> consumers and other editors updating their logic if the change is
>only
>> discussed in the iD project.
>>
>> [1] https://github.com/openstreetmap/iD/issues/3201
>> [2] https://github.com/osmlab/name-suggestion-index/issues/30
>> [3] https://github.com/openstreetmap/iD/issues/3213
>>
>> --
>> m...@nguyen.cincinnati.oh.us
>>
>>
>> ___
>> Talk-us mailing list
>> Talk-us@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-us
>>
>
>
>
>
>___
>Talk-us mailing list

Re: [Talk-us] User bumping all grade-separated intersections to motorway

[Jack Burke]

I don't see anything immediately wrong with the only segments your Overpass 
query turns up in Georgia (Savannah).

-jack

-- 
Typos courtesy of fancy auto spell technology

On June 13, 2016 8:17:59 PM EDT, Toby Murray  wrote:
>I just discovered some misguided edits and the user in question seems
>to have made many of them over a wide area so I thought I would put
>people on notice to be aware of this.
>
>While on the Biking Across Kansas tour last week I saw some odd
>looking segments in OsmAnd along US 36 in Kansas. I got home this
>weekend and saw the same thing locally.
>
>Upon investigation it looks like user "SD Mapman" has gone around
>upgrading grade-separated intersections to highway=motorway,
>regardless of any other criteria. So US 36 in Kansas had a random
>section of highway=motorway for less than a mile even though the rest
>of it is highway=primary and it is a two-lane highway with nothing
>between the lanes but a dashed yellow line and sometimes a center
>rumble strip.
>
>He also did not use the oneway=no tag so it has ruined routing of
>single carriageway highways in one direction because routers assume
>motorways are one-way by default.
>
>I made a comment on one of the changesets. I have not received a
>response yet however he is now going back and downgrading them from
>motorway to trunk. I still think this is not correct and will probably
>go back and reclassify them to what they were before his edits, at
>least in Kansas.
>
>According to a quick overpass query, he is the last editor of
>highway=motorway ways in 22 states so these will probably need to be
>reviewed.
>
>Here is a link to the Overpass query (warning: a couple MB of JSON to
>render)
>http://overpass-turbo.eu/s/gMq
>
>Toby
>
>___
>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] 'Honorary' street name conflicts with posted name - how to decide

[Jack Burke]

I concur. You could also put Harvey as an alt_name tag. 
 
-- 
Typos courtesy of fancy auto spell technology

On May 23, 2016 1:03:15 PM EDT, Martijn van Exel  wrote:
>Salt Lake City just renamed a part of 900 South to ‘Harvey Milk
>Boulevard’. This is a so-called ‘honorary designation’. But now I see a
>conflict. 
>
>1) The common tagging practice is that posted names rule. The signs
>changed to show the new honorary name:
>https://goo.gl/photos/xqAxQCwCmPRUGWkm9
> . So that would suggest I
>change the name to ‘Harvey Milk Boulevard’ and demote ‘900 South’ to
>name_1 or loc_name.
>2) Addressing and geocoding. People will continue to refer to this
>street as 900 South. Official addresses will not change. That would
>suggest that I leave the name=900 South in place and add name_1=Harvey
>Milk Boulevard. 
>
>I went with option 2, here is a segment —>
>https://www.openstreetmap.org/way/418190301
>
>
>Opinions?
>
>Martijn
>
>
>
>___
>Talk-us mailing list
>Talk-us@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/talk-us
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Odd road / odd structure

[Jack Burke]

For Paisley Place, maybe: 

abandoned:highway = residential 
access = no
name = Paisley Place
note = Your description of what the GIS people say. 

Since it needs to exist for addresses, it needs to be there. 


For the reservoir: 

landuse = reservoir 
intermittent = yes

-- 
Typos courtesy of fancy auto spell technology

On May 23, 2016 12:41:17 PM EDT, Steve Friedl  wrote:
>Hi all,
>
> 
>
>I have two things that I just don't quite know how to map.  Sorry that
>I
>have to provide Google Maps views to demonstrate.
>
> 
>
>1)  How does one represent a named street which is really a
>greenbelt:
>never been drivable, was assigned a name just to allow attaching a
>street
>name to the houses on either side.
>
> 
>
>Example: In Irvine California there's a residential area shown here:
>
> 
>
>https://www.google.com/maps/@33.7298257,-117.7572128,19z
>
> 
>
>I'm referring to Paisley Place, which is shown as a named alley
>connecting
>Garden Gate Lane and Winslow Lane.
>
> 
>
>After surveying the area and seeing that the City of Irvine GIS showed
>Paisley as that greenbelt, I reported it as an error (as I've done
>dozens of
>times for other things), but the very helpful GIS manager reported that
>this
>is correct (but certainly odd), and the two street-like things on
>either
>side of it are just unnamed alleys.
>
> 
>
>How do I represent this in OSM?  It's not a street that doesn't allow
>access, it's not really even a street!
>
> 
>
>2)  How do I represent a parking-lot-sized area that's intended to
>collect rainwater that fills a cistern?
>
> 
>
>In the Santa Ana Mountains in Southern California, the satellite views
>show
>something that looks exactly like a helipad:
>
> 
>
>https://www.google.com/maps/@33.7875181,-117.5805174,419m/data=!3m1!1e3
>
> 
>
>But it's not. That whole huge surface - paved in asphalt - is tilted
>slightly so that rainwater water will collect and fill the two cisterns
>to
>the left (zooming in you can barely see the pipe from the big pad to
>the
>cisterns.
>
> 
>
>I cannot find anything that's even close to describing what this is,
>but
>it's so prominent on the maps (and interesting to visit) that I seems
>like
>it should be there even if to make note that it's not a helipad.
>
> 
>
>Thanks,
>
> 
>
>Steve - who hopes the links above work.
>
>--- 
>
>Stephen J Friedl  | Security Consultant | UNIX Wizard | 714 345-4571
>
>  st...@unixwiz.net | Southern California |
>Windows Guy |  unixwiz.net
>
> 
>
>
>
>
>
>___
>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] Old Aerodromes

[Jack Burke]

Many of them may be valid, and could be nothing more than a farmer's private 
grass landing strip for his cropduster. The FAA does have a regulation 
requiring anyone establishing or closing an airfield (a private farm strip 
qualifies) to notify the government, but they don't really police it. States 
have e varying levels of regulation. 

-jack


On April 11, 2016 10:50:58 PM EDT, Martijn van Exel  wrote:
>Hi, 
>
>I was mapping some rural area in the U.S. and noticed, not for the
>first time, an aerodrome node in the middle of a field where there is
>obviously no airport or airfield. 
>
>So I decided to collect all aerodrome nodes in the U.S that have not
>been edited since 2013 and make a MapRoulette challenge out of them to
>get these either removed or improved. I posted one state (see link
>below) but I would really like some feedback - is the instruction clear
>enough, is this good as a MapRoulette challenge… 
>
>I have a few thousand (!!) more to post if it turns out this is good as
>a MapRoulette challenge!
>
>http://maproulette.org/#t=old-aerodromes-nebraska/old-aerodromes-nebraska-node-368386655
>
>
>Thanks for looking,
>
>Martijn
>
>
>
>___
>Talk-us mailing list
>Talk-us@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/talk-us

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

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

[Jack Burke]

Is it just me, or does social_path sound like the way to a "social disease"?

-jack


On March 25, 2016 6:36:56 PM EDT, Greg Troxel  wrote:
>
>There seems to be some wiki-agitation going on about a "proposed tag"
>of
>social path.  Perhaps everyone who is opposed might want to look and
>register opposition, unless they are more opposed to wikifiddling than
>to this tag :-)
>
>https://wiki.openstreetmap.org/wiki/Proposed_features/Social_path
>
>
>
>
>___
>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] State relationpages

[Jack Burke]

I didn't even know they existed. What is their purpose? What is needed to 
maintain them? 

On March 24, 2016 9:51:56 AM EDT, Martijn van Exel  wrote:
>Hi, 
>
>I haven’t paid any attention to these in a pretty long while. If they
>are still useful I can try and find some time to look into the issue.
>Anyone else still using the relation pages? Anyone wanting to help out
>with maintaining them?
>
>Martijn
>
>> On Mar 24, 2016, at 4:09 AM, Paul Johnson 
>wrote:
>> 
>> I've noticed that
>http://184.73.220.107/relationpages/oklahoma%20state%20routes.html
>
>has not updated in an extremely long time now.  What's going on with
>these?
>> ___
>> 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

-- 
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] County Road Tiles

[Jack Burke]

"Open to the public" is not the same thing as free from copyright 
restrictions

-jack


On February 11, 2016 1:46:53 PM EST, Clifford Snow  
wrote:
>Sixty percent of Washington State counties have open data portals with
>GIS
>data. Washington State laws (Open Records Act) requires that this data
>be
>open to the public. Road data from most of the counties seem to be much
>more current than TIGER data.  I've been creating background tiles for
>nearby counties but I would like to find a way to share the information
>with others. Since tiles use a lot of disk space, I've been looking for
>solution other than using my laptop. One promising solution is Mapbox
>Studio's vector tile service. Unfortunately the ability to provide
>background tiles is not yet available. If anyone from Mapbox has an
>update
>on when, I would be interested in hearing from you.
>
>My questions to the community are:
>  * Is it valuable to have county tiles available as backgrounds in our
>editors?
>  * Counties use all sorts of formats for name and road
>classifications. Should we produce generalized background or a detailed
>background with different colors and line type with a key? The key
>would
>have to be on the wiki as far as I know.
>  * The data is usually updated monthly. How often should we try to
>update the tiles?
>  * Is there a good cost effective solution to serve these tiles?
>   * If the solution is to use a cloud based service, is the US Chapter
>willing to pay for the service?
>
>Washington State is the only state with counties providing open data.
>If
>this works for Washington, it could work for others. If this approach
>is
>adopted, a scaleable solution will be required.
>
>Clifford
>
>-- 
>@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

-- 
Typos courtesy of fancy auto-spell technology. ___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Fwd: State Park Boundary shp file

[Jack Burke]

You can copyright a publication of facts, too. I could publish a book called 
Ugly Red Things and copyright it. But nothing would stop you from publishing 
your own book, Red Things That I Find Ugly. 

On January 23, 2016 1:48:51 PM EST, Russ Nelson  wrote:
>Kevin Kenny writes:
>> Other localities see GIS as a profit center. In New York, at least,
>this 
>> is perfectly lawful. The Court of Appeals of the Second Circuit said
>so. 
> > (There's a circuit split on the issue, if memory serves.)
> > 
>>
>https://www.rcfp.org/browse-media-law-resources/news/court-rules-copyright-maps-does-not-offend-open-records-law
>
>You cannot copyright a fact about the world in the United States. You
>can copyright creative choices that you've made in the arrangement or
>presentation of the facts, but you cannot copyright the fact
>itself. You can copyright commentary about the facts, but you cannot
>copyright the fact itself. If an object in the world is red, you can
>call it ugly and claim a copyright on that, but you cannot claim a
>copyright in its redness. You can copyright a creative subset of
>facts, but you cannot copyright the totality of facts.
>
>New York courts are free to rule any way they want, but copyright
>doesn't allow you to own facts. This is well-adjudicated in higher
>courts.
>
>If you could claim a copyright on facts, you could control people's
>speech, and the First Amendment does not allow that. The freedom of
>factual information is very strongly protected in the US. No matter
>what Suffolk County thinks.
>
>-- 
>--my blog is athttp://blog.russnelson.com
>Crynwr supports open source software
>521 Pleasant Valley Rd. | +1 315-600-8815
>Potsdam, NY 13676-3213  | Sheepdog   
>
>___
>Talk-us mailing list
>Talk-us@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/talk-us

-- 
Typos courtesy of fancy auto-spell technology. ___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Extra wide shoulders / travel lanes in NJ

[Jack Burke]

Normally yes.  But just north of Atlanta we have a freeway called Georgia 400, 
and several miles of it are signed that the shoulder lanes are allowed for all 
motor vehicle traffic between certain hours, albeit with a lower spec limit 
than the regular lanes. 

-jack

On October 16, 2015 4:29:32 PM EDT, John Eldredge <j...@jfeldredge.com> wrote:
>My experience elsewhere is that shoulders are not considered legal
>driving 
>lanes for motor vehicles, except under special circumstances, such as a
>
>construction zone where a normal driving lane has been shut down.
>People 
>who try to use the shoulder as a driving lane receive traffic
>citations.
>
>-- 
>John F. Eldredge -- j...@jfeldredge.com
>"Darkness cannot drive out darkness; only light can do that. Hate
>cannot 
>drive out hate; only love can do that." -- Martin Luther King, Jr.
>
>
>
>On October 12, 2015 11:05:12 PM Jack Burke <burke...@gmail.com> wrote:
>
>> Wait, question:
>>
>> Are these shoulder lanes under discussion *only* for bicycles, or for
>motor
>> vehicles as well?
>>
>> --jack
>>
>>
>> On Mon, Oct 12, 2015 at 11:47 PM, Elliott Plack
><elliott.pl...@gmail.com>
>> wrote:
>>
>>> Mike,
>>>
>>> I have not seen the Shoulder or Lanes tags in wide use yet. I use
>the
>>> cycleway tags on the highway line way to denote bike lanes that are
>part of
>>> the road surface, as it seems your case is. (cycleway:right=lane).
>Though
>>> in this case it is arguable if the shoulder is a lane. What is
>certain is
>>> that most cyclists treat shoulders as such.
>>> http://wiki.openstreetmap.org/wiki/Key:cycleway
>>>
>>> I'm interested in routing and the Open Source Routing Map project.
>Cycle
>>> and ped routing is especially interesting to me as an athlete, and
>so I
>>> looked on the ORSM backend for clues on how they're handling shared
>lanes
>>> and such. Looks like one of these tagging combos will work:
>>>
>https://github.com/Project-OSRM/osrm-backend/blob/8f8bd05f83fa2ccc542c2c44761f548a1e8b7579/features/bicycle/cycleway.feature
>>>
>>> Elliott
>>>
>>> On Mon, Oct 12, 2015 at 2:15 PM Mike Dupont <
>>> jamesmikedup...@googlemail.com> wrote:
>>>
>>>> Hi there,
>>>> This road cr 546 (http://www.openstreetmap.org/relation/566939) and
>>>> many others here in the area has extra wide  wide shoulders that
>>>> people use for walking or biking. How do you want to tag them as
>such
>>>> so that we can also use that for routing?
>>>>
>>>> Here is a table of the segments with lane information
>>>>
>>>>
>http://lawrencetwp.com/documents/planning/Route546BikewayBicycleCompatibilityMatrix.pdf
>>>>
>>>> I see http://wiki.openstreetmap.org/wiki/Shoulder and
>>>> http://wiki.openstreetmap.org/wiki/Lanes what are your thoughts on
>a
>>>> detailed tagging for this information.
>>>>
>>>>
>>>> thanks
>>>> mike
>>>>
>>>> --
>>>> James Michael DuPont
>>>> Kansas Linux Fest http://kansaslinuxfest.us
>>>> Free/Libre Open Source and Open Knowledge Association of Kansas
>>>> http://openkansas.us
>>>> Member of Free Libre Open Source Software Kosova
>http://www.flossk.org
>>>> Saving Wikipedia(tm) articles from deletion
>>>> http://SpeedyDeletion.wikia.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
>
>
>
>
>___
>Talk-us mailing list
>Talk-us@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/talk-us

-- 
Typos courtesy of fancy auto-spell technology. ___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Downgrading 'motorways' around toll plazas?

[Jack Burke]

My 2 mills worth (after inflation):

The Florida Turnpike is a toll road (highway=motorway in OSM) with a
standard 70 mph speed limit that drops to 25 mph a few dozen yards before
the toll plazas (even for SunPass users).  Having driven on it for years, I
would never consider any section of it to be anything less than motorway,
even the low-speed toll plazas.

--jack



On Mon, Oct 12, 2015 at 11:17 PM, James Mast 
wrote:

> We can unfortunately add two more changesets where Matt1993 has done this
> in the last 24h. [10] [11]
>
> I've sent him a PM about this to come and join us on [talk-us] to talk
> about it, but I bet he's going to 'ignore' it after what he wrote to me on
> a changeset in the last day (he must have just discovered it by luck to be
> honest). [12]  He bashed me as not being 'professional', 'rude' & to send
> him a message (I did, it's called the chanageset comment...).  I waited 6+
> days (others might have only waited 12h or less) before I attempted to fix
> any damage he's done waiting for a response on the changeset (and others
> with him too) [12] My source for the change was 'common sense/Bing'
> there because I was repairing the routing for bicycle routes as that's part
> of a Bike PA route (as mentioned in the comments of [12]) and I looked at
> the area with Bing (plus I've been there before).  When he converted it to
> a motorway (twice), it broke the bicycle routing in that area.  I was
> repairing the data there and it was a legit changeset comment on my repair
> (links to changesets in comments of [12]).  At least I explain what I'm
> doing in a changeset and don't use a 'generic' comment on all my
> changesets.  Plus, a 'Single interchange doesn't = motorway...'.  If so,
> we'd have several mini motorways segments along US-19 in West Virginia
> between I-79 & I-77, where it's a major 'trunk' highway, but has several
> interchanges sprinkled along it (the only true motorway segments it has is
> from I-77 to it's first interchange (which is where US-19 leaves/joins
> Corridor L) and the bypass segment in the Oak Hill area.  Anyways, several
> other users I talked to agreed with me on this fix for [12] (on and off of
> OSM).
>
> Anyways David, I don't agree with the 'maxspeed:advisory' tag unless the
> speed sign is one of the 'yellow' ones.  I know the toll plaza on the Ohio
> Turnpike on I-76 going into/out-of Pennsylvania uses normal speed limit
> signs.  Thus, those areas should be with the normal 'maxspeed' tag.
> However, I do fully agree with you on the lanes tag.  That's how I did it @
> the Gateway Toll Plaza on the I-76 PA Turnpike. [13]  Could use some more
> fine tuning using the 'turn:lanes' tag however.
>
> -James
>
> [10] - https://www.openstreetmap.org/changeset/34581064
> [11] - https://www.openstreetmap.org/changeset/34581478
> [12] - 
> https://www.openstreetmap.org/changeset/33674410
> [13] - https://www.openstreetmap.org/#map=17/40.90417/-80.49574
>
>
> --
> From: dwalt...@gmail.com
> Date: Mon, 12 Oct 2015 09:27:05 -0700
> To: g...@ir.bbn.com
> CC: rickmastfa...@hotmail.com; talk-us@openstreetmap.org
> Subject: Re: [Talk-us] Downgrading 'motorways' around toll plazas?
>
>
> I also don't think it's reasonable to represent every lane of a toll booth
> as a different way or as trunk. I've also tried to contact this user and
> received no response.
>
> I think a better representation is using the lanes tag and
> or  maxspeed:advisory.
>
> On Sun, Oct 11, 2015 at 7:16 PM, Greg Troxel  wrote:
>
>
> James Mast  writes:
>
> > Does anybody think it is a good idea to downgrade 'motorways' around
> > toll plazas to 'trunk' highways?  I just noticed a user did this in
> > mass in NY and MA along I-90/I-87. [1] [2] He's even done this in PA a
> > few times. [3]
>
> No, this is not reasonable.  While one might object philosophically to a
> tollbooth on an Interstate highway, that's the way the world is, and
> noting it as a tollbooth is adequate.
>
> > I've also noticed several problematic changesets this user has done in
> > the past.  I've left several comments on some of his changesets [4]
> > [5] and he's never responded to them except once, and that was after
> > sending him a few PM's (1 per month) till he finally responded only
> > partially to my question in it. [6] That leads me to believe that he's
> > either completely ignoring the e-mails, or he's not even getting them.
> > Also, in that one comment that he did leave (in [6]), he pretty much
> > completely ignored my question (if he had been there and saw shields
> > for this 'new' route since I don't want to delete 'valid' data) and
> > said that he works '12 hour days'.  Honestly, if he can still find
> > time to do big OSM edits and work for 12 hours a day, can't he spare a
> > minute or two to respond to a comment left for him instead of taking 2
> > 

Re: [Talk-us] Extra wide shoulders / travel lanes in NJ

[Jack Burke]

Wait, question:

Are these shoulder lanes under discussion *only* for bicycles, or for motor
vehicles as well?

--jack


On Mon, Oct 12, 2015 at 11:47 PM, Elliott Plack 
wrote:

> Mike,
>
> I have not seen the Shoulder or Lanes tags in wide use yet. I use the
> cycleway tags on the highway line way to denote bike lanes that are part of
> the road surface, as it seems your case is. (cycleway:right=lane). Though
> in this case it is arguable if the shoulder is a lane. What is certain is
> that most cyclists treat shoulders as such.
> http://wiki.openstreetmap.org/wiki/Key:cycleway
>
> I'm interested in routing and the Open Source Routing Map project. Cycle
> and ped routing is especially interesting to me as an athlete, and so I
> looked on the ORSM backend for clues on how they're handling shared lanes
> and such. Looks like one of these tagging combos will work:
> https://github.com/Project-OSRM/osrm-backend/blob/8f8bd05f83fa2ccc542c2c44761f548a1e8b7579/features/bicycle/cycleway.feature
>
> Elliott
>
> On Mon, Oct 12, 2015 at 2:15 PM Mike Dupont <
> jamesmikedup...@googlemail.com> wrote:
>
>> Hi there,
>> This road cr 546 (http://www.openstreetmap.org/relation/566939) and
>> many others here in the area has extra wide  wide shoulders that
>> people use for walking or biking. How do you want to tag them as such
>> so that we can also use that for routing?
>>
>> Here is a table of the segments with lane information
>>
>> http://lawrencetwp.com/documents/planning/Route546BikewayBicycleCompatibilityMatrix.pdf
>>
>> I see http://wiki.openstreetmap.org/wiki/Shoulder and
>> http://wiki.openstreetmap.org/wiki/Lanes what are your thoughts on a
>> detailed tagging for this information.
>>
>>
>> thanks
>> mike
>>
>> --
>> James Michael DuPont
>> Kansas Linux Fest http://kansaslinuxfest.us
>> Free/Libre Open Source and Open Knowledge Association of Kansas
>> http://openkansas.us
>> Member of Free Libre Open Source Software Kosova http://www.flossk.org
>> Saving Wikipedia(tm) articles from deletion
>> http://SpeedyDeletion.wikia.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] Self Storage Places

[Jack Burke]

I use commercial. 

To me, retail implies that you can take home a product (even if it's food in 
your stomach). Commercial means you are buying a service. 

-jack



On October 1, 2015 1:35:14 AM EDT, Clifford Snow  
wrote:
>On Wed, Sep 30, 2015 at 9:53 PM, Hans De Kryger
>
>wrote:
>
>> What landuse should i use for Self Storage places?
>
>
>I'd most likely use retail but commercial depending on the
>location,might
>also be appropriate.
>
>
>-- 
>@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

-- 
Typos courtesy of fancy auto-spell technology. ___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Find missing roads

[Jack Burke]

Clearly, your sample contained nuts. 


On September 30, 2015 2:40:37 PM EDT, Paul Johnson  wrote:
>On Wed, Sep 30, 2015 at 10:11 AM, Martijn van Exel  wrote:
>>
>> Our OSM team cooked up something new. A missing roads plugin for
>JOSM. I
>> think it's pretty nice but I would really like to hear what you
>think.
>>
>
>Neat, has potential.
>
>You can read some more about it on my diary
>(http://bit.ly/missingroads)
>> but it's basically what it says on the tin. The plugin will show
>where we
>> think roads are missing from OSM based on GPS data so you can add
>them :)
>>
>
>Based on whose GPS data from where?  I trust the source in this
>question
>is completely halal, kosher, gluten-free, vegan, organic, free-range,
>all-natural data, but some of the output I'm getting from it is rather
>odd.  Take, for example, this screenshot in JOSM near node 148319848
>
>in my
>neighborhood.
>
>
>​
>Other than highlighting my own inadvertently selective blindness (what
>with
>having not mapped the large and aging chain link fence factory on the
>northeast corner of the intersection; Brinks behind my favorite
>QuikTrip
>
>only
>recently appeared on Bing), I do find two things remarkable about this
>plugin's output:
>
>   1. It seems to have picked out an incomplete set based on the paths
>   relative to imagery.
> 2. I have no way of being able to survey the exact location of the GPS
>output from the plugin from the ground (it's inside a fence factory,
>*of
> course* it's fenced off!), so I can only assume the GPS was located on
>   one of those big diesel-powered forklifts.
>
>
>
>
>___
>Talk-us mailing list
>Talk-us@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/talk-us

-- 
Typos courtesy of fancy auto-spell technology. ___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] what happened to Sacramento?

[Jack Burke]

You're not crazy. Just using the regular OSM website interface, I can find the 
city node, and the county boundary, but not a city boundary. AFAICT, it isn't a 
consolidated city-County, so it should exist. 

-jack


On September 29, 2015 5:10:25 PM EDT, Ray Kiddy  wrote:
>
>I have been fixing up boundaries of cities in California and I have
>found something odd.
>
>Where is the city of Sacramento?
>
>There is a city there. There is a county. The county boundaries are at
>http://openstreetmap.org/relation/396460 and that all looks good. And
>it is not a county/city hybrid thing like San Francisco. Yes? And I can
>find the cities of West Sacramento, Rancho Cordova and others nearby,
>But I cannot find boundaries for the actual city of Sacramento. Google
>has boundaries for it, but OSM does not?
>
>Or is there some way I should be finding it that I am not doing? I
>guess it could be mis-spelled.
>
>I am going to the area around the county in
>http://overpass-turbo.eu/ and doing this search:
>
>[out:json][timeout:360];
>(
>relation["name"="Sacramento"]({{bbox}});
>way["name"="Sacramento"]({{bbox}});
>node["name"="Sacramento"]({{bbox}});
>);
>out body;
>>;
>out skel qt;
>
>It finds lot of stuff, but no city. Any ideas?
>
>cheers - ray
>
>
>
>___
>Talk-us mailing list
>Talk-us@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/talk-us

-- 
Typos courtesy of fancy auto-spell technology. ___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] More strangeness in Baltimore

[Jack Burke]

I'll put money on it being the same vandal. 
1) The account was created today
2) The account profile has the following on it: "Homicide: Life On The Street 
Baltimore 1990"

-jack

On September 14, 2015 1:26:47 PM EDT, Andy Townsend  wrote:
>Can any Baltimore locals veryify or otherwise the changes in 
>https://www.openstreetmap.org/changeset/34024769 ?
>
>It looks a similar style to the recent problematical ones there and at 
>the very least that one seems to break some bus route relations.
>
>Cheers,
>
>Andy Townsend (SomeoneElse)
>
>
>___
>Talk-us mailing list
>Talk-us@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/talk-us

-- 
Typos courtesy of fancy auto-spell technology. ___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Request revert on Changeset #33669446

[Jack Burke]

Paul,

He's not saying that jakeroot isn't the most recent editor. He's saying that 
the specific changes you're referring to are in changesets earlier than 
jakeroot's, and that *those* changesets appear to be yours. 

Not at a computer, so can't look myself. 

-jack


On September 4, 2015 4:44:53 PM EDT, Paul Johnson  wrote:
>This is in conflict with what I'm seeing in the area around Vancouver
>Mall,
>where jakeroot appears to be the most recent editor of everything along
>WA500.
>
>On Fri, Sep 4, 2015 at 12:43 PM, Chris Lawrence 
>wrote:
>
>> It's in the OSM way history. I didn't make it up. Look at it yourself
>if
>> you don't believe me.
>>
>> http://www.openstreetmap.org/way/45846830/history
>> - "lanes" disappears between revisions 19 and 20. You submitted
>revision
>> 20.
>>
>> http://www.openstreetmap.org/way/45846831/history
>> - "lanes" disappears between revisions 13 and 14. You submitted
>revision
>> 14.
>>
>> http://www.openstreetmap.org/way/201133287/history
>> - "lanes" disappears between revisions 3 and 4. You submitted
>revision 4.
>>
>> I could go on...
>>
>>
>> Chris
>>
>> On Fri, Sep 4, 2015 at 12:58 PM Paul Johnson 
>wrote:
>>
>>> On Fri, Sep 4, 2015 at 10:45 AM, Chris Lawrence
>
>>> wrote:
>>>
 On Fri, Sep 4, 2015 at 3:54 AM Paul Johnson 
>wrote:

> I'm going to have to additionally request this revert due to a
>fairly
> substantial loss of data that was involved after I spent a good
>12-15 hours
> on detail lane tagging this expressway.  It appears many ways got
>merged
> and data was lost as a result.
>

 Paul - You deleted that data yourself in changeset 32790788 when
>you
 made the road a trunk in the first place.

>>>
>>> Patently false.  I still have the last edit I made in the area on my
>>> desktop.  jakeroot vandalized the map in his quest to tag the map
>NE2
>>> style, and merged dozens of ways with zero regard for any tags
>except the
>>> one he was trying to game.
>>>
>> --
>> Christopher N. Lawrence 
>>
>
>
>
>
>___
>Talk-us mailing list
>Talk-us@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/talk-us

-- 
Typos courtesy of fancy auto-spell technology. ___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Pequot Terrace

[Jack Burke]

Just offering my unsolicited opinion

From the map, I would guess that this node is located near an old settlement, 
where the train station used to be, that has since been absorbed into the 
larger city nearby. 

From other searching, it appears that the name is being applied to a nearby 
mobile home park nowadays.  Maybe move the node (or rather let someone local 
check and move the node) and reclassify it as neighborhood.

-jack


On July 10, 2015 8:17:54 AM EDT, Clifford Snow cliff...@snowandsnow.us wrote:
I'm vacationing near Nisswa, MN. In the city of Nisswa, there is a
hamlet
node for Pequot Terrace just a short distance from the City of Nisswa
node.
As far as I can discover, there is no Pequot Terrace here.
http://www.openstreetmap.org/node/151467331

Since I don't live in Minnesota, I'd like to hear from some locals if
it is
ok to delete the node. It was imported from GNIS in 2007 with a
modification a year later to add the county.

Clifford

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

-- 
Typos courtesy of fancy auto-spell technology. ___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] cycle.travel US bike routing, and unreviewed rural TIGER

[Jack Burke]

So, just for fun, I'm going through the area you pointed out and fixing some of 
the roads. I'm making some of those Unclassified instead of Tertiary because 
they go from nowhere to nowhere, but feel free to change them. 

I plan on making a road trip in a few weeks, and depending on timing and 
weather, I might make a detour through that area and capture a random sampling 
of those roads in Mapillary. 

-jack


On June 19, 2015 3:47:22 PM EDT, Richard Fairhurst rich...@systemed.net wrote:
Just as a postscript to this discussion I thought I'd cite an example
area.
If you look here, in Georgia:

   http://cycle.travel/map?lat=31.9023lon=-84.0398zoom=14

you'll see that most of the roads are unreviewed TIGER residentials. Of
those, these are adjacent to each other:

http://www.openstreetmap.org/way/9359782 - good tarmac, should be
highway=tertiary
http://www.openstreetmap.org/way/9359913 - unpaved road;
highway=unclassified, surface=unpaved
http://www.openstreetmap.org/way/9359784 - probably tertiary, but lousy
geometry at the S
http://www.openstreetmap.org/way/9359783 - whoops, where did the
connectivity go?

All of this is trivially fixable but right now there's no way of using
them
for routing or sensible cartography. Do dive in - the cycle.travel
rendering
makes it obvious which bits need fixing, and you learn to identify the
roads
which are likely to be paved through roads and therefore targets to
fix.
It's quite good fun. :)

cheers
Richard





--
View this message in context:
http://gis.19327.n5.nabble.com/cycle-travel-US-bike-routing-and-unreviewed-rural-TIGER-tp5848084p5848589.html
Sent from the USA mailing list archive at Nabble.com.

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

-- 
Typos courtesy of fancy auto-spell technology. ___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] cycle.travel US bike routing, and unreviewed rural TIGER

[Jack Burke]

Usually I change it to =yes instead of just deleting it. The main reason is I 
frequently use ITOworld maps to review the county I live in to find unreviewed 
roads, and I like the color pattern better that way. 

-jack

On June 22, 2015 2:46:36 AM EDT, Bryce Nesbitt bry...@obviously.com wrote:

 In other words, it won't route over a rural road tagged as
 highway=residential
 tiger:reviewed=no


Most of the well reviewed Tiger I see still has this tag.
People don't know to delete it.  The automatic delete on edit does not
apply to tiger:reviewed (it applies to a Tiger tag I wish was kept
instead!).




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

-- 
Typos courtesy of fancy auto-spell technology. ___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

[Talk-us] Things that are not buildings but are used as one

[Jack Burke]

Is it correct to tag a non-building object with building=yes if it is 
functionally used as one? 

As examples, I'm thinking about restaurants that use an old train car as a 
dining room, or this unusual example of a riverboat as a welcome center 
http://osm.org/go/Tv8f5t42q?layers=Nway=349671718

-jack
-- 
Typos courtesy of fancy auto-spell technology. ___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

[Talk-us] Truck stop gas stations as caravan_site

[Jack Burke]

Hi folks, 

I was wondering if it is appropriate to tag truck stops with 
tourism=caravan_site. I've noticed a lot of them tagged this way, presumably 
because many of the truck stop chains allow overnight parking of RVs, some have 
dump stations, etc. 

The wiki on caravan_site seems to imply a more specialized place like a real RV 
campsite, which wouldn't include a truck stop. 

-jack
-- 
Typos courtesy of fancy auto-spell technology. ___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

[Talk-us] OSM US Google group gone?

[Jack Burke]

What happened to the OSM US Google group? I can't find it any more. 

-jack

-- 
Typos courtesy of fancy auto-spell technology. ___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] [Imports] Importing Tesla Superchargers

[Jack Burke]

In many cases, the sucket:tesla_supercharger is different

So Tesla is calling their supercharger sockets suckets?

How appropriate. 

-jack


On April 13, 2015 4:24:03 PM EDT, Charles Samuels o...@charles.derkarl.org 
wrote:
On Sunday, April 12, 2015 05:33:02 PM Greg Troxel wrote:
 You may actually be right about the likelihood of correctness, and
this
 may lead to an expected value of  0.1 errors per year.  However,
 imports changing data entered by hand is something that crosses a
 cultural bright line, and I find it concerning that you're heading
down
 that path.  I say that as someone who is usually much more on the
 pro-import side.
 
 To stay within OSM norms, the thing to do is leave the existing data
 alone, and publish a list someplace of mismatches.  It's fine to
write
 to the person who added it and explain that there's a mismatch and
ask
 if they are sure.

Ok, I've made a bunch of changes to the code so that I make fewer
changes to 
OSM. Please follow the links in the original email to see the (now
updated) 
OSM changefile.


 
 The other notion in imports is to test  out the process before you do
 it.  Have you run the conflation code against the osm database, and
how
 many cases are there where osm already has a charger station but the
 tags dont' match?

There are 127 such differences, the vast majority of which are the
name tag. 
I have manually checked this differences:

- The name tags I produce are better than the original
- If they're not better, I manually adjust them
- In many cases, the sucket:tesla_supercharger is different, sometimes 
capacity is different too, in all cases, my numbers match Tesla.com's
- A small number of opening_hours tags are wrong in OSM
- The resulting .osm file I produce has the old tags in an XML comment
for 
convenience.
- Going forward I can and will look at new conflicts.

Charles

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

-- 
Typos courtesy of fancy auto-spell technology. ___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Boundaries and verifiability (was Re: Retagging hamlets in the US)

[Jack Burke]

I would politely disagree that TIGER is an authoritative source for two reasons:

1) The extensive TIGER cleanup that is still being done years after the last 
import, and

2) While helpful at compiling data, the federal government is not authoritative 
for any boundaries within a state (and once established, not even for the 
boundaries of the states themselves).

-jack

On March 24, 2015 4:57:44 PM EDT, Martijn van Exel mart...@openstreetmap.us 
wrote:
 there is an
authoritative
source for official administrative boundaries that can be easily
accessed
by anyone: TIGER

-- 
Typos courtesy of fancy auto-spell technology. 

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

Re: [Talk-us] Mappy hour tomorrow!

[Jack Burke]

Won't be able to make it. 2pm is the middle of my afternoon at work. 

-jack

On March 8, 2015 10:42:00 PM EDT, Martijn van Exel m...@rtijn.org wrote:
Hey all,

It's time for Mappy Hour tomorrow! I changed the time slot to 11am
Pacific
/ 2pm Eastern, let's try that a few weeks and see if it works for more
people. Let me know.

https://plus.google.com/u/0/events/cpiqg6sldpjconoipvhmd3skhcc

We will start doing a theme as promised, I just don't know what it
should
be and haven't had time to think about it. Any suggestions?
-- 
Martijn van Exel
skype: mvexel




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

-- 
Typos courtesy of fancy auto-spell technology. ___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Mappy hour tomorrow!

[Jack Burke]

PS. The event link doesn't work for me. 


On March 8, 2015 10:42:00 PM EDT, Martijn van Exel m...@rtijn.org wrote:
Hey all,

It's time for Mappy Hour tomorrow! I changed the time slot to 11am
Pacific
/ 2pm Eastern, let's try that a few weeks and see if it works for more
people. Let me know.

https://plus.google.com/u/0/events/cpiqg6sldpjconoipvhmd3skhcc

We will start doing a theme as promised, I just don't know what it
should
be and haven't had time to think about it. Any suggestions?
-- 
Martijn van Exel
skype: mvexel




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

-- 
Typos courtesy of fancy auto-spell technology. ___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Destination tagging

[Jack Burke]

I don't see where you're getting the interstate references shouldn't go in
the destination tag bit...can you quote the sentence/paragraph on that?  I
agree that it seems wrong, for the same reason you listed.

The ref= tag is used for the highway number on the actual highway itself.
E.g., I-95 should have a ref=I 95 on the highway=motorway.  The ref=tag
is used on freeway exits to indicate the exit number on the junction node
(where the exit ramp diverges from the freeway).

I put whatever is on the sign in the destination= tag, even if it's an
Interstate number.

Abbreviating Interstate as just I does seem to go against the OSM rule of
not using abbreviations.  :-)  I suspect that it started that way
(abbreviated) because in Europe they have highway naming systems that just
have a letter that has no meaning (that is, not an abbreviation), so they
just figured the same thing applied to the U.S. and we just used the letter
I for our major freeways instead of the letter A like most of them do.
Although I've been just using the letter I, I would say that Interstates
should be spelled out to conform to the no-abbreviation rule.

As for north/south, same thing:  spell them out.

And I don't use the dash, and put a blank, as you describe.

I think your examples are correct for your signs.

--jack


On Tue, Mar 3, 2015 at 10:28 AM, Harald Kliems kli...@gmail.com wrote:

 I recently captured Mapillary imagery along I-90W between Madison and
 Wisconsin Dells with the aim of adding destination tags to exits. The
 example section of the documentation in the wiki [1] only has German signs,
 which is not that useful. I'm wondering how people handle the highway
 destinations commonly found on signs. For a somewhat complex example, take
 this sign:

 http://mapillary.com/map/im/lE5ZLUjfn-gTLB51nnh9fg

 (Not that for some reason the Mapillary has an offset for the location of
 the images; the actual location of the sign is about here:


 http://www.openstreetmap.org/?mlat=43.10188mlon=-89.28977#map=18/43.10188/-89.28977
 )

 So for the left part of the highway I tagged
 destination:lanes=I 39 North;I 90 West; I 94 West;Wisconsin Dells|I 94
 East;Milwaukee

 For the off-ramp: destination=I 39 South;I 90 East;Janesville;Chicago

 Questions:
 - the wiki page seems to imply that the various interstate references
 shouldn't go into the destination tag. That seems wrong to me, as I'd
 expect a router to include them (Take the exit towards I 39 South, ...)
 and don't see where else they would reasonably go. The wiki (first example)
 says Additionally it is possible to set ref=A 2 on the highway=motorway.
 -- not sure what that means.
 - The ever-recurring abbreviation question: Do I write out Interstate or
 not? Abbreviate north/south...? I have the suspicion in some cases that
 would lead to exceeding the 255 char limit. If using an abbreviation, we
 don't use a dash between I and the number, and a blank between the number
 and direction, right?

 Thanks for your input. In case there is consensus (one can dream!), I'm
 happy to update the wiki with some more US-specific examples.

  Harald.

 ___
 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] Retail Example using OSM

[Jack Burke]

I'll be out on a limb and say that the reason is because they know not all 
locations for a particular business are mapped in OSM and so they don't want to 
rely on OSM for the actual locations. 

Which begs the question of why Where 2 Get It doesn't edit OSM themselves to 
add the locations (which I will answer by saying that W2GI knows that they 
aren't familiar enough with all the areas to do it properly).

-jack


On December 22, 2014 10:44:12 AM EST, Tod Fitch t...@fitchdesign.com wrote:

On Dec 22, 2014, at 7:36 AM, Peter Dobratz wrote:

 The company providing the service is Where 2 Get It (
http://www.where2getit.com/ ).  They provide maps for store locator
functions for a number of companies.  For example: Moe's Southwest
Grill, Safeway, Trader Joe's, Jo-Ann Fabric, Michael's.  OSM is used
for the base map with the store location placemarks as an overlay.  You
can tell that they are not utilizing the OSM data for the store
locations because if you look closely you can see that their placemarks
don't always line up with the actual locations of the stores in OSM.
 
 --Peter
 
I had noticed that the nearest Michael's to me had the pin in the wrong
part of the shopping center (I am the one that mapped that Michael's
location for OSM and am pretty sure I have it right).

Just looked at the Trader Joe's web site and it looks like they are
using background map data from NAVTEQ. But they also have the store
nearest me in the wrong location. :)



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

-- 
Typos courtesy of fancy auto-spell technology. ___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Beaver dam? Wrecked bridge? Hallucinatory roads in TIGER?

[Jack Burke]

access=use_at_your_own_risk

access=two_paths_diverged_in_a_yellow_wood

access=choose_wisely

access=plugh

access=xyzzy

?

-jack


On December 22, 2014 10:06:15 AM EST, Richard Welty rwe...@averillpark.net 
wrote:
On 12/22/14 3:27 AM, Bryce Nesbitt wrote:
 I've frequently wanted to map the trails that peter out for exactly

 the reason you state.

 The choices as a mapper seem wrong:
 1) Map the trail : thus encouraging use of a flawed route.
 2) Don't map the trail.  The casual map reader thinks OSM is missing 
 something.


 Possible solutions include a node type of becomes indistinct, or 
 dead end.
 How to mark the way is trickier.
perhaps a new access tag..

access=deprecated
access=not_recommended

something else?

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

-- 
Typos courtesy of fancy auto-spell technology. ___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] State highway refs (was Re: New I.D Feature)

[Jack Burke]

In Georgia, (almost?) all state roads are signed with the state outline and the 
highway number, but no GA or Georgia text with it. Occasionally you might 
see State Road or State Route printed on the sign in addition to the state 
outline. In some very rural areas, I think there might still be a few un-logoed 
signs, but probably not many. 

-jack

On November 30, 2014 5:58:53 PM EST, Minh Nguyen m...@nguyen.cincinnati.oh.us 
wrote:
On 2014-11-30 10:41, stevea wrote:
 My two cents:  I must say that here in California, I've made it a
habit
 to remove the County Route designation (CR) which precedes a ref
 number in our County Route system.  For example, NE2 (a
banned-from-OSM
 former contributor for those unfamiliar with that history) entered
ref
 tags for many G2, N1... county routes as CR G2 and CR N1.  That,
in
 my opinion, is so redundant (as G and N and A and S... are well-known
 multi-county/regional-within-California county highway networks) as
to
 be true clutter.  People in California do know (and routing software,
 renderers... SHOULD know) that A1, G2, N4 and S16 are county routes
in a
 lettered system where each letter represents a cluster of
counties...at
 least in California.

Some northwest Ohio counties post shields along section line roads that

say A, B, C, etc. So far I've been tagging them like CR A, even
though 
you'd be hard-pressed to find that style anywhere outside of OSM. 
Instead of reducing ambiguity, I wonder if the CR may cause very mild

confusion, for example when a router tells its user to turn onto CR
R.

 Also, while SR (for State Route in California and other states)
is
 still legally correct, I still might change for consistency's sake
any
 SR prefix I see in a highway route relation ref tag to be CA
 instead.  So, while SR 17 is correct, I much prefer CA 17 and
will
 change it to that if I see SR in a California highway route relation
ref
 tag.

Yes, usage is different in California. I've only ever seen SR on 
signage a few times, in rather obscure places. But in Ohio, it's
ubiquitous.

 I agree with what we (as OSM volunteers entering/editing data in our
 map) now do, as well as what map styles/renderers and routing engines
 do, as Minh notes above:  recognize the state abbreviation, SR or
SH.
 Yes, Michigan still has its M- routes, and I think OSM (both its
human
 editors and software components) should just learn to cope with that
 (plus perhaps a few other states) as exceptions to this largely
(though
 not completely) applicable rule.  I believe we are pretty much there,
 but we still have edge cases, data in the map and newer contributors
who
 are not completely familiar with these conventions in the USA.
 Discussing it here helps, though wiki documentation and taginfo data
 which are consistent across the fifty states is better.

My response to anyone who wants more consistency is that route
relations 
are the way forward. They may be painful now but they make the data a 
lot less subject to interpretation.

-- 
m...@nguyen.cincinnati.oh.us


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

-- 
Typos courtesy of fancy auto-spell technology. ___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

[Talk-us] Directional suffixes on roads: yes or no?

[Jack Burke]

Howdy, 

I have a question about how much effort should be put into adding directional 
suffixes to road names. 

Many counties around Atlanta have adopted directional suffixes for roads, both 
in incorporated areas as well as outside city limits. Usually all areas in the 
county use the same system, with directions denoted NE, SE, NW and SW from some 
standard point, although some cities tend to ignore the suffixes. Also, signage 
is inconsistent--some street signs bear the suffix while others on the same 
street don't. 

In most cases, the suffix is immaterial, and most people don't use it anyway.  
Use of it or not won't affect directions most of the time,  although I know of 
a few specific cases where knowing the suffix can be important in finding the 
right location (is your house 100 Concord Road Southeast or  Southwest?).

The majority of the Tiger data doesn't include the suffix.

So, how much should I worry about the missing suffixes? Should they be included 
in the main name= tag? Or one of the other *name tags with the unsuffixed name 
in the name= tag. 

Because most people don't use the suffix, on some roads I've put the 
with-suffix name in the name= tag and the unsuffixed one in the short_name= 
tag, but I'm wondering if I should continue to bother. 

-jack


-- 
Typos courtesy of fancy auto-spell technology. ___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] admin level for US states

[Jack Burke]

I would point out that the legal status of U.S. States is slightly different 
than that of provinces (and likely of states in other countries).  For one 
thing, U.S. States exist in their own right and do not drive their existence 
from a higher government (even though most of them were created by a higher 
government). German States and perhaps Swiss cantons might have the same status.

-jack

On November 24, 2014 9:44:22 AM EST, Richard Weait rich...@weait.com wrote:
On Mon, Nov 24, 2014 at 8:00 AM, Martin Koppenhoefer
dieterdre...@gmail.com wrote:
 I wonder why US States are tagged as admin_level=4, wouldn't it be
more
 consistent with the rest of the map to have them tagged as level 3?


Based on which uses of admin_level=3?   A quick scan of the wiki shows
admin_level=4 as states or provinces for several countries.

I guess the biggest reason they are admin_level=4 now is, that seemed
like the way to go in 2009[1], but that wouldn't prevent a change for
a compelling reason.

[1] wiki history of the admin_level page goes back to 2009, the tag
use in USA could pre-date that.
http://wiki.openstreetmap.org/wiki/Tag:boundary%3Dadministrative

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

-- 
Typos courtesy of fancy auto-spell technology. ___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] admin level for US states

[Jack Burke]

And the England/Wales and /Scotland borders are all 4, too. If we're trying to 
reflect geopolitical status, these should absolutely be different than 
provinces. OTOH, if we're just interested in drawing pretty lines

-jack

On November 24, 2014 12:55:04 PM EST, Martin Koppenhoefer 
dieterdre...@gmail.com wrote:
2014-11-24 18:05 GMT+01:00 Brad Neuhauser brad.neuhau...@gmail.com:

  ...and German states and Swiss cantons are admin_level=4 according
to the
 previously-linked page.



yes, I am coming from a German-Italian perspective, where Italian
regions
are clearly less sovereign than German states, which again are less
sovereign than US american states (all on level 4 currently).
We need the levels 5 to 10 in Germany (all are in use, 3 is not in
use).
Correspondance of European entities should also be supported by the
NUTS
and LAU system:
http://en.wikipedia.org/wiki/Nomenclature_of_Territorial_Units_for_Statistics
http://en.wikipedia.org/wiki/Local_administrative_unit

cheers,
Martin




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

-- 
Typos courtesy of fancy auto-spell technology. ___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Rand McNally is using OSM

[Jack Burke]

Haven't found the attribution yet, but Hans is right. In my county, I can 
clearly see that the buildings shown on the RMcN map match ones in OSM, 
including neighborhoods where I drew some houses but skipped others because the 
imagery isn't clear enough. 

-jack


On November 22, 2014 9:46:08 PM EST, Richard Welty rwe...@averillpark.net 
wrote:
On 11/22/14 9:29 PM, Hans De Kryger wrote:
 Rand McNally is using OSM in TripMaker. Say what? No way.

 1.) http://tripmaker.randmcnally.com/
 2.) https://www.mapbox.com/blog/rand-mcnally-uses-mapbox/

perhaps someone smarter than i am can point out where the
attribution for OSM contributors is on the Rand McNally site.

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

-- 
Typos courtesy of fancy auto-spell technology. ___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Second thoughts

[Jack Burke]

OSM has the tag unsigned_ref to handle exactly this situation.  There just 
isn't a wiki page describing it. 

-jack


On October 13, 2014 3:45:22 PM EDT, Dale Puch dale.p...@gmail.com wrote:
US 52 FOLLOWS I 94 to me means they are concurrent, even if Minnesota
only has signs for I94 instead of I94/US52
So it is a matter of presentation, not facts.

Here in Florida there are places where most signs list only one name,
but
periodically there will be references to other names sharing the same
route.

Dale

Dale Puch

On Mon, Oct 13, 2014 at 9:59 AM, Tom Fistere tbfist...@gmail.com
wrote:

 Hello!  My name is Tom Fistere and I go by CountryLoon on OSM.  After
 about a week of editing I thought I should throw out a couple of
questions
 and comments of what I am doing so far...

 I have started looking at the road typing throughout the state of
 Minnesota as it gives me an opportunity to study the status of the
map
 statewide.  I see areas that are well documented and drawn and then
there
 are areas so neglected that the lines and imagery are needed some
immediate
 help.  I invite anyone to check out my editing job on the segment of
MN 23
 between St Cloud and Foley, MN as it was rebuilt to an expressway in
2013
 and let me know how I did.

 A couple of questions, Minnesota hates concurrent highways.  US 52 is
 concurrent with I 94 from St Paul, MN to Fargo, ND according to
AASHTO but
 MNDoT refuses to sign the routing beyond US 52 FOLLOWS I 94 sign at
the
 interchange in St Paul.  A similar thing occurs with US 12 through
the Twin
 Cities to the Wisconsin line.  Should the map reflect the concurrency
or
 not?  Google chose to do it but since it is unsigned, I lean toward
not
 showing it.

 Most of my information is coming from county GIS sites and DOT, are
there
 other other sites I should be checking into when looking for
information
 verification?  So far my interest is in the road network but I am
willing
 to branch off into recreational trails and such in the future.

 Thanks!
 Tom

 ___
 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

-- 
Typos courtesy of fancy auto-spell technology. ___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Edits needing investigation in Tennessee

[Jack Burke]

I'm not from Tennessee, but I am next door and make occasional trips there. I 
can take a look at some of them and see if they're something I'm comfortable 
offering an opinion on. 


On October 10, 2014 11:54:09 AM EDT, Andrew Guertin andrew.guer...@uvm.edu 
wrote:
While investigating changes in my area, I noticed that 
http://www.openstreetmap.org/user/Rondale has quite a large number of 
changes recently where they changed highway=* to highway=residential (*

including at least service[1], unclassified[1], tertiary[1], secondary,

primary[2], and trunk[2]).

I have messaged them specifically about the changes in Vermont, but 
there are other changes in Tennessee that I'm not local to and wouldn't

feel comfortable discussing or reverting. In Vermont, the highway 
changes were paired with other changes (road deletions, road additions,

road additions through buildings[3]...) that may (?) have come from 
working with old aerial imagery. Is there anyone here from Tennessee to

check if similar problems exist in this user's edits to that area? And 
would feel comfortable reverting if appropriate?

--Andrew


[1] http://nrenner.github.io/achavi/?changeset=25947668
[2] http://nrenner.github.io/achavi/?changeset=25904320
[3] http://nrenner.github.io/achavi/?changeset=25967936

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

-- 
Typos courtesy of fancy auto-spell technology. ___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us