You can subscribe to this list here.
2001 
_{Jan}

_{Feb}

_{Mar}

_{Apr}

_{May}

_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}
(8) 
_{Dec}
(36) 

2002 
_{Jan}
(116) 
_{Feb}
(68) 
_{Mar}
(88) 
_{Apr}
(135) 
_{May}
(116) 
_{Jun}
(66) 
_{Jul}
(86) 
_{Aug}
(70) 
_{Sep}
(76) 
_{Oct}
(64) 
_{Nov}
(106) 
_{Dec}
(90) 
2003 
_{Jan}
(131) 
_{Feb}
(329) 
_{Mar}
(264) 
_{Apr}
(176) 
_{May}
(252) 
_{Jun}
(128) 
_{Jul}
(301) 
_{Aug}
(208) 
_{Sep}
(221) 
_{Oct}
(223) 
_{Nov}
(237) 
_{Dec}
(152) 
2004 
_{Jan}
(135) 
_{Feb}
(217) 
_{Mar}
(167) 
_{Apr}
(248) 
_{May}
(508) 
_{Jun}
(327) 
_{Jul}
(341) 
_{Aug}
(263) 
_{Sep}
(256) 
_{Oct}
(299) 
_{Nov}
(179) 
_{Dec}
(155) 
2005 
_{Jan}
(157) 
_{Feb}
(405) 
_{Mar}
(379) 
_{Apr}
(491) 
_{May}
(664) 
_{Jun}
(519) 
_{Jul}
(382) 
_{Aug}
(400) 
_{Sep}
(403) 
_{Oct}
(447) 
_{Nov}
(334) 
_{Dec}
(251) 
2006 
_{Jan}
(279) 
_{Feb}
(198) 
_{Mar}
(445) 
_{Apr}
(330) 
_{May}
(379) 
_{Jun}
(310) 
_{Jul}
(447) 
_{Aug}
(581) 
_{Sep}
(277) 
_{Oct}
(647) 
_{Nov}
(661) 
_{Dec}
(656) 
2007 
_{Jan}
(393) 
_{Feb}
(603) 
_{Mar}
(568) 
_{Apr}
(416) 
_{May}
(411) 
_{Jun}
(605) 
_{Jul}
(595) 
_{Aug}
(380) 
_{Sep}
(350) 
_{Oct}
(285) 
_{Nov}
(342) 
_{Dec}
(327) 
2008 
_{Jan}
(479) 
_{Feb}
(489) 
_{Mar}
(274) 
_{Apr}
(465) 
_{May}
(591) 
_{Jun}
(491) 
_{Jul}
(482) 
_{Aug}
(305) 
_{Sep}
(256) 
_{Oct}
(307) 
_{Nov}
(313) 
_{Dec}
(323) 
2009 
_{Jan}
(340) 
_{Feb}
(408) 
_{Mar}
(515) 
_{Apr}
(291) 
_{May}
(582) 
_{Jun}
(388) 
_{Jul}
(421) 
_{Aug}
(233) 
_{Sep}
(337) 
_{Oct}
(269) 
_{Nov}
(308) 
_{Dec}
(197) 
2010 
_{Jan}
(128) 
_{Feb}
(149) 
_{Mar}
(411) 
_{Apr}
(315) 
_{May}
(567) 
_{Jun}
(477) 
_{Jul}
(370) 
_{Aug}
(174) 
_{Sep}
(160) 
_{Oct}
(205) 
_{Nov}
(147) 
_{Dec}
(174) 
2011 
_{Jan}
(296) 
_{Feb}
(225) 
_{Mar}
(255) 
_{Apr}
(486) 
_{May}
(684) 
_{Jun}
(372) 
_{Jul}
(253) 
_{Aug}
(271) 
_{Sep}
(173) 
_{Oct}
(311) 
_{Nov}
(187) 
_{Dec}
(114) 
2012 
_{Jan}
(135) 
_{Feb}
(70) 
_{Mar}
(120) 
_{Apr}
(100) 
_{May}
(321) 
_{Jun}
(250) 
_{Jul}
(250) 
_{Aug}
(328) 
_{Sep}
(198) 
_{Oct}
(237) 
_{Nov}
(234) 
_{Dec}
(208) 
2013 
_{Jan}
(190) 
_{Feb}
(143) 
_{Mar}
(138) 
_{Apr}
(125) 
_{May}
(181) 
_{Jun}
(213) 
_{Jul}
(289) 
_{Aug}
(173) 
_{Sep}
(92) 
_{Oct}
(121) 
_{Nov}
(114) 
_{Dec}
(76) 
2014 
_{Jan}
(134) 
_{Feb}
(185) 
_{Mar}
(190) 
_{Apr}
(211) 
_{May}
(177) 
_{Jun}
(143) 
_{Jul}
(60) 
_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 





1
(12) 
2
(5) 
3
(1) 
4
(2) 
5
(4) 
6
(5) 
7
(26) 
8
(21) 
9
(6) 
10
(7) 
11
(9) 
12
(14) 
13
(8) 
14
(14) 
15
(7) 
16
(4) 
17
(6) 
18
(1) 
19
(5) 
20
(5) 
21
(10) 
22
(14) 
23
(12) 
24
(3) 
25
(6) 
26
(6) 
27
(8) 
28
(9) 
29
(4) 
30
(14) 

From: Rueben Schulz <r_j_schulz@ya...>  20040404 22:54:28

Hi, As seen in the "Reprojection Question" emails, cts is using approximate equations for the transverse mercator projection (please see my discussion about the equations there). This may or may not be causing some problems. Since this is a very important projection, I think it would be good to discuss this. Question 1: how important is it to have accurate values greater than 6 degrees from the central meridian of the projection (outside of a utm zone). Question 2: does anyone know a good reference for these equations? Specifically I am looking for something that discusses the exact equations and different approximations. Reference that I know about are: Snyder "Map projections: a working manual"  gives approximation Proj4  approximation "The universal grids: utm and ups" from the US Defense mapping agency (DMA)  still approximations, but has many more terms and will be more accurate. Army 1973 and 1962  references by Snyder that I have not yet been able to look up. He says these give more terms and are good to mm accuracy at 24 deg longitude from the central meridian. Question 3: all of these equations use series approximations (the more accurate ones use more terms in the series). My math background does not include spherical trig. so I am not exactly sure what they are approximating. Does anyone have a good reference for this (or a quick explanation)? For my own thoughts, my primary concern is that the equations and errors are documented well. It appears that anything we do here will be an approximation. I am thinking about implementing the DMA equations (used by jump). This would take me about 2 weekends, probably more for proper testing (having the jump implementation helps, but it is gpl and cannot be used directly). I will not have any time to work on this until my exams and papers are finished (april 20). Before I do any work, I would like a better understanding of this issue. I will probably see how the jump equations compare to the spherical case in cts first (see how much the approximations differ as you move away from the central meridian). Looking up some more references about this would also be useful. Also note that the more accurate equations will be slower (I will not knot the exact about until they are implemented). Thank you for any help/input, Rueben 
From: Rueben Schulz <r_j_schulz@ya...>  20040404 22:51:36

To everyone, Thank you for promptly getting together the answers to my questions. Unfortunately I have not been able to account for all of the differences seen. There are definitely some differences caused by the approximations used in cts, but if my guesses are correct (below) this is not enough to account for 200,000 ha. First a bit about the equations. CTS uses the equations from proj4, which are approximations. These approximations have about 2.0m error in the forward (geog to planar) projection at 20 degrees from the central meridian and get steadily worse past that. They are fine when working within a utm zone. The jump code implements the equations in "The universal grids: utm and ups" (available from http://earthinfo.nga.mil/GandG/index.html, publications). According to this document the equations are good to 0.01 m for planar and 0.001 arc seconds for geog coordinates (does not mention if this varies as you move away from the central meridian). The equations given in Snyder ("map projections: a working manual") are also approximations and are different from those given by the us military and proj4. He mentions that these are good to 0.01m for the forward projection at 7 deg from the central meridian (worse for the inverse). Snyder also references some authors who give more accurate equations with more terms. Note. It would be nice if the jump code referenced the above document. I got lucky when searching for it yesterday (mental note, do all the cts proj's reference the proper documents?). Now for some guesses and rough calculations (please tell me if these are wrong). The image is 354*469 pixels. 341142 of these pixels represent vancouver island (according to a conversion to arcinfo grid). The crs for the image is utm zone 11N, wgs84 (based on the info in previous emails. Note that the image did not include a world file (*.pngw), so I was only looking at it in pixel space on friday). Based on the 3,167,985.5 ha value for the island, each cell is about 92.8 ha (960m *960 m square). The 200,000 ha difference between calculations means that there is about 6.2 ha difference per grid cell (this is a lot). The attached java code does a few comparisons between the results of the inverse projections for points on the bounding box and an area calculation. The output from the tests is below with some comments. I have also included output from arcinfo for these points (these are also different from the values given by cts and jump (would be nice if they referenced which equations they used, or let me read their code...)). >From this test, there is up to a 19m difference between points calculated for the west side of the dataset. This is because the central meridian is at 117 deg (utm zone 11) and the north west corner of the island is at 128 deg long. This is caused by the approximations used. However note that the areas calculated for a grid cell (I think I used the same technique you guys did) in the north west corner are close to being the same. This is because while cts is underestimating the proper latitude (assuming jump is correct), it is doing this for both the top and bottom points in the grid cell). So to wrap up my findings, I am not sure what is causing all of the difference in the areas. One possibility is that my guesses above are wrong (hopefully this is the case). Another possibility is that the differences are caused in the calculations you guys did (was the image accessed the same way between calculations, was distance on a sphere calculated the same way, was cts used correctly, etc). I cannot tell this without looking at your code as I am still a bit unsure about the exact calculations that you did. Hopefully the above discussion will help you to track this down. Please let me know if the above is helpful or wrong. Rueben //output from vanIslandTest.java with some comments setting up jump proj UTM 11N / WGS 84 sourceCS: PROJCS["WGS_1984_UTM_Zone_11N", GEOGCS["GCS_WGS_1984", DATUM["D_WGS_1984", SPHEROID["WGS_1984", 6378137.0, 298.257223563]], PRIMEM["Greenwich", 0.0], UNIT["degree of angle",0.017453292519943295], AXIS["Longitude",EAST], AXIS["Latitude",NORTH]], PROJECTION["Transverse_Mercator"], PARAMETER["semi_major", 6378137.0], PARAMETER["semi_minor", 6356752.314245179], PARAMETER["central_meridian", 117.0], PARAMETER["latitude_of_origin", 0.0], PARAMETER["scale_factor", 0.9996], PARAMETER["false_easting", 500000.0], PARAMETER["false_northing", 0.0], UNIT["metre",1.0], AXIS["x",EAST], AXIS["y",NORTH]] targetCS: GEOGCS["WGS84", DATUM["WGS84", SPHEROID["WGS84", 6378137.0, 298.257223563]], PRIMEM["Greenwich", 0.0], UNIT["degree of angle",0.017453292519943295], AXIS["Longitude",EAST], AXIS["Latitude",NORTH]] cts transform: INVERSE_MT[PARAM_MT["Transverse_Mercator", PARAMETER["semi_major",6378137.0], PARAMETER["semi_minor",6356752.314245179], PARAMETER["central_meridian",117.0], PARAMETER["latitude_of_origin",0.0], PARAMETER["scale_factor",0.9996], PARAMETER["false_easting",500000.0], PARAMETER["false_northing",0.0]]] //this tests a point on the central meridian //(no difference between implementations; as expected) test point: (500000.0, 5400000.0) jump out: 48.75301299906651, 117.0 cts out: CoordinatePoint[117.0, 48.75301300431135] diff: 5.832516103410899E4 x diff: 3.535402482206358E10 y diff: 5.832516103410899E4 //the lower left corner //arcinfo value (128.51772815, 47.83430193) test point: (361310.8, 5362466.5) jump out: 47.83442853079063, 128.5176656058043 cts out: CoordinatePoint[128.51766560641096, 47.834304709849825] diff: 13.76729130064849 x diff: 4.534895621020055E5 y diff: 13.767291300573802 //upper left //arcinfo value (129.25371466, 50.84542943) test point: (361310.8, 5704551.7) jump out: 50.84560558126784, 129.2536076781215 cts out: CoordinatePoint[129.2536076792191, 50.84543403765599] diff: 19.08342352078021 x diff: 7.720052056307932E5 y diff: 19.083423520624056 //upper right //arcinfo value (122.85720865, 51.34552102) test point: (92218.7, 5704551.7) jump out: 51.345522964253234, 122.85720807725518 cts out: CoordinatePoint[122.85720807816185, 51.345521039085384] diff: 0.21418433655942234 x diff: 6.309054644685014E5 y diff: 0.21418432726738626 //lower right //arcinfo value (122.49774620, 48.28377696) test point: (92218.7, 5362466.5) jump out: 48.2837783552065, 122.49774587083925 cts out: CoordinatePoint[122.49774587141744, 48.28377696575528] diff: 0.15450120212292104 x diff: 4.284539593253266E5 y diff: 0.15450119618210004 // area of 1000*1000 cell in the north west corner of the island Test Area calcs Jump width: 991.3396466847508 m Jump height: 991.3701400918343 m Jump area: 98.2784524412451 ha CTS width: 991.3562038147948 m CTS height: 991.3573555730368 m CTS area: 98.27882646447594 ha On Fri, 20040402 at 11:16, Jody Garnett wrote: > Thanks for the response, > > It is taking me some time to assemble the answers to your questsion  > the answers being spread across several people. > > Rueben Schulz wrote: > > >Unfortunately I do not think the following information is enough to > >track down the problem. Note that the transverse mercator equations used > >in geotools2 are an approximation and do not preform well when you start > >to get far away from your central meridian (anything over 6 degrees away > >starts to have issues, see > >http://geotools.sourceforge.net/gt2docs/api/org/geotools/ct/docfiles/Accuracy.html). > >Could you please provide the following (mostly more detail): > > > > How were the areas calculated (I assume jts was used in both cases) > > > > > Emily: Each pixel is divided into four points. Each of these four > points is > reprojected from the source projection to the destination projection > (lat long). A function is used that determines the distance between > two lat long coordinates on the sphere using the > ("WGS_1984",6378137,298.257223563) definition of the sphere. The > area is calculated by multiplying the height and width averaged. > > > What source projection was the data in (appears lat/long below) > > > > > Emily: > Source Projection: > 32611 > EPSG > PROJCS["WGS_1984_UTM_Zone_11N",GEOGCS["GCS_WGS_1984",DATUM["D_WGS_1984",SPHEROID["WGS_1984",6378137,298.257223563]],PRIMEM["Greenwich",0],UNIT["Degree",0.017453292519943295]],PROJECTION["Transverse_Mercator"],PARAMETER["False_Easting",500000],PARAMETER["False_Northing",0],PARAMETER["Central_Meridian",117],PARAMETER["Scale_Factor",0.9996],PARAMETER["Latitude_Of_Origin",0],UNIT["Meter",1]] > +proj=utm +zone=11 +ellps=WGS84 +datum=WGS84 +units=m > > > How was it reprojected with jump (I do not remember jump having > >transform support when I last looked at it (summer)) > > > > > I don't think it has it quite yet, my impresison is that support has > been added by a third party as a plugin. Sent the reprojection code > (GLP) to Rueben in a separate email (since I can't tell mathmatically > what they are doing from the comments). > > > what are the datasets involved (what vector data are you comparing to, > >what is the image (are you resampling the image?)) > > > > > Emily: It's a black and white picture of Vancouver Island. > Jody: I have attached the image for your reference > The image is bounded by: > > > boundingBox.setMinx( 361310.8 ); > > boundingBox.setMiny( 5704551.7 ); > > boundingBox.setMaxx( 92218.7 ); > > boundingBox.setMaxy( 5362466.5 ); > > > > where are the datasets located in relation to your central meridian > > > > > Jody: No one seemd to know this answer. > > > anything else important that I forgot in the above list > > > >Thank you, > >Rueben > > > > > > > >On Thu, 20040401 at 10:59, Jody Garnett wrote: > > > > > >>Hmm ... that stack trace is a little misleading: it lists the Geotools2 > >>wkt and Transform under the USING JUMP heading when it not actually > >>used there. > >> > >>Here is what it was acutal using: > >>PredefinedCoordinateSystems.UTM_11N_WGS_84  the code is hidden away off > >>in a GPL jar I don't have access to the src code at the moment. > >> > >>If this does represent a lack in Geotools2 I can hunt down the src if we > >>need it.. I wonder if my wkt for 32611 is correct. > >> > >>Thanks for posting the "bug" david, > >> > >>Jody > >> > >> > >>David Zwiers wrote: > >> > >> > >> > >>>Below are some results for computing the area using Geotools and Jump. > >>>In both cases the same project and image were used. Wondering what I > >>>am missing, as the JUMP reprojection is close (1% off) to the vector > >>>data, while the geotools reprojection is not. > >>> > >>>Many thanks, > >>> > >>>David > >>> > >>> Original Message  > >>> > >>>JUMP Results in 3167985.5 hectars area > >>>Geotools Results in 2955931.75 hectars area > >>> > >>> > >>>USING JUMP > >>> > >>>32611>PROJCS["WGS_1984_UTM_Zone_11N",GEOGCS["GCS_WGS_1984",DATUM["D_WGS_1984",SPHEROID["WGS_1984",6378137,298.257223563]],PRIMEM["Greenwich",0],UNIT["Degree",0.017453292519943295]],PROJECTION["Transverse_Mercator"],PARAMETER["False_Easting",500000],PARAMETER["False_Northing",0],PARAMETER["Central_Meridian",117],PARAMETER["Scale_Factor",0.9996],PARAMETER["Latitude_Of_Origin",0],UNIT["Meter",1]] > >>> > >>>testService32611 area calculated:1.5399122E7 > >>>testService32611 area :3167985.5 > >>> > >>>USING GEOTOOLS > >>> > >>>32611>PROJCS["WGS_1984_UTM_Zone_11N",GEOGCS["GCS_WGS_1984",DATUM["D_WGS_1984",SPHEROID["WGS_1984",6378137,298.257223563]],PRIMEM["Greenwich",0],UNIT["Degree",0.017453292519943295]],PROJECTION["Transverse_Mercator"],PARAMETER["False_Easting",500000],PARAMETER["False_Northing",0],PARAMETER["Central_Meridian",117],PARAMETER["Scale_Factor",0.9996],PARAMETER["Latitude_Of_Origin",0],UNIT["Meter",1]] > >>> > >>>Transform from LatLong to EPSG:32611:CONCAT_MT[PARAM_MT["Affine", > >>>PARAMETER["num_row",3], PARAMETER["num_col",3], > >>>PARAMETER["elt_0_0",0.0], PARAMETER["elt_0_1",1.0], > >>>PARAMETER["elt_1_0",1.0], PARAMETER["elt_1_1",0.0]], > >>>PARAM_MT["Transverse_Mercator", PARAMETER["semi_major",6378137.0], > >>>PARAMETER["semi_minor",6356752.314245179], > >>>PARAMETER["central_meridian",117.0], > >>>PARAMETER["latitude_of_origin",0.0], PARAMETER["scale_factor",0.9996], > >>>PARAMETER["false_easting",500000.0], PARAMETER["false_northing",0.0]]] > >>>Transform from EPSG:32611 to > >>>latLong:CONCAT_MT[INVERSE_MT[PARAM_MT["Transverse_Mercator", > >>>PARAMETER["semi_major",6378137.0], > >>>PARAMETER["semi_minor",6356752.314245179], > >>>PARAMETER["central_meridian",117.0], > >>>PARAMETER["latitude_of_origin",0.0], PARAMETER["scale_factor",0.9996], > >>>PARAMETER["false_easting",500000.0], > >>>PARAMETER["false_northing",0.0]]], PARAM_MT["Affine", > >>>PARAMETER["num_row",3], PARAMETER["num_col",3], > >>>PARAMETER["elt_0_0",0.0], PARAMETER["elt_0_1",1.0], > >>>PARAMETER["elt_1_0",1.0], PARAMETER["elt_1_1",0.0]]] > >>>GeoTools transformation on > >>>testService32611 area calculated:1.4384618E7 > >>>testService32611 area :2955931.75 