My point is, as long this problem is not addressed properly, we shouldn’t invest our time to Wikidata, because performance-wise it’s quite risky.

I dug into this quite s lot and even helped WMF investigate and evaluate alternatives.

I wholeheartedly disagree with avoiding Wikidata based on the assumption thst the whole project is brittle. Wikidata is not brittle. If, and this if is still theoretical, WDQS cannot cope with the amount of triples tomorrow, then there are viable (AFAICS) plans to get it back up in a short time.

The lack of scalability of Blazegraph is a problem and WMF is working on it.

Note that Wikidata is a mix of mariadb and blazegraph. The former is not affected by the latter which is a rdf slap on getting updated every few minutes.

Also there is really no good reason for WMF to be the only one making Wikidata available for queries. Anyone can download the dump, run the updater and provide a good query service. See e.g. https://addshore.com/2022/10/a-wikidata-query-service-jnl-file-for-public-use/

https://github.com/LeMyst/WikibaseIntegrator Simple bot written with WBI https://github.com/internetarchive/cgraphbot Hiking trail matcher https://www.wikidata.org/wiki/Q114238977 (also written using WBI) I started the https://www.wikidata.org/wiki/Wikidata:WikiProject_Hiking_trails and tried to prepare a few imports to wikidata so I can have an overview over what is still missing in OSM. Unfortunately as you can see there in the country subpages the data we get from authorities is quite dirty and for New York it’s a mix of trails and trail systems (which are probably mappablein osm in a relation, but I’m not sure anyone has done that and it’s probably not verifiable on the ground 🤷‍♂️)

In Sweden there are thousands of trails on the ground but very little official data about any of them as of yet. I’m poking the relevant authorities to release their data as open data.

Hi. Thanks for sharing this information and analysis. I work with Wikidata since a few years and use WikibaseIntegrator to create bots and tools and I am an advanced osm editor also.

wikibase API is complex, annoying and troublesome. In comparison using https://github.com/earwig/mwparserfromhell allowed to get me parsed infobox parameters in time that I used in failed attempt to get “required tags” field out of wikibase API. Going by name mwparserfromhell is dealing with a lot of complexity underneath, but as user of this it was really pleasant.

I agree with the statements about complexity. It is not easy to use, the documentation on errors is lacking, the errors are lacking clarity because they don’t point to what in the blob of json you tried to upload that were rejected, etc. Without a good library like WikibaseIntegrator you are probably going to quickly get a headache when interacting with the Wikibase API 🤷‍♂️

That said the system is allowing a whole new level of semantic encoding and linking that is not possible on a wikipage. The question is if the community is willing to invest in this and see the benefits clearly or not.

I have used the wikidat <> osm webui matcher quite a lot to find matches between the two projects. I have used Sophox to create interesting federated queries. None of that rely on the data items in the osm wiki because we store the necessary mappings already in Wikidata 🤷‍♂️

I recently created my own matcher for my purposes, see url in my next post

I really like the community of OSM, the on the ground rule, etc but the data mode is not really to my liking. It makes imports hard (for example of addresses in DK or nature reserve boundaries in SE (they cannot be observed on the ground btw so maybe OSM is not the right place for this kind of data because it cannot be verified by other mappers?). All in all I see a future with Wikidata containing most of the data except the geographic features themselves. I see no point in storing names of features in osm if there is a wikidata link for example, but my work on shelters also made me think that other data like the area or whether it has a floor or bot is probably better stored in Wikidata where it can be easily queried and validated using an EntitySchema.

I like that iD is disallowing edits to brand name when there is a brand qid. I see a future with more cross editing. That is we agree on what data to have only in Wikidata and iD or other editors upload to Wikidata instead of storing it in OSM.

This increases complexity btw. To edit osm you suddenly have to also grapple with a monster like Wikidata. But the advantages probably outweigh the complexity.

Nice work!

@beautifulplaces2020 I think you misunderstood the policies. There is a pretty strict import policy, but if your municipality has CC0 or CC-BY with a waiver of the attribution, it totally possible to add official addresses. In DK they added them in bulk for most of the country a while back. Please contact the local mapping community and help get involved. I contacted the Swedish authorities and open addresses for all of Sweden is on their roadmap in the near future. Your government could probably be persuaded to release the information as well. I add addresses using the AddressIntrapolation plugin after scouting them out. It’s pretty fast once you get the hang of it. Cheers

Very nice 😃.

Beware of the “no waypoints found bug” with OsmAnd, workaround is here: https://github.com/osmandapp/OsmAnd/issues/11278

Big thanks. Very clear

Fantastic!

A ha! Thanks again mmd! This should be added to the union documentation I think.

Code is now at https://github.com/pangoSE/gpx-extractor MIT license. Feel free to create issues with ideas for improvements or bugs.

I now added jQuery Autocomplete from the Wikipedia API. I’m quite happy with the result! :)

@mmd Thank you! Now I understand. I will add center to all queries then. :)

Hi Hamlet. Have a look on WP:Brittany. It says: “This article is about the cultural region in the north-west of France. For the current French administrative region, see Brittany (administrative region).”

So in this case “Brittany (administrative region)” should work in your case as it is linked with Q12130.

Hi mmd, which query do you mean?

This is the function that builds the query: function buildQuery(areaCode) { var q = ‘https://overpass-api.de/api/interpreter?data=[out:xml][timeout:325];area(‘+areaCode+’)->.searchArea;’+query+’out;’;

I decided not to add “center” after out because it does not seem to be necessary and make the query time much longer. togpx() handles the data like this: “Points are converted to Waypoints. Lines are converted to Tracks. (Multi)Polygons are represented as a Track of their outline(s).” see https://github.com/tyrasd/togpx

I don’t know how this looks on a GPS-device because I don’t own one.

Very nice! I would love to see something like this from more board members and others active in the community 😃

*try

Did you hey https://osm.wikidata.link/ ?

Med det ny MapWithAI tillägget undrar jag om det fortfarande kan betala sig att hålla på med halvgammal LM data? Det går ganska snabbt för mig att lägga till vägar nu och LM topo anger vägklass.

I have improved the query to better catch the type of paths I’m interested in and added it to the examples as a similar example was missing. https://wiki.openstreetmap.org/wiki/Overpass_API/Overpass_API_by_Example#Count_number_of_ways_and_length Do any of you know how if it is possible to calculate this over time? Say yearly?