Opened 3 years ago

Closed 10 days ago

Last modified 10 days ago

#708 closed defect (wontfix)

SECORE support proj4 to support transformation to customized CRS

Reported by: pcampalani Owned by: dmisev
Priority: major Milestone: 10.0
Component: petascope Version: development
Keywords: crs encode Cc:
Complexity: Medium

Description (last modified by bphamhuu)

Petascope should not pass the URI as crs parameter of the 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", [...]

Change History (18)

comment:1 Changed 3 years ago by pcampalani

  • Description modified (diff)

comment:2 Changed 3 years ago by dmisev

You think GML -> WKT would be a lot of effort?

comment:3 Changed 3 years ago by dmisev

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.

comment:4 Changed 3 years ago by pcampalani

  • Owner changed from pcampalani to dmisev
  • Status changed from new to assigned

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

(I'll reassign this to you now)

comment:5 Changed 3 years ago by dmisev

  • Milestone changed from 9.1 to 10.0

comment:6 Changed 2 years ago by pbaumann

  • Resolution set to wontfix
  • Status changed from assigned to closed

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.

comment:7 Changed 2 years ago by dmisev

  • Resolution wontfix deleted
  • Status changed from closed to reopened

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..

comment:8 Changed 2 years ago by pbaumann

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

comment:9 Changed 2 years ago by dmisev

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

comment:10 Changed 2 years ago by pbaumann

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

comment:11 follow-up: Changed 15 months ago by pbaumann

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.

comment:12 in reply to: ↑ 11 Changed 15 months ago by dmisev

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.

comment:13 Changed 9 months ago by bphamhuu

  • Complexity changed from Hard to Medium
  • Description modified (diff)
  • Owner changed from dmisev to bphamhuu
  • Status changed from reopened to assigned
  • Summary changed from CRS parameter for encode() function to SECORE support proj4 to support transformation to customized CRS

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.

Last edited 9 months ago by bphamhuu (previous) (diff)

comment:14 Changed 9 months ago by dmisev

  • Owner changed from bphamhuu to dmisev

comment:15 Changed 4 months ago by bphamhuu

I update this ticket with some testings from using GDAL library instead of geoTool in Petascope for CrsTransform?.

+ GDAL can read GML (?) from a non-valid GML 3.2.1 schema CRS: http://spatialreference.org/ref/epsg/4326/gml/ instead of CRS with valid schema http://www.opengis.net/def/crs/EPSG/0/4326.
+ For ticket:367, GDAL can export to WKT, Proj4 so SECORE can also have these definitions for ESPG codes as same as: http://epsg.io/4326

However, if a CRS is not from EPSG, GDAL cannot do anything as it could not read the GML from SECORE. In this case, the only thing can help is put the wkt or proj4 of the CRS definition manually to e.g: WCPS with CrsTransform? to Rasql for GDAL. That is why I suggested to allow user add the wkt or proj4 definition manually as same as GML in SECORE in the above comment because the GML is verbose when wkt or better proj4 is short and straightforward.

comment:16 Changed 10 days ago by bphamhuu

@pbaumann: please read this https://docs.qgis.org/2.2/en/docs/user_manual/working_with_projections/working_with_projections.html#custom-coordinate-reference-system as current PlanetServer? 2 using EPSG:4326 for WMS on the Globe for Mars, Moon. So, there is a must for Petascope can support custom CRS reprojection as GDAL only knows EPSG Code, WKT, Proj4.

comment:17 follow-up: Changed 10 days ago by pbaumann

  • Resolution set to wontfix
  • Status changed from assigned to closed

actually, not: SECORE is just the OGC _resolver_ with the sole task of delivering definitions of CRS URLs passed. Being the authoritative OGC resolver we do not have authority to do anything beyond that.

comment:18 in reply to: ↑ 17 Changed 10 days ago by bphamhuu

Replying to pbaumann:

actually, not: SECORE is just the OGC _resolver_ with the sole task of delivering definitions of CRS URLs passed. Being the authoritative OGC resolver we do not have authority to do anything beyond that.

It is fine, thanks for closing it, so we know Petascope can only support CRS projection from EPSG code.

Note: See TracTickets for help on using tickets.