For many geometries/entities in a map, the meta-data is attached to the relation grouping rather than to the nodes or ways. E.g. this map depicts a pier structure made up of two ways; however those ways are tag-less so they don't show up when parsed with the Ways Component.
The current parsers could relatively easily pickup these relations, but it is unclear how to handle their metadata outputs given the existing structure. At a minimum, they could work within the existing structure by just assigning all tags from the relation to the ways (in effect duplicating them).
That naïve option strips any relationship between the child-ways/nodes and is complicated by structures such as multipolygons. A more thorough rework would be to reconfigure the tree structure to add another level of depth for the relation. E.g. {query, relation, geometry|metadata} rather than just {query, geometry|metadata}.
For many geometries/entities in a map, the meta-data is attached to the
relationgrouping rather than to thenodesorways. E.g. this map depicts a pier structure made up of twoways; however those ways are tag-less so they don't show up when parsed with the Ways Component.The current parsers could relatively easily pickup these relations, but it is unclear how to handle their metadata outputs given the existing structure. At a minimum, they could work within the existing structure by just assigning all tags from the
relationto theways(in effect duplicating them).That naïve option strips any relationship between the child-ways/nodes and is complicated by structures such as multipolygons. A more thorough rework would be to reconfigure the tree structure to add another level of depth for the relation. E.g.
{query, relation, geometry|metadata}rather than just{query, geometry|metadata}.