Due to the current gap in continued funding from the U.S. National Science Foundation (NSF), the NSF Unidata Program Center has temporarily paused most operations. See NSF Unidata Pause in Most Operations for details.
Due to the current gap in continued funding from the U.S. National Science Foundation (NSF), the NSF Unidata Program Center has temporarily paused most operations. See NSF Unidata Pause in Most Operations for details.
Hi THREDDS people I’m looking for a bit of future certainty/unpicking the relationship between TDS, ncWMS and edal-java. In particular, I need to know if: a. TDS uses edal-java for it’s ncWMS handling b. if so, is TDS using current versions of edal-java Why? Because of the issue raised here: https://github.com/Reading-eScience-Centre/edal-java/issues/69 In short, we have user demand to serve both large, high resolution rasters that suit a scanline read mode, and other data which is happily handled in memory all at once. At present we use two slightly different TDS servers. Ideally we would reduce our management load a bit and serve both from a standardised TDS installation. (realising that I also have a touch of homework to do on the edal-java issue listed above) if there’s a way to clarify the pipeline between ncwms/edal-java changes and incorporation into TDS, it would be great to hear about it. I’m not a java developer by any stretch of the imagination, I dive into the TDS codebase and get thoroughly lost! Thanks, Adam
thredds archives: