Royal Randwick

Written by on October 12, 2014, 11:16 pm

Just another places API data glitch that I needed to write down somewhere. The auto complete results for "Royal Randwick" has the suburb as "Randwick" which is all good:

The corresponding detail response has "Sydney" as the locality. Accurate but imprecise ;)

Permalink - Comments - Tags: Development

The Mauritius Campaign

Written by on August 22, 2014, 7:39 am

Bruce Trinque, an esteemed member of the Gunroom, passed away last year. His family has given me permission to host an article he wrote many years ago which describes the history behind The Mauritius Command. It's and excellent read and I am honoured to include it on this site:

The Mauritius Campaign

Permalink - Comments - Tags: Patrick O'Brian

Same same but different

Written by on July 15, 2014, 7:20 am

I have done a bit more digging into issues I have been having with the places API and discovered that Google has deprecated (as of 24th June) the reference property of autocomplete responses (and place detail requests) and moved to a new place_id parameter. The semantics of these parameters are the same so I didn't have to modify much code (just change the names) and it looks like the new ids are working better than the old ones.

I hoped that all the problems I have been seeing would go away with the new ids, and some certainly have (Bridge St Sydney seems to work now), but have found there are still erroneous suggestions coming back in autocomplete.

If you search for "60 Pitt St" while in the Sydney CBD the first suggestion you get back is "60 Pitt St, Sydney" followed by "60 Pitt St, Parramatta" and then "60 Pitt St, Redfern". There are a couple of issues with this:

  • - Why is Parramatta (23 km) presented before Redfern (3km)?
  • - When I resolve the place_id for the first result, I would expect 60 Pitt St in Sydney CBD. Instead, I get the location in Redfern (same lat, lng as the third result).

So still somewhat dissatisfied with the data I am getting back from the Places API, but getting closer.

Permalink - Comments - Tags: Development

George St and St George

Written by on July 7, 2014, 4:18 am
Time to post another bug in the autocomplete data. This one happens when you do an autocomplete request for "George St" when you are in the Sydney CBD.

As you can see here, the first prediction you get back from autocomplete is "George Street, Sydney, New South Wales". Seems legit:

Unfortunately when you go to resolve this location reference id, you get the center of the St George region. Definitely not the place I was looking for.

The predictions that follow St George in the array are George Streets in Redfern, Parramatta, North Strathfield and Liverpool, but not George Street in the Sydney CBD.

Permalink - Comments - Tags: Development

A bug in Google Places Autocomplete predictions

Written by on June 26, 2014, 1:52 am

I needed to document a bug I found with the Google Places Autocomplete API and here seemed as good a place as any. If you are from Google and you plan to fix this, I would love to hear from you.

Update: Very similar problem with typing "Pitt St" in the city. Getting a location in Parramatta.

If you make an Autocomplete request, from the following location (just near Circular Quay in Sydney) for the search string "Brid" you will be presented with a list of predictions that make perfect sense:

I am making the request with these parameters:

ParamValueExplantation
location-33.862408,151.210848Corner of Loftus and Custom House Lane
radius30000Only interested in locations 30km from your location
inputbridThe begning of "Bridge St"
countryAUJust results in Australia please

You can see the JSON result I get back from the request or try it yourself here (assuming you have an API key). The first result in the list of predictions is this one:

FieldValue
descriptionBridge Street, Sydney, New South Wales, Australia
referenceCmRfAAAAs3Qot0vFrtKUIgWa7pCD5...

I have linked the reference id in the table to the corresponding Google Places Details Request. This reference id describes Bridge St in the Sydney CBD, just up the road from the request location, so all good so far.

The problem raises its head when we try the same request on the other side of Darling Harbour in Pyrmont (is also reproducable a few blocks away in the CBD):

I am making the request with the same parameters as before, except for my location:

ParamValueExplantation
location-33.865606,151.196359Just across the park from Google in Pyrmont

I get back this JSON result. You can try it yourself here (again you need an API key). This time my results look suspiciously like the first. Importantly the first entry has the same description, "Bridge Street, Sydney, New South Wales, Australia". I am going to show this description to my unsuspecting user.

FieldValue
descriptionBridge Street, Sydney, New South Wales, Australia
referenceCmRfAAAAWcjNUI81JLFvS53mlF51Q...

Unfortunately this id refers to Bridge St in Windsor NSW, 55km away. Now I am sure Bridge St in Windsor is lovely this time of year and certainly worth visiting, but perhaps a better prediction for the "Bridge St" the user is looking for is the one that is just 3km away.

It would be awesome if this particular case (and perhaps any like it) were fixed and would also be good if the place description reflected the locality better. If "Bridge Street, Windsor, New South Wales" were returned for the second case, then my users would be far less inclined to click on it thinking it is Bridge St in the City.

Permalink - Comments - Tags: Development