- If you want to try to edit the data on the dev server, you’ll need a user. Otherwise, you can browse everything unregistered.
- 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.
dimka:There are 6 forests uploaded thus far
Each forest is actually a relation of type multipolygon, having one or more outer/inner ways. The ways themselves are not tagged, all the data is in the relations.They look good!
Are these “full” forests? They seem to lack some areas.
e.g. Kfar HaHoresh, Zipori, or Haifa forests.
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).
dimka:Please review the above data (Potlatch can be used as usual), I would like to get as much feedback as possible before I proceed to the live database. Some issues which I think need to be discussed (please add more if possible):
- Should the ways comprising the multipolygon be tagged somehow (at least as landuse:forest)?
Yes. landuse=forest is a must.
I agree.
In some places (e.g. UK) every way is also named. We could discuss whether we’d like it or not. AFAIK, there’s nothing about it in the standards.
i.e. every little part of the forest has the name of the whole forest.
I guess this is another issue we could discuss.
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)
dimka:
- English names. The original data has only Hebrew names, it seems we will need to add name:en by hand after the import. After this is done, we would have a script collect the english names for future updates.
Can you send me the Hebrew names list in a private message?
I’ll see if I can translate them all at once, so you’ll have reference for future uploads.talkat.
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.
talkat: dimka:
- English names. The original data has only Hebrew names, it seems we will need to add name:en by hand after the import. After this is done, we would have a script collect the english names for future updates.
Can you send me the Hebrew names list in a private message?
I’ll see if I can translate them all at once, so you’ll have reference for future uploads.I’ve put the metadata table here (editable in-place):
https://spreadsheets.google.com/spreadsheet/ccc?key=0AlhvTH5eFdJvdGk4aGFRZ3B6cUVYSWNUenBoeW8zdmc&hl=en_US&authkey=CMGMgdkKI did a few, but right now don’t have the time to go over all of them.
I added all English names.
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.
talkat: dimka:Please review the above data (Potlatch can be used as usual), I would like to get as much feedback as possible before I proceed to the live database. Some issues which I think need to be discussed (please add more if possible):
- Should the ways comprising the multipolygon be tagged somehow (at least as landuse:forest)?
Yes. landuse=forest is a must.
I agree.
talkat:In some places (e.g. UK) every way is also named. We could discuss whether we’d like it or not. AFAIK, there’s nothing about it in the standards.
i.e. every little part of the forest has the name of the whole forest.
I guess this is another issue we could discuss.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)
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
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/11062If 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: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/11062If 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/289829talkat.
Yes, this is necessary because in OSM (more precisely, API 0.6) each way can have at most 2000 nodes.
talkat: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/289829Yes, 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.
How many ways have more than 2000 nodes?
76
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?
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
Why exactly do we need the ways to be closed?
Because landuse=forest can be used in either nodes or areas (closed ways)
Not in ways (lines)
talkat.
dimka:Why exactly do we need the ways to be closed?
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?
talkat: dimka:Why exactly do we need the ways to be closed?
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.
dimka: talkat: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.
talkat: dimka: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.
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: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.
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