OSM does have “map what is” and “tag because it is real” and “on-the-ground verifiable” tenets, so I’m not sure what you mean by “boots on the ground.” I will say that a map that is made by somebody who “just hiked that trail earlier today” (as say, they enter a neatly-trimmed GPX dump from their GPS track) is better than somebody who grabbed “trail heat data from the Internet” and stuck it in, so there’s that.
Metadata are often additional attributes added onto the actual data like details of the photographic equipment used to take the photo or similar. Might be an attribute like the name of a non-profit who publishes the data or similar (as a source tag or changeset comment).
So, there isn’t “a tag to delete” (quite yet) as there isn’t really a talking point of a particular datum that might have its tag, whether contentious or not, deleted. I appreciate your conciliatory tone, though, it is helpful.
Again, have you seen our Public Lands wiki? What specific “wildlife boundaries” do you propose to import? All of 'em? Some of 'em? Which of 'em? And with what tags? Are you hoping to see these rendered somewhere? If so, where? Would being able to “see” them (extract them from OSM, really) with a tool like OverpassTurbo and making a few lines of query in an area suffice for your purposes? Do you have a specific “interest” (in timber of a particular species, or deer, or areas with particular geological interest)? Those answers can help us propel you forward to next steps. Though telling us you’ve read / at least skimmed the State section of our Public Lands wiki, and maybe whether you researched how your proposed-to-be-imported data might mesh (or doesn’t) with a Colorado PAD source would be excellent next steps (hint, hint).
I’m being gentle with you, I know you’ve had a recent snow-oriented power failure, hey, it’s even the weekend AND you’ve said you are chill with the tempo of this being about walking speed. Here we are!
Edit: Finally, while your Let’s Encrypt (web, mail) certificate is valid (for a couple more months) I’m getting some pushback by my (web browsing) security about mismatches between the mail and web subdomains of your domain. But others are perusing them, so that’s good. We’re all just strolling through a chat on a Saturday evening…
I’m double-posting myself, I know. 1639 isn’t something I’d say is “just” or “only” w.r.t. an import of state boundary data. That’s a pretty substantial number of good-sized (multi)polygons, actually. And because I can’t get to your data as linked in your wiki (again, my web browser has its security ratcheted up pretty paranoid…your issues with your certificate seem to be that the web subdomain isn’t your mail subdomain), I can’t really look at the data with JOSM myself. Do you have another way to “push” those data? A cloud-let or a drop-box or some shared 'net space other than “your” domain? Thanks.
Some days I wonder why I still bother to run my own here at home… I fixed apache to use the one for my webserver instead of mail (oops), so it should work now. Chrome is happy.
Since the data isn’t uploaded, deleting a tag would be in the source file of course. I’m not so concerned about the state park boundaries with the leisure=park tag, I’m primarily interested in the wildlife and Trust lands. Yes, I’ve been all through that wiki page and others multiple times. There’s a lot there for National public lands, not so much for state public lands.
As far as the data size, I deal with large OSM datasets all the time for my dayjob at HOT. I’m also not tagging for the renderer, I primarily use custom data extracts. OverpassTurbo is nice, but at HOT we use Underpass (which I wrote) instead, and maintain our own OSM database updated every minute. Note that HOT does not do anything in the US, this is a personal project. Anyway, yes, I would prefer to upload all of this data at some point once we’re all in agreement. As I mentioned, I’m not in a hurry, and will admit I’m learning how to do imports here in the US which is different than when I’m mapping overseas for a disaster response. I’m planning on more future Colorado imports, so might as well get the process right.
Once these boundaries are uploaded, there is of course followup data, campsites, public toilets, landuse, highways, etc… but the boundaries are very useful to filter the size of the external datasets. My primary goal is we use any public land as staging areas when fighting wildland fires, so this data becomes very useful for emergency response. Plus the recreational use for others when it’s not on fire.
I see there are several comments above about broken links to the source data set. It looks like the source data would be the CPW Administrative Boundary Data which is available here.
You haven’t been clear about which layer you’d be using but it appears it would be the CPW Public Access Properties layer.
The thing about boundaries is that they’re not easily verifiable on the ground. It really doesn’t matter whether you’ve camped there. You’re not going to correct them by hand, and neither is anyone else.
It does matter whether the boundaries get imported at the right locations in OSM, and properly transforming the data is necessary to get that right. It can see that the default transformation in ogr2ogr is just reprojecting the coordinates onto a new ellipsoid. It’s not actually applying any grid shifts. Do it right, and the coordinates will be transformed with an error of much less than 1 m.
If you care about this stuff, you do care about doing it right, don’t you?
For a disaster we’re doing either remote mapping using imagery, or field data collection, so no imports other than building footprints. If we do import footprints, there are zero tags other than building=yes, so easy.
To be honest, many boundaries in OSM bear little resemblance to the real world… I suffer dealing with poor boundaries frequently. It is important to get it as close to accurate as possible. If other data I collect when standing in one of these areas is in the correct location in the boundary in JOSM (the information board usually), I’d think that’s good confirmation. Course a phone GPS is 3-9m off, so I guess that’s not very accurate if you’re taking about 1m accuracy.
For the few boundaries that already were in OSM (state parks), everything lined up the same. I can redo the transformation if that’s what the community wants, but before doing that, I’d like to have agreement on tagging so I only have to redo everything once.
I went through the steps in the wiki on transforming the geometries. I had to zoom in pretty far, but the polygons are in a slightly different position, which I assume is the desired result. I’ll migrate the tags from the previous version and add it to the other files. I’m considering leaving the state parks out of the import for now to focus on the wildlife areas and trust lands.
The maximum difference between NAD83 and WGS84 in Colorado is less than four feet. I doubt the original source data was this accurate (it is probably not survey quality). I would be more concerned as to whether CPW has kept this data up-to-date with land acquisitions and divestitures - which are not infrequent. Having worked with CPW data before, my impression is that GIS data is an afterthought. In other words, they go about their business of managing the lands they are in charge of and making changes on the ground, and then later, sometimes years later, they get around to updating the GIS data. I know you are probably aware of this. Not a reason to not do the import, but something to keep in mind.
I am still getting a “Not Found” error when I try to access the final data on your server. Can you post it somewhere else?
Some state parks in Colorado might qualify as leisure=park, such as Boyd Lake SP in Loveland. But, most, if not all SP here seem to be focused on recreation, so protected_area=recreation could be applied generally.
In your description of the import you state that if hunting is allowed you are going to tag the area as “access=yes”, to some data consumers this means that all access is allowed, unless more specific tags state otherwise, and at least for SWAs this is not the case as one is only allowed access if one is hunting or fishing (and has the necessary license).
When I checked taginfo, hunting=yes wasn’t very common. There is leisure=fishing, which I did use, so leisure=hunting ? I don’t want to start inventing tags though.
I went through the documented process to reproject the original data file, and then since it’s a small dataset, went through and made the same tagging changes. All relations where converted to a proper multi-polygon. I dropped the state parks, many are already in OSM, so no leisure=park required. I updated the wiki with the new files and added more details.
I was finally able to download the file - at least the most current one, which is what counts. Thanks! I will try to take a detailed look at it over the weekend. In the meantime, here is some feedback based on your latest post.
The operator of both State Trust Lands and State Wildlife Areas is Colorado Parks and Wildlife, not “State Trust Lands” or “State Wildlife & Parks”
you can only assign one value per key, so you couldn’t tag both. hunting=yes is used far more than leisure=hunting and is consistent with other access tags that use the yes/no/permit/private etc scheme.
Additionally, you do not want to use leisure=* for these types of lands because they are very very commonly tagged leisure=nature_reserve, which conflicts with using any other leisure=* key. That’s why I would personally recommend fishing=* and hunting=* rather than trying to overload leisure=*. They are both wiki-documented as I’ve linked so you’re not making anything up.
Oops, that was a typo. I am using only boundary=protected_area for the wildlife areas. I see your point about landuse=recreation_ground. I just dropped that everywhere. And changed to operator=“Colorado Parks and Wildlife”. I added a new v2 file, and updated the wiki.
Are you going to have ‘state trust land’ or ‘state wildlife area’ in the name so we can tell them apart? It looks like there won’t be any other tags to tell them apart.
Thanks or doing this, it will be great to have this in OSM
Yeah, with changing the operator tag, this became more obscure. Right n ow the names have either SWA or STL as an abbreviation. I could expand that though for example “Indian Run SWA” would be “Indian Run Wildlife Area”. or “Radium STL” would be “Radium Trust Land”. I do see in taginfo fishing=yes 4588 times, and hunting=yes 2876, so I’ll make the change. I’ll add hunting=yes to all the wildlife and trust lands, and change leisure=fishing to fishing=yes.
I’m not so concerned about the state park boundaries with the leisure=park tag, I’m primarily interested in the wildlife and Trust lands. Yes, I’ve been all through that wiki page and others multiple times. There’s a lot there for National public lands, not so much for state public lands.