# [Proj] conversion latlong to UTM (& vice versa)

Oscar van Vlijmen ovv at hetnet.nl
Fri Nov 3 14:29:09 EST 2006

```> From: Roger Oberholtzer
> Date: Fri, 03 Nov 2006 14:40:26 +0100
> Subject: Re: [Proj] conversion latlong to UTM (& vice versa)

> Not exactly an answer here, but we provide locations from moving
> vehicles as well. In the countries that are UTM and span more than one
> zone, it is quite often the case that one zone is chosen as the one used
> in all calcs in the country. In Spain, for example, it is the zone where
> Madrid is. In Finland it is Helsinki. In Saudi Arabia it is Riyadh. So,
> maybe that is an approach. This is mostly useful for GIS-type apps more
> than those wanting to find absolute locations. Of course, all your data
> must agree with this.

Actually, this doesn't sound too idiotic.
I did a calculation for Saudi Arabia.
Suppose everything is UTM based, with the zone Ar-Riyad is in. Riyad is at
24:38N, 46:43E, hence in UTM zone 38, central meridian 45 deg.
I'll travel from a location near Egypt at 28N, 36E to somewhere near the
Oman border at 22N, 55E (try this with a car, but that's another story!).
Many 'transportation people' use UTM coordinates to get an idea of the
distance by taking the vectorial distance between the x,y coordinates of
source and target (i.e. sqrt(dx^2+dy^2)).

The source location is in UTM zone 37 and the target is in zone 40. Let's
calculate everything as if it were in zone 38 on a wgs84 ellipsoid.
Using an ultra-wide transverse mercator projection function (like libproj's
ftmerc; ask mr. Evenden by email), we get for the source an x,y =
-386952.39, 3130081.43 m
and for the target:
1536016.65, 2466933.90
Vectorial distance =
2034102.89 m.
The 'true' geodesic distance, calculated with 'Vincenty' (not in PROJ)
gives:
2027075.25 m
That's about 7 kilometers off, but only 1/3 percent.
Since one usually doesn't drive or even fly along a geodesic line, this
distance estimation is quite reasonable.
It isn't even necessary to use an ultra-wide tmerc, the regular tmerc in
(lib)proj produces in this case x,y values that differ only a couple of
millimeters from the exact TM values.

```