I'm currently working on a Qt Quick application that will provide a map viewer for a smallish area (1 square KM or so), the map details for which will be provided in a single geo-referenced image file (GeoTIFF, geo-referenced PDF, ESRI Shape file etc.), along with display of current location, operator identified points of interest etc. It's primarily responsibility is the display of custom maps (as opposed to generic maps retrieved from public map image service providers (OSM, MabBox, ESRI etc)), and it will often be used in areas with limited connectivity
An extensive web search has identified others who have made similar enquiries in the past (here, Qt forums etc), and the general suggestions for solutions are as follows:
ArcGIS Runtime with Qt SDK Doesn't work for me as down the track I'm intending to target an embedded linux device using an ARM processor, and ArcGIS doesn't make source available for cross-compilation for arbitrary targets. They've recently produced an Android release, but nothing for ARM linux in general)
QGIS developer libraries GPL licence not compatible with my commercial development
Use the Qt Location Map component with a local tile server or offline tile collection (some plugins have recently introduced support for this) Seems a bit of a hack, as noted I'm primarily using custom maps, as opposed to offline copies of public map server images, and my images won't be big enough to really warrant tiling otherwise
It would be feasible to develop a Qt Quick component from scratch to do this, but given that the existing Qt Location Map component provides a well defined pre-existing front end interface for everything my map would need to do and has an extendable plugin based architecture, writing a custom Qt Location GeoServices plugin seems the most sensible and elegant way forward.
I've started examining the source code of the existing plugins, but can't shake the feeling that in a world containing 8 billion people, with "nothing new under the sun", this would have been done already if it was a good idea....
Would anyone with more familiarity with the Qt Location module care to comment?
Since geo-referenced images can be arbitrarily large, it is the standard to convert them into a tile pyramid, to be able to efficiently display them on any hardware (at the cost of doubling the size, at worst, depending on how many layers you want).
Even if you would write your own geoservice plugin, you most likely will end up (directly or by using 3rd party code) tiling your geotiff.
This said, QtLocation does allow you to use custom tilesets ( http://doc.qt.io/qt-5/location-plugin-osm.html, look for osm.mapping.custom.host) served in most ways (http, https, file, qrc, etc.).
So go ahead, fire up QGis, install the QTiler plugin, and convert your images.
If you need to serve these pictures over the net directly to the clients (thus needing to do the conversion on the client), you can either see what QTiler does, or build up your gdal pipeline (gdal_translate, gdalwarp and gdal2tiles), and ship the relevant gdal bits with your application.
If you need multiple images at the same time, you can either use multiple Plugin elements with different plugin parameters, or you can fork the osm plugin and support multiple custom hosts.
Based upon Paul's response, and a couple of similar responses to the same enquiry on Qt forums and mailing lists, plus my own investigation, I'd conclude the following:
Generating a custom Qt Location GeoServices plugin to directly provide map imagery from a geo-referenced image file would not be a great idea as the implementation would be less than straightforward, and in practice any non-trivial map image would likely be large enough that an initial tiling step, followed by use of one of the standard tiled mapping plugins referencing a local tile set would be more appropriate anyway.
Related
I'm writing a Qt application that is supposed to show a geo-map of a specific geographical region in one of its views on top of which I need to be able to draw various other graphical elements.
The requirements are that all the map-tiles must be pre-downloaded for off-line use as during the use of the application there will be no internet connection.
After lengthy search for a suitable library that I could link into my Qt project that would support my needs (off-line tile loading, rendering and painting the map in Qt framework, non-QML only C++ integration) I thought libOsmScout would do the job.
However, I have managed to download .mbtiles files for my region from OpenMapTiles just to realise that libOsmScout cannot natively work with .mbtiles.
The library can only work (indirectly after "import") with .osm.pbf files.
(http://libosmscout.sourceforge.net/tutorials/importing/)
I've searched extensively the web but all the results were pointing to conversion procedures in the opposite direction, i.e. into the .mbtiles.
So my question is: is it possible to convert .mbtiles files to .osm.pbf format so I can then import it into libOsmScout compatible internal set of files?
If it is possible, what the process?
Any help or guidance would be much appreciated.
Thanks.
Easiest way is to use ogr2ogr to convert to pbf format.
ogr2ogr -f MVT output_dir_name input.mbtiles -dsco MAXZOOM=2
This will create a directory structure with each zoom level having a directory and pbf file named according to the tile position.
Or
using this tool called MBUtil.
There are some steps which you can follow from the github repo.
After that, you can then use the following command to convert to directory structure with each tile in pbf format.
mb-util input.mbtiles output_dir_name image_format=pbf
where tiles is the directory name you want
Rendering large DWG files as such has shown performance degradation to large extent. Planning to use the concept of map tiles using leaflet. Need some pointers/information on how to convert DWG files to map tiles.
After too many hours, searching everywhere for a solution to convert DWG/DXF files using any automated command line tool, finally I found QCAD.org.
And that works even on Windows, MacOS and Linux.
After a quick look in documentation, I found the section for command line tools.
They are:
dwg2bmp, dwg2png, dwg2jpeg, dwg2tiff, dxf2png, dxf2jpeg, dxf2tiff
and the awesome:
dwg2maptiles and dxf2maptiles
Using this tool, they came up with a beautiful sample using leaflet.js:
http://qcad.org/res/map/
The project is OpenSource, but this scripts are only avaliable at QCAD Professional edition.
You can use the free open source QCAD Community Edition by downloading the trial version for your platform (Win, Mac, Linux) and then remove the QCAD Professional add-on running in trial mode. Alternatively, you may compile your own package from sources.
PS: I'm very happy to support the project buying a professional copy.
The easiest approach may be to save your DWG files as PDF and use MapTiler to create the raster tiles and leaflet viewer for you.
You can render such PDF by drag&drop into MapTiler while choosing the "raster" profile - just follow the video tutorial: https://youtu.be/9iYKmRsGoxg?list=PLGHe6Moaz52PiQd1mO-S9QrCjqSn1v-ay
If you need to assign coordinates for later on placing markers or polygons on specified position over the DWG tiles - it is possible with advanced tiles.
If you need help with using MapTiler - write details and provide sample file you need to process to https://www.maptiler.com/support/community/.
If you data are sensitive or you need a guarantee on the answering of your request you seek directly the support from us, the authors of MapTiler.
Given qt3d's structure, is it possible to integrate the oculus sdk with a qt3d application?
I have tried but my two main obstacles are:
I cant use the textures from the texture swap chain created by the oculus sdk as a render target attachment
I am not able to call ovr_SubmitFrame at the end of each frame since qt3d doesnt have a signal that would allow me to do so.
Has anyone successfully gotten the oculus sdk to work with qt3d? If so, how did you overcome these issues?
Are there any plans for allowing the integration of VR SDKs (not just oculus') in qt3d in further releases?
You could probably do it with some sort of custom framegraph that encapsulated the stereo rendering functionality and included a custom component that could take the currently rendered content and submitted it to the SDK prior to the swapbuffer call.
Alternatively you could dive into the code that processes the framegraph itself and see how hard it would be to customize it to work against a VR API. I've done significant work with integrating Qt apps with VR, but not specifically with Qt3D.
The frame graph will indeed provide one part of the solution for the stereoscopic rendering setup. There is already an anaglyphic stereo example showing most of what you need that ships with Qt 3D.
To integrate the swap chain of the occulus SDK will require deeper integration. I do not know the details of the Occulus SDK as yet but we can take a look.
From what I can see you should be able to do something analogous to the Scene3D custom Qt Quick 2 item to be able to render to the textures provided by the Occulus SDK and to tell Qt 3D which OpenGL Context to use. See
http://code.qt.io/cgit/qt/qt3d.git/tree/src/quick3d/imports/scene3d?h=5.7
Nicolas, I also do not appreciate you publicly saying that KDAB are not much help. I only received an email from Karsten on Friday which I responded to despite being on vacation saying that we can help but it will be on a best efforts basis since you are not paying and I have a very full workload preparing Qt 3D for release at the end of the month along with Qt 5.7. Today is a public holiday in the UK, as you are aware, yet you are already saying detrimental things about us.
You were also directed to post to the interest#qt-project.org mailing list on the qt-forums as I do not tend to monitor SO or the qt-forums on a regular basis. You could have also emailed us directly or via the development#qt-interest mailing list.
We would be more than happy to set up a support agreement with you.
We are currently working with the Gracenote Music API and are wondering if there is a full list of generes and mappings between the different hierarchies of genres. Ideally, we'd love a dump of those tables in the backend Gracenote system. If .csv's, text files, or even XML are easier to provide, we will figure out a way to import that data in our system.
If a full mapping isn't available, a list of top level genres would be very helpful.
I'm afraid there is no way to iterate the list of genres via the Web API. Most of the client SDKs have this capability.
It turns out that there are at least three sources for example code in the GNSDK:
Properly maintained samples in the "samples" directory. This will compile into full applications with minimal effort (once you've settled on a makefile solution for your platform, as a complete Automake setup is not yet part of the package).
samples/code_snippets - These are useful to look at, but do not necessarily build into full apps, and may not be completely up to date with the SDK.
Code linked from the documentation. This is a problem if you downloaded the SDK as an archive and the documentation as a PDF, as the links will resolve as relative file links, not HTTP links, and you won't have the files. You need to look at the HTML version of the documentation on the server to find these files. However, they are apparently outdated and will not build without some (relatively minor rework). This can be done using the primary samples as a guide.
So, all of that said, what you want to look at in the GNSDK Developer's Guide is "Advanced Topics : Using Lists". You will want to read that entire section, then find and work with the sample application referenced on page 93.
To get the list of genres (or moods, or eras) you need to make a call to the "fieldvalues" API, you can see how to do it here:
https://developer.gracenote.com/rhythm-api#attribute-station
This call will give you the list of supported genres:
https://cXXXXXXX.web.cddbp.net/webapi/json/1.0/radio/fieldvalues?fieldname=RADIOGENRE&client=CLIENT_ID&user=USER_ID
You can then use the returned ID's with pygn.createRadio()
I am working on a learning project for mobile devices that requires (or would at least be desirable) the ability to export to a SCORM-compatible format. I see that SCORM has a "Package Interchange Format" (PIF) based around a .zip file. I am new to SCORM and am trying to understand exactly what this file must contain. Specifically, is the PIF file just a format for generating interchangeable data between systems, or is it more complicated than that?
For some context, imagine the use case of a set of questions/sections that a user has to run through on a native mobile app, and at the end, we want to offer the ability for the user to "export" their data in a SCORM-compliant fashion. Is this simply a matter of exporting information about a) the questions and b) the answers into some .xml format, or is there more to it? I notice a lot of the documentation around SCORM seems to focus on Javascript and HTML. Is SCORM HTML specific, or are native apps reconcilable with SCORM, at least from the export perspective?
Apologies if any of this is basic stuff. Just trying to wrap my head around the standard and how it does or does not apply to what I'm doing.
The PIF is really a very small detail of SCORM's packaging. It only says that you can distribute your content in zip format, but not what that should contain.
What a SCORM (1.2) file should contain is described in much, much detail in the SCORM CAM book. To summarize very quickly, you need:
All the files necessary for the content to run (images, html files, javascript files, css etc)
A file called imsmanifest.xml that describes a few things about your content, the files it contains and possibly how they interract with the LMS they run on. It can vary from very simple to very complicated.
Optionally, metadata in XML format
So, SCORM does not care if and where you include your questions and answers. It doesn't know about them. This is your content's responsibility and that should be able to include them and present them to the user, when ran. What SCORM can do is make your content communicate with the LMS you're running it on, so that the results of these questions are persisted.
For now, I'd suggest that you have a look at some existing SCORM files, to get an idea of how the imsmanifest.xml file should look like, and then study the SCORM CAM book and things will get rolling.
The trouble with SCORM is that is has to be launched from within LMS. If you're building an external app that has to communicate to a LMS, take a look at either LTI (http://www.imsglobal.org/toolsinteroperability2.cfm) or TinCanAPI (http://tincanapi.com/).
SCORM 2004 sample https://github.com/cybercussion/SCOBot/
You zip the contents of the directory. Some LMSs expect the imsmanifest.xml to be located in the root of the zip.
Some people are using Native Apps in a LMS format and loading the SCO's into an HTML view, but as stated above SCORM is expecting a JavaScript to JavaScript communication.