So you know when I said I would update next week and didn’t for the next two weeks. Yeah. Well, family came up for the fourth of July and I had to work a few extra days at Rocks State Park due to the holiday. The end result of these events was a slacking off on my mapping projects.
However, after all those shenanigans were over with I spent my time on generating the polyline KML data for the state park trails and polygon KML data for the state park area. Did you know how incredibly large these datasets are when converted to KML? Lets just say they are well above the limits of Google Maps. It was a total bummer to realize this. However, as I always say, there is always a solution.
Solution A: Generalize the KML data to decrease the size.
Why solution A does not work for me: A lot of people actually recommend doing this. I imagine this would work if I did not want my data to be as accurate as possible. However, if people are going to be using these maps to see where they trails are in comparison with the landscape, too much generalization is not going to fly.
Solution B: Create a spatial query on the MySQL backend to the extent of the map window
Why I chose solution B: First and foremost, it allows me to drastically decrease the file size of the KML shipped from my server. Second of all, it does not decrease the accuracy of the data. This method does limit the spatial extent at which a layer can be shown. But you can not really see the trails or park polygons from that far out anyway.
Here is my query:
This seams to be working out pretty well. The back-end is completed. Hooray! My problem is that IE does not recognize the KML file I generate for some reason. Firefox on Windows and OS X, Safari and Opera all run the page great. I am starting to get incredibly frustrated. I can totally relate to this pie chart.
Alright, well I have the rest of the day scheduled for cover letters and then I am going to Artscape the arts festival of Baltimore. Since this is a mapping blog that someone relates to Baltimore, here is a map of the festival.
Later Days, Christopher A. Fricke