Curt, WE7U wrote:
On Sun, 15 Jun 2008, Jason KG4WSV wrote:
Java, Ruby, Python, et al, seem to me to be rather heavy in terms of
system requirements good performance. Is this true? My knee-jerk
reaction is that the smaller devices (handhelds, old 486 computers,
etc) would be strained by the re
On Sun, 15 Jun 2008, Jason KG4WSV wrote:
> On the abstraction layers around the daemon:
>
> Where does network extensible fit in? I can see where in some
> situations (mostly emergency/disaster response) there could be
> multiple data feeds and multiple clients. Would a single daemon
> instance
On Sun, Jun 15, 2008 at 12:02 PM, Magne Mæhre <[EMAIL PROTECTED]> wrote:
> So, lets find a language and environment which is productive,
> maintainable, and with good available libraries.
No argument, but the proposed requirements include some support for
smaller hardware platforms, so performanc
On Sun, 15 Jun 2008, Magne Mæhre wrote:
> The reason I mentioned some of these is that there is more or less the
> same basic information (I even did a dirty hack to get input from my
> AIS receiver into xastir for visualization once). Not that I know how
> useful it would be, but an somewhat bro
On Sun, 15 Jun 2008, Magne Mæhre wrote:
> So, lets find a language and environment which is productive,
> maintainable, and with good available libraries.
Note that the language used for the daemon & persistence layer (no
GUI) doesn't have to be the same as the Xastir-NG clients (GUI). In
fact e
Curt, WE7U wrote:
> On Sun, 15 Jun 2008, Jason KG4WSV wrote:
>
>> Java, Ruby, Python, et al, seem to me to be rather heavy in terms of
>> system requirements good performance. Is this true? My knee-jerk
>> reaction is that the smaller devices (handhelds, old 486 computers,
>> etc) would be strai
On Sun, 15 Jun 2008, Tom Russo wrote:
> Proper OO design begins with study of use cases and requirements capture.
>
> > What are we trying to accomplish, why isn't Xastir good enough?
>
> Xastir has become unmaintainable due to years of creeping featurism. The
> Motif library on which it is ba
> I don't have a lot of experience with C++, but it's close enough to
> C that I've been able to do some C++ hacking here and there. I
> wouldn't object to going with C++.
>
> More votes?
>
Only my second post to the list, so I'm not sure if my vote 'counts',
but I'm definitively all for C++.
On Sun, 15 Jun 2008, Jason KG4WSV wrote:
> Java, Ruby, Python, et al, seem to me to be rather heavy in terms of
> system requirements good performance. Is this true? My knee-jerk
> reaction is that the smaller devices (handhelds, old 486 computers,
> etc) would be strained by the resource requir
REQUIREMENT: GUI supports multiple map windows or multiple, independent
instances.
USE-CASE: When operating an event or SAR instance, tracking multiple,
and independent areas may be required. A single large map with
restricted resolution requires zoom and restore actions to be able to
determ
Curt, WE7U wrote:
On Sun, 15 Jun 2008, Gerry Creager wrote:
The GDAL/ORG tools work nicely for vector -> postGIS management. They also
offer some help for rasters although getting a good raster into a postGIS db
isn't that good an idea. Better a good vector MAP, then a georeferenced
raster wi
On Sun, 15 Jun 2008, Gerry Creager wrote:
> My preference for hand-held and embedded devices... at this time and subject
> to change... is SQLite and adding a geoprocessing layer, probably based on
> GDAL, in.
I'd prefer SQLite over Berkeley. I've used Berkeley (BDB) a bit and
it suffers from "c
On Sun, 15 Jun 2008, Gerry Creager wrote:
> The GDAL/ORG tools work nicely for vector -> postGIS management. They also
> offer some help for rasters although getting a good raster into a postGIS db
> isn't that good an idea. Better a good vector MAP, then a georeferenced
> raster with the geo da
On Sun, Jun 15, 2008 at 01:18:30PM +0200, we recorded a bogon-computron
collision of the <[EMAIL PROTECTED]> flavor, containing:
> I've been reading the recent xastir-ng threads with some interest, and
> while the programming language, programming paradigms and supported
> platforms are interestin
Gerry Creager wrote:
> Magne Mæhre wrote:
>> I've been reading the recent xastir-ng threads with some interest, and
>> while the programming language, programming paradigms and supported
>> platforms are interesting questions, I guess the functional
>> (and non-functional) requirements should be de
The GDAL/ORG tools work nicely for vector -> postGIS management. They
also offer some help for rasters although getting a good raster into a
postGIS db isn't that good an idea. Better a good vector MAP, then a
georeferenced raster with the geo data maintained in the db.
I'm currently thinkin
Magne Mæhre wrote:
I've been reading the recent xastir-ng threads with some interest, and
while the programming language, programming paradigms and supported
platforms are interesting questions, I guess the functional
(and non-functional) requirements should be determined first !?
Woohoo! A sy
I realize that PostGIS and friends are intended to store the typical
ARPS stations/objects/etc.
What I'm unclear on is what this may mean for mapping. Would this
also mean that, instead of various map types, I would use some tool to
shove my shapefile, GPS track log, etc into the database up fron
My preference for hand-held and embedded devices... at this time and
subject to change... is SQLite and adding a geoprocessing layer,
probably based on GDAL, in.
Magne Mæhre wrote:
Gerry Creager wrote:
If we can use postGIS across most/all platforms it'll save us from
having to do a lot of in
On the abstraction layers around the daemon:
Where does network extensible fit in? I can see where in some
situations (mostly emergency/disaster response) there could be
multiple data feeds and multiple clients. Would a single daemon
instance talk to one or more databases? local or networked? W
Some thoughts from the peanut gallery:
I'm not a software developer (although I did get that education once
upon a time), unless you count the typical scripting a sysadmin does
day to day to get the job done.
Java, Ruby, Python, et al, seem to me to be rather heavy in terms of
system requirements
> Regarding C++, I seem to remember something about problems with
> certain libraries from system to system, but those libraries are
> things the true-blue C++ guys tend to use a lot of. STL maybe? Is
> this something we can avoid entirely in order to run on more
> platforms or will it be a cont
I'm all for supporting sqllite along with other database backends.
sqllite would allow users to set up/use xastir without having to do any
additional database setup.
___
Xastir-dev mailing list
Xastir-dev@xastir.org
http://lists.xastir.org/cgi-bin/mailma
Gerry Creager wrote:
> If we can use postGIS across most/all platforms it'll save us from
> having to do a lot of inherent GIS functions. That said, MySQL and
> SQLite can also do a lot of the lifting for us. Access, believe it or
> not, has been shimmed with some form of a spatial-awareness cloa
Curt, WE7U wrote:
> Does anyone have experience with persistence mechanisms,
> particularly cross-platform?
>
> We need a persistence mechanism that will support as many of the
> chosen platforms as possible. It also must allow us to swap the
> back-end database among several alternatives, runnin
I've been reading the recent xastir-ng threads with some interest, and
while the programming language, programming paradigms and supported
platforms are interesting questions, I guess the functional
(and non-functional) requirements should be determined first !?
What are we trying to accomplish,
FWIW,
When we started a recent project, (not so recent anymore), we needed
to use Irish Mapping information. With much help from Tom and Gerry,
I was able to convert them into something xastir could use. However,
the results were pretty poor, so we (Kristian) ended up doing a GUI
from s
27 matches
Mail list logo
