I recently exported geojson data for all the public lands of Kentucky, and would like to import them into OSM. I have a project plan on the wiki.
https://wiki.openstreetmap.org/wiki/Kentucky_WMA_Import
Please let me know if you have any feedback. I’ve also posted about this to the Slack community.
Hello! I’m taking a look at a few of the generated files in JOSM and some things look a bit odd and would love to have your input.
Here’s a portion of the Beave Creek boundary… it seems to cut back and forth across the highway as well as through buildings and (presumably) residential areas. The rest of the boundary is similar. What’s the story there?
For areas where the boundary appears to be defined by other features, do you plan on merging the ways to existing nodes? Here’s an example from Buckhorn Lake that… I would guess… is defined in this way and has corresponding water areas already in OSM.
It’s very common for imported shapes to be (gently) simplified before ingestion into OSM. JOSM is great at this and a simplification tolerance of even .1m usually gets things into a more typical node density. Here’s a before and after of a portion of the Curtis Gates Lloyd boundary. Tosses about half the nodes with very little appreciable difference in shape.
Thanks for the question. I honestly don’t have an answer. Is it safe to assume the satellite map is correct, and to move nodes to match the image, or is it better to assume the source data is correct regarding lat/lon and leave things as they are?
For Buckthorn lake, I’m assuming this area is an area where the lake level may rise up to. Each feature has a link to a webpage on the ky fish and wildlife website which explains some of the history and reason each area exists. The Beaver Creek WMA site may explain the border. Each webpage has a PDF with a more detailed map of the WMA.
I would love to use JOSM, but my only computer is provided by my employer, and they lock down the ability to install anything. I might have to figure out using VNC from a cloud server I have. If you or anyone else pulls up a file and feel it looks good, feel free to pich it to OSM and send me a message. I’m doing them one at a time and check if something is already there before pushing a change.
If the computer has Java you don’t need to install anything further, just copy the josm .jar file to the computer
I don’t think it has Java. I’m pretty sure the computer tried to install it when I tried to load JOSM and received a nasty automated IT message.
Try downloading this file to your desktop and then double-clicking it:
https://josm.openstreetmap.de/josm-tested.jar
Typically within the US overhead imagery (satellite or aerial) is accurate to within a few meters. It is much more likely that the data you are proposing to import is in error. You might try to get parcel data from the county in question and compare. Presumably, the state owns the SWA.
Before we make an assumption one way or another, maybe you could do some research about the regulations associated with the WMAs. In some states, some kinds of protected areas have inholdings that allow people to live there normally.
Personally, I don’t really care if someone lives there or not. If the state says a certain border is considered a WMA, why would I change it because the line crosses a building?
Here is some further feedback:
The files you have provided do not have OSM tagging. The community should be able to see the files with the converted tagging to make sure nothing went wrong.
Some of polygons overlap other polygons from the proposed import, e.g.
This concerns object ID 88 and object ID 103, but this isn’t the only example
In OSM there is a limit of 2000 nodes per way. There are 60 ways in your proposed import that have more than 2000 nodes. These will need to be turned into multipolygons.
Have you tested whether all polygons are valid? Just doing a visual inspection some appear to be self intersecting. I will try to test.
Some of the features you propose to import are already in OSM, e.g.
The title of your post says “WMA import project”, but 659 of the features you propose to import are tagged WMA=No (they are bits of things like National Forest, etc.)
Some of the WMAs that you propose to import are broken up into many tiny little polygons (closed ways), such as the Barren River Lake WMA. In my view these should be merged into a multipolygon.
Because government data sources are often inaccurate or outdated (there are a lot of other issues with this data, e.g. overlapping WMAs). It is possible that those bits used to be WMAs, but the state divested of some of the land, or that some contractor or intern who was tasked with making the dataset cut corners or was sloppy. If as a hunter I assume that I am allowed to hunt in these WMAs, but if it is someone’s private land, that may not end well. But, as @Minh_Nguyen stated, we really need to know the definition of a WMA in Kentucky.
It looks like you didn’t actually read the import project proposal. I state pretty clearly that I am separating out all the features from the original data dump, and only importing the WMAs that do not exist in OSM. I was going to deal with updating the existing ones possibly at some future time.
I know about the 2000 node limit. A plan of first importing the ones that do not require splitting, then splitting the larger ways.
The project page specifies the OSM tags I plan on adding to each WMA before I import them. The osm/done directory on the new-vs-update branch on GitHub has files that are complete.
Those are ones you have already imported, right? You shouldn’t start importing before community review is complete.
Where can we see all of the data in its final form that you plan on importing? So we can inspect the geometry and the tagging?
Unless the existing OSM data in the area is out of alignment with the aerial imagery, I generally assume it is relatively well aligned (at least within a few meters). If a boundary is randomaly crossing roads and going through buildings this is a pretty good indicator that the source data is not very accurate. When I’m adding public land boundaries like this I try to look at a few different sources and adjust as necessary. For example if a map from the land managment agency shows the boundary all on one side of a road, but the polygon I’m working with criss-crosses back and forth across the road in OSM, I assume the boundary is innaccurate and I adjust it to match up with the road. Similarly if there is a clear division between woods and residential backyards (say with a fence perhaps), I’ll adjust the boundary to follow this rather than inaccurately going through the backyards or houses. Where the boundary is going through the middle of the woods there are no reference points so I don’t worry about the accuracy there.
Yes, I’m only suggesting due diligence. Government agencies often intentionally put out datasets that are intended to be shown at lower zoom levels but would fail scrutiny at higher zoom levels. If that’s the case here, then manually correcting the data might be reasonable and necessary, but even as a layperson who has visited Kentucky plenty, I just don’t feel qualified to opine one way or another without more information.
I do not know how tidy lock your computer is but josm-setup.exe is made to install into user space and includes Java. Have you tried to install it that way, yet?
It said a Java exception has occurred after trying to run the jar file. I’ll try the exe later tonight.
Hello everyone,
I want to address some concerns that have emerged around the Kentucky WMA Import project (DWG Ticket#2024043010000239). It has been brought to my attention that the import began before the customary 14-day community feedback period has concluded, and with some unaddressed comments updates here. @Beakerboy please pause on this import until all community feedback has been adequately reviewed and addressed.
Thank you for your understanding and cooperation.
Best regards,
Elliott Plack
Member, Data Working Group
OpenStreetMap Foundation
I was thinking I’d be able to do them one at a time, and explain my process for what I was going to do, but apparently I need to have everything done before importing anything, so see you guys next year. More than likely though, it’ll not happen.
Unless you just want me to repost here for each file before I push it as a check…whatever…I’m just trying to help. I’ll probably just start working on my 3D building renderer some more.
It looks like you’ve added only four features from this dataset so far, hardly a cause for alarm. However, these edits took place before you posted here. Unfortunately, no one had noticed your post to Slack by that point. In a fast-paced chatroom like Slack, no response doesn’t necessarily mean consent.
I suppose your edits could qualify as test edits to aid in reviewing the proposal, though technically you are supposed to provide an OSM file showing the result of a dry run if you’re able. (JOSM is the best tool for producing this file, though some other tools might work.) Regardless, you could’ve avoided misunderstanding by saying something about these edits in your original post or wiki documentation, or by leaving more descriptive changeset comments.
This doesn’t need to be the end of the story. We need better coverage of protected areas in Kentucky. Have all of these questions been addressed? They seem like things that would normally be straightforward to fix inside JOSM using its built-in commands. That would save you time and effort compared to patching them up manually outside of JOSM.
I think it is reasonable to expect that the community have an actual copy of the data you intend to import, and that includes all of the features and only the features, you intend to import. That way we don’t waste time investigating a feature you don’t intend to import, and we don’t comment on interactions between features you do intend to import and features that you do not (such as overlaps). The data should be in its final form with OSM style tagging. I have seen many cases where someone says they are going to tag something a certain way, but for one reason or another, the actual data doesn’t get tagged that way. It could be a .osm (XML) file or geojson.
Once we have the actual data, we will need some time to evaluate. Most of us have jobs and other obligations and we may not be able to immediately comment.
I also think that it is reasonable that you investigate some of the cases where these features contain obvious built-up areas. You might contact the agency that manages these lands (or publishes this data) and ask them. It could be that these areas can contain private built-up areas, which may influence the proposed tagging. It also could be that the data is outdated, which may mean that an import at this time is not a good idea. Perhaps the agency could point you to a better source, or tell you when they might update their data. You could also download parcel data from the relevant county and compare. Does the state own all of the land within these areas?
Good data take effort. But it is possible.
