PGN 129285: Route/WP Information

[timmathews]

The current implementation of 129285 provides the following mapping:

• 8, Route Name: ~/navigation/currentRoute/Name
• 11, WP Name: ~/navigation/currentRoute/waypoints/[n]/name
• 12, WP Latitude: ~/navigation/currentRoute/waypoints/[n]/position/latitude
• 13, WP Latitude: ~/navigation/currentRoute/waypoints/[n]/position/longitude

where [n] specifies a position in an array of waypoints. These paths don't exist in the schema. Maybe this is a schema issue as well, but even if it is, route and waypoint definitions belong in /resources, not ~/navigation. There should however be a pointer from ~/navigation/activeRoute to the route definition in /resources.

The current design of /resources/routes specifies start and end waypoints, but AFAICT intermediate waypoints are to be specified with a GeoJSON line object.

A more compliant mapping would probably look something like this:

• 8, Route Name: /resources/routes/«uuid»/name
• 10, WP ID: /resources/waypoints/«uuid»/id
• 11, WP Name: /resources/waypoints/«uuid»/name # This doesn't exist yet
• 12, WP Latitude: /resources/waypoints/«uuid»/position/latitude
• 13, WP Longitude: /resources/waypoints/«uuid»/position/longitude

Fields 10 - 13 repeat for each waypoint in the PGN. Fields 12 and 13 may also get mapped to /resources/waypoints/«uuid»/feature/geometry/coordinates which is an array: [longitude, latitude].

[rob42]

More compliant with n2k or a better way to handle routes/tracks?. The big advantage of geoJson is the flexibility. It can be edited with std web tools, converted to/from useful sources, and overlaid on charts easily. Plus it handles complex shapes, regions, and polygons. The n2k format can be easily translated to a geojson line, either to a series of waypoints joined with geojson straight lines, or just skip the intermediate waypoints and store a wiggly geojson line.

It would be much harder if we adopt n2k formats, and need to translate lines all the time, and then use geoJson for regions, polgons etc.

[timmathews]

Given a GeoJSON route, how do you reference waypoints in /resources/waypoints? Or perhaps more concretely, given a route received via n2k what does it look like translated into GeoJSON?

[sbender9]

I guess I missed the resources stuff when I was implementing this.

Are we missing in the spec some way to show that this is the route that we're currently following?

Are these messages only used for the current route? That's what I see from my Raymarine stuff and they only give last waypoint and the next two.

Seems like uuid is going to be hard to deal with here..

Anyone have any sample data for this. All I have are examples from boat.

[rob42]

@timmathews I implemented routes and tracks in freeboard-sk. I found the simplest way was to define a route as a geojson line feature that connected two waypoints.

A route therefore has a start and end which is defined (badly) as a wayoint UUID

...
 "name": {
              "type": "string",
              "description": "Route's common name",
              "example":"Nelson Harbour to Adele Is"
            },
            "description": {
              "type": "string",
              "description": "A description of the route"
            },
            "distance": {
              "description": "Total distance from start to end",
              "type": "number",
              "units": "m"
            },
            "start": {
              "type": "string",
              "description": "The waypoint UUID at the start of the route"
            },
            "end": {
              "type": "string",
              "description": "The waypoint UUID at the end of the route"
            },

The first and last points in the geojson line will also have the same lat/lon as the start/end waypoints

It would be nice to have a 'foreign key' facility between waypoint uuid and start end here, but json doesnt do that. You can store additional data in a geojson feature in the properties if you need to.

[rob42]

For the route above I have two waypoints (Nelson, and Adele Is) and a complex line that avoids shallows, fish farms, and takes me through a pass to the anchorage :-)

[tkurki]

That’s all well and good that you have that track, but how does it help us forward?

It looks to me that we should support the traditional route as an ordered list of waypoints and route as a track views. If you plan a track, on paper, navigation application or mfd, it is usually the waypoint kind. If you ’save’ it off a track it will be the track kind. Afaik there are no pgns or sentences for communicating anything but waypoints - everything else is gpx-like export import.

Imho we need to support both of these approaches. Adrian @ Slack is working on gpx integration - we can fuse all the efforts, based on real world data and at the same time be future ready if not proof.

Please remember that we should strive away from thinking about a single representation of the data: we can serve the same route as uuid’d individual waypoints, a list of references to them and a GeoJSON track. And the server can choose to use whatever representation for internal use; gpx files, PostGIS db, whatnot.

[panaaj]

I like the idea of being able to define: 1) a track between two waypoints (a route in the spec) 2) a collection of items described in 1) (a collection of routes )

This could easily be made to align with GPX and more traditional schemas as well as providing the flexibility of having more that just a straight line between two waypoints.

[rob42]

Yes we should support both types, in fact a traditional route is actually an ordered list of simple (straight lines) geoJson routes. So possibly we need a way to store a series of routes or chain routes somehow.

BTW in terms of creating/planning a route its a lot easier to enter start and end as waypoints with a straight line between, then drag the line out around the various obstacles/ intermediate points. Its especially good when you move one point, which then requires an adjustment to a previous point since no actual waypoints need to be moved/recreated. Same for fixing a route later.

[tkurki]

What’s the difference between an actual waypoint and the points that you drag to make the route go around obstacles?

[webmasterkai]

Waypoints should have names and a resource id. Dots to go around obstacles might not necessarily have that and simply be part of a wiggly line.

[tkurki]

I meant more like ’why / what is the conceptual difference’? Why are route endpoints waypoints and not just locations? What if you want to use a waypoint in the middle of a route? Or add special instructions to a hairy passage in the middle of a route?

[timmathews]

The main difference between a point and a waypoint (from my POV) is that a point exists only as part of a route. It doesn't have any meaning on its own. A waypoint on the other hand is a standalone entity with a name and optionally notes or a description which you might incorporate into a route or build a route out of.

That said, we've gotten somewhat far afield of the actual issue here, which is:

• How do we translate this PGN (and the other Route/WP Service PGNs) into the Signal K schema? and
• If the existing schema falls short, what do we need to add?

[timmathews]

As a point of reference, the following PGNs make up the routing service of n2k:

129284: Navigation Data

This is information regarding the current leg of the active route: distance/bearing to waypoint, eta, etc. It's unclear whether origin and destination waypoint in this PGN refer to the first and last waypoints in a route or the previous and next waypoints. I would assume the latter, but I don't know. Regardless, it doesn't have any route identifying information, just origin and destination waypoint IDs and destination waypoint lat/lon.

129285: Route/WP Information

Definition of the active route. Can potentially ID the route database (if the sender has multiple), the route itself, and provides a list of waypoints (ID, name, lat, lon) within the route. Also includes the direction that you are navigating the route (i.e. forward or reverse).

129301: Time to/from Mark

I included this PGN because it can potentially refer to a fixed waypoint.

129302: Bearing and Distance between two Marks

Again, not really a routing PGN, but it can refer to a fixed waypoint by ID.

130064 - 130074: Route and Waypoint Service

Canboat doesn't have any samples of these and I can't find any mention of them in Garmin or Navico manuals, so I am skeptical that they are being used anywhere. If someone has a device that makes use of these PGNs and can provide samples, that would be great.

[rob42]

@tkurki the conceptual difference is that a route between two waypoints can be a wiggly line. This removes the need for hundreds of waypoints. That hugely simplifies the naming and selection of waypoints.

No reason a long route cannot be split into many smaller routes. If you need complex instructions for a geoJson route they can be added to the properties.

The only reason I chose waypoints for the ends of the route was the idea that a route goes from one location to another, and thats how its always been done. On reflection there is no real need to do that.

[tkurki]

Thanks Tim for the list! I thought it fruitful to continue in the context of n2k route pgns, but the issue is really in the spec.

I think talking about wiggly line obscures the fact that it is just an ordered list of positions, not some other data structure. Unless I am mistaken and there is some fancy stuff like Bezier curves and it just obscures my ignorance..

Again mapping real n2k and gpx route data to (Geo)json would be very fruitful: these present some of the real world use cases we should support. Then we can come from the what if there were no pre existing ways for this, what would we do and form a synthesis of these.