subject:"Re\: \[OSM\-talk\] New OSM Quick\-Fix service"

@mmd,

I have noticed that the proposed fixes were not marked with vote=1. I fixed
them.
https://wiki.openstreetmap.org/wiki/Quick_fixes#Proposed_fixes

I'm not sure if vote=1 is needed for the multiple-choice challenges. They
were originally copied from the officially deprecated tags, so technically
they have already been discussed by the community. Also, I would think that
the person who changes amenity=education to college/school/university has
to have the local knowledge, or find business' website and research it
there?  Either case is fine of course.
https://wiki.openstreetmap.org/wiki/Quick_fixes#Multiple_Choice_Challenges

Lastly - in case of a manual edit (power mode), Sophox will set
"task_id=manual" to make them easier to find.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] New OSM Quick-Fix service

On Mon, Nov 13, 2017 at 6:02 PM, Michael Reichert 
wrote:

> Hi Yuri,
>
> Am 13.11.2017 um 22:58 schrieb Yuri Astrakhan:
> > Andy, I can only assume you agree with the rest of my argument. As for
> this
> > case -- this is not a mechanical edit. Per definition. I looked at each
> of
> > these three features, analyzed them, and thought this is a reasonable
> > change. You could call it a mistake (I am human), but it cannot be called
> > mechanical.
>
> Here comes another of our unwritten rules into play. Even if a
> systematical edit [1] is not a mechanical edit, it is sensible to
> discuss it beforehand as if it were a mechanical edit (although you
> could steps which involve the OSM wiki). This rule is unwritten but
> people who have followed discussions on any relevant mailing list or
> forum section will know it because some other users mentioned it there.
> That's why silently reading discussions for a while before doing
> possibly disruptive things in OSM is recommended (another unwritten rule).
>
> Michael, was there a URL [1] missing?   I 100% agree with you about this
unwritten rule, and that's why I am here too, discussing the tool and the
quick fix tasks. I might disagree with some of the hardliners, but thanks
to the discussion and feedback, Sophox tool has been substantially changed.
Also an existing rule in JOSM has been fixed.

The quick fixes have all been published, and I hope we can agree which ones
are non-conflicting. I do get a lot of animosity instead of fruitful
discussion, but despite that there has been a number of good comments that
helped it improve.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] New OSM Quick-Fix service

2017-11-13 Thread Branko Kokanovic

Hi all,
Lurking, but first time posting. I was trying to just ignore this
thread, but at this point, I had to add my 2c... My story: I am rather
new to OSM community (although I joined in 2009[1], probably before most
of you reading this:), came here (again) recently, full of optimism to
improve world (literally:). Created complete fancy tool to do fixes in
Serbia[2] and along the way, I learned about Sophox. This turned out to
be really cool tool to deal with problems we have in Serbia community
with 2 scripts (cyrillic/latin) and it helped me a lot, as you can
see[3]. Plan was even to get rid of my tool. I was also making plans
with Yuri to add support to query individual regions[4]!, and was eager
to work on that. However, I learned in this short period that this
community unfortunately has very fixed mindset (IMHO!). Yes, I can
understand rules you created around here and I understand needs for
them, and I tried really hard to obey all rules, stick to them, learn
new ones, not to get down whenever somebody interrogated my
changesets/reverted my whole day of work without asking, but now that
the bot I was doing work under is publicly mentioned in (IMHO) wrong
context, and now that it is banned, I cannot collect enough enthusiasm
to continue, I just give up from this unwelcoming community.
Don't get me wrong, I still think OSM is awesome, I will continue to
use it as always, but it is just not for me - it is clear that majority
of people here is strongly against mechanical edits (it's not about
Sophox really?) and I am kind of guy that thinks automation is
solution to everything:) (no, you should not take this literally!:) So,
all the good luck in this nice stringent community, but I will continue
to be just a user:)
Thanks, Branko

[1] https://www.openstreetmap.org/user/Branko%20Kokanovic
[2] https://github.com/stalker314314/serbian-osm-lint
[3] https://wiki.openstreetmap.org/wiki/Serbia/Sophox
[4] https://phabricator.wikimedia.org/T179991

On Tue, Nov 14, 2017, at 00:32, Yuri Astrakhan wrote:
> While it is easy to throw tons of accusations and be less civil, I
> will try maintain my level of decency.  I have forwarded you a snippet
> of one of the emails I received (without the sender name). Also, you
> are welcome to organize some independent person you trust in NYC to
> stop by and examine it in person, and I hope that person will be
> decent not to disclose the sender.> 
> I am still in this chat, despite the witch hunt. Which implies I do
> want to listen, and civilly communicate. The witch hunt is a fun
> activity for some, but others do provide useful feedback and comments,
> and that's why I am still hopeful.  Note that the ones who offered
> specific feedback and suggestions have not spoken yet after the
> changes, with the exception of @mmd (thanks!)> 
> Distorting what? I present my case. Most of the arguments are ignored.
> Tiny pieces of the emails get blown out of proportion.  I said a) why
> i do it, b) why i think its better than existing system, c) how it
> makes it easier to review/revert, unlike the current system. And I
> keep repeating these things from various angles, explaining that at
> the end of the day, this will make OSM better for everyone.  Instead,
> we are discussing everything but the above.> 
> _
> 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

While it is easy to throw tons of accusations and be less civil, I will try
maintain my level of decency.  I have forwarded you a snippet of one of the
emails I received (without the sender name). Also, you are welcome to
organize some independent person you trust in NYC to stop by and examine it
in person, and I hope that person will be decent not to disclose the sender.

I am still in this chat, despite the witch hunt. Which implies I do want to
listen, and civilly communicate. The witch hunt is a fun activity for some,
but others do provide useful feedback and comments, and that's why I am
still hopeful.  Note that the ones who offered specific feedback and
suggestions have not spoken yet after the changes, with the exception of
@mmd (thanks!)

Distorting what? I present my case. Most of the arguments are ignored. Tiny
pieces of the emails get blown out of proportion.  I said a) why i do it,
b) why i think its better than existing system, c) how it makes it easier
to review/revert, unlike the current system. And I keep repeating these
things from various angles, explaining that at the end of the day, this
will make OSM better for everyone.  Instead, we are discussing everything
but the above.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] New OSM Quick-Fix service

2017-11-13 Thread Andy Townsend


On 13/11/2017 22:31, Yuri Astrakhan wrote:
...  Maybe I should write up an FAQ with all the arguments raised 
here, and simply refer to them? It would save on typing.


No, maybe you should just listen and act on the feedback that you're 
getting here.  There have been an awful lot of replies in this thread, 
and the vast majority have been directly critical of what you're doing here.


As JB said earlier ("Did someone already said that you mix issues?"), 
you're deliberately trying to confuse and distort what people have said 
(also e.g. "I can only assume you agree with the rest of my argument").


In the mean time, I receive *multiple* private emails of support from 
people who feel intimidated to discuss it here


Ah, that old chestnut.  Unfortunately we have absolutely no evidence for 
this other than your word for it, and as you've not been entirely honest 
in the past*, such statements carry little weight.


Best Regards,
Andy

* https://lists.openstreetmap.org/pipermail/talk/2017-October/079085.html


___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] New OSM Quick-Fix service

@mmd, thanks, inline:

On Mon, Nov 13, 2017 at 5:32 PM, mmd  wrote:

> > * Added voting - experimental tasks require two users agreement to
> change DB
>
> I assumed this to be a mandatory part of the new process. However, some
> recent edits made by a "Serbian OSM Lint bot" [1] via your tool
> indicates that you can skip pretty much all of those safeguards, and
> still be able to run mass updates without any kind of voting, two user
> agreement, etc. Not sure, if this is intentional, or a bug.
>

The voting is meant to be used by the task authors when they publish
experimental tasks to the community. For example, if I write a new,
possibly contentious task that might cause significant disruption, and
decide to publish it to a large community, I should enable voting for that
task by setting "vote": true -- especially because most of the users might
not be experts in the specific change. If I simply use Sophox as my own
power editor, instead of JOSM/Level0/...,  I would edit things directly,
and follow the same rules as set for the rest of the community. In this
case, Serbian OSM Lint bot simply makes these changes directly. I think
that person used to add name:sr with a custom script and/or by hand, and
now simply uses Sophox for their work.

> * Made it simple to revert Sophox changes: changesets now contain
> > "task_id" to track task-related edits.
>
> Also, this seems to be optional:
> https://www.openstreetmap.org/changeset/53753685 has task_id =
> "undefined" and was editing via Sophox 0.5. Isn't this case handled in
> your tool to forbid creating such changesets in the first place?
>

This change was not done as part of a task, it was done in the "power
editor" mode (as described above).  I think task_id should be set to
something else though, instead of undefined, to indicate that the user is
using it in the power mode, and takes personal responsibility for all
changes. Or I could simply not add the task_id tag in those cases. BTW, I
think they should still use taskId in addition to the comment to better
track their work.

BTW, it is not possible to run a task without task id in a published
(embed) mode.  You can only run it as a task developer by hand (by editing
the query, clicking run button, and scrolling down into the results section)
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] New OSM Quick-Fix service

2017-11-13 Thread Michael Reichert

Hi Yuri,

Am 13.11.2017 um 22:58 schrieb Yuri Astrakhan:
> Andy, I can only assume you agree with the rest of my argument. As for this
> case -- this is not a mechanical edit. Per definition. I looked at each of
> these three features, analyzed them, and thought this is a reasonable
> change. You could call it a mistake (I am human), but it cannot be called
> mechanical.

Here comes another of our unwritten rules into play. Even if a
systematical edit [1] is not a mechanical edit, it is sensible to
discuss it beforehand as if it were a mechanical edit (although you
could steps which involve the OSM wiki). This rule is unwritten but
people who have followed discussions on any relevant mailing list or
forum section will know it because some other users mentioned it there.
That's why silently reading discussions for a while before doing
possibly disruptive things in OSM is recommended (another unwritten rule).

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

Thanks Christoph, I love #386 too.  As I repeatedly stated - my goal is to
allow simpler way for community to fix issues, which in turn would lower
data consumer entry barrier. Not prove someone incorrect (despite the
appearance). Several specific issues and suggestions were raised in this
thread, and they have been resolved. I proposed that we pick a some well
understood tasks for wider review, but instead we got bugged down with
level=0 debate. Many times I stated (what I hope is a) logical argument,
but a few people pick one tiny sentence out of the whole thing and argue
about that, or do a personal attack.  Maybe I should write up an FAQ with
all the arguments raised here, and simply refer to them? It would save on
typing. In the mean time, I receive *multiple* private emails of support
from people who feel intimidated to discuss it here - and I think this is
by far the most significant problem with this discussion, and community
health in general?

On Mon, Nov 13, 2017 at 5:13 PM, Christoph Hormann  wrote:

> On Monday 13 November 2017, Yuri Astrakhan wrote:
> > Andy, I can only assume you agree with the rest of my argument. [...]
>
> If you have made this assumption about anyone who you have communicated
> with in the OSM community in the past you would be well advised to stop
> that and review the views you have developed based on that assumption.
>
> https://xkcd.com/386/ is something something most of us have stopped
> doing relatively soon after we discovered the internet...
>
> --
> 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

2017-11-13 Thread mmd

Am 07.11.2017 um 07:29 schrieb Yuri Astrakhan:
> The tool has been thoroughly reworked, thanks to many good suggestions.
> Please keep discussion to constructive suggestions and ideas - they help
> us all move forward and reach agreement.
> 
> What's new:
> * Added "reject" vote button
> * Tasks can now offer multiple choices selection (thanks Tobias for the
> idea)
> * Added voting - experimental tasks require two users agreement to change DB

I assumed this to be a mandatory part of the new process. However, some
recent edits made by a "Serbian OSM Lint bot" [1] via your tool
indicates that you can skip pretty much all of those safeguards, and
still be able to run mass updates without any kind of voting, two user
agreement, etc. Not sure, if this is intentional, or a bug.


> * Users can "unvote" their own votes
> * Multiple changes per changeset
> * All votes are stored in the same RDF db, so the task can query it too.

> * Made it simple to revert Sophox changes: changesets now contain
> "task_id" to track task-related edits.

Also, this seems to be optional:
https://www.openstreetmap.org/changeset/53753685 has task_id =
"undefined" and was editing via Sophox 0.5. Isn't this case handled in
your tool to forbid creating such changesets in the first place?

[1] https://www.openstreetmap.org/user/Serbian%20OSM%20Lint%20bot


___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] New OSM Quick-Fix service

2017-11-13 Thread Michael Reichert

Hi Yuri,

Am 13.11.2017 um 13:20 schrieb Yuri Astrakhan:
> Christoph, I don't think this works for any community that grows beyond a
> certain size, especially when the community is not in the same
> location/building/land otherwise, and doesn't see each other every day.
> Look at Wikipedia, or any large social organization for that matter. At the
> village/startup level, you have very few codified rules, but as the group
> grows to a city/corporation size, it becomes more and more bureaucratic. We
> may not like it, but clear rules help community maintain cohesion, and
> prevents many conflicts.

No, it works. It works if someone is considerate and mindful and listens
(reads) what people write on mailing lists and forums. That's how I
learned how OSM works. I have read the mailing lists (Talk-de when it
was one of the most active mailing lists) and the German forum and
learned a lot of unwritten rules there. For example, the AGF rule, the
on the ground rule, to be friendly with newbies, not to blindly trust
satellite imagery and so on.

But if someone just bursts into a community instead of feeling his way,
it won't be a surprise if he violates a dozen of unwritten social rules
with one single action.

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

2017-11-13 Thread Christoph Hormann

On Monday 13 November 2017, Yuri Astrakhan wrote:
> Andy, I can only assume you agree with the rest of my argument. [...]

If you have made this assumption about anyone who you have communicated 
with in the OSM community in the past you would be well advised to stop 
that and review the views you have developed based on that assumption.

https://xkcd.com/386/ is something something most of us have stopped 
doing relatively soon after we discovered the internet...

-- 
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

2017-11-13 Thread Frederik Ramm

Hi,

On 11/13/2017 08:52 PM, Andy Townsend wrote:
> At the risk of repeating something that's been said multiple times
> previously, with JOSM autofixes you're performing edits in an area where
> you've already edited.  You're presumably somewhat familiar with what's
> there

I'll also repeat something I have mentioned a while ago in this thread:
People have been blocked and their edits reverted for blindly loading
one area after the other in JOSM and clicking the fix button without
having knowledge of or interest in the area, because that counted as a
mechanical edit. If someone does the same just without JOSM in the loop,
of course it's also a mechanical edit that requires prior discussion.

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

Andy, I can only assume you agree with the rest of my argument. As for this
case -- this is not a mechanical edit. Per definition. I looked at each of
these three features, analyzed them, and thought this is a reasonable
change. You could call it a mistake (I am human), but it cannot be called
mechanical.

I have contacted the original author, but haven't heard back.  Judging by
their site, it does look like both a marsh and a monument. You might want
to classify it as something else - that's where the tag expert is needed.
http://gardenseeds.swarthmore.edu/gardenseeds/2017/03/return-of-crumhenge/

On Mon, Nov 13, 2017 at 4:39 PM, Andy Townsend  wrote:

> On 13/11/2017 21:19, Yuri Astrakhan wrote:
>
>
> Andy, as I stated before, JOSM doesn't force you to edit in your area - it
> shows you whatever data you download. OverpassT can provide it to JOSM
> anywhere too. Your query in Sophox can be limited to an area, or can be
> anywhere - it all depends on the task's query. Also, you keep misusing the
> word "mechanical edit" (per wiki definition, see my other email).  Don't
> dilute the term.
>
>
> Unfortunately, a mechanical edit looks exactly like what you're doing -
> see https://www.openstreetmap.org/changeset/53598691 for example.  The
> tags on that as they stand (before or after your edit) don't make a whole
> lot of sense - likely there's a whole bunch of stuff there yet to be
> mapped, and maybe someone more familiar with the area would know if either
> the "memorial" or "marsh" tags make any sense.
>
> Best Regards,
> Andy
>
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] New OSM Quick-Fix service

2017-11-13 Thread Andy Townsend


On 13/11/2017 21:19, Yuri Astrakhan wrote:


Andy, as I stated before, JOSM doesn't force you to edit in your area 
- it shows you whatever data you download. OverpassT can provide it to 
JOSM anywhere too. Your query in Sophox can be limited to an area, or 
can be anywhere - it all depends on the task's query. Also, you keep 
misusing the word "mechanical edit" (per wiki definition, see my other 
email).  Don't dilute the term.




Unfortunately, a mechanical edit looks exactly like what you're doing - 
see https://www.openstreetmap.org/changeset/53598691 for example.  The 
tags on that as they stand (before or after your edit) don't make a 
whole lot of sense - likely there's a whole bunch of stuff there yet to 
be mapped, and maybe someone more familiar with the area would know if 
either the "memorial" or "marsh" tags make any sense.


Best Regards,
Andy

___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] New OSM Quick-Fix service

On Mon, Nov 13, 2017 at 2:52 PM, Andy Townsend  wrote:

> On 13/11/2017 19:36, Yuri Astrakhan wrote:
>
> > That's why I think Sophox is a much better and safer alternative to
> JOSM's autofixes.
>
> At the risk of repeating something that's been said multiple times
> previously, with JOSM autofixes you're performing edits in an area where
> you've already edited.  You're presumably somewhat familiar with what's
> there (you may even have actually visited in person and seen what it looks
> like on the ground). With your "tool" you're simply performing a mechanical
> edit with no experience of the underlying data.
>

Andy, as I stated before, JOSM doesn't force you to edit in your area - it
shows you whatever data you download. OverpassT can provide it to JOSM
anywhere too. Your query in Sophox can be limited to an area, or can be
anywhere - it all depends on the task's query. Also, you keep misusing the
word "mechanical edit" (per wiki definition, see my other email).  Don't
dilute the term.

My main point remains - doing a "by-the-way fixing" is worse than dedicated
effort to fix one issue at a time. Tagging experts who studied specific
issue, and who reviewed all relevant wiki notes and comment are better than
a local user who auto-accepts all JOSM-suggested fixes because they sound
reasonable, but who might have missed all the nuances of the specific tag
change. This makes it unrevertable and impossible to find. Also, it's bad
because if a user doesn't accept them, a subsequent editor eventually
will.  Local expertise needs to be balanced with tagging task expertise -
and sorry, there is no unicorn, who knows both perfectly.

In Rory's example - you cannot find who changed what in the past 16 months
for the bathroom autofix. You cannot revert it, because it is mixed with
others. My tool solves that, because experts can review it, and later
experts in that specific issue can review all found cases, and spot
errors.  Even if one person doing a Sophox task spots an error and tags it
as invalid, we can easily notice it and adjust or remove the task, and
easily revert all changes made for that task.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] New OSM Quick-Fix service

2017-11-13 Thread Andy Townsend


On 13/11/2017 19:36, Yuri Astrakhan wrote:

> That's why I think Sophox is a much better and safer alternative to 
JOSM's autofixes.


At the risk of repeating something that's been said multiple times 
previously, with JOSM autofixes you're performing edits in an area where 
you've already edited.  You're presumably somewhat familiar with what's 
there (you may even have actually visited in person and seen what it 
looks like on the ground).


With your "tool" you're simply performing a mechanical edit with no 
experience of the underlying data.


Best Regards,

Andy


___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] New OSM Quick-Fix service

On Mon, Nov 13, 2017 at 8:50 AM, Rory McCann  wrote:

> On 13/11/17 01:16, Yuri Astrakhan wrote:
>
>> if an accepted tool already does something in a certain way, and noone is
>> raising any objections to it, I think other software should follow in the
>> same foot steps.
>>
> > ...
>
>> I haven't heard anyone saying that JOSM validator autofixes do a bad
>> thing until this conversation. Do you think they are bad?
>>
>
> Yes, sometimes! I looked at your fixes, saw one that didn't make sense,
> (about unisex toilets) followed it to the JOSM validator, filed a bug which
> seems to be fixed ( https://josm.openstreetmap.de/ticket/15536 ).
>
> JOSM isn't perfect, "many eyes make all bugs shallow" etc.
>
> Great, thanks for spotting it! I will update the Sophox task shortly as
well.
But my statement about "tool doing something in a certain way" is not about
the specific task - as they can be buggy in every tool. I was talking about
the overall JOSM autofix approach that Sophox copies and attempts to
improve. I don't think your example argues against that.

On the contrary, your example shows that it is much better to have these
tasks standalone, with an expert oversight.  Right now you have no easy way
to find when users have auto-fixed the bathrooms using JOSM - there could
be none, or thousands.  And they are mixed together with other changes,
making it nearly impossible to revert. With Sophox, you can instantly find
them all, and review/revert them - simply search changsets for
task_id=josm_unisex_female_male_dup.  That's why I think Sophox is a much
better and safer alternative to JOSM's autofixes.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] New OSM Quick-Fix service

2017-11-13 Thread Rory McCann


On 13/11/17 01:16, Yuri Astrakhan wrote:
if an accepted tool already does something in a certain way, and 
noone is raising any objections to it, I think other software should 
follow in the same foot steps.

> ...
I haven't heard anyone saying that JOSM validator autofixes do a bad 
thing until this conversation. Do you think they are bad?


Yes, sometimes! I looked at your fixes, saw one that didn't make sense, 
(about unisex toilets) followed it to the JOSM validator, filed a bug 
which seems to be fixed ( https://josm.openstreetmap.de/ticket/15536 ).


JOSM isn't perfect, "many eyes make all bugs shallow" etc.



___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] New OSM Quick-Fix service

2017-11-13 Thread Frederik Ramm

Hi,

On 11/13/17 13:04, Christoph Hormann wrote:
> On Monday 13 November 2017, Yuri Astrakhan wrote:
>> Christoph, thanks for clarifying.  I should have been a bit more
>> careful with that word.  Could you clarify one thing - if wiki is not
>> authoritative for deprecation, than what is?  "Community consensus
>> that something is not to be used" has to be documented somewhere,
>> right?

> No, it does not have to.  It is the nature of most societies that not 
> all social rules that exist are also codified.  The process of becoming 
> a member of the OSM community to a large part consists of becoming 
> familiar with and developing an intuitive understanding of the 
> unwritten rules.

If I may add something here: OpenStreetMap has many unwritten rules and
this usually isn't a problem if someone goes through a normal
socialisation process - starting small with a few edits around their
house, looking around what others do, following a discussion or two,
etc.; they will pick up the rules as they go. This is just like in any
other society. It can go wrong when people from outside of OSM come in
and want to "hit the ground running", believing that their age, their
life experience, or their IT skills will automatically make them a
black-belt member of the OSM community. Upon noticing that there's maybe
more to OSM than can be seen from the API wiki page, some people try to
slow down and adapt, while others keep running and explain to everyone
in OSM how they're doing it wrong (or blame OSM for not having an
exhaustive handbook that you can study in order to avoid having to talk
to actual people).

Most rules that you find written in the Wiki were unwritten rules first,
and have been written down in order to make the onboarding easier for
new people - for example, we talked about "not tagging for the renderer"
long before http://wiki.openstreetmap.org/wiki/Tagging_for_the_renderer
existed. The wiki page now tries to explain that unwritten rule to
people, but that doesn't mean the wiki page *is* the rule. It's like
when you read in a travel guide that walking barefoot is frowned upon in
the country you plan to visit. The travel guide is trying to be helpful
so you don't embarrass yourself but the travel guide isn't the authority.

So yes, like Christoph says, in OSM community consensus isn't
necessarily written somewhere because you will learn about it while
becoming a member of the community. Even so, everyday normal mapping
(even by a total newbie) hardly ever falls foul of community consensus
if mappers let themselves be guided by presets and try do "blend in".

It works reasonably well on the whole.

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

Christoph, I don't think this works for any community that grows beyond a
certain size, especially when the community is not in the same
location/building/land otherwise, and doesn't see each other every day.
Look at Wikipedia, or any large social organization for that matter. At the
village/startup level, you have very few codified rules, but as the group
grows to a city/corporation size, it becomes more and more bureaucratic. We
may not like it, but clear rules help community maintain cohesion, and
prevents many conflicts.

On Mon, Nov 13, 2017 at 7:04 AM, Christoph Hormann  wrote:

> On Monday 13 November 2017, Yuri Astrakhan wrote:
> > Christoph, thanks for clarifying.  I should have been a bit more
> > careful with that word.  Could you clarify one thing - if wiki is not
> > authoritative for deprecation, than what is?  "Community consensus
> > that something is not to be used" has to be documented somewhere,
> > right?
>
> No, it does not have to.  It is the nature of most societies that not
> all social rules that exist are also codified.  The process of becoming
> a member of the OSM community to a large part consists of becoming
> familiar with and developing an intuitive understanding of the
> unwritten rules.
>
> --
> 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

2017-11-13 Thread Christoph Hormann

On Monday 13 November 2017, Yuri Astrakhan wrote:
> Christoph, thanks for clarifying.  I should have been a bit more
> careful with that word.  Could you clarify one thing - if wiki is not
> authoritative for deprecation, than what is?  "Community consensus
> that something is not to be used" has to be documented somewhere,
> right?

No, it does not have to.  It is the nature of most societies that not 
all social rules that exist are also codified.  The process of becoming 
a member of the OSM community to a large part consists of becoming 
familiar with and developing an intuitive understanding of the 
unwritten rules.

-- 
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

Christoph, thanks for clarifying.  I should have been a bit more careful
with that word.  Could you clarify one thing - if wiki is not authoritative
for deprecation, than what is?  "Community consensus that something is not
to be used" has to be documented somewhere, right?

Per https://wiki.openstreetmap.org/wiki/Automated_edits

*Automated edits* and *semi-automated edits* (sometimes called *mechanical
edits*) are changes made to OpenStreetMap content with no or very limited
human oversight, including those made by bots
, algorithmic processes, imports
 and also major
changes made using general-purpose map editing tools such as JOSM
.


This differs from your own definition. The wiki definition does not discuss
which features are being edited, or how I pick what to edit. It
concentrates on the oversight - if I oversee each change one by one, and
pay attention to it, by the above definition it is not an automated, nor a
mechanical edit. A bot is an automated edit. Loading things into JOSM, and
renaming 100 instances of tag "foo" into "bar" is a semi automated
(mechanical) edit, because both lack oversight for each change.

JD, The whole layer=0 conversation started with this message:

I have copied some of the JOSM & deprecation autofixes as Sophox tasks
> (quick fixes page). *Which of them would be good for the first review? *It
> should probably be more obvious, like replacing identical
> maxspeed:forward+maxspeed:backward with maxspeed tag, or removing
> layer=0, etc.
>
> As you can see, it was a call for a balanced discussion on what would be
good to fix, in a way Map Roulette and other fixing tools do it.  Instead,
we are now discussing if layer=0 and semantics.  I agree that using words
correctly is paramount to understanding each other, but if we target one
example, and blow it into multiple messages, it helps no one.


> I only think I will print Frederick's mails, and regularly read them again
> and again.
>
Frederick's mail have been very passionate, and they would be great for
uniting people for a cause, but I don't think they were as productive or
consensus reaching as some other emails. Vilifying your opponent does not
help the discussion - we are talking about ideas and tools, not persons.
Otherwise we end up with Facebook's opinion bubble, where both sides sit in
their own hall of mirrors, and don't try to reach any mutual understanding.


> I will not answer anymore to this thread. It feels too much like a
> scientific paper submission: If you answer to every objection, even
> sometimes with halt-truth, there will come a time when there is no more to
> say.
>

Using a word with a slightly different meaning is not the same as a
half-truth. Half-truth implies a lie. If you think I have lied or mislead,
say so, and explain where. Otherwise, this is baseless accusations.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] New OSM Quick-Fix service

2017-11-13 Thread Christoph Hormann

On Monday 13 November 2017, Yuri Astrakhan wrote:
>
> The wiki deprecation only lists one =no:  highway=no, but we are not
> discussing that one yet --
> https://wiki.openstreetmap.org/wiki/Deprecated_features
>
> I used the word "deprecated" in a more general term, to mean anything
> that community has decided to phase out, such as JOSM autofixes and
> deprecation list.

For the record (so people reading this later do not get a wrong 
impression) - 'deprecated' in the OSM context means that there is a 
community consensus that something is not to be used any more in new 
mapping.  The wiki, editor presets etc. are not authoritive in that 
regard and deprecation does not supersede the freedom of mappers to map 
how they see fit (in other words: it is not forbidden to use deprecated 
tags).

And automatic fixes in JOSM are not normally mechanical edits because 
they are only applied to features that are (manually) edited otherwise.  
Applying the same 'fixes' mechanically to all features with a certain 
tag however is a mechanical edit and needs to be discussed on a 
per-case basis - always, no matter how trivial, useful or obvious they 
might seem to anyone.

-- 
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

2017-11-13 Thread JB

I only think I will print Frederick's mails, and regularly read them 
again and again.
Deprecated implies «bad, should not exist in OSM database, no one 
reviewed this object for the last years». It has very strong 
implications in OSM vocabulary. Using it here would have the effect to 
readers «Yes, if it's deprecated, of course it should be deleted». No, 
they are not deprecated, they only are useless to software parsers. They 
may be useful for contributors.
I will not answer anymore to this thread. It feels too much like a 
scientific paper submission: If you answer to every objection, even 
sometimes with halt-truth, there will come a time when there is no more 
to say.

JB.

Le 13/11/2017 à 11:27, Yuri Astrakhan a écrit :
JB, try to avoid swearword outburst, not helpful. Are you taking issue 
with the word "deprecated"?   The proper word should probably have 
been "unnecessary" to discuss the layer=0, per JOSM's naming:
https://josm.openstreetmap.de/browser/josm/trunk/data/validator/unnecessary.mapcss 



The wiki deprecation only lists one =no:  highway=no, but we are not 
discussing that one yet -- 
https://wiki.openstreetmap.org/wiki/Deprecated_features


I used the word "deprecated" in a more general term, to mean anything 
that community has decided to phase out, such as JOSM autofixes and 
deprecation list.


I have no   clue what you meant otherwise about mixing issues. I am 
attempting to answer every possible question being raised. So far 
there has been a few very constructive and helpful emails, and lots of 
sidetracks. If you want to stay focused, re-read my initial post, as 
well as my most latest post with the new tool capabilities, or just 
read the Sophox wiki page and try to follow the style of Simon & 
Tobias - both have raised valid objections, and in both cases it 
resulted in tool's improvements.


On Mon, Nov 13, 2017 at 3:05 AM, JB > wrote:


Le 13/11/2017 à 01:16, Yuri Astrakhan a écrit :

You are right that =0 and =no seem like nobrainers, but if we
have listed them as deprecated, we should not use them.

Deprecated? Where did you find that?
(Swearwords somewhere here. Did someone already said that you mix
issues?)

___
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

JB, try to avoid swearword outburst, not helpful.  Are you taking issue
with the word "deprecated"?   The proper word should probably have been
"unnecessary" to discuss the layer=0, per JOSM's naming:
https://josm.openstreetmap.de/browser/josm/trunk/data/validator/unnecessary.mapcss

The wiki deprecation only lists one =no:  highway=no, but we are not
discussing that one yet --
https://wiki.openstreetmap.org/wiki/Deprecated_features

I used the word "deprecated" in a more general term, to mean anything that
community has decided to phase out, such as JOSM autofixes and deprecation
list.

I have no   clue what you meant otherwise about mixing issues. I am
attempting to answer every possible question being raised. So far there has
been a few very constructive and helpful emails, and lots of sidetracks. If
you want to stay focused, re-read my initial post, as well as my most
latest post with the new tool capabilities, or just read the Sophox wiki
page and try to follow the style of Simon & Tobias - both have raised valid
objections, and in both cases it resulted in tool's improvements.

On Mon, Nov 13, 2017 at 3:05 AM, JB  wrote:

> Le 13/11/2017 à 01:16, Yuri Astrakhan a écrit :
>
>> You are right that =0 and =no seem like nobrainers, but if we have listed
>> them as deprecated, we should not use them.
>>
> Deprecated? Where did you find that?
> (Swearwords somewhere here. Did someone already said that you mix issues?)
>
> ___
> 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

2017-11-13 Thread JB


Le 13/11/2017 à 01:16, Yuri Astrakhan a écrit :
You are right that =0 and =no seem like nobrainers, but if we have 
listed them as deprecated, we should not use them. 

Deprecated? Where did you find that?
(Swearwords somewhere here. Did someone already said that you mix issues?)

___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] New OSM Quick-Fix service

2017-11-12 Thread Yuri Astrakhan

@mmd, thanks, but I never said anything about oneway=no, and never proposed
to remove it.  Andy Townsend introduced that into the discussion, and JB
elaborated on it. It is not listed in the deprecated list, nor is it in
JOSM autofixes, so it is a moot point.  BTW, I did find oneway=1 ->
oneway=yes JOSM autofix and added it to Sophox (about 4,250 hits)  here


@JB, my only goal with this effort is to reduce the amount of work data
consumers must do to use our data, as I believe this to be a significant
enough problem that raises barrier of entry. You are right that =0 and =no
seem like nobrainers, but if we have listed them as deprecated, we should
not use them. Otherwise - why deprecate, if they still contain meaning?
Perhaps they are bad for discussing Sophox itself, and we should pick some
other deprecated or JOSM autofix.

Second, there is no mechanical edits here. Lets not dilute the meaning of
the words, otherwise eventually almost anything can be called that. These
are tasks, or "challenges", that allows users to review each case
independently, either agree, pick one of the solutions, or mark as invalid.
Some cases can be resolved based on the existing information, e.g. other
tags / satellite imagery / reading OSM wiki / local knowledge / visiting
other web sites.  Some cases require in-person visit to the location.
Sophox is not a magic bullet that will solve all such cases, it is just a
tool to fix some of the existing issues.

If someone points out a problem, surely it's better for the
> developer to think about whether they have a point, about whether your
> software should act this way, rather than just saying "But JOSM does it!".
>
Rory, I agree that any problem raised should be analyzed. At the same time,
if an accepted tool already does something in a certain way, and noone is
raising any objections to it, I think other software should follow in the
same foot steps. Because otherwise we are saying that only existing tool
could have an otherwise discouraged practice.

> Do *you* think removing layer=0 is a good idea? What is the objection to
> removing it?
>
I think that if the community deprecates anything, it should eventually be
fixed. Otherwise we keep creating multiple ways of specifying things, and
each data consumer must understand each of them, making it progressively
harder to parse, and raising the entry bar. This is a general statement
about all deprecation, not specifically layer=0.
The objections stated by Andy are that there *could* be cases when it is
useful to indicate that something exists above/below, but hasn't been drawn
yet.  This might be a valid objection (even though it was not backed up by
any specific examples), but 1) if it caries valid info, why was it
deprecated? 2) how widespread is this usecase? 3) why are we using
deprecated tags to indicate a problem, instead of using fixme= or note= ?
4) With the existing tooling (JOSM), there are very high chances that
someone would delete this tag without realizing it is needed for something.
My tool offers a way to spot and highlight it - shouldn't we use it asap to
find all such cases?

>
> Just because someone else does a bad thing doesn't mean you have to copy
> them. Is your tool merely "JOSM validator, but with SPARQL and on the web"?
>
I haven't heard anyone saying that JOSM validator autofixes do a bad thing
until this conversation. Do you think they are bad? Richard Fairhurst said
that JOSM has been exemplary in matching community editing approaches, and
Jo Hannes mentioned that JOSM's devs are always ready to fix any kind of
issue.  So lets agree - either this is a good feature, in which case other
tools should follow similar approaches, or it's bad, in which case we
should file bug reports, and other tools should rectify it - which Sophox
tries to do already.

My tool goals are listed here, and they have very little to do with SPARQL:
https://wiki.openstreetmap.org/wiki/Sophox#Sophox_design_goals
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] New OSM Quick-Fix service

2017-11-10 Thread mmd

Am 10.11.2017 um 09:57 schrieb JB:
> oneway=no have the same meaning as no information

Very careful with removing oneway=no! Some highway=* combinations have
oneway=yes per default, and oneway=no is used to override this default
value (!!).

Obviously, removing such a oneway=no tag with the intent of getting rid
of some "redundant" data causes real damage.

The Wiki is your friend: http://wiki.openstreetmap.org/wiki/Key:oneway

-- 




___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] New OSM Quick-Fix service

2017-11-10 Thread Rory McCann

If someone points out a problem, surely it's better for the
developer to think about whether they have a point, about whether your
software should act this way, rather than just saying "But JOSM does it!".

Do *you* think removing layer=0 is a good idea? What is the objection to
removing it?

Just because someone else does a bad thing doesn't mean you have to copy
them. Is your tool merely "JOSM validator, but with SPARQL and on the web"?

On 09/11/17 21:48, Yuri Astrakhan wrote:
JB, the "layer=0 removal" is one of the JOSM validations - it
automatically gets suggested to anyone editing an area with that object,
with the "fix" button autofixing it. JOSM doesn't have a "mark this
autofix as invalid" button, which means that even if you don't autofix
it, the next person reviewing the same area may. This sounds identical
to the issue raised by Simon above:
> ...you don't actually "confirm" that something is a good edit or not.
You only have the choice of making an edit or leaving it to others to
do. ... This makes the whole thing entirely equivalent to a mechanical edit.

So we should either A) remove it from JOSM, or B) define when it should
be kept vs deleted, because otherwise we are not being consistent with
requirements.

In JOSM:
https://josm.openstreetmap.de/browser/josm/trunk/data/validator/unnecessary.mapcss?rev=12999#L6

On Thu, Nov 9, 2017 at 5:56 AM, JB > wrote:

Le 08/11/2017 à 19:43, Yuri Astrakhan a écrit :

removing layer=0

Please don't. Once again, mapping is done by humans, and layer=0 IS
sometimes useful to humans, even if computers don't need it.

___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] New OSM Quick-Fix service

2017-11-10 Thread JB

I disagree once more. You are mixing two problems which are completly 
different. The one you introduce being easier to agree with than the one 
previously at hand.
Layer=0, oneway=no have the same meaning as no information. It can be 
useful in some cases, as explained by Andy. Deleting them have no impact 
on data consumers. If you are able to parse the oneway=* tag, I 
seriously hope you check the value. Having 0/no as a value should not 
disturbe your software, or you are doing it wrong (a renderer used to 
render oneway=-1 the same as oneway=yes. I hope you agree it was the 
consumer's fault, not OSM's).
Deprecated tags, badly applied new tags is another problem, that should 
be discussed with the community if a mecanical edit is done.

JB.

Le 10/11/2017 à 08:18, Yuri Astrakhan a écrit :
On Thu, Nov 9, 2017 at 4:07 PM, ajt1...@gmail.com 
 > wrote:

On 09/11/2017 20:48, Yuri Astrakhan wrote:

JB, the "layer=0 removal" is one of the JOSM validations - it
automatically gets suggested to anyone editing an area with
that object, with the "fix" button autofixing it. JOSM doesn't
have a "mark this autofix as invalid" button, which means that
even if you don't autofix it, the next person reviewing the
same area may. This sounds identical to the issue raised by
Simon above:
> ...you don't actually "confirm" that something is a good
edit or not. You only have the choice of making an edit or
leaving it to others to do. ... This makes the whole thing
entirely equivalent to a mechanical edit.

So we should either A) remove it from JOSM, or B) define when
it should be kept vs deleted, because otherwise we are not
being consistent with requirements.

No, the two aren't equivalent.  In JOSM, validator suggestions are
made after you've been editing in the area.  Typically where
"default tags" such as "layer=0" (or "oneway=no" for that matter)
are used are in places where something's an exception (maybe this
is the only cross-town two-way street) , or there's more
information to be mapped (maybe there's something yet to be mapped
over or under the "layer=0" way that's obvious from the context of
the data in the area).

Andy, "... obvious from the context of the data in the area" is the 
exact problem.  It may be obvious to you, but another mapper who may 
visit the same area might not be as experienced, and when they see a 
suggestion from JOSM, it will be obvious to them to remove it. And if 
not them, than the next person - making it equivalent to what Simon 
was saying - eventually there will be a person who will overlook your 
obvious context and who will heed to JOSM's advice. It's just a matter 
of time.

  All you're doing is blindly performing (or encouraging the
performance of) mechanical edits, where the mapper has no
knowledge of the local area.

Incorrect, I am encouraging tagging experts, the same experts that 
decide which tags should be used for what on the @tagging, to review 
just that specific tag, case by case, and decide if the tag should be 
fixed, or if a new rule should be made. Maybe the deprecation was a 
mistake, and there are legit use cases?

Ask yourself "in what way does removing layer=0 from a bunch of
ways improve the quality of OpenStreetMap?". It certainly adds no
valid data.  It could potentially remove information (if there's a
problem with something else also tagged layer=0 nearby that will
be obvious to a user of an interactive editor from context).

I strongly disagree, it greatly improves the quality of OSM, because 
it simplifies the work that every data consumer has to do.  The 
layer=0 is a tiny, perhaps less important subset of the big problem. 
If I am a data consumer, I need to handle every case. and if something 
can be stored in multiple ways, I need to handle all of them. And this 
increases my workload.

Fundamentally ,this is not about layer=0, but about all of the 
deprecated tagging.  For example, natural=marsh → natural=wetland + 
wetland=marsh -- this implies that every data processor has to know 
both of these tagging schemas.  And there are hundreds of others, with 
hundreds of thousands of cases.

If I am a large organization, I have enough resources to handle each 
case by my data team. So if OSM wants to cater to the deep pockets, 
leaving all these deprecated tagging behind is fine. But if we want 
individuals and small organizations to easily use the data without 
much effort, the data must be as clean and straightforward as 
possible. Otherwise every single data consumer has to redo the same 
work, and handle every corner case, or it ends up ignoring or 
mishandling many of them.

___
talk mailing list
talk@openstreetmap.org

Re: [OSM-talk] New OSM Quick-Fix service

2017-11-09 Thread Yuri Astrakhan

On Thu, Nov 9, 2017 at 4:07 PM, ajt1...@gmail.com  wrote:

> On 09/11/2017 20:48, Yuri Astrakhan wrote:
>
>> JB, the "layer=0 removal" is one of the JOSM validations - it
>> automatically gets suggested to anyone editing an area with that object,
>> with the "fix" button autofixing it. JOSM doesn't have a "mark this autofix
>> as invalid" button, which means that even if you don't autofix it, the next
>> person reviewing the same area may. This sounds identical to the issue
>> raised by Simon above:
>> > ...you don't actually "confirm" that something is a good edit or not.
>> You only have the choice of making an edit or leaving it to others to do.
>> ... This makes the whole thing entirely equivalent to a mechanical edit.
>>
>> So we should either A) remove it from JOSM, or B) define when it should
>> be kept vs deleted, because otherwise we are not being consistent with
>> requirements.
>>
>>
> No, the two aren't equivalent.  In JOSM, validator suggestions are made
> after you've been editing in the area.  Typically where "default tags" such
> as "layer=0" (or "oneway=no" for that matter) are used are in places where
> something's an exception (maybe this is the only cross-town two-way street)
> , or there's more information to be mapped (maybe there's something yet to
> be mapped over or under the "layer=0" way that's obvious from the context
> of the data in the area).

Andy, "... obvious from the context of the data in the area" is the exact
problem.  It may be obvious to you, but another mapper who may visit the
same area might not be as experienced, and when they see a suggestion from
JOSM, it will be obvious to them to remove it. And if not them, than the
next person - making it equivalent to what Simon was saying - eventually
there will be a person who will overlook your obvious context and who will
heed to JOSM's advice.  It's just a matter of time.

  All you're doing is blindly performing (or encouraging the performance
> of) mechanical edits, where the mapper has no knowledge of the local area.
>
Incorrect, I am encouraging tagging experts, the same experts that decide
which tags should be used for what on the @tagging, to review just that
specific tag, case by case, and decide if the tag should be fixed, or if a
new rule should be made. Maybe the deprecation was a mistake, and there are
legit use cases?

>
> Ask yourself "in what way does removing layer=0 from a bunch of ways
> improve the quality of OpenStreetMap?".  It certainly adds no valid data.
> It could potentially remove information (if there's a problem with
> something else also tagged layer=0 nearby that will be obvious to a user of
> an interactive editor from context).
>

I strongly disagree, it greatly improves the quality of OSM, because it
simplifies the work that every data consumer has to do.  The layer=0 is a
tiny, perhaps less important subset of the big problem. If I am a data
consumer, I need to handle every case. and if something can be stored in
multiple ways, I need to handle all of them. And this increases my workload.

Fundamentally ,this is not about layer=0, but about all of the deprecated
tagging.  For example, natural=marsh → natural=wetland + wetland=marsh --
this implies that every data processor has to know both of these tagging
schemas.  And there are hundreds of others, with hundreds of thousands of
cases.

If I am a large organization, I have enough resources to handle each case
by my data team. So if OSM wants to cater to the deep pockets, leaving all
these deprecated tagging behind is fine. But if we want individuals and
small organizations to easily use the data without much effort, the data
must be as clean and straightforward as possible. Otherwise every single
data consumer has to redo the same work, and handle every corner case, or
it ends up ignoring or mishandling many of them.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] New OSM Quick-Fix service

2017-11-09 Thread ajt1...@gmail.com


On 09/11/2017 20:48, Yuri Astrakhan wrote:
JB, the "layer=0 removal" is one of the JOSM validations - it 
automatically gets suggested to anyone editing an area with that 
object, with the "fix" button autofixing it. JOSM doesn't have a "mark 
this autofix as invalid" button, which means that even if you don't 
autofix it, the next person reviewing the same area may. This sounds 
identical to the issue raised by Simon above:
> ...you don't actually "confirm" that something is a good edit or 
not. You only have the choice of making an edit or leaving it to 
others to do. ... This makes the whole thing entirely equivalent to a 
mechanical edit.


So we should either A) remove it from JOSM, or B) define when it 
should be kept vs deleted, because otherwise we are not being 
consistent with requirements.




No, the two aren't equivalent.  In JOSM, validator suggestions are made 
after you've been editing in the area.  Typically where "default tags" 
such as "layer=0" (or "oneway=no" for that matter) are used are in 
places where something's an exception (maybe this is the only cross-town 
two-way street) , or there's more information to be mapped (maybe 
there's something yet to be mapped over or under the "layer=0" way 
that's obvious from the context of the data in the area).  All you're 
doing is blindly performing (or encouraging the performance of) 
mechanical edits, where the mapper has no knowledge of the local area.


Ask yourself "in what way does removing layer=0 from a bunch of ways 
improve the quality of OpenStreetMap?".  It certainly adds no valid 
data.  It could potentially remove information (if there's a problem 
with something else also tagged layer=0 nearby that will be obvious to a 
user of an interactive editor from context).


Best Regards,
Andy


___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] New OSM Quick-Fix service

2017-11-09 Thread Yuri Astrakhan

JB, the "layer=0 removal" is one of the JOSM validations - it automatically
gets suggested to anyone editing an area with that object, with the "fix"
button autofixing it.  JOSM doesn't have a "mark this autofix as invalid"
button, which means that even if you don't autofix it, the next person
reviewing the same area may. This sounds identical to the issue raised by
Simon above:
> ...you don't actually "confirm" that something is a good edit or not. You
only have the choice of making an edit or leaving it to others to do. ...
This makes the whole thing entirely equivalent to a mechanical edit.

So we should either A) remove it from JOSM, or B) define when it should be
kept vs deleted, because otherwise we are not being consistent with
requirements.

In JOSM:
https://josm.openstreetmap.de/browser/josm/trunk/data/validator/unnecessary.mapcss?rev=12999#L6

On Thu, Nov 9, 2017 at 5:56 AM, JB  wrote:

> Le 08/11/2017 à 19:43, Yuri Astrakhan a écrit :
>
>> removing layer=0
>>
> Please don't. Once again, mapping is done by humans, and layer=0 IS
> sometimes useful to humans, even if computers don't need it.
>
>
>
> ___
> 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

2017-11-09 Thread JB


Le 08/11/2017 à 19:43, Yuri Astrakhan a écrit :

removing layer=0
Please don't. Once again, mapping is done by humans, and layer=0 IS 
sometimes useful to humans, even if computers don't need it.



___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] New OSM Quick-Fix service

2017-11-08 Thread Yuri Astrakhan

Thanks Mikel, very well put.

There are currently hundreds of deprecated features & JOSM validations,
with hundreds of thousands of instances. They seem to be good candidates
for community reviewing and fixing. Some of them have been there for over
10 years without being addressed. Setting up a bot to do them may cause
more problems than solving, but the Sophox tasks should help. Reviewing
each change one by one should help spot cases when the change should NOT
happen, and either be fixed manually, or the Sophox query needs changing.
Sophox tags each changset with a task ID, so it will be very easy to undo
in case of a wide-scale error.  This makes Sophox much safer than when
multiple types of changes are combined in the same changeset.

I have copied some of the JOSM & deprecation autofixes as Sophox tasks
(quick fixes page). Which of them would be good for the first review? It
should probably be more obvious, like replacing identical
maxspeed:forward+maxspeed:backward with maxspeed tag, or removing layer=0,
etc.

* https://wiki.openstreetmap.org/wiki/Quick_fixes

Thanks!

On Wed, Nov 8, 2017 at 10:35 AM, Mikel Maron  wrote:

> Hey everyone -- let's do stick to the topic at hand. My takeaways from the
> good points on the discussion here from Frederik and Yuri.
>
> * It's ok to have different points of view
> * Being respectful of each other is important. Very important
> * Let's not make disagreements personal
>
> Online communication is hard. We are missing all the context and cues from
> real life. Let's make an extra effort to get beyond the inevitable
> miscommunications when they crop up.
>
> -Mikel
>
> * Mikel Maron * +14152835207 <(415)%20283-5207> @mikel s:mikelmaron
>
>
> On Tuesday, November 7, 2017, 4:32:42 AM EST, Yuri Astrakhan <
> yuriastrak...@gmail.com> wrote:
>
>
> TLDR; Please read my previous email, and lets discuss the actual tool, its
> capabilities, and how it can fit and add value to OSM ecosystem, while
> minimizing potential negatives.
>
> Frederik, I have offered to have a direct video conversation with you to
> better understand your concerns, explain my goals, and bring it back into
> productive scope, but no luck yet. I still hope you are more interested in
> resolving our differences than having a public tribune.  Lets not spend
> hours on emails, but try to understand each other's concerns in a private
> conversation, without involving the entire world.  I am sure what you think
> I am trying to do is substantially different from what I actually am trying
> to do, and my understanding of your concerns is also different from your
> actual concerns.
>
> If there is a large group of people who are trying to do something
> different from your strongly held believes, it means they have a problem
> you might not be aware about. In your example, "kick foreigners out" is a
> symptom of a problem - possibly related to people's insecurity or lack of
> education. Vilifying them and calling their ideas outrageous makes us feel
> righteous and united, but does not solve the actual problem or changes what
> they think - it actually exacerbates it, because both sides become more
> entrenched in their believes.
>
> So yes, I do want to keep our conversation constructive (not positive!) -
> understand concerns on all sides, and provide the most value to everyone
> involved.
>
>
> On Tue, Nov 7, 2017 at 2:57 AM, Frederik Ramm  wrote:
>
> Hi,
>
> On 07.11.2017 07:29, Yuri Astrakhan wrote:
> > Please keep discussion to constructive suggestions and ideas - they help
> > us all move forward and reach agreement.
>
> I have a general remark about statements like the above, that is not
> related to your specific tool.
>
> Statements like this are aimed at silencing opposition. But that is
> neither fair, nor right, nor a good way for a community to move forward.
> Opposition must be allowed, and people who are in opposition must not be
> cast as "negative" (="bad").
>
> Just imagine if someone suggested something outrageous ("Let's deport
> all foreigners from or village") and then if someone says "no", they are
> told: "Please keep discussion to constructive suggestions and ideas".
> ("If you have a better idea on how to get rid of foreigners, we're all
> ears!")
>
> There are many ideas that are broken beyond repair, where the basic
> tenets are already so wrong that no constructive suggestion can ever
> make it good. Rejecting such ideas is good, and a valuable contribution.
>
> Please don't try to silence opposing voices by limiting discussion to
> "constructive suggestions".
>
> As I said, this is not aimed specifically at you; I think the last time
> I said it was in a discussion about a tree import where the importers
> asked critics to simply take their energy elsewhere instead of being
> "negative" about the import.
>
> Bye
> Frederik
>
> --
> Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"
>
>

Re: [OSM-talk] New OSM Quick-Fix service

2017-11-08 Thread Mikel Maron

Hey everyone -- let's do stick to the topic at hand. My takeaways from the good 
points on the discussion here from Frederik and Yuri.
* It's ok to have different points of view* Being respectful of each other is 
important. Very important* Let's not make disagreements personal
Online communication is hard. We are missing all the context and cues from real 
life. Let's make an extra effort to get beyond the inevitable miscommunications 
when they crop up.
-Mikel
* Mikel Maron * +14152835207 @mikel s:mikelmaron 

On Tuesday, November 7, 2017, 4:32:42 AM EST, Yuri Astrakhan 
 wrote:  

 TLDR; Please read my previous email, and lets discuss the actual tool, its 
capabilities, and how it can fit and add value to OSM ecosystem, while 
minimizing potential negatives.
Frederik, I have offered to have a direct video conversation with you to better 
understand your concerns, explain my goals, and bring it back into productive 
scope, but no luck yet. I still hope you are more interested in resolving our 
differences than having a public tribune.  Lets not spend hours on emails, but 
try to understand each other's concerns in a private conversation, without 
involving the entire world.  I am sure what you think I am trying to do is 
substantially different from what I actually am trying to do, and my 
understanding of your concerns is also different from your actual concerns.
If there is a large group of people who are trying to do something different 
from your strongly held believes, it means they have a problem you might not be 
aware about. In your example, "kick foreigners out" is a symptom of a problem - 
possibly related to people's insecurity or lack of education. Vilifying them 
and calling their ideas outrageous makes us feel righteous and united, but does 
not solve the actual problem or changes what they think - it actually 
exacerbates it, because both sides become more entrenched in their believes.

So yes, I do want to keep our conversation constructive (not positive!) - 
understand concerns on all sides, and provide the most value to everyone 
involved.

On Tue, Nov 7, 2017 at 2:57 AM, Frederik Ramm  wrote:

Hi,

On 07.11.2017 07:29, Yuri Astrakhan wrote:
> Please keep discussion to constructive suggestions and ideas - they help
> us all move forward and reach agreement.

I have a general remark about statements like the above, that is not
related to your specific tool.

Statements like this are aimed at silencing opposition. But that is
neither fair, nor right, nor a good way for a community to move forward.
Opposition must be allowed, and people who are in opposition must not be
cast as "negative" (="bad").

Just imagine if someone suggested something outrageous ("Let's deport
all foreigners from or village") and then if someone says "no", they are
told: "Please keep discussion to constructive suggestions and ideas".
("If you have a better idea on how to get rid of foreigners, we're all
ears!")

There are many ideas that are broken beyond repair, where the basic
tenets are already so wrong that no constructive suggestion can ever
make it good. Rejecting such ideas is good, and a valuable contribution.

Please don't try to silence opposing voices by limiting discussion to
"constructive suggestions".

As I said, this is not aimed specifically at you; I think the last time
I said it was in a discussion about a tree import where the importers
asked critics to simply take their energy elsewhere instead of being
"negative" about the import.

Bye
Frederik

--
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

__ _
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.or g/listinfo/talk

___
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

2017-11-07 Thread Yuri Astrakhan

TLDR; Please read my previous email, and lets discuss the actual tool, its
capabilities, and how it can fit and add value to OSM ecosystem, while
minimizing potential negatives.

Frederik, I have offered to have a direct video conversation with you to
better understand your concerns, explain my goals, and bring it back into
productive scope, but no luck yet. I still hope you are more interested in
resolving our differences than having a public tribune.  Lets not spend
hours on emails, but try to understand each other's concerns in a private
conversation, without involving the entire world.  I am sure what you think
I am trying to do is substantially different from what I actually am trying
to do, and my understanding of your concerns is also different from your
actual concerns.

If there is a large group of people who are trying to do something
different from your strongly held believes, it means they have a problem
you might not be aware about. In your example, "kick foreigners out" is a
symptom of a problem - possibly related to people's insecurity or lack of
education. Vilifying them and calling their ideas outrageous makes us feel
righteous and united, but does not solve the actual problem or changes what
they think - it actually exacerbates it, because both sides become more
entrenched in their believes.

So yes, I do want to keep our conversation constructive (not positive!) -
understand concerns on all sides, and provide the most value to everyone
involved.

On Tue, Nov 7, 2017 at 2:57 AM, Frederik Ramm  wrote:

> Hi,
>
> On 07.11.2017 07:29, Yuri Astrakhan wrote:
> > Please keep discussion to constructive suggestions and ideas - they help
> > us all move forward and reach agreement.
>
> I have a general remark about statements like the above, that is not
> related to your specific tool.
>
> Statements like this are aimed at silencing opposition. But that is
> neither fair, nor right, nor a good way for a community to move forward.
> Opposition must be allowed, and people who are in opposition must not be
> cast as "negative" (="bad").
>
> Just imagine if someone suggested something outrageous ("Let's deport
> all foreigners from or village") and then if someone says "no", they are
> told: "Please keep discussion to constructive suggestions and ideas".
> ("If you have a better idea on how to get rid of foreigners, we're all
> ears!")
>
> There are many ideas that are broken beyond repair, where the basic
> tenets are already so wrong that no constructive suggestion can ever
> make it good. Rejecting such ideas is good, and a valuable contribution.
>
> Please don't try to silence opposing voices by limiting discussion to
> "constructive suggestions".
>
> As I said, this is not aimed specifically at you; I think the last time
> I said it was in a discussion about a tree import where the importers
> asked critics to simply take their energy elsewhere instead of being
> "negative" about the import.
>
> 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

2017-11-07 Thread Frederik Ramm

Hi,

On 07.11.2017 07:29, Yuri Astrakhan wrote:
> Please keep discussion to constructive suggestions and ideas - they help
> us all move forward and reach agreement.

I have a general remark about statements like the above, that is not
related to your specific tool.

Statements like this are aimed at silencing opposition. But that is
neither fair, nor right, nor a good way for a community to move forward.
Opposition must be allowed, and people who are in opposition must not be
cast as "negative" (="bad").

Just imagine if someone suggested something outrageous ("Let's deport
all foreigners from or village") and then if someone says "no", they are
told: "Please keep discussion to constructive suggestions and ideas".
("If you have a better idea on how to get rid of foreigners, we're all
ears!")

There are many ideas that are broken beyond repair, where the basic
tenets are already so wrong that no constructive suggestion can ever
make it good. Rejecting such ideas is good, and a valuable contribution.

Please don't try to silence opposing voices by limiting discussion to
"constructive suggestions".

As I said, this is not aimed specifically at you; I think the last time
I said it was in a discussion about a tree import where the importers
asked critics to simply take their energy elsewhere instead of being
"negative" about the import.

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

2017-11-06 Thread Yuri Astrakhan

The tool has been thoroughly reworked, thanks to many good suggestions.
Please keep discussion to constructive suggestions and ideas - they help us
all move forward and reach agreement.

What's new:
* Tool has a new name: Sophox
* Added "reject" vote button
* Tasks can now offer multiple choices selection (thanks Tobias for the
idea)
* Added voting - experimental tasks require two users agreement to change DB
* Users can "unvote" their own votes
* Multiple changes per changeset
* All votes are stored in the same RDF db, so the task can query it too.
* Added Mapbox satellite imagery
* Made it simple to revert Sophox changes: changesets now contain "task_id"
to track task-related edits.
* Added imagery tag to changeset
* Added domain name & https cert
* Many UI improvements, e.g. login / logoff / unread messages / icons
* Improve query parameter naming

Requirement:  Modern browser (tested on the latest Firefox and Chrome)
Full documentation:  https://wiki.openstreetmap.org/wiki/Sophox

Multiple choice example: changing from amenity=education to a more specific
one, e.g. amenity=school or university.
* http://tinyurl.com/y9tobxm8

Single choice example:  removing natural=water from the swimming pools
(should be checked with the satellite view)
* http://tinyurl.com/y84tlqzt

See more examples (single and multi-choice) here:
* https://wiki.openstreetmap.org/wiki/Quick_fixes

== Next steps ==
* address/fix any uncovered issues and concerns
* clean up wiki pages with tasks
* figure out the process when a task is OK to use without voting (direct
save, without the two person agreement)

== Moonshot goal ==
Mobile site/app that would bring up yes/no and multiple choice questions
from multiple tasks for the user's location. While I would love to do this,
lets discuss it in a separate thread if desired, as it is too far off at
this point.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] New OSM Quick-Fix service

2017-11-04 Thread Yuri Astrakhan

Hehe, fun picture, and the article seems to be covering the concept well.
Simon, I don't think anyone was arguing that sanatoriums should be switched
one way or the other globally.  As long as there is a clear conceptual
distinction between two types of features (whichever they are), and that
distinction is documented in a wiki, all is good.  A new mapper should be
told exactly which tags to use for each concept - no matter where in the
world they are.  Guessing the meaning based on the local interpretation of
the tag name/value is not a good approach.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] New OSM Quick-Fix service

2017-11-04 Thread Simon Poole

Slightly on topic
http://www.spiegel.de/panorama/gesellschaft/sanatorien-aus-der-sowjetzeit-urlaub-in-der-vergangenheit-a-1173776.html
is an article on Sowjet "sanatoriums" (sorry German only). Which
explains why our colleagues want to change the tagging, but  it just as
clearly shows that such changes should stay just in the former Eastern
Block countries if not even cover less territory.

Simon






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

2017-10-24 Thread Yuri Astrakhan

Ryszard, I have disabled the fixing from the "embed" mode - you can still
open the query (using "edit query"), click the "run" button (blue play
button), and fix things from there.

In my spare time, I am still working on the next version, based on all the
useful feedback:
* It will be easy to find the changes made for a specific task, and review
or revert them.
* It will be possible to "vote" on a change for an experimental task.
E.g., unless the task is marked as safe, two people will have to agree on a
change before it happens, assuming there are no "no" votes.
* It will be possible to have multiple choice tasks.
* multiple changes for the same task can go into the same changeset
* All votes will be stored in the same RDF database, making it possible to
use vote information in tasks.

I will write up a bit more about this project in a bit.  I think there was
a number of misconceptions about it, namely that it only relates to
Wikidata, and that its a bot rather than a platform for the community to
create and review tasks.

On Tue, Oct 24, 2017 at 8:04 AM, Ryszard Mikke 
wrote:

> Even without disabling - what a better tool fixes, JOSM's autofix won't
> find...
>
> On 17 October 2017 at 09:50, Yuri Astrakhan 
> wrote:
>
>> Well, you kind of can fix one with the other - by introducing a better
>> tool and disabling some of the autofixes in JOSM (very easy to do).  A more
>> complex approach would clearly require a separate topic(s) and a
>> substantial dev involvement.
>>
>> P.S. No, https://master.apis.dev.openstreetmap.org/ doesn't have any
>> real data (it shows maps from live servers, but editing shows just a few
>> objects).
>>
>> On Tue, Oct 17, 2017 at 3:36 AM, Tobias Zwick  wrote:
>>
>>> I get your point, especially regarding the appliance of the JOSM
>>> fix-button as a "by-the-way" fixing.
>>>
>>> Though, you can't fix possible issues with of one tool by introducing
>>> another tool. People will not stop using (that feature of) JOSM. That is
>>> why I think, if you think you detected a problematic issue there in that
>>> editor, it should be discussed in a separate topic.
>>>
>>> On 17/10/2017 00:57, Yuri Astrakhan wrote:
>>> > 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

Re: [OSM-talk] New OSM Quick-Fix service

2017-10-24 Thread Ryszard Mikke

Even without disabling - what a better tool fixes, JOSM's autofix won't
find...

On 17 October 2017 at 09:50, Yuri Astrakhan  wrote:

> Well, you kind of can fix one with the other - by introducing a better
> tool and disabling some of the autofixes in JOSM (very easy to do).  A more
> complex approach would clearly require a separate topic(s) and a
> substantial dev involvement.
>
> P.S. No, https://master.apis.dev.openstreetmap.org/ doesn't have any real
> data (it shows maps from live servers, but editing shows just a few
> objects).
>
> On Tue, Oct 17, 2017 at 3:36 AM, Tobias Zwick  wrote:
>
>> I get your point, especially regarding the appliance of the JOSM
>> fix-button as a "by-the-way" fixing.
>>
>> Though, you can't fix possible issues with of one tool by introducing
>> another tool. People will not stop using (that feature of) JOSM. That is
>> why I think, if you think you detected a problematic issue there in that
>> editor, it should be discussed in a separate topic.
>>
>> On 17/10/2017 00:57, Yuri Astrakhan wrote:
>> > 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

Re: [OSM-talk] New OSM Quick-Fix service

2017-10-20 Thread Richard

On Mon, Oct 16, 2017 at 12:13:12PM +0200, 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.

it could be used as an automated editing tool but perhaps this was
not the intention of the author?
Because - if you wanted to do automated editing there are much easier
and quicker methods.

Of course therer are many ways the tool should be improved before it
is used.

Richard

___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] New OSM Quick-Fix service

2017-10-17 Thread Yuri Astrakhan

Rory, I agree with you - there are always corner cases.  And while we
concentrate on the geographical aspect (e.g.  "somewhere there might be a
large territory where the tags mean different thing"), the corner case can
actually exist in our own neighborhood, simply because our neighbor
understood some tags to mean something different.

To use the a handball vs team_handball example - if it wasn't for you, no
one would have been aware of such a distinction, and if we had a @talk
discussion of the global bot autorename to fix it, there is a good chance
it __might__ have been overlooked, and damage would be done - we don't have
as many people monitoring @talk, as we have actually mapping things.  But
if someone made a challenge to convert handball->team_handball, someone
would have caught it in your area, thus flagging the issue globally,
documenting the distinction, and cleaning up the other areas where having a
mix of both values is incorrect.

On Tue, Oct 17, 2017 at 8:29 AM, Rory McCann  wrote:

> On 16/10/17 19:49, Tobias Zwick wrote:
>
>> 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.
>>
>
> The idea that automated edits and tag replacements on a worldwide scale
> are a bad idea and might have edge cases you've never heard about? 
>
> but it is the only documentation we have.
>>
>
> Not really. We have editors, and what they do, map styles and what they
> do, programmes like osm2pgsql and what they do. That's a form of
> "unwritten documentation".
>
>
>
> ___
> 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

2017-10-17 Thread Rory McCann


On 16/10/17 19:49, Tobias Zwick wrote:

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.


The idea that automated edits and tag replacements on a worldwide scale 
are a bad idea and might have edge cases you've never heard about? 



but it is the only documentation we have.


Not really. We have editors, and what they do, map styles and what they
do, programmes like osm2pgsql and what they do. That's a form of
"unwritten documentation".



___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] New OSM Quick-Fix service

2017-10-17 Thread Frederik Ramm

Hi,

On 17.10.2017 10:32, Yuri Astrakhan wrote:
> The thing is - we have been discussing hypothetical issues so far, not
> the real ones.

Users have been blocked and edits reverted for indiscriminately applying
JOSM's autofixer to large swaths of data. But those who do that are
usually aware that they are mis-using the feature, which is meant to
support you in mapping an area. The usual workflow is that you open
JOSM, choose an area to edit, and then use available material and
knowledge to improve the map in that area. It is not "some query directs
you to a random area, you open the editor and click the fix button just
as someone else has told you to".

> some hypothetical individual might not pay attention and go
> clicking trigger happy -- in other words we don't trust our users to be
> diligent. 

This is not a faithful argument. You have said, multiple times, that you
consider the diligence we ask of people a waste of time because certain
tasks could just as well be done by the computer. You have written a
tool that will, at least as currently presented, lower the diligence
standard.

> And that's the fundamental problem - we are worried about things that
> might happen, at the expense of ignoring significant number of existing
> data issues.

You are personally responsible for quite a few of these existing data
issues. -- Yes there are many bugs in OSM and there are many tools that
help find and fix them. Most fixes are not "quick", they require manual
intervention, switching on your brain, and usually knowledge of the
place or at the very least knowledge of the culture where the edit
happens. It appears to me that after the myriad of emails that have been
sent to you over the last half year, you still haven't understood that.
Initially I thought you simply needed some time to "get" OSM, but now I
am convinced that you don't really want to understand. You believe that
you are right and everyone else should finally admit that.

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

2017-10-17 Thread Yuri Astrakhan

Polyglot, I don't think there is a substantial **real** problem in JOSM
with the autofixes.  And yes, I have worked with JOSM devs and was
impressed at the speed of response.

The thing is - we have been discussing hypothetical issues so far, not the
real ones.   And hypothetically, allowing a simple way for users to review
one specific change on one object and click save is dangerous,  because
some hypothetical individual might not pay attention and go clicking
trigger happy -- in other words we don't trust our users to be diligent.
And so is **hypothetically** dangerous the JOSM's autofix feature,
especially because in JOSM, unilke the new tool, it is possible to click
"fix" without actually seeing what was changed.  On the other hand, JOSM's
autofix has been around for a long time, thus validating its own existence
by trial rather than by philosophy - or at least showing that for those
cases, the number of errors is so small, they don't surface to a major
community attention.

And that's the fundamental problem - we are worried about things that might
happen, at the expense of ignoring significant number of existing data
issues.  But I think this is fairly normal - after all, we are usually more
comfortable with a well understood existing problem than with a potential
unknown harm.

On Tue, Oct 17, 2017 at 4:13 AM, Jo  wrote:

> If there would be real problems with autofixes in JOSM, it's easy to
> report those as a bugs or enhancement requests. JOSM's issue tracker may be
> antiquated, but it does work and JOSM's developers are very responsive.
>
> If JOSM users who apply these auto fixes would worsen the data, then they
> would get remarks through their changeset messages. I'm convinced that if
> there are real problems on that side, we would already know about them and
> they would be fixed very fast. Most likely by disabling the fix button for
> that particular validator warning.
>
> So if you find actual issues, please report them.
>
> Polyglot
>
> 2017-10-17 9:50 GMT+02:00 Yuri Astrakhan :
>
>> Well, you kind of can fix one with the other - by introducing a better
>> tool and disabling some of the autofixes in JOSM (very easy to do).  A more
>> complex approach would clearly require a separate topic(s) and a
>> substantial dev involvement.
>>
>> P.S. No, https://master.apis.dev.openstreetmap.org/ doesn't have any
>> real data (it shows maps from live servers, but editing shows just a few
>> objects).
>>
>> On Tue, Oct 17, 2017 at 3:36 AM, Tobias Zwick  wrote:
>>
>>> I get your point, especially regarding the appliance of the JOSM
>>> fix-button as a "by-the-way" fixing.
>>>
>>> Though, you can't fix possible issues with of one tool by introducing
>>> another tool. People will not stop using (that feature of) JOSM. That is
>>> why I think, if you think you detected a problematic issue there in that
>>> editor, it should be discussed in a separate topic.
>>>
>>> On 17/10/2017 00:57, Yuri Astrakhan wrote:
>>> > 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

Re: [OSM-talk] New OSM Quick-Fix service

2017-10-17 Thread Jo

If there would be real problems with autofixes in JOSM, it's easy to report
those as a bugs or enhancement requests. JOSM's issue tracker may be
antiquated, but it does work and JOSM's developers are very responsive.

If JOSM users who apply these auto fixes would worsen the data, then they
would get remarks through their changeset messages. I'm convinced that if
there are real problems on that side, we would already know about them and
they would be fixed very fast. Most likely by disabling the fix button for
that particular validator warning.

So if you find actual issues, please report them.

Polyglot

2017-10-17 9:50 GMT+02:00 Yuri Astrakhan :

> Well, you kind of can fix one with the other - by introducing a better
> tool and disabling some of the autofixes in JOSM (very easy to do).  A more
> complex approach would clearly require a separate topic(s) and a
> substantial dev involvement.
>
> P.S. No, https://master.apis.dev.openstreetmap.org/ doesn't have any real
> data (it shows maps from live servers, but editing shows just a few
> objects).
>
> On Tue, Oct 17, 2017 at 3:36 AM, Tobias Zwick  wrote:
>
>> I get your point, especially regarding the appliance of the JOSM
>> fix-button as a "by-the-way" fixing.
>>
>> Though, you can't fix possible issues with of one tool by introducing
>> another tool. People will not stop using (that feature of) JOSM. That is
>> why I think, if you think you detected a problematic issue there in that
>> editor, it should be discussed in a separate topic.
>>
>> On 17/10/2017 00:57, Yuri Astrakhan wrote:
>> > 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
>> > >

Re: [OSM-talk] New OSM Quick-Fix service

2017-10-17 Thread Yuri Astrakhan

Well, you kind of can fix one with the other - by introducing a better tool
and disabling some of the autofixes in JOSM (very easy to do).  A more
complex approach would clearly require a separate topic(s) and a
substantial dev involvement.

P.S. No, https://master.apis.dev.openstreetmap.org/ doesn't have any real
data (it shows maps from live servers, but editing shows just a few
objects).

On Tue, Oct 17, 2017 at 3:36 AM, Tobias Zwick  wrote:

> I get your point, especially regarding the appliance of the JOSM
> fix-button as a "by-the-way" fixing.
>
> Though, you can't fix possible issues with of one tool by introducing
> another tool. People will not stop using (that feature of) JOSM. That is
> why I think, if you think you detected a problematic issue there in that
> editor, it should be discussed in a separate topic.
>
> On 17/10/2017 00:57, Yuri Astrakhan wrote:
> > 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
> >

Re: [OSM-talk] New OSM Quick-Fix service

2017-10-17 Thread Tobias Zwick

> 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.

I like this idea, that also goes into the right direction.
Something like this is what I had in mind when I said the tool should
not lend itself for a purpose it is intended for (mass re-taggings
without prior discussion and consensus).
> In the mean time, I will add the "two person approval required", which
> should alleviate expressed concern.  Should be ready fairly soon.

+1
A reject feature plus a two-person approval feature sounds like a
solution with which noone should have a problem with the tool thereafter.

___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] New OSM Quick-Fix service

2017-10-17 Thread Andy Townsend


On 17/10/2017 08:29, Tobias Zwick wrote:


Does the dev API have real (=mirrored) data?


It has whatever data you add to it.  I've used it in the past to 
demonstrate a "different way of mapping something" by copying everything 
from live to dev in a small area and then making the changes in that 
small area.


Best Regards,

Andy


___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] New OSM Quick-Fix service

2017-10-17 Thread Tobias Zwick

I get your point, especially regarding the appliance of the JOSM
fix-button as a "by-the-way" fixing.

Though, you can't fix possible issues with of one tool by introducing
another tool. People will not stop using (that feature of) JOSM. That is
why I think, if you think you detected a problematic issue there in that
editor, it should be discussed in a separate topic.

On 17/10/2017 00:57, Yuri Astrakhan wrote:
> 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
> 


___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] New OSM Quick-Fix service

2017-10-17 Thread Tobias Zwick

>> 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.

Does the dev API have real (=mirrored) data?

___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

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

2017-10-16 Thread Frederik Ramm

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

2017-10-16 Thread Tobias Zwick

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

Re: [OSM-talk] New OSM Quick-Fix service

2017-10-16 Thread Michael Reichert

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

2017-10-16 Thread Tobias Zwick

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] New OSM Quick-Fix service

2017-10-16 Thread Tobias Zwick

> 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] New OSM Quick-Fix service

2017-10-16 Thread Richard Fairhurst

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

2017-10-16 Thread Rory McCann


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

2017-10-16 Thread Rory McCann

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

2017-10-16 Thread Christoph Hormann

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

2017-10-16 Thread Marc Gemis

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

2017-10-16 Thread Christoph Hormann

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

2017-10-16 Thread Marc Gemis

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

2017-10-16 Thread Martin Koppenhoefer

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] New OSM Quick-Fix service

2017-10-16 Thread Lester Caine

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] New OSM Quick-Fix service

Tobias, as promised, a thorough response.

On Sun, Oct 15, 2017 at 9:14 AM, Tobias Zwick  wrote:

>
> So, the initial question is: What is the conceptual use case for such a
> tool? Where would be its place in the range of available OSM tools?
>

I think my main target is the JOSM validator's "fix" button. The fix button
allows contributors to auto-fix everything that validator has found, even
without looking at it.  In order to actually see what the autofix did, one
has to select all modified objects, select them all in the "selection"
window, hit "history", wait for all individual objects to download, and
then view individual changes one by one.  It requires a great deal of
dedication and diligence, especially considering that these auto-changes
will be combined with all the other changes the user might have made.
While I trust that many OSM contributors are highly skilled, this
complexity may lead to errors, especially as some people might not know the
exact steps required to view it, cut corners, or think that the "fix"
button should know what it's doing.  Lastly, if I spot a bad autofix, I
have to go to the antiquated JOSM issue reporting site, create an account,
and file a bug. Not an easy endeavor for most of the users, so most would
probably not bother. So the "FIX" button is similar to my "SAVE" button -
users either catch it and do nothing, or they don't, and it gets saved, if
not by this person than by next.

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.
>
> 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.
>

Here are a few of the existing JOSM autofixes done with my tool. See full
list at JOSM autofixes
.
* replace operator=ERDF -> operator=Enedis -- 5422 cases

* use  "cs:" instead of "cz:" prefix for Wikipedia links -- 3 cases

* fix duplicate Wikipedia tag prefixes, e.g.  "ru:ru:Something"  126 cases

While they probably should be ran by a bot, the barrier of entry is too
high to be realistic, especially for the smaller cases.  The very few
globally-licensed bot operators would probably not want to deal with these
small fixups, and for a very good reason - its not worth the risk! The
chance of a programming error far outweighs the benefits of the full
automation at so few objects. In addition to the programming error risks,
the community must have a far more thorough review of the proposal before
"bot-agreeing" to it - because what if there are corner cases that proposal
would break? This fear is what prevents the ease of bot adaption.

Lets look at a another example - a large 215,000+ cases autofix: removing
unnecessary "area=yes". These would greatly benefit from a bot edit, BUT
everyone makes coding mistakes, so there are some chances of a bad autofix.
If a bot owner makes a mistake, it can only be spotted AFTER running the
bot. A user would then post a message on the changeset, bot owner would
have to do a complex full/partial revert, fix the bot, and re-run it.
Painful. BTW, while doing these examples, I spotted a few potential bugs
with the existing JOSM autofixes that noone has reported - another reason
to put it through one-by-one accept/reject testing.

My tool would actually address these issues! When community first proposes
a change, it is relatively easy to add it to the tool - you simply write a
query and save it on a wiki page, possibly under the "proposed" section.
Then, many users can go through it one by one, accepting or rejecting them.
If there are rejects, anyone can go and fix the query, and the process
continues. Once this has been going on long enough, and there hasn't been
any rejects, some bot owner could simply run the exact same query on the
server, auto-applying it to the rest of the world. By that time, the query
has been well tested by many different members, and will be a much greater
quality than some bot author can ever do alone.

> 2. If this does require humans to check the transition to the new tag
> because the deprecated tagging scheme is ambiguous (i.e. , such as
> sport=football -> soccer or american/australian/canadian/... football),
> then, an automatic edit cannot be done. Instead, tools like MapRoulette
> are used.
>

I agree that my tool does not cover this use case yet.  I was thinking of
adding an option picker - a fairly easy task if the options are known in
advance, but this use case is not my primary target at the moment.

>
> 3. Finally, if this also does require humans because a tag combination
> is suspicious (what would show up as warnings in JOSM and what most of
>

Re: [OSM-talk] New OSM Quick-Fix service

2017-10-15 Thread Frederik Ramm

Yuri,

On 10/15/2017 11:53 AM, Yuri Astrakhan wrote:
> Christoph, kindly explain, instead of making snide remarks. You have not
> added to the discussion, but instead raised the level of toxicity of
> this channel even further.  Note that several people have already noted
> that this channel is toxic and refused to participate in it,

There's toxic talk and toxic behaviour. I have called you out because I
think that for the last half year, your behaviour has been toxic. You
have used nice and pleasant words, reassured us all that you mean no
evil, but if one looks at your actions, it is clear that you have very
little respect for OSM and how we've been doing things until now.

Now in certain circles that might be called "disruptive" and seen in a
positive way; but I think that disrupting OSM is not positive, and I
think you have been doing that very brazenly. When I attack you with
clear words, then that is a response to you attacking OSM with clear
actions, with a speed and intensity that few of us "spare time OSMers"
can match. Before we really had time to see what you were doing, you had
already automatically added often questionable Wikidata tags to tens of
thousands of objects. 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.

Repeatedly during the process, you have said things like "I don't see
why people should waste time on  when it can be done
automatically". Then some explained to you why it would be better and
more OSM-like to *not* do it automatically. And the next thing you do is
come up with a tool to allow even more de-facto automatic changes
because you either haven't understood, or simply don't care for how OSM
operates.

I think the latter is the case; you find it silly, backwards, a waste of
time to do what we do, and how we do it. To you, OSM is not a community
of people, it's just a database that can be queried, bulk-updated, and
bulk-updated again. Numerous efforts have been undertaken to explain
this to you but you just don't want to see it; you insist on treating
OSM, on treating us all, as if we were just too stupid to simply do a
few SQL updates on our database. Your "Quick Fix" tool is either a sign
that you have understood nothing and really believe that a tag change
edit can be "checked" by someone while looking at a zoom level 4 map, or
it is another brazen attempt at subverting our quality standards,
seducing even more people to make the kind of poor-quality,
lack-of-local-knowledge types of edits that you have often been
criticized for.

If you are harshly criticized then it is because your actions are
dangerous to OSM, and because you haven't listened to prior friendly
messages and warnings. You have harmed OSM, and when this was pointed
out to you, you harmed OSM even more, and now you're proudly presenting
a software that will help others to harm OSM. You have had ample
friendly warnings, but you have heaped toxic actions on toxic actions.

You have been criticised professionally and in a friendly way and you
replied along the lines of "thank you I will consider it", and continued
- again and again. This may look friendly on paper; you didn't use any
swear words and you always said thank you. But after a while, the "thank
yous" ring hollow. Your actions are treating OSM with disrespect, and
have been doing so for the last half year. You have no right to complain
about "toxicity".

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

2017-10-15 Thread Éric Gillet

2017-10-14 12:05 GMT+02:00 Christoph Hormann :

> On Friday 13 October 2017, Yuri Astrakhan wrote:
> > I would like to introduce a new quick-fix editing service.  It allows
> > users to generate a list of editing suggestions using a query, review
> > each suggestion one by one, and click "Save" on each change if they
> > think it's a good edit.
>
> 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.
>

Every editor can be used for "mechanical edits". The responsability of
doing correct changes and changesets lies on the user of such tools.
I don't think we can blame a tool for blind, thoughtless edits by users.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] New OSM Quick-Fix service

2017-10-15 Thread Stephen Doerr

On 15 October 2017, at 13:51, Yuri Astrakhan  wrote:

>Andy, first off, this whole email thread was about "hi, this is a new, rough 
>around the edges tool I'm building, that MIGHT benefit SOME people" 
>Suggestions/ideas welcome.  When you say "stop" - stop what? Stop coding?

The only thing I would say is, as the tool is clearly still at the 
proof-of-concept stage / in development, it should be hitting the test database 
and not the live one. It's not clear to me from what you've posted that that's 
the case: can you reassure us on that point?

Steve
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] New OSM Quick-Fix service

2017-10-15 Thread Dave F


It's both the splash screen & value for your created_by tag!

DaveF

On 15/10/2017 14:24, Yuri Astrakhan wrote:
Christoph, once again, what does Wikidata have to do with anything in 
this thread?  Wikidata is a heated and important point, and just today 
I saw another great use of it - https://opentripmap.com/en/ but this 
is totally irrelevant for the current discussion.



---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus


___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] New OSM Quick-Fix service

2017-10-15 Thread john whelan

>Thank you for a very well thought out analysis.

Surely the analysis should be done at the front of the project.  Making a
change during the project has costs.  The further you are into the project
normally the higher the cost is to correct something.  This is general not
specifically your project.

In this case the cost is either we end up with tatty data or some poor
muggings has to clean it up plus of course some reputational damage.

I suggest pausing and then defining the problem(s) you are trying to
address.  Once that is agreed then is the time to work out a solution that
is agreeable to more people than the present version.

Cheerio John

On 15 October 2017 at 09:24, Yuri Astrakhan  wrote:

> Tobias, this is the best and most constructive email I have seen yet!
> Thank you for a very well thought out analysis. I want to give it justice
> and do a thorough reply, but only after getting some sleep.  Thank you for
> restoring my faith in the proper communication.
>
> Christoph, once again, what does Wikidata have to do with anything in this
> thread?  Wikidata is a heated and important point, and just today I saw
> another great use of it - https://opentripmap.com/en/  but this is
> totally irrelevant for the current discussion.
>
> On Sun, Oct 15, 2017 at 9:14 AM, Tobias Zwick  wrote:
>
>> Hi Yuri
>>
>> I am not aware of the record of your previous interactions with the
>> community and I think you cannot be blamed to not respond to any toxic
>> feedback and/or accusations thrown at you here, whether they may be
>> justified or not.
>>
>> So, I give you the benefit of the doubt and write up this honest and
>> constructive feedback. Substantively, I come to the same conclusions as
>> the previous posters: That I find it hard to see that the app will have
>> any positive impact - at least "as is". I hope you value it nonetheless,
>> I also have some suggestions at the end.
>>
>> So, the initial question is: What is the conceptual use case for such a
>> tool? Where would be its place in the range of available OSM tools?
>>
>> 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.
>>
>> 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.
>>
>> 2. If this does require humans to check the transition to the new tag
>> because the deprecated tagging scheme is ambiguous (i.e. , such as
>> sport=football -> soccer or american/australian/canadian/... football),
>> then, an automatic edit cannot be done. Instead, tools like MapRoulette
>> are used.
>>
>> 3. Finally, if this also does require humans because a tag combination
>> is suspicious (what would show up as warnings in JOSM and what most of
>> Osmose consists of), also, a tool like Osmose or MapRoulette is used.
>>
>> 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.
>>
>> I reckon you see the quick fix tool to be in category 2 and 3 here,
>> along with MapRoulette and Osmose, only with the crucial advantage of
>> being quicker to use, since no editor is required.
>> But it seems to me, you didn't think this through. If the tool offers
>> *one* solution to any re-tagging ("Save" or leave it), then, this is
>> pretty much a manually operated automatic bot (case 1), which really
>> doesn't make sense. For case 2 and 3, it cannot be used as is, because:
>>
>> - Quick fix cannot be used to find what kind of football it is (case 2),
>> but MapRoulette can, because it leaves the actual editing to the user.
>>
>> - Quick fix cannot be used to solve any markers which may or may not be
>> an actual problem (case 3) because it has no way of marking any of the
>> things as false-positives.
>>
>> Looking at your linked Wiki document (
>> https://wiki.openstreetmap.org/wiki/Quick_fixes ), most of these are
>> candidates for automatic corrections. I.e.:
>> - Convert religion=Christian to religion=christian
>> - Convert various common forms of religion=catholic to
>> religion=christian + denomination=catholic
>> - Convert religion=islam to religion=muslim
>> - etc.
>>
>> (Only) your initial example ( amenity=sanatorium -> leisure=resort +
>> resort=sanatorium for ex-USSR-countries) falls in case 2. But then, as
>> mentioned, either marking as false-positives or other answer options
>> (i.e. "yes, it is a sanatorium in the West European sense") are missing.
>>
>> Okay, so much for why I think the tool is, as is, not fit to be used and
>> probably why you got so many negative responses here.
>>
>> *However*, the idea as such, to make the clean-up process of either

Re: [OSM-talk] New OSM Quick-Fix service

2017-10-15 Thread Dave F


Hi
"this tool has nothing to do with Wikidata"

"Currently, the tool creates two changeset tags:
 created_by=OSM+Wikidata 0.1"

Am I confused by what you mean by "this tool"?

DaveF

On 15/10/2017 13:04, Yuri Astrakhan wrote:
Andu, with all due respect, you are misrepresenting things.  I have 
received praises on OSM-RU channel, and that's where I got my first 
bug reports and suggestions that were quickly fixed.  The current 
mailing thread also received a praise from Steve. I have received a 
private email explicitly praising this tool, some twitter feedback, 
plus, some general encouragements for my efforts. So, despite some 
vocal people on one side of the issue, claiming to represent "the 
community" is not accurate, as others have expressed opposing views.  
Thus, it is not as uniform as you try to portray it, but rather, as 
any other conflict, deserves a thoughtful approach to attempt to 
balance goals of everyone, and to find a valuable compromise.


At the same time, judging from the fact that someone did not feel 
comfortable emailing to the group, there seems to be significant 
toxicity and bullying going on.  There was a number of personal 
attacks, which to me seems to be a violation of our communication 
policies, and which I deliberately ignore. So no, I see some people in 
the community may support it, but do not want to participate in such a 
violent discussion. When someone is foaming at the mouth, people tend 
to stay away, rather than engage in a constructive discussion.


Luckily, there has been some valuable feedback too, and I hope our 
community will be mature enough to provide more broadly.  For example, 
Simon was very clear and explicit about the exact deficiencies he 
objected to - something that I attempted to rectify, and will continue 
to improve on.  Some other remarks, despite being presented in a bad 
form, lead me to more good fixes such as a mandatory high zoom before 
editing. I am clearly continuing to participate in the discussion, and 
try to abstain from discussing PEOPLE, but instead concentrate on a 
specific IDEA being presented in this thread, and the specific 
PROBLEMS it tries to solve. As a volunteer. Without any financial 
benefit from anything I do. Same as many other participants on this 
channel, regardless of their views. Trying to maneuver between the 
abstract philosophy, various believes of what is the "right thing to 
do", and the specific problems and solutions.


P.S. @mmd, sorry for not replying earlier. I suspect you meant it as 
an "ad absurdum" argument. Thing is, Wikidata does use wiki pages to 
store bot states. Mostly bots generate various talk pages and 
templates, and users sometimes modify those talk pages to control the 
bots. Yet, this tool has nothing to do with Wikidata, so it is a moot 
point to discuss storing OSM metadata there. See my reply about the 
"nobot" tag. I think it would help to partially heal the bot-nobot 
divide, as it gives control over each object to editors, and allows 
mini-bots.


And one last thing.  Something that has helped me many times to find 
COMPROMISE in a forum discussion. When replying, let's try to sum up 
the opponent's position and the reasons for that position, and explain 
why you think it is incorrect. Perhaps we should learn from the high 
school debate class? Sorry for the long email.





---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus


___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] New OSM Quick-Fix service

Tobias, this is the best and most constructive email I have seen yet!
Thank you for a very well thought out analysis. I want to give it justice
and do a thorough reply, but only after getting some sleep.  Thank you for
restoring my faith in the proper communication.

Christoph, once again, what does Wikidata have to do with anything in this
thread?  Wikidata is a heated and important point, and just today I saw
another great use of it - https://opentripmap.com/en/  but this is totally
irrelevant for the current discussion.

On Sun, Oct 15, 2017 at 9:14 AM, Tobias Zwick  wrote:

> Hi Yuri
>
> I am not aware of the record of your previous interactions with the
> community and I think you cannot be blamed to not respond to any toxic
> feedback and/or accusations thrown at you here, whether they may be
> justified or not.
>
> So, I give you the benefit of the doubt and write up this honest and
> constructive feedback. Substantively, I come to the same conclusions as
> the previous posters: That I find it hard to see that the app will have
> any positive impact - at least "as is". I hope you value it nonetheless,
> I also have some suggestions at the end.
>
> So, the initial question is: What is the conceptual use case for such a
> tool? Where would be its place in the range of available OSM tools?
>
> 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.
>
> 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.
>
> 2. If this does require humans to check the transition to the new tag
> because the deprecated tagging scheme is ambiguous (i.e. , such as
> sport=football -> soccer or american/australian/canadian/... football),
> then, an automatic edit cannot be done. Instead, tools like MapRoulette
> are used.
>
> 3. Finally, if this also does require humans because a tag combination
> is suspicious (what would show up as warnings in JOSM and what most of
> Osmose consists of), also, a tool like Osmose or MapRoulette is used.
>
> 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.
>
> I reckon you see the quick fix tool to be in category 2 and 3 here,
> along with MapRoulette and Osmose, only with the crucial advantage of
> being quicker to use, since no editor is required.
> But it seems to me, you didn't think this through. If the tool offers
> *one* solution to any re-tagging ("Save" or leave it), then, this is
> pretty much a manually operated automatic bot (case 1), which really
> doesn't make sense. For case 2 and 3, it cannot be used as is, because:
>
> - Quick fix cannot be used to find what kind of football it is (case 2),
> but MapRoulette can, because it leaves the actual editing to the user.
>
> - Quick fix cannot be used to solve any markers which may or may not be
> an actual problem (case 3) because it has no way of marking any of the
> things as false-positives.
>
> Looking at your linked Wiki document (
> https://wiki.openstreetmap.org/wiki/Quick_fixes ), most of these are
> candidates for automatic corrections. I.e.:
> - Convert religion=Christian to religion=christian
> - Convert various common forms of religion=catholic to
> religion=christian + denomination=catholic
> - Convert religion=islam to religion=muslim
> - etc.
>
> (Only) your initial example ( amenity=sanatorium -> leisure=resort +
> resort=sanatorium for ex-USSR-countries) falls in case 2. But then, as
> mentioned, either marking as false-positives or other answer options
> (i.e. "yes, it is a sanatorium in the West European sense") are missing.
>
> Okay, so much for why I think the tool is, as is, not fit to be used and
> probably why you got so many negative responses here.
>
> *However*, the idea as such, to make the clean-up process of either
> clearly wrong tags, deprecated tags or even just warnings
> semi-automatic, is a very good one. The prerequisite is, that there must
> always be the option to *not* apply that fix and save that decision. The
> other very critical point is, that the easier you make it for users to
> apply a predefined fix, the more precautions must be taken to ensure
> that the user really checked the situation.
>
> So, the most critical missing features from my point of view in your
> tool are
>
> a) There must be an option to manually edit this instead and/or marking
> it as a false positive. In any case, the marker may not be shown for
> other users anymore. 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

Re: [OSM-talk] New OSM Quick-Fix service

2017-10-15 Thread Tobias Zwick

Hi Yuri

I am not aware of the record of your previous interactions with the
community and I think you cannot be blamed to not respond to any toxic
feedback and/or accusations thrown at you here, whether they may be
justified or not.

So, I give you the benefit of the doubt and write up this honest and
constructive feedback. Substantively, I come to the same conclusions as
the previous posters: That I find it hard to see that the app will have
any positive impact - at least "as is". I hope you value it nonetheless,
I also have some suggestions at the end.

So, the initial question is: What is the conceptual use case for such a
tool? Where would be its place in the range of available OSM tools?

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.

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.

2. If this does require humans to check the transition to the new tag
because the deprecated tagging scheme is ambiguous (i.e. , such as
sport=football -> soccer or american/australian/canadian/... football),
then, an automatic edit cannot be done. Instead, tools like MapRoulette
are used.

3. Finally, if this also does require humans because a tag combination
is suspicious (what would show up as warnings in JOSM and what most of
Osmose consists of), also, a tool like Osmose or MapRoulette is used.

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.

I reckon you see the quick fix tool to be in category 2 and 3 here,
along with MapRoulette and Osmose, only with the crucial advantage of
being quicker to use, since no editor is required.
But it seems to me, you didn't think this through. If the tool offers
*one* solution to any re-tagging ("Save" or leave it), then, this is
pretty much a manually operated automatic bot (case 1), which really
doesn't make sense. For case 2 and 3, it cannot be used as is, because:

- Quick fix cannot be used to find what kind of football it is (case 2),
but MapRoulette can, because it leaves the actual editing to the user.

- Quick fix cannot be used to solve any markers which may or may not be
an actual problem (case 3) because it has no way of marking any of the
things as false-positives.

Looking at your linked Wiki document (
https://wiki.openstreetmap.org/wiki/Quick_fixes ), most of these are
candidates for automatic corrections. I.e.:
- Convert religion=Christian to religion=christian
- Convert various common forms of religion=catholic to
religion=christian + denomination=catholic
- Convert religion=islam to religion=muslim
- etc.

(Only) your initial example ( amenity=sanatorium -> leisure=resort +
resort=sanatorium for ex-USSR-countries) falls in case 2. But then, as
mentioned, either marking as false-positives or other answer options
(i.e. "yes, it is a sanatorium in the West European sense") are missing.

Okay, so much for why I think the tool is, as is, not fit to be used and
probably why you got so many negative responses here.

*However*, the idea as such, to make the clean-up process of either
clearly wrong tags, deprecated tags or even just warnings
semi-automatic, is a very good one. The prerequisite is, that there must
always be the option to *not* apply that fix and save that decision. The
other very critical point is, that the easier you make it for users to
apply a predefined fix, the more precautions must be taken to ensure
that the user really checked the situation.

So, the most critical missing features from my point of view in your
tool are

a) There must be an option to manually edit this instead and/or marking
it as a false positive. In any case, the marker may not be shown for
other users anymore. 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.

b) I strongly suggest to offer different answer options. As I said, if
only one option is available, it is really nothing else than a manually
operated automatic edit. If several options are available (i.e.
"american football", "soccer" etc. ) as a quick fix, only then the tool
becomes to be useful. (There are some challenges like that on
MapRoulette also, such as "Phone or fax number is not in international
format" and these in my opinion also do not belong there because they
can be solved automatically)

c) Require users to zoom into the map at around zoom 17 or more to make
any changes. If the users are supposed to check if something is the case
(via satellite image), then at least don't let them cheat by just
solving

Re: [OSM-talk] New OSM Quick-Fix service

2017-10-15 Thread Christoph Hormann

On Sunday 15 October 2017, ajt1...@gmail.com wrote:
>
> You did indeed receive one message in your favour - I miscounted.
> That's 1 in favour, 1 question (from someone who has been critical
> elsewhere) and 7 against.  Maybe that counts as a majority in your
> favour in some places, but it doesn't here.

Indeed - and you should always be careful to make assumptions about 
the 'silent majority' of people who do not voice their opinion for one 
reason or another.  I for example know of quite a few people who in 
general have a positive attitude to either Wikidata or mechanical edits 
and want to explore the possibilities of these but who feel the 
attitude and approach of Yuri Astrakhan is inconsiderate, 
non-constructive and damaging.  I would wish more of them would speak 
up here but i also understand if they do not want to "pour oil into the 
fire" so to speak.

-- 
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

Andy, first off, this whole email thread was about "hi, this is a new,
rough around the edges tool I'm building, that MIGHT benefit SOME people"
Suggestions/ideas welcome.  When you say "stop" - stop what? Stop coding? I
have not done any significant amount of editing since last month, right
around the time when Wikidata debacle happened. Also, I think you are
ignoring what I said - others who are NOT on this thread have also
expressed support - and they have not spoken here, possibly due to the
toxic environment. When you say we voted - voted on what? Was there a
proposal? Was there a bad action being performed?

Re toxicity - these are not my words to qualify what has been going on, but
I do agree with them.  I cannot say that I have been perfect in all of my
responses, but I do try to keep them civil, and expect the same back.
Also, please reread my previous email, I tried to carefully express most
issues I encountered.

John, noone is saying its a consensus either way.  I am WORKING on finding
a compromise, while also building a tool that at least some people in some
communities find useful.   I did draw a comparison to at least two tools -
MapRoullette and Osmose. The first - mostly about building "challenges",
the second - in how it presented the editing interface. Osmose has many
more features than I do, allowing greater editing experience.  Also, I do
draw a comparison with RawEdit (Osmose) and Level0 - they both allow very
quick text editing of the raw XML content - a highly error-prone process
that I try to avoid.

On Sun, Oct 15, 2017 at 8:33 AM, john whelan  wrote:

> > I have received praises on OSM-RU channel,
>
> Wow, within the large number of active mappers there is a very broad range
> of opinions.  One or two people saying this is wonderful is not a
> consensus within OpenStreetMap that it is.
>
> Within OpenStreetMap the authority is normally accepted to be the local
> mappers and the DWG.  There are processes to follow for automated edits.
>
> I seem to recall you drawing a comparison between your work and
> MapRoulette.  MapRoulette identifies problems and has mappers resolve
> them one at a time.  My understanding is it does not make changes or add
> anything to the database.  Your approach seems to be quite different and I
> don't think the two can be compared.
>
> My understanding is you have not followed these processes and have ignored
> the wishes of local mappers.  This is not a personal attack these are
> issues and concerns.
>
> Could you be so kind as to address the issues and concerns raised please.
>
> Especially not taking into account the wishes of the local communities
> when expressed.
>
> Many Thanks
>
> Cheerio John
>
>
>
>
>
> On 15 October 2017 at 08:04, Yuri Astrakhan 
> wrote:
>
>> Andu, with all due respect, you are misrepresenting things.  I have
>> received praises on OSM-RU channel, and that's where I got my first bug
>> reports and suggestions that were quickly fixed.  The current mailing
>> thread also received a praise from Steve. I have received a private email
>> explicitly praising this tool, some twitter feedback, plus, some general
>> encouragements for my efforts. So, despite some vocal people on one side of
>> the issue, claiming to represent "the community" is not accurate, as others
>> have expressed opposing views.  Thus, it is not as uniform as you try to
>> portray it, but rather, as any other conflict, deserves a thoughtful
>> approach to attempt to balance goals of everyone, and to find a valuable
>> compromise.
>>
>> At the same time, judging from the fact that someone did not feel
>> comfortable emailing to the group, there seems to be significant toxicity
>> and bullying going on.  There was a number of personal attacks, which to me
>> seems to be a violation of our communication policies, and which I
>> deliberately ignore. So no, I see some people in the community may support
>> it, but do not want to participate in such a violent discussion. When
>> someone is foaming at the mouth, people tend to stay away, rather than
>> engage in a constructive discussion.
>>
>> Luckily, there has been some valuable feedback too, and I hope our
>> community will be mature enough to provide more broadly.  For example,
>> Simon was very clear and explicit about the exact deficiencies he objected
>> to - something that I attempted to rectify, and will continue to improve
>> on.  Some other remarks, despite being presented in a bad form, lead me to
>> more good fixes such as a mandatory high zoom before editing. I am clearly
>> continuing to participate in the discussion, and try to abstain from
>> discussing PEOPLE, but instead concentrate on a specific IDEA being
>> presented in this thread, and the specific PROBLEMS it tries to solve. As a
>> volunteer. Without any financial benefit from anything I do. Same as many
>> other participants on this channel, regardless of their views. Trying to
>> maneuver

Re: [OSM-talk] New OSM Quick-Fix service

2017-10-15 Thread john whelan

> I have received praises on OSM-RU channel,

Wow, within the large number of active mappers there is a very broad range
of opinions.  One or two people saying this is wonderful is not a consensus
within OpenStreetMap that it is.

Within OpenStreetMap the authority is normally accepted to be the local
mappers and the DWG.  There are processes to follow for automated edits.

I seem to recall you drawing a comparison between your work and MapRoulette.
MapRoulette identifies problems and has mappers resolve them one at a
time.  My understanding is it does not make changes or add anything to the
database.  Your approach seems to be quite different and I don't think the
two can be compared.

My understanding is you have not followed these processes and have ignored
the wishes of local mappers.  This is not a personal attack these are
issues and concerns.

Could you be so kind as to address the issues and concerns raised please.

Especially not taking into account the wishes of the local communities when
expressed.

Many Thanks

Cheerio John





On 15 October 2017 at 08:04, Yuri Astrakhan  wrote:

> Andu, with all due respect, you are misrepresenting things.  I have
> received praises on OSM-RU channel, and that's where I got my first bug
> reports and suggestions that were quickly fixed.  The current mailing
> thread also received a praise from Steve. I have received a private email
> explicitly praising this tool, some twitter feedback, plus, some general
> encouragements for my efforts. So, despite some vocal people on one side of
> the issue, claiming to represent "the community" is not accurate, as others
> have expressed opposing views.  Thus, it is not as uniform as you try to
> portray it, but rather, as any other conflict, deserves a thoughtful
> approach to attempt to balance goals of everyone, and to find a valuable
> compromise.
>
> At the same time, judging from the fact that someone did not feel
> comfortable emailing to the group, there seems to be significant toxicity
> and bullying going on.  There was a number of personal attacks, which to me
> seems to be a violation of our communication policies, and which I
> deliberately ignore. So no, I see some people in the community may support
> it, but do not want to participate in such a violent discussion. When
> someone is foaming at the mouth, people tend to stay away, rather than
> engage in a constructive discussion.
>
> Luckily, there has been some valuable feedback too, and I hope our
> community will be mature enough to provide more broadly.  For example,
> Simon was very clear and explicit about the exact deficiencies he objected
> to - something that I attempted to rectify, and will continue to improve
> on.  Some other remarks, despite being presented in a bad form, lead me to
> more good fixes such as a mandatory high zoom before editing. I am clearly
> continuing to participate in the discussion, and try to abstain from
> discussing PEOPLE, but instead concentrate on a specific IDEA being
> presented in this thread, and the specific PROBLEMS it tries to solve. As a
> volunteer. Without any financial benefit from anything I do. Same as many
> other participants on this channel, regardless of their views. Trying to
> maneuver between the abstract philosophy, various believes of what is the
> "right thing to do", and the specific problems and solutions.
>
> P.S. @mmd, sorry for not replying earlier. I suspect you meant it as an
> "ad absurdum" argument. Thing is, Wikidata does use wiki pages to store bot
> states. Mostly bots generate various talk pages and templates, and users
> sometimes modify those talk pages to control the bots. Yet, this tool has
> nothing to do with Wikidata, so it is a moot point to discuss storing OSM
> metadata there. See my reply about the "nobot" tag. I think it would help
> to partially heal the bot-nobot divide, as it gives control over each
> object to editors, and allows mini-bots.
>
> And one last thing.  Something that has helped me many times to find
> COMPROMISE in a forum discussion. When replying, let's try to sum up the
> opponent's position and the reasons for that position, and explain why you
> think it is incorrect. Perhaps we should learn from the high school debate
> class?  Sorry for the long email.
>
> On Sun, Oct 15, 2017 at 6:38 AM, ajt1...@gmail.com 
> wrote:
>
>> On 15/10/2017 11:04, Christoph Hormann wrote:
>>
>>> On Sunday 15 October 2017, Yuri Astrakhan wrote:
>>>
 [...] I was following up on the Christoph Hormann's
>> idea of the "bot=no" tag, to "allow mappers to opt out of bot
>> edits on a case-by-case basis."
>>
> No, you were not, likely because you misunderstood my suggestion
> which is likely because you don't get how OpenStreetMap is working
> overall.
>
> I would strongly advise you to reconsider your whole approach to
> OpenStreetMap and to interacting with the OpenStreetMap community.
>

Re: [OSM-talk] New OSM Quick-Fix service

2017-10-15 Thread ajt1...@gmail.com


On 15/10/2017 13:04, Yuri Astrakhan wrote:
Andu, with all due respect, you are misrepresenting things.  I have 
received praises on OSM-RU channel, and that's where I got my first 
bug reports and suggestions that were quickly fixed.  The current 
mailing thread also received a praise from Steve.


You did indeed receive one message in your favour - I miscounted. That's 
1 in favour, 1 question (from someone who has been critical elsewhere) 
and 7 against.  Maybe that counts as a majority in your favour in some 
places, but it doesn't here.


At the same time, judging from the fact that someone did not feel 
comfortable emailing to the group, there seems to be significant 
toxicity and bullying going on.

Your message to Christoph seems to be an attempt by you to do exactly that.

People are telling you to stop; you need to stop.

Any amount of dissembling by you won't change the facts.

Best Regards,

Andy


___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] New OSM Quick-Fix service

Andu, with all due respect, you are misrepresenting things.  I have
received praises on OSM-RU channel, and that's where I got my first bug
reports and suggestions that were quickly fixed.  The current mailing
thread also received a praise from Steve. I have received a private email
explicitly praising this tool, some twitter feedback, plus, some general
encouragements for my efforts. So, despite some vocal people on one side of
the issue, claiming to represent "the community" is not accurate, as others
have expressed opposing views.  Thus, it is not as uniform as you try to
portray it, but rather, as any other conflict, deserves a thoughtful
approach to attempt to balance goals of everyone, and to find a valuable
compromise.

At the same time, judging from the fact that someone did not feel
comfortable emailing to the group, there seems to be significant toxicity
and bullying going on.  There was a number of personal attacks, which to me
seems to be a violation of our communication policies, and which I
deliberately ignore. So no, I see some people in the community may support
it, but do not want to participate in such a violent discussion. When
someone is foaming at the mouth, people tend to stay away, rather than
engage in a constructive discussion.

Luckily, there has been some valuable feedback too, and I hope our
community will be mature enough to provide more broadly.  For example,
Simon was very clear and explicit about the exact deficiencies he objected
to - something that I attempted to rectify, and will continue to improve
on.  Some other remarks, despite being presented in a bad form, lead me to
more good fixes such as a mandatory high zoom before editing. I am clearly
continuing to participate in the discussion, and try to abstain from
discussing PEOPLE, but instead concentrate on a specific IDEA being
presented in this thread, and the specific PROBLEMS it tries to solve. As a
volunteer. Without any financial benefit from anything I do. Same as many
other participants on this channel, regardless of their views. Trying to
maneuver between the abstract philosophy, various believes of what is the
"right thing to do", and the specific problems and solutions.

P.S. @mmd, sorry for not replying earlier. I suspect you meant it as an "ad
absurdum" argument. Thing is, Wikidata does use wiki pages to store bot
states. Mostly bots generate various talk pages and templates, and users
sometimes modify those talk pages to control the bots. Yet, this tool has
nothing to do with Wikidata, so it is a moot point to discuss storing OSM
metadata there. See my reply about the "nobot" tag. I think it would help
to partially heal the bot-nobot divide, as it gives control over each
object to editors, and allows mini-bots.

And one last thing.  Something that has helped me many times to find
COMPROMISE in a forum discussion. When replying, let's try to sum up the
opponent's position and the reasons for that position, and explain why you
think it is incorrect. Perhaps we should learn from the high school debate
class?  Sorry for the long email.

On Sun, Oct 15, 2017 at 6:38 AM, ajt1...@gmail.com 
wrote:

> On 15/10/2017 11:04, Christoph Hormann wrote:
>
>> On Sunday 15 October 2017, Yuri Astrakhan wrote:
>>
>>> [...] I was following up on the Christoph Hormann's
> idea of the "bot=no" tag, to "allow mappers to opt out of bot
> edits on a case-by-case basis."
>
 No, you were not, likely because you misunderstood my suggestion
 which is likely because you don't get how OpenStreetMap is working
 overall.

 I would strongly advise you to reconsider your whole approach to
 OpenStreetMap and to interacting with the OpenStreetMap community.

>>> Christoph, kindly explain, instead of making snide remarks. You have
>>> not added to the discussion, but instead raised the level of toxicity
>>> of this channel even further.  Note that several people have already
>>> noted that this channel is toxic and refused to participate in it,
>>> rather than being productive and beneficial to everyone involved.
>>>
>> I rest my case.
>>
>>
> Yuri,
>
> In English there is a common phrase "which part of  *** do you not
> understand" (expletive removed because people offended by such words may be
> reading).
>
> This thread https://lists.openstreetmap.org/pipermail/talk/2017-October/
> thread.html#79145 currently has replies from 9 people.  1 is asking a
> question but all other replies are entirely negative (including comments
> such as "I'm appalled" and "that isn't acceptable behaviour").
>
> Christoph Hormann's comment above is not a snide remark; it's entirely
> reasonable based on your actions so far - for an example of that see Tomas'
> reply earlier in the thread, or indeed almost any of the other interactions
> that you've had with the OSM community.
>
> Best Regards,
> Andu
>
>
>
>
> ___
> talk mailing list
>

Re: [OSM-talk] New OSM Quick-Fix service

2017-10-15 Thread ajt1...@gmail.com


On 15/10/2017 11:04, Christoph Hormann wrote:

On Sunday 15 October 2017, Yuri Astrakhan wrote:

[...] I was following up on the Christoph Hormann's
idea of the "bot=no" tag, to "allow mappers to opt out of bot
edits on a case-by-case basis."

No, you were not, likely because you misunderstood my suggestion
which is likely because you don't get how OpenStreetMap is working
overall.

I would strongly advise you to reconsider your whole approach to
OpenStreetMap and to interacting with the OpenStreetMap community.

Christoph, kindly explain, instead of making snide remarks. You have
not added to the discussion, but instead raised the level of toxicity
of this channel even further.  Note that several people have already
noted that this channel is toxic and refused to participate in it,
rather than being productive and beneficial to everyone involved.

I rest my case.



Yuri,

In English there is a common phrase "which part of  *** do you not 
understand" (expletive removed because people offended by such words may 
be reading).


This thread 
https://lists.openstreetmap.org/pipermail/talk/2017-October/thread.html#79145 
currently has replies from 9 people.  1 is asking a question but all 
other replies are entirely negative (including comments such as "I'm 
appalled" and "that isn't acceptable behaviour").


Christoph Hormann's comment above is not a snide remark; it's entirely 
reasonable based on your actions so far - for an example of that see 
Tomas' reply earlier in the thread, or indeed almost any of the other 
interactions that you've had with the OSM community.


Best Regards,
Andu



___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] New OSM Quick-Fix service

2017-10-15 Thread Christoph Hormann

On Sunday 15 October 2017, Yuri Astrakhan wrote:
>
> > > [...] I was following up on the Christoph Hormann's
> > > idea of the "bot=no" tag, to "allow mappers to opt out of bot
> > > edits on a case-by-case basis."
> >
> > No, you were not, likely because you misunderstood my suggestion
> > which is likely because you don't get how OpenStreetMap is working
> > overall.
> >
> > I would strongly advise you to reconsider your whole approach to
> > OpenStreetMap and to interacting with the OpenStreetMap community.
> 
> Christoph, kindly explain, instead of making snide remarks. You have
> not added to the discussion, but instead raised the level of toxicity
> of this channel even further.  Note that several people have already
> noted that this channel is toxic and refused to participate in it,
> rather than being productive and beneficial to everyone involved.

I rest my case.

-- 
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