On Mon, Jul 4, 2011 at 2:38 AM, Jody Garnett jody.garn...@gmail.com 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
On Mon, Jul 4, 2011 at 7:29 AM, Michael Bedward
michael.bedw...@gmail.comwrote:
On 4 July 2011 10:38, Jody Garnett jody.garn...@gmail.com 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
On 4 July 2011 17:28, Andrea Aime andrea.a...@geo-solutions.it 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:
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.
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 all
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
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 perspective
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 am going
Am 04.07.2011 14:00, schrieb Andrea Aime:
On Mon, Jul 4, 2011 at 1:06 PM, Matthias Lendholt
matthias.lendh...@gfz-potsdam.de
mailto: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)
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, grid
Am 04.07.2011 16:29, schrieb Andrea Aime:
On Mon, Jul 4, 2011 at 4:20 PM, Matthias Lendholt
matthias.lendh...@gfz-potsdam.de
mailto: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
ImagePyramidReaderTest testCropLevel2 and testCropLevel3 fail extensive tests
-
Key: GEOT-3691
URL: https://jira.codehaus.org/browse/GEOT-3691
Project: GeoTools
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
On Mon, Jul 4, 2011 at 7:35 PM, Andrea Aime andrea.a...@geo-solutions.itwrote:
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
On Mon, Jul 4, 2011 at 7:40 PM, Andrea Aime andrea.a...@geo-solutions.itwrote:
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,
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
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 ); //
On 4 July 2011 20:26, Andrea Aime andrea.a...@geo-solutions.it 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
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 ?
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
20 matches
Mail list logo
