Latest Contributions by Nicholas-Furness

I'm guessing the issue is that you're getting envelopes and working with them. Compare the visibleArea polygon (rather than its envelope) against the geoElement's geometry (rather than its envelope). Envelopes are always orthogonal to the spatial reference, so in the case of the viewArea, a polygon that's rotated 45º will result in an envelope encompassing a lot of space outside that polygon. And in the case of the geoElement's point geometry, the envelope will have zero width and height, so it's just adding work to the comparison. Much better just to use the point. Let me know if that helps. ... View more

Yeah, the app should remain responsive while those 3000 files are opened (except perhaps when you're stepping through in the debugger). Thanks for opening that other issue. That's the best way to get feedback on this issue. ... View more

Hi @radimbachb. No problem! Not off topic yet 🙂 The load() method should not be blocking (though it might take some time to open and load all 3,000 files, but that should happen in the background). If you're stepping through in the debugger, that might have something to do with it. Can you set a breakpoint after the load rather than stepping through it? Or try the app without the debugger. If that doesn't show things working as expected, then we are starting to get off topic here so could I ask you to pose the question about RasterElevationSource load() blocking over in the Qt forum please? ... View more

Hi @radimbachb (this might also be of interested to @IgnisDev). What you're doing is reasonable, but we do have APIs that can make it much easier for you. What you need to do is create a standalone Surface. You can add 1 or more ElevationSources to it, where an ElevationSource can be an ArcGISTiledElevationSource (using a service or a local TPK/TPKX file), or it can be a RasterElevationSource (which can use one or more local DTED files). Please note: when using a standalone Surface like this, you do currently need to explicitly load each of its ElevationSources. Here's some sample Swift code (though you would use a RasterElevationSource instead)… let surface: Surface = { let surface = Surface() let worldElevationServiceURL = URL(string: "https://elevation3d.arcgis.com/arcgis/rest/services/WorldElevation3D/Terrain3D/ImageServer")! let elevationSource = ArcGISTiledElevationSource(url: worldElevationServiceURL) surface.addElevationSource(elevationSource) Task { await surface.elevationSources.load() let failedSources = surface.elevationSources.filter({ $0.loadStatus == .failed }) for source in failedSources { print("Elevation source \(source) failed to load: \(String(describing: source.loadError))") } } return surface }() and you can then call it with something like this… let elevationAtPoint = try await surface.elevation(at: mapPoint) Hope that helps. ... View more

Hi @sveinhal.  How we cache internally varies by layer type, and I agree is quite opaque. It's something that's been on our backlog to improve for some time, and internally we're considering how we can deliver a better experience. Posts like this really help us to prioritize that, so thank you. In terms of us responding to system memory pressure notifications, a better solution would probably be via an API like the one you suggest, so that you as a developer can flush the cache when you receive the notification; for many developers, having data simply disappear from their map without their say-so can be a showstopper. That said, I'm glad you've identified a solution that can tide you over until we can deliver something more refined. We have made some improvements in the past. For example, we used to cache image tiled data in memory but realized that for many platforms this was duplicating OS-level HTTP cached data. That did make a good difference to the memory footprint for a lot of people, but there is definitely more that we can do across many layer types. Just to set expectations: this is probably not something we'd deliver in the next release or two. But it is something we're very interested in improving and is high on our list of priorities. ... View more

Hi. Yeah, not all Living Atlas content is completely free. You can see from the details page of the item in question, that it's "Subscriber" content. You can learn more about what that means here, but the short of it is that you'll need to authenticate to use it. It won't cost you any credits to access, but there are some items of content that for various reasons we cannot just open up publicly. You should be able to use a user-based or app-based OAuth token. ... View more

Hi @SalvadorApltp . The License string and the API Key are different things and independent of each other: The License string removes the developer watermark and enables specific capabilities of the SDK (depending on the license level). You always need a License string to deploy your app to production. If you don't provide a License string, you can use all the capabilities, but only for development and testing. The API Key grants an access token you can use to access hosted content. You only need an API Key if you are accessing private content (as you are). See these topics for more information (note, I am linking to the ArcGIS Maps SDK for Kotlin documentation since the ArcGIS Runtime SDK for Android is in extended support): Licensing levels and capabilities (expand the "License strings vs API keys" note). Security and authentication In this reply I focused on API Key because that seems to be what you're using, but note that API Key is just one way to access secure (private) content. You can learn more at the Security and authentication link above. ... View more

Hi @MaríaBencomo  Glad that improves things, but I'm curious why you're using densify at all. For straight-line segments you shouldn't need to. I could be missing a nuance of your use case though. ... View more

I assume the route is being drawn using your own custom code and stored as a Graphic (the pathRoute above looks like a GeoElement of some sort - can you confirm if it's a Graphic or a Feature, though it shouldn't make a difference). It looks like sometime between tapping the 4 points and writing it out to JSON, it is being densified somehow. Do you have any code that calls GeometryEngine.densify() or .densifyGeodetic()? ... View more

Just posted an update on the Xcode 16 issue. ... View more

Hi @MikeLeavy. As experienced iOS developers, the team is as excited to work with iOS 18 as everyone else, and we have been working closely with Apple to identify a solution since Xcode 16 RC was posted last week. It did surprise us that Xcode 16 RC did not address this Swift Concurrency compatibility issue since we had raised it with Apple early in the Xcode 16 beta and, historically, compatibility issues like this have often existed through the entire Xcode beta period only to be resolved in the RC.  In our discussions with Apple last week, they did not completely discount the option that the Xcode bug could be fixed in final, but we expect it will not. With that in mind, we will be publishing guidance today, and rest assured we're working hard to come up with a solution, which we hope to deliver this week. In the meantime, if you want to use ArcGIS Maps SDK for Swift 200.5, you will need to do so with Xcode 15. ArcGIS Maps SDK for Swift 200.4 should work with Xcode 16, but I only mention that in case it helps to tide you over. We recognize that for most, these options are not a good solution, and the current situation is highly frustrating. I'll reply to this thread as soon as we have a solution. ... View more

I'd just add to @KoushikHajra's reply that visual analysis was deliberately designed and built to work only on what you see on the display. That's part of the reason that the actionable output of the analysis is very limited (e.g. we don't provide a polygon output from the viewshed analysis). What Koushik alludes to is that to deliver a performant and responsive display, there's a lot of trade-off that has to happen on different devices in consideration of their GPU, CPU, memory limitations, and data loads. As he mentions, desktop systems can afford to less aggressively reduce LOD levels at distance, but at 50km you'd almost certainly still see degradation. Rather, the way to get an accurate and actionable analysis is to use the Geoprocessing APIs to make a request to a GP service. See the API Reference, and this viewshed sample. All that said, we are always interested in identifying ways we can improve the SDKs so if you could DM me with more details on your use case, I'd like to learn more about what you're trying to build here. ... View more