Re: [Talk-us] Parks in the USA, leisure=park, park:type
(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
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
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
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
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
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
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
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
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
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
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
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
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
> 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
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
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
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
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
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
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-ca] Open Data for Airdrie AB
John, that was an outstanding overview of and answer to today's quite workable process. I can only dream that this be written up in whatever now guides this effort in OSM (BC2020 wiki, whatever). Congratulations on developing what looks like it now does allow and will eventually better allow nationwide building data to properly and further enter OSM. Good luck with your efforts, I genuinely mean that.Best regards,SteveA ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Building Import
Ah, good dialog ensues. Municipality by municipality, in conjunction with BOTH the StatsCan and Bing data, the right things are getting noticed, the right things are getting human-realized at what the next steps are to do. It gets better. Yay. Stitch it together. One municipality at a time. One province at a time. Pretty soon, after a few revisions of data and back-and-forths between municipalities and province-wide data checking, you've got something. There, you go. SteveA > On Mar 27, 2019, at 8:23 PM, keith hartley wrote: > > The patchwork of municipalities is at least useful, before we didn't have a > framework for adding this data, but at least we do now thanks to the umbrella > license @ Stats Canada. We're a big country with very few, but very skilled > OSM mappers (IE gecho111 mapped all of regina's building footprints! ). > > I like the concept of the Bing data, but they may have to do another few > tries, or maybe retain their Neural network. - Is there anywhere where the > Bing data looks nice? I found burbs in Winnipeg not bad, but there's some > really weird elements when the source data is too simple (buildings in the > middle of fields) or too complex (urban cores) > > On Wed, Mar 27, 2019 at 6:29 AM John Whelan wrote: > The Stats Canada data comes from the municipalities. Unfortunately there are > over 3,000 in Canada so yes ideally each would be treated separately in > reality each municipality doesn't have a group of skilled OSM mappers who are > capable of setting up an import plan and doing the work although there is > nothing to stop them doing so. > > Cheerio John ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-us] Is there any value at all in tiger:MTFCC and tiger:FUNCSTAT tags? (Kevin Kenny)
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
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
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
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
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-ca] Microsoft has released its building outlines for Canada
On Sat, Mar 2, 2019, 7:45 PM Tim Elrick, wrote: > Just my two cents here. There are plenty of others doing so, too (me included, though I'll happily deduct a cent for being non-Canadian, so before you know it, you've got a whole dollar. "Many hands make light work," though I agree that achieving consensus on a nationwide import can be (and often is) quite difficult. I'm not trolling here, I wish to be encouraging and have decided to go crawl back under my rock for awhile to pursue other OSM endeavors (south of our border). Cheers, SteveA ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Microsoft has released its building outlines for Canada
John, these aren't my fish to fry; this endeavor belongs primarily to Canadian OSM volunteers with optimistic attitudes who have the courage to envision a finish line of mighty and pride-inspiring results into existence. Being encouraging, my feeling is it IS possible to reach consensus across Canada. It might be rough going at first, it might seem like the iterative process is taxing or even exhausting at times (especially early on in the project, as it is now), yet patience, the realization that when you bite off a nationwide data importation you'll have to chew (and chew and chew and chew...) before you can swallow a bit and recognize some important milestone of progress, but I am 100% certain Canada can and will get there. It is already in the process of doing so, and while "sausage making can be a mess!" I'm sure there are many who look forward to delicious results. Be heartened and courageous, be optimistic and visionary. If or as you don't, others will (and already have). Keep up the good work, everybody! SteveA (who usually doesn't like to be simply a cheerleader, though sometimes it helps) > On Mar 2, 2019, at 4:33 PM, John Whelan wrote: > > >More discussion often yields consensus. > > Feel free to lead the discussion and gain consensus. > > My feeling is it will not be possible to reach one across Canada. > > Good Luck > > Cheerio John ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Microsoft has released its building outlines for Canada
On Mar 2, 2019, at 3:47 PM, John Whelan wrote: > Two years ago a group of Toronto mappers submitted the City of Toronto Open > Data license to the LWG to see if it was acceptable. I assume they meant to > import things such as building outlines. I also assumed as I think others > did that this meant Toronto mappers were happy to import the City of > Toronto's data especially as it was discussed on talk-ca first. Historical info is appreciated for context, however, the LWG found Canada-wide city-by-city submissions for ODbL-compliance burdensome, given LWG's limited bandwidth. Assuming about events in the past is unhelpful, first because it is assuming (seldom helpful) and second, these events are in the past. How Toronto imported (building) data can't really help us first understand and second improve from what we learn until we know what we learned. That isn't presented here, but it could be. > More recently Nate who currently lives in Toronto feels that this should be > discussed once more in Toronto to work out what is desired etc. I agree with Nate. Perhaps first in Toronto, perhaps wider in talk-ca. "Once more" seems limiting, though it's possible it could suffice. > Tim I think is organising Montreal open data import. Please consider adding this (and links to user: wiki or Talk pages) to the active Import wiki. Generate communication using our media! > I note that Nate and Tim have different ideas about what should be imported. > One is happy with bay windows and I think the other feels they should be > removed. More discussion often yields consensus, especially as it "goes wide" (or as wide as is practical). > We also have Pierre who is unhappy because the imported building outlines > available have too many corners that are not right angles. More discussion often yields consensus. > The local Ottawa mappers are content with their Open Data import and find the > data quality acceptable even though Pierre has expressed reservations about > it. More discussion often yields consensus. Wide area (large cities, province-wide, nationwide) imports are not easy to achieve consensus but can often reach something approaching one as data are entered, not liked, improved, liked better, et cetera. These are often an interactive, iterative process. > Someone in Manitoba? mentioned there were no building outlines released for > Manitoba? I apologise if I have the province name wrong. It is spelled correctly. I am not Canadian and I know that; it isn't hard to spell-check Manitoba. > So we have a mixture of expectations which is only to be expected in a large > group. More discussion often yields consensus. It might be part "mixture of expectations" but I'm sure that everyone will agree that "high quality data entering OSM" is expected. What can be difficult is "what do we mean by high quality?" (in addition to establishing and communicating clear goals for the importation of the data). > Microsoft's Open Data provides another source of Open Data which might meet > Pierre's data quality expectations. They may meet Nate's. All provinces and > Territories now have Open Data building outlines available. OK, thanks for the clarification that a "union" of these datasets (Stats Canada-produced building data + Microsoft-produced building data) provide an "all provinces and Territories dataset." That truly is helpful as it makes it clear that "if Set A doesn't have your province's or Territory's building data, Set B will." > Northwest Territories, Nunavut, and Yukon have populations of around 35,000 > people. Realistically I don't think they have a group of local OSM mappers. Please don't "write them off" so easily. Not only does it seem "not nice," it may not be true. A better approach may be to actively develop community there, difficult as that might seem. I believe there is usually Internet available there in the villages (sometimes via clever and state-of-the-art methodologies) and it may be as simple as "shaking the trees" of the right people, then "they'll take it from there." > Essentially the problem now we no longer have a Canada wide consensus on what > is acceptable More discussion often yields consensus. > ...appears to be how do you identify local mappers across Canada and how far > away can a "local" mapper be to be considered local since it is the local > mappers who make the decision about what is acceptable and I think it is they > who have to drive the import process. There are no such "hard and fast" rules as this. I think you're on the right track that "hinterland" (I do not mean that disparagingly, rather more like "far away from others") OSM volunteers "drive the import process," so I again encourage you and others to "better develop" this community and let them, teach them, encourage them to "do what they will." > I'm sure if a local group would like to contact me we can find resources to > assist them
Re: [Talk-ca] Microsoft has released its building outlines for Canada
No, I am not planning to import these. However, your notification that the data are available seems to be encouraging the data to BE imported into OSM. Of course, there is a "more correct" way to do that. Perhaps I might encourage you to sharpen up your intention for notifying talk-ca of the availability of the data. Are they an additional source to ENTER into OSM? (Thus importing them). Or, perhaps you mean them to be a set of "comparison data" which might be used to verify or compare against the "other" data. Although, then, should there be a discrepancy, the question becomes "which are (more) correct?" I didn't see any of these issues addressed by your notification, which feel likes it begs these questions. Thank you in advance for any follow-up that better clarifies. Late notice just before I clicked Send: thanks to James for letting us know here that the data are ODbL and therefore OSM-compatible. (One down, perhaps a bit more to go). SteveA > On Mar 2, 2019, at 2:40 PM, john whelan wrote: > > Why are you planning to import it? > > Cheerio John > > On Sat, Mar 2, 2019, 5:26 PM OSM Volunteer stevea, > wrote: > A responsible complement to this would be a link to license information, a > wiki page about these data, and perhaps an Import Plan should those data > actually be asserted to be worthy of being responsibly imported into OSM. > > SteveA > California > > > On Mar 2, 2019, at 2:17 PM, john whelan wrote: > > > > https://github.com/Microsoft/CanadianBuildingFootprints > > > > So now there are two Open Data sources for building outlines in Canada. > > > > Cheerio John > > ___ > > Talk-ca mailing list > > Talk-ca@openstreetmap.org > > https://lists.openstreetmap.org/listinfo/talk-ca > ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Microsoft has released its building outlines for Canada
A responsible complement to this would be a link to license information, a wiki page about these data, and perhaps an Import Plan should those data actually be asserted to be worthy of being responsibly imported into OSM. SteveA California > On Mar 2, 2019, at 2:17 PM, john whelan wrote: > > https://github.com/Microsoft/CanadianBuildingFootprints > > So now there are two Open Data sources for building outlines in Canada. > > Cheerio John > ___ > Talk-ca mailing list > Talk-ca@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-ca ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-us] Proposed mechanical edit - elimination of old-style Wikipedia links in USA
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-ca] Some feedback on import quality in Toronto
It is an honor to participate in this good growth. May good (province-at-a-time building) data enter OSM at the hands of skilled OSM editors who have good instructions on "how" (the Import Plan can go that distance, please finish it) as their skills of good editing OSM data push the import ahead. Speaking for myself, I like what I see here: a community speaking amongst itself/ourselves. Should "tall enough to ride the ride" volunteers "step right up" I think the current red flags can go to yellow, then green. Nate, Yaro, Pierre, Blake, Nate, John, Danny, so many others here unnamed have shown leadership. Many Canadians seem on the road to "how" and "talk amongst yourselves." Good is not the enemy. Good are good enough as they are included with "how." Thumbs up from here ahead. I keep trying to be outta here. Et, voilá. SteveA > ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Building Import update
I dislike sounding simply "like a cheerleader," here however, I am deeply encouraged by what I see as substantial progress. This sort of discussion bodes very well for the future of the import. Keep up the good work! SteveA On Feb 3, 2019, at 3:26 PM, john whelan wrote: > I'm hearing we keep the single import project as such. ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Building Import update
Pierre writes that he is "waiting for John's demonstration that the import data for Ottawa represents the outline of the buildings and is quality data." In reality, anybody (not necessarily John) can offer this sort of characterization. En réalité, n'importe qui (pas nécessairement John) peut offrir ce type de caractérisation. SteveA On Feb 3, 2019, at 11:42 AM, Pierre Béland via Talk-ca wrote: > De tes exemples sortis du chapeau ne font pas avancer la discussion. > > J'attends la démonstration de John que les données d'import pour Ottawa > représentent bien le contour des bâtiments et sont des données de qualité. > > Pierre ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Some feedback on import quality in Toronto
Mmm, careful with your language, John. The data "have a license which is compatible with OSM's ODbL" (is an accurate way to say it). I believe that took about eight years and was a difficult slog, a lot of hard work by many, lessons learned from Ottawa, a determination by OSM's LWG, but it is done. (I am grateful for that, it is an important milestone). A different issue is whether the data and their concomitant quality "are acceptable" to the OSM community. The license being ODbL compatible is not that; these are different issues. We now discuss data quality (and what to do to improve them, if anything) here in talk-ca and in the mildly-being-updated Import Plan, with experiences of what Yaro, Danny and Nate have done in Toronto. It is not the case, as John says, that "the data (are) licensed to be acceptable to (OSM)." The concept of "acceptability" is not related to the data being licensed compatible with ODbL. What often/usually happens is an Import Plan gets wide vetting and acceptance by the OSM community before data become imported, including suitability/acceptability of the quality of the data. What happened here is the Import Plan was attempted to be widely vetted, but this seems to have been largely ignored or little-paid-attention-to. While the Plan's initial shortcomings were pointed out, yet not remedied, the Import began, then the community began to react (with some complaint and some "what Yaro does seems OK"). Yaro (and Nate, I believe) then updated the Import Plan with Yaro's specific technical steps. Still, complaints and/or disagreements about simplification, squaring and potentially other issues continue. (As two asides, I'll say that MANY buildings are not necessarily "square" — like buildings with bay windows — and that truly square/rectangular buildings should express this with a tagged way/closed polygon made up of exactly four nodes). As these discussions continue, eventually what will emerge is "how do we (algorithmically, manually...) change the data, whether pre-import or during-import, so that they achieve wide acceptance as to their quality by the community." We're getting closer, it seems to me, but I don't think we're there yet. Nobody seems to be arguing there is or isn't a "desire to bring in the buildings by many" or to "use them for many purposes." That point seems "decided." The questions remain: "how, with the existing data?" Once those are determined (and documented in the Import Plan), over time, the data will (or will not) be imported. I wish to offer encouragement to this process, it does appear to continue here and can likely bear fruit in the near future. Keep going! Consensus is ahead! SteveA On Feb 3, 2019, at 10:55 AM, john whelan wrote: > So I suggest that you name yourself as the coordinator on the wiki page for > Toronto that allows the local mappers in Toronto to import at the rate and to > the standard you suggest. > > For the rest of the country the data is licensed to be acceptable to > OpenStreetMap thus anyone can set up their own import plan and import it even > if this import is abandoned. I'd like to see this voiced as the general > desire though on talk-ca before it happens as it was a talk-ca decision to > proceed. > > My reading of the posts on talk-ca is that there is a desire to bring in the > buildings by many. There is also a desire by many to use them for many > purposes. > > Cheerio John > > On Sun, Feb 3, 2019, 1:42 PM Nate Wessel John, > You seem to be mostly addressing topics which have been brought up elsewhere. > My email was meant to address specific data quality issues in Toronto, so I'm > not sure how to respond to all of this. > To your broader question though, my position is that we *do* have the > volunteers and skills necessary to make this a good import. Supposing that we > didn't though, then I would have to say that the import should wait until we > have the right people working on it. A bad import is worse than no import. > > Cheers, > Nate Wessel > Jack of all trades, Master of Geography, PhD candidate in Urban Planning > NateWessel.com ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Building Import update
On Feb 1, 2019, at 1:13 PM, john whelan wrote:
> So how would you tackle it?
>
> Adding buildings with JOSM and the buildings_tool is possible, I think Julia
> tried to whip up some interest with the 2020 project. Unfortunately
> mapathons using iD and new mappers for some reason don't work too well for
> buildings. They do work fine for adding tags though.
>
> I seem to recall March 2nd is some sort of student GIS day and we can expect
> something to happen in GEO/GIS week whenever it is. I'd prefer adding tags
> to existing outlines rather than having to clean up buildings added with iD.
Adding tags to buildings by students at a "student GIS day" (whether with iD or
not) is "one thing," and honestly shouldn't even be in this same thread
("Building Import update." ) Conflating the two is either mistaken,
disingenuous or both.
> If we go back in time to the Ottawa import and the licensing issues I seem to
> recall a Toronto mapper submitting the Toronto Open Data License to the legal
> working group which implies at least one Toronto OSM mapper was after the
> Toronto Open Data.
While it can be valuable to "look in the rear view mirror" (to learn from past
mistakes), I fail to see how this comment matters. Doing my best to stay on
point, my educated guess is there are MANY users who want to see "the five
provincial building datasets" (what we TRULY attempt to discuss here) enter
OSM. However, there appear to be questions about the data quality, with some
saying "skilled editors are able to do a decent job with these data, but not
without substantial post-data publication (now) improvements before the data
are uploaded." (This would be downloading a "square" on the Task Manager and
rather heavily improving the data, building by building. Yaro and Danny,
please chime in and agree or disagree. Should that be true, only
intermediate-to-advanced — i.e. rather skilled OSM editors with practice and
experience should "do" the importation of these data). Others say "these data
need wholesale algorithmic changes before they are good enough to be uploaded."
(As I've said, maybe "squaring" or "simplification," yet I and this mail-list
still do not know exactly where consensus lies there). There are likely other
opinions along and even outside of that spectrum, I simply do not know that.
But GETTING to know the answers to those questions really must be "next." We
appear to be hashing that out here and now. Much else (all else?) is, largely
speaking, noise, distraction and what Nate said, "red herring."
> My feeling at the moment is there is a suggestion that "cleaning" the data up
> then some sort of team approach in a particular area would be acceptable but
> how you put it together I'm not sure.
No, you do not appear to be sure, John. Yet, somehow, Canada will get there.
Either in talk-ca, the Import wiki, the wiki's Discussion tab ("Talk page") the
consensus of what to do with the data will EVENTUALLY emerge (fix 'em, scrap
'em, leave 'em alone and import 'em with great care...), then they will
(slowly, there are a LOT!) begin to be imported into OSM. Or not.
It is a maxim of good project management which is often unstated, yet now is
the time to say it: "Lead, follow or get out of the way."
SteveA
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Building Import update
On Jan 31, 2019, at 5:47 PM, john whelan wrote: > > I note that both Google and Bing have most buildings these days That's a strong assertion, any cite you might make? Or are you simply guessing? Also, so what? And, "most?" > and it has almost become a map user expectation. Do you have any sources to cite for this? Bing users? Google Maps users? OSM users? Who, exactly is "expecting" this and how do you know this? What matters here and now is the OSM community's acceptance of the quality of these data. Is Canada able to MAKE such a determination? I think so. > There is a case that says to keep up with the competitors we really ought to > have buildings. John, I believe you are the first to ever assert "we ought to have buildings" I've ever seen in OSM. What "case" are you talking about? > I think someone else has commented that parts of the Microsoft building > outline from scanned images in the US is problematic. Well, then say so. Say who. Say when. Say where. Say what you mean by "problematic." Let us (the OSM community) reflect on these comments. Let us (the OSM community) make our own determinations whether this is or isn't "problematic." Those issues are a completely separate issue from OSM, although there might be overlap, I simply don't know, as you haven't given us any data, simply your opinion. I'd like to know, but I can't, given what you have offered. > So given the results in Ottawa are comparable to Ontario and in my opinion > Ottawa is acceptable then I think the rest is also acceptable. OK: one vote in the fog of consensus. I have very little data to go on, and I'm not completely certain why, but it is an assertion of an OSM volunteer saying "then I think..." something. > Certainly Kingston where not all building angles were right angles weren't > noticeable to me by eye or perhaps my eyesight is just getting worse with age. Canada (and OSM) either agrees its building data for the five provincial datasets are OK, or Canada (and OSM) don't. As I've heard many here (I don't need to cite them, these cite themselves) say "I don't" or "we don't" (think the datasets are OK), the next things to say are "Well, they seem fixable with some algorithmic/programatic massaging, so, how do we fix them?" Or, "OK, here's how we're going to fix them." (Simplify the nodes, make them have 90º angles, whatever). This doesn't seem like it's an impossible finish line to cross, though I do see at least one person running in detours going nowhere. In short: "what's wrong with these data, how might they get fixed?" (Then they might get imported). It doesn't seem to me to be a whole lot more complicated a discussion than that. SteveA ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-us] The San Jose / Santa Clara border
(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
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-ca] OSM Canada building import
On Jan 26, 2019, at 12:37 PM, john whelan wrote:
A history of building data released by Stats Can and how these were entered
into OSM via an Ottawa pilot project, with some success and some lessons
learned. Good for OSM!
> The other complicating factor here is a lot of people are very interested in
> using the data one way or another.
No doubt it's a factor, though I fail to see how it complicates — unless there
is a rush to enter the data before they are fully vetted. (That won't work).
Should the data be used "from OSM," they must enter OSM with our community
consensus, standards and practices. That is beginning to be achieved:
https://wiki.osm.org/wiki/Canada_Building_Import improves, related Task Manager
tasks appear to get closer to being "opened again" as Nate's four steps of what
might be accomplished reach wider consensus and are implemented (or not, or
something else happens...) and discussion continues right here on talk-ca.
Yes, "broad philosophical discussions" are included: they are helpful, likely
to some more than others.
> The take away, have fun if you can.
"Have fun" is "OSM tenet #2" (#1 is "Don't copy from other maps.") As we're
not violating #1 here, I enthusiastically agree with John's "take away:"
please do have fun (yes, you can, yes, many do). Yet, as we are a data
project, we must also be a community who cares deeply about data quality, that
our data "pass muster" as they enter (especially when via a nationwide Import).
I speak for myself only, but others in this project concur. Canada gets
there, I'm delighted to see. Yes, it's taking a bit of thrashing to do so, but
that's all for the greater good, as the ends justify the (polite, patient,
correct) means by which we do. We're many steps into this 10,000-kilometer
journey, let's keep going, as the goal is worthy.
Now, who is rolling up their sleeves and addressing Nate's four steps? Those
discussions can take place here, though I think the Discussion tab ("Talk
page") of the link above seems more appropriate. (And, I'd prefer to "get out
of the way" here, if anybody were to go so far as to feel "get lost, already,
SteveA," I wouldn't be offended, though I remain watching this Import for that
greater good).
SteveA
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Building Import update
On Jan 26, 2019, at 8:42 AM, Nate Wessel wrote: Four absolutely OUTSTANDING aspects of this project which can (seemingly must) be addressed before the Task Manager releases these (or improved/simplified) data. A salute to you, Nate, for these thoughtful words and their potential to very positively drive forward this import. SteveA ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] OSM Canada building import
I'm changing the Subject to delete "Stats Can" as this is an import into OSM, not a Stats Can import. True, they published the data, so "thanks for the data," but Stats Can isn't a part of this conversation, they merely published the data. I say it like this to emphasize that OSM is quite aware of a good analogy: the US Census Bureau, who published the TIGER data which was imported massive road and rail data into the USA (roughly, many agree), had nothing to do with the import, nothing to say about it and don't to this day: they merely published the data into the public domain (as the federal US government do all their/our data, except when it is "classified") and OSM chose to import the data. OSM wishes in retrospect we had done a better job of it, as we improve it to this day (and will for years/decades, likely) and OSM has learned from this. Please, Canada, see this import as the opportunity it truly is: do NOT be in a rush to import lower-quality, not fully community-vetted data, or you will be quite sorry at the mess you'll have to clean up later. Doing that would be much more work than the dialog we are having now to prevent this. It is worth it to have these dialogs and achieve the consensus that the data are as we wish them to be. Are they yet? It sounds like they are not (Nate's four points). On Jan 26, 2019, at 7:49 AM, John Whelan wrote: > Currently we seem to be at the point where some on the mailing list feel > there wasn't enough discussion on talk-ca before the import. MANY agree there wasn't enough discussion. But that was before. Rather than looking back (though there is nothing wrong from learning from missteps), we are in a "now" where that is changing. So, we continue to discuss. That's fine. That's actually excellent. > Quebec I think we should put on one side until the Quebec mappers feel more > comfortable. OK, so we await Québécois suggestions / improvements to the process to their satisfaction, their input that they are (widely amongst themselves) with "comfortable to where it has finally evolved" (but I haven't heard that yet), or both. Usually in that order, but certainly not "well, enough time has elapsed, yet we haven't heard much, so let's proceed anyway." That doesn't work, that won't work. > Nate I feel has been involved in a smaller import before and in that case > there was benefit by simplifying the outlines. In this case verifying > nothing gets screwed up adds to the cost. Nate has done a lot of things in OSM, including a very positively-recognized (award-winning?) Ohio bicycle map that included very wide coordination with other OSM volunteers, the academic world and local community. (It is absolutely delicious; take a look at it). Another example of what a single person in OSM who reaches out to the community with a vision and a plan can achieve — given planning, the time it really takes and wide consensus. > Buildings not absolutely square, yes but different GIS systems use different > accuracy so if the incoming data has a few more decimal places then rounding > will occur which can lead to minor inaccuracies. I feel the simplest is just > to leave them. Others seem to feel that these inaccuracies are too rough (data quality too poor) to enter OSM. And "different GIS systems" only matter in a historical context (as in, for example "these data came from QGIS" or "these data were run through GDAL and turned into a shapefile" or many other workflows). The only "GIS system" that matters is OSM. Each individual contributor who enters data into OSM is responsible for entering high-quality data, or risks having those data redacted by the community (though that means the process was broken to begin with) — that's simply how OSM works. Again, this is an OSM project: a data import, which follows rules and community standards judging its quality as much as the individual entering the data itself. If the data should and can be improved before they enter (especially with a "data-wide" application of some algorithm), like "this squares buildings and we want to do this" or "this turns a true rectangle into four nodes instead of eleven and we should do this to reduce the amount of data and simplify future edits" then we should. This isn't being "anti-import." It IS about "data which ARE imported must be high-quality," so let's discuss what we mean by that in the case of these data. That's what we're doing now. > Selecting everything and squaring is really a mechanical edit and you can get > some odd results which again would need to be carefully compared and adds to > the workload. Sometimes "mechanical edits" are OK, sometimes they are not. It seems John is saying "these are not." Whether this adds to the workload or not is moot, the workload will be what it takes for high-quality data to enter, and "what that means" is achieved by the discussions we have had, have now and what
[Talk-ca] Building Import update
Thanks to some good old-fashioned OSM collaboration, both the https://wiki.osm.org/wiki/Canada_Building_Import and https://wiki.osm.org/wiki/WikiProject_Canada/Building_Canada_2020#NEWS.2C_January_2019 have been updated. (The latter points to the former). In short, it says there are now step-by-steps to begin an import for a particular province, and that as the steps get fine-tuned (they look good, but might get minor improvements), building a community of at least one or two mappers in each of the provinces with data available, the Tasking Manager can and will lift the "On Hold" or "Stopped" status. Nice going, Canada! See you later, SteveA California ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Place Tagging
On Jan 24, 2019, at 11:03 AM, Danny McDonald wrote: > A place does not need to incorporated to be a place=town, city, village. > That is not how it works anywhere in OSM - there are many unincorporated > places with these tags, worldwide. The tagging in Ottawa is a good guide, > with e.g. Richmond a village, but e.g. Centretown and Stittsville > place=suburbs, based on distinctness. I don't believe I said it did, I do believe I said that a city is always incorporated, a town or village, "maybe." And, as I also said, "local tagging as a consensus or guide" is something to consider. This isn't alway black-and-white, nor easy. As we "do our best," things eventually emerge as correct, though it usually takes some time and effort to get there. (Consensus does). SteveA ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Place Tagging
On Jan 24, 2019, at 7:50 AM, Danny McDonald wrote: > My understanding of place tagging is that place=city, place=town, and > place=village are for distinct urban settlements, whether or not they are > separate municipalities. Correct, in that these tags can be placed upon a node, way or relation (if a boundary relation, a node with role admin_centre is correct). Sometimes a way (often a closed polygon) is not precisely known, or is, but license restrictions prevent those data from entering OSM. In that case, a simple node tagged place=* with appropriate value is used, as documented at https://wiki.osm.org/wiki/Key:place . Though, be aware and careful regarding "incorporated" areas; see below. > Place=suburb is for large parts of urban settlements (such as North York in > Toronto, or Kanata in Ottawa). While I am not a political scientist, I did participate in the development of consensus in the United_States in https://wiki.osm.org/wiki/United_States_admin_level , a complex task indeed (and I'll say we only have it "largely correct," certainly not "exactly correct"). While Canada has similarities, it certainly is unique in admin_level, appropriately documented at https://wiki.osm.org/wiki/Canada_admin_level . Yet an important concept found in many countries, Canada included, is that of "incorporation" — whether an urban settlement is a "body corporate." Cities always are, suburbs and towns, depending on differing context for each of these, may or may not be. > Whether to classify a place as a place=city/town/village or place=suburb > depends on the facts on the ground (I.e. whether a place is part of a larger > urban settlement), and not primarily on municipal/administrative boundaries. I can't speak for all of Canada, but I can speak to what OSM documents in our place=* wiki: that urban and rural populated places are distinguished by two separate tables there, so it is useful to understand how OSM characterizes these as slightly different (with specific tags in each table). This is regardless of how any particular country might use the same names. For example, place=suburb has a very specific semantic as it is used in OSM, contrasted with how "real world" "suburb" might mean an incorporated (smaller) city near a (larger) city, OR it might mean a district/area/small region INSIDE of an incorporated city (how OSM means it). We must be careful to tag in OSM with how OSM means things, mapping our "real world" semantics onto OSM semantics. > Municipal boundaries might be somewhat relevant in determining if a place is > distinct (e.g. Vaughan is a city, not a suburb), but they are a relatively > minor factor. I don't know what this means exactly. Municipal boundaries ARE EXACTLY relevant in determining if a place is distinct: they literally distinguish it. In "real world speak" Vaughn might be called a suburb, but unless it meets OSM's place=suburb definition, it shouldn't be tagged that way in OSM. This isn't minor, it is "either correct or incorrect." > The main way that municipal names are mapped is through admin boundary > relations, not place nodes (although many municipalities have the same name > as their largest urban settlement, of course). Yes, this is true, although for many smaller human settlements (and some larger ones), place nodes simply "will have to" suffice. > The way to distinguish between a place=city, place=town, and place=village is > population size, with nearby places shading things a bit (so a smaller > population size qualifies for a place=town in Northern Ontario). Very > roughly, a city has population >50k, a town has population 5k-50k, and a > village is <5k. OSM's place wiki notes that a village is more like "200 to town size" so that 5k edge is fuzzy. The USA admin_level wiki documents some "rules of thumb" here, but, yes, these can be rough, and are sometimes "stretched" (or "shaded" as you say) a bit so that wide-zoom views of very rural areas (e.g. northern Ontario) show settlements a bit more clearly. > There seems to be a persistent mis-understanding of this scheme, where > various editors (mainly @OntarioEditor and various other accounts controlled > by them) believe that place=city/town/village are for municipalities, whether > or not the municipality has one major urban settlement with the same name as > the municipality or not. They are also tagging all unincorporated places in > a municipality as place=suburb, regardless of size or distinctness. Finally, > they are using the official title of the municipality to determine if it is a > city/town/village, whether than using population size. This can lead to very > misleading results, as Ontario municipalities called towns range in size from > 313 to 195k, and Ontario municipalities called cities range in size from 8k > to 2.7M. Quebec “ville”s (which means town or city) range in size from 5 to > 1.6M. > > To give an example,
Re: [Talk-ca] Canada Building imports wiki page
On Jan 24, 2019, at 9:29 AM, john whelan wrote: > You seem to have made rather large changes without consultation including > changing the title of the project. You have also added some value judgments. > A number of people were involved in the original and it might have been nice > to consult with them before making such drastic changes. The word consensus > springs to mind. > > I make no comment on whether the changes are good or bad merely extensive > without apparent consultation. John, much consensus is achieved in wiki Discussion(s), simply click the Discussion tab, https://wiki.osm.org/wiki/Talk:Canada_Building_Import and notice that there are four threads/sections under Discussion there already. If some "number of people" were involved in the original, they are perfectly welcome to join there. I'm not saying "don't do this in talk-ca" I am saying "there are often more-appropriate (vs. less-appropriate) places to have a discussion to achieve consensus." Sometimes, it makes sense to have an off-list email conversation in a one-on-one or one-on-many fashion. Thanks. SteveA California > On Jan 24, 2019, at 9:40 AM, OSM Volunteer stevea > wrote: > > On Jan 24, 2019, at 9:29 AM, john whelan wrote: >> You seem to have made rather large changes without consultation including >> changing the title of the project. You have also added some value >> judgments. A number of people were involved in the original and it might >> have been nice to consult with them before making such drastic changes. The >> word consensus springs to mind. >> >> I make no comment on whether the changes are good or bad merely extensive >> without apparent consultation. > > John, much consensus is achieved in wiki Discussion(s), simply click the > Discussion tab, https://wiki.osm.org/wiki/Talk:Canada_Building_Import and > notice that there are four threads/sections under Discussion there already. > > If some "number of people" were involved in the original, they are perfectly > welcome to join there. > > I'm not saying "don't do this in talk-ca" I am saying "there are often > more-appropriate (vs. less-appropriate) places to have a discussion to > achieve consensus." Sometimes, it makes sense to have an off-list email > conversation in a one-on-one or one-on-many fashion. Thanks. > > SteveA > California ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] 2020 building import wiki comment by Nate Wessel
Yeah, even going to 8 GB (-Xmx8192m on my java launch command line) I hang about halfway through opening "Loading json file." I'll try 16 GB (whew!) and QGIS next. Steve > On Jan 19, 2019, at 2:17 PM, James wrote: > > use qgis or launch josm with java in 64bit mode(d64) with memory options > (Xms, Xmx), or it will crap out at 3.5GB > > On Sat., Jan. 19, 2019, 5:13 p.m. OSM Volunteer stevea > On Jan 19, 2019, at 2:01 PM, James wrote: > > Is there no one that will analyse the data I've posted here? > > https://drive.google.com/file/d/1OK83yrPwMW4nefyu-6JsIInu0meK2rW6/view?usp=sharing > > or are we just email thread warriors? > > Well, slow down there, cowboy, it is gigabytes of data and I've been busy > replying to talk-ca, though my CPU is hot decompressing and opening your file > right now. Though even with JOSM getting assigned multiple gigabytes of heap > space (and I've got plenty dozens of GB of RAM), I'm still getting > out-of-memory errors on trying to bite-and-chew this monster. > > Maybe some of ARE email thread warriors, but I am not "just" an email thread > warrior. > > SteveA > California ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] 2020 building import wiki comment by Nate Wessel
On Jan 19, 2019, at 2:01 PM, James wrote: > Is there no one that will analyse the data I've posted here? > https://drive.google.com/file/d/1OK83yrPwMW4nefyu-6JsIInu0meK2rW6/view?usp=sharing > or are we just email thread warriors? Well, slow down there, cowboy, it is gigabytes of data and I've been busy replying to talk-ca, though my CPU is hot decompressing and opening your file right now. Though even with JOSM getting assigned multiple gigabytes of heap space (and I've got plenty dozens of GB of RAM), I'm still getting out-of-memory errors on trying to bite-and-chew this monster. Maybe some of ARE email thread warriors, but I am not "just" an email thread warrior. SteveA California ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] 2020 building import
On Jan 19, 2019, at 1:22 PM, john whelan wrote: > As a point of information the 2020 web page I think was started by Julia and > very heavily edited by Stevea. Sure I did, because it seriously lacked in the technical direction anybody would need to "map going forward" in the project/initiative as described. What tags, what tools, what's the finish line? It was hugely vague, essentially not a wiki that "nuts and bolts" OSM editors who wanted to make real contributions would be able to refer to and get concrete answers to their "how do I DO this?" questions. And that's what wikis normally do, not "catch imagination." > I think we are now agreed that the 2020 project with its idea of mapping > buildings in iD is not optimal. This distinction of "don't use iD, it sucks at allowing good building data to enter (except for tags, maybe)" is somewhat new to me. I don't doubt it happened, but it almost seems a "red herring distinction" (distraction?) at this point in time. And if "don't use a particular editor" is the bottom-line result from all the effort that came from writing that wiki, that's not a lot of bang for the buck. > However Julia's style did make its mark with many students and educators and > caught their imagination. Fine, glad to hear it. However, please don't pretend that wiki is the document that "roll up our sleeves" volunteers go-to to discover "HOW?" as the be-all and end-all of answers to our questions (most quite specific and somewhat technical, though truth be told, not truly difficult, simply trying to draw a line from "can't do it" to "ah, now I see how"). OSM volunteers need guidance and answers to their questions, especially in huge, nationwide endeavors. Plan! Answering "how do I do this in OSM" questions is what wikis in OSM are pretty good at doing, usually. While Julia's might have a style that appeals to students (and that's "not nothing") it was essentially "non wiki-like" in what wikis usually do. The remedy? Fix the existing wiki (that re-write, despite my best efforts, did not produce the desired results, or did so in odd and ineffective directions) OR write wholesale new wikis which DO get the job done. Largely, the Import Plan (the "current wiki" of this project) still doesn't fully do that (and an Import Plan is not a WikiProject), but "necessary steps to get the job done" are at least "out there somewhere," and hopefully will get better. (Look, Yaro "discovered" methods to move the ball forward, so it's possible). Anybody up for writing a real WikiProject for this endeavor? (Not me). The project really would benefit by this (and provincial-level wikis, too, imo) as well. We're in early days, let's see what unfolds. "The snowball is rolling downhill" and it's hard to predict what surprises OSM will reveal as things pick up mass and speed. > The import plan is not the 2020 web page, it is something different. The 2020 > web page has a pointer to it and it is the import plan or the import we are > talking about here. Starting with a fresh WikiProject (and even what it should be named are being thrown around, e.g. by Nate in the Talk tab) seems a fairly important direction to take. I've done this with WikiProject United States Bicycle Route System (fairly successfully) and WikiProject United States railways. The latter is a tough slog, starting from our 2007 TIGER data import of USA railways (many times more massive data than Canada's building import), though since I started to talk about this on talk-us in 2013-4, spoke about it at SOTM-US in Seattle in 2016 and at end of 2018, we now have almost half the US states (all Western states, some Eastern) with a wiki describing the state of their rail (both freight and passenger) and color-coded tables which describe how far along we are with TIGER Review. Replicate that, Canada, please, in your own way, at your own pace. Such massive, nationwide projects CAN be done, and while I'm not saying I did this single-handedly, I'm living proof that a dedicated leader can take it far, far forward. So, GO! You, I, many can bang out a decent (skeletal, at first, they always are) wiki in two hours to a weekend, so get busy. > The decision was taken by the small group who are putting this lot together, > to keep the 2020 as part of the name in order to link the two together. A > large part of the 2020 project was enriching the building outline data and > that I think was and still is important. Great. > What would be interesting is to hear from Canadian mappers what their current > thoughts are. The earlier talk-ca comments are still in talk-ca but remember > some time has passed since they were made. Certainly Nate for one was not > around in talk-ca when the matter was discussed. You asked for "Thoughts?" and you got mine. Yes, let's hear from Canadians, please. SteveA California P.S. Merci à Pierre pour son récent post de Toronto stats
Re: [Talk-ca] (no subject)
On Jan 19, 2019, at 10:48 AM, john whelan wrote: > There was an earlier discussion on talk-ca about how to handle this project. There were MANY. Speaking for myself only, I urged a very cautious, go-slow approach, to edit the data into "improvement / harmony-with-OSM" as much as possible BEFORE they upload to be imported, (or document in the wiki HOW this was to happen), to use talk-ca, Tasking Manager and especially to develop and use a freshly-rewritten (and undergoing continuous improvement) wiki (this part was a/the major failing, imo) to communicate. But that is looking in the rear-view mirror, and I don't like to hear "told you so," let alone say it. > It is similar to CANVEC in the original data sources are municipal data > CANVEC uses a few other sources as well and it is released under exactly the > same license but by a different federal government department. CANVEC data are roundly criticized. And it doesn't matter where those data came from (CANVEC), nor where the present data come from (Stats Canada). They are now "in the wild" and from an OSM perspective (what matters here and now), their source is essentially meaningless, except for historical context. > There are 3,700 municipalities in Canada. How do you deal with that? With good planning, using the tenets of OSM (e.g. the Import process, gaining consensus, good communication and appropriate tools like wiki, Tasking Manager and JOSM plug-ins where they make sense). You DON'T try to short-circuit that by wholesale re-writing a re-write of the seed project wiki (now well-vetted, as if it were it were, and I tried, would have widely been seen as lacking), posting notice on talk-ca and waiting two weeks independent of their being very little feedback on so gigantic a process (a massive red flag). In short, this was a huge "failure of consensus." Look at the posts now which say "I woke up to a mess." That simply shouldn't happen. > A suggestion was made on talk-ca we have one import plan that way it would at > least be consistent and that's what we did. This import plan, coming from the BC2020 wiki, which as written by Julia left a LOT to be desired as to technical specifics. I characterized this as "cheerleading and buzzword-compliant," sorry Julia, but it was and hence was ineffective as a wiki for its intended purposes, which is to answer questions of those who need technical guidance in an endeavor to have their "how?" questions appropriately answered. That's what wikis do, they are good at it, OSM expects this, so when a wiki fails to deliver, the project experiences failures. That absolutely should not surprise. > Mentally I'd split the project into getting an import plan that met all the > requirements and the actual importing. Um, yeah. > To me the importing would be done by local mappers or mappers with a local > connection after a local discussion which is what happened in Kingston. For > locations that did not have such mappers then over time they could be tackled > at a distance. One comment I recall was this was more of a marathon and to be > honest we expected it to take place over a fair length of time. A lot of > buildings have gone in much faster than I expected. So, plan for that. Manage that. If it isn't happening, make it happen with outreach and OSM's usual tactics of "developing community." OSM has been doing this for over 15 years (and gets better at it), but it isn't "a hope and a prayer," it is continual engagement, effort (technical and social) and mid-course correction when necessary, all while keeping a hawkish eye on the finish line. > For the pilot project with Ottawa the local Ottawa mappers were heavily > involved. We learnt a fair bit on the way and that's why we basically cloned > the Ottawa import plan. We noticed a lot of additional tags being added to > the building=yes and that to be was a good thing in that it drew more people > into OSM. I'm much more interested in those additional tags than anything > else. Crowdsourced projects often yield unexpected positive results. This is what our project means when we say our data get used "in creative, productive, or unexpected ways." It happens (a lot), this is one of the best things about OSM. > As far as I am aware there is no list of local OSM communities in Canada and > to be honest many mappers simply map and do not gather once a month at OSM > meetings. So? We don't need no stinkin' meetings, though all are welcome at meetings. > I don't think we do an import plan every time we bring something across from > CANVEC. Shame on whoever does this, it is wrong (from OSM's perspective, and this is OSM). > Unfortunately there really is a demand for this sort of information. The > initial 2020 meeting that took place at Stats Canada during the HOT summit in > Ottawa had many people from government departments who were very interested > in the data and especially what I call
Re: [Talk-ca] Ongoing Canadian building import needs to be stopped, possibly reverted
On Jan 17, 2019, at 6:27 PM, Jarek Piórkowski wrote:
> When no one is responding, sometimes it is because they are fine with
> the message as-is. I read it. I was fine with it. This isn't an
> Australian election.
I'm not sure about the allusion to Australian elections, so I'll let that pass
(over my head). I will self-admonish at not saying more in November at the
"reboot post," as while I felt then that these (BC2020) efforts would go awry
(again) this time (and here we are) I also felt like some (would, do) see me as
a loud-mouth with an unwelcome message. Despite my continuing desire to be
polite ("you catch more flies with honey than you do with vinegar"), no amount
of sugar-coating was going to sweeten a dearth of consensus and a
still-vinegar-sour early-draft wiki into the green flag of "let's proceed."
I tried to write as much as I thought helpful into that wiki, however, it never
became more sharply focused, which badly needed doing. Lesson learned (by me,
how about Canadian OSM volunteers?). Honestly, I am not looking to flog
anybody here, let's simply learn how to do this better. There are kernels of
success here that can be further developed, so, go do that. Figure out how,
first, then proceed. Most/all of the principal and important players talking
to each other while/as you do so seems like "first grade" to me and isn't
really so hard, it's more like effort that needs to be truly expended rather
than wished for instead. OSM isn't a crowdsourcing magic trick. Especially
with nationwide efforts, it's "one building (rail line, bike route, park
boundary...) at a time." Do that well (early) and scale that up (after).
> I must say I find the panic about imperfect building shapes is a bit
> amusing considering the very poorly manually-drawn sidewalks I've been
> seeing and having to fix in Toronto, or thousands of laneways having a
> descriptive "name" added by our corporate friends. Do we aim for
> perfect, or for good? Because if it's perfect, I see a _lot_ to be
> reverted or deleted.
Thanks, Jarek. Considering I am a proponent of "perfection must not be the
enemy of good" (regarding OSM data entry), I think data which are "darn good,
though not perfect" DO deserve to enter into OSM. Sometimes "darn good" might
be 85%, 95% "good," as then we'll get it to 99% and then 100% over time. But
if the focus on "how" isn't sharp enough to get it to 85% (or so) during
initial entry, go back and start over to get that number up. 85% sounds
arbitrary, I know, but think of it as "a solid B" which might be "passes the
class for now" without failing. And it's good we develop a "meanwhile
strategy" to take it to 99% and then 100% in the (near- or at most mid-term)
future. This isn't outrageously difficult, though it does take patience and
coordination. Open communication is a prerequisite.
SteveA
California
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Ongoing Canadian building import needs to be stopped, possibly reverted
The thread link is: https://lists.openstreetmap.org/pipermail/imports/2019-January/005878.html SteveA ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Ongoing Canadian building import needs to be stopped, possibly reverted
This is redirected (by request of its author) from a thread on the (talk-) imports mailing list at . On Jan 17, 2019, at 4:55 PM, John Whelan wrote: > The import was discussed on talk-ca and in my opinion there was a consensus > of opinion it should go ahead. The data comes from the municipalities of > which there are some 37,000 separate ones in Canada. The idea of a single > import plan was suggested on talk-ca by someone not involved rather than have > 37,000 different import plans. Many municipalities are very small. There was a serious dearth of reply, and nothing even approaching "consensus of opinion," indicating (to me and likely others) that a nationwide import did not have the wide, national consensus it must have to continue. John, we're simply going to disagree about that, it seems. Especially in light of the events in this desire/wiki/project going back to 2017, MUCH more consensus ought to have been built. I kept my mouth largely shut at the reboot two months ago, yet here we are. > If you look at Canada there are locations with poor imagery and lots of > buildings and my suspicion is some were being imported without the licenses > really meeting the OSM licensing requirements. Really? Then, fix this. That's a bit blunt of me, yes, yet, there it is. Stop. Fix this. You need coordination, via built-in tools like wiki, this list, and a real dialog made up of real conversation for this to continue. There appears to be a desire to do this, but there does not appear to be anybody willing to take responsibility to do it right, except perhaps (presently) Yaro, who John apparently not only has never met, but in all likelihood, has never communicated with. Hence, "let your wiki communicate for you." It is very good at this, I speak from personal experience on nationwide efforts, though I will tell you it takes work, dedication, time and writing skills. Dismissing wiki as "too detailed" or "ineffective" is not a green flag to begin a race. It means "stop, fix the wiki so anybody who comes along will know what to do." So: "bzzzt." Not there yet, though, it seems Yaro was able to glean enough to make progress. Grow his kernel of expertise and expand what works about it. > Many locations in Canada do not have a group of OpenStreetMap local mappers. > Many locations do. Locating local groups is difficult. My understanding is > it has always been it is the local community who make the decision to do an > import. We did use talk-ca and if you wish to continue the conversation then > I would suggest that is the place to hold the conversation. I think the > problem here is defining the ideal local community. It is probably somewhere > between the whole of Canada and each individual municipality and contains > groups of local mappers. Really? Then, fix this. A national project (nearly single-handedly) like this into OSM is a very, very tall order. It seems quite disingenuous to me to initiate these data and "hope for the best." It's not exactly the same as giving matches, gasoline, dynamite, liquor and car keys to teenagers and being surprised at a tragic outcome, but it does stray in that direction of irresponsibility. This time, I don't think you are allowed to be surprised. > The intent is certainly to involve local mappers, building outlines by > themselves are especially interesting but building outlines with added tags > are much more interesting. We need boots on the ground, we need local > mappers onside. You (John, others, the poorly-focused impetus to import these data...) DID get local mappers involved. Today, I believe John implied or said he hasn't even communicated with them. (Or barely has). Yet while some work seems patient and better quality, enough bad data alarmed Nate (and others, myself included) enough to say something. This simply shouldn't happen. Please right your ship. I don't pretend to represent all of OSM as I ask this, but I do stand tall in this project and politely ask you to do so. Nate wrote some powerfully-potent directions for this building importation to go in with his later post. Those are a good start, a "productive way forward." Talk-ca (this channel) and wiki (including its Talk page, Discussion tab) are wide-area, very open, vetted, scrutinizable methodologies to communicate about this. Let's keep the way(s) forward OPEN for discussion so this doesn't happen any longer. Please! We don't need 37,000 import plans and nobody is suggesting we do. We do need good project management to import Canada's buildings. There, I said it. (Again). This starts with good, open communication. Nothing less will do, or you consign your project to a whispered hope upon the wind, and that won't do it. SteveA California ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-us] US Bureau of Land Management Boundaries
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
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
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
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
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
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
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 ;)
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 ;)
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-ca] Exit with name on node *and* destination
Between "out meta;" and "out meta qt;" there should be a >; but sometimes this
gets mangled.
Entre "out meta;" et "out meta qt;" il devrait y avoir un >; mais parfois cela
est mutilé.
So, I'm choosing to share an "OT share link:"
Donc, je choisis de partager un "lien de partage OT:"
http://overpass-turbo.eu/s/DrG
Good luck / bonne chance,
SteveA
California
> As Overpass Turbo allows named area geocoding, try this:
> Comme Overpass Turbo permet le géocodage de zone nommée, essayez ceci:
>
> [out:xml]
> [timeout:25];
> {{geocodeArea:Quebec}}->.searchArea;
> (
> way["service"="emergency_access"](area.searchArea);
> );
> out meta;
>> ;
> out meta qt;
>
> You can modify what is inside the "way" part of the query any way you like.
> Vous pouvez modifier le contenu de la partie "way" de la requête à votre
> guise.
>
> SteveA
> California
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Exit with name on node *and* destination
On Nov 6, 2018, at 8:08 AM, Pierre Béland wrote:
> Petit test rapide avec Overpass. J'observe que les clés suivantes sont
> utilisées
> highway=service
> service=emergency_access
> access=no
> exemple https://www.openstreetmap.org/way/19692719
>
> La Requête Overpass ci-dessous avec paramètre around, détecte les voies de
> service à proximité d'autoroutes sans clé service=emergency_access ou
> access=no. Sélection d'un grand bbox requiert long délais d'exécution. Et
> d'autres chemins de service se retrouvent dans les résultats, notamment les
> voies de service pour haltes routières.
>
> https://www.openstreetmap.org/way/20057142#map=16/44.8089/-73.4450
>
> Pierre
As Overpass Turbo allows named area geocoding, try this:
Comme Overpass Turbo permet le géocodage de zone nommée, essayez ceci:
[out:xml]
[timeout:25];
{{geocodeArea:Quebec}}->.searchArea;
(
way["service"="emergency_access"](area.searchArea);
);
out meta;
>;
out meta qt;
You can modify what is inside the "way" part of the query any way you like.
Vous pouvez modifier le contenu de la partie "way" de la requête à votre guise.
SteveA
California
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-us] California is too big ;)
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 ;)
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-ca] Talk-ca Digest, Vol 129, Issue 15
On Nov 5, 2018, at 7:29 AM, keith hartley wrote: > I saw it was a great job. But you're correct, I have no documentation on how > they did it. Licence process, wiki ( I feel Steve already yelling at his > computer) If you mean me, I'm saddened to hear that others think I "yell." Rather, my motivation is to see that: 1) High quality (or VERY high quality) data are what get uploaded to OSM, 2) License terms are compatible with ODbL (I respect how difficult this can be, especially with the limited bandwidth of OSM's LWG and the wide variety of activities taking place in a very widely geographically dispersed country like Canada) and 3) Communication about these efforts stay within a public realm (or "more public," as in "open source based protocols" rather than "secret sauce walkie talkies" hobbled by license agreements, like Facebook/Twitter/Instagram and Slack). Yes, primary among these are talk-ca and imports mailing lists, OSM's wiki pages, especially explicit Import Plans and Tasking Manager for projects "approved" by the wider community and actually underway. Right now, with John Whelan's (and others') recent newer thrusts to provide momentum to buildings getting entered (and/or improved) on Canada, I'm doing my best to "largely watch" (from the sidelines) what is happening right now. I see no reason to "burn bridges" when I don't mean to or need to do that. And yes, I do know that "you catch more flies with honey than you do with vinegar." (No, that isn't a slight at calling anybody "flies," rather a saying that means "positive encouragement works much better than throwing rocks"). SteveA California ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Stats Canada new building outlines Open Data do we wish to import it?
On Nov 2, 2018, at 3:58 PM, John Whelan wrote: > So to paraphrase your reply. A centralised import plan in the wiki which > says the data is approved for import and should be tackled in chunks of some > sort of region since we are a decentralized organization. Which I think is > similar to the way Task Manager works. The project is broken into tiles and > each tile is tackled completed separately. The 'Tiles' would of course be > somewhat larger in area and there is a technical limitation as to how big an > area can be downloaded from the OSM server. > > The local mappers certainly have a role to play and because the goal is not > only to import the buildings but to enrich the tags with commercial etc so > the tag enrichment would be a task that a mapathon could tackle. I > personally don't think a new mapper using iD in a mapathon has a role to play > in importing the building outlines into OSM. > > The plan should include the technical steps to import the data. AND, must include how existing data in OSM (as there appears to be "in some cases, significant" (I haven't examined the entire dataset, to do so would be overwhelming) which overlap with the "official datasets" will be conflated. That is a critical step. SteveA California ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Stats Canada new building outlines Open Data do we wish to import it?
On Nov 2, 2018, at 3:35 PM, Pierre Béland wrote: > La rédaction d' une page wiki pour l'ensemble du Canada peut répondre aux > exigences du groupe Import de OSM. Mais l'organisation doit être > décentralisée. Je conviens qu'il est plus facile de rédiger un "plan d'importation" unique pour tout le Canada. Cela devient donc très difficile à déterminer pour les Canadiens. Toutefois, si de tels plans deviennent localisés, des plans d'importation réellement localisés sont réellement nécessaires. Bien sûr, il peut y avoir des chevauchements et des similitudes, mais des plans d'importation différents mènent nécessairement à une documentation unique et distincte. Lorsque je télécharge de petits échantillons de données (par exemple, ODB_NorthwestTerritories qui n'inclut que Yellowknife), je constate qu'une grande partie ou la plupart des données des fichiers de formes de construction sont déjà téléchargées vers OSM, à quelques rares exceptions près ou lorsqu'un très faible pourcentage de les bâtiments existants ne diffèrent que d'un mètre ou deux. Tout plan d'importation doit tenir compte de la manière dont ces données seront regroupées. Cordialement, SteveA Californie ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Enablers and Barriers for Voluntary Participation in Crowdsourcing Platforms
On Nov 2, 2018, at 9:31 AM, John Whelan wrote: > My feeling is OpenStreetMap has two sides. The first is local adding local > knowledge to the map. The other I'll call armchair mapping. When Stats > Canada did the pilot it tapped the local Ottawa mappers who meet physically. Speaking from nearly a decade of experience, OSM has many, many sides, though the two that John Whelan identifies are two many find "readily apparent." I quick-read the study, which was actually quite informative in that it broke up similar crowdsourcing efforts (OSM is only lightly mentioned) into demographic categories, with some surprising results. One is that many volunteers are older, sometimes disabled (stroke victims noting benefits of "repetitious tasks which help my brain to heal" was cited) and have a particular need for the sorts of social feedback which projects like this uniquely offer. (At the same time, there is often a sharp dichotomy between these sorts of crowdsourced projects and social media, with many in the study who prefer the former appearing loathe to use the latter). Another very important take-away is how participants in projects like these truly improve their skill-sets (seriously improving quality of submitted data) over time: like many things, the longer one participates, the better become their skills. This emphasizes the importance of "growing experts," something seldom mentioned in OSM. > I would agree that amongst mappers with the most edits there is a high number > of retired people and those with disabilities involved and these may not be > visible. Tapping them for groups coming together to map can be a problem. It might appear that way (that they are invisible), yet there is no denying that "they find you." In short, "build a project that attracts older, likely high-skill (or can grow there) participants, and they will come." > In my view typically the most productive mappers are those with a special > interest. Adding WiFi access or churches for example or even a change of > street name. While it is difficult to say why mappers become productive, it may be even harder to do the apparently more simple task of defining "productive." I know one mapper who flits about the entire planet in OSM, seeking to "up his stats on a leaderboard" as he measures the number of edits he makes in the tens or hundreds of thousands. Needless to say, the quality of his edits, and how productive he is, is a matter of contention. There is such a thing as "high quality" and in OSM this can and should be defined and refined especially for major projects. Certainly "quality of data entered" is one metric, yet even that can be hard to define or measure, unless strict criteria are established at the beginning of a project as a goal to strive. Once again, and especially in highly ambitious projects (like BC2020) this underscores the need for some up-front planning, up-front project management, up-front expectations of data quality and up-front documentation of all of these things so that these expectations are met and measured along the way. (Project Management 101, really). > We also have a number of teachers who would like to use OSM and in particular > the building project to involve their students. We get a fair amount of data > added but the quality can be questionable. HOT and others I think have found > that using a restricted set of tasks and tags works best. I personally have experienced helping professors at the university level (computer science, environmental studies...) use OSM, as students at the undergraduate level readily take to OSM. Younger students (high school, middle school) enjoy some success with it, more often at smaller, less ambitious tasks, a recently popular one in the USA being "micro-mapping our local school campus." (Drinking fountains/water stations, extremely detailed sporting facilities, footways and associated potential routing, landscaping, restricted/off-limits areas, parking areas for autos, motorcycles, bicycles, etc.) What often works is breaking students into functional groups (sports facilities, transportation, amenities...) and having a teacher/administrator check the results of each group. The tags can start out restricted and stay that way, or they can start out restricted and allow the students to develop further "depth" by researching OSM's wiki pages, or even (yes, this is advanced) structure their own scheme. For example, a high school has four different libraries in several different buildings, or extensive sports facilities, how might we best tag these? And whether young, old or in-between, Martijn van Exel (an OSM superstar) has proven with his (well, largely his) MapRoulette project that "gamification" can really super-charge particular kinds of data entry/improvement sub-projects like few other strategies can. The Study confirms this, saying "Platform features such as gamification,
Re: [Talk-ca] Nova Scotia imports, and boundary=land_area
On Nov 1, 2018, at 12:47 PM, Дмитрий Киселев wrote: > Looks like the wiki needs amending to only list open data with the correct > license either separately or a note added to each entry. Mmmm, not "only," an Import Plan is required, too. That can be part of a wiki that describes the project in general or stands on its own as a separate wiki. But it is required. SteveA California ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Open Database of Buildings / Base de données ouvertes sur les immeubles
Additionally, the greater OSM community looks forward to your Import Plan that follows our Import Guidelines ( https://wiki.openstreetmap.org/wiki/Import/Guidelines ). Regards, SteveA California > On Nov 1, 2018, at 11:22 AM, John Whelan wrote: > > I think on the OSM side we probably need to think this one through and get > organised. > > In Ottawa on the first import we went through all the steps to do the import > including getting agreement with the local mappers and we were very fortunate > in having an organised team of competent local mappers to do the import. > > It went reasonably smoothly but there were some questions asked and one or > two buildings were probably remapped which raised some eyebrows. Since its > been released under the federal government open data license licensing isn't > an issue. > > If we do nothing on the organising side then we will almost certainly get > individuals importing Open Data in an ad hoc mode as has been happening in > Nova Scotia recently. > > My feeling is it would be better if mappers in the major cities / regions > such as Toronto and Montreal took the lead for their cities / regions. > > Cheerio John > > > > Alasia, Alessandro (STATCAN) wrote on 2018-11-01 2:06 PM: >> Released today! / Diffusée aujourd’hui >> Share with your networks ! / Partagez avec vos réseaux ! >> >> >> ***(EN) >> Open Building Data: an exploratory initiative >> This exploratory initiative aims at enhancing the use and harmonization of >> open building data from government sources for the purpose of contributing >> to the creation of a complete, comprehensive and open database of buildings >> in Canada. The outcome of this exploratory work is a first version of the >> Open Database of Buildings (ODB), a centralized and harmonized repository of >> building data made available under the Open Government License - Canada. >> This initiative originates from insights taken from the Statistics Canada >> pilot project on data crowdsourcing, which used OpenStreetMap as a platform >> for integrating data on building footprints. In addition to the possible >> benefits of crowdsourcing, that project highlighted the potential of >> integrating open data from municipal, regional, and provincial governments >> to meet the needs of official statistics. >> In its current version (version 1.0), the ODB contains approximately 4.3 >> million building footprints. >> https://www.statcan.gc.ca/eng/open-building-data/index >> Open Database of Buildings (ODB), >> >> *** (FR) >> Données ouvertes sur les immeubles : une initiative exploratoire >> Cette initiative exploratoire vise à accroître l'utilisation et >> l'harmonisation des données ouvertes sur les immeubles provenant de sources >> gouvernementales en vue de contribuer à la mise en œuvre d'une base de >> données complète, exhaustive et ouverte sur les immeubles au Canada. Le >> travail exploratoire a mené à la création d'une première version de la Base >> de données ouverte sur les immeubles (BDOI), un référentiel centralisé et >> harmonisé des données sur les immeubles rendu public en vertu de la Licence >> du gouvernement ouvert du Canada. >> Cette initiative est fondée sur les leçons tirées du projet pilote de >> Statistique Canada sur l'approche participative en matière de données, qui >> avait employé OpenStreetMap comme plateforme d'intégration des données sur >> les empreintes d'immeubles. En plus des avantages potentiels de l'approche >> participative, ce projet a mis en lumière la possibilité d'intégrer les >> données ouvertes des administrations publiques municipales, régionales et >> provinciales afin de répondre aux besoins en matière de statistiques >> officielles. >> Dans sa version actuelle (version 1.0), la BDOI contient environ 4,3 >> millions d'empreintes d'immeubles. >> https://www.statcan.gc.ca/fra/donnees-ouvertes-immeubles/index >> >> Base de données ouverte sur les immeubles (BDOI) >> >> >> Alessandro Alasia >> Chief | Chef >> Data Exploration and Integration Lab (DEIL) | Lab pour l’exploration et >> l’intégration de données (LEID) >> Center for Special Business Projects | Centre des Projets Spéciaux sur les >> entreprises >> Statistics Canada | Statistique Canada >> alessandro.ala...@canada.ca / (613) 796-6049 >> >> >> >> >> ___ >> Talk-ca mailing list >> >> Talk-ca@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/talk-ca > -- > Sent from Postbox > ___ > Talk-ca mailing list > Talk-ca@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-ca ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Dartmouthmapmaker
Being as gentle (though not local) as I can be, I continue to assert that our wiki for BC2020 in general and https://wiki.openstreetmap.org/wiki/WikiProject_Canada/Building_Canada_2020#The_data_that_could_be_mapped as a specific section IN that wiki (calling attention to these tags, with hundreds of potential values): building man_made addr start_date entrance amenity and others might prove very helpful starting points. Often the simple act of reading OSM's built-in wiki documentation is one of the best, if not THE best starting point. Of course, talk- mailing lists, our forum and many other sources of advice/documentation/help are available, too. Regards. SteveA California > On Nov 1, 2018, at 9:40 AM, john whelan wrote: > I've discussed the Open Data side with them but I think they could do with a > bit of guidence on the tagging side. Could someone ideally more local than I > point them gently towards map features and more standard tagging? > > I must confess my knowledge of tagging is a little limited to highways and > buildings. > > I get the impression they are open to dialog if treated gently. > > Thanks John > ___ > Talk-ca mailing list > Talk-ca@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-ca ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-us] New United States Bicycle Routes!
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!
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!
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!
"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!
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"
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!
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
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-ca] Hydro Network (inland water) question
Heck, all kinds of things are fun to map: bike routes, railways, making sure provincial and TransCanada route relations are all lined up and tagged correctly, bus and public_transport, small details (micro-mapping), like gymnasium/library details and drinking fountain locations in elementary/middle/high schools, it's almost endless. Now, all the bodies of water in Canada, the 2nd largest geographic country on Earth, and with "hundreds" (you can grow it to thousands, I know you can) of dedicated mappers: wow, that is something I'd call "you've got your work cut out for you!" I mean that to be encouraging rather than discouraging. OSM, it seems (and I've been at it most of its life) is a longer-term project, it's really only starting to fly after fifteen years or so. Give it a few more decades (really), and even in a few years, it does, can and will get better. It takes time, it takes dedication, it takes good communication, it takes people working well together. Largely speaking (and Canada isn't large, it's HUGE!), so far, so good. Encouragingly, SteveA California > On Sep 27, 2018, at 4:42 PM, john whelan wrote: > Besides bus stops are more fun to map. ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-us] More-complex wiki pages are spitting up Lua errors
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
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
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
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-ca] Fwd: BC2020i - update Sept 2018
Thank you for those clarifications, John. I speak for myself, but I do feel confident that others are learning from what you say and that OSM and all involved can and shall do better. Honestly, I look forward to "better processes" which "make more open data available to OSM" (a worthy goal, indeed). "Getting familiar with steps" is part of it, and I know we are good people as we see first crawling, then walking, then running, then flying. May Canada and its buildings together with OSM gain much altitude and indeed fly. Governmental agencies around the world can and will gain, OSM can and will gain and it will be a win-win-win all around. Part of that happens because we talk to each other (civilly) and lots of people nod our heads and many/most of us say, "hey, yeah, that's a pretty good idea/way to do things, let's do it like that." Like learning to walk, it is a process, it isn't that hard, and it does come naturally. SteveA On Sep 17, 2018, at 12:16 PM, john whelan wrote: > Just a comment Alessandro is not a dedicated project manager but rather the > person that the project manager reports to. Currently in addition to his > normal job he is also acting in the position above his so he really is doing > two jobs at once. Bjenk was the project manager who pulled the project > together and worked hard and closely with the local OSM mappers on the first > phase but has moved from Stats Canada to another department. > > Alessandro has had staff working in the background to find ways to make more > open data available to OSM but probably isn't familiar with all the steps to > bring it in. > > The numbers from Ottawa would suggest that we need to understand more about > what information is most useful and which can be easily obtained. > > This isn't just about Canada by the way there are other places on the world > where this sort of information and the techniques used on the stats side can > be useful. > > Cheerio John ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Fwd: BC2020i - update Sept 2018
I (rather fully, and without Alessandro's accusatory "troll-like behaviours," wow) addressed Alessandro in an off-list email reply, though I quickly received an "out of the office until September 21" bounce-back. We shall see. One thing I must say here I found unfortunate in Alessandro's post was the cavalier attitude of "I would like to have more time to write emails...so do not be offended if I will not continue this conversation." Again, wow. As long as we keep it civil, and I'll give us a "passing grade, just" along those lines, we can and should continue this dialog. Please, let's do our best to keep it civil. SteveA > On Sep 17, 2018, at 8:31 AM, Alasia, Alessandro (STATCAN) > wrote: (a reply to my missive) ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Fwd: BC2020i - update Sept 2018
Matthew, I personally thank you for sharing Alessandro's missive with talk-ca (an OSM-based list).However, Alessandro mentions "BC2020i" (and even "BC2020i-2"), initiatives which "used" (or proposed to "use") OSM as a data repository. Not wishing to rehash history about this yet again, the initiative was found to not fully respect some basic tenets of OSM (primarily that process and importation of data be "Open") and a genuine attempt was made (partly rather publicly here) to re-imagine a re-branded project (BC2020, no "i") which more openly and harmoniously integrated with a wider OSM community using familiar and more-open communications channels like our wiki and this talk-list.As Alessandro didn't mention OSM one single time in that message, yet it was forwarded to this list, I remain quite curious what role OSM is to or might play in any "BC2020i-2" initiative. So, I invite / politely request Alessandro to post here exactly what that is or will be. Is it a national-scale import of the Bing building data (as he says "what they did in the US")? I realize that from STATCAN's and indeed a much wider Canadian perspective, this "initiative" will be much more than that, benefiting many, and for that I do share enthusiasm. Still, I ask the specific question from an OSM perspective: what role will our mapping project play?Please, Alessandro, address OSM directly (in this list) what OSM is to BC2020i-2. You might start by addressing what is wrong with BC2020 (no i) as it exists in our wiki and how BC2020i-2 might diverge from that, but I'd prefer you explain it to us, rather than me guessing here in talk-ca.Regards,Steve AllOSM Volunteer since 2009 ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-us] Denver RTD's public_transport growth
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
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
Re: [Talk-ca] counting buildings - ( 2020 project ) - help please.
On Sep 12, 2018, at 11:06 AM, john whelan wrote:
> One of the requirements was to create something that did not require an
> Internet connection
OK, yet I had no way of knowing that from your post. Though, that is an
"interesting" requirement for a crowdsourced, Internet-based map database.
> or a Ph.D. in OpenStreetMap jargon.
C'mon, John, I'm offering earnest help with a powerful tool familiar to a great
many OSM users and a drop-dead-simple query whose guts are:
{{geocodeArea:Ottawa}}->.searchArea;
(way["building"="residential"](area.searchArea););
That's pretty much it, and you get your results in seconds visually or in
various export formats.
> As I mentioned I'm after end users rather than OSM technically knowledgeable
> ones.
By substituting "node" for "way" or other text-strings for the keys or values
you're looking for, and with a multitude of output formats, this is not
Ph.D.-level stuff: it is designed to easily query OSM data, returning results
in familiar "map/visually" OR well-known geo datafile formats. It isn't
jargon-y, it IS used by "end users" and by OSM technically knowledgeable ones
alike. Using OSM data? (Yes, you are): use OSM-based tools. You want
jargon, use R. I'm trying to help create light, not heat.
> Another was the ability to combine the information with other data.
Export the results of OT queries, and ye shall.
> Thank you for your thoughts and hopefully the answers will clarify what sort
> of assistance I'm after.
You are welcome, and I'll be curious to watch what happens. As I saw your
request for feedback is to be off-list, we who are on-list (I speak for myself
right here) appreciate hearing of any fruit your query may bear.
Best regards,
SteveA
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] counting buildings - ( 2020 project ) - help please.
Whew, seems like overkill. Try "overpass turbo" (OT) for such queries. Here is a sample, and the query language (OverPass QL) is text-based and OSM-friendly, as it uses the tags you're searching for: http://overpass-turbo.eu/s/BQ6 When it dialogs that the query will return a lot of data, click the "continue anyway" button and wait a few seconds. The data are returned visually and you can export them in various formats (raw OSM data, GeoJSON, GPX, KML). Look to the left column to see how easy the tags are and read our wiki on OT for rich and rewarding documentation. Have fun, SteveA California > On Sep 12, 2018, at 10:39 AM, john whelan wrote: (a lot about how hard it is to query our data). ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] GitHub app for BC2020i Challenge
On Sep 6, 2018, at 4:30 PM, john whelan wrote: > The pilot project itself did manage to get a fair amount of accurate data > into OSM. That data is still there and can be used. It was instrumental in > supporting the HOT summit in Ottawa. It managed to raise awareness within > local government both in Canada and in Africa about how OSM could be useful > and it clarified a number of legal issues about importing data. Then, quite a number of events caused it to go off the rails. OK, that happens; no judgement on my part, I'm far, far happier to try to watch the smoke clear and "might I offer to help?" > > And I'm not boasting, but I did put some effort into the richest set of > > potential tags (harvested from our wikis) than I believe anybody else did, > > and I don't really have any specific interest in the project, except that > > it be a WELL RUN project. (So I tried very hard to "seed it well"). > > You mean me getting the recumbent trike out and site inspecting a few hundred > buildings and adding tags to them was for nought? How sad. John, I'm on your side, the side of OSM having great data while it builds communities across Canada, universities, high schools, libraries, etc. I'm happy the project has "stubbed in" (it's certainly "not nothing!") at least some data. Dust off your hands and keep going! (Is hopefully the attitude I'm encouraging you to adopt). > There is still a gentle movement to gather more data over time, whether we > are keeping the current building data up to date is a separate issue. Stats > is still trying to find ways to make building outlines available under their > Open Data license. A 100% separate track for which I wish them the very best of luck. That may or may not be successful, and CAN and SHOULD happen on a parallel track with OSM strategies which work. I'll stand shoulder-to-shoulder with THAT spirit, as it is what makes OSM a very powerful OSM. > The approach used on the pilot to import building outlines manually has been > picked up by Microsoft who have been making them available for the USA and I > understand Stats were involved with discussions with Microsoft about some > technical aspects. Truly, I'm glad to hear it. OSM and Microsoft (and now, it turns out, Stats Canada) do get symbiotic every once in a while, and we're all the better for it as/when it happens. > The Ottawa pilot was a perfect storm in many ways with many different players > involved coming together. Reproducing it is harder than it first seems. I get that, so do others. A "more valuable" aspect to pick up as a shiny coin from that is the learning experience that it is. In QA this is called a "post mortem" and is one of the most valuable data chunks for "the next phase" (and there always is a next phase). > What I would like to see is someone pick up doing analysis with R r.org to > see if we can build the feedback loops that might help motivate getting the > tags populated. Heh, you could sketch up a wiki to get them started...! :-) (It's not a bad idea, really). Steve ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] GitHub app for BC2020i Challenge
On Sep 6, 2018, at 1:14 PM, john whelan wrote (replying to me, stevea): > > Hm, we tried to revive the wiki, a tried-and-true OSM methodology for doing > > EXACTLY that. Is there something wrong with that idea? > > No this project was initiated by Stats Canada, but without clear requirements > or feedback about what had been achieved. The Stats Can side wasn't > dependant on normal OSM mappers but my understanding was it was hoping to > draw in new mappers. John, BC2020i (note the i) was initiated by Stats Canada. Threads here, consensus and the wiki declared it dead, as it failed on a number of fronts, primarily that it didn't respect OSM in certain ways in which OSM must be respected. It MIGHT have become resurrected as BC2020 (no i) and the wiki were attempts to do that, especially as Stats Canada was out of the picture by then, as they weren't going to contribute to either the wiki or the BC2020 itself, though, like anybody who "takes" (uses, and not in a bad way) OSM data, StatsCanada would be welcome to the results of BC2020 (and BC2020i is dead, I'll say it one more time). We stripped away what was wrong with "i" and slightly renamed the project to conform to the way that OSM has, can, does and will complete projects (including, but requiring that we use wikis). BC2020 seems to have become moribund and ineffective, though I continue to hold out high hopes that it can be successful. OSM actually DOES have clear requirements or feedback, part of those are naturally "built in" to crowdsourced projects, part of those need a bit of goosing along by prompting volunteers to communicate well (wiki is ONE way, not the only way) via simple things like reporting progress and/or continuing to sharpen up focus because tagging started out as an early draft, but now is a "more complete" or "final" draft. Sure, any good project wants to start out with clear goals (and should) but a modest bit of mid-course correction certainly won't prevent successful completion. > Fine but a couple of maperthons that were organised had data quality issues > and no clear guidance about what tags were most valuable. That's because no QA was planned up front, just like I suggested to do last year and into January of this year. And I'm not boasting, but I did put some effort into the richest set of potential tags (harvested from our wikis) than I believe anybody else did, and I don't really have any specific interest in the project, except that it be a WELL RUN project. (So I tried very hard to "seed it well"). In crowdsourcing, yes, this can be challenging, but communication is the lynchpin that allows it. Wikis, at least in OSM can be and often are a critical component of the successful ongoing (status reporting, etc.) and completion of projects. > I could be wrong but I'm not aware of any significant movement on the project. OSM (worldwide, not "just" in Canada or any particular country) seems to be in a communication crisis, where everybody thinks that some sort of "secret-special-sauce walkie-talkie" (like GitHub or Slack) will solve everything. No. While those have their place (let me emphasize, I truly mean that) they will continue to Balkanize (fracture) and legally bind (have you READ the contracts GitHub and Slack ask you to agree to?!) OSM volunteers far past the state of hobble-and-wobble, it will kill us. Talking about GitHub is like pilot-radio-chatter: specialized, harmful to BUILDING new community (which is CRITICAL in BC2020) and will keep you grounded as certain as a hurricane. OSM Canada knows how to crawl, and even walk. To run, and even fly, especially with BC2020, use what we have. The fancy stuff might (MIGHT!) be used later. SteveA ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] GitHub app for BC2020i Challenge
> Personally I think if the BC2020i is to be revived mappers really need some > feedback on what has been done and what tags are of interest. Hm, we tried to revive the wiki, a tried-and-true OSM methodology for doing EXACTLY that. Is there something wrong with that idea? I've been trying to keep "the embers orange and warm" on this project (via its wiki) since January. https://wiki.osm.org/wiki/WikiProject_Canada/Building_Canada_2020 If there is something wrong with that wiki (John Whelan, you have described its history both here in talk-ca and to me via private email any number of times), then re-write it. I think it is at least a start to describe what you (Canada) are trying to do, so if it or parts of it are useful, use it. On an upside, there are a lot of data there, (though some of it might be junk or outdated), and so as a corollary, on a minor downside, it could be said to be loquacious/wordy/overly detailed. On a MAJOR downside, "BC2020" (not suffixed with an "i" as that is rightly declared to be dead) "needs reviving." OK, revive it. If not via wiki, "because mappers really need some feedback" (it DOES mention Active Monitoring tools) and "what tags are of interest" (it DOES mention Tag Standardization" and "The data that could be mapped"), then HOW? The answer: (or at least an excellent one): use our already-built, well-established, good-for-our-community tools which WORK. Go! SteveA OSM Volunteer since 2009 ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
[Talk-us] Denver RTD's public_transport growth
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)
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
