[OSM-talk] Tiles at Home client update

[J.D. Schmidt]

Jochen Topf skrev:
> On Sun, Mar 04, 2007 at 12:25:10AM +0100, J.D. Schmidt wrote:

>> We found the culprit who shall remain unamed (Just buy me a couple of 
>> beers at SOTM sxpert.. :D), who generated the bad renderings,
>> Looks like there's an issue with Gentoo on AMD64 boxes. Bad mathlibs, 
>> rounding errors in the underlying routines called by Math::Vec, or 
>> something of that kind.
>> So far it seems that only Gentoo AMD64 boxes are affected. No errors on 
>> Ubuntu AMD64 boxes (and probably not on any other Debian deriatived 
>> AMD64 distros).
>>
>> I've changed the Bangkok client to include a config option "NoBezier" 
>> which when set to 1 in the tiles at home.conf file will render without the 
>> beziercurve hinting.
>>
>> If you are using Gentoo on an AMD64 architecture, please upgrade to SVN 
>> revison 2200.
>> Other users do not need to upgrade, unless they want to render without 
>> bezier curve hinting.

> 
> Do I understand this correctly: There is now an option in tiles at home
> deciding whether you want to render with or without bezier curves.

Yes.

> every client can decide which rendering he wants. 

Yes, although a client should not enable NoBezier, unless he has the 
following problems :
A) Tiles generated with errors like the ones described in Kristians 
post, and which has been identified as happening on AMD64 boxes running 
Gentoo.
B) Persons who for some reason can't get Math::Vec installed, but still 
want to participate in the T at H project.

> So some clients will
> render their pieces of the map differently from others

Yes, just like today, where people are running a mixture of clients 
version. If you look at the Log page, you can see both Agadir, Athens 
and Bangkok revisions running.

> leading to
> problems at tiles boundaries 

Those problems do NOT arise from the Beziercurve hinting used. Think it 
over..

The beziercurve hinting does NOT change the position of the endpoint of 
any ways. Therefore the endpoint at the edges of the tile will be at the 
exact same point as if they were rendered without the Beziercurve 
hinting. I'm putting up an example page on the wiki under the 
tiles at home/problems page, which shows two neighbouring tiles rendered 
with and without Beziercurvehinting.

It REALLY is a Non-Issue.
(Or as they say here in Copenhagen at the moment : Move along folks, 
nothing to throw stones at.)


 > and to strange "yesterday it looked
 > different" problems.

That is again not due to the Beziercurve hinting. But due to the fact 
there are different client versions running, using different stylesheets.

The Beziercurve hinting is just that, a subtle hinting that smooth out 
sharp bends into curves. On zoom level 12, it's hardly possible to see 
it, on higher zoomlevels it gives the roads a more pleasing look. The 
only way you can see a difference on the slippymap is when zoomed in to 
zoom level 15 and beyond, and happen to look at a boundary where there 
are a curve in a road. And then you still need to look closely, to see 
the difference, which is only in the esthetics of the render, not in the 
actual lineup of the tiles.

So again, having the option of enabling beziercurve hinting is still a 
non-issue IMHO.
Why ?
Because most of the T at H renderers running the Bangkok revision will be 
running with Beziercurve hinting on, as it is the default.
Those few who will run without Beziercurve hinting, will have their 
tiles re-rendered at some other time anyways, since we aren't doing a 
static map, but a dynamically updated map.


> 
> Or did I misunderstand you? What does that option do?

You didn't misunderstand me, nor what the option do. You just 
misunderstod the ramifications of the Beziercurve hinting. Whether its 
because you got some beef with it being implemented this way, or whether 
its because you didn't understand how the Beziercurve hinting affects 
the data in the tile, I really can't say.

But if it's the former, due to it being implemented now, instead of 
sending it through a plenum session and 24 subcommitees, then just 
remember : OSM isn't a Democratic project as in everybody has to sign of 
on things implemented, it's more like an Anarchy with some overseers.

If someone has an idea, implements it and it works, then feel free to :
A) use the idea as implemented
B) don't use it as implemented
C) bitch about it being implemented differently than you wished for
D) or implement a better way of doing it

Instead of choosing option C, which is the only NON-CONSTRUCTIVE option 
of the four, go ahead and do option D. I ain't stopping you, and I don't 
think anybody else will, since thats the Anarchy effect mentioned above 
coming into play.

If, or rather WHEN someone comes up with a better implementation, using 
the OSM raw data, or transforming the OSM DB to polylines, or something 
completely different, then I'm sure people will use that instead.

Untill then all I can say is "Caveat Emptor, there is a solution that 
works NOW, and lets everybody participate in T at H, on the table."



J.D. "Dutch" Schmidt