Dear Sirs.
A colleague and I have tried to find out how projectins Work in order to try and keep a maps zoom constant while we changed the shown map from EPSG 25832 to GoogleMap and vice versa. As the two maps use different projections, the map will be redrawn in another scale if we don’t do anything about This.
Our problem is that we end up with strange values when trying to define an exact zoom Width and trying to convert this accordingly using a Proj4 projection.
The attached miniproject shows what we are talking about. The input data should be valid for UTM Zone 32, so we shouldn’t be talking errors where we are perpendicular to our projection or some such stuff.
Best regards
Keld Laursen
Knowledge Centre for Agriculture
Denmark.
Proj4Conversions.zip (35.5 KB)
Proj4 projection woes
Hi Keld,
Seems like there is something wrong with the code at line 39 in class "MainForm.cs", the northing value should read from textBox2, please try the code as following:
var
easting = Convert.ToDouble(textBox1.Text);
//var
northing = Convert.ToDouble(textBox1.Text);
var northing = Convert.ToDouble(textBox2.Text);
Thanks,
Johnny
Hi, Johnny.
Darn! The copy/paste devil got me there. I am sorry about the bad example code.
But when that small mistake is corrected, we can see that happens.
If I go with the coordinates that are preloaded and presses "show", we do see that the UTM has some wildly diferent values - as expected when going from a Spherical Mercator to a Transverse Mercator. The "Width" parameter shows that the Spherical Mercator has a distance error of about a factor of 2 at this latitude.
When we look at the parameters to the right, we can see that when we get back into Spherical mercator we have a northing error of around 135 meters, an easting error of around -126 meters and a Width (of the rectangle) error of around 780 meters.
These were the errors I were looking for an explanation for.
Quite ordinary low resolution conversations should yield better results than less than 5 meters, whereas high res conversations should yield centimeter to millimeter accuracies.
Or where am I wrong in my assumptions.
Best regards,
Keld Laursen
Knowledge Center for Agriculture
Hi Keld,
This issue is caused by we pass rectangle shape in, when we reprojection a rectangle shape 900913 and 25832. In fact this API is designed for work well by PolygonShape, so the solution should be convert rectangle shape to polygon before reprojection and convert it back after reprjection.
The code as below should be helpful:
RectangleShape rect;
PolygonShape poly = rect.ToPolygon();
PolygonShape poly;
RectangleShape rect = poly.GetBoundingBox(); // You should make sure in fact this Polygon is a rectangle shape, orelse they won’t be same shape
Wish that’s helpful.
Regards,
Don
Hi Keld,
We don’t want to do the test for rectangle shape, because the same rectangle shape won’t keep its width equal height between different projections, but for design we need they keep the same. So this API should be only work well for PolygonShape.
The solution is convert rectangle shape to polygon before reprojection and convert it back after reprojection.
The code as below should be helpful:
RectangleShape rect;
PolygonShape poly = rect.ToPolygon();
PolygonShape poly;
RectangleShape rect = poly.GetBoundingBox(); // You should make sure in fact this Polygon is a rectangle shape, orelse they won’t be same shape
Wish that’s helpful.
Regards,
Don
Hello Don.
So The problem for me is that the rectangle is converted info a trapezoid, which is then squares up into a rectangle in the new projection. When converted back into the original projection again The same happens, resulting in the rectangle being good and well distorted from the original.
One solution should be to use a horizontal line to do the calculation, or as you suggest: convert the rectangle to a polygon.
Thank you for your explanation.
Seasons greeetings,
Keld
Hi Keld,
Yes you’re right.
Seasons greetings,
Don