(16) Discussion on the problems caused by offset compensation in Webgis

1. Background

In the previous chapter, when explaining the implementation of the map translation function, I raised two questions at the end:

A After the map is panned, the XY of the canvas of the vector layer changes, at which point the screen coordinates are converted to the screen coordinate formula based on the geographic coordinates, can the features be displayed correctly on the canvas?

B Vector Layer Canvas's origin coordinate XY is it necessary to revert to the original (0,0)?

The answer to these two questions is: not and need.

In this chapter, we will explain in detail the reasons for these two answers.

2. What is the offset compensation amount?

When the map was panned, we did two things: one was to change the Mapcanvas's origin coordinate XY, and the second was to change the actual geographic extent of the screen at that time. The detailed implementation process and the formula can refer to the design and implementation of the translation function in the previous chapter Webgis.

Both operations require a common parameter, which is the operation offset (Movex,movey) at this time. However, at this point the operation offset is not the offset compensation amount. The offset compensation amount is for the initial coordinate (0,0), at which point the canvas's upper-left corner coordinates XY's overall offset, which we used (Summovex,summovey) to represent.

3. Effect of offset compensation amount 3.1 if the offset compensation amount is not considered, the problem will occur

Assuming that the canvas origin of the map has been translated (Summovex,summovey), when we re-use the vector service of the geographic or business service, the geometry in the returned vector data is parsed, the coordinates of the screen are converted first, The features plotted at this time in screen coordinates are then added to the canvas. However, the problem comes, we will find that the elements at this time are not in the position we want (at the actual coordinates), but in other places and thus the offset. This is also a complete description of our first question.

3.2 This problem occurs because of the 3.2.1 Review screen coordinates and geographical coordinates of the reciprocal conversion formula

Before we discuss this issue, we need to look back at the formulas I gave in the tenth chapter for the reciprocal conversion of screen coordinates and geographical coordinates:

A Screen coordinates converted to geographic coordinates

geoxy.x = screengeobounds.left + ScreenX * slicelevellength/tilesize;

GEOXY.Y = Screengeobounds.top-screeny * slicelevellength/tilesize;

B Convert geographic coordinates to screen coordinates

screenxy.x = (geox-screengeobounds.left)/(slicelevellength/tilesize);

SCREENXY.Y = (Screengeobounds.top-geoy)/(slicelevellength/tilesize);

where Geoxy represents geographic coordinates, SCREENXY represents screen coordinates, Screengeobounds represents the screen's geographic extent, and Sliecelevellenth represents the actual geographic length represented by a tile under the map level, Tilesize represents the pixel size of a tile.

3.2.2 The problem of generating offsets from the formula analysis

We carefully observe the formula for converting geographic coordinates to screen coordinates, by subtracting the geographic coordinates represented by the upper-left corner of the screen container by the geographic coordinates at this point, then dividing the geographic length represented by a pixel to the screen coordinates at this point relative to the upper-left corner of the screen container.

As you can see in my description, the upper-left coordinate of the screen container is mentioned repeatedly, what is the upper-left corner of the screen container? Let's look at the translation principle I gave in the previous chapter:

The upper-left screen coordinates of the container are the coordinates (0,0) that overlap the top-left corner of the canvas at the beginning.

Therefore, when we add a feature relative to (0,0) to a canvas in which the upper-left corner has become (Summovex,summovey), the problem of feature location offset occurs.

3.3 How to resolve this offset problem

Knowing the problem that caused the offset, we just need the remedy. That is, when we turn the geographic coordinates in the vector data into screen coordinates, we subtract an offset compensation amount.

That is

Screenxy=geoxytosreenxy (Geoxy)-summovexy

At the code level, that is, when drawing, the converted screen coordinates are subtracted from the offset compensation amount.

4. When does the offset compensation amount return to zero?

To figure this out, we have to study the coordinate transformation formula again. In this formula, an important parameter is involved, that is, slicelevellength, the actual geographic length represented by the tile length under the current map level.

Imagine that when our map level changes, then this parameter slicelevellength also changed, if Summovexy or the previous number, then the actual geographical length of the summovexy is no longer the correct geographical length.

This can cause a problem when the map level changes, and if you continue to use the previous Summovexy value, the resulting converted screen coordinates will be offset.

At this point, if we adopt such a practice, after the map level changes, all the summovexy will be changed to 0, that is, to revert to the non-offset state, it will be a good solution if the retention of summovexy value caused by the position offset problem.

At the code level, a zoom event is thrown each time the map changes level, and the layer should listen for this event and then change the upper-corner coordinate XY of the layer (canvas) to 0.

5. Further explore the nature of offset compensation and its problems 5.1 raise questions

Here, I continue to give two questions:

A. I want to click on the mouse after each mouse can draw a dot, but when the map was dragged, the mouse click on the map, but did not draw the dots in the click Place, but offset.

B. Also want to click on the mouse to draw a point in the mouse click, even if you do not drag the map, when the mouse click on the already drawn features, found that the current draw points offset to other places.

5.2 Experimental and experimental results analysis

In answer to the above two questions, I first give a set of experimental data.

Stagexy: Coordinates of the global stage;

LOCALXY: local coordinate system;

GeoPoint: The geographical coordinates at this time;

Mapdrawcanvas: The origin coordinates of this layer (Canvas);

Screenpoint: Coordinates are converted to screen coordinates at this point;

Fixedsreenpoint: The corrected coordinates of the screenpoint minus the offset;

1) When the map is not dragged, that is, when there is no offset compensation amount:

2) When you drag the map, there is offset compensation amount:

5.2.1 Conclusion 1-screen coordinates for coordinate conversion preferably stagexy

When you don't drag the map and drag the map, the stagexy and the screenpoint that convert the geographic coordinates to screen coordinates are well-matched. For this reason, it is not difficult to understand when we have carefully looked at the formula of geographical coordinates converted into screen coordinates, because the coordinates of the converted screen are relative to the (0,0) coordinates, and the corresponding stagexy coordinates of this mapdrawcanvas are relative to (0,0).

This conclusion tells us that the screen coordinates used for coordinate conversion are best stagexy.

5.2.2 Conclusion 2-the converted screen coordinates must be subtracted from the offset to be equal to the localxy at this time

Observing the experimental conclusion, the screenpoint minus the offset fixedscreenpoint the minimum error is equal to Localxy. To draw within a container, you must use its LOCALXY coordinates.

5.2.3 Conclusion 3-The offset is the origin of the container (Mapdrawcanvas. x, Mapdrawcanvas. Y)

We found that when the origin coordinates of the container (Mapdrawcanvas) (Mapdrawcanvas. x, Mapdrawcanvas y) changed, the resulting localxy in the local coordinate system also changed. With this offset, the container's origin can be used directly.

5.3 Questions and Answers

From conclusion 1 we can see that the coordinates used for coordinate conversion are preferably stagexy.

The reason for issue 1 is that LOCALXY is used as the screen coordinate, and then the LOCALXY is converted to geographic coordinates for saving. When the map is panned, the saved geographic coordinates are no longer the correct geographic coordinates, and the feature is drawn with an offset.

The reason for issue 2 is that when we click on a feature, the localxy is no longer relative to the local coordinates of the container mapdrawcanvas, but rather to the local coordinates of the clicked feature. So there is a very serious shift in the coordinate conversion.

6. Summary

In this chapter, we detail the nature of the offset compensation amount and the problems and solutions it causes. In this chapter, we mention a lot of what we've already talked about, including coordinate transformations and translational nature. Finally, I give a simple experimental data, for you to further explain the nature of the offset compensation amount.

In the next chapter, we'll discuss the algorithm, design, and implementation involved in the tool bar's acreage and area tools. I hope you will continue to pay attention.

--------Welcome reprint, but retain the copyright, please indicate the source in obvious place: http://www.cnblogs.com/naaoveGIS/

(16) Discussion on the problems caused by offset compensation in Webgis