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
<[email protected]<mailto:[email protected]>>
Datum: Donnerstag, 25. Dezember 2014 11:29
An: David Collins <[email protected]<mailto:[email protected]>>
Cc: Geoserver-devel
<[email protected]<mailto:[email protected]>>
Betreff: Re: [Geoserver-devel] Status of the CSS extension?
On Thu, Dec 25, 2014 at 2:38 AM, David Collins
<[email protected]<mailto:[email protected]>> 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.
-------------------------------------------------------
------------------------------------------------------------------------------
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
