Poważny błąd w statystykach strefowych ArcGIS?

25

Aktualizacja: Błąd został naprawiony w wersji ArcGIS 10.4

Korzystam z ArcGIS 10.2.2, aby określić statystyki strefowe dla wielu stref. Jeśli w rastrze wartości jest jakakolwiek NoData, chcę, aby wyniki strefy były „NoData”, dokładnie tak, jak podano w opisie narzędzi. Ten opis narzędzia stwierdza:

DANE - W obrębie dowolnej strefy tylko komórki, które mają wartość w wartości wejściowej rastra wartości, zostaną użyte do określenia wartości wyjściowej dla tej strefy. Komórki NoData w rastrze wartości zostaną zignorowane w obliczeniach statystycznych.

NODATA - W obrębie dowolnej strefy, jeśli w rastrze wartości istnieją komórki NoData, uznaje się, że nie ma wystarczających informacji do wykonania obliczeń statystycznych dla wszystkich komórek w tej strefie; dlatego cała strefa otrzyma wartość NoData na wyjściowym rastrze.

Proszę spojrzeć na moją konfigurację na tym obrazku: wprowadź opis zdjęcia tutaj

Używam opcji NODATA z rastrem wartości, który ma jeden piksel NoData, i dlatego oczekuję, że wynikowa wartość strefy (strefa 61154) będzie mieć wartość „NoData”. Zamiast tego otrzymuję wartość 12,74 (zaokrągloną do 13 na obrazie), co dezorientuje mnie na dwóch poziomach: po pierwsze oczekiwałem „NoData”, a po drugie, wynikowa wartość 12,74 jest matematycznie niemożliwa, ponieważ średnia nie może być większa niż maksymalna wartość w rastrze wartości, która w tym przypadku wynosi 10.

Jeśli korzystam z opcji DANE, otrzymuję wartość około 9,1, co ma sens. Przetestowaliśmy to na różnych zestawach danych, komputerach i wersjach ArcGIS.

Czego tu brakuje?

Edytuj / Komentarz dodatkowy: Właśnie zauważyłem, że atrybut „Liczba” jest również nieprawidłowy dla tej konkretnej strefy. Rzeczywiście w tej strefie jest 421 komórek, ale narzędzie liczyło tylko 297. Obliczenie 421 minus 297 daje 124 - co dziwne, jest to „pozycja”, w której znajduje się piksel NoData, jeśli policzy się piksele od lewej górnej do dolnej bezpośrednio w strefie. Narzędzie może źle zliczać liczbę komórek (zbyt nisko), co może wyjaśniać wzrost średniej.

Edycja: Oto link do danych, których używam.

Edycja: Dan Patterson i ja przeprowadziliśmy dalsze debugowanie tutaj na forum ESRI.

G-Wizard
źródło
1
Tak, produkuje coś szalonego. W moim przypadku MEAN = 537 dla rastra w zakresie (16,8). Nie śmieszne
FelixIP
Jaka wartość służy do reprezentowania NoData w tym rastrze?
Jezibelle,
@Jezibelle: Dobre pytanie, gdzie znajdę wiarygodną odpowiedź? Jeśli eksportuję jako Ascii, jest to -9999. Jeśli użyję funkcji eksportu z menu kontekstowego, pole „NoData as:” - pole dialogu eksportu zostanie wstępnie wypełnione 2147483647. Czy to podnosi flagę?
G-wizard
Pojawiłby
1
Na końcu mojego wpisu dokonałem kolejnej edycji, gdzie zamieszczam link do podobnego postu na forum ESRI. Błąd potwierdzony (z niespodzianką). Obliczanie „MEAN” daje tylko inne / gorsze wyniki niż obliczanie statystyk „ALL”.
G-Wizard

Odpowiedzi:

9

Występuje błąd, który wydaje się odpowiadać temu, co napotykasz - jest zarejestrowany jako BUG-000084883 - Opcja „Ignoruj ​​brak danych w obliczeniach” w statystykach strefowych jako narzędzie tabeli {i narzędzie statystyk strefowych} nie jest honorowana po sprawdzeniu, co powoduje nieprawidłowe wyniki.

Występuje z 10.3 i 10.2.2, ale nie 10.1. Czy wypróbowałeś narzędzie w tej wersji?

GISGe
źródło
To brzmi jak dobre podejście, chociaż osobiście nie wiem, jak uruchomić starsze wersje tego narzędzia. Czy ktoś wie, gdzie skierować mnie, abym spróbował wykonać tę pracę?
UdderlyAstray,
Dzięki @GISGe. Gdzie to znalazłeś? Czy istnieje link, w którym udokumentowano ten błąd?
G-Wizard
1
@ G-wizard - dodałem link do mojej odpowiedzi. Jako międzynarodowy personel Esri mam dostęp do bardziej szczegółowego opisu niż to, co możesz zobaczyć, dlatego mogę ci powiedzieć, że błąd dotyczy również narzędzia statystyk strefowych i nie został znaleziony w 10.1.
GISGe,
@UdderlyAstray - jeśli chcesz uruchomić starszą wersję narzędzia, musisz zainstalować starszą wersję ArcGIS.
GISGe,
1
Jeszcze raz dziękuję, @GISGe, ponieważ tego właśnie szukam (błąd oficjalnie potwierdzony), zaznaczam tę odpowiedź jako poprawną, chociaż inni również to potwierdzili, wykonując testy.
G-Wizard
9

To jest błąd. Coś strasznie nie tak z liczbą komórek.

Prawidłowa średnia (9,0452380952381) razy poprawna liczba niepustych komórek (420) podzielona przez 297 (liczba komórek podana przez narzędzie ) daje 12,7912457912458. To błędna średnia zgłoszona przez narzędzie.

Wyniki mojego testu siatki rozmiarów zabawek:

wprowadź opis zdjęcia tutaj

FelixIP
źródło
1
Potwierdzam, że mam ten sam problem z 10.3, NODATA i „MEAN”
radouxju
Dziękuję obu za potwierdzenie tego. Ale pomijając różnice w wartości średniej, czy mylę się, zakładając, że wynikiem nie powinna być żadna wartość, ale „NODATA”? Opis narzędzia pozwala mi w to uwierzyć. Mówi: „NODATA - W obrębie dowolnej strefy, jeśli w rastrze wartości istnieją komórki NoData, uznaje się, że nie ma wystarczających informacji do wykonania obliczeń statystycznych dla wszystkich komórek w tej strefie; dlatego cała strefa otrzyma wartość NoData na rastrze wyjściowym. ” Ponieważ z „NODATA” jest jeden piksel, statystyki strefowe powinny również oznaczać „NODATA”. Prawidłowo?
G-wizard
2
@ G-wizard, masz rację, jak podano w Opisie narzędzia. nieco analogiczny do # DIV / 0! w programie Excel.
c0ba1t
1

Podobnie do innej odpowiedzi , przenieś dane rastrowe do tablic zamaskowanych NumPy, aby obliczyć statystyki. Zakładając dwa nakładające się rastry o tym samym kształcie, jest to proste:

import numpy as np
zones = arcpy.RasterToNumPyArray("zones")
value = np.ma.masked_equal(arcpy.RasterToNumPyArray("value"),
                           arcpy.Raster("value").noDataValue)
print("Zone\tCount\tNoData\tMean")
for z in np.unique(zones):
    sel = (zones == z)
    print z, sel.sum(), value.mask[sel].sum(), value[sel].mean()

Przedstawia:

Zone    Count   NoData  Mean
61131   53   0   8.92452830189
61154   421   1   9.04523809524
61207   1   0   8.0
61317   35   0   7.2
61644   644   0   7.90838509317
61677   12   0   7.41666666667
61789   7   0   9.0
61871   193   0   7.98445595855
187472   349   0   8.5787965616
Mike T.
źródło