The case of the reappearing location data (or delete vs suppress)

On Social Hiking, you have the ability to delete locations on your maps – either individually (using the id number that appears in the relevant info window on your map*) or by a date range. Both options are available under the ‘Delete Beacons’ tab in the location sources section (accessible when you log in).

[* yeah I know this is quite clunky – this is being addressed in the big update I am working on!]

If you have used this function already, you will have noticed there are two types of delete available – ‘delete’ and ‘suppress’.

Delete – this deletes the beacon(s) from the database, and updates any related maps.

Suppress – this keeps the beacon(s) in the database, but removes it(them) from any related maps.

So what is the difference?

The difference relates to how Social Hiking handles new locations. Each new location shared via any of your location sources is checked to see if it is a duplicate of any existing locations in the database – this check is fairly complicated, but is something like  “do I already know that this user was at this location (without moving away and then coming back) in the last hour?” (this is where your tolerance setting comes in by the way, but that is probably a topic for another post!).

As a suppressed beacon is still in the database it stops ‘duplicate’ beacons from being added to your map. As a deleted beacon is removed from the database, it has no affect on new location data received.

This subtle difference is important when you take into account how Social Hiking has to check for new location data:

– for SPOT and YellowBrick, the location data arrives as a feed of your last x positions (20 I think) – all these positions have to be processed as new location data.

– for ViewRanger,  Social Hiking can request all new location data since the last position was received. This is however made more complicated by the way the ViewRanger app uploads data: BuddyBeacons are cached on your phone when you are out of signal, when signal returns the beacons are uploaded latest first. If signal interrupts this upload, it is possible that Social Hiking can receive the latest locations and then miss older ones – you would be surprised how often this happens! To overcome this feature/bug, Social Hiking always processes all your beacons since 8 hours before the last beacon was received (up to a day before).

In both cases – the duplication check stops repeat locations being added…. unless you have deleted some or all of those locations in the meantime…. in which case they will reappear! 

So if you want to remove locations permanently then choose the ‘suppress’ option!

If you only want to remove locations, but plan to replace them with data from another source (a gpx upload for example), then choose ‘delete’ .

This all becomes a massive nightmare when you merge gpx locations with live shared locations and discover that the time stamps are slightly out of sync (this has the effect of creating a spiky altitude graph, and massively inflating distance and altitude gain). If this happens do not panic – just ‘delete’ the locations, wait up to half an hour for Social Hiking to reload any data from your live sources, ‘suppress’ the locations, then upload your gpx file (or you can always get in touch, and I can remove the dodgy data from the database direct).

Locations created from media are not currently affected with the same issues – the media item is only ever imported once, so if the location is deleted or suppressed it will not reappear.

Share with Others:
  • Digg
  • StumbleUpon
  • del.icio.us
  • Facebook
  • Twitter
  • FriendFeed
  • Google Buzz
  • Posterous

Got something to say? Go for it!