This pull request includes changes to implement the proposal from issue #45 for real-time updates to each object's "bounding box". Along the way, it also adds a bit more unit test coverage to the existing classes.
Approach
An abstract calculateBounds() method has been added to GeoJsonObject and implemented in each subclass. This method recalculates the bounding box around whatever coordinates are stored within the object. The method may be called explicitly, but it is also called by each method in each GeoJsonObject implementation which sets the object's geometry. This ensures that the value of the bbox class member is always up-to-date, even if the object's geometry changes over time. Since the base class's equals() method considered bbox in its requirements for equality, this was necessary to ensure that practically equal objects were programmatically considered equal.
For any geometric object that represents a single shape, the object recalculates its bounding box from scratch, each time it is modified. However, for any object that represents a list of shapes, or a list of points that define a shape, the object accumulates bounding box statistics with each additional member. This is an attempt to improve the overall performance of the realtime update mechanism as much as possible.
Consequences
There will likely be a slight performance hit because of the overhead of calculating this bounding box for each object. However every attempt has been made to minimize this in the algorithm used.
In order to prevent unintended rendering of the bbox member in JSON serializations, a @JsonIgnore annotation has been added to the accessor/mutator for this field in GeoJsonObject. (Without this annotation, once the bounding boxes were updated with non-null values, some previous unit tests began to fail.)
Alternatives
As an alternative implementation, we could provide the calculateBounds() methods as a utility, but remove the consideration for the bbox member from all equals() methods. This would remove the need to keep bbox updated in realtime.
Testing
A set of jUnit tests has been added to meaningfully each of the calculateBounds() methods. All existing unit tests also pass.
Disclaimer
"Derpy" in the second commit comment is me admonishing myself for not checking my work the first time. :blush: :laughing:
This pull request includes changes to implement the proposal from issue #45 for real-time updates to each object's "bounding box". Along the way, it also adds a bit more unit test coverage to the existing classes.
Approach
An abstract
calculateBounds()method has been added toGeoJsonObjectand implemented in each subclass. This method recalculates the bounding box around whatever coordinates are stored within the object. The method may be called explicitly, but it is also called by each method in eachGeoJsonObjectimplementation which sets the object's geometry. This ensures that the value of thebboxclass member is always up-to-date, even if the object's geometry changes over time. Since the base class'sequals()method consideredbboxin its requirements for equality, this was necessary to ensure that practically equal objects were programmatically considered equal.For any geometric object that represents a single shape, the object recalculates its bounding box from scratch, each time it is modified. However, for any object that represents a list of shapes, or a list of points that define a shape, the object accumulates bounding box statistics with each additional member. This is an attempt to improve the overall performance of the realtime update mechanism as much as possible.
Consequences
There will likely be a slight performance hit because of the overhead of calculating this bounding box for each object. However every attempt has been made to minimize this in the algorithm used.
In order to prevent unintended rendering of the
bboxmember in JSON serializations, a@JsonIgnoreannotation has been added to the accessor/mutator for this field inGeoJsonObject. (Without this annotation, once the bounding boxes were updated with non-null values, some previous unit tests began to fail.)Alternatives
As an alternative implementation, we could provide the
calculateBounds()methods as a utility, but remove the consideration for thebboxmember from allequals()methods. This would remove the need to keepbboxupdated in realtime.Testing
A set of jUnit tests has been added to meaningfully each of the
calculateBounds()methods. All existing unit tests also pass.Disclaimer
"Derpy" in the second commit comment is me admonishing myself for not checking my work the first time. :blush: :laughing: