See that's where I have an issue with your revert logic, if errors are mostly corrected and say theres only 1 or 2 warnings, you want to revert the whole thing which is very bad for: 1. The community and 2. The database. Let me explain: there are many hours that go into merging down CanVec ways and you want to undo all that work. Why is it bad for the database? It makes it bigger everytine you do stuff like that, an ID has to be allocated to every node, way and relation and by you "deleting" everything, they remain in the database as history which is bad as the full history planet file is already retardedly big(200+GB) and then when someone redoes the work you undid, new IDs are allocated which doubles the data size just for you being anal about perfection. Instead of reverting it for 1-2 warnings FIX IT! You dont have nice bing satelite imagery to reference(which is the case with most of northern Canada)? Too bad you want to be anal. Also this is a reminder that bing imagery can be 1. Really really really stale(10-15 years old as taking high res photos of trees doesnt return on investment) and 2. 1-20m offset. Instead of reverting the data that isnt perfect, why not spend your time correcting it instead of work being done: Canada isn't Germany.
Ich wünsche einen guten Tag! On Sep 1, 2016 1:40 AM, "Michael Reichert" <naka...@gmx.net> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Hi, > > unfortunately posting via Gmane does not seem to work (the website is > down but NNTP still works), that's why I have to start a new thread. :-( > > Am Tue, 30 Aug 2016 21:41:21 -0500 schrieb Sam Dyck: > > After reading through the changeset discussion, I discovered that > > one of my imports in Northern Manitoba made Worst of OSM. > > (http://worstofosm.tumblr.com/post/22180046353/dear- > > openstreetmap-isnt-it-strange-how-the). As someone who spends a > > some time amount of time in some of relatively unpopulated areas of > > Canada and makes an effort to check the quality of Canvec data > > (which is usually pretty good), I do agree that it is impossible to > > do everything to the same level of quality that we would provide in > > Toronto or Timmins or even small prairie towns. > > First of all, it is ok that an import takes a few years and therefore > creates ugly green rectancles on the map. If an import is "unavoidable" > :-), a manual import is the best thing that can be happen. But if > someone uploads a changeset without a manual review beforehand, he > counteracts the aim of a manual import: addind good data to > OpenStreetMap. That's what I am mainly fighting against. If a users > uploads much more than 100 objects per minute [1], you can be sure that > he has not done any manual review. A manual review by myself confirmed > this these. I am fighting against such changesets/users. > > A good imports must be reviewed *before* it is being uploaded. The > review contains: > - - Run JOSM validator, fix all warnings and errors. This includes all > warnings regarding validity of areas. (you can argue if all warnings > about "deprecated" tagging have to be fixed) > - - Compare the data with available imagery. Is the forest really a forest > or is another tag more appropiate? Right-click on a Bing tile at JOSM > and have a look how old/recent the imagery is. > - - Check if CanVec data fits to itself. > http://worstofosm.tumblr.com/post/22180046353/dear-openstreetmap-isnt- > it-strange-how-the > - - Check if there has been any other data before. If yes, adapt the > either the CanVec data or the old data. > https://wiki.openstreetmap.org/wiki/File:Import-Fails-Powerlines-Not-Ins > ide-Cutting.png > https://www.openstreetmap.org/way/439631732 > - - Ways should not overlap with other ways if it is not necessary. The > outer ring of a lake should also be inner member of the forest > multipolygon. Maybe the program which created the OSM files should be > imprved? > - - Keep the history. > https://wiki.openstreetmap.org/wiki/Good_practice#Keep_the_history > > If a tile has been imported without being checked manually and no > post-upload fixes have been done (i.e. upload without any checks), I > will not shrink from reverting it. If a tile has been uploaded to OSM > without a review and if it has not been fixed within a month, it is > worthless and can easily be reimported at a later time if someone has > the time to check and fix it. > > For the future, I will abstain from reverting changesets which have been > imported before September 1, 2016 and whose users are currently doing > the fixes that should already have been done. But if I come across an > imported tile of low quality which has not been touched for a few weeks > and is full of errors, it is just a question of time until it is reverte > d. > > Best regards > > Michael > > > > [1] I had a look on a few of my changesets which added a large number of > buildings to OSM. The fastest changeset contained about 60 objects per > minute and was full of missing buildings as I later detected while > collecting the housenumbers and usage of the buildings. > > - -- > Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten > ausgenommen) > I prefer GPG encryption of emails. (does not apply on mailing lists) > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2 > > iQIcBAEBCAAGBQJXx77+AAoJEB87G9rMCMyI95YQAJyCMY/Qtnqu4C3MpLPrrwTH > vN2aVBNoKHL+i6r5VBTPFy4JhcacjbAZSseMCbmQHo6CSdPgVk9Jvnk/Keh3ihH6 > r//EqwqRnSPPE+JIBktW0DG50jzcogWun3UQmOyA/blRfYEZaIDhjRDjMcivBWvs > x8EGZsuX/mraX74ucTbfhy13Xoy4M4Yjf4ibNS7ZmJKlT4Zj8HDwlPKRzFxZ6iWG > JGfibU4wxxvJlQDWqjrVRN6zacbt8SKh9sHU3M88kNRhM+eido/rYY9LiKBFdO21 > TBGM/XkvxcqM7F9u9uC03caDFi0cTb7PLZgv90QhXTi2DuFobfHf3sc1czq8lGeB > Wa8ZZqRI6Y9/SV06P/wydA48caKeeO3OiiuH8UXzEZJPauUhLjpEVxY1OixkgNkC > GR79KbVcx0AyFK66Jnrdn2pqa2HotJ2rM6RLSi68mMOYPbHcUvujcb7XQW5dvubF > L3TamnVs8u1qiifpfTCAp/AJFxd/9UDnGi2VsjSHrIPdZgJaCAcHmhiUSXkcZa55 > hjfL+4b+itj48PRcfJRzXTRE3I9Q7oAyMkbwMKVFvSOe9GwgUNw5nvspWvPUriUo > pDoDHFJt3k4RE6hHVhsb0+L/OyVr6NFpjex2aoEbX0990Gvi+G6uabkNAOn4o0Ub > nAQhtQWnI5dlwMWhcYOH > =vPJv > -----END PGP SIGNATURE----- > > _______________________________________________ > Talk-ca mailing list > Talk-ca@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-ca >
_______________________________________________ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
