The Masters Thesis is no more. Now there will only be a Master’s Project, which requires only a 25 page writeup instead of a 50 page one. I’m also working with a different adviser. Currently I’m somewhere on page 11 with the writeup and I’m not sure I have enough material to fill 25 pages. If I come up short it’s likely that I’ll add a section on loading the map data to a database for retrieval, or a section on using the full history of the traveled path in order to find the current road location more accurately (instead of the current method of matching to one of the two nearest roads based on angle).
This previous week I worked on loading road data to a database. Since there may be some question, this relates to my thesis in the following ways… Currently the road data is loaded from a CSV file and all of it is loaded at once (i.e. a small part of my local area). So if someone drives out of that area then there is simply no data. Using a database will allow me to dynamically load the road data based on a general location and all of the roads in the US can be stored (offline) and retrieved when needed.
Additionally this will be useful if my next thesis adviser wants me to create something that gives directions from one address to another. Also this will be useful for GeoCoding if that ever comes up.
So I’ve downloaded all of the “edge” files from the Tiger “edge” files from the US Census Bureau and wrote a program to process each one, one by one. Additionally I’ve installed MySQL. This week I may work on creating the appropriate users, tables for loading the data, and actually loading the data (if I get that far).
Match GPS Data to Road Data
Last week I tried choosing the closest road segment instead of using the angle as the most important attribute. This gives significantly better results. However, the results still aren’t perfect… of course. The found road location jumps back and forth from one end of the road segment to the other. I’m fairly burnt out on trying to find the correct road location, so it’s time for a reevaluation again.
As I currently have no direction (aka no Thesis adviser at the moment) I’ll have to make up my own possible next steps.
- Get the road location to actually work.
- probably involves assuring movement on a road segment matches movement from the GPS, while still taking into account other things like distance to the segment, etc.
- once this is done there is an issue with the perspective transformation that causes the road lines to disappear in some cases. I have no idea how to fix this.
- use color information (this would theoretically work in the same way as edge detection currently works, only edges are defined by significant changes in color).
- the academic papers I’ve read say this does not work very well.
- shadows change colors so the first bit of research would be figuring out if colors can be “normalized” so that green areas in sunny areas can be seen as the same green as in shadowy areas.
- use curve fitting to fit two curved lines to the image.
- apparently this works well but it can’t handle intersections which is why I dislike the idea.
- requires research on how it works, since I don’t know.
- try to add to the edge detection algorithm.
- if it’s added to then it won’t be strictly edge detection anymore. I’m not sure what else to add to it.
- look through the academic papers again for other attributes for recognizing road versus non-road.
- the one about recognizing country roads probably has some ideas.
- the various techniques should probably be cataloged anyway since they may be useful when I actually have to write the paper.
Although I previously said that matching the current angle of travel to the a nearby road with a similar angle of travel in order to match the current location to road worked just fine, that’s actually incorrect. What happens when the vehicle turns a corner is that the angle of travel does not match either of the roads it’s currently on. For example, if approaching an intersection which looks like a “T” and runs North/South and East/West, then while turning the vehicle is traveling somewhere between North/South and East/West. So the angle of travel doesn’t match either of the possible roads to which one would hope to match the location.
Match GPS Location to Road Data (Attempt 2)
Perhaps one thing that went horribly wrong with the previous attempt was putting more weight (importance) on the current angle of travel instead of the distance to a road segment. Assuming the GPS data isn’t off by too much, then the distance to the nearby road segments should be the most important. i.e. initially there should be a choice between 3 or less road segments based on distance.
Ideally, a path of travel would be saved and matched to nearby road segments, so that if the vehicle travels North then turns West, we could match to road segments which travel North and then West. Unfortunately I don’t have any ideas on how to implement this. It seems difficult because the GPS data gives you a lot more points to work with than the map data, to the point where the GPS data seems continuous compared to the discrete map data.
So next I will snap the GPS’ location to the nearest road segment and test the results. From there I will try to come up with a way to solve issue mentioned in an earlier post where the “snapped-to” road’s angle of travel does not match the current angle of travel at all. Currently I have two ideas: 1) Don’t allow the road to change until the angle more closely matches the new road and 2) detect when near an intersection and (similar to #1) allow the road to change when the angle of movement matches the new road more than the current road. For 1 and 2, if the road looks like a “T” then 45 degrees would be the threshold for changing the road that’s currently “snapped-to.”
Two Weeks Ago
Two weeks ago I worked out various bugs in the methods which remove non-visible lines and do rotations and transformations. The fact that using a “Graphics2D” instance applies things later instead of immediately and the fact that PerspectiveTransform’s can’t be done using a Graphics2D instance caused me to have to rewrite much of the code so that all of the rotations, transformations, etc. could be applied in the correct order.
Last week I augmented the simulation to not only include a GPS location with map data, but to also include the image captured when the GPS data was captured. So now I can test the various algorithms without driving around. From this I noticed that the “snap-to” algorithm works about 10% of the time and needs to improved.