The GML driver has no coordinate system support at this time.
In contrast to most GML readers, the OGR GML reader makes no effort to read the format XML Schema definition of the feature classes in a GML file. Instead it attempts to automatically discover them 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.
The first time a GML file is opened 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 automatically regenerated if the associated .gml file has a newer timestamp.
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 GML_FIELDTYPES to the value ALWAYS_STRING. Configuration options can be set via the CPLSetConfigOption() function or as environment variables.
The GML writer supports the following creation options:
ogr2ogr -f GML output.gml OCI:usr/pwd@db my_feature -where "id = 0"
The ogr2ogr utility can be used to dump the results of a PostGIS query to GML:
ogr2ogr -f GML output.gml PG:'host=myserver dbname=warmerda' -sql "SELECT pop_1994 from canada where province_name = 'Alberta'"