POST
|
Joe, This is not currently supported for arcpy. We have an issue in our backlog to get it added in an upcoming release. Brad
... View more
2 weeks ago
|
1
|
2
|
170
|
POST
|
Joe, The ability to edit the side offset and end offset was added at Pro 2.7. Brad
... View more
2 weeks ago
|
1
|
0
|
198
|
POST
|
Joe, At this point in time the Locate Pane will always return all of the output fields when choosing "Show Details". Another option is the "Detailed View" by selecting the burger menu on the top right but when it is enabled it will also show all of the fields. It is a good requirement for a future enhancement to only show the enabled fields in the locator when in "Detailed View". I think we would continue to show everything in the "Show details" dialog though. I will add something to the backlog for the "Detailed View" though. Brad
... View more
12-18-2020
02:30 PM
|
1
|
0
|
161
|
POST
|
Joe, If you use updateLocator () after modifying the locator settings in Python, the properties get persisted into the locator for future use. If you don't call the updateLocator () method, the properties will only be applied for that session of geocoding in Python. Doc all the way at the bottom of this page: https://pro.arcgis.com/en/pro-app/arcpy/geocoding/locator-class.htm#M2_GUID-B617A31C-2B5E-427F-BBEB-B52C1667CC51 Brad
... View more
12-04-2020
09:42 AM
|
1
|
0
|
488
|
POST
|
Joe, You need to call arcpy.SignInToPortal(“https://machinename.domainname.com/portal”, “username”, “password”) and then using services as data sources should work just fine for CreateLocator using Python. The data sources need to be on the server federated with the Portal you are signing into. If your data sources are shared with everyone (public) you don’t need to call SignInToPortal() first. Brad
... View more
12-01-2020
01:15 PM
|
1
|
0
|
357
|
POST
|
Stephanie, Sorry, I have been super busy. What issue are you having when using multiple alternate city names? Each alternate city name for a specific city (ex North Redlands, South Redlands) should have the same JoinID (ex 12345) in the alternate city names table. If you primary reference data (the one with geometry) already has a city name (ex Redlands), this will be the primary city name. All streets in the data that are in Redlands should have a city JoinID (ex. 12345). This allows you to link in multiple alternate city names for Redlands. If you use a fully normalized dataset where city isn't in the primary reference data, then the primary city name can be in the alternate city name table but with an extra field that indicates which city is the primary (determined by the "Primary Name Indicator" field in the alternate name table field mapping). Hope this helps but let me know if you have any additional questions or issues. Brad
... View more
10-27-2020
01:05 PM
|
0
|
0
|
439
|
POST
|
Stephanie, Yes, that is correct. Instead of having a bunch of duplicated IDs for streets, you can use the same ID for each street in that city. Brad
... View more
10-05-2020
11:26 AM
|
0
|
3
|
439
|
POST
|
Stephanie, See the following doc topic all the way at the bottom. Fundamentals of alternate name tables—ArcGIS Pro | Documentation The image at the bottom shows a fully normalized reference dataset where all cities are in the alternate city name table but the logic still applies. You can keep the city in the primary featureClass but have all alternate city names for the primary city in the alternate city name table with the same CityID value. You also wouldn't need a "Primary Name Indicator" fields either because the value from the primary featureClass is used as the primary. At a basic level it would look something like this (obviously the Primary table would have many more fields). Primary reference data: City | City JoinID My City | 1 My City 2 | 2 Alt Name Table: Alt City | Alt City JoinID My City Alt1 | 1 My City Alt2 | 1 My City Alt3 | 1 My City 2 Alt1 | 2 My City 2 Alt2 | 2 My City 2 Alt3 | 2
... View more
10-05-2020
10:07 AM
|
0
|
5
|
439
|
POST
|
Stephanie, As for the duplicate results and different scores, yes it is because there is no postal code for the PointAddress record so it is returned with a lower score. The best way to fix this is to have both datasets have the same fields. That would be by either enhancing the PointAddress dataset to include the postal code with the data (this can be done by overlaying postal polygons to apply postal codes to different points that fall within the postal polygons). Another option is to not map the postal code for the StreetAddress locator when building it. This is not ideal but would give back better ordering of the results because the scores would be the same. I would stick to option 1 if that is possible. As for the joining of alternate city names, it is better to associate an ID with all cities with the same alternate city name and then the alternate city name table would have a single record for that alternate city name and would get linked with all of the records that had that ID. This is more optimal and will make the locator smaller and faster. Brad
... View more
10-02-2020
04:32 PM
|
0
|
7
|
737
|
POST
|
Joe, Are you saying that in the case where a base address does not exist in the Point Address dataset it is better to fall back to a Street Address location instead of an arbitrary unit associated with the address? If so, I would say that even better than that would be if there was a process to ensure that every complex has a base address point location without any unit as well. It could just be the centroid of the complex but it would be better than an interpolated Street Address location in my opinion. If I have misinterpreted you comments, I might need some further clarification of what you are trying to describe. Brad
... View more
08-11-2020
01:01 PM
|
0
|
1
|
498
|
Online Status |
Offline
|
Date Last Visited |
2 weeks ago
|