Organizing Nav Objects into Layers

[PjotrC]

Originally Posted by rooiedirk

there could be extra info for character, height, description, range, angle of view etc. This extra info could than be visible after a right click on the (way)point.

Dirk...

Sorry to disappoint you about the Lights... I just need the positions in handheld GPS and lighthouse names on small-scale zoom in OCPN. No need for other characteristics as long as there is some power. If there isn't, extra gpx fields won't help much...

Would it be sufficient to enter this information into the Description field as text? If I felt this is needed, I would do it this way - much more flexible. One might perhaps wish to have more space in the dialog for descriptive text, and less for icon selection, but I think few people go to the trouble of doing any typing.

As an example of another way of providing additional information about a waypoint, it is worth noting that you can include a very general link in the "additional information" property. In the example shown I've linked a waypoint to the actual .pdf text of the relevant Notice to Mariners.

It's all in there, but takes some effort to fill in the data...

Piotr

[Jon Hacking]

Piotr, I REALLY appreciate all the work you've been doing. I used the Layers feature of MaxSea all the time & really missed it in OCPN. I'm very happy to see Layers (& general Track-handling) being improved.

Could you please point me to a Requirements Doc or something similar for this project? If there's no formal doc, perhaps your own words on what functionality you plan to implement, or even just how it will behave relative to MaxSea Layers (similarities & differences)? From what I've read in this thread, the requirements still seem to be evolving. Thanks!

[nohal]

Jon,
I really doubt there's something like that. I for example forgot to buy or even use MaxSea at all before starting to implement new features for OpenCPN. But it could be quite helpful if someone who knows what's missing wrote stuff like what you ask for. Really.

Pavel

[Jon Hacking]

Thanks Pavel. I'm a SW dev but usually for embedded medical, where we have to have reviewed requirements. I've never done Open SW dev, but I'd think the spread-out environment would need requirements even more, to keep everyone on the same page. But I'll take a swing at it...

Here's what I know about how MaxSea (MS) Layers functionality [with my comments in square brackets]:

1. Multiple Layers can be Open (loaded into memory) at the same time
2. Layers can be Opened or Closed at will, except that at least one layer must be open at all times [MS provides an initially empty "default.ptf" layer file, which must always be open]
3. Layers can be visible or invisible. That is, they can be Open but their contents not actually being displayed. [This should be made easy to do, as it's very handy for having info at your fingertips but decluttering the display, even if it takes memory & probably increases start-up time]
4. All Tracks & Points (chart markings) belong to a Layer. [Routes do not in MS AFAIK, but we may want to think about that]
5. All objects in a Layer are deletable or modifyable (as much as the UI allows)
6. Default Layer: One Layer is designated the "Default" Layer. [I suggest that the Default Layer must be Open & Visible]
   1. Which Layer is the Default can be changed at any time.
   2. All "Marks" (waypoints & other chart markings) go into the current Default Layer. [If we do not want to go with the "Default" Layer concept for saving marks then we need to ask the user which layer to store each mark to. Having a Default is probably easier but we might want to think about this as it's a bit clunky]
7. Track Handling: Tracks do not have to go into the Default Layer, but they do have to go into some Layer.
   1. When the user stops laying a track, the system brings up a dialog box asking which Layer should the track be saved (appended) to.
   2. This dialog box has buttons for:
      1. Saving (appending) the track to an existing (open) Layer,
      2. Opening & saving to an existing Layer on the hard drive,
      3. Opening & saving to a new layer,
      4. Not saving the track at all, or
      5. Canceling the "Stop Tracking" function (which returns the user to normal operation with tracking still on)
   3. If the system is shut down while tracking is on, the user should be asked which layer the track should be saved (appended) to.
   4. If the system crashes while Tracking is on, the next time the system starts the system should recover the old track info & the user should be asked where that track should be saved (appended). [MS does this really badly, clobbering the old layer file rather than appending to it]
8. In MS, Layers are single files. [Not sure if this needs to be a requirement, but it does make it easier to exchange layers, which we & others do a LOT. I'd say the requirement here is that exchanging Layers should be easy.]
9. In MS, you can not close the file "Default.ptf" (the initial Default Layer file). [This seems a silly restriction. I NEVER use Default.ptf, as I always setup a Layer file for each area I'm in. But it may simplify some programming]

If the OCPN implementation of Layers will be significantly different, I'd appreciate knowing how & where. I DO think it's a good idea to not reinvent the wheel, but to build on & improve what's already out there, especially since it works pretty well.

Thank you all for adding Layer functionality!

[nohal]

Jon,
Thanks for the description We are most of the time in the invent it yourself, describe yourself, review it yourself, implement it yourself situation, so we just skip the middle two steps and integrate them in the last one
The layers implementation in OpenCPN is a bit different in how it's done.

The "default layer" (although not being a layer technically) is always there and is the only one where you can touch any individual navobjects. The track is always recorded there etc.
The visibility for individual navobjects can be changed from the GUI, the individual navobjects can be saved as GPX etc. (what you know from the current Route manager)
By the way technically it's a GPX file as well.

The layers are meant for a more static content. They are constructed from GPX files found in a certain filesystem location. A layer is a single GPX file or a folder containing more GPX files.
They can contain anything - waypoints, routes and tracks.
You can't modify this data from the GUI - if you want to do so, you have to Import the GPX file, modify whatever navobject you want, resave whatever you want to GPX and place that GPX file into the layer folder.
From the GUI you can switch the visibility of the whole layer.

The way to "exchange layers" is to take the GPX files and give them to someone. If there are more such files, to pack them with something is a good idea.

I would say it's functionally very similar, the only annoyance could be the more complicated workflow when you want to change something being part of the layer, but the read-onlyness of the layers is considered a feature currently. Time will show whether it has to be changed or not (quite some work).

By the way the best to compare is to see for yourself - using git and compiling OpenCPN from source is not rocket science stuff and is described reasonably well in Developer's Guide | Official OpenCPN Homepage

Pavel

[PjotrC]

Originally Posted by Jon Hacking

Could you please point me to a Requirements Doc or something similar for this project? If there's no formal doc, perhaps your own words on what functionality you plan to implement, or even just how it will behave relative to MaxSea Layers (similarities & differences)? From what I've read in this thread, the requirements still seem to be evolving. Thanks!

Jon,

There is no formal doc, and probably most important things have been already written in this thread and in the specification I attached to the flyspray patch.

I logged some 20000 miles with MaxSea and certainly there is some influence, if only superficial. The requirement is simple:

1. to protect part of NavObjects (WPT/RTE/TRK) from change and loss
2. to manage their visibility not one-by one, but group-wise (layer-wise )
3. this is meant for well-chosen and prepared GPX files, that the user really wants to have on-hand most of the time

There are some deeper implications, but the above is the target.

The difference from MaxSea is that in MaxSea layers concern (if I remember correctly) only drawing objects, i.e. chart annotations, and a track is a chart annotation there. OpenCPN does not have today the concept of chart annotation, and a track is a Nav object, behaving almost as a route. MaxSea - in turn, I think, does not have the concept of grouping waypoints and routes. I never got to like the MaxSea usability, especially recording tracks in layers always confused me...

The prototype that is available for testing is fully working. I am going to sail with it this year, without much change. It is neither a large nor a difficult modification to OpenCPN. Even if OpenCPN will get a nice Chart Markup facility one day, which it deserves, the possibility of grouping waypoints etc. would still be helpful.

Some of the deeper implications:

- declaring some structures as read-only should, in principle, open a possibility of optimizing the way their storage is managed. I think this is one of the sources of MaxSea superior performance in track handling. It's an estimate, but probably I usually have in my nav window 2000 trackpoints, 50-100 routepoints, 20-50 waypoints. Tracks grow fast.

- OpenCPN, when exporting GPX objects, in another optimization, attaches some proprietary identification, e.g. refusing to re-import twice the same route. This means that Layer model routes - should we want one day to change them, should be stripped of this identification data.

It is not necessary to address these isuues now, as it is not a hinderance.

Time for usage feedback...

Piotr

[Jon Hacking]

Thanks Piotr I think I'm getting a feeling for this now. I read this entire thread & was getting confused. I didn't see your Flyspray info, but I was probably looking in the wrong place.

The main issue I see is that I'll probably be wanting to save the vast majority of my info to a Layer, & this sounds a bit cumbersome. But we'll see how it goes.

I haven't had a problem with marks & such accidentally changing but presumably others have, ergo the R/O status of your Layer implementation.

I do use wayponts as chart annotations, just because there's no other mechanism. You're absolutely right that OCPN deserves better - some annotations are more useful than the tracks!

I don't usually save my routes once I've laid a track. I might have 20 annotations (waypoints) open. But I often have several thousand track-points open. I save all my tracks (& annotations) for a given area & then publish them for others.

You're right that tracks grow quickly - too quickly IMHO. About 7 months of cruising Malaysia produced a 13GB GPX file! Even the zipped version was 800MB - borderline for sharing. I try to remember to back off the tracking frequency on long straight stretches but I often forget.

Hmmm... Maybe OCPN could add a dynamic tracking option, where it realizes that you're on autopilot & going in a straight line so it backs off on the tracking frequency.

I'll be looking forward to your Layers!

[sinbad7]

After making a fresh installation of the latest OpenCPN version,I have lost all my new IALA markers. I created a new sub folder 'UserIcons' and copied my previously prepared icons in a .gpx file. After re.booting OpenCPN the new icons should be in my Mark properties box, but they are not. Has anything changed in the new OpenCPN version?

Tore

[sinbad7]

Re my #68..

Please ignore it. I copied the wrong files.. all working again now..

Tore

[jaapbood]

To people using layers: I use the mechanism to add buoy’s to the sea charts. Works great (getting the most recent buoy’s files). However, I dont seem to get rid of the “old” buoy’s and their names from the chart. I know I need to do-select lights, buoy’s, etc from the vector charts, but still get double byou’s. Any ideas?

[Jon Hacking]

Jaapbood, there's no way to delete objects in a CHART short of editing the chart itself, which sounds not only difficult but dangerous. Chart data is supposed to be sacrosanct. Only user data is supposed to be modifiable.

If they're in a vector chart, you can manage the display of that GROUP of objects, but not individual objects. And I don't think you want to turn off the display of ALL buoys.

Goodness, talk about kicking a zombie thread - the last post here was about when you joined CF, over 10 years ago. But I guess it's better than starting a new thread. Thanks for recycling!