Ungewöhnliche Ergebnisse für Geoverarbeitungsgeschwindigkeitstests

Ich habe eine ungewöhnliche Leistung mit einem Python-Geoverarbeitungsskript beobachtet. Das (angehängte) Skript führt die folgenden Aktionen aus:

Verwenden Sie einen Suchcursor, um die UTM-Zone nach Polygon-Features zu suchen
Erstellen Sie ein räumliches Referenzobjekt basierend auf den Ergebnissen des Suchcursors
Konvertieren Sie .csv in einen Feature-Layer und dann in eine Punkt-Feature-Class

Ich habe deutlich unterschiedliche Verarbeitungszeiten festgestellt, je nachdem, wie das Skript ausgeführt wird:

32-Bit- Verarbeitung mit IDLE = 203 Sekunden
Vordergrund- Skript-Tool für die 32-Bit- Verarbeitung = 91 Sekunden
Hintergrundskript- Tool für die 64-Bit- Verarbeitung = 206 Sekunden

Warum sollte dieses Skript unter den oben genannten Bedingungen so unterschiedlich funktionieren? Ich würde sicherlich nicht erwarten, dass das im Vordergrund ausgeführte 32-Bit-Skript-Tool 2X so schnell ist wie die anderen Methoden.

import arcpy, os, time

###IDLE Parameters
##fc = r'C:\path\to\polygon\fc\with\utm\zones\and\features'
##outws = r'C:\out\location'
##arcpy.env.workspace = r'C:\workspace'

####################
## Script tool parameters
fc = arcpy.GetParameterAsText(0)    # Feature class
outws = arcpy.GetParameterAsText(1) # Folder
arcpy.env.workspace = arcpy.GetParameterAsText(2)   # Workspace
####################

# Tables are .csv
tables = arcpy.ListTables()

start = time.clock()

# Look up which UTM zone .csv features are in
for t in tables:
    quad = t[7:17]
    print quad
    whereClause = """ "QUADID" LIKE '%s' """ % quad
    with arcpy.da.SearchCursor(fc, ("QUADID","ZONE"), whereClause) as cursor:
        for row in cursor:
            if row[0] == quad:
                utmZone = row[1]
                if utmZone == 10:
                    sr = arcpy.SpatialReference(26910)  # NAD_1983_UTM_Zone_10N
                elif utmZone == 11:
                    sr = arcpy.SpatialReference(26911)  # NAD_1983_UTM_Zone_11N
                elif utmZone == 12:
                    sr = arcpy.SpatialReference(26912)  # NAD_1983_UTM_Zone_12N
                elif utmZone == 13:
                    sr = arcpy.SpatialReference(26913)   # NAD_1983_UTM_Zone_13N
                else:
                    print "The UTM Zone is outside 10-13"
            else:
                pass

    # Convert .csv to feature class
    try:
        outLayer = "in_memory"
        # Now with the sr defined, create the XY Event Layer
        arcpy.MakeXYEventLayer_management(t, "x", "y", outLayer, sr, "z")
        arcpy.FeatureClassToFeatureClass_conversion(outLayer, outws, t[7:17])
        arcpy.Delete_management("in_memory")
        end = time.clock()
        print "In_memory method finished in %s seconds" % (end - start)

    except:
        # Print any error messages
        print arcpy.GetMessages(2)

print "Processing complete"

— Aaron
quelle

Wie lange dauert es, arcpy alleine zu importieren? Gibt es einen Formatierungsfehler in der Post. Sollte der Versuch: innerhalb der for-Schleife sein?

— Nathan W

Ich denke, @ NathanWs Punkt import arcpyist es wert, zuerst in Betracht gezogen zu werden, da es den Anschein hat, dass nur die IDLE- und 64-Bit-Routen Ihrer drei Tests Zeit benötigen, aber das Hinzufügen von fast zwei Minuten scheint übertrieben. Versuchen Sie, ein Tool auszuführen, das nur den Import von ArcPy zeitlich übernimmt.

— PolyGeo

Ich würde ziemlich sicher sagen, dass es die import arcpyLinie ist. Als ich das letzte Mal arcpy verwendet habe, war der Import von außen langsam. ArcGIS hätte das bereits in seinem internen Python importiert, sodass der Import bereits zwischengespeichert ist.

— Nathan W

@ Nathan und andere sind absolut korrekt. Das Ausführen eines Prozesses über IDLE oder die Befehlszeile wird ausgeführt, wenn Sie "arcpy importieren" aufrufen. Sie können jedoch einen Kompromiss für sehr große Prozesse erzielen, bei denen Sie durch eine verbesserte Leistung die Zeit zurückbekommen. Das Ausführen eines Hintergrundprozesses hat auch einen Zeitverlust, da ArcGIS effektiv eine weitere ArcMap-Sitzung startet. Schließlich haben Sie noch andere Variablen, die Sie in Ihrem Test eliminieren müssen, z. B. welche Unterschiede in der Hardware zwischen Ihren 32- und 64-Bit-Computern bestehen und welche anderen Prozesse während Ihres Tests Ressourcen verbraucht haben usw.?

— MappaGnosis

+1 @JayLaura. Könnte weiter gehen und Profil. [ General python doc] [ docs.python.org/2/library/profile.html] und [ stackexchange posting] [ stackoverflow.com/questions/582336/… .

— Roland

@ Aaron: Reposting meinen früheren Kommentar als Antwort basierend auf seinem Rat:

Könnte weiter gehen und Profil. [Allgemeines Python-Dokument] und [Stackexchange-Posting] .

Auf jeden Fall daran interessiert zu hören, was er findet.

— Roland
quelle

Ich habe eine Theorie.

Ich denke, das Problem könnte die Validierung Ihrer Ausgabe oder Ihrer Eingabe sein. Bevor ein GP-Tool ausgeführt wird, überprüft arcpy Parameter, z. B. ob die Ausgabe-Feature-Class bereits vorhanden ist.

In ArcMap werden alle Inhalte des Arbeitsbereichs (Ordners) zwischengespeichert, und die Überprüfung kann anhand der "Ansicht" des Katalogs des Arbeitsbereichs - im Speicher - schnell durchgeführt werden. Dies kann zu Verwirrung führen, wenn Datasets mit einem Nicht-ArcGIS-Tool hinzugefügt werden. Dazu muss arcpy.RefreshCatalog () ausgeführt werden, um die Katalogansicht mit dem Status des Arbeitsbereichs (Ordners) zu synchronisieren.

Wenn Ihr Ordner sehr groß ist und Sie außerhalb von ArcGIS ausgeführt werden, muss arcpy möglicherweise jedes Mal eine Ordnerliste erstellen, um Ihre FeatureClassToFeatureClass-Ausgabe zu überprüfen. Wenn sich viele Elemente im Ordner befinden, kann dies sehr langsam werden.

— Curtis Price
quelle