FileProcessor().with_areas() not working as expected

[cmahnke]

This is a hacked version of a construct from the documentation:

    fab = osmium.geom.WKTFactory()
    filter_geometries: List[BaseGeometry] = []
    for o in osmium.FileProcessor(args.patch).with_areas():
        way = ""
        if o.is_way():
            way = f"Closed? {o.is_closed()}"
        logger.debug(f"{o.type_str()} Area? {o.is_area()} {way} {o}")
        if o.is_way() and not o.is_closed():
            wkt = fab.create_linestring(o.nodes)
        #elif o.is_way() and o.is_closed():
        #    wkt = fab.create_linestring(o.nodes)
        elif o.is_area():
            wkt = fab.create_multipolygon(o)
        else:
            wkt = None # ignore relations
        if wkt:
            filter_geometries.append(wkt)

This is a (cliped) output to illustrate a possible problem:

2025-11-12 15:37:11 - DEBUG - n Area? False  n-26410: location=9.9358697/51.5426796 tags={}
2025-11-12 15:37:11 - DEBUG - w Area? False Closed? True w-9031: nodes=[-25917,-25918,-25919,-25920,-25921,-25922,-2592...] tags={addr:city=Göttingen,addr:country=DE,addr:housen...}
2025-11-12 15:37:11 - DEBUG - w Area? False Closed? True w-9032: nodes=[-25930,-25931,-25932,-25933,-25930] tags={building:levels=18,building:material=concrete,b...}
2025-11-12 15:37:11 - DEBUG - w Area? False Closed? True w-9033: nodes=[-25934,-25935,-25936,-25937,-25938,-25939,-2594...] tags={addr:city=Göttingen,addr:country=DE,addr:housen...}

As you can see in the third line of the log, the way is closed, but it's not an area. What am I missing?
I also can't find a Area() constructor, so I tried to pass the object to fab.create_linestring if the way is is closed (see commented part) but this also fails, regardless if I add .with_locations() to the FileProcessor or not...

Any suggestions?

[cmahnke]

I'm not getting not that much further on this issue. There doesn't seem to be a way to generate a Polygon from a closed way?
On the other hand the cause for the first post might be the case that I have negative IDs, I already found this a issue in GeoPandas where negative IDs a silently discarded, maybe that's a similar problem?

[cmahnke]

There are some solutions. One can work arround the strict typing using GeoJSON - this part of the API does't feel very Pythonic...

gsfab = osmium.geom.GeoJSONFactory()

 if o.is_way() and o.is_closed():
     gjson = json.loads(gsfab.create_linestring(o.nodes))
     if (gjson["coordinates"][0] == gjson["coordinates"][-1]):
         gjson["type"] = "Polygon"
         gjson["coordinates"] = [gjson["coordinates"]]
  
     envelope = {"type": "Feature",
	            "geometry":gjson,
                 "properties": {}}
     geojson_string = json.dumps(envelope)
     wkb = shapely.from_geojson(geojson_string)

This can be used to update the IDs, given that they are consistently negative and the file only contains such changes.

    class IDChanger(osmium.SimpleHandler):
        def __init__(self, writer):
            super(IDChanger, self).__init__()
            self.writer = writer

        def node(self, n):
            new_node = create_mutable_node(n)
            new_node.id = n.id * -1
            logger.debug(f"Changing node ID from {n.id} to {new_node.id}")
            self.writer.add_node(new_node)
            
        def way(self, w):
            new_way = create_mutable_way(w)
            new_way.id = w.id * -1
            new_way.nodes = None
            refs = []
            for r in w.nodes:
                r.ref = r.ref * -1
                refs.append(r)
            new_way.nodes = refs
            logger.debug(f"Changing way ID from {w.id} to {new_way.id}")
            self.writer.add_way(new_way)

        def relation(self, r):
            new_relation = create_mutable_relation(r)
            new_relation.id = r.id * -1
            logger.debug(f"Changing relation ID from {r.id} to {new_relation.id}")
            self.writer.add_relation(new_relation)

In the end is suspect to be a bug: The underlying library should throw if there seems something wrong, silently discarding things is a bad habit...

[lonvia]

Have a look at the documentation on areas: when you request areas with with_areas(), then pyosmium will return relations and ways that can be made into an area. They will be emitted in addition to the normal node, way and relation objects. So you don't need any special handling for closed ways. A closed way (which can be made into a valid area) will appear twice in your output: once as o.is_way() is True and once as o.is_area() is True with o.from_way() is True.

[cmahnke]

Thanks for the reply, I have read how this is supposed to work, but it doesn't (in my case), have a look at the initial post, especially the part where I output if something is a closed way and an area. Or I misunderstood something: When calling with with_areas() then o.is_way() is True and o.is_area() is True should both either always be True or False or is it a valid case that a closed way isn't an area? Maybe it's a understanding / documentation issue then.

[lonvia]

is_way() is a short-cut for checking if you have a Way object, is_area() is checking if you have an Area object. For any given object either can be true but not both at the same time.

There are closed ways that cannot be assembled to an area, mostly when they are self-intersecting. But I don't see how this is relevant for you. If you are interested in ways that can be areas, then ignore all objects except the ones where o.is_area() is True. Forget about o.is_way() and o.is_closed(). It is not relevant for the task of assembling polygons.

[cmahnke]

That's what I meant with misunderstanding (on my side): I learned by now that the OSM data model is in parts badly designed and even hostile (due to being counterintuitive, see aspectumapp/osm2geojson#56: metadata can change the semantics of primitives, WTF?).

Thanks for the explanations, In OSM lingo I was certainly only interested in closed ways. But I needed them as polygons (regardless of the semantics of the OSM data model). That's why I wrote that the API currently doesn't feels very Pythonic, since currently there is a lock in, into these semantics and thats's also the reason for gymnastics above. Sure there might be better solutions, but I wasn't able to work them out, given the fact I had a naive approach to the data and tried to avoid digging into the code ob the underlying library.

Anyways: I have to admit, that my use case might be not that common, you can read about here.:

• https://christianmahnke.de/en/post/patching-osm-data/ (this is a automatic translation)
• Original in German:https://christianmahnke.de/post/patching-osm-data/