chrisvwn / Rnightlights

R package to extract data from satellite nightlights.
GNU General Public License v3.0
47 stars 14 forks source link

Vietnam - country level vs. admin1 level #15

Closed fnarita closed 5 years ago

fnarita commented 5 years ago

Hi Chris,

I have downloaded about 60 developing countries' data and happened to find that for Vietnam, the aggregation of nighttime lights over the admin1-level locations does not add up to the country-level nighttime lights. The former tends to be slightly larger than the latter.

As far as I have (only roughly) checked for the period of 2002-2013, Vietnam is the only case and other countries (e.g., Myanmar, Mozambique, Tanzania, Zimbabwe, etc.) show the same numbers between the country-level result and the aggregation of the admin1-level locations to the country level.

My interest is on the country level for now, so this is not an issue to me, but I would like to flag this to you just in case.

Specifically, for example, for the year 2013, OLS.Y, I got 1573093 for Vietnam as a whole, running the following code:

ctry <- "VNM"
highestAdmLevelStats <- getCtryNlData(ctryCode = ctry, 
                                      admLevel = "country",
                                      nlType = "OLS.Y", 
                                      nlPeriods = nlRange("2013", "2013"), 
                                      nlStats = "sum",
                                      ignoreMissing=FALSE)

But I got 1573185 if I summed up all locations' nighttime lights, after running the following code:

ctry <- "VNM"
highestAdmLevelStats <- getCtryNlData(ctryCode = ctry, 
                                      admLevel = "admin1",
                                      nlType = "OLS.Y", 
                                      nlPeriods = nlRange("2013", "2013"), 
                                      nlStats = "sum",
                                      ignoreMissing=FALSE)

I tried twice and the resulting data did not fluctuate and consistently show 1573093 and 1573185.

Hope this would be helpful over the long term, but no urgent response is needed. Thank you for your dedication for this project, again, and I'm feeling that I wish I could contribute to the code by myself too, instead of just asking you to improve the already great package like this.

By the way, I very much like the logs that the code produces as well as the automatic check on which data are already computed or need to be computed etc. Such nice functionalities!

Futoshi

chrisvwn commented 5 years ago

Hi Futoshi,

Once again, thank you for your feedback. It is indeed interesting that the sum at country level would not match the aggregated sums of lower levels. I will look at this particular example (Vietnam, OLS.Y, 2000) and hopefully will find out what is going on here.

Thanks for your comment on the package features. Indeed, I have added them because using the package myself they have made my life that much easier. I will probably introduce log levels in future so only verbose mode will generate all this output.

Your study sounds really interesting. I would be interested in your findings - if you do publish in some form and can send a link please do.

Thanks again for your feedback, I appreciate it!

fnarita commented 5 years ago

Thank you very much Chris! Yes, will let you know once I get a result.

Thank you! Futoshi

chrisvwn commented 5 years ago

Hi @fnarita,

Apologies for the time it has taken to look into this.

I can confirm that I get the same discrepancy when I run getCtryNlData as you mentioned. I also have found that this issue seems to be isolated to VNM at the moment out of the ones I have tested. Farther, this seems to only affect VNM where the polygons are version 2.8 from GADM. When I tried using GADM 3.6 (the latest Rnightlights versions have a gadmVersion param and it is 3.6 by default) the stats tallied across all admLevels.

I performed a rudimentary polygon difference/clip of adm1 with adm0 in QGIS and it does seem like there is a difference between the two polygon layers hence the stats difference.

So this looks like a polygon issue and one which maybe GADM can address. In the meantime, maybe look at using the updated GADM 3.6 polygons which, I assume, are improved.

Regards,

Chris

fnarita commented 5 years ago

Thank you very much Chris! This is great and so helpful.

Have a nice weekend! Futoshi