Initial draft notes on implementing support for UAV datasets #96
Conversation
der
left a comment
der
left a comment
There was a problem hiding this comment.
Seems like a sensible approach to me.
For what its worth, I think the OGC terminology for this sort of dataset would be a coverage which is a map from some space-time path/grid/point-cloud to a set of (measured/forecast) values. There's mention of this in Spatial Data on the Web. There are OGC API specs for retrieving coverages but don't recall anything in SensorThings that might relate to that. If there's some part of those specs that would nicely represent a UAV flight path I can't immediately find it. So don't think any of that makes a difference to the modelling.
|
|
||
| **QUESTION** Is there any value in capturing the duration of the flight log? | ||
|
|
||
| **NOTE** Currently the FDRI model does not have a generic "Document" resource type with associated Distributions. This sort of model might be useful not only for providing a means to associate metadata with a flight log, but also for specifying distribution formats and locations for other files (e.g. sensor certifications) No newline at end of file |
There was a problem hiding this comment.
Ability to capture document format in the metadata store would be useful I suspect. At least to know what is available, and possibly to capture format information that isn't cover by the document's mediatype.
There was a problem hiding this comment.
Yes I think it makes sense to add the Document class to the model and allow it to have distributions for linking to the document file.
For initial review and comment @mattfry-ceh , @der