Ajax and WebGIS [reprint]

The article I read last year is very good. <Transfer> More and more desktopsApplicationTurning to the Web Platform, people have always hoped that the increasingly rich Web applications will be easy to use, efficient, and interactive. WithGoogleThe launch of a series of services such as Google Maps and Gmail gave people a new Web user experience. A notable feature of this experience is thatDownload, Installation, fast operation response, and good interaction, especially the previous white screen phenomenon caused by refreshing the browser while waiting for the returned results. This exciting experience comes fromAjaxMethod.Ajax(Asynchronous JavaScript + XML) is not a newTechnology. As its name shows,AjaxIt is a combination of several booming technologies in a new way: Using XMLHttpRequest for asynchronous data transmission; using XML and XSLT technology for data exchange and processing; using XHTML and CSS as the display standard, dynamic display and interaction are achieved through DOM, And all of these are connected through javascript concatenation. These traditional technologies seem simple, but they bring new vigor to Web application development. ForWebGISThis kind of good user experience has always been lacking in applications. It is difficult for researchers and developers to find a proper balance between performance and user experience. This article discussesAjaxThe method is applied to the implementation of the WebGIS client to improve the user experience. AjaxClient Analysis Traditional client Analysis After years of development, the system architecture of WebGIS has become mature and stable. Generally, it adopts a three-layer Browser/Server structure, that is,GISApplication Server, spatial database, and so on. The browser corresponds to the client in the traditional C/S (Client/Server) structure. The client contacts the user andGISService bridges play a major role, but are inherently subject to browsers. The next day, they were deeply influenced by the development technology used by the system. In the early stage, WebGIS used CGI, and interactive operations were completely dependent on browser processing. The user experience was poor and often encountered white screen conditions. The researchers immediately introduced the plug-in technology to expand the browser'sGISBut the effect is not significant. With Java,DCOMLarge-scale application of other technologies, mainstreamGISVendors have used applet, ActiveX and other technologies to develop clients. They are embedded into the web page for running and have strong functions, but they are highly coupled with the server. before using them for the first time, download and install the corresponding program. The difference is that the applet can be run across platforms, provided that the Java Runtime Environment is supported. ActiveX is only applicable to Windows platforms and requires security authentication and registration during installation. These additional requirements are a burden on common users. Therefore, in addition to Applet and ActiveX, commercial WebGIS software such as ArcIMS also provides client implementation based on JavaScript and DHTML technologies. Although simple, but the results are not ideal, users often get stuck in waiting. In addition, the spatial data transmission mode adopted by WebGIS also has a great impact on the development of the client, and there is always a battle for the yagu data.MapIt can be processed and drawn on the server side, and transmitted to the client through the HTTP protocol in the form of JPG and other images. This type of raster map is static and interactive, and transmission occupies a large amount of network bandwidth. However, it can be viewed directly in a browser. Therefore, the client functions are simple and have high requirements on servers. The relevant work can also be partially moved to the client, which is often used in Applet and ActiveX methods. Vector Data is usually transmitted Based on the TCP/IP protocol. Because the data volume is relatively small, the speed is fast. This client can draw a map locally to achieve real-time interaction and even complete some complex analysis work. Weigh the pros and cons, developers have to balance the client with the server, or adopt the fat client mode, thin client mode, or hybrid mode. With OGC (openGISConsortium) with the introduction and continuous improvement of sharing standards, WebGIS gradually develops towards Information Sharing: Vector Data uses GML as the exchange format in a unified manner and can be transmitted through the HTTP protocol like raster data; the provided services are gradually refined and standardized. As long as various OGC service specifications are followed, the related spatial data processing tasks can be completed in a heterogeneous environment, reducing the coupling between the server and the client. These changes put forward new requirements for browser-based clients and also bring opportunities. AjaxModel The running process of the traditional web application model is: user operations trigger the HTTP request submitted to the Web server. After receiving the request, the server executes the corresponding operation and then returns an HTML page to the client. This process repeats until the user exits. The entire process is synchronized, and the next step can be started only after the previous step ends. As a result, the user remains in the waiting status after sending the request and before returning the result. The browser is also unable to respond to further operations because of waiting, and the white screen is caused by PAGE refreshing. AjaxThe difference between the model and the traditional model lies in The Asynchronization of service responses (figure 1 ). This is by introducing an intermediate layer between the client and the server --AjaxEngine (AjaxEngine.AjaxThe engine splits the client page into a data layer, a control layer, and a presentation layer: various types of data in the browser are organized into a DOM tree. for various events triggered by operations, use JavaScript to process DOM data and draw Interfaces Based on XHTML and CSS specifications. The clear structure lays the foundation for asynchronous responses. all communications with the server are centrally submitted to the XMLHTTPRequest object for processing. This object encapsulates the XML-RPC protocol and supports asynchronous requests, which is equivalent to a dedicated thread that communicates with the server outside the independent user interaction thread. In short, XMLHttpRequest can use JavaScript to send requests to the server and process responses without blocking users. This asynchronous communication mechanism isAjaxThe core of the model. This feature makes it suitable for environments that require frequent interaction with the server and immediate response. The following uses the IE environment as an example to describe the basic application of XMLHttpRequest. Create an XMLHTTPRequest object request, submit the parameter URL to the server using the get method, and call the callback function after receiving the response. The Code is as follows: Request = new actviexobject ("Microsoft. XMLHTTP "); If (request! = NULL) { Url = "http: // localhost/Q? X = 1 "; Request. onreadystatechange = callback; Request. Open ("get", URL, true ); Request. Send (); } Based onAjaxAnd OGC standard WebGIS framework Through the client Development Review andAjaxMechanism Analysis, it is not difficult to find that WebGIS has adoptedAjaxBasic Features of development: requires immediate interaction and response, mass and frequent communication with the server, and data transmission in the form of GML or images. In fact, ArcIMS has long been stuck inAjaxThe door is out. Its HTML viewer mode can transmit ArcXML data and images, and use JavaScript scripts to control operations while using DHTML technology to display maps. This is only a key part of asynchronous transmission. So,AjaxIt can fully undertake the implementation of the WebGIS client and improve user experience. In WebGIS that complies with OGC specificationsAjaxIt is extremely appropriate to implement the client. The obvious advantage is that it achieves the common client required for space information sharing in an extremely natural way. People do not need to install additional programs. They can obtain space information from the Internet by relying only on the browser itself. The focus of system development only needs to be focused on improving server performance. Google maps has shown this scenario for us. Google maps can be seen as an application of the Web Coverage Service and WFS service in the OGC specification, providing image and interest point query services respectively. The map is rendered, andSatellite imagesImages are stored on the server side and sliced and organized in pyramid mode. Point of interest data containing geographical coordinates is stored in the database separately. On the client, the entire interaction process is: 1,AjaxThe engine responds to user operations to obtain the current scale, field of view, and the location of the mouse on the screen; 2. Convert the screen coordinates into geographical tags and read the relevant data asynchronously; 3. Convert the returned point of interest coordinates into screen coordinates, draw on the client, and stack the coordinates on the map and image. Google Maps, as a mass-oriented map publishing system, is a good solution, but it is far from enough for WebGIS applications. Maps are just a simple reference system here, users cannot complete more space data processing and analysis work. A basic WebGIS should provide WMS services (Web Map Service) and WFS services. WMS allows you to draw a map and output it as an image in a specified way. It mainly supports calling the getcapabilities, getmap, and getfeatureinfo interfaces. The getmap interface implements the drawing function. WFS provides various object retrieval services, such as adjacent queries. The extended WFS-T Service supports additional data editing and update operations. Two methods can be used to call the OGC Service: one is to write the parameters into a URL and submit them to the server using the get method; or encapsulate the Request command into XML and submit it using the POST method. Raster maps are often obtained using the get method, as shown in figure Http://wms.jpl.nasa.gov/wms.cgi? & Version = 1.1.1 & request = getmap & styles = & layers = global_mosaic & format = image/PNG & SRS = epsg: 4326 & bBox = 73,18, 800 & width = 456 & Height =, Request the drawing service to JPL (Jet Propulsion Laboratory). The WGS84 coordinate system is used. The output format of the map containing the global_mosaic layer is PNG in the range of 18-53 degrees north latitude and 73-135 degrees east longitude, the size is 800*456. Complex WFS calls encapsulate service requests in XML format and submit them in post mode. The returned GML results are separated by XPath and XSLT to obtain the geographical coordinate and attribute information of the objects, finally, an object is drawn on the map to represent attributes in the form of a list.