Add other viewers from components

[severo]

Currently only the MapViewer is used.

We can use:

• the text viewer
• the table viewer (for CSV)
• the markdown viewer (already handled for README, let's merge some code)

[yharby]

I can work on that ... implement duckdb-wasm to quickly visualize CSV, Prquet .. other supported formats of duckdb spatial and wasm
It will work on client side, no backend for now

[severo]

Good ideas.

The scope of this issue is narrower for two reasons:

1. it aims at using on source.coop the four viewer components already developed in https://github.com/source-cooperative/components/tree/main/packages/components (showcased here: https://source-cooperative.github.io/components/viewers/ and used here: https://viewers.source.coop/)
2. beyond this issue, our goal on source.coop is to show a quick preview of the contents of any file, without many features. That's why, for example, we don't plan to rely on duckdb-wasm but on hyparquet (and maybe hightable) for parquet files. See Create a GeoParquet viewer components#45. Adding viewers or improving the existing ones will be done for now at https://github.com/source-cooperative/components. Feel free to review the issues there if you want to start contributing!

[jedsundwall]

@severo curious to get your opinion on @bdon's approach in #125. I discussed this with @alukach today and he and I agree that there's something elegant about having the viewer be entirely separate and shown via an iframe. This particularly makes sense in the case of PMTiles which benefits from having a sophisticated viewer maintained by its owner. It might not make as much sense for a simple CSV viewer. I defer to you on the approach you'd like to take for Parquet, GeoParquet, or other viewers you'd like to work on.

One nice thing about @bdon's approach is that pmtiles.io is simply a GitHub page, hosted entirely for free.

[severo]

Indeed, this approach has advantages:

• decouple development/maintenance between the platform and the viewer, making it easier to have somebody focus on a specific viewer (no need to install and run the source.coop platform). It think it's a very important point.
• the viewer can be used as a standalone app too
• as we focus on cloud native formats, the source.coop platform does not provide any backend preprocessing of the data, so: the viewer has no particular reason to live in the same codebase. Ideally, it only needs the data file URL.
• as the viewer hosting is independent/decoupled from source.coop, you can opt for a more adapted hosting (like github pages for pmtiles.io), reducing the load and traffic on the main hosting.

Some drawbacks:

• UI styling might be harder to harmonize
• it's not always easy to communicate between the parent window and the child iframe (we have to use messages). But I'm not sure the product page and the viewer really need to exchange data: the interactivity (zoom/pan for maps, filter/sort for table) will possibly only be handled by the viewer.
• sizing is not always easy to handle, in particular if the iframe must resize itself automatically
• if the iframe has to access protected resources, passing credentials might be complex
• another deployment and hosting platform to handle / monitor / maintain / scale

Overall, I agree it's a good solution, and I will propose the same for the Parquet table viewer, because I think we should use the same approach for all the viewers, for consistency and simplicity (even if some viewers will be simpler than others).

[bdon]

UI styling might be harder to harmonize

In the specific case of the PMTiles viewer, since I maintain the viewer I can add more Source-friendly branding when the ?iframe=true mode is used.

if the iframe has to access protected resources

The way I implemented it is that it uses the data URL in the Source product. This only works because of the existing CORS headers in the Source public HTTP server. If in the future those URLs come from outside Source, it would rely on CORS working for the domain embedded in the iframe.

+1 to all the advantages @severo mentioned

[bdon]

I'd also propose building a COG Viewer for Source that lives inside an iframe:

• replace https://cogeo.org/map/ (relies on tiles.rdnt.io lambda)
• use https://github.com/geomatico/maplibre-cog-protocol so the user experience / basemap is similar to the PMTiles viewer

I think this new viewer should be in either the https://github.com/cogeotiff or http://github.com/source-cooperative GitHub orgs.

Potential complexity:

• non-RGB COGs - how to default visualize?
• What about polar / antimeridian crossing COGs?
• Reject GeoTIFFs that are not COGs?
• Overlap with existing viewers at http://labs.geomatico.es/maplibre-cog-protocol/ and https://geotiffjs.github.io/cog-explorer/ ?

[jedsundwall]

@bdon what about a smart TIFF viewer that displays TIFFs whenever possible and the display changes based on what kind of TIFF it is?

Some scenarios:

• if the TIFF is over a certain size and doesn't contain overviews, it probably just displays metadata
• if the TIFF contains overviews, it displays an overview? ¯_(ツ)_/¯
• if it's a COG, it shows the TIFF on a basemap
• I imagine there are other kinds of TIFF

Actually, now that I think about it, what if we just make this a raster viewer and it displays all kinds of imagery files (TIFF, COG, PNG, JPG, etc)?

Given that I don't think this should be just a COG thing, I'd vote for this to live within http://github.com/source-cooperative

[bdon]

Can we quantify how many non-COG rasters there are on Source right now? If it's a very small % maybe it's not worth maintaining a viewer for those cases?

Otherwise if we do want to do that, we would need a standalone iframe-able page that:

• sniffs the bits from the front of the file to determine if it's a TIFF, PNG, JPEG, etc
• If it's a PNG/JPG display it using an <img> tag
• If it's a TIFF sniff it for being a COG with geotiff.js
• If it is a COG, show an interactive map component with the COG overlaid
• If it's not a COG (do something with geotiff.js)

[cholmes]

+1 for COG viewer. We've got lots in https://source.coop/kerner-lab/fields-of-the-world that would be great to display. I think they're all COG's.

[bdon]

I spiked on a throwaway implementation of a fully client-side COG viewer, it's live now at https://cogeo.org/viewer

View a COG by using the hash #url=https://example.com/example.tif

example: https://cogeo.org/viewer/#url=https://sentinel-cogs.s3.us-west-2.amazonaws.com/sentinel-s2-l2a-cogs/36/Q/WD/2020/7/S2A_36QWD_20200701_0_L2A/TCI.tif

I think we ought to integrate this into Source ASAP via an iframe so we can discover where it breaks for the kinds of files on Source.