[OSM-dev] [OSM-talk] Polygons in OSM don't necessarily comply to simple feature specification

Christopher Schmidt crschmidt at metacarta.com
Wed Apr 16 23:30:07 BST 2008


On Thu, Apr 17, 2008 at 12:19:19AM +0200, Iván Sánchez Ortega wrote:
> El Miércoles, 16 de Abril de 2008, Christopher Schmidt escribió:
> > On Wed, Apr 16, 2008 at 11:28:32PM +0200, Martijn van Exel wrote:
> > > yesterday a colleague approached me asking why OSM data doesn't comply to 
> > > the Simple Feature specification[...]
> 
> > > Is this something that is being considered? I guess it would be easy
> > > to check for self-intersection upon adding / changing a polygon.
> >
> > "Easy"? I don't think that this is true... determining self-intersection
> > is hard.
> 
> IMHO, checking for self-intersection is as easy as the Simple Features 
> Specification is simple ;-)
> 
> 
> Now, really, OSM data doesn't comply with OGC's Simple Features spec because 
> it doesn't need to in order to work. That's it.
> 
> Even more - if OSM's API would support SFs, the number of geometries would 
> raise from 3 (nodes, ways, relations) to 6, increasing the complexity of 
> *any* tool that wants to work with the API.

7, really, since Simple Features doesn't describe relations, and OSM
would still need them.

> About importing into MS SQL server: Has your colleague browsed the subversion 
> repository? Namely, /applications/utils/export/ - I guess that osm2pgsql 
> could be hacked to work against MS SQL instead of Postgres. Or import into 
> postgres, dump the data into WTK, import into MS SQL.

Probably not. PostGIS doesn't prevent self-intersecting polygons, so
he would probably  have the same problem taking the data from PostGIS ->
SQL server.

Regards,
-- 
Christopher Schmidt
MetaCarta




More information about the dev mailing list