Hello Andrea,
just few clarifications in order to see if I correctly understood the issue
...
The main difference between solution a and b is that:
- in the a case we reproject the crossing side of the geometry by adding an
offset to the coordinates and lets say "force" someway the earth to not be
exactly round, then we merge the geometries again
- in the case b we cut the geometry in two different one, compute separately
the two pieces projection and then create a new multipolygon containing the
two pieces
As far as I understoond the solution a is not lets say fully correct from
a theoretical point of view, but simpler to achieve ... and since we are
speaking just about rendering we can live with this "limitation" I guess.
I would ask just two things ... in both cases is possible to have a seamless
wrap like google does, is that right?
Can we use those API changes on GeoTools 2.5 also someway in order to solve
the problem for GeoServer 1.7.x too?
-------------------------------------------------------
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 Wed, Nov 11, 2009 at 11:04 AM, Andrea Aime <aa...@opengeo.org> wrote:
> Hi,
> I've been recently assigned to look into the dateline rendering
> issues (not to solve them, just to analyze them), with particular
> interest in looking into polygon crossing the dateline and Google
> Maps like rendering, that is, seamless wrapping map:
>
> http://maps.google.com/?ie=UTF8&ll=25.799891,150.117188&spn=155.12213,360&z=2
>
> To make things more interesting the specific use case shows a projection
> in which the dateline effect has been moved away from -180/+180 using
> a non standard central meridian:
>
> PROJCS["WGS 84 / PDC Mercator",
> GEOGCS["WGS 84",
> DATUM["WGS_1984",
> SPHEROID["WGS 84",6378137,298.257223563,
> AUTHORITY["EPSG","7030"]],
> AUTHORITY["EPSG","6326"]],
> PRIMEM["Greenwich",0,
> AUTHORITY["EPSG","8901"]],
> UNIT["degree",0.01745329251994328,
> AUTHORITY["EPSG","9122"]],
> AUTHORITY["EPSG","4326"]],
> UNIT["metre",1,
> AUTHORITY["EPSG","9001"]],
> PROJECTION["Mercator_1SP"],
> PARAMETER["central_meridian",-150],
> PARAMETER["scale_factor",1],
> PARAMETER["false_easting",0],
> PARAMETER["false_northing",0],
> AUTHORITY["EPSG","3349"],
> AXIS["Easting",EAST],
> AXIS["Northing",NORTH]]
>
> The projection per se makes sense, it's what you want if whatever you
> want to show happens in the middle of the pacific ocean.
> The result of the projection does not look too good thought.
> I've tried with both GeoServer and ogr2ogr + qgis, the result is basically
> the same, see geoserver.png and qgis_ogr.gif
>
> What's happening? Well, first consider that the central_meridian
> trick above basically moves the break point at 30° EST, that's our
> new dateline.
> Both softwares do point by point reprojection, and when a point
> crosses the dateline the modular math kicks in, +181° -> -179° or,
> in our case with shifted data, +31° -> -329°. Then the projection
> happens and the next point gets kicked out at the other side of the
> world.
> Ah, with modular math I'm not necessarily referring to actual code
> chaning the longitude of the point, even without such code you have
> to take into account the cyclic nature of the trigonometric functions
> used during the map projections.
>
> Now, in general, what does one need to do to handle the dateline?
> I came up with two things, hopefully readers can add more:
> - if the query window spans the dateline, it has to be duplicated
> so that it queries also the other end of the world. E.g., if one
> has this lon/lat bbox: [170,0,190,80] the query should also include
> [-190,0,-170,90].
> Mind, we dont' cut the bboxes to the normal longitude range to
> accomodate data sources that are not geodetic aware and data that
> has been stored on purpose outside of the normal range to have it
> draw properly in a plate caree projection
> - when rendering the data with world wrapping projection (normal
> cylindrical, normal conic) the geometries crossing the dateline
> need special handling
>
> The "special handling" I can think of can follow two different approaches:
> a) during the geometry reprojection detect the dateline crossing
> and move the resulting coordinates so they follow the previous
> ones (e.g. add the x corresponding to the earth circumference).
> When done duplicate the geometry and create an offseted copy
> at the other end of the circle, so that in fact the geometry
> is drawn once per side of the rift
> b) cut the geometry at the dateline crossing and then reproject
> them separately
>
> The approach b) seems simpler but has two downsides:
> - there is no actual seamless continuation after the dateline,
> no google like effect
> - a fake border in correspondence of the dataline is introduced
> and it will be drawn on the map, but it's not there in the
> data
>
> Approach a) downside is that how you move the coordinate to
> get a seamless visual result is projection dependent.
>
> I've been looking into how other open source software deals
> with the issue and the only project I've found that properly
> draws polygons crossing the dataline is OpenMap.
> Attached you can see a normal cylindrical mercator map with
> the same shapefile as the other two screenshots, see openmap.gif
>
> Now, what do they do? Well, they use approach a), just the way
> they address is, is kind of unexpected.
> Basically all projection classes in OpenMap have a forwardPolygon
> method that is designed to reproject a source polygon onto the
> screen, using different techniques in the case the polygon is filled, or
> not. Yes, the projection classes are rendering aware
> (and of course there is a forwardXXX method for all geometric types).
>
> See for example the _forwardPoly method in:
>
> http://openmap.bbn.com/svn/openmap/trunk/src/openmap/com/bbn/openmap/proj/Cylindrical.java
>
> http://openmap.bbn.com/svn/openmap/trunk/src/openmap/com/bbn/openmap/proj/Azimuth.java
>
> http://openmap.bbn.com/svn/openmap/trunk/src/openmap/com/bbn/openmap/proj/LambertConformal.java
>
> http://openmap.bbn.com/svn/openmap/trunk/src/openmap/com/bbn/openmap/proj/UTMProjection.java
>
> Each projection class in turn implements custom handling of the
> dateline issue. I guess we can do the same without polluting
> the referencing subsystem by breaking strategy objects in the
> rendering subsystem that know how to deal with the oddities
> of each different projection.
>
> The current rendering code does all the coordinate to pixel mangling in
> one shot for performance reasons: the Decimator class actually decimates
> the original geometry and then applies a single transformation that deals
> with both the source to dest coordinate transformand and the world
> to screen affine transformation.
> We need those strategies to plugin somewhere in that code (or just after
> that code), decide if the geometry needs special handling, and if so,
> perform the cloning and the offsetting as needed and... I still haven't
> figure out that part.
>
> Anyways, looking forward to your feedback.
> Suggestions? Anyone interested in helping out?
>
> 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
> _______________________________________________
> Geotools-devel mailing list
> Geotools-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>
>
------------------------------------------------------------------------------
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
_______________________________________________
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
