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.
HI All,
I have test the data in western gallil around EILON and i found that the names of the forest are wrong and not correct.
also some of the forest are no longer exist for the reason that there is new building near some of the civilization.
it look that the data is not update.
OK, so what do I do with an area which is part of a KKL relation, but is not actualy a forest?
Delete it from the relation? That would be a shame. Most of these areas are uncultivated land that can be described as natural:scrub (בתה או גריגה).
I believe that we should not enforce any integrity of the KKL data, as our primary concern is to the up-do-dateness of the map.
But I would like nevertheless to have all such inconsistencies documented at least in this forum thread.
A possible solution:
split the areas into “forest” (keeping this in the original relation) and “scrub” (making a separate relation with a note such as “original boundary taken from KKL import, relation XXX.”
Thanks to all for their comments and active participation!
There should be 278 forests overall. I checked all the import again and found out that for some reason there appear 14 duplicate relations as follows:
6 duplicates in http://www.openstreetmap.org/browse/changeset/8611316. This is a situation created by bulk_upload script: each pair of duplicates uses its own ways, but the ways themselves reuse the same nodes. Deleting this appears to be tricky, but doable.