Modify

Opened 9 years ago

Closed 9 years ago

Last modified 9 years ago

#11255 closed enhancement (fixed)

[PATCH] Tiling approach to WMS layers

Reported by: wiktorn Owned by: team
Priority: normal Milestone: 15.08
Component: Core imagery Version: latest
Keywords: WMS Cc: bastiK

Description

Currently, WMS layers has it's own tiling mechanism and it's own cache mechanism, which - in my opinion is apparently less robust than TMS layer. TMS layer has a mechanisms to use tiles from different zoom level to draw current zoom level, if they are available.

I did some Proof Of Concept, where I implemented WMS layer as extension of TMS layer, which overrides the TileSource class and implemented there conversion from tile numbers to X,Y for WMS:

        EastNorth ne_en = Main.getProjection().latlon2eastNorth(new LatLon(tileYToLat(tiley, zoom), tileXToLon(tilex+1, zoom)));
        EastNorth sw_en = Main.getProjection().latlon2eastNorth(new LatLon(tileYToLat(tiley+1, zoom), tileXToLon(tilex, zoom)));

If we would go this way, we could leverage the same cache mechanisms as for TMS, get far more better caching (as we are always requesting the same bbox'es).

This could also be a step forward to support WMTS imagery.

Shall I continue working on such patch, or there is some functionality that I'm not aware of, that we will be missing with this approach

Attachments (1)

wms_jcs_cache.patch (285.8 KB ) - added by wiktorn 9 years ago.

Download all attachments as: .zip

Change History (18)

comment:1 by stoecker, 9 years ago

Hmm, that would fix WMS to TMS zoom steps, which probably is not a good idea. You'd need to find a way, that the user-selectable deepest zoom step does not vanish. Otherwise we'll get complaints.

OTOH unifying these two and handling WMS in JMapViewer would be a worthy goal.

Maybe the Auto-zoom variant could be TMS-based and the fixed-zoom variant using freely choosable zoom depth.

comment:2 by bastiK, 9 years ago

Agree with stoecker, it would be fine if the default mode (auto-zoom) was using TMS zoom levels. But some users may want to request images at a specific scale.

comment:3 by wiktorn, 9 years ago

I'm not sure if I'm following you. You mean that user might select arbitrary PixelPerDegree to work with? How do I achieve it right now?

As I understand, right now we can lock the zoom level on WMS layer, but still - it was one of PPD, that JOSM provided. If I would honour maxzoom specification the same way as for TMS and add no-auto-zoom functionality, as it is now for WMS - would it be sufficient?

in reply to:  3 comment:4 by stoecker, 9 years ago

Replying to wiktorn:

I'm not sure if I'm following you. You mean that user might select arbitrary PixelPerDegree to work with? How do I achieve it right now?

Turn off auto-zoom, zoom to a specific zoom-depth and right click on the layer and select zoom level readjustment.

comment:5 by wiktorn, 9 years ago

So as far as I checked, WMS layer has 2x more zoom levels as TMS.

But to make progress in small steps, I'd like to start with implementing auto-zoom toggle and zoom level readjustment in TMS, once this is ready and works as expected, then I'd introduce the change to make WMS layer as extension of TMS layer.

in reply to:  5 ; comment:6 by stoecker, 9 years ago

Replying to wiktorn:

So as far as I checked, WMS layer has 2x more zoom levels as TMS.

But to make progress in small steps, I'd like to start with implementing auto-zoom toggle and zoom level readjustment in TMS, once this is ready and works as expected, then I'd introduce the change to make WMS layer as extension of TMS layer.

You mean fixing the zoom level to a certain degree for TMS? Is this useful?

in reply to:  6 comment:7 by wiktorn, 9 years ago

Replying to stoecker:

You mean fixing the zoom level to a certain degree for TMS? Is this useful?

Yes, that's what I mean. I'm not sure if it's useful, but I guess that the use case would be the same as for WMS. I would use current extra functionality of WMS layer to avoid unnecessary downloads of other zoom levels, as this improves performance. Once I have all TMS functionality, I do not need those.

So to keep our users happy, I'd leave them this functionality, though I find it of little usefulness. But maybe I'm missing something.

by wiktorn, 9 years ago

Attachment: wms_jcs_cache.patch added

comment:8 by wiktorn, 9 years ago

Summary: Tiling approach to WMS layers[PATCH] Tiling approach to WMS layers

As this is a major change, I'd like first to let everybody review this patch, before I'll commit this into the trunk.

I plan to commit this patch after upcomming freeze on 31.05. This is too big change in my opinion, to commiting it right now.

What's done:

  • move most of TMSLayer to AbstractTileSourceLayer - this is shared functionality between WMS, TMS, and upcoming WMTS
  • "Precache imagery along GPX track" works for both - TMS Layer and WMS Layer
  • Saving WMS and TMS layer also should work. I took some effort to also support current file format
  • autozoom, autoload, show errors, show tile info - all integrated within AbstractTileSourceLayer

I decied that TemplatedWMSTileSource will go to josm tree, not to JMapViewer, as it's too much dependant on JOSM code. The same will be with WMTS, where there is a need to use Projections.

Code is also available at my GitHub repo:
https://github.com/wiktorn/josm/tree/wms_jsc_cached_imagery_new

Last edited 9 years ago by wiktorn (previous) (diff)

comment:9 by wiktorn, 9 years ago

Milestone: 15.06

comment:10 by Don-vip, 9 years ago

Milestone: 15.0615.07

skip milestone 15.06

comment:11 by wiktorn, 9 years ago

Resolution: fixed
Status: newclosed

In 8526/josm:

Introduce WMS layer based on TMS. (closes: #11255)

HEADS UP: After this patch you need to manually remove JAX-B generated file/class: org/w3/_2001/xmlschema/Adapter1.java to compile the tree again.

  • create AbstractTileSourceLayer based on TMSLayer as a base for TMS, WMS and (future) WMTS layers, (addresses #11459)
  • WMS layer now uses JCS Caching (closes: #7363)
  • introduce new conversion methods in TileSource, that convert both X and Y (lat and lon) in one call. This is necessary for other than PseudoMercator projections
    • introduce TileXY class that represents X and Y indexes of tile in tile matrix/space
    • mark old conversion methods as deprecated
    • refactor JMapViewer and JOSM to new methods
    • change use of Coordinate class to ICoordinate where appropiate
  • extract CachedAttributionBingAerialTileSource to separate file
  • create TemplatedWMSTileSource that provides the WMS Layer with square (according to current projection) tiles (closes: #11572, closes: #7682, addresses: #5454)
  • implemented precaching imagery along GPX track for AbstractTileSourceLayer, so now it work for both - WMS and TMS (closes: #9154)
  • implemented common righ-click menu on map view, as well on layer list (closes #3591)
  • create separate build commands for JMapViewer classes to easily spot, when josm classes are used within JMapViewer
  • remove unnecessary classes of previous WMS implementation - GeorefImage, wms-cache.xsd (and JAXB task from build), WMSCache, WMSRequest, WMSGrabber, HTMLGrabber, WMSException

comment:12 by Don-vip, 9 years ago

In 8527/josm:

see #11255 - remove JAXB parameter unused since r8526

comment:13 by Don-vip, 9 years ago

In 8528/josm:

see #11255 - remove references to imagery/types folder deleted since r8526

comment:14 by Don-vip, 9 years ago

In 8529/josm:

see #11255 - remove JAXB stuff unused since r8526

comment:15 by Don-vip, 9 years ago

In 8530/josm:

see #11255 - checkstyle/findbugs

comment:16 by Don-vip, 9 years ago

In 8531/josm:

see #11255 - remove last JAXB stuff

comment:17 by Don-vip, 9 years ago

Milestone: 15.0715.08

Milestone renamed

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The owner will remain team.
as The resolution will be set.
The resolution will be deleted. Next status will be 'reopened'.

Add Comment


E-mail address and name can be saved in the Preferences .
 
Note: See TracTickets for help on using tickets.