Skip to main content
26 events
when toggle format what by license comment
Mar 18, 2011 at 14:03 comment added whuber @Dan Only a few of the simpler projections have that property, Dan, and only for the sphere as far as I can tell. Leaf through the formulas in Snyder's Map Projections--A Working Manual to see what I mean. On balance there is much in favor of a normal-vector representation of locations, but before plunging in to an implementation it's good to research the possible negative effects.
Mar 17, 2011 at 17:20 comment added Dan S. RE: (1) Yes, they aren't as intuitive. (2) I think lat/lon are a great data exchange representation & said so. RE: (3), I'm skeptical. The vast majority of projections have an awful lot of trig that smells significantly like the exact opposite of what you're saying -- that is, they begin their first step by converting lat/lon to a cartesian space. E.g. a mercator's y component is a nonlinearly scaled version of a vector's "north" (z/y depending on convention) coordinate...
Mar 17, 2011 at 16:40 comment added whuber @Dan (1) OK, quickly now: approximately where on the world are (0.208, -0.725, 0.656) and (-0.389, -0.732, 0.559)? About how many time zones apart are they? What's the bearing between them? What is the climate like in those two places? Having simple, meaningful coordinates to locate places on the earth is useful. (2) Why use three numbers for data exchange when two work just fine? (3) To project the ellipsoid (that is, make a map), sometimes normal vectors will be good, but most of the time they would have to be converted back to (lat, lon) anyway. That's inefficient.
Mar 17, 2011 at 16:28 comment added Dan S. @whuber --- I don't think you'll find much on numerical stability or ease of implementation in Chapter 1. However, that was more or less the whole point of the paper, and those topics aren't very interesting from a pure maths point of view at all. Sorry to disappoint! A question for you: If Step One in doing any interesting calculations is converting to a vector, then why on earth (hah) isn't it a good idea to use vectors as a primary representation in the first place, and relegate lat/lon to a mere data-exchange representation?
Mar 17, 2011 at 14:41 comment added Dan S. @whuber: Check the alt link? "N-vector" is a weird shortening of "normal vector" and you will be disappointed if you expect new mathematics there at all. It is, however, a decent exposition & accompanying advocacy of 3D unit vectors as a geographic primitive of choice for representing a point on the surface of the earth.
Mar 17, 2011 at 14:39 comment added whuber @Dan I found it online at navlab.net/Publications/… . I guess I found it uninteresting for the simple reason that it explains the usual way that one goes about doing any calculations on the sphere or ellipsoid: you convert (lat, lon) to the Cartesian coordinates of a normal vector and then do analytic geometry or calculus in three dimensions. This is the way to work with DEMs, too. This method is usually lesson 1 in any differential geometry textbook; e.g., see Chapter 2.2 of math.uga.edu/~shifrin/ShifrinDiffGeo.pdf
Mar 17, 2011 at 4:12 comment added Dan S. @whuber: This is a placeholder comment to make your mailbox light up --- you may be interested in the citation I edited into the main question!
Feb 12, 2011 at 2:03 comment added Dan S. @whuber Comment limits prevented me from clarifying that I was talking about points/geodesics/etc on the sphere. (Some of it carries over to a wgs84-style spheroid, though, via the auxiliary sphere.)
Feb 12, 2011 at 1:51 comment added Dan S. @whuber: Let me concisely make the case for geocentric 3d unit vectors as a primary representation. Consider two points, a & b, represented so. Then we have: geodesic_dist(a,b) = radius*acos(dot(a,b)). great_circle(a,b) = cross(a,b). (As the normal vect of the corresponding plane). closest_point(a, great_circle(b,c)) = (solve for plane at right angle to the (b,c) plane through a; intersect planes). construct_point(start_point, initial_bearing, dist) is 3D rotation. geodesic_edge(a,b) can be represented by great_circle(a,b) plane and two planes perpendicular to it, one each through a and b.
Feb 12, 2011 at 1:11 comment added whuber @Dan Projection is a matter of how you think about things. After all, the use of (lat, lon) to parameterize the sphere is a projection everywhere except at the poles. Trig is inevitable in converting from those coordinates to 3D. A disadvantage with the 3D solution is that the dimensions all go up by one, essentially guaranteeing everything you do will be more complex. After a stereographic projection you can solve the PiP problem without trig, either.
Feb 11, 2011 at 23:58 comment added Dan S. @Whuber You don't have to project everything to a plane for PiP methods. I was thinking of going the other direction, representing edges as three-dimensional objects that form the appropriate curve at their intersection with the surface of the earth, then doing a 3D ray-cast to infinity to count the even/odd or winding numbers. (Note that great circles on the sphere correspond to planes in 3D, meaning that you can test a geodesic polygon edge with a single ray-plane intersection and 3 plane-side tests. No trig!)
Feb 11, 2011 at 23:43 comment added Dan S. @Kirk: As whuber said, they both work -- and should not require any special cases whatsoever for the dateline or the poles. This is a big part of my motivation for the approach: all operations work everywhere. To be overly dramatic, it would be nice to stop the (useful) lies we tell ourselves every time we perform a GIS analysis, namely that the Earth is flat. ;)
Feb 11, 2011 at 22:21 comment added Kirk Kuykendall @whuber Thanks for the explanation. So since it is possible, what are the benefits? Would this approach help resolve dateline issues? If you move a polygon across a sphere so that it straddles the dateline, would there be any extra processing required (like inserting a vertex at the dateline crossing?)
Feb 11, 2011 at 21:26 comment added whuber @Kirk Suitably interpreted, they both work. Ray casting determines whether two points lie within the same component of the sphere determined by a closed, non-self intersecting polyline. The winding number is a basic tool of Complex Analysis, which naturally treats the sphere (with a single point removed) as the set of complex numbers by means of stereographic projection. All geodesics on the sphere become circles or lines in the complex plane, so you get curvilinear polygons. That's no problem; for instance, use Mobius transformations to straighten circular arcs conformally.
Feb 11, 2011 at 21:06 comment added Kirk Kuykendall @whuber Would either one of these point in polygon methods work on a spheroid? en.wikipedia.org/wiki/Point_in_polygon If not, what method(s) would you propose?
Feb 11, 2011 at 21:03 vote accept Dan S.
Feb 11, 2011 at 19:39 comment added whuber @Dan Quick responses: (i) An edit clarifies "parallel." (Of course there are no parallel geodesics on a spheroid.) (ii) Voronoi regions for conics are not generally bounded by conics; no closure there. (iii) There's no problem with complements of polygons in the plane: handle those with the boundary orientation. (iv) Working on the sphere you want to use rotations, not affine maps; but on the ellipsoid there is no transitive group of isometries. (v) I agree about the limited usefulness of the just-in-time computing approach.
Feb 11, 2011 at 19:18 history edited whuber CC BY-SA 2.5
added 66 characters in body
Feb 11, 2011 at 18:44 comment added Dan S. An example of that general approach is found in a lot of 3D cad/ray-tracing -- instead of trying to compute the shape of the intersection/union/difference of two objects, they store both and have conditionals on the rays. (Eg, a ray-hit test for the intersection of objects A and B = if ray hits object A AND ray hits B.)
Feb 11, 2011 at 18:40 comment added Dan S. Overall: There's a general approach to 'parametric' operations that may make sense, which is to store raw inputs, the operation, and (re)compute to a useful precision each time on-demand. ;) It's usefulness is limited though, and it's not a panacea -- you have to be very careful when e.g. deciding if things intersect...
Feb 11, 2011 at 18:37 comment added Dan S. Translation/rotation: Affine transforms are possible on the plane, although there are other non-affine transform possible that might actually make more sense by making them specifically non-affine. E.g: "move every point due north by 150 meters" is often what is meant by a simple translation in a lot of projections, but of course the distortions of the projection mean that intent is slightly undermined...
Feb 11, 2011 at 18:34 comment added Dan S. Set-theoretic operations: Planar GIS systems typically aren't closed under set complement since it creates an infinitely-sized polygon; sphere/sphereoid/ellipsoid can do better. Note that sometimes intersection points can't (or a difficult) to represent for a lot of curve typess, though, even on the plane.
Feb 11, 2011 at 18:19 comment added Dan S. On the plane, areas of influence for straight-sided features have straight-line and conic-section curves in their borders -- but I doubt that it is closed. I've actually no idea what curves form the boundary of influence for (conic-section) curved features themselves; maybe some deep thought/research will reveal that they're conic sections too, but I'm skeptical. Being closed in general under these operation seems very unlikely.
Feb 11, 2011 at 18:17 comment added Dan S. Nit: Buffering is fixed-distance, not parallel (except for infinite lines).
Feb 11, 2011 at 18:15 comment added Dan S. I really like this way of thinking about it. A few random thoughts in following comments...
Feb 10, 2011 at 18:17 history answered whuber CC BY-SA 2.5