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

[Rahkonen Jukka]

Hi,

Your plan is very reasonable. It should give correct results in most cases and I think that total solution is not possible before OSM project is able to develop 'the simplest approach that could possibly generate useful polygons' (adapted from http://wiki.openstreetmap.org/wiki/FAQ#Why_aren.27t_you_using_Open_Geospatial_Consortium_.28OGC.29_schemas_and_software_for_OpenStreetMap.3F

-Jukka-


Even Rouault wrote:
 
> 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
> >
>