[Guest post by Francesco Bartoli. Francesco is the founder at Geobeyond Srl and a geospatial technologist who fosters innovation technology to Geographic Information System and Spatial Data Infrastructure. He is advocate of Open Source, Open Government, Open Data development where also acts as OGC standards and INSPIRE advisor to assisting business programs at largest extent of interoperability and cooperation.]

Participating in a conference call among the core developers of a very interesting project such as Ushahidi is not only an honor but also a stimulus to actively interact. The spirit behind developers and maintainers of initiatives based on this platform is so full of willingness that you can never back down. Being the promoter of the GeoAvalanche project means to have a clear idea of what can be significantly decisive for the goals we have set ourselves to achieve. Despite knowing of course that new features must necessarily accommodate common needs. So I said, "let's try to throwing some new ideas". Of course considering the current developments and the features already implemented along the various sub-components. The responsiveness which animated the discussion was surprising and writing this explanation is needed to figure out the concepts and scenarios of a their possible implementation. I'd like here below to dig out two use cases identified during the call that I consider quite interesting for all installations of Ushahidi in which different organizations have to operate on the same platform. In particular, when having to deal with the verification, validation and visualization of disjointed geographic territories. But what does it mean in practice? What would be the more benefits for the user to grips with the operations management on the Ushahidi platform? Let me explain it with two simple examples that then can be translated into practical sequence diagrams. In the first case, imagine having to give permission to each national authority for managing reports that are located only within its own borders of competence. This is the case of GeoAvalanche: the platform gathers the snow avalanche reports all over the world but then only the national avalanche service of each country is in charge of the reliability for the information. This ownership is to be only claimed on those geographic informations falling within its specific national territory. So it comes to distinguishing the administrator user depending on the country where it is authorized to operate. We will see then technically how this concept can be extended to a generic geographical area. In the second case let's consider if you want to provide different small scale representations of the same larger phenomenon depicted on several portions of geographical territory by hosting such information on the same Ushahidi server and publishing them across maps of the different portions all together with corresponding dots over third-level domains of the main website. Let's have a look at an example: we need to map the phenomenon of illegal landfills in some provinces and at the same time we are receiving funds by each of them for providing a custom view on their territory accessible on the web according to a pattern like this:

• roma.wasteabuse.com
• milano.wasteabuse.com
• venezia.wasteabuse.com

etc. Certainly you could also proceed with separate installations on the same server, but this would imply the use of disjoint database of the overall phenomenon. This doesn't mean, however, that it is a way ever acceptable with certain pros and cons in some use cases. It is evident how the two abovementioned cases may also collide with a relevant challenge in which we can blend both requirements. We will call these two modus operandi as GeoRole and MultiSite: GeoRole is an geometric extension of a generic role in which the user is constrained to operate only on those reports that are included in the geometric property defined for that, so as exploiting a spatial constraint of inclusion. It is more likely that it is always a polygon (thereby avoiding the trivial cases as points and lines) and that can be declared simply from a geometric element of a shapefile or a GeoJSON. This solution also generalizes the case where the geometry is not exactly a nation but may represent a geographic shape of generic type. MultiSite should be an extension of the main view with its configuration (for example at least the administration of the map visualisation) where you can configure each individual virtual host and the related geographic extent in which it has to operate. Even in this case the geographical boundaries can be loaded from a kind of format among those mentioned previously. With regards to the first example each province could therefore benefit from its own custom view. Subject to the provision for mapping the global phenomenon that would remain in control of categories and input forms. Just wanting to express everything with simple sequence diagrams then we have that: These two situations are quite interesting in different contexts from a business requirements' perspective and able to meet the needs of projects with worldwide scope. If the first one is controlled through the assertion in the model of a geometry type field that simply overrides the privileges associated to a specific role with slight impact on the logic for managing with the report, the second one requires a more extensive assessment with core developers for clarifying the impact in term of MVC pattern. A good time to discuss will be definitely the next monthly call for developers where unfortunately I can not attend. However, I had good feelings when reading the post about the 3.0 version what makes me confident of a possible integration in time not too far away. In this regard, the team behind the scene of the GeoAvalanche project is certainly available to support somehow these developments. Previous posts by Francesco: Mapping Avalanche Incidents by Capturing Information from the Crowd