Importing official data from Keren Kayemet LeIsrael

  1. If you want to try to edit the data on the dev server, you’ll need a user. Otherwise, you can browse everything unregistered.
  2. No, the databases are totally disconnected, that’s why I first wanted to try the whole process on the test database.

In fact, the chunks are built so that each contains all the objects (nodes, ways, relations) belonging to only specific forests. That is, a relation in one chunk cannot have as its member a way from another chunk. In any case, the script I’m using can recover from network failures, in which case it will open a new changeset for every attempt, but will remember which objects were already uploaded. I think this is inevitable because network errors happen all the time.

Yes these are the entire forests as appear in the dataset, but these are only the forests managed by KKL. In fact, they warned us that the boundaries may not correspond to actual areas with trees, but rather they reflect the official designation by the land authorities (or something).

I agree.

Maybe this is just overkill to tag every way (there are lots of ways compared to just 278 relations, after all…) Despite the fact that right now there are no ways shared by two or more relations, this might change in the future (e.g. as a result of some automatic simplification/duplicate node removal)

I’ve put the metadata table here (editable in-place):
https://spreadsheets.google.com/spreadsheet/ccc?key=0AlhvTH5eFdJvdGk4aGFRZ3B6cUVYSWNUenBoeW8zdmc&hl=en_US&authkey=CMGMgdkK

I did a few, but right now don’t have the time to go over all of them.

I added all English names. :slight_smile:

If possible, I’d suggest adding " Forest" and "Yaar " to the English and Hebrew names.
e.g.
current name in excel: Beer Sheva
name:he (in Hebrew)=Yaar Beer Sheva
name:en (in English)=Beer Sheva Forest

talkat.

Actually, there is something about multipolygons here:
http://wiki.openstreetmap.org/wiki/Relation:multipolygon#Usage

So now I tend to think that the ways should not be tagged at all.

dimka

I’ve incorporated English names into the script (thanks talkat!), here is an example (scroll to the bottom to see the 5 new forests):
http://api06.dev.openstreetmap.org/browse/changeset/11062

If everybody agrees that the tagging is OK, I will proceed with the full import on the real database.

dimka

Tagging looks ok.

Some ways aren’t closed, and they all should be closed loops with no crosses.
Is it intentional?

Here are 2 of them:
http://api06.dev.openstreetmap.org/browse/way/289828
http://api06.dev.openstreetmap.org/browse/way/289829

talkat.

Yes, this is necessary because in OSM (more precisely, API 0.6) each way can have at most 2000 nodes.

I know of this limitation. (I cut a few ways in the past that were created before this limitation was imposed… Last time I checked, the longest way was around 800 nodes)

How many ways have more than 2000 nodes?
Can they be simplified in some way to have less than 2000 nodes?

If not, then another option is to cut one big loop into 2 closed smaller loops with shared nodes.
But this should be manual.

talkat.

76

Why exactly do we need the ways to be closed?

For the impatient, I’ve done a little simulation of how the large-scale map would look like.

Before import: http://flic.kr/p/9R377a
After import: http://flic.kr/p/9R3chT
The difference: http://flic.kr/p/9R3d8r

Because landuse=forest can be used in either nodes or areas (closed ways)
Not in ways (lines)

talkat.

So maybe this is another reason not to tag individual ways?

Sure, but how would the forest relation know how to connect them?

You’d need a relation to contain each of these more-than-2000-nodes-areas and add this relation to the forest’s relation (and not the individual ways that are part of the “smaller” relation)

talkat.

I believe this is no problem - look here at Figure 6.

Ok, go for it.
Hopefully this is supported in all the popular renderers (mapnik, osmarender, mkgmap, osm2gpsmid, etc.)

talkat.

I understand your concern. To be sure, I will take one such relation in OSM format and try to produce a mapnik/osmarender image as well as a Garmin map (unfortunately I don’t have experience with osm2gpsmid).

I can test osm2gpsmid.
But if all other renderers work (and osm2gpsmid doesn’t) - then it’s good enough for me (if my vote counts, that is…)

talkat.

I’ve checked mapnik, osmarender (new version, orp.pl) and mkgmap - all of them render the multipolygons with untagged+splitted ways just fine.

I will be therefore proceeding with the import on the live database soon.

Cheers!
Hope the import will be smooth.

I’ll create a list in the wiki with all forests, like the places and municipalities.

Maybe we could have a list of non-KKL forests as well?
So we could see whether we’d like to keep them or not, and if we want to keep them - to tag them accordingly.

talkat.

One last test before the actual upload was successful.
You can review all the data via
http://api06.dev.openstreetmap.org/browse/changeset/11130

Do you want to run some tests (scripts etc.) on the test database before the actual upload?

dimka