[postgis-devel] PostGIS raster feedback

[Chris Hodgson]

I have to admit that I still haven't had time or reason to have a good 
look at the raster support, either. However I do have a fair bit of 
experience with using GDAL and other tools to manipulate orthophotos.

I just want to say that I definitely agree that a GDAL write driver is 
the way to go,and then replace the python loader with a GDAL-based one 
in C. I wouldn't want to necessarily take all of the retiling/overview 
logic away from the loader (or at least the loader could call the SQL 
functions for you) because I think it may be more intuitive for most 
people when compared to existing systems... though having it all 
available through SQL to change the overview levels and tile sizes after 
the load sounds great, I think most people starting out would rather 
just give an extra parameter or two to the loader and let it do it's thing.

Cheers,
Chris

Pierre Racine wrote:
> Thanks Mark,
>
> Converting the Python loader in C would be a great improvement and, I think, a big task. We would get rid of all the Python dependencies (at least 3: python, gdal for python, numpy). Some questions you may want to answer before going too far:
>
> 1) Do we really need to write an importer from scratch? Could we rely instead on a write GDAL driver. I know the question has been asked often but now that we are dependent on GDAL anyway, we might want to reconsider the question. Maybe writing a write GDAL driver and then a small loader based on it (in order to simplify the GDAL awkward syntax) would be the best way to go. The benefit of having a GDAL write driver would be enormous. I think this is the approach we should have taken from the beginning.
>
> 2) Maybe it should not be the job of the importer to retile and/or to create overviews. We should instead develop SQL functions allowing to do those two essential things. The idea being: "import everything raw (images) and then construct something more usefull (a multiresolution, tiled coverage) from the raw material using the SQL API". The only two missing pieces for that are, I think, ST_Resample() and ST_Clip() (or an ST_Intersection(raster, geometry) -> raster equivalent to ST_Clip()) so you can cut rasters into a smaller grid (retile) or resample them into a lower resolution coverage (overviews). ST_Resample() is already on the way (Bborie) and ST_Clip() is a midterm objective. We could have facilitating functions like ST_Retile() and ST_CreateOverview() encapsulating the whole processes. Most of the complex logic in the python importer are there to accomplish those two things. Removing them would really simplify your task, that would simplify the importer GUI and force 
>  us to implement the right tools at the right location (ST_Resample() and ST_Clip()).
>
> 3) It would be nice if the importer would have the possibility to write directly to the database. Creating an intermediate SQL file for raster is cumbersome.
>
> 4) It seems to me that we should not have to use the -s option when we loading data. GDAL should help us determine the right coordinate system. We might have a message saying "the importer could not determine the coordinate system of the dataset, use the -s option to set it" or something similar. Identifying the right SRID when loading data is always the thing that slow down the whole process.
>
> 5) Thing we really want to keep are 1) the ability to load multiple rasters with one command c:/temp/*.tif 2) being able to append rasters to an existing table 3) the possibility to only register raster georeference metadata (-R).
>
> I think you could easily achieve all those things in the same amount of time as you would need to blindly rewrite the python importer without reconsidering any past choices.
>
> Pierre
>
>   
>> -----Original Message-----
>> From: postgis-devel-bounces at postgis.refractions.net [mailto:postgis-devel-
>> bounces at postgis.refractions.net] On Behalf Of Mark Cave-Ayland
>> Sent: Monday, June 20, 2011 7:22 AM
>> To: PostGIS Development Discussion
>> Subject: [postgis-devel] PostGIS raster feedback
>>
>> Hi all,
>>
>> Just an email to say that I'm currently working on a project that requires raster
>> capability and so it's the first time I've managed to take a look at the new
>> functionality.
>>
>> And I'm really impressed at the work that you guys have done so far in regard to
>> the implementation and documentation - great effort guys!
>>
>> In terms of things to do for a 2.0 release, I'd like suggest the following:
>>
>> - Review the consolidation of the raster/vector codebases. The directory
>> structure in particular looks as if it's just been dumped there, and there is some
>> work to remove excessive version numbering in autoconf/separate raster
>> versioning
>>
>> - Convert raster2pgsql.py to C with a longer-term view of integrating it into the
>> loader GUI.
>>
>> I can probably start to take a look at the C conversion if everyone agrees that
>> this is the right thing to do going forward?
>>
>>
>> ATB,
>>
>> Mark.
>>
>> --
>> Mark Cave-Ayland - Senior Technical Architect
>> PostgreSQL - PostGIS
>> Sirius Corporation plc - control through freedom
>> http://www.siriusit.co.uk
>> t: +44 870 608 0063
>>
>> Sirius Labs: http://www.siriusit.co.uk/labs
>> _______________________________________________
>> postgis-devel mailing list
>> postgis-devel at postgis.refractions.net
>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>     
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>