<html style="direction: ltr;">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<style id="bidiui-paragraph-margins" type="text/css">body p { margin-bottom: 0cm; margin-top: 0pt; } </style>
</head>
<body bidimailui-charset-is-forced="true" style="direction: ltr;">
<p><font size="+1">Hello Mike:</font></p>
<p><font size="+1"><br>
</font></p>
<p><font size="+1">Thanks for addressing this issue. </font></p>
<p><font size="+1"><br>
</font></p>
<p><font size="+1">A few more details might make the overall goal
clearer. The RAINLINK package converts cellular signal
attenuation between microwave towers to rain rate (path averaged
depending on the distance between the towers). Typically the
tower locations will be in longitude/latitude, but RAINLINK
needs Cartesian coordinates in three functions:</font></p>
<p><font size="+1"><br>
</font></p>
<p><font size="+1">1- An important first step in RAINLINK determines
if the microwave antenna itself is wet (causing attenuation even
before hitting any rain). The approach adopted in the package is
to find other antennas in the time and space vicinity that also
are experiencing attenuation. Here we need to get those antennas
that are within, say, 15 km. This issue can be easily addressed
with the distVincenty* functions from geosphere, or (as Roger
suggested) using the new s2 package for calculating distances on
a sphere. No need really for any reprojection (submeter accuracy
is not an issue). <br>
</font></p>
<p><font size="+1"><br>
</font></p>
<p><font size="+1">2- RAINLINK also produces some informative plots
of the topology of the microwave link network. Among them bar
plots of distances between towers vs frequency, etc. Here,
cartesian distance is needed, but again, we could probably get
away with either of the distance on sphere functions above.</font></p>
<p><font size="+1"><br>
</font></p>
<p><font size="+1">3- The more tricky problem (I think) is the
RAINLINK interpolation function. Here, both IDW and kriging are
used to produce precipitation distribution maps. A Cartesian CRS
is needed/preferred, I believe, both to construct the variogram
model, and to create the target interpolation grid. </font></p>
<p><font size="+1"><br>
</font></p>
<p><font size="+1">So, my intuition is to choose right at the start
a "proper" projected CRS depending on the location on the earth,
and use that throughout. In the current version of RAINLINK a
hand-crafted aeqd CRS was defined from the middle of the
distribution of antennas. But now, with proj >=6.x
definitions like:</font></p>
<p><font size="+1"> projstring <- paste("+proj=aeqd +R_A
+lat_0=", YMiddle,<br>
" +lon_0=", XMiddle,<br>
" +x_0=0 +y_0=0 +ellps=WGS84",sep="")</font></p>
<p><font size="+1">might not be future-proof. The second option
could be a local UTM based CRS, getting the zone from the
XMiddle, Ymiddle values.</font></p>
<p><br>
</p>
<p><font size="+1">Any other suggestions are welcome!</font></p>
<p><font size="+1"><br>
</font></p>
<p><font size="+1">Best,</font></p>
<p><font size="+1">Micha<br>
</font></p>
<p><font size="+1"><br>
</font></p>
<p><font size="+1"><br>
</font></p>
<p><font size="+1"><br>
</font></p>
<p><font size="+1"><br>
</font></p>
<p><font size="+1"><br>
</font></p>
<p><font size="+1"></font><br>
</p>
<div class="moz-cite-prefix">On 6/11/21 5:16 AM, Michael Sumner
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAAcGz99h1NHJMuqz5d_FqdzHzVYc=y6kks=-GBPdCJFcO6sZdg@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">I'd do
<div><br>
</div>
<div>local_aeqd <- function(lon, lat) {<br>
sprintf("+proj=aeqd +lat_0=%f +lon_0=%f +datum=WGS84", lat,
lon)<br>
}<br>
<br>
local_aeqd(147, -42)<br>
</div>
<div><br>
</div>
<div>just note that the very high accuracy of distances only
applies from points to that central point - but for a fair
region around probably suits your purposes well also and
definitely a 15km region, the equidistant property is unlikely
to matter at that scale, for general use I go for laea or if I
have a definite extent and for larger regions >=1000km lcc
with +lat_1 and +lat_2 set to the north/south extent. </div>
<div><br>
</div>
<div>But, do you really need a projection or just distance
between points of long-lat? (Can't tell from your
description). I use geosphere or geodist routinely, the same
code (Karney) exists in the sf stack as well. </div>
<div><br>
</div>
<div>Cheers, Mike. </div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Sun, Jan 24, 2021 at 2:56
AM Micha Silver <<a href="mailto:tsvibar@gmail.com"
moz-do-not-send="true">tsvibar@gmail.com</a>> wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div style="direction:ltr">
<p><br>
</p>
<div>On 1/23/21 1:05 PM, Roger Bivand wrote:<br>
</div>
<blockquote type="cite">On Sat, 23 Jan 2021, Micha Silver
wrote: <br>
<br>
<blockquote type="cite"> <br>
Roger: <br>
<br>
<br>
<br>
</blockquote>
<br>
Yes, but the exceptions for WGS84, NAD83 and NAD27 are
just that, exceptions from the general rule of +datum=
being dropped. The next road bump will occcur soon(ish)
because WGS84 is an ensemble of datum specifications, not
a unique specification, and PROJ 7.2.0 is starting to
address this: <a href="https://proj.org/news.html"
target="_blank" moz-do-not-send="true">https://proj.org/news.html</a>
(Update to EPSG 10.003 and make code base robust to
dealing with WKT CRS with DatumEnsemble (#2370)). The link
to <a href="https://github.com/OSGeo/PROJ/pull/2370"
target="_blank" moz-do-not-send="true">https://github.com/OSGeo/PROJ/pull/2370</a>
gives details. <br>
<br>
Unless you need sub-metre accuracy, this may not matter,
but if different parts of the world use different WGS84
definitions (at different times), the s2 package may be
more stable though a little less accurate. <br>
<br>
</blockquote>
<p>Sub meter accuracy is definitely not an issue in our use
case. The microwave antennas are from 1-12 km apart. We
need the list of antennas that are within a radius of
about 15 km. Missing one antenna that is, on a sphere, a
few 10's of meters too far is of no consequence here.<br>
</p>
<p><br>
</p>
<blockquote type="cite">This is more detail than you
expected, I think, but at least it is a way of documenting
things. <br>
<br>
</blockquote>
<p>Well, like you said, you can't get the sweet potatoes
back after cooking orange vegetable soup.</p>
<p>:-)</p>
<p><br>
</p>
<blockquote type="cite">Roger <br>
<br>
<blockquote type="cite"> <br>
<br>
If this isn't a reprex, please extend briefly. <br>
<br>
Roger <br>
<br>
<br>
Thanks again, <br>
<br>
Regards, Micha <br>
<br>
<br>
<br>
</blockquote>
<br>
</blockquote>
<pre cols="72">--
Micha Silver
Ben Gurion Univ.
Sde Boker, Remote Sensing Lab
cell: +972-523-665918</pre>
</div>
_______________________________________________<br>
R-sig-Geo mailing list<br>
<a href="mailto:R-sig-Geo@r-project.org" target="_blank"
moz-do-not-send="true">R-sig-Geo@r-project.org</a><br>
<a href="https://stat.ethz.ch/mailman/listinfo/r-sig-geo"
rel="noreferrer" target="_blank" moz-do-not-send="true">https://stat.ethz.ch/mailman/listinfo/r-sig-geo</a><br>
</blockquote>
</div>
<br clear="all">
<div><br>
</div>
-- <br>
<div dir="ltr" class="gmail_signature">Michael Sumner<br>
Software and Database Engineer<br>
Australian Antarctic Division<br>
Hobart, Australia<br>
e-mail: <a href="mailto:mdsumner@gmail.com" target="_blank"
moz-do-not-send="true">mdsumner@gmail.com</a></div>
</blockquote>
<pre class="moz-signature" cols="72">--
Micha Silver
Ben Gurion Univ.
Sde Boker, Remote Sensing Lab
cell: +972-523-665918</pre>
</body>
</html>