Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Cancel
- Home
- :
- About SeanMurphy1
SeanMurphy1
New Contributor II
since
10-10-2014
01-31-2024
9
Posts created
68
Kudos given
0
Solutions
0
Kudos received
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
My Ideas
(0 Idea Submissions)Latest Contributions by SeanMurphy1
|
POST
|
Hello, What field names or aliases do I need to give Locator source data to have the geoprocessing tool automatically match them in the Field Map (address elements) when source data selected and role assigned? I can't seem to find that documentation anywhere. Thanks! -Sean
... View more
09-08-2020
09:07 AM
|
0
|
1
|
1182
|
|
POST
|
I'm dissolving a line feature class with over 400k rows of data based on two fields: 1) Key 2) TLGID. However, when I run the dissolve with single feature activated, some smaller lines disappear altogether. When I change the setting to multi-feature and run the dissolve again, I get shape_lengths of 0 for those same lines that disappeared before. I've attached photos of the before and after the multi-feature dissolve. BEFORE multi-feature dissolve: AFTER multi-feature dissolve: Is there a cluster tolerance that is set by default that deletes segments that don't meet a minimum length? In my case 2.8 meters...
... View more
02-23-2016
06:01 AM
|
0
|
1
|
2192
|
|
POST
|
Since your reference data doesn't have the zone information, you should process the table you are geocoding as Jeff suggests. Remove the zone information from the input table before you geocode. Like Jeff suggested, the split() function might be useful for that. The problem with creating a style file modification to fix problem is that there is nothing to set the zone information to (in the reference data) when creating the address locator. When you run the created locator, it thinks that that info is missing by default (since that's what you set in reference data), even if the zone information is in the address you're trying to geocode. In other words, the locator thinks that the house number, street, city, state is all part of the house number, street. It sounds like getting street data with zone info is most ideal... Sorry I couldn't be more help.
... View more
02-24-2015
01:06 PM
|
0
|
5
|
1142
|
|
POST
|
From what I understand of your problem, here's what you want to do: 1. Copy and paste the style file under C:\Program Files (x86)\ArcGIS\Desktop10.2\Locators" so that you can customize. 2. Open the new style file in Notepad or another text editor. 3. Change the <name> of the style so you can distinguish when creating address locator. 4. Find (ctrl+f) "Top Level Elements". 5. In the Top Level Elements section, scroll down to "FullNormalAddress" definition. 6. Change the weight of "NormalAddress" to "100" and "Zone" to "0". 7. Repeat step 6 for "FullIntersection" if desired. 8. Save and close. Open ArcMap and create new address locator. 9. Select your customized style file. Make sure the city, state, and zip code fields have street data associated with them. The address locator should return results with a matched city, state, and zip code, even if the geocoded address entry does not have those elements. Essentially, you gave the zone elements less say/weight in finding the location, but the zone elements are still returned in the results. Hope this helps.
... View more
02-24-2015
07:39 AM
|
0
|
9
|
1142
|
|
POST
|
I have an address locator that is suppose to return place name locations. The place names the locator is based on has numbers in the name, for example, "7102-2" is a place name. Instead of returning the place name location as the match result, longitude and latitude values are returned. Using the same example, "Found: Longitude: 7102.000000; Latitude: -2.000000". Is there a setting that can ignore the "coordinate" match type? Or another setting to fix this problem? Thanks!
... View more
02-18-2015
11:43 AM
|
0
|
1
|
14009
|