AW: [Freezvaut-devel] Gemeinsame Mapdateien für EDBSILON und EDBS2WKT?

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

Hallo,
vielleicht sollte ich das Datenmodell von EDBS2WKT hier kurz erläutern, ohne zu sehr in Detail zu gehen.

Es gibt 9 Tabellen, die Geometrien enthalten.
Die Geometrien aller Folien werden dort gemeinsam eingetragen.
Die Filterung nach "Folien" erfolgt über gespeicherte Abfragen ("Views").

Nicht jede Folie hat Einträge in jeder Tabelle.
Die theoretische Menge an Views 
  (Anzahl ALK-Folien)  x  (Anzahl Geometrie-Tabellen) 
.. wird daher bei weitem nicht erreicht.

Die Views werden als SQL-Script ausgeliefert.
Die von CCGIS erstellten Map-Dateien rufen grundsätzlich diese Views auf, nicht direkt die Tabellen.

==> Diese Views wären eine gute Stelle zur Harmonisierung der Datenstrukturen! 

Die Geometrie-Tabellen "hängen" alle mit Foreign-Key-Constraint an der Tabelle "alkObjekte".
Die hat genau einen Eintrag je ALK-Objektnummer.
Bei Fortführung über BZSN wird nur der Eintrag in alkObjekte gelöscht, den Rest macht das DBMS.

Es gibt noch eine Gruppe mit Tabellen für Objektnamen (nicht verwechseln mit Objektnummern).
Die dienen nicht der Darstellung sondern der Navigation (Suche) oder der Verbindung zu anderen Datenbanken (z.B. ALB).
Es wird so auch verhindert, dass zu einem Flurstückskennzeichen mehrere Objekte vorhanden sind (muss 1:1 sein!).

Objektnamen sind z.B. die "Adresse" eines Gebäudeobjektes oder das (ALB-) "Flurstückskennzeichen" eines Flurstücksobjektes.

Der Rest sind Hilfstabellen und Schlüsseltabellen.

Nun zu den 9 Geometrie-Tabellen, die für Map-Dateien relevant sind.

** Elementare Geometrie (ALK-Definitionsgeometrie), 
   genau 1 Eintrag je Objekt je nach Typ des Objektes in einer der 3 Tabellen:
1.  Flächen (Multipolygone)
2.  Linien 
3.  Punkte

** Texte
4.  durch Linie definiert
5.  durch Punkt und Drehwinkel definiert

** Ausgestaltungsgeometrie der ALK (mehrmals je Objekt möglich)
6.  Linien  (z.B. "Balkon" und "Durchfahrt" eines Gebäudes)
7.  Symbole (z.B. "Signatur Gartenland")

** Um "spezielle Anforderungen der ALK" abzubilden brauchen wir noch 2 Tabellen
8.  Begleitsignatur an einer Linie (links, rechts) für Flurgrenze usw.
9.  Der Rand einer Fläche (aus 1.) wird besonders dargestellt,
    wenn die Objektart der Line (Rand) abweicht von der Objektart des Objektes (Fläche)
    z.B. offene und geschlossene Seiten eines Carports


Das war's in Kürze.
Mehr in:  http://62.153.231.87/alk/edbs2wkt/help/dbtab.htm


mfG
F.J.


-----Ursprüngliche Nachricht-----
Von: freezvaut-devel-bounces at wald.intevation.org
[mailto:freezvaut-devel-bounces at wald.intevation.org]Im Auftrag von Silke
Reimer
Gesendet: Donnerstag, 15. Dezember 2005 17:41
An: freezvaut-devel at wald.intevation.org
Betreff: Re: [Freezvaut-devel] Gemeinsame Mapdateien für EDBSILON und
EDBS2WKT?



Hallo Frank,

da ich relativ stark an der Entwicklung von edbsilon beteiligt war und bin,
wollte ich mich an dieser Stelle auch noch einmal zu Wort melden.

On Wed, Dec 14, 2005 at 06:20:55PM +0100, "Jäger, Frank \(KRZ\)" wrote:
> Hallo Liste bzw. Hallo Entwickler,

[...]

> 
> Aus Zeitgründen konnte ich diesen Konverter noch nicht näher betrachten.
> Ich weiß insbesondere nicht, welche Datenbankstrukturen aus den EDBS-Daten
> erzeugt werden.
> Unter den gegebenen gleichen Rahmenbedingungen "ALK" und "OGC" vermute ich
> jedoch starke Ähnlichkeiten.

Im Detail habe ich mir das Modell von EDBS2WKT auch noch nicht angeschaut,
aber so viele fundamental unterschiedliche Möglichkeiten, ALK-Daten in Shapefiles
oder relationalen Tabellen zu speichern gibt es ja auch nicht. Insofern
dürften die Datenmodell tatsächlich einigermaßen ähnlich sein.

> 
> 
> Nun zu meinen Fragen:
> 
> Werden die in diesem Projekt entstehenden Map-Dateien ausschließlich mit
> dem Konverter EDBSILON zu verwenden sein?
> 
> Wäre es möglich, durch kleine Anpassungen z.B. am DATA-Statement die
> Mapdateien auch für den Konverter EDBS2WKT zu verwenden?

Prinzipiell natürlich ja. Entscheidend ist hierbei natürlich, dass nicht nur
die Namen der Shapefiles bzw. PostGIS-Tabellen sondern auch die dahinter
liegende Struktur passen muss (s.u.).

> 
> 
> Ich fände es sehr sinnvoll die Arbeiten für die ZVAut-konforme
> ALK-Darstellung zu bündeln und gemeinsam an den Mapdateien weiter zu
> arbeiten.
> Es wäre schade, wenn diese Arbeiten doppelt, nämlich für jeden Konverter
> getrennt, geleistet werden müssen.

Ja, da hast Du recht. U.a. deswegen wurde das Projekt FreeZVAUT ja auch
gegründet, nämlich um eine Plattform zu schaffen, auf der eine solche
Harmonisierung diskutiert werden kann - insofern: willkommen an Bord :-)

> 
> Wie ich sehe (siehe unten: "... das entstehende Datenmodell") ist die
> Datenstruktur von EDBSILON noch in Änderung.
> Vielleicht können die Strukturen beider Konverter soweit harmonisiert
> werden, dass eine gemeinsame Nutzung der Mapdateien möglich wird.

Generell ist das Datenmodell von edbsilon nicht auf ein konkretes
Datenmodell festgelegt. In welche Tabellen und Attribute die verschiedenen
Daten geschrieben werden, wird über eine Konfigurationsdatei festgelegt, die
dabei relativ viele Freiheiten zulässt.  Sie ließe sich u.U. tatsächlich so
konfigurieren, dass das Datenmodell von edbsilon sehr nah an dem von
EDBS2WKT ist.

Die Hauptanpassungen, die ich an edbsilon für die annähernd ZVAUT-konforme
Darstellung der ALK-Daten derzeit sehe, ist die Generierung von
Zusatzinformationen, die für die Darstellung benötigt werden, z.B. um den
Winkel von Gebäudeschraffuren richtig setzen zu können. Da habt Ihr ja, wenn
ich das richtig sehe, durchaus schon Lösungen in EDBS2WKT integriert,
richtig?

Viele Grüße,

	Silke

-- 
Intevation GmbH

Georgstrasse 4                    49074 Osnabrück, Germany
http://intevation.de              http://intevation.de/~silke
FreeGIS.org                       http://freegis.org/