parsing WFS/WCS/WMTS capabilities

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

parsing WFS/WCS/WMTS capabilities

Paul van Genuchten
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/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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geonetwork-devel
GeoNetwork OpenSource is maintained at http://sourceforge.net/projects/geonetwork
Reply | Threaded
Open this post in threaded view
|

Re: parsing WFS/WCS/WMTS capabilities

Olivier Guyot
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 <[hidden email]> 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/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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geonetwork-devel
GeoNetwork OpenSource is maintained at http://sourceforge.net/projects/geonetwork

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geonetwork-devel
GeoNetwork OpenSource is maintained at http://sourceforge.net/projects/geonetwork
Reply | Threaded
Open this post in threaded view
|

Re: parsing WFS/WCS/WMTS capabilities

Paul van Genuchten
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 <[hidden email]> 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 <[hidden email]> 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/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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geonetwork-devel
GeoNetwork OpenSource is maintained at http://sourceforge.net/projects/geonetwork


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geonetwork-devel
GeoNetwork OpenSource is maintained at http://sourceforge.net/projects/geonetwork
Reply | Threaded
Open this post in threaded view
|

Re: parsing WFS/WCS/WMTS capabilities

Olivier Guyot
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:

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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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/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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geonetwork-devel
GeoNetwork OpenSource is maintained at http://sourceforge.net/projects/geonetwork


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geonetwork-devel
GeoNetwork OpenSource is maintained at http://sourceforge.net/projects/geonetwork