File: drv_gml.html

package info (click to toggle)
gdal 1.10.1+dfsg-8
  • links: PTS, VCS
  • area: main
  • in suites: jessie, jessie-kfreebsd
  • size: 84,320 kB
  • ctags: 74,726
  • sloc: cpp: 677,199; ansic: 162,820; python: 13,816; cs: 11,163; sh: 10,446; java: 5,279; perl: 4,429; php: 2,971; xml: 1,500; yacc: 934; makefile: 494; sql: 112
file content (483 lines) | stat: -rw-r--r-- 23,724 bytes parent folder | download
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
<html>
<head>
<title>GML - Geography Markup Language</title>
</head>

<body bgcolor="#ffffff">

<h1>GML - Geography Markup Language</h1>

OGR has limited support for GML reading and writing. Update of existing
files is not supported.<p>

Supported GML flavors :
<table border>
<tr><th>OGR version</th><th>Read</th><th>Write</th></tr>
<tr><td>OGR &gt;= 1.8.0</td>
    <td>GML2 and GML3 that can<br>be translated into simple feature model</td>
    <td>GML 2.1.2 or GML 3 SF-0<br>(GML 3.1.1 Compliance level SF-0)</td>
</tr>
<tr><td>OGR &lt; 1.8.0</td><td>GML2 and limited GML3</td><td>GML 2.1.2</td></tr>
</table>
<p>

<h2>Parsers</h2>

The reading part of the driver only
works if OGR is built with Xerces linked in. Starting with OGR 1.7.0, when
Xerces is unavailable, read support also works if OGR is built with Expat linked in.
XML validation is disabled by default.
GML writing is always supported, even without Xerces or Expat.<p>

Note: starting with OGR 1.9.0, if both Xerces and Expat are available at build time,
the GML driver will preferentially select at runtime the Expat parser for cases where it is possible
(GML file in a compatible encoding), and default back to Xerces parser in other cases.
However, the choice of the parser can be overriden by specifying the <b>GML_PARSER</b>
configuration option to <b>EXPAT</b> or <b>XERCES</b>.<p>

<h2>CRS support</h2>

Since OGR 1.8.0, the GML driver has coordinate system support. This is
only reported when all the geometries of a layer have a srsName attribute,
whose value is the same for all geometries. For srsName such as "urn:ogc:def:crs:EPSG:",
for geographic coordinate systems (as returned by WFS 1.1.0 for example), the axis order
should be (latitude, longitude) as required by the standards, but this is
unusual and can cause issues with applications unaware of axis order. So
by default, the driver will swap the coordinates so that they are in the
(longitude, latitude) order and report a SRS without axis order specified.
It is possible to get the original (latitude, longitude) order and SRS with axis order
by setting the configuration option <b>GML_INVERT_AXIS_ORDER_IF_LAT_LONG</b>
to <b>NO</b>.<p>
There also situations where the srsName is of the form "EPSG:XXXX" (whereas
"urn:ogc:def:crs:EPSG::XXXX" would have been more explicit on the intent) and
the coordinates in the file are in (latitude, longitude) order. By default, OGR will
not consider the EPSG axis order and will report the coordinates in (latitude,longitude)
order. However, if you set the configuration option <b>GML_CONSIDER_EPSG_AS_URN</b> to
<b>YES</b>, the rules explained in the previous paragraph will be applied.<p>
Since OGR 1.10, the above also applied for projected coordinate systems whose EPSG
preferred axis order is (northing, easting).<p>

<h2>Schema</h2>

In contrast to most GML readers, the OGR GML reader does not require
the presence of an XML Schema definition of the feature classes (file with .xsd
extension) to be able to read the GML file. If the .xsd file is absent or
OGR is not able to parse it, the driver attempts to automatically discover
the feature classes and their associated properties by scanning the file and
looking for "known" gml objects in the gml namespace to determine the organization.
While this approach is error prone, it has the advantage of working for GML files
even if the associated schema (.xsd) file has been lost.<p>

Starting with OGR 1.10, it is possible to specify an explicit filename for the XSD
schema to use, by using "a_filename.gml,xsd=another_filename.xsd" as a connection string.<p>

The first time a GML file is opened, if the associated .xsd is absent or could not been
parsed correctly, it is completely scanned in order to
determine the set of featuretypes, the attributes associated with each and
other dataset level information.  This information is stored in a .gfs file
with the same basename as the target gml file.  Subsequent accesses to the
same GML file will use the .gfs file to predefine dataset level information
accelerating access.  To a limited extent the .gfs file can be manually edited
to alter how the GML file will be parsed.  Be warned that the .gfs file will
be ignored if the associated .gml file has a newer timestamp.
<p>

When prescanning the GML file to determine the list of feature types, and
fields, the contents of fields are scanned to try and determine the type of the
field.  In some applications it is easier if all fields are just treated as
string fields.  This can be accomplished by setting the configuration option
<b>GML_FIELDTYPES</b> to the value <b>ALWAYS_STRING</b>.<p>

OGR 1.8.0 adds support for detecting feature attributes in nested GML elements
(non-flat attribute hierarchy) that can be found in some GML profiles
such as UK Ordnance Survey MasterMap. OGR 1.8.0 also brings support for reading
IntegerList, RealList and StringList field types when a GML element has several occurences.<p>

Since OGR 1.8.0, a specialized GML driver - the <a href="drv_nas.html">NAS</a> driver - is available to read
German AAA GML Exchange Format (NAS/ALKIS).<p>

Configuration options can be set via the CPLSetConfigOption() function or as
environment variables.<p>

<h2>Geometry reading</h2>

When reading a feature, the driver will by default only take into account the
last recognized GML geometry found (in case they are multiples) in the XML subtree describing the feature.<p>

Starting with OGR 1.10, in case of multiple geometry occurences, if a geometry is in a &lt;geometry&gt; element,
this will be the one selected. This will make default behaviour consistent with Inspire objects.<p>

Starting with OGR 1.8.0, the user can change the .gfs file to select the appropriate
geometry by specifying its path with the &lt;GeometryElementPath&gt; element. See the
description of the .gfs syntax below.<p>

<!-- Voluntary commented : a bit experimental for now and perhaps a better solution
     will emerge later -->
<!--
OGR 1.8.0 adds support to "merge" the multiple geometries found in a feature by
setting the configuration option <b>GML_FETCH_ALL_GEOMETRIES</b> to <b>YES</b>. The geometries
will be collected into a GeometryCollection (or Multipolygon if individual geometries
are polygons or multipolygons). This can be useful when reading some GML application profiles.
If a &lt;GeometryElementPath&gt; element is specified in the .gfs, the fetching will be limited
to paths that match the value of &lt;GeometryElementPath&gt;.<p>
-->

OGR 1.8.0 adds support for more GML geometries including TopoCurve,
TopoSurface, MultiCurve. The TopoCurve type GML geometry can be interpreted as
either of two types of geometries.  The Edge elements in it contain curves and
their corresponding nodes.  By default only the curves, the main geometries,
are reported as OGRMultiLineString.  To retrieve the nodes, as OGRMultiPoint,
the configuration option <b>GML_GET_SECONDARY_GEOM</b> should be set to the
value <b>YES</b>.  When this is set only the secondary geometries are
reported.<p>

<h2>gml:xlink resolving</h2>

OGR 1.8.0 adds support for gml:xlink resolving.  When the resolver finds an
element containing the tag xlink:href, it tries to find the corresponding
element with the gml:id in the same gml file, other gml file in the file system
or on the web using cURL.  Set the configuration option
<b>GML_SKIP_RESOLVE_ELEMS</b> to <b>NONE</b> to enable resolution.<p>

By default the resolved file will be saved in the
same directory as the original file with the extension ".resolved.gml", if it
doesn't exist already.  This behaviour can be changed using the configuration
option <b>GML_SAVE_RESOLVED_TO</b>.  Set it to <b>SAME</b> to overwrite the
original file.  Set it to a <b>filename ending with .gml</b> to save it to that
location.  Any other values are ignored.  If the resolver cannot write to the
file for any reason, it will try to save it to a temperary file generated using
CPLGenerateTempFilename("ResolvedGML"); if it cannot, resolution fails.<p>

Note that the resolution algorithm is not optimised for large files.  For files
with more than a couple of thousand xlink:href tags, the process can go beyond
a few minutes.  A rough progress is displayed through CPLDebug() for every
256 links.  It can be seen by setting the environment variable CPL_DEBUG.
The resolution time can be reduced if you know any elements that
won't be needed.  Mention a comma seperated list of names of such elements with
the configuration option <b>GML_SKIP_RESOLVE_ELEMS</b>.  Set it to <b>ALL</b>
to skip resolving altogether (default action).  Set it to <b>NONE</b> to
resolve all the xlinks.<p>

Starting since OGR 1.9.0 an alternative resolution method is available.
This alternative method will be activated using the configuration option
<b>GML_SKIP_RESOLVE_ELEMS HUGE</b>. In this case any gml:xlink will be 
resolved using a temporary SQLite DB so to identify any corresponding
gml:id relation. At the end of this SQL-based process, a resolved file
will be generated exactly as in the <b>NONE</b> case but without their limits. 
The main advantages in using an external (temporary) DBMS so to resolve 
gml:xlink and gml:id relations are the followings:<ul>
	<li>no memory size constraints. The <b>NONE</b> method stores the whole
	   GML node-tree in-memory; and this practically means that no GML
	   file bigger than 1 GB can be processed at all using a 32-bit
	   platform, due to memory allocation limits. Using a file-system
	   based DBMS avoids at all this issue.</li>
	<li>by far better efficiency, most notably when huge GML files containing
	   many thousands (or even millions) of xlink:href / gml:id relational 
	   pairs.</li>
	<li>using the <b>GML_SKIP_RESOLVE_ELEMS HUGE</b> method realistically allows 
	   to succesfully resolve some really huge GML file (3GB+) containing many 
	   millions xlink:href / gml:id in a reasonable time (about an hour or so on).</li>
	<li>The <b>GML_SKIP_RESOLVE_ELEMS HUGE</b> method supports the followind further
	   configuration option:<ul>
		<li>you can use <b>GML_GFS_TEMPLATE</b> <b><i>path_to_template.gfs</i></b>
		   in order to unconditionally use a predefined GFS file. This option is really useful
		   when you are planning to import many distinct GML files in subsequent steps [<b>-append</b>] 
		   and you absolutely want to preserve a fully consistent data layout for the whole GML set.
		   Please, pay attention not to use the <b>-lco LAUNDER=yes</b> setting when using <b>GML_GFS_TEMPLATE</b>; 
		   this should break the correct recognition of attribute names between subsequent GML import runs.
</li>
	</ul></li>
</ul>

<h2>TopoSurface interpretation rules [polygons and internal holes]</h2>

<p>
Starting since OGR 1.9.0 the GML driver is able to recognize two different interpretation
rules for TopoSurface when a polygon contains any internal hole:
<ul>
	<li>the previously supported interpretation rule assumed that:<ul>
		<li>each TopoSurface may be represented as a collection of many Faces</li>
		<li><i>positive</i> Faces [i.e. declaring <b>orientation="+"</b>] are assumed to
		    represent the Exterior Ring of some Polygon.</li>
		<li><i>negative</i> Faces [i.e. declaring <b>orientation="-"</b>] are assumed to
		    represent an Interior Ring (aka <i>hole</i>) belonging to the latest declared 
			Exterior Ring.</li>
		<li>ordering any Edge used to represent each Ring is important: each Edge is expected
			to be exactly adjacent to the next one.</li>
	</li></ul>
	<li>the new interpretation rule now assumes that:<ul>
		<li>each TopoSurface may be represented as a collection of many Faces</li>
		<li>the declared <b>orientation</b> for any Face has nothing to deal with Exterior/Interior Rings</li>
		<li>each Face is now intended to represent a complete Polygon, eventually including any possible Interior 
			Ring (<i>holes</i>)</li>
		<li>the relative ordering of any Edge composing the same Face is completely not relevant</li> 
	</li></ul>
</ul>
		
The newest interpretation seems to fully match GML 3 standard recommendations; so this latest
is now assumed to be the default interpretation supported by OGR.</p>

<p><b>NOTE</b> : Using the newest interpretation requires GDAL/OGR to be built against the GEOS library.</p>

<p>Using the <b>GML_FACE_HOLE_NEGATIVE</b> configuration option you can anyway select the
actual interpretation to be applied when parsing GML 3 Topologies:
<ul>
	<li>setting <b>GML_FACE_HOLE_NEGATIVE NO</b> (<i>default</i> option) will activate
	    the newest interpretation rule</li>
	<li>but explicitly setting <b>GML_FACE_HOLE_NEGATIVE YES</b> still enables to activate
	    the old interpretation rule</li>
</ul>
</p>

<h2>Encoding issues</h2>

Expat library supports reading the following built-in encodings :
<ul>
<li>US-ASCII</li>
<li>UTF-8</li>
<li>UTF-16</li>
<li>ISO-8859-1</li>
</ul>

When used with Expat library, OGR 1.8.0 adds supports for Windows-1252 encoding (
for previous versions, altering the encoding mentionned in the XML header to
ISO-8859-1 might work in some cases).<p>

The content returned by OGR will be encoded in UTF-8, after the conversion from the
encoding mentionned in the file header is.<p>

If the GML file is not encoded in one of the previous encodings and the only parser available
is Expat, it will not be parsed by the GML driver. You may convert it into one of the supported
encodings with the <i>iconv</i> utility for example and change accordingly the <i>encoding</i>
parameter value in the XML header.<p>

When writing a GML file, the driver expects UTF-8 content to be passed in.<p>

Note: The .xsd schema files are parsed with an integrated XML parser which
does not currently understand XML encodings specified in the XML header. It expects encoding to be always
UTF-8. If attribute names in the schema file contains non-ascii characters, it is
better to use <i>iconv</i> utility and convert the .xsd file into UTF-8 encoding first.<p>

<h2>Feature id (fid / gml:id)</h2>

Starting with OGR 1.8.0, the driver exposes the content of the gml:id attribute
as a string field called <i>gml_id</i>, when reading GML WFS documents. When creating
a GML3 document, if a field is called <i>gml_id</i>, its content will also be used to
write the content of the gml:id attribute of the created feature.<p>

Starting with OGR 1.9.0, the driver autodetects the presence of a fid (GML2)
(resp. gml:id (GML3)) attribute at the beginning of the file, and, if found,
exposes it by default as a <i>fid</i> (resp. <i>gml_id</i>) field. The autodetection
can be overriden by specifying the <b>GML_EXPOSE_FID</b> or <b>GML_EXPOSE_GML_ID</b> configuration
option to <b>YES</b> or <b>NO</b>.<p>

Starting with OGR 1.9.0, when creating a GML2 document, if a field is called
<i>fid</i>, its content will also be used to write the content of the fid attribute of the
created feature.<p>

<h2>Performance issues with large multi-layer GML files.</h2>

There is only one GML parser per GML datasource shared among the various layers.
By default, the GML driver will restart reading from the beginning of the file, each time a layer
is accessed for the first time, which can lead to poor performance with large GML files.<p>

Starting with OGR 1.9.0, the <b>GML_READ_MODE</b> configuration option can be set to <b>SEQUENTIAL_LAYERS</b>
if all features belonging to the same layer are written sequentially in the file. The reader will then avoid
unnecessary resets when layers are read completely one after the other. To get the best performance,
the layers must be read in the order they appear in the file.<p>

If no .xsd and .gfs files are found, the parser will detect the layout of layers when
building the .gfs file. If the layers are found to be sequential, a <i>&lt;SequentialLayers&gt;true&lt;/SequentialLayers&gt;</i>
element will be written in the .gfs file, so that the GML_READ_MODE will be automatically
initialized to MONOBLOCK_LAYERS if not explicitly set by the user.<p>

Starting with OGR 1.9.0, the GML_READ_MODE configuration option can be set to INTERLEAVED_LAYERS to be able
to read a GML file whose features from different layers are interleaved. In the case, the semantics of the
GetNextFeature() will be slightly altered, in a way where a NULL return does not necessarily mean that
all features from the current layer have been read, but it could also mean that there is still a feature to read, but that
belongs to another layer. In that case, the file should be read with code similar to the following one :

<pre>
    int nLayerCount = poDS->GetLayerCount();
    int bFoundFeature;
    do
    {
        bFoundFeature = FALSE;
        for( int iLayer = 0; iLayer &lt; nLayerCount; iLayer++ )
        {
            OGRLayer   *poLayer = poDS->GetLayer(iLayer);
            OGRFeature *poFeature;
            while((poFeature = poLayer->GetNextFeature()) != NULL)
            {
                bFoundFeature = TRUE;
                poFeature->DumpReadable(stdout, NULL);
                OGRFeature::DestroyFeature(poFeature);
            }
        }
    } while (bInterleaved &amp;&amp; bFoundFeature);
</pre>

<h2>Creation Issues</h2>

On export all layers are written to a single GML file all in a single
feature collection.  Each layer's name is used as the element name for
objects from that layer.  Geometries are always written as the 
ogr:geometryProperty element on the feature.<p>

The GML writer supports the following dataset creation options:

<ul>
<li> <B>XSISCHEMAURI</B>: If provided, this URI will be inserted as the
schema location.  Note that the schema file isn't actually accessed by OGR, so
it is up to the user to ensure it will match the schema of the OGR produced 
GML data file.<p>

<li> <B>XSISCHEMA</B>: This can be EXTERNAL, INTERNAL or OFF and defaults to
EXTERNAL.  This writes a GML application schema file to a corresponding .xsd file
(with the same basename). If INTERNAL is used the schema is written within the GML
file, but this is experimental and almost certainly not valid XML.
OFF disables schema generation (and is implicit if XSISCHEMAURI is used).<p>

<li> <b>PREFIX</b> (OGR &gt;= 1.10) Defaults to 'ogr'. This is the prefix for the application target namespace.</p>

<li> <b>TARGET_NAMESPACE</b> (OGR &gt;= 1.10) Defaults to 'http://ogr.maptools.org/'. This is the application target namespace.</p>

<li> <b>FORMAT</b>: (OGR &gt;= 1.8.0) This can be set to :
<ul>
<li><i>GML3</i> in order to write GML files that follow GML 3.1.1 SF-0 profile.</li>
<li><i>GML3Deegree</i> (OGR &gt;= 1.9.0) in order to produce a GML 3.1.1 .XSD schema,
with a few variations with respect to what is recommanded by GML3 SF-0 profile,
but that will be better accepted by some software (such as Deegree 3).</li>
<li><i>GML3.2</i>(OGR &gt;= 1.9.0) in order to write GML files that follow GML 3.2.1 SF-0 profile.</li>
</ul><br>
If not specified, GML2 will be used.<p>

<li> <b>GML3_LONGSRS</b>=YES/NO. (OGR &gt;= 1.8.0, only valid when FORMAT=GML3/GML3Degree/GML3.2) Default to YES. If YES, SRS with EPSG authority will
be written with the "urn:ogc:def:crs:EPSG::" prefix.
In the case, if the SRS is a geographic SRS without explicit AXIS order, but that the same SRS authority code
imported with ImportFromEPSGA() should be treated as lat/long, then the function will take care of coordinate order swapping.
If set to NO, SRS with EPSG authority will be written with the "EPSG:" prefix, even if they are in lat/long order.<p>

<li> <b>SPACE_INDENTATION</b>=YES/NO. (OGR &gt;= 1.8.0) Default to YES. If YES, the output will be indented with spaces
for more readability, but at the expense of file size.<p>

</ul>

<h2>VSI Virtual File System API support</h2>

(Some features below might require OGR &gt;= 1.9.0)<p>

The driver supports reading and writing to files managed by VSI Virtual File System API, which include
"regular" files, as well as files in the /vsizip/ (read-write) , /vsigzip/ (read-write) , /vsicurl/ (read-only) domains.<p>

Writing to /dev/stdout or /vsistdout/ is also supported. Note that in that case, only the content of the GML file
will be written to the standard output (and not the .xsd). The &lt;boundedBy&gt; element will not be written. This is also
the case if writing in /vsigzip/<p>

<h2>Syntax of .gfs file by example</h2>

Let's consider the following test.gml file :

<pre>
&lt;?xml version="1.0" encoding="UTF-8"?&gt;
&lt;gml:FeatureCollection xmlns:gml="http://www.opengis.net/gml"&gt;
  &lt;gml:featureMember&gt;
    &lt;LAYER&gt;
      &lt;attrib1&gt;attrib1_value&lt;/attrib1&gt;
      &lt;attrib2container&gt;
        &lt;attrib2&gt;attrib2_value&lt;/attrib2&gt;
      &lt;/attrib2container&gt;
      &lt;location1container&gt;
        &lt;location1&gt;
            &lt;gml:Point&gt;&lt;gml:coordinates&gt;3,50&lt;/gml:coordinates&gt;&lt;/gml:Point&gt;
        &lt;/location1&gt;
      &lt;/location1container&gt;
      &lt;location2&gt;
        &lt;gml:Point&gt;&lt;gml:coordinates&gt;2,49&lt;/gml:coordinates&gt;&lt;/gml:Point&gt;
      &lt;/location2&gt;
    &lt;/LAYER&gt;
  &lt;/gml:featureMember&gt;
&lt;/gml:FeatureCollection&gt;
</pre>

and the following associated .gfs file.

<pre>
&lt;GMLFeatureClassList&gt;
  &lt;GMLFeatureClass&gt;
    &lt;Name&gt;LAYER&lt;/Name&gt;
    &lt;ElementPath&gt;LAYER&lt;/ElementPath&gt;
    &lt;GeometryElementPath&gt;location1container|location1&lt;/GeometryElementPath&gt;
    &lt;PropertyDefn&gt;
      &lt;Name&gt;attrib1&lt;/Name&gt;
      &lt;ElementPath&gt;attrib1&lt;/ElementPath&gt;
      &lt;Type&gt;String&lt;/Type&gt;
      &lt;Width&gt;13&lt;/Width&gt;
    &lt;/PropertyDefn&gt;
    &lt;PropertyDefn&gt;
      &lt;Name&gt;attrib2&lt;/Name&gt;
      &lt;ElementPath&gt;attrib2container|attrib2&lt;/ElementPath&gt;
      &lt;Type&gt;String&lt;/Type&gt;
      &lt;Width&gt;13&lt;/Width&gt;
    &lt;/PropertyDefn&gt;
  &lt;/GMLFeatureClass&gt;
&lt;/GMLFeatureClassList&gt;
</pre>

Note the presence of the '|' character in the &lt;ElementPath&gt; and &lt;GeometryElementPath&gt elements to
specify the wished field/geometry element that is a nested XML element. Nested field elements are only supported from OGR 1.8.0, as well
 as specifying &lt;GeometryElementPath&gt; If GeometryElementPath is not specified, the
GML driver will use the last recognized geometry element.<p>

The output of <i>ogrinfo test.gml -ro -al</i> is:
<pre>
Layer name: LAYER
Geometry: Unknown (any)
Feature Count: 1
Extent: (3.000000, 50.000000) - (3.000000, 50.000000)
Layer SRS WKT:
(unknown)
Geometry Column = location1container|location1
attrib1: String (13.0)
attrib2: String (13.0)
OGRFeature(LAYER):0
  attrib1 (String) = attrib1_value
  attrib2 (String) = attrib2_value
  POINT (3 50)
</pre>

<h2>Example</h2>

The ogr2ogr utility can be used to dump the results of a Oracle query to
GML:

<pre>
ogr2ogr -f GML output.gml OCI:usr/pwd@db my_feature -where "id = 0"
</pre>

<P>
The ogr2ogr utility can be used to dump the results of a PostGIS query to
GML:

<pre>
ogr2ogr -f GML output.gml PG:'host=myserver dbname=warmerda' -sql "SELECT pop_1994 from canada where province_name = 'Alberta'"

</pre>


<h2>See Also</h2>

<ul>
<li> <a href="http://www.opengeospatial.org/standards/gml">GML Specifications</a><p>
<li> <a href="http://portal.opengeospatial.org/files/?artifact_id=15201">GML 3.1.1 simple features profile - OGC(R) 06-049r1</a><p>
<li> <a href="http://xml.apache.org/xerces2-j/index.html">Xerces</a><p>
<li> <a href="drv_nas.html">NAS/ALKIS : specialized GML driver for cadastral data in Germany</a><p>
</ul>

<h2>Credits</h2>
<ul>
	<li>Implementation for <b>GML_SKIP_RESOLVE_ELEMS HUGE</b> was contributed by A.Furieri, with funding from Regione Toscana</li>
</ul>

</body>
</html>