Re: [Merge request] New map source infrastructure

[Jiří Techet <techet gmail com>]

OK, done. I had to modify MemphisMapSource much more than I originally
expected and basically took your branch and (with a great help of
kdiff3) merged my changes with it and made all extra necessary changes
(so it was a very manual --onto ;-). So now it appears as a single
commit because I wasn't able to preserve the git history.

There are two issues remaining:

Memphis doesn't indicate when a tile cannot be rendered because of
missing vector data for that area and generates empty tile. This
however means that a chain like

MemphisMapSource -> NetworkTileSource

won't work as expected (i.e. to load tiles from network from the areas
for which we don't have vector data). I plan to file a bug report for
this.

The second issue is it that I'm not quite sure now what the factory
should return when you create a map source. Before it was a map source
together with cache (plus error tile was drawn when the tile couldn't
be loaded). Now we have 3 separate map sources for all these things
(FileCache, NetworkTileSource, ErrorTileSource). We have two options
what to return now:

1. A complete chain FileCache->NetworkTileSource->ErrorTileSource -
the main disadvantage is that user applications will see the chain as
a whole but it won't be possible for them to change properties of the
sub- map sources individually (this is particularly problematic with
MemphisTileSource).

2. Only the requested map source. This however means that users have
to create the chain manually. Also if they upgrade to 0.6 without
reading the documentation, there will be millions of questions like
"why isn't the map source cached any more?" (because it'll create
NetworkTileSource only without any cache).

Despite the incompatibility with previous libchamplain versions, I
tend to prefer the second solution. The first one hides everything
from the user, which might cause problems like when the user is
casting the map source to e.g. NetworkTileSource (because he thinks
that he uses this source), but in fact the source is the complete
chain. I changed the demos to use the second approach so you can see
what needs to be changed in the client applications (see
launcher-gtk).

Unless you have some interface-related comments to my patch, I'll
start documenting it and after this is done, I plan to optimize the
cache a bit.

Thanks,

Jiri

(By the way, the problem why the local rendering demo wasn't running
before was the change of MapSource base class to InitiallyUnowned -
the demo just unref()ed it after passing to view which destroyed it
because it was just sink()ed by the view.)


On Thu, Jan 14, 2010 at 14:30, Pierre-Luc Beaudoin
<pierre-luc pierlux com> wrote:
> On Thu, 2010-01-14 at 13:52 +0100, Jiří Techet wrote:
>> can I use your local rendering branch as a base for
>> my merge (i.e. aren't you going to do some new merge/rebase that would
>> then complicate merge of my branch)?
>> If you put the additional fixes
>> that make it working on top of it it should be no problem to merge
>> them back to my work. Also should I rebase my branch on top of it or
>> use ordinary merge?
> Yes use it, but if you do please don't remove the branch, just rebase
> yours on top.  git is pretty intelligent and allows rebranching. :) (see
> the git rebase --onto examples in the man pages)
>
> Pierre-Luc
>