Hi André,
----- Mensagem original ----- > DE: André Joost >>> >>> The transformation table inside QGIS only has those tfm from the >>> EPSG database where the target CRS is 4326 (we want towgs84, >>> right?) >>> >>> So I suggest to set target CRS for all new portuguese CRS to 4326 >>> as well. >> >> >> Yes, I know Andre, in my proposal I put the transformations to 4326, >> except the transformations using NTv2 grids, since these have been >> prepared specifically for 4258, and do not use the "+towgs84" >> parameter, but "+nadgrids". What do you think? > > We need them to convert to WGS84. If Marco filters the EPSG list for > target=4326, he won't get them. > > In earlier years, WGS84 parameters were adopted from ETRS89 with a note > "assuming that WGS84 and ETSR89 are the same". They seem to have > dropped > that. > I've been doing some tests and, in the case of NTv2 grids, using target_crs_code 4258 vs 4326, the difference is ~0.104mm, which is compatible with the coord_op_scope (decimetre accuracy), don't you think? In this case, we can simply put 4326 as target_crs_code, right? Anyway, as Marco already inserted portuguese grids in srs.db, and the parameter used is +nadgrids, we don't need to put 4326 as grids target, because it is already in QGIS and the filter to the EPSG DB will prevent duplication. Different situation happens with Molodensky and Bursa-Wolf transformations. Apparently, the latest transformation parameters are being made available for 4258. Nevertheless, if we use 4258 as target_crs_code, the error we get is huge, maybe because it generate some conflict with +towgs84 parameter. So, simply changing the target_crs_code for 4326 (no further changes), it works ok. I did some tests with tfm 5037, and with this same tfm but with target_crs_code changed to 4326. The results were these: - Tmf 5037 (4274 -> 4258): more than 120m error! (this must be the problem with +towgs84) - Tmf changed, using exactly the same transformation parameters, but with target_crs_code 4326 (4274 -> 4326): error ~0.292m. The question is, inevitably we have to put these latest transformations "manually" in srs.db, right? Otherwise they will be filtered out, because the target_crs is not 4326. There is nothing we can do with EPSG, right? > >> >> >> The difference between them seems to me only the Prime Meridian, one >> is referenced to Greenwich and the other to Lisbon: > > The transformation for those is a 2-step-transformation: First move the > prime meridian from Lisbon to Greenwich, then do one of the > Lisbon-to-WGS84 transformations. So no new parameters here. > > >> >> I also do not know if this has any implications on the accuracy of >> the transformations, but which I find more strange is that all the >> transformations are set from 4207. Would, in the past, EPSG >> 20790/20791 were using Greenwich Prime Meridian, and this was updated >> recently? > But then, why are the transformations referring to 4207 when the reference systems use pm=lisbon (4803) (except the new 5018)? This leads to this problem http://hub.qgis.org/issues/9614. > > No, they still use pm=lisbon, but 20791 was replaced by 5018 using > Greenwich. The lon_0 moved from +1 to +lon_0=-8.131906111111112 > > The pm=lisbon is at -9.0754862. I wonder why that fits. > I've been watching this and I get it! The information in the EPSG DB v8.4 is in Degrees, Minutes and Seconds, and when I extracted it for the table, the data in DMS changed the format. The longitude of datum Lisbon 1937 is 9°07'54.862" W of Greenwich, which, transformed to Decimal Degrees, is -9.131906111111112. When I extracted that field to the table, it did not convert anything, simply changed from 9°07'54.862 to 9.0754862! :) Regarding the Datum Transformation window, whenever I want to convert something to 4258, through a transformation +towgs84, what is done is, again, a 2-step-transformation: 1) source_crs -> 4326 2) 4326 -> 4258. The problem is that there are now two transformations in srs.db 4326 -> 4258: tfm 1149 (+towgs84=0,0,0); and tmf 1571, that as you explained already, is a bug in the EPSG DB, and is generating a lot of confusion in the 2nd step of the transformation. I think all deprecated transformations should be dropped. Thank you very much! Best regards, Pedro _______________________________________________ Qgis-developer mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/qgis-developer
