Yes, a somewhat-strong tenet of OSM is "don't tag for the renderer" (osm.wiki/Tagging_for_the_renderer) but since these are vast areas (30% of the USA land mass, by one estimate), a bit of a wink and a nod seems to be acceptable (I think it rather stinks and hold my nose, wishing this sort of tagging didn't happen) and these sorts of gyrations are done.

For example, I sincerely believe that adding a leisure=nature_reserve to a Wilderness is technically incorrect, yet I know many do exactly that. WHen you say "standardizing" there really is no such thing, simply this opinion vs. that opinion.

Honestly, the sooner (the better) for Carto to start to render boundary=protected_area (though the myriad protect_class values make this difficult: look how much wrangling goes on to simply render boundary=aboriginal_lands in a single color).

And this: osm.wiki/US_Forest_Service_Data#Wilderness_Boundaries says to tag the way I tag, so I understand the confusion.

OK, I found your assertion of type=multipolygon to be true (all 26 in this changeset are, but not all protected_areas across the country are), so I left that tag there, because it is true for these. I also conflated relation/70010 into 70986, because they are the same entity.

However, rather than changing all of the entities in this changeset (and indeed all of the USA) from boundary=national_park to boundary=protected_area (and assuring there is also the correct "paired tag" with that of protect_class=6), I'll wait for the Carto folks to better render boundary=protected_area. (There is a move to get the recently "vote approved" boundary=aboriginal_lands rendered in Carto, for example, so render work for these keys does slowly improve). I would like to see deleted on all 26 relations here the boundary:type key, as it is nonsensical and being deprecated, even though your source documents it (as a "red" key, meaning it has no wiki entry).

Summary: longer-term, national parks should be tagged boundary=national_park (as many/most are today) but other protected lands (like these national forests) should be tagged with boundary=protected_area + protect_class=6 as well as having their nonsensical and being-deprecated boundary:type tag removed.

Thanks for your quick reply.

Update: IF (and ONLY if) they are multipolygons (some are, some are not) set to type=multipolygon. Otherwise, correct tags are boundary=protected_area and protect_class=6 and removing boundary:type=protected_area.

Adam, national forests (part of the US Department of Agriculture) are not National Parks (part of the US Department of Interior). These should not be tagged boundary=multipolygon (period — that is reserved for the "type" key), they should be tagged boundary=protected_area + protect_class=6 and the boundary:type=protected_area key-value pair should be removed.

Please set tags on all 26 of these National Forests back to what they are supposed to be.

Thanks, I reverted these back to not being level crossings. This was an "automated" (all ten of them at once) Validator "Fix" that I rather blithely did at once without realizing they were down the middle of the street, but you're right.

Really? I'm OK with trees being named where they have a plaque and maybe a rememberance fund and maybe a bench. I entered a tree like that S of Stevenson Lower Quad about a km away. I don't think naming trees in East Field Parking Lot is that, though I'm willing to be enlightened. As fun as this might have been, please remove the names from these trees, unless they really, really have names.

The guy who entered the trees (unnamed, simply trees) in the first place.

Changed. Of course, you are welcome to make such changes, too; noted in our wiki (osm.wiki/Montana/Railroads) are both (about this rail spur) that "name is speculative" and in general, "improvements are welcome."

Actually, this sort of local knowledge is one of many things that makes OSM a GREAT map. Thank you for your improvements and again, you are welcome to make these yourself, though I appreciate the Changeset Comment as a polite way to call this to my attention.

Happy mapping / see you in the map,

Steve

Postscript: Gaia's topo web rendering of OSM data looks pretty nice!

I'm surprised you or I didn't get an edit conflict. That area is really "all kerb" (or curb as we Americans say) and there is no crossing there, whether on a node or a way, I deleted the way entirely!

As my comments used to say about this area/crossing before I deleted them and their parent ways/nodes, this really was a dangerous area for both cyclists AND pedestrians and the whole area being closed to nothing but automobile traffic is a much smarter and safer designation by the city/county/Caltrans.

I think between the two of us we now have it correct. Thanks again for your good communication.

stevea

Sensibly, the City of Santa Cruz has seen fit to put sharrows (cycleway=shared_lanes) on Fairmount Avenue, so this makes a reasonable connector to include in lcn 45 to get across the freeway at Branciforte Drive (which again, I've done thousands of times myself). It all makes sense now.

stevea

My turn for corrections to my previous:

The sign says "Pedestrians, bicycles an motor-driven cycles prohibited." This is a common sign in California at freeway entrances.

I should have said you"think" I "SHOULDN'T" copy from a County Bike Map, however I happen to know it is perfectly legal to do so.

It's all good.

stevea

I have lived and ridden my bike) in the area for decades, and always found this a "tricky" bicycle area. I have driven this overpass thousands of times and only two days ago noted that from Farimount for the entirety of the "trumpet interchange" (so-called by Caltrans engineers because of its shape) — even if you are a cyclist (or pedestrian) "exiting" at Rooney, as I often do to get to my house) now has a "Pedestrians, bicycles and motor-driven cycles" sign RIGHT THERE (for the overpass), just as you also find at the beginning of any freeway (like the Morrissey Blvd. entrance to Hwy 1 South next to it).

Accordingly, I have removed from this "trumpet" overpass its bicycle tags and the lcn/ref 45 from OSM.

I also appreciate that you "think" I should copy from a County Bike Map, however I happen to "know" that it is: the SCCRTC (I have attended literally dozens of Bicycle Committee Meetings there, and I live in the area under jurisdiction, so as a citizen I'm actually a ranking member there). There are multiple court cases upholding that data published by the state (and the county is a branch of state government) ESPECIALLY GIS data, are in the public domain. Plus, I am the author of the CycleNet numbering protocol proposal, for which we wait for the SCCRTC, its Bicycle Committee and the city jurisdictions affected (four, total) for final approvals.

Thank you for your comments, it really was two days ago I saw the new sign, and I was going to make this edit sometimes this week: your comment prompted me to do so!

stevea

You are welcome for clarification. Tubes needs to be seriously educated that OSM is not his personal rail playground (he is very coy about why he insists on entering rail with his often-metamorphosing odd/wrong methodologies) and if that doesn't "take" or "stick," I believe he should be shown the door.

Nope, @prefix is a Twitter thing I believe. When somebody isn't on Twitter (or social media completely), it doesn't do anything.

Call me old-fashioned (no, I'm not so old fashioned I insist on a hand-written letter sent by pony express with a postage stamp or even a fax), but I'll speak to you by phone (home office or cell), email you, missive you or a variety of other more secure (but not proprietary) methods. Those seem adequate, and we've had a nice back-and-forth here. Again, thanks.

Let's keep a close eye on Tanner.

Steve

Bryan, with this slippery character who uses at least three accounts (maybe more: ethylisocyanate, US Woods and now, Tubes), is disingenuous when I missive him, says one thing and does another, I would call this nice. This is my fourth or fifth attempt to contact him, after he broke off with me earlier this week, we've gone around and around for the better part of a year, he is vandalizing 95% to 98% correct data (hey, I know we'll get it to100% eventually, but I'll take a "solid A" while we do) for some odd pet project or obsession he has to "make USA rail in his own image." He seems to have technical skills, but lacks in OSM social skills of consensus while his actions appear to me to become more furtive, underhanded and actually destructive to valid OSM data, curated by many people here who "do it right," except for him.

As I quite deliberately don't use social media, addressing me as @stevea seems odd. You are welcome to call me Steve, refer to me as user:stevea, and in our wiki I am Stevea.

Thanks for your concern, but I am one step away from Reporting this person (his first name is Tanner, or so he tells me), something I have never done in nearly a decade of OSM volunteering. (As I really do my very best to be civil, and I am and have been civil, though my patience does wear thin after so many attempts).

If this is too shrill for a Discusson Comment, please missive me at user:stevea and I'll answer any questions you may have there. Again, thanks.

What are you DOING?! A route=railway is NOT a single set of rail infrastructure which must be contiguous! It can be multiple tracks which are not, and if such railways ARE what makes up a Subdivision, then THOSE railway=rail segments are what must be in the route=railway relation, even if they are not contiguous!

Can you point to any documentation, discussion or established convention which allows or encourages you to do this? No? I didn't think so. So, the only conclusion that may be drawn (as you use a THIRD user account to obfuscate your actions), is that you have a "pet project" you are trying to complete "behind the scenes," using OSM as your private rail data repository. That is not OK.

Stop breaking apart perfectly valid route=railway for a pet project of "contiguous" rail subdivisions multiplying like rabbits all over the USA! It is vandalism, pure and simple.

These are now being aggressively repaired to their "complete" route=railway relations, rather than your total preference of "pieces of these which are wholly contiguous." It's wrong!

I have asked you politely (and more than once) to explain why you insist on creating route=railway relations which seem they must be contiguous (even as the actual data, as multiple parallel elements, are not). You do not answer. Moreover, you obfuscate your identity by creating multiple OSM accounts (ethylisocyanate and US Woods, at least) apparently for the express purpose of making your activities more furtive.

Years ago, we established that route=tracks relations were not used in North American rail, this has been talked about in our wikis, talk-us and Discussion pages and between us personally.

Yet you insist upon creating abominations like Ottumwa Route Master (relation/8821512), a super-relation tagged route=railway made up of relations tagged route=tracks. This is a form of vandalism, not documented anywhere as it destroys valid route=railway data. (Ottumwa Subdivision 1, there is no such "1" relation/2222667 was chopped up, Ottumwa Subdivision 2, there is no such "2" relation/8821510 was created, and the route=railway tags were changed to route=tracks). Please stop doing this.

We well- and fully document how we create route=railway out of rail elements in the USA out of TIGER-originated data. ORM documents this as well, the only difference being that we do not (or only exceedingly rarely, and isolated to a single island) use route=tracks relations in all of North America. You fail to follow these tagging conventions, simply making up new rules to tag rail. This is unacceptable.

Creating this super-relation tagged route=railway made up of relations tagged route=tracks as you have is simply wrong. Please restore these data to well-documented route=railway data structures that are widely used and understood in the USA/North America as we document them in our wikis.

Or I and others will. Thank you.

The relation/7193738 is incorrect. A local bicycle route is a SINGLE route, not "all bicycle infrastructure elements in a local area aggregated together." For example, look north a few miles, at the corner of West Magnolia Avenue and 6th Avenue, there are two correct local bicycle route relations (8411679 and 8411680).

These are much more reasonable, they are linear, and are only a kilometer to a few km in length.

The way you correct this is to "break out" from this gigantic relation containing 269 elements each linear route into a single relation that represents a single, numbered route. Also, put the route number, if signed or if from a local authority map, like a "County Bike Map" with route numbers, into the ref tag.

Please see those other relations as better examples, and/or osm.wiki/United_States/Bicycle_Networks . Thank you.

SteveA

Nobody is vandalizing relations. Relations which are superfluous (but which supplant existing relations which are correct) SHOULD be deleted, as their data can be found in other, proper relations. And if those relations are not proper, they should be corrected so they ARE proper, rather than having a wholly redundant (but incomplete) relation created in their stead.

OK, you asked help for the names, I've deleted "Dallas Sub" as erroneous and superfluous, superseded (as it was original) with a more correct Dallas Subdivision (from which I removed your FIXME comment "sort out tracks in Fort Worth," because I did).

This work is ongoing and will continue to improve.

Terribly sorry, that was a JOSM error on my part. After 13,000+ edits, I'm likely to make a mistake here or there, but I don't think I make many. Thank you very much for noticing this and bringing it to my attention! I have fixed the error by deleting the erroneous tags.

Happy mapping, Steve

Hello. It was about six months ago I was working on "consolidating multiple sources" of map data (maybe Strava heat map, maybe others' GPS tracks, maybe others...) and so I can't remember exactly. I do remember thinking that 579705809 seemed like "the best compromise for my estimate of the combined data." In other words, a "best fit" from multiple sources.

It may very well be that 579705809 does not exist, and as you seem to have better "boots on the ground" way out there, feel free to delete it. The last time I was there (near Fern Gulch) was at least ten years ago and your data seem newer and better.

Regarding 475700792, once again, feel free to adjust it to either your original data, or better (newer) data. If it doesn't connect to Hihn SS Road, then it doesn't, and so, of course, shouldn't connect in OSM.

Thanks for the discussion!

Steve