-
Notifications
You must be signed in to change notification settings - Fork 75
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
is there a way to parse WFS DescribeFeatureType #41
Comments
Hm, a very good idea. :) Let me check if I'm getting this right.
Correct? |
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 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 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 That would be impressive, wouldn't it? |
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. |
Ok, let me give it a try then. |
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 |
@bartvde Could you please prepare a sample |
@bartvde Cool! Congratulations. I'm glad it worked for you. Please file that issue, I'll take a look what is causing it. |
Great, thank you. I'll report when I get something running. |
Corresponding issue in w3c-schemas: Compile XML Schema 1.0 . |
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: 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:
It should be now possible to build a Jsonix mappings for the |
wow this is very cool, really shows the power of JSONIX |
Related issue: 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 <
|
@highsource not very important but one thing I noticed is that minOccurs is an integer and maxOccurs is a string for the field info:
|
Because of the "unbounded" thing. On Fri, Jan 9, 2015 at 4:18 PM, Bart van den Eijnden <
|
@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. |
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. |
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.
The text was updated successfully, but these errors were encountered: