Hi Roland 2013/2/10 Roland Olbricht <roland.olbri...@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.olbri...@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@openstreetmap.org > http://lists.openstreetmap.org/listinfo/dev _______________________________________________ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
