Andrew Williams | 1 Feb 05:32 2006
Picon

Azimuthal Equidistant projection Northern Hemisphere centric

Hi folks,
I'm using GDAL to try and warp an AEQD projected image to Latlong. 

This is the syntax
gdalwarp -s_srs "+proj=aeqd +lat_0=0 +long_0=134 +x_0=0 +y_0=0" -t_srs "+proj=latlong +datum=WGS84"
input.tif output.tif

The issue is that the image is a Southern hemisphere Equatorial projection of Australia. The image is
warping, but instead of "spreading" the Southern part of the image so that line of longitude no longer
converge, it's spreading the Northern part of the image and making it worse.

It looks like the warp calculation is assuming a Northern aspect where the lines of longitude converge at
the top of the image rather than the bottom of the image in a Southern aspect.

The reason for my enquiry here is to find out if I can (or need to) add some other parameter to the source
definition to make GDAL sensitive to the fact that it's a Southern Hemisphere rather than Northern
hemisphere projection.

regards
Andrew

_______________________________________________
Proj mailing list
Proj <at> lists.maptools.org
http://lists.maptools.org/mailman/listinfo/proj

Steffen Macke | 1 Feb 06:56 2006
Picon

Re: Roussilhe Projection

Hello All,

I tried to move the Roussilhe projection from

http://members.verizon.net/~vze2hc4d/proj4/lbp4-3_060124R.tar.gz

to proj.4.4.9. I attached a patch with the changes I did to make things compile.
However, while Gerald Evenden's package works fine, my patched proj does not
work.
E.g.

echo 36.176039 31.203685 0 | ./proj +to +proj=rouss +ellps=clrk80 
+rf=293.46 +a=6378249.2 +lon_0="39d09'E" +lat_0="34d12'N"
+k_0=0.9995341

gives

-1.#J   -1.#J 0

Did I miss anything?

Regards,

Steffen
Attachment (rouss4proj4.diff): application/octet-stream, 1833 bytes
_______________________________________________
Proj mailing list
Proj <at> lists.maptools.org
(Continue reading)

ErichS | 1 Feb 08:00 2006
Picon
Picon

System 42/83 (S42/83)

Hello all,

I'm trying to use coordinates in S42/83, a system often used in eastern Europe
(e.g. Russia) and partially in East-Germany ("Deutsches Heeresgitter").

It's similar to Gauss-Kruger (Gauß-Krüger) (i.e a transverse mercator
projection) but it uses 6 degrees wide stripes instead of 3 degrees.

And its first meridian is at 3E.

Is there a possibility to define these parameters in cs2cs/proj4?

As ellipsoid "Krassovski" is used (+ellps=krass).

Many greetings
Erich

_______________________________________________
Proj mailing list
Proj <at> lists.maptools.org
http://lists.maptools.org/mailman/listinfo/proj

Michael P Finn | 1 Feb 11:01 2006
Picon

Michael P Finn of the USGS/ National Geospatial Technical Operations Center is out of the office.


I will be out of the office starting  02/01/2006 and will not return until
02/07/2006.

I will be unable to check e-mail regularly while I am out. If I can't
respond to your message while I am out, then I will when I return. If you
have anything that cannot wait, please contact my colleague, Mr. Michael
Williams, at mswilliams <at> usgs.gov.     Mike

_______________________________________________
Proj mailing list
Proj <at> lists.maptools.org
http://lists.maptools.org/mailman/listinfo/proj

Clifford J Mugnier | 1 Feb 14:32 2006

Re: System 42/83 (S42/83)


The DHG has its origin in WWII and was developed by the Germans,
specifically by Dr. Gigas.  It is identical to the UTM with only one
exception:  Scale Factor at Origin is 1.0 and NOT 0.9996 - there is no
other difference (other than the standard ellipsoid for System 42 Datum.
Furthermore, it is the identical system that is termed "Russia Belts."  The
math model is the Gauss-Kruger.

Clifford J. Mugnier
Chief of Geodesy and
Associate Director,
CENTER FOR GEOINFORMATICS
Department of Civil Engineering
CEBA 3223A
LOUISIANA STATE UNIVERSITY
Baton Rouge, LA  70803
Voice and Facsimile:  (225) 578-8536 [Academic]
Voice and Facsimile:  (225) 578-4474 [Research]
======================================================
http://www.asprs.org/resources/GRIDS/
http://www.cee.lsu.edu/facultyStaff/mugnier/index.html
======================================================

Hello all,

I'm trying to use coordinates in S42/83, a system often used in eastern
Europe
(e.g. Russia) and partially in East-Germany ("Deutsches Heeresgitter").

It's similar to Gauss-Kruger (Gauß-Krüger) (i.e a transverse mercator
(Continue reading)

Andrew Williams | 1 Feb 23:39 2006
Picon

Repost into Feb Archive Azimuthal Equidistant projection Northern Hemisphere centric

Hi folks,

	I'm using GDAL to try and warp an AEQD projected image to Latlong. 
	 
	This is the syntax
	gdalwarp -s_srs "+proj=aeqd +lat_0=0 +long_0=134 +x_0=0 +y_0=0" -t_srs "+proj=latlong
+datum=WGS84" input.tif output.tif
	 
	The issue is that the image is a Southern hemisphere Equatorial projection of Australia. The image is
warping, but instead of "spreading" the Southern part of the image so that line of longitude no longer
converge, it's spreading the Northern part of the image and making it worse.
	 
	It looks like the warp calculation is assuming a Northern aspect where the lines of longitude converge at
the top of the image rather than the bottom of the image in a Southern aspect.
	 
	The reason for my enquiry here is to find out if I can (or need to) add some other parameter to the source
definition to make GDAL sensitive to the fact that it's a Southern Hemisphere rather than Northern
hemisphere projection.
	 
	regards
	Andrew

_______________________________________________
Proj mailing list
Proj <at> lists.maptools.org
http://lists.maptools.org/mailman/listinfo/proj

Oscar van Vlijmen | 2 Feb 01:11 2006
Picon

Re: System 42/83 (S42/83)

> I'm trying to use coordinates in S42/83, a system often used in eastern Europe
> (e.g. Russia) and partially in East-Germany ("Deutsches Heeresgitter").

> Is there a possibility to define these parameters in cs2cs/proj4?

One might want to give the ESRI IDs 28402 ... 28492 a try.
Inspect the PROJ - esri file.
For instance:
# Pulkovo 1942 / Gauss-Kruger zone 2
<28402> +proj=tmerc +lat_0=0 +lon_0=9 +k=1.000000 +x_0=2500000 +y_0=0
+ellps=krass +units=m 

_______________________________________________
Proj mailing list
Proj <at> lists.maptools.org
http://lists.maptools.org/mailman/listinfo/proj

Erich Sadlowski | 2 Feb 10:32 2006
Picon
Picon

Re: System 42/83 (S42/83)

Thanks to you, Clifford J. and you, Oscar!

Now I understand the way of proj4's thinking and the calculation of transverse
mercator much better:

The stripe's wide affects only the x_0 value, not the conversion itself.
Therefore it's the same math model for UTM, Gauss-Kruger, DHG, etc.

cs2cs doesn't calculates the stripe (zone), you have to deliver it as parameter
lon_0 - while I was thinking, lon_0 would indicate the starting meridian of UTM
(-177), GK (0), DHG (3) and therefore should be left fixed.

Now I have to re-design my application a bit, but that's o.k.

Again: Thanks a lot!

Greetings
   Erich

P.S. Isn't it confusing, that there are identical definition (i.e. 2166 <-> 2397
) or incomplete zone enumerations in the delivered epsg file ?

_______________________________________________
Proj mailing list
Proj <at> lists.maptools.org
http://lists.maptools.org/mailman/listinfo/proj

Frank Warmerdam | 2 Feb 16:01 2006
Picon

Re: Re: System 42/83 (S42/83)

On 2/2/06, Erich Sadlowski <erich.sadlowski <at> gmx.de> wrote:
> P.S. Isn't it confusing, that there are identical definition (i.e. 2166 <-> 2397
> ) or incomplete zone enumerations in the delivered epsg file ?

Erich,

The "epsg file" is a rather pale reflection of the original
EPSG database.  I think if you went back and inspected
2166 and 2397 carefully in the original database there
would turn out to be differences that are not reflected
in the epsg file.  It may be that one is deprecated and
the other has different datum information, for instance.

But yes, it is confusing.

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

_______________________________________________
Proj mailing list
Proj <at> lists.maptools.org
http://lists.maptools.org/mailman/listinfo/proj

Stephan Holl | 3 Feb 09:10 2006
X-Face
Picon

Compile-error on Solaris2.6 (SPARC)

Dear proj-gurus,

I could not succeed in compiling PROJ on a Solaris2.6. The error is
given below:

<error>
.libs/vector1.o .libs/pj_release.o .libs/pj_gauss.o .libs/nad_cvt.o .libs/nad_init.o
.libs/nad_intr.o .libs/emess.o .libs/pj_apply_gridshift.o .libs/pj_datums.o
.libs/pj_datum_set.o .libs/pj_transform.o .libs/geocent.o .libs/pj_utils.o
.libs/pj_gridinfo.o .libs/pj_gridlist.o .libs/jniproj.o
-lm -lc ld: warning: relocation error: R_SPARC_32:
file .libs/PJ_krovak.o: symbol .LLC8: external symbolic relocation
against non-allocatable section .stab; cannot be processed at runtime:
relocation ignored ld: warning: relocation error: R_SPARC_32:
file .libs/PJ_krovak.o: symbol .LLC4: external symbolic relocation
against non-allocatable section .stab; cannot be processed at runtime:
relocation ignored ld: warning: relocation error: R_SPARC_32:
file .libs/PJ_krovak.o: symbol .LLC8: external symbolic relocation
against non-allocatable section .stab; cannot be processed at runtime:
relocation ignored ld: warning: relocation error: R_SPARC_32:
file .libs/PJ_krovak.o: symbol .LLC4: external symbolic relocation
against non-allocatable section .stab; cannot be processed at runtime:
relocation ignored ld: warning: relocation error: R_SPARC_32:
file .libs/PJ_krovak.o: symbol .LLC8: external symbolic relocation
against non-allocatable section .stab; cannot be processed at runtime:
relocation ignored ld: warning: relocation error: R_SPARC_32:
file .libs/PJ_krovak.o: symbol .LLC4: external symbolic relocation
against non-allocatable section .stab; cannot be processed at runtime:
relocation ignored (cd .libs && rm -f libproj.so.0 && ln -s
libproj.so.0.5.0 libproj.so.0) (cd .libs && rm -f libproj.so && ln -s
(Continue reading)


Gmane