It appears that you discount much of what I have reported. Unfortunately the migration to qtVLM routing has already started and will continue without improvements, and this will draw users away from OpenCPN. That is why your plugin, weather_routing really needs some tender love and care now.
Quote:
it would be better to somehow get vector chart data and use that. That way it could use safety margin from grounding depth, and the resolution would be high at .1nm with gshhs you will have problems
High Res GSHHS does not always align with the charts, I have noticed that sometimes there is a very significant offset which in itself is dangerous, but it also makes using chart depths somewhat difficult, unless you just use chart depth only for "Land avoidance".
As I reported there are also freezes and hangups, particularly when the time interval is set short and there are many many isochrones that have been created and the PI just keeps calculating and calculating endlessly with routes that are getting further and further away from the destination.
Why can't we have a definitive "Stop" button next to "Calculate"?
Why can't the settings automatically be "saved" first, when the "Calculate button is selected?
Quote:
There are too many possible cases and parameters generally. You could try to code this "logic" but for other cases it would fail. It would make the resulting isochrone more difficult to read unless you are careful with the rendering.
Next to "Advanced Tab", provide "Slow start-finish Tab"
There are just 3 significant parameters involved in my opinion:
So basically the only question is how to reduce the Time Interval. Perhaps after a failed calc when approaching the destination, the time interval should be successively reduced by 1/2 until it is 30 seconds, and then it becomes a failure. These settings could be added to a new dynamic tab to be adjustable by the user. I do not think users read the isochrones as much as you think, they read the optimal route created. You bring up a good point about reading isochrones however, when dynamic parameters are being used we could just draw the isochrones in a different color, just as Climatology based isochrones are done.
I checked both the log file and the backup log for "error" and "fail" and all I found was NZ chart problems. I am going to have to make weather_routing fail again, and immediately get the log. Sorry.
Rick, Sean,
I just tried 1.13.41.0 of the WR plugin, and share some experiences and opinions below. Let me start by saying that I am pretty impressed by this plugin and the work that Sean did. It would be great to have this functionality in OpenCPN. My personal experiences however, were not that good with it, and I used qtVlm. Not easy to learn, but as soon as you know how to deal with it, it is realiable and works pretty well. Obviously I would prefer to have all in one system, so that I did not have to export / import routes, copy waypoint or others things, though as said my experiences were not that good with the plugin. That was 3 years ago while sailing from Amsterdam to NZ. I am now preparing somer sailing again and started experimenting.
My main issue is with the land detection and the CM93 files. Out on the ocean that is not an issue, but near shore, you want it to work. I couldn't. :-( Every now an then in crosses land, and the other time is seems to detect it. Sometimes it seems to detect some land, and other land not. (Distance to land on 0nM) See the attachment showing this. And the next time it just crashes. Using an 2019 iMac with recent osX etc. See the attached crashlog. (a zip file, saved as pdf). And indeed Rick, in that case all settings are gone. :-( Sean is right as well, you can save the file prior to calculating, though ... that is not the way one normally works. Though ... on the positive site, it sometimes works as well. See attached file, while planning from Pacific to Tasman.
Regarding the values: the plugin sees 180 as the max course angle and max search angle. I cannot get them any higher.
The isochrones still only show with advanced graphics off.
Sean, do you recall if WR acted this way sometime ago? Requiring that OpenGL be off?
I seem to remember that it did not matter, it just worked and I am wondering if something has happened with respect to the TestPlugin frontend that causes this. I have tried to be careful about changing some of the lib files/folders that are different between testplugin and weather_routing.
@wernertook I've looked at your file and realize you are on MacOS, and there seems to be some hangups during processing, I can't determine any more than that. I would suggest that you turn off CM93 charts because Weather_routing only uses GSHHS and you should be using the High Resolution version of those charts. This is most important. Also keep in mind that the High Res GSHHS do not necessarily coincide with charts.
I have tested routing in an around New Zealand extensively and it is working for me on Windows. I wish I was at your elbow so that perhaps we could understand what is happening better. I hope Sean will download your log file and inspect it to see if anything is amiss. Sorry.
Furthermore qtVlm offers a version for the iOS operating system for iPhone and iPad devices beside all other OS.
Rick’s reference to qtVlm prompted me to download the MacOS version and see what it was about. The first impression was that the Graphics were superior to OpenCPN - the same CM93 charts that I use with OpenCPN showed much better detail with qtVlm. qtVlm’s handling of Pathways/Routes(weather routes) really sucks and it is the main reason that I am not considering it for my iPad at present. But, the fact that OpenCPN does not work on the iPad is equally a turnoff.
In my view the WR pi and GRIB pi in OpenCPN both need a bottoms-up review and update. Graphics on the Grib viewer and the clunky progression and display of Grib data is terrible by comparison with all other Grib viewers. The WR pi is slow to calculate and it has many issues that I and others have identified. To be fair, the WR pi also has good features that other WR apps don’t have.
I continue to be amazed at Rick’s commitment to support OpenCPN - just wish I had the programming knowledge to help him. I am equally impressed with Sean’s work, but he seems to have backed out of giving the level of support to OpenCPN that is crucially needed.
I know that there are many others that help with the development and maintenance of OpenCPN and they are all to be congratulated on their efforts.
I hope these comments are taken in the positive way that they are meant. Someone has to focus attention in the areas that need fixing.
re:
"The first impression was that the Graphics were superior to OpenCPN - the same CM93 charts that I use with OpenCPN showed much better detail with qtVlm."
If you have the time and inclination, I sure would like to see some A/B comparison shots of cm93 on OCPN vs qtVlm, especially demonstrating the differences. I'm sure we could learn something from the exercise.
Kevinh...
I don't understand why people are asking for more informations. They could simply install qtVlm themselfes and see for themselfes the differences to OpenCPN. qtVlm is for free same as OpenCPN. Only the versions for Android and iOS (iPad / iPhone) takes a small fee and so does OpenCPN for Android which is however not available for iOS.
Hi Dave, CarCode and bcn. Here are some comparisons. I cannot change the User Standard Objects under Vector Chart Display because the settings are greyed out in OpenCPN 5.6.2 for MacOS. The zoom levels don't always align in the comparisons, but you can see the difference.
qtVlm shows NAMES and depth contours. OpenCPN shows very few if any names and often spot depths instead of depth contours.
I would make the change to qtVml if it were not for the crappy way they deal with Pathways/Routes/Routing (weather routing), and the crappy way they deal with Barriers (Boundaries).
Drawing attention to qtVlm however was not the purpose of my original post - please get someone to overhaul OpenCPN Weather Routing and the Open GL issue with it. I have turned to Luckgrib for WR - excellent and very quick. But it does note have some of the bells and whistles that OpenCPN WR has.
See screenshots for comparisons between OpenCPN and qtVlm.
Quote:
Originally Posted by bdbcat
kevinh...
re:
"The first impression was that the Graphics were superior to OpenCPN - the same CM93 charts that I use with OpenCPN showed much better detail with qtVlm."
If you have the time and inclination, I sure would like to see some A/B comparison shots of cm93 on OCPN vs qtVlm, especially demonstrating the differences. I'm sure we could learn something from the exercise.
Carcode...
"I don't understand why people are asking for more informations."
The reason is simple. Here is a concrete way in which one of our experienced users can contribute directly, in a positive way, to the improvement of OCPN.
Not everyone has the ability or inclination to write code. But thoughtful and specific input on OCPN, its functions, and ideas for improvement always has value, don't you think?
I fiddled around at one location, your last two screenshots. (Yaurava Bay).
See the attached pix. Generated using Display Category "All", no other tweaks. linux/x86.
I cannot see much content difference between my screen shot, and your last attachment. Of course, some differences in line style, fonts, colors, etc. OCPN uses IHO S52 PLIB display standards.
If you cannot get something similar to my shot on your Mac, then of course that is a problem.
Linear Mode
Recent Discussions