[gdal-dev] 'Polygons as multipolygons' option for OSM driver

[Even Rouault]

Selon Jukka Rahkonen <jukka.rahkonen at mmmtike.fi>:

> In OSM data same sort of polygon features are typically modelled either as
> closed rings or as multipolygon relations if they happen to have holes or if
> the
> length of the outer ring exceeds the limit of 2000 nodes.
>
> For making rendering more simple the OGR driver might have an option for
> skipping the polygon layer.

This is a topic that I've had in mind indeed. The problem is not just ease of
use on the generated result, but also a problem of "correctness", more exactly
of duplicates.

For example, let's imagine a forest with a clearing. You'll have 2 closed ways,
one to describe the outer ring of the forest, the other one for the clearing.
And a relation that binds the 2 ways. If the outer ring of the forest has tags,
and the clearing not, currently, the outer ring will be advertized in the
'polygons' layer, and the outer ring combined with the inner ring in the
'multipolygons' layer. So there is a duplicate, and the reported polygon in the
polygons layer has not the hole, which is not wanted for correct rendering.

(As far as the clearing itself, if it has tags, then it will be reported as
another feature, otherwise not : but this doesn't change from the current
situation)

> In that case features which are found from the
> list
> 'closed_ways_are_polygons' in osmconf.ini would take attributes from the
> [multipolygons] section instead of [polygons].

To be more exact, closed ways are identified as areas if they have a area=yes
tag, or if they have a tag which is listed in closed_ways_are_polygons

> Results would be written into
> the
> multipolygons table and geometry type of these features would be
> multipolygon.
>
> Place of the control could be just below the 'closed_ways_are_polygons'
> control.
> It might have an understandable name like 'write_polygons_as_multipolygons'
> and
> it could take values yes/no. As a comment there might be something like
>
> # Uncomment to write also simple polygons into 'multipolygons' table
> # If selected the 'polygons' table will not be created
> # and all the polygons will take their attributes from the [multipolygons]
> # section below
>
> Does this feel reasonable?

I agree with the idea, with the exception that I think that this should not be
configurable. So I'd just remove the polygons layer, to have only multipolygons.
That would simplify implementation (there are
already (too) many configurable stuff). And I don't think that the polygons
layer is currently very usefull, because it can advertize areas as just having
an outer ring, whereas they should be reported with a hole.

The behaviour of the driver would be that no simple polygons (polygons that are
described as ways) would be reported until the file has been completely
processed.

The algorithm would be something like that :
- store ways in the temporary way DB as currently, but don't advertize ways that
are identified as area for now
- when examining relations, when a polygon described as a way has been
"consumed" as being the outer way of a relation, it will be removed from the
temporary way DB (actually, probably just tagged as being no longer
advertizable, in case it would be needed by another relation afterwards)
- at the end, report all ways that are areas that remain in the temporary way DB
as being advertizable


>
> -Jukka Rahkonen-
>
>
>
>
>
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>