Summary of recent WebGIS learning and online vectoring of GoogleMap Images

Recently, with some research efforts on WebGIS, I have learned some of my own experiences. Here I will write about it and share it with you.
Because of the limitations of the knowledge structure, I have not studied the underlying software aspects in the early stage. However, I think students with poor computer background do not have to stick to these concepts, however, you must have an ideological grasp. If you are involved in a project, you should be able to start quickly.
WebGIS is nothing more than displaying a map on a webpage and responding to user interaction operations. From the word of its WebGIS, we can see that, on the one hand, the "Web" feature should consider the browser and the HTTP mechanism behind it; on the other hand, the "GIS" feature should consider the unique GIS data format;
I. Web features:
1. the browser's response is an HTML document, and the HTML document is a byte stream transmitted over HTTP. the browser parses the file based on its tags to restore the file to a formatted rich file with embedded multimedia elements. The map that WebGIS needs to pass to the browser is intuitively an image, but the image can be scaled, displayed by hierarchy, and queried by space. The image is very good for the browser, and is displayed directly when it passes through.
2. the browser imposes restrictions on the display methods and means of graphics and images. The image format is more in line with the computer's display principle. Therefore, it is very efficient to store image libraries on the server side, most general electronic maps use this method. For example, GoogleMap uses image pyramid and other technologies. browsers use built-in plug-ins to demonstrate graphics. For example, Internet Explorer uses VML, firefox uses SVG, which can be driven by JavaScript to generate images on the client;
Ii. "GIS" features:
1. The map has rich presentation forms, diverse projection information, display requirements of different scales, and rich and varied display styles;
2. Maps are not only a problem of display, but also a variety of "Space Analysis" at the application layer;
After writing two features, there is a problem here. Which of the following solutions can be used to transmit a map in vector format?
(1) The first method is to directly transmit the map image generated on the server to the browser;
(2) The second method is to transmit vector code to the browser, and then use JavaScript to drive VML or SVG on the browser side to draw a map, or use Silverlight, flex, Flash, and other plug-in technologies to draw a map;
In fact, these two methods have been applied. Most ordinary Electronic Map websites use the first method to build an image pyramid and use cache technology to reduce the burden on servers. At the same time, the second method is also used for functions that require a small amount of interaction with the server on the browser side. The second method should fully consider the browser compatibility problem. Generally, JavaScript is used to identify the browser type, we decided to call VML or SVG for plotting.
Some time ago, I spent a little time experimenting with a "Google map online vector Interoperability GIS platform". This is a website that digitizes Google map images in a browser without plug-ins, google APIs are used to make some extensions. digital vector files can be saved in the shape format of the standard ESRI. At the same time, users can load Local Shape files to Google map for Superimposition and display, in the early stage, the basic functions were initially implemented. The technologies involved mainly include Google map API, SVG/VML, Ajax, gdal/ORG, and Asp.net, in the future, there will be many bottlenecks and problems in efficiency and a fatal weakness. This is the coordinate encryption and random offset of Google map images, these bring about a Coordinate Deviation of more than meters, especially the digitization at a small scale, because Google map images only ensure that the user looks basically seamless, and do not care about the coordinate accuracy of the texture, it improves user experience at the expense of precision. Therefore, after the Google map image is digitalized, it will find that the accuracy on the coordinates is too bad, and it is not easy to correct, however, the largest scale is basically the same as the offset generated when a single image is digitalized. Therefore, it is easy to correct and there is still a prospect for creating a city's high-definition digital map.

The above is the superimposed China boundary vector shape file, with a very large coordinate offset.

However, it is highly consistent with the administrative boundaries on GoogleMap.

This is a small area of Shanghai, where the map is digitalized and saved as a shape file.

When the data size is too large, the drawing bottleneck will be found. When the size of the Shape file reaches several hundred kb, the drawing will be slow, which will be solved by multiple methods later. This is my idea. I will write several blogs later to talk about this idea and implementation process in detail.
Then, I took a look at the source code of sharpmap and found that its WebGIS mechanism is to generate a PNG image of the map on the server side and then deliver it to the client for display, but its efficiency will be very low, each time the image is zoomed in and out, it requests the server to regenerate a new NNG image. Although it uses the cache technology, the efficiency is not high. After all, this is done by a cool man. It is good to do so. I think it is very likely to be optimized. If you have time to study it and make some extensions.
This is my idea and experiment for a short time. I would like to share with you some incomplete and incorrect ideas. please correct me.