Response by the Authors
Thank you for the detailed evaluation, precise questions, and insightful comments!
### Response to the Weaknesses
> Reviewer:
> It would have been interesting to see more comparisons on datasets [...], e.g., the fMoW dataset.
We considered including FMoW initially but decided against it, as the accuracy benefit of adding coordinate information is only 1.62 % (see Mai et al., 2023; Sphere2Vec Table 3; no std devs given). We believe that this margin is too small to show any systematic differences between the location encoders. Instead, we focused rather on iNaturalist, where the benefit of adding geolocation adds a 12.3% improvement (Table 1c) over the image-only model.
> Reviewer:
> Would it be possible to integrate this method other tasks more common with ERA5 such as downscaling?
The location encoder is not restricted to gridded data and can predict ERA5 variables continuously. Hence, generating a 1km rather than 30km grid (as in downscaling) is possible on a technical level. Still, adding further (higher-res.) covariates, like detailed topographic features, is likely necessary to improve the effective resolution. The location encoder can be used here as a module for a larger downscaling model.
### Response to Questions
> Reviewer:
> Intuition about the combination of SirenNet and some DFS based encodings performing worse than SirenNet alone?
Sphere{C,M} keep one lat/lon coordinate at the original (lowest-frequency) scale while scaling up the other. We hypothize that the lowest scale may be too low-resolution, which can be potentially detrimental. Beyond that, we have no further intuition other than that DFS-embeddings are not optimal for the Sphere in general (violated assumption of rectangular lat/lon domain). Regarding the good performance of SirenNet alone (i.e., with Direct), we show in Section 2.3 that a single Siren layer with specifically set weights can produce the same embedding as Grid. Hence, it is not surprising that Siren with direct coordinates performs competitively well.
> Reviewer:
> I may have missed this information but what is the number of Legendre Polynomials in the experiments results reported in the tables?
We performed hyperparameter tuning separately for each NN-PE combination, as described in the Appendix Section "A.1 Implementation details and hyperparameter tuning".
Concretely, every model in the results tables has a different configuration for the SH models. We tune the Legendre polynomials L between 10 and 30 in steps of 5 polynomials. In the best hyperparameter file, we find the entire value range (10 to 30) present. Indeed, L controls the smoothness of the interpolation directly. A too-low L may be too low-frequency to capture the signal, while a too-high L may lead to overfitting around particular training points and not considering nearby test points.
> Reviewer:
> I would also be curious to have the performance of the different models of Figure 5 with the number of polynomials alongside the computational efficiency.
Thank you for this suggestion. We provide the accuracies of the models below. Note that SphereC+ does not have an L parameter to control the degree of interpolation, but an $r_{min}$ parameter that determines the minimum radius. We compare both using the maximum resolvably frequency formula $r_{min} = f_{max} = \frac{180°}{2L}$.
You can find the accuracies of the runtime experiment for Figure 5 below:
|__Spherical Harmonics__|L=2|L=5|L=10|L=20|L=40|
|-|-|-|-|-|-|
| Siren(SH) analytic|7.74 %|36.00 %|82.03 %|95.89 %|94.63 %|
|__SphereC+__|$r_{min}=90°$|$r_{min}=36°$|$r_{min}=18°$|$r_{min}=9°$|$r_{min}=4°$|
|Siren(SphereC+)|13.44 %|15.81 %|20.55 %|34.71 %|49.87 %|
Note that SphereC+ is not as accurate as in the comparison tables, as $r_{min}=4°$ is likely too restrictive (many, but not all, optimal $r_{min}$ hyperparameters are 1). We chose $r_{min}$ to be comparable to L rather than optimal with respect to predictive accuracy (as in Tables 1,2). Accuracy-wise, Siren(SH) with L=20 is slightly more accurate than Siren(SH) L=40. Hence, a higher L does not automatically lead to better accuracies.
> Reviewer:
> What is your take on SphereM poor performance?
Thank you for noticing that.
We double-checked our implementation of SphereM{+}, which corresponds exactly to the code provided by Mai et al., 2023.
To make sure, we also re-ran the land-ocean classification on a different computer (now Macbook Pro on CPU/originally a GPU workstation), which resulted in very similar results to Table 1b:
|PE, NN|Linear|FcNet|Siren|
|-|-|-|-|
|SphereC|$79.9 \pm 0.3$|$94.9 \pm 0.1$|$95.2 \pm 0.1$|
|SphereC+|$84.4 \pm 0.0$|$95.1 \pm 0.1$|$95.4 \pm 0.0$|
|SphereM|$74.0 \pm 0.0$|$89.0 \pm 0.3$|$88.3 \pm 0.4$|
|SphereM+|$81.9 \pm 0.2$|$91.6 \pm 0.2$|$93.7 \pm 0.1$|
|SH (ours)|$94.1 \pm 0.0$|$95.7 \pm 0.1$|$95.8 \pm 0.1$|
Hence, we do not have an explanation for the poor SphereM performance and can only stress that we run all models in the same environment.