كلما تعمقت في @vangrid_io، كلما شعرت أن جوهره الحقيقي هو طريقة ربط "احتياجات البيانات" بـ"الأشخاص الراغبين في جمعها". تخيل سيناريوًا بسيطًا جدًا. شركة ما ترغب في تعليم روبوتات التنقل داخل مراكز تجارية أو مستودعات أو أحياء في مدينة معينة. ما قد تفتقر إليه ليس بالضرورة 100,000 صورة إضافية على الإنترنت. ربما تحتاج فقط إلى بيانات مكانيّة على مستوى الأرض، من موقع معين، في وقت معين، ضمن بيئة معينة. في هذه الحالة، يواجه التجميع الحر للمستخدمين مشكلة. فالناس سيذهبون دائمًا إلى الأماكن التي يسهل الوصول إليها. المناطق التجارية المزدحمة يُصوّرها الناس. المركز الحضري يُصوّر. المواقع السياحية تُصوّر. وبالتالي، ستتجمع البيانات بشكل متزايد في الأماكن التي كانت بالفعل سهلة الوصول إليها. إن نهج Vangrid هو "التجميع المُعين". يمكن للمُطلب (Requester) طلب موقع محدد، وتقديم مكافأة (Bounty)، حيث يتم تجميد الأموال في حساب ضامن (Escrow). بعد رؤية الطلب، يمكن للمُساهم (Contributor) الذهاب إلى الموقع وجمع البيانات بنفسه. بعد التسليم، إذا قبل المُطلب البيانات، يتم إصدار المكافأة فقط حينها. أبرز ما في هذه الآلية هو أنها حوّلت: "أين يوجد الناس" إلى "أين توجد فجوات حقيقية في البيانات" وحتى جعلت التغطية (Coverage) متغيرًا يمكن للشبكة تعديله تلقائيًا. لأنه إذا كانت هناك منطقة ذات بيانات قليلة، فإن رفع مكافأة جمع البيانات هناك قد يشجع المُساهمين على قضاء الوقت للذهاب إليها. إذًا، ما تسعى Vangrid لبناءه هو دورة ملموسة جدًا: شخص يحتاج بيانات → ينشر طلبًا → يقدم مكافأة → شخص ما يجمع البيانات → تُسلّم البيانات → تُطلق المكافأة وهذا بنية اقتصادية مختلفة تمامًا عن مجرد تشجيع الناس على "التقاط المزيد من الصور". أعتقد أن هذا أيضًا أحد المشكلات التي غالبًا ما يتم تجاهلها في شبكات البيانات المكانية. وجود كمية كبيرة من البيانات لا يعني بالضرورة توزيعًا منطقيًا لها. في كثير من الأحيان، تكون البيانات ذات القيمة الحقيقية موجودة في الأماكن التي يتجنب الناس زيارتها خصيصًا. والمكافأة (Bounty) هي ما تحلّه: "لماذا عليّ أن أذهب خصيصًا إلى هناك؟"