5Map: Free GIS Rendering Engine Vinay Kumar Student Computer Science Dr. Rajesh Bhat Student Computer Science Abstract Over the last half a decade there has been major technological revolutions in the domain of GIS in comparison to its total history of around forty five years. These technological advances have made the GIS technologies expensive and as a result inaccessible to GIS enthusiast and common learner. This prompted the development of 5Map, a free GIS Rendering Engine with features comparable to ones available in many existing commercial products. 1. Introduction 5Map a GIS rendering engine, is full of almost all the important features which one finds in commercially available products. The objective behind developing 5Map as free GIS rendering engine is to free the consumers and developers from the clutches of multinational companies who provide these GIS rendering engines commercially at an exorbitant price. The Purpose of providing 5Map in free domain is being met by making it available in the form of an ActiveX control, which can further be used by other developers to customize their application around it. Here the focus is on the selection criteria used for choosing technologies for the development of 5Map from a variety of technological options available as-on-date, and the Architecture of 5Map along with its technical features. 2. Technology Selection Criteria The selection criteria for choosing technologies from various technological options available, goes as under:
 Native implementation of GDI+ on Windows is much faster then Java2D which interacts with Operating System through Java Virtual Machine. For performance reasons use of GDI+ as native implementation on Windows is an obvious choice. 3. 5Map Architecture  All the editing are done over secondary buffer i.e. map details like Road (Line), area (Polygon), etc. are modified in secondary buffer. This modified drawing is then overlaid on primary buffer data which is shown in user window. 4. Technical Features
ActiveX Controls have become the primary architecture for developing programmable software components for use in a variety of different containers, ranging from software development tools to end-user productivity tools. For a control to operate well in a variety of containers, the control must be able to assume some minimum level of functionality that it can rely on in all containers. These functionalities are provided by ActiveX technology on windows. MFC provide framework required to build an ActiveX control. Any other COM supported programming language can use our control. Even Java can be used for building application around the ActiveX Control of 5Map on Windows. A flexible architecture is developed for handling graphics work with implementation of various functions which in turn execute corresponding functions by invoking GDI+ calls. This implementation removes tight coupling between graphics code of 5Map and GDI+. Underlying graphics system can easily be changed without making any changes to the rest of system. GDI+ A graphics device interface, such as GDI+, allows application programmers to display information on a screen or printer without having to be concerned about the details of a particular display device. The application programmer makes calls to methods provided by GDI+ classes and those methods in turn make the appropriate calls to specific device drivers. GDI+ insulates the application from the graphics hardware, and it is this insulation that allows us to create device-independent applications. GDI+ is divided into three parts: Vector graphics involves drawing primitives (such as lines, curves, and figures) that are specified by sets of points on a coordinate system. GDI+ provides classes that store information about the primitives themselves, classes that store information about how the primitives are to be drawn, and classes that actually do the drawing. Example: Rect, Brush, Pen. Provide functions related to loading, unloading and manipulation of image data. Used when we do raster tracing. Typography is concerned with the display of text in a variety of fonts, sizes, and styles. GDI+ provides an impressive amount of support for complex task such as sub pixel anti-aliasing. I. Line Drawing  I. Line Drawing Status DrawLine(const Pen *pen, const PointF &pt1, const Point &pt2); pen [in] Pointer to a pen that is used to draw the line. pt1 [in] Reference to a PointF object that specifies the start of the line. pt2 [in] Reference to a PointF object that specifies the end of the line. II. Polygon Drawing Status DrawPolygon(const Pen *pen,const PointF *points, INT *count); pen [in] Pointer to a pen that is used to draw the polygon. points [in] Pointer to an array of PointF objects that specify the vertices of the polygon. count [in] Integer that specifies the number of elements in the points array. III. Curve Drawing  Curve Drawing Status DrawBezier(const Pen *pen,const POINTF &pt1,const POINTF &pt2, const POINTF &pt3,const POINTF &pt4); pen [in] Pointer to a pen that is used to draw the Bézier spline. pt1 [in] Reference to the starting point of the Bézier spline. pt2 [in] Reference to the first control point of the Bézier spline. pt3 [in] Reference to the second control point of the Bézier spline. pt4 [in] Reference to the ending point of the Bézier spline IV. Label/Text Text is drawn by calling TextOut, DrawText, DrawString of GDI+. But, before text can be drawn, it has to be rotated and scaled to fit according to given scale and position. Following steps are used in drawing text:
It is done by changing the scale of GDI+ buffer we maintain. In this way zoom is done automatically by GDI+.  Steps taken while Zooming: The window refers to the logical coordinate system of the page space. The extent is the maximum value of an axis. This function sets the maximum values for the horizontal and vertical axes of the window (in logical coordinates). When mapping between page space and device space, SetViewportExtEx and SetWindowExtEx determine the scaling factor between the window and the viewport. BOOL SetWindowExtEx( HDC hdc, // handle to device context int nXExtent, // new horizontal window extent int nYExtent, // new vertical window extent LPSIZE lpSize // original window extent); BOOL SetViewportExtEx( HDC hdc, // handle to device context int nXExtent, // new horizontal viewport extent int nYExtent, // new vertical viewport extent LPSIZE lpSize // original viewport extent); hdc [in] Handle to the device context. nXExtent [in] Specifies the horizontal extent, in device units, of the viewport. nYExtent [in] Specifies the vertical extent, in device units, of the viewport. lpSize [out] Pointer to a SIZE structure that receives the previous viewport extents, in device units. If lpSize is NULL, this parameter is not used. This function (along with SetViewportExtEx and SetWindowExtEx) helps define the mapping from the logical coordinate space (also known as a window) to the device coordinate space (the viewport). SetViewportOrgEx specifies which device point maps to the logical point (0,0). It has the effect of shifting the axes so that the logical point (0,0) no longer refers to the upper-left corner. BOOL SetViewportOrgEx( HDC hdc, // handle to device context int X, // new x-coordinate of viewport origin int Y, // new y-coordinate of viewport origin LPPOINT lpPoint // original viewport origin); BOOL SetWindowOrgEx( HDC hdc, // handle to device context int X, // new x-coordinate of window origin int Y, // new y-coordinate of window origin LPPOINT lpPoint // original window origin); hdc [in] Handle to the device context. X [in] Specifies the x-coordinate, in device units, of the new viewport origin. Y [in] Specifies the y-coordinate, in device units, of the new viewport origin. lpPoint [out] Long pointer to a POINT structure. The previous viewport origin (in device coordinates) is placed in this structure. If lpPoint is NULL, nothing is returned VI. Panning Panning is done by taking rectangle equal to user window from primary buffer and drawing it on user window. When a user moves his mouse over user window, the amount of shift is send to  DoPanning(REAL X_Shift,REAL Y_Shift) X_Shift : Amount of shift in X direction Y_Shift : Amount of shift in Y direction Once shift is complete, Primary buffer is again updated and user viewable area again comes into center in primary buffer. DoPanning Utimatly calls GDI function BitBlt. The BitBlt function performs a bit-block transfer of the color data corresponding to a rectangle of pixels from the specified source device context into a destination device context.In our case from Primary buffer to user window Reason for making primary buffer 9 times of user windows is to give user a smooth panning experience. Since, user can maximum shift from one end to other end in one go. As soon as user release his mouse. Whole primary buffer is updated again, taking user visible area again in center of primary buffer. VII. Hit Test It is a very important task. For every interaction between user and program, we have to use hit test. Doing hit test efficiently is a very complex task. Specially, it becomes more complex when we have to detect point on Bezier curves and other irregular shapes. GDI+ again helps us in this complex task. In GDI+ we associate path with every line and Bezier curve. When ever we have to check for a point over a line or Bezier. We use GraphicsPath function IsOutlineVisible which indicates whether the specified point is contained within (under) the outline of this Graphics Path when drawn with the specified Pen and using the specified Graphics. One important aspect while doing hit test is tolerance i.e. to select line even when mouse is not over it and is in some specific range of line. This is accomplished by specifying pen class width. This object is passed to function. Larger the value of width larger will be the tolerance. bool IsOutlineVisible (PointF pt, Pen* pen, Graphics* graphics) pt [in] A PointF that specifies the location to test. pen [in] The Pen to test. graphics [in] The Graphics for which to test visibility. This method returns true if the specified point is contained within (under) the outline of this GraphicsPath as drawn with the specified Pen; otherwise, false. There are other overload implementations VIII. Raster Layer Tracing Control can load in the background which can be used to trace data to support large maps. Maps currently loaded are of 4bit color depth. Maps are loaded by calling information related to Layers. The information like size, coordinates where it layers are to be loaded is saved in Layer file. Based on user request corresponding layer can be loaded.  Raster Layer Tracing IX. High quality anti-aliased vector graphics Anti-aliasing is very important aspect for smooth graphics. Anti-aliasing is a compute intensive job and puts small penalty over the performance of application. This performance degradation is negligible in fast computers.  Anti-aliasing These modes are set on each call to various drawing functions. To switch between various rendering mode we use: Status SetSmoothingMode( SmoothingMode smoothingMode); X. Icons Many locations over maps are represented by icons. Icons are currently BMP files. These BMP files could be sequence of image. Sequence of images plays animated Icons. Each image sequence is read by dividing image in equal parts. Information related to Icons is saved in Image list file which contains number of sequences present in image.  This BMP file has sixteen sequences of images. The width of this image is divided into 16 parts and each sequence is drawn incrementally. The drawing of icons takes place in a different thread and does not hamper working of main thread running ActiveX. Icons are drawn directly to user window using XI. Path Finding Currently Standard implementation of Shortest-Path algorithm using Dijkstra Algorithm is done, where weighted graph is taken to calculate shortest path.  Shortest-Path XII. GPS support 5Map’s control can be connected to any National Marine Electronics Association (NMEA) supporting device. NMEA 0183 protocol is a RS-232 compatible protocol providing information in the form of string. NMEA standard is 4800 baud with 8 bits of data, no parity, and one stop bit. The data is read from a device connected to COM port of computer. Data is extracted from there. XIII. Functions Supported by 5Map ActiveX control The 5Map ActiveX control works in two modes. In one mode it only acts as a GIS rendering engine and presents information. The second mode is Edit mode where various elements of map can be edited and changes are saved in corresponding files. 5Map support two functions: long GetStatus(long StatusID); It returns the current status of various element of ActiveX control long SetStatus(long StatusID, VARIANT* Data1, VARIANT* Data2); Sets the data and mode of ActiveX control. Data is passed in and out of control as a Variant data type. Status ID represents various actions to be performed, accordingly arguments are passed. 5. Conclusion & Future work During the initial development phase of 5Map the basic issues of GIS rendering engine revolving around graphics support had been addressed to bring around the point that such GIS engines are the need of almost everyone and should be available in free domain. The more advanced issues can be addressed and customized as advanced modules around the ActiveX control of 5Map and depending on the type of applications may be available free or at some cost. In future more optimization of internal algorithm of data handling and drawing will be done. And data import and export from other format will be included. Addition of more innovative editing features will be done. Porting code to smaller frameworks like PDA’s will be key area of development. |