[josm-dev] Removing scale_max / scale_min from elemstyles.xml? / mapcss

[Sebastian Klein]

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