GIS to show when, where and how death occured

(1)

Jenny Hagman

GIS to show when, where and how death occured

BACHELOR'S THESIS

Högskoleingenjörsprogrammet Geografisk informationsteknik Institutionen för Institutionen i Kiruna

Avdelningen för -

2000:78 • ISSN: 1404-5494 • ISRN: LTU-HIP-EX--00/78--SE

(2)

Jenny Hagman GIS-3

GIS-engineer programme, Kiruna Luleå University of Technology

Document: report v4.doc Date: 2000-09-15

(3)

Preface

This report is submitted in fulfilment of an undergraduate project at the GIS (Geographical Information System) – engineer study programme. The program is located in Kiruna and belongs to Luleå University of Technology. I did the

undergraduate project in the spring of 1999 at SMC (Spatial Modelling Centre), Kiruna.

(4)

1 Abstract

SMC has a database, referred to as TOPSWING (Total Population of Sweden Individual and Geographical database), since 1997. The major obstacle in using the database by a wide range of users, is the inefficient way the data can be accessed and displayed. This undergraduate project aims at creating an application that simplifies this process in the content of researching death causes.

(6)

2 Sammanfattning

SMC har en databas, här åberopas som TOPSWING (Total Population of Sweden Individual and Geographical database), sedan 1997. Det största hindret som uppstår när ett flertal användare anropar databasen är det ineffektiva sätt som data behandlas och visas på skärmen. Detta examensarbete har som mål att skapa en applikation som underlättar denna process i undersökningen av dödsorsaker.

(7)

3 Introduction

SMC is a research centre that is governed by Umeå University and Luleå University of Technology. SMC has, in contrast to many other research institutes, focused its research activities on the human factor of environmental changes. Work at SMC is being

undertaken on two fronts: international level of pure and applied research and application-driven studies. Several international projects are now assembling natural science databases about the environment. At SMC these will be complemented by time- and space- specific information about the population and its activities. SMC will utilise the rich Swedish statistical resources in order to test the potential of databases of micro data for this type of research. Methodological developments will be stimulated within, for example, time-geographic microsimulation, geographic information techniques, data languages and artificial neural networks.

SMC is affiliated with the Environment and Space Research Institute (MRI), a research and development project under the Swedish Council for Planning and Co-ordination of Research (FRN). MRI has further affiliations. These are Atmospheric Research Program (AFP), Climate Impact Research Centre (CIRC) and Environmental Satellite Data Centre (MDC).

SMC has a database that contains socio-economic information about all people in Sweden during the years 1985-1995. The database is called TOPSWING (Total Population of Sweden Individual and Geographical database). The kind of information that exists in the database is for example where a person lives, income, education level, migration, civil status, sex and age. If a person is dead there will be information about the cause of death, what year the person died and so on. Microsoft SQL server handles TOPSWING. The data in the database comes from Statistics Sweden and the database was created in 1997 by merging different registers.

The main aim of SMC is to develop a microsimulation model of Sweden using the database as support. By using Microsoft Access, SQL graphics edition or SPSS¹ information from the database can be reached. The most common way is to use

Microsoft Access and write SQL-statements². The processing time of a SQL-statement can be very long considering the large database tables. One part of this undergraduate

1 SPSS = a statistical program

2 SQL = Structured Query Language, a query language that is used to get information from a database.

(8)

project was to make the search procedure from the database easier and less time consuming. The particular application that was studied was death causes. No analysis was undertaken by me, where, when and why is up to the scientist to decide.

This undergraduate project had it focused on death causes. Where and when, why is up to the scientist to decide.

(9)

4 Aims

The aim of this undergraduate project was to create an application in ArcView 3.0 using the program language Avenue. The application can be used in the starting process of a research project or for investigation of unknown patterns. It is important to study exploratory analysis of the data. In the current setting this is not as easy as it should be.

Not only manipulating several tables in the database but also exporting the data to different systems of softwares is very tedious and time consuming.

In the application, the user should be able to choose a cause of death, a year and one or two regions in Sweden. These are the different divisions of Sweden:

• All of Sweden

• County

• Municipality

• Parish

The result will be shown as the rate, which is the number of people that died in the selected region divided by the number of people in the region times 1000. (Figure 1)

Figure 1

The result will be shown in a bar chart.

The number of people that died in the selected region(s) during the selected year

* 1000 = rate Population in the selected region(s) during the selected year

(10)

5 Methodology

My approach on this undergraduate project, and which makes this project special, is the construction of new tables to make the search from the database much faster. Previously the user had to write long SQL-statements to get a result. To search through a database that consists of every human being in Sweden during eleven years takes a long time.

After the SQL-part, the user had to import the data to ArcView to be able to do the graphs/investigation. If the user wanted to do the same thing for another cause of death, the only way was to start all over again. Of course this took a long time.

By making an application where it will be easy for the user to get a result without being an expert on SQL or the database, the number of people who will use it would hopefully increase.

The method I used during the project can be divided into three steps:

1. Create new tables by making SQL-statements to the database.

2. Make the graphical user interface (GUI) to the application.

2.1. Different scales (All of Sweden, county, municipality or parish).

2.2. Point and click features.

2.3. Visual representation of rate.

3. Connect the application to the new tables in the database.

Resources used during the project are ArcView 3.0 and its program language Avenue, the extension Dialog Designer, TOPSWING, Microsoft Access and Microsoft Word.

(11)

6 The application

6.1 Creating new tables

Because the tables in the database did not suit the requirements, new tables had to be created. This was important because the selection from the tables must be fast. If it is too slow, the user will probably get annoyed and stop using the application. So this was a very important step. If the selection from the new tables was not fast enough would show further on.

The new tables were created by SQL-statements using the existing tables in the database.

One big problem with this was the time requried. In the worst case it could take a day or even more to get an answer and then maybe realise that the question was wrong…

The new tables contain:

• The population of a region a single year.

• How many people died in the region due to a specific cause of death during a specific year.

6.1.1 Table 1: Region, year and population

• The population of a region a single year.

For this table the region is essential. A region is not represented as a single number in the database. It is divided into three different fields. These are bCountyNo, bCommunityNo and bParishNo. (b stands for bostad, which is the Swedish word for home.) For tables and their fields, see Appendix 1. The first step was to create a table (jha_areas_alive) which would show the number of living persons in each area each year. Data was extracted from PersonYearOccupation. The SQL-statement for this new table can be seen in Appendix 2.

Figure

PersonYearOccupation

• pid

• year

• bCountyNo

• bCommunityNo

• bParishNo etc.

jha_areas_alive

• count(pid) as alive

• year

• bCountyNo

• bCommunityNo

• bParishNo

Figure 2

(12)

The difference between the two tables may not seem big, but it is. The small word “etc.”

represents a number of fields that does not exist in the table jha_areas_alive.

By comparing the data from the new table, jha_areas_alive, with data from Sweden Statistics, accuracy could be assessed. In general you could say that the data became more and more accurate with time. The data from the table regarding the middle of the 1980s were more often failing to correspond to the data from Sweden Statistics. In general the data are more correct in the 1990s. This depends on the way of collecting data. Data from the 1990s are for example more accurate than data from the 1980s.

To be able to search for a region in one field it was necessary to merge the three fields for county, municipality and parish into one field. Merging the fields will mean that the new field will have a number containing five or six digits depending on how many digits bCountyNo contained. The system to do this could be seen below:

bCountyNo bCommunityNo bParishNo

Parish AA BB CC

Municipality AA BB 00

County AA 00 00

All of Sweden 00 00 00

Figure 3

Figure 3 shows that County is getting its data from bCountyNo and only from there. It would not need any data from bCommunityNo or bParishNo so these “empty places”

will be filled up with zeros. For Municipality it is necessary to know the bCountyNo the selected municipality belongs to and the number for the bCommunityNo itself. But the data from bParishNo is irrelevant. Parish needs data from all fields. For All of Sweden on the other hand, a selection of a specific field is not necessary because every field should be selected.

The table jha_Regions_Populations was created with a SQL-statement. This table contains region-field (at this point the table only contains county), year and the sum of all living persons (population).

By using the command INSERT in a SQL-statement, municipality and parish could be added to jha_Regions_Populations.

(13)

To get the number of the region:

County bCountyNo * 10.000

Municipality bCountyNo * 10.000 + bCommunityNo

Parish bCountyNo * 10.000 + bCommunityNo * 100 + bParishNo

Figure 4

It is possible to add data (INSERT) for All of Sweden by setting Region to zero. By making a “group by year” and only on year, the population on All of Sweden is received.

Appendix 3 shows the SQL-statements for this new table and also parts of the results.

Figure 5

6.1.2 Table 2: The number of dead people, cause of death, year, region

• How many people died in the region by a specific cause of death in a specific year.

This new table had to be created in two steps. In the first step the table jha_pd1 was created and data from the original table PersonDeath was used. The following fields was selected: the personal ID (pid) for the persons who died, the year before the persons died (lastyear) and cause of death (undorsak). The SQL-statement for the creation of jha_pd1 can be seen in Appendix 4. The reason that the wanted year is not the year the person died, but the year before, is that if a person dies during a year there will be no data for that person that year. But if the selected year is the year before, when the person was still alive, then there is data. All tables with fields can be seen in Appendix 1.

jha_areas_alive

• count (pid) as alive

• year

• bCountyNo

• bCommunityNo

• bParishNo

jha_RegionsPopulations

• population

• year

• region

(14)

Figure 6

Step number two, which is the last step, was to create the table jha_pyo1. This table had six fields. These were pid from the original table PersonYearOccupation, lastyear and undorsak from jha_pd1, bCountyNo, bCommunityNo and bParishNo, all from

PersonYearOccupation. By using JOIN it was possible to merge PersonYearOccupation with jha_pd1. The connecting part was pid from the two tables and lastyear from jha_pd1 and year from PersonYearOccupation. The reason to join on lastyear and year is that the data from lastyear is connected to the year a person died. The SQL-statement to create jha_pyo1 can be seen in Appendix 4.

Figure 7

PersonDeath

• pid

• DeathDate

• Undorsak etc.

jha_pd1

• pid

• lastyear

• undorsak

jha_pd1

• pid

• lastyear

• undorsak

PersonYearOccupation

• pid

• year

• bCountyNo

• bCommunityNo

• bParishNo etc.

JOIN

jha_pyo1

• pid

• lastyear

• undorsak

• bCountyNo

• bCommunityNo

• bParishNo

(15)

Now the table jha_pyo1 and jha_RegionsPopulations are ready to be used! As shown before, the tables look like this:

Figure 8

Unfortunately I was forced to exclude the years of 1985 and 1986 from the application.

For some unknown reason, these two years lacked a lot of data. The risk for producing incorrect results was considered so large that this action was necessary.

6.2 The Graphical User Interface

6.2.1 The outline map

The map that is used in the application is obtained from the red map (Lantmäteriverket).

Its original scale is 1:250 000. In the application the scale changes constantly. For example when the user uses the button zoom in. The data from the red map is divided into four layers. The first one is All of Sweden. Here are the borders of the country from the county-layer is selected and added to a new single layer. County, municipality and parish already existed. A person that is familiar with Sweden only needs a quick look at the map to see that something is very wrong. It is the coastline that is incorrect. This is due to the fact that the borders for county, municipality and parish stretch out into the water. (See figure 9.) All the islands that surround Sweden must also belong to a parish, a municipality and a county. As a result the boarders stretches out into the water.

Attempts to correct this, so that the boarder would be were the shoreline is, failed.

6.2.2 The views

The Graphical User Interface (GUI) shows a map over Sweden (similar to the one described above). Beside the map there are several comboboxes. A combobox is a box that for example contains a list of several different areas. Several comboboxes can be seen in figure 9.

In the top combobox in the main view, the first combobox, the user can choose between the different scales, all of Sweden, county, municipality or parish. Cause of death can be

jha_pyo1

• pid

• lastyear

• undorsak

• bCountyNo

• bCommunityNo

• bParishNo

jha_RegionsPopulations

• population

• year

• region

(16)

chosen from the second combobox. The third combobox is for region 1 and the fourth combobox is for region 2. By pressing the button 2 the user can study two regions. The fourth combobox is the only combobox that is optional. The user can also select

region/regions by first clicking on the tool 1 for Region1 or 2 for Region2 and then click on the map for the wanted region. The name of the region will then appear in the

combobox. If this is not the region that you had in mind you can click on the map again for “your” region. This can continue until “your” region is found. The last thing to select is year, which is available through the fifth and last combobox.

When the user has made the selections, he/she presses the button Go! and the connection to the database is established. As the processing is done, the result is shown as a bar chart. The bar chart will be seen in ¼ of the screen and the rest will show the map and the comboboxes. The selected region/regions will be marked with a yellow colour. The time from that the user presses the button Go! to that an answer is shown in the bar chart is a couple of minutes depending on the size of the region(s).

The extension Dialog Designer was used to create comboboxes, buttons and text in the view.

Figure 9

button Go!

bar

chart button 2 map comboboxes

(17)

6.3 Connect the application to the new tables in the database

The major part of the work with this project was to write scripts in Avenue. A script is a sequence of commands. By connecting different scripts to each other you can make a connection between the application to the new tables in the database. Due to this

connection it is possible to find the rate of people who died based on the settings that the user makes.

Figure 10 and figure 11 shows in what order the different scripts interact. A summary of what each scripts does can be read in Appendix 5.

doc.open

start Start_noselection

Start_sverige_combobox

Val av år samt dc

Val av tema samt area 1 och 2

nolegend

ickesynlig fullextent These scripts runs when view_granser is opened.

1

2

3 4

5

8

6 7

Figure 10

(18)

Figure 11

the empty list, lstTom, sends to con_dc

select

con_all_test

con_dc

year

barchart returns

the selected undorsak- string in lstTom sammankoppling

returns the selected year-string in lstYear 1

lstRT sends to con_all_test

4

the empty list, lstYear, sends to year

6

7 This tree-diagramm of scripts

starts when button Go! is pressed

2

3

5

Omradesval_1

Omradesval_2

Knapp_osynlig

Runs when the user clicks on the map. Region 1 is selected.

Runs when the user clicks on the map. Region 2 is selected.

Runs when the user presses the 2-button.

(19)

7 A guide through the application

This is a small guide through the application. The first thing that appears when the project is opened is the project window. The view-icon indicates that the project only contains one view. This can not be changed. It is not possible to add or remove any views or charts. The reason for this is to protect the application so that the most

important (and only) view will not be deleted. Because it is not possible to add views, no users will be confused about which view they should open.

After opening the view view_granser this shows:

(20)

The combobox Divide Sweden is different from the other comboboxes. Divide Sweden is directly connected to the map. By changing the selected criteria, for example from All of Sweden to County, changes are made immediately, in contrast to the rest of the

comboboxes where the changes are made after querying the database.

By clicking the down-arrow in the comboboxes the user can choose different settings. In the following example the settings are:

Divide Sweden: county Cause of death: diabetes Region 1: Hallands län Region 2: Norrbottens län

Year: 1990

The result is shown as a bar chart. The county of Halland can be seen in red and the county of Norrbotten is green. The y-axis always begins at zero and end at three.

The selected regions are now yellow.

By clicking on the bar chart, a window with the title Identity Results comes up. Identity Results shows the name of the selected region(s) and its exact digit for the rate.

(21)

By closing Identity Results a new selection from the database can be made. In the next example the new settings are:

Divide Sweden: Parish

Cause of death: Malignant tumour in respiratory organ

Region 1: Abild

Region 2: Jukkasjärvi

Year: 1987

Before the user has pressed the button Go!, the result from the last search can still be seen in the bar chart.

The result from the settings:

(22)

The bar chart shows that no one died in Abild during 1987 of Malignant tumour in respiratory organ. To get the exact digit it is, as before, possible to look at Identity Results by clicking on the bar chart.

It is not possible to get a zero-value for Abild in the Identity Result window. Abild is so small that it is not shown on the map even though it is marked with a yellow colour. One way to see a parish that does not shows up is to use the button Zoom to Selected.

Zoom to Selected

(23)

By closing the window Identity Results and make the view active it is possible to use the button Zoom to Selected. Here is the result:

The difference is marginal, since Abild and Jukkasjärvi are located in two different parts of the country. By using the button Zoom to Full Extent the whole map is shown again.

Zoom to Full Extent

Now there are two ways to find out where Abild is.

• Use the tool Zoom In. This tool is used manually. Because the smallest parishes is in the southern part of the country it is a good idea to start to zoom here.

Zoom In

• The other way to find out where Abild is, is to make new settings and only search for one region, in this case, Abild. It would now be easier to find out were that region is.

(24)

The settings will look like this:

Now it is easier for the user to find out were a specific region is. By using the button Zoom to Selected the result will be as shown:

This is too close, too much zoomed in, to say were in Sweden Abild is. By using the tool Zoom Out and clicking in the centre of the view, the map will be zoomed out step by step.

Zoom Out

(25)

After a few times the map will look something like this:

Here it is possible to see how small the parishes is in the southern part of Sweden.

In the application there are also these functions:

• Tools

Pan – the hand, moves the map in different locations.

Pointer – its main task in this application is to choose graphics. For example, choose view instead of bar chart. The Pointer is also important for the user in the way that it is a familiar tool.

When the tool 2 is pressed down, the user is able to select region 2 by clicking directly on the map. This is a complement to selecting region by using the down-arrow in combobox Region2. This could be very useful if the user is not sure about the name but knows the approximate location or of course if the user is sure about the location but have no idea what the region is called. When the tool 1 is pressed down the same thing could of course be done for region 1.

(26)

• Buttons

With Help the user can get help with questions regarding ArcView.

• Menus

There are two menus in the application. These are File and Help. Under File there are the commands open, close, print, export and exit project. Under Help there are the usual help-files.

In comparison to ArcView´s standard GUI some menus, tools and buttons have been

“removed” to make the GUI as easy as possible to understand. The menus, tools and buttons, which are missing, are not really removed. They are just set invisible. This means that they could easily bee seen if the user would like to. By changing the settings to visible, the user will be able to see the standard GUI again. Of course a person who knows ArcView 3.0 and Avenue well should do this.

(27)

8 Results

By making new tables based on parts from already existing tables in the database it was possible to enhance the searching process. With a GUI that is easily understood and a number of scripts that connects the application to the new tables in the database a rate could be calculated based on the settings that the user made. The “answer” from the database is displayed as a bar chart. An application was born!

The time needed for this undergraduate project was totally 13 weeks excluded the time it took to write this report. That would be too scary… It was planned to be a 10 weeks job, including the writing of the report, but reality got in the way.

8.1 Does the application work?

Does the application work? This is maybe the most interesting question. As far as I have been able to check, it works! Of course it is not perfect. Some of the things that can be improved are listed under the section “Discussion”.

8.2 Is it easy to use?

One of the main concerns when I made the application was that it was going to be easy to use. The main problem previously was that to get the information from the database the user had to know SQL well. It is always good to know some SQL but I do not think that it should be a condition to get data from the database. One of my goals was to create an application that would be easy to use and would not include a number of unnecessary menus, tools and buttons. I think that I have reached this goal.

(28)

9 Discussion

If I were to do this again I would do many things in a different way. For example, in the beginning I would try to see the problem from a bigger view and not focus too much on details. It is important to first have a survey on what the project is all about so that you later can figure out how the details are going to be solved.

During the work I have come to discover some details that would make the application better. For example:

• The script fullextent is not able to make Sweden to its original size if Sweden has been zoomed out from its original size, which is if Sweden is presented in a scale smaller than the default. Has Sweden on the other hand been made bigger, then the original size is back. Fortunately it is more common that Sweden is zoomed in than zoomed out from the original scale.

• Because the application uses data from lastyear, the information becomes incorrect if a person has moved during his/hers last year alive. The data may show that the person lived in Skövde but actually the person had just moved to Burträsk.

• There is no easy way to save data.

• The script con_all_test is too big and clumsy. It should be possible to divide it into smaller parts. For example by removing parts from con_all_test that includes

strRegvillkor, strRegvillkor2 and strRegslut. A general cleaning of the program code is necessary.

• It would be better if the y-axis on the bar chart could change depending on the result.

It would be even better if the user could choose if this function should be activated or not.

• The Identity Results window can not show zero values.

• It would look good for the eye if the colour of the columns had the same colour as the selected regions in the map. It would also be easier for the user to see what column was connected to which region.

In spite of this I can proudly say that the application works! One problem though that I realised during the work was the absence of a schedule that had something to do with reality.

I think it is important to see this job as a first version of the application. As mentioned above there are several things that can be made better. It will hopefully be easier to make the next version (the current application has already been amended at SMC by another researcher) because now there is something to build from.

(29)

10 Conclusions

The goal with this undergraduate project was to make an application that would answer to the needs to find out the rate of people whom died due to a specific cause during a specific year in a selected region(s). This goal has been reached.

(30)

11 Acknowledgment

I would like to thank these people:

• Coomaren P Vencatasawmy, my supervisor for this project.

• Mats Sundberg whose excellent programming skills have been very useful!

• Johan Esko whose advice on Avenue-programming has been very helpful.

• Lisa Sparrings who has helped me with Avenue.

• Anders Forsberg who has provided me with data from the red map.

• Moa Hagman who has helped me with the English language.

(31)

Appendix 1

Tables

jha_RegionsPopulations

• region

• population

• year

jha_pyo1

• pid

• lastyear

• undorsak

• bCountyNo

• bCommunityNo

• bParishNo

jha_pd1

(This table was needed to create the table jha_pyo1)

• pid

• lastyear

• undorsak

jha_areas_alive

(This table was needed to create the table jha_RegionsPopulations)

• bCountyNo

• bCommunityNo

• bParishNo

• year

• count (pid) as alive

The original table PersonDeath contains following fields:

(This table was needed to create jha_pd1)

• pid

(32)

• DeathDate

• undorsak and so on…

The original table PersonYearOccupation contains following fields:

(This table was needed to create jha_pyo1 and jha_areas_alive.)

• pid

• year

• bCountyNo

• bCommunityNo

• bParishNo and so on…

(33)

Appendix 2

PersonYearOccupation → jha_areas_alive

SELECT bCountyNo, bCommunityNo, bParishNo, year, count(pid) as alive INTO jha_areas_alive

FROM PersonYearOccupation

GROUP BY bCountyNo, bCommunityNo, bParishNo, year

(34)

Appendix 3

jha_areas_alive → jha_regionspopulations

SELECT bCountyNo*10000 as Region, Year, sum (alive) as Population INTO jha_RegionsPopulations

FROM jha_areas_alive

GROUP BY bCountyNo, Year go

INSERT jha_RegionsPopulations (Region, Year, Population)

SELECT (bCountyNo*10000)+(bCommunityNo*100), Year, sum (alive) FROM jha_areas_alive

GROUP BY bCountyNo, bCommunityNo, Year go

INSERT jha_RegionsPopulations (Region, Year, Population)

SELECT (bCountyNo*10000)+(bCommunityNo*100) + bParishNo, Year, alive FROM jha_areas_alive

go

INSERT jha_RegionsPopulations (Region, Year, Population) SELECT 0, Year, sum (alive) FROM jha_areas_alive GROUP BY Year

The result is shown below:

(There is county in the beginning.)

Region Year Population

---

10000 1985 1577596

10000 1986 1593333

10000 1987 1606157

10000 1988 1617038

10000 1989 1629631

10000 1990 1641669

10000 1991 1654512

10000 1992 1669840

10000 1993 1686230

10000 1994 1708502

10000 1995 1725756

(35)

30000 1985 251754

30000 1986 254938

30000 1987 257739

30000 1988 260476

(The end shows parish and last but not least there is All of Sweden.)

258402 1995 2506

258403 1985 1219

258403 1986 1220

258403 1987 1239

258403 1988 1271

258403 1989 1299

258403 1990 1306

258403 1991 1318

258403 1992 1316

258403 1993 1291

258403 1994 1256

258403 1995 1228

0 1985 8360172

0 1986 8381519

0 1987 8414089

0 1988 8458888

0 1989 8527039

0 1990 8590630

0 1991 8644120

0 1992 8692013

0 1993 8745109

0 1994 8816381

0 1995 8837496

(36)

Appendix 4

explanation: (floor(deathdate/10000) + 1899) = (950101/10000 = 95 + 1899 = 1994) PersonDeath → jha_pd1

SELECT pid, (floor(deathdate/10000) + 1899) AS lastyear, undorsak INTO SMCWORK..jha_pd1

FROM persondeath WHERE undorsak <> null

--- Indexera tabell jha_pd1

--- PersonYearOccupation JOIN jha_pd1

SELECT pyo.pid, lastyear, undorsak, bcountyno, bcommunityno, bparishno INTO SMCWORK..jha_pyo1

FROM

jha_pd1 pd1 JOIN PersonYearOccupation pyo ON pd1.pid = pyo.pid AND pd1.lastyear = pyo.year

The criteria for the index were:

• Unique

• Clustered

(37)

Appendix 5

The following scripts was used to make the GUI:

1. Doc.open

1.1. Ran the script start every time when the view view_granser was opened.

2. Start

2.1. Ran the scripts 3-9.

3. Start_noselection

3.1. Set All of Sweden as the selected and visible theme.

4. Start_sverige_combobox

4.1. Emptied every object that was not connected to All of Sweden.

5. Val av år samt dc

5.1. Got the first row in the table year.dbf and showed it in combobox year.

5.2. Got the first cause of death in the table d_c.dbf and showed it in combobox cause of death.

6. Val av tema samt area 1 och 2

6.1. Set the selected theme (the first time that was All of Sweden, see script start_noselection) to the active and visible theme.

6.2. Got the selected themes vtab (virtual table) and their fields.

6.3. Got the field with the name(s) for the region(s) and showed the name(s) of the region(s) that belong(s) to the selected theme in combobox Divide Sweden.

7. Nolegend

7.1. The legend’s size was set to zero. The user can not see it.

8. Ickesynlig

8.1. The icons for tables, layouts and scripts are made invisible in the project window.

9. Fullextent

9.1. The map of Sweden was set to full extent. End of start-script.

This starts when button Go! is pressed:

1. Select

1.1. Created a query to the database where Region1 was selected.

1.2. If region 2 existed, the same thing was also made for Region2.

1.3. Sends information about which region(s) and the type of region (All of Sweden, county, municipality or parish.) to the script con_all_test.

2. Sammankoppling

(38)

2.1. Connects the selection of cause of death made from the combobox with the number that it will appear as in the database.

3. Con_dc

3.1. Created a query to the database where cause of death was selected.

4. Year

4.1. Created a query to the database where year was selected.

5. Con_all_test

5.1. Found the database that the SQL-statement later will be connected to.

5.2. Fetched the region(s), the cause of death and the year from other scripts.

5.3. Made a SQL-statement.

5.4. Made a connection to the database.

5.5. From the answer from the database, rate was calculated. Rate is the number of people who died in the specific region from the selected cause of death during the selected year divided with all people in that region under that period, times 1000.

6. Barchart

6.1. Showed the region(s) and the rate(s) in a barchart.

7. Knapp_osynlig

7.1. When the button 2 was pressed the combobox Region2 and the text above it was set to visible if it was invisible and the other way around.

8. Omradesval_1

8.1. Got the point where the user had clicked.

8.2. The name of the region where the point was, was sent to combobox Region1.

9. Omradesval_2

9.1. Got the point where the user had clicked.

9.2. The name of the region where the point was, was sent to combobox Region2.

GIS to show when, where and how death occured

Jenny Hagman