Support direct tile access for slippy map like services

[avarab@…]

I thought WMSPlugin was slow when I viewed an area with it in JOSM, as it turns out it was requesting around 60! zoom 18 tiles to get & display an area to me that looks to be covered by 4 z18 tiles on the OSM tileserver.

I'm attaching a log of the networksniffer I used and screenshots showing what I did, but basically I:

1. Zoomed into a very small (~ 50x50 meter) are in JOSM
2. Turned on WMSPlugin/OpenStreetMap
3. Logged network traffic
4. Blocked all HTTP traffic (so further request wouldn't be made)
5. zoomed out to see what tiles JOSM had requested

It turned out that it made 191 GET request to the tileserver to get 57 tiles, so it's getting each tile around 3 times or so:

avar@aoeu:~$ cat screenlog.3 | perl -pe 's/.*?(?=GET)//'|grep GET.*png|sort|wc -l
191
avar@aoeu:~$ cat screenlog.3 | perl -pe 's/.*?(?=GET)//'|grep GET.*png|sort|uniq|wc -l
57

All this to cover a ​very small area, just surrounding that playground there (the green area).

[avarab@…]

Log of GET requests from the tcpflow network sniffer

[avarab@…]

The initial zoom level of JOSM when I turned the WMSPlugin on

[avarab@…]

The display area WMSPlugin has to show for making 191 requests to get 57 tiles

[stoecker]

The problem is clear, that multiple requests aren't cached over different calls to the image downloader. So each call results in duplicated downloads.

[avarab@…]

Replying to stoecker:

The problem is clear, that multiple requests aren't cached over different calls to the image downloader. So each call results in duplicated downloads.

If it would properly cache things it would just make 57 requests instead of 191. The main problem is that it's making 57 z18 requests and then displays an area that's covered by 4 z18 tiles.

I haven't looked at the tile numbers in any detail, perhaps it got enough z18 tiles to display half the suburb I was looking at but then threw all the data away because I had such a small map viewing area.

In any case getting 57 tiles is obviously redundant for what it ended up actually displaying.

[stoecker]

Sure, the code very likely will load the whole area around the current position, so that moving the map does not result in missing tiles. We need to use a Javascript access which is not meant to be used for that purpose, so it is clear that the results will not be optimal.

[anonymous]

BTW. WMSPlugin will try 3 times if fetching a tile fails. That is why you got 3 times the requests when you blocked the http traffic. However, that's no reason fro the 57 instead of 4 requests.

I also noticed here that sometimes when adding a WMS layer, my tile server's logfile starts showing requests for one or two minutes before JOSM starts displaying any tiles. I always had the feeling that some garbage was requested, but as this only happened when adding a new layer, and not when panning around, I never investigated.

[stoecker]

Webkit-image downloader now supports caching. This should reduce this problem. Otherwise due to the general structure of our Yahoo support it is unsolvable.

We can add direct tile downloading instead of wms simulation for services, where this is allowed. On the other hand the slippymap plugin does this already. maybe these two should be joined.