rasgeo imports MDD with wrong spatial domain if nm_meta not present

[Dimitar Misev]

Importing two images from a directory (using the -d option), seems to mess up the X dimension (and also the Y doesn't seem right).

I believe this was working fine before the 0.5 patch. I looked at the patch but can't figure out what could be the problem. Any ideas Alex?

$ rasql -q 'select sdom(c) from pan as c' --out string
rasql: rasdaman query tool v1.0, rasdaman v8 -- generated on 01.03.2012 22:47:21.
opening database RASBASE at localhost:7001...ok
Executing retrieval query...ok
Query result collection has 1 element(s):
  Result element 1: [-2147483648:12318,-2147483648:14552]
rasql done.

file 1:

Driver: GTiff/GeoTIFF
Size is 12319, 14553
Coordinate System is:
PROJCS["unnamed",
    GEOGCS["GRS 1980(IUGG, 1980)",
        DATUM["unknown",
            SPHEROID["GRS80",6378137,298.257222101]],
        PRIMEM["Greenwich",0],
        UNIT["degree",0.0174532925199433]],
    PROJECTION["Lambert_Azimuthal_Equal_Area"],
    PARAMETER["latitude_of_center",52],
    PARAMETER["longitude_of_center",10],
    PARAMETER["false_easting",4321000],
    PARAMETER["false_northing",3210000],
    UNIT["metre",1,
        AUTHORITY["EPSG","9001"]]]
Origin = (4278064.000000000000000,1995080.000000000000000)
Pixel Size = (1.000000000000000,-1.000000000000000)
Metadata:
  AREA_OR_POINT=Area
Image Structure Metadata:
  INTERLEAVE=BAND
Corner Coordinates:
Upper Left  ( 4278064.000, 1995080.000) (  9d29'29.33"E, 41d 3'13.98"N)
Lower Left  ( 4278064.000, 1980527.000) (  9d29'33.16"E, 40d55'20.15"N)
Upper Right ( 4290383.000, 1995080.000) (  9d38'14.57"E, 41d 3'16.29"N)
Lower Right ( 4290383.000, 1980527.000) (  9d38'17.30"E, 40d55'22.45"N)
Center      ( 4284223.500, 1987803.500) (  9d33'53.59"E, 40d59'18.32"N)
Band 1 Block=12319x1 Type=UInt16, ColorInterp=Gray
  Overviews: 6160x7277, 3080x3639, 1540x1820, 770x910, 385x455, 193x228

file 2:

Driver: GTiff/GeoTIFF
Size is 12704, 14958
Coordinate System is:
PROJCS["unnamed",
    GEOGCS["GRS 1980(IUGG, 1980)",
        DATUM["unknown",
            SPHEROID["GRS80",6378137,298.257222101]],
        PRIMEM["Greenwich",0],
        UNIT["degree",0.0174532925199433]],
    PROJECTION["Lambert_Azimuthal_Equal_Area"],
    PARAMETER["latitude_of_center",52],
    PARAMETER["longitude_of_center",10],
    PARAMETER["false_easting",4321000],
    PARAMETER["false_northing",3210000],
    UNIT["metre",1,
        AUTHORITY["EPSG","9001"]]]
Origin = (4840632.000000000000000,2274320.000000000000000)
Pixel Size = (1.000000000000000,-1.000000000000000)
Metadata:
  AREA_OR_POINT=Area
Image Structure Metadata:
  INTERLEAVE=BAND
Corner Coordinates:
Upper Left  ( 4840632.000, 2274320.000) ( 16d24'13.58"E, 43d22'39.24"N)
Lower Left  ( 4840632.000, 2259362.000) ( 16d23'20.64"E, 43d14'35.23"N)
Upper Right ( 4853336.000, 2274320.000) ( 16d33'34.81"E, 43d22'3.65"N)
Lower Right ( 4853336.000, 2259362.000) ( 16d32'40.60"E, 43d13'59.73"N)
Center      ( 4846984.000, 2266841.000) ( 16d28'27.39"E, 43d18'19.58"N)
Band 1 Block=12704x1 Type=UInt16, ColorInterp=Gray
  Overviews: 6352x7479, 3176x3740, 1588x1870, 794x935, 397x468, 199x234

[Dimitar Misev]

Ok after enabling debug, I realized I've forgotten to initialize nm_meta.

I think rasgeo should throw an error when nm_meta is not found and -d is used.

[beccati@…]

Hi,
I got the same issue but with nm_meta initialised but I am currently unable to reproduce it systematically.

It happened while loading several images into different collection, it would appear that the first collection had the lower bounds of x and y axes set to "-2147483648" while the other collections were loaded correctly.

Deleting the collections and repeating the ingestion process with the same data led to a correct load of the spatial domain for all collections.

May it be some uninitialized variable/pointer that causes the issue on a "first use" basis?
Alan

[abeccati]

Changed to sanity check inclusion then, further tests for stability can come later on if still needed. With the upcoming version 9, contents of the the nm_meta table should be directly included into the petascope tables, hence that won't apply to that version.

[Dimitar Misev]

Doesn't seem like it will get fixed, in 9.0 it will be gone anyway.