[OSM-talk] Tiles at Home client update

Jochen Topf jochen at remote.org
Sun Mar 4 16:30:18 GMT 2007


On Sun, Mar 04, 2007 at 02:45:02PM +0100, J.D. Schmidt wrote:
> Jochen Topf skrev:
> >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.

Which is also a problem. Everybody should use the same renderer. Of
course there is some overlap until everybody has moved to the new
version. Thats ok, because we are not re-rendering the whole world each
time we change the code anyway. But old code and old tiles should eventually
be worked out of the system by itself. Now, for the first time, you have
created an incompatibility that will potentially last forever. Thats
what I am objecting to.

> >leading to
> >problems at tiles boundaries 
> 
> Those problems do NOT arise from the Beziercurve hinting used. Think it 
> over..

Actually they do.

> 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.

This might be true for a point sitting directly on the boundary. But in
the general case the point is not directly on the boundary so this
*will* lead to rendering problems.

> 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.

See above.

> 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.

Nobody said that is was in the lineup of the tiles.

But I see that you see my point which is exactly what you say here.
There is a difference which affects "the esthetics of the render". And
thats the whole point. I want the map to look beautiful, I assume you do,
too. So I don't like this little "difference" and you don't care about
this difference, because it is too small for you. Well, I do care. And I
assume other do, too. (If it was that small we didn't need Bezier curves
in the first place.)

> 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.

No need to get personal. Have you considered that I might know a thing
about how all of this works and my reason for bringing up this topic is
that I care about nice looking maps?

Jochen
-- 
Jochen Topf  jochen at remote.org  http://www.remote.org/jochen/  +49-721-388298





More information about the talk mailing list