-
Notifications
You must be signed in to change notification settings - Fork 8
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add inner and outer members of boundary and multipolygon relations #72
Comments
Another possible way to satisfy this use case would be to add |
osm2rdf has an option @lehmann-4178656ch @patrickbr Do you agree? |
@1ec5 I have set up a SPARQL endpoint for the data from Germany (that was quick to do), where relations now have the mentioned members. Can you please check whether that has all the triples you need: https://qlever.cs.uni-freiburg.de/osm-germany . Note that for that endpoint the geometries are obtained again with geo:hasGeometry (without the geo:asWKT). I didn't do that on purpose, it was accidental, but just so you know. Here is a query which gives (and shows) all the geometries of all the members of Berlin: https://qlever.cs.uni-freiburg.de/osm-germany/TWlwsr |
Thank you, yes, this query returns the least compact |
@1ec5 Thanks for the feedback! @lehmann-4178656ch @patrickbr The increase in the number of tripels due to |
@lehmann-4178656ch is already working on a PR to make Regarding additional data completeness options: we are currently not outputting the "members" (node IDs) of ways. The reason is that most of these nodes are empty (without any attributes). We could do this, but it would significantly increase the dataset size (essentially, we would add 3 triples for each anchor point of a way geometry: (1) a triple connecting the way to the empty OSM node, (2) a Another thing I just thought of: we are also not outputting author information, which could be present in the input .pbf file (it is present in the input files we use for https://osm2rdf.cs.uni-freiburg.de/). I might be interesting to get all objects last authored by user X. Also, the changeset id (basically an OSM "commit") is currently not dumped. |
These way members and changeset metadata are often used in Overpass queries, but I refrained from asking for them upfront because I assumed they’d be of more interest internally to OSM and OHM than externally. Off the top of my head, one external use case would be finding a given building’s entrances, something geocoders might do to better serve navigation applications. Another would be finding street intersections. For reference, Sophox includes relation members but omits way members. Sophox also includes the element’s version and last changeset, timestamp, and user. Some of the example queries make use of this functionality. |
@1ec5 I am already convinced that these should be in our dataset. Just waiting for feedback from @lehmann-4178656ch and @patrickbr . They already agreed that we should have the information about changeset, timestamp, and user in our dataset. It's just a few billion more triples :-) |
A late update to this thread:
@patrickbr @lehmann-4178656ch What about the changeset and user information? |
@1ec5 Does my previous comment also address the problem you had with your original timezone query? |
Wonderful!
I’ve added an example query to the OSM Wiki.
Yes, this query actually gets a bit closer to the point I was trying to make in that forum discussion than Overpass was able to, since QLever allows us to distinguish between |
There is actually an open PR for this: #83 I will merge this into master today. |
@patrickbr Great, thanks! I will consider this for the next version of https://qlever.cs.uni-freiburg.de/osm-planet. Two questions:
|
By default at the moment. But I will add a configuration option to disable it.
For an input dataset containing the |
Right, in particular, the public extracts from Geofabrik omit this information, due to their implementation of GDPR compliance. They have a separate set of extracts containing this information that’s restricted to OSM users and subject to a click-through confidentiality agreement. The official first-party OSM planets don’t have these restrictions, but I’m unfamiliar with the reasoning for the different approaches. |
Ok, so around 40B more triples for OSM Planet, piece of cake :-) |
@1ec5 Do you have any idea, why GDPR compliance is an issue here, given that the complete dataset (including the user infomation) is public? |
Unfortunately, this isn’t my area of expertise. The data protection laws are different where I live (in California). The OSM Wiki has some documents related to the OSMF’s compliance with GDPR, but it’s unclear to me whether the same considerations would apply to QLever. Besides the official OSMF planet distribution, the major Overpass API instances, Sophox, and OSM by the Slice all expose this metadata based on the official planet. As far as I know, Geofabrik is the only redistributor of raw OSM data that has taken the step of gating access to the metadata behind an OSM account. I just brought it up because it’s the most popular source of extracts in OSM PBF format. |
@1ec5 The latest version of https://qlever.cs.uni-freiburg.de/osm-planet now has predicates for
|
This query shows that no boundary or multipolygon relation in the OSM Planet dataset has
osmrel:member
s that are ways with the roleinner
orouter
. The only members in the dataset arelabel
andadmin_centre
nodes,subarea
relations, and plenty of tagging mistakes. This makes it difficult to perform tasks such as:Also, in this OSM discussion, I needed to access the ways that make up a boundary relation in order to determine the total set of ways that would be part of a proposed time zone relation. I had to drop down to Overpass, which has various recursing operators as well as a
length()
operator.The text was updated successfully, but these errors were encountered: