Alessio Fabiani ha scritto: > 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
Not sure what you mean by "forcing the earth not to be exactly round" :-) What happens there is that we recognize the discontinuity in the reprojected output, we compensate for it by duplicating such geometry so that it's painted on both sides of the dateline. By doing so however we won't get a full Google Maps like effect, as geometries not crossing the dateline won't be duplicated. For example, see this: http://maps.google.com/?ie=UTF8&ll=19.973349,-41.132812&spn=156.4262,360&t=h&z=2 In the approach I describe, which is the one taken by OpenMap, Australia, not crossing the dateline, won't be duplicated. To do that we'd have to recognize that the display area is "larger than the world" and start duplicating also geometries that do not cross the dateline, but that sit in an area that is actually depicted twice on the screen. > - 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 Yes > 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. Nope, solution a) is harder to achieve, but might result in a nicer looking rendering effect for the mercator projection. > I would ask just two things ... in both cases is possible to have a > seamless wrap like google does, is that right? In case b) not at all, in case a) only if we also start replicating the geomtries of the non dateline crossing polygons as well. Case b) is simpler to achieve btw, the main drawback is that it will introduce sides in the polygons that were not supposed to be there (since by cutting we introduce a portion of the dateline into the mix). > Can we use those API changes on GeoTools 2.5 also someway in order to > solve the problem for GeoServer 1.7.x too? I honestly don't like the idea of doing such a backport, the changes are not trivial. Anyways, if that's the only way to get funding to do this work I think it's worth the pain. It's going to be more work thought, my initial estimate did not include it. 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
