Feedback from Rwanda Building Assessment

[spwoodcock]

Feedback

Rwanda building assessment

• It appears that the data (Tags : Keys and values) did not adhere to proper protocols and documentation, as it did not conform to the tag scheme on the OpenStreetMap (OSM) database.
• The uploaded data raised several issues that required cleaning up.
• The search function in FMTM is not working effectively, either by using project ID or by name to locate a particular project. I suggest referring to the HOT Tasking Manager for a clearer understanding of this issue as it makes it impossible to redirect to the data source and anyone with no knowledge of the project might not be able to verify the source.
• We need to develop a protocol and documentation to submit to the team responsible for the OSM database. This will address conflicting issues that arise from the current upload. Tags' keys should conform to the length of characters and symbols, among other standards.
• It is essential to develop a protocol and documentation, such as the fmtm_id, which will serve as a primary key in uploading data to the OSM database. This process requires adding tag schemes to OSM.
• Local knowledge needs to be added as part of the changeset not as key and values, as the current data conflicts with the OSM tag scheme.
• I propose using a unique scheme key that automatically picks FMTM as the source and includes the project ID (e.g., FMTM07). This will help uniquely identify projects in FMTM which will work if the first point I raised here is fixed, especially when multiple projects share the same name.
• Features should be designed with or include the OSM ID to ensure compatibility with existing data and the data to be uploaded as that will serve as a merging Key between FMTM data and Existing Data on OpenStreetMap Database.
• I have made changes to the keys and values in the uploaded data to ensure conformity with the tagging scheme. This includes ensuring the length of characters, using underscores, dashes, full stops, and other conventions that align with the OpenStreetMap database.

You can follow and monitor my progress on the data cleaning using this Changeset link, or follow some of our discussion here.

Follow up
The process presented some challenges that slowed our progress as planned from 1 day to 2 days.
Despite this, we gained valuable insights into data importing, cleaning, and fixing issues.

One notable challenge we encountered was with keys like "select_feature-x_location," which exceeded 255 characters. These were rejected by the OSM database as bad data, prompting us to remove them entirely. Also, we identified numerous white spaces in the values, likely stemming from errors during data collection. We diligently cleaned these before uploading as it was preventing upload.

To track our progress, we used the hashtags #FMTM #FMTMDataCleaning #FMTMDataImporting during uploading. I included "For Any Clarification contact Username:KingVik" to ensure transparency and avoid any misunderstandings regarding the new tags used in FMTM as it is new to OpenStreetMap database and some users might mistaken it and block my fellow volunteers account thinking it was a mistake but by redirecting to me and checking my contribution profile, anyone will understand it is for a purpose.

Comment

@susmina94 @manjitapandey for future reference, we can create issue/tasks from this feedback.
Some of the issues may have been solved already, e.g. the project searching.
But most of the feedback about the output from FMTM needs to be addressed at some point.
We can use this thread to discuss.

[spwoodcock]

• These issues will be addressed when osm-fieldwork & conflator code are used to map ODK values to OSM tags nicely.
• The feedback about tagging with the project_id has been implemented.
• Now by default the project is always tagged with {domain}-{project_id}, for example fmtm.hotosm.org-90.
  • This allows for tagging on prod/stage/dev, or other instances operated under different domains.