Closed jlaura closed 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.
@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.
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.
I just ran into this: https://github.com/thareUSGS/ssys - Are you aware of this extension, @jlaura ?
@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.
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?
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...
@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.
Sounds good. Looking forward to your PR!
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.
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.
Will be part of STAC Browser v3
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:
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:
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?