Interlis leicht gemacht #8
29 May 2016
Für PostGIS-Anwender, die den Bezugsrahmenwechsel noch durchführen müssen, steht ja eine geniale Datenbankfunktion zur Verfügung, um die Daten wirklich innerhalb der Datenbank transfomieren zu können und nicht ein Drittwerkzeug bemühen zu müssen.
Als Transformationsgrundlage zwischen den beiden Bezugsrahmen dient die nationale Dreiecksvermaschung CHENyx06. Swisstopo stellt dafür eine DLL zur Verfügung. Die PostGIS-Funktion kann aber nichts mit dieser DLL anfangen, sondern erfordert die Dreiecksdefinitionen in beiden Bezugsrahmen als Polygon in einer einzigen Datenbanktabelle (was nebenbei bemerkt die Funktion enorm flexibel macht). Leider ist die Definition dieser Dreiecksvermaschung nirgends auffindbar. Ich habe einzig eine Spatialite-Datenbank, die ich aus Shape-Dateien zusammengeschustert habe, die ich vor Jahren bei swisstopo bestellt habe. Wäre die Definition nicht sogar ein Geobasisdatensatz?
Egal. Um aber die Dreiecksdefinition vom Spatialite-Joch zu befreien und den Import in die PostGIS-Datenbank vermeintlich einfacher zu gestalten, habe ich mir kurzerhand ein klitzekleines INTERLIS-Datenmodell zusammengebaut:
Der Datenumbau von der bereits bestehenden Datenbanktabelle (resultierend aus einem ogr2ogr-Import der Spatialite-Datenbank nach PostGIS) in die leere mit ili2pg angelegten Datenbanktabelle ist simpel:
INSERT INTO av_chenyx06.chenyx06_chenyx06 (nummer, nom, jahr_definiert, jahr_eliminiert, geom_lv03, geom_lv95)
SELECT num, nom, to_date(jahr_def::varchar, 'YYYY'), NULL::date AS jahr_elim,
ST_SnapToGrid(the_geom_lv03, 0.001),
ST_SnapToGrid(the_geom_lv95, 0.001)
FROM av_chenyx06.chenyx06_triangles;Die UML-Datei gibt es hier, das INTERLIS-Modell hier und die exportierte INTERLIS-Transferdatei hier. Es wurde bewusst nur eine Tabelle mit zwei Geometriespalten modelliert, da ja genau diese Konstellation von der ST_Fineltra-Funktion erwartet wird.
Ohne gross zu überlegen, kann man jetzt mit ili2pg die INTERLIS-Datei in die PostgreSQL-Datenbank importieren:
java -jar ili2pg.jar --dbhost localhost --dbport 5432 --dbdatabase rosebud2 --dbusr stefan --dbpwd ziegler12 --defaultSrsAuth EPSG --defaultSrsCode 21781 --createGeomIdx --strokeArcs --createUnique --nameByTopic --dbschema av_chenyx06 --modeldir "http://models.geo.admin.ch;." --models SO_CHENyx06_20160527 --import SO_CHENyx06.xtfDa sollten jetzt zwei Optionen ins Auge stechen: --defaultSrsAuth resp. --defaultSrsCode. Damit geben wir der Datenbank an, um welches Bezugssystem es sich handelt. In unserem Fall haben wir nun das Problem, das wir zwei unterschiedliche Bezugssysteme in einer einzigen Tabelle im INTERLIS-Modell haben. Dh. ili2pg importiert beiden Geometrien als LV03:
Auch die einzelnen Geometrien selbst sind als LV03 codiert. Folgende Abfrage
SELECT ST_AsEWK(geom_lv95) FROM av_chenyx06.chenyx06_chenyx06 LIMIT 1;ergibt:
"SRID=21781;POLYGON((2619108.994 1266953.473,2624004.381 1265802.492,2619830.525 1263811.084,2619108.994 1266953.473))"PostgreSQL/PostGIS wäre nicht PostgreSQL/PostGIS wenn die Rettung nicht bloss ein Einzeiler wäre:
ALTER TABLE av_chenyx06.chenyx06_chenyx06
ALTER COLUMN geom_lv95 TYPE geometry(Polygon, 2056)
USING ST_SetSRID(geom_lv95, 2056);Dieser Einzeiler setzt einerseits die korrekte SRID für die Tabelle als auch für jedes einzelne Feature ohne irgendetwas zu transformieren. Das Resultat der vorherigen Query ist:
"SRID=2056;POLYGON((2619108.994 1266953.473,2624004.381 1265802.492,2619830.525 1263811.084,2619108.994 1266953.473))"Und die Definition der Tabelle sieht jetzt wie gewünscht aus:
Das Problem mit den unterschiedlichen Bezugssystemen tauchte natürlich bereits beim Herstellen der INTERLIS-Transferdatei auf. Dabei wurde die leere Tabelle mit --schemaimport angelegt. Das Vorgehen war anschliessend identisch.