Thread: App for vector renderer maps, using OpenGL ES 2.0
View Single Post
rinigus is offline rinigus
2017-09-19 , 06:17
Posts: 1,414 | Thanked: 7,547 times | Joined on Aug 2016 @ Estonia
#47
Originally Posted by Zeta View Post
I followed in QtLocation 5.9 source code how they were handling the MapPolyline elements that can be added to the Map QML element.

So far, I found out that :
qgeomap.cpp adds all those items in a "m_mapItems" list as "QDeclarativeGeoMapItemBase"

As subclass called "QDeclarativePolylineMapItem" is in charge of the Polyline element, which is then drawn directly with OpenGL calls on top of the map.

This uses an internal "MapPolylineNode" class, which is doing the OpenGL call (things like "geometry_.setDrawingMode(QSGGeometry:rawTriangl eStrip);" )., through the "geometry_" variable.

The QDeclarative*MapItems (polylines, polygons, ...) exist from Qt 5.0 from the documentation, so it may be possible to restore this functionality by making the MapboxMap a derivative of the GeoMap class, and adding some glue (if the one from 5.6 has enough) ?

The second way would be to code that behavior in a custom class, like MapboxMap, but keeping the raw GL way (to let the GPU handle the coordinates changes, and not computing them by hand which would be difficult).

And then, there is the solution rinigus presented, to add a layer through GeoJSon to do this in the MapBoxGL Engine.
I am not sure yet what the advantages and drawbacks of each solutions are, especially the overhead of adding a layer compared to a few direct GL calls.
When compared to QtLocation, we don't have to be compatible with the other modules. This makes it significantly easier. My reasoning for going with GeoJSON is that
  • originally supported by Mapbox GL Native (same as for Mapbox GL JS)
  • simple to implement since it directly interfaces with QMapboxGL

As for comparison in terms of features: using GeoJSON we can position the added features in between the map layers. As far as I could understand, you style the added features using the same styling as you do for the map. For example, its possible to add calculated road as a layer after the road on the map but before road names layer. As a result, your calculated road is visible, but does not cover road names. As a limitation, it was mentioned that MapboxGL added layers don't support transparency. However, with the ability of positioning the layer accordingly, I don't think its a problem.

There is one complication that has to be taken into account while writing a widget - QMapboxGL object lives in the rendering thread, not main thread. We can have an access via update method of the widget when you are allowed to sync, but otherwise its "no touch" condition. The second complication is that, in SFOS, when you minimize the application, the corresponding OpenGL scene is destroyed. So, when the application is restored, the widget is constructed again and we have to add all the layers/sources/paint properties.

I am writing now the part that will keep track on sources/layers/ and other properties and would patch or play back all the needed (non-removed) features on construction. It would probably take few evenings to implement it, but nothing really major. When ready, I'll make a new demo.

Originally Posted by Zeta View Post
If stucked, we may ask somone of Jolla staff for that one (maybe during a community meeting, or through TJC) ? Having a high performances mapping/routing application is probably something they would like to have in their catalog, seeing how limited the default maps application they provide is. Not sure who is the OpenGL specialist there. Stskeeps obvioulsy comes in mind, and back in time, there was also w00teh. But I am sure there are others...
If we have a good program to show, the interest will be there, I am sure .
 

The Following User Says Thank You to rinigus For This Useful Post: