SECORE support proj4 to support transformation to customized CRS

[Piero Campalani]

Petascope should not pass the URI as crs parameter of the [RasqlEncodeFunction encode] function of RasQL since only opengis ones are recognized.

I suggest that Petascope sets the crs in EPSG:CODE format. Non-EPSG ones will not be embedded in the file anyway.

Alternatively, Petascope would personally fetch the definition and translate it to PROJ4 or WKT format, and pass it on to the encode function: this would be the ultimate solution to deliver proper CRS information for any CRS. This involves time CRS too.

$ rasql -q 'select encode( c, "GTiff", "xmin=111.975;ymin=-44.525;xmax=156.275;ymax=-8.975;crs=kahlua.eecs.jacobs-university.de:8080/def/crs/EPSG/0/4326" ) from mean_summer_airtemp as c' --out file
$ gdalinfo rasql_1.tif
[...] Coordinate System is `'

$ rasql -q 'select encode( c, "GTiff", "xmin=111.975;ymin=-44.525;xmax=156.275;ymax=-8.975;crs=http://www.opengis.net/def/crs/EPSG/0/4326" ) from mean_summer_airtemp as c' --out file
$ gdalinfo rasql_1.tif
Coordinate System is:
[...] GEOGCS["WGS 84", [...]

[Dimitar Misev]

You think GML → WKT would be a lot of effort?

[Dimitar Misev]

​http://confluence.highsource.org/display/OGCS/GML+Parser+for+Java

Something like this could be implemented in secore, so that with '&format=wkt' we could get WKT definition.

[Piero Campalani]

If SECORE could pass WKT directly, that would be the cleanest solution probably (see also #367).

(I'll reassign this to you now)

[Peter Baumann]

EPSG:xxx is not possible, since the CRS may well be non-EPSG. Also, any interpretation of the URI is not kosher - encode() must always deliver the "truth", ie: the information without modification. If users want to be compatible they need to indicate a proper code.

[Dimitar Misev]

I think you misunderstood the ticket, we are aiming for the 'alternative', i.e. to provide the WKT definition (which should allow any CRS) to GDAL. But someone should implement a GML → WKT translation..

[Peter Baumann]

hm, I don't see this as the task of rasdaman. It is about servig rasters, not translating CRS representations.

[Dimitar Misev]

I think it's desirable that the output rasters have proper geo-referencing information in their metadata?

[Peter Baumann]

maybe I am missing something indeed, let's discuss again f2f.

[Peter Baumann]

still not sure I understand correctly. Is it

• support for WKT in srsName? This is violating the OGC standard, so I couldn't see why we should want to do that. Is there a use case?
• Is it about internal evaluation, ie: receiving a CRL URL and turn it into an actionable definition that GDAL can digest? This I could understand right away, but the CRS URL would need to be retained for later delivery.

[Dimitar Misev]

This one yes, GDAL doesn't understand GML definitions unfortunately.
Replying to pbaumann:

• Is it about internal evaluation, ie: receiving a CRL URL and turn it into an actionable definition that GDAL can digest? This I could understand right away, but the CRS URL would need to be retained for later delivery.

[Bang Pham Huu]

I've spared sometimes to find a reasonable solution for this problem. Unfortunately, the tool that Dimitar hoped will not appear soon (as GML is not what gdal wanted to use for projection) . I'd like to propose my idea:
+ I agree with Prof. Peter, the translation from EPSG GML to WKT is not what SECORE need to concern.
+ However, if we don't support for SECORE to have a feature to resolve in WKT, then it will lead to no georeferenced metadata (here is a problem from PS-2 CRSs ​http://rasdaman.org/ticket/1457).

In short words, I think CRS extension only can transform from existing CRSs supported by GDAL (e.g: EPSG:4326 - EPSG:32633, but not from user defined CRS, EPSG:4326 - FICTION:4326_upgraded (FICTION:4326_upgraded is a copy of EPSG:4326 with only change a value of angle from UNIT["degree",0.0174532925199433], to UNIT["degree",0.0274532925199433]).

As you can see, gdal already stores the wkt of all the supported EPSG:Crss so we don't need to provide wkt as input parameter. However, if someone can understand and can create/modify an existing CRS, we can assume he can create +proj4 definition for this CRS as well (he should be a geologist and can do like this ​https://docs.qgis.org/2.2/en/docs/user_manual/working_with_projections/working_with_projections.html#custom-coordinate-reference-system)

so what need to be discussed here is how to allow to add +proj4 manually in SECORE (proj4 is likable as it is short and straightforward), then in Petascope it can just add these parameters to encode().

EPSG:4326

proj4:
"+proj=longlat +datum=WGS84 +no_defs"

WKT:
GEOGCS["WGS 84",DATUM["WGS_1984",SPHEROID["WGS 84",
6378137,298.257223563,AUTHORITY["EPSG","7030"]],
TOWGS84[0,0,0,0,0,0,0],AUTHORITY["EPSG","6326"]],
PRIMEM["Greenwich",0,AUTHORITY["EPSG","8901"]],
UNIT["degree",0.0174532925199433,AUTHORITY["EPSG","9108"]],
AUTHORITY["EPSG","4326"]]

If gdal/geotool or some library can convert GML (validated by GML 3.2.1 schema) to proj4 then we just don't ask user to add the proj4 when he creates/updates definition anymore, but it is of course not what can be happened soon.