Track-based Network Proposal

When a new location is being added to the network, both the existing network and a list of GPX-sourced "Tracks" are considered for potential connections to the network. For those locations not already on the network, but covered by a Track, we evaluate and score those tracks for appropriate Edges to recommend. This describes that procedure.

Criteria

Here are significant attributes that are evaluated:

  • Are there Tracks which "cover" the point being added?
  • Of the covering Tracks, which ones bring you to existing edges or nodes on the network? Which are "connecting" Tracks?
  • Is the track "Intersecting" or "Crossing"?
  • Does the connecting Track reach the network traveling only in one direction or in both directions?
  • For Tracks that intersect more than one segment and/or node, which segment/node is chosen to represent the connection?
  • Does a connecting Track reach an Edge or a Node?
  • If there are more than one connecting Track, which one is preferred? How do we rank the Track recommendations?
  • If there are more than one connecting Track, would we want to add more than one at a time?
  • If a single-source Track connects on both ends, it would score higher than singly-connected source tracks.
  • Shortest distance is a tie-breaker.
  • It may be possible to only evaluate those Tracks which have connections to the network already instead of performing this calculation at the time a location is provided. For this reason, we may find Connecting Tracks without having to cull a list of Covering Tracks.

High-level Steps

This assumes we haven't pre-evaluated the tracks to see which ones get us to the network.

  1. Obtain a list of Covering Tracks.
  2. From that list, prepare the Connecting Tracks. This involves splitting the tracks into the two tracks that depart the new location and travel to either end of the Track, and checking each. Only the Connecting portion needs to be retained for further steps.
  3. For each Connecting Track, prepare an OnTrack NetworkRecommendation. There are five choices of sub-type:
    1. ToNode
    2. ToSegment
    3. ToSegmentAndNode
    4. ToTwoNodes
    5. ToTwoSegments

Details on Specific Steps

Discussion points

  • What performs the iterating across the Track's network connections to find the shortest? Currently have the GeoEval doing this per LineString which was split from a Track. It finds the connections, so perhaps it does make sense that it evaluates them based on the distance. What I don't like is it has become aware of the "TrackConnection" class. I'd prefer the service class take results from GeoEval and plug them into the builder for assembling the Track Connection. Looks like more expansion of the Service responsibilities.
  • What records the Splitting Node for network connections on an Edge? Choices are TrackConnection and the RecommendationBuilder. Part of this decision depends on what the GeoEval will be doing as it finds a crossing/intersection. It looks like I'm leaning toward a "servicy" sort of class that asks GeoEval for the Geometry help, but leans on the RecommendationBuilder to record the values we assemble for the recommendation. TrackConnectionBuilder might be something like what we want: hold some info, apply some logic to produce a result. Not clear though that I want GeoEval and Builders to know about each other. More "servicy" than what Builder does: collect DTOs and crank the Factory.
  • DefaultNetwork.proposeSegmentFromTrack() still has a lot of the work defined there.
  • What interface on the RecommendationBuilder would support this?
  • Looking like the approach is to break up the NewLocBuilder into stuff that leans on the RecommendationBuilder and stuff that leans on another service. TrackService? NetworkService?
  • Keep in touch with the Node Eval structure.

Some Decisions

  • For Single Rec, will keep what we've got since it returns directly from LocationService.
  • For Multi Rec, still swimming in this, but don't need another class just yet.
  • There are tons of stuff in the crMain project that are specific to Network Building, so I've got a com.clueride.service package under that project, but not yet ready for a Service project.
  • May go with evaluating each pair according to something that bundles up what we've got coming out of GeoEval at this level. A builder may be able to crunch on this.
    • Node Match
    • Distance to see what's close
    • Edge Match
    • Distance again
    • Proposed Splitting Node
  • An alternative I'd like to consider is finding the closest of each and running with that per track. A lot of the data I was carrying around was intended to compare track to track — and we do want to rank them — but narrowing down this way will help manage the complexity.

Splitting a Track

Tracks can usually head in one of two directions away from the new location. Each must be evaluated separately, but together, the two directions with their connections would be scored against other tracks with their one or two connections. The TrackEval class keeps the details for one direction. The TrackRecBuilder holds together the two TrackEvals for a given Track. The LocationService runs through the Tracks and asks TrackRecBuilders to do the work.

Track which Connects multiple times in a single direction

It is possible for a candidate track to intersect/cross the network at multiple points for a single direction. General rule is to take the shortest distance connection.

NodeNetworkState structure

Responsibility for Setting the Node Network State

Points:

  • Currently, it's the GeoNode newLoc that carries the Network State enum over as part of the Feature that is returned to the client. We probably want to improve this, but it's what we've got right now.
  • For the On Network choices, this state is baked into the recommendation. It's a single value that uses the existing channel for communicating with the client.
  • For the track-based recommendations, we're computing this at the LocationService level, but it's something that the NetworkProposal implementation could handle. The question is "should it?"

Currently, we have the following:
<pick up from the code>

Diagrams

Interaction Diagram for creating a NetworkProposal from a New Location

construction-seq.png

Class Tree for NetworkProposal and the sub-types of Recommendation

newLocRec.pngdeprecated:
construction-collab.png

Move to new page

Turn lat/lon into New Location

These are currently inside the LocationService, but we could possibly get more specific and re-usable with the code inside that service. Details in the addNewLocation() method.

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