I can’t say for sure, but it is possible that these are all parts of boundaries which are longer than 2000 nodes. In that case there is a split, and the other part(s) just haven’t been uploaded yet.
Right now there is a problem with the upload - the server returns “500 Internal server error”. I have no idea what can be causing this, I just posted a question on the OSM-talk list.
If a source polygon has more than 2000 nodes on its boundary, this boundary cannot be represented by a single (closed) way in OSM, in which case there will be a split and the relation will take care of the connection.
Due to problems, I have started to revert all the changes made so far.
The problem is that there was a gap between the upload of nodes and the upload of ways, during which some of the nodes were changed.
I have already removed all the ways, and now continue with nodes.
Afterwards I will do a clean import by small chunks, each of which will contain several forests in their entirety - i.e. relations and all the ways and nodes belonging to these relations.
Most editions are great!
In some places, though, like around the Canada park, the boundaries enclose open areas.
Do they describe KKL-managed areas? planned forests?
The solution should be to reuse the same way in both relations. We do it in the administrative boundaries,
but the administrative boundaries are drawn by hand, and this is an automatic import.
I’m not sure it’s feasible.
dimka should answer this.
This is the case of a way with too many (more than 2000) nodes, that needs to be split into smaller ways.
The polygon algorithm takes care of it.
See more here
Hmm that might have been an oversight on my part. The script (polyshp2osm) does not reuse nodes for different features (in our case forests), therefore the nodes get duplicated.
The import is slightly more than half way through, I will try to correct this through JOSM for the remaining data. As for what got uploaded
Hopefully the number of such duplicates is not large (this happens only in the case of two distinct forests sharing a common boundary).
I’ll make a list of such problematic forest pairs later. Then it shouldn’t be too difficult to merge the duplicates manually (again through JOSM).
the import of the forest dataset has been completed. Several problems have been encountered (mostly duplicated objects which needed to be reverted). There may be still some of these “orphaned” duplicates around but not many.
There are probably several dozens of yet other duplicated nodes coming from the data - like the ones mentioned by adrukh.
When I have time, I will be continuing with the import of POIs.