Geometries of route relations should preserve the order of the members

[marchile]

I'm updating OSM data using osmosis and osm2pgsql. The updates work fine. There is only one issue for relation update. If a relation has been modified only inverting its members order, the osm update does not take this into account. So the relation is not updated in the database.

Here below is the command I use for updates:

` osmosis \ --read-replication-interval workingDirectory=$WORKDIR_OSM \ --simplify-change \ --write-xml-change update.osm

osm2pgsql \ --append \ --cache 10000 \ --number-processes 6 \ --hstore \ --multi-geometry \ -r xml \ --database gis \ --slim \ --style $HOME/openstreetmap-carto/openstreetmap-carto.style \ --tag-transform-script $HOME/openstreetmap-carto/openstreetmap-carto.lua \ --flat-nodes $HOME/mapdata/nodes.flat \ update.osm `

[pnorman]

Do we use the order of the relation in forming the geometry from it?

[lonvia]

@pnorman No, we assemble the geometry independently of member order.

@marchile What kind of change do you expect?

[marchile]

@lonvia take this relation for example: https://www.openstreetmap.org/relation/7468547

You can see that the first member of the relationship is placed southeast. The direction of the relationship is therefore south-east -> north-west. As written in the tags (from - to): from Badia Prataglia to Passo della Calla.

My problem is that the relation I have on my copy of OSM has an inverted geometry with respect to the direction of the members. If you open this link, you see that the elevation profile of the route is inverted with respect to the points of departure and arrival: http://simap.j.webmapp.it/#/layer/Toscana_Emilia_Romagna/7468547

On the Waymarked trail all relation directions are correct. Take the same relation: https://hiking.waymarkedtrails.org/#route?id=7468547&map=13!43.8253!11.8106

If you see the elevation profile you climb from Badia Prataglia to Passo della Calla.

[lonvia]

That indeed does not work. As I said, osm2pgsql does not take any membership order into account. It just assembles the geometries of the members to longest possible lines. The order is determined by internals of the algorithm.

We don't have any immediate plans to add such a feature but we are discussing options to add more configurability in that regard with the new Lua API (#901). I've modified the title of the ticket and leave it open as something to look at for the next major version.

[joto]

The master branch now provides a way of doing this with the flex output. You can get the "raw" multilinestring geometry from a relation with object:as_multilinestring(). The geometry will have the linestrings for each member way in it without any merging going on.

[joto]

As mentioned above I believe there is now a way to get at this data. Closing here.