Autocomplete with whitespace in names fails.

  • 2
  • Problem
  • Updated 2 years ago
There are several locations which fail to autocomplete correctly.

One example: querying for "Bad " properly gives (among others) the result "Bad Nauheim, Germany" ( http://autocomplete.wunderground.com/... ). However, looking for "Bad N" fails to return this result ( http://autocomplete.wunderground.com/... ) - seriously, what is going on here?

Same problem with "Death " which gives several results relating to
"Death Valley". But autocompleting "Death V" yields no results whatsoever.

What is going on there?

Thanks for any help,
Simon
Photo of Simon

Simon

  • 10 Posts
  • 0 Reply Likes
  • frustrated

Posted 4 years ago

  • 2
Photo of Brendan Hayes

Brendan Hayes, Official Rep

  • 962 Posts
  • 122 Reply Likes
When we investigate this it seems to be working. Are you still having this issue?
Photo of afelicioni

afelicioni

  • 227 Posts
  • 43 Reply Likes
I think I was somehow able to reproduce the issue: it seems this gets triggered since the autocomplete tries to return a "localized" version of response.

For example, an excerpt from http://autocomplete.wunderground.com/aq?h=0&query=Bad%20 contains international (en_US ?) and localized version for a city I flagged for my reference: Bad Hersfeld

{
"name": "Bad Hersfeld, Germania",
"type": "city",
"c": "DE",
"zmw": "00000.1.10542",
"tz": "Europe/Berlin",
"tzs": "CEST",
"l": "/q/zmw:00000.1.10542",
"ll": "50.849998 9.730000",
"lat": "50.849998",
"lon": "9.730000"
},
{
"name": "Bad Hersfeld, Germany",
"type": "city",
"c": "DE",
"zmw": "00000.1.10542",
"tz": "Europe/Berlin",
"tzs": "CEST",
"l": "/q/zmw:00000.1.10542",
"ll": "50.849998 9.730000",
"lat": "50.849998",
"lon": "9.730000"
},
{


The issue gets triggered when querying for http://autocomplete.wunderground.com/aq?h=0&query=Bad%20H seems forcing and filtering for a localized only response: in my case I just get returned the italian one

{ "RESULTS": [
{
"name": "Bad Hersfeld, Germania",
"type": "city",
"c": "DE",
"zmw": "00000.1.10542",
"tz": "Europe/Berlin",
"tzs": "CEST",
"l": "/q/zmw:00000.1.10542",
"ll": "50.849998 9.730000",
"lat": "50.849998",
"lon": "9.730000"
}
]
}


Following this, a user asking for a city with no localized variant name, it wouldn't get data.
Photo of Simon

Simon

  • 10 Posts
  • 0 Reply Likes
[Seems afelicioni was slightly quicker - here is my analysis]

Yes, the issue is unchanged for me.

However, upon further debugging I determined, that the problem is related to the "Accept-Language" header. A request that contains "de-DE" as the first of the acceptable languages results in missing completions:

This request fails:
GET /aq?h=0&query=Bad%20N HTTP/1.1

Host: autocomplete.wunderground.com
Accept-Language: de-DE,de;q=0.8,en-US;q=0.5,en;q=0.3


and this request gives lots of completions:
GET /aq?h=0&query=Bad%20N HTTP/1.1

Host: autocomplete.wunderground.com
Accept-Language: de;q=0.8,de-DE,en-US;q=0.5,en;q=0.3


"de-DE" seems to be a standard language tag, my firefox includes it by default. Even if it were invalid or not known to wunderground it must not result in missing completions.

Please fix this.

Further observations:

Accept-Language: en       - works

Accept-Language: de - fails
Accept-Language: fr - fails
Accept-Language: xy - works
Accept-Language: de;q=0.8 - works


(seems it works in the last case because wunderground fails to understand the quality-parameter...)

Thanks,
Simon
Photo of afelicioni

afelicioni

  • 227 Posts
  • 43 Reply Likes
To follow the good and clean analysis from Simon, I can add the request headers sent from my side to help in fixture from WU staff.


GET /aq?h=0&query=Bad%20N HTTP/1.1
Host: autocomplete.wunderground.com
Connection: keep-alive
Cache-Control: no-cache
Pragma: no-cache
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/34.0.1847.131 Safari/537.36
Accept-Encoding: gzip,deflate,sdch
Accept-Language: it-IT,it;q=0.8,en-US;q=0.6,en;q=0.4,de;q=0.2,fr;q=0.2,nl;q=0.2,pl;q=0.2,pt;q=0.2
Photo of Simon

Simon

  • 10 Posts
  • 0 Reply Likes
It really is strange how this only affects names with spaces:

Querying for "Buchholz%20in" works for "en" as language, but fails for "de".

Querying for "Using" works for "en" and "de", resulting in "Usingen, Germany" (i.e. untranslated in the "de" case) in both cases. So despite not having a translation to german available it still is available in the german search results.

Bye,
Simon
Photo of Brendan Hayes

Brendan Hayes, Official Rep

  • 962 Posts
  • 122 Reply Likes
This is all very interesting, thank you for this feedback! I will share it with the Autocomplete development team.
Photo of Simon

Simon

  • 10 Posts
  • 0 Reply Likes
Is there any progress in this issue? This is driving me crazy.

As an intermediate solution it would be acceptable for me to get the same results as the english ones, even if that means that I get "Bad Nauheim, Germany" instead of "Bad Nauheim, Deutschland". Both is better than not getting Bad Nauheim at all.

Bye,
Simon
Photo of Simon

Simon

  • 10 Posts
  • 0 Reply Likes
It is now 5 months later. Is there any Progress? How did the Autocomplete development team react?

Bonus Problem: The City of "Bad Homburg" (or "Bad Homburg vor der Höhe") is missing completely from the autocomplete dataset, despite it being a fairly large city in the vicinity of Frankfurt am Main.

Bye,
Simon
Photo of Tim Roche

Tim Roche, Official Rep

  • 307 Posts
  • 27 Reply Likes
What is your language cookie set to?  With english as my primary language, I get '

{
  • RESULTS: 
    [

    • {
      • name: "Bad Homburg vor der Hohe, Germany",
      • type: "city",
      • c: "DE",
      • zmw: "00000.5.10638",
      • tz: "Europe/Berlin",
      • tzs: "CEST",
      • l: "/q/zmw:00000.5.10638",
      • ll: "50.226673 8.619633",
      • lat: "50.226673",
      • lon: "8.619633"
      }
    ]
}
Photo of Simon

Simon

  • 10 Posts
  • 0 Reply Likes
ok, correct. With english as language Bad Homburg appears.

So it in essence is the same problem as originally described 5 months ago: Names with spaces cause troubles when doing requests in e.g. the german language.
Photo of bonar

bonar

  • 1 Post
  • 0 Reply Likes
I'm getting the same problem. I use Autocomplete API with JSONP, so it is not easy to change Accept-Language header for my request...

Is there a plan to fix this problem?