In my previous post I explained the rationale of providing the support for OpenGIS types in phpMyAdmin. In this post I will describe in detail the features I wish to implement under OpenGIS support.
Following detailed description of features is extracted from my GSoC proposal. I know this is too lengthy for a blog post, but I though this is comprehensive :)
1. Visualizing OpenGIS data
It should be possible for the users to visualize GIS data wherever applicable. When the GIS data refer to the Earth’s geography (i.e. when Spatial Reference ID is present) visualizing GIS data is done using the API of OpenStreetMap. On other occasions a simple visualization is presented. Zooming and panning is provided for better user experience.
When the user browses a table or views a query result that has atleast one OpenGIS data column a link should appear underneath the table to visualize the GIS data. User can chose the GIS column to be visualized if more than one GIS column is present and chose a label column that is used to generate tooltips and/or legend.
Here is the proposed interface layout for the visualization.
2. Inserting OpenGIS data
It is a tedious task to write the Well Known Text (WKT) format of a geometry object, especially when the data type is a complex one. This difficulty is addressed by automatically constructing the WKT from the points the user provides.
When the GIS data refer to the Earth’s geography, points for complex geometry types are captured by tagging on OpenStreetMap maps. When the GIS data refer to simple geometry WKT is constructed by X and Y cordinates the user feed in for each point. The user is provided with visual feedback of the geometry object being created and user can click on the visualization to capture the clicked location and use it as a point in the OpenGIS data object.
Here is the proposed interface to insert multipolygon data objects. The interface changes appropriately for each of the OpenGIS data types.
3. Editing OpenGIS data
Currently editing OpenGIS data fields is disabled as browser representation causes problems when submitting changes. Even when the GIS data is not altered they are sometimes captured as altered. I wish to address this problem before developing the new interface to insert/edit GIS data.
A similar interface used to insert data is used to edit OpenGIS data. User can modify the data by adding new data points and/or by deleting some of the existing data points.
4. 'Function based search'
Searching for equality or using simple comparison operators is of very less use when it comes to OpenGIS data types. When effectively used with functions defined for OpenGIS types they create powerful search criterion for searching. I wish to implement 'function based search' for OpenGIS data types to enhance the search capability under table search.
a. Unary operator functions
The user will select the function, the comparison operator and enter the comparison value. For example the user choosing function ‘Dimention()’, comparison operator ‘<’ and value ‘2’ would add ‘Dimention(`<column_name>`) < 2’ to the where clause.
Another extension to 'function based search' is function chaining. For example applying ‘Envelope()’ function to a geometric object would yield a polygon and we can apply 'function based search' to the resultant polygon. Facilitating this would require a highly dynamic interface and I wish to support this idea as an optional deliverable. However I would do my best to deliver this within the stipulated GSoC development period.
b. Binary operator functions
Search based on special relations between geometric objects is essential for an effective GIS search functionality. For example user would want to search for all geometric objects that lie inside a user given polygon or to search for all geometric object within which the given polygon lies. Moreover search functionality need to be capable of searching based on whether geometric objects cross, intersect, overlap, are disjoint etc. Similar search capabilities would be sought with related to the Minimum Bounding Rectangle (MBR) of geometric objects.
5. Exporting OpenGIS data
When exporting either database or table the user should be asked to indicate whether the Geometric data should be exported in WKT or WKB formats. In the case of exporting to SQL, compatibility should be ensured so that the data can be imported back without lose of data or data types.
Exporting GIS data in visual form makes sense only for a single geometric data column. I would like to extend this capability to bitmap images and PDFs using GD extension and TCPDF library respectively.
6. Spatial indices
When the user adds an index to an OpenGIS data column, by default a SPATIAL index should be added.
7. Browsing OpenGIS data
Three options would be added in ‘Options’ section of query result browsing window
To view geometric data in Well Known Text (WKT) format
To view geometric data in Well Known Binary (WKB) format
To view geometric data with Geometric type indication and size (e.g. [GEOMETRY – 2.2KiB])