Open Map Yamama Dagash & Haitham Khateeb under the supervision of: Benny Daon & Eyal Levin Open Map

Agenda Goals Scope Methodology Milestones Development environment Risks Deliverables Open Map

Goals Our goal is to build a platform that: o help local authorities adhere to the law and publish environmental data o enables people to get this information o support future extensions though layers and open API Open Map

Scope Build a cloud service that will: o Host multiple layers of geo-tagged information o Allow time-based information o Allow authorized user to publish verified information o Support a full RESTful API Develop a simple, web-based client o Will display the information over a detailed map Open Map

Methodology Open sourced under the BSD license Iterative - launch a first site within 30 days and upgrade it every two weeks. Have a bi-weekly meeting to present the latest and decide on the next iteration Use open source code packages - don't develop what's already available Test Driven Development with coverage of at least 80% Extensive Documentation in Wiki + Automatic Document Generation from Code & Developer Comments Open Map

Milestones Learn Python, jQuery, Django framework, and new technologies First version is up (expected date: 1/5) planning game in Tzofen's yearly conference (24/5)planning game basic requirements and at least one ticket (1/7) Open Map

Development enviroment git & github services for version control and code review Redmine for tracking tickets and wiki-based docs (sample) sample Schemeless, geo enabled document base such as mongodb Django based server for keeping user information jQuery based client Jenkins (formerly hudson) continuous integration server to run tests and monitor testing coverage OpenStreetMap / Google maps for base map layers Open Map

General Risks main risk is an inaccurate definition of the project. which might delay us with starting the work. or starting based on vague information. solution: avoid starting before having exact definition and design of the project. second risk : not having data available in time. for example the map, the environmental data. solution : start achieving the data as early as possible. Not Future Ready: The system is designed such that it is difficult to add features in the future. The advantage may be low efforts and low cost in the start of the project, but this will end up costing more in the long run. Solution: Keep it simple. If a feature is not required now, don't develop it yet (but do take into account when developing API's, and allow empty stub functions). Open Map

Specific Risks Protocol Bloat (causing both high traffic, slow transfers, and increase processing times): We should refrain from using "fat" protocols such as XML. The preference is to use more compact protocols such as JSON or the likes. The advantage being that objects arrive as objects, and do not require any parsing beyond what the browser already does on its own (data is "natural"). "Hard" Data Structures (difficult to change later): We need to make sure we support an infinite amount of layers, with infinite data types. We need to make the layers themselves something dynamically managed in a separate table (not hard coded). Layer profiles should also be possible, with a default profile defining which layers appear by default to a new visitor. Allow the user to define his own set of layers, and give it a name. Bad planning for bottlenecks (causes heavy loads on servers, and a bad user experience): When data is accessed very frequently, and the "search key" is simple enough to produce a textual hash, consider storing this data on a filesystem instead of using a database. In this manner, the distance from the web server to the data is very short and bypasses any language interpreters. Furthermore, the files can be cached in memory, or even stored on a CDN, without requiring complex mechanisms for lookup/retrieval. Proper expiration headers can be set in the HTTP headers, to allow extensive caching on the client side (lowering amount of access to our servers, and improving user experience in general). Usage of "strange" technologies: As much as possible, the project should use common/popular technologies that are less likely to "expire" next year. When you decide to use a component, think about its survivability. Is it following the "Unix" ideology? (small component that does its job very well, and doesn't try to do things it's not supposed to do?).

Deliverables Demo site that actually works and helps authorities adhere to the requirements as defined by law Well documented open issues A roadmap for future versions Bonus - implement with one "early adopter" (preferably a local municipality, yet to be located) Open Map

Questions? Open Map

Thank you Open Map