[Mapserver-users] "SUM: DHTML Navigation Tools for MapScript"

[Martin Weinelt]

I start with the last paragraph of Steves mail: "folks with existing code to 
inventory and document what they have" .I will in the near future put together
the code and some documentation on what I have, and hopefully some parts
can be reuserd for what Chip outlined. His point under "FUNCTIONS" and
DESIGn PARAMETERS"  give  a very good starting point. 

Cheers, Martin


Steve Lime on Freitag 20 Dezember 2002 08:31:
> I'll talk to the UMN folks about a new repository soon, although nothing
> is likely to happen until after the holidays.
>
> One thing I'd like to bring up is that I'd like to see applets and DHTML
> to both be considered here. Contrary to public opinion I don't think
> applets are dead, nor is the technology that drives things like jbox or
> rosa (LiveConnect). When LiveConnect support becomes widespread again
> (IE supports it and that 90% of the market) I for one would like to roll
> out dhmtl or java versions. It may be that long term applets hold more
> promise. I'd really like to see a common API that would allow you to
> access events in either java or dhtml. Things like coordinate, layer,
> legend, and reference map mangagement being totally seperate (i.e.
> non-graphical stuff), implemented in javascript but not dependent on
> what the user interface is written in. This would allow for even more
> user interfaces (like flash or svg!) to leverage the same code. The
> dhtml/java/flash/svg code could then be *very* simple and would only
> need adhere to a relatively simple api for reporting events (e.g.
> box/mouse coordinates).
>
> The backend javascript that communitates with whatever would use the
> event information from the ui to construct URLs to use to retrieve
> components (maps, scalebars, legends, reference maps) and make them
> available to the page. I would suggest using the base MapServer CGI
> syntax (which already handles some ROSA nuances) as the communication
> API with oportunities to extent it of course.
>
> Before a bunch of coding takes place, it would seem to be to make sense
> for folks with existing code to inventory and document what they have.
> Then we can pick and choose from that lot and move forward. This would
> include the ROSA and jbox (formerly mapplet) tools.
>
> Steve
>
> Stephen Lime
> Data & Applications Manager
>
> Minnesota DNR
> 500 Lafayette Road
> St. Paul, MN 55155
> 651-297-2937
>
> >>> "Hankley, Chip" <Chip.Hankley at GASAI.com> 12/19/02 15:34 PM >>>
>
> I've received a LOT of responses since I posted this question... some
> off-line, so I thought it might be a good time to SUM. There are about
> five
> or six folks who were interested in contributing to development.
>
> Apparently a lot of us have been working on DHTML navigation tools...
> there
> are already some fairly refined tools - so there is probably not a need
> to
> re-invent this. Martin Weinelt's and Steve Lime's provide a good
> foundation... so we could probably start with their work, and make some
> modifications to build a modular 'plug-in' that could be used with
> MapServer
> or MapScript.
>
> A number of people suggested a 'skin' type approach... the idea being to
> create a more comprehensive application where all you have to do is
> supply a
> link to a mapfile and it works. While I think these types of apps are
> great
> and worthy of development, it's not really what I'm interested in here.
> The
> best explanation that I can come up with is that I want to develop a
> DHTML
> version of ROSA.  Such a tool could certainly be used as PART of a
> Skin-type
> application, but could be used independently in MapScript (or MapServer)
> apps when developers want to create something that is more customized.
>
> I'll try to explain a little better what MY goals for a DHTML navigation
> toolset are:
>
> FUNCTIONS
> -------------------------
> o Click & drag boxes.
>
>   User clicks and drags a box on the image. The tool returns
>   the bounding coordinates of the box (in image coordinates).
>
> o Single point click.
>
>   User clicks on the image. The tool returns the coordinates of
>   click (in image coordinates).
>
> o Image drag (for panning)
>
> o Mouse move capture (image coordinates) in order to display
>   geo coordinates.
>
> o 'Custom' button.
>
>   When the user clicks the button, some JS code is executed.
>
> o 'Measure' tool.
>
>   User clicks on the image and either:
>     a) clicks a second time to identify the 'end' of the
>        measure segment
>     b) is allowed to continue 'clicking' to simulate
>        vertices of a measured line segment, with a double
>        -click identifying the end of the measure segment.
>
>   Values returned are in image coordinates.
>
> DESIGN PARAMETERS
> ----------------------------
> o A 'tool' will always be associated with an image that functions as a
> button.
> o A 'tool' will have image swaps for the 'over' and 'click' events
> o Implementing a tool should be as simple as possible from the main
> program
> interface... something like this
>
>   <new tool> = createTool(<new tool>, <offImage>, <overImage>,
> <onImage>,
>                <action type>, <form name>, <form field>, <coord field>);
>
>   example:
>   navZoomIn = createTool('navZoomIn', 'ZoomInOff.png', 'ZoomInOver.png',
> 'ZoomInOn.png',
>               'rectangle', 'frmMap', 'CMD', 'COORDS');
>
>   When the user uses this tool, a field called 'CMD' in the form
> 'frmMap'
> will be given
>   the value of 'navZoomIn'. The image coordinates of the drag event will
> be
> placed in
>   the filed 'COORDS'.
>
>   The goal here is to provide kind of a navigation API... so that users
> can
> implement the
>   tools without really having to know what's going on in the background.
> They would simply
>   have to make sure that their main program included the references to
> the
> JS files.
>
> o At a minimum, should work in IE 5+, Mozilla 1.01+, or NS 7+. Would be
> nice
> if it worked with other browsers
>   (Konqueror, Opera, AOL?).
>
> ----------------------------
>
> As I mentioned in my previous post, I have no experience developing
> something in a 'team' environment like that... so I have no idea where
> to
> begin. Someone suggested setting up a CVS and mailing list... for those
> of
> you that have done other development, would this project be suitable for
> something like that, is it overkill? Do I have to set up my own CVS, or
> could we use one of the environments that is already set up for
> MapServer
> development?
>
> Thanks!
>
> Chip
> _______________________________________________
> Mapserver-users mailing list
> Mapserver-users at lists.gis.umn.edu
> http://lists.gis.umn.edu/mailman/listinfo/mapserver-users
>
> _______________________________________________
> Mapserver-users mailing list
> Mapserver-users at lists.gis.umn.edu
> http://lists.gis.umn.edu/mailman/listinfo/mapserver-users