I have implemented a data store and the associated classes such as FeatureSource/Store and FeatureCollection. I’ve registered this as a source in Geoserver. Everything works fine as long as the layer name is equal to the feature name - in particular, getting type dimensions such as min and max datetime works well. However, if the name does not match the type name, then my source is getting wrapped in a RetypingFeatureSource and getting type dimensions incurs a full table scan. Digging into the code a bit, the DecoratingFeatureCollection (parent class of RetypingFeatureCollection) is not delegating to the underlying wrapped collection in its accept(visitor) method. Is there another way of instantiating a custom data store that will perform delegation for aggregation operations?
Thanks,
Anthony
On Fri, Sep 27, 2013 at 2:24 PM, Anthony Fox <anthonyfox@anonymised.com> wrote:
I have implemented a data store and the associated classes such as
FeatureSource/Store and FeatureCollection. I've registered this as a
source in Geoserver. Everything works fine as long as the layer name is
equal to the feature name - in particular, getting type dimensions such as
min and max datetime works well. However, if the name does not match the
type name, then my source is getting wrapped in a RetypingFeatureSource and
getting type dimensions incurs a full table scan. Digging into the code a
bit, the DecoratingFeatureCollection (parent class of
RetypingFeatureCollection) is not delegating to the underlying wrapped
collection in its accept(visitor) method. Is there another way of
instantiating a custom data store that will perform delegation for
aggregation operations?
I'm sure this was discussed recently, and _maybe_ fixed too? Have you tried
out GeoServer 2.4.0?
Cheers
Andrea
--
Ing. Andrea Aime
@geowolf
Technical Lead
GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549
http://www.geo-solutions.it
http://twitter.com/geosolutions_it
-------------------------------------------------------
I have not tried 2.4.x but I was poking around the source on Github and did not see that it was fixed:
https://github.com/geoserver/geoserver/blob/2.4.x/src/main/src/main/java/org/geoserver/feature/DecoratingFeatureCollection.java
which extends:
https://github.com/geotools/geotools/blob/10.x/modules/library/main/src/main/java/org/geotools/feature/collection/DecoratingSimpleFeatureCollection.java
which has a default implementation of canDelegate that returns false.
If it’s a bug, I can help fix it - just wondering if I was doing something wrong.
Thanks,
Anthony
···
On Fri, Sep 27, 2013 at 8:33 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:
On Fri, Sep 27, 2013 at 2:24 PM, Anthony Fox <anthonyfox@anonymised.com> wrote:
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk
Geoserver-devel mailing list
Geoserver-devel@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
I have implemented a data store and the associated classes such as FeatureSource/Store and FeatureCollection. I’ve registered this as a source in Geoserver. Everything works fine as long as the layer name is equal to the feature name - in particular, getting type dimensions such as min and max datetime works well. However, if the name does not match the type name, then my source is getting wrapped in a RetypingFeatureSource and getting type dimensions incurs a full table scan. Digging into the code a bit, the DecoratingFeatureCollection (parent class of RetypingFeatureCollection) is not delegating to the underlying wrapped collection in its accept(visitor) method. Is there another way of instantiating a custom data store that will perform delegation for aggregation operations?
I’m sure this was discussed recently, and maybe fixed too? Have you tried out GeoServer 2.4.0?
Cheers
Andrea
–
Ing. Andrea Aime
@geowolf
Technical Lead
GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549
http://www.geo-solutions.it
http://twitter.com/geosolutions_it
On Fri, Sep 27, 2013 at 2:39 PM, Anthony Fox <anthonyfox@anonymised.com> wrote:
I have not tried 2.4.x but I was poking around the source on Github and
did not see that it was fixed:
https://github.com/geoserver/geoserver/blob/2.4.x/src/main/src/main/java/org/geoserver/feature/DecoratingFeatureCollection.java
which extends:
https://github.com/geotools/geotools/blob/10.x/modules/library/main/src/main/java/org/geotools/feature/collection/DecoratingSimpleFeatureCollection.java
which has a default implementation of canDelegate that returns false.
If it's a bug, I can help fix it - just wondering if I was doing something
wrong.
Ah ok, in this case I guess the retyping feature collection should be
overriding canDelegate and
do some custom logic.
It really boils down to the kind of logic the visitor is pulling off,
whether it uses the feature type
name, or not. Most do not, but some could (the API is open ended)
Cheers
Andrea
--
Ing. Andrea Aime
@geowolf
Technical Lead
GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549
http://www.geo-solutions.it
http://twitter.com/geosolutions_it
-------------------------------------------------------