merspieler wrote in Tue Jan 12, 2010 7:40 am:Since you know MapStructure so well... how do I _properly_ implement a moving map like these:
https://www.airbus.com/newsroom/news/en ... craft.html
MapStructure is all about identifying static elements and dynamic ones - to selectively update things that change, unlike things that don't change.
So the next step is to logically divide a "map" into a set of "layers", that contain layer-specific elements/information (think taxiways, runways, buildings, compass rose, text labels) - as a rule of thumb, anything that can be toggled on/off separately, could go into its own layer (for the sake of simplicity). Also, anything that responds to scale (LOD) needs be handled correctly - e.g., switching the range of map display, does not invalidate the previous data (model).
Basically, the taxiway layout of the airport no longer changes once it's initialized - so you primarily need one layer for the taxiways, and use other layers for more dynamic stuff.
We developed MapStructure so that people can easily reuse existing layers. The idea was to allow people to find related layers and only adapt what's needed. In this case, I would use the taxiway layer or ThomasS' ground services layers to get started quickly - and then copy/adapt those layers as needed, styling I would add once all other functionality is working:
https://wiki.flightgear.org/Ground_Services
The next step would then be to add layers for other stuff (e.g. runways) - again, it's best to look at what we've got already, and then copy/adapt existing layers for your OANS:
https://wiki.flightgear.org/Canvas_MapStructure_layers
For things like scaling/rotation, it's best to create the geometry layer separately - and then use a transformation - just like the compass rose is handled: there's no point redrawing a compass rose, if all that's changed is the heading/orientation - equally, if you need to render the airport diagram using different orientations, merely use a rotation/transform
You can also exploit internal knowledge - for example, for the ND, we knew that aircraft support toggling ranges based on a fixed set of ranges:
This means, range toggling can happen between 10/20/40/80/160/320 miles.
That also means, the two "neighboring" of any given range are most likely to be selected at any given time, so you can pre-create the model for that switch - and you can in fact allocate all symbols into groups based on the CURRENT display range: https://wiki.flightgear.org/MapStructure_Optimizations
At that point, you can always use the current range +1 (say 20nm instead of 10) and then update the sub-layers by shuffling elements from one layer to another.
That way, you will always have a pre-created layer, which you can hide (20nm contains all layers below it, whereas 320nm contains all layers in general). At that point, toggling between layers merely entails updating and hiding/showing elements - i.e. you merely propagate elements from one "group" to another - instead of deleting/re-adding all layers/symbols at once:
From an optimization/performance standpoint it's good to keep asking yourself a number of questions:
- how many layers are needed for the new feature ?
- which existing layers are related/similar ?
- how does the new functionality differ ?
- what's static/dynamic on each layer (static stuff does not need to be updated frequently)
- how are update heuristics affected by toggling display-specific modes (range/LOD, airport, labels etc)
Also, suppose a single cockpit shows multiple independent instances of this display in the same cockpit (think captain/first officer): how can the underlying data (model) be reused without multiple instances querying the Nasal/core side unnecessarily - for instance, if both instances show the same airport (ICAO identifier), you can simply cache/reuse the result from the other instance.
Or, if two instances show the same display using the same airport, with different range/LOD, how can the data be structured, to avoid unnecessary overhead ?
Finally, there's the multiplayer (dual pilot/shared control) factor, too - which is overlapping with requirements due to multi-instance setups - at that point, you'd probably want to use Emesary to structure the layer.
(FWIW, I don't think we currently have any geometry for buildings available - so you might want to use a static raster image as a placeholder or reach out to the scenery folks/core devs to learn if it's possible to retrieve building shape info procedurally, or add what's missing to the Nasal cppbind interface)
PS: I think omega95 (?) implemented the OANS several years ago, so you might want to run a forum search - not sure if that was using MapStructure or pure canvas directly.