Originally Posted by taixzo

Rinigus, how do you have it running on OnePlus X? I can't install as there are no OS updates past 2.0.2.51.

Originally Posted by MartinK

I guess if there is no marker/polyline support in the widget itself I should be able to use the existing polyline & POI overlays in modRana by putting them on top of the widget and adjusting them accordingly (scale, rotation, offset, etc.). But it could be quite tricky if the widget supports non-90 degree view angles & fractional scrolling. Also synchronization with animations would have to be handled so that the overlay does not lag behind during animations. Coordinate transformations could also potentially by fun in some cases.

Originally Posted by rinigus

Edit: Looks like the same lib is used in J1. In my case (Oneplus X), I have libGLESv2_adreno.so (and others similar, without 200). Whether its an issue, don't know - I am not a specialist on OpenGL.

Originally Posted by rinigus

Looking good. Would you mind to add debug info for qmapboxgl and mapbox-sfos. As far as I can see, its packages qmapboxgl-debugsource and mapbox-sfos-debuginfo .

Originally Posted by rinigus

Actually, you could add http://repo.merproject.org/obs/home:...mv7hl/armv7hl/ as a repo and then just use

Code:

pkcon install

. It will also allow you to upgrade in future, while we hunt for the bug.

Originally Posted by rinigus

If I can get these crash backtraces, we could open an issue for mapbox-gl-native and explain what has been done to make it run on SFOS. Maybe they can help.

Originally Posted by rinigus

As for crashes occurring for J1 and Photon Q: I wonder if its some OpenGL limitation of these devices. I haven't fiddled with OpenGL settings while compiling qmapboxgl, but maybe I should (have to look it up). But then not sure why it would crash on free/malloc calls...

Originally Posted by rinigus

As far as I remember, qmapboxgl does use some QtLocation structures, but I could be mistaken. If this will disqualify it from current Harbour - so be it. I am sure that Jolla will change the rules regarding QtLocation when they manage to get into working on QtLocation 5.6. There is surely a pressure from their customers to get it sorted, maybe just would take some time. In meanwhile, we can distribute via OpenRepos, if needed.

Originally Posted by rinigus

Mapbox GL Native allows you to add all these elements via GeoJSON and styling of the data. This should allow to add POIs, routes, any polygon... See https://github.com/mapbox/mapbox-gl-...window.cpp#L96 for the start of the example.

Originally Posted by rinigus

I am planning to expose similar API as well as write a small wrapper allowing you to add routes/POIs/location icon easier. So, you would not have to draw anything above it, just regular widgets as you do for interaction. Let's see where I can get in a week.

Originally Posted by rinigus

We would probably need tile-based widgets, as you all have already, as well to support sources that are not compatible with the mapbox-gl. So, you would probably end up having two alternative ways to show the maps that you would have to switch in between in the application.

Originally Posted by rinigus

Widget seems to be locked. Its actually possible to use other data sources, as done for https://openmaptiles.org/ . Right now I am developing against Mapbox data sources, since it easiest. Already now it should be possible to use other sources, but I have not tried.

Originally Posted by rinigus

As for offline, as soon as widget is ready, I am planning to add offline support for it via OSM Scout Server. We should be able to squeeze in additional datapack for mapbox gl, I presume it will be of similar size to mapnik datapack. Hopefully, data.modrana.org will be fine to host it .

Originally Posted by rinigus

So, the plan is to go all the way with the full online and offline support. And I don't think there are any major roadblocks on the way.

Originally Posted by Zeta

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.

Originally Posted by Zeta

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...

Originally Posted by Zeta

Done.

Translating in commands, for future me (and other who could need to):

=> (warning, the last "armv7hl" is not part of the repo name)

Code:

 devel-su ssu addrepo mer_rinigus http://repo.merproject.org/obs/home:/rinigus:/maps/sailfish_latest_armv7hl/ 
ssu updaterepos
pkcon refresh
pkcon install mapbox-sfos-debuginfo qmapboxgl-debugsource

Here are the backtraces for 3 consecutive runs : https://pastebin.com/QiPcKsfi

Is there another gdb command output you need ? (my gdb is a bit rusty...)


Seeing as the last run crashed on QSslConfiguration, we are probably chasing a memory corruption bug. The kind that can corrupt stack or heap at some place in the code, and leaving its effects to something else later (like free and malloc that are using pointers) that is what gdb captures, and not the real thing that broke the stack.
It is usually one variable stored above in the memory that got out of its bounds, but can be more subtle. This can be "quite easy" to find in a small micro-controller, but I don't know how to show it in that case, as there are a lot of allocation/deallocation happening and so it can be difficult to know what was in memory before when the problem happened. Especially as valgrind doesn't run, from your tests.
Some basics tests could be done, like adding tests around all mallocs and pointers usage, leading to a qFatal() call to stop the application with a core dump and details. However, if the problem is on the GPU side (as only the adreno 200 shows it right now), it would not help that much..

Originally Posted by MartinK

That definitely sounds like a good idea - to provide a general purpose "add/remove" POI marker/route API while still allowing to use the lower-level GeoJSON as well for more advanced stuff.

BTW, any idea if the markers could be made clickable ? Some generic "marker <id> clicked, with id set/provided at marker creation would be enough. Otherwise it would be tricky to resolve which marker the user has clicked on due to rotation/animation/camera angle, etc. Not are a blocker though as there are ways to address the markers even when they are not clickable, by eq. showing a list, etc. Still would be nice to have & is IIRC already possible with current solutions in Poor Maps and in modRana.

Originally Posted by MartinK

Yeah, supporting to map views/widgets is certainly the way to go for the time being.

On the other hand I wonder - how hard it would be to also support map tiles in the Open GL widget ? That way you could use specialized tiled map layers (traffic, weather, OSM bugs, etc.) on top of the rendered map layer or even just use tiled maps directly with all the benefits of an Open GL based map widget. It would also mean mapping apps could eventually drop their solutions for tiled maps as the Open GL map widget would cover that as well.

...

But in any case no pressure - this is just a nice to have feature while the widget already provides a lot of pretty cool stuff & there is certainly much more things that need to be solved.