Map count does not match georeferenced record count
14344
Reporter: jlegind
Assignee: jlegind
Type: Bug
Summary: Map count does not match georeferenced record count
Priority: Critical
Resolution: Fixed
Status: Closed
Created: 2013-11-08 15:38:37.378
Updated: 2015-03-10 11:01:29.368
Resolved: 2015-03-10 11:01:29.349
Description: This concerns the Belgian dataset from INBO "Loopkevers aan de grensmaas-Carabid beetles near the river Meuse
http://www.gbif.org/dataset/f4230399-51b8-4862-8991-93d6ba11406f
The number of records next to the map in that section of the page, states that there are '4,202 georeferenced data' but I see 5,860 georef records when querying for that property:
http://www.gbif.org/occurrence/search?GEOREFERENCED=true&DATASET_KEY=f4230399-51b8-4862-8991-93d6ba11406f
I checked the records from the DwC archive and they all have lat/long coordinates.
The resource was indexed twice to make sure the issue persisted.]]>
Author: trobertson@gbif.org
Created: 2013-11-12 11:27:39.541
Updated: 2013-11-12 11:27:39.541
There are 2 backend systems that provides counts.
a) the "occurrence cube" which simply tracks counts, and is what shows on the dataset page
b) the SOLR index is able to provide a count of records for a query.
The cube shows 4,202 records on the dataset page [1].
When you click the "all records" link beside the map, you get to a search query [2] which also shows 4,202 records
Please note, that the link [2] includes "with NO coordinate issues" since maps do not show records with issue. The link you post above [3] includes records with issue. Thus I believe the portal to behaving correctly, and this should be closed as invalid.
As a data management activity though, the records with issue might need inspection. The occurrence search can provide those records [4]. I have taken one record [5] which is marked as incorrect and putting those coordinates into the geocode lookup WS, it returns as the Netherlands [6]. Google suggests this is correct too [7].
The record itself states Belgium however, and therefore it is marked as suspicious.
[1] http://www.gbif.org/dataset/f4230399-51b8-4862-8991-93d6ba11406f
[2] http://www.gbif.org/occurrence/search?DATASET_KEY=f4230399-51b8-4862-8991-93d6ba11406f&SPATIAL_ISSUES=false&GEOMETRY=-180+-82%2C-180+82%2C180+82%2C180+-82%2C-180+-82
[3] http://www.gbif.org/occurrence/search?GEOREFERENCED=true&DATASET_KEY=f4230399-51b8-4862-8991-93d6ba11406f
[4] http://www.gbif.org/occurrence/search?GEOREFERENCED=true&SPATIAL_ISSUES=true&DATASET_KEY=f4230399-51b8-4862-8991-93d6ba11406f
[5] http://www.gbif.org/occurrence/812090585
[6] http://boma.gbif.org:8080/geocode-ws/reverse?lat=50.98410&lng=5.75
[7] https://www.google.com/maps/preview#!q=50.98410%2C5.75&data=!1m4!1m3!1d5370!2d5.7553029!3d50.9855797!4m12!2m11!1m10!1s0x47c0c427ffcf7799%3A0x6bc263a75970371a!3m8!1m3!1d26081603!2d-95.677068!3d37.0625!3m2!1i1024!2i768!4f13.1
Author: jlegind@gbif.org
Created: 2013-11-19 09:46:52.409
Updated: 2013-11-19 09:46:52.409
I have had some discussion with Dimitry about georef and we might have to open this issue again: http://dev.gbif.org/issues/browse/PF-1315
Did some testing on the verbatim lat/long values and according to these, the records I tested fall just inside the Belgian border and should be valid.
http://www.gbif.org/occurrence/search?SPATIAL_ISSUES=true&DATASET_KEY=f4230399-51b8-4862-8991-93d6ba11406f (second record from the top)
http://www.gbif.org/occurrence/812085784/verbatim
https://www.google.com/maps?q=50.89844,+5.69506&hl=da&sll=37.0625,-95.677068&sspn=60.635244,95.449219&t=m&z=16
Same goes for the bottom record Tychius parvulus Stephens, 1829 , verbatim coordinates = 51.00344 / 5.76685
https://www.google.com/maps?q=51.00344,++5.76685&hl=da&sll=50.89844,5.69506&sspn=0.01199,0.023303&t=m&z=16
Could it be that the geocode webservice looks at the rounded coordinate values rather than the high precision ones?
Sorry about this
/JanK
Author: kbraak@gbif.org
Created: 2013-12-18 15:26:49.582
Updated: 2013-12-18 15:26:49.582
[~jlegind@gbif.org] I'm trying to understand why this issue was marked as invalid.
Seems like the improvement made in POR-1202 or the future enhancements in POR-1387 are needed to close this issue?
Author: jlegind@gbif.org
Comment: Kyle you are right - the issue remain open then.
Created: 2014-01-09 15:41:42.734
Updated: 2014-01-09 15:41:42.734
Author: omeyn@gbif.org
Comment: This is now effectively a dupe of POR-1387
Created: 2015-03-10 11:01:29.366
Updated: 2015-03-10 11:01:29.366