October 2009 Blog Posts
I’ve been investigating the issues with dealing with invalid geography data, from live GPS points, and how that can be stored in SQL Server spatial types. Firstly I must retract the statement about using TRY/CATCH, since although you can use it, the resultant type won’t contain invalid data, it will be null. I have so much data I screwed the tests. So now my options are to create MULTILINESTRINGs or use the Geometry type, both of which I’ve considered and are both solutions that were suggested as a comment on the previous entry. I also spent some time yesterday discussing...
In my previous post I was talking about the new SQL Server 2008 spatial features and how they help with most types of location data, but I mentioned the big issue is the trace back one, where a line isn’t valid if it goes back on itself. I thought I’d explain this more clearly, so consider the following points that define a line: -0.17187595367432515, 51.50221132119076 -0.17191886901856548, 51.503840854209066 -0.1680564880371023, 51.50378742782091 -0.17191886909856548, 51.503840854209066 This defines 3 segments: vertically up, across to the right, and then back to the left,...
One of the applications I work on deals with a lot of geographical data; 32Gb database, one table having 22 million rows. Certainly not the biggest I’ve heard of, but the biggest I’ve worked on. Most of this data is point data, which is currently stored as separate Longitude and Latitude fields, which are floats, but we’re now on SQL 2008 and using the new spatial features has some advantages, noticeably speed, and to take advantage of that we need to add a column of type Geography. Next, this column needs to be updated with the existing data: ...