Latest Contributions by Nicholas-Furness

Hi @JBuchanan. Great to see you diving in to the new APIs. We're a little thin on the ground with samples at the moment, but building more out as we can. Some answers for you: 1. Outputting to an in-memory raster for use in a raster layer is something we know is an important capability, and is on the roadmap. In terms of that sample, you're right, it's not writing out loads of rasters and loading them in. That's actually using the AnalysisOverlay. This sample shows how to do that (for a single overlay), but the principle is pretty simple: once you have your analysis defined, create a FieldAnalysis from it, and add that to an AnalysisOverlay in your MapView's AnalysisOverlays collection. Then just update the analysis parameters (anywhere in the analysis chain), and the display will update to reflect those changes. In that example, from the DevTech Summit plenary, the code does this: Creates one AnalysisOverlay and adds it to the MapView's AnalysisOverlays collection. For each drone, it creates a ViewshedFunction with the drone's parameters (including location and heading). All these ViewshedFunctions use the same imported elevation ContinuousFieldFunction (as in your first code snippet). Create a FieldAnalysis for each ViewshedFunction, providing the same ColormapRenderer. Add all the FieldAnalysis objects to the Analyses collection of the AnalysisOverlay from step 1. Now things are set up, the SDK takes over. As drone position updates come in, just update the parameters for the appropriate ViewshedFunction, and the SDK will handle the rest. Note that there are currently a couple of limitations to be aware of: Viewshed and Line of Sight functions don't yet work correctly in geographic coordinate systems, so this may give you unexpected results in a SceneView. The spatial reference of the final analysis needs to match that of the GeoView. If your map is WebMercator, that usually just means tell the createAsync() call to project your elevation to WebMercator. We're working hard on reducing these limitations. One hint: as you test, keep an eye on the GeoView's AnalysisViewStateChanged event to help debug issues. 2. I'm not sure I can explain this one. I'm not a .NET developer, but what you're doing looks reasonable (especially since you've tried reversing the order). One note: when I've done this kind of reclassification, I've used a lower and upper bound (see the swift example halfway down this blog post). My initial thought is the SDK might be reducing/optimizing things internally in a way you're not expecting, but that doesn't explain why it works when chained in one line vs applied in an iteration. Someone smarter than I am will add their thoughts… 3. Signed 32-bit integers should behave as expected, with values in the range of -2147483648…2147483647, so consider that the same upper limit for both 32-bit signed and unsigned ints. 4. The CreateAsync documentation says "Supports reading of all raster pixel types except 64-bit float." Our target has been the pixel types listed as supported by Pro in this table, with the exceptions mentioned in the CreateAsync constructors. I'll see if we can maybe be a bit more explicit about this. [Updated to correct "projected" to "geographic" coordinate systems with respect to Viewshed/Line of Sight limitations] ... View more

Hi @BenHaas4. Sorry for the delay getting back to you. Assuming you are setting returnGeometry=false on the QueryParameters being used to populate the table (I think you are), then I would expect this behaviour, yes, though arguably we should treat this as an error and provide better feedback. What you have with a ServiceFeatureTable from a feature layer (i.e. NOT a non-spatial table) is a table that expects a geometry as part of its schema. It's reading the feature service definition to get to that state. So the geometry field cannot be NULL in this table, but you're trying to populate the table with NULL geometries. When you then try to populate it with geometry-less features, what should it do¹? It's an invalid state for that feature table to have records with no geometry. You could do one of two things: Don't populate the table manually. Instead use the default featureRequestMode (onInteractionCache) and then simply query (not populate) the ServiceFeatureTable using the QueryParameters. That will return you a dataset of the features you want, without their geometries. Populate the service feature table including the geometries, but then ignore the geometries when you work with the features you get back. Hope that helps. Let me know if I've missed something. ¹ Well, what it should probably do is tell you that you can't do what you're trying to do, not nothing at all and leave you hanging… I'll see if we can look into that. Feels like a decent improvement to the SDKs. ... View more