geopython / geopython/pygeofilter
sqlalchemy backend: DWITHIN/BEYOND unit conversion divides instead of multiplying
- Dominant language
- Python
- Stars
- 90
- Forks
- 44
- PR merge metrics
- No merged PRs in 30d
Description
In the SQLAlchemy backend's spatial filter, the DWITHIN/BEYOND unit conversion divides where it should multiply:
https://github.com/geopython/pygeofilter/blob/master/pygeofilter/backends/sqlalchemy/filters.py#L238-L243
```python
if units == "kilometers":
distance = distance / 1000
elif units == "miles":
distance = distance / 1609
```
A distance of 5 kilometers becomes 0.005 of the base unit instead of 5000. If the intended base unit is meters, both branches should multiply (`* 1000`, `* 1609.34`).
Separately worth a note in the docs: `ST_DWithin` on a `geometry` column with a geographic SRID measures in degrees, so even with the conversion fixed the result is only unit-correct for projected/metric SRIDs (or a `geography` cast).
Found while wiring pygeofilter 0.4.0 into an OGC API Features Part 3 endpoint; we currently reject S_DWITHIN/S_BEYOND rather than execute them.
Contributor guide
Research direction
Start in pygeofilter/backends/sqlalchemy/filters.py at lines 238-243, then trace the DWITHIN/BEYOND spatial filter entry point and existing SQLAlchemy backend coverage. Confirm the base distance unit before adjusting kilometer and mile handling. Done means the conversions are correct and the documentation notes the SRID-dependent behavior of ST_DWithin on geometry columns.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python, sqlalchemy
- Domain
- backend, databases
- Issue type
- Bug
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 74/100