I also notice that a week or a bit more ago OSM overlay objects started to disappear and appear randomly, similar to T268927 in last November. Is this another side-effect of T269582? Earlier, in first half of the year, these overlay objects displayed more reliably, apart from defective static snapshot of new map getting cached in page preview and correct image appearing an hour or so after saving (an issue that surfaced in the end of last year – T269984).

It seems that a relation is not displayed with geoline service in particular, while if it's a polygon then it is displayed with geoshape service. E.g. Delaware article now displays blank boundary map as it's set to use geoline service (type=line in given wrapper template), but the relation is displayed (in page preview at least) if it's switched to use geoshape service (type=shape).

If it's also necessary to configure particular types of relations, like route relations, to work properly with imposm, then once at it, maybe in similar manner you can also configure waterway relations that previously weren't available with osm2pgsql (T156433)?

In T288400#7281005, @Pikne wrote:

If it's also necessary to configure particular types of relations, like route relations, to work properly with imposm, then once at it, maybe in similar manner you can also configure waterway relations that previously weren't available with osm2pgsql (T156433)?

Yes, AFAICT we could make any OSM relation available with the strategy I'm looking for, which is preparing a table that is specific for geoshapes service to query any geometry that contains wikidata tag. I'm experimenting with this approach and will post here the results once I have them.

Change 713827 had a related patch set uploaded (by MSantos; author: MSantos):

[operations/puppet@production] maps: update imposm mapping

https://gerrit.wikimedia.org/r/713827

Change 713827 merged by Hnowlan:

[operations/puppet@production] maps: update imposm mapping

https://gerrit.wikimedia.org/r/713827

Mentioned in SAL (#wikimedia-operations) [2021-08-23T09:55:44Z] <mbsantos> start re-import OSM planet data into maps1009 eqiad master (T288400, T288897)

Change 720985 had a related patch set uploaded (by MSantos; author: MSantos):

[maps/kartotherian/deploy@imposm] geoshapes: update table names

https://gerrit.wikimedia.org/r/720985

Change 720985 merged by jenkins-bot:

[maps/kartotherian/deploy@imposm] geoshapes: update table names

https://gerrit.wikimedia.org/r/720985

Relations now appear again. However, it seems that now the problem is the other way around. Previously individual ways with wikidata tag weren't affected, but now I can't find any that'd be available via geoline service. For instance:

• https://www.openstreetmap.org/way/4853843 > https://maps.wikimedia.org/geoline?getgeojson=1&ids=Q12366992
• https://www.openstreetmap.org/way/262102391 > https://maps.wikimedia.org/geoline?getgeojson=1&ids=Q4471311

I realize this is somewhat unrelated, so maybe there's a better place to ask this, but is there an API for maps.wikimedia.org? I didn't know about this until @Pikne 's last comment

In T288400#7395906, @BMACS1002 wrote:

I realize this is somewhat unrelated, so maybe there's a better place to ask this, but is there an API for maps.wikimedia.org? I didn't know about this until @Pikne 's last comment

We are lacking a bit of an simple introduction to that indeed. I made a start here: https://www.mediawiki.org/wiki/Wikimedia_Maps/API

Not sure I understand exactly what the current status of this issue is, but I just wanted to say that the original problem I reported (https://phabricator.wikimedia.org/T286089) is still there: relations whose members are sub-relations and not directly objects with a geometry are not properly handled by geoshapes.

I suppose geoshapes still need to reach planet_osm_line table as well, or tables need further rearrangement?

In T288400#7396889, @StC wrote:

...the original problem I reported (T286089) is still there: relations whose members are sub-relations and not directly objects with a geometry are not properly handled by geoshapes.

This is old issue. I think superroute relations are rather in scope of T156433.

Well, I'm not the one who decided to join the issue I filed to this one instead of T156433 :-)

The tables geoshapes is querying are defined here: https://gerrit.wikimedia.org/r/plugins/gitiles/maps/kartotherian/deploy/+/refs/heads/imposm/scap/templates/config.yaml.j2#28

In T288400#7496340, @MSantos wrote:

The tables geoshapes is querying are defined here: https://gerrit.wikimedia.org/r/plugins/gitiles/maps/kartotherian/deploy/+/refs/heads/imposm/scap/templates/config.yaml.j2#28

So, can you simply readd planet_osm_line next to new wikidata_relation_members in this config file? Similar to polygons that appear to be queried from both wikidata_relation_polygon and planet_osm_polygon.

Edit: I may be wrong about polygons being queried from two tables. New table wikidata_relation_polygon is of table type polygon which, if I get imposm docs right, includes polygons built both from individual closed ways and from some types of relations. But if imposm doesn't allow the same approach for linestrings, then we should query these from two tables, right?

In Estonian Wikipedia this currently affects about 1200 articles where map is broken due to indivdual OSM way with wikidata tag not being reachable via geoline service.

In T288400#7512679, @Pikne wrote:

In T288400#7496340, @MSantos wrote:

The tables geoshapes is querying are defined here: https://gerrit.wikimedia.org/r/plugins/gitiles/maps/kartotherian/deploy/+/refs/heads/imposm/scap/templates/config.yaml.j2#28

So, can you simply readd planet_osm_line next to new wikidata_relation_members in this config file? Similar to polygons that appear to be queried from both wikidata_relation_polygon and planet_osm_polygon.

Querying from both tables requires a little extra work AFAIC. I'll investigate that.

In T288400#7597231, @MSantos wrote:

Querying from both tables requires a little extra work AFAIC. I'll investigate that.

Have you had a chance to look into it yet?

In OSM current situation leads Wikimeda users to create single-member relations that otherwise wouldn't be necessary. This in turn may lead to conflicts with other OSM users on the basis of tagging for the renderer.

@Pikne I wasn't able to define the proper solution. But I could explore your suggestion and considering the current DB schema, the table union/combination is not feasible unless geoshapes is using ParseCache for its expansions, even then we could still have some query timeouts in the DB level.

The only possibility I can see is to explore the imposm mapping and include more relation types. That still needs some investigation though and we couldn't prioritize it yet.

In T288400#8614899, @MSantos wrote:

The only possibility I can see is to explore the imposm mapping and include more relation types.

The remaining regression here is that individual ways, not part of a relation, are missing via geoline.

Currently a polygon can be retrieved both when it's built from a relation (e.g. relation>geoshape) and individual closed way (e.g. way>geoshape). So if this data is not queried from multiple tables then this means that polygon data from relations and individual ways is included in the same table, right?

Is there any chance that imposm supports the same solution also for linestrings? E.g. if table type linestring would be used together with relation_types: [...] then would the resulting table include both individual ways and ways from listed types of relations?

If the above idea wouldn't work then alternatively could this example be useful:
https://github.com/omniscale/imposm3/blob/master/test/single_table_mapping.json
Could this approach be used to combine the mappings of current planet_osm_line and wikidata_relation_members into a mapping of a single table?