Re: [Geotools-devel] Optimizing (and maybe fixing) the recode function

On Tue, Jul 5, 2011 at 5:52 AM, Michael Bedward wrote: > Hi again Andrea, > > Jody and I chatted on IRC a while ago about how using these functions > with rasters and how bad this would be :) We were talking in > particular about InterpolateFunction and wondered about compiling the > interpolatio

Re: [Geotools-devel] Optimizing (and maybe fixing) the recode function

When he says we it is more that he hurt my mind talking about byte code and I ran and hid in a corner. I actually think it is really and interesting idea; but would love to see some benchmarking to justify the complexity / effort / magic. Jody On Tue, Jul 5, 2011 at 1:52 PM, Michael Bedward wrote

Re: [Geotools-devel] Optimizing (and maybe fixing) the recode function

Hi again Andrea, Jody and I chatted on IRC a while ago about how using these functions with rasters and how bad this would be :) We were talking in particular about InterpolateFunction and wondered about compiling the interpolation expression to bytecode using Janino. What do you think ? Michael

Re: [Geotools-devel] Optimizing (and maybe fixing) the recode function

On 4 July 2011 20:26, Andrea Aime wrote: > I looked into the SE spec for RasterSymbolizer, it uses the Categorize > function > and the Interpolate one, not the Recode one. Section 11.6.4 of the specs (05-077_Symbology_Encoding_Implementation_Specification.pdf) includes Recode along with Interpola

Re: [Geotools-devel] Need a improved DataUtilities.mixQueries()

Probably; it is supposed to be the brains behind the get view method; where you cut a feature source down to size. One more option... you could make a method on Query (since it is a class) that covers the kind of "mix" you want to perform. Query.intersect( Query ): Query Query.add( Query ); //

Re: [Geotools-devel] Adding a disposeChain() method to GridCoverage2D

Ciao Andrea, did you think about the interactions with the Views in GridCoverage? This could be a good occasion to get rid of them and/or harmonize with the CoverageRenderer. Feedback? Regards, Simone Giannecchini --- Ing. Simone Giannecchini Ge

Re: [Geotools-devel] Need a improved DataUtilities.mixQueries()

On Mon, Jul 4, 2011 at 7:40 PM, Andrea Aime wrote: > Actually, thinking about it the security case is a bit different, in that > mixing > two attribute lists I need to have the security one act as the only > possible > set of values, thus pick the intersection, not the sum, so I need to roll > som

Re: [Geotools-devel] Need a improved DataUtilities.mixQueries()

On Mon, Jul 4, 2011 at 7:35 PM, Andrea Aime wrote: > Hi, > in GeoServer land we use extensively DataUtilities.mixQueries() to merge > queries that > are coming from two different places. > Tipical scenario is having a layer definition query and a user provided > query, or a > user provided query a

[Geotools-devel] Need a improved DataUtilities.mixQueries()

Hi, in GeoServer land we use extensively DataUtilities.mixQueries() to merge queries that are coming from two different places. Tipical scenario is having a layer definition query and a user provided query, or a user provided query and one coming from the security subsystem. Now, the issue here is

[Geotools-devel] [jira] Created: (GEOT-3691) ImagePyramidReaderTest testCropLevel2 and testCropLevel3 fail extensive tests

ImagePyramidReaderTest testCropLevel2 and testCropLevel3 fail extensive tests - Key: GEOT-3691 URL: https://jira.codehaus.org/browse/GEOT-3691 Project: GeoTools Issu

Re: [Geotools-devel] gt-process planning

Am 04.07.2011 16:29, schrieb Andrea Aime: > On Mon, Jul 4, 2011 at 4:20 PM, Matthias Lendholt > > wrote: > > Interesting. Did you try dropping those processes in a GeoServer? > They might work out of the box in WPS if they are registered in

Re: [Geotools-devel] gt-process planning

On Mon, Jul 4, 2011 at 4:20 PM, Matthias Lendholt < matthias.lendh...@gfz-potsdam.de> wrote: > Interesting. Did you try dropping those processes in a GeoServer? >> They might work out of the box in WPS if they are registered in SPI and >> use simple enough arguments and return values (privitives,

Re: [Geotools-devel] gt-process planning

Am 04.07.2011 14:00, schrieb Andrea Aime: > On Mon, Jul 4, 2011 at 1:06 PM, Matthias Lendholt > > wrote: > > Am 03.07.2011 09:57, schrieb Jody Garnett: > > Well with the map layer work sorted out (thanks mbedward and aaime) I > > can return to

Re: [Geotools-devel] gt-process planning

On Mon, Jul 4, 2011 at 1:06 PM, Matthias Lendholt < matthias.lendh...@gfz-potsdam.de> wrote: > Am 03.07.2011 09:57, schrieb Jody Garnett: > > Well with the map layer work sorted out (thanks mbedward and aaime) I > > can return to what I wanted to work on after docs ... > > > > With that in mind I

Re: [Geotools-devel] gt-process planning

Am 03.07.2011 09:57, schrieb Jody Garnett: > Well with the map layer work sorted out (thanks mbedward and aaime) I > can return to what I wanted to work on after docs ... > > With that in mind I am going to break out gt-process with an eye towards > moving it to supported status. From my perspect

Re: [Geotools-devel] Optimizing (and maybe fixing) the recode function

On Mon, Jul 4, 2011 at 12:08 PM, Jody Garnett wrote: > That would be great Andrea; making it actually work fast is required > before we use it on rasters. I do not know why the code is case insensitive. > Working on rasters... hmmm... does not make sense to me, for the raster case it should be r

[Geotools-devel] starting 8.0-M1

Well it is the last day before the live dvd goes out ... - I need to release 8.0-M1 for a udig release - We need a summary for the geotools library (ie what does it do ... https://jira.codehaus.org/browse/GEOT-3602 ) Ian you have access to the live dvd right? If you are on IRC today we could try

Re: [Geotools-devel] Optimizing (and maybe fixing) the recode function

That would be great Andrea; making it actually work fast is required before we use it on rasters. I do not know why the code is case insensitive. -- Jody Garnett On Monday, 4 July 2011 at 8:04 PM, Andrea Aime wrote: > Hi, > I'm looking into optimizing the recode function for the case where al

[Geotools-devel] Optimizing (and maybe fixing) the recode function

Hi, I'm looking into optimizing the recode function for the case where all keys and values are literals. It seems to me the simplest choice is to build a hashmap in the constructor that maps between keys and values and then use it in the evaluate, it would be the fastest option available I think.

Re: [Geotools-devel] gt-process planning

On 4 July 2011 17:28, Andrea Aime wrote: >> The GeoTools raster-to-vector code should be dropped and the >> equivalent JAITools operator wrapped instead. The latter was based on >> the former but has had far more testing thanks to Andrea. There is an >> issue for this: http://jira.codehaus.org/bro

Re: [Geotools-devel] gt-process planning

On Mon, Jul 4, 2011 at 7:29 AM, Michael Bedward wrote: > On 4 July 2011 10:38, Jody Garnett wrote: > > 3) gt-process-raster > > - migrate raster to vector for gt-process > > - not sure what else goes here; jgrasstools stole most of the reason for > > this one to live > > > > The GeoServer ones ar

Re: [Geotools-devel] gt-process planning

On Mon, Jul 4, 2011 at 2:38 AM, Jody Garnett wrote: > Or drop them altogheter. The current ones are not efficient, most of them > have a better implementation > on the GeoServer side. All the FeatureToFeatureProcess classes are memory > bound for example. > There are some good ideas on both sides