POST
|
I am snapping points to polygon edges, which should be a simple task. However, when I drag the point over the polygon edge, it appears to snap to the edge but then, once released, doesn't actually snap to the edge and shows the centroid outside of the point. Usually but not always, deselecting and then reselecting the point temporarily solves the problem. This is not a problem related to multiple points or layers being selected- only one feature in the entire map was selected when the snapshot was taken. Snapping was set to Point and Edge. [ATTACH=CONFIG]26602[/ATTACH] This only occurs during manual snapping- the snapping tool does not seem to be affected. It doesn't happen every single time, but it happens enough that it is very disruptive. The problem can be circumvented by editing the vertices of a point and moving the vertex to the edge, but with stacks of multiple points snapped together this is not viable. Any assistance or related experience is welcome. Katherine
... View more
08-08-2013
03:31 PM
|
0
|
0
|
1827
|
POST
|
I am new to Python but I have been having an issue with the lines of code in the ArcMap Python window above where I am typing beginning to execute before I have completed everything and pressed enter twice. My understanding is that ctrl-enter is pressed to create a new line, (and lines above should not do anything when this happens) and enter is then pressed twice when I am ready for the whole thing to execute. This problem seems to be happening mainly when I use the up arrow to recall the last code snippet that was typed. Is there a way to turn this off?
... View more
05-20-2013
09:07 AM
|
0
|
1
|
383
|
POST
|
I figured out a solution: my Tiger city field said "061" for NYC and the field I created in my address table said "61" since Arc automatically removed the zero. Apparently when geocoding without zips as many of the other fields as possible must be EXACT matches to produce candidates, and without the city being an exact match I was getting 100% failure. I did a number of tests using a very small sample of data and streets and found that as long as all possible fields (to/from addresses on left and right, city, state, and street name) were filled in when creating the locator, it didn't matter if the zip field was designated, left blank, or filled with a set of false zips. However, when only the required information was filled in (to/from addresses on left and right and street name, I believe- Arc is currently frozen so can't make sure), the geocoding failed because it was unable to make a match just based on street addresses themselves, even within a single city. I didn't test to see if both city and state were needed, but I assume that they are, or at least that city was more necessary than state, since everything failed when my two city fields were not exactly the same. I never designated the zip field in the run options for my table, which worked fine since the other fields were able to make the match. One other problem I had: I was using a table copied out of a shapefile, rather than a straight database, so the FIDs were still included a few times when I imported the table and forgot to delete them. The geocoding wouldn't run unless the name for the FID field was changed slightly. (This was the problem at the time of my March 6 post). Shawn, I don't know if any of the above will help you (maybe designating more fields would help your success rate?), but I have no idea what's going on with your offsets. Mine worked fine, but it's also not something I'm worried about because I have to hand-adjust the points based on historic data. The only records I could find online related to offsetting problems recommended installing SP2, so you might want to make sure you have that.
... View more
03-08-2012
08:00 AM
|
0
|
0
|
590
|
POST
|
I've tried adding a field of nulls, a field of single-digit " "s, and a field of 5-digit dummy zips (for example, 11111) to both the reference file (which does have the correct zips) and the address file to be geocoded, both separately and at the same time. Nothing seems to work- the only difference is that instead of having a 100% failure rate, nothing happens when I tell it to geocode- it just returns a 0% rate for successful, unsuccessful and tied. The geocoding seems to rely on the zip since it returns no suggestions if the zip is wrong even by one digit.
... View more
03-06-2012
12:02 PM
|
0
|
0
|
590
|
POST
|
US Streets is what I would have used in 9.3, but it doesn't seem to exist any longer- do you know the equivalent? The dual is used when the side of the street matters, and I used it since the Tiger lines include that information.
... View more
03-05-2012
12:57 PM
|
0
|
0
|
590
|
POST
|
I'm trying to geocode historical addresses for Manhattan and Brooklyn that do not include zip codes. Based on the instructions in this other thread: http://forums.arcgis.com/threads/13639-Geocode-streets-without-knowing-ZIP , I made a dual range locator (using Tiger 2010 lines, Kings and NY counties merged) and left the zip fields <none>. When running the geocoding process, I left the zip field blank again. None of the addresses match up at all- no errors, just 100% failure. To make sure my addresses were okay, I filled in a few zips and ran again using a similar locator that did include the zip field- those addresses with zips geocoded fine. What do I need to do to get all of my addresses to geocode successfully, without zipcodes? I'm running the trial version of Arc 10 which is supposed to have been updated with all of the service packs. Thanks.
... View more
03-05-2012
08:57 AM
|
0
|
9
|
2749
|
Online Status |
Offline
|
Date Last Visited |
11-11-2020
02:23 AM
|