[NAS] Erfahrungsbericht zum Laden von Alkisdaten

Gregor Fikoczek gregor.fikoczek at wheregroup.com
Die Feb 17 10:32:46 EST 2009


Hallo Herr Jäger, Hallo Liste, 

vielen Dank für die konstruktive Kritik, ich werde in der nächsten Woche (KW9) 
Zeit habe die von Ihnen vorgetragenen Punkte zu untersuchen. 


Bezüglich der Geometrie-Typen in einer Tabelle habe ich noch eine Frage an die 
Liste:

##########################

# Einige FatureTypes/Tabellen beinhalten nicht nur einen GeometrieTyp sondern 
mehrere. Die Erfahrung mit den verschiedenen Geometrien habe ich mit 
Demodaten gemacht, kann mir dies jemand bestätigen?

Wenn dem so sein sollte, so müsste man meiner Ansicht nach für jedes 
Geometrifeld eine Geometrie vom Typ Geometry-Collection anlegen.
Oder ist dies nur bei einzelnen FeatureTypes der Fall?

Grüße,
Gregor Fikoczek


Am Dienstag 17 Februar 2009 11:27:17 schrieb Jäger, Frank (KRZ):
> Moin,
> wie gestern beschrieben, führt die dynamische Generierung der
> Daten(bank)struktur aus dem Inhalt der ("ersten") Datei zu - wechselnden
> Geometrie-Typen je Objektart
>  - Fehlenden Feldern
>
> Weitere Tests ergaben, dass auch /Feldlängen/ und /Feldformate/ unpassend
> angelegt werden.
>
> Beispiel: Layer = Tabelle = "ax_georeferenziertegebaeudeadresse".
>
> In der ersten Datei wird als Ortsbezeichung gefunden: "Lage, Lippe"
> Daraus wird generiert:
>
> ortsnamepost		character(4), -- "Lage"
> zusatzortsname		character(7), -- ", Lippe"
>
> Ein Ortsname aus 4 Buchstaben ist verdammt knapp.
> So wird die Nachbarstadt "Bad Salzuflen" aus einer folgenden Datei zu "Bad
> ".
>
> Was würde aus "Neustadt am Rübenberge", vielleicht "Neus" "am Rübe"?
>
> Auch der nach dem Zufallsprinzip mit 23 Zeichen dimensionierte Strassenname
> führt zu abgeschnittenen Inhalten. Hier sollte man sich 50 Character
> gönnen.
>
> Das Feld "beginnt" enthält offensichtlich eine Zeitangabe z.B.
> "2008-06-10T15:19:17Z". Ein Feldformat "timestamp" erscheint mir passend.
> Ein manuell so angelegtes Feld bleibt allerdings leer, wird also nicht
> geladen.
>
> Die Lösung zu den verkürzten Feldern ist die gleiche wie zu den gestrigen
> Problemen: - SQL-Script mit Datenbank-Definitionen manuell erarbeiten.
> - Eine leere Datenbank damit anlegen, bevor die erste NAS-Datei mit
> "-append" geladen wird.
>
>
> Fragen:
> Die so nicht zu erschlagenden Fehler ..
>   - wechselnde Geometrie
>   - timestamp wird nicht gefüllt
> .. müssten Richtung Entwickler kommuniziert werden.
> Gibt es schon einen Trac?
> Bündelt und übersetzt das jemand (WhereGroup)?
>
>
> 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
> >
> >
> > ... ist es ein konzeptioneller
> > Fehler von PostNAS 0.3, die Datenbank-Struktur aus dem
> > (zufälligen) Inhalt der ersten Datei aufzubauen. Das
> > funktioniert mit Musterdaten in Form von *einer* Datei, nicht
> > aber bei größeren Gebieten, die aufgeteilt werden müssen.
>
> _______________________________________________
> NAS mailing list
> NAS at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/nas



-- 
Mit freundlichen Grüßen / Kind regards

Gregor Fikoczek



---------------------------------------
WhereGroup GmbH & Co. KG
Siemensstraße 8
53121 Bonn
Germany

Gregor Fikoczek
Email: gregor.fikoczek at wheregroup.com
Fon: +49 (0)228 / 90 90 38 - 25
Fax: +49 (0)228 / 90 90 38 - 11

info at wheregroup.com
www.wheregroup.com
Amtsgericht Bonn, HRA 6788
-------------------------------
Komplementärin:
WhereGroup Verwaltungs GmbH
vertreten durch:
Olaf Knopp, Peter Stamm
---------------------------------------