[IDV #IMF-703813]: imageserver

["Unidata IDV Support" <support-idv@xxxxxxxxxxxxxxxx>]

Hi Reinoud,


> Sorry for the late reply, I just returned from my summer holidays.
And sorry for my late reply as well.

Backend image generation is something we are working on in the context of Unidata's new data repository effort RAMADDA:
http://www.unidata.ucar.edu/software/ramadda/

RAMADDA is a general purpose data repository and server. It provides for a variety of upload capabilities (web page, web api, file scanning) and a variety of services - html interface, thredds catalogs, rss feeds, search, etc. It also has an embedded thredds tds opendap service.

We have just started exploring the use of the IDV for image generation.
The approach is to have the servlet instantiate an IDV (so you don't get hit with Java start up costs).
It uses the IDV Scriping Language (ISL) to define what is to be captured.
More comments below.

> 
> As I described earlier I am most interested in using IDV as a backend image generator for our Web Mapping Services. Together with THREDDS for data access this could be a powerfull combination. I work mainly with atmospheric and oceanographical data and until now I have failed to find a good tool to do just that. My general requirements to such a tool are (those I can think of right now, in random order):
> 
> 1. able to run without a display
No problem.

> 2. provides a library to be able to use it efficiently in a web-application or can be run continously as a server (as opposed to having to execute an external program for each request)
> 3. fast / short startup time (related to point 2)
Since it runs in Tomcat the IDV is just created once. 

> 4. must be able to generate an image in common web formats like jpeg, gif or png (many scientific plotting tools just output PostScript which is useless for a web application)
The IDV can capture various image formats, animated gifs, quicktime, avi, google earth kmz files and most recentl pdf, svg and ps.

> 5. output image width and height can be specified
This is done in the isl script.

> 6. Page filling plots can be generated (i.e. no borders, margins and axes).
Actually, that's all we ever capture. The isl can then modify the image, matteing it, labeling it, etc.

> 7. provides common operations like drawing contours (shaded and non-shaded), vectors, automatic decluttering the plots (for example vestor density), etc.
The IDV does all that.

> 8. reads at least NetCDF-CF and GRIB (1/2) data.
No problem.

> 9. supports different map projections
No problem.

> (10. for WMS's it would be nice to be able to generate a legend image separately, f.ex. a color scalebar, and/or being able to embed it inside the plot)
Right now we don't generate other imagery. Color scale bars are shown right in the plot.


> 
> An API-like approach would work best for me (assuming you are not going to implement a WMS interface in the imageserver) and is most flexible for other purposes. I would use the API in a script that translates WMS parameters to IDV commands, presumably in a Java/Tomcat environment. I guess that the imageserver could still be usefull to simply publish an auto-generated image on a website but I am currently not using it that way.
> 


Yes, that would be the best approach. As I said in a previous email we were planning on pushing on this effort this summer. But, I haven't gotten to it yet. Give me a month or so to get some things working better. There are a few things that need to be done to support WMS.  I will get back in touch with you this later this Fall.

-Jeff


Ticket Details
===================
Ticket ID: IMF-703813
Department: Support IDV
Priority: Normal
Status: Open