On 8/6/2014 4:08 AM, Mark Morgan Lloyd wrote:
waldo kitty wrote:
i suspect this is going to be like the long-standing joke of
cheap, fast, stable: choose two
over the years, i've seen two schools of code for dealing with dates... years,
specifically... one school is string based and the other is math based... both
have their faults and pluses...
eg: string based fault : prepend '19' to single digit year value
math based fault : 2003 - 1900 = 103 (3 is intended result)
I'd be inclined to start off using your method 1, i.e. text manipulation until
the format is consistent.
i don't understand "until the format is consistent"... the format has been in
use since the 60s at least (AFAIK) ;)
FWIW: i have taken some time and reworked things to be math based while still
taking the required text format into account... i've seen a very nice increase
in processing speed and now need to just make sure that i don't run into any of
the basic and well known flaws that math processing of date strings seem to have ;)
Flatten the original record and save it in a database, create a new flat text
this appears that you are speaking of a sql database or similar? that may be a
later feature but for now, everything is/has to be done with the raw TLE files...
i'm not sure what you mean by "flatten", either... currently i break down the
TLEs into their major records for storage in the in-memory ""database""... the
processing i posted is done before that storage takes place...
the goal of the program is to build the in-memory database from all specified
TLE files and then to write out new TLE files which may be filtered on a
selection property so that only certain matching TLE records are saved...
eg: take 100 TLE files and build one new TLE file containing only geosynch
objects
record starting with a database reference and then comprising slightly-massaged
text. Run consistency checks on the new records until everything looks good
(e.g. no non-numeric garbage resulting from a failed EBCDIC or GOST conversion),
and only then parse it into numeric fields.
yeah, we don't have to worry about EBCDIC or similar because all that's done
when those tools generate the TLE files they output... FORTRAN was used
originally but these days, there's numerous languages used... the format is
plain old 7bit ASCII characters of 0-9... if there's a 0th line with the
object's ""name"" in it, it is only (IME) A-Z0-9... for my purposes, lowercase
letters are no problem, though ;)
Out of curiosity, I presume that times are GMT/UTC but does a day start at
midnight or noon (civil and astronomers' convention respectively)?
i'm not sure on this either... i just know that my calculations return the same
results as all the other programs and web sites i've validated against... i'm
pretty sure that UTC is the base and i assume that the day starts at midnight...
again, this because my calculations return the same results and projections as
other programs and web sites i've validated against...
more information on the TLE format is available in numerous places on the web...
one well known one is
http://celestrak.com/columns/v04n03/
Do the coordinates have to take into account changed ephemeris changes as the
equinox precesses?
i presume so but am not sure... each TLE record stands on its own and can be
used to create tracking forward and backward in time for X period of time... as
time progresses from the epoch, the certainty of the calculations falls off for
numerous reasons... solar flux, perturbations, atmospheric drag, boosting the
orbit, etc...
--
NOTE: No off-list assistance is given without prior approval.
Please *keep mailing list traffic on the list* unless
private contact is specifically requested and granted.
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
