Feature Classes
features.png

Scope

The Domain package has interfaces and implementations that do not depend on an underlying geometry — it is simply an abstract network where a Segment is an edge and the Node is a vertice. The classes and interfaces outside the Domain package are specific to the JTS Library for the specific implementation for ClueRide.

In addition to testability and the advantages offered by interfaces, the purpose of this separation was two-part:

  • Make the dependencies between packages/projects more clear.
  • Avoid carrying around more information than was necessary for a particular job.

Notes regarding Instantiation

There are a handful of Use Cases for the Developer actor which are significant:

  • Constructing Feature Implementations from a underlying SimpleFeatureImpl that had been constructed using the FeatureBuilder (often when reading the instance from storage)
  • Constructing Feature Implementations from instances already sitting in memory.
  • How to assign unique IDs to instances in the following cases:
    • Bring in from an external source (Tracks for example)
    • Bring in from a permanent store where IDs have already been assigned and persisted (Network Segments for example)
    • Create from hand-entered data (Test cases)
    • Create from derived data (split or portion of an existing Feature)

Further detail is found on the page Feature Instantiation.

Constructing from Feature attributes

The first is able to pull values from reading directly from the DB or JSON store. The constructors only need to accept the fully populated SimpleFeatureImpl since it already has the Domain-specific properties embedded as attributes. The implementation classes perform a couple of roles:

  1. Exposing the attributes as instances.
  2. Building up Domain implementations where appropriate for performance.

Construction from class instances

Here we have values supplied by a Geometry and a Domain-specific instance. For instance, we may already have a LineString that was built by reversing and splitting out a section of a Track that had been read from the JSON store. This LineString hasn't yet acquired any of the Domain-Specific attributes such as an ID or a name. In this case, our constructor would accept the Geometry (the LineString) and a populated instance of the appropriate Domain object (TrackImpl). Together, these two can be used to assemble an appropriate SimpleFeature instance that holds both the Geometry and the domain specific properties.

It isn't always clear which approach is best for a given circumstance and providing a different implementation is an option available to the designer.

Notes regarding State Mapping

Wanted to collect the decisions before implementing, so here they go:
- ON_NETWORK => ON_NODE
- WITHIN_GROUP => ON_NODE (tentative pending decisions regarding the PointFeature / GeoNode implementations)
- ON_SEGMENT => ON_SEGMENT
- ON_SINGLE_TRACK => multiple
- ON_MULTI_TRACK => multiple; represented by more than one recommendation in a list
- OFF_NETWORK =>

Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License