Kep JTS Ingest and Query Geometry Consistent with Key/Range Dateline behavior

[rfecher]

we try to do our best with geometries out of range: points are clamped between -180 and 180 (eg. POINT(-181, -91) would become POINT(-180,-90)) ; complex geometries are reflected across the dateline and split if necessary so that [-181, -179] becomes [179, 180] , [-179, -180] for example, but keep in mind min and max is respected so for example [-179,-181] becomes [-179, 179] this method within LongitudeDefinition may be of interest in better understanding how longitudes are handled outside of [-180,180]: https://github.com/ngageoint/geowave/blob/master/core/geotime/src/main/java/mil/nga/giat/geowave/core/geotime/index/dimension/LongitudeDefinition.java#L40

However, JTS geometries are still unchanged in the case where geometric relationships are applied for fine-grained evaluation. It seems we should translate JTS geometries to be consistent with their index representation (the behavior defined in LongitudeDefinition).

[themowski]

Thanks for logging this.

Supporting example: in my index, making a SpatialQuery with this polygon:

createPolygon(new Coordinate[] { new Coordinate(-73.975, 40.745),
                                 new Coordinate(-73.970, 40.745),
                                 new Coordinate(-73.970, 40.746),
                                 new Coordinate(-73.975, 40.746),
                                 new Coordinate(-73.975, 40.745) });

returns some data, but this querying with this polygon:

createPolygon(new Coordinate[] { new Coordinate(-73.975+360, 40.745),
                                 new Coordinate(-73.970+360, 40.745),
                                 new Coordinate(-73.970+360, 40.746),
                                 new Coordinate(-73.975+360, 40.746),
                                 new Coordinate(-73.975+360, 40.745) });

does not, and after normalization I would expect these to be the same rectangle.