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
For osm2pgsql we plan to switch from geos to libosmium for creating polygons. libosmium's area assembler is doing a good job but is actually doing too much for us as it is also evaluating tags. That might interfere with osm2pgsql's own tag evaluation. We actually need a function that just assembles areas from ways and relations if anyhow possible.
To solve that, I've added two functions to the area assembler that achieve exactly that:
That's working okay and I'd like to see something like this go into libosmium master. However, this particular implementation is specifically geared towards our use case. A different way to go about that, is to make a few functions public, so that the area assembler can be used with arbitrary input data. Given the code above, we'd need only three functions to be publicly accessible:
extract segments from way
create rings
add rings to area
I can provide PRs for both solutions if that helps. Any preferences?
For reference, the current state of the geometry assembly rewrite can be found here.
The text was updated successfully, but these errors were encountered:
For osm2pgsql we plan to switch from geos to libosmium for creating polygons. libosmium's area assembler is doing a good job but is actually doing too much for us as it is also evaluating tags. That might interfere with osm2pgsql's own tag evaluation. We actually need a function that just assembles areas from ways and relations if anyhow possible.
To solve that, I've added two functions to the area assembler that achieve exactly that:
That's working okay and I'd like to see something like this go into libosmium master. However, this particular implementation is specifically geared towards our use case. A different way to go about that, is to make a few functions public, so that the area assembler can be used with arbitrary input data. Given the code above, we'd need only three functions to be publicly accessible:
I can provide PRs for both solutions if that helps. Any preferences?
For reference, the current state of the geometry assembly rewrite can be found here.
The text was updated successfully, but these errors were encountered: