[Therion] Calibration of co-ordinate systems
On 27/05/10 13:29, Martin Budaj wrote: > Hi, > > On Mon, May 17, 2010 at 11:17 PM, Andrew Atkinson > wrote: >> import Great_Swallet.3d -surveys use -filter great_swallet -cs EPSG:27700 >> -calibrate [0 0 0 299912 1 0] >> #Should be -calibrate [0 0 0 30 10 0] >> >> (goodness knows why the calibrate is not right, the bodge is to align it on >> goodle earth, probably my ignorance) > > Which therion version are you using? Recent versions include geodetic > datum shift parameter which should eliminate the 90-m difference. 5.28 on ubuntu. Wookey has said that he is trying to update the repository, so I am waiting to be the crash dummy.. But the datum shift would explain one of the jumps we got, however we still seem to get jumps (google earth), on the same version with no change to the cs, calibration (3d files) or the fixed points. This is something I do not understand. Generally all the entrances are off by the same amount, so I can go and adjust them, but it is tedious, especially when the jump a few months latter (possibly when google earth is updated?) Maybe this indicates a calibrate for cs when used as output will still be needed, even with the solution below, although in reality it should not be. > >> cs EPSG:27700 -calibrate [0 0 0 299912 1 0] >> >> gives error >> >> output coordinate system specification requires single parameter > > It is not possible to modify cs using 'calibrate' option. > > I guess your problem could be solved by defining custom Proj4 > coordinate system. For ST square it should be > > +proj=tmerc +lat_0=49 +lon_0=-2 +k=0.9996012717 +x_0=10 > +y_0=-20 +ellps=airy +datum=OSGB36 +units=m +no_defs > > Currently the 'cs' command doesn't accept custom Proj4 specifications > like the one given above (this funcionality will be added as soon as > possible), so the easiest way to add this projection is to modify > thcsdata.tcl and recompile therion. > > In thcsdata.tcl just duplicate line 52 (s-merc projection) and replace > 's-merc' with e.g. OSGBST and proj4 specification with the > specification given above. > > Then use cs OSGBST in your data. > Thanks Martin, sounds like another good solution. I think that I will wait for the ability to customise proj4. I have already been through an adjusted them by hand. Plus this is a project spread over lots of cavers and clubs (SVN is wonderful, most of the time!) and everyone having to compile from source would be a pain (I have to go round and install the software as it is...) thanks Andrew
[Therion] Calibration of co-ordinate systems
Hi, On Mon, May 17, 2010 at 11:17 PM, Andrew Atkinson wrote: > import Great_Swallet.3d -surveys use -filter great_swallet -cs EPSG:27700 > -calibrate [0 0 0 299912 1 0] > #Should be -calibrate [0 0 0 30 10 0] > > (goodness knows why the calibrate is not right, the bodge is to align it on > goodle earth, probably my ignorance) Which therion version are you using? Recent versions include geodetic datum shift parameter which should eliminate the 90-m difference. > cs EPSG:27700 -calibrate [0 0 0 299912 1 0] > > gives error > > output coordinate system specification requires single parameter It is not possible to modify cs using 'calibrate' option. I guess your problem could be solved by defining custom Proj4 coordinate system. For ST square it should be +proj=tmerc +lat_0=49 +lon_0=-2 +k=0.9996012717 +x_0=10 +y_0=-20 +ellps=airy +datum=OSGB36 +units=m +no_defs Currently the 'cs' command doesn't accept custom Proj4 specifications like the one given above (this funcionality will be added as soon as possible), so the easiest way to add this projection is to modify thcsdata.tcl and recompile therion. In thcsdata.tcl just duplicate line 52 (s-merc projection) and replace 's-merc' with e.g. OSGBST and proj4 specification with the specification given above. Then use cs OSGBST in your data. Martin
[Therion] Calibration of co-ordinate systems
I will try to explain a little more to help clarify. (we will ignore te uneven numbers for now to stick to one topic) In the OSGB it is typical to quote 10 figure grid references to fix a location to 1m EG 47130 56380 Strictly this identifies a location within a 100km square the is referred to with a 2 letter code so the above should be ST 47130 56380 However, it is common to miss out the ST if it is clear what area you are talking about, ie a Mendip cave. Now these 10 figure grid references are fine for putting systems together, however to get a kml output, in the right place, I need to add 30 1 which I can do, but makes the files a bit confusing to people that do not understand co-ordinate systems. (And I am trying to get lots of people to be able to contribute to the area map, so simplicity is important) Now when importing a 3d file it is possible to use calibrate option to add the 30 10 but I cannot find a way to do this to all the th files I have, so I would have to go through all the fixed stations and do it manually. It would seem sensible to be able to work in these local co-ordinates until the output of the kml and then do the a calibrate to add the 3 1. (I am sure there must be similar situations in other countries.) I am hoping there is a way to do this and I am just been incapable of finding it. From other function is Therion such as prefix etc, it would seem to fit the pattern of construction. (It is simple to do it manually if it is 3 1 but if it is 299912 1 it will be far more tedious) hope this is clearer and a solution that does not involve me manually editing tens of fixed locations is possible thanks Andrew Wolfgang Zillig wrote: > Hi Andrew, > > I'm not sure if I understand your problem correctly. There is on issue > with the EPSG codes for OSGB36, see: > http://osgeo-org.1803224.n2.nabble.com/EPSG-27700-td4469120.html > and > http://www.osgeo.org/pipermail/grass-user/2009-July/051494.html > > But this could explain your uneven numbers in the calibrate command. Can > it be that the coordinate fix misses some leading numbers? The skipping > is sometimes common to avoid huge numbers. Can you check this by > converting some coordinates from WGS84 (for instance) to OSGB36? > > Best regards > Wolfgang > > Am 17.05.2010 23:17, schrieb Andrew Atkinson: >> Hi >> >> I am having a little bit of difficulty with the various different >> helps on co-ordinate systems. I am building an area survey map from >> data from various different sources, so having to 'adapt' it, but >> really do not want to have to convert it all. It would be nice to have >> one of the outputs as .kml for google earth and the like. >> >> Lots of the data is in Survex, with Local OSGB 6 figure grid >> references. These I have been importing eg >> >> import Great_Swallet.3d -surveys use -filter great_swallet -cs >> EPSG:27700 -calibrate [0 0 0 299912 1 0] >> #Should be -calibrate [0 0 0 30 10 0] >> >> (goodness knows why the calibrate is not right, the bodge is to align >> it on goodle earth, probably my ignorance) >> >> >> As most of the new data is in Pockettopo imported, into therion, is >> attached to the survex data this has worked well. >> One cave entrance has been done in therion direct but I just dealt >> with that by doing the calibrate manually >> >> I have now been sent lots of data with lots (60 fix #ed points or >> more) of cave entrances, all in therion with local 6 figure grid >> references. >> >> I can set the coordinate system to EPSG:27700 by adding it within the >> centreline/endcentre, but that puts the cave in the Atlantic >> somewhere. So using >> centreline -cs EPSG:27700 -calibrate [0 0 0 299912 1 0] >> gives the error >> >> not enough option arguments -- -calibrate -- must be 2 >> >> Which is fair enough as calibrate is already used in the centreline >> for correcting a zero error. >> >> Not to be easily put off I tried it the other way round, remove the >> calibrate from the centreline and use >> >> cs EPSG:27700 in the config files to get therion to output in these >> coordinates, however although I can get the caves relatively next to >> each other, the kml puts them in the Atlantic again and >> >> cs EPSG:27700 -calibrate [0 0 0 299912 1 0] >> >> gives error >> >> output coordinate system specification requires single parameter >> >> >> and >> >> cs EPSG:27700 >> calibrate [0 0 0 299912 1 0] >> >> gives error >> >> unknown configuration command -- calibrate >> >> Have I missed something or do I need to go through and add 30 and >> 10 to all the fixed points. If this is so, could we have a >> calibratecs to use with the cs command to overcome localised >> coordinates on a national grid, the UK cannot be the only country with >> this problem, and it must be easier to work mainly in the more >> localised coordinates and calibrate it on output >> >> hope this all makes sense,
[Therion] Calibration of co-ordinate systems
Hi Andrew, I'm not sure if I understand your problem correctly. There is on issue with the EPSG codes for OSGB36, see: http://osgeo-org.1803224.n2.nabble.com/EPSG-27700-td4469120.html and http://www.osgeo.org/pipermail/grass-user/2009-July/051494.html But this could explain your uneven numbers in the calibrate command. Can it be that the coordinate fix misses some leading numbers? The skipping is sometimes common to avoid huge numbers. Can you check this by converting some coordinates from WGS84 (for instance) to OSGB36? Best regards Wolfgang Am 17.05.2010 23:17, schrieb Andrew Atkinson: > Hi > > I am having a little bit of difficulty with the various different > helps on co-ordinate systems. I am building an area survey map from > data from various different sources, so having to 'adapt' it, but > really do not want to have to convert it all. It would be nice to have > one of the outputs as .kml for google earth and the like. > > Lots of the data is in Survex, with Local OSGB 6 figure grid > references. These I have been importing eg > > import Great_Swallet.3d -surveys use -filter great_swallet -cs > EPSG:27700 -calibrate [0 0 0 299912 1 0] > #Should be -calibrate [0 0 0 30 10 0] > > (goodness knows why the calibrate is not right, the bodge is to align > it on goodle earth, probably my ignorance) > > > As most of the new data is in Pockettopo imported, into therion, is > attached to the survex data this has worked well. > One cave entrance has been done in therion direct but I just dealt > with that by doing the calibrate manually > > I have now been sent lots of data with lots (60 fix #ed points or > more) of cave entrances, all in therion with local 6 figure grid > references. > > I can set the coordinate system to EPSG:27700 by adding it within the > centreline/endcentre, but that puts the cave in the Atlantic > somewhere. So using > centreline -cs EPSG:27700 -calibrate [0 0 0 299912 1 0] > gives the error > > not enough option arguments -- -calibrate -- must be 2 > > Which is fair enough as calibrate is already used in the centreline > for correcting a zero error. > > Not to be easily put off I tried it the other way round, remove the > calibrate from the centreline and use > > cs EPSG:27700 in the config files to get therion to output in these > coordinates, however although I can get the caves relatively next to > each other, the kml puts them in the Atlantic again and > > cs EPSG:27700 -calibrate [0 0 0 299912 1 0] > > gives error > > output coordinate system specification requires single parameter > > > and > > cs EPSG:27700 > calibrate [0 0 0 299912 1 0] > > gives error > > unknown configuration command -- calibrate > > Have I missed something or do I need to go through and add 30 and > 10 to all the fixed points. If this is so, could we have a > calibratecs to use with the cs command to overcome localised > coordinates on a national grid, the UK cannot be the only country with > this problem, and it must be easier to work mainly in the more > localised coordinates and calibrate it on output > > hope this all makes sense, > > Andrew > > ___ > Therion mailing list > Therion at speleo.sk > http://mailman.speleo.sk/mailman/listinfo/therion
[Therion] Calibration of co-ordinate systems
Hi I am having a little bit of difficulty with the various different helps on co-ordinate systems. I am building an area survey map from data from various different sources, so having to 'adapt' it, but really do not want to have to convert it all. It would be nice to have one of the outputs as .kml for google earth and the like. Lots of the data is in Survex, with Local OSGB 6 figure grid references. These I have been importing eg import Great_Swallet.3d -surveys use -filter great_swallet -cs EPSG:27700 -calibrate [0 0 0 299912 1 0] #Should be -calibrate [0 0 0 30 10 0] (goodness knows why the calibrate is not right, the bodge is to align it on goodle earth, probably my ignorance) As most of the new data is in Pockettopo imported, into therion, is attached to the survex data this has worked well. One cave entrance has been done in therion direct but I just dealt with that by doing the calibrate manually I have now been sent lots of data with lots (60 fix #ed points or more) of cave entrances, all in therion with local 6 figure grid references. I can set the coordinate system to EPSG:27700 by adding it within the centreline/endcentre, but that puts the cave in the Atlantic somewhere. So using centreline -cs EPSG:27700 -calibrate [0 0 0 299912 1 0] gives the error not enough option arguments -- -calibrate -- must be 2 Which is fair enough as calibrate is already used in the centreline for correcting a zero error. Not to be easily put off I tried it the other way round, remove the calibrate from the centreline and use cs EPSG:27700 in the config files to get therion to output in these coordinates, however although I can get the caves relatively next to each other, the kml puts them in the Atlantic again and cs EPSG:27700 -calibrate [0 0 0 299912 1 0] gives error output coordinate system specification requires single parameter and cs EPSG:27700 calibrate [0 0 0 299912 1 0] gives error unknown configuration command -- calibrate Have I missed something or do I need to go through and add 30 and 10 to all the fixed points. If this is so, could we have a calibratecs to use with the cs command to overcome localised coordinates on a national grid, the UK cannot be the only country with this problem, and it must be easier to work mainly in the more localised coordinates and calibrate it on output hope this all makes sense, Andrew
