svg:transform for mapping

Editor’s Draft,

This version:
http://dev.w3.org/fxtf/motion-1/
Feedback:
www-svg@w3.org with subject line “[transform-mapping] … message topic …” (archives)
Editor:
(KDDI Corporation)

Copyright © 2015 W3C® (MIT, ERCIM, Keio, Beihang). W3C liability, trademark and document use rules apply.

Abstract

This specification gives guidance how the SVG transform attribute in the SVG namespace can be used in other context than SVG.

Status of this document

This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.

This document is the 13 February 2015 Editor’s Draft of svg:transform for mapping.

Comments on this Editor’s Draft are welcome. Comments can be sent to www-svg@w3.org, the public email list for issues related to vector graphics on the Web. This list is archived and senders must agree to have their message publicly archived from their first posting. To subscribe send an email to www-svg-request@w3.org with the word subscribe in the subject line.

This document has been produced by the SVG Working Group as part of the Graphics Activity within the W3C Interaction Domain. The goals of the W3C SVG Working Group are discussed in the W3C SVG Charter. The W3C SVG Working Group maintains a public Web page, http://www.w3.org/Graphics/SVG/, that contains further background information. The authors of this document are the SVG Working Group participants.

This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of each group; these pages also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.

A list of current W3C Recommendations and other technical documents can be found at http://www.w3.org/TR/. W3C publications may be updated, replaced, or obsoleted by other documents at any time.

Table of contents

1. Geographic coordinate systems

In order to allow interoperability between SVG content generators and user agents dealing with maps encoded in SVG, the use of a common metadata definition for describing the coordinate system used to generate SVG documents is encouraged.

Such metadata must be added under the metadata element of the topmost svg element describing the map, consisting of an RDF description of the Coordinate Reference System definition used to generate the SVG map [RDF-PRIMER]. Note that the presence of this metadata does not affect the rendering of the SVG in any way; it merely provides added semantic value for applications that make use of combined maps.

The definition must be conformant to the XML grammar described in GML 3.2.1, an OpenGIS Standard for encoding common CRS data types in XML [GML]. In order to correctly map the 2-dimensional data used by SVG, the CRS must be of subtype ProjectedCRS or Geographic2dCRS. The first axis of the described CRS maps the SVG x-axis and the second axis maps the SVG y-axis.

The main purpose of such metadata is to indicate to the user agent that two or more SVG documents can be overlayed or merged into a single document. Obviously, if two maps reference the same Coordinate Reference System definition and have the same SVG transform property value then they can be overlayed without reprojecting the data. If the maps reference different Coordinate Reference Systems and/or have different SVG transform property values, then a specialized cartographic user agent may choose to transform the coordinate data to overlay the data. However, typical SVG user agents are not required to perform these types of transformations, or even recognize the metadata. It is described in this specification so that the connection between geographic coordinate systems and the SVG coordinate system is clear.

2. The 'svg:transform' attribute

Attribute definition:

svg:transform = <transform-list> | none
<transform-list>

Specifies the affine transformation that has been applied to the map data. The syntax is identical to that described for the transform property.

none

Specifies that no supplemental affine transformation has been applied to the map data. Using this value has the same meaning as specifying the identity matrix, which in turn is just the same as not specifying the svg:transform the attribute at all.

Animatable: no.

This attribute describes an optional additional affine transformation that may have been applied during this mapping. This attribute may be added to the OpenGIS CoordinateReferenceSystem element. Note that, unlike the transform property, it does not indicate that a transformation is to be applied to the data within the file. Instead, it simply describes the transformation that was already applied to the data when being encoded in SVG.

There are three typical uses for the svg:transform global attribute. These are described below and used in the examples.

Below is a simple example of the coordinate metadata, which describes the coordinate system used by the document via a URI.

<?xml version="1.0"?>
<svg xmlns="http://www.w3.org/2000/svg"
     width="100" height="100" viewBox="0 0 1000 1000">

  <desc>An example that references coordinate data.</desc>

  <metadata>
    <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
             xmlns:crs="http://www.ogc.org/crs"
             xmlns:svg="http://www.w3.org/2000/svg">
      <rdf:Description rdf:about="">
        <!-- The Coordinate Reference System is described
             through a URI. -->
        <crs:CoordinateReferenceSystem
            svg:transform="rotate(-90)"
            rdf:resource="http://www.example.org/srs/epsg.xml#4326"/>
      </rdf:Description>
    </rdf:RDF>
  </metadata>

  <!-- The actual map content -->
</svg>

The second example uses a well-known identifier to describe the coordinate system. Note that the coordinates used in the document have had the supplied transform applied.

<?xml version="1.0"?>
<svg xmlns="http://www.w3.org/2000/svg"
     width="100" height="100" viewBox="0 0 1000 1000">

  <desc>Example using a well known coordinate system.</desc>

  <metadata>
    <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
             xmlns:crs="http://www.ogc.org/crs"
             xmlns:svg="http://www.w3.org/2000/svg">
      <rdf:Description rdf:about="">
        <!-- In case of a well-known Coordinate Reference System
             an 'Identifier' is enough to describe the CRS -->
        <crs:CoordinateReferenceSystem svg:transform="rotate(-90) scale(100, 100)">
          <crs:Identifier>
            <crs:code>4326</crs:code>
            <crs:codeSpace>EPSG</crs:codeSpace>
            <crs:edition>5.2</crs:edition>
          </crs:Identifier>
        </crs:CoordinateReferenceSystem>
      </rdf:Description>
    </rdf:RDF>
  </metadata>

  <!-- The actual map content -->
</svg>

The third example defines the coordinate system completely within the SVG document.

<?xml version="1.0"?>
<svg xmlns="http://www.w3.org/2000/svg"
     width="100" height="100" viewBox="0 0 1000 1000">

  <desc>Coordinate metadata defined within the SVG document</desc>

  <metadata>
    <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
             xmlns:crs="http://www.ogc.org/crs"
             xmlns:svg="http://www.w3.org/2000/svg">
      <rdf:Description rdf:about="">
        <!-- For other CRS it should be entirely defined -->
        <crs:CoordinateReferenceSystem svg:transform="scale(1,-1)">
          <crs:NameSet>
            <crs:name>Mercator projection of WGS84</crs:name>
          </crs:NameSet>
          <crs:ProjectedCRS>
            <!-- The actual definition of the CRS -->
            <crs:CartesianCoordinateSystem>
              <crs:dimension>2</crs:dimension>
              <crs:CoordinateAxis>
                <crs:axisDirection>north</crs:axisDirection>
                <crs:AngularUnit>
                  <crs:Identifier>
                    <crs:code>9108</crs:code>
                    <crs:codeSpace>EPSG</crs:codeSpace>
                    <crs:edition>5.2</crs:edition>
                  </crs:Identifier>
                </crs:AngularUnit>
              </crs:CoordinateAxis>
              <crs:CoordinateAxis>
                <crs:axisDirection>east</crs:axisDirection>
                <crs:AngularUnit>
                  <crs:Identifier>
                    <crs:code>9108</crs:code>
                    <crs:codeSpace>EPSG</crs:codeSpace>
                    <crs:edition>5.2</crs:edition>
                  </crs:Identifier>
                </crs:AngularUnit>
              </crs:CoordinateAxis>
            </crs:CartesianCoordinateSystem>
            <crs:CoordinateReferenceSystem>
              <!-- the reference system of that projected system is
                         WGS84 which is EPSG 4326 in EPSG codeSpace -->
              <crs:NameSet>
                <crs:name>WGS 84</crs:name>
              </crs:NameSet>
              <crs:Identifier>
                <crs:code>4326</crs:code>
                <crs:codeSpace>EPSG</crs:codeSpace>
                <crs:edition>5.2</crs:edition>
              </crs:Identifier>
            </crs:CoordinateReferenceSystem>
            <crs:CoordinateTransformationDefinition>
              <crs:sourceDimensions>2</crs:sourceDimensions>
              <crs:targetDimensions>2</crs:targetDimensions>
              <crs:ParameterizedTransformation>
                <crs:TransformationMethod>
                  <!-- the projection is a Mercator projection which is
                        EPSG 9805 in EPSG codeSpace -->
                  <crs:NameSet>
                    <crs:name>Mercator</crs:name>
                  </crs:NameSet>
                  <crs:Identifier>
                    <crs:code>9805</crs:code>
                    <crs:codeSpace>EPSG</crs:codeSpace>
                    <crs:edition>5.2</crs:edition>
                  </crs:Identifier>
                  <crs:description>Mercator (2SP)</crs:description>
                </crs:TransformationMethod>
                <crs:Parameter>
                  <crs:NameSet>
                    <crs:name>Latitude of 1st standart parallel</crs:name>
                  </crs:NameSet>
                  <crs:Identifier>
                    <crs:code>8823</crs:code>
                    <crs:codeSpace>EPSG</crs:codeSpace>
                    <crs:edition>5.2</crs:edition>
                  </crs:Identifier>
                  <crs:value>0</crs:value>
                </crs:Parameter>
                <crs:Parameter>
                  <crs:NameSet>
                    <crs:name>Longitude of natural origin</crs:name>
                  </crs:NameSet>
                  <crs:Identifier>
                    <crs:code>8802</crs:code>
                    <crs:codeSpace>EPSG</crs:codeSpace>
                    <crs:edition>5.2</crs:edition>
                  </crs:Identifier>
                  <crs:value>0</crs:value>
                </crs:Parameter>
                <crs:Parameter>
                  <crs:NameSet>
                    <crs:name>False Easting</crs:name>
                  </crs:NameSet>
                  <crs:Identifier>
                    <crs:code>8806</crs:code>         
                    <crs:codeSpace>EPSG</crs:codeSpace>
                    <crs:edition>5.2</crs:edition>
                  </crs:Identifier>
                  <crs:value>0</crs:value>
                </crs:Parameter>
                <crs:Parameter>
                  <crs:NameSet>
                    <crs:name>False Northing</crs:name>
                  </crs:NameSet>
                  <crs:Identifier>
                    <crs:code>8807</crs:code>
                    <crs:codeSpace>EPSG</crs:codeSpace>
                    <crs:edition>5.2</crs:edition>
                  </crs:Identifier>
                  <crs:value>0</crs:value>
                </crs:Parameter>
              </crs:ParameterizedTransformation>
            </crs:CoordinateTransformationDefinition>
          </crs:ProjectedCRS>
        </crs:CoordinateReferenceSystem>
      </rdf:Description>
    </rdf:RDF>
  </metadata>

  <!-- the actual map content -->
</svg>

Conformance

Document conventions

Conformance requirements are expressed with a combination of descriptive assertions and RFC 2119 terminology. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in the normative parts of this document are to be interpreted as described in RFC 2119. However, for readability, these words do not appear in all uppercase letters in this specification.

All of the text of this specification is normative except sections explicitly marked as non-normative, examples, and notes. [RFC2119]

Examples in this specification are introduced with the words "for example" or are set apart from the normative text with class="example", like this:

This is an example of an informative example.

Informative notes begin with the word "Note" and are set apart from the normative text with class="note", like this:

Note, this is an informative note.

Advisements are normative sections styled to evoke special attention and are set apart from other normative text with <strong class="advisement">, like this: UAs MUST provide an accessible alternative.

Conformance classes

Conformance to this specification is defined for three conformance classes:

style sheet
A CSS style sheet.
renderer
A UA that interprets the semantics of a style sheet and renders documents that use them.
authoring tool
A UA that writes a style sheet.

A style sheet is conformant to this specification if all of its statements that use syntax defined in this module are valid according to the generic CSS grammar and the individual grammars of each feature defined in this module.

A renderer is conformant to this specification if, in addition to interpreting the style sheet as defined by the appropriate specifications, it supports all the features defined by this specification by parsing them correctly and rendering the document accordingly. However, the inability of a UA to correctly render a document due to limitations of the device does not make the UA non-conformant. (For example, a UA is not required to render color on a monochrome monitor.)

An authoring tool is conformant to this specification if it writes style sheets that are syntactically correct according to the generic CSS grammar and the individual grammars of each feature in this module, and meet all other conformance requirements of style sheets as described in this module.

Partial implementations

So that authors can exploit the forward-compatible parsing rules to assign fallback values, CSS renderers must treat as invalid (and ignore as appropriate) any at-rules, properties, property values, keywords, and other syntactic constructs for which they have no usable level of support. In particular, user agents must not selectively ignore unsupported component values and honor supported values in a single multi-value property declaration: if any value is considered invalid (as unsupported values must be), CSS requires that the entire declaration be ignored.

Experimental implementations

To avoid clashes with future CSS features, the CSS2.1 specification reserves a prefixed syntax for proprietary and experimental extensions to CSS.

Prior to a specification reaching the Candidate Recommendation stage in the W3C process, all implementations of a CSS feature are considered experimental. The CSS Working Group recommends that implementations use a vendor-prefixed syntax for such features, including those in W3C Working Drafts. This avoids incompatibilities with future changes in the draft.

Non-experimental implementations

Once a specification reaches the Candidate Recommendation stage, non-experimental implementations are possible, and implementors should release an unprefixed implementation of any CR-level feature they can demonstrate to be correctly implemented according to spec.

To establish and maintain the interoperability of CSS across implementations, the CSS Working Group requests that non-experimental CSS renderers submit an implementation report (and, if necessary, the testcases used for that implementation report) to the W3C before releasing an unprefixed implementation of any CSS features. Testcases submitted to W3C are subject to review and correction by the CSS Working Group.

Further information on submitting testcases and implementation reports can be found from on the CSS Working Group’s website at http://www.w3.org/Style/CSS/Test/. Questions should be directed to the public-css-testsuite@w3.org mailing list.

References

Normative References

[rfc2119]
S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. March 1997. Best Current Practice. URL: https://tools.ietf.org/html/rfc2119

Informative References

[rdf-primer]
Frank Manola; Eric Miller. RDF Primer. 10 February 2004. REC. URL: http://www.w3.org/TR/rdf-primer/

Index