Closed editorialbot closed 9 months ago
MGousseff
commented
11 months ago Error: processing vignette 'lczexplore_en.Rmd' failed with diagnostics: X11 font -adobe-helvetica-%s-%s---%d-------*, face 1 at size 9 could not be loaded --- failed re-building
I have no idea where this comes from as I don't specify the font anywhere. I wonder if it could come from the fact that there are bold fonts somewhere in the vignette ?
MGousseff
commented
11 months ago I don't see any community guidelines?
They are in the .github folder. I was told it is standard practice to put them there, but I can move them to the package root if you find it more convenient ?
Ha, I missed that. I am also unware about this "standard practice".
Neither contributing nor code of conduct shall be in the
.githubfolder. That is intended for interaction with GitHub APIs, not users or contributors. The optimal place is the root of the repository.
@martinfleis I followed what I saw in other repositories. Maybe they had github actions relative to this ? I will move these at the root of the package. Or do you think that jus integrating them at the end of the readme file is a better practice ? Less files, but a bit longer readme ? I'll move them to the root in the PR I'll do to include all the remarks of the reviewwers. Thank you all for the time spent.
martinfleis
commented
11 months ago @MGousseff Explicit files in the root are better in my opinion but either way is fine.
Not sure about the .github model but it is, from my perspective, wrong.
matthiasdemuzere
commented
11 months ago - Software paper: Quality of writing: Is the paper well written (i.e., it does not require editing for structure, language, or writing quality)?
Following my comments on Summary and A statement of need, perhaps you can critically look into the structure again? You currently try to convey two messages (LCZ and general map intercomparisons), which does not help the general story line?
I also noted some typos, or have other textual and content suggestions, eg.
MGousseff
commented
11 months ago I will look in details all this modifications. I didn't manage to reproduce the font problem on a virtual machine nor on another ubuntu machine. But the vignettes are not the vital part of the package. Maybe I will wait review from @wcjochem to integrate all modification in a single pull request ?
matthiasdemuzere
commented
11 months ago -Example usage: Do the authors include examples of how to use the software (ideally to solve real-world analysis problems).
(apologies for no longer following the order of the checklist, this will be the last one I address)
There is a good minimal example, that showcases the capacity of the tool using the data that was also used / produced in Bernard et al. (2023)
Now, as an additional stress-test, I'll check whether I can use some of the modules to compare two other LCZ maps, just to see if all works as expected. I'll try to look into this this evening, and will share my experiences here.
Ok, so I extracted two LCZ maps for the area of Rennes (France), from: 1) The LCZ Generator 2) The most recent global LCZ map (version 3)
For both maps, I selected the filtered LCZ band. The files are here: lcz_maps.zip
Let me try to read one map, for which I need importLCZraster.
There is documentation in there, though with quite some typos and honestly not very clear? But I see that I need the following usage:
importLCZraster(
dirPath,
zone = "europe",
bBox,
fileName = "EU_LCZ_map.tif",
column = "EU_LCZ_map",
typeLevels = c(`1` = "1", `2` = "2", `3` = "3", `4` = "4", `5` = "5", `6` = "6", `7` =
"7", `8` = "8", `9` = "9", `10` = "10", `101` = "11", `102` = "12", `103` = "13",
`104` = "14", `105` = "15", `106` = "16", `107` = "17")
)More or less clear, except how to get bBox? In the docs:
bBox: bBox is the bounding box needed to crop the wudapt tiff file.
It can be produced bu the importLCZvect function. It can
either be of class bBox or of class sfcMmm, ok. Not very clear? After some googling (remember I don't work with R), I decided to use something roughly based on the sanDiegobBoxCoord example (why use the CONUS map in this part whilst all other references refer to the EU map?):
RennesBoxCoord<-st_sf(a=1:2, geom=st_sfc(st_point(c(-1.93,47.95)), st_point(c(-1.41,48.29)),crs = 4326))
RennesBbox<-st_bbox(RennesBoxCoord)So far so good.
Then I read the map:
LCZ1<-importLCZraster(
dirPath,
fileName="9bce5ae7f3e297ebad75e6577fe1030b0d3c6ae6_lczfilter.tif",
column="lczFilter",
bBox=RennesBbox
)with and without defining typeLevels, as the role of this is not very clear?
Seems to work, and the labels are changed to 1-10,101-107 instead of the original 1-17 in the .tif
Then I try to plot this map:
showLCZ(LCZ1,column="lczfilter")
and get an error:
Error in `fct_recode()`:
! `.f` must be a factor or character vector, not a <NULL> object.
Run `rlang::last_trace()` to see where the error occurred.
Warning message:
In structure(x, class = setdiff(class(x), "sf")) :
Calling 'structure(NULL, *)' is deprecated, as NULL cannot have attributes.
Consider 'structure(list(), *)' instead.Mmm ... ok.
So let's try the cropped area from the global map.
LCZ2<-importLCZraster(
dirPath,
fileName="lcz_filter_globalmap.tif",
column="LCZ_Filter",
bBox=RennesBbox
)
showLCZ(LCZ2,column="LCZ_Filter")Now I got another error:
Error in grid.Call(C_textBounds, as.graphicsAnnot(x$label), x$x, x$y, :
invalid use of -176 < 0 in 'X11_MetricInfo'That's bad luck.
So I tried again, using the EU map you refer to in the importLCZrasterdescription.
LCZ_EU<-importLCZraster(
dirPath,
zone = "europe",
bBox=RennesBbox,
fileName = "EU_LCZ_map.tif",
column = "EU_LCZ_map",
typeLevels = c("1" = "1", "2" = "2", "3" = "3", "4" = "4", "5" = "5", "6" = "6", "7" =
"7", "8" = "8", "9" = "9", "10" = "10", "101" = "11", "102" = "12", "103" = "13",
"104" = "14", "105" = "15", "106" = "16", "107" = "17")
)
showLCZ(LCZ_EU,column="EU_LCZ_map")That gives me the same error:
Error in grid.Call(C_textBounds, as.graphicsAnnot(x$label), x$x, x$y, :
invalid use of -176 < 0 in 'X11_MetricInfo'Ok, none of this really worked for me.
But perhaps it is just local settings that does not allow me to plot attempt 2 and 3. So let's try to compare two maps:
comparison<-compareLCZ(sf1=LCZ2,column1="LCZ_Filter", wf1="Global map",
sf2=LCZ1, column2="lczFilter", wf2="Generator map",
ref=1, repr="standard", exwrite=F, location="Rennes")I get the text The column LCZ_Filter of the dataset LCZ2 is the reference against which the lczFilter column of the dataset LCZ1 will be compared. and then it keeps running. Already for over an hour now, so not sure whether this is still leading to something?
matthiasdemuzere
commented
11 months ago @MGousseff @martinfleis
Long story short on the above tests using some other datasets: I did not really get anywhere. And it does require some creativity from the user to understand what is needed.
My feeling about this work: it is clear that the routines have been developed for a very specific purpose, namely to support the research done for this manuscript. The minimal examples with the datasets from this effort seems to work well.
Then these routines are brought together and advertised here as an R package, not only to explore the difference between LCZ classifications, but also "any pair of classifications on geographical units" (as stated in the Summary).
After some testing I am not convinced that this bundle of scripts is mature enough to go forward with the review process in JOSS. I believe the routines in lczexplore can only be valuable and widely used if users can easily read and assess their own maps, without fiddling with the code to get the data/labels right. Of course also key functions should work (eg. compareLCZ), which is not the case for me, even though I am using common LCZ map databases.
MGousseff
commented
11 months ago For this error :
Then I try to plot this map: showLCZ(LCZ1,column="lczfilter")
I think it comes from the fact that when you import the file the column is named : column="lczFilter", and when you try to show it you call showLCZ(LCZ1,column="lczfilter") with a lower case f ?
wcjochem
commented
11 months ago I will look in details all this modifications. I didn't manage to reproduce the font problem on a virtual machine nor on another ubuntu machine. But the vignettes are not the vital part of the package. Maybe I will wait review from @wcjochem to integrate all modification in a single pull request ?
@MGousseff I already completed my checklist and have raised no new issues. From that perspective, my review is complete and I will not be monitoring this thread further. I think Matthias has raised valid concerns, and I leave that to an editorial decision from @martinfleis.
MGousseff
commented
11 months ago I will try and reproduce the example you gave to day and see if I can reproduce bugs. I agree than I am more used to deal with vector maps than raster maps, and the issue you raised comes from an error in the man file. There is no column to specify for a raster file, the name of the LCZ column is derived from the name of the file, it's an error I'll promptly correct. The following code works.
library(lczexplore)
library(sf)
pathEuWudaptMap<-"/home/gousseff/Documents/3_data/WUDAPTSources/WudaptEurope"
fileNameWudaptEurope<-"EU_LCZ_map.tif"
RennesBoxCoord<-st_sf(a=1:2, geom=st_sfc(st_point(c(-1.93,47.95)), st_point(c(-1.41,48.29)),crs = 4326))
RennesBbox<-st_bbox(RennesBoxCoord)
LCZ1<-importLCZraster(
dirPath=pathEuWudaptMap,
fileName=fileNameWudaptEurope,
bBox=RennesBbox
)
showLCZ(LCZ1,column="EU_LCZ_map")For the bounding box, what would seem an acceptable way to define it ? I tried to avoid calls to API as we have seen many sites modify their policies towards this. I confess that my workflow starts with vector reference, so producing the bbox from a vector reference map IS an oriented way of seeing this. A very simple roundabout is to use the getbb function from osmdata, which is quite commonly used by the R-spatial community. This would give the follwing code, which works very easily :
library(lczexplore)
library(sf)
library(osmdata)
pathEuWudaptMap<-"/home/gousseff/Documents/3_data/WUDAPTSources/WudaptEurope"
fileNameWudaptEurope<-"EU_LCZ_map.tif"
rennesBbox<-getbb( "Rennes",format_out = "sf_polygon")
LCZ1<-importLCZraster(
dirPath=pathEuWudaptMap,
fileName=fileNameWudaptEurope,
bBox=RennesBbox
)
showLCZ(LCZ1,column="EU_LCZ_map")
I am still reading your comment about redaction and will integrate them today.
matthiasdemuzere
commented
11 months ago The following code works.
library(lczexplore) library(sf) pathEuWudaptMap<-"/home/gousseff/Documents/3_data/WUDAPTSources/WudaptEurope" fileNameWudaptEurope<-"EU_LCZ_map.tif" RennesBoxCoord<-st_sf(a=1:2, geom=st_sfc(st_point(c(-1.93,47.95)), st_point(c(-1.41,48.29)),crs = 4326)) RennesBbox<-st_bbox(RennesBoxCoord) LCZ1<-importLCZraster( dirPath=pathEuWudaptMap, fileName=fileNameWudaptEurope, bBox=RennesBbox ) showLCZ(LCZ1,column="EU_LCZ_map")
Unfortunately not for me. I get the following graphic:
With this warnings in the terminal:
In grid.Call.graphics(C_path, x$x, x$y, index, switch(x$rule, ... :
Path drawing not available for this deviceIn Rstudio, I get the error on X11_MetricInfo.
Both errors might be related to the configuration of my OS itself? That of course not necessarily reflects the quality of your scripts.
Yet at the same time it also does not adhere to the guidelines of JOSS in terms of installation?
matthiasdemuzere
commented
11 months ago I think it comes from the fact that when you import the file the column is named :
column="lczFilter", and when you try to show it you callshowLCZ(LCZ1,column="lczfilter")with a lower case f ?
Indeed, my mistake.
Yet I get the same error as above when plotting, with an empty map.
MGousseff
commented
11 months ago I tried with RennesBoxCoord<-st_sf(a=1:2, geom=st_sfc(st_point(c(-1.93,47.95)), st_point(c(-1.41,48.29)),crs = 4326)) RennesBbox<-st_bbox(RennesBoxCoord) and with library(osmdata) ; rennesBbox<-getbb( "Rennes",format_out = "sf_polygon") and it works in both cases. I guess you changed
fileNameWudaptEurope<-"EU_LCZ_map.tif" to include your path ?
The very strange thing is that we are both on Ubuntu. Hard to believe the locale settings would have such an impact ? I'll try on yet another computer this morning.
MGousseff
commented
11 months ago I tried on another PC, which runs on windows, and I expected to be problematic. To my surprise it worked with the three ways to build the bBox : with a bBox built with the coordinates and the sf package, with the call to getbb from the package osmdata, and with a bBox built from a vector file using importLCZvect on an area a asking for bBox as an output. I fed these bBox to importLCZraster with the EU map available here as the raster source to crop, and in all three cases, the import and the plot worked seamlessly. I'm a bit at a loss as to why it doesn't work on your computer.
MGousseff
commented
11 months ago I am actively integrating the corrections you proposed. I will make a pull request with the corrections of the man page, the modifications of the article. The only corrections I don't understand is the problem you stated with the reference which didn't seem to appeared bugged on my version of the paper.pdf.
MGousseff
commented
11 months ago The link to Huang et al doesn't seem to work, could you send me the DOI ? I am already reading the other reference. Thank you.
MGousseff
commented
11 months ago I think it should link to this paper that I''m now currently reading. Thank you for the ref.
ebocher
commented
11 months ago @MGousseff
I think it should link to this paper that I''m now currently reading. Thank you for the ref.
We are talking about a paper published after this one ? It's an unusual suggestion.
@matthiasdemuzere
Long story short on the above tests using some other datasets: I did not really get anywhere. And it does require some creativity from the user to understand what is needed.
A long story and a long waiting review in balance ;-) . Let me tell you : If there was an error when comparing with raster data, due to the documentation, LZCExplorer is used without any issues to compare vector data with urban planners, students and colleagues.
But in general, I'm more intrigued by your position on the story line and the usefulness of the tool.
Now, I realize we already had an extensive discussion on the need for a tool to compare LCZ maps. I don't want to go back there, and will leave it up to the user community to decide whether this is useful.
Comparing model outputs, and in our case maps, is a natural approach in GIS science if you want to be able to assess the relevance of a method. Despite WUDAPT's long experience in producing LCZs, there's nothing to suggest that this method is any better than maps produced by human or by any other tool. The opposite is true. ;-)
I hope @MGousseff will have the energy to include all the new comments.
We are therefore aware of the limited technical contribution of this tool, but its use corresponds to a real need for evaluating different LCZ classifications.
At the end , as @wcjochem wrote "leave that to an editorial decision from @martinfleis" will be the best option.
Best regards
@j3r3m1
MGousseff
commented
11 months ago After retest : there wasn't any error in importLCZraster, not even in the examples. The arg column is the name you want to give to the output, not a column to look for in the tif input. I was worried as this would have been detected by the unit tests, but the tests are OK so far.
I added as an example a way to get the bounding box with osmdata package. It didn't seem useful to include a dedicated function as it is already present in this package.
About the example with the CONUS map, it seemed better to also put an example with data not included in the package, so that the user doesn't think only rasters included in the package could be used. Plus it showed WUDAPT maps were available worldwide !
I added the reference to american and world maps as suggested. I didn't add the Huang review, as it was published after the submission of our article (and seems quite focused on remote sensor based methods). I checked after today's pull request, I can't see the problems you noted about the references. I hoped I'm looking at the right place.
About the structure of the paper, I think it reflects the community which is most likely to use it : people comparing LCZ maps. Yet, if a package allowed map comparison with ease, maybe lczexplore wouldn't be useful, hence the part about comparing maps, as a first subsection of the statement of need. By the way, I have to thank you, as your remarks made me add this section, and thus add the Cohen's Kappa as a better indicator of agreement than only the percentage of agreeing surface.
I hope I fixed all the typo you noted. The space before ":" is due to french habits ! Corrected in the paper and in the vignettes !
I moved the CODE_OF_CONDUCT.md and CONTRIBUTING.md to the root of the package. I understood why some R coders hid it in the .github : it raises a note in R Check, as they are not considered standard files at the root of an R package. I think we can accept a note (not a warning or an error) and have a far better visibility for these files.
As stated by the reviewers and our team, the scope of the package may seem narrow, but our collaborations with various users make us think it is useful, helps gain productivity and insights. Therefore, it is probably up to JOSS and @martinfleis to decide whether it is worth being published in the journal.
Whatever the decision, I thank you @wcjochem @matthiasdemuzere @martinfleis @ebocher for the improvements I could make thanks to all the remarks.
matthiasdemuzere
commented
10 months ago @MGousseff
I think it should link to this paper that I''m now currently reading. Thank you for the ref.
We are talking about a paper published after this one ? It's an unusual suggestion.
This JOSS paper is still under review. So why not update it with the most recent information?
@matthiasdemuzere
Long story short on the above tests using some other datasets: I did not really get anywhere. And it does require some creativity from the user to understand what is needed.
A long story and a long waiting review in balance ;-) . Let me tell you : If there was an error when comparing with raster data, due to the documentation, LZCExplorer is used without any issues to compare vector data with urban planners, students and colleagues.
Then perhaps this use should be better reflected in the statement of need. So far, I have not been able to use the package with my own raster data. So unfortunately I can not share this experience of usefulness.
But in general, I'm more intrigued by your position on the story line and the usefulness of the tool.
Now, I realize we already had an extensive discussion on the need for a tool to compare LCZ maps. I don't want to go back there, and will leave it up to the user community to decide whether this is useful.
Comparing model outputs, and in our case maps, is a natural approach in GIS science if you want to be able to assess the relevance of a method. Despite WUDAPT's long experience in producing LCZs, there's nothing to suggest that this method is any better than maps produced by human or by any other tool. The opposite is true. ;-)
I am not stating anywhere that the WUDAPT method is better than any other. I just wanted to convey that - for me personally - I don't see the added value of idenfying the (dis)similarity between map A and B without knowing the best available reference.
I hope @MGousseff will have the energy to include all the new comments.
We are therefore aware of the limited technical contribution of this tool, but its use corresponds to a real need for evaluating different LCZ classifications.
Again, I am willing to follow that storyline, but why not convince me than via the statement of need?
At the end , as @wcjochem wrote "leave that to an editorial decision from @martinfleis" will be the best option.
Best regards
@j3r3m1
I am getting the feeling that the authors think I can not provide an impartial assessment of this work. In that case, there is no point for me to continue my review duties. As with any other accepted review assignment, I always try to deliver an unbiased assessment to the best of my abilities. But I'd leave that to @martinfleis.
matthiasdemuzere
commented
10 months ago After retest : there wasn't any error in importLCZraster, not even in the examples. The arg column is the name you want to give to the output, not a column to look for in the tif input.
I see. That was not clear to me from the docs:
column: indicates the name of the column containing LCZ values, all
otherI was worried as this would have been detected by the unit tests, but the tests are OK so far.
Reading the geotif is not the problem. So this piece of code works.
RennesBoxCoord<-st_sf(a=1:2, geom=st_sfc(st_point(c(-1.97,48)), st_point(c(-1.40,48.1)),crs = 4326))
rennesBbox<-st_bbox(RennesBoxCoord)
#rennesBbox<-getbb( "Rennes",format_out = "sf_polygon") #
LCZ1<-importLCZraster(
dirPath="/mnt/SSD2TB/data/FIGSHARE/LCZ_EU/v4",
zone = "europe",
bBox=rennesBbox,
fileName = "EU_LCZ_map.tif",
column = "EU_LCZ_map",
typeLevels = c(`1` = "1", `2` = "2", `3` = "3", `4` = "4", `5` = "5", `6` = "6", `7` =
"7", `8` = "8", `9` = "9", `10` = "10", `101` = "11", `102` = "12", `103` = "13",
`104` = "14", `105` = "15", `106` = "16", `107` = "17")
)
LCZ1 is a Simple feature collection with 47858 features and 1 field.
But I can not plot this using showLCZ(LCZ1,column="EU_LCZ_map")
In Rstudio I get this error without a plot:
Error in grid.Call(C_textBounds, as.graphicsAnnot(x$label), x$x, x$y, :
invalid use of -176 < 0 in 'X11_MetricInfo'In a terminal I get an empty plot with legend, and this error:
50: In grid.Call.graphics(C_path, x$x, x$y, index, switch(x$rule, ... :
Path drawing not available for this deviceOthers have identified this as well (eg. here), though I don't really see a solution?
My R session info (the same in R and Rstudio):
> sessionInfo()
R version 4.3.0 (2023-04-21)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Ubuntu 22.04.3 LTS
Matrix products: default
BLAS/LAPACK: /usr/lib/x86_64-linux-gnu/openblas-pthread/libopenblasp-r0.3.20.so; LAPACK version 3.10.0
locale:
[1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C LC_TIME=nl_BE.UTF-8 LC_COLLATE=en_US.UTF-8 LC_MONETARY=nl_BE.UTF-8 LC_MESSAGES=en_US.UTF-8
[7] LC_PAPER=nl_BE.UTF-8 LC_NAME=C LC_ADDRESS=C LC_TELEPHONE=C LC_MEASUREMENT=nl_BE.UTF-8 LC_IDENTIFICATION=C
time zone: Europe/Brussels
tzcode source: system (glibc)
attached base packages:
[1] stats graphics grDevices utils datasets methods base
other attached packages:
[1] osmdata_0.2.5 lczexplore_0.0.1.0002 sf_1.0-14
loaded via a namespace (and not attached):
[1] gld_2.6.6 gtable_0.3.4 ggplot2_3.4.4 htmlwidgets_1.6.2 devtools_2.4.5 remotes_2.4.2.1 processx_3.8.2 lattice_0.21-8 callr_3.7.3
[10] vctrs_0.6.4 tools_4.3.0 ps_1.7.5 generics_0.1.3 tibble_3.2.1 proxy_0.4-27 fansi_1.0.5 pkgconfig_2.0.3 Matrix_1.5-4
[19] KernSmooth_2.23-20 data.table_1.14.8 RColorBrewer_1.1-3 readxl_1.4.3 rootSolve_1.8.2.4 lifecycle_1.0.3 farver_2.1.1 compiler_4.3.0 stringr_1.5.0
[28] Exact_3.2 munsell_0.5.0 terra_1.7-55 codetools_0.2-19 httpuv_1.6.11 htmltools_0.5.6.1 usethis_2.2.2 DescTools_0.99.50 class_7.3-21
[37] later_1.3.1 pillar_1.9.0 crayon_1.5.2 urlchecker_1.0.1 tidyr_1.3.0 MASS_7.3-58.4 ellipsis_0.3.2 classInt_0.4-10 cachem_1.0.8
[46] sessioninfo_1.2.2 boot_1.3-28.1 mime_0.12 tidyselect_1.2.0 digest_0.6.33 mvtnorm_1.2-3 stringi_1.7.12 dplyr_1.1.3 purrr_1.0.2
[55] forcats_1.0.0 cowplot_1.1.1 fastmap_1.1.1 grid_4.3.0 expm_0.999-7 lmom_3.0 colorspace_2.1-0 cli_3.6.1 magrittr_2.0.3
[64] pkgbuild_1.4.2 utf8_1.2.3 e1071_1.7-13 withr_2.5.1 prettyunits_1.2.0 scales_1.2.1 promises_1.2.1 httr_1.4.7 cellranger_1.1.0
[73] memoise_2.0.1 shiny_1.7.5.1 miniUI_0.1.1.1 profvis_0.3.8 rlang_1.1.1 Rcpp_1.0.11 xtable_1.8-4 glue_1.6.2 DBI_1.1.3
[82] pkgload_1.3.3 rstudioapi_0.15.0 R6_2.5.1 fs_1.6.3 units_0.8-4 I added as an example a way to get the bounding box with osmdata package. It didn't seem useful to include a dedicated function as it is already present in this package.
I tried to use rennesBbox<-getbb( "Rennes",format_out = "sf_polygon") when reading the EU map with the above script. But that process was still running after 15min, so I killed it. The sf approach does seem to work.
About the example with the CONUS map, it seemed better to also put an example with data not included in the package, so that the user doesn't think only rasters included in the package could be used. Plus it showed WUDAPT maps were available worldwide !
I understand your reasoning. But also the EU map is not included in the package itself? So why not:
I added the reference to american and world maps as suggested. I didn't add the Huang review, as it was published after the submission of our article (and seems quite focused on remote sensor based methods). I checked after today's pull request, I can't see the problems you noted about the references. I hoped I'm looking at the right place.
I am not 100% sure what note you refer to? Probably my note on having the references that are embedded within a sentence in between (). Eg. As stated in (Visser & De Nijs, 2006) ... This should be: As stated in Visser & De Nijs (2006). See the JOSS citation guidelines
About the structure of the paper, I think it reflects the community which is most likely to use it : people comparing LCZ maps. Yet, if a package allowed map comparison with ease, maybe lczexplore wouldn't be useful, hence the part about comparing maps, as a first subsection of the statement of need. By the way, I have to thank you, as your remarks made me add this section, and thus add the Cohen's Kappa as a better indicator of agreement than only the percentage of agreeing surface.
I am not sure if you now kept or removed the part about comparing non-LCZ maps? In any case, given the package "breaths" LCZ (package name, its title, functions names, examples etc), perhaps just focus on LCZ mapping only, to simplify the narrative?
I hope I fixed all the typo you noted. The space before ":" is due to french habits ! Corrected in the paper and in the vignettes !
Ok.
I moved the CODE_OF_CONDUCT.md and CONTRIBUTING.md to the root of the package. I understood why some R coders hid it in the
.github: it raises a note in R Check, as they are not considered standard files at the root of an R package. I think we can accept a note (not a warning or an error) and have a far better visibility for these files.Ok
As stated by the reviewers and our team, the scope of the package may seem narrow, but our collaborations with various users make us think it is useful, helps gain productivity and insights. Therefore, it is probably up to JOSS and @martinfleis to decide whether it is worth being published in the journal.
Whatever the decision, I thank you @wcjochem @matthiasdemuzere @martinfleis @ebocher for the improvements I could make thanks to all the remarks.
MGousseff
commented
10 months ago I see. That was not clear to me from the docs:
column: indicates the name of the column containing LCZ values, all other
So sorry, I corrected the example but not the argument description, it is fixed now, thank you.
The plot bug is really very strange. I didn't manage to reproduce it, neither on Linux (with French and English locales) or on Windows. The link you provided shows that some of those who encountered it couldn't explain it either. The underlying libraries used for plotting are sf for the data and ggplot2 for the graphics productions, which are quite standard libraries ! I may try to use tmap to produce the maps in a future version, if I do so, maybe you can see if it works better ? But I still can't explain why no other user of the package would face this bug. Does it also happen when you use showLCZ() after importing a vector with importLCZvect() ? If so, it is strange. I do not dismiss this is a bug, but as you pointed, it is seen by users not using lczexplore and may be a problem of either sf or ggplot2 ?
Even weirder is your stalling with the getbb function. Below is the time it took on my R install :
system.time(rennesBbox<-getbb( "Rennes",format_out = "sf_polygon"))
user system elapsed
0.501 0.000 1.307 About the maps : what is included in the package is a tiny area cropped from the wudapt map in order to illustrate the use, but not to include a heavy tif in the package. The link to wudapt's web page is included in the vignette dedicated to comparison of raster and vector maps.
About the reference, they are produced by the github action from the paper.md and paper.bib, I think it should be okay with JOSS guidelines ? If not, I have to investigate why the github action would produce something different, maybe my bib file is not standard ? I redid a pull request in case the action would not have worked as intended.
About Focusing on LCZ and not including the possibility to compare other categorical maps. It was our first approach. Then, working with specialists of urban development and urban climate, it appeared that they use other types of classifications quite frequently, like utrf, or even urban planning zoning, and they saw the importQualVar() function as quite useful.
I don't think our difference of points of view is that controversial nor problematic.
I don't see the added value of idenfying the (dis)similarity between map A and B without knowing the best available reference.
In our own practice, when we compared some maps produced from OpenStreetMap data or from BD_TOPO data, highlighting the disagreements wasn't a way to blame one or the other source of data, but to understand what the differences could teach us. I find very hard to grasp how one could not find interesting to see how two methods differ on the same area.
Let's imagine a theoretical situation : you produce a map from satellite images, but you have no prior expert knowledge on this area. Then, you work with ground experts, who can qualify some areas, and you can now use this information to train a machine learning algorithm on this area and produce a refined map. Wouldn't it be useful to see how the use of expert knowledge modifies the classification, where, and how the old values are broken-down into the new values ? There is no "absolute ground truth" either, but a useful insight as to how expert knowledge impacted the new vision of the territory ? Does this example seem somehow relevant to you ? I hope so.
I think I took into account most of the improvements you suggested, to the package and the article, and they helped improve both.
@martinfleis Please let me know if you feel I need to do something else to help the editor about the decision regarding this paper.
matthiasdemuzere
commented
10 months ago The plot bug is really very strange. I didn't manage to reproduce it, neither on Linux (with French and English locales) or on Windows. The link you provided shows that some of those who encountered it couldn't explain it either. The underlying libraries used for plotting are
sffor the data andggplot2for the graphics productions, which are quite standard libraries ! I may try to usetmapto produce the maps in a future version, if I do so, maybe you can see if it works better ? But I still can't explain why no other user of the package would face this bug. Does it also happen when you useshowLCZ()after importing a vector withimportLCZvect()? If so, it is strange. I do not dismiss this is a bug, but as you pointed, it is seen by users not usinglczexploreand may be a problem of eithersforggplot2?
Well, as I am a user of lczexplore, this was blocking me of course completely.
But ... good thing I am a persistent user when it comes to software bugs.
So, I completely removed the R environment on my system and did a fresh install. After that I also installed lczexplore again. And good news: this fresh install was able to build the vignettes, and I am now able to explore the package using my own data, and visualize the results. Unfortunately I have not been able to identify the problem in my previous set-up, so I can't provide feedback on this.
But since the package now works for me, I can do some tests.
Both in terms of terms of all LCZ classes as well as grouped classes. This exercise also tests the capacity to read a large-scale map, and the re-projection of the EU map, that is in a different coordinate system than the Global map. This works fine, as you can see for the grouped comparison below.
library(lczexplore)
library(sf)
#bBox Rennes
RennesBoxCoord<-st_sf(a=1:2, geom=st_sfc(st_point(c(-1.78,48.05)), st_point(c(-1.55,48.2)),crs = 4326))
rennesBbox<-st_bbox(RennesBoxCoord)
#rennesBbox<-getbb( "Rennes",format_out = "sf_polygon")
LCZ1<-importLCZraster(
dirPath="/mnt/SSD2TB/data/FIGSHARE/LCZ_EU/v4",
zone = "europe",
bBox=rennesBbox,
fileName = "EU_LCZ_map.tif",
column = "EU_LCZ_map",
typeLevels = c(`1` = "1", `2` = "2", `3` = "3", `4` = "4", `5` = "5", `6` = "6", `7` =
"7", `8` = "8", `9` = "9", `10` = "10", `101` = "11", `102` = "12", `103` = "13",
`104` = "14", `105` = "15", `106` = "16", `107` = "17")
)
showLCZ(LCZ1,column="EU_LCZ_map")
LCZ2<-importLCZraster(
dirPath="/mnt/SSD2TB/data/ZENODO/LCZ_GLOBAL/v3",
zone = "global",
bBox=rennesBbox,
fileName = "lcz_filter_v3.tif",
column = "lcz_filter_v3",
typeLevels = c(`1` = "1", `2` = "2", `3` = "3", `4` = "4", `5` = "5", `6` = "6", `7` =
"7", `8` = "8", `9` = "9", `10` = "10", `101` = "11", `102` = "12", `103` = "13",
`104` = "14", `105` = "15", `106` = "16", `107` = "17")
)
showLCZ(LCZ2,column="lcz_filter_v3")
## Comparison
comparison<-compareLCZ(sf1=LCZ1,column1="EU_LCZ_map", wf1="LCZ EU",
sf2=LCZ2,column2="lcz_filter_v3",wf2="LCZ Globe", ref=1,
repr="standard",exwrite=F,location="Rennes",
saveG="/home/matthias/Documents/reviews/Gousseff_lcz_explore_review/compareLCZ.png")
## Comparison - grouped
LCZ1grouped<-groupLCZ(LCZ1,column="EU_LCZ_map",
urban=c("1","2","3","4","5","6","7","8"),
industry="10",
vegetation=c("9", "101","102","103","104"),
impervious="105",pervious="106",water="107",colors=c("red","black","green","grey","burlywood","blue"))
LCZ2grouped<-groupLCZ(LCZ2,column="lcz_filter_v3",
urban=c("1","2","3","4","5","6","7","8"),
industry="10",
vegetation=c("9", "101","102","103","104"),
impervious="105",pervious="106",water="107",colors=c("red","black","green","grey","burlywood","blue"))
comparisonGrouped<-compareLCZ(sf1=LCZ1grouped,column1="grouped",
sf2=LCZ2grouped, column2="grouped",
repr="alter",
levels=c("urban","industry","vegetation","impervious","pervious","water"),
colors=c("red","black","green","grey","burlywood","blue"),
saveG="/home/matthias/Documents/reviews/Gousseff_lcz_explore_review/compareLCZgrouped.png")
I'll do some more testing, so stay tuned!
MGousseff
commented
10 months ago @matthiasdemuzere I find it very kind of you to have taken the time to redo an install from scratch, and I am sorry the first installation didn't work.
If I understand your example, after grouping, one can see, for instance, that what was seen as water in the EU_map is seen in the world map as water for only 49% and as some vegetation for 37% and as urban for 14%. The default workflows are "BDTOPO V2.2" for the first dataset and "OSM" for the second dataset, and it reflects our main usage, but of course, you could have set them to wf1="Europe map" and wf2=" World map", and the labels would have followed.
All publication matters set aside, I'm really glad you could install the package, that it works, and that you took time to think of a testing use case. Maybe my last comment better reframed a usefull situation, and I should have started by this example.
I'm sure that given your conscientiousness you will now find new bugs for me to fix ! Game may be back on for a little moment, and I'm eager to fix any problem you may find.
Thank you for your persistance.
matthiasdemuzere
commented
10 months ago As the LCZ generator geotiff (get it here) contains 3 bands, for simplicity I first extracted the lczFilter band, to have one band only.
gdal_translate -b 2 86bb1a1c28c6faa2c3cd109867b8ef5f87054d98.tif 86bb1a1c28c6faa2c3cd109867b8ef5f87054d98_lczfilter.tif
Using this code provides me with an error:
#Define Bbox
BoxCoord<-st_sf(a=1:2, geom=st_sfc(st_point(c(150.5,-34.15)), st_point(c(151.3,-33.6)),crs = 4326))
Bbox<-st_bbox(BoxCoord)
#rennesBbox<-getbb( "Rennes",format_out = "sf_polygon")
LCZ1<-importLCZraster(
dirPath="/home/matthias/Documents/reviews/Gousseff_lcz_explore_review",
# zone = "europe",
bBox=Bbox,
fileName = "86bb1a1c28c6faa2c3cd109867b8ef5f87054d98_lczfilter.tif",
column = "LCZ1",
typeLevels = c(`1` = "1", `2` = "2", `3` = "3", `4` = "4", `5` = "5", `6` = "6", `7` =
"7", `8` = "8", `9` = "9", `10` = "10", `101` = "11", `102` = "12", `103` = "13",
`104` = "14", `105` = "15", `106` = "16", `107` = "17")
)Error:
Error in `stopifnot()`:
ℹ In argument: `LCZ1 = fct_recode(...)`.
Caused by error:
! `LCZ1` must be size 545302 or 1, not 0.
Run `rlang::last_trace()` to see where the error occurred.But, when I change column = lczFilter (the actual name of the band in the geotiff), it does work. So this seems to contradict your previous statement that column only refers to the name of the column that is provided to the data object?
So now I am able to read the LCZ Generator map.
Reading the global map works as well, but the LCZ labels are not converted to the pre-defined types. This seems to be due to the nodata values in the clipped LCZ map, since the global map often has no LCZ labels over oceans. Perhaps future versions of the code should introduce a treatment of missing values?
For now I just clipped a smaller area of interest, just to complete the test.
BoxCoord<-st_sf(a=1:2, geom=st_sfc(st_point(c(151.0,-33.7)), st_point(c(151.2,-33.97)),crs = 4326))
Bbox<-st_bbox(BoxCoord)Since the compareLCZ process seems to hang for a while now, I further decreased the area of interest.
BoxCoord<-st_sf(a=1:2, geom=st_sfc(st_point(c(151.0,-33.7)), st_point(c(151.1,-33.8)),crs = 4326))
Bbox<-st_bbox(BoxCoord)The comparison sections have been running for more than half an hour now, without completing.
As there is no messaging on the command line (except The column lczFilter of the dataset LCZ1 is the reference against which the lcz_filter_v3 column of the dataset LCZ2 will be compared.), it is hard to say whether anything breaks in the process, or whether it is just slow. So:
comparison<-compareLCZ(sf1=LCZ1,column1="lczFilter", wf1="LCZ Generator",
sf2=LCZ2,column2="lcz_filter_v3",wf2="LCZ Globe", ref=1,
repr="standard",exwrite=F,location="Sydney",
saveG="/home/matthias/Documents/reviews/Gousseff_lcz_explore_review/compareLCZ_Sydney.png")
## Comparison - grouped
LCZ1grouped<-groupLCZ(LCZ1,column="lczFilter",
urban=c("1","2","3","4","5","6","7","8"),
industry="10",
vegetation=c("9", "101","102","103","104"),
impervious="105",pervious="106",water="107",
colors=c("red","black","green","grey","burlywood","blue"))
LCZ2grouped<-groupLCZ(LCZ2,column="lcz_filter_v3",
urban=c("1","2","3","4","5","6","7","8"),
industry="10",
vegetation=c("9", "101","102","103","104"),
impervious="105",pervious="106",water="107",colors=c("red","black","green","grey","burlywood","blue"))
comparisonGrouped<-compareLCZ(sf1=LCZ1grouped,column1="grouped",
sf2=LCZ2grouped, column2="grouped",
repr="alter",
levels=c("urban","industry","vegetation","impervious","pervious","water"),
colors=c("red","black","green","grey","burlywood","blue"),
saveG="/home/matthias/Documents/reviews/Gousseff_lcz_explore_review/compareLCZgrouped_Sydney.png") Yet instead of using the WUDAPT .tif as part of the package, I clip it from the global LCZ map v3.
All seems to work fine, as you can see from the grouped comparison results below.
I like the vignettes, though I do think they could be cleaned a bit:
These comments apply to all vignettes, so please double-check.
Code and result of my test.
library(lczexplore)
library(osmdata)
library(sf)
redonBbox<-importLCZvect(dirPath=paste0(system.file("extdata", package = "lczexplore"),
"/bdtopo_2_2/Redon"), file="rsu_lcz.geojson",column="LCZ_PRIMARY",output="bBox")
redonWudapt<-importLCZraster(
dirPath="/mnt/SSD2TB/data/ZENODO/LCZ_GLOBAL/v3",
zone = "europe",
bBox=redonBbox,
fileName = "lcz_filter_v3.tif",
column = "lcz_filter_v3",
typeLevels = c("1" = "1", "2" = "2", "3" = "3", "4" = "4", "5" = "5", "6" = "6", "7" =
"7", "8" = "8", "9" = "9", "10" = "10", "101" = "11", "102" = "12", "103" = "13",
"104" = "14", "105" = "15", "106" = "16", "107" = "17")
)
st_crs(redonWudapt)
# Path to embedded Data
dirPath<-paste0(system.file("extdata",package="lczexplore"),"/")
# Path to OSM data specifically
dirPathOSM<-paste0(dirPath,"osm/2022/Redon")
# loading Redon Data produced with GeoClimate on OSM input Data
redonOSM<-importLCZvect(dirPath=dirPathOSM,file="rsu_lcz.geojson",column = "LCZ_PRIMARY", drop=TRUE)
summary(redonOSM$LCZ_PRIMARY)
## Comparison
compareLCZ(sf1 = redonWudapt, column1 = "lcz_filter_v3", wf1="WUDAPT",
sf2 = redonOSM, column2 = "LCZ_PRIMARY", wf2 = "GeoClimate_OSM",
ref=1 ,exwrite=FALSE,
saveG="/home/matthias/Documents/reviews/Gousseff_lcz_explore_review/lczexplore_raster_vector_redon.png")
## Comparison - grouped
# Regroup levels of the WUDAPT sf file.
redonWudaptGrouped<-groupLCZ(redonWudapt,column="EU_LCZ_map",
urban=c("1","2","3","4","5","6","7","8","9"),
industry="10", vegetation=c("101","102","103","104"),
impervious="105",pervious="106",water="107", outCol = "Regrouped")
# Regroup levels of the GeoClimate sf file
redonOSMgrouped<-groupLCZ(redonOSM, column="LCZ_PRIMARY",
urban=c("1","2","3","4","5","6","7","8","9"),
industry="10", vegetation=c("101","102","103","104"),
impervious="105",pervious="106",water="107", outCol = "Regrouped")
# Pass the files, the columsn and a vector of colors associated to the broader categories
compareLCZ(sf1 = redonWudaptGrouped, column1 = "Regrouped", wf1 = "Wudapt",
sf2 = redonOSMgrouped, column2 = "Regrouped", wf2 = " GeoClimate on OSM data",
exwrite = FALSE, plot=TRUE, repr="alter", levels=c("urban","industry","vegetation","impervious","pervious","water"),
colors=c("red","black","green","grey","burlywood","blue"),
saveG="/home/matthias/Documents/reviews/Gousseff_lcz_explore_review/lczexplore_raster_vector_redon_grouped.png")
#> The column Regrouped of the dataset redonWudaptGrouped is the reference against which the Regrouped column of the dataset redonOSMgrouped will be compared.
#> Both sf datasets need to live in the same crs projection (srid / epsg),
#> they will be coerced to the specified reference (redonWudaptGrouped)
#> Warning: attribute variables are assumed to be spatially constant throughout all
#> geometries
#> Warning: attribute variables are assumed to be spatially constant throughout all
#> geometries I like this idea, so I wanted to test it out ,using the probability layer that is embedded within the WUDAPT-based LCZ maps. This probability reflects the number of types the modal LCZ is assigned to a pixel during 25 bootstraps.
But .... I realized this procedure is only available for the vector files read by importLCZvect, and not with the raster files read by importLCZraster.
Too bad, perhaps this should become a new feature in upcoming releases.
matthiasdemuzere
commented
10 months ago Even weirder is your stalling with the getbb function. Below is the time it took on my R install :
system.time(rennesBbox<-getbb( "Rennes",format_out = "sf_polygon")) user system elapsed 0.501 0.000 1.307
The problem is not in getting the bounding box. It exists when using this (rennesBbox<-getbb( "Rennes",format_out = "sf_polygon")) bounding box in clipping the map. For the EU map it does not seem to work, it does however when clipping from the global map? Or perhaps it takes long for the EU map because a reprojection is required?
I am not sure how you documented the definition of creating a bounding box in the updated version (via sf or osmdata, but perhaps it makes sense to double-check if it really works?
About the reference, they are produced by the github action from the paper.md and paper.bib, I think it should be okay with JOSS guidelines ? If not, I have to investigate why the github action would produce something different, maybe my bib file is not standard ? I redid a pull request in case the action would not have worked as intended.
Instead of using [@REF], you need to use @REF for references as part of sentences. See eg. my W2W JOSS paper and references in there.
About Focusing on LCZ and not including the possibility to compare other categorical maps. It was our first approach. Then, working with specialists of urban development and urban climate, it appeared that they use other types of classifications quite frequently, like utrf, or even urban planning zoning, and they saw the
importQualVar()function as quite useful.That I understand. Yet all scripts are really tailored towards LCZs (and have LCZs in their name). Also, to me the JOSS text does not work trying to have both audiences targeted at the same time. It just makes things confusing? I see two possible pathways:
- Target mainly LCZ users, and add a small note somewhere that these scripts can be used on other maps as well. No need to change the codes
- Revise the whole manuscript and the codes to make it generic, and then use LCZs as just one example, given the interest of this scheme in the urban climate community.
If I where you, I would opt for 1.
Perhaps analogues: the LCZ Generator tool could be used to map any type of land cover or landscape feature, as long as you provide the expected training label names. But for simplicity, we did not include this in the paper.
I don't think our difference of points of view is that controversial nor problematic.
I don't see the added value of idenfying the (dis)similarity between map A and B without knowing the best available reference.
In our own practice, when we compared some maps produced from OpenStreetMap data or from BD_TOPO data, highlighting the disagreements wasn't a way to blame one or the other source of data, but to understand what the differences could teach us. I find very hard to grasp how one could not find interesting to see how two methods differ on the same area.
Let's imagine a theoretical situation : you produce a map from satellite images, but you have no prior expert knowledge on this area. Then, you work with ground experts, who can qualify some areas, and you can now use this information to train a machine learning algorithm on this area and produce a refined map. Wouldn't it be useful to see how the use of expert knowledge modifies the classification, where, and how the old values are broken-down into the new values ? There is no "absolute ground truth" either, but a useful insight as to how expert knowledge impacted the new vision of the territory ? Does this example seem somehow relevant to you ? I hope so.
The part that starts with ground experts ... you do know you just described "the" WUDAPT approach no?? Irony?
That said. No, unfortunately I do not share the same interest. I've been making LCZ maps for years now, and my main concern is to make sure to reach a certain level of quality. This is something we typically do by bootstrapping and accuracy assessment against the expert labels, or via independent products that serve as proxies for the underlying paramater values. Not perfect no, as it also has its limitations (always described transparently in papers or here).
I don't see how comparing two maps can serve this. Two maps could be similar, but because of false positives. Or dissimilar because of true negatives. Or anything in between. But that does not tell me really what I should focus to improve the accuray, nor what features or procedures I should use to make one of the two maps better.
So we do see things differently. But as said, I leave it up to the community to assess the value of this package. So I will not get back to this anymore.
I think I took into account most of the improvements you suggested, to the package and the article, and they helped improve both.
@martinfleis Please let me know if you feel I need to do something else to help the editor about the decision regarding this paper.
matthiasdemuzere
commented
10 months ago @martinfleis: it has taken me a long time to delve into this. And now I finally did. Trying to be critical yet constructive at the same time, which has been rather time-consuming.
I have updated my reviewers check list.
As you might have seen from the discussions above, the authors and myself not always agree on things. But this disagreement does not outweigh the work that has been put in these scripts. I was able to test most of them, also with unseen data, and they perform as expected.
I do think that the paper itself needs some work still. In terms of structure, text and clarity. The same might be true for some module docs and vignettes. I am willing to read JOSS paper one more time when revised, but other than that I can not put more time in this review ....
MGousseff
commented
10 months ago @matthiasdemuzere
1) I didn't think of the possibility to have a confidence value as a band of a raster, and I didn't know you had one layer of probability included in the map rasters : I am coding it right now. The terra package, on which lczexplore relies for raster allows this, and it would allow the use of the sensitivity analysis when comparing raster maps: very interesting.
2) There was absolutely no irony in my use case example. I'm sorry if sometimes text written in a a language which is not my first doesn't convey the proper tone. It was, indeed, inspired from the workflow of wudapt, as I tried to find a case which could be useful in your frame of work.
3) About the vignettes. The graphic library I use is ggplot2. When one executes the chunks of code it renders quite well, as one can zoom at will, but it seems to render poorly when a vignette is built. I'll try to tweak graphics size, and if it doesn't behave properly, I'll export the graphs to png and upload them in the vignette (I did it for one of the figure and is why you saw it as duplicate, but it makes the package heavier). Or if you consider this being a problem, I'll get rid of the vignettes until I have fixed the issue (vignettes are not a core part of the package).
4) About the article. I'm a bit surprised about your point of view. I added the part about map utility as a response to your concern of may 24 :
Once you know about the difference / agreements between two maps, what then? How will you use this information?
It seems to me that comparing map section addresses the need to compare two maps, and once this general problem is cleared, the article focuses on the core aim of the package : comparing LCZ maps.
5) In response to
I see two possible pathways:
- Target mainly LCZ users, and add a small note somewhere that these scripts can be used on other maps as well. No need to change the codes
- Revise the whole manuscript and the codes to make it generic, and then use LCZs as just one example, given the interest of this scheme in the urban climate community.
I feel that the article is already following 1. I describe all the process for LCZ maps and then just show a function exists to do the same with any other qualitative variable. I'll let that sink during the weekend because I have a hard time seeing how it confuses the reading flow, but I may be too "acquainted" to my own paper to see this. I'll have a better point of view next week, after I finish coding multilayer rasters, probability layer, raster sensitivity analysis.
We have a core difference of points of view about the use of comparing maps. Don't you find it interesting to see how your global map and your Europe map differ on the Rennes area, as you showed with your example ? I find it interesting. It would have been a different message if the disagreement was not about water but urban areas, for instance. Even if none of the map is ground truth, it's still a lead on where to focus when trying to get more information on ground truth ?
Anyway, I'd like to say again : there is no irony nor controversial feeling on my side. I see the work you put for this review, I am grateful for it. I'm very glad I can improve the package and hopefully make it more useful for a part of the community who uses more raster sources than I do.
Next Pull Request (and probably last for this review) will occur before the end of last week.
martinfleis
commented
10 months ago @editorialbot generate pdf
editorialbot
commented
10 months ago :point_right::page_facing_up: Download article proof :page_facing_up: View article proof on GitHub :page_facing_up: :point_left:
martinfleis
commented
10 months ago @matthiasdemuzere Thank you a lot for all the effort and patience you have put into this review. I'll await a paper revision from @MGousseff but I think we are getting close. Keep in mind that the paper is not the primary medium in the JOSS publication but I understand some of the points raised.
Thank you all!
MGousseff
commented
10 months ago I coded the possibility to :
All this allows the confidence analysis as shown in the image :
I will add the test and check the documentation, I hope all this is done by tomorrow.
matthiasdemuzere
commented
10 months ago @martinfleis I checked all the boxes in my checklist so I consider my work done.
martinfleis
commented
10 months ago @editorialbot generate pdf
martinfleis
commented
10 months ago @editorialbot check references
editorialbot
commented
10 months ago Reference check summary (note 'MISSING' DOIs are suggestions that need verification):
OK DOIs
- 10.1016/0304-3800(92)90003-W is OK
- 10.1002/joc.5447 is OK
- 10.1016/j.eiar.2015.10.004 is OK
- 10.1016/0013-9351(72)90023-0 is OK
- 10.1080/17512549.2015.1043643 is OK
- 10.1175/bams-d-11-00019.1 is OK
- 10.1016/j.buildenv.2021.107791 is OK
- 10.21105/joss.03541 is OK
- 10.3390/land11050747 is OK
- 10.1016/j.landurbplan.2017.08.009 is OK
- 10.1111/j.1467-8306.1965.tb00529.x is OK
- 10.1175/BAMS-D-16-0236.1 is OK
- 10.1177/001316446002000104 is OK
- 10.3389/fenvs.2021.637455 is OK
- 10.5194/egusphere-2023-371 is OK
- 10.5194/gmd-2021-428 is OK
- 10.1016/j.uclim.2018.01.008 is OK
- 10.32614/RJ-2018-009 is OK
MISSING DOIs
- 10.5194/ems2022-83 may be a valid DOI for title: A global map of Local Climate Zones to support earth system modelling and urban scale environmental science
- 10.1038/s41597-020-00605-z may be a valid DOI for title: Combining expert and crowd-sourced training data to map urban form and functions for the continental US
INVALID DOIs
- None@editorialbot commands
editorialbot
commented
10 months ago Hello @martinfleis, here are the things you can ask me to do:
# List all available commands
@editorialbot commands
# Add to this issue's reviewers list
@editorialbot add @username as reviewer
# Remove from this issue's reviewers list
@editorialbot remove @username from reviewers
# Get a list of all editors's GitHub handles
@editorialbot list editors
# Assign a user as the editor of this submission
@editorialbot assign @username as editor
# Remove the editor assigned to this submission
@editorialbot remove editor
# Remind an author, a reviewer or the editor to return to a review after a
# certain period of time (supported units days and weeks)
@editorialbot remind @reviewer in 2 weeks
# Check the references of the paper for missing DOIs
@editorialbot check references
# Perform checks on the repository
@editorialbot check repository
# Adds a checklist for the reviewer using this command
@editorialbot generate my checklist
# Set a value for version
@editorialbot set v1.0.0 as version
# Set a value for branch
@editorialbot set joss-paper as branch
# Set a value for repository
@editorialbot set https://github.com/organization/repo as repository
# Set a value for the archive DOI
@editorialbot set set 10.5281/zenodo.6861996 as archive
# Mention the EiCs for the correct track
@editorialbot ping track-eic
# Generates the pdf paper
@editorialbot generate pdf
# Recommends the submission for acceptance
@editorialbot recommend-accept
# Generates a LaTeX preprint file
@editorialbot generate preprint
# Flag submission with questionable scope
@editorialbot query scope
# Get a link to the complete list of reviewers
@editorialbot list reviewers
# Creates a post-review checklist with editor and authors tasks
@editorialbot create post-review checklist
# Open the review issue
@editorialbot start review
@editorialbot set <DOI here> as archive@editorialbot set <version here> as version@editorialbot generate pdf@editorialbot check references and ask author(s) to update as needed@editorialbot recommend-accepteditorialbot
commented
10 months ago :point_right::page_facing_up: Download article proof :page_facing_up: View article proof on GitHub :page_facing_up: :point_left:
martinfleis
commented
10 months ago Thank you @matthiasdemuzere and @wcjochem for your reviews! JOSS could not work without people like you!
@MGousseff please see the post-review tasks in the post above https://github.com/openjournals/joss-reviews/issues/5445#issuecomment-1776718434. Also, check the DOIs reported by @editorialbot. If the suggestions are correct, add the DOIs please.
MGousseff
commented
10 months ago @matthiasdemuzere
I added the possibility to chose the raster band (by number or name) and checked if it allowed to perform the sensibility analysis. To have a consistent measure I divided the probability you provided by 100, to get a proba between 0 and 1, as the one GeoClimate provides. To test it, I chose a bounding box inside the zone of the tif you provided. Is it OK for you if I include the tif you provided in the package in order to have a working example ?
About the logic of the article, I get what your point about how comparing pairs of maps for any other categorical variable is an "add-on" so :
I think I cleaned the use of reference with and without square brackets. Thank you for pointing this out : I forgot about the two ways to cite a reference.
For the vignettes : I generated png for all the ggplot2 graphs that scale poorly in the vignettes. They now appear in a readable way.
MGousseff
commented
10 months ago @editorialbot generate my checklist
editorialbot
commented
10 months ago @MGousseff I can't do that because you are not a reviewer
MGousseff
commented
10 months ago The version of the package post review will be: Version: 0.0.1.0003
matthiasdemuzere
commented
10 months ago @MGousseff
To test it, I chose a bounding box inside the zone of the tif you provided. **Is it OK for you if I include the tif you provided in the package in order to have a working example ?
Sure, I think I took it from the Generator? In any case, you can use any tiff available from the LCZ Generator. https://lcz-generator.rub.de/submissions. You could add the reference for the map you take, that is normally provided around here
Thanks for taking into account my other points as well.
MGousseff
commented
10 months ago @martinfleis The new version is on Zenodo with the following DOI : https://doi.org/10.5281/zenodo.10041206
I don't suceed at checking the box of the author checklist. Is it in another thread ? I think everything is OK, now.
MGousseff
commented
10 months ago Thanks for taking into account my other points as well.
@matthiasdemuzere Thank you very much. The process has been a little rough, but I really am grateful for the improvements. I will improve in raster management !
Submitting author: !--author-handle-->@MGousseff<!--end-author-handle-- (Matthieu Gousseff) Repository: https://github.com/orbisgis/lczexplore Branch with paper.md (empty if default branch): master Version: 0.0.1.0003 Editor: !--editor-->@martinfleis<!--end-editor-- Reviewers: @matthiasdemuzere, @wcjochem Archive: 10.5281/zenodo.10041206
Status
Status badge code:
Reviewers and authors:
Please avoid lengthy details of difficulties in the review thread. Instead, please create a new issue in the target repository and link to those issues (especially acceptance-blockers) by leaving comments in the review thread below. (For completists: if the target issue tracker is also on GitHub, linking the review thread in the issue or vice versa will create corresponding breadcrumb trails in the link target.)
Reviewer instructions & questions
@matthiasdemuzere & @wcjochem, your review will be checklist based. Each of you will have a separate checklist that you should update when carrying out your review. First of all you need to run this command in a separate comment to create the checklist:
The reviewer guidelines are available here: https://joss.readthedocs.io/en/latest/reviewer_guidelines.html. Any questions/concerns please let @martinfleis know.
✨ Please start on your review when you are able, and be sure to complete your review in the next six weeks, at the very latest ✨
Checklists
📝 Checklist for @wcjochem
📝 Checklist for @matthiasdemuzere