[Proj] proj4 string for perfect sphere

Fischer, Robert P. (GISS-6110)[COLUMBIA UNIVERSITY] robert.p.fischer-1 at nasa.gov
Mon Apr 16 17:24:26 EST 2012

> As for indexing on a sphere, I've used this for a few years now with
> great success:
> http://code.google.com/p/q3c/
> My GIS wanderings were to try to find a similar solution for smaller
> datasets without the overhead of creating a new schema, importing the
> data, etc. to take advantage of the optimized indexing. It might be in
> the end that implementing q3c into sqlite or through a Python
> interface is the best solution.

Have you tried creating temporary schemas/tables in PostgreSQL with q3c?  Is that fast enough?  It sounds like that would be by far the easiest solution for you.

> Thanks very much for the extensive comments. The biggest thing I
> learned about GIS this week (starting from knowing nothing about it
> last week) is that calculations are primarily done on an XY plane
> which are projections of a curved surface. I had naively assumed going
> in that calculations and indices (e.g. spatialite) were optimized for
> the surface of a sphere.

Yes, that's what I surmised too.  The good news is, the technique works quite well for local computations, and you often choose whatever projection you like.  For example, area of a general closed curve on the surface of a sphere can be computed this way, using any old equal area projection centered near your polygon.

> > 1. You can compute distance between two lat/lon points on a sphere
> >   using the Haversine formula or Vincenty's formula specialized to
> >   the sphere.  They are described at:
> >   http://en.wikipedia.org/wiki/Great-circle_distance Code for
> >   Haversine is below.  Fix it up as needed.
> Thanks for the code. I've been using the law of cosines and wasn't
> aware of the problem at small separations (though this seems to trade
> that problem for one at large separations).

Vincenty's formula solves that problem.

> I will also look at the other links you mentioned. Since all my source
> points are in ra/dec (not 3D cartesian), there will be the computation
> hit to convert them back and forth.

Is this signficant for your problem?

More information about the Proj mailing list