With the latest changes in git, the performance is already pretty good for "static" maps. Zooming is a different matter, and so is panning.
But that can probably be addressed during the next weeks, I think we have discussed some pretty good ideas already.
- By default displaying the airports within 100nm, so this dialog can be used to find some nice airports to fly to. That was one of my original motivations for doing this work - I like to do short VFR flights from a random airport without having to spend lots of time planning, so knowing the distance, course and airport information in-sim makes that easier. Not exactly realistic flight-planning, but fun enough.
Supporting multiple airports didn't seem too difficult after all the refactoring that I had done already, and it will also be needed for all the other efforts (mapwidget, navdisplay, route manager) so I gave it a quick try:
This uses now multiple canvas groups to emulate layers, so that groups can be individually toggled, in other words toggling the tower view, no longer updates the the whole tree and doesn't redraw taxiways/parkings etc anymore.
OOP-wise it's still not quite there yet, because I didn't want to rewrite all the original code, so I just put some wrappers around the original code.
- Indicating the selected runway direction in the highlight.
- Displaying the highlighted parking position irrespective of the checkbox state
My original refactorings sort of "broke" this ... I have now fixed the runway highlighting, but I am not sure if we should even use this approach at all?
The canvas system is prepared for multiple addressing modes, currently "by-index" is the default. But like you say, without a proper data model, by-index addressing is pretty poor.
Personally, I'd suggest to use "by-name (by-id)" - and then just look up "/by-name/map/ksfo/28R" or something like that - we previously talked about that, and I don't that it would be complicated to support this, Tom?
Just let me know how you want to proceed to merge my changes, if anybody else has worked on the Nasal, just post your patches here, so that I can merge them beforehand - because I have touched tons of places ...
Also, I'll probably need to clean up the code quite a bit - otherwise, just keep in mind that we want the API to evolve like this, so nothing is set in stone, and we are only just coming up with the requirements, so many things I added are probably like to be changed or even removed anyhow, so please don't worry about the amount of code. In the long run, I hope to provide a full OOP interface (like the rest of the canvas), but with a MVC design for different types of "layered maps".
That should make it very easy to add new layers (e.g. multiplayer, ai traffic, navaids etc) , so that arbitrary maps can be scripted with just a handful of Nasal code.
Thus, I am hoping that we can collect all code and clean up/refine things later on.
Ideally, all of us could now work on different dialogs (i.e. airport selection, route manager, map widget, navdisplay) - so that the backend code gets improved for different use cases.