Details
-
Type:
Improvement
-
Status:
Open
-
Priority:
Major
-
Resolution: Unresolved
-
Affects Version/s: 1.0, 2.0
-
Fix Version/s: None
-
Component/s: geometry
-
Labels:None
Description
In GeoAPI 1.0, geometries are immutables. Some applications need mutables geometries, since reconstructing a whole geometry for a change in only one point (for example) is not always pratical. Some other application requires immutable geometries, for example a display could become out of synchronisation if a geometry changed without renderer knowledge. There is different ways to provide that:
1) Provide listeners
2) Provide mutable and immutable views of geometries either through:
a) optional setFoo(...) methods, which may thrown an
UnmodifiableGeometryException;
b) Some kind of ReadAccess and WriteAccess interfaces. For example
basic geometry interfaces could be immutable, with a
"ModifiableFoo" subinterface for each of them.
I see that the Geometry interface in the GeoAPI 2.0 release has the isMutable() and toImmutable() methods. Does this JIRA task refer to a somewhat more complicated support mechanism?
The out-of-synchronization issue is not necessarily related to immutability. A mutable geometry requires the use of NotifyingCollection interfaces (NotifyingSet, NotifyingList), defined to fire events when elements are added or deleted. GeoAPI could define the event/event listener to be used, as well as the required extensions to the Collections framework. So I guess we could either fix the synchronization problem by providing for immutability or setting up an extension to Collections.