Page MenuHomePhabricator

Geoline/geoshape does not work with relations other than multipolygon/route/boundary
Open, LowestPublic

Tokens
"Like" token, awarded by AntiCompositeNumber."Like" token, awarded by Kozuch."Heartbreak" token, awarded by Tagishsimon."Like" token, awarded by Liuxinyu970226."Like" token, awarded by WikedKentaur."Like" token, awarded by Samwilson.
Assigned To
None
Authored By
Pnorman, Jan 26 2017

Description

T155924: Kartographer's maplink/mapframe ExternalData should render super-relations, T154599: Geoline service not retrieving OSM waterway despite the Wikidata ID, and T155923: Kartographer maplink/mapframe ExternalData should render all geolines and/or geoshapes in an OSM relation regardless of continuity or whatever it is (it's not working properly, basically) are all aspects of how to handle relations other than type=multipolygon, type=route, and type=boundary with way members. Rather than trying to figure out exactly which issue to comment on, I'm merging them all in here.

I don't know if the wikidata tagging in OSM in those issues is correct, but the basic issue is creating a geometry from an arbitrary relation. In the issues referenced, they were waterway relations, boundary relations containing relations, and public transport route masters.

multipolgon, route, and boundary relations have well-established ways of creating geometries from them and are handled by osm2pgsql. Some of the relation types above like waterway relations could be handled by osm2pgsql but are not with the default data transformation. Others, like public_transport and relations of relations cannot be handled by osm2pgsql, and may not even have a sensible representation as a single geometry with tags.

This means if we decide we want to handle arbitrary relations, we would need to deploy another database specific for geoline/geoshape and abandon the possibility of returning OSM tags for some objects. We could then build a GeometryCollection for all relations, which could be used to draw something on a map, but not always a good interpretation. For example an area with a hole drawn as a MP when interpreted this way is a closed line inside a closed line.

Event Timeline

Pnorman created this task.Jan 26 2017, 11:26 PM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptJan 26 2017, 11:26 PM
Ayack added a subscriber: Ayack.Mar 31 2017, 3:39 PM
debt triaged this task as Normal priority.Sep 12 2017, 7:13 PM
Pikne added a subscriber: Pikne.May 11 2018, 8:02 AM

WIWOSM seems to show waterways like this (r3582427). In what way is the mechanism behind it different? Could that be of some use here?

Abbe98 added a subscriber: Abbe98.May 19 2018, 12:24 PM
Haros added a subscriber: Haros.May 19 2018, 6:19 PM

This will be addressed in the cleartables-based style work. All relations will be handled, subject to inherent osm2pgsql limitations. boundary and multipolygon relations are turned into polygons, and all others are turned into linestrings

jmac added a subscriber: jmac.May 24 2018, 9:02 PM
Pnorman closed this task as Declined.Jun 26 2018, 4:16 PM

This would require a database schema change, which we wouldn't deploy, so this is declined due to resource constraints.

Pikne added a comment.Jun 27 2018, 5:01 AM

This would require a database schema change, which we wouldn't deploy, so this is declined due to resource constraints.

To be clear, you mean that cleartables mentioned above wouldn't be deployed? If so, then couldn't we still look for some other solution? (I still wonder what solution WIWOSM uses.) Waterway relations with wikidata tag are considerably more common (currently 8692 uses) than other special type relations, so it would be nice to see at least that supported, at least in long-term.

To be clear, you mean that cleartables mentioned above wouldn't be deployed?

Yes, management has decided not to deploy that work.

If so, then couldn't we still look for some other solution?

The default database osm2pgsql database schema does not do anything with relations other than boundary or multipolygon. Because we can't deploy a switch from that for the reason above, we can't add the feature requested here.

Evad37 reopened this task as Open.Aug 28 2018, 4:48 AM
Evad37 lowered the priority of this task from Normal to Lowest.

This still seems like a valid low/lowest priority bug to me, even if it isn't going to be fixed in the near future due to the current management's decision (i.e. it's more of a "not now", rather than "never ever ever", isn't it?)

Evad37 added a comment.EditedAug 28 2018, 4:52 AM

The default database osm2pgsql database schema does not do anything with relations other than boundary or multipolygon.

How are the type=route relations handled then? Is there any chance of doing something similar for just for the geoline service for relations that are only made up of lines (e.g. streets which aren't part of a numbered route)?

Pikne added a comment.Oct 9 2018, 8:15 AM

I find a mail conversation about similar issue in WIWOSM and code (introduced soon after this conversation) that does something with relations that osm2pgsql misses. I've little understanding of this, but can you do something similar here?

mxn added a subscriber: mxn.Nov 10 2018, 9:59 PM

+1 for recognising relation:type=waterway

I have a ton of these ready to deploy. It's a clear, consistent and common use case, and its something that doesn't show well on maps without this kind of highlighting.

This should probably be done for highways, too.

Perhaps this might be one of the task that will be focused on during this year's WM Hackathon, @Vojtech.dostal ?
This feature was also requested on cs.wiki in the past, as I can remember.

@jmac: Anyone is free to add to Wikimedia-Hackathon-2019 whatever they plan to work on themselves; no need to ask anyone else :)

Perhaps this might be one of the task that will be focused on during this year's WM Hackathon, @Vojtech.dostal ?
This feature was also requested on cs.wiki in the past, as I can remember.

That would be excellent! :)

@Pigsonthewing: That's because you replied "alas no". (I'd simply like to avoid adding tasks that nobody plans / has committed to work on.) Feel free to correct me please, if I misunderstood!

Kozuch added a subscriber: Kozuch.Sun, Aug 4, 9:46 AM