You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Inherited from Proj.4 and all its successors to this point, a UTM zone is a part of the projection and NOT a part of the coordinate, This means you set up the projection for a single zone, then run all your conversions through that. That is kind of okay when you are going from UTM to another coordinate system, but not the other way around, since you don't know the zone of a longitude until you pass it to the projection to work it out (okay, you can work it out, but the point is, you should not have to do a part of the projection's work to find it out what parameters it needs for a coordinate before you can even create the projection - it seems back-to-front).
So my approach will be to allow you to set the zone for a projection if you ave a bunch of coordinates to transform, but allow the coordinate to define the zone and that takes precedence. An x/y coordinate from a UTM projected map is of no use without knowing this additional information (i.e. which hemisphere and/or MGRS latitude zone, and which longitude zone the x/y is bound to).
The text was updated successfully, but these errors were encountered:
judgej
changed the title
UTM - is teh zone part of the coordiate or not?
UTM - is teeh zone part of the coordiate or not?
Oct 24, 2015
judgej
changed the title
UTM - is teeh zone part of the coordiate or not?
UTM - is the zone part of the coordiate or not?
Oct 24, 2015
I think the approach Proj.4 has taken is that a user will be driving the transformation commands by hand, and will know exactly what they are putting in and getting out. They can pass in lists of context-less decimals and know what is going to happen to them. My approach here is to put more type checking and bound restrictions on everything, so exceptions are raised when silly things are being done, and also all data has context, so that transformations can be sensibly chosen by the code where appropriate. For example, converting an Geodetic coordinate to an Geodetic coordinate will result in no conversion, because the code can see that a Geodetic coordinate has been supplied and needs no further conversion.
This one has me scratching my head a little.
Inherited from Proj.4 and all its successors to this point, a UTM zone is a part of the projection and NOT a part of the coordinate, This means you set up the projection for a single zone, then run all your conversions through that. That is kind of okay when you are going from UTM to another coordinate system, but not the other way around, since you don't know the zone of a longitude until you pass it to the projection to work it out (okay, you can work it out, but the point is, you should not have to do a part of the projection's work to find it out what parameters it needs for a coordinate before you can even create the projection - it seems back-to-front).
So my approach will be to allow you to set the zone for a projection if you ave a bunch of coordinates to transform, but allow the coordinate to define the zone and that takes precedence. An x/y coordinate from a UTM projected map is of no use without knowing this additional information (i.e. which hemisphere and/or MGRS latitude zone, and which longitude zone the x/y is bound to).
The text was updated successfully, but these errors were encountered: