Android geocoder still not working

[vreixo]

It seems that we are not getting back functionality automatically, I suppose that would be necessary to contact Google.

Today Android geocoder results are still not working properly, just returning 4 or 5 too general results. For example selecting "Prefer Android geocoder" and Tampa server, writting "airport" on text boxes will display 4 results "Tampa, Pinellas County, Pinellas County Aquatic Preserve, Pasco County". And this are going to be the results for every input inserted on this server.

We still continue clearly limited.

At least Google Places is already working again.

[barbeau]

Hmmmm, not good. I'm seeing the same on my device.

@vreixo Have you found any examples of this happening to anyone else, and possible solutions? I think contacting Google directly is a long shot, but I'm willing to try it. Do you have an estimate of the number of requests you were sending per second, just so I can explain what was going on?

[vreixo]

@barbeau I agree, it's an unfortunate situation and it's specially not good because the app is failing completely on every device that it's installed because the Android geocoder does return results, although they're incorrect, not allowing the fallback geocoders to get triggered (now this is worked out but, as you know, this was not released yet).

I didn't have any time to investigate the issue because I'm on the final days to deliver my thesis (if I have still time to do it). So, I don't know about others. I just have read on stack overflow about one guy that had some kind of concerns about what were the limits and wrote to Google and had a reply describing the limits, was on the previous closed issue http://stackoverflow.com/questions/8218764/android-geocoder-quota-limits.

It's quite difficult to estimate the number of requests per second, I suppose that could be really a lot. There was one moment of the development that each walking/biking subdirection leg of each itinerary were queried when they had auto-generated names. If on each leg they were like 3 or 4 for example, with 2 or 3 walking subdirections by itinerary and 3 itineraries, 36 queries that are going to be in the same second if the app is so quick to do it (a new asynctask it's created and processed for each query) and for some trips may be more perhaps till 70-80 I guess, all depends on the number of unnamed points and with bike trips in Coruña, there were many.

Also in the first moment this queries were not cached and each time that the directions were generated (each time this screen was opened or app restarted) the queries were sent again.

The good point is that this situation was less than 48 hours that I have dedicated to the development of this feature.

The code is still on this branch https://github.com/vreixo/OpenTripPlanner-for-Android/tree/issue357 if you want to prove that this was not with bad intentions.

[barbeau]

Just chatted with Android Developer Console support. They initially referred me to the API Console, but I pointed them to my StackOverflow post that highlights that it's not clear what backend the Android Geocoder uses, and that there is no "Android Geocoder" entry in the API Console. They agreed to look into it further and would get back to me by the end of the day (fingers crossed).

[barbeau]

Also, as mentioned in the above SO thread by others, there is a "Geocoding API" in the API console. This refers to the Google Geocoder API for web apps, not the Android Geocoder. Just in case the two are related, I just turned on the "Geocoder API" in the API Console. I haven't seen any change on my end, but @vreixo let me know if you see any changes.

[barbeau]

@vreixo Is there an easy way to see if the Android Geocoder is working using the current master branch?

[vreixo]

@barbeau yes, there is the way that I have described at the beginning of this issue. Just be sure that "Prefer Android geocoder" on settings is checked and input any word in the start/end text boxes that you think that should return some results, like airport, if it's not working the returned results won't have anything to do with an airport and are going to be very general results like "Tampa, Florida" for example.

The patch only affects when points are selected on the map, because we have a reference of the exact lat/lng to compare with the results and see if they're good or not.

[barbeau]

I tried that with master, but I get results and if I look at Logcat it
appears as if a Nomination response is being used.
On Sep 2, 2014 5:59 PM, "Vreixo González Caneda" [email protected]
wrote:

@barbeau https://github.com/barbeau yes, there is the way that I have
described at the beginning of this issue. Just be sure that "Prefer Android
geocoder" on settings is checked and input any word in the start/end text
boxes that you think that should return some results, like airport, if it's
not working the returned results won't have anything to do with an airport
and are going to be very general results like "Tampa, Florida" for example.

The patch only affects when points are selected on the map, because we
have a reference of the exact lat/lng to compare with the results and see
if they're good or not.

—
Reply to this email directly or view it on GitHub
#396 (comment)
.

[barbeau]

Sorry, I think I misunderstood your response. It works when I long press
on map, but now I'm seeing it fail when I type into the box - right?
On Sep 2, 2014 6:08 PM, "Sean Barbeau" [email protected] wrote:

I tried that with master, but I get results and if I look at Logcat it
appears as if a Nomination response is being used.
On Sep 2, 2014 5:59 PM, "Vreixo González Caneda" [email protected]
wrote:

@barbeau https://github.com/barbeau yes, there is the way that I have
described at the beginning of this issue. Just be sure that "Prefer Android
geocoder" on settings is checked and input any word in the start/end text
boxes that you think that should return some results, like airport, if it's
not working the returned results won't have anything to do with an airport
and are going to be very general results like "Tampa, Florida" for example.

The patch only affects when points are selected on the map, because we
have a reference of the exact lat/lng to compare with the results and see
if they're good or not.

—
Reply to this email directly or view it on GitHub
#396 (comment)
.

[vreixo]

Yes, that's it :-) I was already looking at the line where is the decision to use other geocoders taken (https://github.com/CUTR-at-USF/OpenTripPlanner-for-Android/blob/master/opentripplanner-android/src/main/java/edu/usf/cutr/opentripplanner/android/util/LocationUtil.java#L228) and the only optionwould be that the Android geocoder won't be returning any results.

I have taken some screenshots just for better document the issue.

[barbeau]

OK, thanks, sorry about that. So far not a lot of feedback from Play
Console support, they are saying it may be an issue with the Geocoding API
web service limit, but we aren't using Geocoding API web service. My
suspicion has always been that the android Geocoder is linked to the
Geocoding API within most devices, but we have no way to confirm that and
no way to see quotas in the API console.
On Sep 2, 2014 6:19 PM, "Vreixo González Caneda" [email protected]
wrote:

Yes, that's it :-) I was already looking at the line where is the decision
to use other geocoders taken (
https://github.com/CUTR-at-USF/OpenTripPlanner-for-Android/blob/master/opentripplanner-android/src/main/java/edu/usf/cutr/opentripplanner/android/util/LocationUtil.java#L228)
and the only optionwould be that the Android geocoder won't be returning
any results.

I have taken some screenshots just for better document the issue.

[image: screenshot_2014-09-03-00-10-20]
https://cloud.githubusercontent.com/assets/3153388/4126704/faca9700-32ee-11e4-98c8-cd304132a690.png
[image: screenshot_2014-09-03-00-10-37]
https://cloud.githubusercontent.com/assets/3153388/4126703/fac9eea4-32ee-11e4-859e-f31e4b318253.png
[image: screenshot_2014-09-03-00-10-44]
https://cloud.githubusercontent.com/assets/3153388/4126705/facaa772-32ee-11e4-8076-20a069c9bcc5.png

—
Reply to this email directly or view it on GitHub
#396 (comment)
.

[barbeau]

@vreixo Maybe there is a chance that your work on this is a coincidence, and something else is causing the Android Geocoder failure?

See:
https://code.google.com/p/android/issues/detail?id=75575

This makes sense to me, since the geocoder is returning some (if incorrect) results. If we were banned, it seems like it would be returning no results.

[barbeau]

@vreixo I just put together a small sample project to test the Android Geocoder in a new app, and it appears to have the same problem of the Android Geocoder not working:
https://github.com/barbeau/GeocoderDemo

Can you take a quick look at this project and confirm that I'm executing an Android Geocoder search in the same way as OTP Android? And, can you confirm you get the same erroneous results?

If you get the same results, I'll post this sample project to the above AOSP issue to demonstrate the problem.

[vreixo]

@barbeau today I won't be able to work too much on this, because I need to
advance with my project.

I have taken a quick look and, yes, you're using it the same way. I have
read on the issue that you have mentioned that without boundingbox the
problem is solved, so you can check if it works that way (I suppose that
will be using the other very similar function that don't have bounding box).

If this would be a solution and Google don't solve the problem maybe we can
use this on the app, because we do ourselves filtering of the results.

2014-09-03 16:43 GMT+02:00 Sean Barbeau [email protected]:

@vreixo https://github.com/vreixo I just put together a small sample
project to test the Android Geocoder in a new app, and it appears to have
the same problem of the Android Geocoder not working:
https://github.com/barbeau/GeocoderDemo

Can you take a quick look at this project and confirm that I'm executing
an Android Geocoder search in the same way as OTP Android? And, can you
confirm you get the same erroneous results?

If you get the same results, I'll post this sample project to the above
AOSP issue to demonstrate the problem.

—
Reply to this email directly or view it on GitHub
#396 (comment)
.

[barbeau]

I posted my demo app to the AOSP issue. I also added another button to the demo app, so others can easily test with and without the bounding box.

I found a StackOverflow question from someone else on the same issue as well:
http://stackoverflow.com/questions/25621087/android-geocoder-getfromlocationname-stopped-working-with-bounds

I've also posted to the Android Developer's group:
https://groups.google.com/forum/#!topic/android-developers/KuZDVRXyTc0

...and G+ about the issue:
https://plus.google.com/+SeanBarbeau/posts/Mm5YwzeUoZV

[barbeau]

Another possible work-around is to use the Google Geocoding API web service directly instead of the Android geocoder. I've always thought that the Android Geocoder is using the Geocoding API under-the-hood, so moving to the Google Geocoding API may just be cutting out the middle man. It seems that getting support for the Google Geocoding API will be easier than the Android Geocoder, since no one really seems to know how its implemented or where to get support for it.

[vreixo]

@barbeau Your solution might be best for the long term, although I think that there are some important aspects of Android geocoder like caching of results that we might lose moving to the API. Now I find Android Geocoder much faster for example than Google Places, but is just how I felt it I didn't actually measured the difference.

I think that as a quick fix we can check how is working to just remove the bounding box and use our results filtering. Just for the next release until we implement something better or the issue is solved.

[barbeau]

@vreixo Agreed, I thought the same thing about caching and responsiveness when using the Android Geocoder.

I think that as a quick fix we can check how is working to just remove the bounding box and use our results filtering. Just for the next release until we implement something better or the issue is solved.

Sounds good to me.

[barbeau]

@vreixo submitted a work-around for this issue in #406, but I'm going to re-open the issue until we get get more clarity on a real solution.

[barbeau]

I prematurely merged the last PR, so the remainder of the commits are in #408. I'm re-opening this issue again, as stated earlier, until we get more clarity on a real solution.

[vreixo]

On issue page in android:

Comment #19 on issue 75575 by [email protected]: Geocoder has stopped working in existing application com.cavtel.android.keyfuels
https://code.google.com/p/android/issues/detail?id=75575

It looks like there is some improvement in results - I'm now seeing results relevant to my current location when using the bounding box. Are others seeing the same improvements?

[kalon33]

Geocoding has stopped working since a few days in the app (tested on both my phone and tablet). Any reason why?

[barbeau]

@kalon33 Hmmm, not sure. Doesn't seem to be working for me either in OTP Android.

Can you try running the below project on your device, and see if you get results when tapping the "Run Geocoder w/ bounding box" button?

https://github.com/barbeau/GeocoderDemo

[kalon33]

@barbeau how can I build an apk from this to push on my phone/tablet? I launched gradle, it built properly but I cannot find the output file.

[barbeau]

If you do gradlew installDebug it should directly install the app to your device. You can then manually tap on the app icon "GeocoderDemo" to launch it. You can alternately launch via command line with adb shell am start -n com.barbeaudev.geocoderdemo/.GeocoderDemo.

[kalon33]

So I just tried it on my phone and got results (12 "airports" and 4 "station" when I launched these requests, without bounding box I could get my address resolved). So... it's seems an app problem isn't it? Maybe a quota problem of some API? Or some change in something?

[barbeau]

I had forgotten the full history of this issue - I believe we pulled the Android Geocoder from OTP Android when it stopped working, and as a result we're using a different geocoder by default now. So this issue is likely with that geocoder. I'll see if I can look into it next week.

[kalon33]

@barbeau Do you think it might be a request number limit of some API?

[barbeau]

Looks like its something with the MapQuest Nomination API. If I change the
default search provider to Google Places it works. But of course you can't
do this, because you can't access settings :(. You could switch if you
build the app yourself.

I think the quick fix for this is to re-enable the Android geocoder, which
seems to be working again.

[bikeoid]

Mapquest has activated a developer key requirement for Nominatim,etc use during the 4th quarter of last year. But it's limited to 15,000 transactions per month.
https://developer.mapquest.com/plan_purchase/steps/business_edition/business_edition_free

I haven't surveyed - does everyone who runs an OTP server also serve an address lookup service at the API /otp/geocode? That could be a solution.

[barbeau]

Thanks @bikeoid! Good to know about MapQuest - just opened a new issue for that - #479.

Historically I believe the OTP geocoder has always been optional - you didn't have to deploy it with the webapp. And, IIRC, the geocoder was actually ditched in more recent versions of OTP - I believe it no longer exists in the master branch. At USF we're actually running two versions of OTP side-by-side to run the more recent master branch for main web client/server along with the older version for the geocoder. If it re-emerges as a standard part of main OTP project I'm definitely open to adding that geocoder option.

So, the immediate path forward for us in OTP Android is to re-enable the Android geocoder (which IIRC is essentially reverting #406 and #408), and fixing MapQuest Nominatim (#479).

[barbeau]

Alright, both the Android and MapQuest geocoders should now be fixed. I just pushed v2.1.4 to Google Play with these fixes, so it should be rolling out soon. Please take a look when you get the update to make sure everything is working as intended.

Thanks to everyone for their patience dealing with these bugs!

[bikeoid]

It worked here. Thanks!

[afotest]

When i use geocode in android device so in that case some device in properly work or some device in not work, Tell me about my device i am using Lenovo vibe k4 note in that case geocode get Latitude and Long value get but not nevigate in next activity so how can i resolved it ?

Also GPS on then after not proper work so what i should do ?