Administrator

Hi,
a question from a user in the gt2users list made me wonder about performing all the JTS operations in geodetic space (e.g., wgs84 coordinates). Am I right in assuming that only the operations using concepts of distance and angle are affected? I mean, if we take a set theory operation such as intersect, difference, overlap tests and the like, they should not be affected at all by the lon/lat nature of the data. The reasoning is that we could find a projection that allows to make the computations in metric space, and if the projection is a continuous transformation, the set related properties should not be affected, the intersection points of a geometry would be the same as if we intersected them using the ellipsoidal geometry, no? (I am sure for things such as point containment, not as sure about intersection... do any of you has the right math background to prove/disprove this statement?). If this is true, the major operations that are left out is the Buffer one and distance one (am I missing any?). For doing distance/angle computation in geodetic space in GT2 we have this GeodeticCalculator class, that given a starting point, a metric distance and an azimuth can compute a resulting point, or vice versa, given two points can compute the distance and the angle. If I were to compute the buffer of a line in geodetic space, I could conceivably use that class to trace the buffer shell of simple line segments using a sampling approach, but alike what is done for the round endcaps in metric space. And then all I would have to do is to union all those tiny buffers, which is a set operation, so unaffected by the geodetic nature of the coordinates. The same could be done for polygons, so ultimately for all kinds of geometries supported by JTS. If this line of reasoning is correct, this would be a nice project for a summer of code student. Opinions? Cheers Andrea  Andrea Aime OpenGeo  http://opengeo.org Expert service straight from the developers. _______________________________________________ jtsdevel mailing list [hidden email] http://lists.refractions.net/mailman/listinfo/jtsdevel 
Andrea,
I am not a geodesist, and I am pretty sure there will be other experts that respond. But my initial thought is that it will be harder to do this type of thing than it will seem on the surface. I have some minimal exposure to geodesy and I think this would likely require another library, or at least a separate small group of classes. Here are a couple of examples of the problems that can come up: A triangle is supposed to have interior angles that sum to 180 degrees. But as the size of a triangle (or any other polygon) on the Earth's surface increases in size, the sum of the interior angles becomes greater because of "speherical excess". Two points are the same distance from the north pole on the different meridians (lines of longitude). A straight line between the two points on the surface of the Earth is not a line of latitude. A line of latitude between the two points would actually be an arc, not a straight line. This becomes more pronounced as you move to the poles. A surveyor sets up his angle measuring device at one point on the Earth's surface, sights the north pole, and turns a perfect 90 degree angle. He then runs that same line (due east or west) across the surface of the Earth. The line he runs actually changes direction as you move away from the instrument point. (This is related to the item above.) I think some of these problems would need to be addressed in a geodetic geometry library. This is a topic I am very interested in, so if I can help in some way, please let me know. The Sunburned Surveyor On Wed, Nov 5, 2008 at 1:41 AM, Andrea Aime <[hidden email]> wrote: > Hi, > a question from a user in the gt2users list made me wonder about performing > all the JTS operations in geodetic space (e.g., wgs84 > coordinates). > > Am I right in assuming that only the operations using concepts of distance > and angle are affected? I mean, if we take a set theory > operation such as intersect, difference, overlap tests and the like, > they should not be affected at all by the lon/lat nature of the > data. The reasoning is that we could find a projection that > allows to make the computations in metric space, and if > the projection is a continuous transformation, the set related > properties should not be affected, the intersection points of > a geometry would be the same as if we intersected them using > the ellipsoidal geometry, no? (I am sure for things such as > point containment, not as sure about intersection... do any > of you has the right math background to prove/disprove > this statement?). > > If this is true, the major operations that are left > out is the Buffer one and distance one (am I missing > any?). > For doing distance/angle computation in geodetic space > in GT2 we have this GeodeticCalculator class, that > given a starting point, a metric distance and an azimuth > can compute a resulting point, or vice versa, given two > points can compute the distance and the angle. > > If I were to compute the buffer of a line in geodetic space, > I could conceivably use that class to trace the buffer shell > of simple line segments using a sampling approach, but > alike what is done for the round endcaps in metric space. > And then all I would have to do is to union all those tiny > buffers, which is a set operation, so unaffected by the > geodetic nature of the coordinates. > The same could be done for polygons, so ultimately for > all kinds of geometries supported by JTS. > > If this line of reasoning is correct, this would be a nice > project for a summer of code student. > > Opinions? > Cheers > Andrea > >  > Andrea Aime > OpenGeo  http://opengeo.org > Expert service straight from the developers. > _______________________________________________ > jtsdevel mailing list > [hidden email] > http://lists.refractions.net/mailman/listinfo/jtsdevel > jtsdevel mailing list [hidden email] http://lists.refractions.net/mailman/listinfo/jtsdevel 
In reply to this post by aaime
On Wed, Nov 5, 2008 at 1:41 AM, Andrea Aime <[hidden email]> wrote:
> Am I right in assuming that only the operations using concepts of distance > and angle are affected? I mean, if we take a set theory > operation such as intersect, difference, overlap tests and the like, > they should not be affected at all by the lon/lat nature of the > data. The reasoning is that we could find a projection that > allows to make the computations in metric space, and if > the projection is a continuous transformation, the set related > properties should not be affected, the intersection points of > a geometry would be the same as if we intersected them using > the ellipsoidal geometry, no? No. It's easier to visualize if you use longer lines. The cartesian line between Vancouver and London doesn't touch Greenland. The spherical line goes right through it. For small areas/distances, the cartesian approximation is "close enough", but it isn't an exact relationship. P. _______________________________________________ jtsdevel mailing list [hidden email] http://lists.refractions.net/mailman/listinfo/jtsdevel 
In reply to this post by aaime
mhm.. I also thought that just finding a projection and doing it there
should work. But Paul is right.. you can to this only, lets say for UTM, with a certain accuracy if your geometryoperations stay within a 20km area (I think so). Martin D. on the geotools list may know more on the distortions. Stefan _______________________________________________ jtsdevel mailing list [hidden email] http://lists.refractions.net/mailman/listinfo/jtsdevel 
In reply to this post by aaime
Hei,
an addon: I just found this reference: R.G. Raskin (1994): Spatial Analysis on the Sphere: A Review NCGIA National Center for Geographic Information & Analysis which may help you to evaluate if it possible to do simplify the calculation in the plane and project it pack onto the earth. However, not sure where to download it. If somebody finds a source please tell me. Stefan _______________________________________________ jtsdevel mailing list [hidden email] http://lists.refractions.net/mailman/listinfo/jtsdevel 
In reply to this post by Paul Ramsey
I agree with Paul  it's not just distance and angle, but also the
actual location of intersections which is affected by working in geodetic. I think Andrea's basically correct about the *topology* of operations not be affected. It *might* be possible that if distance, angle and intersection location were pulled out into a strategy class, that it would be possible to replace this with a geodetic strategy and have things still work. Although... there may also be an implicit assumption that intersection points lie on the planar line segment they occur in in a few places. This is obviously violated by geodetic. Paul Ramsey wrote: > On Wed, Nov 5, 2008 at 1:41 AM, Andrea Aime <[hidden email]> wrote: > > >> Am I right in assuming that only the operations using concepts of distance >> and angle are affected? I mean, if we take a set theory >> operation such as intersect, difference, overlap tests and the like, >> they should not be affected at all by the lon/lat nature of the >> data. The reasoning is that we could find a projection that >> allows to make the computations in metric space, and if >> the projection is a continuous transformation, the set related >> properties should not be affected, the intersection points of >> a geometry would be the same as if we intersected them using >> the ellipsoidal geometry, no? >> > > No. It's easier to visualize if you use longer lines. The cartesian > line between Vancouver and London doesn't touch Greenland. The > spherical line goes right through it. For small areas/distances, the > cartesian approximation is "close enough", but it isn't an exact > relationship. > > P. > _______________________________________________ > jtsdevel mailing list > [hidden email] > http://lists.refractions.net/mailman/listinfo/jtsdevel > >  Martin Davis Senior Technical Architect Refractions Research, Inc. (250) 3833022 _______________________________________________ jtsdevel mailing list [hidden email] http://lists.refractions.net/mailman/listinfo/jtsdevel 
In reply to this post by Stefan Steiniger
Here's the actual document:
http://www.ncgia.ucsb.edu/Publications/Tech_Reports/94/947.PDF P. On Thu, Nov 6, 2008 at 12:00 PM, Stefan Steiniger <[hidden email]> wrote: > Hei, > > an addon: I just found this reference: > > R.G. Raskin (1994): Spatial Analysis on the Sphere: A Review > NCGIA National Center for Geographic Information & Analysis > > which may help you to evaluate if it possible to do simplify the calculation > in the plane and project it pack onto the earth. > > However, not sure where to download it. If somebody finds a source please > tell me. > > Stefan > _______________________________________________ > jtsdevel mailing list > [hidden email] > http://lists.refractions.net/mailman/listinfo/jtsdevel > jtsdevel mailing list [hidden email] http://lists.refractions.net/mailman/listinfo/jtsdevel 
Hi,
Here are some thoughts about the subject, which is surely not as simple as it may seem : Take the intersection of two simple lines, each line being defined by two coordinates. If lines are long enough, on the earth surface, their intersection will be a pair of points (If lines follow a geodetic line, which is also the shortest line between two points on Earth's surface if I remember correctly) On the projected plan, the intersection of two straight lines defined by two points have no chance to be a pair of points. Another difficult aspect of the problem, IMHO, is that a pair of points can define two different lines (one on each "side" of the Earth), and similarly, a closed line (ex. equator) define two different surfaces (ex. two hemispheres). May be these difficulties can be solved, thanks to the % operator and some conventions, but it's quite easy to imagine many sort of traps which can rise around the 180° meridian and the poles. But it's an interesting project, which is worth working on my two cents Michaël Paul Ramsey a écrit : > Here's the actual document: > > http://www.ncgia.ucsb.edu/Publications/Tech_Reports/94/947.PDF > > P. > > On Thu, Nov 6, 2008 at 12:00 PM, Stefan Steiniger <[hidden email]> wrote: > >> Hei, >> >> an addon: I just found this reference: >> >> R.G. Raskin (1994): Spatial Analysis on the Sphere: A Review >> NCGIA National Center for Geographic Information & Analysis >> >> which may help you to evaluate if it possible to do simplify the calculation >> in the plane and project it pack onto the earth. >> >> However, not sure where to download it. If somebody finds a source please >> tell me. >> >> Stefan >> _______________________________________________ >> jtsdevel mailing list >> [hidden email] >> http://lists.refractions.net/mailman/listinfo/jtsdevel >> >> > _______________________________________________ > jtsdevel mailing list > [hidden email] > http://lists.refractions.net/mailman/listinfo/jtsdevel > > > _______________________________________________ jtsdevel mailing list [hidden email] http://lists.refractions.net/mailman/listinfo/jtsdevel 
Administrator

In reply to this post by Martin Davis
Martin Davis ha scritto:
> I agree with Paul  it's not just distance and angle, but also the > actual location of intersections which is affected by working in geodetic. > > I think Andrea's basically correct about the *topology* of operations > not be affected. Hum... consider two lines that do barely touch. You have an intersection point. If the transformation changes the intersection points, it would mean that it's possible that after reprojection the two lines do not touch anymore, thereby changing their topological relationship. I have vague memories of continuous transformations never altering the topological relationships between the transformed geometries, but I may have dreamt about it :) Cheers Andrea  Andrea Aime OpenGeo  http://opengeo.org Expert service straight from the developers. _______________________________________________ jtsdevel mailing list [hidden email] http://lists.refractions.net/mailman/listinfo/jtsdevel 
> Hum... consider two lines that do barely touch. You have an intersection > point. If the transformation changes the intersection points, it would > mean that it's possible that after reprojection the two lines do > not touch anymore, thereby changing their topological relationship. > > I have vague memories of continuous transformations never altering > the topological relationships between the transformed geometries, > but I may have dreamt about it :) I think it may be true with shapes which are not discretized. But we always use a discrete representation and we generally suppose that coordinates can be linearly interpolated between points. But interpolation function should not be the same in geodetic space and in projected space (the precise image of a straight segment  or a geodetic line  on Earth's surface is generally not a straight segment in the projected plan). The error is hidden as far as we do not need to interpolate, but can appear as soon as we need to interpolate (as in intersection computation for example). Michaël > Cheers > Andrea > _______________________________________________ jtsdevel mailing list [hidden email] http://lists.refractions.net/mailman/listinfo/jtsdevel 
In reply to this post by michaelm2
Michael wrote: "Another difficult aspect of the problem, IMHO, is that
a pair of points can define two different lines (one on each "side" of the Earth), and similarly, a closed line (ex. equator) define two different surfaces (ex. two hemispheres). " Oooooh. I didn't even think of that. Shame on the surveyor in me. SS On Thu, Nov 6, 2008 at 12:51 PM, Michael Michaud <[hidden email]> wrote: > Hi, > > Here are some thoughts about the subject, which is surely not as simple as > it may seem : > Take the intersection of two simple lines, each line being defined by two > coordinates. > If lines are long enough, on the earth surface, their intersection will be a > pair of points (If lines follow a geodetic line, which is also the shortest > line between two points on Earth's surface if I remember correctly) > On the projected plan, the intersection of two straight lines defined by two > points have no chance to be a pair of points. > > Another difficult aspect of the problem, IMHO, is that a pair of points can > define two different lines (one on each "side" of the Earth), and similarly, > a closed line (ex. equator) define two different surfaces (ex. two > hemispheres). May be these difficulties can be solved, thanks to the % > operator and some conventions, but it's quite easy to imagine many sort of > traps which can rise around the 180° meridian and the poles. > > But it's an interesting project, which is worth working on > > my two cents > > Michaël > > Paul Ramsey a écrit : >> >> Here's the actual document: >> >> http://www.ncgia.ucsb.edu/Publications/Tech_Reports/94/947.PDF >> >> P. >> >> On Thu, Nov 6, 2008 at 12:00 PM, Stefan Steiniger <[hidden email]> >> wrote: >> >>> >>> Hei, >>> >>> an addon: I just found this reference: >>> >>> R.G. Raskin (1994): Spatial Analysis on the Sphere: A Review >>> NCGIA National Center for Geographic Information & Analysis >>> >>> which may help you to evaluate if it possible to do simplify the >>> calculation >>> in the plane and project it pack onto the earth. >>> >>> However, not sure where to download it. If somebody finds a source please >>> tell me. >>> >>> Stefan >>> _______________________________________________ >>> jtsdevel mailing list >>> [hidden email] >>> http://lists.refractions.net/mailman/listinfo/jtsdevel >>> >>> >> >> _______________________________________________ >> jtsdevel mailing list >> [hidden email] >> http://lists.refractions.net/mailman/listinfo/jtsdevel >> >> >> > > _______________________________________________ > jtsdevel mailing list > [hidden email] > http://lists.refractions.net/mailman/listinfo/jtsdevel > jtsdevel mailing list [hidden email] http://lists.refractions.net/mailman/listinfo/jtsdevel 
In reply to this post by michaelm2
No one has mentioned that the new ArcGIS 9.3 will create Geodesic buffers if:
"Features to be buffered are points or multipoints. Input features are in geographic coordinates. Buffer distance is in Euclidian linear units." "Output buffer polygons will take into account that longitudinal distance varies with latitude." Taken from the summer issue of ArcUSER: http://esri.com/news/arcuser/1008/files/top10gp.pdf I don't have 9.3 yet so I can't try this. Has anyone else? I guess the fact that ESRI limits the input to points says that they haven't really solved this problem either. regards, Larry Becker On Thu, Nov 6, 2008 at 4:56 PM, Michael Michaud <[hidden email]> wrote:
 http://amusingprogrammer.blogspot.com/ _______________________________________________ jtsdevel mailing list [hidden email] http://lists.refractions.net/mailman/listinfo/jtsdevel 
In reply to this post by michaelm2
>
I think it may be true with shapes which are not discretized.
@Michaël, Is this a job for Monsieur Bézier's curves? :) Larry On Thu, Nov 6, 2008 at 4:56 PM, Michael Michaud <[hidden email]> wrote:
 http://amusingprogrammer.blogspot.com/ _______________________________________________ jtsdevel mailing list [hidden email] http://lists.refractions.net/mailman/listinfo/jtsdevel 
In reply to this post by Larry Becker
I have 9.3, but I am no arcmap wizard. If you can give me stepbystep instructions I can tell you what happens and/or attach screen shots.
On Fri, Nov 7, 2008 at 9:21 AM, Larry Becker <[hidden email]> wrote: No one has mentioned that the new ArcGIS 9.3 will create Geodesic buffers if: _______________________________________________ jtsdevel mailing list [hidden email] http://lists.refractions.net/mailman/listinfo/jtsdevel 
I don't know the procedure myself. However, while searching for a solution I did find a fascinating parallel discussion about this topic on the ESRI forum titled "Is ArcGIS a real GIS?"
http://forums.esri.com/Thread.asp?c=93&f=982&t=266198&mc=7 Larry On Fri, Nov 7, 2008 at 1:58 PM, Jeff Adams <[hidden email]> wrote: I have 9.3, but I am no arcmap wizard. If you can give me stepbystep instructions I can tell you what happens and/or attach screen shots.  http://amusingprogrammer.blogspot.com/ _______________________________________________ jtsdevel mailing list [hidden email] http://lists.refractions.net/mailman/listinfo/jtsdevel 
In reply to this post by aaime
I thought about this issue a bit more over the weekend.
I still think you're right about continuous transformations not altering the topology of geometries, Andrea. The apparent counterexample that you proposed has a flaw in it. This is that the preservation of topology applies to the *exact* image of the geometry under the transformation. In particular, you have to work with the image of the line segments. Most geodetic arcs have curved images under planar projections  and I think if you inspected the curved images you would see that the original topology was preserved. The basic problem is that we are used to being able to linearly interpolate between vertices of geometries in planar space. This is no longer the case in geodetic space  the interpolation has to follow an arc of a great circle. As long as all the implications of this are properly implemented (e.g. correct coordinate for arc intersection) the structures modelling topology should still work. (I still think there's places in JTS where linearity is assumed  these would have to be enhanced/removed. A fundamental example is the concept of Envelope  it's used everywhere, and would have to be enhanced to support geodetic. Or maybe redefined  an nice way of modelling geodetic coordinates is using direction cosines  essentially 3D points on the sphere. The envelope then becomes a 3D box). The other key point is the one raised by Michael. You need to have a more rigorous definition of geometry topology in a spherical model. There's standard techniques for doing this  arc is assumed to be the smaller of the two possible semiarcs between two points, geometry is oriented with inside to the right of a ring, etc. These are a bit fussy but I think in practice aren't much of a problem. Andrea Aime wrote: > Martin Davis ha scritto: >> I agree with Paul  it's not just distance and angle, but also the >> actual location of intersections which is affected by working in >> geodetic. >> >> I think Andrea's basically correct about the *topology* of operations >> not be affected. > > Hum... consider two lines that do barely touch. You have an intersection > point. If the transformation changes the intersection points, it would > mean that it's possible that after reprojection the two lines do > not touch anymore, thereby changing their topological relationship. > > I have vague memories of continuous transformations never altering > the topological relationships between the transformed geometries, > but I may have dreamt about it :) > > Cheers > Andrea >  Martin Davis Senior Technical Architect Refractions Research, Inc. (250) 3833022 _______________________________________________ jtsdevel mailing list [hidden email] http://lists.refractions.net/mailman/listinfo/jtsdevel 
Administrator

Martin Davis ha scritto:
> I thought about this issue a bit more over the weekend. > > I still think you're right about continuous transformations not altering > the topology of geometries, Andrea. The apparent counterexample that > you proposed has a flaw in it. This is that the preservation of > topology applies to the *exact* image of the geometry under the > transformation. In particular, you have to work with the image of the > line segments. Most geodetic arcs have curved images under planar > projections  and I think if you inspected the curved images you would > see that the original topology was preserved. Correct. JTS already has quite a few places where approximations of reality are used:  precision models  buffer representation (number of segments per quadrant) Would it hurt so much using this kind of assumption on the geodetic case? Allow the user to specify a tolerance under which the approximation of a curve with a set of straight lines is considered to be tolerable? Cheers Andera  Andrea Aime OpenGeo  http://opengeo.org Expert service straight from the developers. _______________________________________________ jtsdevel mailing list [hidden email] http://lists.refractions.net/mailman/listinfo/jtsdevel 
Free forum by Nabble  Edit this page 