Re: [OSM-talk] cycle.travel bike routing for Western Europe

[Éric Gillet]

It hasn't been done on osrm.at because each routing profile require a
separate instance of OSRM.

The bicycle profile is available in OSRM for quite some time now, but I've
yet to find a public OSRM instance with bicycle or foot routing...


On Fri, Jul 18, 2014 at 7:00 PM,  wrote:

> Am 18.07.2014 19:01, schrieb Richard Fairhurst - rich...@systemed.net:
> > I'm pleased to report that http://cycle.travel/map now defaults to
> > kilometres for European routes. :)
>
> Thanks!
>
> By the way, it's great work you've done. Thank you very much for the
> map on cycle.travel! You can't imagine how long I've been waiting for
> osrm.at to integrate bicycle routing.
>
> You made my day, Richard.
>
> Cheers.
> John
>
>
> ___
> 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] This has to stop: User Diaries Spam

[Éric Gillet]

It still continue, and some spam is getting through, not deleted by admins.

Would it be possible that I volunteer for deleting incoming spam on user
diaries ? I could also put up a webpage listing the bans acted, allowing
full transparency if neccessary.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] This has to stop: User Diaries Spam

[Éric Gillet]

It still continue, and some spam is getting through, not deleted by admins.

Would it be possible that I volunteer for deleting incoming spam on user
diaries ? I could also put up a webpage listing the bans acted, allowing
full transparency if neccessary.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] This has to stop: User Diaries Spam

[Éric Gillet]

I know a friend who have some ruby knowledge, and will try to implement
something.

It seems that there already is a "moderator" user role
,
so it should not be that hard to do.


On Fri, Sep 5, 2014 at 4:36 PM, Andreas Goss  wrote:

> Would it be possible that I volunteer for deleting incoming spam on user
>> diaries ? I could also put up a webpage listing the bans acted, allowing
>> full transparency if neccessary.
>>
>
> I think the problem -if I understood it correctly- is that it can only be
> done by some top admins. Someone whould have to program it so they could
> give someone moderator rights so they could let more people help without
> destroying anything else.
>
> __
> openstreetmap.org/user/AndiG88
> wiki.openstreetmap.org/wiki/User:AndiG88‎
>
>
> ___
> 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] Spam vs. Vandalism : Example and Future Procedure (Example from Israel)

[Éric Gillet]

OSM is not an advertisment tool. It is a geographical database. I'd say in
this case delete the node and associated relations, as it seems the mapper
have made no effort to try to enter relevant and standard information on
OSM.

But you're right there are some edits in grey-area, where the best course
of action is hard to determine.

2015-03-13 18:13 GMT+01:00 Bryce Nesbitt :

> There are a number of written procedures for handling vandalism in OSM
> (mappers operating outside of community norms).
>
> There's not much yet in terms of handling spam, like this possible example:
> https://www.openstreetmap.org/relation/4124721/history
> (a series of relations advertising in breathless Hebrew a Jeep rental
> place).
>
> If I thought it was just a business trying to get listed, I'd send them a
> note.
> If I thought it was pure spam I'd revert it.
> It's kind of in the middle.
> Advice?
>
> ___
> 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] Spam vs. Vandalism : Example and Future Procedure (Example from Israel)

[Éric Gillet]

A pull-request
 (by me)
is still open about reporting changesets/diaries entries/users on the OSM,
and a GSOC project
is
proposed for that matter.

2015-03-13 19:33 GMT+01:00 Bryce Nesbitt :

> It would help to have a working group or escalation procedure for things
> like this.  Blocking the account for example, requires some escalation.
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] contact: tags

[Éric Gillet]

2015-05-06 15:33 GMT+02:00 Richard Z. :
>
> Btw anyone knows what phone=3631 is ?


3631 is the short (local) phone number to contact "La Poste", the postal
services in France.
The large number of occurences is from an opendata import.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] VisualEditor on the OSM wiki

[Éric Gillet]

I thought I missed the announcement, but looks like it was a secret gift
from the wiki sysadmins !

Thank you and have a good 2016 :)


> 2016-01-03 23:02 GMT+01:00 Rob Nickerson :
> > Hi,
> >
> > Not sure when this happened (some time recently) but I wanted to thank
> our
> > wiki system admins for adding the VisaulEditor extension to the OSM wiki.
> > For those that don't know the extension is a rich text editor for wiki's
> and
> > came about following concern over declining new contributors to the
> > wikimedia projects. It has taken many years to develop this extension
> but it
> > is great to see it now being used on the OpenStreetMap wiki (as well as
> the
> > WikiMedia sites).
> >
> > If you have never edited a wiki page before now is the time to try it
> out.
> > No longer do you have to remember the wiki syntax to make an edit :-)
> >
> > Rob
> >
> > ___
> > 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] International Womens Day - Mapping locations and dates of incidents on OpenStreetMaps

[Éric Gillet]

I don't think crime stats have their place in OSM, as they don't have a
physical presence on the group, are highly dynamic, and somewhat
subjective/local (some crimes in certain countries are not crimes in other).

2016-02-19 15:28 GMT+01:00 Mhairi O'Hara :

> Hello,
>
> Sexual harrassment towards women has been increasing in Bali with a number
> of individuals taking a stand by capturing images to post on Facebook to
> shame and apprehend, and I would like to help assist by empowering women to
> utilise OSM to further highlight and tackle these kinds of issues.
>
> I am thinking of trying to create some kind of harassment map like they
> have in Egypt (http://harassmap.org
> ). Ideally I would like to utilise OSM to capture and present this data
> (type of incident and date, etc), but have not been able to find an
> appropriate tag to use.
>
> The tag 'incident' has been used in the past, once and perhaps
> unofficially. So I was hoping to get some feedback and suggestions on how
> to approach this. In fact the mapping of this kind of data doesn't seem to
> exist on OSM, but is it something the community might be interested in
> exploring?
>
> Kind regards,
>
> Mhairi
>
>
> --
> Mhairi O'Hara
> Mobile: +62 822 4701 1475
> Email: mhairi.oh...@hotosm.org
> twitter  | linkedin
>  | facebook
>  | website 
>
> *Humanitarian OpenStreetMap Team *
> *Using OpenStreetMap for Humanitarian Response & Economic Development*
>
> ___
> 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] Mobile businesses

[Éric Gillet]

2016-06-16 20:17 GMT+02:00 john whelan :

> Locally we're seeing the demise of the local bicycle store with its
> mechanic but there are a least two cycle mechanics operating out of mobile
> workshops.  You ring or  contact them via the Internet.
>
> Knowing that many in OSM indulge in cycling I'm wondering if they should
> be included in the map and is there is some way of adding them to the map,
> perhaps a tag on the city name?
>

If they have a "brick and mortar" store, map the store, witth maybe
delivery=yes (or more suitable tag) to mean that they are also mobile.

If they have fixed stops with stable schedules, I would map the stops as a
shop=bicycle with opening_hours=* and a description/note to explain why the
"shop" is not present out of opening_hours.

If the bike shops intervene on-demand only, I think their presence is too
abstract to map them in OSM.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk] Automated edits code of conduct

[Éric Gillet]

Hello,

OSM contributions must follow the Contributor Terms
; these
therms are being shown to new users and they must explicitely accept them
before they can start contributing.

However, another distinct set of rules is also being enforced by the DWG :
the Automated edits code of conduct

 (AECoC).

In contrary to the Contributor Terms, these rules :

   - Are not shown to new contributors
   - Are not accepted by new or existing contributors
   - Doesn't seem to have been voted on before their "establishment"
   - Seems to have been written by an eminent, but small set of
   contributors (history
   

   )

Like the Contributor terms, the AECoC is enforced by the DWG and can cause
reverts by its members, on terms that have not been accepted by
contributors.

As such, I think that the AECoc in its current form should not serve as a
basis for reversal of changesets by the DWG.

If it were to, I think it should be put to an higher set of standards than
the changeset it aims to direct. For example it could be audited with an
RFC, then a vote, and finally being explicitely accepted by contributors.

What are your thoughts ?

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

[OSM-talk] Fwd: Automated edits code of conduct

[Éric Gillet]

2016-07-10 23:56 GMT+02:00 Christoph Hormann :

> On Sunday 10 July 2016, Éric Gillet wrote:
> >
> > In contrary to the Contributor Terms, these rules :
> >
> >- Are not shown to new contributors
> >- Are not accepted by new or existing contributors
>
> Maybe that is because they don't apply to the vast majority of
> contributors.  You don't need to accept the automated edit rules to
> contribute to OSM as long as you don't do automated edits.
>

If you do a search-and-replace on 20 elements and review manually the
change, it is covered under the AE CoC. I don't think of that as an
advanced or uncommon task.


>
> >- Doesn't seem to have been voted on before their "establishment"
> >- Seems to have been written by an eminent, but small set of
> >contributors (history
>
> Doesn't this also apply for the Contributor Terms?
>

Yes, it does. But it's mainly the combination of these points that is
problematic.

>
> Remember OSM is largely a do-ocracy - those who put work into developing
> the rules have a significant influence on their content.


It shouldn't forbid to re-evaluate them.

This does not
> make them illegitimate.


This doesn't make them legitimate either.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Automated edits code of conduct

[Éric Gillet]

Hi Michael,

2016-07-11 0:08 GMT+02:00 Michael Reichert :

> Hi Éric,
>
> Am 10.07.2016 um 23:26 schrieb Éric Gillet:
> > In contrary to the Contributor Terms, these rules :
> >- Are not shown to new contributors
>
> It is shown to new contributors, not directly but they get informed. If
> you create an account, you will see a welcome page after clicking on the
> confirmation link which you get via email. This page explains basic
> things like the data model (node, way, relation) and says that there are
> special rules for imports and mechanical edits.
>

You're right, I just noticed that they indeed are, but a lot less
prominently as the Contributor Terms (and doesn't require acceptance)

>
> >- Are not accepted by new or existing contributors
> >- Doesn't seem to have been voted on before their "establishment"
>
> There are dozens of other rules which have neither been voted nor being
> accepted by every contributor. Just have a look at Good_Practice at OSM
> wiki. None of those items has been voted. They are basic rules.
>

Of course, however those rules are not enforced by the DWG.


>
> The Contributor Terms are a replacement for the former CC-BY-SA license
> all contributors granted (to everyone directly). Nowadays OSMF
> "collects" all these rights using a contract called Contributor Terms.
>
> >- Seems to have been written by an eminent, but small set of
> >contributors (history
> ><
> http://wiki.openstreetmap.org/w/index.php?title=Automated_Edits_code_of_conduct&offset=&limit=500&action=history
> >
> >)
>
> Did you have a look at the mailing list archives of the time when this
> policy was written (+-6 months)?
>

I believe that just like the tagging process, the discussion leading to the
establishment of those rules should be open and not require digging through
an 8 years-old mailing list.


>
> Both Import Guidelines and Automated Edits Code of Conduct are
> guidelines which will reduce the likelihood that your import/mechanical
> edit gets reverted.
>

This is only the stated goal of the AE CoC. Following that wiki page means
that the changeset can't be reversed on basis of this wiki page, no more.
I think  that this page should encourage mapping good data ©, not be as
broad as possible in order to become a justification when someone want to
revert a changeset.


> We don't have a Don't Delete Everything Policy. Nevertheless, we revert
> vandalism (if we discover it).
>

But what is vandalism ?
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Fwd: Automated edits code of conduct

[Éric Gillet]

2016-07-11 11:28 GMT+02:00 Martin Koppenhoefer :

>
> 2016-07-11 2:02 GMT+02:00 Éric Gillet :
>
>> If you do a search-and-replace on 20 elements and review manually the
>> change, it is covered under the AE CoC. I don't think of that as an
>> advanced or uncommon task.
>
>
>
> when you do any "search and replace" based edits I believe these are
> correctly considered automated edits, because you can only in rare
> occassions do a real "manual review": you would have to visit (or at least
> have visited) all those places and see what is there on the ground,
> otherwise you can't be sure what the tags are applied to, and if a change
> makes sense.
>

I agree that survey are that on-premise survey is the best review method.
But then you are adressing armchair mapping as a whole and not specifically
search-and-replace edits.

There are instances where a survey is not necessary, and the information
needed to perform the modification is available on imagery, website or open
data, so the need to be on the premises is limited. But again this does
apply to all armchair mapping.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Fwd: Automated edits code of conduct

[Éric Gillet]

2016-07-11 2:16 GMT+02:00 Frederik Ramm :

> On 07/11/2016 02:02 AM, Éric Gillet wrote:
> > If you do a search-and-replace on 20 elements and review manually the
> > change, it is covered under the AE CoC.
>
> No, the document clearly states in the "Scope" section:
>
> "use of find-and-replace functionality using a standard editor such as
> JOSM or finding using services such as Overpass API and changing without
> reviewing cases individually;"
>
> Sadly, we often have people who run search-and-replace operations and
> *claim* that they have "reviewed cases individually", and then if you
> look at their edit, they have changed a tag on a POI that sits in the
> middle of a road or so - which means that they were either lying, or
> they have only done a very, very cursory "manual review" of their change.
>
> An automated, or mechanical, edit is when you do not look at the
> individual object you're editing.
>

When you add or correct some information on features are you responsible
for the data outside the original reach of the changeset ? If so, it's a
really important point for all contributions. I agree that ideally you
would review all the data, but sometimes it is not necessary or even
possible when you are not local.

I believe that changesets should try to be atomical, so when the point of
the changeset is to correct phone numbers for examples, you shouldn't touch
other tags.
In the case that the main subject of the changeset cause controversy, and
must be reversed, you wouldn't want to remove other unrelated changes (e.g.
node positions when editing phone numbers)

There is no similar policy covering manual edits. But of course if
> someone *manually* changes 500 landuse=wood to landuse=forest across the
> planet, it is still possible that they make a mistake and it needs
> fixing in some way, or if they do it repeatedly and cause problems with
> it, they might still be blocked. [...] However, causing trouble through
> manual edits is so much less
> frequent than causing trouble with mechanical edits that we have written
> up a policy on the latter.
>

Limiting the automation doesn't necessarily reduce the raw number of
errors. What it does is that in case of an mapper/software error, the error
may be applied to less content than a large edit.
But contributors can put a lot more focus and time in the "automated" edit
than on each one-by-one manual updates, so I don't think the net gain of
"automated" edits is negative.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Automated edits code of conduct

[Éric Gillet]

2016-07-12 14:35 GMT+02:00 Frederik Ramm :
>
> On 07/12/2016 03:03 AM, tuxayo wrote:
> > The questions is how legitimate are they. To know if we can enforce them
> > strictly.
>
> Enforcing anything "strictly" is likely to cause problems. Rules can
> only be enforced strictly if they are so well written that any idiot can
> enforce them by simply following the instructions ;)
>

 The DWG currently use those (AE CoC) rules to revert changesets without
further justification.

For example, a few years ago we had a user called "worst-fixer" or so
> who did a couple of large-scale edits removing the "created-by" tag. Now
> this was a mechanical edit against the rules, and there was a consensus
> in the community to remove those unwanted tags piecemeal instead of
> creating a new version for hundreds of thousands of objects, needlessly.
>
> Strictly enforcing rules would have meant reverting all these edits but
> that would have been quite silly (causing another extra version to be
> created), so they were allowed to stand.
>

It's a good thing that rules could be bent a little, but that means that
they should be modified. Defining rules but overriding them when convenient
is not a sane approach in the long term.


> > That would also allow DWG members to intervene with a greater legitimacy
> > because it would not come from their status.
>
> Having a DWG whose legitimacy comes from rules would allow everyone to
> start endless discussions about DWG's interpretation of the rules, or
> finding loopholes in the wording. This is what happens in Wikipedia and
> it allows troublemakers to waste an awful lot of volunteer time by
> posing as innocent, rule-abiding people.
>

Do you suggest that DWG members should not even base their actions on rules
accepted by the community ? That wouldn't work even with perfectly honest,
calm, and open-minded members, as even then contributors could have have
another valid opinion on things. (just to be clear : I am not saying that
they are not calm, honest and open-minded)


> > I agree that showing them at sign up wouldn't help. However it's to be
> > expected that first time mass edits are done without knowing the AECoC
> > as nothing more than the JOSM search and replace tool is needed. Is not
> > like importing which require more documentation.
>
> Perhaps we could make JOSM cleverer in detecting such cases and alerting
> people to the rules. JOSM already pops up tons of warnings - about
> moving lots of nodes, about displaced aerial imagery, etc. - it could
> also say "you're changing a lot of objects over a geographically large
> area at the same time and you haven't zoomed in on any, are you sure you
> have read the rules..."
>

That is a good idea !


>
> > The reporting of AECoC violations could be done in a dedicated open
> > mailing list so we could have accountability about how these issues are
> > handled.
> > *Any thoughts about this? This is a concrete proposal.*
>
> DWG is happy about every case that the community manages to handle
> between themselves, without DWG having to get involved. If such a
> mailing list would help taking some of the load off DWG's shoulders and
> DWG would then only deal with those cases that the community can't
> handle or where things aren't clear enough, sure that would be great.
>

So at least one user should reach out to the contributor before involving
the DWG ? That would be great but that's not currently the case in my
experience.


> The rules about automated edits stem from their ability to upset many
> people in the community. Reverting an automated edit will usually only
> upset one person.


At least some reversal were done after only one complaint, so it doesn't
currently work like that.


> It is a logical fallacy to believe that just because
> automated edits are a problem that needs to be regulated, the reverting
> of automated edits needs to be regulated as well.


Why not ? All changesets should be justifiable, even so on a revert where
there are no verification at all of the modified data, whereas in
"automated" edits there are at least some.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Automated edits code of conduct

[Éric Gillet]

2016-07-12 19:35 GMT+02:00 Andy Townsend :

> On 12/07/2016 17:29, Éric Gillet wrote:
>
> I've read through your posts in this thread, and while it's clear that you
> have an issue with the way that things work now, I can't see what that
> problem actually is.  Can you provide some specific examples of DWG actions
> that you think were inappropriate?  What do you think should have happened
> instead?
>

I will summarise what course of action I think would be appropriate to
follow :

   - It's not clear whether AE CoC terms are rules or simply guidelines
  - As Frederik said, rules should be written well in order to have the
  legitimacy to be used strictly (ODbL, Contributor's Terms etc.)
  - Guidelines should contain, well, guidelines that should not be used
  as a direct basis for reversal. They could be used as part as an
argument,
  but just using one item should not be grounds for reversal by DWG.
   - In consequence, a choice have to be made :
  - Either overhaul the current AE CoC, submit it to RFC/voting and use
  it as a ruleset for contribution after a consensus is reached
  - Use the current AE CoC as guidelines, not strict rules.



> However do bear in mind that just like the vast majority of people in OSM
> everyone in the DWG's a volunteer.  Some volunteered; others were asked to
> join but everyone's unpaid.  Also bear in mind that everyone in OSM's a
> human being and deserves a basic level of respect - even new users creating
> invalid POIs simply because they don't realise they're editing a worldwide
> map.
>

DWG members are volunteers, I am too, you surely are too. Contributor's
time is a premium ressources in projects such as OSM. So let's not waste
any of it :)


> Andy (aka http://www.openstreetmap.org/user/SomeoneElse , member of the
> DWG but writing in a personal capacity).
>

Thank you for disclosing that and differentiating between DWG
actions/opinions and yours.

-

2016-07-13 5:36 GMT+02:00 Nicolás Alvarez :

> 2016-07-12 23:08 GMT-03:00 tuxayo :
> > Automated edits should also have a place. For thing like pure tagging
> > errors:
> >   - URLs lacking "https://"; prefix
> >   - leading and trailing spaces in names
> >   - common, obvious and non ambiguous typos
> > The error probability is almost null (error in script or typo?)
>
> When I searched for typos and leading and trailing spaces in my area,
> I found lots of unrelated wrong things. For example, many objects with
> trailing spaces in the names were "my house is here" nodes. Or roads
> including the name of the political administration that was around
> when the road was built (typical political bullshit that appears in
> signs sometimes, but it's *not* the name of the road).
>
> Checking them one by one was a great idea.


I agree that often an error is not alone and it would be best to correct
all them while explaining to each individual contributor why it's and
error, but as I said before, time is a premium. Here are other problems :

   - It slows down the actual error correction
   - As I said before : if you lace "completely manual" modifications with
   "slightly automated" (search/replace) and face objections for the
   "automated" part of your changesets, there are every chance that the whole
   changeset would be reverted, or even all the changesets in a time interval
   (just ask Test360 about it)

So what do you suggest :

   - Do one changeset by feature you're editing, where you both correct the
   original subject of the error and othoner problems ? (Very slow, but higher
   quality at the end)
   - Do both the search and replace and correct other errors on multiple
   other errors "completely manually" in the same changeset ? (Time efficient
   but slow, good quality of data, but at risk of reversal of the whole
   changeset)
   - Correct "automatically" what can be automatically corrected, and rely
   on QA tools to spot the other errors ? (Time efficient, quick, but leave
   other errors untouched)

These three approaches seems valid to me, but it doesn't seem to be the
case for everyone.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Automated edits code of conduct

[Éric Gillet]

2016-07-14 6:12 GMT+02:00 tuxayo :

> On 13/07/2016 09:25, Éric Gillet wrote:
> > I will summarise what course of action I think would be appropriate to
> > follow :
> >
> >   * It's not clear whether AE CoC terms are rules or simply guidelines
> >   o As Frederik said, rules should be written well in order to have
> > the legitimacy to be used strictly (ODbL, Contributor's Terms
> etc.)
> >   o Guidelines should contain, well, guidelines that should not be
> > used as a direct basis for reversal. They could be used as part
> > as an argument, but just using one item should not be grounds
> > for reversal by DWG.
> >   * In consequence, a choice have to be made :
> >   o Either overhaul the current AE CoC, submit it to RFC/voting and
> > use it as a ruleset for contribution after a consensus is reached
> >   o Use the current AE CoC as guidelines, not strict rules.
>
> Should an RFC + vote be made on this? Or is there a simpler process to
> try to settle (for at least one/few years) this issue?
>

I don't see a simpler process than this other than just accepting the
status quo. As you said before, this process is what is used in OSM (for
tags), and it seems democratic to vote on rules.


> > So what do you suggest :
> >
> >   * Do one changeset by feature you're editing, where you both correct
> > the original subject of the error and othoner problems ? (Very slow,
> > but higher quality at the end)
> >   * Do both the search and replace and correct other errors on multiple
> > other errors "completely manually" in the same changeset ? (Time
> > efficient but slow, good quality of data, but at risk of reversal of
> > the whole changeset)
> >   * Correct "automatically" what can be automatically corrected, and
> > rely on QA tools to spot the other errors ? (Time efficient, quick,
> > but leave other errors untouched)
> >
> > These three approaches seems valid to me, but it doesn't seem to be the
> > case for everyone.
>
> A fourth approach to fix that would be to have a first automated edit
> changeset and then a manual fix changeset for the other errors.
> A variant would be to reverse the order: fix the other errors first when
> inspecting the selected/searched objects to be automatically edited. And
> then doing the automated edit.
>

That would be slightly faster to execute than the first approach I was
suggesting, but then how would you prove that you checked every and all
features ?
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Automated edits code of conduct

[Éric Gillet]

2016-07-14 14:00 GMT+02:00 Richard Fairhurst :

> Éric Gillet wrote:
> > That would be slightly faster to execute than the first approach I was
> > suggesting, but then how would you prove that you checked every
> > and all features ?
>
> Well, the best way to prove that you checked everything is not to fuck
> things up, which of course you won't, because you've checked everything.
>
> If you fuck things up (for example, by changing name=McDonalds to
> name=McDonald's on an independent restaurant that is actually called
> McDonalds), then by definition you haven't checked sufficiently, have you?
>

Oh, I thought you talked about checking peripheral data such as the
position of the nodes as mentionned by Frederik Ramm. Of course it should
be the responsibility of the changeset maker to lessen the errors
introduced, just like any mapper really.

However I'd believe that there is (in Europe for the example's sake) a very
low number of restaurant really named McDonalds and not part of the
franchise. So if the changeset correct 300 restaurants but 2 are "damaged"
by the automated edit, would the edit be bad enough to be reverted or not
be done in the first place ?
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Analysis of usage of similar tags over time

[Éric Gillet]

2016-09-01 8:16 GMT+02:00 Oleksiy Muzalyev :

> Could it be that there are only 104000 ATMs mapped in the whole world? I
> mean, - is it really the data from the OSM database?
>

You can see on taginfo that there are indeed around 104k ATM on OSM :
http://taginfo.openstreetmap.org/tags/amenity=atm
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] OSM Conflation Tool

[Éric Gillet]

Nice tool, thank you for making it !
Also python3 support is appreciated.

Éric

2017-02-16 15:47 GMT+01:00 Ilya Zverev :

> Hi everyone,
>
> I have just finished the conflation script, that would make importing a
> set of points much easier. For example, when you have a GeoJSON of
> McDonalds' restaurants or a website with locations of Carrefour Express
> shops. It reads or downloads OSM data and finds matching objects (including
> ways and multipolygons). Then it adds some tags, adds nodes for unmatched
> points, and produces an osmChange, ready to be uploaded.
>
> Of course, you should not upload anything made with a script right away,
> there are procedures for automated edits.
>
> The script is written in Python 3, and called OSM Conflator. The
> description and instructions are on the wiki: https://wiki.openstreetmap.
> org/wiki/OSM_Conflator
>
> It is published on Github under the Apache 2 license:
> https://github.com/mapsme/osm_conflate
>
> The first local import made with it will be uploaded tomorrow after the
> ongoing discussion in the Russian forum. I'd be happy to see it help
> anybody else.
>
> Ilya
> ___
> 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 Overpass API v0.7.54 version

[Éric Gillet]

2017-04-04 6:47 GMT+02:00 Roland Olbricht :

> Hello everybody,
>
> the blog
> http://dev.overpass-api.de/blog/
> has not only new entries but now also an RSS feed:
> http://dev.overpass-api.de/blog/rss.xml


Thanks, it's a lot easier to follow the updates !
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] The Top Ten Tasks list

[Éric Gillet]

2017-04-07 12:11 GMT+02:00 David Earl :

> The link https://pads.ccc.de/k4rlFOGIHb reports an invalid https
> certificate!
>

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

Re: [OSM-talk] "NRCS basic OSM training" - low quality changesets in Nepal

[Éric Gillet]

2017-06-23 0:34 GMT+02:00 Nicolás Alvarez :

> > Ben .. you could try, say, bdiscoe@gmail.com and
> bdiscoe.old...@gmail.com - they should both end up in you gmail account.
>
> Are you saying that if anyone emails nicolas.whate...@gmail.com it will
> reach me? That... doesn't sound right.
>

Please check out this link

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

Re: [OSM-talk] An import in New Zealand, assistance requested

[Éric Gillet]

2017-08-31 16:55 GMT+02:00 Simon Poole :

> Sorry for responding to this late.
>
> Just because a specific source has been legally "OK"ed doesn't imply
> that an import of all the data from a specific source is warranted and
> should continue on for all times. The import guidelines are silent on
> this, but I would suggest that revisiting and reviewing such undertaking
> now and then would really make sense.


Meh, If the import has been going on for years, and the only objection is
about "process" or meta-data, I'd say they should continue.
If there is problems with the data or what's being entered on OSM, we can
stop and think before continuing.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] An import in New Zealand, assistance requested

[Éric Gillet]

2017-08-31 21:56 GMT+02:00 Simon Poole :
>
> If there is problems with the data or what's being entered on OSM, we can
> stop and think before continuing.
>
> Well it seems as if exactly -that- wasn't happening which is why this
> thread was started in the first place. Seems however that the brakes have
> been put on now, see https://lists.openstreetmap.
> org/pipermail/imports/2017-July/005118.html
>

I do not see any reference to such problem in OP.

If the original plan didn't include building, that's fine by me to stop
because importing building is wholly different from roads.
But if it did, and the data is valid, precise and license-compatible, it's
sad to stop because of minute details imo.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

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

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

[Éric Gillet]

2017-10-13 23:25 GMT+02:00 Yuri Astrakhan :

> 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.
>
> 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.
> Try it:  http://tinyurl.com/y8mzvk84
>
> I have started a Quick fixes wiki page, where we can share and discuss
> quick fix ideas.
> * Quick fixes 
> * Documentation
> 
>
> This is a very new project, and bugs are likely. Please go slowly, and
> check the resulting edits. Let me know if you find any problems. Your
> technical expertise is always welcome, see the code at
> https://github.com/nyurik/wikidata-query-gui  The service has adapted
> some code from the Osmose project (thanks!)
>
> TODO:
> * Allow multiple edits per one change set
> * Show objects instead of the dots
> * Allow users to change comment before saving
>

(Posting also in talk ML.)

First of, I comend you for the calm you've expressed in this thread, in
face of the hostile (I don't mean constructive criticism) answers you've
been getting.

I think this is a nice tool, however as for every tool, it can be used for
good and bad things. As long as you adress pertinent feedback I encourage
you to continue developping this tool.
As Simon pointed out, having a "False positive" button on each correction
would be really helpful (like Osmose for example).
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] weeklyOSM #379 2017-10-17-2017-10-23

[Éric Gillet]

2017-10-28 14:29 GMT+02:00 Ilya Zverev :

> [Philippe Verdy's] number of edits makes his work virtually unverifyable
> and unrevertable.
>

Without regard to the (objective?) quality of his work, you convey that he
is to blame because of his important implication to the project ?
AFAIK he does not circumveit moderating processes, and not using
"automated" tools. OSM is a do-o-cracy; blaming people (especially people
investing a lot of time) for their implication is not the way to go.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] weeklyOSM #379 2017-10-17-2017-10-23

[Éric Gillet]

[Citation needed]

More seriously, could you please list multiple objective instances of "net
negative value" edits ?

Let's not jump on the bandwagon of banning someone because some disagree
with his contributions, based on this single issue presented in OSM weekly.

2017-10-28 12:06 GMT+02:00 Andrew Hain :

> It is now time to talk about banning Verdy p from the wiki permanently.
>
> His behaviour over the past years makes him a contributor of net negative
> value.
>
> It is exceptionally difficult to correct any mistake that he makes and as
> a result people have cut down their contributions to the wiki or given up
> completely.
>
> He likes to tell people that they have made mistakes without trying to
> teach them what he thinks they did wrong and obfuscates changes with mass
> reformatting. It is often unclear whether he is addressing a problem that
> actually exists.
>
> He often projects his own personality deficiencies onto other people.
>
> Even in the current case where there is software that could be made more
> flexible, he only offers handwaving rather than assistance.
>
> --
> Andrew
> --
> *From:* weeklyteam 
> *Sent:* 28 October 2017 08:47:48
> *To:* talk@openstreetmap.org
> *Subject:* [OSM-talk] weeklyOSM #379 2017-10-17-2017-10-23
>
> The weekly round-up of OSM news, issue # 379,
> is now available online in English, giving as always a summary of all
> things happening in the openstreetmap world:
>
> http://www.weeklyosm.eu/en/archives/9571/
>
> Enjoy!
>
> weeklyOSM?
> who?: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages
> where?: https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-
> produced-in_56718#2/8.6/108.3
> ___
> 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] weeklyOSM #379 2017-10-17-2017-10-23

[Éric Gillet]

2017-10-28 19:15 GMT+02:00 Christoph Hormann :

> A quick note - since i think it is important to make this distinction:
>
> But the OSM wiki as a meta-project for documenting and communicating
> about mapping is not a do-o-cracy on its own.  You cannot simply invest
> a lot of time in the wiki and expect your ideas about how things are
> supposed to be there to supersede those of others, especially those who
> might not spend so much time on the wiki but on other OSM related
> things and who rightfully expect to be able to use the wiki for those
> activities.


This is a really hard subject to tackle. Everyone prefer to have their own
idea/ways validated by others. It is always hard to be corrected, or having
its work replaced by an equally valid work.
The underlying questions I believe are how much one's work should be
immutable ? Can someone "claim ownership" of a wiki page for example by
being the first to write it, or being the most close geographically to the
feature described ?

I do think that one shouldn't expect to have their ideas/work unchallenged
and untouched on OSM. As it is a public work, and
contributors/contributions are expected to be equal, the only way of
expressing their opinion is by contributing in content or discussion. If
you do neither, or fail to provide valid objections to subsequent
modifications, why would one's previous contribution prevail over later
work ?

That's what I meant by do-o-cracy, and I think it applies all the same to
the wiki, which really is a part of the OSM project.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

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

[Éric Gillet]

2017-11-13 20:52 GMT+01:00 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).
>

The data one have edited is automatically validated before upload by JOSM
validator, but you can also use it to validate and auto-fix any area you
have downloaded, without any prior "manual" edits. It's a bit convoluted of
a process, but it can be used like that to do mass edits. So comparing it
to OSM Quick-fix seems valid to me, even if JOSM is our beloved editor.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Mailing list security

[Éric Gillet]

2017-11-25 11:12 GMT+01:00 Colin Smale :

> My point is that the email I received contained my password to that
> account, in plain text!
>
> WTF#1: Why is it remembering the cleartext password and not a
> non-reversible hash?
>
> WTF#2: Why is it sending my password around in the email?
>
> My feeling is that this needs fixing, and quick.
>
This is non-ideal, but you were warned during your account creation that
this password is to be considered non-secure :

> You may enter a privacy password below. This provides only mild security,
but should prevent others from messing with your subscription. Do not use a
valuable password as it will occasionally be emailed back to you in
cleartext.

https://lists.openstreetmap.org/listinfo/talk

I don't think that this mailing-list software (mailman
) can work with hashed
passwords.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Mailing list security

[Éric Gillet]

Hmm it seams released in April 2015, but anyway it's been some time since
the release.
It's not mentionned in the Operations issue tracker
<https://github.com/openstreetmap/operations/issues>, maybe you could open
an issue there to suggest upgrading to mailman 3.
But it seems to be a rewrite of mailman, so it may be not trivial to
migrate to this version.

Another point : This password is not secure, but what the worst that could
happen with it ? As long as one don't reuse it on other applications (as
warned during registration), the only action an attacker could do would be
to unsubscribe you. Not really catastrophic

2017-11-25 12:55 GMT+01:00 Colin Smale :

> On 2017-11-25 11:53, Éric Gillet wrote:
>
> This is non-ideal, but you were warned during your account creation that
> this password is to be considered non-secure :
>
> > You may enter a privacy password below. This provides only mild
> security, but should prevent others from messing with your subscription. Do
> not use a valuable password as it will occasionally be emailed back to you
> in cleartext.
>
>
> Thanks Éric, I admit that "I was warned" but I still find it scandalous in
> this day and age... It seems this shortcoming in mailman was fixed in V3,
> released in 2014. I read here that V3 no longer stores
> unencrypted/decryptable passwords:
>
> https://mail.python.org/pipermail/mailman-users/2014-July/077411.html
>
> Are we still running V2.1?
>
> //colin
>
> ___
> 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] anonymous notes spam?

[Éric Gillet]

Same here.

Le ven. 20 juil. 2018 à 20:25, Johnparis  a écrit :

> When I click on the samples I get full notes. Perhaps there was a database
> hiccup?
>
> On Fri, Jul 20, 2018, 18:29 Andrew Hain 
> wrote:
>
>> Can we find out what software is being used to send these notes?
>>
>> --
>> Andrew
>> --
>> *From:* Doug Hembry 
>> *Sent:* 20 July 2018 14:26:13
>> *To:* talk@openstreetmap.org
>> *Subject:* Re: [OSM-talk] anonymous notes spam?
>>
>> Yes. In the San Francisco Bay Area. Single letters "f", "k", and "l".
>> Example:
>>
>> https://www.openstreetmap.org/note/778721#map=15/37.5009/-122.3032&layers=N
>> BTW, is there a simple way to delete such note comments?
>>
>> On 7/20/2018 2:32 AM, maning sambale wrote:
>> > I'm getting several single letter notes comments since yesterday.
>> > Example: https://www.openstreetmap.org/note/562375
>> > Are people noticing the same?
>> >
>>
>> ___
>> 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
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk