>>   It is mostly because you pushed the effort, not beaucse of
>> "advantage of wikidata". The same fixing has already been done for
>> YEARS before your effors based on wikipedia tags only.
>
>
> Tomas, you claimed that "It adds NO value."  This is demonstrably wrong. You
> are right that the same fixing was done for years. But until wikidata tag,
> there was no easy way to FIND them.

  There always was.
  You simply take wikipedia provided geo-tags dump like
https://dumps.wikimedia.org/ltwiki/latest/ltwiki-latest-geo_tags.sql.gz

  This gives you a very simple table with: lat/lon/page_title.
  No parsing or anything else involved.
  You then take data from OSM - lat/lon/wikipedia.tag
  So you have two tables of same structure. Voila. You can compare
anything (title, coordinates), in any direction with some
approximation if needed etc. No OSM wikidata involved at all.

  If wikipedia page moves - title is gone from this dump and the new
one appears on the same coordinates. You can map them very quickly.
Theoretically you can update OSM data automatically, but usually if
wikipedia title has changed, it means that something has changed in
the object on the ground, so maybe something else has to be changed in
OSM data as well (for example name).

> About a year ago when I first started
> this project, I created lists of thousands of such errors, that were very
> rapidly fixed once they were identified. This was not possible before.

  Cool. I have nothing against that. I'm just saying the same could be
done without wikidata tags.

> My method is for finding broken wikipedia tags. What method are you talking
> about? Can you describe what method you use to identify errors?

  See above.

> Here is the DATA for my "theoretical ramblings". Can you show any data to
> back your theoretical ramblings?

  See above. What are practical advantages of your method?
  Because theoretically you are taking a set A, creating a new set B
from this A, and then you're trying to fix A according to B. This is
logical nonsense :-) There is no point of putting this B into OSM.
This is a temporary data which could be stored in your local "error
checking" database.

> Now there is a simpler http://tinyurl.com/ybv7q7n6 query - it used to have
> about 1300, now down to ~750. And these are JUST the disambig errors.

  550 objects globally... Well... :-) You should see from here, that
the problem is finding people who want to FIX, not finding problems...

> wiki. Lastly, what am I proposing to destroy?!?  I am ADDING a tag and
> ADDING a new search mechanism, because there is current no reliable
> mechanism to fix these things.

  I have nothing against that. I'm arguing against idea that wikipedia
tag is outdated or in any way worse. Yes, OSM would not be born
without a geek idea, but it would not have reached what it is now if
it would not be easy to understand for non geeks. Wikidata tag is
totally non-understandable to non-geeks.

> This is wonderful that you are fixing all these issues, could you tell me
> how you find them? Also, funny enough, I used to live in Vilnius a long time
> ago, near Gineitiškės. Should I be allowed to edit there? (I hope this
> doesn't lead to another huge but unrelated discussion :) )

  You know that is not the point. You could still live in Lithuania
and you would still need to consult the local community before doing
automated changes.

>>   When we create a POI detail page, we want to add a link (url without
>> redirects) to a wikipedia page. To do that it is straightforward to
>> use a value in wikipedia tag.
> Great, thanks. As you can see, nothing in what I do breaks that. Instead, it
> actually helps your POI links to be more accurate.

  It does not help. We are not using wikidata in any way. We are
fixing wikipedia links, OSM objects, wikipedia articles manually using
automated checks described above to pinpoint the problems.

-- 
Tomas

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

Reply via email to