RE: [TC-Discuss] Symbology Standardization

Hi Chris,

Thanks for following up today. Reading through the thread, I have a few comments probably to individuals not reading this list, but anyway I'd like to make a few points.

Jérôme wrote: 
> > I think W3C CSS serves a somewhat different use case, and there are
> > many aspects of CSS that has made me pull my hair in despair, so I
> > doubt I could be convinced to go in that direction.

CSS was designed for HTML, which is different from maps / MapML in its layout semantics, but I believe that MapML shares the 'painters model' with SVG: https://www.w3.org/TR/SVG/render.html, which makes that aspect different from HTML.  Since SVG also relies on CSS to separate style from content, I am hopeful that the geospatial community can find commonalities with the graphics community, instead of re-inventing the (style) wheel completely. The imperative to do so is strong, because CSS is a well established global standard that supports DOM styling.  MapML being a DOM-based format, would seem to lend itself to re-using / influencing / participating in existing dominant standards like CSS instead of inventing something new.  I think the "Test of Independent Invention" is informative on this point, which is not very well described on the Web https://www.w3.org/DesignIssues/Principles.html#TOII , as far as I can tell, but was quite explicitly discussed in Tim Berners-Lee's book "Weaving the Web".  Essentially, you ask yourself when designing something for the Web, in order for this to succeed, does some other system have to die? If the answer is "Yes", start your design over, repeat until the answer is "No".  I think the dominance of CSS and the Web is a factor that we need to recognize from the outset.

Jérôme wrote: 
> > Both MapCSS & CartoCSS take a somewhat different approach to some
> > things.
> > A challenge in establishing a styling standard is how styling
> > properties often tend to be closely tied to both the visualization
> > engine as well as the geospatial data they are used with (OSM MapCSS
> > for example is very much tied to the OSM data model iirc).
> > Yet, not standardizing key things and using 'vendor options' as is
> > currently all over the place in SLD/SE is just as bad if not worst of a problem.
> >
> > Certainly we are influenced by how our own visualization tools work in
> > designing this, but it is the goal to try to generalize things as much
> > as possible to avoid the styling standard being too specific.
> >
> > By considering a number of styling systems to support (e.g.
> > Meteorology, Aviation, S-52) as well as compatibility with existing
> tools/standards (e.g.
> > SLD/SE, OSM MapCSS, Mapbox CartoCSS, ESRI .LYR, QGIS QML styles), I
> > think we have good chances to achieve this successfully. It is also
> > our goal to be able to import/export to/from some of those at least.

All of these technologies and experiences can and should inform the requirements we should bring to the CSS + SVG communities.   We have to keep in mind we're dealing with the Web platform, not a single GIS engine, so the requirements need to be adapted accordingly.

> > In my experience (somewhat limited, I'm definitely not an expert web
> > page
> > developer) CSS as used for web pages has a tendency to be hard to
> > follow, hard to understand what overrides what and what applies to what.

I believe that this is true of many types of development when a discipline is not applied, but I've also heard that there are strategies for managing CSS complexity, for example an approach called "BEM" I gather is widely used http://getbem.com/introduction/ .  

You asked: 

> > > What are the parts of W3C CSS that do not work for geospatial use case?

I believe that is THE important question.  Tom MacWright was a MapBox architect when he wrote this: https://blog.mapbox.com/the-end-of-cartocss-da2d7427cf1, which I think is full of wisdom that we need to take into account.  Wouldn't it be great if individuals with Tom's experience pitched in to build maps into the Web (standards)!

"CartoCSS is the language Mapbox created ... — a CSS-like syntax that renders static maps,"
  
In the section "Problems with CSS Syntax", Tom mentions that inventing a new (non-standard) CSS syntax "was a mistake".  I'm not sure how that's a problem with CSS, perhaps more so with CartoCSS.  

He also mentions "CSS is a language designed to style a document with an existing drawing order — HTML.", whereas maps need to draw the same data multiple times, without repeating the data.  So I guess that's a major issue that CartoCSS tried to solve.  I wonder if it mightn't be possible, instead of inventing a new syntax, for the mapping and SVG communities to compare notes to see if there are requirements/requests that could be brought to the CSS community and solved as a group?

There are also distinct use cases for styles: creation of static tiles (images), vector features (MapML) and vector tiles.  I wonder if they all require the same technology?  According to my reading of Tom's experience, I think the answer is "No".  

But, I think that the answer, for MapML, should be "let's try to use CSS+SVG, bringing requirements to the CSS+SVG community if necessary".  If  MapML can support vector tiles (I think it can [by reference/media type], TBD in Testbed 14), maybe we need a broader debate as to what the right approach for vector tiles in the Web platform is, not just for one company's technology needs.  For example, if the CSS structure and syntax standard could be extended to support maps, it would bring maps and map technology to the World, not expecting that the World should adapt wholesale to map technology.  That's the step I think we need to make, mentally, as a community.

I won't be in Palmerston, but I will be at the Testbed 13 demo in Reston the following week.  I look forward to chatting with anybody on this list about these and other topics.

Cheers,
Peter


Peter Rushforth

Technology Advisor
Canada Centre for Mapping and Earth Observation / Earth Sciences Sector
Natural Resources Canada / Government of Canada
peter.rushforth@canada.ca / Tel: 613-759-7915

Conseiller technique
Centre canadien de cartographie et d’observation de la Terre / Secteur des sciences de la Terre
Ressources naturelles Canada / Gouvernement du Canada
peter.rushforth@canada.ca / Tél: 613-759-7915

Received on Thursday, 30 November 2017 17:59:48 UTC