[Proj] cs2cs - specifying UTM zone on command line

[Kristian Evers]

On 29 Oct 2018, at 19:11, Robb Main <rmain.mws at gmail.com<mailto:rmain.mws at gmail.com>> wrote:

One final question, and I'll stop beating this to death:
From my naive viewpoint, I want to supply a lat & long coordinate, and receive a UTM coordinate (i.e, zone, easting, northing).
Obviously, determining a zone is the first step required in the process, but it would seem to be something that cs2cs could (/should?) handle.
The zone IS determined from the longitude (even if it is supplied on the command line).

Is there some philosophical reason PROJ tools don't currently do this?


Theoretically PROJ could do that, but I don’t think that it should. The zone is set up before any coordinates are passed to the projection, so given the current architecture PROJ wouldn’t know what to base the zone choice on. This could of course be changed so that for every coordinate passed to the projection an “optimal zone” could be determined from the input and the projection parameters adjusted accordingly. Let’s have a look at what that would mean in a real world implementation. Say you have two coordinates with the same latitude and the longitude spaced exactly six degrees. For instance somewhere in Germany, 51N 6E and 51N 12E. Using a dynamically assigned UTM zone the first coordinate would end up in zone 31 and the second in zone 32. Let’s look at the UTM coordinates for both points:

$ echo 6 51 | proj +proj=utm +zone=31
710488.86       5654109.18

$ echo 12 51 | proj +proj=utm +zone=32
710488.86       5654109.18

They are exactly the same. Now image converting a dataset of the German borders with a UTM projection that dynamically assigns the zone. That is going to be a very big mess when plotted in a map. Additionally, you have eliminated the possibility to convert the data back to geodetic coordinates - which one of the 60 possible ways do you choose?

Would there be any point in me coding up a patch to support this & submitting a pull request?

No.

(I guess that's really two questions...).
Thanks again,
Robb.


On Mon, Oct 29, 2018 at 1:55 PM Kristian Evers <kreve at sdfe.dk<mailto:kreve at sdfe.dk>> wrote:
Robb,

On 29 Oct 2018, at 18:34, Robb Main <rmain.mws at gmail.com<mailto:rmain.mws at gmail.com>> wrote:

Thanks for the link, Kristian.

It seemed to me that the source code (specifically proj_etmerc.c:338 - 354) looked like it would calculate the zone if one wasn't supplied (although it also doesn't handle the 'exception' cases mentioned in your link), though I was surprised when I could not find a way to request conversion without specifying a zone.


In that part of the code it tries to determine the zone from the central meridian set with +lon_0. If neither +zone or +lon_0 is set PROJ defaults to zone 30 (based on the default value of +lon_0 which is 0 when not specified).

As I understand your statement though, there is no way to do this with the current implementation of PROJ tools.

Correct.

On the subject of 'correctness', doesn't using a 'clever shell script' like you suggest amount to doing what I was requesting, just doing it outside the PROJ framework?

Yes. I am not saying that it is a smart thing to do, but if you really want to, there’s a way to do it.

/Kristian

Regards,
Robb.

On Mon, Oct 29, 2018 at 1:07 PM Kristian Evers <kreve at sdfe.dk<mailto:kreve at sdfe.dk>> wrote:
Robb,

/Kristian

On 29 Oct 2018, at 17:30, Robb Main <rmain.mws at gmail.com<mailto:rmain.mws at gmail.com>> wrote:

When converting many lat,long coordinates to UTM, is there some way to setup cs2cs to calculate the UTM zone based on the longitude of the source cordinate system, rather than having to specify the zone on the command line?

No. You can probably do something clever in a shell script if you want, but it is not possible with any PROJ tool. See [0] for an overview of how to determine the nearest UTM zone of a coordinate.


What I'm looking for is something like: instead of this:
  cs2cs +proj=latlong +data=NAD83 +to +proj=utm +zone=10 +datum=NAD27 ./input.data
you could instead specify:
  cs2cs +proj=latlong +data=NAD83 +to +proj=utm +zone=auto +datum=NAD27 ./input.data
where 'zone=auto' might tell the algorithm to figure the zone out based on longitude of the input coordinate. This would ensure the output data would be correct, even if the input data file contains coordinates that span multiple UTM zones.

What you call correct, I regard as potentially incompatible coordinates. What you are proposing here is fundamentally breaking the promise that you are given by the cs2cs application: cs2cs transform coordinates from one coordinate reference system to another. With your proposed auto-zoned UTM the output crs would not be properly defined and your output coordinates would be incompatible in the case that they span several UTM zones. You are much better of just sticking to one zone - cs2cs will deliver numerically stable coordinates several thousands of kilometers outside the chosen zone.

/Kristian

[0] https://stackoverflow.com/questions/9186496/determining-utm-zone-to-convert-from-longitude-latitude

_______________________________________________
Proj mailing list
Proj at lists.maptools.org<mailto:Proj at lists.maptools.org>
http://lists.maptools.org/mailman/listinfo/proj

_______________________________________________
Proj mailing list
Proj at lists.maptools.org<mailto:Proj at lists.maptools.org>
http://lists.maptools.org/mailman/listinfo/proj
_______________________________________________
Proj mailing list
Proj at lists.maptools.org<mailto:Proj at lists.maptools.org>
http://lists.maptools.org/mailman/listinfo/proj

_______________________________________________
Proj mailing list
Proj at lists.maptools.org<mailto:Proj at lists.maptools.org>
http://lists.maptools.org/mailman/listinfo/proj
_______________________________________________
Proj mailing list
Proj at lists.maptools.org<mailto:Proj at lists.maptools.org>
http://lists.maptools.org/mailman/listinfo/proj

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.maptools.org/pipermail/proj/attachments/20181029/98971e96/attachment-0001.htm