Opened 4 years ago

Closed 4 years ago

Last modified 4 years ago

#318 closed enhancement (fixed)

SECORE distinct notation to retrieve raw definition of a parametrized CRS

Reported by: pcampalani Owned by: mrusu
Priority: major Milestone: 8.4.2
Component: secore Version: 8.3
Keywords: parametrized definitions Cc: dmisev, mrusu, pbaumann, abeccati
Complexity: Medium

Description

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.

Change History (9)

comment:1 Changed 4 years ago by pcampalani

  • Summary changed from SECORE distinct notation to retrieve real source of a parametrized CRS to SECORE distinct notation to retrieve raw definition of a parametrized CRS

comment:2 follow-up: Changed 4 years ago by dmisev

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

comment:3 in reply to: ↑ 2 Changed 4 years ago by pcampalani

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

comment:4 follow-up: Changed 4 years ago by 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 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..

comment:5 in reply to: ↑ 4 Changed 4 years ago by pcampalani

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.

comment:6 Changed 4 years ago by dmisev

  • Complexity set to Medium

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

comment:7 follow-up: Changed 4 years ago by dmisev

  • Resolution set to fixed
  • Status changed from new to closed

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

comment:8 in reply to: ↑ 7 Changed 4 years ago by pcampalani

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.

comment:9 Changed 4 years ago by abeccati

  • Milestone changed from 9.0 to 8.4.2
Note: See TracTickets for help on using tickets.