[Tilesathome] Huge Names for natural=water?

[Knut Arne Bjørndal]

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 tiles at home, 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 t at h.

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 tiles at home 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 t at h 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
bob+osm at cakebox.net
bobkare at irc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4167 bytes
Desc: not available
URL: <http://lists.openstreetmap.org/pipermail/tilesathome/attachments/20080810/e299cb1a/attachment.bin>