[OSM-talk] Tiles at Home client update

Frederik Ramm frederik at remote.org
Sun Mar 4 23:57:24 GMT 2007


Hi,

> Well, I'm sure that wouldn't happen, since IMHO T at H, O at H and Osmarender 
> are different projects.

Yes, but T at H is IMHO the most prominent user of Osmarender, so there's a 
close relationship and I surely expect Osmarender developers to refrain 
from making changes that would render T at H incompatible!

> Again, I say it is a Non-Issue. The beziercurve hinting has been 
> implemented this way, people have an option of using it or not. 

I agree with you that the differences are minuscle, and the probability 
of visible ugliness at the edge between two tilesets is small, and if 
the ugliness occurs, it isn't that bad. (Probably less bad than the 
white stripes that only recently have been fixed and which we more or 
less all shruggingly accepted.)

But still, at the heart of this "non-issue" lies the question: Is it ok 
to introduce arbitrary stuff to T at H which changes the resulting look, 
make it configurable and then say: "people have an option of using it or 
not"? The answer, surely, must be no!

> At the 
> moment it looks like it is being used by the majority of the T at H 
> renderers, and probably with beziercurve hinting enabled on all except 
> one client (sxperts), since that is the default. Actually I currently 
> only see one Agadir client, while the rest are Bangkok clients, on 
> http://dev.openstreetmap.org/~ojw/Log/ which means that around 7 clients 
> + my 3 dual-cpu clients = 13 clients generate beziercurvehinted tiles, 
> vs 2 clients that doesn't.

I think there are a total of 50 or 60 renderers, not all of them being 
up all the time. But as with all "non-issues" that result in discussion, 
it is less about the practical impact... your numbers say that 15% of 
clients don't use the new feature. Now if I were to introduce another 
optional (or non-working-on-some-platforms) feature which would also be 
used by 85%, then we'd have a further split, and soon every single 
renderer would have his or her personal combination of little layout 
tweaks... yes I know, it's a typical "think what happens if anyone did 
that" line of reasoning, but still there's a grain of truth.

> If others can't live with that, then they should come up with, AND 
> implement a better solution.

Others *might* just say that the overall situation was better before - a 
little less quality when individual tiles were viewed, but better 
quality (due to consistency) of the map as a whole.

> It all boils down to : Do we want the beziercurve hinting now with the 
> current minor flaws, or do we want to wait an undetermined period of 
> time, untill there has been developed a better method ?

And exactly that is the question that - next time something similar 
happens - I'd ask and discuss on the list, BEFORE making the change to 
tiles at home and asking everybody to update their clients.

> When it turned out to be easy to make it work together (2 hours where 
> most where spent learning the perl syntax), and worked great on the O at H 
> client after Barry had squashed two bugs in the lines2curves.pl script, 
> I mentioned that it would be nice to have in T at H on IRC.
> 
> Again Oliver said go for it.

I am not into O at H but as far as I understand, with O at H there's always 
exactly one renderer doing one map, so you always have consistency. So 
with O at H it is really no problem at all.

> IMHO Oliver (whether he likes it or not) is one of the "Anarchy 
> overseers" when it comes to T at H and O at H, just like I see Jochen as one 
> of the "Anarchy overseers" of Osmarender, and Artem as one of the 
> "Anarchy overseers" of Mapnik.

> If he says go for it, then IMHO I'm good to go.

Well. Yes. No. Sometimes my little son comes asking whether I'd allow 
him to do something, and I'm about to say "why, yes, of course", when 
suddenly I remember that I might just ask his mother whether by chance 
there has been some discussion with her and for some reason she said 
no... it may be difficult to be an "Overseer" if you don't have the full 
context.

Firstly, Oliver may not have fully considered the fact that the 
difference between O at H and T at H might have side effects here; secondly, 
at the time you were speaking to Oliver, it was probably not yet known 
that compatibility problems would lead to incompatible rendering for the 
unforseeable future, instead of just minor "glitches" where old tiles 
meet new tiles for a few days. Thirdly, Oliver might not have been aware 
that the solution proposed by Barry was considered too hackish by some.

(I am not too involved here, it's just that when I did the Osmarender4 
for T at H stuff, Barry asked me whether we should put Bezier stuff in 
there, and remembering that Jochen said he was in discussion with Barry 
about this, I thought it might be better for them to find a good 
solution and then somehow put that "into Osmarender" for all projects to 
use, instead of deploying it individually. Technically, I was hoping for 
a pre-processing step instead of a post-processing step, where 
coordinate transformation, bezier hinting and some more input data 
valuable to Osmarender would have been computed on the basis of the OSM 
file, and then Osmarender would process that file and output a finished 
SVG. I had done some promising work on the coordinate transformation 
step, leading e.g. to Osmarender being able to render other projections 
than Mercator and removing the inherent Osmarender projection inaccuracy 
(which also is one of the non-issues as it boils down to a few pixels on 
the highest zoom levels). But I have no idea if putting the bezier stuff 
in there would have been practical at all.)

Well. Let us, as you said, move on and not throw any stones around.
Let's leave the bezier stuff in now and try to fix that Gentoo issue 
(maybe at least one could put a check in tahconfig.pm that does whatever 
computation is broken with the Gentoo Math::Vec, checks the result and 
when it finds it is broken, just says "please switch off bezier hinting" 
and quits?). And let us have a little bit more public discussion before 
we make such changes to T at H in the future... perhaps on dev, not talk? 
Or, like OJW did with his Tiles-from-Files stuff, write proposals on 
Wiki pages and give people a few days to comment. Whatever.

I can understand that IRC is very "hands-on" friendly, a medium for 
getting things done on short notice, but I dislike the fact that 
discussions on IRC are not archived. I often hear "we had that 
discussion on IRC", and unless someone takes the time to write a summary 
to the list, I'm just excluded if I wasn't on IRC at the time.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frederik at remote.org  ##  N49°00.09' E008°23.33'




More information about the talk mailing list