is there a way to parse WFS DescribeFeatureType

[bartvde]

trafficstars

Since WFS DescribeFeatureType response is actually an XML schema, can we parse something like this with JSONIX?

Example:

http://demo.opengeo.org/geoserver/wfs?service=WFS&request=DescribeFeatureType&version=1.1.0&typename=topp:tasmania_state_boundaries

TIA for any guidance.

[highsource]

Hm, a very good idea. :)

Let me check if I'm getting this right.

• You're getting an schema as the WFS DescribeFeatureType response.
• This schema is probably not completely arbitrary but complies to a certain structure. I don't have the reference at the moment, but there is an OGC spec/profile/best practices which describes it.
• You're probably interested in
  • Feature type tasmania_state_boundariesType, global feature element name tasmania_state_boundaries, namespace http://www.openplans.org/topp.
  • Property/type mapping:
    • the_geom - gml:MultiSurfacePropertyType
    • STATE - xsd:string
    • and so on.

Correct?

[highsource]

Yes, this should be possible.

First of all, there's an XML Schema for XML Schema. So basically we could compile that schema and use the generated mappings to unmarshal the DescribeFeatureType response.

This might be a bit too heavyweight. So I would rather compile or write manually mappings for a limited subset of elements you need to unmarshal exactly those things you have in the DescribeFeatureType responses. They don't use the whole XML Schema so a very limited subset should be sufficient.

Next, here's even a cooler idea. After unmarshalling that schema you can actually dynamically build Jsonix mappings for that schema. And then use them to unmarshal the GetFeature responses.

That would be impressive, wouldn't it?

[bartvde]

that would be very impressive indeed ;-)

My first use case would be getting the list of attributes of a feature type and their types.

We had a parser for this in OpenLayers 2:

https://github.com/openlayers/openlayers/blob/master/lib/OpenLayers/Format/WFSDescribeFeatureType.js

which might give a good idea of the subset needed.

[highsource]

Ok, let me give it a try then.

[bartvde]

thanks a lot in advance! Btw my wps-gui project is almost coming to an end and I had no issues anymore with JSONIX and the mappings, all works flawlessly.

https://github.com/boundlessgeo/wps-gui

The only issue I had but worked around is:

https://github.com/boundlessgeo/wps-gui/blob/master/src/wpsclient.js#L665

[highsource]

@bartvde Could you please prepare a sample GetFeature URL for me? So that I could test unmarshalling.

[bartvde]

sure no problem here is one: http://demo.opengeo.org/geoserver/wfs?service=WFS&request=GetFeature&version=1.1.0&typename=topp:tasmania_state_boundaries&maxfeatures=5

[highsource]

@bartvde Cool! Congratulations. I'm glad it worked for you. Please file that issue, I'll take a look what is causing it.

[highsource]

Great, thank you. I'll report when I get something running.

[highsource]

Corresponding issue in w3c-schemas: Compile XML Schema 1.0 .

[highsource]

Status update.

XML Schema for XML Schema compiled without big issues:

https://github.com/highsource/w3c-schemas/tree/master/XMLSchema/2001

I just had to customize a bit to simplify a few properties:

https://github.com/highsource/w3c-schemas/blob/master/XMLSchema/2001/src/main/resources/xmlschema-v_1_0.xjb

The full resulting mappings are ~28Kb so I'll leave them as they are at the moment:

https://github.com/highsource/w3c-schemas/blob/master/scripts/lib/XSD_1_0.js

Here's a very rought sketch I've implemented:

https://github.com/highsource/w3c-schemas/blob/master/scripts/tests/XSD/1.0/XSD_1_0.js

Schema is unmarshalled without any problems. My tests does some very rough analysis and prints out the following:

{ tasmania_state_boundaries:
   { typeName:
      { namespaceURI: 'http://www.openplans.org/topp',
        localPart: 'tasmania_state_boundariesType',
        prefix: '',
        key: '{http://www.openplans.org/topp}tasmania_state_boundariesType',
        string: '{http://www.openplans.org/topp}tasmania_state_boundariesType' },
     properties:
      { the_geom: [Object],
        STATE: [Object],
        COUNTRY: [Object],
        CURR_TYPE: [Object],
        CURR_CODE: [Object] } } }

It should be now possible to build a Jsonix mappings for the tasmania_state_boundaries.

[bartvde]

wow this is very cool, really shows the power of JSONIX

[highsource]

Related issue:

https://github.com/highsource/ogc-schemas/issues/13

And test (just started, nothing in there yet):

https://github.com/highsource/ogc-schemas/blob/master/scripts/tests/WFS/1.1.0/WFS_1_1_0.js

On Thu, Oct 30, 2014 at 10:17 AM, Bart van den Eijnden < [email protected]> wrote:

wow this is very cool, really shows the power of JSONIX

— Reply to this email directly or view it on GitHub https://github.com/highsource/jsonix/issues/41#issuecomment-61063464.

[bartvde]

@highsource not very important but one thing I noticed is that minOccurs is an integer and maxOccurs is a string for the field info:

maxOccurs: "1"
minOccurs: 0

[highsource]

Because of the "unbounded" thing.

On Fri, Jan 9, 2015 at 4:18 PM, Bart van den Eijnden < [email protected]> wrote:

@highsource https://github.com/highsource not very important but one thing I noticed is that minOccurs is an integer and maxOccurs is a string for the field info:

maxOccurs: "1" minOccurs: 0

— Reply to this email directly or view it on GitHub https://github.com/highsource/jsonix/issues/41#issuecomment-69347288.

[highsource]

@bartvde Take a look at this project:

https://github.com/highsource/jsonix-support/tree/master/w/wfs-dynamic

This is what it does:

First it parses the following DescribeFeatureType request.

Then, based on the parsed data it creates a mapping for the feature type dynamically. This is the result:

{
  "n": "TOPP",
  "dens": "http://www.openplans.org/topp",
  "tis": [
    {
      "ln": "tasmania_state_boundariesType",
      "ps": [
        {
          "n": "the_geom",
          "ti": "GML_3_2_1.MultiSurfacePropertyType"
        },
        {
          "n": "STATE",
          "ti": "String"
        },
        {
          "n": "COUNTRY",
          "ti": "String"
        },
        {
          "n": "CURR_TYPE",
          "ti": "String"
        },
        {
          "n": "CURR_CODE",
          "ti": "String"
        }
      ],
      "bti": "GML_3_2_1.AbstractFeatureType"
    }
  ],
  "eis": [
    {
      "en": "tasmania_state_boundaries",
      "ti": ".tasmania_state_boundariesType"
    }
  ]
}

Next, it creates a new context (including the newly created mapping).

Finally, it parses the following GetFeature request. Below is the result (I've cut the geometry which was also fully processed):

{
  "wfs:FeatureCollection": {
    "TYPE_NAME": "WFS_2_0.FeatureCollectionType",
    "numberMatched": "1",
    "numberReturned": 1,
    "timeStamp": {
      "year": 2015,
      "month": 3,
      "day": 1,
      "hour": 18,
      "minute": 31,
      "second": 27,
      "fractionalSecond": 0.758,
      "timezone": 0
    },
    "boundedBy": {
      "TYPE_NAME": "WFS_2_0.EnvelopePropertyType",
      "any": {
        "gml:Envelope": {
          "TYPE_NAME": "GML_3_2_1.EnvelopeType",
          "lowerCorner": {
            "TYPE_NAME": "GML_3_2_1.DirectPositionType",
            "value": [
              -43.648056,
              143.83482400000003
            ]
          },
          "upperCorner": {
            "TYPE_NAME": "GML_3_2_1.DirectPositionType",
            "value": [
              -39.573891,
              148.47914100000003
            ]
          }
        }
      }
    },
    "member": [
      {
        "TYPE_NAME": "WFS_2_0.MemberPropertyType",
        "content": [
          {
            "topp:tasmania_state_boundaries": {
              "TYPE_NAME": "TOPP.tasmania_state_boundariesType",
              "id": "tasmania_state_boundaries.1",
              "boundedBy": {
                "TYPE_NAME": "GML_3_2_1.BoundingShapeType",
                "envelope": {
                  "gml:Envelope": {
                    "TYPE_NAME": "GML_3_2_1.EnvelopeType",
                    "srsDimension": 2,
                    "srsName": "urn:ogc:def:crs:EPSG::4326",
                    "lowerCorner": {
                      "TYPE_NAME": "GML_3_2_1.DirectPositionType",
                      "value": [
                        -43.648056,
                        143.83482400000003
                      ]
                    },
                    "upperCorner": {
                      "TYPE_NAME": "GML_3_2_1.DirectPositionType",
                      "value": [
                        -39.573891,
                        148.47914100000003
                      ]
                    }
                  }
                }
              },
              "the_geom": { ... },
              "STATE": "Tasmania",
              "COUNTRY": "Australia",
              "CURR_TYPE": "Australia Dollar",
              "CURR_CODE": "AUD"
            }
          }
        ]
      }
    ]
  }
}

So the proof-of-concept is there. This is a kind of generic/dynamic type and structure safe WFS Feature parser for Simple Features profile.

Kinda very cool but I'm not sure what to do about this next.

ps. You'll need the very latests Jsonix scripts to test.

[bartvde]

wow very cool indeed!

Since for most of my applications, ol3 will handle the feature parsing, I also cannot think of a use case currently.