Re: [OSM-talk] [OSM-dev] Polygons in OSM don't necessarily comply to simple feature specification
On Wed, Apr 16, 2008 at 2:28 PM, Martijn van Exel [EMAIL PROTECTED] wrote: Hi all, I've been warming up as many of my colleagues to OSM as possible, and sometimes this comes back to me. Being GIS people, they have GIS requirements, and OSM was not devised specifically with GIS requirements in mind. That said, yesterday a colleague approached me asking why OSM data doesn't comply to the Simple Feature specification[1] (allowing easy import in for example SQL Server 2008, which he was actually attempting). The only exceptions apparently being that self-intersecting polygons are allowed in OSM. He found a couple hundred in the Netherlands' OSM data. Is this something that is being considered? I guess it would be easy to check for self-intersection upon adding / changing a polygon. Is there a specific reason why self-intersecting geometries would be explicitly allowed? Take care, [1] http://en.wikipedia.org/wiki/Simple_Features -- martijn van exel -+- [EMAIL PROTECTED] -+- http://www.schaaltreinen.nl/ I doubt they were explicitly allowed. Heck, there isn't even a polygon type (although I hear there used to be...) More likely they're just not explicitly denied. And without an explicit polygon type, they can't be filtered/denied without determining if it's a polygon or not, which would involve evaluating the way tags against some (changeable) rules which govern whether the particular way should be treated as a polygon. Karl ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] [OSM-dev] Polygons in OSM don't necessarily comply to simple feature specification
On Wed, Apr 16, 2008 at 11:28:32PM +0200, Martijn van Exel wrote: Hi all, The only exceptions apparently being that self-intersecting polygons are allowed in OSM. He found a couple hundred in the Netherlands' OSM data. 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. Also, note that many many 'GIS' implementations also allow self-intersecting polygons. Shapefiles, GML, etc. etc. and the tools around them all 'allow' this insofar as there is typically no technological limitation preventing it. It seems likely that the netherlands 'self intersecting polygons' are simply the result of poorly curated coastline imports or something similar: in general, self-intersecting polygons aren't useful for anything I can think of in OSM, but preventing it is hard, and not really within the spirit of *most* simple geographic data tools. Regards, -- Christopher Schmidt MetaCarta ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] [OSM-dev] Polygons in OSM don't necessarily comply to simple feature specification
Hi, yesterday a colleague approached me asking why OSM data doesn't comply to the Simple Feature specification[1] I guess the honest answer is very likely that most people invovled in designing anything at OSM have no prior GIS experience. Most of us are amateurs. We design stuff that we think works, and if people say we don't follow standards then we say that's by design, but mostly it is just ignorance. And ignorance is bliss. I had to read a couple OGC(*) standards in the past. It begins with selecting wether you want the 0.7 or the 1.0 or the 1.1.0 version, the Implementation Specification or the Implementation Specfication Corrigendum or the Implementation Specification Havum Coolum Wordum document. Then you are invited to read a page of small print that you have to accept before they even tell you what the standard is they would like you to implement. After that you get a document which more or less reads like a Chomsky book on transformation grammar, only where Chomsky used short words and letters to identify elements, they usually have sentences. So make extra sure you don't confuse the Server Answer Receipt Message Confirmation with the Server Answer Recepit Message Confirmation Request because both are, cleary, very different things. I'm overdoing it a bit here, but only a bit. The most difficult part for me is distingushing between those parts of these documents which are really the bread-and-butter stuff that any software worth its salt must support, and which parts are just fancy cloud cuckoo stuff that nobody even attempted to support. If the OGC material was more accessible - I'm not asking much, I'd just like Internet RfC style with a few examples every now and then or something like that - then I'm sure more Open Source developers would actually take the time to try and implement stuff conforming to their specs. But the way these specs currently worded and delivered gives the impression that they're not very interested - sometimes I think it is enough for them if their paying members understand what is meant (because their paying members have been involved in the mailing lists and working groups and don't need to read the actual paper that comes out at the end). So much for OGC stuff in general. About Simple Features specifically, I guess there simply was nobody who wanted to do the extra work. I remember Artem complaining about self-intersecting stuff once and I think the offending items are sorted out somewhere in osm2pgsql, are they not? Bye Frederik (*) The number is not high enough for my findings to be statistically significant. -- Frederik Ramm ## eMail [EMAIL PROTECTED] ## N49°00'09 E008°23'33 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] [OSM-dev] Polygons in OSM don't necessarily comply to simple feature specification
Hi, The only exceptions apparently being that self-intersecting polygons are allowed in OSM. The wiki page you cited says In general, a 2D geometry is simple if it contains no self-intersection. - what do they mean by 2D geometry? Specifically, would a self-intersecting *line* be allowed? (I like to think of points as 0D, lines as 1D, and areas as 2D but I have a feeling the GIS people might view this differently?) Self-intersecting *lines* may indeed make sense, think of an 8 shaped narrow-gauge railway in a park. For a data format without topology, the 8 could be drawn in a way that would not intersect but if you intend to keep topology intact then you need the intersection. Bye Frederik -- Frederik Ramm ## eMail [EMAIL PROTECTED] ## N49°00'09 E008°23'33 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] [OSM-dev] Polygons in OSM don't necessarily comply to simple feature specification
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
Re: [OSM-talk] [OSM-dev] Polygons in OSM don't necessarily comply to simple feature specification
Op 17 apr 2008, om 00:07 heeft Frederik Ramm het volgende geschreven: Hi, yesterday a colleague approached me asking why OSM data doesn't comply to the Simple Feature specification[1] I guess the honest answer is very likely that most people invovled in designing anything at OSM have no prior GIS experience. Most of us are amateurs. We design stuff that we think works, and if people say we don't follow standards then we say that's by design, but mostly it is just ignorance. And ignorance is bliss. [..] Frederik, I guess this is what I thought would be the underlying train of thought, but thanks so much for putting it to words so well, and for making me laugh :) The question I asked in return was: you could just as well filter the offending objects out upon importing, couldn't you? That proved hard: apparently SQL Server 2008 croaks when it encounters self-intersecting objects. Shh. -- martijn van exel -+- [EMAIL PROTECTED] -+- http://www.schaaltreinen.nl/ ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] [OSM-dev] Polygons in OSM don't necessarily comply to simple feature specification
On Wed, Apr 16, 2008 at 11:58:21PM +0200, Martijn van Exel wrote: Op 16 apr 2008, om 23:41 heeft Christopher Schmidt het volgende geschreven: On Wed, Apr 16, 2008 at 11:28:32PM +0200, Martijn van Exel wrote: It seems likely that the netherlands 'self intersecting polygons' are simply the result of poorly curated coastline imports or something similar: in general, self-intersecting polygons aren't useful for anything I can think of in OSM, but preventing it is hard, and not really within the spirit of *most* simple geographic data tools. Why not? Simple Features to me seem to be all about the spirit of simplicity - and they exclude self-intersection. But implementatons don't. (MS's spatial offering is somewhat lonely in respecting this.) In any case, OSM doesn't have polygons, so OSM can't prevent the intersection of Polygons. The fact that the interpretation of specific types of ways as polygons is common does not make the API have that property. Discourating this behavior, or preventing it, is therefore not an API level decision, but an editor-level decision. Regards, -- Christopher Schmidt MetaCarta ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] [OSM-dev] Polygons in OSM don't necessarily comply to simple feature specification
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 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] [OSM-dev] Polygons in OSM don't necessarily comply to simple feature specification
On Thu, Apr 17, 2008 at 12:15:16AM +0200, Frederik Ramm wrote: Hi, The only exceptions apparently being that self-intersecting polygons are allowed in OSM. The wiki page you cited says In general, a 2D geometry is simple if it contains no self-intersection. - what do they mean by 2D geometry? Specifically, would a self-intersecting *line* be allowed? (I like to think of points as 0D, lines as 1D, and areas as 2D but I have a feeling the GIS people might view this differently?) Geometry in a 2 dimensional plane. In a 2 dimensional plane, all geometries are 2d, because you specify their coordinates in two dimensions. Regards, -- Christopher Schmidt MetaCarta ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] [OSM-dev] Polygons in OSM don't necessarily comply to simple feature specification
On Thu, 2008-04-17 at 00:07 +0200, Frederik Ramm wrote: So much for OGC stuff in general. About Simple Features specifically, I guess there simply was nobody who wanted to do the extra work. I remember Artem complaining about self-intersecting stuff once and I think the offending items are sorted out somewhere in osm2pgsql, are they not? I have a feeling that the relevant lines of code may be disabled at the moment in osm2pgsql. It was implemented by some of the commented out noded() lines in build_geometry.cpp. I think I removed them when I had some problems getting this to work with the 0.5 relation handling and never found the need to put them back again. Jon ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
