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.
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
As much as I could see (I only did a brief overview) - it looks good! Great job!
I wonder if we could somehow automate all the inner ways.
e.g. this water.
talkat.
I see changes by kkl_import! 
Let us know when we can start tidying up.
Should we decide about tagging non-kkl forests?
Or should future updates just update kkl-managed forests?
talkat.
There are some problems with the import - duplicates. I am looking into it.
Please do not change the objects uploaded by kkl_import. I will try to revert the changes.
Something went wrong with the import script, which caused the duplicate ways.
As far as I understand, there are no duplicate nodes, can you confirm this? If so, recovery should be much easier.