simboss
commented
6 years ago Comment added by agent Support in Freshdesk ticket id 16396:
Dear Gabriel, Paal,
Providing a bit of background context, the prime format of WFS 1.1.0 and WFS 2.0 is GML (31 and 32 respectively). That's the main reason why WFS XML machinery (including App-Schema) are usually kind of expecting a GML based schema at some point, this is not specific to GeoServer. On the same line, OGC standards related with WFS kind of expect XML\GML to be available, e.g. we use a XAPTH to query complex features when performing a GetFeature request.
GML is quite complex, is not only a matter of extending a few types, for example there is also some structural rules. GML encoding rules require that complex types are never
the direct property of another complex type; they are always contained
in a property type to ensure that their type is encoded in a surrounding
element. Encoded GML is always type/property/type/property. This is
also known as the GML “striping” rule.
The way I see it, we have two possible paths here:
The first one is the one we are following right now, which is basically rewriting the DATEX schema to a GML based schema, and I agree with Gabriel: some improvements can be done to make this task easier, less error prone and easier to maintain ... but at the end we are stilling rewriting the schema. We could also investigate the possibility of implementing an automatic translation, this should be possible to do with some assumptions.
The second path, is basically the one where we don't need a GML based schema, i.e. instead of adapting the DATEX schema to a GML based schema we make GeoServer capable of handling a normal XML schema (this will not be easy to do). This puts a major constraint on this use case: a GML output will never be available, the only available output will be GeoJSON and the XML based on DATEX schema. Taking into account that the standard format for complex features types is GML, this means that no "standards" tolls will be able to communicate with this system, e.g. we will not be able to use QGIS to visualized\query DATEX features.
The option of having an automatic translation from DATEX schema to a GML is interesting since DATEX is a relatively big schema, but it is quite linear.
So the question is, taking into account the pos and cons of each option which one do you think suits best your use case ? Is worth noticing that second option should be harder to implement than the first one.
Looking forward to read your feedback.
Kind regards,
Nuno Oliveira
==
Our support, Your Success! Visit http://www.geo-solutions.it/enterprise-support-services for more information.
==
Support Engineer
GeoSolutions S.A.S.
Via di Montramito 3/A
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
Freshdesk Ticket ID: 16396
Freshdesk Ticket Agent: Support
Freshdesk Ticket Agent Email: support@geo-solutions.it
Ticket Priority: High
Freshdesk Ticket Description: