[postgis-users] Selecting an SRID

Paragon Corporation lr at pcorp.us
Sat Jun 28 20:36:12 PDT 2008


Well the problem with UTMZones is that they are different for each region of
the globe, so you would have to maintain one for each region which I think
is 20 or more.  For that I would suggest partitioning your data into
inherited tables, which you'd probably want to do anyway if you have a lot
of data.

I'm tackling a similar problem with a project I'm working on, but for now we
are just dealing with US so not so bad.  We did decide to go with Mercator
because we are more concerned with presentation than distance calculations
and didn't want to have to contend with multiple UTM Zones.  The thing to
watch out for though - is ST_Transform introduces floating point errors so
you probably want to decide on a single projection to write to and make sure
all your others transform from that one.

Yes you would probably want to store in both lon/lat and UTMZone (and
possibly a third set or view that presents in GoogleMercator (your WMS might
take care of this for you)) although you'd want to have at the very least a
functional index on google mercator projection.

Actually I haven't used googleMaps API directly in a while.  I've been using
mostly OpenLayers http://www.openlayers.org  because it allows me to easily
overlay different mapping data sources 
(GoogleMaps, VirtualEarth, MapServer, GeoServer, OpenStreetMap etc.) all in
one map and for what I do, that's more important than the additional bells
and whistles the raw Google Map API provides.

If you wanted to use OpenLayers - you would want to have your WMS/WFS
service be able to dish out in GoogleMercator so that your client app
doesn't need to do any reprojecting (note you can reproject your own layers
on the client  with OpenLayers using the proj4js.js , but I would suggest
against that since it puts more load on the client).

I think the raw GoogleMaps api even though it dishes out in GoogleMercator
assumes you are feeding data in lat long.

I hope I haven't confused you more,


-----Original Message-----
From: postgis-users-bounces at postgis.refractions.net
[mailto:postgis-users-bounces at postgis.refractions.net] On Behalf Of Edward
Q. Bridges
Sent: Saturday, June 28, 2008 11:17 AM
To: PostGIS Users Discussion
Subject: Re: [postgis-users] Selecting an SRID

Hi Regina,

Thanks for the follow up.

To be more specific, the application would indeed cover the whole globe
(including bodies of water).  It would be based on regions drawn by users
(and/or points selected by users) via google maps.  These coordinates would
be stored and then displayed again on google maps. 
There's a possibility we may seek to include input from GPS devices
(depending on the added complexity).

The vast majority of use cases will be proximity analyses on points v. 
points, regions v. regions, and regions v. points.  By proximity, I mean
what locations are either adjacent or enclosed by another.  Since these
would be average users, proximity would have to be measured in meters (or
miles) not in degrees of latitude or longitude.

Based on my interpretation of the points you make, it sounds like perhaps
the approach would be to store in both lon/lat and UTMzone: the former for
submitting back to gmaps and the other for doing the above proximity
analysis?  Would you agree?

Would it make sense to store coordinates in different regions of the world
using different SRS's?  Or, would simply using the Goole Projection (i.e.
http://spatialreference.org/ref/user/6/) for any point/polygon on the globe
be sufficient? Also, how much of these issues are non-issues given that the
display in in gmaps, and the input is coming from gmaps?


Paragon Corporation wrote:
> Ed,
> Depends of your region of interest and which analysis (mostly database 
> or just user drawing on a map)  and how much of it you will be doing.  
> Also what kind of tool you will be using to render your maps.
> If you are covering the whole globe - you might be best to leave your 
> data in long lat and transform to an appropriate UTM zone or other 
> regional zone as needed or have your mapping app do the transformation 
> for you to the base map layer projection.  (a lot of mapping software 
> can do this)
> For display purposes long lat (4326, 4269) looks squashed so I usually 
> go with US National Atlas (2163 which provides a nice balance of look 
> and measurement but really only works for continental US) or 
> Mercator/Google Mercator (which sucks for measurement but looks decent 
> on a map and covers the globe) .  If you are just dealing with 
> overlaying points on a map (and not  polygons, lines etc then the 
> issue of the skewedness of polygons etc is a non-issue so you can keep 
> in 4326) but you'll probably want to maintain a functional index on the
based on transform of the UTMzone.
> By far a state plane zone or UTM zone is preferable for any kind of 
> intense measurement analysis and for presentation on a map.
> You could transform on the fly but if you are doing enough of that, it 
> will affect performance a little and is an added hassle since you will 
> also want to keep a functional index on that transformation.
> Anyrate 2 resources I always recommend if you haven't looked at them 
> already
> 1) http://spatialreference.org  - lists both well-known and user 
> contributed projections and for each provides the PostGIS sql insert 
> state to insert into the spatial_ref_sys table if the spatial ref 
> doesn't already exist in PostGIS.
> 2) 
> http://postgis.refractions.net/support/wiki/index.php?plpgsqlfunctions  
> - the UTMZone function which given a point geometry will return the SRID
of the UTM zone the point falls in.
> Hope that helps,
> Regina
> -----Original Message-----
> From: postgis-users-bounces at postgis.refractions.net
> [mailto:postgis-users-bounces at postgis.refractions.net] On Behalf Of 
> Edward Q. Bridges
> Sent: Friday, June 27, 2008 8:26 PM
> To: postgis-users at postgis.refractions.net
> Subject: [postgis-users] Selecting an SRID
> Hi,
> I'm relatively new to PostGIS and to GIS concepts in general, and I'm 
> working on a project which has  a goal of being able to identify 
> points within regions (basically).
> In enabling a geometry column I'm stuck on how to decide on which SRID 
> to use.  The data will come into the system as lon/lat; and it will be 
> used as both lon/lat (i.e. to show system users points within regions) 
> and in meters (i.e. to tell users how far away one point is from 
> another).  Other sorts of analyses will be what regions are near a 
> region, what points are near a point, and what regions and points are
enclosed by another region.
> Will my choice of SRID affect how efficiently these analyses can be done?
> Is it possible to use one SRID for all of these different usage scenarios?
> Thanking in advance for any help, or useful ideas.
> Best regards,
> Ed
postgis-users mailing list
postgis-users at postgis.refractions.net

More information about the postgis-users mailing list