[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