I recall that Victor thought of using -1 for the size(), but the XML
schema for the cached response requires an xsd:nonNegativeInteger for
numberOfFeatures. If size() returned an Integer, we could use null and
nothing would be encoded, but handling a -1 would require changes to the
binding. Enc
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 th
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 ins
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
int size()
Returns the number of elements in this collection. If this collection contains
more than Integer.MAX_VALUE elements, returns Intege
Hi Victor,
I think you might want to move this to geoserver-devel. But yeah, as you are
seeing changing the meaning of 0 with respect to what the api says is
causing you headaches :)
I don't know of any way to get this information at the geotools api level.
In GeoServer you could probably get a h
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?
