Saturday, June 25, 2011

Fifth week of GSoC

During this week I started working on the GIS data editor. 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 and this editor is aimed  at easing the task of inserting new geometry data and editing existing geometry data.

Since I wanted this feature to be available to those who does not have JavaScript enabled, I started with developing a version compatible with JavaScript disabled browsers. Users can reach this editor by clicking the pencil icon next to geometry fields in insert/edit window. The GIS data editor has a dropdown with all the geometry types and choosing a type would change the fields below accordingly. When the user fills the coordinate values and optionally SRID and hit submit, WKT is displayed, so the user can copy it in to the edit window. This is the most basic form of the GIS data editor and I wish to add number of features to enhance the user experience with JavaScript.

Earlier, editing GIS data fields were disabled as browser representation caused problems when submitting changes. Even when the GIS data were not altered they were sometimes captured as altered as described  in bug #3038193 and bug #3194559. While working on the GIS data editor I fixed this by choosing 'GeomFromText' as the default function and having the WKT with SRID in the value field. Meanwhile I had to change the data editing/inserting functionality to accept two parameters (WKT/WKB and SRID) from the value field and add apostrophes correctly.

During the next week I will be Ajaxifying the GIS data editor. By Ajaxifying user will be able to change the data type, add data points, inner rings, polygons without submitting. Further we can provide visual feedback for the changes being done by visualizing the GIS data and to automatically place the final WKT on the value field when the user is done with editing. 


  1. >I started with developing a version compatible with JavaScript disabled browsers.

    Non-js-support is not a priority of pma anymore, and in my opinion should be dropped.
    There's already a bunch of things that will not work without javascript anymore.

  2. Well yes. But letting the user enjoy basic functionality without JS support would not harm IMO. I think it's a good compromise to let the user use basic functionality event without JS and provide richer functionality available to those who has JS enabled.