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/c2860333...@github.com>
_______________________________________________
rails-dev mailing list
rails-dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/rails-dev
