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 [email protected] http://lists.openstreetmap.org/listinfo/dev
