Timeline for Is there a faster way to add a field based on zonal statistics to an attribute table?
Current License: CC BY-SA 3.0
7 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Feb 16, 2017 at 21:01 | vote | accept | K. Credo | ||
| Feb 16, 2017 at 7:35 | comment | added | PolyGeo♦ | @FelixIP Sometime I should test what I would call fundamental field calculations (field = 3, field1 = field2) on attribute table rather than joined fields. I'm not sure but I think they would stay in C and away from the Python Parser. | |
| Feb 16, 2017 at 7:13 | comment | added | FelixIP | Also gis.stackexchange.com/questions/177923/… | |
| Feb 16, 2017 at 7:04 | comment | added | FelixIP | @PolyGeo according to gis.stackexchange.com/questions/198163/… calculator twice slower. 200k were used. At 1000k the difference even greater. I cannot find my own answer, where surprise surprise arcview 3 beat them all | |
| Feb 16, 2017 at 5:14 | comment | added | PolyGeo♦ | @FelixIP have we ever performance tested to validate your statement that "da cursor is fundamentally faster than field calculator"? I would have expected the opposite, but with there not being a huge difference, unlike between old and new style cursors. | |
| Feb 16, 2017 at 5:04 | comment | added | FelixIP | +1 nice. I'd shorten statistics table name, just in case. And da cursor is fundamentally faster than field calculator | |
| Feb 16, 2017 at 4:50 | history | answered | Michael Stimson | CC BY-SA 3.0 |