-
|
Hi, I want to use our INSPIRE WFS (deegree) in ldproxy. Configuration (/store/entities/providers/MU_INSPIRE.log (replaced yml because yml can not be uploaded ): attached MaritimeBoundary is working Output browser: but Baseline has some problems: Output browser: Log: I suppose after some validation tests (XML Spy, INSPIRE Reference Validator) the geometry should be valid. Best regards, Matthias |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments 2 replies
-
|
Matthias, I had a quick look at the GML. The Baseline feature does not have a geometry, but it has embedded data types (or objects) which each has a geometry. There is no general mapping how to represent such a feature in GeoJSON, which only supports a single geometry. My guess is that such cases are simply not supported by the current, generic code for WFS providers. The current code will probably look for a geometry property as a top-level property of the feature. |
Beta Was this translation helpful? Give feedback.
-
|
Hi Clemens,
Do you think that we shouldn't use complex INSPIRE data for ldproxy or what is your experience? We have also gpkg but this is also not working: the columns are not found Are there demo files for gpkg or PostgreSQL? Best regards an a nice weekend, Matthias |
Beta Was this translation helpful? Give feedback.
-
|
The problem is not the OGC API Standards, they support complex and nested data structures, if these are needed. The limitation is with the WFS Feature Provider, which is not actively maintained and always will have constraints due to the nature of WFS. We recommend to use SQL (PostGIS or GeoPackage) as the source of feature data. With an SQL feature provider you can support very complex data models, if you have to. For some sample configurations have a look at https://github.com/ldproxy/demo. This includes the configurations, data and steps to set the APIs from https://demo.ldproxy.net up. As an aside, it is not straightforward to encode a Baseline feature in GeoJSON (or Shapefile, etc.), because of the geometries in BaselineSegment. This, however, is not an API issue, it is just that these feature formats cannot handle such constructs directly. What is probably needed is to upgrade the BaselineSegments to features. When I look into the GeoPackage, there are also no baseline segment geometries included, as far as I can tell after a quick look. |
Beta Was this translation helpful? Give feedback.
-
|
Hi, thanks a lot, we are now using PostgreSQL, works fine. Best regards, Matthias |
Beta Was this translation helpful? Give feedback.
Matthias, I had a quick look at the GML. The Baseline feature does not have a geometry, but it has embedded data types (or objects) which each has a geometry. There is no general mapping how to represent such a feature in GeoJSON, which only supports a single geometry. My guess is that such cases are simply not supported by the current, generic code for WFS providers. The current code will probably look for a geometry property as a top-level property of the feature.