geopython / geopython/pygeofilter

sqlalchemy backend: DWITHIN/BEYOND unit conversion divides instead of multiplying

Open Beginner friendly
#164 0 comments 0 reactions 0 assignees View on GitHub
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

Open the contributing 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.