Filter relation members based on "role" and / or "tags"

[mboeringa]

I am sure this must have been discussed last year in the online meeting about the osm2pgsql "flex" development, but for the life of me, I can't remember any answer: is there a way to filter relation members in the Lua flex style based on "role" and / or "tags"?

E.g. let's say I want osm2pgsql to build a type=waterway relation's geometry based on member ways having the role "main_stream" only, so no member ways with other roles should be included in the final geometry representing the relation.

Is this possible? I have looked through the osm2pgsql manual and noticed the section about Processing Callbacks, which lists the object properties, which includes a members field, that refers to the needed information in an array of Lua tables, but it is unclear to me how and if I could use this to filter on a member's role before osm2pgsql constructs the output geometry of the relation.

[joto]

You'll have to decide in the relation callback based on roles which ways you are interested in and then write those ways into the database in the second stage. After that you can, in a postprocessing step, do something with your ways in the database, join them up or whatever.

[mboeringa]

Hi @joto,

I figured something like this would be necessary. It is along the lines of the other work I did on the admin_level boundaries based on Paul's initial implementation in the Lua style, but not quite the same.

I think it would still be valuable to have a basic filtering option for OpenStreetMap relation members as well.

In this particular case, it adds quite a bit of essentially unnecessary post-processing overhead, while all I want is osm2pgsql to select a subset of relation members based on role membership.

In essence, some basic filtering is already applied by osm2pgsql: if I define a table as 'MultiLineString', osm2pgsql already seems to ignore any 'node' and nested 'relation' members, and only uses the 'way' members to construct the waterway relation geometry. It would feel like a natural extension to this, to be able to instruct osm2pgsql to ignore certain members at import stage.

There's also a gotcha with using the stage1/2 strategy: joining the lines back up to a single geometry representing the waterway relation, will require some union or dissolve process, which means that in order to maintain certain tags, these tags must be included in the dissolve process. Including the 'tags' hstore/jsonb column of a relation, may be difficult in this case, and may lead to the loss of access to all tags of the original relation if the 'tags' column cannot be properly included in the dissolve process. It will at least be more difficult to handle this.

Another gotcha is that I cannot do a straight 'length' based SQL selection of e.g. waterway relations. I will indeed need to first join all way members up into a single geometry, before I can again apply a length filtering.