Re: [OSM-talk] OSMF makes a political decision where should be a technical solution?
Hi,
On 23.11.2018 01:42, Yuri Astrakhan wrote:
> One idea (perhaps this should go into a separete thread):
There already is a separate thread over on the tagging list started just
a couple of weeks ago. I suggest that would be a good place to continue
the discussion.
Being able to map different claims is certainly interesting, in so far
as they are verifiable (which surprisingly often is not the case). But
all that's already been mentioned over at
https://lists.openstreetmap.org/pipermail/tagging/2018-October/040333.html
I fear that this is only "kicking the can down the road" though because
we'd likely have - just as we have with names - one "default" set of
boundaries where we say "that's the one you get if you don't ask for any
particular one", and the fight would then be on which one that is going
to be. And judging from how this decision is blown out of proportion
("OMG OSM SUPPORTS TERRORISTS!") I am sure that people would display
exactly the same outrage when discussing which one of a large set of
mapped claims gets the "default" flag.
> I especially appreciate 4.2 -- the fact that this decision is very bad for
> the data users --
I think you have misread Victor's 4.2 which essentially says that data
users currently have to make up their own boundaries anyway and that
therefore this decision does not *help* them. He does not say that it is
good or bad, just that it does not improve an already-bad situation.
As for whether
> DWG has gone too far into the political landscape - something I hope it did
> not intend to do.
let me quote from the DWG statement - again:
"The Data Working Group takes no stance on if Russia's control is legal
or not, as that is not within our scope."
The DWG has simply applied a policy that has existed in OSM since before
Crimea's annexation. That policy was written by LWG and approved by the
OSMF board in 2013 and has been applied many, many times since and it
has generally worked well for OSM. It certainly can be discussed and
improved but that needs to be on a general level, and not tacking on an
"Ukraine exemption" to the rule.
Bye
Frederik
--
Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33"
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk
[OSM-talk] OpenStreetMap Carto release v4.17.0
Dear all, Today, v4.17.0 of the OpenStreetMap Carto stylesheet (the default stylesheet on the OSM website) has been released. Once changes are deployed on the openstreetmap.org it will take couple of days before all tiles show the new rendering. Changes include - Showing natural areas from z5 - Cleaning up medium zoom rendering, including: - Making societal amenities look like residential on z10-z12 - Rendering motorway junction names from z13 instead of z12 - Dropping buildings up to z13 instead of z13 - Correctly dropping minor waterways from z13 - Rendering intermittent streams/ditches/drains from z15 - Reducing lightening of tramways - Rendering religious landuse and place of worship lighter - Adding text-repeat-distance for highway names - Rendering dots for gastronomy objects on z17 - Adding icons for memorial subtags - Rendering man_made=telescope - Rendering amenity=internet_cafe - Adding icon for amenity=public_bookcase - Adding icons for barrier=cattle_grid and barrier=stile - Adding icon for leisure=fishing - Rendering entrance for underground parking - Rendering basin=detention/infiltration as intermittent water - Tweaking outline of swimming pools and rendering it from z17 - Moving danger_area into landuse-overlay - Buildings code rewrite Thanks to all the contributors for this release including jeisenbe, a new contributor. For a full list of commits, see https://github.com/gravitystorm/openstreetmap-carto/compare/v4.16.0...v4.17.0 As always, we welcome any bug reports at https://github.com/gravitystorm/openstreetmap-carto/issues -- "Excuse me, I have some growing up to do" [P. Gabriel] ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OSMF makes a political decision where should be a technical solution?
Victor, thank you for a very thorough and accurate analysis. I especially appreciate 4.2 -- the fact that this decision is very bad for the data users -- I would not be able to use this data at all, simply because most of the time one needs to render the map from the perspective of the specific user, e.g. render it differently for the user in Ukraine, Russia, or anywhere else for that matter. I also agree that DWG has gone too far into the political landscape - something I hope it did not intend to do. I strongly believe DWG should retract that decision, and the community should instead devise a proper policy to record all of the relevant data. One idea (perhaps this should go into a separete thread): * each country gets its own admin_level=2 relation according to THAT country. The relation should contain all of the ways outlining the country's claims (using inner/outer roles). The relation should also contain sub-relations for each of the disputed territory. * each disputed territory should be a relation as well, containing the list of countries that claim its ownership, as well as which countries accept which position. There could be two (or more) "claimed" tags, e.g. in case of Crimea -- "claimed:ru=af;ar;be;..." (list of countries that accept RU claim), and "claimed:ue=*" (everyone else, making it unnecessary to record every country code) This way data consumers could decide how to draw each country depending on the user - simply by combining all of the "claimed:*" tags. On Thu, Nov 22, 2018 at 1:57 PM Victor Shcherb wrote: > 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 >
[OSM-talk] OSMF makes a political decision where should be a technical solution?
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.
Re: [OSM-talk] Multiple errors in the same location
On 2018-11-21 2:29 PM, Jem wrote: > It is a CanVec import from 4 years ago Is there subtext to this? I saw the weird natural=wood CanVec features yesterday (polys cut up into quadtrees) and wondered about its validity. Is the CanVec import notable for being problematic? Yes. CanVec is built from multiple sources, so there can be different issues in different regions. The issues here with overlapping forest and water geometries and overlapping data with existing data are common to many CanVec imports. Four years ago is recent enough that the user should have known that they needed to fix these problems. Where I live there are problems like some data being 40-50 years old. From a practical side, when fixing an area, my first step is generally to delete any data bears no resemblance to reality. In this case, if I wanted to fix just around this lake I would do it by 1. deleting whichever of the water traces is worse; 2. getting any obvious water improvements; 3. deleting the forest inner way; and 4. adding the water as an inner to the forest multipolygon relation. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
