Hi Benjamin,
you should consider that both CSS efforts in GeoServer, the Scala and the
Java one, are based
on spare time work, the Scala one is basically dead, the Java one is about
to get into maintenance
mode because I cannot keep on working on it and ignoring the bug reports
for the rest of GeoServer/GeoTools
in the meantime.
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.
If you're curious about the rule expansion is performed today see here:
https://github.com/geotools/geotools/blob/master/modules/unsupported/css/src/main/java/org/geotools/styling/css/util/FilteredPowerSetBuilder.java
https://github.com/geotools/geotools/blob/master/modules/unsupported/css/src/main/java/org/geotools/styling/css/RulePowerSetBuilder.java
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).
Cheers
Andrea
On Sun, Dec 28, 2014 at 6:20 PM, Stadin, Benjamin <
[email protected]> 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 <[email protected]>
> Datum: Donnerstag, 25. Dezember 2014 11:29
> An: David Collins <[email protected]>
> Cc: Geoserver-devel <[email protected]>
> Betreff: Re: [Geoserver-devel] Status of the CSS extension?
>
> On Thu, Dec 25, 2014 at 2:38 AM, David Collins <[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.
>
> -------------------------------------------------------
>
--
==
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
