I assume that the properties button in your dialog brings up the route properties dialog for the selected route.
It does
Great circle routing is about distance/course calculation and display, right? That would indeed fit better elsewhere. It's probably very important for anyone going long distance If I understand it correctly, this should be automatic for any route leg of substantial length?
Great circle routing is about distance/course calculation and display, right? That would indeed fit better elsewhere. It's probably very important for anyone going long distance If I understand it correctly, this should be automatic for any route leg of substantial length?
You are most welcome. Good work is always appreciated.
Great Circle or Rhumb Line routing would be a selectable option for each leg of a given route. What would need to be automatic would be the selection of waypoints for Great Circle routes. Unless the Great Circle route is in a cardinal direction, these routes could be to divided into equal legs with a set of waypoints defining each leg. The route properties dialog would show the Great Circle or Rhumb Line course and distance for each leg of the route. Thus, a route could be either Great Circle, Rhumb Line or a composite of both.
I looked at it, and the prognosis for creating tooltips for list items are not good with wxwidgets, there is no appearent events or functions provided to facilitate this, neither in v.2.8 nor in the current trunk (wxwidgets 2.9 to come).
That means that I would have to do some hocus pocus with mouse tracking and timers -- possible but tedious, although I may give it a try.
Can you remember what tooltips usage was fantasized about? Can I find it in this forum?
Anders
Tooltips would be the best, as wide (and non-resizeable) dialogs are a pain. The route properties dialog is already too wide in my opinion.
As an alternative, could you not simply place the required additional read-only fields at the foot of the table, and populate them when a row is selected? There's room left of the OK button.
Simple enough UI-wise and a lot less of a pain to hack together I imagine.
I would love to see an OpenCPN option where you just take a cheap web cam and aim it at your depth sounder whilst under way, and letting OpenCPN log the depth sounder readout of depth information. Using some kind of "SIMPLE OCR software" Optical Character Recognition Software. (And believe me I know nothing is simple with computers)
This would allow the collective OpenCPN users to create a database of Ocean depths that we could all share. By logging depth, location and time the data base could correct for tidal variation.
Web-cams are cheap now and work well. If we could get it to work on depth sounder output Numerals maybe it could be extended to putting a web-cam on you engineinstruments and having OpenCPN monitor and log the data they are outputting.
It would also be great if OpenCPN could extend to a boat management system and monitor my solar panel regulator as well. Which would then let me graph input power versus out put.
Boat: Schioning 12.3 "Wilderness" Bi-Rig under construction
Posts: 550
Quote:
Originally Posted by yachtmanforfun
I would love to see an OpenCPN option where you just take a cheap web cam and aim it at your depth sounder whilst under way, and letting OpenCPN log the depth sounder readout of depth information. Using some kind of "SIMPLE OCR software" Optical Character Recognition Software. (And believe me I know nothing is simple with computers)
It would be a lot easier to just log the nmea data from the depth sounder.
I can't think why i would want a nav program to get into data loging and power managment functions. PC's multitask so a seperate app would be most appropriate i would think.
This would allow the collective OpenCPN users to create a database of Ocean depths that we could all share. By logging depth, location and time the data base could correct for tidal variation. [...] It would also be great if OpenCPN could extend to a boat management system and monitor my solar panel regulator as well. Which would then let me graph input power versus out put.
Btw if you have an NMEA output from your logs and/or solar regulator, you might try capcode or openpilot for display gauges - or perhaps the closed win-only but allegedly excellent - navmonpc.
I attach for review/test experimental code implementing a couple of simple things, mostly around AIS, that I mentioned earlier in Technical thread.
The aim of the excercise is mostly for me to learn OpenCPN, but I find all these features useful, so perhaps this will ease their way into some future release..
Cheers,
Piotr
A short summary of features :
1. highlight the target currently selected for query dialog
2. remove course predictor/ROT indicator for lost targets
3. mark lost targets with a single strike across
4. provide uniform interpretation of "moored/anchored"
5. highlight "moored/anchored" and display Class B in special way
6. handle AIS Aid to Navigation msg 21
7. enable switching off the AIS display
8. replace NMEA checksum with safer one
9. produce simple logbook messages
10.play ships bells
I build and run on Vista32. I did not try Linux.
I look at OCPN from nav station point of view and I mostly try to put in what I'm missing. It's not so easy to make just the right things without having a myriad of options etc. The code is very nice to work with.
You are right... indeed vessel type 37 (pleasure craft) is not shown. Any more missing items? I have limited capability to test, but if anyone wants to build, I will fix this.
This is a source patch, that needs rebuilding.
But if you run Vista32 I suppose you can just replace the opencpn.exe that I can provide. I did not change anything in the environment (and the bells.wav files can be missing :-) ).
I tried this on my machine, and it seems to work. The opencpn.exe is 3.8 MB.