Week 11: New data collection method, geolocation API

After completing the PDF parsing version of the project, I realized that this process can be simplified by parsing data from the KML files that are generated after each recording session. I put in a lot of hard work for the initial approach but we now have a better method of execution, which shouldn't take long too implement. This will also reduce the requirements from the end user when submitting their data.

Within KML files lies entries for each "hit" when the echo meter detects a bat call in the app. It includes everything needed like name of species, coordinates of each hit, time stamps, and more. With this information available, the process will now skip using a PDF entirely, and the user will only be required to submit audio files with the supplied KML file. That's it, no filling out forms or anything, just bring the generated files and you are set... Simple! 

This change has led me to working with a reverse geolocation API, and I believe I have settled on one that will fit our needs without costing anything. Reverse geolocation is the process of gathering location data from a set of coordinates. I have only recently started working with JSON and now have much respect for how easy it makes the process of collecting data from online sources for use in any application. In this case, the user's average coordinates will be referenced and relevant geolocation data will be returned such as address, neighborhood, city, state, etc. 

Example of a pin drop and the returned results from the API. In place of a pin drop would be coordinates from the user's KML file.

The plan is to hopefully prime this for scalability on the national or even global level. Imagine a bat database that serves the entire planet! Pretty exciting stuff. Can't wait to see how far this thing can go.

Week 10: Front-end to back-end translation

As I have been getting reacquainted with HTML and JavaScript, I have had to pass information regarding file uploads to the PHP script that works with the database. Progress has been made but I have learned some ugly things about the nature of interacting with PHP along the way. Multi-file uploads are sent via POST as a bizarre 3-dimensional array with file information split into string-based indices. The last index is a number associated with the index of the file you are trying to access. It took me a while to realize that and finally figured it out after using a var_dump. PHP is a great language but it can be a bit wonky sometimes. The good news is that I have files uploading and posting from front-end to back-end, although accessing the file information I need is still underway. Hoping to have it done by next week, as we are close to the final steps for this project.

Week 9: Uploader and exception handling

This week I dusted off my JavaScript knowledge to implement a new uploader. It has been years since I last touched the language, and I appreciated taking a look at it again now that I have more experience programming. I am still trying to remember how to appropriately style pages but it will come in time! Since users will be required to submit both a pdf form along with their data, I felt it was important to keep things simple for the user and make a drag and drop uploader that does the sorting and checking for you instead of having separate upload pages or entry boxes. The script will now sort through the files and manipulate them as needed. On top of all this, I have started the process of exception handling for all possible outcomes when using the uploader. This process can be challenging, but it feels very rewarding to know I am identifying all possible issues that may occur and supplying a procedure to deal with them appropriately.