On Mon, Jan 23, 2006 at 10:30:09PM +0100, Armin Burger wrote: > Ciao Silke, a second round:
And again its me :-) > > Silke Reimer wrote: > >Hi Armin, > > > >since you have mentioned that you want to publish future plans > >shortly, I thought this could be the right time to join into the > >discussion. Since our clients want to have enhancments of the > >already existing applications our main issues are right now: > > > >1 Enable p.mapper to use different config.ini to have more than one > > p.mapper application at once > > Should be covered now by version 1.1.0 and the last dev snapshot for pm > 2 (http://www.pmapper.de/dl/pmapper2-2006-01-11.zip). Great!! I will have a look on that shortly. > >3 Make map.phtml more flexible to allow rearranging of the > > page. We already started by allowing different sizes of the map > > BTW: forgot to mention this in my last mail but of course > > we would like to contribute this as well if you are interested. > > This is one of my favorite enhancements. I would like to have a flexible > definition of the layout, including all the re-sizing and moving stuff > of the DIV elements. I postponed it for quite a long time and got a > first functioning version in the development snapshots. I'm everything > else than satisfied with it because it makes layouts partially even less > flexible than with frames. > > I would like something that allows eg. > * define, if the map or the legend should re-size, or no resize at all > * define easily where to place elements (map, legend/TOC, toolbar, etc) > * have an intelligent and robust way of moving/resizing elements > * get all running with most browsers > (Safari and Konqueror cause some problems) As I already said: We have changed map.phtml to be able to resize the map when loading the application. This could be a start - even when this fulfills not the full functionality. > > And when starting to think about it, a visual tool with definition, > sizing and positioning elements would be nice, as a long term project > maybe. Could eg. be like the attached example (use SHIFT+mouse-drag for > re-sizing). And then save the result as map.phtml Yes, this would be cool - but probably more a mid- or longterm project. > > All this stuff requires fairly good skills in Javascript and all the > DOM/DHTML stuff, and some cool blood ;-) I started to hate Javascript > when working with all the positioning/resizing stuff for pmapper 2. So > everybody is very welcome to take over the lead for this! I offered that > already since some time, though... You already did a great job! I will take into account the need for help for this task into account for our new project. Hopefully we can spend some time and money to do a step in this direction. > > > >4 Enhance p.mapper to be a full WMS-client supporting Web Map > > Context, adding of user defined WMS-layer etc. (seems to be > > already on your list) > > > > I started last fall with some development & implementations. Due to > limited time and a lack of deeper knowledge of XSLT I ceased further > development for some time. My idea was to use the built-in functionality > of Mapscript to create and load Web Map Context files. Ie. requesting > the capabilities from the server, extract layer info and use an XSLT > template to convert the capabilities XML to WMContext XML that is loaded > with Mapscript. I got a basic function running. Needs also some > functions to re-order layers because newly added layers are by default > on top of existing ones. > > It requires to save the information somehow on the server for the > requesting client, but that seemed to be feasible. The advantage would > be that one can save and load WMS layers for the next session (might be > even possible with cookies). I mainly stopped because I had to better > understand tokenizing strings with XSLT, for a developer with good > knowledge of XSLT it takes probably less than an hour to achieve it. Do you really think that XSLT is necessary for that? What you need is the possibility to read read and write WMC-files (could be done by mapscript as you mentioned) and read a layer tree from a capabilities document to give the user the choice to add a single layer from a whole WMS. This has already be done by several projects (phpwms, maplab (mapbrowser), mapbender). Maplab seems to me the closest to the pmapper concept. So it might be possible to learn from that code. > > > >What do you think? Are those ideas confirming with yours? > > > > Some ideas additionally to that: > > * some more testing of the XMLHttp (AJAX) stuff > to ensure proper functioning under all conditions > * re-structure some code, especially for queries > * setting transparency for layers (some tests made) > * replace pop-up windows with DHTML/DOM windows, > avoiding pop-up blocking by browsers > * setting order of layers, maybe using a bit functions like at > http://www.walterzorn.com/dragdrop/demos/dnd_snapandsort.htm Cool! > * a clear API for adding dynamic layers (started) > * Adding points of interest to the map, including a label: > a prototype is already working, the points are added to the URL > and can be saved as bookmark or sent as link via mail Then I would like to add: Add not only POIs but also simple lines or polygons. > * more elaborate PDF printing using LaTeX > * Export of query results in Excel, XML, etc. > * Setting up a WIKI where people could add some typical > problems, solutions, docs, Howto's, etc. This could also help to maintain something like a TODO-list > > and maybe some more that currently slipped my mind... > > > One bigger plan I have in mind for a long term extension, is to have the > possibility to separate the client and server logic. Ie. having an > Internet server acting as middleware and providing the user interface, > collecting client requests and sending a map request with pre-defined > parameters to the map rendering server. Then getting back from this > rendering server the map image or just the URL and forwarding it to the > client. This could eg. be achieved via Remote Procedure Calls (RPC). > > One could separate the server providing public access and the server > that does the rendering. Both would not need to be in the same network > environment, the rendering engine could be inside the corporate network. > Also map requests could be sent to different rendering servers for load > balancing. > > Currently just an idea, but I would like to check the feasibility. Would > also allow to have just the rendering engine using PHP/Mapscript, the > client interface could then as well be written in Java or C#, etc, just > have to create the correct requests. > > > I know it's quite much that one could add, and I don't know how feasible > it is to implement or coordinate it. But first it needed some folks that > wants to work on it, anyway... We certainly are willing to join when we have appropriate projects for our clients. It's good to know your plans so that we can keep this in mind for our next steps. Some of your ideas might become necessary for some projects anyway. In this case we will inform you to coordinate its development (with a strong contribution by us of course). Saluti, Silke -- Silke Reimer : www.intevation.de/~silke | GISpatcher: www.gispatcher.de Intevation GmbH: www.intevation.de | Thuban : thuban.intevation.org Georgstr.4 : 49074 Osnabr?ck | FreeGIS : www.freegis.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://faunalia.it/pipermail/pmapper-users/attachments/20060124/575ff73c/attachment.pgp
