OpenStreetMap logo OpenStreetMap

Changeset When Comment
175333356 7 days ago

Thanks for the fix here, Kerry, I had not noticed this.

174222476 about 1 month ago

Nice work, Mike! The bridge is already starting to render, and no changes to existing USBR 50 relation, as is correct.

The "sail the paper airplane to Caltrans" that this might be incorporated into USBR 50 routing in some future AASHTO USBRS Round has begun. Will wheels turn and heads nod? We hope they will!

173055700 about 2 months ago

Thank you for adding Davenport CDP!

171926973 about 2 months ago

Y'know, maybe my eyes are trained to see Carto rendering with these three SEPARATE things (leisure=nature_reserve as boundary, natural=wood where they are, leisure=park if/as such manicured areas / "human sculpted land") exist, and maybe other eyeballs of other OSM contributors, less so.

But, I'm beginning to see these things evolve as Carto is rendering them and as @ZLima12 makes the changes. While we are maybe in "later innings" of this "go team" effort, meaning we are not quite yet done, we certainly are now around TWO thumbs up at our shared progress.

Lookin' good, even if not (quite) yet done!

171926973 about 2 months ago

To @ZeLonewolf 's comments above: 👍

171926973 about 2 months ago

Please, be very careful with "usually" (especially "usually wooded"). It's a very slippery slope (semantically); it's very easy to make assumptions and slip / fall down.

The wider practice that seems to be working is to "break apart" a dual-tagged (or assumed to be "both" wooded BECAUSE it is a "natural state" thing — around here — single-tagged thing) to TWO polygons. One for the, say, leisure=nature_reserve, one for the natural=wood which may sort of and sort of not be landcover in the area. You do need two polygons because you can't assume that "one means the other." (Around here). It doesn't. That assumption must die, or we'll continue to have misunderstandings like this.

So, really, there are THREE things here that might be tagged separately: the leisure=nature_reserve (which draws a boundary) the landcover (maybe wooded here, swampy there, grassland in patches here and there...) AND maybe there is a "front of park" area which could be subsetted with a small polygon tagged leisure=park.

Is everybody happy now?! We can do this!

171926973 about 2 months ago

Mmmm, it isn't "wooded" preserves that make for a correctly-tagged leisure=nature_preserve. The "landcover" could be woods, swampy or even desert (say certain kinds of sagebrush and a species of roadrunner is part of what is being "preserved").

It is the function of both "protecting natural biology" AND that humans are allowed (usually to do very low-impact activities, like read signs, observe with binoculars, hike only if strictly staying upon trails...) which makes the unique "dual-use" aspects of a leisure=nature_reserve. Yes, the natural biology is "preserved" here, yet humans might also recreate (leisure), but only if low-impact.

Semantics like "wood" are best left to natural=* tags. We express TWO DIFFERENT semantics with tagging both leisure=nature_reserve AND natural=wood, for example. The former does NOT imply the latter...that's why it's appropriate to use two tags to tag the two meanings.

171926973 about 2 months ago

And let's not forget: some areas might have a dirt parking space and maybe a bbq grill and a picnic table, that doesn't always really rise to the level of a park. It's a grill in a boundary=protected_area.

It's a big world.

171926973 about 2 months ago

Yes, it was Kevin Kenny (ke9tv), another Mapper of the Month, who helped to both coin the "front of park / back of park" concept (using leisure=park ONLY on the "manicured" segments of larger boundary=protected_area polygons) but also the word "manicured" and the phrase "human sculpted landscape."

A natural preserve (leisure=nature_preserve or boundary=protected_area) simply is not a "park" (even as that word is blurred in US English with the OSM tagging of leisure=park). ALTHOUGH, it may contain small (front-of-park) subset areas within it which could be rightly tagged with leisure=park.

The US has been chewing on these topics for many, many years, and Brian, Kevin, I and many others have contributed to the understanding that the "front-of park / back-of-park" concept is quite workable. It may not be perfect, but I'll take "workable" any day of the week. It has truly improved things to the point where these "tempests in a teapot" are only on a low simmer, rather than boiling over.

Good luck on the specifics of where the leisure=park SUBset(s) are in this (correctly tagged) leisure=nature_reserve. Sometimes they include sinuous access road squiggly polygons, sometimes not and sometimes include "islands" that are not obvious how you get to them, but these are geographic data describing "where" (not always "how"). And as leisure=nature_reserve does render the boundary edge, "you get that, too."

If you really wanted a more complete more "pretty looking" map (in Carto, say), you could carefully add natural tags (like wood or grassland) where appropriate. All together, to seasoned visual parsers of these rendered taggings, you'll "see what's really there," not as the fill colors you seem to want to see with an (incorrect) leisure=park tag on the whole polygon.

171926973 2 months ago

I've been wrangling these semantics in OSM for literally decades.

There is a possible solution to address most (or perhaps even everybody's) concerns in this case. The entirety of the property, as a "protected area" (in each of the 50 states, federal law and even OSM semantics there is such a thing, replete with databases, law and much geo data) is correctly tagged leisure=nature_reserve. That's simply a legal fact.

That some wish to see leisure=park tagging on at least some of the areas / facilities of this area CAN be accommodated with what is often called the "front of park / back of park" concept: those areas which are "front of park" that contain things like parking lots, amenities such as restrooms, picnic tables, sport fields / facilities, etc. CAN be tagged as a (subset of the area) leisure=park. The "back of park" areas are NOT so tagged, and remain tagged "simply" as a leisure=nature_reserve.

This isn't always perfect, but it is a compromise solution that often works.

172635521 2 months ago

Thanks, Mashin, for fixing up my tagging. I was a bit hasty entering this, looks nice now.

169532324 2 months ago

Toby, I do not consider you to be anywhere near a "pain in the butt," quite the contrary.: we have had an educational, reasonable, adult dialog.

You are welcome for my diligence; I have found that it frequently pays to be diligent, here we are.

Keep on mapping and mapping well and I'll do the same. Meanwhile, the data in OSM get better and better — and that's what it's all about.

169532324 3 months ago

I spoke with "Jordan" (831-345-1397) who IS authoritative at State Parks and he said that a combination of California Code of Regulations Title 14, Section 4326(a), together with "District Superintendent Posted Orders" (at the entrance kiosk off Hwy 9) makes all areas of "Lower Highway 9 South of Garden of Eden, except on designated roads" to be off-limits (to BOTH cyclists and even pedestrians / hikers).

The "designated roads" I have (and the website has) clarified above. So, now I am certain: access=no is the correct tag according to State Parks, state law and OSM's tagging principles for access (=no).

I'll assume the same for UCSC, but if you want me to call my former colleagues at TAPS-UCSC, I can do that, too.

Accurate tagginig is what OSM is about. Should mountain bikers decide to trespass by mountain biking here, the risk in doing so is wholly on those who choose to break this law. In short, maps don't make people trespass, trespassers decide to trespass.

And, conclusively, access=permissive is now known to be wholly incorrect.

169532324 3 months ago

From https://www.parks.ca.gov/?page_id=29709 (California State Parks HCRSP website):
"Bicycles are allowed only on Pipeline Road, Rincon Fire Road, Ridge Fire Road, and Powder Mill Fire Road."

From access=* (OSM's own wiki about the access tag):
"Access tags pre-eminently describe LEGAL permissions/restrictions ... regulation, rather than guesswork. They do not describe common or typical use, even if the signage is generally ignored."

As these trails are not explicitly granted access, and the same at UCSC (I have worked personally with their Transportation And Parking Services on properly mapping campus access tags in OSM, and can similarly document their explicit mountain biking paths, now properly denoted in OSM), the access=no tagging as it presently exists appears to be correct.

169532324 3 months ago

There are a number of "landowners" here: UCSC, State Parks (both Wilder and HCRSP). If you can point somewhere online where this "implicit permission" exists in publicly-accessible clarity (from State Parks and/or UCSC), then access=permissive might very well be correct.

For example, I got a letter from AASHTO (national-level route numbering protocol authority) to number bicycle routes that I enter (and posted a link to this letter in our wiki). For another example, I have direct emails from the Watershed Manager of the City of Santa Cruz to tag watershed lands (around Loch Lomond) exactly as they are presently tagged.

Absent those, the more restrictive tagging (access=no) applies, as that is the best data I'm working with. For access=permissive, all we need is an agency (or ranger...something authoritative) that says "it's OK to ride here, but we reserve the right to restrict this in the future..." and I'm fine with access=permissive. But (in this case, as it has been so contentious) OSM really needs something more than simply one mapper's word — we need some documentation as to the actuality of the permissiveness. Thanks for understanding we have a relatively high burden of "proof" here.

169532324 3 months ago

I'm listening. What is it, exactly that it is you propose to do / change?

170801657 4 months ago

Bravo, sir!

170785724 4 months ago

Such beautiful mapping; thank you!

170647487 4 months ago

Really solid additions and data updates here — thank you for your efforts at editing OSM!

170505700 4 months ago

Nice work, thank you!