GOQL query by ID

[clarisma]

Querying by ID is coming to GeoDesk for Python, but it would also be useful to support this in the GOL Tool via GOQL queries.

We would need to decide on a query syntax:

1. n#1234 would be the most intuitive from (used by CSS), however it leads to ambiguity as w only selects lineal ways, and a may return two features, since a way and a relation can have identical IDs

2. Alternatively, w and r if coupled with an ID could be interpreted as including areas -- but this would be less performant in the case where user intends to constrain the query (useful if ID indexing is not used)

3. We could introduce W (all ways, including areas) and R (all relations, including areas) -- this is less intuitive if we intend to mimic CSS, which treats selectors as case-insensitive (i.e. r and R are treated as the same; also w and W may be hard to differentiate in certain fonts)

4. Pseudo-classes (another CSS concept): :node, :way and :relation (More verbose and less intuitive, but would also enable queries that select only area relations: a:relation)

5. An alternative form that does not follow CSS syntax: w1234, which would disallow tag clauses and always include areas (a1234 would be rejected)

6. ID in parentheses (Overpass syntax): w(1234) -- could be interpreted the same as # 5

7. Type and ID as pseudo-tags: w[@id=1234], a[@type=relation][@id=1234] (less intuitive)

8. Pseudo-tags, but without the @ sign: w[id=1234], a[osm_type=relation][id=1234] (assumes id is never used as a key; uses osm_type -- same as GeoDesk for Python -- because type is a widely used tag)

We could support multiple forms, but this increases code and documentation complexity.

[durkie]

another use case (that at least I personally have) is querying lists of IDs as well, like way(id: 9179706, 9171393); in overpass turbo.

would query by ID be backed by an index?