[Mapcss] Development of MapCSS?

[Jo]

2013/3/8 Andrew Shadura <bugzilla at tut.by>

> Hello,
>
> On Fri, 08 Mar 2013 23:16:58 +0100
> Paul Hartmann <phaaurlt at googlemail.com> wrote:
>
> > > I'm not particularly happy with what's happening with MapCSS. It's
> > > understandable when certain software doesn't implement some
> > > features, as sometimes there may be technical or other obstacles
> > > for that. When features are implemented a very different way, or
> > > implemented without priop discussions, this leads to chaos. And
> > > that's what we have now.
>
> > > In my opinion, JOSM implements MapCSS in a very bad way, and its
> > > extensions are extremly non-systematic and against the spirit of
> > > CSS-like languages at all and MapCSS in particular. Function naming
> > > is very strange and is not easily readable.
>
> > I'm a bit surprised by your strong disapproval. Extensions have been
> > implemented because there was demand for these features. If you have
> > ideas to achieve the same with a better syntax, then please let me
> > know. You can also suggest better function names, it shouldn't be a
> > problem to add an alias and deprecate the old name.
>
> Well, maybe it sounded too strong, but... I'm not against the
> improvements at all. I'm against the particular way they're
> implemented. Sometimes similar things in JOSM are done different way,
> and different things — in a similar. If I have enough time, I may try
> to prepare some kind of analysis, not sure when I do that, however.
>
> > In my opinion, MapCSS support in JOSM has been a great success so
> > far. We have about 40 MapCSS styles contributed and maintained by
> > users. Some of these styles are quite comprehensive and extremely
> > useful (like the one by Martin).
>
> Practical achievements is one thing, I'm happy with the fact that users
> can easily add things to JOSM styles, and I've used that feature
> myself. I was extremely disappointed when simple things I expected to
> work didn't just because JOSM implements them a different way.
>
> > I'd be happy to join the discussion and work towards a unification of
> > the language. However there seems to be little direct and practical
> > benefit from this. If there was another MapCSS renderer that was
> > interested in using the JOSM tailored styles, then some discussion
> > would be starting. But for one reason or another, there isn't much
> > exchange and sharing of styles at the moment. (Well, JOSM ships the
> > main PL2 style. :) )
>
> I don't understand why there should be separete MapCSS styles for JOSM.
> Or this is a single MapCSS which works across different renderers,
> maybe with different support degree, or we have lots of local dialects
> of it — why can' we have just one? We'd all benefit from that.


If you want the same level of support in other products, why don't you
implement what has been done in JOSM already? Why is it a problem that
extra functionality is implemented first in JOSM?

What I'd like to see is a way to count how many relations a primitive (way)
is a member of. Preferably with a way to narrow down the relations by (a
combination) of tags.

The other thing I need is a way to create a list of a given property of
those relations (colour or ref), also constrained by type=route,
route="bus|tram".

What I don't see very well though, is how to use them then. On the one
hand, it would be nice to get a list, but as a property for color,
right-casing-color and left-casing-color one needs them as something that
is indexed.

Do I really have to wait until this has been discussed, before it can
become implemented? On the one hand, that would be good, as it may mean
other people can give their insight on feasibility and how to best
implement it. But apart from this thread, it's rather silent on this list...

Jo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/mapcss/attachments/20130309/ff06588f/attachment-0001.html>