Fwd: [Gdal-dev] Status Report KML Driver

[Christoph Ehrler]

somehow the conversation took place outside the mailing list...
sorry

---------- Forwarded message ----------
From: Christoph Ehrler <ehrler-soft at gmx.de>
Date: Sep 21, 2007 10:31 AM
Subject: Re: [Gdal-dev] Status Report KML Driver
To: Jens Oberender <j.obi at troja.net>


Hallo Jens,

wenn ich es richtig verstehe, dann bildest du erst die gesamte KML
Datei als DOM im Speicher ab...
this->poKMLFile->parse();

danach Klassifizierst du die KML-Tags/Elemente um Geometriedaten von
Nicht-Geometriedaten unterscheiden zu können...
this->poKMLFile->classifyNodes();

um dann die KML-Geometrien auszulesen und in OGR-Layers umzuwandeln
this->poKMLFile->findLayers(NULL);
...


Du hattest geschrieben, es ist notwendig die Struktur zu kennen.
Welche Probleme traten auf?? Eigentlich könnte man doch alles
vernachlässigen, was nicht <Placemark> untergeordnet ist und sich dann
nach und nach mit SAX durchhangeln...

Unser Problem ist, dass wir sehr grosse KML Dateien lesen und
schreiben wollen (über Netzwerk) und deswegen auf
Streaming-Funktionalität angewiesen sind (sprich SAX und nicht DOM).

Noch eine Frage:
Wie schalte ich die Debug-Meldungs-Ausgabe mit CPLDebug ein??


Danke und Grüsse
Christoph


On 9/20/07, Jens Oberender <j.obi at troja.net> wrote:
> Hi Christoph
>
> Ich schreib jetzt einfach mal auf deutsch, das ist einfacher. :-)
>
> Am Donnerstag 20 September 2007 schrieben Sie:
> > Hello Jens,
> >
> > your GDAL/OGR KML driver works fine. The only thing is I have to
> > remove the <MultiGeometry> tags manually with that GoogleEarth
> > brackets the polylines when creating a route. But that is already on
> > your TODO list...
>
> Ja, hab ich vor bald zu implementieren...
>
> > I dug into the source code and did some UML modeling to understand
> > what's going on. Some questions do arise:
> >
> > You use eXpat - a SAX parser - for parsing the KML file but then you
> > build your own DOM. That's a bit strange since you could have used a
> > DOM parser at all that follows the official DOM specifications and
> > releases you from coding it yourself.
>
> Ursprünglich war es nach SAX geplant, aber dann kamen beim implementieren
> Probleme auf, weil die Struktur erst mal analysiert werden muss. Deshalb hab
> ich dann einfach die Struktur nachempfunden.
>
> > Also it seems your DOM tree consists of strings entirely...
> > why didn't you map the KML file to internal classes with the
> > approriate data-types (string, float, integer) right at parsing time??
> > I'm not sure but isn't std::string much more memory consuming than
> > integer/float ??
>
> Ich wollte die Knoten möglichst generisch halten, so dass ich sie für alle
> Elemente verwenden kann. Deshalb sind die Felder auch Strings, weil ich sie
> dann in späteren Aktionen auswerten kann.
>
> > Do you really represent the whole KML file as a DOM because elements
> > like <Style> and <LookAt> are not mappable to OGR but are included in
> > your DOM?? I found no checks to exclude these elements...
> > If this is true the main benefit from using a SAX parser - that is
> > being able to parse KML files larger than the memory / low memory
> > consumption - would be gone...
>
> Ich nehm nur eine Untermenge der KML-Tags in den Baum auf. Entschieden wird
> das in der KMLVector Klasse. Später soll dann noch eine KMLRaster Klasse
> dazukommen, um KMLs in Raster zu laden.
>
> Das Speicherproblem kann man glaube ich nicht umgehen. In der KML Datasource
> Methode open kannst du die einzelnen Schritte sehen, mit der ich die KML zur
> späteren Behandlung aufbereite.
>
> Noch Fragen???
>
> Ciao,
>         Jens
>
> PS: Ab und zu bin ich auch im IRC #GDAL under dem Nick D|dge
>
>