Three Webgis Front-end map shows the principle of the tile row number based on geographic range (CORE)

Source: Internet
Author: User

1. Preface

In the previous section we know how much of a pixel is equal to the actual number of units (meters or longitude) of the conversion method, and after knowing this principle, then how do we use it? How does it relate to our front-end display of the map? In this section, I will try to answer these two questions in detail. To say a digression, this series of articles I will be less to the code, painting flowcharts or UML diagram to communicate with you, one is not a lot of GIS and programming basis for people to read, and secondly so that we are not limited to the implementation of some code and more attention to the principle.

2. Introduction to Image Pyramid

We've talked about the concept of image pyramid before, but we haven't made a general introduction to it, and I'll add that to this concept.

2.1 Why the concept of image pyramid appears

Now, I assume we have a 1G image on our server that needs to be displayed on the front end. Our traditional approach is to first download the 1G image from the server to the front end and then the browser to load the rendering plot. But let's think about it, it must be a long time before the client downloads the 1G image, and then the browser loading such a large file will probably cause it to crash. And the most important problem is that our demand is simply to browse a certain level of the entire map, but now the full picture is downloaded, which also leads to data insecurity (download to the local), and every time we zoom in and out and drag will make the browser spend long enough time to render.

It can be seen that the traditional way is not in line with the actual demand. Later, there are new solutions, such as the concept of a dynamic plot in the IMS version of ArcGIS. That is, the current side of the request contains the need to display the scope, the size of the display window and other parameters, the background dynamic in the original data cut out a matching tile, and then return this data to the foreground, and the server to cache the tile.

However, the front-end diagram of this method is still very slow, and the pressure on the map server is too large. Finally, our image pyramid solution came into being.

2.2 Principle

Image Pyramid is, we first the original image according to the needs of users, such as the number of users need to display the data under the scale, need to display the original image of which region of the data, the original image according to these requirements are divided and extracted.

The lowest layer is the one that we extract and divide the smallest level of tiles, and the top is the largest scale tile. We look closely at a pattern that shows that the smaller the scale, the lower the tile data, and the greater the other. The result of this rule is that the smaller the scale scales the faster the transduction, and the more images the same size tiles contain.

When we set up the image of the gold tower, the front end of the request map, it will just cut the tile cache, the corresponding level of the corresponding tile can be found. Then on the front side of the tiles of these requests to the mosaic, you can get the user needs of the level of the visible tiles in the range.

3. Tile row Number Conversion Principle 3.1 Why to convert the tile row number

In the previous section, I gave a picture of the image into a discrete diagram after the organization of the file, which shows you in this graph, the organization of the file is in accordance with the tile level, row, column number to organize. In fact, the same is true of the organization style of the compact tile (Bundle), but it also has a series of conversions after the number of rows, such as reading the index file to find the offset in the file, which I will discuss with you in a later chapter. Also, standard WMS requests involve the conversion of row and column numbers, and there is a bbox parameter in the WMS request, and this parameter is also related to the conversion of the row number. In the standard WMTS request, the three parameters of Tilematrix, Tilerow, and Tilecol represent the level, row, and column number of the tile.

This shows that the level of tiles, col, and row are at the core of the request, regardless of the tile request for the offline or online map.

3.2 Tile Row Number conversion principle

In the following, we first give the formula for the conversion of the tile row number.

Assuming that the origin of the map transduction is (x0,y0), the tile size of the map is tilesize, and the actual distance represented by the 1 pixels on the map screen is resolution. The formula for calculating the row number of the tile where the coordinate point (x, Y) resides is:

Col = Floor ((x0-x)/(tilesize*resolution))

Row = Floor ((y0-y)/(tilesize*resolution))

This formula should not be difficult to understand, the simple point is, first figure out how much the actual length of a tile is ltilesize, and then calculate the geographical coordinates on the screen from the tile transduction the actual distance between the starting point lrealsize, and then use the actual distance divided by the actual length of a tile, Can be at this time the tile row number: Lrealsize/ltilesize.

Conversion principle of 3.3 resolution

As I described in the previous section, "Map scale scaling principle", when the system is a latitude-longitude system, this resolution can be used directly in the resolution of the graphics document. If the system is a planar coordinate system, this resolution algorithm is:

resolution=scale*inch2centimeter/dpi. Where scale is the map bar, Inch2centimeter is an inch to centimeter parameter, and DPI is 1 inches of pixels.

4. Application in the actual system

Now I summarize the requirements in the actual application as follows:

(1) Get the height and width of the canvas and the geometric extent of the map you want to display at this time

(2) Get the height and width of the canvas and the geometric extent of the map you want to display at this time, and also get the level of the map you need to display

Finally, we need to get the range of tiles in both of these requirements.

5. Conversion Process 5.1 flowchart

For the two requirements mentioned in the 3rd section, we have a different conversion process, here I first give the flowchart:

5.2 Detailed explanation

Some common variables are involved in the following steps, and for the sake of description, I represent some parameters here in English.

Originx,originy: The coordinates of the transduction origin when the map is transduction.

Tilesize: The screen pixel size of the tiles.

Level: Map levels.

Resolution: The actual unit size represented by the screen one pixel below a map level.

Canvaswidth, Canvasheight: The length and width of the screen

Geomaxx, Geominx: The largest or smallest x-coordinate in the geographic range.

5.2.1 first step, GET request Center point in geographic Range (CENTERGEOPOINT)

This conversion is relatively simple, but why should we first convert this center point? The reason is that the real geographic range we need last, and not necessarily the geographic range that corresponds to the screen range, is likely to be larger than the geographic extent of the screen. And in fact, it must be greater than that, in the later we explain the design of the tile layer class, we will refer to a geographical range buffer width, then we can understand why first to obtain the geographical range of the center point.

5.2.2 The second step, determine whether the request contains the level of the map to be displayed, processing 5.2.2.1 contains the Levels

If the level used is already specified in the request, then we can then use it directly to convert the actual request range of the map.

5.2.2.2 does not contain level

When there is no level in the request, our conversion will be more complex, the purpose of this conversion is to find out at what level the map should be at what level is the most appropriate, that is, Nearestlevel. The process is, first of all, according to the geographical range and screen size range of the request, we need the actual size of tiles at this time, namely: (Geomaxx-geominx)/(Canvaswidth/tilesize), that is, the actual geographical length divided by the number of tiles at this time, So we can get the actual size of the tiles in our request.

At the moment, however, we cannot guarantee that the scale of the demand in the graph we are cutting is certain. So we also need to do a traverse, traverse all the scales in our map, find a real tile actual size closest to the actual size of the tile under this demand scale, and the actual size of the tile corresponds to the map scale at this time, that is the most suitable scale we can find, The map level it represents is the map level closest to the requirement, Nearestlevel.

5.2.3 The third step to figure out the geographic range of the screen range (MinX, miny, MaxX, Maxy)

In the first step to get the Centergeopoint, the second step to get the level of the condition, this step is very simple.

First get the actual size of a pixel under level, i.e. resolution. Then the range of Centergeopoint plus or minus half the screen length (canvasbounds) multiplied by resolution is the actual geographic range that the screen range in the requirement should correspond to at the level attained.

Take the actual geographic coordinates of the x in the upper left corner of the screen as an example:

MinX =centergeopoint-(resolution* canvaswidth)/2;

Here by the way, the calculated range of this screen corresponds to the geographic extent, it is very large, in the subsequent screen coordinates converted to geographical coordinates, as well as geographical coordinates converted to screen coordinates, and offset compensation amount of the conversion is an important parameter.

5.2.4 The fourth step, calculate other parameters, such as the starting number of the tile column and the number of tiles

This step is the finishing touches, based on a series of parameters previously calculated for the final conversion.

5.2.4.1 Tile starting row number (FIXEDTILELEFTTOPNUMX, fixedtilelefttopnumy)

After knowing the geographic extent of the request, the conversion of this starting row and line number is the same. But here's a little bit of a supplement, the geographical range we've worked out does not guarantee that the geographical coordinates of the original tiles of the real tile coincide with the geographical range of the upper-left corner of the geographical range, so we should allow an expansion of the geographical range, which is a very worthwhile area to be considered. Here we default to the geographic coordinates that extend to the top left corner of the first tile requested.

The formula is:

FIXEDTILELEFTTOPNUMX = Math.floor ((Math.Abs (Originx-minx))/resolution*tilesize);

Fixedtilelefttopnumy = Math.floor ((Math.Abs (Originy-maxy))/resolution*tilesize);

5.2.4.2 actual geographical range (Realminx, Realmaxy)

We had previously only obtained the geographical range of the screen range, and when we converted the tiles needed for this range, the geographic extent of the calculated tiles was not necessarily the geographic range corresponding to the screen range, at which point we needed to recalculate the actual geographical range.

Realminx = fixedtilelefttopnumx * curlevelcliplength + Originx;

realmaxy= Originy-fixedtilelefttopnumy * CURLEVELCLIPLENGTH;

5.2.4.3 upper left corner offset pixels (OffSetX, OffSetY)

Because the first tile in the geographic range, the first tile in the upper-left corner, is not necessarily completely contained within the screen's geographic range, it involves another pair of parameters, with the upper-left corner offset pixels.

Why ask for this parameter, the reason is that when we put the tile request back to do a conversion, that is, each tile to be converted to the upper-left corner of the coordinates should correspond to the layer (Tilecanvas) on which screen coordinates. This offset pixel is intended for this conversion.

OffSetX = ((Realminx-minx)/resolution);

OffSetY = ((Maxy-realmaxy)/resolution);

Added again, where resolution represents the actual unit size represented by a pixel at this level.

5.2.4.4 number of tiles on X and y axes (mapxclipnum, mapyclipnum)

Here I first give a screen geographical range and the actual requested tile geographical range of the relationship between:

As I have already told you, the number of tiles in the geographic area of the screen we've been trying to represent is basically larger than the screen size itself. In fact, this reason is not difficult to understand, because the tile is the smallest unit of map representation, it can not be divided, so in our request for the beginning of the tile column number, the use of Math.floor this function, that is, the upper left corner of the screen to obtain the coordinates of the nearest tile row number. However, in order to obtain the number of tiles on the x and Y axes, we have to use the Math.ceil function, which is to get the nearest tile row-to-right coordinates from the screen range.

The specific formula is:

Mapxclipnum = Math.ceil ((canvaswidth + math.abs (OffSetX))/tilesize);

Mapyclipnum = Math.ceil ((canvasheight + math.abs (OffSetY))/tilesize);

6. Summary

Based on the above steps, we can finally find out the number of tiles and the number of x and Y axes required. At the same time, we obtained the parameters needed to draw the tiles on the canvas, and the upper left corner is offset pixels.

This section believes that everyone will look very tired, because this section of the process too much, the formula is too many, but also because of this, this section is we introduce the front-end display map of the most important section of the series, I hope you can work with me to the principle of a good study and scrutiny. In the next section I will write the class capacity relatively easy, the main introduction will be we figure out the number of columns, how to use it. I'll make a presentation and a summary of several common online maps and how to request offline maps. We welcome your continued attention.

Today is Tanabata, wish a happy holiday. For those of me who have the same holiday as myself, write a sentence and share with you:

On the journey of missing Miss

You are a boat, a bridge.

----------Welcome reprint, but retain the copyright, please mark the source in a prominent place

Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: info-contact@alibabacloud.com and provide relevant evidence. A staff member will contact you within 5 working days.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.