Inspiration

Crossed off the first one when I saw the track (because I had no idea how to do it), and thought about how to optimize and reconnect. Thought of some random ideas, including online campfire (reconnect), sending location information via flashing lights for rescue (optimize), and forming a decentralized network via Bluetooth to connect in case of disaster (optimize).

But all too vague or technically unreliable abandoned.

Suddenly I thought of the previous Henan rainstorm when I saw a lot of friends begging for proliferation, probably saying that the private spontaneous rescue site - "a location to provide shelter and a light meal" and so on. I even saw such comments on a video that had nothing to do with the storm.

So I realized that this is a current problem: how do the resources of self-organized organizations connect with the people who need help? After thinking about it, I realized that it would be best to match people by geographic location. Imagine it's pouring, there's water everywhere, you're barely sheltering under the eaves: the most efficient way to get help is to turn on your phone and see where you can get help nearby - when it comes to things that need a basis in reality, (real) geography never lies.

So it occurred to me that if I now allowed people to add self-organized private supply points or other relief help in real time, and then made them visible to everyone around them via GPS, that would dramatically increase the positive impact of private goodwill, and dramatically increase the efficiency of private resource allocation.

What it does

  • People who want to help create supply points on it

  • Everyone can see it and book it

  • By choosing to go there, you can follow the route plan and navigation map of the platform. The display of approximate routes and text descriptions saves the most power (conventional navigation is too power hungry for short distance navigation in disaster scenarios)

  • You can book a venue and leave your contact information.

  • You can select your own needs and then automatically match the nearest supplies to your site.

How I built it

  • Frontend functions such as map positioning, display and navigation are implemented through Baidu Map API.

  • Some of the pages are rendered using templates, which is done through Jinjia2.

  • Web server based on Python Flask framework for back-end data interfacing.

  • Using Postgre SQL database for data storage.

Challenges I ran into

Frontend:

- I found some features were not implemented as documented on Baidu's API document: switched from WebGL version API to old JS API to solve.

- Baidu Maps does not support brief information pages: write a template HTML, then replace keywords to generate HTML code, and finally add it to the string input provided by Baidu (as innerHTML reality); achieve the effect I want.

- Baidu Map's asynchronous API are done all with callbacks, which is not convenient: I manually encapsulated a layer of Promise to achieve an elegant asynchronous writing method (when deployed with Babel compilation can solve the compatibility problem)

- Asynchronous data display: by replacing the HTML directly after the data is available.

Backend:

- Heavy architecture at the beginning for Hackathon activities: throw away the rules and let loose in the later stages, and finish it first.

- Material point related data is ugly and inelegant due to too many SQL values (lots of repetitive code): optimize later, make sure it's functional first.

Accomplishments that I'm proud of

  • The ability to create flexible material points is really achieved.

  • Elegantly displaying all kinds of information and providing very power-efficient navigation.

  • You don't even have to pick your own material points, they are automatically matched, saving time and effort.

  • Material Design style user interface, very nice and silky.

What I learned

  • How to do a lot of things with the Baidu Maps API.

  • Hackathon how to get things done under tight time constraints.

  • Deepened my understanding of JavaScript asynchronous mechanism.

  • Deepened my understanding of Postgre SQL databases.

What's next for Live Site Maps

I found out that this is totally not limited to natural disaster scenarios: for example, if you're at school and you've just finished lunch and have nothing to do. You can open it up and see what's going on around you in real time, like a free club music show or a couple of announcements at the ball park that you want to play but there's no one there. You can choose what you want and go straight to it, which is very convenient and efficient. And the bulletin board is very real-time and location-based, so it's less likely to bother you when you're busy.

In other words, I see a future where it's a social app for everything - where everything that's happening in reality can be uploaded and people are welcome to come: everything based on reality, not a fuzzy cyberspace dominated by big data recommendation algorithms.

中文版:

Inspiration

看到赛道先划掉第一个 (因为完全不知道怎么做), 想怎么优化重连. 想了一些随机想法, 包括在线篝火晚会(重连), 通过闪光灯来发送位置信息方便救援(优化), 通过蓝牙组建去中心化网络连起来方便在灾难发生时联系(优化).

但都因为太虚或者技术上不靠谱放弃了.

突然想到之前河南暴雨的时候我看到很多朋友圈求扩散, 大概就是说民间自发的救助站点——“某个位置提供庇护所和简餐” 之类的. 我甚至在内容和暴雨完全无关的视频上看到了这样求扩散的评论.

于是我意识到这是一个目前存在的问题: 自发组织的资源如何和需要帮助的人对接? 经过一番思考后, 我意识到通过地理位置就近匹配是最好的. 设想一下, 下着暴雨, 到处都是积水, 你躲在屋檐下勉强避雨: 这时候最高效率的方式就是打开手机看看附近哪里可以得到帮助——在需要现实基础的事上, (真实的)地理位置永远不会骗人.

因此我进一步想到, 如果现在我允许人们实时添加自发组织的民间物资点或者其他救援帮助, 再通过GPS定位让周围的人都能看到, 那这便可以大幅提升民间好心人积极的影响力, 大幅增加民间资源的分配效率.

What it does

  • 希望提供帮助的人在上面创建物资点

  • 所有人都可以看到并且预约

  • 选择前往可以跟随平台的路径规划和导航图. 通过大致路线和文字描述的展示最大幅度省电 (常规导航过于费电的特性并不适合灾难场景下的短距离导航)

  • 可以预约场地, 留下联系方式.

  • 可以选择自己的需求然后自动匹配离自己最近的物资点.

How we built it

  • 通过百度地图 API 实现地图定位、展示、导航等前端功能.

  • 部分页面使用了模版渲染, 通过 Jinjia2 完成.

  • 基于 Python Flask 框架的 Web 服务器实现后端数据对接.

  • 使用 Postgre SQL 数据库实现数据存储.

Challenges we ran into

前端:

- 对接百度地图API发现部分功能没有做到文档说的实现: 从 WebGL 版 API 换成老的 JS API 解决.

- 百度地图对简要信息页面支持不足: 自己写一个模版 HTML, 然后替换关键字实现生成 HTML 代码, 最后再加到百度提供的字符串输入中 (作为innerHTML现实); 达到我想要的效果.

- 百度地图异步API全都是回调, 用起来不方便: 我手动通过封装一层 Promise 实现了优雅的异步写法 (部署时用 Babel 编译一下就可以解决兼容性问题了)

- 异步数据的显示: 通过等数据到位之后直接替换HTML的方式实现.

后端:

- 开始过于沉重的架构并不适合 Hackathon 活动: 后期扔掉条条框框放飞自我, 先做完再说.

- 物资点相关的数据因为值太多SQL很难看并且很不优雅(大量重复的代码): 后期再做优化, 先保证功能.

Accomplishments that we're proud of

  • 真正做到了可以灵活创建物资点的功能.

  • 可以很优雅地显示各种信息提供十分省电的导航.

  • 甚至可以不用自己挑物资点, 直接自动匹配, 省时省力.

  • Material Design 风格用户界面, 十分好看丝滑.

What we learned

  • 如何使用百度地图 API 做很多事.

  • Hackathon 紧迫的时间下如何做完东西.

  • 加深了对 JavaScript 异步机制的理解.

  • 加深了对 Postgre SQL 数据库的理解.

What's next for 活点地图

我发现这东西完全不止局限在自然灾害的场景下: 比如你在学校中午刚吃完饭, 无事可做. 你可以打开它, 然后看到周围实时进行的活动, 比如一场免费的社团音乐表演或是几个在球场想打球但是缺人的公告. 你可以选择你想要的, 然后直接前往, 十分方便高效. 并且这样的公告牌实时性很强而且基于地理位置, 可以有效减少在你忙时候打扰你.

也就是说, 我看到的它的未来是一款万能的社交软件——各种正在现实发生的事都可以在上面上传, 然后欢迎别人来: 一切基于现实, 而不是摸不着边界、被大数据推荐算法支配的网络空间.

Share this project:

Updates