|
| From: | Kristian Evers |
| Subject: | Re: [Bug-gama] Feature request: Allow usage of id and time attributes in observation tags in XML files |
| Date: | Wed, 19 Dec 2018 12:04:17 +0000 |
|
Hi Ales, I’ve added
address@hidden
to the recipients, hopefully this mail and the previous thread arrives in the mail list archive eventually. Regarding the database, the corporate policy here is to use Oracle so that is what we do. But for this use case it doesn’t
really matter as we are interfacing with the database via a purpose-made Python API (there are many reasons for this, amongst them are the flexibility to switch database and perform complicated logic not suited for the database level). I see your point in
terms of interfacing directly with the database via Qt, while it is a great idea and a cool feature for gama to have, it would not be particular suitable for our use case I think. We rely on a data model that is quite different to what gama uses in the sqlite
files, so we would still have to rely on outside logic to prepare data for adjustments. For the time attribute it was not my intention to ascribe any inherent value to it, I would just have it there as metadata
for the operator. I agree that assigning meaning to a timestamp in an adjustment poses all sorts of problems, so let’s not go down that road. We do keep an observation time for each of our observations. Exactly what it means depends on which type of observation
it is (and how old it is), but in the general case we store a timestamp midway between start and end of the observation. Ultimately a time attribute is a nice-to-have for me, but it would allow a gama operator to get a quick overview of the observation they
are working on. In our database we have observations going all the way back to the first half of the 19th century. While we usually use observations from the last decade or so, it happens that we use the older observations as well in which case
it can help the operator decide how to proceed with the adjustment. Regarding the observation id attribute, that is definitely the most important to me. At the moment we handle the problem
by keeping a list of each observation with their database IDs and to/from points in the <description> section. This works but is in no way elegant. If xml-tags not required by gama was allowed we could work around all of this in nice and clean ways. Speaking
of that, what is the reason for the strict interpretation of the xml? Enjoy the Christmas party, Kristian Fra: Aleš Čepek <address@hidden>
Dear Kristian, I do not see your email in bug-gama list archive (I am sure I approved it yesterday), can you send it there again please? Your suggestion needs thorough consideration, I am leaving for our department Christmas party in a
moment and anyway I need some tome to think about your proposal. Meanwhile let me ask a technical detail. What database are you using? As you may know, gama can read adjustment input from sqlite3 database (and the Qt graphical interface qgama from any database
supported by Qt platform. So may be there is a better option than enhancement of XML format. Actually, adding timestamps to gama-local observations is not a good idea, this might suit your specific needs but it is not general solution (talking about leveling,
what the timestamp should mean? Beginig of the observations, end, mean time? And what is time in general, with my roots in geodetic astronomy I must ask, are you talking about MJD (Modified Julian Date) or about what? By the way, several decades ago I started
my professional carrier at the Leveling Section of the Czech Surveying office (one year only, my first benchmark was about 60 kilometers). On the other hand, general ID could serve anybody (with metadata elsewhere). .... but I would like to ask all these
rhetorical questions in the bug-gama list. If you were using Postresql, it would be a delight to add direct access with libpq++ library. Aleš On Tue, 18 Dec 2018 at 16:54, Kristian Evers <address@hidden> wrote:
|
| [Prev in Thread] | Current Thread | [Next in Thread] |