diff --git a/.nojekyll b/.nojekyll new file mode 100644 index 0000000000..e69de29bb2 diff --git a/404.html b/404.html new file mode 100644 index 0000000000..2741810526 --- /dev/null +++ b/404.html @@ -0,0 +1,1068 @@ + + + +
+ + + + + + + + + + + + + + + + +It started as Ivan's idea to build FMTM (Ivan Gayton is Senior Humanitarian +Advisor at Humanitarian OpenStreetMap Team) which then became a collaborative +project with the efforts of Ivan, Rob Savoye who is Senior Technical Lead at +Humanitarian OpenStreetMap Team and many other members from HOT as well as +volunteers interested in the project.
+HOT uses ODK heavily, but most of the data never makes it into OSM because all +the data processing is manual and slow, so it doesn't get done.
+Ivan Gayton (Senior Humanitarian Advisor at Humanitarian OpenStreetMap Team) +heard about what Rob was working on and goes "That's the missing piece I +needed!". He'd been wanting to build FMTM for years, but lacked the ability to +process the data.
+A webinar then took place in September 2022 +that showcased the high interest from the community and the need for +collaborative field mapping that really kicked off the starting point for +building the Field Mapping Tasking Manager.
+Want to know about OSM-Fieldwork project? click here
+The Field Mapping Tasking Manager (FMTM) is a project that aims to provide tools +for coordinating field mapping activities in Open Mapping campaigns. While +there are existing field mapping applications, there is a lack of efficient +tools to coordinate these activities. The FMTM builds on the HOT Tasking +Manager and other mapping applications to provide a more streamlined and +organized process for completing mapping tasks.
+Currently, it is possible to implement a Field Mapping Tasking Manager workflow +using existing tools, but it requires significant effort and can be challenging.
+The FMTM project is developing automation features to address these challenges +and make the process more accessible to users.
+By providing a centralized platform for organizing and managing mapping tasks, +assigning them to specific users, and tracking their progress, the FMTM aims to +simplify the coordination of mapping activities. The tool also provides +analytics and reporting features, allowing users to gain insights into mapping +campaigns and adjust their strategies accordingly.
+Background and description of the project and idea are +here: please have a look at this blog if you haven't yet!
+The FMTM project is open source and community-driven, welcoming contributions +from designers, user testers, and both front-end and back-end developers. If +you're interested in getting involved, please see our +contributor guidelines +for more information. We welcome questions and feedback, so don't hesitate +to reach out to us. 👍🎉
+ODK's Select From Map feature is a useful tool for field mappers to +collect data in a well-structured questionnaire format. The tool was +incorporated into ODK in mid-2022 and allows mappers to select an object from a +map, view its existing attributes, and fill out a form with new information +and attributes.
+To prepare map files for ODK, inspiration is taken from the HOT Tasking Manager, +which allows remote mappers to choose well-defined small "task" areas, ensuring +full coverage of the project area and no unintended duplication of tasks. For +example, a mapper can approach a building, select that building from a map +view within ODK on their mobile phone, and add the opening hours, number of +floors, construction material, or any number of useful attributes in a +well-structured questionnaire format
+To prepare the appropriate map files for ODK, we are taking our inspiration from +the HOT Tasking Manager, which allows remote +mappers to choose well-defined small "task" areas, ensuring full coverage +of the project area and no unintended duplication of tasks.
+There are three main user roles for using ODK's Select From Map feature: +campaign managers, field mappers, and validators.
+Campaign managers select an Area of Interest (AOI) and organize field mappers +to go out and collect data. They need to:
+ +Field mappers select (or are allocated) individual tasks within a project AOI +and use the ODK mobile app to gather data in those areas. They need to:
+Validators review the data collected by field mappers and assess its quality. +If the data is good, the validators merge the portion of the data that +belongs in OpenStreetMap to OSM. If it requires more work, the validators +either fix it themselves (for minor stuff like spelling or capitalization +mistakes that don't seem to be systematic) or inform the field mappers +that they need to fix it. They need to:
+For this visit the Getting Started Page
+ +First off, We are really glad you're reading this, because we need +volunteer developers to help improve the Field Mapping Tasking Manager (FMTM)! +
+We welcome and encourage contributors of all skill levels, and we are committed +to making sure your participation is inclusive, enjoyable, and rewarding. If +you have never contributed to an open source project before, we are a good +place to start, and we will make sure you are supported every step of the way. +If you have any questions, please ask!
+You can see an overview of the project and the process we have gone through in +developing FMTM so far in these +slides
+Furthermore, there are many ways to contribute to the +Field Mapping Tasking Manager (FMTM), which includes:
+Right now, we are in the process of building the prototype. We warmly welcome +your input in testing and sharing your feedback. If you are also interested in +coordinating a field testing session, please reach out!
+Create pull requests (PRs) for changes that you think are needed. We would +really appreciate your help!
+Skills with the following would be beneficial:
+Our latest task board can be found +here.
+The issue queue is the best way to get +started. There are issue templates for BUGs and FEATURES that you can use, you +could also create your own. Once you have submitted an issue, it will be +assigned one label from the following +label categories. +If you are wondering where to start, you can filter by the +good first issue label.
+Thank you very much in advance for your contributions!! Please ensure you refer +to our Code of Conduct. +If you've read the guidelines, but are still not sure how to contribute on +Github, please reach out to us via our Slack #geospatial-tech-and-innovation.
+We operate the "Fork & Pull" model explained at About Pull Requests
+You should fork the project into your own repo, create a topic branch +there and then make one or more pull requests back to the repository. +Your pull requests will then be reviewed and discussed by other +developers. Don't submit a Pull Request while still developing the +code, wait till the feature is complete and ready for review. A +preliminary review by other developers can be requested via the +comments for the issue on github, or via slack or email.
+It is preferred that all patches contain any documentation +updates made, and for any new features, a test case is preferred when +possible. Keep patches focused on a single feature to avoid merging +complications with other developers. The old free software joke is +"patches are better than bug reports" is how we contribute to the +community of people involved with this project.
+Project documentation should be in Markdown format, and in a docs +subdirectory. While it is possible to use HTML in Markdown documents +for tables and images, it is preferred to use the Markdown style as +it's much easier to read.
+See a detailed guide on documentation contributions +here.
+Python enforces a certain amount of style due to indent levels. Unlike +C/C++, we don't have to worry about curly braces. It is preferred that +all code follows object oriented techniques, with a minimal amount of +code other than basic control in the main function. This allows code +to be easily reused and run either standalone, or part of a REST API +backend. Code that is not designed to be run standalone can have a +main function to do simple testing during development. That test code +should be moved to a standalone test case when possible. +Pytest is used as the test framework for +standalone test cases.
+Code follows a CamelCase +style. Classes use an Upper Case for the first word, method use a +lower case for the first word. Variable names are all lower case with +an underbar as a word separator. Properly naming everything makes it +much easier to read the code and get an idea of what it is doing. This +enables people new to this project to contribute easier.
+All methods should have a comment that can be used by +pydoc. The usage of +base classes is encouraged so functionality can be shared. Comments in +the code are encouraged when necessary to explain code that may not be +obvious, but avoid over commenting as well. Code should be able to be +read like a book, with descriptive names used, no fancy tricks unless +required. Always be conscious of performance and security.
+