drv_gml.html 48.1 KB
Newer Older
xuebingbing's avatar
xuebingbing committed
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 484 485 486 487 488 489 490 491 492 493 494 495 496 497 498 499 500 501 502 503 504 505 506 507 508 509 510 511 512 513 514 515 516 517 518 519 520 521 522 523 524 525 526 527 528 529 530 531 532 533 534 535 536 537 538 539 540 541 542 543 544 545 546 547 548 549 550 551 552 553 554 555 556 557 558 559 560 561 562 563 564 565 566 567 568 569 570 571 572 573 574 575 576 577 578 579 580 581 582 583 584 585 586 587 588 589 590 591 592 593 594 595 596 597 598 599 600 601 602 603 604 605 606 607 608 609 610 611 612 613 614 615 616 617 618 619 620 621 622 623 624 625 626 627 628 629 630 631 632 633 634 635 636 637 638 639 640 641 642 643 644 645 646 647 648 649 650 651 652 653 654 655 656 657 658 659 660 661 662 663 664 665 666 667 668 669 670 671 672 673 674 675 676 677 678 679 680 681 682 683 684 685 686 687 688 689 690 691 692 693 694 695 696 697 698 699 700 701 702 703 704 705 706 707 708 709 710 711 712 713 714 715 716 717 718 719 720 721 722 723 724 725 726 727 728 729 730 731 732 733 734 735 736 737 738 739 740 741 742 743 744 745 746 747 748 749 750 751 752 753 754 755 756 757 758 759 760 761 762 763 764 765 766 767 768 769 770 771 772 773 774 775 776 777 778 779 780 781 782 783 784 785 786 787 788 789 790 791 792 793 794 795 796 797 798 799 800 801 802 803 804 805 806 807 808 809 810 811 812 813 814 815 816 817 818 819 820 821 822 823 824 825 826 827 828 829 830 831 832 833 834 835 836 837 838 839 840 841 842 843 844 845 846 847 848 849 850 851 852 853 854 855 856 857 858 859 860 861 862 863 864 865 866 867 868 869 870 871 872 873 874 875 876 877 878 879 880 881 882 883 884 885 886 887 888 889 890 891 892 893 894 895 896 897 898 899 900 901 902 903 904 905 906 907 908 909 910 911 912 913 914 915 916 917 918 919 920 921 922 923 924 925 926 927 928 929 930 931 932 933 934 935 936 937 938 939 940 941 942 943 944 945 946 947 948 949 950 951 952 953 954 955 956 957 958 959 960 961 962 963 964 965 966 967 968 969 970 971 972 973 974 975 976 977 978 979 980 981 982 983 984 985 986 987 988 989 990 991 992 993 994 995 996 997 998 999 1000 1001 1002 1003 1004 1005 1006 1007 1008 1009 1010 1011 1012 1013 1014 1015 1016 1017 1018 1019 1020 1021 1022 1023 1024 1025 1026 1027 1028 1029 1030 1031 1032 1033 1034
<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>

Starting with GDAL 2.2, another driver, <a href="drv_gmlas.html">GMLAS</a>, for GML driven by application schemas, is also available. Both GML and GMLAS drivers have their use cases.<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 overridden 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:"
(or "http://www.opengis.net/def/crs/EPSG/0/" starting with GDAL 2.1.2),
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>
<p>Starting with GDAL 2.1.2, the SWAP_COORDINATES open option (or GML_SWAP_COORDINATES
configuration option) can be set to AUTO/YES/NO. It controls whether the order of the x/y or long/lat
coordinates should be swapped. In AUTO mode, the driver will determine if swapping
must be done from the srsName and value of other options
like CONSIDER_EPSG_AS_URN and INVERT_AXIS_ORDER_IF_LAT_LONG. When SWAP_COORDINATES
is set to YES, coordinates will be always swapped regarding the order they appear
in the GML, and when it set to NO, they will be kept in the same order. The default
is AUTO.</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.
Staring with GDAL 2.0, the XSD can also be specified as the value of the XSD open option.<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>

Starting with GDAL 1.11, the <b>GML_ATTRIBUTES_TO_OGR_FIELDS</b> configuration
option can be set to <b>YES</b> so that attributes of GML elements are also
taken into account to create OGR fields.<p>

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

<h2>Particular GML application schemas</h2>

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 occurrences.<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>

Since OGR 1.8.0, the GML driver has partial support for reading AIXM or CityGML files.<p>

Since OGR 1.11, the GML driver supports reading :
<ul>
 <li><a href="http://xml.nls.fi/XML/Schema/Maastotietojarjestelma/MTK/201202/Maastotiedot.xsd">Finnish National Land Survey GML files (a.k.a MTK GML) for topographic data.</a></li>
 <li><a href="http://xml.nls.fi/XML/Schema/sovellus/ktjkii/modules/kiinteistotietojen_kyselypalvelu_WFS/Asiakasdokumentaatio/ktjkiiwfs/2010/02/">Finnish National Land Survey GML files for cadastral data</a>.</li>
 <li><a href="http://inspire.ec.europa.eu/schemas/cp/3.0/CadastralParcels.xsd">Cadastral data in Inspire GML schemas</a>.</li>
 <li><a href="http://www.cuzk.cz/Uvod/Produkty-a-sluzby/RUIAN/2-Poskytovani-udaju-RUIAN-ISUI-VDP/Vymenny-format-RUIAN/Vymenny-format-RUIAN-%28VFR%29.aspx">Czech RUIAN Exchange Format (VFR)</a>.</li>
</ul>

Since OGR 2.0, the GML driver supports reading responses to CSW GetRecords
queries.<p>

Since OGR 2.2, the GML driver supports reading Japanese FGD GML v4 files.<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>

But, starting with OGR 1.11, if the .xsd schema is understood by the XSD parser and declares
several geometry fields, or the .gfs file declares several geometry fields, multiple geometry
fields will be reported by the GML driver according to
<a href="http://trac.osgeo.org/gdal/wiki/rfc41_multiple_geometry_fields">RFC 41</a>.<p>

Starting with OGR 1.10, in case of multiple geometry occurrences, 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>

Starting with GDAL 2.0, Arc, ArcString, ArcByBulge, ArcByCenterPoint, Circle
and CircleByCenterPoints will be returned as circular string OGR geometries.
If they are included in other GML elements such as CurveComposite, MultiCurve, Surface,
corresponding non-linear OGR geometries will be returned as well. When
reading GML3 application schemas, declarations of geometry fields such as
CurvePropertyType, SurfacePropertyType, MultiCurvePropertyType or MultiSurfacePropertyType
will be also interpreted as being potential non-linear geometries, and corresponding
OGR geometry type will be used for the layer geometry type.<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 temporary file generated using
CPLGenerateTempFilename("ResolvedGML"); if it cannot, resolution fails.<p>

Note that the resolution algorithm is not optimized 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
will not be needed.  Mention a comma separated 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 following:<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 successfully 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 following 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 mentioned 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 mentioned 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 overridden 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 SEQUENTIAL_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>Open options</h2>

<ul>
<li> <b>XSD=filename</b>: (GDAL &gt;=2.0) to specify an explicit filename for the XSD
application schema to use.</li>
<li> <b>FORCE_SRS_DETECTION=YES/NO</b>: (GDAL &gt;=2.0) Force a full scan to detect the SRS of layers.
This option may be needed in the case where the .gml file is accompanied with
a .xsd. Normally in that situation, OGR would not detect the SRS, because this
requires to do a full scan of the file. Defaults to NO</li>
<li> <b>EMPTY_AS_NULL=YES/NO</b>: (GDAL &gt;=2.0) By default (EMPTY_AS_NULL=YES),
fields with empty content will be reported as being NULL, instead of being an empty
string. This is the historic behaviour. However this will prevent such fields to
be declared as not-nullable if the application schema declared them as mandatory.
So this option can be set to NO to have both empty strings being report as such,
and mandatory fields being reported as not nullable.</li>
<li> <b>GML_ATTRIBUTES_TO_OGR_FIELDS=YES/NO</b>: (GDAL &gt;=2.0) Whether GML
attributes should be reported as OGR fields. Note that this option has only an
effect the first time a GML file is opened (before the .gfs file is created),
and if it has no valid associated .xsd. Defaults to NO.</li>
<li> <b>INVERT_AXIS_ORDER_IF_LAT_LONG=YES/NO</b>: (GDAL &gt;=2.0) Whether to
present SRS and coordinate ordering in traditional GIS order. Defaults to YES.</li>
<li> <b>CONSIDER_EPSG_AS_URN=YES/NO/AUTO</b>: (GDAL &gt;=2.0) Whether to
consider srsName like EPSG:XXXX as respecting EPSG axis order. Defaults to AUTO.</li>
<li> <b>SWAP_COORDINATES</b>=AUTO/YES/NO: (GDAL &gt;=2.1.2) Whether the order of the x/y or long/lat
coordinates should be swapped. In AUTO mode, the driver will determine if swapping
must be done from the srsName and value of other options
like CONSIDER_EPSG_AS_URN and INVERT_AXIS_ORDER_IF_LAT_LONG. When SWAP_COORDINATES
is set to YES, coordinates will be always swapped regarding the order they appear
in the GML, and when it set to NO, they will be kept in the same order. The default
is AUTO.</li>
<li> <b>READ_MODE=AUTO/STANDARD/SEQUENTIAL_LAYERS/INTERLEAVED_LAYERS</b>: (GDAL &gt;=2.0)
Read mode. Defaults to AUTO.</li>
<li> <b>EXPOSE_GML_ID=YES/NO/AUTO</b>: (GDAL &gt;=2.0)
Whether to make feature gml:id as a gml_id attribute. Defaults to AUTO.</li>
<li> <b>EXPOSE_FID=YES/NO/AUTO</b>: (GDAL &gt;=2.0)
Whether to make feature fid as a fid attribute. Defaults to AUTO.</li>
<li> <b>DOWNLOAD_SCHEMA=YES/NO</b>: (GDAL &gt;=2.0)
Whether to download the remote application schema if needed (only for WFS currently). Defaults to YES.</li>
<li> <b>REGISTRY=filename</b>: (GDAL &gt;=2.0)
Filename of the registry with application schemas. Defaults to {GDAL_DATA}/gml_registry.xml.</li>
</ul>

<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>STRIP_PREFIX</b> (OGR &gt;= 1.11) Defaults to FALSE. Can be set to TRUE to avoid writing
the prefix of the application target namespace in the GML file.</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 recommended 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.<br>
Starting with GDAL 2.0, non-linear geometries can be written. This is only compatible
with selecting on of that above GML3 format variant. Otherwise, such geometries will be
approximating into their closest matching linear geometry.
<br>
Note: starting with OGR 1.11, fields of type StringList, RealList or IntegerList can be written. This
will cause to advertize the SF-1 profile in the .XSD schema (such types are not supported by SF-0).<br>

<p>

<li> <b>GML_FEATURE_COLLECTION</b>=YES/NO (OGR &gt;= 2.3) Whether to use the gml:FeatureCollection,
instead of creating a dedicated container element in the target namespace.
Only valid for FORMAT=GML3/GML3.2. Note that gml:FeatureCollection has been
deprecated in GML 3.2, and is not allowed by the OGC 06-049r1 "Geography Markup
Language (GML) simple features profile" (for GML 3.1.1) and OGC 10-100r3
"Geography Markup Language (GML) simple features profile (with Corrigendum)" (for GML 3.2)
specifications.</li>

<p>

<li> <b>GML3_LONGSRS</b>=YES/NO. (OGR &gt;= 1.8.0, only valid when FORMAT=GML3/GML3Degree/GML3.2)
Deprecated by SRSNAME_FORMAT in GDAL 2.2. Default to YES.
If YES, SRS with EPSG authority will
be written with the "urn:ogc:def:crs:EPSG::" prefix.
In the case the SRS is a SRS without explicit AXIS order, but that the
same SRS authority code imported with ImportFromEPSGA() should be treated as lat/long or
northing/easting, 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>SRSNAME_FORMAT</b>=SHORT/OGC_URN/OGC_URL (Only valid for FORMAT=GML3/GML3Degree/GML3.2,
GDAL &gt;= 2.2). Defaults to OGC_URN.
If SHORT, then srsName will be in the form AUTHORITY_NAME:AUTHORITY_CODE
If OGC_URN, then srsName will be in the form urn:ogc:def:crs:AUTHORITY_NAME::AUTHORITY_CODE
If OGC_URL, then srsName will be in the form http://www.opengis.net/def/crs/AUTHORITY_NAME/0/AUTHORITY_CODE
For OGC_URN and OGC_URL, in the case the SRS is a SRS without explicit
AXIS order,  but that the same SRS authority code imported with
ImportFromEPSGA() should be treated as lat/long or northing/easting,
then the function will take care of coordinate order swapping.<p>

<li> <b>SRSDIMENSION_LOC</b>=POSLIST/GEOMETRY/GEOMETRY,POSLIST. (Only valid for FORMAT=GML3/GML3Degree/GML3.2, GDAL &gt;= 2.0) Default to POSLIST.
For 2.5D geometries, define the location where to attach the srsDimension attribute.
There are diverging implementations. Some put in on the &lt;gml:posList&gt; element, other
on the top geometry element.<p>

<li> <b>WRITE_FEATURE_BOUNDED_BY</b>=YES/NO. (OGR &gt;= 1.11, only valid when FORMAT=GML3/GML3Degree/GML3.2) Default to YES.
If set to NO, the &lt;gml:boundedBy&gt; element will not be written for each feature.<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>

<li> <b>GML_ID</b>=string. (Only valid for GML 3.2, GDAL &gt;= 2.0)
Value of feature collection gml:id. Default value is "aFeatureCollection".<p>

<li> <b>NAME</b>=string. Content of GML name element. Can also be set as the
NAME metadata item on the dataset.<p>

<li> <b>DESCRIPTION</b>=string. Content of GML description element. Can also be set as the
DESCRIPTION metadata item on the dataset.<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 &lt;GeometryType&gt; element can be specified to force the geometry type.
Accepted values are : 0 (any geometry type), 1 (point), 2 (linestring), 3 (polygon),
4 (multipoint), 5 (multilinestring), 6 (multipolygon), 7 (geometrycollection).<p>

Starting with OGR 1.11, the &lt;GeometryElementPath&gt; and &lt;GeometryType&gt; can be
specified as many times as there are geometry fields in the GML file. Another possibility
is to define a &lt;GeomPropertyDefn&gt;element as many times as necessary:
<pre>
&lt;GMLFeatureClassList&gt;
  &lt;GMLFeatureClass&gt;
    &lt;Name&gt;LAYER&lt;/Name&gt;
    &lt;ElementPath&gt;LAYER&lt;/ElementPath&gt;
    &lt;GeomPropertyDefn&gt;
        &lt;Name&gt;geometry&lt;/Name&gt; &lt;-- OGR geometry name --&gt;
        &lt;ElementPath&gt;geometry&lt;/ElementPath&gt; &lt;!-- XML element name possibly with '|' to specify the path --&gt;
        &lt;Type&gt;MultiPolygon&lt;/Type&gt;
    &lt;/GeomPropertyDefn&gt;
    &lt;GeomPropertyDefn&gt;
        &lt;Name&gt;referencePoint&lt;/Name&gt;
        &lt;ElementPath&gt;referencePoint&lt;/ElementPath&gt;
        &lt;Type&gt;Point&lt;/Type&gt;
    &lt;/GeomPropertyDefn&gt;
  &lt;/GMLFeatureClass&gt;
&lt;/GMLFeatureClassList&gt;
</pre>
<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>Advanced .gfs syntax (OGR &gt;= 1.11)</h2>

<h3>Specifying ElementPath to find objects embedded into top level objects</h3>

Let's consider the following test.gml file :
<pre>
&lt;?xml version="1.0" encoding="utf-8"?&gt;
&lt;gml:FeatureCollection xmlns:xlink="http://www.w3.org/1999/xlink"
                       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                       gml:id="foo" xmlns:gml="http://www.opengis.net/gml/3.2"&gt;
  &lt;gml:featureMember&gt;
    &lt;TopLevelObject gml:id="TopLevelObject.1"&gt;
      &lt;content&gt;
        &lt;Object gml:id="Object.1"&gt;
          &lt;geometry&gt;
            &lt;gml:Polygon gml:id="Object.1.Geometry" srsName="urn:ogc:def:crs:EPSG::4326"&gt;
              &lt;gml:exterior&gt;
                &lt;gml:LinearRing&gt;
                  &lt;gml:posList srsDimension="2"&gt;48 2 49 2 49 3 48 3 48 2&lt;/gml:posList&gt;
                &lt;/gml:LinearRing&gt;
              &lt;/gml:exterior&gt;
            &lt;/gml:Polygon&gt;
          &lt;/geometry&gt;
          &lt;foo&gt;bar&lt;/foo&gt;
        &lt;/Object&gt;
      &lt;/content&gt;
      &lt;content&gt;
        &lt;Object gml:id="Object.2"&gt;
          &lt;geometry&gt;
            &lt;gml:Polygon gml:id="Object.2.Geometry" srsName="urn:ogc:def:crs:EPSG::4326"&gt;
              &lt;gml:exterior&gt;
                &lt;gml:LinearRing&gt;
                  &lt;gml:posList srsDimension="2"&gt;-48 2 -49 2 -49 3 -48 3 -48 2&lt;/gml:posList&gt;
                &lt;/gml:LinearRing&gt;
              &lt;/gml:exterior&gt;
            &lt;/gml:Polygon&gt;
          &lt;/geometry&gt;
          &lt;foo&gt;baz&lt;/foo&gt;
        &lt;/Object&gt;
      &lt;/content&gt;
    &lt;/TopLevelObject&gt;
  &lt;/gml:featureMember&gt;
&lt;/gml:FeatureCollection&gt;
</pre>

By default, only the TopLevelObject object would be reported and it would only
use the second geometry. This is not the desired behaviour in that instance.
You can edit the generated .gfs and modify it like the following in order to
specify a full path to the element (top level XML element being omitted) :

<pre>
&lt;GMLFeatureClassList&gt;
  &lt;GMLFeatureClass&gt;
    &lt;Name&gt;Object&lt;/Name&gt;
    &lt;ElementPath&gt;featureMember|TopLevelObject|content|Object&lt;/ElementPath&gt;
    &lt;GeometryType&gt;3&lt;/GeometryType&gt;
    &lt;PropertyDefn&gt;
      &lt;Name&gt;foo&lt;/Name&gt;
      &lt;ElementPath&gt;foo&lt;/ElementPath&gt;
      &lt;Type&gt;String&lt;/Type&gt;
    &lt;/PropertyDefn&gt;
  &lt;/GMLFeatureClass&gt;
&lt;/GMLFeatureClassList&gt;
</pre>

<h3>Getting XML attributes as OGR fields</h3>

The element@attribute syntax can be used in the &lt;ElementPath&gt;
to specify that the value of attribute 'attribute' of element 'element' must
be fetched.<p>

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;length unit="m"&gt;5&lt;/length&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;GeometryType&gt;100&lt;/GeometryType&gt; &lt;!-- no geometry --&gt;
    &lt;PropertyDefn&gt;
      &lt;Name&gt;length&lt;/Name&gt;
      &lt;ElementPath&gt;length&lt;/ElementPath&gt;
      &lt;Type&gt;Real&lt;/Type&gt;
    &lt;/PropertyDefn&gt;
    &lt;PropertyDefn&gt;
      &lt;Name&gt;length_unit&lt;/Name&gt;
      &lt;ElementPath&gt;length@unit&lt;/ElementPath&gt;
      &lt;Type&gt;String&lt;/Type&gt;
    &lt;/PropertyDefn&gt;
  &lt;/GMLFeatureClass&gt;
&lt;/GMLFeatureClassList&gt;
</pre>

The output of <i>ogrinfo test.gml -ro -al</i> is:

<pre>
Layer name: LAYER
Geometry: None
Feature Count: 1
Layer SRS WKT:
(unknown)
gml_id: String (0.0)
length: Real (0.0)
length_unit: String (0.0)
OGRFeature(LAYER):0
  gml_id (String) = (null)
  length (Real) = 5
  length_unit (String) = m
</pre>

<h3>Using conditions on XML attributes</h3>

A &lt;Condition&gt; element can be specified as a child element of a
&lt;PropertyDefn&gt;. The content of the Condition follows a minimalistic
XPath syntax. It must be of the form @attrname[=|!=]'attrvalue' [and|or other_cond]*.
Note that 'and' and 'or' operators cannot be mixed (their precedence is not
taken into account).<p>

Several &lt;PropertyDefn&gt; can be defined with the same &lt;ElementPath&gt;, but with
&lt;Condition&gt; that must be mutually exclusive.<p>

Let's consider the following testcondition.gml file :

<pre>
&lt;?xml version="1.0" encoding="utf-8" ?&gt;
&lt;ogr:FeatureCollection
     xmlns:ogr="http://ogr.maptools.org/"
     xmlns:gml="http://www.opengis.net/gml"&gt;
  &lt;gml:featureMember&gt;
    &lt;ogr:testcondition fid="testcondition.0"&gt;
      &lt;ogr:name lang="en"&gt;English name&lt;/ogr:name&gt;
      &lt;ogr:name lang="fr"&gt;Nom francais&lt;/ogr:name&gt;
      &lt;ogr:name lang="de"&gt;Deutsche name&lt;/ogr:name&gt;
    &lt;/ogr:testcondition&gt;
  &lt;/gml:featureMember&gt;
&lt;/ogr:FeatureCollection&gt;
</pre>

and the following associated .gfs file.

<pre>
&lt;GMLFeatureClassList&gt;
  &lt;GMLFeatureClass&gt;
    &lt;Name&gt;testcondition&lt;/Name&gt;
    &lt;ElementPath&gt;testcondition&lt;/ElementPath&gt;
    &lt;GeometryType&gt;100&lt;/GeometryType&gt;
    &lt;PropertyDefn&gt;
      &lt;Name&gt;name_en&lt;/Name&gt;
      &lt;ElementPath&gt;name&lt;/ElementPath&gt;
      &lt;Condition&gt;@lang='en'&lt;/Condition&gt;
      &lt;Type&gt;String&lt;/Type&gt;
    &lt;/PropertyDefn&gt;
    &lt;PropertyDefn&gt;
      &lt;Name&gt;name_fr&lt;/Name&gt;
      &lt;ElementPath&gt;name&lt;/ElementPath&gt;
      &lt;Condition&gt;@lang='fr'&lt;/Condition&gt;
      &lt;Type&gt;String&lt;/Type&gt;
    &lt;/PropertyDefn&gt;
    &lt;PropertyDefn&gt;
      &lt;Name&gt;name_others_lang&lt;/Name&gt;
      &lt;ElementPath&gt;name@lang&lt;/ElementPath&gt;
      &lt;Condition&gt;@lang!='en' and @lang!='fr'&lt;/Condition&gt;
      &lt;Type&gt;StringList&lt;/Type&gt;
    &lt;/PropertyDefn&gt;
    &lt;PropertyDefn&gt;
      &lt;Name&gt;name_others&lt;/Name&gt;
      &lt;ElementPath&gt;name&lt;/ElementPath&gt;
      &lt;Condition&gt;@lang!='en' and @lang!='fr'&lt;/Condition&gt;
      &lt;Type&gt;StringList&lt;/Type&gt;
    &lt;/PropertyDefn&gt;
  &lt;/GMLFeatureClass&gt;
&lt;/GMLFeatureClassList&gt;
</pre>

The output of <i>ogrinfo testcondition.gml -ro -al</i> is:
<pre>
Layer name: testcondition
Geometry: None
Feature Count: 1
Layer SRS WKT:
(unknown)
fid: String (0.0)
name_en: String (0.0)
name_fr: String (0.0)
name_others_lang: StringList (0.0)
name_others: StringList (0.0)
OGRFeature(testcondition):0
  fid (String) = testcondition.0
  name_en (String) = English name
  name_fr (String) = Nom francais
  name_others_lang (StringList) = (1:de)
  name_others (StringList) = (1:Deutsche name)
</pre>

<h2>Registry for GML application schemas (OGR &gt;= 1.11)</h2>

The "data" directory of the GDAL installation contains a "gml_registry.xml"
file that links feature types of GML application schemas to .xsd or .gfs files
that contain their definition. This is used in case no valid .gfs or .xsd file
is found next to the GML file.<p>

An alternate location for the registry file can be defined by setting its full
pathname to the GML_REGISTRY configuration option.<p>

An example of such a file is :
<pre>
&lt;gml_registry&gt;
    &lt;!-- Finnish National Land Survey cadastral data --&gt;
    &lt;namespace prefix="ktjkiiwfs" uri="http://xml.nls.fi/ktjkiiwfs/2010/02" useGlobalSRSName="true"&gt;
        &lt;featureType elementName="KiinteistorajanSijaintitiedot"
                 schemaLocation="http://xml.nls.fi/XML/Schema/sovellus/ktjkii/modules/kiinteistotietojen_kyselypalvelu_WFS/Asiakasdokumentaatio/ktjkiiwfs/2010/02/KiinteistorajanSijaintitiedot.xsd"/&gt;
        &lt;featureType elementName="PalstanTunnuspisteenSijaintitiedot"
                 schemaLocation="http://xml.nls.fi/XML/Schema/sovellus/ktjkii/modules/kiinteistotietojen_kyselypalvelu_WFS/Asiakasdokumentaatio/ktjkiiwfs/2010/02/palstanTunnuspisteenSijaintitiedot.xsd"/&gt;
        &lt;featureType elementName="RekisteriyksikonTietoja"
                 schemaLocation="http://xml.nls.fi/XML/Schema/sovellus/ktjkii/modules/kiinteistotietojen_kyselypalvelu_WFS/Asiakasdokumentaatio/ktjkiiwfs/2010/02/RekisteriyksikonTietoja.xsd"/&gt;
        &lt;featureType elementName="PalstanTietoja"
                 schemaLocation="http://xml.nls.fi/XML/Schema/sovellus/ktjkii/modules/kiinteistotietojen_kyselypalvelu_WFS/Asiakasdokumentaatio/ktjkiiwfs/2010/02/PalstanTietoja.xsd"/&gt;
    &lt;/namespace&gt;

    &lt;!-- Inspire CadastralParcels schema --&gt;
    &lt;namespace prefix="cp" uri="urn:x-inspire:specification:gmlas:CadastralParcels:3.0" useGlobalSRSName="true"&gt;
        &lt;featureType elementName="BasicPropertyUnit"
                     gfsSchemaLocation="inspire_cp_BasicPropertyUnit.gfs"/&gt;
        &lt;featureType elementName="CadastralBoundary"
                     gfsSchemaLocation="inspire_cp_CadastralBoundary.gfs"/&gt;
        &lt;featureType elementName="CadastralParcel"
                     gfsSchemaLocation="inspire_cp_CadastralParcel.gfs"/&gt;
        &lt;featureType elementName="CadastralZoning"
                     gfsSchemaLocation="inspire_cp_CadastralZoning.gfs"/&gt;
    &lt;/namespace&gt;

    &lt;!-- Czech RUIAN (VFR) schema (v1) --&gt;
    &lt;namespace prefix="vf"
               uri="urn:cz:isvs:ruian:schemas:VymennyFormatTypy:v1 ../ruian/xsd/vymenny_format/VymennyFormatTypy.xsd"
               useGlobalSRSName="true"&gt;
        &lt;featureType elementName="TypSouboru"
                     elementValue="OB"
                     gfsSchemaLocation="ruian_vf_ob_v1.gfs"/&gt;
        &lt;featureType elementName="TypSouboru"
                     elementValue="ST"
                     gfsSchemaLocation="ruian_vf_st_v1.gfs"/&gt;
    &lt;/namespace&gt;
&lt;/gml_registry&gt;
</pre>

XML schema definition (.xsd) files are pointed by the schemaLocation attribute,
whereas OGR .gfs files are pointed by the gfsSchemaLocation attribute. In both
cases, the filename can be a URL (http://, https://), an absolute filename,
or a relative filename (relative to the location of gml_registry.xml).<p>

The schema is used if and only if the namespace prefix and URI are
found in the first bytes of the GML file
(e.g. <i>xmlns:ktjkiiwfs="http://xml.nls.fi/ktjkiiwfs/2010/02"</i>),
and that the feature type is also detected in the first bytes of the
GML file (e.g. <i>ktjkiiwfs:KiinteistorajanSijaintitiedot</i>). If the
element value is defined than the schema is used only if the feature
type together with the value is found in the first bytes of the GML
file (e.g. <i>vf:TypSouboru&gt;OB_UKSH</i>). <p>

<h2>Building junction tables</h2>

The <a href="http://svn.osgeo.org/gdal/trunk/gdal/swig/python/samples/ogr_build_junction_table.py">ogr_build_junction_table.py</a>
script can be used to build a <a href="http://en.wikipedia.org/wiki/Junction_table">junction table</a> from
OGR layers that contain "XXXX_href" fields.

Let's considering the following output of a GML file with links to other features :

<pre>
OGRFeature(myFeature):1
  gml_id (String) = myFeature.1
  [...]
  otherFeature_href (StringList) = (2:#otherFeature.10,#otherFeature.20)

OGRFeature(myFeature):2
  gml_id (String) = myFeature.2
  [...]
  otherFeature_href (StringList) = (2:#otherFeature.30,#otherFeature.10)
</pre>

After running <pre>ogr2ogr -f PG PG:dbname=mydb my.gml</pre> to
import it into PostGIS and <pre>python ogr_build_junction_table.py PG:dbname=mydb</pre>,
a <i>myfeature_otherfeature</i> table will be created and will
contain the following content :<p>

<table border="1">
<tr><th>myfeature_gml_id</th><th>otherfeature_gml_id</th></tr>
<tr><td>myFeature.1</td><td>otherFeature.10</td></tr>
<tr><td>myFeature.1</td><td>otherFeature.20</td></tr>
<tr><td>myFeature.2</td><td>otherFeature.30</td></tr>
<tr><td>myFeature.2</td><td>otherFeature.10</td></tr>
</table>

<h2>Reading datasets resulting from a WFS 2.0 join queries</h2>

Starting with GDAL 2.0, the GML driver can read datasets resulting from a WFS 2.0 join queries.<p>

Such datasets typically look like:
<pre>
&lt;wfs:FeatureCollection xmlns:xs="http://www.w3.org/2001/XMLSchema"
    xmlns:app="http://app.com"
    xmlns:wfs="http://www.opengis.net/wfs/2.0"
    xmlns:gml="http://www.opengis.net/gml/3.2"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    numberMatched="unknown" numberReturned="2" timeStamp="2015-01-01T00:00:00.000Z"
    xsi:schemaLocation="http://www.opengis.net/gml/3.2 http://schemas.opengis.net/gml/3.2.1/gml.xsd
                        http://www.opengis.net/wfs/2.0 http://schemas.opengis.net/wfs/2.0/wfs.xsd"&gt;
  &lt;wfs:member&gt;
    &lt;wfs:Tuple&gt;
      &lt;wfs:member&gt;
        &lt;app:table1 gml:id="table1-1"&gt;
          &lt;app:foo&gt;1&lt;/app:foo&gt;
        &lt;/app:table1&gt;
      &lt;/wfs:member&gt;
      &lt;wfs:member&gt;
        &lt;app:table2 gml:id="table2-1"&gt;
          &lt;app:bar&gt;2&lt;/app:bar&gt;
          &lt;app:baz&gt;foo&lt;/app:baz&gt;
          &lt;app:geometry&gt;&lt;gml:Point gml:id="table2-2.geom.0"&gt;&lt;gml:pos&gt;2 49&lt;/gml:pos&gt;&lt;/gml:Point&gt;&lt;/app:geometry&gt;
        &lt;/app:table2&gt;
      &lt;/wfs:member&gt;
    &lt;/wfs:Tuple&gt;
  &lt;/wfs:member&gt;
  &lt;wfs:member&gt;
    &lt;wfs:Tuple&gt;
      &lt;wfs:member&gt;
        &lt;app:table1 gml:id="table1-2"&gt;
          &lt;app:bar&gt;2&lt;/app:bar&gt;
          &lt;app:geometry&gt;&lt;gml:Point gml:id="table1-1.geom.0"&gt;&lt;gml:pos&gt;3 50&lt;/gml:pos&gt;&lt;/gml:Point&gt;&lt;/app:geometry&gt;
        &lt;/app:table1&gt;
      &lt;/wfs:member&gt;
      &lt;wfs:member&gt;
        &lt;app:table2 gml:id="table2-2"&gt;
          &lt;app:bar&gt;2&lt;/app:bar&gt;
          &lt;app:baz&gt;bar&lt;/app:baz&gt;
          &lt;app:geometry&gt;&lt;gml:Point gml:id="table2-2.geom.0"&gt;&lt;gml:pos&gt;2 50&lt;/gml:pos&gt;&lt;/gml:Point&gt;&lt;/app:geometry&gt;
        &lt;/app:table2&gt;
      &lt;/wfs:member&gt;
    &lt;/wfs:Tuple&gt;
  &lt;/wfs:member&gt;
&lt;/wfs:FeatureCollection&gt;
</pre>

<p>OGR will group together the attributes from the layers participating to the
join and will prefix them with the layer name. So the above example will be
read as the following:</p>
<pre>
OGRFeature(join_table1_table2):0
  table1.gml_id (String) = table1-1
  table1.foo (Integer) = 1
  table1.bar (Integer) = (null)
  table2.gml_id (String) = table2-1
  table2.bar (Integer) = 2
  table2.baz (String) = foo
  table2.geometry = POINT (2 49)

OGRFeature(join_table1_table2):1
  table1.gml_id (String) = table1-2
  table1.foo (Integer) = (null)
  table1.bar (Integer) = 2
  table2.gml_id (String) = table2-2
  table2.bar (Integer) = 2
  table2.baz (String) = bar
  table1.geometry = POINT (3 50)
  table2.geometry = POINT (2 50)
</pre>

<h2>Examples</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="https://portal.opengeospatial.org/files/?artifact_id=42729">Geography Markup Language (GML) simple features profile (with Corrigendum) (GML 3.2.1) - OGC(R) 10-100r3</a><p>
<li> <a href="http://xml.apache.org/xerces2-j/index.html">Xerces</a><p>
<li> <a href="drv_gmlas.html">GMLAS - Geography Markup Language (GML) driven by application schemas</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>
    <li>Support for cadastral data in Finnish National Land Survey GML and Inspire GML was funded by The Information Centre of the Ministry of Agriculture and Forestry (Tike)</li>
</ul>

</body>
</html>