Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Constrain IWXXM to 2D spatial CRSs #140

Closed
marqh opened this issue Dec 13, 2018 · 6 comments
Closed

Constrain IWXXM to 2D spatial CRSs #140

marqh opened this issue Dec 13, 2018 · 6 comments
Assignees

Comments

@marqh
Copy link
Member

marqh commented Dec 13, 2018

#120 was discussed in the Joint MIE MRI meeting in November 2017

A consensus was reached that IWXXM shall constrain use to 2D CRS definitions

An implementation plan to provide this constraint is now required

@marqh marqh self-assigned this Dec 13, 2018
@marqh marqh added this to the IWXXM 3.0 milestone Dec 13, 2018
@marqh
Copy link
Member Author

marqh commented Dec 13, 2018

One implementation proposal I have on this topic is to mandate the use of
srsDimension

within IWXXM.

srsDimension is optional within GML, with a constraint that if it is stated it must be consistent with the canonical information in the defined CRS, referenced by the srsName

By mandating that IWXXM messages use the srsDimension and that it's value is always set to srsDimensions=2 then IWXXM is enforcing the use of 2D horizontal CRS definitions within ElevatedPoint and other elements.

This proposal avoids the need for a whitelist of allowable srsName values, which may be an overly restrictive constraint for ongoing development.

@blchoy how would this look to you as a verifiable constraint?

@blchoy
Copy link
Member

blchoy commented Dec 14, 2018

srsDimension is optional within GML, with a constraint that if it is stated it must be consistent with the canonical information in the defined CRS, referenced by the srsName

The (embedded) schematron rules for GML are in this file but it doesn't seem to have the constrains you've mentioned. Seems to me that we will have to implement the CRS checking directly.

The checking is further complicated that srsName could be inherited from an ancestor as described here.

@marqh
Copy link
Member Author

marqh commented Dec 17, 2018

If we were to take this path, I think that we would need to link the requirements, making one conditional on the other.

We could perhaps state:

If and srsName is defined on an element, then that element shall also define
  - an srsDimension 
  - define srsDimension=2

This may be able to be added by us, but it would have to be part of IWXXM

We may want to add a note indicating why this is done, and highlighting that the srsDimension value must be consistent with the definition referenced by the srsName

This is extra work for us to manage inside IWXXM

@blchoy
Copy link
Member

blchoy commented Dec 18, 2018

Let me recap what we would like to do. Correct me if I have interpreted it wrongly:

  1. Indicate in our documentation that we SHALL only use 2D CRS in all features (we need to confirm this later on) making reference to the coordinate system
  2. Introduce schematron rules to ensure (1) is complied in IWXXM reports

There are certain ways to implement (2), including:
a. Mandate the use of 2D CRS by directly checking srsName
b. Mandate the inclusion of srsDimension=2 when srsName is specified, but expect the document creator to ensure the srsName is consistent with srsDimension

My gut feeling is that implementing (b) may not be reliable enough to tell people one has violated (1). Having said that, enforcing (1) with (a) at this moment could be too restrictive, especially as we still need to figure out how to manage the list of 2D CRS to be allowed.

@marqh
Copy link
Member Author

marqh commented Feb 20, 2019

question: should elevation in aixm:ElevatedPoint mandate that a vertical datum is defined

@blchoy
Copy link
Member

blchoy commented May 1, 2019

This was implemented in IWXXM 3.0.0RC3.

@blchoy blchoy closed this as completed May 1, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants