DE:Grenzen der Schweiz

OSM darf die Grenzen der Schweiz und von Lichtenstein importieren.

Datensatz

Der amtliche Datensatz "GG25" von SwissTopo umfasst:

• Landesgrenzen
• Kantonsgrenzen
• Bezirksgrenzen
• Gemeindegrenzen
• Gemeinschaftsareale (Kommunanzen)
• Staatswald Galm
• Seen mit einer Fläche > 5km²

Lagegenauigkeit: 3..8 m
Aktualität: jährliche Korrektur im April

Aktueller Stand der Grenzen in der Schweiz in OSM

Merkmale

Vorschlag - Verbesserungen willkommen!

• ref:ch:gemeindenummer o.ä. würde ich vorschlagen /al

Beschreibung	GG25	OSM
Gemeindenummer: gemäss Amtlichem Gemeindeverzeichnis der Schweiz (BFS)	OBJECTVAL	ref:bfs_Gemeindenummer
Kantonsnummer	KANTONSNR	ref:bfs_Kantonsnummer
Bezirksnummer	BEZIRKSNR	ref:bfs_Bezirksnummer
Seenummer; 0, wenn kein See	SEENR	ref:bfs_Seenummer
Gemeindename: gemäss Amtlichem Gemeindeverzeichnis der Schweiz (BFS)	GENAME	name
Gemeindeteil: 0 = ohne Exklave; 1..9 = mit Exklaven; 1= Hauptteil	GEMTEIL	wird in Relation gespeichert
Gemeindefläche: berechnet und auf Bezirks- und Kantonsflächen ausgeglichen, in Hektaren	AREA	?
Jahr der letzten Änderung	YEAROFCHAN	?

Nutzungsvereinbarung

Am 30.8.2010 wurde folgende Vereinbarung abgeschlossen:

Nutzungserlaubnis Swisstopo erteilt OpenStreetMap die Erlaubnis, die GG25-Daten in die OpenStreetMap-Datenbank zu übernehmen und unter der Lizenz von OpenStreetMap zu nutzen. OpenStreetMap verpflichtet sich, die Daten bei der Übernahme mit einem 'source'-Attribut zu ergänzen, mit dem Inhalt 'GG25 swisstopo 2010'. Die Daten werden von swisstopo kostenfrei zur Verfügung gestellt.

Import

Source

Bitte benutze source=GG25 swisstopo 2010

Änderungen in 2011 bekommen dann source=GG25 swisstopo 2011

von CH1903 zu WGS84

Parameter für proj4:

# CH 1903 / Swiss Oblique Cylindrical
<9814> +proj=somerc +lat_0=46d57'08.66"N +lon_0=7d26'22.50"E +ellps=bessel +x_0=600000 +y_0=200000 +towgs84=674.374,15.056,405.346 +units=m +k_0=1 +no_defs <>

Ogr2Osm

Mit dem Python-Programm Ogr2Osm werden Multipolygone automatisch aus den SHP-Flächen erstellt. Man kann zudem eine Übersetzungsdatei angeben, bei der Shape-Attribute in OSM-Tags gewandelt werden. Dies lässt sich aber auch im Nachhinein mit JOSM erledigen. Gemeinsam mit dem proj4-String zur Umwandlung in WGS84 sollte es ein relativ gutes Ergebniss liefern. Einzig die Nachbearbeitung und Löschung schon vorhandener Grenzen und Wasserflächen ist mittels dieser Methode Handarbeit.

 (c) Iván Sánchez Ortega, 2009

 python ogr2osm.py [options] [filename]

 Options:
  -e, --epsg=...             EPSG code, forcing the source data projection
       -p, --proj4=...       PROJ4 string, forcing the source data projection
  -v, --verbose              Shows some seemingly random characters dancing in the screen for every feature that's being worked on.
  -h, --help                 Show this message
  -d, --debug-tags           Outputs the tags for every feature parsed
       -a, --attribute-stats Outputs a summary of the different tags / attributes encountered
       -t, --translation     Select the attribute-tags translation method.
                             See the translations/ diredtory for valid values.

Nachbarn ermitteln

Für OSM müsste für jede mögliche Kombination von Nachbarn die gemeinsame Grenzlinie ermittelt, und in einen Weg umgewandelt werden, der dann mit boundary=administrative und admin_level=9 getaggt wird. Das kann man in PostGIS machen (also Shapefiles in PostGIS einlesen, dort dann rechnen lassen).

Frederik hat das vor einiger Zeit mal fuer Dresden gemacht und stichwortartig dokumentiert:

Shapefile mit shp2pgsql in Postgis einlesen (in eine neue Tabelle "dresden") [anmerkung: in den shapes, um die es hier ging, gab es eine spalte namens "sicad_txt", in der eine Zahl stand, die das Gebiet eindeutig beschrieb)

CREATE TABLE multilinestrings (
    id   SERIAL NOT NULL UNIQUE,
    gid1 INTEGER NOT NULL,
    gid2 INTEGER NOT NULL
);
SELECT AddGeometryColumn('multilinestrings', 'geom', 4326, 'MULTILINESTRING', 2);
INSERT INTO multilinestrings (gid1, gid2, geom) SELECT int4(a.sicad_txt), int4(b.sicad_txt), ST_Multi(ST_Intersection(a.the_geom, b.the_geom)) FROM dresden a, dresden b WHERE a.sicad_txt<b.sicad_txt AND ST_Touches(a.the_geom, b.the_geom);

Jetzt hat man die Linien, wo sich einzelne Stadtteile beruehren. Die Aussengrenze fehlt noch:

create table outline (id serial not null unique);
SELECT AddGeometryColumn('outline','geom',4326,'MULTILINESTRING',2);
insert into outline (id,geom) values(0, (select ST_Boundary(ST_Multi(ST_Union(the_geom))) as geom from dresden));
insert into multilinestrings(gid1,gid2,geom) select int4(a.sicad_txt),0,ST_Multi(ST_Intersection(a.the_geom, b.geom)) FROM dresden a, outline b where ST_Touches(a.the_geom,b.geom);

Und um die resultierenden multilinestrings zu zerlegen:

CREATE TABLE ways (
 id serial not null,
 gid1 INTEGER NOT NULL,
 gid2 INTEGER NOT NULL
 );
SELECT AddGeometryColumn('ways', 'geom', 4326, 'LINESTRING', 2);
INSERT INTO ways (geom, gid1, gid2) SELECT (ST_Dump(ST_LineMerge(geom))).geom, gid1, gid2 FROM multilinestrings;

Nun hat man alle Grenz-Ways als einzelne Geometrien in der Datenbank und kann mittels einem modifizierten shp2osm-Skript diese Ways in .osm-Dateien verwandeln und die passenden Relationen anlegen. Dazu habe ich ein Skript, das ist aber eine ziemliche Perl-Bastelwueste. Kann gern jeder haben, aber man muss sich schon mit Perl auskennen.

Ist nicht nötig, da das von ogr2osm bereits erledigt wird. --t-i 20:47, 30 August 2010 (BST)