osgeo / proj

PROJ - Cartographic Projections and Coordinate Transformations Library

PROJ

PROJ is a generic coordinate transformation software, that transforms coordinates from one coordinate reference system (CRS) to another. This includes cartographic projections as well as geodetic transformations.

For more information on the PROJ project please see the web page at:

https://proj.org/

The PROJ mailing list can be found at:

https://lists.osgeo.org/mailman/listinfo/proj/

See the NEWS.md file for changes between versions.

The following command line utilities are included in the PROJ package:

• proj: for cartographic projection of geodetic coordinates.
• cs2cs: for transformation from one CRS to another CRS.
• geod: for geodesic (great circle) computations.
• cct: for generic Coordinate Conversions and Transformations.
• gie: the Geospatial Integrity Investigation Environment.
• projinfo: for geodetic object and coordinate operation queries.
• projsync: for synchronizing PROJ datum and transformation support data.

More information on the utilities can be found on the PROJ website.

Installation

Consult the Installation page of the official documentation. For builds on the master branch, install.rst might be more up-to-date.

Distribution files and format

Sources are distributed in one or more files. The principle elements of the system are stored in a compressed tar file named proj-x.y.z.tar.gz where "x" will indicate the major release number, "y" indicates the minor release number, and "z" indicates the patch number of the release.

In addition to the PROJ software package, distributions of datum conversion grid files and PROJ parameter files are also available. The grid package is distributed under the name proj-data-x.y.zip, where "x" is the major release version and "y" is the minor release version numbers. The resource packages can be downloaded from the PROJ website.

More info on the contents of the proj-data package can be found at the PROJ-data GitHub repository.

The resource file packages should be extracted to PROJ_LIB where PROJ will find them after installation. The default location of PROJ_LIB on UNIX-based systems is /usr/local/share/proj but it may be changed to a different directory. On Windows you have to define PROJ_LIB yourself.

As an alternative to installing the data package on the local system, the resource files can be retrieved on-the-fly from the PROJ CDN. A network-enabled PROJ build, will automatically fetch resource files that are not present locally from the CDN.

Citing PROJ in publications

See CITATION

proj's Issues

add a hint to decimal degrees to proj4 manpage

Reported by timmie on 31 Jul 2008 15:40 UTC
Often users need to convert to/from decimal degrees.

The default output is DMS.

Please add a hint to the manpage that -f '%.8f' can be used to get decimal degree output that can be used for further processing tools. There is no easy hint at the moment how to get the decimal degrees.

See here as a reference:
http://thread.gmane.org/gmane.comp.gis.proj-4.devel/1640/focus=1643

Thanks.

Migrated-From: https://trac.osgeo.org/proj/ticket/10

Proj4 gives a error code -45 for grid conversion

Reported by jaruna on 15 Apr 2009 14:06 UTC
HELP...New to proj4.

For coordinate in degrees (x,y,z) (-2.1489573535205362, 0.99775570445558781, 0.00000000000000000 ) and covnerting FROM: wgs84_utm(zone=10)_m TO: nad27_utm(zone=10)_m gives a pj_errorno as -45.

pj_datum_transform((PJ_)from_cs, (PJ_)to_cs,1,0,&coord.x,&coord.y,&coord.z);

Also need access to bug report at
http://bugzilla.remotesensing.org/show_bug.cgi?id=1038

Migrated-From: https://trac.osgeo.org/proj/ticket/36

epsg file: wrong transformation parameters for EPSG 31370 ?

Reported by mlennert on 9 Jul 2009 16:58 UTC
In http://svn.osgeo.org/metacrs/proj/trunk/proj/nad/epsg the definition of EPSG 31370 includes the following transformation parameters:

+towgs84=106.869,-52.2978,103.724,-0.33657,0.456955,-1.84218,1

This seems to be incorrect. The correct parameters should be something like this

+towgs84=-106.869,52.2978,-103.724,0.33657,-0.456955,1.84218,1

This is confirmed by EPSG transformation 15929 which indicates the following parameters:

+towgs84=-106.869,52.2978,-103.724,-0.33657,0.456955,-1.84218,-1.2747

but specifies that the rotation parameters are Bursa-Wolf and so for proj's epsg, they apparently have to be negated (note also the difference scale. Not sure whether this needs to be negated or not).

More in this thread:

[http://lists.maptools.org/pipermail/proj/2009-July/004774.html]

Moritz

Migrated-From: https://trac.osgeo.org/proj/ticket/47

Offset in WGS84 to UTM32 ED50 projection

Reported by lcivik on 25 Mar 2009 14:27 UTC
HI,
I used proj4 to translate WGS84 data in UTM32 ED50. I compared the outputs with other conversion tools like Oracle Spatial and Geotools.
I always obtained and offset of more than 100m, as shown below
WGS84 (43.82785, 11.16217)
Oracle (4855222.02796736 673936.770861242)
Geotools (4855222.270847487,673933.6868168702)
Proj4 ''' (4855113.67 673860.23)'''

Is there a bug in this kind of projection?

Migrated-From: https://trac.osgeo.org/proj/ticket/32

command-line geod fails when listing points along the equator

Reported by mikebanahan on 3 Aug 2009 07:03 UTC
Using geod to list points on a great circle route around the equator causes NaN values to be produced, e.g

geod +ellps=WGS84 +n_S=25 +lat_1=0dN +lon_1=-2dW +lat_2=0dN +lon_2=2dE -f %f

produces

0.000000 -2.000000

nan nan

nan nan

... etc

Looking at the code there are two clear problems. The first is not relevant to this but should be fixed. Line 18 in geod_for.c reads

if ((merid = fabs(sina12 = sin(al12)) < MERI_TOL)) {

whereas I believe it SHOULD be

if ((merid = (fabs(sina12 = sin(al12)) < MERI_TOL))) {

i.e instead of assigning the fabs value to merid, it should assign the truth value.

That then prompts what appears to be correct behaviour on north-south geodesics along the 0 longitude meridian

The cause of NaN is at lines 41-46:

41 if (merid) s1 = HALFPI - th1;

42 else {

43 s1 = (fabs(M) >= 1.) ? 0. : acos(M);

44 s1 = sinth1 / sin(s1);

45 s1 = (fabs(s1) >= 1.) ? 0. : acos(s1);

46 }

Where on line 43 s1 becomes zero and line 44 immediately produces divide-by-zero

As a result I've had to switch to using Geographic Library for great-circle work, which is a shame. I don't understand the code well enough (too few comments here and what are to me, opaque variable names) to fix it. It doesn't help that I'm not a good enough geographer/mathematician to understand the algorithm of course.

Migrated-From: https://trac.osgeo.org/proj/ticket/48

gdaltransform.exe incorrectly translates long island utm file to wgs84

Reported by Himaunshu on 16 Sep 2008 15:46 UTC
Hi,

If I use

gdaltransform.exe -s_srs EPSG:32118 -t_srs EPSG:4326
1140000.000 192000.000
-63.9241443598518 41.4600795990435 0

The output should be
73d26'18.08"W, 40d41'32.29"N in decimal degrees.

Last Modified by warmerdam on 17 Jun 2009 03:17 UTC

Migrated-From: https://trac.osgeo.org/proj/ticket/14

Patch for warnings and perhaps a bug

Reported by dcthomp on 3 Jun 2008 15:19 UTC
I've made some changes to PROJ.4 to get it compiling without
any warnings even setting CFLAGS="-W -Wall". I've attached a
patch.

Most of the changes are straightforward, a few are tedious, and
one of the warnings appears to actually point to a bug. Specifically,
in src/PJ_imw_p.c it looks like the argument "double* yc" is
shadowed by a local variable below and thus never used. The patch
includes what I believe to be a fix, but it would be nice if someone
reviewed it.

The only other real problem I had was with the declaration and
initialization of "static char EMESS_H_ID[]" inside src/emess.h.
Since this header file is included multiple times it results in
EMESS_H_ID being instantiated in multiple object files. I removed
the variable since it doesn't appear to be used.

Migrated-From: https://trac.osgeo.org/proj/ticket/4

tmerc "back folding" problems.

Reported by warmerdam on 17 Jun 2008 15:46 UTC
You can demonstrate the problem with the PROJ.4 commandline program cs2cs:

cs2cs +proj=latlong +datum=WGS84 +to +proj=utm +zone=32 +datum=WGS84

Give as input, this point in Alaska:

-149.66 64.237

And you get this:

522986.92       5029096.80 0.00

which is somewhere in Italy (near Milan).

I realize this result is an effect of using tmerc equations far from where they are valid, but it causes serious problems in MapServer when trying to establish which images intersect a target map request. In this case we have images from around the world, some in relatively local projections like tmerc. We reproject the map request bounds into the target projection and check for overlap.

What I would like is if we could make the tmerc projection fail (ie return HUGE_VAL) for points so far from the central meridian that they are likely to start folding back on themselves.

Migrated-From: https://trac.osgeo.org/proj/ticket/5

CTABLEs are arch dependent

Reported by frankie on 29 May 2009 18:15 UTC
It would be useful having an arch-independent format used for the CTABLE files. That would allow moving/sharing files among multiple platforms without unexpected results.

Migrated-From: https://trac.osgeo.org/proj/ticket/44

stere projection produces wrong results on Win32 MSVC7

Reported by warmerdam on 21 Aug 2008 17:26 UTC
Using the supplied Makefile.vc, I did two builds for each version. The "release" build uses the OPTFLAGS settings
as distributed in the source, while the "debug" build swaps the OPTFLAGS to use the second set of settings (which is commented out in the sources).

The command:

echo 105 40 | proj +proj=stere +lat_0=90 +lon_0=0 +lat_ts=70 +datum=WGS84

The Results:

Flavor 7 (debug): 5577808.93      1494569.40
Flavor 7 (release): 5610189.12      1503245.64
Flavor 8 (debug): 5577808.93      1494569.40
Flavor 8 (release): 5577808.93      1494569.40
Flavor 9 (debug): 5577808.93      1494569.40
Flavor 9 (release): 5577808.93      1494569.40

So, we can see this is a direct result of doing an optimized build with Flavor 7 (Visual Studio .Net 2003).

So, then I downloaded and installed Service Pack 1 (http://www.microsoft.com/downloads/details.aspx?familyid=69d2219f-ce82-46a5-8aec-072bd4bb955e ) and rebuilt a "release" version. The results were the same.

Then, I added the "/Op" (Improve Float Consistency) flag and then the "release" results matched the "debug" results.

OPTFLAGS= /nologo /Ox /Op /MD

Eric G. Miller

Last Modified by warmerdam on 22 Aug 2008 04:19 UTC

Migrated-From: https://trac.osgeo.org/proj/ticket/12

Error converting WGS84 lat long to RSO Malaya (m)

Reported by bjorn on 16 Apr 2009 12:39 UTC
Using parameters described in Proj-4.6.1\nad\epsg for GDM2000 I am getting the right results.
But when I am using the parameters for # Kertau (RSO) / RSO Malaya (m) the result is not correct.
The parameters I am using are:

cs2cs +proj=longlat +ellps=WGS84 +no_defs  +to +proj=omerc +lat_0=4  +lonc=102.25 +alpha=323.0257905 +k=0.99984 +x_0=804670.24 +y_0=0   +a=6377295.664 +b=6356094.667915204 +units=m +no_uoff +rot_conv +no_defs
101.77245333333333 3.1964683333333332
419628.13       353695.12 0.000

The espected result is: 419791.755 353716.076
The deviation is 163m in east and 21 m in north direction.
I am using the binary cs2cs.exe from http://trac.osgeo.org/proj/proj446_win32_bin.zip

Last Modified by warmerdam on 17 Apr 2009 14:36 UTC

Migrated-From: https://trac.osgeo.org/proj/ticket/37

nmake.opt comments need help

Reported by dougrm on 8 Sep 2009 17:41 UTC
This paragraph in nmake.opt is very misleading and fairly wrong.

# Set the following to the directory where the PROJ distribution 
# data files (ie, the contents of ..\NAD).  The following assumes
# the PROJ distribution is unpacked as C:\PROJ, which generally must
# be adjusted.  It is also possible to leave this, and define the
# PROJ_LIB environment variable to point to the NAD directory.

It should read something like this:

# Set the following to the directory where the PROJ distribution data files
# (ie, the contents of ..\NAD) are to be installed.  It is possible to later
# move the data files to another directory, and define the PROJ_LIB
# environment variable to point to that directory.  It is also possible to
# have PROJ_LIB name the original NAD directory of the unpacked PROJ
# distribution.  Any setting of the PROJ_LIB environment variable takes
# precedence at runtime over the setting of the PROJ_LIB_DIR macro stored in
# the compiled software.

Migrated-From: https://trac.osgeo.org/proj/ticket/50

Automatic datum shift when +nadgrids=@nul is not explicitly given

Reported by janh on 27 Nov 2008 14:27 UTC
An automatic datum shift to WGS84 seems to take place, even when not requested.

Test point 9018/375648 (Dutch RD, EPSG:28992 without WGS84 datum shift)
The source PROJ string is:
+proj=sterea +lat_0=52.15616055555555 +lon_0=5.38763888888889 +k=0.999908 +x_0=155000 +y_0=463000 +ellps=bessel +units=m +no_defs.
I tested this string both without and with +nadgrids=@null on four target projections:

1. to latlon Bessel (+proj=longlat +ellps=bessel +no_defs)
   --> (without nadgrids in source) 3.291612 51.352060
   --> (with nadgrids null in source) 3.291612 51.351476

2. to latlon Bessel with nadgrids null (+proj=longlat +ellps=bessel +no_defs +nadgrids=@null)
   --> (without nadgrids in source) 3.291612 51.352643
   --> (with nadgrids null in source) 3.291612 51.352060

3. to latlon Bessel on the WGS84 datum (+proj=longlat +ellps=bessel +no_defs +datum=WGS84)
   --> (without nadgrids in source) 3.291612 51.352060
   --> (with nadgrids null in source) 3.291612 51.351476

4. to latlon on the WGS84 datum (+proj=longlat +no_defs +datum=WGS84)
   --> (without nadgrids in source) 3.291612 51.352643
   --> (with nadgrids null in source) 3.291612 51.352060

5. and 3) give the same results; so do 2) and 4), which seems to inicate that an automatic datum shift to WGS84 takes place, even when not requested. I'm not sure about the effects of +nadgrids=@null. Specifying +ellips=bessel without adding +nadgrids=@null seems to cause an automatic WGS84 datum shift, whether or no datum=WGS84 is specified (1a = 3a). If +nadgrids=@null is specified in the the source projection, but not in the target projection (1b = 3b), the latlon coordinates shift about 65m to the south. When +nadgrids=@null is omitted in the source projection, but added in the target projection, the resulting coordinates are shifted of 65M to the north (2a). Finally, when +nadgrids=@null is specified in both source and target projections, the datum shift is applied nevertheless (2b is equal to 1a and 3a). Finally, specifying a WGS84 datum shift for the target projection without the Bessel ellipsoide gives the same values as 2.

Migrated-From: https://trac.osgeo.org/proj/ticket/22

utm/GRS80 to tmerc/intl conversion poor now, was good in 4.4.9

Reported by janne on 17 Sep 2008 10:31 UTC
The +towgs84 parameters in the epsg file of version 4.6.1 are incorrect. These are not the TOWGS84 parameters of the current or even the prior versions of the real EPSG database. Additionally the parameters in the Proj4's epsg file are the same.

List of CRSs having wrong parameters:
EPSG:2391
EPSG:2392
EPSG:2393
EPSG:2394
EPSG:3385
EPSG:3386

Migrated-From: https://trac.osgeo.org/proj/ticket/15

ETRS89-based CRSs missing datum definition?

Reported by msieczka on 14 Aug 2008 11:46 UTC
PROJ 4.6.0 does not apply a datum shift reprojecting between a CRS which has an implicit datum definition (e.g. Pulkovo 1942/58-based EPSG 4179, for which GDAL uses towgs84=33.4,-146.6,-76.3,-0.359,-0.053,0.844,-0.84) and an ETRS89-based CRS, e.g. EPSG 2180, that has no implicit towgs84 or datum.

The above results in reprojection errors of dozens of meters and makes using EPSG codes for ETRS89-based CRS unreliable. Should PROJ.4 and GDAL enforce towgs84=0,0,0 for all ETRS89 CRSs that have no implicit datum definition otherwise?

There are 58 CRSs in PROJ.4 4.6 epsg file that are based on ETRS89 datum (including e.g. pan-European LCC EPSG 3034 or LAEA EPSG 3035). Using any of their EPSG codes leads to huge reprojection errors.

Example:

The source EPSG 4179 is Pulkovo 1942(58) based, target EPSG 2180 is ETRS89 based. Since no explicit towgs84 is specified for EPSG 2180 but there is for EPSG 4179, GDAL fails to perform the datum shift and returns a wrong result:

$ echo "16E 52N 64" | gdaltransform -s_srs EPSG:4179 -t_srs EPSG:2180
294132.884446735 463557.976146893 64

The correct reprojection is possible if the EPSG 2180 definition is given in proj4 format plus +towgs84=0,0,0:

$ echo "16E 52N 64" | gdaltransform -s_srs EPSG:4179 -t_srs "+proj=tmerc +lat_0=0 +lon_0=19 +k=0.9993 +x_0=500000 +y_0=-5300000 +ellps=GRS80 +units=m +towgs84=0,0,0"
294006.094422874 463523.916413687 103.090447655879

For instance, GRASS always forces towgs84=0,0,0 for EPSG 2180 and does the reprojection right. I'm not 100% sure if towgs84=0,0,0 is the correct, ultimate solution, but there is something to it.

Migrated-From: https://trac.osgeo.org/proj/ticket/11

new +proj type needed for epsg's

Reported by mc82 on 2 Jul 2008 13:14 UTC
Currently there are only two types of oblique mercator projections readable from epsg. They are somerc and omerc. somerc is the swiss version omerc is non-natural origin. There needs to be a +proj=rso (Rectified Skew Orthomorphic) or +proj=homerc (Hotine Oblique Mercator) that would basically add the tag +no_uoff in the proj4 definition in the epsg file. With this added tag, projections such as michigan georef ought to have their +proj reset in the epsg to the new "homerc" as well. Here are what test results should look like when going from geographic NAD83 to this projection.

Point 1

-86 longitude

43 latitude



Point 2

-84 longitude

44 latitude



Point 1 transformed by Autocad

499864.50007694 X georef meters

272108.85926347 Y georef meters

Point 1 transformed using proj 446

499864.50 X georef meters

272108.86 Y georef meters



Point 2 transformed by Autocad

660180.92564610 X georef meters

385135.16670815 Y georef meters

Point 2 transformed using proj 446

660180.93 georef meters

385135.17 georef meters

Last Modified by warmerdam on 21 Aug 2008 19:59 UTC

Migrated-From: https://trac.osgeo.org/proj/ticket/6

Some Srid not supported.

Reported by yangyong on 27 May 2009 06:30 UTC
I tested out that 2 problems exists:

1. The Srid 28992 is sopposed to be supported in the latest PROJ.4
   http://www.spatialreference.org/ref/epsg/28992/
   But when it will throw exception when I use it through proj4.
   Similar problem will happen to all the following "sterea" projects:

<28992> +proj=sterea +lat_0=52.15616055555555 +lon_0=5.38763888888889 +k=0.9999079 +x_0=155000 +y_0=463000 +ellps=bessel +units=m +no_defs  <>
<2036> +proj=sterea +lat_0=46.5 +lon_0=-66.5 +k=0.999912 +x_0=2500000 +y_0=7500000 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs  <>
<2171> +proj=sterea +lat_0=50.625 +lon_0=21.08333333333333 +k=0.9998 +x_0=4637000 +y_0=5647000 +ellps=krass +towgs84=33.4,-146.6,-76.3,-0.359,-0.053,0.844,-0.84 +units=m +no_defs  <>
<2172> +proj=sterea +lat_0=53.00194444444445 +lon_0=21.50277777777778 +k=0.9998 +x_0=4603000 +y_0=5806000 +ellps=krass +towgs84=33.4,-146.6,-76.3,-0.359,-0.053,0.844,-0.84 +units=m +no_defs  <>
<2173> +proj=sterea +lat_0=53.58333333333334 +lon_0=17.00833333333333 +k=0.9998 +x_0=3501000 +y_0=5999000 +ellps=krass +towgs84=33.4,-146.6,-76.3,-0.359,-0.053,0.844,-0.84 +units=m +no_defs  <>
<2174> +proj=sterea +lat_0=51.67083333333333 +lon_0=16.67222222222222 +k=0.9998 +x_0=3703000 +y_0=5627000 +ellps=krass +towgs84=33.4,-146.6,-76.3,-0.359,-0.053,0.844,-0.84 +units=m +no_defs  <>
<2200> +proj=sterea +lat_0=46.5 +lon_0=-66.5 +k=0.999912 +x_0=300000 +y_0=800000 +a=6378135 +b=6356750.304921594 +units=m +no_defs  <>
<2290> +proj=sterea +lat_0=47.25 +lon_0=-63 +k=0.999912 +x_0=700000 +y_0=400000 +a=6378135 +b=6356750.304921594 +units=m +no_defs  <>
<2291> +proj=sterea +lat_0=47.25 +lon_0=-63 +k=0.999912 +x_0=400000 +y_0=800000 +a=6378135 +b=6356750.304921594 +units=m +no_defs  <>
<2292> +proj=sterea +lat_0=47.25 +lon_0=-63 +k=0.999912 +x_0=400000 +y_0=800000 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs  <>
<2953> +proj=sterea +lat_0=46.5 +lon_0=-66.5 +k=0.999912 +x_0=2500000 +y_0=7500000 +ellps=GRS80 +units=m +no_defs  <>
<2954> +proj=sterea +lat_0=47.25 +lon_0=-63 +k=0.999912 +x_0=400000 +y_0=800000 +ellps=GRS80 +units=m +no_defs  <>
<3120> +proj=sterea +lat_0=50.625 +lon_0=21.08333333333333 +k=0.9998 +x_0=4637000 +y_0=5467000 +ellps=krass +towgs84=33.4,-146.6,-76.3,-0.359,-0.053,0.844,-0.84 +units=m +no_defs  <>
<3328> +proj=sterea +lat_0=52.16666666666666 +lon_0=19.16666666666667 +k=0.999714 +x_0=500000 +y_0=500000 +ellps=krass +towgs84=33.4,-146.6,-76.3,-0.359,-0.053,0.844,-0.84 +units=m +no_defs  <>
<22780> +proj=sterea +lat_0=34.2 +lon_0=39.15 +k=0.9995341 +x_0=0 +y_0=0 +a=6378249.2 +b=6356515 +units=m +no_defs  <>
<28991> +proj=sterea +lat_0=52.15616055555555 +lon_0=5.38763888888889 +k=0.9999079 +x_0=0 +y_0=0 +ellps=bessel +units=m +no_defs  <>
<28992> +proj=sterea +lat_0=52.15616055555555 +lon_0=5.38763888888889 +k=0.9999079 +x_0=155000 +y_0=463000 +ellps=bessel +units=m +no_defs  <>
<31600> +proj=sterea +lat_0=45.9 +lon_0=25.39246588888889 +k=0.9996667 +x_0=500000 +y_0=500000 +ellps=intl +units=m +no_defs  <>
<31700> +proj=sterea +lat_0=46 +lon_0=25 +k=0.99975 +x_0=500000 +y_0=500000 +ellps=krass +units=m +no_defs  <>

2. The Srid 7415/7402 are not supported in latest proj4. I want to make sure it will supported or not.

http://www.spatialreference.org/ref/epsg/7415/

http://www.spatialreference.org/ref/epsg/7402/

Any hints will be appreciated.

Last Modified by warmerdam on 17 Jun 2009 03:09 UTC

Migrated-From: https://trac.osgeo.org/proj/ticket/43

fallback to 7/3 param transform when gridshift transform fails

Reported by cdestigter on 4 Nov 2008 21:08 UTC
Posted to proj user list on 16 April 08:

We came across some out-of-grid geometries when transforming from EPSG:27200 (New Zealand Map Grid). The results returned included INFs and NANs, which was hardly useful.

As a solution I wrote a patch for the pj_datum_transform function in Proj. The patch first tries to convert coordinates using the gridshift approach if available, but on failure will fall back to using the appropriate 3- or 7-parameter transform.

I've updated the patch to a universal diff and attached it to this ticket.

Comment from the original post ( hamish_b at yahoo dot com ):
Yes, the distortion grid hugs the coast quite closely in places.
(regardless of file size issues, it's based on trig stations, so that's hardly surprising)

I've experienced this in GRASS when plotting a lat/lon grid over a NZMG location with the 'd.grid -g' or 'ps.map geogrid' modules. I had to switch to the 7 term transform to get it to work. But then at a scale where you're going far offshore switching away from the grid probably doesn't make any difference. (for me it was just ~10-20km west of Fiordland when it failed)

NZMG distortion gets very bad (totally wonky) far away from the main coasts, if your data is from like the Kermadec, Chatham, or Auckland Islands I think you probably should try hard to use something else. (somewhen I made a screenshot of that)

One worry I have with the patch is that it makes the data of uneven quality across the dataset. (but again NZMG/NZGD1949 is pretty much ???? at sea anyway, so maybe who cares?)

regards,
Hamish

Dept Marine Science
University of Otago

Migrated-From: https://trac.osgeo.org/proj/ticket/19

Error converting WGS84 lat long to RSO Malaya (m), ref closed ticket #37

Reported by bjorn on 29 Apr 2009 11:06 UTC
I have found datum shift parameters (+towgs84=-11,851,5).
Using cs2cs version 4.4.6:
cs2cs +proj=longlat +ellps=WGS84 +no_defs +to +proj=omerc +lat_0
=4 +lonc=102.25 +alpha=323.0257905 +towgs84=-11,851,5 +k=0.99984 +x_0=804670.24 +y_0=0 +a=6377295.664 +b=6356094.667915204 +units=m +no_uoff +rot_conv +no_defs
The output coords are: 419628.08 353674.74

Using cs2cs version 4.6.1 gives the same result.(also without the +towgs84 parameter)

Using C# together with old libraries with the following code:
inpWgs84.ImportFromProj4("+proj=longlat +ellps=WGS84 +no_defs <>");
outRSO.ImportFromProj4("+proj=omerc +lat_0=4 +lonc=102.25 +alpha=323.0257905 +k=0.99984 +x_0=804670.24 +y_0=0 +a=6377295.664 +b=6356094.667915204 +towgs84=-11,851,5,0,0,0,0 +units=m +no_uoff +rot_conv +wktext +no_defs <>");

The result E: 419791.024 N: 353715.943 is very close to what I espect. (dx=0.73 dy=0.13)

C# using 4.6.1 libraries (from FWTools2.3.0):
The code is the same as with the old libraries:
Now the result is E= 419628.127 N: 353695.117. Removing +towgs84 in the +to string the result remains the same.

This is still far from the expected result (E:419719.755 N:353716.076)

As far as I can se the only way to get close to the correct result is to use the old libraries in C#.

I am not getting correct results by using version 4.6.1 as Frank Warmerdam said in ticket #37.

Migrated-From: https://trac.osgeo.org/proj/ticket/38

Help Frank Help You

Reported by Jive on 15 May 2008 20:59 UTC
FrankW puts in a lot of volunteer time wrangling up these osgeo facilities; I am creating this issue to make sure he has hooked up Trac authentication correctly.

This issue can be closed when he is happy.

Migrated-From: https://trac.osgeo.org/proj/ticket/1

biveval.c is not reentrant

Reported by runeaa on 23 Jan 2009 09:39 UTC
I suggest removing the static variables used for value passing between functions in biveval.c with ordinary function arguments to make it reentrant. Proposed changed file:

/* procedures for evaluating Tseries */
#ifndef lint
static const char SCCSID[      4.4     93/06/12        GIE     REL";
#endif
# include <projects.h>
# define NEAR_ONE       1.00001
static double ceval(struct PW_COEF *C, int n, projUV w, projUV w2) {
        double d=0, dd=0, vd, vdd, tmp, *c;
        int j;

        for (C += n ; n-- ; --C ) {
                if (j = C->m) {
                        vd = vdd = 0.;
                        for (c = C->c + --j; j ; --j ) {
                                vd = w2.v * (tmp = vd) - vdd + *c--;
                                vdd = tmp;
                        }
                        d = w2.u * (tmp = d) - dd + w.v * vd - vdd + 0.5 * *c;
                } else
                        d = w2.u * (tmp = d) - dd;
                dd = tmp;
        }
        if (j = C->m) {
                vd = vdd = 0.;
                for (c = C->c + --j; j ; --j ) {
                        vd = w2.v * (tmp = vd) - vdd + *c--;
                        vdd = tmp;
                }
                return (w.u * d - dd + 0.5 * ( w.v * vd - vdd + 0.5 * *c ));
        } else
                return (w.u * d - dd);
}
        projUV /* bivariate Chebyshev polynomial entry point */
bcheval(projUV in, Tseries *T) {
        projUV w2, w;
        projUV out;
                /* scale to +-1 */
        w.u = ( in.u + in.u - T->a.u ) * T->b.u;
        w.v = ( in.v + in.v - T->a.v ) * T->b.v;
        if (fabs(w.u) > NEAR_ONE || fabs(w.v) > NEAR_ONE) {
                out.u = out.v = HUGE_VAL;
                pj_errno = -36;
        } else { /* double evaluation */
                w2.u = w.u + w.u;
                w2.v = w.v + w.v;
                out.u = ceval(T->cu, T->mu, w, w2);
                out.v = ceval(T->cv, T->mv, w, w2);
        }
        return out;
}
        projUV /* bivariate power polynomial entry point */
bpseval(projUV in, Tseries *T) {
        projUV out;
        double *c, row;
        int i, m;

        out.u = out.v = 0.;
        for (i = T->mu; i >= 0; --i) {
                row = 0.;
                if (m = T->cu[i](]="@(#)biveval.c).m) {
                        c = T->cu[+ m;
                        while (m--)
                                row = *--c + in.v * row;
                }
                out.u = row + in.u * out.u;
        }
        for (i = T->mv; i >= 0; --i) {
                row = 0.;
                if (m = T->cv[i](i].c).m) {
                        c = T->cv[i].c + m;
                        while (m--)
                                row = *--c + in.v * row;
                }
                out.v = row + in.u * out.v;
        }
        return out;
}

projUV /* general entry point selecting evaluation mode */
biveval(projUV in, Tseries *T) {

    if (T->power) {
        return bpseval(in, T);
    } else {
        return bcheval(in, T);
    }
}

Last Modified by warmerdam on 23 Jan 2009 14:53 UTC

Migrated-From: https://trac.osgeo.org/proj/ticket/24

./config.guess: No such file or directory

Reported by mloskot on 28 Mar 2009 01:01 UTC
I tried to build r1552 and it fails with error complaining that config.guess is missing. Here is the story:

mloskot@dog:~/dev/proj4/_svn/trunk$ svn co https://svn.osgeo.org/metacrs/proj/trunk/proj/ .
...
Checked out revision 1552.
mloskot@dog:~/dev/proj4/_svn/trunk$ ./configure 
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... no
checking for mawk... mawk
checking whether make sets $(MAKE)... yes
checking whether to enable maintainer-specific portions of Makefiles... no
checking for gcc... gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables... 
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking for style of include used by make... none
checking dependency style of gcc... none
checking for a BSD-compatible install... /usr/bin/install -c
checking whether ln -s works... yes
checking whether make sets $(MAKE)... (cached) yes
checking build system type... /bin/bash: ./config.guess: No such file or directory
configure: error: cannot guess build type; you must specify one
mloskot@dog:~/dev/proj4/_svn/trunk$ ls -l config.*
-rw-r--r-- 1 mloskot mloskot  8356 2009-03-28 00:57 config.log
-rwxr-xr-x 1 mloskot mloskot 32665 2009-03-28 00:56 config.sub

I tried it on both, old Fedora Core 4 (xblade14) and on my own laptop running Ubuntu 9.04 (Jaunty).

Migrated-From: https://trac.osgeo.org/proj/ticket/33

Support +title parameter

Reported by dgrichard on 13 Oct 2008 21:25 UTC
As PROJ4JS is moving, the use of +title parameter for having a name for the CRS could be supported in PROJ.4. This parameter holds a string with spaces (like in "Lambert II etendu").
Currently, the use of such parameter in command line like :

cs2cs -v +init=IGNF:RGF93G  +to +title="Lambert II etendu" +proj=lcc 
+nadgrids=ntf_r93.gsb,null +towgs84=-168.0000,-60.0000,320.0000 
+a=6378249.2000 +rf=293.4660210000000 +pm=2.337229167 
+lat_0=46.800000000 +lon_0=0.000000000 +k_0=0.99987742 
+lat_1=46.800000000 +x_0=600000.000 +y_0=2200000.000 +units=m +no_defs

works fine :

#--- following specified but NOT used
# +title=Lambert II etendu +towgs84=-168.0000,-60.0000,320.0000

Nevertheless, when a catalogue such as IGNF uses it, we may encounter problem if the string contain a keyword like in "Lambert II etendu proj".
The attached patch tries to fix this.

Migrated-From: https://trac.osgeo.org/proj/ticket/17

Man pages typos

Reported by frankie on 26 Nov 2008 17:03 UTC
There are a few typos to be fixed in proj man pages. Find attached a cumulative patch.

Migrated-From: https://trac.osgeo.org/proj/ticket/21

Dutch Coordinate System Not Working

Reported by lxnyce on 18 Jul 2008 14:59 UTC
Please see this bug for an overview : http://trac.osgeo.org/gdal/ticket/2487

We are contacting customer about getting the prj generated by ESRI. I'll repost the basic problem though. From a customer :

Just so we know what we are talking about: the Dutch coordinate system is Rijksdriehoeksstelsel. Luckily that is commonly abbreviated to RD.

Most of that is just parameters, and we can fill them out basically. But what is fundamentally lacking is the actual projection formula used in that coordinate system. Its the Double Stereographic projection, used worldwide only in NL and on Nova Scotia. It is different from the regular stereographic projection, one that is supported.

Please find enclosed two point shapefiles, depicting the same points. One is in RD, the other one is in geographic coordinates on the WGS84 datum. Please also find enclosed a PDF (published by the Dutch Cadastre, the owners of the coordinate system) describing the specs of the coordinate system (chapter 4.2.1 for latlong X, Y, and 4.2.2 for X, Y latlong)

Migrated-From: https://trac.osgeo.org/proj/ticket/7

EPSG code 3785 not translated in "epsg" file

Reported by neteler on 30 Jul 2008 09:53 UTC
From
http://www.sharpgis.net/post/2008/05/SphericalWeb-Mercator-EPSG-code-3785.aspx

and
http://www.epsg-registry.org/
I got information that EPSG registered the so-called

"Popular Visualisation CRS / Mercator" alias Google Projection as EPSG code 3785.

However, it results as broken in the 4.6.1 candidate:

# Unable to translate coordinate system EPSG:3785 into PROJ.4 format.

Any chance to get that fixed to avoid the EPSG:900913 pseudo-code?
Sharpgis suggests:

PROJCS[Visualisation CRS / Mercator", GEOGCS["Popular Visualisation CRS", DATUM["Popular Visualisation Datum", SPHEROID["Popular Visualisation Sphere", 6378137, 0, AUTHORITY["EPSG",7059]("Popular)], TOWGS84[0, 0, 0, 0, 0, 0](0,), AUTHORITY[PRIMEM["Greenwich", 0, AUTHORITY["EPSG", "8901"]("EPSG",6055]],)], UNIT[0.0174532925199433, AUTHORITY["EPSG", "9102"]("degree",)], AXIS[EAST]("E",), AXIS[NORTH]("N",), AUTHORITY[PROJECTION["Mercator"]("EPSG",4055]],), PARAMETER[0]("False_Easting",), PARAMETER[0]("False_Northing",), PARAMETER[0]("Central_Meridian",), PARAMETER[0]("Latitude_of_origin",), UNIT[1, AUTHORITY["EPSG", "9001"]("metre",)], AXIS[EAST]("East",), AXIS[NORTH]("North",), AUTHORITY["EPSG",3785]]

which doesn't look too strange to me (I'll be overlooking something).

Thanks,
Markus

Migrated-From: https://trac.osgeo.org/proj/ticket/9

Reset LC_NUMERIC in pj_init()

Reported by grisxa on 4 Sep 2009 01:17 UTC
As pj_init() calls pj_datum_set() that in turn calls locale-dependent atof() to convert, say, +towgs84 datum parameters, I suggest to reset LC_NUMERIC to "C" in beginning of pj_init() and get back on exit (see patch).
There is some more atof() in source tree, so maybe another steps should be taken to make proj.4 really locale-independent. See also http://trac.osgeo.org/proj/wiki/FAQ#DoesPROJ.4workindifferentinternationalnumericlocales

Migrated-From: https://trac.osgeo.org/proj/ticket/49

a patch for proj4 pkg-config support

Reported by 183 on 26 May 2008 08:58 UTC
Hello,
this is a small patch that could be useful to use pkg-config facility.

--- configure.in.orig   2008-05-16 18:42:04.000000000 +0200
+++ configure.in    2008-05-16 18:43:00.000000000 +0200
@@ -80,3 +80,4 @@
 AC_OUTPUT(Makefile src/Makefile man/Makefile man/man1/Makefile \
    man/man3/Makefile nad/Makefile \
    jniwrap/Makefile jniwrap/org/Makefile jniwrap/org/proj4/Makefile)
+AC_OUTPUT(proj.pc)
--- Makefile.am.orig    2008-05-16 18:57:12.000000000 +0200
+++ Makefile.am 2008-05-16 18:57:24.000000000 +0200
@@ -1,6 +1,3 @@
 SUBDIRS    =   src man nad jniwrap

-pkgconfigdir = $(libdir)/pkgconfig
-pkgconfig_DATA = proj.pc
-
 AUTOMAKE_OPTIONS = dist-zip
--- /dev/null   2008-05-05 11:09:07.000000000 +0200
+++ proj.pc.in  2008-05-16 18:51:33.000000000 +0200
@@ -0,0 +1,11 @@
+prefix=@prefix@
+exec_prefix=@exec_prefix@
+libdir=@libdir@
+includedir=@includedir@
+
+Name: proj
+Description: Cartographic Projections Library.
+Requires: 
+Version: @VERSION@
+Libs: -L${libdir} -lproj
+Cflags: -I${includedir}

Last Modified by warmerdam on 21 Aug 2008 19:55 UTC

Migrated-From: https://trac.osgeo.org/proj/ticket/3

bug in inverse in pj_sts.c

Reported by barendgehrels on 17 May 2009 21:31 UTC
The inverse projection in file PJ_sts.c gives wrong results.

Line 34, lp.phi /= P->C_p; should be erased because is duplicated in line 35.
This is already solved in libproj4

Migrated-From: https://trac.osgeo.org/proj/ticket/40

Unclear behaviour of param +nadgrid= vs. +nadgrids=

Reported by lczub on 7 Jul 2009 20:54 UTC
I find following not clear behaviour of cs2cs during a typing error.

I was surprised, that the declaration with the wrong parameter '+nadgrid=' has another effect as the declaration of the correct parameter '+nadgrids=' with a non existing NTv2 file (see test b+c vs d).

My expectation was, that test b+c+d should use the same default datum shift parameter, but this is not the case.

A description for '+nadgrid=' could not be found in ProjAPI. What is the impact of this parameter?

=== Test A: declaring existing ntv2 file with correct param +nadgrids ===
Expectation: 399340.601863 5928794.177992 -> ok

C:\>cs2cs +init=epsg:31466 +nadgrids=BETA2007.gsb +to +init=epsg:25
832 +towgs84=0.0,0.0,0.0
2598417.333192 5930677.980308
399340.60       5928794.18 0.00  
^C

=== Test B: declaring existing ntv2 file with typing error param +nadgrid ===
Expectation: great delta to Test A, cause wrong param nadgrid should be interpreted as missing datum shift -> why is the delta so small?

C:\>cs2cs +init=epsg:31466 +nadgrid=BETA2007.gsb +to +init=epsg:258
32 +towgs84=0.0,0.0,0.0
2598417.333192 5930677.980308
399339.28       5928789.39 -5.76 
^C

=== Test C: declaring non existing ntv2 file with typing error param +nadgrid ===
Expectation: great delta to test A, cause wrong param nadgrid should be interpreted as missing datum shift -> why is the delta so small?

C:\>cs2cs +init=epsg:31466 +nadgrid=nofile.gsb +to +init=epsg:25832
 +towgs84=0.0,0.0,0.0
2598417.333192 5930677.980308
399339.28       5928789.39 -5.76 
^C

=== Test D: declaring non existing ntv2 file with correct param +nadgrids ===
Expectation: great delta to test A, cause missing ntv2 file should be interpreted as missing datum shift -> ok

C:\>cs2cs +init=epsg:31466 +nadgrids=nofile.gsb +to +init=epsg:2583
2 +towgs84=0.0,0.0,0.0
2598417.333192 5930677.980308
399399.12       5928964.19 0.00 

Migrated-From: https://trac.osgeo.org/proj/ticket/46

WGS 84 Mercator (epsg:54004) missing from epsg list

Reported by runeaa on 23 Jan 2009 09:42 UTC
I suggest adding the following line to the epsg list:

# WGS84 / Normal Mercator
<54004> +proj=merc +lat_ts=0 +lon_0=0 +k=1.000000 +x_0=0 +y_0=0 +ellps=WGS84 +datum=WGS84 +units=m no_defs <>

Last Modified by warmerdam on 23 Jan 2009 14:09 UTC

Migrated-From: https://trac.osgeo.org/proj/ticket/25

LCC projection not thread safe

Reported by artwisz on 22 May 2009 11:44 UTC
The lcc projection is currently not thread safe. The rho parameter should be removed from PJ and declared on the stack in the projection functions.
File: PJ_lcc.c

Migrated-From: https://trac.osgeo.org/proj/ticket/41

Errors in Proj.4 documentation on the Wiki

Reported by jcrepetto on 15 Apr 2009 12:03 UTC
It seems that the pj_transform has a new parameter (point_offset), but :

• the example on the page http://trac.osgeo.org/proj/wiki/ProjAPI has not been updated :
  test.cpp:17: erreur: invalid conversion from double* to int
  /usr/include/proj_api.h:125: erreur: too few arguments to function int pj_transform(void_, void_, long int, int, double_, double_, double*)
• the point_offset parameter is not documented on the page http://trac.osgeo.org/proj/wiki/pj_transform

Migrated-From: https://trac.osgeo.org/proj/ticket/35

Add EPSG 3410 PROJ.4 string to share/proj/epsg

Reported by billinb on 17 Nov 2008 14:39 UTC
in the "share/proj/epsg" file in FWTools, for the entry for 3410, it says:

NSIDC EASE-Grid Global

Unable to translate coordinate system EPSG:3410 into PROJ.4 format.

However we have been successfully using the PROJ.4 string
+proj=cea +lat_0=0 +lon_0=0 +lat_ts=30 +x_0=0 +y_0=0 +a=6371228 +b=6371228
+units=m +no_defs

to work with this projection with gdal utilities. Can this projection
definition be added to the file?

Thanks,
Brendan

Migrated-From: https://trac.osgeo.org/proj/ticket/20

imp_w projection error

Reported by barendgehrels on 13 May 2009 13:05 UTC
Compiler says:

imw_p.hpp 91: warning: 'yc' is used uninitialized in this function

Compiler is right, loc_for takes a pointer to yc BUT declares yc locally and never assigns its value.
It is then used unitialized in the inverse function.

Migrated-From: https://trac.osgeo.org/proj/ticket/39

Contribution: proj.dox and Doxyfile

Reported by neteler on 29 Jan 2009 11:16 UTC
To easier navigate in the PROJ4 code using doxygen, I have created the required proj.dox and Doxyfile files for upload in SVN (see attachment).

Markus

Migrated-From: https://trac.osgeo.org/proj/ticket/26

incorrect convergence calculation for lcc projection.

Reported by keesk on 22 Sep 2008 08:36 UTC

Convergence calculation for lcc seems to have an incorrect sign. The convention for convergence is:

  meridian convergence = bearing of grid north (measured clockwise from true north)

  so: true bearing = grid bearing + convergence

To demonstrate this i modified proj.exe so it prints the convergence (in
deg) at the end of the line when using the -S flag:

C:\proj-4.6.1\src>proj -vS +proj=lcc +datum=WGS84 +lat_0=52 +lon_0=3
+lat_1=50 +lat_2=54
#Lambert Conformal Conic
# Conic, Sph&Ell
# lat_1= and lat_2= or lat_0
# +proj=lcc +datum=WGS84 +lat_0=52 +lon_0=3 +lat_1=50 +lat_2=54 +ellps=WGS84
# +towgs84=0,0,0
2 52
-68634.11 472.08 <0.999392 0.999392 0.998785 0.000355057 0.999395
0.999389 0.788173>
4 52
68634.11 472.08 <0.999392 0.999392 0.998785 0.000355708 0.999395
0.999389 -0.788173>
4 52.1
68481.15 11591.10 <0.999393 0.999393 0.998787 0.000434814
0.999397 0.99939 -0.788173>

When i calculate two positions along a longitude east of the origin (point E4N52 and point E4N52.1) the easting reduces when going northwards. According te the convention the convergence should be positive and not negative.

Testing with a UTM projection gives the expected results:

C:\proj-4.6.1\src>proj -vS +proj=utm +datum=WGS84 +lon_0=3
#Universal Transverse Mercator (UTM)
# Cyl, Sph
# zone= south
# +proj=utm +datum=WGS84 +lon_0=3 +ellps=WGS84 +towgs84=0,0,0
2 52
431350.30 5761510.32 <0.999658 0.999658 0.999316 1.20783e-006
0.999658 0.999658 -0.788041>
4 52
568649.70 5761510.32 <0.999658 0.999658 0.999316 8.54066e-007
0.999658 0.999658 0.788041>
4 52.1
568496.62 5772632.28 <0.999658 0.999658 0.999315 0 0.999658
0.999658 0.789115>

From the above results it seems that for utm the convergence is
negative when west and positive when east of lon_0.
If you calculate two utm positions along the same longitude east of
lon_0, you see that the easting reduces when going northwards.

From this is seems that TrueNorth = GridNorth + convergence which complies with the convention.

Regards,

Kees Krikke

Last Modified by warmerdam on 22 Sep 2008 14:54 UTC

Migrated-From: https://trac.osgeo.org/proj/ticket/16

Silent @null gridshift failure for points outside -180º/+180º

Reported by rcoup on 3 Jun 2009 02:15 UTC
Following on from http://trac.osgeo.org/gdal/ticket/2994

Test case is attached against trunk r1583.

Basic problem:

• transform: (165.9134918212895400 -47.7347488403320312, 165.9134918212895400 -34.2310752868652344, 184.6205993652343977 -34.2310752868652344, 184.6205993652343977 -47.7347488403320312, 165.9134918212895400 -47.7347488403320312)
• from: +proj=longlat +ellps=WGS84 +datum=WGS84 +no_defs
• to: +proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0 +x_0=0.0 +y_0=0 +k=1.0 +units=m +nadgrids=@null +no_defs
• end up with points[- points[4](0].x).x == -3.7252902984619141e-09 != 0.0 (which then results in a not-closed polygon)

What i've dug up:

• The @null gridshift isn't quite null:
  (2.8957367057621863 + 3.1415926535897931 - 3.1415926535897931) - 2.8957367057621863 == -4.4408920985006262e-16 != 0 nad_cvt.c:13 & nad_cvt.c:57
• The @null gridshift fails for points outside +180/-180 longitude.
• Then the failure is treated as a transient error (pj_transform.c:638) and returns a success code, so 1/2 the points are gridshifted (ie. slightly-not-0 change) and 1/2 are not (ie. 0 change).

Questions:

• Is the @null gridshift meant to fail for points outside +180/-180? nad_cvt() seems to normalise values back into a 2PI range anyway, so maybe it can be ignored?
• Should the gridshift failure be silently dropped?
• This particular case only happens to fail using Proj's DEG_TO_RAD (0.0174532925199432958) which is different from OGC's (0.0174532923199433) which GDAL uses... just to make it more fun.
• As an aside (for nad_cvt()'s normalising), in adjlon(), ONEPI * 2.0 != TWOPI...

Migrated-From: https://trac.osgeo.org/proj/ticket/45

PROJ.4 Trac improvements

Reported by mloskot on 16 May 2008 12:29 UTC
By the way of checking I can authenticate, I wanted to suggest a few improvements:

• include PROJ.4 Trac link in the list at http://trac.osgeo.org/
• add svn-trunk or CVS HEAD to Version drop-down box

Migrated-From: https://trac.osgeo.org/proj/ticket/2

README for windows build outdated

Reported by behrisch on 23 Mar 2009 13:35 UTC
The readme does not describe the windows build correctly. Diff is attached.

Migrated-From: https://trac.osgeo.org/proj/ticket/30

make check has errors (proj-4.6.1)

Reported by rstarr on 9 Mar 2009 05:37 UTC
OS: RH Enterprise 4.7 2.6.9-78.0.13.ELsmp x86_64 x86_64 x86_64 GNU/Linux
gcc (GCC) 3.4.6 20060404

Compile is clean, then I run

make check

and this is what I get:

============================================
Running ./testvarious using ../src/cs2cs:
============================================
doing tests into file td_out, please wait
diff td_out with td_out.dist
3,4c3,4
< 111d00'00.000"W 44d00'00.000"N 0.0    111dW   44dN 0.000
< 111d00'00.000"W 39d00'00.000"N 0.0    111dW   39dN 0.000

---
> 111d00'00.000"W 44d00'00.000"N 0.0    111d0'3.085"W   43d59'59.756"N 0.000
> 111d00'00.000"W 39d00'00.000"N 0.0    111d0'2.604"W   38d59'59.912"N 0.000
7,8c7,8
< 111d00'00.000"W 44d00'00.000"N 0.0    111dW   44dN 0.000
< 111d00'00.000"W 39d00'00.000"N 0.0    111dW   39dN 0.000

---
> 111d00'00.000"W 44d00'00.000"N 0.0    111d0'2.788"W   43d59'59.725"N 0.000
> 111d00'00.000"W 39d00'00.000"N 0.0    111d0'2.604"W   38d59'59.912"N 0.000
11,14c11,14
< 79d58'00.000"W 37d02'00.000"N 0.0     79d58'W 37d2'N 0.000
< 79d58'00.000"W 36d58'00.000"N 0.0     79d58'W 36d58'N 0.000
< 79d58'00.000"W 37d02'00.000"N 0.0     79d58'W 37d2'N 0.000
< 79d58'00.000"W 36d58'00.000"N 0.0     79d58'W 36d58'N 0.000

---
> 79d58'00.000"W 37d02'00.000"N 0.0     79d58'0.005"W   37d1'59.998"N 0.000
> 79d58'00.000"W 36d58'00.000"N 0.0     79d57'59.128"W  36d58'0.501"N 0.000
> 79d58'00.000"W 37d02'00.000"N 0.0     79d57'59.126"W  37d2'0.501"N 0.000
> 79d58'00.000"W 36d58'00.000"N 0.0     79d57'59.128"W  36d58'0.501"N 0.000

PROBLEMS HAVE OCCURED
test file td_out saved


And here is td_out:
% cat ./nad/td_out
##############################################################
1st through ntv1, 2nd through conus
111d00'00.000"W 44d00'00.000"N 0.0      111dW   44dN 0.000
111d00'00.000"W 39d00'00.000"N 0.0      111dW   39dN 0.000
##############################################################
As above, but without ntv1 everything goes through conus file.
111d00'00.000"W 44d00'00.000"N 0.0      111dW   44dN 0.000
111d00'00.000"W 39d00'00.000"N 0.0      111dW   39dN 0.000
##############################################################
Test MD used where available
79d58'00.000"W 37d02'00.000"N 0.0       79d58'W 37d2'N 0.000
79d58'00.000"W 36d58'00.000"N 0.0       79d58'W 36d58'N 0.000
79d58'00.000"W 37d02'00.000"N 0.0       79d58'W 37d2'N 0.000
79d58'00.000"W 36d58'00.000"N 0.0       79d58'W 36d58'N 0.000
##############################################################
Test raw ellipse to raw ellipse
79d58'00.000"W 37d02'00.000"N 0.0       79d58'W 37d2'N 0.000
79d58'00.000"W 36d58'00.000"N 0.0       79d58'W 36d58'N 0.000
##############################################################
Test NAD27 to raw ellipse
79d00'00.000"W 35d00'00.000"N 0.0       79dW    35dN 0.000
##############################################################
Between two 3parameter approximations on same ellipsoid
0d00'00.000"W 0d00'00.000"N 0.0 0dE     0dN 4.000
79d00'00.000"W 45d00'00.000"N 0.0       78d59'59.821"W  44d59'59.983"N 0.540
##############################################################
3param to raw ellipsoid on same ellipsoid
0d00'00.000"W 0d00'00.000"N 0.0 0dE     0dN 0.000
79d00'00.000"W 45d00'00.000"N 0.0       79dW    45dN 0.000
##############################################################
Test simple prime meridian handling.
0d00'00.000"W 0d00'00.000"N 0.0 1dW     0dN 0.000
79d00'00.000"W 45d00'00.000"N 0.0       80dW    45dN 0.000
##############################################################
Test simple prime meridian handling within a projection.
500000 3000000  113dW   27d7'20.891"N 0.000
##############################################################
Test geocentric x/y/z generation.
0d00'00.000"W 0d00'00.000"N 0.0 6378137.00      -0.00 0.00
0d00'00.000"W 0d00'00.000"N 10.0        6378147.00      -0.00 0.00
79d00'00.000"W 45d00'00.000"N 0.0       861996.98       -4434590.01 4487348.41
0d00'00.000"W 90d00'00.000"N 0.0        0.00    -0.00 6356752.31
##############################################################
Test geocentric x/y/z consumption.
6378137.00      -0.00 0.00      0dE     0dN 0.000
6378147.00      -0.00 0.00      0dE     0dN 10.000
861996.98       -4434590.01 4487348.41  79dW    45dN 0.001
0.00    -0.00 6356752.31        0dE     90dN -0.004
##############################################################
Test stere projection (re: win32 ticket 12)
105 40  5577808.93      1494569.40 0.00

Last Modified by warmerdam on 4 Apr 2009 14:51 UTC

Migrated-From: https://trac.osgeo.org/proj/ticket/28

Synder vs. Snyder

Reported by peifer on 11 Mar 2009 18:08 UTC
From the cs2cs man page:

Map ProjectionsA Working Manual (Synder, 1988,...

It should obviously read Snyder.

Migrated-From: https://trac.osgeo.org/proj/ticket/29

nmake install-all fails due to missing data file

Reported by behrisch on 23 Mar 2009 13:44 UTC
If I issue:

D:\behrisch\libs\proj-4.6.1>nmake /f makefile.vc install

I get

D:\behrisch\libs\proj-4.6.1\nad>copy ntf_r93.gsb D:\behrisch\libs\proj\data
Das System kann die angegebene Datei nicht finden.
NMAKE : fatal error U1077: "for": Rckgabe-Code "0x1"
Stop.
NMAKE : fatal error U1077: ""C:\Programme\Microsoft Visual Studio 8\VC\BIN\nmake
.EXE"": Rckgabe-Code "0x2"
Stop.

NMAKE is right, the file is not there.

Migrated-From: https://trac.osgeo.org/proj/ticket/31

Is False Easting is always automatically applied?

Reported by jaruna on 22 May 2009 15:11 UTC
Hi,

I was reading the OF90-284.pdf and came across the line "In all cases, a false easting of 500,000m is used" for UTM. Just want to reconfirm what this means is whether I ask for it or not by setting params, a false easting will ALWAYS be applied for utm and the result be returned.

Also if a Flse Easting is 500,000m, then what is the origin ( 500000,0 ) or ( -500000, 0 ). I understand it to be the earlier, but I came across a code which is latter and that completely confuses me.

Migrated-From: https://trac.osgeo.org/proj/ticket/42

lack of support for South African projections

Reported by gfleming on 17 Oct 2008 08:59 UTC
South African Coordinate System zone xx (EPSG odd numbers from 22275 - 22293)

and

Hartebeesthoek94/ Loxx (EPSG 2046 - 2055)

are not supported / do not have standard definitions in proj4. South Africa users of proj4, QGIS, PostGIS and others are thus crippled.

Attached are the WKT and PROJ4 definitions as csvs from PostGIS spatial_ref_sys.

SA Hartebeesthoek datum.csv:

4148 is fine - that's the fundamental GEOGCS. The rest have default, invalid proj4 definitions, except for 2054 (the last one) where I have attempted a proj4 definition but I dont think its quite right - it doesn't work.

SA Cape datum.csv:

The proj4 definitions for the SA Cape datum projections are INCOMPLETE. They only include the datum specs, not the projection or central meridian or other parameters.

Apparently the problem is that proj4 does not support 'transverse_mercator_south_orientated'?

Migrated-From: https://trac.osgeo.org/proj/ticket/18

Provide functions used in geod in the library instead

Reported by jluebbe on 3 Apr 2009 15:35 UTC
It would be nice to be able to use the functions for geodesic calculations (implemented in geod) by linking against libproj.

The python proj bindings (http://code.google.com/p/pyproj) currently includes a copy of the complete proj sources. I've modified it to link agains libproj, but it still needs emess.c, emess.h, geod.c, geodesic.h, geod_for.c, geod_inv.c and geod_set.c.

Migrated-From: https://trac.osgeo.org/proj/ticket/34

Confusion over Gauss Laborde projection

Reported by warmerdam on 23 Jul 2008 04:01 UTC
Before releasing PROJ 4.6.1 I'd like to ensure that the implementation and naming of the Gauss Laborde Sphere Geometric Mean (glabsgm) projection is brought into line between PROJ.4 and libproj4.

In response to:

o Added the glabsgm (Gauss Laborde / Sphere Geometric Mean) projection

Gerald writes:

Excuse me for forgetfulness. This is really the Gauss-Schreiber projection
that we went over a few months ago. Aka +proj=stmerc

Migrated-From: https://trac.osgeo.org/proj/ticket/8

Can you please check for EPSG:3787 and EPSG:3794 implementation

Reported by ssddgreg on 6 Mar 2009 08:05 UTC
Can you please check for EPSG:3787 and EPSG:3794 implementation for the Slovenian WMS and WFS users?

Thanks!

Best regards,
Dejan

Migrated-From: https://trac.osgeo.org/proj/ticket/27

gdalinfo does not redirect lat long in windows bat file

Reported by Himaunshu on 16 Sep 2008 15:28 UTC
Hi,

I am creating a batchfile(e.g. fwtools.bat) with the gdalinfo command to redirect to a file. The problem is that if the longitude is less than 100 degrees, only the utm coordinates are output for the corner coordinates.

Migrated-From: https://trac.osgeo.org/proj/ticket/13

make check returns problem

Reported by rfk46 on 6 Jan 2009 11:23 UTC
Hello,

Trying to install on a MacPro OS 10.5
make check fails with problems on test83.
./configure finishes without error
make seems ok except some missing symbols:
ranlib: file: .libs/libproj.a(jniproj.o) has no symbols

Is this build usable?
Thanks
Rich
[email protected]

[make check
Making check in src
Making check in man
Making check in man1
make[2](magmox:proj-4.6.1]$): Nothing to be done for `check'.
Making check in man3
make[Nothing to be done for `check'.
make[2](2]:): Nothing to be done for `check-am'.
Making check in nad
make  check-local
./test27 ../src/proj
============================================
Running ./test27 using ../src/proj:
============================================
doing tests into file proj_out27, please wait
diff proj_out27 with pj_out27.dist
TEST OK
test file proj_out27 removed

./test83 ../src/proj
============================================
Running ./test83 using ../src/proj:
============================================
doing tests into file proj_out83, please wait
diff proj_out83 with pj_out83.dist
TEST OK
test file proj_out83 removed

./testvarious ../src/cs2cs
============================================
Running ./testvarious using ../src/cs2cs:
============================================
doing tests into file td_out, please wait
diff td_out with td_out.dist
3,4c3,4
< 111d00'00.000"W 44d00'00.000"N 0.0    111dW   44dN 0.000
< 111d00'00.000"W 39d00'00.000"N 0.0    111dW   39dN 0.000

---
> 111d00'00.000"W 44d00'00.000"N 0.0    111d0'3.085"W   43d59'59.756"N 0.000
> 111d00'00.000"W 39d00'00.000"N 0.0    111d0'2.604"W   38d59'59.912"N 0.000
7,8c7,8
< 111d00'00.000"W 44d00'00.000"N 0.0    111dW   44dN 0.000
< 111d00'00.000"W 39d00'00.000"N 0.0    111dW   39dN 0.000

---
> 111d00'00.000"W 44d00'00.000"N 0.0    111d0'2.788"W   43d59'59.725"N 0.000
> 111d00'00.000"W 39d00'00.000"N 0.0    111d0'2.604"W   38d59'59.912"N 0.000
11,14c11,14
< 79d58'00.000"W 37d02'00.000"N 0.0     79d58'W 37d2'N 0.000
< 79d58'00.000"W 36d58'00.000"N 0.0     79d58'W 36d58'N 0.000
< 79d58'00.000"W 37d02'00.000"N 0.0     79d58'W 37d2'N 0.000
< 79d58'00.000"W 36d58'00.000"N 0.0     79d58'W 36d58'N 0.000

---
> 79d58'00.000"W 37d02'00.000"N 0.0     79d58'0.005"W   37d1'59.998"N 0.000
> 79d58'00.000"W 36d58'00.000"N 0.0     79d57'59.128"W  36d58'0.501"N 0.000
> 79d58'00.000"W 37d02'00.000"N 0.0     79d57'59.126"W  37d2'0.501"N 0.000
> 79d58'00.000"W 36d58'00.000"N 0.0     79d57'59.128"W  36d58'0.501"N 0.000

PROBLEMS HAVE OCCURED
test file td_out saved

make[*** [check-local](2]:) Error 100
make[*** [check-am](1]:) Error 2
make: *** [check-recursive] Error 1

Last Modified by warmerdam on 6 Jan 2009 15:45 UTC

Migrated-From: https://trac.osgeo.org/proj/ticket/23