Geospatial on a shoestring - my experiences in Native Title
Poole, Cameron
Geospatial on a shoestring - my experiences in Native Title
 So first and foremost, I wish to acknowledge the custodians of this land, the Wurundjeru people of the Kuala Nation and their elders past and present. I acknowledge and respect their continuing culture and the contribution they make to the life of this city and this region. Secondly, I'm super excited to be here, kicking off this session. My name's Cameron Poole. Welcome to my talk, Geospatial on a Shoe String, my experience in native tidal. Now, alternative titles for this talk include My Data Sucks, Your Data Sucks, Everyone's Data Sucks, and Manifesto. Everything is broken and I don't have time to fix it because I've broken something else and machines need to start learning faster because I've got no idea. So before I begin, I should state everything here is my own view and not YMAX. I've got a lot of lawyers, so I hope they don't sue me. Lastly, just keeping with cultural tradition, just a quick warning. So a bit of background and context, YMAX stands for Yamachi Malba Aboriginal Corporation. It's an example of a native tidal representative body and these organizations appointed under the Native Tidal Act to assist Indigenous people in all aspects of their native tidal claims. Now, YMAX as an organization has got a number of unique considerations. They represent many claims and determinations within the state of Western Australia. During my time, they had approximately 100 staff over three locations with a staff mixture mostly made up of archaeologists, anthropologists, lawyers and administrative staff. They deal with a lot of culturally and legally sensitive information. They've got a limited budget, outsourced technological expertise, and prior to around 2012, they had minimal spatial or data standardization practices since their conception. Of course, no geospatial talk would be complete without a map. So here are the claims and determinations represented by YMAX. The Yamachi region is in the south around Sherilton and the Malba region up in the north kind of around Graf and Tom Price area. So this is my first time presenting, maybe my last time presenting. I'm not dying or anything. Just you know, if this goes bad, they'll move countries and go into hiding. I mean, I might still anyway, but you know, if this bombs. I've been a part of the phosphor G community for a few years now. It's given me a lot, most in terms of income, but a lot of fun and knowledge along the way. So I thought it was about time I've already gave something back. At the heart of this presentation is the story of the map men. It's a story of friendship, technical issues, data that makes me cry, cultural issues and mapping. It's a story of an organization going from almost no spatial infrastructure to having a functioning, efficient and effective spatial department on a budget. And we call the spatial department, the map men and the spelling is intentional, by the way. So in the beginning, there was a map father and he bring us the map men. Map man himself has over 25 years of GIS experience in many organizations, government agencies and departments. I started with almost none. Prior to map man, there was no spatial department at YMAC. He built it from the ground up. Quickly a bit about me, the map boy. I graduated with a Bachelor of Health Science in 2010. I immediately began working at the Department of Health in W.A. in the data linkage branch. And I started to learn to program there because I soon realized that one day I could maybe automate myself entirely out of a job and get paid to do so. So I went back to uni. I spent a few years working towards getting a masters when I was approached by map man, not on a dark street or anything, just, you know. And he offered to ask me to come work at YMAC. During my time at YMAC, there were other map men and map people, but this is where my story begins. So when I started at YMAC, I was given these central tenets of being a map man. And I included these because I guided a lot of the decisions we made in the spatial department during my time at YMAC. I also included these because they might be the only sage advice you'll get during this whole talk. So number one, spatial is not special. Two, it's not my GIS, it's RGIS. Three, never worry about making mistakes. Never worry about not learning from them. Admit to your mistakes quickly. They're then far easier to fix. Four, don't withhold your GIS expertise. Share it. It's of no benefit to you. Never assume what others know they may well know more than you think. Five, don't teach GIS to other people. Encourage them to learn. Six, good maps aren't made in a GIS. They come from telling the story they're required to very well. Seven, GIS expertise is only useful if it recognizes what it doesn't know. Resorting to blinding people with GIS science means you haven't understood the problem yourself. Nine, technology doesn't get you out of a hole. Ask no questions. Never just buy more technology. And ten, don't use the words GIS outside of these commandments. Information is description enough. I'm going to break that. Sorry. So we had one goal in the spatial department and that was to make information easy, accessible and accurate. I myself had one goal. That was just to automate myself out of a job. And I didn't automate everything, but I no longer have a job at YMAX. It's kind of a pass, right? In the beginning there was a lot of chaos disorder, a lot of Excel spreadsheets, GPX files, shape files and long wait times for maps. There was no real organizational standardization in terms of spatial infrastructure and the native title tribunal was handling the mapping jobs. So Matman starts working in September of 2012, finds the required core data sets, purchase software and map printers and starts mapping like crazy. Commencing a torrent of requests, everything from site maps, technological descriptions for core to maps and data for going out on surveys. Now Matman brought along order and some really neat software and now a lot of our architecture was open source, but we still relied on some proprietary software and occasionally some free proprietary software, which I know sounds like a bit of a misnomer, but for those not for profits out there, here's the thing, if you do good things in general people will want to help you do those good things. And in some cases that means free software. So I just wanted to acknowledge those companies that helped us out. Now Matman was swamped by requests, he was able to smooth talk management into hiring part time help and the first of the GA spatial specialist was Hyde. Now this person really knew what they were doing. They still do, but they're used to it as well. They set up some batch scripting of FME for automated downloads, built a tool in Google Earth and started working on some demo post-jist and GA server instances. However, one and a half people wasn't enough to fulfill all the requests, so they began training staff and using QGIS to produce their own maps. Now we'll go into a bit more detail about this, but it was a big step forward for the spatial department for easing stress. So then the GA spatial specialist left and the reign of Matboy begins. Now it's fair to say we had data everywhere and in every format. So what I wanted to do was centralize all our data in one place to make it searchable and easy to work with. So I combined the powers of Post-Jist and GA Django and built us a spatial web portal for all of our spatial needs. And now the portal housed our data, but it also allowed us to build things like web pages for requests, useful links, downloads and other useful information. So I carried on the work of automating our data downloads and other repetitive processes, including from batch grips to FME workbench and server and just a side note here, I could have written everything in Python, which was my initial inclination. However, not only is FME easy for programmers, it was also good for non-programmers. So where I could, I tried to look for solutions that would work without a developer to keep them going. Originally, we used a lot of instructional Word documents and PDFs and although easy to edit, finding information was tough. So I built us a spatial wiki using docu wiki. The wiki included step-by-step instructions for common procedures and other information relevant to the spatial team. Now there are a lot of good reasons for a wiki, but the main ones were to ensure the longevity of the system and to mitigate against team member loss. Now I did some other good things, highlight include making our GeoServer instance more operational, helping train more staff in the out of QGIS, helping set up a range of program collecting data using Fulcrum, things like invasive animal and track management, wildlife surveys, tracking bilby burrows, and I helped set up a return of cultural materials site. So YMAC had a lot of complex mapping requests which required good data, a solid understanding of cartographic principles and particularly when it came to presenting evidence to courts and lawyers. We also had a lot of simple mapping requests that just took a long time to fill use demands. So we realized we had the resources of experienced technical people, they just needed harnessing. Anyone can make maps if you make it easy enough. So what I really want to focus on now is how do you get non-spatial people to start using spatial software well. So I think you can teach anyone to make a map in less than an hour, but can they do it two days later, what about two weeks later? So how do we get ARCs and frozen lawyers to use QGIS infrequently and well? The answer of course is to make things as simple as possible. If you don't you'll lose people and then you'll be back to be mapping all by yourself. So the way we did this is to reduce cognitive load by having everything in one place. We used a plugin called YMAC Tools which is just a customized and modified version of DC tools and DC and now called D-POR, it's not acronyms, but a massive thanks to them for providing the source for it. I think it's just an example if you ask people for help, they'll provide it. So some of these features include a browser with just our core data sets and this point into our spatial drives and posters server, menu with useful links and menu items for loading certain actions onto layers, zoom to point tool allowing for different coordinate systems or to a locality in our core data sets and I think the real genius was a NAT composer which uses our built-in templates and makes it easy to customize and produce reasonably good cartographic maps. Now here's an example of a map made with a composer, it's not winning any awards, but it's good enough for a lot of the users. So we also did some other neat things with QGIS to make life easier, custom actions, always awesome, integrated YMAC tools of our posters server allowing us to use triggers, history, restrict access, custom views for groups, customize attribute forms for validation and easier input and a tool for loading imagery layers. Now I know none of this is revolutionary and a lot you can do with alternative plugins or standard QGIS free, however I think by simplifying things you can keep your users coming back and actually making maps. And even with all of this however it still took a immense amount of training and support. So you don't always need to make a map but you just might have a question that you want answering quickly. Like the rest of the world, YMAC could be divided into two groups, those who willingly learn QGIS, let's call this first group the archeologist and anthropologist and those who will if forced to let's call this second group lawyers. So for those who the QGIS training didn't stick we had YMAC Earth. In short there was just a set of KML files of all of our core data sets and this was created around 2013 during the time when Google Earth Pro still cost money and we got it free thanks to Matman and Google's Outreach program. So just remember to ask for help. Here's an example of it and you can see our core data sets, they're updated weekly, easily searchable and people are familiar with Google products so it requires less training and support. So I apologize if you thought I was going to deliver a prescriptive roadmap to running a space department on a budget. Hopefully you got some ideas of what we did. Now I'm going to tell you where everything fell down and maybe your solutions will be better than mine. So standardizing data takes a lot of time and effort to do it as soon as possible. The same goes for data validation. We did not do that. I'm doubtful the machine is going to take over for a while because automation in practice is easy. In reality it's kind of hard and especially when you're dependent upon external data there's a high chance that eventually things will break down. Now I love new software features as a developer. However updates do fix a lot of bugs but when you've got custom code like Wi-MAC tools they also introduce a lot of bugs. I know developers try to keep backwards compatibility but it's hard to fully comprehend how new changes will affect old code and this goes for FOS and proprietary software we use so just be careful. I love challenges but sometimes you can't fix everything. I certainly said yes too much just for the challenge. I think FOS can take up a fair amount of time resources because you are the support. You have to fix things and maybe sometimes as a time money trade-off often not considered about that. Spatial software generally speaking needs a fair amount of memory so does everything else now. Is it easier to just buy more RAMs and spend more time writing more efficient code? The biggest thing I learned is that money may be limited but so is your time. Work begets more work and can all of this be supported without a developer? I suspect a lot of what was built may fall by the wayside when things break sufficiently enough. So, information to generate change and support you is spatial on the shoestring. Here's what I think you need to do. You need whole wide organisation support. You need to make it as easy as possible. You need to invest a lot of resources and by this I mean time more than money and you need to support it. If you don't support it, you are back to making maps by yourself. You need to adapt to the skill sets of your users. If you need help, just ask. And finally and most importantly, you need someone to drive it. You need a champion. Which brings me to my motivation for giving this talk. I hope it's been a little enlightening. I give it a little reluctantly. Unfortunately, Matman is not here to give this talk so I'm giving it an instead. I'm sure I would have done a better job of it than me. But I wanted to give something back to the community. I also just wanted to express my gratitude for the community. All those from developing the software to those writing documentation to the teachers, to the users and the donors. But I really wanted to thank those champions pushing open source software in organisations. In top of this, I really wanted to honour Matman. He was the one who pushed it all at YMAC. He did a fantastic job and I'm very grateful for the opportunity I got to work with him and the passionate people at YMAC. Who might consider to be a second family. Now, Matman was a great colleague, a great friend, champion of FOSS and he was a great father. Matman is, was in fact, my father, Clive. Now, my father passed away one month shy of his 61st birthday and two months before we were first. Before we were both to attend our first FOSS 4G conference together in Seoul. And I'd like to think that he could have become a very involved member of the open source community, alas it was not meant to be. We lost an advocate and a champion. In his wake though, I believe there are people who can feel the void the great man left. So I wanted to give this talk to honour him and the spirit of openness and community. Unfortunately in life, we don't often get the chance to fully acknowledge other people's hard work. So I wanted to thank those champions out there pushing FOSS and working on it. And I'd like to acknowledge the organisers of this event and in particular John Bryant who was a very switched on GEO Special Specialist I mentioned earlier. He's my good friend. He's helped me a lot personally so big thanks John. Also I want to encourage others to give back to the community and advocate the open source way within their organisations. And lastly, I'd like to advocate for enjoying yourselves and each other whilst we're still here to do it. Anyway, thank you all for listening to me. I'm slightly over time but I'm going to forget a few seconds of questions to let Matt Man play me out. la Pokémon Lo と � like 2 opinion on the We'll do our time for two questions. Anybody want to ask a question? Easy. We have a question here. What beverage or culture are there any real perceived hassles of trying to get from one side into the other? Do you have a spatial opinion? Yeah. There are a few hassles. I mean, of course, you've got the cultural problems around sacred sites. So you can only really keep a boundary of where they are. You've got gender differences. So only men can see some sites. Yeah, they're the big two really, sacred sites and gender issues. And also, within YMAC, there was a lot of issues because you've got lawyers working on different claims that might be, well, in disagreement with each other. So you've got to separate a lot of stuff from the lawyers. One more question. Anybody? Oh, I have a question about. So there was the boundary data, the sacred site data. What are the data sets we bring together to help our community to attach it to the claim? So, well, it's mostly site data, but then also a lot of anthropological stories have to be transferred to maps, which is kind of hard. Yeah, I think that's the main one. That's pretty hard. Thanks. Anyway. Thanks, Damon. That's great. Cool. Thanks. No problem.
 So first and foremost, I wish to acknowledge the custodians of this land, the Wurundjeru  people of the Kuala Nation and their elders past and present.  I acknowledge and respect their continuing culture and the contribution they make to  the life of this city and this region.  Secondly, I'm super excited to be here, kicking off this session.  My name's Cameron Poole.  Welcome to my talk, Geospatial on a Shoe String, my experience in native tidal.  Now, alternative titles for this talk include My Data Sucks, Your Data Sucks, Everyone's  Data Sucks, and Manifesto.  Everything is broken and I don't have time to fix it because I've broken something else  and machines need to start learning faster because I've got no idea.  So before I begin, I should state everything here is my own view and not YMAX.  I've got a lot of lawyers, so I hope they don't sue me.  Lastly, just keeping with cultural tradition, just a quick warning.  So a bit of background and context, YMAX stands for Yamachi Malba Aboriginal Corporation.  It's an example of a native tidal representative body and these organizations appointed under  the Native Tidal Act to assist Indigenous people in all aspects of their native tidal  claims.  Now, YMAX as an organization has got a number of unique considerations.  They represent many claims and determinations within the state of Western Australia.  During my time, they had approximately 100 staff over three locations with a staff mixture  mostly made up of archaeologists, anthropologists, lawyers and administrative staff.  They deal with a lot of culturally and legally sensitive information.  They've got a limited budget, outsourced technological expertise, and prior to around 2012, they had  minimal spatial or data standardization practices since their conception.  Of course, no geospatial talk would be complete without a map.  So here are the claims and determinations represented by YMAX.  The Yamachi region is in the south around Sherilton and the Malba region up in the north  kind of around Graf and Tom Price area.  So this is my first time presenting, maybe my last time presenting.  I'm not dying or anything.  Just you know, if this goes bad, they'll move countries and go into hiding.  I mean, I might still anyway, but you know, if this bombs.  I've been a part of the phosphor G community for a few years now.  It's given me a lot, most in terms of income, but a lot of fun and knowledge along the way.  So I thought it was about time I've already gave something back.  At the heart of this presentation is the story of the map men.  It's a story of friendship, technical issues, data that makes me cry, cultural issues and  mapping.  It's a story of an organization going from almost no spatial infrastructure to having  a functioning, efficient and effective spatial department on a budget.  And we call the spatial department, the map men and the spelling is intentional, by the  way.  So in the beginning, there was a map father and he bring us the map men.  Map man himself has over 25 years of GIS experience in many organizations, government agencies  and departments.  I started with almost none.  Prior to map man, there was no spatial department at YMAC.  He built it from the ground up.  Quickly a bit about me, the map boy.  I graduated with a Bachelor of Health Science in 2010.  I immediately began working at the Department of Health in W.A. in the data linkage branch.  And I started to learn to program there because I soon realized that one day I could maybe  automate myself entirely out of a job and get paid to do so.  So I went back to uni.  I spent a few years working towards getting a masters when I was approached by map man,  not on a dark street or anything, just, you know.  And he offered to ask me to come work at YMAC.  During my time at YMAC, there were other map men and map people, but this is where my story  begins.  So when I started at YMAC, I was given these central tenets of being a map man.  And I included these because I guided a lot of the decisions we made in the spatial department  during my time at YMAC.  I also included these because they might be the only sage advice you'll get during this  whole talk.  So number one, spatial is not special.  Two, it's not my GIS, it's RGIS.  Three, never worry about making mistakes.  Never worry about not learning from them.  Admit to your mistakes quickly.  They're then far easier to fix.  Four, don't withhold your GIS expertise.  Share it.  It's of no benefit to you.  Never assume what others know they may well know more than you think.  Five, don't teach GIS to other people.  Encourage them to learn.  Six, good maps aren't made in a GIS.  They come from telling the story they're required to very well.  Seven, GIS expertise is only useful if it recognizes what it doesn't know.  Resorting to blinding people with GIS science means you haven't understood the problem yourself.  Nine, technology doesn't get you out of a hole.  Ask no questions.  Never just buy more technology.  And ten, don't use the words GIS outside of these commandments.  Information is description enough.  I'm going to break that.  Sorry.  So we had one goal in the spatial department and that was to make information easy, accessible  and accurate.  I myself had one goal.  That was just to automate myself out of a job.  And I didn't automate everything, but I no longer have a job at YMAX.  It's kind of a pass, right?  In the beginning there was a lot of chaos disorder, a lot of Excel spreadsheets, GPX  files, shape files and long wait times for maps.  There was no real organizational standardization in terms of spatial infrastructure and the  native title tribunal was handling the mapping jobs.  So Matman starts working in September of 2012, finds the required core data sets, purchase  software and map printers and starts mapping like crazy.  Commencing a torrent of requests, everything from site maps, technological descriptions  for core to maps and data for going out on surveys.  Now Matman brought along order and some really neat software and now a lot of our architecture  was open source, but we still relied on some proprietary software and occasionally some  free proprietary software, which I know sounds like a bit of a misnomer, but for those not  for profits out there, here's the thing, if you do good things in general people will  want to help you do those good things.  And in some cases that means free software.  So I just wanted to acknowledge those companies that helped us out.  Now Matman was swamped by requests, he was able to smooth talk management into hiring  part time help and the first of the GA spatial specialist was Hyde.  Now this person really knew what they were doing.  They still do, but they're used to it as well.  They set up some batch scripting of FME for automated downloads, built a tool in Google  Earth and started working on some demo post-jist and GA server instances.  However, one and a half people wasn't enough to fulfill all the requests, so they began  training staff and using QGIS to produce their own maps.  Now we'll go into a bit more detail about this, but it was a big step forward for the  spatial department for easing stress.  So then the GA spatial specialist left and the reign of Matboy begins.  Now it's fair to say we had data everywhere and in every format.  So what I wanted to do was centralize all our data in one place to make it searchable  and easy to work with.  So I combined the powers of Post-Jist and GA Django and built us a spatial web portal  for all of our spatial needs.  And now the portal housed our data, but it also allowed us to build things like web pages  for requests, useful links, downloads and other useful information.  So I carried on the work of automating our data downloads and other repetitive processes,  including from batch grips to FME workbench and server and just a side note here, I could  have written everything in Python, which was my initial inclination.  However, not only is FME easy for programmers, it was also good for non-programmers.  So where I could, I tried to look for solutions that would work without a developer to keep  them going.  Originally, we used a lot of instructional Word documents and PDFs and although easy  to edit, finding information was tough.  So I built us a spatial wiki using docu wiki.  The wiki included step-by-step instructions for common procedures and other information  relevant to the spatial team.  Now there are a lot of good reasons for a wiki, but the main ones were to ensure the  longevity of the system and to mitigate against team member loss.  Now I did some other good things, highlight include making our GeoServer instance more  operational, helping train more staff in the out of QGIS, helping set up a range of program  collecting data using Fulcrum, things like invasive animal and track management, wildlife  surveys, tracking bilby burrows, and I helped set up a return of cultural materials site.  So YMAC had a lot of complex mapping requests which required good data, a solid understanding  of cartographic principles and particularly when it came to presenting evidence to courts  and lawyers.  We also had a lot of simple mapping requests that just took a long time to fill use demands.  So we realized we had the resources of experienced technical people, they just needed harnessing.  Anyone can make maps if you make it easy enough.  So what I really want to focus on now is how do you get non-spatial people to start using  spatial software well.  So I think you can teach anyone to make a map in less than an hour, but can they do it  two days later, what about two weeks later?  So how do we get ARCs and frozen lawyers to use QGIS infrequently and well?  The answer of course is to make things as simple as possible.  If you don't you'll lose people and then you'll be back to be mapping all by yourself.  So the way we did this is to reduce cognitive load by having everything in one place.  We used a plugin called YMAC Tools which is just a customized and modified version of  DC tools and DC and now called D-POR, it's not acronyms, but a massive thanks to them  for providing the source for it.  I think it's just an example if you ask people for help, they'll provide it.  So some of these features include a browser with just our core data sets and this point  into our spatial drives and posters server, menu with useful links and menu items for  loading certain actions onto layers, zoom to point tool allowing for different coordinate  systems or to a locality in our core data sets and I think the real genius was a NAT  composer which uses our built-in templates and makes it easy to customize and produce  reasonably good cartographic maps.  Now here's an example of a map made with a composer, it's not winning any awards, but  it's good enough for a lot of the users.  So we also did some other neat things with QGIS to make life easier, custom actions,  always awesome, integrated YMAC tools of our posters server allowing us to use triggers,  history, restrict access, custom views for groups, customize attribute forms for validation  and easier input and a tool for loading imagery layers.  Now I know none of this is revolutionary and a lot you can do with alternative plugins  or standard QGIS free, however I think by simplifying things you can keep your users  coming back and actually making maps.  And even with all of this however it still took a immense amount of training and support.  So you don't always need to make a map but you just might have a question that you want  answering quickly.  Like the rest of the world, YMAC could be divided into two groups, those who willingly  learn QGIS, let's call this first group the archeologist and anthropologist and those  who will if forced to let's call this second group lawyers.  So for those who the QGIS training didn't stick we had YMAC Earth.  In short there was just a set of KML files of all of our core data sets and this was  created around 2013 during the time when Google Earth Pro still cost money and we got it free  thanks to Matman and Google's Outreach program.  So just remember to ask for help.  Here's an example of it and you can see our core data sets, they're updated weekly, easily  searchable and people are familiar with Google products so it requires less training and  support.  So I apologize if you thought I was going to deliver a prescriptive roadmap to running  a space department on a budget.  Hopefully you got some ideas of what we did.  Now I'm going to tell you where everything fell down and maybe your solutions will be  better than mine.  So standardizing data takes a lot of time and effort to do it as soon as possible.  The same goes for data validation.  We did not do that.  I'm doubtful the machine is going to take over for a while because automation in practice  is easy.  In reality it's kind of hard and especially when you're dependent upon external data there's  a high chance that eventually things will break down.  Now I love new software features as a developer.  However updates do fix a lot of bugs but when you've got custom code like Wi-MAC tools  they also introduce a lot of bugs.  I know developers try to keep backwards compatibility but it's hard to fully comprehend how new  changes will affect old code and this goes for FOS and proprietary software we use so  just be careful.  I love challenges but sometimes you can't fix everything.  I certainly said yes too much just for the challenge.  I think FOS can take up a fair amount of time resources because you are the support.  You have to fix things and maybe sometimes as a time money trade-off often not considered  about that.  Spatial software generally speaking needs a fair amount of memory so does everything  else now.  Is it easier to just buy more RAMs and spend more time writing more efficient code?  The biggest thing I learned is that money may be limited but so is your time.  Work begets more work and can all of this be supported without a developer?  I suspect a lot of what was built may fall by the wayside when things break sufficiently  enough.  So, information to generate change and support you is spatial on the shoestring.  Here's what I think you need to do.  You need whole wide organisation support.  You need to make it as easy as possible.  You need to invest a lot of resources and by this I mean time more than money and you  need to support it.  If you don't support it, you are back to making maps by yourself.  You need to adapt to the skill sets of your users.  If you need help, just ask.  And finally and most importantly, you need someone to drive it.  You need a champion.  Which brings me to my motivation for giving this talk.  I hope it's been a little enlightening.  I give it a little reluctantly.  Unfortunately, Matman is not here to give this talk so I'm giving it an instead.  I'm sure I would have done a better job of it than me.  But I wanted to give something back to the community.  I also just wanted to express my gratitude for the community.  All those from developing the software to those writing documentation to the teachers,  to the users and the donors.  But I really wanted to thank those champions pushing open source software in organisations.  In top of this, I really wanted to honour Matman.  He was the one who pushed it all at YMAC.  He did a fantastic job and I'm very grateful for the opportunity I got to work with him  and the passionate people at YMAC.  Who might consider to be a second family.  Now, Matman was a great colleague, a great friend, champion of FOSS and he was a great  father.  Matman is, was in fact, my father, Clive.  Now, my father passed away one month shy of his 61st birthday and two months before  we were first.  Before we were both to attend our first FOSS 4G conference together in Seoul.  And I'd like to think that he could have become a very involved member of the open source  community, alas it was not meant to be.  We lost an advocate and a champion.  In his wake though, I believe there are people who can feel the void the great man left.  So I wanted to give this talk to honour him and the spirit of openness and community.  Unfortunately in life, we don't often get the chance to fully acknowledge other people's  hard work.  So I wanted to thank those champions out there pushing FOSS and working on it.  And I'd like to acknowledge the organisers of this event and in particular John Bryant  who was a very switched on GEO Special Specialist I mentioned earlier.  He's my good friend.  He's helped me a lot personally so big thanks John.  Also I want to encourage others to give back to the community and advocate the open source  way within their organisations.  And lastly, I'd like to advocate for enjoying yourselves and each other whilst we're still  here to do it.  Anyway, thank you all for listening to me.  I'm slightly over time but I'm going to forget a few seconds of questions to let Matt Man  play me out.  la Pokémon Lo と � like  2  opinion on the  We'll do our time for two questions.  Anybody want to ask a question?  Easy.  We have a question here.  What beverage or culture are there any real perceived hassles  of trying to get from one side into the other?  Do you have a spatial opinion?  Yeah.  There are a few hassles.  I mean, of course, you've got the cultural problems  around sacred sites.  So you can only really keep a boundary of where they are.  You've got gender differences.  So only men can see some sites.  Yeah, they're the big two really,  sacred sites and gender issues.  And also, within YMAC, there was a lot of issues  because you've got lawyers working on different claims  that might be, well, in disagreement with each other.  So you've got to separate a lot of stuff from the lawyers.  One more question.  Anybody?  Oh, I have a question about.  So there was the boundary data, the sacred site data.  What are the data sets we bring together  to help our community to attach it to the claim?  So, well, it's mostly site data,  but then also a lot of anthropological stories  have to be transferred to maps, which is kind of hard.  Yeah, I think that's the main one.  That's pretty hard.  Thanks.  Anyway.  Thanks, Damon.  That's great.  Cool.  Thanks.  No problem.
Cameron_Poole__Geospatial_on_a_shoestring_-_my_experiences_in_Native_Title_T_tz-zFqKRo_0_59.png Cameron_Poole__Geospatial_on_a_shoestring_-_my_experiences_in_Native_Title_T_tz-zFqKRo_60_1463.png Cameron_Poole__Geospatial_on_a_shoestring_-_my_experiences_in_Native_Title_T_tz-zFqKRo_1464_1511.png Cameron_Poole__Geospatial_on_a_shoestring_-_my_experiences_in_Native_Title_T_tz-zFqKRo_1512_2747.png Cameron_Poole__Geospatial_on_a_shoestring_-_my_experiences_in_Native_Title_T_tz-zFqKRo_2748_4031.png Cameron_Poole__Geospatial_on_a_shoestring_-_my_experiences_in_Native_Title_T_tz-zFqKRo_4032_4367.png Cameron_Poole__Geospatial_on_a_shoestring_-_my_experiences_in_Native_Title_T_tz-zFqKRo_4368_7415.png Cameron_Poole__Geospatial_on_a_shoestring_-_my_experiences_in_Native_Title_T_tz-zFqKRo_7416_12599.png Cameron_Poole__Geospatial_on_a_shoestring_-_my_experiences_in_Native_Title_T_tz-zFqKRo_12600_12683.png Cameron_Poole__Geospatial_on_a_shoestring_-_my_experiences_in_Native_Title_T_tz-zFqKRo_12684_14627.png Cameron_Poole__Geospatial_on_a_shoestring_-_my_experiences_in_Native_Title_T_tz-zFqKRo_14628_17267.png Cameron_Poole__Geospatial_on_a_shoestring_-_my_experiences_in_Native_Title_T_tz-zFqKRo_17268_19751.png Cameron_Poole__Geospatial_on_a_shoestring_-_my_experiences_in_Native_Title_T_tz-zFqKRo_19752_20447.png Cameron_Poole__Geospatial_on_a_shoestring_-_my_experiences_in_Native_Title_T_tz-zFqKRo_20448_20507.png Cameron_Poole__Geospatial_on_a_shoestring_-_my_experiences_in_Native_Title_T_tz-zFqKRo_20508_20951.png Cameron_Poole__Geospatial_on_a_shoestring_-_my_experiences_in_Native_Title_T_tz-zFqKRo_20952_20999.png Cameron_Poole__Geospatial_on_a_shoestring_-_my_experiences_in_Native_Title_T_tz-zFqKRo_21000_21119.png Cameron_Poole__Geospatial_on_a_shoestring_-_my_experiences_in_Native_Title_T_tz-zFqKRo_21120_23411.png Cameron_Poole__Geospatial_on_a_shoestring_-_my_experiences_in_Native_Title_T_tz-zFqKRo_23412_23747.png Cameron_Poole__Geospatial_on_a_shoestring_-_my_experiences_in_Native_Title_T_tz-zFqKRo_23748_24023.png Cameron_Poole__Geospatial_on_a_shoestring_-_my_experiences_in_Native_Title_T_tz-zFqKRo_24024_24383.png Cameron_Poole__Geospatial_on_a_shoestring_-_my_experiences_in_Native_Title_T_tz-zFqKRo_24384_24455.png Cameron_Poole__Geospatial_on_a_shoestring_-_my_experiences_in_Native_Title_T_tz-zFqKRo_24456_24539.png Cameron_Poole__Geospatial_on_a_shoestring_-_my_experiences_in_Native_Title_T_tz-zFqKRo_24540_27277.png
So first and foremost, I wish to acknowledge the custodians of this land, the Wurundjeru people of the Kuala Nation and their elders past and present. I acknowledge and respect their continuing culture and the contribution they make to the life of this city and this region. Secondly, I'm super excited to be here, kicking off this session. My name's Cameron Poole. Welcome to my talk, Geospatial on a Shoe String, my experience in native tidal. Now, alternative titles for this talk include My Data Sucks, Your Data Sucks, Everyone's Data Sucks, and Manifesto. Everything is broken and I don't have time to fix it because I've broken something else and machines need to start learning faster because I've got no idea. So before I begin, I should state everything here is my own view and not YMAX. I've got a lot of lawyers, so I hope they don't sue me. Lastly, just keeping with cultural tradition, just a quick warning. So a bit of background and context, YMAX stands for Yamachi Malba Aboriginal Corporation. It's an example of a native tidal representative body and these organizations appointed under the Native Tidal Act to assist Indigenous people in all aspects of their native tidal claims. Now, YMAX as an organization has got a number of unique considerations. They represent many claims and determinations within the state of Western Australia. During my time, they had approximately 100 staff over three locations with a staff mixture mostly made up of archaeologists, anthropologists, lawyers and administrative staff. They deal with a lot of culturally and legally sensitive information. They've got a limited budget, outsourced technological expertise, and prior to around 2012, they had minimal spatial or data standardization practices since their conception. Of course, no geospatial talk would be complete without a map. So here are the claims and determinations represented by YMAX. The Yamachi region is in the south around Sherilton and the Malba region up in the north kind of around Graf and Tom Price area. So this is my first time presenting, maybe my last time presenting. I'm not dying or anything. Just you know, if this goes bad, they'll move countries and go into hiding. I mean, I might still anyway, but you know, if this bombs. I've been a part of the phosphor G community for a few years now. It's given me a lot, most in terms of income, but a lot of fun and knowledge along the way. So I thought it was about time I've already gave something back. At the heart of this presentation is the story of the map men. It's a story of friendship, technical issues, data that makes me cry, cultural issues and mapping. It's a story of an organization going from almost no spatial infrastructure to having a functioning, efficient and effective spatial department on a budget. And we call the spatial department, the map men and the spelling is intentional, by the way. So in the beginning, there was a map father and he bring us the map men. Map man himself has over 25 years of GIS experience in many organizations, government agencies and departments. I started with almost none. Prior to map man, there was no spatial department at YMAC. He built it from the ground up. Quickly a bit about me, the map boy. I graduated with a Bachelor of Health Science in 2010. I immediately began working at the Department of Health in W.A. in the data linkage branch. And I started to learn to program there because I soon realized that one day I could maybe automate myself entirely out of a job and get paid to do so. So I went back to uni. I spent a few years working towards getting a masters when I was approached by map man, not on a dark street or anything, just, you know. And he offered to ask me to come work at YMAC. During my time at YMAC, there were other map men and map people, but this is where my story begins. So when I started at YMAC, I was given these central tenets of being a map man. And I included these because I guided a lot of the decisions we made in the spatial department during my time at YMAC. I also included these because they might be the only sage advice you'll get during this whole talk. So number one, spatial is not special. Two, it's not my GIS, it's RGIS. Three, never worry about making mistakes. Never worry about not learning from them. Admit to your mistakes quickly. They're then far easier to fix. Four, don't withhold your GIS expertise. Share it. It's of no benefit to you. Never assume what others know they may well know more than you think. Five, don't teach GIS to other people. Encourage them to learn. Six, good maps aren't made in a GIS. They come from telling the story they're required to very well. Seven, GIS expertise is only useful if it recognizes what it doesn't know. Resorting to blinding people with GIS science means you haven't understood the problem yourself. Nine, technology doesn't get you out of a hole. Ask no questions. Never just buy more technology. And ten, don't use the words GIS outside of these commandments. Information is description enough. I'm going to break that. Sorry. So we had one goal in the spatial department and that was to make information easy, accessible and accurate. I myself had one goal. That was just to automate myself out of a job. And I didn't automate everything, but I no longer have a job at YMAX. It's kind of a pass, right? In the beginning there was a lot of chaos disorder, a lot of Excel spreadsheets, GPX files, shape files and long wait times for maps. There was no real organizational standardization in terms of spatial infrastructure and the native title tribunal was handling the mapping jobs. So Matman starts working in September of 2012, finds the required core data sets, purchase software and map printers and starts mapping like crazy. Commencing a torrent of requests, everything from site maps, technological descriptions for core to maps and data for going out on surveys. Now Matman brought along order and some really neat software and now a lot of our architecture was open source, but we still relied on some proprietary software and occasionally some free proprietary software, which I know sounds like a bit of a misnomer, but for those not for profits out there, here's the thing, if you do good things in general people will want to help you do those good things. And in some cases that means free software. So I just wanted to acknowledge those companies that helped us out. Now Matman was swamped by requests, he was able to smooth talk management into hiring part time help and the first of the GA spatial specialist was Hyde. Now this person really knew what they were doing. They still do, but they're used to it as well. They set up some batch scripting of FME for automated downloads, built a tool in Google Earth and started working on some demo post-jist and GA server instances. However, one and a half people wasn't enough to fulfill all the requests, so they began training staff and using QGIS to produce their own maps. Now we'll go into a bit more detail about this, but it was a big step forward for the spatial department for easing stress. So then the GA spatial specialist left and the reign of Matboy begins. Now it's fair to say we had data everywhere and in every format. So what I wanted to do was centralize all our data in one place to make it searchable and easy to work with. So I combined the powers of Post-Jist and GA Django and built us a spatial web portal for all of our spatial needs. And now the portal housed our data, but it also allowed us to build things like web pages for requests, useful links, downloads and other useful information. So I carried on the work of automating our data downloads and other repetitive processes, including from batch grips to FME workbench and server and just a side note here, I could have written everything in Python, which was my initial inclination. However, not only is FME easy for programmers, it was also good for non-programmers. So where I could, I tried to look for solutions that would work without a developer to keep them going. Originally, we used a lot of instructional Word documents and PDFs and although easy to edit, finding information was tough. So I built us a spatial wiki using docu wiki. The wiki included step-by-step instructions for common procedures and other information relevant to the spatial team. Now there are a lot of good reasons for a wiki, but the main ones were to ensure the longevity of the system and to mitigate against team member loss. Now I did some other good things, highlight include making our GeoServer instance more operational, helping train more staff in the out of QGIS, helping set up a range of program collecting data using Fulcrum, things like invasive animal and track management, wildlife surveys, tracking bilby burrows, and I helped set up a return of cultural materials site. So YMAC had a lot of complex mapping requests which required good data, a solid understanding of cartographic principles and particularly when it came to presenting evidence to courts and lawyers. We also had a lot of simple mapping requests that just took a long time to fill use demands. So we realized we had the resources of experienced technical people, they just needed harnessing. Anyone can make maps if you make it easy enough. So what I really want to focus on now is how do you get non-spatial people to start using spatial software well. So I think you can teach anyone to make a map in less than an hour, but can they do it two days later, what about two weeks later? So how do we get ARCs and frozen lawyers to use QGIS infrequently and well? The answer of course is to make things as simple as possible. If you don't you'll lose people and then you'll be back to be mapping all by yourself. So the way we did this is to reduce cognitive load by having everything in one place. We used a plugin called YMAC Tools which is just a customized and modified version of DC tools and DC and now called D-POR, it's not acronyms, but a massive thanks to them for providing the source for it. I think it's just an example if you ask people for help, they'll provide it. So some of these features include a browser with just our core data sets and this point into our spatial drives and posters server, menu with useful links and menu items for loading certain actions onto layers, zoom to point tool allowing for different coordinate systems or to a locality in our core data sets and I think the real genius was a NAT composer which uses our built-in templates and makes it easy to customize and produce reasonably good cartographic maps. Now here's an example of a map made with a composer, it's not winning any awards, but it's good enough for a lot of the users. So we also did some other neat things with QGIS to make life easier, custom actions, always awesome, integrated YMAC tools of our posters server allowing us to use triggers, history, restrict access, custom views for groups, customize attribute forms for validation and easier input and a tool for loading imagery layers. Now I know none of this is revolutionary and a lot you can do with alternative plugins or standard QGIS free, however I think by simplifying things you can keep your users coming back and actually making maps. And even with all of this however it still took a immense amount of training and support. So you don't always need to make a map but you just might have a question that you want answering quickly. Like the rest of the world, YMAC could be divided into two groups, those who willingly learn QGIS, let's call this first group the archeologist and anthropologist and those who will if forced to let's call this second group lawyers. So for those who the QGIS training didn't stick we had YMAC Earth. In short there was just a set of KML files of all of our core data sets and this was created around 2013 during the time when Google Earth Pro still cost money and we got it free thanks to Matman and Google's Outreach program. So just remember to ask for help. Here's an example of it and you can see our core data sets, they're updated weekly, easily searchable and people are familiar with Google products so it requires less training and support. So I apologize if you thought I was going to deliver a prescriptive roadmap to running a space department on a budget. Hopefully you got some ideas of what we did. Now I'm going to tell you where everything fell down and maybe your solutions will be better than mine. So standardizing data takes a lot of time and effort to do it as soon as possible. The same goes for data validation. We did not do that. I'm doubtful the machine is going to take over for a while because automation in practice is easy. In reality it's kind of hard and especially when you're dependent upon external data there's a high chance that eventually things will break down. Now I love new software features as a developer. However updates do fix a lot of bugs but when you've got custom code like Wi-MAC tools they also introduce a lot of bugs. I know developers try to keep backwards compatibility but it's hard to fully comprehend how new changes will affect old code and this goes for FOS and proprietary software we use so just be careful. I love challenges but sometimes you can't fix everything. I certainly said yes too much just for the challenge. I think FOS can take up a fair amount of time resources because you are the support. You have to fix things and maybe sometimes as a time money trade-off often not considered about that. Spatial software generally speaking needs a fair amount of memory so does everything else now. Is it easier to just buy more RAMs and spend more time writing more efficient code? The biggest thing I learned is that money may be limited but so is your time. Work begets more work and can all of this be supported without a developer? I suspect a lot of what was built may fall by the wayside when things break sufficiently enough. So, information to generate change and support you is spatial on the shoestring. Here's what I think you need to do. You need whole wide organisation support. You need to make it as easy as possible. You need to invest a lot of resources and by this I mean time more than money and you need to support it. If you don't support it, you are back to making maps by yourself. You need to adapt to the skill sets of your users. If you need help, just ask. And finally and most importantly, you need someone to drive it. You need a champion. Which brings me to my motivation for giving this talk. I hope it's been a little enlightening. I give it a little reluctantly. Unfortunately, Matman is not here to give this talk so I'm giving it an instead. I'm sure I would have done a better job of it than me. But I wanted to give something back to the community. I also just wanted to express my gratitude for the community. All those from developing the software to those writing documentation to the teachers, to the users and the donors. But I really wanted to thank those champions pushing open source software in organisations. In top of this, I really wanted to honour Matman. He was the one who pushed it all at YMAC. He did a fantastic job and I'm very grateful for the opportunity I got to work with him and the passionate people at YMAC. Who might consider to be a second family. Now, Matman was a great colleague, a great friend, champion of FOSS and he was a great father. Matman is, was in fact, my father, Clive. Now, my father passed away one month shy of his 61st birthday and two months before we were first. Before we were both to attend our first FOSS 4G conference together in Seoul. And I'd like to think that he could have become a very involved member of the open source community, alas it was not meant to be. We lost an advocate and a champion. In his wake though, I believe there are people who can feel the void the great man left. So I wanted to give this talk to honour him and the spirit of openness and community. Unfortunately in life, we don't often get the chance to fully acknowledge other people's hard work. So I wanted to thank those champions out there pushing FOSS and working on it. And I'd like to acknowledge the organisers of this event and in particular John Bryant who was a very switched on GEO Special Specialist I mentioned earlier. He's my good friend. He's helped me a lot personally so big thanks John. Also I want to encourage others to give back to the community and advocate the open source way within their organisations. And lastly, I'd like to advocate for enjoying yourselves and each other whilst we're still here to do it. Anyway, thank you all for listening to me. I'm slightly over time but I'm going to forget a few seconds of questions to let Matt Man play me out. la Pokémon Lo と � like 2 opinion on the We'll do our time for two questions. Anybody want to ask a question? Easy. We have a question here. What beverage or culture are there any real perceived hassles of trying to get from one side into the other? Do you have a spatial opinion? Yeah. There are a few hassles. I mean, of course, you've got the cultural problems around sacred sites. So you can only really keep a boundary of where they are. You've got gender differences. So only men can see some sites. Yeah, they're the big two really, sacred sites and gender issues. And also, within YMAC, there was a lot of issues because you've got lawyers working on different claims that might be, well, in disagreement with each other. So you've got to separate a lot of stuff from the lawyers. One more question. Anybody? Oh, I have a question about. So there was the boundary data, the sacred site data. What are the data sets we bring together to help our community to attach it to the claim? So, well, it's mostly site data, but then also a lot of anthropological stories have to be transferred to maps, which is kind of hard. Yeah, I think that's the main one. That's pretty hard. Thanks. Anyway. Thanks, Damon. That's great. Cool. Thanks. No problem.
Welcome to my talk, Geospatial on a Shoe String,