dimka
June 6, 2011, 6:51pm
17
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
talkat
June 6, 2011, 8:47pm
18
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.
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.
dimka
June 6, 2011, 9:14pm
19
Yes, this is necessary because in OSM (more precisely, API 0.6) each way can have at most 2000 nodes.
talkat
June 6, 2011, 9:37pm
20
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.
dimka
June 6, 2011, 9:54pm
21
76
talkat:
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.
Why exactly do we need the ways to be closed?
dimka
June 6, 2011, 10:49pm
22
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
talkat
June 7, 2011, 4:41am
23
Because landuse=forest can be used in either nodes or areas (closed ways)
Not in ways (lines)
talkat.
dimka
June 7, 2011, 5:24am
24
So maybe this is another reason not to tag individual ways?
talkat
June 7, 2011, 6:25am
25
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.
dimka
June 7, 2011, 6:52am
26
talkat:
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.
talkat
June 7, 2011, 9:52am
27
Ok, go for it.
Hopefully this is supported in all the popular renderers (mapnik, osmarender, mkgmap, osm2gpsmid, etc.)
talkat.
dimka
June 7, 2011, 10:11am
28
talkat:
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).
talkat
June 7, 2011, 10:59am
29
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.
dimka
June 7, 2011, 7:48pm
30
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.
talkat
June 7, 2011, 8:25pm
31
dimka:
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.
dimka
June 11, 2011, 12:47pm
32
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
talkat
June 11, 2011, 4:01pm
33
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.
adrukh
June 13, 2011, 6:19am
34
I see changes by kkl_import!
Let us know when we can start tidying up.
talkat
June 13, 2011, 6:47am
35
Should we decide about tagging non-kkl forests?
Or should future updates just update kkl-managed forests?
talkat.
dimka
June 13, 2011, 7:36am
36
There are some problems with the import - duplicates. I am looking into it.