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. 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]. 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?
-Jukka Rahkonen-
_______________________________________________
gdal-dev mailing list
gdal-
http://lists.osgeo.org/mailman/listinfo/gdal-dev
)
Selon Jukka Rahkonen <>:
> 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-
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>
_______________________________________________
gdal-dev mailing list
gdal-
http://lists.osgeo.org/mailman/listinfo/gdal-dev
)
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 <>:
>
> > 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-
> > http://lists.osgeo.org/mailman/listinfo/gdal-dev
> >
>
_______________________________________________
gdal-dev mailing list
gdal-
http://lists.osgeo.org/mailman/listinfo/gdal-dev
)
> 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
I've implemented the above in r24774. It might have an impact of performance
(not benchmarked, and hopefully not too big) and if you turn -progress, it
will seem to be stuck at 100% for longer as before, since there is now the
post processing of closed ways that are not referenced by relations to do.
Best regards,
Even
_______________________________________________
gdal-dev mailing list
gdal-
http://lists.osgeo.org/mailman/listinfo/gdal-dev
)
Even Rouault wrote:
> > 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
>
> I've implemented the above in r24774. It might have an impact of
> performance (not benchmarked, and hopefully not too big) and if you turn -
> progress, it will seem to be stuck at 100% for longer as before, since there is
> now the post processing of closed ways that are not referenced by relations
> to do.
I made a quick test with command
ogr2ogr -f SQLite -dsco spatialite=yes germany.sqlite germany.osm.pbf -gt 20000 -progress --config OGR_SQLITE_SYNCHRONOUS OFF --config OSM_COMPRESS_NODES YES -lco SPATIAL_INDEX=NO
With previous version the conversion took 880 seconds vs. 985 seconds with the new one (r24776) thus it was 12 percent slower in this phase. I consider that it is not bad at all because for most use cases the OSM polygons (closed rings presenting areas) and multipolygons (coming from OSM multipolygon relations) must be combined anyway and it would probably be much slower as a separate process.
The timings above include only the raw conversion into Spatialite. Creating spatial indexes for the tables take so much time that the whole process that gives indexed tables as end result is only 4 percent slower with the new OSM driver version.
-Jukka Rahkonen-
_______________________________________________
gdal-dev mailing list
gdal-
http://lists.osgeo.org/mailman/listinfo/gdal-dev
)
