Re: [OSM-talk] New OSM Quick-Fix service
I agree that the tool requires some additional work. It seems almost all of the criticism has been directed at the hypothetical "community clicking rampage" - where the query is stored on a wiki, and some user runs it thoughtlessly. At the same time, several skilled users have expressed their desire to use it for their own work. Hence, as a good compromise between the two, how about I disable the "embed edit". If the query is executed from a link, without the query editor mode, users can only view results. But in the power mode, the users can still use the tool to write a query they need, test and edit things as they need. So its ok to use it as a power editor (e.g. JOSM or Level0), but not as mass contribution. In the mean time, I will add the "two person approval required", which should alleviate expressed concern. Should be ready fairly soon. On Mon, Oct 16, 2017 at 8:24 PM, Frederik Ramm wrote: > Hi, > > On 10/16/2017 11:10 PM, Tobias Zwick wrote: > > Anyway, generally, with everyone raising the alarm about this tool, it > > would be a friendly gesture to either take the tool offline for now or > > set it to read-only mode > > Or have it run on the dev API. > > > So then, the solution is simple: Make the quick-fix tool to only record > > confirms and rejects into a separate database and let the tool not make > > actual edits to OSM. The confirms and most importantly the rejects are > > shown on the tool's interface, so the problems in the automatic query > > can be addressed. > > The "Kort game" has followed a similar approach. When they started, they > first only recorded things internally and also had more than one user > confirm each edit. After test-driving that for a while and assessing the > quality of results, they started a discussion about if and how the Kort > results could automatically be applied to OSM. It was a slow process but > one that went to great lengths to respect how OSM works and not to > "disrupt" anything. The makers of "Kort" probably spent as much time on > making their tool acceptable to the community as they spent on > developing it - but that's what you have to do when you deal with humans > and not just an API. > > 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 > ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] New OSM Quick-Fix service
Hi, On 10/16/2017 11:10 PM, Tobias Zwick wrote: > Anyway, generally, with everyone raising the alarm about this tool, it > would be a friendly gesture to either take the tool offline for now or > set it to read-only mode Or have it run on the dev API. > So then, the solution is simple: Make the quick-fix tool to only record > confirms and rejects into a separate database and let the tool not make > actual edits to OSM. The confirms and most importantly the rejects are > shown on the tool's interface, so the problems in the automatic query > can be addressed. The "Kort game" has followed a similar approach. When they started, they first only recorded things internally and also had more than one user confirm each edit. After test-driving that for a while and assessing the quality of results, they started a discussion about if and how the Kort results could automatically be applied to OSM. It was a slow process but one that went to great lengths to respect how OSM works and not to "disrupt" anything. The makers of "Kort" probably spent as much time on making their tool acceptable to the community as they spent on developing it - but that's what you have to do when you deal with humans and not just an API. 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
Re: [OSM-talk] New OSM Quick-Fix service
Richard, thanks for the link and your analysis. Eric Raymond once said that "Every good work of software starts by scratching a developer's personal itch." Judging by how many different individuals have created various challenges and fixers, there is clearly a big irritation - highly messy, unclean data. A corollary is that the existing tools do not address the entire scope of the problem, thus new tools keep being created. BTW, thanks for listing a few tools I haven't heard about. A number of people here feel that we cannot trust our users to be diligent. While I don't like stigmatizing it in such way, some people some times do make bad edits. The fundamental question we should keep in mind is: "does the benefit outweighs the risk". Or more precisely - which approach produces better result. If we do nothing, the data becomes less consistent, and sporadic unorganized efforts may hinder more than help. If we do bot editing, corner cases and bugs may spoil valid data. If a challenge requires manual edit, we have a high risk of typos - people are not very good at performing the same edit over and over and not make mistakes. If we do distributed accept/reject, some people, in theory, may be tempted to be trigger happy. In each case, the balance is fairly hard to reach. In distributed editing, one way to solve the "auto-clicking" is to use "multi-reviewer" approach - require two people to agree on an edit before it happens. I can fairly easily add that capability. This way, an expert editor may use the tool for direct editing (power mode), but the published challenges will require two person agreement, unless the community decides that a specific query is acceptable with just one. I do not want to make that decision for each community, as different cases require different approaches. What do you think? Would that address the most pressing concern? On Mon, Oct 16, 2017 at 10:13 AM, Richard Fairhurst wrote: > Yuri Astrakhan wrote: > > For example, RU community wants to convert amenity=sanatorium > > -> leisure=resort + resort=sanatorium. Clicking on a dot shows a > > popup with the suggested edit. If you think the edit is correct, simply > > click Save. > > I've been a bit loth to get involved with this one but I do share the > general worry. > > Editor authors have a general responsibility to encourage good editing > behaviour in their UI design. It isn't quite as simple as "every tool can > be > used for good and bad things": the developer should design the tool to > encourage the good and discourage (or prevent) the bad. The developers of > JOSM and, particularly, iD have long been exemplary in this regard. > > This new tool can certainly be used for good, and there are use cases for > which it is ideal, but it's also very easy to misuse. My biggest concern is > that since it's decoupled from an editing environment, the natural tendency > is just to click 'Change', 'Change', 'Change' rather than reviewing and > manually making the changes. (We've seen this behaviour in several > "challenges" in the past, such as the dupe nodes drive.) OSM is a > collection > of human knowledge; this workflow goes too far in removing the human from > the equation. > > As an alternative, could I encourage you to look at something tentative I > did the other year for that relic of an editor, Potlatch 2? > >https://www.openstreetmap.org/user/Richard/diary/28267 > > This allows a user to navigate instantly between instances of a "challenge" > within the editor, while benefiting from an external data source to define > that challenge. The P2 implementation is fairly simple (there's no > "Resolved" button to feed back to that external source, for example) but > demonstrates the concept. > > If you were to build something along these lines into JOSM or iD, following > the traditional MapRoulette-like approach of asking users to make the > change > rather than automating it, I think you'd get the benefits you're seeking to > achieve without the potential damage. > > Richard > > > > -- > Sent from: http://gis.19327.n8.nabble.com/General-Discussion-f5171242.html > > ___ > talk mailing list > talk@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk > ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] New OSM Quick-Fix service
Michael, I can only judge by my own experience adding validation autofix rules - I added a number of Wikipedia tag auto cleanups to JOSM, and they were reviewed by one or two JOSM developers and merged, probably because they were deemed benign. I don't know about the other rules, but I suspect many of them also went this route. Should have they been discussed more widely? I don't know, but that question is complicated, just like "what is a local community?" question. What a few devs may see as benign, others may say needs a discussion, right? Mass editing is a different matter. We consider mass editing when one person goes out to fix something everywhere in the world. But when we provide a tool that automatically fixes something that you are looking at, we don't view it as such. Or at least we don't view it when it happens as part of JOSM, but we do when it happens in my new tool. Of course there is an important difference - JOSM doesn't guide you towards those cases. I think massive "by-the-way" fixing is far worse than the targeted fix of a single issue. When you want to fix a single issue in many places, you become a subject matter expert. You know all about that change, how it interacts with other tags, what to watch out for, how to handle bad values, etc. For example, when fixing wikipedia tags, you would see the types of mistakes people make, wrong prefixes people use, incorrect url encodings, hash tags in urls, incorrect multiple values, ... .When you simply click "fix" because JOSM validator tells you it can fix it automatically, you don't have that knowledge, so it effectively becomes a distributed mechanical edit without the "reject" capability. My tool tries to address this - to build domain experts in a narrow field, and let those experts review changes one by one. I do not discount the value of local knowledge, but it is not a panacea - you must be both to make intelligent choices, and in some cases, the domain knowledge is more important than the knowledge of a specific locale. On Mon, Oct 16, 2017 at 4:00 PM, Michael Reichert wrote: > Hi Yuri, > > Am 16.10.2017 um 16:02 schrieb Yuri Astrakhan: > > Rory, most of those queries were copied from the current JOSM validator > > autofixes. I don't think they were discussed, but they might have been > > mass applied without much thought by all sorts of editors. > > Could you please give examples for (a) the mass appliance of these rules > and (b) rules which have not been discussed but should have been discussed? > > There are two ways to use the tool - you can write your own query, run > it, > > and fix whatever it is you want to fix. That's the power user mode - > > anything goes, no different from JOSM or Level0. And there is another > one - > > where you go to osm wiki, read the instructions, find the task you may > want > > to work on, and go at it. The community reviews wiki content, tags > > different pages with different explanation or warning boxes, etc. The > > discussion could still be on the forum, or here, or in IRC, > > Just for future readers: IRC and Telegram channels are no replacement > for a mailing list or a forum with a public readable archive where you > can look up the discussions years later. > > Best regards > > Michael > > > > -- > Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten > ausgenommen) > I prefer GPG encryption of emails. (does not apply on mailing lists) > > > ___ > talk mailing list > talk@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk > > ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] New OSM Quick-Fix service
Number 2. >> [...] This was a topic in this thread already and it was >> voiced that inventing new tags just to be used by this tool in not >> acceptable and I agree with that. The other tools also do not >> require that. > > [...] Not showing it can also be easily done by a slight > modification of the query itself. This is assuming my reasoning for > on-OSM tag storage makes sense for other tools. In the mean time, I do > plan to make a separate reject storage system just to cover all cases. An on-OSM tag storage? Inventing new tags for (single) tools is specifically what I mentioned has been strongly opposed! I see you mention having some OSM tag further below in your message and you give some arguments why this might be a good idea beyond the ease of implementation. I'd say, of course whether such a tag or namespace of tags could make sense is something that can be discussed. But not after the fact and not on pressure. Your tool being live, and no way marking something as false-positive, this does set a discussion about this in exactly in a bad atmosphere. Anyway, generally, with everyone raising the alarm about this tool, it would be a friendly gesture to either take the tool offline for now or set it to read-only mode (no save button) so that everyone can calm down and the critical points about it can been addressed and solutions be found, in an objective non-pressured manner. Since this is a general consideration that concerns other tools as well then, it should be done in a separate topic. Anyway. I am surprised to read that you see the tool actually also in case #1, as a manually operated automatic edit. It could be that I, and probably many people here in this topic majorly misunderstood your intention with this tool. Let me summarize your arguments why this makes sense over a fully automated edit: 1. barrier too high for writing a completely automatic bot a) automatic edits are too risky, fear of programming errors b) too thorough review is required for fully automatic edits, fear of uncovered edge cases c) a mistake of a bot edit can only be spotted after the fact and a (partial) revert of such a bot edit is complex 2. your tool lowers that barrier by creating some kind of staging / test area for bot edits by having different users manually confirm or reject the proposed fix for any such element a) it's relatively easy to add an automatic edit to the tool and that same query can be used to run directly on the server for full automation b) issues with the query can be fixed by anyone (wiki) --- I can follow your line of argumentation and your vision. There is quite the discrepancy between this and the concerns mentioned so far in this topic, which see your tool from a different perspective (which I will iterate further below). The concerns are, that the tool will not actually be used to stage/analyze the impact of an automatic edit that is to be applied after consensus and thorough testing but to go forward with organized re-tagging without that (or at least give other users the tool to do that). If this is not your intention, then the tool must be changed in a way that it does not lend itself for that purpose. Furthermore, the argument that a mistake in a completely automatic bot is complex to revert, seems bogus. If the edit happens in *one* edit, it is on the contrary, very easy to revert. If, on the other hand, dozens or even hundreds of people worked on a quick-fix task which needs to be reverted, again on the contrary, this is much harder to revert because there are different users, different changesets and over a varying timespan involved. (Also, I hope the tool at least writes into the changeset which quick-fix exactly was used, to link quick-fix with changesets) > [...] this will be up to the communities to enforce - if > someone writes a query [that requires actually going there to check], > others should be quick to point this out. Better, document that. Here, look for example at the guidelines for new "quick-fixes" (aka quests) I wrote for my OSM tool: https://github.com/westnordost/StreetComplete/wiki/Adding-new-Quests-to-StreetComplete Leaving this kind of supervision to "the community" means that you generate thankless work for people that constantly "should be quick to" sound the alarm for quick-fixes that are not correct in one way or the other (which are immediately live). Not sure if this came across to you yet, but it has been said a couple of times in this thread already and it should be repeated in light of the answer you gave above: When you say, it is up to the community to point out problems with any such query that has already been created and is being worked on, then you basically reverse the whole guidelines for bot-editing - the community learns about it after the fact, instead of before it is happening. This is exactly the situation we do not want to have. This is the fundamental issue with the tool and something t
Re: [OSM-talk] New OSM Quick-Fix service
Hi Yuri, Am 16.10.2017 um 16:02 schrieb Yuri Astrakhan: > Rory, most of those queries were copied from the current JOSM validator > autofixes. I don't think they were discussed, but they might have been > mass applied without much thought by all sorts of editors. Could you please give examples for (a) the mass appliance of these rules and (b) rules which have not been discussed but should have been discussed? > There are two ways to use the tool - you can write your own query, run it, > and fix whatever it is you want to fix. That's the power user mode - > anything goes, no different from JOSM or Level0. And there is another one - > where you go to osm wiki, read the instructions, find the task you may want > to work on, and go at it. The community reviews wiki content, tags > different pages with different explanation or warning boxes, etc. The > discussion could still be on the forum, or here, or in IRC, Just for future readers: IRC and Telegram channels are no replacement for a mailing list or a forum with a public readable archive where you can look up the discussions years later. Best regards Michael -- Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten ausgenommen) I prefer GPG encryption of emails. (does not apply on mailing lists) signature.asc Description: OpenPGP digital signature ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] New OSM Quick-Fix service
I will split this into several answers, that is what a threaded structure is for. > JOSM fix button I am not sure what is your point with JOSM's fix button. Let's not deviate from the topic: your tool. If you find, something is wrong with JOSM or any other tool in that matter, better create an own topic for that. In any case, it is not a good argument to justify deficiencies of one tool with deficiencies another tool might (or might not) have. Not saying that this is your intention here, what I understood is that you want to say that the idea for your tool mainly comes from wanting to improve on the idea behind that feature in JOSM. Ok. > it won't save unless you zoom in to 16+ (just like iD editor). > Plus I added Mapbox satellite imagery to help. You mean, the save button is disabled, right? > MapRoulette and SPARQL Well, if you are not interested in getting involved in MapRoulette to add your idea there, that's your choice. I am elaborating below just to get this clear, in case you misunderstood: I did not mention SPARQL. I was talking solely about the idea of quick-fixes, not to transplant your current code into MapRoulette. Naturally, the implementation in MapRoulette would not include SPARQL queries but i.e. 1. the creator of a challenge simply supplies the "quick fix" answer option(s) in a multiline textfield after he supplied the Overpass query, i.e. like this: sport=soccer sport=american_football sport=canadian_football sport=australian_football sport=gaelic_football 2. MapRoulette shows the answer option(s) (as dropdown) next to the other buttons for each element in the challenge. 3. MapRoulette uploads the selected quickfix through OSM API I was also bringing this up, because I was quite shocked to see how much code is necessary in SPARQL just to convert religion=Christian into religion=christian (http://tinyurl.com/yame4thf ) I am already lost there with this query. I'd say, as a user, it is *really* easy to make a mistake there. >> Though, note, for all three cases, a prior consensus is required, >> either by prior discussion or by looking at what was previously >> agreed on in the wiki. That is the case for *any* organized >> re-tagging of existing tags. > > Sure thing. There are very very few cases when the fix is super > obvious, e.g. a typing fix, but lets not dwell there. In regards to what I said above, I reckon you can do a lot more stuff with SPARQL than simple tag replacement. Fair enough, that I'd find such an extension of MapRoulette more useful is just my personal opinion. Tobias ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Zooming past native resolution
Thanks - disabling auto zoom worked. I'm working on the Puerto Rico project - they are using ESRI World imagery as a base. On 2017-10-16 11:22 AM, Nelson A. de Oliveira wrote: On Mon, Oct 16, 2017 at 3:09 PM, Richard Nairn wrote: I'm just starting out and I had a question related to imagery. I am trying to do some digitizing of house footprints for HOT-OSM. I'm having issues when the houses are very close together, or I'm trying to digitize smaller features. When I try to zoom in beyond native resolution to move, or prevent snapping I get that the imagery is no longer available. Is there a way to prevent it from doing that? I want to still see the imagery even though it may be coarse just to do some detail work... Which layer are you using? (and the location, if possible) The layer can be updated in https://josm.openstreetmap.de/wiki/Maps to use no-tile-header and/or no-tile-checksum See https://josm.openstreetmap.de/wiki/Maps#Generalproperties (or open a ticket, if you possible too) And as a workaround you can zoom to the maximum level where you see the tiles, click with the right mouse button and disable "Auto zoom" ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] New OSM Quick-Fix service
> Except that's not true. In Ireland "handball" is Gaelic Handball¹ > which is a one-on-one game, not a team sport (which is apparently a > different thing²). There are some sport=handball's tagged in Ireland. > Now the tag is clearly wrong, and we need to figure out something about > that. But if you just change sport=handball to sport=team_handball, then > you've entered incorrect data, based on incorrect assumptions. Good catch. So, it is no good as an example for that. But no matter, I think the idea got across anyhow. > Big question: What defines "community consensus"? I can't really answer that. I'd define it as "Topic has been brought up to the public and there are no justified and irrefuted objections." > Not everyone (incl me) thinks that the wiki defines what a tag should > mean... Sure, the wiki is to be taken with a pinch of salt (I think I do not need to elaborate why), but it is the only documentation we have. Everyone, (new) users, data consumers and app developers simply will always consult the wiki. Because the wiki has such a central importance, the (unwritten? written?) rule is that parts that explain what has to be mapped how should only be done to document the status quo (if it is explicitly stated as such) or better after finding such a consensus. Tobias ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Zooming past native resolution
Sorry for the duplicated message, Richard. The first one didn't have talk on CC. On Mon, Oct 16, 2017 at 3:09 PM, Richard Nairn wrote: > I'm just starting out and I had a question related to imagery. I am trying > to do some digitizing of house footprints for HOT-OSM. I'm having issues > when the houses are very close together, or I'm trying to digitize smaller > features. When I try to zoom in beyond native resolution to move, or prevent > snapping I get that the imagery is no longer available. Is there a way to > prevent it from doing that? I want to still see the imagery even though it > may be coarse just to do some detail work... Which layer are you using? (and the location, if possible) The layer can be updated in https://josm.openstreetmap.de/wiki/Maps to use no-tile-header and/or no-tile-checksum See https://josm.openstreetmap.de/wiki/Maps#Generalproperties (or open a ticket, if you possible too) And as a workaround you can zoom to the maximum level where you see the tiles, click with the right mouse button and disable "Auto zoom" ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Zooming past native resolution
Sorry - Using JOSM - dev build On 2017-10-16 11:09 AM, Richard Nairn wrote: Hi, I'm just starting out and I had a question related to imagery. I am trying to do some digitizing of house footprints for HOT-OSM. I'm having issues when the houses are very close together, or I'm trying to digitize smaller features. When I try to zoom in beyond native resolution to move, or prevent snapping I get that the imagery is no longer available. Is there a way to prevent it from doing that? I want to still see the imagery even though it may be coarse just to do some detail work... Thanks ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Zooming past native resolution
Hi, I'm just starting out and I had a question related to imagery. I am trying to do some digitizing of house footprints for HOT-OSM. I'm having issues when the houses are very close together, or I'm trying to digitize smaller features. When I try to zoom in beyond native resolution to move, or prevent snapping I get that the imagery is no longer available. Is there a way to prevent it from doing that? I want to still see the imagery even though it may be coarse just to do some detail work... Thanks ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] New OSM Quick-Fix service
Yuri Astrakhan wrote: > For example, RU community wants to convert amenity=sanatorium > -> leisure=resort + resort=sanatorium. Clicking on a dot shows a > popup with the suggested edit. If you think the edit is correct, simply > click Save. I've been a bit loth to get involved with this one but I do share the general worry. Editor authors have a general responsibility to encourage good editing behaviour in their UI design. It isn't quite as simple as "every tool can be used for good and bad things": the developer should design the tool to encourage the good and discourage (or prevent) the bad. The developers of JOSM and, particularly, iD have long been exemplary in this regard. This new tool can certainly be used for good, and there are use cases for which it is ideal, but it's also very easy to misuse. My biggest concern is that since it's decoupled from an editing environment, the natural tendency is just to click 'Change', 'Change', 'Change' rather than reviewing and manually making the changes. (We've seen this behaviour in several "challenges" in the past, such as the dupe nodes drive.) OSM is a collection of human knowledge; this workflow goes too far in removing the human from the equation. As an alternative, could I encourage you to look at something tentative I did the other year for that relic of an editor, Potlatch 2? https://www.openstreetmap.org/user/Richard/diary/28267 This allows a user to navigate instantly between instances of a "challenge" within the editor, while benefiting from an external data source to define that challenge. The P2 implementation is fairly simple (there's no "Resolved" button to feed back to that external source, for example) but demonstrates the concept. If you were to build something along these lines into JOSM or iD, following the traditional MapRoulette-like approach of asking users to make the change rather than automating it, I think you'd get the benefits you're seeking to achieve without the potential damage. Richard -- Sent from: http://gis.19327.n8.nabble.com/General-Discussion-f5171242.html ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] New OSM Quick-Fix service
Rory, most of those queries were copied from the current JOSM validator autofixes. I don't think they were discussed, but they might have been mass applied without much thought by all sorts of editors. What's worse, there is no way to track those autofixes. The wiki page has a huge warning box at the top, which should stop accidental misuse. At this point, there is no officially agreed wiki page with the "allowed" queries. Once the tool matures a bit, we can create a place for the community approved tasks. My proposal - place queries for evaluation on a wiki page under a warning box. Let community review them. Then we can move them one by one to the "green" page. There are two ways to use the tool - you can write your own query, run it, and fix whatever it is you want to fix. That's the power user mode - anything goes, no different from JOSM or Level0. And there is another one - where you go to osm wiki, read the instructions, find the task you may want to work on, and go at it. The community reviews wiki content, tags different pages with different explanation or warning boxes, etc. The discussion could still be on the forum, or here, or in IRC, The tool cannot automate the review process - if someone wants to break the rules, they can still write whatever query they want and run it. Or use JOSM or Level0. Just like Éric Gillet said - every tool can be used for good and bad things. Having the right explanations on the wiki will solve 80% of the problems. P.S. You can star any wiki page, and it will email you when the page changes. Just like a forum. On Mon, Oct 16, 2017 at 8:42 AM, Rory McCann wrote: > On 16/10/17 14:02, Yuri Astrakhan wrote: > >> Rory, thanks, and that's why I think it is a bad idea to do bot edits >> without first running it through my tool. If we do a mass edit, we have to >> go through a very lengthy community consensus study, which might still miss >> things. Then the bot developer might still make an error that is not likely >> to be caught for quiet some time, until it is very hard to revert. On the >> other hand, if a query is made, reviewed by community, and later many >> people try going through it, accepting and rejecting changes, we will know >> if we caught all the corner cases like the one you just gave. If noone has >> rejected anything for a long time, a bot can simply pick up the query and >> finish running it. Much safer. >> > > I don't see how your tool will stop (say) an American making this sort > of assumption, and edit? How should community review happen in your > tool? I'm not going to monitor your wiki page. Automated edits should be > discussed on the talk or imports mailing list. But I don't think you've > done that for the queries you've done already, and I'm not sure how your > programme requires that. > > > As for "community consensus" - TBH, very hard to define. >> > > Agreed. > ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] New OSM Quick-Fix service
On 16/10/17 14:02, Yuri Astrakhan wrote: Rory, thanks, and that's why I think it is a bad idea to do bot edits without first running it through my tool. If we do a mass edit, we have to go through a very lengthy community consensus study, which might still miss things. Then the bot developer might still make an error that is not likely to be caught for quiet some time, until it is very hard to revert. On the other hand, if a query is made, reviewed by community, and later many people try going through it, accepting and rejecting changes, we will know if we caught all the corner cases like the one you just gave. If noone has rejected anything for a long time, a bot can simply pick up the query and finish running it. Much safer. I don't see how your tool will stop (say) an American making this sort of assumption, and edit? How should community review happen in your tool? I'm not going to monitor your wiki page. Automated edits should be discussed on the talk or imports mailing list. But I don't think you've done that for the queries you've done already, and I'm not sure how your programme requires that. As for "community consensus" - TBH, very hard to define. Agreed. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] New OSM Quick-Fix service
Rory, thanks, and that's why I think it is a bad idea to do bot edits without first running it through my tool. If we do a mass edit, we have to go through a very lengthy community consensus study, which might still miss things. Then the bot developer might still make an error that is not likely to be caught for quiet some time, until it is very hard to revert. On the other hand, if a query is made, reviewed by community, and later many people try going through it, accepting and rejecting changes, we will know if we caught all the corner cases like the one you just gave. If noone has rejected anything for a long time, a bot can simply pick up the query and finish running it. Much safer. As for "community consensus" - TBH, very hard to define. On Mon, Oct 16, 2017 at 7:49 AM, Rory McCann wrote: > On 15/10/17 15:14, Tobias Zwick wrote: > > 1. If this does not require humans because both tagging schemes are > > mutually translatable (i.e. lets say for sport=handball <-> > > sport=team_handball), then, the edit can be made automatically by a bot. > > Except that's not true. In Ireland "handball" is Gaelic Handball¹ > which is a one-on-one game, not a team sport (which is apparently a > different thing²). There are some sport=handball's tagged in Ireland. > Now the tag is clearly wrong, and we need to figure out something about > that. But if you just change sport=handball to sport=team_handball, then > you've entered incorrect data, based on incorrect assumptions. > > There is the use case where one tagging scheme has been deprecated by >> community consensus and one (combination of) tag(s) should be changed >> into another (combination of) tag(s) globally. >> > > Big question: What defines "community consensus"? > > Though, note, for all three cases, a prior consensus is required, either >> by prior discussion or by looking at what was previously agreed on in >> the wiki. That is the case for *any* organized re-tagging of existing >> tags. >> > > Not everyone (incl me) thinks that the wiki defines what a tag should > mean... > > > ¹ https://en.wikipedia.org/wiki/Gaelic_handball > ² https://en.wikipedia.org/wiki/Handball > > > ___ > talk mailing list > talk@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk > ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] New OSM Quick-Fix service
On 15/10/17 15:14, Tobias Zwick wrote: > 1. If this does not require humans because both tagging schemes are > mutually translatable (i.e. lets say for sport=handball <-> > sport=team_handball), then, the edit can be made automatically by a bot. Except that's not true. In Ireland "handball" is Gaelic Handball¹ which is a one-on-one game, not a team sport (which is apparently a different thing²). There are some sport=handball's tagged in Ireland. Now the tag is clearly wrong, and we need to figure out something about that. But if you just change sport=handball to sport=team_handball, then you've entered incorrect data, based on incorrect assumptions. There is the use case where one tagging scheme has been deprecated by community consensus and one (combination of) tag(s) should be changed into another (combination of) tag(s) globally. Big question: What defines "community consensus"? Though, note, for all three cases, a prior consensus is required, either by prior discussion or by looking at what was previously agreed on in the wiki. That is the case for *any* organized re-tagging of existing tags. Not everyone (incl me) thinks that the wiki defines what a tag should mean... ¹ https://en.wikipedia.org/wiki/Gaelic_handball ² https://en.wikipedia.org/wiki/Handball ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] New OSM Quick-Fix service
On Monday 16 October 2017, Marc Gemis wrote: > I was thinking about possible changes to the tool that would make it > a useful tool for the community, and at the same time not violating > any policy. Sure, if you want to do that. In my opinion there is however not really a need for more tools in that field. I don't think anyone who wants to do an automated edit in compliance with the guidelines is seriously limited by the lack of suitable tools. Most smaller tag editing tasks will be served very well by Overpass+JOSM and for larger tasks (which are very rare) you will want a fully scripted solution and not something interactive. -- Christoph Hormann http://www.imagico.de/ ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] New OSM Quick-Fix service
I was thinking about possible changes to the tool that would make it a useful tool for the community, and at the same time not violating any policy. On Mon, Oct 16, 2017 at 1:06 PM, Christoph Hormann wrote: > On Monday 16 October 2017, Marc Gemis wrote: >> Would Yuri's tool be OK, if the proposed changes were limited to >> objects that were created/last edited after survey to the person that >> is using the tool ? >> >> I was thinking of a scenario where people try to help with a >> tag-renaming proposal. >> Such a tool would be handy to help them locate all objects that they >> know well and retag them. > > I think you are missing the point here - this tool's only purpose is > doing automated edits. The discussion if and under what circumstances > automated edits are OK for the community is not the issue here, this is > already regulated by the automated edit policy. > > Creating a tool for doing automated edits is perfectly fine, but > designing it in a way and advertising it in a way that encourages > automated edits in ignorance of existing rules is not. > > You probably recall that we have had discussions in how far Maproulette > encourages mechanical edits > (http://www.openstreetmap.org/user/imagico/diary/40759) but Martijn has > always demonstrated he is aware of the problem and tries to avoid such > abuse, for example by not allowing anonymous challenges and not having > simple click through tasks with already fully predetermined editing > decisions. > > In summary so far i think it can be said developers in the OSM context > have overwhelmingly been responsible in the way they design tools in > compliance with the spirit of the OSM community. But this one is > clearly different in that regard. > > -- > Christoph Hormann > http://www.imagico.de/ > > ___ > talk mailing list > talk@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] New OSM Quick-Fix service
On Monday 16 October 2017, Marc Gemis wrote: > Would Yuri's tool be OK, if the proposed changes were limited to > objects that were created/last edited after survey to the person that > is using the tool ? > > I was thinking of a scenario where people try to help with a > tag-renaming proposal. > Such a tool would be handy to help them locate all objects that they > know well and retag them. I think you are missing the point here - this tool's only purpose is doing automated edits. The discussion if and under what circumstances automated edits are OK for the community is not the issue here, this is already regulated by the automated edit policy. Creating a tool for doing automated edits is perfectly fine, but designing it in a way and advertising it in a way that encourages automated edits in ignorance of existing rules is not. You probably recall that we have had discussions in how far Maproulette encourages mechanical edits (http://www.openstreetmap.org/user/imagico/diary/40759) but Martijn has always demonstrated he is aware of the problem and tries to avoid such abuse, for example by not allowing anonymous challenges and not having simple click through tasks with already fully predetermined editing decisions. In summary so far i think it can be said developers in the OSM context have overwhelmingly been responsible in the way they design tools in compliance with the spirit of the OSM community. But this one is clearly different in that regard. -- Christoph Hormann http://www.imagico.de/ ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] New OSM Quick-Fix service
Martin, could you take a look at my last reply to Tobias - I have actually expressed some concerns with bots in general (very surprisingly, considering my heavy involvement with it previously). I think this tool can actually make the path to bots easier for the community, making new bots safer and reduce the chance of an accidental programming bug -- Tobias "case #1". I do hear your concern about the "distributed auto-fix", and we should minimize the negative effect. I think the best way would be to have a good community process to propose, evaluate, and approve such queries. Currently, anyone can add create a challenge in MapRoulle without oversight. Only a few devs might see changes in Osmose or the JOSM's autofix (my reply to Tobias actually focuses on JOSM issue, and I think its the most important issue). Here, we could use our wiki to host all queries, e.g. a "proposed" page where everyone will be instructed to be very careful with the changes, as queries have not been extensively vetted, and "approved" - queries that even bots can run automatically. We could have both locally oriented and globally oriented queries. Basically, if anyone wants to cause havoc, they can do it with any tool, but if the person wants to really help, we can guide that help towards the most beneficial contribution. Lastly, it won't be too hard to track which query was used - I can add the query ID to the changeset tag, so if an experimental query starts getting mass-edited, it can be easily discovered. Hope this helps. On Mon, Oct 16, 2017 at 6:13 AM, Martin Koppenhoefer wrote: > Frederik: > >> I am appalled that after your abysmal OSM editing history where you more >> often than not ignored existing customs rules, while *claiming* to >> follow them, you're now building a service that entices others to do the >> same. >> > > > >> On Sat, Oct 14, 2017 at 6:09 AM Christoph Hormann wrote: >>> This is a tool to perform automated edits as per the automated edits >>> policy. A resposible developer of such a tool should inform its users >>> that making automated edits comes with certain requirements and that >>> not following these rules can result in changes being reverted and user >>> accounts being blocked. >>> >> > 2017-10-14 13:06 GMT+02:00 Yuri Astrakhan : > >> Christoph, I looked around Osmose and MapRoulette, and I don't see any >> such warnings . Could you elaborate how you would like these kinds of tools >> to promote good editing practices? Any UI ideas? I'll be happy to improve >> our tools on making sure they meet community expectations. >> > > > I agree with Christoph and Frederik, that this is oviously a tool to > perform (crowdsourced) automated edits, and although it is designed in a > way to make them look like individual contributions, the automated editing > guidelines should apply. I agree with Yuri that there is also (to some > lesser extent, as the editing is not performed by the tool) some > problematic potential in other QA tools like Osmose or "remote batch > fixing" tools like MapRoulette. > > The thing with remotely "fixing tags" is that people usually don't know > the situation on the ground and therefore hardly can make an individual > decision for the specific object. The proposed "one-click-solution" > encourages to do quick "fixes" without looking individually, and you even > refuse to notify people that they might be participating in an automated > edit. In examples like the one you gave, even if you look very hard, you > won't see something that confirms the proposed change (you will have to > know the place). I could imagine there are good cases where your tool can > facilitate fixing problems, e.g. with clear typos (highway=residental), but > changing from one tag to a combination of two is not one of them (either we > could make an automated edit, or if it's disputed, we wouldn't do it at > all, rather than sneaking it in via distributed automated editing). > > Cheers, > Martin > > ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] New OSM Quick-Fix service
Would Yuri's tool be OK, if the proposed changes were limited to objects that were created/last edited after survey to the person that is using the tool ? I was thinking of a scenario where people try to help with a tag-renaming proposal. Such a tool would be handy to help them locate all objects that they know well and retag them. m. On Mon, Oct 16, 2017 at 12:13 PM, Martin Koppenhoefer wrote: > Frederik: >> >> I am appalled that after your abysmal OSM editing history where you more >> often than not ignored existing customs rules, while *claiming* to >> follow them, you're now building a service that entices others to do the >> same. > > > >>> >>> On Sat, Oct 14, 2017 at 6:09 AM Christoph Hormann wrote: >>> This is a tool to perform automated edits as per the automated edits >>> policy. A resposible developer of such a tool should inform its users >>> that making automated edits comes with certain requirements and that >>> not following these rules can result in changes being reverted and user >>> accounts being blocked. > > > 2017-10-14 13:06 GMT+02:00 Yuri Astrakhan : >> >> Christoph, I looked around Osmose and MapRoulette, and I don't see any >> such warnings . Could you elaborate how you would like these kinds of tools >> to promote good editing practices? Any UI ideas? I'll be happy to improve >> our tools on making sure they meet community expectations. > > > > I agree with Christoph and Frederik, that this is oviously a tool to perform > (crowdsourced) automated edits, and although it is designed in a way to make > them look like individual contributions, the automated editing guidelines > should apply. I agree with Yuri that there is also (to some lesser extent, > as the editing is not performed by the tool) some problematic potential in > other QA tools like Osmose or "remote batch fixing" tools like MapRoulette. > > The thing with remotely "fixing tags" is that people usually don't know the > situation on the ground and therefore hardly can make an individual decision > for the specific object. The proposed "one-click-solution" encourages to do > quick "fixes" without looking individually, and you even refuse to notify > people that they might be participating in an automated edit. In examples > like the one you gave, even if you look very hard, you won't see something > that confirms the proposed change (you will have to know the place). I could > imagine there are good cases where your tool can facilitate fixing problems, > e.g. with clear typos (highway=residental), but changing from one tag to a > combination of two is not one of them (either we could make an automated > edit, or if it's disputed, we wouldn't do it at all, rather than sneaking it > in via distributed automated editing). > > Cheers, > Martin > > > ___ > talk mailing list > talk@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk > ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] New OSM Quick-Fix service
Frederik: > I am appalled that after your abysmal OSM editing history where you more > often than not ignored existing customs rules, while *claiming* to > follow them, you're now building a service that entices others to do the > same. > > On Sat, Oct 14, 2017 at 6:09 AM Christoph Hormann wrote: >> This is a tool to perform automated edits as per the automated edits >> policy. A resposible developer of such a tool should inform its users >> that making automated edits comes with certain requirements and that >> not following these rules can result in changes being reverted and user >> accounts being blocked. >> > 2017-10-14 13:06 GMT+02:00 Yuri Astrakhan : > Christoph, I looked around Osmose and MapRoulette, and I don't see any > such warnings . Could you elaborate how you would like these kinds of tools > to promote good editing practices? Any UI ideas? I'll be happy to improve > our tools on making sure they meet community expectations. > I agree with Christoph and Frederik, that this is oviously a tool to perform (crowdsourced) automated edits, and although it is designed in a way to make them look like individual contributions, the automated editing guidelines should apply. I agree with Yuri that there is also (to some lesser extent, as the editing is not performed by the tool) some problematic potential in other QA tools like Osmose or "remote batch fixing" tools like MapRoulette. The thing with remotely "fixing tags" is that people usually don't know the situation on the ground and therefore hardly can make an individual decision for the specific object. The proposed "one-click-solution" encourages to do quick "fixes" without looking individually, and you even refuse to notify people that they might be participating in an automated edit. In examples like the one you gave, even if you look very hard, you won't see something that confirms the proposed change (you will have to know the place). I could imagine there are good cases where your tool can facilitate fixing problems, e.g. with clear typos (highway=residental), but changing from one tag to a combination of two is not one of them (either we could make an automated edit, or if it's disputed, we wouldn't do it at all, rather than sneaking it in via distributed automated editing). Cheers, Martin ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] New OSM Quick-Fix service
Lester, the naming of this service is still a work in progress, and might have confused a few people. My apologies for that. I do plan to create a proper name, logo, domain name, and SSL certificate once I have some spare time. If anyone wants to take care of that, your help is appreciated. The new tool is not about the Wikidata database. My database could contain just the OSM data and this tool would be just as functional. The service shares some of the technology that was built for Wikidata, and it has a clone of the Wikidata database which some of the queries may optionally use if they want to. But if you look at the quick fixes page, there are 20 queries that do not use Wikidata, and only one query that does. So again, lets discuss the merits of this tool, just like Tobias did above, and leave the Wikidata out of this conversation, as it is not relevant. https://wiki.openstreetmap.org/wiki/Quick_fixes On Mon, Oct 16, 2017 at 3:59 AM, Lester Caine wrote: > On 15/10/17 22:04, Frederik Ramm wrote: > > You've built a query engine to work with OSM and > > Wikidata and are pushing that relentlessly, to a point where the > > decision of just how much Wikiadata linking we want in OSM is totally > > taken out of our hands. > > Seconded ... personally I have still to be convinced that wikidata is an > independent and reliable source, so will not be using it as a cross > reference. It may well be that OSM needs it's own secondary database > with the sort of cross references material SOME of which is slowly being > added to wikidata but wikidata is an independent and unrelated project > with it's own agenda ... > > -- > Lester Caine - G8HFL > - > Contact - http://lsces.co.uk/wiki/?page=contact > L.S.Caine Electronic Services - http://lsces.co.uk > EnquirySolve - http://enquirysolve.com/ > Model Engineers Digital Workshop - http://medw.co.uk > Rainbow Digital Media - http://rainbowdigitalmedia.co.uk > > ___ > talk mailing list > talk@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk > ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Could we just pause any wikidata edits for a month or two?
On 16/10/17 05:24, Minh Nguyen wrote: > When a Wikidata item is modified to link to a Wikipedia article (or > Wikivoyage article etc.), the Wikipedia article automatically links back > to the Wikidata item. This is a software feature made possible because > Wikipedia and Wikidata are colocated in the same database cluster. No > bots are involved; this is unlike the process by which interwiki links > used to be maintained before Wikidata was introduced. > > When a Wikipedia article is renamed, it does temporarily get detached > from the Wikidata item because the task of updating the Wikidata item > falls to a process that runs asynchronously on a job queue. It isn't > possible for OpenStreetMap, as an external site, to automatically update > its wikipedia tags via the same mechanism. However, in principle, one > could write a bot that consumes Wikipedia's or Wikidata's recent changes > feed, looking for features to update. I'm not personally proposing to > run such a bot, to be clear. And one of the benefits of wikidata tags is > that such a bot would decrease in necessity over time, since Wikidata > QIDs are more stable. Minh ... I can see that there is potential to use the Wikidata QID's as a more stable path into wikipedia data. The way it is solving the problem of accessing translated versions of wikipedia articles is looking good, but I think it will be some time before it is totally mastered? Some translations are completely different articles? The problem I still see is that many of the items I am looking to link to are elements of an article rather than the whole article, such as the location of the works of a particular artist. At some point in the future wikidata may well have a complete index of QID's for every artist's work, but currently I don't have the time to add wikidata entries where they don't exist, so a link to the artists wikipedia article which may or may not actually list this particular work is second best and in many cases there is not even an english version :( Some bot then modifying that link out of context is not helpful and while the idea of 'nobot' flags may seem a solution, it's just adding another layer of complexity which potentially needs to exist for EVERY tag on EVERY object. Something I don't think should be allowed! This is just an example but there are hundreds of areas where the object being identified is part of one or more wikipedia article in one or more language, so the use of this data in the OSM dataspace needs to be managed by OSM and only a small part can be automated using the feeds from the wikidata bot's? Even if it is OSM bots that are doing the processing. The annoying thing here is that the hierarchy of places that wikidata provides could be useful to OSM searches ... but it still needs the likes of Nominatim and/or GeoNames to cross reference that data which provides an alternate secondary database. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] New OSM Quick-Fix service
On 15/10/17 22:04, Frederik Ramm wrote: > You've built a query engine to work with OSM and > Wikidata and are pushing that relentlessly, to a point where the > decision of just how much Wikiadata linking we want in OSM is totally > taken out of our hands. Seconded ... personally I have still to be convinced that wikidata is an independent and reliable source, so will not be using it as a cross reference. It may well be that OSM needs it's own secondary database with the sort of cross references material SOME of which is slowly being added to wikidata but wikidata is an independent and unrelated project with it's own agenda ... -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Hardware partnership and projects wishlist
2017-10-16 4:26 GMT+02:00 Daniel Koć : > Hi, > > I'm looking for partners with hardware resources in Poland to use it for > some interesting OSM-related projects. > > I've made basic research with OSMF, French and German pages about hardware > and network connectivity and it looks like they collaborate with academic > and business world: > > - https://hardware.openstreetmap.org/thanks/ > > - https://www.openstreetmap.fr/soutiens > > - https://wiki.openstreetmap.org/wiki/FOSSGIS/Server > > What are your experience with such collaborations in different places (not > only in GB, FR and DE)? Any advices or warnings? > In Italy some projects are running on: - personal hardware, - research centres hardware, - WMF virtual machines > > I have few ideas what could be done with enough hardware resources > available, but I'm also interested what other people think could be the > most wanted and useful projects for the OSM community? > > > -- > "My method is uncertain/ It's a mess but it's working" [F. Apple] > > > ___ > talk mailing list > talk@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk > ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
