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

MI_Band Changes #168

Open
tedhabermann opened this issue Jan 21, 2017 · 5 comments
Open

MI_Band Changes #168

tedhabermann opened this issue Jan 21, 2017 · 5 comments

Comments

@tedhabermann
Copy link
Contributor

tedhabermann commented Jan 21, 2017

Add MI_Sensor,
nominalSpatialResolution -> Real (used to be distance which makes more sense)

@smrgeoinfo
Copy link
Contributor

mac:MI_Sensor is a property of mrc:MI_Band, and mac:MI_Sensor is a subtype of mac:MI_Instrument.
mac:MI_Instrument has a content property of type mrc:MD_ContentInformation. This creates a circular dependency between mrc and mac in 2017 ISO19115-2 revision.

Use cases--

  1. assert that a particular 'band' in a coverage was measured by a sensor described using acquisition details.
  2. assert the structure of information produced by an instrument (or sensor).

ContentInformation already has an abstract parent class in mcc;, so mac: can be decoupled from mrc with no problem.
It seems like an edge case that someone would want to bring all the MI_Instrument baggage into a MI_Band content information description. MI_Band already inherits a otherProperty.Record that could be used to detail this information.
I'd suggest that the sensor property on MI_Band should be a CI_Citation that provides a pointer to a complete definition of the sensor in a separate mac: document (or perhaps using ISO19130...). This would eliminate the circular dependency.

@tedhabermann
Copy link
Contributor Author

Another addition to MI_AcquisitionInformation is the MI_AcquisitionInformation/scope/MD_Scope that can be used to identify the attribute(s) derived from a particular instrument/sensor without creating a dependence between mac and mrc. I think we discussed this topic, but I am nor remembering the content of the discussion.

@tedhabermann
Copy link
Contributor Author

On MI_Band/sensor being a citation. The MI_Sensor object includes a citation that, I think, accomplishes the goal you describe.

@smrgeoinfo
Copy link
Contributor

That doesn't solve the problem, there's still a dependency from mac to mrc (for MD_ContentInformation) and from mrc to mac (for MI_Sensor on MI_Band), so one could never use anything from one package without importing both.
In MI_Instrument, if the data type for the content property is mcc:Abstract_ContentInformation then mac would have dependency on mcc (which is already there). mrc would still have a dependency on mac since there's not abstract class for MI_Sensor. I still think that making that a link (by reference only) so that mrc doesn't have to import mac would be a good thing,

@tedhabermann
Copy link
Contributor Author

Steve - am I wrong that the MD_Scope in MI_AcquisitionInformation solves the problem of linking acquisition information to an attribute(s), see earlier comment. I think we can drop MI_Sensor from mac and contentInformation from MI_Sensor. Then the connection from acquisition information / content is made as a link from mac to mrc.

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

2 participants