On Sun, Aug 10, 2008 at 10:14:04PM +0200, Frederik Ramm wrote: > Hi, > > Knut Arne Bjørndal wrote: > > It's a part of r9574, which includes a filter that or/p doesn't > > understand that makes osmarender xsl only print those labels for > > really large areas. > > Ok folks. Either you stop using or/p altogether or you at least give me > (or others working on or/p) some realistic chance to catch up.
Sorry, this was a simple case of me not thinking long enough before doing a commit. > In this case, you have changed the rules files and Osmarender/XSLT two > days ago, introducing a new mechanism that you knew or/p didn't have > (because it was, well, new). Not even a mention on the mailing list. And > no, I don't have a RSS feed on SVN commits. > > When that change was introduced, it was absolutely foreseeable that or/p > would create those huge labels, that then somebody would complain, and > that I would then be forced to fix that. Which is a rather sub-optimal > flow of information, don't you think? I certainly didn't intend for this to happen, and I wouldn't expect any or/p devs to sit around staring at the osmarender commit log jumping into action every time something changes. > I have commented out the "minsize" rules for the time being to avoid > further disfigured tiles. Good, I should have just done that myself, but didn't get to it. > To avoid problems like this in the future, I suggest to decouple > > /applications/rendering/osmarender6 > > from > > /applications/rendering/tilesAtHome/osmarender > > so that improvements to Osmarender/XSLT and its rules do not > automatically flow into [EMAIL PROTECTED], but instead only after there has > been a chance for or/p to catch up. Please don't, that will only make it more work to make most changes, which really can just go straight in without causing any problems for or/p or [EMAIL PROTECTED] I'd rather not see a system where we need to have a committee meeting before we can push a bugfix into osmarender. > If you are unwilling to grant this chance to or/p and instead insist on > dropping style changes into tilesAtHome that only work with the newest > Osmarender/XSLT that you deploy at the same time and which will break > or/p, then please stop using it, or if you prefer, make [EMAIL PROTECTED] use > or/p *exclusively* in which case whatever happens to Osmarender/XSLT > would become irrelevant. What I should have done with this change is to put the stylechanges in there, but with the little change of being commented out with a note that they break or/p, then either get around to improving or/p as well or asking on the ML if anybody wants to. Having new functions in Osmarender XSLT isn't the problem, using them in the [EMAIL PROTECTED] stylesheets are. Like I said, I just didn't think long enough before doing the commit. In case you haven't noticed, there is another change there that implements a notConnectedSameTag filter, which is also an incompatibility between or/p and osma xsl, but it's reasonably minor so it shouldn't be a problem to wait until I or somebody else gets around to implementing it in or/p. > PS: I'm annoyed in case you haven't noticed. PS: I hope you also notice I'm sorry. -- Knut Arne Bjørndal aka Bob Kåre [EMAIL PROTECTED] [EMAIL PROTECTED]
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Tilesathome mailing list [email protected] http://lists.openstreetmap.org/listinfo/tilesathome
