DB Design for a Course

This describes a sequence of Locations and Paths connecting those Locations to form a Course. There are two structures, both described here as Json objects.

  1. As part of Game State, a sequence of locations and paths are strung together. There may be options along the way. Not yet clear how I want to represent these since it is still being explored, but eventually, the structure should accommodate substantial latitude in choosing your direction at any given Location. The main constraint is to arrive back at the original departure point to form a loop. Even this constraint however, may eventually be opened up to allow for point-to-point courses.
  2. For presentation on a map, a GeoJson object (Feature Collection) also supplies the structure for following a course.

Game State Representations

There are also a couple of representations for tracking Game State:

  1. Sequence of Paths where the locations are determined from those paths.
  2. An array of alternating locations and paths where
    • odd indices indicate a location and
    • even indices indicate a path.

Persisted Representation


  1. Support Outing View
  2. Support static Course (single path from start to destination)
  3. Support Multi-Path Courses

Supporting OutingView

This is the set of data that is required for a first cut at the Course:

  • ID
  • Name
  • Description - one liner
  • URL - Link back to the Course Page
  • Start Location - Provides the LatLon for a "Start Pin"

Course Type ID is probably covered by the Description.

Supporting Static Courses


Multi-Path Courses

As a first cut, Courses are stored on disk as JSON files. A few criteria:

  • Human readable names for Locations. Index can be checked upon reading the Names using the Course Editing Tool.
  • Paths between Locations can be recorded as an ID. Note that when a Course is constructed, to avoid sensitivity to changes in the underlying network, the exact LineString geometry object is constructed and recorded under an immutable object written to the File Store for Paths. If a Path within the Course changes, a new Path will replace the old one.
  • It would be possible to store a score for the Path along with the LineString, although applying Profiles would require recalculating that score from the underlying Segments.
  • There may be more than one Path between two locations. These are recorded as an array of Path IDs.
  • There may be more than one "Next Location" for a given location.
    • This array is dependent on the "Loop" — particularly the original departure location and other location selections along the way (will we hit a market before arriving at the picnic destination, for example).
    • It seems whatever divergence of path choice occurs, the constraint to close the loop will provide convergence — fewer and fewer route options will remain available.
    • Choices will be easier to provide and sequence if they are similar in type. Public Art should be easy to accommodate, for example, as way-points on our way to a final destination. Two parks would provide choices for a picnic location given the market has already been reached.
Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License