On Tue, Dec 3, 2013 at 2:39 PM, Dries Jeroen <[email protected]> wrote:
> Hi Daniele,
>
> Indeed, if I modify the code to read the array from netcdf "as-is" and I
> disable the affine transformation, then I get a correct result.
>
> However, I think we should be able to use the netcdf metadata to simply do
> the
> right thing. My understanding is that netcdf always uses coordinate
> variables
> to model axis. In my case, this means I have a 'lon' and a 'lat' coordinate
> variable.
>
> The values in these variables should be either monotonically increasing or
> decreasing. This means we can determine the order of the data in the netcdf
> array. Once we have that, we should be able to create a correctly oriented
> BufferedImage in UnidataImageReader.read. Do you agree?
>
I agree with your approach. (I was suggesting to use a parameter because,
if my memory serves me right, I have found some custom NetCDF files the
past years having a different Y direction, but probably that was due to a
wrong usage of the writers, made by the data producer.).
>
> This brings me to another question: currently UnidataImageReader.read
> loops
> over all samples and copies them one by one. Another option would be to
> try do
> do something like this to improve performance:
>
> raster.setDataElements(xmin,ymax,array.getDataAsByteBuffer().array());
>
> (But perhaps we should get it working before trying to optimize
> performance.)
>
I agree with you although improving that would be great. (That code comes
from previous read operations setup on NetCDF 2.2 which probably wasn't
supporting that optimized byteBuffer access op)
>
> To make things more clear, I added some unit tests in a geotools fork on
> github:
> https://github.com/jdries/geotools/commits/10.x
> I can always do a pull request if this seems usefull to you. Note that I
> did
> add a bit of extra code to be able to decode ncml files.
>
That would surely be useful. I can take a look on that.
Best Regards,
Daniele
>
> best regards,
> Jeroen
>
>
> On Tuesday 03 December 2013 10:54:21 Daniele Romagnoli wrote:
> > Hi Jeroen,
> > the postProcessRaster code usually does some processing after the read
> > operation such as adding alpha or applying an affine transformation to
> fit
> > the request.
> >
> > From you feedbacks, I assume that for your HDF5 data, you don't need the
> > negative scale right?
> > In that case, I'm wondering whether we can introduce a FLIP_Y read
> > parameter to be provided to the read operation in order to arrange the
> code
> > to do proper flipping/scaling when set to true.
> > Does it make sense?
> >
> > Cheers,
> > Daniele
> >
> >
> >
> > ==
> > Our support, Your Success! Visit http://opensdi.geo-solutions.it for
> more
> > information.
> > ==
> > Ing. Daniele Romagnoli
> > Senior Software Engineer
> >
> > GeoSolutions S.A.S.
> > Via Poggio alle Viti 1187
> > 55054 Massarosa (LU)
> > Italy
> > phone: +39 0584 962313
> > fax: +39 0584 1660272
> >
> > http://www.geo-solutions.it
> > http://twitter.com/geosolutions_it
> >
> > -------------------------------------------------------
> >
> > On Sun, Dec 1, 2013 at 7:27 PM, Dries Jeroen <[email protected]>
> wrote:
> > > Hi all,
> > >
> > > I'm trying to use the unsupported netcdf plugin to support reading from
> > > HDF5 image files. Currently this results in an exception, because
> > > NetCDFResponse.postProcessRaster tries to apply a jai scale operation
> to
> > > the image, using a negative Y-scale.
> > >
> > > This negative Y-scale is more or less normal, because the latitude
> > > coordinate variable in netcdf is a decreasing value. This is also hard
> > > coded in UnidataVariableAdapter:
> > >
> > > scaleY = -(max-min) / valuesLength;
> > > origin[1] = max;
> > >
> > > So now I'm wondering how to fix the postProcessRaster code, without
> > > breaking anything else. Does anyone know what the goal of this method
> is?
> > >
> > > Should I also log a jira issue?
> > >
> > > thanks,
> > > Jeroen
> > >
> > > Jeroen Dries
> > > TAP - Centre for Remote Sensing and Earth Observation Processes
> > > VITO NV | Boeretang 200 | 2400 Mol
> > > tel. +32 14 33 55 11 | [email protected]
> > > VITO Disclaimer: http://www.vito.be/e-maildisclaimer
> > >
> > >
> > >
> --------------------------------------------------------------------------
> > > ---- Rapidly troubleshoot problems before they affect your business.
> Most
> > > IT organizations don't have a clear picture of how application
> > > performance affects their revenue. With AppDynamics, you get 100%
> > > visibility into your Java,.NET, & PHP application. Start your 15-day
> FREE
> > > TRIAL of AppDynamics Pro!
> > >
> http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktr
> > > k
> > > _______________________________________________
> > > GeoTools-Devel mailing list
> > > [email protected]
> > > https://lists.sourceforge.net/lists/listinfo/geotools-devel
> VITO Disclaimer: http://www.vito.be/e-maildisclaimer
>
------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk
_______________________________________________
GeoTools-Devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
