Implementing the ability to add campaign information to the ISO, I've been using the spreadsheet.  Similar to the bit with Platforms, I think the spreadsheet may not be completely up-to-date.  Here is a sample of the ISO we are using:

<gmi:operation>
<gmi:MI_Operation>
<gmi:description>
<gco:CharacterString>StartDate=2010-10-19 EndDate=2010-11-21</gco:CharacterString>
</gmi:description>
<gmi:identifier>
<gmd:MD_Identifier>
<gmd:code>
<gco:CharacterString>2010_AN_NASA</gco:CharacterString>
</gmd:code>
<gmd:codeSpace>
<gco:CharacterString>gov.nasa.esdis.umm.projectshortname</gco:CharacterString>
</gmd:codeSpace>
<gmd:description>
<gco:CharacterString>Operation IceBridge West Antarctica/Antarctic Sea Ice 2010</gco:CharacterString>
</gmd:description>
</gmd:MD_Identifier>
</gmi:identifier>
<gmi:status gco:nilReason="missing"/>
<gmi:type>
<gmi:MI_OperationTypeCode codeList="#MI_OperationTypeCode" codeListValue="real">real</gmi:MI_OperationTypeCode>
</gmi:type>
<gmi:parentOperation gco:nilReason="missing"/>
</gmi:MI_Operation>
</gmi:operation>

This is all in the Acquisition Information tag, between the instruments and platforms tags.

A few notes:

  • The part in the identifier "code" tag seems to get picked up properly as the Short Name as expected.
  • The spreadsheet (M530) indicates that the Long Name should be coming from the "description" tag inside the identifier tag.  However, it seems to be pulling from the OUTER "description" tag (the one just above the identifier tag).
  • The spreadsheet (M532:M533) indicates that the Start and Stop dates should be coming from parsing out the outer "description" tag; however, as mentioned above, the outer tag is being used to pull in the Long Name instead.  (I tried putting the StartDate= and EndDate= bits in the "inner" description just to see what would happen, and it's still being ignored.
  • There are a few tags that are required by the schema that aren't discussed in the spreadsheet:
    • gmi:status - this is a required tag.  I wasn't sure what to put here, so I just put it as "missing"
    • gmi:type - I may have been able to try putting "missing" here, but I did find a code list entry for this; in the case of what we are doing here, the value is going to all be "real" for our datasets anyway.  It doesn't seem to care that I didn't put a full URL in, but I'll probably need to find out what the URL part should be.
    • gmi:parentOperation - Seems to be required, but I'm not sure what should go here, so I just put it as missing.

 

  • No labels

3 Comments

  1. Scott Lewis

    Modified the above.  The latter points about the required tags came up when I ran a validation check against the XML, and had to add the fields as described.  Those aren't as critical as I don't think they are being parsed during ingest.

    1. Erich Reiter

      This problem is being worked through issue: CMR-3908 and the issue does include the NSIDC label. This issue is being worked in sprint 72 which ends this Friday April 28th.  Which means that this code will be in UAT on May 3rd. While testing I discovered one issue that needs to be addressed in the Data below.  On the 4th line change <gco:CharacterString>StartDate=2010-10-19 EndDate=2010-11-21</gco:CharacterString> to

      <gco:CharacterString>StartDate: 2010-10-19 EndDate: 2010-11-21</gco:CharacterString>

      change = to :  (colon with a space after it)

       

                  <gmi:operation>
              <gmi:MI_Operation>
                <gmi:description>
                  <gco:CharacterString>StartDate: 2010-10-19 EndDate: 2010-11-21</gco:CharacterString>
                </gmi:description>
                <gmi:identifier>
                  <gmd:MD_Identifier>
                    <gmd:code>
                      <gco:CharacterString>2010_AN_NASA</gco:CharacterString>
                    </gmd:code>
                    <gmd:codeSpace>
                      <gco:CharacterString>gov.nasa.esdis.umm.projectshortname</gco:CharacterString>
                    </gmd:codeSpace>
                    <gmd:description>
                      <gco:CharacterString>Operation IceBridge West Antarctica/Antarctic Sea Ice 2010</gco:CharacterString>
                    </gmd:description>
                  </gmd:MD_Identifier>
                </gmi:identifier>
                <gmi:status gco:nilReason="missing"/>
                <gmi:type>
                  <gmi:MI_OperationTypeCode codeList="#MI_OperationTypeCode" codeListValue="real">real</gmi:MI_OperationTypeCode>
                </gmi:type>
                <gmi:parentOperation gco:nilReason="missing"/>
              </gmi:MI_Operation>
            </gmi:operation>

       

      As to your notes:

      • The part in the identifier "code" tag seems to get picked up properly as the Short Name as expected.

      Great.

      • The spreadsheet (M530) indicates that the Long Name should be coming from the "description" tag inside the identifier tag.  However, it seems to be pulling from the OUTER "description" tag (the one just above the identifier tag).

      The code has been fixed to read the long name from the identification description.

      • The spreadsheet (M532:M533) indicates that the Start and Stop dates should be coming from parsing out the outer "description" tag; however, as mentioned above, the outer tag is being used to pull in the Long Name instead.  (I tried putting the StartDate= and EndDate= bits in the "inner" description just to see what would happen, and it's still being ignored.

      The code has been fixed to read the StartDate:  and EndDate: in the outer description element. Also change your software to use StartDate:(space)(date) and EndDate:(space)(date) instead of the equal sign.

      • There are a few tags that are required by the schema that aren't discussed in the spreadsheet:
        • gmi:status - this is a required tag.  I wasn't sure what to put here, so I just put it as "missing"

      I didn't use missing, I left it empty, but missing is better


        • gmi:type - I may have been able to try putting "missing" here, but I did find a code list entry for this; in the case of what we are doing here, the value is going to all be "real" for our datasets anyway.  It doesn't seem to care that I didn't put a full URL in, but I'll probably need to find out what the URL part should be.

      In the ISO MENDS schema that the CMR is using located here:https://cdn.earthdata.nasa.gov/iso/ under the acquisitionInformation.xsd located here: https://cdn.earthdata.nasa.gov/iso/gmi/1.0/acquisitionInformation.xsd the gmi:type is optional: <xs:element name="type" type="gmi:MI_OperationTypeCode_PropertyType" minOccurs="0" maxOccurs="1"/>  If you want to use it that is fine, the CMR will ignore this element.


        • gmi:parentOperation - Seems to be required, but I'm not sure what should go here, so I just put it as missing.

      Missing is fine. I used <gmi:parentOperation gco:nilReason="inapplicable"/> - either way the CMR is not reading this element.

       

      1. Scott Lewis

        Thanks.  I must have misread the errors that Oxygen was giving me with the parentOperation and gmi:type thing.  When I removed the gmi:type bit, it still seems to work, so I'll just omit that, and will put "inapplicable" for the parentOperation.

        I'll fix the StartDate: and EndDate: bits in my code as well.