Tapping on .TPK maps to start from 1 instead of 0

I am trying to number structures by tapping on the ,TPK uploaded in the interviewer app. However, when the interviewer does the first tap, the number that appears first is a 0 instead of a 1, as shown in this image.

Any help will be appreciated

Judging from the image in the documentation under “Manual mode” here, I’m pretty sure that this is a zero-indexed array of coordinates–meaning, the index of the first element is 0, the index of the second, 1, etc. This is pretty common in many programming languages (even if not always intuitive–at least for me).

Thankyou @arthurshaw2002 for your very kind feedback. I understand that the indexing is actually a programming issue where the first element will be 0. The reason I reached out, is because we are creating a frame and the mappers tablet point should reflect the information captured by the lister. The first point on the mapper (tapped on the .TPK map) should be similar to the information captured by the lister (structure listing starts from number 1)

@samwenda , consider changing this post to a feature request.

For my part, I’ve definitely heard this request before. For a project a few years ago, my colleagues and I wanted the same as you.

Why not make every point a separate interview then?

The points are for identifying the structures in the EA during quick count , and they are too many to create a question for each

Hi @samwenda,

we faced a similar problem some time ago and came up with the following implementation in Survey Solutions https://designer.mysurvey.solutions/questionnaire/details/cf198897-b793-4556-adf8-fffe786a5d8d

This questionnaire uses a list question in combination with the map question as you are planning to use it. The list question is for the “IDs” and is designed to start with 0. It worked quiet well in the field, and the location accuracy is significantly better than with the regular tablet GPS, if enumerators are well trained.

One problem in this workaround however is, that if enumerators delete list elements in-between, than the whole enumeration is messed up. For this reason it is important, to emphasize in the training, that under no circumstances enumerators should delete individual list elements.

@arthurshaw2002 Extending on your thought of a feature request, i think an even more interesting feature in this regard could be a map question which generates a roster row for each point set on the map, because this would connect the two different instances and make household listing a fairly easy and precise task.

Update: this is certainly not a solution for the numbering inside the map questions, but i was assuming you are intending to collect additional information for each point.

1 Like

Glad this was implemented as attached. thanks to the survey solutions team.


Thank you @samwenda , but I believe this was not an intended change, but rather a change in underlying components used by Survey Solutions, which are responsible for this numbering.

I see that there is additionally the rotate/distort functionality present, which was not intended:

If you had any processes tied to the points numbering, be aware that the numbering may have shifted, and e.g. the interviewers referring in the past to point 1 will now need to look at point 2.

Yet another reason not to tie any logic to the points numbering. Instead use multiple interviews and a map dashboard view.