Integration with QtVlm - Data files and Import/Export

[JesperWe]

Originally Posted by sinbad7

Jesper...

I received the following explanation from the developer of Android OruxMaps
....
The result of an examination of a .kml file from qtVlm

Tore

QtVlm <> Oruxmaps communication is none of my business I'm afraid.

[sinbad7]

Jesper..

- The ° character is exported from QtVlm. It is an OK UTF8 character, and when I test we read it fine into O. But to be strict and allow pasting into apps that do not read UTF8 correctly QtVlm should really be using the &deg; entity instead of the ° character. I don't know where you are pasting it, and getting the broken character, but making sure that the app you paste to sees the pasted text as UTF8 encoded will probably fix it.

I do not expect you to... it was only an answer to your earlier comments regarding the mis-typing of the ° character. Purely for YOUR info.

As I said,it is double-Dutch to me anyway he he

Tore

[rgleason]

Apologize for the numerous postings on this subject which is now closed.

Thank you Tore. Just one suggestion / request. Since this is still fresh in your mind, would you summarize your recommended steps in using OpenCPN and QtVLM? Which commands to use when for all those interested? Thanks. Rick

[maitai]

np with this, i'll put the &deg in the next patch

Concerning the tidal/current stuff, it's on the agenda, as well as waves. Waves are tricky enough, current is trikiest because it changes apparant wind. We know what to do, it needs some (free) time to do it well

[sinbad7]

maitai..

Yes,wind over tide is an important route factor.
Tide and tidal streams are more predictable than the wind but I can see it will increase the complexity of your wind optimimizing equation.

How about starting with an alternative tidal route optimizing option for motor vessels and later follow up with the more complex wind combination option?

By the way,I tried using the tidal GRIB in qtVlm. They seemed to load up but did not display anything.

Hope you had a pleasant holiday...

Tore

[sinbad7]

Rick..

Select Boat/boat settings and choose one of the listed boat polars as well as at what minimum speed to use the engine and at what max speed.

Create a Routing in qtVlm by locating your boat icon somewhere and then placing a POI somewhere at your destination.

Then you can create a box covering the entire sailing area holding down the right key of your mouse and moving it till the area is covered. Then goto the gribfile area and download the grib for the indicated area.

Click the Routings/create a routing and OK - the route will start creating before your very eyes magically.

To transfer the route or track data to OCPN,right click the route so the line increases it´s with and select copy route to kml.

Switch over to OCPN displaying the same area and right click either paste Route or paste Track. (or both) Your optimized route is now showing on your map.

Use the Route/Track Properties window (right clik the route) to view all details.

Hope this is helpful.

Tore

[rgleason]

Yes, sounds easier than I found it to be initially, but hopefully its so easy we'll use it a lot. Thanks.

[maitai]

Originally Posted by sinbad7

Jesper...

I received the following explanation from the developer of Android OruxMaps:
(which is Greek to me)



The result of an examination of a .kml file from qtVlm

Tore

Tore,
When I export a route in kml format, I have correctly the ° character encoded as C2B0... I do route->export a route and choose a file name with a .kml extension. Maybe you are pasting the route from the clipboard inside a text editor and then save it in a file, and your text editor is not saving in UTF-8 ?

[sinbad7]

maitai..

I tested your optimized .kml route with two different Android nav progs.
One displayed a strange character,the other a correct °.

Examining a route I pasted today directly into XML Copy Editor:

<Data name="TWS (grib/eta)">
<value>17.99 kts</value>
</Data>
<Data name="TWD (grib/eta)">
<value>2.03°</value>
</Data>

So you are probably right,it must be Notepad which does not use the UTF-8.


Tore

[rgleason]

Thanks, Tore, Maitai, Jesperwe and others for pursuing this integration with patience, and sorting out the last questions.

[cagney]

Originally Posted by sinbad7

Thomas..

With more possibilities for errors selecting the wrong file or time.
But OK,that´s a possibillity,but would prefer adding the TWD and TWS as shown.

I´d be happier if the normal track layout was followed,also for the pasted tracks from qtVlm. Why was that changed?

Tore

A grib is a just a computer forecast whichever way you present it.
It's well worth reading all of Frank Singletons weather site,/Franks-Weather/Forecast-Accuracy-Limitations.

Importing a route from QtVlm, as a track, does not make it a real track. It's still a route, or more correctly, a suggested route based on limited input. It's important to understand this. Talking about TWD and TWS in the way it's done above is totally misleading. TWD and TWS are what you experience when actually out there. It's real facts, not virtual. Tore's "TWD" and "TWS" are still just derived from a grib, a forecast.

Tore's suggestions for modifications, just leads to even more confusion.

Unless ... QtVlm is used as a total virtual experience, when, as maitai pointed out, the grib is "true", in the sense that it's a part of the rules for the game. But then ... there is no point in mixing in O.

QtVlm is a very useful tool in weather-routing, but to take the impressive output as facts, is wrong and dangerous.

All forecasts are just forecasts; they are not statements of fact. It is my view that if you do not understand these simple facts and are not prepared to put some of your own thought into forecast interpretation, then you are probably better sticking to rowing boats on the Serpentine - in settled weather, of course!

Using GRIBs and other Objective Forecasts/ Franks-Weather | The Weather Window

Thomas

[rgleason]

Thomas, your skepticism is legitimate, and based on our collective experience with weather prediction, I am sure others will agree. However we are seeing a revolution in weather routing resulting in faster sailing times in world class races, and admittedly these times are the result of experienced weather advisers and software, and hull, sail and composite technology. The weather routing software is only one part of the equation. The QtVLM and OpenCPN integration will help us understand the role of these planning tools better.

[sinbad7]

Thomas..

OK,some people prefers to use an old fashioned magnetic compass and stick a finger in the air to judge the wind. Fair enough,it´s your choice. BUT,for the rest of us who have arrived in the 21st century,we prefer to make use of ALL possible forecasts and predictions to plan our voyage,even if they are only 50% correct.

I am a little bored with dumb arguments and repetitive postings to get the penny to drop and your last quote is quite revealing to all who and what you are. For your information I have around 60 years sailing experience across the seven seas,commercially as a captain and privately as a leisure and charter operator so the pond you mention I only use to pi.. in!

On a more constructive tone,I have never indicated that the imported optimized route is the final and accurate one,we are all the time talking about PLANNING. Many other factors,not at least tidal currents and waves must be considered before a final course is set. Fresh consultations with qtVlm using the latest gribs should of course also be made at frequent intervals to check for alteration.

I suggest we all take a deep breath and stop this inane and futile banter.

Tore

[jonasaberg]

Originally Posted by sinbad7

Thomas..

OK,some people prefers to use an old fashioned magnetic compass and stick a finger in the air ... I am a little bored with dumb arguments and repetitive postings to get the penny to drop and your last quote is quite revealing to all who and what you are ...." Tore

Tore,
I think you are totally inapropriate in the tone of your post.

It is perfectly ok to have different opinions and the purpose of the discussion in this forum is to improve OpenCPN to the best possible. Your and all others opinions are welcome, but I think your attack on Thomas is well over line.

It is better to argue your point than to accuse others of posting "dumb arguments".

I can understand both your line of reasoning "maximizing the bells and whistles" and Thoma's "be careful not to lull the user into believing he has more accurate information than in reality" arguments. I tend to lean in your direction Tore, since I have had great help of self-hacked routing software in the past, but that doesnt mean I agree with the way you write in your last post.

If we keep the tone civil I am sure it is to the benefit of the development. Writing that arguments are "dumb" will likely make newcomers vary of entering discussions.

regards
Jonas

ps The software I used was an early pre-release version of Sailplanner. I think the way they present the grib forecast using a polar adopted to the predicted weather at the mouse location is brilliant. Well worth to copy in OpenCPN.
In the example below the polar-butterfly show the possible speed and direction the boat could make if it was at the position of the boat icon and at time that the grib is displayed on the screen. The polar is expanded/contracted in size depending on the predicted windspeed, and rotated to allways point in to the predicted eye.

I agree that it is misleading to talk about TWD/TWA it should be expressed as predicted TWA and predicted TWD.

[rgleason]

Tore, I like your ideas and process thoughts about software use. I agree with Jonas about being civil and thoughtful. The strength of this software is relationships, skills and cooperation, and both you and Thomas are important contributors, so I hope you can smoke some peace pipe, so to speak!

PS: I find Jonas illustration of polar very interesting. Now that's something to talk about.