[postgis-users] Spatial Ref Sys oops

[Frank Warmerdam]

Carl Anderson wrote:
> I have tested the +to_meter parameter in proj and invproj,  it just is 
> not working for me. but falling back to the old +units=us-ft is working.
> I see clearly that the +to_meter style is much better, allowing for 
> clearer conversions from feet to meters, but something is broken there.

Carl,

Could you provide an example with "proj" where +to_meter does not work?

I just tried:

warmerda at gdal2200[1]% proj +proj=utm +zone=11 +ellps=clrk66
-117 44
500000.00       4871656.65
-116 44
580176.57       4872142.71
warmerda at gdal2200[2]% proj +proj=utm +zone=11 +ellps=clrk66 +to_meter=3
-116 44
193392.19       1624047.57

The +to_meter seems to be affecting things as expected in this case.

> 
> Can someone else who has proj4 (4.4.5 or 4.4.6) support in their postgis
> cut and paste the examples from the last post?  maybe I have cross 
> linked libs.  the correct answer is the second.  -100W is in Texas not 
> Georgia.

I have already deleted the last post.  If you resend directly to me I
can try it out.

>> Note that in proj for, all the offsets are in meters, even when the 
>> output projection is in feet. Fun.
>>
> 
> This might be a design principle, but testing shows this to be different 
> (and maybe a feature that I don't understand) possibly Wamerdam can shed 
> some light.  your epsg file (very similar to the one distributed in 
> PROJ4 (4.4.6)) has:

I believe Paul is right that x_0 and y_0 are always in meters.  Do you have
some reason to believe otherwise?  I tried the following test which seems
to confirm that the false easting is in meters:

warmerda at gdal2200[5]% proj +proj=tmerc +lat_0=30 +lon_0=-84.16666666666667 +k=0.9999 +x_0=700000 +y_0=0 +ellps=GRS80 
+datum=NAD83 +to_meter=0.3048006096012192 +no_defs
-84.16666666 30
2296583.34      0.00


>> # NAD 1983 StatePlane Georgia West FIPS 1002 Feet
>> <102667> +proj=tmerc +lat_0=30 +lon_0=-84.16666666666667 +k=0.999900
>> +x_0=700000 +y_0=0 +ellps=GRS80 +datum=NAD83
>> +to_meter=0.3048006096012192  no_defs <>
> 
> 
> CVS's (spatial_ref_sys.sql) entry
> is:
> --- ESRI : NAD_1983_StatePlane_Georgia_West_FIPS_1002_Feet
> ---
> INSERT INTO "spatial_ref_sys" 
> ("srid","auth_name","auth_srid","srtext","proj4text") VALUES 
> (102667,'ESRI',102667,'PROJCS["NAD_1983_StatePlane_Georgia_West_FIPS_1002_Feet",GEOGCS["GCS_North_American_1983",DATUM["D_North_American_1983",SPHEROID["GRS_1980",6378137,298.257222101]],PRIMEM["Greenwich",0],UNIT["Degree",0.017453292519943295]],PROJECTION["Transverse_Mercator"],PARAMETER["False_Easting",2296583.333333333],PARAMETER["False_Northing",0],PARAMETER["Central_Meridian",-84.16666666666667],PARAMETER["Scale_Factor",0.9999],PARAMETER["Latitude_Of_Origin",30],UNIT["Foot_US",0.30480060960121924]]','+proj=tmerc 
> +lat_0=30.000000000 +lon_0=-84.166666667 +k=0.999900 +x_0=2296583.333 
> +y_0=0.000 +ellps=GRS80 +to_meter=+0.3048006096 ');
> 
> 
> Observe the x_0 parameter in the epsg Proj4 INIT file is 700000.00, 
> (feet) per the NAD83 definition false easting is 700,000 feet.
> The spatial_ref_sys entry is in meters.

It would indeed appear that the definition for <102667> from the esri
translation file is wrong.   I don't believe I produced this file.  I
think the 4.4.6 release has corrected definition (with regards to units
and false easting/northing values) for all the EPSG coordinate systems.

> Why is to_meter=0.3048006096 but us-ft defined as 0.304800609601219 per 
> prog -lu ?   It is beneath my usable scale, but the change seems arbitrary.

This would appear to be a peculariarity of the translation used to produce
the file.  I try to use a %.16g format string to retain essentially all
the precision of a double.

In general, I am not sure how the epsg and spatial_ref_sys.sql files
were produced.  I think it was with older version of my OGRSpatialReference's
class translation capabilities which had a number of flaws ... both in the
way they produced PROJ.4 strings, and in their understanding of ESRI WKT.
There were new esri translations posted to the PROJ.4 list but I haven't
dug into them yet.

I don't know if this helps, other than to confirm that some of the
coordinate systems as distributed with PostGIS are likely messed up.

Best regards,

-- 
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | Geospatial Programmer for Rent