Update population-geography sql files.

[pratimakandel]

Syncs with 2011 National Data Census.

[cliftonmcintosh]

@pratimakandel

Can you provide a few examples of the geographic locations whose names were changed as part of this? I would like to verify that this works with the current geojson and topojson files.

Providing a list of half a dozen geographic locations whose names were changed would be useful. If the changes were only for local bodies, then examples for local bodies in different districts and provinces would be nice.

If the changes were for districts as well, an example or two of changed districts would also be useful.

For the name changes, were they only in the long_name variable or also in the name variable? If it was only in the long_name variable, then I believe the change will be compatible with the json files. If there are changes in the name variable, then we should do some checking because I believe the name variable is used in matching geo data to the SQL data.

[cliftonmcintosh]

I have confirmed that total population now matches the population in the pre-federal version at https://nepalmap.org/profiles/country-NP-nepal. I have spot-checked districts, and the following districts also have matching populations.

District Name	Pre-federal URL
Lalitpur	https://nepalmap.org/profiles/district-26-lalitpur/
Humla	https://nepalmap.org/profiles/district-56-humla/
Dang	https://nepalmap.org/profiles/district-60-dang/
Jhapa	https://nepalmap.org/profiles/district-04-jhapa/

[cliftonmcintosh]

I have navigated through the map, selecting a variety of local bodies without any problems so far. What I notice is that the "long name", the name that appears in the box on the map has been changed for all of the local bodies that I selected, and the map continues to work correctly. I would like to learn more about whether or not the shorter "name" was altered as well for any local bodies so that I can check them to make sure they also display correctly.

[nikeshbalami]

Hi @cliftonmcintosh

Based on the issues #92, I was the one who recommended updating local bodies' name so that it will be easier for users to navigate and find their local bodies, and in this PR both the name and long_name are updated in geography.sql file. We are yet to update the GEO file and currently searching for the easiest way to update geojson and topojson files with the current geography table.

Regarding the change, we can take an example of Rolpa district.

Here is how the previous table looks like:

Name	geo_code	year	parent_level	long_name	geo_level	parent_code
Duikholi	53001	2016	district	Duikholi	local	58
Lungri	53002	2016	district	Lungri	local	58
Madi	53003	2016	district	Madi	local	58
Rolpa	53004	2016	district	Rolpa	local	58
Runtigadi	53005	2016	district	Runtigadi	local	58
Sukidaha	53006	2016	district	Sukidaha	local	58
Sunchhahari	53007	2016	district	Sunchhahari	local	58
Suwarnabati	53008	2016	district	Suwarnabati	local	58
Thawang	53009	2016	district	Thawang	local	58
Tribeni	53010	2016	district	Tribeni	local	58

And here is the updated table with new local bodies name: (for reference: https://myrepublica.nagariknetwork.com/news/33282/)

Name	geo_code	year	parent_level	long_name	geo_level	parent_code
Parivartan Rural Municipality	53001	2016	district	Parivartan Rural Municipality	local	58
Lungri Rural Municipality	53002	2016	district	Lungri Rural Municipality	local	58
Madi Rural Municipality	53003	2016	district	Madi Rural Municipality	local	58
Rolpa Municipality	53004	2016	district	Rolpa Municipality	local	58
Runtigadhi Rural Municipality	53005	2016	district	Runtigadhi Rural Municipality	local	58
Gangadev Rural Municipality	53006	2016	district	Gangadev Rural Municipality	local	58
Sunchhahari Rural Municipality	53007	2016	district	Sunchhahari Rural Municipality	local	58
Sunil Smriti Rural Municipality	53008	2016	district	Sunil Smriti Rural Municipality	local	58
Thawang Rural Municipality	53009	2016	district	Thawang Rural Municipality	local	58
Triveni Rural Municipality	53010	2016	district	Triveni Rural Municipality	local	58

Also there were many other similar kinds of spelling errors, for example:

• Jaimuni (at NepalMap) - Jaimini (at National Data Profile)

• Kanthekhola (at NepalMap) - Kathekhola (at National Data Profile)

• Sahid Lakhan (at NepalMap) - Shahid Lakhan (at National Data Profile)

• Sulikot (at NepalMap) - Barpak Sulikot (at National Data Profile)

But unfortunately, we haven't created a separate table for the changed local bodies name.

If there are any problems with the display, I believe it will be because of the GEO file which is yet to be updated as per the “wazimap_geography” table. Do you have any recommendations on how we can do it, we kinda struggle on that part and @pratimakandel is currently exploring the QGIS and learning how to edit & update it.

[cliftonmcintosh]

@nikeshbalami

Thank you for the examples. They are useful. Based on the examples, here is what I have learned:

• The local bodies are searchable by new name after the name change.
• They can be compared.
• Data for the local bodies with name changes can be accessed correctly via the "Show Data" links.
• Hovers on the map show the old names. See examples below.

Based on this, it seems that the most important bit of information about each body is the geo code because it allows for matching data to places on the map.

In my experience, the GEO files are some of the hardest things to work with in this project. It's hard to edit them. They are each one giant line of text, and figuring out how to adjust them can be difficult. In this case, since the geo codes have not changed and because we know which local bodies have changed names and what the changes are, it seems like it would be possible to write a script to go over the files and alter the names.

I am curious about what might be best for "name", which is the value that shows up on hover. Will full names, like "Parivartan Rural Municipality" be unwieldy for hovers? Would using just "Parivartan" be acceptable? The "long_name" is what is searchable and is what is used in displays, like in the box with stats that shows on the map. One possibility would be to use a shortened name, like "Parivartan" or "Kathmandu" in the "name" field and the full, official name in the "long_name" field.

Here are some examples showing incorrect hover texts.

Jaimini shows Jaimuni

Parivartan Rural Municipality shows Duikholi

[nikeshbalami]

Thank you @cliftonmcintosh - using the short name at "name" field and official name in the "long_name" field is a nice idea, I will go ahead and prepare new sheet accordingly and ask @pratimakandel to update the geography.sql file again.

Regarding the GEO file, we were trying to resolve issue #61 with the new update but it looks like it's very difficult and time-consuming. For a moment, we will go ahead and create a table of changed local bodies name so that we can write a script to go over the files and alter the names.

[pratimakandel]

Sorry, there is a problem with my latest commit "Update Geography SQL file".

[pratimakandel]

@cliftonmcintosh I have been playing around with the geojson files to understand how it operates. I accidentally pushed changes to my dev repo with the updated geography sql along with some changes in the local.geojson. I deleted the local.geojson file and uploaded the correct one from Code4nepal repo. Everything works perfectly! However please let me know if there is a better way to make a pull request that does not change the local.geojson file.
Sorry for the inconvenience.

[cliftonmcintosh]

@pratimakandel

I have a question. Are you saying that the local.geojson included in this PR is an updated file that should have changes you made in it? Or is it "the correct one from Code4nepal repo"?

Are you trying to make a commit that does not change the local.geojson file? If so, I can try to provide some guidance for that.

[pratimakandel]

@cliftonmcintosh

Sorry for the confusion, this PR's latest commit has the correct local.geojson from Code4Nepal Repo. And yes, I am trying to make a commit that does not change the local.geojson file at all.

[cliftonmcintosh]

@pratimakandel

Thanks. Since Github says the local.geojson file that has been included here has changes
That file is very difficult to troubleshoot, and trying to verify that the extra lines that have been added in 76292b3 would be difficult.

I request that we figure out how to adjust this PR so that there are no changes to the local.geojson file, even if we think those changes might be safe. Here are some directions that should do that:

1. Check out the commit from before the changes to that file

git checkout 9b67d63

2. Copy that file somewhere

cp wazimap_np/static/geo/local.geojson wazimap_np/static/geo/local.geojson.old

3. Check out your dev branch

git checkout dev

4. Verify that that file is the only thing changes

git status

This should show one untracked file -- the file that you have just created, something like:

Untracked files:
  (use "git add <file>..." to include in what will be committed)

	wazimap_np/static/geo/local.geojson.old

5. Replace the current "local.geojson" file with the copy from earlier.

wazimap_np/static/geo/local.geojson.old wazimap_np/static/geo/local.geojson

6. Checck status to make sure that the "local.geojson" file has been modified.

git status

This should show something like:

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

	modified:   wazimap_np/static/geo/local.geojson

no changes added to commit (use "git add" and/or "git commit -a")

7. Stage the change to that file

git add wazimap_np/static/geo/local.geojson

8. Commit
9. Push
10. Verify that this pull request show that there are now no changes to the local.geojson file.

You might also be able to use git reset and then force push to achieve the same thing, but I am not sure what would happen with the merge commit that you have in this PR when you do that.

[pratimakandel]

@cliftonmcintosh
Thank you so much for the help. I merged your pull request to fix the local.geojson file. Also I have merged the recent changes too. While running the server, it worked fine, please let me know if there is anything missing.

[cliftonmcintosh]

Even though this change introduces a discrepancy between the SQL data and the map data, I think it is fine to go ahead and merge this update to the SQL data because the SQL data are more accurate. Subsequent changes to the map data should remove the discrepancy.

[cliftonmcintosh]

This change has been deployed to beta.nepalmap.org