Status update

OK, I've now got SQL Server 2008 Express installed, which does support spatial data. Which is nice. I've yet to see what I can do with it, though one thing I look forward to is being able to store lines as geometric data instead of having to perform string manipulation within a stored procedure. We're going to stick with Express because we need a database on every customer's site and our business is such that we can't fit a full SQL Server license into the deal. I'm developing on Express so I always know with absolute certainty that what I do will work in the field.

FME is quietly chugging away pulling data in, but it's a little on the slow side. My personal opinion is that it eats far too much memory for what I'm asking of it, and that there could be some quite considerable optimisations made. All the same, it does what we need it to. I'm going to ask if we can buy a hardware-locked FME license in preference to a node-locked license, so we can run jobs (which should ultimately occur quarterly) on any machine which isn't in use. I'd like one now, so I can use this machine for developing on at the same time. I can foresee a time when we have a node-locked license and the machine we need to run the translation on becomes outmoded or unavailable through malfunction. And I don't want to have to deal with that.

FME can generate Voronoi cells, but we're now debating whether we need to do that or just go back to the Nearest Neighbour approach with 50m accurate points from Densified lines. Which would blow away the point about being able to store lines - the roads are stored as To and From Node IDs for our Dijkstra implementation to walk down, and the positions of those Nodes are stored in another table. For each To / From combination we store whether the path is Forwards or Backwards, and a Road ID which points to another table containing all the points in that Road except for the Nodes (which we already have elsewhere).