Re: [Talk-us] Railway Wiki
(Answered off-list). SteveA ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] finding city boundary info?
Please tag boundary=census on census tracts. These are distinct from boundary=administrative + admin_level=8 (for city or town boundaries, at least in California). See United States/admin_level for what works out to be all fifty states and six "other things" like Territories and Commonwealths. Another (easy-to-use) wiki is United States/Boundaries. Both of these are linked in the "United States" row of admin_level's "10 levels" table. The reason that administrative and census collide in the boundary key (making you choose one or the other) is because they really are things distinct from one another. Choose the correct one, especially true when making the distinction between boundary=census and boundary=administrative. It is not correct to include an admin_level=* key on objects tagged boundary=census. Thank you and please let the community know if either (or both) of the wikis noted in the first paragraph above do not explain this to your satisfaction for tagging these things in the USA. (There may be yet-to-add details to those wikis, though they are believed to be largely correct and current). ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Reference numbers to use for hiking trail route relations
On Oct 15, 2020, at 12:06 PM, Joseph Eisenberg wrote: > Many of the old "pack trail" labeled features near my home-town are now > overgrown and barely usable. I would be skeptical about the utility of this > tag - mappers will need to survey the trail in person before suggesting that > it is currently suitable for horse, mules or other pack animals. Right: many "trails" labelled "Pack Trail" are either from a long time ago and/or mapped a long time ago. I would be wary of the utility of this label on many maps, but that can be said of many labels on many maps, especially when they are older or specify an "older" aspect of a map label such as "Pack Trail." This has an old-fashioned sense about it, as while pack animals on trails are certainly still used, it's safe to say far, far less than they were in the 20th (and 19th and previous) centuries. SteveA ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Reference numbers to use for hiking trail route relations
brad wrote > I think I've seen old usgs topo maps, or perhaps FS maps with trails labeled > as pack trails. Not quite sure what it means, probably nothing anymore. > Perhaps the OSM person just used the info from the old map. A "pack trail" is suitable for pack animals, such as donkeys or horses for carrying "in" supplies, building materials or hauling "out" garbage, ore waste or the like. It is more substantial than a "single-track" trail for a bipedal human, but may or may not be suitable for an off-road vehicle like an off-road motorcycle, all-terrain-vehicle / four-runner or other high-clearance, two-axle vehicle. It is a common phrase seen on maps of the 19th and 20th centuries, but has fallen somewhat out of favor, though is still seen and used. SteveA ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Recent Trunk road edits
Albert Pundt wrote: > It seems another editor by the name of Fluffy89502 is going around doing > similar edits all over the US, even demoting divided, multi-lane roads. Other > users have commented on his changesets and he cites the wiki's wording. Ugh, I don't like to complain about specific Contributors, but for Fluffy89502, I'll make an exception. He seems to be based out of the Greater Los Angeles area (based on what appears to be decent work under the same name in Wikipedia) and changes road classifications in a way that makes it sound like a religious sermon (based on some federal standard, which to me seems both obscure and not-living-in-this-reality). He also made an unholy mess out of landuse around the Mojave Desert with landuse=heath in a way that was more like "pollution" instead of "vandalism." His changeset comments are MOST unhelpful, being very generic like "landuse" (and that's all he wrote). I have written to him several (many?) times in changeset comments and via missive, yet I think I've only received two responses, both rather curt and smug. One was "I guess I better not do that anymore" (after I admonished him for vast natural=heath and natural=scrub messes that I redacted) — and then he went right ahead and started doing it again, the other was a sort of chapter-and-verse "sermon" on how certain (obscure) federal highway standards "absolutely" apply on roads I frequently drive (no, they don't). He'll only map something if it renders: he's much more interested in "seeing" his work than he is in getting it right. I'm very heartened to see the greater community talking about "problem editors" in a larger (and louder) context. While I'm no fan of edit wars, let's keep up the vigilance and good work to remain as civil as we can with these folks. Sometimes, with patience and a sort of mentoring-while-not-appearing-to-be-mentoring, they can be shaped into great contributors, other times, they are stubborn and don't really belong in our project. SteveA ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] [Tagging] Large fire perimeter tagging?
James Umbanhowar wrote: > Something else to consider is that even though there is a perimeter for > a fire, there can be highly variable impacts on the landcover within > the perimeter. > Some areas may have not burned, other areas only burned > the understory, some with limited burning of trees and other with full > tree killing canopy burns. The effects of these will also depend on > the specific species that burn. So to convert and entire area inside a > fire perimeter to one land cover without extensive surveying would > likely be in error. (Please take further discussion of this thread to the tagging list https://lists.osm.org/pipermail/tagging/2020-September/055496.html ). James, this is all well known and part of the intended solution (to better map) here, thank you for pointing this out. There is no intention to "convert an entire area" inside of the fire perimeter, rather careful RE-mapping of SELECTED areas which have ACTUALLY burned (e.g. a natural=wood area is shrunk to where trees remain and "no data" or "blank map" is what remains of the burned area). This will likely best emerge when newer imagery data become available. > It seems as though the perimeter tag is the most verifiable at this point. Yes, to be clear: this fire=perimeter polygon intends to delineate the area where, as they become available, newer imagery data which display fire damage should be used to update the map. In short, the polygon conveys "here is the EXTENT of the area that burned: while it isn't yet clear whether existing landcover natural=* tags need to be altered, that is likely, as there was a major fire inside of these bounds." That's all, really. This is a 140 square mile rural area, formerly heavily/primarily wooded, not a few blocks of residential or commercial landuse, as are many typical urban fires. "Huge" is about right. At least one person (a HOT technical manager, also a firefighter) said (on the tagging thread and in off-list emails to me) that such polygons can serve a historical purpose by remaining in OSM, though I see little purpose in doing so for extended periods of time, believing that after the map is updated with newer imagery, the polygon's (initial) purpose is exhausted and can be removed from OSM. His arguments for why it should remain have to do with better building polygons enclosed by the perimeter during HOT re-mapping and into the re-population and re-building phases in landuse=residential areas that happen after a major fire. As a firefighter (and HOT mapper), he finds such data helpful, as in that case, a fire=perimeter polygon remaining is valuable history. That could last years, perhaps decades, I'm certain the effects of this fire will be long-lasting: many of the millions of trees that were destroyed were several hundred years old. Either way (the polygon is long-lasting or ephemeral to the extent it aids better landcover mapping), it is a lightweight data structure, tagged with only three tags (fire=perimeter, start_date and end_date), it remains invisible to all renderers (that I know of) and is intended to aid mappers determining "should re-mapping of landcover happen HERE, in or out?" I find that balance of data vs. usefulness "worth it." SteveA ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] United States Bicycle Route System ballot(s) pending AASHTO approval
Thanks, Richard. That's valuable input and I've updated the USBRS wiki, which effectively puts the (informal) proposal for proposed:route=bicycle into a sort of stalemate. SteveA ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] [Tagging] Large fire perimeter tagging?
Clifford Snow wrote: > Just a reminder, landuse is to tag what the land is used for. landuse=forest > is for areas that have harvestable wood products, ie trees. Just because > there was a fire doesn't mean the landuse changes. Landcover is a better tag > for burnt areas as well as areas just clearcut. This thread likely shouldn't have been cross-posted by me to talk-us and is now (substantially) continued at the tagging list. SteveA ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Large fire perimeter tagging?
I didn't get a single reply on this (see below), which I find surprising, especially as there are currently even larger fires that are more widespread all across the Western United States. I now ask if there are additional, appropriate polygons with tags I'm not familiar with regarding landcover that might be added to the map (as "landuse=forest" might be strictly true now only in a 'zoning' sense, as many of the actual trees that MAKE these forests have sadly burned down, or substantially so). Considering that there are literally millions and millions of acres of (newly) burned areas (forest, scrub, grassland, residential, commercial, industrial, public, private...), I'm surprised that OSM doesn't have some well-pondered and actual tags that reflect this situation. My initial tagging of this (simply tagged, but enormous) polygon as "fire=perimeter" was coined on my part, but as I search wiki, taginfo and Overpass Turbo queries for similar data in the map, I come up empty. First, do others think it is important that we map these? I say yes, as this fire has absolutely enormous impact to what we do and might map here, both present and future. The aftermath of this fire (>85,000 acres this fire alone) will last for decades, and for OSM to not reflect this in the map (somehow, better bolstered than a simple, though huge, polygon tagged with fire=perimeter, start_date and end_date) seems OSM "cartographically misses something." I know that HOT mappers map the "present- and aftermath-" of humanitarian disasters, I've HOT-participated myself. So, considering the thousands of structures that burned (most of them homes), tens of thousands of acres which are burn-scarred and distinctly different than their landcover, millions of trees (yes, really) and even landuse is now currently tagged, I look for guidance — beyond the simple tag of fire=perimeter on a large polygon. Second, if we do choose to "better" map these incidents and results (they are life- and planet-altering on a grand scale) how might we choose to do that? Do we have landcover tags which could replace landuse=forest or natural=wood with something like natural=fire_scarred? (I'm making that up, but it or something like it could work). How and when might we replace these with something less severe? On the other hand, if it isn't appropriate that we map any of this, please say so. Thank you, especially any guidance offered from HOT contributors who have worked on post-fire humanitarian disasters, SteveA California (who has returned home after evacuation, relatively safe now that this fire is 100% contained) On Aug 29, 2020, at 7:20 PM, stevea wrote: > Not sure if crossposting to talk-us is correct, but it is a "home list" for > me. > > I've created a large fire perimeter in OSM from public sources, > http://www.osm.org/way/842280873 . This is a huge fire (sadly, there are > larger ones right now, too), over 130 square miles, and caused the evacuation > of every third person in my county (yes). There are hundreds, perhaps > thousands of structures, mostly residential homes, which have burned down and > the event has "completely changed" giant redwoods in and the character of > California's oldest state park (Big Basin). > > This perimeter significantly affects landuse, landcover and human patterns of > movement and activity in this part of the world for a significant time to > come. It is a "major disaster." I'm curious how HOT teams might delineate > such a thing (and I've participated in a HOT fire team, mapping barns, water > sources for helicopter dips and other human structures during a large fire > near me), I've simply made a polygon tagged fire=perimeter, a name=* tag and > a start_date. I don't expect rendering, it's meant to be an "up to right > about here" (inside the polygon is/was a burning fire, outside was no fire). > I wouldn't say it is more accurate than 20 to 50 meters on any edge, an > "across a wide street" distance to be "off" is OK with me, considering this > fire's size, but if a slight skew jiggles the whole thing into place better, > feel free to nudge. It's the tagging I'm interested in getting right, and > perhaps wondering if or even that people enter gigantic fires that will > significantly change landscape for some time into OSM, as I have done. This > will affect my local mapping, as a great much has burned. Even after > starting almost two weeks ago, as of 20 minutes ago this fire is 33% > contained, with good, steady progress. These men and women are heroes. > > To me, this is a significant polygon in my local mapping: it is a "huge > thing" that is a major feature on a map, especially right now. I firmly > b
Re: [Talk-us] place=neighborhood on subdivisions?
I'd like to clarify my take-aways from this discussion, hopefully yours, too. Thank you for reading and your patience. Brian says that a common (THE common) definition of "suburb" in the US is (roughly) "a smaller city next to or near a much larger one as part of a conurbation." I agree that is a very frequent understanding of how the word "suburb" is both used and understood in the USA, even most or almost all of the time. I also assert that there is a (much less-common, agreed) usage for "suburb" in the US that is more in line with how OSM tags with place=suburb, as a kind of "district of a larger city." Magnolia (in Seattle) is tagged place=suburb, believed correctly as to how that tag should be used, even though Magnolia is CALLED a "neighborhood" in local vernacular. It seems these two usages of "suburb" can co-exist simultaneously (OSM tagging and local vernacular) while disagreeing slightly, though with some confusion unless and until this clarification is understood. OK, we've discussed it, I hope it is less confusing. (In the USA, we tend to CALL someplace like Bellevue a "suburb," though we correctly TAG it a place=city in OSM. Such differences between "call" and "tag" are the source of much of the confusion about "suburb" and "neighborhood" or place=neighbourhood). I fully support the use of place=neighbourhood tagging on nodes or polygons in the USA where it makes sense to do so. In a previous post, I said the logic of using place=neighbourhood in Seattle makes less sense, as there is a hierarchy with using place=* (city, suburb, neighbourhood, among other values if greater granularity exists). So, with what are CALLED neighborhoods being actually TAGGED place=suburb, there is "excess room" in that hierarchy: with Seattle tagged "city" and Magnolia (and other so-called neighborhoods) tagged "suburb," tagging Magnolia (and others) with place=neighbourhood (because it is "called" that) would leave a gap between neighbourhood and city: what suburb would Magnolia be a part of? Yes, as it was said somewhere that Seattle's "neighborhoods" have specific boundaries, it could be a small OSM project to restructure Seattle from nodes-tagged-suburb to polygons-tagged-neighbourhood. That could happen, though I still ask what place=suburb tag, if any, would be appropriate to bridge the gap between neighbourhood and city. Perhaps none, and that is OK, I'm not sure if this is "allowed" with place=* tagging, maybe it is. In the example I gave in the city of Santa Cruz (Prospect Heights "neighborhood," now tagged with a relatively large landuse=residential PLUS smaller more-correct, "block-level" landuse=residential polygons), our county wiki outlines a strategy for the already-existing large landuse=residential polygons (older, less correct, "first draft") and the smaller landuse=residential polygons (newer, more correct, "corrections to first draft underway"): when all the smaller, more correct polygons are completed, the landuse=residential tag on the larger, less correct is changed to place=neighbourhood! Santa Cruz, a city of about 65,000, already has five nodes tagged place=suburb, (13,000 in a suburb seems about right, these suburb names are widely used), as well as five or so "smaller" (in identity) scattered place=locality nodes (slightly different than the suburb or neighborhood names). This all works both in how the real world names things and in OSM: the City (multipolygon) is tagged place=city, its five suburbs (in the less common sense) are nodes tagged place=suburb, the "residential neighborhoods" are NOW tagged landuse=residential, yet OSM is on track (and documents how) we're converting these to better-granularity "block-level" landuse=residential polygons inside of larger polygons, and these larger polygons will be changed from landuse=residential to place=neighbourhood when full "inner high-granularity" polygons are completed inside of the to-be-designated place=neighbourhood larger enclosing polygons. (Additionally, there are some scattered nodes tagged place=locality, what might be considered "the bottom of the hierarchy," which have accrued and stabilized according to local convention). Clear! May this clarify similar strategies for better place=* tagging in the USA. It is complicated when US English diverges from the more British (or Australian) English that strongly influences wiki definitions of tags, but with some discussion, we can both better understand these potentially confusing (but ultimately understandable) differences, and tag well, even in the USA. SteveA ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] While we're fixing things in iterations
Of course, I'm not pointing fingers or placing blame on any person / human in particular. We agree: a bit of cleaning some rust off of the toolchain. Change management. Does that happen on this channel? That's OK: no need to answer that. SteveA ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] While we're fixing things in iterations
Paul Johnson wrote: > Can we finally fix two other longstanding problems, then? > > 1. The wiki being incorrect about not counting bicycle lanes. That's not > reflective of how validators deal with lanes, how data consumers like Osmand > or Magic Earth deal with lanes, or how ground truth works. The whole "but > you can't fit a motor vehicle down it" argument is facile, that's what > access:lanes=* and width:lanes=* is for. If it truly is the wiki that needs fixing, I'm all for fixing the wiki here. Is there some reason the relatively low bar of making a change to the wiki hasn't been done yet? > 2. Tagging route information on ways. It's about a decade too long at this > point for ref=* on a way to be completely disconnected from the entity the > tag applies to: That's why route relations exist. Biggest problem child on > this at the moment: OSM's own tilesets. Let's drop rendering for ref=* on > ways and just render the route relations already, this and multipolygons are > why relations came to exist in the first place. Yes, 100% agreement. I think this is simply pure inertia (the kind that says "broken process") on the part of renderers. Can anybody (renderer authors included, maybe even especially) are welcome to offer reasons why "the old machinery" remains in place? Are there legacy use cases that remain unclear to the wider community? Please tell us here, if so. While I still find murky and mysterious exactly "how" to effect change in renderers (who you gonna call?), my two best efforts along these lines are to "tag well" and "wiki well." (And that can include a great deal of discussion and consensus building on its own, no doubt). Eventually, (and I've discovered it can take years), renderers do catch up. SteveA ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] United States Bicycle Route System ballot(s) pending AASHTO approval
On Sep 22, 2020, at 8:38 PM, Elliott Plack wrote: > Excellent! I see no problem keeping state=proposed with the lifecycle. With both of us in agreement about tag "proposed:route=bicycle" (especially as it co-exists with "state=proposed") can we gain some more consensus (here, soon?) allowing us to move closer towards recommending in our wiki that we tag proposed USBRs with "proposed:route=bicycle"? I'd love to see wider agreement that these tags together are a good way to move forward, as "state" continues the legacy rendering support by OCM and cyclosm and "proposed:route" is harmonious with tagging schemes that are more modern as they grow into sensible namespaces like Lifecycle. > Another tag in that realm that I like to use is the `start_date` or in this > case the `opening_date`. The latter is for some future date, if known, when > the route would change to regular active status. Then you can add the > start_date. I find those useful when another mapper might not see something, > either on imagery or out in the world. If they see a recent start date, it > might help explain the discrepancy. I do put start_date and end_date on objects in OSM (I just did on a fire=perimeter that covers a huge portion of my county and which burned for over five weeks). But for proposed USBRs, predicting what to use as "start_date" requires predicting when AASHTO will complete the voting on its ballot for state's USBR applications during that AASHTO "round" (twice a year), and we simply can't do that. It's easier to wait until "after the fact" (OSM receives news that the AASHTO ballot has completed and published results) and then simply remove the "state=proposed" tag: that's how we've been doing it, it's well-understood, it's quite simple / straightforward and it "works" (causing OCM to render solid route lines from initially dashed route lines), but more importantly, as accurate route data in OSM as a database. So while I agree with you it would be useful to do this, we don't have a crystal ball that allows it to predictably happen in this case. I think the "state=proposed" and "proposed:route=bicycle" tags convey enough, especially as source=* tags and/or changeset comments often denote a pending USBR being part of a particular AASHTO ballot — "AASHTO Autumn 2020 round," for example. The whole idea of these entering OSM is to have enough time to enter them (sometimes they are hundreds or even thousands of kilometers of route to enter) by the time they become approved. Sometimes we "beat the clock" and end up with some dashed lines and we wait for approval, sometimes we lag a bit and they get approved first, THEN we complete our entry of them into OSM. > Annotation geekery aside, it brings me great joy that OSM holds such a vast > repository of bicycle/pedestrian related data that are virtually unparalleled > by other commercial mapping products. Keep up the good work adding and > maintaining these networks. Very kind of you to say. There ARE other (often commercial) such "repositories" (e.g. RideWithGPS) but these tend towards the ephemeral, transitory-natured "I think this a good bike ride" GPX data, rather than "these are official or quasi-official (signed on the ground)" bicycle route data contained in OSM. Happily. the Internet has room for both. Is OSM "unparalleled" when it comes to "official" bicycle/pedestrian related data? Well, that's a great goal to shoot for, I'm delighted to receive the feedback you believe we're "getting there!" SteveA Simply "one more volunteer" doing this, there are many! ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] place=neighborhood on subdivisions?
On Sep 23, 2020, at 10:51 AM, Brian Stromberg wrote: > A short question of a lengthy response: What is the history behind that > definition of 'suburb'? Is it a result of the term being used that way in > UK/Europe/elsewhere? Seems like an odd usage, since "suburbs" have had a very > clear definition in the United States for decades now, and it has nothing to > do with neighborhoods. I believe it is UK-derived, as are many OSM "definitions" (usually / often clarified in wiki for that key). I don't know that I agree with "suburbs have had a very clear definition in the United States for decades." To wit, some would say that a "suburb" can be an incorporated city that is smaller than, but "associated with" (and maybe even sharing a partial contiguous boundary with) a larger city, of which it "is a suburb." (For example, Bellevue to Seattle, or El Cajon to San Diego). These are quite precisely defined as incorporated cities with rather exact boundaries. Some say that a "suburb" is a subset of an incorporated city, like a district of that city. (For example, Magnolia to Seattle, or Mid-City to San Diego). These are often amorphous and imprecisely defined, though there might be agreement at a rough "center" or "town square that defines the central character of this suburb," but not always. At least in the USA, I think many would nod our heads and say "yes" (both). In short, both "definitions" (or really, "understandings") of "suburb" are correct, perhaps depending on context or a given region / locality. I don't think that (at least these two, there may be more) this is a "very clear definition in the United States." The "definition" of "neighborhood" in the USA is even less clear, though it is possible to draw the beginnings of a rough box around it. We could spend some time trying to refine this, but I believe it would be difficult and possibly contentious, but it could also bear fruit for purposes of better tagging here. SteveA ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] place=neighborhood on subdivisions?
place=, and identify the smaller landuse areas (which are sometimes all > residential). Use place=* according to its wiki, and I have no problem. Please consider how there are data in OSM which do not strictly adhere to wiki, they might be considered "rough" or "technically inaccurate on a minor level" but they should not be called "absolutely wrong" at an informal, novice-level-mapper level. This really is how OSM gets built: at first, sometimes roughly (slightly wrong, but not absolutely), then these data are refined into adherence to specification. Sure, we'd love the high-granularity, absolutely correct data to enter the map "first, always and we're done," but that doesn't always happen. > Exactly. My rule of thumb is if you're thinking about putting a name on it, > and it's not a shopping center, apartment complex or similar large but > contiguous landuse, then landuse=* probably isn't what your polygon should be. At least initially, it MIGHT be. Let's acknowledge that and while we can absorb complaints about it, I won't redact such data, it being a first draft at completion (similar to TIGER roads and rail). We'll take decades to clean that up, as OSM is a long-term project. Let's acknowledge that, too: "the map is never 'done.'" SteveA Notes/References: [1] https://www.osm.org/relation/7071337 [2] https://www.osm.org/way/219988725 [3] https://www.osm.org/way/220344508 [4] https://www.osm.org/way/446025524 [5] https://www.osm.org/way/446025531 ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] place=neighborhood on subdivisions?
On Sep 22, 2020, at 7:05 PM, Clifford Snow wrote: > For example, in Seattle I lived in the Wallingford Neighborhood. Seattle has > defined boundaries for each of the neighborhoods. In other areas, > neighborhoods are roughly defined by people living there. In those cases > using a place= tag makes more sense. Clifford: One more thing. Several summers ago, I lived at / house sat at my sister's house in the Magnolia suburb of Seattle. I believe I mapped fairly well the little "village downtown" there (it was walking distance, as a nice suburb or neighborhood might be) as a hobby after I fed her cats, I'd have to check OSM data history I think summer of 2012. But you'll notice that suburbs (not Neighborhoods, as you call them) of Seattle are tagged in OSM as place=suburb. (And it wasn't simply me who has done that, I think I only did it once or twice for Magnolia and maybe Ballard). In a larger city like Seattle, this seems about right. I don't like disagreeing with a friend like you about where you have lived (and all I did was feed my sister's cat for a few weeks, and I do love Seattle) but I think the jury is in about Seattle suburbs in OSM, and they are tagged suburb. Does Wallingford or Ballard or Magnolia get called a neighborhood in local vernacular? Sure, I don't doubt it: you just did so yourself! But in OSM tagging, which is I think what we're trying to better agree upon, I think the tagging of place=suburb on these is correct. For the original poster's question, I think I've already stated my opinion, though there are certainly enough to go around! We do a lot of landuse=residential on "neighborhoods" in the USA, especially without any "council" or active administration at the sub-city level. Larger cities DO have these, admin_level=10 is correct on them. Smaller cities and rural areas that are "a cluster of homes/houses/dwellings?" I think a (multi)polygon tagged landuse=residential works well there. SteveA ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] place=neighborhood on subdivisions?
Whoops, "but NOT if it isn't something like a council" SteveA ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] place=neighborhood on subdivisions?
Clifford: I certainly agree with you if (and likely only if) there is something like a neighborhood council that actually has some sort of "administrative" function (which could be as "lowly" as dog catcher, mosquito abatement, or "sub-municipal parks department for these three neighborhood parks." These are often found in larger cities, United States/Boundaries has a small list of examples. But if it is more like "what the locals call it between 12th and Main out to the lake" (more informal, not administrative in any way), and it IS exclusively residential (not big or populated enough to contain a commercial district, though perhaps an elementary school or a crossroads where there is a transit stop) I'd say landuse=residental fits nicely. Again, if you think place=neighbourhood works, use it, but please try to be true to other values of place (like suburb) which allow neighbourhood to be used in a sensible hierarchy. I believe you are suggesting admin_level=10 to fit into a hierarchy (and sensibly, too), but if it isn't something like a council (however tiny and local) but not political, as there seems to be a sense of wards at admin_level=9 that are purely voting / electoral districts to being better tagged administrative=political. SteveA ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] place=neighborhood on subdivisions?
If you MUST tag place=neighbourhood (note the u) see if you agree with me that this tag makes most sense in a hierarchy where place=suburb (and perhaps quarter, if applicable, is/are above) also exist(s). I'm not strictly saying I believe that place=neighbourhood CANNOT exist without place=suburb, but it makes me wrinkle my brow a bit at it not fitting as well as a landuse=residential (multi)polygon might rather generically and innocently (without any hierarchy required) fit in. SteveA ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] place=neighborhood on subdivisions?
I'm harmonious with Minh's comments in the changeset. The place key, with value suburb, has quite specific meanings, I don't think these are those. And as we don't or shouldn't be truly precise and especially not authoritative with "legal subdivisions," I think the "more informal" nature of OSM data entry around what a local (resident) might consider "a neighborhood" (especially as one distinct from place=neighbourhood. which also has quite specific meanings) and not necessarily one taggable with admin_level=10 (as it hasn't any administrative neighborhood council, extant, but rare in the USA) then yes, use landuse=residential (with a name=*) tag. That has worked for some time, it does work for now, and appears it will work into the future. Read https://wiki.osm.org/wiki/Key:place (which will show this very likely shouldn't be used). Read https://wiki.osm.org/wiki/United_States_admin_level (which will show this very likely shouldn't be used). Read https://wiki.osm.org/wiki/Key:landuse. It's a good match for "these" (roughly, "subdivisions"), especially with a name tag, since a bonus is the name tag renders nicely in Carto. Carto rendering is not the reason to do it, simply a "nice to have, since it's done correctly, Carto rewards you with an appropriate rendering." Carto does a pretty good job (maybe even always getting a bit better as time goes on) of rendering what you tag, when you tag appropriately. Tag "appropriately" and help it out: it will help you out with a pretty "blossom" of your tagging. (Unless it doesn't, but then we're out at the hairy edge of OSM and Carto...another, bigger, topic). SteveA ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] United States Bicycle Route System ballot(s) pending AASHTO approval
I have added a one-line addition to our USBRS wiki suggesting that some aspect of Lifecycle_prefix (with a link to that wiki) include into USBRS route proposals something like "proposed:route=bicycle" in addition to state=proposed, while welcoming further suggestions and refinements. Thanks, again, Elliott, for a great suggestion. SteveA ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] United States Bicycle Route System ballot(s) pending AASHTO approval
On Sep 22, 2020, at 12:33 PM, Elliott Plack wrote: > Great work getting these into the map already Steve! I work on the MDOT bike > team (as a GIS consultant) so it is great to see this on the map so quickly. Thank you, Elliott; nice to see your reply! I agree about "so quickly:" I posted a request here and just a couple/few days later, an intrepid OSM volunteer had finished USBR 201 in Maryland before I could brew a cup of coffee! Then, when it was suggested that the route become fully bi-directional, he quickly refined it to be so (just yesterday). Wow! (OSM has some great mappers!) > A note about the *proposed* routes, they do appear in the OSM Cyclemap > already [1]. > [1] = > https://www.openstreetmap.org/?mlat=39.5798=-76.6054#map=15/39.5798/-76.6054=C I believe what is going on here is that East Coast Greenway (ECG, a "quasi-national" bicycle route not part of the USBRS, but sometimes, like here, sharing segments with it as USBR 201) is that OpenCycleMap (OCM) is in the process of redrawing the combined / shared segments of ECG + USBR 201 (in Maryland). OCM can (and often does) take several days or even a week or two to re-render. And, Andy Allan (OCM's author/maintainer) recently upgraded OCM to vector tiles with some newer rules for how specific tags (including and especially routes tagged state=proposed) are differently-rendered than as before (before vector tiles). If I'm mistaken and somebody wants to correct me here, I welcome that, as I'm speculating a bit at what/how OCM is "currently rendering." It's a bit like watching paint dry: the colors can change a bit as it does. > Instead of using the `state=proposed` tagging [2], you might consider putting > a lifecycle prefix [3] on the network tag so as to prevent data users from > integrating it blindly. > [2] = > https://www.openstreetmap.org/relation/11654314#map=11/39.5964/-76.2022=C > [3] = https://wiki.openstreetmap.org/wiki/Lifecycle_prefix The usage of state=proposed on bicycle routes is long (in my experience, going back to about 2010) and somewhat complex history, I've exchanged quite a bit (though not TOO frequent!) emails with Andy on this, he has been most helpful, especially with the switch to vector tiles earlier this year. It is also quite deliberate, as state=proposed DOES render (in OCM as dashed, not solid) but does NOT render in Lonvia's waymarkedtrails bicycle renderer, providing a contrast between seeing the routes as proposed (and dashed) or not as all, as they are "not quite yet approved nor signed (yet)." This contrast is documented in our USBRS wiki. Additionally, a newer bicycle renderer (cyclosm) has emerged which also renders state=proposed. I very much like the idea of Lifecycle_prefix in addition to state=proposed (I don't think it must be a choice between one and the other). Using both tags (state and a lifecycle prefix) somewhat "standardizes" the concept of "proposed" in a wider OSM context, while continuing use of state=proposed (as it is supported in OCM), allowing the "dashing" of routes so tagged to continue in those renderers where the tag is applied and is supported. We (OSM, ACA, a sponsor of USBRS, even AASHTO itself) have all participated in rather carefully crafting and or supporting this process and set of tags, which emerged in 2013. I gave a talk at SOTM-US / Washington, DC about this in April, 2014 and we've been using this carefully-hammered-out consensus since. Your suggestion to consider Lifecycle_prefix in addition is both welcome and excellent, imo. Thank you. If anybody wishes to contribute a suggested strategy to include Lifecycle_prefix tagging in our USBRS wiki, I welcome that and also consider doing so myself. What a great project (OSM) we have here, SteveA ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] United States Bicycle Route System ballot(s) pending AASHTO approval
Minor correction to my previous post: USBR 1 in Washington DC is a new route, not a realignment. SteveA ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] United States Bicycle Route System ballot(s) pending AASHTO approval
There are at least four new national bicycle routes "pending" in the USBRS! (Ballots by state Departments of Transportation before AASHTO's Autumn 2020 round): USBR 11 in West Virginia (done in OSM), USBR 30 in North Dakota (done in OSM), USBR 50 in Washington, District of Columbia (a realignment only, done in OSM) and USBR 201 in Maryland. To help OSM "get ahead of the curve" of the Autumn 2020 AASHTO ballot, the USBR 201 application by Maryland DOT is available, allowing OSM to enter these state-at-a-time national bicycle route data. This route has been "seeded" as a route relation and still needs to be fully entered into OSM. Please visit our wiki https://wiki.osm.org/wiki/United_States_Bicycle_Route_System#Proposed_USBRs_in_OSM for a link to the route data ballot for USBR 201 in Maryland. OSM-US has explicit permission from AASHTO to enter these data from these ballots. Thank you for helping to build Earth's largest official cycling route network: check out our wiki, follow the links to the turn-by-turn and map data and have fun making bicycle route data in OSM more complete and better! SteveA California One of many USBRS-in-OSM folks (among other hats I wear) ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] Unintentional improvements in OSM data influencing / improving other databases
On September 1, 2020 at 8:07:46 AM PDT, Kevin Kenny wrote: > > In many of these cases OSM has an opportunity to improve the government data. > A mapper can analyze the conflict, sort out the different data sources, > perhaps visit the site in the field, and produce a result that is more > accurate than any of the government data sets. It's been pretty quiet, but I > know that there some corrections from OSM have flowed back into some of the > government data sets that I use. Starting a new thread. I echo this sentiment exactly as having taken place in California and in my experiences with OSM. This is most certainly a longer-term endeavor (over several, even many years), but improvements in alignments between data components which have been entered into OSM from my County GIS, GreenInfo.org's publishing its "CPAD" (California Protected Area Database, published semi-annually, see our wiki) and other sources HAVE INDEED resulted in data improvements: OSM influences CPAD, resulting in data improvements, CPAD influenced County GIS data, resulting in data improvements, later versions of these (County GIS and CPAD) data influenced OSM all over again, resulting in data improvements...and upward, upward and upward the spiral of more accurate, better-aligning data goes: both private and public. OSM gets the results, so do others. Win-win. Taking OSM out of the equation by asserting "these data don't belong in OSM" stops this improvement pipeline (wholly unintentional on my part, but certainly noticed) in its tracks. (Yes, some data belong in OSM, some don't). This is a seldom-talked about real benefit OSM offers to both non-profit based data aggregators (like GreenInfo and their CPAD) and public ones (like County GIS departments). Yes, a relatively high-degree of accuracy and careful mapping, skilled volunteers in OSM (who likely don't have the credentials of professional surveyors, but who are aware of basics like monument markers, "metes and bounds" in deeds and the like) ARE required. So, even volunteer "citizen mappers" can go a long distance at improving data, simply by doing solid mapping in OSM. And by remaining a database of high quality and careful curation, OSM earns the respect of other GIS professionals (public and private) who (over the longer-term) find the puzzle-pieces fitting together better. The examples are numerous, thank you Kevin for providing several. OSM will likely never become "authoritative" in the sense a cadastral database does for tax or land survey purposes, but as we keep our quality high, keep our mapping careful and pay attention to things like survey markers (we do), other mapping professionals will continue to look to us as "worthy enough" to include as a layer on their systems, for example. OSM does not have the goal of being so "authoritative," nor should it in my opinion, but speaking personally, I do strive to map as accurately as I possibly can. Our data being widely and deeply respected is a great result OSM can be proud to continue. I can't count the number of times I've (more recently) heard from Land Trust mapping professionals, local public GIS professionals, non-profit GIS professionals and more "OSM is a fantastic and amazing resource, there is nothing else like it and the world of mapping is a far richer place because it exists." (Or something very much like that). Bottom line: please don't scoff at the possibility that your careful and accurate mapping might influence "official" or "authoritative" GIS data. It can, it has, it does and it will continue to do so. SteveA ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Trouble with getting Superior National Forest boundary to render on standard map
On Sep 1, 2020, at 2:46 PM, Kevin Kenny wrote: > 'Private' vs 'public' hits near the mark, but not in the gold. I was trying > to be precise when I said that the property line determines the protected > status and the public access constraints. A public-access nature reserve > operated by an NGO (such as a private conservancy or land trust - there are > quite a few in my part of the world) deserves the same treatment as a > government-run one. Thank you for pointing out this distinction, Kevin. It certainly exists, such as in abundance in New York state where you have mapped these distinctions extensively. As I was talking about the specific case of National Forests (and their odd "dual boundary" nature), I did not mean to exclude other (e.g. NGO) kinds of ownership in the greater realm of mapping. However, in the distinct case of National Forests, the distinction between public and private (for "smaller, actually owned" polygon components vs. "larger, potentially own-able without additional Congressional legislation" polygon components) remains true. So while I do not "hit the gold" in all cases, but I think the public-private distinction (along with the pesky "Congress has authorized further acquisitions out to HERE" outer-outer polygon) accurately captures what we're trying to better understand, better map and better render in the case of National Forests, I happy accept your "adjustment or correction." Nicely, I believe we are both correct! SteveA ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Trouble with getting Superior National Forest boundary to render on standard map
Here I weigh-in with what I believe to be a crucial distinction between "cadastral data which are privately owned" and "data which can be characterized as cadastral, but which are publicly owned and are often used for recreation, hiking and similar human activities." Joseph, many others in OSM, I and wide consensus agree that the former (private cadastral data, especially down to the level of individual parcels) generally do not belong in OSM. I believe we also agree there are widely-acknowledged exceptions to this, such as when polygons tagged landuse=* denote where a farm is distinct from a forested area, or where residential vs. commercial vs. industrial areas clearly follow property lines up to an edge of "difference," especially as they better characterize what we might call "zoning" (of larger areas like "neighborhoods" or "downtown's shopping district" or "the industrial zone where auto parts are manufactured by numerous industrial companies on numerous parcels") instead of individual parcels. If I am incorrect in any of my assumptions, I welcome adjustment or correction. However, with PUBLIC "cadastral data" which define national parks, large areas used for human recreation (such as state parks, county parks, national forests and similar public lands), I don't think there is any argument whatsoever that OSM wishes to map these. Yet what Joseph characterizes as "cadastral data" precisely define these. Please, let's dispense with this apparent (but not actual) contradiction: public lands belong in OSM denoted as such, and an acknowledged best method to do this is to map their boundary as the data where they are "owned by the public." What we discuss here is the particular (peculiar?) example of national forests in the USA, where there are effectively "two legal boundaries, one actual ownership, another potential ownership." We absolutely should agree (here? now?) on which of these two (or both) we enter into OSM. The current situation of data in our map is scattered between the two and still confused in the minds of many mappers who do or wish to enter these data. Since we agree they should be entered, let's better discuss how we enter them "properly" (by achieving consensus) and watch as they render according to our hammered-out-here agreements on how this should and will best take place. We really are getting closer to doing this, thanks to excellent discussion here. SteveA ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Trouble with getting Superior National Forest boundary to render on standard map
Kevin Kenny wrote: > They're both 'legal' boundaries. (and more). Thank you, Kevin. Finally, this is written in a manner that allows me to understand it and I do now. Whew! THEN, there is how OSM might ultimately remedy this (by specifying — good example wiki diagrams can go miles here — mapping the "simple outer" with an "outer" role?) and how Carto (and its authors) remedy this as it renders. These remain to be seen. It's messy, but we do get closer talking about it here. It appears there are some forests which denote "legislative outer" with "outer" role and other forests which denote an outer role of land which is ACTUALLY federally owned (a smaller area, contained wholly inside of the first kind, the could-be-national-forest-without-more-legislation kind). OSM must specify correct / preferred tagging if we keep both kinds of multipolygons (MPs) in our data (I prefer the latter, as the tags in the polygon "do apply"). We may also coin a new flavor of MP (it would still BE a MP, but perhaps with special tagging, special rendering, or both) for such national forests in the USA to better characterize the "dual nature" of this odd "sort of" ownership: an "outer-outer" of "legislative possibility of ownership." But maybe that's not required: a wiki page describing this and the tagging required on one or two MPs could do it, I think. In my mind, now that these are quite distinct, it seems a straightforward solution is two MPs, maybe linked somehow (one a super-relation containing the other?). The first MP might be the (larger) "legislatively-defined outer-role possibly-owned 'limit without additional legislation.'" The second MP might be the (smaller) "actually owned, tagged outer-role, plus punched-out inner-role inholdings." Those quoted descriptions can be sharpened up, but I hope the idea is clear. Then, maybe some logic is built into Carto (maybe not, it may not be necessary). Then, we document this well in wiki (explaining as Kevin did, as I understand now clear-as-crystal, I believe others will, too). Then, we discuss whether there might be a harmonization of data across the country. Then (as usual, the final act, please pass the popcorn), we watch our hard work render. And applaud. With Kevin and Joseph talking, this feels like it can get solved! Thanks for putting on thinking caps and typing words carefully, SteveA ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Opinions on Devil's Slide Bunker (San Mateo, CA)
(as in this case) come from a single definitive source or wiki entry, though wiki guidance about using good judgement USING subjective criteria can help. I don't see as a major problem in OSM "we have too many viewpoints around here because of low-bar subjectivity!" Sure, that COULD happen, but it's too much of a "what if" to seriously consider restricting viewpoint addition with strict criteria (like it must be signed, benched or on another map). OSM tends to "self-heal" if it runs away with itself like this. (Strong local volunteers who mentor and grow novice users and establish wide consensus greatly helps, too). Too long, stopping here, SteveA ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Opinions on Devil's Slide Bunker (San Mateo, CA)
On Aug 30, 2020, at 5:50 PM, Brian Stromberg wrote: > I would argue that maps can only show the world as the mapmaker wants it to > be shown, and OSM should probably not be encouraging people (in any way) to > be visiting sites that are clearly marked as illegal to visit. This seems > like a bad precedent to set. I would include the bunker but not mark it as > tourism. People will find it if they want to, whatever OSM tags it as, so it > doesn't seem necessary to participate/encourage in whatever degree of > illegality the access entails. And here is where some disagree: OSM does not "encourage." OSM is data. It simply says "this is" and "these are." OSM does not encourage people (in any way) to visit a site or trespass. It is a collection of data (of "what is") expressed as a map. Full stop. Sometimes, "sites" or "roads" are marked as "private" or "permissive" or "no access." What people do from there did not happen because I, you, she, he, they or ANYBODY entered data into a map. Period. If a sign says "No Trespassing" yet it is ignored, who is responsible? A map? No, the trespasser. (And yes, to the greatest extent possible, OSM wants to not only tag such data where known, but express these access restrictions in renderings, as well. OSM has been doing this for years, quite well in my opinion). I don't believe OSM "sets precedents" as Brian describes, as OSM doesn't "encourage." Two facts: 1), tourists DO visit this site and 2), OSM uses the tourism key to denote viewpoints (and the view IS spectacular). I have no problem with "tourism=viewpoint" here, though apparently Brian disagrees. OK. I'm glad the thread includes the word "Opinions!" (Thank you, Frederik). I don't mean to sound argumentative or antagonistic, but if someone more clearly draws a line between "entered map data" and "encouraged people (in any way) to do anything illegal," I'd like to follow that line. However, nobody has been able to do that (yet). I believe "the correct" access tagging (on the path, for example) will go a long distance here. Both access=no and access=private mean the same thing to me as a "No Trespassing" sign when I see them rendered in Carto, for example. Some final notes in the realm of "legal" (I am not an attorney): there is something in California called Civil Code 1008 which expresses a method to legally prevent easements from being created on private property. One can create an easement by simply "using" (traversing, for example) said private property in a notorious manner for some number of years. To prevent this, the owner must post a sign reading "Right to pass by permission and subject to control of owner: Civil Code Section 1008." However, that's not what the sign says (which Frederik posted and I have seen personally). Speculating, I'd guess this sign was placed there by local search and rescue personnel (might be fire / paramedics) who don't wish to be burdened with rescues (or worse) at the same place for the same reason — and the local ordinance cited (San Mateo County Ordinance No. 1462) makes that actual law. With all this, I believe access=no is a correct tag (on the path, would be my first inclination). SteveA ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] Opinions on Devil's Slide Bunker (San Mateo, CA)
Joseph asks good, relevant questions regarding whether the access tag should be private vs. no. But, yes, I agree Frederik, there absolutely should be one of these two tags with that sign you displayed. (I've seen it many times driving past here before the tunnel was built, it's a bit more out-of-the-way now). And if it was historically a bunker, OSM should strive to tag this, I'm not exactly sure of the right mix of military=bunker and historic=yes flavors that might be absolutely correct, but something like those if not exactly those. Though historic=ruins seems correct, too, so perhaps better than "yes." I slightly disagree with Frederik about a viewpoint necessarily being signposted or "called a viewpoint." I've tagged tourism=viewpoint on many such places, where they are absolutely a viewpoint in my opinion (and I've hiked a LOT) but are neither so noted via signpost on site, nor on a map. Many that I have so entered into OSM have a bench nearby (and so I'll tag amenity=bench on a node, too) so I'm not the only one who thinks the spot has a nice view worthy of a short sit and "take it all in." I mean, hiking trails and viewpoints go together like peas and carrots, otherwise, what's the point? (Exercise, sure — but, but the VIEWS!) What I'm saying is that I believe it's OK for an OSM mapper who enters a tourism=viewpoint tag to say "I'm asserting this to be a bona fide viewpoint here." Of course, if it is signed, benched or otherwise mapped or widely acknowledged as a viewpoint, all the better. I tire of self-declared "concerned citizens" who think they should tell us mappers what is in the world and how to tag it. What must be immediately dispensed with is that "maps make people do things." (Hike closed trails, trespass...) Nonsense: maps show the world as it is (to the extent they can). PEOPLE do things with maps. When you start there, all the right things to do follow. Let's get an access tag here, tune up "historic" and let the renderers do their magic. (As usual, but it's a good question, thank you for that familiar sign and I'm glad there is such lively participation in suggestions). SteveA ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] Large fire perimeter tagging?
Not sure if crossposting to talk-us is correct, but it is a "home list" for me. I've created a large fire perimeter in OSM from public sources, http://www.osm.org/way/842280873 . This is a huge fire (sadly, there are larger ones right now, too), over 130 square miles, and caused the evacuation of every third person in my county (yes). There are hundreds, perhaps thousands of structures, mostly residential homes, which have burned down and the event has "completely changed" giant redwoods in and the character of California's oldest state park (Big Basin). This perimeter significantly affects landuse, landcover and human patterns of movement and activity in this part of the world for a significant time to come. It is a "major disaster." I'm curious how HOT teams might delineate such a thing (and I've participated in a HOT fire team, mapping barns, water sources for helicopter dips and other human structures during a large fire near me), I've simply made a polygon tagged fire=perimeter, a name=* tag and a start_date. I don't expect rendering, it's meant to be an "up to right about here" (inside the polygon is/was a burning fire, outside was no fire). I wouldn't say it is more accurate than 20 to 50 meters on any edge, an "across a wide street" distance to be "off" is OK with me, considering this fire's size, but if a slight skew jiggles the whole thing into place better, feel free to nudge. It's the tagging I'm interested in getting right, and perhaps wondering if or even that people enter gigantic fires that will significantly change landscape for some time into OSM, as I have done. This will affect my local mapping, as a great much has burned. Even after starting almost two weeks ago, as of 20 minutes ago this fire is 33% contained, with good, steady progress. These men and women are heroes. To me, this is a significant polygon in my local mapping: it is a "huge thing" that is a major feature on a map, especially right now. I firmly believe it belongs in OSM for many reasons and want it tagged "correctly." Yes, there are other maps that show this, I believe OSM should have these data, too, as this perimeter will affect much (in the real world) and much newer, updated mapping in OSM going forward. Thank you for your suggestions, SteveA California (safer now thanks to truly heroic efforts by firefighters, law enforcement and many others) ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] [OSM-talk] VANDALISM !
I largely agree, but I have found there are times and places where explicitly saying "this particular wiki here is being PREscriptive (should be done), rather than the usual tone of DEscriptive (as done now)" can be a value-add to both our map and our wiki (in the long run). When done well and right, this practice can encourage a messy state in the map into a more orderly one, with the wiki aiding in displaying progress, "how far along" this is. When this "task" (or "project" as it is a good chunk of work) is done, the wiki can describe itself as descriptive (like most are) and it fully self-documents. This really works, but such "macro states" are best declared quite explicitly, so that people know how a particular wiki is being used. (The vast majority are indeed "how things are actually mapped.") It starts with a goal, a prescriptive description of "how things should be" is asserted, then we build it. Finally (sort of), around the time it's "done" (or it gets close, as some things are never "done") we say "this is how it is." This practice is not THAT unusual, even if some wiki pages are explicit about it and others are less so or not. A subset of these are something we used to call "WikiProjects" but somehow that moniker seems to have dissolved. SteveA > On Aug 21, 2020, at 6:38 PM, Paul Johnson wrote: > I feel like now is a good time to remind folks that the wiki should be > descriptive of how things are actually mapped, not strictly proscriptive. ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Potential Mechanical Edit to remove access=private from Amazon Logistics driveways in NH
> This makes sense; however, on the other hand, I can't think of a > situation where someone grants blanket access to the public to drive on > their home's driveway whenever they want, so access=private seems like > it would be correct for 99% of cases. > > However, I do agree that because of this custom, it makes sense instead > just to leave it highway=service + service=driveway, and leave off the > access tag for these kinds of automated bulk additions. > > Thanks for your input! > -- > Skyler Something for a representative of Amazon Logistics (who can influence tagging among Amazon delivery vehicle drivers who also add tags to the map) to consider: what do you think of as the semantics of OSM's access=destination tag (it is defined in our wiki) and perhaps adding it to driveways you visit? Just a thought, but it would be good for a super-participant who feels comfortable speaking from experience and not afraid to perhaps assert some authority for "how the company would like to tag and see tagging." What does this tag mean now? What might Amazon and OSM users worldwide think it means as its use is more sharply defined through a certain kind of use, because we talked about it some more here. That's a good conversation we might have here. Or on the tagging list. Let's talk about it; we're here on talk and doing so and it's not crystal clear and does seem to blend into access=destination. SteveA ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Potential Mechanical Edit to remove access=private from Amazon Logistics driveways in NH
Kevin Broderick wrote: > > If I understand correctly, all driveways added by Amazon Logistics (before a > certain point in time) have access=private, regardless of the situation on > the ground. If that is the case, I'd strongly advocate removing that tagging; > access=destination *may* be correct, but since we don't know that (i.e. there > are probably some number of driveways included that *are* access=private), > it's better to remove the tagging and let the map data reflect that > uncertainty rather than provide a guess based only on the regional norm for > driveway access (which, IMO, is already implied by service=driveway) Thank you Kevin: when you word it like that, I fully agree with you — this is a very workable solution. SteveA ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Potential Mechanical Edit to remove access=private from Amazon Logistics driveways in NH
There are many opinions about driveway access tags in OSM, some (conflicting ones) even expressed here, if briefly. Plus, such semantics can be slippery and blur among regions. I believe it correct that access=private tag be removed from highway=service + service=driveway, as "private" seems too strict to accurately describe a driveway (that's part subjunctive mood where it needs doing, part indicative where true now). This is especially correct when entered or deleted by a company performing delivery services — access=destination seems much more precise, and directly in that exact circumstance. I only tag access=private when there is a sign explicitly prohibiting access, a gate which enforces this, or both. (And "I believe it correct..." is, after all, simply one person's opinion, it is important to remind). There is an "implied semantic" (in my mind and I believe many others') of how private property and driveways "work" in USA law and custom: "If tagged highway=service + service=driveway, this MEANS it is on private property. If you are invited by having delivery requested or are visiting the residence (by invitation) or business (because they are open) so attached to the road network, you may traverse. Otherwise, it should be respected as private property, access=private is superfluous and too strict." In short, I'm agreeing with Tod that an access=* tag isn't explicitly needed, but if one is added, access=destination seems most accurate and seems distinctly more correct than access=private. I would ask Alex to consider the slight modification to his proposal that he tag driveways with access=destination, but I don't consider doing so a hard-and-fast requirement for me to agree (again, simply one person's opinion). It would be good for both the OSM community and Amazon Logistics to reach a firm consensus on this, as AL will continue adding these (it's good for them, it's good for our map). That AL has agreed to NOT add access=private is a step in the right direction. Whether this consensus includes whether access=destination is correct or not awaits more agreement in our community first, then Amazon can hew to OSM's preferences. Consensus may differ in different parts of the world, as Rory (for example) has a better grasp on how driveways are thought of (and used, and most-ideally tagged in OSM) in the UK, and USA-ans (weird word, I know) I believe are pretty close to (if not 100% in line with) how I describe it above. So, no access=private on driveways (unless gated or explicitly signed as such), that's clear. As for access=destination? Requires some more discussion and consensus and may vary by region to conform with law and/or custom. We'll get there. SteveA California ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] [OSM-talk] Tag:railway=stop
Please click on the "View History" link of the wiki page (upper right) to see the contributors to this wiki (there are ten). You can click on their username links to contact them. SteveA > On Aug 2, 2020, at 8:25 AM, 80hnhtv4agou--- via talk > wrote: > Did someone on this List, contribute to this Wiki.? > https://wiki.openstreetmap.org/wiki/Tag:railway%3Dstop ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Clear Creek County in Colorado has a broken county boundary
Taylor Smock wrote: > https://data.colorado.gov/Transportation/Counties-in-Colorado/67vn-ijga The > `About` tab /claims/ that the data is Public Domain, but > I would double check, just in case. (Some people I've talked to in county > governments thought public domain meant the data was > available for the public, /not/ that the copyright status was public domain, > so I've learned to double check). Thank you for that link, Taylor. While I am not an attorney, I am confident enough that when a state government adds metadata of "License: Public Domain" I can discern these data are ODbL-compatible. So I essentially re-drew OSM's previously-broken (significant chunks missing) polygon for Clear Creek County based on these data (and using the missing segment whole and unchanged). This also required some massage of the data for part of the boundary shared with Gilpin County. I attributed the link above in the changeset's source comment. Especially in the area of James Peak (node/358916927), there are a number of boundaries here (James Peak Wilderness Area, James Peak Protection Area, Grand County, Continental Divide) which remain quite messy, with significant errors that look to be around 20 to 30 meters. Indeed, the Continental Divide itself (way/385331055) is tagged FIXME=improve precision. While I don't often publicly complain about OSM's data, thanks to this dataset submission to talk-us, I have noticed that a fair amount of county boundary data in Colorado, while extant in OSM, have serious drift and accuracy errors — hundreds of meters or even kilometers. As there exist ODbL-compatible data which are clearly superior to OSM's current dataset, I recommend a dedicated editor (or team) properly import these, conflating with existing data where necessary (there appear to be many shared ways for edges of forest and wilderness boundaries). This necessarily will be careful work, but OSM will be much better for it. I don't know how extensive these sorts of data errors are in other states. I stumbled down this rabbit hole while using http://layers.openstreetmap.fr/?zoom=5=40.2=-97.5=0B000FFFTFTTTFF to quality-check county-boundary tagging. There are still some oddities (several counties in California plus a score or so sprinkled around the lower 48) where I still do not quite understand why they remain in apparent error, despite my "healing" some previously-broken boundaries. It could be I don't fully understand this renderer's tiling schedule. But while this rendering has improved some of those broken counties due to my improvements, some of them stubbornly refuse to better render, despite seeming correct (and correctly-tagged) polygons. Hm. I'm "slowly watching" this (county boundaries which appear to have decayed to brokenness, then repairing them), but I wanted to both share my activities more widely with the US OSM community, as well as thank Taylor for his quick reply to my request for state-issued county boundary data: I appreciate the pointer. SteveA California ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Coconino National Forest boundary isn't rendering anymore?
To my reply of: >> Coconino's boundary IS rendering, but with more accurate tags, and >> differently than a national_park Joseph Eisenberg wrote: > That's incorrect. It's not rendering at all on the highest zoom levels, which > have been refreshed most recently. > > boundary=national_park and boundary=protected_area are rendered identically > in the relevant map style: > https://github.com/gravitystorm/openstreetmap-carto/blob/master/style/admin.mss#L496 I appreciate the clarification, and now better understand that there is an issue with a particular multipolygon not rendering in Carto. I also now understand that these are intended to render identically from two different sets of tags, one set that was previously applied to this multipolygon, one set that is presently applied to this multipolygon. I also apologize for my misunderstanding. As the issue seems to be "at the highest zoom levels" (where I assume it wasn't before), I defer to the authors of the renderer code to determine what the root cause may be. SteveA ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] Clear Creek County in Colorado has a broken county boundary
If any Colorado or Rocky Mountain area mappers know where data may be acquired to fix some missing segments in the boundary of Clear Creek County (relation/442310), I ask that they either be pointed to or that those data please be repaired. SteveA ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Coconino National Forest boundary isn't rendering anymore?
On Jul 16, 2020, at 10:13 AM, Joseph Eisenberg wrote: > It's not the tagging. Other relations with boundary=protected_area + > protect_class=6 are rendering fine in the OpenStreetMap Carto style. The code > is here: > https://github.com/gravitystorm/openstreetmap-carto/blob/5724017f5b549ba954d9d645c0b2383dd16237d1/project.mml#L1132-L1149 > - boundary=protected_area + protect_class=6 is enough. To repeat myself, I believe Joseph and I agree / are saying largely the same thing here: there isn't anything to "fix," as boundary=protected_area + protect_class=6 renders fine in Carto, and that is how Coconino is now (more correctly) tagged. Given the recent history of this multipolygon's tags being changed from national_park to protected_area (both of which render, but slightly differently), if original poster Paul wants to add clarity to why he believes this "isn't rendering anymore" I welcome what he might add or additionally ask. However, I believe the relevant issues to be addressed have been. The answer is "Coconino's boundary IS rendering, but with more accurate tags, and differently than a national_park, which is how it was previously though incorrectly tagged." SteveA ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Coconino National Forest boundary isn't rendering anymore?
Paul White wrote: > Does anybody know why the Coconino National Forest doesn't render on osm.org > anymore? I don't see any recent changes that would've messed anything up but > it's gone. I also noticed that the Klamath National Forest is gone, as well. I'm glad to see august and more-technical members of OSM (Paul Norman, Joseph Eisenberg...) chiming into this thread. I am the most recent author of this relation. I made minor changes to the tags on the relations, not the members or their roles. Specifically, the edit History (click View History link at bottom of object "pane") displays the previous set of tags (and seems to have rendered to the o.p.'s liking), which included: boundary=national_park + boundary:type=protected_area while the present tags exclude those, but include: boundary=protected_area + protect_class=6 I did this because boundary=national_park is not a valid tag on a USFS National Forest per our evolving wiki https://wiki.osm.org/wiki/United_States/Public_lands , which prescriptively suggests this tagging. I believe it is safe to assume that the previous tagging of boundary=national_park was incorrectly applied because it rendered, and that the somewhat clumsy and collides-with tag boundary:type=protected_area was added to be more consistent with the newer tagging scheme of protected_area, though it excluded the associates-with tag of protect_class=6 which my newer tagging added, along with the "proper" key of boundary, not boundary:type. If you followed all that, thank you. The particular combination of boundary=protected_area + protect_class=6 does render (as a thin green line and an occasional name=* value along edges). And again, boundary=national_park renders, though differently than boundary=protected_area + protect_class=6 — and rightly so, as these ARE different entries: a national park is not a national forest and vice versa. > If anyone knows how to fix this, let me know. I believe there isn't anything to "fix" here: what appears to have happened is that a wrong-tagging which rendered with a certain appearance was corrected to be "more properly" tagged, and this renders, but differently. As these are issues which may continue to be evolving (relatively newer tagging schemes like protected_area compared to national_park, as well as rendering support, or lack thereof, for various values of protect_class), it is possible I lack full clarity into either the present exception of or intended effects of these tags and the Carto renderer. Here, I only offer my best explanation of present tagging and rendering effects, not future ones. SteveA ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Finding Changesets to Correct or Revert (Clifford Snow)
On Wed, Jul 8, 2020 at 11:56 AM Doug Peterson wrote: > It's my fault for not zooming in more. I did not see it at all when I > downloaded that area in JOSM. I sent a note to tyndale about that. I > understand that there is a direction towards using boundary to replace state > and county use of leisure=park. I have seen plenty of expections to those > description, meaning state and county parks that are urban manicured parks. > However, it is not an argument I'm going to pick. I would just like to be > sure the parks don't disappear in the process, like this one. It has distinctly emerged over the last year or two that leisure=park on such "larger" parks (county parks and especially state parks) is incorrect tagging. Some have substituted leisure=nature_reserve, but these semantics may or may not logically map very well in the eye of the contributor. However, this renders, so go figure. Our "slowly emerging" wiki https://wiki.osm.org/wiki/United_States/Public_lands suggests the following: It is important to note that boundary=national_park is also tagged on state parks, states being as sovereign as the federal government for purposes of declaring a park a park. So, for a "State Park," Tag boundaries: • boundary=national_park or boundary=protected_area with protect_class=2 • protection_title=State Park • name=Name of the State Park • ownership=state • operator=Name of the state Department of Parks & Recreation (as appropriate) • protected=perpetuity It may be that this tagging does not render to your liking, or as Doug may have noticed "the park disappears." I suggest bringing that up with the author(s) of your chosen renderer. This is a difficult and contentious (less so, but still) topic in OSM in the USA, so tag your best, map your best. OSM can keep kicking this can down the road, but eventually will need to harmonize parks / public lands tagging with better rendering. SteveA ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Streaming JOSM -- suggestions?
I think we're saying the same thing: I use OT to curate datasets and sometimes I'll specifically clean up their TIGER data, like when that is exactly what I curate in my query. Other times, I'll fix TIGER data otherwise. I'm deliberate in all cases and I believe all good OSM editors are deliberate, too. (Those who find themselves faced with TIGER data, as some of us are). As long as "OT query results" don't ridiculously get out-of-control turning into automated edits, we're good. I don't think that happens (often), but if you wanted to make it a short distance between those two, you could. Even if your intentions are nefarious, which they are not and is what I mean by "all good OSM editors." So, yeah, lots of sharp edges that might cut, there. I don't mean to hurt anybody by suggesting that they tend towards that, not my intentions at all. Let's all be careful growing these wonderful map data. They are wonderful, often beautiful. SteveA ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Streaming JOSM -- suggestions?
On Jul 7, 2020, at 5:17 PM, Tod Fitch wrote: > Please accept my apology for implying using the search for an automated edit. > > I assumed the same type of work flow I am doing now: Using the results of the > query to direct my attention to what I want to fix. Still need to examine the > location and available information to decide, on an object by object basis, > if the data in OSM meets your standards or needs further improvement before > doing something like removing the tiger:reviewed tag. Sure, I don't think an apology is necessary, as we're all adults here (I think!) and take responsibility for our actions. Sometimes, we are not aware that our actions are like pulling a machine gun trigger or tipping over an entire bucket of paint: relatively minor actions on our part but which have a profound effect on the map's data. Be aware, the map will be fine. SteveA ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Streaming JOSM -- suggestions?
On Jul 7, 2020, at 5:03 PM, Tod Fitch wrote:
> One thing that I only recently figured out: You can include a search for your
> OSM user ID in the Overpass query. That might help to find roads you’ve
> edited in the past so you can remove the tiger:reviewed tag.
>
> I am using that to find all those highway=stop I mapped back when the Wiki
> said that the render/consumer could figure out which direction is was for
> based on distance to the nearest intersection. Since that time tagging
> practice has changed and a “direction=forward | backward” tag is now supposed
> to be on nodes tagged with “highway=stop | yield”.
>
> Since Osmose is nagging me, I thought I should go back and clean up the
> several thousand instances. About 2/3rds of the way done on that task. The
> Overpass search I currently use is:
>
>> [out:xml][timeout:25];
>> (
>> node(user:"n76")["direction"!~".*"]["highway"="stop"]({{bbox}});
>> node(user:"n76")["direction"!~".*"]["highway"="give_way"]({{bbox}});
>> );
>> out meta;
>> >;
>> out meta qt;
>
> p.s. Thanks Steve! I was not aware I could use a geocode area like California
> for my Overpass search boundary. That will come is handy!
You are welcome. And it is amazing how OT can combine queries into dizzyingly
complex stacks of very specific subsets of OSM's data. However, I would
caution what has a whiff of "automated edit" here: having an OT query — even
when it is all your editing — to be an all-encompassing assumption that "what
you edited before is absolutely correct...because YOU did!" might be too strong
of an assumption. So, please be careful.
My point is that every time I remove the tiger_reviewed=no tag, it is during an
edit session where I was quite deliberately doing specifically-TIGER aware
editing and correction. Assuming that a bunch of edits you have done before
actually WERE improving TIGER data "so good" (maybe so, maybe not) that you
might also (retrospectively) remove the tiger_reviewed=no tag might be
specious. It might not be specious, true, so OK, go ahead and remove the "no"
tag, but don't do so in a batch. I'd recommend a re-review of those data
before you remove "no" tags. Individually during a review that might go pretty
quickly, but not all at once with an assumption that sounds a lot like a lark
or a wish. Be careful!
Cautious sometimes (including here), rather than bold (but bold on occasion),
SteveA
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Streaming JOSM -- suggestions?
On Jul 7, 2020, at 4:37 PM, Bob Gambrel wrote: > A very good answer stevea. I suspect the changes I have been making would be > appropriate enough for removing tiger_reviewed=no. > > 1) almost always have driven the road as passenger taking notes in OSMAND+ > about pavement type > 2) in ID carefully aligning the roads > 3) in ID verifying that an extra road doesn't exist by looking at several > aerial phots sources before deleting > 4) setting pavement tpe > 5) setting lane counts > 6) putting in traffic signals where known > 7) noting stop signs where possible and adding stop sign nodes > > Have been less likely to change road type. For example have left minor rural > roads as residential if there are farms on it. I have made sure that service > roads and driveways are not naked as residential. > > From now on I will get rid of the tag as I walk through an area. > > Thanks for the two links and advice. Am not ready to exhaustively do an area > by using OT. For now just concentration on roads that I have been on and > taken notes about and have created and uploaded traces for. That all sounds great. As I have said, "no mapping task that positively contributes to OSM is too small." We all make contributions at our own pace, biting off what we are able to chew. "The journey of a thousand miles begins with a single step." (Slaying the TIGER dragon involves individuals one at a time whacking away the tiger:reviewed=no tag). It's all good, SteveA ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Streaming JOSM -- suggestions?
Bob, thank you for asking. Good entry points for the history and what to do with TIGER data are https://wiki.osm.org/wiki/TIGER and https://wiki.osm.org/wiki/TIGER_fixup (respectively). One of the more important things you CAN do is that if you truly do "fix up" TIGER data to about as good as it can be today (given local knowledge — best — or aerial / satellite data like Esri or Bing) is to remove the tiger_reviewed=no tag. As the latter wiki says, "the practice to remove this tag varies" but I believe you should feel confident removing it when you are personally proud of the resultant data in OSM being truly reflective of what is in reality as you upload the changeset containing it. And, it isn't simply "alignment" being accurate, all of the tags on that datum should be snappy, modern and correct, too. It's not hard, and can even be fun with some practice. There used to be some excellent tools for visualizing areas where TIGER Review is needed, unfortunately, these are either old, fully deprecated or replaced by less-than-as-useful tools (imo). It may be that Overpass Turbo (OT) queries suit you, I use them in my large (data, geographically) state of California on TIGER rail data, and the results (while somewhat large) are not overwhelming, either to browsers, editors (like JOSM) where you might edit them (or subsets of them) or humans. However, for highway=* data, especially in a large (data, geographically) state where little TIGER Review has already completed, you may very well find OT does get overwhelmed. Try the query I (and others) use for California/Railroads: http://overpass-turbo.eu/s/PSt noting that it is easy to change the geocodeArea to your state and "way[railway]" to something like "way[highway=tertiary]" Of course, you are asking the OT server to digest large amounts of data as you do so, be prepared to (first) increase the timeout value (try one-minute-at-a-time bump-ups, from 180 to 240, from 240 to 300...) and (second) you might need to decrease the geocodeArea to a (unique) county, rather than a whole state-at-a-time. Good luck, have fun, share with your OSM friends how this can be a fun activity in your local area and let's slay the TIGER dragon! SteveA ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Streaming JOSM -- suggestions?
Hello again, Martijn: This might not be a perfect fit, but perhaps helpful. I (and others) have refined how TIGER data for rail in the USA might or should be "Reviewed" (cleaned up over the long term) at https://wiki.osm.org/wiki/United_States/Railroads#Editing_Railroads_starting_from_TIGER_data Like TIGER data themselves, this is rather rough, but it has proven to "get the job done," even as it might do so slowly. If you could make a similar write-up (text-based instructions of your workflow to clean up TIGER data, whether roads, rail or whatever) that gets shared widely, I think many people might find that helpful. It is the experience of what people do and how they do it that makes for this sort of transfer of experience at "how to map" quite successful in OSM. I've seen it, it works and people tend to not only like it, they sort of crave it. "When the student is ready, the teacher arrives." Sometimes this is a "live streaming JOSM editing session," (great!), sometimes it's a "here are the steps of my workflow, read them, re-create them at your own pace, I hope you can learn from my examples." You never know! Thank you for offering your "streaming JOSM" session, it's a great idea, SteveA ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] [openrailwaymap] Self organised session at SotM about Railway tagging in the US tomorrow
Chuck contacted me, Nathan and Clay are included in the emails, we'll see how many of us might make it tomorrow. Thank you for organizing the discussion, Michael. SteveA ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] National Forest boundaries
losed_member_ways_belonging_to_the_same_role>. Yes, that would break JOSM's Validator plug-in, for sure (not potentially, I've seen this and done this and the only way to upload the MP is "in Error" or after it is corrected so that there are no shared outer ways). > That said, I'm not quite sure of the nuances of valid/invalid multipolygons > that are children of a parent relation and I'd be happy to be wrong on this > point. It's rich, deep and almost beyond my ken. I think I can understand it, I think many who are reading this can, too. Speaking for myself, we're out on the hairy edge of my understanding of MPs, super-relations, differences between boundary and MP and how the sort of "higher math" of tagging segments differently, then stitching them together into either polygons or members of MP relations affect whether the MP / relation is or isn't valid. Thank you, Adam! This thread HAS momentum, let's keep it rolling! SteveA ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] National Forest boundaries
Adam Franco writes (about my 1, 2, 3 post potentially defining NF MPs, now clarified that 1 isn't "all enclosing") > I think this is correct:. He continues: > If there is consensus on dropping (3), then a system for mapping NFs as > (1-2) should be possible to figure out. That said, how that OSM object is > assembled and tagged may be tricky. In the Green Mountain National forest > the (1-2) area contains a large mix of areas with different protections... > Some of these child boundaries would have their own names and additional > tags, others not. Exactly! I'm not yet ready to say 3) should be dropped, though I strongly lean in that direction, as I think it's unnecessary / superfluous given how we map "actual" data, not necessarily "Congressional" data, whatever that means. Let's allow this list to concur and / or wider consensus to emerge about whether 3) can be clearly articulated enough as "here's how we should implement these data in the context of a well-crafted NF multipolygon," or whether it's not logically / geometrically necessary for OSM to denote and should be "dropped." We'll eventually get there; we do inch closer. Especially as it seems to be emerging that OSM can (and does) well-represent NFs with completely OSM-conforming multipolygons of the sort that I describe with 1) and 2), even while I/we look for additional guidance on 3). Here's something I'll throw against the wall and see if it sticks: maybe 3) (Congressionally-defined boundary) is a sort of crutch, a "nice to have," but not strictly logically / geometrically necessary except as a rough outline sketch of this NF (for Congress-critters, for low-zoom maps). It seems we're there, but again, I solicit clarity on 3) here and now. > I would imagine that the parent NF object that has the name > "Green Mountain National Forest" would contain members that had > protect_class=6 (resource extraction), protect_class=1b (wilderness), > protect_class=5 (recreation areas, Appalation Trail corridor), etc. Again, yes. To clarify, the NF object itself (the multipolygon's tags, I'd discourage calling this "parent" as it means something else in the context of relations and super-relations and we shouldn't confuse those) would have the name=Green Mountain National Forest + protect_class=6 tags (plus others, like operator=USFS). AND the additional members "associated with the NF" (like wilderness areas which are "within the NF") would be separate polygons with role inner as members of this NF relation, but ALSO with their OWN tags (like protect_class=1b and name=Breadloaf Wilderness). Yes, this makes "holes" of wilderness inside of the NF, but think about it: if the "whole thing less inholdings and stuff that's different" (outer minus inners) really deserves protect_class=6 AND the "inners that are wilderness" are tagged with protect_class=1b, well, we've got it! Sure, doing it like that makes it logically appear (and maybe actually be) that wildernesses are excluded from the NF, but in the sense by which we tag them, they ARE excluded, even as they are surrounded by something with a "lesser" protect_class. Plus, it is the same agency tagged both on the multipolygon (for the outer) and its member inners. They are logically excluded by being inners, but because the MP is tagged operator=USFS (and so should be the inner wildernesses), we "add them back in," at least for their operator, by virtue of that tag being on the inners (But being differently tagged with protect_class=1b, as they should be). Whew! > I'm not sure what tagging would be appropriate for the NF object itself > maybe these as a starting point? >- name=* >- boundary=national_park >- operator=US Forest Service That IS a good starting point, for an exposition I recommend our wiki on this topic: https://wiki.openstreetmap.org/wiki/United_States/Public_lands#Agriculture_Department_.28USDA.29_National_Forests_.28USFS.29.2C_National_Grasslands.2C_Special_Biological_Areas (Full disclosure, I'm a significant author of this wiki, even as I and other authors earnestly seek wider contributions to it). There, we say: • boundary=protected_area • protect_class=6 • protection_title=National Forest • ownership=national • operator=United States Department of Agriculture, Forest Service Regarding the subtopic (in this context) of "Ranger Districts," I think that can be accommodated with polygons of the particular areas that make up the MP of the NF and naming them accordingly. It might take some work on the part of an intrepid OSM mapper to do this, as I'm not sure the way the USFS publishes the geo data of the NFs these are quite delineated &
Re: [Talk-us] National Forest boundaries
ferent (operator=BLM, for example). I've understood this and tagged like this for many years (and thought I've done a decent job of building NFs, at least in California, where I primarily map). But then this topic of Congressionally-defined reared its head, and it still spins mine around. Can anyone continue to offer more clarity about this? Bradley, thank you so much for all you've said so far, I do get closer and I hope the list does as well. SteveA ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] relations on which thematic data can be connected? eg internet availabilty byt zipcode
Ray Kiddy wrote > ...published by the FCC and I think that at least some of the information is > per zipcode. and > Wow. Bizarre, but good to know. Yes, I _always_ have thought that zipcodes > partition land areas. This was not my original though, but I have found it useful (and mentioned in a sprinkling of places) to think of ZIP codes as a sort of routing algorithm meant to facilitate the efficient movement of mail through the USPS infrastructure. Their history is quite interesting and supports this interpretation, especially with automation and the extensions to 9- and 11-digit codes. > Now I have to wonder if ZCTAs are still around and if they are mapped. I > expect not. Considering how OSM wants to (and to some decent extent, does) denote census areas as quite distinct from the "OSM-usual" key:value pairs for conurbations, and ZCTAs blend ZIP codes and census boundaries, you'd muddy a lot of water by using ZCTAs, especially as you use OSM data. I, too, (like Clifford) wish you good luck and hope you have fruitful results you might share with us here at the completion of your project. SteveA ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] National Forest boundaries
A refinement, perhaps Bradley and others agree with me, perhaps not. A USFS NF is a "virtual" multipolygon (not one in OSM, we can get to that later) of three kinds of things: 1) An "outer" (but not the biggest one) which is "the enclosing land which USFS manages, except for inholdings, below," 2) Zero to many "inner" polygons, representing inholdings (and with the usual "hole" semantic of exclusion from 1), above and 3) An even LARGER and ENCLOSING of 1) "outer" which Congress declares is the geographic extent to which USFS may or might "have influence to someday manage." If we ignore 3) as "not real, but rather aspirational or in the future rather than the present, and certainly not on-the-ground" then an OSM multipolygon consists of simply 1) plus 2). Yes? SteveA ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] National Forest boundaries
On Jun 24, 2020, at 9:40 PM, Bradley White wrote: > NF congressionally designated boundary, minus private inholdings (more > specifically, non-USFS-owned land), gives you the boundary of land > that is actually managed and protected by the USFS. This boundary > should be tagged with 'protect_class=6'. USFS owned land is always a > subset of this congressional boundary (I suspect it is, in all cases > in the US, a proper subset). Subtracting these private inholdings is > generally going to change the shape of the 'outer' way such that it no > longer is the same as the "designated" boundary. That really helps; thank you! I think I still need to do some imagination exercises here, and maybe see some examples (in a JOSM buffer, in the real world...) and it will fully crystallize in my mind. And, if true, the phrase "proper subset" helps, as well. >> My slight disagreement with Bradley is as above: I don't think we should >> put a "naked" (missing admin_level) boundary=administrative tag on these, it >> simply feels wrong to do that. (I READ the point that these are >> "Congressionally designated" and that SEEMS administrative...but, hm...). > > I wasn't clear in what I meant by suggesting 'boundary=administrative' > tagging here - I don't think we should tag "declared" boundaries > 'boundary=administrative' with no 'admin_level'. This is simply the > closest widely-used tag that comes close to representing what this > "declared" boundary actually means. This is also why I suggest we > think about not including it at all in OSM; should we also start > adding boundaries for interstate USFS administrative regions (an > 'admin_level', for lack of a better term, more general than a NF > boundary), as well as ranger districts within each national forest? > > The real, on-the-ground objects of importance here are the plots of > land that are actually owned and operated by the USFS, not an > administrative boundary that declares where each national forest *may* > legally be authorized to own and manage land, and that is not > surveyable on the ground. We were doing great there, then I think my (admonishment? might be too strong) way of expressing "owned and operated by the USFS" is technically, accurately stated as "owned by the People, managed / operated specifically by the USFS." If you can agree with me there, I think we can get even closer. If not, that seems like a central core of the snarl in at least my understanding. There are three states we seem to be trying to capture here: 1) land Congress declares is "managed and protected" by USFS, which OSM represents with an enclosing "outer." 2) Excluded from 1) are inholdings, which have role "inner" in the multipolygon. 3) Land Bradley called "owned and operated by USFS" (but which I say is owned by the People and operated by the USFS). See, 1) and 3) seem like the same thing to me. Why would Congress say what Bradley mentions first (at the top of this post) is "managed and protected by USFS" (minus inholdings) and yet there is something "owned by USFS" (when the government owns land, the People own the land; the government agency is operator FOR the People) which I seem to confuse with 3). Am I doing that? Is Bradley? Is Congress? Is it about ownership and operator status being confused in my mind? I'm not stupid, I'm getting closer and I'm grateful for what I hope isn't confused blather. Thankful for talk-pages, thankful for the good talk that happens within them, SteveA ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] National Forest boundaries
I (momentarily?) recede from my "watching mode" in this thread to offer my
agreement with Mike and to reiterate a slight disagreement with Bradley (or
maybe to ask Bradley and especially the wider list here for clarification), as
while it seems we get closer to a "more definitive" way to tag NF boundaries,
this discussion doesn't seem close to having yielded a complete agreement
(yet). Nor even full understanding, at least on my part.
My agreement with Mike is noticing that (in California only), CPAD data for NFs
are excellent quality; I believe OSM users in California should feel
comfortable using them for NFs, as when I look at the "SuperUnit" version of
CPAD's release of these (there are also "Unit" and "Holdings," a sort of
"parcel-level") NFs invariably have a big, SINGLE outer polygon (and up to
hundreds of inners). I wrote wiki on how CPAD data might be best utilized in
OSM, see https://wiki.osm.org/wiki/California/Using_CPAD_data . However, I'm
not exactly sure how the outer polygons found in NFs differ from either the
"Congressional" boundary or the one Bradley says he would tag
"boundary=administrative" (and I don't think we should tag it that, especially
while excluding a specific value for admin_level), but I'm willing to listen to
more discussion about what this "different from Congressional" boundary is and
how the two differ. Apologies if that isn't clear, I'm doing my best, but I
remain unclear on some concepts here.
My slight disagreement with Bradley is as above: I don't think we should put a
"naked" (missing admin_level) boundary=administrative tag on these, it simply
feels wrong to do that. (I READ the point that these are "Congressionally
designated" and that SEEMS administrative...but, hm...). One major problem I
have is that we're multiplying polygons (by two) here for a SINGLE national
forest. Isn't there a way we can keep all these data in a single relation?
Yes, inner can remain as the right role for inholdings, maybe outer is better
placed on either "Congressional" or "the other one that is more on-the-ground",
maybe we coin a third role ("congressional"?) for that one, allowing us to keep
the "bigger, enclosing" polygons in a single multipolygon relation, which I
think is an "OSM-sane" thing to do.
Summarizing, CPAD data for California: very good. Maybe even excellent,
though I think some examination of the differences of NFs between the
SuperUnit, Unit and Holdings flavors of CPAD data is a very good idea that
somebody (a Californian OSM multipolygon and shapefile jockey who knows
something about national forest structure) should take some time to examine.
Differences between "the two" kinds of "more outer" multipolygon boundaries of
NFs? Murky, well, remaining somewhat murky in my mind, at least how these
should best logically be expressed by OSM relations. The discussion is good, I
simply reiterate my "I still don't quite understand all of this very well" here
and now. Brian seems to agree with me and I don't think I'm alone. Let's keep
the momentum rolling until more / most of this achieve that "a-ha" moment as to
how OSM should best express NFs with multipolygons.
SteveA
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] National Forest boundaries
Thank you Bradley, Mike and brad for the fascinating insights, clarifications and continuing discussion. I did not realize that this sort of boundary / ownership / administration / distinctions with private inholdings was anywhere near this complex: that "Congressional Boundary" thing I find quite a curve ball. I think OSM can accommodate both "kinds" of boundaries, but I'm not presently sure how best to do so. I am glad to learn of the distinctions. And of course, when we talk about public "land owned by the USFS," what we really mean is "land owned by the People, and managed for us properly, under law, BY our federal employees, the USFS." I retreat to more of a "watching mode" to see if more discussion shakes out of this. Again, it is fascinating. SteveA ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] National Forest boundaries
>> A relation for all would be ok too, as long as the private inholdings are >> not removed from the NF (which I think has been done in some cases). > Bradley White writes > I've argued for this in the past on this mailing list, but have since > come around to disagreeing with this position over tagging semantics. > Most NF boundaries are now tagged with 'boundary=protected_area', in > which case the boundary should represent physical land that the NF > actually owns and manages, and not the congressionally-declared > boundary. In my area, half of the city of Reno and nearly all of > Truckee fall within an congress-declared/administrative NF boundary - > these areas are certainly not protected. "Private inholdings are NOT removed from the NF?" (Emphasis mine). That doesn't make sense to me. OSM WANTS to (logically) remove private inholdings from NFs. We do so with relations where inholdings are members with the "inner" role. While it certainly may exist, I'm not aware of a disparity between the "congressionally declared boundary" and any other boundary of a NF, including "physical land that the NF actually owns and manages." How would anyone know where this latter boundary is? (Opinion?) Around Reno is Humboldt-Toiyabe NF, largest NF in the lower 48, nearly 10,000 square miles, that is LARGE. Wikimedia has a nice interactive map of this (superimposed on OSM data) at https://en.wikipedia.org/wiki/Humboldt–Toiyabe_National_Forest . Yes, it looks like "half of Reno" is within this boundary. I agree with you it is odd / unusual that this mix of urbanization is technically within NF boundaries. Yet, it is. I believe OSM wants to map this NF "as is," not "where it appears the area is 'not protected'" (again, by your opinion?) National Forests are federally-managed land, often with many inholdings in highly complex landuse blends. OSM has the "machinery" to represent them: data structures called multipolygons with membership roles of outer and inner, plus tags. If thousands of residential parcels in Reno "should" logically be excluded from H-T, yes, that's ambitious (and rather odd / unusual / even wacky), but it seems to me it is correct to represent it that way in OSM. Can somebody (literally or figuratively) call up Bill Dunkelberger (Forest Supervisor) and ask him the questions "why are thousands of Reno's residential parcels inside the boundaries of our forest? Can you explain how a map might properly represent this?" There might be some history about the city of Reno, how Congress declares federal protection with a fee simple boundary, likely a great deal of hand-waving and probably an "admission" that constructing a ridiculously-complex multipolygon could properly represent it, but only with mind-boggling intricacies of detail. Are we up for the task?! > IMO, a tagging scheme that better represents the meaning of these two > boundaries would be: > 1. 'boundary=protected_area' around fee simple NF land ownership, > since this describes the actual protected areas of land > 2. 'boundary=administrative' (with a not-yet-existing 'admin_level') > around declared NF boundaries, since this is an administrative > boundary for the NF and doesn't necessarily show what land is actually > managed by the NF. I am virtually certain we do not want to put boundary=administrative on NFs (and without admin_level, this doesn't make sense; the two tags are codependent). This EXCLUDES them from whatever admin_level you MIGHT give them, making them a "hole" in that entity at that level. Many years ago, I (mistakenly) thought that national parks should haven an admin_level=2 set on them (and state parks 4 and county parks 6) but that logically punches a hole in the country, state or county, so "don't do that." > We should even consider not including congressionally-declared > boundaries, since they aren't even theoretically verifiable on the > ground, and really don't necessarily indicate any kind of protection > of the land within the boundary. Fee simple ownership is at least > usually ground-verifiable with small yellow "NF boundary" placards. This needs more discussion, with a better declaration of terms. If Congress declares an area as protected, OSM should map it as protected. That doesn't seem weird to me, although "half of Reno in a NF" does. Most importantly how would we / who declares where is this "other" boundary? (not the Congressional one, the one which says "the USFS actually owns and manages this") Very confusing as stated; I think we can state this more clearly. SteveA ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] National Forest boundaries (Mike Thompson)
On Jun 21, 2020, at 5:58 PM, Mike Thompson wrote: > 1) Not all "inholdings" are completely surrounded by the National Forest, > they are "bites" off the edge in some cases. I don't think one can have an > inner ring and an outer ring which are at all coincident (they can't share an > edge) and still have a valid multipolygon. I don't wish to sound dismissive as it seems we largely agree, but this is merely quibbling over constructing an outer edge. If truly a "bite off the edge," then it seems the outer polygon should shrink to accommodate, no need for edge mumbo-jumbo (though sometimes these edge memberships take on a tagging life of their own and it gets to be a high-wire act as to how "loaded with tags" each one might become). There are a lot of methods to capture semantics using syntax that is crisp and unambiguous, I believe some methods are smarter (less or even no ambiguity about the semantics that are "meant") and cleaner (fewer data) than others. There is what might be characterized as "a wide zoo of tagging in these realms" (nationally at the enormous polygon scope). Thank you (again) to Kevin for the word "menagerie" here. This also enters what some have dubbed "higher math" (multipolygon edge tagging in a relational database and how deep these semantics can be relied upon are a "topology of deep genus"). > 2) Holes (inner rings) are not part of the polygon. Thus if one did an > analysis of (for example) a series of points, any points that fall in one of > the holes would not register as being inside the multipolygon, even though > they are inside the outer ring. That sounds right. And a snappy-efficient way to achieve what is "truly excluded as PRIVATE" as an inner member of an "outer polygon that describes geographic extents of this PUBLIC forest" is by simply tagging what IS the inner member with "what it is." That might seem fancy word salad, so I want to break down what we say as understandable to both of us. We're using the double-duty that in a public forest (with a large, enclosing geography, but no larger than necessary or truly) which is tagged as outer role, anything we tag inner role is EXCLUDED from the public forest. That "inholding," in every sense I've ever seen it, is private, hence, it's an inner to the outer, as private isn't public and vice versa. The logic of opposites, the power of roles (inner and outer) in a relational database and the geography (in 2-space) of what we "mean" (quite intentionally) by inner and outer become powerful. Let's simply tag the "thing inside, different from its enclosing polygon and so excluded from that polygon" for what it is, then include it as an inner member of the relation. We do this, the logic of "nodes registering or not" is already built into "the space." Think of a grassland in otherwise-land-filled-with-trees, it's a (mathematical) "hole" (of the 2-space, lat-long of nodes OSM lives in). It simply works, like math, geography, software. (Um, "well written" software!) Meet you off list? Steve ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] National Forest boundaries (Mike Thompson)
Continuing from my previous post, we even have an especially data-compact (efficient) way of representing that: the member of the forest relation which is an inholding (tagged with role inner) IS the polygon of, say, a private residence "inside of" the forest. For example (I'm making this up), say we have a national forest with a small shopping area (for food, supplies...) near its center for convenience. I could see one polygon (tagged landuse=retail, name=ABC Forest Shopping Center) both BEING exactly that, AND being included in the (enclosing) forest multipolygon as a member tagged "inner." Voilà, double-duty and done. SteveA ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] National Forest boundaries (Mike Thompson)
Mike Thompson wrote: > One polygon for the administrative boundary of the NF which was established > by Congress. > Zero or more polygons describing limitations on access (no need for polygons > to for access=yes, we can assume that in a NF generally), whether they be due > to private ownership, or other reasons. > The above are two separate concepts, so it is ok to have two separate OSM > elements, in my opinion. > A relation for all would be ok too, as long as the private inholdings are not > removed from the NF (which I think has been done in some cases). If I'm not mistaken, we already have the machinery to do that with how we build multipolygons. To wit, a single multipolygon (well tagged as to name of national forest, protect_class=6, ownership=national...representing the forest) has one or more polygons with role "outer" where all those tags apply and one or more polygons with role "inner" where there are inholdings and "something else, not national forest" are, and the tags on this multipolygon do NOT apply. (These appear as "holes" in the usual way inner members do in a multipolygon). There is nothing stopping us (and sometimes we do) from adding additional polygons that are "coincident with the holes" which represent "what that particular inholding is." It seems to me THOSE are the places where any access tagging (if necessary) might apply, should your fancy run to tagging those specificities. We've been tagging "large public areas with inholdings" like this (using multipolygons with inner members) for as long as OSM has had multipolygons. Why might we (re-)establish "two separate concepts" in two separate data structures when we already achieve this with one data structure (and possibly others, by that I mean "one multipolygon representing the forest, which might have inner members," while noting that ADDITIONAL polygons can describe what the inholdings ARE and superimpose on top of the holes represented by the inner members? Am I missing something? SteveA ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] National Forest boundaries
A large thank-you to Kevin for that deeply informative post.
> brad wrote:
> I think its simpler and better to just create an inner boundary as was done
> with the Coconino NF
The Coconio NF (relation/10956348) hasn't "an" inner boundary, it has hundreds
of them. I'm not sure I understand what Brad is saying is "simpler and better"
here, as a well-constructed multipolygon in OSM is "a well-constructed
multipolygon in OSM." We already know how to do that so I don't think we want
to develop something else to represent the same thing.
Is Brad or Mike proposing something else, like two multipolygons to describe
one national forest? I'd be against that (unless I hear and understand more).
Perhaps Brad can tell the list what he thinks is "simpler and better" in the
context of a well-defined multipolygon with one or more outer members, one or
more inner members (as we've established) and then what he might propose?
There is something intriguing with how Mike worded it ("separate polygons for
inholdings, tagged with access=private and possibly ownership=private") which
is certainly novel, and I'm willing to listen to that, but I don't quite
understand what he means. Two relations for one forest? Our wider tagging
practices don't (currently) understand this (two relations, one entity), nor do
any renderers (that I know of), but this sort of access/ownership tagging on a
separate polygon is an idea that might allow us to pack semantics into a
relation (or two relations?) in a way I haven't thought of before. Kind of
pie-in-the-sky, but I'll listen, provided I fully understand what is being
proposed.
We've established there are "more simply described" national forests where
more-or-less "only" (or substantially only) the outer polygon is a member of
the relation, and "very well described" national forests with highly complex
memberships (perhaps multiple outer polygons, and numbering into the hundreds
of inner elements, like Coconio). OSM (in my opinion) has room to accept both,
knowing that while the latter is much more complete, the former might be either
a case of "very few if any inholdings, so essentially 'done'" or it might be "a
rough sketch of (only) the outer polygon member to get the relation started,
more inner polygon memberships need to be added to this relation." And that's
OK, but if / as we do so, let's make note of it (perhaps a FIXME tag in the
relation with value "Incomplete; needs more inner members to describe the full
gamut of all inholdings in this forest.")
SteveA
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] National Forest boundaries
I don't think we should map all ownership in OSM either, however, there is a
lot of tagging in OSM right now which does tag ownership=national,
ownership=state, which, for public lands owned by the federal or a state
government, I have no problem with making this distinction known in OSM
tagging. It doesn't "hurt" our data and I personally find it informative to
make this distinction (sometimes as an OSM author, sometimes as an OSM
consumer). I feel here that Joseph is asking us to accept hyperbole ("we
should not try to map all land ownership by parcel") when I'm not nor do I
believe our volunteers are asking that. (I understand why, I even agree,
"let's not tip towards OSM as cadastral-oracle, those are elsewhere"). I might
tag something ownership=national or ownership=state on some public land,
because lots of us seem to be doing that and I find it useful data (sometimes).
OSM isn't looked to as a land-ownership database, even as it might have a
sprinkling of those on data, especially "national vs. state" distinctions for
public land. That's fairly common around the world.
In California, if you don't put a Civil Code 1008 sign up on your private-land
easement, de facto or de jure, it might become a public easement. There are
rules, they are local, I don't think OSM wants to quibble here. We might need
to quibble and sketch in some localized method of doing things at some level in
some cases, that's manageable. I am not an attorney.
It's OK to have similar conversations over and over again. We get a bit
smarter and sharper as we do, as long as we don't lose patience or civility. I
think we're fine in that department.
SteveA
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] National Forest boundaries
Mike, I hadn't considered that, it distinctly deepens the discussion. Stroking my chin and saying "hm" now. SteveA ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] National Forest boundaries
I think we need both as well. I've been doing this while watching the evolution of how we best do this as I participate in a "do our best, always better" efforts to accomplish this. Even now! The idea of the first kind is simply a relation with a focus on the / a polygon with the outer (-most) membership. The idea of the second kind is one of these plus a carefully crafted inner membership, often made up of a complex inholding distribution containing many sometimes complex themselves inner polygons. The idea of "both" (in my mind, maybe Mike's too) is that "a good outer is a good outer." We ARE building multipolygons and they are big complex beasts around here. And we cannot let the perfect be the enemy of the good. Are you willing to "take on" the responsibility of entering a sane (for 2020) relation with "simply" a single outer polygon as member of an emerging multipolygon relation representing the national forest? Hey, tag it well and hang it up for others to add richer complexity with inner members. This is (sometimes) how we build this map. (I have offered my efforts for a decade). I believe we want to tag these with protected_area, whereas we did, but no longer, "automatically" double-tag these with natural=wood, as landuse (national protected area we manage with our Forest Service, doesn't mean it's a forest) is not landcover. As we're talking about the US, I recommend our wiki https://wiki.osm.org/wiki/United_States/Public_lands. That wiki is what might be called "heavier lifting" in how we use a wiki. Part of it intends to be prescriptive, saying "here's how we might very-well tag in the USA on public lands, and if we don't, we should" (as an ideal, at least as it shapes with sharper focus). Where it dissolves into "how each state does this today," it's a DEscriptive canvas of wet paint. Heavy lifting, yes, but we can do this. That wiki might nudge things forward, I put my shoulder into this. At the federal level (which National Forests are), it does (to me) feel like a nice ideal with fairly-well-defined recommended tagging. Discuss there? How do what we enter render? That's another topic. Let's begin saying "we can, do and should enter into OSM well-tagged outer-member (only, to begin with) multipolygon relations representing national forests." With "perfect, rich structure?" Every single first draft? Let's talk in a week or month, these might take some work and discussion and work and discussion to do them. That's OK. Earth wasn't built in a day. SteveA ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Rail tagging in US (and North America): operator=* and reporting_marks=*
Russ Nelson writes: > Yeah, for me the map is much more important than the wiki. Except for > Wikipedia's stupid citation rules, all that information > belongs in > Wikipedia. Although if it drives more mappers, that's fine. Maybe we should > populate the wiki with the > old_railroad_operator information? That would be a smart. I wish NE2 could > have managed to color within the lines. > He was a very prolific mapper. As the author of that "in-its-infancy / not-even-alpha" New York/Railroads wiki (and dozens of other state-level /Railroads wikis, some of which ARE alpha, and a few are beta) I must say I agree whole-heartedly with Russ (and I believe most of us) that "map data are much more important than wiki data." Additionally, in 11 years of OSM mapping and wiki-writing, I HAVE seen that wiki (which admittedly does lag mapping) very much can contribute quite positively to developing community, establishing standards (which might slightly diverge at a continental-level instead of worldwide, or a state-level instead of nationwide, so let's wiki-document those divergences) AND allows an at-a-glance "status report" mechanism by color-coding (red-yellow-green) how far certain progress is (such as TIGER Review) in tables. This admittedly does straddle a line of "effort expended vs. positive benefit gained" but in another agreement with Russ, "as it DOES seem to drive mappers, that's fine." The wiki isn't always a go-to for would-be rail mappers, but for those curious who discover somebody has taken some time to develop a statewide rail wiki local to them (even at a pre-alpha level of completion) it can be like a guided tour while someone gently holds your hand. As "all Western states" now have at least a preliminary /Railroads wiki, we are well on our way to the back-and-forth development of both better rail editing that improves TIGER data and developed and updated wiki which reflect the progress in doing so: the "divide (by a state at a time) and conquer (to the extent any single editor has the energy to do so!)" strategy of doing this with USA rail really works. I like the potentiality of a typo with "that would be a smart" (start?) Yes, old_railroad_operator tagging and wiki-inclusion is an important consideration for rail tagging in the USA, most often for Abandoned rail: see how https://wiki.osm.org/wiki/California/Railroads#Abandoned_lines (for example) consistently includes old_railway_operator=* as table Column #2, this seems the completely correct thing to do (in the wiki, yes, but in tagging old_railway_operator=* in the map as "more important," we agree). Regarding NE2, I had my interactions with him way-back-when. He was like the Good (he WAS prolific!), the Bad and the Ugly all rolled up into one. Many have said "good riddance" to him being banned, he was certainly an early OSM example of "be bold." My personal experience of feeling like USA rail mapping is overwhelming (it is a VAST amount of data) is that "eating the elephant" really can be done one bite at a time, where state-level "divide and conquer" is actually doable. Yes, California is a gigantic rail state, but over the years, we've been able to get the data and the wiki to "later beta." We can do so in other states, too: data being more important, wiki being secondary, but still important to build community, establish maybe-local standards, and offer "status reporting" with color-coded tables. I am bowled over that Nathan Proudfoot says "Researchers utilize OSM as we have the most up to date railway map in the country of any data source...". Wow! Go OSM, SteveA ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Rail tagging in US (and North America): operator=* and reporting_marks=*
It is absolutely fascinating (to me, anyway) to watch this conversation! I thanked Russ Nelson on wiki for his comments at New York/Railroads. (And we still have a ways to go there). SteveA ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Rail tagging in US (and North America): operator=* and reporting_marks=*
I point out for those who might not know this: rail tagging, despite excellent efforts by the ORM folks (largely in Germany, I understand) to encourage OSM to follow global tagging conventions for ORM, have already quite seriously fractured (necessarily) into country-specific tagging standards. (Or in the case of North America, three-country-specific, as while there are differences in these three countries, they are relatively minor and do share a lot of commonality, quite intentionally, because of the large amount of interchange traffic between them). This country-specificity is in both our tagging and in our wiki, and again, quite extensively. SteveA ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Rail tagging in US (and North America): operator=* and reporting_marks=*
Volker (hello!) discusses that the tag (used in the USA, but not extensively) of "reporting_marks" isn't (I paraphrase him a bit) "as international as OSM might like it," and proposes presumed-better tag "operator_identifier" (I correct a minor spelling error in his posted suggestion). Volker also mentions that this tag seems to be meant for rolling stock, asking on what sorts of OSM data the tag will be applied. Meanwhile, Chuck (hello!) answers that reporting_marks will be applied to ways (perhaps not as originally intended to identify the owner / operator of rolling stock) but that this use of reporting_marks (or operator_identifier, it isn't yet decided) is semantically an excellent OSM syntactic synonym for "short_name_of_operator." (I agree). I'm of mixed opinion on this. On the one hand, I agree with Volker that "regional tagging" (as in all of North America, as "reporting_marks" are used in all three countries) should be discouraged in OSM in favor of more worldwide standards / tagging, especially as they already exist (though, "operator_identifier" comes up empty in taginfo). However, as this tag doesn't yet exist (in Europe or elsewhere), that diminishes its value, except going forward (and there's nothing wrong with that). And, the tag "reporting_marks" (also, "reporting_mark" is used more often, though primarily by one mapper, Chuck and I have discussed these two tags should be conflated into "reporting_marks" as a single tag) already DOES exist, and it IS an existing "regional standard." So, I'm sitting on the fence, seeing both potential solutions have merit. What I think might work is for North American rail mapping to continue to "standardize" on using "reporting_marks" as a tag with a value that effectively stands in for "short_name_of_operator" (and we should wiki-document this) and others should chime in (please) with what I agree with Chuck is a good use of this simple (and widespread: in all of Canada, USA and Mexico, which interchange a lot of rail with each other) "rail standard," regional-to-North-America though it is. If Germany or European and / or Asian / African / South American countries want to something like this, they might get started now, using (as I propose North America does) using their own flavor of "reporting_marks" (as originally intended to identify rolling stock) as a novel and useful method to identify carriers (owners / operators) on OSM ways as a synonym for short_name_of_operator. Then, at some point in the future when there can be some global OSM harmonization of these, a proposal to roll them all into "operator_identifier" (which suits me just fine) can take place as a good idea that will standardize this sort of tagging worldwide. But in the meantime, I think it a good idea for these to develop locally / regionally, with the terminology to both mappers and those familiar with railroad terminology (as it is used locally / regionally) being used. That will "root" and better establish these tags, I believe this is (almost?) necessary (first). The globalization / standardization can happen later. This seems a workable approach, though I'd like to hear from others who might posit that a "no, let's globalize such tagging immediately" approach is better. SteveA ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Off-highway vehicle recreation areas
Tod Fitch writes: > I have noticed a couple of off-highway vehicle recreation areas that are > tagged with things that seem incorrect to me: As generic parks or as > protected areas. The one near me (way/40263471, Hollister Hills State Vehicular Recreation Area, SVRA) I myself have tagged landuse=recreation_ground, but I've been taken to task for doing that, as it isn't one of these as our wiki defines it, even though the name of it seems like a good match (it isn't). However, I suffer from the same problem, as I don't know what a better tag is, either. California State Parks (who manages them) prioritizes them as "recreation opportunity," although their web site says "provisions in California law require actions to stabilize soils and to provide for healthy wildlife populations in OHV recreation areas." So there are some leisure=nature_reserve aspect to these, one could argue (but this is for the restoration of the lands for the primary purpose of offering the ORV recreational opportunity). I agree with you that neither leisure=park nor boundary=protected_area are appropriate on these sorts of areas. They are specifically set aside (by the state) as areas for rather intensive landuse by off-road vehicles, and they can be quite extensive. Hungry Valley SVRA is about 30 square miles in area, with well over 100 miles of ORV trails, not something small by any definition. > Consider the Hungry Valley State Vehicle Recreation Area [1][2][3][4] and the > Wildomar OHV Area [5][6]. It appears we are both in California and "suffer" from "how best to tag?" about these. Nor (as is Hungry Valley) is BOTH boundary=protected_area (it isn't) and leisure=nature_reserve correct. Plain and simply, "not." Hungry Valley even has at least two "inholdings" (areas internal to the SVRA) which ARE boundary=protected_areas, the Freeman Canyon and Gorman Cultural Preserves. Oddly, these are tagged boundary=national_park, which isn't quite correct, either. Located between two major earthquake faults, Hungry Valley is quite interesting geologically. > My problem is that I can’t tell from the wiki and taginfo what might more > appropriate or more accepted tagging. It seems there is tagging for tracks > used for motocross. And people have used access tags for ATVs. But I don't > see a documented tagging for an area that contains a trail system for use by > multiple types of off-highway vehicles. I have some thoughts on what might be > appropriate, but would rather hear from others. I'm coming up empty of "what to do?" but I am finding quite a few of these with quite-poorly tagged boundaries. Surely, OSM can do better than this, but Tod asks an excellent question: "with what tags, please?" SteveA ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Rail tagging in US (and North America): operator=* and reporting_marks=*
My apologies (it was my error): the correct link to Chuck's post is https://wiki.osm.org/wiki/Talk:OpenRailwayMap/Tagging_in_North_America ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Heavily-wooded residential polygons
Mateusz Konieczny writes: "OSM is not a place to map property rights. And landuse=residential is certainly not a tool for mapping boundaries of owned areas or property right boundaries." I don't wish to start an argument, and I ask with all the politeness I can muster, but Mateusz, how can you be so sure? Quoting our wiki, "land use...describes what an area of land is used for e.g. housing..., etc." On the land that property owners own, and live on, can you truly say they are not "using the entirety of their land for residential purposes?" Of course, some of that might have a house or apartment building, but the rest of it, is that land not also residential? I believe it is. I am not alone. You might be conflating these areas with the "property rights" of the owners/residents, as I did bring that phrase into the conversation. But what else would we call "the remainder of land which is used for residential purposes which does not strictly contain the footprint of a building (hut, apartment, tent, hogan, mud daub dwelling)?" Something other than residential? It is residential! SteveA ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] admin_level and COGs, MPOs, SPDs, Home Rule
Bill Ricker, this is in regards to your comment "Ward and Precinct not having elective officers nor staff of government, but are accepted as admin_level=9 and 10 respectively; likewise Neighborhood admin_level=10, Unincorporated community admin_level=8 need not have officers nor staff." It may be that in some parts of the USA (especially New England, where ward and precinct seem more prevalent than elsewhere), these are better characterized not as boundary=administrative (the tag paired with admin_level), but rather boundary=political. Considering the thread topic as germane to this discussion in a "more major" way, I'd call wards and precinct being retagged as boundary=political "more minor" — not AS important, but data still important enough to further discuss and possibly change (their boundary tags to the value "political"). Maybe one of us will start such a talk-us thread, but I don't have quite that much patience for the topic right now, especially as we continue to discuss admin_level at the county level. So, yes, thank you for sharing your observations about these more-political and less-administrative entities we now map and perhaps might map with tags we agree are more accurate (or not). The topics are rich and complex, indeed. SteveA ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] admin_level and COGs, MPOs, SPDs, Home Rule
Thank you Bill Ricker for the deep, thoughtful and researched background and weigh-in on Connecticut and Rhode Island county status. I'm now leaning in the direction of Greg Troxel that Rhode Island may indeed have counties which are administrative, though I withhold my final judgement (and it is solely mine, which shouldn't influence all of OSM that much) for the present time. Again, it is only Rhode Island which does not have counties tagged admin_level=6, the other 49 states do. (Mass. didn't for a week or so in May during a dispute, that has been remedied). Thank you Greg Troxel for thoughtful weigh-in, too. I agree it is important to recognize that "the federal government recognizes counties" (for "everything") and uses FIPS codes "for everything," however, I'll also point out that OSM has, for some time, made distinctions between what the federal government does (in the guise of the Census Bureau, for example, and so mentioned on the United States admin_level wiki) and what OSM does. Most of the time (CCCs, Independent Cities...) what OSM does w.r.t. admin_level and what the Census Bureau does more-or-less harmonize. Some of the time (the further division of Alaska's Unorganized Borough into counties, what the Census Bureau does, versus census tracts, as OSM does, how the District of Columbia is not called a "county equivalent" but instead gets admin_level=4 while the contiguous city of Washington gets admin_level=8...) OSM and the federal government do not harmonize. Indeed, as has already been mentioned, the federal government even disagrees with itself: one bureau says USVI has two subdivisions (as county equivalents), another federal department (USGS) says USVI has three (as distinct islands), so "take your pick" (two or three?) Honestly, I'm not trying to stir up muck or make trouble, rather I have striven mightily to get as much understanding and agreement as possible where, when and how it can be. While Mass. and Conn. seem to (now) be "solved issues" (DO include admin_level=6 on county boundaries, much to do with "local support"), Rhode Island continues to remain under discussion (though it seems like it is tipping towards "let's make it 50 out of 50"). As I read Greg's "let's not make our map awkward for our downstream users" (and indeed I have heard this before, for example as part of Mashin's argument for why COGs should be tagged with admin_level, still disagreeable and not done in OSM), I must say how that seems to fly in the face of (disagree with) the notion that we "map accurately what is." As I have said before, I honestly don't think we want to shoehorn something that isn't something into a box that says it is. Especially when we have plastic tagging (we do; boundary=COG is a good example). If this means a bit of extra logic, code or providing for a data exception, reducing the "clean, easy" path of code and data parsing, well, that might seem unfortunate, but it does mean that our important tenet of wanting our map to be "truly data accurate" (or as much so as possible) is closer to reality. I certainly see both sides of this, but there are two sides and I'm not sure which is more important: convenience or accuracy. I lean towards accuracy, that is simply me (and my nature). Others are welcome to disagree, which means some discussion must continue. Honestly, I think the discussion is productive, provided we remain civil, and we're doing a good job so far, imo. SteveA ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Heavily-wooded residential polygons
On Jun 2, 2020, at 1:25 PM, Joseph Eisenberg wrote: > > should the entirety of the underlying area be tagged landuse=farmland or > > landuse=residential? > > Neither: just tag the areas that are used for residences as > landuse=residential, and the area used for farming (mostly crops) as > landuse=farmland. I can certainly appreciate how this is an easy suggestion from the author of a renderer, but it diminishes from our map the extent of property rights of the owner of the residence / farmland. I don't want to do that, I don't believe others want to, either. > In OpenStreetMap we want to map what is actually there, not the zoning or > legal landuse or property boundaries. What is actually there are property rights, which is what I take as the meaning of "landuse=residential." If you saying I don't have "landuse=residential" on property I own which I simply (but AM) using to "enjoy the trees from my backyard deck," I'd say you are diminishing from our map (and by extension, a representation of property owners' actual land use) actual landuse. Why would you suggest we do that? Property rights can't be seen from satellite imagery, but that doesn't mean they aren't there. > This might change next year, just like an unmown meadow may change back into > scrubland, and then eventually into woodland, or how a river will meander > over time. No, people own land for many years or decades, with property lines seldom changing anywhere near as radically as Mother Nature. > Map what is there in reality right now, to your best ability. If people want > to know the legal zoning or property boundaries there are plenty of data > sources for that information, but OpenStreetMap is valueable because it > provides local knowledge of what is really there. The "land, as it is being used, residentially" (denoted in OSM as landuse=residential) is really there, so I do. SteveA ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Heavily-wooded residential polygons
Mateusz Konieczny wrote: > I think that it is not a good assumption. One may have a property boundary > that is partially landuse=residential and partially > landuse=industrial/farmland I have mentioned before that the values OSM documents for the landuse key, while good, are incomplete with the great richness by which the world recognizes and categorizes these. Here, Mateusz mentions a "triple" where residential, industrial and farmland exist together (or perhaps "double" where the latter two are blended, a certain kind of "single" activity, so when the residence is added, this makes two distinct landuses in total). I myself have mentioned what are locally known as "residential / agricultural" areas, which I characterize as a "live on family farm." These consist of a residence (house) and small (one to ten hectares) or medium-to-large (ten hectares and larger) areas where a wide variety of agriculture either can or might take place. Some areas are substantially tree-covered and give rise to wild mushroom gathering, what I am told is a "fruits of the forest" activity, not "farmland." On these (especially in clearings, grassland/meadow areas), I often find landuse=greenhouse_horticulture, landuse=orchard and landuse=vineyard areas which "crop up" and appear in imagery. Because OSM has specific tags for these, I tag them as I see them. However, should the entirety of the underlying area be tagged landuse=farmland or landuse=residential? The truth is, "they are both," but OSM hasn't a landuse=live_on_family_farm_that_gives_rise_to_tree-planting_viticulture_and_hothouses tag. Getting the entirety of the world to agree upon values which seem very highly locally-dependent and articulated seems difficult. The alternative is to have our renderers only approximate the tagging mappers are encouraged to "shoehorn" into, given these many, often subtle, landuse distinctions. Another complicating factor is "actual landuse" vs. "potential landuse," (does take place vs. can or might take place) where some say to "tag only what is actual." Others see this approach as a removal of land rights, further muddying what OSM means by landuse. These issues truly are complicated, I believe it is easy to agree. SteveA ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] admin_level and COGs, MPOs, SPDs, Home Rule
The way it is now (I believe) is that Connecticut counties "exist" in OSM as expected, tagged boundary=administrative + admin_level=6. Additionally, (thanks to Mashin's entry, I believe) Connecticut has "Regional COGs" tagged boundary=COG (with no admin_level tag, as that key associates with boundary=administrative, never with boundary="any value besides administrative"). This wasn't true for a while (days to a week or two) in May during a dispute about Mashin's entry of COGs, but (thanks to some good dialog and diplomacy by Minh), now the above seems to be a widely-agreed upon consensus, by locals and this Californian alike. The reasoning behind this is both "the locals say it is this way" as well as "some minor aspects of government, like judiciary, district attorney and possibly sheriff area boundaries do exist at the county level, so they are administrative, but to a lesser degree than other states, so these ARE admin_level=6 nonetheless." This is approximately the same in the eight (out of 14) counties in Massachusetts where it is said that "these counties have limited to no government:" local consensus and tagging is deliberate to the extent that all 14 counties in the state are tagged boundary=administrative + admin_level=6. However, in Rhode Island (and this is the only state in 50 where this is true), counties are tagged boundary=region, border_type=county, with no admin_level key with any value whatsoever on county boundaries. This is based upon there being no governmental / administrative functions at this "level," counties are said to be essentially geographic, not political / governmental / administrative areas. If there remains a lack of clarity or disagreement about these topics to anybody, now seems to be a good time and place to express it. SteveA ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Heavily-wooded residential polygons
On Jun 2, 2020, at 4:11 AM, Greg Troxel wrote: > stevea writes: >> ...we ask the wider community "what do you think?" and "What are best >> practices here?" > > Agreed this is really hard. I'm heartened to hear others share not necessarily only frustration, but even some difficulty in articulating the issues! > First, I'm going to assume that polygons for landuse=residential do or > are intended to align with property boundaries. I'm also going to > assume that natural=wood aligns with the actual location of trees, which > is (in mass) almost always not aligned with property boundaries. I have > thought it an error to have natural=wood tagged on a polygon that shows > conservation land, as the adjacent non-conservation land almost always > similarly has trees (around me). Yes, I speak locally (in my county, based on the landuse polygons that have been entered into OSM for over a decade), the (multi)polygons tagged landuse=residential are aligned with property boundaries of residential parcels, agglomerated into a single datum (the polygon), not individual parcels. In my very strong opinion (and others in OSM have told me they agree), OSM absolutely wants these polygons, as they define "this IS residential landuse." (Not COULD BE, but IS). Yes, this land might be "natural" now, including being "treed," but I could still build a patio and bbq there after perhaps cutting down some trees, it is my residential land and I am allowed to do that, meaning it has residential use, even if it is "unimproved" presently. These facts do add to the difficulty: OSM doesn't wish to appear to be removing property rights from residential landowners (by diminishing landuse=residential areas), but at the same time, significant portions of these areas do remain in a natural state, while distinctly and presently "having" residential landuse. For example, I can visually enjoy my trees and creek from my backyard deck, even as they remain natural, this IS (not COULD BE) a residential landuse. (An important one I don't believe OSM wants to remove from the map data). > I would suggest that perhaps a "this land has some trees" landcover tag > (cover != use, strongly agreed) may make sense. I am not sure you are > talking about this, or not. I find natural=wood to imply that the land > has none to very little built structures, mostly trees, and the usual > understory plants. I would definitely not want to use this tag on an > landuse=residential area with houses, but I might use it on the rear > parts of a housing area that are basically trees. I also would not > want to stop at the subdivision line. We agree. The issues are both around the different behavior of the (Carto) renderer when both landuse=residential and natural=wood are combined (and there are highly complex ways they can be and are "combined" in the OSM database), and around how mappers understand these data should be entered. Should both natural=wood and landuse=residential be "stacked" as two tags on one (multi)polygon? That was and is widely done in cases where heavily-wooded residential polygons exist, though a "better" trend (at least around here) is to break these apart into two polygons: one explicitly on the landuse=residential polygon (glom of parcels which are residential, to the area extent where they are), one on the polygon defining the extent of natural=wood. This has the added benefit of allowing much finer detail on where the actual wooded extents are, as making these distinctions are important to the map as well as to many mappers. Unfortunately, Carto doesn't easily (it does consistently, but the rules are complex, having to do with sizes of the underlying polygons) render these consistently, requiring frequent "fiddling" by craft mappers who are looking for both a desired effect and a visual semiotic which richly and accurately conveys what is going on: heavily wooded residential landuse. > The basic problem here is that it's pretty straightforward to render a > map that primarily shows landuse, and it's pretty straightforward to > render a map tha primarily shows landcover. What carto does, and what a > lot of people want, is a way to show both of them. I wouldn't necessarily call it a "basic problem," more like the desire of "let Carto display both" doing so in complex ways, which gives rise to "well, what are the best practices here?" > I would suggest that if tagging heroics are needed there is something > suboptimal in the renderer. I think renderers probably need fancier > code to choose which of landuse/landcover to emphasisize depending on > local scale. Or a deconfliction of symbology. Yes, heroics are sometimes employed, yet even th
Re: [Talk-us] Heavily-wooded residential polygons
It sounds like we are all on a "broad mind" of "channel what is known locally about land-use, deeply." That is many different things around the world. Let us keep a very open mind about how we characterize and categorize. These are deep and difficult topics. SteveA ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Heavily-wooded residential polygons
Mateusz Konieczny writes: > (quoting stevea) "treed farmland" or "heavily wooded residential" prove slightly problematic to OSM tagging. Then, Mateusz Konieczny answers: > Map tree-covered area (landuse=forest) and map farmland (landuse=farmland) or > residential (landuse=residential). Yes, the same area may be tree covered > and residential at the same time. If only it were this simple, it appears not to be. "Tree covered area" can be either landuse=forest (OSM's wiki defines something like a half-dozed different conventions on how we actually tag this) OR it can be natural=wood. Very roughly stated, what _I_ do (as I see other California and USA-based users doing this — I'm not trying to invent a new tagging method) is to map distinctly "timber production" areas as landuse=forest and distinctly "appears to be wooded — whether pristine and ancient never-cut forest I don't necessarily know — as natural=wood. That is for starters and only attempts to start from a point of "visible trees" (as in imagery) while only leaning in the direction of landuse in the aspect of landuse=forest being "it is well-known that this is an area which is either actively forested, or has the right to have its trees felled" (timber permits, owned by a logging company, CAN be cut but maybe are still growing to maturity, MIGHT be cut but could also be deeded by owner later on to become conservation or land trust protected area...). The possibilities are myriad, but OSM does a "fair to good" job of characterizing these, and with only two tags, forest and wood. This isn't perfect nor is the consensus about how we do it, so that aspect alone complicates this question, while at least providing SOME stability of understanding the complex semantics. THEN there is the aspect of ALSO-has-a-residential-aspect (or perhaps PRIMARILY does). Clearly, a 10 hectare / 25 acre parcel which is 98% trees and 2% house, garage, a small clearing and a driveway for access is something quite different than natural=wood (as far as its residential landuse goes). However, it might not be all that different than a landuse=forest, ESPECIALLY if the residential land owner also has a timber permit to cut trees (possible, though not necessarily common, at least around here). Regarding farmland, this has also been discussed many times, especially about Santa Cruz County (see that topic's wiki, the fifth paragraph of the "Work to be done in the County" section). Briefly, misunderstandings happen because around here, we have areas which are zoned farmland, (and are actually areas of — among other agricultural activities — beekeeping, wild mushroom harvesting, herb-crafting for essential oils, other unusual but certainly agricultural production) but also have significant tree-cover, which may or may not be permitted for felling timber. That is a whole lot of complexity to shoehorn into a couple-few simple tagging "rules." (Or even "guidelines"). Two "admonishments" in that county-level wiki are offered to prevent misunderstandings: one is that "farmland isn't simply row crops" and the second is to read the definition of what our landuse=farmland wiki says (about "tillage," for example). When both local zoning says "agricultural" and some activity like wildcrafting herbs to harvest essential oils both meet the definition of what I and others agree is "landuse=farmland," I tag these landuse=farmland. These topics are complicated. If we need more tags to better differentiate (I believe we do), let's coin them (with discussion and consensus, of course). For example, locally, we distinguish between "Commercial Agricultural" (row crops), what most people would certainly agree is classically landuse=farmland, but we also have "Residential Agricultural," or what might be termed "a live-on family farm" which includes a residence / house and significant land, a large amount of which might be "treed," with 0% row crops, but allows (and actually develops) into orchards, vineyards, greenhouse_horticulture. Indeed, I have tagged exactly those three latter tags on sub-polygons where I see them (as they are distinct tags in OSM), but in essence, it is 100% correct to tag the whole area landuse=farmland on the entire polygon (in my opinion), even though it is "also" residential. OSM does not have "landuse=live-on-family-farm" as a tag, maybe we should better develop something like this and these. > Yes, the same area may be tree covered and residential at the same time. Yet, Mateusz, you don't say exactly how to tag these. And (multi)polygons which describe them ARE (I know it, Doug knows it, many know it) and can be exceedingly complex structures to "get them right.
[Talk-us] Heavily-wooded residential polygons
Fellow OSMer doug_sfba maps natural=wood edges around the southern and western areas of Silicon Valley (the South Bay Area in California), among other mapping and places. I map similar things a bit further south, with initial emphasis on landuse, but as I sometimes combined natural tags in the same polygon, I now tend — as "more correct" — towards breaking these into two polygons, this is a fair bit of work. Doug and I have collaborated a lot, and agree (among other things) that in OSM, there is a distinction between landUSE and landCOVER. For example, "treed farmland" or "heavily wooded residential" prove slightly problematic to OSM tagging. Due to complex tagging schemes on complex (multi)polygon construction (sometimes half-jokingly referred to as "higher math," though it is more like discrete math, topology and possibly its concept of "genus" or "holes in a complex surface") this can result in quite different results in the Carto renderer. Recently, Doug and I discussed that Carto, areas of "heavily wooded residential" render with three possibilities, depending on some complex tagging strategies and the sizes of the underlying (multi)polygons: • "fully gray," indicating pure residential, but leaving the human viewing Carto no indication the area is heavily wooded, • "fully green-with-trees" (as natural=wood), which excludes the important aspect that while wooded, this is residential, or • "gray with superimposed trees" (in both our opinions, a superior and pleasing method to display "heavily wooded residential"). For an example of the latter, see https://www.osm.org/query?lat=37.3769=-122.2506#map=15/37.3873/-122.2526 and notice the residential areas surrounding Thornewood Open Space Preserve. As I mentioned to Doug I exchanged a couple of emails with user:jeisenberg (a principal contributor to Carto) about what was going on with some examples of this, and Mr. Eisenberg explained to me (in short) that it is a complicated ordering (or re-ordering) of layers issue, both Doug and I continue to scratch our heads about what "best practice" might be here. (For "heavily wooded residential" polygons, which are frequent in Northern California). While Doug and I both tend towards the preference of the "superimposed look," it is not always simple to achieve, due to complexities in the renderer and data/tagging dependencies. And, Doug and I are certainly aware of "don't code for the renderer." However, given that Doug and I are fairly certain that others have noticed this, but aren't certain that others know what best to do (we don't, either), we ask the wider community "what do you think?" and "What are best practices here?" Yes, the questions are a bit fuzzy and it is difficult to describe what is going on in the renderer (ordering or re-ordering of layers depending on size, I believe), but it does seem like we might be able to agree upon a best practice of "what to do." In short, Doug and I both strive to "tag accurately," but just as "9" can be 5+4 or 6+3, there are many methods to combine and build polygons to describe an area and tag them accurately, though many combinations render differently. This is being sent to both talk-us and the tagging list, where I think the latter may be a better place, but this was noticed by a couple of California mappers (for some time), so including talk-us might help widen the audience to include others who have noticed these anomalies. Thank you in advance for good discussion. SteveA California ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] admin_level and COGs, MPOs, SPDs, Home Rule
Due to some discussion between Minh, Martin and I on the Talk page of United States admin_level, we seemed to agree that restoring admin_level=6 to Connecticut counties is reasonable. I did so, and made minor changes to the wiki to outline why. SteveA ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] admin_level and COGs, MPOs, SPDs, Home Rule
you want to enter the haunted South County!" on my cool map? Tag as we say we should (and more-or-less do). You might be confusing what you see in a rendering (Carto, your own renderer, perhaps)...) with the data in the map. Simply because a renderer doesn't map boundary=region doesn't mean it isn't there (in the database). It is, it renders differently (or even not at all). These are often hashed out topics (for 15 year olds, for adults) about digital map production. I don't mind talking about them again, though because renderers change, laws change, better/newer tagging schemes sometimes emerge, they almost MUST be talked about every so often. We're simply discussing. I strive mightily to keep my mind open and not seem autocratic and having an attitude of "I'm certain I am right." We all should. But let's also acknowledge that things change and emerge in OSM and we still seem to need to fine-tune middle-level admin_levels in parts of New England. I'm OK with that, but my patience wears thin. It doesn't make me mad at anyone in particular for that, just, um, tired of typing so much. SteveA ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] admin_level and COGs, MPOs, SPDs, Home Rule
notion of knowing which county you are in, even if > >> they don't collect taxes and have employees. Whether and how OSM maps a county isn't determined by what you or a number of people believe. It is determined by political realities and established tagging standards, sometimes requiring carefully-crafted consensus, which here we have largely achieved. If you want to change this, make an argument as described in the Discussion page of the relevant wiki. This includes addressing Home Rule and Dillon's Rule, not repeatedly exhorting "your beliefs." > We in the Massachusetts local community want to have admin_level 6 > relations for these boundaries, and I personally consider deleting them > to be vandalism. Then let's hear from them and their rather precisely-described to-become arguments, rather than you and your beliefs (nor me and my repetitions of these). Saying that a dozen of you believe 2 + 2 = 5 (especially as 11 other voices aren't present) doesn't make it so. Cogent, scholarly, well-presented arguments that address the salient political and legal topics described (in the wiki page, where this more properly belongs, though I'm glad it's getting a hopefully final gasp of exposure here) might be able to describe why 2 + 2 might look like 5, in a certain way, in Connecticut, because of x, y and z. But nobody is hearing that and nobody but user:Mashin is saying so. (At least in wiki and talk-us. Slack? That's proprietary. I avoid secret-sauce walkie-talkies in an open data project, but that's me. I do hear that people use it to communicate, I wouldn't know what's on it). SteveA ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] admin_level and COGs, MPOs, SPDs, Home Rule
Thank you, Kevin. And so it goes. I'll be an observer for a while. SteveA ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] admin_level and COGs, MPOs, SPDs, Home Rule
On May 8, 2020, at 12:09 PM, Greg Troxel wrote: > My point is that in Massachusetts, counties are real in that the > government expects you to know what county you are in, and there are > signs. Many state government functions are lined up with these counties > - it's just that the people are state employees instead. The federal > government believes in counties - they are used to organize lots of > things even if the counties have no taxing and spending. So they really > are a political subdivision, even if they have zero government > functions. > > We in the Massachusetts local community want to have admin_level 6 > relations for these boundaries, and I personally consider deleting them > to be vandalism. I'm not in Massachusetts, but as I constantly strive to improve my listening skills, so I ask you to please point out any flaws in my understanding of this. I'm literally quoting from Footnote 18: "Geographically divided into 14 counties, Massachusetts effectively has no county government in eight of them, similar to Rhode Island. This means in these eight counties (Berkshire, Essex, Franklin, Hampden, Hampshire, Middlesex, Suffolk and Worcester), all government administration is at state (4) and local (8, 9) levels. However, several functions implemented by the state are organized by county lines, including District Attorney, Sheriff and the judiciary." I believe the six counties WITH "county government" deserve boundary=administrative, admin_level=6. I believe the eight counties WITHOUT "county government" deserve border_type=county (and no admin_level key-value pair whatsoever). I wholeheartedly agree with you that removing / deleting / altering the "county boundaries" (and there are two kinds, as our wiki and I describe them here) besides these tagging schemes is vandalism. The federal government certainly does "believe in" counties, it (via the Census Bureau, USGS and other agencies that refer to them) categorizes them in sometimes slightly-different ways than OSM does. (We say so in our wiki, and why, and point out that we also align with the Census Bureau in certain circumstances, like CCCs, for the most part). It also describes many other "things" (like Census County Divisions and many flavors of Statistical Areas) which OSM happily ignores. In fact, the federal government even disagrees with itself: the Census Bureau and USGS divide the USVI into either two or three county-equivalents (take your pick). So, OSM must make its own decisions, based on its own definitions. Often, OSM and the federal government agree on these things. Sometimes, not quite. That's OK, especially as we recognize this, point it out and explain why. I think we do OK here. The distinctions can be subtle, but they are explainable, so we do. Wow, people still have patience to discuss this! SteveA ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] admin_level and COGs, MPOs, SPDs, Home Rule
COGs" (councils of town governments with strictly limited function, like landuse planning), then in 2014 reduced these to 9 RCOGs. Do COGs (MPOs, SPDs...) in OTHER states (besides Connecticut) deserve boundary=administrative (and hence admin_level)? No, I think that is a settled question (as of summer 2017); these deserve boundary=COG (MPO, SPD...). Do RCOGs (or COGs) in Connecticut deserve boundary=administrative? I personally think not (and our wiki reflects that, despite Mashin's "case closed" to the contrary). However, for Mashin's benefit (and the greater good of the truth of what OSM should BEST do), I invite more-scholarly (as I think we need it) political science-based further Discussion. I've "run out of intellectual gas" and that's the best I can suggest beyond my limitations. > We also have the concept of ward and precinct as admin_levels, and I > have never seen these entities have any government functions. They are > simply boundaries that determine how votes are counted or which poling > place you go to. If they are legit as admin_levels, then counties with > no government are much more legit. There are boundary=political taggings (I think) which I believe are more-appropriate for things like voting districts. I would very much like us to sharpen up these distinctions, too. But that might be "minor" considering what I'd say is a more-major issue of RCOGs in Connecticut (as a perhaps-one-off exception to "no COGs as administrative," as perhaps being county-less makes this a quirky something-else that IS administrative, I really don't know, but I invite further Discussion). >> Please, put the boundary in the map if you must and tag it >> boundary=COG and let's be done, please. No admin_level value at all, >> unless we can tolerate seemingly endless discussion and maybe some >> heated argument, too. > > That's a very good plan. Thank you very much for saying so! > The basic issue here is that admin_level has to have a clear hierarchy, > and once you talk about 12 kinds of regional things, that is clearly not > possible. Yes: I refer to calling Connecticut RCOGs as administrative "letting a genie out of a bottle," as then we have a rainbow of not-really-full-spectrum governments (federal=2, state=4, county=6, city=8 ARE "full-spectrum") that need careful categorization by political scientists savvy about how admin_level both works and is supposed to work. That is a can of worms. Maybe somebody wants to work on that, I have about reached my limits. Many others who express impatience have, too. If there is an argument to be made that Connecticut RCOGs "have a clear hierarchy," Mashin has (only begun, in my opinion) to make it and it needs to be FURTHERED by addressing the "limited powers" aspects of these RCOGs. That is a wholly unspoken conversation, and so, (to quote the Soup Nazi): "no admin_level for you." Maybe in the future with (currently, unmade) supporting arguments, but "not today." If you've read this far, I deeply thank your patience with this topic. SteveA ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] admin_level and COGs, MPOs, SPDs, Home Rule
Our wiki is a vital source of reference and "how to." It deserves the very best effort we can give it. Sometimes, especially with a complex topic where local knowledge matters, yet so also does learned, scholarly perspective, a Discussion page gets wordy and detailed. I do believe OSM wants to get this page as "right" as it can. Minh and I agree there can be "multiple books in the library about (roughly) one subject;" the wiki he started on Boundaries is "more descriptive"while this one is "more prescriptive." We walk a careful edge. There are some crafted boundaries (heh) of syntax and semantics. Let's build upon what we've built (with some effort). Greg, the sort of COG Connecticut has built (an RCOG) is unique as "COG entity in a state with no counties." There are also COGs in states with counties and I temporarily assume perhaps in states with townships, though I can't offer immediately a concrete example. I don't know what numerical value of admin_level we would begin to assign to these (we shouldn't assign any, imho, and it seems your opinion, too), I have heard 5, 5.5. 6 and 7. "Collisions with existing," hence 5.5. We started to do this with CDPs at 8 and backed that out: they're not these. Please, put the boundary in the map if you must and tag it boundary=COG and let's be done, please. No admin_level value at all, unless we can tolerate seemingly endless discussion and maybe some heated argument, too. Clifford hasn't the patience as loudly and clearly, patience is wearing thin. If we must continue, let's be careful to keep it civil and scholarly if we can. And shorter. Paul's mentioning of COGs in Oregon reminds me the decision didn't go over well (years ago) with many in Oregon, who rather strongly feel their COGs should have an admin_level value, though I'm not sure any numerical value revealed itself. I made a call for an expert in Oregon's Blue Book to chime in; nothing. (There are "collisions" in the number space with 5, 6 and 7 in other states). If we let this genie out of this bottle, poof, we suddenly have a rainbow of values and state-specific up-and-down-the-hierarchy relationships between brand new things that need pigeon-holing we don't need to do: these already have names and a tagging scheme (boundary=COG). Maybe that's OK, maybe admin_level wasn't meant to be "beaten up" like that. I don't look forward to participating in those discussions, that's for sure. It's manageable, it takes some words and time to slog through. Let's keep that trimmed well. SteveA > On May 7, 2020, at 6:07 PM, Greg Troxel wrote: > For what it's worth, I live in Massachusetts, which is next to > Connecticut, and generally pay attention. I have aboslutely zero idea > what a COG/MPO is, but I think admin_level belongs on state/county/town > and things that pretty much everybody recognizes as admininstrative > subdivisions. There are school districts, sewer districts, historical > districts, and a ton of other things, that are something else. > > I do fear for the future of OSM that wiki editing is such a big thing. ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] admin_level and COGs, MPOs, SPDs, Home Rule
On May 7, 2020, at 5:32 AM, Clifford Snow wrote: > Steve, > I don't have the patience to put up with discussions about admin levels. As > you know they can drag on forever. I did post a link to the discussion on the > Connecticut Slack channel. Maybe that will get more people involved. > > Good luck, > Clifford I appreciate the Slack post, I appreciate your wish for good luck, I appreciate you reminding us that patience can quickly wear thin regarding OSM admin_level discussions. Indeed, they can frequently use good luck. SteveA ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] admin_level and COGs, MPOs, SPDs, Home Rule
If you fancy yourself (or know one!) a political scientist steeped enough in US law, history and politics sufficient to discuss subtle, nuanced topics like Home Rule and Dillon's law, a Discussion in our wiki could use your wisdom and guidance. As the OSM community in USA discussed boundary=administrative at length in 2017, admin_level got "mostly" hashed out, with a "settled" consensus about COGs, MPOs, SPDs and their ilk. (Briefly, admin_level=2 federal, 4 state, 6 county and 8 city/town are rough rungs, 7 emerged for townships and 5 is the multi-county glom-of-6s New York City, OSM's only 5 in the USA). But COGs/MPOs/SPDs and their ilk stuck in many craws and apparently is difficult for some, even many. The topic is active again at https://wiki.osm.org/wiki/Talk:United_States_admin_level#Recently_added_Connecticut_COG_.28Regions.29_as_5_and_CDP_as_10_should_be_deleted and seems to need the assistance of seasoned political scientists who can say whether a COG in Connecticut, for example, is "a government" or not. (I say a COG/MPO is a LIMITED government, like a sewer district, so isn't "really" a "full spectrum" government, therefore shouldn't get an admin_level value, as this key associates with boundary=administrative). Some Wikipedia links to "Home Rule in the USA" and "Dillon's Rule" are clickable at the end of that long Discussion, then I "run out of intellectual gas." Please help this Discussion if you have this sort of knowledge / wisdom to contribute. Thank you, SteveA California ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] United States Bicycle Route System ballots pending AASHTO approval
Bicycling-specific renderers (cyclosm, opencyclemap at z>8...) begin to render these national proposed routes. Thanks not only to Kerry, states (Departments of Transportation), AASHTO, volunteers on the ground, some of whom erect signs among other efforts, Harald and Bradley, but to many others who endeavor to bring these routes and this system to OSM and the world. AASHTO may approve these, in which case OSM removes the state=proposed tag. It all works! SteveA ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] United States Bicycle Route System ballots pending AASHTO approval
SteveA ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] United States Bicycle Route System ballots pending AASHTO approval
I just finished entering the last 15% - 20% of USBR 50 in California as a "first draft" into OSM. Thanks for entering the first 80% or so, Bradley: teamwork! SteveA ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] United States Bicycle Route System ballots pending AASHTO approval
It looks pretty good from here, Harald. I did a quick "click the sort button in the relation editor" (I edit with JOSM) and that seemed to "neaten things up" a bit. Thanks for some pretty heavy lifting in Wisconsin: this isn't a short route! Many hands make light work (in a crowdsourced map, especially), SteveA > On Apr 15, 2020, at 6:47 AM, Harald Kliems wrote: > > I'm happy to report that the proposed WI segment of USBR 30 is complete now. > My route relation skills are a little rusty, and so it's possible that some > of the forward/backward sections may have QC issues, but based on what I saw > in JOSM's route editor, things look pretty good. If anybody has the time, a > quick check would be appreciated. > https://osmrm.openstreetmap.de/relation.jsp?id=3346668 > I'll get the USBR 230 segment up in the next couple of days. > Harald (hobbesvsboyle) ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] United States Bicycle Route System ballots pending AASHTO approval
Of course, my recent introduction of three PROPOSED routes to the USBRS left out the word "proposed." My apologies. If/as the routes are approved by AASHTO later this year, we may remove the "state=proposed" tag and move them in the wiki from the Proposed section to the Approved section. Just dotting my is and crossing my ts. And thank you both Harald (for asking around) and Bradley for terrific progress on USBR 50 in California! SteveA ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] United States Bicycle Route System ballots pending AASHTO approval
There are at least three new national bicycle routes in the USBRS! To help OSM "get ahead of the curve" of the May 2020 Spring AASHTO ballot (may not be completed until June / July this year), USBR applications by state DOTs are available, allowing OSM to enter these state-at-a-time national bicycle route data. Currently, USBR 30 in Wisconsin, USBR 230 in Wisconsin and USBR 50 in California have been "seeded" as route relations and need to be fully entered into OSM. Please visit our wiki https://wiki.osm.org/wiki/United_States_Bicycle_Route_System#Proposed_USBRs_in_OSM for links to the route data ballots. OSM-US has explicit permission to enter these. If you're in Wisconsin, please contact user:hobbesvsboyle via OSM missive to coordinate entry of USBRs 30 and 230 into OSM. If you are in California (or even if not!) and want to enter USBR 50, helping to build Earth's largest official cycling route network, check out our wiki, follow the links to the turn-by-turn and map data and have fun! SteveA California USBRS-in-OSM guy (among other hats I wear) ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] Restructuring a state rail wiki
USA rail mappers (and wiki authors): As our wiki California/Railroads grows (and grows and grows...) I believe it has gotten to the point of "too big and unwieldy" as it nears completing late(r) beta and heads to a finish line of "about 1.0." I've been considering re-structuring this for some time, but as it would be a first (for USA rail wiki pages) I'd like some feedback in case there might be a better way to do this I haven't thought of. If interested, please see https://wiki.osm.org/wiki/Talk:California/Railroads for the further discussion. Thanks, SteveA ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Railway improvements; stations vs. halts
> Clay Smalley wrote: > Thanks, all. This pretty much confirms what I expected. I'll go ahead and > bring them back to railway=station. Clay, I know it is an extra ask, I request that you document how you're doing this at (minimally): https://wiki.osm.org/wiki/Tag:railway%3Dhalt#Distinction_Between_Halt_and_Station and https://wiki.osm.org/wiki/OpenRailwayMap/Tagging#Stations_.2F_Stops with the usual "In North America..." distinction text that is similarly sprinkled around the latter. I'd consider it optional (though courteous) to find a place to add this to: https://wiki.osm.org/wiki/United_States/Railways and https://wiki.osm.org/wiki/OpenRailwayMap/Tagging_in_North_America although I leave how and where exactly (or even whether you do so) up to you. Thank you, SteveA ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Railway improvements; stations vs. halts
I forgot to mention that I have also directly edited the OpenRailwayMap/Tagging wiki itself by sprinkling several "In North America..." text blurbs. These are nearly always left intact by other wiki reviewers (and that page is very well watched and heavily/strictly "policed" for accuracy). Finally, you could also add a similar "In North America..." text blurb directly to https://wiki.osm.org/wiki/Tag:railway%3Dhalt#Distinction_Between_Halt_and_Station (there is already one bullet point that is specific to Germany). SteveA ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
