headers
Duffy, Garret | 1 May 2012 17:49
Picon
Favicon

concatenate EPSG codes in proj4?

Hi,

Does proj4 support concatenation of EPSG codes?  e.g. I would like to
concatenate any projection with EPSG operation 9621.  I would ideally
like to do this in QGIS.

If not, does anyone have any advice how to do this?

Thanks,

Garret
_______________________________________________
Proj mailing list
Proj <at> lists.maptools.org
http://lists.maptools.org/mailman/listinfo/proj
Permalink | Reply | 0 comments |
headers
Frank Willett | 3 May 2012 19:40

Problem with projection imw_p


Hi All,

I'm having a problem with the imw_p projection and thought I
should send it to this list for comments before submitting a bug
report. The prompt from proj is % in the following examples and
the prompt from the OS is $.

This is proj-4.8.0 .

imw_p : International Map of the World Polyconic

$ ./proj +proj=imw_p +lat_1=2 +lat_2=6 +lon_1=0 +x_0=500000
%0 0
500000.00       0.00
%0 2
500000.00       0.00
%.0001 .0001
500011.15       -221138.40
%.0001 2
500011.13       0.00
%.0001 2.0001
500011.13       11.06

$ ./proj +proj=imw_p +lat_1=2 +lat_2=6 +lon_1=0 +x_0=500000 -I
%500000 0
-2147483648d-2147483648'1.#QO"E -2147483648d-2147483648'-1.#IO"N
%500000 1
-2147483648d-2147483648'1.#QO"E -2147483648d-2147483648'-1.#IO"N
%500001 1
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mikael Rittri | 4 May 2012 11:57
Favicon

How does the datum "NAD27 Michigan" work?

Hello,

I am trying to understand the ”NAD27 Michigan” datum, EPSG:6268.

 

As represented in EPSG, this is a datum distinct from NAD27,
and uses the ellipsoid “Clarke 1866 Michigan”.

EPSG remarks:

  

    “Ellipsoid taken to be 800 ft above the NAD27 reference ellipsoid.”

 

The information source (J. P. Snyder. Map Projections: A Working Manual, p. 56, note 1)
is more precise:

 

   “The major and minor axes of the ellipsoid are taken at exactly 1.0000382 times those

    of the Clarke 1866, for Michigan only. This incorporates an average elevation throughout

    the State of about 800 ft, with limited variation.”

 

Neither EPSG nor Snyder gives any datum shift for NAD 27 Michigan.

 

However, the Michigan Department of Natural Resources just writes:

 

      Datum:    NAD27

      Ellipsoid: Modified Clarke, 1866

                    

where the ellipsoid turns out to be the same as “Clarke 1866 Michigan”.

(http://www.michigan.gov/documents/DNR_Map_Proj_and_MI_Georef_Info_20889_7.pdf)

 

So it seems that Michiganders regard the datum NAD27 Michigan to be the same as NAD27:

it is not an adjustment or densification or whatever, it just has a different ellipsoid.

 

But this can be interpreted in two ways:

   a) that long/lat are the same in both datums,
   b) or that geocentric Cartesian coordinates X,Y,Z are the same in both datums.

 

If a) is intended, then a correct datum shift for NAD27 Michigan could use the CONUS
grid shift file intended for NAD27.

And if b) is intended, then the 3-parameter shift between NAD27 Michigan

and NAD27 would be 0,0,0.

 

These interpretations are not quite equivalent.

 

I’ve tried out b) in Proj.4, by setting identical towgs84 parameters for both datums.

(These are not very accurate, but since they are the same on both sides, they should

 cancel each other and give a 0,0,0 shift between NAD 27 Michigan and NAD27.)

 

>cs2cs +proj=longlat +a=6378450.0475 +b=6356826.6215 +towgs84=-9,161,179 +to +proj=longlat +ellps=clrk66 +towgs84=-9,161,179

 

-85 45 0

 

85dW    44d59'59.973"N 243.235

 

So, the point at the ellipsoid surface of NAD27 Michigan is 243.235 m = 798 feet
above the NAD27 ellipsoid, as expected. What surprised me is the latitude
shift of 0.027" = 0.83 meters. Well, I think understand where it comes from: the
line that is perpendicular to the ellipsoid surfaces doesn’t go through the ellipsoid
center(s). But the effect is much larger than I would have thought.  

 

So, does anyone know whether a) or b) or something else is the correct interpretation?

 

Best regards,

 

Mikael Rittri

Carmenta

Sweden

http://www.carmenta.com

 

_______________________________________________
Proj mailing list
Proj <at> lists.maptools.org
http://lists.maptools.org/mailman/listinfo/proj
Permalink | Reply | 2 comments |
headers
Jon Olav Skoien | 4 May 2012 15:59
Picon

Inconsistencies in projection definition (epsg 3857)

Dear list,

First of all, I am sorry if this is not the right list for the following 
question.

We are working with some data that has been transformed from latlong via 
different software and have encountered some inconsistencies with the 
coordination system definitions of epsg:3857 (WGS 84 / Pseudo-Mercator, 
often referred to as web mercator as it is used in web services such as 
Google Maps). Some software (e.g. psql2shape) seems to use the 
definition from spatialreference.org:
http://spatialreference.org/ref/sr-org/6864/
which gives the proj4 definition as:
+proj=merc +lon_0=0 +k=1 +x_0=0 +y_0=0 +a=6378137 +b=6378137 
+towgs84=0,0,0,0,0,0,0 +units=m +no_defs

ogr2ogr appears to use a proj4 definition that is quite similar (gives a 
dislocation of 10-20 meters in y-direction for some locations we have 
checked)
+proj=merc +lon_0=0 +k=1 +x_0=0 +y_0=0 +datum=WGS84 +units=m +no_defs 
+ellps=WGS84 +towgs84=0,0,0

However, the epsg-source of proj seems to use the following definition:
+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= <at> null +wktext  +no_defs

The difference for a random location in Europe is about 30 km in 
y-direction between the two definitions (using e.g. cs2cs). Which 
definition should we trust?

Thanks,
Jon

-- 
Jon Olav Skøien
Joint Research Centre - European Commission
Institute for Environment and Sustainability (IES)
Land Resource Management Unit

Via Fermi 2749, TP 440,  I-21027 Ispra (VA), ITALY

jon.skoien <at> jrc.ec.europa.eu
Tel:  +39 0332 789206

Disclaimer: Views expressed in this email are those of the individual and do not necessarily represent
official views of the European Commission.

_______________________________________________
Proj mailing list
Proj <at> lists.maptools.org
http://lists.maptools.org/mailman/listinfo/proj
Permalink | Reply | 1 comment |
headers
Mikael Rittri | 4 May 2012 16:46
Favicon

Re: Inconsistencies in projection definition (epsg 3857)

Trust the last one, with +nadgrids. 
See http://trac.osgeo.org/proj/wiki/FAQ (question 8).

Best regards,

Mikael Rittri
Carmenta
Sweden
http://www.carmenta.com

4 maj 2012 kl. 16:25 skrev "Jon Olav Skoien" <jon.skoien <at> jrc.ec.europa.eu>:

> Dear list,
> 
> First of all, I am sorry if this is not the right list for the following 
> question.
> 
> We are working with some data that has been transformed from latlong via 
> different software and have encountered some inconsistencies with the 
> coordination system definitions of epsg:3857 (WGS 84 / Pseudo-Mercator, 
> often referred to as web mercator as it is used in web services such as 
> Google Maps). Some software (e.g. psql2shape) seems to use the 
> definition from spatialreference.org:
> http://spatialreference.org/ref/sr-org/6864/
> which gives the proj4 definition as:
> +proj=merc +lon_0=0 +k=1 +x_0=0 +y_0=0 +a=6378137 +b=6378137 
> +towgs84=0,0,0,0,0,0,0 +units=m +no_defs
> 
> ogr2ogr appears to use a proj4 definition that is quite similar (gives a 
> dislocation of 10-20 meters in y-direction for some locations we have 
> checked)
> +proj=merc +lon_0=0 +k=1 +x_0=0 +y_0=0 +datum=WGS84 +units=m +no_defs 
> +ellps=WGS84 +towgs84=0,0,0
> 
> However, the epsg-source of proj seems to use the following definition:
> +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= <at> null +wktext  +no_defs
> 
> The difference for a random location in Europe is about 30 km in 
> y-direction between the two definitions (using e.g. cs2cs). Which 
> definition should we trust?
> 
> Thanks,
> Jon
> 
> 
> -- 
> Jon Olav Skøien
> Joint Research Centre - European Commission
> Institute for Environment and Sustainability (IES)
> Land Resource Management Unit
> 
> Via Fermi 2749, TP 440,  I-21027 Ispra (VA), ITALY
> 
> jon.skoien <at> jrc.ec.europa.eu
> Tel:  +39 0332 789206
> 
> Disclaimer: Views expressed in this email are those of the individual and do not necessarily represent
official views of the European Commission.
> 
> 
> _______________________________________________
> Proj mailing list
> Proj <at> lists.maptools.org
> http://lists.maptools.org/mailman/listinfo/proj
_______________________________________________
Proj mailing list
Proj <at> lists.maptools.org
http://lists.maptools.org/mailman/listinfo/proj
Permalink | Reply | 0 comments |
headers
Clifford J Mugnier | 4 May 2012 17:09
Favicon

Re: How does the datum "NAD27 Michigan" work?

Option (a) is the desired intent.  This is an attempt to translate between GIS pros and Cadastral pros.  Many GIS pros back then were not aware of using the Gaussian Sphere to implement the "Sea Level Correction" muchless go above the ellipsoid to the surface.  Minnesota does this on a county-by-county basis; Colombia does city-by-city.  This is essentially a scale factor correction for grid to ground distances.


Sent from Cliff Mugnier's iPhone

On May 4, 2012, at 5:19, "Mikael Rittri" <Mikael.Rittri <at> carmenta.com> wrote:

Hello,

I am trying to understand the ”NAD27 Michigan” datum, EPSG:6268.

 

As represented in EPSG, this is a datum distinct from NAD27,
and uses the ellipsoid “Clarke 1866 Michigan”.

EPSG remarks:

  

    “Ellipsoid taken to be 800 ft above the NAD27 reference ellipsoid.”

 

The information source (J. P. Snyder. Map Projections: A Working Manual, p. 56, note 1)
is more precise:

 

   “The major and minor axes of the ellipsoid are taken at exactly 1.0000382 times those

    of the Clarke 1866, for Michigan only. This incorporates an average elevation throughout

    the State of about 800 ft, with limited variation.”

 

Neither EPSG nor Snyder gives any datum shift for NAD 27 Michigan.

 

However, the Michigan Department of Natural Resources just writes:

 

      Datum:    NAD27

      Ellipsoid: Modified Clarke, 1866

                    

where the ellipsoid turns out to be the same as “Clarke 1866 Michigan”.

(http://www.michigan.gov/documents/DNR_Map_Proj_and_MI_Georef_Info_20889_7.pdf)

 

So it seems that Michiganders regard the datum NAD27 Michigan to be the same as NAD27:

it is not an adjustment or densification or whatever, it just has a different ellipsoid.

 

But this can be interpreted in two ways:

   a) that long/lat are the same in both datums,
   b) or that geocentric Cartesian coordinates X,Y,Z are the same in both datums.

 

If a) is intended, then a correct datum shift for NAD27 Michigan could use the CONUS
grid shift file intended for NAD27.

And if b) is intended, then the 3-parameter shift between NAD27 Michigan

and NAD27 would be 0,0,0.

 

These interpretations are not quite equivalent.

 

I’ve tried out b) in Proj.4, by setting identical towgs84 parameters for both datums.

(These are not very accurate, but since they are the same on both sides, they should

 cancel each other and give a 0,0,0 shift between NAD 27 Michigan and NAD27.)

 

>cs2cs +proj=longlat +a=6378450.0475 +b=6356826.6215 +towgs84=-9,161,179 +to +proj=longlat +ellps=clrk66 +towgs84=-9,161,179

 

-85 45 0

 

85dW    44d59'59.973"N 243.235

 

So, the point at the ellipsoid surface of NAD27 Michigan is 243.235 m = 798 feet
above the NAD27 ellipsoid, as expected. What surprised me is the latitude
shift of 0.027" = 0.83 meters. Well, I think understand where it comes from: the
line that is perpendicular to the ellipsoid surfaces doesn’t go through the ellipsoid
center(s). But the effect is much larger than I would have thought.  

 

So, does anyone know whether a) or b) or something else is the correct interpretation?

 

Best regards,

 

Mikael Rittri

Carmenta

Sweden

http://www.carmenta.com

 

_______________________________________________
Proj mailing list
Proj <at> lists.maptools.org
http://lists.maptools.org/mailman/listinfo/proj 
_______________________________________________
Proj mailing list
Proj <at> lists.maptools.org
http://lists.maptools.org/mailman/listinfo/proj
Permalink | Reply | 1 comment |
headers
Mikael Rittri | 7 May 2012 10:05
Favicon

Re: How does the datum "NAD27 Michigan" work?

> Option (a) is the desired intent.  

> [ … ]

> This is essentially a scale factor correction for grid to ground distances.

 

I see.

 

> Minnesota does this on a county-by-county basis; Colombia does city-by-city.

 

Aha, so that’s the explanation for things like

 

GEOGCS["GCS_NAD_1983_HARN_Adj_MN_Carver",
       DATUM["D_NAD_1983_HARN_Adj_MN_Carver",

             SPHEROID["S_GRS_1980_Adj_MN_Carver",6378400.653,298.2572221008827]],

       PRIMEM["Greenwich",0.0],

       UNIT["Degree",0.0174532925199433]]

 

They have confused me, too.

 

Thank you very much,

 

Mikael Rittri

Carmenta

Sweden

http://www.carmenta.com

 

From: proj-bounces <at> lists.maptools.org [mailto:proj-bounces <at> lists.maptools.org] On Behalf Of Clifford J Mugnier
Sent: den 4 maj 2012 17:09
To: PROJ.4 and general Projections Discussions
Subject: Re: [Proj] How does the datum "NAD27 Michigan" work?

 

Option (a) is the desired intent.  This is an attempt to translate between GIS pros and Cadastral pros.  Many GIS pros back then were not aware of using the Gaussian Sphere to implement the "Sea Level Correction" muchless go above the ellipsoid to the surface.  Minnesota does this on a county-by-county basis; Colombia does city-by-city.  This is essentially a scale factor correction for grid to ground distances.

 

Sent from Cliff Mugnier's iPhone


On May 4, 2012, at 5:19, "Mikael Rittri" <Mikael.Rittri <at> carmenta.com> wrote:

Hello,

I am trying to understand the ”NAD27 Michigan” datum, EPSG:6268.

 

As represented in EPSG, this is a datum distinct from NAD27,
and uses the ellipsoid “Clarke 1866 Michigan”.

EPSG remarks:

  

    “Ellipsoid taken to be 800 ft above the NAD27 reference ellipsoid.”

 

The information source (J. P. Snyder. Map Projections: A Working Manual, p. 56, note 1)
is more precise:

 

   “The major and minor axes of the ellipsoid are taken at exactly 1.0000382 times those

    of the Clarke 1866, for Michigan only. This incorporates an average elevation throughout

    the State of about 800 ft, with limited variation.”

 

Neither EPSG nor Snyder gives any datum shift for NAD 27 Michigan.

 

However, the Michigan Department of Natural Resources just writes:

 

      Datum:    NAD27

      Ellipsoid: Modified Clarke, 1866

                    

where the ellipsoid turns out to be the same as “Clarke 1866 Michigan”.

(http://www.michigan.gov/documents/DNR_Map_Proj_and_MI_Georef_Info_20889_7.pdf)

 

So it seems that Michiganders regard the datum NAD27 Michigan to be the same as NAD27:

it is not an adjustment or densification or whatever, it just has a different ellipsoid.

 

But this can be interpreted in two ways:

   a) that long/lat are the same in both datums,
   b) or that geocentric Cartesian coordinates X,Y,Z are the same in both datums.

 

If a) is intended, then a correct datum shift for NAD27 Michigan could use the CONUS
grid shift file intended for NAD27.

And if b) is intended, then the 3-parameter shift between NAD27 Michigan

and NAD27 would be 0,0,0.

 

These interpretations are not quite equivalent.

 

I’ve tried out b) in Proj.4, by setting identical towgs84 parameters for both datums.

(These are not very accurate, but since they are the same on both sides, they should

 cancel each other and give a 0,0,0 shift between NAD 27 Michigan and NAD27.)

 

>cs2cs +proj=longlat +a=6378450.0475 +b=6356826.6215 +towgs84=-9,161,179 +to +proj=longlat +ellps=clrk66 +towgs84=-9,161,179

 

-85 45 0

 

85dW    44d59'59.973"N 243.235

 

So, the point at the ellipsoid surface of NAD27 Michigan is 243.235 m = 798 feet
above the NAD27 ellipsoid, as expected. What surprised me is the latitude
shift of 0.027" = 0.83 meters. Well, I think understand where it comes from: the
line that is perpendicular to the ellipsoid surfaces doesn’t go through the ellipsoid
center(s). But the effect is much larger than I would have thought.  

 

So, does anyone know whether a) or b) or something else is the correct interpretation?

 

Best regards,

 

Mikael Rittri

Carmenta

Sweden

http://www.carmenta.com

 

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

_______________________________________________
Proj mailing list
Proj <at> lists.maptools.org
http://lists.maptools.org/mailman/listinfo/proj
Permalink | Reply | 0 comments |
headers
rps_rt | 7 May 2012 14:19
Picon
Favicon

Re: Using EPSG codes with cs2cs

Dear Warmerdam and all members,

I have been browsing and reading for a while to convert my coordinates with
no hope until finding this Proj. 4.

Kindly, I seek your support here ... I am using Linux Ubuntu to convert from
long/lat (WGS84) to Cartesian (x/y) and vice versa. My need here is to get
as accurate as possible results (cm-level if possible).

I was reading this thread because I had a problem of getting a cs2cs results
for espg=31495, while I could get them for espg=31468. But the conversion
results with the later one were not accurate ~ almost 100 meters away.

e.g.,: echo "13.755944 51.054555" | cs2cs +init=epsg:4326 +to
+init=epsg:31468

but when I change it to: echo "13.755944 51.054555" | cs2cs +init=epsg:4326
+to +init=epsg:31495,
I get the message "projection initialization failure cause: no options found
in 'init' file".

I tried to change something based on this thread, to make sure that my
PROJ_LIB path is in place, but it seems I ruined everything. Afterwards, all
espg zones gave the below error:
"
pj_open_lib(epsg): call fopen(/usr/local/bin/cs2cs/epsg) - failed
Using from definition: init=epsg:31467
Rel. 4.8.0, 6 March 2012
<cs2cs>:
projection initialization cause: no system list, errno: 20
"

I tried to "make uninstall" and "make install" but nothing was fixed!!

Here are more details about my project:

My locations are in Dresden city, Germany, (DHDN4), and I have (I assume)
all what is needed to get my coordinates converted accurately, but no idea
how to process them in Proj. 4 (I am totally new here):

PROJCS["DHDN / Germany zone
4",GEOGCS["DHDN",DATUM["Deutsche_Hauptdreiecksnetz",
SPHEROID["Bessel 1841",6377397.155,299.1528128]],PRIMEM["Greenwich",0],
UNIT["degree",0.0174532925199433]],PROJECTION["Transverse_Mercator"],
PARAMETER["latitude_of_origin",0],PARAMETER["central_meridian",12],
PARAMETER["scale_factor",1],PARAMETER["false_easting",4500000],
PARAMETER["false_northing",0],UNIT["metre",1]]
TOWGS84=582.0,105.0,414.0,5.042e-6,1.696e-6,-1.4932e-5,8.3
EPSG=31495

%Seven parameters:
% 582.00     - Translation dx in meter to WGS84
% 105.0      - Translation dy in meter to WGS84
% 414.50     - Translation dz in meter to WGS84
% 5.042e-6   - Rotation ro (omega) in Radiant to WGS84
% 1.696e-6   - Rotation rf (phi) in radiant to WGS84
% -1.4932e-5 - Rotation rk (Kappa) in Radiant to WGS84
% 8.3e-06    - Mapscale factor in ppm (parts per million) to WGS84(m)

Sorry for the long thread but did not want to miss any details, even in my
first ever thread in this forum.

I will be looking forward to reading form you.
Best regards,
Amro 

--
View this message in context: http://osgeo-org.1560.n6.nabble.com/Using-EPSG-codes-with-cs2cs-tp3841592p4957639.html
Sent from the PROJ.4 mailing list archive at Nabble.com.
_______________________________________________
Proj mailing list
Proj <at> lists.maptools.org
http://lists.maptools.org/mailman/listinfo/proj
Permalink | Reply | 6 comments |
headers
rps_rt | 7 May 2012 14:22
Picon
Favicon

Re: Using EPSG codes with cs2cs

Dear Warmerdam and all members,

I have been browsing and reading for a while to convert my coordinates with
no hope until finding this Proj. 4.

Kindly, I seek your support here ... I am using Linux Ubuntu to convert from
long/lat (WGS84) to Cartesian (x/y) and vice versa. My need here is to get
as accurate as possible results (cm-level if possible).

I was reading this thread because I had a problem of getting a cs2cs results
for espg=31495, while I could get them for espg=31468. But the conversion
results with the later one were not accurate ~ almost 100 meters away.

e.g.,: echo "13.755944 51.054555" | cs2cs +init=epsg:4326 +to
+init=epsg:31468

but when I change it to: echo "13.755944 51.054555" | cs2cs +init=epsg:4326
+to +init=epsg:31495,
I get the message "projection initialization failure cause: no options found
in 'init' file".

I tried to change something based on this thread, to make sure that my
PROJ_LIB path is in place, but it seems I ruined everything. Afterwards, all
espg zones gave the below error:
"
pj_open_lib(epsg): call fopen(/usr/local/bin/cs2cs/epsg) - failed
Using from definition: init=epsg:31467
Rel. 4.8.0, 6 March 2012
<cs2cs>:
projection initialization cause: no system list, errno: 20
"

I tried to "make uninstall" and "make install" but nothing was fixed!!

Here are more details about my project:

My locations are in Dresden city, Germany, (DHDN4), and I have (I assume)
all what is needed to get my coordinates converted accurately, but no idea
how to process them in Proj. 4 (I am totally new here):

PROJCS["DHDN / Germany zone
4",GEOGCS["DHDN",DATUM["Deutsche_Hauptdreiecksnetz",
SPHEROID["Bessel 1841",6377397.155,299.1528128]],PRIMEM["Greenwich",0],
UNIT["degree",0.0174532925199433]],PROJECTION["Transverse_Mercator"],
PARAMETER["latitude_of_origin",0],PARAMETER["central_meridian",12],
PARAMETER["scale_factor",1],PARAMETER["false_easting",4500000],
PARAMETER["false_northing",0],UNIT["metre",1]]
TOWGS84=582.0,105.0,414.0,5.042e-6,1.696e-6,-1.4932e-5,8.3
EPSG=31495

%Seven parameters:
% 582.00     - Translation dx in meter to WGS84
% 105.0      - Translation dy in meter to WGS84
% 414.50     - Translation dz in meter to WGS84
% 5.042e-6   - Rotation ro (omega) in Radiant to WGS84
% 1.696e-6   - Rotation rf (phi) in radiant to WGS84
% -1.4932e-5 - Rotation rk (Kappa) in Radiant to WGS84
% 8.3e-06    - Mapscale factor in ppm (parts per million) to WGS84(m)

Sorry for the long thread but did not want to miss any details, even in my
first ever thread in this forum.

I will be looking forward to reading form you.
Best regards,
Amro

--
View this message in context: http://osgeo-org.1560.n6.nabble.com/Using-EPSG-codes-with-cs2cs-tp3841592p4957644.html
Sent from the PROJ.4 mailing list archive at Nabble.com.
_______________________________________________
Proj mailing list
Proj <at> lists.maptools.org
http://lists.maptools.org/mailman/listinfo/proj
Permalink | Reply | 1 comment |
headers
Fischer, Robert P. (GISS-6110)[COLUMBIA UNIVERSITY] | 7 May 2012 14:37
Picon
Favicon

Re: Using EPSG codes with cs2cs

Have you tried using the version of proj.4 that comes with Ubuntu (apt-get install proj)?

http://packages.ubuntu.com/search?keywords=proj

-- Bob
________________________________________
From: proj-bounces <at> lists.maptools.org [proj-bounces <at> lists.maptools.org] On Behalf Of rps_rt [ec_eng01 <at> yahoo.com]
Sent: Monday, May 07, 2012 8:22 AM
To: proj <at> lists.maptools.org
Subject: Re: [Proj] Using EPSG codes with cs2cs

Dear Warmerdam and all members,

I have been browsing and reading for a while to convert my coordinates with
no hope until finding this Proj. 4.

Kindly, I seek your support here ... I am using Linux Ubuntu to convert from
long/lat (WGS84) to Cartesian (x/y) and vice versa. My need here is to get
as accurate as possible results (cm-level if possible).

I was reading this thread because I had a problem of getting a cs2cs results
for espg=31495, while I could get them for espg=31468. But the conversion
results with the later one were not accurate ~ almost 100 meters away.

e.g.,: echo "13.755944 51.054555" | cs2cs +init=epsg:4326 +to
+init=epsg:31468

but when I change it to: echo "13.755944 51.054555" | cs2cs +init=epsg:4326
+to +init=epsg:31495,
I get the message "projection initialization failure cause: no options found
in 'init' file".

I tried to change something based on this thread, to make sure that my
PROJ_LIB path is in place, but it seems I ruined everything. Afterwards, all
espg zones gave the below error:
"
pj_open_lib(epsg): call fopen(/usr/local/bin/cs2cs/epsg) - failed
Using from definition: init=epsg:31467
Rel. 4.8.0, 6 March 2012
<cs2cs>:
projection initialization cause: no system list, errno: 20
"

I tried to "make uninstall" and "make install" but nothing was fixed!!

Here are more details about my project:

My locations are in Dresden city, Germany, (DHDN4), and I have (I assume)
all what is needed to get my coordinates converted accurately, but no idea
how to process them in Proj. 4 (I am totally new here):

PROJCS["DHDN / Germany zone
4",GEOGCS["DHDN",DATUM["Deutsche_Hauptdreiecksnetz",
SPHEROID["Bessel 1841",6377397.155,299.1528128]],PRIMEM["Greenwich",0],
UNIT["degree",0.0174532925199433]],PROJECTION["Transverse_Mercator"],
PARAMETER["latitude_of_origin",0],PARAMETER["central_meridian",12],
PARAMETER["scale_factor",1],PARAMETER["false_easting",4500000],
PARAMETER["false_northing",0],UNIT["metre",1]]
TOWGS84=582.0,105.0,414.0,5.042e-6,1.696e-6,-1.4932e-5,8.3
EPSG=31495

%Seven parameters:
% 582.00     - Translation dx in meter to WGS84
% 105.0      - Translation dy in meter to WGS84
% 414.50     - Translation dz in meter to WGS84
% 5.042e-6   - Rotation ro (omega) in Radiant to WGS84
% 1.696e-6   - Rotation rf (phi) in radiant to WGS84
% -1.4932e-5 - Rotation rk (Kappa) in Radiant to WGS84
% 8.3e-06    - Mapscale factor in ppm (parts per million) to WGS84(m)

Sorry for the long thread but did not want to miss any details, even in my
first ever thread in this forum.

I will be looking forward to reading form you.
Best regards,
Amro

--
View this message in context: http://osgeo-org.1560.n6.nabble.com/Using-EPSG-codes-with-cs2cs-tp3841592p4957644.html
Sent from the PROJ.4 mailing list archive at Nabble.com.
_______________________________________________
Proj mailing list
Proj <at> lists.maptools.org
http://lists.maptools.org/mailman/listinfo/proj
_______________________________________________
Proj mailing list
Proj <at> lists.maptools.org
http://lists.maptools.org/mailman/listinfo/proj
Permalink | Reply | 0 comments |

Gmane