[NAS] Erfahrungsbericht zum Laden von Alkisdaten

["Jäger, Frank (KRZ)"]

Hallo


Versuch:

Eine Tabelle in der Datenbank manuell anlegen (mit allen Attributen) und mit 

 # ogr2ogr ..... [layername]

nur diese Tabelle laden.


Ergebnis:

- ax_flurstuecke  
erfolgreich

- ax_gebaeude      
Geometriefeld vom Typ "POLYGON" klappt bei den meisten Dateien, aber bei einigen Dateien erzeugt PostNAS SQL-Inserts mit "MULTIPOLYGON". Klar, es gibt ja auch Gebäude mit "Atrium".
Es wird dann nicht nur das Gebäude übersprungen, sondern das Laden dieser Dateien wird komplett abgebrochen.
Legt man das Geometriefeld für ax_gebaeude gleich mit MULTIPOLYGON an, lassen sich aber alle anderen Dateien nicht laden (Dabei müsste nur eine Klammer mehr um die Koordinaten).


Fragen:

- Wie ist in einer NAS-Datei der Geometrietyp einer Objektart beschrieben?

- Darf das gemischt sein? (Vielleicht liegt es ja an den Daten)


Weitere Möglichkeiten:

- Die Prüfung des Geometrietyps kann man in der Datenbank ausschalten.
  Auskommentieren der Zeile:
  CONSTRAINT ... CHECK (((geometrytype(wkb_geometry) = ...

Im Fall POLYGON/MULTIPOLYGON  kann man später mit der Function MULTI() auswerten.
Aber bei der heute morgen geschilderten Mischung aus POLYGON und POINT hilft das auch nichts. 


Vorschlag:

Der Konverter sollte sich am Geometrietyp der Datenbank orientieren und wenn möglich diesen Typ beim Insert verwenden.
Wenn nicht möglich, sollte das Objekt protokolliert und überschrungen oder ohne Geometrie gespeichert werden damit der Rest der Datei noch geladen wird.


Mit freundlichen Grüßen
F. Jäger 


> -----Original Message-----
> From: nas-bounces at lists.osgeo.org 
> [mailto:nas-bounces at lists.osgeo.org] On Behalf Of "Jäger, Frank (KRZ)"
> Sent: Monday, February 16, 2009 1:23 PM
> To: Entwicklung einer NAS Schnittstelle
> Subject: RE: [NAS] Erfahrungsbericht zum Laden von Alkisdaten
> 
> Es scheint noch Verwirrung zu herrschen bezüglich des 
> Geometrie-Typs einzelner Elemente:
> 
...
> 
> Gibt es in ALKIS/NAS keinen festgelegten Geometrietyp für 
> eine Objektart?
> 
> Wir werden ein SQL-Script erstellen müssen, dass vor der 
> ersten Konvertierung eine komplette Datenbank mit allen 
> vorkommenden Attributen aufbaut.
>