POST
|
Thanks, Shantonu. I did not understand what you were suggesting. Though I am using Desktop, it's running remote on a server somewhere. I don't have any control or information about the platform or computing resources for the machine upon which the software is running (without asking the administrators). My university has some pretty impressive research computing resources. I would be very surprised if this service as not adequate for very intensive use.
... View more
07-02-2017
07:53 AM
|
0
|
0
|
210
|
POST
|
Thanks for your advice! I'm a little foggy on the architecture, since the program is running on a virtual machine somewhere. However, the files are stored on separate server. I have done these big calculations with files all over the place and never had problems like this. However, I'll try moving them to the "machine" where the program is running and see if that helps. This morning I tried selecting only the first 1000 polygons, and that completed in 20 minutes or so. Extrapolating the results (segments in each polygon) from the first 1000 polygons gives a final result set of "only" ~2.5 million, which should not be a problem for maxing out the file limits, as I understand it. The second 1000 polygons has been running for hours. Makes me wonder if there is a one or more problem polygon in there not detected by repair geometry. I appreciate your help!
... View more
07-02-2017
07:47 AM
|
0
|
1
|
210
|
POST
|
Repeating my reply to another user so you'll see it. I doubt that the polygons are very complex. They are generated with service areas on a mostly sqare street grid. I exported the line features to a new features class and checked the geometry. It was fine. (I had previously run repair on both the segments and the polygons.) I projected the polygons so that shapefile was in the same system as the line segments. As a precaution, I moved both shapefiles into the same file geodatabase. Again the intersect ran a long time--overnight. This time the results had 2048 features, and all the data in the table was blank. Nothing mapped.
... View more
07-02-2017
04:09 AM
|
0
|
0
|
718
|
POST
|
I exported the line features to a new features class and checked the geometry. It was fine. (I had previously run repair on both the segments and the polygons.) I projected the polygons so that shapefile was in the same system as the line segments. As a precaution, I moved both shapefiles into the same file geodatabase. Again the intersect ran a long time--overnight. This time the results had 2048 features, and all the data in the table was blank. Nothing mapped.
... View more
07-02-2017
04:07 AM
|
0
|
5
|
718
|
POST
|
Ah! I think they are not the same! I'll project them into the same system and try that.
... View more
07-01-2017
10:07 AM
|
0
|
0
|
718
|
POST
|
Thanks for your reply. The version is 10.4.1. It's a university install on university machines run by the research computing people, so I assume it's going to be set up correctly and adequately for most normal and even moderately intensive uses. I will try your suggestions and report back. Thanks!
... View more
07-01-2017
09:04 AM
|
1
|
1
|
718
|
POST
|
I have shapefiles with segments (representing roads, but they're just regular polylines, not a network dataset) and polygons (~14,000 polygons generated with service areas). I'm running intersect to get the segments (and their lengths) within each polygon. On the first run, I got errors, and the tool did not complete. I reduced the segments dataset (from lines representing the whole county to just those within the city) and ran "repair geometry," which did find some problems and fixed them. When I ran it again, the analysis took 12+ hours and completed. The table looked normal, but the resulting featureset was suspicious. It had exactly 64,000 segments in it, and only a few tiny segments mapped. The rest did not appear on the map. Repair geometry on the results featureset had no effect. I ran the analysis again from python. Again it took 12+ hours. This time there were exactly 70,000 segments in the results, and none of them mapped. So, I don't have confidence that these are complete results. I ran a similar analysis with the same polygons shapefile and another set of segments from the same road system; this one had many, many more segments, and the analysis completed normally. It took maybe four hours to run on my university's machine. Seems like maybe the analysis is maxing out the computing resources, causing ARCMap to choke and produce bad results. But why could it run the previous, much more complex analysis? Advice?
... View more
07-01-2017
07:12 AM
|
0
|
13
|
1485
|
POST
|
Background: I have an original shapefile with points that map just fine. I want to use these points to map other data (one point to many observations) that can be joined to the points with a field in the .dbf. (The "relate" functionality has not worked for me, and it seems like a ridiculous pain to fight with the software to do something I can do in a relational database in 30 seconds.) I thought instead to compute the X,Y for the points, output the .dbf as a text file, do my manipulations in other software, import the manipulated file, map the points, save as a shapefile, then do my geographic analysis. What I did: Open the attribute table, create fields called X and Y, calculate corresponding geometry (using decimal degrees) using the coordinate system of the data source. Checked to see that the results match the coordinates of the mapped points. They do. Export the attribute table to a text file and when it asks if I want to add the exported table, say "Yes". Right click on table and go to "Display XY data." Note that the PCS and GCS are the same as the data source. Specify field X for X and field Y for Y. Map the data. Problem: The points are in North America and map to near the equator. I'm attaching a graphic showing for one observation the X and Y fields in the data file and the X,Y of the mapped point. They don't match. No transformations are set. The data frame coordinate system and the ones for the attribute table and new table are the same (NAD 1983 UTM Zone 15N). Plainly, I'm doing something wrong, but I don't know what it is. Help?
... View more
10-15-2016
09:59 AM
|
0
|
3
|
2903
|
Title | Kudos | Posted |
---|---|---|
1 | 07-01-2017 09:04 AM |
Online Status |
Offline
|
Date Last Visited |
11-11-2020
02:24 AM
|