L1 includes both direct impacts (Deaths, Injuries, Homeless, Displaced, Affected, and Buildings Damaged) and monetary impacts (Damage and Insured Damage). All impact fields are nullable, but at least one impact must be present to report the event in our database. Basic information fields about the event, such as Event_ID, Event_Names, Sources, Start_Date_Year, and Administrative_Areas_Norm are mandatory at this level. We use the Database of Global Administrative Areas (GADM) level 0 administrative area to denote the Administrative_Areas_Norm field in our database . This area representation may contain countries or other geographic entities, which we hereafter refer to as either a country or as a national-level location. We remain neutral regarding to jurisdictional claims made in any material presented in this paper and the associated database. The impact information refers to the event's overall impact (e.g. 243 deaths in Fig. ). Whenever possible, impact information from Wikipedia articles is sourced from parts of the text which explicitly state the total impact. If aggregated impacts for the main event are not explicitly stated in the article, we aggregate data from L2 to present the total impact in L1. Fields with names ending in “Approx” indicate whether the information extracted from the Wikipedia article is precise (Table ). Returning to our example of the 2021 European floods, the article specifies “243 deaths”, and the “Approx” field for this number in the database is thus marked as “False”. Conversely, if the article had stated “more than 200 deaths”, then the data would have been normalized to [201,301] in the database using predefined normalization rules (see Sect. S7), and the related “Approx” field would have been marked as “True”. Similarly, if the L1 impact information is inferred from L2, the related “Approx” field is also marked as “True”.

L2 breaks down the impact information at national level. The Administrative_Areas_Norm field is a list, typically containing the single country (17 802 entries in the database) in which the reported total impact occurred or, in rare cases, a list of countries (110 entries in the database) if the impact could not be fully disaggregated between a subset of countries. Figure  provides as example the total number of deaths in Germany during the 2021 European Floods, and Sect. S1 shows that L2 contains corresponding information for other countries affected by these floods. Spatial information on the L2 impacts is mandatory in order for them to be included in the database, while temporal information is not mandatory as the impact should logically fall within the time span specified in L1 (Table ). National-level impact information is not always available. In some cases, the overall impact at this level is unknown, but impact information for specific locations within a country is provided. In these cases, we aggregate the information from L3 to present it in L2.

L3 provides a detailed breakdown of impact information at a sub-national level (e.g., province, municipality) . Similarly to L1, we use the GADM level 0 administrative area to denote the Administrative_Area_Norm fields in this level. Figure  provides as example the information on number of deaths in L3 for the city of Pepinster (shown as a point) in Belgium and the state of Bavaria (shown as a polygon) in Germany. In most cases, the impact is confined to a single location, yet there are instances where the impact spans multiple places within the country. In that case, the field Administrative_Area_Norm contains the country, and the field Locations_Norm contains a list of specific locations within that country where the impact occurred. Like for L2, spatial information is mandatory at this level, while temporal information remains optional (Table ).

A three-step approach is used to select relevant English articles. First, we craft a keyword list covering all main event categories in the database, which we then use to extract relevant articles (see Sect. S2 for keywords). Querying Wikipedia using these English keywords (with a cut-off date at 29 February 2024), results in 30 085 articles. However, not all articles retrieved through this keyword extraction process are related to climate events. For instance, some refer to topics like “Miami Hurricanes football” . Therefore, in a second step, to filter non-climate-related articles automatically, we apply as text classifier a pre-trained English distilled Bidirectional Encoder Representations from Transformers (BERT) model (DistilBert for sequence classification, accessed via the HuggingFace platform at https://huggingface.co/docs/transformers/en/model_doc/distilbert, last access: 20 May 2026) ). To this end, the BERT model is fine-tuned on a set of 300 Wikipedia articles, containing 248 relevant and 52 irrelevant articles.

For articles longer than 512 tokens, only the first 512 tokens are used.

A core component of our database construction pipeline is the application of the GPT4o model (version: gpt-4o-2024-05-13). Different from initial trials , we employ the GPT4o model, released in 2024, rather than the GPT4 model because its longer context window allows it to process a substantially larger number of input tokens, which is particularly beneficial for handling long Wikipedia articles. To extract information from Wikipedia articles, we feed the full text and the information box (if it exists) to the GPT4o model together with a set of prompts corresponding to the different fields of our database. We do not process tables or list items within them. Consequently, information that appears only in tables is currently excluded from the database. To facilitate post-processing, we instruct the GPT4o model to provide output in JSON. However, one issue we faced was that the model sometimes cannot produce valid JSON objects. This can occur due to the longer output length that exceeds the total number of permitted output tokens, as found by – for example when we instruct the model to return the text segment where it identifies the relevant information as a traceable source in the output but this is too long for JSON output. To mitigate this issue, each Wikipedia article is presented as a JSON file where each key is the header title of the section in the Wikipedia article and each value is the verbatim text as it appears in Wikipedia. Compared to other text sources, Wikipedia articles are well-structured, enabling the extraction of the full text in the header-content pair format. In this setup, and for all fields, we instruct the model to provide a source section that includes the original section headers from the Wikipedia article where the information is found. This strategy also helps to prevent model hallucinations since the model does not need to return large blocks of source text when extracting information on extreme climate impacts.

To obtain location and time information about the event in L1, we build prompts for the relevant information, and for the source section of this information. To obtain the location information, we ask the model to capture all locations affected by the event and retrieve the affected countries during post-processing. To obtain the main event category and the reported hazards, we provide the model with the list of main event categories and the hazards associated with each category (Table ). Following this, we pose four prompts: the first for the event category, the second for the source section of the event category, the third for the associated hazards based on the result of the event category, and the last for the source section of the hazards. We then use more complex prompts to extract information on different impacts. These prompts partly rely on keywords used for categorising the impacts. These same keywords are also used in the annotation process (Sect. ). The L1 information represents the total impact of the event, for which we use two prompts: one regarding the total impact and another pertaining to its source section. This is followed by information extraction at L2 and L3, as well as specifics on times and locations, if such details are available. Additionally, we prompt the model to capture L1 impact information only when explicitly stated in the text, such as in the 2021 European Floods example: “At least 243 people died in the floods”. If this information is not provided explicitly, the model is tasked to return “NULL” rather than summing individual data entries to produce a total for L1. Similarly, for L2, the model is tasked to return the total impact for specific countries only when explicitly available. If unavailable, it should not aggregate data from various locations within a country but instead return “NULL”. We also evaluate the performance of different prompt settings for information extraction. Our prompt design, evaluation and the complete text of the prompts used for full run production can be found in Sect. S4. We use what is termed “prompt v3.1” in the Supplement for all information categories, except the L1 location, where we use “prompt v3.2”.

The outputs produced by the GPT4o model contain “raw” data (e.g. dates represented in a variety of formats or ambiguous location names) that often requires normalization i.e., conversion to a standardized format. We apply a set of normalization rules (see Sect. S7) to the raw data, ensuring that the post-processed model output can be evaluated and stored in a standardized format in the database. Overall, we normalise the main event, hazards, time, location, and numerical data prior to the evaluation. The detailed post-processing steps are listed below.

During the consolidation process, we filter out events that do not fall within our predefined main event types or hazard categories, such as “geomagnetic storm”, or “landslide”. Nonetheless, these events may be implicitly accounted for in the impact data, for example if the reported impacts for a flood include the impacts of a landslide triggered by the flood. Upon constructing the initial database, we identify missing information at various levels. For instance, the attribute Total_Deaths for a particular event might be recorded as NULL at L1, while at L2, there could be an entry indicating 20 fatalities in Germany. Furthermore, the cumulative impact at L3 within a single country might exceed the documented impact at L2 for the same country, and similarly, aggregated L2 data might provide larger values than the information available at L1.

To address these discrepancies and ensure data consistency across the database, we adopt a bottom-up approach beginning with L3. We sum L3 impact values for a given country and compare these to L2. If L2 provides a range, we adjust the minimum and maximum of the range if necessary. If L2 provides a single number, we transform this into a range if it is lower than the aggregated information from L3. We repeat the same procedure for L1, by aggregating impact values from L2. Detailed rules and procedures are provided in Sect. S8.

In addition to addressing these data inconsistencies, we standardize currencies and adjust for inflation throughout the database, choosing USD as the base currency. Using the currency statistics from the Wikimpacts 1.0 database, we obtain conversion rates for most non-USD currencies from a publicly available resource . For periods before a currency's available data, a constant currency conversion rate is applied as the earliest available year. Additionally, we include EUR as a secondary standardized currency, with USD-2024-inflation-adjusted values converted to EUR using the 2024 average conversion rate.

Our approach to inflation adjustments follows the same rules as those documented by EM-DAT (Minneapolis Fed CPI calculator, https://www.minneapolisfed.org/about-us/monetary-policy/inflation-calculator/consumer-price-index-1800-, last access: 20 May 2026; EM-DAT protocol, https://doc.emdat.be/docs/protocols/economic-adjustment/, last access: 20 May 2026). In Wikimpacts 1.0, all monetary values are adjusted to reflect 2024's inflation rates, except for events occurring in 2024, which are left unadjusted for inflation. Detailed information on these adjustments is provided in Sect. S8.

As part of Wikimpacts 1.0, we develop a gold standard dataset by manually annotating Wikipedia articles. The gold standard events are randomly sampled from the original set of 5046 classified articles, and only the subset of single-event articles are annotated for Wikimpacts 1.0 database development, with the constraint that their event-type distribution is representative of that of the entire database. The annotation was conducted over the course of one year by two postdoctoral researchers in climate science and two researchers with a master's degree in water engineering. This gold standard dataset includes a development set containing 70 main events (used to develop the information extraction pipeline) and a test set containing 156 main events (used exclusively for evaluation of the GPT4o model output). The disaster type distribution of these two sets is shown in Sect. S5 and Table S6 in the Supplement. Compared to preliminary results from , part of these annotated data now include L2 and L3 information. In the development set, we have 55 events with L2 and L3 information annotated, while in the test set, there are 97 events annotated with this additional level of impact information. An error rate for each field provided by the GPT4o model is calculated by comparing the LLM output with the gold standard.

We recognise that manual annotation is not error-proof. To ensure consistent and robust annotation, we provided the annotators with a list of keywords for detecting impacts (see Table ). We further established comprehensive logical normalization rules for the annotators to follow. These correspond to the post-processing rules for the Wikimpacts database (see Sect. S7).

We evaluate the LLM output using the above-described test set from the gold standard data. The evaluation involves all three levels of information. For all main events, the three levels contain many fields, making evaluation challenging. To obtain an overall aggregated score for each event, as well as scores for specific fields, we define a difference error metric for each field, ranging from 0 to 1 (where lower values indicate better performance). We then calculate an aggregated score as a weighted sum of these field-specific scores: 1D(a,r):=1n∑iwidiai,ri D(a,r) is the difference between a gold entry a and an LLM output entry r, with weights wi and difference metrics di of fields i, where n is the number of fields. This approach allows to adjust the relative influence of each field by modifying its weight. Since the importance of the different fields is user-dependent, in this paper we present evaluation results with an equal weighting of all fields.

The difference metrics for specific fields are defined based on metrics for the following basic types: numbers, strings, booleans, and lists.

For (non-negative) numbers:2dn(a,r):=0,ifa=r|a-r|a+r,otherwise

Rather than using more conventional evaluation metrics (such as accuracy, recall, or precision), we opt to use metrics tailored to the database's specific application: representing climate extremes and their impacts. For instance, if the correct number of deaths is 10, an output of 11 would result in a minor error, whereas an output of 100 would be a substantial error. Under the current metric, these predictions receive a normalized error rates of 0.048 and 0.818, respectively.

In this paper, we evaluate only those fields that are directly extracted by GPT4o, excluding any post-processed or otherwise derived fields. Specifically, our assessment is limited to the fields in Table  that appear without an asterisk, as the asterisked fields are obtained through post-processing rather than representing the raw output of the LLM. For the evaluation of L1, the LLM output is automatically matched with the gold standard using the Event_ID since only a single entry is retrieved per article in L1. However, for L2 and L3, the number of entries extracted by the LLM may vary, compared to the gold standard. For instance, for the same event there may be 5 entries in L2 from the gold standard, but 10 entries in the LLM output. To address this, we implement a matching algorithm during the L2/L3 evaluation process that identifies the most similar entries in the LLM output and the gold standard. The matching algorithm uses the same evaluation metrics as above to determine similarity of entries as 1-d(a,r), and the best matching entry pairs in the LLM output and the gold standard are then selected. The remaining entries in the gold data or the LLM output are matched to empty entries padded with “NULL” values. This results in two lists of entries of equal length, which is the desired format for evaluation. In the matching algorithm, it is possible to select different values for some important parameters:

the similarity threshold under which entries are not considered to be a good match

We use the 55 events in the gold standard development set to select the matching algorithm's parameters setting. For the rest of the evaluation, we use the parameter set termed “Setting 2” in Sect. S5, Table S10.

Table  shows that the model performs consistently well across all L1 fields in the test set. The error rates for Main Event and Hazards are 0.0256 and 0.2004, respectively, indicating that the model effectively captures robust information for the Main Event and comparatively reliable information for the associated hazards. Regarding time-related information, the model achieves near-perfect performance, with error rates ranging from 0.0003 to 0.0463. However, the location information exhibits a higher error rate of 0.4843. For the impact categories, Total Deaths has the lowest error rates, ranging from 0.0236 to 0.0374; Total Damage and Total Insured Damage also show low error rates of approximately 0.07 and 0.012, respectively. For other impact categories, error rates range from 0.2118 to 0.311, indicating that the LLM encounters difficulties in capturing this information from Wikipedia articles.

Tables  and  present the evaluation results for L2 and L3. For these two levels, the model's performance on the test set is comparable to its performance on the development set (see Sect. S5, Table S11). Next to the Weighted_Score in each impact category, the error rates for individual fields within the impact categories are presented in these tables. The location field Administrative_Areas_Norm exhibits the highest error rate across all impact categories in L2. Similarly, in L3, both Administrative_Area_Norm and Locations_Norm display higher error rates compared to other fields. Notably, time-related information in both L2 and L3 has relatively low error rates, which are generally lower than the Weighted_Score. For impact information fields such as Num_Min and Num_Max, L2 generally achieves lower error rates compared to L3. Referring to the Weighted_Score across all impact categories, the information in L2 is more robust than that in L3 within our database. Furthermore, across impact categories, Injuries, Homeless, and Displaced exhibit relatively lower error rates than other categories.

Overall, the L1 information extracted by the LLM thus provides the most reliable representation of the underlying Wikipedia articles, followed by L2 and L3. Within L1, event and timing data are highly accurate, while location data is less robust. The Deaths category in L1 has the lowest error, followed by Damage and Insured Damage, with other categories showing higher errors. In L2 and L3, the injuries, homeless, and displaced categories are most reliable. We underscore that the evaluation is conducted only the LLM output, not the final database entries. In the final entries, the output of the LLM may be corrected through post-processing, for example by aggregating L2 impact information to revise the corresponding L1 value. This is why we maintain the categories in the database even when the error scores are high (e.g., the Location_Norm of Damage in L3 with an error score of 1). For further discussion of the evaluation errors and database quality, we refer the reader to Sect. 6.1.

We next investigate the spatial distribution of national-level (L2) impact data entries (Fig. a). In total, we have 17 912 such entries, with the US having the highest number (4071 entries in total). They are followed by the Philippines with 1174 data entries, Mexico with 1170, Japan with 1003, China with 884, Australia with 515, and Canada with 486. Most African countries display a limited number of impact data entries, with some exceptions such as Madagascar (208 entries). This largely reflects the spatial distribution of the main events (Sect. ). Furthermore, a limited number of data entries is observed in parts of Western Latin America, Eastern Europe, and Central Asia.

The L3 information in our database reflects impact data reported at sub-national level, which we visualise in Fig. b–c. In total, there are 32 343 entries in L3, and 9 entries contain unexpected GeoJSON shapes, such as ocean shapefiles of the Arabian Sea, which were subsequently removed for visualization purposes (see Sect. S9). The US leads with 10 994 sub-national level entries, followed by Mexico, Japan, the Philippines, China, Australia, India, and Canada, with 2385, 2334, 1845, 1306, 1012, 933, and 694 entries, respectively. Vietnam and Cuba have fewer entries, with 505 and 355 entries, respectively. The GeoJSON files include both polygons and points, where polygons often represent larger administrative areas such as states or provinces (here referred to as “Regions”). Points typically represent cities, towns, or villages (here referred to as “Cities”) for which OpenStreetMap could not find a GeoJSON object of a non-Point shape (such as Polygon or MultiPolygon). In some cases, when a region cannot be represented by a polygon or multi-polygon shape, it is recorded as a point location in our database. The “Regions” map (Fig. b) indicates that not all states or provinces within a country have recorded impacts (Fig. b). In some countries, such as China, impacts predominantly occur in coastal regions, with Fujian province having the highest number of data entries at 141, followed by Zhejiang province with 79 entries. In contrast, in the US impacts are distributed across most states, with Delaware having the highest number of entries at 98. In Mexico, a few states have a large number of data entries, like Acapulco (116 entries). In contrast, sub-national impact entries for African countries are limited, particularly in Central and Northern Africa. We observe a similar pattern in Western Latin America. In the “Cities” map, the distribution of impact data entries is more concentrated (Fig. c). Most entries are of events that occurred in the US, with Outer Banks having the highest number of entries (34), followed by East Texas with 17 entries. Notably, Cabo San Lucas in Mexico also has a large number of data entries, with 27 entries. In Africa, the sub-national impact data entries are concentrated in coastal regions of South, East, and West Africa, whereas in South America, city-level impact data entries appear to be limited.

We compare the coverage of Wikimpacts 1.0 to the widely-used EM-DAT impact database. As a first step, we align our database's time span with that of EM-DAT (1 January 1900–29 February 2024). To compare the most detailed available level in each dataset, we benchmark the number of impact data entries at L3 between our database and EM-DAT. To ensure a fair comparison, we assign one entry per impact field present in EM-DAT, and EM-DAT disaster subtypes are mapped to our main event categories (see Sect. S6). We specifically map the Tropical Cyclone category in EM-DAT to our Tropical Storm/Cyclone category, and the Extra-Tropical Storm category in EM-DAT to our Extratropical Storm/Cyclone category. Additionally, we aggregate all storm-related entries in EM-DAT and compare this with the combined total of Tropical Storm/Cyclone and Extratropical Storm/Clone categories in our database. For the spatial comparison, we utilize ISO codes from EM-DAT and the Administrative_Areas_GID identifiers from our database.

In total, the EM-DAT database contains 35 502 impact data entries, whereas the Wikimpacts 1.0 database comprises 31 405 data entries for the same period. The Wikimpacts 1.0 database includes a greater number of data entries for main event types such as tropical storms (12 767 more entries), extratropical storms (1895 more), tornadoes (1925 more), and wildfires (291 more) (Fig. a). Notably, our database has 10 280 more entries for storms overall even when considering all storm-related entries in EM-DAT. However, our database contains substantially fewer data entries for floods (fewer by 14 619), as well as fewer data entries for droughts (fewer by 1370) and extreme temperature events (fewer by 618). From a spatial distribution perspective (see Fig. b), our database contains more impact data entries in the US (7362 more entries), Mexico (1724 more entries), Japan (1456 more entries), Canada (368 more entries), and Australia (293 more entries), as well as in a few countries in Northern Europe and Africa. In contrast, Wikimpacts 1.0 contains fewer impact data entries in most countries in Africa, South America, and Asia. For example, there are fewer data entries in China (1139 fewer), Indonesia (787 fewer), India (697 fewer), Bangladesh (670 fewer), Brazil (562 fewer), Vietnam (448 fewer), and Thailand (373 fewer). Despite these regional differences in coverage, both datasets overall suffer from a spatial reporting biased towards the Global North.

We also perform an event-by-event matching between EM-DAT and Wikimpacts. We select four impact categories (deaths, injuries, homeless, and total damage), and compare the L2 data in our database to the country-level impacts from EM-DAT. For each event and each impact variable, we compute the relative difference as ((Wikimpacts impact value - EM-DAT impact value) / EM-DAT impact value × 100 %), which quantifies how much the Wikimpacts value differs from the corresponding EM-DAT value. Events are precisely matched based on ISO code (Administrative_Areas_GID), main event type, and exact start/end year and month. We then classify the events depending on whether the impact entries match, or by how much they differ. The comparison is illustrated in Fig. . In the deaths category, 32 out of 179 matched events exhibit identical values with EM-DAT. Of the remaining events, 38 show higher values by 50 % or more, and 47 show lower values by 50 % or more compared to EM-DAT. In the injury category, 7 out of 77 events perfectly align with EM-DAT values; over one-third of the events exhibit values at least 50 % higher than EM-DAT. For the homeless and damage categories, no events display the same impact values. More events in the homeless category have lower values than EM-DAT, while nearly 94 % in the damage category show higher values than EM-DAT.

The pipeline of the Wikimpacts 1.0 database is designed to capture information contained in Wikipedia articles as accurately as possible. In this respect, the performance of the GPT4o model is crucial for determining the database's quality and robustness. The GPT4o model exhibits strong performance across all three levels of information (see Sects. , S4 and S5). L1 data is the most robust and reliable, displaying the lowest error rate among the three levels, with the errors increasing as the spatial scale of the reported impacts decreases. L3 data entries display the highest errors. Nonetheless, even for L1, the error rate for location information is high, with a score of 0.48 in Administrative_Areas_Norm across 156 events. We find that 35 NULL penalties, each scoring 1 for the corresponding attribute, account for nearly 46 % of the total error score. Similarly, NULL penalties in the L2 and L3 location information lead to high error scores in these location-related fields. During the consolidation process, we filter out these entries. Moreover, we do not compare the results obtained after consolidation with the gold standard, because, as described in Sect. 3.4, the data are processed from L3 to L2 to L1, and the resulting processed data no longer match the originally annotated data. Thus, the extraction errors from the LLM do not necessarily propagate to the final version of the database. The reasons for these differences are explored in detail in the following error analysis.

We endeavoured to conduct a fair comparison between EM-DAT and Wikimpacts, even though the databases differ in structure and in the categorisation of main events. EM-DAT has some level of standardization, using ISO/UN regions, and refers to GAUL administrative units. The weakness of EM-DAT is that the impact is not disaggregated between identified sub-national units. Our database generally contains more detailed information than EM-DAT, such as standardised impact data at a sub-national level, despite having fewer impact data entries than EM-DAT in many countries. The two databases further display very different distributions of the impact information across the different event categories. The total number of impact data entries between the two databases is nonetheless comparable, as are their biases in geographical coverage. When assessing the impact values, matching records can be noted for death and injury information, although significant discrepancies are observed in the data for homelessness and damage.

Notably, the substantial differences in both event coverage and impacts for matched events between Wikimpacts and EM-DAT do not necessarily arise from extraction errors in our pipeline. They may also issue from divergent event definitions, inclusion thresholds and criteria for impact data, differences in impact sources, and differences in the definitions and components of impact categories. Moreover, in this study we did not conduct a systematic comparison with other existing databases, such as DesInventar, but previous work shows large discrepancies between DesInventar and EM-DAT . We therefore recommend using our database as a complementary resource to existing databases. Furthermore, when matching events across different databases, we suggest testing different matching algorithms, for example based on event names and by allowing temporal buffers in event dates, in order to more reliably identify corresponding events across databases.

We next return to the broader challenges that we outlined in the introduction related to the currently available impact data for climate-related hazards. We argue that Wikimpacts 1.0 presents clear advances in several of those respects. First, it addresses the issue of non-standardised geographical information by including event-level and national-level impact data, and standardised information for sub-national impact data. This also prevents the issue of the same large-scale main event, e.g. a heatwave, being included in the database as several distinct events if it affected different countries. Second, Wikimpacts 1.0 is readily expandable thanks to its highly automated pipeline. Third, data in Wikimpacts 1.0 is traceable, as our database includes a Sources field for each impact entry. We also assign a range to our quantitative data when exact information is not provided in the underlying data source, enabling uncertainty-aware impact analyses. Finally, the database is fully reproducible (as long as the proprietary LLM models used remain available for use), since we openly share both the database itself and the source code of our processing pipeline.

While Wikimpacts 1.0 innovates over existing databases in many aspects, it nonetheless comes with a number of caveats. First, the geographical coverage of the impact data remains uneven. We find that the exclusive use of English-language Wikipedia articles is likely not the main driver of this, as most of the reported events in other language editions of Wikipedia are also reported in English. While English-language bias does exists in our database, we thus do not view it as the primary source of overall geographical bias. We instead hypothesise that the reduced coverage in the Global South issues from less reporting of extreme events through Wikipedia, regardless of language. Related to this, for the events that are reported, there are many missing data for the different impact categories. Moreover, the pre-1900 records in Wikimpacts 1.0 database are limited, and future versions of Wikimpacts database will aim to include available historical events prior to 1900. Second, the coverage across main event categories is uneven, with comparatively few data entries for some categories like extreme temperatures and droughts. This may be partly due to the difficulty of assigning quantitative impacts to these events as their detrimental effects often occur on relatively long timescales and can be indirect. Moreover, certain hazards, such as landslides, are not included in our database. In addition, our pipeline, while scoring highly on the evaluation metrics, nonetheless introduces some errors relative to the original information provided by the Wikipedia articles we use. Systematic errors introduced by the LLM-based extraction, such as misclassification of L2 and L3 information, may lead to duplicate entries in the database. The extracted information is also sensitive to the specific LLM employed. The full Wikimpacts 1.0 database was generated using the state-of-the-art GPT-4o model available in 2024. The GPT family has continued to evolve since then; however, newer GPT versions are not evaluated in this work because we aim to fine-tune open source LLMs for the future live updates. Furthermore, we only provide information on the hazard causing the impacts at L1 level, while the database lacks L2 and L3 hazard information. The database focuses on direct impacts, and overlooks indirect or cascading impacts unless these fit into one of the predefined impact categories. Finally, the database's reliability is inherently tied to the quality of Wikipedia articles, as we perform no additional verification of the sources beyond what Wikipedia does. Nevertheless, the Wikimpacts 1.0 database is suitable for global impact-database benchmarking, exploratory sub-national impact assessment, and risk modeling in data-rich contexts (e.g., tropical storm/cylone events in the United States). However, it should be used with caution in applications that are sensitive to completeness or that focus on local or small-scale events. Further research could aim at addressing some of these limitations, for instance by expanding the database to multi-event Wikipedia articles, other Wikipedia languages or online textual sources beyond Wikipedia.