Hi All, I followed many topics for the last 3 days about the Ukraine/Crimea and I would like to propose another look to all known issues.
*DISCLAIMER:* First of all, I would like to thank everybody for staying calm and considering all views for this *non-trivial* problem. Originally, I'm from Belarus (former USSR) and currently I live for a long time in the Netherlands, so I hope I can express my point of view objective but also explaining the gist of the issue. Even though I'm leading OsmAnd mobile development, I will speak solely from my perspective on this question. *STATEMENT 1. *There is no ToTG principle for artificial objects such as boundaries + Boundaries are always driven by one or another authorities. *1.1 *To clarify that principle we can go the lowest level, city or suburb boundaries. it is very clear that it is impossible to identify on the ground whether city-suburb has ended and another has started. *1.2 *Of course, we can clarify or build it that knowledge from milestone, flags or fence. Though we have different Mapping for fence, milestone and *we shouldn't mix it with country borders.* Following that principle, it will be hard to build polygons cause we always could miss data in between or it could be very incomplete from the Ground knowledge *1.3 *Most of the data today is coming from authorities. Local municipalities provide that public data, so admin_level of lower level corresponds to *1.4 *There is no ToTG to identify a country, unless you go and do a voting on the special piece of terriritory. I think you can find lots of places like Kurdistan where people would say that they belong to country that doesn't exist or not listed in UN. Country is an entity that coexist with other countries and other countries should acknowledge it and acknowledge their borders (especially for neighbor countries). *1.5 *Fence or any physically present object which could be verified by ToTG doesn't make border legitimate and will be very likely removed from admin_level relations doesn't matter if it looks or claimed by non-authorized entity a special territory if it contradicts to 99.9% perception of other mappers. With this point I'm trying to say, that hiding a solution behind ToTG principle we are raising even more questions than we had. *STATEMENT** 2. *There is no right decision unless we clarify what exactly data and how it should be organized. *2.1 *Moving objects or making special statements about concrete objects will drive to a mess. It is obvious that we better focus on Proposal and clarify how to deal with data rather than changing the map itself. *2.2 *Every mapper should be able to make the right decision himself following the wiki documentation. If it is not possible than the documentation or rules are not complete or not correct. We should not block people that do mistakes in understanding whether their logic correct or not especially if it is a significant number of people. *STATEMENT** 3. *Any decision about current Relations in OSM will be political and it will only evolve confrontation between local editing groups. I believe OSMF should not take any political decisions in such manner. I truly believe that DWG/ OSMF didn't want to make any political decision and only correct the data and make it consistent which makes perfect sense from top level view unless you don't bother with the real situation itself. Unfortunately it is not possible to solve political question and don't get dragged into politics. *3.1 *Hidden political decisions are bad. Why this decision is political? First of all, there is a small politics involved anyway DWG is elected by OSMF members and DWG made that decision. In case people are against it, they can vote for different DWG group and next year the situation around it will be changed again and again. The problem remains here anyway, what if Ukrainian community to vote will be smaller than Russian or what if votes can be based on various connections between people, so we'll get into a minority problem. *3.2 *THE WORST PART: We evolve confrontation between 2 big group of mappers which were always welcome in OSM but as of today they read OSM rules differently and the war of edits begins. In case we want to keep both group of mappers because they INDIVIDUALLY support different regions, we need to find a solution for both of parties. In that case I would actually support idea of deleting all country boundaries to avoid this question completely. *3.3 *DWG/OSMF should minimize any political impact with all possible technical solutions. I truly believe that this question could be solved with proper tagging mechanism and even more it could be solved on the level Google Maps solves it, by having different maps for locales UK_en. Everything should be considered and estimated in order to minimize reputation and diplomatic damage. *STATEMENT** 4. *Decisions should be focused on providing the most value to A) users/editors B) Applications -> to users in the end. *4.1 *openstreetmap.org website solves at most 5-10% use cases where OSM data There is not much critical that some features are not supported on it and it is first of all made to be useful for mappers where data through applications could reach much bigger audience and make mappers happier to impact on the world by small changes. *4.2 *Any decision about Ukraine osm-relation doesn't satisfy End-User application. For example, in OsmAnd we would like to display different maps for different regions and as of today we are forking country relations and doing lots of manual hard fork and all that is coming anyway from OSM but there is no way to contribute it back. We don't have clear algorithm to represent correct boundaries from Chinese Government perspective and in the end we don't represent any boundary correct at all which makes that data almost useless for End-User application. *4.3 *OSM should focus on providing as much and as relevant data as possible and solution will come naturally. If we focus to much what we can display on openstreetmap.org website we will bound ourselves of what feasible/not-feasible to implement on it where it is not necessary. Give right amount of data to the application and give an indicative algorithm for most typical use-cases and problems and it will be sufficient. For a sake of edit-wars some features could be disabled on the main website, so the data question will be leading. *4.4 *Making political risky decisions on the data side will transfer the legitimate problems to End-User applications which they wouldn't know how to solve correctly, basically it will have an amplifier effect. *STATEMENT 5. *Making a decision about Ukraine creates a very nasty precedent which should lead to other changes and raise another questions. *5.1 *Ukraine government doesn't control EAST part of Ukraine (even though there are some relations with citizens who live on that part). *So in that case Ukraine border should change again.* *5.2 *South Cyprus doesn't control North Cyprus https://www.openstreetmap.org/relation/307787#map=9/35.0525/33.8736. It also contain statement about UN recognition which could be applied to Ukraine and then Ukraine should contain Crimean and Russia shouldn't *5.3* Admin levels for China disputed territories are not consistent. Somehow Country level *contains less than all administrative child relations under it *(https://www.openstreetmap.org/relation/4052315 goes beyound country level) Other questions as well. So, it means DWG is not creating a rule but rather changing 1 local object which should be done by local community (in that case it should be ukranian community as Ukraine refers to it). *SOLUTION* I don't want to enumerate possible solutions cause I think if we spend enough time on it and invite people from different communities, we could find it easily. *P.S.* I hope we do not take that question as something that will die out in a week or in a month. Disputed territories were a painful part for OSM for a long time and the pain is only getting bigger. I totally support decision OSMF stay away from politics but it looks like if you don't get involve enough, then politics will start involving you in a different expected way. Thanks, Victor
_______________________________________________ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
