Importing official data from Keren Kayemet LeIsrael

So far it looks good! :slight_smile:

Here is a nice big chunk that is clearly more accurate than the current data we have.

talkat.

Looks very detailed in compare of our “bing” work :slight_smile:
We will have a very green Israel - Palestine in OSM.

BTW: I have added some notes some days ago to the areas you imported… hope this will not harm the upload. I removed the notes just now.

http://www.openstreetmap.org/?lat=31.79481&lon=35.29368&zoom=15&layers=M

As a matter of fact, I believe that these ways were not reverted automatically precisely because they were changed. If I remember correctly, there should be only around 5 of those. I was planning to “hunt” these after I finish the upload and delete them anyway. Could you please just write their IDs (but do not delete them yourself as I would like all the edits to be done through the kkl_import user).

Just found this: http://www.openstreetmap.org/browse/way/117745023
Seems strange.

Here are some more:
117745024
117744991
117745025
117745008
117744993
117745111

And several others in that area.

talkat.

Another issue:
Way 117745110 has 2 nodes which are practically in the same place.

talkat.

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.

Sounds unlikely, as these are closed ways, polygons.

It could be that KKL’s source has these as errors, or they’re a result of some rounding algorithm when you converted to OSM’s coordinated?

talkat.

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.

I’ve checked the source of http://www.openstreetmap.org/browse/way/117745023: turns out this is a “hole” in elyakim forest: see its counterpart http://api06.dev.openstreetmap.org/browse/way/293395
In the original KKL shapefile there is indeed such a hole, so the problem starts there. I guess it is an error and not some physical feature. After the upload is finished, I’ll ask KKL about those.

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.

I believe all the changes are by now reverted (perhaps with the exceltion of ~1000 nodes which I couldn’t track down yet).

Any comments/suggestions before the second attempt?

I have started the second attempt. This time there are 20 smaller self-contained chunks.
The first one is already done:
http://www.openstreetmap.org/browse/changeset/8539352

I see the additions near Modiin! Cool…
Should we delete the old forests?

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?

Two issues that I noticed:

  1. Boundary between Modiin forest and Ben Shemen forest - double nodes in vicinity of node 1338642702.
  2. Node 1338697923 is shared by two ways in the same relation, which (I think) should be merged into a closed loop.

I’ve added this to the wiki:
Main Israel wiki
And a sortable list of all forets.

talkat.

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

talkat.

The KKL guy indeed mentioned that the boundaries in the file refer to KKL managed areas, not necessarily real forests with trees.

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).

dimka

I guess we should gradually correct this. Map readers would care about the actual land cover, not administrative jurisdiction.