[OSM-dev] Gisify relations

[Frederik Ramm]

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