nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Routing issue

ChrisKeefer

I'm having an issue with the directions coming back from a RouteTask. The DirectionsFeatureSet object that comes back has an array of features for each of the directions and the attributes of each are fine (time, text, maneuverType, etc). The geometry of each of these features, which are Polylines representing a specific segment of the directions, is present with multiple MapPoints in the paths array, but their x and y values are 'Infinity'. The mergedGeometry Polyline also has the same issue with its MapPoints having 'Infinity' x and y values.

I'm trying to emulate the Route Directions sample where the user can click on a segment of the directions and a graphic is overlaid on the route. Because the geometry is bad I can't make a valid graphic to overlay.

I tried calling the Route service REST endpoint via Firefox to see what gets returned and I noticed that the geometry is compressed ("compressedGeometry" : "+1m91-...some nasty string"). I figure the ESRI Flex API should take care of that but I don't know.

Has anyone else had this issue or know if the compressedGeometry thing is automatically handled?

NOTE: I'm using the ESRI Flex SDK 2.1 with the ESRI viewer 2.1 hitting an ArcGIS 10.0 server

Thanks,
Chris

タグ付けされた投稿をもっと見る

Accepted answers

All comments

Hernando_CountyProperty_Apprai

I know this is an old thread but just wanted to thank Dmitry for solving a problem I was having with merged geometry coming back as infinity. Change the analysis settings of Output Shape Type to True Shape solved it.

DmitryKudinov

Hi Juliano,

10.0 REST API (and, consequently, client APIs such as JavaScript API) does not support 3D geometry. In some cases though, compressed geometry returned by NAServer (DotNet ArcGIS Server only) through REST can contain Z-values. In order to decode this format you will need to do some custom client-side programming. Please see this code-gallery sample: http://resources.arcgis.com/gallery/file/java/details?entryID=7B5F4B9F-1422-2418-A0AA-E4F68C404124

It's still important to mention that although you can potentially deliver Z-values to client through the way described above, 10.0 REST API still will not allow to pass trough 3D input locations.

If you need to specify 3D input locations while working with 10.0 NAServer, you can use NAServer SOAP API which fully supports 3D input/output.

10.1 REST API and corresponding releases of client APIs will support 3D.

Dmitry

JulianoKersting

I have a campus 3D interior/exterior buildings network and I am using a 3D network map published in server10.

Similar error is happening when I get the directions featureset, all segment geometries (including extent) are infinity and it does not allow me to use direction properly.

Is there a workaround to that? Is the new version 10.1 going to support 3D networks?

Please advice,

DmitryKudinov

Hi Chris,

The most probable case in which you can get new 10.0 formatted compressed geometry through 10.0 REST endpoint is if the underlying network dataset is a 3D one, or somehow server produces output route geometry with measures.

If you are using your own network dataset, please make sure that none of the network dataset source feature classes are 3D aware. If any of them is a 3D feature class, you will have to make them 2D and rebuild the network.

To make sure that NAServer does not return compressed geometry with measures, please make sure tat you pass RouteParameters.outputLines = "esriNAOutputLineTrueShape". Also, to be absolutely sure, open the published map document in ArcMap, open corresponding Route layer's "Analysis Settings" dialog box and check that "Output Shape Type" value is set to "True Shape". Save the document, restart the service, and clean the REST endpoint cache (or restart the web server).

Dmitry

ChrisKeefer

In case anyone else is having this issue, I thought I'd update you on my current progress. I took the code from the link that Robert posted and ran it with the compressed geometry strings that were returned from calling the routing service via REST (using a web browser). The code failed with my compressed geometry strings but worked fine with the test compressed geometry string listed on the site. Then I noticed that my compressed geometry strings all had a '|' character in them, which the code didn't account for.

After doing a little searching, I found the following link which says that in 10.0, compressed geometries can contain M and Z values in addition to X and Y values. The link provided some code to parse such compressed geometries and after looking at it, the M and Z values are located after '|' characters in the string. Since I'm using 10.0 to serve the route task service, I assumed that was my problem. I tried the code listed there and it parsed my compressed geometries without issue.

So it seems like the Flex SDK 2.2 doesn't support parsing compressed geometries with M and Z values. I'm not sure what to do from here if the SDK doesn't support it. I don't know if it's possible to tell the service to only return X and Y values.

- Chris

ChrisKeefer

Robert,
Thanks for the info on the compressed geometry. Unfortunately I don't have access to the compressed geometry from the Flex RouteTask call since it automatically converts it (or tries to) to Polyline Geometry objects. I can make the REST call through the browser and then use that algorithm to convert the compressed geometry myself just to see if what is coming back from the server is valid.

- Chris

rscheitlin

Chris,

Here is some info on compressed geometry.

http://resources.esri.com/help/9.3/arcgisengine/ArcObjects/esrinetworkanalyst/INACompactStreetDirection_CompressedGeometry.htm

会話に参加する

サインインしたメンバーは投稿、更新のフォローなどができます。初めてですか？無料アカウントを登録してください。

クイックリンク

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.