The above patrol track coordinate is in one of the two sectors but as we can see it is not computed as within that sector.

Also see this document:
https://docs.google.com/document/d/1axC_Y3kvox85b_-1q8setV-jNPkXR2kn57a6Y9myIBA/edit?usp=sharing

This may have been implemented like this to prevent patrols that touch the boundary of an area without going into the area being counted as in that given area. The test may be checking that the patrol track and area polygon intersect as a line. We may want to implement a contains check instead - the needs further investigation.

This query works as expected on SMART Connect, so it's only the desktop instance that is affected.

Linestrings of 0 length in the x,y plane are invalid linestrings:
connectemily=# select st_isvalid('LINESTRING(0 0, 0 0)');

JTS (desktop uses) obviously doesn't like these and it seems postgis sometimes works and sometimes doesn't. The solution might be to covert the linestring to a point if it is of length 0

I've fixed this on the desktop by changing the intersects function check if the linestring is of zero length first and if so it does a point in polygon check instead.
Also affected include:
- patrol queries with area filters
- mission queries with area filters
- mission summaries

On the server it looks okay, but I got mixed results in my testing. When I wrote the queries directly in postgis I got both true and false for same linestring/polygon intersection depending on the way the query was run. The results are non-deterministic so we need to fix connect as well. All the above cases also need fixing/testing on connect.

Performance on the 500 patrol (90 track points per patrol) doesn't seem significantly affected. Area group bys are slow and will always be slow in derby.

fixed on desktop and connect

r. 5546

In 5.0.a1, I created a patrol with 4 waypoints all with identical coords and set the track. The Summary Query appears to be working as expected.