[Marble-devel] Review Request 124522: gsoc: KML writer/handlers for OsmPlacemarkData objects

[Marius Stanciu]

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/124522/
-----------------------------------------------------------

(Updated Aug. 16, 2015, 5:20 p.m.)


Status
------

This change has been marked as submitted.


Review request for Marble.


Changes
-------

Submitted with commit b0facbb668284acb65def96a6d8fb66f30442cbd by Marius Stanciu to branch master.


Repository: marble


Description
-------

- 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:
           <Polygon>
                <outerBoundaryIs>
                    <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 )


Diffs
-----

  src/lib/marble/geodata/CMakeLists.txt cb89e7f 
  src/lib/marble/geodata/handlers/kml/KmlMemberTagHandler.h PRE-CREATION 
  src/lib/marble/geodata/handlers/kml/KmlMemberTagHandler.cpp PRE-CREATION 
  src/lib/marble/geodata/handlers/kml/KmlNdTagHandler.h PRE-CREATION 
  src/lib/marble/geodata/handlers/kml/KmlNdTagHandler.cpp PRE-CREATION 
  src/lib/marble/geodata/handlers/kml/KmlOsmPlacemarkDataTagHandler.h PRE-CREATION 
  src/lib/marble/geodata/handlers/kml/KmlOsmPlacemarkDataTagHandler.cpp PRE-CREATION 
  src/lib/marble/geodata/handlers/kml/KmlTagTagHandler.h PRE-CREATION 
  src/lib/marble/geodata/handlers/kml/KmlTagTagHandler.cpp PRE-CREATION 
  src/lib/marble/geodata/writers/kml/KmlFeatureTagWriter.cpp f4a77ff 
  src/lib/marble/geodata/writers/kml/KmlOsmPlacemarkDataTagWriter.h PRE-CREATION 
  src/lib/marble/geodata/writers/kml/KmlOsmPlacemarkDataTagWriter.cpp PRE-CREATION 

Diff: https://git.reviewboard.kde.org/r/124522/diff/


Testing
-------

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.


Thanks,

Marius Stanciu

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/marble-devel/attachments/20150816/8c831ef5/attachment.html>