Support of querying based on meta data

[aighes]

Couldn't find anything regarding whether the meta data like user name or creation date of nodes/ways/relations can be queried or whether it's planned at all in any future version?

It might be quite useful to filter for own data or stuff like this.

[clarisma]

Thanks for opening this issue!

GOLs currently do not store metadata of features. Metadata support is not on our road map as of now, but we may consider adding it if there is sufficient demand.

Below are some thoughts on use cases and technical aspects:

Metadata in OSM

What is stored in OSM-PBF:

• changeset ID
• user name/ID (name can change; ID is fixed)
• object version
• timestamp

(Separate changeset files track other metadata related to the entire changeset: sources, tags, QA flags, etc.)

Potential use cases

• Contributor statistics
• Quality assurance
  • For low-quality edits or vandalism, find edits by the same user
  • How recent is the data? (A feature that has not been touched in many years may no longer be present)
• Editing
  • By storing the version number for each feature, XML output from queries could be used for editing (would also need Omit stracktrace for error message regarding incompatible tile set  gol-tool#57, along with a mechanism to also track version of anonymous nodes)

Typical queries

In addition to current GOQL syntax, would likely need to support these queries:

• by user name/ID
• by date/time range
  • last edited prior to certin date
  • edited within a particular year
• by changeset ID?

Possible ways to store metadata in a GOL

• Full support: Metadata becomes a "first class" data element within a GOL

• Partial support via synthetic tags

• Not stored within GOL itself, but in an auxiliary file

Metadata as "first class" data

Advantages:

• More concise data storage, especially we can simply store a reference to a changeset for each feature (rather than storing changeset ID, timestamp and user name/ID individually)

Drawbacks:

• Requires changes to GOL file-format
• Requires separate query logic

Notes:

• If changesets are atomic, we would only need to track the changeset of a feature
• ChangeSet could then be a separate data type within a GOL
• version number is independent of changeset and would need to be tracked as a separate property

Generate synthetic tags based on metadata

We could turn metadata into tags when a GOL is built.

Advantages:

• No need to modify the GOL file-format
• Easier implementation

Drawbacks:

• Increased file size: Storing metadata as tags is significantly more verbose than using dedicated data structures. It also reduces the opportunity to deduplicate tag-tables as the addition of metadata would make tag-tables more unique.

Related: Proposed Tag Transformations (clarisma/geodesk-gol#14)

Changes to Query Engine

• The GeoDesk Query Engine currently recognizes only two types of data: text and numbers. To allow meaningful queries of timestamp ranges, need to add support for time/date data type.

Open issues

• Are changesets atomic?
• Can a changeset have more than one timestamp?