LNM - OpenLayers Integration Roadmap

[KOKAProduktion]

Hiho @albar965, hiho @u-an-i,

i finally got some thoughts together after diving deeper into LNM's structure, its repos, your discussions and the littlenavmap-openlayers implementations current state.

Wow, @u-an-i you're really tackling a lot! I admire your drive and ambition to modify/refactor and to introduce a lot of new ideas. I hope it's ok for you, if i present my current view mostly focused on the OpenLayers-related topics only and link to your proposals wherever they overlap. I'm sure we can manage to join forces to contribute something cool to @albar965's LNM project.

---

LNM - OpenLayers Integration Roadmap

At the time of writing LNM is serving the Marble rendered map image via the built in http-server for requesting web clients. The UI/UX logic for map interaction besides other features is a custom implementation.

OpenLayers (OL) is a web-based mapping framework written in JS under the BSD-2-Clause License providing the following features i.a.:

• Retrieval and rendering
  • of both tiled and untiled map sources organized on layers
  • of vector data
  • of stylable map features like clickable items
• Popular map navigation UX (drag to pan, mouse zoom, etc.)
• API to manipulate the maps behaviour programmatically (e.g. animate to position, etc.)

The following comments show a possible roadmap based on my review and assumptions. Please feel free to correct me and to add your thoughts on the topics!

[KOKAProduktion]

Milestone 1 : LNM Web API

The idea is to expose dynamic elements information (e.g. position and appearance of Airports, VOR's, the users aircraft etc.) which is currently being composed onto the LNM Marble image output, via a Web API.

Requirements

• The ability to retrieve the required LNM data in the built-in webserver context
• Extending LNM by a web-based API to query interactable map features (e.g. Airports, VOR's, etc.), the users aircraft (e.g. position, orientation, vector flight path etc.) and "output image static" elements (e.g. Contributions, Wind indicator)

Thoughts

Creating a strict API contract allows full separation of concerns between LNM and possible web UI implementations. Both sides could develop independently as long as they satisfy the contract.

Related

• possibly adding holistic JSON support preparation to any oo C++ (17++) project #663
• Plugin interface #150
• Extend web server with JSON data interface #397

Possible Solution

• Defining a sensible API contract using
  • OpenAPI
• Providing the build in webserver context with the required data
• Extending the built-in webserver by a JSON/RESTful API satisfying the contract mentioned above using
  • JSON Support in Qt
  • nlohmann/json as proposed by @u-an-i

PR

• feature/webapi #776

[KOKAProduktion]

Created a LNM Web API proposal PoC at: #731

[KOKAProduktion]

Extended API proposal by

• simulation aircraft info
• UI info

at: #772

[KOKAProduktion]

Minor fixes at: #776

[KOKAProduktion]

Milestone 2 : LNM WMTS API (optional)

The idea is to modify the LNM Marble image output web routes to satisfy a strict WMTS API definition in order to increase compatibility with mapping clients like OL. This could come in handy if OL should become abandoned/obsolete and would require replacement by another WMTS-capable mapping solution.

However this should be considered optional as its map image retrieval would become obsolete with milestone 5.

Possible Solution

• Modifying LNM Marble image and data web retrieval routes to reflect a standard defined API specification
  • OpenGIS Web Map Tile Service Implementation Standard

[KOKAProduktion]

Milestone 3 : LNM Web UI OL Display Integration

The idea is to replace the existing web ui map display of the rendered Marble image from LNM by an OL implementation to remove the need for custom mapping and map navigation logic and to provide a popular map UX. LNM remains serving the Marble images as the map source but requested in multiple tiles like a WMTS server instead of a single image.

Proof of Concept: KOKAProduktion/littlenavmap-openlayers first presented at #622

Requirements

• LNM Web API developed at milestone 1
• (optional) LNM WMTS API developed at milestone 2

Related

• fluid zoom levels for web map ui #665

Possible Solution

• Modification of the LNM Marble image output rendering for tile-based display
  • Hiding of common/static elements (e.g. Contributions, Wind indicator)
  • Hiding of interactable/dynamic elements (e.g. Airports, VOR's, the users aircraft etc.)
• The actual OL implementation assembling the data retrieved from the Web API visually to enable interactability with the map features and to avoid rendering issues with already composed images.

PR

• feature/webapi-mapfeatures #826

[u-an-i]

but they have no benefit whose achieving they are purpose-built for to achieve...

You mean that they are too generic and therefore have to be bended to our purpose?

No, they use concepts but those are not a solution to a problem, eg. MVC is just MVC (a naming), it's not pluggability like a DirectShow graph in which 1 part can be exchanged and everything still works right away, eg replace MySQL by PostgreSQL or replace view 1 by view 2. Read further on.

• strict typing (TypeScript)

  • More "strictness" in JS makes the code more transient to the backend code language, enables "pre-compiling", consistency checks and sensible auto-complete. In my opinion it eases development and reduces errors.

TS is TS -- which caters for C++ developers (or perhaps Java and C# ones) -- and can be used separately, it is not a framework, throws away the strengths of JavaScript. Similar to JS 15++ (ECMA JS 6++): ECMA should have build upon the strengths of JS, instead they created ambiguity ("this"), unlegibility ("let" is l 1 | or I ?, => thin lines, is () now not a call anymore?), uneasy graspability (what does/should "let" mean?). Whether the advantages you list can/could not be achieved for plain JS I think not. "Luckily" you wrote "imo" because the effort to jump on TS and stay within certainly does not ease dev but requiring a compiler that one might catch errors before the JS runs on a deployed system.

• MVC (e.g. Angular)

  • I like MVC :)
  • Templating

name your functions "model_X", "model_Y" in plain JS and your are (for rather most intents and purposes) done.

• Live-data binding (e.g. Angular, React)

  • Fully managed UI "loop". No need for setTimeouts or "callback hell" anymore.

I don't know what timeouts can be sensibly applied here and callbacks are just the necessary async continuation (Promises basically are a rename only with different syntax (similar to different mathematical notations)) but bindings give you hierarchy headaches, conglomeration concerns I don't want to have.

The white teeth advertising you propagate does not tell the truth.

This does not mean it cannot be helpful. They are tools and possibilities and given a problem they make solving easy to use them is sensible.

I'd say they just extend the tools you have available for implementing your project. The less I have to implement, the better.

But they do not spare you any implementation of the code required to achieve a real world consumers comfort. "MVC", "DI" is a personal baggage you might like to abide by, nothing required to solve an issue.

needing Monstrous effort to apply for the first time... additional software on your pc, obscure storage locations, servers started on startup..

Can't really confirm that. My experience was extremely mind-blowing on what can be done with plain JS inside the node.js universe and how easy it is to apply.

Yes, plain JS can "do everything", but A can't

Angular and React can be challenging in the beginning but the reward is really f*** huge in my opinion! Of course I'm not claiming they are here to stay forever, but XMLHttpRequest usage got also less popular since fetch is natively available if you get my point.

fetch eases XHR (just "fetch" instead of reading docs, implementing by writing many lines of code and catches), A complicates JS (need to read huge docs first, read TS doc first, decipher their intention, repel their boasting claims), A also is 50 % TS and 50 % reinventing the wheel of plain JS, locking you into them.

and the core of your to-be original (because if not original, why were you creating it?)

I'm mostly writing applications for to be applied not to be original. If there is a stable and relatively established solution already available for a problem which is not specific to my project (like handling a map), I'll thankfully use it. The same way I'm building on top of LNM instead of writing my own fully integrated simulator mapping, weather, traffic, flight planning and monitoring app :)

LNM and OL are comfort and solutions already, "MVC" isn't.

[...] from the jaw of the jail they are in

You can still keep your business logic in plain JS inside, if you're worried about those frameworks lifetimes.

does require (a bit) extra effort but yes, right.

...and once it is, A has released 700 new version the readers past is useless

Yes the update cycles are fast, but this also means free out-of-the-box updates for issues you don't want to worry about. Also, it's not that bad anymore as in node.js's early days.

You have to worry about excatly about every update even in ..1 A broke compatibility (as far as I've read), before-to-last major release requiring weeks of rework (depending on project size, as I've heard) and now there is even a newer release (as I've heard). By wanting to write software to solve a real world problem and thinking about this and planning and implementing it, months if not years of net developer time, headaches and sorrow could have been avoided, but A is about hacking theoretical theories and bragging.

kis in every way

And that's probably the philosophical question here: Would you like to create a custom solution from scratch every time...

Like written before, A does not offer anything one would want sensibly to write and the core code has to be written. libraries like OL help, "frameworks" like A lock.

Meaning everyone has to read-in into custom solutions everytime. Omitting the fact that they quite often lack documentation and the author has to maintain updates inside a changing environment.

This is exactly what is occuring with A ! The dependency hierachy of likely every A project is different to every other A project and so likely is the code and every A update has to be maintained and possibly lacks documentation of what they broke this time.

In my opinion it's conventions and standards which make focusing on specific aspects of implementation work easier, leading to less specific code which translates to "simple" for me. At least I don't want to think about on how to fetch data or how to update a value in the UI every time.

Yes, of course.

I can just look up and copy/paste the example from the corresponding frameworks docs...

Here you "fail": copy/paste you can from your previous projects as well. "Framework" already implies complex and "doc": unfortunately "good luck" finding that part documented.

If it's for the kicks I understand the urge to create individual solutions. But not for challenges/problems which have already been solved...

This appears to be your whole derailedness of mind: no problem of your actual goal has alreay been solved (by any of the frameworks I have read about, their doc or worked with)!

I hope you're not mad at me :) All paths lead to Rome...

I'm not. Your reply turned out well.

If you haven't already tried out node.js, Angular and/or React please do! My guess would be, that you eventually could fall in love with at least TypeScript :)

I have (sans using React), wrt the frameworks. TypeScript I might have liked 20 years ago when I would have come directly from C++. But during working with C++ I realised it leads to attempts to engineer things which don't need enigineering, locking one-self into hierachies later not suited anymore all while costing a lot of thinking about how to express something in code rather than having everything thought through and planned before and then only implement. This is particularly true for the creatom of tools such as frameworks are which have no goal on their own. If you have planned to present a certain comfort to a user and thought through and planned all which is necessary, an OO language might make things easy, but JS is an OO language.

Thanks for your thoughts and cheers!

Likewise :) !

[KOKAProduktion]

Hiho @u-an-i,

hmmm, you gave me something to think about... Thanks! I'm not sure if I'm with you on all the points. But for now I'll retreat and prepare my next strike :)

Just a single remark since you also seem to avoid writing out the frameworks names:

The white teeth advertising you propagate does not tell the truth.

I didn't mean to advertise anything. I don't care whether a project uses framework A, framework B, none or something proprietary. I have to adapt to it. I'm just enjoying the ride learning from others. Sorry if I broke some code mentioning them directly...

I feel that this might go for a longer intense discussion, so maybe we can postpone it until i get this milestone done? :)

For now I'd just need confirmation from you and @albar965 if it's ok to:

• Keep the OL implementation project just about mapping and map interaction handling
  • Embeddable and configureable inside the current Web UI or any HTML/JS
• Keep the OL implementation as separate NodeJS project/repo
  • Only project build/dist output merged into LNM's web/ol

Thank you for your time, thoughts and cheers!

[albar965]

For now I'd just need confirmation from you and @albar965 if it's ok to:

* Keep the OL implementation project just about mapping and map interaction handling

I leave this up to you.

  * Embeddable and configureable inside the current Web UI or any HTML/JS

Yes. Maybe think about a standalone version or a GUI-less LNM option later. Neh. Just thinking.

* Keep the OL implementation as separate NodeJS project/repo

Yep.

  * Only project build/dist output merged into LNM's `web/ol`

Or keep as a separate project but LNM is not usable as a library. No idea. Git sub-modules to minimize dependencies perhaps? Git modules look promising.

In general it would be nice if there are no downloaded third party libraries, fonts or Google analytics links. Especially the analytics I hate.

[u-an-i]

I feel that this might go for a longer intense discussion, so maybe we can postpone it until i get this milestone done? :)

Yes, sure! I'm not thrilled to have this conversation and am glad you took in my "observations" indulgently apparently, but I (guess I feel I) am happy to read any advantages and benefits you put forward.

[KOKAProduktion]

Finished OL integration into LNM web UI at #826

[KOKAProduktion]

Milestone 4 : Control LNM via Web API

The idea is to extend the API established during milestone 1 by methods controlling LNM itself. This could for example provide simple functionality like changing the map theme or more complex processes like creating/modifying the flight plan. Or even add all functionaility the in-app Marble widget view offers for milestone 5.

Requirements

• LNM Web API developed at milestone 1

Possible Solution

• Extending the API contract by sensible methods to expose to the external client using
  • OpenAPI
• Evaluation/Modification of LNM to allow control input coming outside the main thread
• Implementing defined methods

[KOKAProduktion]

Milestone 5 : Replacing LNM in-app Marble with an OpenLayers web view

The idea is to replace the Marble dependency from the project to decrease build setup complexity and issues. If the solution from previous milestones proves itself reliable and satisfying it may serve as the replacement.

Thoughts

As i understand Marble and OL are solutions serving the same purpose (Mapping) in different languages/environments. They even have similar source adapters. Also i don't see any performance-critical obstacle which would disqualify an in-app web view based solution. The only crucial thing to find out would be how good/reliable the communication between the Qt WebView JS and the QT Application works in my opinion.

Related

• #180
• fluid zoom levels for web map ui #665

Possible Solution

• Altering the OL implementation to retrieve map image data from Marble's current sources directly instead from LNM Marble image output
• Complementing all missing interaction logic currently provided by the in-app Marble view (if any)
• Replacing the in-app Marble Widget with a Qt WebView displaying the OL implementation

[KOKAProduktion]

Commitment

@albar965 if you find that roadmap sketch sensible I could commit myself to milestones 1-3 on both Qt/C++ and JS parts but sadly without a specific time frame, not only for obvious reasons but also because some points still require a bit more specification.

I've managed to build LNM, thankfully to your building instructions, but coming from the web and mobile apps world my Qt/C++ commits would certainly require reviews from a Qt/C++ pro. Also I'd probably have a lot of questions during the process :) For now I'd like to say, that the sources are pleasant to read!

As for the milestones 4 and 5 i'd say, let's check again when we get there :)

Also I'm totally open to split up the work @u-an-i. If you keen on particular parts, let's elaborate a more specific plan together!

I'm looking forward to your comments. Have a nice evening!

Cheers!

[u-an-i]

thoughts:

• how can I express my awe?

observation:

• "All Good Things": status quo précis, target state aperçu, apropos linking, strategy, segmentation, conducive breakdown

fears:

• is the "Popular ... UX" not not-liked by me?

I imagine operating an OL map delivers a smooth and responsive behaviour at hardly any cost (technical, physical, financial nature), quite the contrary of the latter I imagine in fact: easy to apply, comparably lightweight and free. (i visited their website and saw your application of them.)

[KOKAProduktion]

Thank you for your kind words @u-an-i !

As for the fears, I'm not claiming that this UX is the one and only solution. Also I'm not an aviator and I surely don't know all use cases of LNM (yet), so I don't want to force anything on anyone. Neither users nor dev's :) It's just my own impression, so please express any concerns or doubts anytime!

If you don't object, I'd soon start writing the OpenApi specification for the LNM Web API mentioned at milestone 1 as a base for further discussion. Or do you have already planned/started something else around that part?

Once again, thx and cheers!

[u-an-i]

i haven't planned and haven't started something around that.

look at the beginning of #661 for your consideration

[albar965]

Oi!

I cannot say that I do not like this approach. 🙂

What I like:

• Can be done in steps (as you described) without breaking main LNM plain and old UI.
• Getting a JSON web API as a welcome side effect.
• Makes old and ugly networking code obsolete.
• Makes Marble obsolete.
• Opens possibilities for plenty of JS add-ons/plugins as a side effect.

This will not be done in a year for sure. Just saying. 🙃
Converting current functionality to web UI is a real challenge, I'd say.

BSD license: Not sure if this is compatible with GPL. No idea.

Any plans to use an UI framework like Vaadin?

BTW: Very professional presentation! Like a lot. 👍

Alex

[KOKAProduktion]

Hiho @albar965,

Cool, I'm glad you like it and thank you for the props! I'm very excited to get going!

This will not be done in a year for sure. Just saying. 🙃
Converting current functionality to web UI is a real challenge, I'd say.

Yeah, talk is cheap... I know :) I've already had some "What have i done...?" moments browsing through the source :) but I'm still onboard and hopefully we'll be able to add usable features already on the way to the top.
As mentioned I'm still getting myself more into Qt/C++ as well as LNM itself and writing the OpenApi specification for the future LNM Web API during the process. I hope it will serve as a base for further discussion but please give me some time.

Opens possibilities for plenty of JS add-ons/plugins as a side effect.

Oh yes, that's a sexy one! It certainly raises and falls with the API capabilities.

BSD license: Not sure if this is compatible with GPL. No idea.

As far as i've googled, the BSD 2-Clause License seems to be one-way compatible with GPL as long as the distributions retain its copyright notice.

Here are some of the sources i've got this information from

• https://janelia-flyem.github.io/licenses.html
• https://opensource.stackexchange.com/a/305

Maybe we should have a closer look again before we actually start integrating OL.

Any plans to use an UI framework like Vaadin?

I'm a fan of Bootstrap licensed under the MIT License which seems also to be compatible to GPL as long as its requirements are met.

But I'm not married to it, so if you prefer any other framework I'll adjust. I'd just suggest trying to get away from server-side rendering/templating techniques to a strict REST interface only and independent, consuming client applications.

I've subscribed to the repo's notifications in order to be kept up-to-date but please keep tagging me on related items if i happen to oversee something.

Once again thanks and hear you soon hopefully!

Kosma

[albar965]

I thought about this and I'm hesitant to use the JS inside LNM for map display. Absolutely no problem with a JS plugin interface, though. Can we postpone the map display replacement to a later version? I see an interfacing nightmare, sorry. There is so much functionality on/with the map display (flight plan rubber band, modifier clicks and whatnot). Could be very difficult and work intense.

Add things step by step.
Here an idea for a first step (maybe in next major 2.8):

• Implement JSON (REST?) interface as discussed. I already had user requests for this. Might be valuable.
• Leave the web UI as a read only interface for simplicity. Means: No flight plan editing or similar functionality.
• Port all or most map display configuration options from the view menu to the web UI. Allow people to fully configure their map display, details, theme and stuff.
• Improve information for airport and navaid display. Maybe even add a simple search.

Magic can be done later. 🙂

Lemme know what you guys think about this.

[u-an-i]

reads fine for me

[KOKAProduktion]

Absolutely no problem with a JS plugin interface, though.

You mean browser-based plugins using the REST API (like the Web UI) or some kind of more sophisticated JS interface enabling LNM in-app plugins/extensions?

Can we postpone the map display replacement to a later version?

You're the boss deciding what to focus and what is merged when. No objections.

I see an interfacing nightmare, sorry.

Absolutely, there will be blood. But i do hope that the API contract will help us a bit to oversee and control this.

There is so much functionality on/with the map display (flight plan rubber band, modifier clicks and whatnot). Could be very difficult and work intense.

Definitely as all the objects drawing and map context interaction logic would have to be fully ported to JS. I'm with you leaving this for now.

Leave the web UI as a read only interface for simplicity. Means: No flight plan editing or similar functionality.

As the current implementation or already OL? I'm fine with both but the OL implementation does require some modification on the Marble output to avoid visual glitches/bugs introduced by the tile-based mapping approach. (e.g. dynamic objects glitching between tiles)

The remaining points sound both reasonable and doable to me. Count me in!

Thank you and cheers!

[albar965]

You're the boss deciding what to focus and what is merged when. No objections.

Ok. But still feel free to call me names is something is not reasonable. 🙃

As the current implementation or already OL? I'm fine with both but the OL implementation does require some modification on the Marble output to avoid visual glitches/bugs introduced by the tile-based mapping approach. (e.g. dynamic objects glitching between tiles)

OL would be cool and what you have as a prototype is very fluid. I leave this up to you.

1. No OL. Marble delivers full images as is right now. Inefficient but least effort.
2. Use OL. Slight modifications in Marble to leave out the copyright labels. Not very efficient to download tiles, render a full map and then use this as a tile.
3. Use OL and Marble HttpDownloadManager or another class to get tiles and pass them as they are to the web UI. Most efficient approach. LNM then acts more as a tile proxy. Needs changes and some research on Marble internals.

BTW: I'd limit the projection in the web UI to Mercator since the tiles use the same projection.

You can take your time since 2.8 won't be release soon, i.e. not this year. I'd rather do minor updates which fix bugs and a few cherry picked changes.

Alex