[openstreetmap/openstreetmap-website] Adds note versions and variable note tags (PR #5904)
Nenad Vujicic
notifications at github.com
Wed May 7 20:56:04 UTC 2025
nenad-vujicic left a comment (openstreetmap/openstreetmap-website#5904)
> I think this PR would benefit from outlying in more details exactly _**why**_ is it doing changes (i.e. what exactly new user-requested functionality will become available), instead of just enumerating low-level technical steps which are being done. Judging by few words and linked PR discussion, I guess it might have something to do with enabling users to add tags to notes and thus making notes mutable, but I cannot really tell what is an actual idea being implemented, and what are technical side-effects.
@mnalis thanks for feedback! PR's main contributions are:
1. Adds mutable note tags. Why do we (both developers and mappers) need them? Do we want to continue writing hash tags (#surveyme and similar) instead of clicking "add tag" button (still not implemented)? Do we want to read hash tags from discussion's comments instead of having e.g. a table with tags and using appropriate API calls which will do this in an efficient and proper way (implemented)? Do we want to manually filter / search notes or use 3rd party tools across the www instead of having much better stuffs on one place (still not implemented)? I think the answer is "Yes, we would like to have add tag button, see a table with tags instead of #tag-name and searching / filtering ability on OSM". Why mutable? Some note tags are naturally static (e.g. created-by) while some are naturally dynamic (e.g. edited-by, language, ..), also we need to allow adding / deleting after creation (because of input errors, changing circumstances, ..).
2. Adds note versioning. Why do we (both developers and mappers) need it? I believe having an efficient way to retrieve note's provenance (mostly implemented) is important to enable building efficient notes history viewers like we currently have for elements (e.g. [this](https://pewu.github.io/osm-history/#/)) to enable moderators more efficient note's inspection (at the moment this is very slow and fully manual, but in future it will be much faster (still manual) at the beginning, semi-automatic at one moment and eventually almost fully automatic). Also, on OSM website's source-code level, we are moving "special comments" from note's comments to "version's parameters" which will bring us much better decomposition and easier maintenance (also, as a side-effect, we are preparing for removing special comments from `Discussion`, leaving it to only end-user's comments, in the next API increase).
> > plus update functionality (we would have new event type - update) something you would like?
>
> I don't think that notes would benefit from being changed, in fact it would likely be very bad. I.e. if note could be moved or its description changed, followup comments could be misunderstood or turned out of context. Also, it would make necessary not only API/UI to see what changes were being made and when, but a new (or extended) planet.osm.org dump (like we have e.g. `planet-*.bz2` as well as `history-*.bz2` for nodes/ways/relations).
>
> Only part of Note that should be modifiable IMHO is implementing #hashtags, the rest of the notes should better remain immutable. Having versions, locations and descriptions being changed are IMHO likely to introduce much more chaos then help.
At the moment, this PR supports modifying note's description, latitude / longitude and note-tags. At the beginning I wanted to support only modifying tags, but added support for other fields because of [this](https://github.com/openstreetmap/openstreetmap-website/issues/5294#issuecomment-2541473139). For me, it's not a problem to remove modifying note's description and latitude / longitude (in database table `note_versions` we would remove columns `latitude`, `longitude`, `tile` and `description`) and enable modifying only note-tags.
> **TL;DR:** can you list example use-cases and how this PR addresses them (i.e. _"users currently do this thing xxxxx which is inconvenient, and with those changes implemented they will be able do this other thing which is easier/better because yyyy"_)
The purpose of this PR is to show current proposal of how note's could look like. I will update this PR with new features until above functionalities are added and remove stuffs from it when they are committed / rejected. Use-cases we are trying to improve are (among others):
1. At the moment mappers use hash-tags. In near future we could use buttons for creating / updating / deleting note tags. Similarly for reading, instead of passing through note-comments, we will have a table like for elements (this is implemented).
2. At the moment mappers manually search / filter notes. In near future we could use UI for defining searching / filtering criterias.
3. At the moment mappers manually inspect notes or use 3rd party tools. We already have implemented (in this PR) retrieving particular note's version, which gives us a chance to build note's history viewers / analyzers for automatizing parts of note's inspection.
--
Reply to this email directly or view it on GitHub:
https://github.com/openstreetmap/openstreetmap-website/pull/5904#issuecomment-2860333861
You are receiving this because you are subscribed to this thread.
Message ID: <openstreetmap/openstreetmap-website/pull/5904/c2860333861 at github.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/rails-dev/attachments/20250507/9eb81684/attachment.htm>
More information about the rails-dev
mailing list