gbif / portal-feedback

User feedback for the GBIF API, website and published data. You can ask questions here. 🗨❓
30 stars 16 forks source link

Insect is from Kansas which is USA not China #5408

Open gbif-portal opened 3 months ago

gbif-portal commented 3 months ago

Insect is from Kansas which is USA not China

https://www.gbif.org/occurrence/2235721586

Locality does not match coordinates


User: See in registry - Send email System: Chrome 126.0.0 / Windows 10.0.0 Referer: https://www.gbif.org/occurrence/2235721586 Window size: width 2124 - height 1073 API log&_a=(columns:!(_source),filters:!(),index:'3390a910-fcda-11ea-a9ab-4375f2a9d11c',interval:auto,query:(language:kuery,query:''),sort:!())) Site log&_a=(columns:!(_source),filters:!(),index:'5c73f360-fce3-11ea-a9ab-4375f2a9d11c',interval:auto,query:(language:kuery,query:''),sort:!())) System health at time of feedback: OPERATIONAL datasetKey: e6137ccd-15b7-47ca-bb81-91dc3003a9b0 publishingOrgKey: 73fb29e5-c684-4edf-b2ee-41b13a4f329f

Node handles: @sformel-usgs

Mesibov commented 3 months ago

decimalLongitude for this should be negative. Interesting this error wasn't picked up in GBIF processing. In this dataset https://www.gbif.org/dataset/e6137ccd-15b7-47ca-bb81-91dc3003a9b0 there are 235 other records from Kansas (according to locality) with the longitude mistakenly entered as positive.

It would be nice to think that having been notified of a single-record error (as above), a data publisher would check their dataset for other records with the same error. This dataset has many other data problems, though.

sformel-usgs commented 2 months ago

@CatChapman I agree with @Mesibov about the flipped longitudes. You're listed under georeferencedBy, could you please take a look when you have a moment? The occurrenceIDs for which the longitudes should be negative, instead of positive, are:

295582
263433
263439
295558
263497
263446
263496
263495
263313
263434
263162
263438
295556
271807
271808
271802
271803
265902
263321
295564
263323
295581
86440
86439
87680
88123
87061
87124
87125
87123
91240
93563
93562
93905
93909
93907
93908
93906
95015
180181
96436
97893
97892
103728
105071
105073
105072
89060
98454
94567
94566
94940
95646
80617
82735
83331
83330
86437
86438
86477
86476
87182
88165
89869
260263
260264
260270
260267
260262
260266
260268
260269
260261
260265
93539
91971
93955
93954
94791
94186
94184
94185
95657
95654
95656
95655
95653
192789
192786
192785
192792
192790
192788
192793
192787
192791
97910
97905
97908
97909
97911
97907
97906
97902
97904
97903
105149
105150
103488
94841
95071
95889
95883
95888
92203
93821
93822
89062
89070
92580
95279
97604
106811
87608
91791
91578
96155
106809
106813
106810
106812
106814
106808
107632
107633
107631
87120
87119
87121
87117
87118
87116
87122
88811
88813
88814
88812
88810
88815
89653
89666
89671
89669
89668
89670
89649
89646
89642
89644
89655
89662
89645
89643
89659
89654
89650
89660
89667
89672
89673
89652
89661
89658
89647
89656
89651
89648
89657
89742
89746
89745
89738
89727
89739
89736
89723
89728
89729
89733
89735
89731
89743
89741
89744
89747
89755
89752
89753
89740
89737
89732
89734
89724
89726
89722
89797
91888
91911
91912
91573
92145
92146
93233
95798
95360
95359
96974
96976
96975
96972
96973
96473
96475
96474
97736
265901
90734
90720
90718
90719
94221
94220
97201
97924
97961
CatChapman commented 2 months ago

Hi there, thanks for tagging me in this. I indeed georeferenced this many years ago, using the built-in GeoLocate tool in Symbiota. At the time, I reviewed batch of records I georeferenced to avoid issues like this, and it passed "QAQC" at that time. It looks like the longitude value was flipped from negative to positive between then and now - maybe something in the code is returning the absolute value instead of the negative value?

I'm not sure who manages the K-State data on SCAN these days. In my free time I can see if I still have edit privs on SCAN for these data, and if so, if these data points can be easily corrected on the Symbiota frontend.

Mesibov commented 2 months ago

@CatChapman, there are quite a few other data problems in this dataset. Do you think it would be worthwhile contacting the current data manager, or is that unlikely to lead to corrections due to time/funding/staff/resources issues?

CatChapman commented 2 months ago

@Mesibov - I don't think it would hurt to reach out, but I also would be realistic about expectations given your latter clause... only one way to find out, as they say. :)

sformel-usgs commented 2 months ago

I wrote an email to Greg Zolnerowich, the dataset contact.