Nested relations don't include their member's geometry when using out geom; #783
Description
Hi,
I was playing a bit with nested relations and the out geom; statement to explore the resulting geometries. But I found out that nested relations simply don't include anything about their geometry despite having requested the "full geometry" (as documented on the Wiki) using out geom;.
I understand that it may be a little bit tricky to handle that properly, but I think that it should be possible (but maybe not desirable? Then skip to the end of this issue). I know I probably can build a query that would prepend the nested relations to the results, so I would be able to get them, but I feel like this defeats the purpose of the out geom; statement. It would be very handy (and optimized) to be able to get the (truly) full geometry for each element, regardless of whether it is a relation with nested relations or not.
To showcase, here is a request returning a simple relation (some random street in Paris) with a nested relation:
[timeout:25];
relation(id: 11829733);
out geom;
Response
<?xml version="1.0" encoding="UTF-8"?>
<osm version="0.6" generator="Overpass API 0.7.62.11 87bfad18">
<note>The data included in this document is from www.openstreetmap.org. The data is made available under ODbL.</note>
<meta osm_base="2026-03-25T15:58:51Z"/>
<relation id="11829733">
<bounds minlat="48.8520737" minlon="2.3365920" maxlat="48.8521952" maxlon="2.3370228"/>
<member type="relation" ref="19722618" role="street"/>
<member type="way" ref="233729110" role="street">
<nd lat="48.8521265" lon="2.3365920"/>
<nd lat="48.8521316" lon="2.3367273"/>
<nd lat="48.8521402" lon="2.3369556"/>
<nd lat="48.8521406" lon="2.3369720"/>
<nd lat="48.8521410" lon="2.3369886"/>
<nd lat="48.8521419" lon="2.3370228"/>
</member>
<member type="node" ref="806011349" role="house" lat="48.8520737" lon="2.3368368"/>
<member type="node" ref="806011106" role="house" lat="48.8521952" lon="2.3368422"/>
<tag k="name" v="Rue Toustain"/>
<tag k="ref:FR:FANTOIR" v="751069399D"/>
<tag k="type" v="associatedStreet"/>
<tag k="wikidata" v="Q21098231"/>
</relation>
</osm>As you can see, despite having out geom; at the end of the request, the nested relation (ID: 19722618, first member of that resulting relation) is returned without any geometry information.
What I imagine, in XML for example, would be something like this:
Hypothetical example
<?xml version="1.0" encoding="UTF-8"?>
<osm version="0.6" generator="Overpass API 0.7.62.11 87bfad18">
<note>The data included in this document is from www.openstreetmap.org. The data is made available under ODbL.</note>
<meta osm_base="2026-03-25T15:58:51Z"/>
<relation id="11829733">
<bounds minlat="48.8520737" minlon="2.3365920" maxlat="48.8521952" maxlon="2.3370228"/>
<member type="relation" ref="19722618" role="street">
<member type="way" role="outer">
<nd lat="48.8521895" lon="2.3367214"/>
<nd lat="48.8521952" lon="2.3368422"/>
<nd lat="48.8522005" lon="2.3369522"/>
<nd lat="48.8522007" lon="2.3369686"/>
<nd lat="48.8522010" lon="2.3369856"/>
<nd lat="48.8521410" lon="2.3369886"/>
<nd lat="48.8520807" lon="2.3369916"/>
<nd lat="48.8520805" lon="2.3369754"/>
<nd lat="48.8520794" lon="2.3369583"/>
<nd lat="48.8520737" lon="2.3368368"/>
<nd lat="48.8520719" lon="2.3367989"/>
<nd lat="48.8520690" lon="2.3367365"/>
<nd lat="48.8521316" lon="2.3367273"/>
<nd lat="48.8521895" lon="2.3367214"/>
</member>
<member type="way" role="inner">
<nd lat="48.8521685" lon="2.3367324"/>
<nd lat="48.8521718" lon="2.3368225"/>
<nd lat="48.8521523" lon="2.3368242"/>
<nd lat="48.8521490" lon="2.3367341"/>
<nd lat="48.8521685" lon="2.3367324"/>
</member>
<member type="way" role="inner">
<nd lat="48.8521726" lon="2.3368552"/>
<nd lat="48.8521760" lon="2.3369453"/>
<nd lat="48.8521565" lon="2.3369470"/>
<nd lat="48.8521531" lon="2.3368569"/>
<nd lat="48.8521726" lon="2.3368552"/>
</member>
<tag k="type" v="multipolygon"/>
</member>
<member type="way" ref="233729110" role="street">
<nd lat="48.8521265" lon="2.3365920"/>
<nd lat="48.8521316" lon="2.3367273"/>
<nd lat="48.8521402" lon="2.3369556"/>
<nd lat="48.8521406" lon="2.3369720"/>
<nd lat="48.8521410" lon="2.3369886"/>
<nd lat="48.8521419" lon="2.3370228"/>
</member>
<member type="node" ref="806011349" role="house" lat="48.8520737" lon="2.3368368"/>
<member type="node" ref="806011106" role="house" lat="48.8521952" lon="2.3368422"/>
<tag k="name" v="Rue Toustain"/>
<tag k="ref:FR:FANTOIR" v="751069399D"/>
<tag k="type" v="associatedStreet"/>
<tag k="wikidata" v="Q21098231"/>
</relation>
</osm>Notice that submembers would only have the bare minimum to recreate the full geometry, which include only members' type and role (along with their sub-geometry, recursively), and the type tag of the subrelation. Obviously, 2-deep nested relations would behave similarly, and maybe and hard limit should be put to ensure no problem occurs with really big relations.
If it is an issue to have <member>s inside <member>s, maybe submembers could be <mb>, similarly to <node>s being <nd> on ways.
After a quick analysis of the code, it seems that (at least for XML), it would take place near there, with a clause else if (skel.members[i].type == Relation_Entry::RELATION) instead. However to get the actual geometry data to return, it may need additional changes when the relation's geometry is loaded, along with some more methods in the Opaque_Geometry/Partial_Relation_Geometry class to expose such values.
Would it be something you would consider, to have truly full geometries returned, even with complex relations? If so, I can (try to) work on that, at least to see how it turns out. Otherwise, which workaround would you recommend to be 100% sure to be able to rebuilt the whole geometry of every single element returned by a query?
Thanks