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

2009-06-29 Thread 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, warmer...@pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush| Geospatial Programmer for Rent

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev


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

2009-06-29 Thread Jorge Arévalo
Hello Frank,

2009/6/30 Frank Warmerdam warmer...@pobox.com

 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.


Don't worry. As you said, this is not the current version. Even, Mateusz,
Tamas... and myself, have commented a lot of things that must be added.




 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.


OK. I'll use the GDAL trac to create a web version with more information.



 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.


Understood. Since now, I'm working on an extended version of the document
(1.0 this time), describing more in detail all the work,  including your
comments, and any other information that can be useful.

Many thanks for your comments, I'll keep you (and the list) informed.

Best regards
Jorge



 --

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


___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev