Great dramatization Adrian!!!
>From a more practical point of view, my experience with Bursa-Wolf
was mostly for PostGIS. Here we use the EPSG:3003 system for
Italy mainland and the spatial_ref_sys table of PostGIS doesn't have
the TOWGS parameter for EPSG:3003. This resulted in _very_ bad transforms
from/to 3003 and 4326 (aka WGS84) and, I believe, to/from any other system.
So I added the TOWGS parameters inside the srtext and proj4text of the
PostGIS spatial_ref_sys table for EPSG:3003 and now transforms are accurate.
These are the parameters I added:
for "srtext" => TOWGS84[-104.1,-49.1,-9.9,0.971,-2.917,0.714,-11.68]
for "proj4text" => +towgs84=-104.1,-49.1,-9.9,0.971,-2.917,0.714,-11.68'
Where did I take them from???
>From the EPSG database itself (in PostgreSQL format), using this query:
SELECT o.coord_op_name, m.coord_op_method_name, p.parameter_name,
pu.sort_order, pv.parameter_value, u.unit_of_meas_name, a.area_name
FROM epsg_coordoperation o
JOIN epsg_coordoperationmethod m
ON m.coord_op_method_code = o.coord_op_method_code
JOIN epsg_coordoperationparamvalue pv
ON pv.coord_op_method_code = o.coord_op_method_code AND
pv.coord_op_code = o.coord_op_code
JOIN epsg_coordoperationparamusage pu
ON pu.coord_op_method_code = o.coord_op_method_Code AND
pu.parameter_code = pv.parameter_code
JOIN epsg_coordoperationparam p
ON p.parameter_code = pv.parameter_code
JOIN epsg_unitofmeasure u
ON u.uom_code = pv.uom_code
JOIN epsg_area a
ON a.area_code = o.area_of_use_code
WHERE o.coord_op_type = 'transformation' AND o.deprecated = 0
AND o.target_crs_code = 4326 AND o.source_crs_code = 4265
order by o.coord_op_name,pu.sort_order
Where 4326 is the crs code for 'WGS84' and 4265 for 'Monte Mario'.
Both are defined inside the epsg_coordinatereferencesystem of the EPSG database
and are referenced inside the WKT string of each record inside the
PostGIS spatial_ref_sys table.
The values I used are the ones with coord_op_method_name equal to:
'Position Vector 7-param. transformation'
in the order they appear by field sort_order.
I'm absolutely not an expert in this field, but this solved our
transform problems and I hope it can be of help for others.
Bye
Paolo Rizzi
> -----Messaggio originale-----
> Da: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] conto di
> Edgar Soldin
> Inviato: martedì 18 settembre 2007 10.17
> A: List for discussion of JPP development and use.
> Oggetto: Re: [JPP-Devel] Bursa-wolf parameters [WAS: Projection with
> Geotools2 CRS]
>
>
> Adrian,
>
> true, true .. well told story rhat ... thanks alot.
>
> just to make a point:
> if bursa wolf parameters are missing, the parameters for an accurate
> ellipsoid shift are missing, so results will be (very?) inaccurate?
>
> kind regards ede
> --
> > Hey,
> >
> > In the "for dummies" collection, "geodesy for dummies",
> from adrian,
> > will surely become a best seller :-)
> >
> > Michael
> >
> > Adrian Custer a écrit :
> >
> >
> >> On Mon, 2007-09-17 at 10:46 -0700, Jody Garnett wrote:
> >>
> >>
> >>
> >>> Edgar Soldin wrote:
> >>>
> >>>
> >>>
> >>>> just one question .. what is this bursa wolf parameter option?
> >>>>
> >>>>
> >>>>
> >> ...
> >>
> >>
> >>
> >>
> >>> My impression is that this is scary math I never quite
> understood. The
> >>> javadocs describe it all detail (and have links to papers etc..).
> >>>
> >>>
> >>>
> >> Well, Bursa was a 9 year old bicyclist from the Alps
> and...no, no, no, i
> >> lie. Actually it's not particularly scary math and quite easy to
> >> understand. All you really need to remember is that no one
> has ever been
> >> to the center of the earth.
> >>
> >> So everyone started surveying (mostly so the repressive central
> >> governments could exploit taxes from people and have lots
> of jolly wars
> >> where people could slog through the mud and kill each
> other so they'd be
> >> blood and suffering for all). Each group started from some
> random place
> >> on the surface of the earth. Right away, it becomes
> obvious to everyone
> >> that euclidean rules don't work so well. Some didn't care
> so much since
> >> taxes are basically arbitrary anyway and getting serious
> about it means
> >> you'd have to walk through fields and woods and get lots
> of mud on your
> >> shoes. Others kept at it and resorted to spherical
> geometry. Once you
> >> start doing that precisely and at continental scales you
> realize that
> >> doesn't really work either so you decide to try the next
> hardest thing,
> >> an ellipsoid of rotation. Now how do you know which one to
> choose? Well
> >> you pick one that minimizes your squared errors. All good
> and nice but
> >> (1) you are surveying the ground which is anything but an ellipsoid
> >> since it has all those ditches you keep falling into and that keep
> >> getting your clothes covered in mud and (2) you are not perfect
> >> especially with all that mud on your paper. So you have a bunch of
> >> errors. Well everyone that does this comes up with lots of
> different
> >> ellipsoids that work really nice for their data and
> everyone is sure
> >> they clearly have found the 'one true ellipsoid' and they
> decide to use
> >> that for all their work. Then everyone guesses where they
> actually are
> >> on each of their particular ellipsoids which involves lots of going
> >> outside at night and looking up from the mud at the stars.
> But then it's
> >> not like the edges of each survey was nice and level on
> these ellipsoids
> >> either --- think of the eastern USA. You can start nice
> and clean and
> >> warm and dry at an inn in Boston on the edge of the sea
> drinking clam
> >> chowder and having a good time but a few months later it
> will be bitter,
> >> bitter cold in that tiny town of Denver because you are
> somewhere like a
> >> mile high up in the air and you're wet and covered in mud
> from slogging
> >> through the plains in a snowstorm. So you've got a pretty
> good idea that
> >> your data is on a major slant but, well, you'll do your
> best to make up
> >> for it but it really doesn't help the effort any,
> especially what with
> >> all that mud that's still itching in your hair. So your
> errors may be a
> >> wee bit big but hey it's all right: it's good enough to
> wage lots of
> >> good wars with lots of mud and blood and to keep collecting lots of
> >> taxes so no one cares too much.
> >>
> >> Fast forward to more recent times where some people want
> to talk to lots
> >> of different governments and work with lots of different
> data. They take
> >> everyone's guess and try to line them up. Well it turns
> out, when you
> >> try to line everything up, that the center points of all
> the different
> >> ellipses aren't really the same points and even the
> orientation of the
> >> three axes are all a bit off because of how everyone
> guessed where their
> >> were on their ellipsoids. So now, to go from one data set
> to another so
> >> they line up "the best," you need estimates of how much to
> rotate each
> >> of the axes and how to shift the center point around; all
> this beyond
> >> even the obvious stuff of changing between the different
> definition of
> >> all those "one true" ellipsoids.
> >>
> >> When you do this mathematically, you need a bunch of
> parameters: these
> >> now have the names of the wolf and the bursa. Generally,
> you can only
> >> come up with good parameters if you have lots of data to
> compare and
> >> some good software to do the comparing. That's what the
> EPSG did for
> >> everyone. The guys in the pickup trucks that went out
> looking for oil
> >> kept falling into ditches along the way and getting mud on
> their faces
> >> but when they got back to the office they had a good sense
> of what lined
> >> up with what and could say: "yep, that hill there is the
> same as this
> >> squiggle here and there's this big ditch right here that
> cost us our
> >> third flat tire and..." So they collected as much data as
> they could and
> >> compared it and came up with a database of parameters by
> which you go
> >>
> > >from one data set to another. So that's it. That's why we use their
> >
> >> data; we don't have to fall in any ditches and can avoid
> getting mud on
> >> our clothes. They give us their parameters and we can
> mostly line up
> >> data from one survey against data from another. But you do
> need some
> >> good parameters because the earlier folk had a harder time
> of the mud
> >> and the data they created don't just line up the way we
> would like them
> >> to.
> >>
> >> Actually doing the math is a bit harder but the concept is pretty
> >> straight forward: geographic data all ultimately gets tied
> into points
> >> on the earth surface and that requires estimating where the points
> >> really are and how they line up on the estimated ellipsoid
> being used.
> >> That in turn means none of ellipsoids quite line up and we need
> >> parameters to move between them.
> >>
> >> --adrian
> >>
> >>
> >>
> --------------------------------------------------------------
> -----------
> >> This SF.net email is sponsored by: Microsoft
> >> Defy all challenges. Microsoft(R) Visual Studio 2005.
> >> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> >> _______________________________________________
> >> Jump-pilot-devel mailing list
> >> Jump-pilot-devel@lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
> >>
> >>
> >>
> >>
> >>
> >
> >
> >
> --------------------------------------------------------------
> -----------
> > This SF.net email is sponsored by: Microsoft
> > Defy all challenges. Microsoft(R) Visual Studio 2005.
> > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> > _______________________________________________
> > Jump-pilot-devel mailing list
> > Jump-pilot-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
> >
>
>
> --
> public class WhoDidIt{ // A comment. I love comments
> private static Person sender;
>
> public static void main (String[] foo){
>
> sender = new Person();
> sender.setName(new String[]{"Edgar", "Soldin"});
>
> Address address = new Address();
> address.setStreet("Stadtweg 119");
> address.setZip(39116);
> address.setCity("Magdeburg");
> address.setCountry("Germany");
>
> sender.setAddress(address);
>
> sender.setMobilePhone(" +49(0)171-2782880 ");
> sender.setWebSiteUrl(" http://www.soldin.de ");
> sender.setEmail(" [EMAIL PROTECTED] ");
> sender.setPGPPublicKey(" http://www.soldin.de/edgar_soldin.asc ");
> sender.setGender(true);
>
> System.out.println(sender.toString());
> }
> }
>
>
> --------------------------------------------------------------
> -----------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Jump-pilot-devel mailing list
> Jump-pilot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
