|
POST
|
Hey Jake, In the 10.2.x Runtime (which Asif is using) that's what the AGSQueryTask does (plus it integrates with the credential cache). Just initialize it with a URL to the service, and start firing queries against it. The NSOperation you get back can be cancelled if need be. In the 100.x runtime, you can hold on to a reference to an AGSServiceFeatureTable that you load once and query against often (actually, you don't need to load it explicitly - any calls to query will take care of loading it). You don't need to create a layer from it or add it to a map. And when you run a query against it, you get back an AGSCancelable, which you can… as you might expect… cancel The only limitation is that you can't list specific fields for the query. There's a sort of workaround for that involving setting the featureRequestMode to manualCache and populating the table using the query and fields you're after, then querying the table (which will run off the local cache and return immediately), but that is admittedly a bit tricky and if you have parallel queries going on with different field sets you'd want to have separate table instances; one for each field set. Lastly, 10.2.x's AGSQuery.returnGeometry and 100.x's AGSQueryParameters.returnGeometry can be set to false to prevent geometry being returned. Asif: If you can't control CLLocationManager.distanceFilter, then in your locationUpdate handler you could use AGSGeometryEngine.distanceFromGeometry:toGeometry() to see how far the new point is from that last acceptable point, and only fire a query once the distance has reached a threshold. So, you're still getting as many updates from CoreLocation, but you're not firing queries off until you've moved a sensible amount. Also, in your sample code, before your "do" block, set up a "let trafficSpeedLayer = ..." there. Right now, as soon as your "do { }" block exits, your trafficSpeedLayer is being deallocated, and so the query callbacks have nothing to latch on to when they happen. Cheers, Nick
... View more
09-24-2018
09:38 PM
|
0
|
0
|
2375
|
|
POST
|
Hi. Thanks for the question. Please see if the reply to your other question here resolves the issue for you: https://community.esri.com/thread/221746-query-a-feature-layer-without-adding-the-layer-to-the-map#comment-801385 Nick.
... View more
09-24-2018
08:56 AM
|
0
|
0
|
696
|
|
POST
|
Sounds like you are not holding on to the instance of the layer, so it's going out of scope and being destroyed before the query callback. When you add a layer to the map view, it's being retained by the map view so you're seeing results. Create an object property (rather than a function variable) to hold on to the layer reference and you will get the completion called. You only need to create one instance of the layer and can query it multiple times. You should not create an instance each time your location updates. Sounds like this could be causing the issue in your other question: Querying feature on device location change Nick.
... View more
09-24-2018
08:55 AM
|
0
|
1
|
2375
|
|
BLOG
|
Why are GIS features using one spatial reference whereas the location listener is receiving coordinates in different spatial reference? iOS's CoreLocation returns Lat/Lon, i.e. wgs84 (4326). We can't assume you need it in a specific spatial reference so we don't translate it. But you can use AGSGeometryEngine.projectGeometry() to project it to the route geometry's spatial reference. As for why the route is in Web Mercator (3857): Our major public services (World Geocoder, World Route Task) output in 3857 by default because that matches our default basemaps and so the returned geometries can be overlaid on the map with no extra transformation. If you're working with a different spatial reference in your map, you can specify the AGSRouteParameters.outputSpatialReference property when calling AGSRouteTask.solveRouteWithParameters(). One note: your logic above is likely to always return false though. The chances of the GPS location actually being precisely on the line are vanishingly small. You should buffer around your location by a few meters using AGSGeometryEngine.Buffer() or AGSGeometryEngine.geodeticBuffer() (perhaps adjusting the buffer size by considering AGSLocation.horizontalAccuracy) and check if that buffer polygon intersects with your maneuver line. Or else, as I suggested earlier, measure the distance between the location's point and the maneuver line. Lastly, may I suggest that if you have further questions about this that you post them in the iOS Forums where the community will be more likely to see them? Thanks!
... View more
09-13-2018
08:59 AM
|
1
|
0
|
1066
|
|
POST
|
Hi YunFeng Wu, Are you able to share that data with us? This seems unexpected and we'd like to reproduce the issue. Thanks! Nick.
... View more
09-11-2018
11:47 AM
|
0
|
1
|
671
|
|
POST
|
Are you getting any results, or do all solves fail? I've seen that error when the stops cannot be located on the network (that is to say the network is too far away from the stops). If you're sure the stops are OK (lat/lon the right way around, and spatial reference is correct), then another thought below: Network models have a number of parameters that determine just how the network model is used and to which you make changes and add your stops. I'm not familiar with ArcMap 10.5 and how it configures those parameters, but one thing to check is whether you're using the default parameters as the basis for your runtime requests. One thing to try: once you've created your AGSRouteTask, try calling defaultRouteParametersWithCompletion() and then modifying those parameters with your stops and calling solve from that completion block. See this pattern. Let me know if that helps. Nick.
... View more
09-11-2018
10:17 AM
|
0
|
0
|
869
|
|
BLOG
|
Hi Manasa Parida. Thanks for the questions. We distinguish the functionality that you're talking about as Navigation vs Routing. The Routing API that we already provide (and which you're making use of) gives you the components you need to get from A to B. But a full Navigation experience that tracks that progress and adjusts the route on the fly and intelligently (such as that provided by the Navigator app) is something you will have to build yourself for the time being. Some high-level thoughts, based off your questions: Using the locationDisplay.locatidHandler is the correct approach to get updates to the user's position. Use AGSGeometryEngine.distanceBetweenGeometry1:geometry2() to calculate the distance of the user's location from the planned route. Perhaps look at the distance between the AGSLocation.position and the AGSDirectionManeuver.geometry to see if the user has moved too far from the route. Consider building some logic to work out which maneuver the user is currently on rather than treating the route as a whole. This can help with cases where the route doubles back on itself, or crosses over itself. By working on a maneuver-by-maneuver basis, you can work out when to read the next maneuver step. E.g. get the end point of the current maneuver, and use GeometryEngine to check when the user has approached within a certain distance of it before reading the next maneuver's text. Realize the limitations of your GPS data. Does the environment cause bad data from time-to-time? How frequently do you get updates (you can control this through the AGSCLLocationDataSource.locationManager in the default case)? And you should probably smooth out bad data rather than allow it to trigger thresholds. Variables like GPS accuracy/quality/frequency or complexity of the route all play into making the work tricky. Nick.
... View more
09-10-2018
09:51 AM
|
1
|
0
|
1066
|
|
POST
|
Hi Michael, Not sure I have code available. At the moment, we don't expose the right properties on the symbol objects to modify the Arcade expression (deeper symbology API is coming in the next couple of releases too - you can imagine a lot of this is interrelated). In the example I've seen, this Arcade expression is created in ArcGIS Pro to drive the symbol size: As you mention, it's not an ideal workflow to manage with a lot of layers. I'm not familiar with the Pro SDK, but I imagine you should be able to write something to manage this, or manage it with some Python code. However, as a proof of concept this should at least let you figure out if this workaround will work for you. Alternatively, you can take the symbol definition JSON that this creates when the MMPK is generated, and modify that in the runtime to update as necessary, using AGSSymbol.fromJSON() to create a new symbol to apply to the layer. That's the code I have to work out how to dig up. Cheers, Nick.
... View more
09-06-2018
03:39 PM
|
2
|
9
|
4991
|
|
POST
|
Thanks Muruganandham Kuppan. Great to hear. Could you mark your original question as answered please? It'll help other people home in on the right answer.
... View more
08-30-2018
09:04 AM
|
2
|
0
|
1996
|
|
POST
|
Hi Muruganandham Kuppan, This reply to another thread should get you going: https://community.esri.com/message/771776-re-how-to-use-external-gps-location-data?commentID=771776#comment-771776 Cheers, Nick.
... View more
08-29-2018
12:25 PM
|
0
|
0
|
847
|
|
POST
|
To reiterate Michael Branscomb above, we agree that Reference Scale is important. Our goal is to introduce support for Reference Scale in the Q1/Q2 2019 Runtime release but of course schedules can change and functionality can slip (though we're working hard to hit that release). In the meantime, some customers have had success with a partial workaround. The gist of it is that you define a symbol's size when authoring the map using an Arcade expression along the lines of (1/$view.scale)*1000000. Some notes on this approach: This is not true Reference Scale. Reference Scale is defined by the map or layer. This approach is a function of the layer's renderer. You'd need to tweak the factor here for each layer to get close to what you want. This requires that the layer be rendered in static mode. It is not currently supported in dynamic rendering mode (Arcade support in dynamic rendering mode is coming, but is not there yet). You should use 100.3 or later for using this approach. Hope this helps! Nick.
... View more
08-09-2018
09:38 AM
|
2
|
11
|
4991
|
|
POST
|
When using a Polyline as the search geometry you probably want AGSQueryParameters.spatialRelationship to be AGSSpatialRelationshipIntersects. See here for more options. Does that help?
... View more
08-09-2018
07:48 AM
|
0
|
0
|
724
|
|
POST
|
Good to know. Would you mind flagging the question as answered? It'll help others when browsing the questions. Thanks!
... View more
07-30-2018
11:52 AM
|
0
|
0
|
1988
|
|
POST
|
Thanks Muruganandham Kuppan, The documentation here has some specific requirements for ensuring the relationship is written and committed properly. If you're meeting those and are still seeing this issue, it might be best for you to open a support ticket. It's hard to tell from just the info provided above without more context, and support will be able to dig into that with you more.
... View more
07-23-2018
12:49 PM
|
0
|
1
|
1120
|
| Title | Kudos | Posted |
|---|---|---|
| 1 | 12-17-2025 10:12 AM | |
| 1 | 11-05-2025 10:52 AM | |
| 1 | 11-04-2025 08:55 AM | |
| 1 | 11-04-2025 08:38 AM | |
| 1 | 11-01-2025 03:25 PM |