----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/124522/#review83166 -----------------------------------------------------------
It would be neat if we could provide an .xsd file for validation of .kml files that use elements in the mx namespace. Google provides it here for gx: https://developers.google.com/kml/schema/kml22gx.xsd We could upload that .xsd to marble.kde.org also such that tools can validate .kml files automatically. With the .xsd in place you could also verify .osm => .kml conversion results locally, see http://stackoverflow.com/a/573443 Regarding verbosity of the osm placemark data in KML I'm fine with the current approach. src/lib/marble/geodata/handlers/kml/KmlMemberTagHandler.cpp (line 55) <https://git.reviewboard.kde.org/r/124522/#comment57430> As the index is read from a parser attribute I'd prefer a safety check here that memberIndex is within the bounds of innerBoundaries. src/lib/marble/geodata/handlers/kml/KmlNdTagHandler.cpp (line 50) <https://git.reviewboard.kde.org/r/124522/#comment57491> I don't think returning 0 is considered an error. There are a couple of handlers that do that. Can you check the various documentation snippets whether the mx: namespace is consistently included? - Dennis Nienhüser On July 31, 2015, 5:37 p.m., Marius Stanciu wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/124522/ > ----------------------------------------------------------- > > (Updated July 31, 2015, 5:37 p.m.) > > > Review request for Marble. > > > 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 > >
_______________________________________________ Marble-devel mailing list [email protected] https://mail.kde.org/mailman/listinfo/marble-devel
