Hi, i recently added 2 PR’s to introduce WFS2 and WCS parsing capabilities using the common jsonix approach. I noticed little interest to review/contribute to the PR’s. This topic is not of interest to any of you? Or am I missing aspects to for example highlight better the benefits?
The relevant PR’s are here:
https://github.com/geonetwork/core-geonetwork/pull/3026
https://github.com/geonetwork/core-geonetwork/pull/2932
With Antonio I discussed that at some point we may want to introduce a capabilities abstraction in GN, any (wms/wfs/wcs) capabilities would be parsed into an instance of an abstracted gn-service-capabilities object, from there we could use a more generic approach to build GN UI common to various (versions of the) standards. But for now, using above approaches would be a first step to support these standards.
Three other standards that would be interesting to add in a similar way are Inspire Atom, TMS (https://github.com/geonetwork/core-geonetwork/pull/2356) and OData, introducing these standards would benefit of having such an abstracted capabilities object available, since the standards don’t provide a capabilities request/response themselves.
Looking forward to hear your thoughts around this topic.
Regards, Paul.
Hi Paul,
What do you think should be present in an abstract “Capabilities” object? I mean, each protocol has its own set of properties that may not make sense for another one. Formats, styles, resolutions… So if I understand correctly, an abstract object would only be used for parsing a list of layers. Is that correct?
Thanks for your work, hope I’m not missing something here!
···
–
camptocamp
INNOVATIVE SOLUTIONS
BY OPEN SOURCE EXPERTS
Olivier Guyot
Geospatial Developer
+33 4 58 48 20 28
Hi Olivier,
Some formats may indeed have their unique properties (like WMTS, which has tilegridset). The abstracted object should support those (or have the shared ones via inheritance). I think it’s important to identify from the UI which ones GN requires, and not necessarily support the full capabilities object. Below an example of such an object
capabilities
protocol: wms
version: 1.3.0
url: http…
projections
epsg:4326
epsg:3857
format
image/png
text/xml
list of layer/featuretype/coverage (may support nesting)
identifier:
name:
title:
styles:
scaledenominator:
metadatalink:
···
–
camptocamp
INNOVATIVE SOLUTIONS
BY OPEN SOURCE EXPERTS
Olivier Guyot
Geospatial Developer
+33 4 58 48 20 28
Ok, such an object would be easier to consume for sure. Please note that their is also support for WPS capabilities parsing in GN, see here:
https://github.com/geonetwork/core-geonetwork/blob/f6ee468fc19dd9b1cceff1b971244072d9d28759/web-ui/src/main/resources/catalog/components/viewer/wps/WpsService.js#L146
It isn’t very clear to me what is there to gain from the application point of view, apart from potentially making it easier to support new protocols/versions. Implementing a generic object for all Capabilities responses would require a lot of refactoring, and in parts of the code that are sometimes used very rarely. I think it would need to be made alongside a significant UI evolution to justify the cost.
We’ll ask if there are people interested among our customers to work specifically on this topic.
–
camptocamp
INNOVATIVE SOLUTIONS
BY OPEN SOURCE EXPERTS
Olivier Guyot
Geospatial Developer
+33 4 58 48 20 28
On Mon, Aug 27, 2018 at 2:10 PM Paul van Genuchten <paul.vangenuchten@anonymised.com> wrote:
Hi Olivier,
Some formats may indeed have their unique properties (like WMTS, which has tilegridset). The abstracted object should support those (or have the shared ones via inheritance). I think it’s important to identify from the UI which ones GN requires, and not necessarily support the full capabilities object. Below an example of such an object
capabilities
protocol: wms
version: 1.3.0
url: http…
projections
epsg:4326
epsg:3857
format
image/png
text/xml
list of layer/featuretype/coverage (may support nesting)
identifier:
name:
title:
styles:
scaledenominator:
metadatalink:
On 27 Aug 2018, at 13:05, Olivier Guyot <olivier.guyot@anonymised.com> wrote:
Hi Paul,
What do you think should be present in an abstract “Capabilities” object? I mean, each protocol has its own set of properties that may not make sense for another one. Formats, styles, resolutions… So if I understand correctly, an abstract object would only be used for parsing a list of layers. Is that correct?
From my point of view, what has been done in these PR is pretty much the best we can do: extend the existing OWS service to handle new versions/potocols. We might eventually think of a way to return flatter, simpler objects instead of straight unmarshalled XML, but that’s about it.
Thanks for your work, hope I’m not missing something here!
–
camptocamp
INNOVATIVE SOLUTIONS
BY OPEN SOURCE EXPERTS
Olivier Guyot
Geospatial Developer
+33 4 58 48 20 28
On Mon, Aug 27, 2018 at 11:40 AM Paul van Genuchten <paul.vangenuchten@anonymised.com> wrote:
Hi, i recently added 2 PR’s to introduce WFS2 and WCS parsing capabilities using the common jsonix approach. I noticed little interest to review/contribute to the PR’s. This topic is not of interest to any of you? Or am I missing aspects to for example highlight better the benefits?
The relevant PR’s are here:
https://github.com/geonetwork/core-geonetwork/pull/3026
https://github.com/geonetwork/core-geonetwork/pull/2932
With Antonio I discussed that at some point we may want to introduce a capabilities abstraction in GN, any (wms/wfs/wcs) capabilities would be parsed into an instance of an abstracted gn-service-capabilities object, from there we could use a more generic approach to build GN UI common to various (versions of the) standards. But for now, using above approaches would be a first step to support these standards.
Three other standards that would be interesting to add in a similar way are Inspire Atom, TMS (https://github.com/geonetwork/core-geonetwork/pull/2356) and OData, introducing these standards would benefit of having such an abstracted capabilities object available, since the standards don’t provide a capabilities request/response themselves.
Looking forward to hear your thoughts around this topic.
Regards, Paul.
Check out the vibrant tech community on one of the world’s most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot_______________________________________________
GeoNetwork-devel mailing list
GeoNetwork-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geonetwork-devel
GeoNetwork OpenSource is maintained at http://sourceforge.net/projects/geonetwork