SAVITR：微博紧急情况下的实时位置提取系统

challenging since geo-tagged tweets are very sparse, especially indeveloping countries like India, accounting for only 0.36% of thetotal tweet traffic. Hence it becomes necessary to extract locationsfrom the text of the tweets. This work proposes a novel and fastmethod of extracting locations from English tweets posted duringemergency situations. The location is inferred from the tweet-textin an unsupervised fashion as opposed to using the geo-taggedfield.Note that several methodologies for extracting locations fromtweets have been proposed in literature; some of these are discussedin the next section. We compare the proposed methodology withseveral existing methodologies in terms of coverage (Recall) andaccuracy (Precision). Additionally, we also compared the speedof operation of different methods, which is crucial for real-timedeployment of the methods. The proposed method achieves verycompetitive values of Recall and Precision with the baseline meth-ods, and the highest F-score among all methods. Importantly, theproposed methodology is several orders of magnitude faster thanmost of the prior methods, and is hence suitable for real-time de-ployment.We deploy the proposed methodology on a system available athttp://savitr.herokuapp.com, which is described in a later section.16430SAVITR：一种用于紧急情况下从微博中实时提取位置的系统0Ritam Dutt 计算机科学与工程系印度理工学院卡拉格普尔分校，印度ritam@iitkgp.ac.in0Kaustubh Hiware 计算机科学与工程系印度理工学院卡拉格普尔分校，印度hiwarekaustubh@iitkgp.ac.in0Avijit Ghosh 化学与金融工程系印度理工学院卡拉格普尔分校，印度avijitg22@iitkgp.ac.in0Rameshwar Bhaskaran 计算机科学与工程系印度理工学院卡拉格普尔分校，印度rameshwar.cs@iitkgp.ac.in0摘要0我们提出了SAVITR，这是一个利用Twitter微博网站上发布的信息来监测和分析紧急情况的系统。鉴于只有极小比例的微博带有地理标记，因此对于这样的系统来说，从微博文本中提取位置是至关重要的。我们采用自然语言处理技术以无监督的方式推断微博文本中提到的位置，并在基于地图的界面上显示出来。该系统设计高效，达到了0.81的F-score，并且比其他可用的位置提取工具快两个数量级。0CCS概念0•  信息系统  →  信息检索；0关键词0紧急情况，微博，位置提取，Geonames0ACM参考格式：Ritam Dutt，Kaustubh Hiware，AvijitGhosh和RameshwarBhaskaran。2018年。SAVITR：一种用于紧急情况下从微博中实时提取位置的系统。在WWW'18Companion：2018年网络会议伴侣，2018年4月23日至27日，法国里昂。ACM，纽约，美国，7页。https://doi.org/10.1145/3184558.319162301 引言0在线社交媒体网站，尤其是微博网站如Twitter和Weibo，已被证明对于实时收集情境信息非常有用[9,16]。因此，不仅需要实时处理庞大的输入数据流，还需要准确地从非结构化和嘈杂的数据中提取相关信息。从推文（微博）中提取地理位置尤为重要，因为位置有助于将在线可用信息与实际位置相关联。这项任务具有挑战性，因为带有地理标记的推文非常稀少，尤其是在印度等发展中国家，仅占总推文流量的0.36%。因此，从推文文本中提取位置变得必要。本文提出了一种从紧急情况下发布的英文推文中无监督地提取位置的新颖快速方法，而不是使用地理标记字段。请注意，文献中提出了几种从推文中提取位置的方法；下一节将讨论其中一些方法。我们将所提出的方法与几种现有方法在覆盖率（召回率）和准确性（精确度）方面进行了比较。此外，我们还比较了不同方法的操作速度，这对于方法的实时部署至关重要。所提出的方法在召回率和精确度方面与基线方法具有非常有竞争力的值，并且在所有方法中具有最高的F-score。重要的是，所提出的方法比大多数先前方法快几个数量级，因此适合实时部署。我们在http://savitr.herokuapp.com上部署了所提出的方法，该方法在后面的章节中进行了描述。0本文发表在知识共享署名4.0国际许可证（CC BY4.0）下。作者保留在个人和公司网站上传播作品的权利，并附上适当的归属。WWW'18Companion，2018年4月23日至27日，法国里昂，©2018IW3C2（国际万维网会议委员会），根据知识共享CC BY 4.0许可证发布。ACM ISBN978-1-4503-5640-4/18/04。https://doi.org/10.1145/3184558.319162302 相关工作0我们讨论了一些现有的用于紧急情况下的信息系统，以及一些从微博中提取位置的先前方法。02.1 紧急信息系统0一些信息系统已经在各个国家实施，用于紧急信息学，并且它们的效果已经在各种情况下得到了证明。在日本，[17]使用Twitter用户作为社交传感器部署了实时地震检测。在印度金奈市的2015年洪水期间，像金奈洪水地图[3]这样的简单系统证明了信息系统的需求和效用。该系统结合了众包、开源地图技术，并促进了大规模的公民参与。同样，Ushahidi[1]是一家非营利性危机地图软件公司，利用众包的概念进行社会行动和公共问责。它使当地观察员能够使用他们的手机或互联网提交报告，从而创建一个正在进行事件的时间和地理空间档案。Ushahidi已经在海地的地震、智利的地震、意大利和俄罗斯的森林火灾等情况下部署。本研究开发的系统与上述系统的基本原理相同-从众包数据中提取信息。然而，与Mapbox [3]和Ushahidi[1]不同的是，用户不需要明确指定位置。相反，我们从推文文本中推断位置，而无需任何先前的手动标记。0Track: 利用社交媒体进行紧急救援和准备 WWW 2018，2018年4月23-27日，法国里昂Location inferencing is a specific variety of Named Entity Recogni-tion (NER), whereby only the entities corresponding to valid geo-graphical locations are extracted. There have been seminal worksregarding location extraction from microblog text, inferring thelocation of a user from the user’s set of posted tweets and evenpredicting the probable location of a tweet by training on previ-ous tweets having valid geo-tagged fields. Publicly available toolslike Stanford NER [7], TwitterNLP [15], OpenNLP [2] and GoogleCloud1, are also available for tasks such as location extraction fromtext.We focus our work only on extracting the locations from thetweet text, since we have observed that (i) a very small fractionof tweets are geo-tagged 2, and (ii) even for geo-tagged tweets, atweet’s geo-tagged location is not always a valid representative ofthe incident mentioned in the tweet text. For instance, the tweet“Will discuss on TimesNow at 8.30 am today regarding Dengue Feverin Tamil Nadu.” clearly refers to Tamil Nadu, but the geo-taggedlocation is New Delhi (from where the tweet was posted).We give an overview of the different types of methodologiesused in location extraction systems. Prior state-of-the-art methodshave performed common preprocessing steps like noun-phraseextraction and phrase matching [12], or regex matching [6] beforeemploying some of the following techniques for location extraction.3https://spacy.io/4http://www.cs.cmu.edu/ ark/TweetNLP/Track: Exploitation of Social Media for Emergency Relief and Preparedness WWW 2018, April 23-27, 2018, Lyon, France16440位置推断是一种特定类型的命名实体识别（NER），只提取与有效地理位置相对应的实体。关于从微博文本中提取位置的工作已经有了开创性的研究，从用户发布的推文集合中推断用户的位置，甚至通过训练先前具有有效地理标记字段的推文来预测推文的可能位置。公开可用的工具如Stanford NER [7]、TwitterNLP [15]、OpenNLP[2]和Google Cloud1也可用于从文本中提取位置等任务。我们的工作仅关注从推文文本中提取位置，因为我们观察到：(i) 微博只有很小一部分是带有地理标记的2，(ii)即使对于带有地理标记的微博，微博的地理标记位置并不总是推文文本中所提到事件的有效代表。例如，推文“今天上午8点30分将在TimesNow上讨论有关泰米尔纳德邦登革热的问题。”明显是指泰米尔纳德邦，但地理标记位置是新德里（推文发布地）。我们概述了用于位置提取系统的不同类型的方法学。先前的最先进方法在使用一些以下技术进行位置提取之前，执行了常见的预处理步骤，如名词短语提取和短语匹配[12]，或正则表达式匹配[6]。02.2 位置推断方法0•地名簿查询：[12]、[13]和[8]采用了地名簿查询和n-gram匹配。通常使用一些公开可用的地名簿，如GeoNames或OpenStreetMap。•  [12]和[8]采用了手工规则。•监督方法：在当前情境中使用的一些知名监督模型有：(1)基于条件随机场（CRF）的模型，如StanfordNER解析器，被[8]和[12]采用。[8]在推文文本上训练了模型，而[12]则在没有训练的情况下使用了解析器。(2)基于最大熵的模型，如OpenNLP，被[11]在没有训练的情况下使用，并使用ME推断位置。•半监督方法：[10]使用了半监督方法，如波束搜索和结构感知器，对序列进行标记，并将其与相应的Foursquare位置实体链接起来。01 https://cloud.google.com/natural-language/ 2注意，在带有地理标记的推文中，位置是由用户明确提供的，作为一个单独的字段，无论它是否出现在文本中03 从微博中提取位置0我们现在描述从推文文本中推断位置的提出的方法。该方法涉及以下任务。03.1 标签分割0在Twitter中，标签是一个相关的信息来源。特别是在紧急情况下发布的推文中，标签通常包含嵌入其中的位置名称，例如#NepalQuake，#GujaratFloods，#puertorico，#HoustonStrong，#MumbaiRains。事实上，观察到在与洪水、地震和雨有关的一些最近紧急事件中发布的100个最常见的标签中有多达21个有效的位置。然而，由于标签的独特造词风格，将它们分解为有意义的单词变得必要。与[12]和[5]类似，我们采用基于统计的词分割算法[14]将标签分解为不同的单词，并从这些单词中提取位置。我们还保留原始标签，以确保我们不会因为它们不常见而失去有意义的远程位置。我们观察到标签分割有一些意想不到的结果。在尝试从推文中优化召回率时，它会影响精确性，特别是当分割的单词对应实际位置时。例如，'＃Bengaluru'（印度的一个地方）被分解为'bengal'和'uru'，它们是印度的另外两个地方。同样，乌干达的一家医院'＃Kisiizihospital'在推文中“我们已经派遣设备到＃Kabale和＃Kisiizihospital，作为最近灾害的紧急干预措施”中被错误地分割为'kissi'和'zi'，这两个都不是位置名称。尽管标签分割存在这些限制，但我们仍然进行这一步骤，因为我们希望提取所有可能的位置名称，包括那些嵌入在标签中的位置名称。03.2 推文预处理0我们对推文文本进行了常见的预处理技术，以删除URL、提及、括号、'RT'、#、&、省略号和与表情符号对应的特定Unicode字符，如图1所示。我们还将驼峰式单词和联合字母数字术语（如'Chennai2015'）分割成不同的术语（'Chennai'和'2015'）。我们没有对文本进行大小写转换，因为我们想检测专有名词。同样，我们也避免了词干提取，因为位置名称可能会被改变，无法使用地名词典进行检测。03.3 从解析树中消除专有名词的歧义0由于大多数位置名称可能是专有名词，我们使用一种启发式方法来确定专有名词是否是位置。我们首先应用词性标注器生成词性标签。有几种公开可用的词性标注器可以应用，例如SPaCy3，专为Twitter设计的CMU TweeboParser4等。我们选择SPaCy的词性标注器，而不是CMUTweeboParser，是因为后者的处理时间较长。5https://en.wikipedia.org/wiki/List_of_landforms6https://wiki.waze.com/wiki/India/Editing/Roads7http://www.haringey.gov.uk8https://en.wikipedia.org/wiki/List_of_building_types9https://en.wikipedia.org/wiki/List_of_epidemics10https://en.wikipedia.org/wiki/Lists_of_disastersTrack: Exploitation of Social Media for Emergency Relief and Preparedness WWW 2018, April 23-27, 2018, Lyon, France16450TweeboParser比SpaCy慢1000倍。我们认为速度对于准确性来说是一个可行的权衡，因为我们希望该方法能够实时部署，并且我们观察到处理时间将成为一个瓶颈。设T_i表示推文中第i个单词w_i的词性标签。如果T_i对应一个专有名词，我们会继续追加后续的单词，前提是它们也是专有名词、形容词或分隔符（连词（'and'，'or'）或标点符号（';'，')'））。我们已经开发了一个常见的地名后缀列表（下面解释）。如果w_i后面跟着一个在这个后缀列表中的名词，我们认为它是一个可行的位置。鉴于Twitter上常见的OOV（Out ofVocabulary）词汇，我们还考虑那些与后缀列表中的词汇具有较高Jaro-Winkler相似度的词汇。我们还检查w_i之前的单词，看它是否是通常在地点或位置之前的介词，比如'at'，'in'，'from'，'to'，'near'等，或者像north，eastern等方向。然后我们通过分隔符拆分获得的单词流。因此，我们试图从文本的句法结构中推断出符合位置要求的专有名词。我们使用处理过的推文文本'18 doctors on 18motorcycles rode to 132 flood-hit villages in Bainsa division ofPurnia district inBihar'来说明这个过程的工作原理，该过程也在图1的流程图中描述。该算法将'Bainsa'、'Purnia'和'Bihar'识别为专有名词。由于'Purnia'后面跟着单词'district'，所以将短语'Purniadistrict'识别为一个位置。然而，'Bainsa'和'Bihar'也被检测为可行的位置，因为它们被视为相对于介词'in'的介词对象。03.4 正则表达式匹配0如前一节所述，我们编制了一个后缀列表，其中包含通常出现在位置名称之后的词。后缀列表包括不同的命名约定，用于地貌5、道路67、建筑物8和城镇。类似地，我们还编制了一个前缀列表，用于指定在位置之前添加的方向，例如南加州、西孟加拉邦。表1显示了后缀和前缀列表的一部分。我们从推文文本中识别出前缀和后缀元素，并将其后续或前导的单词视为可行的位置。我们执行这个额外的正则表达式相似性任务，以解决推文以小写字母发布时难以检测和消除歧义的情况。使用后缀列表使我们能够从推文“紧急B+组血小板患登革热，AnkitArora在Vinayak医院，Gujranwala镇，德里”中检测到“Vinayak医院”和“Gujranwala镇”等地点。03.5 紧急词的依赖解析0到目前为止，该方法旨在通过考虑通常用于标识位置的特定规范或模式来提高精确度。这一步旨在通过捕获不遵循上述常见模式的位置来提高召回率。0类型常见示例0地貌多巴、湖、蒸汽、河、岛、山谷、山、山丘0道路街道、街、大道、交叉口、巷、路、桥0建筑物医院、学校、神社、电影院、别墅、寺庙、清真寺0城镇城市、区、村、克拉姆、地方、城镇、纳加尔0方向南、东、西北、东南、西、西部、东北0疾病登革热、埃博拉、霍乱、寨卡病毒、疟疾、基孔肯雅热0灾害地震、洪水、干旱、海啸、滑坡、降雨0表1：后缀和与紧急情况相关的词的示例0考虑到我们的目标是监测紧急情况，我们确定了一组与流行病灾害9和自然灾害10相关的词，其中一些在表1中显示。我们从推文文本中识别出紧急词列表，并考虑距离紧急词在推文文本的依赖图中的3-4个单词，即专有名词、名词和形容词。距离度量指的是连接推文文本的依赖图中的单词的链接数量。较短的依赖意味着该词受紧急词的影响更密切。我们随机选择了100条推文，其中通过手动注释可识别出153个位置，其中139个被正确识别。通过依赖图，紧急词与可识别位置之间的平均距离为3.942，而正字距离（紧急词和目标词之间的单词数）为5.111。例如，图2显示了推文“孟买失去了泥滩和湿地，现在每年的季风都会发生洪水。”的依赖图。我们可以看到，在推文的依赖图中，孟买和洪水之间的距离为2，而在文本中的实际距离为7。因此，我们可以通过依赖解析将孟买识别为一个正确的位置。此后，我们还从依赖图中提取名词短语，类似于[12]。这些名词短语可以表示潜在的位置，如图1所示，其中NP（名词短语）块提供了可行的位置，如“普尔尼亚区”、“班萨分区”，以及冗余信息如“132个受洪水影响的村庄”。最后，为了完整起见，我们使用类似于[8, 11,12]的NER标记器。我们使用的NER标记器是SpaCy提供的，而不是更常见的NER工具，如Stanford NER [7]、Twitter NLP [15]、OpenNLP [2]，因为前者的执行时间更快，如表2所示。03.6 地名词典验证0然后，使用地名词典对以上方法提取的短语和地点进行验证，仅保留与现实世界地点相对应的单词。如图1所示，地名词典验证步骤对于过滤掉通过依赖解析和正则匹配获得的冗余名词短语和名词非常重要，例如“18 doctors”，“flood-hitvillages”，“division”等。对于我们的系统，地名词典还返回地理坐标以便在地图上标注位置。地名词典的选择取决于我们位置的粒度和精度以及11https://developer.twitter.com/en/docs12http://www.geonames.org/Track: Exploitation of Social Media for Emergency Relief and Preparedness WWW 2018, April 23-27, 2018, Lyon, France16460图1：流程图描述了我们的算法在一个样本推文“RT firstpost: 18 doctors on 18 motorcycles rode to 132 flood-hit villages in Bainsadivision of Purnia district in #Bihar https://t.co”的运行过程。0图2：样本推文“孟买失去了泥滩和湿地，现在每年的季风季节都会发生洪水”的依赖图。0性能速度。在精确性和性能之间存在权衡，我们将在后面的章节中进行说明。04 位置推断的比较评估0在本节中，我们描述了提出的方法的评估，并将其与几种基线方法进行了比较。我们首先描述数据集和我们所做的一些设计选择。04.1 数据集0我们使用Twitter Streaming API 11收集了来自2017年10月12日的推文0我们使用Twitter Streaming API11收集了从2017年9月13日到10月13日的推文，并过滤掉了包含“登革热”或“洪水”这两个词的推文。这一步骤产生了一个包含31天内收集的317,567条推文的数据集。对推文进行了预处理，去除了重复项和非英语语言的推文。这个过滤结果得到了239,276条不同的推文。04.2 使用的地名词典0在这项工作中，我们目前专注于收集和显示印度国境框内的推文。因此，我们需要一些词典/地名词典来消除一个地方是否位于印度以及其地理坐标是什么的歧义。为此，我们从Geonames12公开可用的数据中抓取了数据，并创建了一个对应于印度境内不同位置的词典。该词典包含了449,973个印度境内的位置信息。然而，该词典中提到的一些地方与常见的英语名词具有高度的拼写相似性。例如，我们发现词“song”是位于锡金（印度境内）的一个地方，其坐标为27 . 24641 ′ N，88 . 50622 ′E。此外，Geonames不包含道路和建筑物等地址的细粒度信息。13http://geocoder.readthedocs.io/providers/OpenStreetMap.html14http://download.geofabrik.de/asia/india.html15https://cloud.google.com/natural-language/UNILoc0.38480.78520.51650.0553BILoc0.40250.85900.54820.0624StanfordNER0.81030.63220.6988175.0124TwitterNLP0.63560.54740.588228.0001GoogleCloud0.63210.53390.5789NASpaCyNER0.98830.55550.71131.0891GeoLoc0.79870.83000.81411.1901OSMLoc0.33830.88880.4901711.5817GeoLocNoNER0.79870.79870.79871.168716470因此，我们探索了另一个地名词典 - Open StreetMap地名词典13，该词典为印度提供了一个全面的地址列表。然而，数据量庞大 - 大约是Geonames的530倍 -会影响实时环境下的性能。此外，与查询下载的Geonames地名词典转储相比，API调用需要相当长的时间。因此，地名词典的选择受到召回率和效率之间的权衡的影响。我们在本文中使用两个地名词典报告性能。因此，我们考虑了两种变体的提出的方法:0• GeoLoc - 我们使用Geonames作为地名词典的提出的方法。• OSMLoc - 我们使用Open StreetMaps作为地名词典的提出的方法。04.3 基线方法0我们将我们的算法的提出方法与下面列出的几种基线方法进行了比较：0•  UniLoc-获取处理后的推文文本中的所有单词，并推断其中是否有可能的位置（通过参考地名词典）。 •  BiLoc- 类似于UniLoc，但是我们考虑推文文本中的单词和双词。•  StanfordNER - 使用coreNLP解析器的NER。 •  TwitterNLP -使用Ritter等人开发的Twitter NLP解析器的NER。 •  GoogleCloud -使用Google Cloud自然语言平台推断位置。 150•  SpaCyNER - 使用训练好的SpaCy NER标注器。0对于所有基线方法，使用GeoNames地名词典检查潜在位置。04.4 评估度量0给定一个推文文本，我们希望推断出推文中包含的所有可能位置。因此，我们应该更喜欢具有更高召回率的方法。然而，由于我们还希望绘制从推文中获取的位置，我们提取的位置的精确度也很重要。因此，我们应用以下度量标准。0精确度 = | 正确的位置  ÷  检索到的位置 |0检索到的位置（1）0召回率 = | 正确的位置  ÷  检索到的位置 |0正确的位置（2）0其中'正确的位置'是人工标注员在推文中实际提到的位置集合，'检索到的位置'是某种方法从同一推文中推断出的位置集合。为了了解精确度和召回率，我们使用F-score，它是精确度和召回率的调和平均值。此外，由于我们希望实时部署系统，方法的评估时间也是一个合理的指标。0方法 精确度 召回率 F-score 时间（以秒为单位）0表2：基线方法和提出方法（使用GeoNames地名词典和使用OpenStreet Maps地名词典的两个变体）的评估性能。04.5 评估结果0我们从收集到的推文集合中随机选择了1,000条推文，并要求人工标注员识别其中包含一些位置名称的推文。标注员确定了一组包含至少一个位置名称的99条推文，所有这些位置都位于印度的地理边界内。因此，对这组99条推文进行了比较评估。表2比较了基线方法和提出方法的性能。最后一列显示了处理用于评估的99条推文所需的总时间（以秒为单位）。我们观察到，GeoLoc在F1得分方面表现最好，超过所有其他方法。它在精确度上也得分很高，仅排名第三，仅次于StanfordNER和SpaCyNER。SpaCyNer的高精确度由于其召回率较低而受到抵消，因此它几乎无法检测到偏远地区。例如，对于推文'Urgent B+ blood needed for a crit dengue patient at May Hosp. ,Mohali,(Chandigarh)'，SpaCyNer无法从推文中检测到'Mohali'等位置。然而，我们的GeoLoc算法可以检测到'Mohali'。精确度略微降低是由于一些常见词如'song'，'monsoon'，'parole'被选择为潜在位置，因为错误的标签分割，然后地名词典将这些词标记为位置，因为这些词也是印度某些地方的名称。还可以看到，使用GeoNames地名词典的提出方法比其他方法快得多，而性能相当（例如，StanfordNER）。我们还注意到，在表2中没有使用任何NER工具的情况下，我们提出的算法的性能由GeoLocNoNER表示。观察到，与GeoLoc相比，我们提出的方法表现更好，仅在召回率上略微下降（3.7%）。这证实了我们提出的方法不仅仅依赖于所使用的NER工具的准确性。0地名选择：如前所述，Geonames地名词典缺乏细粒度的信息。因此，与医院和街道相关的特定地点通常无法被识别为有效位置。这影响了系统的召回率，例如，提议的方法无法在推文“我们”中检测到“star hospital”0Track: Exploitation of Social Media for Emergency Relief and Preparedness WWW 2018, April 23-27, 2018, Lyon, France16480图3：SAVITR系统的系统架构0图4：SAVITR系统的快照：在印度地图上可视化的推文0需要O-ve血型，用于卡里姆纳格尔的一名8岁男孩患登革热，就医于星级医院，请联系。”Open Street Map(OSM)能够检测到这种特定位置，因此在所有其他方法中具有最高的召回率。然而，使用OSM的副作用是将许多简单的名词短语分类为有效位置。例如，在推文“@rajeev_mp seems its time to renameBangalore as Floods city I/O silicon city.”中，“siliconcity”被判断为“Concorde Silicon Valley, Electronics City Phase1, Vittasandra,Bangalore”条目的缩写，因此被检测为位置。由于此类错误，使用OSM的方法在所有方法中具有最低的精确度得分。0整个数据集的性能：在239,276条不同的推文中，只有3,493条带有地理标记，其中869条来自印度（占整个数据集的0.36%）。使用我们提出的技术和Geonames，从整个数据集中成功标记的推文数量为68,793条，约占26.15%。因此，覆盖范围大大增加。该方法可以识别印度的小众和偏远地区，如“Ghatkopar”、“Guntur”、“Pipravillage”和“Kharagpur”，以及“Delhi”、“Kolkata”和“Mumbai”等大都市。05 SAVITR：部署位置推断方法0我们已经在名为SAVITR的系统上部署了提出的技术（使用GeoNames），该系统可以在http://savitr.herokuapp.com上实时访问。Savitr的软件架构如图3所示。由于0由于要显示的数据量庞大，我们不得不实施某些设计考虑，以使显示的信息既紧凑又视觉丰富，同时具有可扩展性。该系统使用了Plotly的Dash框架[4]进行构建。为了实现可视化目的，我们在UI的核心采用了mapbox地图，并配备了各种控件，如下所述。系统的快照如图4所示。0•页面顶部的搜索栏。每当在搜索栏中输入一个词语，地图就会刷新并显示与该查询词相关的推文。它还支持多个搜索查询，如“登革热，疟疾”。•地图上的推文按照一天中的时间进行颜色编码。夜间发布的推文颜色较深。•日期选择器-如果希望可视化特定时间段内发布的推文，该选择器提供了精细的日期选择，包括月份和日期级别。•直方图-显示每天发布的相关（已标记）推文数量。•未标记的推文-最后，在页面底部，我们显示无法推断出位置的推文（因此无法在地图上显示）。0我们报告了2017年秋季困扰印度的大规模登革热爆发期间系统的性能。喀拉拉邦受到了这次爆发的严重影响。在这段时间里，系统识别出了2204条提及喀拉拉邦的推文，远高于其他地点被检测到的平均速率。此外，在2204条包含“喀拉拉邦”位置的推文中，有1960条（88.92%）也包含了我们编制的灾害术语列表中的“登革热”一词（见表1）。这些统计数据展示了SAVITR系统如何作为一个“预警系统”来标记任何即将到来的紧急情况。尽管SAVITR系统目前只能推断印度境内的位置，但它可以很容易地扩展到推断其他国家和整个世界的位置。06 讨论0一个自然的问题是扩展系统的范围，例如，扩展到非英文推文和整个世界（而不仅仅是印度）。为此，我们观察到仍然需要解决的几个挑战，其中一些在本节中列举。06.1 处理非英文推文0目前的方法主要集中在从英文推文中推断位置。然而，本文中的技术利用简单的句法和语义技术，因此可以扩展到其他语言，如德语和印地语，只要有必要的工具（POS标记器，依赖解析器，词典）可用。我们只需要制定规则，例如消除专有名词的歧义，以符合语法结构。然而，更具挑战性的问题在于从混合代码和借用代码的推文中提取位置。一种简单、粗糙的技术将涉及从推文中识别不同的语言016 https://www.telegraphindia.com/india/dengue-spurt-in-south-1828460Track: 利用社交媒体进行紧急救援和准备 WWW 2018年4月23日至27日，法国里昂16490文本，转写成英文，然后按照本文中描述的算法进行应用。然而，是否能够在实时基础上以较高的准确性完成这个任务仍然没有解决。06.2 全球定位0目前实施的系统仅关注印度国境内的位置。我们尝试了不同粒度的地名词典，并观察到一个全面/广泛的地名词典能够以更高的精度捕捉到更细粒度的位置，但也会导致更多的错误分类。因此，为了在全球范围内推断位置，我们需要一种位置消歧算法来区分两个共享相同名称的不同位置。例如，在推文“我家里的6个成员中有3个上周在印度拉贾斯坦邦的科塔得了登革热。”和“科塔贝鲁德的洪水切断了对8个村庄的通行。”中，“科塔”这个地点分别指的是印度的拉贾斯坦邦和马来西亚的另一个地方。任何位置消歧技术都需要依赖社交线索，例如发布推文的人的用户名或推文/用户的地理标记位置，以及文本本身。推文文本的长度可能无法提供足够的上下文。然而，在全球灾难的情况下，世界各地的人们都会表达他们的意见/同情，这加剧了从用户名本身判断文本位置的挑战。同样，在一些带有地理标记的推文中，观察到推文可以从与文本中提到的位置不同的地方发布。一个常见的现象是，从大都市（如新德里）发布的推文包含有关郊区的一些信息。如何处理这样的推文取决于具体的应用。06.3 系统改进0如