Hi! 2013/3/9 Tom Davie <[email protected]>: >> * text-offset is also supported as text-offset-y in JOSM; furthermore >> there is a property text-offset-x, but I don't really can think of a >> use-case for this. > > Personally what I'd like to see is the user being able to specify label > placement techniques, and methods of deciding priority on labels. That is, > if they want to see the names of minor roads – let them, it shouldn't be up > to the renderer to decide that major roads are more important.
That's a very good point indeed. >> * The MapCSS specifications seems to lack the property "offset" from >> JOSM, which moves the line left or right. This is a very important >> property! > I'm not convinced I can think of a use case for it, but if you say so. Have a look at the screenshot here: http://josm.openstreetmap.de/wiki/Styles/Lane_and_Road_Attributes All the lanes use the property offset. >> Improvements needed to process data: >> Obviously from the number of built-in functions in JOSM there is a >> strong need of more processing capabilities. Arrays, loops, nested if >> statements are just a few of them. As I'm not really a fan of >> reinventing the wheel again and again I want to suggest something and >> hear your opinions. Here's an example which should make clear what I >> have in mind: > > No, the design philosophy here is entirely wrong. Shouldn't the design philosophy be targeted at the use-cases? > MapCSS is a declarative language. That means, you say "given this input, the > result is this", not "to compute the result from this input do this then this > then this". This has significant benefits to implementors, and to clarity of > stylesheets. If you want to invent MapJavascript, do so, but MapCSS is not > the place to put it. I don't want to invent MapJavascript. I - and I guess some others - need more processing power. Why should we invent something new (did I already mention I don't like to reinvent the wheel again?) instead of taking something that works and add what is needed? The approach would be fully backward-compatible, use existing code (for the javascript interpreter) and tremendously increase the abilities of MapCSS. Take a look at the code of the JOSM style. Doesn't this look very 1970ish? Or even 1960ish? For example the style supports eight lanes in each direction. Why eight? Because I wrote the code for the first lane and copied it seven times. I wouldn't use the word "elegant" for this. > For reference, OpenStreetPad already supports nested selectors, allowing you > to do things like this (in a declarative form): > ......... Nice but too less. Where are loops and arrays? We have an increasing number of tags that contain multiple information. For example all tags like turn:lanes or change:lanes contain a list of properties. Some people need to get a list of all relations attached to a way. We are completely missing the power to process such information in an efficient way. Of course we can increase the number of eval-built-in functions. But I'm asking again: why reinventing the wheel? best regards, Martin _______________________________________________ Mapcss mailing list [email protected] http://lists.openstreetmap.org/listinfo/mapcss
