Ulf Lamping wrote:
Am 15.11.2010 23:48, schrieb Sebastian Klein:
No objections. Maybe we can switch the default value of
mappaint.zoomLevelDisplay from false to true afterwards. This way
authors of external style sets can create fancy scale dependent styles
and don't need to bother their users with advanced preferences
configuration.
Makes sense. To avoid any hassle, we may want to remove the scale
entries first, wait one or two releases and then change the default value.
Generally I don't see any problem since the xml style is distributed
with the binary. But users who have loaded a modified copy of
elemstyles.xml would be affected.
Btw., I have mostly completed mapcss support (which offers zoom
dependent markup, as well), but it will take some time to integrate into
JOSM. A lot of existing code needs to be adapted and I don't want to
break too much...
E.g. the z-index property does not work well with the way multipolygons
are drawn in the PaintVisitor.
Do you keep an eye on the performance? Having a new "rendering engine"
that is able to display a lot of fancy stuff but is also a lot slower
might be the wrong direction ... ;-)
Yes, I'm aware of this. Currently, the new PaintVisitor is slightly
slower (basically due to z-level ordering) but not significantly ( < 5%
I think, but I will do careful benchmarking). All styles are cached, of
course, so most time is not spend in JOSM code, but with actual
rendering of areas and lines.
Regards, ULFL
P.S: I'm not a big fan of mapcss, as the XML we currently have makes it
a lot easier for externals to automatically analyze the rendering (and
preset) rules files (as e.g. Jochen is currently doing it for taginfo).
Parsing the css alike syntax isn't impossible, but obviously harder
compared to XML that a lot of people already know how to do - including
myself ;-)
Sure, it's not that easy to parse, but it's a matter of priority. E.g.
you don't design a programming language such that compiler has an easy
job to parse the source code, but from a user perspective. (Otherwise
Lisp would be much more popular and Perl much less. :) )
Another reason for supporting this format is its use in potlatch 2, so
we might get a second style in JOSM "for free". Maintaining a single
style must be a lot of work already, so why not join forces a little.
I'm not about to remove the xml style support, though. It will still be
available and you can even load style files with different formats at
the same time. (But as I said, don't expect it before Christmas. :) )
Sebastian
_______________________________________________
josm-dev mailing list
josm-...@openstreetmap.org
http://lists.openstreetmap.org/listinfo/josm-dev
