Message-ID: <1470943657.41412.1371648868628.JavaMail.email@example.com> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_41411_1374671269.1371648868627" ------=_Part_41411_1374671269.1371648868627 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
This page provides some background of the concept of geometry transforma= tions in SLD, a tool that can be used to improve the rendering abilities an= d address some commonly requested rendering abilities.
The idea behind transformations is simple, instead of drawing the geomet= ry directly we plan to support its transformation into a different geometry= by means of a filter function declared in the SLD. For example:
Considering the rendering pipeline there are two steps in which a transf= ormation can be injected. Here is a list of the rendering steps with transf= ormations embedded into them:
Both kinds of transformations are useful:
The SE 1.1 specification seems to address, via a finite set of transform=
ations, both of them, depending on the unit of measure used in the symboliz=
This proposal is about going beyond, and having a pluggable extension point= for people to create whatever transformation they need.
Geometry transformations can be used in a number of cases. Here are some= example:
During the code sprint at FOSS4G 2009 a tentative geometry transformatio= n implementation has been created that addresses only the first type of tra= nsformation, the one operating in real world coordinates.
The changes needed to support a simple version of it in the streaming re=
nderer are not big, neither are those required in the parsing. Some API cha=
nges were needed so that Symbolizer.getGeometry() returns a generic Express=
ion instead of a PropertyName.
The patch to trunk = is attached to this page for review.
Besides the changes in the GeoTools Symbolizer interfaces the other new = piece of API is the GeometryTransformation interface:
The interface should be implemented by all transformation that do change=
the location of the geometry during the transformation, and it's used by t=
he renderer to guess the query area given the display area. For example, a =
buffer transformation will require an extended query area to catch those fe=
ature that are sitting out of the display area, but whose buffer crosses in=
to the display area.
The renderer uses a visitor to get the full transformation (as transformati= ons can be chained together, for example one could first perform an interse= ction and then buffer the result).
The patch attached also introduces samples of the above:
The patch also includes tests for the transformation machinery.
The future of this work requires the implementation of more transformati= ons and the ability to perform transformations in pixel space as well. This= could be implemented, for example, by using a visitor that takes the trans= formation and wraps the geometry accesses within a further transformation t= hat applies the generalization, reprojection and world to screen transforma= tions.------=_Part_41411_1374671269.1371648868627--