Multiple instances

[sailingharry]

Not sure if this is a feature request, or a search for an already included feature.


I have an existing Furuno system. It has two plotters, one at the helm and one at the nav. They are fully independent, and do different things. I run the helm at HeadUp (a religious thing, I know), and the one at the nav at NorthUp. I can zoom out at the nav to look at where we are going, and the helmsman sees no change. The helm can turn on RADAR overlay, without cluttering up the Nav. We can even use different charts (RNC or ENC).


BUT, they live on the same database. If I modify our route at the Nav, it immediately changes at the helm. If I make a new route, it's available at the helm. No "sharing data," or "pushing," or remembering who has the current version of what.


Can OpenCPN do this? Not a mirror system -- that's different. Not two different systems, and then you push the data from one to the other. I spoke with a chart company at the boat show">Annapolis Boat Show, and they say their system does. It's Windows based, and you can run two instances on a single computer. Push instance one to screen one, instance two to screen two (presumably that's a Windows feature). And since they use the same database, it solves all the version management issues.


Even if you can't run it on the same Pi with two instances (will Pi do that?), you could run it on two networked Pi's, and point the "data" vector at a single storage system (even a NAS). And if you could use one chart repository (and one place to update), that would be a bonus that Furuno doesn't do.


A sort of related question -- chart licenses. Furuno has a "master" plotter that holds all the license keys, and they work on any plotter on the network. The encrypted charts have to be loaded on each device, but one key purchase unlocks charts on all plotters. How does the OpenCPN license scheme works, and can one purchase work charts on all devices on the boat? (I'm talking outside USA -- Furuno uses NOAA charts, so like OpenCPN they are free for USA).

[CaptTom]

Interesting concept. I haven't seen any such option in OpenCPN, but that doesn't mean it's not there, just that I've never looked.

You could set up a share on one machine, and mount it on the other, then point your chart library at that. And you can import and export routes, but it wouldn't be instant or automatic. Personally I'd be OK with that. I prefer to tell a computer what I'd like it to do, rather than have it decide for me.

[sailingharry]

Originally Posted by CaptTom

Interesting concept. I haven't seen any such option in OpenCPN, but that doesn't mean it's not there, just that I've never looked.

You could set up a share on one machine, and mount it on the other, then point your chart library at that. And you can import and export routes, but it wouldn't be instant or automatic. Personally I'd be OK with that. I prefer to tell a computer what I'd like it to do, rather than have it decide for me.

The nice thing about a single repository for waypoints and routes (not sure what else even would need to be there) is that I don't have to worry about "version control." Imagine:
* Start the day with both devices the same
* While sailing, at the helm, create a new route for the next bit
* Go below, make a route for tomorrow
* Have the helm send the current route do the Nav (did that action then overwrite the one you just made for tomorrow?)
* Modify the current route.
* Delete 5 or 6 routes from last week
* Send back to Helm.... but am I sending the full database (to ensure deletions occur at helm)? Or am I only sending the new route? And what happens to the route the helm is following when I send an update -- does it update, or does it create a new route with (1) added to the name?
* At the end of the day, I want to ensure a fully "merged" database reflecting changes made on either location -- deletions are sync'd, new routes and waypoints are sync'd, and any changes (tweaks to a route, waypoint "fine tuned" with an adjusted location or improved name, etc) are sync'd.

The problem that can occur with a shared config location is that we need several different types of data, and only some should be shared.
* Charts are shared
* Routes/waypoints are shared
* Screen settings (north up, chart format -- enc vs rnc, sat overlay, scale, "widgets" on screen and layout, etc) should NOT be shared -- this could cause problems if all user data is in a single location.


The end objective (best to state that, rather than the desired process...) is that all devices have the same routes/waypoints, with no user management required. I shouldn't have to do the same management (create, delete, rename, modify, etc) on each device (and remember which device is "current"). It gets worse if one device is off for several days -- when re-activated, its data could be horribly out of date, but if Routes/waypoints are stored on a single networked location, all devices are continuously synchronized.

[Bellinghamster]

TimeZero on a buddy's boat does this well and I find it pretty handy (4 monitors on the bridge, 3 PCs running, one dedicated to Maritron dashboards, 2 running TimeZero, one of those running dual monitors. I love being able run radar or radar overlay on one and uncluttered nav chart on the other or differnent zoom levels. Routes, waypoints and chart licenses seem to share seemlessly.
My boat is MUCH simpler - Garmin GPSmap at the helm and OpenCPN on my phone and tablet, sometimes building routes at home before a trip. I wish I could easily share routes and waypoints between all of them, but between 2 openCPN instances (tablet and phone) would be a big improvement.

[UnicornUnicorn]

Hi OP

started out 4 years ago with RPi4s that have dual HDMI and had 2 full size monitors with touch and it was a drama from get go - there was a hardware glitch when you used the 2nd HDMI port it affected cant remember wifi reception or so then it was just too weak to deal with AIS in high traffic areas - I used the split screen feature btw. so one instance and you can blow it up over both screens and do whatever you want with both halves north up - different charts different zooms different overlays - very nice.
Feature is still in settings.

Problem was the OpenCPN hugged only one core of the think 4 to 100% so had same idea to use multiple instances and there was the feature of "OpenCPN PORTABLE" think it was like running it from a USB key. Never worked for me and seems abandoned feature now.

So now I have Intel boards with SSDs better graphic more power with only one screen per computer. Works and I am ok.

Not sure if you can run multiple flatpack instances??

nice Columbus Day Weekend everybody!!
MV Unicorn

[sailingharry]

Originally Posted by UnicornUnicorn

Hi OP

started out 4 years ago with RPi4s that have dual HDMI and had 2 full size monitors with touch and it was a drama from get go - there was a hardware glitch when you used the 2nd HDMI port it affected cant remember wifi reception or so then it was just too weak to deal with AIS in high traffic areas - I used the split screen feature btw. so one instance and you can blow it up over both screens and do whatever you want with both halves north up - different charts different zooms different overlays - very nice.
Feature is still in settings.

Problem was the OpenCPN hugged only one core of the think 4 to 100% so had same idea to use multiple instances and there was the feature of "OpenCPN PORTABLE" think it was like running it from a USB key. Never worked for me and seems abandoned feature now.

So now I have Intel boards with SSDs better graphic more power with only one screen per computer. Works and I am ok.

Not sure if you can run multiple flatpack instances??

nice Columbus Day Weekend everybody!!
MV Unicorn

I do have real concerns about the Pi being able to manage multiple instances, which you have confirmed. But individual Pi's each running a single instance, but with a single storage location, might well solve those problems. Or a Windows system on a real computer.

[UnicornUnicorn]

Googled around:

• single storage for charts and waypoint data ok
• licensed charts need separate keys no sharing from master like Furuno
• plugins and configuration needs to be individual - might be an easy way via "templates" to transfer Options > Display > Templates
• routes can be right click "send to peer"

HTH
MV Unicorn

[sailingharry]

I must admit being a bit surprised at the modest response to this post. I rather expected a lively discussion, with developers commenting on challenges, suggestions, or pointing to the already installed feature. Or users presenting functional workaround based on real experience.


I appreciate the comments I did get, with Unicorn doing some digging in Google. Bellinghamster mentioned TimeZero, which is very closely related to my existing Furuno system -- and having seen it in action, he seems to understand the value I see in it.


Still, where is everyone? Out sailing?

[PippaB]

IIRC, the latest version just ditched the local XML file in favor of a sqlite db? In that case it seems it would not be terribly hard to point each instance at a path to the db. The additional work, however, would be in record locks that are not needed for a 1:1 relationship. If you try to edit the same object from two locations at the same time there has to be locking/arbitration/selection. Curious if those ideas are on the roadmap with the recent change to the structure.

I will second the idea that it would be nice feature to have, I would use it, but don't know about the general user populace.

[sailingharry]

So the best way to solve almost any problem is to try. At least try. You may not solve it, but if you don't try you certainly won't! So I tried.


I installed O on my laptop (well, updated, it was already there). Then I copied it to an adjacent directory, and created a Bat to run it as portable. So I can run one "installed" and a second instance "portable."


Some challenging sleuthing found that the routes live in navobj.db (the date stamp doesn't seem to update when it's modified so it wasn't easy to find). This hold all the routes for the "fixed" copy, but not the Portable copy. The portable copy actually doesn't seem to save routes anywhere -- anyone know where they are supposed to be saved?


As an aside, the portable goes through a very long process of identifying data sources (none, on my laptop in my living room....) and rescanning all charts. Can this be shortened?


Oh, the split view feature is pretty awesome. It seems to allow different charts, different views, different operations, and different orientation(north/course). If the split view could be split "window," (not even different monitors), then Windows could handle sending to different monitors.

[stevead]

The adoption of the SQLite database as the underlying storage method for routes, waypoints and tracks provides OpenCPN with greater scalability, better integrity and more resiliency than the previous text based GPX file used for navobj.xml.

SQLite is available on all of the platforms that OpenCPN supports and as it is serverless and built from source code, it is easily integrated into the core of OpenCPN.

However SQLite is not a multi-user RDBMS such as DB2, Oracle, SQL Server etc. and the suggestion that multiple instances of OpenCPN can "share" a single SQLite database is unsupported and fraught with danger.

Also, unlike navobj.xml which was text based, human readable and could be edited, the SQLite database is a binary file, not human readable and cannot be edited with a text editor.

In other words, Mess with navobj.db at your own peril.

The supported method to "share" routes, waypoints and tracks between multiple instances of OpenCPN are:
1. Use the "Send to Peer" capability
2. Import & Export using GPX

To backup the navobj.db file, with OpenCPN closed, make a copy of the navobj.db file and save in a safe location. The next version of OpenCPN includes a feature that will enable users to perform backups whilst OpenCPN is running.

[sailingharry]

Steve,


Thanks for what sounds like a very knowledgeable answer. Having cut my teeth in DBII and Clipper back in the distant past, I was hoping that the OpenCPN database would be multi-user.


I take it from your response that this is not only not possible, but not in the plans. Rats.


Sending routes is fraught with problems on its own. Start with a route called "Home to Portsmouth" on all computers. Modify it on one computer, and send to a peer -- how is the name collision handled? Does it update (ideal answer) or create a new name (much like downloading a duplicate file in a browser)?


It also leads to management headaches. Realize that you've created a dozen routes on Computer A, and a dozen on Computer B, and you want to align them. Not knowing what is what, you can send all of A to B, and then go to B and send all (now it's got both A and B) to A, and you have all on both.


But, when you've got 200 waypoints, many of which really serve no purpose (I keep dropping random waypoints on my chartplotter), and you want to clean them up. You could go through both, one waypoint at a time. Or perhaps, send all of A to B, then clean up B (which has all waypoints), then mass delete all waypoints on A, and then send the cleaned up set from B to A.


It gets exponentially harder if you use 3 computers.


I really don't use waypoints or routes much, so perhaps the problem is more theoretical than real. But it seems like a real limitation for using O as a primary nav system.

[stevead]

Start with a route called "Home to Portsmouth" on all computers. Modify it on one computer, and send to a peer -- how is the name collision handled? Does it update (ideal answer) or create a new name (much like downloading a duplicate file in a browser)?

If you initially create the route on one PC, then replicate to other PC's you can safely make a change to a route on one instance and replicate to its peers.

If you make a concurrent change to the route on both PC's, and replicate the change, the first replication will overwrite the changes.

Like any multi-master replication model, at some stage conflicts are resolved, either by the first or last writer. Although OpenCPN maintains timestamps for routes, waypoints and tracks, it has opted for the first writer (or more accurately, first replicator) to win.

If on the other hand you create "Home to Portsmouth" separately on multiple computers, you will end up with two routes named "Home to Portsmouth" albeit under the covers identified with a unique Globally Unique Id (GUID). OpenCPN, like many commercial chartplotters allows routes & waypoints to have the same names, in other words it does not enforce uniqueness.

Software, does not solve the problem of poor discipline. Your scenario is no different to creating a document with the same name " on two PC's. Editing each document separately then attempting to merge the two.

There are derivatives or addons for SQLite (SQLite Sync, Litesync etc) that can synchronize multiple databases or store the database in the cloud. Whilst I can't comment on the future development plans it may one day provide an alternative to the manual peer-to-peer-replication that we have today, although as these products are commercial (ie not free), unlikely to be viable.

Due to the great work that Dave performed in decoupling the database storage from the route, waypoint & track code, it might be possible for SQLite to be replaced with one of the free RDBMS platforms. But I hate to think of the support nightmare that would entail. It's hard enough educating users about OpenCPN & networks, let alone running a database server!

[bcn]

There is another resource in play: the chart database.
Although named "data base" it is not something as we see the SQLite one.
No previsions for concurrent updates from users or systems.
Obviously a manual task to keep different installs in synch. As it would happen on a vessel with various stations.

[CyKlop]

Originally Posted by stevead

SQLite is available on all of the platforms that OpenCPN supports and as it is serverless and built from source code, it is easily integrated into the core of OpenCPN.

Out of curiousity, Steve, is there any chance of convincing developers to go with ODBC or similar so that we _could_ use a more heavy-weight database for the back end?

I realize there are some pretty hefty cons to that, especially in the area of initial setup, but that could probably be worked around by setting up sqlite as the default during initial installation.