FOSSLC is a non-profit organization that specializes in technology and know-how to record conferences with excellent quality. Click on the icons below to view great videos from communities we are actively involved with:

 

UCOSP Weekend!

10 Oct in Blog, Build, Database, Education, gcc, Programming, UCOSP Fall 2010, Ingres, UCOSP, Intern, Databases, Programming
Ingres

So, this weekend I flew over to Toronto for the Undergraduate Capstone Open Source Project, which is basically a class where students from all over the country get together to work on various different open source projects! I wasn't sure what to expect - but the weekend was awesome! We got together with our groups, myself being part of the group working on Ingres.  The students on this program were from all over - SFU, UBC, UoW, UoM, and many other various places across the country, which is great because its always fun to meet new people from across the world!

Now, before I talk about what I'm going to work on, I'd like to briefly describe what Ingres is all about. Ingres is an open source database founded over years back, and is still one of the most popular commercially used databases across the world. One of the big features that has started to come into play for open source databases is geospatial technology.  Basically, most databases have the typical datatypes; int, varchar, etc. But the geospatial support in Ingres actually allows you to input geo data into the database, such as points, shapes, etc. 

Different members of the class get to work on different aspects of the database. Some are working on documentation, some working on testing; but myself and two others are working on some actual code. Our main goal by the end of the course is to add an additional functions to the database, output as KML (Googles XML format for mapping data in Google Maps and Google Earth), GML (a standardized XML format defined by a Geo Open Source group), and GeoJSON. I am specific responsible for making asKML work properly, while the other two developers are in charge of the other two functions. So, that is our main goal, but what is the plan of attack for such a venture? There are many strategies that come into play here:

1. Learn how to create custom SQL functions, and initially make asKML output "Hello KML" each time you use it, just so I know that I have created an SQL function correctly. I will be doing this with guidence from the following article in the documentation:

http://community.ingres.com/wiki/Implementing_New_SQL_Function

2. We will be using pieces of the open source project OGR to get the functionality to take text and binary and translate it to KML, GML, and GeoJSON. The first goal here is to actually get the functionality working using the API. I have found some sample code on using their API for doing exactly that here:

http://gdal.osgeo.org/ogr/ogr_apitut.html

3. Once we have the functionality of the OGR library working, we would like to strip it down and do our best to create an "OGR-lite", as Ingres doesn't necessarily need all of the functionality that OGR provides.

4. Put all of these together! That means taking the library, integrating with the stubs SQL functions, and viola! We will have our completed project.

My own bonus: I would also like to have Ingres with Geospatial compiled for Mac, and release a binary for it on the webpage. I haven't been able to get it compiled on Mac yet, but if I have some extra time I know I will do my best to!

I will be blogging weekly about my progress, so stay tuned on my struggles and successes!