Sophox indeed needs to be migrated to the new server. I have set up a 501c(3) via OpenCollective to get the needed $150/month. Once I have enough for the first two months, I will migrate Sophox to the new hardware, bring it up to date, etc. Also, would be awesome to get more developer help with maintaining it at GitHub. Thanks!

@dieterdreist that is a fair point, but any kind of mapping could be taken to absurdity. When drawing a sea shore, should we draw around every rock? How small of a rock? This could get ridiculous, therefore we should not draw the sea shore lines at all, right?

Per country border information is a real request by data consumers. I saw it at Wikipedia, and I now see it at Elastic. An identical need has been expressed by OpenMapTiles and IIRC Mapbox. These are real needs, and we can always say “just use another source”, but every time a new source is required, it makes OSM project more difficult to use – making it even less appealing to data users as oppose to just taking a ready-made solution. It simply becomes too expensive (time/resource/computing/…) for smaller players to get what they need within their time/expertise/budget constraints.

I agree with Mateusz that we shouldn’t break existing consumers - so lets figure out a tagging schema that wouldn’t break them, but will allow those who want to do it to do it.

Mateusz, isn’t there a fundamental difference between a country and a person? We are not talking about a single person, we are only talking about countries. The slippery slope argument is wonderful, but has nothing to do with the discussion at hand. Countries. Nothing more. If you want to start a discussion about mapping politician’s perspectives, lets do it in a separate thread.

The 2nd argument is much more important. Yes, we do not want to break the existing data consumers. There is a simple solution - we can use a new type of a relation, e.g. type=disputed_border as oppose to a border. Those who are interested in the information will use it. Those who want the legacy data, will not be affected. We can debate on the best approach to tagging – suggestions are welcome.

Let’s not take the issue to extreme - it won’t help the argument. The proposal is not to let people map “their PERSONAL opinion”. Government of China, India, Russia, Ukraine, … – those are far bigger entities than individual people, and lets stick to that to avoid going on a tangent.

The NEED is there to have a few additional relations to represent the views of those large entities. Nothing more. We do not need to alter the existing “true borders” (whatever that even means). If we have no qualms about people making up new tags as they go (we have over 70,000 unique keys, most of which noone knows the meaning of) - why are we objecting a few extra relations with the new keys?

It might be just my impression, but there appears to be a few highly vocal individuals that simply refuse to allow the rest of the community to map the information that they want on philosophical grounds.

In other words, instead of honoring the core principal of “you want to draw it - draw it, as long as it has basis in reality and you don’t break other’s people stuff”, they try to force others not to do what is clearly in demand by at least a significant portion of participants.

We are not talking about removing data. We are not talking about changing existing data. We are talking about ADDING new data that is important to many data consumers (anyone drawing maps targeted at multiple locales)

And the reasoning - philosophy of the “ground truth”, whereas it is clear that when it comes to political matters like country borders, ground truth becomes much less clearly defined than a street name.

So please, stop blocking others from participating. You don’t want to draw it? Fine, don’t. We allow you to have that freedom. Please allow the rest the freedom too.

As I mentioned previously, I believe this to be a wonderful effort that will make any data consumer’s job much easier. An external database is a wrong approach because it makes harder to collaborate and consume the data – essentially we are forking OSM db into multiple dbs with identical functionality but different rules. Both DBs will need to be curated, collaborated with participants, require tools to work with, etc etc. So instead of simply allowing those who are interesting in this project to do it, to draw and tag data with the clearly marked “disputed” status, we have OSM purists who claim others must follow the most conservative views and must not do anything they do not like. I find this very much against the whole idea of the open data project.

Speaking of humans - here’s a list of all links to humans - something that should never happen in OSM (we don’t map people, we map objects :)) https://wiki.openstreetmap.org/wiki/Wikipedia_Link_Improvement_Project#Linking_to_Humans

I tried to document all different cases, but feel free to add more. Thx!

Hi Mateusz, so which queries do you think are still missing in the https://wiki.openstreetmap.org/wiki/Wikipedia_Link_Improvement_Project ?

There is a project to improve wikipedia links at https://wiki.openstreetmap.org/wiki/Wikipedia_Link_Improvement_Project - at this point it lists many problems found so far, and SPARQL queries to show them on a map (usually worldwide).

It would be awesome to merge our efforts :)

I cannot zoom in - the “edit in JOSM” uses remote control, which starts download the moment you click the edit button and allow remote control function

Thanks for doing it! I tried to edit http://maproulette.org/map/2477/2156740 but JOSM failed because it tried to download too large of an area, and in iD it was not possible to see the actual object to be edited. I suspect others might have similar problems with other locations as well.

Also, I think the instructions should mention that in iD adding a wikipedia field (not tag) automatically adds wikidata. Whereas in JOSM, there is a plugin to auto-pull wikidata if wikipedia tag is set.

Lastly, I really wish we would offer a suggestion - so that a person can quickly evaluate if the machine is accurate, instead of forcing each edit to be fully manual. Machine-aided manual editing might be much more beneficial.

Nice! Some similar efforts: * https://tools.wmflabs.org/wiwosm/osm-gadget-leaflet/#/?lang=en&article=Berlin * The Wikipedia Android app has a map (“nearby”) feature * More at https://www.mediawiki.org/wiki/Maps/Future_Plans#Existing_Tools