[openstreetmap/openstreetmap-website] Add back users.nearby column as a dummy (#2543)
notifications at github.com
Wed Feb 19 10:31:36 UTC 2020
@tomhughes, thanks for replying!
> we do our best to help them where we can but at the end of the day the primary goal takes priority.
Surely I understand the main goal here and value your contributions to it.
Let's also not forget that, besides "regular" map consumers and its well established uses, there are "power" users a.k.a. developers/hackers and new ideas they are constantly trying. All innovation depends on them and their comfort with working over the project. This comfort depends on quality of tools they have at their disposal. Of course, they can always write their own tools (or apply their own hacks to the DB for that matter), but the speed of innovation and thus long-term survival of the project depends on them. Let's not forget about that while we cater to our main goals.
> Trying to do bidirectional data migration between the main database and a mirror is definitely way out of scope
Data migration here is actually unidirectional:
open data source → OSM XML → private OSM DB → public OSM DB
extraction osmosis josm layers
What happens in the reverse direction is a cleanup to prevent double work. Essentially, primitives are "moved", not "copied" from private API to public API.
I go through all these troubles to try a new technique of collaboration over an open data source. Consider this in the context of the OSM project philosophy:
1. The OSM project does not and will not support separate geospatial data layers with its API. Everything we have has to be in *the* single layer, and it immediately goes live.
2. Data imports are prohibited unless they are well integrated/conflated with present DB contents. This basically means each and every new primitive (node, way, relation) has to be visually inspected/tuned by a person before signing it off for uploading. But to do such inspection, a person has to be able to compare "old" and "new" data, essentially working with two layers.
A single person can do the inspection locally in JOSM: the editor does support notion of layers. However, typical data imports are huge enough to be parallelizable among many persons. So, a distributed second data "layer" is needed for them to collaborate. Traditionally, this is done via ad-hoc measures like a shared folder with a bunch of smaller OSM files for everyone to grab, inspect and upload. But shared folders and other filesystem-based collaboration workflows suck immediately when amount of data grows. That is why databases were invented, and this is what I am trying to use here.
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the rails-dev