Some of the planning tools allow calculated routes (e.g. with time, fuel,
weight, etc) based on performance models of different "vehicles". Some allow
each segment of the route to use a different vehicle (e.g. these route segments
are the aircraft move, the next segment is a wheeled vehicle, the next
segments are on foot, etc). Some allow non-linear legs (arcs, serpentines).
Some allow routes to split.
What are routes intended to be used for? Upload to a nav system / GPS?
What features / fidelity are required for a route?
Is the GeoPackage API required to do any route calculations or is it more of a
store / retrieve capability?
I'm assuming multiple routes per GeoPackage. Any need for dependencies between
routes?
Brad
I'm just trying to understand what, if anything, is different between a route
and any other linestring vector in the GeoPackage container.
Brad
1. Composition -- a route is a set of 1 or more curves plus 2 or more points; the points establish the starting-place, destination, and any specified waypoints. The curves establish the path(s) between the start/end and any included waypoints.
2. Connection -- a route is a completely connected set of components that form a single continuous path; there are no disconnected components. Usually this implies that at some stage of processing the "route" has been represented as a 2D topology of nodes and edges, however it's not necessary that the node-edge topology be used for information exchange so long as the geometry of each component is exact and coordinate-equality can be used to assert/determine connectedness.
[3. A route does not self-intersect :->!]
Note that this definition for a "route" (particularly the use of coordinate-equality as a test for connectedness) is a simplification that assumes a 2D world where roads that cross over-under are still "connected". That's not a good simplification, but at least this description gets at the (IMO) fundamental principles :->.
IMO, a "route" introduces two functionalities not shared by a "simple" linestring:1. Composition -- a route is a set of 1 or more curves plus 2 or more points; the points establish the starting-place, destination, and any specified waypoints. The curves establish the path(s) between the start/end and any included waypoints.
Agreed.
2. Connection -- a route is a completely connected set of components that form a single continuous path; there are no disconnected components. Usually this implies that at some stage of processing the "route" has been represented as a 2D topology of nodes and edges, however it's not necessary that the node-edge topology be used for information exchange so long as the geometry of each component is exact and coordinate-equality can be used to assert/determine connectedness.
[3. A route does not self-intersect :->!]
Note that this definition for a "route" (particularly the use of coordinate-equality as a test for connectedness) is a simplification that assumes a 2D world where roads that cross over-under are still "connected". That's not a good simplification, but at least this description gets at the (IMO) fundamental principles :->.
In essence, I'm questioning why routes have to be a special case.
Glad to hear that just storing the coordinates has worked for you. Because of the vagaries of moving coordinates between different platforms using different libraries I’ve seen small discrepancies be introduced that results in loss-of-connectivity without introducing a fudge-factor to “re-snap” coordinates to assumed equality. What is acceptable for visualization (“looks close enough”) isn’t necessarily acceptable for “blind” algorithms. Until we can enforce one representation, one encoding, one conversion library, etc. we’ll continue to see the sorts of problems arise. One joy that can’t be avoided is that XML-based encodings use fractional decimal values but binary data storage is, well, binary (powers of 2) and therefore there is an inexact relationship between xml-decimal and internal-binary. E.g., 0.1 is an infinite-length number in binary …
From: geospatial-mobile-da...@googlegroups.com [mailto:geospatial-mobile-da...@googlegroups.com]
On Behalf Of Scott C
Sent: Monday, March 12, 2012 9:12 AM
To: geospatial-mobile-da...@googlegroups.com
Subject: Re: Requirements exploration - routes