SECORE cannot resolve parametertized CRSs inside a CRS definition

[Bang Pham Huu]

SECORE supports parameterized CRS e.g:
​http://www.opengis.net/def/crs/OGC/0/Index1D?axis-label=%22xxx%22
which will replace the default of axisAbbrev element from "i" to "xxx".

This works by:
+ Index1D is defined as a ParameterizedCrs, see definition here: ​http://www.opengis.net/def/crs/OGC/0/Index1D/browse.jsp [1]
+ And inside Index1D definition, it has a "targetCRS xlink" element which points to a template CRS (this is the final output to client). [2]

Step [1] is handled in Java code (class ParameterizedCrsHandler ​http://rasdaman.org/browser/applications/secore/src/main/java/org/rasdaman/secore/handler/ParameterizedCrsHandler.java#L241).

After it processed the input parameter, it will pass to step [2] which is handled by BaseX recursive query (​http://rasdaman.org/browser/applications/secore/src/main/java/org/rasdaman/secore/handler/AbstractHandler.java#L190) which only tries to resolve xlink href CRS from collections (userdb, gml_versions).

For WMS 1.3 CRSs, there is a problem as CRS can contain another parameterized CRS inside, e.g (not exist in opengis.net yet):

​http://www.opengis.net/def/crs/OGC/1.3/AUTO42001/99/8888
(99, 8888 are parameters)

which contains

<conversion

[3] xlink:href="http://www.opengis.net/def/coordinateOperation/OGC/1.3/AutoUniversalTransverseMercatorConversion/99/8888"/> 

(99, 8888 are parameters)

SECORE can't resolve [3] via the recursive XQuery in [2] as there are no existing CRS which has these parameters (99, 8888).

Need some ideas how to solve it.

[Peter Baumann]

what about inserting the missing CRSs bottom up?

[Bang Pham Huu]

Replying to pbaumann:

what about inserting the missing CRSs bottom up?

I'm fixing this problem already, bottom-up can only be done after this fix.

[Peter Baumann]

ok, excellent!