Requirements exploration - routes

[Brad Hards]

In the context of GeoPackage, is the Routes element intended to be a simple
linestring, or something more complex?

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

[Scott C]

This sounds like we're going down the road of a data model.  I think what we really want is the storage container that can accomodate the geometries.  Those geometries may be routes, power lines, etc, but the attributes should describe those geometries.

[Brad Hards]

On Monday 12 March 2012 12:41:23 Scott C wrote:
> This sounds like we're going down the road of a data model. I think what
> we really want is the storage container that can accomodate the geometries.
> Those geometries may be routes, power lines, etc, but the attributes
> should describe those geometries.

So to you, a route is just another geometry of linestring type. It doesn't
need to curve, have altitude, fly-by / fly-over or whatever other attributes?
I'm not saying it should or shouldn't. I just want to understand what you
want. I'm not trying to describe a data model, or a container. I'm not trying
to critique the requirements.

I'm just trying to understand what, if anything, is different between a route
and any other linestring vector in the GeoPackage container.

Brad

[Birkel, Paul A.]

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.

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 :->.

[Scott C]

On Monday, March 12, 2012 3:34:08 AM UTC-4, pbi...@mitre.org wrote:

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.

Also agreed, but in many cases users only care about the route once it has been calculated, and not the graph.  Also, as Brad points out, a route needs to have the ability to carry altitude - which is a characteristic all of the line geometries need to support.  In fact we should be able to apply whatever attributes we need to any line geometry.  Not all applications are solely in 2D space.

 

[3. A route does not self-intersect :->!]

They don't self-intersect anymore than lines would but they do overlap.  In calculating routes, sometimes you have a waypoint that can only be reached by going down a segment, making that stop and then coming back out that segment (resupply or delivery as an example).  Also, from flying reconnaissance, I can tell you that air tracks can loop back on themselves.

 

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 :->.

If we simply support lines in 3D space doesn't this problem take care of itself?  In routing applications, connectivity in the case you outline is handled by assigning nodes/junctions on the graph.  for an overpass there is no node where the underpass crosses.

In essence, I'm questioning why routes have to be a special case.  They don't get treated as a different geometry type in any GIS I've used.  When we implemented routing for ERDC/AGC, we didn't have to do anything special with line geometries to represent a route.  The graphs are what is truly unique.  Simply allowing storage of 3D characteristics on geometries, along with attribute fields, such as time, distance, ID, etc. allows for all sorts of great applications in temporal and spatial context.  

[Jeff Yutzler]

On Mon, Mar 12, 2012 at 9:11 AM, Scott C <scott...@lmnsolutions.com> wrote:

In essence, I'm questioning why routes have to be a special case.

I'm not sure how we ended up here either.  Routes were explicitly mentioned in early versions of Paul D.'s GeoPackage Specification document, but were taken out later.  Here is the current version of the graphic:

--
Jeff Yutzler
Image Matters LLC
Mobile: (703) 981-8753
Office: (703) 428-6731

[Birkel, Paul A.]

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

 

[Nathan]

I removed the routes from the said graphic. I view routing as a
requirement for the package but not as a separate entity of the
GeoPackage ( I could be wrong..). To my understanding the ability to
store a network would require no more than the vector specification we
are trying to outline here. (Again, I could be wrong).

We have successfully implemented spatialite routing on Android using a
VirtualNetwork and custom built networks. This type of functionality
is what we are looking for and the fact that spatialite already has
this capability is another reason we have pushed it as a reference
spec.

- Nathan

On Mar 12, 9:38 am, Jeff Yutzler <je...@imagemattersllc.com> wrote:

>  image.png
> 11KViewDownload

[Scott C]

What I'm saying is that the storage of the geometry for a route shouldn't be any different from storing that of any other line or point geometry.  The issues of methods of storing coordinates and conversions doesn't change that.