|
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
|
5957
|
|
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
|
2783
|
|
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
|
1079
|
|
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
|
5957
|
|
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
|
935
|
|
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
|
2618
|
|
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
|
1551
|
|
POST
|
Was the feature you're relating to created and added in code (as opposed to being retrieved from a query)? If so, have you called refreshObjectID on it after the add completed?
... View more
07-06-2018
06:25 AM
|
1
|
3
|
1551
|
|
POST
|
It's really hard to determine without more info or sample code, but in general that error means that something else is already tied to that table. The table may already be part of the map.tables collection or a layer in your map might be using it. If you still really need to duplicate the layer, you could call copy() on it and add that reference to the map but I'd suggest you double-check that you're not unwittingly duplicating things.
... View more
06-26-2018
08:44 AM
|
0
|
0
|
2125
|
|
POST
|
It should be larger but not that much larger by a long shot. We've found that the 100.1 Runtime adds about 60Mb to an app (so even less when you consider the existing impact of Runtime 10.2.x). Has the app been installed via the App Store or TestFlight? What I think may be happening is that the Universal IPA is being installed to the device bypassing the App Store and TestFlight which should thin the app automatically (assuming you're on iOS 9 or later). Could you take a look at these steps I posted to a possibly related question and let me know if that helps? Nick
... View more
06-19-2018
09:02 AM
|
1
|
2
|
1122
|
|
POST
|
Hi m h, Were you able to get this working by inheriting from AGSImageTiledLayer? Nick.
... View more
06-18-2018
12:46 PM
|
0
|
2
|
2618
|
|
POST
|
Hi, Depending on what data.graphic is, you may need an additional step. If data.graphic is an AGSArcGISFeature instance which you created, added, and then stored with applyEdits (as opposed to an object you got back from a query), then before you do further operations on it, you should call AGSArcGISFeature.refreshObjectID(). In more detail: For any feature you get with a query, it'll already have the data store's ID populated, but if you create the feature, there is no ID until it's stored (when working against a local geodatabse/shapefile, that happens when you call addFeature, or when working against an AGSServiceFeatureTable, when you call applyEdits). Since it's bad for us to assume we can update your Objective-C objects without telling you, we don't set the ID automatically as part of the add/apply operation, so if you want to continue using the same reference to the AGSArcGISFeature for future writes (e.g adding attachments or relating records), call AGSArcGISFeature.refreshObjectID(). In your case above, try calling refreshObjectID() on data.graphic before querying for related features. Let me know if that helps. Nick.
... View more
06-18-2018
11:37 AM
|
0
|
2
|
2125
|
|
BLOG
|
At their annual developer's conference a couple of weeks ago, Apple announced that they will be deprecating OpenGL and OpenGL ES with the releases of macOS 10.14 and iOS 12 later this year. What does this mean for the ArcGIS Runtime SDKs, which use these technologies, and for your apps built on top of them? Short version: just carry on as normal. Work is already underway at Esri to adopt Metal well in advance of Apple removing OpenGL and OpenGL ES. As a Runtime developer, you'll simply download an updated version of the Runtime SDK. For the longer version, read on. Runtime Engineering The ArcGIS Runtime engineering team here at Esri began planning for Metal support earlier this year as part of a broader review of Runtime GPU performance and capabilities. Once complete this work will dispense with the need for OpenGL on iOS and macOS. That said, it's also important to understand what Apple mean by "deprecation"… Apple Deprecations When Apple deprecates a technology, it's a warning that the technology will be removed in "some future version of the OS" (see Apple's notices here for OpenGL and here for OpenGL ES). That means it will work until at least Fall 2019 when iOS 13 and macOS 10.15 will be released. But in Apple's own words, they take it even further: Deprecated APIs typically remain present and usable in the system for a reasonable time past the release in which they were deprecated. This means it's quite possible we'll see OpenGL and OpenGL ES stick around through iOS 13 and macOS 10.15, taking us to Fall 2020. Although Apple could always opt for a more aggressive timeline, experience tells us that's unlikely. Update from WWDC 2019: As predicted, Apple will continue to include OpenGL in iOS 13. We continue to make great progress on Metal implementation in Runtime and will keep you posted. Cross Platform ArcGIS Runtimes What about the ArcGIS Runtime SDKs that target iOS and macOS as part of a cross-platform strategy? Well, thanks to the encapsulation of functionality in the common Runtime core, all of the above considerations and timelines also apply to the ArcGIS Runtime SDK for .NET (Xamarin.iOS) and to the ArcGIS Runtime SDK for Qt. Your Apps Once Esri releases a version of the Runtime SDK that includes support for Metal, you should plan on updating the Runtime SDK used by your apps before Apple removes support for OpenGL.
... View more
06-18-2018
10:39 AM
|
1
|
0
|
1903
|
|
POST
|
Would you be able to subclass from AGSImageTiledLayer instead, or is there specific AGSArcGISTiledLayer functionality that you need?
... View more
06-06-2018
02:46 PM
|
0
|
3
|
2618
|
| Title | Kudos | Posted |
|---|---|---|
| 2 | Thursday | |
| 2 | 2 weeks ago | |
| 4 | 4 weeks ago | |
| 1 | 01-29-2026 09:39 AM | |
| 1 | 12-17-2025 10:12 AM |