ganzo55 / osmdroid

Automatically exported from code.google.com/p/osmdroid
0 stars 0 forks source link

Send a better user-agent when downloading tiles #515

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
The default Apache HttpClient user-agent was recently banned from accessing 
tile.openstreetmap.org (server returns 403). As a result, the Mapnik provider 
is no longer serving any tiles for osmdroid.

OpenStreetMap's tile usage policy ( 
http://wiki.openstreetmap.org/wiki/Tile_usage_policy ) says that a "Valid 
User-Agent identifying application" must be sent. The current user-agent 
osmdroid sends when it downloads a tile is "Apache-HttpClient/UNAVAILABLE (java 
1.4)" which is pretty generic.

I've created a patch that will send a user-agent that is more compliant with 
OSM's tile usage policy. The new user-agent is "osmdroid ([package name])" 
where [package name] is the package name of the application using osmdroid.

The patch can be found here: http://pastebin.com/kxBh1gQ5

The patch is not very pretty, but it does its job.

Original issue reported on code.google.com by sto...@gmail.com on 20 Jan 2014 at 1:24

GoogleCodeExporter commented 8 years ago
Issue 516 has been merged into this issue.

Original comment by kurtzm...@gmail.com on 20 Jan 2014 at 5:21

GoogleCodeExporter commented 8 years ago
This issue was updated by revision r1401.

Add user-agent field to TileSource.
Set proper user-agent for some tile sources like Mapnik.
Added createHttpClient() method to MapTileDownloader.

Original comment by kurtzm...@gmail.com on 20 Jan 2014 at 5:34

GoogleCodeExporter commented 8 years ago
I think the proper way to implement this is to associate the user-agent with 
the TileSource (which define the "instructions" for how to pull tiles from the 
server). However, I think it's worth it to add a createHttpClient() protected 
method for overriding for further customization if needed.

We will probably post a new version soon.

Original comment by kurtzm...@gmail.com on 20 Jan 2014 at 5:39

GoogleCodeExporter commented 8 years ago
Hi,

May I ask why the change of aBaseUrl parameter from varargs to String[] ?

Best regards, Emux
https://play.google.com/store/apps/details?id=gr.talent.cruiser

Original comment by devemu...@gmail.com on 20 Jan 2014 at 7:03

GoogleCodeExporter commented 8 years ago
Sure - that was an intentional change. The problem is that the TileSource 
constructor parameters were taking a bunch of String arguments followed by a 
varargs String parameter(s). So if I add a new String parameter before the 
varargs parameter, then all existing TileSources would continue to compile 
without any error but now they would be incorrect since the first "url" would 
now be used as the User-Agent. By changing to String[] we force implementors to 
deal with the change and force them to address the new userAgent parameter 
(this also applies to any String parameters we add in the future). I hope that 
makes sense.

Original comment by kurtzm...@gmail.com on 20 Jan 2014 at 7:09

GoogleCodeExporter commented 8 years ago
This issue was updated by revision r1402.

Rolled back some of the previous changes. Instead of per-tile source 
user-agents, use a global one which better meets the definition/use of 
user-agent.
Added global user-agent to HttpClientFactory. Custom user-agents can easily be 
installed here at run-time.

Original comment by kurtzm...@gmail.com on 20 Jan 2014 at 8:35

GoogleCodeExporter commented 8 years ago
I rolled back some of those changes. By definition, the user-agent should be 
one value and not a per-tile source value. So instead we set the default 
user-agent in the HttpClientFactory (where it really belongs).

If you want to set a custom user-agent, then simply create your own factory for 
HttpClientFactory.

Finally, I left in the varargs to String[] change. If we want to add parameters 
to that class later it will be a problem and I feel like it's better to change 
it now.

Original comment by kurtzm...@gmail.com on 20 Jan 2014 at 8:41

GoogleCodeExporter commented 8 years ago

Original comment by neilboyd on 21 Jan 2014 at 8:34

GoogleCodeExporter commented 8 years ago
Issue 517 has been merged into this issue.

Original comment by neilboyd on 21 Jan 2014 at 8:36

GoogleCodeExporter commented 8 years ago
Fixed in release 4.1

Original comment by neilboyd on 25 Jan 2014 at 6:08