Re: [Talk-us] user damages administrative boundaries around Rapid City
On Wed, Mar 25, 2015 at 3:13 PM, arch_a...@t-online.de arch_a...@t-online.de wrote: Hello, I've detected a user who damages administrative boundaries around Rapid City. I've tried to contact the user but I got no reaction. I've told the mapper that iD editor is inappropriate, as it has no built in validator but he didn't stop the edits. I want to ask someone from the US to take care of the case and to involve the Data Working Group if necessary. There may be also other damaged objects. http://hdyc.neis-one.org/?gm360st Pascal says: 302 project days; 117 mapping days; ... the last modifier of 28k nodes using Potlach and iD using 3,936 change sets. In my book, gm360st is a valuable young mapping resource more so than a couple of broken polygons. The last thing that I would want to do is involve the Data Working Group. The bar has been purposely lowered to include and attract new mappers via the iD editor. iD is gm360st's editor of choice. There are a number of tools to correct these issues. At this point in time I wouldn't even follow the mapper and correct the problems. The real question is how do you gently grow a young mapper like this without alienating the valuable resource? Regards, Greg ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] user damages administrative boundaries around Rapid City
On Thu, Mar 26, 2015 at 4:21 AM, Greg Morgan dr.kludge...@gmail.com wrote: The last thing that I would want to do is involve the Data Working Group. I'm sending this mail as a DWG member- but I'm only speaking for myself, and not on behalf of the DWG. I don't think most people realize that the DWG will often get complaints, and usually don't take administrative action. It's quite frequent that we get a complaint, and our resolution to the matter is to mediate a disagreement, or focus on education of one or more mappers. Most of the time a resolution can be found without needing to take any official DWG actions. The DWG member's role in those situations is as a third party who can come in, hear everyone's side, and try to find a resolution that works for all parties. In fact, I think that one thing the DWG members would like is if more mappers took time to try to find another solution before contacting the DWG. Many times we'll get a complaint from one user about another mapper's mapping practices and the person complaining hasn't used changeset discussions to, or in some cases even having send someone an in-system message. In other words, the person being complained about may not even know that there's someone whose upset. Reaching out to your fellow mapper should your first step in any conflict resolution. If that doesn't work, the DWG is there to help, and you should feel free to contact them. The DWG email address is d...@osmfoundation.org - Serge ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Elevation in local units
On 03/25/2015 01:43 AM, Bryce Nesbitt wrote: * I feel that osm convention should encourage all mappers to specify units (e.g. 22 m). * That whitespace should be allowed (e.g. 22m, 22 m, or even 22 meters). * And that local units should be encouraged (e.g. 22 feet, or 22' 0). The wiki templates, if spruced up, could define the rules uniformly for all keys that take a measurement unit (e.g. height, width, ele, max_height, etc). -- Parsers are cheap. Any parser worth using can convert 22m, 22 m, 22 feet or a variety of reasonable variants. Humans are messy. Forcing them into boxes generally goes badly. +1 As much as wish meters were used everywhere, I'd rather make it easier for contributors by letting them use whatever make sense to them, and worry about unit conversion later. Especially in this case, where mechanical conversion is so easy. If the elevation was surveyed in feet, entering it in m will almost always result in loss of precision. For my own maps, such as [1], I use a simple osm2pgsql lua script [2] that does various preprocessing, including converting all ele and width tags to feet. It's fairly liberal in the formats it accepts for values. By the way, I thought that the wiki page for ele *used* to say that other units than m were acceptable (if explicitly specified) but I may be confusing it with something else, like width? [1] http://toposm.ahlzen.com/hikemap.html [2] https://github.com/Ahlzen/Hikemap/blob/master/hikemap_tagtransform.lua - Lars ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] user damages administrative boundaries around Rapid City
arch_arch@... arch_arch@... writes: I've detected a user who damages administrative boundaries around Rapid City. I've tried to contact the user but I got no reaction. I've told the mapper that iD editor is inappropriate, as it has no built in validator but he didn't stop the edits. I want to ask someone from the US to take care of the case and to involve the Data Working Group if necessary. This boundary got deleted: http://www.openstreetmap.org/relation/194816 invalid geometry: http://www.openstreetmap.org/relation/195005 invalid geometry: http://www.openstreetmap.org/relation/194808 deleted relation: http://www.openstreetmap.org/relation/194807 It's clear that the user simply meant to remove the CDP boundaries (194816 and 194807), an action that many of us on this list (but maybe not all) would approve of. [1] Unfortunately, the user removed the CDP boundaries by deleting all the ways that belong to the CDP's relation, roping in members of neighboring non-CDP boundary relations. The good news is that Richard Fairhurst patched iD to prevent errors like this in the future. [2] The bad news is that the fix didn't make it into 1.7.0, the version currently on osm.org. So in the meantime we'll have to rely on user education. Echoing Greg's comments, even experienced mappers sometimes hop into iD or Potlatch to make quick edits. These editors may not be as mature as JOSM when it comes to relations, but it isn't necessary to dismiss them out of hand. When it comes to educating new mappers about data entry errors, I've found them to be more receptive to messages like please be careful; here's what to watch out for. Thanks for bringing up this topic. It's an opportunity to remind mappers new and old to review their changesets before saving. iD's save panel lists changes along with validator warnings for some common errors. [3] If iD's validator is missing a check you consider useful, I'm sure the developers would appreciate a bug report. [4] [1] For example, see this thread: https://lists.openstreetmap.org/pipermail/talk-us/2015-January/014075.html [2] https://github.com/openstreetmap/iD/pull/2526 [3] https://github.com/openstreetmap/iD/blob/master/js/id/validate.js [4] https://github.com/openstreetmap/iD/issues ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Elevation in local units
On Thu, Mar 26, 2015 at 2:44 PM, Lars Ahlzen l...@ahlzen.com wrote: By the way, I thought that the wiki page for ele *used* to say that other units than m were acceptable (if explicitly specified) but I may be confusing it with something else, like width? FYI: There's a wiki template that could be extended to give consistency to unit rules, wiki wide. ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
