Clue Ride Geo Classes

Related Pages

Feature Classes
geoSvcDom-explore.png
This was explored using a handful of open source software packages:
  • Leaflet.js for the map presentation
  • angular-leaflet-directive for an AngularJS wrapper
  • Geotools and particularly the JTS topology suite for turning tracks into GeoJSON files.

High-Level Packages

ID Package Description
Encoder What we've been using to take GPX files and turn them into objects the Google Maps API was able to use.
Business Domain Objects on the map that game players and game developers will interact with
Geometry Objects on the map as handled/persisted by the Geotools software mentioned above. Attempts to standardize on what other people are using, and also leverages existing libraries.

The Business Domain package contains a more restricted set of classes/objects that players would interact with (called "User Domain").

Classes

Start with the User Domain and work our way to more technical classes.

User Domain

ID Class / Interface Description
Location This is a point of interest on the map. It could be the player's starting point, current location, destination, Clue, or interesting things to visit on the way to a Clue or destination. It is represented underneath by a Node which is discussed in more detail below.
Path A route between two locations whose characteristics are determined from the sequence of segments making up the path. Paths intersect each other to form the network.
DeadEnd If the Location is at the end of a path that is out-and-back, it's helpful for the user to know the path will dead end at the location.

Business Domain (Game Developer Classes)

ID Class / Interface Description
Node This supports Locations, and implements the interface which describes how to work with a PointFeature. There are a number of subclasses of Node.
Vertice This Node is an intersection point for Segments so they can be sequenced to form a Path. Two segments which are able to be traversed will have endpoints in common. That common endpoint is the Vertice.
FalseVertice The topology tools are pretty much 2D, so they don't really represent bridges and tunnels where two Segments would cross, but there is not an intersection. The common point shared by two segments cannot be traversed and that's what makes it a FalseVertice.
UnconnectedNode There will be points on the map which are not reachable by the network we've captured. If we want to reach an UnconnectedNode, we need to add a Segment from one of the other Nodes which is part of the network.
PointFeature In addition to the geometrical aspects of representing a Node (Lat/Lon for example), there is an ID, and perhaps other properties such as name, description, website, or Clue that make this Node a Feature. The PointFeature interface describes the pieces/parts that make up the full Point/Feature geometrical object.
ReportedFeature There are instances of both PointFeature and LineFeature that we'll want to place on the map that represent problems uncovered by the JTS validation. The ReportedFeature carries additional data regarding the specific problem.
Segment This supports Paths and potential paths, by representing the string of Lat/Lon pairs that correspond to following trails, roads, cut-throughs, or whatever to get from one point to another. That Segment will have a Facility Type which is scored according to certain characteristics of that Facility. Essentially, the score is used to calculate preferences of one Path over another between two Locations/Nodes.
UnratedSegment This is a Segment whose Facility information is incomplete.
RawPath This is a sequence of Lat/Lon pairs (often captured via a GPX file) that has not yet been mapped to Segments in our network. Some of the Lat/Lon pairs will map to existing Segments and others will not. The RawPath can be represented exactly as the GPX shows it or as a mixture of Segments and ReportedFeatures
LineFeature Just as a PointFeature combines geometrical and non-geometrical properties for a Node/Location, the LineFeature does the same for Segments.

Geometry

As mentioned above, these were explored using a specific set of software libraries.
ID Class / Interface Description
DeadEnd

Notes

  • Thinking that the Segment can include the existing Encoder package's Track
  • A set of Trackpoints appears to be sufficient for carrying around the info we need (includes elevation and distance calculation. Missing slope related info at this time)
  • The Node should be limited to the connections points — the start/end of a Segment.
  • Business rule should be that each segment begins and ends at a Node, but to draw the Segment, we won't need the "canonical" Node. This is to facilitate joining of segments using indices instead of lat/lon pairs (integer surrogate keys instead of a pair of doubles).
Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License