Don't understand me wrong. I like OSM's data model how it is. I have studied the OpenGIS features and it makes sense to build a system on top of OpenGIS if you are interested to index the geometries of OSM objects. All a question of data representation. So in the end it would be great, if all multipolygons would fit to the new standard ( http://wiki.openstreetmap.org/wiki/Multipolygon#Advanced_multipolygons ) where MultiPolygons are supported. Then it is much easier to transform OSM multipolygons into OpenGIS MultiPolygons. That's it. I just want that it is easier for developers to built on top of OSM. It's not about OSM supporting official standards. But the standards built inside OSM should be consistent.
The first algorithm I implemented cared about the order of the ways as LineStrings, which make up the rings of the polygon. This will just work properly for recently created objects. For older ones I have to create the rings by combining the ways in the right order. This algorithm is not as performant because I have to find the order for myself or even have to find out which inners belong to which outer. Conclusion: Make a robot change all multipolygon relations to fit into the new model - so the software built on top of OSM (starting with the Map renderers) doesn't need to care any more of different representations. Andi Frederik Ramm schrieb: > Hi, > > Wolfgang Schreiter wrote: > >> I'm also interested in this topic from a quality assurance point of view >> (identification of impossible/invalid overlaps). We could exchange our ideas >> and experiences here. However, I'm using Postgres/POstGIS, which has a >> richer set of geometry functions and is also the database of choice for osm. >> > > To be clear, OSM only switched to Postgres a few months ago and had been > running Mysql for quite a long time before. Also, OSM really uses > Postgres and not PostGIS, i.e. does not make use of any geometry extensions. > > >> Have you already >> taken a look at the OGC spec (http://www.opengeospatial.org/standards/sfa)? >> IMHO this will be the first standard that osm will find impossible to >> ignore, provided is takes it self seriously. >> > > Care to explain why exactly you think SFA is in any way relevant to OSM? > It describes geometric objects and their relationships and functions to > be called on them - but you don't seriously suggest that OSM should > implement an API supporting geometric operations, do you? > > The SFA spec even contains a description of how to model text attributes > including a list of allowable font colours ("blanchedalmod" is ok, > "applegreen" sadly isn't). Surely something we cannot ignore if we want > to take ourselves seriously! > > On a more serious note, SFA - much like all the traditional GIS stuff > I've seen, Shapefiels and PostGIS being other examples - defines curves > and surfaces as first-level standalone data types, next to points. In > OSM, however, curves and surfaces are one level down from points - they > use points as their building blocks. This is required to retain proper > inter-object topology (which I do not see SFA speak of - topology for > them only comes into play talking about the shape of an individual > object). This means that even if OSM were to adopt SFA in one way or > another, representing OSM information in SFA form would mean a data > loss, and thus SFA access would be restricted to read-only. > > Remind me again why our seriousity would depend on working with a > standard that cannot even model the richness of our data? > > Bye > Frederik > > > _______________________________________________ > dev mailing list > dev@openstreetmap.org > http://lists.openstreetmap.org/listinfo/dev > > > _______________________________________________ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
