hydroportail issueshttps://gitlab.irstea.fr/HYCAR-Hydro/hydroportail/-/issues2022-01-25T16:59:36+01:00https://gitlab.irstea.fr/HYCAR-Hydro/hydroportail/-/issues/1Allow get_ts_hydro to retrieve several features2022-01-25T16:59:36+01:00Delaigue OlivierAllow get_ts_hydro to retrieve several featuresAdd possibility to give a list or a vector of more than one element to the code argument.Add possibility to give a list or a vector of more than one element to the code argument.https://gitlab.irstea.fr/HYCAR-Hydro/hydroportail/-/issues/9Move 'barplot.regime' function from the 'regime" doc to a specific help page2022-01-25T16:59:18+01:00Delaigue OlivierMove 'barplot.regime' function from the 'regime" doc to a specific help pageTo make the `regime()` doc page more readable it would be necessary to move `barplot.regime()` function from the `regime()` doc to a specific help page.To make the `regime()` doc page more readable it would be necessary to move `barplot.regime()` function from the `regime()` doc to a specific help page.https://gitlab.irstea.fr/HYCAR-Hydro/hydroportail/-/issues/12Manage exported functions2022-01-25T17:00:32+01:00Delaigue OlivierManage exported functionsCurrently, all the functions are exported to facilitate development. Thus, they are listed in the manual.
However, it is not relevant to do so, especially for the `plot*()` functions.
In addition, I am not sure that it is relevant to ...Currently, all the functions are exported to facilitate development. Thus, they are listed in the manual.
However, it is not relevant to do so, especially for the `plot*()` functions.
In addition, I am not sure that it is relevant to create `plot` S3 methods for `HN`, `RR` and `TA` objects just to manage the type of plot.
Maybe it could be managed inside the `plot.ts_meteo()` function. It could simplify the readability of the index of the package functions for the user. Especially since the user never consciously manipulates these objects.
Maybe it is enough to keep only `plot.ts_hydro()` and `plot.ts_meteo()`.
Maybe it could be the same for the `regime` S3 methods.
I don't know if we should split the 'hydro' and 'meteo' functions.
I think that it more readable and easier to manage, but the code and documentation are sometimes a bit redundant.
The 'meta()` function is not currently splited `metats_hydro()` and `meta.ts_meteo()`.
By the way, it would be possible to detect automatically if it is a hydrological or meteorological feature by checking the feature code:
```r
# hydro
grepl("^\\d", "Y1234567")
[1] FALSE
# meteo
grepl("^\\d", "12345678")
[1] TRUE
```https://gitlab.irstea.fr/HYCAR-Hydro/hydroportail/-/issues/13Split 'utils' functions in many files2022-02-23T10:19:44+01:00Delaigue OlivierSplit 'utils' functions in many filesSplit private functions in various files according to the public functions they refer to.Split private functions in various files according to the public functions they refer to.https://gitlab.irstea.fr/HYCAR-Hydro/hydroportail/-/issues/14Manage sf_hydro_regions object2022-01-25T16:59:53+01:00Delaigue OlivierManage sf_hydro_regions objectShould we keep them as datasets or make a function that returns a different object depending on a 'territory' argument?
Currently, the package contains the following data sets:
- `sf_hydro_regions_gua`
- `sf_hydro_regions_met`
- `sf_hy...Should we keep them as datasets or make a function that returns a different object depending on a 'territory' argument?
Currently, the package contains the following data sets:
- `sf_hydro_regions_gua`
- `sf_hydro_regions_met`
- `sf_hydro_regions_mtq`
- `sf_hydro_regions_myt`
- `sf_hydro_regions_reu`
They could therefore be replaced by the following function:
```r
get_sf_hydro_regions(territory = "Mayotte")
```