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
