> I recommend minor revision. The manuscript describes EuroCrops v2.0, a multi-annual harmonized parcel-level crop-type dataset built from publicly available EU Geo-Spatial Application (GSA) declarations (18 Paying Agencies; minimum three consecutive years including 2021), harmonized via the updated HCAT v4 taxonomy and linked to key EU statistical/survey and EO classification systems. The paper is timely and valuable for CAP-related analysis, crop-rotation studies, and as training/validation data for EO products; the processing chain and interoperability ambition are strong

> Handling missing crop codes: you gap-fill codes where possible and otherwise create new unique codes (starting at 10001) “in a random order.” Please clarify the randomization (seed; stability across releases) and provide a quick summary of how frequent this situation is by country/year (e.g., Estonia/Ireland name-only years

Before the crop names were translated from their native language to English, a pre-processing step was undertaken to align the crop names across the years because countries provide an updated crop code list on an annual basis and the EuroCropsv2.0 process has been ongoing since 2021.  The github now includes a table with the original_code and how these are related to multiple instances of original_name. The process for consolidating the dataset (i.e., having unique pairs of original_code/original_name) involved the use of an LLM (gpt-4o and nous-hermes-2-mixtral-8x7b-dpo), or a manual process. The source of the consolidated original_name is provided in this table here: https://github.com/Martincccc/EuroCropsV2/blob/main/data/processing/name_mistakes.csv.

The aligned crop names were then translated using three machine learning packages. We have uploaded one table per country (XX_trans_stats.csv) with the original codes and their translations from Google Translate (g_tname), DeepL (dpl_name) and OPUS-MT (opus_tname) to github, placed in this folder: https://github.com/Martincccc/EuroCropsV2/tree/main/data/eurocrop_trans, where XX in the filename is the two letter country code or the three letter regional code. Note that these files have been updated in 2026 so that they are reproducible since this process was done over several years (since 2021) as outlined above.

We attempted to provide the best translations possible, which is why a third machine translator was introduced as part of EuroCropsv2.0. At the beginning of EuroCropsv2.0, we discovered some wrong translations by DeepL and Google Translate. Therefore, we added OPUS-MT, which is not as good as the other two translators, accounting for 63-92% of the translation errors, but it served as an additional check. Without the use of OPUS-MT, the number of manual checks would have been reduced significantly, but we ran the risk of wrong translations that would not have been picked up using only DeepL and Google Translate.

The translation accuracy varies by country with the lowest in Spain at 40% to the highest in Belgium at around 72%. Estonia provides English translations of most labels on https://klassifikaatorid.stat.ee/, so a simple search there resolved most disagreements. Other countries do not have such convenient portals. Slovenia releases their labels along with the scientific name of the crops while Ireland’s labels are in English. Spelling mistakes were rare except for the Spanish, Bulgarian, Czech, Portuguese and Italian GSA, which led to direct failures of translation and no results were provided by Google Translate. In the German GSA, there were many abbreviations and short forms of names used, which hindered the automatic translation. In the GSA of Czechia, there were extremely detailed species level crop descriptions of grasses and legumes as well as the use of colloquial terms. After machine translation, colloquial terms often led to non-crop-like descriptions such as diabetes, quiet, etc. Subsequent Google searches of these terms sometimes turned up empty, whereas for other niche translations, they showed up in Wikipedia. In other cases, we sent the colloquial terms to native speakers to review but this was not possible for all languages.

We have added a new section to the Supplementary Material (called Translation of crop names) and added all of this text. It includes a summary table, Table S1, which summarizes the number and percentage of multiple instances of original_name per country and the translation statistics and errors. The accuracy refers to the percentage of time when all the machine translations were in agreement. Where there was disagreement in the remaining  translations, these were all manually checked. Of these manually checked translations, five different cases may have occurred. In the majority of cases, at least one machine translator was correct. Often OPUS-MT was the poorest performer, but other times, e.g., in Slovakia, Google Translate and DeepL failed but OPUS-MT was correct. The second type of case included the occurrence of niche crop names, e.g., species level trees or legumes, which were confirmed by Wikipedia, or where the translator chose a more frequently used homonym, which were then checked using Wikipedia’s disambiguation pages. A third case was the occurrence of  colloquial or regional names, which were also checked using Wikipedia. Finally, spelling errors (case 4) and crop names that were abbreviated or truncated (case 5) were also identified through this manual checking process.

Table S1: Summary of instances of multiple original_name for crops and translation statistics

*EE has separable prefixes: 7.57% of the errors because MT cannot handle prefix at the end

Thank you for this suggestion. However, the purpose was not to evaluate the EurocropsV2 dataset against all potential crop datasets. We compared EuroCropsV2 with what is considered to be the most robust reference, i.e., crop statistics from Eurostat and gridded agricultural census data from the Integrated Farm Statistics (IFS) as these were available at a finer level of granularity than Eurostat NUTS2 level statistics. However, we have added a reference to this paper in the discussion section, citing it as a source for users to access if they want to do a comparison with other datasets.

> This manuscript presents EuroCrops v2.0, a multi-annual harmonized dataset of parcel-level crop declarations derived from publicly available Geo-Spatial Application (GSA) data across 18 Paying Agencies in the European Union. The dataset is harmonized using an updated Hierarchical Crop and Agriculture Taxonomy (HCAT4), which introduces additional dimensions for seasonality and usage, and is linked to multiple European statistical and Earth Observation classification systems (AGRIPROD, LUCAS, IFS/FSS, FADN, HRL Crop Types). The manuscript fits well within the scope of Earth System Science Data. It describes a large, policy-relevant, open-access geospatial dataset with clear potential for reuse in Earth observation, agricultural monitoring, sustainability assessment, and CAP-related evaluation. The extension from a single-year dataset (EuroCrops v1) to a multi-annual harmonized dataset represents a significant and valuable advance. The manuscript is generally well structured, and the authors demonstrate considerable effort in data cleaning, semantic harmonization, and validation. The comparison with Eurostat statistics and gridded IFS data provides useful validation evidence. The discussion appropriately acknowledges limitations.

> However, several aspects require clarification or strengthening, particularly regarding reproducibility of the harmonization workflow, quantification of methodological impacts (e.g., stacking and rasterization), and documentation of uncertainty and metadata.

> 1. Major Comments

> Handling of Multiple Crops per Parcel

> The manuscript describes rules for handling multiple crops listed within a single parcel label (e.g., hierarchy-based grouping, majority crop assignment, first-mentioned crop). However:

> The proportion of parcels affected by multi-crop labels is not reported.

> The potential bias introduced by assigning the “first mentioned” crop is not assessed.

> Country-level differences in this issue are not quantified. Given that some countries (e.g., Portugal, Ireland) exhibit specific declaration complexities, this could introduce systematic distortions.

> 2. Reproducibility of the Harmonization Workflow

> The harmonization process is conceptually well described, including translation, semantic verification, matching to HCAT4, and iterative refinement. However, several components lack sufficient detail for full reproducibility.  The manuscript indicates that crop names were translated using Google Translate, DeepL, OPUS-MT, and, where necessary, ChatGPT. Additionally, a large language model (LLM) was used to detect semantic discrepancies in crop code definitions over time. For ESSD, automated or semi-automated semantic decisions that affect taxonomy assignment should be reproducible. The manuscript should clarify:

> Which LLM(s) and versions were used?

> Were deterministic settings applied?

> What prompts or criteria were used to detect semantic discrepancies?

> How were disagreements between translation tools resolved?

> What proportion of entries required manual intervention?

> Without these details, it is difficult for future users to replicate or audit the harmonization procedure.

> The manuscript presents validation against Eurostat and IFS data, including R² and NSE metrics. This is commendable and strengthens confidence in the dataset. However, the dataset itself does not appear to provide:

> Harmonization confidence indicators,

> Translation reliability scores,

> Flags for manually corrected entries,

> Country-level reliability summaries.

> Given the complexity of semantic harmonization across languages and classification systems, some form of quality metadata would enhance transparency.

> 4. Metadata, FAIR Compliance, and Versioning

> The dataset is openly available (with DOI), and code is provided via GitHub. This is highly positive. However, the manuscript would benefit from:

> A clear data dictionary describing all attributes in the geoparquet files,

> Explicit CRS documentation,

> Description of file naming conventions,

> A versioning and update policy (e.g., semantic versioning, expected update frequency),

> Clarification on long-term repository archiving (e.g., Zenodo snapshot of code).

> Minor Comments

> Abstract: Consider explicitly stating the temporal coverage range (e.g., 2008–2023, where applicable) for clarity.

> Consistency of terminology: Ensure consistent referencing of HCAT versions (HCAT2, HCAT3, HCAT4).

> CRS specification: Explicitly define the coordinate reference systems used for storage and visualization.

> Validation summary: A concise summary table of validation statistics per crop class would enhance readability.