[Tilesathome] Lowzoom Place Labels displaced

[Matthias Julius]

Sebastian Spaeth <Sebastian at SSpaeth.de> writes:

> Matthias Julius wrote:
>> Sebastian Spaeth <Sebastian at SSpaeth.de> writes:
>> 
>>> Yes. If we did proper projection, we could cut the number of inkscape 
>>> calls by a factor of 10. Cutting a full zoom level inkscape in 256x256 
>>> tiles rather than doing one y-stripe at a time would be beneficial (from 
>>> a render time perspective)
>> 
>> I was wondering about that, too.  For the 6th zoom level of a tileset
>> (z17 usually) this creates 8192 x 8192 pixel image which would be 256
>> MB of raw RGBA data for transparent layers.  Do you think the tile
>> splitter would digest that well?
>
> The tile splitter has no problem with that. It's rather inkscape 
> crapping out with these sizes and complex tiles. But then as inkscape 
> seems to load and render the complete svg anyway even if we are only 
> interested in a small stripe, it wouldn't make a different memory wise 
> to what we have now.
>
> But generally doing striped calls should be what we do on complex 
> tilesets, while easier ones can be rendered in one go. I had a local 
> modification (which might still be around) which showed that the render 
> time was proportional to the number of times we called inkscape. So this 
> would translate in *real* savings.
>
> One needs to modify the SplitImageX routing to cope with multi-stripe 
> images.
>
> However, I stopped my experiments when it showed that z17 tiles were 
> moved about 1 tile when doing it in one go. I just don't know enough 
> about projections and the osmarender parallellogram approach to fix 
> these things.
I have actually tried that myself now.  Instead of calling RenderTile
recursively it is now doing the rendering in a loop.  And with the
elimination of the shortcut to avoid rendering empty tiles (I want all
tile files anyway for tileset files) this simplifies the code quite a
bit.

I have rendered a few test tiles including one in northern Norway and
did not notice any displacement at z17.  I will check a couple more
tiles before committing the code to SVN.  

If it is true that Inkscape always renders the whole SVG file then
there is probably no benefit rendering in stripes.

GD knows a method trueColorToPalette() which is supposed to convert
the image to a palette based one.  After this colorsTotal() corectly
reports 256 colors, but when it is written to a file this file has 24
bpp.  Does anyone know a fix for this?

Matthias