Latest Contributions by BryanLynn1

I agree!! The other day while waiting or Pro to open I checked my email and waited, and waited, and waited for Pro to open. Finally I realized the "Sign In" dialog was on a second screen underneath my Outlook window. I will move the Pro window back and forth between screens depending on what I am working on (I tend to keep my primary task on the right screen...) and the dialogs always popping up on a different screens is annoying. And I agree with @ZachMoore, it isn't a bad idea, but it should be customizable. ... View more

Yeah, I have had a long discussion with support about this issue. True, a StreetAddress role will return a location but it's really not useful when it is a 1000 feet from the actual address location. Our street segments have theoretical address ranges not actual ranges. So, the range may be 4000-4099 but the real range only goes to 4024. This causes the StreetAddress point to be misplaced along the street segment. We have been using the FindAddressCandidates method (from 10.3 locators) to help users find ACTUAL address point - for years. We would take the returned address candidates and sort the results based on score and proximity to the entered house number (i.e. user enters 4231 [which doesn't exist] we would sort the results of actual address points as follows 4232,4229, 4231, 4228.....) This also allowed us to provide the user with additional info from the actual address points (parcel id, owner name, etc.) so they could select the correct address. We could also search/sort the results for other street names (user enters Broadway - we would show them the actual street names Old Broadway, N Broadway, & S Broadway). The new methodology breaks our existing apps, but we will adjust. Suggestions, which we have never used because they were kind of squirrely - ghost addresses and such, will help, but that too requires changes to the applications. We have discussed the new locators at length in the office and really find the changes....just strange. We were simply updating some processes that rebuild the locators every night and thought we would go ahead and move to the new Pro locators when we discovered the issue. Support has made it clear that it works as designed and that we should move to the new model. And we will, just not very quickly. Thanks for replying. ... View more

For everyone's info, I reported the issue to support back in Nov. 2022 and they have listed it as a bug. Here is the info: Bug number: BUG-000153603 Synopsis:  ArcGIS Pro Locate pane returns a value with 1 space although the Value in the Reference Data from the custom locator with 2 spaces Status: New ... View more

Thanks for the suggestions Shana. Unfortunately, both the POI role and the Feature Locator did the same thing and stripped out one of the spaces. I will open a support ticket. I am using ArcGIS Pro 3.0.2 ... View more

We have parcel ids that have 2 spaces in the the middle of the id. For instance 001  001. The locators are trimming the multiple spaces to a single space and causing problems downstream. Since we can't modify the locator rules to account for this situation, how do we handle it? Or is there a locator style that already has support for multiple blank spaces? ... View more

I was experiencing the same issue - ArcGIS Pro 3.0.1. However, after much fussing and cussing, I cleared my graphics cache and the problem cleared up. Not sure this is the answer but I thought it might help someone else.   ... View more

I agree with Dan, I would expect the more you type the fewer candidates you see. I don't know who Dan works for but he seems to be in the same situation that we are. We really only need to search addresses across a few counties. 90% of the time we are only looking in one county and don't even use city, state, and zip values. We do have some situations where we need to find addresses across a utility district that may cover portions of several counties but I still don't see that as a problem. The existing tool handles addresses across the entire world, so addresses with subunits across 8 counties shouldn't be a big deal. No, I don't expect to scroll through 1000s of subunit addresses. I think this is a bad idea from both a performance and UI standpoint. We do have some locations with lots of subunits but most of the time it is a fairly short list. I had not considered the "100 Main St, My City, My State, Zip (150 units)" idea but it is a thought. And if I could click it and see the 150 units that would be handy. However, if you have to click it to simply see 2, 3, or 10 units it becomes more cumbersome than useful. I know this video doesn't come from an address locator but it does show some examples of subunits in our data set. Well, the video upload service isn't working right now so I will just include a link to the video: https://www.kgis.org/portal/portals/0/videos/misc/addresssubunits.mp4  Thanks for looking into this and I feel sure you guys will come up with something that works. Bryan ... View more

Dan McCoy is spot on in his reply. But another situation we currently have is some locations only have subunit addresses. The addressing folks are looking at changing this in the future but for now it is allowed and it exists. The Clinch address is a good example. If you look at the screen shot a few items back you will see that 2020 Clinch Ave only has unit addresses. So if the units don't show up in the suggestions then the user would never know it was a valid address. ... View more

No. Our need/use of ArcGIS Pro has really dropped at this point (we are sticking with ArcMap for the short term) so it isn’t a huge deal right now but we need the ability to search for unit level addresses. Thanks for checking back, Bryan ... View more

Here is a quick video to show the performance I am seeing in Pro vs ArcMap. ... View more

I have been using the Geodatabase class to access a feature class and get info. However, the performance is horrible!! I was hoping to use the Oracle.ManageDataAccess control to go straight against the database views and hopefully get better performance (this is what I have done in my ArcMap Add-Ins and the performance is great). I will look at the Database class but I assume it will be the same on a performance level. When I say bad performance here is an example. I am looking up a subdivision by object id. In ArcMap it takes less than a second to locate and highlight the subdivision in the map - basically I click the OK button and it shows up. In Pro, it takes close to 3 seconds to highlight the subdivision in the map. It isn't just the subdivision feature class either, I have seen this same type of performance with other feature classes. I am currently drawing nothing in the map - just highlight the subdivision. In this example, I am not using the Oracle.ManagedDataAccess class I am using the Geodatabase class in Pro SDK or ArcObjects for ArcMap. I am experiencing the same slowness with other simple database type queries where I only want attribute info which is why I wanted to try the Oracle data provider. My preference is to stick with ArcGIS Pro SDK objects and controls. Is this behavior typical? If so, I will move on, finish the code, and live with the poor performance. If not, I would like to build it right the first time. Thanks. ... View more