From wiedemann at pde.com Tue May 3 17:42:51 2016 From: wiedemann at pde.com (Victor Wiedemann) Date: Tue, 3 May 2016 15:42:51 -0700 Subject: [Proj] FW: Convert from WGS84 (Lat, Lon) to other geodetic datums (Lat, Lon) and vice versa Message-ID: <000001d1a58d$20a4d460$61ee7d20$@pde.com> After looking through the code for PROJ.4, I haven't seen any basic conversion commands, but I am sure there is something already written for this. If this is already made could someone point me in the right direction. If not, any ideas on how to do this? Thank you, Victor -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.maptools.org/pipermail/proj/attachments/20160503/4a915090/attachment.htm From charles.karney at sri.com Tue May 3 19:02:10 2016 From: charles.karney at sri.com (Charles Karney) Date: Tue, 3 May 2016 20:02:10 -0400 Subject: [Proj] FW: Convert from WGS84 (Lat, Lon) to other geodetic datums (Lat, Lon) and vice versa In-Reply-To: <000001d1a58d$20a4d460$61ee7d20$@pde.com> References: <000001d1a58d$20a4d460$61ee7d20$@pde.com> Message-ID: <2e4b41ba-769d-5b15-0862-f2a35e4501a3@sri.com> man cs2cs includes an example of changing datums. On 05/03/2016 06:42 PM, Victor Wiedemann wrote: > After looking through the code for PROJ.4, I haven?t seen any basic > conversion commands, but I am sure there is something already written > for this. If this is already made could someone point me in the right > direction. If not, any ideas on how to do this? > > Thank you, > > Victor From dschulze at wirelessseismic.com Mon May 9 17:41:10 2016 From: dschulze at wirelessseismic.com (Dean Schulze) Date: Mon, 9 May 2016 22:41:10 +0000 Subject: [Proj] Running the cities example in the pdf documents gives different results Message-ID: <05D3156E14665542AF857A27B23CFA1BA14532@mbx026-w1-ca-4.exch026.domain.local> I ran the cities example using the inputs on pg. 4 of the docs at ftp://ftp.remotesensing.org/proj/OF90-284.pdf, but I got different results than shown. Here are the results I got: $ proj +proj=poly -r cities.lat.lon.txt # coordinates for a few cities -4887445.45 7318110.56 Boston, United States -5542376.59 6982834.25 New York, United States 171219.46 5415571.82 Paris, France 485343.33 5730932.66?w London, England The document linked above shows this: $ proj +proj=poly -r cities # coordinates for a few cities -4887590.49 7317961.48 Boston, United States -5542524.55 6982689.05 New York, United States 171224.94 5415352.81 Paris, France -8101.66 5707500.23 London, England Am I doing something wrong, or did something change from when the document was written? Thanks. From martin.desruisseaux at geomatys.com Mon May 9 18:00:34 2016 From: martin.desruisseaux at geomatys.com (Martin Desruisseaux) Date: Mon, 9 May 2016 16:00:34 -0700 Subject: [Proj] Running the cities example in the pdf documents gives different results In-Reply-To: <05D3156E14665542AF857A27B23CFA1BA14532@mbx026-w1-ca-4.exch026.domain.local> References: <05D3156E14665542AF857A27B23CFA1BA14532@mbx026-w1-ca-4.exch026.domain.local> Message-ID: Hello Dean From jagoncal at gmail.com Tue May 10 03:19:04 2016 From: jagoncal at gmail.com (=?UTF-8?Q?Jose_Gon=C3=A7alves?=) Date: Tue, 10 May 2016 09:19:04 +0100 Subject: [Proj] Running the cities example in the pdf documents gives different results In-Reply-To: <05D3156E14665542AF857A27B23CFA1BA14532@mbx026-w1-ca-4.exch026.domain.local> References: <05D3156E14665542AF857A27B23CFA1BA14532@mbx026-w1-ca-4.exch026.domain.local> Message-ID: Hi You're not specifying an ellipsoid in the command line. Your PROJ version is using WGS84 by default. The default ellipsoid of the PROJ version used in the example of the PDF document was Clarke 66. You get those results with: proj +proj=poly +ellps=clrk66 -r Regards Jos? Gon?alves 2016-05-09 23:41 GMT+01:00 Dean Schulze : > > I ran the cities example using the inputs on pg. 4 of the docs at > ftp://ftp.remotesensing.org/proj/OF90-284.pdf, but I got different > results than shown. Here are the results I got: > > $ proj +proj=poly -r cities.lat.lon.txt > # coordinates for a few cities > -4887445.45 7318110.56 Boston, United States > -5542376.59 6982834.25 New York, United States > 171219.46 5415571.82 Paris, France > 485343.33 5730932.66?w London, England > > > The document linked above shows this: > > $ proj +proj=poly -r cities > # coordinates for a few cities > -4887590.49 7317961.48 Boston, United States > -5542524.55 6982689.05 New York, United States > 171224.94 5415352.81 Paris, France > -8101.66 5707500.23 London, England > > > Am I doing something wrong, or did something change from when the document > was written? > > Thanks. > _______________________________________________ > Proj mailing list > Proj at lists.maptools.org > http://lists.maptools.org/mailman/listinfo/proj > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.maptools.org/pipermail/proj/attachments/20160510/f068b47d/attachment.htm From dschulze at wirelessseismic.com Tue May 10 09:45:29 2016 From: dschulze at wirelessseismic.com (Dean Schulze) Date: Tue, 10 May 2016 14:45:29 +0000 Subject: [Proj] Running the cities example in the pdf documents gives different results In-Reply-To: References: <05D3156E14665542AF857A27B23CFA1BA14532@mbx026-w1-ca-4.exch026.domain.local>, Message-ID: <05D3156E14665542AF857A27B23CFA1BA1457E@mbx026-w1-ca-4.exch026.domain.local> Ahhh, so the default ellipsoid changed from the time of writing. Adding +ellps=clrk66 gives the same results as in the document for the first 3 cities, but the 4th city (London) is way off. Here's my results: $ proj +proj=poly +ellps=clrk66 -r cities.lat.lon.txt # coordinates for a few cities -4887590.49 7317961.48 Boston, United States -5542524.55 6982689.05 New York, United States 171224.94 5415352.81 Paris, France 485359.70 5730714.96?w London, England The document shows the following for London: -8101.66 5707500.23 London, England so something else is wrong. I'm using Rel. 4.8.0, 6 March 2012. ________________________________________ From: proj-bounces at lists.maptools.org [proj-bounces at lists.maptools.org] on behalf of Jose Gon?alves [jagoncal at gmail.com] Sent: Tuesday, May 10, 2016 2:19 AM To: PROJ.4 and general Projections Discussions Subject: Re: [Proj] Running the cities example in the pdf documents gives different results Hi You're not specifying an ellipsoid in the command line. Your PROJ version is using WGS84 by default. The default ellipsoid of the PROJ version used in the example of the PDF document was Clarke 66. You get those results with: proj +proj=poly +ellps=clrk66 -r Regards Jos? Gon?alves 2016-05-09 23:41 GMT+01:00 Dean Schulze >: I ran the cities example using the inputs on pg. 4 of the docs at ftp://ftp.remotesensing.org/proj/OF90-284.pdf, but I got different results than shown. Here are the results I got: $ proj +proj=poly -r cities.lat.lon.txt # coordinates for a few cities -4887445.45 7318110.56 Boston, United States -5542376.59 6982834.25 New York, United States 171219.46 5415571.82 Paris, France 485343.33 5730932.66?w London, England The document linked above shows this: $ proj +proj=poly -r cities # coordinates for a few cities -4887590.49 7317961.48 Boston, United States -5542524.55 6982689.05 New York, United States 171224.94 5415352.81 Paris, France -8101.66 5707500.23 London, England Am I doing something wrong, or did something change from when the document was written? Thanks. _______________________________________________ Proj mailing list Proj at lists.maptools.org http://lists.maptools.org/mailman/listinfo/proj From jagoncal at gmail.com Tue May 10 18:13:48 2016 From: jagoncal at gmail.com (=?UTF-8?Q?Jose_Gon=C3=A7alves?=) Date: Wed, 11 May 2016 00:13:48 +0100 Subject: [Proj] Running the cities example in the pdf documents gives different results In-Reply-To: <05D3156E14665542AF857A27B23CFA1BA1457E@mbx026-w1-ca-4.exch026.domain.local> References: <05D3156E14665542AF857A27B23CFA1BA14532@mbx026-w1-ca-4.exch026.domain.local> <05D3156E14665542AF857A27B23CFA1BA1457E@mbx026-w1-ca-4.exch026.domain.local> Message-ID: The problem is with the longitude, which is 7 minutes west. If you do the inverse projection with the projected coordinates, you get exactly 7 degrees east. echo 485359.70 5730714.96 | proj -I +ellps=clrk66 +proj=poly 7dE 51d30'N The symbol of minutes (') and the w are not being read correctly. Regards Jos? 2016-05-10 15:45 GMT+01:00 Dean Schulze : > Ahhh, so the default ellipsoid changed from the time of writing. > > Adding +ellps=clrk66 gives the same results as in the document for the > first 3 cities, but the 4th city (London) is way off. Here's my results: > > $ proj +proj=poly +ellps=clrk66 -r cities.lat.lon.txt > # coordinates for a few cities > -4887590.49 7317961.48 Boston, United States > -5542524.55 6982689.05 New York, United States > 171224.94 5415352.81 Paris, France > 485359.70 5730714.96?w London, England > > > The document shows the following for London: > > -8101.66 5707500.23 London, England > > so something else is wrong. I'm using Rel. 4.8.0, 6 March 2012. > > > ________________________________________ > From: proj-bounces at lists.maptools.org [proj-bounces at lists.maptools.org] > on behalf of Jose Gon?alves [jagoncal at gmail.com] > Sent: Tuesday, May 10, 2016 2:19 AM > To: PROJ.4 and general Projections Discussions > Subject: Re: [Proj] Running the cities example in the pdf documents gives > different results > > Hi > You're not specifying an ellipsoid in the command line. Your PROJ version > is using WGS84 by default. > The default ellipsoid of the PROJ version used in the example of the PDF > document was Clarke 66. > You get those results with: > proj +proj=poly +ellps=clrk66 -r > > Regards > > Jos? Gon?alves > > > > > 2016-05-09 23:41 GMT+01:00 Dean Schulze >: > > I ran the cities example using the inputs on pg. 4 of the docs at > ftp://ftp.remotesensing.org/proj/OF90-284.pdf, but I got different > results than shown. Here are the results I got: > > $ proj +proj=poly -r cities.lat.lon.txt > # coordinates for a few cities > -4887445.45 7318110.56 Boston, United States > -5542376.59 6982834.25 New York, United States > 171219.46 5415571.82 Paris, France > 485343.33 5730932.66?w London, England > > > The document linked above shows this: > > $ proj +proj=poly -r cities > # coordinates for a few cities > -4887590.49 7317961.48 Boston, United States > -5542524.55 6982689.05 New York, United States > 171224.94 5415352.81 Paris, France > -8101.66 5707500.23 London, England > > > Am I doing something wrong, or did something change from when the document > was written? > > Thanks. > _______________________________________________ > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.maptools.org/pipermail/proj/attachments/20160511/77b22b3c/attachment.htm From dschulze at wirelessseismic.com Mon May 16 12:24:37 2016 From: dschulze at wirelessseismic.com (Dean Schulze) Date: Mon, 16 May 2016 17:24:37 +0000 Subject: [Proj] Using invproj to get back the inputs to proj Message-ID: <05D3156E14665542AF857A27B23CFA1BA146D7@mbx026-w1-ca-4.exch026.domain.local> Following the example in the man page if I do proj +proj=utm +lon_0=112w +ellps=clrk66 -r man.page.lat.lon.txt where the file man.page.lat.lon.txt contains 45d15'33.1" 111.5W 45d15.551666667N -111d30 +45.25919444444 111d30'000w I get the 3 lines of output shown in the man page: 460769.27 5011648.45 460769.27 5011648.45 460769.27 5011648.45 So far, so good. But when I try to use invproj to get back the original inputs the results are not even close to the inputs: proj +proj=utm +lon_0=112w +ellps=clrk66 -r man.page.lat.lon.txt | invproj +proj=utm +lon_0=112w +ellps=clrk66 -r gives 73d25'28.89"W 3d18'2.678"N 73d25'28.89"W 3d18'2.678"N 73d25'28.89"W 3d18'2.678"N What is invproj giving me? How do I run invproj to get back my original inputs? Apparently invproj doesn't use command line parameters the same way that proj does. Is this documented somewhere? I've read the 3 .pdfs provides as users manuals, but they say nothing about how to use invproj to get back the original inputs. Thanks. From knudsen.thomas at gmail.com Tue May 17 00:59:45 2016 From: knudsen.thomas at gmail.com (Thomas Knudsen) Date: Tue, 17 May 2016 07:59:45 +0200 Subject: [Proj] Using invproj to get back the inputs to proj In-Reply-To: <05D3156E14665542AF857A27B23CFA1BA146D7@mbx026-w1-ca-4.exch026.domain.local> References: <05D3156E14665542AF857A27B23CFA1BA146D7@mbx026-w1-ca-4.exch026.domain.local> Message-ID: Try to leave out the -r option in invproj: the output of proj, that you feed into invproj is not in reverse order. Also, do not expect identical output, especially not for data points far off the central meridian. /Thomas Den 16. maj 2016 19.26 skrev "Dean Schulze" : > Following the example in the man page if I do > > proj +proj=utm +lon_0=112w +ellps=clrk66 -r man.page.lat.lon.txt > > where the file man.page.lat.lon.txt contains > > 45d15'33.1" 111.5W > 45d15.551666667N -111d30 > +45.25919444444 111d30'000w > > I get the 3 lines of output shown in the man page: > > 460769.27 5011648.45 > 460769.27 5011648.45 > 460769.27 5011648.45 > > So far, so good. But when I try to use invproj to get back the original > inputs the results are not even close to the inputs: > > proj +proj=utm +lon_0=112w +ellps=clrk66 -r man.page.lat.lon.txt | > invproj +proj=utm +lon_0=112w +ellps=clrk66 -r > > gives > > 73d25'28.89"W 3d18'2.678"N > 73d25'28.89"W 3d18'2.678"N > 73d25'28.89"W 3d18'2.678"N > > What is invproj giving me? How do I run invproj to get back my original > inputs? > > Apparently invproj doesn't use command line parameters the same way that > proj does. Is this documented somewhere? I've read the 3 .pdfs provides > as users manuals, but they say nothing about how to use invproj to get back > the original inputs. > > Thanks. > _______________________________________________ > Proj mailing list > Proj at lists.maptools.org > http://lists.maptools.org/mailman/listinfo/proj > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.maptools.org/pipermail/proj/attachments/20160517/c0852653/attachment.htm From dschulze at wirelessseismic.com Tue May 17 09:54:06 2016 From: dschulze at wirelessseismic.com (Dean Schulze) Date: Tue, 17 May 2016 14:54:06 +0000 Subject: [Proj] Using invproj to get back the inputs to proj In-Reply-To: References: <05D3156E14665542AF857A27B23CFA1BA146D7@mbx026-w1-ca-4.exch026.domain.local>, Message-ID: <05D3156E14665542AF857A27B23CFA1BA1475B@mbx026-w1-ca-4.exch026.domain.local> Leaving off the -r on invproj gives me back the correct latitude, but the longitude is even worse: $ proj +proj=utm +lon_0=112w +ellps=clrk66 -r man.page.lat.lon.txt | invproj +proj=utm +ellps=clrk66 # proj +proj=utm +lon_0=112w +ellps=clrk66 -r man.page.lat.lon.txt # Should give # 460769.27 5011648.45 3d30'W 45d15'33.1"N 3d30'W 45d15'33.1"N 3d30'W 45d15'33.1"N ________________________________________ From: proj-bounces at lists.maptools.org [proj-bounces at lists.maptools.org] on behalf of Thomas Knudsen [knudsen.thomas at gmail.com] Sent: Monday, May 16, 2016 11:59 PM To: PROJ. 4 and general Projections Discussions Subject: Re: [Proj] Using invproj to get back the inputs to proj Try to leave out the -r option in invproj: the output of proj, that you feed into invproj is not in reverse order. Also, do not expect identical output, especially not for data points far off the central meridian. /Thomas Den 16. maj 2016 19.26 skrev "Dean Schulze" >: Following the example in the man page if I do proj +proj=utm +lon_0=112w +ellps=clrk66 -r man.page.lat.lon.txt where the file man.page.lat.lon.txt contains 45d15'33.1" 111.5W 45d15.551666667N -111d30 +45.25919444444 111d30'000w I get the 3 lines of output shown in the man page: 460769.27 5011648.45 460769.27 5011648.45 460769.27 5011648.45 So far, so good. But when I try to use invproj to get back the original inputs the results are not even close to the inputs: proj +proj=utm +lon_0=112w +ellps=clrk66 -r man.page.lat.lon.txt | invproj +proj=utm +lon_0=112w +ellps=clrk66 -r gives 73d25'28.89"W 3d18'2.678"N 73d25'28.89"W 3d18'2.678"N 73d25'28.89"W 3d18'2.678"N What is invproj giving me? How do I run invproj to get back my original inputs? Apparently invproj doesn't use command line parameters the same way that proj does. Is this documented somewhere? I've read the 3 .pdfs provides as users manuals, but they say nothing about how to use invproj to get back the original inputs. Thanks. _______________________________________________ Proj mailing list Proj at lists.maptools.org http://lists.maptools.org/mailman/listinfo/proj From andre+joost at nurfuerspam.de Tue May 17 13:09:58 2016 From: andre+joost at nurfuerspam.de (Andre Joost) Date: Tue, 17 May 2016 20:09:58 +0200 Subject: [Proj] Using invproj to get back the inputs to proj In-Reply-To: <05D3156E14665542AF857A27B23CFA1BA1475B@mbx026-w1-ca-4.exch026.domain.local> References: <05D3156E14665542AF857A27B23CFA1BA146D7@mbx026-w1-ca-4.exch026.domain.local>, <05D3156E14665542AF857A27B23CFA1BA1475B@mbx026-w1-ca-4.exch026.domain.local> Message-ID: Am 17.05.2016 um 16:54 schrieb Dean Schulze: > Leaving off the -r on invproj gives me back the correct latitude, but the longitude is even worse: > > $ proj +proj=utm +lon_0=112w +ellps=clrk66 -r man.page.lat.lon.txt | invproj +proj=utm +ellps=clrk66 > # proj +proj=utm +lon_0=112w +ellps=clrk66 -r man.page.lat.lon.txt > # Should give > # 460769.27 5011648.45 > 3d30'W 45d15'33.1"N > 3d30'W 45d15'33.1"N > 3d30'W 45d15'33.1"N > > > ________________________________________ > From: proj-bounces at lists.maptools.org [proj-bounces at lists.maptools.org] on behalf of Thomas Knudsen [knudsen.thomas at gmail.com] > Sent: Monday, May 16, 2016 11:59 PM > To: PROJ. 4 and general Projections Discussions > Subject: Re: [Proj] Using invproj to get back the inputs to proj > > Try to leave out the -r option in invproj: the output of proj, that you feed into invproj is not in reverse order. > > Also, do not expect identical output, especially not for data points far off the central meridian. > > /Thomas > > Den 16. maj 2016 19.26 skrev "Dean Schulze" >: > Following the example in the man page if I do > > proj +proj=utm +lon_0=112w +ellps=clrk66 -r man.page.lat.lon.txt > > where the file man.page.lat.lon.txt contains > > 45d15'33.1" 111.5W > 45d15.551666667N -111d30 > +45.25919444444 111d30'000w > > I get the 3 lines of output shown in the man page: > > 460769.27 5011648.45 > 460769.27 5011648.45 > 460769.27 5011648.45 > > So far, so good. But when I try to use invproj to get back the original inputs the results are not even close to the inputs: > > proj +proj=utm +lon_0=112w +ellps=clrk66 -r man.page.lat.lon.txt | invproj +proj=utm +lon_0=112w +ellps=clrk66 -r > > gives > > 73d25'28.89"W 3d18'2.678"N > 73d25'28.89"W 3d18'2.678"N > 73d25'28.89"W 3d18'2.678"N > > What is invproj giving me? How do I run invproj to get back my original inputs? > You have missed the lon_0 in invproj, so it takes it to Greenwich. HTH, Andr? Joost From dschulze at wirelessseismic.com Tue May 17 17:15:29 2016 From: dschulze at wirelessseismic.com (Dean Schulze) Date: Tue, 17 May 2016 22:15:29 +0000 Subject: [Proj] Using invproj to get back the inputs to proj In-Reply-To: References: <05D3156E14665542AF857A27B23CFA1BA146D7@mbx026-w1-ca-4.exch026.domain.local>, <05D3156E14665542AF857A27B23CFA1BA1475B@mbx026-w1-ca-4.exch026.domain.local>, Message-ID: <05D3156E14665542AF857A27B23CFA1BA147D4@mbx026-w1-ca-4.exch026.domain.local> Thanks Andre. Leaving off the lon_0 was the problem. ________________________________________ From: proj-bounces at lists.maptools.org [proj-bounces at lists.maptools.org] on behalf of Andre Joost [andre+joost at nurfuerspam.de] Sent: Tuesday, May 17, 2016 12:09 PM To: proj at lists.maptools.org Subject: Re: [Proj] Using invproj to get back the inputs to proj Am 17.05.2016 um 16:54 schrieb Dean Schulze: > Leaving off the -r on invproj gives me back the correct latitude, but the longitude is even worse: > > $ proj +proj=utm +lon_0=112w +ellps=clrk66 -r man.page.lat.lon.txt | invproj +proj=utm +ellps=clrk66 > # proj +proj=utm +lon_0=112w +ellps=clrk66 -r man.page.lat.lon.txt > # Should give > # 460769.27 5011648.45 > 3d30'W 45d15'33.1"N > 3d30'W 45d15'33.1"N > 3d30'W 45d15'33.1"N > > > ________________________________________ > From: proj-bounces at lists.maptools.org [proj-bounces at lists.maptools.org] on behalf of Thomas Knudsen [knudsen.thomas at gmail.com] > Sent: Monday, May 16, 2016 11:59 PM > To: PROJ. 4 and general Projections Discussions > Subject: Re: [Proj] Using invproj to get back the inputs to proj > > Try to leave out the -r option in invproj: the output of proj, that you feed into invproj is not in reverse order. > > Also, do not expect identical output, especially not for data points far off the central meridian. > > /Thomas > > Den 16. maj 2016 19.26 skrev "Dean Schulze" >: > Following the example in the man page if I do > > proj +proj=utm +lon_0=112w +ellps=clrk66 -r man.page.lat.lon.txt > > where the file man.page.lat.lon.txt contains > > 45d15'33.1" 111.5W > 45d15.551666667N -111d30 > +45.25919444444 111d30'000w > > I get the 3 lines of output shown in the man page: > > 460769.27 5011648.45 > 460769.27 5011648.45 > 460769.27 5011648.45 > > So far, so good. But when I try to use invproj to get back the original inputs the results are not even close to the inputs: > > proj +proj=utm +lon_0=112w +ellps=clrk66 -r man.page.lat.lon.txt | invproj +proj=utm +lon_0=112w +ellps=clrk66 -r > > gives > > 73d25'28.89"W 3d18'2.678"N > 73d25'28.89"W 3d18'2.678"N > 73d25'28.89"W 3d18'2.678"N > > What is invproj giving me? How do I run invproj to get back my original inputs? > You have missed the lon_0 in invproj, so it takes it to Greenwich. HTH, Andr? Joost _______________________________________________ Proj mailing list Proj at lists.maptools.org http://lists.maptools.org/mailman/listinfo/proj From jagoncal at gmail.com Tue May 17 18:03:55 2016 From: jagoncal at gmail.com (=?UTF-8?Q?Jose_Gon=C3=A7alves?=) Date: Wed, 18 May 2016 00:03:55 +0100 Subject: [Proj] Using invproj to get back the inputs to proj In-Reply-To: <05D3156E14665542AF857A27B23CFA1BA147D4@mbx026-w1-ca-4.exch026.domain.local> References: <05D3156E14665542AF857A27B23CFA1BA146D7@mbx026-w1-ca-4.exch026.domain.local> <05D3156E14665542AF857A27B23CFA1BA1475B@mbx026-w1-ca-4.exch026.domain.local> <05D3156E14665542AF857A27B23CFA1BA147D4@mbx026-w1-ca-4.exch026.domain.local> Message-ID: Hi When you chose the UTM projection with +proj=utm you should define the zone with +zone=..., and avoid +lon_0. The correct lon_0 of zone 12 is 111w. Regards Jos? Gon?alves 2016-05-17 23:15 GMT+01:00 Dean Schulze : > > Thanks Andre. Leaving off the lon_0 was the problem. > > ________________________________________ > From: proj-bounces at lists.maptools.org [proj-bounces at lists.maptools.org] > on behalf of Andre Joost [andre+joost at nurfuerspam.de] > Sent: Tuesday, May 17, 2016 12:09 PM > To: proj at lists.maptools.org > Subject: Re: [Proj] Using invproj to get back the inputs to proj > > Am 17.05.2016 um 16:54 schrieb Dean Schulze: > > Leaving off the -r on invproj gives me back the correct latitude, but > the longitude is even worse: > > > > $ proj +proj=utm +lon_0=112w +ellps=clrk66 -r man.page.lat.lon.txt | > invproj +proj=utm +ellps=clrk66 > > # proj +proj=utm +lon_0=112w +ellps=clrk66 -r man.page.lat.lon.txt > > # Should give > > # 460769.27 5011648.45 > > 3d30'W 45d15'33.1"N > > 3d30'W 45d15'33.1"N > > 3d30'W 45d15'33.1"N > > > > > > ________________________________________ > > From: proj-bounces at lists.maptools.org [proj-bounces at lists.maptools.org] > on behalf of Thomas Knudsen [knudsen.thomas at gmail.com] > > Sent: Monday, May 16, 2016 11:59 PM > > To: PROJ. 4 and general Projections Discussions > > Subject: Re: [Proj] Using invproj to get back the inputs to proj > > > > Try to leave out the -r option in invproj: the output of proj, that you > feed into invproj is not in reverse order. > > > > Also, do not expect identical output, especially not for data points far > off the central meridian. > > > > /Thomas > > > > Den 16. maj 2016 19.26 skrev "Dean Schulze" < > dschulze at wirelessseismic.com>: > > Following the example in the man page if I do > > > > proj +proj=utm +lon_0=112w +ellps=clrk66 -r man.page.lat.lon.txt > > > > where the file man.page.lat.lon.txt contains > > > > 45d15'33.1" 111.5W > > 45d15.551666667N -111d30 > > +45.25919444444 111d30'000w > > > > I get the 3 lines of output shown in the man page: > > > > 460769.27 5011648.45 > > 460769.27 5011648.45 > > 460769.27 5011648.45 > > > > So far, so good. But when I try to use invproj to get back the original > inputs the results are not even close to the inputs: > > > > proj +proj=utm +lon_0=112w +ellps=clrk66 -r man.page.lat.lon.txt | > invproj +proj=utm +lon_0=112w +ellps=clrk66 -r > > > > gives > > > > 73d25'28.89"W 3d18'2.678"N > > 73d25'28.89"W 3d18'2.678"N > > 73d25'28.89"W 3d18'2.678"N > > > > What is invproj giving me? How do I run invproj to get back my original > inputs? > > > > You have missed the lon_0 in invproj, so it takes it to Greenwich. > > HTH, > Andr? Joost > > > _______________________________________________ > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.maptools.org/pipermail/proj/attachments/20160518/c3b811f5/attachment.htm From mkennedy2 at earthlink.net Tue May 17 23:08:07 2016 From: mkennedy2 at earthlink.net (Melita Kennedy) Date: Tue, 17 May 2016 21:08:07 -0700 (GMT-07:00) Subject: [Proj] Using invproj to get back the inputs to proj Message-ID: <26191614.1463544487516.JavaMail.wam@mswamui-thinleaf.atl.sa.earthlink.net> Your last test is missing the +lon_0=112w parameter so the command is either assuming zone 30 or 31 or that the central meridian/longitude of origin is zero. (I don't have a working copy to check) From dcesari at arpa.emr.it Wed May 18 02:03:05 2016 From: dcesari at arpa.emr.it (Davide Cesari) Date: Wed, 18 May 2016 09:03:05 +0200 Subject: [Proj] Using invproj to get back the inputs to proj In-Reply-To: <05D3156E14665542AF857A27B23CFA1BA1475B@mbx026-w1-ca-4.exch026.domain.local> References: <05D3156E14665542AF857A27B23CFA1BA146D7@mbx026-w1-ca-4.exch026.domain.local>, <05D3156E14665542AF857A27B23CFA1BA1475B@mbx026-w1-ca-4.exch026.domain.local> Message-ID: <573C13A9.60506@arpa.emr.it> Hello Dean, it seems you forgot "+lon_0=112w" in the invproj string, I get the correct result with the following command: echo "45.25919444444 -111.5" | \ proj +proj=utm +lon_0=112w +ellps=clrk66 -r | \ invproj +proj=utm +lon_0=112w +ellps=clrk66 111d30'W 45d15'33.1"N Davide On 17/05/2016 16:54, Dean Schulze wrote: > Leaving off the -r on invproj gives me back the correct latitude, but the longitude is even worse: > > $ proj +proj=m +lon_02w +ellps=clrk66 -r man.page.lat.lon.txt | invproj +proj=utm +ellps=clrk66 > # proj +proj=m +lon_02w +ellps=clrk66 -r man.page.lat.lon.txt > # Should give > # 460769.27 5011648.45 > 3d30'W 45d15'33.1"N > 3d30'W 45d15'33.1"N > 3d30'W 45d15'33.1"N > > > ________________________________________ > From: proj-bounces at lists.maptools.org [proj-bounces at lists.maptools.org] on behalf of Thomas Knudsen [knudsen.thomas at gmail.com] > Sent: Monday, May 16, 2016 11:59 PM > To: PROJ. 4 and general Projections Discussions > Subject: Re: [Proj] Using invproj to get back the inputs to proj > > Try to leave out the -r option in invproj: the output of proj, that you feed into invproj is not in reverse order. > > Also, do not expect identical output, especially not for data points far off the central meridian. > > /Thomas > > Den 16. maj 2016 19.26 skrev "Dean Schulze" >: > Following the example in the man page if I do > > proj +proj=m +lon_02w +ellps=clrk66 -r man.page.lat.lon.txt > > where the file man.page.lat.lon.txt contains > > 45d15'33.1" 111.5W > 45d15.551666667N -111d30 > +45.25919444444 111d30'000w > > I get the 3 lines of output shown in the man page: > > 460769.27 5011648.45 > 460769.27 5011648.45 > 460769.27 5011648.45 > > So far, so good. But when I try to use invproj to get back the original inputs the results are not even close to the inputs: > > proj +proj=m +lon_02w +ellps=clrk66 -r man.page.lat.lon.txt | invproj +proj=utm +lon_02w +ellps=clrk66 -r > > gives > > 73d25'28.89"W 3d18'2.678"N > 73d25'28.89"W 3d18'2.678"N > 73d25'28.89"W 3d18'2.678"N > > What is invproj giving me? How do I run invproj to get back my original inputs? > > Apparently invproj doesn't use command line parameters the same way that proj does. Is this documented somewhere? I've read the 3 .pdfs provides as users manuals, but they say nothing about how to use invproj to get back the original inputs. > > Thanks. > _______________________________________________ > Proj mailing list > Proj at lists.maptools.org > http://lists.maptools.org/mailman/listinfo/proj > -- ============================= Davide Cesari ============================ Dott**(0.5) Davide Cesari Arp? Emilia Romagna, Servizio IdroMeteoClima NWP modelling - Modellistica numerica previsionale Tel. +39 051525926 ======================================================================== From mpasquini at navionics.com Thu May 19 02:12:39 2016 From: mpasquini at navionics.com (Matteo Pasquini) Date: Thu, 19 May 2016 07:12:39 +0000 Subject: [Proj] help Message-ID: Matteo Pasquini OPS - Production Agent Skype :[world_modern_art_29x44] Pasquini.Matteo Mobile: 331-595-8761 [NAV271_NAV+Updates_EmailSig_v5b.jpg] [cid:13DDE468-0357-42D2-B644-AE4A1507679B at home] [cid:D0557F7B-6DD1-4F22-B08E-4AEEFDADC756 at home] [cid:22AC4E59-369F-4951-9B9B-F9C9EE333661 at home] [cid:F9C3FA33-5EC5-4873-A21A-65A9B632BAA0 at home] -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.maptools.org/pipermail/proj/attachments/20160519/a5bbedd4/attachment-0001.htm -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 1093 bytes Desc: image001.png Url : http://lists.maptools.org/pipermail/proj/attachments/20160519/a5bbedd4/attachment-0001.png -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.jpg Type: image/jpeg Size: 5193 bytes Desc: image002.jpg Url : http://lists.maptools.org/pipermail/proj/attachments/20160519/a5bbedd4/attachment-0005.jpg -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.jpg Type: image/jpeg Size: 2366 bytes Desc: image003.jpg Url : http://lists.maptools.org/pipermail/proj/attachments/20160519/a5bbedd4/attachment-0006.jpg -------------- next part -------------- A non-text attachment was scrubbed... Name: image004.jpg Type: image/jpeg Size: 2177 bytes Desc: image004.jpg Url : http://lists.maptools.org/pipermail/proj/attachments/20160519/a5bbedd4/attachment-0007.jpg -------------- next part -------------- A non-text attachment was scrubbed... Name: image005.jpg Type: image/jpeg Size: 1592 bytes Desc: image005.jpg Url : http://lists.maptools.org/pipermail/proj/attachments/20160519/a5bbedd4/attachment-0008.jpg -------------- next part -------------- A non-text attachment was scrubbed... Name: image006.jpg Type: image/jpeg Size: 1605 bytes Desc: image006.jpg Url : http://lists.maptools.org/pipermail/proj/attachments/20160519/a5bbedd4/attachment-0009.jpg From howard at hobu.co Thu May 19 09:12:39 2016 From: howard at hobu.co (Howard Butler) Date: Thu, 19 May 2016 09:12:39 -0500 Subject: [Proj] MACRO modernization Message-ID: <9AE64D0D-3F0C-4069-873B-F0FFE4735E26@hobu.co> All, I just wanted to make you aware of the significant effort that Thomas Knudsen and Kristian Evers have put in to modernize Proj.4's macros and codebase. Along the way, they've increased the code coverage 42%! Three cheers to them! https://github.com/OSGeo/proj.4/pull/373 Howard From even.rouault at spatialys.com Thu May 19 09:55:04 2016 From: even.rouault at spatialys.com (Even Rouault) Date: Thu, 19 May 2016 16:55:04 +0200 Subject: [Proj] MACRO modernization In-Reply-To: <9AE64D0D-3F0C-4069-873B-F0FFE4735E26@hobu.co> References: <9AE64D0D-3F0C-4069-873B-F0FFE4735E26@hobu.co> Message-ID: <201605191655.05360.even.rouault@spatialys.com> Le jeudi 19 mai 2016 16:12:39, Howard Butler a ?crit : > All, > > I just wanted to make you aware of the significant effort that Thomas > Knudsen and Kristian Evers have put in to modernize Proj.4's macros and > codebase. Along the way, they've increased the code coverage 42%! > > Three cheers to them! > > https://github.com/OSGeo/proj.4/pull/373 This is an amazing work indeed ! As far as I can see the increased test coverage comes from pj_XXXXX_selftest() functions added in the file implemented each XXXXX projection method. It seems that by default those selftest functions are compiled, and if PJ_OMIT_SELFTEST is defined they are replaced by a stub. For a "production" build, I'm wondering if we want the selftest to be compiled in the .so, so perhaps the logic should be reversed (and thus in Travis and other integration builds we would define PJ_INCLUDE_SELFTEST) ? Size of libproj.so.11.0.0 (compiled with -O2 and stripped with -s) * sdfe-refactor-macros--and-repair-generic-constructor-bug : 555440 * master : 379920 Even -- Spatialys - Geospatial professional services http://www.spatialys.com From mfinn at usgs.gov Thu May 19 10:06:01 2016 From: mfinn at usgs.gov (Finn, Michael) Date: Thu, 19 May 2016 09:06:01 -0600 Subject: [Proj] Call for Lightning Talks -- Workshop of Open Source Geospatial Technologies Message-ID: *Call for Lightning Talks* *Workshop of Open Source Geospatial Technologies* *At AutoCarto 2016, Albuquerque, New Mexico, USA* 14 September 2016 The ICA Commission on Open Source Geospatial Technologies is holding a one-day workshop on ?*Advancing GIScience with Open Source Technologies*.? AutoCarto 2016 will be held in Albuquerque, New Mexico, USA, 14 ? 16 September 2016 (http://tinyurl.com/p7bpfhp). This workshop at AutoCarto 2016 is a follow-on to the successful AutoCarto 2012 workshop on "The Internet and Geospatial Technologies,? (Columbus, Ohio). AutoCarto is a Cartography and Geographic Information Society (CaGIS) research symposium held every two years. CaGIS is the US adhering body to the International Cartographic Association (ICA). In the morning, invited speakers will give presentations on the workshop topic. In the afternoon, we will have a series of *lightning talks*. These talks will quickly and broadly introduce recent trends and identify future research possibilities in the rapidly expanding domain of open source technologies in the GIScience domain. Further, these talks will identify existing and new researchers and practitioners in the field and open up new collaboration opportunities. Ultimately, these talks and the workshop, as a whole, will provide attendees (and their research or development teams) with a platform for discussing the dramatically changing open source landscape. Please *provide* a proposed talk title (and, if you would like, an expanding sentence or two) and your contact information to: Michael P. Finn U. S. Geological Survey Vice-Chair, ICA Commission on Open Source Geospatial Technologies *mfinn at usgs.gov * * Important Dates:* Proposed Talk Title Submission: *20 June 2016* Acceptance Decision Notification to Submitters: *15 July 2016* Early Registration Deadline: *01 August 2016* Registration: http://tinyurl.com/zl8dadg n Note: Attendees must be registered for AutoCarto 2016. There is no separate or addition fee for the workshop Lightning Talks: *14 September 2016* -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.maptools.org/pipermail/proj/attachments/20160519/d082894f/attachment.htm From mpasquini at navionics.com Thu May 19 15:43:18 2016 From: mpasquini at navionics.com (Matteo Pasquini) Date: Thu, 19 May 2016 20:43:18 +0000 Subject: [Proj] help Message-ID: @HowarButler Ok, here we are. Not trying to not bother you with fifty lines of questions anymore... I'm a Gis tech, not a software developer. I have a lot to give back to Open Source community and for this I'm studying, trying, making errors, rethinking myself to participate and maybe help. I'm interested to help on postgis .. well, next step. Now we have a very uncommon, out of standards, private and not shareable (for now) projections function and ... obviously a lot of problems... Now, in the hope the company will change idea and start to share that function, I've resolved adding a function to the proj.4 and successfully building it. The problem is how distribute this on postgis and qgis in the first place. For what I've understood about postgis I have to get all it's dependencies, (Gdal, Geos ... ) build them one by one while linking my proj.4 version, for all architectures needed ... It is right ? There is a simpler way to do that? or simply I cannot ask this ? Can you point me in the right direction ? Thanks Send by office365 web app -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.maptools.org/pipermail/proj/attachments/20160519/a7bb599b/attachment.htm From kreve at sdfe.dk Fri May 20 04:55:07 2016 From: kreve at sdfe.dk (Kristian Evers) Date: Fri, 20 May 2016 09:55:07 +0000 Subject: [Proj] MACRO modernization In-Reply-To: <201605191655.05360.even.rouault@spatialys.com> References: <9AE64D0D-3F0C-4069-873B-F0FFE4735E26@hobu.co> <201605191655.05360.even.rouault@spatialys.com> Message-ID: <2E885BB293AF0448A0181138489E9A0E793FA4A5@S000014.PROD.SITAD.DK> Thank you, Howard and Even! It's been a lot of work, but it was certainly worth it. We will continue the effort as Thomas already has hinted at in the PR. Regarding the self-test in the shared library. I agree with you, Even, there is no need to clutter the .so unnecessarily. We should find a way to avoid that and your suggestion is without a doubt the easiest way to do that. We implemented the self-tests to ensure that we didn't mess anything up while doing rather extensive code-surgery. As an added bonus we made the self-test callable from the command line via the proj binary. The reason for this is that it might prove useful to users to actually confirm that the application works as intended on their specific setup. Especially on obscure systems not covered by the Travis/Appveyor tests I see this as a nice feature. For the curious, the self-test can be invoked by running "proj -C". Use -VC to get a more verbose test result. I suspect that we will have to work a bit more on the self-test as it only covers 2D-projection at the moment. I will have to think a bit about what the best way to move forward is. I'll share my thoughts with the list once I have a plan. Kristian -----Oprindelig meddelelse----- Fra: proj-bounces at lists.maptools.org [mailto:proj-bounces at lists.maptools.org] P? vegne af Even Rouault Sendt: 19. maj 2016 16:55 Til: proj at lists.maptools.org Emne: Re: [Proj] MACRO modernization Le jeudi 19 mai 2016 16:12:39, Howard Butler a ?crit : > All, > > I just wanted to make you aware of the significant effort that Thomas > Knudsen and Kristian Evers have put in to modernize Proj.4's macros and > codebase. Along the way, they've increased the code coverage 42%! > > Three cheers to them! > > https://github.com/OSGeo/proj.4/pull/373 This is an amazing work indeed ! As far as I can see the increased test coverage comes from pj_XXXXX_selftest() functions added in the file implemented each XXXXX projection method. It seems that by default those selftest functions are compiled, and if PJ_OMIT_SELFTEST is defined they are replaced by a stub. For a "production" build, I'm wondering if we want the selftest to be compiled in the .so, so perhaps the logic should be reversed (and thus in Travis and other integration builds we would define PJ_INCLUDE_SELFTEST) ? Size of libproj.so.11.0.0 (compiled with -O2 and stripped with -s) * sdfe-refactor-macros--and-repair-generic-constructor-bug : 555440 * master : 379920 Even -- Spatialys - Geospatial professional services http://www.spatialys.com _______________________________________________ Proj mailing list Proj at lists.maptools.org http://lists.maptools.org/mailman/listinfo/proj From howard at hobu.co Fri May 20 08:50:19 2016 From: howard at hobu.co (Howard Butler) Date: Fri, 20 May 2016 08:50:19 -0500 Subject: [Proj] Motion: add Kristian Evers and Thomas Knudsen to the Proj.4 team Message-ID: <1697C907-EC23-4F61-B740-0BACEC4C74F8@hobu.co> All, I propose to add Thomas Knudsen and Kristian Evers to the Proj.4 team with commit rights into the OSGeo/Proj.4 repository. They have been leading a modernization effort in the Proj.4 package to improve maintainability, reduce redundancy, and increase test coverage. Thomas has also been a long time Proj.4 list member, and he has provided a lot of experience and guidance on a number of coordinate system and projection topics. Both have been software contributors in a project that has been lacking them, and giving them full access will make it more convenient for them to contribute. I'll start with a +1. Howard From support at mnspoint.com Fri May 20 09:19:32 2016 From: support at mnspoint.com (support at mnspoint.com) Date: Fri, 20 May 2016 17:19:32 +0300 Subject: [Proj] Motion: add Kristian Evers and Thomas Knudsen to the Proj.4 team In-Reply-To: <1697C907-EC23-4F61-B740-0BACEC4C74F8@hobu.co> References: <1697C907-EC23-4F61-B740-0BACEC4C74F8@hobu.co> Message-ID: Hello, Please! "if it works .. don't touch it" -- if you make "huge improvements" label the whole product something ELSE than Proj.4. and don't mix it with the stable version! We don't want to have random rewriters for the code since it does not add anything but more work for us! (... and lot of random errors and problems) Thanks! Janne. ---------------------------------------- Howard Butler kirjoitti 20.05.2016 16:50: > All, > > I propose to add Thomas Knudsen and Kristian Evers to the Proj.4 team > with commit rights into the OSGeo/Proj.4 repository. They have been > leading a modernization effort in the Proj.4 package to improve > maintainability, reduce redundancy, and increase test coverage. Thomas > has also been a long time Proj.4 list member, and he has provided a > lot of experience and guidance on a number of coordinate system and > projection topics. Both have been software contributors in a project > that has been lacking them, and giving them full access will make it > more convenient for them to contribute. > > I'll start with a +1. > > Howard > _______________________________________________ > Proj mailing list > Proj at lists.maptools.org > http://lists.maptools.org/mailman/listinfo/proj -- MNS Support NNS Master Navigator Software Copyright ? Sapper Oy www.mnspoint.com support at mnspoint.com From howard at hobu.co Fri May 20 09:56:45 2016 From: howard at hobu.co (Howard Butler) Date: Fri, 20 May 2016 09:56:45 -0500 Subject: [Proj] Motion: add Kristian Evers and Thomas Knudsen to the Proj.4 team In-Reply-To: References: <1697C907-EC23-4F61-B740-0BACEC4C74F8@hobu.co> Message-ID: <6B76E04A-BB4E-4E51-B113-FCFD527C0E14@hobu.co> > On May 20, 2016, at 9:19 AM, support at mnspoint.com wrote: > > Hello, > > Please! "if it works .. don't touch it" Janne, I'll let them discuss the rationale for their efforts, but I would point out that the converse of your statement is also probably true. "If you don't touch it, it will rot". The two+ years of no Proj.4 releases and backlog of unattended tickets exemplify that. The large ticket backlog is due in part to few people feeling confident enough to make fixes or improvements to the code beyond small tweaks. More confidence is achieved by more automated testing and code pathways that are easier to follow - precisely the types of contributions Thomas and Kristian have been making. Their improvements will make it much easier for people to come in and work in the codebase. They added a large mass of tests to back up changes and protect against future rot. It is also very likely they have lessened the security venerability surface that Proj.4 was providing, though I have no specific proof of that claim other than to say that less complex code generally means fewer pathways to break into. > label the whole product something ELSE than Proj.4. and don't mix it with the stable version! Proj.4 is already a fork, if you'll remember. > We don't want to have random rewriters for the code since it does not add anything but more work for us! (... and lot of random errors and > problems) Do you not have rigorous automated testing to confirm whether or not a new version of a given open source library you are using will cause regressions in your platform? Certainly you use other software beyond Proj.4 that moves much faster than it does, right? There's nothing preventing you from staying with your old(er) version of Proj.4. Howard From richard.greenwood at gmail.com Fri May 20 10:16:49 2016 From: richard.greenwood at gmail.com (Richard Greenwood) Date: Fri, 20 May 2016 09:16:49 -0600 Subject: [Proj] Motion: add Kristian Evers and Thomas Knudsen to the Proj.4 team In-Reply-To: References: <1697C907-EC23-4F61-B740-0BACEC4C74F8@hobu.co> Message-ID: I am not a metacrs nor PROJ.4 PSC member but have worked with PROJ.4 for years. I strongly support the efforts of Thomas Knudsen and Kristian Evers to modernize the code, remove the macros and add test coverage. PROJ.4 needs this to stay relevant, useful and maintainable. Best regards, Rich On Fri, May 20, 2016 at 8:19 AM, wrote: > Hello, > > Please! "if it works .. don't touch it" -- if you make "huge > improvements" label the whole product something ELSE than Proj.4. and > don't mix it with the stable version! > We don't want to have random rewriters for the code since it does not > add anything but more work for us! (... and lot of random errors and > problems) > > Thanks! Janne. > > ---------------------------------------- > > Howard Butler kirjoitti 20.05.2016 16:50: > > All, > > > > I propose to add Thomas Knudsen and Kristian Evers to the Proj.4 team > > with commit rights into the OSGeo/Proj.4 repository. They have been > > leading a modernization effort in the Proj.4 package to improve > > maintainability, reduce redundancy, and increase test coverage. Thomas > > has also been a long time Proj.4 list member, and he has provided a > > lot of experience and guidance on a number of coordinate system and > > projection topics. Both have been software contributors in a project > > that has been lacking them, and giving them full access will make it > > more convenient for them to contribute. > > > > I'll start with a +1. > > > > Howard > > _______________________________________________ > > Proj mailing list > > Proj at lists.maptools.org > > http://lists.maptools.org/mailman/listinfo/proj > > -- > MNS Support > NNS Master Navigator Software > Copyright ? Sapper Oy > www.mnspoint.com > support at mnspoint.com > _______________________________________________ > Proj mailing list > Proj at lists.maptools.org > http://lists.maptools.org/mailman/listinfo/proj -- Richard W. Greenwood, PLS www.greenwoodmap.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.maptools.org/pipermail/proj/attachments/20160520/59308edf/attachment-0001.htm From knudsen.thomas at gmail.com Fri May 20 12:48:38 2016 From: knudsen.thomas at gmail.com (Thomas Knudsen) Date: Fri, 20 May 2016 19:48:38 +0200 Subject: [Proj] Motion: add Kristian Evers and Thomas Knudsen to the Proj.4 team In-Reply-To: References: <1697C907-EC23-4F61-B740-0BACEC4C74F8@hobu.co> Message-ID: Janne, First, I strongly object to being characterized as a ?random rewriter?. I have used proj since 1993, did my first (tiny) contribution to the code base in 1999, and I facilitated the inclusion of the etmerc, high precision transverse mercator code written by my colleague Karsten Engsager, in 2008. It is correct that I have not touched the code base since then, but that does not turn me into a ?random rewriter?. Also, I described my intended work, and asked for comments and opinions on the proj mailing list more than a month ago. It attracted one comment, which was very much in favor of the work. It did not attract any comments from you. Also, the pull request has been open since the beginning of april. Howard Butler, Even Rouault, and Micah Cochran have commented and given constructive criticism. I have seen no comments from you. So all in all, you have had plenty of time to air your opinion. It would have been very helpful if you had done it a bit earlier than 2 months into the process. As a long term proj-list member, I know that you are a frequent and very helpful list contributor, so I have great respect for your experience and willingness to share it, and I believe you could have been a very helpful commenter and mentor for this work. Second: In general I agree with your opinion of ?not touching what works?. However, what ?works? is not easily definable - especially not in the long term. Kristian Evers and I have turned to proj after having spent time updating trlib, the transformation system of the Danish national mapping agency (now SDFE, formerly GST, formerly KMS, formerly GI). trlib originated as Algol code written around 1961, for the GIER system (a, for that time, medium sized computer, which was highly optimized for geodetic computations). The code survived and evolved through more than 5 decades following what was ?current best practice? all along. And the one ?best practice? that has been prevalent through all these decades has been exactly the one you forward here. The problem is that, while commendable for the medium term, for the long term ?not touching what works? leads to kludge-upon-kludge, from bolting on additional functionality, while not touching existing code. In the long term, the ?not touching what works? dogma (NTWW in the following) leads to stale and unmaintainable code. As an example, for trlib, one of the things we have removed during the last few years of code revision, is a complete user-space Virtual Menory mangagement system. It was evidently needed when added to the code around 1970, and left in due to NTWW when the code was migrated from Algol to C around 1980. And kept ever since, due to NTWW. So our experience is very much that NTWW should be challenged now and then. Things change, and so do the hardware platforms the code is supposed to run on. The proj.4 macro system reflects a development environment of Tektronix style, green phosphor 24x80 terminals, where saving vertical whitespace directly translated into a better general view, by having more context on screen at a time. This is not the problem for modern coding tools on modern high-resolution displays. In today?s coding environment the proj internal macro system is a high barrier for entry: It makes it extremely hard for new coders to get productive. If you look at the commit history, you will notice that new people enter the project in order to contribute one or two new projectione that they need. They do not stay to help evolving proj further. I hypothesize that this is at least partially because the macro system is convoluted and not at all C-like (e.g. leading to syntax highlighter blues). My intention was to make the code less impenetrable, in order to make it more welcoming to new contributors. As you will see when you study the code, this has been done without touching the algorithmic flow. The procedure has been designed to enhance the clarity for human readers - not to touch the flow. I suggest you read the description ?A verbose justification for some highly intrusive code surgery? I wrote at the very beginning of this work, over at https://github.com/busstoptaktik/proj.4/blob/sdfe-refactor-macros--and-repair-generic-constructor-bug/src/PJ_minimal.c. Hopefully you will see that I have no intentions to break what works - but at medium time scale intervals, changing what works is necessary in order to keep things in shape. regards Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.maptools.org/pipermail/proj/attachments/20160520/29a630eb/attachment.htm From knudsen.thomas at gmail.com Fri May 20 12:49:29 2016 From: knudsen.thomas at gmail.com (Thomas Knudsen) Date: Fri, 20 May 2016 19:49:29 +0200 Subject: [Proj] Motion: add Kristian Evers and Thomas Knudsen to the Proj.4 team In-Reply-To: References: <1697C907-EC23-4F61-B740-0BACEC4C74F8@hobu.co> Message-ID: Rich, Thank you for the kind words of support for the work done by Kriatian Evers and myself! Needless to say that I very much agree with your opinion :-) /Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.maptools.org/pipermail/proj/attachments/20160520/61384590/attachment.htm From knudsen.thomas at gmail.com Sat May 21 08:42:57 2016 From: knudsen.thomas at gmail.com (Thomas Knudsen) Date: Sat, 21 May 2016 15:42:57 +0200 Subject: [Proj] Motion: add Kristian Evers and Thomas Knudsen to the Proj.4 team In-Reply-To: References: <1697C907-EC23-4F61-B740-0BACEC4C74F8@hobu.co> Message-ID: All, I apologize for reposting this post from yesterday, but it appears that gmail mangled the outgoing text, turning it into an attachment, making the text invisible on many platforms. Hope it works this time - and please ignore if you've already seen this. /Thomas Original post: Janne, First, I strongly object to being characterized as a ?random rewriter?. I have used proj since 1993, did my first (tiny) contribution to the code base in 1999, and I facilitated the inclusion of the etmerc, high precision transverse mercator code written by my colleague Karsten Engsager, in 2008. It is correct that I have not touched the code base since then, but that does not turn me into a ?random rewriter?. Also, I described my intended work, and asked for comments and opinions on the proj mailing list more than a month ago. It attracted one comment, which was very much in favor of the work. It did not attract any comments from you. Also, the pull request has been open since the beginning of april. Howard Butler, Even Rouault, and Micah Cochran have commented and given constructive feedback. I have seen no comments from you. So all in all, you have had plenty of time to air your opinion. It would have been very helpful if you had done it a bit earlier than 2 months into the process. As a long term proj-list member, I know that you are a frequent and very helpful list contributor, so I have great respect for your experience and willingness to share it, and I believe you could have been a very helpful commenter and mentor for this work. Second: In general I agree with your opinion of ?not touching what works?. However, what ?works? is not easily definable - especially not in the long term. Kristian Evers and I have turned to proj after having spent time updating trlib, the transformation system of the Danish national mapping agency (now SDFE, formerly GST, formerly KMS, formerly GI). trlib originated as Algol code written around 1961, for the GIER system (a, for that time, medium sized computer, which was highly optimized for geodetic computations). The code survived and evolved through more than 5 decades following what was ?current best practice? all along. And the one ?best practice? that has been prevalent through all these decades has been exactly the one you forward here. The problem is that, while commendable for the medium term, for the long term ?not touching what works? leads to kludge-upon-kludge, from bolting on additional functionality, while not touching existing code. In the long term, the ?not touching what works? dogma (NTWW in the following) leads to stale and unmaintainable code. As an example, for trlib, one of the things we have removed during the last few years of code revision, is a complete user-space Virtual Menory mangagement system. It was evidently needed when added to the code around 1970, and left in due to NTWW when the code was migrated from Algol to C around 1980. And kept ever since, due to NTWW. So our experience is very much that NTWW should be challenged now and then. Things change, and so do the hardware platforms the code is supposed to run on. The proj.4 macro system reflects a development environment of Tektronix style, green phosphor 24x80 terminals, where saving vertical whitespace directly translated into a better general view, by having more context on screen at a time. This is not the problem for modern coding tools on modern high-resolution displays. In today?s coding environment the proj internal macro system is a high barrier for entry: It makes it extremely hard for new coders to get productive. If you look at the commit history, you will notice that new people enter the project in order to contribute one or two new projections that they need. They do not stay to help evolving proj further. I hypothesize that this is at least partially because the macro system is convoluted and not at all C-like (e.g. leading to syntax highlighter blues). My intention was to make the code less impenetrable, in order to make it more welcoming to new contributors. As you will see when you study the code, this has been done without touching the algorithmic flow. The procedure has been designed to enhance the clarity for human readers - not to touch the flow. I suggest you read the description ?A verbose justification for some highly intrusive code surgery? I wrote at the very beginning of this work, over at https://github.com/busstoptaktik/proj.4/blob/sdfe-refactor-macros--and-repair-generic-constructor-bug/src/PJ_minimal.c. Hopefully you will see that I have no intentions to break what works - but at medium time scale intervals, changing what works is necessary in order to keep things in shape. regards Thomas 2016-05-20 16:19 GMT+02:00 : > Hello, > > Please! "if it works .. don't touch it" -- if you make "huge > improvements" label the whole product something ELSE than Proj.4. and > don't mix it with the stable version! > We don't want to have random rewriters for the code since it does not > add anything but more work for us! (... and lot of random errors and > problems) > > Thanks! Janne. > > ---------------------------------------- > > Howard Butler kirjoitti 20.05.2016 16:50: > > All, > > > > I propose to add Thomas Knudsen and Kristian Evers to the Proj.4 team > > with commit rights into the OSGeo/Proj.4 repository. They have been > > leading a modernization effort in the Proj.4 package to improve > > maintainability, reduce redundancy, and increase test coverage. Thomas > > has also been a long time Proj.4 list member, and he has provided a > > lot of experience and guidance on a number of coordinate system and > > projection topics. Both have been software contributors in a project > > that has been lacking them, and giving them full access will make it > > more convenient for them to contribute. > > > > I'll start with a +1. > > > > Howard > > _______________________________________________ > > Proj mailing list > > Proj at lists.maptools.org > > http://lists.maptools.org/mailman/listinfo/proj > > -- > MNS Support > NNS Master Navigator Software > Copyright ? Sapper Oy > www.mnspoint.com > support at mnspoint.com > _______________________________________________ > Proj mailing list > Proj at lists.maptools.org > http://lists.maptools.org/mailman/listinfo/proj > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.maptools.org/pipermail/proj/attachments/20160521/26770468/attachment-0001.htm From wqyuwss at hotmail.com Mon May 23 09:31:20 2016 From: wqyuwss at hotmail.com (Wang Leslie) Date: Mon, 23 May 2016 14:31:20 +0000 Subject: [Proj] convert from Equidistant Cylindrical to Eckert I Message-ID: Dear all, I'm new to this tool, and hope to get some advise here. I'm thinking to use your tool to convert a map picture which is based on Equidistant Cylindrical, to another picture based on Eckert I. Since both of them are 2 dimension only (x,y), what I'm gonna to do is: - Use proj command to calculate the new mapped coordinate (x1, y1) - Set new pixel value at (x1, y1) using original pixel value (x,y) - loop for all pixel at original Equidistant Cylindrical picture So can you please help me confirm if one idea can work or not? If yes, what should command line look like? Thanks. Best Regards Leslie Qi Wang -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.maptools.org/pipermail/proj/attachments/20160523/0eff4628/attachment.htm From even.rouault at spatialys.com Mon May 23 17:49:43 2016 From: even.rouault at spatialys.com (Even Rouault) Date: Tue, 24 May 2016 00:49:43 +0200 Subject: [Proj] Performance impact of switch of utm to etmerc Message-ID: <201605240049.44176.even.rouault@spatialys.com> Hi, I've given a try with proj master with GDAL, and wanted to assess the performance impact of utm now using etmerc instead of tmerc. Given a in.tif raster of 5000x5000 pixels in EPSG:3857, I did : $ time gdalwarp in.tif out.tif -t_srs EPSG:32611 -overwrite -et 0 -q This runs in 18.1 s. With proj 4.9.2, the same runs in 13.6 s EPSG:32611 is resolved by GDAL as "+proj=utm +zone=11 +ellps=WGS84 +units=m +no_defs" I added explicitly -et 0 so that the exact transformer of GDAL is used, meaning that 5042x5019 inverse projections will be done (number of pixels of output dataset). By default GDAL would use an approximate linear interpolation transformer leading to very few transformations, and the time spent in proj is then almost neglectable. But with -et 0, reprojection work becomes really significant. It should be noted that -et 0 is the default if doing RPC transformation with a DEM since GDAL 2.1.0 (since DEM have no nice regularity, an approximate interpolator can do really bad guesses in mountain areas), and this will probably the use case mostly affected by this. To come back to previous performance, I've added in GDAL the possibility to define the OSR_USE_ETMERC=NO configuration option/environment variable so that "+proj=utm" is expanded to the appropriate "+proj=tmerc ...." Best regards, Even -- Spatialys - Geospatial professional services http://www.spatialys.com From strebe at aol.com Tue May 24 02:05:32 2016 From: strebe at aol.com (strebe at aol.com) Date: Tue, 24 May 2016 03:05:32 -0400 Subject: [Proj] convert from Equidistant Cylindrical to Eckert I In-Reply-To: References: Message-ID: <154e1953462-2220-d607@webprd-m96.mail.aol.com> Hello Leslie. Your procedure will work. The results will be heavily aliased, which will look like speckling. Some values of (x?, y?) will be empty unless the destination map is considerably smaller than the source image. Regards, ? daan Strebe -----Original Message----- From: Wang Leslie To: proj Sent: Mon, May 23, 2016 7:37 am Subject: [Proj] convert from Equidistant Cylindrical to Eckert I Dear all, I'm new to this tool, and hope to get some advise here. I'm thinking to use your tool to convert a map picture which is based on Equidistant Cylindrical, to another picture based on Eckert I. Since both of them are 2 dimension only (x,y), what I'm gonna to do is: - Use proj command to calculate the new mapped coordinate (x1, y1) - Set new pixel value at (x1, y1) using original pixel value (x,y) - loop for all pixel at original Equidistant Cylindrical picture So can you please help me confirm if one idea can work or not? If yes, what should command line look like? Thanks. Best Regards Leslie Qi Wang _______________________________________________ Proj mailing list Proj at lists.maptools.org http://lists.maptools.org/mailman/listinfo/proj -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.maptools.org/pipermail/proj/attachments/20160524/fecfba14/attachment.htm From nhv at cape.com Tue May 24 02:20:14 2016 From: nhv at cape.com (Norman Vine) Date: Tue, 24 May 2016 03:20:14 -0400 Subject: [Proj] convert from Equidistant Cylindrical to Eckert I In-Reply-To: <154e1953462-2220-d607@webprd-m96.mail.aol.com> References: <154e1953462-2220-d607@webprd-m96.mail.aol.com> Message-ID: Hello Leslie I suggest using http://www.gdal.org/gdalwarp.html todo this To avoid the speckling that Daan mentions you want to loop over the new image pixels and do the inverse projection to find the pixel value in the original image gdalwarp takes care of this for you and is built on top of the proj library Norman > On May 24, 2016, at 3:05 AM, strebe at aol.com wrote: > > Hello Leslie. > > Your procedure will work. The results will be heavily aliased, which will look like speckling. Some values of (x?, y?) will be empty unless the destination map is considerably smaller than the source image. > > Regards, > ? daan Strebe > > > > -----Original Message----- > From: Wang Leslie > To: proj > Sent: Mon, May 23, 2016 7:37 am > Subject: [Proj] convert from Equidistant Cylindrical to Eckert I > > Dear all, > > I'm new to this tool, and hope to get some advise here. > > I'm thinking to use your tool to convert a map picture which is based on Equidistant Cylindrical, to another picture based on Eckert I. Since both of them are 2 dimension only (x,y), what I'm gonna to do is: > - Use proj command to calculate the new mapped coordinate (x1, y1) > - Set new pixel value at (x1, y1) using original pixel value (x,y) > - loop for all pixel at original Equidistant Cylindrical picture > > So can you please help me confirm if one idea can work or not? If yes, what should command line look like? Thanks. > > Best Regards > Leslie Qi Wang > _______________________________________________ > 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 From wqyuwss at hotmail.com Tue May 24 17:16:44 2016 From: wqyuwss at hotmail.com (Wang Leslie) Date: Tue, 24 May 2016 22:16:44 +0000 Subject: [Proj] convert from Equidistant Cylindrical to Eckert I In-Reply-To: References: <154e1953462-2220-d607@webprd-m96.mail.aol.com>, Message-ID: Hi Norman, Dann, Thanks for quick reply. It would be highly appreciated for one sample command on these tools to achieve my goal. Best Regards Leslie ________________________________________ From: proj-bounces at lists.maptools.org on behalf of Norman Vine Sent: Tuesday, May 24, 2016 7:20 AM To: PROJ.4 and general Projections Discussions Subject: Re: [Proj] convert from Equidistant Cylindrical to Eckert I Hello Leslie I suggest using http://www.gdal.org/gdalwarp.html todo this To avoid the speckling that Daan mentions you want to loop over the new image pixels and do the inverse projection to find the pixel value in the original image gdalwarp takes care of this for you and is built on top of the proj library Norman > On May 24, 2016, at 3:05 AM, strebe at aol.com wrote: > > Hello Leslie. > > Your procedure will work. The results will be heavily aliased, which will look like speckling. Some values of (x?, y?) will be empty unless the destination map is considerably smaller than the source image. > > Regards, > ? daan Strebe > > > > -----Original Message----- > From: Wang Leslie > To: proj > Sent: Mon, May 23, 2016 7:37 am > Subject: [Proj] convert from Equidistant Cylindrical to Eckert I > > Dear all, > > I'm new to this tool, and hope to get some advise here. > > I'm thinking to use your tool to convert a map picture which is based on Equidistant Cylindrical, to another picture based on Eckert I. Since both of them are 2 dimension only (x,y), what I'm gonna to do is: > - Use proj command to calculate the new mapped coordinate (x1, y1) > - Set new pixel value at (x1, y1) using original pixel value (x,y) > - loop for all pixel at original Equidistant Cylindrical picture > > So can you please help me confirm if one idea can work or not? If yes, what should command line look like? Thanks. > > Best Regards > Leslie Qi Wang > _______________________________________________ > 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 _______________________________________________ Proj mailing list Proj at lists.maptools.org http://lists.maptools.org/mailman/listinfo/proj From wqyuwss at hotmail.com Tue May 24 17:30:29 2016 From: wqyuwss at hotmail.com (Wang Leslie) Date: Tue, 24 May 2016 22:30:29 +0000 Subject: [Proj] which Cylindrical projection has smallest area Message-ID: Dear all, https://en.wikipedia.org/wiki/List_of_map_projections#Table_of_projections lists so many different Cylindrical projection. I guess different projection should generate different dimensions. If yes, can you please tell me which one has smallest area (width multiply height)? And also how about 1) Guyou hemisphere-in-a-square projection; 2) Adams hemisphere-in-a-square projection; 3) Eckert II, which are not Cylindrical projection, but still have polygon shape. Best Regards Leslie -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.maptools.org/pipermail/proj/attachments/20160524/f696c47d/attachment.htm From jagoncal at gmail.com Tue May 24 18:03:02 2016 From: jagoncal at gmail.com (=?UTF-8?Q?Jose_Gon=C3=A7alves?=) Date: Wed, 25 May 2016 00:03:02 +0100 Subject: [Proj] convert from Equidistant Cylindrical to Eckert I In-Reply-To: References: <154e1953462-2220-d607@webprd-m96.mail.aol.com> Message-ID: Hi You can transform your image with the following command line: gdalwarp -s_srs "+ellps=WGS84 +proj=eqd" -t_srs "+ellps=WGS84 +proj=eck1" in.tif out.tif The input image must be georeferenced in the equidistant cylindrical projection, with units in meters. See page http://www.gdal.org/gdalwarp.html. Other important options are -r, -te and -tr. Regards Jos? Gon?alves 2016-05-24 23:16 GMT+01:00 Wang Leslie : > Hi Norman, Dann, > > Thanks for quick reply. It would be highly appreciated for one sample > command on these tools to achieve my goal. > > Best Regards > Leslie > > ________________________________________ > From: proj-bounces at lists.maptools.org > on behalf of Norman Vine > Sent: Tuesday, May 24, 2016 7:20 AM > To: PROJ.4 and general Projections Discussions > Subject: Re: [Proj] convert from Equidistant Cylindrical to Eckert I > > Hello Leslie > > I suggest using http://www.gdal.org/gdalwarp.html todo this > > To avoid the speckling that Daan mentions you want to loop over the new > image > pixels and do the inverse projection to find the pixel value in the > original image > > gdalwarp takes care of this for you and is built on top of the proj library > > Norman > > > On May 24, 2016, at 3:05 AM, strebe at aol.com wrote: > > > > Hello Leslie. > > > > Your procedure will work. The results will be heavily aliased, which > will look like speckling. Some values of (x?, y?) will be empty unless the > destination map is considerably smaller than the source image. > > > > Regards, > > ? daan Strebe > > > > > > > > -----Original Message----- > > From: Wang Leslie > > To: proj > > Sent: Mon, May 23, 2016 7:37 am > > Subject: [Proj] convert from Equidistant Cylindrical to Eckert I > > > > Dear all, > > > > I'm new to this tool, and hope to get some advise here. > > > > I'm thinking to use your tool to convert a map picture which is based on > Equidistant Cylindrical, to another picture based on Eckert I. Since both > of them are 2 dimension only (x,y), what I'm gonna to do is: > > - Use proj command to calculate the new mapped coordinate (x1, y1) > > - Set new pixel value at (x1, y1) using original pixel value (x,y) > > - loop for all pixel at original Equidistant Cylindrical picture > > > > So can you please help me confirm if one idea can work or not? If yes, > what should command line look like? Thanks. > > > > Best Regards > > Leslie Qi Wang > > _______________________________________________ > > 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 > > _______________________________________________ > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.maptools.org/pipermail/proj/attachments/20160525/2a973b28/attachment.htm From wqyuwss at hotmail.com Tue May 24 18:34:08 2016 From: wqyuwss at hotmail.com (Wang Leslie) Date: Tue, 24 May 2016 23:34:08 +0000 Subject: [Proj] convert from Equidistant Cylindrical to Eckert I In-Reply-To: References: <154e1953462-2220-d607@webprd-m96.mail.aol.com> , Message-ID: Hi Jose, Thanks for the quick reply. What do you mean "be geo-referenced"? What I'm thinking is to use these tools to convert a 360 panorama picture, such as https://upload.wikimedia.org/wikipedia/commons/3/35/Space_Needle_360_Panorama.jpg, which is an equidistant cylindrical projection, to other type of projection, which keeps same quality but with smaller size. Thus I can save some storage spaces. In this case, these 360 picture doesn't have any geo-referenced data. Can I still use these tools? [https://upload.wikimedia.org/wikipedia/commons/3/35/Space_Needle_360_Panorama.jpg] ________________________________ From: proj-bounces at lists.maptools.org on behalf of Jose Gon?alves Sent: Tuesday, May 24, 2016 11:03 PM To: PROJ.4 and general Projections Discussions Subject: Re: [Proj] convert from Equidistant Cylindrical to Eckert I Hi You can transform your image with the following command line: gdalwarp -s_srs "+ellps=WGS84 +proj=eqd" -t_srs "+ellps=WGS84 +proj=eck1" in.tif out.tif The input image must be georeferenced in the equidistant cylindrical projection, with units in meters. See page http://www.gdal.org/gdalwarp.html. Other important options are -r, -te and -tr. GDAL: gdalwarp www.gdal.org image reprojection and warping utility. SYNOPSIS. Usage: gdalwarp [--help-general] [--formats] [-s_srs srs_def] [-t_srs srs_def] [-to "NAME=VALUE"] [-order n | -tps ... Regards Jos? Gon?alves 2016-05-24 23:16 GMT+01:00 Wang Leslie >: Hi Norman, Dann, Thanks for quick reply. It would be highly appreciated for one sample command on these tools to achieve my goal. Best Regards Leslie ________________________________________ From: proj-bounces at lists.maptools.org > on behalf of Norman Vine > Sent: Tuesday, May 24, 2016 7:20 AM To: PROJ.4 and general Projections Discussions Subject: Re: [Proj] convert from Equidistant Cylindrical to Eckert I Hello Leslie I suggest using http://www.gdal.org/gdalwarp.html todo this To avoid the speckling that Daan mentions you want to loop over the new image pixels and do the inverse projection to find the pixel value in the original image gdalwarp takes care of this for you and is built on top of the proj library Norman > On May 24, 2016, at 3:05 AM, strebe at aol.com wrote: > > Hello Leslie. > > Your procedure will work. The results will be heavily aliased, which will look like speckling. Some values of (x?, y?) will be empty unless the destination map is considerably smaller than the source image. > > Regards, > - daan Strebe > > > > -----Original Message----- > From: Wang Leslie > > To: proj > > Sent: Mon, May 23, 2016 7:37 am > Subject: [Proj] convert from Equidistant Cylindrical to Eckert I > > Dear all, > > I'm new to this tool, and hope to get some advise here. > > I'm thinking to use your tool to convert a map picture which is based on Equidistant Cylindrical, to another picture based on Eckert I. Since both of them are 2 dimension only (x,y), what I'm gonna to do is: > - Use proj command to calculate the new mapped coordinate (x1, y1) > - Set new pixel value at (x1, y1) using original pixel value (x,y) > - loop for all pixel at original Equidistant Cylindrical picture > > So can you please help me confirm if one idea can work or not? If yes, what should command line look like? Thanks. > > Best Regards > Leslie Qi Wang > _______________________________________________ > 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 _______________________________________________ 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.maptools.org/pipermail/proj/attachments/20160524/2d3085c1/attachment-0001.htm From strebe at aol.com Tue May 24 18:54:20 2016 From: strebe at aol.com (strebe at aol.com) Date: Tue, 24 May 2016 16:54:20 -0700 Subject: [Proj] convert from Equidistant Cylindrical to Eckert I In-Reply-To: References: <154e1953462-2220-d607@webprd-m96.mail.aol.com> Message-ID: <243B7268-43AA-4D7C-9D37-0295EF86DA03@aol.com> Hello Leslie. You cannot magically preserve information by reprojecting it. That can only lose information. You would get much better results just using standard image editing applications to scale the image down. Regards, ? daan Strebe > On May 24, 2016, at 16:34, Wang Leslie wrote: > > Hi Jose, > > > Thanks for the quick reply. > > > What do you mean "be geo-referenced"? What I'm thinking is to use these tools to convert a 360 panorama picture, such as https://upload.wikimedia.org/wikipedia/commons/3/35/Space_Needle_360_Panorama.jpg, which is an equidistant cylindrical projection, to other type of projection, which keeps same quality but with smaller size. Thus I can save some storage spaces. In this case, these 360 picture doesn't have any geo-referenced data. Can I still use these tools? > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.maptools.org/pipermail/proj/attachments/20160524/dbe8d163/attachment.htm From jagoncal at gmail.com Wed May 25 06:51:21 2016 From: jagoncal at gmail.com (=?UTF-8?Q?Jose_Gon=C3=A7alves?=) Date: Wed, 25 May 2016 12:51:21 +0100 Subject: [Proj] convert from Equidistant Cylindrical to Eckert I In-Reply-To: References: <154e1953462-2220-d607@webprd-m96.mail.aol.com> Message-ID: An image is georeferenced if there is some form of associating pixel positions (row, column) to geolocation, in geographic or cartographic coordinates. Proj, or any other program that uses proj, needs that to apply map projection formulas In your case you must simulate that your image is georeferenced, giving it an extent of 360 degrees in longitude (row) and some proportional extent in latitude (column). Regards Jose 2016-05-25 0:34 GMT+01:00 Wang Leslie : > Hi Jose, > > > Thanks for the quick reply. > > > What do you mean "be geo-referenced"? What I'm thinking is to use these > tools to convert a 360 panorama picture, such as > https://upload.wikimedia.org/wikipedia/commons/3/35/Space_Needle_360_Panorama.jpg, > which is an equidistant cylindrical projection, to other type of > projection, which keeps same quality but with smaller size. Thus I can save > some storage spaces. In this case, these 360 picture doesn't have any > geo-referenced data. Can I still use these tools? > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.maptools.org/pipermail/proj/attachments/20160525/cb19f8fa/attachment.htm From wqyuwss at hotmail.com Wed May 25 11:27:08 2016 From: wqyuwss at hotmail.com (Wang Leslie) Date: Wed, 25 May 2016 16:27:08 +0000 Subject: [Proj] convert from Equidistant Cylindrical to Eckert I In-Reply-To: References: <154e1953462-2220-d607@webprd-m96.mail.aol.com> , Message-ID: I thought this association is standard. In other words, given the size of one image and type of cylindrical projection, each pixel should be associated to correct (longitude, latitude) at sphere. My assumption is the image is assumed to unwrap the complete sphere. Best Regards Leslie ________________________________ From: proj-bounces at lists.maptools.org on behalf of Jose Gon?alves Sent: Wednesday, May 25, 2016 11:51 AM To: PROJ.4 and general Projections Discussions Subject: Re: [Proj] convert from Equidistant Cylindrical to Eckert I An image is georeferenced if there is some form of associating pixel positions (row, column) to geolocation, in geographic or cartographic coordinates. Proj, or any other program that uses proj, needs that to apply map projection formulas In your case you must simulate that your image is georeferenced, giving it an extent of 360 degrees in longitude (row) and some proportional extent in latitude (column). Regards Jose 2016-05-25 0:34 GMT+01:00 Wang Leslie >: Hi Jose, Thanks for the quick reply. What do you mean "be geo-referenced"? What I'm thinking is to use these tools to convert a 360 panorama picture, such as https://upload.wikimedia.org/wikipedia/commons/3/35/Space_Needle_360_Panorama.jpg, which is an equidistant cylindrical projection, to other type of projection, which keeps same quality but with smaller size. Thus I can save some storage spaces. In this case, these 360 picture doesn't have any geo-referenced data. Can I still use these tools? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.maptools.org/pipermail/proj/attachments/20160525/2ccd4ce1/attachment.htm From mcochran at athensal.us Tue May 31 13:49:41 2016 From: mcochran at athensal.us (Micah Cochran) Date: Tue, 31 May 2016 13:49:41 -0500 Subject: [Proj] Changing Math Constants Message-ID: This is my attempt to put the math constants into M_ namespace, and when possible use the compiler to define those constants. I opened PR #387 https://github.com/OSGeo/proj.4/pull/387 This is similar to an earlier PR that I had opened. So, I'm looking for any comments about this change. Thank you, Micah -- *Micah Cochran* GIS Coordinator - City of Athens - Engineering Services & Community Development Dept. - Dept. of Public Works Building - 1600 ELM ST W, Athens, AL - geo:34.820608,-86.991474 - p. 256-233-2224 - f. 256-233-8791 - www.athensalabama.us -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.maptools.org/pipermail/proj/attachments/20160531/14f05310/attachment.htm