{"id":2368,"date":"2019-05-10T11:45:01","date_gmt":"2019-05-09T23:45:01","guid":{"rendered":"http:\/\/blogs.lincoln.ac.nz\/gis\/?p=2368"},"modified":"2023-05-07T03:24:43","modified_gmt":"2023-05-07T03:24:43","slug":"deleting-smokers-part-1","status":"publish","type":"post","link":"https:\/\/blogs.lincoln.ac.nz\/gis\/deleting-smokers-part-1\/","title":{"rendered":"Deleting Smokers – Part 1"},"content":{"rendered":"

This is the first post in a series covering the development of a Python script to carry out some analysis.\u00a0 We\u00a0cover the idea behind the script and develop some pseudo-code used to flesh it out.<\/em><\/p>\n

For those of you having trouble sleeping, this post may be the one for you.\u00a0 In several previous posts, we’ve covered some of the analysis done in looking at the link between tobacco outlets and secondary schools<\/a>.\u00a0 Some of those analyses required the writing of a Python script<\/a> to automate some complex analysis.\u00a0 There’s been a move underfoot\u00a0internationally to look at setting minimum distances between tobacco retailers and\u00a0 my colleagues at Otago have been keen to follow this up.\u00a0 We’ve been looking at a paper<\/a> that employed a Python script to systematically look over a dataset of retailers, determine their distances apart and then randomly remove retailers until there are none within a given distance of each other.\u00a0 Once all the retailers within a given distance are removed, we can run some statistics to evaluate the effects on policy. Then we do that several more times to get a representative sample size.\u00a0 Different countries have looked at different distances – the paper we’ve been looking at uses 500 ft (heathens)<\/em>.<\/p>\n

We contacted the paper’s authors, hoping that they might share their script with us, but alas, we’ve had no response.\u00a0 So if we’re going to carry out a similar analysis in NZ, we’ll have to write our own script, which will probably be an unpleasant experience, but it may work out that I can reuse some of the code another time.\u00a0 (I do slightly exaggerate things…I actually do like coding, but it can often be a frustrating experience.)<\/p>\n

In this series of posts I’ll step through the whole process, from development, to testing, to debugging and, hopefully, to a fully fledged, error-free, working script.\u00a0 This will either inspire you to start (or continue) your own coding, or more likely, convince you that coding is for someone else to do (I hope it’s the former).\u00a0 To my way of thinking, there are\u00a0four stages to scripting: conceptualising the script, writing the script, debugging the script and finally, running the script error free.\u00a0 I won’t say this is universal, but just my approach to it.<\/p>\n

Disclaimer: (ed. you seem to be doing a lot of that lately…) I wouldn’t call myself a Python expert.\u00a0 I know enough to make me dangerous.\u00a0 I’m sure some readers out there will be kilometres ahead of me and will easily pick out my errors.\u00a0\u00a0<\/em><\/p>\n

Stage 1 – conceptualising the script<\/strong><\/p>\n

A first step in writing a script is to be sure you’re clear about what you want to achieve.\u00a0 And it doubly helps if you can be as crystal clear as possible.\u00a0 Any ambiguity will rear its ugly head and force you to rethink things – that’s not a bad thing but if you can be as clear as possible going into it, you can often speed up the process.\u00a0 So a good first cut is to list the important tasks that need to be done as well as the order in which they have to happen if order is important.<\/p>\n

Here’s what they say in the paper about their script: “ArcMap was used to identify all tobacco retailers within 500 ft\u00a0from another tobacco retailer.\u00a0 A custom script was written in Python to randomly select one tobacco retailer to be deleted from the list.\u00a0 The process continued iteratively until the list contained zero tobacco retail outlets from within 500 ft of another retailer.\u00a0 This random -choice analysis\u00a0(sic)<\/em> yields different results each the process is run (see Figs. 1 and 2).\u00a0 Thus the process was run 1000 times and the mean number of retailers was removed from each list.”\u00a0 (Myers et al.<\/em>, 2015).\u00a0 I include figure 1 to help explain this:<\/p>\n

\"\"<\/a><\/p>\n

It’s interesting to note the figure above focuses on picking “proximity relationships” rather than points.\u00a0 After a bit of thought this make sense when you consider two points close to each other.\u00a0 Each has a point within a given distance and so would be of interest, but there’s only one relationship – this makes the whole process a bit easier, I think.\u00a0 That’s already got me thinking of a potential tool I could use – an OD Cost Matrix<\/a>.\u00a0 Not sure yet that that’s the right tool.<\/p>\n

That’s an overview in sentence form – next I’ll see if I can list those steps in order with more of a GIS slant:<\/p>\n