@Brice_Goedert, don't worry, it was just my interpretation that wasn't right! Your English is great but also feel free to write in your most comfortable language and someone is bound to speak it too. We're a multilingual crowd here!
There are some great comments on the specification. I want to specifically call out one major decision point which is to have a separate map for each form. An alternative would be to have a single map to see data for all forms. @adam.butler said some good things about this that are think are worth bringing up here since it might spark broader conversation:
Form-specific is simpler (both to implement performantly and to use), but I've had requirements for multiple forms on a single map before, and I wouldn't want to foreclose that option.
Can you describe the scenario in a little more detail? How were the multiple forms related? For example, were they different forms for different types of things ("plants" vs "buildings)? What would enumerators do with the map of mixed form data?
My general sense is that once we have a form-centric map view built, it would be trivially easy to do things like add the option to layer on data from other forms. I think the hardest part would be coming up with a good UI to convey what each marker represents. If needed, we could also add a top-level map view that shows points from all forms. There should not be performance issues with this since the geo features will be pulled out in a preprocessing step.
A "general" map view could have a form filter, so that only points from a selected form are displayed.
What do you think of what I've described above which is kind of the inverse of this? The idea would be that you're still in the context of a single form that you're filling but you have visibility into where else you've been.
This doesn't allow for filling different forms. I'm envisioning that this would come in the context of a more entity-based workflow. Again, I think that this form-centric map would be easily reusable in that context.
It's worth considering how devices are configured before real-world data collection takes place; in my experience, a device will often only have one or two forms installed on it, in order to prevent surveyor error (filling the wrong form). In this situation, a general map view could be better, in that it is versatile without being overwhelming. OTOH, I don't know how widespread the practice of removing irrelevant forms is.
For better or worse, my experience suggests that organizations have different workflows around this. Sometimes enumerators work on multiple unrelated data collection campaigns and other times they are focused on one and having just the forms for that campaign is really important. The feature described at Have Collect exactly match the forms on Central is intended to help address the case where having a controlled set of forms and versions is really important. It'd be great to get your impressions there.
It wouldn't be part of this initial feature but that's certainly where I'd like things to go. Would you get value from only seeing the points collected so far on the current device (what this spec is) or is the data preloading you describe essential for you?