Serving data in the geostationary projection

[djhoese]

I'd like to use OnEarth to serve some geostationary imagery data that I have as a WMTS service. It may not necessarily go in to WorldView. I've been reading through the OnEarth documentation and code and it seems like all the parts dealing with projections use EPSG codes. If I want to serve the GOES-16 ABI Full Disk, +proj=geos and not an EPSG projection as far as I know, is there any way I can do this with OnEarth?

If the current code can't handle it, what would need to be changed to make it work? Would the OnEarth team be open to me contributing these changes?

[jtroberts]

It should be possible in OnEarth with a few tweaks. I think there are places in the code that expect to parse an explicit EPSG code, but the software should be able to support a proj.4 declaration as well. This would involve scanning the Python scripts and making some updates. We're certainly open to you contributing the changes and willing to assist.

There are a few things that you would also need to configure:

1) OnEarth uses MRF for its file archive format. The imagery would all need to be generated using the geostationary projection.

2) New projection configurations (for OnEarth 1.x) need to be added to the "projections.xml" file: https://github.com/nasa-gibs/onearth/blob/master/src/layer_config/conf/projection.xml

3) TileMatrixSets need to be defined for the new projection: https://github.com/nasa-gibs/onearth/blob/master/src/layer_config/conf/tilematrixsets.xml

I might be missing another step, but these are the main items. Note that the configuration files will be a bit different in OnEarth 2.x.

[djhoese]

Thanks for the info. I'm not super familiar with the MRF format. Is it generic enough that it should accept any projection? What version of GDAL is OnEarth compatible with? One thing that was a problem with GOES-R ABI data when it was first being produced was the introduction of a +sweep parameter which required modifications to PROJ/GDAL. These changes have been in these libraries for a while now, but even the GeoTIFF specification doesn't have actual handling of this parameter (GDAL has a workaround for this).

[jtroberts]

MRF is part of the GDAL library (https://gdal.org/drivers/raster/marfa.html), so it should accept any projection that GDAL supports. There is a detailed user guide here: https://github.com/nasa-gibs/mrf/blob/master/doc/MUG.md

Recent versions of OnEarth are compatible with GDAL versions >= 2.1. Older versions work as well, but you would need to build GDAL with a separate MRF driver (https://github.com/nasa-gibs/mrf/tree/1.1.3/src/gdal_mrf/frmts/mrf). We generally build our own GDAL packages (https://github.com/nasa-gibs/mrf/releases) that include additional helper tools for MRF (https://github.com/nasa-gibs/mrf/tree/master/mrf_apps).

With all that said, I'm not familiar with the +sweep parameter and whether or not that is handled. It could be the case that the same workaround is needed. Is there a good place to find more information about that parameter?

[djhoese]

https://proj.org/operations/projections/geos.html#note-on-sweep-angle

The GOES-R ABI instruments use the non-default sweep angle where satellite instruments like Himawari-8 AHI use the default. So AHI never really had the format/projection issues that ABI did.

[lucianpls]

Is this a one-time image or do you want to have an updating service? If you only do a one time, you could skip most of the OnEarth ingest and the projection in the MRF is not even required. The only issue would be how to set up WMTS to expose the projection, I'm not sure what works there. Alternatively, you can use GDAL to reproject the input to a standard projection like GCS or WebMercator, and then use a GL web planet viewer to explore it on a sphere. See https://earthlive.maptiles.arcgis.com for an example

[djhoese]

This will be an updating service with older images being deleted over time. My goal is to avoid resampling for performance reasons but also to avoid resampling artifacts and present the data in its original projection.

[jtroberts]

@djhoese were you able to find a solution to your issue? Closing this issue for now, but can reopen if there are more things to discuss.

[djhoese]

Sorry. I forgot this was still open. I ended up using MapServer and MapCache for my WMS and WMTS services. I did this mostly because of how much "hacking" seemed possible with these services for the tasks I needed to accomplish. One of these "hacks" was adding fake EPSG codes to the PROJ C libraries database of EPSG codes for the geostationary projections I needed to use (EPSG:930916 for GOES-16, EPSG:930917 for GOES-17). This overall seemed easiest out of all the options I researched.

Thanks for your help anyway.