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 > Options>View/Edit>Prevent 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 > > Options>View/Edit>Prevent 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 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 >>> <mailto:Jump-pilot-devel@lists.sourceforge.net> >>> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel >>> >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> 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 >> >> >> >> ------------------------------------------------------------------------------ >> 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 >> > > ------------------------------------------------------------------------------ > 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 > ------------------------------------------------------------------------------ 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
