Even,
Thanks – also for the additional background info!
Johannes

Von: Even Rouault <[email protected]>
Gesendet: Dienstag, 15. November 2022 13:27
An: Johannes Echterhoff <[email protected]>; 
[email protected]
Betreff: Re: [gdal-dev] GML driver - gml:xlink resolving - just embedding?


Johannes,

Does resolving of xlink:href by the GML driver (when GML_SKIP_RESOLVE_ELEMS is 
used, i.e., set to NONE or HUGE) simply mean that the referenced resource is 
copied into the XML element that contains the xlink:href XML attribute? Tests 
seem to support this, but I’d really like to double-check on this list.
Yes, that's my recollection of how it works.


My somewhat naive assumption was that if the reference pointed to another GML 
object, then that would be recognized somehow (though the exact “how” is 
probably the issue; document-internal reference via @gml:id could work, but not 
an external reference), and duplication of objects avoided. The resolving also 
seems to remove the xlink:href attributes for resolved references, and the 
gml:id attributes on the elements that are copied into the main GML file. That, 
in fact, creates duplicate objects in my test case.

Complex GML is a pain to deal with and the "classic" GML driver is close its 
maximum potential. I believe the GML_SKIP_RESOLVE_ELEMS feature was mostly used 
to deal with geometry elements (like part of a boundary being used in different 
geometries, in particular use of GML topology elements), for which the current 
copy&paste strategy is fine to reconstruct a simple feature geometry. When 
xlink:href points at objects/features, then the ideal strategy is indeed much 
harder to define.

For anything advanced, using GMLAS 
(https://gdal.org/drivers/vector/gmlas.html#vector-gmlas) is suggested. I won't 
say recommended to avoid people complaining that  it goes to the other extreme 
of returning an output that is (supposed to be) fully lossless regarding the 
original content but hard to comprehend.

Even

--

http://www.spatialys.com

My software is free, but my time generally not.
_______________________________________________
gdal-dev mailing list
[email protected]
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Reply via email to