stuart wrote in Sat Sep 22, 2012 7:58 am:Regarding highlighting, I think a better approach will simply be to display an aircraft icon at the appropriate location. That will allow us to indicate runway direction and neatly sidesteps the whole issue of modifying an existing layer. We will want an aircraft layer for the moving map anyway.
With the modified code, this will be fairly simple - for example, adding a new "navaid" layer took me less than 2 minutes now (in this case, I don't manually draw the image, but instead use the NDB symbol from wikimedia commons):
Adding another layer for route manager waypoints would be similarly simple.
That said, there's still some ugly code in it, and we'll want to get rid of it so that the API can really evolve.
For example, while the concept of a "map" and of "layers" is fairly encapsualted now, updating the layer is still done "manually" in a separate callback. This is something where we should really use a MVC based design to update the layer in a decoupled fasion. That would be a huge opportunity to get rid of lots of code and move it to the canvas folder instead.
Also, this will almost certainly be required for dynamic maps.
From a performance/resource usage point of view, it would be great if we could extend the canvas such that:
- ...it renders groups to textures and merges them on demand
- ...it differentiates between "dynamic" and "static" map layers (i.e. aircraft/traffic vs. fixed positions)
- ...it is possible to explicitly configure an update interval in hertz for a map, i.e. in most cases, 0.1-5hz would be sufficient
- ...groups may refer to an existing group, that would allow us to reuse vector images very easily, without duplicating the data over and over again
I'll try to clean up the code a little and then post it here, so that you can have a look.
Like I said, I didn't bother "fixing/porting" the "runway/parking highlighting" feature properly.
EDIT: https://gitorious.org/fg/fgdata/merge_requests/95