Page 8 of 13 « First 67 8 910 Last »
Reply
Thread Tools
rinigus is offline rinigus
2017-09-25 , 20:36
Posts: 1,414 | Thanked: 7,547 times | Joined on Aug 2016 @ Estonia
#71
An API allowing to add widgets to the map and associate it with the position in the widget has been added. In short, you need just to specify which location do you want to track and then follow signals to change widget location on the screen accordingly. Tested on desktop demo app and it worked quite nicely (you can add/remove single location and remove all tracked locations as well). See demo app for details:

Main: https://github.com/rinigus/mapbox-gl...p/qml/main.qml

Widget that tracks position, hides when out of the screen, and destroys itself when tracking is removed: https://github.com/rinigus/mapbox-gl...l/location.qml

I think that its complete now in the sense that I can start testing it further by porting a proper map application over it and see if I hit some problems.

Replies to the questions below:

Originally Posted by otsaloma View Post
Things move such fast, that I can't quite keep up. Could you explain in high-level terms, how this API relates to QtLocation 5.2/5.6 or the Mapbox GL plugin API in QtLocation 5.9? I'm wondering if people writing map apps for SFOS will along with this new component have three different APIs for routes, POIs, position icons, etc.? And not just functions, but also data structures (QtPositioning coordinates, MapQuickItems, JSON etc.) given as arguments?
Its a new API. To put into perspective:

QtLocation 5.6 - assuming it will come to SFOS - has three main plugins - HERE, Mapbox, OpenStreetMap (http://doc.qt.io/qt-5.6/qtlocation-index.html). All these plugins use tiled maps.

QtLocation 5.9 - introduced the first "vector" plugin in the form of Mapbox GL. Mapbox GL Native (https://github.com/mapbox/mapbox-gl-native) has Qt interface (called platform in their project) that was further integrated into QtLocation by providing corresponding QtQuick components and interfaces with the other QtLocation classes.

This API: Based on the bits from QtLocation/Mapbox GL plugin (rendering of the map on QtQuick widget); interface to QMapboxGL that provides Mapbox GL functionality for Qt C++; and my understanding of what's needed from application perspective. This API compiles and runs against Qt 5.6 using QtLocation 5.2 (SFOS) and Qt 5.7 / QtLocation 5.7 (desktop), as far as I tested.

So, for people writing map apps, this API allows you to have probably one of the best renderings of the map available now, on any platform. In the background, it will communicate with the vector tile server and keep the cache with the minimal effort from the map application writer.

APIs for routes, POIs, and position icons are different. Data structures, for most part, are compatible with the QtPositioning coordinates used to provide points, routes (list of coordinates). For more complicated cases, we can see what's the reasonable approach.

Now, I don't know how much would take an effort to port an existing application to such API. In my understanding, it shouldn't be too difficult. However, it maybe that the devil is in the details and I underestimate the task. Hence my idea to port Poor Maps over and see how much time does it take in practice as well as whether we can cover all the cases as exposed by complete map application.

Edit: I hope I did reply to all questions / please ask again if I missed anything

Originally Posted by otsaloma View Post
Please file an issue about that and suggest a high-level outline for discussion, assuming it's likely to end up being more than just testing.
Sure, I will. I'll have to read the code of Poor Maps again and then I'll be able to suggest something. Probably would test few things first to get some feel about possible solutions.
 

The Following 5 Users Say Thank You to rinigus For This Useful Post:
otsaloma's Avatar
otsaloma is offline otsaloma
2017-09-25 , 20:57
Posts: 141 | Thanked: 1,530 times | Joined on May 2011 @ Finland
#72
Originally Posted by rinigus View Post
Sure, I will. I'll have to read the code of Poor Maps again and then I'll be able to suggest something. Probably would test few things first to get some feel about possible solutions.
All right. To clarify, my main concern is whether we can support both raster and vector maps in the same codebase. Considering the experimental nature of Mapbox GL and crashes on Jolla 1 and Jolla store rules, we might need to support raster tiles for quite a while still. That would favor a single codebase, but if it looks seriously complicated, then rather a fork, and new features only in the fork.
 

The Following 3 Users Say Thank You to otsaloma For This Useful Post:
Zeta is offline Zeta
2017-09-25 , 22:39
Posts: 339 | Thanked: 1,623 times | Joined on Oct 2013 @ France
#73
Hello rinigus,

First of all, hats down for the work you did/are doing there !

I can confirm the demo app works really good on Desktop, and it is quite easy to build something around the Qml component in a custom application.
Updating a geojson source live seems to work without quirks. I got it working with OSRM when it computes a new route to the latest clicked point.
I will need a bit more time in the week to clean this a bit before I start pushing it on GitHub, if other can find inspiration in it.

Working with it, I have a couple of minor questions/remarks:

* margins have a setter, but are not a "real" property. Is this by design or was it a shortcut ? Having them as properties would allow adding them a "Behavior", to smooth switching from one view to another

* when trying to find the coordinates for a pixel on the screen, the answer can only be asynchronously obtained as it goes through internal signal/slots :
Code:
connect(n, &QSGMapboxGLTextureNode::replyCoordinateForPixel, this, &QQuickItemMapboxGL::replyCoordinateForPixel, Qt::QueuedConnection);
connect(this, &QQuickItemMapboxGL::queryCoordinateForPixel, n, &QSGMapboxGLTextureNode::queryCoordinateForPixel, Qt::QueuedConnection);
It is not as easy to use as a simple function call as you need to keep some state of what you wanted to get this point coordinates, for when the answer comes back (like if you use right click for route start, and left click for route end, you need to store which click was the one that triggered the request. The more complex the interaction with the map, the more it will be visible).
I imagine the reason behind this is that the 2 objects live in different threads ? If so, there is not much that could be done to change it.


Thanks again !
 

The Following 3 Users Say Thank You to Zeta For This Useful Post:
rinigus is offline rinigus
2017-09-26 , 06:39
Posts: 1,414 | Thanked: 7,547 times | Joined on Aug 2016 @ Estonia
#74
Originally Posted by otsaloma View Post
All right. To clarify, my main concern is whether we can support both raster and vector maps in the same codebase. Considering the experimental nature of Mapbox GL and crashes on Jolla 1 and Jolla store rules, we might need to support raster tiles for quite a while still. That would favor a single codebase, but if it looks seriously complicated, then rather a fork, and new features only in the fork.
I suspect that raster tiles are supported, but haven't had time to test it. See https://www.mapbox.com/mapbox-gl-js/example/map-tiles/ .

If true and we can use raster tiles, it leaves us with J1 and JStore issues. While JStore is political and probably induced by QtLocation version available for us, J1 (and Photon Q) is a technical one that we should be able to look into. I may make a small app to test whether this issue is for some arbitrary OpenGL code as well. Would be easier to debug if we can get crashes with the small codebase.
 

The Following 2 Users Say Thank You to rinigus For This Useful Post:
rinigus is offline rinigus
2017-09-26 , 06:45
Posts: 1,414 | Thanked: 7,547 times | Joined on Aug 2016 @ Estonia
#75
Originally Posted by Zeta View Post
Hello rinigus,

First of all, hats down for the work you did/are doing there !

I can confirm the demo app works really good on Desktop, and it is quite easy to build something around the Qml component in a custom application.
Updating a geojson source live seems to work without quirks. I got it working with OSRM when it computes a new route to the latest clicked point.
I will need a bit more time in the week to clean this a bit before I start pushing it on GitHub, if other can find inspiration in it.

Working with it, I have a couple of minor questions/remarks:

* margins have a setter, but are not a "real" property. Is this by design or was it a shortcut ? Having them as properties would allow adding them a "Behavior", to smooth switching from one view to another

* when trying to find the coordinates for a pixel on the screen, the answer can only be asynchronously obtained as it goes through internal signal/slots :
Code:
connect(n, &QSGMapboxGLTextureNode::replyCoordinateForPixel, this, &QQuickItemMapboxGL::replyCoordinateForPixel, Qt::QueuedConnection);
connect(this, &QQuickItemMapboxGL::queryCoordinateForPixel, n, &QSGMapboxGLTextureNode::queryCoordinateForPixel, Qt::QueuedConnection);
It is not as easy to use as a simple function call as you need to keep some state of what you wanted to get this point coordinates, for when the answer comes back (like if you use right click for route start, and left click for route end, you need to store which click was the one that triggered the request. The more complex the interaction with the map, the more it will be visible).
I imagine the reason behind this is that the 2 objects live in different threads ? If so, there is not much that could be done to change it.


Thanks again !
Hi Zeta, thanks for testing and working on it!

Re margins: its oversight. I'll fix it tonight

Re coordinates/pixel: yes, map renderer lives in rendering thread and we have access through main gui thread. I have access to map object either via update method or via signals. What we can do is to add a tag as an additional argument for query (QVariant). Then, when you get a reply, you'll have the same tag delivered. This should allow you to keep all housekeeping info in that tag and simplify your code. I'll add it later tonight, unless someone has a better idea.
 

The Following 3 Users Say Thank You to rinigus For This Useful Post:
otsaloma's Avatar
otsaloma is offline otsaloma
2017-09-26 , 16:59
Posts: 141 | Thanked: 1,530 times | Joined on May 2011 @ Finland
#76
Originally Posted by rinigus View Post
I suspect that raster tiles are supported, but haven't had time to test it. See https://www.mapbox.com/mapbox-gl-js/example/map-tiles/ .
I have used Mapbox GL JS for web apps and at least that does support raster tiles. Tiles are blurry though, since there's a smoothing filter, which can't be turned off. If doing custom packages for SFOS, I expect the smoothing can be resolved too.
 

The Following 2 Users Say Thank You to otsaloma For This Useful Post:
rinigus is offline rinigus
2017-09-26 , 18:43
Posts: 1,414 | Thanked: 7,547 times | Joined on Aug 2016 @ Estonia
#77
Originally Posted by otsaloma View Post
I have used Mapbox GL JS for web apps and at least that does support raster tiles. Tiles are blurry though, since there's a smoothing filter, which can't be turned off. If doing custom packages for SFOS, I expect the smoothing can be resolved too.
Raster tiles are supported, just tested, and easy to use. They are blurry and it seems to me that the library loads tiles which are just one z level higher than the expected one. Would have to see if there is a knob I can turn to fix it.

Edit: looks like the zoom level depends on the tile size. So, I can get blurry images even when the correct level is loaded.
Last edited by rinigus; 2017-09-26 at 18:54.
 

The Following 2 Users Say Thank You to rinigus For This Useful Post:
rinigus is offline rinigus
2017-09-26 , 19:29
Posts: 1,414 | Thanked: 7,547 times | Joined on Aug 2016 @ Estonia
#78
Zeta, I have added a tag for pixel to location conversion. That should simplify your code.

As for margins, not sure how to make them a property. We have 4 margins in the setter. Should I cover them as RectF? It would make it a bit more convolved for the app writer, but maybe its OK.
 

The Following 4 Users Say Thank You to rinigus For This Useful Post:
rinigus is offline rinigus
2017-09-27 , 17:30
Posts: 1,414 | Thanked: 7,547 times | Joined on Aug 2016 @ Estonia
#79
Blurry rendering issue has been open at https://github.com/mapbox/mapbox-gl-native/issues/10076 . Similar to an issue reported for JS version of the library about 6 month ago.
 

The Following User Says Thank You to rinigus For This Useful Post:
rinigus is offline rinigus
2017-09-27 , 19:45
Posts: 1,414 | Thanked: 7,547 times | Joined on Aug 2016 @ Estonia
#80
Now the question from my side: how to make it simple to use the developed QML extension?

For C++ - based projects, its all trivial. We could just include corresponding library as a subproject in git and merge with the C++ project build system. As soon as QtLocation is allowed, all these projects are also Harbour-proof.

For Python-based map applications (Poor Maps and modRana), situation is not that simple. Its either I have to somehow make QML type available as a library or these applications would have to be converted to C++ in small parts (probably just to register type and define main). I presume that having extra lib requirement would make the application non-Harbour proof. The library has a small chance to be integrated into device either, since its LGPL3 (I used parts of the code from current QtLocation, hence the license).

Any ideas? If we go with the library approach, how do I register it in the QML to make it available?


PS: Zeta, margins are now a property through QRectF class.
 

The Following 3 Users Say Thank You to rinigus For This Useful Post:
Reply
Page 8 of 13 « First 67 8 910 Last »

« Previous Thread | Next Thread »

 
Forum Jump


All times are GMT. The time now is 16:55.

Contact Us - Home - Archive - Top