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.rahko...@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@lists.osgeo.org > > http://lists.osgeo.org/mailman/listinfo/gdal-dev > > > _______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
