gsoc: KML writer/handlers for OsmPlacemarkData objects

Review Request #124522 - Created July 29, 2015 and submitted

Marius Stanciu
  • This completes the parsing/writing cycle: load ".osm" -> export as ".kml" -> import ".kml" -> export ".osm" -> repeat

  • I have made the custom XML schema very verbose, so as to be understandable and have a KMLish XML style.
    If you think it's too verbose. I can eliminate the <member> and <nd> wrapper tags and save their data
    as attributes

  • One small change had to be done: ExtendedData is now written after the Geometry within a <Placemark> tag ( @see change in KmlFeatureTagWriter.cpp )
    ( OsmPlacemarkData depends on the geometry, so that has to be initialized before, when parsing ".kml" files )

  • There is one known issue: if you import polygons from a ".osm" file, the polygon()->outerBoundary().nodeType() is GeoDataLineStringType, not GeoDataLinearRingType as it should be
    ( this, when written in ".kml" will result such a thing:
    <LineString> // this should be <LinearRing>
    <coordinates>-5.7129150009,-16.0033060822 -5.7131777661,-16.0038067061 -5.7124571297,-16.0041031487 -5.7119945396,-16.0034240531 -5.7124492636,-16.0031684483 -5.7129150009,-16.0033060822</coordinates>
    </LineString> )

I know what causes the issue, and i'm currently currently trying to fix it ( GeoDataLinearRing::GeoDataLinearRing( const GeoDataGeometry & other ) constructor does not initialize
it's own GeoDataLinearRingPrivate member )

created stuff within editor then done the cycle: export as ".osm" ----> load ".osm" ----> export as ".kml" ----> import ".kml" ----> export ".osm"
compared the initial ".osm" file with the last one, they are the same. ( except tag order inconsistencies cause by the QHash mechanism )
Unit tests coming soon.


  • 0
  • 1
  • 0
  • 1
Description From Last Updated
Marius Stanciu
Marius Stanciu
Dennis Nienhüser
Dennis Nienhüser
Marius Stanciu
Review request changed

Status: Closed (submitted)

Change Summary:

Submitted with commit b0facbb668284acb65def96a6d8fb66f30442cbd by Marius Stanciu to branch master.