Opened 13 years ago
Closed 13 years ago
#7872 closed enhancement (fixed)
adjustable tile size for wms
| Reported by: | Cobra | Owned by: | team |
|---|---|---|---|
| Priority: | normal | Milestone: | |
| Component: | Core | Version: | |
| Keywords: | Cc: |
Description
The tile size for WMS layers is hardcoded to 500x500px (see source:trunk/src/org/openstreetmap/josm/gui/layer/WMSLayer.java#L111)
This is quite small, especially on large screens. A maximised josm window on 1920x1080 takes about 6 tiles.
This causes some issues for services with large watermarks which are to be included only once per (larger) view.
This also slows josm down. Waiting for all the tiles to arrive takes some time for slow servers. The server load might also increase.
I suggest to make the tile size configurable, at least via the "advanced settings" tab, better on the wms/tms tab.
Another option could be to make the tile size adapt to the current window size so that there is only 1 tile visible until the user zooms or pans the map view.
Attachments (1)
Change History (6)
follow-up: 2 comment:1 by , 13 years ago
follow-up: 3 comment:2 by , 13 years ago
Replying to bastiK:
Replying to Cobra:
The tile size for WMS layers is hardcoded to 500x500px (see source:trunk/src/org/openstreetmap/josm/gui/layer/WMSLayer.java#L111)
This is quite small, especially on large screens. A maximised josm window on 1920x1080 takes about 6 tiles.
I think 500x500 is a reasonable choice, 6 tiles for one screen seems not too much for me.
I've made a quick hack and tested the default 500x500, 800x800 and 1000x1000. 500x500 was the slowest, 800x800 resulted in a quite nice performance, both when adding the layer and while panning.
This causes some issues for services with large watermarks which are to be included only once per (larger) view.
If there are large and annoying watermarks on the images, this is probably intended by the data provider. If you really want to circumvent this protection, we cannot stop you, but we don't have to make this particularly easy either.
This is explicitly not intended as circumvention of any protections. But I have seen WMS which were designed for larger map views showing a single attribution line at the bottom where it doesn't disturb the user. Loading a lot of small images resulted in having this attribution line cluttering the map view (instead of a single line as intended).
This also slows josm down. Waiting for all the tiles to arrive takes some time for slow servers. The server load might also increase.
The tiled approach has the advantage, that you can see the parts that have been loaded completely and don't need to wait for one large (several MB) request to finish.
I suggest to make the tile size configurable, at least via the "advanced settings" tab, better on the wms/tms tab.
Another option could be to make the tile size adapt to the current window size so that there is only 1 tile visible until the user zooms or pans the map view.
This is impractical for multiple reasons: First, if you pan only 20% of the screen, you don't want to download the entire screen again, but only the new parts. This may seem easy, but e.g. even PL 2 had not implemented this "intelligence" for map data downloads until recently. Second, irregular image requests make caching much more complicated.
In short: Departing from the tile approach makes things for the developers significantly more complex and for this cost there should be a major benefit, but I can't see this benefit at the moment.
I do want to keep the tiled approach. That is definitely the best way to do it. The only thing I'm suggesting is a possibility for changing the size of the tiles.
I think you have misunderstood "single wms tile per map view" proposal. I really don't want to replace the currently loaded image by a new one - this is what annoys me most when using other applications. My idea was to set the tile size to the size of the map view only once when adding the wms layer. It's still tiled and won't load anything which has already been loaded. But after having a look at the existing code, I think this would be too much effort.
I have added a new property imagery.wms.imageSize and got that working so far. I can post that simple patch if desired.
This patch will definitely break the ability to save wms layer to a file, because the image size isn't saved and it's assumed to be the default 500x500px. Also, there is no possibility to handle different image sizes (user set it to 600x600 while opening a file with 500x500). But it doesn't even work as intended with the plain vanilla josm-latest. Is this feature used by anyone? I couldn't find any tickets for this.
comment:3 by , 13 years ago
Replying to Cobra:
Replying to bastiK:
Replying to Cobra:
The tile size for WMS layers is hardcoded to 500x500px (see source:trunk/src/org/openstreetmap/josm/gui/layer/WMSLayer.java#L111)
This is quite small, especially on large screens. A maximised josm window on 1920x1080 takes about 6 tiles.
I think 500x500 is a reasonable choice, 6 tiles for one screen seems not too much for me.
I've made a quick hack and tested the default 500x500, 800x800 and 1000x1000. 500x500 was the slowest, 800x800 resulted in a quite nice performance, both when adding the layer and while panning.
This probably depends heavily on the network and connection you are using. Google Maps, OSM and other TMS choose a significantly smaller tile size of 256x256, I suppose there are reasons for this.
I think you have misunderstood "single wms tile per map view" proposal. I really don't want to replace the currently loaded image by a new one - this is what annoys me most when using other applications. My idea was to set the tile size to the size of the map view only once when adding the wms layer. It's still tiled and won't load anything which has already been loaded. But after having a look at the existing code, I think this would be too much effort.
Yes, misunderstood you there.
I have added a new property imagery.wms.imageSize and got that working so far. I can post that simple patch if desired.
In principle, it is good to have the tile size user configurable, but it's still a niche feature. I'd prefer a patch that is not just a proof of concept, but makes it work mostly.
This patch will definitely break the ability to save wms layer to a file, because the image size isn't saved and it's assumed to be the default 500x500px. Also, there is no possibility to handle different image sizes (user set it to 600x600 while opening a file with 500x500). But it doesn't even work as intended with the plain vanilla josm-latest. Is this feature used by anyone? I couldn't find any tickets for this.
Apparently broken at the moment, but should work.
comment:4 by , 13 years ago
As I mentioned, saving and loading wms layers isn't yet changed, WMSLayer.imageSize is still present and used by WMSLayer.LoadWmsAction and WMSLayer.SaveWmsAction.
Besides that I consider it finished.
by , 13 years ago
| Attachment: | wmsTileSize-0.patch added |
|---|
patch for adjustable wms tile size, breaks saving and loading wms layers from/to files
Replying to Cobra:
I think 500x500 is a reasonable choice, 6 tiles for one screen seems not too much for me.
If there are large and annoying watermarks on the images, this is probably intended by the data provider. If you really want to circumvent this protection, we cannot stop you, but we don't have to make this particularly easy either.
The tiled approach has the advantage, that you can see the parts that have been loaded completely and don't need to wait for one large (several MB) request to finish.
This is impractical for multiple reasons: First, if you pan only 20% of the screen, you don't want to download the entire screen again, but only the new parts. This may seem easy, but e.g. even PL 2 had not implemented this "intelligence" for map data downloads until recently. Second, irregular image requests make caching much more complicated.
In short: Departing from the tile approach makes things for the developers significantly more complex and for this cost there should be a major benefit, but I can't see this benefit at the moment.