BruTileLayer for SharpMap?

Feb 11, 2010 at 9:28 AM

Hi,

First of, BruTile is amazing - great piece of work! I noticed in a previous posting that you were working on a BruTileLayer to replace the TiledWmsLayer in sharpmap? I am very interested in this and was thinking of doing the same thing. Do you have/could you make the source code available?

Cheers,

Kev.

Coordinator
Feb 11, 2010 at 4:18 PM

Hi Kevin,

Good to hear you want to participate, and I saw you already contributed to the SharpMap SqlLite provider.

The BruTileLayer is actually almost finished. I already used it in a project. So, I really should check it into SharpMap. From that point you migth be able to contribute, but I am not sure what else should be done to the BruTileLayer . There is lots of other stuff that needs to be done though.

To get involved you could also join the IRC channel
http://sharpmap.codeplex.com/wikipage?title=IRC%20chat&referringTitle=Home

Paul.

Coordinator
Feb 13, 2010 at 12:28 PM

I committed a version to SharpMap, maybe you can take a look

http://sharpmap.codeplex.com/SourceControl/list/changesets

Paul

Feb 13, 2010 at 12:58 PM

Thanks very much.

Just had a quick look at the code. I will have a proper look next week! It certainly gives me something to play with. I did wonder if there was a way of implementing some kind of feedback system (like in the BruTile samples) whereby instead of waiting for all the tile threads to return, the map would be re-rendered as each tile is fetched until all the tiles are available in the cache. In the projects where we use sharp map, we cache all the layer bitmaps anyway so as long as they haven't changed, a redraw is quite cheap.

While it may seem like it would make more sense to use a 'pure' BruTile solution for this, a SharpMap solution would enable existing SharpMap projects, that overlay data from a number of sources, to work with BruTile tile providers for base mapping layers.

Just a thought. Anyway, look forward to trying this out soon!

Cheers

Kev.

Developer
Feb 13, 2010 at 8:43 PM

Thanks Paul, and now for v2 ;-)

Cheers

FObermaier

Coordinator
Feb 14, 2010 at 11:01 AM
Edited Feb 14, 2010 at 11:22 AM

Hi Kev.,

I started off on that road with SharpMap 2 years ago, and got it working to some extend, but started building BruTile.UI to do it properly. Currently BruTile.UI leans heavily on tiling but I would like to transform it into a more general solution, with async data retrieval as its basic mechanism. Tiling should be just one possible caching strategy. BruTile.UI will have to move to another repository anyway since SharpMap now uses BruTile and BruTile.UI uses SharpMap:

BruTile <- SharpMap <- BruTile.UI

In BruTile.UI the fetching and the rendering are separated so that rendering is always fast. In SharpMap those are combined in a single Render update, so rendering could take a while, depending on what kind of Layer type you have, and how much data is in it. We could split off the tile fetching to an async process, but that will be an half solution because other long processes will still be in the render update. 

If I were to improve the user experience of SharpMap I would move the Render+Fetch method to a background thread - lets call it RenderWorker -and let it render to a buffer bitmap of which the extent is also stored. The OnPaint in the MapControl only renders this buffer taking into account the difference between the MapControls extent and the buffers' extent. This OnPaint will be very fast, so the user always sees an immediate effect of its' actions. However, since the buffer could lag behind on the current MapControls' state, it will not fill the entire screen during panning and zooming. On every pan and zoom action an ViewChanged message is sent to the RenderWorker. If the RenderWorker is idle it will start its Render, if it is busy it will postpone redraw untill after the current Render. If a render update is complete a DataChanged message is sent to the MapControl which allows it to redraw.

Actually this is how BruTile.UI works, with the difference that there is always only 1 tile, i.e. the buffer. Currently there is no background rendering in BruTile.UI but it will be at some point. Above solution is like this picture but with Fetcher replaced by RenderWorker and MemoryCache with Buff

BTW, did you look at the SharpMap sample in BruTile.UI.Wpf?. It also uses the SharpMap.Map object, so all SharpMap Layer types can be used. What kind of functionality are you missing from a solution like that? With TileLayers in SharpMap you could have that kind of performance, and tiles in the background and SharpMap features on top of it.

Paul

 

 

 

Coordinator
Feb 14, 2010 at 11:07 AM
fobermaier wrote:

Thanks Paul, and now for v2 ;-)

Cheers

FObermaier

aiai, yes, I really should get into V2! With your GDAL raster as an example it should now be easy :)

Paul

Feb 15, 2010 at 3:49 PM

Works like a treat thanks.

I also had a look at the SharpMapTileProvider. I think this would work well for our purposes in the most part and that's probably the route i would go down if we ever get to make any major changes :)

Cheers

Kev.