DWITHIN for EPSG:4326 assumes decimals, ignored the provided units of measure.
After discussing, the current proposal is as follows:
(1) Use a visitor to find the DWITHIN clause.
(2) Calculate the encapsulating geometry with the given units in a meter projection.
(3) Re-project the geometry into EPSG:4326
(4) replace DWITHIN to intersection with the new project geometry.
Why this approach?
(1) Client side one-time activity for fast/efficient evaluation.
Why not use this approach?
Alternative idea is to work within the iterator. For each scanned geometry, convert to a EPSG:3408, then evaluate DWITHIN. This approach would provide a bit more accuracy. However, the reprojection of every point is slower.
See #398 for the related issue.
DWITHIN for EPSG:4326 assumes decimals, ignored the provided units of measure.
After discussing, the current proposal is as follows:
(1) Use a visitor to find the DWITHIN clause.
(2) Calculate the encapsulating geometry with the given units in a meter projection.
(3) Re-project the geometry into EPSG:4326
(4) replace DWITHIN to intersection with the new project geometry.
Why this approach?
(1) Client side one-time activity for fast/efficient evaluation.
Why not use this approach?
Alternative idea is to work within the iterator. For each scanned geometry, convert to a EPSG:3408, then evaluate DWITHIN. This approach would provide a bit more accuracy. However, the reprojection of every point is slower.
See #398 for the related issue.