Child pages
  • ISO - AircraftID (additional attribute) mapping to actual Aircraft
Skip to end of metadata
Go to start of metadata

Information I was given for including AircraftID for a dataset (IE, IceBridge) was to use an AdditionalAttribute tag, like this:

<eos:AdditionalAttributes>
<eos:AdditionalAttribute>
<eos:reference>
<eos:EOS_AdditionalAttributeDescription>
<eos:name>
<gco:CharacterString>AircraftID</gco:CharacterString>
</eos:name>
<eos:description>
<gco:CharacterString>The identifier of the airplane used by the FAA to uniquely identify each aircraft</gco:CharacterString>
</eos:description>
<eos:dataType>
<eos:EOS_AdditionalAttributeDataTypeCode codeList="http://earthdata.nasa.gov/metadata/resources/Codelists.xml#EOS_AdditionalAttributeDataTypeCode" codeListValue="STRING">STRING</eos:EOS_AdditionalAttributeDataTypeCode>
</eos:dataType>
</eos:EOS_AdditionalAttributeDescription>
</eos:reference>
<eos:value>
<gco:CharacterString>**Actual ID Goes Here**</gco:CharacterString>
</eos:value>
</eos:AdditionalAttribute>
</eos:AdditionalAttributes>

The main question I have with this, however, is how this aircraft ID will be linked with the actual aircraft/platform from the platform section?

  • No labels

13 Comments

  1. Another somewhat related question is regarding campaigns.  Some datasets, particularly for IceBridge, will have multiple campaigns associated with them.  While it's possible that some of these campaigns may use the same airplane/platform with corresponding sensors, it's also possible that a new campaign may use a different airplane (with a different tail number/ID) with the same or different sensors.  How will these be mapped and linked together during ingest, so that the right airplane/aircraftID/sensors are connected?

  2. On behalf of Amanda EarlyWhile I can't speak to ISO directly, the UMM-Common has a Platform/Characteristics field that would allow you to enter an identifier that is directly linked to a specific platform.

  3. I see that section now in the mapping spreadsheet.  I think that place makes sense, and I will get that implemented in the ISO in that spot.  The question then becomes whether we should still be including these ID's as "additional attributes" as shown above?  At this point, I'm guessing no, because the ID's don't really make a lot of sense in that context, as they wouldn't be connected to anything.  However, maybe those attributes are used for searching purposes, in which case it would make sense to have the ID's in both places.

    Or, as I look closer, the "eos:AdditionalAttributes" bit in the above may have been referencing this place to begin with, as that's the ISO place that is mapped to "characteristics".

  4. One thing I noticed about this is, while it does seem to work as expected, it gives a warning:

    "After translating item to UMM-C the metadata had the following issue: /Platforms/0/Characteristics/0 object has missing required properties (["Unit"])"

    In the case of an AircraftID, there really isn't an associated unit.  (In fact, that may be the case for other Characteristics of DataType STRING?)

    It's just a "warning" in the response right now.  If there's something that should be put there instead, I can certainly do so.

  5. I added this example into the Platform thread as well.

    Emily is correct and below is my ISO example that follows the airborne's group recommendations:

    <gmi:platform>
      <eos:EOS_Platform id="Aircraft1">
        <gmi:identifier>
          <gmd:MD_Identifier>
            <gmd:code>
              <!-- The aircraft short name -->
              <gco:CharacterString>B-200</gco:CharacterString>
            </gmd:code>
            <gmd:codeSpace>
              <!-- 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 -->
              <gco:CharacterString>gov.nasa.esdis.umm.platformshortname</gco:CharacterString>
            </gmd:codeSpace>
            <gmd:description>
              <!-- The aircraft long name -->
              <gco:CharacterString>Beechcraft King Air B-200</gco:CharacterString>
            </gmd:description>
          </gmd:MD_Identifier>
        </gmi:identifier>
        <!-- This is UMM Platform Type -->
        <gmi:description>
          <gco:CharacterString>Aircraft</gco:CharacterString>
        </gmi:description>
        <gmi:instrument xlink:href="#Instrument3"/>
        <eos:otherProperty>
          <gco:Record>
            <eos:AdditionalAttributes>
              <eos:AdditionalAttribute>
                <eos:reference>
                  <eos:EOS_AdditionalAttributeDescription>
                    <eos:type>
                      <eos:EOS_AdditionalAttributeTypeCode codeList="https://cdn.earthdata.nasa.gov/iso/resources/Codelist/eosCodelists.xml#EOS_AdditionalAttributeTypeCode" codeListValue="platformInformation">platformInformation</eos:EOS_AdditionalAttributeTypeCode>
                    </eos:type>
                    <eos:name>
                      <gco:CharacterString>Tail Number</gco:CharacterString>
                    </eos:name>
                    <eos:description>
                      <gco:CharacterString>Aircraft Tail Number</gco:CharacterString>
                    </eos:description>
                    <eos:dataType>
                      <eos:EOS_AdditionalAttributeDataTypeCode codeList="https://cdn.earthdata.nasa.gov/iso/resources/Codelist/eosCodelists.xml#EOS_AdditionalAttributeDataTypeCode" codeListValue="string">string</eos:EOS_AdditionalAttributeDataTypeCode>
                    </eos:dataType>
                    <eos:parameterUnitsOfMeasure>
                      <gco:CharacterString>Not Applicable</gco:CharacterString>
                    </eos:parameterUnitsOfMeasure>
                  </eos:EOS_AdditionalAttributeDescription>
                </eos:reference>
                <eos:value>
                  <gco:CharacterString>EER2365876</gco:CharacterString>
                </eos:value>
              </eos:AdditionalAttribute>
            </eos:AdditionalAttributes>
          </gco:Record>
        </eos:otherProperty>
      </eos:EOS_Platform>
    </gmi:platform>

     

    By Placing the additional attributes inside the platform the CMR can associate that the tail number is part of the platform.

    Your second question about campaigns.  I was talking with Jon Pals last year and while I can't find the ticket I wrote, I wrote another  ECSE-189 to document your question.  In the next set of changes to the UMM, I would like to expand on Campaigns to accommodate airborne data.

    Instead of including the aircraft ID in two places, one for searching and the other for associating the tail number with the platform, I wrote a new CMR issue CMR-4058 to include searching on Platform/Characteristics/Value so that the tail number can be searched.  

    You can add the following for items that do not have a unit :

                    <eos:parameterUnitsOfMeasure>
                      <gco:CharacterString>Not Applicable</gco:CharacterString>
                    </eos:parameterUnitsOfMeasure>
  6. Thanks!  I think my bit about campaigns, too, was partly from a misunderstanding on my part as to where this additional characteristic should go; I was putting it in the wrong place, rather than with the platform itself.  But it's good to know that the Platform Characteristics will be searchable to avoid having it put in two places

  7. Erich, just to follow up on a couple things with the AircraftID bit:

    We've been using the attribute name "AircraftID", whereas you have "Tail Number" above.  Theoretically we could change, but talking with Cathy it sounds like the Descriptor Maker expects the attribute to be called "AircraftID". Was the "Tail Number" bit above just an example, or does it need to be that exact term for something on the ingest side?

    Similarly, with the description of the attribute, the example above just says "Aircraft Tail Number", where the description we were going to use was "The identifier of the airplane used by the FAA to uniquely identify each aircraft".  Does it matter which is in that field?  I just want to make sure that it doesn't break ingest or anything.

    1. Hi Scott, The values of "Tail Number" for name and "Aircraft Tail Number" for description was taken from the airborne teams recommendation of what the values should be.  The CMR doesn't care what is in the name or in the description element.  As long as the UMM Platform/Characteristic/Value is indexed and can be searched (CMR-4058), then users can find records by the aircraft's tail number.  I can talk with Jon Pals and Robert Hartranft to see if we can change the value that the descriptor maker looks for if you want to use something different than AircraftID. 

      1. I think we're OK just leaving the Descriptor Maker as-is and continuing to use AircraftID.  I think internally we may already have some things that use that term already, so it would be simpler for us to just use the same term here.

  8. The Descriptor Maker will look for Additional Attributes in the UMM-C representation of the collection metadata and add them to the SDPS Descriptor file.

    The AircraftID shows up in the UMM-C as a Platform Characteristic and so it is ignored by the Descriptor Maker.

    If you want the granule metadata to contain the AircraftID (or TailNumber), then it should be in the Additional Attributes section of the UMM-C or we need to figure out a way to tag Platform characteristics that are additional attributes to separate them from platform characteristics that are not additional attributes.

    1. The problem is, the only way currently to get it to parse from the ISO to the UMM-C's "Additional Attributes" section is by putting it in the ISO in the same section as processing information, which isn't really the place that AircraftID should go.  I made another thread about that issue, and it looks like the mapping spreadsheet indicates that the CMR code may need to be updated to read Additional Attributes from other places in the document for this very reason.

      1. The spreadsheet needs to be updated for AdditionalAttributes.  There are other places in ISO where we need to get information and put it into AdditionalAttributes.

        1. Sounds good.  Just to clarify then (and I think this will address my other topic thread, too), if we have the AircraftID in the platforms as an AdditionalAttribute, we can expect that eventually, the ingest code will be updated so that not only will it populate the Platform stuff, but will also add it to the root AdditionalAttributes section?