Bryce L Nordgren ha scritto:
>
> [EMAIL PROTECTED] wrote on 02/14/2007 01:38:48
> AM:
> Nope. Use the default (slow) generic service. I suspect that Geometry
> implementations will only offer services if there is a specific and
> substantial performance advantage over the generic services. Usi
[EMAIL PROTECTED] wrote on 02/14/2007 01:38:48
AM:
> Bryce L Nordgren ha scritto:
> > An observation:
> > [...]
> > There should also be a collection of
> > "generic" services which operate only on the GeoAPI interfaces (to
> > accomodate foreign GeoAPI implementations, if slowly). The renderer
Bryce L Nordgren ha scritto:
> An observation:
>
> A reprojection service should not be implemented in a renderer, but should
> be provided by the Geometry implementation. In fact, any operation which
> could significantly impact performance should be offered as an optimized
> service by the impl
An observation:
A reprojection service should not be implemented in a renderer, but should
be provided by the Geometry implementation. In fact, any operation which
could significantly impact performance should be offered as an optimized
service by the implementation. There should also be a colle
Thanks Simone - that extra detail is what I needed.
Jody
Simone wrote:
> I think there is a little bit of confusione here.
>
> My baseline goal with the geometry --> shape converter classes is
> simply to move them out of
> the renderer module and place them back in the main module. In this
> wa
[EMAIL PROTECTED]>
To: "Andrea Aime" <[EMAIL PROTECTED]>
Cc: "simone giannecchini" <[EMAIL PROTECTED]>; "Geotools-devel"
Sent: Tuesday, February 13, 2007 11:13 AM
Subject: Re: [Geotools-devel] Geometry to Shape (on trunk) using Converter
> Andrea
Andrea Aime wrote:
> Jody Garnett ha scritto:
>> Hi Simboss; just a follow up to our question on how to separate out
>> the Geometry -> Shape transition from the rendering code. Since we
>> will be defining no new API we do not need a proposal for this one;
>> you have my permission as module ma
Simone wrote:
> Ciao Jody,
> I am kind of puzzed here (maybe it's time to go to bed) since I do not
> understand why you are talking about controling decimation.
Perhaps we are both puzzled here in different directions - the rendering
package has some Geometry --> Shape code. When making the
tra
Jody Garnett ha scritto:
> Hi Simboss; just a follow up to our question on how to separate out the
> Geometry -> Shape transition from the rendering code. Since we will be
> defining no new API we do not need a proposal for this one; you have my
> permission as module maintainer to package up th
Ciao Jody,
I am kind of puzzed here (maybe it's time to go to bed) since I do not
understand why you are talking about controling decimation.
My base goal with the Geometry --> Shape converters was to move them outsie
of the renderer
in order to be able to leverage on them from the coverage proc
Hi Simboss; just a follow up to our question on how to separate out the
Geometry -> Shape transition from the rendering code. Since we will be
defining no new API we do not need a proposal for this one; you have my
permission as module maintainer to package up the code in *main*; and I
seem to
11 matches
Mail list logo
