{"id":2147,"date":"2018-06-01T10:46:07","date_gmt":"2018-05-31T22:46:07","guid":{"rendered":"http:\/\/blogs.lincoln.ac.nz\/gis\/?p=2147"},"modified":"2023-05-07T03:30:27","modified_gmt":"2023-05-07T03:30:27","slug":"another-point-on-the-map-part-3","status":"publish","type":"post","link":"https:\/\/blogs.lincoln.ac.nz\/gis\/another-point-on-the-map-part-3\/","title":{"rendered":"Another Point on the Map (Part 3)"},"content":{"rendered":"

Quality assurance is crucial when creating new data, especially with geocoding.\u00a0 We cover some of the frustrations of this process and some useful tips (definition queries and label scale ranges) to make it a bit easier.<\/em><\/p>\n

I can safely say that over the past few days I have been almost everywhere in New Zealand: from Invercargill to Cable Bay, from Te Araroa to Westport, and boy is my mousing finger tired.\u00a0 I’ve visited no less that 948 locales and, most sadly of all, never even left my office.\u00a0 Lest you think that GIS is all glitz and glory (I sadly had to turn down the invitation to the Meghan and Harry’s wedding to get this work done), this post will cover some of the drudgery of bearing the mantle of GIS analyst.<\/p>\n

In previous posts we’ve covered\u00a0some analysis around the proximity of tobacco retailers to secondary schools<\/a>.\u00a0 One of the key layers needed for that analysis was a point layer of tobacco retailers and late last year we got an updated spreadsheet of addresses that needs to be included into the existing layer.\u00a0 Geocoding is the process of taking street addresses and converting them to points on a map.\u00a0 It’s not a difficult to do, but the accuracy of those points on the map shouldn’t be taken for granted – not by a long shot.\u00a0 Getting the points on the map is the easy part; the much harder part is assuring yourself that they’re correct.\u00a0 Here’s a for instance.\u00a0 Amongst the many points in these new data is one listed for 34 London Street, Lyttelton.\u00a0 Now that’s right in my proverbial backyard (almost)!\u00a0 Imagine my surprise when the geocoded point on the map ended up here:<\/p>\n

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

Correct, it is London Street, but it’s the Richmond one rather than the Lyttelton one.\u00a0 Points like this rang enough alarm bells that it was time for a serious quality assurance effort, which, sadly, meant going through each point: one by one…<\/p>\n

I did quite a good job of putting this off for as long as possible, but eventually I knew I just had to knuckle down and get it done.\u00a0 So I thought it through and tried to come up with a good systematic plan to approach this.\u00a0 Let’s have a quick look at the geocoded layer’s table:<\/p>\n

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

When geocoding through ArcMap, you get a “Score” attribute at the far left which gives you a sense of how good of a match it found.\u00a0 Some of the above scores are at 100, which is about as good as it gets, while the lowest value visible above is 71.2.\u00a0 Overall, the lowest score in this layer was 61.16.\u00a0 Of the 948 points, 541 has a score of 100.\u00a0 My hypothesis was that points with a score of 100 would probably be pretty close to their true location and decreasing scores would mean more work in getting them properly located (which turned out to be correct).\u00a0 I tend to approach things by getting the more difficult things out of the way first (while I’ve still got some enthusiasm) and leave the easier tasks for later, so I sorted the points by ascending score and started working my way though.\u00a0 This meant having the table open and selecting each point individually, then clicking on the Zoom to Selected button:<\/p>\n

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

(I later discovered that I could do the same thing by double-clicking on the wee grey box at the left end of the record).\u00a0 With some judicious zooming in, I could then see if the point was in the right place:<\/p>\n

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

If it wasn’t, I can just shift it to the right place with the editing turned on.\u00a0 Points could often be challenging to place accurately as the picture above illustrates.\u00a0 I can clearly see address points for numbers 215 and 227, but where’s the best place for 217?<\/p>\n

Sometimes it wasn’t obvious where the point should be, so I had Google Maps open at the same time (having a second screen was a godsend here):<\/p>\n

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

More often than I care to admit, I also needed to switch to satellite view to confirm or even go so far as to look at Street View:<\/p>\n

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

(Sidenote – this particular example is interesting because in Street View this Caltex station is clearly visible and we saw that it’s on the above Google Maps map view as well.\u00a0 But here’s that same location in the Satellite view:)<\/em><\/p>\n

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

With this process, I worked my way through the points until I got to the 100 scores.\u00a0 Some of the sub-100 points were 10s or 100s of kilometres away from their true location and took some detective work to place correctly.\u00a0 I then got a little sidetracked (pesky classes…) and had to leave it for a bit.\u00a0 When I came back, the records were unsorted I couldn’t quite remember how I was working through so I resorted the points by ascending address and started working through from the 1s upwards (note to self: take better project notes next time).<\/em>\u00a0 I soon realised that I was starting to repeat myself and stopped to regroup.\u00a0 With the points listed in ascending order of address, the scores were a mix of values.\u00a0 I needed a way to just show the points with a score of 100 but keep the ascending address order.\u00a0 And here’s where a definition query<\/a> came in very handy.<\/p>\n

I don’t think these have come up before but definition queries are useful ways of limiting which features are visible (on the map and in the table) in a layer.\u00a0 It’s sort of like a query (well, it is, in fact, a query) but instead of highlighting records in blue, ArcMap only displays the records that match the query.\u00a0 Let’s start with a quick view of the table with addresses sorted in ascending order – note the mix of scores at left:<\/p>\n

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

To set up a definition query, open the layer Properties and go to the (surprise, surprise) the Definition Query tab:<\/p>\n

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

Click Query Builder… to do just that:<\/p>\n

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

OK > OK then filters the records and I’m just left with only those with a score of 100.\u00a0 The other records are still there, they’re just not being displayed:<\/p>\n

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

(And note that there are 541 of the 948 displayed.<\/em>)\u00a0 Now I can work my way through these points without having to revisit the ones I’ve already done.<\/p>\n

Another useful thing was to label the points so I didn’t have to keep going back to the table to see where they should be.\u00a0 Labelling is also done from the layer Properties:<\/p>\n

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

You can set the labels and font sizes and colour and they’ll be displayed on screen (don’t forget to tick the “Label features in this layer” box):<\/p>\n

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

After a while of doing this, I found the map getting a bit too crowded with all those labels and realised I only really needed them when I was zoomed in beyond a certain scale.\u00a0 After a bit of trial and error I decided that I only needed to see the labels with scales greater than 1:6,000.\u00a0 But rather than turning the labels on and off manually for each point, I changed a setting in the label properties so that they only display beyond that scale.\u00a0 Back in the label properties, one can do this by clicking on the Scale Range… button:<\/p>\n

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

Now, the labels only get turned on when I zoom in far enough:<\/p>\n

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

So while all those things helped, there’s no getting around the fact that this is drudgery.\u00a0 I will admit to having Another Brick in the Wall Part 3<\/a> going through my head from about point 800 on (hence the title of this post).\u00a0 That said, it was important to get this right as so much depends on getting the retailer location correct.\u00a0 The next stages of this analysis hinge upon accurately determining if a retailer is within 500 m of a school or not.\u00a0 So if its position isn’t as accurate as we can make it, what’s the point?\u00a0 (Sorry, didn’t mean to do that.)<\/p>\n

Three main things covered in this post: first, GIS analysis is not always glitz and glory [Is it ever? – Ed.], second, definition queries can be useful ways of limiting what gets displayed in a layer, and third, setting the scale range for labels can be handy.<\/p>\n

While we’re talking about scale ranges, the same thing can be done for the display of layers.\u00a0 For instance, if you look at the Canterbury Maps site, different layers get displayed depending on the scale.\u00a0 As you zoom in, more and more layers get turned on and vice-versa.\u00a0 These layers have had their scale ranges set to only display above a certain scale.\u00a0 This can be set in the Properties > General tab:<\/p>\n

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

This is a good way of keeping your maps uncluttered at smaller scales.\u00a0 If you’d like to have a look at a map set up with scale ranges, open up EnvironmentalDatabases.mxd\u00a0in J:\\Courses\\ERST203.\u00a0 As you zoom in more layers will get turned on.\u00a0 Now if you don’t mind, I’ll get back to some Pink Floyd – I’m feeling a bit Comfortably Numb<\/a> after all those points.<\/p>\n

C<\/p>\n","protected":false},"excerpt":{"rendered":"

Quality assurance is crucial when creating new data, especially with geocoding.\u00a0 We cover some of the frustrations of this process and some useful tips (definition queries and label scale ranges) to make it a bit easier. I can safely say that over the past few days I have been almost everywhere in New Zealand: from […]<\/p>\n","protected":false},"author":3,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-2147","post","type-post","status-publish","format-standard","hentry","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/blogs.lincoln.ac.nz\/gis\/wp-json\/wp\/v2\/posts\/2147","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blogs.lincoln.ac.nz\/gis\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blogs.lincoln.ac.nz\/gis\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blogs.lincoln.ac.nz\/gis\/wp-json\/wp\/v2\/users\/3"}],"replies":[{"embeddable":true,"href":"https:\/\/blogs.lincoln.ac.nz\/gis\/wp-json\/wp\/v2\/comments?post=2147"}],"version-history":[{"count":1,"href":"https:\/\/blogs.lincoln.ac.nz\/gis\/wp-json\/wp\/v2\/posts\/2147\/revisions"}],"predecessor-version":[{"id":4117,"href":"https:\/\/blogs.lincoln.ac.nz\/gis\/wp-json\/wp\/v2\/posts\/2147\/revisions\/4117"}],"wp:attachment":[{"href":"https:\/\/blogs.lincoln.ac.nz\/gis\/wp-json\/wp\/v2\/media?parent=2147"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blogs.lincoln.ac.nz\/gis\/wp-json\/wp\/v2\/categories?post=2147"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blogs.lincoln.ac.nz\/gis\/wp-json\/wp\/v2\/tags?post=2147"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}