CRS support with rasimport

[abeccati]

I just imported a dataset with rasimport on version 8.5.2 expecting it to load the EPSG code found in the GeoTIFF but I ended up with a CRS:1 coverage. I recall the functionality of automatically reading and setting the CRS from GeoTIFF was included in some earlier version so that existing CRS would be assigned, while new crs would have been loaded automatically if not present in ps_crs.

I think the functionality should already be part of the 8.5 release branch so no having it is a defect. Furthermore its quite relevant to avoid users re-coding CRS-related extraction and inserts when loading geodata. At least for 2D coverages that should be straightforward to support. I'd set it to critical since 2D geodata in such widespread format is a very fundamental ingestion to support.

[abeccati]

Assigning to Alex for joint assessment.

[Dimitar Misev]

Setting the CRS is a simple psql update, there is no need to consider this as so critical. Especially as 8.5 has been in use since August 2013 and nobody complained about this so far.

[abeccati]

I would advise against waiting too much for complaints, they might simply never come and we will still be missing a basic feature of our geo-related component. New users trying out that stable version might just be turned away by its absence (and by having to dwell into the db schema to use it), that's why it looks critical to me.

[ungarj]

Well, at least for us it made no difference with 8.5 because we were just updating existing coverages thus not recognizing this is missing.

However from a user's perspective it would be very convenient if there is a tool handling everything that can be handled (rasimport now, maybe WCS-T later) instead of having to tinker with the database manually.

Just imagine somebody wanting to quickly test rasdaman. He would install it and load some test data. The easier these steps are, the better the important first impression is.

[Alexander Herzig]

I agree, the first impression is important and I'm happy to look into it. However, I think we should postpone it until we've sorted the v9.0 release.

[abeccati]

Indeed, patch release for 8.5 should come after that, re-raising priority meantime (which is independent from 9.0 schedule)

[Marcus Sen]

I have found something similar using v9.0 RPMs. I assume it is the same issue so I am just appending the information here rather than creating a separate ticket.

When using v8.4 I could execute a command like

rasimport -coll bgs_rs -t RGBImage:RGBSet -f Landsat_ETM_321_11Sep2002.tif

and it would recognise the coordinate system of the tif and insert this in the petascope metadata tables.

With v9.0 if I execute

rasimport --coll bgs_rs -t RGBImage:RGBSet -f Landsat_ETM_321_11Sep2002.tif

I get the error message:

Couldn't find any CRS info in file metadata! Set CRS URI to:
%SECORE_URL%/crs/OGC/0/Index2D

and the Index2D crs is the one registered against the coverage in the petascope tables.

I can explicitly set the CRS with the —crs-uri option but it is a major loss of functionality not to be able to recognise the CRS information already present in the file (and recognised by gdalinfo).

[Alexander Herzig]

Prior to v9.0 rasimport just reads the ProjectionRef provided by GDAL and puts it into petascope, if not already present. There is no check as to whether this CRS description makes any sense or not. This works fine as long as the provided info is correct. From v9.0 onwards we've got CRS info referenced by URI, so just reading whatever is provided doesn't work any more. So, rasimport looks for the most high level EPSG code provided with ProjectionRef and then builds the URI based on that code, which seems to work fine. However, if there's no EPSG code given in ProjectionRef, the WKT had to be parsed to identify a suitable CRS URI. Since rasimport doesn't do that, the only option is to assign an Index2D/2D URI. I agree that that's not ideal and honestly it bothers me too, since you then always have to specify —crs-uri, which is a bit of a pain. Is anyone aware of a piece of code which parses CRS WKT to come up with an EPSG code or directly with a URI?

[Marcus Sen]

As requested on rasdaman-users list here is a gdalinfo dump of one of the files we tried importing:

Driver: GTiff/GeoTIFF
Files: Landsat_ETM_321_11Sep2002.tif
       Landsat_ETM_321_11Sep2002.tfw
       Landsat_ETM_321_11Sep2002.tif.aux.xml
Size is 9130, 8372
Coordinate System is:
PROJCS["OSGB 1936 / British National Grid",
    GEOGCS["OSGB 1936",
        DATUM["OSGB_1936",
            SPHEROID["Airy 1830",6377563.396,299.3249646000044,
                AUTHORITY["EPSG","7001"]],
            AUTHORITY["EPSG","6277"]],
        PRIMEM["Greenwich",0],
        UNIT["degree",0.0174532925199433],
        AUTHORITY["EPSG","4277"]],
    PROJECTION["Transverse_Mercator"],
    PARAMETER["latitude_of_origin",49],
    PARAMETER["central_meridian",-2],
    PARAMETER["scale_factor",0.9996012717],
    PARAMETER["false_easting",400000],
    PARAMETER["false_northing",-100000],
    UNIT["metre",1,
        AUTHORITY["EPSG","9001"]],
    AUTHORITY["EPSG","27700"]]
Origin = (314158.774125767638907,632963.644179778289981)
Pixel Size = (28.500000000000000,-28.500000000000000)
Metadata:
  AREA_OR_POINT=Area
Image Structure Metadata:
  INTERLEAVE=PIXEL
Corner Coordinates:
Upper Left  (  314158.774,  632963.644) (  3d21'42.89"W, 55d34'57.87"N)
Lower Left  (  314158.774,  394361.644) (  3d17'32.64"W, 53d26'19.59"N)
Upper Right (  574363.774,  632963.644) (  0d45'54.00"E, 55d33'32.82"N)
Lower Right (  574363.774,  394361.644) (  0d37'26.49"E, 53d25' 0.97"N)
Center      (  444261.274,  513662.644) (  1d18'58.35"W, 54d30'58.31"N)
Band 1 Block=9130x1 Type=Byte, ColorInterp=Red
  Min=0.000 Max=255.000
  Minimum=0.000, Maximum=255.000, Mean=26.170, StdDev=39.245
  Metadata:
    STATISTICS_MAXIMUM=255
    STATISTICS_MEAN=26.169896604182
    STATISTICS_MINIMUM=0
    STATISTICS_STDDEV=39.244770460374
Band 2 Block=9130x1 Type=Byte, ColorInterp=Green
  Min=0.000 Max=255.000
  Minimum=0.000, Maximum=255.000, Mean=26.343, StdDev=35.800
  Metadata:
    STATISTICS_MAXIMUM=255
    STATISTICS_MEAN=26.342840449231
    STATISTICS_MINIMUM=0
    STATISTICS_STDDEV=35.799822649416
Band 3 Block=9130x1 Type=Byte, ColorInterp=Blue
  Min=0.000 Max=255.000
  Minimum=0.000, Maximum=255.000, Mean=21.129, StdDev=32.566
  Metadata:
    STATISTICS_MAXIMUM=255
    STATISTICS_MEAN=21.129230892209
    STATISTICS_MINIMUM=0
    STATISTICS_STDDEV=32.566471974712

[Peter Baumann]

seeing no activity, closing it.