Re: [Xastir] boot from external drive?
On Oct 24, 2007, at 6:52 AM, Gerry Creager wrote: Fortran-based GUIs are, of course, an exercise for the truly interested student. Or the minimum-wage earning student. Once upon a time, I implemented some text support for a graphics library that was written in FORTRAN- IV (which, the historically or chronologically gifted will recall had no real character or string support). I forget the name of the graphics package, but I understand the brain will block out certain kinds of trauma as a defensive mechanism. I'd like, at this point, to start arguing that if we do adopt our own internal format for maps that we produce a product capable of interacting with the Open Geospatial Consortium's standards for GML and servers. Yeah, if there are already standards, we definitely want to target them. Given what's going on with the free data (GNIS data loses useful fields, TIGER may chage for the worse, etc) I would hope we could replace some of the data we're losing with data that is in some of the freely available mapservers that are out there. Maybe somebody will even figure out a sane way to replace TIGER with user- contributed GPS road tracks, or something along those lines. I'll also echo Curt's call for enhanced security here. We likely want to invoke some implementation of GeoDRM, even though it's got a lot of baggage associated with the name. I'm gonna assume that GeoDRM is more about appropriate access control levels to data and not like ScrewYouDRM as propagated by recording industries. I had assumed Curt was talking about more security aware code, less subject to buffer overflow attacks and the like. -Jason kg4wsv ___ Xastir mailing list [email protected] http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir
Re: [Xastir] boot from external drive?
Curt, WE7U wrote: On Tue, 23 Oct 2007, Jason Winningham wrote: *) DATABASE: The initial database is probably going to be PostgreSQL with PostGIS extensions. I'll have to admit I'm a bit torn on this one - I like to keep things simple, and IMO xastir's fairly large number of external support packages required are a weak point. On the other claw, if a GIS- aware database results in performance and features worth the effort, then bring it on. For some of the handheld devices we need a different back-end, so berkeley db files or SQLite might be the way to go there. I'll state a preference for SQLite if we have to go this way but would like the "full-function" Xastir to be PostgreSQL + PostGIS driven. I wouldn't mind seeing a native Mac OS X port (is that Aqua?). Yes, let's keep that in mind as well. 1), and the two versions are incompatible! This is a serious management headache, and something that should not be inflicted on end users. Yep. I'm all for stability and less dependencies. So let Auto-cough or whatever build-script we choose decide the config at the end with only a limited of supported featured. some of us with some processing horsepower and storage could convert to the xastir internal format and distribute those converted maps for folks who don't want to do a "full" build. We could also allow for distributed map databases, where the users could get their vector or raster maps via external servers. Maintain WMS compatibility and start leveraging the WMS servers that are out there... and the new ones coming online. Another worthy goal would be to allow for binary distributions. I know this can get ugly, but it will increase the user base (and hopefully the developer base along with it). Yep. I'm already distributing SuSE RPM's and LSB binaries. I used to be against distributing binaries for a variety of reasons, but many people want them. I need to get on-track for Fedora and CentOS binaries, I guess. Let me check into manufacturing a few more hours in a day. gerry -- Gerry Creager -- [EMAIL PROTECTED] Texas Mesonet -- AATLT, Texas A&M University Cell: 979.229.5301 Office: 979.458.4020 FAX: 979.862.3983 Office: 1700 Research Parkway Ste 160, TAMU, College Station, TX 77843 ___ Xastir mailing list [email protected] http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir
Re: [Xastir] boot from external drive?
The old fogie in me would prefer xastird but there _is_ something appealing to Dxastir... I feel compelled to argue in favor of strong support for Fortran as a language of choice. Fortran-based GUIs are, of course, an exercise for the truly interested student. I'm really thinking ant for a cross-platform build scripting approach. Are we going to advocate Eclipse for the IDE? I'd like, at this point, to start arguing that if we do adopt our own internal format for maps that we produce a product capable of interacting with the Open Geospatial Consortium's standards for GML and servers. The list includes WMS, WFS, SOS (weather!), OLS and CS-W. I'd really love to see services included in the mix to allow exporting our maps and objects across the 'Net. I'll also echo Curt's call for enhanced security here. We likely want to invoke some implementation of GeoDRM, even though it's got a lot of baggage associated with the name. gerry Curt, WE7U wrote: On Tue, 23 Oct 2007, Jason Winningham wrote: I'll take this chance to lobby the developers once again to please target xastir 2 to some cross-platform development environment, so we can run native on windows. I don't do windows, but there are just too blasted many people who do. Can't answer your questions about bootable Linux distributions. As far as the new development, I'm a proponent of cross-platform tools as well, and did the work on the README.win32 document after a couple of users reported that Xastir could be run on Windows. You're speaking to the choir here. I'm not quite in a position to start hacking on new code yet, but it shouldn't be too many months longer. I was mostly silent during the last round of "wouldn't it be great if..." discussions about Xastir-2 'cuz I just didn't have the time/energy at that time to participate. Or code. Current thoughts about the matter: *) DAEMON: We need a daemon that handles the interfaces, does the transmit timing, and talks to a database. This part of it does NOT have to have any kind of GUI interface at all, but we could create a separate (GUI or text) program just for use in configuring it. A person could choose to run just the daemon and the database and connect other clients to it, without running any Xastir GUI clients. *) DATABASE: The initial database is probably going to be PostgreSQL with PostGIS extensions. As we implement this part of the code we should code for database independence though, including but not limited to MySQL, SQLite, and even perhaps Berkeley DB files. *) GUI: This is problematic. Some of the handheld devices are Gtk only. Some are Qt only. We currently program with Motif but that is not in vogue anymore and lately has been problematic. Something like WxWidgets could also work across multiple platforms but it looks kind of "lowest common denominator". Duplication of the GUI programs will probably occur as people may need a Gtk and a Qt application for two different platforms. *) LANGUAGE(S): Can be different for each piece. The daemon will most likely be written in C or C++. The GUI pieces may be written in several languages as they only need to interface with the Xastir daemon API. I'm envisioning this as a standard setup: - Xastir Daemon. Because one of my buddies like's to call our project "Disaster", just for fun I'll call it "DXASTIR" for now. - PostgreSQL + PostGIS extensions. - Messaging/Bulletins GUI: Gtk and Qt versions. - Map GUI: Gtk and Qt versions. - Other GUI's for other pieces we might need: Gtk and Qt versions. - Dxastir Configuration GUI: Gtk and Qt versions. - Other GUI pieces as needed (I'm sure I forgot some). - "Make" scripts using one of the newer cross-platform build systems perhaps? Looking for suggestions here: Automake/autoconf - probably not! Maven? Ant? Others? While we're at it, I'd also like to import maps and store them in our own internal format. This would allow us to take image maps in some other projection and/or datum and convert them to what we need for display - ONCE! Same for vector maps: Convert them once and be done with it. The vector maps could (should?) also be stored in the database instead of as flat files. That's where the spatially-aware database comes in. Intended "Make" targets: Solaris HP-UX Linux (many variants) Windows, 98 through Vista Nokia N800/N810 and similar handhelds (Gtk) Qtopia handhelds Others? Security of the daemon, database, and API is also a factor. Discussions on this are welcome. I'd also like to have the ability to "remote control" the daemon, so that I could change it's configuration and have it adopt the new configuration easily, plus have a web-based method of showing/manipulating a map screen. To be absolutely clear here, we're talking MULTIPLE applications here. A "family" of applications instead of one monolithic program that does everything (as we have now). -- Curt, WE7U: XASTIR: "Lotto: A ta
Re: [Xastir] boot from external drive?
On Tue, 23 Oct 2007, Jason Winningham wrote: > > *) DATABASE: The initial database is probably going to be > > PostgreSQL with PostGIS extensions. > > I'll have to admit I'm a bit torn on this one - I like to keep things > simple, and IMO xastir's fairly large number of external support > packages required are a weak point. On the other claw, if a GIS- > aware database results in performance and features worth the effort, > then bring it on. For some of the handheld devices we need a different back-end, so berkeley db files or SQLite might be the way to go there. > I wouldn't mind seeing a native Mac OS X port (is that Aqua?). Yes, let's keep that in mind as well. > 1), and the two versions are incompatible! This is a serious > management headache, and something that should not be inflicted on > end users. Yep. I'm all for stability and less dependencies. > some of us with > some processing horsepower and storage could convert to the xastir > internal format and distribute those converted maps for folks who > don't want to do a "full" build. We could also allow for distributed map databases, where the users could get their vector or raster maps via external servers. > Another worthy goal would be to allow for binary distributions. I > know this can get ugly, but it will increase the user base (and > hopefully the developer base along with it). Yep. I'm already distributing SuSE RPM's and LSB binaries. I used to be against distributing binaries for a variety of reasons, but many people want them. -- Curt, WE7U: XASTIR: "Lotto: A tax on people who are bad at math." -- unknown "Windows: Microsoft's tax on computer illiterates." -- WE7U The world DOES revolve around me: I picked the coordinate system! ___ Xastir mailing list [email protected] http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir
Re: [Xastir] boot from external drive?
On Oct 23, 2007, at 11:00 AM, Curt, WE7U wrote: *) DAEMON: We need a daemon that handles the interfaces, does the transmit timing, and talks to a database. The nice part about this multiple binary approach is that development could theoretically start soon, as the daemon could speak APRS-IS over a local port and get GUI by talking to the existing xastir 1.9 server interface. *) DATABASE: The initial database is probably going to be PostgreSQL with PostGIS extensions. I'll have to admit I'm a bit torn on this one - I like to keep things simple, and IMO xastir's fairly large number of external support packages required are a weak point. On the other claw, if a GIS- aware database results in performance and features worth the effort, then bring it on. *) GUI: This is problematic. Some of the handheld devices are Gtk only. Some are Qt only. This is a tough one. The only thing I'll say here is keep support package requirements as simple as possible, and whatever we use should be fairly easy to get/build/use so that xastir doesn't depend on Y which in turn depends on A, B, C, and D. Something like wxPython scares me. I tried a quick (./configure;make;make install) build of wxWidgets on Solaris and on linux, and neither was successful. I didn't try to find out why, but it _must_ be that simple to get the support packages or people won't use xastir. I wouldn't mind seeing a native Mac OS X port (is that Aqua?). *) LANGUAGE(S): Can be different for each piece. The daemon will most likely be written in C or C++. The GUI pieces may be written in several languages as they only need to interface with the Xastir daemon API. Again, let's keep that list short, and use those that are stable and portable. I hate to pick on python, but that's my poster child for staying away from some of these development tools. I have one package that needs Python 2.X and others that need 2.Y (where Y = X + 1), and the two versions are incompatible! This is a serious management headache, and something that should not be inflicted on end users. While we're at it, I'd also like to import maps and store them in our own internal format. This would allow us to take image maps in some other projection and/or datum and convert them to what we need for display - ONCE! Sounds like a good idea. Could be a big performance improvement, and would allow a simpler build for "typical" users, and some of us with some processing horsepower and storage could convert to the xastir internal format and distribute those converted maps for folks who don't want to do a "full" build. Another worthy goal would be to allow for binary distributions. I know this can get ugly, but it will increase the user base (and hopefully the developer base along with it). -Jason kg4wsv ___ Xastir mailing list [email protected] http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir
Re: [Xastir] boot from external drive?
On Tue, 23 Oct 2007, Jason Winningham wrote: > I'll take this chance to lobby the developers once again to please > target xastir 2 to some cross-platform development environment, so we > can run native on windows. I don't do windows, but there are just > too blasted many people who do. Can't answer your questions about bootable Linux distributions. As far as the new development, I'm a proponent of cross-platform tools as well, and did the work on the README.win32 document after a couple of users reported that Xastir could be run on Windows. You're speaking to the choir here. I'm not quite in a position to start hacking on new code yet, but it shouldn't be too many months longer. I was mostly silent during the last round of "wouldn't it be great if..." discussions about Xastir-2 'cuz I just didn't have the time/energy at that time to participate. Or code. Current thoughts about the matter: *) DAEMON: We need a daemon that handles the interfaces, does the transmit timing, and talks to a database. This part of it does NOT have to have any kind of GUI interface at all, but we could create a separate (GUI or text) program just for use in configuring it. A person could choose to run just the daemon and the database and connect other clients to it, without running any Xastir GUI clients. *) DATABASE: The initial database is probably going to be PostgreSQL with PostGIS extensions. As we implement this part of the code we should code for database independence though, including but not limited to MySQL, SQLite, and even perhaps Berkeley DB files. *) GUI: This is problematic. Some of the handheld devices are Gtk only. Some are Qt only. We currently program with Motif but that is not in vogue anymore and lately has been problematic. Something like WxWidgets could also work across multiple platforms but it looks kind of "lowest common denominator". Duplication of the GUI programs will probably occur as people may need a Gtk and a Qt application for two different platforms. *) LANGUAGE(S): Can be different for each piece. The daemon will most likely be written in C or C++. The GUI pieces may be written in several languages as they only need to interface with the Xastir daemon API. I'm envisioning this as a standard setup: - Xastir Daemon. Because one of my buddies like's to call our project "Disaster", just for fun I'll call it "DXASTIR" for now. - PostgreSQL + PostGIS extensions. - Messaging/Bulletins GUI: Gtk and Qt versions. - Map GUI: Gtk and Qt versions. - Other GUI's for other pieces we might need: Gtk and Qt versions. - Dxastir Configuration GUI: Gtk and Qt versions. - Other GUI pieces as needed (I'm sure I forgot some). - "Make" scripts using one of the newer cross-platform build systems perhaps? Looking for suggestions here: Automake/autoconf - probably not! Maven? Ant? Others? While we're at it, I'd also like to import maps and store them in our own internal format. This would allow us to take image maps in some other projection and/or datum and convert them to what we need for display - ONCE! Same for vector maps: Convert them once and be done with it. The vector maps could (should?) also be stored in the database instead of as flat files. That's where the spatially-aware database comes in. Intended "Make" targets: Solaris HP-UX Linux (many variants) Windows, 98 through Vista Nokia N800/N810 and similar handhelds (Gtk) Qtopia handhelds Others? Security of the daemon, database, and API is also a factor. Discussions on this are welcome. I'd also like to have the ability to "remote control" the daemon, so that I could change it's configuration and have it adopt the new configuration easily, plus have a web-based method of showing/manipulating a map screen. To be absolutely clear here, we're talking MULTIPLE applications here. A "family" of applications instead of one monolithic program that does everything (as we have now). -- Curt, WE7U: XASTIR: "Lotto: A tax on people who are bad at math." -- unknown "Windows: Microsoft's tax on computer illiterates." -- WE7U The world DOES revolve around me: I picked the coordinate system! ___ Xastir mailing list [email protected] http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir
Re: [Xastir] boot from external drive?
Jason Winningham wrote: Has anyone tried putting a linux distro on an external drive (like a USB powered laptop drive enclosure) to boot linux and run xastir? I'd gladly set up such a drive for the balloon chasers to use, if it would work. Live distros work, but they are so slow I can't get my users to use them, and there is the problem of saving (and total ease of losing) the logged data. The only issue is likely to be the system BIOS ... as long as it can boot from a USB device then it should work, just make sure the USB etc. drivers are built in the kernel or initrd. I haven't tried it myself yet though is another project I was going to try sometime (using a USB flash drive probably, just make sure the system has enough RAM to avoid using swap). ... Niall ___ Xastir mailing list [email protected] http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir
