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. I speak from experience here - I spent about half an hour to understand OSM's data model, but an entire weeks trying to get an algorithm for checking that the inner hulls of my polygons are indeed inside the outer hull. Less complex mandatory stuff = lower entry barrier = more hackers = more cool stuff done with OSM data. About self-intersecting polyg^H^H^H^H^Hways: even if they are allowed to sit in the database, you can check for them a posteriori - that's what JOSM's validator plugin does. 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. Cheers, -- ---------------------------------- Iván Sánchez Ortega <[EMAIL PROTECTED]> MSN:[EMAIL PROTECTED] Jabber:[EMAIL PROTECTED] ; [EMAIL PROTECTED]
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk