>
> First off we need to hear back from other devs as this would be a core
> modification in a very core class, then we'll decide how to handle
> this. Anyways, the two most promising routes seem to suggest the
> usage of a DataStore wrapper (whether we need a factory or not, it's
> up to how the
Christian Müller ha scritto:
> Andrea, can we agree on 3 terms
> 1) Vertical Generalization
> Having multipe stuctural indentical features
> 2) Horizonalt Generalization
> Having mulitple geometry properties
Hmmm... I don't feel the need to make up terms for this, but
if you'll use them, I'll know
Andrea, can we agree on 3 terms
1) Vertical Generalization
Having multipe stuctural indentical features
2) Horizonalt Generalization
Having mulitple geometry properties
3) Dynamic Generalization
Delegating the work to a backend (Btw, we have to include generalization
into jdbc-ng)
As you p
Christian Müller ha scritto:
> 1)
> Andrea, after the last messages I would propose:
> Pass the resolution hint if you are sure that nothing bad can happen.
> However you do it, I rely on getting the hint with feature types having one
> geometry property with the same CRS.
>
>
> 2) I did a qui
1)
Andrea, after the last messages I would propose:
Pass the resolution hint if you are sure that nothing bad can happen.
However you do it, I rely on getting the hint with feature types having one
geometry property with the same CRS.
2) I did a quick implementation of GeneralizingFeatureSourc
>>
>> The spec definitely does not prohibit it. But the CITE tests only
>> ensure we can handle multiple geoms in the same referencing system.
>
> Then I wonder why we have all this code around checking the JTS Geometry
> user data for a per-geometry CRS (in the rendering code in particular,
> i
Justin Deoliveira ha scritto:
>> - the same column can contain geometries with different spatial
>> reference system too. I know it sounds crazy, but as far as I remember
>> OGC WFS makes sure that you can handle that case as well... mixed
>> with the fact that in GeoServer you have to declar
> - the same column can contain geometries with different spatial
> reference system too. I know it sounds crazy, but as far as I remember
> OGC WFS makes sure that you can handle that case as well... mixed
> with the fact that in GeoServer you have to declare a SRS anyways
> (we have no w
Christian Müller ha scritto:
> Andrea, I am not sure what you are meaning
> "same data source can provide different geometries properties"
> 1a)
> I assume you mean that within one feature type we can have more than one
> geometry property.
Indeed.
> Since a feature has a default geometry, this
Andrea, I am not sure what you are meaning
"same data source can provide different geometries properties"
1a)
I assume you mean that within one feature type we can have more than one
geometry property.
Since a feature has a default geometry, this is the one we should use. If I
have a feature
Christian Müller ha scritto:
> But anyway, I do not want any generalization on the fly and 1) is my first
> target.
>
> Passing difference/offset in the native CRS as a hint would make me happy
> :-)
> If the hint is missing, you always get the base geometries, the same holds
> true if the val
Thanks for the information.
I never had the intension to generalise on the fly. I want to implement the
same principle I used
with the imagemosaic-jdbc module, storing pyramid levels in the datastore.
All the pre generalized geometries have to be valid, because WFS should also
be supported.
Christian Müller ha scritto:
> Last week I posed a question about having a FeatureSource which has also
> some generalizations of the vector data to speed up response time and reduce
> data transfer.
>
> While it is is surely not the problem to implement such a FeatureSource, I
> need the Sca
A few comments inline.
On Tue, Mar 31, 2009 at 3:26 AM, Christian Müller
wrote:
>
> Last week I posed a question about having a FeatureSource which has also
> some generalizations of the vector data to speed up response time and reduce
> data transfer.
>
> While it is is surely not the problem t
Hi Christian,
I will delegate to Andrea on this one since he is the rendering expert
but I will say that imo this is a perfectly valid use of a query hint.
And indeed afaik many other type of hints are passed down by the render
to perform similar functions like decimation, etc...
2c,
-Justin
Last week I posed a question about having a FeatureSource which has also
some generalizations of the vector data to speed up response time and reduce
data transfer.
While it is is surely not the problem to implement such a FeatureSource, I
need the ScaleDenominator from the caller.
I studi
16 matches
Mail list logo
