Another problem is when you are trying to limit the results with respect
to a user specified MAX_FEATURES in the request. This happens with both
WMS:GetFeature as well as WMS:GetFeatureInfo.
The result is particularly dodgy when you have multiple feature
collections, and the geoservers adds their sizes together to calculate
when max_features is reached (or, to pass on to the next feature
collection how many features you want). The results would be even more
buggy if you return -1, or MAX_VALUE.
With WMS:GetFeatureInfo I did a work-around, by calculating the size
through a loop in the special case of complex features (it's basically
the old way -> which means building the copmplex features twice, and you
have same performance issue!) .
But I was already suspicious that breaking the API contract might cause
problems elsewhere...
Niels
On 17/02/11 12:09, Gabriel Roldán wrote:
On Thu, 2011-02-17 at 10:25 +1000, Jody Garnett wrote:
What are you trying to communicate with a size of 0?
You could consider returning Integer.MAX_VALUE if you are unsure of
the size of the collection....
-1 has been used elsewhere to signal "unknown size", so I'd recommend
that instead, as Integer.MAX_VALUE is potentially a valid size?
2c/
Gabriel
int size()
Returns the number of elements in this collection. If this
collection contains more than Integer.MAX_VALUE elements,
returns Integer.MAX_VALUE.
Returns:
the number of elements in this collection
--
Jody Garnett
On Wednesday, 16 February 2011 at 5:49 PM, VT@CSIRO wrote:
Hi, one thing that I realise in my performance patch is that because
I have
set the mappingFeatureCollection.size() to always return 0, it will
affect
the function of resulttype=hits.
Is there any way to bring in GetFeatureType request or the
resultType
variable into my mappingFeatureCollection?
Suggestions was made to use hints but that will require changes to
the Hint
and getFeature classes.
--
View this message in context:
http://osgeo-org.1803224.n2.nabble.com/Performance-patch-bug-tp6030788p6030788.html
Sent from the geotools-devel mailing list archive at Nabble.com.
------------------------------------------------------------------------------
The ultimate all-in-one performance toolkit: Intel(R) Parallel
Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development
cycle.
Locate bottlenecks in serial and parallel code that limit
performance.
http://p.sf.net/sfu/intel-dev2devfeb
_______________________________________________
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
------------------------------------------------------------------------------
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
_______________________________________________ Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
--
*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
------------------------------------------------------------------------------
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
_______________________________________________
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
