Timeline for Script and model crashes after first iteration
Current License: CC BY-SA 3.0
15 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Feb 3, 2015 at 22:47 | answer | added | Mark Bryant | timeline score: 1 | |
| Feb 2, 2015 at 16:09 | comment | added | D_C | I have attempted repair geometry to no avail. The 'objectid' is maximum 3 characters in length, so no possibility of hitting the 13 character mark. The layers that it crashes on run fine when I do them manually. This process worked fine in modelbuilder 10-15 times before, then something changed to make it crash on the second iteration to which I have no clue; this is why I went to python but it hasn't fixed it. I am researching the .bat idea now. | |
| Feb 1, 2015 at 23:43 | comment | added | Michael Stimson | It says INVALID TOPOLOGY, Coverages are NOT tolerant for topology errors. Use Repair Geometry to clean up the data before you try to convert to a coverage. Also be aware that there is a restriction in coverage names of 13 characters so I would reccomend using "A" + objectid instead of "AVICV_" + objectid for the name. | |
| Feb 1, 2015 at 21:38 | comment | added | FelixIP | Ooops. Disregard one above. It refers to other tool | |
| Feb 1, 2015 at 21:31 | comment | added | FelixIP | Naming of in_features in error line seems strange. It is something like "AVI_OBJECTNAME.shp POLYGON". Is this a legal thing at all? | |
| Feb 1, 2015 at 16:24 | comment | added | D_C | I was thinking in the line of segmentation somehow, but am still new to pyhton. Never used .bat before, so will have to look into it. Any good resources you can think of? I tried on the 46gb RAM virtual machine to the same error. | |
| Feb 1, 2015 at 7:17 | comment | added | PolyGeo♦ | You could try splitting your script out into one script per iteration and then writing them into a *.bat so that it becomes a series of standalone runs. | |
| Feb 1, 2015 at 4:05 | comment | added | D_C | I have also just noticed that the coverage created in python in the first iteration is bigger (more records) than the one that it crashes on ( as checked through the stand alone run). So the memory hang is more and more likely. | |
| Feb 1, 2015 at 4:05 | comment | added | PolyGeo♦ | You may need to consider the approach that I suggested on another ERROR 999999 at gis.stackexchange.com/a/92421 - it is certainly what I would have pursued if that error became a showstopper for me. | |
| Feb 1, 2015 at 4:02 | comment | added | D_C | I've got 16GB and 64 bit. I have access to a virtual machine on our network with 48GB and 64 bit but the modelbuilder version of this process crashed on it too. | |
| Feb 1, 2015 at 3:56 | comment | added | PolyGeo♦ |
Some people have suggested using Python's subprocess (e.g. geonet.esri.com/thread/49275) and I started to investigate that once a few years ago but I think I found that upping the RAM solved my issues and so I abandoned that effort.
|
|
| Feb 1, 2015 at 3:49 | comment | added | D_C | I can do that for sure with the image. As for your comment, I think something like that is happening; as if after the first iteration, the memory is held onto. Is there a way to dump everything after the iteration? | |
| Feb 1, 2015 at 3:47 | comment | added | PolyGeo♦ | For that error message my first thought is always a lack of memory - see gis.stackexchange.com/a/90531 - also, it is far better to include error messages as text rather than pictures so that they can be searched for. It looks like you have run it at the DOS prompt which may make that hard to copy/paste so I would try running it from IDLE instead. | |
| Feb 1, 2015 at 3:45 | history | edited | PolyGeo♦ |
edited tags; edited tags
|
|
| Feb 1, 2015 at 3:38 | history | asked | D_C | CC BY-SA 3.0 |