Re: [JPP-Devel] The new geometry is invalid. Cancelled.
Hi Martin, I just noticed that the code we use for the CombineSelectedFeature plugin is very close to GeometryFactory.buildGeometry() method. Hence, I checked buildGeomery code and found that in the particular case of two adjacent polygons, it will also produce an invalid geometry. I don't know what would be the cost of an extra test for validity, but I think buildGeometry should never return invalid geometries from valid input. Best regards, Michaël Hi, Is it in OJ possible to check first for valid geometries when Combine Selected Features or is this a great problem? If it is a great problem maybe it is better Combine Selected Features makes always a geometrycollection? There are several points : 1 - in the step by step process you described, error should have been thrown while combining the two polygons, not while moving the resulted invalid multipolygon 2 - I agree that in this case, building a valid GeometryCollection is better than building an invalid Multipolygon, even if GeometryCollection are much less useful (many operations accepting MultiPolygon will fail on GeometryCollection). If if no one has any objection, I propose to do the change. 3 - you surely knows that OpenJUMP has a hidden option to accept/refuse invalid geometries during edit operations (in this case, it is of no help though) Regards, Michaël What do you think? Regards Uwe Am 09.04.2013 03:21, schrieb Martin Davis: As Michael and Stefan point out, Polygons in a MultiPolygon must be edge-disjoint (which another way of stating the formal definition must only touch at a finite number of points. If they touched along an edge, that would cause an infinite number of points to be coincident). Another way of looking at this is that MultiPolygons are in a sense the canonical description of a given area of the plane. If edge touches or overlaps were allowed then there would be an infinite number of geometries which described the same area. Also, from the point of view of computing polygon overlay and spatial relationships this is a nice rule to have, since it reduces the number of cases which need to be checked for. This makes the code simpler and more performant. The cost is that it is necessary to ensure that MultiPolygons are valid at creation time. This is a reasonable tradeoff, since in general geometries are queried more often than they are created. GeometryCollections on the other hand have no particular semantics - they are just bags of geometries. This makes them useful for holding arbitrary sets of geometries, but makes them more complex (and sometimes slower) to process. On 4/8/2013 11:04 AM, Michaël Michaud wrote: Hi Uwe, Stefan, OpenJUMP (JTS) is right, this MultiPolygon is not OGC conform Here is the citation : Multipolygon 2. The Boundaries of any 2 Polygons that are elements of a MultiPolygon may not ‘cross’ and may touch at only a finite number of points. (Note that crossing is prevented by assertion 1 above). Don't ask me why, I've always thought it is strange that lines can share their boundaries in a MultiLineString and polygons cannot share an edge in a MultiPolygon, but it's a well established rule that JTS follows. Michaël Hi Uwe, I am not sure I would call it a bug. OJ, should (try to) create data that are OGC conform, but in this case it doesn't. Which means, the case needs special treatment, but this is not implemented. That the multi-polygon causes an error is with the OGS SF specification = correct. However, that the geometry collection does not cause an error should be correct aw well, because there is, I believe, nothing said about geometry collections and their validity. Geometry collections should be allowed to have any type of geometries in what ever way they are drawn - like a container. If we would check geometry collections for their validity it may be that people cannot store anymore the data they have. Hence, checking should be optional. But I guess here, Michael M. knows probably more about OGC conformance? I'll also cc to JTS list. cheers, stefan PS: the Multi-polygon: MULTIPOLYGON ((( 80 125, 80 241, 175 241, 175 125, 80 125 )), (( 175 125, 175 241, 263 241, 263 125, 175 125 ))) Am 08.04.13 09:48, schrieb Uwe Dalluege: Hi Stefan, I am afraid I do not understand :-( Do you think this is a bug in OJ? The multipolygon causes an error the geometrycollection not. Is this behaviour OGC-conform (simpel features...)? What do you think? uwe Am 08.04.2013 16:36, schrieb Stefan Steiniger: Hi, so - well the situation is not so nice, as it should be valid. However, the JTS TestBuilder says the Multi-Polgyon is invalid because of Self-intersection at or near point
Re: [JPP-Devel] The new geometry is invalid. Cancelled.
Hi Martin, I just noticed that the code we use for the CombineSelectedFeature plugin is very close to GeometryFactory.buildGeometry() method. Hence, I checked buildGeomery code and found that in the particular case of two adjacent polygons, it will also produce an invalid geometry. And probably also in all the cases of overlapping polygons, which means the suggested change is not just a corner case. Michaël I don't know what would be the cost of an extra test for validity, but I think buildGeometry should never return invalid geometries from valid input. Best regards, Michaël Hi, Is it in OJ possible to check first for valid geometries when Combine Selected Features or is this a great problem? If it is a great problem maybe it is better Combine Selected Features makes always a geometrycollection? There are several points : 1 - in the step by step process you described, error should have been thrown while combining the two polygons, not while moving the resulted invalid multipolygon 2 - I agree that in this case, building a valid GeometryCollection is better than building an invalid Multipolygon, even if GeometryCollection are much less useful (many operations accepting MultiPolygon will fail on GeometryCollection). If if no one has any objection, I propose to do the change. 3 - you surely knows that OpenJUMP has a hidden option to accept/refuse invalid geometries during edit operations (in this case, it is of no help though) Regards, Michaël What do you think? Regards Uwe Am 09.04.2013 03:21, schrieb Martin Davis: As Michael and Stefan point out, Polygons in a MultiPolygon must be edge-disjoint (which another way of stating the formal definition must only touch at a finite number of points. If they touched along an edge, that would cause an infinite number of points to be coincident). Another way of looking at this is that MultiPolygons are in a sense the canonical description of a given area of the plane. If edge touches or overlaps were allowed then there would be an infinite number of geometries which described the same area. Also, from the point of view of computing polygon overlay and spatial relationships this is a nice rule to have, since it reduces the number of cases which need to be checked for. This makes the code simpler and more performant. The cost is that it is necessary to ensure that MultiPolygons are valid at creation time. This is a reasonable tradeoff, since in general geometries are queried more often than they are created. GeometryCollections on the other hand have no particular semantics - they are just bags of geometries. This makes them useful for holding arbitrary sets of geometries, but makes them more complex (and sometimes slower) to process. On 4/8/2013 11:04 AM, Michaël Michaud wrote: Hi Uwe, Stefan, OpenJUMP (JTS) is right, this MultiPolygon is not OGC conform Here is the citation : Multipolygon 2. The Boundaries of any 2 Polygons that are elements of a MultiPolygon may not ‘cross’ and may touch at only a finite number of points. (Note that crossing is prevented by assertion 1 above). Don't ask me why, I've always thought it is strange that lines can share their boundaries in a MultiLineString and polygons cannot share an edge in a MultiPolygon, but it's a well established rule that JTS follows. Michaël Hi Uwe, I am not sure I would call it a bug. OJ, should (try to) create data that are OGC conform, but in this case it doesn't. Which means, the case needs special treatment, but this is not implemented. That the multi-polygon causes an error is with the OGS SF specification = correct. However, that the geometry collection does not cause an error should be correct aw well, because there is, I believe, nothing said about geometry collections and their validity. Geometry collections should be allowed to have any type of geometries in what ever way they are drawn - like a container. If we would check geometry collections for their validity it may be that people cannot store anymore the data they have. Hence, checking should be optional. But I guess here, Michael M. knows probably more about OGC conformance? I'll also cc to JTS list. cheers, stefan PS: the Multi-polygon: MULTIPOLYGON ((( 80 125, 80 241, 175 241, 175 125, 80 125 )), (( 175 125, 175 241, 263 241, 263 125, 175 125 ))) Am 08.04.13 09:48, schrieb Uwe Dalluege: Hi Stefan, I am afraid I do not understand :-( Do you think this is a bug in OJ? The multipolygon causes an error the geometrycollection not. Is this behaviour OGC-conform (simpel features...)? What do you think? uwe Am 08.04.2013 16:36, schrieb Stefan Steiniger: Hi, so - well the situation is not so nice, as
Re: [JPP-Devel] The new geometry is invalid. Cancelled.
Hi Larry, Thanks for the input, I followed your suggestion to add a warning in the status bar. I did the test for the MultiPolygon case only though. Not sure it is useful in the general case. Maybe it would be better to make the plugin consistent with the edit tools option accept invalid geometry. I think it is not yet. Michaël Hi Michaël, Echoing what I think you are proposing: 1) when Combine Selected Features is invoked, a basic topology validity check is done on the result. 2) Any errors should be reported in the status bar or the Output Window. 3) If an invalid geometry results from building a MultiPolygon, a GeometryCollection is built instead. +1 if this is the plan. -1 if the plan is to just build a GeometryCollection instead. regards, Larry On Tue, Apr 9, 2013 at 1:36 PM, Michaël Michaud michael.mich...@free.fr mailto:michael.mich...@free.fr wrote: Hi, Is it in OJ possible to check first for valid geometries when Combine Selected Features or is this a great problem? If it is a great problem maybe it is better Combine Selected Features makes always a geometrycollection? There are several points : 1 - in the step by step process you described, error should have been thrown while combining the two polygons, not while moving the resulted invalid multipolygon 2 - I agree that in this case, building a valid GeometryCollection is better than building an invalid Multipolygon, even if GeometryCollection are much less useful (many operations accepting MultiPolygon will fail on GeometryCollection). If if no one has any objection, I propose to do the change. 3 - you surely knows that OpenJUMP has a hidden option to accept/refuse invalid geometries during edit operations (in this case, it is of no help though) Regards, Michaël What do you think? Regards Uwe Am 09.04.2013 03:21, schrieb Martin Davis: As Michael and Stefan point out, Polygons in a MultiPolygon must be edge-disjoint (which another way of stating the formal definition must only touch at a finite number of points. If they touched along an edge, that would cause an infinite number of points to be coincident). Another way of looking at this is that MultiPolygons are in a sense the canonical description of a given area of the plane. If edge touches or overlaps were allowed then there would be an infinite number of geometries which described the same area. Also, from the point of view of computing polygon overlay and spatial relationships this is a nice rule to have, since it reduces the number of cases which need to be checked for. This makes the code simpler and more performant. The cost is that it is necessary to ensure that MultiPolygons are valid at creation time. This is a reasonable tradeoff, since in general geometries are queried more often than they are created. GeometryCollections on the other hand have no particular semantics - they are just bags of geometries. This makes them useful for holding arbitrary sets of geometries, but makes them more complex (and sometimes slower) to process. On 4/8/2013 11:04 AM, Michaël Michaud wrote: Hi Uwe, Stefan, OpenJUMP (JTS) is right, this MultiPolygon is not OGC conform Here is the citation : Multipolygon 2. The Boundaries of any 2 Polygons that are elements of a MultiPolygon may not 'cross' and may touch at only a finite number of points. (Note that crossing is prevented by assertion 1 above). Don't ask me why, I've always thought it is strange that lines can share their boundaries in a MultiLineString and polygons cannot share an edge in a MultiPolygon, but it's a well established rule that JTS follows. Michaël Hi Uwe, I am not sure I would call it a bug. OJ, should (try to) create data that are OGC conform, but in this case it doesn't. Which means, the case needs special treatment, but this is not implemented. That the multi-polygon causes an error is with the OGS SF specification = correct. However, that the geometry collection does not cause an error should be correct aw well, because there is, I believe, nothing said about geometry collections and their validity. Geometry collections should be allowed to have any type of geometries in what ever way they are drawn - like a container. If we would check geometry collections for their validity it may be that people cannot store anymore the data they have. Hence, checking should be optional. But I guess here, Michael M. knows probably more about OGC conformance? I'll also cc to JTS
Re: [JPP-Devel] The new geometry is invalid. Cancelled.
Hi Michaël, do you mean the option OptionsView/EditPrevent edits resulting invalid geometries? I am not understanding this option. What is the use of drawing a selfintersection polygon? 1. In my opinion a program should never *compute* invalide geometries like multipolygon if it is not a valid multipolygon. 2. If a user construct an invalide geometry there must be a warning but it should not drawn. 2. The other side is to *load* invalide geometries from extern and have a chance to correct them. Is this option OptionsView/EditPrevent edits resulting invalid geometries for this case? Uwe Am 10.04.2013 08:53, schrieb Michaël Michaud: Hi Larry, Thanks for the input, I followed your suggestion to add a warning in the status bar. I did the test for the MultiPolygon case only though. Not sure it is useful in the general case. Maybe it would be better to make the plugin consistent with the edit tools option accept invalid geometry. I think it is not yet. Michaël Hi Michaël, Echoing what I think you are proposing: 1) when Combine Selected Features is invoked, a basic topology validity check is done on the result. 2) Any errors should be reported in the status bar or the Output Window. 3) If an invalid geometry results from building a MultiPolygon, a GeometryCollection is built instead. +1 if this is the plan. -1 if the plan is to just build a GeometryCollection instead. regards, Larry On Tue, Apr 9, 2013 at 1:36 PM, Michaël Michaud michael.mich...@free.fr mailto:michael.mich...@free.fr wrote: Hi, Is it in OJ possible to check first for valid geometries when Combine Selected Features or is this a great problem? If it is a great problem maybe it is better Combine Selected Features makes always a geometrycollection? There are several points : 1 - in the step by step process you described, error should have been thrown while combining the two polygons, not while moving the resulted invalid multipolygon 2 - I agree that in this case, building a valid GeometryCollection is better than building an invalid Multipolygon, even if GeometryCollection are much less useful (many operations accepting MultiPolygon will fail on GeometryCollection). If if no one has any objection, I propose to do the change. 3 - you surely knows that OpenJUMP has a hidden option to accept/refuse invalid geometries during edit operations (in this case, it is of no help though) Regards, Michaël What do you think? Regards Uwe Am 09.04.2013 03:21, schrieb Martin Davis: As Michael and Stefan point out, Polygons in a MultiPolygon must be edge-disjoint (which another way of stating the formal definition must only touch at a finite number of points. If they touched along an edge, that would cause an infinite number of points to be coincident). Another way of looking at this is that MultiPolygons are in a sense the canonical description of a given area of the plane. If edge touches or overlaps were allowed then there would be an infinite number of geometries which described the same area. Also, from the point of view of computing polygon overlay and spatial relationships this is a nice rule to have, since it reduces the number of cases which need to be checked for. This makes the code simpler and more performant. The cost is that it is necessary to ensure that MultiPolygons are valid at creation time. This is a reasonable tradeoff, since in general geometries are queried more often than they are created. GeometryCollections on the other hand have no particular semantics - they are just bags of geometries. This makes them useful for holding arbitrary sets of geometries, but makes them more complex (and sometimes slower) to process. On 4/8/2013 11:04 AM, Michaël Michaud wrote: Hi Uwe, Stefan, OpenJUMP (JTS) is right, this MultiPolygon is not OGC conform Here is the citation : Multipolygon 2. The Boundaries of any 2 Polygons that are elements of a MultiPolygon may not ‘cross’ and may touch at only a finite number of points. (Note that crossing is prevented by assertion 1 above). Don't ask me why, I've always thought it is strange that lines can share their boundaries in a MultiLineString and polygons cannot share an edge in a MultiPolygon, but it's a well established rule that JTS follows. Michaël Hi Uwe, I am not sure I would call it a bug. OJ, should (try to) create data that are OGC conform, but in this case it doesn't. Which means, the case needs special treatment, but
Re: [JPP-Devel] The new geometry is invalid. Cancelled.
Hi, sorry, the last point 2 should be a 3 :-( uwe Am 10.04.2013 10:24, schrieb Uwe Dalluege: Hi Michaël, do you mean the option OptionsView/EditPrevent edits resulting invalid geometries? I am not understanding this option. What is the use of drawing a selfintersection polygon? 1. In my opinion a program should never *compute* invalide geometries like multipolygon if it is not a valid multipolygon. 2. If a user construct an invalide geometry there must be a warning but it should not drawn. 2. The other side is to *load* invalide geometries from extern and have a chance to correct them. Is this option OptionsView/EditPrevent edits resulting invalid geometries for this case? Uwe Am 10.04.2013 08:53, schrieb Michaël Michaud: Hi Larry, Thanks for the input, I followed your suggestion to add a warning in the status bar. I did the test for the MultiPolygon case only though. Not sure it is useful in the general case. Maybe it would be better to make the plugin consistent with the edit tools option accept invalid geometry. I think it is not yet. Michaël Hi Michaël, Echoing what I think you are proposing: 1) when Combine Selected Features is invoked, a basic topology validity check is done on the result. 2) Any errors should be reported in the status bar or the Output Window. 3) If an invalid geometry results from building a MultiPolygon, a GeometryCollection is built instead. +1 if this is the plan. -1 if the plan is to just build a GeometryCollection instead. regards, Larry On Tue, Apr 9, 2013 at 1:36 PM, Michaël Michaud michael.mich...@free.fr mailto:michael.mich...@free.fr wrote: Hi, Is it in OJ possible to check first for valid geometries when Combine Selected Features or is this a great problem? If it is a great problem maybe it is better Combine Selected Features makes always a geometrycollection? There are several points : 1 - in the step by step process you described, error should have been thrown while combining the two polygons, not while moving the resulted invalid multipolygon 2 - I agree that in this case, building a valid GeometryCollection is better than building an invalid Multipolygon, even if GeometryCollection are much less useful (many operations accepting MultiPolygon will fail on GeometryCollection). If if no one has any objection, I propose to do the change. 3 - you surely knows that OpenJUMP has a hidden option to accept/refuse invalid geometries during edit operations (in this case, it is of no help though) Regards, Michaël What do you think? Regards Uwe Am 09.04.2013 03:21, schrieb Martin Davis: As Michael and Stefan point out, Polygons in a MultiPolygon must be edge-disjoint (which another way of stating the formal definition must only touch at a finite number of points. If they touched along an edge, that would cause an infinite number of points to be coincident). Another way of looking at this is that MultiPolygons are in a sense the canonical description of a given area of the plane. If edge touches or overlaps were allowed then there would be an infinite number of geometries which described the same area. Also, from the point of view of computing polygon overlay and spatial relationships this is a nice rule to have, since it reduces the number of cases which need to be checked for. This makes the code simpler and more performant. The cost is that it is necessary to ensure that MultiPolygons are valid at creation time. This is a reasonable tradeoff, since in general geometries are queried more often than they are created. GeometryCollections on the other hand have no particular semantics - they are just bags of geometries. This makes them useful for holding arbitrary sets of geometries, but makes them more complex (and sometimes slower) to process. On 4/8/2013 11:04 AM, Michaël Michaud wrote: Hi Uwe, Stefan, OpenJUMP (JTS) is right, this MultiPolygon is not OGC conform Here is the citation : Multipolygon 2. The Boundaries of any 2 Polygons that are elements of a MultiPolygon may not ‘cross’ and may touch at only a finite number of points. (Note that crossing is prevented by assertion 1 above). Don't ask me why, I've always thought it is strange that lines can share their boundaries in a MultiLineString and polygons cannot share an edge in a MultiPolygon, but it's a well established rule that JTS follows. Michaël Hi Uwe,
Re: [JPP-Devel] The new geometry is invalid. Cancelled.
Hi, 1) It should never happen but we are living in a not perfect world and it happens and will always happen. 2) For some use cases the invalid geometries may be good enough. Typical examples are polygons with tiny self-intersections or inner circles with only two vertices (A-B-A). Simplification may create such invalid features and they can be used for rendering. Also some other some other useful operations like buffer can create invalid geometries. It may be better to accept them and give user a possibility to correct self-intersections etc. by hand than not to create a buffered geometry at all. 3) This is a valid point too and if you sometimes try to correct a very messy polygon with lots of self-intersections in the corners you will notice that it may be impossible to correct the feature with this setting on. Removing or moving a vertex of the invalid geometry may create another invalid geometry and you cannot continue to the next step if this intermediate phase is not accepted. -Jukka Rahkonen- Uwe Dalluege wrote: Hi, sorry, the last point 2 should be a 3 :-( uwe Am 10.04.2013 10:24, schrieb Uwe Dalluege: Hi Michaël, do you mean the option OptionsView/EditPrevent edits resulting invalid geometries? I am not understanding this option. What is the use of drawing a selfintersection polygon? 1. In my opinion a program should never *compute* invalide geometries like multipolygon if it is not a valid multipolygon. 2. If a user construct an invalide geometry there must be a warning but it should not drawn. 2. The other side is to *load* invalide geometries from extern and have a chance to correct them. Is this option OptionsView/EditPrevent edits resulting invalid geometries for this case? Uwe Am 10.04.2013 08:53, schrieb Michaël Michaud: Hi Larry, Thanks for the input, I followed your suggestion to add a warning in the status bar. I did the test for the MultiPolygon case only though. Not sure it is useful in the general case. Maybe it would be better to make the plugin consistent with the edit tools option accept invalid geometry. I think it is not yet. Michaël Hi Michaël, Echoing what I think you are proposing: 1) when Combine Selected Features is invoked, a basic topology validity check is done on the result. 2) Any errors should be reported in the status bar or the Output Window. 3) If an invalid geometry results from building a MultiPolygon, a GeometryCollection is built instead. +1 if this is the plan. -1 if the plan is to just build a GeometryCollection instead. regards, Larry On Tue, Apr 9, 2013 at 1:36 PM, Michaël Michaud michael.mich...@free.fr mailto:michael.mich...@free.fr wrote: Hi, Is it in OJ possible to check first for valid geometries when Combine Selected Features or is this a great problem? If it is a great problem maybe it is better Combine Selected Features makes always a geometrycollection? There are several points : 1 - in the step by step process you described, error should have been thrown while combining the two polygons, not while moving the resulted invalid multipolygon 2 - I agree that in this case, building a valid GeometryCollection is better than building an invalid Multipolygon, even if GeometryCollection are much less useful (many operations accepting MultiPolygon will fail on GeometryCollection). If if no one has any objection, I propose to do the change. 3 - you surely knows that OpenJUMP has a hidden option to accept/refuse invalid geometries during edit operations (in this case, it is of no help though) Regards, Michaël What do you think? Regards Uwe Am 09.04.2013 03:21, schrieb Martin Davis: As Michael and Stefan point out, Polygons in a MultiPolygon must be edge-disjoint (which another way of stating the formal definition must only touch at a finite number of points. If they touched along an edge, that would cause an infinite number of points to be coincident). Another way of looking at this is that MultiPolygons are in a sense the canonical description of a given area of the plane. If edge touches or overlaps were allowed then there would be an infinite number of geometries which described the same area. Also, from the point of view of computing polygon overlay and spatial relationships this is a nice rule to have, since it reduces the number of cases which need to be checked for. This makes the code simpler and more performant. The cost is that it is necessary to ensure that MultiPolygons are valid at
Re: [JPP-Devel] The new geometry is invalid. Cancelled.
Hi Martin, Michaël and Stefan, thank you very much for this detailed clarification! Is it in OJ possible to check first for valid geometries when Combine Selected Features or is this a great problem? If it is a great problem maybe it is better Combine Selected Features makes always a geometrycollection? What do you think? Regards Uwe Am 09.04.2013 03:21, schrieb Martin Davis: As Michael and Stefan point out, Polygons in a MultiPolygon must be edge-disjoint (which another way of stating the formal definition must only touch at a finite number of points. If they touched along an edge, that would cause an infinite number of points to be coincident). Another way of looking at this is that MultiPolygons are in a sense the canonical description of a given area of the plane. If edge touches or overlaps were allowed then there would be an infinite number of geometries which described the same area. Also, from the point of view of computing polygon overlay and spatial relationships this is a nice rule to have, since it reduces the number of cases which need to be checked for. This makes the code simpler and more performant. The cost is that it is necessary to ensure that MultiPolygons are valid at creation time. This is a reasonable tradeoff, since in general geometries are queried more often than they are created. GeometryCollections on the other hand have no particular semantics - they are just bags of geometries. This makes them useful for holding arbitrary sets of geometries, but makes them more complex (and sometimes slower) to process. On 4/8/2013 11:04 AM, Michaël Michaud wrote: Hi Uwe, Stefan, OpenJUMP (JTS) is right, this MultiPolygon is not OGC conform Here is the citation : Multipolygon 2. The Boundaries of any 2 Polygons that are elements of a MultiPolygon may not ‘cross’ and may touch at only a finite number of points. (Note that crossing is prevented by assertion 1 above). Don't ask me why, I've always thought it is strange that lines can share their boundaries in a MultiLineString and polygons cannot share an edge in a MultiPolygon, but it's a well established rule that JTS follows. Michaël Hi Uwe, I am not sure I would call it a bug. OJ, should (try to) create data that are OGC conform, but in this case it doesn't. Which means, the case needs special treatment, but this is not implemented. That the multi-polygon causes an error is with the OGS SF specification = correct. However, that the geometry collection does not cause an error should be correct aw well, because there is, I believe, nothing said about geometry collections and their validity. Geometry collections should be allowed to have any type of geometries in what ever way they are drawn - like a container. If we would check geometry collections for their validity it may be that people cannot store anymore the data they have. Hence, checking should be optional. But I guess here, Michael M. knows probably more about OGC conformance? I'll also cc to JTS list. cheers, stefan PS: the Multi-polygon: MULTIPOLYGON ((( 80 125, 80 241, 175 241, 175 125, 80 125 )), (( 175 125, 175 241, 263 241, 263 125, 175 125 ))) Am 08.04.13 09:48, schrieb Uwe Dalluege: Hi Stefan, I am afraid I do not understand :-( Do you think this is a bug in OJ? The multipolygon causes an error the geometrycollection not. Is this behaviour OGC-conform (simpel features...)? What do you think? uwe Am 08.04.2013 16:36, schrieb Stefan Steiniger: Hi, so - well the situation is not so nice, as it should be valid. However, the JTS TestBuilder says the Multi-Polgyon is invalid because of Self-intersection at or near point (175.0, 125.0, NaN) Same message appears when you try to add it as a new feature. maybe you can make it valid before by running a zero-buffer over it? stefan Am 08.04.13 07:30, schrieb Uwe Dalluege: Hi, if you put a third geometrie to the two polygons, for instance a linestring, and combine them you will receive a geometrycollection and not a multipolygon. The geometrycollection causes *no* errors but the multipolygon. Uwe Am 08.04.2013 12:05, schrieb Uwe Dalluege: Hi, I get the error: The new geometry is invalid. Cancelled. and I am not shure whether this error is correct. 1. Switch Snap to vertices option. 2. Draw a rectangle. 3. Draw a second rectangle with two identical vertices from the first rectangle (with snap). 4. Select the two rectangles and Combine Selected features 5. Try to move this multipolygon with Move Selected Items Tool. 6. The error appears The new geometry is invalid. Cancelled. 7. The QAValidate Selected Layers... causes a self-intersection in *one* point. Is this a bug in OJ (a precision-problem) or is
Re: [JPP-Devel] The new geometry is invalid. Cancelled.
Hi, Is it in OJ possible to check first for valid geometries when Combine Selected Features or is this a great problem? If it is a great problem maybe it is better Combine Selected Features makes always a geometrycollection? There are several points : 1 - in the step by step process you described, error should have been thrown while combining the two polygons, not while moving the resulted invalid multipolygon 2 - I agree that in this case, building a valid GeometryCollection is better than building an invalid Multipolygon, even if GeometryCollection are much less useful (many operations accepting MultiPolygon will fail on GeometryCollection). If if no one has any objection, I propose to do the change. 3 - you surely knows that OpenJUMP has a hidden option to accept/refuse invalid geometries during edit operations (in this case, it is of no help though) Regards, Michaël What do you think? Regards Uwe Am 09.04.2013 03:21, schrieb Martin Davis: As Michael and Stefan point out, Polygons in a MultiPolygon must be edge-disjoint (which another way of stating the formal definition must only touch at a finite number of points. If they touched along an edge, that would cause an infinite number of points to be coincident). Another way of looking at this is that MultiPolygons are in a sense the canonical description of a given area of the plane. If edge touches or overlaps were allowed then there would be an infinite number of geometries which described the same area. Also, from the point of view of computing polygon overlay and spatial relationships this is a nice rule to have, since it reduces the number of cases which need to be checked for. This makes the code simpler and more performant. The cost is that it is necessary to ensure that MultiPolygons are valid at creation time. This is a reasonable tradeoff, since in general geometries are queried more often than they are created. GeometryCollections on the other hand have no particular semantics - they are just bags of geometries. This makes them useful for holding arbitrary sets of geometries, but makes them more complex (and sometimes slower) to process. On 4/8/2013 11:04 AM, Michaël Michaud wrote: Hi Uwe, Stefan, OpenJUMP (JTS) is right, this MultiPolygon is not OGC conform Here is the citation : Multipolygon 2. The Boundaries of any 2 Polygons that are elements of a MultiPolygon may not ‘cross’ and may touch at only a finite number of points. (Note that crossing is prevented by assertion 1 above). Don't ask me why, I've always thought it is strange that lines can share their boundaries in a MultiLineString and polygons cannot share an edge in a MultiPolygon, but it's a well established rule that JTS follows. Michaël Hi Uwe, I am not sure I would call it a bug. OJ, should (try to) create data that are OGC conform, but in this case it doesn't. Which means, the case needs special treatment, but this is not implemented. That the multi-polygon causes an error is with the OGS SF specification = correct. However, that the geometry collection does not cause an error should be correct aw well, because there is, I believe, nothing said about geometry collections and their validity. Geometry collections should be allowed to have any type of geometries in what ever way they are drawn - like a container. If we would check geometry collections for their validity it may be that people cannot store anymore the data they have. Hence, checking should be optional. But I guess here, Michael M. knows probably more about OGC conformance? I'll also cc to JTS list. cheers, stefan PS: the Multi-polygon: MULTIPOLYGON ((( 80 125, 80 241, 175 241, 175 125, 80 125 )), (( 175 125, 175 241, 263 241, 263 125, 175 125 ))) Am 08.04.13 09:48, schrieb Uwe Dalluege: Hi Stefan, I am afraid I do not understand :-( Do you think this is a bug in OJ? The multipolygon causes an error the geometrycollection not. Is this behaviour OGC-conform (simpel features...)? What do you think? uwe Am 08.04.2013 16:36, schrieb Stefan Steiniger: Hi, so - well the situation is not so nice, as it should be valid. However, the JTS TestBuilder says the Multi-Polgyon is invalid because of Self-intersection at or near point (175.0, 125.0, NaN) Same message appears when you try to add it as a new feature. maybe you can make it valid before by running a zero-buffer over it? stefan Am 08.04.13 07:30, schrieb Uwe Dalluege: Hi, if you put a third geometrie to the two polygons, for instance a linestring, and combine them you will receive a geometrycollection and not a multipolygon. The geometrycollection causes *no* errors but the multipolygon. Uwe Am 08.04.2013 12:05, schrieb Uwe Dalluege:
Re: [JPP-Devel] The new geometry is invalid. Cancelled.
2 - I agree that in this case, building a valid GeometryCollection is better than building an invalid Multipolygon, even if GeometryCollection are much less useful (many operations accepting MultiPolygon will fail on GeometryCollection). If if no one has any objection, I propose to do the change. +1 but I see, you added already a feature request Michael. stefan -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] The new geometry is invalid. Cancelled.
Hi Michaël, Echoing what I think you are proposing: 1) when Combine Selected Features is invoked, a basic topology validity check is done on the result. 2) Any errors should be reported in the status bar or the Output Window. 3) If an invalid geometry results from building a MultiPolygon, a GeometryCollection is built instead. +1 if this is the plan. -1 if the plan is to just build a GeometryCollection instead. regards, Larry On Tue, Apr 9, 2013 at 1:36 PM, Michaël Michaud michael.mich...@free.frwrote: Hi, Is it in OJ possible to check first for valid geometries when Combine Selected Features or is this a great problem? If it is a great problem maybe it is better Combine Selected Features makes always a geometrycollection? There are several points : 1 - in the step by step process you described, error should have been thrown while combining the two polygons, not while moving the resulted invalid multipolygon 2 - I agree that in this case, building a valid GeometryCollection is better than building an invalid Multipolygon, even if GeometryCollection are much less useful (many operations accepting MultiPolygon will fail on GeometryCollection). If if no one has any objection, I propose to do the change. 3 - you surely knows that OpenJUMP has a hidden option to accept/refuse invalid geometries during edit operations (in this case, it is of no help though) Regards, Michaël What do you think? Regards Uwe Am 09.04.2013 03:21, schrieb Martin Davis: As Michael and Stefan point out, Polygons in a MultiPolygon must be edge-disjoint (which another way of stating the formal definition must only touch at a finite number of points. If they touched along an edge, that would cause an infinite number of points to be coincident). Another way of looking at this is that MultiPolygons are in a sense the canonical description of a given area of the plane. If edge touches or overlaps were allowed then there would be an infinite number of geometries which described the same area. Also, from the point of view of computing polygon overlay and spatial relationships this is a nice rule to have, since it reduces the number of cases which need to be checked for. This makes the code simpler and more performant. The cost is that it is necessary to ensure that MultiPolygons are valid at creation time. This is a reasonable tradeoff, since in general geometries are queried more often than they are created. GeometryCollections on the other hand have no particular semantics - they are just bags of geometries. This makes them useful for holding arbitrary sets of geometries, but makes them more complex (and sometimes slower) to process. On 4/8/2013 11:04 AM, Michaël Michaud wrote: Hi Uwe, Stefan, OpenJUMP (JTS) is right, this MultiPolygon is not OGC conform Here is the citation : Multipolygon 2. The Boundaries of any 2 Polygons that are elements of a MultiPolygon may not ‘cross’ and may touch at only a finite number of points. (Note that crossing is prevented by assertion 1 above). Don't ask me why, I've always thought it is strange that lines can share their boundaries in a MultiLineString and polygons cannot share an edge in a MultiPolygon, but it's a well established rule that JTS follows. Michaël Hi Uwe, I am not sure I would call it a bug. OJ, should (try to) create data that are OGC conform, but in this case it doesn't. Which means, the case needs special treatment, but this is not implemented. That the multi-polygon causes an error is with the OGS SF specification = correct. However, that the geometry collection does not cause an error should be correct aw well, because there is, I believe, nothing said about geometry collections and their validity. Geometry collections should be allowed to have any type of geometries in what ever way they are drawn - like a container. If we would check geometry collections for their validity it may be that people cannot store anymore the data they have. Hence, checking should be optional. But I guess here, Michael M. knows probably more about OGC conformance? I'll also cc to JTS list. cheers, stefan PS: the Multi-polygon: MULTIPOLYGON ((( 80 125, 80 241, 175 241, 175 125, 80 125 )), (( 175 125, 175 241, 263 241, 263 125, 175 125 ))) Am 08.04.13 09:48, schrieb Uwe Dalluege: Hi Stefan, I am afraid I do not understand :-( Do you think this is a bug in OJ? The multipolygon causes an error the geometrycollection not. Is this behaviour OGC-conform (simpel features...)? What do you think? uwe Am 08.04.2013 16:36, schrieb Stefan Steiniger: Hi, so - well the
[JPP-Devel] The new geometry is invalid. Cancelled.
Hi, I get the error: The new geometry is invalid. Cancelled. and I am not shure whether this error is correct. 1. Switch Snap to vertices option. 2. Draw a rectangle. 3. Draw a second rectangle with two identical vertices from the first rectangle (with snap). 4. Select the two rectangles and Combine Selected features 5. Try to move this multipolygon with Move Selected Items Tool. 6. The error appears The new geometry is invalid. Cancelled. 7. The QAValidate Selected Layers... causes a self-intersection in *one* point. Is this a bug in OJ (a precision-problem) or is the new geometry really invalide? Uwe -- Minimize network downtime and maximize team effectiveness. Reduce network management and security costs.Learn how to hire the most talented Cisco Certified professionals. Visit the Employer Resources Portal http://www.cisco.com/web/learning/employer_resources/index.html ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] The new geometry is invalid. Cancelled.
Hi, I followed the steps and after the Combine selected features I had this multipolygon MULTIPOLYGON ((( 80 125, 80 241, 175 241, 175 125, 80 125 )), (( 175 125, 175 241, 263 241, 263 125, 175 125 ))) It cannot be added as WKT either. -Jukka- -Alkuperäinen viesti- Lähettäjä: Uwe Dalluege [mailto:uwe.dallu...@hcu-hamburg.de] Lähetetty: 8. huhtikuuta 2013 13:06 Vastaanottaja: Devel Jump Aihe: [JPP-Devel] The new geometry is invalid. Cancelled. Hi, I get the error: The new geometry is invalid. Cancelled. and I am not shure whether this error is correct. 1. Switch Snap to vertices option. 2. Draw a rectangle. 3. Draw a second rectangle with two identical vertices from the first rectangle (with snap). 4. Select the two rectangles and Combine Selected features 5. Try to move this multipolygon with Move Selected Items Tool. 6. The error appears The new geometry is invalid. Cancelled. 7. The QAValidate Selected Layers... causes a self-intersection in *one* point. Is this a bug in OJ (a precision-problem) or is the new geometry really invalide? Uwe -- Minimize network downtime and maximize team effectiveness. Reduce network management and security costs.Learn how to hire the most talented Cisco Certified professionals. Visit the Employer Resources Portal http://www.cisco.com/web/learning/employer_resources/index.html ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel -- Minimize network downtime and maximize team effectiveness. Reduce network management and security costs.Learn how to hire the most talented Cisco Certified professionals. Visit the Employer Resources Portal http://www.cisco.com/web/learning/employer_resources/index.html ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] The new geometry is invalid. Cancelled.
Hi, if you put a third geometrie to the two polygons, for instance a linestring, and combine them you will receive a geometrycollection and not a multipolygon. The geometrycollection causes *no* errors but the multipolygon. Uwe Am 08.04.2013 12:05, schrieb Uwe Dalluege: Hi, I get the error: The new geometry is invalid. Cancelled. and I am not shure whether this error is correct. 1. Switch Snap to vertices option. 2. Draw a rectangle. 3. Draw a second rectangle with two identical vertices from the first rectangle (with snap). 4. Select the two rectangles and Combine Selected features 5. Try to move this multipolygon with Move Selected Items Tool. 6. The error appears The new geometry is invalid. Cancelled. 7. The QAValidate Selected Layers... causes a self-intersection in *one* point. Is this a bug in OJ (a precision-problem) or is the new geometry really invalide? Uwe -- Minimize network downtime and maximize team effectiveness. Reduce network management and security costs.Learn how to hire the most talented Cisco Certified professionals. Visit the Employer Resources Portal http://www.cisco.com/web/learning/employer_resources/index.html ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel -- Minimize network downtime and maximize team effectiveness. Reduce network management and security costs.Learn how to hire the most talented Cisco Certified professionals. Visit the Employer Resources Portal http://www.cisco.com/web/learning/employer_resources/index.html ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] The new geometry is invalid. Cancelled.
Hi, so - well the situation is not so nice, as it should be valid. However, the JTS TestBuilder says the Multi-Polgyon is invalid because of Self-intersection at or near point (175.0, 125.0, NaN) Same message appears when you try to add it as a new feature. maybe you can make it valid before by running a zero-buffer over it? stefan Am 08.04.13 07:30, schrieb Uwe Dalluege: Hi, if you put a third geometrie to the two polygons, for instance a linestring, and combine them you will receive a geometrycollection and not a multipolygon. The geometrycollection causes *no* errors but the multipolygon. Uwe Am 08.04.2013 12:05, schrieb Uwe Dalluege: Hi, I get the error: The new geometry is invalid. Cancelled. and I am not shure whether this error is correct. 1. Switch Snap to vertices option. 2. Draw a rectangle. 3. Draw a second rectangle with two identical vertices from the first rectangle (with snap). 4. Select the two rectangles and Combine Selected features 5. Try to move this multipolygon with Move Selected Items Tool. 6. The error appears The new geometry is invalid. Cancelled. 7. The QAValidate Selected Layers... causes a self-intersection in *one* point. Is this a bug in OJ (a precision-problem) or is the new geometry really invalide? Uwe -- Minimize network downtime and maximize team effectiveness. Reduce network management and security costs.Learn how to hire the most talented Cisco Certified professionals. Visit the Employer Resources Portal http://www.cisco.com/web/learning/employer_resources/index.html ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel -- Minimize network downtime and maximize team effectiveness. Reduce network management and security costs.Learn how to hire the most talented Cisco Certified professionals. Visit the Employer Resources Portal http://www.cisco.com/web/learning/employer_resources/index.html ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel -- Minimize network downtime and maximize team effectiveness. Reduce network management and security costs.Learn how to hire the most talented Cisco Certified professionals. Visit the Employer Resources Portal http://www.cisco.com/web/learning/employer_resources/index.html ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] The new geometry is invalid. Cancelled.
Hi Stefan, I am afraid I do not understand :-( Do you think this is a bug in OJ? The multipolygon causes an error the geometrycollection not. Is this behaviour OGC-conform (simpel features...)? What do you think? uwe Am 08.04.2013 16:36, schrieb Stefan Steiniger: Hi, so - well the situation is not so nice, as it should be valid. However, the JTS TestBuilder says the Multi-Polgyon is invalid because of Self-intersection at or near point (175.0, 125.0, NaN) Same message appears when you try to add it as a new feature. maybe you can make it valid before by running a zero-buffer over it? stefan Am 08.04.13 07:30, schrieb Uwe Dalluege: Hi, if you put a third geometrie to the two polygons, for instance a linestring, and combine them you will receive a geometrycollection and not a multipolygon. The geometrycollection causes *no* errors but the multipolygon. Uwe Am 08.04.2013 12:05, schrieb Uwe Dalluege: Hi, I get the error: The new geometry is invalid. Cancelled. and I am not shure whether this error is correct. 1. Switch Snap to vertices option. 2. Draw a rectangle. 3. Draw a second rectangle with two identical vertices from the first rectangle (with snap). 4. Select the two rectangles and Combine Selected features 5. Try to move this multipolygon with Move Selected Items Tool. 6. The error appears The new geometry is invalid. Cancelled. 7. The QAValidate Selected Layers... causes a self-intersection in *one* point. Is this a bug in OJ (a precision-problem) or is the new geometry really invalide? Uwe -- Minimize network downtime and maximize team effectiveness. Reduce network management and security costs.Learn how to hire the most talented Cisco Certified professionals. Visit the Employer Resources Portal http://www.cisco.com/web/learning/employer_resources/index.html ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel -- Minimize network downtime and maximize team effectiveness. Reduce network management and security costs.Learn how to hire the most talented Cisco Certified professionals. Visit the Employer Resources Portal http://www.cisco.com/web/learning/employer_resources/index.html ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel -- Minimize network downtime and maximize team effectiveness. Reduce network management and security costs.Learn how to hire the most talented Cisco Certified professionals. Visit the Employer Resources Portal http://www.cisco.com/web/learning/employer_resources/index.html ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel -- Minimize network downtime and maximize team effectiveness. Reduce network management and security costs.Learn how to hire the most talented Cisco Certified professionals. Visit the Employer Resources Portal http://www.cisco.com/web/learning/employer_resources/index.html ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] The new geometry is invalid. Cancelled.
Hi Uwe, I am not sure I would call it a bug. OJ, should (try to) create data that are OGC conform, but in this case it doesn't. Which means, the case needs special treatment, but this is not implemented. That the multi-polygon causes an error is with the OGS SF specification = correct. However, that the geometry collection does not cause an error should be correct aw well, because there is, I believe, nothing said about geometry collections and their validity. Geometry collections should be allowed to have any type of geometries in what ever way they are drawn - like a container. If we would check geometry collections for their validity it may be that people cannot store anymore the data they have. Hence, checking should be optional. But I guess here, Michael M. knows probably more about OGC conformance? I'll also cc to JTS list. cheers, stefan PS: the Multi-polygon: MULTIPOLYGON ((( 80 125, 80 241, 175 241, 175 125, 80 125 )), (( 175 125, 175 241, 263 241, 263 125, 175 125 ))) Am 08.04.13 09:48, schrieb Uwe Dalluege: Hi Stefan, I am afraid I do not understand :-( Do you think this is a bug in OJ? The multipolygon causes an error the geometrycollection not. Is this behaviour OGC-conform (simpel features...)? What do you think? uwe Am 08.04.2013 16:36, schrieb Stefan Steiniger: Hi, so - well the situation is not so nice, as it should be valid. However, the JTS TestBuilder says the Multi-Polgyon is invalid because of Self-intersection at or near point (175.0, 125.0, NaN) Same message appears when you try to add it as a new feature. maybe you can make it valid before by running a zero-buffer over it? stefan Am 08.04.13 07:30, schrieb Uwe Dalluege: Hi, if you put a third geometrie to the two polygons, for instance a linestring, and combine them you will receive a geometrycollection and not a multipolygon. The geometrycollection causes *no* errors but the multipolygon. Uwe Am 08.04.2013 12:05, schrieb Uwe Dalluege: Hi, I get the error: The new geometry is invalid. Cancelled. and I am not shure whether this error is correct. 1. Switch Snap to vertices option. 2. Draw a rectangle. 3. Draw a second rectangle with two identical vertices from the first rectangle (with snap). 4. Select the two rectangles and Combine Selected features 5. Try to move this multipolygon with Move Selected Items Tool. 6. The error appears The new geometry is invalid. Cancelled. 7. The QAValidate Selected Layers... causes a self-intersection in *one* point. Is this a bug in OJ (a precision-problem) or is the new geometry really invalide? Uwe -- Minimize network downtime and maximize team effectiveness. Reduce network management and security costs.Learn how to hire the most talented Cisco Certified professionals. Visit the Employer Resources Portal http://www.cisco.com/web/learning/employer_resources/index.html ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel -- Minimize network downtime and maximize team effectiveness. Reduce network management and security costs.Learn how to hire the most talented Cisco Certified professionals. Visit the Employer Resources Portal http://www.cisco.com/web/learning/employer_resources/index.html ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel -- Minimize network downtime and maximize team effectiveness. Reduce network management and security costs.Learn how to hire the most talented Cisco Certified professionals. Visit the Employer Resources Portal http://www.cisco.com/web/learning/employer_resources/index.html ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel -- Minimize network downtime and maximize team effectiveness. Reduce network management and security costs.Learn how to hire the most talented Cisco Certified professionals. Visit the Employer Resources Portal http://www.cisco.com/web/learning/employer_resources/index.html ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] The new geometry is invalid. Cancelled.
Hi Uwe, Stefan, OpenJUMP (JTS) is right, this MultiPolygon is not OGC conform Here is the citation : Multipolygon 2. The Boundaries of any 2 Polygons that are elements of a MultiPolygon may not ‘cross’ and may touch at only a finite number of points. (Note that crossing is prevented by assertion 1 above). Don't ask me why, I've always thought it is strange that lines can share their boundaries in a MultiLineString and polygons cannot share an edge in a MultiPolygon, but it's a well established rule that JTS follows. Michaël Hi Uwe, I am not sure I would call it a bug. OJ, should (try to) create data that are OGC conform, but in this case it doesn't. Which means, the case needs special treatment, but this is not implemented. That the multi-polygon causes an error is with the OGS SF specification = correct. However, that the geometry collection does not cause an error should be correct aw well, because there is, I believe, nothing said about geometry collections and their validity. Geometry collections should be allowed to have any type of geometries in what ever way they are drawn - like a container. If we would check geometry collections for their validity it may be that people cannot store anymore the data they have. Hence, checking should be optional. But I guess here, Michael M. knows probably more about OGC conformance? I'll also cc to JTS list. cheers, stefan PS: the Multi-polygon: MULTIPOLYGON ((( 80 125, 80 241, 175 241, 175 125, 80 125 )), (( 175 125, 175 241, 263 241, 263 125, 175 125 ))) Am 08.04.13 09:48, schrieb Uwe Dalluege: Hi Stefan, I am afraid I do not understand :-( Do you think this is a bug in OJ? The multipolygon causes an error the geometrycollection not. Is this behaviour OGC-conform (simpel features...)? What do you think? uwe Am 08.04.2013 16:36, schrieb Stefan Steiniger: Hi, so - well the situation is not so nice, as it should be valid. However, the JTS TestBuilder says the Multi-Polgyon is invalid because of Self-intersection at or near point (175.0, 125.0, NaN) Same message appears when you try to add it as a new feature. maybe you can make it valid before by running a zero-buffer over it? stefan Am 08.04.13 07:30, schrieb Uwe Dalluege: Hi, if you put a third geometrie to the two polygons, for instance a linestring, and combine them you will receive a geometrycollection and not a multipolygon. The geometrycollection causes *no* errors but the multipolygon. Uwe Am 08.04.2013 12:05, schrieb Uwe Dalluege: Hi, I get the error: The new geometry is invalid. Cancelled. and I am not shure whether this error is correct. 1. Switch Snap to vertices option. 2. Draw a rectangle. 3. Draw a second rectangle with two identical vertices from the first rectangle (with snap). 4. Select the two rectangles and Combine Selected features 5. Try to move this multipolygon with Move Selected Items Tool. 6. The error appears The new geometry is invalid. Cancelled. 7. The QAValidate Selected Layers... causes a self-intersection in *one* point. Is this a bug in OJ (a precision-problem) or is the new geometry really invalide? Uwe -- Minimize network downtime and maximize team effectiveness. Reduce network management and security costs.Learn how to hire the most talented Cisco Certified professionals. Visit the Employer Resources Portal http://www.cisco.com/web/learning/employer_resources/index.html ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel -- Minimize network downtime and maximize team effectiveness. Reduce network management and security costs.Learn how to hire the most talented Cisco Certified professionals. Visit the Employer Resources Portal http://www.cisco.com/web/learning/employer_resources/index.html ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel -- Minimize network downtime and maximize team effectiveness. Reduce network management and security costs.Learn how to hire the most talented Cisco Certified professionals. Visit the Employer Resources Portal http://www.cisco.com/web/learning/employer_resources/index.html ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] The new geometry is invalid. Cancelled.
As Michael and Stefan point out, Polygons in a MultiPolygon must be edge-disjoint (which another way of stating the formal definition must only touch at a finite number of points. If they touched along an edge, that would cause an infinite number of points to be coincident). Another way of looking at this is that MultiPolygons are in a sense the canonical description of a given area of the plane. If edge touches or overlaps were allowed then there would be an infinite number of geometries which described the same area. Also, from the point of view of computing polygon overlay and spatial relationships this is a nice rule to have, since it reduces the number of cases which need to be checked for. This makes the code simpler and more performant. The cost is that it is necessary to ensure that MultiPolygons are valid at creation time. This is a reasonable tradeoff, since in general geometries are queried more often than they are created. GeometryCollections on the other hand have no particular semantics - they are just bags of geometries. This makes them useful for holding arbitrary sets of geometries, but makes them more complex (and sometimes slower) to process. On 4/8/2013 11:04 AM, Michaël Michaud wrote: Hi Uwe, Stefan, OpenJUMP (JTS) is right, this MultiPolygon is not OGC conform Here is the citation : Multipolygon 2. The Boundaries of any 2 Polygons that are elements of a MultiPolygon may not ‘cross’ and may touch at only a finite number of points. (Note that crossing is prevented by assertion 1 above). Don't ask me why, I've always thought it is strange that lines can share their boundaries in a MultiLineString and polygons cannot share an edge in a MultiPolygon, but it's a well established rule that JTS follows. Michaël Hi Uwe, I am not sure I would call it a bug. OJ, should (try to) create data that are OGC conform, but in this case it doesn't. Which means, the case needs special treatment, but this is not implemented. That the multi-polygon causes an error is with the OGS SF specification = correct. However, that the geometry collection does not cause an error should be correct aw well, because there is, I believe, nothing said about geometry collections and their validity. Geometry collections should be allowed to have any type of geometries in what ever way they are drawn - like a container. If we would check geometry collections for their validity it may be that people cannot store anymore the data they have. Hence, checking should be optional. But I guess here, Michael M. knows probably more about OGC conformance? I'll also cc to JTS list. cheers, stefan PS: the Multi-polygon: MULTIPOLYGON ((( 80 125, 80 241, 175 241, 175 125, 80 125 )), (( 175 125, 175 241, 263 241, 263 125, 175 125 ))) Am 08.04.13 09:48, schrieb Uwe Dalluege: Hi Stefan, I am afraid I do not understand :-( Do you think this is a bug in OJ? The multipolygon causes an error the geometrycollection not. Is this behaviour OGC-conform (simpel features...)? What do you think? uwe Am 08.04.2013 16:36, schrieb Stefan Steiniger: Hi, so - well the situation is not so nice, as it should be valid. However, the JTS TestBuilder says the Multi-Polgyon is invalid because of Self-intersection at or near point (175.0, 125.0, NaN) Same message appears when you try to add it as a new feature. maybe you can make it valid before by running a zero-buffer over it? stefan Am 08.04.13 07:30, schrieb Uwe Dalluege: Hi, if you put a third geometrie to the two polygons, for instance a linestring, and combine them you will receive a geometrycollection and not a multipolygon. The geometrycollection causes *no* errors but the multipolygon. Uwe Am 08.04.2013 12:05, schrieb Uwe Dalluege: Hi, I get the error: The new geometry is invalid. Cancelled. and I am not shure whether this error is correct. 1. Switch Snap to vertices option. 2. Draw a rectangle. 3. Draw a second rectangle with two identical vertices from the first rectangle (with snap). 4. Select the two rectangles and Combine Selected features 5. Try to move this multipolygon with Move Selected Items Tool. 6. The error appears The new geometry is invalid. Cancelled. 7. The QAValidate Selected Layers... causes a self-intersection in *one* point. Is this a bug in OJ (a precision-problem) or is the new geometry really invalide? Uwe -- Minimize network downtime and maximize team effectiveness. Reduce network management and security costs.Learn how to hire the most talented Cisco Certified professionals. Visit the Employer Resources Portal http://www.cisco.com/web/learning/employer_resources/index.html
