From: Wendy E. <mr...@gm...> - 2006-08-14 21:44:20
|
I'm actually glad we're talking about all this stuff before we try to implement anything. Here's an example scenario that I imagined. Let's say we have a tsunami striking Indonesia. We get the best GIS data we can (from a map server, Google, whatever) and make that the basis for our display. But maybe we have other data coming in, like GPS coordinates, that may be linked to other data. For example, maybe we have a list of hospitals, with information about their physical addresses, size, capabilities, etc, and we also have their GPS coordinates. What I'd like to see the GIS module do is "discover" that there's information to map (using XML or some other mechanism), and then render the hospitals as their own layer that the viewer could turn on or off. It'd be ideal if we could let the "hospital" module make some suggestions about how to display the coordinates (e.g., as red circles). Does this make any sense? Wendy On 8/14/06, Brent Wood <pc...@pc...> wrote: > > > How easy will this be for module developers with little or no GIS > > knowledge? Lets say the Camp Management System wants to have a map > > interface where the user can click to create a camp marker. Under the > > API idea, the developer would call some function such as shn_show_map() > > which would show the relevant map of the relevant GIS plugin along with > > a listener interface. All the standard formats would be supported > > underneath depending on the admin's selections and settings, so the > > developer has abstraction and is free to concentrate on other business > > logic. Here, the developer would only be calling the above function, and > > the relevant code/tools/services/standards will be dynamically called > > based on the admins selections on the backend. > > > > > If you look at the WMS/WFS spec from OGC, that is exactly what they do. This > issue has been around in GIS/web mapping circles for years, and has been > very > effectively addressed by OGC standards. Unless there is some special > requirement of Sahana which no-one else managing, rendering & displaying > maps > via the internet has, then I see no point in reinventing this particular > wheel. > > > I'll stick to describing WMS here, as implemented by UMN mapserver. > > A spatial dataset exists ( > eg: shapefile, Mapinfo TAB, PostGIS table, aerial photo, WMS data source) > Describe this in a mapfile ( > where it becomes a layer with symbologies, scales, etc all defined) > Add the metadata to the mapfile which enables WMS capability ( > WMS version no, WMS layer name, etc) > > > map server is done. > > Now set up a mapserver WMS client: > > Add a layer to the mapfile which has type = WMS > Specify the layer's data source as the URL to the remote mapfile > > > What happens: > > The client sends an XML request to the server: "What have you got?" > (get capabilities request) > > It receives an XML document saying: > I have these layers available. > Info on scales & extent > I can supply these image formats > I support these projections > > The client can then parse this info & interact with the user to specify > which > layers are to be plotted, then the client sends another message (get map > request) to aks for the desired layers to be sent, specifying the region > extent, the current projection required, the scale, etc. > > The appropriate/requested image(s) appropriate are rendered by the server & > sent > to the client which displays them. (WFS can send the data itself, WMS just > the > map.) > > > > Don't confine Sahana developers to a single format, or a single API, but > > allow > > > then to use (as far as possible) any spatial data they want, with any > > > tools/formats. We'll read & support it anyway. > > > > +1 to not confining developers. But we have to assume the worst case as > > well. So what are the chances of having both the API and standard format > > method working hand in hand? Thus, the developer has the choice of > > implementation. And for advanced functionality, you do need the ability > > to break out of the limits. > > Umm... So anything API based will be incompatible with non-Sahana clients. > All > those developing web mapping & web GIS tools are irrelevant and incompatible > with Sahana, which has decided to be different. > > If you look at the OGC standards & what is supported, All Sahana needs in > this > arena are pretty basic, compared to some applications. Before we race down > the > custom API track, I strongly suggest you present a list of all required > Sahana > web mapping functionality & see if any is not met by OGC standards. > > For maps to interoperate you're goung to need full projection & datum meta > data > management & transformation. This is an incredibly complex area, which most > commercial systems & some FOSS ones are less than 100% effective after years > of > development. > > Sorry, but all my 12 year experience with FOSS & commercial GIS tools tells > me > that any attempt to roll your own has a 99% chance of being largely futile. > Sourceforge has many examples of others who've tried. What is left in the > community today is the cream, who managed to get it right. All these, bar > one, > have succeeded by using the same standards & being totally interoperable. > This > is exactly why OGC was set up, & why even the largest commercial providers > are > moving away from local solutions. > > > > > > For example, standard html forms are implemented as a form library in > > Sahana. Developers using these simple set of functions are ensured of a > > standard and consistent look and feel and ease of use for creating > > forms. At the same time, they do have the option of not using the form > > library, and adding html code themselves. So the user has the choice of > > going for ease of use, or customizability, depending on his/her needs. > > Not a problem but have forms which are compatible with OGC. See mapserver > html > templates, & you have a comparable arrangement. > > > > > IMHO, the above case is synonymous to a mapping API, where users can > > either use existing stuff easily, or can use various tools available to > > build in their own spatial functionality. In both cases, data > > will/should be stored in standard formats, that is usable across > > different architectures/tools. > > I'm not sayoing don't do it, but please look at utilising interoperable > systems > & existing libraries as a Sahana "API" before rolling your own. > > > > > Just my 10 cents :) > > > > Cheers > > > > Mifan > > > > > > > > So a mapping module simply presents the data stored in other Sahana > > modules. No > > > need for any map functionality in any other module, unless they want to, > or > > > have specific needs. Just "supported data format = automatically mapable > > data". > > > > > > > > > For example, a camp management module may have it's own mapping > capability > > for > > > data entry, but this goes into data structures which the Sahana map > server > > > module supports, or provides the data via OGC protocols. The generic > > mapping > > > client will still work with it. No need for an API. > > > > > > > > > > > Hope all this makes sense? > > > > > > > > > Cheers, > > > > > > Brent Wood > > > > > > > > > > > > > > > --- Gavin Treadgold <gt...@ke...> wrote: > > > > > > > On 13/08/2006, at 02:42, Mifan Careem wrote: > > > > > > > > >> I would hope that any system Sahana implements for storing & > > > > >> managing spatial > > > > >> features will be able to identify, and hopefully correct, such > > > > >> errors before > > > > >> publishing the data. There are FOSS tools which have this > capability. > > > > > Definitely a must. Understood. > > > > > > > > > > Please advice me on the ideal scenario, so we can think of how-to > > > > > restructure Sahana Mapping for efficient usage, for developers, 3rd > > > > > parties, users, admins etc. > > > > > > > > At a generic level, spatial applications tend to be moving away from > > > > a standalone implementation and are tending to become more integrated > > > > into applications. > > > > > > > > 1. Sahana end user. > > > > I think from a Sahana end user perspective, mapping should not > > > > necessarily be presented as a standalone module (except perhaps the > > > > same as the reporting module that aggregates all the available > > > > reports in the system). A mapping modules may just provide an easy > > > > front end to all maps that are provided by the activated modules. I > > > > am in favour of having mapping capability built into every relevant > > > > module, and designed to suit the module needs. I.e. when creating a > > > > camp, there may be a map view to the right of the form that a user > > > > can browse and click to add the location of the newly entered camp on > > > > the map. When browsing the person registry, you could have a map > > > > display that allows you to limit searches to only the extent of the > > > > map being currently displayed. > > > > > > > > 2. Sahana admin user. > > > > As per the Sahana end users, administration of most mapping > > > > capabilities should be included in the module admin interface and be > > > > integrated with non-spatial configuration options. I think it is > > > > important that all module admin is contained in one place for > > > > consistency. > > > > > > > > 3. Mapserver admin. > > > > The mapserver admin is potentially standalone from a Sahana > > > > installation as the provision and management of the map data on which > > > > Sahana data is overlaid may be on another machine entirely. This is > > > > the interface where new map layers may be added as they become > > > > available, old layers archived. This will not be for managing Sahana > > > > data. > > > > > > > > 4. Mapping API. > > > > The mapping API should make it easy for modules developers to > > > > incorporate maps into their modules, as well as providing a > > > > consistent mapping UI across all modules. The last thing we would > > > > want to see is each Sahana module having different ways of > > > > manipulating and browsing the embedded maps. This is the key way by > > > > which a consistent mapping interface can be embedded in Sahana, and > > > > apply system-wide mapping configuration options etc. > > > > > > > > I hope this is in line with the work that Brent and Wendy are working > > > > on :) > > > > > > > > Cheers Gav > > > > > > > > > ------------------------------------------------------------------------- > > > > Using Tomcat but need to do more? Need to support web services, > security? > > > > Get stuff done quickly with pre-integrated technology to make your job > > easier > > > > Download IBM WebSphere Application Server v.1.0.1 based on Apache > > Geronimo > > > > > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > > > > _______________________________________________ > > > > Sahana-maindev mailing list > > > > Sah...@li... > > > > https://lists.sourceforge.net/lists/listinfo/sahana-maindev > > > > > > > > > > > > > > ------------------------------------------------------------------------- > > > Using Tomcat but need to do more? Need to support web services, > security? > > > Get stuff done quickly with pre-integrated technology to make your job > > easier > > > Download IBM WebSphere Application Server v.1.0.1 based on Apache > Geronimo > > > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > > > _______________________________________________ > > > Sahana-maindev mailing list > > > Sah...@li... > > > https://lists.sourceforge.net/lists/listinfo/sahana-maindev > > > > > > ------------------------------------------------------------------------- > > Using Tomcat but need to do more? Need to support web services, security? > > Get stuff done quickly with pre-integrated technology to make your job > easier > > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > > _______________________________________________ > > Sahana-maindev mailing list > > Sah...@li... > > https://lists.sourceforge.net/lists/listinfo/sahana-maindev > > > > > ------------------------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job > easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > Sahana-maindev mailing list > Sah...@li... > https://lists.sourceforge.net/lists/listinfo/sahana-maindev > |