Page tree
Skip to end of metadata
Go to start of metadata

In adding the AircraftID characteristic, I noticed that there may be some discrepancy between what the DIF-UMM_ECHO Mapping.xlsx file says (v1.9) and how the ingest is actually happening.

Looking at rows 489-492 in particular:

  • The "gmd:description" tag under the main EOS_Platform tag shows in the Spreadsheet to have it's Character String value "= Type:" (not really sure what this is)
  • The Short Name should be in a "gmi:identifier/gmd:MD_Identifier" tag, with the "gmd:code" being the short name value, and the Description being text that simply says "Platform Short Name", and a "gmd:codeSpace" tag along with it (wasn't clear on how that should be used)
  • The Long Name is similar to the Short Name above, except the Description says "Platform Long Name" (and a corresponding value for gmd:codeSpace)

However, in practice, it doesn't seem like it actually ingests that way.  For one thing, it seems to be invalid to have multiple "gmi:identifier" tags.  In the ingest ISO that we are currently sending, it looks like this:

<gmi:instrument xlink:href="#INSTRUMENT_ID"/>

Essentially, the Short Name is in the "gmd:code" part of the identifier, but the Long Name is the "description" of the identifier (and not a separate identifier).  The description of the platform itself is not "Type:" but rather seems to actually be the description of the platform.

My guess is the spreadsheet is incorrect in this case, and that the way we are writing the ISO is indeed the correct way to specify short name, long name, etc.  (After ingesting, when we look at the UMM, for instance, the fields seem to be populated based on the values above).


A related note, too, is that if the value of PLATFORM_DESCRIPTION is longer than 80 characters, it throws a warning message about it.  While this may be a necessary restriction for something on the back-end, it's not really clear from the spreadsheet, and many of our platform descriptions may be longer than 80 characters.  We could truncate, but it would make these descriptions somewhat less useful.


Mostly need clarification as to the "proper" way to ingest platforms.

  • No labels


  1. Scott Lewis

    Erich Reiter is the best to answer these questions, but he is out until tomorrow. We have tickets in the next sprint to update our code to match the spreadsheet, so what you are saying is correct. Right now it is slightly off. From what I can see, what you are doing is correct. 

    As for the platform description length, Erich will have to speak to that and if that is something we would want to increase.

  2. I have updated the spreadsheet I think early last week, because I also noticed that only one identifier was allowed in the platform.  Download it again to see the latest updates.  I had the same issue for instrument, instrument composedOf (old sensor), and project.

    Other issues:

    1. The "gmd:description" tag under the main EOS_Platform tag ...
      1. no longer includes type: as part of the value.  In many places where elements don't exist that are needed to represent data in the UMM, Ted had placed these values in description elements along with a prefix of the name: and then the value.  Since it wasn't clear that the description is mapped to the UMM Platform/Type element I wanted to add the prefix so that others could also include a description if it was desired.  I have removed the prefix of type: from the description element. Now the entire string will be mapped to Platform/Type which is controlled vocabulary from the GCMD platform/category element.
    2. The Short Name should be in a "gmi:identifier/gmd:MD_Identifier" tag ...
      1. The Short Name is placed into the gmd:code/gco:CharacterString element.
      2. For all identifiers I am using the codeSpace to let software know what kind of ID this element group is.  I understand that in this example there is only one identifier, but at the identificationInfo level there can be many. We are using this structure for all identifiers.
      3. The description contains the long name.
    3. Since there can only be one identifier the Long Name has been placed into the shortname's identification/description element.
    4. Not every element is mapped correctly we have issue CMR-3913 to fix any outstanding issues with platform ISO <=> UMM translations which will start the week of April 17th.
    5. PLATFORM_DESCRIPTION - since ISO platform/description is mapped to UMM Platform/Type the CMR will expect the controlled vocabulary as defined in number 1) above. If it is desired to have a platform description, we will need to add prefixes to this element so that it can hold both the platform type and the description.  If we allow both values then we would have to allow many more characters than 80 for this element.  To follow Ted's examples the description would look like the following:

        <gco:CharacterString>Type: Aircraft  Description: Some long description of the platform</gco:CharacterString>


    Here is my ISO example for an aircraft platform where the description just contains the UMM Platform/Type value:

      <eos:EOS_Platform id="Aircraft1">
              <!-- The aircraft short name -->
              <!-- for all identifiers I am using the codeSpace to let software know what kind of ID this is
                   I understand that in this example there is only one identifier, but at the identificationInfo
                   level there can be many, so we are using this for all identifiers -->
              <!-- The aircraft long name -->
              <gco:CharacterString>Beechcraft King Air B-200</gco:CharacterString>
        <!-- This is UMM Platform Type -->
        <gmi:instrument xlink:href="#Instrument3"/>
                      <eos:EOS_AdditionalAttributeTypeCode codeList="" codeListValue="platformInformation">platformInformation</eos:EOS_AdditionalAttributeTypeCode>
                      <gco:CharacterString>Tail Number</gco:CharacterString>
                      <gco:CharacterString>Aircraft Tail Number</gco:CharacterString>
                      <eos:EOS_AdditionalAttributeDataTypeCode codeList="" codeListValue="string">string</eos:EOS_AdditionalAttributeDataTypeCode>
                      <gco:CharacterString>Not Applicable</gco:CharacterString>


    Here is how is it translated into UMM:

      "Type" : "Aircraft",
      "ShortName" : "B-200",
      "LongName" : "Beechcraft King Air B-200",
      "Characteristics" : [ {
        "Name" : "Tail Number",
        "Description" : "Aircraft Tail Number",
        "Value" : "EER2365876",
        "Unit" : "Not Applicable",
        "DataType" : "string"
        } ],
  3. Thanks, this makes a lot of sense, and I think it will allow us to go forward.