I've always wanted to know more about lower level systems. I can run a TSR app in MS-DOS and steal data from it using QuickBASIC (I did this once to make an oscilliscope type app using a sound recorder with a 2kb buffer and output set to nul:) but I'd love to know more about electronics, PICs, etc.
So I have a plan.
I'm going to start reading bits & pieces as & when I need to, and try to make small circuits I can fit in a tic-tac box. I do have some tripad board and some veroboard, but I'm somewhat lacking in thin single-core wire and actual components. And for such small designs, I might abandon boards altogether.
I'll post about my first project when I get to it :)
Wednesday, November 19, 2008
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).
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).
Monday, November 10, 2008
Dagnabbit, it *doesn't* work after all!
Because of the distortion between Latitude & Longitude, and the sparseness (sparsity??) of the data we're using, we found that we had difficulties where we have a sparse road with a dense junction at one end. The "nearest point" in terms of Longitude & Latitude is not necessarily the same as that in terms of Metres.
We now have further options: One is to generate Voronoi Cells around every road & junction, and use those to determine which road section (up to 50m in length) or junction someone is at by checking if their location is within that cell. Another is to oversample the road (required for the generation of the Voronoi Cells in any case) and hope that the existing algorithm works properly in that case - which would probably be much quicker.
I've spent an inordinate amount of time tinkering with a tool called FME, which allows me to throw geometric data about. It's with FME that I created the node map we used to do the routing, although I have also written an exporter in C# using our own Shapefile reader (started by Ben, enriched by myself). FME also allows us to generate the Voronoi Cells, but if we don't need them, we might not even need FME in the long run.
Watch this space!
We now have further options: One is to generate Voronoi Cells around every road & junction, and use those to determine which road section (up to 50m in length) or junction someone is at by checking if their location is within that cell. Another is to oversample the road (required for the generation of the Voronoi Cells in any case) and hope that the existing algorithm works properly in that case - which would probably be much quicker.
I've spent an inordinate amount of time tinkering with a tool called FME, which allows me to throw geometric data about. It's with FME that I created the node map we used to do the routing, although I have also written an exporter in C# using our own Shapefile reader (started by Ben, enriched by myself). FME also allows us to generate the Voronoi Cells, but if we don't need them, we might not even need FME in the long run.
Watch this space!
Subscribe to:
Posts (Atom)