search

zoometh / iconr

Formal methods to study Prehistory iconography
GNU General Public License v3.0
11 stars 5 forks source link

Delete 5_Ibahernando_Ibahernando_type.png #63

Closed josempozo closed 3 years ago

josempozo commented 3 years ago

I forgot to remove this image in the previous commit. It is no longer needed.

zoometh commented 3 years ago

Let's see if all works from my side

josempozo commented 3 years ago

Hi Tom,

I had sent you two emails this morning. But I cannot find them now in the sent folder. Don't know what happened.

  1. The tests passed perfectly in the check_rhub. Thus, no problem seems to really exist.
  2. I have maked some pulls to test some changes. But you should not accept them. I have declined them actually. But just in case. The p purpose was to make some test to see from where the error comes.
  3. I have confirmed that the problem is in the image_annotate(). This is really weird because I hadn't changed this at all.
  4. I have now a proposal to make this figure using standard plot. I have it and will pull the changes. Tell me if you like this or not.
  5. I have seen that you changed my description of the coordinate conventions. I think that my description was much better. You seem to refer to a package "R grid", which we don't directly use at all (right?). But for what you say we use the same conventions in iconr as in this grid package. Is this right. However, you don't make this statement clear. In fact you say that we use two conventions (GIS and grid). But this is not true, iconr use a single convention (as it should) which is the GIS one. And, in contrast, you choose to ignore the standard R plot conventions, which I think we should comment on. I write here both versions for you to check. Tell me what you think. Probably we should merge both if you want to comment on grid too.

Your version: For a given decoration, its image is the reference space of the graph: nodes and edges inherit their coordinates from the image grid. The package iconr considers the following coordinate conventions:

warning=FALSE}
df.equi <- data.frame("devices" = c("GIS interface","R grid"),
                      "units of measures" = c("number of pixels", "number
of pixels"),
                      "origin corner" = c("top-left", "top-left"),
                      "x-axis" = c("rightward", "rightward"),
                      "y-axis" = c("upward", "downward"),
                      check.names = FALSE)
knitr::kable(df.equi) %>%
  kableExtra::add_header_above(c(" " = 1, " " = 1, " " = 1, "axes
orientation" = 2)) %>%
  kable_styling(full_width = F)

Observe that the y-axis orientation are different between the GIS interface and R grids. In the GIS the y-axis is oriented upwards (ie, with negative values downwards), while in a R grid the y-axis is oriented downwards (ie, with positive values downwards). Then, the heights (ie, y-axis) coming from the GIS have to be inverted. This can be illustrated with the magick package.

My version: For a given decoration, its image is the reference space of the graph: nodes and edges inherit their coordinates from the image grid. The package iconr considers the following coordinate conventions:

Observe that the origin and y-axis orientation implies that y-coordinates are always negative in the image. This follows the same convention as relative coordinates in GIS, which are referenced to the top left corner of the local map with upwards y-axis orientation. However, it contrast with both default R plots (upwards y-axis but bottom-left origin) and magick image package plots (top-left origin but downwards y-axis), for which y values are positive.

Missatge de Thomas Huet notifications@github.com del dia ds., 30 de gen. 2021 a les 10:16:

Let's see if all works from my side

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/zoometh/iconr/pull/63#issuecomment-770182370, or unsubscribe https://github.com/notifications/unsubscribe-auth/ARKCR2O3HIJQVCPDKEJ7QKTS4PE5RANCNFSM4WZZGD3A .

zoometh commented 3 years ago

Hi Jose,

I will review all of this in the late afternoon

Best

On Sat, Jan 30, 2021 at 12:22 PM josempozo notifications@github.com wrote:

Hi Tom,

I had sent you two emails this morning. But I cannot find them now in the sent folder. Don't know what happened.

  1. The tests passed perfectly in the check_rhub. Thus, no problem seems to really exist.
  2. I have maked some pulls to test some changes. But you should not accept them. I have declined them actually. But just in case. The p purpose was to make some test to see from where the error comes.
  3. I have confirmed that the problem is in the image_annotate(). This is really weird because I hadn't changed this at all.
  4. I have now a proposal to make this figure using standard plot. I have it and will pull the changes. Tell me if you like this or not.
  5. I have seen that you changed my description of the coordinate conventions. I think that my description was much better. You seem to refer to a package "R grid", which we don't directly use at all (right?). But for what you say we use the same conventions in iconr as in this grid package. Is this right. However, you don't make this statement clear. In fact you say that we use two conventions (GIS and grid). But this is not true, iconr use a single convention (as it should) which is the GIS one. And, in contrast, you choose to ignore the standard R plot conventions, which I think we should comment on. I write here both versions for you to check. Tell me what you think. Probably we should merge both if you want to comment on grid too.

Your version: For a given decoration, its image is the reference space of the graph: nodes and edges inherit their coordinates from the image grid. The package iconr considers the following coordinate conventions:

warning=FALSE}
df.equi <- data.frame("devices" = c("GIS interface","R grid"),
"units of measures" = c("number of pixels", "number
of pixels"),
"origin corner" = c("top-left", "top-left"),
"x-axis" = c("rightward", "rightward"),
"y-axis" = c("upward", "downward"),
check.names = FALSE)
knitr::kable(df.equi) %>%
kableExtra::add_header_above(c(" " = 1, " " = 1, " " = 1, "axes
orientation" = 2)) %>%
kable_styling(full_width = F)

Observe that the y-axis orientation are different between the GIS interface and R grids. In the GIS the y-axis is oriented upwards (ie, with negative values downwards), while in a R grid the y-axis is oriented downwards (ie, with positive values downwards). Then, the heights (ie, y-axis) coming from the GIS have to be inverted. This can be illustrated with the magick package.

My version: For a given decoration, its image is the reference space of the graph: nodes and edges inherit their coordinates from the image grid. The package iconr considers the following coordinate conventions:

  • Unit of length: number of pixels.
  • Origin: top-left corner.
  • Axes orientation: x-coordinates rightward and y-coordinates upwards.

Observe that the origin and y-axis orientation implies that y-coordinates are always negative in the image. This follows the same convention as relative coordinates in GIS, which are referenced to the top left corner of the local map with upwards y-axis orientation. However, it contrast with both default R plots (upwards y-axis but bottom-left origin) and magick image package plots (top-left origin but downwards y-axis), for which y values are positive.

Missatge de Thomas Huet notifications@github.com del dia ds., 30 de gen. 2021 a les 10:16:

Let's see if all works from my side

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/zoometh/iconr/pull/63#issuecomment-770182370, or unsubscribe < https://github.com/notifications/unsubscribe-auth/ARKCR2O3HIJQVCPDKEJ7QKTS4PE5RANCNFSM4WZZGD3A

.

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/zoometh/iconr/pull/63#issuecomment-770197095, or unsubscribe https://github.com/notifications/unsubscribe-auth/AQGHHLS6WNWKQUJTIPWO3JLS4PTY3ANCNFSM4WZZGD3A .

zoometh commented 3 years ago

Hi Jose,

I think there's a misunderstanding. I was not clear about the terminology. You write:

I have seen that you changed my description of the coordinate conventions. I think that my description was much better. You seem to refer to a package "R grid", which we don't directly use at all (right?). But for what you say we use the same conventions in iconr as in this grid package. Is this right. However, you don't make this statement clear. In fact you say that we use two conventions (GIS and grid). But this is not true, iconr use a single convention (as it should) which is the GIS one. And, in contrast, you choose to ignore the standard R plot conventions, which I think we should comment on. I write here both versions for you to check. Tell me what you think. Probably we should merge both if you want to comment on grid too.

I am used to employ "grid" for any bitmap image (this comes from my practice of GIS, also called "raster"), so I don't refer to the package "R grid" , I have changed "grid" to "bitmap image", to let it clear. I have updated the vignettes. Currently, I am doing the ultimate check of the package before release it

Best

Tom

On Sat, Jan 30, 2021 at 1:21 PM Thomas Huet thomashuet7@gmail.com wrote:

Hi Jose,

I will review all of this in the late afternoon

Best

On Sat, Jan 30, 2021 at 12:22 PM josempozo notifications@github.com wrote:

Hi Tom,

I had sent you two emails this morning. But I cannot find them now in the sent folder. Don't know what happened.

  1. The tests passed perfectly in the check_rhub. Thus, no problem seems to really exist.
  2. I have maked some pulls to test some changes. But you should not accept them. I have declined them actually. But just in case. The p purpose was to make some test to see from where the error comes.
  3. I have confirmed that the problem is in the image_annotate(). This is really weird because I hadn't changed this at all.
  4. I have now a proposal to make this figure using standard plot. I have it and will pull the changes. Tell me if you like this or not.
  5. I have seen that you changed my description of the coordinate conventions. I think that my description was much better. You seem to refer to a package "R grid", which we don't directly use at all (right?). But for what you say we use the same conventions in iconr as in this grid package. Is this right. However, you don't make this statement clear. In fact you say that we use two conventions (GIS and grid). But this is not true, iconr use a single convention (as it should) which is the GIS one. And, in contrast, you choose to ignore the standard R plot conventions, which I think we should comment on. I write here both versions for you to check. Tell me what you think. Probably we should merge both if you want to comment on grid too.

Your version: For a given decoration, its image is the reference space of the graph: nodes and edges inherit their coordinates from the image grid. The package iconr considers the following coordinate conventions:

warning=FALSE}
df.equi <- data.frame("devices" = c("GIS interface","R grid"),
"units of measures" = c("number of pixels", "number
of pixels"),
"origin corner" = c("top-left", "top-left"),
"x-axis" = c("rightward", "rightward"),
"y-axis" = c("upward", "downward"),
check.names = FALSE)
knitr::kable(df.equi) %>%
kableExtra::add_header_above(c(" " = 1, " " = 1, " " = 1, "axes
orientation" = 2)) %>%
kable_styling(full_width = F)

Observe that the y-axis orientation are different between the GIS interface and R grids. In the GIS the y-axis is oriented upwards (ie, with negative values downwards), while in a R grid the y-axis is oriented downwards (ie, with positive values downwards). Then, the heights (ie, y-axis) coming from the GIS have to be inverted. This can be illustrated with the magick package.

My version: For a given decoration, its image is the reference space of the graph: nodes and edges inherit their coordinates from the image grid. The package iconr considers the following coordinate conventions:

  • Unit of length: number of pixels.
  • Origin: top-left corner.
  • Axes orientation: x-coordinates rightward and y-coordinates upwards.

Observe that the origin and y-axis orientation implies that y-coordinates are always negative in the image. This follows the same convention as relative coordinates in GIS, which are referenced to the top left corner of the local map with upwards y-axis orientation. However, it contrast with both default R plots (upwards y-axis but bottom-left origin) and magick image package plots (top-left origin but downwards y-axis), for which y values are positive.

Missatge de Thomas Huet notifications@github.com del dia ds., 30 de gen. 2021 a les 10:16:

Let's see if all works from my side

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/zoometh/iconr/pull/63#issuecomment-770182370, or unsubscribe < https://github.com/notifications/unsubscribe-auth/ARKCR2O3HIJQVCPDKEJ7QKTS4PE5RANCNFSM4WZZGD3A

.

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/zoometh/iconr/pull/63#issuecomment-770197095, or unsubscribe https://github.com/notifications/unsubscribe-auth/AQGHHLS6WNWKQUJTIPWO3JLS4PTY3ANCNFSM4WZZGD3A .

josempozo commented 3 years ago

Hi Tom,

I see. I think that there are actually two misunderstandings:

  1. I was missing to refer to this "raster" format and you were missing to refer to the standard graphics::plot.
  2. We need to make clear that we use a single convention. This is what I tried to make clear, but you mixed by describing the two cases in the table as conventions we use.

Let me propose a merge version. I do it just now. Probably I need 30 minutes.

Jose

Missatge de Thomas Huet notifications@github.com del dia dl., 1 de febr. 2021 a les 10:44:

Hi Jose,

I think there's a misunderstanding. I was not clear about the terminology. You write:

I have seen that you changed my description of the coordinate conventions. I think that my description was much better. You seem to refer to a package "R grid", which we don't directly use at all (right?). But for what you say we use the same conventions in iconr as in this grid package. Is this right. However, you don't make this statement clear. In fact you say that we use two conventions (GIS and grid). But this is not true, iconr use a single convention (as it should) which is the GIS one. And, in contrast, you choose to ignore the standard R plot conventions, which I think we should comment on. I write here both versions for you to check. Tell me what you think. Probably we should merge both if you want to comment on grid too.

I am used to employ "grid" for any bitmap image (this comes from my practice of GIS, also called "raster"), so I don't refer to the package "R grid" , I have changed "grid" to "bitmap image", to let it clear. I have updated the vignettes. Currently, I am doing the ultimate check of the package before release it

Best

Tom

On Sat, Jan 30, 2021 at 1:21 PM Thomas Huet thomashuet7@gmail.com wrote:

Hi Jose,

I will review all of this in the late afternoon

Best

On Sat, Jan 30, 2021 at 12:22 PM josempozo notifications@github.com wrote:

Hi Tom,

I had sent you two emails this morning. But I cannot find them now in the sent folder. Don't know what happened.

  1. The tests passed perfectly in the check_rhub. Thus, no problem seems to really exist.
  2. I have maked some pulls to test some changes. But you should not accept them. I have declined them actually. But just in case. The p purpose was to make some test to see from where the error comes.
  3. I have confirmed that the problem is in the image_annotate(). This is really weird because I hadn't changed this at all.
  4. I have now a proposal to make this figure using standard plot. I have it and will pull the changes. Tell me if you like this or not.
  5. I have seen that you changed my description of the coordinate conventions. I think that my description was much better. You seem to refer to a package "R grid", which we don't directly use at all (right?). But for what you say we use the same conventions in iconr as in this grid package. Is this right. However, you don't make this statement clear. In fact you say that we use two conventions (GIS and grid). But this is not true, iconr use a single convention (as it should) which is the GIS one. And, in contrast, you choose to ignore the standard R plot conventions, which I think we should comment on. I write here both versions for you to check. Tell me what you think. Probably we should merge both if you want to comment on grid too.

Your version: For a given decoration, its image is the reference space of the graph: nodes and edges inherit their coordinates from the image grid. The package iconr considers the following coordinate conventions:

warning=FALSE}
df.equi <- data.frame("devices" = c("GIS interface","R grid"),
"units of measures" = c("number of pixels", "number
of pixels"),
"origin corner" = c("top-left", "top-left"),
"x-axis" = c("rightward", "rightward"),
"y-axis" = c("upward", "downward"),
check.names = FALSE)
knitr::kable(df.equi) %>%
kableExtra::add_header_above(c(" " = 1, " " = 1, " " = 1, "axes
orientation" = 2)) %>%
kable_styling(full_width = F)

Observe that the y-axis orientation are different between the GIS interface and R grids. In the GIS the y-axis is oriented upwards (ie, with negative values downwards), while in a R grid the y-axis is oriented downwards (ie, with positive values downwards). Then, the heights (ie, y-axis) coming from the GIS have to be inverted. This can be illustrated with the magick package.

My version: For a given decoration, its image is the reference space of the graph: nodes and edges inherit their coordinates from the image grid. The package iconr considers the following coordinate conventions:

  • Unit of length: number of pixels.
  • Origin: top-left corner.
  • Axes orientation: x-coordinates rightward and y-coordinates upwards.

Observe that the origin and y-axis orientation implies that y-coordinates are always negative in the image. This follows the same convention as relative coordinates in GIS, which are referenced to the top left corner of the local map with upwards y-axis orientation. However, it contrast with both default R plots (upwards y-axis but bottom-left origin) and magick image package plots (top-left origin but downwards y-axis), for which y values are positive.

Missatge de Thomas Huet notifications@github.com del dia ds., 30 de gen. 2021 a les 10:16:

Let's see if all works from my side

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/zoometh/iconr/pull/63#issuecomment-770182370, or unsubscribe <

https://github.com/notifications/unsubscribe-auth/ARKCR2O3HIJQVCPDKEJ7QKTS4PE5RANCNFSM4WZZGD3A

.

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/zoometh/iconr/pull/63#issuecomment-770197095, or unsubscribe < https://github.com/notifications/unsubscribe-auth/AQGHHLS6WNWKQUJTIPWO3JLS4PTY3ANCNFSM4WZZGD3A

.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/zoometh/iconr/pull/63#issuecomment-770722457, or unsubscribe https://github.com/notifications/unsubscribe-auth/ARKCR2L7GLMYAYVC4G2TVG3S4ZZXVANCNFSM4WZZGD3A .

zoometh commented 3 years ago

Hi Jose,

I've just submitted the package to the CRAN. So, the ultimate version is: * For a given decoration, its image is the reference space of the graph: nodes and edges inherit their coordinates from this image. Firstly, the decoration image is open in the GIS and the graph is built. The, these features are imported into R:

fig.align="center",echo=FALSE,warning=FALSE}
df.equi <- data.frame("devices" = c("GIS raster","R bitmap image"),
                      "units of measures" = c("number of pixels", "number
of pixels"),
                      "origin corner" = c("top-left", "top-left"),
                      "x-axis" = c("rightward", "rightward"),
                      "y-axis" = c("upward", "downward"),
                      check.names = FALSE)
knitr::kable(df.equi) %>%
  kableExtra::add_header_above(c(" " = 1, " " = 1, " " = 1, "axes
orientation" = 2)) %>%
  kable_styling(full_width = F)

Observe that the y-axis orientation is different between a GIS raster/grid and R bitmap images. In the GIS the y-axis is oriented upwards (ie, with negative values downwards) and y-coordinates are always negative. However, it contrasts with the R bitmap image (top-left origin but downwards y-axis), for which y values are positive. Then, the heights (ie, y-axis) coming from the GIS have to be inverted. This can be illustrated with the magick package. * I guess it is sufficient for this first release, we will improve in a next version (or latter, if the current version is dismissed)

best

On Mon, Feb 1, 2021 at 11:20 AM josempozo notifications@github.com wrote:

Hi Tom,

I see. I think that there are actually two misunderstandings:

  1. I was missing to refer to this "raster" format and you were missing to refer to the standard graphics::plot.
  2. We need to make clear that we use a single convention. This is what I tried to make clear, but you mixed by describing the two cases in the table as conventions we use.

Let me propose a merge version. I do it just now. Probably I need 30 minutes.

Jose

Missatge de Thomas Huet notifications@github.com del dia dl., 1 de febr. 2021 a les 10:44:

Hi Jose,

I think there's a misunderstanding. I was not clear about the terminology. You write:

I have seen that you changed my description of the coordinate conventions. I think that my description was much better. You seem to refer to a package "R grid", which we don't directly use at all (right?). But for what you say we use the same conventions in iconr as in this grid package. Is this right. However, you don't make this statement clear. In fact you say that we use two conventions (GIS and grid). But this is not true, iconr use a single convention (as it should) which is the GIS one. And, in contrast, you choose to ignore the standard R plot conventions, which I think we should comment on. I write here both versions for you to check. Tell me what you think. Probably we should merge both if you want to comment on grid too.

I am used to employ "grid" for any bitmap image (this comes from my practice of GIS, also called "raster"), so I don't refer to the package "R grid" , I have changed "grid" to "bitmap image", to let it clear. I have updated the vignettes. Currently, I am doing the ultimate check of the package before release it

Best

Tom

On Sat, Jan 30, 2021 at 1:21 PM Thomas Huet thomashuet7@gmail.com wrote:

Hi Jose,

I will review all of this in the late afternoon

Best

On Sat, Jan 30, 2021 at 12:22 PM josempozo notifications@github.com wrote:

Hi Tom,

I had sent you two emails this morning. But I cannot find them now in the sent folder. Don't know what happened.

  1. The tests passed perfectly in the check_rhub. Thus, no problem seems to really exist.
  2. I have maked some pulls to test some changes. But you should not accept them. I have declined them actually. But just in case. The p purpose was to make some test to see from where the error comes.
  3. I have confirmed that the problem is in the image_annotate(). This is really weird because I hadn't changed this at all.
  4. I have now a proposal to make this figure using standard plot. I have it and will pull the changes. Tell me if you like this or not.
  5. I have seen that you changed my description of the coordinate conventions. I think that my description was much better. You seem to refer to a package "R grid", which we don't directly use at all (right?). But for what you say we use the same conventions in iconr as in this grid package. Is this right. However, you don't make this statement clear. In fact you say that we use two conventions (GIS and grid). But this is not true, iconr use a single convention (as it should) which is the GIS one. And, in contrast, you choose to ignore the standard R plot conventions, which I think we should comment on. I write here both versions for you to check. Tell me what you think. Probably we should merge both if you want to comment on grid too.

Your version: For a given decoration, its image is the reference space of the graph: nodes and edges inherit their coordinates from the image grid. The package iconr considers the following coordinate conventions:

warning=FALSE}
df.equi <- data.frame("devices" = c("GIS interface","R grid"),
"units of measures" = c("number of pixels", "number
of pixels"),
"origin corner" = c("top-left", "top-left"),
"x-axis" = c("rightward", "rightward"),
"y-axis" = c("upward", "downward"),
check.names = FALSE)
knitr::kable(df.equi) %>%
kableExtra::add_header_above(c(" " = 1, " " = 1, " " = 1, "axes
orientation" = 2)) %>%
kable_styling(full_width = F)

Observe that the y-axis orientation are different between the GIS interface and R grids. In the GIS the y-axis is oriented upwards (ie, with negative values downwards), while in a R grid the y-axis is oriented downwards (ie, with positive values downwards). Then, the heights (ie, y-axis) coming from the GIS have to be inverted. This can be illustrated with the magick package.

My version: For a given decoration, its image is the reference space of the graph: nodes and edges inherit their coordinates from the image grid. The package iconr considers the following coordinate conventions:

  • Unit of length: number of pixels.
  • Origin: top-left corner.
  • Axes orientation: x-coordinates rightward and y-coordinates upwards.

Observe that the origin and y-axis orientation implies that y-coordinates are always negative in the image. This follows the same convention as relative coordinates in GIS, which are referenced to the top left corner of the local map with upwards y-axis orientation. However, it contrast with both default R plots (upwards y-axis but bottom-left origin) and magick image package plots (top-left origin but downwards y-axis), for which y values are positive.

Missatge de Thomas Huet notifications@github.com del dia ds., 30 de gen. 2021 a les 10:16:

Let's see if all works from my side

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/zoometh/iconr/pull/63#issuecomment-770182370, or unsubscribe <

https://github.com/notifications/unsubscribe-auth/ARKCR2O3HIJQVCPDKEJ7QKTS4PE5RANCNFSM4WZZGD3A

.

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/zoometh/iconr/pull/63#issuecomment-770197095, or unsubscribe <

https://github.com/notifications/unsubscribe-auth/AQGHHLS6WNWKQUJTIPWO3JLS4PTY3ANCNFSM4WZZGD3A

.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/zoometh/iconr/pull/63#issuecomment-770722457, or unsubscribe < https://github.com/notifications/unsubscribe-auth/ARKCR2L7GLMYAYVC4G2TVG3S4ZZXVANCNFSM4WZZGD3A

.

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/zoometh/iconr/pull/63#issuecomment-770745339, or unsubscribe https://github.com/notifications/unsubscribe-auth/AQGHHLWCEBKQZAWSLA4CEGLS4Z56LANCNFSM4WZZGD3A .

josempozo commented 3 years ago

Let me propose it anyway. If you need to resubmit (quite probable), it can be included. Otherwise, we include it in other releases.

Missatge de Thomas Huet notifications@github.com del dia dl., 1 de febr. 2021 a les 11:36:

Hi Jose,

I've just submitted the package to the CRAN. So, the ultimate version is: * For a given decoration, its image is the reference space of the graph: nodes and edges inherit their coordinates from this image. Firstly, the decoration image is open in the GIS and the graph is built. The, these features are imported into R:

fig.align="center",echo=FALSE,warning=FALSE}
df.equi <- data.frame("devices" = c("GIS raster","R bitmap image"),
"units of measures" = c("number of pixels", "number
of pixels"),
"origin corner" = c("top-left", "top-left"),
"x-axis" = c("rightward", "rightward"),
"y-axis" = c("upward", "downward"),
check.names = FALSE)
knitr::kable(df.equi) %>%
kableExtra::add_header_above(c(" " = 1, " " = 1, " " = 1, "axes
orientation" = 2)) %>%
kable_styling(full_width = F)

Observe that the y-axis orientation is different between a GIS raster/grid and R bitmap images. In the GIS the y-axis is oriented upwards (ie, with negative values downwards) and y-coordinates are always negative. However, it contrasts with the R bitmap image (top-left origin but downwards y-axis), for which y values are positive. Then, the heights (ie, y-axis) coming from the GIS have to be inverted. This can be illustrated with the magick package. * I guess it is sufficient for this first release, we will improve in a next version (or latter, if the current version is dismissed)

best

On Mon, Feb 1, 2021 at 11:20 AM josempozo notifications@github.com wrote:

Hi Tom,

I see. I think that there are actually two misunderstandings:

  1. I was missing to refer to this "raster" format and you were missing to refer to the standard graphics::plot.
  2. We need to make clear that we use a single convention. This is what I tried to make clear, but you mixed by describing the two cases in the table as conventions we use.

Let me propose a merge version. I do it just now. Probably I need 30 minutes.

Jose

Missatge de Thomas Huet notifications@github.com del dia dl., 1 de febr. 2021 a les 10:44:

Hi Jose,

I think there's a misunderstanding. I was not clear about the terminology. You write:

I have seen that you changed my description of the coordinate conventions. I think that my description was much better. You seem to refer to a package "R grid", which we don't directly use at all (right?). But for what you say we use the same conventions in iconr as in this grid package. Is this right. However, you don't make this statement clear. In fact you say that we use two conventions (GIS and grid). But this is not true, iconr use a single convention (as it should) which is the GIS one. And, in contrast, you choose to ignore the standard R plot conventions, which I think we should comment on. I write here both versions for you to check. Tell me what you think. Probably we should merge both if you want to comment on grid too.

I am used to employ "grid" for any bitmap image (this comes from my practice of GIS, also called "raster"), so I don't refer to the package "R grid" , I have changed "grid" to "bitmap image", to let it clear. I have updated the vignettes. Currently, I am doing the ultimate check of the package before release it

Best

Tom

On Sat, Jan 30, 2021 at 1:21 PM Thomas Huet thomashuet7@gmail.com wrote:

Hi Jose,

I will review all of this in the late afternoon

Best

On Sat, Jan 30, 2021 at 12:22 PM josempozo <notifications@github.com

wrote:

Hi Tom,

I had sent you two emails this morning. But I cannot find them now in the sent folder. Don't know what happened.

  1. The tests passed perfectly in the check_rhub. Thus, no problem seems to really exist.
  2. I have maked some pulls to test some changes. But you should not accept them. I have declined them actually. But just in case. The p purpose was to make some test to see from where the error comes.
  3. I have confirmed that the problem is in the image_annotate(). This is really weird because I hadn't changed this at all.
  4. I have now a proposal to make this figure using standard plot. I have it and will pull the changes. Tell me if you like this or not.
  5. I have seen that you changed my description of the coordinate conventions. I think that my description was much better. You seem to refer to a package "R grid", which we don't directly use at all (right?). But for what you say we use the same conventions in iconr as in this grid package. Is this right. However, you don't make this statement clear. In fact you say that we use two conventions (GIS and grid). But this is not true, iconr use a single convention (as it should) which is the GIS one. And, in contrast, you choose to ignore the standard R plot conventions, which I think we should comment on. I write here both versions for you to check. Tell me what you think. Probably we should merge both if you want to comment on grid too.

Your version: For a given decoration, its image is the reference space of the graph: nodes and edges inherit their coordinates from the image grid. The package iconr considers the following coordinate conventions:

warning=FALSE}
df.equi <- data.frame("devices" = c("GIS interface","R grid"),
"units of measures" = c("number of pixels", "number
of pixels"),
"origin corner" = c("top-left", "top-left"),
"x-axis" = c("rightward", "rightward"),
"y-axis" = c("upward", "downward"),
check.names = FALSE)
knitr::kable(df.equi) %>%
kableExtra::add_header_above(c(" " = 1, " " = 1, " " = 1, "axes
orientation" = 2)) %>%
kable_styling(full_width = F)

Observe that the y-axis orientation are different between the GIS interface and R grids. In the GIS the y-axis is oriented upwards (ie, with negative values downwards), while in a R grid the y-axis is oriented downwards (ie, with positive values downwards). Then, the heights (ie, y-axis) coming from the GIS have to be inverted. This can be illustrated with the magick package.

My version: For a given decoration, its image is the reference space of the graph: nodes and edges inherit their coordinates from the image grid. The package iconr considers the following coordinate conventions:

  • Unit of length: number of pixels.
  • Origin: top-left corner.
  • Axes orientation: x-coordinates rightward and y-coordinates upwards.

Observe that the origin and y-axis orientation implies that y-coordinates are always negative in the image. This follows the same convention as relative coordinates in GIS, which are referenced to the top left corner of the local map with upwards y-axis orientation. However, it contrast with both default R plots (upwards y-axis but bottom-left origin) and magick image package plots (top-left origin but downwards y-axis), for which y values are positive.

Missatge de Thomas Huet notifications@github.com del dia ds., 30 de gen. 2021 a les 10:16:

Let's see if all works from my side

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <https://github.com/zoometh/iconr/pull/63#issuecomment-770182370 , or unsubscribe <

https://github.com/notifications/unsubscribe-auth/ARKCR2O3HIJQVCPDKEJ7QKTS4PE5RANCNFSM4WZZGD3A

.

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/zoometh/iconr/pull/63#issuecomment-770197095, or unsubscribe <

https://github.com/notifications/unsubscribe-auth/AQGHHLS6WNWKQUJTIPWO3JLS4PTY3ANCNFSM4WZZGD3A

.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/zoometh/iconr/pull/63#issuecomment-770722457, or unsubscribe <

https://github.com/notifications/unsubscribe-auth/ARKCR2L7GLMYAYVC4G2TVG3S4ZZXVANCNFSM4WZZGD3A

.

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/zoometh/iconr/pull/63#issuecomment-770745339, or unsubscribe < https://github.com/notifications/unsubscribe-auth/AQGHHLWCEBKQZAWSLA4CEGLS4Z56LANCNFSM4WZZGD3A

.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/zoometh/iconr/pull/63#issuecomment-770755519, or unsubscribe https://github.com/notifications/unsubscribe-auth/ARKCR2MWKIBDP3AVNNAWU53S4Z73HANCNFSM4WZZGD3A .

zoometh commented 3 years ago

Sure

On Mon, Feb 1, 2021 at 11:39 AM josempozo notifications@github.com wrote:

Let me propose it anyway. If you need to resubmit (quite probable), it can be included. Otherwise, we include it in other releases.

Missatge de Thomas Huet notifications@github.com del dia dl., 1 de febr. 2021 a les 11:36:

Hi Jose,

I've just submitted the package to the CRAN. So, the ultimate version is: * For a given decoration, its image is the reference space of the graph: nodes and edges inherit their coordinates from this image. Firstly, the decoration image is open in the GIS and the graph is built. The, these features are imported into R:

fig.align="center",echo=FALSE,warning=FALSE}
df.equi <- data.frame("devices" = c("GIS raster","R bitmap image"),
"units of measures" = c("number of pixels", "number
of pixels"),
"origin corner" = c("top-left", "top-left"),
"x-axis" = c("rightward", "rightward"),
"y-axis" = c("upward", "downward"),
check.names = FALSE)
knitr::kable(df.equi) %>%
kableExtra::add_header_above(c(" " = 1, " " = 1, " " = 1, "axes
orientation" = 2)) %>%
kable_styling(full_width = F)

Observe that the y-axis orientation is different between a GIS raster/grid and R bitmap images. In the GIS the y-axis is oriented upwards (ie, with negative values downwards) and y-coordinates are always negative. However, it contrasts with the R bitmap image (top-left origin but downwards y-axis), for which y values are positive. Then, the heights (ie, y-axis) coming from the GIS have to be inverted. This can be illustrated with the magick package. * I guess it is sufficient for this first release, we will improve in a next version (or latter, if the current version is dismissed)

best

On Mon, Feb 1, 2021 at 11:20 AM josempozo notifications@github.com wrote:

Hi Tom,

I see. I think that there are actually two misunderstandings:

  1. I was missing to refer to this "raster" format and you were missing to refer to the standard graphics::plot.
  2. We need to make clear that we use a single convention. This is what I tried to make clear, but you mixed by describing the two cases in the table as conventions we use.

Let me propose a merge version. I do it just now. Probably I need 30 minutes.

Jose

Missatge de Thomas Huet notifications@github.com del dia dl., 1 de febr. 2021 a les 10:44:

Hi Jose,

I think there's a misunderstanding. I was not clear about the terminology. You write:

I have seen that you changed my description of the coordinate conventions. I think that my description was much better. You seem to refer to a package "R grid", which we don't directly use at all (right?). But for what you say we use the same conventions in iconr as in this grid package. Is this right. However, you don't make this statement clear. In fact you say that we use two conventions (GIS and grid). But this is not true, iconr use a single convention (as it should) which is the GIS one. And, in contrast, you choose to ignore the standard R plot conventions, which I think we should comment on. I write here both versions for you to check. Tell me what you think. Probably we should merge both if you want to comment on grid too.

I am used to employ "grid" for any bitmap image (this comes from my practice of GIS, also called "raster"), so I don't refer to the package "R grid" , I have changed "grid" to "bitmap image", to let it clear. I have updated the vignettes. Currently, I am doing the ultimate check of the package before release it

Best

Tom

On Sat, Jan 30, 2021 at 1:21 PM Thomas Huet thomashuet7@gmail.com wrote:

Hi Jose,

I will review all of this in the late afternoon

Best

On Sat, Jan 30, 2021 at 12:22 PM josempozo < notifications@github.com

wrote:

Hi Tom,

I had sent you two emails this morning. But I cannot find them now in the sent folder. Don't know what happened.

  1. The tests passed perfectly in the check_rhub. Thus, no problem seems to really exist.
  2. I have maked some pulls to test some changes. But you should not accept them. I have declined them actually. But just in case. The p purpose was to make some test to see from where the error comes.
  3. I have confirmed that the problem is in the image_annotate(). This is really weird because I hadn't changed this at all.
  4. I have now a proposal to make this figure using standard plot. I have it and will pull the changes. Tell me if you like this or not.
  5. I have seen that you changed my description of the coordinate conventions. I think that my description was much better. You seem to refer to a package "R grid", which we don't directly use at all (right?). But for what you say we use the same conventions in iconr as in this grid package. Is this right. However, you don't make this statement clear. In fact you say that we use two conventions (GIS and grid). But this is not true, iconr use a single convention (as it should) which is the GIS one. And, in contrast, you choose to ignore the standard R plot conventions, which I think we should comment on. I write here both versions for you to check. Tell me what you think. Probably we should merge both if you want to comment on grid too.

Your version: For a given decoration, its image is the reference space of the graph: nodes and edges inherit their coordinates from the image grid. The package iconr considers the following coordinate conventions:

warning=FALSE}
df.equi <- data.frame("devices" = c("GIS interface","R grid"),
"units of measures" = c("number of pixels", "number
of pixels"),
"origin corner" = c("top-left", "top-left"),
"x-axis" = c("rightward", "rightward"),
"y-axis" = c("upward", "downward"),
check.names = FALSE)
knitr::kable(df.equi) %>%
kableExtra::add_header_above(c(" " = 1, " " = 1, " " = 1, "axes
orientation" = 2)) %>%
kable_styling(full_width = F)

Observe that the y-axis orientation are different between the GIS interface and R grids. In the GIS the y-axis is oriented upwards (ie, with negative values downwards), while in a R grid the y-axis is oriented downwards (ie, with positive values downwards). Then, the heights (ie, y-axis) coming from the GIS have to be inverted. This can be illustrated with the magick package.

My version: For a given decoration, its image is the reference space of the graph: nodes and edges inherit their coordinates from the image grid. The package iconr considers the following coordinate conventions:

  • Unit of length: number of pixels.
  • Origin: top-left corner.
  • Axes orientation: x-coordinates rightward and y-coordinates upwards.

Observe that the origin and y-axis orientation implies that y-coordinates are always negative in the image. This follows the same convention as relative coordinates in GIS, which are referenced to the top left corner of the local map with upwards y-axis orientation. However, it contrast with both default R plots (upwards y-axis but bottom-left origin) and magick image package plots (top-left origin but downwards y-axis), for which y values are positive.

Missatge de Thomas Huet notifications@github.com del dia ds., 30 de gen. 2021 a les 10:16:

Let's see if all works from my side

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub < https://github.com/zoometh/iconr/pull/63#issuecomment-770182370 , or unsubscribe <

https://github.com/notifications/unsubscribe-auth/ARKCR2O3HIJQVCPDKEJ7QKTS4PE5RANCNFSM4WZZGD3A

.

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <https://github.com/zoometh/iconr/pull/63#issuecomment-770197095 , or unsubscribe <

https://github.com/notifications/unsubscribe-auth/AQGHHLS6WNWKQUJTIPWO3JLS4PTY3ANCNFSM4WZZGD3A

.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/zoometh/iconr/pull/63#issuecomment-770722457, or unsubscribe <

https://github.com/notifications/unsubscribe-auth/ARKCR2L7GLMYAYVC4G2TVG3S4ZZXVANCNFSM4WZZGD3A

.

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/zoometh/iconr/pull/63#issuecomment-770745339, or unsubscribe <

https://github.com/notifications/unsubscribe-auth/AQGHHLWCEBKQZAWSLA4CEGLS4Z56LANCNFSM4WZZGD3A

.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/zoometh/iconr/pull/63#issuecomment-770755519, or unsubscribe < https://github.com/notifications/unsubscribe-auth/ARKCR2MWKIBDP3AVNNAWU53S4Z73HANCNFSM4WZZGD3A

.

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/zoometh/iconr/pull/63#issuecomment-770756997, or unsubscribe https://github.com/notifications/unsubscribe-auth/AQGHHLWKZSESHHE3MBWWZ2DS42AEZANCNFSM4WZZGD3A .

josempozo commented 3 years ago

Hi Tom,

I have just committed my proposal for the description of the coordinate convention. I hope you agree.

I liked a lot the idea of the tutorial web page. It is really good. And very good way to facilitate the use of the package.

Best

Jose

Missatge de Thomas Huet notifications@github.com del dia dl., 1 de febr. 2021 a les 12:06:

Sure

On Mon, Feb 1, 2021 at 11:39 AM josempozo notifications@github.com wrote:

Let me propose it anyway. If you need to resubmit (quite probable), it can be included. Otherwise, we include it in other releases.

Missatge de Thomas Huet notifications@github.com del dia dl., 1 de febr. 2021 a les 11:36:

Hi Jose,

I've just submitted the package to the CRAN. So, the ultimate version is: * For a given decoration, its image is the reference space of the graph: nodes and edges inherit their coordinates from this image. Firstly, the decoration image is open in the GIS and the graph is built. The, these features are imported into R:

fig.align="center",echo=FALSE,warning=FALSE}
df.equi <- data.frame("devices" = c("GIS raster","R bitmap image"),
"units of measures" = c("number of pixels", "number
of pixels"),
"origin corner" = c("top-left", "top-left"),
"x-axis" = c("rightward", "rightward"),
"y-axis" = c("upward", "downward"),
check.names = FALSE)
knitr::kable(df.equi) %>%
kableExtra::add_header_above(c(" " = 1, " " = 1, " " = 1, "axes
orientation" = 2)) %>%
kable_styling(full_width = F)

Observe that the y-axis orientation is different between a GIS raster/grid and R bitmap images. In the GIS the y-axis is oriented upwards (ie, with negative values downwards) and y-coordinates are always negative. However, it contrasts with the R bitmap image (top-left origin but downwards y-axis), for which y values are positive. Then, the heights (ie, y-axis) coming from the GIS have to be inverted. This can be illustrated with the magick package. * I guess it is sufficient for this first release, we will improve in a next version (or latter, if the current version is dismissed)

best

On Mon, Feb 1, 2021 at 11:20 AM josempozo notifications@github.com wrote:

Hi Tom,

I see. I think that there are actually two misunderstandings:

  1. I was missing to refer to this "raster" format and you were missing to refer to the standard graphics::plot.
  2. We need to make clear that we use a single convention. This is what I tried to make clear, but you mixed by describing the two cases in the table as conventions we use.

Let me propose a merge version. I do it just now. Probably I need 30 minutes.

Jose

Missatge de Thomas Huet notifications@github.com del dia dl., 1 de febr. 2021 a les 10:44:

Hi Jose,

I think there's a misunderstanding. I was not clear about the terminology. You write:

I have seen that you changed my description of the coordinate conventions. I think that my description was much better. You seem to refer to a package "R grid", which we don't directly use at all (right?). But for what you say we use the same conventions in iconr as in this grid package. Is this right. However, you don't make this statement clear. In fact you say that we use two conventions (GIS and grid). But this is not true, iconr use a single convention (as it should) which is the GIS one. And, in contrast, you choose to ignore the standard R plot conventions, which I think we should comment on. I write here both versions for you to check. Tell me what you think. Probably we should merge both if you want to comment on grid too.

I am used to employ "grid" for any bitmap image (this comes from my practice of GIS, also called "raster"), so I don't refer to the package "R grid" , I have changed "grid" to "bitmap image", to let it clear. I have updated the vignettes. Currently, I am doing the ultimate check of the package before release it

Best

Tom

On Sat, Jan 30, 2021 at 1:21 PM Thomas Huet <thomashuet7@gmail.com

wrote:

Hi Jose,

I will review all of this in the late afternoon

Best

On Sat, Jan 30, 2021 at 12:22 PM josempozo < notifications@github.com

wrote:

Hi Tom,

I had sent you two emails this morning. But I cannot find them now in the sent folder. Don't know what happened.

  1. The tests passed perfectly in the check_rhub. Thus, no problem seems to really exist.
  2. I have maked some pulls to test some changes. But you should not accept them. I have declined them actually. But just in case. The p purpose was to make some test to see from where the error comes.
  3. I have confirmed that the problem is in the image_annotate(). This is really weird because I hadn't changed this at all.
  4. I have now a proposal to make this figure using standard plot. I have it and will pull the changes. Tell me if you like this or not.
  5. I have seen that you changed my description of the coordinate conventions. I think that my description was much better. You seem to refer to a package "R grid", which we don't directly use at all (right?). But for what you say we use the same conventions in iconr as in this grid package. Is this right. However, you don't make this statement clear. In fact you say that we use two conventions (GIS and grid). But this is not true, iconr use a single convention (as it should) which is the GIS one. And, in contrast, you choose to ignore the standard R plot conventions, which I think we should comment on. I write here both versions for you to check. Tell me what you think. Probably we should merge both if you want to comment on grid too.

Your version: For a given decoration, its image is the reference space of the graph: nodes and edges inherit their coordinates from the image grid. The package iconr considers the following coordinate conventions:

warning=FALSE}
df.equi <- data.frame("devices" = c("GIS interface","R grid"),
"units of measures" = c("number of pixels", "number
of pixels"),
"origin corner" = c("top-left", "top-left"),
"x-axis" = c("rightward", "rightward"),
"y-axis" = c("upward", "downward"),
check.names = FALSE)
knitr::kable(df.equi) %>%
kableExtra::add_header_above(c(" " = 1, " " = 1, " " = 1, "axes
orientation" = 2)) %>%
kable_styling(full_width = F)

Observe that the y-axis orientation are different between the GIS interface and R grids. In the GIS the y-axis is oriented upwards (ie, with negative values downwards), while in a R grid the y-axis is oriented downwards (ie, with positive values downwards). Then, the heights (ie, y-axis) coming from the GIS have to be inverted. This can be illustrated with the magick package.

My version: For a given decoration, its image is the reference space of the graph: nodes and edges inherit their coordinates from the image grid. The package iconr considers the following coordinate conventions:

  • Unit of length: number of pixels.
  • Origin: top-left corner.
  • Axes orientation: x-coordinates rightward and y-coordinates upwards.

Observe that the origin and y-axis orientation implies that y-coordinates are always negative in the image. This follows the same convention as relative coordinates in GIS, which are referenced to the top left corner of the local map with upwards y-axis orientation. However, it contrast with both default R plots (upwards y-axis but bottom-left origin) and magick image package plots (top-left origin but downwards y-axis), for which y values are positive.

Missatge de Thomas Huet notifications@github.com del dia ds., 30 de gen. 2021 a les 10:16:

Let's see if all works from my side

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub < https://github.com/zoometh/iconr/pull/63#issuecomment-770182370 , or unsubscribe <

https://github.com/notifications/unsubscribe-auth/ARKCR2O3HIJQVCPDKEJ7QKTS4PE5RANCNFSM4WZZGD3A

.

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub < https://github.com/zoometh/iconr/pull/63#issuecomment-770197095 , or unsubscribe <

https://github.com/notifications/unsubscribe-auth/AQGHHLS6WNWKQUJTIPWO3JLS4PTY3ANCNFSM4WZZGD3A

.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/zoometh/iconr/pull/63#issuecomment-770722457, or unsubscribe <

https://github.com/notifications/unsubscribe-auth/ARKCR2L7GLMYAYVC4G2TVG3S4ZZXVANCNFSM4WZZGD3A

.

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/zoometh/iconr/pull/63#issuecomment-770745339, or unsubscribe <

https://github.com/notifications/unsubscribe-auth/AQGHHLWCEBKQZAWSLA4CEGLS4Z56LANCNFSM4WZZGD3A

.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/zoometh/iconr/pull/63#issuecomment-770755519, or unsubscribe <

https://github.com/notifications/unsubscribe-auth/ARKCR2MWKIBDP3AVNNAWU53S4Z73HANCNFSM4WZZGD3A

.

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/zoometh/iconr/pull/63#issuecomment-770756997, or unsubscribe < https://github.com/notifications/unsubscribe-auth/AQGHHLWKZSESHHE3MBWWZ2DS42AEZANCNFSM4WZZGD3A

.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/zoometh/iconr/pull/63#issuecomment-770774019, or unsubscribe https://github.com/notifications/unsubscribe-auth/ARKCR2K47EWDOLJ5K56FQFTS42DMXANCNFSM4WZZGD3A .