[OSM-dev] Call for A Proper Area Datatype for OSM

Stefan Keller sfkeller at gmail.com
Sun Feb 10 13:43:45 GMT 2013


Hi Roland

2013/2/10 Roland Olbricht <roland.olbricht at gmx.de>:
> ...
> What makes me hesitate about GeoJSON is essentially that there is no clear
> rule whether an elements becomes a linestring or a polygon. Solving this will
> require both a test for validness (e.g. self intersections, but also some
> other corner cases. Most are listed on
> http://wiki.openstreetmap.org/wiki/Multipolygon#Valid_Multipolygon_conditions
> ) as well as a semantic interpretation of tags.
>
> The most likely mid-term solution is to convert ways always to linestrings,
> but the area type to polygons. This has the advantage that both the code to
> validate polygons and the choice of tags is done by code that does this anyway
> for area creation.
>
> I will code this proper together with a area output implementation conforming
> to Jochen's outline
> http://blog.jochentopf.com/2012-11-26-an-area-datatype-for-osm.html
> so it will take some time until it gets available. I expect it is complete
> some weeks before the FOSSGIS conference, together with a couple of other
> larger changes.

I understand and I know very well about the current unsatisfying
situation in OSM.
When we implemented OSM-in-a-box prototype this part of code took most
of the time fiddling around about if a way was meant as linstring or
polygon.
And I'm convinced that an area type on its own would make live easier
not only for coders but also for mappers who will get more clear rules
about what is an area.

This is why I am proposing an area/polygon type in OSM since years.
And I'm fully supporting Jochen's proposal.
(Note: What OSM calls a Multipolygon is in fact simply a polygon
(containing zero to many inner boundaries) in OGC/ISO/Geoscience. This
would'nt be a problem unless because of OGC/ISO/Geoscience defines
Multpolygon as a SET OF (ogc-)polygons).

To be more specific regarding the corner cases, Martin mentioned two
of them: "E.g. one can interpret an administrative boundary as a
border line [LineString] or the containing area [Polygon]. It gets
even more non-trivial for some of the more abstract relation types
(turn restrictions, enforcements, etc.)." To me the geometry type of
such admin. boundaries is always a polygon. This is not an
interpretation issue about how to model and store it, but rather a
question of handling in some applications (e.g. after clipping).
Regarding turn restrictions: I suppose he refers to the fact that they
are encoded with linestrings. But here we ware discussing basic
geometry types, not higher level semantics.

Yours, Stefan


2013/2/10 Roland Olbricht <roland.olbricht at gmx.de>:
> Hello Stefan,
>
>> That's what I conclude from [1] i.e. <osm-script output="json">  ...
>> </osm-script>
>
> The format option "JSON" meets the format described here:
> http://wiki.openstreetmap.org/wiki/Xappy.js
>
> This has exactly the same semantics like OSM XML and only different syntax.
> However, JSON makes some JavaScript applications a lot easier than XML, so I
> followed the suggestion to add it.
>
> What makes me hesitate about GeoJSON is essentially that there is no clear
> rule whether an elements becomes a linestring or a polygon. Solving this will
> require both a test for validness (e.g. self intersections, but also some
> other corner cases. Most are listed on
> http://wiki.openstreetmap.org/wiki/Multipolygon#Valid_Multipolygon_conditions
> ) as well as a semantic interpretation of tags.
>
> The most likely mid-term solution is to convert ways always to linestrings,
> but the area type to polygons. This has the advantage that both the code to
> validate polygons and the choice of tags is done by code that does this anyway
> for area creation.
>
> I will code this proper together with a area output implementation conforming
> to Jochen's outline
> http://blog.jochentopf.com/2012-11-26-an-area-datatype-for-osm.html
> so it will take some time until it gets available. I expect it is complete
> some weeks before the FOSSGIS conference, together with a couple of other
> larger changes.
>
> Cheers,
>
> Roland
>
>
> _______________________________________________
> dev mailing list
> dev at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/dev



More information about the dev mailing list