-
Hi @joto, We had the opportunity to talk about some of the new functionality and developments regarding osm2pgsql at SOTM 2022 (really enjoyed the conference!), and my specific question whether it was now possible to select specific role members of a relation, and use only those for creating a geometry in flex output. The specific use case being, as explained then and before, the ability to select only those members with the role 'main_stream' of a 'waterway' relation. You suggested I should look at the new options to create a geometry collection, and then go over the members of the collection to sort things out in Lua. However, reading quite extensively through the updated osm2pgsql manual, it is still unclear how this would help my use case, as the geometry collection only contains the actual geometries, but no information about e.g. the roles, and there appears no clear way to store or access this vital information. You already suggested there was not yet a straightforward way to do this. What we actually appear to need is some kind of filter statement, most likely as an input parameter to the
function, so that it becomes possible to filter out certain roles, although this would also require the ability to specify relation type specific filter statements, e.g. as a Lua table, as a single filter statement should only be applied to a single specific relation type, as with the 'main_stream' role for the 'waterway' relation type. Jochen, what are your thoughts on this? And if you still see an option to do this with the current v1.7.0 version of osm2pgsql, could you perhaps give some more clues as to how, or include a working example in the repository's 'flex-config' example styles folder? Actually, interestingly, I noticed the old pgsql output option, actually appears to have a function that gives access to some of these properties of a relation, like the roles:
Don't know how this fits in the bigger picture of the new flex output though, maybe you have something sensible to say about that, although it is clear from the documentation this function only concerns tags, not geometry processing. |
Beta Was this translation helpful? Give feedback.
Replies: 3 comments 3 replies
-
In https://osm2pgsql.org/doc/manual.html#processing-callbacks you can see that there is a |
Beta Was this translation helpful? Give feedback.
-
I am afraid I still need a bit more help. I have gotten this far with the specific piece of code that should handle the selection of specific role members, or exclusion of any others. My problem is that I do not understand if, and how, it is possible to manipulate the 'geom' variable, the 'geometrycollection', to exclude certain members, and then be able insert the entire collection (or even preferably a multilinestring') of the correct ways of role 'main_stream', into a single record in the actual database. Yes, it is possible and I do understand how to insert individual geometry records / selected ways each in their own record, as there is an example of that using the 'insert' function in the manual. But since I seem to be unable to remove objects from the 'geometrycollection', or create e.g. a new empty 'multilinestring' Lua geometry object and add each 'way' object I want to keep to it one-by-one, I do not see how to create and fill a single record with the entire "cleaned up" waterway relation only consisting of members of role 'main_stream'. Of course, I could potentially insert the individual records and merge the selected ways in post-processing in PostGIS, but I was just wondering if this is possible at the osm2pgsql stage as well.
|
Beta Was this translation helpful? Give feedback.
-
Thanks for all the help, this now succeeded. Left the new enhanced display of OSM waterway relations based on the "main_stream" members only using v1.7.0, right the previous display with the clutter of "side_stream" members in the delta of the Mackenzie River in Canada with osm2pgsql <= v1.6.0. |
Beta Was this translation helpful? Give feedback.
In https://osm2pgsql.org/doc/manual.html#processing-callbacks you can see that there is a
members
array you can access from the parameter of the processing callback which contains all the members with their roles. The GeometryCollection we spoke about contains one geometry for each node and way member, so you can iterate over both theobject.members
array as well as the result ofobject:as_geometrycollection()
at the same time, ignore the members of type relation and you have a one-to-one correspondence between roles and geometry.