Ispot seems to be moving my observations from the locations I carefully entered to places I’ve never been to. I visited the Observations Map, filtered to my own observations, and found several places where my obs had drifted for some reason to new locations.
In this screen snip the four obs to the right have drifted eastwards from their original locations.
In this snip of obs made in my garden (the green square or allotments (the blue square).
two obs have drifted westwards, into other people’s land, and one has drifted northwards into a road.
And in this one, an observation of Sea Purslane, has moved from the small tidal marsh to the northwest to a street I’ve never been to in the middle of a housing estate:
THIS IS REALLY BAD NEWS @miked . APPALLING…Sifting Observations to see if they are correctly located will be the pits - an almost impossible CHORE - something that will make me stop posting Observations.
I think we should expect ANYTHING to happen until we hear something positive from the Admins… Seems little point in watching THIS space.
To be fair, they’re not going far - a hundred metres at the most.
Are these recent entries? Since the update to iSpot the system does something odd when you enter a location using OS grid references which typically moves the location a bit (if I had to guess I’d say it is mapping a rounded grid reference to set of rounded lat-long co-ordinates and the two rounding approaches are mucking things up). Not a major issue for ID purposes as it is not moving things from one area of the country/world to another but rather annoying if you are looking back at your old entries.
If it is old records that were in one location when you entered them but are in another one now that sounds like a different issue.
If recent means since the update, it looks as if they are recent, It’s not a big deal from my point of view, because I know pretty much where I saw things on my local patches, One example is sea kale at Wembury, moved from the beach to the middle of a wheat field. That’s more irritating than anything else. But if it was someone else looking for a species I’d found it would make it impossible. Last week I found what’s supposed to be a very scarce gall on an ivy flower, That sort of record needs to be as specific as possible imho.
OF COURSE IT IS A BIG DEAL.
This is simply data corruption and it means that the Open University does not mind that it is feeding wrong localities into the national databases. It might not matter in the UK, but 100m in the Cape Flora can be a totally different patch and make the difference between a development or a conservation easement.
This has been identified as an issue in May - before the revised site went live. AND THREE MONTHS ON HAS STILL NOT BEEN FIXED.
Is this the quality of data that the Open University allows? Shocking! Do they not care for international standards of data curation and storage. How can they be allowing this to continue?
The other data corruption issue is that the locality resolution has been lost. That was a condition of southern Africa joining iSpotm and the OU are in breach of this agreement. But they dont seem to care!
THREE MONTHS OF CORRUPT DATA. How is this going to be fixed? Who is going to fix it?
UTTERLY UNACCEPTABLE.
This is a serious issue. The main issue here is that there is no indication about the accuracy of the data. Because the dot is on a map, it looks as if accurate, unless if obvious (e.g. is in the sea). But that dot could be false. There needs to be a scale of accuracy. Otherwise all observations will be less than reliable. Or not scientific. There are numerous observations with such suspected localities.
AND EVEN WORSE: SENSITIVE DATA ARE BEING RANDOMLY FUDGED TO 10KM WITHOUT ANY INDICATION IN THE DATA THAT THE FUDGING HAS BEEN DONE.
On the old iSpot the data shown with clipped to 1 decimal place (or 10km) so that by looking at the number of decimal places the accuracy of the data were obvious.
For some inexplicable reason - against all intelligent data standards, it was decided to “LIE” on this new iSpot and the data are randomly fudged with no evidence that it has been done.
We complained about this in May, and noting has been done. International Standards be dammed - iSpot decided to post incorrect data for Sensitive Species, potentially resulting in poachers/harvesters/collectors turning up at random farms, potentially upsetting landowners
.
The correct standard is to reduce the resolution to either:
Anyone can then immediately see the resolution and poachers wont bother visiting these sites, but have to get their data elsewhere.
The old iSpot was leagues above this new site in terms of design. This site is quite pathetic.
Why are you still here?
Because I have invested 50 000 observations on the site! When it was up to standard.
And because I am southern African curator - not that that counts for anythng. Since the Sept 2014 amalgamation I have been unable to do ANY curation. The most urgent requests (about 1% of curation) were done by the UK curator.
This is the second degradation of the site. Sept 2014 was almost as bad and also generated over 100 major bugs or retrograde design (compared to the old ZA site: we had tailored the ZA site for efficiency and user experience, some of which was not implemented on the UK site), of which most are still present.
But unless something is done soon I shall leave. The question is:
We will demand all our observations repatriated though.
See https://www.surveymonkey.com/results/SM-S9F6MR9V8/
But at this stage we are giving the OU one last chance.
As Tony says this is a big deal. We spoke recently to a manager of the programmers who have been working on this issue for some time and he said that the issue also affected the old site. However in earlier years I did quite a lot of checking of locations on the old site and they seemed fine to me (checking using gps 5m accuracy and zooming in and assuming google aerial imagery is only a few metres out at worst).
Joe, how have you been entering your data? Is it from the metadata in images (the lat long coordinates stored in the image exif) or by clicking on the map or by typing lat long or OS grid reference. There was a suggestion that it was the OS grid ref that was not working correctly whereas the other methods may have been ok.
Would be good to have plenty of examples from all of these methods from different parts of the world. I did some checking of the metadata method when the new system first started and those looked ok.
If it is mainly affecting OS then this narrows down the problem. I specifically mentioned to the programmers when they first started that (a) the OS grid had recently changed, although the change was too small to affect the kind of location info we use but much more importantly (b) there are many methods to approximately convert between lat long and OS but there is only one method that is fully accurate, the Ordnance Survey OSTN15 & OSGM15 method (it used to be OSTN02 & OSGM02 before the OS grid was updated). Many general websies use one of the approximate methods as it is much easier and computationally less intensive but depending on the method the errors are between 3m and 300m so these are not acceptible.
how are you getting the locations for your 100x100 square, that would be a good one to test for bad locations. Do you have the ability to do this yourself possibly using the tom bio plugin for qgis? Or I may be able to do it for you.
I am copying in these into each Ob.
58.940855863240245
-3.0766675522188507
I then open satellite view and move the Ob by a few meters. I make certain EVERY time that the 6 fiig Grid ref is the right one.
I had to enlarge my map polygon (it is not precise) to allow for my errors. The Polygon is unnecessary but I wanted to show it.
If the locations move a little I won’t know unless they disappear from >>MY PROJECT<<
Did you know that all email notifications from the Forum are linked to the Approval site
Typically Typically http://forum.ispotnature-approval.org/t/continental-drift/399/14 - logged OUT
which should read Continental Drift? - Logged IN
It’s a whole MESS Mike and getting worse DAILY, if not HOURLY
I have looked through a bunch of my uk observations and the location is correct to within a couple of metres for all of the ones checked. However I nearly always use the gps location embedded from the image so this is only checking one method. I do occasionally use the map and these you can see so assume they don’t move.
What I have not tested is inputting the OS grid ref directly into the box on the page, this is where I think one of the errors is happening. This is more difficult to test as there are few ways to get the correct OS grid ref for the reasons I mention elsewhere (websites and indeed gps units/smartphones may use the less accurate conversion method), suggest you use the https://www.ordnancesurvey.co.uk/gps/transformation/ OS website if there are just a few to test.
Ok, thanks for the message about email notifications from approval site that explains the problems I was having yesterday with those images not showing. Hopefully this should not be difficult to fix.
I will test some methods this morning…
Happening from at least 14 Aug…
