Latest Contributions by JakobGaardsted

‎05-30-2016

Hooray - we've found the solution for this! We got some ESRI technical support, who provided us with an 'independent' code sample using our same config, which DIDN'T crash. The issue was caused by one of the many changes to the API between 10.2.3 and 10.2.6. We originally wrote the app under v10.2.3. There, it was legal to have e.g. NAFeaturesAsFeature allocated on the stack. In 10.2.6, NAFeaturesAsFeature _must_ be heap-allocated with new (applies further, e.g. EsriRuntimeQt::Graphic). To our bad luck, it didn't cause guaranteed crashes - it "only" failed in rare cases. To our good luck, it crashed consistently. If it had been a random crash, I don't know if we would ever have solved it :-/. I can only shudder at the thought of how many further similar 10.2.3-bugs we may have lying in wait for us - the proper approach would probably be to go through every single numerous line of gis-code we have for 10.2.6-ishness :-/.

‎05-09-2016

'touching' certain parts of the street network seems to trigger crashes, when calling LocalRouteTask.solve. I have attached the geodatabase I'm using for routing, to this post. The data set was built by an ESRI partner, partially with your assistance earlier (msg 595156 - a problem caused by accidental clipping.) The example trace is between these two points: // Iceland, narrow-bad crash: ER::Point pointA(-21.590907, 64.180326, EgisProj2::sr_wgs); ER::Point pointB(-21.590828, 64.180222, EgisProj2::sr_wgs); which were precisely chosen to demonstrate the issue. Those points are very close by each other, only because I narrowed them down to 'where the map broke' (the outset was an attempt to trace between points 6 km apart). Here is a stack trace dump. though I have never been able to get any useful info from any stack traces when ArcGis crashes; I presume because of the service-styled architecture (ie my call is presumably hidden in some asynchronous hand-off) 0 QSortFilterProxyModel::mapToSource Qt5Cored 0x666a01f7 1 EsriRuntimeQt::OnlineRouteTaskParameters::getImpl EsriRuntimeQtd 0x11c6ed2 2 EsriRuntimeQt::SolveCondition::messagesForCondition EsriRuntimeQtd 0x11f846b 3 EsriRuntimeQt::SolveCondition::messagesForCondition EsriRuntimeQtd 0x11f693f 4 EsriRuntimeQt::SolveCondition::messagesForCondition EsriRuntimeQtd 0x11f63d3 5 EsriRuntimeQt::SolveCondition::trUtf8 EsriRuntimeQtd 0x11b7b38 6 EsriRuntimeQt::LocalRouteTask::isValid EsriRuntimeQtd 0x11c88e1 7 EsriRuntimeQt::LocalRouteTask::isValid EsriRuntimeQtd 0x11c9669 8 EsriRuntimeQt::LocalRouteTask::isValid EsriRuntimeQtd 0x11dab1c 9 EsriRuntimeQt::LocalRouteTask::isValid EsriRuntimeQtd 0x11daa4c 10 QSortFilterProxyModel::mapToSource Qt5Cored 0x6643c3f8 11 QSortFilterProxyModel::mapToSource Qt5Cored 0x664433c5 12 _callthreadstartex threadex.c 376 0xff63651 13 _threadstartex threadex.c 359 0xff63861 14 BaseThreadInitThunk kernel32 0x7511338a 15 RtlInitializeExceptionChain ntdll 0x77739902 16 RtlInitializeExceptionChain ntdll 0x777398d5 My original 6-km 'trigger' points (which caused me to hunt the points listed above), are instead: // Iceland, bad crash: ER::Point pointAz(-21.6944, 64.1672, EgisProj2::sr_wgs); ER::Point pointBz(-21.5904, 64.1803, EgisProj2::sr_wgs); (I cannot guarantee they cause the identical crash - it may be two similar crashes. But neither of them should crash, if you ask me). BUT - I _can_ do plenty of other tracing on this LocalRouteTask geodatabase, that _doesn't_ crash. So it's just some parts that act broken. Given that the crashes bring down our entire application, it's a bit difficult to diagnose, since I need to spend about a minute restarting everything, after each crash. (This scenario is a follow-up on LocalRouteTask geodatabase format, documentation/how? https://community.esri.com/message/595156 ) By the way, the reason we are using offline/LocalRouteTask, is because it's way faster than using the ESRI online router. When I developed the application, I used the esri online-routing demo server - which runs very very fast. When time came to deploy with clients, to our horror we learned that ESRI's production online routing runs much slower (ie gives us much slower responses.) I believe the current average times I see for online, per simple A->B (ie trace between two simple nearby points), is about > 2 seconds. This makes it hard to use for clients doing e.g. 70 street link traces, as that would cause the client to sit and wait for several minutes. By using LocalRouteTask, we can achieve the same performance I originally saw from the online test service. I have used Lukas Danzinger's 'visualize street network' code from my earlier 595156 case, and on the surface, the problematic area looks OK, if a bit weird (a small rectangle of roads.) I would have loved to visualize the network as directional arrows, but the C++ Qt api 10.2.6 only includes the SimpleLineSymbol 😕 Apart from input/solution regarding why the street network algorithm will crash on this data built with ESRI tools, it would also be helpful with any general hints or tips for how to diagnose and check for such problems ourselves. Once these issues lead to crashes in production for our clients, our position becomes hard to defend :-/. Thank you for any help /insight you can offer on this

‎05-09-2016

Just an update: I ported your QML example (for visualizing the network layer) in C++, and thought I'd add that snippet here, to aid others working with similar stuff (in particular, it was something I wish I had worked out for myself..) (excuse the weird formatting, I tried to repair it as best I could) // First, find us a geodatabase: QString gdbPath = "straeto_network.geodatabase"; ER::Geodatabase* geodatabase = new ER::Geodatabase(gdbPath); // Then, make a featureTable: ER::GeodatabaseFeatureTable* gdft = new ER::GeodatabaseFeatureTable; gdft->setGeodatabaseWithLayerName(geodatabase, "Streets"); // Now make a layer out of that table: ER::FeatureLayer* featureLayer = new ER::FeatureLayer(gdft); // Hmm, we should probably set some symbol stuff? // Finally, add that layer to the map. m_map->addLayer(featureLayer);

‎04-12-2016

It works now :-). The esri partner reports this about what caused it: "... When I run this Arcruntime version there is a popup window that opens below the dataframe and cuts the dataframe extent, from below .." So presumably that is the UI aspect to be aware of, when building/exporting such a network graph. Again, Thank you for all your assistance in getting this to work!

‎04-12-2016

A question from the analyst/ESRI partner: "Does it matter whether it is arcmap 10.3 or 10.4. ?" (that they use to build the geodatabase). My own instinct says 'no', but given the situation, I thought it might be better to ask..?

‎04-12-2016

Once again thank you for your very helpful answer! Once I saw the clipping in your screenshot, I re-tried a trace in new data set, further north. And it worked! So it appears to me, the clipping issue is now my/our primary remaining issue. Regarding your QML code, thank you for that. I've now read it. Tracing-wise, it appears I do the same as you. However, the insight/ephipany you are giving me here, is that your QML code is also able to DISPLAY how the street-network from the Sqlite geodatabase looks (correct me if I'm wrong..) Assuming this is true, you've now given me 'the missing piece', solving my main problem of trying to "diagnose something invisible". I'll assume/hope GeodatabaseFeatureTable+FeatureLayer+Geodatabase can be combined in a similar way in C++/Qt. Otherwise, time for me to get better acquainted with QML.. I'll return to the ESRI partner/analyst, with your 'new clipped screenshot', and let them know it still gets clipped somehow. Ironically, the area that is missing from the street network, is where they themselves are located 🙂 If we figure out what goes wrong with the routing-network, I'll put the answer back here. Thank you so far.

‎04-11-2016

Thank you yet again! With your input, the esri partner was able to produce an updated (and much bigger) geodatabase. Unfortunately, now it behaves very weirdly. It does not deliver any actual routes, but now claims to solve all queries successfully?! They (the source) have tried to tweak various settings, but all attempts so far give same behaviour. Strange, that this time it doesn't give the '-1 unexpected error' when attempting to trace, but instead claims success. The source claims they are building with "same" settings as they built the 'original error set' (that DOES trace, but has problems.) All 'part' traces respond like this: Route km:0; geom:1/2/1, ie 1 path, 2 points, 1 seg. (apparently no curve is displayed.) I believe all we do happens in wkid 3057 - both basemap and network-graph. I have attached the new network here. We are continuing to look into what could be wrong this time, but I'd appreciate and love it, if you can offer any insight into why this dataset wouldn't work.. Cheers, Jakob.

‎04-08-2016

Update: Since march 15th, we have locally had a lot of back-and-forth on this issue (between me and my 'esri partner'), trying to get it to work. The good news is that it 'sort of works'. The bad news is the 'sort of' part.. We experience that 'benign'/obvious connections unexpectedly don't work. E.g. a major road intersection, that in reality allows traffic in all directions, is impossible to pass from north to south. The routing error we get is is code -1, "an unexpected error occured". What makes this so strange, is that the ESRI partner has no problems whatsoever, doing this "same" routing task in her source data (ie from/to same lat/lon as I get errors with.) Note that the ESRI partner is not running off the SQLLite-geodatabase - she's running on the source data set, which she uses to build the sqllite-network. We've so far spent fruitless weeks trying to resolve this, having an impatient client that was supposed to do production on our result, if it would work. I'll try to include (some of) my data case here. I'm considering posting this issue as a new post instead, and closing this existing query off as resolved (whose subject was the proper format of LocalRouteTask data.) However the queries are somewhat related, since it's the same goal - we were/are attempting the 'nobrainer of just setting up a local routing network :-)'.. Here the details: (edit: I HAVE ATTACHED the sqllite Geodatabase that fails/on which we can't route between the following coordinates.) I'm trying to route from -21,949970 / 64,079085 to -21,950415 with 64,078141 (supposedly WGS84 / decimal degrees lat lon.) On this screenshot, that is from point 24 to point 25. And the problem is, it won't move south across the west-east-going road. As the basemap (and reality) suggests, this should very much be possible. The esri partner says she is using "I am using the network dataset in Arc GIS desktop, and the network extension there". And she can trace across here, just fine. She sends me this screenshot, of how the street-graph actually looks: (ignore the green (2) circle on the right. The trace goes to the leftmost southern green dot.) What is visible from this screenshot is, that the intersection is a bit weird (the triangle), but I think I've seen that structure arise in other similar cases, with roads that split/merge.) I just received a mail from the esri partner, with some technical notes on how they build the data set. I qoute them here: " We have street centerlines as a feature class in ArcGIS File Geodatabase. The feature class has attributes that describes things like speed limit, road class and route weight. There is also another feature class that contains restricted turns. Then we used ArcGIS 10.4 Network Analyst to create a Network dataset from these feature classes, through wizards and with directions from Esri. The network dataset runs fine in our ArcGIS software (ArcMap) and routes everything correctly. It is a rather simple dataset based on few rules as we lack good information about lot of places but that should not cause errors in the routing. After that we used ArcMap to create a run time geodatabase with the Network and sent it to you. " If you deem necessary, we can try to provide you with the 'working' source data too. Thank you in advance for any light you can shed on this issue.

‎03-15-2016

(FYI - this is not a request for help at the moment, it is just a status update on situation so far.) Hi Again. As mentioned, the '.tn' folder was indeed critical - my ESRI partner says they 'tried something different', and sent me a new data set, which now included a ".tn" sub-folder. I am trying to get them to describe what 'something different' was.. [ UPDATE: "Before analyse I have to select the network in the left pane and the analyze and share...." ] Note: this only means I'm not crashing anymore, when trying to load data - I have no idea of behaviour/quality yet. Main note for this is: Building the data set, they got the error "...Actually I get and warning with the network now, saying that the network dataset has not been dissolved. .." We are looking into what that means.. I will update here with info on how/if we got it working.

‎03-15-2016

Thank you for the useful answer - my ESRI partner and I have tried to follow this, and it certainly brings us closer. However, I still get a crash when we try to load the .geodatabase. I am unsure, if the .geodatabase is enough on its own, or if an accompanying folder is necessary, which was there in the ESRI test data: "RuntimeSanFrancisco.tn". UPDATE: it would seem 'xxx.tn' subfolder may be required.. at least, if I hide that folder, in the ESRI demo example, I get a similar(?) crash when trying to load the geodatabase..? [UPDATE2: the .tn folder was indeed critical, see next reply] I went through the check-list on the webpage you've linked above (see below next screenshot.) I include a screenshot of the contents of the built geodatabase, according to QGis: It seems to include Streets, Streets_ND_Junctions, and RestrictedTurns. I assume, but am not sure, that layers 20-21-22 would be the coordinate-system description. I The checklist, with my uninformed comments: [[JG: ]] I was going through the info from http://desktop.arcgis.com/en/arcmap/10.3/map/working-with-arcmap/creating-arcgis-runtime-content.htm to see if we are violating anything obvious. I've listed the relevant sections here below, with comments: "(quoting) Network Data -" "If your map contains a network dataset or a network analysis layer that references a network dataset, you can include the network dataset in your ArcGIS Runtime content as a transportation network for routing and driving directions. When including a network, all feature layers the network references become part of the ArcGIS Runtime content. This may include layers that are not part of the map. For example, if you only have a network layer in the map, your ArcGIS Runtime content includes the streets, junctions, and turns feature classes associated with the network. For a network dataset to become a transportation network, there are a few restrictions to keep in mind: The network dataset must be part of a geodatabase [JG: I assume this part is OK?] . This excludes networks that are in SDC or shapefile format. The network dataset must be from ArcGIS 10.0 or later. [JG: I assume OK.. You can judge this.] If your network is from an earlier version, you can upgrade your geodatabase and your network. The network dataset cannot have an unknown coordinate system. [JG: I can see layer 20,21 and 22 mention something like this, but don't know if that is the required part.] The network dataset cannot use any VB or Python script evaluators. [JG: shouldn't apply here.] The network dataset cannot use any custom COM evaluators. [JG: shouldn't apply here.] A network dataset that uses live traffic [JG: shouldn't apply here.] will be ported to a transportation network, but the live traffic components are excluded since they are not supported. style="margin-bottom:20.55pt;background:#FEFEFE" Do not include network data—Exclude network datasets from the ArcGIS Runtime content. [JG: I assume you chose the first of these two options?] In short, it doesn't appear obvious to me, that we are violating any items on this list.. I'll return with more info, if we figure more out.

‎03-14-2016

I am trying to set up offline streeet routing in ArcGisRuntime for Qt, Using LocalRouteTask. However, I cannot find adequate documentation for how to obtain/configure an appropriate database. The info I've found, just refers to two string parameters, with no further details. The main things I've been able to guess, is from examining/reverse engineering the demo "RuntimeSanFrancisco.geodatabase" files. What I've learned so far: - There are 4 "geodatabase" formats. (One for each format name would have been sufficient for me.) Until that page is moved, a link here: https://developers.arcgis.com/qt/cpp/guide/supported-geodatabase-formats.htm describing the 4 formats. - the 'RuntimeSanFrancisco' is format 1 - .geodatabase-SQLite. Using QGis, I can see the SanFrancisco offline-routing example contains ALL the following data - I don't know how much of it is required for a street routing example. I notice the N_1_* tables, and the 3 Streets* tables (relevant because the named network is called Streets_ND) and the ND_27* tables, and Streets_ND_Junctions. (however, I note that the geometry-type is different compared to the next picture I show.) We had an ESRI partner prepare a 'geodatabase' data set for our client for offline routing, and they came up with a ".gdb" folder, which I, based on the link above, guess to be a socalled "file geodatabase" type (it's called 'file', because it's stored in a directory, as opposed to the SQLite variant, which is stored in a file. In case you wonder.) When I open that 'file geodatabase' in QGis, I get this: Again we see names 'Streets', 'Streets_ND_Junctions', and 3 ND_XXX* tables. However, trying to load this in our ArcGis Runtime application, just leads to crashes giving us no relevant info. (executing the LocalRouteTask constructor gives a crash.) The only documentation I find is this: https developers.arcgis.com/qt/cpp/guide/find-a-route.htm Find a route—ArcGIS Runtime SDK for Qt | ArcGIS for Developers from which I don't seem to find any info about how to obtain/build routing geodatabases? QUESTION: Anybody got any hints for how to figure this out / how one is supposed to figure this out? The ESRI partners who built the 'geodatabase' are nice people, but it appears to me, they have access to the same lack of documentation as I find..? How does one figure out how to build a usable routing-network data set for ArcGisRuntime LocalRouteTasks, and is it possible to diagnose it with other things than mute crashes? I spent some time googling this, but only found people asking similar questions in threads around the web, that never attracted any replies 😞 Detail question: I would like to know, if LocalRouteTask only works with the SQLite variant? From the linked 'supported' page, it suggests that "geodatabase file" would work too, but given the very little doc-details on LocalRouteTask itself, and my crashes, I'm wondering..? IE SQLite is the thing I've seen it work with.. Thank you for any help or advice you can offer on this. URLs: http developers.arcgis.com/qt/cpp/guide/supported-geodatabase-formats.htm

‎10-13-2015

Followup - this is now a registered bug as [BUG-000091356 - Qt Runtime displays miles rather than kilometers for the EsriRuntimeQt::Route::totalKilometers() method.] cheers, Jakob.

‎10-09-2015

Thank you for your verification! I tried looking at how to submit a bug report. I am in Europe, so I got lost at http_://support.esri.com/en/ , whose bewildering array of options mainly seem to apply to US customers and 'international distributors', so I ended up sending an email with the bug description to my national ESRI distributor's support-email. Thank you.

‎10-07-2015

in 10.2.6, and possibly also 10.2.3, I experience that EsriRuntimeQt::Route::totalKilometers() 'consistently' returns miles, not kilometers? Luckily, ER::GeometryEngine::geodesicLength seems to give the correct result, or at least the same value I can measure with Google Earth. In fact, calling route.totalMiles() gives same value that totalKilometers() gives..? In a way, I'm impressed with ESRI trying to reconcile the age-old difference between metric and imperial units, with this initiative. I just suspect, that it takes someone on the scale of Napoleon to achieve change on that level. On the positive side, route.totalMiles() seems to return a correct value, so it's about 50% correct. I am running off these data: https:_//route.arcgis.com/arcgis/rest/services/World/Route/NAServer/Route_World http:_//services.arcgisonline.com/arcgis/rest/services/World_Street_Map/MapServer I am running on msvc2013, 32bit, and based in Europe; the example was measured in Iceland (on map). I'm curious if it is related to something in my setup, or if any others experience similar.. Seems like a weird bug people would react to. My queries look like this: bool bLocal = ( !UseEsri::useOnlineRouting() ); //!NodeLinkDlg_Gis::OnlineRoutingHack); if (bLocal) { #ifdef HACK_10_2_3 ER::LocalRouteTaskParameters lparameters = HACK_10_2_6_STAR lroutingTask.defaultParameters(); #else // > 10.2.3: ER::RouteTaskParameters& lparameters = HACK_10_2_6_STAR lroutingTask.defaultParameters(); #endif // HACK_10_2_3 lparameters.setOutSpatialReference(spatRef); lparameters.setOutputLines(bWithMeasure ? ER::NAOutputLine::TrueShapeWithMeasure : ER::NAOutputLine::TrueShape); lparameters.setReturnRoutes(true); lparameters.setStops( HACK_10_2_6_AMP stops); lroutingTask.solve( HACK_10_2_6_AMP lparameters); } else { // Online: #ifdef HACK_10_2_3 // For some reason, >10.2.3 does not allow us to check if routingtask object is correctly initialized? if (oroutingTask.isEmpty()) { // bad path to data QMessageBox::warning(NULL, QObject::tr("Routing Error"), QObject::tr("The oroutingTask is empty."), QMessageBox::Ok ); // this return false; } #endif // HACK_10_2_3 // stops.setCompressedRequest(true); #ifdef HACK_10_2_3 ER::OnlineRouteTaskParameters oparameters = HACK_10_2_6_STAR oroutingTask.defaultParameters(); #else // > 10.2.3: ER::RouteTaskParameters* p_oparameters = oroutingTask.defaultParameters(); // HACK_10_2_6_STAR if (p_oparameters == NULL) { debstr() << "Err: oroutingTask.defaultParameters failed!\n"; QMessageBox::warning(NULL, QObject::tr("Routing Error"), QObject::tr("oroutingTask.defaultParameters failed."), QMessageBox::Ok ); return false; } ER::RouteTaskParameters& oparameters = *p_oparameters; #endif // HACK_10_2_3 oparameters.setOutSpatialReference(spatRef); oparameters.setOutputLines(bWithMeasure ? ER::NAOutputLine::TrueShapeWithMeasure : ER::NAOutputLine::TrueShape); oparameters.setReturnRoutes(true); oparameters.setStops( HACK_10_2_6_AMP stops); oroutingTask.solve( HACK_10_2_6_AMP oparameters); }

‎09-30-2015

We recently upgraded our esri app source code from 10.2.3 to 10.2.6, since 10.2.3 apparently doesn't support authentication to esri online routing servers. However, we can't find any 32bit build of the sdk for Linux at SDK Downloads | ArcGIS for Developers https_//developers.arcgis.com/en/downloads/ Only a 64bit build? Is this a mistake, am I overlooking something? Some of our developers work on linux, and it's a tall order to tell them to change their linux from 32bit to 64bit, in order to access online street routing? Thank you in advance, Jakob Gaardsted.

Online Status	Offline
Date Last Visited	‎11-11-2020 02:24 AM

My Ideas

Latest Contributions by JakobGaardsted

Re: LocalRouteTask.solve() crashing on 'innocent' query

LocalRouteTask.solve() crashing on 'innocent' query

Re: LocalRouteTask geodatabase format, documentation/how?

Re: LocalRouteTask geodatabase format, documentation/how?

Re: LocalRouteTask geodatabase format, documentation/how?

Re: LocalRouteTask geodatabase format, documentation/how?

Re: LocalRouteTask geodatabase format, documentation/how?

Re: LocalRouteTask geodatabase format, documentation/how?

Re: LocalRouteTask geodatabase format, documentation/how?

Re: LocalRouteTask geodatabase format, documentation/how?

LocalRouteTask geodatabase format, documentation/how?

Re: EsriRuntimeQt::Route::totalKilometers() returns miles, not kilometers?

Re: EsriRuntimeQt::Route::totalKilometers() returns miles, not kilometers?

EsriRuntimeQt::Route::totalKilometers() returns miles, not kilometers?

Where is 32bit linux 10.2.6 build?

Re: EsriRuntimeQt::Route::totalKilometers() return...

Re: EsriRuntimeQt::Route::totalKilometers() return...