Introduce writeMeta and use for Nodes, Relations and Ways #83
Conversation
|
Partial example output for Lichtenstein: |
|
I have merged the latest master and made the following changes:
|
| osm2rdf::ttl::constants::IRI__OSMMETA_VERSION = | ||
| generateIRI(osm2rdf::ttl::constants::NAMESPACE__OSM_META, "version"); | ||
| osm2rdf::ttl::constants::IRI__OSMMETA_VISIBLE = | ||
| generateIRI(osm2rdf::ttl::constants::NAMESPACE__OSM_META, "visible"); |
There was a problem hiding this comment.
visible is guaranteed to be either true or false in the OSM XML format, so the corresponding triples could have Boolean values instead of strings. That said, visible will always be true in any normal extract of OSM or OHM data unless you specifically load an extract that contains full history.
There was a problem hiding this comment.
I agree, I changed it to boolean values. Also, the visibility triples are now only written if visibility is false.
…ll normal datasets), use boolean value for visible and also for hasCompleteGeometry triples
|
This PR now also adds the option |
|
At https://qlever.cs.uni-freiburg.de/osm-test you find a SPARQL endpoint for all objects in the bounding box of Germany (extracted from For example, https://qlever.cs.uni-freiburg.de/osm-test/4gtzjU . Note that every object has a version and changeset, but there are a few objects without timestamp or user, hence the two OPTIONALs in the query. @1ec5 Does this now contain all the information you would expect or is there something important still missing? |
There was a problem hiding this comment.
Yes, I think this is what I’d intuitively expect when metadata happens to be available in the source dataset. The visibility flag has me wondering about what it would like to support historical queries in the future, but you’d probably like to save that idea for some other day. 😉
| // avoid writing empty users, drop entire triple | ||
| if (!object.user().empty()) { | ||
| _writer->writeTriple(subj, IRI__OSMMETA_USER, | ||
| _writer->generateLiteral(object.user(), "")); |
There was a problem hiding this comment.
Just for your awareness, one common attribute hasn’t been implemented yet: uid is the user’s numeric identifier. Looking at the alternative query engines, OverpassQL has a uid() operator, while Sophox doesn’t expose this information at all. Wikidata has a lightly used OpenStreetMap numeric user ID (P8754) property (only for otherwise notable users), which is expected to have a website username or ID (P554) qualifier.
A UID has somewhat different privacy implications than a user name. A user can change their user name at any time, but the UID remains constant. If the user deletes their account, the UID remains on any element they edited until someone else edits that element.
User names and UIDs are primarily used for quality assurance, or for mappers to track their own contributions somewhat crudely. I suspect people use user names more frequently than UIDs when crafting Overpass API queries by hand, since UIDs are somewhat hidden on the main OSM website. However, anything that needs to be stable despite user renaming, such as countervandalism tools, would probably use UIDs instead.
There was a problem hiding this comment.
The UID is now also written (predicate osmmeta:uid).
Also, I added proper prefixes for OSM users (https://www.openstreetmap.org/user/) and changesets (https://www.openstreetmap.org/changeset/).
There was a problem hiding this comment.
Also, I added proper prefixes for OSM users (
https://www.openstreetmap.org/user/)
Reverting this to simply using strings for user names again because of some strange UTF-8 encoding issues when creating the user IRIs for flamboyant user names.
There was a problem hiding this comment.
Thank you. Out of curiosity, what kind of problematic sequences occurred in the user names that prevented UTF-8 encoding? That might be useful for the OSM Wiki to document for other data consumers too.
writeMetaadds Facts aboutchangeset,timestamp,user,versionandvisible. If these values are not set0,1970-01-01 00:00:00and""depending on the key will be answered.