For the
system property route, do you mean set it on geoserver?
If so then that did not work.
For the
second option I’m not directly querying the accumulo
stack, I’m doing it via geoserver so I do not think I
can add that hint.
What I do
know is 1.2.0 dev system returns the correct number of
matches with the WFS response. The 1.2.2 based system
is returning the total number of features regardless of
the actual query. I didn’t upgrade the 1.2.0 dev system
but I bet as soon as I do it no longer returns a correct
count. When I say a different number the WFS request
matched 3 records/features.
On the
1.2.0 based system for the same data I had
numberMatched=”3” but for the 1.2.2 based system it had
numberMatched=”1508503” (for resultType=hits)
Same data
set, same query:
CQL_FILTER=(BBOX(pickupLocation,
-73.82473468780518,40.82369327545166,-73.81924152374268,40.828328132629395,
'EPSG:4326') AND (Total_amount >=1 AND Total_amount
<=5))
With
outputFormat=json:
1.2.0 gave field "totalFeatures":
3
1.2.2 gave field “totalFeatures”:
1508503
Diane
Hi Diane,
Most likely it is due to getCount being called on the
feature collection being returned. Since GeoMesa is
streaming data from accumulo, in order to calculate an
exact count we essentially have to run the query twice.
Because of this, we return a fake count, or in the
upcoming 1.2.3 an estimated count.
Since sometimes the exact count is important, we have two
ways to force the counting:
1. Set the system property "geomesa.force.count" to
"true" to force exact counting for all queries
2. For individual queries, set a query hint using the key
org.locationtech.geomesa.accumulo.index.QueryHints.EXACT_COUNT
and the value of Boolean.TRUE
I believe this behavior was the same in 1.2.0 though...
Could you try one of the above and see if it resolves your
problem?
Thanks,
Emilio
On 06/23/2016 01:10 PM, Diane
Griffith wrote:
We had upgraded to GeoMesa 1.2.2 in
order to fix the ability to combine IN parameters in a
cql call and get proper results. But I did leave one
environment set to GeoMesa 1.2.0.
What we noticed recently when finally
hooking paging is that the WFS calls (version 2.0.0) we
issued would return the correct number of results given
the CQL_FILTER (that would hold a bbox as well as other
cql filters) but the value in numberMatched was the
total number of features for the feature type specified
not the number of results that would match the
CQL_FILTER. So we would indicate there were more pages
available for the user than actual number of results.
I also tried testing where I just
sent a BBOX parameter instead of combining that with the
cql_filter and it was behaving the same. WFS responses
hooked to GeoMesa 1.2.0 indicated the correct number but
WFS responses hooked to GeoMesa 1.2.2 were reporting the
total number of features for the specified feature type
not the number of features that matched the bbox
specified for that feature type.
I looked at the queries logged in
accumulo and they looked the same on quick review. I
also looked at the call logged by GeoServer and it
looked the same as well.
I was trying to find where in the
code it set the numberMatched field for the WFS 2.0.0
response but I hadn’t found that yet.
I can upgrade the old environment but
I believe once I do that it will behave the same and no
longer give correct numberMatched values.
I compared JDK versions of the
servers, geoserver versions, that they both have native
JAI and it all matches. Also both appear to use the
same version of GeoTools 14.1. The only difference I
have found so far is GeoMesa version. Has anyone
noticed this issue yet? Is there a fix for it?
Thanks,
Diane
_______________________________________________
geomesa-users mailing list
geomesa-users@xxxxxxxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.locationtech.org/mailman/listinfo/geomesa-users
