"On 29 May 2015 at 09:58, Martin Koppenhoefer <dieterdre...@gmail.com> wrote: > > 2015-05-28 23:00 GMT+02:00 Andy Mabbett <a...@pigsonthewing.org.uk>: >> >> On 28 May 2015 at 09:50, Martin Koppenhoefer <dieterdre...@gmail.com> >> wrote: >> >> > e.g. the "en:Spanish Steps" / "de:Spanische Treppe" are >> > called "Scalinata di Trinità dei Monti" in the local language (it is >> > located >> > at "piazza di Spagna", that's where the foreign name comes from, while >> > in >> > Italian it is called after to church it leads to). Naturally, OSM has >> > the >> > original name of this world famous monument, but Wikidata hasn't. >> >> It does now.
> OK, this is one point for you, but it also proves my point: wikidata at the > moment is not sufficiently mature (IMHO) to replace name tags in different > languages in OSM. It proves nothing of the kind, Does OSM still have work needing to be done? Is OSM "not sufficiently mature to replace" other mapping services? > Of course you can fix wikidata issues (if you understand > how it is done, I haven't had enough time yet to understand how to make > edits like this, How long does it take a new mapper to understand how to make such edits in OSM? > and the fact that not all tags are shown to me Try logging in and enabling the "Labels list" gadget; or alternatively https://www.wikidata.org/wiki/Q1?withJS=MediaWiki:Gadget-labelLister.js for the Q value of your choice (I did say I would provide an update about this in an earlier post) > (e.g. only 4 > out of all language labels, after I have explicitly clicked on "in more > languages")) doesn't help. Did you use the "configure" link alongside that? > Now I could link the wikidata object of the spanish steps to the OSM object > and get an Italian name. But I will not have an Italian wikipedia article > about it, because it is covered in the spanish square (piazza di spagna) > article in Italian. How would I ideally procede now? There is no Italian Wikipedia article about the steps. So what? >> > and impose our entity structure on them, >> >> Really? Good luck with that. > what I meant, and what you do confirm below: if for instance there is an > object in wikidata which is an administrative entity and a geographic place > at the same time, but for OSM we'd need 2 distinct objects, we will have to > split the wikidata object. This could be done only if there wasn't > resistance from other wikidata users who might want to keep the current > unmodified object because it links better to wikipedia articles. There would be no such resistance. > We might > introduce another object that linked the split objects onto one, which could > serve for wikipedia articles, etc. but this is a much more complicated > procedure than changing tags in OSM alone. It's trivially easy. You just said atht you haven't yet learned to do so, that is all. >> > or it won't work in some cases (and if it doesn't work in some case, it >> > doesn't work at all). >> >> That is, of course, nonsense. > OK, let's say it is nonesense, because you can accept that a solution works > for most of the cases and try work around those that don't work. Currently > (all names in OSM) we don't have these problems though. We have another set of problems: Disagreement over when to include names; insufficient volunteer-hours, etc. > IMHO you have to understand to which geometry you are referring when you > make edits, or you might break stuff without noticing it. Wikidata editors > would have to look at OSM geometries to ensure that their edit maintains > consistency, Why would they? I say that claim is bogus. > and OSM users would have to check wikidata to see if editing > something in a certain way (e.g. merges or splits, adding tags, changing > geometry) is OK or whether they have to split the wikidata object and update > the wikidata link. It is not impossible, but it is an enormous amount of > complexity added, For those who wish to do so, this is not onerous. > and it also augments the risk of non-availability of the > backend by 100% (because now we depend on 2 services and not on one). Not if, as others have suggested, data is cached. In any case, WIkdiata's relaibality, like other WMF projets, is commendably high. -- Andy Mabbett @pigsonthewing http://pigsonthewing.org.uk _______________________________________________ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
