Limitation of omerc in Proj 4.8.0: the alpha must point in a northish direction
2012-06-19 12:46:27 GMT
I discovered an unexpected behaviour of the new omerc
implementation of Proj 4.8.0,
and I want to warn others about it. But I don’t think it needs to be fixed, as long as you
are aware of it.
In the old omerc implementation (Proj 4.7.0), you got an error message if alpha was
exactly -90 or 90 degrees. Now, you don’t get the error message, but the results are
unreliable. What’s more, the results are unreliable unless alpha points in a northish
direction. I mean, alpha values in the open interval -90 to 90 degrees are okay (and
also if you add +/-360 degrees), but not southish values.
Example: the omerc approximation of the Madagascar projection:
>proj +proj=omerc +lat_0=-18.9 +lonc=44.1 +alpha=18.9 +k=0.9995 +x_0=400000 +y_0=800000 +gamma=18.9 +ellps=intl +towgs84=-189,-242,-91 +pm=paris +units=m +no_defs
This seems to work as expected; the central point in Long/Lat is projected to False Easting
and False Northing.
But let’s add 180 degrees to both alpha and gamma. That should effectively be the same
projection, I would think (or possibly rotated 180 degrees around the central point).
>proj +proj=omerc +lat_0=-18.9 +lonc=44.1 +alpha=198.9 +k=0.9995 +x_0=400000 +y_0=800000 +gamma=198.9 +ellps=intl +towgs84=-189,-242,-91 +pm=paris +units=m +no_defs
Not what I would expect. As far as I can understand, these weird results appear when alpha
is southish (in the closed interval 90 to 270). The omerc of Proj 4.7.0 did not behave this way.
But as long as you know about it, the behaviour is tolerable. After all, the initial line leaves the
central point in two opposite directions, so you just have to choose the northish one for alpha.
(All predefined omerc instances in the nad/epsg file have a northish alpha, I think.)
_______________________________________________ Proj mailing list Proj <at> lists.maptools.org http://lists.maptools.org/mailman/listinfo/proj