[Tilesathome] Leisure rendered black @ level 12

[Hugh Barnes]

Hi

Apologies for breaking the thread, I have only just subscribed. First
some metadata:

Ed Loach submitted a patch [1] for the problem reported by Michael
Ritzert [2].

This is almost certainly an unnoticed consequence of some patches I
have applied recently, towards trac ticket #1476 [3]. So it may be
neater to revert my recent commits if we can't get to the bottom of it.

Let me try to explain what I'm doing and the process I'm following.

I really want to improve OSM's SVG rendering, but I find the code in
need of a lot of cleaning before I can do that. It works, sure, but
it's repetitive and unnecessarily difficult to maintain. The first step
for me is to improve the application of CSS classes. I want to get away
from these aggregations comprising every level of the hierarchy to a
set of classes that actually enumerate the singular properties of the
object so that they can be selected reusably individually or in
combination.

So, fictionally:

highway-core highway-bridleway-core highway-bridleway-tunnel-core

can be just:

highway bridleway tunnel core

So that's 3 aggregate classes with minimal reusability, versus 4
classes with hooks that can be exploited flexibly, and many of these
can be shared with other elements.

For example, all elements with "highway" class can be styled in one way
(bad example, probably). All bridleways can be, say, blue and dashed.
All tunnels can have dashed outlines. (Not a very compelling example
in practice because I don't know the renderings very well :( )

And because CSS cascades, all of these can be overridden by rules of
specificity and invocation sequence, so we can still say:

.bridleway.tunnel.core

… if we have specific styling we want apply to elements with
classes .bridleway *and* .tunnel *and* .core.

(Note that I am also making the assumption that all bridleways are
highways, so omitting that redundancy. I believe this is a small
increase in robustness.)

This is how CSS was born to be used. It's maintainable and scalable
and it doesn't give you headaches when you do it right. :~)

So the process I have for completing this ticket is to start with z12,
the least popular and least actively developed features ruleset. I am
selecting small sets of keys for the moment and testing them carefully.

I am testing on the dataset in the testdata directory of the svn
repository. For each file, before and after, I am:

- running the transform
- converting to image/tiff with batik
- running diffs

With a completely comprehensive test data set, this seems a robust
process to me for any changes that are code cleanups only (i.e. should
have no rendered impact).

I seem to recall I got some diffs for the leisure key, and when I
examined the images they were indeed black in some cases. However, I
fixed that (I thought).

I am currently getting some binary diffs I can't explain with waterways
and, I think, buildings. I haven't committed in a while because of
these. I am actually starting to wonder if batik has implemented CSS
accurately, but it's also possibly something right under my nose.

So that's what I'm doing, and I've noticed since I started writing that
the patch has indeed been applied. I have been advised by bobkare that
t at h can also use inkscape, so possibly that is something else to
include in my tests. It would be really helpful if you could give me the
bounding box of the area where you found this problem. More test data
will always be valuable.

I'd like to keep doing this cleanup, so this change will probably be
eventually undone. I'm happy I've had the chance to explain what I'm
doing, though.

(and well spotted Michael and well patched Ed)

Cheers

1.
http://lists.openstreetmap.org/pipermail/tilesathome/2009-February/005593.html
2.
http://lists.openstreetmap.org/pipermail/tilesathome/2009-February/005592.html
3. http://trac.openstreetmap.org/ticket/1476