Ticket #542 (closed defect: wontfix)

Opened 3 years ago

Last modified 18 months ago

[raster] raster2pgsql.py should not set regular_blocking to true when wildcard are used to load many rasters

Reported by: pracine Owned by: pracine
Priority: high Milestone: PostGIS 2.0.0
Component: raster Version: trunk
Keywords: Cc: mloskot

Description

wildcard allow us to load many rasters and it is very usefull to be able to use them with the "-k 100x100" option but there is no garantee that those many rasters will result in a coverage following rules 3 and 5 of regular blocking:

3) The top left block must start at the top left corner of the extent.

5) The extent field must be a simple rectangle (non-rotated).

It might be very difficult to verify those conditions so it might be better to set regular_blocking to FALSE when using wild card.

I saw that it is also impossible to use -k when two -r options are used. Again the rule should be that we can use -k but because there is many rasters we can not assume they will end up in a coverage following regular_blocking.

Change History

Changed 3 years ago by pracine

  • milestone changed from WKTRaster 0.1.6 to PostGIS 2.0.0

Changed 3 years ago by pracine

  • summary changed from [wktraster] gdal2wktraster.py should not set regular_blocking to true when wildcard are used to load many rasters to [raster] gdal2wktraster.py should not set regular_blocking to true when wildcard are used to load many rasters

Changed 2 years ago by pracine

-Same problem when we use the -a option to append tiles to an existing table.

Changed 2 years ago by robe

  • summary changed from [raster] gdal2wktraster.py should not set regular_blocking to true when wildcard are used to load many rasters to [raster] raster2pgsql.py should not set regular_blocking to true when wildcard are used to load many rasters

Changed 22 months ago by pracine

  • owner changed from mloskot to pracine

Changed 18 months ago by dustymugs

  • status changed from new to closed
  • resolution set to wontfix

As regular_blocking is now an "informational" constraint explicitly set by the user, no reason for the software to make the decision.

Note: See TracTickets for help on using tickets.