Importing official data from Keren Kayemet LeIsrael

Hi all,

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.

dimka

Great!
Thank you for all your work!

The Wiki List of Israeli Forests contains 263 forests.
Is that correct?

talkat.

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.

Tzur

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 (בתה או גריגה).

Thank you, all this information is very important, as it allows us to estimate the actual quality of the KKL data.

You probably refer to Eilon (http://www.openstreetmap.org/browse/relation/1637969) and Hanita (http://www.openstreetmap.org/browse/relation/1637980) forests?
I see from the kkl:update_date tag that Eilon is pretty outdated (2005) but Hanita is not too much so (2010). Are these the only forests you meant?

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.

dimka

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

dimka

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:

  1. 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.
  2. 4 duplicates times 2 = 8 duplicates in changesets http://www.openstreetmap.org/browse/changeset/8602520 and http://www.openstreetmap.org/browse/changeset/8602815 (in addition to the “originals” in http://www.openstreetmap.org/browse/changeset/8602418)). Here again the ways are duplicated (56 originals, 112 duplicates) but the nodes are not.

Furthermore, there are additional 29 forests in http://www.openstreetmap.org/browse/changeset/8651910.

That makes 263+29-6-8=278, so at least all (big) problems seem to be accounted for.

dimka

Ok, I’ve got the latest OSM data, and now there are 292 forests.
Meaning there are 14 duplicates?

talkat.

Yes. These are:
http://www.openstreetmap.org/browse/relation/1647914
http://www.openstreetmap.org/browse/relation/1647913
http://www.openstreetmap.org/browse/relation/1647912
http://www.openstreetmap.org/browse/relation/1647911
http://www.openstreetmap.org/browse/relation/1647910
http://www.openstreetmap.org/browse/relation/1647909
http://www.openstreetmap.org/browse/relation/1646716
http://www.openstreetmap.org/browse/relation/1646715
http://www.openstreetmap.org/browse/relation/1646714
http://www.openstreetmap.org/browse/relation/1646713
http://www.openstreetmap.org/browse/relation/1646669
http://www.openstreetmap.org/browse/relation/1646668
http://www.openstreetmap.org/browse/relation/1646667
http://www.openstreetmap.org/browse/relation/1646666

The above relations and their associated ways (but not the nodes!) should be deleted.

dimka

The above 14 duplicates and associated ways have been deleted.

talkat - can you please regenerate the wiki list (probably should wait until tomorrow at least)?

dimka

Will do.
If not tomorrow, then by early next week.

talkat.

There are now. :slight_smile:

talkat.

The KKL import seems low quality in some areas… In the Carmel region it’s often detached completely from what’s on the ground. I currently just delete and replace whenever I encounter this.

It denotes KKL-administered areas pretty accurately. There’s an assumption that those are forests, but that is often not the case.

Also, often times the administrated area is a fraction of the entire forest.

When the actual forest is different from the KKL administrated area, do you think the latter has relevance to a map user and should be preserved? Or should we map purely the physical features and delete it?

Only the physical forest matters.

I would say the “this portion is administered by KKL” tagging should be kept if it is present and accurate, and removed otherwise.

Rationale: 1) the map should have no incorrect data, 2) the extra information is conceivably interesting to some data consumers. By analogy, if KKL were a municipality and the forest was a built-up area, we’d map the city limits even though there are buildings both inside and outside those limits, won’t we?

My 2 cents, based on reasonable guesses:

In my opinion, it is unlikely to be used except for very specific and extremely obscure cases. Furthermore, someone who wants such specialized data likely knows exactly what they’re doing, and can obtain it directly from KKL, where it’d be more up to date. The OSM data is 5 years old.

Sure, if the data is out of date, then either tag it appropriately or delete it, and let interested parties fetch it from the edit history or from KKL. (Sorry, didn’t see your answer before.)

I think people have been editing these relations on the assumption that they represent physical forests. Nobody should use them for KKL administration data - they will likely be very inaccurate now.