GeoServer WCS BBOX and RESX, RESY are missing

[christianbraun]

[ldesousa]

This issue also affects the harvester. The BBox is in the GetCapabilities response document, but is not being captured.

[ldesousa]

Regarding the harvester, this problem was caused by a small bug in OWSLib (now fixed). When the harvester runs these layers will get the correct information on BBox and resolution.

Now only the mass_import is missing.

[ldesousa]

Shouldn't the WGS84 BBox be in the DescribeCoverage response? Must check the documents, this might actually be a bug with with GeoServer.

It can be solved in mass_import, but will complicate things even further.

[ldesousa]

I am now trying to merge the information of both requests (GetCapabilities and DescribeCoverage) to obtain all the information we need from GeoServer. There is a major problem with this however, GeoServer reports different coverage identifiers on each request! Take for example the response to this GetCapabilities:

http://extragisqa.gent.be/geoserver/Gent/ows?SERVICE=WCS&VERSION=1.1.1&REQUEST=GetCapabilities

There is a layer advertised as "dsm2003", but when I issue a DescribeCoverage:

http://extragisqa.gent.be/geoserver/Gent/ows?SERVICE=WCS&VERSION=1.1.1&REQUEST=DescribeCoverage&IDENTIFIERS=dsm2003

The identifier is now reported as "Gent:dsm2003"! With different identifiers I am not able to merge the metadata.

I will report this to the GeoServer mail list and see what develops from that.

[ldesousa]

The discussion thread at the GeoServer list for future reference:

http://osgeo-org.1560.x6.nabble.com/WCS-different-coverage-identifiers-in-GetCapabilities-and-DescribeCoverage-tp5206853.html

[ldesousa]

Andrea Aime has confirmed this to be a bug. It is now registered in the issue tracker: https://osgeo-org.atlassian.net/browse/GEOS-7039

I went through the WCS 1.1.1 specification an in fact the WGS84BoundingBox should not be present in the response to DescribeCoverage, i.e., GeoServer is compliant, MapServer not. It can be present in the GetCapabilities response, but it is optional. This means the strategy we are currently following might not function with other WCS servers.

I could try to fix GeoServer myself, but would then have to distribute our own release to our partners. I see it more efficient for the moment to seek some sort of workaround with the JavaScript.

Long term the best option might be to ditch WCS 1.1.1 for 2.0.

[uleopold]

At least it seems that MapServer and Geoserver are both able to provide WGS84BoundingBox under GetCapabilities (see below). So we might be able to use GetCapabilities for WGS84BoundingBox any way. WCS 2.0 provides anyway WGS84BoundingBox as well as the CRSs.

As a work around you could check first in "Keywords" and/or "OnlineRessource" if you are dealing with Geoserver and then strip off everything before and including the colon. In your example it is "Gent:". Regular expressions might do the job here. It is not the most elegant way but does the job hopefully. Maybe tehre is even a more elegant way to find out if it Geoserver which is serving data services.

Maybe also take into account already the move to WCS 2.0.x and write some commented code how this can be done in 2.0.x in the future. I agree, that WCS 2.0.x is much better. We can also urge the partners to upgrade and comply with 2.0.x in the future.

Rotterdam MapServer http://ows.gis.rotterdam.nl/cgi-bin/mapserv.exe?map=d:\gwr\webdata\mapserver\map\gwr_basis_pub.map&SERVICE=WCS&VERSION=1.1.1&REQUEST=GetCapabilities

LIST MapServer http://maps.iguess.tudor.lu/cgi-bin/mapserv?map=/srv/mapserv/MapFiles/RO_localOWS_test.map&SERVICE=WCS&VERSION=1.1.1&REQUEST=GetCapabilities

LIST QUICS Geoserver http://geo.quics.list.lu/geoserver/wcs?&SERVICE=WCS&VERSION=1.1.1&REQUEST=GetCapabilities

Gent Geoserver http://extragisqa.gent.be/geoserver/Gent/ows?SERVICE=WCS&VERSION=1.1.1&REQUEST=GetCapabilities

LIST QUICS Geoserver WCS 2.0.1 request http://geo.quics.list.lu/geoserver/wcs?&SERVICE=WCS&VERSION=2.0.1&REQUEST=GetCapabilities

[ldesousa]

Answering to uleopold: I don't think working further on OpenLayers is a solution. The pull request I made about a month ago with new parser classes for WCS 1.1.1 has not been accepted yet and there is no activity in the thread. I prefer to follow on with something more akin to the way the Harvester is dealing with this.

Regarding WCS 2.0, it is not realistic to start tackling something like that at this stage.

[uleopold]

I don't understand this answer. I did not refer to open layers and only suggested to have a more innovative thinking where we already prepare for future services. Can you better explain why now open layers and not getting ready for 2.0 by developing idea's how this can be already taken into account? I'm not saying we should move to 2.0 but take it into account for a solution. This would avoid major redevelopments for 2.0. I think it makes a lot of sense to prepare already our request developments in the view if 2.0. It just requires a bit more thinking and studying of the different standards.Sent from IBM Notes TravelerLuís de Sousa --- Re: [iguess] GeoServer WCS BBOX and RESX, RESY are missing (#265) --- From:"Luís de Sousa" notifications@github.comTo:"ERIN-LIST/iguess" iguess@noreply.github.comCc:"Ulrich Leopold" ulrich.leopold@list.luDate:Fri, 22 May 2015 10:09Subject:Re: [iguess] GeoServer WCS BBOX and RESX, RESY are missing (#265)Answering to uleopold: I don't think working further on OpenLayers is a solution. The pull request I made about a month ago with new parser classes for WCS 1.1.1 has not been accepted yet and there is no activity in the thread. I prefer to follow on with something more akin to the way the Harvester is dealing with this.

Regarding WCS 2.0, it is not realistic to start tackling something like that at this stage.

—Reply to this email directly or view it on GitHub.

[ldesousa]

If the option is to ditch OpenLayers right away, then we either develop the WCS 2.0 parser within some other library or do it ourselves from scratch. Either way, all the reminding JS code reliant on OpenLayers would have to be re-coded accordingly. Who is supposed to tackle such a task?

Once again, my advice is to wait for what comes out of the GeoExt 3.0 code sprint before any decisions are taken on replacing OpenLayers. Meanwhile we should limit any changes to OpenLayers to the bare minimum, or better still, simply freeze it.

[ldesousa]

Regarding resolution: the GridOffsets element can either contain 2 or 4 values. OpenLayers is coded to parse only 2, returning null if there are 4. This should be simple to patch.

This is likely a problem in the Harvester too, although it has not shown yet. Testing needed.

[uleopold]

We discussed OGC standards and the best version to use for requests, neither to ditch open layers, nor to implement 2.0 now. I don't know where this discussion comes from.For me it is important to have the requests working, and if 2.0 is a possible future track, to keep it in mind if that's possible. If it is too complex for you we just stick with a simple solution for now and redesign things later. Sent from IBM Notes TravelerLuís de Sousa --- Re: [iguess] GeoServer WCS BBOX and RESX, RESY are missing (#265) --- From:"Luís de Sousa" notifications@github.comTo:"ERIN-LIST/iguess" iguess@noreply.github.comCc:"Ulrich Leopold" ulrich.leopold@list.luDate:Fri, 22 May 2015 10:56Subject:Re: [iguess] GeoServer WCS BBOX and RESX, RESY are missing (#265)If the option is to ditch OpenLayers right away, then we either develop the WCS 2.0 parser within some other library or do it ourselves from scratch. Either way, all the reminding JS code reliant on OpenLayers would have to be re-coded accordingly. Who is supposed to tackle such a task?

Once again, my advice is to wait for what comes out of the GeoExt 3.0 code sprint before any decisions are taken on replacing OpenLayers. Meanwhile we should limit any changes to OpenLayers to the bare minimum, or better still, simply freeze it.

—Reply to this email directly or view it on GitHub.