Latest Contributions by KyleGruber

@JakeSkinner Sorry for the long delay in response, that solution works perfectly.  Thanks again! ... View more

@JakeSkinner  Yes, that is exactly what I was doing.  I will give that a shot, thank you very much for the quick response! ... View more

@RichardJShepherd @PreetiMaske  Sorry to respond to such an old thread, but is there any update on MMPK storing overrun values and the engine's ability to support it?  It would cut down on a tremendous amount of work and make the labeling engine (especially when it comes to street labeling) much more intuitive. ... View more

@ShanaBritt Essentially the goal is to get intersection suggestions as soon as possible.  As soon as they enter the trigger character (/, &, etc), the locator should bring back suggestions.  If I type in Main &, it should give me the first 20 suggestions for an intersection with Main in it. Ultimately, I was able to achieve this by creating a feature layer with all of the intersections in the map data.  I do a custom query on this feature to the LSN values of the intersection.  I then use these values to mimic the Locator suggest behavior. As far as I can tell, there is no way to get a locator to behave this way.   ... View more

Sometimes I really make things out to be harder than they are.  I simply created an intersections layer with all possible intersections, and I'm now querying the LSN values to build the intersection.  While it's going to require some extra work to make this work for each individual end user, I don't see why this couldn't even be scaled to database functionality if the dataset is large enough to warrant it. ... View more

@RobertJensen Thanks for the info.  Is there any resource you can point me to for determining cross streets with preprocessing?  This tool works well, but I don't know how for instance I would determine:   what the cross streets for 101 E MAIN ST are.  I can visually tell it's N Highland St and Washington St, running this tool will likely give me those values for that street segment (E MAIN ST), but there's nothing that directly connects the address point to the centerline. Update:  In this particular case, it appears the last statement is not true, and there is a SEGID element connecting the address point and centerline.  I'm not sure if this is a typical requirement of GIS data like this, but it does solve the issue entirely at least for this case. ... View more

@BruceHarold Is there any updated workflow to this process, anything built into ArcGIS Pro now?  If not, do you have any suggestions on how you would get cross streets for an address point?  The only thing I can think of is doing a query to the centerline to find the street segment that the address point falls into, is there a better way? ... View more

In case anyone happens to be Googling: RuntimeCoreNet.GeneratedWrappers.CoreGeoView.Pulse() or runtimecore.dll!SkBaseDevice::SkBaseDevice What this turned out to be in my case is an OutOfMemoryException that didn't appear as such because it ultimately originates in the RuntimeCore code, through no fault of RuntimeCore.  After removing wasteful layers that weren't doing anything or intended to be displayed in the application from the MMPK and compiling the app to AnyCPU/Prefer 32-Bit (with the intention of removing the Prefer 32-Bit once our installer is handling all platform dependency installers), our app is no longer crashing. Huge thanks to Michael Branscomb‌ for his work in helping track this down. ... View more

Please download repro app here: https://helpdesk.alertts.com/content/Debugging/ArcGISReproApp_100_8_NativeCrash_05172020.7z The archive is password protected, please let me know how best to send the password to the needed person or people. Reproducing the crash is not a science, and can range from easy to impossible depending on the quality of your hardware, but it is very consistent (I've gotten the repro app to crash over 20 times in roughly 2 hours of testing).  The most consistent way I have found is to move the map twice to make it stretch the extent of the window, change the basemap twice (aerial to streets to aerial) zoom in to the area with the MMPK content and vehicles (scale around 1500) and start panning the map.  If I get to the end of the content area (which being in the content area doesn't necessarily seem to matter), I zoom back out and repeat the process.  The magic number seems to be doing that 3 times, sometimes it takes less, very rarely does it take more.  The only absolutely necessary thing is to use the button at the bottom to move the map at least once. Thanks! Kyle ... View more

Thanks Mike.  Tried this with no effect other than making the map slower, process still crashes.  I have even removed all code related to updating GraphicOverlays and can still get the process to crash by panning the map.  Absolutely pulling my hair out on this one, I have aligned the stars in this one application that I am somehow unable to isolate and bring into another (repro) application. Michael Branscomb‌ I now have a basic repro app that I can share.  Essentially with how barebones this thing is, I'm sure it's something I'm doing wrong during the initial load of the map regarding async/await and WPF's Dispatcher behavior, but I cannot for the life of me figure out what it is.  Please let me know the best way to get it to you, I would prefer sharing the repro app privately. ... View more

Michael Branscomb‌ Thanks for getting back to me.  I deleted my last post because it ended up being disproven.  I was able to get the map to a point where it was always loading the dark green tiles in the aerial basemap by resetting the basemap (creating a new instance of the current basemap), but was still able to get the app to crash.  I still can't provide repro code because no matter how much I add to the example app to make it closer to the real production app, it still doesn't behave the same way and crash.  I'm now starting to wonder if this is a dependency conflict, and the thing that sticks out to me is CEFSharp.  Possibly when CEFSharp gets loaded at runtime, it could be loading a different or incompatible version of Skia that ArcGIS is falling back to?  This is where things start to get way out of my expertise, but I've dealt with things that had at least superficial similarity before.  Is this a possibility or am I spouting nonsense? Is there any way to explicitly disable hardware acceleration in runtime?  I can see it happen when I debug the app on my remote workstation via RDP (Information: 0 : Software rendering forced by process), or will ArcGIS use the software rendering of the WPF app if it is set explicitly?  I don't want to go this route, but I'm at the point of desperation. This is what I was describing before... Before moving the map (notice dark green "placeholder" tiles on the left): After moving the map (notice grey/grid "placeholder" tiles on left): ... View more

Michael Branscomb‌ Thanks, I went ahead and updated to the official nuget release and confirmed the crash is still occurring.  Any idea when the 100.8 symbols are planned to be available?  I'm 90% sure this has something to do with the GraphicOverlays I'm using (as just loading the MMPK and base layer in a repro app will not allow this to reproduce), but I can't say what it is if anything I'm doing wrong with the GraphicOverlays/Graphics, and can't say with complete certainty that this is the problem (the app crash doesn't seem to be linked with panning the map to an area where there's a graphic, but I don't know if that even matters). I have a GraphicOverlay with static rendering that generally has 70-100 graphics on it that are getting updated on intervals between 1-30 seconds.  Is it possible this is posing an issue?  When I set the rendermode to dynamic, strange things start happening with labels (they don't move along with the graphic), but I'm about to try it to see if it makes any difference with the crashes. Edit:  Did not make a difference with the crashes and makes the experience way worse (all graphics on a GraphicsOverlay flicker when you update one, label drift as previously mentioned). ... View more