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 (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 QA>Validate 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 >>>>>>>>> >>>>>>>>> ------------------------------------------------------------------------------ >>>>>>>>> >>>>>>>>> >>>>>>>>> >> >> > ------------------------------------------------------------------------------ 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
