[gdal-dev] WCS driver
Peter Baumann
p.baumann at jacobs-university.de
Fri Oct 27 09:41:23 PDT 2017
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 at 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.baumann at jacobs-university.de
tel: +49-421-200-3178, fax: +49-421-200-493178
- Executive Director, rasdaman GmbH Bremen (HRB 26793)
www.rasdaman.com, mail: baumann at 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)
More information about the gdal-dev
mailing list