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? 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/b3ccc22a/attachment.html From lblake at ksninc.com Mon Aug 25 12:27:23 2008 From: lblake at ksninc.com (Landon Blake) Date: Mon Aug 25 12:27:30 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: <0D544207876CDA428F17DD7EA448C192D54552@bailey.DOMAIN.KSNINC.PVT> Clifford wrote: "Absolute spatial positions between disparate datums are lost when using datum-specific coordinates in a single spherical projection." Are you talking about moving a position between two spherical datums, or any transformation which involves a spherical datum?" Clifford wrote: "I suggest you read some of my past columns, in particular "The Basics of Datums."" Where could we find these columns? Do you also post messages on the POB forum occasionally? Thanks, The Sunburned Surveyor ________________________________ From: proj-bounces@lists.maptools.org [mailto:proj-bounces@lists.maptools.org] On Behalf Of Clifford J Mugnier Sent: Monday, August 25, 2008 9:03 AM To: PROJ.4 and general Projections Discussions Subject: RE: [Proj] WGS84 to Sphere Inconsistency Between Proj Versions 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? 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 Warning: Information provided via electronic media is not guaranteed against defects including translation and transmission errors. If the reader is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this information in error, please notify the sender immediately. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.maptools.org/pipermail/proj/attachments/20080825/490d20ef/attachment-0001.html From cjmce at lsu.edu Mon Aug 25 16:05:37 2008 From: cjmce at lsu.edu (Clifford J Mugnier) Date: Mon Aug 25 16:05:47 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> <0D544207876CDA428F17DD7EA448C192D54552@bailey.DOMAIN.KSNINC.PVT> Message-ID: There is no such thing as a spherical datum. Not since the late 1600s, anyway. Before then ... beats me. For the past 300 years or so, there has been no such thing as a spherical datum. Period. There were these two little French "expeditions" - one to Lapland & one to Peru that proved Newton's theory that the earth is best approximated by an oblate ellipsoid of revolution and not by the French theory of a prolate ellipsoid of revolution - Published in 1716. I publish monthly in Photogrammetric Engineering and Remote Sensing. Each month my column on the Grids and Datums of the world cover a different country's geodetic history, it's coordinate systems that comprise its datums and grid systems, etc. The American Society for Photogrammetry and Remote Sensing has been publishing my columns at their website (for free downloads) in pdf files since 1997. Right now, I'm more than halfway through the world. This month is on Saudi Arabia, next month is on Sakhalin Island, Russia. I post messages, comments, opinions, advice, jokes, and occasional insults (to liberals) on the POB forum frequently. (Current messages are 3,400+.) Check out the website at the bottom of my signature block. Clifford J. Mugnier, C.P., C.M.S. Past National Director (2006-2008), Photogrammetric Applications Division American Society for Photogrammetry and Remote Sensing and Chief of Geodesy, CENTER FOR GEOINFORMATICS Department of Civil Engineering Patrick F. Taylor Hall 3223A LOUISIANA STATE UNIVERSITY Baton Rouge, LA 70803 Voice and Facsimile: (225) 578-8536 [Academic] Voice and Facsimile: (225) 578-4474 [Research] Honorary Life Member of the Louisiana Society of Professional Surveyors Member Emeritus of the ASPRS Member of the Americas Petroleum Survey Group ====================================================== http://www.asprs.org/resources/GRIDS/ ====================================================== ________________________________ From: proj-bounces@lists.maptools.org on behalf of Landon Blake Sent: Mon 25-Aug-08 11:27 To: PROJ.4 and general Projections Discussions Subject: RE: [Proj] WGS84 to Sphere Inconsistency Between Proj Versions Clifford wrote: "Absolute spatial positions between disparate datums are lost when using datum-specific coordinates in a single spherical projection." Are you talking about moving a position between two spherical datums, or any transformation which involves a spherical datum?" Clifford wrote: "I suggest you read some of my past columns, in particular "The Basics of Datums."" Where could we find these columns? Do you also post messages on the POB forum occasionally? Thanks, The Sunburned Surveyor ________________________________ From: proj-bounces@lists.maptools.org [mailto:proj-bounces@lists.maptools.org] On Behalf Of Clifford J Mugnier Sent: Monday, August 25, 2008 9:03 AM To: PROJ.4 and general Projections Discussions Subject: RE: [Proj] WGS84 to Sphere Inconsistency Between Proj Versions 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? 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 Warning: Information provided via electronic media is not guaranteed against defects including translation and transmission errors. If the reader is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this information in error, please notify the sender immediately. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.maptools.org/pipermail/proj/attachments/20080825/1cdfd6a5/attachment-0001.html From support.mn at elisanet.fi Tue Aug 26 08:35:43 2008 From: support.mn at elisanet.fi (support.mn@elisanet.fi) Date: Tue Aug 26 08:35:51 2008 Subject: [Proj] Extended range TM usage Message-ID: <15439115.107541219754144048.JavaMail.support.mn@elisanet.fi> "Gerald I. Evenden" wrote: > My question is can anyone supply a rational reason for the practical use of an > elliptical TM projection with extended longitude range. How practical is that, I don't know, but there is the situation where an user is zooming out a view so much that a very large area is visible. There can rise a situation where those extreme areas should be shown somehow. The accuracy does not matter in that case, since it is only show in relation with that middle section which is the main focus. This same situation applies basicly to all projections. Sometimes users zoom out the views very much and the extreme areas should be shown somehow. Sometimes clipping them away, or projecting to some limiting line, might be as good alternative. But my opinion is that it is better to show something than nothing even if it is a bit unaccurate. If somebody wants to have more aggressive limiting, he might use the error mechanism, where the library warns him about the error getting too large and that particular solution might start to clip those areas away. Regards: Janne From al001 at uni-koeln.de Tue Aug 26 10:03:43 2008 From: al001 at uni-koeln.de (Irwin Scollar) Date: Tue Aug 26 10:03:49 2008 Subject: [Proj] Egypt Datum Transformation Parameters Message-ID: <200808261403.m7QE3gZc012716@smtp-auth.uni-koeln.de> Can anyone supply Helmert 7 parameter datum parameters between WGS84 Ellipsoid and the Helmert 1906 Ellipsoid used in the "Red Belt, Blue Belt, Purple Belt, Purple Belt Extended" Old Egyptian 1907 areas or a link to where they may possibly be found? I have only the 3 parameter Molodensky transform data in the NIMA 1987 Madtran and the later Geotran2 programs which may not have errors as low as those of a modern dual frequency GPS receiver. Irwin Scollar From Mikael.Rittri at carmenta.com Tue Aug 26 10:27:40 2008 From: Mikael.Rittri at carmenta.com (Mikael Rittri) Date: Tue Aug 26 10:27:49 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: Clifford J Mugnier wrote: > ________________________________ > From: proj-bounces@lists.maptools.org [mailto:proj-bounces@lists.maptools.org] On Behalf Of Clifford J Mugnier > Sent: den 25 augusti 2008 18:03 > To: PROJ.4 and general Projections Discussions > Subject: RE: [Proj] WGS84 to Sphere Inconsistency Between Proj Versions > > > Absolute spatial positions between disparate datums > are lost when using datum-specific coordinates in a > single spherical projection. Sorry, I don't understand that sentence, either. > 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. Thanks for the advice; I have read some of your columns, but I had overlooked that one. However, now that I have read it, I am no wiser. There is no mention of spherical projections there. Well, since you say datums and spherical projections don't go together, it stands to reason that you wouldn't mention spherical projections in a column about datums. > In regards to your logic, I'll leave the rationalizations to you. > What I said stands as is. > > C. Mugnier Certainly. As I said, I respect your expertise. That's why I am eager to understand what you mean. About my logic, my intention was not to convince you that you were wrong in a matter of geodesy. I merely hoped that if I exposed the details of my own amateur reasoning, you would be able to pinpoint some detail and say: "THAT's where you are wrong, Mikael." I am sorry if it was all nonsense. By the way, that's why I quoted Hillel, but perhaps it was obscure: "The shamefast is not apt to learn", because he is too shy to expose his ignorance by asking questions. In order to learn, I was trying to expose my ignorance --- not my arrogance. There was a related post from Melita Kennedy in June, by the way: MK> The Mercator-based coordinate system used by Google Maps can be thought of in MK> two ways. MK> MK> 1) It uses a sphere with radius=6378137.0 m. Sent to Mercator, hopefully, the MK> code is smart enough to use the spherical equations. MK> 2) It uses WGS84 with spherical Mercator equations. MK> MK> [--- text deleted ---] MK> MK> Melita MK> ESRI, Inc. (Quoted from http://lists.maptools.org/pipermail/proj/2008-June/003434.html). I think that (2) corresponds to my way of thinking. I suppose you would say that (1) is the only correct view. 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 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? 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 From cjmce at lsu.edu Tue Aug 26 12:14:37 2008 From: cjmce at lsu.edu (Clifford J Mugnier) Date: Tue Aug 26 12:14:47 2008 Subject: [Proj] Extended range TM usage References: <15439115.107541219754144048.JavaMail.support.mn@elisanet.fi> Message-ID: The most common rational reasons include GIS applications of hydrocarbon-producing regions. For example, the entire Gulf of Mexico, significant portions of Siberia, the Persian Gulf, etc. The key word is "region." There are numerous cartographic uses for this in Reservoir Engineering as well as maintenance of lease blocks data bases, etc. The military has ALWAYS recognized this need and actually published a special book on Zone-to-Zone transformations. I seem to write about these valid rational reasons periodically, and I think I do so in this discussion list. If you don't want to implement this sort of thing and are looking for a reason not to do so, use sunrise tomorrow as an excuse. Cliff Mugnier LOUISIANA STATE UNIVERSITY ________________________________ From: proj-bounces@lists.maptools.org on behalf of support.mn@elisanet.fi Sent: Tue 26-Aug-08 07:35 To: PROJ.4 and general Projections Discussions; geraldi.evenden@gmail.com Subject: Re: [Proj] Extended range TM usage "Gerald I. Evenden" wrote: > My question is can anyone supply a rational reason for the practical use of an > elliptical TM projection with extended longitude range. How practical is that, I don't know, but there is the situation where an user is zooming out a view so much that a very large area is visible. There can rise a situation where those extreme areas should be shown somehow. The accuracy does not matter in that case, since it is only show in relation with that middle section which is the main focus. This same situation applies basicly to all projections. Sometimes users zoom out the views very much and the extreme areas should be shown somehow. Sometimes clipping them away, or projecting to some limiting line, might be as good alternative. But my opinion is that it is better to show something than nothing even if it is a bit unaccurate. If somebody wants to have more aggressive limiting, he might use the error mechanism, where the library warns him about the error getting too large and that particular solution might start to clip those areas away. Regards: Janne _______________________________________________ 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/20080826/11dc660a/attachment.html From cjmce at lsu.edu Tue Aug 26 12:31:29 2008 From: cjmce at lsu.edu (Clifford J Mugnier) Date: Tue Aug 26 12:31:39 2008 Subject: [Proj] Egypt Datum Transformation Parameters References: <200808261403.m7QE3gZc012716@smtp-auth.uni-koeln.de> Message-ID: Irwin, There are numerous academics and government agencies in Egypt that can supply what you want, but nobody is likely going to do so. I have tried to get such information for years, and have never even received the courtesy of a reply. Note that such information is considered a military secret in some countries, and I suspect that Egypt is one of those countries. The NIMA/NGA transformation parameters are from ED50 - European Datum 1950 to WGS84 as well as Old Egyptian Datum 1930 to WGS84. If you need better accuracy, I recommend you perform the observations yourself and publish your derived transformation parameters on this list for everyone else. I would like to point out that 7-parameter transformations are really applicable only to small provincial areas that are significantly smaller in areal extend than a single Egyptian Transverse Mercator Belt. Working with a crew of a dozen men all with dual-frequency receivers, you should get the job done within a decade or so ... :-) The point to this is that what you desire is likely a government secret, and you are asking for geodetic-quality transformations for an entire country. That sort of thing is implemented with algorithms such as NTv2 or NADCON - not with a Molodensky or Bursa-Wolfe model. I have used such models in the past, but for tiny regions such as a single international boundary line or for a city. You likely will have to "make do" with what you have unless you receive Egyptian Government authorization to do otherwise. Cliff Mugnier LOUISIANA STATE UNIVERSITY ________________________________ From: proj-bounces@lists.maptools.org on behalf of Irwin Scollar Sent: Tue 26-Aug-08 09:03 To: proj@lists.maptools.org Subject: [Proj] Egypt Datum Transformation Parameters Can anyone supply Helmert 7 parameter datum parameters between WGS84 Ellipsoid and the Helmert 1906 Ellipsoid used in the "Red Belt, Blue Belt, Purple Belt, Purple Belt Extended" Old Egyptian 1907 areas or a link to where they may possibly be found? I have only the 3 parameter Molodensky transform data in the NIMA 1987 Madtran and the later Geotran2 programs which may not have errors as low as those of a modern dual frequency GPS receiver. Irwin Scollar _______________________________________________ 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/20080826/65ebcf34/attachment.html From geraldi.evenden at gmail.com Tue Aug 26 20:41:09 2008 From: geraldi.evenden at gmail.com (Gerald I. Evenden) Date: Tue Aug 26 20:41:18 2008 Subject: [Proj] Extended range TM usage In-Reply-To: <15439115.107541219754144048.JavaMail.support.mn@elisanet.fi> References: <15439115.107541219754144048.JavaMail.support.mn@elisanet.fi> Message-ID: <200808262041.09221.geraldi.evenden@gmail.com> On Tuesday 26 August 2008 8:35:43 am support.mn@elisanet.fi wrote: > "Gerald I. Evenden" wrote: > > My question is can anyone supply a rational reason for the practical use > > of an elliptical TM projection with extended longitude range. > > How practical is that, I don't know, but there is the situation where an > user is zooming out a view so much that a very large area is visible. There > can rise a situation where those extreme areas should be shown somehow. The > accuracy does not matter in that case, since it is only show in relation > with that middle section which is the main focus. > > This same situation applies basicly to all projections. Sometimes users > zoom out the views very much and the extreme areas should be shown somehow. > Sometimes clipping them away, or projecting to some limiting line, might be > as good alternative. But my opinion is that it is better to show something > than nothing even if it is a bit unaccurate. > > If somebody wants to have more aggressive limiting, he might use the error > mechanism, where the library warns him about the error getting too large > and that particular solution might start to clip those areas away. > > Regards: Janne Zooming out seems to be a common reason for extended TM range. In this situation, the view is probably a monitor screen so there is no need for an elliptical TM in the first place. In addition, if unlimited out-zoom is employed you probably need to change projection anyway---a view from space might suggest the the near side perspective plot (nsper) for example. Extreme, but the point I want to emphasize is that one does not have to stick to the same projection in the zoom process. I would advise that the projection selected for display be determined by the extent and scale of the data. Small scale maps would often suggest pseudocylindricals, or many others commonly used for continental or global extents. Only close ups or scales larger than 1:250,000 suggest TM. I would not bother with elliptical projections for display computer display purposes. The only time something like elliptical TM or any other elliptical projection is demanded is when making maps on stable base material to be overlain on similar class material or published where such standards are required. When working for the USGS the preparation of a "stand alone" sheet such as AMS 1x2 sheet or 1:25,000 scale maps, the graphics were always prepares with an elliptical projection in common use by Topo Div. for that type of map and with precision commensurate with the printing process. If a map was a page illustration in an article or report I do not recall anyone ever raising the issue as to projection nor the use of an elliptical projection---any reasonable projection that properly displays the data can be used. Note: the USGS maps I am talking about were for geologic data but often had cultural underlays. The thing I want to emphasize here is that computer display and certain types of map publication are two entirely different subjects with different demands. -- 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 Tue Aug 26 21:37:08 2008 From: geraldi.evenden at gmail.com (Gerald I. Evenden) Date: Tue Aug 26 21:37:16 2008 Subject: [Proj] Extended range TM usage In-Reply-To: References: <15439115.107541219754144048.JavaMail.support.mn@elisanet.fi> Message-ID: <200808262137.08866.geraldi.evenden@gmail.com> On Tuesday 26 August 2008 12:14:37 pm Clifford J Mugnier wrote: > The most common rational reasons include GIS applications of > hydrocarbon-producing regions. For example, the entire Gulf of Mexico, > significant portions of Siberia, the Persian Gulf, etc. The key word is > "region." There are numerous cartographic uses for this in Reservoir > Engineering as well as maintenance of lease blocks data bases, etc. My question here is what was the rational for choosing TM and, in particular, elliptical TM? Was the shape of the region considered? Were other projections like Stereographic or Lambert Conic considered? > The military has ALWAYS recognized this need and actually published a > special book on Zone-to-Zone transformations. Indeed, I often ran into geologist spanning UTM zones and thus the AMS sheets that they were using as base maps and thus ended up giving us computer map makers fits. NMD (National Mapping Division) would kludge up a base map for them from pasted together mylar sheets. But, you cannot extend the TM projection and expect it to overlay sheets from a different zone---because---the scale of the projection rapidly deteriorates at increased distance from the CM and is not the same scale as a sheet from the adjacent zone. Thus computer generated maps with extended zones would not match AMS sheets not having the same CM. > I seem to write about these valid rational reasons periodically, and I > think I do so in this discussion list. Because it keeps coming up and I do not think some people realize the problems. > If you don't want to implement this sort of thing and are looking for a > reason not to do so, use sunrise tomorrow as an excuse. As long as user's recognize that extending the range of TM will create charts that *do not* overlay regions *not exactly* computed in the same manner, then no problem. Current libproj4 allows a fairly wide TM extent. BUT no user shall come and complain that a map area generated on one CM will not match a map generated on another CM. That is: UTM sheets will not match extended TM when the extended TM's CM is not the same as the UTM sheet. Secondly, *do not* complain if distances taken from extended TM grid at extended distances from the TM do not seem to match real distances. The scale factor goes to hell as one gets further and further from the CM. Given the scale problems there seems little reason to even bother with the ellptical TM and just use spherical TM with a radius that gives a "close enough for ... " accuracy. That's what they have in practice have now. Again, I try to be a good rope maker and I want to be sure that users have enough to hang themselves. The added TMs give the user a choice of the color of the hemp. Of course, the least area outlines come up. As I recall, we digitized the zones into geographic so they could be plotter anywhere, anyway. We had to do it because of the irregular shape near the shore line. It's getting late. > Cliff Mugnier > LOUISIANA STATE UNIVERSITY ... -- 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 Wed Aug 27 11:45:53 2008 From: geraldi.evenden at gmail.com (Gerald I. Evenden) Date: Wed Aug 27 11:46:28 2008 Subject: [Proj] Global Gauss-Kruger and libproj4---the final story Message-ID: <200808271145.53793.geraldi.evenden@gmail.com> Thanks to a reader I have a copy of the Lee-Thompson material for the Transverse Mercator projection. After perusing the material it is clear that no bivariate function operation such as libproj4 can handle the general case of the global extent of the Gauss-Kruger projection. This is because of the nature of the equator graticule line and the fact that it branches into two parts as it approaches 90 degrees from the central meridian. That is, all points with 0 latitude and with a delta longitude near 90 degrees will have *two* resultant Cartesian coordinates---one for the northern hemisphere and one for the southern hemisphere. Proj_fwd returns only one Cartesian point. I had a suspicion that this was the case from viewing the "tombstone" illustrations of TM referenced many weeks ago but had to wait to learn the details of what was tranpiring. So case closed. Next. -- 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 ahuerta at awi-bremerhaven.de Wed Aug 27 12:20:37 2008 From: ahuerta at awi-bremerhaven.de (Adriana Huerta-Casas) Date: Wed Aug 27 12:21:34 2008 Subject: [Proj] polar stereographic coord Message-ID: Hi, I'm new using proj4 and I can't really figure out how to do this properly: I need to convert data given in polar stereographical coordinates (from BEDMAP, 71S lat true scale,0E central meridian,5km nominal grid spacing) to cartesian coordinates. The input file is ascii and contain headers. I'm after a file x,y,data. The first lines of the file to read and convert are: ncols 1200 nrows 1000 xllcorner -3000000 yllcorner -2500000 cellsize 5000 NODATA_value -9999 -9999 -9999 -9999 -999 ... I'm doing the follwing: cat icethic.asc | proj +proj=stere +lon_0=0 +lat_0=-90 +lat_ts=-71 +ellps=WGS84 +datum=WGS84 but I'm wondering how to write a file and read the headers. Thanks a lot! adriana -- ---------------------------- Dr. Adriana Huerta-Casas Alfred-Wegener-Institute for Polar and Marine Research Bussestrasse 24 (Building F-406) D-27570 Bremerhaven, Germany Telephone:+49(471)4831-1855 From dagnew at ucsd.edu Wed Aug 27 12:53:52 2008 From: dagnew at ucsd.edu (Duncan Agnew) Date: Wed Aug 27 12:53:59 2008 Subject: [Proj] Extended range TM usage In-Reply-To: <200808262137.08866.geraldi.evenden@gmail.com> References: <15439115.107541219754144048.JavaMail.support.mn@elisanet.fi> <200808262137.08866.geraldi.evenden@gmail.com> Message-ID: If an onlooker can weigh in on the extended TM debate, partly because I think the debaters somewhat talk past each other... Gerald is looking at the TM math as a projection--that is, something that is used to create XY coordinates with the purpose of display (a map on paper or on the screen). Given the finite resolution of any display system he is right to say that spherical TM is often just fine (scale error at most 1 part in 300). The best possible for a physical display might be 0.01 mm over 1 m for a hardcopy, which is 10**-5. These numbers matter only if you wanted to actually make measurements from the map display itself, rather than (as in GIS) the numbers stored internally. How many people actually measure off maps to high precision, these days? (Getting coordinates off doesn't count--eg, if using military maps in UTM with a 1-km graticule, how many people measure the distances to high precision off the map, as opposed to getting coordinates from the graticule and then computing the distance from the coordinates?) Cliff is looking at the TM math as a grid system--that is, something that is used to create XY coordinates to be used "as they stand"--eg, for deciding if your region (defined by lat-long) overlaps mine (defined by XY, according to some official or semi-official system). Then you and I had better use the same math or we have a problem. So if customary usage for defining property boundary coordinates (eg lease areas in the Gulf of Mexico) is ellipsoidal TM coordinates with a reference meridian 10 degrees away, then there will be a need for an implementation of this transformation, however bizarre the scale may be. For boundary work (though for little else), the precision had best be very high--though as a practitioner of geodetic GPS, I have to point out that, in practice, even claiming lat/long to better than a few centimeters is problematic unless you take care to allow for tectonic motions. Duncan Agnew From strebe at aol.com Wed Aug 27 13:40:43 2008 From: strebe at aol.com (strebe) Date: Wed Aug 27 13:40:51 2008 Subject: [Proj] Re: Global Gauss-Kruger and libproj4---the final story In-Reply-To: <200808271145.53793.geraldi.evenden@gmail.com> Message-ID: Not knowing anything about libproj4, I am surprised by this note. All projections of the complete globe are "multivariate". What does libproj4 do for other projections? Why would it not do something similar for ellipsoidal transverse Mercator? Regards, -- daan Strebe On Aug 27, 2008, at 8:45:53 AM, "Gerald I. Evenden" wrote: From: "Gerald I. Evenden" Subject: [Proj] Global Gauss-Kruger and libproj4---the final story Date: August 27, 2008 8:45:53 AM PDT To: "PROJ.4 and general Projections Discussions" Thanks to a reader I have a copy of the Lee-Thompson material for the? Transverse Mercator projection. After perusing the material it is clear that no bivariate function operation? such as libproj4 can handle the general case of the global extent of the? Gauss-Kruger projection. This is because of the nature of the equator? graticule line and the fact that it branches into two parts as it approaches? 90 degrees from the central meridian. That is, all points with 0 latitude? and with a delta longitude near 90 degrees will have *two* resultant? Cartesian coordinates---one for the northern hemisphere and one for the? southern hemisphere. Proj_fwd returns only one Cartesian point. I had a suspicion that this was the case from viewing the "tombstone"? illustrations of TM referenced many weeks ago but had to wait to learn the? details of what was tranpiring. So case closed. Next. --? 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.maptools.org/pipermail/proj/attachments/20080827/def046ff/attachment.html From al001 at uni-koeln.de Wed Aug 27 14:17:12 2008 From: al001 at uni-koeln.de (Irwin Scollar) Date: Wed Aug 27 14:17:20 2008 Subject: [Proj] Egyptian Datum Parameters In-Reply-To: <200808271549.m7RFnHna026356@duke.maptools.org> References: <200808271549.m7RFnHna026356@duke.maptools.org> Message-ID: <200808271817.m7RIHDhq010988@smtp-auth.uni-koeln.de> >Cliff Mugnier wrote: >There are numerous academics and government agencies in Egypt that >can supply what you want, but nobody is likely going to do so. I >have tried to get such information for years, and have never even >received the courtesy of a reply. Note that such information is >considered a military secret in some countries, and I suspect that >Egypt is one of those countries. I thought that this might be the case which is why I asked on this list. My dear departed friend Yigal Shiloh told me that before and during the 6 days war, he and his reconnaissance squadron flew the length of the Nile Valley at low altitude and archived nearly complete vertical aerial cover. But military minds are usually two wars or more behind in their thinking, even if Keyhole and Quickbird imagery, both public and non-public, makes it all absurd. >The NIMA/NGA transformation parameters are from ED50 - European >Datum 1950 to WGS84 as well as Old Egyptian Datum 1930 to WGS84. > >If you need better accuracy, I recommend you perform the >observations yourself and publish your derived transformation >parameters on this list for everyone else. The reason behind my request was simply that in my program AirPhoto, I recently implemented the use of Google Earth at enhanced high resolution, and for less belligerent parts of the world have incorporated the ability to search GE using a local grid system converted to the lat/lons needed by Google on the assumption that over small areas of interest, the error is not significant. After linear correction of the result, I get apparent precision to better than a meter, and in some places like the UK, Switzerland and Germany even in the low decimeter range as tested by using some of the known coordinates of the more than 6000 UK Ordnance Survey primary trig point pillars, many of which are visible in Google Earth. For rough GE search in Egypt, the error in Molodensky/Bursa Wolfe won't be troublesome. What will be a bit annoying will be the inability to do a local correction down to the error range of a dual frequency receiver. This project using GE data raised the interest of the Egyptologists in Berlin who did not have access to accurate imagery or maps. Hence my request to this list. >I would like to point out that 7-parameter transformations are >really applicable only to small provincial areas that are >significantly smaller in areal extend than a single Egyptian >Transverse Mercator Belt. Working with a crew of a dozen men all >with dual-frequency receivers, you should get the job done within a >decade or so ... :-) I haven't the slightest intention of ever travelling south of the Balearics >:-} . Seriously though, I didn't expect to get a single 7 parameter Helmert transform value for a country as large as Egypt. I had hoped that like Spain, where four such sets are openly available on the national mapping service web site, that a set of such parameters might exist and be available. >The point to this is that what you desire is likely a government >secret, and you are asking for geodetic-quality transformations for >an entire country. That sort of thing is implemented with >algorithms such as NTv2 or NADCON - not with a Molodensky or >Bursa-Wolfe model. I have used such models in the past, but for >tiny regions such as a single international boundary line or for a city. Molodensky/Bursa Wolfe used to be adequate in the days of GPS "selective availability". Today, the way I have followed in temperate highly occupied parts of the world is to create a dense Delaunay trianglulation on visible points and do affine interpolation within that grid to a precision digital map or to primary and secondary trig points if visible rather than the use of high order polynomials. I obtained fairly good results matching old first edition Ordnance Survey maps from about 1793-1805 to to modern digital maps of the Isle of Wight that way. Lantmateriet in Sweden has published a similar technique to connect up the large number of idiosyncratic communal grids to the national grid. >You likely will have to "make do" with what you have unless you >receive Egyptian Government authorization to do otherwise. Never fear! I shan't ask. :-) Irwin Scollar >From: proj-bounces@lists.maptools.org on behalf of Irwin Scollar >Sent: Tue 26-Aug-08 09:03 >To: proj@lists.maptools.org >Subject: [Proj] Egypt Datum Transformation Parameters > >Can anyone supply Helmert 7 parameter datum parameters between WGS84 >Ellipsoid and the Helmert 1906 Ellipsoid used in the "Red Belt, Blue >Belt, Purple Belt, Purple Belt Extended" Old Egyptian 1907 areas or >a link to where they may possibly be found? > >I have only the 3 parameter Molodensky transform data in the NIMA >1987 Madtran and the later Geotran2 programs which may not have >errors as low as those of a modern dual frequency GPS receiver. > >Irwin Scollar From EMiller at dfg.ca.gov Wed Aug 27 14:25:19 2008 From: EMiller at dfg.ca.gov (Eric Miller) Date: Wed Aug 27 14:25:30 2008 Subject: [Proj] polar stereographic coord In-Reply-To: References: Message-ID: <48B5399F.95FD.00E4.0@dfg.ca.gov> You can't project an ascii grid with proj. It only works with coordinates. Additionally, the "proj" command only does forward or inverse projections. You'd need to use "cs2cs" to convert between two coordinate systems. However, I think gdalwarp might be able to handle projecting the data. >>> On 8/27/2008 at 9:20 AM, Adriana Huerta-Casas wrote: > Hi, > > > I'm new using proj4 and I can't really figure out how to do this properly: > > > I need to convert data given in polar stereographical coordinates (from > BEDMAP, 71S lat true scale,0E central meridian,5km nominal grid spacing) > to cartesian coordinates. The input file is ascii and contain headers. > I'm after a file x,y,data. > > > The first lines of the file to read and convert are: > ncols 1200 > nrows 1000 > xllcorner -3000000 > yllcorner -2500000 > cellsize 5000 > NODATA_value -9999 > -9999 -9999 -9999 -999 ... > > > > > I'm doing the follwing: > > > cat icethic.asc | proj +proj=stere +lon_0=0 +lat_0=-90 +lat_ts=-71 > +ellps=WGS84 +datum=WGS84 > > > but I'm wondering how to write a file and read the headers. > > > Thanks a lot! > adriana > From support.mn at elisanet.fi Wed Aug 27 15:05:50 2008 From: support.mn at elisanet.fi (support.mn@elisanet.fi) Date: Wed Aug 27 15:05:57 2008 Subject: [Proj] Egypt Datum Transformation Parameters Message-ID: <5725882.1259301219863950279.JavaMail.support.mn@elisanet.fi> Hello, there seems to be some entries in EPSG database which have also a datum defined. Here are them: # epsg.pin:4706 # Egypt Gulf of Suez S-650 TL proj=longlat ellps=helmert towgs84=-146.21,112.63,4.05,0,0,0,0 no_defs # epsg.pin:3355 # Egypt Gulf of Suez S-650 TL / Red Belt proj=tmerc lat_0=30 lon_0=31 k=1 x_0=615000 y_0=810000 ellps=helmert towgs84=-146.21,112.63,4.05,0,0,0,0 units=m no_defs There are also some other entries, but those are without any datum shift. Those given seem to use only 3 parameters. Spatialreference.org gives exactly the same data: http://spatialreference.org/ref/epsg/?search=egypt&srtext=Search+EPSG+References If nothing else helps you could always calculate your self some datum parameters?? if you have some known points available. Regards: Janne. ------------------- Irwin Scollar kirjoitti: > Can anyone supply Helmert 7 parameter datum parameters between WGS84 > Ellipsoid and the Helmert 1906 Ellipsoid used in the "Red Belt, Blue > Belt, Purple Belt, Purple Belt Extended" Old Egyptian 1907 areas or > a link to where they may possibly be found? > > I have only the 3 parameter Molodensky transform data in the NIMA > 1987 Madtran and the later Geotran2 programs which may not have > errors as low as those of a modern dual frequency GPS receiver. > > Irwin Scollar > > _______________________________________________ > Proj mailing list > Proj@lists.maptools.org > http://lists.maptools.org/mailman/listinfo/proj > From geraldi.evenden at gmail.com Wed Aug 27 16:40:19 2008 From: geraldi.evenden at gmail.com (Gerald I. Evenden) Date: Wed Aug 27 16:40:27 2008 Subject: [Proj] Re: Global Gauss-Kruger and libproj4---the final story In-Reply-To: References: Message-ID: <200808271640.19868.geraldi.evenden@gmail.com> On Wednesday 27 August 2008 1:40:43 pm strebe wrote: > Not knowing anything about libproj4, I am surprised by this note. All > projections of the complete globe are "multivariate". What does libproj4 do > for other projections? Why would it not do something similar for > ellipsoidal transverse Mercator? Of course there is what might be called longitude "wrap around" of unrestrained longitude. libproj4 clips longitude at pi to prevent such problems (can be overridden). Granted there is an ambiguity at lon=pi(180) but that is the problem that is well understood and to be resolved by the calling applications. But libproj4 and any predecessor gives only *one* answer at lambda=pi. In the case of the split of the equator by TM, the longitude where the split occurs is determined by the eccentricity of the ellipsoid and thus there is no "standard" longitude of occurrence. Regardless of this detail it creates a problem totally unique to TM and would require specialized modification of application programs merely to handle this single projection. Given the *very* questionable application of TM in this region there is no practical excuse to pursue this problem. Also, unless I missed something in Lee's and Thompson's math, the mechanism for computing TM by their math would create execution times orders of magnitude slower than any of the current approximations. There are certainly legit debate over extended TM (beyond UTM zones) but I do not see any reason to continue with global TM. > Regards, > -- daan Strebe ... -- 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 strebe at aol.com Wed Aug 27 17:50:35 2008 From: strebe at aol.com (strebe) Date: Wed Aug 27 17:50:47 2008 Subject: [Proj] Re: Global Gauss-Kruger and libproj4---the final story In-Reply-To: <200808271640.19868.geraldi.evenden@gmail.com> Message-ID: Surely there is nothing unique to the ellipsoidal transverse Mercator in this regard. Consider, for example, a spherical coordinate rotation that leaves the equator coincident with the original 180th meridian of any cylindric or pseudocylindric projection. In order to draw the equator properly, it must be drawn at the locations of both the 180th east and west original meridians. There is no end to cases like this. While it is true the location of the cusp varies in the ellipsoidal transverse Mercator according to the eccentricity, that is merely a parameterization detail. Many projections vary something or another according to parameterization, and sometimes what varies is the location or extent of an interruption. Once you have an interruption, you have one-to-many mapping, and any map line coincident with that interruption must be drawn in (at least) two places in order to be correct. All global projections are interrupted. Given comments you have made in the past, I gather that the natural boundary of the projection is up to the client application (or some other library) to compute. This means that any imaging of lines coincident to interruptions must also be up to the client or some other library, since interruptions are always part of the natural boundary of the projection. Therefore the rationale of one-to-many mapping precluding a global ellipsoidal transverse Mercator in iibproj4 is fallacious. Ways a one-to-many situation may be handled: 1) The bare-bones projection package returns all values corresponding to the mapped input point. This is unsatisfactory when the result is not a finite number of points, such as a pole that is stretched into a line. A sophisticated solution would return an object instance that spits out cartesian points according to some parameterized form. In almost all instances, it would only spit out one result, but in the case of a typical interruption it would spit out two results, and in the case of a point-to-line mapping, it would spit out a different cartesian value for each value of a supplied parameter. I gather this is not an option for libproj4. 2) Don't. Just return a single value and put the onus on the client application or some other library. Since libproj4 already does this for the projection's natural boundary, client applications already understand that they need to know something about the projection in order to do anything useful with it. What is true with any projection is true with global ellipsoidal transverse Mercator: you need to know the natural boundary of the projection in order to draw it. Yes, the computation of an ellipsoidal transverse Mercator is an order of magnitude (or two) more expensive than series expansions for regions near the central meridian. Whether that is useful or practical for the client application should be up to the client. Naturally if you (and everyone else) is not inclined to program a global ellipsoidal transverse Mercator, then it will not happen. I do not encourage abandoning the project for reasons that are not reasonable, however. Regards, -- daan Strebe On Aug 27, 2008, at 1:40:19 PM, "Gerald I. Evenden" wrote: On Wednesday 27 August 2008 1:40:43 pm strebe wrote: > Not knowing anything about libproj4, I am surprised by this note. All > projections of the complete globe are "multivariate". What does libproj4 do > for other projections? Why would it not do something similar for > ellipsoidal transverse Mercator? Of course there is what might be called longitude "wrap around" of? unrestrained longitude. libproj4 clips longitude at pi to prevent such? problems (can be overridden). Granted there is an ambiguity at lon=pi(180)? but that is the problem that is well understood and to be resolved by the? calling applications. But libproj4 and any predecessor gives only *one*? answer at lambda=pi.? In the case of the split of the equator by TM, the longitude where the split? occurs is determined by the eccentricity of the ellipsoid and thus there is? no "standard" longitude of occurrence. Regardless of this detail it creates? a problem totally unique to TM and would require specialized modification of? application programs merely to handle this single projection. Given the? *very* questionable application of TM in this region there is no practical? excuse to pursue this problem. Also, unless I missed something in Lee's and? Thompson's math, the mechanism for computing TM by their math would create? execution times orders of magnitude slower than any of the current? approximations. There are certainly legit debate over extended TM (beyond UTM zones) but I do? not see any reason to continue with global TM. > Regards, > -- daan Strebe ... --? 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.maptools.org/pipermail/proj/attachments/20080827/88056245/attachment.html From geraldi.evenden at gmail.com Wed Aug 27 20:32:33 2008 From: geraldi.evenden at gmail.com (Gerald I. Evenden) Date: Wed Aug 27 20:32:45 2008 Subject: [Proj] Re: Global Gauss-Kruger and libproj4---the final story In-Reply-To: References: Message-ID: <200808272032.34133.geraldi.evenden@gmail.com> On Wednesday 27 August 2008 5:50:35 pm strebe wrote: > Surely there is nothing unique to the ellipsoidal transverse Mercator in > this regard. Consider, for example, a spherical coordinate rotation that > leaves the equator coincident with the original 180th meridian of any > cylindric or pseudocylindric projection. In order to draw the equator > properly, it must be drawn at the locations of both the 180th east and west > original meridians. There is no end to cases like this. Yes, you run into them every 10 to 20 years. > While it is true the location of the cusp varies in the ellipsoidal > transverse Mercator according to the eccentricity, that is merely a > parameterization detail. Many projections vary something or another > according to parameterization, and sometimes what varies is the location or > extent of an interruption. Once you have an interruption, you have > one-to-many mapping, and any map line coincident with that interruption > must be drawn in (at least) two places in order to be correct. All global > projections are interrupted. What do you mean by interrupted other than by the longitude boundary. If you are talking about interrupted maps such as Goode's Interrupted Homolosine projection, that is generated by 4 initialized libproj4 projection structures used by 8 geographic clipping windows for the fully fleshed out version. None of the libproj4 entries ever sees a geographic point out of range. The +proj=goode projection used by each of the initialized structures (differing only by initializing central meridians) has no "idea" of the complexity of the map being drawn and only returns *one* coordinate pair when called. > Given comments you have made in the past, I gather that the natural > boundary of the projection is up to the client application (or some other > library) to compute. Absolutely. libproj4 merely handles the projection part. It doesn't do windows. Those aspects are an entirely different disciplines and involve very different procedures. > This means that any imaging of lines coincident to > interruptions must also be up to the client or some other library, since > interruptions are always part of the natural boundary of the projection. > Therefore the rationale of one-to-many mapping precluding a global > ellipsoidal transverse Mercator in iibproj4 is fallacious. Image or display of the lines has *nothing* to do with the mechanics of computing the projection. In many situations, like grid computing, graphics operation are not involved. > Ways a one-to-many situation may be handled: If you say so. It is not the problem of a projection. > 1) The bare-bones projection package returns all values corresponding to > the mapped input point. > This is unsatisfactory when the result is not a > finite number of points, such as a pole that is stretched into a line. A A flat pole is graphically handled by repeated calls to libproj4 by the graphic software using varying longitude and fixed latitude at +-90. Knowledge of how to deal with various oddities in displaying the projection are functions of the calling software. > sophisticated solution would return an object instance that spits out > cartesian points according to some parameterized form. In almost all > instances, it would only spit out one result, but in the case of a typical > interruption it would spit out two results, and in the case of a > point-to-line mapping, it would spit out a different cartesian value for > each value of a supplied parameter. I have graphic procedures that handle line projection line graphics used in my manual and they operate with libproj4 only indicating that a point may be not be projectable or the next point has unexpected characteristics. In all cases, libproj4 *only* returns one point per entry with the only abnormal return for points not projectable, Its been working fine for nearly 40 years that way. > I gather this is not an option for libproj4. I am tired of repeating, libproj4 is *NOT* a graphic routine any more than sine or tangent. In the case of making maps it is merely the process that transforms information from one coordinate system to another! > 2) Don't. Just return a single value and put the onus on the client > application or some other library. Since libproj4 already does this for the > projection's natural boundary, client applications already understand that > they need to know something about the projection in order to do anything > useful with it. What is true with any projection is true with global > ellipsoidal transverse Mercator: you need to know the natural boundary of > the projection in order to draw it. No other projection has a requirement that the user needs to know an arcane formula to manipulate graphical usage to interpret the results. There is currently no means for libproj4 to return such information. > Yes, the computation of an ellipsoidal transverse Mercator is an order of > magnitude (or two) more expensive than series expansions for regions near > the central meridian. Whether that is useful or practical for the client > application should be up to the client. Naturally if you (and everyone > else) is not inclined to program a global ellipsoidal transverse Mercator, > then it will not happen. I do not encourage abandoning the project for > reasons that are not reasonable, however. What is reasonable??? As an academic curiosity---sure. As a practical projection? You have to be kidding! The last few kilometers of easting are so distorted that it is impossible to figure out what one is looking at. We lop off the top and bottom of Mercator, lets have the grace to do the same here. > > Regards, > -- daan Strebe ... -- 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 strebe at aol.com Thu Aug 28 00:37:36 2008 From: strebe at aol.com (strebe) Date: Thu Aug 28 00:37:49 2008 Subject: [Proj] Re: Global Gauss-Kruger and libproj4---the final story In-Reply-To: <200808272032.34133.geraldi.evenden@gmail.com> Message-ID: <5EFA3E26.0382.43E3.A106.8D2012D948E8@aol.com> On Aug 27, 2008, at 5:32:33 PM, "Gerald I. Evenden" wrote: ________ Yes, you run into them every 10 to 20 years. ________ No, I run into them commonly. Perhaps you run into them every ten or twenty years. ________ No other projection has a requirement that the user needs to know an arcane? formula to manipulate graphical usage to interpret the results. There is? currently no means for libproj4 to return such information.? ________ I do not understand that utterance. The problem has nothing to with "graphical usage", whatever that means. It has to do with the results of the projection at a single point.?Many world projections do not come with a 90?N/S, 180? E/W natural boundary that the client software can treat as some fixed convention, and all projections have interruptions. An interruption automatically means the projection formul? are not a function, which renders this utterance invalid: ________ I am tired of repeating, libproj4 is *NOT* a graphic routine any more than? sine or tangent. In the case of making maps it is merely the process that? transforms information from one coordinate system to another! ________ Sine and tangent are functions. A projection is not. It is generating formul? that are (usually) a function over the range of the map except at boundaries, where they are multivalued. You have chosen, for your own convenience, to ignore the the possible multiple results of the projecting formul?. That is fine, but it does not make your rant correct; it only makes your decision convenient for you. In any case, if you're tired of repeating yourself, then quit repeating yourself. I suspect everyone else is tired of it, too ? particularly because it's a straw man. Would you like a list of world projections whose boundaries differ from the boundaries of finite cylindric projections? And if there are many projections with other kinds of boundaries, would you explain again how it is that the ellipsoidal transverse Mercator is somehow unique in that regard? I don't care if you don't implement a global ellipsoidal transverse Mercator. If you don't want to implement it, then don't implement it. Surely no one can begrudge that ? no one's paying you to, as far as I know. I just don't see the point of rationalizing that decision with sophistry, or why you'd expect your audience to swallow the rationalizations. I suggest just stating that you're not convinced of the value of the work, or that you hate the ellipsoidal transverse Mercator, or that you're tired, and be done with it. Which reminds me: once again, I am tired of these sorts of conversations, and am done with this one. Regards, -- daan Strebe On Aug 27, 2008, at 5:32:33 PM, "Gerald I. Evenden" wrote: From: "Gerald I. Evenden" Subject: Re: Global Gauss-Kruger and libproj4---the final story Date: August 27, 2008 5:32:33 PM PDT To: strebe Cc: proj@lists.maptools.org On Wednesday 27 August 2008 5:50:35 pm strebe wrote: > Surely there is nothing unique to the ellipsoidal transverse Mercator in > this regard. Consider, for example, a spherical coordinate rotation that > leaves the equator coincident with the original 180th meridian of any > cylindric or pseudocylindric projection. In order to draw the equator > properly, it must be drawn at the locations of both the 180th east and west > original meridians. There is no end to cases like this. Yes, you run into them every 10 to 20 years. > While it is true the location of the cusp varies in the ellipsoidal > transverse Mercator according to the eccentricity, that is merely a > parameterization detail. Many projections vary something or another > according to parameterization, and sometimes what varies is the location or > extent of an interruption. Once you have an interruption, you have > one-to-many mapping, and any map line coincident with that interruption > must be drawn in (at least) two places in order to be correct. All global > projections are interrupted. What do you mean by interrupted other than by the longitude boundary. If you? are talking about interrupted maps such as Goode's Interrupted Homolosine? projection, that is generated by 4 initialized libproj4 projection structures? used by 8 geographic clipping windows for the fully fleshed out version.? None of the libproj4 entries ever sees a geographic point out of range. The? +proj=goode projection used by each of the initialized structures (differing? only by initializing central meridians) has no "idea" of the complexity of? the map being drawn and only returns *one* coordinate pair when called. > Given comments you have made in the past, I gather that the natural > boundary of the projection is up to the client application (or some other > library) to compute. Absolutely. libproj4 merely handles the projection part. It doesn't do? windows. Those aspects are an entirely different disciplines and involve? very different procedures. > This means that any imaging of lines coincident to? > interruptions must also be up to the client or some other library, since > interruptions are always part of the natural boundary of the projection. > Therefore the rationale of one-to-many mapping precluding a global > ellipsoidal transverse Mercator in iibproj4 is fallacious. Image or display of the lines has *nothing* to do with the mechanics of? computing the projection. In many situations, like grid computing, graphics? operation are not involved. > Ways a one-to-many situation may be handled: If you say so. It is not the problem of a projection. > 1) The bare-bones projection package returns all values corresponding to > the mapped input point. > This is unsatisfactory when the result is not a? > finite number of points, such as a pole that is stretched into a line. A A flat pole is graphically handled by repeated calls to libproj4 by the? graphic software using varying longitude and fixed latitude at +-90.? Knowledge of how to deal with various oddities in displaying the projection? are functions of the calling software. > sophisticated solution would return an object instance that spits out > cartesian points according to some parameterized form. In almost all > instances, it would only spit out one result, but in the case of a typical > interruption it would spit out two results, and in the case of a > point-to-line mapping, it would spit out a different cartesian value for > each value of a supplied parameter. I have graphic procedures that handle line projection line graphics used in my? manual and they operate with libproj4 only indicating that a point may be not? be projectable or the next point has unexpected characteristics. In all? cases, libproj4 *only* returns one point per entry with the only abnormal? return for points not projectable, Its been working fine for nearly 40 years? that way. > I gather this is not an option for libproj4. I am tired of repeating, libproj4 is *NOT* a graphic routine any more than? sine or tangent. In the case of making maps it is merely the process that? transforms information from one coordinate system to another! > 2) Don't. Just return a single value and put the onus on the client > application or some other library. Since libproj4 already does this for the > projection's natural boundary, client applications already understand that > they need to know something about the projection in order to do anything > useful with it. What is true with any projection is true with global > ellipsoidal transverse Mercator: you need to know the natural boundary of > the projection in order to draw it. No other projection has a requirement that the user needs to know an arcane? formula to manipulate graphical usage to interpret the results. There is? currently no means for libproj4 to return such information.? > Yes, the computation of an ellipsoidal transverse Mercator is an order of > magnitude (or two) more expensive than series expansions for regions near > the central meridian. Whether that is useful or practical for the client > application should be up to the client. Naturally if you (and everyone > else) is not inclined to program a global ellipsoidal transverse Mercator, > then it will not happen. I do not encourage abandoning the project for > reasons that are not reasonable, however. What is reasonable??? As an academic curiosity---sure. As a practical? projection? You have to be kidding! The last few kilometers of easting are? so distorted that it is impossible to figure out what one is looking at. We? lop off the top and bottom of Mercator, lets have the grace to do the same? here. > > Regards, > -- daan Strebe ... --? 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.maptools.org/pipermail/proj/attachments/20080827/dce58253/attachment-0001.html From yves.moisan at boreal-is.com Thu Aug 28 09:18:56 2008 From: yves.moisan at boreal-is.com (Yves Moisan) Date: Thu Aug 28 09:19:02 2008 Subject: [Proj] Arbitrary translation and custom projection Message-ID: <1219929536.6757.13.camel@dell-desktop.example.com> Hi All, In PostGIS, we have points in a local system that we have made an affine transformation for to get them in EPSG 900913. We followed instructions at http://casoilresource.lawr.ucdavis.edu/drupal/node/433 so we collected a bunch of GCP's, ran a regression and applied the resulting coefficients to transform our local coordinate points to 900913 using affine(). I guess we could alternatively determine a custom projection string and use transform. I would like to know about pointers to tutorials as to how to do that. TIA, Yves Moisan From geraldi.evenden at gmail.com Thu Aug 28 11:46:59 2008 From: geraldi.evenden at gmail.com (Gerald I. Evenden) Date: Thu Aug 28 11:47:08 2008 Subject: [Proj] Re: Global Gauss-Kruger and libproj4---the final story In-Reply-To: <5EFA3E26.0382.43E3.A106.8D2012D948E8@aol.com> References: <5EFA3E26.0382.43E3.A106.8D2012D948E8@aol.com> Message-ID: <200808281146.59454.geraldi.evenden@gmail.com> On Thursday 28 August 2008 12:37:36 am strebe wrote: > On Aug 27, 2008, at 5:32:33 PM, "Gerald I. Evenden" > wrote: > > ________ > > Yes, you run into them every 10 to 20 years. > > ________ > > No, I run into them commonly. Perhaps you run into them every ten or twenty > years. Perhaps you would like to present an example. ______ > > No other projection has a requirement that the user needs to know an > arcane? formula to manipulate graphical usage to interpret the results. > There is currently no means for libproj4 to return such information. > > ________ > > I do not understand that utterance. The problem has nothing to with > "graphical usage", whatever that means. It has to do with the results of > the projection at a single point.?Many world projections do not come with a > 90?N/S, 180? E/W natural boundary that the client software can treat as > some fixed convention, and all projections have interruptions. An > interruption automatically means the projection formul? are not a function, > which renders this utterance invalid: The only context that I use the term "interruption" in discussing cartographic projections are in cases like Goode's world maps or "orange peal" charts often using the sinusoidal projection. Please define what *you* mean by interruptions. > ________ > > I am tired of repeating, libproj4 is *NOT* a graphic routine any more than? > sine or tangent. In the case of making maps it is merely the process that? > transforms information from one coordinate system to another! Amen! > ________ > > Sine and tangent are functions. A projection is not. Let us stop here for a moment. From an online dictionary: "function (math) A quantity so connected with another quantity that if any alteration be made in the latter there will be a consequential alteration in the former." In this case lat,lon <=>x,y. Change lat,lon and you change x,y and vice versa. The mechanism that determines the functional relationship is the cartographic transformation---a procedure that defines the relationship between two coordinate systems. In the case of computing Z=f(K), f is a function. > It is generating > formul? that are (usually) a function over the range of the map except at > boundaries, where they are multivalued. You have chosen, for your own > convenience, to ignore the the possible multiple results of the projecting > formul?. That is fine, but it does not make your rant correct; it only > makes your decision convenient for you. In any case, if you're tired of > repeating yourself, then quit repeating yourself. I suspect everyone else > is tired of it, too ? particularly because it's a straw man. > Would you like a list of world projections whose boundaries differ from the > boundaries of finite cylindric projections? I am aware of some, especially those I call cartoon projections (I do not mean that in a pejorative way) like those that plot the world on a cube or some other solid or ones with very odd boundary system. These are usually very interrupted projections requiring difficult geographic clipping functions that (other than longitude range reduction) is *not* a function of libproj4. We have already covered the +-180 problem and flat pole maps. Let's see, cylindricals, pseudocylindricals, conics, globulars, ... . Even general oblique projections are no problem other than odd boundaries. I managed to make plots of the above with libproj4 as it now stands. See manual. Please list a few provided there is a url to a picture of the listed projection. > And if there are many > projections with other kinds of boundaries, would you explain again how it > is that the ellipsoidal transverse Mercator is somehow unique in that > regard? > > I don't care if you don't implement a global ellipsoidal transverse > Mercator. If you don't want to implement it, then don't implement it. > Surely no one can begrudge that ? no one's paying you to, as far as I know. > I just don't see the point of rationalizing that decision with sophistry, > or why you'd expect your audience to swallow the rationalizations. I > suggest just stating that you're not convinced of the value of the work, or > that you hate the ellipsoidal transverse Mercator, or that you're tired, > and be done with it. Which reminds me: once again, I am tired of these > sorts of conversations, and am done with this one. Oh gee. But this is so much fun! Please don't go. > Regards, > -- daan Strebe ... -- 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 strebe at aol.com Thu Aug 28 17:30:30 2008 From: strebe at aol.com (strebe@aol.com) Date: Thu Aug 28 17:30:46 2008 Subject: [Proj] Re: Global Gauss-Kruger and libproj4---the final story In-Reply-To: <200808281146.59454.geraldi.evenden@gmail.com> References: <5EFA3E26.0382.43E3.A106.8D2012D948E8@aol.com> <200808281146.59454.geraldi.evenden@gmail.com> Message-ID: <8CAD76C6E12B518-6C0-25DB@webmail-ne03.sysops.aol.com> >The only context that I use the term "interruption" in discussing >cartographic projections are in cases like Goode's world maps or >"orange peal" charts often using the sinusoidal projection. Please >define what *you* mean by interruptions. An interruption is any location where two points of infinitesimal separation on the globe are mapped to two points having finite separation on the plane. This happens somewhere on all projections. All along an interruption, the projection formul? are no longer a function; they are multivalue. Regards, -- daan Strebe -----Original Message----- From: Gerald I. Evenden To: strebe Cc: proj@lists.maptools.org Sent: Thu, 28 Aug 2008 8:46 am Subject: Re: Global Gauss-Kruger and libproj4---the final story On Thursday 28 August 2008 12:37:36 am strebe wrote: > On Aug 27, 2008, at 5:32:33 PM, "Gerald I. Evenden" > wrote: > > ________ > > Yes, you run into them every 10 to 20 years. > > ________ > > No, I run into them commonly. Perhaps you run into them every ten or twenty > years. Perhaps you would like to present an example. ______ > > No other projection has a requirement that the user needs to know an > arcane? formula to manipulate graphical usage to interpret the results. > There is currently no means for libproj4 to return such information. > > ________ > > I do not understand that utterance. The problem has nothing to with > "graphical usage", wha tever that means. It has to do with the results of > the projection at a single point.?Many world projections do not come with a > 90?N/S, 180? E/W natural boundary that the client software can treat as > some fixed convention, and all projections have interruptions. An > interruption automatically means the projection formul? are not a function, > which renders this utterance invalid: The only context that I use the term "interruption" in discussing cartographic projections are in cases like Goode's world maps or "orange peal" charts often using the sinusoidal projection. Please define what *you* mean by interruptions. > ________ > > I am tired of repeating, libproj4 is *NOT* a graphic routine any more than? > sine or tangent. In the case of making maps it is merely the process that? > transforms information from one coordinate system to another! Amen! > ________ > > Sine and tangent are functions. A projection is not. Let us stop here for a moment. From an online dictionary: "function (math) A quantity so connected with another quantity that if any alteration be made in the latter there will be a consequential alteration in the former." In this case lat,lon <=>x,y. Change lat,lon and you change x,y and vice versa. The mechanism that determines the functional relationship is the cartographic transformation---a procedure that defines the relationship between two coordinate systems. In the case of computing Z=f(K), f is a function. > It is generating > formul? that are (usually) a function over the range of the map except at > boundaries, where they are multivalued. You have chosen, for your own > convenience, to ignore the the possible multiple results of the projecting > formul?. That is fine, but it does not make your rant correct; it only > makes your decision convenient for you. In any case, if you're tired of > repeating yourself, then quit repeating yourself. I suspect everyone else > is tired of it, too ? particularly because it's a straw man. > Would you like a list of world projections whose boundaries differ from the > boundaries of finite cylindric projections? I am aware of some, especially those I call cartoon projections (I do not mean that in a pejorative way) like those that plot the world on a cube or some other solid or ones with very odd boundary system. These are usually very interrupted projections requiring difficult geographic clipping functions that (other than longitude range reduction) is *not* a function of libproj4. We have already covered the +-180 problem and flat pole maps. Let's see, cylindricals, pseudocylindricals, conics, globulars, ... . Even general oblique projections are no problem other than odd boundaries. I managed to make plots of the above with libproj4 as it now stands. See manual. Please list a few provided there is a url to a picture of the listed projection. > And if there are many > projections with other kinds of boundaries, would you ex plain again how it > is that the ellipsoidal transverse Mercator is somehow unique in that > regard? > > I don't care if you don't implement a global ellipsoidal transverse > Mercator. If you don't want to implement it, then don't implement it. > Surely no one can begrudge that ? no one's paying you to, as far as I know. > I just don't see the point of rationalizing that decision with sophistry, > or why you'd expect your audience to swallow the rationalizations. I > suggest just stating that you're not convinced of the value of the work, or > that you hate the ellipsoidal transverse Mercator, or that you're tired, > and be done with it. Which reminds me: once again, I am tired of these > sorts of conversations, and am done with this one. Oh gee. But this is so much fun! Please don't go. > Regards, > -- daan Strebe ... -- 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.maptools.org/pipermail/proj/attachments/20080828/04802dc3/attachment.html From geraldi.evenden at gmail.com Thu Aug 28 20:04:53 2008 From: geraldi.evenden at gmail.com (Gerald I. Evenden) Date: Thu Aug 28 20:05:00 2008 Subject: [Proj] Re: Global Gauss-Kruger and libproj4---the final story In-Reply-To: <8CAD76C6E12B518-6C0-25DB@webmail-ne03.sysops.aol.com> References: <5EFA3E26.0382.43E3.A106.8D2012D948E8@aol.com> <200808281146.59454.geraldi.evenden@gmail.com> <8CAD76C6E12B518-6C0-25DB@webmail-ne03.sysops.aol.com> Message-ID: <200808282004.53979.geraldi.evenden@gmail.com> On Thursday 28 August 2008 5:30:30 pm strebe@aol.com wrote: > >The only context that I use the term "interruption" in discussing > >cartographic projections are in cases like Goode's world maps or > >"orange peal" charts often using the sinusoidal projection. Please > >define what *you* mean by interruptions. > > An interruption is any location where two points of infinitesimal > separation on the globe are mapped to two points having finite separation > on the plane. This happens somewhere on all projections. All along an > interruption, the projection formul? are no longer a function; they are > multivalue. Let's see. tan(x) has two values at x=90 degrees: +inf and -inf. So it is no longer a function, eh? I can't find any such distinction for the definition of a "function." Please give reference. Even if your questionable definition were true, it merely verifies that proj_fwd() is a function because it only returns one value. It is defined that way in the documentation. In terms of interruptions applying to all projections I presume you are referring to the del-lon=180 condition. In many projection software this is not a break and the map merely repeats on in the x direction. As far as I am aware it is always the graphic programmers job to handle this condition and not the projection routine: when at the map edge recall the function with the sign of the lon term reversed. BTW: you are the first person I have ever heard that refers to the wrap-around condition of longitude as an interruption if, indeed, that is what you are referring to. If there are other examples, other than projections commonly recognized as interrupted (for example Goode) *please* name them. > Regards, > -- daan Strebe -- 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 cjmce at lsu.edu Thu Aug 28 22:08:35 2008 From: cjmce at lsu.edu (Clifford J Mugnier) Date: Thu Aug 28 22:10:00 2008 Subject: [Proj] Re: Global Gauss-Kruger and libproj4---the final story References: <5EFA3E26.0382.43E3.A106.8D2012D948E8@aol.com><200808281146.59454.geraldi.evenden@gmail.com><8CAD76C6E12B518-6C0-25DB@webmail-ne03.sysops.aol.com> <200808282004.53979.geraldi.evenden@gmail.com> Message-ID: WOW! And some people call me arrogant ... Lighten up, fella. Cliff Mugnier ________________________________ From: proj-bounces@lists.maptools.org on behalf of Gerald I. Evenden Sent: Thu 28-Aug-08 19:04 To: strebe@aol.com Cc: proj@lists.maptools.org Subject: [Proj] Re: Global Gauss-Kruger and libproj4---the final story On Thursday 28 August 2008 5:30:30 pm strebe@aol.com wrote: > >The only context that I use the term "interruption" in discussing > >cartographic projections are in cases like Goode's world maps or > >"orange peal" charts often using the sinusoidal projection. Please > >define what *you* mean by interruptions. > > An interruption is any location where two points of infinitesimal > separation on the globe are mapped to two points having finite separation > on the plane. This happens somewhere on all projections. All along an > interruption, the projection formul? are no longer a function; they are > multivalue. Let's see. tan(x) has two values at x=90 degrees: +inf and -inf. So it is no longer a function, eh? I can't find any such distinction for the definition of a "function." Please give reference. Even if your questionable definition were true, it merely verifies that proj_fwd() is a function because it only returns one value. It is defined that way in the documentation. In terms of interruptions applying to all projections I presume you are referring to the del-lon=180 condition. In many projection software this is not a break and the map merely repeats on in the x direction. As far as I am aware it is always the graphic programmers job to handle this condition and not the projection routine: when at the map edge recall the function with the sign of the lon term reversed. BTW: you are the first person I have ever heard that refers to the wrap-around condition of longitude as an interruption if, indeed, that is what you are referring to. If there are other examples, other than projections commonly recognized as interrupted (for example Goode) *please* name them. > Regards, > -- daan Strebe -- 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.maptools.org/pipermail/proj/attachments/20080828/d5e72f31/attachment.html From strebe at aol.com Thu Aug 28 22:23:31 2008 From: strebe at aol.com (strebe) Date: Thu Aug 28 22:23:42 2008 Subject: [Proj] Re: Global Gauss-Kruger and libproj4---the final story In-Reply-To: <200808282004.53979.geraldi.evenden@gmail.com> Message-ID: On Aug 28, 2008, at 5:04:53 PM, "Gerald I. Evenden" wrote: Let's see. tan(x) has two values at x=90 degrees: +inf and -inf. So it is no? longer a function, eh? Infinity is not a value. Your conception and definitions are not mathematical. Tangent is undefined at an abscissa of 90??180?, with the ordinate?increasing?asymptotically as the abscissa approaches 90??180? from lesser values, and with the ordinate decreasing asymptotically as the abscissa approaches 90??180? from greater values. I will not respond to any argument over this, since it is basic mathematics, available anywhere. Any mathematician would disagree with your characterization. Infinity as a value is a convenient fiction, but it does not always work, and it does not bear on the question of whether tangent is a function or not. I can't find any such distinction for the definition of a "function." Please? give reference. See, for example,? http://mathworld.wolfram.com/MultivaluedFunction.html A bazillion other Web pages will do, easily searched for. Even if your questionable definition were true, it merely verifies that? proj_fwd() is a function because it only returns one value. It is defined? that way in the documentation. You have, yet again, confused yourself about the who is arguing what. Yes. You treat projections as functions. That's clear. That's always been clear. That's THE problem. You have decided it's not YOUR problem, so now it's your clients' problem. That doesn't make the problem go away. It just changes who it's a problem for.??I have specifically acknowledged multiple times that you have chosen, for your convenience, to ignore the multivalued results of projection formul? in order to treat projections as functions. Why are you crowing about this evidence of proj_fwd() being a function when its functional nature is exactly why we're even having this conversation? In terms of interruptions applying to all projections I presume you are? referring to the del-lon=180 condition. In many projection software this is? not a break and the map merely repeats on in the x direction. That is impossible for almost all projections that are not cylindric or pseudocylindric. It's merely a convenient evasion of responsibility that works for two common classes of projections. Meanwhile it can't work for most projections because most projections depend on trigonometric (and therefore periodic) manipulations of longitude, resulting in extended longitudinal ranges wrapping back onto themselves ? resulting, even, on 180?E mapping onto 180?W. As far as I am? aware it is always the graphic programmers job to handle this condition and? not the projection routine: when at the map edge recall the function with the? sign of the lon term reversed. As far as "recall the function with the sign of the lon term reversed" goes, see the prior comment. This was never about whose job it is. You're free to decide what's your job and what isn't. Rather, it's a matter of what has to happen regardless of who does what in order to get the job done.? You have declared with much sophistry that somehow the ellipsoidal transverse Mercator can't be accommodated in libproj4 because of the cusps. That's nonsense. There is nothing unique to that projection from libproj4's perspective. Since you have put the onus of interruptions and odd boundaries on the client, then the same would be true in the case of the ellipsoidal transverse Mercator. Meanwhile libproj4 could happily provide one result of the multivalued formul? along the cusp, just as it does for every projection. BTW: you are the first person I have ever heard that refers to the wrap-around? condition of longitude as an interruption if, indeed, that is what you are? referring to. That is what I am referring to. It is an interruption by any rational analysis. I don't care if you call it a phlabbergompkin to distinguish it from what you call an interruption (which you would never be able to provide a definition for that's not arbitrary). It's exactly the same thing, and what you seem to think of as an "uninterrupted" map is undeniably interrupted. It's not important what it's called. It's important what it does. What it does is separate points on the map that are adjacent on the globe. If there are other examples, other than projections commonly recognized as? interrupted (for example Goode) *please* name them. *Berghaus star *Peirce quincuncial *Waterman *Fuller dymaxion *Cahill butterfly *Guyou *Raizs armadillo *two-point equidistant *vertical perspective *general perspective *all of the dozens of polyhedral projections described in the literature *any projection in oblique aspect (which you handle with something of a hack, it appears) Since whatever definition you use for "interruption" appears to be arbitrary, and I have no access to your arbitrary definition, I cannot guarantee that you'll agree that all the projections in that list are "interrupted" by your definition but are not "commonly recognized" as interrupted. That's not my problem, and I will not argue over the list or its meaning. I chose projections whose natural boundaries do not follow the common cylindric or azimuthal bounding parallels and meridians. The list is hardly exhaustive. Perhaps you'll claim those are all cartoon projections, or nobody uses them, or whatever else. I don't care. Not my problem. It's a reasonable policy for you to limit your software to handle 95% of the needs and blow off the rest. It's not reasonable for you to claim your reasons are founded on some natural property of map projections. They're not. My point has only ever been that you're rationalizing your decision not to support the ellipsoidal transverse Mercator with fallacious arguments, and I do not wish for the (doubtless rapidly fading) audience to be confused by such remarks. Regards, -- daan Strebe On Aug 28, 2008, at 5:04:53 PM, "Gerald I. Evenden" wrote: From: "Gerald I. Evenden" Subject: Re: Global Gauss-Kruger and libproj4---the final story Date: August 28, 2008 5:04:53 PM PDT To: strebe@aol.com Cc: proj@lists.maptools.org On Thursday 28 August 2008 5:30:30 pm strebe@aol.com wrote: > >The only context that I use the term "interruption" in discussing > >cartographic projections are in cases like Goode's world maps or > >"orange peal" charts often using the sinusoidal projection. Please > >define what *you* mean by interruptions. > > An interruption is any location where two points of infinitesimal > separation on the globe are mapped to two points having finite separation > on the plane. This happens somewhere on all projections. All along an > interruption, the projection formul? are no longer a function; they are > multivalue. Let's see. tan(x) has two values at x=90 degrees: +inf and -inf. So it is no? longer a function, eh? I can't find any such distinction for the definition of a "function." Please? give reference. Even if your questionable definition were true, it merely verifies that? proj_fwd() is a function because it only returns one value. It is defined? that way in the documentation. In terms of interruptions applying to all projections I presume you are? referring to the del-lon=180 condition. In many projection software this is? not a break and the map merely repeats on in the x direction. As far as I am? aware it is always the graphic programmers job to handle this condition and? not the projection routine: when at the map edge recall the function with the? sign of the lon term reversed. BTW: you are the first person I have ever heard that refers to the wrap-around? condition of longitude as an interruption if, indeed, that is what you are? referring to. If there are other examples, other than projections commonly recognized as? interrupted (for example Goode) *please* name them. > Regards, > -- daan Strebe --? 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.maptools.org/pipermail/proj/attachments/20080828/e67bcb8f/attachment-0001.html From glynn at gclements.plus.com Thu Aug 28 22:34:44 2008 From: glynn at gclements.plus.com (Glynn Clements) Date: Thu Aug 28 22:34:53 2008 Subject: [Proj] Re: Global Gauss-Kruger and libproj4---the final story In-Reply-To: <200808282004.53979.geraldi.evenden@gmail.com> References: <5EFA3E26.0382.43E3.A106.8D2012D948E8@aol.com> <200808281146.59454.geraldi.evenden@gmail.com> <8CAD76C6E12B518-6C0-25DB@webmail-ne03.sysops.aol.com> <200808282004.53979.geraldi.evenden@gmail.com> Message-ID: <18615.24644.535509.694120@cerise.gclements.plus.com> Gerald I. Evenden wrote: > > > The only context that I use the term "interruption" in discussing > > > cartographic projections are in cases like Goode's world maps or > > > "orange peal" charts often using the sinusoidal projection. Please > > > define what *you* mean by interruptions. > > > > An interruption is any location where two points of infinitesimal > > separation on the globe are mapped to two points having finite separation > > on the plane. This happens somewhere on all projections. All along an > > interruption, the projection formul? are no longer a function; they are > > multivalue. > > Let's see. tan(x) has two values at x=90 degrees: +inf and -inf. Depending upon your definition of tan(), it may be undefined, single-valued or two-valued at odd multiples of pi. The set of real numbers doesn't include infinity, so if tan() is defined with the real line as its range, it is undefined at such points. If it's defined with its range as the projective (one-point) compactification of the real line (the real line plus a single point at infinity), it's single valued. If its range is the affine (two-point) compactification of the real line (with separate positive and negative infinities), then its multi-valued. >From a programming perspective, whether you have a single infinity or signed infinities depends upon the CPU and its configuration. The 80287 had a flag bit to select the behaviour, while the 80387 onwards only supports signed (affine) infinities. [One consequence of using affine infinity is that the comparison operation only tests equivalence, not (extensional) equality: -0 == +0 but 1/-0 =/= 1/+0.] > So it is no longer a function, eh? > > I can't find any such distinction for the definition of a "function." Please > give reference. By the set-theoretical definition, a function must be single-valued; that's the only factor which separates functions from relations. -- Glynn Clements From geraldi.evenden at gmail.com Fri Aug 29 10:57:48 2008 From: geraldi.evenden at gmail.com (Gerald I. Evenden) Date: Fri Aug 29 10:57:59 2008 Subject: [Proj] Re: Global Gauss-Kruger and libproj4---the final story In-Reply-To: References: Message-ID: <200808291057.49121.geraldi.evenden@gmail.com> On Thursday 28 August 2008 10:23:31 pm strebe wrote: > On Aug 28, 2008, at 5:04:53 PM, "Gerald I. Evenden" > wrote: Let's see. tan(x) has two values at x=90 > degrees: +inf and -inf. So it is no longer a function, eh? > Infinity is not a value. Your conception and definitions are not > mathematical. > > Tangent is undefined at an abscissa of 90??180?, with the > ordinate?increasing?asymptotically as the abscissa approaches 90??180? from > lesser values, and with the ordinate decreasing asymptotically as the > abscissa approaches 90??180? from greater values. I will not respond to any > argument over this, since it is basic mathematics, available anywhere. Any > mathematician would disagree with your characterization. Infinity as a > value is a convenient fiction, but it does not always work, and it does not > bear on the question of whether tangent is a function or not. I can't find > any such distinction for the definition of a "function." Please give > reference. > See, for example,? > > http://mathworld.wolfram.com/MultivaluedFunction.html LOL. It is still a function. So? > A bazillion other Web pages will do, easily searched for. > Even if your questionable definition were true, it merely verifies that? > proj_fwd() is a function because it only returns one value. It is defined? > that way in the documentation. > You have, yet again, confused yourself about the who is arguing what. Yes. > You treat projections as functions. That's clear. That's always been clear. > That's THE problem. It only seems to be only a problem with you. I have not had anyone else bitch and moan about it. > You have decided it's not YOUR problem, so now it's > your clients' problem. That doesn't make the problem go away. It just > changes who it's a problem for.??I have specifically acknowledged multiple > times that you have chosen, for your convenience, to ignore the multivalued > results of projection formul? in order to treat projections as functions. > Why are you crowing Why do you insist on getting insulting. I merely define a condition. Is it "crowing" about it??? > about this evidence of proj_fwd() being a function when > its functional nature is exactly why we're even having this conversation? > In terms of interruptions applying to all projections I presume you are > referring to the del-lon=180 condition. In many projection software this is > not a break and the map merely repeats on in the x direction. > That is impossible for almost all projections that are not cylindric or > pseudocylindric. It's merely a convenient evasion of responsibility that LOL again. > works for two common classes of projections. Meanwhile it can't work for > most projections because most projections depend on trigonometric (and > therefore periodic) manipulations of longitude, resulting in extended > longitudinal ranges wrapping back onto themselves ? resulting, even, on > 180?E mapping onto 180?W. As far as I am > aware it is always the graphic programmers job to handle this condition > and? not the projection routine: when at the map edge recall the function > with the sign of the lon term reversed. > As far as "recall the function with the sign of the lon term reversed" > goes, see the prior comment. Hey sweet cheeks. Since you hate libproj4 so much why do you even bother sticking around here. I guess it is for the datum issues which I do not involve myself with. > This was never about whose job it is. You're free to decide what's your job > and what isn't. Rather, it's a matter of what has to happen regardless of > who does what in order to get the job done.? I have defined where libproj4 begins and ends long ago. So? If you do not like it go somewhere else rather than pursue these windmills. > You have declared with much sophistry that somehow the ellipsoidal > transverse Mercator can't be accommodated in libproj4 because of the cusps. > That's nonsense. There is nothing unique to that projection from libproj4's > perspective. Since you have put the onus of interruptions and odd > boundaries on the client, Because, by definition, that's where it is placed. Again, if you have never liked the conditions of the program why do you stick around and persist with character assassinations on graphical issues that other user are most likely aware of? > then the same would be true in the case of the > ellipsoidal transverse Mercator. Meanwhile libproj4 could happily provide > one result of the multivalued formul? along the cusp, just as it does for > every projection. BTW: you are the first person I have ever heard that > refers to the wrap-around condition of longitude as an interruption if, > indeed, that is what you are referring to. > That is what I am referring to. It is an interruption by any rational > analysis. I don't care if you call it a phlabbergompkin to distinguish it > from what you call an interruption (which you would never be able to > provide a definition for that's not arbitrary). It's exactly the same > thing, and what you seem to think of as an "uninterrupted" map is > undeniably interrupted. It's not important what it's called. It's important > what it does. What it does is separate points on the map that are adjacent > on the globe. If there are other examples, other than projections commonly > recognized as interrupted (for example Goode) *please* name them. > *Berghaus star > *Peirce quincuncial > *Waterman > *Fuller dymaxion > *Cahill butterfly > *Guyou > *Raizs armadillo > *two-point equidistant > *vertical perspective > *general perspective > *all of the dozens of polyhedral projections described in the literature > *any projection in oblique aspect (which you handle with something of a > hack, it appears) As I have said many times, libproj4 does not handle cartoon projections like Berghaus star. Among some of the above I presume that you may be referring to visibility cutoffs such as in the perspectives and libproj4 indicates these by returning unprojectable condition. Several have odd boundaries which libproj4 handles properly by also returning unprojectable status for a point outside the visible or plottable boundary. With the comment about the oblique procedure you are also insulting the late John Snyder as I merely implemented his formulae. Which is true with several of the other projections as I relied upon his formulae for conditions of visibility---the results are reflected in the return condition of the libproj4 *function*. > Since whatever definition you use for "interruption" appears to be > arbitrary, and I have no access to your arbitrary definition, I cannot > guarantee that you'll agree that all the projections in that list are > "interrupted" by your definition but are not "commonly recognized" as > interrupted. My goodness, how you like to convolute an argument. It has long been recognized by me that we *do not* have a common definition for "interrupted" projection. But you like to persist in exploring this issue in an attempt to support you claims and issues. As another example, you appear to term the "invisibility" of a point in a projection like near-sided perspective as a interuption or at least the line where visibility does or does not occur (the "limb"). For libproj4 the issue is *only* where a point is visible or not---nor is the boundary of visibility an interruption. *Please* remember that libproj4 very easily tells the user about the visibility of the point. There is nothing else to be said. If you do not like it, fine. Go someplace else. I have been perfectly transparent and hopefully clear as to what libproj4 provides and have not hidden anything. > That's not my problem, and I will not argue over the list or > its meaning. I chose projections whose natural boundaries do not follow the > common cylindric or azimuthal bounding parallels and meridians. The list is > hardly exhaustive. The number of projections is beyond estimation. libproj4 only scratches the surface with about 170 entry points, some of which create other "named" projections with appropriate options. My efforts are limited to what descriptions are available and even here I have not included some because of some unique property or condition of the projection. The lastest victim being the world extent TM. > Perhaps you'll claim those are all cartoon projections, or nobody uses > them, or whatever else. I don't care. Not my problem. It's a reasonable > policy for you to limit your software to handle 95% of the needs and blow > off the rest. It's not reasonable for you to claim your reasons are founded > on some natural property of map projections. They're not. Two states are apparent either I failed to give a clear description of the original problem or you do not have the mental capability to understand it. All this subsequent BS has had little to do with my original issue. > My point has only > ever been that you're rationalizing your decision not to support the > ellipsoidal transverse Mercator with fallacious arguments, and I do not > wish for the (doubtless rapidly fading) audience to be confused by such > remarks. I realize that this is merely a lover's quarrel and certainly will not be our last. Of course, I will make the obligatory counter claim about your irrational arguments and ridiculous conditions. > > Regards, > -- daan Strebe Goodnight sweetheart. Don't let the bedbugs bite. ... -- 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 Fri Aug 29 14:34:39 2008 From: geraldi.evenden at gmail.com (Gerald I. Evenden) Date: Fri Aug 29 14:34:46 2008 Subject: [Proj] A tangential aside Message-ID: <200808291434.39331.geraldi.evenden@gmail.com> I knew that using tan(x) as a function example would likely agitate the ivory tower math types but I suspect most of us down and dirty applied programmers treat it as a simple function and avoid tan's nasty behavior near |pi/2| by having tolerance tests of the argument and thus seek an alternate program route if there is going to be a problem. You will find many of these tests within the libproj4 library code and a whole section of added functions that provide argument range testing before calling transcendental functions entries with the sole purpose of providing a known course of action before a funky operation occurs. Some of these test date back to the GCTP days in the '60s. As pointed out, some cpu's provide enhanced status indicators as to what happened during a function evaluation; but relying upon this feature compromises machine independent code. -- 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 strebe at aol.com Fri Aug 29 16:31:58 2008 From: strebe at aol.com (strebe) Date: Fri Aug 29 16:32:12 2008 Subject: [Proj] Re: Global Gauss-Kruger and libproj4---the final story In-Reply-To: <200808291057.49121.geraldi.evenden@gmail.com> Message-ID: <49EDD80E.BC52.4416.89F7.742F65C12407@aol.com> Timeline: 28 August 2008 05:04:53 PM:?Strebe has stated that a function has one value for a single input.?Evenden's premise: tan(x) has two values at 90?. Evenden's conclusion: Strebe must therefore believe tangent is not a function. 28 August 2008 10:23:31 PM: Strebe explains that tan(x) does not have two values at x=90?. This destroys Evenden's premise and therefore his conclusion. 29 August 2009 07:57:48 AM: Either unwilling to acknowledge that his conclusion about Strebe is false, or incapable of following his own chain of reasoning, Evenden pretends instead that Strebe has demonstrated that tangent is a function, and ridicules that, evidently as insignificant. Mr. Evenden, mocking someone else for your own fallacies makes for an amusing read, but I doubt it furthers the purpose of the list. You abandon the original premises, substituting new ones, in every single chain of (un)reasoning recorded below. I ought to have left the conversation when I said I would. I apologize to the list for encouraging this epic nonsense. Regards, -- daan Strebe On Thursday 28 August 2008 10:23:31 pm strebe wrote: > On Aug 28, 2008, at 5:04:53 PM, "Gerald I. Evenden" > wrote: >> Let's see. tan(x) has two values at x=90 >> degrees: +inf and -inf. So it is no longer a function, eh? >> Infinity is not a value. Your conception and definitions are not >> mathematical. >> >> Tangent is undefined at an abscissa of 90??180?, with the >> ordinate?increasing?asymptotically as the abscissa approaches 90??180? from >> lesser values, and with the ordinate decreasing asymptotically as the >> abscissa approaches 90??180? from greater values. I will not respond to any >> argument over this, since it is basic mathematics, available anywhere. Any >> mathematician would disagree with your characterization. Infinity as a >> value is a convenient fiction, but it does not always work, and it does not >> bear on the question of whether tangent is a function or not. I can't find >> any such distinction for the definition of a "function." Please give >> reference. >> See, for example,? >> >> http://mathworld.wolfram.com/MultivaluedFunction.html > >LOL. It is still a function. So? On Aug 29, 2008, at 7:57:48 AM, "Gerald I. Evenden" wrote: From: "Gerald I. Evenden" Subject: Re: Global Gauss-Kruger and libproj4---the final story Date: August 29, 2008 7:57:48 AM PDT To: strebe Cc: proj@lists.maptools.org On Thursday 28 August 2008 10:23:31 pm strebe wrote: > On Aug 28, 2008, at 5:04:53 PM, "Gerald I. Evenden" > wrote: Let's see. tan(x) has two values at x=90 > degrees: +inf and -inf. So it is no longer a function, eh? > Infinity is not a value. Your conception and definitions are not > mathematical. > > Tangent is undefined at an abscissa of 90??180?, with the > ordinate?increasing?asymptotically as the abscissa approaches 90??180? from > lesser values, and with the ordinate decreasing asymptotically as the > abscissa approaches 90??180? from greater values. I will not respond to any > argument over this, since it is basic mathematics, available anywhere. Any > mathematician would disagree with your characterization. Infinity as a > value is a convenient fiction, but it does not always work, and it does not > bear on the question of whether tangent is a function or not. I can't find > any such distinction for the definition of a "function." Please give > reference. > See, for example,? > > http://mathworld.wolfram.com/MultivaluedFunction.html LOL. It is still a function. So? > A bazillion other Web pages will do, easily searched for. > Even if your questionable definition were true, it merely verifies that? > proj_fwd() is a function because it only returns one value. It is defined? > that way in the documentation. > You have, yet again, confused yourself about the who is arguing what. Yes. > You treat projections as functions. That's clear. That's always been clear. > That's THE problem. It only seems to be only a problem with you. I have not had anyone else bitch? and moan about it. > You have decided it's not YOUR problem, so now it's? > your clients' problem. That doesn't make the problem go away. It just > changes who it's a problem for.??I have specifically acknowledged multiple > times that you have chosen, for your convenience, to ignore the multivalued > results of projection formul? in order to treat projections as functions. > Why are you crowing? Why do you insist on getting insulting. I merely define a condition. Is? it "crowing" about it??? > about this evidence of proj_fwd() being a function when? > its functional nature is exactly why we're even having this conversation? > In terms of interruptions applying to all projections I presume you are > referring to the del-lon=180 condition. In many projection software this is > not a break and the map merely repeats on in the x direction. > That is impossible for almost all projections that are not cylindric or > pseudocylindric. It's merely a convenient evasion of responsibility that LOL again. > works for two common classes of projections. Meanwhile it can't work for > most projections because most projections depend on trigonometric (and > therefore periodic) manipulations of longitude, resulting in extended > longitudinal ranges wrapping back onto themselves ? resulting, even, on > 180?E mapping onto 180?W. As far as I am > aware it is always the graphic programmers job to handle this condition > and? not the projection routine: when at the map edge recall the function > with the sign of the lon term reversed. > As far as "recall the function with the sign of the lon term reversed" > goes, see the prior comment. Hey sweet cheeks. Since you hate libproj4 so much why do you even bother? sticking around here. I guess it is for the datum issues which I do not? involve myself with. > This was never about whose job it is. You're free to decide what's your job > and what isn't. Rather, it's a matter of what has to happen regardless of > who does what in order to get the job done.? I have defined where libproj4 begins and ends long ago. So? If you do not? like it go somewhere else rather than pursue these windmills. > You have declared with much sophistry that somehow the ellipsoidal > transverse Mercator can't be accommodated in libproj4 because of the cusps. > That's nonsense. There is nothing unique to that projection from libproj4's > perspective. Since you have put the onus of interruptions and odd > boundaries on the client, Because, by definition, that's where it is placed. Again, if you have never? liked the conditions of the program why do you stick around and persist with? character assassinations on graphical issues that other user are most likely? aware of? > then the same would be true in the case of the? > ellipsoidal transverse Mercator. Meanwhile libproj4 could happily provide > one result of the multivalued formul? along the cusp, just as it does for > every projection. BTW: you are the first person I have ever heard that > refers to the wrap-around condition of longitude as an interruption if, > indeed, that is what you are referring to. > That is what I am referring to. It is an interruption by any rational > analysis. I don't care if you call it a phlabbergompkin to distinguish it > from what you call an interruption (which you would never be able to > provide a definition for that's not arbitrary). It's exactly the same > thing, and what you seem to think of as an "uninterrupted" map is > undeniably interrupted. It's not important what it's called. It's important > what it does. What it does is separate points on the map that are adjacent > on the globe. If there are other examples, other than projections commonly > recognized as interrupted (for example Goode) *please* name them. > *Berghaus star > *Peirce quincuncial > *Waterman > *Fuller dymaxion > *Cahill butterfly > *Guyou > *Raizs armadillo > *two-point equidistant > *vertical perspective > *general perspective > *all of the dozens of polyhedral projections described in the literature > *any projection in oblique aspect (which you handle with something of a > hack, it appears) As I have said many times, libproj4 does not handle cartoon projections like? Berghaus star. Among some of the above I presume that you may be referring? to visibility cutoffs such as in the perspectives and libproj4 indicates? these by returning unprojectable condition. Several have odd boundaries? which libproj4 handles properly by also returning unprojectable status for a? point outside the visible or plottable boundary. With the comment about the oblique procedure you are also insulting the late? John Snyder as I merely implemented his formulae. Which is true with several? of the other projections as I relied upon his formulae for conditions of? visibility---the results are reflected in the return condition of the? libproj4 *function*. > Since whatever definition you use for "interruption" appears to be > arbitrary, and I have no access to your arbitrary definition, I cannot > guarantee that you'll agree that all the projections in that list are > "interrupted" by your definition but are not "commonly recognized" as > interrupted. My goodness, how you like to convolute an argument. It has long been? recognized by me that we *do not* have a common definition for "interrupted"? projection. But you like to persist in exploring this issue in an attempt to? support you claims and issues. As another example, you appear to term the "invisibility" of a point in a? projection like near-sided perspective as a interuption or at least the line? where visibility does or does not occur (the "limb"). For libproj4 the issue? is *only* where a point is visible or not---nor is the boundary of visibility? an interruption. *Please* remember that libproj4 very easily tells the user? about the visibility of the point. There is nothing else to be said. If you do not like it, fine. Go someplace? else. I have been perfectly transparent and hopefully clear as to what? libproj4 provides and have not hidden anything. > That's not my problem, and I will not argue over the list or? > its meaning. I chose projections whose natural boundaries do not follow the > common cylindric or azimuthal bounding parallels and meridians. The list is > hardly exhaustive. The number of projections is beyond estimation. libproj4 only scratches the? surface with about 170 entry points, some of which create other "named"? projections with appropriate options. My efforts are limited to what? descriptions are available and even here I have not included some because of? some unique property or condition of the projection. The lastest victim? being the world extent TM. > Perhaps you'll claim those are all cartoon projections, or nobody uses > them, or whatever else. I don't care. Not my problem. It's a reasonable > policy for you to limit your software to handle 95% of the needs and blow > off the rest. It's not reasonable for you to claim your reasons are founded > on some natural property of map projections. They're not. Two states are apparent either I failed to give a clear description of the? original problem or you do not have the mental capability to understand it. All this subsequent BS has had little to do with my original issue. > My point has only? > ever been that you're rationalizing your decision not to support the > ellipsoidal transverse Mercator with fallacious arguments, and I do not > wish for the (doubtless rapidly fading) audience to be confused by such > remarks. I realize that this is merely a lover's quarrel and certainly will not be our? last. Of course, I will make the obligatory counter claim about your? irrational arguments and ridiculous conditions.? > > Regards, > -- daan Strebe Goodnight sweetheart. Don't let the bedbugs bite. ... --? 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.maptools.org/pipermail/proj/attachments/20080829/c425194c/attachment-0001.html From Chris.Barker at noaa.gov Fri Aug 29 17:25:04 2008 From: Chris.Barker at noaa.gov (Christopher Barker) Date: Fri Aug 29 17:25:07 2008 Subject: [Proj] Re: Global Gauss-Kruger and libproj4---the final story In-Reply-To: <49EDD80E.BC52.4416.89F7.742F65C12407@aol.com> References: <49EDD80E.BC52.4416.89F7.742F65C12407@aol.com> Message-ID: <48B86930.6050004@noaa.gov> strebe wrote: > > Timeline: You've got to be kidding! It's clear to me that you both understand the issues at hand, only really disagree on how best a projection library should address them. Why in the world are you arguing all these symantics? You both are being big babies here -- please stop! -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov From strebe at aol.com Fri Aug 29 17:57:24 2008 From: strebe at aol.com (strebe) Date: Fri Aug 29 17:57:37 2008 Subject: [Proj] Re: Global Gauss-Kruger and libproj4---the final story In-Reply-To: <48B86930.6050004@noaa.gov> Message-ID: <2A91BD7E.39D1.436B.BF7C.052A536C154C@aol.com> I have no quarrel with how libproj4 addresses the problems of projection. Nothing prevents anyone from writing a wrapper that moves any remaining burdens away from the client while still keeping them separate from libproj4's responsibilities. The dispute was in the existence and nature of those burdens, not whether libproj4 is "deficient".?Libproj4 is a valuable product as it stands. Again, I apologize for the unseemly exchange. It probably was not relevant to most users of libproj4. If anyone wants to discuss boundary problems they are grappling with, feel free to contact me privately. Regards, -- daan Stree On Aug 29, 2008, at 2:25:04 PM, "Christopher Barker" wrote: From: "Christopher Barker" Subject: Re: [Proj] Re: Global Gauss-Kruger and libproj4---the final story Date: August 29, 2008 2:25:04 PM PDT To: "PROJ.4 and general Projections Discussions" strebe wrote: > > Timeline: You've got to be kidding! It's clear to me that you both understand the issues at hand, only really disagree on how best a projection library should address them. Why in the world are you arguing all these symantics? You both are being big babies here -- please stop! -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov _______________________________________________ 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/20080829/3cce0dd6/attachment.html From geraldi.evenden at gmail.com Fri Aug 29 17:59:41 2008 From: geraldi.evenden at gmail.com (Gerald I. Evenden) Date: Fri Aug 29 17:59:48 2008 Subject: [Proj] Re: Global Gauss-Kruger and libproj4---the final story In-Reply-To: <48B86930.6050004@noaa.gov> References: <49EDD80E.BC52.4416.89F7.742F65C12407@aol.com> <48B86930.6050004@noaa.gov> Message-ID: <200808291759.41638.geraldi.evenden@gmail.com> On Friday 29 August 2008 5:25:04 pm Christopher Barker wrote: > strebe wrote: > > Timeline: > > You've got to be kidding! > > It's clear to me that you both understand the issues at hand, only > really disagree on how best a projection library should address them. > > Why in the world are you arguing all these symantics? > > You both are being big babies here -- please stop! > > -Chris You are absolutely right. I'm taking my teddy bear and blanket and going to my special corner. So there! -- 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