Active Topics
-
Firefox with Leste (5)
to Maemo 7 / Leste by teroyk - 4 days, 9 hrs ago -
Handbook (2)
to Maemo 7 / Leste by teroyk - 5 days, 9 hrs ago - more...
 |
|
2017-09-25
, 20:57
|
|
Posts: 141 |
Thanked: 1,530 times |
Joined on May 2011
@ Finland
|
#72
|
Originally Posted by rinigus
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.
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.
|
|
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 :
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 !
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);
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 !
|
|
2017-09-26
, 06:39
|
|
Posts: 1,414 |
Thanked: 7,547 times |
Joined on Aug 2016
@ Estonia
|
#74
|
Originally Posted by otsaloma
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/ .
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.
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.
|
|
2017-09-26
, 06:45
|
|
Posts: 1,414 |
Thanked: 7,547 times |
Joined on Aug 2016
@ Estonia
|
#75
|
Originally Posted by Zeta
Hi Zeta, thanks for testing and working on it!
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 :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).Code:connect(n, &QSGMapboxGLTextureNode::replyCoordinateForPixel, this, &QQuickItemMapboxGL::replyCoordinateForPixel, Qt::QueuedConnection); connect(this, &QQuickItemMapboxGL::queryCoordinateForPixel, n, &QSGMapboxGLTextureNode::queryCoordinateForPixel, Qt::QueuedConnection);
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 !
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.
|
|
2017-09-26
, 16:59
|
|
Posts: 141 |
Thanked: 1,530 times |
Joined on May 2011
@ Finland
|
#76
|
Originally Posted by rinigus
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.
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/ .
|
|
2017-09-26
, 18:43
|
|
Posts: 1,414 |
Thanked: 7,547 times |
Joined on Aug 2016
@ Estonia
|
#77
|
Originally Posted by otsaloma
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.
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.
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.
|
|
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.
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.
|
|
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: | ||
|
|
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.
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.
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:
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