|
POST
|
I have a few thoughts. First is that the FeatureLayer is Loadable, just like how Geodatabase is Loadable. So you can connect to the loadStatusChanged signal and wait for the loadStatus to be completed. My other thought is that you should be able to set the visibility of a layer before or after it loaded, and it should persist. Is that not what you are seeing? Side note - you can see in the detailed description that it implements the Loadable interface - FeatureLayer QML Type | ArcGIS for Developers Also, the Loadable documentation has a list of all classes that implement it (and therefore have the loadStatusChanged signal) - http://developersdev.arcgis.com/qt/latest/qml/api-reference/qml-esri-arcgisruntime-loadable.html
... View more
05-05-2017
10:55 AM
|
2
|
2
|
2821
|
|
POST
|
Can you share your project with me please? I do not know if this is related to the issue or not, but I just wanted to make you aware that CentOS is not one of our officially supported platforms. The officially supported platforms are listed here - System requirements—ArcGIS Runtime SDK for Qt | ArcGIS for Developers It still might work since it is similar to RHEL, but we have not done any testing on this platform.
... View more
05-04-2017
07:52 AM
|
1
|
0
|
1694
|
|
POST
|
FYI, the only reason the samples always unregister is because in the case of the sample, they are showing a workflow where some data is taken offline once, and that is it. Otherwise, we would end up with tons of extra replicas registered on the sample server. As for the System.userHomePath vs ~ issues. The issue is that any ArcGIS Runtime QML type will require it to be a file URL, like this- "file:///Users/username/ArcGIS/Runtime/Data/Local.geodatabase". Since the local types require "file:///" to precede the path, we made System.userHomePath return the path with that prefix. However, FileInfo (from the Extras plugin) does not work in the same way.
... View more
05-04-2017
07:23 AM
|
2
|
0
|
1343
|
|
POST
|
For setting the height, we don't currently have a public property for this, but we probably should. I'll add a note for us to look into adding one. In the meantime, since it is open source, you should be able to modify what is released to your liking. From my testing, changing this property changes the height of the callout - arcgis-runtime-toolkit-qt/Callout.qml at master · Esri/arcgis-runtime-toolkit-qt · GitHub For width, did you try turning off auto adjust width, and the setting the calloutWidth property? We pushed this addition up to GitHub after the final release, so you will probably need to fork the repo so you get the updates. Setting this property should allow you to control the width when auto adjust if set to false - arcgis-runtime-toolkit-qt/Callout.qml at master · Esri/arcgis-runtime-toolkit-qt · GitHub
... View more
05-01-2017
08:26 AM
|
0
|
1
|
2150
|
|
POST
|
I tried this, but could not reproduce (tested on Ubuntu 16.04). Could you upload a small sample project that reproduces the issue? Also, are you able to reproduce the issue on any other platforms? As you might know already, CentOS isn't a supported platform of ours, but I'm guessing it should mostly behave the same as RHEL. auto go = new GraphicsOverlay(this);
go->setRenderingMode(GraphicsRenderingMode::Dynamic);
auto s = new SimpleLineSymbol(SimpleLineSymbolStyle::Solid, QColor("black"), 4.0, this);
auto sr = new SimpleRenderer(s, this);
go->setRenderer(sr);
m_mapView->graphicsOverlays()->append(go);
auto g = new Graphic(this);
go->graphics()->append(g);
auto pb = new PolylineBuilder(SpatialReference::webMercator(), this);
connect(m_mapView, &MapGraphicsView::mouseClicked, this, [=](QMouseEvent e)
{
auto p = m_mapView->screenToLocation(e.x(), e.y());
pb->addPoint(p);
g->setGeometry(pb->toPolyline());
});
... View more
05-01-2017
08:01 AM
|
1
|
2
|
1694
|
|
POST
|
This server doc should help a bit - ArcGIS REST API - Services and Data Types per replica (geodatabase) means that individual layers cannot sync independently and per layer means that they can be. With that, the table at the bottom shows that versioned data is per replica and non versioned is per layer. If you use Enums.SyncModelGeodatabase in your generate parameters, then use SyncGeodatabaseParameters::geodatabaseSyncDirection property. Otherwise, if you used Enums.SyncModelLayer, use the layerOptions property. SyncGeodatabaseParameters QML Type | ArcGIS for Developers
... View more
04-28-2017
02:01 PM
|
2
|
0
|
822
|
|
POST
|
My goal is to create an iOS app that will be used by our tree trimmers... This sounds like a relatively simple application that could be written in QML or C++ with (most likely) little to no difference in the output product. Are any drawing tools available for creating the polygons and assigned attributes? We don't yet have a sample or API for this, but we eventually plan on having a SketchEditor type component that will help simplify drawing geometries. For the time being, you will have to create your own editing experience using the various GeometryBuilder classes. For example, if creating/editing a polygon, you should use the PolyonBuilder class for this. what do you think about using 2 different feature services? Either sounds find. It doesn't sound overly complicated with 2 in my opinion. I should be able to use the same code on an Apple machine, and build the app there, right? Yes, your code is all cross platform, so it should build just fine on Mac for iOS.
... View more
04-26-2017
12:19 PM
|
2
|
0
|
1593
|
|
POST
|
It really depends on the application. QML is pretty powerful, but there are definitely some limitations if you are comparing to C++. The first area of limitation to consider would probably be performance. For example, if you perform a query and get an iterator or list of feature objects in QML, and need to iterate through the list in QML/JS, that will be faster in C++. Additionally, you can spin up additional threads for performing background tasks like this in C++, but JavaScript code is all executed in the main UI thread. QML/JS does have the WorkerScript type, which executes a block of code in another thread, but this only handles built in data types, so any types from Runtime or that you create on your own cannot be passed over to the WorkerScript, so it is a bit limiting. With that said, much of the rendering performance should be about the same between both APIs. The performance hits are typically going to come from the client application code, especially when there is lots of imperative code. Your goal when writing QML code should always to be as declarative as possible and to write as little imperative code as possible. That is where you will get optimal performance. The second area of limitation is probably in extensibility. Qt itself is written in C++, so once you want to do something that is not available in QML, you will likely need to do this in C++. In fact, that is how we expose QML objects from ArcGIS Runtime - we write them all in C++ and you consume in QML. With that said, lots of things are available to you in QML, so depending on what you are doing, you might not need to write any C++ code. Basically, there is no easy answer. If your application is relatively simple, QML is just fine. If it is extremely complex, it might be better suited in C++ (but not necessarily). One final thought is that it isn't all or nothing. Probably the most preferred way to write your Qt app is to use QML exclusively for your UI and C++ for your backend code. The different options are discussed a bit more here - https://developers.arcgis.com/qt/latest/cpp/guide/qt-sdk-best-practices.htm
... View more
04-26-2017
09:30 AM
|
2
|
2
|
1593
|
|
POST
|
These sound like they may be error messages being returned from the service. I would suggest you contact Esri support to assist you in debugging this if at all possible. They are well equipped to test if the error is happening on the client side or server side (either with ArcGIS Server or the database itself). Either way, a good place to start is to check the error logs in ArcGIS Server when these errors occur. Typically you can see a lot more information than what is sent back via http to the client.
... View more
04-13-2017
07:16 AM
|
0
|
0
|
1581
|
|
POST
|
Not all classes that were present at 10.2.6 are present at 100.0. 100.0 was a move into the next generation of ArcGIS Runtime, and while it is close to being functionally equivalent (plus lots of new things that were not available at 10.2.6), there are some things that are not yet present at 100.0 that were available at 10.2.6. Most of those holes will be filled with the first update, which is scheduled to come out in June. As for WmsDynamicMapServiceLayer.h, that is a class that is not in version 100.0, hence why you cannot find the header in the install.
... View more
04-10-2017
07:25 AM
|
0
|
0
|
887
|
|
POST
|
Thank you. The short answer to your question is no, it isn't possible to change it dynamically. We are looking to add a way to scale symbols in the future (both military and non military), but don't yet have a solution. The longer answer is: 1) These symbols are coming from stylx files, which are technically sqlite databases that Pro can read. So, while I acknowledge that this is really not a feasible workaround due to the enormity of symbols in the stylx file, one could theoretically go through the sqlite files programmatically or in Pro and alter the size. I'm not recommending you do that, and I have not tried it, but it could potentially work in theory. In addition, since the Symbol class implements JsonSerializable, one could also (in theory) serialize the symbol to json, then go and modify the json, and then deserialize and create a new symbol from json. The trouble is that there is no real documentation on the internal json structure of these advanced symbols, so it would be a reverse engineering effort of sorts. Again, not exactly a very realistic workaround, but maybe something to look into. 2) I am trying to determine if the bigger symbols are right or wrong. We had issues at 10.2.x where all of our symbols were actually smaller than what they were supposed to be. So I am not sure if the fact that they are larger now is a bug or a feature. Perhaps you might know if the spec defines them to be a certain size, but it is not adhering to that? 3) Like I said earlier, we are looking to have a way to scale symbols dynamically in the future - Lucas
... View more
04-06-2017
03:28 PM
|
0
|
0
|
1398
|
|
POST
|
It will be included in the next update of version 100, which is out in approximately May/June of this year.
... View more
04-04-2017
09:32 AM
|
2
|
3
|
2775
|
|
POST
|
We provide some services that you can use out of the box. They are demonstrated in this sample - Display a scene—ArcGIS Runtime SDK for Qt | ArcGIS for Developers It uses this as the elevation service - http://elevation3d.arcgis.com/arcgis/rest/services/WorldElevation3D/Terrain3D/ImageServer, and the Esri World Imagery service as the basemap - World_Imagery (MapServer) If you decide to put up your own service, the size depends on the amount of detail and the area you are covering. For example, if you have a elevation service based off a 1 meter DEM for the entire globe, then it will be quite large. You don't have to use Qt Creator if you don't want - it is just an IDE. You could use other IDEs and build via the command line if you like. However, that is the IDE most commonly used, and provides many nice utilities for Qt developers. Our entire Qt SDK development team, and most all of the customers we talk to use Qt Creator as their IDE for Qt development.
... View more
04-03-2017
07:08 AM
|
2
|
0
|
2881
|
|
POST
|
Hi Florian- You should definitely be able to do that. We do something similar in our Animate 3D Symbols sample - Animate 3D symbols—ArcGIS Runtime SDK for Qt | ArcGIS for Developers You can use either C++ or QML - it is up to you. If you are comfortable in C++, I would recommend going that direction, because it ultimately will lead to more flexibility with writing more custom classes, handling threading, etc. But if you are from a JavaScript background, QML should come very quickly to you, and should suffice for the job as well. The performance of the API itself should be about the same, but if you need to start adding complex JS code in your QML app, you may start to find that the C++ app will get better performance. You can develop your app using Qt's IDE - Qt Creator. We support version 5.6.2, 5.7.1, and 5.8. As for data, you will need at least 2 things - the elevation surface and the basemap. The surface can be obtained through a Tiled Elevation Service, and the basemap can be a tiled map service or a local tile package. I recommend you take a look at the developer page to get started Guide—ArcGIS Runtime SDK for Qt | ArcGIS for Developers. If you install Qt, install the SDK, go through samples, and copy/paste the bits you are interested in into your own app, you should be off to a good start. -Lucas
... View more
03-31-2017
07:41 AM
|
2
|
2
|
2881
|
| Title | Kudos | Posted |
|---|---|---|
| 3 | 05-27-2026 09:52 AM | |
| 1 | 11-24-2025 10:45 AM | |
| 1 | 07-30-2025 08:26 AM | |
| 1 | 05-15-2025 07:35 AM | |
| 2 | 11-26-2024 01:27 PM |
| Online Status |
Offline
|
| Date Last Visited |
06-17-2026
07:54 AM
|