From halfhaggis at gmail.com Fri Aug 8 13:10:11 2008 From: halfhaggis at gmail.com (Neil Robinson) Date: Fri Aug 8 13:10:17 2008 Subject: [Proj] Transverse Mercator south-oriented projection support? Message-ID: <62b0eae70808081010t12874dd1te90c355af704a4d@mail.gmail.com> Hi there, Any idea whether there are plans to implement this stuff: http://lists.maptools.org/pipermail/proj/2000-September/000099.html Or is there a work-around I could use? I would greatly appreciate being able to use this projection in my work with qgis. Thanks, -- Neil Robinson -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.maptools.org/pipermail/proj/attachments/20080808/92f0f9c8/attachment.html From geraldi.evenden at gmail.com Fri Aug 8 16:49:58 2008 From: geraldi.evenden at gmail.com (Gerald I. Evenden) Date: Fri Aug 8 16:50:06 2008 Subject: [Proj] Transverse Mercator south-oriented projection support? In-Reply-To: <62b0eae70808081010t12874dd1te90c355af704a4d@mail.gmail.com> References: <62b0eae70808081010t12874dd1te90c355af704a4d@mail.gmail.com> Message-ID: <200808081649.58507.geraldi.evenden@gmail.com> On Friday 08 August 2008 1:10:11 pm Neil Robinson wrote: > Hi there, > > Any idea whether there are plans to implement this stuff: > http://lists.maptools.org/pipermail/proj/2000-September/000099.html > > Or is there a work-around I could use? > > I would greatly appreciate being able to use this projection in my work > with qgis. > > Thanks, Groan! There is no need to modify the library routines as all that is needed is to switch around the x-y and signs of the lat-lons. I would just use +proj=tmerc and put some added '-' flags to juggle the I/O. But that's somebody else's job as I only work on the library. ;-) -- The whole religious complexion of the modern world is due to the absence from Jerusalem of a lunatic asylum. -- Havelock Ellis (1859-1939) British psychologist From halfhaggis at gmail.com Mon Aug 11 04:07:58 2008 From: halfhaggis at gmail.com (Neil Robinson) Date: Mon Aug 11 04:08:03 2008 Subject: [Proj] Re: Proj Digest, Vol 51, Issue 2 In-Reply-To: <200808091601.m79G1YiH028272@duke.maptools.org> References: <200808091601.m79G1YiH028272@duke.maptools.org> Message-ID: <62b0eae70808110107q4c0cb8c8tb39c1ffbfdc5257d@mail.gmail.com> Hi Gerard, Thanks for your response. I realise that this isn't a support forum, but I'm not getting any joy anywhere else and you are clearly very knowledgeable on this topic On Sat, Aug 9, 2008 at 6:01 PM, wrote: > Send Proj mailing list submissions to > proj@lists.maptools.org > > Message: 2 > Date: Fri, 8 Aug 2008 16:49:58 -0400 > From: "Gerald I. Evenden" > Subject: Re: [Proj] Transverse Mercator south-oriented projection > support? > To: "PROJ.4 and general Projections Discussions" > > Message-ID: <200808081649.58507.geraldi.evenden@gmail.com> > Content-Type: text/plain; charset="utf-8" > > Groan! Is this a bit of a recurring nightmare for you? Sorry about that. > > There is no need to modify the library routines as all that is needed is to > switch around the x-y and signs of the lat-lons. I tried lodging a bug with qgis [1], but they seemed to think the problem was with proj4 (although, through my ignorance that was my guess, so I might have planted the seed of that conclusion). > > > I would just use +proj=tmerc and put some added '-' flags to juggle the > I/O. > But that's somebody else's job as I only work on the library. ;-) I tried this suggestion (I think I did), but negative zero doesn't make any sense to proj4. Without adding the '-' flags, this is what I think the parameters need to be for one of the projections I'm interested in: +proj=tmerc +ellps=WGS84 +lat_0 +lon_29 +k=1 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs Is it defined more fully on spatialreference.org[2]. You'll note that spatialreference.org doesn't have a proj4 definition. If the library isn't the right place to look for a solution to this, where is? Thanks for your time. I'm sure this is a pain for you. I hope any additional groaning will not be too severe. [1] https://trac.osgeo.org/qgis/ticket/1176 [2]http://spatialreference.org/ref/epsg/2053/ -- Neil Robinson -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.maptools.org/pipermail/proj/attachments/20080811/7893880d/attachment.html From geraldi.evenden at gmail.com Mon Aug 11 10:36:52 2008 From: geraldi.evenden at gmail.com (Gerald I. Evenden) Date: Mon Aug 11 10:37:00 2008 Subject: [Proj] Re: Proj Digest, Vol 51, Issue 2 In-Reply-To: <62b0eae70808110107q4c0cb8c8tb39c1ffbfdc5257d@mail.gmail.com> References: <200808091601.m79G1YiH028272@duke.maptools.org> <62b0eae70808110107q4c0cb8c8tb39c1ffbfdc5257d@mail.gmail.com> Message-ID: <200808111036.52778.geraldi.evenden@gmail.com> On Monday 11 August 2008 4:07:58 am Neil Robinson wrote: > Hi Gerard, > > Thanks for your response. I realise that this isn't a support forum, but > I'm not getting any joy anywhere else and you are clearly very > knowledgeable on this topic ... > I tried lodging a bug with qgis [1], but they seemed to think the problem > was with proj4 (although, through my ignorance that was my guess, so I > might have planted the seed of that conclusion). > > > I would just use +proj=tmerc and put some added '-' flags to juggle the > > I/O. > > But that's somebody else's job as I only work on the library. ;-) > > I tried this suggestion (I think I did), but negative zero doesn't make any > sense to proj4. > Without adding the '-' flags, this is what I think the parameters need to > be for one of the projections I'm interested in: > > +proj=tmerc +ellps=WGS84 +lat_0 +lon_29 +k=1 +towgs84=0,0,0,0,0,0,0 > +units=m +no_defs Can you give a sample input (lat/lon) and an approximation of what you expect (without datum conversion which I cannot handle). Under normal circumstances the above would generate (viewed as a console screen capture): gie@charon:~$ lproj +proj=tmerc +ellps=WGS84 +lon_0=29 31 45 157693.72 4986890.93 Note; option +towgs84 and +no_defs is not on my software and the other options are defaulted as you explicitly specified. The input is longitude(31), latitude(45) and the output is easting(x) and northing(y) in meters. What output would you prefer to see? -- The whole religious complexion of the modern world is due to the absence from Jerusalem of a lunatic asylum. -- Havelock Ellis (1859-1939) British psychologist From halfhaggis at gmail.com Tue Aug 12 04:09:40 2008 From: halfhaggis at gmail.com (Neil Robinson) Date: Tue Aug 12 04:09:53 2008 Subject: [Proj] Re: Proj Digest, Vol 51, Issue 2 In-Reply-To: <200808111036.52778.geraldi.evenden@gmail.com> References: <200808091601.m79G1YiH028272@duke.maptools.org> <62b0eae70808110107q4c0cb8c8tb39c1ffbfdc5257d@mail.gmail.com> <200808111036.52778.geraldi.evenden@gmail.com> Message-ID: <48A14544.3010801@gmail.com> An HTML attachment was scrubbed... URL: http://lists.maptools.org/pipermail/proj/attachments/20080812/577bec04/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: halfhaggis.vcf Type: text/x-vcard Size: 197 bytes Desc: not available Url : http://lists.maptools.org/pipermail/proj/attachments/20080812/577bec04/halfhaggis.vcf From plieger at knmi.nl Tue Aug 12 05:08:39 2008 From: plieger at knmi.nl (Maarten Plieger) Date: Tue Aug 12 05:08:45 2008 Subject: [Proj] From proj4 string to EPSG code Message-ID: <48A15317.20405@knmi.nl> Hi, Is there a simple way to convert from a proj4 string to an EPSG code? My proj4 string has the same format as the strings in the epsg definition file. Regards, Maarten Plieger -- Maarten Plieger KNMI, R&D Information and Observation Technology, De Bilt (t) +31 30 2206330 From glynn at gclements.plus.com Tue Aug 12 07:04:59 2008 From: glynn at gclements.plus.com (Glynn Clements) Date: Tue Aug 12 07:05:04 2008 Subject: [Proj] From proj4 string to EPSG code In-Reply-To: <48A15317.20405@knmi.nl> References: <48A15317.20405@knmi.nl> Message-ID: <18593.28251.99776.435698@cerise.gclements.plus.com> Maarten Plieger wrote: > Is there a simple way to convert from a proj4 string to an EPSG code? > My proj4 string has the same format as the strings in the epsg > definition file. If the format is identical in every regard, you could just "grep" for the string then extract the code from the output. But it would be more robust to parse each line and check that the key/value pairs match. Even then, there's the possibility that some floating-point value (e.g. the ellipsoid radius) won't match exactly e.g. due to trailing zeroes or some negligible difference in value. Other than the last issue, the following python script will do the job: #!/usr/bin/env python import sys myparms = sorted(sys.argv[1:]) # use this instead if you want one argument rather than many: # myparms = sorted(sys.argv[1].split()) f = file("/usr/share/proj/epsg") for line in f: if line.startswith("#"): continue l = line.split() code = l[0].strip("<>") parms = l[1:-1] if sorted(parms) == myparms: print code break f.close() Example usage: $ ./epsg.py +proj=tmerc +lat_0=49 +lon_0=-2 +k=0.999601 +x_0=400000 +y_0=-100000 +ellps=airy +units=m +no_defs 27700 If you need to handle the precision issues, things get more complicated. -- Glynn Clements From joeri.theelen at arts.kuleuven.be Tue Aug 12 08:40:26 2008 From: joeri.theelen at arts.kuleuven.be (joeri.theelen) Date: Tue Aug 12 08:40:31 2008 Subject: [Proj] PROJ.4 and local coordinate systems Message-ID: <18943556.post@talk.nabble.com> Hi, Is it possible to use PROJ.4 or any of its related tools to transform coordinates from a local carthesian system into another local carthesian system (thus both are not earth related). I inherit lots of datasets in many different formats for an archaeological site, with coordinates measured in two different local systems (shift in time). I managed to get the transformation parameters to transform sets of coordinates between both systems, with minor error. By transformation, I mean translation, rotation and dilation (scale factor) of the X/Y coordinates only, not height. I also managed to get the transformation parameters from both local systems to the UTM system in use in that area. Thus, transforming from local to UTM to local would be an option as well. Can anybody help me with this? I know programming such a tranformation would be trivial, but I need the power and flexibility of a tool like "cs2cs" to cope with the many different formats I am facing. Thank you, Joeri -- View this message in context: http://www.nabble.com/PROJ.4-and-local-coordinate-systems-tp18943556p18943556.html Sent from the PROJ.4 mailing list archive at Nabble.com. From heather.yager at gmail.com Tue Aug 12 17:01:29 2008 From: heather.yager at gmail.com (Heather M. Yager) Date: Tue Aug 12 17:02:29 2008 Subject: [Proj] installation question: proj_api.h Message-ID: <48A1FA29.9070700@gmail.com> Hi! I don't yet have experience with PROJ4, but I must install it on SuSE in order to run MapServer with projection support. The problem: when I install proj from an RPM (command I used: "yast -i proj-4.4.9-1.guru.suse93.x86_64.rpm") it appears that the installation was successful - I can locate proj, I can type "proj" at the command line (and receive "Rel. 4.4.9, 29 Oct 2004" back). But, when I try to configure MapServer with proj, MapServer cannot locate the file proj_api.h, and when I do a search of the files on my server, I cannot locate proj_api.h either. Should proj_api.h have been created when I installed proj? Is there an installation option that I should include? Should I install it from source instead of an RPM? Any advice is appreciated! Cheers, Heather Yager From neteler at osgeo.org Tue Aug 12 17:52:09 2008 From: neteler at osgeo.org (Markus Neteler) Date: Tue Aug 12 17:52:13 2008 Subject: [Proj] installation question: proj_api.h In-Reply-To: <48A1FA29.9070700@gmail.com> References: <48A1FA29.9070700@gmail.com> Message-ID: <86782b610808121452s6237af9fn7725d8d36f4b304e@mail.gmail.com> Heather, On Tue, Aug 12, 2008 at 11:01 PM, Heather M. Yager wrote: > Hi! > > I don't yet have experience with PROJ4, but I must install it on SuSE in > order to run MapServer with projection support. The problem: when I > install proj from an RPM (command I used: "yast -i > proj-4.4.9-1.guru.suse93.x86_64.rpm") it appears that the installation > was successful - I can locate proj, I can type "proj" at the command > line (and receive "Rel. 4.4.9, 29 Oct 2004" back). You also need to install proj-devel-4.4.9-1.guru.suse93.x86_64.rpm which contains proj_api.h and some more relevant files. Hope this helps, Markus -- Open Source Geospatial Foundation http://www.osgeo.org/ http://www.grassbook.org/ From AWilliams at rapidmap.com Tue Aug 12 22:48:42 2008 From: AWilliams at rapidmap.com (Andrew Williams) Date: Tue Aug 12 22:51:18 2008 Subject: [Proj] Re: Proj Digest, Vol 51, Issue 2 In-Reply-To: <48A14544.3010801@gmail.com> References: <200808091601.m79G1YiH028272@duke.maptools.org> <62b0eae70808110107q4c0cb8c8tb39c1ffbfdc5257d@mail.gmail.com> <200808111036.52778.geraldi.evenden@gmail.com> <48A14544.3010801@gmail.com> Message-ID: <29C3A52E0876C94C97BD6443FA96F73371B50C6A17@rms03.rapidmap.local> Neil, Just chiming in to see if I can assist. Lat Long to UTM is very familiar territory form me. Just looking at your command line these no reason for proj4 to return negative values. For typical UTM projections the standard zones are 6 degrees wide all around the world. Often they are numbered. Increasing East and West from Greenwich eg 0-6 degrees is Zone 1 etc. When using Proj the lon_0 represents the central meridian of a zone. So the lon_0 for Zone 1 is 3. Think of this as the vertical axis of a graph. Lat_0 is typically the equator eg 0 degree. Think of this as the horizontal axis of a graph. Your points fall into Zone 5 between longitudes 24 and 30 in the Northern Hemishpere. So by nominating a lon_0 (correctly) of 27 degrees and by omitting the lat_0 so defaulting to 0 degrees your points fall on the positive/positive quadrant. The formulae that produces UTM will return positive values. Often in the mapping industry we try NOT TO return negative values. The way we do this and is supported by proj4 is the use of false origins. The parameters x_0 and y_0 are used for this purpose. In Australia being South of the equator and using UTM the negative latitudes produce "Northings" and any longitude West of the Central Meridian produces negative "Eastings" To make them positive we define a false origin 10 million metres South of the Central Meridian/Equator(True) origin and 500,000 metres West of the true origin. That way all our Eastings and Northings come out positive. In your case I can't determine why you expect/want negative Eastings, but perhaps the false origin may help. Regards Andrew From: proj-bounces@lists.maptools.org [mailto:proj-bounces@lists.maptools.org] On Behalf Of Neil Robinson Sent: Tuesday, 12 August 2008 6:10 PM To: geraldi.evenden@gmail.com Cc: proj@lists.maptools.org Subject: Re: [Proj] Re: Proj Digest, Vol 51, Issue 2 Dear Gerald, Thanks to your suggestion. In trying to give you a sample of expected output I've tested things more thoroughly (I'm a chemical engineer by training, so this geo-referenced mapping stuff is all new to me) and it does appear to be working correctly -- almost. my input file, "Desktop/proj" had this: 27.5 0.00 27.5 10.0 27.5 20.0 27.5 30.0 27.58676 26.18728 My commands and output from the console: neil@neil:~$ proj +proj=tmerc +ellps=WGS84 +lon_0=27 Desktop/proj 55660.46 0.00 54820.34 1105896.37 52324.06 2212444.34 48243.45 3320218.65 58652.24 2897715.76 In each case, the magnitudes are correct (as far as I can tell using other software) but the first column of values should all be negative. i.e. Desired output: -55660.46 0.00 -54820.34 1105896.37 -52324.06 2212444.34 -48243.45 3320218.65 -58652.24 2897715.76 Gerald I. Evenden wrote: On Monday 11 August 2008 4:07:58 am Neil Robinson wrote: Hi Gerard, Thanks for your response. I realise that this isn't a support forum, but I'm not getting any joy anywhere else and you are clearly very knowledgeable on this topic ... I tried lodging a bug with qgis [1], but they seemed to think the problem was with proj4 (although, through my ignorance that was my guess, so I might have planted the seed of that conclusion). I would just use +proj=tmerc and put some added '-' flags to juggle the I/O. But that's somebody else's job as I only work on the library. ;-) I tried this suggestion (I think I did), but negative zero doesn't make any sense to proj4. Without adding the '-' flags, this is what I think the parameters need to be for one of the projections I'm interested in: +proj=tmerc +ellps=WGS84 +lat_0 +lon_29 +k=1 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs Can you give a sample input (lat/lon) and an approximation of what you expect (without datum conversion which I cannot handle). Under normal circumstances the above would generate (viewed as a console screen capture): gie@charon:~$ lproj +proj=tmerc +ellps=WGS84 +lon_0=29 31 45 157693.72 4986890.93 Note; option +towgs84 and +no_defs is not on my software and the other options are defaulted as you explicitly specified. The input is longitude(31), latitude(45) and the output is easting(x) and northing(y) in meters. What output would you prefer to see? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.maptools.org/pipermail/proj/attachments/20080813/93568337/attachment.html From heather.yager at gmail.com Wed Aug 13 00:42:33 2008 From: heather.yager at gmail.com (Heather M. Yager) Date: Wed Aug 13 00:43:36 2008 Subject: [Proj] installation question: proj_api.h In-Reply-To: <86782b610808121452s6237af9fn7725d8d36f4b304e@mail.gmail.com> References: <48A1FA29.9070700@gmail.com> <86782b610808121452s6237af9fn7725d8d36f4b304e@mail.gmail.com> Message-ID: <48A26639.8070400@gmail.com> Markus Neteler wrote: > Heather, > > On Tue, Aug 12, 2008 at 11:01 PM, Heather M. Yager > wrote: >> Hi! >> >> I don't yet have experience with PROJ4, but I must install it on SuSE in >> order to run MapServer with projection support. The problem: when I >> install proj from an RPM (command I used: "yast -i >> proj-4.4.9-1.guru.suse93.x86_64.rpm") it appears that the installation >> was successful - I can locate proj, I can type "proj" at the command >> line (and receive "Rel. 4.4.9, 29 Oct 2004" back). > > You also need to install > proj-devel-4.4.9-1.guru.suse93.x86_64.rpm > which contains proj_api.h and some more relevant files. > > Hope this helps, > Markus > Markus - Thank you, that solved the problem in one swipe. Cheers, Heather Y. From geraldi.evenden at gmail.com Wed Aug 13 11:06:26 2008 From: geraldi.evenden at gmail.com (Gerald I. Evenden) Date: Wed Aug 13 11:06:34 2008 Subject: [Proj] Re: Proj Digest, Vol 51, Issue 2 - axis rotation issue In-Reply-To: <48A2A24A.90409@gmail.com> References: <200808091601.m79G1YiH028272@duke.maptools.org> <200808122001.15353.geraldi.evenden@gmail.com> <48A2A24A.90409@gmail.com> Message-ID: <200808131106.26532.geraldi.evenden@gmail.com> On Wednesday 13 August 2008 4:58:50 am you wrote: ... > I think it's my fault. I'd had latitudes as S20;? S30; etc. and > should've put the negative in.
My goodness, that make a lot of difference! >
> It looks to me that I simply need to multiply the outputs by -1, but > I'm loath to do that because I don't understand the underlying > mathematics that calculates the projection.
> Is it really that simple? I could use the "-m" flag and set it to -1, > but is that wise?
> It appears to give me the correct output:
>
> ~$ proj +proj=tmerc +ellps=WGS84 +lon_0=27 -m -1 Desktop/proj
> -55660.46??? -0.00
> -54820.34??? 1105896.37
> -52324.06??? 2212444.34
> -48243.45??? 3320218.65
> -58652.24??? 2897715.76
>
> Can you advise?
You have a most strange grid system where the south pole is oriented to the top of the map. I suppose it makes a difference to someone living in the southern hemisphere but it is a bit odd when compared to most grid orientations. All you are doing is rotating the x-y (easting-northing) axis by 180 degrees and this can, as you empirically determined, be done my using the '-m -1' option. As to whether an axis rotation option is libproj4's responsibility or the applications program's (proj4, lproj, etc.) responsibility and thus a "-" option or "+" option respectively is now open for debate. Any comments from the maptools group? -- The whole religious complexion of the modern world is due to the absence from Jerusalem of a lunatic asylum. -- Havelock Ellis (1859-1939) British psychologist From halfhaggis at gmail.com Wed Aug 13 11:22:32 2008 From: halfhaggis at gmail.com (Neil Robinson) Date: Wed Aug 13 11:22:44 2008 Subject: [Proj] Re: Proj Digest, Vol 51, Issue 2 - axis rotation issue In-Reply-To: <200808131106.26532.geraldi.evenden@gmail.com> References: <200808091601.m79G1YiH028272@duke.maptools.org> <200808122001.15353.geraldi.evenden@gmail.com> <48A2A24A.90409@gmail.com> <200808131106.26532.geraldi.evenden@gmail.com> Message-ID: <48A2FC38.4080700@gmail.com> Gerald I. Evenden wrote: > On Wednesday 13 August 2008 4:58:50 am you wrote: > ... > >> I think it's my fault. I'd had latitudes as S20; S30; etc. and >> should've put the negative in.
>> > > My goodness, that make a lot of difference! > > >>
>> It looks to me that I simply need to multiply the outputs by -1, but >> I'm loath to do that because I don't understand the underlying >> mathematics that calculates the projection.
>> Is it really that simple? I could use the "-m" flag and set it to -1, >> but is that wise?
>> It appears to give me the correct output:
>>
>> ~$ proj +proj=tmerc +ellps=WGS84 +lon_0=27 -m -1 Desktop/proj
>> -55660.46 -0.00
>> -54820.34 1105896.37
>> -52324.06 2212444.34
>> -48243.45 3320218.65
>> -58652.24 2897715.76
>>
>> Can you advise?
>> > > You have a most strange grid system where the south pole is oriented to the > top of the map. I suppose it makes a difference to someone living in the > southern hemisphere but it is a bit odd when compared to most grid > orientations. > Don't ask me -- I just live here! I would have been a lot less frustrated if the powers that be could've just kept north at the top. > All you are doing is rotating the x-y (easting-northing) axis by 180 degrees > and this can, as you empirically determined, be done my using the '-m -1' > option. > > As to whether an axis rotation option is libproj4's responsibility or the > applications program's (proj4, lproj, etc.) responsibility and thus a "-" > option or "+" option respectively is now open for debate. > Indeed. As it stands, qgis, which allows configuration of a custom projection using proj4 parameters, doesn't appear to support the -m flag or have an equivalent flag or setting I could use. Since I started this whole investigation to get qgis to work properly, my fight is still not over. At least I can measure distances now, which is my most important requirement. I'll see what the qgis people have to say. Thanks for your time > Any comments from the maptools group? > > -------------- next part -------------- A non-text attachment was scrubbed... Name: halfhaggis.vcf Type: text/x-vcard Size: 197 bytes Desc: not available Url : http://lists.maptools.org/pipermail/proj/attachments/20080813/e3892fef/halfhaggis.vcf From ovv at hetnet.nl Wed Aug 13 13:50:28 2008 From: ovv at hetnet.nl (OvV_HN) Date: Wed Aug 13 13:50:23 2008 Subject: [Proj] Re: Proj Digest, Vol 51, Issue 2 - axis rotation issue In-Reply-To: <200808131106.26532.geraldi.evenden@gmail.com> References: <200808091601.m79G1YiH028272@duke.maptools.org><200808122001.15353.geraldi.evenden@gmail.com><48A2A24A.90409@gmail.com> <200808131106.26532.geraldi.evenden@gmail.com> Message-ID: <121D410F401E4E668C08966F48698A81@PCHP> ----- Original Message ----- From: "Gerald I. Evenden" To: "Neil Robinson" ; "PROJ.4 and general Projections Discussions" Sent: Wednesday, August 13, 2008 5:06 PM Subject: Re: [Proj] Re: Proj Digest, Vol 51, Issue 2 - axis rotation issue .... > As to whether an axis rotation option is libproj4's responsibility or the > applications program's (proj4, lproj, etc.) responsibility and thus a "-" > option or "+" option respectively is now open for debate. > > Any comments from the maptools group? > I have always wondered, why can the lcc projection have a westo flag for a west orientation, but why can't tmerc have a south orientation? The LCC West orientation is used for some rather old Greenland projections, whereas the tmerc South orientation is used today with respect to the South-African Hartebeesthoek datum. Oscar van Vlijmen From tutey at o2.pl Thu Aug 14 11:20:52 2008 From: tutey at o2.pl (Maciej Sieczka) Date: Thu Aug 14 11:19:21 2008 Subject: [Proj] PROJ.4 and local coordinate systems In-Reply-To: <18943556.post@talk.nabble.com> References: <18943556.post@talk.nabble.com> Message-ID: <48A44D54.9040004@o2.pl> joeri.theelen pisze: > Is it possible to use PROJ.4 or any of its related tools to transform > coordinates from a local carthesian system into another local carthesian > system (thus both are not earth related). > > I inherit lots of datasets in many different formats for an archaeological > site, with coordinates measured in two different local systems (shift in > time). I managed to get the transformation parameters to transform sets of > coordinates between both systems, with minor error. By transformation, I > mean translation, rotation and dilation (scale factor) of the X/Y > coordinates only, not height. > > I also managed to get the transformation parameters from both local systems > to the UTM system in use in that area. Thus, transforming from local to UTM > to local would be an option as well. > > Can anybody help me with this? I know programming such a tranformation would > be trivial, but I need the power and flexibility of a tool like "cs2cs" to > cope with the many different formats I am facing. Joeri, As *it seems* there is no such functionality in PROJ, maybe you would be ineterested in GRASS v.transform [1] module. You can load ASCII data into GRASS with v.in.ascii. [1]http://grass.osgeo.org/grass64/manuals/html64_user/v.transform.html Maciek -- Maciej Sieczka www.sieczka.org From support.mn at elisanet.fi Thu Aug 14 14:19:28 2008 From: support.mn at elisanet.fi (support.mn@elisanet.fi) Date: Thu Aug 14 14:19:34 2008 Subject: [Proj] PROJ.4 and local coordinate systems Message-ID: <18931988.3323231218737968641.JavaMail.support.mn@elisanet.fi> Hello, > By transformation, I > mean translation, rotation and dilation (scale factor) of the X/Y > coordinates only, not height. there is the possibility to use datums. What you just wrote is a datum definition. You define a datum for both systems relative to the wgs84 and proj-4 should automatically transform your coordinates.. ?? if the coordinate values do not match to any standard, just define your own false easting and false northing values so that the resulting values are better.. ?? Regards: Janne. ------------------------------------- "joeri.theelen" kirjoitti: > > Hi, > > Is it possible to use PROJ.4 or any of its related tools to transform > coordinates from a local carthesian system into another local carthesian > system (thus both are not earth related). > > I inherit lots of datasets in many different formats for an archaeological > site, with coordinates measured in two different local systems (shift in > time). I managed to get the transformation parameters to transform sets of > coordinates between both systems, with minor error. By transformation, I > mean translation, rotation and dilation (scale factor) of the X/Y > coordinates only, not height. > > I also managed to get the transformation parameters from both local systems > to the UTM system in use in that area. Thus, transforming from local to UTM > to local would be an option as well. > > Can anybody help me with this? I know programming such a tranformation would > be trivial, but I need the power and flexibility of a tool like "cs2cs" to > cope with the many different formats I am facing. > > Thank you, > Joeri > -- > View this message in context: http://www.nabble.com/PROJ.4-and-local-coordinate-systems-tp18943556p18943556.html > Sent from the PROJ.4 mailing list archive at Nabble.com. > > _______________________________________________ > Proj mailing list > Proj@lists.maptools.org > http://lists.maptools.org/mailman/listinfo/proj > From joeri.theelen at arts.kuleuven.be Mon Aug 18 10:14:12 2008 From: joeri.theelen at arts.kuleuven.be (joeri.theelen) Date: Mon Aug 18 10:14:17 2008 Subject: [Proj] PROJ.4 and local coordinate systems In-Reply-To: <48A44D54.9040004@o2.pl> References: <18943556.post@talk.nabble.com> <48A44D54.9040004@o2.pl> Message-ID: <19032640.post@talk.nabble.com> Maciek, Thanks for the tip: I do not use GRASS (yet), but I looked for a similar transform module in SAGA GIS and found it. The module does what I need to transform my files containing shapes in different formats. Kind regards, Joeri Maciej Sieczka wrote: > > joeri.theelen pisze: > >> Is it possible to use PROJ.4 or any of its related tools to transform >> coordinates from a local carthesian system into another local carthesian >> system (thus both are not earth related). >> >> I inherit lots of datasets in many different formats for an >> archaeological >> site, with coordinates measured in two different local systems (shift in >> time). I managed to get the transformation parameters to transform sets >> of >> coordinates between both systems, with minor error. By transformation, I >> mean translation, rotation and dilation (scale factor) of the X/Y >> coordinates only, not height. >> >> I also managed to get the transformation parameters from both local >> systems >> to the UTM system in use in that area. Thus, transforming from local to >> UTM >> to local would be an option as well. >> >> Can anybody help me with this? I know programming such a tranformation >> would >> be trivial, but I need the power and flexibility of a tool like "cs2cs" >> to >> cope with the many different formats I am facing. > > Joeri, > > As *it seems* there is no such functionality in PROJ, maybe you would be > ineterested in GRASS v.transform [1] module. You can load ASCII data > into GRASS with v.in.ascii. > > [1]http://grass.osgeo.org/grass64/manuals/html64_user/v.transform.html > > Maciek > > -- > Maciej Sieczka > www.sieczka.org > _______________________________________________ > Proj mailing list > Proj@lists.maptools.org > http://lists.maptools.org/mailman/listinfo/proj > > -- View this message in context: http://www.nabble.com/PROJ.4-and-local-coordinate-systems-tp18943556p19032640.html Sent from the PROJ.4 mailing list archive at Nabble.com. From joeri.theelen at arts.kuleuven.be Mon Aug 18 10:21:51 2008 From: joeri.theelen at arts.kuleuven.be (joeri.theelen) Date: Mon Aug 18 10:21:57 2008 Subject: [Proj] PROJ.4 and local coordinate systems In-Reply-To: <18931988.3323231218737968641.JavaMail.support.mn@elisanet.fi> References: <18943556.post@talk.nabble.com> <18931988.3323231218737968641.JavaMail.support.mn@elisanet.fi> Message-ID: <19032799.post@talk.nabble.com> Janne, Thanks for trying to help me out. Working with datum definitions is what I tried to avoid in the first place, as I thought it would be too complex and not accurate anough for the kind of data I am working with (high precision and very large scale). Following the advise from another reply to my question, I found a module to transform coordinates from one system to another (in SAGA GIS). This has nothing to do with "real" coordinate transformations, but it is exacly what I need. Kind regards, Joeri support.mn wrote: > > Hello, > >> By transformation, I >> mean translation, rotation and dilation (scale factor) of the X/Y >> coordinates only, not height. > > there is the possibility to use datums. What you just wrote is a datum > definition. You define a datum for both systems relative to the wgs84 > and proj-4 should automatically transform your coordinates.. ?? > > if the coordinate values do not match to any standard, just define your > own false easting and false northing values so that the resulting values > are better.. ?? > > Regards: Janne. > > ------------------------------------- > > "joeri.theelen" kirjoitti: >> >> Hi, >> >> Is it possible to use PROJ.4 or any of its related tools to transform >> coordinates from a local carthesian system into another local carthesian >> system (thus both are not earth related). >> >> I inherit lots of datasets in many different formats for an >> archaeological >> site, with coordinates measured in two different local systems (shift in >> time). I managed to get the transformation parameters to transform sets >> of >> coordinates between both systems, with minor error. By transformation, I >> mean translation, rotation and dilation (scale factor) of the X/Y >> coordinates only, not height. >> >> I also managed to get the transformation parameters from both local >> systems >> to the UTM system in use in that area. Thus, transforming from local to >> UTM >> to local would be an option as well. >> >> Can anybody help me with this? I know programming such a tranformation >> would >> be trivial, but I need the power and flexibility of a tool like "cs2cs" >> to >> cope with the many different formats I am facing. >> >> Thank you, >> Joeri >> -- >> View this message in context: >> http://www.nabble.com/PROJ.4-and-local-coordinate-systems-tp18943556p18943556.html >> Sent from the PROJ.4 mailing list archive at Nabble.com. >> >> _______________________________________________ >> Proj mailing list >> Proj@lists.maptools.org >> http://lists.maptools.org/mailman/listinfo/proj >> > > _______________________________________________ > Proj mailing list > Proj@lists.maptools.org > http://lists.maptools.org/mailman/listinfo/proj > > -- View this message in context: http://www.nabble.com/PROJ.4-and-local-coordinate-systems-tp18943556p19032799.html Sent from the PROJ.4 mailing list archive at Nabble.com. From yjacolin at free.fr Tue Aug 19 05:42:32 2008 From: yjacolin at free.fr (Jacolin Yves) Date: Tue Aug 19 05:42:59 2008 Subject: [Proj] build mapserver 5.2.0 with proj 4.6.0 Message-ID: <200808191142.32660.yjacolin@free.fr> Hi, This is an issue from mapserver building, but I would like to know what do you think about this as it is link top proj4. I am trying to build mapserver with proj 4.6.0, mapserver configure script try to test proj installation and the release number and I get this error: checking for pj_transform in -lproj... no configure: error: This version of PROJ is too old. PROJ4.4.2 or later is required As you see I don't use old release of proj, is it possible that something changed in proj4 (pj_transform for exemple ;) ) and that mapserver is getting wrong release number? Thanks, Y. -- Yves Jacolin --- http://softlibre.gloobe.org From yjacolin at free.fr Tue Aug 19 06:07:23 2008 From: yjacolin at free.fr (Jacolin Yves) Date: Tue Aug 19 06:07:41 2008 Subject: [Proj] build mapserver 5.2.0 with proj 4.6.0 In-Reply-To: <200808191142.32660.yjacolin@free.fr> References: <200808191142.32660.yjacolin@free.fr> Message-ID: <200808191207.23832.yjacolin@free.fr> Le Tuesday 19 August 2008 11:42:32 Jacolin Yves, vous avez ?crit?: > Hi, > > This is an issue from mapserver building, but I would like to know what do > you think about this as it is link top proj4. > > I am trying to build mapserver with proj 4.6.0, mapserver configure script > try to test proj installation and the release number and I get this error: > checking for pj_transform in -lproj... no > configure: error: This version of PROJ is too old. PROJ4.4.2 or later is > required > > As you see I don't use old release of proj, is it possible that something > changed in proj4 (pj_transform for exemple ;) ) and that mapserver is > getting wrong release number? > > Thanks, > > Y. Building proj4 again resolved the problem, sorry for the inconvenience. Y. -- Yves Jacolin --- http://softlibre.gloobe.org From brauplists at gmail.com Wed Aug 20 15:21:01 2008 From: brauplists at gmail.com (Bruce Raup) Date: Wed Aug 20 15:21:08 2008 Subject: [Proj] Polar stereographic, different values on different platforms? In-Reply-To: <46659BC7.5010107@pobox.com> References: <10972083.post@talk.nabble.com> <46659BC7.5010107@pobox.com> Message-ID: <1464295a0808201221u667a5fd4w932c824751f70a09@mail.gmail.com> Frank and all, Has the problem described in the below been resolved yet? A colleague of mine and I have just executed the same "proj" command on Windows and Linux, and are getting different results. Windows version is Rel. 4.6.1, 21 Jul 2008. Linux versions are Rel. 4.5.0, 22 Oct 2006 and Rel. 4.6.0, 21 Dec 2007 Command: echo "105 40" | proj +proj=stere +lat_0=90 +lon_0=0 +lat_ts=70 +datum=WGS84 On both Linux boxes, we get the output 5577808.93 1494569.40 On Windows, my colleague gets: 5610189.12 1503245.64 Using GMT's "mapproject" program, I get the same results as the Linux versions of Proj: echo "105 40" | mapproject -Js0/90/70/1:1 -C -F -R-180/180/30/90 5577808.933369 1494569.399231 What is the cause the the problem? There is no change when we specify '+ellps=WGS84'. I searched my archive of the list and found the below. Thanks in advance for any insight, Bruce Raup On Tue, Jun 5, 2007 at 11:22 AM, Frank Warmerdam wrote: > aaime74 wrote: >> >> Hi, >> at Geoserver we're experiencing some issues with projection code, and we >> took Proj as >> an external reference for comparison. >> Well, it turns out that proj 4.5 returns different results when compiled >> for >> Windows >> and Linux. >> >> On Linux: >> desruisseaux@adagio ~ $ proj >> Rel. 4.5.0, 22 Oct 2006 >> usage: proj [ -beEfiIlormsStTvVwW [args] ] [ +opts[=arg] ] [ files ] >> desruisseaux@adagio ~ $ proj +proj=stere +lon_0=-96.0 +lat_0=90 +lat_ts=71 >> +ellps=WGS84 +datum=WGS84 >> -121.33955 39.1012523 >> -2529570.00 -5341800.00 >> >> On Windows: >> C:\Program Files\FWTools1.1.3>proj >> Rel. 4.5.0, 22 Oct 2006 >> usage: proj [ -beEfiIlormsStTvVwW [args] ] [ +opts[=arg] ] [ files ] >> >> C:\Program Files\FWTools1.1.3>proj +proj=stere +lon_0=-96.0 +lat_0=90 >> +lat_ts=71 >> +ellps=WGS84 +datum=WGS84 >> -121.33955 39.1012523 >> -2544346.32 -5373003.77 > > Andrea, > > I think this is related to the recently reported problem in: > > http://bugzilla.remotesensing.org/show_bug.cgi?id=1558 > > Hopefully I'll be able to resolve it though for your purposes I guess > you should just ignore the windows proj.4 results for now. > > Best regards, > -- > ---------------------------------------+-------------------------------------- > I set the clouds in motion - turn up | Frank Warmerdam, > warmerdam@pobox.com > light and sound - activate the windows | http://pobox.com/~warmerdam > and watch the world go round - Rush | President OSGeo, http://osgeo.org > > _______________________________________________ > Proj mailing list > Proj@lists.maptools.org > http://lists.maptools.org/mailman/listinfo/proj > -- Bruce Raup http://cires.colorado.edu/~braup/ From warmerdam at pobox.com Wed Aug 20 16:04:33 2008 From: warmerdam at pobox.com (Frank Warmerdam) Date: Wed Aug 20 16:04:55 2008 Subject: [Proj] Polar stereographic, different values on different platforms? In-Reply-To: <1464295a0808201221u667a5fd4w932c824751f70a09@mail.gmail.com> References: <10972083.post@talk.nabble.com> <46659BC7.5010107@pobox.com> <1464295a0808201221u667a5fd4w932c824751f70a09@mail.gmail.com> Message-ID: <48AC78D1.8000905@pobox.com> Bruce Raup wrote: > Frank and all, > > Has the problem described in the below been resolved yet? A colleague > of mine and I have just executed the same "proj" command on Windows > and Linux, and are getting different results. Windows version is Rel. > 4.6.1, 21 Jul 2008. Linux versions are Rel. 4.5.0, 22 Oct 2006 and > Rel. 4.6.0, 21 Dec 2007 > > Command: > echo "105 40" | proj +proj=stere +lat_0=90 +lon_0=0 +lat_ts=70 +datum=WGS84 > > On both Linux boxes, we get the output > 5577808.93 1494569.40 > > On Windows, my colleague gets: > 5610189.12 1503245.64 > > Using GMT's "mapproject" program, I get the same results as the Linux > versions of Proj: > echo "105 40" | mapproject -Js0/90/70/1:1 -C -F -R-180/180/30/90 > 5577808.933369 1494569.399231 > > What is the cause the the problem? There is no change when we specify > '+ellps=WGS84'. I searched my archive of the list and found the > below. Bruce, Unfortunately, with the loss of the old PROJ bug tracker, I can't review the old bug report contents, and I don't recall the details of this problem. I will say I see the same results you see here (that is, windows and linux results are different), and I'm running quite recent PROJ.4 code. So I suspect the issue is not fixed. Best regards, ... >> Andrea, >> >> I think this is related to the recently reported problem in: >> >> http://bugzilla.remotesensing.org/show_bug.cgi?id=1558 >> >> Hopefully I'll be able to resolve it though for your purposes I guess >> you should just ignore the windows proj.4 results for now. >> >> Best regards, >> -- >> ---------------------------------------+-------------------------------------- >> I set the clouds in motion - turn up | Frank Warmerdam, >> warmerdam@pobox.com >> light and sound - activate the windows | http://pobox.com/~warmerdam >> and watch the world go round - Rush | President OSGeo, http://osgeo.org >> >> _______________________________________________ >> Proj mailing list >> Proj@lists.maptools.org >> http://lists.maptools.org/mailman/listinfo/proj >> > > > -- ---------------------------------------+-------------------------------------- I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush | Geospatial Programmer for Rent From geraldi.evenden at gmail.com Wed Aug 20 17:26:34 2008 From: geraldi.evenden at gmail.com (Gerald I. Evenden) Date: Wed Aug 20 17:26:42 2008 Subject: [Proj] Polar stereographic, different values on different platforms? In-Reply-To: <1464295a0808201221u667a5fd4w932c824751f70a09@mail.gmail.com> References: <10972083.post@talk.nabble.com> <46659BC7.5010107@pobox.com> <1464295a0808201221u667a5fd4w932c824751f70a09@mail.gmail.com> Message-ID: <200808201726.35005.geraldi.evenden@gmail.com> On Wednesday 20 August 2008 3:21:01 pm Bruce Raup wrote: > Frank and all, > > Has the problem described in the below been resolved yet? A colleague > of mine and I have just executed the same "proj" command on Windows > and Linux, and are getting different results. Windows version is Rel. > 4.6.1, 21 Jul 2008. Linux versions are Rel. 4.5.0, 22 Oct 2006 and > Rel. 4.6.0, 21 Dec 2007 > > Command: > echo "105 40" | proj +proj=stere +lat_0=90 +lon_0=0 +lat_ts=70 +datum=WGS84 > > On both Linux boxes, we get the output > 5577808.93 1494569.40 For what it is worth, lproj reproduces the above value as well as the test in the earlier email. > On Windows, my colleague gets: > 5610189.12 1503245.64 > > Using GMT's "mapproject" program, I get the same results as the Linux > versions of Proj: > echo "105 40" | mapproject -Js0/90/70/1:1 -C -F -R-180/180/30/90 > 5577808.933369 1494569.399231 Also, for what it is worth, lproj gives: 5577808.933368 1494569.399231 Must be a problem in the longitude computation. ;-) ... -- The whole religious complexion of the modern world is due to the absence from Jerusalem of a lunatic asylum. -- Havelock Ellis (1859-1939) British psychologist From nhv at cape.com Thu Aug 21 01:34:24 2008 From: nhv at cape.com (Norman Vine) Date: Thu Aug 21 01:34:29 2008 Subject: [Proj] RE: [OSGeo-Discuss] Brief history of GIS OSS (bit off topic?) In-Reply-To: <48ACD2F2.2020003@loskot.net> Message-ID: <20080821052621.BA4D9DF940@mrelay1.cape.com> Mateusz Loskot writes > Sent: Wednesday, August 20, 2008 10:29 PM > Subject: Re: [OSGeo-Discuss] Brief history of GIS OSS (bit off topic?) > > George Silva wrote: > > Hello lists, > > > > As you can i see im mailing this message to some lists around the web > > (im sorry if thats a problem). > > > > At the moment i am writing my BSc thesis (Geography) focusing the > > development of a open source software and database for logging and > > analysing traffic accidents in Uberl?ndia, MG - Brazil. > > > > I am dedicating a chapter in my thesis to explaining Open Source > > Software, and OSS for GIS. i searched the web for some > history of OSS in > > general, but i found too many different sources. So i come to you, > > developers of GIS OSS, to see if you can give me references > of where to > > search for the history and process regarding this theme. > > George, > > Here is number of "keywords" related to history of FOSS4G > and that you may google for and find details: > > - Sol Katz > - Map Overlay and Statistical System (MOSS) > - GRASS History (http://grass.itc.it/devel/grasshist.html) > - UMP MapServer history Mateusz Great credits but don't forgot http://trac.osgeo.org/proj/ or perhaps http://members.verizon.net/~vze2hc4d/proj4/ :-) Thanks Gerry !! From mateusz at loskot.net Thu Aug 21 01:52:38 2008 From: mateusz at loskot.net (Mateusz Loskot) Date: Thu Aug 21 01:52:46 2008 Subject: [Proj] RE: [OSGeo-Discuss] Brief history of GIS OSS (bit off topic?) In-Reply-To: <20080821052621.BA4D9DF940@mrelay1.cape.com> References: <20080821052621.BA4D9DF940@mrelay1.cape.com> Message-ID: <48AD02A6.5000601@loskot.net> Norman Vine wrote: > Mateusz Loskot writes >> Sent: Wednesday, August 20, 2008 10:29 PM > >> Subject: Re: [OSGeo-Discuss] Brief history of GIS OSS (bit off topic?) >> >> George Silva wrote: >>> Hello lists, >>> >>> As you can i see im mailing this message to some lists around the web >>> (im sorry if thats a problem). >>> >>> At the moment i am writing my BSc thesis (Geography) focusing the >>> development of a open source software and database for logging and >>> analysing traffic accidents in Uberl?ndia, MG - Brazil. >>> >>> I am dedicating a chapter in my thesis to explaining Open Source >>> Software, and OSS for GIS. i searched the web for some >> history of OSS in >>> general, but i found too many different sources. So i come to you, >>> developers of GIS OSS, to see if you can give me references >> of where to >>> search for the history and process regarding this theme. >> George, >> >> Here is number of "keywords" related to history of FOSS4G >> and that you may google for and find details: >> >> - Sol Katz >> - Map Overlay and Statistical System (MOSS) >> - GRASS History (http://grass.itc.it/devel/grasshist.html) >> - UMP MapServer history > > > Mateusz > > Great credits but don't forgot http://trac.osgeo.org/proj/ or perhaps > > http://members.verizon.net/~vze2hc4d/proj4/ :-) > > Thanks Gerry !! Norman, Yes, I've forgot about these two. Thanks for completing. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org From glynn at gclements.plus.com Thu Aug 21 04:01:32 2008 From: glynn at gclements.plus.com (Glynn Clements) Date: Thu Aug 21 04:01:40 2008 Subject: [Proj] Polar stereographic, different values on different platforms? In-Reply-To: <1464295a0808201221u667a5fd4w932c824751f70a09@mail.gmail.com> References: <10972083.post@talk.nabble.com> <46659BC7.5010107@pobox.com> <1464295a0808201221u667a5fd4w932c824751f70a09@mail.gmail.com> Message-ID: <18605.8412.462001.560096@cerise.gclements.plus.com> Bruce Raup wrote: > Has the problem described in the below been resolved yet? A colleague > of mine and I have just executed the same "proj" command on Windows > and Linux, and are getting different results. Windows version is Rel. > 4.6.1, 21 Jul 2008. Linux versions are Rel. 4.5.0, 22 Oct 2006 and > Rel. 4.6.0, 21 Dec 2007 > > Command: > echo "105 40" | proj +proj=stere +lat_0=90 +lon_0=0 +lat_ts=70 +datum=WGS84 > > On both Linux boxes, we get the output > 5577808.93 1494569.40 > > On Windows, my colleague gets: > 5610189.12 1503245.64 FWIW, PROJ 4.6.0 compiled from source on Windows with MinGW gives the "Linux" result above, while the version included in OSGeo4W gives the "Windows" result. However, I don't know if this is an issue with the compiler or the runtime. MinGW uses msvcrt.dll, while the OSGeo4W version uses msvcr71.dll. Attempting to use "-nodefaultlibs ... -lmsvcr71" with MinGW ends up pulling in both msvcrt.dll and msvcr71.dll. -- Glynn Clements From neteler at osgeo.org Thu Aug 21 08:20:59 2008 From: neteler at osgeo.org (Markus Neteler) Date: Thu Aug 21 08:21:03 2008 Subject: [Proj] RE: [OSGeo-Discuss] Brief history of GIS OSS (bit off topic?) In-Reply-To: References: <20080821052621.BA4D9DF940@mrelay1.cape.com> <48AD02A6.5000601@loskot.net> Message-ID: <86782b610808210520p8bbe76ax23a37d1d27fb49f1@mail.gmail.com> I have started a small article: http://wiki.osgeo.org/wiki/Open_Source_GIS_History Feel free to expand. Markus On Thu, Aug 21, 2008 at 9:42 AM, G. Allegri wrote: > Some interesting details about the OpenGIS birth can be found also in > Gardel's OGC history: > http://www.opengeospatial.org/ogc/historylong > > Giovanni > > 2008/8/21 Mateusz Loskot : >> Norman Vine wrote: >>> Mateusz Loskot writes >>>> Sent: Wednesday, August 20, 2008 10:29 PM >>>> Subject: Re: [OSGeo-Discuss] Brief history of GIS OSS (bit off topic?) >>>> George Silva wrote: >>>>> >>>>> Hello lists, >>>>> >>>>> As you can i see im mailing this message to some lists around the web >>>>> (im sorry if thats a problem). >>>>> >>>>> At the moment i am writing my BSc thesis (Geography) focusing the >>>>> development of a open source software and database for logging and analysing >>>>> traffic accidents in Uberl?ndia, MG - Brazil. >>>>> >>>>> I am dedicating a chapter in my thesis to explaining Open Source >>>>> Software, and OSS for GIS. i searched the web for some history of OSS in >>>>> >>>>> general, but i found too many different sources. So i come to you, >>>>> developers of GIS OSS, to see if you can give me references of where to >>>>> search for the history and process regarding this theme. >>>> -- Open Source Geospatial Foundation http://www.osgeo.org/ http://www.grassbook.org/ From EMiller at dfg.ca.gov Thu Aug 21 12:59:33 2008 From: EMiller at dfg.ca.gov (Eric Miller) Date: Thu Aug 21 13:00:12 2008 Subject: [Proj] Polar stereographic,different values on different platforms? In-Reply-To: <18605.8412.462001.560096@cerise.gclements.plus.com> References: <10972083.post@talk.nabble.com> <46659BC7.5010107@pobox.com> <1464295a0808201221u667a5fd4w932c824751f70a09@mail.gmail.com> <18605.8412.462001.560096@cerise.gclements.plus.com> Message-ID: <48AD3C83.95FD.00E4.0@dfg.ca.gov> I did a little testing of various flavors of the Windows compiler. We call these flavors 7, 8 and 9. Flavor 7 is Visual Studio .Net 2003 which reports its C compiler as """ Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 13.10.3077 for 80x86 """ Flavor 8 is Visual Studio 2005 which reports its C compiler as """ Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 14.00.50727.762 for 80x86 """ Flavor 9 is Visual Studio 2008 which reports its C compiler as """ Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 15.00.30729.01 for 80x86 """ Using the supplied Makefile.vc, I did two builds for each version. The "release" build uses the OPTFLAGS settings as distributed in the source, while the "debug" build swaps the OPTFLAGS to use the second set of settings (which is commented out in the sources). The command: echo 105 40 | proj +proj=stere +lat_0=90 +lon_0=0 +lat_ts=70 +datum=WGS84 The Results: Flavor 7 (debug): 5577808.93 1494569.40 Flavor 7 (release): 5610189.12 1503245.64 Flavor 8 (debug): 5577808.93 1494569.40 Flavor 8 (release): 5577808.93 1494569.40 Flavor 9 (debug): 5577808.93 1494569.40 Flavor 9 (release): 5577808.93 1494569.40 So, we can see this is a direct result of doing an optimized build with Flavor 7 (Visual Studio .Net 2003). So, then I downloaded and installed Service Pack 1 (http://www.microsoft.com/downloads/details.aspx?familyid=69d2219f-ce82-46a5-8aec-072bd4bb955e ) and rebuilt a "release" version. The results were the same. Then, I added the "/Op" (Improve Float Consistency) flag and then the "release" results matched the "debug" results. OPTFLAGS= /nologo /Ox /Op /MD -- Eric G. Miller Staff Programmer CA Dept. of Fish & Game >>> On 8/21/2008 at 1:01 AM, Glynn Clements wrote: > Bruce Raup wrote: > >> Has the problem described in the below been resolved yet? A colleague >> of mine and I have just executed the same "proj" command on Windows >> and Linux, and are getting different results. Windows version is Rel. >> 4.6.1, 21 Jul 2008. Linux versions are Rel. 4.5.0, 22 Oct 2006 and >> Rel. 4.6.0, 21 Dec 2007 >> >> Command: >> echo "105 40" | proj +proj=stere +lat_0=90 +lon_0=0 +lat_ts=70 +datum=WGS84 >> >> On both Linux boxes, we get the output >> 5577808.93 1494569.40 >> >> On Windows, my colleague gets: >> 5610189.12 1503245.64 > > FWIW, PROJ 4.6.0 compiled from source on Windows with MinGW gives the > "Linux" result above, while the version included in OSGeo4W gives the > "Windows" result. > > However, I don't know if this is an issue with the compiler or the > runtime. MinGW uses msvcrt.dll, while the OSGeo4W version uses > msvcr71.dll. Attempting to use "-nodefaultlibs ... -lmsvcr71" with > MinGW ends up pulling in both msvcrt.dll and msvcr71.dll. From warmerdam at pobox.com Thu Aug 21 13:28:33 2008 From: warmerdam at pobox.com (Frank Warmerdam) Date: Thu Aug 21 13:28:59 2008 Subject: [Proj] Polar stereographic,different values on different platforms? In-Reply-To: <48AD3C83.95FD.00E4.0@dfg.ca.gov> References: <10972083.post@talk.nabble.com> <46659BC7.5010107@pobox.com> <1464295a0808201221u667a5fd4w932c824751f70a09@mail.gmail.com> <18605.8412.462001.560096@cerise.gclements.plus.com> <48AD3C83.95FD.00E4.0@dfg.ca.gov> Message-ID: <48ADA5C1.9020505@pobox.com> Eric Miller wrote: > I did a little testing of various flavors of the Windows compiler. Eric, Great work! I have filed this as: http://trac.osgeo.org/proj/ticket/12 I'll update the makefile.vc to use /Op by default, and look into updating at least the OSGeo4W binaries. Best regards, -- ---------------------------------------+-------------------------------------- I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush | Geospatial Programmer for Rent From brauplists at gmail.com Thu Aug 21 16:12:21 2008 From: brauplists at gmail.com (Bruce Raup) Date: Thu Aug 21 16:12:26 2008 Subject: [Proj] Polar stereographic, different values on different platforms? In-Reply-To: <48ADA5C1.9020505@pobox.com> References: <10972083.post@talk.nabble.com> <46659BC7.5010107@pobox.com> <1464295a0808201221u667a5fd4w932c824751f70a09@mail.gmail.com> <18605.8412.462001.560096@cerise.gclements.plus.com> <48AD3C83.95FD.00E4.0@dfg.ca.gov> <48ADA5C1.9020505@pobox.com> Message-ID: <1464295a0808211312j41bef9b3ge76bc1b3c981a015@mail.gmail.com> Eric, Frank, Glynn, Gerald, and all, It's great to see quick action on this. In my view, this is quite a major bug, and it's unknown (to me) whether it affects other projections or things that are built on top of Proj.4, like GDAL/OGR, MapServer, etc. It doesn't affect me directly because I use Linux, but the colleague I'd just introduced to all these tools is getting a bad first impression of open source geospatial software (his words). Is there a test script already written for checking the results from Proj.4? If not, I will try to work up a script that tests some other projections. Bruce On Thu, Aug 21, 2008 at 11:28 AM, Frank Warmerdam wrote: > Eric Miller wrote: >> >> I did a little testing of various flavors of the Windows compiler. > > Eric, > > Great work! I have filed this as: > > http://trac.osgeo.org/proj/ticket/12 > > I'll update the makefile.vc to use /Op by default, and look into updating > at least the OSGeo4W binaries. > > Best regards, > > -- > ---------------------------------------+-------------------------------------- > I set the clouds in motion - turn up | Frank Warmerdam, > warmerdam@pobox.com > light and sound - activate the windows | http://pobox.com/~warmerdam > and watch the world go round - Rush | Geospatial Programmer for Rent > > _______________________________________________ > Proj mailing list > Proj@lists.maptools.org > http://lists.maptools.org/mailman/listinfo/proj > -- Bruce Raup http://cires.colorado.edu/~braup/ From knudsen.thomas at gmail.com Thu Aug 21 17:17:49 2008 From: knudsen.thomas at gmail.com (Thomas Knudsen) Date: Thu Aug 21 17:17:54 2008 Subject: [Proj] Polar stereographic, different values on different platforms? In-Reply-To: <1464295a0808211312j41bef9b3ge76bc1b3c981a015@mail.gmail.com> References: <10972083.post@talk.nabble.com> <46659BC7.5010107@pobox.com> <1464295a0808201221u667a5fd4w932c824751f70a09@mail.gmail.com> <18605.8412.462001.560096@cerise.gclements.plus.com> <48AD3C83.95FD.00E4.0@dfg.ca.gov> <48ADA5C1.9020505@pobox.com> <1464295a0808211312j41bef9b3ge76bc1b3c981a015@mail.gmail.com> Message-ID: <7e6835790808211417t28221f15sd601d6df95376813@mail.gmail.com> 2008/8/21 Bruce Raup : > but the colleague I'd just introduced to all these tools is getting a > bad first impression of open source geospatial software (his words). IMHO your colleague has actually rather gotten a bad impression of Microsoft Compilers. Eric Miller's quick diagnosis of the cause of the problem is a wonderful example of what Eric Raymond dubbed Linus' law: "`Given enough eyeballs, all bugs are shallow". Another confirmation of the superiority of the open development method ("bazaar style" for proj vs. "cathedral style" for Microsoft's compilers, to follow Eric Raymond's terminology). Excellent work, Eric Miller! Thomas From brauplists at gmail.com Thu Aug 21 17:49:31 2008 From: brauplists at gmail.com (Bruce Raup) Date: Thu Aug 21 17:49:36 2008 Subject: [Proj] Polar stereographic, different values on different platforms? In-Reply-To: <7e6835790808211417t28221f15sd601d6df95376813@mail.gmail.com> References: <10972083.post@talk.nabble.com> <46659BC7.5010107@pobox.com> <1464295a0808201221u667a5fd4w932c824751f70a09@mail.gmail.com> <18605.8412.462001.560096@cerise.gclements.plus.com> <48AD3C83.95FD.00E4.0@dfg.ca.gov> <48ADA5C1.9020505@pobox.com> <1464295a0808211312j41bef9b3ge76bc1b3c981a015@mail.gmail.com> <7e6835790808211417t28221f15sd601d6df95376813@mail.gmail.com> Message-ID: <1464295a0808211449g1a8786ffr49e834ec297cfa32@mail.gmail.com> Thomas, On Thu, Aug 21, 2008 at 3:17 PM, Thomas Knudsen wrote: > 2008/8/21 Bruce Raup : >> but the colleague I'd just introduced to all these tools is getting a >> bad first impression of open source geospatial software (his words). > > IMHO your colleague has actually rather gotten a bad impression of Microsoft > Compilers. Hopefully, this is now his impression, but the *first* impression was formed before Eric's diagnosis. I tried to set him straight! > Eric Miller's quick diagnosis of the cause of the problem is a wonderful > example of what Eric Raymond dubbed Linus' law: "`Given enough eyeballs, > all bugs are shallow". Another confirmation of the superiority of the open > development method ("bazaar style" for proj vs. "cathedral style" for > Microsoft's > compilers, to follow Eric Raymond's terminology). I agree with this general philosophy. I can't imagine a bug being squashed within 24 hours in a typical proprietary package. However, I see two areas for improvement here: 1) a rigorous test script to test the output of proj against known correct values (within some tolerance). It should test forward and reverse transformations, as many of the projection/datum combinations as is practical, using points from all eight octants of the globe. If this existed (and covered this particular projection), the bug would never have been released. I've offered to make a start at this if this doesn't exist already. 2) Better user documentation. At least one of the docs on the web site is out of date (ftp://ftp.remotesensing.org/proj/OF90-284.pdf says you can say "proj +proj=list" to get a list of projections, but this doesn't work in any version I've seen -- I know it says it's old, but how is a user to know what is out of date and what is not?), and it would be good to have more examples out there to copy. A discussion of how to treat the datum and ellipsoid separately (in cases where they are not the same) would be particularly useful. These issues are even more pressing with GDAL, where the -wktext flag can affect how the underlying proj does its job. There are some good books out there now on some of the higher level packages like MapServer, but I wonder if there are any efforts under way to consolidate and expand the documentation for Proj/GDAL/OGR? I wish I had more time to spend on this kind of thing myself! Thanks, Bruce -- Bruce Raup http://cires.colorado.edu/~braup/ From fanslow at eos.ubc.ca Thu Aug 21 19:50:13 2008 From: fanslow at eos.ubc.ca (Faron Anslow) Date: Thu Aug 21 19:50:13 2008 Subject: [Proj] WGS84 to Sphere Inconsistency Between Proj Versions Message-ID: <48ADFF35.7030501@eos.ubc.ca> Hello, This is my first post to the list, so I hope this hasn't been covered extensively elsewhere (probably has). A Colleague and I are working with an atmospheric reanalysis product (NARR) that is on a fairly odd projection. That projection being lambert conformal conic with a spherical earth with radius of 6371200 m. To assist in projecting site data, DEMs and etc from lat/long WGS84 coords to our spherical projection my colleague has written a matlab interface to the proj library. Our problem arises when we compare reprojected coordinate values from cs2cs or GRASS with the matlab mex file result. For instance, with cs2cs, running: cs2cs +proj=latlong +datum=WGS84 +to +proj=lcc +lat_1=50 +lat_2=50 +lat_0=50 +lon_0=-107 +a=6371200.0000000000 +es=0.0 +f=0.0 +no_defs -r on the coordinates 70.933 -8.667 will yield: 2859697.41 4597308.07 0.00 while our matlab mex file gives: 2873633.37 4593659.17 -12148.43 I suspect the problem is that documented in the FAQ, which requires the addition of +nadgrids=@null to the proj command. However, when I add this to the cs2cs call, the results don't change. When I add it to the mex call, the mex file crashes (not set up to handle the @null I guess). Our question is which result is the correct one? We suspect that a big change in elevation should be expected when switching from the WGS84 ellipsoid to the sphere. cs2cs from proj 4.4 installed on another machine gives results that agree with our mex file. Even stranger is that when we compile the mex file with the line: mex Work/Code/Matlab_tools/cs2cs_proj4.c /usr/lib/libproj.a instead of: mex -l proj /home/fanslow/Work/Code/Matlab_tools/cs2cs_proj4.c the matlab result matches that of the cs2cs command given above. If anyone has any answers, or even if you want to try to project these test coords using your proj install, and send those along, your help would be greatly appreciated. Thanks a ton, Faron -- Post Doctoral Researcher Department of Earth and Ocean Sciences The University of British Columbia 6339 Stores Road Vancouver, British Columbia Canada, V6T 1Z4 604 822 3063 From geraldi.evenden at gmail.com Thu Aug 21 21:18:19 2008 From: geraldi.evenden at gmail.com (Gerald I. Evenden) Date: Thu Aug 21 21:18:27 2008 Subject: [Proj] WGS84 to Sphere Inconsistency Between Proj Versions In-Reply-To: <48ADFF35.7030501@eos.ubc.ca> References: <48ADFF35.7030501@eos.ubc.ca> Message-ID: <200808212118.19139.geraldi.evenden@gmail.com> On Thursday 21 August 2008 7:50:13 pm Faron Anslow wrote: > Hello, > > This is my first post to the list, so I hope this hasn't been covered > extensively elsewhere (probably has). > > A Colleague and I are working with an atmospheric reanalysis product > (NARR) that is on a fairly odd projection. That projection being The projection is not odd, maybe the usage. > lambert conformal conic with a spherical earth with radius of 6371200 > m. To assist in projecting site data, DEMs and etc from lat/long WGS84 > coords to our spherical projection my colleague has written a matlab > interface to the proj library. Our problem arises when we compare > reprojected coordinate values from cs2cs or GRASS with the matlab mex > file result. For instance, with cs2cs, running: > > cs2cs +proj=latlong +datum=WGS84 +to +proj=lcc +lat_1=50 +lat_2=50 > +lat_0=50 +lon_0=-107 +a=6371200.0000000000 +es=0.0 +f=0.0 +no_defs -r Simpler to use proj: proj +proj=lcc +R=6371200 +lat_1=50 +lon_0=-107 -8.667 70.933 2859697.41 4597308.07 where the -8.667 is longitude and 70.933 is latitude. > on the coordinates 70.933 -8.667 will yield: > 2859697.41 4597308.07 0.00 > > while our matlab mex file gives: > 2873633.37 4593659.17 -12148.43 The problem here is what are the projection parameter being used by matlab? What is the "mex" file. If the matlab is projecting with an elliptical earth then the values will be different. But who know what is going on within matlab. Sorry to not be able to help with the matlab stuff other than to point out that you need to know what is going on within that system and how is it projecting the data. > I suspect the problem is that documented in the FAQ, which requires the > addition of +nadgrids=@null to the proj command. However, when I add > this to the cs2cs call, the results don't change. When I add it to the > mex call, the mex file crashes (not set up to handle the @null I > guess). Our question is which result is the correct one? We suspect > that a big change in elevation should be expected when switching from > the WGS84 ellipsoid to the sphere. cs2cs from proj 4.4 installed on > another machine gives results that agree with our mex file. > > Even stranger is that when we compile the mex file with the line: > > mex Work/Code/Matlab_tools/cs2cs_proj4.c /usr/lib/libproj.a > > instead of: > > mex -l proj /home/fanslow/Work/Code/Matlab_tools/cs2cs_proj4.c > > > the matlab result matches that of the cs2cs command given above. > > If anyone has any answers, or even if you want to try to project these > test coords using your proj install, and send those along, your help > would be greatly appreciated. > > > Thanks a ton, > Faron -- The whole religious complexion of the modern world is due to the absence from Jerusalem of a lunatic asylum. -- Havelock Ellis (1859-1939) British psychologist From geraldi.evenden at gmail.com Thu Aug 21 21:33:42 2008 From: geraldi.evenden at gmail.com (Gerald I. Evenden) Date: Thu Aug 21 21:33:50 2008 Subject: [Proj] Polar stereographic, different values on different platforms? In-Reply-To: <1464295a0808211449g1a8786ffr49e834ec297cfa32@mail.gmail.com> References: <10972083.post@talk.nabble.com> <7e6835790808211417t28221f15sd601d6df95376813@mail.gmail.com> <1464295a0808211449g1a8786ffr49e834ec297cfa32@mail.gmail.com> Message-ID: <200808212133.42364.geraldi.evenden@gmail.com> On Thursday 21 August 2008 5:49:31 pm Bruce Raup wrote: > Thomas, > > On Thu, Aug 21, 2008 at 3:17 PM, Thomas Knudsen > > wrote: > > 2008/8/21 Bruce Raup : > >> but the colleague I'd just introduced to all these tools is getting a > >> bad first impression of open source geospatial software (his words). > > > > IMHO your colleague has actually rather gotten a bad impression of > > Microsoft Compilers. > > Hopefully, this is now his impression, but the *first* impression was > formed before Eric's diagnosis. I tried to set him straight! We hope! > > Eric Miller's quick diagnosis of the cause of the problem is a wonderful > > example of what Eric Raymond dubbed Linus' law: "`Given enough eyeballs, > > all bugs are shallow". Another confirmation of the superiority of the > > open development method ("bazaar style" for proj vs. "cathedral style" > > for Microsoft's > > compilers, to follow Eric Raymond's terminology). > > I agree with this general philosophy. I can't imagine a bug being > squashed within 24 hours in a typical proprietary package. > > However, I see two areas for improvement here: > > 1) a rigorous test script to test the output of proj against known > correct values (within some tolerance). It should test forward and > reverse transformations, as many of the projection/datum combinations > as is practical, using points from all eight octants of the globe. If > this existed (and covered this particular projection), the bug would > never have been released. I've offered to make a start at this if > this doesn't exist already. There once was test material for GCTP that I occasionally used in the early stages of proj4. I'm not sure they are still around. The data only covered US state plane systems and thus only a few projections. There are some problems with doing a general test of projections. One of them is the detail that some projections have several options which complicates the process. Another detail is that a testing software must allow for precision of testing and "round trip" precision. > 2) Better user documentation. At least one of the docs on the web > site is out of date (ftp://ftp.remotesensing.org/proj/OF90-284.pdf My goodness, it is still around in spite of some changes in the system. My current efforts are slow and at 128 pages less than half way through the effort. Even the last copy is not up to date as it uses the old pj_ rather than proj_ namespace. Right now I am trying to redo the Transverse Mercator section (now about 8 pages) which may only be half done. Currently delayed by getting used to an updated OS, reinstalling software and trying to figure out how to do some non-map graphics. > says you can say "proj +proj=list" to get a list of projections, but That's part of the problem of being of the Open-File report being woefully out of date. Try "[l]proj -lp". Oops. That only works on my sources. Dunno about other distributions. See. That is also part of the problem(s). I go by a very broadly dated release number (currently proj4.3) and a tightly spec'd distribution date which is part of the distribution tarball name. As I recall, 4.3 occurred when it went to proj_ name space. > this doesn't work in any version I've seen -- I know it says it's old, > but how is a user to know what is out of date and what is not?), and > it would be good to have more examples out there to copy. A discussion > of how to treat the datum and ellipsoid separately (in cases where > they are not the same) would be particularly useful. These issues are > even more pressing with GDAL, where the -wktext flag can affect how > the underlying proj does its job. Of course there is also an underlying problem in that original proj *and* my current software does not have anything to do with datums. Inclusion of datum conversion was the work of others. The reasons have been exhaustively discussed before. This is one of the basic problems with all discussions about "proj[4]". For most of you, the discussion is about software that contains a good deal of what of the "proj" that I am very familiar with but there is also a good deal of value added 'stuff" I know nothing about. > There are some good books out there now on some of the higher level > packages like MapServer, but I wonder if there are any efforts under > way to consolidate and expand the documentation for Proj/GDAL/OGR? I > wish I had more time to spend on this kind of thing myself! Glad to jaw about this at any time. Perhaps we should also review some old issues and see where things are going. > Thanks, > Bruce -- The whole religious complexion of the modern world is due to the absence from Jerusalem of a lunatic asylum. -- Havelock Ellis (1859-1939) British psychologist From fanslow at eos.ubc.ca Thu Aug 21 21:51:12 2008 From: fanslow at eos.ubc.ca (Faron Anslow) Date: Thu Aug 21 21:51:11 2008 Subject: [Proj] WGS84 to Sphere Inconsistency Between Proj Versions In-Reply-To: <200808212118.19139.geraldi.evenden@gmail.com> References: <48ADFF35.7030501@eos.ubc.ca> <200808212118.19139.geraldi.evenden@gmail.com> Message-ID: <48AE1B90.70500@eos.ubc.ca> Hi Gerald, Thanks for looking at this. Looks like your proj reprojection matches my result, which is encouraging. Would you go out on a limb and say this is the "right answer"? The Matlab function we built passes identical projection parameters into the proj library as I pass to cs2cs or proj or define in GRASS GIS. I looked closer, and compiling the mex file as mex -l proj /home/fanslow/Work/Code/Matlab_tools/cs2cs_proj4.c uses matlab's version of the PROJ.4 library, which is of uknown origin. My other method uses the library that I compiled (PROJ 4.6). (FYI a mex file is an interface between matlab and other programming languages). I guess the main question here is why one version of proj gives different values than another when passed identical projection parameters? We have Matlab's version (comes with the mapping toolbox) and then we have the one I compiled giving different results. Do you know if there was a change in how proj handled moving from an ellipse to sphere since version 4.4? Thanks again. --Faron Gerald I. Evenden wrote: > On Thursday 21 August 2008 7:50:13 pm Faron Anslow wrote: > >> Hello, >> >> This is my first post to the list, so I hope this hasn't been covered >> extensively elsewhere (probably has). >> >> A Colleague and I are working with an atmospheric reanalysis product >> (NARR) that is on a fairly odd projection. That projection being >> > > The projection is not odd, maybe the usage. > > >> lambert conformal conic with a spherical earth with radius of 6371200 >> m. To assist in projecting site data, DEMs and etc from lat/long WGS84 >> coords to our spherical projection my colleague has written a matlab >> interface to the proj library. Our problem arises when we compare >> reprojected coordinate values from cs2cs or GRASS with the matlab mex >> file result. For instance, with cs2cs, running: >> >> cs2cs +proj=latlong +datum=WGS84 +to +proj=lcc +lat_1=50 +lat_2=50 >> +lat_0=50 +lon_0=-107 +a=6371200.0000000000 +es=0.0 +f=0.0 +no_defs -r >> > > Simpler to use proj: > proj +proj=lcc +R=6371200 +lat_1=50 +lon_0=-107 > -8.667 70.933 > 2859697.41 4597308.07 > > where the -8.667 is longitude and 70.933 is latitude. > > >> on the coordinates 70.933 -8.667 will yield: >> 2859697.41 4597308.07 0.00 >> >> while our matlab mex file gives: >> 2873633.37 4593659.17 -12148.43 >> > > The problem here is what are the projection parameter being used by matlab? > What is the "mex" file. If the matlab is projecting with an elliptical earth > then the values will be different. But who know what is going on within > matlab. > > Sorry to not be able to help with the matlab stuff other than to point out > that you need to know what is going on within that system and how is it > projecting the data. > > >> I suspect the problem is that documented in the FAQ, which requires the >> addition of +nadgrids=@null to the proj command. However, when I add >> this to the cs2cs call, the results don't change. When I add it to the >> mex call, the mex file crashes (not set up to handle the @null I >> guess). Our question is which result is the correct one? We suspect >> that a big change in elevation should be expected when switching from >> the WGS84 ellipsoid to the sphere. cs2cs from proj 4.4 installed on >> another machine gives results that agree with our mex file. >> >> Even stranger is that when we compile the mex file with the line: >> >> mex Work/Code/Matlab_tools/cs2cs_proj4.c /usr/lib/libproj.a >> >> instead of: >> >> mex -l proj /home/fanslow/Work/Code/Matlab_tools/cs2cs_proj4.c >> >> >> the matlab result matches that of the cs2cs command given above. >> >> If anyone has any answers, or even if you want to try to project these >> test coords using your proj install, and send those along, your help >> would be greatly appreciated. >> >> >> Thanks a ton, >> Faron >> > > > > -- Post Doctoral Researcher Department of Earth and Ocean Sciences The University of British Columbia 6339 Stores Road Vancouver, British Columbia Canada, V6T 1Z4 604 822 3063 From warmerdam at pobox.com Thu Aug 21 22:15:54 2008 From: warmerdam at pobox.com (Frank Warmerdam) Date: Thu Aug 21 22:16:30 2008 Subject: [Proj] WGS84 to Sphere Inconsistency Between Proj Versions In-Reply-To: <48ADFF35.7030501@eos.ubc.ca> References: <48ADFF35.7030501@eos.ubc.ca> Message-ID: <48AE215A.9040802@pobox.com> Faron Anslow wrote: > Hello, > > This is my first post to the list, so I hope this hasn't been covered > extensively elsewhere (probably has). > > A Colleague and I are working with an atmospheric reanalysis product > (NARR) that is on a fairly odd projection. That projection being > lambert conformal conic with a spherical earth with radius of 6371200 > m. To assist in projecting site data, DEMs and etc from lat/long WGS84 > coords to our spherical projection my colleague has written a matlab > interface to the proj library. Our problem arises when we compare > reprojected coordinate values from cs2cs or GRASS with the matlab mex > file result. For instance, with cs2cs, running: > > cs2cs +proj=latlong +datum=WGS84 +to +proj=lcc +lat_1=50 +lat_2=50 > +lat_0=50 +lon_0=-107 +a=6371200.0000000000 +es=0.0 +f=0.0 +no_defs -r > > on the coordinates 70.933 -8.667 will yield: > 2859697.41 4597308.07 0.00 > > while our matlab mex file gives: > 2873633.37 4593659.17 -12148.43 Faron, In PROJ 4.6.0 and later the cs2cs command (and pj_transform()) will no longer attempt to apply any datum shift or change of ellipsoid transformation unless both the source and destination coordinate system have meaningful datum definitions provided (either +towgs84 or +nadgrids). > I suspect the problem is that documented in the FAQ, which requires the > addition of +nadgrids=@null to the proj command. However, when I add > this to the cs2cs call, the results don't change. When I add it to the > mex call, the mex file crashes (not set up to handle the @null I > guess). Our question is which result is the correct one? We suspect > that a big change in elevation should be expected when switching from > the WGS84 ellipsoid to the sphere. cs2cs from proj 4.4 installed on > another machine gives results that agree with our mex file. > > Even stranger is that when we compile the mex file with the line: > > mex Work/Code/Matlab_tools/cs2cs_proj4.c /usr/lib/libproj.a > > instead of: > > mex -l proj /home/fanslow/Work/Code/Matlab_tools/cs2cs_proj4.c I can only conclude that when you link against the static library you get one version, while the other link command is using a shared library and you end up picking up a different version of libproj.so. It isn't easy to deduce your build configuration, but basically I believe this comes down to the announced change of behavior between PROJ 4.5 and PROJ 4.6. Best regards, -- ---------------------------------------+-------------------------------------- I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush | Geospatial Programmer for Rent From hamish_b at yahoo.com Thu Aug 21 22:21:42 2008 From: hamish_b at yahoo.com (Hamish) Date: Thu Aug 21 22:21:50 2008 Subject: [Proj] WGS84 to Sphere Inconsistency Between Proj Versions In-Reply-To: <48ADFF35.7030501@eos.ubc.ca> Message-ID: <4261.21926.qm@web110009.mail.gq1.yahoo.com> Faron Anslow wrote: > A Colleague and I are working with an atmospheric > reanalysis product (NARR) that is on a fairly odd projection. > That projection being lambert conformal conic with a spherical > earth with radius of 6371200 m. It's not LCC, but I wonder if similar scripts written for Smith & Sandwell's bathymetry data could help? (wrt @null usage) http://topex.ucsd.edu/marine_topo/mar_topo.html is there any code with the data for interfacing with GMT mapping? Maybe some clues there. > To assist in projecting site data, DEMs and etc from lat/long > WGS84 coords to our spherical projection my colleague has > written a matlab interface to the proj library. Any thoughts on publishing that as open source? I'd be interested to see that; currently for working with PROJ.4 from within Matlab we just make a series of system calls to cs2cs. But it's a bit of a clunky solution. Either like: [exitcode, result] = system('cs2cs +parameters < inputfile.txt') or with !cs2cs as in this script: http://ou035063.otago.ac.nz/twiki/bin/view/MarineScience/Cs2csFromMatlab (fairly straight forward, just MS Windows needs the environment set; adapted from the FWTools .bat setup file) I've never used it, but seem to recall reading that Matlab's mapping toolbox uses PROJ. > Our question is which result is the correct one? Getting it working with confidence via cs2cs seems like a good first approach, i.e. minimize the unknown variables. > We suspect that a big change in elevation should be expected > when switching from the WGS84 ellipsoid to the sphere. Right. > cs2cs from proj 4.4 installed on > another machine gives results that agree with our mex file. how about proj 4.5 on that other machine? IIRC between those releases proj.4 changed the way it dealt with situations where datum transform params were given on one side of the "+to" but no the other. Best to specify that on both sides if you can. > Even stranger is that when we compile the mex file with the > line: > mex Work/Code/Matlab_tools/cs2cs_proj4.c /usr/lib/libproj.a > > instead of: > mex -l proj /home/fanslow/Work/Code/Matlab_tools/cs2cs_proj4.c > > the matlab result matches that of the cs2cs command given > above. hmmm. > Department of Earth and Ocean Sciences > The University of British Columbia good memories of the dept, from many many years ago. (pre-Earth&) regards, Hamish From warmerdam at pobox.com Thu Aug 21 22:24:27 2008 From: warmerdam at pobox.com (Frank Warmerdam) Date: Thu Aug 21 22:24:42 2008 Subject: [Proj] Polar stereographic, different values on different platforms? In-Reply-To: <1464295a0808211449g1a8786ffr49e834ec297cfa32@mail.gmail.com> References: <10972083.post@talk.nabble.com> <46659BC7.5010107@pobox.com> <1464295a0808201221u667a5fd4w932c824751f70a09@mail.gmail.com> <18605.8412.462001.560096@cerise.gclements.plus.com> <48AD3C83.95FD.00E4.0@dfg.ca.gov> <48ADA5C1.9020505@pobox.com> <1464295a0808211312j41bef9b3ge76bc1b3c981a015@mail.gmail.com> <7e6835790808211417t28221f15sd601d6df95376813@mail.gmail.com> <1464295a0808211449g1a8786ffr49e834ec297cfa32@mail.gmail.com> Message-ID: <48AE235B.1090306@pobox.com> Bruce Raup wrote: > I agree with this general philosophy. I can't imagine a bug being > squashed within 24 hours in a typical proprietary package. Bruce, While it is rare, when I worked at PCI it was not that uncommon for me to fix a bug reported by a user, and post a fixed shared library within 24 hours. For whatever reason, the concept of providing fixed binaries does not seem very common with larger proprietary software packages these days (or perhaps I just don't see it). Nevertheless, I think speed of bug fixing is a strength of open source, especially for a savvy user willing to rebuild from "trunk". > However, I see two areas for improvement here: > > 1) a rigorous test script to test the output of proj against known > correct values (within some tolerance). It should test forward and > reverse transformations, as many of the projection/datum combinations > as is practical, using points from all eight octants of the globe. If > this existed (and covered this particular projection), the bug would > never have been released. I've offered to make a start at this if > this doesn't exist already. We have a modest test suite in the proj/nad directory (do "make check") but unfortunately it is not convenient to run on win32/msvc builds since it depends on a unix style shell. It is my hope that the MetaCRS project will publish "test data files" at some point which each of the software packages (proj.4, csmap, proj4js,geotools) can use as a base for a substantial regression test. > 2) Better user documentation. At least one of the docs on the web > site is out of date (ftp://ftp.remotesensing.org/proj/OF90-284.pdf > says you can say "proj +proj=list" to get a list of projections, but > this doesn't work in any version I've seen -- I know it says it's old, > but how is a user to know what is out of date and what is not?), and > it would be good to have more examples out there to copy. A discussion > of how to treat the datum and ellipsoid separately (in cases where > they are not the same) would be particularly useful. These issues are > even more pressing with GDAL, where the -wktext flag can affect how > the underlying proj does its job. Agreed. Note that the PROJ.4 web site is now just a trac wiki, and anyone can get a userid and start improving it. I no longer need to be the bottleneck! > There are some good books out there now on some of the higher level > packages like MapServer, but I wonder if there are any efforts under > way to consolidate and expand the documentation for Proj/GDAL/OGR? I > wish I had more time to spend on this kind of thing myself! There is no much of an effort in this regard. Especially in the area of examples, and FAQ types docs, I'm very keen on getting more people contributing, even if rather casually. For GDAL there is a reasonable ongoing effort to maintain decent reference docs, but these are not really filling all the needs of the users. Best regards, -- ---------------------------------------+-------------------------------------- I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush | Geospatial Programmer for Rent From warmerdam at pobox.com Thu Aug 21 22:32:07 2008 From: warmerdam at pobox.com (Frank Warmerdam) Date: Thu Aug 21 22:32:27 2008 Subject: [Proj] PROJ 4.6.1RC2 Available Message-ID: <48AE2527.4090305@pobox.com> Folks, A month after 4.6.1 RC 1 I have prepared a new release candidate. This candidate includes the nmake.opt fix for stere recently discussed, as well as (I understand) resolves the issue of libproj and proj.4 having different approaches to Gauss Laborde projection as described in: http://trac.osgeo.org/proj/ticket/8 The new release candidate is available at: http://download.osgeo.org/proj/proj-4.6.1RC2.tar.gz If there are no objections noted in the next couple days, I'll plan to promote this to 4.6.1 final. I think I mentioned this earlier, but there is also a new version of the datum grid collection at: http://download.osgeo.org/proj/proj-datumgrid-1.4.tar.gz http://download.osgeo.org/proj/proj-datumgrid-1.4.zip Which includes the NTF grid. Best regards, -- ---------------------------------------+-------------------------------------- I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush | Geospatial Programmer for Rent From fanslow at eos.ubc.ca Thu Aug 21 23:00:08 2008 From: fanslow at eos.ubc.ca (Faron Anslow) Date: Thu Aug 21 23:00:06 2008 Subject: [Proj] WGS84 to Sphere Inconsistency Between Proj Versions In-Reply-To: <48AE215A.9040802@pobox.com> References: <48ADFF35.7030501@eos.ubc.ca> <48AE215A.9040802@pobox.com> Message-ID: <48AE2BB8.2090802@eos.ubc.ca> Frank Warmerdam wrote: > > Faron, > > In PROJ 4.6.0 and later the cs2cs command (and pj_transform()) will > no longer attempt to apply any datum shift or change of ellipsoid > transformation unless both the source and destination coordinate system > have meaningful datum definitions provided (either +towgs84 or > +nadgrids). > Hi Frank, This makes sense to me and explains the difference between versions. I would guess that the version of proj that matlab uses and that the mex file links against when "-l proj" is given is an older version of proj.4. The question then is if it is more correct to not have the datum shift applied (and get the values I get from cs2cs as specified earlier) or to have the datum shift applied and get the value with the very negative elevation and different northing and eastings? >> I suspect the problem is that documented in the FAQ, which requires >> the addition of +nadgrids=@null to the proj command. However, when I >> add this to the cs2cs call, the results don't change. When I add it >> to the mex call, the mex file crashes (not set up to handle the @null >> I guess). Our question is which result is the correct one? We >> suspect that a big change in elevation should be expected when >> switching from the WGS84 ellipsoid to the sphere. cs2cs from proj >> 4.4 installed on another machine gives results that agree with our >> mex file. >> >> Even stranger is that when we compile the mex file with the line: >> >> mex Work/Code/Matlab_tools/cs2cs_proj4.c /usr/lib/libproj.a >> >> instead of: >> >> mex -l proj /home/fanslow/Work/Code/Matlab_tools/cs2cs_proj4.c > > I can only conclude that when you link against the static library > you get one version, while the other link command is using a shared > library and you end up picking up a different version of libproj.so. > > It isn't easy to deduce your build configuration, but basically I > believe this comes down to the announced change of behavior between > PROJ 4.5 and PROJ 4.6. > > Best regards, I agree as above. Using "-l proj" links to the matlab mapping toolbox library, which probably is older than the library I compiled a few days ago. I just ran this: cs2cs +proj=latlong +datum=WGS84 +to +proj=lcc +lat_1=50 +lat_2=50 +lat_0=50 +lon_0=-107 +a=6371200.0000000000 +es=0.0 +f=0.0 +towgs84=0,0,0 -r on: 70.933 -8.667 and got: 2873633.37 4593659.18 -12148.43 which is my original matlab answer and that from the old proj4.4. Now, the question is if forcing the datum shift with +towgs=0,0,0 is appropriate? Doesn't +towgs48 conflict with/override the spherical projection definition? Thanks, Faron -- Post Doctoral Researcher Department of Earth and Ocean Sciences The University of British Columbia 6339 Stores Road Vancouver, British Columbia Canada, V6T 1Z4 604 822 3063 From warmerdam at pobox.com Thu Aug 21 23:38:50 2008 From: warmerdam at pobox.com (Frank Warmerdam) Date: Thu Aug 21 23:39:04 2008 Subject: [Proj] WGS84 to Sphere Inconsistency Between Proj Versions In-Reply-To: <48AE2BB8.2090802@eos.ubc.ca> References: <48ADFF35.7030501@eos.ubc.ca> <48AE215A.9040802@pobox.com> <48AE2BB8.2090802@eos.ubc.ca> Message-ID: <48AE34CA.5020308@pobox.com> Faron Anslow wrote: > I just ran this: > > cs2cs +proj=latlong +datum=WGS84 +to +proj=lcc +lat_1=50 +lat_2=50 > +lat_0=50 +lon_0=-107 +a=6371200.0000000000 +es=0.0 +f=0.0 > +towgs84=0,0,0 -r > > on: > 70.933 -8.667 > > and got: > 2873633.37 4593659.18 -12148.43 > > which is my original matlab answer and that from the old proj4.4. Now, > the question is if forcing the datum shift with +towgs=0,0,0 is > appropriate? Doesn't +towgs48 conflict with/override the spherical > projection definition? Faron, I can't imagine any situation other than an effort to match old answers where it makes sense to apply a plain lat/long on a sphere to lat/long on an ellipsoid conversion the way this is doing. If you want the lat/long values computed from the lcc projection based on a sphere to treated as WGS84, then use +nadgrids=@null (or in 4.6.0 just omit a datum specifier for the lcc projection). This is *likely* want you want. Best regards, -- ---------------------------------------+-------------------------------------- I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush | Geospatial Programmer for Rent From cjmce at lsu.edu Thu Aug 21 23:45:24 2008 From: cjmce at lsu.edu (Clifford J Mugnier) Date: Thu Aug 21 23:46:56 2008 Subject: [Proj] WGS84 to Sphere Inconsistency Between Proj Versions References: <48ADFF35.7030501@eos.ubc.ca> <48AE215A.9040802@pobox.com> <48AE2BB8.2090802@eos.ubc.ca> <48AE34CA.5020308@pobox.com> Message-ID: When didling with spherical projections, the concept of "DATUM" is entirely inappropriate. Cliff Mugnier LOUISIANA STATE UNIVERSITY ________________________________ From: proj-bounces@lists.maptools.org on behalf of Frank Warmerdam Sent: Thu 21-Aug-08 22:38 To: PROJ.4 and general Projections Discussions Subject: Re: [Proj] WGS84 to Sphere Inconsistency Between Proj Versions Faron Anslow wrote: > I just ran this: > > cs2cs +proj=latlong +datum=WGS84 +to +proj=lcc +lat_1=50 +lat_2=50 > +lat_0=50 +lon_0=-107 +a=6371200.0000000000 +es=0.0 +f=0.0 > +towgs84=0,0,0 -r > > on: > 70.933 -8.667 > > and got: > 2873633.37 4593659.18 -12148.43 > > which is my original matlab answer and that from the old proj4.4. Now, > the question is if forcing the datum shift with +towgs=0,0,0 is > appropriate? Doesn't +towgs48 conflict with/override the spherical > projection definition? Faron, I can't imagine any situation other than an effort to match old answers where it makes sense to apply a plain lat/long on a sphere to lat/long on an ellipsoid conversion the way this is doing. If you want the lat/long values computed from the lcc projection based on a sphere to treated as WGS84, then use +nadgrids=@null (or in 4.6.0 just omit a datum specifier for the lcc projection). This is *likely* want you want. Best regards, -- ---------------------------------------+-------------------------------------- I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush | Geospatial Programmer for Rent _______________________________________________ Proj mailing list Proj@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/20080821/b5354aab/attachment.html From warmerdam at pobox.com Fri Aug 22 00:24:50 2008 From: warmerdam at pobox.com (Frank Warmerdam) Date: Fri Aug 22 00:25:11 2008 Subject: [Proj] Re: PROJ 4.6.1RC2 Available In-Reply-To: <48AE2527.4090305@pobox.com> References: <48AE2527.4090305@pobox.com> Message-ID: <48AE3F92.3080805@pobox.com> Frank Warmerdam wrote: > Folks, > > A month after 4.6.1 RC 1 I have prepared a new release candidate. This > candidate includes the nmake.opt fix for stere recently discussed, as well > as (I understand) resolves the issue of libproj and proj.4 having different > approaches to Gauss Laborde projection as described in: > > http://trac.osgeo.org/proj/ticket/8 > > The new release candidate is available at: > > http://download.osgeo.org/proj/proj-4.6.1RC2.tar.gz Folks, Sorry for the churn, but I discovered that PROJ 4.6.1RC2 lacked a few win32 build files. I have produced an RC3 and made it available: http://download.osgeo.org/proj/proj-4.6.1RC3.tar.gz I would add that OSGeo4W has been updated to use 4.6.1RC3, so feel free to test these windows binaries. http://trac.osgeo.org/osgeo4w/ Best regards, -- ---------------------------------------+-------------------------------------- I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush | Geospatial Programmer for Rent From strebe at aol.com Fri Aug 22 01:06:04 2008 From: strebe at aol.com (strebe) Date: Fri Aug 22 01:06:20 2008 Subject: [Proj] Re: Polar stereographic, different values on different platforms? In-Reply-To: <48AE235B.1090306@pobox.com> Message-ID: <55A0B21B.388A.4302.9008.0EBCC27E62A2@aol.com> On Aug 21, 2008, at 7:24:27 PM, "Frank Warmerdam" wrote: Bruce Raup wrote: > I agree with this general philosophy. I can't imagine a bug being > squashed within 24 hours in a typical proprietary package. ... For whatever reason, the concept of providing fixed binaries does not seem very common with larger proprietary software packages these days (or perhaps I just don't see it). Nevertheless, I think speed of bug fixing is a strength of open source, especially for a savvy user willing to rebuild from "trunk". It is a problem of responsibility. Many bug fixes introduce new bugs, occasionally far, far from the location of the fix. A propriety vendor feels responsible for the consequences of a bug fix and often ends up exhaustively testing the entire binary for any bug fix(es) that go into a build. Hence it is most common for a propriety vendor to roll up several bug fixes into one release so that the exhaustive testing can be amortized over many bugs. Of course, it takes time to accumulate many bug fixes. Hence it takes time for new releases. Regards, -- daan Strebe -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.maptools.org/pipermail/proj/attachments/20080821/ddaa9625/attachment.html From glynn at gclements.plus.com Fri Aug 22 07:13:29 2008 From: glynn at gclements.plus.com (Glynn Clements) Date: Fri Aug 22 07:13:34 2008 Subject: [Proj] Polar stereographic, different values on different platforms? In-Reply-To: <48AE235B.1090306@pobox.com> References: <10972083.post@talk.nabble.com> <46659BC7.5010107@pobox.com> <1464295a0808201221u667a5fd4w932c824751f70a09@mail.gmail.com> <18605.8412.462001.560096@cerise.gclements.plus.com> <48AD3C83.95FD.00E4.0@dfg.ca.gov> <48ADA5C1.9020505@pobox.com> <1464295a0808211312j41bef9b3ge76bc1b3c981a015@mail.gmail.com> <7e6835790808211417t28221f15sd601d6df95376813@mail.gmail.com> <1464295a0808211449g1a8786ffr49e834ec297cfa32@mail.gmail.com> <48AE235B.1090306@pobox.com> Message-ID: <18606.40793.45521.323187@cerise.gclements.plus.com> Frank Warmerdam wrote: > > However, I see two areas for improvement here: > > > > 1) a rigorous test script to test the output of proj against known > > correct values (within some tolerance). It should test forward and > > reverse transformations, as many of the projection/datum combinations > > as is practical, using points from all eight octants of the globe. If > > this existed (and covered this particular projection), the bug would > > never have been released. I've offered to make a start at this if > > this doesn't exist already. > > We have a modest test suite in the proj/nad directory (do "make check") > but unfortunately it is not convenient to run on win32/msvc builds > since it depends on a unix style shell. > > It is my hope that the MetaCRS project will publish "test data files" > at some point which each of the software packages (proj.4, csmap, > proj4js,geotools) can use as a base for a substantial regression test. Even if you lack external test data, testing different versions and different builds of the program against each other can often detect problems; it would certainly have caught this one. Comparing the results of debug and optimised builds is always a good idea, particularly for numerical software. If you look at the errata when a new version of a compiler is released, it's invariably the case that most of bugs only applied when optimisation was enabled. FWIW, i'm really curious about how the lack of that option came to result in an error of 32km. The description of the /Op option suggests that it's the same as -ffloat-store on gcc. But gcc gives the same answer (to 2 decimal places, i.e. centimetre precision) with or without that option. It also gives the same answer with -funsafe-math-optimizations, which can introduce more substantial errors (e.g. it allows replacing x/y with x*(1/y)). That suggests that it isn't just a case of minor rounding errors exploding due to algorithmic instability. I also note that the documentation for /Op says: http://msdn.microsoft.com/en-us/library/aa984742(VS.71).aspx Note The /Op option disables inline generation of floating-point functions. The standard run-time library routines are used instead. For more information, see the /Oi option. The documentation for /Oi says: http://msdn.microsoft.com/en-us/library/f99tchzc(VS.71).aspx The floating-point functions listed below do not have true intrinsic forms. If you use the Generate Intrinsic Functions option, the listed functions are replaced with versions that pass arguments directly to the floating-point chip rather than pushing them onto the program stack: acos cosh pow tanh asin fmod sinh The floating-point functions listed below have true intrinsic forms when you specify both /Oi and /Og (or any option that includes /Og: /Ox, /O1, and /O2): atan exp sin atan2 log sqrt cos log10 tan Switching to an inline implementation would seem to provide more scope for substantial errors. It would also mean that the issue would never be observed with gcc, as the problem would be in code generated by MSVC rather than in the run-time. -- Glynn Clements From tutey at o2.pl Fri Aug 22 10:38:33 2008 From: tutey at o2.pl (Maciej Sieczka) Date: Fri Aug 22 10:37:02 2008 Subject: [Proj] Re: PROJ 4.6.1RC2 Available In-Reply-To: <48AE3F92.3080805@pobox.com> References: <48AE2527.4090305@pobox.com> <48AE3F92.3080805@pobox.com> Message-ID: <48AECF69.7090905@o2.pl> Hi, Is a fix for "ETRS89-based CRSs missing datum definition" included? [1]http://trac.osgeo.org/proj/ticket/11 Maciek -- Maciej Sieczka www.sieczka.org From tutey at o2.pl Fri Aug 22 10:44:21 2008 From: tutey at o2.pl (Maciej Sieczka) Date: Fri Aug 22 10:42:49 2008 Subject: [Proj] Trac does not post replies Message-ID: <48AED0C5.4030002@o2.pl> Hi After opening the ticket in PROJ.4 Trac [1] I never got an email notification of replies, while there were 2. Other OSGEO Trac (GDAL, GRASS) instances send emails at replies. [1]http://trac.osgeo.org/proj/ticket/11 -- Maciej Sieczka www.sieczka.org From warmerdam at pobox.com Fri Aug 22 11:03:56 2008 From: warmerdam at pobox.com (Frank Warmerdam) Date: Fri Aug 22 11:04:27 2008 Subject: [Proj] Re: PROJ 4.6.1RC2 Available In-Reply-To: <48AECF69.7090905@o2.pl> References: <48AE2527.4090305@pobox.com> <48AE3F92.3080805@pobox.com> <48AECF69.7090905@o2.pl> Message-ID: <48AED55C.8000004@pobox.com> Maciej Sieczka wrote: > Hi, > > Is a fix for "ETRS89-based CRSs missing datum definition" included? > > [1]http://trac.osgeo.org/proj/ticket/11 Maciek, No, that issue is not resolved yet (as is implied in the ticket). Best regards, -- ---------------------------------------+-------------------------------------- I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush | Geospatial Programmer for Rent From warmerdam at pobox.com Fri Aug 22 11:33:45 2008 From: warmerdam at pobox.com (Frank Warmerdam) Date: Fri Aug 22 11:34:10 2008 Subject: [Proj] Trac does not post replies In-Reply-To: <48AED0C5.4030002@o2.pl> References: <48AED0C5.4030002@o2.pl> Message-ID: <48AEDC59.9000100@pobox.com> Maciej Sieczka wrote: > Hi > > After opening the ticket in PROJ.4 Trac [1] I never got an email > notification of replies, while there were 2. Other OSGEO Trac (GDAL, > GRASS) instances send emails at replies. > > [1]http://trac.osgeo.org/proj/ticket/11 Maciek, Thanks for pointing that out. I think I have it enabled now, let me know if you don't get a test message on ticket 11. Best regards, -- ---------------------------------------+-------------------------------------- I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush | Geospatial Programmer for Rent From tf at ttqv.com Fri Aug 22 12:25:28 2008 From: tf at ttqv.com (Thomas Flemming) Date: Fri Aug 22 12:25:36 2008 Subject: [Proj] Projection of Airial images by reference points Message-ID: <48AEE878.5010602@ttqv.com> Hello, I would like to know, if the proj-libary might also have a function to give a projection of images or scanned maps where the geographical projection is unknown but where only some reference points are known. For example I have some aerial images where I exactly know at least 4 or even more points on the ground with there geographical coordinates. I would like to have a "projection", like latlon2xy and xy2latlon for all points of the image according to the known reference points. Something like polynom-approximation? Is there such thing already in proj? Best regards, Thomas -- /**************************************** ** Dipl.-Ing. Thomas Flemming ** Software Development ** ** Touratech AG ** Auf dem Zimmermann 7-9 ** D-78078 Niedereschach ** ** mail tf@ttqv.com ** fon +49 (0) 7728 9279-206 ** fax +49 (0) 7728 9279-29 ** ** http://www.ttqv.com ** http://www.touratech.de ** ** ... und immer dem Pfeil nach! ***************************************/ From shgeo at online.de Sat Aug 23 06:39:07 2008 From: shgeo at online.de (Sebastian Holler) Date: Sat Aug 23 06:39:38 2008 Subject: [Proj] dealing with EPSG axis order Message-ID: <48AFE8CB.8070209@online.de> Hi list, working on a WMS server that shall provide the WMS version 1.3.0 in future, I noticed, that the "axis order problem" [1] seems to be a big barrier in the implementation of this standard. For dealing with the bbox parameter in a correct way, it is necessary that the program has information about the order of the comma separated values inside, depending on the respective EPSG code. The easiest way is the creation of a file that stores this information for all EPSG codes. I think that many projects would be benefit from this additional information, so the proj4 package is possibly the best place for this file, because I assume it is installed on most systems, that deals with free gis software. One possibility is the introduction of a new parameter (+axis_order) in the already existing epsg file. Here is a example: # Unknown datum based upon the Airy 1830 ellipsoid <4001> +proj=longlat +ellps=airy +no_defs +axis_order=latlon <> # NAD83(HARN) / North Carolina <3358> +proj=lcc +lat_1=36.16666666666666 +lat_2=34.33333333333334 +lat_0=33.75 +lon_0=-79 +x_0=609601.22 +y_0=0 +ellps=GRS80 +units=m +no_defs +axis_order=EN <> # KKJ / Finland Uniform Coordinate System <2393> +proj=tmerc +lat_0=0 +lon_0=27 +k=1 +x_0=3500000 +y_0=0 +ellps=intl +towgs84=-96.0617,-82.4278,-121.743,4.80107,0.34543,-1.37646,1.4964 +units=m +no_defs +axis_order=NE <> # S-JTSK (Ferro) / Krovak <2065> +proj=krovak +lat_0=49.5 +lon_0=42.5 +alpha=30.28813972222222 +k=0.9999 +x_0=0 +y_0=0 +ellps=bessel +pm=ferro +units=m +no_defs +axis_order=SW <> (For testing purposes I've written a python script that inserts the new parameter for each EPSG code automatially.) But I don't know if a new parameter in the epsg file has any negative effect on other programs using this file. So it could maybe be better to store this information in a separate file (in the same directory). If someone is interested in, I'll fill in an Open Enhancement Request. Regards, Sebastian H. [1]: http://geotools.codehaus.org/The+axis+order+issue From geraldi.evenden at gmail.com Sun Aug 24 22:05:10 2008 From: geraldi.evenden at gmail.com (Gerald I. Evenden) Date: Sun Aug 24 22:05:20 2008 Subject: [Proj] Extended range TM usage Message-ID: <200808242205.10683.geraldi.evenden@gmail.com> -- The whole religious complexion of the modern world is due to the absence from Jerusalem of a lunatic asylum. -- Havelock Ellis (1859-1939) British psychologist From geraldi.evenden at gmail.com Sun Aug 24 22:08:03 2008 From: geraldi.evenden at gmail.com (Gerald I. Evenden) Date: Sun Aug 24 22:08:10 2008 Subject: [Proj] Extended range TM usage Message-ID: <200808242208.03435.geraldi.evenden@gmail.com> I am finishing up the revised transverse Mercator section of libproj4's manual which includes three additional versions of the projection that give an extended longitude range for the projection. These version persist in being singular at the equator and 90 degrees from the central meridian. Hopefully, I may soon obtain a copy of Lee's work and include the Ultimate version. The old Taylor series version (tmerc) of TM is shown to be quite adequate for cadestral applications as demonstrated by comparisons with the expanded versions, That is, it has sub-millimeter accuracy within all longitude zones of standard applications that I am aware of. At the current time I consider the work on the extended version academic and of little practical application for the following reason: scale error of TM beyond an easting of about 400km (approximately 3.5 degrees longitude at the equator) would appear too large to make the projection useful in any application other than general mapping. If general mapping is the application then using the spherical form of tmerc should be adequate---especially for small scale maps. The problem of the singularity of the projection at (+-90,0) is not a problem because the distortion is so severe at the right and left edges the sides can be clipped. My question is can anyone supply a rational reason for the practical use of an elliptical TM projection with extended longitude range. The explanation should discuss how the projected coordinates are used and how the error factor is handled in application of the coordinates (like determining distance between points, azimuth, etc.). Of course, how precise do you expect such measurements to be? I would like to include some practical applications for using the added projections. Thank-you. -- The whole religious complexion of the modern world is due to the absence from Jerusalem of a lunatic asylum. -- Havelock Ellis (1859-1939) British psychologist From Mikael.Rittri at carmenta.com Mon Aug 25 10:02:55 2008 From: Mikael.Rittri at carmenta.com (Mikael Rittri) Date: Mon Aug 25 10:03:02 2008 Subject: [Proj] Re: PROJ 4.6.1RC2 Available In-Reply-To: <48AED55C.8000004@pobox.com> References: <48AE2527.4090305@pobox.com> <48AE3F92.3080805@pobox.com><48AECF69.7090905@o2.pl> <48AED55C.8000004@pobox.com> Message-ID: Hello, In the ticket, Frank wrote: > I'd like some supporting documentation indicating > that ETRS89 is essentially equivalent to WGS84. May I quote myself: > However, for most practical purposes, ETRS89 can be regarded as > identical to WGS84 ... The difference is mainly caused by the > continental drift since 1989, which moves Europe (and ETRS89) > about 2 cm/year towards east-northeast. Differential GPS in Europe > will (primarily) give coordinates in ETRS89, but such coordinates > are often called "WGS84 coordinates", in a loose sense of the word. (From the Carmenta Engine manual.) My primary source is the text by the British Ordnance Survey, http://www.ordnancesurvey.co.uk/oswebsite/gps/docs/A_Guide_to_Coordinate_Systems_in_Great_Britain.pdf or http://www.ordnancesurvey.co.uk/oswebsite/gps/information/coordinatesystemsinfo/guidecontents/ which, by the way, I find wonderfully clear and easy to read. ETRS89 is described in section 4.2.4. I admit that the guide does give some (time-dependent) 7-parameter transformations between WGS84 and ETRS89, in section 6.5. But as I understand it, these would be needed only for special scientific applications (perhaps interferometry with very long baselines, where observatories on different continents have to cooperate.) For everyday mapping, ETRS89 is used. For positioning, if you use GPS with differential correction, you will also get ETRS89. And if you use GPS without differential corrections, then you will indeed get WGS84 instead of ETRS89, but the accuracy will be worse than the (currently) half-metre difference between the datums, so it will not matter anyway. Best regards, -- Mikael Rittri Carmenta AB Box 11354 SE-404 28 G?teborg Visitors: Sankt Eriksgatan 5 SWEDEN Tel: +46-31-775 57 37 Mob: +46-703-60 34 07 mikael.rittri@carmenta.com www.carmenta.com -----Original Message----- From: proj-bounces@lists.maptools.org [mailto:proj-bounces@lists.maptools.org] On Behalf Of Frank Warmerdam Sent: den 22 augusti 2008 17:04 To: Maciej Sieczka Cc: PROJ.4 and general Projections Discussions Subject: Re: [Proj] Re: PROJ 4.6.1RC2 Available Maciej Sieczka wrote: > Hi, > > Is a fix for "ETRS89-based CRSs missing datum definition" included? > > [1]http://trac.osgeo.org/proj/ticket/11 Maciek, No, that issue is not resolved yet (as is implied in the ticket). Best regards, -- ---------------------------------------+-------------------------------- ---------------------------------------+------ I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush | Geospatial Programmer for Rent _______________________________________________ Proj mailing list Proj@lists.maptools.org http://lists.maptools.org/mailman/listinfo/proj From Mikael.Rittri at carmenta.com Mon Aug 25 11:00:28 2008 From: Mikael.Rittri at carmenta.com (Mikael Rittri) Date: Mon Aug 25 11:00:35 2008 Subject: [Proj] Extended range TM usage In-Reply-To: <200808242208.03435.geraldi.evenden@gmail.com> References: <200808242208.03435.geraldi.evenden@gmail.com> Message-ID: Dear Mr. Evenden, Thanks for your efforts, but let me turn the question around: What is the rational reason for using the Taylor series for ellipsoidal Transverse Mercator? The Kr?ger formulas are almost as easy to implement, and seem better in all respects. Well-tested tradition? But the Kr?ger formulas are from 1912, and have been recommended by the Swedish Land Survey at least since 1976. Speed? In my own implementation, I find no speed difference in the inverse direction. In the forward direction, I admit that Kr?ger's formulas are almost 3 times slower. But no matter: if a point is within a region where a Taylor series gives at most 1 millimeter error, then I use Taylor. Elsewhere, I use Kr?ger. So my implementation is fast where it is safe to be so. (It is fairly simple to check which formulas to use.) The safe area extends 6 degrees from the central meridan at the equator, but is wider (measured in longitude degrees) at higher latitudes. But I'll try to give some answers to your question: > My question is can anyone supply a rational reason for the practical > use of an elliptical TM projection with extended longitude range. 1) How about conformal mapping of Norway? You might say that the shape of Norway calls for an Oblique Mercator instead, but not if we include Svalbard, Jan Mayen (halfway between Iceland and Svalbard), Bovet Island (at 54? 26' S, 3? 24' E), and the Norwegian claims on Antarctica. A suitably placed ellipsoidal Transverse Mercator would be excellent where the population lives. If the local scale factor is too bad on Jan Mayen, then the population there (if any) just have to learn to divide distances on the grid by the local scale factor. But if the round-trip accuracy fails on Jan Mayen (as I think it would using the Taylor series), this might cause serious problems in a GIS system. 2) Usage across a pole? The longest direct flight in world goes between Singapore and New York. Since these are on almost opposite meridians, a Transverse Mercator centered on Singapore would be a good choice to display possible flight routes. The Taylor series cannot be used on the backside of the Earth. But the Kr?ger formulas work there automatically (in the Swedish description, the occurrences of atan must be replaced by atan2.) 3) GIS systems that are easier to use? Printed maps have a fixed scale, but a GIS system has a zoom button. At some scale, it is usually necessary to switch to a suitable world projection, but this requires extra application code, which people often forget to insert. If it is necessary to switch from ellipsoidal Transverse Mercator to spherical Transverse Mercator at a certain scale, this is yet another thing people will forget. (And no one reads documentation, by the way.) As they say, it is hard to make things fool-proof because fools are so ingenious. That's why I like to have a single Transverse Mercator implementation that can be used in almost all scales. So, why not, if it has no real drawbacks? -- Mikael Rittri Carmenta AB Box 11354 SE-404 28 G?teborg Visitors: Sankt Eriksgatan 5 SWEDEN Tel: +46-31-775 57 37 Mob: +46-703-60 34 07 mikael.rittri@carmenta.com www.carmenta.com -----Original Message----- From: proj-bounces@lists.maptools.org [mailto:proj-bounces@lists.maptools.org] On Behalf Of Gerald I. Evenden Sent: den 25 augusti 2008 04:08 To: PROJ.4 and general Projections Discussions Subject: [Proj] Extended range TM usage I am finishing up the revised transverse Mercator section of libproj4's manual which includes three additional versions of the projection that give an extended longitude range for the projection. These version persist in being singular at the equator and 90 degrees from the central meridian. Hopefully, I may soon obtain a copy of Lee's work and include the Ultimate version. The old Taylor series version (tmerc) of TM is shown to be quite adequate for cadestral applications as demonstrated by comparisons with the expanded versions, That is, it has sub-millimeter accuracy within all longitude zones of standard applications that I am aware of. At the current time I consider the work on the extended version academic and of little practical application for the following reason: scale error of TM beyond an easting of about 400km (approximately 3.5 degrees longitude at the equator) would appear too large to make the projection useful in any application other than general mapping. If general mapping is the application then using the spherical form of tmerc should be adequate---especially for small scale maps. The problem of the singularity of the projection at (+-90,0) is not a problem because the distortion is so severe at the right and left edges the sides can be clipped. My question is can anyone supply a rational reason for the practical use of an elliptical TM projection with extended longitude range. The explanation should discuss how the projected coordinates are used and how the error factor is handled in application of the coordinates (like determining distance between points, azimuth, etc.). Of course, how precise do you expect such measurements to be? I would like to include some practical applications for using the added projections. Thank-you. -- The whole religious complexion of the modern world is due to the absence from Jerusalem of a lunatic asylum. -- Havelock Ellis (1859-1939) British psychologist _______________________________________________ Proj mailing list Proj@lists.maptools.org http://lists.maptools.org/mailman/listinfo/proj From Mikael.Rittri at carmenta.com Mon Aug 25 11:26:32 2008 From: Mikael.Rittri at carmenta.com (Mikael Rittri) Date: Mon Aug 25 11:26:42 2008 Subject: [Proj] WGS84 to Sphere Inconsistency Between Proj Versions In-Reply-To: References: <48ADFF35.7030501@eos.ubc.ca> <48AE215A.9040802@pobox.com><48AE2BB8.2090802@eos.ubc.ca> <48AE34CA.5020308@pobox.com> Message-ID: Dear Mr. Mugnier, you wrote >When diddling with spherical projections, the concept of "DATUM" is entirely inappropriate. which made me quite confused, because 1) I think what you wrote is absurd, and 2) I know well that you are an expert in geodesy. But Hillel said, "the shamefast is not apt to learn", so let me go on. I suppose you require more properties of a geodetic datum than I care about. For me, a geodetic datum is essentially a way to georeference a map (or at least to georeference the graticule on the map.) Surely you are not saying that if a map uses a spherical projection, then its graticule cannot be georeferenced. I have also been wondering why the EPSG people, when describing the web Mercator, are careful to say that the geodetic datum is not WGS84 but something spherical that is not a true datum. As I see it, the projection machinery has to treat the earth as a sphere, while the datum shift machinery has to treat it as an ellipsoid. And why not? In Carmenta Engine, the Mercator class has a switch that lets you choose between ellipsoidal and spherical formulas. So the projection can ignore the flattening of the ellipsoid, but the datum shift machinery will not. Are you (and EPSG) reasoning like this: (1.) all projections must be implemented by ellipsoidal formulas, so (2.) the only way to emulate spherical formulas is to supply an earth model that is a sphere from the beginning; and no proper datum can be spherical. ? If so, then I agree that (2) follows from (1), and I agree that proper datums should not be spherical. But I do not agree that (1) is true. Best regards, -- Mikael Rittri Carmenta AB Box 11354 SE-404 28 G?teborg Visitors: Sankt Eriksgatan 5 SWEDEN Tel: +46-31-775 57 37 Mob: +46-703-60 34 07 mikael.rittri@carmenta.com www.carmenta.com ________________________________ From: proj-bounces@lists.maptools.org [mailto:proj-bounces@lists.maptools.org] On Behalf Of Clifford J Mugnier Sent: den 22 augusti 2008 05:45 To: PROJ.4 and general Projections Discussions; PROJ.4 and general Projections Discussions Subject: RE: [Proj] WGS84 to Sphere Inconsistency Between Proj Versions When didling with spherical projections, the concept of "DATUM" is entirely inappropriate. Cliff Mugnier LOUISIANA STATE UNIVERSITY ________________________________ From: proj-bounces@lists.maptools.org on behalf of Frank Warmerdam Sent: Thu 21-Aug-08 22:38 To: PROJ.4 and general Projections Discussions Subject: Re: [Proj] WGS84 to Sphere Inconsistency Between Proj Versions Faron Anslow wrote: > I just ran this: > > cs2cs +proj=latlong +datum=WGS84 +to +proj=lcc +lat_1=50 +lat_2=50 > +lat_0=50 +lon_0=-107 +a=6371200.0000000000 +es=0.0 +f=0.0 > +towgs84=0,0,0 -r > > on: > 70.933 -8.667 > > and got: > 2873633.37 4593659.18 -12148.43 > > which is my original matlab answer and that from the old proj4.4. Now, > the question is if forcing the datum shift with +towgs=0,0,0 is > appropriate? Doesn't +towgs48 conflict with/override the spherical > projection definition? Faron, I can't imagine any situation other than an effort to match old answers where it makes sense to apply a plain lat/long on a sphere to lat/long on an ellipsoid conversion the way this is doing. If you want the lat/long values computed from the lcc projection based on a sphere to treated as WGS84, then use +nadgrids=@null (or in 4.6.0 just omit a datum specifier for the lcc projection). This is *likely* want you want. Best regards, -- ---------------------------------------+-------------------------------------- I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush | Geospatial Programmer for Rent _______________________________________________ Proj mailing list Proj@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/20080825/a59b23a1/attachment-0001.html From cjmce at lsu.edu Mon Aug 25 12:03:03 2008 From: cjmce at lsu.edu (Clifford J Mugnier) Date: Mon Aug 25 12:03:16 2008 Subject: [Proj] WGS84 to Sphere Inconsistency Between Proj Versions References: <48ADFF35.7030501@eos.ubc.ca><48AE215A.9040802@pobox.com><48AE2BB8.2090802@eos.ubc.ca><48AE34CA.5020308@pobox.com> Message-ID: Absolute spatial positions between disparate datums are lost when using datum-specific coordinates in a single spherical projection. I suggest you read some of my past columns, in particular "The Basics of Datums." This is not an appropriate venue to get into a detailed tutorial on geometric geodesy and it's historical foundations. In regards to your logic, I'll leave the rationalizations to you. What I said stands as is. C. Mugnier ________________________________ From: proj-bounces@lists.maptools.org on behalf of Mikael Rittri Sent: Mon 25-Aug-08 10:26 To: PROJ.4 and general Projections Discussions Subject: RE: [Proj] WGS84 to Sphere Inconsistency Between Proj Versions Dear Mr. Mugnier, you wrote >When diddling with spherical projections, the concept of "DATUM" is entirely inappropriate. which made me quite confused, because 1) I think what you wrote is absurd, and 2) I know well that you are an expert in geodesy. But Hillel said, "the shamefast is not apt to learn", so let me go on. I suppose you require more properties of a geodetic datum than I care about. For me, a geodetic datum is essentially a way to georeference a map (or at least to georeference the graticule on the map.) Surely you are not saying that if a map uses a spherical projection, then its graticule cannot be georeferenced. I have also been wondering why the EPSG people, when describing the web Mercator, are careful to say that the geodetic datum is not WGS84 but something spherical that is not a true datum. As I see it, the projection machinery has to treat the earth as a sphere, while the datum shift machinery has to treat it as an ellipsoid. And why not? In Carmenta Engine, the Mercator class has a switch that lets you choose between ellipsoidal and spherical formulas. So the projection can ignore the flattening of the ellipsoid, but the datum shift machinery will not. Are you (and EPSG) reasoning like this: (1.) all projections must be implemented by ellipsoidal formulas, so (2.) the only way to emulate spherical formulas is to supply an earth model that is a sphere from the beginning; and no proper datum can be spherical. ? If so, then I agree that (2) follows from (1), and I agree that proper datums should not be spherical. But I do not agree that (1) is true. Best regards, -- Mikael Rittri Carmenta AB Box 11354 SE-404 28 G?teborg Visitors: Sankt Eriksgatan 5 SWEDEN Tel: +46-31-775 57 37 Mob: +46-703-60 34 07 mikael.rittri@carmenta.com www.carmenta.com ________________________________ From: proj-bounces@lists.maptools.org [mailto:proj-bounces@lists.maptools.org] On Behalf Of Clifford J Mugnier Sent: den 22 augusti 2008 05:45 To: PROJ.4 and general Projections Discussions; PROJ.4 and general Projections Discussions Subject: RE: [Proj] WGS84 to Sphere Inconsistency Between Proj Versions When didling with spherical projections, the concept of "DATUM" is entirely inappropriate. Cliff Mugnier LOUISIANA STATE UNIVERSITY ________________________________ From: proj-bounces@lists.maptools.org on behalf of Frank Warmerdam Sent: Thu 21-Aug-08 22:38 To: PROJ.4 and general Projections Discussions Subject: Re: [Proj] WGS84 to Sphere Inconsistency Between Proj Versions Faron Anslow wrote: > I just ran this: > > cs2cs +proj=latlong +datum=WGS84 +to +proj=lcc +lat_1=50 +lat_2=50 > +lat_0=50 +lon_0=-107 +a=6371200.0000000000 +es=0.0 +f=0.0 > +towgs84=0,0,0 -r > > on: > 70.933 -8.667 > > and got: > 2873633.37 4593659.18 -12148.43 > > which is my original matlab answer and that from the old proj4.4. Now, > the question is if forcing the datum shift with +towgs=0,0,0 is > appropriate? Doe