How to convert Contour Data

I recently discussed the contour line scheme. I also studied it yesterday and submitted a document to the internal system. Today I will briefly talk about my idea of contour line conversion.

First of all, you can understand what is a contour line. Baidu has already made it very clear. I have also read the definition of a contour line before I have a deeper understanding of the contour line, in particular, I also learned from this about why a rough line is drawn between the four contour lines.

Then let's determine the input and output. The input is the DEM data downloaded from the Internet. You can download the data from here: http://srtm.csi.cgiar.org/selection/inputcoord.asp. The output is custom contour data. The engine can display this data, or click the contour to view its height information. The input and output content is consistent without any conflict.

Next we will talk about the idea of contour line conversion. The ambiguity in this part is quite large. Some say that a self-developed tool directly converts data in TIFF or. Dem format to our final data format. I think this practice is very good, but it is very difficult to implement. We can't use this sentence to summarize the entire process. Let's analyze it in detail to find the best solution.

Although the output data is customized binary data, it does not explain the principle of the format. I think the principle of final data is nothing more than two types. One is vector data, just like most navigation electronic maps, which are expressed by point, line, and area, this is also true for the vast majority of GIS data. The other is raster data, which can be processed into tile data, similar to tile used by Google Maps, only the tile data originally stored on the server is packaged into a binary file for local display. This is what the offline map provided by Baidu map currently does. I personally think that the implementation of the latter is relatively simple, but it is relatively limited. For example, clicking a contour line to display the elevation information of the contour line seems a little troublesome. I prefer to use the former, but how can I directly convert the tiff data of a grid into the final data of a vector?

I admit that it is the best way to convert from raster data to custom binary vector data, but it is not difficult to implement it. My idea is to use a third-party tool to convert tiff to vector data, such as the SHP format, and then convert the vector data to a custom binary file, self-made tools only consider converting General formats to their own formats, and the difficulty is naturally greatly reduced. In addition, this tool exists in the world. We do not have to look for foreign professional tiff to vector conversion software. We can use a general globe er. In globe Mapper, there is a menu for generating contour lines. You can directly convert Topographic Map Data (including. tif,. Dem,. bil, and other formats) into their own intermediate format.

Note: In the equal height settings, this number determines the minimum equal height in the final data. One person has another idea: if the data source itself is 90 meters accurate (such as the topographic map provided by NASA), if this height is set to 30 meters, there must be distortion, because two contour lines between 90 and 30 need to be differentiated, the difference method must be distorted.

It is the intermediate format data converted near Lhasa, Which is customized by Globe er. GMP data, use GM to open the data in the intermediate format, and then select the SHP data of the output vector. SHP is the middle data of the easily read contour lines, and then from the general intermediate format to the final format, is this conversion relatively simple?

In retrospect, it is proved from another example that it is difficult for TIF terrain data to Vector Data: globe mapper does not provide the function of directly inputting Topographic Map raster data to output contour map vector data, it is also necessary to generate intermediate data through the contour line function, and then convert it to a common vector data format.

I think: technology can implement a lot of difficult content, but as a non-professional or unfamiliar person in the terrain data field, why do we need a one-step cow tool, instead of using a step-by-step implementation policy? From another perspective: 1. the user data is strange. Can you meet all your needs? 2. In terms of personnel gradient or value transfer, users will not pay for the tool, but users will pay for the data. How to pay? It is to find our product Technical Support Team, provide raw data to them, and make them the final data. The technical support staff first convert the data into intermediate formats using common tools, using Self-made tools to convert the data into final data, the technical support team can still rely on such a business to make money. How happy is this three-win situation?

Therefore, defining your own data specifications and providing a simple and easy-to-use conversion tool is more costly than making a conversion software.

This is my idea of converting contour data. You are welcome to discuss it together.