[gdal-dev] WCS driver
It seems to me that the WCS driver could benefit from some love. Is anybody working on it / planning to work on it? I think simply a support for gdalinfo WCS:... to get a list of offered coverages would be useful to start with. Ari ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] WCS driver
Hi Ari, > It seems to me that the WCS driver could benefit from some love. That would be a good initiative! In the wished feature list, I could add: * improve test coverage, which is really low currently: https://rawgit.com/rouault/gdalautotest-coverage-results/master/coverage_html/frmts/wcs/wcsdataset.cpp.gcov.html One issue we have for testing is the lack of stable & reliable servers. One potential way of addressing this is to use a local HTTP server, like I did recently with the /vsis3/ (and similar) subsystems, where you can add stub endpoints. An extra advantage is that you can also easily test error situations. See - example of server start and end https://trac.osgeo.org/gdal/browser/trunk/autotest/gcore/vsis3.py#L126 https://trac.osgeo.org/gdal/browser/trunk/autotest/gcore/vsis3.py#L1906 - example of installation of HTTP answers to expected requests: https://trac.osgeo.org/gdal/browser/trunk/autotest/gcore/vsis3.py#L1258 * WCS 2.0 support Even -- Spatialys - Geospatial professional services http://www.spatialys.com ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] WCS driver
Even Rouault kirjoitti 23.10.2017 klo 13:19: Hi Ari, It seems to me that the WCS driver could benefit from some love. That would be a good initiative! I could begin with the gdalinfo WCS:... to list the subdatasets. I guess that's enough for some time. In the wished feature list, I could add: * improve test coverage, which is really low currently: https://rawgit.com/rouault/gdalautotest-coverage-results/master/coverage_html/frmts/wcs/wcsdataset.cpp.gcov.html One issue we have for testing is the lack of stable & reliable servers. One potential way of addressing this is to use a local HTTP server, like I did recently with the /vsis3/ (and similar) subsystems, where you can add stub endpoints. An extra advantage is that you can also easily test error situations. See - example of server start and end https://trac.osgeo.org/gdal/browser/trunk/autotest/gcore/vsis3.py#L126 https://trac.osgeo.org/gdal/browser/trunk/autotest/gcore/vsis3.py#L1906 - example of installation of HTTP answers to expected requests: https://trac.osgeo.org/gdal/browser/trunk/autotest/gcore/vsis3.py#L1258 I think the way to go is to use local server with hand-made response variations and that looks like the needed infrastructure. * WCS 2.0 support Even Ari ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] WCS driver
Ari Jolma-2 wrote > I could begin with the gdalinfo WCS:... to list the subdatasets. I guess > that's enough for some time. My personal opinion is that developing anything for WCS 1.x versions is waste of time. WCS 2.x is much better standard and it is quite a lot different than 1.x. -Jukka Rahkonen- -- Sent from: http://osgeo-org.1560.x6.nabble.com/GDAL-Dev-f3742093.html ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] WCS driver
Hi all, splendid idea! Anybody who feels like working on WCS 2 support, feel free to contact me or my group for any sort of explanations sought (I am the spec writer of the coverages, admittedly). Note that the Coverage Implementation Schema (CIS) 1.1 is out. Maybe this is a good starter: http://external.opengeospatial.org/twiki_public/CoveragesDWG/WebHome . I' be most happy to see GDAL WCS2-enabled! cheers, Peter On 10/23/2017 12:19 PM, Even Rouault wrote: > Hi Ari, > >> It seems to me that the WCS driver could benefit from some love. > That would be a good initiative! > > In the wished feature list, I could add: > > * improve test coverage, which is really low currently: > https://rawgit.com/rouault/gdalautotest-coverage-results/master/coverage_html/frmts/wcs/wcsdataset.cpp.gcov.html > One issue we have for testing is the lack of stable & reliable servers. > One potential way of addressing this is to use a local HTTP server, like I > did recently with the /vsis3/ (and similar) > subsystems, where you can add stub endpoints. An extra advantage is that you > can also easily test error situations. > See > - example of server start and end > https://trac.osgeo.org/gdal/browser/trunk/autotest/gcore/vsis3.py#L126 > https://trac.osgeo.org/gdal/browser/trunk/autotest/gcore/vsis3.py#L1906 > - example of installation of HTTP answers to expected requests: >https://trac.osgeo.org/gdal/browser/trunk/autotest/gcore/vsis3.py#L1258 > > * WCS 2.0 support > > > Even > -- Dr. Peter Baumann - Professor of Computer Science, Jacobs University Bremen www.faculty.jacobs-university.de/pbaumann mail: p.baum...@jacobs-university.de tel: +49-421-200-3178, fax: +49-421-200-493178 - Executive Director, rasdaman GmbH Bremen (HRB 26793) www.rasdaman.com, mail: baum...@rasdaman.com tel: 0800-rasdaman, fax: 0800-rasdafax, mobile: +49-173-5837882 "Si forte in alienas manus oberraverit hec peregrina epistola incertis ventis dimissa, sed Deo commendata, precamur ut ei reddatur cui soli destinata, nec preripiat quisquam non sibi parata." (mail disclaimer, AD 1083) ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] WCS driver
jratike80 kirjoitti 23.10.2017 klo 17:23: Ari Jolma-2 wrote I could begin with the gdalinfo WCS:... to list the subdatasets. I guess that's enough for some time. My personal opinion is that developing anything for WCS 1.x versions is waste of time. WCS 2.x is much better standard and it is quite a lot different than 1.x. Are you saying that WCS 2 is too different from 1 to be developed into the same driver? I'm not familiar enough with the specs to judge that. What prompted me into this matter was a need to develop a client for ArcGIS WCS server, which advertises only different versions of WCS 1. I see from ArcGIS server docs that it supports WCS 2. Ari -Jukka Rahkonen- -- Sent from: http://osgeo-org.1560.x6.nabble.com/GDAL-Dev-f3742093.html ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] WCS driver
Peter Baumann kirjoitti 23.10.2017 klo 18:01: Hi all, splendid idea! Anybody who feels like working on WCS 2 support, feel free to contact me or my group for any sort of explanations sought (I am the spec writer of the coverages, admittedly). Note that the Coverage Implementation Schema (CIS) 1.1 is out. Maybe this is a good starter: http://external.opengeospatial.org/twiki_public/CoveragesDWG/WebHome . "universe of optional extensions" sounds like a fun software development project :) In short, how well do you see WCS 2 / the coverage model fits GDAL data model? It's not just raster anymore, right? I guess the basic question is that do you think the existing WCS driver is not an appropriate starting point? In any case I don't have at this point any real funding / time for this so I'd start incrementally and just reading the capabilities response for coverage list is enough. But, I see the importance. Ari I' be most happy to see GDAL WCS2-enabled! cheers, Peter On 10/23/2017 12:19 PM, Even Rouault wrote: Hi Ari, It seems to me that the WCS driver could benefit from some love. That would be a good initiative! In the wished feature list, I could add: * improve test coverage, which is really low currently: https://rawgit.com/rouault/gdalautotest-coverage-results/master/coverage_html/frmts/wcs/wcsdataset.cpp.gcov.html One issue we have for testing is the lack of stable & reliable servers. One potential way of addressing this is to use a local HTTP server, like I did recently with the /vsis3/ (and similar) subsystems, where you can add stub endpoints. An extra advantage is that you can also easily test error situations. See - example of server start and end https://trac.osgeo.org/gdal/browser/trunk/autotest/gcore/vsis3.py#L126 https://trac.osgeo.org/gdal/browser/trunk/autotest/gcore/vsis3.py#L1906 - example of installation of HTTP answers to expected requests: https://trac.osgeo.org/gdal/browser/trunk/autotest/gcore/vsis3.py#L1258 * WCS 2.0 support Even ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] WCS driver
On 10/23/2017 04:23 PM, jratike80 wrote: > Ari Jolma-2 wrote >> I could begin with the gdalinfo WCS:... to list the subdatasets. I guess >> that's enough for some time. > My personal opinion is that developing anything for WCS 1.x versions is > waste of time. WCS 2.x is much better standard and it is quite a lot > different than 1.x. > > -Jukka Rahkonen- > > > > -- > Sent from: http://osgeo-org.1560.x6.nabble.com/GDAL-Dev-f3742093.html > ___ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/gdal-dev yes. major version change means: incompatibilities can be expected. Actually, WCS 1 and 2 _are_ incompatibly different. WCS 1 essentially dates back to ~2000, a lot of lessons have been learnt since then. -Peter -- Dr. Peter Baumann - Professor of Computer Science, Jacobs University Bremen www.faculty.jacobs-university.de/pbaumann mail: p.baum...@jacobs-university.de tel: +49-421-200-3178, fax: +49-421-200-493178 - Executive Director, rasdaman GmbH Bremen (HRB 26793) www.rasdaman.com, mail: baum...@rasdaman.com tel: 0800-rasdaman, fax: 0800-rasdafax, mobile: +49-173-5837882 "Si forte in alienas manus oberraverit hec peregrina epistola incertis ventis dimissa, sed Deo commendata, precamur ut ei reddatur cui soli destinata, nec preripiat quisquam non sibi parata." (mail disclaimer, AD 1083) ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] WCS driver
On 10/23/2017 05:20 PM, Ari Jolma wrote: > jratike80 kirjoitti 23.10.2017 klo 17:23: >> Ari Jolma-2 wrote >>> I could begin with the gdalinfo WCS:... to list the subdatasets. I guess >>> that's enough for some time. >> My personal opinion is that developing anything for WCS 1.x versions is >> waste of time. WCS 2.x is much better standard and it is quite a lot >> different than 1.x. > > Are you saying that WCS 2 is too different from 1 to be developed into the > same driver? I'm not familiar enough with the specs to judge that. I do not know the driver code. Maybe code can be reused, but it should be inspected carefully whether it adheres to the WCS 2 semantics. If you need to test code: use the OGC compliance test suite. If you need to explore & learn WCS: look at http://standards.rasdaman.com, this is a small 1D ... 5D demo site. And see the tutorials collection on www.earthserver.eu/webinars . > > What prompted me into this matter was a need to develop a client for ArcGIS > WCS server, which advertises only different versions of WCS 1. I see from > ArcGIS server docs that it supports WCS 2. Starting 10.3, ESRI supports WCS 2. If you are looking for clients: we are using WCS 2 through OpenLayers, Leaflet, QGIS, NASA WorldWind, and several more. Should the clients not yet support it natively let us know, we have the code (likely just not yet propagated into these projects). -Peter > > Ari > >> >> -Jukka Rahkonen- >> >> >> >> -- >> Sent from: http://osgeo-org.1560.x6.nabble.com/GDAL-Dev-f3742093.html >> ___ >> gdal-dev mailing list >> gdal-dev@lists.osgeo.org >> https://lists.osgeo.org/mailman/listinfo/gdal-dev > > ___ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/gdal-dev -- Dr. Peter Baumann - Professor of Computer Science, Jacobs University Bremen www.faculty.jacobs-university.de/pbaumann mail: p.baum...@jacobs-university.de tel: +49-421-200-3178, fax: +49-421-200-493178 - Executive Director, rasdaman GmbH Bremen (HRB 26793) www.rasdaman.com, mail: baum...@rasdaman.com tel: 0800-rasdaman, fax: 0800-rasdafax, mobile: +49-173-5837882 "Si forte in alienas manus oberraverit hec peregrina epistola incertis ventis dimissa, sed Deo commendata, precamur ut ei reddatur cui soli destinata, nec preripiat quisquam non sibi parata." (mail disclaimer, AD 1083) ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] WCS driver
On lundi 23 octobre 2017 18:31:58 CEST Ari Jolma wrote: > Peter Baumann kirjoitti 23.10.2017 klo 18:01: > > Hi all, > > > > splendid idea! Anybody who feels like working on WCS 2 support, feel free > > to contact me or my group for any sort of explanations sought (I am the > > spec writer of the coverages, admittedly). Note that the Coverage > > Implementation Schema (CIS) 1.1 is out. Maybe this is a good starter: > > http://external.opengeospatial.org/twiki_public/CoveragesDWG/WebHome . > > "universe of optional extensions" > > sounds like a fun software development project :) > > In short, how well do you see WCS 2 / the coverage model fits GDAL data > model? It's not just raster anymore, right? You can certainly expose traditional 2D rasters with WCS 2. This is what MapServer does for example. If you want to deal with higher dimension coverages too, you'd probably have to use the subdataset concept of GDAL (if there are not too many values on the other axis) or require the user to set the values of the n > 2 dimensions. This was already the case in the current driver with the time dimension. Even -- Spatialys - Geospatial professional services http://www.spatialys.com ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] WCS driver
On 10/23/2017 05:31 PM, Ari Jolma wrote: > > > Peter Baumann kirjoitti 23.10.2017 klo 18:01: >> Hi all, >> >> splendid idea! Anybody who feels like working on WCS 2 support, feel free to >> contact me or my group for any sort of explanations sought (I am the spec >> writer >> of the coverages, admittedly). Note that the Coverage Implementation Schema >> (CIS) 1.1 is out. Maybe this is a good starter: >> http://external.opengeospatial.org/twiki_public/CoveragesDWG/WebHome . > > "universe of optional extensions" > > sounds like a fun software development project :) indeed - you can start with the Core (and even there specialize, cf CIS 1.1 conformance class modularization) and then can add support for extensions one by one, whenever you feel like :) > > In short, how well do you see WCS 2 / the coverage model fits GDAL data model? > It's not just raster anymore, right? coverages are a strict superset of rasters, and they can be nD. But an implementation does not need to support all cases. > > I guess the basic question is that do you think the existing WCS driver is not > an appropriate starting point? as said, I do not know the code, maybe it can be reused to some large part as the WCS Core functionality in the end still is subsetting. But a careful check for semantics (especially corner cases) is certainly appropriate. > > In any case I don't have at this point any real funding / time for this so I'd > start incrementally and just reading the capabilities response for coverage > list is enough. But, I see the importance. > > Ari > >> I' be >> most happy to see GDAL WCS2-enabled! >> >> cheers, >> Peter >> >> >> On 10/23/2017 12:19 PM, Even Rouault wrote: >>> Hi Ari, >>> It seems to me that the WCS driver could benefit from some love. >>> That would be a good initiative! >>> >>> In the wished feature list, I could add: >>> >>> * improve test coverage, which is really low currently: >>> https://rawgit.com/rouault/gdalautotest-coverage-results/master/coverage_html/frmts/wcs/wcsdataset.cpp.gcov.html >>> >>> One issue we have for testing is the lack of stable & reliable servers. >>> One potential way of addressing this is to use a local HTTP server, like I >>> did recently with the /vsis3/ (and similar) >>> subsystems, where you can add stub endpoints. An extra advantage is that you >>> can also easily test error situations. >>> See >>> - example of server start and end >>> https://trac.osgeo.org/gdal/browser/trunk/autotest/gcore/vsis3.py#L126 >>> >>> https://trac.osgeo.org/gdal/browser/trunk/autotest/gcore/vsis3.py#L1906 >>> - example of installation of HTTP answers to expected requests: >>> >>> https://trac.osgeo.org/gdal/browser/trunk/autotest/gcore/vsis3.py#L1258 >>> >>> * WCS 2.0 support >>> >>> >>> Even >>> > > ___ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/gdal-dev -- Dr. Peter Baumann - Professor of Computer Science, Jacobs University Bremen www.faculty.jacobs-university.de/pbaumann mail: p.baum...@jacobs-university.de tel: +49-421-200-3178, fax: +49-421-200-493178 - Executive Director, rasdaman GmbH Bremen (HRB 26793) www.rasdaman.com, mail: baum...@rasdaman.com tel: 0800-rasdaman, fax: 0800-rasdafax, mobile: +49-173-5837882 "Si forte in alienas manus oberraverit hec peregrina epistola incertis ventis dimissa, sed Deo commendata, precamur ut ei reddatur cui soli destinata, nec preripiat quisquam non sibi parata." (mail disclaimer, AD 1083) ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] WCS driver
Even Rouault kirjoitti 23.10.2017 klo 13:19: Hi Ari, It seems to me that the WCS driver could benefit from some love. That would be a good initiative! In the wished feature list, I could add: * improve test coverage, which is really low currently: https://rawgit.com/rouault/gdalautotest-coverage-results/master/coverage_html/frmts/wcs/wcsdataset.cpp.gcov.html One issue we have for testing is the lack of stable & reliable servers. One potential way of addressing this is to use a local HTTP server, like I did recently with the /vsis3/ (and similar) subsystems, where you can add stub endpoints. An extra advantage is that you can also easily test error situations. See - example of server start and end https://trac.osgeo.org/gdal/browser/trunk/autotest/gcore/vsis3.py#L126 https://trac.osgeo.org/gdal/browser/trunk/autotest/gcore/vsis3.py#L1906 - example of installation of HTTP answers to expected requests: https://trac.osgeo.org/gdal/browser/trunk/autotest/gcore/vsis3.py#L1258 * WCS 2.0 support Is there any reason not to switch to libxml2 from minixml? I see only GMLAS driver uses libxml2 currently, and maybe OGR VRT. Ari Even ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] WCS driver
> Is there any reason not to switch to libxml2 from minixml? > > I see only GMLAS driver uses libxml2 currently Ah, yes indirectly when it validates the data/gmlasconf.xml file against data/gmlasconf.xsd, since CPLValidateXML() uses libxml2 underneath to do that (it could actually have an alternate implementation using Xerces-C validation functionnalities.) > , and maybe OGR VRT. Same thing, OGR VRT, optionnaly, uses libxml2 to validate the .vrt file against its schema. But minixml functionnality should be enough for WCS purposes, and libxml2 and Xerces-C remain optional dependencies. Even -- Spatialys - Geospatial professional services http://www.spatialys.com ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] WCS driver
On 10/23/2017 08:47 PM, Even Rouault wrote: > On lundi 23 octobre 2017 18:31:58 CEST Ari Jolma wrote: >> Peter Baumann kirjoitti 23.10.2017 klo 18:01: >>> Hi all, >>> >>> splendid idea! Anybody who feels like working on WCS 2 support, feel free >>> to contact me or my group for any sort of explanations sought (I am the >>> spec writer of the coverages, admittedly). Note that the Coverage >>> Implementation Schema (CIS) 1.1 is out. Maybe this is a good starter: >>> http://external.opengeospatial.org/twiki_public/CoveragesDWG/WebHome . >> >> "universe of optional extensions" >> >> sounds like a fun software development project :) >> >> In short, how well do you see WCS 2 / the coverage model fits GDAL data >> model? It's not just raster anymore, right? > > You can certainly expose traditional 2D rasters with WCS 2. This is what > MapServer does for example. If you want to deal with higher dimension > coverages too, you'd probably have to use the subdataset concept of GDAL (if > there are not too many values on the other axis) or require the user to set > the values of the n > 2 dimensions. This was already the case in the current > driver with the time dimension. The netcdf files I looked at through the GDAL driver had time and/or depth offered as different gdal layers, and offered different variables (i.e. different coverages) as subdatasets. Which other GDAL drivers give direct access to time-varying raster stacks in single files? > > Even > -- Edzer Pebesma Institute for Geoinformatics Heisenbergstrasse 2, 48151 Muenster, Germany Phone: +49 251 8333081 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] WCS driver
> The netcdf files I looked at through the GDAL driver had time and/or > depth offered as different gdal layers, and offered different variables > (i.e. different coverages) as subdatasets. Yes, although in the WCS case, a coverage can have several bands, and thus using the band mechanism to reflect the N>2 dimensions can become confusing. The only clean solution to that would be to have a true multidimensional raster support at the GDAL API level, but that's a rather involved effort. > > Which other GDAL drivers give direct access to time-varying raster > stacks in single files? I guess HDF5, as it is really close to netCDF. GRIB could potentially be used to have time-varying raster, although, from what I saw, generally you put instead different variables for the same forecast time in the same file. But technically you couldx just concatenate any amount of GRIB messages into a single file and this will be seen as a multi-band raster by GDAL. Even -- Spatialys - Geospatial professional services http://www.spatialys.com ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] WCS driver
Even Rouault kirjoitti 24.10.2017 klo 13:28: > The netcdf files I looked at through the GDAL driver had time and/or > depth offered as different gdal layers, and offered different variables > (i.e. different coverages) as subdatasets. Yes, although in the WCS case, a coverage can have several bands, and thus using the band mechanism to reflect the N>2 dimensions can become confusing. Also in NetCDF the time dimension may be as bands - at least I have marine research data which opens first as having two subdatasets (mean and max wave height) and then as bands (the monthly values). The only clean solution to that would be to have a true multidimensional raster support at the GDAL API level, but that's a rather involved effort. Above the division to subdatasets and bands seems arbitrary and perhaps not user controllable. I agree it would be useful to have a better data model in this respect. Ari > > Which other GDAL drivers give direct access to time-varying raster > stacks in single files? I guess HDF5, as it is really close to netCDF. GRIB could potentially be used to have time-varying raster, although, from what I saw, generally you put instead different variables for the same forecast time in the same file. But technically you couldx just concatenate any amount of GRIB messages into a single file and this will be seen as a multi-band raster by GDAL. Even -- Spatialys - Geospatial professional services http://www.spatialys.com ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] WCS driver
Whoa! How hard can XML be? I have a real Capabilities document (from well known company) which defines *both* default and ows namespace to http://www.opengis.net/ows/2.0. Thus, to be sure, I need to look for *both* ows:ServiceIdentification and ServiceIdentification. Or maybe loop through all elements and check for both at each element? And additional spice is that in WCS 1.1.0 ServiceIdentification is in namespace http://www.opengis.net/wcs/1.1/ows. :) Ari Even Rouault kirjoitti 24.10.2017 klo 12:45: > Is there any reason not to switch to libxml2 from minixml? > > I see only GMLAS driver uses libxml2 currently Ah, yes indirectly when it validates the data/gmlasconf.xml file against data/gmlasconf.xsd, since CPLValidateXML() uses libxml2 underneath to do that (it could actually have an alternate implementation using Xerces-C validation functionnalities.) > , and maybe OGR VRT. Same thing, OGR VRT, optionnaly, uses libxml2 to validate the .vrt file against its schema. But minixml functionnality should be enough for WCS purposes, and libxml2 and Xerces-C remain optional dependencies. Even -- Spatialys - Geospatial professional services http://www.spatialys.com ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] WCS driver
FWIW, OWS Common 2.0 is known to be flawed in several aspects (we spec writers suffered dearly - from the resources it needed to discover, to finding workarounds in the spec, to explaining to people...). Trust me, the namespace issue is just a minor one in comparison... OGC is looking to get something revised since 2 (?) years now, and until that will come we will have to live with this situation, unfortunately and sometimes painfully. just 2 cents, Peter On 10/24/2017 04:07 PM, Ari Jolma wrote: > > Whoa! How hard can XML be? I have a real Capabilities document (from well > known company) which defines *both* default and ows namespace to > http://www.opengis.net/ows/2.0. > > Thus, to be sure, I need to look for *both* ows:ServiceIdentification and > ServiceIdentification. Or maybe loop through all elements and check for both > at each element? > > And additional spice is that in WCS 1.1.0 ServiceIdentification is in > namespace http://www.opengis.net/wcs/1.1/ows. :) > > Ari > > > Even Rouault kirjoitti 24.10.2017 klo 12:45: >> >> > Is there any reason not to switch to libxml2 from minixml? >> >> > >> >> > I see only GMLAS driver uses libxml2 currently >> >> >> >> Ah, yes indirectly when it validates the data/gmlasconf.xml file against >> data/gmlasconf.xsd, since CPLValidateXML() uses libxml2 underneath to do that >> (it could actually have an alternate implementation using Xerces-C validation >> functionnalities.) >> >> >> >> > , and maybe OGR VRT. >> >> >> >> Same thing, OGR VRT, optionnaly, uses libxml2 to validate the .vrt file >> against its schema. >> >> >> >> But minixml functionnality should be enough for WCS purposes, and libxml2 and >> Xerces-C remain optional dependencies. >> >> >> >> Even >> >> >> >> >> >> -- >> >> Spatialys - Geospatial professional services >> >> http://www.spatialys.com >> > > > > ___ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/gdal-dev -- Dr. Peter Baumann - Professor of Computer Science, Jacobs University Bremen www.faculty.jacobs-university.de/pbaumann mail: p.baum...@jacobs-university.de tel: +49-421-200-3178, fax: +49-421-200-493178 - Executive Director, rasdaman GmbH Bremen (HRB 26793) www.rasdaman.com, mail: baum...@rasdaman.com tel: 0800-rasdaman, fax: 0800-rasdafax, mobile: +49-173-5837882 "Si forte in alienas manus oberraverit hec peregrina epistola incertis ventis dimissa, sed Deo commendata, precamur ut ei reddatur cui soli destinata, nec preripiat quisquam non sibi parata." (mail disclaimer, AD 1083) ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] WCS driver
On mardi 24 octobre 2017 17:07:51 CEST Ari Jolma wrote: > Whoa! How hard can XML be? I have a real Capabilities document (from > well known company) which defines *both* default and ows namespace to > http://www.opengis.net/ows/2.0. > > Thus, to be sure, I need to look for *both* ows:ServiceIdentification > and ServiceIdentification. Or maybe loop through all elements and check > for both at each element? If there's no ambiguity with elements having same names in different namespaces, you can just strip namespace prefixes from elements with CPLStripXMLNamespace(psRoot, NULL, true) -- Spatialys - Geospatial professional services http://www.spatialys.com ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] WCS driver
Even Rouault kirjoitti 24.10.2017 klo 20:23: On mardi 24 octobre 2017 17:07:51 CEST Ari Jolma wrote: > Whoa! How hard can XML be? I have a real Capabilities document (from > well known company) which defines *both* default and ows namespace to > http://www.opengis.net/ows/2.0. > > Thus, to be sure, I need to look for *both* ows:ServiceIdentification > and ServiceIdentification. Or maybe loop through all elements and check > for both at each element? If there's no ambiguity with elements having same names in different namespaces, you can just strip namespace prefixes from elements with CPLStripXMLNamespace(psRoot, NULL, true) I implemented a solution, where the namespace prefixes is a list (CPLStringList). That is probably a general solution and actually quite simple. Some fundamental thoughts on how to use the driver. The idea is to allow starting from a GetCapabilities request. The initial dataset name is thus WCS:URL where the URL may be without any parameters. We'll add service and request parameters but *not* version or acceptVersions since the server should return the latest supported version. The one I test with seems to return 1.1.2 and 2.0.1 only when requested. We'll leave it to user to add the version/acceptVersions. The user can also add updateSequence and other parameters. If the user adds coverage/identifiers/coverageId then we'll proceed directly to DescribeCoverage or further to GetCoverage if there are bounding boxes or such. DescribeCoverage is needed unless it is cached (see below) since it probably contains important metadata (nodata value, min and max values etc). Errors are reported to the user - it is important to know whether the error is HTTP 404 or ExceptionReport InvalidParameterValue. The driver currently honors some HTTP parameters such as timeout length, authorization etc. and they are in the service XML. How to forward them to the driver in the case of this simple dataset name case? Environment variables or somehow coded into the dataset name? (for example "WCS:x=y,URL=url" ?) Also, it would be useful to cache at least the capabilities and coverage description. I have not yet thought much about that but using something like $HOME/.gdal/wcs_cache would be preferred I guess? Then there is the question how the user can control refreshing the cache - with options as above? Ari -- Spatialys - Geospatial professional services http://www.spatialys.com ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] WCS driver
I have my initial work here: https://github.com/ajolma/gdal/commit/2335bc6222e8d8df7e4b5fcfe21a825c727ad549 what I've done so far: * Recognize WCS:URL format * Parse GetCapabilities XML (versions 1.0.0 to 2.0.1) * Simple cache for various XML-files (PAM, WCS_GDAL, Capabilities, DescribeCoverage) My goal is to support something like (1-3 work somehow, 3 only for 1.0.0 - for 1.1.1 it issues a too large GetCoverage request, maybe I broke something(?)) 1) gdalinfo WCS:URL-to-server this fetches, parses and caches GetCapabilities XML 2) pick a layer from the list (DescribeCoverage URL is given) 3) gdalinfo WCS:DescribeCoverage-URL 4) use the layer I'll work on at least basic support for 2.0.1 - time permitting. Notes: * No tests yet in the autotest suite * I'm testing against existing ArcGIS, GeoServer and MapServer servers on the net * The namespace support in parsing XML may be a bit overkill, but anyway its there. * There are a few small utility functions - some could perhaps be replaced by ones from port and some could perhaps be added there in some form; and all could be improved. Ari Even Rouault kirjoitti 23.10.2017 klo 13:19: Hi Ari, It seems to me that the WCS driver could benefit from some love. That would be a good initiative! In the wished feature list, I could add: * improve test coverage, which is really low currently: https://rawgit.com/rouault/gdalautotest-coverage-results/master/coverage_html/frmts/wcs/wcsdataset.cpp.gcov.html One issue we have for testing is the lack of stable & reliable servers. One potential way of addressing this is to use a local HTTP server, like I did recently with the /vsis3/ (and similar) subsystems, where you can add stub endpoints. An extra advantage is that you can also easily test error situations. See - example of server start and end https://trac.osgeo.org/gdal/browser/trunk/autotest/gcore/vsis3.py#L126 https://trac.osgeo.org/gdal/browser/trunk/autotest/gcore/vsis3.py#L1906 - example of installation of HTTP answers to expected requests: https://trac.osgeo.org/gdal/browser/trunk/autotest/gcore/vsis3.py#L1258 * WCS 2.0 support Even ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] WCS driver
cool work! Once released, you may want to list yourself here: https://en.wikipedia.org/wiki/Web_Coverage_Service . FYI, GDAL is already listed here: http://external.opengeospatial.org/twiki_public/CoveragesDWG/WebHome#Known_Implementations -Peter On 10/27/2017 06:38 PM, Ari Jolma wrote: > I have my initial work here: > > https://github.com/ajolma/gdal/commit/2335bc6222e8d8df7e4b5fcfe21a825c727ad549 > > what I've done so far: > > * Recognize WCS:URL format > > * Parse GetCapabilities XML (versions 1.0.0 to 2.0.1) > > * Simple cache for various XML-files (PAM, WCS_GDAL, Capabilities, > DescribeCoverage) > > My goal is to support something like (1-3 work somehow, 3 only for 1.0.0 - for > 1.1.1 it issues a too large GetCoverage request, maybe I broke something(?)) > > 1) gdalinfo WCS:URL-to-server > > this fetches, parses and caches GetCapabilities XML > > 2) pick a layer from the list (DescribeCoverage URL is given) > > 3) gdalinfo WCS:DescribeCoverage-URL > > 4) use the layer > > I'll work on at least basic support for 2.0.1 - time permitting. > > Notes: > > * No tests yet in the autotest suite > > * I'm testing against existing ArcGIS, GeoServer and MapServer servers on the > net > > * The namespace support in parsing XML may be a bit overkill, but anyway its > there. > > * There are a few small utility functions - some could perhaps be replaced by > ones from port and some could perhaps be added there in some form; and all > could be improved. > > Ari > > > Even Rouault kirjoitti 23.10.2017 klo 13:19: >> Hi Ari, >> >>> It seems to me that the WCS driver could benefit from some love. >> That would be a good initiative! >> >> In the wished feature list, I could add: >> >> * improve test coverage, which is really low currently: >> https://rawgit.com/rouault/gdalautotest-coverage-results/master/coverage_html/frmts/wcs/wcsdataset.cpp.gcov.html >> >> One issue we have for testing is the lack of stable & reliable servers. >> One potential way of addressing this is to use a local HTTP server, like I >> did recently with the /vsis3/ (and similar) >> subsystems, where you can add stub endpoints. An extra advantage is that you >> can also easily test error situations. >> See >> - example of server start and end >> https://trac.osgeo.org/gdal/browser/trunk/autotest/gcore/vsis3.py#L126 >> >> https://trac.osgeo.org/gdal/browser/trunk/autotest/gcore/vsis3.py#L1906 >> - example of installation of HTTP answers to expected requests: >> >> https://trac.osgeo.org/gdal/browser/trunk/autotest/gcore/vsis3.py#L1258 >> >> * WCS 2.0 support >> >> >> Even >> > > ___ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/gdal-dev -- Dr. Peter Baumann - Professor of Computer Science, Jacobs University Bremen www.faculty.jacobs-university.de/pbaumann mail: p.baum...@jacobs-university.de tel: +49-421-200-3178, fax: +49-421-200-493178 - Executive Director, rasdaman GmbH Bremen (HRB 26793) www.rasdaman.com, mail: baum...@rasdaman.com tel: 0800-rasdaman, fax: 0800-rasdafax, mobile: +49-173-5837882 "Si forte in alienas manus oberraverit hec peregrina epistola incertis ventis dimissa, sed Deo commendata, precamur ut ei reddatur cui soli destinata, nec preripiat quisquam non sibi parata." (mail disclaimer, AD 1083) ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] WCS driver
Ari Jolma kirjoitti 27.10.2017 klo 19:38: * I'm testing against existing ArcGIS, GeoServer and MapServer servers on the net Version 1.0.0 seems to be usually understandable/ok but strangeness begins with 1.1 For example this request to a MapServer WCS (I'm not responsible for that server so don't know much about it), which is generated in the driver during a DescribeCoverage for the coverage, http://194.66.252.155/cgi-bin/BGS_EMODnet_bathymetry/ows?SERVICE=WCS&VERSION=1.1.1&REQUEST=GetCoverage&IDENTIFIER=BGS_EMODNET_CentralMed-MCol&FORMAT=image%2Ftiff&BOUNDINGBOX=9.83335,46.18325,9.83755,46.18745,urn:ogc:def:crs:EPSG::4326&RangeSubset=band gets the response WCS server error. Requested BBOX (46.18325,9.83335,46.18745,9.83755) is outside requested coverage BBOX (9.83125,30.01040372,22.23542659,46.18958333) If I change the order of X and Y in the bounding box in the request, the reply is ok. I'm thinking MapServer is in error here, for example similar request to ArcGIS WCS server http://paikkatieto.ymparisto.fi/arcgis/services/Testit/Velmu_wcs_testi/MapServer/WCSServer?SERVICE=WCS&VERSION=1.1.2&REQUEST=GetCoverage&IDENTIFIER=1&FORMAT=image%2FGeoTIFF&BOUNDINGBOX=61686.0383772501,7302181.14320843,61706.0383772501,7302201.14320843,urn:ogc:def:crs:EPSG::3067&RangeSubset=Field_1 gets an ok response. The case of GeoServer is also strange https://msp.smartsea.fmi.fi/geoserver/wcs?SERVICE=WCS&VERSION=1.1.1&REQUEST=GetCoverage&IDENTIFIER=smartsea%3Aeusm2016&FORMAT=image%2Ftiff&BOUNDINGBOX=61610,7303970,61630,7303990,urn:ogc:def:crs:EPSG::3067&RangeSubset=contents -- GeoServer does not seem to understand that GDAL wants only a 2 x 2 sample - the response is huge (the whole geotiff?). Ari ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] WCS driver
Ari Jolma-2 wrote > Ari Jolma kirjoitti 27.10.2017 klo 19:38: >> >> >> * I'm testing against existing ArcGIS, GeoServer and MapServer servers >> on the net > > Version 1.0.0 seems to be usually understandable/ok but strangeness > begins with 1.1 > > For example this request to a MapServer WCS (I'm not responsible for > that server so don't know much about it), which is generated in the > driver during a DescribeCoverage for the coverage, > > http://194.66.252.155/cgi-bin/BGS_EMODnet_bathymetry/ows?SERVICE=WCS&VERSION=1.1.1&REQUEST=GetCoverage&IDENTIFIER=BGS_EMODNET_CentralMed-MCol&FORMAT=image%2Ftiff&BOUNDINGBOX=9.83335,46.18325,9.83755,46.18745,urn:ogc:def:crs:EPSG::4326&RangeSubset=band > > gets the response > > WCS server error. Requested BBOX > (46.18325,9.83335,46.18745,9.83755) is outside requested > coverage BBOX (9.83125,30.01040372,22.23542659,46.18958333) > > If I change the order of X and Y in the bounding box in the request, the > reply is ok. I'm thinking MapServer is in error here, for example > similar request to ArcGIS WCS server > > http://paikkatieto.ymparisto.fi/arcgis/services/Testit/Velmu_wcs_testi/MapServer/WCSServer?SERVICE=WCS&VERSION=1.1.2&REQUEST=GetCoverage&IDENTIFIER=1&FORMAT=image%2FGeoTIFF&BOUNDINGBOX=61686.0383772501,7302181.14320843,61706.0383772501,7302201.14320843,urn:ogc:def:crs:EPSG::3067&RangeSubset=Field_1 > > gets an ok response. > > The case of GeoServer is also strange > > https://msp.smartsea.fmi.fi/geoserver/wcs?SERVICE=WCS&VERSION=1.1.1&REQUEST=GetCoverage&IDENTIFIER=smartsea%3Aeusm2016&FORMAT=image%2Ftiff&BOUNDINGBOX=61610,7303970,61630,7303990,urn:ogc:def:crs:EPSG::3067&RangeSubset=contents > > -- GeoServer does not seem to understand that GDAL wants only a 2 x 2 > sample - the response is huge (the whole geotiff?). > > Ari Hi, BoundingBoxes in WCS 1.1.x and 2.x must follow the axis order of the coordinate system, so with urn:ogc:def:crs:EPSG::4326 it must be latitude-longitude. EPSG:3067 is natively an easting-northing system and therefore it can make you believe that everything works fine but if you test the Finnish services also with northing-easting system EPSG:2393 you may get more frustration. An open Geoserver with a DEM of Finland is available for testing at http://avoindata.maanmittauslaitos.fi/geoserver/wcs?service=WCS&version=2.0.1&request=GetCapabilities -Jukka Rahkonen- -- Sent from: http://osgeo-org.1560.x6.nabble.com/GDAL-Dev-f3742093.html ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] WCS driver
jratike80 kirjoitti 28.10.2017 klo 13:10: Ari Jolma-2 wrote For example this request to a MapServer WCS (I'm not responsible for that server so don't know much about it), which is generated in the driver during a DescribeCoverage for the coverage, http://194.66.252.155/cgi-bin/BGS_EMODnet_bathymetry/ows?SERVICE=WCS&VERSION=1.1.1&REQUEST=GetCoverage&IDENTIFIER=BGS_EMODNET_CentralMed-MCol&FORMAT=image%2Ftiff&BOUNDINGBOX=9.83335,46.18325,9.83755,46.18745,urn:ogc:def:crs:EPSG::4326&RangeSubset=band gets the response WCS server error. Requested BBOX (46.18325,9.83335,46.18745,9.83755) is outside requested coverage BBOX (9.83125,30.01040372,22.23542659,46.18958333) If I change the order of X and Y in the bounding box in the request, the reply is ok. Hi, BoundingBoxes in WCS 1.1.x and 2.x must follow the axis order of the coordinate system, so with urn:ogc:def:crs:EPSG::4326 it must be latitude-longitude. ok, this is the famous confusion concerning axis order. To me it seems that GDAL is correct since it determines the bounding box originally from GridCRS in CoverageDescription where the origin is said to be "9.83335 46.18745" (i.e., lon-lat). In the same GridCRS the CRS is stated to be "urn:ogc:def:crs:EPSG::4326" - so the axis order could be assumed correct. Interestingly in the same CoverageDescription MapServer says the LowerCorner of the "urn:ogc:def:crs:EPSG::4326" BoundingBox is "30.01040372 9.83125" (i.e., lat-lon). So it seems to me that MapServer is contradicting itself. Reading MapServer code, it seems to be based on the idea that x,y is always east,north and when it writes BoundingBox, it swaps x and y if the projection is inverted (like 4326). It does not do that when it writes GridCRS. GDAL seems to be based on the idea that x,y is what the projection says (what the projection says could be found out with OGRSpatialReference::GetAxis - however, for 4326 it does not say anything). This is my impression from WCS driver - I see there's a lot on this issue in the GML driver page. A fix could be a WCS driver option "swap axis order for bounding box". But since I think that is not fixing the root cause (lying twice does not make you a truth speaker), also an option "swap axis order when reading GridOrigin" is needed. Isn't this fun? EPSG:3067 is natively an easting-northing system and therefore it can make you believe that everything works fine but if you test the Finnish services also with northing-easting system EPSG:2393 you may get more frustration. I'm sure you mean 'fun'. An open Geoserver with a DEM of Finland is available for testing at http://avoindata.maanmittauslaitos.fi/geoserver/wcs?service=WCS&version=2.0.1&request=GetCapabilities I'll try the axis order with that. The geoserver at msp.smartsea.fmi.fi is mine and I'm not sure how well I can manage a geoserver. Ari -Jukka Rahkonen- -- Sent from: http://osgeo-org.1560.x6.nabble.com/GDAL-Dev-f3742093.html ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] WCS driver
FYI, this is one of the shortcomings of WCS 1.x. Remedied in WCS 2. -Peter On 10/28/2017 04:39 PM, Ari Jolma wrote: > jratike80 kirjoitti 28.10.2017 klo 13:10: > >> Ari Jolma-2 wrote >>> >>> For example this request to a MapServer WCS (I'm not responsible for >>> that server so don't know much about it), which is generated in the >>> driver during a DescribeCoverage for the coverage, >>> >>> http://194.66.252.155/cgi-bin/BGS_EMODnet_bathymetry/ows?SERVICE=WCS&VERSION=1.1.1&REQUEST=GetCoverage&IDENTIFIER=BGS_EMODNET_CentralMed-MCol&FORMAT=image%2Ftiff&BOUNDINGBOX=9.83335,46.18325,9.83755,46.18745,urn:ogc:def:crs:EPSG::4326&RangeSubset=band >>> >>> >>> gets the response >>> >>> WCS server error. Requested BBOX >>> (46.18325,9.83335,46.18745,9.83755) is outside requested >>> coverage BBOX (9.83125,30.01040372,22.23542659,46.18958333) >>> >>> If I change the order of X and Y in the bounding box in the request, the >>> reply is ok. >> Hi, >> >> BoundingBoxes in WCS 1.1.x and 2.x must follow the axis order of the >> coordinate system, so with urn:ogc:def:crs:EPSG::4326 it must be >> latitude-longitude. > > ok, this is the famous confusion concerning axis order. > > To me it seems that GDAL is correct since it determines the bounding box > originally from GridCRS in CoverageDescription where the origin is said to be > "9.83335 46.18745" (i.e., lon-lat). In the same GridCRS the CRS is > stated to be "urn:ogc:def:crs:EPSG::4326" - so the axis order could be assumed > correct. Interestingly in the same CoverageDescription MapServer says the > LowerCorner of the "urn:ogc:def:crs:EPSG::4326" BoundingBox is "30.01040372 > 9.83125" (i.e., lat-lon). So it seems to me that MapServer is contradicting > itself. > > Reading MapServer code, it seems to be based on the idea that x,y is always > east,north and when it writes BoundingBox, it swaps x and y if the projection > is inverted (like 4326). It does not do that when it writes GridCRS. > > GDAL seems to be based on the idea that x,y is what the projection says (what > the projection says could be found out with OGRSpatialReference::GetAxis - > however, for 4326 it does not say anything). This is my impression from WCS > driver - I see there's a lot on this issue in the GML driver page. > > A fix could be a WCS driver option "swap axis order for bounding box". But > since I think that is not fixing the root cause (lying twice does not make you > a truth speaker), also an option "swap axis order when reading GridOrigin" is > needed. Isn't this fun? > > >> EPSG:3067 is natively an easting-northing system and >> therefore it can make you believe that everything works fine but if you test >> the Finnish services also with northing-easting system EPSG:2393 you may get >> more frustration. > I'm sure you mean 'fun'. >> >> An open Geoserver with a DEM of Finland is available for testing at >> http://avoindata.maanmittauslaitos.fi/geoserver/wcs?service=WCS&version=2.0.1&request=GetCapabilities >> > > I'll try the axis order with that. The geoserver at msp.smartsea.fmi.fi is > mine and I'm not sure how well I can manage a geoserver. > > Ari > >> >> -Jukka Rahkonen- >> >> >> >> >> -- >> Sent from: http://osgeo-org.1560.x6.nabble.com/GDAL-Dev-f3742093.html >> ___ >> gdal-dev mailing list >> gdal-dev@lists.osgeo.org >> https://lists.osgeo.org/mailman/listinfo/gdal-dev > > ___ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/gdal-dev -- Dr. Peter Baumann - Professor of Computer Science, Jacobs University Bremen www.faculty.jacobs-university.de/pbaumann mail: p.baum...@jacobs-university.de tel: +49-421-200-3178, fax: +49-421-200-493178 - Executive Director, rasdaman GmbH Bremen (HRB 26793) www.rasdaman.com, mail: baum...@rasdaman.com tel: 0800-rasdaman, fax: 0800-rasdafax, mobile: +49-173-5837882 "Si forte in alienas manus oberraverit hec peregrina epistola incertis ventis dimissa, sed Deo commendata, precamur ut ei reddatur cui soli destinata, nec preripiat quisquam non sibi parata." (mail disclaimer, AD 1083) ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] WCS driver
jratike80 kirjoitti 28.10.2017 klo 13:10: Ari Jolma-2 wrote The case of GeoServer is also strange https://msp.smartsea.fmi.fi/geoserver/wcs?SERVICE=WCS&VERSION=1.1.1&REQUEST=GetCoverage&IDENTIFIER=smartsea%3Aeusm2016&FORMAT=image%2Ftiff&BOUNDINGBOX=61610,7303970,61630,7303990,urn:ogc:def:crs:EPSG::3067&RangeSubset=contents -- GeoServer does not seem to understand that GDAL wants only a 2 x 2 sample - the response is huge (the whole geotiff?). Ari An open Geoserver with a DEM of Finland is available for testing at http://avoindata.maanmittauslaitos.fi/geoserver/wcs?service=WCS&version=2.0.1&request=GetCapabilities Same thing with this server (I'm still testing with version 1.1), except that it is nice enough to let me know that ERROR 1: This request is trying to generate too much data, the limit is 488.28MB but the actual amount of bytes to be written in the output is 18479MB With the help of GeoServer demo tool in its admin panel, it seems necessary to add GridCRS to the request http://avoindata.maanmittauslaitos.fi/geoserver/wcs?SERVICE=WCS&VERSION=1.1.0&REQUEST=GetCoverage&IDENTIFIER=korkeusmalli_10m%3Akorkeusmalli_10m&FORMAT=image%2Ftiff&BOUNDINGBOX=44005,7781985,44015,7781995,urn:ogc:def:crs:EPSG::3067&RangeSubset=contents&GridBaseCRS=urn:ogc:def:crs:EPSG::3067&GridType=urn:ogc:def:method:WCS:1.1:2dSimpleGrid&GridOffsets=20.0,-20.0&GridCS=urn:ogc:def:cs:OGC:0.0:Grid2dSquareCS GridCRS should be optional but in practise GeoServer seems to require it. Ari -Jukka Rahkonen- -- Sent from: http://osgeo-org.1560.x6.nabble.com/GDAL-Dev-f3742093.html ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] WCS driver
Hi Ari,
>
> I'd like to have your comment on this.
>
> Ari Jolma kirjoitti 28.10.2017 klo 17:39:
> > Reading MapServer code, it seems to be based on the idea that x,y is
> > always east,north and when it writes BoundingBox, it swaps x and y if
> > the projection is inverted (like 4326). It does not do that when it
> > writes GridCRS.
> >
> > GDAL seems to be based on the idea that x,y is what the projection
> > says (what the projection says could be found out with
> > OGRSpatialReference::GetAxis - however, for 4326 it does not say
> > anything).
Depends on how your import the CRS. If you import with importFromEPSG(), it
will strip axis
definition when they are in the unusual order. If you do importFromEPSGA(),
you'll always
get the axis definition.
(try gdalsrsinfo EPSG:4326 vs gdalsrsinfo EPSGA:4326. Same for EPSG:2393 vs
EPSGA:2393)
> > This is my impression from WCS driver - I see there's a lot
> > on this issue in the GML driver page.
>
> I think the fix depends on what's GDAL's opinion to what X,Y is. Is it
> what the projection says or is it easting,northing?
>
I guess it depends on the WCS version. According to
http://mapserver.org/development/rfc/ms-rfc-41.html , contrary to WCS 1.0, WCS
1.1 is
supposed to honour EPSG axis order, so lat,long for most/all geodetic CRS, and
easting,northing or northing,easting depending on the actual projected CRS
The "tradition" in GDAL drivers such as GML, WFS is to strip AXIS from the CRS
WKT exposed
when they are in the "annoying" lat,long and northing,easting,
>From the GML driver:
{{{
if (poSRS != NULL && m_bInvertAxisOrderIfLatLong &&
GML_IsSRSLatLongOrder(pszSRSName))
{
OGR_SRSNode *poGEOGCS = poSRS->GetAttrNode("GEOGCS");
if( poGEOGCS != NULL )
poGEOGCS->StripNodes("AXIS");
OGR_SRSNode *poPROJCS = poSRS->GetAttrNode("PROJCS");
if (poPROJCS != NULL && poSRS->EPSGTreatsAsNorthingEasting())
poPROJCS->StripNodes("AXIS");
}
}}}
and to switch the coordinates appropriately so that the user sees the "GIS
friendly" lon,lat
and x,y order. It would be propably appropriate for the WCS driver to do so as
well, as
nothing else in GDAL can deal with rasters referenced in lat,long order.
Now, you may also have to deal with implementation bugs (if what MapServer does
is indeed
a bug), which can sometimes be auto-corrected, or not...
Even
--
Spatialys - Geospatial professional services
http://www.spatialys.com
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] WCS driver
Even Rouault kirjoitti 29.10.2017 klo 11:52:
The "tradition" in GDAL drivers such as GML, WFS is to strip AXIS from
the CRS WKT exposed when they are in the "annoying" lat,long and
northing,easting,
From the GML driver:
{{{
if (poSRS != NULL && m_bInvertAxisOrderIfLatLong &&
GML_IsSRSLatLongOrder(pszSRSName))
{
OGR_SRSNode *poGEOGCS = poSRS->GetAttrNode("GEOGCS");
if( poGEOGCS != NULL )
poGEOGCS->StripNodes("AXIS");
OGR_SRSNode *poPROJCS = poSRS->GetAttrNode("PROJCS");
if (poPROJCS != NULL && poSRS->EPSGTreatsAsNorthingEasting())
poPROJCS->StripNodes("AXIS");
}
}}}
and to switch the coordinates appropriately so that the user sees the
"GIS friendly" lon,lat and x,y order. It would be propably appropriate
for the WCS driver to do so as well, as nothing else in GDAL can deal
with rasters referenced in lat,long order.
So, treat lat,lon and north,east always as exceptions. And in this case
add an option to make that exception when appropriate and when writing
the BoundingBox into the request. (But not when reading GridOrigin.
However, I still have to see what other servers say.)
Now, you may also have to deal with implementation bugs (if what
MapServer does is indeed a bug), which can sometimes be
auto-corrected, or not...
We'll see what MapServer developers say. I submitted an issue to its github.
Ari
Even
--
Spatialys - Geospatial professional services
http://www.spatialys.com
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] WCS driver
> So, treat lat,lon and north,east always as exceptions. And in this case
> add an option to make that exception when appropriate and when writing
> the BoundingBox into the request. (But not when reading GridOrigin.
> However, I still have to see what other servers say.)
I'm not sure what you exactly mean with "option". I'd see more that as a code
branch ("if WCS >= 1.1 with SRS with unusual axis order, do axis inversion"),
rather than something user visible. Similarly to what the WMS driver does in
WMS 1.3 vs WMS 1.1
We may need to expose an advanced user option to deal with broken servers to
avoid doing axis inversion although it would be normally required.
--
Spatialys - Geospatial professional services
http://www.spatialys.com
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] WCS driver
Even Rouault kirjoitti 29.10.2017 klo 12:49:
> So, treat lat,lon and north,east always as exceptions. And in this case
> add an option to make that exception when appropriate and when writing
> the BoundingBox into the request. (But not when reading GridOrigin.
> However, I still have to see what other servers say.)
I'm not sure what you exactly mean with "option". I'd see more that as
a code branch ("if WCS >= 1.1 with SRS with unusual axis order, do
axis inversion"), rather than something user visible. Similarly to
what the WMS driver does in WMS 1.3 vs WMS 1.1
We may need to expose an advanced user option to deal with broken
servers to avoid doing axis inversion although it would be normally
required.
Yes, sure. It should be the expected behavior.
Ari
--
Spatialys - Geospatial professional services
http://www.spatialys.com
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] WCS driver
Ari Jolma kirjoitti 24.10.2017 klo 17:07: Whoa! How hard can XML be? I have a real Capabilities document (from well known company) which defines *both* default and ows namespace to http://www.opengis.net/ows/2.0. Seems that XML is actually much harder than that :) XML namespaces can be declared in any element and then they are in effect in that element and in all of its children unless they override the namespace declarations. For example Rasdaman seems to write XML like that. I'm wondering how much benefit there is from looking into the namespaces in WCS responses. Probably not much in practise. Not a lot of benefit from a lot of work if I implement those rules. Ari ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] WCS driver
On lundi 30 octobre 2017 10:54:56 CET Ari Jolma wrote: > Ari Jolma kirjoitti 24.10.2017 klo 17:07: > > Whoa! How hard can XML be? I have a real Capabilities document (from > > well known company) which defines *both* default and ows namespace to > > http://www.opengis.net/ows/2.0. > > Seems that XML is actually much harder than that :) > > XML namespaces can be declared in any element and then they are in > effect in that element and in all of its children unless they override > the namespace declarations. > > For example Rasdaman seems to write XML like that. > > I'm wondering how much benefit there is from looking into the namespaces > in WCS responses. Probably not much in practise. Not a lot of benefit > from a lot of work if I implement those rules. Yes, XML can be a pain. Did you see my past suggestion of just stripping all namespace prefixes from elements with CPLStripXMLNamespace(psRoot, NULL, TRUE) ? I don't expect namespace ambiguities in the case of decoding WCS GetCapabilities or GetCoverage responses. -- Spatialys - Geospatial professional services http://www.spatialys.com ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] WCS driver
Even Rouault kirjoitti 30.10.2017 klo 22:41: On lundi 30 octobre 2017 10:54:56 CET Ari Jolma wrote: > > XML namespaces can be declared in any element and then they are in > effect in that element and in all of its children unless they override > the namespace declarations. > Yes, XML can be a pain. Did you see my past suggestion of just stripping all namespace prefixes from elements with CPLStripXMLNamespace(psRoot, NULL, TRUE) ? Yes. I dropped the examine of namespaces from my code and use the above namespace dropper instead. If we want to support at some point namespaces later in some case, maybe a similar function that fixes namespace prefixes to something we decide would be used. I mean that after the method, we would be sure the prefixes for "http://www.opengis.net/wcs/2.0"; are "wcs" for example. One thing CPLStripXMLNamespace could perhaps do is remove the namespace definition attribute nodes from element nodes. Ari I don't expect namespace ambiguities in the case of decoding WCS GetCapabilities or GetCoverage responses. -- Spatialys - Geospatial professional services http://www.spatialys.com ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] WCS driver work
I've got very close to being able to get valid data (visual comparison in QGIS) from various server types and WCS versions. I've documented the results here: https://trac.osgeo.org/gdal/wiki/WCS%2Binteroperability It seems that I need eight option flags to cover all cases. Mostly the problems are with CRS that have inverted axis order. Also it seems to be a problem if the server or the standard does not support requesting directly tiles of specific size. It is especially a problem since GDAL fails the call if the size is not expected. The only combination that I have not yet managed to get to work is GeoServer with version 1.1 and inverted axis order. I can get a decent response but the returned geotiff has slightly wrong size (59x38 instead of 60x38). The problematic call is below[1]. Also, I have/know only a few servers and I lack some combinations; I've also found a server with a combination that I've managed to test ok, but whose behavior I can't yet explain[2]. I'm writing documentation and test code but the latter will still take some time to be ready for the trunk. The code is at https://github.com/ajolma/gdal/tree/trunk/gdal/frmts/wcs I've also made one ticket regarding port code https://trac.osgeo.org/gdal/ticket/7141 Ari [1] https://msp.smartsea.fmi.fi/geoserver/wcs?SERVICE=WCS&VERSION=1.1.0&REQUEST=GetCoverage&IDENTIFIER=smartsea%3Aeusm2016-EPSG2393&FORMAT=image%2Ftiff&BOUNDINGBOX=6620001.14539506,3199988.18514013,6670001.21326246,3279980.29051582,urn:ogc:def:crs:EPSG::2393&RangeSubset=contents&GridBaseCRS=urn:ogc:def:crs:EPSG::2393&GridCS=urn:ogc:def:cs:OGC:0.0:Grid2dSquareCS&GridType=urn:ogc:def:method:WCS:1.1:2dGridIn2dCrs&GridOrigin=6670001.21326246,3199988.18514013&GridOffsets=0,1333.20175626157,-1315.79125966838,0 [2] https://lists.osgeo.org/pipermail/mapserver-users/2017-November/080339.html ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] WCS driver work
Ari Jolma kirjoitti 14.11.2017 klo 17:41: I've got very close to being able to get valid data (visual comparison in QGIS) from various server types and WCS versions. I've documented the results here: https://trac.osgeo.org/gdal/wiki/WCS%2Binteroperability It seems that I need eight option flags to cover all cases. Mostly the problems are with CRS that have inverted axis order. Also it seems to be a problem if the server or the standard does not support requesting directly tiles of specific size. It is especially a problem since GDAL fails the call if the size is not expected. The only combination that I have not yet managed to get to work is GeoServer with version 1.1 and inverted axis order. I can get a decent response but the returned geotiff has slightly wrong size (59x38 instead of 60x38). The problematic call is below[1]. I was able to fix this by computing the pixel size a bit differently (kind of numeric problem again, since you want n pixels, the pixel size needs to be computed like you need n+0.5 pixels). Ari Also, I have/know only a few servers and I lack some combinations; I've also found a server with a combination that I've managed to test ok, but whose behavior I can't yet explain[2]. I'm writing documentation and test code but the latter will still take some time to be ready for the trunk. The code is at https://github.com/ajolma/gdal/tree/trunk/gdal/frmts/wcs I've also made one ticket regarding port code https://trac.osgeo.org/gdal/ticket/7141 Ari [1] https://msp.smartsea.fmi.fi/geoserver/wcs?SERVICE=WCS&VERSION=1.1.0&REQUEST=GetCoverage&IDENTIFIER=smartsea%3Aeusm2016-EPSG2393&FORMAT=image%2Ftiff&BOUNDINGBOX=6620001.14539506,3199988.18514013,6670001.21326246,3279980.29051582,urn:ogc:def:crs:EPSG::2393&RangeSubset=contents&GridBaseCRS=urn:ogc:def:crs:EPSG::2393&GridCS=urn:ogc:def:cs:OGC:0.0:Grid2dSquareCS&GridType=urn:ogc:def:method:WCS:1.1:2dGridIn2dCrs&GridOrigin=6670001.21326246,3199988.18514013&GridOffsets=0,1333.20175626157,-1315.79125966838,0 [2] https://lists.osgeo.org/pipermail/mapserver-users/2017-November/080339.html ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] WCS driver disk cache
Hi! Is it possible to cache server responds using WCS driver in GDAL? Like in WMS driver ... Thanks. -- Sent from: http://osgeo-org.1560.x6.nabble.com/GDAL-Dev-f3742093.html ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] wcs driver not cooperating
Hi, using gdal 1.9 (trunk) I try to read data from this service (with following configuration): http://motherlode.ucar.edu:8080/thredds/wcs/fmrc/NCEP/DGEX/Alaska_12km/NCEP-DGEX-Alaska_12km_best.ncd? Geopotential_height gdalinfo says: ERROR 1: HTTP error code : 400 ERROR 1: BBOX [-2382.54740463738,-4406.77080800545,-2358.65740463738,-4430.66080800545] minimum point larger than maximum point. gdalinfo failed - unable to open 'wcs.xml'. That seems logical The request, which is send to the server (by gdal, while calling gdalinfo) is /thredds/wcs/fmrc/NCEP/DGEX/Alaska_12km/NCEP-DGEX-Alaska_12km_best.ncd?SERVICE=WCS&VERSION=1.0.0&REQUEST=GetCoverage&COVERAGE=Geopotential_height&FORMAT=GeoTIFF&BBOX=-2382.54740463738,-4406.77080800545,-2358.65740463738,-4430.66080800545&WIDTH=2&HEIGHT=2&CRS=OGC:CRS84&time=2011-08-27T12:00:00 The bbox seems all right to me (minx,miny, maxx, maxy) So the question of mine would be: is the server configured wrong, or is that s gdal issue? Thanks for help Jachym NOTE: I have absolutely no relation to the server and I do not have single idea, what are the data about. -- Jachym Cepicky e-mail: jachym.cepicky gmail com URL: http://les-ejk.cz GPG: http://les-ejk.cz/pgp/JachymCepicky.pgp ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] WCS Driver - Wrong request when
Hi,
I've been having some issues getting the WCS driver to behave correctly.
However, I am new to GIS so it's very likely I'm doing something wrong.
When performing a request on a coverage whose CRS is EPSG:4326, if the
projWin contains a negative longitude, the driver requests instead the
coverage extent's minimum longitude. For example, when requesting projWin
[-0.15, 39.5, 0.15, 39.2], the driver instead performs a request on [-6.5 ,
39.5, 0.15, 39.33], where -6.5 is the requested coverage's minimum
longitude. I have not been able to test if this is also the case for the
other axis. It results in the following error:
ERROR 1: Returned tile does not match expected configuration.
Got 6015x163 instead of 263x163.
I've been performing my requests through Python:
target_area = [-0.15, 39.5, 0.15, 39.2]
global url, layername
ds = gdal.OpenEx(f"WCS:{url}&coverage={layername}",
open_options=["NoGridAxisSwap=TRUE"])
outfile = "outputRaster.tif"
gdal.Translate(outfile, ds, projWin=target_area)
The performed request is:
https://URL/geoserver/wcs?SERVICE=WCS&REQUEST=GetCoverage&VERSION=2.0.1&COVERAGEID=geonode__F4_2020fromASC&SUBSET=Long%28-6.37708333,0.1502403500634%29&SUBSET=Lat%2839.20020966016,39.50021936252%29&Format=image/tiff
This approach works when target_area does not contain a negative longitude,
like for projWin [0.1, 39.5, 0.4, 39.2]
Is there something wrong with this approach? What would the correct way to
request this area be?
Thanks,
Alberto Paradís
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] wcs driver not cooperating
Le vendredi 19 août 2011 23:46:16, Jachym Cepicky a écrit : Looks like you are running into http://trac.osgeo.org/gdal/ticket/4118 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] WCS driver, GetSubdatasets (Python) returns empty list
Hi,
using Python, gdal 1.8.0, Ubuntu
I need to access some Temporal information about available WCS layer
http://www.gdal.org/frmt_wcs.html says at the end, that
"Each time position available for the coverage will be treated as a subdataset."
I have following service description file (with service, I need to deal with):
http://briseide01.ingr.briseide.eu:8080/geoserver/ows?
20101012T210222_pig
5000
The DescribeCoveridge request seems to be passed correctly, the file
is "extended" with aditional informations, among others it has
2010-10-17T00:00:00.000Z
2010-10-17T01:00:00.000Z
2010-10-17T02:00:00.000Z
2010-10-17T03:00:00.000Z
2010-10-17T04:00:00.000Z
in it
So, I would assume, there is Temporal dimension available in the WCS dataset.
In my Python code, I approach:
from osgeo import gdal
ds = gdal.Open("the_wcs_def_file.xml")
ds.GetMetadata()
# returns empty list
ds.GetSubDatasets()
# returns empty list
So, my question would be: how to access the temporal information from
WCS dataset, using Python, according to WCS format description
(http://www.gdal.org/frmt_wcs.html)?
Thanks
Jachym
P.S. Congrats, Frank! Good luck in your new job.
--
Jachym Cepicky
e-mail: jachym.cepicky gmail com
URL: http://les-ejk.cz
GPG: http://les-ejk.cz/pgp/JachymCepicky.pgp
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] WCS driver, GetSubdatasets (Python) returns empty list
Le dimanche 26 juin 2011 00:03:55, Jachym Cepicky a écrit : > Hi, > > using Python, gdal 1.8.0, Ubuntu > > I need to access some Temporal information about available WCS layer Jachym, Frank has added support for WCS temporal information in GDAL trunk just a few days ago. So it is not available in GDAL 1.8.0 (I've just updated the doc to mention that) With a GDAL build from trunk, gdalinfo shows this : Driver: WCS/OGC Web Coverage Service Files: time.xml Size is 645, 585 Coordinate System is: PROJCS["GGRS87 / Greek Grid", GEOGCS["GGRS87", DATUM["Greek_Geodetic_Reference_System_1987", SPHEROID["GRS 1980",6378137,298.257222101, AUTHORITY["EPSG","7019"]], TOWGS84[-199.87,74.79,246.62,0,0,0,0], AUTHORITY["EPSG","6121"]], PRIMEM["Greenwich",0, AUTHORITY["EPSG","8901"]], UNIT["degree",0.0174532925199433, AUTHORITY["EPSG","9122"]], AUTHORITY["EPSG","4121"]], UNIT["metre",1, AUTHORITY["EPSG","9001"]], PROJECTION["Transverse_Mercator"], PARAMETER["latitude_of_origin",0], PARAMETER["central_meridian",24], PARAMETER["scale_factor",0.9996], PARAMETER["false_easting",50], PARAMETER["false_northing",0], AUTHORITY["EPSG","2100"], AXIS["Easting",EAST], AXIS["Northing",NORTH]] Origin = (409900.000,4503200.000) Pixel Size = (20.000,-20.000) Metadata: TIME_POSITION=2010-10-17T04:00:00.000Z Subdatasets: SUBDATASET_1_NAME=WCS_SDS:time="2010-10-17T00:00:00.000Z",time.xml SUBDATASET_1_DESC=Coverage 20101012T210222_pig at time 2010-10-17T00:00:00.000Z SUBDATASET_2_NAME=WCS_SDS:time="2010-10-17T01:00:00.000Z",time.xml SUBDATASET_2_DESC=Coverage 20101012T210222_pig at time 2010-10-17T01:00:00.000Z SUBDATASET_3_NAME=WCS_SDS:time="2010-10-17T02:00:00.000Z",time.xml SUBDATASET_3_DESC=Coverage 20101012T210222_pig at time 2010-10-17T02:00:00.000Z SUBDATASET_4_NAME=WCS_SDS:time="2010-10-17T03:00:00.000Z",time.xml SUBDATASET_4_DESC=Coverage 20101012T210222_pig at time 2010-10-17T03:00:00.000Z SUBDATASET_5_NAME=WCS_SDS:time="2010-10-17T04:00:00.000Z",time.xml SUBDATASET_5_DESC=Coverage 20101012T210222_pig at time 2010-10-17T04:00:00.000Z Corner Coordinates: Upper Left ( 409900.000, 4503200.000) ( 22d56' 2.07"E, 40d40'29.14"N) Lower Left ( 409900.000, 4491500.000) ( 22d56' 8.10"E, 40d34' 9.76"N) Upper Right ( 422800.000, 4503200.000) ( 23d 5'11.49"E, 40d40'33.86"N) Lower Right ( 422800.000, 4491500.000) ( 23d 5'16.66"E, 40d34'14.45"N) Center ( 416350.000, 4497350.000) ( 23d 0'39.58"E, 40d37'21.89"N) Band 1 Block=645x585 Type=Float64, ColorInterp=Undefined So your best luck is to checkout svn trunk and build by yourself ;-) Best regards, Even ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] WCS driver, GetSubdatasets (Python) returns empty list
Evan, thanks for answer it works!! Thanks Jachym 2011/6/26 Even Rouault : > Le dimanche 26 juin 2011 00:03:55, Jachym Cepicky a écrit : >> Hi, >> >> using Python, gdal 1.8.0, Ubuntu >> >> I need to access some Temporal information about available WCS layer > > Jachym, > > Frank has added support for WCS temporal information in GDAL trunk just a few > days ago. So it is not available in GDAL 1.8.0 (I've just updated the doc to > mention that) > > With a GDAL build from trunk, gdalinfo shows this : > > Driver: WCS/OGC Web Coverage Service > Files: time.xml > Size is 645, 585 > Coordinate System is: > PROJCS["GGRS87 / Greek Grid", > GEOGCS["GGRS87", > DATUM["Greek_Geodetic_Reference_System_1987", > SPHEROID["GRS 1980",6378137,298.257222101, > AUTHORITY["EPSG","7019"]], > TOWGS84[-199.87,74.79,246.62,0,0,0,0], > AUTHORITY["EPSG","6121"]], > PRIMEM["Greenwich",0, > AUTHORITY["EPSG","8901"]], > UNIT["degree",0.0174532925199433, > AUTHORITY["EPSG","9122"]], > AUTHORITY["EPSG","4121"]], > UNIT["metre",1, > AUTHORITY["EPSG","9001"]], > PROJECTION["Transverse_Mercator"], > PARAMETER["latitude_of_origin",0], > PARAMETER["central_meridian",24], > PARAMETER["scale_factor",0.9996], > PARAMETER["false_easting",50], > PARAMETER["false_northing",0], > AUTHORITY["EPSG","2100"], > AXIS["Easting",EAST], > AXIS["Northing",NORTH]] > Origin = (409900.000,4503200.000) > Pixel Size = (20.000,-20.000) > Metadata: > TIME_POSITION=2010-10-17T04:00:00.000Z > Subdatasets: > SUBDATASET_1_NAME=WCS_SDS:time="2010-10-17T00:00:00.000Z",time.xml > SUBDATASET_1_DESC=Coverage 20101012T210222_pig at time > 2010-10-17T00:00:00.000Z > SUBDATASET_2_NAME=WCS_SDS:time="2010-10-17T01:00:00.000Z",time.xml > SUBDATASET_2_DESC=Coverage 20101012T210222_pig at time > 2010-10-17T01:00:00.000Z > SUBDATASET_3_NAME=WCS_SDS:time="2010-10-17T02:00:00.000Z",time.xml > SUBDATASET_3_DESC=Coverage 20101012T210222_pig at time > 2010-10-17T02:00:00.000Z > SUBDATASET_4_NAME=WCS_SDS:time="2010-10-17T03:00:00.000Z",time.xml > SUBDATASET_4_DESC=Coverage 20101012T210222_pig at time > 2010-10-17T03:00:00.000Z > SUBDATASET_5_NAME=WCS_SDS:time="2010-10-17T04:00:00.000Z",time.xml > SUBDATASET_5_DESC=Coverage 20101012T210222_pig at time > 2010-10-17T04:00:00.000Z > Corner Coordinates: > Upper Left ( 409900.000, 4503200.000) ( 22d56' 2.07"E, 40d40'29.14"N) > Lower Left ( 409900.000, 4491500.000) ( 22d56' 8.10"E, 40d34' 9.76"N) > Upper Right ( 422800.000, 4503200.000) ( 23d 5'11.49"E, 40d40'33.86"N) > Lower Right ( 422800.000, 4491500.000) ( 23d 5'16.66"E, 40d34'14.45"N) > Center ( 416350.000, 4497350.000) ( 23d 0'39.58"E, 40d37'21.89"N) > Band 1 Block=645x585 Type=Float64, ColorInterp=Undefined > > So your best luck is to checkout svn trunk and build by yourself ;-) > > Best regards, > > Even > -- Jachym Cepicky e-mail: jachym.cepicky gmail com URL: http://les-ejk.cz GPG: http://les-ejk.cz/pgp/JachymCepicky.pgp ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] WCS driver, GetSubdatasets (Python) returns empty list
Hi list, on that occasion it may be noteworthy that OGC is about to publish a Request for Comments (RFC) on the 10-140 OGC Web Coverage Service - Earth Observation Application Profile nicknamed EO-WCS. This specification, which has been tasked by ESA, specializes WCS for use in remote sensing. An open source reference implementation of EO-WCS is available with EOxServer, see www.eoxserver.org. Among other features, it provides a tight integration with MapServer and GDAL. Thought this might be of interest to the list. -Peter On 06/26/2011 12:25 AM, Even Rouault wrote: Le dimanche 26 juin 2011 00:03:55, Jachym Cepicky a écrit : Hi, using Python, gdal 1.8.0, Ubuntu I need to access some Temporal information about available WCS layer Jachym, Frank has added support for WCS temporal information in GDAL trunk just a few days ago. So it is not available in GDAL 1.8.0 (I've just updated the doc to mention that) With a GDAL build from trunk, gdalinfo shows this : Driver: WCS/OGC Web Coverage Service Files: time.xml Size is 645, 585 Coordinate System is: PROJCS["GGRS87 / Greek Grid", GEOGCS["GGRS87", DATUM["Greek_Geodetic_Reference_System_1987", SPHEROID["GRS 1980",6378137,298.257222101, AUTHORITY["EPSG","7019"]], TOWGS84[-199.87,74.79,246.62,0,0,0,0], AUTHORITY["EPSG","6121"]], PRIMEM["Greenwich",0, AUTHORITY["EPSG","8901"]], UNIT["degree",0.0174532925199433, AUTHORITY["EPSG","9122"]], AUTHORITY["EPSG","4121"]], UNIT["metre",1, AUTHORITY["EPSG","9001"]], PROJECTION["Transverse_Mercator"], PARAMETER["latitude_of_origin",0], PARAMETER["central_meridian",24], PARAMETER["scale_factor",0.9996], PARAMETER["false_easting",50], PARAMETER["false_northing",0], AUTHORITY["EPSG","2100"], AXIS["Easting",EAST], AXIS["Northing",NORTH]] Origin = (409900.000,4503200.000) Pixel Size = (20.000,-20.000) Metadata: TIME_POSITION=2010-10-17T04:00:00.000Z Subdatasets: SUBDATASET_1_NAME=WCS_SDS:time="2010-10-17T00:00:00.000Z",time.xml SUBDATASET_1_DESC=Coverage 20101012T210222_pig at time 2010-10-17T00:00:00.000Z SUBDATASET_2_NAME=WCS_SDS:time="2010-10-17T01:00:00.000Z",time.xml SUBDATASET_2_DESC=Coverage 20101012T210222_pig at time 2010-10-17T01:00:00.000Z SUBDATASET_3_NAME=WCS_SDS:time="2010-10-17T02:00:00.000Z",time.xml SUBDATASET_3_DESC=Coverage 20101012T210222_pig at time 2010-10-17T02:00:00.000Z SUBDATASET_4_NAME=WCS_SDS:time="2010-10-17T03:00:00.000Z",time.xml SUBDATASET_4_DESC=Coverage 20101012T210222_pig at time 2010-10-17T03:00:00.000Z SUBDATASET_5_NAME=WCS_SDS:time="2010-10-17T04:00:00.000Z",time.xml SUBDATASET_5_DESC=Coverage 20101012T210222_pig at time 2010-10-17T04:00:00.000Z Corner Coordinates: Upper Left ( 409900.000, 4503200.000) ( 22d56' 2.07"E, 40d40'29.14"N) Lower Left ( 409900.000, 4491500.000) ( 22d56' 8.10"E, 40d34' 9.76"N) Upper Right ( 422800.000, 4503200.000) ( 23d 5'11.49"E, 40d40'33.86"N) Lower Right ( 422800.000, 4491500.000) ( 23d 5'16.66"E, 40d34'14.45"N) Center ( 416350.000, 4497350.000) ( 23d 0'39.58"E, 40d37'21.89"N) Band 1 Block=645x585 Type=Float64, ColorInterp=Undefined So your best luck is to checkout svn trunk and build by yourself ;-) Best regards, Even ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev -- Dr. Peter Baumann - Professor of Computer Science, Jacobs University Bremen www.faculty.jacobs-university.de/pbaumann mail: p.baum...@jacobs-university.de tel: +49-421-200-3178, fax: +49-421-200-493178 - Executive Director, rasdaman GmbH Bremen (HRB 26793) www.rasdaman.com, mail: baum...@rasdaman.com tel: 0800-rasdaman, fax: 0800-rasdafax, mobile: +49-173-5837882 "Si forte in alienas manus oberraverit hec peregrina epistola incertis ventis dimissa, sed Deo commendata, precamur ut ei reddatur cui soli destinata, nec preripiat quisquam non sibi parata." (mail disclaimer, AD 1083) ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
