We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

GNOSIS Cartographic Map Style Sheets (CMSS)

00:00

Formal Metadata

Title
GNOSIS Cartographic Map Style Sheets (CMSS)
Subtitle
an elegant and powerful styling language for both classic and 3D cartography
Title of Series
Number of Parts
295
Author
Contributors
License
CC Attribution 3.0 Germany:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Identifiers
Publisher
Release Date
Language

Content Metadata

Subject Area
Genre
Abstract
An overview of GNOSIS CMSS, a styling language for both classic and 3D cartography. Ecere developed the GNOSIS Cascading Map Style Sheets language in conjunction with the OGC Innovation Program's Tetstbed 13 and 14, and the open specifications for it are available in a public Engineering Report: http://docs.opengeospatial.org/per/18-025.html#StylingModel Key features of GNOSIS CMSS include cascading of styling rules and sheets, any symbolizer value can be a complex expression, and a concise and clear syntax.
Keywords
129
131
137
139
Thumbnail
28:17
Formal languageExecution unitBitVisualization (computer graphics)Formal languageMappingLecture/Conference
Formal languageComputer programmingSubsetSource codeSoftware development kitService (economics)Server (computing)Mathematical optimizationKeyboard shortcutSoftwareAerodynamicsModul <Datentyp>FreewareComputing platformMaizeOrientation (vector space)Object (grammar)Vector spaceRule of inferenceAxonometric projectionVirtual realityAuto mechanicGenetic programmingRegular expressionData modelInterface (computing)Positional notationCascading Style SheetsMultiplicationElectric generatorSocial classComputing platformValidity (statistics)Java appletLevel (video gaming)Cross-platformVector spaceReflection (mathematics)Software testingVirtualizationKeyboard shortcutObject (grammar)Formal languagePhysical systemComputer programmingBitMechanism designRule of inferenceVisualization (computer graphics)Software developerObject-oriented programmingText editorSubsetTerm (mathematics)CodeComplete metric spaceDynamical systemClassical physicsGraphical user interfaceRepository (publishing)Category of beingAreaKey (cryptography)WindowService (economics)Line (geometry)Automatic differentiationAndroid (robot)Order (biology)Projective planeSoftware development kitProgramming languageSelf-organizationThomas BayesState observerMetropolitan area networkOpen sourceLatent heatAdditionCASE <Informatik>MereologyResultantXMLComputer animation
Auto mechanicRule of inferenceGenetic programmingRegular expressionVector spaceAxonometric projectionVirtual realityData modelInterface (computing)Positional notationObject (grammar)Formal languageComputer programmingSubsetCascading Style SheetsWeb 2.0Object (grammar)SubsetOcean currentLevel (video gaming)Link (knot theory)Endliche ModelltheorieQuicksortCodeCodierung <Programmierung>Different (Kate Ryan album)2 (number)Formal languageMereologyAdditionRegular expressionLine (geometry)Clique-widthTestbedFamilySign (mathematics)Genetic programmingSystem callError messageComputer programmingAttribute grammarCategory of beingTraffic reportingCodeOrder (biology)WebsiteMiniDiscSineComputer animation
World Wide Web ConsortiumBoolean algebraComputer fontLocal ringIntegerAnglePoint (geometry)RadiusComputer-generated imagerySinguläres IntegralPattern languageComa BerenicesGradientArithmetic meanInclusion mapRegular expressionRule of inferenceCategory of beingQuicksortObject (grammar)Genetic programmingComputer iconShape (magazine)Point (geometry)Symbol tableComputer animation
Order (biology)Clique-widthBuildingComputer fontCircleRadiusRegular expressionCodeIntegerVisualization (computer graphics)Enumerated typeOperator (mathematics)LogicPairwise comparisonConditional probabilityData typeLengthGeometryGeometryObject (grammar)Multiplication signCASE <Informatik>Electronic mailing listMereologyComputer fontSquare numberResultantMechanism designSet (mathematics)Attribute grammarRegular expressionOrder (biology)IdentifiabilityMultiplicationType theoryDifferent (Kate Ryan album)Rational numberEmailMessage passingCartesian coordinate systemPoisson-KlammerGraph coloringMilitary baseCategory of beingDemosceneBuildingClient (computing)GUI widgetGenetic programmingLine (geometry)Software developerSource codeQuicksortStylus (computing)Greatest elementOperator (mathematics)2 (number)Element (mathematics)Time seriesLevel (video gaming)Rule of inferenceDefault (computer science)Block (periodic table)Functional (mathematics)Visualization (computer graphics)CodecSoftware testingString (computer science)Row (database)Physical systemFraction (mathematics)Scaling (geometry)CircleECosProcess (computing)System callWritingNetwork topologyReal numberFormal languageLengthClosed setZoom lensSymbol tablePointer (computer programming)CodeIntegerBasis <Mathematik>Enumerated typeRadiusComputer animation
Visual systemText editorFormal languageTranslation (relic)DisintegrationSoftware testingVideoconferencingTestbedEndliche ModelltheorieParsingCore dumpSource codeRaster graphicsLine (geometry)Rule of inferencePolygonLatent heatPattern recognitionAugmented realityCore dumpText editorEndliche ModelltheorieTranslation (relic)Source codeSoftware testingGreatest elementGeometryRepository (publishing)Raster graphicsVideoconferencingMereologyRule of inferenceGraphical user interfaceCross-platformAreaPattern recognitionPolygonBranch (computer science)Line (geometry)ParsingProjective planeTraffic reportingOrder (biology)Electronic visual displayVideo cardLevel (video gaming)AxiomOpen setSolid geometryTask (computing)User interfaceFormal languageArithmetic progressionServer (computing)Open sourceComputer animation
Revision controlVideoconferencingCodeVideo card
Physical systemGraph coloringSolid geometrySymbol tableNetwork topologyComputer fontSubject indexingTouchscreenVideo gameSubstitute goodExtension (kinesiology)Default (computer science)WindowPresentation of a groupForm (programming)TesselationDifferent (Kate Ryan album)Vector spaceWindows RegistryVideoconferencingBitRight angleComputer animationLecture/Conference
Pointer (computer programming)Substitute goodExtension (kinesiology)Computer fontSoftware testingText editorRegular expressionRule of inferenceRight angleDifferent (Kate Ryan album)
Maxima and minimaVector spaceEmbedded systemInclusion mapTexture mappingFile formatZoom lensGraph coloringElectronic mailing listText editorExpert systemGeometryINTEGRALComputer animation
GeometryINTEGRALSoftware testingVector spaceTesselation
GeometrySoftwareVolumenvisualisierungRepresentation (politics)Tesselation
Google MapsView (database)SoftwareMappingVolumenvisualisierungOpen setNumbering schemeServer (computing)Level (video gaming)Source codeKey (cryptography)Core dumpTranslation (relic)Formal languageArtistic renderingDifferent (Kate Ryan album)Metropolitan area networkClient (computing)Bit rateTable (information)Order (biology)Electronic mailing listFamilyMereologyGraph coloringHeat transferVector spaceEndliche ModelltheorieCybersexSoftware developerTerm (mathematics)Mobile appOffice suiteWritingRight angleEntropie <Informationstheorie>State of matterInsertion lossFunctional (mathematics)Software development kitPresentation of a groupGeometryRange (statistics)Raster graphicsCanadian Mathematical SocietyComputer hardwareMobile WebCodierung <Programmierung>Computer animation
Transcript: English(auto-generated)
Thank you, so yeah, I'm Jerome Saint-Louis from HRA in Canada and today I would like to talk to you about our styling language which can be used with both 2D or 3D maps.
So first I would like to give you a bit of an overview, I don't know if anybody saw my talk yesterday, if so that would be a bit repetitive, I apologize, but just to give you the background of our Gnosis toolkit. So basically it's a complete visualization,
geospatial visualization stack, it includes a map server, a GIS tool, and also an SDK. In terms of the services, so we're implementing the classic OGC services, but we're also working on implementing support for the new upcoming OGC API. The GIS tool can do things
like produce styles, applying the styles, so we're building a styling editor for this styling language. And the software development kit, we program it in EC, which is our own object-oriented programming language, but we also have a system a little bit like SWIG, but it's our own tool that automatically builds bindings to other languages. Because
EC has reflection and object orientation, so it can produce actually pretty good bindings for each language, because it has a good way to model the different classes. So right now we have C bindings, Python, and we're also working on the generation of C++ bindings,
and Java and C Sharp are next in line. So our EC programming language, it's a superset of the C language, so any C code is technically valid EC code, but it adds classes, properties, dynamic modules, and reflection. So that language I started in 2004, eclang.org, and it's compiled,
that's the nice thing about it, so you can write very high-performance code, but it's also executing, it's also easy, fast to actually write it. And also our diagnosis
geospatial toolkit also leverages our Acheri SDK, which is also all open-source, the Acheri SDK, and that includes a cross-platform GUI toolkit, and it supports multiple platforms, Windows, Linux, Mac, Android, WebGL, and the Odroid, which is this tiny device, a
little bit like the Raspberry Pi, but with a GPU, and FreeBSD. So it's very from the ground up, very cross-platform, and it includes a 2D and 3D graphics engine, and it's also in the Debian and Ubuntu repository as Acheri SDK. So our Gnosis platform is built on top of that. So now about the actual Gnosis CMSS, the styling language. So the goal
is that you can style multiple map layers, so whether it's vector imagery or coverage, and it's all based on a cascading rule system. And we're testing it with both the classic cartographic projection, but also with virtual 3D globes. And the idea is to
have very clear mechanics with nested rules that can inherit, so only use a more general rule, but then for specific cases with additional selectors, then you change some specific part of the style, so it can result in very concise styling, very expressive, very easy
to modify. And expressions are used both inside the selectors to decide whether some styles is going to be applied, but also for the actual value of the symbolizer, so you can have the expressions used directly when you set, for example, the width of a line
or the size of a dot marker, something like that, so you can directly put an expression here that reference the attributes of the data. So the foundation for the Gnosis CMSS,
it's an encoding in the OGC testbeds. We've been working on a conceptual model for styling to try to achieve styling interoperability, which is a really big challenge. I think it's been going on for many years, and it will probably keep going for long again. But the idea is to have one conceptual model, but different encodings for it. So our CMSS is
trying to be a very generic, very close to the conceptual model, very easy to translate different other styling language, for example. The actual cascading and the selectors aspect
of it was inspired by the web CSS, but also Carto CSS. So the CMSS itself is actually a specialization of what is now a general purpose ECCSS, and what ECCSS basically is.
So we have our EC language, which is like an object-oriented C, so it adds objects to the C language. So the syntax is much inspired from this, but from the EC language, a subset of it describes objects, and that syntax that describes objects is very
similar to JSON, if you're familiar with JSON, but the main difference is the column becomes an equal, and you lose the quotes on the left-hand side of assigning things to properties. So that's ECON, and then ECCSS, inside ECCSS, there are pieces that are exactly ECON. So
that's sort of the syntax inspiration for what it looks like, and I'll show you in a second. And ECON itself, so that's also something we use extensively in all our programs, because it's very easy to go from the data to the code. The actual ECON data definition is valid code in our EC language, so it's easy to work together. So there's a link
here to eclang.org slash econ, that's the definition of this. And the links here from the OGC engineering reports, they're actually the current draft definition of the cascading map style sheets language. So now I'll show you some examples.
Well, before the examples, this is sort of the overall conceptual model of it. So basically it starts with the style sheet, which is basically defining a style. Inside your style sheet you have multiple rules, and then each rule has an expression, sort
of the selector, and then you can apply the style or maybe symbolizer is more the appropriate terminology with the OGC terminology. So style here should actually say symbolizer now. And here you have all the different properties you can set, and then you have
specific things which applies to shapes, for example, like the stroke or the fill. And then we have also the concept of labels and markers, and inside your label you can have multiple objects that make up your label. So you can build a label with some text and
also an icon, and then this will be applied, for example, if you have point features. And then for the actual graphics definition, we have all the different shapes here, which also can be styled with the symbolizing aspects here. So here's the first example. So if you're familiar with Carto CSS or Geo CSS,
it looks quite familiar. So at the top is the layer selector, so it just selects the layer ID, so this style is for styling buildings. And then you have the concept, so between the curly braces is all the symbolizing that's going to be applied for the buildings layer,
and you have the nested rules inside here. So the second curly block is a nested rule. What this means here is by default all the buildings are not visible, and they should be drawn at the Z-order 8. And if your scale denominator is smaller or equal to
127,000, then you also apply this style on top of it, so that's the nested style here. So if you zoom in close enough, then you'll have the visibility turned on for the buildings, you'll have a color applied to the fill, and at this zoom level here, there won't be a stroke,
so it's just going to be the fill for the buildings. So that's the basics, it's very concise, it's very easy to work with, and you can see the econ syntax here, which is basically the curly braces, and the property, the equal, and the semicolon. So that's also a valid ECObjects when you have just that, but ECObjects doesn't have the
concept of selectors. So the nice thing about the reason we did the ECCSS, instead of just writing the styles in JSON or econ, is that it lets you write the expression in a native way here, whereas if you use JSON, it's not very intuitive to write expressions as selectors or as value,
so you have to either encode them in strings or resort to things that are not very easy to work with, which I find is the case with Mapbox, GL, Stas, for example.
And this is another example here, so this is a more specific rule, so if you zoom in even further, we're going to start to add a stroke to the buildings, so you're going to have a thin line around each building, and we're also going to start labeling the buildings, for example.
So here you see the label property, and it's actually, so the label is an object, that's the curly braces, and inside your object, you'll have an array of elements that you want to define for each building, so that's the array syntax here. And so the first object we'll create was only one object, in this case we only want to put some text, so that's the text
object, and so the actual value for the text will be the name attribute, which is taken from the attributes of the data, and then the label will be white, and we select a font, we apply an outline to the font, so there's a black outline around the font.
So that's the basics of it, so this is pretty much how ECCSS or CMSS looks like. And this is another example here, trying to style the roads from OSM data, for example. So here you can see the in operator, so instead of having to repeat the different expressions,
if the highway is in any of these values, then this symbolizer will apply, and you can also see here the case where rather than setting the whole stroke object, we'll just change the color, or we'll just change the color of the casing of the stroke,
so it's going to inherit the default, the width, and every other property of the stroke, the opacity of the stroke, so that's that case here, that's the same thing here. It's also applying the z-order, so you can layer your roads, the visual priority
based on this. So this is actually pretty optimized for a client-side rendering, using a z-order mechanism, as opposed to having like, defining multiple layers of roads to draw, so it just says that these elements should be rendered before those, but we can render all of them in a single pass, as opposed to having to do one pass to render the roads,
and then render all the roads again with different styles, so this makes it very efficient for 3D rendering. And this is sort of an overview of all the types of expressions you can have in ECCSS, so an identifier, like a feature code for example,
so this you just write like this, and that means an attribute in your data set directly, so you don't have to put anything special, it's just like the name of the identifier, and that's resolved to the attribute in the data set, then you can have a text string,
you can use integer or real numbers, you can use objects, so there's a few cases where objects are used, for example here, this is an example value for defining the time, so if you want to do a time series comparison, so you can use that. The text object, like we saw earlier when defining the labels, so you can define graphical
elements, so that's part of the language syntax. Another example would be a circle, and you can set the radius of the circle to display it, and our example is the list, but I actually got that wrong in here, so the list was more like the in, so what we saw earlier,
like in primary, secondary, so you can have more than one value, so that's the list with the array syntax, like the square brackets, and then you can have also a variable, which can be something that the application can modify, and the style sheets can use that basis to use application settings, for example.
And so the identifiers themselves, there's a few different types of identifiers as well, there's the null value as enumeration system, which is just directly written, like true or false, there's objects that are predefined, such as the layer, for example,
so you can do like layer.id, layer.geometry, and there's the viz, which refers to the visualization properties, like the scale denominator, and you can also refer to a specific record, so get the geometry of the record, or the id of the record,
to use in your selectors, and then you can refer to all of the data attributes as well, and there's also an identifier for records, which means all of the records in the data set, which you could use, for example, with an iterate function to test for overlapping, so that you can apply different styles if you have features overlapping with one feature.
So it's a full expression language, so you have all the basic operators, logical, comparison, there's text-specific operators to check if a string contains, begins with, or ends with, you can do arithmetic, you can change the priority with
parentheses, you have the conditional operator, so that you can, for example, apply easily, concisely, to find different things for different scale denominators, all inside the same symbolizer, so this is the list example here with in, and you can also
have function calls, for example, the length of the centroid of the geometry, for example, so that's, of course, this is also extensible, so more functions can be added, and so this is sort of the road map for the work ahead, so it's still all very heavily in development,
at the bottom here you can find the repository where a lot of the source code for this is, currently the core ECCSS parser and the styling engine are all open source, our 2D and 3D graphics engine, the core of it is also open source, and one of the things we're doing right now is improving our style editor to really
use this CMSS model and make it easy to edit improvements to this, and we're also working on translation to and from other styling languages, including SLDSC, Mapbox GL styles, and also eventually we'd like to do a geo CSS,
which GeoServer supports, and we're also working with the OGC API, there's going to be a styles module, which is going to be able to retrieve and upload, and so you can edit and you can exchange, you can discover style sheets, so that's going to be very powerful, I think,
so we're working on integrating with that as well, eventually, so we're also working on testing with the full OpenStreetMap, with some bright style, trying to make it look as close to it as possible, as one example of testing how well this works, we're improving the definition of
how this style, the raster data, like coverages and imagery, and right now we're working as part of 15 portrayal in the OGC on this task, which covers a lot of this here, and at the end of the year there will be published videos and engineering reports about this, so that will be quite
interesting, I think, when this is ready, and other things that we have on the roadmap is styling more specific to 3D, like rules for example, for styling 3D models and 3D solids, and doing extrusion of polygons and lines to display them in 3D, and you could even have
markers which are animated 3D models, for example, and we also do some projects with segmented reality, so you could have selectors which are based on the pattern recognition to apply certain styles, so I think that would be very interesting, and we also, this ECCSS,
like I say, it's not specific to cartography at the core of the styling language, so it's something that we want to use also for styling our user interfaces, not only the maps, so that's, and since we have a cross-platform GUI toolkit also, this is one area where we want to use this as well, so if you're interested, I invite you to
check out our repository on GitHub, the dev branch is where all of this is happening, and this is an example here of an OpenStreetMap style using this, so this is still working in progress, so we're still working on improving all this, and since this, we actually switched
to a whole new graphics engine version as well, so we're still improving this, and that's some of the work I'll be doing tomorrow at the code sprint tomorrow, so that's this, so thank you, and I might have a video as well that I could show you if I still have time,
be patient, thank you, and do we have any questions?
Thank you for presentation, what happens if text contains symbols not exist in font? Sorry?
What happens with your engine if text contains symbols? Yes, but the symbols not exist in font, for example I have Arabic symbols in text by font not contain this. Right, so we actually, right now it's an interesting question, because right now in
Gnosis we have two text engine which we're going to merge, and one of them does the font substitution, when the glyph is missing it's going to default to another font that does have the font, but currently we're kind of in the middle of making these two engines work together, so our goal is that we would do the font substitution with
another font that does have the symbol to replace it, so that's one of the things we want to support. The default font, yeah? Well, so, and it's different on a different platform, but on Windows for example there's actually a registry entry which defines which font should default to which other font,
so you can change the mapping of if that one doesn't have a glyph then it's going to go to the next one that might have it. And second question, have you a specific solution for your styles? Yes, so we do have that, and I think the video might show a bit of that, if we're
working right now on improving our style editor, but it's all WYSIWYG-based, so you have sliders and you have colors and you see the styles right away, you get a live update for it. Thank you.
And so this is a video that we did for one of the OGC vector tiles palette activity,
which was the extension which was focused on the styling, so this might actually be using that font substitution here, or maybe it was using the Avrial Unicode which did
have the Arabic fonts. So this is the night styles where we're testing different, switching the style sheets from one to another, so this was the night-oriented style.
And this is our editor here, so you can see you can edit the different expressions, on the right list you have your list of rules, and here's showing here the live color
editor, and we also have a geo package exports, this is showing Google Maps integration with our terrain model, now this is the topographic style that it was called, and
the vector tiles palette which produced the data, so it was a big interoperability test between the different participants, so earlier I talked about the OGC API, but
geo package is somewhere else that we're working on integrating styling capability, and so that's also something here.
So great presentation, thank you, just for my understanding, if we wanted to create WMTS layer, so rendered already tiles, this would mean to use the software you're giving,
right, so the way we saw that you can configure this, so if we wanted to render open street maps with your styling scheme, it would be through your software, right, are you considering integrating this rendering of the styling concept into other software
solutions? So my presentation is on the styling language itself, which any software could implement, and I would welcome anybody who's interested to contribute to develop this and implement this in other engines, and we're also working on the translation layer and tools
that we'll probably publish to do translation between different languages, which our geo server for example could do it, and also it's meant both for client side or server side rendering, and for example our server is going to be capable of generating dynamic tiles,
so you can give it the style that you want to render and then it's going to return it to you already styled, or you can request the feature data, the vector data, and the style separately, and then your client can render it using your engine that could implement this, so there's many ways to do it, but like the CMS thing is really just purely
a nice concise way to edit and write the styles, saying how you want to portray things. So let's say right now there is like two software solutions implementing this styling, so there's a server solution and a client solution?
Right now there's probably actually only our client-based software, we're still working and making this server side too, but we're more focused, and I think in general the industry is more going towards client side in the future, because you have the GPU and all your mobile hardware anyway, so it's much faster, it's less transfer, you can do nicer
things for 3D, it's much better I think, so we're focused on the client side, but we're also planning to implement the server side, and we'd welcome other people to implement this as well. Thank you. Thank you.
Thank you. Just interesting, maybe I'm not sure if that's very valuable, but did you compare the size of the style, for example, for some basic OpenStreetMap styling in Mapbox, for example, styling, and in your styling options?
So far we haven't really implemented the full Mapbox style, but I don't know how much is, I know with SLD this is much, much, much smaller, but what I find with the Mapbox style is it's very cryptic, it's very hard to follow because they sort of encode
things in a JSON way, which doesn't, I think they might have some, I forget if they have cascading aspect, not really, right, I don't think they have, but it's just hard to work with, I find, but I don't know in terms of the size how compact it is, I think it also depends on what approach you take, but it should be comparable if not smaller, I
think. Just out of curiosity, I was wondering if it is possible to transform, for instance, SLD to CMS or vice versa? Yeah, that's what we're working on right now, so we're writing the importer and the exporter to SLD SE and also to Mapbox GL styles, so those are the two core
translators that we're doing, so we're working on a tool to do that, exactly that right now, later would also like to do the Geo CSS, same thing, having one way and the other way, so the idea is that this could act as a nice translation tool
to any other styling language, so that's kind of the big goal of the styling interoperability, I think, but it's challenging because each renderer support different features and maybe do things slightly differently, so it's always not an exact science to translate styles from different engines, but we're still trying to do it
as good as possible. And another question, this is both for raster and vector? Yeah, so far it's more focused on the vector, but definitely in the next month we'll have the basic, at least for elevation model styling, we'll be there and we'll
have some basic things like brightness, opacity, saturation, which can style the imagery and for coverages also we'll have the, so applying a color map and mapping the range or an offset for the values to colors, so we'll have that basic functionality in, but that part is still in development right now.
Thank you. Thank you.