| Version 19 (modified by , 17 years ago) ( diff ) |
|---|
Todo
- check out Xerces and Expat
- explore existing code in gdal
KML 2.1 or 2.2
Points against 2.2:
- Still beta (date 05.06.2007)
- Only few new tags, which are useless for gdal
Points for 2.2:
- Support for Image Pyramids
XML Parser
The very first task is to choose XML parser that will be used as a foundation of the KML driver. There are many questions that have to be answered:
- SAX or DOM?
- provide XML validation for KML documents (mandatory, optional, none)?
- ...
There are 3 or 4 XML parsers under our consideration:
Here is very detailed comparison (made in 2003) of XML parsing libraries that may be helpful during the analysis.
| Feature | Expat | Xerces | minixml | libXML |
| Parser | SAX | SAX, DOM | DOM | DOM |
| Validating | no | yes | no | yes (w/o reparsing) |
| Encoding | UTF-8 | UTF-8/16,ASCII,latin1 | ASCII/UTF-8 | UTF-8/16,ASCII,latin1 |
| Library size | 150KB | ~4MB | built-in | ~1MB |
| Thread safe | yes | yes | yes | yes |
| Used in GDAL part | ? | GML, ILI | many places | not yet |
| ... | ... | ... | ... | ... |
SAX or DOM
Which technic should be used for reading the KML files?
- I (Jens) guess SAX would be best, because of the memory consumption of DOM
- SAX is more complex to use in case of KML
Links
- KML read support for the existing driver - an overview at the GSoC Mentor Home page.
- KML Documentation
- kml21.xsd - XML Schema for KML
- Wikipedia
GML SDK
Brian McClendon, from Google, has indicated that he would like to see an industrial quality standalone C++ GML SDK that could be used by other companies wanting to work with KML. Desirable things for such an SDK would include:
- Standalone with no dependencies on OGR. Possibly not even on CPL though that might be inconvenient in the GDAL context.
- Use a safe XML parser like Expat rather than an unsafe (security wise) one like Xerces or make the xml parser easily pluggable.
- Support the whole KML feature model, even stuff not of use for OGR.
- Support all versions of KML.
The OGR driver would then presumably be built on the standalone SDK. This is similar to how the GML driver is structured since it was originally implemented for use in a non-OGR environment.
Contacts
- Michael Ashbridge of the Google Earth team has offered to be a technical resource on KML support (email is mashbridge at google dotcom)
