[Proj] lonlat default datum confusion

Jose Gonçalves jagoncal at gmail.com
Fri Feb 3 11:21:00 PST 2012


Andrew

NAD27 is treated by a datum shift grid (or several grids as you can see in
the output with -v)

# +proj=lonlat +datum=NAD27 +ellps=clrk66
# +nadgrids=@conus, at alaska, at ntv2_0.gsb, at ntv1_can.dat

What the grids do is to estimate (delta_lon,delta_lat) to transform from
NAD27 to WGS84. Since your input point (-62.16775,16.74132) is outside of
the grid range, the shift is zero. So there is no change in the input
coordinates, and accidentally your result is correct.

Regards

Jose Gonçalves



2012/2/3 Andrew Simpson <drew.simpson.home at gmail.com>

> Thank you for the responses Frank and Jose.
>
> So when I do the UTM to lonlat with no datum, the conversion the results
> are in WGS84.
>
> When I go from lonlat to epsg:2004, cs2cs assumes there is no datum
> conversion needed, so I get the wrong results.
>
> But if I specify a source datum of NAD27 or WGS84 on the latlon, the
> towgs84 in the target epsg:2004 kicks in?
>
> Not sure why I can put either datum in and get the same result?
>
> Thanks again,
> Drew
>
> On Thu, Feb 2, 2012 at 6:22 PM, Jose Gonçalves <jagoncal at gmail.com> wrote:
>
>> Andrew
>>
>> Since you don't specify an ellipsoid in the source system, WGS84 is
>> assumed:
>>
>>
>> cs2cs -v +proj=lonlat +to +init=epsg:2004
>>
>> This is not enough because you must specify some datum control, such as
>> +towgs84=0,0,0 (notice that +datum=WGS84 is equivalent to +ellps=WGS84
>> +towgs84=0,0,0). You get the correct result with:
>>
>> cs2cs +proj=lonlat +towgs84=0,0,0 +to +init=epsg:2004
>> -62.16775 16.74132
>> 381799.69       1850374.10 37.86
>>
>>
>> Regards
>>
>> Jose Gonçalves
>>
>>
>>
>>
>> 2012/2/2 Andrew Simpson <drew.simpson.home at gmail.com>
>>
>>> Greetings,
>>>
>>> I am having trouble understanding how lonlat is handled in cs2cs and proj
>>>
>>> If I cs2cs straight from "WGS 84 / UTM zone 20N" to "Montserrat 1958 /
>>> BWI" I get one result.
>>>
>>> If I cs2cs to lonlat in between I get a different result.
>>>
>>> If I provide a datum on the conversion from lonlat to "Montserrat 1958 /
>>> BWI" such as WGS84, I get the original result, even if the datum is not
>>> applicable as in NAD27.
>>>
>>> Is the datum enabling a portion of code that wouldn't otherwise be used,
>>> and then just being discarded?
>>>
>>> What EPSG code would lonlat default to, or does it default to the +to
>>> coordinate system?
>>>
>>> Thanks for any thoughts
>>>
>>> Rel. 4.7.1, 23 September 2009 on Linux 2.6.26-2-686 #1 SMP Thu Sep 16
>>> 19:35:51 UTC 2010 i686 GNU/Linux
>>>
>>>
>>> ====================================
>>> --  All the way from UTM to Monty
>>> cs2cs -v +init=epsg:32620 +to +init=epsg:2004 <<EOF
>>> 588710.63       1851124.52
>>> EOF
>>> # ---- From Coordinate System ----
>>> #Universal Transverse Mercator (UTM)
>>> #       Cyl, Sph
>>> #       zone= south
>>> # +init=epsg:32620 +proj=utm +zone=20 +ellps=WGS84 +datum=WGS84 +units=m
>>> # +no_defs +towgs84=0,0,0
>>> #--- following specified but NOT used
>>> # +ellps=WGS84
>>> # ---- To Coordinate System ----
>>> #Transverse Mercator
>>> #       Cyl, Sph&Ell
>>> # +init=epsg:2004 +proj=tmerc +lat_0=0 +lon_0=-62 +k=0.9995000000000001
>>> # +x_0=400000 +y_0=0 +ellps=clrk80 +towgs84=174,359,365,0,0,0,0 +units=m
>>> # +no_defs
>>> 381799.69       1850374.10 37.86
>>> =====================================
>>>
>>> -- Inverse Proj from UTM
>>> invproj -v -f "%.5f" +init=epsg:32620  <<EOF
>>> 588710.63       1851124.52
>>> EOF
>>> #Universal Transverse Mercator (UTM)
>>> #       Cyl, Sph
>>> #       zone= south
>>> # +init=epsg:32620 +proj=utm +zone=20 +ellps=WGS84 +datum=WGS84 +units=m
>>> # +no_defs +towgs84=0,0,0
>>> #--- following specified but NOT used
>>> # +ellps=WGS84
>>> -62.16775       16.74132
>>>
>>> ======================================
>>> -- lonlat to Monty
>>> cs2cs -v +proj=lonlat +to +init=epsg:2004  <<EOF
>>> -62.16775 16.74132
>>> EOF
>>> # ---- From Coordinate System ----
>>> #Lat/long (Geodetic)
>>> #
>>> # +proj=lonlat +ellps=WGS84
>>> # ---- To Coordinate System ----
>>> #Transverse Mercator
>>> #       Cyl, Sph&Ell
>>> # +init=epsg:2004 +proj=tmerc +lat_0=0 +lon_0=-62 +k=0.9995000000000001
>>> # +x_0=400000 +y_0=0 +ellps=clrk80 +towgs84=174,359,365,0,0,0,0 +units=m
>>> # +no_defs
>>> 382121.20       1850599.03 0.00
>>>
>>> ======================================
>>> -- lonlat with a datum to Monty
>>> cs2cs -v +proj=lonlat +datum=NAD27 +to +init=epsg:2004  <<EOF
>>> -62.16775 16.74132
>>> EOF
>>> # ---- From Coordinate System ----
>>> #Lat/long (Geodetic)
>>> #
>>> # +proj=lonlat +datum=NAD27 +ellps=clrk66
>>> # +nadgrids=@conus, at alaska, at ntv2_0.gsb, at ntv1_can.dat
>>> # ---- To Coordinate System ----
>>> #Transverse Mercator
>>> #       Cyl, Sph&Ell
>>> # +init=epsg:2004 +proj=tmerc +lat_0=0 +lon_0=-62 +k=0.9995000000000001
>>> # +x_0=400000 +y_0=0 +ellps=clrk80 +towgs84=174,359,365,0,0,0,0 +units=m
>>> # +no_defs
>>> 381799.69       1850374.10 37.86
>>>
>>> _______________________________________________
>>> 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.osgeo.org/pipermail/proj/attachments/20120203/984d1e15/attachment.html>


More information about the Proj mailing list