Home

Goals and Guidance:

1. Define in the FSD a formalization of the XML fields that are used to specify the horizontal and vertical CRS in the BAG file. The goal being to make sure that there is no ambiguity in how these fields should be filled out in the future.
2. Provide a definitive and axiomatic formalization of the encoding in the CRS fields (both vertical and horizontal).
3. If a Geographic 3D CRS is specified, mandate that it only appear in what is currently the “horizontal” CRS position, and that the “vertical” CRS metadata must be blank. Failure to do this is a validation error.
4. Strongly prefer EPSG codes when possible, and prefer the EPSG code embedded in WKT over the WKT itself. Use WKT as a backup if the EPSG doesn’t exist.
5. Allow optional transformation information to be encoded, but in a separate metadata element from the horizontal/vertical CRS information. Provide a definitive and axiomatic encoding of same.
6. Provide for validation of the CRS and (optional) transformation information through a suitable mechanism (e.g., XML schema).

Questions

1. How should the CRS be specified? Can we do this with existing metadata elements? Or do we need to use a separation layer?
2. Does the discovery level metadata in the XML provide enough, or do we need something more specialized? Could we do this in two layers so that average users could use the obvious definitions, but more sophisticated users could dig deeper?
3. What are the complexity implications for your selected method of CRS definition? Is this going to be a major effort to implement? Would we break backwards compatibility?
4. How do we do validation checks? Is an XSD statement enough, or do we need code?
5. If we choose to store a history of transformations, could this be in the lineage metadata? If so, how?