Hi,
while we are redoing all our boundaries in Switzerland, could we maybe discuss the format of the boundary relations once more?
In particular, I'd like to get rid of the subparts in those relations. As far as I know, we are the only country to include this subparts in the boundary relations. So, the first reason would be that we should do as everybody else.
The second reason is that the relation, as it is now, is a pain to process. In most other countrys, subrelations are used to group parts of the boundary (see France for example). Not so in Switzerland. Just because of us, special processing is needed (i.e. looking at the role).
I don't think the whole hierarchical grouping is needed at all. So, I would be really happy if they are just deleted. But if you really must have it, how about moving the subparts in the nation relation: http://www.openstreetmap.org/browse/relation/16042
Sarah
Hello,
I like this subarea because with it it's easy to get all the canton boundaries, but it's true that is not specified in the boundary relation, than it's a good idea to move it to nation relation who it's not strictly defined.
CU Stéphane
On Tue, Jul 19, 2011 at 10:28 AM, Sarah Hoffmann lonvia@denofr.de wrote:
Hi,
while we are redoing all our boundaries in Switzerland, could we maybe discuss the format of the boundary relations once more?
In particular, I'd like to get rid of the subparts in those relations. As far as I know, we are the only country to include this subparts in the boundary relations. So, the first reason would be that we should do as everybody else.
The second reason is that the relation, as it is now, is a pain to process. In most other countrys, subrelations are used to group parts of the boundary (see France for example). Not so in Switzerland. Just because of us, special processing is needed (i.e. looking at the role).
I don't think the whole hierarchical grouping is needed at all. So, I would be really happy if they are just deleted. But if you really must have it, how about moving the subparts in the nation relation: http://www.openstreetmap.org/browse/relation/16042
Sarah _______________________________________________ talk-ch mailing list talk-ch@openstreetmap.ch http://lists.openstreetmap.ch/mailman/listinfo/talk-ch
Hi all,
first of all: the import should be ready this weekend. I used the simplifier-plugin in JOSM which reduced the nodes from over one million down to about 360'000.. Handling is a lot easier now.
Sarah wrote:
while we are redoing all our boundaries in Switzerland, could we maybe discuss the format of the boundary relations once more?
You mean if type=boundary or type=multipolygon? :->
In particular, I'd like to get rid of the subparts in those relations.
Lucky you, the new relations will be without hierarchy anyway, so that's a good moment to separate them. Because - as Stéphane says - it's just practical to have the hierarchy included in relations and not just the 'raw' data..
Is there any accepted tagging scheme?
Regards, Thomas
Hi,
On Thu, Jul 21, 2011 at 01:03:31AM +0200, Thomas Ineichen wrote:
Hi all,
first of all: the import should be ready this weekend. I used the simplifier-plugin in JOSM which reduced the nodes from over one million down to about 360'000.. Handling is a lot easier now.
Sarah wrote:
while we are redoing all our boundaries in Switzerland, could we maybe discuss the format of the boundary relations once more?
You mean if type=boundary or type=multipolygon? :->
boundary=*, the type tag is sooo out of fashion. ;)
In particular, I'd like to get rid of the subparts in those relations.
Lucky you, the new relations will be without hierarchy anyway, so that's a good moment to separate them. Because - as Stéphane says - it's just practical to have the hierarchy included in relations and not just the 'raw' data..
As I said, 'practical' depends on your point of view. If you try to build polygons from the relations, those are very impractical. And I know I'm fighting windmills here but may I point out once more that relations are NOT bookmarks. If you need all boundaries in Switzerland, you can use the XAPI.
Is there any accepted tagging scheme?
Looking at the boundary page in the Wiki again, it seems that somebody actually did make the subarea an official role. I checked the database now and only the Czech Republic seems to actually use this (and some smaller counties in Spain and Japan). Altogether about 6000 out of 160.000 boundary relations. On the other hand, we are also the only ones to have a relation "type=nation". So, no, there is no accpeted tagging schema, I'd say.
Sarah
Hi
Hi,
On Thu, Jul 21, 2011 at 01:03:31AM +0200, Thomas Ineichen wrote:
Hi all,
first of all: the import should be ready this weekend. I used the simplifier-plugin in JOSM which reduced the nodes from over one million down to about 360'000.. Handling is a lot easier now.
Sarah wrote:
while we are redoing all our boundaries in Switzerland, could we maybe discuss the format of the boundary relations once more?
You mean if type=boundary or type=multipolygon? :->
boundary=*, the type tag is sooo out of fashion. ;)
In particular, I'd like to get rid of the subparts in those relations.
Lucky you, the new relations will be without hierarchy anyway, so that's a good moment to separate them. Because - as Stéphane says - it's just practical to have the hierarchy included in relations and not just the 'raw' data..
As I said, 'practical' depends on your point of view. If you try to build polygons from the relations, those are very impractical. And I know I'm fighting windmills here but may I point out once more that relations are NOT bookmarks. If you need all boundaries in Switzerland, you can use the XAPI.
Is there any accepted tagging scheme?
Looking at the boundary page in the Wiki again, it seems that somebody actually did make the subarea an official role. I checked the database now and only the Czech Republic seems to actually use this (and some smaller counties in Spain and Japan). Altogether about 6000 out of 160.000 boundary relations. On the other hand, we are also the only ones to have a relation "type=nation". So, no, there is no accpeted tagging schema, I'd say.
It would be useful to have some guidelines to follow for the swiss boundaries if there is no global consent. As I never really used boundaries for anything I suggest somebody who did comes up with a simple step by step guide how to build the relations once thomas did the upload. Sarah? :-)
Beni
Am Fri, 22 Jul 2011 16:23:47 +0200 (CEST) schrieb Beni Buess beni@benel.net:
Hi
Hi,
On Thu, Jul 21, 2011 at 01:03:31AM +0200, Thomas Ineichen wrote:
Hi all,
first of all: the import should be ready this weekend. I used the simplifier-plugin in JOSM which reduced the nodes from over one million down to about 360'000.. Handling is a lot easier now.
Sarah wrote:
while we are redoing all our boundaries in Switzerland, could we maybe discuss the format of the boundary relations once more?
You mean if type=boundary or type=multipolygon? :->
boundary=*, the type tag is sooo out of fashion. ;)
In particular, I'd like to get rid of the subparts in those relations.
Lucky you, the new relations will be without hierarchy anyway, so that's a good moment to separate them. Because - as Stéphane says
- it's just practical to have the hierarchy included in relations
and not just the 'raw' data..
As I said, 'practical' depends on your point of view. If you try to build polygons from the relations, those are very impractical. And I know I'm fighting windmills here but may I point out once more that relations are NOT bookmarks. If you need all boundaries in Switzerland, you can use the XAPI.
Is there any accepted tagging scheme?
Looking at the boundary page in the Wiki again, it seems that somebody actually did make the subarea an official role. I checked the database now and only the Czech Republic seems to actually use this (and some smaller counties in Spain and Japan). Altogether about 6000 out of 160.000 boundary relations. On the other hand, we are also the only ones to have a relation "type=nation". So, no, there is no accpeted tagging schema, I'd say.
As I have now done the admin_level 5/6 for some cantons (and missed to use the existing relations for these -shame on me-) i have dived into this boundary relation stuff for the first time. I was a bit confused by the use of the place key in the boundary relation of Aargau for example, as it is not mentioned at [1]. There are relations for admin_level 6 which have some subparts relation, but not all the possible subparts, a bit inconsistent :-) I'd expected to see just ways (and probably the admin_centre) as childs of boundary relations with admin_level>6 but it seems to be a inconsistent bookmark-tree.
Here I am, not sure if I should revert my newly created boundary relations (admin_level 5/6) with just ways as members and reuse the existing ones, removing all the old ways and adding the new ones. I'm not sure as well about what to do with the admin_level=4 relation.
Any suggestions?
I'm with you Sarah, we should get rid of this bookmarking stuff. seems to be too much work to have it in a consistent state to me. And yes, we can use the XAPI to get all the boundaries (unfortunately some ways near the border are missing, but it is easy to load them from the API manually for now).
Good night. Beni
Zitat von Beni Buess beni@benel.net:
As I have now done the admin_level 5/6 for some cantons (and missed to use the existing relations for these -shame on me-) i have dived into
Just as a short notice:
Because of the relicensing thing, I'd suggest to only use new relations for everything we do with the boundaries..
Regards, Thomas
On Mon, Jul 25, 2011 at 10:01:57AM +0200, Thomas Ineichen wrote:
Zitat von Beni Buess beni@benel.net:
As I have now done the admin_level 5/6 for some cantons (and missed to use the existing relations for these -shame on me-) i have dived into
Just as a short notice:
Because of the relicensing thing, I'd suggest to only use new relations for everything we do with the boundaries..
Good point. New relations it is. But for the moment I'll reuse the country relation to put the new ways into. You can move the whole thing into a new relation afterwards. Fixing the country relation is tricky enough as it is. (If Switzerland is gone by tomorrow, you know where to complain. ;) )
As for the place tag. I agree, it's not necessary, I just deleted it for Graubuenden as well.
Sarah
Hello,
For me this import is relay great ;-)
I just have some questions: - Is the import ended (Can we start to fix boundaries with others countries ? I started to fix it in the Lac Leman, I leave the old boundary because It seem more accurate. - I see a relation for « Lac Léman (VD) » I don't find it relay useful, than can we delete relation like it ? - I don't see ans relation for district, is it plan to import on a second time or should we create them manually ? - How do you plane to remove the old boundaries ? with a bot ? (with JOSM it's nearly impossible ...)
CU Stéphane
On Mon, Jul 25, 2011 at 9:51 PM, Sarah Hoffmann lonvia@denofr.de wrote:
On Mon, Jul 25, 2011 at 10:01:57AM +0200, Thomas Ineichen wrote:
Zitat von Beni Buess beni@benel.net:
As I have now done the admin_level 5/6 for some cantons (and missed to use the existing relations for these -shame on me-) i have dived into
Just as a short notice:
Because of the relicensing thing, I'd suggest to only use new relations for everything we do with the boundaries..
Good point. New relations it is. But for the moment I'll reuse the country relation to put the new ways into. You can move the whole thing into a new relation afterwards. Fixing the country relation is tricky enough as it is. (If Switzerland is gone by tomorrow, you know where to complain. ;) )
As for the place tag. I agree, it's not necessary, I just deleted it for Graubuenden as well.
Sarah _______________________________________________ talk-ch mailing list talk-ch@openstreetmap.ch http://lists.openstreetmap.ch/mailman/listinfo/talk-ch
Hi Stéphane,
I just have some questions:
- Is the import ended (Can we start to fix boundaries with others countries ? I started to fix it in the Lac Leman, I leave the old boundary
because It seem more accurate.
Yes. All data we've got from Swisstopo is now imported.
- I see a relation for « Lac Léman (VD) » I don't find it relay
useful, than can we delete relation like it ?
IMHO: Yes.
If a multipolygon has "swisstopo:OBJEKTART=Kantonsgebiet" tagged, that means that this part does not belong to any municipality but only to the canton. They ended up as level-8-boundary because Swisstopo split up the whole area of Switzerland.
- I don't see ans relation for district, is it plan to import on a
second time or should we create them manually ?
Unfortunately, the district relations are not part of the Swisstopo- data, so we have to recreate them manually. You can collect all polygons with the same "swisstopo:BEZIRKSNUM", as this is the district ID.
- How do you plane to remove the old boundaries ? with a bot ? (with
JOSM it's nearly impossible ...)
Don't know yet. ;) Most important for the moment is, that they don't show up on any map anymore..
Regards, Thomas
Hello Thomas,
Thanks for your response...
On Tue, Jul 26, 2011 at 11:33 PM, Thomas Ineichen osm.mailinglist@t-i.ch wrote:
Hi Stéphane,
I just have some questions:
- Is the import ended (Can we start to fix boundaries with others countries ?
I started to fix it in the Lac Leman, I leave the old boundary because It seem more accurate.
Yes. All data we've got from Swisstopo is now imported.
- I see a relation for « Lac Léman (VD) » I don't find it relay
useful, than can we delete relation like it ?
IMHO: Yes.
If a multipolygon has "swisstopo:OBJEKTART=Kantonsgebiet" tagged, that means that this part does not belong to any municipality but only to the canton. They ended up as level-8-boundary because Swisstopo split up the whole area of Switzerland.
Than if there not any opposition I will remove them.
- I don't see ans relation for district, is it plan to import on a
second time or should we create them manually ?
Unfortunately, the district relations are not part of the Swisstopo- data, so we have to recreate them manually. You can collect all polygons with the same "swisstopo:BEZIRKSNUM", as this is the district ID.
OK, I start to create them again in Vaud, ...
- How do you plane to remove the old boundaries ? with a bot ? (with
JOSM it's nearly impossible ...)
Don't know yet. ;) Most important for the moment is, that they don't show up on any map anymore..
OK, Your true that it's the most important ;-)
CU Stéphane
Regards, Thomas
talk-ch mailing list talk-ch@openstreetmap.ch http://lists.openstreetmap.ch/mailman/listinfo/talk-ch
Hi
To find the old admin_level=6 (Bezirke) relations and reuse them with the new boundaries the following is useful:
http://xapi.openstreetmap.ch:8080/xapi/api/0.6/relation%5Bold:admin_level=6%...
Happy relation-building :-)
Thomas, have you already made a wiki page for the import? You mentioned that during the meeting in Rapperswil, but i can't find it. Would be useful to organise the work on the admin_level=6 relations a bit.
Beni
Am Sun, 24 Jul 2011 21:22:42 +0200 schrieb Beni Buess beni@benel.net:
Hi
To find the old admin_level=6 (Bezirke) relations and reuse them with the new boundaries the following is useful:
http://xapi.openstreetmap.ch:8080/xapi/api/0.6/relation%5Bold:admin_level=6%...
Happy relation-building :-)
Thomas, have you already made a wiki page for the import? You mentioned that during the meeting in Rapperswil, but i can't find it. Would be useful to organise the work on the admin_level=6 relations a bit.
:-) open your eyes
I've added a table to this wiki page [1] to keep track of the work. Add your name to this table before you create relations for admin_level 5/6.
[1] http://wiki.openstreetmap.org/wiki/EN:Switzerland/swissBOUNDARIES3D
Hi all,
I've added a table to this wiki page [1] to keep track of the work. Add your name to this table before you create relations for admin_level 5/6.
[1] http://wiki.openstreetmap.org/wiki/EN:Switzerland/swissBOUNDARIES3D
The import is now done and all cantons can found in this relation: http://www.openstreetmap.org/browse/relation/1685640
I'll write a short summary tomorrow on how you can help to improve the data (aka what relations should be created)
Regards, Thomas
-
Beni Buess -
Sarah Hoffmann -
Stéphane Brunner -
Thomas Ineichen