Comments (15)
It would just take a update to the mdJson schema and iso19115-2 writer
(internal object, mdBook, blah, blah, ...). We would first need to map the
appropriate classes into our class model. These were some of the classes
we passed over in the first cut. Do we need them now you think?
On Wed, May 27, 2015 at 1:09 PM, Josh Bradley [email protected]
wrote:
Any thoughts on implementing basic gridded/raster (MD_ContentInformation)
support in mdJSON & 19115-2 writer? Output would be something like this:gmd:contentInfo
gmi:MI_CoverageDescription
gmd:attributeDescription
gco:RecordTypeGrid Cell/gco:RecordType
/gmd:attributeDescription
gmd:contentType
<gmd:MD_CoverageContentTypeCode codeList="http://www.ngdc.noaa.gov/metadata/published/xsd/schema/resources/Codelist/gmxCodelists.xml#MD_CoverageContentTypeCode" codeListValue="physicalMeasurement">physicalMeasurement/gmd:MD_CoverageContentTypeCode
/gmd:contentType
gmd:dimension
gmd:MD_Band
gmd:descriptor
gco:CharacterStringDATATYPE IN CELL/gco:CharacterString
/gmd:descriptor
gmd:maxValue
gco:Real99/gco:Real
/gmd:maxValue
gmd:minValue
gco:Real99/gco:Real
/gmd:minValue
gmd:units
<gml:BaseUnit gml:id="gridCellID">
<gml:identifier codeSpace="local">UNITS/gml:identifier
<gml:unitsSystem nilReason="missing"/>
/gml:BaseUnit
/gmd:units
/gmd:MD_Band
/gmd:dimension
gmi:rangeElementDescription
gmi:MI_RangeElementDescription
gmi:name
gco:CharacterStringEmpty Grid Cell/gco:CharacterString
/gmi:name
gmi:definition
gco:CharacterString
Representation of grid cell with no measurement value.
/gco:CharacterString
/gmi:definition
gmi:rangeElement
gco:RecordEMPTY CELL VALUE/gco:Record
/gmi:rangeElement
/gmi:MI_RangeElementDescription
/gmi:rangeElementDescription
/gmi:MI_CoverageDescription
/gmd:contentInfo—
Reply to this email directly or view it on GitHub
#34.
Stan Smith
Alaska Science Center
Data Manager
907-786-7072 Office
907-223-8752 Mobile
[email protected]
from mdjson-schemas.
I'm in the process of writing some metadata for a bunch of geotiffs using mdJSON. Right now, if I want to include the raster specific metadata, I'll have to inject it after the translation process. It's not imperative we add it right now, but I think it should be on the priority list given the abundance of gridded data out there.
from mdjson-schemas.
I concur.
On Thu, May 28, 2015 at 8:52 AM, Josh Bradley [email protected]
wrote:
I'm in the process of writing some metadata for a bunch of geotiffs using
mdJSON. Right now, if I want to include the raster specific metadata, I'll
have to inject it after the translation process. It's not imperative we add
it right now, but I think it should be on the priority list given the
abundance of gridded data out there.—
Reply to this email directly or view it on GitHub
#34 (comment)
.
Stan Smith
Alaska Science Center
Data Manager
907-786-7072 Office
907-223-8752 Mobile
[email protected]
from mdjson-schemas.
Here's the proposed JSON implementation for MD_CoverageDescription. Note that this was largely based on the ISO 19115-1 model.
{
"rasterInfo": [
{
"rasterDescription": "",
"processingLevel": {
"identifier": "",
"type": "",
"namespace": "",
"version": "",
"description": "",
"authority": {
"title": "",
"date": [
{
"date": "",
"dateType": ""
}
],
"responsibleParty": [
{
"contactId": "",
"role": ""
}
],
"onlineResource": [
{
"uri": "",
"protocol": "",
"name": "",
"description": "",
"function": ""
}
]
}
},
"illuminationElevationAngle": 999.99,
"illuminationAzimuthAngle": 999.99,
"imagingCondition": "",
"imageQuality": {
"identifier": "",
"type": "",
"namespace": "",
"version": "",
"description": "",
"authority": {
"title": "",
"date": [
{
"date": "",
"dateType": ""
}
],
"responsibleParty": [
{
"contactId": "",
"role": ""
}
],
"onlineResource": [
{
"uri": "",
"protocol": "",
"name": "",
"description": "",
"function": ""
}
]
}
},
"cloudCoverPercent": 999.99,
"compressionQuantity": 9,
"triangulationIndicator": true,
"radiometricCalibrationAvailable": true,
"cameraCalibrationAvailable": true,
"filmDistortionAvailable": true,
"lensDistortionAvailable": true,
"attributeGroup": [
{
"contentType": [""],
"attribute": [
{
"attributeName": "",
"attributeType": "",
"description": "",
"numberOfValues": 9,
"maxValue": 999.99,
"minValue": 999.99,
"units": "",
"scaleFactor": 999.99,
"offset": 999.99,
"meanValue": 999.99,
"standardDeviation": 999.999,
"bitsPerValue": 8,
"attributeDomain": [
{
"identifier": "",
"type": "",
"namespace": "",
"version": "",
"description": "",
"authority": {
"title": "",
"date": [
{
"date": "",
"dateType": ""
}
],
"responsibleParty": [
{
"contactId": "",
"role": ""
}
],
"onlineResource": [
{
"uri": "",
"protocol": "",
"name": "",
"description": "",
"function": ""
}
]
}
}
],
"sensorMax": 999.99,
"sensorMin": 999.99,
"sensorUnits": "",
"sensorPeakResponse": 999.99,
"toneGradation": 9
}
]
}
]
}
]
}
from mdjson-schemas.
JSON representation of MD_GridSpatialRepresentation.
{
"gridInfo": [
{
"numberOfDimensions": 9,
"dimension": [
{
"dimensionType": "",
"dimensionSize": 9,
"resolution": 9,
"resolutionUnit": "",
"dimensionTitle": "",
"dimensionDescription": ""
}
],
"cellGeometry": "",
"transformationParameterAvailability": false
}
]
}
from mdjson-schemas.
What do you think about changing the mdJson dimension array above to remove 'resolution' since it is not a array and always a measure?
"dimension": [
{
"dimensionType": "",
"dimensionTitle": "",
"dimensionDescription": "",
"dimensionSize": 9,
"resolution": 9,
"resolutinUnits": ""
}
],
from mdjson-schemas.
I created mdTranslator interalObject hashes for rasterInfo and some modified element names to make more sense (provided I understand rasterInfo properly). Take a look and see if there are any problems. We may want to adopt some of this vocabulary in mdJson.
def newRasterInfo
intObj = {
rasterDescription: nil,
processingLevel: {},
illuminationElevationAngle: nil,
illuminationAzimuthAngle: nil,
imageCondition: nil,
imageQuality: {},
cloudCoverPercent: nil,
compressionQuality: nil,
triangulationInfo: false,
radiometricCalibrationInfo: false,
cameraCalibrationInfo: false,
filmDistortionInfo: false,
lensDistortionInfo: false,
rasterBandGroups: []
}
end
def newRasterBandGroup
intObj = {
bandGroupContents: [],
bands: []
}
end
def newRasterBand
intObj = {
bandName: nil,
bandType: nil,
bandDescription: nil,
minValue: nil,
maxValue: nil,
bandUnits: nil,
scaleFactor: nil,
offset: nil,
meanValue: nil,
numberOfValue: nil,
bitsPerValue: nil,
toneGradation: nil,
bandDomain: [],
sensorMin: nil,
sensorMax: nil,
sensorUnits: nil,
sensorPeakResponse: nil
}
end
processingLevel, imageQuality, and bandDomain elements are RS_Identifiers
from mdjson-schemas.
The MD_GridSpatialRepresentation looks good to me, and I like Stan's suggestion to remove the 'resolution' object and instead use the two fields (resolution, resolutionUnit) to document values for the the 'resolution' element its 'uom' attribute.
Where do the boundMin(sensorMin), boundMax(sensorMax), boundUnits(sensorUnits) come from in the MD_CoverageDescription/rasterInfo section?
Are we only going to use the MD_SampleDimension/attributeGroup content for electromagnetic sampling info (that is, wavelength measurements)? If not, then using bandName, bandType, bandDescription, might be confusing or perceived as limiting.
Josh, would you mind sharing the metadata records (and maybe the geotiffs themselves) that you mentioned in the your comment from May 28? It would be helpful to see them as examples.
from mdjson-schemas.
boundMin,Max,Units come from MD_Band in -1 (which incorporates MD_SampleDimension and MD_RangeDimension).
I do think we would like to handle more than just electromagnetic sampling - I an struggling for names that actually help people understand the element. If you have suggestion I would love to here them.
from mdjson-schemas.
I agree that using bandName, bandType, etc. might be confusing. However, I haven't come up with a better naming convention than attributeGroup/attribute.
@iamchrisser here's a link to an example of the geotiff's I'm documenting. The metadata was output using the mdTranslator (I did not add contentInfo or spatialRepresentation). There's an html version in the zip.
from mdjson-schemas.
Good point - I changed the internal names back from band to attribute ...
def newRasterInfo
intObj = {
rasterDescription: nil,
processingLevel: {},
illuminationElevationAngle: nil,
illuminationAzimuthAngle: nil,
imageCondition: nil,
imageQuality: {},
cloudCoverPercent: nil,
compressionQuality: nil,
triangulationInfo: false,
radiometricCalibrationInfo: false,
cameraCalibrationInfo: false,
filmDistortionInfo: false,
lensDistortionInfo: false,
rasterAttributeGroups: []
}
end
def newRasterAttributeGroup
intObj = {
rasterAttributeGroupContents: [],
rasterAttributes: []
}
end
def newRasterAttribute
intObj = {
attributeName: nil,
attributeType: nil,
attributeDescription: nil,
numberOfValues: nil,
minValue: nil,
maxValue: nil,
units: nil,
scaleFactor: nil,
offset: nil,
meanValue: nil,
bitsPerValue: nil,
attributeDomains: [],
sensorMin: nil,
sensorMax: nil,
sensorUnits: nil,
sensorPeakResponse: nil,
toneGradation: nil
}
end
I kept the changes boundMin, boundMax, boundUnit, and peakResponse to 'sensor' since these do relate director to sensor performance - unless you can see a use for them outside electromagnetic sampling.
from mdjson-schemas.
Added rasterInfo and gridInfo to template: 2ac2882#diff-ec3083330efb787fe8d0aae5be743335R682
from mdjson-schemas.
My take on for MD_CoverageDescription:
{
"coverageInfo": [
{
"coverageType": "MD_CoverageContentTypeCode",
"coverageDescription": "",
"coverageName": "",
"processingLevel": {
"identifier": "",
"type": "",
"namespace": "",
"version": "",
"description": "",
"authority": {
"title": "",
"date": [
{
"date": "",
"dateType": ""
}
],
"responsibleParty": [
{
"contactId": "",
"role": ""
}
],
"onlineResource": [
{
"uri": "",
"protocol": "",
"name": "",
"description": "",
"function": ""
}
]
}
},
"illuminationElevationAngle": 999.99,
"illuminationAzimuthAngle": 999.99,
"imagingCondition": "",
"imageQuality": {
"identifier": "",
"type": "",
"namespace": "",
"version": "",
"description": "",
"authority": {
"title": "",
"date": [
{
"date": "",
"dateType": ""
}
],
"responsibleParty": [
{
"contactId": "",
"role": ""
}
],
"onlineResource": [
{
"uri": "",
"protocol": "",
"name": "",
"description": "",
"function": ""
}
]
}
},
"cloudCoverPercent": 999.99,
"compressionQuantity": 9,
"triangulationIndicator": true,
"radiometricCalibrationAvailable": true,
"cameraCalibrationAvailable": true,
"filmDistortionAvailable": true,
"lensDistortionAvailable": true,
"coverageItems": [
{
"maxValue": 999.99,
"minValue": 999.99,
"units": "",
"scaleFactor": 999.99,
"offset": 999.99,
"meanValue": 999.99,
"standardDeviation": 999.999,
"scaleFactor": 999.99,
"offset": 999.99,
"meanValue": 999.99,
"standardDeviation": 999.999,
"bitsPerValue": 8,
"classification": [
{
"classificationName": "",
"classificationDescription": "",
"classificationIdentifier": [
{
"code": "",
"description": ""
}
]
}
],
"band": {
"toneGradation": 9,
"sensorMax": 999.99,
"sensorMin": 999.99,
"sensorUnits": "",
"sensorPeakResponse": 999.99
}
}
]
}
]
}
from mdjson-schemas.
Update to MD_CoverageDescription
Edited a few of the element names, but primarily grouped imageDescription, classifiedDataValues,, and sensorInfo into objects. This will provide a simple method for the writer to test what kind of coverageInfo is being described and then use the appropriate ISO classes.
{
"coverageInfo": [
{
"coverageType": "MD_CoverageContentTypeCode",
"coverageName": "",
"coverageDescription": "",
"processingLevel": {
"identifier": "",
"type": "",
"namespace": "",
"version": "",
"description": "",
"authority": {
"title": "",
"date": [
{
"date": "",
"dateType": ""
}
],
"responsibleParty": [
{
"contactId": "",
"role": ""
}
],
"onlineResource": [
{
"uri": "",
"protocol": "",
"name": "",
"description": "",
"function": ""
}
]
}
},
"coverageItem": [
{
"itemName": "",
"itemType": "",
"itemDescription": "",
"minValue": 999.99,
"maxValue": 999.99,
"units": "",
"scaleFactor": 999.99,
"offset": 999.99,
"meanValue": 999.99,
"standardDeviation": 999.999,
"bitsPerValue": 8,
"classedData": {
"numberOfClasses": 9,
"classedDataItem": [
{
"className": "",
"classDescription": "",
"classValue": 999.99
}
]
},
"sensorInfo": {
"toneGradations": 9,
"sensorMin": 999.99,
"sensorMax": 999.99,
"sensorUnits": "",
"sensorPeakResponse": 999.99
}
}
],
"imageInfo": {
"illuminationElevationAngle": 999.99,
"illuminationAzimuthAngle": 999.99,
"imagingCondition": "",
"imageQuality": {
"identifier": "",
"type": "",
"namespace": "",
"version": "",
"description": "",
"authority": {
"title": "",
"date": [
{
"date": "",
"dateType": ""
}
],
"responsibleParty": [
{
"contactId": "",
"role": ""
}
],
"onlineResource": [
{
"uri": "",
"protocol": "",
"name": "",
"description": "",
"function": ""
}
]
}
},
"cloudCoverPercent": 999.99,
"compressionQuantity": 9,
"triangulationIndicator": true,
"radiometricCalibrationAvailable": true,
"cameraCalibrationAvailable": true,
"filmDistortionAvailable": true,
"lensDistortionAvailable": true
}
}
]
}
from mdjson-schemas.
Current implementation of coverageInfo. One change: classedDataItem => classifiedDataItem. Still need a real example, I just used the test example for now.
{
"coverageType": "coverageType",
"coverageName": "coverageName",
"coverageDescription": "coverageDescription",
"processingLevel": {
"identifier": "identifier",
"type": "type",
"namespace": "namespace",
"version": "version",
"description": "description",
"authority": {
"title": "title",
"alternateTitle": "alternateTitle",
"date": [
{
"date": "1111-11-11",
"dateType": "dateType1"
}
],
"responsibleParty": [
{
"contactId": "contactId1",
"role": "role1"
}
],
"onlineResource": [
{
"uri": "http://thisisanexample1.com",
"protocol": "protocol1",
"name": "name1",
"description": "description1",
"function": "function1"
}
]
}
},
"coverageItem": [
{
"itemName": "itemName1",
"itemType": "itemType1",
"itemDescription": "itemDescription1",
"minValue": 111.11,
"maxValue": 111.11,
"units": "",
"scaleFactor": 111.11,
"offset": 111.11,
"meanValue": 111.11,
"standardDeviation": 111.119,
"bitsPerValue": 1,
"classifiedData": {
"numberOfClasses": 1,
"classifiedDataItem": [
{
"className": "className1",
"classDescription": "classDescription1",
"classValue": 111.11
},
{
"className": "className2",
"classDescription": "classDescription2",
"classValue": 222.22
}
]
},
"sensorInfo": {
"toneGradations": 1,
"sensorMin": 111.11,
"sensorMax": 111.11,
"sensorUnits": "",
"sensorPeakResponse": 111.11
}
}, {
"itemName": "itemName2",
"itemType": "itemType2",
"itemDescription": "itemDescription2",
"minValue": 222.22,
"maxValue": 222.22,
"units": "",
"scaleFactor": 222.22,
"offset": 222.22,
"meanValue": 222.22,
"standardDeviation": 222.22,
"bitsPerValue": 2,
"classifiedData": {
"numberOfClasses": 2,
"classifiedDataItem": [
{
"className": "className2",
"classDescription": "classDescription2",
"classValue": 222.22
}
]
},
"sensorInfo": {
"toneGradations": 2,
"sensorMin": 222.22,
"sensorMax": 222.22,
"sensorUnits": "",
"sensorPeakResponse": 222.22
}
}
],
"imageInfo": {
"illuminationElevationAngle": 111.11,
"illuminationAzimuthAngle": 111.11,
"imagingCondition": "imagingCondition",
"imageQuality": {
"identifier": "identifier",
"type": "type",
"namespace": "namespace",
"version": "version",
"description": "description",
"authority": {
"title": "title",
"alternateTitle": "alternateTitle",
"date": [
{
"date": "1111-11-11",
"dateType": "dateType1"
}
],
"responsibleParty": [
{
"contactId": "contactId1",
"role": "role1"
}
],
"onlineResource": [
{
"uri": "http://thisisanexample1.com",
"protocol": "protocol1",
"name": "name1",
"description": "description1",
"function": "function1"
}
]
}
},
"cloudCoverPercent": 11.11,
"compressionQuantity": 1,
"triangulationIndicator": true,
"radiometricCalibrationAvailable": true,
"cameraCalibrationAvailable": true,
"filmDistortionAvailable": true,
"lensDistortionAvailable": true
}
}
from mdjson-schemas.
Related Issues (20)
- New Class - ProcessParameter HOT 1
- Acquisitions HOT 1
- New Class - CoverageResult HOT 5
- Data Quality
- New Class - ComponentIdentifier HOT 1
- Feature/Data Quality HOT 6
- Identifying metadata standard and profile
- Verify translation descriptions for dataQuality report elements HOT 3
- Update dataQuality report type element
- Verify and update datQuality derivedElementReport schema HOT 2
- Update dataQuality report evaluationMethod element HOT 2
- Rename dev --> develop HOT 1
- Release v2.8.2 HOT 1
- Update Ruby Gem Version Number
- DQ_CompletenessOmission Typo
- Missing DQ_NonQuantitativeAttributeAccuracy
- Release v2.8.3 HOT 1
- Bug Fix Data Quality and Schema Versioning
- Fix Data Quality Report Type Enum
- Update definitions for mdJSON component system identifiers
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from mdjson-schemas.