- From: Little, Chris <chris.little@metoffice.gov.uk>
- Date: Thu, 30 Nov 2017 12:08:22 +0000
- To: "Rushforth, Peter (NRCan/RNCan)" <peter.rushforth@canada.ca>
- CC: "public-sdwig@w3.org" <public-sdwig@w3.org>
Peter,
This is the thread about style sheets and interoperability that recently re-emerged.
Chris
-----Original Message-----
From: TC-Discuss [mailto:tc-discuss-bounces+chris.little=metoffice.gov.uk@lists.opengeospatial.org] On Behalf Of Little, Chris via TC-Discuss
Sent: Wednesday, November 29, 2017 1:48 PM
To: Jérôme St-Louis <jerome@ecere.com>
Cc: rcass@compusult.net; tc-discuss@lists.opengeospatial.org
Subject: Re: [TC-Discuss] Symbology Standardization
Jérôme,
Thank you. That is a really helpful page of information and experience. I look forward to good discussion and resolutions.
Chris
> -----Original Message-----
> From: Jérôme St-Louis [mailto:jerome@ecere.com]
> Sent: Wednesday, November 29, 2017 12:33 PM
> To: Little, Chris <chris.little@metoffice.gov.uk>;
> b.j.kobben@utwente.nl
> Cc: tc-discuss@lists.opengeospatial.org; rcass@compusult.net
> Subject: Re: [TC-Discuss] Symbology Standardization
>
> Chris,
>
> 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.
>
> A key goal of our approach is that a style sheet is very intuitive to
> understand and hand-edit, matching almost directly the visual
> representation we present in our styles editor UI.
> The way we propose selectors to combine and rules to override parent
> rules, tweaking only some style properties, makes it very simple to
> follow even complex styling rules.
>
> 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.
>
> That being said, perhaps it would be useful once we have settled on
> our approach to map aspects of it to integrate within CSS, especially
> with the new HTML map tag.
>
> 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.
>
> We are still in a crazy rush for Testbed 13 before I leave on Friday
> so I won't have too much time to discuss, but I would be happy to
> during the week in New Zealand.
> Feel free to bring up our proposed ideas and keen interest to
> participate in this at the telco; I would be happy to join a later
> one, and I hope to meet some of them at the TC as well!
>
> Best regards,
>
> -Jerome
>
> On 2017-11-29 7:01 AM, Little, Chris wrote:
> > Jerome,
> >
> > Have you any interest in making it more compatible/interoperable
> > with
> W3C CSS?
> >
> > What are the parts of W3C CSS that do not work for geospatial use case?
> Apart from establishing 'proprietary' lock-in, are there any
> specialities in OSM MapCSS and MapBox CartoCSS that distinguish them,
> or are they all basically similar?
> >
> > There is a plenary meeting (telco) tonight at 20:00 UTC of the joint
> > OGC/W3C Spatial Data on the Web Interest Group (preceded by the SDW
> > Best Practice maintenance Sub-Group at 19:00 UTC)
> >
> > Maybe this could be raised with them as a topic of future interest?
> > The
> group has only just started.
> >
> > We could discuss this next week.
> >
> > Chris
> >
> >> -----Original Message-----
> >> From: TC-Discuss [mailto:tc-discuss-
> >> bounces+chris.little=metoffice.gov.uk@lists.opengeospatial.org] On
> >> bounces+Behalf
> >> Of Jérôme St-Louis via TC-Discuss
> >> Sent: Wednesday, November 29, 2017 10:36 AM
> >> To: b.j.kobben@utwente.nl; tc-discuss@lists.opengeospatial.org
> >> Subject: Re: [TC-Discuss] Symbology Standardization
> >>
> >> Dear Barend,
> >>
> >> The rationale for it is that it is partly inspired by ECON (eC
> >> Object Notation -- http://ec-lang.org/econ/), which is itself very
> >> close to JSON (and defined as a superset to be compatible).
> >>
> >> However JSON or ECON does not lend itself well to defining a
> >> complex hierarchy of rules, so that some styles can be applied
> >> generally, to a number of features, and then additional styles can
> >> further be refined for additional selectors.
> >> Also generally speaking adding and combining selectors as code
> >> expressions is not easily embedded within that hierarchy.
> >>
> >> For this hierarchy & selector part of the syntax, it is similar in
> >> form to web CSS, OpenStreetMap's MapCSS and Mapbox's CartoCSS.
> >>
> >> All the best,
> >>
> >> -Jerome
> >>
> >> On 2017-11-29 5:14 AM, b.j.kobben@utwente.nl wrote:
> >>> Interesting to see. I do wonder why you seem to have chosen a
> >>> syntax that
> >> is very close, but not actually, JSON...
> >>> --
> >>> Barend Köbben
> >>>
> >>>
> >>> On 29/11/2017, 03:40, "TC-Discuss on behalf of Jérôme St-Louis via
> >>> TC-
> >> Discuss" <tc-discuss-bounces@lists.opengeospatial.org on behalf of
> >> tc- discuss@lists.opengeospatial.org> wrote:
> >>> All,
> >>> Sorry to be jumping in but we've had some experience with
> >>> SLD/SE in
> >> both Arctic SDP and Testbed 13/Vector Tiles work package, and as a
> >> result we've started coming up with a very compact way to describe
> >> styles which we hope to become or contribute to an open
> >>> standard. I will be at the Palmerston North TC and would
> >>> love to discuss
> >> this further with the relevant groups / people.
> >>> Our ideas address both the expressiveness of the styling
> >>> language so as ,
> >> as well as some issues resulting from SLD being used mainly for
> >> producing offline tiles and thus difficult to reconcile with high
> >> performance rendering (e.g. repeating mention of layers
> >>> many times as opposed to concisely defining how a layer
> >>> should be rendered in a single definition). One such issue was
> >>> filed as
> >>>
> >>> http://ogc.standardstracker.org/show_request.cgi?id=519
> >> <http://ogc.standardstracker.org/show_request.cgi?id=519>
> >>> We're also using it for both cartographic projections and 3D
> >> environments.
> >>> Here's a glimpse of how the prototype looks like so far:
> >>>
> >>> #Roads
> >>> {
> >>> [scale>=1000][scale<=15000][FEATCODE in
> >> (15710,15719,15723,15729,15735,15739,15743,15749,15750,15759)]
> >>> {
> >>> line = { width = Meters { 17 }, color = 0xff505050,
> >>> cap = butt, join =
> >> round }
> >>> }
> >>> }
> >>>
> >>>
> >>> We want this to become very flexible, up to the point where
> >>> it could fully
> >> describe very complex symbology standards like S-52 for example.
> >>> There will be a brief section about our styling experience
> >>> in the DS001
> >> Vector Tiles ER from Tesbed 13.
> >>> Best regards,
> >>> ________________________________________
> >>> Jérôme Jacovella-St-Louis
> >>> Founder, Chief Technology Officer
> >>> Ecere Corporation http://ecere.ca <http://ecere.ca/>
> >>> jerome@ecere.com
> >>> (819) 663-8539 <tel:%28819%29%20663-8539>
> >>>
> >>>
> >>> On 2017-11-28 1:39 PM, Little, Chris via TC-Discuss wrote:
> >>>
> >>>
> >>> Rob,
> >>>
> >>> I have spent some time rummaging around and the presentation
> >>> that sparked the discussion was at Geneva 2014 TC
> >>> https://portal.opengeospatial.org/files/?artifact_id=59278
> >>>
> >>> This is probably about Testbed 11, but no idea whether it
> >>> made it into
> >> one.
> >>> HTh, Chris
> >>>
> >>> From: Rob Cass [mailto:rcass@compusult.net]
> >>>
> >>> Sent: Wednesday, November 01, 2017 12:19 PM
> >>> To: Ron Lake
> >>> <rlake@galdosinc.com> <mailto:rlake@galdosinc.com>; Little, Chris
> >>> <chris.little@metoffice.gov.uk>
> <mailto:chris.little@metoffice.gov.uk>;
> >>> tc-discuss@lists.opengeospatial.org <mailto:tc-
> >> discuss@lists.opengeospatial.org>
> >>> Subject: Re: [TC-Discuss] Symbology Standardization
> >>>
> >>>
> >>>
> >>> Ron,
> >>>
> >>> Was this work documented somewhere? Was this work related
> >>> back to
> >> the OWS-8 work on portrayal registries?
> >>> Also,
> >>>
> >>> Chris, was the LEAPS effort documented as well? Was it testbed 11?
> >>>
> >>> Thanks,
> >>> Rob
> >>>
> >>> On 2017-10-31 05:38 PM, Ron Lake via TC-Discuss wrote:
> >>>
> >>>
> >>> The idea of symbol set management and access interfaces is
> >>> covered by
> >> the notion of a registry of symbols. We did some work on this
> >> within the
> >>> OGC using ebRIM in the aviation context.
> >>>
> >>>
> >>>
> >>> Ron
> >>>
> >>>
> >>>
> >>>
> >>> Get
> >>> Outlook for iOS <https://aka.ms/o0ukef>
> >>>
> >>>
> >>>
> >>> ________________________________________
> >>>
> >>> From: Little, Chris
> >>> <chris.little@metoffice.gov.uk>
> <mailto:chris.little@metoffice.gov.uk>
> >>> Sent: Tuesday, October 31, 2017 1:02:15 PM
> >>> To:
> >>> tc-discuss@lists.opengeospatial.org <mailto:tc-
> >> discuss@lists.opengeospatial.org>
> >>> Cc: Roger Lott (EPSG); 'Tisdale, John'; Thomas Kolbe; Ron Lake
> >>> Subject: RE: [TC-Discuss] Symbology Standardization
> >>>
> >>>
> >>>
> >>> John, and other colleagues,
> >>>
> >>> Meteorology has had a long history of symbology
> >>> standardisation,
> >> outside of OGC, within the UN’s WMO and also ICAO for aviation.
> >> Ergonomics with dim lighting and the safety critical aspects are
> >> important
> requirements.
> >>> The colour gamut of the symbols is extremely limited –
> >>> basically black
> >> and red as these are the only readily available archival (~500
> >> years!) inks/dyes.
> >>>
> >>> A few years ago, the OGC LEAPS DWG, now part of the EDM DWG,
> >> proposed loads of complex symbols to be standardised, and the
> >> gentle steer given to them was to not standardise the specific
> >> instances, but to standardise
> >>> the symbol set management and interfaces. Nothing done as
> >>> yet as far
> >> as I know.
> >>> In Southampton, I raised the issue of 3D compatibility of
> >>> existing 2D
> >> approaches (such as SLD/SE) for use in 3D AR/VR environments. I do
> >> not foresee this being difficult. Map Styles/3D Scene are more
> problematic.
> >>> HTH, Chris
> >>>
> >>> From: TC-Discuss [mailto:tc-discuss-
> bounces@lists.opengeospatial.org]
> >>> On Behalf Of Roger Lott (EPSG) via TC-Discuss
> >>> Sent: Thursday, October 26, 2017 9:25 AM
> >>> To: 'Tisdale, John'
> >>> <JTISDALE@eprod.com> <mailto:JTISDALE@eprod.com>
> >>> Cc:
> >>> tc-discuss@lists.opengeospatial.org <mailto:tc-
> >> discuss@lists.opengeospatial.org>
> >>> Subject: Re: [TC-Discuss] Symbology Standardization
> >>>
> >>>
> >>>
> >>> John,
> >>>
> >>> The upstream oil industry has some work on this. See
> >>> http://www.iogp.org/Geomatics/#geo-information for the Shell
> >> standard legend as augmented by IOGP to support the Seabed Survey
> >> Data Model. Despite its name it has been adopted
> >>> by other operators and IOGP as an industry standard. This
> >>> is suitable for
> >> medium and small scale mapping so not going to address engineering
> >> detail, but you might build on it especially the general symbology
> >> in section 3. Note that there are two versions,
> >>> oil = green (and gas = red) and vice-versa. There is no
> >>> global consensus
> >> on the colour convention, and one or the other is mandated for
> >> reporting to various national governmental authorities. So both are
> >> required. I suggest that the preference is for oil =
> >>> green but you must allow for the other convention and the
> >>> convention
> >> in use should be stated (although it can be determined through
> >> examination of the different symbol codes). The strategy is to
> >> publish both legend and symbol set.
> >>> Roger
> >>>
> >>> From: TC-Discuss [mailto:tc-discuss-
> >> bounces+epsg.rl=btinternet.com@lists.opengeospatial.org]
> >>> On Behalf Of Tisdale, John via TC-Discuss
> >>> Sent: 23 October 2017 22:22
> >>> To:
> >>> tc-discuss@lists.opengeospatial.org <mailto:tc-
> >> discuss@lists.opengeospatial.org>
> >>> Subject: [TC-Discuss] Symbology Standardization
> >>>
> >>>
> >>>
> >>> Dear Technical Committee,
> >>>
> >>> The PipelineML SWG is discussing concepts for standardizing
> >>> symbology
> >> at various levels of detail. Is there an existing strategy for doing so?
> >>> Thanks,
> >>> John Tisdale
> >>> Co-chair PipelineML SWG
> >>>
> >>>
> >>> ________________________________________
> >>>
> >>>
> >>> This message (including any attachments) is confidential and
> >>> intended
> >> for a specific individual and purpose. If you are not the intended
> >> recipient, please notify the sender immediately and delete this message.
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> _______________________________________________TC-
> Discuss
> >> mailing
> >>> listTC-Discuss@lists.opengeospatial.org This is an auto-subscribe
> >>> list. All OGC members are encouraged to maintain a subscription to
> >>> this list. You may change your delivery options in the "Email
> >>> Subscriptions" portion of "My Account" in the OGC Web Portal.
> >>> https://portal.opengeospatial.org/?m=users&a=viewuser&tab=3
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> TC-Discuss mailing list
> >>> TC-Discuss@lists.opengeospatial.org
> >>>
> >>> This is an auto-subscribe list. All OGC members are
> >>> encouraged to
> >> maintain a subscription to this list. You may change your delivery
> >> options in the "Email Subscriptions" portion of "My Account" in the
> >> OGC
> Web Portal.
> >>> https://portal.opengeospatial.org/?m=users&a=viewuser&tab=3
> >>>
> >>>
> >>>
> >>>
> >> _______________________________________________
> >> TC-Discuss mailing list
> >> TC-Discuss@lists.opengeospatial.org
> >>
> >> This is an auto-subscribe list. All OGC members are encouraged to
> >> maintain a subscription to this list. You may change your delivery
> >> options in the "Email Subscriptions" portion of "My Account" in the
> >> OGC
> Web Portal.
> >>
> >> https://portal.opengeospatial.org/?m=users&a=viewuser&tab=3
_______________________________________________
TC-Discuss mailing list
TC-Discuss@lists.opengeospatial.org
This is an auto-subscribe list. All OGC members are encouraged to maintain a subscription to this list. You may change your delivery options in the "Email Subscriptions" portion of "My Account" in the OGC Web Portal.
https://portal.opengeospatial.org/?m=users&a=viewuser&tab=3
Received on Thursday, 30 November 2017 14:27:53 UTC