[openstreetmap/openstreetmap-website] Designate regions where new accounts cannot edit or add notes (Issue #6512)

Andy Allan notifications at github.com
Thu Nov 27 11:57:40 UTC 2025


gravitystorm left a comment (openstreetmap/openstreetmap-website#6512)

> Are there any past instances of features that haven't been implemented, or have been implemented with workarounds, because PostGIS wasn't available?

For historical reasons (e.g. timing of when we moved to Postgres, widespread availability of PostGIS etc) the "nearby users" feature has been implemented using our own code. See for example [`User#nearby`](https://github.com/openstreetmap/openstreetmap-website/blob/3023ef046a102226c60237634d8e11c5d6ae9a5b/app/models/user.rb#L299-L314), [`sql_for_distance`](https://github.com/openstreetmap/openstreetmap-website/blob/3023ef046a102226c60237634d8e11c5d6ae9a5b/lib/osm.rb#L465-L467), [`sql_for_area`](https://github.com/openstreetmap/openstreetmap-website/blob/3023ef046a102226c60237634d8e11c5d6ae9a5b/lib/osm.rb#L521-L528) and the [QuadTile](https://github.com/openstreetmap/quad_tile) library. It's a prime candidate for refactoring to use PostGIS nowadays, but we should discuss that elsewhere. As for features that haven't yet been implemented, I have lots of ideas (e.g. "notes near me") that again would be candidates for implementing with PostGIS, but again we should discuss elsewhere.

Returning to the matter at hand, I believe it can be implemented using PostGIS, without adding any additional columns to the nodes/ways/relations or changesets tables. I would attempt an implementation as follows:

* create a "zones" table (name tbd, I'm just using a distinctive one here to help illustration) with usual attributes, created_by etc and a PostGIS geometry column
* Have a form for creating zones, with something like https://terradraw.io/ to create the geometry attribute
* Hook into the [`Changeset#update_bbox`](https://github.com/openstreetmap/openstreetmap-website/blob/3023ef046a102226c60237634d8e11c5d6ae9a5b/app/models/changeset.rb#L145-L153) method, and throw an error if the changeset overlaps any zone
* This can be detected by creating a postgis bbox for the changeset at query-time, and relying on the PostGIS indexes and intersection tests to efficiently check for overlapping zones, e.g. (pseudo-query) `select * from zones where ST_Intersects(ST_MakeEnvelope(#{changeset.min_lon}, #{...}, ...), zones.geometry)` or similar

As for whether we should use PostGIS or continue writing/using our own spatial code, I think PostGIS is my preferred choice for this. It moves all the heavy lifting (e.g. 2D-indexes, intersection testing) to a well-maintained library, and if we only need ~1 line of SQL to detect the overlaps, it's much easier to implement both here and in cgimap with much duplication.

There's a few details to be worked out (e.g. exact type of the geometry column, should zones auto-expire like UserBlocks etc) but the spatial stuff is important to nail down first.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/openstreetmap/openstreetmap-website/issues/6512#issuecomment-3585474641
You are receiving this because you are subscribed to this thread.

Message ID: <openstreetmap/openstreetmap-website/issues/6512/3585474641 at github.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/rails-dev/attachments/20251127/01f28047/attachment.htm>


More information about the rails-dev mailing list