Closed johnbaums closed 9 years ago
This relates to the underlying ALA service that delivers the data - ALA4R just wraps that service. I've asked the ALA devs for comment, will report here.
Nice package. Over the last 24 hours the occurrences function is producing errors that I haven't seen previously. Any ideas? e.g.
x=occurrences(taxon="penguins", download_reason_id=10) Error in read.table(unz(thisfile, filename = "data.csv"), header = TRUE, : no lines available in input
@WCSPNG - I created a new issue for your comment, see https://github.com/AtlasOfLivingAustralia/ALA4R/issues/8
Back to the geodeticDatum question. From the ALA devs:
"Generally it appears to operate like this:
Your example http://biocache.ala.org.au/ws/occurrence/5400e754-d39c-4814-82ca-2f29b40fb3e2 is (2). The processed location is using the unrecognised datum.
If supplying a valid raw datum the raw location and processed location datums do vary http://sandbox.ala.org.au/ws/occurrences/8580591d-80ba-44c9-9572-96a3d292581e"
I'll close the issue here. If more info is needed, suggest raising an issue on the repo that provides the underlying service: https://github.com/AtlasOfLivingAustralia/biocache-service
Thank very much Ben.
The occurrence function started functioning normally again about 24 hours after I posted on GitHub. I now suspect that a rogue .Rprofile file might have been interferring with the downloads (oddly "search _fulltext" was working but not "occurrences") . Apologies for bothering you.
Wonderful package - so useful. I've stuck a RMarkdown doc on Rpubs to showcase the package at a very basic level.
Cheers, Nathan
On 23/04/2015 5:00 PM, Ben Raymond wrote:
@WCSPNG https://github.com/WCSPNG - I created a new issue for your comment, see #8 https://github.com/AtlasOfLivingAustralia/ALA4R/issues/8
— Reply to this email directly or view it on GitHub https://github.com/AtlasOfLivingAustralia/ALA4R/issues/7#issuecomment-95466124.
Click here https://www.mailcontrol.com/sr/Ozia0S6fQBbGX2PQPOmvUqW%21RI4xIDLrMVeu4IDYsR+gN%21lnmeTw7l1a4vbsEpc5MBnckTdHjFJsVqdfswMBgw== to report this email as spam.
Scientific Support Officer WCS Papua New Guinea PO Box 277, Goroka, Eastern Highlands Province, Papua New Guinea PNG Phone: (+675) 532-3494 Fax: (+675) 532-3180
/Our vision for PNG: Gutpela sindaun, gutpela solwara, gutpela bus. Empowered communities with healthy forests and seas./
This email has been checked for viruses by Avast antivirus software. http://www.avast.com
Consider
x <- occurrences('Diplolaena grandiflora', fq='geospatial_kosher:true', download_reason_id=10)
.Is
x$data$geodeticDatum
the datum associated withx$data$latitude
andx$data$longitude
, or have the coordinates given in those fields already been transformed to WGS84 (or GDA94? - though they are basically identical AFAIK)?If they have been transformed, then:
What does this mean for the following row:
If the datum is unrecognised, and it's not assumed to be WGS84, what datum is assumed? In this case
latitudeOriginal
andlongitudeOriginal
matchlatitude
andlongitude
, so it seems no transformation has taken place. Note also that the originaloccurrences()
query requestedgeospatial_kosher
records only - should records such as5400e754-d39c-4814-82ca-2f29b40fb3e2
be omitted?