[R-sig-Geo] How to define a local equidistant CRS

[Michael Sumner]

Hi again, at that kind of range - 15km - you could choose almost any
projection family and a custom centre. I don't think distance accuracy fors
those distances  would be an issue even over a continent like USA or
Australia. AEQD or LAEA or LCC , doesn't matter. What you might consider is
a single custom projection (or an actual authority one, such as Abers for
USA, or LCC for Australia (they exist)) that is suitable for all of your
sites to avoid complexity.

(I avoid UTM because it's rarely suitable, sometimes its actual properties
are of use but mostly it's a legacy from a previous age, it's only in wide
use because authorities did deploy it for local use in many many
jurisdictions, and it's easy to calculate.)

For custom use I find it simpler to pick a long-lat centre for a LAEA, it
requires less effort and is more robust *globally* that any UTM choice.

In terms of your locality, the actual region over which your sites might
be, maybe you do need a non-WGS84 datum, and perhaps a non-temporal or an
actual specific-temporal datum family  - but I don't get that impression
from your description.

Cheers, Mike



On Mon, Jun 14, 2021 at 11:54 PM Micha Silver <tsvibar using gmail.com> wrote:

> Hello Mike:
>
>
> Thanks for addressing this issue.
>
>
> 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:
>
>
> 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).
>
>
> 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.
>
>
> 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.
>
>
> 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:
>
>   projstring <- paste("+proj=aeqd +R_A +lat_0=", YMiddle,
>                       " +lon_0=", XMiddle,
>                       " +x_0=0 +y_0=0 +ellps=WGS84",sep="")
>
> might not be future-proof. The second option could be a local UTM based
> CRS, getting the zone from the XMiddle, Ymiddle values.
>
>
> Any other suggestions are welcome!
>
>
> Best,
>
> Micha
>
>
>
>
>
>
>
> On 6/11/21 5:16 AM, Michael Sumner wrote:
>
> I'd do
>
> local_aeqd <- function(lon, lat) {
>   sprintf("+proj=aeqd +lat_0=%f +lon_0=%f +datum=WGS84", lat, lon)
> }
>
> local_aeqd(147, -42)
>
> 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.
>
> 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.
>
> Cheers, Mike.
>
> On Sun, Jan 24, 2021 at 2:56 AM Micha Silver <tsvibar using gmail.com> wrote:
>
>>
>> On 1/23/21 1:05 PM, Roger Bivand wrote:
>>
>> On Sat, 23 Jan 2021, Micha Silver wrote:
>>
>>
>> Roger:
>>
>>
>>
>>
>> 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: https://proj.org/news.html (Update to EPSG 10.003 and make
>> code base robust to dealing with WKT CRS with DatumEnsemble (#2370)). The
>> link to https://github.com/OSGeo/PROJ/pull/2370 gives details.
>>
>> 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.
>>
>> 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.
>>
>>
>> This is more detail than you expected, I think, but at least it is a way
>> of documenting things.
>>
>> Well, like you said, you can't get the sweet potatoes back after cooking
>> orange vegetable soup.
>>
>> :-)
>>
>>
>> Roger
>>
>>
>>
>>       If this isn't a reprex, please extend briefly.
>>
>>       Roger
>>
>>
>> Thanks again,
>>
>> Regards, Micha
>>
>>
>>
>>
>> --
>> Micha Silver
>> Ben Gurion Univ.
>> Sde Boker, Remote Sensing Lab
>> cell: +972-523-665918
>>
>> _______________________________________________
>> R-sig-Geo mailing list
>> R-sig-Geo using r-project.org
>> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>>
>
>
> --
> Michael Sumner
> Software and Database Engineer
> Australian Antarctic Division
> Hobart, Australia
> e-mail: mdsumner using gmail.com
>
> --
> Micha Silver
> Ben Gurion Univ.
> Sde Boker, Remote Sensing Lab
> cell: +972-523-665918
>
>

-- 
Michael Sumner
Software and Database Engineer
Australian Antarctic Division
Hobart, Australia
e-mail: mdsumner using gmail.com

	[[alternative HTML version deleted]]