add modis_sinusoidal as a horizCoordSysName option

[srearl]

Requesting the addition of modis_sinusoidal as a horizCoordSysName option. Please see #352 for details. I am just taking a stab at naming this particular projection so am open to suggestions.

[mbjones]

This looks good, @srearl. Thanks!

• can you elaborate why you chose the name you did, particularly not following the capitalization conventions of the rest of the names in the list?
• you need a corresponding definition in https://github.com/NCEAS/eml/blob/master/eml-spatialReferenceDictionary.xml before we can merge this.
• while I find the projection on Spatial Reference as SR-ORG:6842, the corresponding code on EPSG.io (EPSG:6842) seems to be a different projection. Any idea why they use the same code?

[srearl]

Hi @mbjones,

Thank you for having a look at my request.

My understanding is that this is a customized projection and, thus, does not have a epsg number, and, yes, that the sr-org number overlaps with epsg 6842 is confusing and unfortunate.

Using snake case was an oversight on my part, and I will change that to title case with an underscore in a revised pull request. First, though, let me run by you a draft spatialReferenceDictionary entry.

reference:

PROJCS["Sinusoidal",
    GEOGCS["GCS_Undefined",
        DATUM["Undefined",
            SPHEROID["User_Defined_Spheroid",6371007.181,0.0]],
        PRIMEM["Greenwich",0.0],
        UNIT["Degree",0.0174532925199433]],
    PROJECTION["Sinusoidal"],
    PARAMETER["False_Easting",0.0],
    PARAMETER["False_Northing",0.0],
    PARAMETER["Central_Meridian",0.0],
    UNIT["Meter",1.0]]

<horizCoordSysDef name="Modis_Sinusoidal">
  <projCoordSys>
    <geogCoordSys name="GCS_Undefined">
      <datum name="Undefined"/>
      <spheroid name="User_Defined_Spheroid" semiAxisMajor="6371007.181"/>
      <primeMeridian name="Greenwich" longitude="0"/>
      <unit name="degree"/>
    </geogCoordSys>
    <projection name="Sinusoidal">
      <parameter name="False_Easting" value="0"/>
      <parameter name="False_Northing" value="0"/>
      <parameter name="Central_Meridian" value="0"/>
      <unit name="meter" value="1"/>
    </projection>
  </projCoordSys>
</horizCoordSysDef>

Not sure about the denomFlatRatio attribute of the spheroid name element - I guess that could be the 0.0 after 6371007.181, which I assume is the semiAxisMajor attribute, but I am not certain so have omitted it.

[mbjones]

@srearl looks good, but we do need to resolve the denomFlatRatio issue.

@brunj7 could you take a look at this and verify the proposed horizCoordSysDef is correct, and whether @srearl has the right idea for denomFlatRatio? Thanks. Anyone else with geospatial background that wants to review and comment, please do so, we could use the input.

[srearl]

thank you @metamattj and @brunj7 - I can ask the geospatial folks here at ASU about that denomFlatRatio attribute as well, but do folks know to what that refers, is there a more human-understandable translation of that that particular property?

[brunj7]

Hi @mbjones and @srearl ,

I do not think there is an EPSG code for MODIS Sinusoidal projection. It is mainly a system for NASA to tile the data. From my experience, you generally reproject the data into another projection system when analyzing it.

This is the most detailed description of this projection I could find:
https://modis-land.gsfc.nasa.gov/GCTP.html

It does not match the sinusoidal systems in EPSG:

• http://epsg.io/53008
• http://epsg.io/54008

Note that the term MODIS Sinusoidal is referring to 3 different projection systems:
https://spatialreference.org/ref/?search=MODIS

It is mentioned that the two versions with higher reference numbers are attempting to "correct" the original: https://spatialreference.org/ref/sr-org/modis-sinusoidal/ (which matches the definition on the above MODIS webpage). The two newer ones refer to a WGS84 ellipsoid instead of the custom one using parameters semi-major and semi-minor to customize it to the MODIS sinusoidal one.

I think my recommendation will be to use SR-ORG:6974's definition to write the EML projection definition as you will be able to point to defined Ellipsoid and Datum and their EPSG codes
https://spatialreference.org/ref/sr-org/modis-sinusoidal-3/html/

Hope it helps!

[srearl]

@brunj7 - thanks very much for your input on this issue. I had not thought about the fact that modis sinusoidal can refer to the three different projection systems that you highlighted. In fact, the investigator did not specify one of the three, having indicated only modis sinusoidal.

However, regarding your suggestion to use SR-ORG:6974, the CRS of the data (as indicated by the provider and detailed when loaded into a GIS system) is CRS (+proj=sinu +lon_0=0 +x_0=0 +y_0=0 +a=6371007.181 +b=6371007.181 +units=m +no_defs). That CRS corresponds to the PRJ of SR-ORG:6842, our problem child, and, unfortunately, not to the more well described PRJ of SR-ORG:6974 that you sugggest. Those could be functionally equivalent but as I have no idea, I am a bit hesitant to call these SR-ORG:6974. I am trying to get the investigator to weigh in also.

Reprojecting is a possibility but not ideal as the investigator indicated that that can cause pixel values to change in the function of the resampling method. Plus, a lot of folks use MODIS data so this really seems like something we should nail down.

[mbjones]

That denomFlatRatio attribute comes from eml-spatialReference.xsd, but I see that it is not properly defined in the schema. See https://github.com/NCEAS/eml/blob/master/xsd/eml-spatialReference.xsd#L2343 We need to remedy that.

However, all of these structures were derived from a combination of early draft releases of ISO 19115 and FGDC concepts, and so within ISO, they defined the field as:

• MD_EllipsoidParameters:denominatorOfFlatteningRatio (denFlatRat)
  • radius of the equatorial axis of the ellipsoid denominator of the ratio of the difference between the equatorial and polar radii of the ellipsoid when the numerator is set to 1

MD_EllipsoidParameters has been superseded, as newer versions of ISO 19115 defer to ISO 19111/OGC 18-005r4 (Spatial referencing by coordinates) to define these ellipsoid parameters, which is now done usingCD_SecondDefiningParameter (see table 55 of the OGC spec).

We should likely update EML's documentation to both define these fields and establish the relationship to corresponding concepts in ISO 19111.

[srearl]

@mbjones - Just FYI, I wrote to the MODIS team at NASA to get some clarification about that denomFlatRatio attribute for the sinusoidal projection. Sounds like they may be able to help but are all at AGU this week so will have to wait a bit. I will leave the pull request open and update when they respond.

Regarding your more general comments, it seems that attention to geospatial data/metadata within LTER has waned since Theresa retired. I document a lot of geospatial data at CAP and, while not my area of expertise, am happy to discuss how we might put more attention and effort toward addressing some of the issues you raise.

cc @brunj7

[rewolfe]

Hi, I just joined this conversation by way of an email from @srearl

Some of the confusion in the MODIS sinusoidal projection comes from the fact that the sinusoidal projection is only defined for a sphere (see https://en.wikipedia.org/wiki/Sinusoidal_projection). This means that the standard ellipsoid semi-major/semi-minor axis (and flattening factor) is not applicable. However, there are various ways of using auxiliary latitudes (see https://en.wikipedia.org/wiki/Latitude#Auxiliary_latitudes) to convert from a reference like WGS 84 (or GRS 80) datum to a spherical projection. However, most projection packages don't support auxiliary latitudes and I don't think that EPSG supports this concept, or at least it didn't 20 years ago when we were defining the parameters for the MODIS sinusoidal projection.

What we did may be unconventional, because at the time I was not aware of any similar work. We computed the radius of a sphere with a surface area that was the same area as the WGS 84 ellipsoid and used this radius as the single radius (6371007.181 m) in the projection. We then used the WGS 84 geodetic latitude directly as an auxiliary latitude (projection_latitude == geodetic_latitude). We documented this and (naively?) thought that our end-users would do the same when converting from the latitude from the sinusoidal projection back to geodetic latitude. Notice, the radius I choose has two more digits of precision than the authalic (equal area) radius defined here: https://en.wikipedia.org/wiki/Earth_radius (6371007.2 m), but it the same as the IUGG 'radius of sphere of same surface (R2)' in the table (6371007.1810 m, note one more digit of precision).

Note that this is similar to as for users who use geographic (equi-rectangular, plate carree, etc.) or other spherical projections (https://en.wikipedia.org/wiki/Equirectangular_projection). Note that the convention for the radius R in those projections varies as described in the Wikipedia reference above.

I hope that this helps with this discussion.

[srearl]

@mbjones - updated PR with a few notes:

• I changed the proposed name to Sinusoidal as Modis_Sinusoidal seems more appropriate to document SR-ORG 6974 and 6965 in the future.
• Updated the geogCoordSys to include the degree value.
• denomFlatRatio is optional, and not included.
• Though, per @rewolfe 's comments, semiAxisMajor is not applicable to this projection, I think it is the only option available for documenting the radius so have included it.
• It would be helpful here, and for the other two projections noted above (SR-ORG 6974 & 6965), if we could add a reference to the SR-ORG identifier but I do not see a way to do that.

[srearl]

Hi @mbjones - Any thoughts on this PR, I am not comfortable merging without your review?

[mbjones]

While in general this looks good to me, I don't have sufficient background in projections to really vet it. If you feel that you've done due diligence and this would be helpful to the EML community, then I am supportive.

We should not merge this to master, which contains the current 2.2.0 release. Instead, we should merge it in the targeted branch for the next release. We haven't discussed what that release would be or its objectives. This addition should be completely backwards compatible, so it could go in either a 2.2.1 patch release, or more likely a 2.3.0 release. Frequent releases are a maintenance problem for sites, so we should strategically discuss how to best handle this and whether this patch can sit while we wait for other changes to accrue. Do you want to get this out right away?

One other thing we could consider would be to externalize the vocabulary of projections so that it is independently maintainable outside of EML releases. That would allow new CRS entries to be added without a new release of EML. Something to consider.

[srearl]

Thanks for reviewing this @mbjones. One concern is the ability to distinguish the same or similarly named user-defined projections using the structure in the spatialReferenceDictionary. For example, as @brunj7 had pointed out, there are three MODIS Sinusoidal projections (6842 is the one of interest here). It would seem valuable, critical really, to be able to distinguish those in the dictionary with a unique name and, ideally, to reference their respective SR-ORG identifier. In fact, it would be helpful to reference the SR-ORG identifier even when there are not multiple, similarly named references. It is not clear how to do that.

I have had to punt on the issue for the dataset that started this (by describing the rasters with otherEntity instead of spatialRaster) but MODIS data are really quite common so it seems that this would be a helpful addition for the community. Thoughts welcome, and I am happy to revise the PR and point it to the appropriate branch or to table it for the time being.