Opened 7 years ago

Closed 7 years ago

#1624 closed defect (fixed)

SECORE_Resolve user-defined CRS with non-existent version correctly

Reported by: Bang Pham Huu Owned by: Bang Pham Huu
Priority: major Milestone: 9.5
Component: secore Version: development
Keywords: Cc: Dimitar Misev, Vlad Merticariu, Peter Baumann
Complexity: Medium

Description

I'm investigating this problem in SECORE. Current, SECORE supports 3 versions for CRS (default: 0, 8.5 and 8.9.2).

One can add a custom CRS to user dictionary via SECORE JSP page (e.g: opengis.net/def/browse.jsp). And from that, a user-defined CRS could be added to userdb with a non-existent version by changing the value of gml:identifier.

e.g: user wants to add a EPSG:4326 CRS as OGC/1.3/CRS84, then in opengis.net/def/browse.jsp, copy EPSG:4326's definition from opengis.net/def/crs/EPSG/0/4326/browse.jsp and change value for gml:identifier to:

<gml:identifier codeSpace="OGP">http://www.opengis.net/def/crs/OGC/1.3/CRS84</gml:identifier>

And click on "Add" button to add new CRS to BaseX database. After that, any request with this non-existent version (1.3) goes to the user dictionary (userdb).

However, when requesting to opengis.net/def/crs/OGC/1.3/CRS84, it could not resolve this CRS correctly as from opengis.net/crs/EPSG/0/4326, although the only difference from them is the gml:identifier value.

Here the diff from 2 outputs, left is EPSG/0/4326, right is OGC/1.3/CRS84 with "<empty/>" elements instead of resolved elements.

https://www.diffchecker.com/6s8p9WSj

Change History (2)

comment:1 by Bang Pham Huu, 7 years ago

I fixed this problem, it is due to SECORE only sends to a fixed version (8.5 in this case) when it resolves internal CRS of OGC/1.3/CRS84 which is: def/crs/EPSG/0/4326). As dictionary version 8.5 does not contain any version 0 so it returns empty.

The correct solution is changing in XQuery to be dependent on the version of the resolving CRS (it could be 0, 8.5, 8.9.2,…) instead of a fixed version (8.5), e.g internal of 0GC/1.3/CRS84 contains 3 different versions of internal CRSs which all could be resolved:

<gml:identifier codeSpace="OGP">http://www.opengis.net/def/crs/OGC/1.3/CRS84</gml:identifier>
  <gml:name>WGS 84</gml:name>
  <gml:domainOfValidity xlink:href="http://www.opengis.net/def/area/EPSG/0/1262"/>
  <gml:scope>Horizontal component of 3D system. Used by the GPS satellite navigation system and for NATO military geodetic surveying.</gml:scope>
  <gml:ellipsoidalCS xlink:href="http://www.opengis.net/def/cs/EPSG/8.5/6422"/>
  <gml:geodeticDatum xlink:href="http://www.opengis.net/def/datum/EPSG/8.9.2/6326"/>

Need Dimitar to review and makes Jenkins run to test the patch and after that updating to opengis.net with new war file.

Version 0, edited 7 years ago by Bang Pham Huu (next)

comment:2 by Bang Pham Huu, 7 years ago

Resolution: fixed
Status: newclosed
Note: See TracTickets for help on using tickets.