[postgis-users] Newbie questions: SRIDs, function return values

[Burgholzer,Robert]

David,

This is very nice,  I think this could also be expanded, with some math,
to do the extent case as well.  You make the assumption that the UTM
zone of geometry a is a better fit than geometry b's zone, but I think
that is a reasonable starting point, though arbitrary.

 

Will diddle around with this one. Thanks!

r.b.

 

Robert W. Burgholzer

Surface Water Modeler

Office of Water Supply and Planning

Virginia Department of Environmental Quality

rwburgholzer at deq.virginia.gov

804-698-4405

Open Source Modeling Tools:

http://sourceforge.net/projects/npsource/

-----Original Message-----
From: postgis-users-bounces at postgis.refractions.net
[mailto:postgis-users-bounces at postgis.refractions.net] On Behalf Of
David William Bitner
Sent: Thursday, May 15, 2008 3:49 PM
To: PostGIS Users Discussion
Subject: Re: [postgis-users] Newbie questions: SRIDs, function return
values

 

This is where a slightly less easy to use implementation that I put in
the PostGIS Wiki as a PL/PGSQL function presents a slightly more robust
approach to the problem.  The use of this function simply returns the
UTM SRID for the appropriate zone for a point that you pass in (note:
this could be expanded to be center of extent or whatever pretty
easily). So the use of this would be:
select blah from a,b where
st_dwithin(transform(a.the_geom,utmzone(a.the_geom)),transform(b.the_geo
m,utmzone(a.the_geom)),100);

While being quite a bit more verbose, at least this approach holds the
zone constant.  Granted it is still rife with the problem of geometries
being a distance similar to the size of a UTM zone or more apart or
sizes similar to UTM zones, but it at least holds to one zone per
comparison.

David

CREATE OR REPLACE FUNCTION utmzone(geometry) RETURNS integer AS 

$BODY$ 

  declare 

   geomgeog geometry; 

   zone int; 

   pref int; 

  begin 

    geomgeog:=transform($1,4326); 

    if (y(geomgeog))>0 then 

      pref:=32600; 

    else 

      pref:=32700; 

    end if; 

    zone:=floor((x(geomgeog)+180)/6)+1; 

    return zone+pref; 

  end; 

$BODY$ LANGUAGE 'plpgsql' immutable;

 

On Thu, May 15, 2008 at 9:57 AM, Paul Ramsey <pramsey at cleverelephant.ca>
wrote:

The danger of this approach is that it falls apart as people start
pushing the limits...

select blah from a, b where
st_dwithin(st_utm(a.geom),st_utm(b.goem),100)

It's a pandora's box... as are all things geodetic

p


On Thu, May 15, 2008 at 7:45 AM, Markus Schaber <schabi at logix-tt.com>
wrote:
> Hi, Paul,
>
> "Paul Ramsey" <pramsey at cleverelephant.ca> wrote:
>
>> There's no universal answer to this, but I have long thought that a
>> simple answer suitable for may people would be a ST_UTM(geom) wrapper
>> on transform that picks the appropriate UTM zone for a given
geometry.
>> It would work perfectly well for any collection of small objects. It
>> would fall apart for larger things like states and countries that are
>> of similar size to a UTM zone.
>
> The function could simply use the centroid of the bounding box, that
> shoul be fast enough.
>
>
> Regards,
> Markus
>
> --
> Markus Schaber | Logical Tracking&Tracing International AG
> Dipl. Inf.     | Software Development GIS
>
> Fight against software patents in Europe! www.ffii.org
> www.nosoftwarepatents.org
> _______________________________________________
> postgis-users mailing list
> postgis-users at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-users
>
_______________________________________________
postgis-users mailing list
postgis-users at postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-users




-- 
************************************
David William Bitner 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-users/attachments/20080515/1a8a7703/attachment.html>