Re: [Geotools-devel] [Geoserver-devel] Dateline wrapping code committed on trunk

[Alessio F. <ale...@gm...>]

Great work,
really cool.

Thanks Andrea.

-------------------------------------------------------
Eng. Alessio Fabiani
Founder / CTO GeoSolutions S.A.S.
Via Carignoni 51
55041  Camaiore (LU)
Italy

phone: +39 0584 980933
fax:      +39 0584 983027
mob:    +39 349 8227000

http://www.geo-solutions.it
http://geo-solutions.blogspot.com
-------------------------------------------------------


On Tue, Nov 24, 2009 at 11:08 AM, Andrea Aime <aa...@op...> wrote:

> Hi,
> I write to follow up the dateline wrapping discussion (and to thank
> GeoSolutions for sponsoring this work).
>
> I've just committed, only on trunk, code to perform proper processing
> of projection singularities and dateline wrapping on selected projections,
> in particular, Mercator, Transverse Mercator, and flat
> geographic.
>
> You can see the results in the screenshots I've attached.
> The 3349 is the mercator with longitude origin moved 130° away
> (thus centered in the pacific ocean), 900913 is the usual Google
> projection, 32632 is UTM 32N.
>
> In all projections the geometries have been cut in a valid area
> before being reprojected, in the two Mercator ones dateline wrapping
> has been performed.
>
> The classes performing the magic are here:
>
> http://svn.osgeo.org/geotools/trunk/modules/library/render/src/main/java/org/geotools/renderer/crs/
>
> Given we cannot rely on the CRS itself to state what is the valid
> area (EPSG contains some definitions, but WKT definitions don't)
> the ProjectionHandler classes assume a valid area computed from
> the projection parameters, relying on knowledge of the math of
> projection itself.
>
> As you can see the ProjectionHandler is a class, not an interface.
> This is because I don't know exactly how it will evolve. For one,
> the class does not handle coverages, and in the future we'll
> want to handle wrapping coverages as well.
>
> Moreover the finder does not rely on SPI atm. This is because I'm
> not sure we want to use SPI to start with.
> What if, for example, people want to manually provide projection
> handlers to have more control over them?
>
> This is basically the reason the API is not fully fleshed out,
> simply because I don't know, as of now, how a long term shape
> will look like. Suggestions welcomed.
>
> Since this is a new feature it is not enabled by default, a rendering
> hint has to be provided:
> rendererParams.put(StreamingRenderer.ADVANCED_PROJECTION_HANDLING_KEY,
> true);
>
> This should allow backporting the changes to 2.6.x and 2.5.x without
> breaking any existing code, as the new paths will lie dormant unless
> explicitly activated (both backports are required in order to
> get this one funded).
>
> On GeoServer trunk I've enabled them by default to allow people to check
> this functionality out.
>
> Going forward I'd like to add projection handlers to a few more
> common projections (Stereographic, Lambert), add unit tests, and
> backport.
>
> Comments?
>
> Cheers
> Andrea
>
> --
> Andrea Aime
> OpenGeo - http://opengeo.org
> Expert service straight from the developers.
>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus
> on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Geoserver-devel mailing list
> Geo...@li...
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>
>