AnsweredAssumed Answered

LocalRouteTask.solve() crashing on 'innocent' query

Question asked by pylgrym on May 9, 2016
Latest reply on May 30, 2016 by pylgrym

'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)

0QSortFilterProxyModel::mapToSourceQt5Cored0x666a01f7
1EsriRuntimeQt::OnlineRouteTaskParameters::getImplEsriRuntimeQtd0x11c6ed2
2EsriRuntimeQt::SolveCondition::messagesForConditionEsriRuntimeQtd0x11f846b
3EsriRuntimeQt::SolveCondition::messagesForConditionEsriRuntimeQtd0x11f693f
4EsriRuntimeQt::SolveCondition::messagesForConditionEsriRuntimeQtd0x11f63d3
5EsriRuntimeQt::SolveCondition::trUtf8EsriRuntimeQtd0x11b7b38
6EsriRuntimeQt::LocalRouteTask::isValidEsriRuntimeQtd0x11c88e1
7EsriRuntimeQt::LocalRouteTask::isValidEsriRuntimeQtd0x11c9669
8EsriRuntimeQt::LocalRouteTask::isValidEsriRuntimeQtd0x11dab1c
9EsriRuntimeQt::LocalRouteTask::isValidEsriRuntimeQtd0x11daa4c
10QSortFilterProxyModel::mapToSourceQt5Cored0x6643c3f8
11QSortFilterProxyModel::mapToSourceQt5Cored0x664433c5
12_callthreadstartexthreadex.c3760xff63651
13_threadstartexthreadex.c3590xff63861
14BaseThreadInitThunkkernel320x7511338a
15RtlInitializeExceptionChainntdll0x77739902
16RtlInitializeExceptionChainntdll0x777398d5

 

 

 

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

Attachments

Outcomes