Take the 2-minute tour ×
Geographic Information Systems Stack Exchange is a question and answer site for cartographers, geographers and GIS professionals. It's 100% free, no registration required.

While reading the GeoDjango documentation, they advise using geometric rather than the geographic data type when storing values that are on a continental scale.

The Canadian province of Ontario, for example, is fairly large. Although it's not on a continental scale, will I face a significant loss of accuracy when performing polygon calculations and mapping using geometric (as opposed to geographic) storage? At what threshold should one switch over from using geometric data types to using geographic data types?

share|improve this question
1  
Related: stackoverflow.com/questions/6708362/… N.B. Although the referenced post is for SQL Server, the differences between geometry and geography are transferable to any DBMS that adopts the standards correctly. –  Geoist Jun 27 '13 at 2:38
1  
One issue about that post- the claim that reprojection is expensive is not consistent with my experience. I found that in retrieving geometries from SQL '08 (on another machine, same network), reprojecting via proj, and rendering via WPF, time spent in reprojection was only about 1-2% of the total query/render time. –  Russell at ISC Jun 27 '13 at 13:28
    
Geoist, thanks for the link to the post. I'm surprised I missed that on Stackoverflow. I've revised the question a little. Granted that there is some loss in performance, what I'm really after is what a suitable threshold would be to warrant switching over from geometric to geographic data types. –  Ashwin Balamohan Jun 27 '13 at 19:06
add comment

1 Answer

up vote 4 down vote accepted

The geographic data type is quite new and it doesn't have so many functions as the geometric data type. Never the less it has some important functions that take into account the great circle calculations when dealing with length units.

Currently you can take advantage of geog data type even if you are using the geometry, by casting from one type to another eg:

select st_length(<geom_column)::geography) from my_spatial_table;

currently casting from and to geography works for the 4326 SRID.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.