UTM Coordinate System projection

gluLookAt() serves as a viewing transformation. You have to clarify differences between viewing and projecting.

Yes. It can be used for both, if you are using gluPerspective(). glOrtho() does not reflect changes in the distance, so “zooming” is excluded. At least on that way. But you can implement zooming by changing glOrtho parameters.

Of course that it can, but refer to the previous answer.

Hi friend…

Thanks for sharing knowledge with me… Now its my turn to give a test… and its your turn to tell me whether i’m pass or fail… Probably this will be my last post… Whatever i have written here is according to my understanding…

First and foremost, there is a difference between, computer monitor pixel and OpenGL coodinates. So in order to convert from Monitor pixel coordinate to OpenGL coordinates is called the process UnProject. And the reverse process is called Project. And in order to do so, we make use of gluUnProject and gluProject… Am i correct…??

Secondly, When user clicks on the canvas, we UnProject the mouse (x,y) values and process it… Now little bit more practical explaination… I run my application, and the interface is standing in front of me… First thing i need to do is the set the coordinate system… So suppose as an example, i Set the coordinate system, with

projection = UTM, ellipsoid = WGS84, zone=44, northern hemisphere…

Now coming to the storing of values, i am using two different variables… One to store the actual pixel value, and another to store the converted values (values converted to the current coordinate system…) So suppose i want to display a line… I make use of variables having actual value to display on the canvas and converted values to display in property grid…

Now, suppose i want to convert the coordinate system… From UTM projection to the Geographic (lat/lon) projection. For this conversion i make use of PROJ.4 library… So i take each and every point from the list. I read the converted value and pass them as an argument to PROJ.4 library… I get the converted value and store them into the same variable(which is used to store into the converted variables)…

So basically, the actual stored values will remain same, only the converted values will be changing… This is what i have implemented till now… Am i correct…?? Please dont fail me… :slight_smile:

Thanks in advance…

Hi!

No problem. The pleasure is mine. :slight_smile:

I don’t like grading students. It is the worst part of the education process. I would be much happier if I could only teach and not prepare exams and evaluate students’ knowledge, but … And never say it is the last time… Who knows… :slight_smile:

Yes! To be more precise, the gluProject() function transforms the specified object coordinates into window coordinates using modelMatrix, projMatrix, and viewport matrices specified as a parameters of the function. The gluUnProject() function maps the specified window coordinates into object coordinates.

That is OK!

Uhhh… Depends on what you are intending to achieve. The Coordinates which you call “Monitor pixels” should be coordinates in your OpenGL scene, and in order to be properly displayed must be a geographic (map) projection. I suppose that UTM is most suitable for your purpose. But as you have already said, UTM coordinates are large. For example, Y-coordinate is a distance from the Equator. Who cares about thousands of kilometers if your displayed region is just a few dozen square kilometers large?! So, subtract center of your area from the UTM coordinates and let’s that be coordinates you will use to display data (first pair of coordinates you are storing for each entity). Besides, you can store also original UTM coordinates to avoid two additions before calculating coordinates in another geographic coordinate system.

Everything you display should be in that (native) coordinate system. Second pair of coordinates can be in another (chosen) coordinate system. And that is the place where Proj.4 does its job. If that coordinates servers only for displaying in a grid control, nothing in the OpenGL scene is changed when you choose another coordinate system. But if you want the data to be displayed in the chosen coordinate system, then everything is much different. In that case, you should recalculate all coordinates and display objects in a new system. For example, choosing LatLon (i.e. Geographic) projection, everything will be stretched along the X-axis, and the stretching will be more and more apparent as you go north. In that case, first pair of coordinate will be translated version of the second pair, and you don’t need to store dual coordinates, because you can easily calculate another by just adding/subtracting certain values (usually center of your area of interest).

Hi,

But if you want the data to be displayed in the chosen coordinate system, then everything is much different.

Yes… The requirement for my application is the same as u mentioned in the above statement…

In that case, you should recalculate all coordinates and display objects in a new system.

All coordinates means…?? only the coordinates of the objects or also my glcanvas projection area coordinates…?? (i mean to say here that near, far, left, right, top and bottom) all should be recalculated…??

For example, choosing LatLon (i.e. Geographic) projection, everything will be stretched along the X-axis, and the stretching will be more and more apparent as you go north.

How much it has to be stretched…?? or will the proj.4 will give the stretched value…??

In that case, first pair of coordinate will be translated version of the second pair, and you don’t need to store dual coordinates, because you can easily calculate another by just adding/subtracting certain values (usually center of your area of interest).

I’m not clear with this point… How exactly can be the second pair calculated…??

Thanks again…

When you change coordinate system, recalculate OpenGL display coordinates in three steps:

  1. If displayed feature is not a point, maybe you should subdivide feature into smaller peaces. (For example, a quad in one projection is a distorted rhombus, or parallelogram, or trapeze in another). If the feature covers small area, skip subdividing and just perform recalculation of its vertices.
  2. Use Proj.4 to calculate position in a chosen projection.
  3. (optionally) subtract coordinates of the center of your area in order to “localize” coordinates.

You don’t need to store multiple values for the coordinates (each in different system), because you can display coordinates in the actual (chosen) coordinate system. My advice is to use step 3, especially in the case of UTM and similar projections.

The parameters of the glOrtho() must also be changed, because we are now in different coordinate-system, and viewing area cannot be the same.

Proj.4 will do everything (according to geographic projections) for you, so don’t bother with stretching. Only be aware that some primitives must be subdivided before reprojection.

I hope that this time I have succeeded to formalize my advices. :slight_smile:

Hi…

When you change coordinate system, recalculate OpenGL display coordinates in three steps:

  1. If displayed feature is not a point, maybe you should subdivide feature into smaller peaces. (For example, a quad in one projection is a distorted rhombus, or parallelogram, or trapeze in another). If the feature covers small area, skip subdividing and just perform recalculation of its vertices.
  2. Use Proj.4 to calculate position in a chosen projection.

Till here i understood…

  1. (optionally) subtract coordinates of the center of your area in order to “localize” coordinates.

This point is optional u said… Why is that so…?? I think this point works fine only if the coordinates are in UTM system, right…?

Secondly, suppose i read in a file which contains lat/lon values (long in range of 71-72 and lat in the range of 0 - 1.5), then in this case, there is no need to use proj.4… Just directly read the values and display on the canvas… But if i plot these values, then it will be visible very small compared to the actual screen… coz my glcanvas size is 0 to 800 along x and 0 to 450 along y… So basically how do i take care of such situations where in the range of x and y axis are much smaller (or much bigger) compared to my display canvas size…??

You don’t need to store multiple values for the coordinates (each in different system), because you can display coordinates in the actual (chosen) coordinate system. My advice is to use step 3, especially in the case of UTM and similar projections.

I also want the coordinates to be displayed below on the status bar as the mouse moves… So i think keeping the converted values will help for this purpose instead of spending time to convert each coordinate… What say…??

The parameters of the glOrtho() must also be changed, because we are now in different coordinate-system, and viewing area cannot be the same.

Proj.4 will do everything (according to geographic projections) for you, so don’t bother with stretching. Only be aware that some primitives must be subdivided before reprojection.

This is fine…

I hope that this time I have succeeded to formalize my advices.

Yes you have… But that adjustment… :slight_smile: And also please go through my new post on help requirement of optimizing the display techniques…

Thanks

When you start to have difficulties with a large numbers, than you can understand why “the third step” is important. :slight_smile:
If everything works fine, just skip it.

That’s right!

The size of the screen in pixels is irrelevant! Stop thinking in pixels and start thinking in logical coordinates. OpenGL is a 3D API. Everything you define is expressed in 3D coordinates in some “virtual” space. Fragments (the “candidates” for pixels) appears after a rasterization step. Some of the fragments survive trip through 3D pipeline and they become pixels. How the process of rasterization converts vector data to a raster depends on the Viewport transformation. Please, please, please, READ AGAIN 3rd CHAPTER OF THE RED BOOK, or 4th chapter of the SuperBible.

That’s OK!

Yes you have… But that adjustment…

Well, if your coordinate system is LatLon and you want to see 2x2 degrees, then (right-left) and (top-bottom) must be 2. If your coordinate system is UTM, and (right-left)=2 and (top-bottom)=2, then you will see just 2x2 meters! Parameters of the glOrtho() are NOT defined in pixels, but in logical coordinates. I think that your way to a success must start with forgetting about pixels at all! :slight_smile:

hi.

Well, if your coordinate system is LatLon and you want to see 2x2 degrees, then (right-left) and (top-bottom) must be 2. If your coordinate system is UTM, and (right-left)=2 and (top-bottom)=2, then you will see just 2x2 meters! Parameters of the glOrtho() are NOT defined in pixels, but in logical coordinates.

Ya i know… It was just an example… Suppose if i read any other file, there the range may be totally different… It may be between 78 to 84 (along x) and 8 to 10 (along y)… In this case the range is different… So in this case the parameters passed to the glOrtho will change… I’m wondering how these parameters can be set priorly, in order to fit any data, and display it(data) at the center of the screen…

One way what i was doing is finding min and max in both x and y direction and use them as parameters for glOrtho()… I thought this would work… But it isnt giving me the desired output…

THanks again…

Hi Alexsandar…

I am trying two cases, one for west coast off Goa and another off Visakhapatanam along East coast… I’m getting correct desired result for the west coast… I used the same technique which i explained in my previous post… But the same logic isnt working for east coast…

Any other solution or logic u can give…??

Thanks in advance

Hi, rakesh_thp!

For that example parameters can be set like this…

glOrtho(-3,3,-1,1,near,far);

But, be aware that aspect in this case is 3! So, set viewport on adequate way. Or, what I suggest, adjust viewing frustum according to viewport (set the same aspect).

Set projection to, for example,


float aspect = (float)window_width / (float)window_height;
glOrtho(-aspect, aspect, -1, 1, near, far);

And in the viewing transformation translate the whole scene so that the center of the scene is in (0,0). For example:


glTranslatef(-81.0f, -9.0f, 0.0f);

Can you provide some picture of that? What does it mean “the same logic isn’t working”? I guess the aspect is the problem.
It must me the same as in the viewport transformation, or the picture will be stretched.