Message-ID: <1320597990.94211.1397918473782.JavaMail.email@example.com> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_94210_105874758.1397918473781" ------=_Part_94210_105874758.1397918473781 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.=20
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:=20 =20
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:=20
Both kinds of transformations are useful:=20
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 exten= sion point for people to create whatever transformation they need.
Geometry transformations can be used in a number of cases. Here are some= example:=20
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.=20
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:=20 =20
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 tran= sformation (as transformations can be chained together, for example one cou= ld first perform an intersection and then buffer the result).
The patch attached also introduces samples of the above:=20
The patch also includes tests for the transformation machinery.=20
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.