POST
|
Thanks, Dan and Neil. Neil's reply helped me the quickest, but I definitely need to learn more about those overlay tools. As it turns out, the real issue was duplication in several "block-group" polygons that I got, I think, from the Census Bureau. After describing the issue and Neil's reply to a friend, she taught me to use the "Find Duplicates" and "Remove Duplicates" tools. Those helped me clean up the duplicates and now all is intersecting as would be expected. I still wonder how I got the duplicates got into the "block-group" polygon layer. Thanks again for your quick responses and help. Herb Kuehne, Sioux City, IA
... View more
03-23-2016
04:52 PM
|
1
|
0
|
1514
|
POST
|
Thanks, Dan and Neil. Neil's reply helped me the quickest, but I definitely need to learn more about those overlay tools. As it turns out, the real issue was duplication in several "block-group" polygons that I got, I think, from the Census Bureau. After describing the issue and Neil's reply to a friend, she taught me to use the "Find Duplicates" and "Remove Duplicates" tools. Those helped me clean up the duplicates and now all is intersecting as would be expected. I still wonder how I got the duplicates got into the "block-group" polygon layer. Thanks again for your quick responses and help. Herb Kuehne, Sioux City, IA
... View more
03-23-2016
04:52 PM
|
0
|
0
|
1514
|
POST
|
I am using the Intersect geoprocessing tool on a small sample of individuals with lon/lat coordinates. I'm intersecting them with blockgroups. When I do so, a number of records are duplicated, so that the original list of entries now is larger by a small fraction....2%. But it shouldn't be larger at all, or at least, so it seems to me. What am I doing wrong or what should I do in order to correct the duplication process?
... View more
03-21-2016
05:51 PM
|
0
|
4
|
4242
|
POST
|
Thanks for the thoughts, Chris. You've listed many of the key issues, and for the most part, I've taken those into account. The key bugaboo, however, has been my inability (now resolved) to transform the Geo.Id2 data listed in the ACS files into a text-formatted number. For some reason, ACS seems to treat Geo.Id2 as a number to be reported in scientific notation. FIPs numbers are not, in my mind, real numbers. They cannot, should not, be manipulated arithmetically. I attempted over and over again to copy/paste those Geo.Id2 numbers into an Excel text-formatted column. But those attempts never resulted in a field that ArcMap would allow to join to my block-group files. utz I did everything that ACS said I should in one of their publications, but even their example process did not work. I finally stumbled upon a special process for pasting the Geo.Id2 numbers in a way that they stayed as numbers-in-text. And now the joins take. I'm not a klutz with Excel, but this one did confound me. I still don't know why the Census B. puts that Geo.Id2 in scientific notation, and I hope to find out (by complaining a bit). Thanks again for the reply. If you know of any published ways to convert Geo.Id2 numbers into numbers-in-text, do tell. Thanks again. Herb
... View more
12-13-2015
02:42 PM
|
0
|
0
|
455
|
POST
|
I used to have no trouble joining ACS files to shapefiles such as county tracts or block groups. Recently, I find that I cannot. ACS files come with "GEO.id" fields that are numeric and do not join to shapefiles whose GEO.id fields are all text. I have tried numerous ways in Excel to turn the ACS numerical location fields to text, but when I load those files into ArcMap, ArcMap turns them all back into numerical fields. HELP. Vary frustrated that I can't figure out how join anymore. And frankly, the Census Bureau pdf describes the process, but the process no longer works. What's changed? Me? They? Any and all recommenations will be welcome.
... View more
12-12-2015
09:24 AM
|
0
|
2
|
2977
|
POST
|
Thanks, Mody. Actually, the "split lines at vertices" tool did automatically split the length of segments, but I didn't catch that. I was only looking at the "miles" field in the street file. As you probably realize, our "miles" field was a calculated field. I simply went back to the street file and recalculated the "miles" field....and now all is well. Thanks for the reply. Herb Kuehne
... View more
10-21-2015
07:15 AM
|
0
|
0
|
829
|
POST
|
Thanks, Richard. We're now aware of everything in your response, except that we haven't used Attribute Assistant nor have we worked the typology properly. Will be taking your suggestions to heart. Thanks again.
... View more
10-19-2015
02:38 PM
|
0
|
0
|
829
|
POST
|
Thanks Richard, and also Kyle Balke and Dan Patterson. I didn't think to look for shape length. That is the issue, and you are right in point me to it. I was focused only on the "miles" field. The Split Line at Vertex DID divy up the shape length appropriately. Just checked a couple. From here on out it's easy. Thanks a bunch.
... View more
10-19-2015
06:34 AM
|
0
|
0
|
829
|
POST
|
I am working with Network Analyst, but my road dataset needs to be fixed so that NA can find shortest routes.. Some roads have been drawn to skip right over vertices where intersections are present. NA would find better routes, if all intersections were really available. I have used the "split line at vertex" tool, and it does a marvelous job of splitting up the roads. But it does not divide the distances among the various splits. The same mileage numbers, for example, simply transfer over to all splits made on a given line. I want NA to be able to report on the lengths of the routes What's the better way to split the roads at intersections and have the software calculate new, correct distances (lengths)?
... View more
10-18-2015
05:40 PM
|
0
|
7
|
3206
|