Changes between Version 4 and Version 5 of WKTRaster/SpecificationWorking01

Timestamp:

Apr 16, 2009, 7:47:18 AM (15 years ago)

Author:

pracine

Comment:

—

WKTRaster/SpecificationWorking01

@@ -258 +258 @@
 
 This section is dedicated to discussion that took place during the [http://wiki.osgeo.org/wiki/Toronto_Code_Sprint_2009 Toronto Code Sprint 2009].[[BR]][[BR]]
- 1. Bug tracking - Launch separate Google project or join PostGIS bug tracker, as a module? Answer: We will track our bug in the PostGIS Google Code project. PostGIS plan on moving (back) to Trac soon.[[BR]][[BR]]
- 1. Wiki: is there a chance to have a better wiki for documentation, schedule, specs, road map, users inputs? Actual PostGIS wiki limitations: security, no images, no tables (or sophisticated page structure) (For this Leo and Regina are drafting up a PSC and then once we have a PSC we'll vote to locate on OSGEO.  Main issue is Refractions server is kind of old)[[BR]][[BR]]
+ 1. '''Bug tracking -''' Launch separate Google project or join PostGIS bug tracker, as a module? Answer: We will track our bug in the PostGIS Google Code project. PostGIS plan on moving (back) to Trac soon.[[BR]][[BR]]
+ 1. '''Wiki:''' is there a chance to have a better wiki for documentation, schedule, specs, road map, users inputs? Actual PostGIS wiki limitations: security, no images, no tables (or sophisticated page structure) (For this Leo and Regina are drafting up a PSC and then once we have a PSC we'll vote to locate on OSGEO.  Main issue is Refractions server is kind of old)[[BR]][[BR]]
   a. Is Google Code Wiki well working?[[BR]][[BR]](remember export issues with Google code - see gvSIG - Cuba)[[BR]][[BR]]
- 1. Windows build. What is the plan?[[BR]][[BR]]
+ 1. '''Windows build.''' What is the plan?[[BR]][[BR]]
   a. First step is to review Windows/Visual C++ native build configuration for PostGIS. ML: I will try to investigate and solve outstanding issues like PGXS makefiles generation, soon.[[BR]][[BR]]
   a. ML: Prefer native build toolsets on supported platform (Windows/Visual C++, GCC/Linux, etc.). On Windows, avoid Cygwin, MinGW, wherever possible. Issue directly related to point a).[[BR]][[BR]]
   a. Is cmake a possibility?[[BR]][[BR]]
- 1. GiST indexing: is wrapping PostGIS Gist function in plpgslq sufficient? From Paul comments it seems actually that cast are sufficients.[[BR]][[BR]]
- 1. API: Any other SQL raster function you would like to see?[[BR]][[BR]]
+ 1. '''GiST indexing:''' is wrapping PostGIS Gist function in plpgslq sufficient? From Paul comments it seems actually that cast are sufficients.[[BR]][[BR]]
+ 1. '''API:''' Any other SQL raster function you would like to see?[[BR]][[BR]]
   a. ML: RT_AsJPEG - What JPEG implementation to use?[[BR]][[BR]]
   a. ML: RT_AsTIFF - Do we aim to depend on libgeotiff?[[BR]][[BR]]
   a. ML: Is there any function that would require/fit GDAL dependency?[[BR]][[BR]]
   a. Pierre: We should maybe investigate the cost of using GDAL and have a general RT_AsImage(format, params) instead of using the individual tiff, jpeg and png libraries. Those will anyway also have a cost I guess... And we will probably have to link with GDAL for AsPolygon(rast) and AsRaster(geom) anyway.[[BR]][[BR]]
- 1. Implementing raster -> vector conversion for intersections(). How to do it? Possible using only plpgsql? So we don't have to link with liblwgeos and we can have our own release schedule.
+ 1. '''Implementing raster -> vector conversion for intersections().''' How to do it? Possible using only plpgsql? So we don't have to link with liblwgeos and we can have our own release schedule.
    * polygonize with GDAL or GRASS, that generates some internal structure for those libraries, and you turn that into a WKT form of polygon. That can be passed to PostGIS, and you don't need to link to liblwgeom.[[BR]][[BR]]
- 1. Best practice for band referencing: having a band parameter (index?) or always use RT_Band()[[BR]][[BR]]-e.g. SELECT RT_AsTIFF(RT_Band(raster,2),60) FROM coverandtemp[[BR]][[BR]]SELECT RT_AsTIFF(RT_Band(raster,2),RT_Band(raster,1),60) FROM coverandtemp[[BR]]or[[BR]]SELECT RT_AsTIFF(raster,2,60) FROM coverandtemp[[BR]][[BR]]Pierre: Having a band parameter (or a list of band) for each function trying to access a band would be preferable to avoid useless memcopy of band data.[[BR]][[BR]]
- 1. Architecture & design issues:[[BR]][[BR]]
+ 1. '''Best practice for band referencing:''' having a band parameter (index?) or always use RT_Band()[[BR]][[BR]]-e.g. SELECT RT_AsTIFF(RT_Band(raster,2),60) FROM coverandtemp[[BR]][[BR]]SELECT RT_AsTIFF(RT_Band(raster,2),RT_Band(raster,1),60) FROM coverandtemp[[BR]]or[[BR]]SELECT RT_AsTIFF(raster,2,60) FROM coverandtemp[[BR]][[BR]]Pierre: Having a band parameter (or a list of band) for each function trying to access a band would be preferable to avoid useless memcopy of band data.[[BR]][[BR]]
+ 1. '''Architecture & design issues:'''[[BR]][[BR]]
    * How to handle no NODATA? Pierre from Frank input: We'll need a HasNoDataValue flag for each band.[[BR]][[BR]]
- 1. Documentation[[BR]][[BR]]
+ 1. '''Documentation'''[[BR]][[BR]]
    * Setup a structure (likely on a Wiki), sections for developers and for users[[BR]][[BR]]
    * Update existing documents like RFCs - they are out of date.[[BR]][[BR]]
    * Describe key terms: canonical format, serialized format, transfer format (WKB), in-db raster, out-db raster, etc. This should help people to grasp the WKT Raster key elements quickly, and help them to decide which document/RFC to read in details.[[BR]][[BR]]
- 1. Development Roadmap[[BR]][[BR]]
+ 1. '''Development Roadmap'''[[BR]][[BR]]
    * Review current schedule.
    * Add note on a website where users should (or should not) expect 1 release - clear statement.