radiantearth / stac-browser

A full-fledged UI in Vue for browsing and searching static STAC catalogs and STAC APIs
https://radiantearth.github.io/stac-browser
ISC License
276 stars 138 forks source link

Alternative Map #79

Closed jlaura closed 3 years ago

jlaura commented 3 years ago

Is it possible to use other base maps, perhaps via WMS. Right now, looking at the Catalog, it looks like the baseman is hard coded to use a tiled layer.

https://github.com/radiantearth/stac-browser/blob/6d664e17e88d88fd5165170d06b43e045c34a141/src/components/Catalog.vue#L703

It would be great to be able to use a WMS from a different provider. For example: https://www.arcgis.com/home/webmap/viewer.html?useExisting=1&layers=5dba5970961c4b33a11c1c550d801526 would make it so that our products were shown in the proper context and not in an ocean on Earth. 😄 For the example above, this would be: https://planetarymaps.usgs.gov/cgi-bin/mapserv?map=/maps/earth/moon_simp_cyl.map&service=WMS

I tested this by hard coding the above moon example into the catalog view:

      Leaflet.tileLayer.wms(                                                    
        "https://planetarymaps.usgs.gov/cgi-bin/mapserv?map=/maps/earth/moon_simp_cyl.map",
        {                                                                       
            layers: 'LROC_WAC',                                                 
            crs: Leaflet.CRS.EPSG4326,                                          
            format: 'image/png',                                                
            attribution: 'USGS Astrogeology'                                    
        }                                                                       
      ).addTo(this.locatorMap);  

Lots going on here that might below in the config file? Specifically, (1) swapping to use the WMS, (2) the WMS URL, (3) the CRS because this WMS happens to be using 4326 and not 3857, (4) format, and (5) variable attribution.

The result is:

Screen Shot 2021-05-25 at 1 27 54 PM

Is a change like this something that the sac-browser team would consider? If so, could we possibly discuss and I can attempt a PR.

Additionally, the aspect ratio on the map is really weird - I suspect someplace else in the library is making some radius assumptions to compute the bounding box that gets passed to the WMS call?

m-mohr commented 3 years ago

I'd consider this for the rewrite I'm currently starting (i.e. STAC Browser 3.0) and would be happy to accept a PR once I have a solid architecture and the basics ready (in 1 or 2 months or so). Your help would be appreciated as I have no clue about non-Earth coding. ;-) Is there a way to distinguish the planets in STAC? Then we could also "hardcode" support for more planets.

Until then you have to stick to change the STAC Browser source code yourself, I can't consider PRs for 2.0 or 1.0 due to time constraints.

jlaura commented 3 years ago

@m-mohr Sounds great. I am happy to contribute.

Is there a way to distinguish the planets in STAC?

We are working on a planetary extension that adds a target field where the body can be identified. The extension will include a target field that could be parsed.

Then we could also "hardcode" support for more planets.

This might be tricky? Here is a listing of the WMS bases that we serve. Lots (and lots!) of different bodies that we have data for. Obviously, it is not all ready for STAC yet, so maybe I can put in a PR (when 3.0 is ready) that includes support for Moon, Mars ,and Europa. Then I could incrementally add. The code would end up with a big old switch statement, but that might be preferable to something this is more configurable?

I'll keep at modifying stac-browser for now. Very cool project and I very much appreciate your work getting it out there and keeping it current. It is really nice for us to be able to demo stac so quickly to our user base because of this project.

m-mohr commented 3 years ago

Thanks, that all sounds very good to me, also with the extension. I'll keep you updated through this issue once there's something new.

m-mohr commented 3 years ago

I just ran into this: https://github.com/thareUSGS/ssys - Are you aware of this extension, @jlaura ?

jlaura commented 3 years ago

@m-mohr Apologies, I've been on PTO. thareUSGS and I work together at USGS. We are working to get that extension in and then we can leverage it in the 3.0.0 update to have the case statement working.

jlaura commented 3 years ago

Looks like V3 is getting along really nicely. I see that the components/Map.vue is encapsulating the map logic. Looking at the vue2-leaflet docs, it looks like I should be able to get WMS layers added into there.

The syss extension is available in @thareUSGS 's home area, and we are working on getting it in to the main stac-extensions area.

Is a PR modifying the Map.vue component the place to make the change? I am thinking that the logic should be to look at the catalog/collection. If the ssys extension exists, check the first element of the target array (sometimes spacecraft image 2 bodies simultaneously) and use the appropriate WMS for that target. If the extensions does not exist, use the open street map as currently coded.

Thoughts and concerns?

m-mohr commented 3 years ago

Hi jlaura,

sounds good so with regards to the WMS.

We are in the process of also getting a stac-layer extension for Leaflet, which we'll be using in STAC Browser. I'm not 100% sure how that relates to each other and whether there could be any issues. How do bboxes/geometries work for non-Earth data? Anyway, I think a PR would be a great contribution. We can check later whether there are any conflicts with the new stac-layer plugin.

Be aware that v3 is still in alpha state and many things will still change or may not work...

jlaura commented 3 years ago

@m-mohr :+1: BBoxes, geometries, etc. are the same as for terrestrial.

A bit of weirdness is introduced when planetary sometimes wants to be in a 0-360 domain (as opposed to the standard -180 to 180 domain). The domain change is not something that I think STAC browser can or should worry about. The difference shows itself at the stac spec level, when using leaflet/open layers, in the FGDC metadata standard, etc. So something to think about and discuss in different venues that might some day percolate into stac browser.

m-mohr commented 3 years ago

Sounds good. Looking forward to your PR!

thareUSGS commented 3 years ago

Note - our planetary WMS services always try to support -180 to 360 to allow interoperability across as many clients/domains as possible. Thus supporting -180 to 180 for STAC browser should already work.

Just FYI - technically we simply do this with using a GDAL VRT (to virtually wrap 180 degrees of data without the need to support 540 degrees of data on disk). For more locked-in tiled WMS services we tend to support -180 to 180 by default. We also still abuse EPSG:4326 code for our planetary WMSs to generically support more clients (fortunately, using degrees cautiously works across bodies). We have been working on the EPSG (Earth-centric) issue for years and we should see updates this year to PROJ/GDAL to help with our "planetary" (non-EPSG) codes.

jlaura commented 3 years ago

I have opened a PR (#88) with an example of a planetary base map hacked in v3.0.0. I would love feedback on that - it is not a workable solution yet.

m-mohr commented 3 years ago

Will be part of STAC Browser v3