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 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
>
>


------------------------------------------------------------------------------
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

Reply via email to