osgeo / proj Goto Github PK
View Code? Open in Web Editor NEWPROJ - Cartographic Projections and Coordinate Transformations Library
Home Page: https://proj.org
License: Other
PROJ - Cartographic Projections and Coordinate Transformations Library
Home Page: https://proj.org
License: Other
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
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
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
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
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
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
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:
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
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
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
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
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
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
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:
Migrated-From: https://trac.osgeo.org/proj/ticket/2
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
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
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:
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
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
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
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
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
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
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
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
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
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
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
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
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
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
Reported by yangyong on 27 May 2009 06:30 UTC
I tested out that 2 problems exists:
<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 <>
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
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
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
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
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
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
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
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
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
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
Reported by jcrepetto on 15 Apr 2009 12:03 UTC
It seems that the pj_transform has a new parameter (point_offset), but :
Migrated-From: https://trac.osgeo.org/proj/ticket/35
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
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
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
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
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:
(165.9134918212895400 -47.7347488403320312, 165.9134918212895400 -34.2310752868652344, 184.6205993652343977 -34.2310752868652344, 184.6205993652343977 -47.7347488403320312, 165.9134918212895400 -47.7347488403320312)
+proj=longlat +ellps=WGS84 +datum=WGS84 +no_defs
+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
points[- points[4](0].x).x == -3.7252902984619141e-09 != 0.0
(which then results in a not-closed polygon)What i've dug up:
@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
@null
gridshift fails for points outside +180/-180 longitude.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:
@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?DEG_TO_RAD
(0.0174532925199432958
) which is different from OGC's (0.0174532923199433
) which GDAL uses... just to make it more fun.nad_cvt()
's normalising), in adjlon()
, ONEPI * 2.0 != TWOPI
...Migrated-From: https://trac.osgeo.org/proj/ticket/45
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
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
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
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
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
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
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
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
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
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.