Smoothed contours - Githubissues

guygriffiths commented 9 years ago

Currently all contours pick up the grid cells of the data. Having smooth contours would be good. This may require using a different library or interpolating the data, but it's not a straightforward issue.

guygriffiths commented 8 years ago

This is only really possible if we start doing interpolation whilst reading the data onto the map grid (instead of taking a nearest-neighbour approach). That's a pretty big change which will have effects throughout EDAL, and no-one's actually requested it. Probably best to leave this one, but I'll leave it open for future possibilities...

acrosby commented 7 years ago

This is mentioned here as well, https://github.com/Reading-eScience-Centre/ncwms/issues/10

docgregt commented 5 years ago

@guygriffiths , I really need smooth contours for drawing Isobaric charts (Pressure contours). I do not write Java code, but I do write c# and Python. Python is quite good at this kind of rendering and it can be called from java, so I could write the code. I know it is a crazy idea, but I don't have any other way to get contours.

guygriffiths commented 5 years ago

I think the problem with calling python from Java is that you either need to use Jython (which does not support numpy, scipy, matplotlib, etc, because they are all C libraries with a python wrapper), or you need to call a separate interpreter (which would add a large dependency to ncWMS, and one which is platform dependent).

The main issue is that the data is extracted onto the image grid prior to rendering, and then passed to an individual renderer. So a renderer is not receiving data of the form:

and then scaling it up (which we could do by interpolation, and then plot a smooth contour across), but is rather receiving something like:

00000000000000000000
00000000000000000000
00000000000000000000
00000000000000000000
00000000000011111111
00000000000011111111
00000000000011111111
00000000000011111111
00000000111111111111
00000000111111111111
00000000111111111111
00000000111111111111
00000000111111111111
00000000111111111111
00000000111111111111
00000000111111111111
00001111111111111111
00001111111111111111
00001111111111111111
00001111111111111111

The upshot is that even with a smooth contouring algorithm, there is no reliable way to determine if an image should be jagged (because the data is), or should be smooth (because it is zoomed in). To make things even more complex, the renderer only receives a single tile at a time, and so must render the data independently of neighbouring tiles, which makes proper smoothing very difficult (impossible?) to achieve.

As ugly as the non-smoothed contours are, they are at least a true representation of the data. If you zoom out to such an extent that the data is not pixelated, the contours are smooth.

jonblower commented 5 years ago

Yes, @guygriffiths' analysis is right. The jagged edges are representing the underlying grid: ncWMS deliberately does not do any sub-gridscale interpolation because this would result in a less faithful representation of the underlying data.

However, I can see an argument for smoothing the data purely for the purposes of creating contour plots. Maybe the jagged field could be smoothed by using a linear or bicubic interpolation before the contour algorithm is applied, thereby creating a "smoothedcontours" style perhaps.

The problem of lining contours up across tiles would remain - there are solutions for this (like using a gutter in the tiling algorithm) but the easiest way to avoid this for now is to request whole images rather than tiles.

docgregt commented 5 years ago

I always request whole images anyway. Maybe a whole image contouring algorithm for those willing to accept whole images.

Get Outlook for Androidhttps://aka.ms/ghei36

From: Jon Blower notifications@github.com Sent: Friday, March 22, 2019 5:05:26 AM To: Reading-eScience-Centre/edal-java Cc: Greg Turner; Comment Subject: Re: [Reading-eScience-Centre/edal-java] Smoothed contours (#12)

Yes, @guygriffithshttps://github.com/guygriffiths' analysis is right. The jagged edges are representing the underlying grid: ncWMS deliberately does not do any sub-gridscale interpolation because this would result in a less faithful representation of the underlying data.

However, I can see an argument for smoothing the data purely for the purposes of creating contour plots. Maybe the jagged field could be smoothed by using a linear or bicubic interpolation before the contour algorithm is applied, thereby creating a "smoothedcontours" style perhaps.

The problem of lining contours up across tiles would remain - there are solutions for this (like using a gutter in the tiling algorithm) but the easiest way to avoid this for now is to request whole images rather than tiles.

— You are receiving this because you commented. Reply to this email directly, view it on GitHubhttps://github.com/Reading-eScience-Centre/edal-java/issues/12#issuecomment-475561761, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ApVpHwdp3kXSm822e2Wiwc1mtW1aIxf6ks5vZKrmgaJpZM4Frr95.

docgregt commented 5 years ago

I did say calling python was a crazy idea. Cython is not totally out of the picture as this discussion shows: https://stackoverflow.com/questions/8898765/calling-python-in-java And yes it would be annoying but from what I know all linux systems have python3 built in or pre-installed and loading the python libs needed is a simple pip install -r requirements.txt. Actually, is much easier dependency than the dependency on something like tomcat. I hear what you @jonblower are saying about accuracy, but I doubt a drawing like this: is accurate. But also is draw lines around a cell accurate?

In any case I can try to tool up something this weekend if someone can point me in the right direction. What tools do you use for development of ncWMS and where at in the code should the new algorithm be written?

guygriffiths commented 5 years ago

Adding a dependency on python is definitely not a road we want to go down.

More importantly, it simply isn't a case of writing a new plotting algorithm - our contour algorithm already plots smooth contours when it is given smooth data - it will require code to allow drawing layers to request interpolated data from the FeatureCatalogue (https://github.com/Reading-eScience-Centre/edal-java/blob/master/graphics/src/main/java/uk/ac/rdg/resc/edal/graphics/utils/FeatureCatalogue.java).

At the very least, it would require:

Adding an additional getFeaturesForLayer method to FeatureCatalogue with a flag requesting that features are interpolated (and perhaps an interpolation method)
Implementing that method in all necessary classes, which will have knock-on effects on data reading code. This will require different methods of reading data depending on whether or not the plotting domain is larger than the data domain.
Making sure that https://github.com/Reading-eScience-Centre/edal-java/blob/master/graphics/src/main/java/uk/ac/rdg/resc/edal/graphics/style/ContourLayer.java now uses this new method. That will require adding new methods to GriddedImageLayer since ContourLayer never directly accesses the FeatureCatalogue.

I use Eclipse, but the build system we use is Maven, which any Java IDE will support.

Reading-eScience-Centre / edal-java

Smoothed contours #12