On Mon, Jan 25, 2010 at 12:13 PM, Curt, WE7U <[email protected]> wrote:
> As I understand it, and my understanding is pretty iffy here, the > spatially-enabled databases add extra functions for doing searches > based on latitude/longitude bounding boxes. That is my (incredibly limited) understanding as well. I am operating under the assumption that if I simply spec it to use postgress, then moving to postGIS would entail a db engine recompile to include GIS extensions, and possibly modifying some queries to use that extra functionality. Right now the project is specced as two parts: a data "broker" that will basically act as everything under the "interfaces" menu in xastir and shove the data into a DB, and a "viewer" that will display stations from the DB (on a blank background, no maps yet) encompassing the stuff in "display filter" and "data filter" menus. They are separate applications with the database as the common link. We (the software engineering instructor and myself) have tried to present xastir V2 implemented in Qt as a project, but there have been no takers. In order to make it less scary, we're presenting these two core pieces as a new project, with xastir as an example implementation. I am fairly certain we'll have some teams working on it this term. Lots is being left out as hard requirements (TNC interfacing, mapping, messaging, position reporting, all come to mind), but I'm shooting for a useful core for further development by either xastir developers or future classes. Hmm, if it doesn't use X it wouldn't be _X_astir, would it? Maybe Q-tastir? (ducks and runs) -Jason kg4wsv _______________________________________________ Xastir-dev mailing list [email protected] http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir-dev
