GML enhancement proposal: Getting all XML attributes as OGR fields

[peifer]

I suggest to have a config option like: GML_ATTRIBUTES_TO_OGR_FIELDS where possible values are a list of elements or ALL, similar to the legal values for config option GML_SKIP_RESOLVE_ELEMS.

The new option would obviously influence how the .gfs files are written. I recently used FME which has this useful option as a built-in.

[Jukka Rahkonen]

Is this something that you can't do with -sql "select field1,field2,field4 from source_layer"?

[peifer]

Jukka,

Thanks for looking into the proposal. Maybe I wasn't clear enough or I am missing something. My proposal is about how the GML driver would make an initial scan through an unknown GML structure with unknown XML element names and unknown XML attributes.

The GML driver does the following currently:

--- snip ---

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 ..., quoted from ​http://www.gdal.org/ogr/drv_gml.html

--- snip ---

The very helpful auto-detection as described above currently covers the content (= character data) of XML elements, but not their attribute values. In other words, the generated .gfs template has a lot of <ElementPath>name</ElementPath> and similar, but not a single auto-detected <ElementPath>name@lang</ElementPath> . At least I wouldn't know how to influence the auto-detection in order to tell me what XML attributes have been found.

[Even Rouault]

trunk r27120 "GML: autodiscover all XML attributes as OGR fields when creating .gfs file if GML_ATTRIBUTES_TO_OGR_FIELDS is set to YES (#5418)"

[peifer]

Thanks for taking care.

In a test file [1] where area is an XML element and uom is an attribute of area, I do get the expected result:

  area (Integer) = 6
  area_uom (String) = km2

The related section of the gfs is:

    <PropertyDefn>
      <Name>area</Name>
      <ElementPath>area</ElementPath>
      <Type>Integer</Type>
    </PropertyDefn>
    <PropertyDefn>
      <Name>area_uom</Name>
      <ElementPath>area_uom</ElementPath>
      <Type>String</Type>
      <Width>3</Width>
    </PropertyDefn>

I would have expected <ElementPath>area@uom</ElementPath>, but both '_' and '@' seem to work fine as path separators.

[1] ​http://tinyurl.com/pj5zjlh

[Even Rouault]

uom attribute handling already pre-existed as a special case. Hence the behaviour you observe.