Future of the web frontend

[u-an-i]

I contemplate making the ol-map plugin a first-class option to the current map, settable in the web frontend settings menu (opened by the purple arrow).

This would want to have all current map menu commands be available for ol-map and be executed by same function calls so that overlaying plugins can work with both.

Overview of features:

• auto refresh: partially available already (by default a strain on the web server actually)
• now: available
• center aircraft: available
• here: not available yet, possible (requires making auto refresh an option)
• fit view to waypoints: not available, likely possible with the current web api
• find icao: available
• prevent standby: independent

Control move by click should become an option for ol-map: on touch devices the user might want to simply do a simple touch to advance and not drag.

[u-an-i]

a map commands API merging the current map button functions and the injected map code update would likely be in order.

[u-an-i]

@KOKAProduktion , @albar965 for your minds

[albar965]

Map commands API sounds great.

1. Click on airport or navaid function to get more information. LNM can provide screen coordinates for most rendered point objects within viewport.
2. Automatic update if LNM map changes with new measurment lines, for example. Client sends request to LNM and gets a flag or timestamp which can be used to detect changes in map theme or other display options.
3. Replace HTML fetch with JSON to give more flexibility for the client.

[u-an-i]

Keep them coming, I have no intention right now to start right away.

re some thoughts:

1. ol-map supports clicks on objects and a web api response is returned but other than refreshing the object markers i don't see something visual occurring, such would have to be added to the ol-map library in KOKA's repository itself currently.
   Regarding the static map, the web api would have to support getting infos of objects at a pixel coordinate clicked within the current image of the current state of the web server (by the developer requesting that info by a request containing the pixel coordinates to it) OR the web api needs a command to get all pixel coordinates of all objects within the current image of the current state of the web server (including those objects associated data). I did not see such a command in the current spec. You mean LNM already has all data present and "only" a web api endpoint needs to be added? This would be awesome!
2. Yes, the frontend would need to poll such in regular intervals and then refresh. With auto refresh enabled, the static map already gets those display updates as the static images, right?
3. "fetch" (fetch(url)) is a browser-native JavaScript command to get arbitrary data asynchronously from a url, that data can be JSON. It would be used when working with the web api. The static map images currently are returned by a simple update to the src of the map img. Were you thinking of something else ?

To me just occurred that rather than making static map and ol-map an option in the settings of the frontend, once ol-map optionally supports controlling movement by click rather than drag, we could just use ol-map only :) For this the integration of KOKA's library's repo into the LNM repo directly might be benefitial (the idea being anyone with access to the shipped LNM installation can modify any part of the web frontend in the web folder to his or her liking (in case they like to do something special without creating a distributable theme or a plugin)).

[albar965]

1. I can collect all drawn features in a cache. For a first implementation I'd limit this to airports, VOR, NDB, waypoints and maybe userpoints. Things are already cached but there is more filtering going on while drawing. That's why I have to remember features while drawing.
2. Ok. Maybe not needed if auto-refresh already covers it. What about cached images? Did not try it yet.
3. Sorry. Did not make this clear. Not the map. I'm talking about the airport and flight plan information which is returned in HTML generated by LNM.

Just noticed that aircraft trails do not appear in the OL map. Have to check.

For this the integration of KOKA's library's repo into the LNM repo directly might be benefitial

Git repo links. Don't know the exact name of the function but it's doable.

[u-an-i]

1. :) If you can provide the extension to the web api I will make use of it (for the static map first). The web api already provides /map/features which returns airports, ndbs, vors and markers but it requires a latLon rectangle. Perhaps extend it so that it returns that data for the current image state when no parameters are contained in the request.
2. Cached images would be an issue, true, ol-maps does have mixed tiles for about 3 iterations of zooming through an area after LNM display features change (map theme). I checked: The source of the library sets it to an options value which is undefined thus, according to the ol docs "cache size. Will auto-grow to hold at least the number of tiles in the viewport". This currently is obviously small enough for display features change but it also is too small to be of sensible use for the frontend. If I would increase it to 10000 tiles or so (which I would like to do), ol-map will have an issue of mixed tiles!
3. Ah yes, of course, that was 1 original reason for a web api. I never got around to replace those. I will intend to work on them.

[albar965]

1. :) If you can provide the extension to the web api I will make use of it (for the static map first). The web api already provides /map/features which returns airports, ndbs, vors and markers but it requires a latLon rectangle. Perhaps extend it so that it returns that data for the current image state when no parameters are contained in the request.

Will do but give some time. Here is da issue for details #1142