This sounds like a great idea. Another requirement may be the ability to add an ETD (Estimated Time of Departure) for each POL (which may be the next day or later for an overnight stop) so that a flight plan pre-filed for a leg further down-route would have the correct times and DOF in it.

Simon

As each sector is its own flight in its own right, they all have their own flight details window entries and so all have their own takeoff time field already.

What will happen to the times if you plan a flight from A->B then insert a POL in the middle? Presumably the 1st sector can keep its initial takeoff time, but what about the 2nd sector if you don't have a 'time on the ground' field. You could just default to 'time on the ground' of zero so that ETA at the final destination will remain the same but this would be very inconvenient as you will then have to manually update all the subsequent sectors and repeat this every time you insert a POL into an existing sector. 

That's exactly the sort of guesswork we don't want to be doing automatically. As it stands, most people never set an explicit takeoff time. If you have, and you split a sector, the second sector will be brand new and its takeoff time will be undefined. The ETA function is a navigation function that applies only to the selected sector, there is no special processing for multi-sector routes.

I've now posted a beta including the functionality at the link below.
http://www.skydemon.aero/start/SkyDemonBeta.msi

Looks really good at first glance. One small problem I've noticed is that if you delete a waypoint (right click and select remove waypoint) which is a POL (i.e. the waypoint appears in two sectors) then the waypoint is only deleted in the current sector. This can result in routes that are broken with gaps in the middle!

Edited to add trivial point: when saving route the default name uses the first and last waypoints of the current sector not the whole route.

Edited again to add: the 'remove waypoint' feature also applies if an intermediate POL is dragged to a different location.

Thanks, that sort of feedback is useful. Behind the scenes the multiple sectors do not have to be contiguous, so we want the user interface to enforce contiguous-ness as much as possible in the normal course of adjusting routes. I'll publish another beta in a couple of days with such issues improved.

Here's some more:

1) When simulating a route with two sectors: Flying the 1st sector and the 1st sector magenta line displays in the virtual radar, but if the second sector is selected (whilst still flying the 1st) then no magenta line is displayed at all in the virtual radar. I would prefer for all sectors to be shown in the Virtual Radar whichever is the active sector, but if only one can be visible then it should always be the active sector.

2) If I create a waypoint over a town then I (quite rightly) do not have the 'land here' option available for that waypoint. However if I have a POL at an airfield waypoint I can then drag this and drop it onto a town and the POL attribute is not reset.

1. You're essentially asking for a new feature here. Please bear in mind what I wrote above about the limitations of what we're doing in the first instance. If you've got a multi-sector route and the selected sector is sector number 2, then SkyDemon navigation services essentially knows _nothing_ about sector 1 while you're flying. This could be a potential enhancement in the future, and that's the idea behind doing it in stages.

2. This is harmless and by design.

Another supporter for multi-sector plans here - being based at a non-UK non-customs airfield means all my flights back to the UK and the return are multi-hop to clear customs. I'll have a play with the MSI above, but for reference the Jepp method of a 'Route Pack' is adequate

Tim,
this new feature is highly appreciated ...

As I see based on your posted Beta, witch is running great on the Mac using Crossover, it works perfectly on the iPad as well.
One key question I got in mind: right now to enter different leg properties you select the leg and enter all data in the usual "Flight Details" Dab.

Unfortunately the colors are not changing regarding the leg you are selecting. It would be much easier to validate with leg you are editing, when the color of the legs between the start - land here - end would have different colors. Like a "active" vs inactive" state.

As a request I would prefer that all legs are edited in one single "Flight Details" window, witch would be simply extended each time a leg is created .. a color code also here would be appreciated as well.

I understand and support your philosophy of leaving much in the responsibility of the pilot vs automating through SD (e.g. Fuel calculation over several legs.
To make it easier for the pilot/user I would find it supportive to just have this one "Flight details" tab with several legs underneath, as this would make the manual entering of data much easier .. 
for example - pilot enters first start time and fuel as full; as SD estimates arrival time / duration as well as fuel consumption the pilot can simply enter now the respective data in the following leg as a starting point .. ideally SD would pre populate in light grey the minimum date as an estimate from the leg before to make it even more convenient for the pilot to actively enter the data / confirm that data, or in red as the fuel would not last for the second leg as a warning ...

I know some of this may definitely something for above and beyond your current scope, but in general this new feature is a massive plus for SD.

Keep up the great work and enhancements
Markus