User Wishlist

Contributions by Andre

  • w3c validation of code
  • digitization of points in PostGIS
  • authentication of users
  • query result printing
  • autozoom at user-defined scale (instead of full-extent, when possible)
  • possibilty to have more than one customized pmapper (in every single part of the application, e.g: html frames, legend, ecc...) launched from the same web-page
  • I would like to see an extended (general) querybuilder. First you should be able to choose on which layer you would like to query, then you should be able to choose from a list of fields and then you should be able to select from a picklist of values derived drom that field, accessable by a .. button. It should not only work on shapefiles, but it would be perfect if it also works on OGR data (MapInfo?, VPF point layers on ODBC-connections etc). For a start, it would be nic if the values-lookup-button works within the search frame as it is now. When using multiple search items, it should recognise the values choosen in the other form-fields. E.g: To find an adress, you lookup first the place field by pressing the place lookup button ..(lookup:select distinct placename from adresses). After choosing the place (e.g Washington), you choose the street (type Mad, press street lookup button .. and the query returns (select distinct streetname from adresses where placename = 'Washington' and streetname like '*Mad*') and after selecting 'Madison Drive', you type or choose the housenumber lookup button (which fires the SQL: select distinct housenumber from adresses where placename = 'Washington' and streetname = 'Madison Drive'
  • It would be nice if result pages form query, nquery or search forms could be extended with related information that is derived from relational databases (data sources). E.g. if you find a parcel, there would be a tabbed interface or a [+] button, and when you click on that the owner of that parcel is extracted form a relational database (access, orcale, SQL server) by means of odbc connections or OLEDB provider. This should be pre-configurable by using an ini-file. The ini-file describes the relations between a layer and its datasource(s), which fields do act as the join-fields (e.g: layer.field(parcel-id) = owner.field(parcel-id)). If muliple datasources are possible then the use of a tabbed interface should be preferable. It should also be a great if these datasources are searchable on their own. So you do search and find an adress or parcel-owner from a database, and a locate button (+) locates the corresponding parcelshape on the map.
  • It would be perfect if the changes you have to make in config.ini, custom.php and custom_js.php and javascript files when you add layers, layergroups and search-entries, are combined in a more centralised place, e.g. the config.ini-file (or maybe a connection to a configuration database) This way, the .php and .js files can stay untouched. Also, it is much easier to use a multiple configurable application, in which all content (mapfile, layers, hyperlinks and datasources) are combined and simply can be adressed by calling the preferred ini-file in the url.

These suggestions do not add much GIS functionality, but do add a lot of "practical use" functionality to act as an information system.


Code available

Please write here a brief description of the code you have developed for p.mapper, specifying:

  • your email address
  • an URI where to download it, if available
  • on which version of p.mapper is your code based
Last modified 13 years ago Last modified on Nov 21, 2006, 10:09:32 PM