depending on where you press and hold on the tiles, your finger can easily block a lot of image. being able to move your finger away would be useful here but when you try to do that the zoom is cancelled

dragging left or right cancels instantly while dragging up and down lets you move a bit (as long as its a perfect straight line, which is hard) but when your finger goes over any of the grid lines underneath its also cancelled

(moved from https://github.com/mapswipe/app-feedback/issues/41)

While browsing tiles, natural patterns can make you wonder what you are actually looking at.

A scalebar, displayed on the upper border for example, could be really useful.

I recently wanted to download a chunk of tiles to help me pass the time on a flight. When I select "Download for later" under a project it first asks me for permission to download without WiFi. After giving the permission the "download for later" button is greyed out and nothing seem to happen. It doesn't seem to matter which package size I select. I kept the phone and mapswipe open for more than 10 minutes and still nothing happened.

I have never been able to download for later.
I have just reinstalled mapswipe and it didn't help.

Create an interactive tutorial in the app for built area and building footprint projects, so that users learn to use the app by actually using it in a guided way. The tutorial will give them prompts of what to do, and provide feedback on their tries, depending on if they did the right thing or not.

The tutorial data will be pulled from the firebase backend like regular projects, but the data structure will also hold an attribute identifying the expected answer.

A mockup of the tutorial is visible at https://invis.io/SCQT6VN6ZJ9
Credit to Mona Yang for the design!

So far, the app hasn't had a fixed versioning scheme. It'd be helpful for deployment (across app stores) as well as for possible debugging if there were fixed versions.

This article goes into some detail and suggests some ways to version React Native applications

• https://medium.com/@andr3wjack/versioning-react-native-apps-407469707661

This relates to the changes introduced in #47 and #48

Not all results are stored in firebase. With the new backend structure the client should store the result for each individual task. Currently only results for tasks are stored, where the user classified as either 1, 2 or 3. Also the 0s (no building) should be stored.

Hello,

It seems this app requests access to Bluetooth devices: https://github.com/mapswipe/yourmapswipe-react-native-app/blob/c198104041810bb1a1eb00f682c1d3946270fb96/android/app/src/main/AndroidManifest.xml#L16
Is this really necessary? I don't really see what functionnality would need to use Bluetooth.

Blinking icons shouldn't be used for people with epilepsy and ADHD

Moved from https://github.com/mapswipe/app-feedback/issues/29

Instagram, facebook etc spread well by invite type mechanisms.

Being able to one click share to friends - "I just helped MSF fight Cholera in X with Mapswipe & MissingMaps" would be a useful tool for inviting new users.

If this ability was only tied to a project after some mapping was done, it would probably balance nicely between obnoxious and useful.

April 2018 will be the end of life for Google Cloud Messaging. We'll need to upgrade to Firebase Cloud Messaging before that.

• https://firebase.google.com/docs/cloud-messaging/js/client

At the moment, results are uploaded one by one at the end of a group. This results in N writes in the database, which trigger at least N function calls on the server to update the user's contribution count.

To minimize network transfers and database updates (which also trigger renderings in the app), the app should upload results in a single write for each group.

The "reward" / "thank you" messages that appear after tapping a few green tiles are great.

Some tasks though have no tile to get tagged green, but still there's effort by the mapper to check that every one of them is either empty (no buildings or roads), a maybe (orange) or the imagery is not readable (cloudy or missing).

This effort should be rewarded in the same or similar way of when the user taps green. Knowing that no buildings are in one area I think it's as valuable as knowing where they are.

(Moved from https://github.com/mapswipe/app-feedback/issues/7)

When 2 or more app users are working on the same group, we have seen cases where one user completes a group and uploads the results to firebase, which triggers a database update on other users' phones who are working on that group.
The app then reloads the screen and resets the group to the beginning, which is less than ideal.

This is due to react-redux-firebase keeping an open connection to firebase RTDB by default (a subscription of sorts) so that the client receives notifications of changes. We don't want that to happen within a group.

This ticket is for documentation mostly, as the fix is already written.

When hitting "Map Further" for a footprint project no news tasks are loaded. It's just the MapSwipe Icon which says loading, but nothing happens.

If you already have an account and you sign in, the app flashes, "Welcome to MapSwipe, " as if to greet you by your username. I think at this stage in the app, the username is undefined somehow so we could fix this up or else rephrase it.

I routinely get the same sets of imagery more than once.

I am only doing the mapping online method.

As you can see in the examples below, the only difference is that one was shown to me at 9:04 and 5 minutes later, probably 2 sets of images later, there is the exact same image. I was taking screenshots for a tutorial so luckily can prove it and not just "I swear I have seen that before... maybe not"

You will also note that they are both at the same % mapped in the set and I can confirm, it was exact the same set after this image.

Hey,
this is an idea how we could increase the information we get out of MapSwipe data. This would increase the value of the work the volunteers are doing and would enable better applications.

Towards a new type of mapping task

At the moment we are mostly mapping the presence of buildings using MapSwipe. This gives us a binary layer of tiles where there are settlements and tiles that are not inhabited. To get more detailed information about the distribution of population (e.g. population density) it would be interesting to explore further ways and new mapping tasks.

• A new simple mapping task could consist of counting buildings.

What would be the improvement:

• We would get more detailed information for each tile.
• our previous work has shown, that tiles for which we detect more than 2 buildings are really "easy". These tasks don't require so many crowdsourced classifications. This would reduce the overall classifications, we therefore might finish projecst faster
• Tasks where volunteers detect only 1 building are more likely to be incorrect. If we would have the information on building count, we could improve the reliability of those tasks by asking more people
• the detailed information per task, could be used also as a better input for automated models, e.g. for building detection using machine learning (we could easily distinguish different types of tasks and provide better training samples. This could increase the quality of machine leaning methods)
• Using building count we would be one step closer to a population density map. Still not perfect, but we would have a better input for spatial sampling methods applied by MSF or other users of MapSwipe data. Also in the HOT Tasking Manager we could prioritize areas using the number of estimated buildings per task.

How could it be done? What would we need to change?

1. Approach: Change nothing, but the description:

• we already save our answer as integer values. Building = 1, Maybe = 2, Bad = 3.
• we could use the same approach of tapping x-times to indicate the number of buildings
• for example tapping once could be referred to as "1 building", tapping twice to "2 buildings", tapping three times to "more than 2 buildings"
• we would only need to change the description that is shown to the users when they start their mapping session
• we would need to think about the classes we are interested in? How many classes do we want?

2. Approach: A new type of input to add the building count:

• whenever a volunteer tapped once to indicate the presence of a building, another input field would be available.
• e.g. by tapping with two fingers you could increase the number of building (there might be more ways to do it)
• or there would be an input field for integer values

3. Approach: A completely new type of interaction to map the building count:

• currently we use tapping as our main interaction, however we might also think about something different
• what about writing a number or symbol with your finger within the corresponding tile (think about how you would solve a sudoku on your smartphone, e.g. tap on the tile and then just write the number with your finger)
• if you would like to classify an image as bad imagery you could just write an "X" with your fingers, for maybe a question mark "?"
• in my opinion this could be really funny, but let's still it would require the most development on the client compared to the other approaches.

Let's start with a test region and prototype

• let's test the effect of such a new approach for a small region, for which we have some reference data (does anyone of the data users has good population density information for a test region we could start with?)
• this could help us to estimate the added value of this approach

So this is just a first idea. I wanted to share it here and foster the discussion, what the next MapSwipe should look like. MapSwipe was built to tackle some of the problems we had towards mapping areas like South Kivu. Let's think about our current problems and how an enhanced MapSwipe could help to solve them.

Best regards,
Benni

Currently MapSwipe requires creating login and password. Missing Maps project is tightly coupled with OpenStreetMap project so it would easier for OSM users if MapSwipe could use OSM login.

(moved from https://github.com/mapswipe/app-feedback/issues/30)

Originally submitted by @Hagellach37

When using the MapSwipe app, users work on a group of tasks. However, when uploading their contributions, individual "results" are saved in firebase. Each result consists of information, which refer to a specific task. Information that a group has been completed by a user are not explicitly stored in firebase as a "group_result" or similar things. Regarding groups, the only thing that happens is that the *CompletedCount" of a group is increased. But, no username or timestamp is added in this step. We therefore can't umambigiously match users and the groups they completed. Here's an example for a result:

To address this issue I propose to save an additional element in firebase: A group_result. This would not affect the existing workflow and could be added in parallel to the existing transfer of the results. This element could look like this:

The results attribute could be an additional place, where we could store the result information for this group.

Adding this new feature would allow us easily derive all contributions of individual users (including "no building" classifications which are not stored in the database), which is an important input to generate more reliable user statistics. Furthermore, we could use the group result to provide feeback to users.

I submitted this bug a while ago.
The problem seems to be here:

its happening a lot where im trying to press and hold to zoom a tile and even the slightest movement ends up triggering a swipe. sometimes it takes a few goes to finally see the tile zoomed which can get frustrating after a while.

if you had to swipe over 5 millimetres or so to activate a swipe it would help cut down on this happening

(copied from https://github.com/mapswipe/app-feedback/issues/40)

Using jest or something equivalent for some key features to prevent major issues and regressions.

The current version is scaled on iPad as the app is build for phones only. Could you release an iPad version with more satellite tiles to tap on every swipe?

Using version 1.3.13, if I finish a build_area group and then go the footprint project, this will crash once I tap on the button of the first task.

Hi,

I recently reinstalled the app on my phone.
I logged in with my account, I was already level 5.
After a few swipes, I see I am back to level 1 with a negative numver of swipes remaining.
Any idea?

HOT has asked about the ability to track which users participate in what project, with the aim to provide more fine grained feedback to corporate partners, which would help increase their engagement.

It looks like it would be the profile, tho an issue with font doesn't allow me to see.

Originally submitted by @Hagellach37

When loading new tasks in MapSwipe users always request a group of tasks. For each project a user will download the group, which has been completed least. I propose to add another attribute "MissingCount" instead, to download the group, which still needs the most contributions.

This would enable us to prioritize specific groups for which we know, that data quality has been an issue. When implementing this change, we could easily add futher iterations to individual groups (e.g. groups with bad quality after 3 passes and therefore further users should have a look at them.). At the same time groups with a high quality would not be affected. Implementing this new feature would therefore help us a lot in addressing MapSwipe data quality issue and would help us to produce more reliable data.

Currently, the following information are stored in firebase for each group of MapSwipe tasks (distributedCount and reportCount are not used.):

This information is requested by the app in this section of the code.

fetch(`${config.firebaseConfig.databaseURL}/groups/` + projectId + '.json?orderBy="completedCount"&limitToFirst=' + groupCount + '')

Finally, when a user completed a group, the information of the respective group is updated. This happens here.

group.completedCount = group.completedCount + 1;

Still it would be good to keep this information. But, we should add another transaction which reduces the MissingCount. E.g. like this:

group.MissingCount = group.MissingCount - 1;

These changes would also affect the project import. However, the required action would be minimal. We just need to set the MissingCount to a start value, e.g. 3 when creating the groups.

I'm having trouble loading map tiles on my device. For reference, here's a screenshot of what I see on my device where instead of overhead aerial photos, I just see blank space.

I've tried a few different things to troubleshoot this so far such as:

• Forcing quit the app and reopening
• Hitting the "Bugs? Clear Project Data"

but neither have resolved this for me.

As a user of the app, I'm happy to try more troubleshooting instructions if you have suggestions.

I didn't see an version in the app to report at all. I'm running an Android device and I can provide more detailed model and OS information if requested.

For the production version.
We could do 2 steps:

• deploy to a limited "testers" group,
• then deploy to all users once the first group has briefly checked that no obvious problems remain.

It'd be good to remove the console.log statements in the codebase because of performance.

It seems like there's a babel plugin that does this automatically at the build stage:

• https://facebook.github.io/react-native/docs/performance.html

This gist should do some if not most of the work toward this:

• https://gist.github.com/mathcass/324f054d14a3d380da0b2265ff9d616d#file-babel-patch-L1162

We started using the rather archaic npm-shrinkwrap.json file but we should really consider migrating to package-lock.json and committing that.

Here,

It seems that we're asking for Phone permissions in the mobile app but I don't see a real need for it.

We should verify that we don't need them and then see about removing them.

If any commands in the prepare.sh script fail, execution continues. It'd probably be better if the script bails as soon as an error occurs.

• https://stackoverflow.com/questions/64786/error-handling-in-bash#69808

This relates to the changes introduced in #47 and #48

I first started to map for Project A, but then stopped it and switched to Project B. I finished Project B and uploaded results to firebase. However, also the unfinished results of Project A have been added to firebase.

Results should only be uploaded, after finishing a group. If you stop mapping halfway, those results should not be uploaded to firebase.

We should be able to preload images while the user is looking at other ones, to make the experience a bit smoother.

This is mostly a tracking issue so we can link commits to something.

The Change Detection (CD) project type allows comparing two sets of imagery (a before and after image) and decide whether changes of some sort (new buildings, flooded areas, deforestation...) are visible.

This is to match the new structure described in mapswipe/python-mapswipe-workers#97

Google has issued a notice that the app will need to work on 64 bit devices. Details of how to verify this are in https://developer.android.com/distribute/best-practices/develop/64-bit

It's likely that we have nothing to actually do.

Deadline is August 1, 2019.

The app should be available in more than just English. We should ideally use https://transifex.com as a translation platform, as it is already the one used by the HOT/OSM communities (for instance for learnosm.org)

There are a few translation libraries for react-native, but none seems like a direct match for transifex.

My first research brought up the following thoughts:

• we could use react-native-language to select the language from the phone's settings
• https://github.com/i18next/react-i18next seems a good candidate for localization, despite a heavy bias towards using locize.com for actual translations. It looks like file formats are compatible with transifex though, so setup should be fairly easy
• https://github.com/yahoo/react-intl is another option, though it looks like it results in very heavy code
• https://ttag.js.org looks cool and plugs into very well established gettext tools, but only has a very small community so far

This relates to the changes introduced in #47 and #48

After finishing a group, I get the same tasks again. This might be related to the changes in the back end. In the back end we should query using the requiredCount attribute.

Groups with the highest requiredCount should be displayed.

Submitted by @ericboucher and copied into public repository

The react-native version is quite old. It is important to update it. It will also be a good opportunity to try and use clean node-modules again.

In particular, we recently tweaked RCTSRWebSocket.m and RCTScrollView.m to work with more recent versions of iOS, which we shouldn't have to do.

Almost all of our iOS users have iPhones 9.3 or up.

...or whatever is most recent at the time.

As #14 has shown, it becomes very hard to maintain RN code when the versions of our main dependencies fall behind the current RN by too many revisions.

facebook produces roughly one big release per month, this ticket should almost be a recurrent one. We should aim to stay within 2-3 "major" versions of their current release at most. As I write this, there are already over 15 versions to go through...

To mimick the behaviour of the original mapper, as right now it is impossible to know how much more work is needed to finish the group.

if a building is right on the border between two tiles then its very easy too miss it from the main screen. they seem to be cropped slightly for some reason

its not a problem in this example since you can see other buildings but its happened in another project where there was a single hut on its own and i would have missed it if i hadnt zoomed in to check

(copied from https://github.com/mapswipe/app-feedback/issues/42)

F-Droid is an android app store for free and open source software.

It would be nice to have your app there, so people who don't want to have google play store on their phone can use it.

Many users are expected to have a slow network connection when using the app. This tends to lead to many bugs that developers often miss as they often use a very high speed connection when developing.

The app development environment (or even better the CI test suite) should include a network speed throttling mechanism, so that developers can easily test the app's behaviour on slow networks.