SECORE distinct notation to retrieve raw definition of a parametrized CRS

[Piero Campalani]

Opening this ticket since I believe that parametrized CRSs should still return the target CRS when e.g. no parameters are set by the user and all the parameters are defined with a default value.

This way the same URI can be used for both template and customized CRS definition.

E.g. Having a template CRS for ANSI dates "http://kahlua.eecs.jacobs-university.de:8080/def/crs/OGC/0.1/ANSI_Date-template", this can be targeted by a parametrized CRS, say "http://kahlua.eecs.jacobs-university.de:8080/def/crs/OGC/0.1/ANSI_Date", offering the chance to customize the axis label from t to something else.

For instance, `"​http://kahlua.eecs.jacobs-university.de:8080/def/crs/OGC/0.1/ANSI_Date?t=%22day%22"' would set the axis label to "day".

Now, by calling the parametrized CRS with no parameters SECORE returns the gml:ParametrizedCRS definition, whereas it would be best to return the ANSI_Date-template definition with default t label, so that the URI "http://kahlua.eecs.jacobs-university.de:8080/def/crs/OGC/0.1/ANSI_Date-template" must no be disclosed, avoiding confusion to the user.

Since still it must be possible to retrieve the raw definition (with XPaths, etc.) of the gml:ParametrizedCRS, we might think of a specific notation (just like with compouninds, or equality tests), as Dimitar suggested.

[Dimitar Misev]

So the point is, the URL below gets the ParameterizedCRS definition when no parameters are given:

​http://kahlua.eecs.jacobs-university.de:8080/def/crs/OGC/0.1/ANSI_Date

But it would be better if it retrieves the target CRS with the default values, if that's possible:

​http://kahlua.eecs.jacobs-university.de:8080/def/crs/OGC/0.1/ANSI_Date?t="day"

So the proposed way to retrieve the ParameterizedCRS itself in that case could be

​http://kahlua.eecs.jacobs-university.de:8080/def/crs-parameterized/OGC/0.1/ANSI_Date

[Piero Campalani]

Yes, something like that, so that:

​http://kahlua.eecs.jacobs-university.de:8080/def/crs/OGC/0.1/ANSI_Date

would retrieve the ANSI-Date-template CRS with default values, and:

​http://kahlua.eecs.jacobs-university.de:8080/def/crs-parametrized/OGC/0.1/ANSI_Date

would return the raw definition with parameters definitions, etc.

Actually, the other way around might be more intuitive… With normal notation you get the raw source, while if you want to exploit parametrization you could use "def/crs-parametrized/OGC... and either set or not the parameters, but always giving back some version of the target CRS. ?

[Dimitar Misev]

I think I'd prefer an extra parameter, e.g.

​http://kahlua.eecs.jacobs-university.de:8080/def/crs/OGC/0.1/ANSI_Date?resolve-target=no

so that you can get back the original ParameterizedCRS definition along with the values substituted. Would be useful for debugging.

I don't even know why we had to introduce /def/crs-compound, when a compound CRS is still a CRS, there's no need to make distinction from simple definitions..

[Piero Campalani]

Replying to dmisev:

I think I'd prefer an extra parameter, e.g.

​http://kahlua.eecs.jacobs-university.de:8080/def/crs/OGC/0.1/ANSI_Date?resolve-target=no

so that you can get back the original ParameterizedCRS definition along with the values substituted. Would be useful for debugging.

I like this idea.

I don't even know why we had to introduce /def/crs-compound, when a compound CRS is still a CRS, there's no need to make distinction from simple definitions..

I would keep compounding explicit, it makes sense (also WKT does), whereas the output of a paramterized CRS is still a CRS, so it is better to keep the notation as you say.

[Dimitar Misev]

It's a bit tricky. The problem is in the canHandle methods, which work purely on the request, and from a request like

​http://kahlua.eecs.jacobs-university.de:8080/def/crs/OGC/0.1/ANSI_Date

is not possible to figure out if it's a normal CRS or parameterized. It would be necessary to resolve it and look at the root element in order to pick the right Handler. I guess it's inevitable to chain the GeneralHandler and ParameterizedHandler

[Dimitar Misev]

I would keep compounding explicit, it makes sense (also WKT does), whereas the output of a paramterized CRS is still a CRS, so it is better to keep the notation as you say.

But the output of /crs-compound is still a valid CRS too. Do you have an example for compound CRS definition in WKT?

Btw, I think I've fixed this ticket, changeset:6b7fd1a369d3e0d1a62e1c71dd8cb3ca7e7e1c59

[Piero Campalani]

Replying to dmisev:

But the output of /crs-compound is still a valid CRS too. Do you have an example for compound CRS definition in WKT?

Yes, see WKT Example in ​http://docs.geotools.org/stable/javadocs/org/opengis/referencing/doc-files/WKT.html.

Btw, I think I've fixed this ticket, changeset:6b7fd1a369d3e0d1a62e1c71dd8cb3ca7e7e1c59

Great.