So any bright idea will have to wait for suitable funding, or someone that wants to build the next generation
of the geo css language.
This is actually the fast part, the heavy one while translating to standard SLD is figuring out the rule coverage
in order to generate fully exclusive rules in the output SLD.
See this thread, and the archive on geotools-devel, for the approaches that have been chosen to deal with it,
considering also the limited spare time available (I swear I’m not going to spend more than a few hours more
of my spare time on it for the foreseeable future, unlike the last six months, where it basically sucked all the little I had, that is, 4-8 hours a week).
···
On Sun, Dec 28, 2014 at 6:20 PM, Stadin, Benjamin <Benjamin.Stadin@anonymised.com> wrote:
Some rambling thoughts… 
The problem that most „CSS“ map styling languages have is in my opinion that next to none do the specificity thing right. CartoCSS for example seems more like a processing chain, applying rules based on occurrence. Though from the looks I actually like CartoCSS and it is probably very useful, but I’ve never tried it.
However, I’m convinced that no map styling language that finally figures the specificity right and in a flexible way, as it is calculated at runtime by the „real“ CSS [1], will be future proof. And it will fail sooner or later when either some new features are required or any of the shortcuts done to simplify calculating specificity become problematic.
To give an example, this is what we needed our map style language to take care of:
- type inheritance, like roomB:room
- object hierarchies (as required for real, non-tile-based, 3D). As a spoken example of a CSS rule: „if a building is farther away than 100m it’s child objects like rooms are not visible and not rendered"
- hierarchical rules: „a session room is green, 10m*10m, walls 2,5m high“, but also „a session room within building A is white“)
- State depending rules (e.g. Normal, selected, highlighted): „If a room is selected, change wall colors to red and show all detailed objects within"
Sure enough, probably only a subset of the above will be of interest to others. I’m just saying that since we had to figure these things, we came to realize how important it really is to do the specificity right, and how much simplified and thus sooner or later certain-to-break most current map style approaches are.
There are some ways to process also very complex styles and specificity rules fast, without having to build a tree or list for all possible combinations. We’ve considered two implementations: A multi-set intersection of sorted sets, and an „expanding automaton“. We went for the set intersection for performance reasons, as this gave us 20 millions of applied styles / second on an iPhone 5s. We need such raw performance for our 3D renderer. For a server side solution, I’d go with the expanding automaton, since this is more flexible and in terms of performance still very fast.
The idea with the automaton is that at the beginning you build an initial automaton that contains states for exact rules. For an example, say you have a style definition on top level for type „room“ and a hierarchical definition for a room inside the definition of type „building“, and you have another definition „buildingA“ but this one has no room defined within your style sheet. Now say you get objects to draw coming in the following order: buildingA->room. There is no room state definition yet under state node for buildingA, so check within the node for super type „building“ - there is our most specific definition for room. If there was no room type within building, we’d go to the top level and choose the room def there as the most specific. For optimization reasons, the room definition can then be copied to buildingA, so the next time we need this definition at the same path it is found without lookup (so I think it will be completely fast enough without copying, as the lookup doesn’t cost that much time).
Cheers
Ben
[1] http://css-tricks.com/specifics-on-css-specificity/
Von: Andrea Aime <andrea.aime@anonymised.com>
Datum: Donnerstag, 25. Dezember 2014 11:29
An: David Collins <david.8.collins@anonymised.com…403…>
Cc: Geoserver-devel <geoserver-devel@lists.sourceforge.net>
Betreff: Re: [Geoserver-devel] Status of the CSS extension?
–
On Thu, Dec 25, 2014 at 2:38 AM, David Collins <david.8.collins@anonymised.com> wrote:
This is an interesting discussion because we use CSS styling extensively with Geoserver. For us, this is much easier to use, understand and maintain than SLD (although ySLD would make life a bit easier). Andrea Aime has done some great work recently with the module, and of course, David Winslow did a great job implementing the system in the first place.
We have also used CartoCSS lately within Tilemill to create geology & geophysics phone maps, and that is also very nice to use.
With the Geoserver CSS, it seems to me that it will always be limited by the fact that it has to be converted back to SLD.
Do you think this will always be the case with Geoserver, or is there a possibility that Geoserver might in future have an engine that processes CSS directly ? (using code from other open source projects?)
Using code from other projects for styling/rendering, I would be close to impossible: the less native code we depend on, the better (it’s not normally written to work in a multithreaded enviroment, it makes GeoServer harder to install, and the first little glitch in it brings the entire server down, reason why most C based servers are using FastCGI, on crash the program just gets restarted).
As for having GeoServer run directly off CSS using Java code, it’s of course a possibility, but it would require quite a bit
of work up front (to just stand it up), and some maintenance headeache down the line, as we’d basically end up having to maintain
two different styling engines.
Mind, in my recent work I’ve setup a CSS->SLD translation mode that is fast (going down from minutes/hours to seconds for crazy
complex CSS styles), however it has a drawback, it generates some extra spurious rules to simplify its translation work,
so the result to a call to GetLegendGraphic won’t make you very happy.
Which is no surprise, if you look around the CSS based tools do not seem to generate a legend for you anyways, you have to create
one by hand or with some support tool, exactly because it’s quite hard to figure out which combination of rules will
end up matching features, and which will never match because higher specificity rules will steal the features away from them.
See these two thread in geotools-devel for more information about this topic:
http://osgeo-org.1560.x6.nabble.com/Extending-FeatureTypeStyle-adding-rule-matching-mode-td5175696.html
http://osgeo-org.1560.x6.nabble.com/Controlling-CSS-gt-Style-transation-mode-from-the-css-style-itself-td5179110.html
Cheers
Andrea
–
==
GeoServer Professional Services from the experts! Visit
http://goo.gl/NWWaa2 for more information.
Please, notice that GeoSolutions will be closed for seasonal holidays
from December the 24th to January the 6th
==
Ing. Andrea Aime
@geowolf
Technical Lead
GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549
http://www.geo-solutions.it
http://twitter.com/geosolutions_it
AVVERTENZE AI SENSI DEL D.Lgs. 196/2003
Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il loro utilizzo è consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora riceviate questo messaggio senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso, divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità diverse, costituisce comportamento contrario ai principi dettati dal D.Lgs. 196/2003.
The information in this message and/or attachments, is intended solely for the attention and use of the named addressee(s) and may be confidential or proprietary in nature or covered by the provisions of privacy act (Legislative Decree June, 30 2003, no.196 - Italy’s New Data Protection Code).Any use not in accord with its purpose, any disclosure, reproduction, copying, distribution, or either dissemination, either whole or partial, is strictly forbidden except previous formal approval of the named addressee(s). If you are not the intended recipient, please contact immediately the sender by telephone, fax or e-mail and delete the information in this message that has been received in error. The sender does not give any warranty or accept liability as the content, accuracy or completeness of sent messages and accepts no responsibility for changes made after they were sent or for other risks which arise as a result of e-mail transmission, viruses, etc.
==
GeoServer Professional Services from the experts! Visit
http://goo.gl/NWWaa2 for more information.
Please, notice that GeoSolutions will be closed for seasonal holidays
from December the 24th to January the 6th
==
Ing. Andrea Aime
@geowolf
Technical Lead
GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549
http://www.geo-solutions.it
http://twitter.com/geosolutions_it
AVVERTENZE AI SENSI DEL D.Lgs. 196/2003
Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il loro utilizzo è consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora riceviate questo messaggio senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso, divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità diverse, costituisce comportamento contrario ai principi dettati dal D.Lgs. 196/2003.
The information in this message and/or attachments, is intended solely for the attention and use of the named addressee(s) and may be confidential or proprietary in nature or covered by the provisions of privacy act (Legislative Decree June, 30 2003, no.196 - Italy’s New Data Protection Code).Any use not in accord with its purpose, any disclosure, reproduction, copying, distribution, or either dissemination, either whole or partial, is strictly forbidden except previous formal approval of the named addressee(s). If you are not the intended recipient, please contact immediately the sender by telephone, fax or e-mail and delete the information in this message that has been received in error. The sender does not give any warranty or accept liability as the content, accuracy or completeness of sent messages and accepts no responsibility for changes made after they were sent or for other risks which arise as a result of e-mail transmission, viruses, etc.
