[gdal-dev] GDAL WKT Raster Driver weekly report #5

[Frank Warmerdam]

Jorge Arévalo wrote:
> Hello,
> 
> This is the report #5 of GDAL WKT Raster 
> driver: http://www.gis4free.org/blog/2009/06/27/gsoc-09-weekly-report-5-1906-2606/
> 
> The project can be followed 
> here: http://trac.osgeo.org/gdal/wiki/WKTRasterDriver

Jorge,

I appologise for not staying on top of my mentoring duties.  I am reviewing
the design document at:

http://www.gis4free.org/blog/wp-content/uploads/2009/06/gdal-wktrasterdriver-spec-0.2.pdf

Is this still the most current version of your design?  I see Even, Mateusz,
Pierre and others have provided some feedback.  Their comments seem good.

I would also support the suggestion to put the design in a more malliable
form, such that others can contribute more directly - such as a trac wiki
page. I also think the design needs some further updates from the 0.2
version.  I notice you have your own trac now, though it does not seem to
have any public access which I think is unfortunate. Don't hesitate to keep
the design in the GDAL trac.

I would like design to better address the relationship between WKTRaster's
data model and the GDAL data model.  So, for instance, you might note things
like:

1) The fPixelSizeX, fPixelSizeY, fUpperLeftX, fUpperLeftY, fRotationX,
fRotationY values will become the GeoTransform in GDAL, possibly noting
how the transformation will take place.   Actually, the f* fields I note
are actually on a single WKTRaster objects after fetching and instead
you really need to populate the Geotransform based on the extent, pixelsize_x
and pixelsize_y fields from the RASTER_COLUMNS table and that
for now only north up images will be supported (unrotated).

2) Note that WKTRaster uses an SRID lookup into the spatial_ref_sys which
may contain WKT and PROJ.4 representations of a coordinate system, but
that GDAL needs WKT.  Note perhaps that the spatial_ref_sys lookup code
from the OGR PG driver can be used essentially unchanged, and that things
only get messy when there is a need to create new rasters as it is sometimes
hard to establish what SRID to use for a given WKT (or whether to create a
new one), but that this matter can also be done using the same approach as
the OGR PG driver.

--

In general I was surprised to find no mention of the RASTER_COLUMNS table
and the implications for the WKTRaster driver.  To a significant extent
this table was defined to make it easier to write the WKTRaster driver.
It encapsulates a concept of simplistic rasters that can be easily mapped
onto the GDAL data model and that can be efficiently manipulated by GDAL.

I would like the design talk about steps in implementation.  The first
complete step should be a read-only driver that supports
"regular_blocking" type images defined via RASTER_COLUMNS.   I would
hope this would be accomplished by the mid-term review.

After that some additions you could work on are:

  1) Supporting rasters that are not "regular_blocking".  I think it will
     be hard to make this really efficient, but it is definately doable.

  2) Support in place update for existing rasters.

  3) Support creating new rasters.

  4) Support access to overviews.

  5) Support "outdb" rasters.

I would like a sense of which of these you hope to do this summer,
in what order, and what you see as the issues with them.

I would personally be quite happy if you did a bulletproof and efficient
implementation of read-only access to WKTRasters with overviews and
all applicable metadata and access to "outdb" rasters.

Make sure the project plan includes time to extend the python test suite
with tests for the WKTRaster driver, and to write up user driver
documentation.


-- 
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | Geospatial Programmer for Rent