I am unable to get OLU to run on an OSM dataset for Bremen

[nicolano]

I am unable to get OLU to run on an OSM dataset for Bremen. The TTL extracts at https://osm2rdf.cs.uni-freiburg.de are only available for countries. Converting the snapshots from Geofabrik (both external and internal) with osm2rdf (adfreiburg/osm2rdf:latest as of today) and --add-way-node-order results in an error when running OLU.

No such node (sparql.results.result.binding.literal)
Could not fetch latest timestamp of any node from sparql endpoint

Originally posted by @Qup42 in ad-freiburg/qlever#1683 (comment)

[nicolano]

I have created a new issue for the problem with the bremen dataset, as it is better placed here than in the qlever repository.

The error "No such node (sparql.results.result.binding.literal)" when fetching the latest timestamp means that the endpoint returned an empty response for the query:

PREFIX osmmeta: <https://www.openstreetmap.org/meta/> PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> PREFIX osm: <https://www.openstreetmap.org/> SELECT ?p WHERE { ?s rdf:type osm:node . ?s osmmeta:timestamp ?p . } ORDER BY DESC(?p) LIMIT 1

Can you check if this query would produce a result in the qlever ui for your bremen instance?

[Qup42]

The queries return an empty result for both the public and internal datasets for bremen from Geofabrik. The string timestamp does not occour in the ttl produced by osm2rdf. I ran osm2rdf with --add-way-node-order as instructed in the readme.

[nicolano]

I believe support for timestamps of osm objects was introduced in osm2rdf with this PR. Could you check if the version of osm2rdf you are using is up to date?

Ideally, you can use this fork of osm2rdf, which is also used internally by olu.

[Qup42]

I was just using the container image as one was available. Turns out, the image in the docker registry is 3 years old. Not to use the docker image might also be a valuable note for the olu readme. At least until the PR adding a CI job for that is merged. I'll try with a current version and report back.

What are the differences in the fork compared to the upstream?

[nicolano]

Thanks for the information, i have added a recommendation to use the fork to the readme.

The fork avoids the use of blank nodes, as they currently cannot be inserted into QLever endpoints (Issue)

[Qup42]

The outdated osm2rdf was indeed the cause for the missing timestamps. olu now runs until the first delete, then it aborts because not enough memory is available (32 Values per Update). But that is another issue.