Can you post the polygon and the simplification tolerances? And which
simplification algorithm were you using?
This could be a bug, of course.
AFAIK, there's no standard about what should be returned by
simplification in limit cases. I can imagine several possible
requirements, all of which I can see be wanted in different situations:
1. return an empty geometry of the same dimension as the input
2. return a "minimal" geometry of the same dimension as the input (e.g.
return a triangle at the limit of simplifying a polygon) (Some systems
have constraints of the type of geometry they can accept, and/or expect
the same type for the result as for the input)
3. return a line segment as you suggest
4. return an empty GEOMETRYCOLLECTION, signifying "null result"
It might be nice to provide a flag to let the user choose his desired
behaviour.
BTW, the semantics of TopologyPreservingSimplifier are more precisely
defined - it follows #2.
Theodor Foerster wrote:
Hi,
I came across a polygon, which I need to simplify. The result is an
empty GeometryCollection. However, when I choose a smaller tolerance
value, it performs correctly. Is this behaviour intended? I am just
curious. Intentionally, I would think, that the result is a line with
two points in the worst case.
Theodor
ITC, Enschede
Department of Geo Information Processing PO. Box 6 7500 AA Enschede the
Netherlands
International Institute for Geo-Information Science and Earth Observation (ITC)
Chamber of Commerce: 410 27 560
E-mail disclaimer
The information in this e-mail, including any attachments, is intended for the
addressee only. If you are not the intended recipient, you are hereby notified
that any disclosure, copying, distribution or action in relation to the content
of this information is strictly prohibited. If you have received this e-mail by
mistake, please delete the message and any attachment and inform the sender by
return e-mail. ITC accepts no liability for any error or omission in the
message content or for damage of any kind that may arise as a result of e-mail
transmission.
_______________________________________________
jts-devel mailing list
[email protected]
http://lists.refractions.net/mailman/listinfo/jts-devel
--
Martin Davis
Senior Technical Architect
Refractions Research, Inc.
(250) 383-3022
_______________________________________________
jts-devel mailing list
[email protected]
http://lists.refractions.net/mailman/listinfo/jts-devel
