The following messages are legitimate and usually represent some sort of update in the definitions to newer information; in several cases an EPSG deprecation has been made. *Datum transformation method on datum named Beijing1954 does not match. Method was 25, is now 3 According to EPSG, this definition should be a Position Vector with additional parameters of (0,0,0.814,-0.38) Operation Code is 15920, Variant is (3). This is a legitimate message :>) *Datum transformation method on datum named Amersfoort does not match. Method was 1, is now 3 There is no definition in EPSG which matches this one. That doesn't mean that it's wrong, just that there are better ones in EPSG. Suggest we should be using Operation Code 1672, Variant (2). This is a legitimate message :>) *Datum transformation method on datum named TM1965 does not match. Method was 25, is now 3 CS-MAP definition deprecated in 2003. Should use Coordinate Operation Code 1641, Variant (1) which is a position vector definition. This is a legitimate message :>) *Datum transformation method on datum named ST84IleDesPins does not match. Method was 9, is now 25 EPSG deprecated this definition in 6.11 and replaced it with coordinate op code 15848. This is a legitimate message :>) *Datum transformation method on datum named NEA74Noumea does not match. Method was 9, is now 25 EPSG deprecated this definition in 6.11 and replaced it with coordinate operation 15904. This is a legitimate message :>) The following represent errors introduced into the dictionaries as a result of the confusion between the Position Vector method and the Coordinate Frame method. The difference between the two is the sign of the three rotation angles. For many definitions, the fact that a definition referenced the Coordinate Frame method was overlooked and the definition parameters entered into the database as published, when in actuality the signs of the rotation angles needed to be flipped. (CS-MAP has not, in the past, supported the Coordinate Frame method directly.) Thus, for these definitions, either the sign of the rotations should be flipped, or the method changed to Coordinate Frame (which is now supported ala CS-MAP RFC #2). In any case, all of these messages are legitimate. *'Pulkovo42/83' differs from EPSG 'Pulkovo 1942(83)' [6178:1675 (1 of 3)]: Pulkovo42/83: X Rotation was -0.020, is now 0.020 *'HD72-7P-CORR' differs from EPSG 'Hungarian Datum 1972' [6237:1448 (3 of 4)]: HD72-7P-CORR: X Rotation was 0.370, is now -0.370 *'DHDN' differs from EPSG 'Deutsches Hauptdreiecksnetz' [6314:1673 (1 of 4)]: DHDN: X Rotation was -1.040, is now 1.040 Consider updating to Coordinate Operation code 1777 *'RT90-3-7P' differs from EPSG 'Rikets koordinatsystem 1990' [6124:1680 (1 of 2)]: RT90-3-7P: Delta X was 414.100, is now 419.384 This message is legitimate, but rather misleading as the real problem here is the coordinate frame problem. The EPSG comparator got the wrong variant, thus the messgae is misleading. It should be comparing with Coordinate Operation code 1896 rather than 1680. We need to flip the signs of the rotations, or change the method to Coordinate Frame. *'Czech/JTSK' differs from EPSG 'Jednotne Trigonometricke Site Katastralni' [6156:1623 (1 of 3)]: Czech/JTSK: Delta X was 570.693, is now 570.800 This definition did not come from EPSG originally; it came from a Czech source. However, in copmparing with EPSG, it appears to have the Coordinate Frame sign reversal problem. It is entirely likely that this definition was extracted from a document written in Czech and the sense of the rotations missed due to the language barrier. Americans and Australians like to use the Position Vector sense of rotations, but Europeans like to use the Coordinate Frame sense of rotations. Thus, the Czech source may have assumed that the reader would know the proper sense of the rotation direction. In nay case, I suggest that this definition be revised to match EPSG Coordinate Operation code 5239 (Variant 5). Looks like the following were considered Coordinate Frame when they were Position Vector. Surely these defects resulted from the coordinate frame confusion, but in these cases the signed got flipped when they didn't need to be flipped. I must have been very very confused that day. Nevertheless, all of these messages are legitimate. *'PDOSurvey93' differs from EPSG 'PDO Survey Datum 1993' [6134:1439 (1 of 3)]: PDOSurvey93: X Rotation was 0.810, is now -0.810 *'Pulkovo42/58' differs from EPSG 'Pulkovo 1942(58)' [6179:1645 (1 of 6)]: Pulkovo42/58: X Rotation was 0.359, is now -0.359 *'Luxembourg30' differs from EPSG 'Luxembourg 1930' [6181:1643 (1 of 2)]: Luxembourg30: X Rotation was 0.410, is now -0.410 *'HitoXVIII63' differs from EPSG 'Hito XVIII 1963' [6254:1529 (1 of 2)]: HitoXVIII63: X Rotation was -0.056, is now 0.056 *'NGO48' differs from EPSG 'NGO 1948' [6273:1654 (1 of 1)]: NGO48: X Rotation was -7.889, is now 7.889 *'HongKong80' differs from EPSG 'Hong Kong 1980' [6611:1825 (1 of 1)]: HongKong80: X Rotation was -0.068, is now 0.068 *'QatarNtl95' differs from EPSG 'Qatar National Datum 1995' [6614:1840 (1 of 1)]: QatarNtl95: X Rotation was -1.164, is now 1.164 *'ST71Belep' differs from EPSG 'ST71 Belep' [6643:1931 (1 of 1)]: ST71Belep: X Rotation was -16.312, is now 16.312 *'Scoresbysund52' differs from EPSG 'Scoresbysund 1952' [6195:1799 (1 of 1)]: Scoresbysund52: Z Rotation was -0.814, is now 0.814 *'Ammassalik58' differs from EPSG 'Ammassalik 1958' [6196:1800 (1 of 1)]: Ammassalik58: Z Rotation was -0.814, is now 0.814 *'WGS72-TBE' differs from EPSG 'WGS 72 Transit Broadcast Ephemeris' [6324:1240 (1 of 1)]: WGS72-TBE: Z Rotation was -0.814, is now 0.814 The following messages are legitimate, the reason vary as indicated: *'NAPARIMA' differs from EPSG 'Naparima 1955' [6158:1556 (3 of 2)]: NAPARIMA: Delta X was -10.000, is now -2.000 This is a NameMapper problem. CS-MAP definition named NAPARIMA-O should be the target for this datum mapping, not NAPARIMA. In the CS-MAP dictionary, there are several Napatima definitions which call themselves 1972, of which only one is correct. In any case, to fix this bust, we need to twiddle the NameMapper. *'Lisbon37' differs from EPSG 'Lisbon 1937' [6207:1656 (1 of 3)]: Lisbon37: Delta X was -282.100, is now -280.900 This message is legitimate. The CS-MAP definition named "Lisbon37" appears to be a definition of Lisbon 1937 to ETRF89 with the sign of the rotations flipped. Anyway, the definition does not match EPSG and needs to be fixed. Suggest that it be updated to jive with EPSG Operation Code 1988. *'DeirEzZor_1' differs from EPSG 'Deir ez Zor' [6227:15741 (2 of 6)]: DeirEzZor_1: Delta X was -177.500, is now -187.500 This definition was deprecated by EPSG and replaced with a new definition. We need to do the same; new EPSG Coordinate Op Code is 15741. *'ERP50-7P' differs from EPSG 'European Datum 1950' [6230:1311 (18 of 41)]: ERP50-7P: Delta X was -102.000, is now -89.500 The CS-MAP definition came from NIMA and does not match any of the 42 variants in EPSG. So this message is legitimate, but I don't know that we need to change any definitions, since this one is probably as good as any of the 42 that EPSG has. *'Datum73-MOD' differs from EPSG 'Datum 73' [6274:1658 (1 of 3)]: Datum73-MOD: Delta X was -231.000, is now -238.200 The CS-MAP definition appears to be a correct rendition of an EPSG definition which has been deprecated with the rotation signs erroneously flipped (Op Code: 1945). Need to replace the guts of this definition with the parameters of Op Code 1987. *'SAPPER' differs from EPSG 'Sapper Hill 1943' [6292:1225 (1 of 1)]: SAPPER: Delta Y was 16.000, is now 21.000 I'm going to call this a NameMapping error. The SAPPER definition is probably exactly what it says it is (i.e. a definition generated by DMA in 1983), but there is another definition, SAPPER-97 which matches EPSG, two other sources. So lets justmap this EPSG code to the SAPPER-97 definition and I think this message should go away. *'Timbalai' differs from EPSG 'Timbalai 1948' [6298:1228 (1 of 4)]: TIMBALAI: Delta X was -689.000, is now -679.000 We have three CS-MAP definitions from three different sources. If we map this EPSG code to TMBLI-B, I think this message goes away. There does not appear to be any problems with the definitions as they are all rather similar. *'Belge72' differs from EPSG 'Reseau National Belge 1972' [6313:1609 (1 of 3)]: Belge72: Scale was 0.99999900, is now -1.00000000 This is a bust in the scale paramater. The actual scale value is given in the CS-MAP definition, but the definition requires scale in parts per million difference from unit. Thus the parameter certainly should be -1.0 as the Test program has diagnosed. *'Guyane95' differs from EPSG 'Reseau Geodesique Francais Guyane 1995' [6624:4840 (2 of 1)]: Guyane95: Delta X was 2.000, is now 0.000 This definition was deprecated by EPSG 7.5, we need to do the same. Should emulate Coordinate Operation 4840 as indicated in the message. *'MOP1978' differs from EPSG 'MOP78' [6639:15847 (2 of 1)]: MOP1978: Delta X was 252.000, is now 253.000 This definition was deprecated by EPSG 6.9, we need to do the same. Should emulate Coordinate Operation 15847 as indicated in the message.