Page MenuHomePhabricator

Geoline/Geoshape queries don't return geojson for QID
Closed, DuplicatePublicBUG REPORT

Description

Steps to replicate the issue (include links if applicable):

  • Request a geoline or geoshape for Q1789012

https://maps.wikimedia.org/geoline?getgeojson=1&ids=Q1789012
https://maps.wikimedia.org/geoshape?getgeojson=1&ids=Q1789012

What happens?:
No features get returned:
{"type":"FeatureCollection","features":[]}

What should have happened instead?:
Overpass returns 1 way for this QID:
https://overpass-turbo.eu/s/1ksP
The geoline or geoshape services should return this way.

Software version (skip for WMF-hosted wikis like Wikipedia):

Other information (browser name/version, screenshots, etc.):
Due to this bug, the first map on https://de.wikipedia.org/w/index.php?title=Benutzer:JeLuF/Sandbox&oldid=224752889 can't be rendered. The two maps should show the same image (once via QID, once via GeoJson exported from overpass)

Event Timeline

The object on OSM is not a relation but a way: https://www.openstreetmap.org/way/275631579. As far as I know these are not supported everywhere for a reason: The id of a way can change any time. The only half-stable identifiers that exist on OSM are relations.

@thiemowmde - does this mean that the ID that I have to provide is an OSM relation ID, not a wikidata QID? That's not what I understood so far.

Oh, and despite all this it seems to work now - at least for geoshapes. The geoshape link returns the JSON of the object, https://maps.wikimedia.org/geoshape?getgeojson=1&ids=Q1789012
Why is this only working for the geoshape now, not for the geoline?

Linking between Wikidata and OSM happens both ways: It's possibly to annotate relations (as well as other things, e.g. ways) on OSM with Wikidata ids. And it's possible to add an OSM property to the item on Wikidata. The later was missing. I just added it to https://www.wikidata.org/wiki/Q1789012. But this was probably not what fixed the issue. What we have here is more likely the same issue as described in T312913.

I wasn't aware that the OSM relationship attribute in Wikidata is being used for Kartographer. The howtos (at least the parts I read) only mention the wikidata tag in OSM. Is it recommended to link in both ways, especially considering the instability of way ids? I'm reluctant to add relations to simple 8-point lines in OSM just to get a stable id.

... the OSM relationship attribute in Wikidata is being used for Kartographer

It isn't and it's easy to find examples where geoshape/geoline object can be retrieved without Wikidata property, e.g. see item Q3743006 and its geoshape (from way/26900845). As far as I can recall, Wikidata ids were perceived to be more stable than OSM ids, for both ways and relations, and this is why geoshape/geoline queries don't rely on OSM ids.

Until last year it was possible to query individual ways via geoline (still is via geoshape if way is a closed way, i.e. a polygon). See details about this regression in T288400.

OK, understood.

Back to the original topic: Querying the geoshape works now most of the time (Behaviour is currently as described in T312913 - sometimes it works, sometimes an empty result is shown, sometimes 404). Trying to access the geoline however always returns an empty result set.

Is there any reason why a circle in OSM can't be retrieved as a line, but only as shape?

Is there any reason why a circle in OSM can't be retrieved as a line, but only as shape?

As mentioned, T288400 has the hints. This behaviour is affected by patches referenced in this other task. Since last year geoline objects are queried from new database table which includes objects that are built from only relations. Geoshape objects are queried from different database table(s).

There's also T311203 about this geoline issue. I suppose this task could be merged into either of these other open tasks.

In OSM, it usually doesn't make a difference whether I have a tag on a way or a relation, so this behaviour of the geoline API came as a surprise. I think T311203 perfectly covers this part of this bug report.
And I think the other part of this bug report is covered by T312913, so this bug report can be either closed or merged (I've been away for too long, don't know what's the prefered way to handle this).