Nested relations don't include their member's geometry when using `out geom;`

[indyteo]

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

[mmd-osm]

You should try “recurse down relations” first: https://wiki.openstreetmap.org/wiki/Overpass_API/Overpass_QL#Recurse_down_relations_(%3E%3E)

It’s designed exactly for this use case. You may need some post processing, though, which should not be a bigger issue.

Nested relation members are incompatible with osm xml format, and probably not a good idea from an interoperability point of view.

[indyteo]

I know I probably can build a query that would prepend the nested relations to the results

But then I can't handle each element's geometry individually, in a stream. I'd need a buffer to keep previous relations in memory just to build the geometry of a single relation that may or may not exist later in the results...

As far as I can tell, having <nd> children inside <member type="way"> isn't OSM XML format either. Still, this is what Overpass produces with out geom;. But it is "compatible" since that's just extra attributes or extra children. My proposal is no different, so I don't see why it would be more "incompatible" that that 🤔