[openstreetmap/openstreetmap-website] Add back users.nearby column as a dummy (#2543)

[Grigory Rechistov]

I have actually hit exactly the same problem just now. The trick by @mmd-osm with a temporary addition of the missing column before invocation of `osmosis` helped. However, for some reason this manipulation (or something else happening at the same time) wiped information about the only OSM user I previously added to the DB (or at least prevented me to access it again). Which was not a big deal, as I created a new account.

It is very sad that `osmosis` is out of support and no replacement is on the horison. And I felt bad about other "ancient" command-line application I was still using (`osmfilter`, `osmconvert`, `upload.py` etc.) I thought that I should have switched to `osmosis`for hopes of its better support in the future, but now I guess I'll stick to my rusty old guns.

A working method to import into DB via command line interface is important for OSM contributors (and for the OSM project in perspective), let me describe my collaboration use case.

I need ability to import data in OSM format into a private instance of OSM API database I've set up. I plan to share a bunch of vector features obtained from a CC0-licensed source with a number of contributors. On my private OSM API instance, these several people can collaborate on improving these features before  uploading them to the public OSM.org database.

I am essentially recreating a WFS-like functionality in a form of an OSM API instance. Using the same JOSM editor and two alternating API URLs, a user does the following steps.

1. For the same bounding box, user loads a chunk of vector data the from private API into layer 1, and from the OSM.org API into layer 2.
2. User manually edits "new" data in layer 1, visually compares its correctness and merges individual map features into the layer 2 via JOSM "Merge" (key combination Ctrl-Shift-M by default).
3. After all problems and conflicts are solved, the user uploads changes of layer 2 to the main OSM API.
4. User deletes all migrated features from layer 1 and uploads this "removal" changeset back to the private API. This way the user informs other collaborators that this portion of import data is finished, so that they won't see already incorporated features any longer. This prevents everyone from double work and from adding duplicates of features to the main OSM database.

I hope my explanation is not overly complicated to grasp (it's a bit late here to think clearly...) There are a few remaining technicalities to solve (like negative IDs for "new" primitives etc.), but nothing unsolvable. `osmosis` is meant to help to perform the initial data import from an OSM XML into the private OSM API server.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/openstreetmap/openstreetmap-website/issues/2543#issuecomment-587978527
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/rails-dev/attachments/20200218/be40cb25/attachment-0001.htm>