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 [EMAIL PROTECTED] 804-698-4405 Open Source Modeling Tools: http://sourceforge.net/projects/npsource/ -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> wrote: > Hi, Paul, > > "Paul Ramsey" <[EMAIL PROTECTED]> 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 > [email protected] > http://postgis.refractions.net/mailman/listinfo/postgis-users > _______________________________________________ postgis-users mailing list [email protected] http://postgis.refractions.net/mailman/listinfo/postgis-users -- ************************************ David William Bitner
_______________________________________________ postgis-users mailing list [email protected] http://postgis.refractions.net/mailman/listinfo/postgis-users
