Organizing Nav Objects into Layers

[PjotrC]

Dirk,

Glad you have it running. PLease let me know, if the bottom "Import" and "Export All.." buttons are correctly disabled for layers and enabled for all other tabs. The wx docs say this behaviour is platform dependent and I still fight with this feature (not really critical).

P.

[rooiedirk]

Pjotr,
Import Export are disabled in Layers tab, and active in all others.
grjes
Dirk

[rooiedirk]

Found another smal bug. the items on the layers tab are not saved and/or reloaded when closing and restarting OC.
Dirk

[PjotrC]

Originally Posted by rooiedirk

Found another smal bug. the items on the layers tab are not saved and/or reloaded when closing and restarting OC.
Dirk

This is indeed the intended behaviour.

My current thinking is to view a layer as a chart extension. Since they are imported from externally-prepared files there is no need to backup or to trace changes. Indeed I think the only imports allowed should be automatic from /layers subdirectory. I added the manual import and delete feature just to see, how useful this will be, and to facilitate testing and trying out. Probably they might even go away. So, once you are happy about correctness of your .gpx file, you add it to the /layers set and that's it.

The key thing in layers is to separate the dynamic, often changing set of nav objects from the static, well known and prepared in advance.

Probably this could be exploited further to improve the speed when handling large number of static objects, but I am not very familiar with inner workings of runtime storage in OCPN.

Please keep testing....

Piotr

[mrm]

Piotr, I understand that you want to protect the layer from accidental modifications, but what do you think about alternate way of dealing with it? I propose to add an attribute field to the .gpx file defaulting to 'locked' (or 'read-only'). Such file would be immutable, but users would have the option of setting it to 'unlocked' (or 'read-write'), add their own modifications when required and lock it again. Analogous to write-protect tab on SD flash cards.

Good idea? Bad? What do you think?

Marius

[PjotrC]

Marius,

Another objective to keep in mind is to minimize the growth of OCPN functions and effect on user interface, and to keep the .gpx format interchangeable with other software. From this point of view, any OCPN-specific attribute is not desirable. There are really excellent tools for managing .gpx sets offline (e.g. EasyGPS, which can be used to keep and organize all your waypoints files etc., then to graphically select just the portion needed for next voyage, copy the result to /layers and that's it, you have your chart extensions ready. I would not encourage any interactive interface in OCPN for adding/modifying layer contents. Even the need for "delete" is doubtful. Let's keep OCPN lean... Let the users manipulate contents offline.

Piotr

[mrm]

Piotr,

I understand your position, but would like to point out, that sometimes it is easier to add/manipulate waypoints on the go, for example noticing an object in your vicinity (nav obj., underwater rock, something else worth placing a mark and not on the underlying map, etc.). Transferring coordinates to some other program only to add them to layer file seems to me a bit roundabout way of doing things in such cases.
Probably cases, when having a marine map background helps in placing layer waypoints could be indicated too. Or a simple need to modify a single point, when we physically are 'there' but the object indicated on the layer is not quite in the right location.

But, if keeping OCPN interface plain and simple is of top priority, then what I propose might be too much. Although I do not consider adding an option (like 'place mark on layer X') to a right mouse button context menu overly cluttering

By the way, EasyGPS is a windows only solution - won't work for me...

Greetings
Marius

[rooiedirk]

Piotr,
After some digging in wxwidgets and a hint from Nohal, I did change the line 1763 in chart1.cpp from

laymsg.Printf(_T("Getting .gpx layer files from: %s"), layerdir);

into:

laymsg.Printf(wxT("Getting .gpx layer files from: %s"), layerdir.c_str());

Same for navutil.ccp line 4143

laymsg.Printf(_T("New layer %d: %s"), l->m_LayerID, l->m_LayerName)

into:

laymsg.Printf(_T("New layer %d: %s"), l->m_LayerID, l->m_LayerName.c_str())

Now it compiles fine under linux, without the warning:
: warning: cannot pass objects of non-POD type 'class wxString' through '...'; call will abort at runtime
grjes
Dirk

[nohal]

Originally Posted by PjotrC

Another objective to keep in mind is to minimize the growth of OCPN functions and effect on user interface, and to keep the .gpx format interchangeable with other software. From this point of view, any OCPN-specific attribute is not desirable.

Piotr,
not that much of a deal. GPX standard supports the vendor-specific extensions and any well written tool should deal with it, preserving the stuff put there by others (we are currently not and discard the 3rd party attributes silently, but it's on my to-do list. Unfortunately with quite a few other things having higher priority right now...)
The other thing is which extensions we actually need to introduce and where and how they should be manageable from the GUI of course.

@mrm - the simple user interface (at least the core part) is of utmost priority, I would say

Pavel

[PjotrC]

Originally Posted by mrm

By the way, EasyGPS is a windows only solution - won't work for me...

Marius,

I am sure there are comparable tools around for your platform, but I really find EasyGPS very handy...

True, it is tempting to have rich functionality under a single mouseclick, but it is also tempting to have a simple, clean database behind, without any need to track changes, save/restore, etc. The incentive to keep the gpx format really interchangeable in practice, and to keep the gpx data in order using rich tools of the platform is also a good thing...

For single waypoints/marks I don't think anyone will suffer the lack of direct modification possibility. Just export a new mark, saving it on top of previous file. You can have subdirectories: /layers/marks1 then /layers/marks2 ... etc. All the contents of these directories will form separate layers. So just drop a file in there, and it is added to the layer e.g. marks1 (or replaced in it) at next reload. So, perhaps the "delete layer" will come in useful, after all...

We are just probing for the right set, trying to stay lean...

@rooiedirk: thanks for the hints, I will change the code accordingly...

Cheers,

Piotr

PS. To make it easier to distinguish, what belongs where, I am now showing the layer name (if any) in the Properties Dialog for WPs, RTEs and TRKs.

Current problems:
- portable way of enable/disable for notebook buttons
- if the same file is imported as regular .gpx, then as layer, deleting routes in it might cause a crash

[PjotrC]

I posted a new, seriously corrected version to flyspray.

As a bonus to would-be test users, I attach a set of 400 waypoints, implementing a simple list of lights for the route Baltic-to-Brazil. I download portions of this to my simple handheld GPS, which has neither POI nor chart capability.

Piotr

[rooiedirk]

hoi Piotr,
Thanks. Compiles and runs fine on my Gentoo machine.

Q. Is it possible and/or desirable to have the points added to the left-click menu, so you are able to read 'properties'. Deleting should be impossible ofcourse.
gr
Dirk

[rooiedirk]

oops, I did mean RIGHT-click offcourse

[PjotrC]

Dirk,

Thanks again for testing.

I am not sure what you mean by a list of points under right-click - in what context?

I tried not to change any read-Properties behaviour for points, routes and tracks.

Do you mean the situation where you have two or more points on top of each other - and you can not learn the properties for the "other one" by right-click? This is not new. Do you think this might be a problem? If you sort the waypoints by distance, the identical positions will always come together in the listing.

As for the left-click, as this is meaningless for "layer" points, perhaps it might be possible to always pick the other point. In my current naive model, the first one is picked, so it depends on which one was there before... if so, you are right, probably this is something to fix. For now, to pick the "regular" point you can hide the layer(s) below it, and then the point will become accessible in the regular way. Which layer? Hmm... Maybe the layer should be also indicated in the listings in rte, trk and wpt tabs...

Please dig more... ;-)

Piotr

[rooiedirk]

Hoi Piotr
Sorry for not being clear enough. What I do mean is:
If you right click on a waypoint you can see (and yes change) all kind of properties (position, description, name)
The gpx format is allowing us for all kind of extra info. So in case of your "list of lights" 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.
grjes
Dirk