Free Routing Software. qtVlm

[maitai]

It's not a bug, it's a feature (lol)

qtVlm sees only visible coastlines. Therefore there is an option to avoid routing outside screen, and another one to zoom automatically on the routing zone. In some rare cases it might be useful to deactivate them, but normally you should let them "by default". Btw there is a button in "advanced options" tab to reset all options to default. If you do that is it OK?

After a second look at your screenshot, I bet your starting point is on land, so since qtVlm routing cannot cross a coastline, you are routing inside land

[cagney]

Yes, the wpt is inland by mistake.
As the land is a different back ground color, isn't it possible to include this in a conditional code statement, and avoid calculation? Just issue a warning, that wpts must be seaward of the shoreline.
Thomas

[maitai]

On one hand coast detection is not based on background color, but on coast polygons. Using background color would not be precise enough imo.

And on the other hand I know at least one guy using qtVlm for sand yachting ("char a voile" in french, not sure about the translation)

[sinbad7]

Maitai...

Why does the route optimizer not follow the waypoints as instructed?

I have even tried just ONE wpt at the tip of Skagen in direct line view with own boat´s position. Also tried using just boat position and end position but always get the same result.
The Grib file is current.

Tore

[maitai]

Tore,

I just don't understand the question so can you precise a bit what you are trying to do, and especially how you did that in qtVlm?

A bit of explanation anyway:

There are 2 different things in qtVlm, the route and the routing. You can convert from routing to route.

The routing will calculate the best path from arrival to start based on your polar and the grib, using isochrons method. You can force it to avoid certain zones by putting barriers on the map, but this is normally not needed. Before a routing is converted in a route, you can also generate "child-routings", by creating a pivot on one of the isopoints.

Then you convert the routing in a route, and because this new route will contain too many points (one a each isochrone), you can simplify it (this process will remove all POIs that do not improve the ETA, typically aligned POIs are often not needed).

Then eventually you can optimize the route. Basically this process will try to reposition better the POIs, because the routing process only looks at fix step (say one hour), it is understandable that a point might be better placed inbetween 2 isochrons. I want to say that this is perfectionism, and IRL not really useful, because the grib is not precise enough, not to speak about reliability. It is very useful in virtual racing, because the grib is of course 100% accurate in that case.

[sinbad7]

Maitai..

Thank you for your very in-depth explanation,BUT,all I wanted was to create an optimized route from Kristiansand,Norway to Kiel,Germany down along the East coast of Denmark as indicated by the 6 wpt´s created.

However,starting the routing calculation,it does not want to follow the wpt´s along the East coast but makes it´s own route along the West coast to the river Elbe?

So,tell me,how do I acheive my OWN planned route down the East coast?

Tore

[maitai]

Ah. I see.

This is one of the (rare ) cases where qtVlm needs a bit of help. This is because the west side seems more attractive, and due to the cape that almost blocks the way to the east side, qtVlm decides to not explore that side.

You can force it to do it by blocking the way to the east side, i.e. creating a barrier that will force the program to explore only the east side. Alternatively you could create a pivot point from the closest iso point on the road you want, but creating a barrier is much simpler. In this case (routing in the middle of many obstacles), it is advised (but not compulsory, it actually depends on your polar) to reduce the iso step, for instance to 1/2 hour.

Note that the intermediary POIs are useless, the routing module knows only about start and arrival points, so creating intermediary points is... pointless

[sinbad7]

Maitai...

Thanks for your explanation,especially your last paragraph,did NOT realize that the intermediate points were pointless.. Like your pun!

I will try out the barrier method.

Tore

[sinbad7]

Maitai..

Sorry to trouble you again,BUT, where do I find the tool to create a barrier?
I have looked everywhere but can not find such a function?

Tore

[maitai]

You create 2 POIs (better to make them of a beacon type), right click on one of them, and draw a line (the last option)

[sinbad7]

Maitai..

Tried the blocking function as per the attached but the routing would not round the Skagen point and gave an error message ´Try another grib´?

Tore

[maitai]

Did you change any other default options? There is a nice button in the advanced tab to reset everything to default, can you try with that? Also note that it is not such a good idea to start from inside a very small bay in the coast almost closed from every side with just a mouse hole to get out. Since you know where you will have to go out from the bay, put the starting point somewhere there, where there is a least a bit of water

[sinbad7]

Maitai..

I checked the Default bar and also moved the Own ship as well as the arrival POI out in clear sea but I got the same results. What settings did YOU have to acheive the route I wanted down the East coast?

Seems the Routing manager has a mind of it´s own..

Tore

[maitai]

It seems to me according to the join picture that you do not have 180 (179) degres of exploration (scanning angle field). If this is not the case send me your files boatAcc.dat, poi.dat, qtVlm.ini, your polar and your grib file and I'll tell you...

[sinbad7]

Maitai..

No sure what setting is NOT 180 degrees? According to the Routing setup it should be 180 degrees?

I have all the files you asked for in a .zip file which I can not send here.
How can I get it to you?

Tore