feature/webapi-marble-tiled-output

[KOKAProduktion]

Hi @albar965, hi @u-an-i,

coming from #776

here's a new PR providing customized Marble image output for tiled usage via the API.

It's actually doing the same thing as "/mapimage" but without dynamic visual elements which would glitch between the separatly retrieved tiles. See the API contract for call details.

It is compatible with my current OL implementation utilising also the new sim info calls from the web API for aircraft tracking:
KOKAProduktion/littlenavmap-openlayers#1

However there are some points to consider to determine possible issues up front:

• This PR introduces another MapPaintWidget instance so this results in 3 running instances. I'm not sure if that's a resources issue?
  • App UI
  • Web UI
  • Web API
• OL hits the image retrieval method quite hard, like 16 times simultaneously on initialisation. Afterwards it only calls for tiles which become visible through user interaction (pan, zoom, etc.) or aircraft tracking. In my opinion this probably increases the load on LNM significantly so maybe we should watch or even profile this. I'm open to any suggestions here although i didn't encounter any issues with this on my host so far.
• It appears to me that the Marble output is somehow resolution constrained. For example i can query for an image of 500x500px but i can't go below 200x300px. So the width appears limited to a minimum of 200px and the height to a minimum of 300px. This doesn't obstruct OL since it can handle non-square sources but could limit other consumers. @albar965 do you know anything about this limitation?

Please tell me if you have any concerns about these points. Otherwise i think this one is stable to merge.

Thanks for your time and hear you
Cheers!

Related: Milestone 3 : LNM Web UI OL Display Integration

[u-an-i]

easily assessable implementation. I wait for your OL implementation PR to see it in action.

[u-an-i]

@KOKAProduktion @albar965 I'm intrigued whether tile generation can be spread across cores like I did for the random flight plan?

OL requests multiple tiles in parallel or does WMTS want 1 request and delivers all at once? (I skimmed over the Standard document after i was aghast it's more than url?lat=x&lng=y&w=A&h=b)

[KOKAProduktion]

@u-an-i that's a great idea! Thank you! Although I would need guidance/assistance for this...

OL requests multiple tiles in parallel or does WMTS want 1 request and delivers all at once? (I skimmed over the Standard document after i was aghast it's more than url?lat=x&lng=y&w=A&h=b)

OL requests one tile per call. On initialisation and map navigation it calls visible/required tiles simultaneously.

We haven't got to WMTS yet. Currently my OL implementation uses a custom source implementation which reuses the existing pattern of querying by a lat/lon rectangle. OL provides the tile to lat/lon rectangle conversion here:
KOKAProduktion/littlenavmap-openlayers/src/ol/source/LNM.js#L89-L102

WMTS requires information about the whole tileset up front in order to query by tile id's directly. e.g. url?x=1&y=1&z=1
I haven't worked much myself through this yet... Not even sure if we need to implement this standard.

I'm intrigued whether tile generation can be spread across cores

As far as i understand the HTTP-Server implementation (stefanfrings.de/qtwebapp) already provides multi-threading requests:
/src/httpserver/httpconnectionhandlerpool.h#L28-L31

On the other hand I've stumbled across this, which indicates serial processing:
/src/httpserver/httpconnectionhandler.h#L34-L36

I believe currently the calls to the web API get synchronized at the latest point via the RequestHandler::serviceWebApi signal to the single WebApiController instance if not already before:
/src/web/requesthandler.cpp#L79-L80

So I don't have an idea right now how to spawn WebApiControllers along with the requests efficiently and what inflictions there might be. I would be glad to hear your input. Also if it's worth the effort... Since it doesn't sound that quick and easy to me.

Thanks and cheers!

[KOKAProduktion]

Hi guys,

I've added the basic OL implementation (dist of KOKAProduktion/littlenavmap-openlayers#1) for testing purposes.

It is accessible from the browser via /ol path.

Also the OL map can be included inside any HTML page by adding:

<script defer="defer" src="ol/index.bundle.js"></script>

and adding a

<div id="map" class="map"></div>

to the body.

There are some visible issues:

• Marble's pixelated source map image output #789
• Unpretty initial zoom

Thank you for your time! Cheers!

[albar965]

I see no issue with an additional Marble instance but I'd keep the web API like the web interface optional. Means: Can be enabled in the menu or not in case users run into port conflicts.

No idea about the limited output size. Never ran into this. But: See below.

File generation across different cores: I doubt this is doable with the Marble widget. I'd rather look at the guts of Marble since there are several layers for HTTP downloaders and caches. These definitely use multi threading and are maybe even thread safe.

Should I merge?

[KOKAProduktion]

@albar965 , not yet please. I have to elaborate some issues and decisions for us to discuss. Until then this PR serves as a starting point.

Thanks and cheers!

[KOKAProduktion]

Closing in favor of

• feature/webapi-mapfeatures #826