<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Johannes,<br>
</p>
<blockquote type="cite"
cite="mid:GV1P193MB2232B523304B81154C2F1CB5FC049@GV1P193MB2232.EURP193.PROD.OUTLOOK.COM">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<meta name="Generator" content="Microsoft Word 15 (filtered
medium)">
<style>@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
font-size:11.0pt;
font-family:"Calibri",sans-serif;
mso-fareast-language:EN-US;}span.E-MailFormatvorlage17
{mso-style-type:personal-compose;
font-family:"Calibri",sans-serif;
color:windowtext;}.MsoChpDefault
{mso-style-type:export-only;
mso-fareast-language:EN-US;}div.WordSection1
{page:WordSection1;}</style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
<div class="WordSection1">
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span lang="EN-US">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.
</span></p>
</div>
</blockquote>
Yes, that's my recollection of how it works.<br>
<blockquote type="cite"
cite="mid:GV1P193MB2232B523304B81154C2F1CB5FC049@GV1P193MB2232.EURP193.PROD.OUTLOOK.COM">
<div class="WordSection1">
<p class="MsoNormal"><span lang="EN-US"><o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">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.</span></p>
</div>
</blockquote>
<p>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.<br>
</p>
<p>For anything advanced, using GMLAS
(<a class="moz-txt-link-freetext" href="https://gdal.org/drivers/vector/gmlas.html#vector-gmlas">https://gdal.org/drivers/vector/gmlas.html#vector-gmlas</a>) 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.<br>
</p>
<p>Even<br>
</p>
<pre class="moz-signature" cols="72">--
<a class="moz-txt-link-freetext" href="http://www.spatialys.com">http://www.spatialys.com</a>
My software is free, but my time generally not.</pre>
</body>
</html>