Standard procedure in Windows is for the Esc key to do the same thing as the cancel key on any dialog. Currently, the Esc key does nothing in the Waypoint, Track and Route Properties dialogs. I am happy to go through the entire program to check if there are others with the same behavior if this is something that will be fixed.
Thanks,
Bruce
Enhancement to OCPN messages are requested to facilitate interoperability with another instance of OCPN or other devices.
Some of the required messages already exist. Others need enhancement.
- Waypoint added, updated or deleted. FS#2805 addresses this partially.
- Route added, updated or deleted.
- For route activity, we already haveOCPN_RTE_ACTIVATED,OCPN_RTE_DEACTIVATED &OCPN_RTE_ENDED. We need additionallyOCPN_RTE_ADVANCED
- We already haveOCPN_WPT_ACTIVATED &OCPN_WPT_ARRIVED. But there is no message for when the active waypoint is deactivated or changed to a different one, such as when a route advances.
Messages need to be sent under all circumtrances, whether the action is through the GUI, through an API call or determined by OCPN in the course of navigation.
In most cases it is sufficient to send the GUID as further details can be retrieved by GUID, except when an object is deleted and no longer exists. So, generally, the message should include the object's name.
This enhanced facility has uses beyond interoperability. For example, at present dropping a waypoint creates a vanilla waypoint and, invariably, the user needs to display its properties to give it a name, icon, scale visibility etc. Adding a OCPN_WPT_ADDED message would allow the user to tailor the new waypoint to personal preference via a simple JavaScript action.
See the forum discussion on interoperability.
The standard dialog box behavior under Windows is that the Esc (escape) key is the keystroke equivalent of clicking the cancel key in a dialog box. It would be nice to be able to use the Esc key to close the Waypoint Properties Form without accepting changes (same as clicking Cancel).
Same goes for other property dialog box (route, track), as well as all froms with a cancel button.
Thanks,
Bruce
route properties dialog box included a cumulative distance column that would show the distance from the beginning of the route to each route
Route Manager still does not show the total length of each route--to see the total length of a route you have to open route properties
OpenCPN (5.0 and above) consistently crasheswhen you do this:
- Open Route & Mark Manager
- Import GPX file (created previously byOpenCPN)
- Click on Track Properties
- Move Track Propertieswindow to side of screen
- Move ship track position using cursor up/down recorded points
- CloseTrack Propertieswindow
- Click on Delete on Route &Mark Manager
- OpenCPN crashesand closes.
Notes: I have tested this on a laptop and desktop computerboth running Windows 10 with same result. Have tested with various GPX files.
The only time it doesn't crash is if you don't move the Track Properties to the side of screen.
I have included a video of the problem:https://youtu.be/owLFZfILxSM
Problem:
Creating a route with night stop anchorages requires the Estimated Time of Departure feature to offset the actual trip duration. It seems the time zone or something is not linked as the ETD time offset of the next waypoint. it calculated incorrect but can be fake adjusted as a workaround.
Repro
Create a route and plot an anchorage waypoint at 12pm, then a departure waypoint .01nm away at 1 knot.. I want to remain anchored untill 6am the next morning so I enter it in the Estimated Time of Departure field in that waypoint's properties. The Route Manager shows a completely different time as calculated. There is no error as expected.
Two GPX files that are before and after the application hangs. v1.5a is a working copy exported at 6am, v1.5b is an exported copy made at 11am after restarting OpenCPN in safe mode. v1.5b reproduces.
REPRODUCE:
Import v1.5a GPX, Right click the Route and choose Properties... Displays diaolog as expected.
Import v1.5b GPX, Right click the Route and choose Properties... Hourglass spins forever, Taskmgr reports max CPU allotment. Have to kill the process. OpenCPN restarts with safe mode dialog. Reproduces in safe mode.
If OpenCPN v5.2 crashes, on next launch it reports "Deleted stale lock file" and gives you an opportunity to start in safe mode, which I decline as the crash is not a repeating one.
OpenCPN does not start completely. Charts are not loaded properly and the plugin buttons in the toolbar are 'dead'.
If I then quite OpenCPN and launch it again, all is well this second time.
I have done a file compare on the log file for the two starts. The only differences I can see are:
- Timestamps (obviously)
- chart1.cpp:2564 OpenCPN Initialized in 499 ms. (for duff start) vs.chart1.cpp:2564 OpenCPN Initialized in 15615 ms. (for successful start)
- the successful start reports 'navutil.cpp:1643 Applying NavObjChanges' but this line is missing from the duff start.
Can we get "F" or "C" into the preferneces for displaying of temperatures in Fahrenheit or Celcius?
Petri Makijarvi was able to include this rather quickly in Dashboard_Tactics plug in. Seems as if this is something simple that should be included in Dashboard_pi, also.
I know F/C is a function of the NMEA0183 data stream, but for my set up, changing the transducers proves to be complicated. With Dash_T, it so easy to just select the correct one.
When I select "USA - NOAA & Inland charts"->ENC->All ENCs-All
in the chart downloader this freezesnot only OpenCPN but the whole operating system.
Windows is not responding anymore. It is not even possible to startthe Task manager to kill the OpenCPN program but I have to do a hard shutdown of the OS to recover from this condition.
This issue reproducable and happens every time I do the above.
When double clicking on a point of a track, the Track Properties window opens. The proposal is to highlight the leg number / line that corresponds to the point where the user double-clicked the track. This allows the user to see the time and speed at that point of the track.
The same feature might be added to another vessel's AIS track
Most features for route planning are missing in version 5. These features are "ETA Planning - Now", "ETA Planning - Now from Intermediate WP" and "ETA - During Passage", all of them are explained in detail in current built-in and online manuals (https://opencpn.org/wiki/dokuwiki/doku.php?id=opencpn:opencpn_user_manual:toolbar_buttons:route_mark_manager#eta_planning_-_now)
All these features were accessed by typing "<" in the "Departure Time" box of Route Properties window, which automatically entered present date and time as departure time from current position to next active waypoint in the route. Now in OCPN 5 release this box does not allow typing "<", so these features can't be accessed even if maybe code is still there.
All of it used to work beautifully in previous versions (although 4.8 introduced errors in calculations as explained in last comment in "FS#2316 - Route properties, Start hour") and were one of the most powerful features of OpenCPN. Now all of these features are out of reach which renders OpenCPN useless for route planning during passage, as all ETA's to waypoints can't be updated as passage goes on.
OPENCPN V 5 Win 10 ver 1906
There are several errors with the ETA calculations
- The ETA for the 2nd WP is calculated at two times the actual ETE. A work arround is to use a WP very close the the starting WP.
- In WP properties Extended, the ETD AM and PM times are reversed when transferred the Route Properties
Feature request.
Is it possible to use the default Windows date format for all date fields. If not then support the user selected format. The ETA format is always USA mm/dd/yyyy. At least the following additional date formats should be supported:
dd/mm/yyyy, yyyy/mm/dd, also dd/mm/yy and yy/mm/dd.
Less annoying is the time format with both 12 hour and 24 hour time formats. Is is possible to use the default Windows format or alternately allow the user to select the format
The new waypoint features lend themselves (nearly) to producing an interactive cruising guide for areas that are accessed via OpenCPN. This would be an awesome tool but to make this work waypoints would be need to be more portable between different computers and operating systems.
At the moment a waypoint can be associated with 1 or more links. These links can be either a URL (on the internet) or a file (on the local computer). The URL structure will obviously work anywhere you have aninternetconnection - but yachts have bad habits of going outside of areas that haveinternetaccess.
Ideally, for something like a cruising guide (or for locations and contact details ofemergencyservices/ restaurant guides / marina guides.... the applications are almost endless) you would want to be able to download a set of waypoints that can be shown on an OpenCPN layer while you are offline. Along with these waypoints you would also want to download the linked files containing photos, information, videos etc. The problem here is that the file:// resource locator is not portable betweencomputers.
Say for example I write a cruising guide comprising of a set of waypoints with links to html files andimageson mycomputer. All of these links use the file:// resource locator which points to html files, images and videos on my computer. Now I want to put this online so that others can use this information.Anyone else who downloads my helpful guide cannot use it as the file:// links used in the waypoints refer to the specific file structure (and drive letters) on my computer. In order to use the guide they would have to go through every waypoint and edit the links to make them point to the right place (where they had downloaded the html and image files).
For large information databases hand editing every waypoint in this way would be unrealistic and a horrible waste of time.
My suggestion here is to add a third type of resource locator - lets call it opencpn://. This then allows you to specify files relative to a user definable base directory into which you can put "points of interest",cruising guidesetc. Lets call this a "Points of Interest" directory.
It would probably be helpful to provide an example to clearly demostrate both the problem and my suggested solution:
The problem
I create an interactive cruising guide for an area describing each anchorage in an area. This guide contains text and photos. Access to the guide is from on-screen waypoints which are intended to be imported into a OpenCPN layer.
For one example waypoint of the 1000 that make up my guide....
I set up a link to file:///C:/My Guide/this-anchorage.html
On my machine I can now happily click into the waypoint properties, click on the link and I get my guide.
Now I upload my cruising guide so that other users can download it. The guide comprises waypoints, HTML files and image files. Once it is downloaded thewaypoints can be imported into an OpenCPN layer.
However. the user downloads my guide to N:\Yacht\Guides\When the waypoints are imported they all point to the wrong drive and directory location so none of the links work. When I click on the example waypoint OpenCPN tries to open
C:\My Guide\this-anchorage.html
meanwhile the file on the users machine is at
N:\Yacht\Guides\this-anchorage.html
The only way fix this is to go through and hand edit every link to that it points to the right place.
My Suggestion
Before I create my cruising guide I set the "Points of Interest" directory on my version of OpenCPN to point to
C:\My Guide\
I then specifiy all of the waypoint links using a opencpn:// resource location.
So for my example waypoint C:\My Guide\this-anchorage.html would be specified as opencpn://this-anchorage.html
Note: that all the links in this-anchorage.html to images, videos or other HTML files would need to be relative links but this is straightforward.
The user then downloads my cruising guide. Prior to importing this into an OpenCPN layer the "Points of Interest Directory" is set toN:\Yacht\Guides\ and the waypoints are then imported into a OpenCPN layer. When the user now clicks on my waypoint link ofopencpn://this-anchorage.html this correctly resolves toN:\Yacht\Guides\this-anchorage.html on the user machine.
Some additional thoughts:
1.Ideally the "Point of Interest" directory needs to be associated with each layer which would for example allow you to import a marina guide into 1 layer with the guide in a specific directory, a cruising guide into another layer, a ports of entry and formalities guide into anther layer etc. This would fit well with the layers dialog.
2. While you could already do something likethis with a text editor and a global find and replace of directory strings in the GPX file this is prone to error (especially with lots of \ and / in the file paths). My suggestion above would make portable waypoints much easier for most users.
The properties table for a particular route includes the total length of the route and the distance between each waypoint.
However, it does not include the cumulative distance for each waypoint, which would enable you to determine the total distance to your next target location/waypoint.
You need to manually sum all the distances between waypoints to obtain this number, and on the ICW with many waypoints due to the constant course change requirements, that can be quite a few waypoints.
This cumulative number is already available in the yellow text box by hovering over a waypoint on a route. All the information in the yellow text box is in the route's property table except the cumulative total.
Feature Request: Add a column in the Route's property table that contains the Cumulative Total.
I produce layers for OpenCPN. One of them is a layer with bridgeinfo.
Because of the "amount" of the information, I have several "lines" in the gpx in the <name> seperated with a line-seperator (
).
The first "line" containing the name (and optional VHF-channel), the following "lines" the width and height of the bridge-openings.
Since version 5.0.0 only the first "line" is displayed. The rest of the lines is cut of after the first line-seperator and not displayed :-(
The idea in the screenshots.
This way the chartwill not be blocked by the window. The interface will become more ergonomic.
According to http://www.cruisersforum.com/forums/f134/feature-requests-30931-186.html#post2844447
is it also possible to implement "Zoom/Scale Weighting" for mbtiles?
For example: zoom=zoom+1 -> tilesize=128x128
Route Properties does not translate d, H, M, S in localization
Unable to modify or Copy the Latitude Longitude fields on a Waypoint Properties window by right clicking and select Paste lat/long or Copy lat/long
Text does not rotate properly.see
http://www.cruisersforum.com/forums/f134/chart-rotation-plugin-oesenc-charts-text-wrong-place-207003.html#post2715251
Use RotationCtrl to test the plugin.
https://github.com/seandepagnier/rotationctrl_pi/issues/7
In the logbook preferences unde capacity / fuel it would be nice to set also default consumption per engine per hour.
Even with more than 1 engine (e.g. catamaran) they are usually of same type / and similar consumption.
This value could/should then be used to calculate approx consumption based on engine hours (except if ERRPM sentences are received)
When user had entered rpm manually and engine is still running it could be assumed for the next automatic logbook entry that this rpm is remained.
In Options>Plugins>Dashboard>Preferences>Appearance can there be a temperature option for ºC/ºF? We can change all the other parameters, so temperature would be nice also.
I have installed opencpn from git master with:
cmake .
make
sudo make install
Running opencpn failes, due to uidata is not readable.
Permissions of folder /usr/local/share/opencpn are:
drwx------. 7 root root 4096 23. Mai 13:31 opencpn
A quick fix is to add the following to CMakeLists.txt:
INSTALL(DIRECTORY DESTINATION ${PREFIX_PKGDATA} DIRECTORY_PERMISSIONS OWNER_READ OWNER_WRITE GROUP_READ GROUP_EXECUTE WORLD_READ WORLD_EXECUTE)
INSTALL(DIRECTORY DESTINATION ${PREFIX_PKGDATA}/uidata DIRECTORY_PERMISSIONS OWNER_READ OWNER_WRITE GROUP_READ GROUP_EXECUTE WORLD_READ WORLD_EXECUTE)
INSTALL(DIRECTORY DESTINATION ${PREFIX_PKGDATA}/plugins DIRECTORY_PERMISSIONS OWNER_READ OWNER_WRITE GROUP_READ GROUP_EXECUTE WORLD_READ WORLD_EXECUTE)
INSTALL(DIRECTORY DESTINATION ${PREFIX_PKGDATA}/doc DIRECTORY_PERMISSIONS OWNER_READ OWNER_WRITE GROUP_READ GROUP_EXECUTE WORLD_READ WORLD_EXECUTE)
INSTALL(DIRECTORY DESTINATION ${PREFIX_PKGDATA}/s57data DIRECTORY_PERMISSIONS OWNER_READ OWNER_WRITE GROUP_READ GROUP_EXECUTE WORLD_READ WORLD_EXECUTE)
But this does not take care of the different build architectures and does not handlethe plugin subfolders.
My cmake version is 3.11.0
- the dialogue could use the desktop rea lestate more economically :)
AND
-should enable recalc (UTC/LT) or updating when a departure date/time is given to calculate ETA
- Also any columne should be able to be printed - especially ETE/ETA
- add posibility to add comment field for personal reminders or tide/current informations
- another rather useful planning option would be to change the av.speed on a wp section and get ETE/ETA recalculated
In the AIS target list it would be desirable to enter the MMSI properties (like track y/n, folloower, ignore etc) directly rather than the cumberson way via the options settings. Maybe a right clickon the AIS target list, either with a selected target or generally anywhere, would be the solution.
GOAL: We really should be able to easily copy and paste lat/long from one place to another without having to worry about format (dec.degrees, degree & dec.min, or deg,min,sec)!
This is currently possible within Opencpn but not so with plugins. This problem has lead to the incorrect declaration that SAR_pi is dangerous when the wrong format copied from a waypoint was used. However
I would submit that the plugin is dangerous because it does not "know" what format the main program is using from the setting Options > Display > Units Tab > Lat/long setting, leading to user errors which could affect SAR searches. http://www.cruisersforum.com/forums/f134/saltypaws-plug-in-sar-90663.html#post2516335
and FS#2110
New API 1.15 Value: Lat/Long Format selected. Options > Display > Units Tab > Lat/Long Format
Plugin Advantage: Interoperability between the main program and the plugin to allow seamless Copy of lat long and perhaps even adjust the display format of lat long.
Plugins: SAR, Weather_routing, Tactics, Route, Cel_nav, Ocpn_draw, Watchdog, vfkaps
Interoperable Code Snippet: Additionally, there should be a standard code snippet for plugins to achieve this interoperability.
Ship bells does not sound properly on odd count of bells except for one bell.
At 08:00 it will sound 8 bells (4 double bells) OK
At 08:30 it will sound 1 bell OK
At 09:00 It will sound 2 bells (1 double bells) OK
At 09:30 it will sound 4 bells (2 double bells) should be 1 double bells + one single
Every odd number of bells afther that is wrong.
This is on Ubuntu 17.10 and Raspberry Pi
Seems Ok on windows 7
AIS target query. For unknown vessel types - display transmitted # instead of unknown. For example, O does not know about type 56 or 57, which are commonly used in the US. Displaying the # will at least allow me to make the identification.
This feature request consists in displaying a dashboard layer showing main data for sailing. the user can directly visualize the main data to sail:
- The true boat speed and direction ( SOG, COG)
- The versus water speed and direction (HDG, STW)
- Thus visualizing the drift
- The true wind and apparent wind.
And by visualizing the polar and the speed vector , how to optimize is heading, and how far he uses the potential of his boat.
You will find as a attachment a "specification" of this layer. If any questions, suggestions of what ever, to improve this feature request , do not hesitate to comment, adjust , ...
Best regards and Thank you very much to all the team for this excellent OPENCPN V4!
Gilles LEPINARD (Cumulus)
Allow displaying properties window and let the user change parameters of most of the fields for all the selected objects at once (except name, description, position, etc...)
