[Proj] cs2cs - specifying UTM zone on command line

Mon Oct 29 14:20:36 EST 2018

I understand your concern.
Where my thoughts deviate (and I have no background in this - only dealing
with it due to immediate necessity), is that I'd consider the UTM zone a
part of the OUTPUT, whereas you seem to consider it part of the required
input (lat, long & UTM zone).

So in my case:
 in: lat & long
out: UTM zone, easting & northing.

so the process would look more like:
$ echo 6 51 | proj +proj=utm +zone=auto
31    710488.86       5654109.18

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

note that if you DID specify the zone on the command line (as your example
'+zone=32' instead of '+zone=auto') , there would be no change to the
current output (printing the zone as output would be redundant).
Regards,
Robb.

On Mon, Oct 29, 2018 at 2:53 PM Kristian Evers <kreve at sdfe.dk> wrote:

>
>
> On 29 Oct 2018, at 19:11, Robb Main <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> wrote:
>
>> Robb,
>>
>> On 29 Oct 2018, at 18:34, Robb Main <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> wrote:
>>
>>> Robb,
>>>
>>> /Kristian
>>>
>>> On 29 Oct 2018, at 17:30, Robb Main <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
>>> http://lists.maptools.org/mailman/listinfo/proj
>>>
>>>
>>> _______________________________________________
>>> Proj mailing list
>>> Proj at lists.maptools.org
>>> http://lists.maptools.org/mailman/listinfo/proj
>>
>> _______________________________________________
>> Proj mailing list
>> Proj at lists.maptools.org
>> http://lists.maptools.org/mailman/listinfo/proj
>>
>>
>> _______________________________________________
>> Proj mailing list
>> Proj at lists.maptools.org
>> http://lists.maptools.org/mailman/listinfo/proj
>
> _______________________________________________
> Proj mailing list
> Proj at lists.maptools.org
> http://lists.maptools.org/mailman/listinfo/proj
>
>
> _______________________________________________
> Proj mailing list
> 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/67d09e45/attachment.htm 