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...@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 _______________________________________________ Tilesathome mailing list [email protected] http://lists.openstreetmap.org/listinfo/tilesathome
