You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We offer process_node and process_untagged_node functions because calling into lua for every untagged node is expensive. This works well, but some work with two stage processing revealed a weakness.
I want to do second stage processing on all nodes that are members of relations that meet some criteria. I can easily identify them with select_relation_members, the problem is I don't know if they're tagged.
According to the docs I need to do something like this in bothprocess_node and process_untagged_node
ifosm2pgsql.stage==1thenreturnendif (somelogic) thensavedgeom[object.id] =object:as_point()
end
and then access savedgeom during stage 2 relation processing.
This will run fine for stage two processing of tagged and untagged nodes because there aren't that many flagged by select_relation_members. It also work okay for stage one processing of tagged nodes because it's not doing much more work than normal. The problem is stage one processing of untagged nodes.
By simply defining the function and having an if statement for every untagged node it adds work to be done for each untagged node. It isn't much work, but because there are so many untagged nodes in stage one it adds a good chunk of time.
I can't think of a good way to handle this. My specific case is also addressed by #2406, but in general tagging nodes for stage two processing is going to require doing some stage one work on every untagged node.
Two-stage processing was developed to add data from the relation to the member objects, not the other way around. Usually the member has some tags in that case. Your use case is better solved by having some kind of mechanism to access member objects directly from the relation. We don't have such a mechanism yet, because it is not quite clear how that should look and how to implement this efficiently, but I'd look for a solution in that direction. Two-stage processing creates a lot of overhead and is difficult to understand and use anway, so it is probably better not to use it for more and more use cases.
I agree this case would be much easier if I could get the member objects geometry while in the lua callback for the relation.
I think this is still a wider problem with the API for stage 2 processing. Most uses of stage two processing I've seen run completely different logic in stage 1 and 2, e.g. functions starting with if osm2pgsql.stage == 1 then return end.
Activity
joto commentedon Jul 24, 2026
Two-stage processing was developed to add data from the relation to the member objects, not the other way around. Usually the member has some tags in that case. Your use case is better solved by having some kind of mechanism to access member objects directly from the relation. We don't have such a mechanism yet, because it is not quite clear how that should look and how to implement this efficiently, but I'd look for a solution in that direction. Two-stage processing creates a lot of overhead and is difficult to understand and use anway, so it is probably better not to use it for more and more use cases.
pnorman commentedon Jul 24, 2026
I agree this case would be much easier if I could get the member objects geometry while in the lua callback for the relation.
I think this is still a wider problem with the API for stage 2 processing. Most uses of stage two processing I've seen run completely different logic in stage 1 and 2, e.g. functions starting with
if osm2pgsql.stage == 1 then return end.