Re: [Talk-us] Parks in the USA, leisure=park, park:type

[OSM Volunteer stevea]

(I'll try that again, without the link syntax that got scrubbed).

Apologies for length, yet this is long and requires words.

> brad  wrote:
> I like this
> (what Joseph Eisenberg wrote)
> better than calling a state park a national park.  Tagging them state parks 
> with the national park tag is an abstract concept that will just result in 
> confusion.

Brad, I "like it," too (what Joseph wrote, as it correctly meets present-day 
OSM conventions), but I won't (right now) go so far as to say I like it 
"better."  We have both, as both definitions and tagging are messy; we have 
multiple tagging methods for meaning the same thing.  I say this partly because 
the concept OSM defines as "national_park" seems (to me) to directly fit onto 
state parks.  I am not alone, as I look at how we tag in the USA:  hundreds of 
"parks" (park-like things) are tagged boundary=national_park when they are not 
"National Parks" as administered by the National Park Service.  Try this OT 
query (which geocodes in randomly-chosen Oregon, searching for 
boundary=national_park there):  overpass-turbo.eu/s/IHx .  You get 20 
megabytes:  hundreds of results representing dozens of "parks," some of them 
national monuments, national recreation areas, national forests, national 
historic parks, a national grassland and yes, even a national_park (as you'd 
expect), Crater Lake NP.

However, note there are also numerous STATE parks, STATE forests, STATE 
recreation areas and things like STATE recreation site, STATE scenic viewpoint 
and STATE natural area.  See:  in one randomly selected state alone, several 
STATE parks NOW TAGGED boundary=national_park!  I am being descriptive (what 
is) as I report these data, not prescriptive (what should be), as I don't say 
how we OUGHT to tag.  I observe that there appear to be few or no consistent 
tagging standards on "parks" in the USA (where I spend time looking, this may 
be true more widely in OSM).  That was my point as I initiated this thread:  so 
we might achieve both better understanding of parks and better (more 
consistent) tagging on parks.

"Tagging them state parks with the national park tag" is NOT "an abstract 
concept," it is correct.  I don't want to get overtly political, but the 50 
states are sovereign.  Period, full stop.  Including how states define parks.  
Please see the US constitution's 10th amendment, and 
https://en.wikipedia.org/wiki/Political_divisions_of_the_United_States, which 
states "According to numerous decisions of the United States Supreme Court, the 
50 individual states and the United States as a whole are each sovereign 
jurisdictions," with cite.  This is settled, well established US legal 
doctrine.  I hope OSM can agree with the US Supreme Court along with centuries 
of decisions by US jurists and citizens (and I think we largely do).

>   If the consensus is to tag them the same then I suggest depracting the 
> national park tag and coming up with something else so it isn't confusing.

I hear you as you say you are confused.  I hope this post has helped w.r.t. 
state sovereignty and the fact that many others in the USA both understand 
state sovereignty and continue to tag "true" (NPS) national parks, 
national-park-like (but aren't) federal areas AND state parks and 
state-park-like areas with boundary=national_park.  (Understandably, and I 
believe correctly, given our wiki definitions and the USA's legal/political 
realities).  I observe I am simply describing and not prescribing (thou shalt 
tag like this...).  I observe this appears messy to many and that untangling it 
has been, is and likely will be difficult.  IMO, Joseph's observations are 
similar positive-contribution suggestions.  I speak for myself, but this thread 
in talk-us seem a proper forum for this dialog.  If, after reading this, you 
have similar forward-looking observations and suggestions of your own, I wish 
to hear those.  Including deprecating the national_park tag, while I listen as 
you might suggest with what we might replace it, and how.  These might align 
perfectly with Joseph's suggestions (though he doesn't appear to advocate for 
deprecation of national_park), or they might not.  I listen.

Thanks,
SteveA

> (what Joseph Eisenberg wrote):
>> I would recommend starting to use boundary=protected_area for State
>> parks, and other parks that are large natural areas that are designed
>> for a balance of tourism and protection of the natural environment but
>> are not actually National Parks.
>> 
>> https://wiki.openstreetmap.org/wiki/Tag:boundary%3Dprotected_area
>> 
>> You can tag state parks like this:
>> 
>> boundary=protected_area + protect_class=2 + protection_title="State Park"
>> 
>> Protect Class 2 is the same type as National Parks, and will be
>> rendered and interpreted the same by most database users, but the
>> protection title makes it clear that it's actually a State Park, not a
>> National Park.
>> 
>> For county parks: many of these are small parks 

Re: [Talk-us] Parks in the USA, leisure=park, park:type

[OSM Volunteer stevea]

Apologies for length, yet this is long and requires words.brad  wrote:I like this(what Joseph Eisenberg wrote)better than calling a state park a national park.  Tagging them state parks with the national park tag is an abstract concept that will just result in confusion.Brad, I "like it," too (what Joseph wrote, as it correctly meets present-day OSM conventions), but I won't (right now) go so far as to say I like it "better."  We have both, as both definitions and tagging are messy; we have multiple tagging methods for meaning the same thing.  I say this partly because the concept OSM defines as "national_park" seems (to me) to directly fit onto state parks.  I am not alone, as I look at how we tag in the USA:  hundreds of "parks" (park-like things) are tagged boundary=national_park when they are not "National Parks" as administered by the National Park Service.  Try this OT query (which geocodes in randomly-chosen Oregon, searching for boundary=national_park there):  https://overpass-turbo.eu/s/IHx .  You get 20 megabytes:  hundreds of results representing dozens of "parks," some of them national monuments, national recreation areas, national forests, national historic parks, a national grassland and yes, even a national_park (as you'd expect), Crater Lake NP.However, note there are also numerous STATE parks, STATE forests, STATE recreation areas and things like STATE recreation site, STATE scenic viewpoint and STATE natural area.  See:  in one randomly selected state alone, several STATE parks NOW TAGGED boundary=national_park!  I am being descriptive (what is) as I report these data, not prescriptive (what should be), as I don't say how we OUGHT to tag.  I observe that there appear to be few or no consistent tagging standards on "parks" in the USA (where I spend time looking, this may be true more widely in OSM).  That was my point as I initiated this thread:  so we might achieve both better understanding of parks and better (more consistent) tagging on parks."Tagging them state parks with the national park tag" is NOT "an abstract concept," it is correct.  I don't want to get overtly political, but the 50 states are sovereign.  Period, full stop.  Including how states define parks.  Please see the US constitution's 10th amendment, and https://en.wikipedia.org/wiki/Political_divisions_of_the_United_States, which states "According to numerous decisions of the United States Supreme Court, the 50 individual states and the United States as a whole are each sovereign jurisdictions," with cite.  This is settled, well established US legal doctrine.  I hope OSM can agree with the US Supreme Court along with centuries of decisions by US jurists and citizens (and I think we largely do).   If the consensus is to tag them the same then I suggest depracting the national park tag and coming up with something else so it isn't confusing.I hear you as you say you are confused.  I hope this post has helped w.r.t. state sovereignty and the fact that many others in the USA both understand state sovereignty and continue to tag "true" (NPS) national parks, national-park-like (but aren't) federal areas AND state parks and state-park-like areas with boundary=national_park.  (Understandably, and I believe correctly, given our wiki definitions and the USA's legal/political realities).  I observe I am simply describing and not prescribing (thou shalt tag like this...).  I observe this appears messy to many and that untangling it has been, is and likely will be difficult.  IMO, Joseph's observations are similar positive-contribution suggestions.  I speak for myself, but this thread in talk-us seem a proper forum for this dialog.  If, after reading this, you have similar forward-looking observations and suggestions of your own, I wish to hear those.  Including deprecating the national_park tag, while I listen as you might suggest with what we might replace it, and how.  These might align perfectly with Joseph's suggestions (though he doesn't appear to advocate for deprecation of national_park), or they might not.  I listen.Thanks,SteveA(what Joseph Eisenberg wrote):I would recommend starting to use boundary=protected_area for Stateparks, and other parks that are large natural areas that are designedfor a balance of tourism and protection of the natural environment butare not actually National Parks.https://wiki.openstreetmap.org/wiki/Tag:boundary%3Dprotected_areaYou can tag state parks like this:boundary=protected_area + protect_class=2 + protection_title="State Park"Protect Class 2 is the same type as National Parks, and will berendered and interpreted the same by most database users, but theprotection title makes it clear that it's actually a State Park, not aNational Park.For county parks: many of these are small parks that are similar to ausual urban park, with gardens, playgrounds, sports fields etc, andcan be tagged with leisure=park. Others are natural areas or naturereserves, and could use boundary=protected_area + 

Re: [Talk-us] Ashuwillticook Rail Trail in Massachusetts

[OSM Volunteer stevea]

Thanks, Kevin.  I believe it will be sorted in a month, but you never know.  
Great to have a dedicated mapper like you so willing to help, I will mention it 
if isn't sorted by then.  Kerry Irons (ACA volunteer) believes the AASHTO 
ballot process will be around "month's end" so that sketches a date for OSM / 
OCM to contain / display a completed route.  We'll get there, I think we're 
almost there.

Steve

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

Re: [Talk-us] Ashuwillticook Rail Trail in Massachusetts

[OSM Volunteer stevea]

I appreciate it!  I'm now/soon scouring more aerial/satellite imagery before I 
MIGHT (with trepidation) enter this.  I do think it would be better if locals 
who are more certain about this were to enter it.  Though if MassDOT asserts a 
USBR 7 re-route through here, "it must exist."

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

[Talk-us] Ashuwillticook Rail Trail in Massachusetts

[OSM Volunteer stevea]

Oops, USBR 7 (not 1) through the area.
SteveA


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

Re: [Talk-us] Parks in the USA, leisure=park, park:type

[OSM Volunteer stevea]

Apologies if I've already answered these.

On Apr 24, 2019, at 4:34 PM, Greg Troxel  wrote:
> I think Kevin has it right that we should tag primarily by something
> about land use, not by owne/operator, although it's fine to tag
> operator.

I 100% agree.  Yet I peruse landuse key values (except park is noted 
leisure=park, which means I'm chasing my tail so I ignore it) and find that 
none of them come close to describing "park" (the American English sense).  I 
myself have also used landuse=conservation (long ago) and/or 
leisure=nature_reserve (neither of which render, not really the point).

> I think the entire "national_park" tag is unfortunate, as it wraps up a
> lot of concepts that vary by country, and makes people understand things
> when they don't.  In the US, it should mean "preserve the land while
> allowing access and enjoyment", there is a notion that the place is
> relatively distinguished, and it doesn't really have a connotation of
> size.

Some say "size matters" with national_park, some say it's too confusing for 
size to matter.  It doesn't seem we're going to eliminate 
boundary=national_park anytime soon, as even though this shouldn't have 
mattered, it did:  this was a tag that rendered, so people used it.  (How 
rendering — presently, eventually, politically-within-OSM... — gets coupled to 
tagging is another chewy topic).

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

Re: [Talk-us] Parks in the USA, leisure=park, park:type

[OSM Volunteer stevea]

The linguist in me feels compelled to be a bit pedantic:  terms like "plain 
language" and "human language" used to distinguish between data/code/machine 
kinds of "language," including what we mean by "tagging" or "codepoint" are, I 
believe, well-expressed with the (linguistic community) phrase "natural 
language."

Much of what OSM is going through with "park" is because:

1)  leisure=park wasn't clearly defined (this is essentially the most important 
lesson),
2)  "park" has wide variation in what is meant (I have noted a distinctly 
American English dialect usage that is much more inclusive than that how OSM 
defines "park" as in 1),
3)  the drift apart between less-precise (over 15 years of tagging) usage of 
leisure=park, more-precise definition of leisure=park (which we partly say 
"what we meant all along" but others disagree, as it was less-precisely 
defined) has become severe, brought into focus as we recently made more precise 
the definition of leisure=park.  (Ostensibly to mean "what we meant all along," 
but which appears to be a significant re-definition to many, especially in the 
USA, where American English is used and its word "park" shaped the lack of 
precision definition in our wiki for the first 15 years of OSM).

Well, about there, anyway.  I think most or even all of us know this, I wanted 
to state it as explicitly as I do here.  These are my opinions, though they 
rise from long-term observation.

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

Re: [Talk-us] Parks in the USA, leisure=park, park:type

[OSM Volunteer stevea]

At today's creation of https://wiki.osm.org/wiki/Talk:Key:park:type , I 
introduce a proposal to reduce usage of the park:type tag (initially, in the 
USA) with the goal of better clarifying USA park tagging.  There are a couple 
of "low hanging fruit" tasks we might do as a pilot run, though past these easy 
ones this will require additional community interaction.  That Discussion page 
is a good place to do so.

If you think you might offer some perspective on how the many values of 
park:type (state_park, city_park, state_beach, county_park, national_forest, 
state_game_land, state_recreational_area, private_park...) might help us better 
characterize and improve USA park tagging, please take a look at the brief 
discussion initiated there.  You are invited to participate.

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

Re: [Talk-us] Parks in the USA, leisure=park, park:type

[OSM Volunteer stevea]

I do think it important we hear about distinctions between British English (and 
how it had a defining influence on much tagging in OSM), and American English, 
which I often say distinctly affected the way Americans have used the 
leisure=park tag.  "Park" in American English is much more encompassing than 
"park" in British English AND leisure=park, and whether good or bad, this 
semantic sense of the word has blurred US tagging to be wide and wild.  OK, 
enough history.  (The problem may be worldwide in OSM, with the US having its 
own quirky reasons and tangles).  Then, there is what we might do going forward.

I am heartened to see so much earnest discussion.  Yet I feel the same way 
Mateusz does when he says while thinking loudly, he is not sure "what exactly 
should be done here."  Yes.

And this is not the first time similar discussion has happened.  A result is 
things mostly grind along as they have.  Or perhaps (as with the introduction 
of the boundary=protected_area, ostensibly created as a new scheme to solve 
many things), we get MORE complexity.  I wish I didn't sound so negative or 
like I'm sowing chaos — I'm not — genuinely, I would love to see clarity 
emerge, yet it seems elusive.  Though I'll say it again:  talk, talk and more 
talk, while tedious and even exhausting sometimes, seems it's better than not 
talking, as sometimes a kernel of better understanding shakes out.  I continue 
to hold out for that here.

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

Re: [Talk-us] Parks in the USA, leisure=park, park:type

[OSM Volunteer stevea]

How much consensus IS there for tagging national_park on "large, (important?) 
state parks" which roughly (or not) meet the national_park definition in our 
wiki?

We have two in New York, quite a few in California, some in other states.  Do 
we wish to keep these as they are?  Do we rough out "rules" of when it is 
appropriate to use this tag?  I might be wrong about this, but it does seem 
that geographic size (sheer area) does play an important role in whether we 
might say "yes" or "no."  "How big" is that threshold?  (If any).

I know:  this gets chewy quickly.  Park tagging is difficult when we put things 
into categories.  We now use four tags to contain a vast universe of parks and 
park-like things, MANY of which are quite different from one another.  Can we 
improve upon this or am I simply barking at a tree?

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

Re: [Talk-us] Parks in the USA, leisure=park, park:type

[OSM Volunteer stevea]

Oops, I meant landuse=recreation_ground.  (Not landuse=recreation_area).  My 
apologies.
SteveA

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

Re: [Talk-us] Parks in the USA, leisure=park, park:type

[OSM Volunteer stevea]

James Umbanhowar  wrote:
> Just to throw another curveball in here, there is also
> leisure=nature_reserve which is frequently (occasionally?) used for the
> city/county parks that are less structured and used for hiking and
> nature appreciation.

Thanks, James.  Reiterating, when I say "Existing 4," (as "tags we use on 
park-like things"), I mean:

leisure=park
leisure=nature_reserve
boundary=national_park
boundary=protected_area

Number "4-1/2" (or a 5th) might be landuse=recreation_area, which sometimes, 
even according to its wiki, conflates with leisure=park.  But use 
landuse=recreation_area when appropriate, of course.

I hear (loud and clear) the unfortunate-ness of boundary=national_park.  I know 
an easy go-to fix might be "how about we Americans coin the boundary=state_park 
tag...".  Two things about that which I hope are enlightening.

1)  As states are as sovereign as the federal government (for purposes of 
saying "what a park is around here"), the tag boundary=national_park has rather 
widely been applied to state parks and state-park like lands.  (I know Kevin 
Kenny has made a good case for why he uses this tag on certain New York state 
"lands" of a certain sort.  And a lot of state parks in California and other 
states get this tag.

2)  Once we go down the road of state_park as a value on boundary, we'll begin 
to tag (if we already haven't, I could check taginfo) county_park, city_park, 
maybe even private_park and other oddities which "break" a strict hierarchy of 
government administration.  (My psuedo/proto-protosal of a park_level=* tag, 
with values that mimic admin_level goes here, but that's an aside).  We have 
sort of tried this with the park:type tag (noted in the Subject), and that has 
been so wide-open (since at least 2009) that it didn't even have a wiki page 
about it until I sketched in a loose one late last week.  (I'm dancing as fast 
as I can).  The park:type tag is a mess, and in my opinion should enter early 
stages of deprecation right now as I believe it is too free-form and confusing. 
 I mean, I'm all for coining tags and plastic values, but this one seems to 
have simply become overly messy.

Perhaps new tags (in addition to the Existing 4 or 5) are in order, so that we 
may better address the "unfortunateness" of boundary=national_park.  But it 
would have to be a quite-well-thought-out proposal, might NEED to include the 
concept of park_level (which can be supplemented by operator=* and/or owner=* 
tags), and should scale to the whole world of OSM, rather than be USA-specific. 
 I'm pretty sure, anyway.  Or maybe we don't need any new tags (maybe values?) 
and we simply need good "rules" (rough logical mappings, maybe tightened up 
over time, or state-by-state) to apply the Existing 4 or 5 that mappers in the 
USA agree are crystal-clear, if that's possible.

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

Re: [Talk-us] Parks in the USA, leisure=park, park:type

[OSM Volunteer stevea]

On Apr 28, 2019, at 9:27 AM, Josh Lee  wrote:
> Where is the consensus or vote? The wiki page says "Status: de facto"
> which implies that the wiki page should document *actual usage* and
> not some sort of idealist, narrow viewpoint.

Perhaps this is where I throw up my hands in exasperation.  Without 
exhaustively describing the threads, private missives, backchannel email 
discussions, hair-pulling exercises, now-stale imports (from when we had no 
Import Guidelines) and even flame-wars in the map (one in my area that has been 
a raging brush fire for a couple of weeks is now in 
truce/detente/notes-are-getting-resolved mode), "the consensus" has been 
evolving for the almost-decade I've been mapping here.

This talk-us thread is intended to address what US tagging of leisure=park 
"should better be" going forward, recognizing there is plenty of "legacy 
tagging" usage of leisure=park, often in California.  Some 
not-strictly-what-the-wiki-says and how leisure=park IS understood "around the 
OSM world" is certainly found in the US beyond California, that is quite true.  
So this topic isn't a fresh, clean sheet of paper, as much has been said and 
written.  But much confusion/misunderstanding (and legacy tagging) exists 
across the USA.

I agree that what our leisure=park wiki says, while it has been tightening up 
recently, isn't absolutely "actual usage," that isn't my fault, it is what 
thousands of contributors have tagged.  And as I've said, my inclinations as to 
why this is so is because our leisure=park wiki wasn't strictly accurate (until 
recent attempts to make it accurate) likely combined with the American English 
usage of the word "park" to be more inclusive (of park-like areas often with 
"park" in their name) than the original OSM concept/usage of leisure=park, 
which we now better wiki-document than we did before.

So, we now have better wiki (which feels fragile, as it is a new consensus, 
though it does appear to be "what we meant all along") AND we have 
legacy-tagging usage in the USA.  Rather than asking for an audit trail of how 
we got here, may we look ahead to how we'll "better" tag areas (with the 
Existing 4 tags, not just leisure=park) going forward?

I think we have "wrung out" (as largely irrelevant) the "government-level" 
semantic component as being unimportant (or we capture it with operator=* 
and/or owner=* tags), although using the specific example in the USA of "how do 
we tag a county park?" roughly asks this ticklish question — not because of 
"county" or that it is admin_level=6, but because county parks are often 
more-rural, larger, not-as-manicured "things" that we often call parks and 
which don't strictly meet how OSM means "leisure=park."

So, what emerges is that going forward, leisure=park is as our wiki describes 
it (a smaller, urban-scale, human-sculpted place for leisure/recreation), EVEN 
THOUGH many areas which aren't this are now tagged this way.  Going forward, 
NEW "parks" (in the USA) get this tag only as it is meant/now wiki-described, 
as we use the Existing 4 more properly.  In other words, it is correct to use 
the Existing 4 INSTEAD of solely leisure=park when appropriate.  
Simultaneously, it is inevitable that many now-tagged-leisure=parks will have 
that tag changed to one of the other Existing 4.  Yes?

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

Re: [Talk-us] Parks in the USA, leisure=park, park:type

[OSM Volunteer stevea]

> Jmapb  wrote:
> ...if I saw a playground on a map
> and then arrived there and found it was just an empty lot or an
> undeveloped bit of land, I would find fault with that map. So if these
> places (kids play here but it's unofficial) are to be mapped, I'd
> suggest different tagging.

I would find fault with that map, too.  Our leisure=playground clearly states 
"Often they provide equipment..." but maybe "often" could be better stated 
"nearly always."  That's my experience, though I hesitate to re-write the wiki. 
 Full disclosure, I did just propose on leisure=playground's Talk page that we 
add two simple words, "and schools" to describe areas where playgrounds are 
found, as lots of schools micro-map their campus as an OSM introduction.  
Giving a wiki-nod to playgrounds explicitly being found at schools seems 
welcoming.

> If recreation really is the primary human activity in these areas, you
> might consider landuse=recreation_ground -- though the way I read the
> wiki, it sounds like the intended use is a little more formal than the
> situations you're describing.

Yes, I considered recreation_ground as making the "Existing 4" actually 5.  
However, recreation_ground's wiki has a note in the See Also section that says 
"in many cases area is both recreation ground and a park. In such cases usual 
tagging is to add just leisure=park."  So while recreation_ground is a specific 
tag for specific uses, there are conflations to park which are both appropriate 
and recognized in the wiki.  So we sort of have "Existing 4-1/2."  There are no 
quick and easy ways to neatly put everything into buckets!


Aaron Forsythe  wrote:
...that he disagrees with my interpretation (not strict definition) of "kids 
play here."  To be clear, I am 100% in agreement with our wiki definition of 
playground as "a children's playground. These are outdoor (sometimes indoor) 
areas for children to play...".  The wiki definition's second sentence aligns 
with my interpretation/characterization, but it is not a definition of (only) 
what is included in the set, it is an elastic "these are also included" 
characterization of the set.  As I said, semantics can be tricky.

Aaron also wrote:
> On another note, there are places defined as “city parks” here that are no 
> more than land that can't really be used for anything.  For instance, a lot 
> in a subdivision that’s used for storm drainage is labeled as a nature park.  
> It's due to the fact they planted native plants on the lot to attract 
> wildlife.  You would not know it's a "park" if you didn't read the small sign 
> stating so.  It just looks like an overgrown, unleveled lot.

I've also noticed that land next to creeks, for drainage, which is too steep to 
build on, which sometimes floods...is frequently included in what 
municipalities/park agencies "call" parks, or manage as what might someday 
become a park (the "proto_park" concept I mentioned).  I've also seen 
"walkways" which are little more than a path next to a drainage (which does 
contain/attract native plants, frogs, birds), yet might be as little as ten 
feet wide but go on for hundreds of feet, and this is called a "park."

Does OSM tag these leisure=park?  "We" (the people, the Departments of 
Parks...) do, yet should we in OSM?  This IS talk-us; a major reason I brought 
this up here is that USA park tagging drifts from elsewhere as "more generous 
with the tag."  Yet the tag has recently become more precise, narrowing it from 
how it is often used in the USA.

Thanks to all who contribute to the discussion,
SteveA
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Parks in the USA, leisure=park, park:type

[OSM Volunteer stevea]

On 4/25/2019 8:39 PM, OSM Volunteer stevea wrote:
>
A hazy sort-of-emerging along with this is wider recognition that a proto_park 
thingy exists.  

And on Fri Apr 26 22:44:56 UTC 2019, Jmapb  replied:
Sounds like a good case for some lifecycle prefixes -- proposed:leisure=park or 
planned:leisure=park.

Excellent!  Yes, "lifecycle prefixes" are perfect for this.  My (careful, 
though I have "burned my fingers" using proposed before, and got spoken to by 
the DWG — the three of us had a nice lunch together — but that was years ago 
about a national mess I was cleaning up and we've straightened it out, as in 
WikiProject USBRS) experience with "proposed" is to use it on something which 
is "brought to fruition to, with or by public officials so responsible; clearly 
planned" at least and the funding is "programmed or likely to be."  That can 
get tricky, as sometimes funding lingers in limbo for a long time, like on 
California High Speed Rail (which I recently scaled back in OSM because our new 
Governor did).  But I certainly agree with your

Once park construction has begun, construction:leisure=park. And finally just 
leisure=park when it opens.

As clearly, construction only happens with funding.

Thank you for reminding us about lifecycle prefixes!

>
 I've seen kids on bikes go under fences and around things and treat "certain 
areas" just like an admittedly fully raw and completely undeveloped park, even 
though it isn't one.  Sometimes with respect, simply hiking around.  What is 
that?  Humans being human.  We should map those, accurately.

We have access=permissive, but I don't think a hole in a fence really
counts as "permissive." (I think de facto access to an area with no
fence/no signage/no enforcement *could* be called permissive.)

I, stevea, agree.  Thank you for your perspective and I hope it clarifies for 
others reading.

Other than that I can't think of any tags that would be applicable to
these sorts of situations. We tend to tag the regulations themselves,
not the extent to which they're adhered to. Certainly just calling it a
park because kids play there doesn't seem consistent with OSM standards.
We don't raise the speed limit in places where everyone speeds, or tag
bicycle=yes on ways where they're prohibited but frequently used.

No, I think leisure=playground aligns a bit more closely with "kids play here," 
though some people like snap-tight definitions, others consider things as much 
more elastic.  It's difficult to please everybody; semantics can be messy.  I'm 
glad we're better sharpening up leisure=park, it deserves more good discussion.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Parks in the USA, leisure=park, park:type

[OSM Volunteer stevea]

 Doug Peterson  wrote (about "Parks in the 
USA..."):
> It is just that there is so much variety to deal with.

I agree, it proves frustrating from an OSM perspective.  I believe partly what 
happened is OSM started in the UK, where British English is spoken and 
"typically British" concepts entered the map with tags thusly derived, like 
leisure=park.  However and simultaneously, the well established American 
English sense of "park" ("a large area of land kept in its natural state for 
recreational use," my dictionary precedes that with "US") heavily affects how 
OSM USA contributors tag leisure=park.  This divergence from its OSM semantic 
(a British English idea of "smaller, urban, human-sculpted...) into US usage 
has gotten wider for many years.

BTW, this is partly a flame war I have been having for a week or two with 
another California user (starting with a question he asked on the leisure=park 
Talk page) and now seems to be improving in its tone and sanity (call it now 
"only" a brush fire).

What seems to be "shaking out" is that we US park-tagging contributors might 
think twice before NEWLY tagging leisure=park, though now there are a LOT of 
those in our map which likely should not be leisure=park, what many say is 
correct tagging.  So we have plenty of legacy tagging of USA parks which could 
benefit from examination and considering "Did this protected_area / 
national_park / nature_reserve / wide-open somewhat-natural recreation place 
get tagged leisure=park because of how Americans call LOTS of things parks, 
which isn't really how leisure=park is meant to be used?  Or is the 
leisure=park tag OK here, though many would say it's being stretched too far to 
correctly apply?  Many county parks are like this, though as Doug says, "there 
is so much variety" — yes, as many other "things" are in that bucket, too.

Greg Troxel  wrote (about "Parks in the USA..."):
> I don't understand this.

about my
>> I can see tag leisure=park persisting on a lot of county_parks for
>> some time (forever?), yet it seems OSM's worldwide view of "park"
>> excludes them (and we tag boundary=national_park on state and national
>> parks).

What I meant is partly what I say above to Doug:  that there is a lot of legacy 
leisure=park tagging in our map in the USA which persists, may for some time 
(by sheer vastness of number), and even when each and every questionable "park" 
is addressed by careful mappers who wish to do the right thing, there appears 
now to be a wide gulf between when the tag is seen to be appropriate, vs. 
inappropriate:  I circle back again to Doug's "there is so much variety to deal 
with."  There IS muddiness of how Americans use "park" to mean so much (and 
governments, via "Parks Departments" contribute), while our wiki definitions 
endeavor to be laser-focused.  I seek clarity, and slowly we appear to be 
getting there.  This won't get fixed overnight or soon, though, that is 
obvious, although I do believe that longer-term, things will heal towards 
better, more consistent tagging.

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

[Talk-us] Parks in the USA, leisure=park, park:type

[OSM Volunteer stevea]

It may be emerging that tagging boundary=protected_area (where correct) where 
leisure=park now exists and we delete it, begins to supersede leisure=park on 
many North American now-called-parks.  I think that's OK, maybe even overdue.  
To be clear, there are plenty of "we now call them parks" which are more like 
protected_area boundary areas or maybe "it is what it is today, nothing more."

A hazy sort-of-emerging along with this is wider recognition that a proto_park 
thingy exists.  Put it in the planning departments "bin" for "department of 
parks budget, depending how much we convert protected_area into 
human-leisure-activity in the next budget or ten."  Maybe never, humanity and 
this planet can hope.  Hey, this could be a park someday if and as we improve 
it.

Ech, did I just say that's what we 'mericans do with some of our landuse 
planning?  Maybe.  I try not to get political here, rather, I endeavor to 
simply tag well.  I've seen kids on bikes go under fences and around things and 
treat "certain areas" just like an admittedly fully raw and completely 
undeveloped park, even though it isn't one.  Sometimes with respect, simply 
hiking around.  What is that?  Humans being human.  We should map those, 
accurately.

I think the greatest thing to "shake out" of this so far is that the 
leisure=park tag can (and should be) frequently be dismissed in preference to 
boundary=protected_area.  This alone will assert a great deal of sanity back 
into things around here.  Whether we invent a tag called proto_park ('cause 
there are such things, the city council just hasn't budgeted or spent the money 
to build it into a more fully human-leisure-place, yet).

Ahhh.  The more people talk about this (leisure=park tagging going away from 
where it doesn't belong), the more it feels like consensus.

SteveA

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

Re: [Talk-us] Parks in the USA, leisure=park, park:type

[OSM Volunteer stevea]

On Apr 24, 2019, at 2:05 PM, Kevin Kenny  wrote:
(a LOT about parks!  thanks, Kevin!)

> TL;DR
I tried to be brief, sorry if I wasn't.

> - Tag the land use, not the land ownership. A city, town,
> county, or state park may be virtually indistinguishable urban green
> spots, recreation grounds, nature reserves, whatever. The level of
> government that manages them may be of interest and worth tagging, but
> ought not to be the primary determinant of 'park type'.

I tag a whole heck of a lot of land USE, yet exactly HOW do I tag a typical 
"county park?"  (Mmm, there is nothing "typical" about these).  This is what we 
'mericans largely call "park" yet doesn't hew to OSM's newly freshened-up 
leisure=park, which now more strictly means "smaller manicured urban public 
greenery, shady, tidy, semi-natural places to walk within the city, likely a 
restroom, maybe a playground..." with the emphasis on "smaller" and "urban."  
County parks are often more-rural and can be quite large.  Accordingly, the 
newly-narrower leisure=park tag seems no longer an even somewhat-correct tag on 
these.  So what IS the "land use" here?  Especially when it clearly ISN'T 
leisure=park?

I do not mean to put as much emphasis on "level of government which administers 
the park" as people take here:  it's almost a non-issue and can be fully 
captured by operator=* and/or owner=* tags:  if they better clarify, use these. 
 The park_level tag is an old idea of mine we might resurrect to aid in better 
rendering park boundaries if we so choose, that's all it would be good for, 
same as admin_level acts today.  (There are places, especially in far northern 
California, where visually parsing the cacophony of different park jurisdiction 
boundaries would greatly benefit by semiotic aids to do so).

> I think that the Wiki definition leaves a lot to be desired, and I'm
> groping in a fog, much as you are, so please don't take anything that
> I say here as a confrontational pronouncement.

I'm glad to hear you grope, too, as I know you've had a lot of interaction with 
these taggings and what might be done about them.  As I've said, it's a chewy 
problem.

> My read on "urban/municipal" is that it describes setting and land
> use, rather than the operator. To me a "park" in a
> urban/suburban/front-country setting connotes a certain type of
> facilities. It will likely have adequate parking, or else access to
> public transportation. It will likely have public toilets.

Right, this is what I meant by "admin_level=8, LARGELY" as leaving that wiggle 
room is truly required:  it isn't ALWAYS the city parks department that will 
operate every single leisure=park in a given city.  Still, look at how vague is 
talking about "setting."  That's difficult to agree upon right out of the gate. 
 (I'm not complaining, merely re-stating the difficulty of articulating the 
problem, even as we do our best to tease out what we mean).

> ...these features make for what is essentially a human landscape...definitely 
> human-sculpted.

This is a potentially excellent addition to the leisure=park wiki, as you do 
capture an important semantic with this.  Thank you.

> A 'national park' ... (is contradistinguished) to...the rest of the zoo of
> NPS-managed facilities)

But you actually seem to glom them together because of their many similarities. 
 I agree these seem much more similar than they do different.  Still, we are 
left with "national parks" (and things which are so much like them that the tag 
might fit well, more-or-less), leisure=park (which we agree "we know them when 
we see them," yet are hand-wavy vague beyond what we now say in its wiki) and 
this great big slew of "other things called parks" which largely happen to be 
things like county parks, county beaches and similar ilk, which do NOT fit 
(neatly or otherwise) into those two categories.  Hence, the conundrum 
continues.  Especially as I ask again, what IS the "land use" on these?

> It's common for large 'parks' (suitable) to introduce beginners...

This is (almost?) yet another category of (loosely stated) "park," perhaps "a 
kind of human recreation area" which perhaps we have yet to well categorize and 
tag thusly.


> 'Nature reserve' covers a lot of things...particularly in North America

It does seem N.A. does things differently than others in OSM and the greater 
world, but it may be that I simply haven't done enough homework or traveling to 
fully and more correctly state that.  This (parochialism, regionalism) may be a 
primary source of our difficulty.  (I have been to three continents, but of 
course I haven't been to nor do I know everywhere — I more and more rely upon 
OSM for that!)

> ...forests and (effective) game reserves.

Thank you, this offers crucial knowledge which definitely should be expressed 
in precision OSM tagging.  I know you do your best to achieve that where you 
map.  We should all strive to do so well at tagging, which is what many see as 
a topical 

Re: [Talk-us] Parks in the USA, leisure=park, park:type

[OSM Volunteer stevea]

A brief update:  I have blown the dust off of a relevant wiki, 
https://wiki.osm.org/wiki/WikiProject_United_States_Public_Lands , started over 
eight years ago and hardly touched since then.  As originally written, this 
addressed federal (admin_level=2) public lands only.  Mainly, it still does, 
though my recent "beefing up" of it does begin to edge into state parks 
(admin_level=4) also having consensus that boundary=national_park is an 
appropriate tag.  As it also mentions that leisure=park (admin_level=8, 
largely) is appropriate on "urban" (municipal) parks, it reveals the obvious 
hole:  OSM in the USA has yet to tackle the now-difficult question of what to 
do on "county parks" (and county beaches, etc.) at admin_level=6.

So, that wiki might be the primary place to discuss, enrich, contribute ideas.  
There are links there to the (just born) park:type wiki, which seems that while 
it may live on as a "crutch" tagging style (there are thousands of examples in 
use), park:type should eventually move towards deprecation as better consensus 
emerges.

Please at least read this brief wiki and think about how we might better tag 
county parks.

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

[Talk-us] Parks in the USA, leisure=park, park:type

[OSM Volunteer stevea]

I'll try to be brief, but there's a decade of history.  The leisure=park wiki 
recently improved to better state it means "an urban/municipal" park, while 
boundary=national_park (or perhaps leisure=nature_reserve, maybe 
boundary=protected_area) works on large, national (and state or provincial in 
North America) parks.  As the sharper wiki focus means a "city_park" (a 
sometimes-found park:type value, I've written brand new wiki on park:type) 
certainly qualifies as a leisure=park, this leaves county_parks (and their ilk, 
like county_beaches) in a quirky "how best do we tag these now?" quandary.

We could be unanimous that all US Department of the Interior, National Park 
Service "parks" gets boundary=national_park.  We have very strong consensus 
that boundary=national_park belongs on state_parks, too (states being as 
sovereign as the US).  We keep leisure=park on city_parks.  Yet how do we tag 
county parks?

At the park:type wiki, I discuss (though do not call for a formal vote) a new 
park_level tag, mimicking values from the admin_level of the level of 
government which operates the park (this doesn't preclude owner=* and 
operator=* tags on "parks," it could supplement them).  It seems park:type 
could/should deprecate, yet county-level parks are pesky with our "new park 
wiki" together with the "older, largely done in the Western USA" kind of park 
tagging.

I can see tag leisure=park persisting on a lot of county_parks for some time 
(forever?), yet it seems OSM's worldwide view of "park" excludes them (and we 
tag boundary=national_park on state and national parks).

This could get tedious, but it seems it has to be discussed.

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

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

[OSM Volunteer stevea]

FWIW, I believe these TIGER tags have exceedingly low value in OSM:  
approaching or at zero.  I say this because of a large/wide/far-reaching 
consensus we have reached with "similar" values in the USA on 
boundary=admin_level tags, where such entities were not only found to not be 
admin_levels (e.g. school districts and special districts are not those), but 
also that a taginfo query found that out of millions of boundary tag entries, 
fewer than a dozen of them were boundary=school.  The myriad flavors of special 
districts are similar:  few entries and low value to OSM.

The usage of a tag (via taginfo) does give some indication of its usefulness 
(e.g. school can't be that important a boundary tag if there are only nine or 
ten of them in all of OSM), unless massive numbers of them were imported, as 
from TIGER and these MTFCC and FUNCSTAT crufty stuff.  But when we can hardly 
figure them out (although Kenny did a great job explaining what they MIGHT 
mean) AND they are from a "hoary old import" (as TIGER is often called), there 
really is good argument to remove them.  I'd vote to do so in a heartbeat (if 
were collecting votes, and we don't appear to be doing so).  Hence, my 
logic-outline instead.  If they are essentially useless — and many seem to 
agree they are — I believe it is prudent to remove them.

SteveA
California

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

Re: [Talk-us] Rails-to-Trails data

[OSM Volunteer stevea]

An update.  Seeing Mark's recent post about is_in reminded me that it has been 
two weeks since I politely asked the Rails-To-Trails Conservancy to donate to 
OSM the same trail data they donated to Google Maps.  I did receive a reply 
that my message was forwarded to their "TrailLink group that handles all GIS 
data, you should hear back from someone soon."  However, as of 3/20 (today), 
nothing.  Yes, I checked my Spam folder, still nothing.

For years (2012-2015) I used to get a monthly e-newsletter (email) from 
railstotrails.org, but then in March, 2015 these mysteriously stopped arriving. 
 Fingers crossed this request goes somewhere, these really are choice data and 
will help OSM in the USA be a map containing yet more excellent hiking and 
biking trails.

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

Re: [Talk-us] Online mappy hour

[OSM Volunteer stevea]

I believe I can make that date and time!  (I do use zoom.us with clients (though I don't / won't use Slack and other proprietary tools) ; THANK YOU for making a dial-in option available for those who tend towards Luddite / more open / old-fashioned comm methods).  Of course, I'm assuming you'll let us know (here?) the zoom credentials and/or a conference call phone #.And, I look forward to the camaraderie of a mappy hour!  Fantastic this is cranking back up!SteveA

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

Re: [Talk-us] motel vs. hotel

[OSM Volunteer stevea]

As I believe the etymology of the word "motel" (circa 1920s) is a contraction 
of "motor hotel," I believe it is fair to say that a motel is a hotel which 
caters to motorists.  That is, patrons who arrive in an automobile and wish for 
it to be immediately accessible, as in parked directly outside the room in the 
case of a single story facility, or very nearby for multiple story.

Others say hotels are "closer to an airport or business district" and while 
this is a more general criterion, (think of resort hotels where you do not 
arrive in your automobile as an exception, for example), I believe that "caters 
to motorists" is the defining difference for motels.

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

Re: [Talk-us] Rails-to-Trails data

[OSM Volunteer stevea]

While I'm not sure the email address from their website I used is exactly 
correct, I did make this request to RTC (and cc'd Richard).  I'll let people 
know here if or how they reply.

Cheers,
SteveA
California

On Mar 6, 2019, at 4:00 AM, Richard Fairhurst  wrote:
> Hi all,
> 
> I see that Rails-to-Trails Conservancy donated their GIS data to Google:
> 
> https://www.railstotrails.org/our-work/trail-mapping-and-gis/
> 
> Anyone in the US fancy asking if they might do the same for OSM? Our coverage 
> is good on the major trails (Katy Trail, Coeur d'Alenes, etc.), but often 
> missing for smaller or less frequented trails, and I believe RTC have some 
> metadata (surfaces etc.) it'd be good to have. Since most cycling apps and 
> websites use OSM data it should be a win for RTC to have better data in OSM.
> 
> I'm happy to approach them if no-one else does, but it'd probably be better 
> coming from, you know, someone on the same continent.
> 
> cheers
> Richard



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

Re: [Talk-us] Proposed mechanical edit - elimination of old-style Wikipedia links in USA

[OSM Volunteer stevea]

I'm OK with this as well.  I especially wish to call to the attention to others 
who may do mechanical wiki edits like this (by Mateusz' good example) that he 
was careful to:

1)  Explain the problem; it confuses mappers/map consumers and wiki 
authors/readers,
2)  Offer a polite proposal as well as taking ownership for any potential 
problems with it,
3)  Have wiki-oriented documentation of this (and here is the link),
4)  Say that this was done on a "smaller" (though still countrywide!) scale, 
and it worked.

Outstanding!  Thank you, Mateusz for your example of wiki, talk page and 
community communication.  OSM has every reason to support such excellent 
suggestions/proposals.

SteveA
California


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

Re: [Talk-us] The San Jose / Santa Clara border

[OSM Volunteer stevea]

(Lengthy reply alert)
Hi Minh:

Thanks for your (always thorough and well-researched) pointers and history — 
though I don't recall "impressing LAFCO" upon you, I did mention it in the 
context of admin_level, so, OK, whatever!  Good for Santa Clara LAFCO for 
publishing municipal boundaries into the PD.  I am again thankful we live in a 
state with excellent public data in the PD along with our "sunshine laws."

I like that you made Seven Trees an admin_level=10 for reasons you did, even as 
you've described other SJ neighborhoods as "amorphous" (exactly the right word, 
imo!)  I wouldn't have noticed had you not sent me links [1].

"Urban islands as a LAFCO high priority to streamline" is something I've never 
heard of before.  Notwithstanding the letter LAFCO sent City of San José nearly 
eight years ago [3], I believe it is the City of San José itself which "serves 
as the authority on" its own municipal boundary.  LAFCO might have something to 
say (keeping accurate maps / GIS data, for example) about all cities in Santa 
Clara County, but I don't think anyone contends that LAFCO doesn't define 
municipal boundaries, the cities themselves do.  Indeed, LAFCO's letter says it 
can "encourage" annexations (of islands) and waive its fees (to incentivize a 
"streamlined process" for islands 150 acres or less) but it cannot force a city 
to do so, whether this is a "high priority" for the LAFCO or not.

Using link [4] and blending with the instant topic (which I volunteered to 
remedy), I examined the five pages of City of Santa Clara.  The first four 
(pages 45-48) are "islands" which share a boundary with City of San José (the 
fifth is an island solely inside of the City of Santa Clara).  None of these 
involve the area around the airport / Westfield Valley Fair, which was Andy 
Townsend's "area of concern," prompting me to answer that I'd take a look.  
(SC05, page 48, is pretty close, but is north of the airport and involves a 
creek edge near Trimble and Orchard).  Those four "islands" probably could be 
used to (rather crudely) "hand draw modify" the Santa Clara City Limit boundary 
in OSM (relation 2221647) but it isn't clear to me how what these maps define 
as Urban Service Boundary is or isn't the actual city limit boundary for Santa 
Clara.  As I think about it, the identification of these four islands (the 
fifth might become an "inner" member of that relation) in this document COULD 
be used to exclude these islands from the City Limit, but I'm not sure that is 
accurate (it likely is, I'm simply not sure).  So while these resources might 
qualify as "interesting," I don't find them wholly relevant to what I 
volunteered to do "near the airport."

However, links [5] and especially [6] yield dense, recent, tasty data.  Having 
used ArcGIS layers before like this (largely while mapping to fix TIGER rail), 
I can set a basemap of OSM while viewing these data.  Doing so allows me to 
find where there are some relatively minor differences, so I elected to fix 
these, "manually" using JOSM.

These (minor) changes were along the "grass edge" NW of the 101-Trimble 
interchange, westerly to the UP Coast Subdivision rail bridge crossing 101, 
southerly to just north of Central Expressway (not south, a significant change 
making OSM's representation of CE W of Trimble/De La Cruz to the rail bridge 
now in Santa Clara, not San José).  This continues easterly across Trimble into 
the airport, as far as Taxiway Y, includes better-traced (though likely not 
perfectly accurate) rectangular and triangular areas of northern portions of 
runways and taxiways, south along De La Cruz and excludes Memorial Cross Park 
(in San José, not Santa Clara).  The barrier=fence had to be node-by-node 
unglued from the city limit (but kept glued to the parking lot) to be better 
characterized as "along Martin Avenue" (and so was), SE on Martin Avenue (with 
some "jogs") to a bit further SE on Aviation Avenue, southerly (with "jogs") to 
Campbell Avenue near Stephen Schott Stadium.

From there, the boundary needed to be moved easterly by about 10 meters, so it 
was, past Sherwood and along Portola Avenue.  Adjustments were made to better 
align with The Alameda, past Morse and Idaho and to I-880, where a 90-degree 
westerly boundary continues to Newhall and Monroe, where as it follows the 
southern boundary of Santa Clara Mission Cemetery, it is correct (enough for 
now).

The ways I changed have IDs 166659029 and 97341711 (recently reverted by Andy 
Townsend), part of the Santa Clara (city) municipal boundary relation.  I 
believe this is moderately better, which is "moderately better."

SteveA

> From: Minh Nguyen 
> Subject: Re: [Talk-us] The San Jose / Santa Clara border
> Date: January 28, 2019 at 5:06:15

Re: [Talk-us] The San Jose / Santa Clara border

[OSM Volunteer stevea]

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

Re: [Talk-us] US Bureau of Land Management Boundaries

[OSM Volunteer stevea]

On January 6, 2019 at 7:50:44 AM PST, brad  wrote:
> 
> Joseph,   I'm not stuck on class 27, but as you say, that fits the definition 
> on the wiki.   I should probably look for other specific protection in the 
> attributes and translate that somehow.   Mostly it's just grazing and 
> recreation land.   Anything such as wilderness or monument would definitely 
> be tagged as such.

I agree with this approach, especially "look for other...attributes and 
translate (them)."  However, this is not something Brad "should probably" do, 
it MUST be done to correctly import these data:  each parcel must be examined 
as to its landuse (in the generic sense, not the OSM tag) and assigned an 
appropriate protect_class, especially if it is not 27.  The protect_class key 
may not render today (though, Carto will hopefully "fix" this with likely 
progressively improving methods in the future), that is a separate issue I 
specifically point out so additional tags (such as leisure=nature_reserve) do 
not get added superfluously ("tagging for the renderer") to make them "appear." 
 Beware this slippery slope, knowing that even a perfect, completed BLM import 
will (today) be essentially invisible in virtually all renderers.  The data 
being in the map is a good goal, even while rendering them can be put off until 
another day (though, not forever).

> Martijn,  Gaia is not available on a Garmin, or on a PC.  It also costs $40 a 
> yr.   Why do you trust Gaia as an authoritative source?   How often do they 
> update from government sources?   BLM boundaries do not change very often.  
> Probably less often than city/town boundaries. For an authoritative 
> source, I have national forest maps that are 10 - 20 years old.  A download 
> today from a federal database is way better than that and in 5 years will 
> probably still be just as good.In relatively sparsely populated areas, on 
> the ground verification does not work as well as it does in the city.If 
> we make OSM more useful for more people then more folks will get involved.

As a segue from my recent comments on USA rail being about 40% done (over a 
decade since their nationwide TIGER import), with such challenges (importing 
nationwide data such as BLM boundaries) come great responsibilities.  To 
repeat:  we imported "all" (that TIGER had) of US railroad data and here we 
are, eleven, twelve years later at about 40% completion of reviewing, improving 
and reporting on their status.  Such nationwide tasks (in the USA) are 
Herculean efforts, though breaking things up into wikis / efforts at a state 
level has proven effective (if relatively slow, it does make logical sense 
given state DOTs create rail inventory / planning reports every so often, which 
help a lot).  Should this BLM data import progress, Brad needs to know how 
large an elephant this is to eat.  I began similar importation of national 
forest (and wilderness, national grassland...) data in California between 
2012-3 but abandoned doing so, as the effort simply overwhelmed my ability to 
either do this myself or do it with the coordinated effort of other OSM 
volunteers.  I cannot emphasize this enough:  to do and manage these kinds of 
national-level data management tasks is an absolutely huge undertaking and I 
speak from extensive experience at either attempting or (partially, 
successfully, unsuccessfully) completing two or three of them (national rail, 
national bicycle routes, NF/Wilderness/BLM/other federal lands).

> Michael,   You bring up some good questions which I don't have the answer for 
> yet.   I would get started with what you call the low road, state sized or 
> smaller pieces at a time.  A quick look at the boundaries around me show none 
> that follow a watercourse or a ridge, they are all straight lines and and 
> square corners.  The extraneous ways at state boundaries look like artifacts 
> from cutting up a larger database into state size chunks.  There was no 
> polygon, or a skinny polygon associated with those artifacts.  I'm guessing 
> that there is BLM land in the adjacent state.

I enthusiastically encourage an initial pilot project of a single 
state-at-a-time's worth of data.  It is far easier to scale up (or abandon) 
something you can bite and chew (and swallow and digest) rather than try to 
scale down a disastrous import that is so large you (and OSM) choke on it.

> Dave, Thanks for being a voice of reason!  

I also agree with Dave's and Brad's assertions that these data belong in OSM.  
Publicly-owned BLM lands afford numerous recreational, educational and other 
opportunities, similar to leisure=park, leisure=nature_reserve and related 
areas.  Denoting where these are with recent federally published data is in 
complete harmony with other sorts of boundaries in OSM.  But there is wishing 
or agreeing that the data belong, then there is doing a high quality job of 
importing and maintaining them.  The former is relatively easy, the latter is 

Re: [Talk-us] Rail Easterly

[OSM Volunteer stevea]

On Dec 21, 2018, at 4:17 PM, OSM Volunteer stevea  
wrote:
> (Hawai'i, our national page says light_rail is "westerly portion is under 
> construction."  Updates?)

OK, I updated our Hawaii wiki so it has a Railroads section and table.  A 
dedicated Hawaii/Railroads wiki seemed a bit much, given there is only minor 
passenger rail and some light_rail construction there.

> * wiki to reflect that status in color-coded tables, "all Western states" 
> (save Hawai'i) roughly done

OSM now has "all Western states" pretty much covered with rail wiki (again, 
"roughly done"), Hawaii included.

Happy New Year,

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

[Talk-us] Rail Easterly

[OSM Volunteer stevea]

In 2013 OpenRailwayMap was released.  After 2014 talk-us posts about "Rail 
Westerly" I spoke at SOTM-US Seattle in 2016 about Rail USA during a theme of 
building community.

Let's call Rail USA today (a decade after our mid-2000s rail import) a version 
0.4.  This includes:

* a certain amount of TIGER Review of our rail import is substantial, though 
still plenty to do,
* wiki to reflect that status in color-coded tables, "all Western states" (save 
Hawai'i) roughly done, and
* the actual state of USA rail data in OSM (completion, correctness).  "Looks 
OK" at a macro-level.

(Hawai'i, our national page says light_rail is "westerly portion is under 
construction."  Updates?)

Viewed in OpenRailwayMap, our TIGER data continue to improve, especially over 
the last months and years, demonstrating solid progress:  improvement, 
cohesion, inventory, status, upgrades, relatively recent data and status.

I estimate USA rail which is "somewhat TIGER Reviewed" (as well as the state of 
the wiki describing them) at about 35% to 40% complete today, but that is a 
loose number with hundreds of thousands of miles of ways with railway=rail (the 
largest active and abandoned rail network on Earth).  These numbers might be 
higher "locally," so for example perhaps 60% completion is a reasonable 
estimate of data, wiki and "completeness" status in California.

OSM-US' rail has enjoyed good growth.  Wiki demonstrate both inventory and a 
status of completion of any given state's TIGER Review and have been doing 
steady work (and can keep doing so, or improve) of "reviewed by multiple sets 
of eyes."  A visual parse (wiki syntax and some color/graphic symbols) is 
underway in Arizona to succinctly visually describe this on a 0 to 4 scale, 4 
is "multiple eyes reviewed these data."  (On passenger routes, this might get 
adopted for freight rail).  Wiki might also "fall away" as data in the map and 
good tools watch data in a more real-time way.  Wiki have and do serve 
"inventory and status," especially with widespread improvement.  (Underlying 
infrastructure, better tagging, gathering of subdivision rail elements into 
relations, TIGER Review, updating tables in the wiki with up-to-date 
status...), though that might change,  (Wiki as status, the way it helps us 
discover each other, "building community" and inventory... gets supplanted?  
well, possible, yes).

The Western states have at least skeletal wiki (some are beta with up-to-date 
status).  Some Eastern states have skeletal wiki, though there is much more 
TIGER rail Review to complete, and depending on where and how it goes, wiki to 
be written.  Getting to a version 1.0 of rail in the USA "done" in some sense 
might be three, five or ten years hence, that's hard to say.  In that we might 
include:

* fully multiple-human review of all TIGER rail, sufficient to remove the 
tiger:reviewed tag.  The improvement we have seen between 2014 and 2018 is 
substantial.
* final (neither alpha nor beta) wiki (as our 
WikiProject_United_States_railways page defines these)
or perhaps a preferred functional equivalent of that, as in the 2020s it might 
be "this is how we keep an eye on rail now."

North Dakota, Nebraska, Kansas are the next wiki-less states (Western becomes 
Eastern, marching south from Canada down the center of the lower 48).   A 
handoff feels "next underway.".  A "certain amount of skeleton exists in the 
data across the lower 48" so "here ya go, Eastern Rail USA."  An "on to version 
0.5" of "Rail Easterly" seems to click in now.  For example, much happens in 
the Northeast Corridor, several high-speed plans and higher-speed corridors 
(Michigan, Rhode Island) where there are many vibrant data, Crescent Corridor, 
all kind of things.  Heck, I think South Carolina, a place you might not 
consider a universe unto itself regarding "a state's worth of rail," is quite a 
bit to chew, really!  Other OSM volunteers are better equipped and more local 
to improve these data and/or their wiki (should those get written or not).

Almost a decade in OSM, chugging along, workin' on the railroads, maybe a third 
of states roughed out, we're doin' fine, volunteers are welcome, maybe you'll 
help make it three years instead of five or ten,

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

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

[OSM Volunteer stevea]

Eric Ladner  wrote
> That may be more of a note to motorists that "hey.. this freeway is coming to 
> an end" rather than an absolute marker of "this freeway ends here at this 
> sign".  San Diego's own GIS system has it marked as I-8 all the way up to 
> where it splits into motorway links at Nimitz/Sunset Cliffs.

Having grown up there and surfed Ocean Beach and Pacific Beach many times, yes.

> Arguing about where the motorway ends and a trunk/something else begins 
> before an at-grade intersection is just splitting hairs.   IMO, it's a 
> motorway all the way up to the intersection.  If you were standing with your 
> back to the intersection looking down the motorway, there'd be nothing 
> visible that would convince you it's not a motorway.

According to Caltrans, the term "freeway" refers to a route that is restricted 
in access and does not have cross traffic.

"End Freeway" simply means that a route that has been restricted in access and 
free of cross traffic for the last number of miles has come to an end, said 
Caltrans spokeswoman Reid.

Although the route will often continue "well-maintained" and "free" for a while 
more, drivers should look for cross traffic and traffic lights just ahead, she 
said.

This is from the Los Angeles Times' "Traffic Talk" column, August 30, 1996.  
And yes, I know for a fact (from having driven millions of miles of California 
Highway and recently passing my written license test again) that a "white sign 
with black text is a regulatory sign," meaning "by law, beginning where this 
sign is placed, forward."

In Santa Cruz, there is about 50 meters of highway=trunk between Highway 17 
(freeway, motorway) and where 17 ends at signalized Ocean Street 
(highway=primary).  At first I was nonplussed about this being so tagged in 
OSM, but as I remembered where the regulatory (therefore, by law) "End Freeway" 
sign is (confirming it today), it actually is tagged correctly.

So, Eric is correct on both counts:  it is "hey, this freeway is coming to an 
end" AND it is "this freeway ends here at this sign."

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

Re: [Talk-us] Strange city boundary: Lee, Illinois

[OSM Volunteer stevea]

I've seen 25or6to4's work, I am impressed.  Furthermore, I've asked him 
(off-list) if he would be willing to share his work more widely (here on 
talk-us), as it may "spark" a wider launch into the sort of clean-up of 
tiger:LSAD=57 data I've been waiting to see happen.  (Their 
boundary=administrative tags are changed to boundary=census and their 
admin_level=8 tags are deleted.  I think we want to exclude Alaska from this).

And, of course, I agree with you that this community is awesome!

Yes, TIGER cleanup continues, TIGER cleanup will continue (and continue, and 
continue...) and one fine day we will drive the last wooden stake into its 
heart.  TIGER data were and are helpful, yet they continue to need tender, 
loving mapping from our awesome community, likely for years to come.  A fresh 
cat box is a beautiful thing, ask any cat.

SteveA
California

> On Nov 14, 2018, at 2:06 PM, Martijn van Exel  wrote:
> 
> Hi all, 
> 
> User 25or6to4 contacted me offline mentioning that he has been working on 
> improving boundaries based on newer TIGER for the past months now. That, 
> taken together with the boundless (ha) energy exuding from this thread, makes 
> me have a very happy boundary-positive attitude! I’m not much of a boundary 
> editor myself, but fortunately we all have our favorite topics. This 
> community is awesome. 
> 
> Martijn 

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

Re: [Talk-us] Strange city boundary: Lee, Illinois

[OSM Volunteer stevea]

Carl Anderson is correct:  what is in the map from TIGER about LSAD is true and 
affords the possibly to derive geo data about incorporated entities (in some 
cases, where they haven't been deleted), although the data (being somewhere 
between 11 and 13 years old) may not be accurate, given annexations, etc.  
However, OSM's community, through exhaustive consensus (much of it right here 
on talk-us, many of these discussions are ref'd in a wiki I noted earlier) 
agree that what the US Census Bureau says is not necessarily what OSM does or 
should use to document such entities.  In other words, the Census Bureau is not 
authoritative.  For what we agree to put into OSM, the OSM community's 
consensus IS authoritative.  We have agreed that census boundaries of CDPs are 
statistical, not administrative (what admin_level attempts to denote).  We 
correctly document how to do this.  However, MUCH old TIGER data remain.

Martijn, your OT link is helpful, here is a visual version:  
http://overpass-turbo.eu/s/DG5 (although that does not allow "census.gov" to 
appear as often as your text-based version does, so thank you for that 
formatting).  What this shows is that the importation of much Census Bureau 
data as CDPs in Utah (and elsewhere in the USA) continues to have MUCH work to 
do:  our wiki suggests admin_level=8 tag be removed from these, and the 
boundary=administrative tag be changed to boundary=census.  This is correct, it 
has achieved wide consensus in OSM (via these talk-us pages) and has been 
documented in our wiki for some time.  And not simply in Utah, this is true in 
all 50 states, except Alaska, where the state works closely with the Census 
Bureau to "organize" (not in the legal sense) the Unorganized Borough of Alaska 
(bigger than any other state, even Texas).  Carl offers a clever way for us to 
sharpen up how we might do this:  choose admin_level=8 tagged relations which 
have tiger:LSAD=57 (e.g. Mona, Utah), change boundary=administrative to 
boundary=census, and delete the admin_level=8 tag.  Import script, anyone?  
(Whew, that's a loaded question!)

However, I disagree with Martijn (or perhaps I do not understand his intention) 
as he says about our US_admin_level wiki "United_States_admin_level is really 
not correct... CDPs should be tagged boundary=census, ideally without an 
admin_level=* tag."  I believe that IS a correct statement, it is simply that 
Utah (and many other states, again, not Alaska) have never had this "clean up" 
done.

Martijn's assertion that "state municipalities: cities, towns, villages and 
hamlets (infrequent)” is an incorrect description of what we INTEND to denote 
with admin_level=8 in the USA is also incorrect.  Simply said, hoary old TIGER 
data contradicts this true statement on a fairly large scale, in Utah, yes, but 
in most other states, too.

Let's not confuse what's in the map (from a noisy TIGER import) as correct, 
when what really is correct is what we have achieved consensus about and 
wiki-documented:  CDP data are boundary=census, not boundary=administrative 
(and so, should have NO admin_level key, with any value).

And, I'd much rather have "too much" wiki than "not enough."  Wiki can be 
ignored if too verbose, however, the consensus such wiki express is not easily 
conjured.

Where I agree with Martijn is "I guess we have some work to do."  "Clean the 
catbox" indeed!

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

[Talk-us] Strange city boundary: Lee, Illinois

[OSM Volunteer stevea]

A lot of people have (quickly) chimed in about this; political boundaries, 
admin_level and cities extending into counties usually gets to be a "hot" topic 
as people have a lot to say or strong opinions on these.

I and others recognized this years ago and what has emerged in OSM are two 
wikis, one on admin_level in the US, the other on "boundaries."  The former is 
quite comprehensive, perhaps it could be called "prescriptive" (here is how we 
SHOULD tag) and almost begins to approach a master's thesis in political 
science.  (OK, I exaggerate a bit).  The latter is more "novice-oriented," has 
user-friendly graphics and is what might called "quick and easy," it is 
certainly more "descriptive" (here is how we DO tag).  Both wikis have "settled 
down" in the last six to eight months, affording us some stability for 
reflection.  I think the many authors of these like where they have "landed," 
and the community doesn't seem to be changing them or discussing them as if 
they need (much) further change.

These are, respectively:

https://wiki.openstreetmap.org/wiki/United_States_admin_level
and
https://wiki.openstreetmap.org/wiki/WikiProject_United_States/Boundaries

They both point to each other.  The first one has extensive footnotes.  The 
"Consolidated city-counties, Independent cities" section mentions that Dallas, 
Texas even extends over FIVE counties, and links (click on "hundreds of US 
cities") to wikipedia article 
http://en.wikipedia.org/wiki/List_of_U.S._municipalities_in_multiple_counties 
that further explains this.

We have patient, open-minded and dedicated-to-getting-it-right wiki authors in 
this project who create and update comprehensive and friendly wiki.  Thank you 
to all of them.  I know my OSM experience would not be anywhere near as rich if 
I didn't have so much excellent wiki to read.

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

Re: [Talk-us] California is too big ;)

[OSM Volunteer stevea]

Reminding everybody that whatever Frederik decides to do about California, it 
isn't "authoritative," simply helpful to keep OSM data manageable.  Sure, 
keeping "a solution" logical, simple, "politically correct" and achieving some 
consensus (as we have) are all helpful towards that goal, but nobody wins or 
loses here.

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

Re: [Talk-us] California is too big ;)

[OSM Volunteer stevea]

Simon Poole  wrote:
> I think the question is less where N vs S California is but more if
> there is a regional split of California that would make sense from a
> processing pov. Is for example somebody likely to do something with a
> North-CA extract, or if you would want to do something on a smaller
> scale, would that clearly be at a county level. Frederik is likely to
> groan at that idea, but some how I suspect that CA county level extracts
> would be comparable with states in other countries.

Simon, I hear you, yet "processing" is what would happen data-wise after this 
split, yet it's also what Californians do in their brains when they hear of or 
think of "Northern"  vs. "Southern:"  we tend to think right around that 
"pretty close to straight line" (it's not, though it's darn close, and it looks 
straight on a larger-scale county map) we are all huddling around as "about" 
where the chop is or should be.  Remember, Frederik's ask is for a sensible 
methodology to break apart something that is now or soon "too big."  Basic 
computer science implies a binary "chop it in half" approach (for now, we can 
do this again, and again...), which is exactly what we're doing.

And, nothing stops anybody from "drilling down" to a county level (or deeper) 
if, as you say, they want to "do something smaller."

I'm a couple of counties away from SLO and know people who live there, work 
there and go to university there; SLO really is a "could go either way" case, 
which makes it a good place to at least start to define (beginning at the 
ocean) a "north-south boundary" of sorts (the only sort of binary chop that 
makes sense:  nobody realistically talks about "Western California" or "Eastern 
California" though "the coast" is both a useful demographic/population concept 
and a geographical reality, however, much fuzzier about "how far inland" is 
meant by "the coast").

Taken "straight across the state" (west to east), following the political 
boundaries of "the northern edges of three counties" (admin_level=6) to break 
up a state (admin_level=4), it's both easy (technically, simply "10 counties 
out of 58" or "northern edges of three counties"), agreeable by many, a 
political reality right now, mostly straight along a similar latitude line and 
already somewhat harmonious among the relatively small sample of people here on 
this list who have something to say about it.  (Not that we're definitive, nor 
am I, personally).  But, look, we did come to a rough consensus on a relatively 
simple solution rather quickly and easily.

I say "we've thrown it against the wall, and it seems to stick."  (Though of 
course, more discussion is welcome).

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

Re: [Talk-us] California is too big ;)

[OSM Volunteer stevea]

Bradley White  wrote:
> I would suggest splitting into North & South along the northern edge
> of the SLO/Kern/San Bernardino county lines as the first step; this
> will at least split the LA and SF Bay areas into separate files, both
> of which I assume account for a significant portion of CA's data.

Exactly what I proposed, but Bradley said it in fewer words (thanks, Bradley), 
something I often find challenging.

The "10 counties + 48 counties" (Southern California and Northern California, 
respectively) method I described is the same thing, it's along northern edges 
of San Luis Obispo, Kern and San Bernardino counties.

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

Re: [Talk-us] California is too big ;)

[OSM Volunteer stevea]

On Nov 6, 2018,at 12:38:05 AM PST, Frederik Ramm  wrote:
> ...on the Geofabrik download server, we usually split up countries into
> sub-regions once their single .osm.pbf has gone over a certain size. The
> aim is to make it easy for people to work with data just for their
> region, even on lower-spec hardware where it might be difficult to
> handle huge files.
> ...but after that,
> for the first time ever, a second-level entity (California) will be
> larger than all not-yet-split countries.
> 
> So I wonder:
> 
> 1. is there already a site where someone interested in only a subset of
> California can download current data and potentially also daily diffs?

Whether you know this or not, your algorithm of "splitting" makes too much 
sense to ignore, especially as there really are those with older hardware and 
"making geographic entities 'bite-sized'" is a technical reality, hence 
necessity.  The data are otherwise simply too large.

> 2. is there a demand for this?

Not by me, but that doesn't mean it doesn't exist, it VERY likely does exist.  
Let's keep OSM "human sized" by making the data that reasonable people and 
reasonable hardware/software toolchains can handle "bite sized," lest we and 
our machines choke on too much data.

> 3. what would be a sensible way to split California - in 58 counties, or
> maybe just go with SoCal and NorCal for now?

I haven't known personally that this "splitting" goes on in OSM (planet.osm 
becoming a smaller .osm or .osm.pbf), but it makes perfect technical sense.

And while I read and understand Vivek Bansal's suggestion about "six 
Californias" and Tod Fitch's "I detest this" (incidentally, I "detest this," 
too), I have suggestion which is likely easier, more "politically simple" and I 
believe is rather geographically elegant.

There is a "straight across" (west to east, "latitudinal") split of California 
(almost) which nicely keeps the major population centers (of Southern and 
Northern California) apart, as well as neatly falls across county lines 
(political boundaries of admin_level=6), as well as is almost a "straight line" 
(geographically, a great circle, because Earth is spheroid).

It works like this:  there are 58 counties in California.  Split these 10 
counties into "Southern California:"

San Diego, Imperial, Orange, Riverside, Los Angeles, Ventura, San Bernardino, 
Santa Barbara, San Luis Obispo and Kern.

And split "the rest" (48 of them) into "Northern California."

Geographically, this is very close to a "straight line" (east west) at about 
latitude 35.7889805 although this wanders very slightly in Sequoia National 
Park (because of a mild survey error 150 years ago near the Kern River, I 
think) and it does take a few minor "jogs" in far eastern California on this 
"line" near Lamont Peak (between two national Wilderness boundaries), another 
"north, then easterly again" jog of about a kilometer near Boulder Peak close 
to United States Highway 395 and finally a similar "north, then easterly again" 
jog of about a mile (~1.6 km) in the Pahrump Valley Wilderness Area very close 
to the Nevada boundary, then easterly a few kilometers to the Nevada State 
Line.  That's it.

Honestly, it sounds more complicated than it is:  most people look at a 
wider-scale map of California's counties and "see" this east-west line rather 
neatly divides California into two, a northern and southern, and simply with 
the designation of "those ten counties" as the method to do so.  It isn't 
"perfectly straight" but it is "perfectly suited" to do this division of 
California, in my opinion.

I hope this helps.  It is one of the few times that living in California has 
intersected with OSM and the talk-us pages where I can say "I think I know what 
I'm talking about here."  Although, I certainly welcome other suggestions:  
these are the "talk" pages, after all!

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

Re: [Talk-us] New United States Bicycle Routes!

[OSM Volunteer stevea]

Only a couple of minor errors, it's good we double-check one another:  KYTC 
spreadsheet Lines 18/19/20 are a loop that excluded Sand Cave and Cathedral 
Domes in Mammoth Caves National Park, I fixed it so this portion of the route 
is now included in USBR 23.  In Franklin, Spreadsheet line 54 advises 
continuing straight onto KY-73E West Cedar Street (you had a southerly jog onto 
South Main Street, then a quick right onto West Madison Street).  You almost 
had this right, but again, because of some wonky names (and very few ref=* 
tags, both CR  for county-designated roads and KY YYY being frequently 
missing for KYTC-designated roads) I can see how it was easy to miss these 
couple of turns.  I'm pretty sure I have correct this as well, though 
Kentucky's existing TIGER data compared to how KYTC (and locals) "now" name 
these roads indicates a SIGNIFICANT drift in names and ref=* numbering (where 
they even exist at all) in the last 11 years.

If there one single US state which quickly rises (imo) to Priority 1, needing 
IMMEDIATE attention to fix its TIGER data, it is Kentucky.  I revise my 
characterization of these data from yesterday's "fair to poor" to simply "poor."

I probably made similar errors on my entry of USBR 21 in Kentucky, including a 
road/rail-undercrossing I'm still not sure truly exists!

If you are reading this and live/work in Knox County, Warren County and/or the 
City of Franklin in Kentucky, OSM sure could use a "triple-check" of these 
data, or even a comprehensive effort at statewide TIGER Review with state- and 
county-level road naming/numbering authorities.  Thank you in advance!

SteveA
California

> On Oct 27, 2018, at 2:30 PM, OSM Volunteer stevea  
> wrote:
> 
> Thanks, Greg, I'm now "double-check reviewing" USBR 23 in Kentucky.  Thanks 
> for your reciprocity on 21 (when/as you get your 'net back, of course).
> 
> SteveA
> California
> 
>> On Oct 27, 2018, at 11:38 AM, Greg Morgan  wrote:
>> 
>> I will be happy to review your implementation of the route. A second pass is 
>> always good for these turn by turn routes. It will have to wait until later 
>> in the day. I have an internet outage right now. 
> 


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

Re: [Talk-us] New United States Bicycle Routes!

[OSM Volunteer stevea]

Thanks, Greg, I'm now "double-check reviewing" USBR 23 in Kentucky.  Thanks for 
your reciprocity on 21 (when/as you get your 'net back, of course).

SteveA
California

> On Oct 27, 2018, at 11:38 AM, Greg Morgan  wrote:
> 
> I will be happy to review your implementation of the route. A second pass is 
> always good for these turn by turn routes. It will have to wait until later 
> in the day. I have an internet outage right now. 

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

Re: [Talk-us] New United States Bicycle Routes!

[OSM Volunteer stevea]

Sorry, I should use the abbreviation of KYTC as Kerry does, not KDOT.
SteveA

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

Re: [Talk-us] New United States Bicycle Routes!

[OSM Volunteer stevea]

"Having little confidence that KDOT got it right, either" is exactly why I 
didn't change the names:  let the locals (cities, counties, local 
residents/citizens) hash this out as well as KDOT, if KDOT wants to get 
involved.  For whatever reason, I've only seen these serious differences of 
this magnitude in the state of Kentucky, lest the greater-in-US OSM community 
suddenly panic that TIGER needs a major boost in fixing.  (I mean, let's STAY 
busy cleaning up TIGER, but let's not panic that it is especially bad).

OK, TIGER data are "only fair to poor" in Kentucky.  I will say that.  I'm not 
laying blame or pointing fingers, simply observing that entering route data 
from a state DOT was frequently perplexing given the need to match highway 
infrastructure of current TIGER data there.

SteveA
California

> On Oct 26, 2018, at 3:48 PM, Kerry Irons  wrote:
> 
> We had the same experience in creating a RideWithGPS map and route log for 
> USBR 21 in KY.  There are even places where a given road has two different 
> spellings; you can tell it's the same road but the name spelling apparently 
> is not agreed by the locals.  You learn to live with it.  While you would 
> think that the KYTC names would be definitive, I have little confidence that 
> that is true.
> 
> 
> Kerry

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

Re: [Talk-us] New United States Bicycle Routes!

[OSM Volunteer stevea]

I have completed a first draft of USBR 21 in Kentucky.  This was actually quite 
difficult as the TIGER name tags frequently do not match what highway names on 
the application from Kentucky's DOT says.  I did not change these, I'll leave 
that for "locals," but there is a great deal of work to do to change highway 
names in OSM in Kentucky, as it appears that counties, cities and KDOT change 
names (and segment breaks that make them up) quite a lot in the last 11 years 
since TIGER data were entered.

As our wiki says and as is good practice in OSM, Greg's 23 and my 21 data entry 
deserve a "double-check review" by another OSM volunteer, and while these are 
"green" in our wiki, they are a "light green" until this is completed.  Greg, 
if you email me off list and agree to double-check 21, I'll do the same to 23.  
Others are welcome, of course; email one or both of us if you are interested in 
helping.

SteveA
California

> On Oct 26, 2018, at 10:51 AM, OSM Volunteer stevea 
>  wrote:
> 
> Wow, Greg, you are quick.  Thank you!
> 
> Additionally, (a major reason I'm including Kerry in this missive), I removed 
> from OSM segments of Kentucky's USBR 23 which overlapped with ACA's 
> Transamerica Trail (TA) "Mammoth Cave Loop."  (Now largely superseded by 76 
> and 23).  These were between Highland Springs ("mid-state") and further north 
> to Tanner, where 23 now connects to 76 at a T-intersection.  There are many 
> reasons why OSM has been deprecating ACA routes in OSM:  these are 
> proprietary and likely don't belong in OSM first place, and we document in 
> our wiki that "over time, these tend to be replaced by USBRs" (among other 
> reasons, like that they can get old and drift from updates that ACA can make 
> or already has made).  Indeed, once again (as in the case of the northern 
> segment of 76 in Kentucky replacing Mammoth Caves Loop earlier when 76 was 
> approved in Kentucky), this segment of 23 100% overlaps with this ACA route, 
> so yet another significant ACA route segment now deleted from OSM (as it is 
> USBR now).
> 
> Thanks again for your work to enter this, and keep up the great entry I'm 
> guessing you are doing with USBR 21.
> 
> Steve
> 
>> On Oct 26, 2018, at 6:18 AM, Greg Morgan  wrote:
>> 
>> Kentucky USBR 23  is done.  
>> https://www.openstreetmap.org/relation/8843677#map=10/37.4960/-85.4712
> 


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

[Talk-us] OSM "motto"

[OSM Volunteer stevea]

I am told that "E datīs multum" would be more accurate Latin ("Out of data, 
much.")

OSM might need a motto as much as we need a state flower, I'm simply having a 
bit of fun tossing this into the greater world.

I do think it is important for OSM to keep important in our minds and hearts 
that we are a data project, and that it is out of our data (first and foremost) 
that we enjoy so many wonderful "creative, productive, or unexpected" 
derivations from them.

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

[Talk-us] New United States Bicycle Routes!

[OSM Volunteer stevea]

AASHTO has completed it's "Autumn 2018 round" of national route numbering 
approvals (almost) and there are new USBRs for OSM to map.

One is already completed (thank you, user:micahcochran!):  USBR 15 was extended 
from Georgia into Florida to connect to Florida's existing USBR 90.

In Kentucky, route data for USBR 21 (Georgia also has 21) and USBR 23 
(connecting to Tennessee's 23) are also available.  While our WikiProject (see 
https://wiki.osm.org/wiki/WikiProject_U.S._Bicycle_Route_System ) has route 
data for both of these — PDF maps and turn-by-turn spreadsheets — the route is 
not quite yet approved.  I have been told by a knowledgable source that "the 
AASHTO bureaucrat in charge of preparing the vote didn't put the (Kentucky) 
applications in front of the committee.  As a result, the applications were 
sent to the committee for an email vote, which is not yet concluded."  That's 
OK.

So, as is our usual (established for at least the last five years) process, we 
can take the sometimes substantial time and effort it takes to enter these 
while we wait for this "email vote approval" to complete, while the route is 
tagged state=proposed in the meantime.  Kentucky's 21 and 23 are each "seeded" 
in one southern county, properly tagged, they simply need completion.  If 
AASHTO's email vote approves these, we remove the state=proposed tag, whether 
the route is fully entered into OSM or not.  Let's enter it sooner rather than 
later!  Details on how to do so and links to route data in the cloud are found 
at the WikiProject link above.  Step right up, please!

Thank you for making OSM (and its companion renderer OpenCycleMap, as well as 
other great bicycle routing tools) one of the most comprehensive bicycle 
routing platforms in the world.  Like "E pluribus, unum" in the USA, "Ex data, 
multum" in OSM:  "From data, much."  (Yes, I did just make that up!)

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

[Talk-us] Fort Worth, Texas bicycle routes

[OSM Volunteer stevea]

I attempted to contact at least some of the authors of "bicycle routes" in the 
Fort Worth area (and waited the requisite two weeks), alas, to no avail.

So I'll say this here:  when tagging for bicycles in OSM, there are two 
"levels" at which this is appropriate:  1) is infrastructure tagging, 2) is 
route tagging.

In Fort Worth, a great deal of bicycle infrastructure (tagging individual ways 
with tags like highway=cycleway or cycleway=track,  "Class I," cycleway=lane, 
"Class II," and bicycle=yes "Class III" is extant and maybe complete.  (I agree 
that those "Class" designations are California-flavored, but that's where I'm 
from and other states use these, too.  I don't know if Texas does or not).  
Much of Fort Worth's tagging of this sort is extensive and appears accurate in 
an OSM sense, I don't have a problem with it.

However, where Fort Worth's bicycle tagging in OSM is problematic is route 
tagging.  Currently, there are two  relations in the area tagged route=bicycle, 
one is network=lcn (https://www.osm.org/relation/7193738) and is unnamed (it 
might be something intended to represent the "Greater Fort Worth/Tarrant County 
local bicycle network"), another is network=rcn 
(https://www.osm.org/relation/7213397), with the name "Trinity Trails."  The 
problem with both is that they are "gigantic agglomerations of hundreds of 
segments of bicycle infrastructure" (often discontiguous) instead of discretely 
numbered (or named) individual contiguous routes.  I'm pretty sure this isn't 
what the City of Fort Worth (or the County of Tarrant, I'm not sure who is the 
bicycle protocol numbering authority who designates these as bicycle routes 
actually) has in mind with bicycle routing, nor is this how OSM tags these 
across the world.  We tag individual, contiguous routes with these tags, as 
they are part of a comprehensive network of routes at a particular 
political-hierarchy level with the network key's values of ncn (USBRs) rcn 
(state-level bicycle routes) and lcn (local/county/city bicycle routes).  We 
use the cycle_network tag (see https://wiki.osm.org/wiki/Key:cycle_network) to 
identify the specific numbering / naming authority of that network.

Without local knowledge to do so, I have "broken out" a couple of the more 
obvious individual routes (these two are wholly disconnected from other parts 
of the network and make obvious choices to do this) into "OSM proper" bicycle 
routes tagged network=lcn, but without only "good guess" ref=* or name=* tags 
(like "3rd" on 3rd Street).  As there are hundreds of segments of 
infrastructure in each of these "gigantic glom relations," someone with local 
knowledge of the individual routes is DEEPLY encouraged to reduce these 
gigantic glom relations to zero and "trade places" of their (again, 
properly-tagged) individual elements into smaller, contiguous, sensible local 
bicycle routes.  (The two example "seeds" I offer are 
https://www.osm.org/relation/8845474 and https://www.osm.org/relation/8845475).

Helpful wiki is at 
https://wiki.osm.org/wiki/United_States/Bicycle_Networks#Local and excellent 
"better example" bicycle relations from which proper route structure can be 
learned are found in nearby Plano and Dallas, Texas.

Thank you for making OSM (and its OpenCycleMap renderer) one of the most 
comprehensive (and widely used) bicycle route mapping platforms in the world.

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

Re: [Talk-us] More-complex wiki pages are spitting up Lua errors

[OSM Volunteer stevea]

Well, I'm no longer seeing the Lua errors I saw, so "caches cleared" (all the 
way down) and the problem seems to be "fixed" now.

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

[Talk-us] More-complex wiki pages are spitting up Lua errors

[OSM Volunteer stevea]

What's up with OpenStreetMap's wiki?  I've noticed in the last couple of days 
that "more complex" wiki pages often generate Lua errors where they never have 
before (and nothing has changed in the content), in particular

Lua internal error: the interpreter has terminated with signal "24"

Try, for example, https://wiki.osm.org/wiki/California/Railroads where it gets 
about halfway through the page plenty fine, but somewhere around "Railtrails" 
it starts spitting up "red text" Lua errors for simple tasks like a 
BrowseRelation entry.  And yes, it's OK if the answer is "that wiki page is 
simply too large, break it up" as there is a proposal in the wiki itself to do 
just that.

My best guess is an overloaded wiki server.  As it isn't clear from munin 
(OSM's statistics / platform status) which server for wiki might be overloaded, 
I looked at https://wiki.osm.org/wiki/Platform_Status and discovered it is 
stormfly-01.openstreetmap.org hosted at Oregon State University's Open Source 
Laboratory (thank you for hosting, OSU!).

However, stats are reporting "green" although the Notes column remarks that the 
job queue counter continues growing.  It seems a "beefy enough" server (HP 
ProLiant DL360 G6, 2 x 6 cores of Xeon X5660s at 2.80 GHz, 72 GB RAM...) but 
maybe we're simply over-stressing it.  Yes, I do write a lot of wiki, but I'm 
fairly certain it isn't me!

Apologies if this should be directly addressed to our OSM Operations Team, I 
don't really know how to do that (and it isn't clear, so perhaps we want a 
"more clear" way to report minor errors like this).

Thanks for directing this to the right people if anybody reading this can do so,
SteveA
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Yet more about USA Rail: now, wiki

[OSM Volunteer stevea]

No hijack seen as actual or intended:  great idea, Martijn!

Trains, transit,  our map:  these really do keep getting better and better.

SteveA

> On Sep 18, 2018, at 12:01 PM, Martijn van Exel  wrote:
> 
> To branch out a little bit — sorry to hijack the thread Steve — it would be 
> nice to do a nationwide transit mapathon around transit. We used to run 
> nationwide coordinated mapathons and I miss them. I think they are fun to 
> connect communities. Who’s in and who wants to help coordinate?
> 
> Martijn

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

[Talk-us] USA (non-Amtrak) passenger rail

[OSM Volunteer stevea]

In https://wiki.osm.org/wiki/WikiProject_United_States_railways#Train_Routes 
there are over 30 USA-based passenger rail routes (e.g. FrontRunner in Utah, 
MVTA in Minnesota, BrightLine as part of Florida East Coast Railway..) which 
suffer from very little (wiki) documentation as to how they fit into a wider 
transportation system for the state/county/city they are based in, and as to 
how they fit into a wider rail network in their respective states.

Suggested there is that by creating a half-dozen state-level rail wikis 
(similar to the recently-declared-alpha 
https://wiki.osm.org/wiki/Colorado/Railroads ) this would knock down the "over 
30 rail routes poorly documented" by more than half.  That's a lot of "bang for 
the buck" even as I (personally) realize that it can be a significant amount of 
work to create a comprehensive statewide rail wiki.  (Yet, out of 50 states, 
the USA is pushing up to having a dozen or so of them, and growing).

If you are looking for something to do in OSM, please consider creating a State 
project rail wiki.  There are seeds both simple and complex for you to clone, 
starting with the lightly-sketched 
https://wiki.osm.org/wiki/New_Mexico/Railroads and 
https://wiki.osm.org/wiki/Montana/Railroads and all the way up to the rather 
comprehensive https://wiki.osm.org/wiki/California/Railroads wiki.

With "Street" as our middle name, lots of folks use OSM for highway and bicycle 
mapping/routing.  Yet, with the importance of rail travel almost exploding 
across our country as new light_rail and suburban train routes are being added 
almost faster than our mapping speed (and certainly faster than our 
wiki-writing speed), we have some work to do to catch up!

Happy mapping (and wiki-documenting),

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

Re: [Talk-us] Denver RTD's public_transport growth

[OSM Volunteer stevea]

Jay Johnson  wrote:
> The authoritative source for railroad GIS data is usually considered to be 
> BTS:  https://www.bts.gov

Thank you, Jay!  That's a very rich website, I'm now fumbling my way through it 
and I think I can find the "platform/stop" locations I'm looking for, but it 
may take some data massaging to get those into OSM in a straight line.  I find 
it kind of neat (circular logic?) that OSM is at least partly used as a basemap 
layer on this site's geo browser, although as I drill down to the data I'm 
looking for, the US DOT web site "becomes" a US DOT-branded site in the 
opendata.arcgis.com domain.  OK, whatever; ArcGIS' open data portal using OSM 
doesn't surprise me, and they do properly attribute OSM.

Some of these data appear to be a national agglomeration of 
transit-authority-produced GTFS feeds, which is/was another method by which I 
might have obtained these data (they are published either by the transit 
authorities themselves or by similar, non-governmental, often academic sites 
which collate the data).  I'm sort of slapping my forehead that I didn't think 
of GTFS data first, as I mentioned GTFS in a 2014 SOTM-US talk I gave on 
national bicycle routing; GTFS are really useful data, and them finding their 
way into OSM is a fairly natural thing to happen (given time, and here we are).

I'm also appreciative that the bts.gov data are quite fresh; it looks like they 
started the project in 2016 and some of the data are dated February, 2018.  
Great!

> When I worked at BNSF, that is what was used to initially populate the 
> linework for our rail feature class.

I would have thought BNSF (and other Class I carriers) had their own maps of 
their own rail lines.  Interesting that they use a .gov site (and data) to 
"populate the linework."  Again, seems sort of circular, as the rail line data 
had to originate from somewhere.

> Class I railroads (the very large ones) are generally regulated by the 
> Federal Railroad Administration.  PUC is for telecom, electric and gas.  

I had great luck with California's PUC and rail data:  one was a statewide 
"crossing spreadsheet" that listed road/rail crossings and allowed OSM (me, in 
this case) to replace (at least in California) our rough TIGER rail data with 
proper Subdivision names.  That took me some time to curate, but our 
California/Railroads wiki and useful products like OpenRailwayMap and 
OpenPublicTransportMap are all the better for it wherever OSM volunteers do 
this work.  The California PUC also publishes an excellent PDF/hypertext of 
passenger rail data (a link to it is in our wiki) right down to the level of 
speed limits on segments and signal/switch names.  That's pretty ambitious 
(especially in a state with as much rail as California) and I haven't 
incorporated those data into OSM, but the links are there for anybody who wants 
to bite that off and chew (and chew, and chew).

Part of what I'm doing is "building community" by launching Colorado/Railroads 
(as another statewide wiki "seed" for good rail documentation) in the hopes of 
inspiring others to do the same in their states.  (We're up to ten or eleven 
states now with alpha/beta-level rail wiki pages).  And, I was hoping that OSM 
volunteers would take heed to "Map Your Train Ride!" to get more platform/stop 
data into OSM's passenger train routes.  But, there is more than one way to do 
all of these things, of course.

Fantastic there are so much good data "out there" and that we have people 
reading this list who know where to find them!

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

Re: [Talk-us] Denver RTD's public_transport growth

[OSM Volunteer stevea]

On Sep 2, 2018, at 9:52 PM, OSM Volunteer stevea  
wrote:
> 
> I "found something rectangular" and sketched in 
> http://wiki.osm.org/wiki/Colorado/Railroads which we might agree (as a 
> useful, communicative wiki) is "alpha-1" or so.

Following up to my own post, (that wiki continues as "early alpha"), two 
important tasks emerge:

1)  Denver RTD's University of Colorado A Line (train) needs nodes/ways added 
to OSM, tagged public_transport=platform to grow the route from 
public_transport:version=1 to v2.  Seeing this is a pretty heavily-travelled 
passenger=suburban route=train, this shouldn't be too difficult, and

2)  TIGER Review of existing mainline freight rail (primarily mainline BNSF 
routes Colorado Springs, Pikes Peak, Spanish Peaks and Walsenburg Subdivisions) 
will need some additional authoritative data sources (Colorado PUC?) to 
"untangle" them from UP lines:  they have blurred so much and are have gotten 
so confused that the original TIGER data are virtually incomprehensible as they 
exist in OSM at present.

Of course, keeping the wiki synced with the data in OSM is the whole point.  
Then we go beta and eventually Colorado/Railroads become "a pretty darn good 
set of statewide rail data, well-documented."  One state at a time, OSM rail 
data (from decade-old hoary TIGER data) do measurably and demonstrably improve.

Thanks, especially to Colorado OSMers/rail enthusiasts who have responded so 
far,

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

[Talk-us] Denver RTD's public_transport growth

[OSM Volunteer stevea]

I "found something rectangular" and sketched in 
http://wiki.osm.org/wiki/Colorado/Railroads which we might agree (as a useful, 
communicative wiki) is "alpha-1" or so.

Denver's FasTracks Lines grow, let's sync OSM and this wiki with another 
up-to-date light_rail table.  This strategy works:  Portland TriMet, meet 
California/Railroads, meet Miami/BrightLine, meet San Francisco BART, meet 
Denver RTD...and so on.

Rail mapping feels like solving a crossword, good for the mind and then there's 
that volunteer spirit part, too.  Go!

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

Re: [Talk-us] ref=* tags on links (Kevin Kenny)

[OSM Volunteer stevea]

So many conversations at once; this list-digest medium proves limiting at 
times, even often.

Helpful old-fashioned aids here might be sketch boards where small-group (two, 
three people?) sub-projects can spin out and a main thread group where someone 
explains what s/he sees going on and how we might all get on the same page, 
making (actually or the equivalent of) a two- or three-page (at most?) wiki / 
OSM structure with two or three graphics of stacks of things, where this stack 
differs from that stack, where technical boundaries make divergences among 
real-world data consumers and a shortest path to "let's help each other out to 
learn how to make this very difficult bubble gum chewable by everybody around 
here who needs to."  Yes, that's a rather tall order yet we can get there.  
Otherwise I might conclude we have some communication difficulties we'll need 
to solve sooner.  We have pieces of this scattered among us in stovepipes.  
That's all, it isn't terrible, it is solvable.

OSM stacks and data consumers (especially over time, years, as projects evolve, 
needs change, specification revise, tagging syntax meets renderer and "changing 
taste among data consumers is both well anticipated and poorly anticipated."  
These are highly complex. the system is a global mapping project among millions 
of us for billions of us, it is largely volunteer and partly "on a shoestring 
and even amongst ourselves we don't always share data and process in our 
stovepipes without a certain reticence .  There is such a thing as intellectual 
property, trade secrets and what we are talking about doing, process 
improvement, pays truly huge dividends for our future.

Let's be the best project we can be.  We're a lot of very smart people.  We can 
solve in weeks or months or a year what it might have taken us ten years (or 
15) to get to "about here."  I'd say we're doing fine, even as we do have some 
climbing ahead.  OK, I'm fine with that.  I'm being a bit rough and fast here, 
no doubt this will morph.  Good.

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

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

[OSM Volunteer stevea]

On Aug 24, 2018, at 11:41 AM, Evin Fairchild  wrote:
> Hey, I totally agree that we need to fix the rendering so that the renderer 
> will show ref tags on route relations. But until then, it's impractical to 
> expect people to avoid putting the ref tags on the ways.

Evin, we agree to disagree about "practicality."  Defects can be so severe that 
workarounds cease as solutions.  If/as more data entry which tags for the 
renderer STOPS (no more bandages), and the real wound is seen for what it is (a 
problem that must be fixed), a much stronger incentive to fix exists.  We are 
not there now because of all the bandages, though we may get there if data 
entry more fully embraces "don't code for the renderer:"  shields don't get 
rendered properly, routing seems to (or does) fail, etc.  Either way (we can't 
have it both ways), the ONLY eventual solution is to fix what's broken.  Mihai 
broached the topic, again (thank you), here we are.

It seems "until then" is good enough for some people.  As I can only speak for 
myself, I say "not good enough for me."  Identifying defects is an absolutely 
critical process in any software endeavor, OSM included.  And, as this is a 
specific/localized problem, I wish to build stronger methodologies in OSM for 
our ability to identify/recognize ANY problem in our data-to-render pipelines, 
while being supported by our community in our quest to fix them.  My annoyance 
IS at the renderer itself.  "Push for it to get fixed" is exactly what this is.

As crucial "render stack coders" (right on, Martijn!), are clearly a critical 
OSM resource, they can't be expected to service every single problem, so we 
have what has evolved.  But, we must prioritize.  This is correct:  some 
defects are purely cosmetic, some are high-priority.  There is a rich spectrum 
of multi-dimensional methods to measure (and hence prioritize) software 
defects.  However, "pretending away" with "it's impractical" and "don't code 
for the renderer" must be identified as what they are:  dancing/hand-waving to 
buy some time until the demand (to fix defects) catches up with the 
supply/reality of them actually getting fixed.  OSM simply must get better at 
this.  I may not know exactly how today, but decades of improving exactly this 
process at major software companies tells me that's what this is and that's 
what we must do.  The process remains opaque quite likely deliberately to 
"obfuscate away" demands on critical resources.  Let's open that up, please; 
Open is our first name.

> I do agree with not tagging for the renderer, but I was merely pointing out 
> that it's impractical to expect EVERYONE to follow it in this case until the 
> renderer is fixed.

To make my point clearly:  calling it "impractical" prolongs the problem by 
winking and nodding at slapping bandages on a wound.  The "short-term bandage 
window" is or should be closed by now.  Paul Johnson is right:  dinosaurs like 
ten-year old bugs ought to be fixed.  If you want to say "it's impractical to 
expect..." you can.  I am saying "let's be practical by fixing what is broken." 
 That's what works.

Really, this is a much wider conversation, as you (Evin) identify about 
Washington state route shields and Kevin Kenny's recent "resurrection" of 
similar topics.  Yes, the data-to-render pipelines can be complex; I 
acknowledge that, this is a fundamental "tall mountain" of OSM.  But I continue 
to say "fix bugs, don't bandage them" (rather than wink or say "that's 
impractical").  Andy's awesome work to streamline mapnik into Carto is an 
excellent example of this tenet:  our project will either learn how to fix 
complexities in renderers (often by simplification of the codebase), or we will 
self-destruct in endless discussions like this.  I'd much rather take what is 
known to be a proven successful path.  So, let's improve our render-defect 
fixing pipeline, as it is rather broken.  No judgement there, rather 
identification of problems needing fixing.  We've done it before, we'll do it 
again, only better.

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

Re: [Talk-us] Talk-us Digest, Vol 129, Issue 27

[OSM Volunteer stevea]

> Evin Fairchild  wrote
> The only way you can get people to stop putting reg tags on ways and only put 
> them on relations is if the renderer actually rendered reg tags from 
> relations. Currently it doesn't do this, so

All good and correct so far...

> it's impractical for people to do what you're suggesting.

By "you" Evin means Paul Johnson and by "do what you're suggesting" — 
eliminating ref=* tags on ways — (as they are 100% redundant if the way is part 
of the appropriate route relations) Paul's suggestion is excellent.  It is 
correct, not impractical.

Continuing to put ref=* tags on ways is called a "workaround."  Like a bandage 
on a wound, workarounds can be decent short-term solutions, but the real 
healing which OSM must complete is for renderers to respect route relation 
tags.  All else is folly.

> Yeah, yeah, yeah, I know, don't tag for the renderer,

OSM's tenet of "don't tag for the renderer" is something I respect.  Yet 
(especially in this case) it has qualities of "magical thinking" whereby the 
wound is artificially babied along by pretending away that the real work 
renderers must (MUST!) do is to fully respect long-established data structures 
renderers purport to represent.  If that is hard work (evidently, it is), well, 
let's roll up our sleeves and code (FIX!) our renderers so they properly 
visually represent our data.

Babying along wounds, pretending away and magical thinking are elements of sad, 
broken, amateurish projects:  they'll "get you through the night," and for too 
long in OSM, they have.  But as OSM matures into a happy, working, 
professional-grade project (we have, we do) that simply doesn't cut it any 
longer.  Someone has to say this — again and again, apparently — until the real 
solution of "this is hard work, but we must do it" is completed.

> but I'd you don't have route numbers show up at all, them this really reduces 
> the usability of the map.

What a fantastic incentive to fix renderers:  evidence of "tag like we say we 
should tag" means "hm, renderers don't respect that!"  We can no longer say 
"don't code for the renderer," wink at those who do and continue to say and do 
this while "rendering incompletely."  It is disingenuous and shows that 
something is fundamentally broken in our project.  We MUST fix renderers or we 
DESERVE monikers of "sad, broken, amateurish."

> It's such an important thing that there's no way you can get people to stop 
> putting the reg tags on ways unless the renderer rendered the ref tags for 
> the whole relation.

It is circular logic (explained) and circular logic is broken.  We must fix our 
renderers so they fully respect our well-established data structures.  No 
longer can we be told "don't pay attention to that man behind the curtain" 
while winking and workarounds fight each other for dominance:  OSM loses (big 
time) in the long-run as we continue to fool ourselves with the folly of these 
contradictions.

The bottom line, "easy as cake, simple as pie:"  FIX WHAT IS BROKEN.  Is this 
difficult software development?  That's OK, let's do it.  No more excuses.  It 
isn't impossible to avoid contradictions, though it may be hard work.

With the greatest respect for our project,
SteveA
California
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Food delivery services: Move-fast-and-break-trust

[OSM Volunteer stevea]

Though I'm "old enough in this project" to celebrate my first decade coming up, 
I haven't seen the English, German or ANY version in printed form — I'd now 
almost consider it a historic document!  And while I seldom snarl "don't print, 
we need our trees" (I did co-develop PDF while at Adobe, so I have helped 
humanity use less paper) I'm still OK with the idea of handing out business 
cards or printed matter explaining who OSM is and what we do.  A-OK.

I repeat myself, but simply opening my mouth and offering a helpful bit of 
truth and a smile has always gotten me a "thank you" in return.  So, "got 
paper?" to hand out?  Great!  Don't, but you have a mouth that politely 
explains OSM as a volunteer project while smiling?  That's good, too:  
invariably, you'll get a smile right back at you.

OSM remains one of the most cool, beneficial-to-humanity, 
feels-good-in-your-bones volunteer activities you might do right now.  Maybe 
that's just me, but I sincerely doubt that.

SteveA
California

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

Re: [Talk-us] Food delivery services: Move-fast-and-break-trust

[OSM Volunteer stevea]

I like Clifford's approach of "If you are curious and asking, I reply openly 
and honestly with my real name and a card I'm handing you so you may 
forthrightly know who I am and what I'm doing."

In the very, very limited number of times I have also had what I can only 
characterize as "mild inquisitiveness" towards "what are you doing with what 
looks like spying (no) / data collection (yes)?  This seldom if every gets rude 
or hostile, I ask them if they have a smart-phone (as they see me punching a 
mobile device in my hand, holding a GPS, scribbling notes on paper, or all 
three).  If they say "yes" (billions of us do), I ask, "Do you ever use maps on 
it or be a little amazed at how because it knows where you are (if you tell it 
that's OK) and then search for the nearest dry-cleaners is or how to most 
quickly walk to the drugstore it draws a nice set of lines on a map that is 
pretty, up to date, and takes you right there easily?  Well, as a volunteer in 
an open data mapping project called OpenStreetMap, I'm helping you continue to 
do that in the present and future by updating things around here."

I invariably get a smile and a hearty "thank you!" and it's all over in about 
twenty seconds.  Good will begets same.

The "scraping of menus" and "we deliver Ming's Chinese" (though Ming knows 
nothing about delivery of his food) are strange trends for me to see, but I 
suppose we shouldn't be too surprised.  Whether this is legal or ethical or has 
anything to do with maps (OSM or otherwise), I'll refrain from saying anything 
about here and now.  Except that as more and more telescopes are pointed at 
everybody everywhere, we shouldn't lament the disappearance of what we once 
quaintly thought of as "privacy."

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

Re: [Talk-us] place=locality on rail junction

[OSM Volunteer stevea]

On Aug 17, 2018, at 2:59 AM, talk-us-requ...@openstreetmap.org wrote:
When I come upon these, what's The Right Thing?  'railway=junction ref="CPF 
499"' instead?

Hi Kevin:  "Railroad place names" in the USA have a lore all their own.  
Sometimes and even often in remote/rural areas, simple junctions, switches or 
sidings which were named by the railroads "turned into" what we (in OSM and 
other contexts) might call a "locality" or even serve as the de facto location 
of a hamlet or village, especially as a station serving freight or passengers 
also "grew up" there.  A surprising number of these (thousands, at least) 
survive presently.  Railroads heavily influenced how the USA became what we are 
today (landuse patterns, industrial zones...).

Though you didn't specify exact nodes so their "true railway function" can be 
determined, I did an Overpass Turbo query in your area and found some.  Many 
are switches, some are junctions.  While 
https://wiki.osm.org/wiki/OpenRailwayMap/Tagging can be daunting documentation 
and could prove helpful, https://wiki.osm.org/wiki/Tag:railway=switch is much 
more succinct.  Simply assure these are at a point where two rail lines diverge 
and modify tags to be railway=switch and ref=CPF 499 (or whatever).  However, 
they may also be junctions instead of switches:  see 
https://wiki.osm.org/wiki/Tag:railway=junction (quite brief) and note that a 
switch diverges two lines whereas a junction might not.

So, if it's a switch, name becomes ref and place=locality becomes 
railway=switch, but only if you are fairly certain it is where two rail lines 
diverge.  If you are not sure it is a railway=switch, it might be a junction 
(e.g. Cherry Valley Junction).  Tags there should be railway=junction + 
name=Cherry Valley Junction (not ref=*).

More difficult still is when the node is NOT part of the rail infrastructure (a 
node actually on the railway=rail, maybe it's simply a node nearby a rail line) 
as then place=locality truly might be an accurate tag.

BTW, I've been cleaning up NE2 messes (as I find them) since about 2011 (even 
after he would rudely swear at me in my polite emails to him); good riddance to 
NE2.  His horrific sense of bicycle routing turned into me and others first 
tearing out our hair in frustration, then we began our USBRS WikiProject.  So:  
lemons?  Lemonade!

Thank you for asking the list.

SteveA
California
___
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

[OSM Volunteer stevea]

I'll refrain from whether adding (or not) "of America" to the end has anything 
to do with cabals or sovereignty.  I agree with Kevin (and others) that adding 
"it is never incorrect to add it" (can't hurt), usually helps and distinguishes 
Mexican states from the fifty north of the Rio Grande (in some places).  Yes, 
there are eighty to ninety admin_level=4 entities in North America when you add 
Canadian provinces and states in Mexico to the fifty in the USA.

I will say that in the USA there are fifty sovereign states AND a Union of 
these together as a "federal" sovereign state.  In short, "the federal entity" 
and "one of the fifty" are wholly different legal entities and "Union" is an 
approximate word.  Our courts agree.

That's OK:  most people know "there's federal law and there's state law" and 
yeah, that's right.

We do pretty well sorting these things out in OSM, with admin_level and so on.  
I don't think we need any major (or minor) changes to how we name countries or 
states, though sometimes the edges blur and we get better at defining things.  
There are some disputes, there are some boundary issues, we are people making a 
map, we both agree and disagree and we do the best we can.

SteveA
California

> On Aug 16, 2018, at 2:52 PM, talk-us-requ...@openstreetmap.org wrote:
> 
> Send Talk-us mailing list submissions to
>   talk-us@openstreetmap.org
> 
> To subscribe or unsubscribe via the World Wide Web, visit
>   https://lists.openstreetmap.org/listinfo/talk-us
> or, via email, send a message with subject or body 'help' to
>   talk-us-requ...@openstreetmap.org
> 
> You can reach the person managing the list at
>   talk-us-ow...@openstreetmap.org
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Talk-us digest..."
> Today's Topics:
> 
>   1. Re: buggy buildings in Maryland (Elliott Plack)
>   2. Re: Proposition for changing the common name tag (Daniel Koć)
>   3. Re: Proposition for changing the common name tag (Daniel Koć)
>   4. Re: Proposition for changing the common name tag (Kevin Kenny)
> 
> From: Elliott Plack 
> Subject: Re: [Talk-us] buggy buildings in Maryland
> Date: August 16, 2018 at 11:08:00 AM PDT
> To: Frederik Ramm 
> Cc: "talk-us@openstreetmap.org Openstreetmap" 
> 
> 
> Thanks for bringing this up, Frederik. I reached out to the user in a 
> changeset and a mail thread (links below) and was under the impression that 
> they would fix the problem. Was that really two years ago?
> 
> https://www.openstreetmap.org/changeset/41375854 - changeset
> https://gist.github.com/talllguy/7d813ece238f359317786a18f7b7bbcb - message 
> thread copy
> 
> I'd say go ahead and remove the extraneous nodes and also any buildings that 
> are either version 0 or do not have any new tags (like names or addresses). 
> The Microsoft buildings could replace any buildings that are only footprints. 
> If you can cull this down to those with some information besides the geometry 
> alone, the community can fill in the blanks.
> 
> 
> On Thu, Aug 16, 2018 at 8:10 AM Frederik Ramm  wrote:
> Hi,
> 
> over the last 2 years, DWG has had a three different complaints about a
> buggy building import that has been run on and off by the user
> "annapolissailor".
> 
> The import was problematic in many ways, most obviously because huge
> batches of un-used nodes were uploaded and later it was attempted to
> connect them, which sometimes failed, leaving lots of un-used nodes in
> the database; also, almost all buildings are over-noded, taking 10 or
> more nodes for a simple rectangular building (eg
> https://www.openstreetmap.org/way/435663194). Buildings that were in the
> area before have been deleted outright, and the data source and legal
> situation is unclear (many buildings are much too precise to have come
> from aerial imagery).
> 
> (Needless to say, had the import been discussed up front as is
> customary, all these issues could have been avoided.)
> 
> I have tried to work with the importer but they seem to be ultimately
> unable or unwilling to fix the problems even though they did seem to
> understand the issue at some point
> (https://www.openstreetmap.org/user_blocks/1587). They asked me a couple
> of times to "hold off reverting data until next steps are discussed on
> the imports list" but never followed up on the promise. They claimed to
> have spent hundreds of hours on the JOSM validator improving problems
> they had introduced.
> 
> I am at the moment deleting about 70,000 untagged and un-used nodes that
> have been left over from this import, which is the uncontroversial part.
> 
> The total amount of buildings created and still visible is 177,151, with
> a total of 1,980,336 nodes, in the general area "East of Washington DC,
> South of Baltimore, North of Chesapeake Beach".
> 
> I think these buildings need to be deleted too, given their technical
> (over-noding) and legal (we don't know where the data came from and what
> 

Re: [Talk-us] [Talk-us-nps] [EXTERNAL] North Carolina National Park

[OSM Volunteer stevea]

Hi Nic:

Several years ago I developed a ten-step process for importing USFS data 
(boundaries) into OSM using our JOSM editor (more difficult to use than 
web-based iD, but more powerful, too).  These are pretty technical steps, 
suitable for an intermediate or advanced OSM volunteer, but they are 
comprehensive, especially for getting a Forest Service boundary (whether forest 
or wilderness, two separate legal designations) "conflated" with data already 
existing in OSM.  I would be happy to send them to you, just reply and ask me 
for my "USFS Import ten-step" document.

SteveA
California

> On Aug 16, 2018, at 9:29 AM, talk-us-nps-requ...@openstreetmap.org wrote:
> 
> Send Talk-us-nps mailing list submissions to
>   talk-us-...@openstreetmap.org
> 
> To subscribe or unsubscribe via the World Wide Web, visit
>   https://lists.openstreetmap.org/listinfo/talk-us-nps
> or, via email, send a message with subject or body 'help' to
>   talk-us-nps-requ...@openstreetmap.org
> 
> You can reach the person managing the list at
>   talk-us-nps-ow...@openstreetmap.org
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Talk-us-nps digest..."
> 
> 
> Today's Topics:
> 
>   1. Re: [EXTERNAL]  North Carolina National Park
>  (English, Jesse R -FS)
> 
> 
> --
> 
> Message: 1
> Date: Thu, 16 Aug 2018 14:37:40 +
> From: "English, Jesse R -FS" 
> To: James McAndrew ,
>   "dunic...@hotmail.com" ,
>   "talk-us-ow...@openstreetmap.org" 
> Cc: "talk-us-...@openstreetmap.org" 
> Subject: Re: [Talk-us-nps] [EXTERNAL]  North Carolina National Park
> Message-ID:
>   
> Content-Type: text/plain; charset="utf-8"
> 
> Thanks for your interest, Nic!
> 
> The place to get data for the Forest Service is the Data Extract Tool, at 
> https://data.fs.usda.gov/geodata/webapps/EDW_DataExtract/. The amount of data 
> varies by Forest, but most every forest should have the information that 
> would be useful to OSM – boundaries, roads, trails, recreation sites, etc.
> 
> Some forests are combined administratively, even if they seem to be separate 
> forests on the ground. For instance, the Croatan NF is managed as part of the 
> National Forests in North Carolina. So to get the Croatan’s information, you 
> would go to the Data Extract Tool and download National Forests in North 
> Carolina data. Some other, mostly southern, states are like this, including 
> Alabama, Mississippi, Texas, and Florida.
> 
> Wilderness areas are congressionally-designated areas within federal lands, 
> managed to standards that preserve their wilderness character. For all the 
> information you could ever want on wilderness, please visit Wilderness.net. 
> Here’s a great page to start on: 
> https://www.wilderness.net/NWPS/WhatIsWilderness
> 
> I hope that helps get you started! Feel free to contact me with any more 
> questions.
> 
> [Forest Service Shield]
> 
> Jesse English, MLA, LEED AP
> Recreation, Wilderness & Trails Program Manager
> 
> Forest Service
> Cherokee National Forest
> 
> p: 423-476-9748
> jrengl...@fs.fed.us
> 
> 2800 Ocoee St N
> Cleveland, TN 37312
> www.fs.fed.us
> [USDA Logo] [Forest Service Twitter] 
>   [USDA Facebook] 
> 
> 
> Caring for the land and serving people
> 
> 
> 
> 
> 
> 
> From: James McAndrew [mailto:james_mcand...@partner.nps.gov]
> Sent: Thursday, August 16, 2018 10:02 AM
> To: dunic...@hotmail.com; 
> talk-us@openstreetmap.org
> Cc: talk-us-...@openstreetmap.org
> Subject: Re: [Talk-us-nps] [EXTERNAL] North Carolina National Park
> 
> Nic,
> 
> I'm CCing the general talk-us on this, since National Forests are outside of 
> the separate from the National Park Service, and there may be someone there 
> who can provide more guidance.
> 
> In this particular case the Pocosin Wilderness Area is managed by the Forest 
> Service (part of the US Dept of Agriculture), although "wilderness areas" can 
> be managed by a number of groups within the federal government.
> 
> If you're using data from state governments, you will need to look at the 
> licensing restrictions, because many states do not release their data into 
> public domain. US Federal government datasets are mandated to be in the 
> public domain, so there are no issues using them for OpenStreetMap.
> 
> Since this National Forest and Wildlife area are not units of the National 
> Park System, you will not find them in the irma.nps.gov 
> dataset. It looks like your best source of data for this will be the PDF that 
> you linked: 
> 

Re: [Talk-us] State Open Data

[OSM Volunteer stevea]

Again, one of the most important things that might be said (in talk-us) about 
"State Open Data" is that there are at least fifty different sets of rules.  
"Check your state laws and county practices" remains excellent advice.  Yes, it 
can be complex, but if in a state like California, we're in pretty good shape.  
In New York, it's different.  Et cetera (48 different other ways).

Documenting state-by-state "rules" and legal state-data copyright 
practices-as-they-apply-to-our-ODbL could turn into a WikiProject.  (And then 
traffic in this mailing list might diminish yet more).  Yet, it's a rapidly 
moving topic and notice how everyone is so careful to say "I'm not a lawyer, 
but..." and gets the bright idea that OSM's seriously-busy Legal Working Group 
might spend time double-checking things, which simply is not practical.  So I 
don't see how a wiki could realistically keep up in real-time, even with a team 
of well-paid top lawyers, unless they fall from the sky like rain and I don't 
see that in tomorrow morning's forecast.

I don't know a good solution to this except to keep open good dialog, even if 
it means we repeat ourselves.  This isn't like a hard math problem that got 
solved a few centuries ago, like orbital mechanics.  It is a very 
up-to-the-minute legal edge that we walk here, out on the hairy precipice of 
"do I or don't I enter these data?"  "Is this a good idea or could it 
jeopardize the project?"

We can be both bold and careful, but it isn't easy.  Ask.  Dialog.  Read.  
Discuss.  It is getting better.

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

Re: [Talk-us] State Open Data

[OSM Volunteer stevea]

Thank you very much for these additional clarifications, Brian.  It may take 
years, it may take several court cases, it may take fifty state legislatures 
and courts and federal appeals and circuits to assert this, it may take 
Attorneys General educating county clerks who try to assert copyright 
(improperly, even illegally), it may even take DECADES of effort in open 
data/open source projects like OSM and we, the good People and Citizen Mappers 
who believe in this stuff and continue to knock on doors, send emails and make 
phone calls to our elected folks.  But the bottom line is that slowly, surely, 
we here in the fifty states of the USA enjoy fairly free-and-open geographic 
data from which we are able to make excellent maps.  (OK, ask around, check 
your state and/or county to be sure).  Harmoniously, together, sharing the best 
knowledge/data we have, coupled with the power of government resources wisely 
spent and our volunteer spirit working for the highest good of awesome 
geography, OSM continues to rock the mapping world.  Yeah!

Keep up the great work, everybody.  I know I am seriously dedicated to this 
project long term.

SteveA
California


> On Aug 14, 2018, at 1:30 PM, Brian May  wrote:
> This may have been stated already, but just wanted to make it clear - State 
> laws on public records filter down through all regional and local governments 
> operating within the state. So if state law doesn't explicitly give a county 
> permission to copyright data, and the county tries to assert copyright, the 
> county is violating state law. If you can get a hold of the data, you can 
> ignore whatever the county says. If you can't get the data and must get it 
> from the agency through formal channels, you need to send a letter and 
> explain the situation. If they don't respond favorably, try the state 
> Attorney General's office. In Florida, the Attorney General weighed in on 
> this issue in the mid-2000s because counties weren't getting the message 
> after a court case clarified the that public records could not be copyrighted 
> or sold at exorbitant prices in Florida for "cost recovery". At that time the 
> Attorney General's office had an open records advocate that would help 
> educate, communicate, and mediate with local governments about public records 
> laws.

>> On Sun, Aug 12, 2018 at 1:05 PM OSM Volunteer stevea 
>>  wrote:
>>> I'm not an attorney, though were I to attempt to sharpen focus on these two 
>>> replies, I'd say that in California, it's more like this:  data produced by 
>>> state agencies (by our state government personnel "on the clock") 
>>> publishing them as "produced by the state of California" cannot have 
>>> onerous copyright terms/restrictions put upon them.  They simply "belong to 
>>> the public."  (This is especially true of GIS data, as in the County of 
>>> Santa Clara and Orange County/Sierra Club cases).
>>> 
>>> So when you say "copyright...owned by the government," that is effectively 
>>> equivalent to "copyright owned by the People of the state" because of 
>>> California's Open Data laws and stare decisis (law determined by court 
>>> precedence/findings).  Whether "public domain" is the correct legal term 
>>> I'm not sure, but if there is a distinction between the legality of 
>>> California-produced data and "the data are in the public domain" it is 
>>> either very subtle or completely non-existent; I consider 
>>> California-produced data "somewhere around, if not actually PD" and "fully 
>>> ODbL-compatible" for OSM purposes.  So, (and I hope this dispels any 
>>> confusion and answers your question, Pine), "created by the government" 
>>> means they can't put "onerous copyright" on it, meaning it is effectively 
>>> owned by the People for any purpose for which We see fit.



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

Re: [Talk-us] State Open Data

[OSM Volunteer stevea]

I'm not an attorney, though were I to attempt to sharpen focus on these two 
replies, I'd say that in California, it's more like this:  data produced by 
state agencies (by our state government personnel "on the clock") publishing 
them as "produced by the state of California" cannot have onerous copyright 
terms/restrictions put upon them.  They simply "belong to the public."  (This 
is especially true of GIS data, as in the County of Santa Clara and Orange 
County/Sierra Club cases).

So when you say "copyright...owned by the government," that is effectively 
equivalent to "copyright owned by the People of the state" because of 
California's Open Data laws and stare decisis (law determined by court 
precedence/findings).  Whether "public domain" is the correct legal term I'm 
not sure, but if there is a distinction between the legality of 
California-produced data and "the data are in the public domain" it is either 
very subtle or completely non-existent; I consider California-produced data 
"somewhere around, if not actually PD" and "fully ODbL-compatible" for OSM 
purposes.  So, (and I hope this dispels any confusion and answers your 
question, Pine), "created by the government" means they can't put "onerous 
copyright" on it, meaning it is effectively owned by the People for any purpose 
for which We see fit.

If there ARE lawyers out there who think I'm getting this wrong, please chime 
in, but I strongly believe this is firm legal ground.

FEDERAL laws are slightly different, and maybe even MORE generous:  data 
produced by federal agencies are "in the public domain" (unless classified as 
Confidential, Secret and Most Secret, which are NOT for wider consumption).

SteveA
California
(and again, not an attorney, though I am an educated person who can read and 
interpret my laws)


> From: Pine W 
> Subject: Re: [Talk-us] State Open Data
> Date: August 11, 2018 at 10:59:55 AM PDT
> To: talk-us 
> 
> I'm interested in this subject. An issue is that the copyright might be owned 
> by the government entity that created it, even if the records are open for 
> the public. If something is public record in California, does that also mean 
> that it's not copyrighted by the government entity that created it?
> 
> Pine
> ( https://meta.wikimedia.org/wiki/User:Pine )


> On Sat, Aug 11, 2018 at 12:01 PM Pine W  wrote:
> I'm interested in this subject. An issue is that the copyright might be owned 
> by the government entity that created it, even if the records are open for 
> the public. If something is public record in California, does that also mean 
> that it's not copyrighted by the government entity that created it?
> 
> Its my understanding that if the state government has an open data law 
> similar to the US, then when they release the data it's public domain. There 
> are exceptions. Sometime they license the data from a company without have 
> the rights to release it as PD. They also have exceptions for not releasing 
> data that has personal information. I sat through a talk by WSDOT. One of the 
> big issues they pressed was to be very careful be for adding data to the 
> state's open data portal. Once it's out in the open, they can't get it back.



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

[Talk-us] An interesting discussion on admin_level about "inclusiveness" with townships

[OSM Volunteer stevea]

There is an interesting discussion initiated by Skybunny on whether townships 
and cities/villages subordinate to them are (or are not) "inclusive" for 
purposes of geocoding.

https://wiki.osm.org/wiki/Talk:United_States_admin_level#Minor_Civil_Divisions.2C_distinguished_by_inclusiveness

I believe a wider audience's participation can offer greater clarity.  Thank 
you in advance for taking a look, especially if you participate,

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

Re: [Talk-us] Whole-US Garmin Map update - 2018-07-03

[OSM Volunteer stevea]

Hello Volker, old friend:

Thank you for the Garmin history, thank you for the additional links!  (I knew 
one, didn't know two).

SteveA

> On July 7, 2018 at 6:23:52 AM, Volker Schmidt  wrote:
> In fact Garmin started using OSM maps aleady in summer 2013 on the edge 
> Touring. This map goes by various names, in Germany it was announced as " 
> europaweiter Garmin Fahrradkarte auf OSM-Basis ", in Italy " Garmin Cycle Map 
> "
> 
> If you are looking for bicycle maps for Garmin on OSM base, try 
>   • Openfietsmap light [1]
>   • velomap [2]
>   • OpenMTBmap [3]
> 
> [1] http://www.openfietsmap.nl/downloads/worldwide
> [2] http://velomap.org/
> [3] https://openmtbmap.org/


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

Re: [Talk-us] Whole-US Garmin Map update - 2018-07-03

[OSM Volunteer stevea]

Yes, indeed!  If Garmin wanted to make its loyal hardware customers a bit 
happier, it could firmware-update how it draws various zoom levels and how much 
detail it those include.  On an "old-school" device like my GPS 60 CSx, it may 
be prudent to trim and prune here and there when using OSM maps (if that can be 
determined, although now, it seems, that may be "more frequently").  However, 
as Elliot has an Edge 820 and even "last week's version" is "sluggish" (with 
OSM maps), a tune-up is prudent.  I believe it is where primary, secondary, 
tertiary, residential roads are drawn at particular zoom levels.  Device 
hardware ROM firmware update, or somewhere around there.

Heck, just like a map update is what Garmin turns into a paid data upgrade, I'd 
pay Garmin several dollars to publish a paid firmware upgrade, especially if it 
was as "smart" (and tuned...) as its data are.  That's clearly a business 
opportunity, too.  I appreciate the good discussion.  Go OSM!

SteveA


> On Jul 5, 2018, at 2:55 PM, Martijn van Exel  wrote:
> Also, if Garmin can sell OSM maps for US/Canada for $50 there is a clear 
> business opportunity there.


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

Re: [Talk-us] Whole-US Garmin Map update - 2018-07-03

[OSM Volunteer stevea]

I frequently download Dave's Garmin images for my (fairly ancient, yet still 
trusty!) Garmin GPS 60 CSx.  (The fact that it runs on two AA NiMH rechargeable 
cells I can rotate into a pocket-sized solar charger while I'm in the 
wilderness has something to do with this).  Yes, I have noticed that as the CPU 
in my Garmin GPS 60 CSx remains the same (obviously), yet the density of OSM 
data from the SDHC card gets denser (especially in urban areas at medium-zoom), 
it REALLY slows down screen-drawing on the Garmin.  This is problematic, but 
only during initial draw or re-draw as I change zoom.  Basically it means I 
shouldn't fiddle Garmin zoom levels (In OR Out) while in dense urban areas 
unless I'm prepared to wait maybe 30 seconds for a full screen refresh, 
possibly missing upcoming navigation cues.  Otherwise, navigation and "the map 
moving along with me" (whether ped, bike or car) work just fine once the screen 
draws at any particular zoom level, even in dense urban areas.

As an aside, if Garmin (a well-respected GPS developer/manufacturer) has 
"switched" to using OSM (even if only ONE of its products!), that says a great 
deal of "wonderful" for the quality of and confidence in our data.  (Which have 
for some time found their way into Telenav's Scout products, too).

I also appreciate learning about alternatives (I didn't know about the Fenix 
link either, thanks, Martijn), and also didn't know that Garmin's own map is 
OSM-based.  Are we sure about that?  Garmin's "built-in" maps didn't used to be 
OSM-based (obviously), when did that change?  (Yes, it may be that different 
maps — some OSM, some not — are used for different 
car/bike/hike/golf/fitness/whatever products by Garmin).  If anybody knows this 
Garmin map history, I'm eager to hear it.

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

Re: [Talk-us] named links

[OSM Volunteer stevea]

While I don't have "a dog in this fight," I also read our wiki which says "Link 
roads NORMALLY do not have names."  (Emphasis mine).  In the unusual 
(abnormal?) cases where they do (and I trust Paul wouldn't have added them 
unless they do), there is no contradiction with our wiki, rather an unusual 
case which isn't "normal."  In my opinion, that's OK.

We should follow what our wiki says, in this case it leave a bit of "wiggle 
room" to name a link road.  Paul has named some link roads where it appears 
they do have such names in the real world, and I see no inconsistency.

Sometimes a datum in OSM will LACK all the tags it should, because some are not 
known.  That's not great, but it's OK:  mappers who come along later can add 
these (and improve this and other features in our map), this is called "growing 
our map."  Sometimes an ADDITIONAL datum exists in the real world and is added 
to a feature even when this is unusual (though not incorrect) as many other 
similar data do not have this additional datum.  That's OK; I see no 
inconsistency.

Our wiki strives to hit the sweet spot of accommodating what is in the real 
world and how we should tag such data in our map.  It is a guide, not 
absolutely strict doctrine.  I say this because we have "plastic tagging" that 
encourages us to tag accurately while allowing flexibility.  Especially in 
early versions, we may not always write our wiki as 100% correct, and so wikis 
grow, change and evolve to accomplish this.  If the wiki needs updating to note 
that unusually, but in certain parts of the world, link roads sometimes get 
names, I encourage you to update it:  we'll all benefit.

Writing/contributing to wiki is easy, though it can be tricky:  you want to 
channel consensus without being too strictly doctrinaire in a direction which 
would hobble contributions or just plain encourage/teach others to enter them 
wrongly.  It is meant to guide us, not preach to us as an absolute.  Where it 
is wrong, or one or more believe it wrong or out-of-date with real world data, 
please use the Discussion page built into each wiki to discuss with others any 
potential changes to existing wiki.  The "right thing" (better written wiki) 
usually happens soon after such discussion.

SteveA
California
OSM Volunteer since 2009 and serious contributor to not only our map's data, 
but our wiki, too
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Slack: Do we need an Alternative (was Planning an import in Price George...)

[OSM Volunteer stevea]

> Clifford Snow  wrote:
> I must admit I like Slack better than some other forms of communications.
Truly, I think that's great.  And again, the many forms of communication OSM 
uses, including new ones, are a natural part of a project as large and diverse 
as OSM is.  There ARE a great many, some of which "resonate with an appropriate 
audience, in a certain niche" better than others.  As has been described here, 
Slack is claimed by its users to appeal to a certain niche of "chat," Jeffrey's 
X, Y, Z examples are excellent descriptions.

> For example, I don't participate on any OSM forums. IRC is nice, but the 
> Slack, as a version of IRC, is just better. Since Slack was introduced to the 
> community I've notice the talk-us mailing list traffic has slowed and even 
> more so is the #osm-us IRC channel which for all practical purposes is dead.

With another OSM volunteer here on an email back-channel, I now discuss early 
thinkings about an existing, working-for-years software bridge between IRC and 
Jabber/XMPP he uses that sounds like it could mimic aspects of Slack using open 
source.  Not a huge amount of effort modifying this software bridge could 
breathe new life into IRC as it is/can be used by OSM participants.  This is a 
medium-scope back-burner for me right now, but it shows with a little glue and 
effort, open source can be leveraged yet again to fill a desire/need.  Peering 
off into the distance a bit, I am here.

> Communications within the community is one of the most important aspects of 
> what makes our community thrive. We need tools that allow people to be 
> engaged in discussions and process to be successful. Tools that people want 
> to use. To me, seeing the number of people that use Slack compared to other 
> forms of communications, means the community has chosen. 

Precisely what I wish OSM to guard against:  the false choice that "choosing" 
one means a certain exclusivity of others.  A "danger" here (as well described 
by Frederik) is to freeze out participation, as in "hush, we discussed this on 
Slack last year and you weren't there."  Such exclusivity enables this, we 
don't want this, (as you state, communication is vital), and "the community has 
chosen" seems to contradict or at least clash.

> I'm also part of a open source community that uses IRC and mailing lists to 
> communicate. When Slack was introduced, just like OSM, traffic drop to 
> nothing on IRC and mainly announcements on the mailing list. Part of that 
> maybe because people use Slack in their day job.

"People use" is only the subset who do.  Importantly, that is a long, long way 
from everybody, or being inclusive towards communication in our very wide 
community.  In fact, it bumps up against that danger of exclusivity I want to 
call attention to so we avoid it.

> I don't wouldn't have any objections to another platform with more agreeable 
> terms of service. But what specifically to Slack's terms is objectionable?

Rather than "get lost in the weeds" of specific paragraphs I find objectionable 
and why...(yawn, snore), I believe this list resonates enough with a 
higher-level description of "commercial software, with (perhaps) onerous or 
difficult-to-agree-with clauses/paragraphs, and the entire proprietary nature 
that being commercial and licensed implies."  We're adults, though it has 
gotten much easier to blithely click an "I agree" button and now you are under 
the thumb of the publisher of the software, with very, very little ability to 
negotiate better terms (more openness/transparency, more clarity with regard to 
data ownership and retention...).  "Open source vs. proprietary" is an even 
more brief way to say it that most people can understand.  The concept is also 
well-respected, and all over the world, too.  Not to mention it resonates well 
with OSM, whose first name, after all, is Open.

> I'm also interested in how others feel about Slack. Is it good for the 
> community or should we look elsewhere?

Again, it isn't "either-or" and some kind of false choice of "let's standardize 
on one thing."  We not doing that, we shouldn't do that.

Thank you for the +1, Mark.  Jeffrey, yes, "too much control in the hands of a 
commercial entity" is concise (and a good start, even enough).  As well as X, 
Y, Z and "noise tends to overwhelm signal" and "real-time can exclude 
less-dedicated members."  Excellent, all of these.

Maybe the best thing to come out of this is wider discussion of the many 
communication methods OSM DOES use, and how they fit into niches and particular 
workflows, and what works (better, worse) and what doesn't.  That should be 
ongoing, anyway, so I suppose we can say we're doing OK.  I often wish us to do 
better, nudge, nudge.  Sometimes that begins with good discussion.  Look, we 
presently have here a rough initial inventory of communication 
methods/channels/protocols/software.  I'll take that as a good beginning.

SteveA
California

Re: [Talk-us] Planning an Import in Prince George's County, Maryland

[OSM Volunteer stevea]

> Clifford Snow  wrote:
> If you haven't already joined our US Slack community, please sign up at 
> https://osmus-slack.herokuapp.com/. The community can help you with build 
> your import plan.

Having met Clifford two summers ago, I admired, marveled at (and congratulated 
him upon!) his awesome community organization skills.  I have "done OSM" with 
him via talk-us, face-to-face (we briefly spoke at SOTM-US Seattle), email and 
wiki to better our map — all using these terrific relatively freely-available 
methods of communication — and none of them requiring that I accept a License 
Agreement.  To be clear:  I have great respect for both Clifford and the 
open-platform communication methods by which we (and many others) "do OSM" 
together.

At least once, Clifford invited me to join Slack as well.  However, after 
reading Slack's Terms of Service Agreement (a contract of adhesion, really), I 
could not and do not abide with the ways which Slack (and other proprietary, 
not-open-source/open-data communication platforms) divide our community into 
"those who Slack" and "those who don't."  Even as Clifford has acknowledged 
this issue in these posts, I feel compelled to speak up about this again 
whenever I see this invitation to Slack again and again.

I don't wish to throw rocks at the good process and results which happen 
because some of us collaborate on Slack.  I do wish to urge OSM volunteers to 
seriously (re-?)consider that there are well-established, perfectly useful 
communication methods (email, wiki, talk-us, face-to-face, meetups/Mapping 
Parties...) which do not require "shiny apps laden with hidden, commercial 
code" that ask us to cloak our communication into the private realm of a 
for-profit company.  As an open-source/open-data project, I remain puzzled why 
OSM volunteers do this.

Perhaps what I'm suggesting (again?  I seem to recall it has been brought up 
before) is that if OSM uses a "live-collaboration communication app" that we 
either develop our own or choose some open-source version of one without 
onerous License Terms that MANY (not just me) find offensive.

Is that possible?

Thanks for reading.  I mean this in the best interests of OSM longer-term.

SteveA
California
OSM Volunteer since 2009
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

[Talk-us] Central Oregon & Pacific Railroad: usage=branch -> usage=main?

[OSM Volunteer stevea]

I realize that distinctions between railway=rail + usage=* tags is subjective 
(even as OpenRailwayMap — ORM — renders main orange and branch yellow).  Full 
disclosure:  I have tried to sharpen focus in contributing to 
https://wiki.openstreetmap.org/wiki/OpenRailwayMap/Tagging and related wiki re 
OSM rail tagging.  I am in a listening mode as I do so and don't wish to be too 
aggressive in positing anything too new or too controversial.

I have not done a comprehensive review of how many Class II railroads (a 
category of regional railroad in the USA which is not usually as "short line" 
as Class IIIs, but neither is it as large as the mighty Class Is) are tagged 
usage=main vs. usage=branch.  I suppose I now toss out as an interesting 
question in the USA (Overpass Turbo can query) a wider beginning of consensus 
regarding Class II railroads being tagged usage=main instead of usage=branch.  
In short, all discussion is welcome:  calling all interested parties.

Starting with Central Oregon and Pacific (reporting mark CORP, in rail-speak) 
now being tagged usage=branch, might this better be tagged usage=main?  Should 
other USA Class II railroads be tagged usage=main as a matter of course?  I'm 
leaning in that direction, suggesting that CORP and other Class II railroads 
see usage=* tags become main (if not main, be changed from branch to main).

Comments?  This includes soliciting Comments from overseas readers, like in 
Germany...those who wrote the ORM renderer and "watch" (and at least pay 
attention) to such things.  (The concept of "Class II" railroad might literally 
be a foreign concept, but I believe European, Chinese, Japanese, Taiwanese, 
Korean, pan-Asian, African, Australian, South American...all worldwide OSM rail 
mapping watchers can understand Class II in the context of "USA Rail"):  these 
are "medium/regional-sized" railroads, measured economically by revenue as 
"between large interstate carriers and short line/more-local carriers."

If you are a rail fan / rail buff or otherwise find OSM rail-useful, please 
consider chiming in here and now as a way to better establish a modicum of 
sub-community (OSM-US rail interest).  I have heard from many over the years 
and consider hearing from others a polite nod in this direction.  I also 
welcome all others and all "new comers" (from my limited perspective) — those 
with whom I have no idea you are "out there."  Thank you.

Perhaps https://wiki.osm.org/wiki/Talk:OpenRailwayMap/Tagging_in_North_America 
is a place to further discuss, as at least one open issue is under discussion 
there (by happy5214) now.  Or, we can discuss here.

Happy holiday weekend (perhaps belated as you read this),
SteveA
California
___
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

[OSM Volunteer stevea]

The legacy of TIGER-tagging will persist in OSM for a long, long time.  That is 
the reality of the import we did, rough/sloppy data and all.  This legacy 
serves as many lessons to be learned regarding the practice(s) of wide-scale 
imports.  If it sounds like I'm saying "we made this bed, so now we must sleep 
in it," you are correct.  There are no easy solutions, though there may be 
better ones.

As TIGER data remain a dominant source of road/highway data in the US (plus 
MANY improvements), obfuscating their source in the guise of "cleaning up their 
history" does not help.  In fact, a wholesale deletion of tags different than 
we delete them now (and have) hinders the continuing clean-up/improvement of 
these data.  I elect to continue to clean up noisy/messy/sloppy TIGER data 
where/when/as I can.  When these data reach a state of "good enough that I 
would enter them into OSM" (as good OSM Contributors, we share such judgements) 
I remove the tiger_reviewed tag.  I support others who do so, too.  Largely 
speaking, this is how we'll "solve" this, although solving with smarter/better 
solutions is certainly welcome.

Slowly, slowly indeed, we clean up TIGER.  It will take years, it may take 
decades.  I 100% support talking about strategies (especially better ones) to 
do so, I support the chip-chip-chip away at messy data that need improving as 
we have since TIGER finished uploading.  However, wholesale deletion of tags, 
as doing so contradicts the workflow we have evolved, no, I do not abide that.  
Should we want to improve that workflow, I'm listening.  But (politely, 
Clifford) I reject that the tiger:reviewed tag has lost all meaning.

We can be more clever, we can be more zealous, but let's not be more blind.

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

[Talk-us] United States Bicycle Route ballots pending AASHTO approval

[OSM Volunteer stevea]

It's a busy time for new national bicycle routes in the USA's USBRS!  To help 
OSM "get ahead of the curve" of May's AASHTO ballot, several USBR applications 
by state DOTs have been made available, allowing OSM to enter these 
state-at-a-time national bicycle route data.  Currently

a USBR 35 realignment in Michigan,
USBR 50 in Nevada,
USBR 66 in Missouri and
USBR 221 and USBR 421 re-numberings

are Spring 2018 ballot items which have been completed or need no additional 
work in OSM, while

USBR 15 in Georgia and
USBR 36 in Pennsylvania

have been "seeded" as route relations at termini, yet still need to be fully 
entered into OSM.  Please visit our wiki 
https://wiki.osm.org/wiki/WikiProject_U.S._Bicycle_Route_System for links to 
the route data ballots (OSM-US has explicit permission to enter these).

USBRs 21 and 25 in Ohio, while "rumored" to be on this semi-annual ballot, do 
not have what OSM considers as route data from ODOT suitable to meet OSM's 
"high bar standard" sufficient to enter into OSM.  When/as these data become 
available (likely as an AASHTO application), the project will endeavor to make 
these data more widely available.

So if you're in Georgia or Pennsylvania (or even if not!) and want to help 
build Earth's largest official cycling route network, check it out and have fun!

SteveA
California
USBRS in OSM guy (among other hats I wear)
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

[Talk-us] USBR 66 in Missouri data available

[OSM Volunteer stevea]

The Spring, 2018 AASHTO ballots for new USBRs are now becoming available.  If 
you wish to enter data into OSM for USBR 66 in Missouri,

https://www.dropbox.com/sh/46ztv3epkgj5kv9/AABiIcGZILoUnSckJqzD0uNda?dl=0

downloads route data, including turn-by-turns and 30+ pages of rather nice, 
clear-enough maps.  (OSM-US has explicit permission to enter these).

Mention your progress on our wiki 
https://wiki.osm.org/wiki/WikiProject_U.S._Bicycle_Route_System#Proposed_USBRs_in_OSM
 and have fun!

Steve All
OSM/USBRS volunteer (among others)
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Amtrak network=Amtrak tagging

[OSM Volunteer stevea]

Neither this talk-us list nor I have received any response to my request for 
comments (on- or off-list).  Hence I might believe it is safe to assume there 
is no widespread opposition to harmonizing the network=* tag on all Amtrak 
routes to network=Amtrak without further subdividing values within that 
key-value pair (as below).  Again, the passenger=* tag (as below, with values 
[suburban, regional, national, international]) now denotes the kind of 
passenger service available without subdividing the single network of Amtrak, 
which seems a valid justification for setting all Amtrak routes to be 
network=Amtrak.  We can take further Discussion on this to 
https://wiki.osm.org/wiki/Talk:Amtrak.  Thank you.

While our Amtrak wiki characterizes many route=train relations as "rough," they 
continue to improve (better tagging as above, public_transport:version=1 being 
upgraded to v2, underlying infrastructure route=railway relations created with 
members that are better named and with correct usage=* tags, many platforms 
have been added thanks to the "Add platforms" MapRoulette challenge...).  The 
US has one of the largest, if not THE largest rail and passenger rail networks 
on Earth, it is a large task to improve the many pieces to be "world-class 
passenger train route data."  OSM is well underway towards this goal and 
progress has been steady for several years.  See 
https://wiki.osm.org/wiki/Amtrak and/or 
https://wiki.osm.org/wiki/WikiProject_United_States_railways if you wish to 
participate.

Did you "play with trains" when you were younger?  Please help improve OSM's 
"national train set" in the US:  it's actually rather fun!

SteveA
California


> On Apr 3, 2018, at 11:08 AM, OSM Volunteer stevea <stevea...@softworkers.com> 
> wrote:
> 
> I remain listening as to what OSM might best do with the network= tag on 
> Amtrak routes.  Some additional research (Wikipedia) reveals that "Amtrak 
> services fall into three groups:  short-haul service on the Northeast 
> Corridor, state-supported short haul service outside the Northeast Corridor, 
> and long-distance service known within Amtrak as the National Network."  (It 
> is not known what routes are in this "National Network.")  As for 
> "international" routes — there are three which continue into Canada — these 
> are not mentioned, although it may be that these three international routes 
> are considered to be in the National Network.
> 
> Current tagging (passenger=*) of national, regional and suburban (meaning 
> "commuter") seem to correlate quite well with these three groups, and the 
> three international routes are indeed tagged passenger=international.  But 
> that is the passenger=* tag, not the network=* tag.  I still wonder (out 
> loud, here) whether all their network=* tags should be set as simply 
> network=Amtrak or whether these three (four, really) groups should be set as:
> 
> network=Amtrak Commuter (on Amtrak routes which are now set to 
> passenger=suburban, meaning "commuter"),
> network=Amtrak Regional (on Amtrak routes which are now set to 
> passenger=regional),
> network=Amtrak National (on Amtrak routes which are now set to 
> passenger=national),
> network=Amtrak International (on Amtrak routes which are now set to 
> passenger=international).
> 
> Because these seem redundant, given the same information can be gleaned from 
> the passenger=* tag, all Amtrak routes set as:
> 
> network=Amtrak
> 
> is what I'm leaning towards doing.  Although, I do remain listening to 
> opinion/guidance from anybody here on talk-us, including pointing me to 
> additional on-line authoritative data.  We're talking about fifty or fewer 
> route=train relation tags, not huge.  Though, as the Northeast Regionals (and 
> other Amtrak routes) break out of rough public_transport:version=1 and grow 
> into version 2 routes, this number will grow.  This is partly why I want to 
> establish network=* tagging as correct, to get ahead of this curve.
> 
> Thank you for reading,
> SteveA


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

Re: [Talk-us] Amtrak network=Amtrak tagging

[OSM Volunteer stevea]

I remain listening as to what OSM might best do with the network= tag on Amtrak 
routes.  Some additional research (Wikipedia) reveals that "Amtrak services 
fall into three groups:  short-haul service on the Northeast Corridor, 
state-supported short haul service outside the Northeast Corridor, and 
long-distance service known within Amtrak as the National Network."  (It is not 
known what routes are in this "National Network.")  As for "international" 
routes — there are three which continue into Canada — these are not mentioned, 
although it may be that these three international routes are considered to be 
in the National Network.

Current tagging (passenger=*) of national, regional and suburban (meaning 
"commuter") seem to correlate quite well with these three groups, and the three 
international routes are indeed tagged passenger=international.  But that is 
the passenger=* tag, not the network=* tag.  I still wonder (out loud, here) 
whether all their network=* tags should be set as simply network=Amtrak or 
whether these three (four, really) groups should be set as:

network=Amtrak Commuter (on Amtrak routes which are now set to 
passenger=suburban, meaning "commuter"),
network=Amtrak Regional (on Amtrak routes which are now set to 
passenger=regional),
network=Amtrak National (on Amtrak routes which are now set to 
passenger=national),
network=Amtrak International (on Amtrak routes which are now set to 
passenger=international).

Because these seem redundant, given the same information can be gleaned from 
the passenger=* tag, all Amtrak routes set as:

network=Amtrak

is what I'm leaning towards doing.  Although, I do remain listening to 
opinion/guidance from anybody here on talk-us, including pointing me to 
additional on-line authoritative data.  We're talking about fifty or fewer 
route=train relation tags, not huge.  Though, as the Northeast Regionals (and 
other Amtrak routes) break out of rough public_transport:version=1 and grow 
into version 2 routes, this number will grow.  This is partly why I want to 
establish network=* tagging as correct, to get ahead of this curve.

Thank you for reading,
SteveA
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Amtrak network=Amtrak tagging

[OSM Volunteer stevea]

On Mar 25, 2018, at 11:09 PM, Greg Morgan  wrote:
> I wonder what to do with some of the routes.  For example, additional tracks 
> were added in the Tucson area. If we add a route, say, us 60 then an east and 
> west relation is created along with a master route. Do we do the same with 
> rail routes or are all the rails thrown into the same relation?

Hi again, Greg:

What I see in Tucson is "Sun Link" tram/streetcar, 
https://www.osm.org/relation/3920972 added over a year ago.  It is tagged as a 
public_transport:version=2 relation, though I don't think it is as I don't see 
a master_route relation.  If you want to take a look at that and check it / fix 
it up (even to simply retag it as a correct/ed v1 route), that would be great!  
If by "some of the routes" (in the Tucson area) you mean some other rail 
infrastructure, I'm curious to know which you mean.  Union Pacific rail through 
Tucson remains poorly tagged from its original TIGER import days and can use 
cleanup as described in our

https://wiki.osm.org/wiki/WikiProject_United_States_railways#Editing_Railroads_starting_from_TIGER_data
 .

Yes, assembling railway=rail into route=railway and route=train (light_rail, 
tram, monorail...) relations can be tedious and a bit confusing until you get 
the hang of it.  Good news:  we wiki-document how to do this fairly well.  In 
"other" news, there remains a great deal of work to do in USA Rail!

Not to sound too much like a "lonely heart rail mapper" calling across the 
chasms of talk-us, looking for more kindred spirits who OSM rail in the USA, I 
am doing that here and now, as I'd like to better establish contact with 
additional active USA rail mappers.  In the last few years OSM has grown 
statewide rail wikis (now at eight, nine...so, still forty-something to go!) 
and I know I'm not the only mapper who wants to keep momentum going to 
wiki-document all 50 states' rail infrastructure and passenger routes.

Thanks in advance for any answer/mapping you might offer,
SteveA
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Amtrak network=Amtrak tagging

[OSM Volunteer stevea]

You're quite welcome.
Steve

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

Re: [Talk-us] Amtrak network=Amtrak tagging

[OSM Volunteer stevea]

I should have included:

https://wiki.openstreetmap.org/wiki/WikiProject_United_States_railways

as that is a better starting place (for your flavor of question) than our "at 
the top" Amtrak wiki.

There's a lot to grok to become a good OSM rail editor (and don't forget 
updating wiki), yet, many of us are doing exactly that!

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

Re: [Talk-us] Amtrak network=Amtrak tagging

[OSM Volunteer stevea]

Hi Greg:

Great questions.  If you are a rail public_transport:version=2 super-jockey, 
hey, polish them up to a firm buff and we'll marvel at their brilliant shine!

However (and this is pedestrian me), I make "better" progress (higher quality 
data, at the expense of being slower) following roughly these steps to get to 
version 1, first.  Though these ordered steps are not strictly required, after 
much experience, I find this flow works and "teaches/practices me into becoming 
a better JOSM rail editor" (and others watching in the map, and progress in the 
wiki...) as I go:

1)  Tag the rail infrastructure correctly with railway=rail (or light_rail, 
subway, tram, monorail...).  If it was TIGER-imported, change its name=* tag to 
operator=* and if you know it, add a name=* tag (like XYZ Subdivision or Orange 
Line Light Rail).  Set a usage=[main, branch, industrial...] tag.  Don't 
include service=siding, service=yard, service=crossover, service=spur in 
route=railway relations, just the "main" line (even if it is tagged 
usage=branch).

2)  Gather same-infrastructure, same-name, same-operator, same=usage, "in the 
same subdivision or track set" into one route=railway relation.

3)  If not light_rail, subway, monorail or tram, make a route=train relation 
which has the elements of that route=railway relation, plus railway=station 
nodes.  (If tram, they might be rail=tram_stop nodes...there is also platform 
tagging, which is for v2, we are getting there).

With those steps, you've made a route=railway (important!) as well as a v1 
train route.  As for extending these to v2, that's more complex and is outside 
the scope of a talk-us post, I'll not do it here, we have wikis for this.

"Starting at the top" (national passenger rail) is 
https://wiki.osm.org/wiki/Amtrak.
There are several state Rail wikis, a simple one is 
https://wiki.osm.org/wiki/New_Mexico/Railroads, 
a medium-complexity one is https://wiki.osm.org/wiki/South Carolina/Railroads,
a ridiculously-complex one is https://wiki.osm.org/wiki/California/Railroads.

These are usually about 75%-80% descriptive of route=railway relations (the 
underlying infrastructure, which carries both freight/industrial traffic and 
sometimes also passenger traffic) and maybe 20%-25% descriptive of route=train 
(or other passenger rail, like tram, light_rail or monorail).

See https://wiki.osm.org/wiki/Relation:route (train, light_rail...) wiki to get 
to v1, and https://wiki.osm.org/wiki/Relation:public_transport to grow these to 
v2 (underway now all over the world there are v1 train routes in OSM).

Happy to help,
Steve

> On Mar 25, 2018, at 11:09 PM, Greg Morgan  wrote:
> 
> I wonder what to do with some of the routes.  For example, additional tracks 
> were added in the Tucson area. If we add a route, say, us 60 then an east and 
> west relation is created along with a master route. Do we do the same with 
> rail routes or are all the rails thrown into the same relation?
> 
> Regards,
> Greg

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

[Talk-us] Amtrak network=Amtrak tagging

[OSM Volunteer stevea]

Gee, what a lot of good chatter here on this list!  However, neither this list 
(nor this requestor) have heard a peep about changing a couple dozen Amtrak 
route network=* tags so all have value Amtrak.  Too easy?  I might simply ask 
forgiveness rather than permission or for feedback, though consensus still 
doesn't feel it has fully emerged, so I'll hold off on this minor change until 
at least somebody says something!

Rail USA does slowly and surely get better.  Nice to be here, everybody.

Remaining in listening mode,
SteveA


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

[Talk-us] Amtrak network=Amtrak tagging

[OSM Volunteer stevea]

Per our Amtrak wiki, https://wiki.openstreetmap.org/wiki/Amtrak , I'd 
appreciate some feedback on conflating all Amtrak route=train relations to be 
tagged network=Amtrak.  Currently, some have this tag, some have network=Amtrak 
Intercity.  I find the latter to be superfluous and confusing and would like 
them to all have the same network=Amtrak tag.  Does this seem reasonable?

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

Re: [Talk-us] Help fight advertising

[OSM Volunteer stevea]

So many good things being said by so many good people here.  This is OSM at its 
best:  organically growing goodness and correct actions by right-thinking 
people.  Be bold, we might say out loud, as in "I delete spam and even just 
plain bad mapping when and as I see it."  (Whether front door, back door, with 
the help of our fellow mappers at a Mapping Party...whatever).  Thanks to all 
who say and do that!  "Right mapping" is attitude as much as action.

Taking either/or approaches is something we acknowledge as short(er)-sighted; a 
multi-pronged approach including everyman/pedestrian works (like my example), 
as well as the kinds of "some investigations" that Paul mentions – there truly 
are bad actors to whom we must apply our realistic and efficient repairs.  
Smart behavior (analytics log analysis, similar/usual white-hat tools) can 
complement "bread crumb trails to do the right things" approaches, too.  (Good 
dialog happens!)  Wiki as I suggested of a regional flavor (let's start with 
USA) of an "anti-spam/SEO, vandalism skill-building strategies..." is possible, 
similar to what we're saying here, but "sticks to the wall a bit more, 
wiki-searchable by those looking for it."  As will individuals with pride in 
making and keeping our map as spic-and-span as we can.  (The core of why "let's 
everybody keep it nice and clean around here" works).  ALL of the above and 
even more as we develop these strategies.  It's very much like cooperative 
folks living together someplace agreeing to do the cleanup chores in as smart 
and efficient way as we can.  As, that is what successful projects like ours 
do:  cool heads prevail.  What a great dialog, even feels a bit 
historical/epic.  OSM is fantastic, like Rosie the Riveter swinging her fist, 
"We can do this."

Curating this discussion to wiki doesn't seem a lengthy task.  Might we see a 
WikiProject USA/Help fight advertising emerge?

SteveA

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

Re: [Talk-us] Help fight advertising

[OSM Volunteer stevea]

Even as I knew my "contact one SEO/Marketing firm, see what happens" approach 
was quite pedestrian in the grand scheme of "fighting advertising," I still 
though it valuable to share with the talk-us list so others could experience it 
too, put on their thinking caps and offer additional approaches.

And we have!  I want to thank everybody for EXCELLENT suggestions on how to 
better approach (and likely solve) this problem, especially the ones that avoid 
antagonistic, confrontational and/or harsh behavior and better lead these folks 
down the garden path of "if you are going to do this, we'll make it EASY for 
you to do it the RIGHT way."  Awesome, everybody!  Let's keep up the good work 
and really follow through on these!

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

Re: [Talk-us] Help fight advertising

[OSM Volunteer stevea]

Sent to Bright Valley Marketing via their website Contact text box:

How can you help me?  More like how can YOU help Bright Valley Marketing?!

OK:  you can stop putting advertising into your clients' OpenStreetMap (OSM) 
nodes.  Phone, website, opening_hours, addr: fields:  those are all OK.  The 
breezy text in the note: field that not only smacks of advertising but actually 
goes way too far and BECOMES advertising, especially in a volunteer and 
non-profit project like OSM:  No.  Absolutely, positively, no.  Also, the 
payment field should not say a single word about financing, especially 
business-offered financing.  This crosses the line into sleazy, many are 
watching what you are doing here.

We are asking you politely to stop doing this.  Starting right now.  Please 
reply to this so I know you have received this message.  I will likely accept 
your apology for abusing our project should you have the honor to offer one and 
it accompanies your understanding to cease and desist these practices.

SteveA
OpenStreetMap volunteer

(A little harsh?  Maybe.  Maybe not.)
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Help fight advertising

[OSM Volunteer stevea]

I phoned a local business owner from Frederik's list and learned he used 
"Bright Valley Marketing" (https://www.brightvalleymarketing.com) out of 
Sacramento, California:  it was they who apparently are the culprit.  The 
business owner was happy to recognize and vaguely seemed to understand the harm 
to both his business and OSM, then encouraged me to remove the ad "from 
whatever seems to be bothering you, Steve."  After I said that we're trying to 
get these kinds of SEO firms to change their business practices, he wished me 
"good luck with that."  Good, honest, done in sixty seconds, actionable and now 
you know, too.

One down.  (Who is going to call Bright Valley and chew their ear off?)  I put 
some good soul into this project (Frederik), what's the script for next?

SteveA

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

Re: [Talk-us] Help fight advertising

[OSM Volunteer stevea]

Thank you Frederik, thank you Ian.  Yes!  To both of you.

I am glad to see Frederik encourages me to do what I (somewhat timidly, at 
first) already now do in earnest:  sweep up when I see some poop in our map.  
It took me many years to grow my confidence as an OSM volunteer as "somebody 
who knows what he is doing" and I still do this with very reserved pride and a 
touch of caution and trepidation that I might go too far, then I aim for the 
sweet spot of "this is how we map" and it is good.  Please, I encourage all of 
us to stand up straight (even on our tiptoes every once in a while if we must 
reach for mature editing skills) and screw up our courage and confidence to do 
this very important work.  It is vital to the future of OSM.

I would also like Ian to follow up (here, in a week or three) with what he 
learned about "real analytics-based research yielding excellent intelligence 
that this minor-to-moderate problem is N # of SEO firms, and we are watching 
certain IP addresses."  (Or something similar, like a newer wiki page like 
"region-based anti-vandalism skill development").  You know, what smart people 
with good tools do when "paint bombs are being thrown at our canvas."  Let's be 
those smart people and use those good tools, developing them with good dialog 
and documenting what we mean to do.

Happy mapping and have a great day!

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

Re: [Talk-us] Satus CDP

[OSM Volunteer stevea]

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

Thank you for your perspective Albert, and while you didn't ask a direct 
question, I am left with a couple myself after reading your observations:

Are these actually "towns" (or "cities") and so should be mapped 
boundary=administrative and admin_level=8?
Are these actually "suburbs" and so should be mapped as nodes tagged 
place=suburb inside of cities (which are mapped as the previous sentence)?

Noting in our United States admin_level wiki that a particular state SHOULD map 
with a particular "rungs on the ladder" hierarchy of particular admin_level 
values is useful, since by consensus we took our time to get those correct for 
that particular state.  THEN, there are assigning proper values on those proper 
entities, whether they came from the Census Bureau or need to be created/come 
from some other source.  If a census boundary exactly matches a city or town 
boundary, for example, (though it might prove challenging to discover or verify 
that), well, by all means:  rather than deleting that tagged polygon, we can 
simply change the tags from boundary=census to boundary=administrative, add an 
admin_level=8 tag (perhaps add a border_type=city tag) and be done until the 
next decennial census.

However, that's the tricky part: IS that Census Bureau-produced boundary truly 
the town or city boundary?  Or is it simply (and likely incorrectly) a "Census 
Bureau-produced boundary of census tract agglomerations" rather than a true 
corporate boundary as denoted by the city itself (or its parent state)?  Either 
might be correct, but as of now, data in our map are not sure.  In OSM, I'd 
like the data surely to be what it claims to be.  I don't believe we have that 
today with many Census Bureau boundaries, except that they denote a "boundary" 
of some sort:  sometimes correctly denoted "census" with no admin_level value 
(but should have one on a different and correct polygon), sometimes incorrectly 
denoted "administrative" with a questionable (maybe correct, maybe not) value, 
but on a polygon which is Census Bureau produced and possibly incorrect, 
possibly correct but we don't know that the Census Bureau exactly mapped a 
corporate boundary 

Locally speaking, they might appear to be "better than nothing, at least until 
the next decennial census," but ask yourself:  what are these really denoting?  
If the answer is "we don't know if this is a corporate boundary or not" then we 
must at a minimum change the boundary tag from administrative to census, 
deleting any admin_level tag.  (Taking note amongst ourselves that these 
boundaries are marginally useful at best, especially when there are entities 
like towns and cities that deserve to have their corporate boundaries in our 
map).

We've already achieved consensus that "CDPs are lesser entities."  I'm 
suggesting we go ahead and delete them as noise (except in truly useful 
circumstances absent any "better" data, as in Alaska).  Superseding them with 
better data:  I'm all for that where we can do so.

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

Re: [Talk-us] Satus CDP

[OSM Volunteer stevea]

Brian Stromberg  writes:
> As someone who does research with Census data, it would be helpful to keep 
> all Census geographies in place (at least until Census decides to get rid of 
> them). Someone will use them at some point. Additionally, they're an official 
> component of Census geographies, as bureaucratic as that might be. That alone 
> seems to make them significant enough to keep. Deleting them because they 
> appear useless seems short sighted. It's not like roads are deleted from OSM 
> just because nobody uses them.

Brian, Wolfgang, Clifford, Michael, talk-us:

Census boundaries were imported, then, after these data were already in our 
map, consensus was reached that these were statistical areas, not 
administrative areas of government.  Specific consensus was reached (in 
talk-us, if I recall correctly) on the following:

• admin_level=8 was simply incorrect and should be deleted as a tag on these 
imported census boundaries,
• boundary=administrative was also incorrect in all cases and should be changed 
to boundary=census as a tag on these.

It is also specifically noted in our wiki[1] that in Alaska, as these 
boundaries were achieved with the cooperation of the Alaska state government in 
addition to the US (federal) Census Bureau, census boundaries in Alaska's 
Unorganized Borough are believed to be useful enough to keep in OSM, but, 
again, specifically without any admin_level tag, as (to repeat), census areas 
are not administrative boundaries.

This consensus has resulted in most (all?) of these admin_level=8 tags (some 
were 7, likely from subsequent edits) being (correctly) removed and the 
boundary=administrative tag being (correctly) changed to a boundary=census tag, 
though this work to correct these Census Bureau import data may not be 
complete.  The result is that what data do remain in OSM (what Brian says would 
be helpful to keep in place) are of marginal value (except in Alaska and 
perhaps a very few other places).  If/as Brian finds these data useful, I 
caution him to keep all of this in mind and perhaps find another methodology to 
"do research" with these data of questionable value than by using them as they 
presently exist in OSM.  I politely disagree with him that "someone will use 
(these data) at some point," for several reasons:  the data age and are not 
updated, they do not "map" (in a language or mathematical sense) well onto 
specifically-rendered entities in any OSM renderer I know of, and (imo, I could 
be wrong) they only serve to add some sense of accuracy to perhaps geocoding or 
place-name lookups in what amounts to "hacked" corner cases.  OSM can do much 
better here and indeed should do so without these census data in OSM whatsoever.

So, except for in Alaska, census boundaries in OSM appear to have marginal or 
even no value to any present or future conceivable use case.  While deleting 
them (except in Alaska) or "converting them to place=* nodes" may be the 
eventually correct solution(s), no organized effort to do so, or examination of 
the history or use-case-based arguments to keep them has emerged or presently 
exists.  (We do document the situation in our wikis, footnoted below).  I would 
like to see either the deletion of boundary=census entities entirely (except in 
Alaska) after a more-complete discussion of why and how they are presently used 
(perhaps in geocoding algorithms) and how better tagging on "more real" and/or 
"more stable" objects can and should supersede them.  Virtually always (if not 
always), a node with tag place= with a consensus-sane value[2] completely 
suffices.  Such cleanup (garbage-y, rapidly obsoleted polygons become a node) 
is very much in OSM's interest.

Complicating this is the major issue of Indian Reservation boundaries.  What 
has emerged as a stopgap[3] is to tag these with either 
boundary=aboriginal_lands or boundary=protected_area + protect_class=24, 
omitting the admin_level=* tag in either case.  Please read our wiki as 
footnoted here, as this may suffice to persuade you to remove the Satus census 
object, replacing it with a node tagged place=* with little or no affront to 
your sense of correctness within OSM.

These issues may seem complicated, though I posit that it is their history 
clouded by misunderstanding and poor introduction of US Census Bureau data into 
OSM that are to blame.  This makes the bottom line straightforward:  US Census 
Bureau census boundary data as polygons do not belong in OSM (except in Alaska, 
where they remain distinctly useful), since a node with a place=* tag delivers 
OSM's proper mapping of these semantics.

SteveA
California
Contributor to our https://wiki.osm.org/wiki/United_States_admin_level and 
https://wiki.osm.org/wiki/WikiProject_United_States/Boundaries wikis
OSM Volunteer since 2009, frequently in listening mode even as I offer what is 
hopefully august opinion

[1] 

Re: [Talk-us] Rural US: Correcting Original TIGER Imported Ways (Ben Miller)

[OSM Volunteer stevea]

Chiming in my +1 that county-at-at-time is a good, workable approach for TIGER 
cleanup.  I review the Ito! map's red highways/freeways first, then red major 
roads, then get to orange.  Joe Larson in San Luis Obispo (part of the 
firefighters there) spent a couple of years coordinating this effort there and 
now that county is "all blue."  (I believe he had some official state/county 
data to use, but still it was good, though tedious multi-year-long work).  My 
county (a few to the north) is maybe 75% done.  I've said it here before, 
elephants are best eaten one bite at a time and TIGER review is no exception.

OSM-US still doesn't have a hard consensus about what to do with many/most of 
the "other" TIGER tags (I would like to see this discussion progress), but 
after a good review, please DO delete the tiger_reviewed=no tag.  Delete it, 
don't change its value to yes.  BTW, I agree with the consensus that sometimes 
an actual human on-the-ground survey is the only way to do this sufficient to 
delete the tiger_reviewed=no tag, as Bing or other imagery is most certainly 
not always sufficient.

SteveA
California
___
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

[OSM Volunteer stevea]

On Feb 12, 2018, at 1:07 PM, Tod Fitch  wrote:
> Thank you Steve for that ITO link. I was unaware of that and it really is a 
> nice tool to see the overall status of the TIGER fixup in an area.

You are welcome, Tod; I'm happy to share what I know.

> I used to simply delete the the tiger:reviewed tag. But, based on things I’ve 
> read either in the mail lists or elsewhere, more recently I’ve been deleting 
> all the TIGER tags when I’ve surveyed the road and fixed any alignment, etc. 
> issues. I see on the ITO map that changes the color to black whilst simply 
> removing the reviewed tag turns it blue. . .

Yes, and this makes for an interesting view that Ito map provides, as areas 
which had roads non-TIGER added (manually or from another dataset/import) do 
show up as black.  For example, some Native American reservations display as 
all-black in this map, as many areas received no ways with TIGER tagging.

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

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

[OSM Volunteer stevea]

Clifford Snow  wrote
> How many of the TIGER imported streets are still untouched?

Thanks for rallying us with this great thrust forward, Clifford, with excellent 
Challenges, resources and direction.  I'd like to add one more tool I use for 
TIGER cleanup, the Ito! map at:  
http://product.itoworld.com/map/162?lon=-122=47=9=true

This can be slow to load, and subsequent changes you make take several days to 
a couple of weeks to re-render, but over a longer-term (months to years) I have 
found it to be a valuable tool.  When a "divide and conquer" strategy is 
applied (for example, a county or sub-area of a county), progress becomes 
visually rewarding.  Seattle, largely dark blue (great!) or light blue (OK for 
now) looks better-than-average, as you note and as would be expected.  However, 
as soon as you drop out of the urban megalopolis, things get orange (fix me) 
and red (fix me FIRST!) rather quickly.  This helps prioritize what TIGER data 
need attention sooner, like right now!

Remember, after you review tags and alignment of TIGER data, REMOVE the 
tiger:reviewed=no tag, don't change its value to yes.

I don't want to pick a year as to when the US will "finish fixing TIGER," it 
might be decades.  But that's OK, it will be worth it, as our map gets better 
every day.

Happy mapping,
SteveA
California
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] tiger name issue in New York

[OSM Volunteer stevea]

I encourage you to edit wiki, Max, it is an important part of OSM-ing, if you 
are one who does, fantastic.  Honest updates or better data, it's easy to write 
and comes naturally to many.  Please, go for It!

Steve

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

[Talk-us] [Imports-us] New to lists and would like to suggest some imports

[OSM Volunteer stevea]

I would add that the guidance of an OSM volunteer with some experience with 
importing can be quite helpful.

It is easy to be eager to complete an import.  It can be challenging, 
especially for novice mappers or those unexperienced with "medium-sized" 
projects like this to do one for the first time and get it completely right, 
very especially to "go it alone."  In the ham radio world, we would sometimes 
call such a person an "Elmer."  Often an older, calm, cool, collected, 
been-around-the-block sort of person who knows a couple of things about a 
couple of things and likes to help others solve problems that might crop up.

Seek some greater community and ask around of those who answer, listening to 
their experience with Mapping Parties or other imports.  Doing this simply 
strengthens our community.  Take your time, there is never any rush to import.  
Quality above quantity or speed.

SteveA
California
___
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

[OSM Volunteer stevea]

What most of us largely "know" (in this context, as we, myself included, posit 
both opinion and potential solutions) comes from a web-based news article.  It 
isn't clear to me that a local ordinance has already passed specifying 
"something."  Same with signs on-the-ground, speaking personally, I don't know.

We are a know-it, see-it, tag-it project.  Local knowledge is helpful and often 
preferred.  Please let those guide us here.

SteveA
California
___
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

[OSM Volunteer stevea]

First, as they are public (not private) streets, anybody has the right to 
traverse them.  Yes, a local ordinance might (in the near future) prohibit 
access for "cut-through," it is the right of the municipality to pass such an 
ordinance and for local police to enforce it.  "We don't want the mappers to 
put these data into their maps and navigation apps" simply isn't going to 
happen, as we (mappers) are not going to be "muzzled:"  these are real data in 
the real world.  Censorship is not the answer, rather it is proper tagging 
which feeds routing algorithms.

I might suggest a solution OSM might consider can be to tag access=destination 
and/or residential=living_street.  There might also be a note tag briefly 
explaining the local ordinance which gives rise to such a local preponderance 
of access tags.  But the streets should not "be deleted" as the mayor and 
residents wish.  With the right tags, the apps' routing algorithms won't 
include these streets, and the problem (as it is perceived as coming from 
"navigation apps") is effectively solved.

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

Re: [Talk-us] Parks, again

[OSM Volunteer stevea]

There is a lot to unpack in this discussion.

First, OSM has the strong tenet that we should not code (data tag) for the 
renderer.  That is sound advice and largely serves us well, but it fails to 
directly address that there is no point to being an OSM volunteer unless there 
ARE renderers which display the results of our mapping (tagging).  Well, if you 
spend time in the more "coding" aspects of our project, you can glean the 
largely opaque (to most OSMers) processes and personalities of renderers and 
rendering, and maybe that is appropriate:  after all, they are the "back end."  
Yes, this is where important decisions are made about what data in our map 
either are or are not shown.  (I'm talking about Carto, what might be called 
OSM's "front door" or "pretty face.")  Carto is, for better or worse (and it 
has gotten much better) what most mappers (and other OSM consumers, though not 
all) "see as OSM."  I know that's not strictly true, but let's say for purposes 
of this discussion about parks that it is.

Especially since having discovered OSM in 2009, I love cartography and mapping. 
 I also love parks, hiking, biking, nature and enjoying our public lands which 
are protected (at certain "levels") from further human development.  So, even 
as I got started mapping in OSM back then, accurately mapping parks (indeed, 
even positing ideas at how we might potentially improve how OSM maps parks, 
something I continue nine years later) became an important goal of mine in this 
project, reflected in my user page, mapping practices and passionate talk-us 
discussions.  I have followed many twists along the way, such as when 
leisure=nature_reserve is more correct than leisure=park, a lengthy debate 
(here) about landuse=forest (which I eventually cried "uncle" about, seeing 
that we were badly smearing the semantics of well-established wiki definitions, 
although they were and are ambiguous), striving to "do the right thing" with 
National Forests, National Parks, State Parks et al, important distinctions 
between landuse and landcover (still badly under-addressed in our project, as 
rendering distinctions between them remains muddy and has not fully emerged), 
the development of the protected_area (a good thing, but sorely lacking in 
helpfulness when it comes to being rendered — a difficult task, I realize) and 
other related topics.  It is quite complex, it is difficult to communicate 
about all the moving parts, let alone reach solid consensus, let alone render 
perfectly what we mean.

Tagging accurately, with well-designed and well-documented (in our wiki) schema 
are absolutely essential.  Rendering, at least at "some" level (a single 
renderer suffices, one, like Carto, which is also well-designed to carefully 
"map what is important and not map what is not important") isn't QUITE AS 
essential, but let's use the word "vital" or say "very important."  The full 
path from "volunteer entering data" to "seeing it blossom upon the map" is 
largely what drives the passion of OSM volunteers doing our good work.  So the 
choice of what to render (in Carto) is vital.  As we diligently enter map data, 
we are pulled forward by the sometimes-seemingly-contradictory desires of 
wanting to see beautiful renderings of our work as well as to rather precisely 
enter data, and not code for the renderer.  Threading that needle is not alway 
successful, and it is often thwarted, as I believe it is in this case (parks 
and related entities, what we might agree are "protected areas") by the 
distinct lack of these entities rendering well.  It is also complicated by the 
legacy of older/preceding tagging conventions.

We've done good work with developing the protected_area schema in our tagging 
syntax.  We haven't done good work rendering the full spectrum of what we mean 
by those.  Again, this is difficult.  Colors, confusion with landuse/landcover, 
ideas about dashing (whether jurisdiction, landcover, "use," or other — I'm 
open to all ideas) are valid topics to discuss.  Let's understand that there 
has been a medium-long arc of history (over a decade) in our project which must 
accommodate the way things were done two, five, ten years ago, as well as that 
we wish to move forward with more robust tagging schema AND better renderings 
of those schema.  In short, and it is widely known:  legacies can be 
challenging to grow beyond.

These are complex issues, we have been evolving them over years on top of doing 
things with more simplistic (legacy) methods, and so many issues must be 
accommodated in a "smart growth" (towards excellent tagging being supported by 
excellent rendering) methodology.  This forum may not be the best way to do 
that, as I feel I have typed too much for one missive already.  Please, let 
good discussion continue.  We are many people, with many good ideas, who wish 
to see the "right" and "best" things happen as our project grows and improves.  
Once again, I believe us to be more in 

Re: [Talk-us] Parks, again

[OSM Volunteer stevea]

On January 4, 2018 at 6:21:03 PM PST, Bradley White  
wrote:
>> I don't think the title
>> given to a piece of land should necessarily have bearing on the data
>> representation, in the same way "Hampstead Heath" doesn't get
>> "natural=heath" just because it's in the name.

I forgot to make this point in my previous post.  The British English 
convention of calling a (sometimes municipal) park-like area "Hampstead Heath" 
being explicitly stated as a different semantic than what OSM tags 
"natural=heath" is an important distinction to make, and I'm glad our wiki does 
so.

However, by way of contrast, something called "Park" generally IS a park:  I 
seldom, if ever, find an exception to this.  As long as that is true (and 
contrasts sharply with "heath" as you and our wiki remind us), I'll continue to 
tag something named "Park" with leisure=park.  Yes, sometimes I'll use 
leisure=nature_reserve, but guess what?  That's because it's name contains 
"Nature Reserve" or "Open Space Reserve" or some other set of English words 
that map directly onto the tag "leisure=nature_reserve."

So, while it doesn't NECESSARILY have bearing, I am an intelligent enough user 
of language (and its derived semantics) to "properly" map these semantics to 
specific syntax tags in OSM.  All OSM volunteers must do at least a little bit 
of this, and we can even talk about the more subtle aspects of doing so in a 
forum like talk-us.

Our tag of park, I continue to assert most assiduously, is vast and elastic.  
We might improve it with a rich schema, but until then, it is correct to tag 
park entries with this tag.

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