OCPN data sharing Focus Group

[bdbcat]

Hello all.

The OCPN development team is working actively on the next release of OCPN, currently scheduled for late this year.
One of the perennial topics under discussion relates to communications between various devices and/or OCPN instances found in a modern electronics suite.

In this thread I'd like to discuss the capabilities to share waypoint, route, and track information between devices. We have seen many, many threads addressing this functionality in the past. Sadly, these threads generally start out by describing a problem faced by a specific use-case. They usually fade away, resulting in no specific actionable feature changes to the OCPN core functionality. So some problems and inconveniences still exist in OCPN.

So I'd like to try a different approach, something of an "online focus group". Here are the "soft rules":

1. Please reply with your specific "wish list" on functionality. Detail on your configuration is good.
2. Comments starting with "I would like to be able to..." are strongly encouraged.
3. Comments starting with "I think people would like to...." are discouraged, and will generally be disregarded. This is what leads a group astray.
4. Of course, your wish list should be within the realm of possibility. No teleportation available, yet.
5. It is OK (and entertaining) to think "outside of the box", if it pertains to your wish-list.
6. Ideas for code implementation methods are not (yet) solicited. We are focused on functionality, first.
6. Please remember, we are talking only about points, routes, and tracks here.

I'll start.

I would like to be able to "sync" routes, points, or tracks between multiple instances of OCPN accessible on a network. The GUI to perform this should be clear and explicit, with no more than two levels of dialog detail, accessible reasonably on a touch screen. As a user, I don't want to know the details of "GUID conflict", whatever that is. I just want it to work about as seamlessly as sending a photo on a social media app.

Bring it on, and let's go!

Thanks
Dave

[PippaB]

Originally Posted by bdbcat

...I would like to be able to "sync" routes, points, or tracks between multiple instances of OCPN accessible on a network. The GUI to perform this should be clear and explicit, with no more than two levels of dialog detail, accessible reasonably on a touch screen. As a user, I don't want to know the details of "GUID conflict", whatever that is. I just want it to work about as seamlessly as sending a photo on a social media app....

For me, you nailed it in one. So, I guess that's an upvote for your suggestion. I can't think of anything else in this regard that I wish OCPN had. The VNC route just isn't pleasant or tenable for me, so being able to share the NavObjs file/data/information in some way per your elegant start would be my #1.

[stevead]

Originally Posted by bdbcat

I would like to be able to "sync" routes, points, or tracks between multiple instances of OCPN accessible on a network.

Please replace the underlying XML file with a proper database that is atomic, supports replication, provides referential integrity and has triggers.
The database is simple, disentangling the OCPN code perhaps not. An opportunity for a clean 3 tier model!

[bdbcat]

Steve...
Point 6, please...

[Be Free]

I would like the option to synchronize the items manually, by schedule, or in (near) real time along with a visual indication that the synchronization is (or is not) up to date.

[RandonneurLibre]

–As an OpenCPN user
–I would like better UI visibility into the meaning of the chart selection buttons at the bottom of the screen
–So that I can select a chart for the given screen without waiting for the app to fully load a potentially unknown chart.

–As an OpenCPN user
–I would like the documentation to be better correlated to the app version and platform
–So that I can more readily accomplish my goals in OpenCPN

–As an OpenCPN user on Android
–I would like the UI to indicate when the application is busy loading charts
–So that I can understand if the app is busy or has frozen.

–As an OpenCPN user using the "Navigate to Here" context menu item
–I would like to be able to add additional routing waypoints after the "Here" point
–So that I may more intuitively modify my route.

[RandonneurLibre]

–As an OpenCPN user
–I would like more explicit denotation of the meaning of scale and chart lines similar to a map scale bar cartographic element
–So that I can at a glance understand the actual distances between chart lines and chart elements.

[bdbcat]

Point #6, please.
We are speaking of routes, points, and tracks only.

[RandonneurLibre]

Oooorrr, you should really consider fixing the basic, busted UI features. The UI/UX world has advanced and OpenCPN just ignores that because "OPEN SOURCE!" Secret pro-tip: the shortcomings in UI/UX and documentation are why FOSS evangelists have such a hard time convincing normies to convert to FOSS. There are fundamental cartographic features missing such as map scale; this alone is one of the struggles I face in convincing my experienced sailing partner to convert from closed source.

[goboatingnow]

Just build in good NMEA2000 support and hence the whole ecosystem opens up.

[bdbcat]

Point #6, please.
We are speaking of routes, points, and tracks only.



If you have no constructive input relating to this focus group, please start a new thread, and the devs will read it separately.
Thanks for your cooperation.


Dave

[CarCode]

Originally Posted by bdbcat

Point #6, please.
We are speaking of routes, points, and tracks only.
If you have no constructive input relating to this focus group, please start a new thread, and the devs will read it separately.
Thanks for your cooperation.
Dave

Why you always ignore the users?

[stevead]

Originally Posted by stevead

Please replace the underlying XML file with a proper database that is atomic, supports replication, provides referential integrity and has triggers.
The database is simple, disentangling the OCPN code perhaps not. An opportunity for a clean 3 tier model!

Originally Posted by bdbcat

Steve...
Point 6, please...

Dave,

I think you've missed the point.

Today OCPN stores waypoints, routes & tracks in a xml text file named navobj.xml. For example as you know a waypoint is stored as something like:

<wpt lat="41.163526667" lon="1.481703333">
    <time>2019-10-08T11:04:32Z</time>
    <name>Roda De Barra</name>
    <sym>triangle</sym>
    <type>WPT</type>
    <extensions>
      <opencpn:guid>2e870000-8acd-4ca8-b6d7-110a7c7affff</opencpn:guid>
      <opencpn:viz_name>1</opencpn:viz_name>
      <opencpn:arrival_radius>0.050</opencpn:arrival_radius>
      <opencpn:waypoint_range_rings visible="false" number="0" step="1" units="0" colour="#FF0000" />
      <opencpn:scale_min_max UseScale="false" ScaleMin="2147483646" ScaleMax="0" />
    </extensions>
</wpt>

What you are soliciting is user input for why, what and how to synchronize or replicate the contents of navobj.xml across different instances of OCPN.

I get the impression that yourself, Alec and the other developers will reinvent the wheel and build some kind of replication mechanism that will entail some sort of network and replication configuration and conflict resolution components and corresponding UI that not only entails a lot of development effort but may also be confusing to many users who already struggle today with OCPN's UI.

All I am suggesting is to give some thought to using a proper database that not only provides better performance and resiliency than a text file & xml parser but also guarantees atomic transactions, already supports replication and addresses conflict resolution.

For some reason the sqlite headers are already included in the OCPN source although I don't know where it is used. I'm not suggesting that litesync; a derivative of sqlite, is the answer but a proper database could easily address the problems you are trying to solve; multi-master replication, support for both online & offline modes and eliminating duplicated entries.

Some databases also support triggers, that could be utilised by plugins to replicate waypoints and routes to non OCPN devices such as the commercial chartplotters.

Other than shoe-horning an underlying database into OCPN and disentangling the myriad of API's that read & write to navobj.xml, I think it is something that should be considered.

For some, SQL may be much easier to code than some of the C++ code that you & Alec are working on at present!

INSERT INTO waypoints VALUES ('2e870000-8acd-4ca8-b6d7-110a7c7affff', '2019-10-08T11:04:32Z', 'Roda De Barra', '41.163526667', '1.481703333', 'triangle')

That's all.

[Rasbats]

https://www.yachtd.com/news/wpl_rte_update.html

With a modern MFD this limits the use of the N2K network to sharing rte, wpt, trk between OpenCPN machines. The MFD cannot use this OpenCPN data. There will not even be a NMEA 0183 connection on a lot of these MFD.

I would like the ability to import/export RTZ routes from OpenCPN. We are then using IMO ECDIS standard data format. This is not manufacturer dependent. Could wireless be used as the transport mechanism for exchanging RTZ between OpenCPN instances?

Mike

[Rasbats]

Originally Posted by stevead

All I am suggesting is to give some thought to using a proper database

Agree with this approach. At the same time a valid shema is needed. None of the present XML validates because it lacks a published schema.

This results in some programs being unable to import OpenCPN GPX.

Mike