![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Dependencies
Jun. 16th, 2021 02:56 pmI think that last time I posted, I said I was going to import some climate information. Well, that didn't work out. It turns out that what I thought was climate information was historical climate information as predicted by climate models, not actual observed reality. I wanted reality, so that source wasn't any good. I eventually found that Wikipedia has a list of cities by average temperature by month, which is great! ...except that it is by city, not by country. That's okay. I was going to need to deal with cities for the cost of living index. I just needed to do it a little bit sooner.
As I mentioned previously, database tables hold unique groupings of information. A country is in one table. Cities are in another table, with each city being linked to the country that it is in. Timezones are another group of unique things that can go into their own table and then be linked to cities in that timezone. However, the official timezone data is very confusing. I finally figured out which file to use and imported the data, only to discover that there are other timezones in use that are aliases of the canonical timezones and the file I was using had only the canonical timezones. There was some complicated way to get the information I need (I think), but ultimately, I went back to Wikipedia, which had all the timezone data I needed. I'm sure that the official timezone information works well for many things, but it just was too much work for what I needed.
So, did I end up getting all the cities imported? Well, there were a ton of them. I ended up using one list for the first import of cities and another list for city population, longitude, latitude, and timezone. The first list was more enthusiastic about cities from rich countries, while the second was supposed to have cities with more than 15,000 people (but actually also had districts inside cities, which wasn't necessary). In the end, I did what I could with the ones that matched up and had the program make a list of all the cities from the second list that weren't imported. I figured that if I needed them, I could import just the ones I needed later.
Yesterday, I spent nearly all my programming time trying to figure out the way to show the population of a city for the most recent year. Because I have some trouble reading (because of the brain damage from mefloquine), it was pretty challenging. I found a way that was supposed to work, but that - it turns out - isn't supported by the database I use. Then, I found a way around that, but - it turns out - that is for a more recent (I guess) version of the database than I use. Finally, I found a third way that actually worked. Why was it important? Think of how many cities there are in China. On the page that shows the country information, having 150 cities just doesn't look good. Also, it is mostly unnecessary. Eventually, maybe it will be useful to have some kind of a dropdown menu of cities, but right now, I'm just displaying the capital city and the nine most populous cities in decreasing order of population.
Today, I made a page to display the cities. Click on one of the cities on the country page, and it will take you to a page that shows the city, country, population, etc. Eventually, that page will display the climate and cost of living information (plus a link to the Wikipedia page for the city and (when this database goes back to being mainly for travel) links to nearby points of interest).
Tomorrow, I hope to finally import that climate information (and the URL for the Wikipedia page for the city, since it is in the same file). While this takes a while, I've learned a bunch about the database programming language and the text editor that I use. Plus, I would have probably never made this much effort importing information for the travel database without having another reason why I needed it, so that part is pretty cool too.
As I mentioned previously, database tables hold unique groupings of information. A country is in one table. Cities are in another table, with each city being linked to the country that it is in. Timezones are another group of unique things that can go into their own table and then be linked to cities in that timezone. However, the official timezone data is very confusing. I finally figured out which file to use and imported the data, only to discover that there are other timezones in use that are aliases of the canonical timezones and the file I was using had only the canonical timezones. There was some complicated way to get the information I need (I think), but ultimately, I went back to Wikipedia, which had all the timezone data I needed. I'm sure that the official timezone information works well for many things, but it just was too much work for what I needed.
So, did I end up getting all the cities imported? Well, there were a ton of them. I ended up using one list for the first import of cities and another list for city population, longitude, latitude, and timezone. The first list was more enthusiastic about cities from rich countries, while the second was supposed to have cities with more than 15,000 people (but actually also had districts inside cities, which wasn't necessary). In the end, I did what I could with the ones that matched up and had the program make a list of all the cities from the second list that weren't imported. I figured that if I needed them, I could import just the ones I needed later.
Yesterday, I spent nearly all my programming time trying to figure out the way to show the population of a city for the most recent year. Because I have some trouble reading (because of the brain damage from mefloquine), it was pretty challenging. I found a way that was supposed to work, but that - it turns out - isn't supported by the database I use. Then, I found a way around that, but - it turns out - that is for a more recent (I guess) version of the database than I use. Finally, I found a third way that actually worked. Why was it important? Think of how many cities there are in China. On the page that shows the country information, having 150 cities just doesn't look good. Also, it is mostly unnecessary. Eventually, maybe it will be useful to have some kind of a dropdown menu of cities, but right now, I'm just displaying the capital city and the nine most populous cities in decreasing order of population.
Today, I made a page to display the cities. Click on one of the cities on the country page, and it will take you to a page that shows the city, country, population, etc. Eventually, that page will display the climate and cost of living information (plus a link to the Wikipedia page for the city and (when this database goes back to being mainly for travel) links to nearby points of interest).
Tomorrow, I hope to finally import that climate information (and the URL for the Wikipedia page for the city, since it is in the same file). While this takes a while, I've learned a bunch about the database programming language and the text editor that I use. Plus, I would have probably never made this much effort importing information for the travel database without having another reason why I needed it, so that part is pretty cool too.
Previous: Part 6 - Decision-Making | Next: Part 8 - On The Subject Of Evacuations
