What
version of WFS are you using for the request? Yes, the
system property should be set in the geoserver startup
scripts, like: -Dgeomesa.force.count=true
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
_______________________________________________
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
