[OSM-talk] Tiles at Home client update
jdsmobile at gmail.com
Sun Mar 4 13:45:02 GMT 2007
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.
> 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
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
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
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
More information about the talk