Re: [OSM-talk] Wikipedia/Wikidata admins cleanup

[Mikel Maron]

 blockquote, div.yahoo_quoted { margin-left: 0 !important; border-left:1px 
#715FFA solid !important;  padding-left:1ex !important; background-color:white 
!important; }  Paul, thanks I hadn't seen that before, and it's a good response.

Mikel

On Friday, January 6, 2017, 7:05 PM, Paul Norman  wrote:

 On 1/6/2017 7:37 AM, Mikel Maron wrote:
 
 http://www.openstreetmap.org/changeset/39517002 is an example. There were 
issues with this import, sure. This was not vandalism, advertising, or a fatal 
breakage of the map -- not a situation where an immediate action was justified 
(and definitely there are other situations where immediate action is needed). 
An active mapper and an active community were communicating, acting to fix the 
problems. The reverter in this case choose to ignore the mapper and the 
community and took a unilateral action, in contradiction to some guidelines on 
the wiki. This kind of approach discourages community contribution and 
cooperation. We can do a lot better to cooperatively improve the map and how we 
map it. 
 
 The revert in this case did not involve the Data Working Group. The DWG 
statement on this issue 
ishttps://lists.openstreetmap.org/pipermail/talk-ca/2016-September/007260.html. 
Quoting from it
 
 
Advance permission is not required for reverts, nor for normal mapping
 activities. At the same time, users are expected to be responsible,
 particularly when using tools for reverting which allow large-scale
 changes where other users may disagree with them.
 
 Where there are problems with an import reverting is an option, but
 just one of many, and often not the appropriate first action. Unless
 there are legal problems or fatal problems with the import it is
 preferable if the original importer can fix the problems in a timely
 manner. There was every indication this was going to happen in this case.
 
 The revert of 39517002 was inappropriate and counter-productive. New
 actions like this revert may lead to further Data Working Group
 involvement and potentially blocks. If the Canadian community needs help
 reverting 41749133 and 41756737, the Data Working Group can revert those
 changesets.
 
 
 Because there seems to be some confusion, neither Nakaner or Mikel are members 
of the Data Working Group.
 
 Frederik Ramm, Andy Townsend, and myself are the three people in this thread 
who are also members of the DWG. Unless they state otherwise, their opinions 
aren't representing the DWG.
 
 Paul Norman
 For the Data Working Group
 ___
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] Wikipedia/Wikidata admins cleanup

[Mikel Maron]

> It is fatal for the project...
It's difficult for me to see how more respect, patientience, and clarity is an 
existential threat to OpenStreetMap. Perhaps I'll feel different after I run 
through a few of these cases...
Mikel

On Friday, January 6, 2017, 11:52 AM, Simon Poole  wrote:

Am 06.01.2017 um 16:37 schrieb Mikel Maron:

..

I would suggest that using this case to make your point is seriously
misplaced.

Reverting a broken import asap to allow for a) the guidelines to be
followed, b) address technical and legal issues, is the sensible,
logical and low impact and only scalable course of action. It is
definitely neither unfriendly nor un-welcoming or any other adjective
you want to use*. The earlier and more consistently it happens the less
effort and work is lost by all participants.

If there is an issue with immediate reverts, it is that, particularly in
the past, there hasn't been enough. The numerous broken imports (CANVEC
and broken import is essentially a synonym) that bitrot in our data and
are long past any reasonable way of removing them are testimony to this.

It is fatal for the project that you are creating the impression that as
long as you argue long enough and feign innocence you will be able to
bypass the rules and get away with whatever you want. To the contrary,
we should be making it clear that not following the few, definitely not
particularly arduous to adhere to, rules will result in immediate
removal of the content.

Simon

* the participants in the referenced discussion are neither newbies, not
aware of the guidelines, or any other mitigating factor, but that is not
the point.
___
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] Wikipedia/Wikidata admins cleanup

[Christoph Hormann]

On Friday 06 January 2017, john whelan wrote:
>
> We have more lakes in Canada than exist in the whole of Europe.  [...]

As Oleksiy already hinted you probably can get useful input from Russian 
mappers in that regard.  They have a vast country and a lot of lakes 
too and somehow managed to map at least most of the larger ones - i 
don't think there is any lake in Russia missing that is more than 10km 
in size and even smaller ones are mapped in most parts of the country 
while in Canada - well, you have still some distance to go to achieve a 
50km threshold...

If the Canadian community is interested in outside advise how to 
productively map large and remote areas without imports i am sure there 
are many people who would be glad to provide input.  But lets separate 
this from the discussion here (which is about wikidata tags).

-- 
Christoph Hormann
http://www.imagico.de/

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

Re: [OSM-talk] Wikipedia/Wikidata admins cleanup

[Simon Poole]

Am 06.01.2017 um 22:22 schrieb john whelan:
> >When Simon says "Canvec and broken import is essentially a synonym"
> that is not an
> exaggeration, if you mention Canvec in a typical European community
> meeting you usually just get a big sigh in return.
>
> I think you have to understand a bit more about CANVEC data what it is
> and how the quality varies.

Obviously the original quality and general suitability of a dataset for
use in OSM is one of the points that has to considered prior to an
import. However that is not the issue here, assuming that the original
data is roughly correct and valid in a topologically / technical sense:
it just doesn't compute to take that valid geo-data and turn it in to
broken OSM data, and it makes even less sense, if that is at all
possible, to do that in sparsely populated remote areas. 

In the past we've had notable OSM participants that have actually
suggested that we should and can just throw some broken  at the
crowd and it will come back out fixed and shiny. I would hope that we
have consensus that, based on the experience of the last decade of OSM,
that doesn't actually work and you end up overwhelming the communities
with stuff they "should be fixing" and it just doesn't get done. 

IMHO in conclusion any import should not take place if the data doesn't
work "as is" post import in OSM and we shouldn't leave such data in OSM
just because of some twisted reasoning that the importer will feel
better if it is not reverted. Nobody is suggesting that such an import,
at whatever level of granularity (for example a single changeset). can't
be redone once the issues have been fixed.

Which brings us back on topic. Yuris mechanical edit is, as mechanical
edits go (not an import so at least a different flavour), not totally
unreasonable. It should have been discussed beforehand, but the main
issue is that it is, at least perceived as, adding to that "should be
fixing" pile in a large way and somebody sitting in NYC deciding what
should be top priority for the local communities around the globe.

That is on top of multiple other edits that have added wikidata tags in
not so controlled and reasonable circumstances, for example to the,
known to be wonky, African place data that has been bit-roting for ages
(see above) . I assume they have been reverted, but maybe not.

Could we let this whole thing cool down and agree that for now there
should be no further mass adding of wikidata tags in any form till we
get a handle on how to proceed?

Simon












signature.asc
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Wikipedia/Wikidata admins cleanup

[Oleksiy Muzalyev]

Canada is the second largest country in the world by area. I understand 
only too well how inaccessible and unexplored a land with a harsh cold 
climate could be as I was born and grew up in a remote part of Siberia.


However, the situation changes nowadays. There is now a lot of 
innovation in clothing, footwear, and especially in ultra-light sleeping 
mats for trekking, sleeping bags, navigation devices, tents, and even 
light aluminum tent spikes for snow. This modern technology allows 
tourists to access cold areas more or less safely.


For example, the documentary film in English "Surviving in the Siberian 
Wilderness for 70 Years" https://youtu.be/tt2AYafET68 was seen on 
Youtube more than two and a half million times. It is a film about a 
religious family who lived in a forest in a complete isolation for 
several decades. And a lot of people hike to this compound now. I read 
recently that even a group of school pupils hiked several hundred 
kilometers to visit it.


I mapped several lakes around this compound 
http://www.openstreetmap.org/node/3645095042 via satellite imagery. A 
lake could be very useful, as it takes much more fuel to melt snow than 
ice. Besides, the water from snow does not provide minerals to a human 
body. It could be possible sometimes to cut through ice till the water 
of a lake.


Unfortunately the long footpath leading to this compound is not visible 
on satellite photos. If this footpath was mapped it would be a major 
security feature for many hikers, and it could also save some expenses 
to the rescue service. But it is possible to map it only via a GPS 
track, it means an expedition of preferably 7 or more people would have 
to go along it. Seven or more because it is a bear land, and no attacks 
being recorded against parties of more than seven people.


I think the remote areas should be mapped carefully, as it is not 
possible to ask for directions there. And tourists, sometimes young 
students, do venture there more and more. The trekking equipment for it 
is readily available via Internet shopping.


With best regards,
Oleksiy



On 06.01.17 22:22, john whelan wrote:

...
We have more lakes in Canada than exist in the whole of Europe.  Most 
are fairly inaccessible and there is little economic incentive to map 
each one to a high degree of accuracy. In many provinces they simply 
haven't spent the cash to map them accurately and recently.  Some data 
is forty or more years old.  So digging into the source of the CANVEC 
data can help to determine how accurate it is.


We don't have many mappers per square km in Canada and mapping with a 
GPS trace doesn't happen at minus 30 for some reason. If I go back in 
time to before I imported the CANVEC road data into Ottawa basically 
Ottawa OpenStreetMap was incomplete, inaccurate, over 140 reads had 
the wrong name when I compared them to the City of Ottawa map. The 
City of Ottawa map wasn't license to copy but I could at least compare 
the two.  Locally some imports had been done but anywhere an existing 
road was in the map an area round the existing road was not imported. 
Fine except that roads were not joined up.  You couldn't find a route 
between two streets in the city.


...


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

Re: [OSM-talk] Wikipedia/Wikidata admins cleanup

[Paul Norman]

On 1/6/2017 7:37 AM, Mikel Maron wrote:
http://www.openstreetmap.org/changeset/39517002 is an example. There 
were issues with this import, sure. This was not vandalism, 
advertising, or a fatal breakage of the map -- not a situation where 
an immediate action was justified (and definitely there are other 
situations where immediate action is needed). An active mapper and an 
active community were communicating, acting to fix the problems. The 
reverter in this case choose to ignore the mapper and the community 
and took a unilateral action, in contradiction to some guidelines on 
the wiki. This kind of approach discourages community contribution and 
cooperation. We can do a lot better to cooperatively improve the map 
and how we map it.


The revert in this case did not involve the Data Working Group. The DWG 
statement on this issue is 
https://lists.openstreetmap.org/pipermail/talk-ca/2016-September/007260.html. 
Quoting from it



Advance permission is not required for reverts, nor for normal mapping
activities. At the same time, users are expected to be responsible,
particularly when using tools for reverting which allow large-scale
changes where other users may disagree with them.

Where there are problems with an import reverting is an option, but
just one of many, and often not the appropriate first action. Unless
there are legal problems or fatal problems with the import it is
preferable if the original importer can fix the problems in a timely
manner. There was every indication this was going to happen in this case.

The revert of 39517002 was inappropriate and counter-productive. New
actions like this revert may lead to further Data Working Group
involvement and potentially blocks. If the Canadian community needs help
reverting 41749133 and 41756737, the Data Working Group can revert those
changesets.


Because there seems to be some confusion, neither Nakaner or Mikel are 
members of the Data Working Group.


Frederik Ramm, Andy Townsend, and myself are the three people in this 
thread who are also members of the DWG. Unless they state otherwise, 
their opinions aren't representing the DWG.


Paul Norman
For the Data Working Group
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Wikipedia/Wikidata admins cleanup

[john whelan]

>When Simon says "Canvec and broken import is essentially a synonym" that
is not an
exaggeration, if you mention Canvec in a typical European community
meeting you usually just get a big sigh in return.

I think you have to understand a bit more about CANVEC data what it is and
how the quality varies.  Some of it is high quality data, the same source
as the local fire department uses.  In general CANVEC data is a collection
of different data sources from each province.  Each province has slightly
different standards of data collection.  The roads in major cites are
fairly accurate both in street name and location.  Address information is
available for some provinces in some areas.  The equipment used to collect
the data is in my opinion more accurate than an iPhone GPS trace near tall
buildings.

We have more lakes in Canada than exist in the whole of Europe.  Most are
fairly inaccessible and there is little economic incentive to map each one
to a high degree of accuracy. In many provinces they simply haven't spent
the cash to map them accurately and recently.  Some data is forty or more
years old.  So digging into the source of the CANVEC data can help to
determine how accurate it is.

We don't have many mappers per square km in Canada and mapping with a GPS
trace doesn't happen at minus 30 for some reason.  If I go back in time to
before I imported the CANVEC road data into Ottawa basically Ottawa
OpenStreetMap was incomplete, inaccurate, over 140 reads had the wrong name
when I compared them to the City of Ottawa map. The City of Ottawa map
wasn't license to copy but I could at least compare the two.  Locally some
imports had been done but anywhere an existing road was in the map an area
round the existing road was not imported.  Fine except that roads were not
joined up.  You couldn't find a route between two streets in the city.

We had a physical local meeting over coffee, I think the first ever in
Ottawa and decided the cleanest way was to replace all the highways in
Ottawa from CANVEC which we did over a weekend.  It probably violated every
rule we have now but it gave us a working functional map.  Since then we've
mapped using traditional methods.  We simply didn't have the resources to
map every street in Ottawa with local mappers.  The City of Ottawa is big,
2,770 square kms.  We are the only map that can display either the official
French version of the name or the English version.  No one else can do
this.  It works in OSMAND or Maperitive using a special set of rules. This
was done with a Visual Basic program that input a .OSM file and took the
English name and output another file adding the French version of the
street name according to the rules in the City of Ottawa's bylaws.  Locally
this has generated a lot of goodwill for OpenStreetMap.

Canada is not Europe.  It is a country but in some ways it is a collection
of provinces and each is different.  Perhaps if I give you an example of
health care.  Each province is different.  Move from one part of the
country to another and you may find you have no health coverage.  If you
move from one part of the UK to another the NHS will still cover you,
whether or not they have the resources to provide a level of service is a
different matter.  In fact if you move from one part of the EU to another
health coverage is automatically available.  Europe is different to Canada.

Cheerio John

On 6 January 2017 at 13:04, Christoph Hormann  wrote:

> On Friday 06 January 2017, john whelan wrote:
> >
> > I think we should be trying to build the community.  We need a
> > balance between adding data without limits, and building the
> > community and building the community is hard.
>
> Well - as overzealous as Nakaners intervention in this case might have
> been in a way it is a good sign that someone still cares.  When Simon
> says "Canvec and broken import is essentially a synonym" that is not an
> exaggeration, if you mention Canvec in a typical European community
> meeting you usually just get a big sigh in return.  I for one do not
> touch Canada in OSM any more, not even with a ten foot pole.  And the
> only way this would change is a permanent moratorium on Canvec imports.
>
> But since i don't see this happening i sincerely hope you are able to
> build a big and active community even with the Canvec data - which
> seems difficult to me but it is not my place to judge this.
>
> > My roots are in the UK, I've mapped in the UK using local knowledge.
> >  I live in Canada.  Am I part of the UK local community of mappers?
>
> To me local community means the community of local mappers.  To what
> extent a local mapper stays a local mapper after moving away and how
> far you can become a local mapper during a short term visit is an open
> question.  But this is just minor semantics.  The important thing is
> that OSM is primarily about local knowledge and human assessment of the
> on-the-ground situation.
>
> --
> Christoph Hormann
> 

Re: [OSM-talk] Wikipedia/Wikidata admins cleanup

[Christoph Hormann]

On Friday 06 January 2017, john whelan wrote:
>
> I think we should be trying to build the community.  We need a
> balance between adding data without limits, and building the
> community and building the community is hard.

Well - as overzealous as Nakaners intervention in this case might have 
been in a way it is a good sign that someone still cares.  When Simon 
says "Canvec and broken import is essentially a synonym" that is not an 
exaggeration, if you mention Canvec in a typical European community 
meeting you usually just get a big sigh in return.  I for one do not 
touch Canada in OSM any more, not even with a ten foot pole.  And the 
only way this would change is a permanent moratorium on Canvec imports.

But since i don't see this happening i sincerely hope you are able to 
build a big and active community even with the Canvec data - which 
seems difficult to me but it is not my place to judge this.

> My roots are in the UK, I've mapped in the UK using local knowledge.
>  I live in Canada.  Am I part of the UK local community of mappers?

To me local community means the community of local mappers.  To what 
extent a local mapper stays a local mapper after moving away and how 
far you can become a local mapper during a short term visit is an open 
question.  But this is just minor semantics.  The important thing is 
that OSM is primarily about local knowledge and human assessment of the 
on-the-ground situation.

-- 
Christoph Hormann
http://www.imagico.de/

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

Re: [OSM-talk] Wikipedia/Wikidata admins cleanup

[john whelan]

I think one issue to try and define is what is the local community?

Canada is big, parts are closer to London UK than Vancouver.

Yes we have a bandwidth of opinions but so does the rest of OSM.

At the moment I'm trying to clean up a bit in Africa.  In many parts there
is no local community.  Morocco is extremely difficult, there are more than
two thousand untagged ways by one mapper many of which are a square with an
arrow pointing away from the square. Many have a note but they look like an
import of some such to me and I'd be delighted if Michael took aim at them.

I think we should be trying to build the community.  We need a balance
between adding data without limits, and building the community and building
the community is hard.  A bit like validation on the HOT side give gentle
guidance and you get better mapping, people feel motivated, tag the tile as
invalid because the project manager who did the validation feels that more
things were mapped on a tile than were requested doesn't help build the
community side of things.  Especially when I checked and the things that
had been mapped had been mapped before the HOT project.

One of the mappers whose opinion I respect in Africa is actually based in
Montreal.  He has travelled a great deal and knows the local conditions and
has good local contacts.  I would say he's part of the local African
community.

My roots are in the UK, I've mapped in the UK using local knowledge.  I
live in Canada.  Am I part of the UK local community of mappers?

I think we have to accept a different standard for imports in different
parts of the world.  Africa has seen a fair number of imports of schools
for example.  Many settlement names have been imported in places they look
like a spreadsheet because the accuracy of the import was limited in the
number of digits after the decimal point.  I haven't seen much activity
from Michael on these imports and to be honest even though they have been
imported and the quality isn't perfect they are being used by end users.
OSM is in use by local government as well as NGOs in Africa they have
nothing better. Should we strip out these imports and demand that only data
from local mappers with hand held GPS devices be allowed into the map?

Cheerio John

On 6 January 2017 at 11:20, Christoph Hormann  wrote:

> On Friday 06 January 2017, Mikel Maron wrote:
> > [...] http://www.openstreetmap.org/changeset/39517002 is
> > an example. There were issues with this import, sure. This was not
> > vandalism, advertising, or a fatal breakage of the map -- not a
> > situation where an immediate action was justified (and definitely
> > there are other situations where immediate action is needed).
>
> Agreed, this is not how things should be done.  Note Nakaner is not a
> local mapper here nor does he - to my knowledge - routinely map in this
> area.
>
> Note within the Canadian community there is a significant bandwidth of
> opinions regarding the Canvec imports and also significant voices that
> want to stop them and even remove significant parts of the Canvec data
> again.  Still this is ultimately the decisions of the Canadian
> community, even if - to quote myself - it is worth considering
> if "someone sitting in Toronto, Montreal or Vancouver [is] really more
> of a local mapper on Devon Island or Ellesmere Island than someone from
> Britain, Germany or Russia?"
>
> --
> 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] Wikipedia/Wikidata admins cleanup

[Simon Poole]

Am 06.01.2017 um 16:37 schrieb Mikel Maron:

..

I would suggest that using this case to make your point is seriously
misplaced.

Reverting a broken import asap to allow for a) the guidelines to be
followed, b) address technical and legal issues, is the sensible,
logical and low impact and only scalable course of action. It is
definitely neither unfriendly nor un-welcoming or any other adjective
you want to use*. The earlier and more consistently it happens the less
effort and work is lost by all participants.

If there is an issue with immediate reverts, it is that, particularly in
the past, there hasn't been enough. The numerous broken imports (CANVEC
and broken import is essentially a synonym) that bitrot in our data and
are long past any reasonable way of removing them are testimony to this.

It is fatal for the project that you are creating the impression that as
long as you argue long enough and feign innocence you will be able to
bypass the rules and get away with whatever you want. To the contrary,
we should be making it clear that not following the few, definitely not
particularly arduous to adhere to, rules will result in immediate
removal of the content.

Simon

* the participants in the referenced discussion are neither newbies, not
aware of the guidelines, or any other mitigating factor, but that is not
the point.



signature.asc
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Wikipedia/Wikidata admins cleanup

[Christoph Hormann]

On Friday 06 January 2017, Mikel Maron wrote:
> [...] http://www.openstreetmap.org/changeset/39517002 is
> an example. There were issues with this import, sure. This was not
> vandalism, advertising, or a fatal breakage of the map -- not a
> situation where an immediate action was justified (and definitely
> there are other situations where immediate action is needed).

Agreed, this is not how things should be done.  Note Nakaner is not a 
local mapper here nor does he - to my knowledge - routinely map in this 
area.

Note within the Canadian community there is a significant bandwidth of 
opinions regarding the Canvec imports and also significant voices that 
want to stop them and even remove significant parts of the Canvec data 
again.  Still this is ultimately the decisions of the Canadian 
community, even if - to quote myself - it is worth considering 
if "someone sitting in Toronto, Montreal or Vancouver [is] really more 
of a local mapper on Devon Island or Ellesmere Island than someone from 
Britain, Germany or Russia?"

-- 
Christoph Hormann
http://www.imagico.de/

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

Re: [OSM-talk] Wikipedia/Wikidata admins cleanup

[Mikel Maron]

> "Reverts should be held to the same standard as imports" and "well documented 
>and visible plan" I read it as meaning "I want you to stop doing what you are 
>currently doing in the way that you are doing it", and want to understand 
>why.> I'd much rather the direction on this came from the community rather 
>than the board
You are questioning my motives and my affiliations. Yes, I wrote off the cuff, 
quickly in the middle of the thread. (Though have no idea what you mean by dog 
whistle here -- and I do know what a dog whistle is, I've just survived the US 
election :P). But sure, I'll take a little time here to do my best to achieve a 
clear communication -- no doubt I'll fall short, happy to keep trying.
It is good we have guidelines for handling imports, mechanical edits, disputes, 
and a community and working group that works to protect the map. I helped start 
the DWG after all. I do think there is room for improvement in certain 
circumstances (I'll give an example below) -- particularly around the tone and 
depth of the communication, the right speed of action, and transparency of 
process. My motivation is pretty much the same as everyone's here -- create a 
great map welcome to contributions to everyone who shares the vision of OSM, 
and helps us collectively improve how we do it. And I'm getting involved again 
in the DWG as me -- this has not been discussed by the Board at all, and 
serving as a Board member has no bearing on this discussion for anyone involved.
http://www.openstreetmap.org/changeset/39517002 is an example. There were 
issues with this import, sure. This was not vandalism, advertising, or a fatal 
breakage of the map -- not a situation where an immediate action was justified 
(and definitely there are other situations where immediate action is needed). 
An active mapper and an active community were communicating, acting to fix the 
problems. The reverter in this case choose to ignore the mapper and the 
community and took a unilateral action, in contradiction to some guidelines on 
the wiki. This kind of approach discourages community contribution and 
cooperation. We can do a lot better to cooperatively improve the map and how we 
map it.

We need guidelines and transparency on reverts and other processes of the the 
DWG, so the community knows best how to act when issues arise, and what to 
expect as mappers. We need to have a consistent understanding -- this will only 
help us in the DWG over time. Transparency educates everyone and has benefitted 
other parts of the OSMF, like the Board. Certainly not saying the transparency 
means all is visible -- there are definitely sensitivity topics, privacy 
implications, etc.

So that's where I'm at. My next steps are going to be review what we have 
written up on the wiki (http://wiki.openstreetmap.org/wiki/Vandalism, 
http://wiki.openstreetmap.org/wiki/Data_working_group, 
http://wiki.openstreetmap.org/wiki/Disputes), assess where there's a need for 
more clarity or inconsistencies, and propose some edits.
-Mikel

 * Mikel Maron * +14152835207 @mikel s:mikelmaron 

   

 On Friday, January 6, 2017 6:16 AM, Andy Townsend  wrote:
 
 

  On 05/01/17 12:23, mi...@groundtruth.in wrote:
 
     * Mikel Maron * +14152835207 @mikel s:mikelmaron ...  As Frederik said, 
better reporting and processing can benefit DWG. This is something I want to 
spend time on.
  
 
 I think that it's important that how we do this sort of thing as a project is 
discussed in whatever public forums are available (and right now the "most 
international" one we have is this talk list, alongside the other widely-used 
international community forums for different languages over at forum.osm.org 
such as the DE and RU forums there).
 
 Your "Reverts should be held to the same standard as imports..." post above 
may have been something of a dog-whistle response to Frederik's post, but when 
I read things that talk about "the current revert regime" and say "Reverts 
should be held to the same standard as imports" and "well documented and 
visible plan" I read it as meaning "I want you to stop doing what you are 
currently doing in the way that you are doing it", and want to understand why.
 
 I'd much rather the direction on this came from the community rather than the 
board (and yes, there will obviously be as many different views as there are 
OSM mappers).  If "the communication I've seen from community members making 
reverts has left a lot of rough feelings" then let's talk about it (for a 
start; which particular actions are we talking about?  Was the data that was 
removed added when it shouldn't have been (for e.g. license reasons) and are we 
just talking about the tone of the conversation, or something else?
 
 Activities such as https://www.openstreetmap.org/changeset/44923663 (to take 
an example revert action from me yesterday) are going to become more common as 
more people use OSM.  In this case the sequence of events was 

Re: [OSM-talk] Wikipedia/Wikidata admins cleanup

[Andy Mabbett]

On 6 January 2017 at 12:01, Christoph Hormann  wrote:

> It seems to me by the way that negative feelings of people whose
> activities have clashed with the DWG are natually more voiceful than
> those of people who contacted the DWG in despair because they are
> swamped with an undiscussed import or because they made a mistake
> themselves and ask for help after getting in trouble with others about
> it.

It seems to me that precisely the opposite is true. But as we've both
offered zero evidence for our beliefs, they should each carry no weight.

-- 
Andy Mabbett
@pigsonthewing
http://pigsonthewing.org.uk

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

Re: [OSM-talk] Wikipedia/Wikidata admins cleanup

[Christoph Hormann]

On Friday 06 January 2017, Andy Townsend wrote:
>
> I'd much rather the direction on this came from the community rather
> than the board (and yes, there will obviously be as many different
> views as there are OSM mappers).  If "the communication I've seen
> from community members making reverts has left a lot of rough
> feelings" then let's talk about it (for a start; which particular
> actions are we talking about?

It seems to me by the way that negative feelings of people whose 
activities have clashed with the DWG are natually more voiceful than 
those of people who contacted the DWG in despair because they are 
swamped with an undiscussed import or because they made a mistake 
themselves and ask for help after getting in trouble with others about 
it.  These countless people who are grateful for the help are mostly 
silent.

> Activities such as https://www.openstreetmap.org/changeset/44923663
> (to take an example revert action from me yesterday) are going to
> become more common as more people use OSM.  In this case the sequence
> of events was detect the problem, revert the vandalism, block the
> user and request that an admin delete the account (which was created
> just for that purpose).  I'd argue that those actions (apart from
> block the user) should be able to be carried out by anyone familiar
> enough with OSM to recognise the problem, and we should actually
> encourage everyone in that position to do so - providing that they
> can recognise the difference between obvious vandalism (as happened
> here) and a business owner unable to get the hang of editing and
> renaming something nearby by mistake.

Exactly - and on average you can assume that active mappers are usually 
careful when reverting others' work.  The on-the-ground rule usually 
gives us a very powerful tool to resolve conflicts, something that 
other communities like wikipedia lack.

And the user blocks - which are the only real power of the DWG - are 
well documented on http://www.openstreetmap.org/user_blocks

-- 
Christoph Hormann
http://www.imagico.de/

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

Re: [OSM-talk] Wikipedia/Wikidata admins cleanup

[Andy Townsend]

On 05/01/17 12:23, mi...@groundtruth.in wrote:

* Mikel Maron * +14152835207 @mikel s:mikelmaron
... As Frederik said, better reporting and processing can benefit DWG. 
This is something I want to spend time on.


I think that it's important that how we do this sort of thing as a 
project is discussed in whatever public forums are available (and right 
now the "most international" one we have is this talk list, alongside 
the other widely-used international community forums for different 
languages over at forum.osm.org such as the DE and RU forums there).


Your "Reverts should be held to the same standard as imports..." post 
above may have been something of a dog-whistle response to Frederik's 
post, but when I read things that talk about "the current revert regime" 
and say "Reverts should be held to the same standard as imports" and 
"well documented and visible plan" I read it as meaning "I want you to 
stop doing what you are currently doing in the way that you are doing 
it", and want to understand why.


I'd much rather the direction on this came from the community rather 
than the board (and yes, there will obviously be as many different views 
as there are OSM mappers).  If "the communication I've seen from 
community members making reverts has left a lot of rough feelings" then 
let's talk about it (for a start; which particular actions are we 
talking about?  Was the data that was removed added when it shouldn't 
have been (for e.g. license reasons) and are we just talking about the 
tone of the conversation, or something else?


Activities such as https://www.openstreetmap.org/changeset/44923663 (to 
take an example revert action from me yesterday) are going to become 
more common as more people use OSM.  In this case the sequence of events 
was detect the problem, revert the vandalism, block the user and request 
that an admin delete the account (which was created just for that 
purpose).  I'd argue that those actions (apart from block the user) 
should be able to be carried out by anyone familiar enough with OSM to 
recognise the problem, and we should actually encourage everyone in that 
position to do so - providing that they can recognise the difference 
between obvious vandalism (as happened here) and a business owner unable 
to get the hang of editing and renaming something nearby by mistake.  I 
don't think that "a well documented and visible plan" would help here, 
unless that plan said "if you see something wrong, please take 
appropriate action to fix it" (which I've always thought was the 0th 
rule of OSM anyway).  Anything too bureaucratic would just slow down the 
fixing of problems.


There are lots of interested parties in OSM - all the way from 
individuals like me who 8 years ago were just looking for somewhere to 
store stuff from an old GPS (a route of footpaths and villages across 
Wales, as it happens) up through large non-profit and for-profit 
corporations, all of whom contribute greatly to the OSM ecosystem.  On a 
personal note with the DWG I've found that the large organisations can 
generally look after themselves, and there's a role for standing up for 
the "little guy", whether it's a new mapper in an established community 
or (as in the SADR case upthread) an attempt to remove a country - for 
some definition of country - from the map.  It's important that as a 
community we talk to each other and listen to what everyone else has to 
say, especially when (as in the "wikidata" case) everyone has the best 
interests of the project at heart, just different visions of what those 
best interests are.


Best Regards,

Andy

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

Re: [OSM-talk] Wikipedia/Wikidata admins cleanup

[michael spreng]

Hi Mikel

I would like to offer a different view on community friendliness.

On 04/01/17 22:18, Mikel Maron wrote:
> Reverts should be held to the same standard as imports (outside of
> obviously urgent problems). That means a well documented and visible
> plan, community discussion. Rob's comment shows that it is not possible
> for someone eyeing a revert to judge this from a quick look at the data
> or discussion on talk@. Right or wrong, the communication I've seen from
> community members making reverts has left a lot of rough feelings. I
> don't believe that this thread meets a community friendly threshold for
> reverts.
As a caring contributor I checked my vicinity with regard to this edit.
After all, it touches all borders. This wastes a lot of time and is not
an activity I like. It was not announced on our local mailing list
talk-ch. Therefore I find this forced edit not community friendly.
> 
> Can we hold off on the current revert regime across the board until we
> have as good guidance and practice in place as we have for Imports?
For the above reason, and reasons mentioned in other posts, I fully
support the good work of the DWG. If people go ahead irresponsibly they
should be sent back in order to keep OSM a place to contribute, and not
just fix data dumps.

Michael


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

Re: [OSM-talk] Wikipedia/Wikidata admins cleanup

[Andy Townsend]

On 04/01/2017 22:24, Mikel Maron wrote:
Ok I hear you. Let me walk this back a step. Not the same standard, 
but a standard beyond now that gives some visibility to the process. I 
know there is a process of monitoring, analysis, communication and 
action followed by the DWG. Let's document that. And a simple not 
burdensome log of actions - summarizing the above. This visibility 
will improve community understanding of the process, help to spot 
trends, and improve everyone's work overall.


Well if it helps, my answer yesterday to this help question

https://help.openstreetmap.org/questions/53812/contested-border-sahrawi-morocco-decision-to-display

explains the process that was followed to try and come up with some kind 
of consensus as to how to display that area in OSM.  However, what 
worked in that case may not be appropriate elsewhere because each case 
is different - in fact the most common response that I give to the DWG 
stuff that I deal with is just to try and get everyone to talk to each 
other more to try and understand other points of view, no other actions 
needed.


Best Regards,

Andy

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

Re: [OSM-talk] Wikipedia/Wikidata admins cleanup

[Frederik Ramm]

Hi,

On 01/04/2017 11:24 PM, Mikel Maron wrote:
> Ok I hear you. Let me walk this back a step. Not the same standard, but
> a standard beyond now that gives some visibility to the process. I know
> there is a process of monitoring, analysis, communication and action
> followed by the DWG. Let's document that. And a simple not burdensome
> log of actions - summarizing the above. This visibility will improve
> community understanding of the process, help to spot trends, and improve
> everyone's work overall.

There's nothing in OSM that could not be improved, and DWG certainly
isn't an exception. There's many things we'd like to improve, better
reporting and processes among them.

These are, however, general concerns that are not related to the
handling of any one individual case. Day-to-day work has to go on
normally while we design future improvements. (And while we also
on-board new members to help us implement such improvements, as these
rarely come without additional cost measured in work units.)

In this particular case, we have clearly made a mistake by delaying for
too long the revert of a large-scale mechanical edit that clearly
violated existing rules. In some cases, the rules can be interpreted one
way or another, but this here is not even a close call. Just like the
tile policy says that you get blocked if you abuse the tile server, so
does the mechanical edit policy say that un-discussed mass edits like
this are subject to revert.

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] Wikipedia/Wikidata admins cleanup

[Mikel Maron]

 blockquote, div.yahoo_quoted { margin-left: 0 !important; border-left:1px 
#715FFA solid !important;  padding-left:1ex !important; background-color:white 
!important; }  Ok I hear you. Let me walk this back a step. Not the same 
standard, but a standard beyond now that gives some visibility to the process. 
I know there is a process of monitoring, analysis, communication and action 
followed by the DWG. Let's document that. And a simple not burdensome log of 
actions - summarizing the above. This visibility will improve community 
understanding of the process, help to spot trends, and improve everyone's work 
overall.


Mikel

On Wednesday, January 4, 2017, 5:00 PM, Richard Fairhurst 
 wrote:

Mikel Maron wrote:
> Reverts should be held to the same standard as imports (outside 
> of obviously urgent problems).

Where a revert of an import (or other automated edit) is done by DWG because
an import did not follow the rules, reverting that import just goes back to
the status quo ante.

That allows damage to be cancelled out and the import to be retried, later,
when the problems have been addressed. Nothing is lost to OSM or the
importer, and a lot is gained.

I would gently submit that requiring DWG volunteers to undergo through a
laborious consultation regime for every revert, simply to be able to apply
the long-standing (and well-founded) rules, would achieve nothing apart from
driving away a bunch of selfless, hard-working volunteers.

(There are no other large-scale reverts that take place in OSM to my
knowledge.)

Richard




--
View this message in context: 
http://gis.19327.n8.nabble.com/Wikipedia-Wikidata-admins-cleanup-tp5888517p5888705.html
Sent from the General Discussion mailing list archive at Nabble.com.

___
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] Wikipedia/Wikidata admins cleanup

[Richard Fairhurst]

Mikel Maron wrote:
> Reverts should be held to the same standard as imports (outside 
> of obviously urgent problems).

Where a revert of an import (or other automated edit) is done by DWG because
an import did not follow the rules, reverting that import just goes back to
the status quo ante.

That allows damage to be cancelled out and the import to be retried, later,
when the problems have been addressed. Nothing is lost to OSM or the
importer, and a lot is gained.

I would gently submit that requiring DWG volunteers to undergo through a
laborious consultation regime for every revert, simply to be able to apply
the long-standing (and well-founded) rules, would achieve nothing apart from
driving away a bunch of selfless, hard-working volunteers.

(There are no other large-scale reverts that take place in OSM to my
knowledge.)

Richard




--
View this message in context: 
http://gis.19327.n8.nabble.com/Wikipedia-Wikidata-admins-cleanup-tp5888517p5888705.html
Sent from the General Discussion mailing list archive at Nabble.com.

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

Re: [OSM-talk] Wikipedia/Wikidata admins cleanup

[Christoph Hormann]

On Wednesday 04 January 2017, Mikel Maron wrote:
> Reverts should be held to the same standard as imports (outside of
> obviously urgent problems).

Definitely not - if the only way to counteract an undiscussed mechanical 
edit that goes against the community principles is to have a discussed 
revert we can also abolish the mechanical edit rule right away.

The DWG has a mandate to revert vandalism, undiscussed imports and 
mechanical edits without starting an open discussion first.  It is also 
common practice that local mappers after having tried to contact a 
mapper making such edits without success can revert these on their own.

No one has suggested to sweepingly revert all edits adding wikidata tags 
independent of who made them and in what context.  No one needs to fear 
that additions of wikidata tags made locally with support from the 
local community are removed.

-- 
Christoph Hormann
http://www.imagico.de/

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

Re: [OSM-talk] Wikipedia/Wikidata admins cleanup

[Chris Hill]

I disagree with this. A revert is putting right the wrong of an 
undiscussed mechanical edit or automated import. *All* undiscussed 
imports should be reverted. That will be part of the enforcement of the 
mechanical edit guidelines.


If we want high quality data (and I certainly do) we must enforce the 
widely discussed and accepted mechanical edit guidelines and when 
someone has flouted those guidelines a revert is to be expected, and as 
quickly as possible.


The idea that a bad quality data should be cleaned up so the revert is 
not needed is opening the door to yet more poor quality data imports, 
some of which inevitably doesn't get cleaned up. Clean it up *before* it 
is imported.


OSM is not a database to dump any old data into in the hope that some 
kind soul will tidy up later.


Bad feeling comes from leaving too long before a revert is made. If the 
revert is made quickly then the importer will realise they have to sort 
the data out before it is imported.


I fully support Frederik in his continued efforts to keep the quality of 
data in OSM as high as possible.


--
Chris Hill (chillly)

On 04/01/2017 21:18, Mikel Maron wrote:
Reverts should be held to the same standard as imports (outside of 
obviously urgent problems). That means a well documented and visible 
plan, community discussion. Rob's comment shows that it is not 
possible for someone eyeing a revert to judge this from a quick look 
at the data or discussion on talk@. Right or wrong, the communication 
I've seen from community members making reverts has left a lot of 
rough feelings. I don't believe that this thread meets a community 
friendly threshold for reverts.


Can we hold off on the current revert regime across the board until we 
have as good guidance and practice in place as we have for Imports?

* Mikel Maron * +14152835207 @mikel s:mikelmaron


On Wednesday, January 4, 2017 2:50 PM, Frederik Ramm 
 wrote:




Hi,

On 01/04/2017 07:25 PM, nebulon42 wrote:
> I would revert it then.
> Violations of the automated edits policy should not be tolerated.


Some automated Wikidata additions have been reverted by me in the
past,
mainly where they came from an algorithm that used proximity (and not
existing wikipedia tags) to match OSM to Wikipedia.

As for Yuri's edits which are based on matching Wikipedia tags, I
asked
him on 18 November to stop making un-discussed automated edits:

http://www.openstreetmap.org/changeset/4377#map=6/54.750/35.752

to which Yuri replied (last comment in the list)

"Woodpeck, I have already stopped changing any objects except the
admin
levels regions 1-6, and even those I have greatly slowed down, and
began
reviewing most of the auto-resolved wikidata IDs. I will cease further
automodifications, and instead concentrate on getting wikidata tags
quality review for the admin levels."

Contrary to what he wrote there, he's modified more than one hundred
thousand objects *after* that exchange - newly adding, instead of just
quality reviewing, Wikidata tags.

I think that at in a first step, those wikidata tags added by Yuri
after
18 November need to be removed. It is rather brazen to ignore our
existing rules outright, especially after I had made it very clear to
Yuri that his edits *are* automated edits according to our rules.
I was
a bit hesitant because there's quite a few people in OSM who think
that
low-quality Wikidata tags are better than no Wikidata tags at all, but
hearing here that the express desire of other community members
has been
blatantly ignored just like our automated edit rules have, I'm leaning
towards reverting the lot and making a clean new start.

We're not in a rush here - we can afford to wait until someone who
actually knows the area they are working in has the time to add
Wikidata
tags. That will yield much higher quality data than some automated
matching.

Bye
Frederik

-- 

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

Re: [OSM-talk] Wikipedia/Wikidata admins cleanup

[Eric Gillet]

On Wed, Jan 4, 2017 at 9:41 PM, Rob Nickerson 
wrote:
>
> All,
>
> May I remind, that whilst we have no mechanism to *properly* vote on the
adoption of new tags, we also have no mechanism to *properly* vote on
whether a mechanical edit can go ahead or not, including mass reverts. With
so few OSMers on this list, the discussion here can miss the true
consensus. That works both ways (approving and rejecting an edit).
>
> A few people on this list does not equate to the voice of the OSM
community!


On Wed, Jan 4, 2017 at 10:18 PM, Mikel Maron  wrote:
>
> Reverts should be held to the same standard as imports (outside of
obviously urgent problems). That means a well documented and visible plan,
community discussion. Rob's comment shows that it is not possible for
someone eyeing a revert to judge this from a quick look at the data or
discussion on talk@. Right or wrong, the communication I've seen from
community members making reverts has left a lot of rough feelings. I don't
believe that this thread meets a community friendly threshold for reverts.

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

Re: [OSM-talk] Wikipedia/Wikidata admins cleanup

[Andy Townsend]

On 04/01/2017 21:01, Andy Mabbett wrote:

On 4 January 2017 at 19:49, Frederik Ramm  wrote:


we can afford to wait until someone who actually knows the area they are
working in has the time to add Wikidata tags.

As has been made clear in other discussions in which you have been
involved, this is already underway.



Is it really?  Near me I've been waiting for 
http://www.openstreetmap.org/changeset/43749373 to be fixed since 
mid-November.  The person who commented on 
http://www.openstreetmap.org/changeset/44249131 over in the USA has been 
waiting for a month.




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

Re: [OSM-talk] Wikipedia/Wikidata admins cleanup

[Mikel Maron]

Reverts should be held to the same standard as imports (outside of obviously 
urgent problems). That means a well documented and visible plan, community 
discussion. Rob's comment shows that it is not possible for someone eyeing a 
revert to judge this from a quick look at the data or discussion on talk@. 
Right or wrong, the communication I've seen from community members making 
reverts has left a lot of rough feelings. I don't believe that this thread 
meets a community friendly threshold for reverts.
Can we hold off on the current revert regime across the board until we have as 
good guidance and practice in place as we have for Imports? * Mikel Maron * 
+14152835207 @mikel s:mikelmaron 

On Wednesday, January 4, 2017 2:50 PM, Frederik Ramm  
wrote:
 
 

 Hi,

On 01/04/2017 07:25 PM, nebulon42 wrote:
> I would revert it then.
> Violations of the automated edits policy should not be tolerated.

Some automated Wikidata additions have been reverted by me in the past,
mainly where they came from an algorithm that used proximity (and not
existing wikipedia tags) to match OSM to Wikipedia.

As for Yuri's edits which are based on matching Wikipedia tags, I asked
him on 18 November to stop making un-discussed automated edits:

http://www.openstreetmap.org/changeset/4377#map=6/54.750/35.752

to which Yuri replied (last comment in the list)

"Woodpeck, I have already stopped changing any objects except the admin
levels regions 1-6, and even those I have greatly slowed down, and began
reviewing most of the auto-resolved wikidata IDs. I will cease further
automodifications, and instead concentrate on getting wikidata tags
quality review for the admin levels."

Contrary to what he wrote there, he's modified more than one hundred
thousand objects *after* that exchange - newly adding, instead of just
quality reviewing, Wikidata tags.

I think that at in a first step, those wikidata tags added by Yuri after
18 November need to be removed. It is rather brazen to ignore our
existing rules outright, especially after I had made it very clear to
Yuri that his edits *are* automated edits according to our rules. I was
a bit hesitant because there's quite a few people in OSM who think that
low-quality Wikidata tags are better than no Wikidata tags at all, but
hearing here that the express desire of other community members has been
blatantly ignored just like our automated edit rules have, I'm leaning
towards reverting the lot and making a clean new start.

We're not in a rush here - we can afford to wait until someone who
actually knows the area they are working in has the time to add Wikidata
tags. That will yield much higher quality data than some automated matching.

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] Wikipedia/Wikidata admins cleanup

[nebulon42]

Are your continuous claims of FUD more FUD?
Or is me questioning this more FUD of FUD of FUD?

You see this can go on towards infinity.

Am 2017-01-04 um 22:01 schrieb Andy Mabbett:
> On 4 January 2017 at 19:49, Frederik Ramm  wrote:
> 
>> there's quite a few people in OSM who think that
>> low-quality Wikidata tags are better than no Wikidata tags at all
> 
> Are there? Or is this more FUD?
> 
>> we can afford to wait until someone who actually knows the area they are
>> working in has the time to add Wikidata tags.
> 
> As has been made clear in other discussions in which you have been
> involved, this is already underway.
> 



signature.asc
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Wikipedia/Wikidata admins cleanup

[Andy Mabbett]

On 4 January 2017 at 20:41, Rob Nickerson  wrote:

> Please don't revert the ones near me. We spent considerable time with a
> contributor (not Yuri but someone else) to ensure that my local community
> were happy with the proposed edit before it was completed.

This is also true of several other, disparate, parts of the globe.

-- 
Andy Mabbett
@pigsonthewing
http://pigsonthewing.org.uk

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

Re: [OSM-talk] Wikipedia/Wikidata admins cleanup

[Andy Mabbett]

On 4 January 2017 at 19:49, Frederik Ramm  wrote:

> there's quite a few people in OSM who think that
> low-quality Wikidata tags are better than no Wikidata tags at all

Are there? Or is this more FUD?

> we can afford to wait until someone who actually knows the area they are
> working in has the time to add Wikidata tags.

As has been made clear in other discussions in which you have been
involved, this is already underway.

-- 
Andy Mabbett
@pigsonthewing
http://pigsonthewing.org.uk

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

Re: [OSM-talk] Wikipedia/Wikidata admins cleanup

[Rob Nickerson]

Frederik,

Please don't revert the ones near me. We spent considerable time with a
contributor (not Yuri but someone else) to ensure that my local community
were happy with the proposed edit before it was completed.

All,

May I remind, that whilst we have no mechanism to *properly* vote on the
adoption of new tags, we also have no mechanism to *properly* vote on
whether a mechanical edit can go ahead or not, including mass reverts. With
so few OSMers on this list, the discussion here can miss the true
consensus. That works both ways (approving and rejecting an edit).

A few people on this list does not equate to the voice of the OSM community!

Best,
*Rob*
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Wikipedia/Wikidata admins cleanup

[Tomas Straupis]

> This all conversation confort my (un-educated, I confess) idea of the
> uselessness of cross referencing the Wikipedia ecosystem with OSM with OSM
> tags.
>
> Automated addition of wikidata id to OSM objects seems worthy, so why not
> doing it on the fly instead of writing it to the database? Next year maybe?

  When you have a lot of data, it becomes difficult to verify it. That
is you encounter an "Oracle problem" (it takes too much time for
somebody with a knowledge to verify the date, or you do not have an
Oracle who can verify the data). One way of solving Oracle problem is
to have a different dataset captured INDEPENDENTLY. This way you can
compare two (or more) datasets and identify PROBABLE errors. When such
errors/incompatibilities are found, they should be checked manually
and resolved manually. If you do a dumb copy/overwrite data (maybe
converted data as is the case of wikipedia article->wikidata) you lose
the "two dataset" situation. That is you can no longer use these two
datasets to solve the Oracle problem -> to verify the data in BOTH
datasets. You simply take one of the datasets (or somebody's
assumption of how data in set A converts to set B) as "correct" and
overwrite the other dataset thus destroying the possibility to do a
genuine data validation.

  So such automated addition of wikidata tags without local knowledge
does more damage than good. If all of this change is based on existing
wikipedia tags, such conversion can be done by anybody with minimal
knowledge on the fly.

  And to give more practical perspective. We had been doing
OSM<->wikipedia comparison for more than two years now. That is we
take osm objects which have wikipedia tag and so we get
page:coordinates. Then we take wikipedia dump (***-latest-geo_tags)
and thus get a different dataset of page:coordinates. Then we compare
those two datasets and identify miss-matches. Then we manually check
each of those to be sure that information in BOTH datasets is correct.
We NEVER do any automated update. This is the only way to be sure data
quality is kept at high level. Try going at least through a hundred of
miss-matches and you will see how many different situations there are
and you will understand why automated update is NOT an option.

-- 
Tomas

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

Re: [OSM-talk] Wikipedia/Wikidata admins cleanup

[Frederik Ramm]

Hi,

On 01/04/2017 07:25 PM, nebulon42 wrote:
> I would revert it then.
> Violations of the automated edits policy should not be tolerated.

Some automated Wikidata additions have been reverted by me in the past,
mainly where they came from an algorithm that used proximity (and not
existing wikipedia tags) to match OSM to Wikipedia.

As for Yuri's edits which are based on matching Wikipedia tags, I asked
him on 18 November to stop making un-discussed automated edits:

http://www.openstreetmap.org/changeset/4377#map=6/54.750/35.752

to which Yuri replied (last comment in the list)

"Woodpeck, I have already stopped changing any objects except the admin
levels regions 1-6, and even those I have greatly slowed down, and began
reviewing most of the auto-resolved wikidata IDs. I will cease further
automodifications, and instead concentrate on getting wikidata tags
quality review for the admin levels."

Contrary to what he wrote there, he's modified more than one hundred
thousand objects *after* that exchange - newly adding, instead of just
quality reviewing, Wikidata tags.

I think that at in a first step, those wikidata tags added by Yuri after
18 November need to be removed. It is rather brazen to ignore our
existing rules outright, especially after I had made it very clear to
Yuri that his edits *are* automated edits according to our rules. I was
a bit hesitant because there's quite a few people in OSM who think that
low-quality Wikidata tags are better than no Wikidata tags at all, but
hearing here that the express desire of other community members has been
blatantly ignored just like our automated edit rules have, I'm leaning
towards reverting the lot and making a clean new start.

We're not in a rush here - we can afford to wait until someone who
actually knows the area they are working in has the time to add Wikidata
tags. That will yield much higher quality data than some automated matching.

Bye
Frederik

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



signature.asc
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Wikipedia/Wikidata admins cleanup

[Oleksiy Muzalyev]

On 04.01.2017 20:04, Yves wrote:
This all conversation confort my (un-educated, I confess) idea of the 
uselessness of cross referencing the Wikipedia ecosystem with OSM with 
OSM tags.


Automated addition of wikidata id to OSM objects seems worthy, so why 
not doing it on the fly instead of writing it to the database? Next 
year maybe?


Also, I always wondered what it supposed to happen when an OSM 
contributor who like me does not give a damn of an external ID when 
he/she edits an OSM element?
Yves 


Sometimes a Wikipedia article does not have coordinates. For example the 
article about the STMicroelectronics SA 
 as it is a big 
company with many locations. However, we can add to its headquarters 
building a clickable Wikidata tag and an image tag:

http://www.openstreetmap.org/way/109964315

There other similar case, - no wikipedia article, no wikidata page, but 
there is a Wikimedia commons category; for example La Givrine train station:

http://www.openstreetmap.org/node/249463533

Unfortunately, wikimedia_commons is not yet clickable on the OSM map. 
Here is a clickable link to this category: 
https://commons.wikimedia.org/wiki/Category:La_Givrine_train_station


If you are to travel to/from this train station in mountains, you can 
learn a lot of practical useful information from the Wikimedia category 
images: that there is a heated waiting hall at the station, a ticketing 
machine, etc.


Oleksiy



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

Re: [OSM-talk] Wikipedia/Wikidata admins cleanup

[Yves]

This all conversation confort my (un-educated,  I confess)  idea of the 
uselessness of cross referencing the Wikipedia ecosystem with OSM with OSM 
tags. 

Automated addition of wikidata id to OSM objects seems worthy,  so why not 
doing it on the fly instead of writing it to the database? Next year maybe? 

Also,  I always wondered what it supposed to happen when an OSM contributor who 
like me does not give a damn of an external ID when he/she edits an OSM 
element? 
Yves 

Le 4 janvier 2017 19:19:13 GMT+01:00, Oleksiy Muzalyev 
 a écrit :
>On 04.01.2017 18:05, Christoph Hormann wrote:
>>
>> Well - in OSM use of and reliance on this expensive resource is the
>core
>> of the whole project and we use automated edits only when they are
>> deemed desirable by the expensive humans on a per case basis.
>>
>I agree with this idea completely. At the same time it is so easy to 
>check if a Wikipedia page actually exists programmatically [1] while a 
>mapper ads a wikipedia=* tag. Certainly, it a bit more complicated in 
>the JOSM as it may be used offline. But in any case, why to check it 
>manually? It is a kind of a routine task which could be done by a
>machine.
>
>Another issue is that a popular mobile app Maps.me does show Wikipedia 
>link all right, but does not show Wikidata link at all even when it was
>
>added for the object. Wikidata article is more resilient than a 
>Wikipedia article, which could be renamed, deleted due to a lack of 
>notability or sources, etc.
>
>I can check in Maps.me if a Wikipedia article tag is OK, but wikidata 
>entry is not visible to me for some reason while I am already near an 
>object with a smartphone.
>
>[1]
>
>http://stackoverflow.com/questions/11916429/check-if-url-is-exist-or-not
>
>http://stackoverflow.com/questions/2280394/how-can-i-check-if-a-url-exists-via-php
>
>Best regards,
>
>Oleksiy
>
>
>
>
>___
>talk mailing list
>talk@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/talk

-- 
Envoyé de mon appareil Android avec K-9 Mail. Veuillez excuser ma brièveté.___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Wikipedia/Wikidata admins cleanup

[Oleksiy Muzalyev]

On 04.01.2017 19:52, Christoph Hormann wrote:


It is not the check that needs to be manual, it is the edit.

In other words: finding errors can often be automatized to a high degree
with good reliability - just look at the OSM Inspector coastline and
area views which are very useful for the community.  Fixing them is
something where a manual approach with local knowledge is considered
desirable by most mappers though.

I agree 100% that a manual approach with local knowledge is the right 
way to go about this.



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

Re: [OSM-talk] Wikipedia/Wikidata admins cleanup

[Christoph Hormann]

On Wednesday 04 January 2017, Oleksiy Muzalyev wrote:
> > Well - in OSM use of and reliance on this expensive resource is the
> > core of the whole project and we use automated edits only when they
> > are deemed desirable by the expensive humans on a per case basis.
>
> I agree with this idea completely. At the same time it is so easy to
> check if a Wikipedia page actually exists programmatically [1] while
> a mapper ads a wikipedia=* tag. Certainly, it a bit more complicated
> in the JOSM as it may be used offline. But in any case, why to check
> it manually? It is a kind of a routine task which could be done by a
> machine.

It is not the check that needs to be manual, it is the edit.

In other words: finding errors can often be automatized to a high degree 
with good reliability - just look at the OSM Inspector coastline and 
area views which are very useful for the community.  Fixing them is 
something where a manual approach with local knowledge is considered 
desirable by most mappers though.

-- 
Christoph Hormann
http://www.imagico.de/

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

Re: [OSM-talk] Wikipedia/Wikidata admins cleanup

[nebulon42]

I would revert it then.
Violations of the automated edits policy should not be tolerated.

Michael

Am 2017-01-04 um 19:17 schrieb Philip Barnes:
> On Wed, 2017-01-04 at 18:16 +0200, Tomas Straupis wrote:
>> There was a flow of undiscussed automated wikidata additions in
>> Lithuania with problems. I asked for discussion before automated
>> changes. I was given a promise that a discussion will follow. But
>> there was no discussion. And automated changes resumed. I see it as
>> violation of automated edit rules and would like these edits to stop.
>> Anybody can do atomated changes, it does not take too much knowledge
>> or inteligence to do them. We will do it ourselves, when we want it.
>> So stop!
> 
> That also happened in the UK, the community were promised time to
> review the proposed imports for our areas but it happened before we had
> a chance to comment.
> 
> Phil (trigpoint)
> 
> 
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
> 



signature.asc
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Wikipedia/Wikidata admins cleanup

[Oleksiy Muzalyev]

On 04.01.2017 18:05, Christoph Hormann wrote:


Well - in OSM use of and reliance on this expensive resource is the core
of the whole project and we use automated edits only when they are
deemed desirable by the expensive humans on a per case basis.

I agree with this idea completely. At the same time it is so easy to 
check if a Wikipedia page actually exists programmatically [1] while a 
mapper ads a wikipedia=* tag. Certainly, it a bit more complicated in 
the JOSM as it may be used offline. But in any case, why to check it 
manually? It is a kind of a routine task which could be done by a machine.


Another issue is that a popular mobile app Maps.me does show Wikipedia 
link all right, but does not show Wikidata link at all even when it was 
added for the object. Wikidata article is more resilient than a 
Wikipedia article, which could be renamed, deleted due to a lack of 
notability or sources, etc.


I can check in Maps.me if a Wikipedia article tag is OK, but wikidata 
entry is not visible to me for some reason while I am already near an 
object with a smartphone.


[1]

http://stackoverflow.com/questions/11916429/check-if-url-is-exist-or-not

http://stackoverflow.com/questions/2280394/how-can-i-check-if-a-url-exists-via-php

Best regards,

Oleksiy




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

Re: [OSM-talk] Wikipedia/Wikidata admins cleanup

[Philip Barnes]

On Wed, 2017-01-04 at 18:16 +0200, Tomas Straupis wrote:
> There was a flow of undiscussed automated wikidata additions in
> Lithuania with problems. I asked for discussion before automated
> changes. I was given a promise that a discussion will follow. But
> there was no discussion. And automated changes resumed. I see it as
> violation of automated edit rules and would like these edits to stop.
> Anybody can do atomated changes, it does not take too much knowledge
> or inteligence to do them. We will do it ourselves, when we want it.
> So stop!

That also happened in the UK, the community were promised time to
review the proposed imports for our areas but it happened before we had
a chance to comment.

Phil (trigpoint)


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

Re: [OSM-talk] Wikipedia/Wikidata admins cleanup

[Christoph Hormann]

On Wednesday 04 January 2017, AJ Ashton wrote:
> > "The ID of the Wikidata item about the feature"
> >
> > suggests a one-to-one relationship and having the same wikidata ID
> > on more than one feature would always be an error but taginfo tells
> > us that there are more than 22000 wikidata values that are used
> > more than once.
>
> The idea of "One feature, one OSM element" [...]

I don't think anyone mentioned that concept.  It would not have much 
relevance here since it does not say "One wikidata item, one OSM 
element".

But the current documentation of the wikidata key is based on the 
premise that there is a one-to-one relationship.  If that is not the 
case the definition needs to be changed.

The wikipedia tag for example does not make this assumption, it is meant 
for any wikipedia article about the feature and a wikipedia article can 
of course cover many different OSM features - just like the same OSM 
feature can be subject of multiple wikipedia articles.  It is also 
language specific by the way, if a certain French wikipedia article 
covers a certain feature this does not guarantee that the corresponding 
English language article also covers it.

Needless to say of course that it will likely be impossible to change 
the wikidata key definition in a way that makes all or even most of the 
22000+ values with multiple uses valid.  Because most of these are 
simply cases where the tag was added without actually looking at the 
data and the real world situation.  Rory already explained this for one 
case but you can widely look around there and find many more.

-- 
Christoph Hormann
http://www.imagico.de/

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

Re: [OSM-talk] Wikipedia/Wikidata admins cleanup

[AJ Ashton]

On Wed, Jan 4, 2017, at 08:22, Christoph Hormann wrote:
> "The ID of the Wikidata item about the feature"
> 
> suggests a one-to-one relationship and having the same wikidata ID on 
> more than one feature would always be an error but taginfo tells us 
> that there are more than 22000 wikidata values that are used more than 
> once.

The idea of "One feature, one OSM element" is often thrown around but
it's not what happens in practice. Single roads and bridges are broken
in to many different ways. Provinces, cities, and towns might have both
a node and a way/relation that represent essentially the same concept. A
single named forest or other landuse area might be split into multiple
parts due to a clearing or a road or something.

Some of these situations might arguably be dealt with by adding
relations to unify the parts, but the problem is with the existing
mapping and not the wikidata tagging.

And obviously you will be able to find many example errors as with any
tag. But 22000 duplicate Wikidata IDs is not itself an indication of any
error.

AJ

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

Re: [OSM-talk] Wikipedia/Wikidata admins cleanup

[Andy Townsend]

On 04/01/2017 16:43, Yuri Astrakhan wrote:
* I think MapRoulette is actually the tool we should use to fix these 
issues.


Hell no.

Let's consider that when MapRoulette users have fixed all problems with 
the TIGER data in the USA - a task that it is far better suited to.  
MapRoulette's great for asking questions that can be answered solely 
based on imagery, not requiring local knowledge.  This problem is 
exactly the opposite of that.


Best Regards,

Andy


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

Re: [OSM-talk] Wikipedia/Wikidata admins cleanup

[Andy Townsend]

On 04/01/2017 16:05, Andy Mabbett wrote:

Third time of asking:

would you accept a single random bad tag/changeset on OSM as evidence
that "tags in OSM are already of low quality"?



What's that got to do with the price of fish?

To be clear, this isn't one single changeset.  It's just one example 
that I can comment on in detail because I'm familiar with the things in 
it because they're near me.  I'd expect similar problems wherever this 
wikidata adder also lacks local knowledge, so I'd expect similar issues 
with other changesets further away, and where people have checked, there 
have been some comments - see e.g. 
http://www.openstreetmap.org/changeset/44249131 (as yet unanswered).  I 
suspect that the vast majority of these changes are as yet unchecked.


In OSM, we can use the source tag to distinguish how things were 
surveyed - for example, in the UK "source=NPE" means "from an old 
inaccurate out of copyright map".  It made perfect sense to add things 
from that source when there wasn't a better source available, but now 
that there are better sources available it makes sense to remap.


The problem with these wikidata mass-additions is that (other than 
looking at the users adding this stuff) there isn't a way to say "this 
is based on local knowledge" and "this clearly isn't", so it's not easy 
to decide what needs remapping.


Best Regards,

Andy



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

Re: [OSM-talk] Wikipedia/Wikidata admins cleanup

[Christoph Hormann]

On Wednesday 04 January 2017, Yuri Astrakhan wrote:
> [...]
> Humans are a VERY
> expensive resource, lets use it only when necessary.

Well - in OSM use of and reliance on this expensive resource is the core 
of the whole project and we use automated edits only when they are 
deemed desirable by the expensive humans on a per case basis.

If this seems unreasonable to you it could be a good idea to consider 
OSM might not be the right project for you.

-- 
Christoph Hormann
http://www.imagico.de/

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

Re: [OSM-talk] Wikipedia/Wikidata admins cleanup

[Marc Gemis]

I'm now trying to clean up the wikidata / wikipedia tags on
administrative boundaries in Belgium. One of the problems seems that
nyuriks automatically (?) added  wikidata tags [1] without making sure
the wikipedia tags were placed correctly in OSM.

And now that same person asks to help him clean up the duplicates :-)
Maybe it was the only way to get us to clean up the wikipedia tags ?

regards

m

[1] http://www.openstreetmap.org/changeset/44128900

On Wed, Jan 4, 2017 at 5:43 PM, Yuri Astrakhan  wrote:
> * I think MapRoulette is actually the tool we should use to fix these
> issues. I am not yet sure how to build an OT query that gets relations for
> the challenge, but this approach should automate the whole process. Any
> ideas?
> https://github.com/maproulette/maproulette2/issues/259
>
> * Wikidata tags are already being auto-added. Adding Wikipedia tag in iD
> editor automatically inserts the matching Wikidata tag - and I seriously
> doubt there are many editors who verify Wikidata ID, or even notice that it
> got auto-added. Relying on the "trickling effect" to ensure quality seems
> bad -- quality is much better ensured by automated rule based validations,
> and either autofix if obvious, or add them to MapRoulette for fixing by
> humans.  Humans are a VERY expensive resource, lets use it only when
> necessary.
>
> * Wikidata ID does not have to be 1:1 with OSM.  A Wikidata ID can be
> thought of as a more permanent ID for a Wikipedia title. So adding it simply
> locks WP title in place, nothing more.  Yet, Wikidata could, in theory, be
> more precise. Instead of Wikidata that describes "civil and historical
> perish" (as a matching WP article), there could be a more precise "civil
> only" wikidata item. Most of the time, there is no additional item, and more
> work is needed to possibly create those in WD, and to decide how to link
> between them. In the mean time, having an ID pointing to the "mixed" item is
> ok - it already provides a huge benefit for analyzing, cross-linking, and
> quality assessment. And the mixed item links to the proper Wikipedia
> articles, which was the original goal.
>
> * By far the biggest issue I discovered was numerous "auto-injected"
> Wikipedia titles. It seems people mindlessly copied the object's title into
> the wikipedia tag, without even checking if the article exists, or if it's
> even about a place or something else. Adding Wikidata tag is a huge
> advantage as we now can quickly evaluate the relevance (item needs to be
> "instance of/subclass of" a location. This was never possible with just a
> text title.  It would be amazing to clone/integrate Wikidata database into
> Overpass-Turbo, allowing much more complex validations.
>
> On Wed, Jan 4, 2017 at 11:12 AM Christoph Hormann 
> wrote:
>>
>> On Wednesday 04 January 2017, Andy Mabbett wrote:
>> > >
>> > > Then you'd need to change the tag definition on the wiki to reflect
>> > > that (and to explain what these circumstances are).
>> >
>> > You - and thus I - were talking about "Wikidata values", now you're
>> > talking about a single tag. Which is it, please?
>>
>> I am sorry - OSM terminology can be somewhat ambigous here.  With tag
>> definition i mean the definition of the meaning of a certain tag, i.e.
>> what it is supposed to mean when an OSM feature has the tag wikidata=x.
>> This should be documented on the OSM wiki in a way that reflects actual
>> mapping practice and which is verifiable for mappers.
>>
>> With 'wikidata values' i was referring to the actual values that exist
>> for the wikidata key in our database.
>>
>> > And where is the link I requested?
>>
>> I considered that a rhetorical question.  Taginfo gives you usage
>> statistics for the values used:
>>
>> http://taginfo.openstreetmap.org/keys/?key=wikidata#values
>>
>> --
>> 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
>

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

Re: [OSM-talk] Wikipedia/Wikidata admins cleanup

[Tom Lee]

Like many conversations about Wikidata tagging, I think this one suffers
from varying levels of stringency -- and perhaps letting the perfect become
the enemy of the good.

At the risk of stating the obvious, it is often the case that Wikidata's
conceptual model of places does not exactly match OpenStreetMap's more
precise spatial model of them: for example, the formal administrative
boundaries of a town versus its popular conception; or the historical sense
of a place versus its current boundaries. This is not always true, and when
it is possible to match the conceptual models precisely, that is of course
what should be done (including making Wikidata's model more precise).

I think it is a mistake to say that a critique based on these kinds of
imprecision necessarily constitutes a good reason for removing the tag. It
is often the case that the slightly-mismatched entity is still tremendously
useful. First and foremost, in the vast majority of cases the multilingual
Wikidata labels on the associated entity will still be correct even when
there is a conceptual mismatch. This is a particularly vital function given
the OSM community's occasional insistence that mechanical transliterations
are a trivial problem.

This sort of utility exists with other Wikidata properties as well. And the
relationship can be revised to a more precise form as users' needs arise.
By way of analogy: a forest area tagged as `natural=wood` can be a useful
part of the map even if it contains clearings or meadows. It would be
counterproductive to revert features mapped as such rather than focusing on
their improvement as user needs demand it.

My 0.02. FWIW, we are using Wikidata matched entities extensively in
production (albeit matched to data sources other than OSM). As you might
imagine, these kinds of mismatch problems are unavoidable for us, too. But
the presence of the Wikidata relationship is of truly incredible value, and
often delivers substantial utility even when the match is imperfect.

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

Re: [OSM-talk] Wikipedia/Wikidata admins cleanup

[Yuri Astrakhan]

* I think MapRoulette is actually the tool we should use to fix these
issues. I am not yet sure how to build an OT query that gets relations for
the challenge, but this approach should automate the whole process. Any
ideas?
https://github.com/maproulette/maproulette2/issues/259

* Wikidata tags are already being auto-added. Adding Wikipedia tag in iD
editor automatically inserts the matching Wikidata tag - and I seriously
doubt there are many editors who verify Wikidata ID, or even notice that it
got auto-added. Relying on the "trickling effect" to ensure quality seems
bad -- quality is much better ensured by automated rule based validations,
and either autofix if obvious, or add them to MapRoulette for fixing by
humans.  Humans are a VERY expensive resource, lets use it only when
necessary.

* Wikidata ID does not have to be 1:1 with OSM.  A Wikidata ID can be
thought of as a more permanent ID for a Wikipedia title. So adding it
simply locks WP title in place, nothing more.  Yet, Wikidata could, in
theory, be more precise. Instead of Wikidata that describes "civil and
historical perish" (as a matching WP article), there could be a more
precise "civil only" wikidata item. Most of the time, there is no
additional item, and more work is needed to possibly create those in WD,
and to decide how to link between them. In the mean time, having an ID
pointing to the "mixed" item is ok - it already provides a huge benefit for
analyzing, cross-linking, and quality assessment. And the mixed item links
to the proper Wikipedia articles, which was the original goal.

* By far the biggest issue I discovered was numerous "auto-injected"
Wikipedia titles. It seems people mindlessly copied the object's title into
the wikipedia tag, without even checking if the article exists, or if it's
even about a place or something else. Adding Wikidata tag is a huge
advantage as we now can quickly evaluate the relevance (item needs to be
"instance of/subclass of" a location. This was never possible with just a
text title.  It would be amazing to clone/integrate Wikidata database into
Overpass-Turbo, allowing much more complex validations.

On Wed, Jan 4, 2017 at 11:12 AM Christoph Hormann 
wrote:

> On Wednesday 04 January 2017, Andy Mabbett wrote:
> > >
> > > Then you'd need to change the tag definition on the wiki to reflect
> > > that (and to explain what these circumstances are).
> >
> > You - and thus I - were talking about "Wikidata values", now you're
> > talking about a single tag. Which is it, please?
>
> I am sorry - OSM terminology can be somewhat ambigous here.  With tag
> definition i mean the definition of the meaning of a certain tag, i.e.
> what it is supposed to mean when an OSM feature has the tag wikidata=x.
> This should be documented on the OSM wiki in a way that reflects actual
> mapping practice and which is verifiable for mappers.
>
> With 'wikidata values' i was referring to the actual values that exist
> for the wikidata key in our database.
>
> > And where is the link I requested?
>
> I considered that a rhetorical question.  Taginfo gives you usage
> statistics for the values used:
>
> http://taginfo.openstreetmap.org/keys/?key=wikidata#values
>
> --
> 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] Wikipedia/Wikidata admins cleanup

[Tomas Straupis]

There was a flow of undiscussed automated wikidata additions in Lithuania
with problems. I asked for discussion before automated changes. I was given
a promise that a discussion will follow. But there was no discussion. And
automated changes resumed. I see it as violation of automated edit rules
and would like these edits to stop. Anybody can do atomated changes, it
does not take too much knowledge or inteligence to do them. We will do it
ourselves, when we want it. So stop!
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Wikipedia/Wikidata admins cleanup

[Christoph Hormann]

On Wednesday 04 January 2017, Andy Mabbett wrote:
> >
> > Then you'd need to change the tag definition on the wiki to reflect
> > that (and to explain what these circumstances are).
>
> You - and thus I - were talking about "Wikidata values", now you're
> talking about a single tag. Which is it, please?

I am sorry - OSM terminology can be somewhat ambigous here.  With tag 
definition i mean the definition of the meaning of a certain tag, i.e. 
what it is supposed to mean when an OSM feature has the tag wikidata=x.  
This should be documented on the OSM wiki in a way that reflects actual 
mapping practice and which is verifiable for mappers.

With 'wikidata values' i was referring to the actual values that exist 
for the wikidata key in our database.

> And where is the link I requested?

I considered that a rhetorical question.  Taginfo gives you usage 
statistics for the values used:

http://taginfo.openstreetmap.org/keys/?key=wikidata#values

-- 
Christoph Hormann
http://www.imagico.de/

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

Re: [OSM-talk] Wikipedia/Wikidata admins cleanup

[Andy Mabbett]

On 4 January 2017 at 15:55, Andy Townsend  wrote:

> On 04/01/2017 15:36, Andy Mabbett wrote:
>> Please quantify that; against the total number of Wikidata tags.

> 214 changes in that changeset; at first glance 82 civil parishes in there
> likely to be in error if they have the "Dunham on Trent" problem - about
> 38%.

I'm pretty sure the total number of Wikidata tags on OSM is now in the
tens, if not hundreds, of thousands.

Third time of asking:

   would you accept a single random bad tag/changeset on OSM as evidence
   that "tags in OSM are already of low quality"?

-- 
Andy Mabbett
@pigsonthewing
http://pigsonthewing.org.uk

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

Re: [OSM-talk] Wikipedia/Wikidata admins cleanup

[Rory McCann]

On 04/01/17 16:45, Andy Mabbett wrote:
> And where is the link I requested?

https://taginfo.openstreetmap.org/keys/wikidata#values

Go to page 429. That shows that the first ~22,000 wikidata values have
2+ occurrences. There are hundreds with 10+ values the number of actual
duplicates is much higher than 22,000 (OSM) objects.

The most common wikidata value in OSM is "Q2961670", of which there are
428 OSM objects with wikidata=Q2961670. Wikidata says it's a road in
germany[1], but in OSM it appears to be many roads in northern France
and Belgium[2]. Something's wrong there, no?

[1] https://www.wikidata.org/wiki/Q2961670
[2] http://overpass-turbo.eu/s/l2J





signature.asc
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Wikipedia/Wikidata admins cleanup

[Andy Townsend]

On 04/01/2017 15:36, Andy Mabbett wrote:


Please quantify that; against the total number of Wikidata tags.


214 changes in that changeset; at first glance 82 civil parishes in 
there likely to be in error if they have the "Dunham on Trent" problem - 
about 38%.






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

Re: [OSM-talk] Wikipedia/Wikidata admins cleanup

[Andy Mabbett]

On 4 January 2017 at 15:38, Christoph Hormann  wrote:
> On Wednesday 04 January 2017, Andy Mabbett wrote:

>> There are circumstances where it is legitimate for a
>> Wikidata value to be used more than once.
>
> Then you'd need to change the tag definition on the wiki to reflect that
> (and to explain what these circumstances are).

You - and thus I - were talking about "Wikidata values", now you're
talking about a single tag. Which is it, please?

And where is the link I requested?

-- 
Andy Mabbett
@pigsonthewing
http://pigsonthewing.org.uk

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

Re: [OSM-talk] Wikipedia/Wikidata admins cleanup

[Christoph Hormann]

On Wednesday 04 January 2017, Andy Mabbett wrote:
> There are circumstances where it is legitimate for a
> Wikidata value to be used more than once.

Then you'd need to change the tag definition on the wiki to reflect that 
(and to explain what these circumstances are).

-- 
Christoph Hormann
http://www.imagico.de/

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

Re: [OSM-talk] Wikipedia/Wikidata admins cleanup

[Andy Mabbett]

On 4 January 2017 at 15:24, Andy Townsend  wrote:
> On 04/01/2017 15:08, Andy Mabbett wrote:
>>
>> On 4 January 2017 at 13:09, Andy Townsend  wrote:
>>
>>> Do my comments on http://www.openstreetmap.org/changeset/43749373 count
>>> as
>>> "evidence" or "anecdotes" in your book?
>>
>> It is evidence that /one/ tag is wrong.
>
>
> To quote from the changeset discussion "... Most of the civil parish ones in
> this changeset look similarly wrong... "

Please quantify that; against the total number of Wikidata tags.

And yous eemt o have overlooked my question:

Or would you accept a single random bad tag on OSM as evidence
that "tags in OSM are already of low quality"?

Feel free to read that as "single random bad changeset on OSM..."

-- 
Andy Mabbett
@pigsonthewing
http://pigsonthewing.org.uk

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

Re: [OSM-talk] Wikipedia/Wikidata admins cleanup

[Andy Townsend]

On 04/01/2017 15:08, Andy Mabbett wrote:

On 4 January 2017 at 13:09, Andy Townsend  wrote:


Do my comments on http://www.openstreetmap.org/changeset/43749373 count as
"evidence" or "anecdotes" in your book?

It is evidence that /one/ tag is wrong.


To quote from the changeset discussion "... Most of the civil parish 
ones in this changeset look similarly wrong... "


Best Regards,

Andy


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

Re: [OSM-talk] Wikipedia/Wikidata admins cleanup

[Andy Mabbett]

On 4 January 2017 at 13:22, Christoph Hormann  wrote:

>> Oh, please stop with this FUD.
>
> Back at you.

My request was for evidence to support the original claim. Do you have any?

> taginfo tells us that there are more than 22000 wikidata values that are used
> more than once.

Link, please. There are circumstances where it is legitimate for a
Wikidata value to be used more than once.

-- 
Andy Mabbett
@pigsonthewing
http://pigsonthewing.org.uk

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

Re: [OSM-talk] Wikipedia/Wikidata admins cleanup

[Andy Mabbett]

On 4 January 2017 at 13:09, Andy Townsend  wrote:

> Do my comments on http://www.openstreetmap.org/changeset/43749373 count as
> "evidence" or "anecdotes" in your book?

It is evidence that /one/ tag is wrong. It is an anecdote so far as
the claim "Wikidata tags in OSM are already of low
quality" goes.

Or would you accept a single random bad tag on OSM as evidence that
"tags in OSM are already of low
quality"?

-- 
Andy Mabbett
@pigsonthewing
http://pigsonthewing.org.uk

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

Re: [OSM-talk] Wikipedia/Wikidata admins cleanup

[Oleksiy Muzalyev]

Thank you. Great tool! It makes an inconsistency visible to people to 
make a final decision.


It is probably like in chess. It is not a man alone, neither a 
supercomputer, but a team of strong human players with usual computers 
who win no-holds-barred championship.


On 04.01.2017 13:22, Imre Samu wrote:
>..  this coordinates correction ...  Before this correction it had 
wrong coordinates placing it erroneously on absolutely another 
mountain. ...


As I see there is a tool for detect distance differences :

*OpenStreetMap - Wikidata Validator*
Each circle is an OpenStreetMap feature with a Wikidata tag.
Circle size and color are based on the distance in kilometers
between OpenStreetMap feature and Wikidata coordinates.
Large red circles mean the distance is greater than 10 kilometers,
which indicates a higher error rate.


map: https://osmlab.github.io/wikidata-osm
code: https://github.com/osmlab/wikidata-osm  ( first commit:  Nov 25, 
2016 )

issues: https://github.com/osmlab/wikidata-osm/issues



2017-01-04 11:21 GMT+01:00 Oleksiy Muzalyev 
>:


Certainly a tool to check and correct obviously broken or
duplicate wikipedia=*, wikimedia_commons=*, wikidata=* links from
the OSM map would be very useful.

However, I've met inconsistencies which could be noticed only by a
knowledgeable human on the ground. For example, this coordinates
correction


for the chapel Chapelle Notre-Dame-des-Voirons de Boëge


. Before this correction it had wrong coordinates placing it
erroneously on absolutely another mountain. I could correct it
reliably only after actually visiting this chapel for making some
photos for its article.

The comprehensive solution would be to have a dedicated Wikipedia
layer on the OpenStreetMap. Now we have Standard, Cycle,
Transport, and Humanitarian layers. Why not Wikipedia layer
similar to this


, so that a user can select Wikipedia language and see the
geo-markers corresponding to Wikipedia articles on the map. Or see
clickable geo-markers corresponding to wikipedia=*,
wikimedia_commons=*, wikidata=* tags.

This tool is using MediaWIki API and Overpass API, but for the OSM
Wikipedia layer the data could be pre-calculated and synchronized
periodically in order not to overload the APIs.

In fact, I am using the OSM map mostly with Wikipedia markers. For
example, I was recently on a short holiday trip to Stockholm and
the first thing I do I look what Wikipedia articles exist for the
city


to select places to visit and to read about. So in my opinion,
such a Wikipedia layer would be kind of synergy, - the creation of
a whole that is greater than the simple sum of its parts.

Best regards,
Oleksiy


On 04.01.17 10:27, Jorge Gustavo Rocha wrote:

Hi Yurik,

Nice work.
I'm interested in make such validation a service, to identify and
fix any inconsistencies between OpenStreetMap and
Wikipedia/Wikidata.
I'll be working on that on the next days.

Regards,

J. Gustavo

Às 09:11 de 03-01-2017, Yuri Astrakhan escreveu:

I have been steadily cleaning up some (many) broken Wikipedia and
Wikidata tags, and would like to solicit some help :)

To my knowledge, there is no site where one could add a set of
OSM IDs
that need attention (something like a bug tracker lite, where
one could
come and randomly pick a few IDs to fix), so I made a few tables:

List of Wikipedia tags that do not resolve to Wikidata tags.
Most of the
time, the WP tag is incorrect, sometimes it was deleted, and
very rarely
there is no matching Wikidata item (needs to be created by hand).
* https://www.mediawiki.org/wiki/User:Yurik/OSM_NoWD


List of duplicate Wikidata tags:
* https://www.mediawiki.org/wiki/User:Yurik/OSM_duplicates2


Thanks!


___
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] Wikipedia/Wikidata admins cleanup

[Christoph Hormann]

On Wednesday 04 January 2017, Andy Mabbett wrote:
> > Wikidata tags in OSM are already of low quality because of mindless
> > mass-addition by people with zero local knowledge
>
> Oh, please stop with this FUD.

Back at you.

It is fairly obvious that the majority of wikidata tags in the OSM 
database are mechanically added based on existing wikipedia tags (or 
even worse: through name matching).  Calling this mindless 
mass-addition by people with zero local knowledge is an apt 
description.  There are many wikipedia tags in OSM that do not really 
match the feature they are applied to and correspondingly this is also 
the case for wikidata tags.

Note the definition of the wikidata tag:

"The ID of the Wikidata item about the feature"

suggests a one-to-one relationship and having the same wikidata ID on 
more than one feature would always be an error but taginfo tells us 
that there are more than 22000 wikidata values that are used more than 
once.

-- 
Christoph Hormann
http://www.imagico.de/

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

Re: [OSM-talk] Wikipedia/Wikidata admins cleanup

[Andy Townsend]

On 04/01/2017 12:19, Andy Mabbett wrote:

On 4 January 2017 at 10:11, Frederik Ramm  wrote:


Wikidata tags in OSM are already of low quality because of mindless
mass-addition by people with zero local knowledge

Oh, please stop with this FUD.

Unless you have evidence* to support this assertion, you should
apologise to the good people whose hard work has seen many thousands
of Wikidata tags usefully - and automatically - added to OSM.


* not anecdotes.





Do my comments on http://www.openstreetmap.org/changeset/43749373 count 
as "evidence" or "anecdotes" in your book?  I'm still waiting for the 
issues raised there to be addressed.


FWIW (and this bit is anecdotal - I've not put any numbers together) the 
root cause of the problems I'm seeing local to me seems to be a lack of 
data quality at the wikidata end. Typically, a wikidata article is 
created from a wikipedia article, and that wikipedia article covers more 
than one OSM item.


For example, https://www.openstreetmap.org/relation/957808 is Dunham on 
Trent civil parish, and https://www.openstreetmap.org/node/1782116865 is 
the village itself.  The civil parish object has a wikidata link to 
https://www.wikidata.org/wiki/Q5315240 , but the village does not.  
Unfortunately https://www.wikidata.org/wiki/Q5315240 claims to be a 
village not a civil parish.  It was created from 
https://en.wikipedia.org/wiki/en:Dunham-on-Trent,%20Nottinghamshire 
which claims to be _both_.


You could argue whether the problem occurred at the creation of the 
wikidata item from the wikipedia item, or the linking of the "wrong" OSM 
item to wikidata, but you can't argue that something hasn't gone a bit 
wrong here.


I'd certainly suggest that currently anyone consuming wikidata links in 
OSM data looks very carefully at who added them.  For example, when I 
create Garmin maps (mainly for walking) I try and indicate on them if a 
contributor isn't likely to have actually walked the path in question - 
if I need to get back to a location before it gets dark I might choose a 
path added by someone who's definitely walked down it rather than 
someone who may not have done - maybe wikidata consumers should do 
something similar.


Best Regards,

Andy (SomeoneElse)



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

Re: [OSM-talk] Wikipedia/Wikidata admins cleanup

[Imre Samu]

>..  this coordinates correction ...  Before this correction it had wrong
coordinates placing it erroneously on absolutely another mountain. ...

As I see there is a tool for detect distance differences :

*OpenStreetMap - Wikidata Validator*
Each circle is an OpenStreetMap feature with a Wikidata tag.
Circle size and color are based on the distance in kilometers between
OpenStreetMap feature and Wikidata coordinates.
Large red circles mean the distance is greater than 10 kilometers, which
indicates a higher error rate.


map:  https://osmlab.github.io/wikidata-osm
code: https://github.com/osmlab/wikidata-osm  ( first commit:  Nov 25, 2016
)
issues: https://github.com/osmlab/wikidata-osm/issues



2017-01-04 11:21 GMT+01:00 Oleksiy Muzalyev :

> Certainly a tool to check and correct obviously broken or duplicate
> wikipedia=*, wikimedia_commons=*, wikidata=* links from the OSM map would
> be very useful.
>
> However, I've met inconsistencies which could be noticed only by a
> knowledgeable human on the ground. For example, this coordinates
> correction
> 
> for the chapel Chapelle Notre-Dame-des-Voirons de Boëge
> 
> . Before this correction it had wrong coordinates placing it erroneously on
> absolutely another mountain. I could correct it reliably only after
> actually visiting this chapel for making some photos for its article.
>
> The comprehensive solution would be to have a dedicated Wikipedia layer on
> the OpenStreetMap. Now we have Standard, Cycle, Transport, and Humanitarian
> layers. Why not Wikipedia layer similar to this
> 
> , so that a user can select Wikipedia language and see the geo-markers
> corresponding to Wikipedia articles on the map. Or see clickable
> geo-markers corresponding to wikipedia=*, wikimedia_commons=*, wikidata=*
> tags.
>
> This tool is using MediaWIki API and Overpass API, but for the OSM
> Wikipedia layer the data could be pre-calculated and synchronized
> periodically in order not to overload the APIs.
>
> In fact, I am using the OSM map mostly with Wikipedia markers. For
> example, I was recently on a short holiday trip to Stockholm and the first
> thing I do I look what Wikipedia articles exist for the city
> 
> to select places to visit and to read about. So in my opinion, such a
> Wikipedia layer would be kind of synergy, - the creation of a whole that is
> greater than the simple sum of its parts.
>
> Best regards,
> Oleksiy
>
>
> On 04.01.17 10:27, Jorge Gustavo Rocha wrote:
>
> Hi Yurik,
>
> Nice work.
> I'm interested in make such validation a service, to identify and fix any
> inconsistencies between OpenStreetMap and Wikipedia/Wikidata.
> I'll be working on that on the next days.
>
> Regards,
>
> J. Gustavo
>
> Às 09:11 de 03-01-2017, Yuri Astrakhan escreveu:
>
> I have been steadily cleaning up some (many) broken Wikipedia and
> Wikidata tags, and would like to solicit some help :)
>
> To my knowledge, there is no site where one could add a set of OSM IDs
> that need attention (something like a bug tracker lite, where one could
> come and randomly pick a few IDs to fix), so I made a few tables:
>
> List of Wikipedia tags that do not resolve to Wikidata tags. Most of the
> time, the WP tag is incorrect, sometimes it was deleted, and very rarely
> there is no matching Wikidata item (needs to be created by hand).
> * https://www.mediawiki.org/wiki/User:Yurik/OSM_NoWD
>
> List of duplicate Wikidata tags:
> * https://www.mediawiki.org/wiki/User:Yurik/OSM_duplicates2
>
> Thanks!
>
>
> ___
> 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

Re: [OSM-talk] Wikipedia/Wikidata admins cleanup

[Andy Mabbett]

On 4 January 2017 at 10:11, Frederik Ramm  wrote:

> Wikidata tags in OSM are already of low quality because of mindless
> mass-addition by people with zero local knowledge

Oh, please stop with this FUD.

Unless you have evidence* to support this assertion, you should
apologise to the good people whose hard work has seen many thousands
of Wikidata tags usefully - and automatically - added to OSM.


* not anecdotes.



-- 
Andy Mabbett
@pigsonthewing
http://pigsonthewing.org.uk

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

Re: [OSM-talk] Wikipedia/Wikidata admins cleanup

[Andy Mabbett]

On 3 January 2017 at 09:11, Yuri Astrakhan  wrote:

> To my knowledge, there is no site where one could add a set of OSM IDs that
> need attention

There is, and you can edit it yourself:

   http://wiki.openstreetmap.org/wiki/Main_Page

-- 
Andy Mabbett
@pigsonthewing
http://pigsonthewing.org.uk

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

Re: [OSM-talk] Wikipedia/Wikidata admins cleanup

[Oleksiy Muzalyev]

Certainly a tool to check and correct obviously broken or duplicate 
wikipedia=*, wikimedia_commons=*, wikidata=* links from the OSM map 
would be very useful.


However, I've met inconsistencies which could be noticed only by a 
knowledgeable human on the ground. For example, this coordinates 
correction 
 
for the chapel Chapelle Notre-Dame-des-Voirons de Boëge 
 
. Before this correction it had wrong coordinates placing it erroneously 
on absolutely another mountain. I could correct it reliably only after 
actually visiting this chapel for making some photos for its article.


The comprehensive solution would be to have a dedicated Wikipedia layer 
on the OpenStreetMap. Now we have Standard, Cycle, Transport, and 
Humanitarian layers. Why not Wikipedia layer similar to this 
 
, so that a user can select Wikipedia language and see the geo-markers 
corresponding to Wikipedia articles on the map. Or see clickable 
geo-markers corresponding to wikipedia=*, wikimedia_commons=*, 
wikidata=* tags.


This tool is using MediaWIki API and Overpass API, but for the OSM 
Wikipedia layer the data could be pre-calculated and synchronized 
periodically in order not to overload the APIs.


In fact, I am using the OSM map mostly with Wikipedia markers. For 
example, I was recently on a short holiday trip to Stockholm and the 
first thing I do I look what Wikipedia articles exist for the city 
 
to select places to visit and to read about. So in my opinion, such a 
Wikipedia layer would be kind of synergy, - the creation of a whole that 
is greater than the simple sum of its parts.


Best regards,
Oleksiy

On 04.01.17 10:27, Jorge Gustavo Rocha wrote:

Hi Yurik,

Nice work.
I'm interested in make such validation a service, to identify and fix 
any inconsistencies between OpenStreetMap and Wikipedia/Wikidata.

I'll be working on that on the next days.

Regards,

J. Gustavo

Às 09:11 de 03-01-2017, Yuri Astrakhan escreveu:

I have been steadily cleaning up some (many) broken Wikipedia and
Wikidata tags, and would like to solicit some help :)

To my knowledge, there is no site where one could add a set of OSM IDs
that need attention (something like a bug tracker lite, where one could
come and randomly pick a few IDs to fix), so I made a few tables:

List of Wikipedia tags that do not resolve to Wikidata tags. Most of the
time, the WP tag is incorrect, sometimes it was deleted, and very rarely
there is no matching Wikidata item (needs to be created by hand).
* https://www.mediawiki.org/wiki/User:Yurik/OSM_NoWD

List of duplicate Wikidata tags:
* https://www.mediawiki.org/wiki/User:Yurik/OSM_duplicates2

Thanks!


___
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] Wikipedia/Wikidata admins cleanup

[Frederik Ramm]

Hi,

On 01/04/2017 10:27 AM, Jorge Gustavo Rocha wrote:
> Nice work.
> I'm interested in make such validation a service, to identify and fix 
> any inconsistencies between OpenStreetMap and Wikipedia/Wikidata.
> I'll be working on that on the next days.

Please ensure that you do not *automatically* fix or edit OSM data based
on Wikipedia/Wikidata. Instead, build something that lets users spot
problems and fix them manually. Wikidata tags in OSM are already of low
quality because of mindless mass-addition by people with zero local
knowledge and we don't want to make the matter worse.

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] Wikipedia/Wikidata admins cleanup

[Jorge Gustavo Rocha]

Hi Yurik,

Nice work.
I'm interested in make such validation a service, to identify and fix 
any inconsistencies between OpenStreetMap and Wikipedia/Wikidata.

I'll be working on that on the next days.

Regards,

J. Gustavo

Às 09:11 de 03-01-2017, Yuri Astrakhan escreveu:

I have been steadily cleaning up some (many) broken Wikipedia and
Wikidata tags, and would like to solicit some help :)

To my knowledge, there is no site where one could add a set of OSM IDs
that need attention (something like a bug tracker lite, where one could
come and randomly pick a few IDs to fix), so I made a few tables:

List of Wikipedia tags that do not resolve to Wikidata tags. Most of the
time, the WP tag is incorrect, sometimes it was deleted, and very rarely
there is no matching Wikidata item (needs to be created by hand).
* https://www.mediawiki.org/wiki/User:Yurik/OSM_NoWD

List of duplicate Wikidata tags:
* https://www.mediawiki.org/wiki/User:Yurik/OSM_duplicates2

Thanks!


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



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