The function UTMZONE() at <a href="http://postgis.refractions.net/support/wiki/index.php?plpgsqlfunctions">http://postgis.refractions.net/support/wiki/index.php?plpgsqlfunctions</a> will find the UTM zone for you for a given geometry.<br>
<br><div class="gmail_quote">On Thu, Feb 28, 2008 at 11:29 PM,  <<a href="mailto:mchapman@texelinc.com">mchapman@texelinc.com</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Also, I think utm is 60 zones each 6 degrees of longitude at the equator starting at the dateline and progressing easterly around the globe. Further, each zone is divided into a northern and southern hemishere.  Then each zone is considered a coordinate system in itself where the width of the zone is something like 500000 and the height of the coordinate system is 10000000, as compared to an angular projection where the bounds are -180, -90, 180, 90.<br>

<br>
You could create a table of utm zone geometries and do an intersect each time you wanted to figure out what zone you needed.<br>
<br>
Just some thoughts.  Hope they help.<br>
Please correct me if I have a flaw in my suggestions.<br>
<br>
Martin<br>
Sent via BlackBerry by AT&T<br>
<div><div></div><div class="Wj3C7c"><br>
-----Original Message-----<br>
From: Dylan Beaudette <<a href="mailto:dylan.beaudette@gmail.com">dylan.beaudette@gmail.com</a>><br>
<br>
Date: Thu, 21 Feb 2008 09:56:15<br>
<a href="mailto:To:postgis-users@postgis.refractions.net">To:postgis-users@postgis.refractions.net</a><br>
Subject: Re: [postgis-users] Projection for Calculating Area<br>
<br>
<br>
On Thursday 21 February 2008 09:33:17 am Travis Kirstine wrote:<br>
> All,<br>
> We have been developing a web mapping application using google maps as<br>
> the front end interface with a postgis backend.  Using this<br>
> application the user can draw a bounding box in google maps and the<br>
> coordinates are then passed to postgis.  With postgis we then perform<br>
> a query on the polygons stored in the postgis database to return the<br>
> area using  ST_Intersection, ST_Transform (usually to UTM) and finally<br>
> ST_Area.  The application works great but the problem is  that since<br>
> we are trying to work on a global scale it is difficult to determine<br>
> what projection (EPSG) to transform the data to calculate an accurate<br>
> area since our data is in EPSG:4326 and returns decimal degrees.  We<br>
> can easily transform the query results to a UTM or a Albers projection<br>
> however the results can be inaccurate since the user may select<br>
> multiple zones or hemispheres when view the map at a global scale.  Is<br>
> there a accurate global projection for calculating area?<br>
<br>
No. Except maybe a global sinusoidal projection... but-<br>
<br>
This touches on one of the fundamental issues with geographic data: when you<br>
want to compute cartesian statistics (length, area, etc. in a planar sense)<br>
you are going to have to make a compromise in<br>
<br>
shape<br>
direction<br>
area<br>
<br>
AND the larger the region you want to work with the more drastic the<br>
distortion on 2/3 of the above parameters you will encounter.<br>
<br>
This is why 'local' projections like UTM are highly valued-- by working with a<br>
very small chunk of the earth you can minimize distortion considerably.<br>
<br>
As for a solution: check the mailing list archives for a custom function that<br>
can automatically determine UTM zone based on a lon/lat coordinate pair.<br>
<br>
If you have really big shapes that are spanning multiple UTM zones, then<br>
setting up some kind of pre-processing logic which determines 1 of several<br>
possible albers equal area conic projections might work. For example, if the<br>
coordinates are near the continental US, use one set of standard parallels /<br>
central lon/lat to setup the projection. Adjust these parameters accordingly<br>
for different (continents?) regions of the world. You should be able to<br>
either find some existing EPSG codes which are close enough, or just make up<br>
your own, and define your projections in PROJ format. Then add them to the<br>
spatial_ref_sys table.<br>
<br>
For some thoughts on equal area projections / projection parameters see:<br>
<br>
Snyder, J. P. Map Projections- A working Manual U.S. Geologic Survey, U.S.<br>
Geologic Survey, 1987<br>
<br>
Cheers,<br>
<br>
Dylan<br>
<br>
--<br>
Dylan Beaudette<br>
Soil Resource Laboratory<br>
<a href="http://casoilresource.lawr.ucdavis.edu/" target="_blank">http://casoilresource.lawr.ucdavis.edu/</a><br>
University of California at Davis<br>
530.754.7341<br>
_______________________________________________<br>
postgis-users mailing list<br>
<a href="mailto:postgis-users@postgis.refractions.net">postgis-users@postgis.refractions.net</a><br>
<a href="http://postgis.refractions.net/mailman/listinfo/postgis-users" target="_blank">http://postgis.refractions.net/mailman/listinfo/postgis-users</a><br>
</div></div><br>_______________________________________________<br>
postgis-users mailing list<br>
<a href="mailto:postgis-users@postgis.refractions.net">postgis-users@postgis.refractions.net</a><br>
<a href="http://postgis.refractions.net/mailman/listinfo/postgis-users" target="_blank">http://postgis.refractions.net/mailman/listinfo/postgis-users</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br>************************************<br>David William Bitner