[Geoserver-devel] getFeatureInfo - HTML with complex features

Niels1 · January 21, 2011, 7:01am

I succeeded in getting wms:getFeatureInfo produce GML3 output from complex features (Yay!).

However, I am now working on using HTML templates with getFeatureInfo.

I noticed in the code that processes templates, that it loads all features in memory first.
However, it uses operations in the FeatureCollection that are not supported by MappingFeatureCollection in app-schema.

There are two possibilities:
(1) Support the methods in MappingFeatureCollection
(2) Rewrite a lot of the template stuff so that it works with an iterator rather than loading all features in memory at once.

As for option (1), correct me if I am wrong, but it seems like a really bad idea to try to load all features in memory at once, especially with complex features. It would be impossible for large collections, that’s why it’s not done in WFS.

Option (2) however seems like it could be potentially huge. I would need to dig very deep in to the template thing.

···

–
Niels Charlier

Software Engineer
CSIRO Earth Science and Resource Engineering
Phone: +61 8 6436 8914

Australian Resources Research Centre
26 Dick Perry Avenue, Kensington WA 6151

Andrea_Aime4 · January 21, 2011, 7:52am

On Fri, Jan 21, 2011 at 8:01 AM, Niels niels.charlier@anonymised.com wrote:

I succeeded in getting wms:getFeatureInfo produce GML3 output from complex features (Yay!).

However, I am now working on using HTML templates with getFeatureInfo.

I noticed in the code that processes templates, that it loads all features in memory first.
However, it uses operations in the FeatureCollection that are not supported by MappingFeatureCollection in app-schema.

There are two possibilities:
(1) Support the methods in MappingFeatureCollection
(2) Rewrite a lot of the template stuff so that it works with an iterator rather than loading all features in memory at once.

As for option (1), correct me if I am wrong, but it seems like a really bad idea to try to load all features in memory at once, especially with complex features. It would be impossible for large collections, that’s why it’s not done in WFS.

Option (2) however seems like it could be potentially huge. I would need to dig very deep in to the template thing.

Pretty much agree with your assessment.

I believe things are the way they are because GFI can be tweaked to return a large
number of results only with quite some effort (i.e., normally does not happen by chance):

you have to specify manually a max number of feature info returned (default is 1, the GS preview sets that to 50)
you have to be hitting with that click a very dense area (be very much zoomed out with a style that shows everything)
you have to force a large buffer parameter to include more than a 3x3 pixels rectangle in your query

So, so far we did not have a urgent need to make things work differently.
However complex features as you say can be huge, even a singe feature in fact can be very dangeours in that it
may be attached to very large lists of sub-features.
Making that work properly with the templates is likely going to require quite some thinking and effort (like some
sort of lazy loading model)

Cheers
Andrea

–
Ing. Andrea Aime
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584962313
fax: +39 0584962313

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

jive · January 21, 2011, 11:39pm

On 21/01/2011, at 5:01 PM, Niels wrote:

I succeeded in getting wms:getFeatureInfo produce GML3 output from complex features (Yay!).

However, I am now working on using HTML templates with getFeatureInfo.

I noticed in the code that processes templates, that it loads all features in memory first.
However, it uses operations in the FeatureCollection that are not supported by MappingFeatureCollection in app-schema.

What operations in FeatureCollection are not supported by MappingFeatureCollection? Perhaps you want to take this to the geotools list if it is a problem to be worked out?
But yeah; there should be no call to load everything at once; but even if the code does do that - it should not effect your implementation of FetaureCollection.

Jody

Niels1 · January 24, 2011, 2:58am

There is a whole series of methods not supported in MappingFeatureCollection: anything that modifies the list (add, clear, etc.) but the one used in the template code is “accepts” to support visitors that visit all features. I think the reason is that a MappingFeatureCollection doesn’t actually hold any features, the features are only created when you use the iterator.

I don’t know if this should or can be worked out, because loading a whole collection of complex features in memory just doesn’t sound like a good idea…

···

–
Niels Charlier

Software Engineer
CSIRO Earth Science and Resource Engineering
Phone: +61 8 6436 8914

Australian Resources Research Centre
26 Dick Perry Avenue, Kensington WA 6151

Niels1 · January 24, 2011, 5:10am

Yeah I guess that would be easy to do, but as i said, I don’t think we want all features to be loaded in memory at once.
I was looking at a different option, but need to threat a FeatureCollection as a Collection for that. I was wondering why it was chosen not to derive the interface of FeatureCollection from the general Collection interface in java, as it implements all the same methods. Because a Feature Collection is not a Collection, I am making a Collection wrapper for a FeatureCollection, and also wondering if that maybe already exists somewhere? Seems like an obvious thing.

···

–
Niels Charlier

Software Engineer
CSIRO Earth Science and Resource Engineering
Phone: +61 8 6436 8914

Australian Resources Research Centre
26 Dick Perry Avenue, Kensington WA 6151

–
Niels Charlier

Software Engineer
CSIRO Earth Science and Resource Engineering
Phone: +61 8 6436 8914

Australian Resources Research Centre
26 Dick Perry Avenue, Kensington WA 6151

jive · January 24, 2011, 6:49am

I was wondering why it was chosen not to derive the interface of FeatureCollection from the general Collection interface in java, as it implements all the same methods.

To answer that question - we did derive from java.util.Collection - however when we moved to Java 5 - the language started assuming what it could do with a collection. Specific the “for each” loop syntax did not match with out need to “close” an iterator after it was no longer used.

We tried some workaround such as:

for( Feature feature : featureCollection ){
System.out.println( feature.getID() );
}
featureCollection.purge(); // to clean up any open iterators

But as you can see above the idea was not thread safe.

There are a couple of other approaches out there; I understand hibernate does something similar with iterators that need to be closed (it was where we got the idea from). Google collections api focuses on providing things that are iteratable; but not a java.util.collection.

We are gradually winding things back to be a nice simple “feature results” which is what we tried for in GeoTools 2.0.

Jody

Andrea_Aime4 · January 24, 2011, 7:28am

On Mon, Jan 24, 2011 at 7:49 AM, Jody Garnett <jody.garnett@anonymised.com> wrote:

I was wondering why it was chosen not to derive the interface of
FeatureCollection from the general Collection interface in java, as it
implements all the same methods.

To answer that question - we did derive from java.util.Collection - however
when we moved to Java 5 - the language started assuming what it could do
with a collection. Specific the "for each" loop syntax did not match with
out need to "close" an iterator after it was no longer used.
We tried some workaround such as:
for( Feature feature : featureCollection ){
System.out.println( feature.getID() );
}
featureCollection.purge(); // to clean up any open iterators
But as you can see above the idea was not thread safe.

It's not only about thread safety. A collection is an intermediary to data
access, as such it should throw some sort of IOException at every step,
otherwise people would just use it as if it was an in memory one
forgetting about handling those errors.

Also, we have one million feature collection implementations, and the
interfaces of Collection is very large, so we ended up finding a lot of
duplicated effort.

Having an explicit close method is a good step forward, not having
the IOExceptions around is something that is still source of many
issues as people forget they are really playing with databases, files
and remote server connections

Cheers
Andrea

--
Ing. Andrea Aime
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584962313
fax: +39 0584962313

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

-----------------------------------------------------