[gdal-dev] The new WCS driver

[Even Rouault]

Hi Ari,

> https://github.com/ajolma/gdal/tree/trunk/gdal/frmts/wcs
> 
> would be accepted into the GDAL trunk, thus to be included into the
> coming version 2.3.
> 
> I'm not making a PL since the GDAL at github is not a primary source.

Well, a lot of people already do pull requests. That's rather convenient to pre-test changes 
and running Travis-CI & AppVeyor on them. And also to enable other people to add review 
comments (I tried directly on your tree, but apparently I need to identify which commit has 
introduced which line to be able to comment, whereas with a pull request I believe you can 
comment on whatever changed lined)

If you work in a github tree like you did, you can even trigger Travis-CI & AppVeyor, before 
doing any pull request, by logging into them with your GH credentials and enabling your 
repo.

> There is a python test program in the above directory (it should be
> moved to autotest eventually but it's now there for easier access).
> 
> There are a couple of things that I've done:
> 
> 1) Introduced "WCS:<URL>" syntax for the driver.
> 
> 2) Introduced a cache for various XML files (GDA WCS service file, GDAL
> metadata files, server responses).
> 
> 3) Split the driver into a base class and version specific subclasses.
> 
> I have tested the driver with four real servers (ArcGIS, GeoServer,
> MapServer, and Rasdaman) and it can work with all of them in all
> versions they support. I have checked the responses (scaled and in CRS
> with inverted axis order (except ArcGIS)) in QGIS and they are ok - not
> always identical with each other but close enough. There is
> documentation and test code - Perl code to run gdal_translate calls to
> real servers and Python code to run tests against the responses obtained).
> 
> However, I assume there to be many small things in the code to
> review/change. I find the typical GDAL code often difficult to read and
> especially write. So I have written the code in a way that's easier for
> me to work with. I think there could be more strict rules for writing
> the code, and an automatic code checker (linter) would be useful.

We have already various "linting" tools that run: cppcheck, clang static analyzer, coverity scan 
and a few ad-hoc scripts in scripts/ . But indeed we don't enforce things like maximum size of 
a function, etc.

> Besides things that a linter would check, I find it useful to write and
> debug shorter functions (max a screenful), while GDAL functions tend to
> be long, which often make them hard for me to understand and follow.
> Some issues specific to this work:
> 
> - I ended up writing quite many utility functions. Some may reinvent
> some wheels.
> 
> - The initial call to the server returns a dataset with subdatasets but
> without bands. It may be that opening a subdataset returns a dataset
> without bands (there are more than 2 dimensions). Then the additional
> subdataset metadata is added to the SUBDATASETS metadata domain.
> 
> - The idea is that the service file in the cache is maintained through
> options, which is used to change values in the file. The current set of
> options is expected to grow.
> 
> - I have not tested the more exotic features of the driver - especially
> mapping the time dimension to bands etc. I hope I have not broken what
> worked before. This is an area where more work is needed.
> 
> - The code compiles and the tests run ok in a new Linux machine.
> 
> Ari
> 
> 
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev


-- 
Spatialys - Geospatial professional services
http://www.spatialys.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20171116/acc6b1ef/attachment-0001.html>