Frederik Ramm wrote: > Stefan Keller wrote: >> Right. In fact - it's currently a programmers nightmare: It took us in OSM-in-a-box several months of development. >> I already argued earlier for an own geometry type. I proposed (and still do) to choose the "Simple Features" geometry schema from OGC. > > This roughly translates to > > http://wiki.openstreetmap.org/wiki/The_Future_of_Areas/Areas_on_Nodes > > and would have the disadvantages listed on that page (e.g. no re-using of edges; difficulties in handling very large polygons).
I do not know if there is anything reusable, but we are using a mixed solution in one production system. The system is handling land parcels and natively polygon geometries are stored as a set of linestrings (elements), mainly because it is not enough to give all the attributes for a polygon but the lines must carry some own attributes as well. Linestrings are identified with entity-ID. Polygons are formed from the linestrings through a middle table. Polygon table contains polygon-IDs and the attributes which belong for the polygon features. The middle table is taking care of handling the many-to-many relationships by connecting polygon-IDs with entity-IDs. In our case we are building a network of polygons belonging to a same layer and therefore the many-to-many relation is restricted so that a polygon can consist of however many linestrings but one linestring can belong only to one or two polygons. In addition to these native relation based polygons we have them also as true polygon features. Polygons are created automatically from the linestrings by a database operation. Polygons are automatically updated if the lines are edited and topology checks are preventing the operation if edits would lead to a non-valid polygon topology. As a result we have parcels in the database both as linestring collections and true polygons. In vast majority of use cases we are utilising only polygon geometries. Sometimes we include also the lines as a separate layer either for visualization or because we need to do some queries by the line attributes and not only by polygon attributes. What might be reusable in OSM is the idea of building the polygon versions of area objects as early as possible and serve them for the end users from the OSM infrastructure. It would not be necessary to have true polygons in the main database but there could be some data warehouse service or something in the middle. After having ready made polygons available there would be no need to implement the complicated polygon handling into every single client. Internally OSM could continue to handle the polygons in whatever way but only OSM data editors should be aware of that. This link offers entertaining reading about handling OSM polygons on the client side http://www.qgis.org/wiki/Using_OpenStreetMap_data#Create_polygons_where_relevant It should not really be so complicated. It should rather be something we can do now by ordering a thousand ready interpreted OSM polygons from a WFS service http://188.64.1.61/cgi-bin/tinyows?service=wfs&version=1.1.0&request=getfeature&typename=osm_polygon&maxfeatures=1000 -Jukka Rahkonen- _______________________________________________ dev mailing list [email protected] http://lists.openstreetmap.org/listinfo/dev
