<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#333399">
Are these the steps (below, in Paul's message) what I will have to use
to get the lat/lon coordinates of a 125 km circle around a point? It
seems to me that Buffer() should do this on it's own. I'm still
struggling to understand what SRIDs are all about, and what I must
insert into my now-empty spatial_ref_sys table, much less the other
steps. Buffer() is a GREAT tool, but it disappoints me that only
rocket scientists know how to set the environment up enough to use it
effectively. <br>
<br>
Our weather radars are essentially randomly spaced from each other.
The effective range of the data gleaned from the radars is 125 km.
Fortunately, the radars are usually closer than 250 km to each other in
the eastern half of the United States such that there are few, if any,
"holes" with no radar coverage. What I'm looking to do is just a
simple concept. Two adjacent radars which overlap will have a
bisecting line between them such that the line represents equal
distances from one radar or the other. Doing this with several
surrounding radars, we can come up with an N-sided polygon around the
"base" radar where N is the number of surrounding radars. This polygon
computed by postGIS represents the region closer to the base radar than
any of the other radars. The vertices of this polygon are the
intersections of the bisecting lines between each of the surrounding
radars. <br>
<br>
My problem, though, is that I don't yet understand enough about SRIDs,
and reprojecting my lat/lon coordinates into a planar projection
(whatever that means). Can someone point me to some documentation
and/or examples that explains to me what SRIDs are all about, and how
to reproject data, so I can get past the very first step of getting the
125km radar rings?<br>
<br>
Thanks!<br>
Mark<br>
<br>
Paul Ramsey wrote:
<blockquote cite="mid427BA138.1020301@refractions.net" type="cite">So,
the whole Buffer('Lat Lon Geometry', planar distance) thing brings this
up again: to what extent should PostGIS try to hide SRS issues from
users? Hiding them generally means hacking around them, and the hacks
could in some occasions give rise to things the users don't want. I am
assuming here that we are not going to invest the time to do arbitrary
geometric calculations on the spheroid.
<br>
<br>
For example, Buffer('Lat Long Geometry', planar distance) would have
to:
<br>
<br>
- Look up the SRID of the goemetry in spatial_ref_sys
<br>
- Instantiate the proj4 definition, see if it includes a cartographic
transformation
<br>
- If not, it's lat/lon so,
<br>
- Create a temporary TransverseMercator (?) projection centered on the
geometry
<br>
- Reproject the geometry into that projection
<br>
- Run the buffer
<br>
- Projection the geometry back out into lat lon
<br>
- Return the result
<br>
<br>
There are two nastinesses here:
<br>
<br>
- the projection needs to be checked all the time now, even when we are
already in a projected system, just to make sure we are not in the
lat/lon case
<br>
- hidden "magic" is happening, and the magic is somewhat complex,
including some assumptions (like doing the buffer in TM)
<br>
<br>
Thoughts?
<br>
<br>
P
<br>
_______________________________________________
<br>
postgis-users mailing list
<br>
<a class="moz-txt-link-abbreviated" href="mailto:postgis-users@postgis.refractions.net">postgis-users@postgis.refractions.net</a>
<br>
<a class="moz-txt-link-freetext" href="http://postgis.refractions.net/mailman/listinfo/postgis-users">http://postgis.refractions.net/mailman/listinfo/postgis-users</a>
<br>
<br>
</blockquote>
</body>
</html>