There is also fours states to a task..clear..no action, yellow...completed and green: validated! (there's also unvalidated to flag a tile as not being done again/not being validated) You can leave comments as well!
On Sat., Jan. 26, 2019, 7:53 p.m. Nate Wessel <[email protected] wrote: > I'm all for this, so long as it really is just for validation. I believe > we can leave notes on tasks via the tasking manager (?), which might be a > good way to catalogue any localized issues we see. > Nate Wessel > Jack of all trades, Master of Geography, PhD candidate in Urban Planning > NateWessel.com <http://natewessel.com> > > On 1/26/19 2:16 PM, john whelan wrote: > > Perhaps a way forward at the moment would be to open the task manager up > so the tiles imported so far can be validated. > > Having lived with computers for many years I'm in total agreement, they > work very quickly but have no common sense what so ever. > > Cheerio John > > On Sat, Jan 26, 2019, 1:56 PM Nate Wessel <[email protected] wrote: > >> Getting a clear idea of what needs to be fixed is what validation is all >> about. Having a second set of eyes look through everyone's imported data in >> a systematic way will give us ideas for what we need to fix moving forward. >> It can't be just a matter of looking at a bunch of automated validation >> script outputs and issuing a checkmark. Machines can do that - us humans >> can do better, and that's a big part of the beauty of OSM: the human >> element. >> >> If I may be permitted a tangent, I was fairly troubled at the last State >> of the Map US conference that the focus of attention seemed to have turned >> to a surprising degree toward "what cool things can machines do with data" >> from the focus I saw in earlier years, which was much more "how can we get >> more people engaged?". Machines don't make quality data - only consistent >> errors. I'm glad the big tech companies were buying us all beers (there was >> soooo much free beer...) but we shouldn't adopt their narrow focus on labor >> efficiency and automation. I don't think efficiency is why we are all here. >> >> ... >> >> I was going to address some of your other points, but I think my little >> digression actually highlighted some of the differences in the way we seem >> to be approaching all of these issues. I'm not a fan of automation and >> efficiency at the cost of quality (in this context), while that is a >> compromise you and others seem willing to make. We may not be able to talk >> our way out of that difference of opinion; the root of the issue is likely >> just a different vision of OSM and why we each care about it. >> Nate Wessel >> Jack of all trades, Master of Geography, PhD candidate in Urban Planning >> NateWessel.com <http://natewessel.com> >> >> On 1/26/19 12:48 PM, Danny McDonald wrote: >> >> 1. In terms of validation, it would be helpful to have a clear idea of >> what sorts of problems need to be fixed. I have re-validated almost all of >> the areas I imported (and all of them in Central Toronto), and fixed all of >> the building related errors/warnings I found (with a few exceptions) there >> weren't many errors, and many pre-dated the import. The only JOSM warning >> I didn't fix is "Crossing building/residential area". Yaro's and John's >> areas don't seem to have many errors either, although there a few isolated >> "Crossing building/highway" warnings (and some "building duplicated nodes" >> errors). I have also split big retail buildings in dense areas. >> 2. I'm fine with simplification, I think we should just do it. In terms >> of orthogonalization, I don't understand why non-orthogonal buildings are a >> problem. If they are, JOSM allows them to be auto-fixed. >> 3. I agree that the task manager squares are too big in central Toronto. >> A separate task can be created for central Toronto only, with smaller >> squares. I think the square size is fine outside of Toronto, as long as >> the squares are split appropriately. >> 4. In terms of conflation, I agree that deleting and re-adding buildings >> is not desirable, but I don't agree that that means it should never be >> done, no matter the time cost. The ideal solution here is some sort of >> script/plugin that auto-merges new and recently added buildings - >> basically, an iterated "replace geometry". >> DannyMcD >> >>> >>> >> _______________________________________________ >> Talk-ca mailing >> [email protected]https://lists.openstreetmap.org/listinfo/talk-ca >> >> _______________________________________________ >> Talk-ca mailing list >> [email protected] >> https://lists.openstreetmap.org/listinfo/talk-ca >> > _______________________________________________ > Talk-ca mailing list > [email protected] > https://lists.openstreetmap.org/listinfo/talk-ca >
_______________________________________________ Talk-ca mailing list [email protected] https://lists.openstreetmap.org/listinfo/talk-ca
