Silke, I wanted to answer your 2 mails in one, but it began to become a huge mail, so I split it up...
Silke Reimer wrote: > > During the projects we had to enhance p.mapper in some directions > and I would like to give them back to p.mapper as far as this is > possible and useful. Right now I have a great diff (based on version > 1.9.1 or p.mapper) which I have to split into different diffs for > each change. I hereby would like to ask you whether there is interest > in our enhancement and which I should prepare as seperate diff: > The problem is that the current development version went quite away from version 1.9.1 so that an ingestion of the code cannot be so easily achieved, I fear. In general, I would recommend that if somebody wants to contribute some parts it might be best to announce something beforehand. I would then not touch those parts, or at least try to communicate necessary changes that might interfere with the development of others. A CVS maybe might help for distributed development, but it still would require that developers are aware of what others are doing. My general question is, which functionality should find it's way into the generic p.mapper without overloading the application with if/then/else checks. And which is a very customized add-on that is defined for a very special application scope. > Legend: > - new legend type multi which is a special combination of some other legend > types: > - list of all layers > - layer out of actual scale are greyed > - nested layers > - activation/deactivation of layers by checkbox > I think parts of your display methods are available in 1.1.0 and the dev snapshot of pmapper 2. But I started now to try a complete new approach because especially for version 2 the used JS library 'dTree' has some shortcomings. With regard to dynamically added layers (like for client-side WMS) there is a need for the possibility to modify the layer structure by using the simple functionality of [DOM-Object].innerHTML = '' I experienced strange behaviours for this with dTree and IE for the initial loading that may cause the legend to just load partially legend icons, and that looks a bit odd. Additionally, the code started to become difficult to maintain, because it was spread over different functions for each legend/TOC type. The new approach planned for 1.1.1 and 2.0 is a bit less sophisticated using a table structure created by PHP, but it's easier to maintain. Also one function should cover all the legend types. The legend/TOC types are also more easy to combine. I hope I will find time to get a good prototype ready in the next 1 to 2 weeks. I think it might be a bit too detailed to describe all the planned legend modes, but for the interested folks I can describe it separately. > I18N: > - full support for gettext instead of the p.mapper internal way to > define text strings. > I already mentioned this in a previous mail. I will use a neutral function _p() that can be mapped to the gettext _() or can use the current approach. I personally will not use the gettext functionality but prefer the maintenance of all language settings via a SQLite DB. > Checkscale: > - adaption of minscale and maxscale: p.mapper shows everything in > ]maxscale,minscale[ while UMN MapServer works with > [maxscale,minscale]. P.mapper has been adapted to UMN MapServer > I do not understand that. I thought pmapper displays all layers that have their scale inside the range defined by max/minscale, like Mapserver does. So a "MAXSCALE 100000" plus "MINSCALE 10000" means that a layer is displayed eg. at a scale of 70000, but not at a scale of 200000, nor at a scale of 8000. This is a bit confusing regarding the definition of large/small scale, but MS works like that (also ESRI eg. changed that from ArcView 3 to ArcGIS to the opposite meaning...). > Info-Results > - adding vertical tabular to show results of a layer. This is useful > if you many attributes in a tabular but only few results. > How is that achieved? The query result is currently written as hard-coded HTML table that makes it difficult to display the result in a different way without re-structuring the code. Can you swap between the display methods? An approach could be to use something like templates (PHP templates, XML and XSL, etc), all with it's advantages and disadvantages. > startGroups and defGroups > - we added the parameter startGroups to config.ini which defines > those layers which are shown when loading the application the > first time while defGroups are now those layers which are shown > all the time. > I currently maintain layers that are always to be displayed by not mentioning them in the config.ini and set them to STATUS default in the map file. How should such layers be displayed in the legend or TOC? Without checkbox? Or just in the legend, not in the TOC? > searchlist: > - Define searchlist in a seperate file (mainly because the list has > been quite long in our case and will change from time to time) > In newer versions all attribute search definitions are defined in 'js_custom.php'. This file is also the area for further customizations that should not be touched by newer developments of p.mapper. > Funktions: > - added a new function to Show coordinates at a point defined by a > mouse click. > Do you mean with display of different projections? Like having the map in a Transverse Mercator but the coordinates in lat/lon? Or display both projected and geographic coordinates together? The current coordinates of the mouse in map coordinates are already available via the showCoordinates() function. Or do you think more about displaying the coordinates for later copy&paste? I think a generic solution could be helpful where you can specify all desired projections as ESPG code and get the results back for the mouse click for all of them. I found it very convenient to have the map displayed in a projected system but the coordinates dynamically (for the mouse move) in lat/lon. This requires conversion formulas in JavaScript for every projection used. I have a formula for the projection we use at work, ETRS-LAEA. If anybody wants to contribute more, he/she is very welcome. I can provide a document with the UTM/ETRS<->lat/lon formulas for Europe, just needs some efforts to bring them into JS. > Many greetings, > > Silke > Greetings from Italy Armin > > > ------------------------------------------------------------------------ > > _______________________________________________ > Pmapper-users mailing list > Pmapper-users at faunalia.it > http://faunalia.it/cgi-bin/mailman/listinfo/pmapper-users
