How to Delete Many “Unsorted Items” from HERE Maps

There’s a lot to like about HERE Maps (née Ovi Maps, née Nokia Maps), especially, for my purposes, that it runs very well on Firefox OS mobile devices – indeed Mozilla is promoting it as the “maps” application for Firefox OS.

Last year when Nokia finally spun down Plazes, it helpfully offered an option to we olde Plazes users to take our saved collections of “Plazes” – locations we’d checked into – and import them into HERE Maps as points of interest.  I did this, and as a result ended up with 802 “unsorted items” my HERE Maps “Collections” section:

Initially this was just an irritant; when I started to use HERE on my Firefox OS phone it became a liability, because opening the “Collections” tab on the device took an awfully long time (in theory because the device had to grab the details of those 802 unsorted items).

I tried to resolve this with some helpful Nokia engineers, but eventually their patience ran out and I was left to my own. Fortunately I managed to figure out a relatively easy – if hacky – way of making this happen.

Here’s what I did.

I logged into here.com with my Nokia account – the account with all those pesky “unsorted items”. Then, using the Firefox Web Developer tool I watched the “Network” tab as I deleted one of the items; it called this URL:

http://here.com/collectionsBackend/favourites/favoritePlace/fb75b689-2ab5-4ff4-9b7a-03798b4540ae

I reasoned that the “fb75b689-2ab5-4ff4-9b7a-03798b4540ae” was a unique ID for the item, and so set about finding a list of all of the IDs of the “unsorted items” attached to my account.

Again using the Web Developer “Network” tab, I was able to determine that the HERE website pulls a JSON representation of all of my Collections, which includes the “unsorted items” as well as items that I’d placed inside named collections, from:

http://here.com/collectionsBackend/all?skiplastsync=false&skipfavourites=false&skipcollections=false

This JSON looks like this:

{
    "favourites": {
        "total": 802,
        "startIndex": 0,
        "data": [
            {
                "type": "favoritePlace",
                "id": "938e7f3d-fca6-48b6-848c-864afc27627e",
                "deleted": false,
                "collectionId": [ ],
                "name": "Aqua Bistro",
                "creatorId": "9f95b738-772b-4862-bb3a-9b17865d665f",
                "createdTime": 1336568888931,
                "updatedTime": 1337712464859,
                "location": {
                    "position": {
                        "longitude": -71.950513100715,
                        "latitude": 42.8771882289749
                    }
                }
            },
            {
                "type": "favoritePlace",
                "id": "ee51605b-7829-438a-b2e7-7ae9c64cbc0f",
                "deleted": false,
                "collectionId": [ ],
                "name": "Arken",
                "creatorId": "9f95b738-772b-4862-bb3a-9b17865d665f",
                "createdTime": 1336568893409,
                "updatedTime": 1337712495800,
                "location": {
                    "position": {
                        "longitude": 12.3842807492963,
                        "latitude": 55.606174327026
                    }
                }
            },

And continued on through all 802 former-Plazes and a handful of other items I’d saved inside HERE. The key here was to extract the “id” of each item. To do this I just copied a text file, used grep to filter for lines with “id”: and then used BBEdit search-and-replace to turn each line into an API call to delete the item.

Now I had a text file with a whole bunch of URLs to hit with an HTTP DELETE request; the final piece of the puzzle was to figure out how to hit this while authenticated to my account. This turned out to be easy: I just used the Web Developer tool to examine the DELETE request that Firefox sent, and then copied the cookie key-value pairs it sent along with the request into the cURL equivalent. What I ended up with was whole bunch of cURL commands, each of which looked like this:

curl -X DELETE \
  -b "undefined_s=First+Visit; OviAPICaller:3548978; ... " \
  http://here.com/collectionsBackend/favourites/favoritePlace/442bd...

the second line contained each of the cookies I pulled from Firefox, in the format “NAME1=VALUE1; NAME2=VALUE2…”.

With thls in place, I saved the text file with the cURL requests and ran it from the command line on my Mac:

sh delete-here-places.sh

The script stopped unexpectedly after deleting about 400 items (error message “Sorry, there’s a problem on our end.”), but when I ran it again it continued.

The result no “unsorted items” in HERE Maps, confirmed by looking at the JSON:

{
    "favourites": {
        "total": 0,
        "startIndex": 0,
        "data": [ ],
        "count": 0
    },

One important thing to note: if you do what I did, you’ll delete all of the “favourites” you’ve saved in HERE, ones you imported from Plazes and ones you save in HERE itself; beware.

Isn’t the open web great!

Comments

mespilus's picture
mespilus on August 23, 2013 - 23:22 Permalink

Having unsuccessfully tried to import a 300+ waypoint bike ride route into my Nokia N8, (three times by the way, as a standard .lmx file then as a route .lmx, then as a track .lmx),
the N8 did not see any ‘route’ just 300+ ‘places’ three times.
If only I was savvy enough to understand what you have illustrated above,
but I may as well be a dog staring at a bike.

Well done you,
I’ll have to go back to individually deleting each ‘place’,
with the long wait as the overworked Here server eventually lets me know I can proceed.