Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Coverage representation in HTML #14

Closed
pebau opened this issue Apr 15, 2019 · 11 comments
Closed

Coverage representation in HTML #14

pebau opened this issue Apr 15, 2019 · 11 comments

Comments

@pebau
Copy link
Contributor

pebau commented Apr 15, 2019

Currently discussion of HTML seems to mostly concentrate on encoding coverage metadata in HTML, ie: not the range set. If we talk about encoding a complete coverage we need to establish an HTML encoding including the range set. (Sometimes an image can be rendered: if the coverage is 2D and contains 1 or 3 integer bands.)

@Schpidi
Copy link
Member

Schpidi commented Apr 26, 2019

Teleconference 20190426: It's agreed that HTML is not a suitable format for coverage's range set.

@pebau
Copy link
Contributor Author

pebau commented Apr 26, 2019

Here is a sample HTML frontend for coverages, is that what you have in mind with an HTML delivery?
http://ows.rasdaman.org/rasdaman/wcs-client/index.html

@pvgenuchten
Copy link

when noticing this discussion, i wondered if the use case "browsing the api through a browser" has been considered. To me it makes sense to have a html representation for any api-level, with option to drill down to lower levels. I agree that representing actual pixel values as a html-table may not be very sensible, but one level up would make sense to have a html page with links to the actual grids as image

@nmtoken
Copy link

nmtoken commented May 13, 2019

one level up would make sense to have a html page with links to the actual grids as image

That assumes that the coverage is 2D and a grid and/or can be represented as a 2D image, and that isn't true for all coverages.

I think there would be an issue too for very large coverages, you'd want some sub-setting, or scaling operations rather than the whole coverage.

I was thinking that by links you meant like <img src...> or <a href...> but I can see that an HTML form that allowed users to select options to create a query to get a coverage as an image, where it was possible, would also be a link.

@pebau
Copy link
Contributor Author

pebau commented May 13, 2019

this reminds me of WCPS which could be typed into a form, or as part of a prefabricated link. Here is a demo (select a query from the bottom of the page, then press "execute"):
http://earthlook.eecs.jacobs-university.de/new_earthlook/index.html?page=demo-apps&?group=geo-service-standard&app=wcps

@cmheazel
Copy link
Contributor

@pvgenuchten One possibility would be an HTML page (or pages) for the collection a thumbnail for each coverage. Only works for 2-D images, but it is a common approach we should consider.

@Schpidi
Copy link
Member

Schpidi commented May 22, 2019

The design overview of STAC says: "An important core principle of the STAC design is to embrace best practices of making data available on the web (like HATEOAS ...". I find this quite interesting.

@pebau
Copy link
Contributor Author

pebau commented May 22, 2019

who decides when a practice is best? ;-)
If we do an HTML encoding we might just translate the XML schema into HTML, a low-hanging fruit (except that HTML has no schema / has a frozen schema). So a coverage would become an HTML snippet which can be embedded anywhere (and styled).

@Schpidi Schpidi added this to Hackathon in Core release Jun 17, 2019
@Schpidi Schpidi added this to Backlog in Core release Nov 27, 2019
@cmheazel
Copy link
Contributor

Current version (12/30/19) treats the range set (pixels) different from the other content.
Since the Range Set is usually binary data, we can expect most APIs to deliver range set data in a binary format. Everything else can be delivered in HTML. For combined deliveries, a multi-part mime-type can be used to combine the binary data with HTML. All of which is supported by HTTP content negotiation.

@pebau
Copy link
Contributor Author

pebau commented Jan 2, 2020

Can you please point us to where exactly that different behavior is specified?

@Schpidi
Copy link
Member

Schpidi commented Jul 8, 2020

#13 (comment)

@Schpidi Schpidi closed this as completed Jul 8, 2020
Core release automation moved this from Backlog to Done Jul 8, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Core release
  
Done
Development

No branches or pull requests

5 participants