[OSM-talk] [OSM-dev] 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 talk
mailing list