Amateurfunk Forum - Archiv

Fragen und Antworten zum Thema Funk


Impressum

Verantwortlich für dieses Angebot gemäß § 5 TMG / § 55 RStV:
Michael Ott
Dorpater Straße 11
70378 Stuttgart
Deutschland



Trotz sorgfältiger inhaltlicher Kontrolle übernehmen wir keine Haftung für die Inhalte externer Links. Für den Inhalt der verlinkten Seiten sind ausschließlich deren Betreiber verantwortlich.

Datenschutzerklärung

Diese Datenschutzerklärung klärt Sie über die Art, den Umfang und Zweck der Verarbeitung von personenbezogenen Daten (nachfolgend kurz „Daten“) innerhalb unseres Onlineangebotes und der mit ihm verbundenen Webseiten, Funktionen und Inhalte auf (nachfolgend gemeinsam bezeichnet als „Onlineangebot“). Im Hinblick auf die verwendeten Begrifflichkeiten, wie z.B. „Verarbeitung“ oder „Verantwortlicher“ verweisen wir auf die Definitionen im Art. 4 der Datenschutzgrundverordnung (DSGVO).

Verantwortlicher

Michael Ott
Dorpater Straße 11
70378 Stuttgart
Deutschland



Arten der verarbeiteten Daten:

- Meta-/Kommunikationsdaten (siehe Abschnitt „Erhebung von Zugriffsdaten und Logfiles“)

Kategorien betroffener Personen

Besucher und Nutzer des Onlineangebotes (Nachfolgend bezeichnen wir die betroffenen Personen zusammenfassend auch als „Nutzer“).

Zweck der Verarbeitung

- Zurverfügungstellung des Onlineangebotes, seiner Funktionen und Inhalte
- Sicherheitsmaßnahmen.

Verwendete Begrifflichkeiten

„Personenbezogene Daten“ sind alle Informationen, die sich auf eine identifizierte oder identifizierbare natürliche Person (im Folgenden „betroffene Person“) beziehen; als identifizierbar wird eine natürliche Person angesehen, die direkt oder indirekt, insbesondere mittels Zuordnung zu einer Kennung wie einem Namen, zu einer Kennnummer, zu Standortdaten, zu einer Online-Kennung (z.B. Cookie) oder zu einem oder mehreren besonderen Merkmalen identifiziert werden kann, die Ausdruck der physischen, physiologischen, genetischen, psychischen, wirtschaftlichen, kulturellen oder sozialen Identität dieser natürlichen Person sind.

„Verarbeitung“ ist jeder mit oder ohne Hilfe automatisierter Verfahren ausgeführte Vorgang oder jede solche Vorgangsreihe im Zusammenhang mit personenbezogenen Daten. Der Begriff reicht weit und umfasst praktisch jeden Umgang mit Daten.

„Pseudonymisierung“ die Verarbeitung personenbezogener Daten in einer Weise, dass die personenbezogenen Daten ohne Hinzuziehung zusätzlicher Informationen nicht mehr einer spezifischen betroffenen Person zugeordnet werden können, sofern diese zusätzlichen Informationen gesondert aufbewahrt werden und technischen und organisatorischen Maßnahmen unterliegen, die gewährleisten, dass die personenbezogenen Daten nicht einer identifizierten oder identifizierbaren natürlichen Person zugewiesen werden.

Als „Verantwortlicher“ wird die natürliche oder juristische Person, Behörde, Einrichtung oder andere Stelle, die allein oder gemeinsam mit anderen über die Zwecke und Mittel der Verarbeitung von personenbezogenen Daten entscheidet, bezeichnet.

„Auftragsverarbeiter“ eine natürliche oder juristische Person, Behörde, Einrichtung oder andere Stelle, die personenbezogene Daten im Auftrag des Verantwortlichen verarbeitet.

Maßgebliche Rechtsgrundlagen

Nach Maßgabe des Art. 13 DSGVO teilen wir Ihnen die Rechtsgrundlagen unserer Datenverarbeitungen mit. Sofern die Rechtsgrundlage in der Datenschutzerklärung nicht genannt wird, gilt Folgendes: Die Rechtsgrundlage für die Einholung von Einwilligungen ist Art. 6 Abs. 1 lit. a und Art. 7 DSGVO, die Rechtsgrundlage für die Verarbeitung zur Erfüllung unserer Leistungen und Durchführung vertraglicher Maßnahmen sowie Beantwortung von Anfragen ist Art. 6 Abs. 1 lit. b DSGVO, die Rechtsgrundlage für die Verarbeitung zur Erfüllung unserer rechtlichen Verpflichtungen ist Art. 6 Abs. 1 lit. c DSGVO, und die Rechtsgrundlage für die Verarbeitung zur Wahrung unserer berechtigten Interessen ist Art. 6 Abs. 1 lit. f DSGVO. Für den Fall, dass lebenswichtige Interessen der betroffenen Person oder einer anderen natürlichen Person eine Verarbeitung personenbezogener Daten erforderlich machen, dient Art. 6 Abs. 1 lit. d DSGVO als Rechtsgrundlage.

Sicherheitsmaßnahmen

Wir treffen nach Maßgabe des Art. 32 DSGVO unter Berücksichtigung des Stands der Technik, der Implementierungskosten und der Art, des Umfangs, der Umstände und der Zwecke der Verarbeitung sowie der unterschiedlichen Eintrittswahrscheinlichkeit und Schwere des Risikos für die Rechte und Freiheiten natürlicher Personen, geeignete technische und organisatorische Maßnahmen, um ein dem Risiko angemessenes Schutzniveau zu gewährleisten.

Zu den Maßnahmen gehören insbesondere die Sicherung der Vertraulichkeit, Integrität und Verfügbarkeit von Daten durch Kontrolle des physischen Zugangs zu den Daten, als auch des sie betreffenden Zugriffs, der Eingabe, Weitergabe, der Sicherung der Verfügbarkeit und ihrer Trennung. Des Weiteren haben wir Verfahren eingerichtet, die eine Wahrnehmung von Betroffenenrechten, Löschung von Daten und Reaktion auf Gefährdung der Daten gewährleisten. Ferner berücksichtigen wir den Schutz personenbezogener Daten bereits bei der Entwicklung, bzw. Auswahl von Hardware, Software sowie Verfahren, entsprechend dem Prinzip des Datenschutzes durch Technikgestaltung und durch datenschutzfreundliche Voreinstellungen (Art. 25 DSGVO).

Zusammenarbeit mit Auftragsverarbeitern und Dritten

Sofern wir im Rahmen unserer Verarbeitung Daten gegenüber anderen Personen und Unternehmen (Auftragsverarbeitern oder Dritten) offenbaren, sie an diese übermitteln oder ihnen sonst Zugriff auf die Daten gewähren, erfolgt dies nur auf Grundlage einer gesetzlichen Erlaubnis (z.B. wenn eine Übermittlung der Daten an Dritte, wie an Zahlungsdienstleister, gem. Art. 6 Abs. 1 lit. b DSGVO zur Vertragserfüllung erforderlich ist), Sie eingewilligt haben, eine rechtliche Verpflichtung dies vorsieht oder auf Grundlage unserer berechtigten Interessen (z.B. beim Einsatz von Beauftragten, Webhostern, etc.).

Sofern wir Dritte mit der Verarbeitung von Daten auf Grundlage eines sog. „Auftragsverarbeitungsvertrages“ beauftragen, geschieht dies auf Grundlage des Art. 28 DSGVO.

Übermittlungen in Drittländer

Sofern wir Daten in einem Drittland (d.h. außerhalb der Europäischen Union (EU) oder des Europäischen Wirtschaftsraums (EWR)) verarbeiten oder dies im Rahmen der Inanspruchnahme von Diensten Dritter oder Offenlegung, bzw. Übermittlung von Daten an Dritte geschieht, erfolgt dies nur, wenn es zur Erfüllung unserer (vor)vertraglichen Pflichten, auf Grundlage Ihrer Einwilligung, aufgrund einer rechtlichen Verpflichtung oder auf Grundlage unserer berechtigten Interessen geschieht. Vorbehaltlich gesetzlicher oder vertraglicher Erlaubnisse, verarbeiten oder lassen wir die Daten in einem Drittland nur beim Vorliegen der besonderen Voraussetzungen der Art. 44 ff. DSGVO verarbeiten. D.h. die Verarbeitung erfolgt z.B. auf Grundlage besonderer Garantien, wie der offiziell anerkannten Feststellung eines der EU entsprechenden Datenschutzniveaus (z.B. für die USA durch das „Privacy Shield“) oder Beachtung offiziell anerkannter spezieller vertraglicher Verpflichtungen (so genannte „Standardvertragsklauseln“).

Rechte der betroffenen Personen

Sie haben das Recht, eine Bestätigung darüber zu verlangen, ob betreffende Daten verarbeitet werden und auf Auskunft über diese Daten sowie auf weitere Informationen und Kopie der Daten entsprechend Art. 15 DSGVO.

Sie haben entsprechend. Art. 16 DSGVO das Recht, die Vervollständigung der Sie betreffenden Daten oder die Berichtigung der Sie betreffenden unrichtigen Daten zu verlangen.

Sie haben nach Maßgabe des Art. 17 DSGVO das Recht zu verlangen, dass betreffende Daten unverzüglich gelöscht werden, bzw. alternativ nach Maßgabe des Art. 18 DSGVO eine Einschränkung der Verarbeitung der Daten zu verlangen.

Sie haben das Recht zu verlangen, dass die Sie betreffenden Daten, die Sie uns bereitgestellt haben nach Maßgabe des Art. 20 DSGVO zu erhalten und deren Übermittlung an andere Verantwortliche zu fordern.

Sie haben ferner gem. Art. 77 DSGVO das Recht, eine Beschwerde bei der zuständigen Aufsichtsbehörde einzureichen.

Widerrufsrecht

Sie haben das Recht, erteilte Einwilligungen gem. Art. 7 Abs. 3 DSGVO mit Wirkung für die Zukunft zu widerrufen

Widerspruchsrecht

Sie können der künftigen Verarbeitung der Sie betreffenden Daten nach Maßgabe des Art. 21 DSGVO jederzeit widersprechen. Der Widerspruch kann insbesondere gegen die Verarbeitung für Zwecke der Direktwerbung erfolgen.

Löschung von Daten

Die von uns verarbeiteten Daten werden nach Maßgabe der Art. 17 und 18 DSGVO gelöscht oder in ihrer Verarbeitung eingeschränkt. Sofern nicht im Rahmen dieser Datenschutzerklärung ausdrücklich angegeben, werden die bei uns gespeicherten Daten gelöscht, sobald sie für ihre Zweckbestimmung nicht mehr erforderlich sind und der Löschung keine gesetzlichen Aufbewahrungspflichten entgegenstehen. Sofern die Daten nicht gelöscht werden, weil sie für andere und gesetzlich zulässige Zwecke erforderlich sind, wird deren Verarbeitung eingeschränkt. D.h. die Daten werden gesperrt und nicht für andere Zwecke verarbeitet. Das gilt z.B. für Daten, die aus handels- oder steuerrechtlichen Gründen aufbewahrt werden müssen.

Nach gesetzlichen Vorgaben in Deutschland, erfolgt die Aufbewahrung insbesondere für 10 Jahre gemäß §§ 147 Abs. 1 AO, 257 Abs. 1 Nr. 1 und 4, Abs. 4 HGB (Bücher, Aufzeichnungen, Lageberichte, Buchungsbelege, Handelsbücher, für Besteuerung relevanter Unterlagen, etc.) und 6 Jahre gemäß § 257 Abs. 1 Nr. 2 und 3, Abs. 4 HGB (Handelsbriefe).

Hosting und E-Mail-Versand

Die von uns in Anspruch genommenen Hosting-Leistungen dienen der Zurverfügungstellung der folgenden Leistungen: Infrastruktur- und Plattformdienstleistungen, Rechenkapazität, Speicherplatz und Datenbankdienste, E-Mail-Versand, Sicherheitsleistungen sowie technische Wartungsleistungen, die wir zum Zwecke des Betriebs dieses Onlineangebotes einsetzen.

Hierbei verarbeiten wir, bzw. unser Hostinganbieter Meta- und Kommunikationsdaten von Besuchern dieses Onlineangebotes auf Grundlage unserer berechtigten Interessen an einer effizienten und sicheren Zurverfügungstellung dieses Onlineangebotes gem. Art. 6 Abs. 1 lit. f DSGVO i.V.m. Art. 28 DSGVO (Abschluss Auftragsverarbeitungsvertrag).

Erhebung von Zugriffsdaten und Logfiles

Wir, bzw. unser Hostinganbieter, erhebt auf Grundlage unserer berechtigten Interessen im Sinne des Art. 6 Abs. 1 lit. f. DSGVO Daten über jeden Zugriff auf den Server, auf dem sich dieser Dienst befindet (sogenannte Serverlogfiles). Zu den Zugriffsdaten gehören Name der abgerufenen Webseite, Datei, Datum und Uhrzeit des Abrufs, übertragene Datenmenge, Meldung über erfolgreichen Abruf, Browsertyp nebst Version, das Betriebssystem des Nutzers, Referrer URL (die zuvor besuchte Seite), IP-Adresse und der anfragende Provider.

Logfile-Informationen werden aus Sicherheitsgründen (z.B. zur Aufklärung von Missbrauchs- oder Betrugshandlungen) für die Dauer von maximal 7 Tagen gespeichert und danach gelöscht. Daten, deren weitere Aufbewahrung zu Beweiszwecken erforderlich ist, sind bis zur endgültigen Klärung des jeweiligen Vorfalls von der Löschung ausgenommen.

Vom Websiteinhaber angepasst
Erstellt mit Datenschutz-Generator.de von RA Dr. Thomas Schwenke




 [ 47 Beiträge ]  Gehe zu Seite 1, 2, 3, 4
Autor Nachricht
 Betreff des Beitrags: Bibliotek für Satelitenpositionsberechnung (pre-alpha)
Hallo,

Ich Programmiere zurzeit an einer Bibliotek für die Berechnung von Satelliten-Positionen.
Der aktuelle Satus der Bibliotek ist zurzeit pre-alpha da erst ein kleiner Teil des späteren Funktionsumfang programmiert ist. Die Bibliotek ist komplett in C++ geschrieben und OOP.

[b:2swd913a]Diese Funktionen sind zurzeit implementiert:[/b:2swd913a]

-> Auslesen der Satellitenbahndaten aus einem TLE-File
-> Berechnen der Bahnparameter aus diesen Satellitenbahndaten
-> Definieren einer geographischen Position und berechnen der geozentrischen Breite.

[b:2swd913a]Diese Funktionen werden noch implementiert werden:[/b:2swd913a]

-> Berechnung der Satellitenposition für einen beliebigen Punkt auf der Erde (Azimu, Elevation)
-> Berechnung der Modposition für einen beliebiegen Punkt auf der Erde (auch Azimu, Elevation)
-> Berechnung des Dopplereffektes
-> Berechnen der Position die der satellit auf der Erde hätte (Richtung Erdmittelpunkt projeziert)
-> Berechnen des Sichtbarkeitsbereiches vom Satelliten
-> Andere Funktionen die sich als wichtig erweisen werden.


Ich hab die Bibliotek unter die GNU General Public License (GPL) gestellt.

Ein Link zum Projekt:

[url:2swd913a]https://sourceforge.net/projects/satpos[/url:2swd913a]

Der aktuelle Status ist pre-alpha, ich hab heute aber diese soweit vervollständigt dass man sie bereits nutzen kann (natürlich nur das was bereits implementiert ist).
Sie hat warscheinlich noch ein paar Bugs, wenn jemand sie schon nutzen möchte und einen Fehler findet soll er mir ihn bitte schreiben, nichts ist schlimmer als eine Bibliotek mit lauter Bugs.
Die Bibliotek benutzt nur die Standardlibary, sie sollte also auch auf Linux, Mac,... funktionieren. Getestet wurde diese Funktionalität aber noch nicht!

Mal schauen wie lange das ganze Programmieren noch dauert, ist ja kein einfaches Thema.

Ich freue mich auf jede art von meinung/kommentare/bewertung dazu

mfg. pointhi


  
 
 Betreff des Beitrags:
Nur mal grob gesichtet:

Es fehlen Prüfungen auf Plausibilität der Eingabegrößen. In satpos_geop.cpp/bgn_to_grd z. B. kann man auch negative Werte eingeben. Trotzdem behauptet der Kommentar "Rückgabewerte: >=0 ... Erfolg". Das passt nicht zusammen.

In diesem Zusammenhang ist auch auf eine unmissverständliche Kommentierung der Eingabegrößen zu achten. "double wtg_grd" sagt nur aus, dass man ein double übergeben kann. Es sagt nicht, ob das ein Wert im Grad- oder im Bogenmaß sein soll. Weiterhin ist der Kommentar zu Funktion falsch: "Rechnet das Bogenmaß in das Gradmaß um".

Ich würde die Namen etwas ausführlicher und sprechender gestalten. Um bei bgn_to_grd zu bleiben: Was heißt bgn und was grd bzw. bk? Aus dem Kontext heraus ist das zwar klar aber stell dir jemanden vor, der diese Funktion vorgesetzt bekommt und sieht dann nur Abkürzungen.

Warum die Präfixe bei den Klassenfeldern? Z. B. "umlb_" bei satpos_umlb.hpp.

Evtl. weitere Konstruktoren einführen, z. B. in satpos_umlb.hpp, dann könnte man in einem Konstruktor, der ein "satpos::tle *ttu_tlein" annimmt, tle_to_umlb aufrufen.


  
 
 Betreff des Beitrags:
[quote]Es fehlen Prüfungen auf Plausibilität der Eingabegrößen. In satpos_geop.cpp/bgn_to_grd z. B. kann man auch negative Werte eingeben. Trotzdem behauptet der Kommentar "Rückgabewerte: >=0 ... Erfolg". Das passt nicht zusammen. [/quote]
ja, ich hab da nicht bedacht dass es auch negative grad/bogenmaß-werte gibt. Bei plausibilität, soll ich da überprüfen dass z.b. die gradangabe nicht über +-360° geht, und ansonsten so lange +-360 gerechnet wird bis die bedingung erfüllt wird?, wäre für mich das logischte. Bei Bogensekunden und Bogenminuten könnten manche programmieren auch negative werte eingeben, oder ist es unüblich?, hab mit diesem format leider noch nicht sehr viel erfahrung.

Ja, das mit der plausablilität muss noch gemacht werden, die Bibliotek ist ja erst der anfang von der Bibliotek. Ich hab mich auch dazu entschlossen das ganze schon in der pre-alpha version zu veröffentlichen damit solche probleme möglicherweise früher erkannt werden. Fehlererkennung wäre bei mir einer der letzten dinge gewesen die ich in der pre-alpha geproggt hätte.
Das mit den Variabelnamen wollte ich sowieso noch angehen, da ich zurzeit das ganze großteils in Deutsch gehalten habe. Bei der nächsten Version wird dann alles in Englisch sein, nur zurzeit heiß eine variable z.b. umlb_exz, also die numerische Exzentrizität der Umlaufbahn bei den Umlaufbahnparametern. Einerseits ist es gut einen aussagekräftigeren namen zu suchen, anderseits sind lange variabelnamen auch nicht das optimale. Das umlb werde ich demnächst bei der Sprachkonvertierung gleich mitenfernen, die Variabelnamen werden auch englisch.
Ich werde einfach mal bei der nächsten version aussagekräftigere namen zu finden versuchen, aber über 10 zeichen wäre es wohl schon zu viel des guten.

Für die Dokumentation werde ich mich in MediaWiki einarbeiten, ich habe keine lust bei pre-alphas lauter pdfs zu schreiben und bei wikis kann man das ganze auch aussagekräftiger gestalten. Man sucht sich dann einfach die funktion heraus die man benötigt, so habe ich es auch bei SDL gemacht.

bei funktionsnamen, wäre es besser wenn ich bogenmas_zu_gradmas(...) (ß will ich lieber nicht verwenden)?, bei solchen funktionen verschreibt man sich dann relativ leicht wenn man keine funktionsvorschau wie bei der aktuellen codeblocksversion hat. Das wäre dann auch nicht gut, und ich hab leider keine bessere Abkürzung zurzeit gefunden.

[quote]Evtl. weitere Konstruktoren einführen, z. B. in satpos_umlb.hpp, dann könnte man in einem Konstruktor, der ein "satpos::tle *ttu_tlein" annimmt, tle_to_umlb aufrufen.[/quote]

Das musst du mir nocheinmal erklären, was du genau meinst.

NACHTRAG:

Ich wollte gerade mit den variabelnamen anfangen, aber schon bei der ersten Variable : // NORAD-Katalog-Nr.
hatte ich ein kleines blackout, soll ich sie "norad" nennen, oder ist das zu wenig?, "norad_katalognumber", nein, zu lange, "norad_katalog", villeicht, aber ist das nicht schon wieder zu lange?

habt ihr einen tipp wie ich da ein wenig bessere namen finde. Ich kenne leider auch nicht viele englische abkürzungen :(.?, wäre es nicht ausreichen wenn man die ersten paar buchstaben pro wort nimmt, da man sowieso nachschauen kann was das genau ist?, also "noradkatnr", aber irgendwie galube ich dass man bei dem ein paar andere sachen hineinphilosopieren kann, und mich sieht dieses Beispiel auch nicht wirklich an.

mfg. pointhi


  
 
 Betreff des Beitrags:
[quote]Bei Bogensekunden und Bogenminuten könnten manche programmieren auch negative werte eingeben, oder ist es unüblich?[/quote]Es gibt sicherlich Sachen, die in der Szene üblich oder unüblich sind. das hat aber nichts damit zu tun, was technisch möglich ist, irgendwo etwas einzugeben oder einzulesen. Das muss/sollte im Programm behandelt werden. Man muss also die jeweilige Sachlage einschätzen können und diese angemessen behandeln. Soweit das allgemeine Prozedere.

Aber nun zur speziellen Anforderung, Grad mit Bogenminuten und -sekunden zu übergeben: Gradangaben werden selbstverständlich auch gerne negativ eingegeben (Geographische Längen westl. Greenwich). Bogenminuten und -sekunden eigentlich vormalerweise positiv. Aber was ist nun, wenn man aus Anwendersicht eingeben will
-0 Grad Ost, 10', 10'' (= +0 Grad West, 10', 10'')
Da das bei der Funktion in einem Double ankommt, ist das negative Vorzeichen flötengegangen und die Funktion weiß nichts von -0 Grad. Das musst du also irgendwie berücksichtigen.

Für Winkel allgemein sollte es zugelassen werden, nicht nur Werte von 0 bis 360 Grad einzugeben (bzw. 0 bis 2PI), sondern auch darüberhinausgehende Werte, die man dann an geeigneter Stelle in das übliche Intervall bringen sollte. Dies ist zwar für trigonometrische Berechnungen nicht notwendig, wohl aber für die Ausgabe.

Astronomische Winkel würde ich nur in einem Intervall 0 bis 360 Grad akzeptieren, bzw. 0 bis 2PI.

Letztendlich müssen z. B. für geographische Angaben Winkel verboten werden, die nach(!) der Umrechnung in eine Fließkommazahl einen ungültigen Wert ergeben.

Wenn also jemand eingibt:
90 Grad Nord, 60', 0''
dann sind zwar die Einzelparameter erlaubt, der resultierende Fließkommawert aber ungültig.

[quote]Ich werde einfach mal bei der nächsten version aussagekräftigere namen zu finden versuchen, aber über 10 zeichen wäre es wohl schon zu viel des guten.[/quote]Das steht dir natürlich frei, aber ich verstehe trotzdem nicht, warum du dich so gegen lange Namen sträubst. And Abkürzungen finde ich auch nicht toll.

[quote]Evtl. weitere Konstruktoren einführen, z. B. in satpos_umlb.hpp, dann könnte man in einem Konstruktor, der ein "satpos::tle *ttu_tlein" annimmt, tle_to_umlb aufrufen.[/quote]
[quote]Das musst du mir nocheinmal erklären, was du genau meinst.[/quote]
Wie schon gesagt, einen zusätzlichen Konstruktor, der gewisse Parameter erwartet. Also eine weitere Überladung des Konstruktors Ich bin zwar kein C++-Experte aber das sollte doch technisch gehen.?

[quote]Ich wollte gerade mit den variabelnamen anfangen, aber schon bei der ersten Variable : // NORAD-Katalog-Nr.
hatte ich ein kleines blackout, soll ich sie "norad" nennen, oder ist das zu wenig?, "norad_katalognumber", nein, zu lange, "norad_katalog", villeicht, aber ist das nicht schon wieder zu lange?[/quote] Was meinst du mit zu lange? Und warum nicht NoradCatalogueNumber?


  
 
 Betreff des Beitrags:
[quote][quote]Es fehlen Prüfungen auf Plausibilität der Eingabegrößen. In satpos_geop.cpp/bgn_to_grd z. B. kann man auch negative Werte eingeben. Trotzdem behauptet der Kommentar "Rückgabewerte: >=0 ... Erfolg". Das passt nicht zusammen. [/quote]
ja, ich hab da nicht bedacht dass es auch negative grad/bogenmaß-werte gibt. Bei plausibilität, soll ich da überprüfen dass z.b. die gradangabe nicht über +-360° geht, und ansonsten so lange +-360 gerechnet wird bis die bedingung erfüllt wird?, wäre für mich das logischte.
mfg. pointhi[/quote]

Hi,

bei "komischen Eingaben" würde ich auf jeden Fall fragen was der Benutzer meint. Nix automatisch irgendwie umwandeln...


73 de DL3KCZ Uwe


  
 
 Betreff des Beitrags:
[quote]Wie schon gesagt, einen zusätzlichen Konstruktor, der gewisse Parameter erwartet. Also eine weitere Überladung des Konstruktors Ich bin zwar kein C++-Experte aber das sollte doch technisch gehen.?[/quote]

Technisch sollte es funktionieren, nur was ist der sinn von einem zusätzlichen konstruktor. zurzeit wird alles auf 0 gesetzt, wenn ein objekt erstellt wird, und es sind zu viele variablen als dass ich alle schon mit dem konstruktor soubler setzen können. soll man eingeben können alles mit 1 zu initialisieren :)?

[quote]NoradCatalogueNumber[/quote]
ist eine gute idee, weiß nicht warum ich das so kurz mache, aber irgendwie mach ich lieber variablen mit 4 als mit 10 stellen, villeicht wegen dem eingeben.

Ich werde mich bald wieder dransetzen, und villeicht ist nächste woche schon die 1.0.1 prealpha online. Die Bücher die ich für die weiteren Berechnungen werden wohl noch ein wenig dauern bis ich sie habe.

mfg. pointhi


  
 
 Betreff des Beitrags:
@pointhi: wenn Du noch mal Formelfragen hast, frag im anderen thread. In die Programmierung steige ich nicht ein, dazu habe ich z.Zt. zuviel andere "Baustellen". Nur so aus dem Mitlesen: bei Eingaben solltest Du ausgiebig prüfen, speziell auch die Grenzwerte. Das ist oft einiges mehr an Arbeit als die eigentliche Rechnerei. Wenn Dir später in Rechenschleifen das Programm abschmiert, kann es eine elende Sucherei geben. Auch in Unterprogrammen grundsätzlich Divisoren auf Null prüfen -- in Verschachtelungen eine Katastrophe zum Suchen. Ansonsten viel Erfolg,

Wenn die Eingabeprüfung ok ist, muß Dein Programm auch "eine flache Hand auf die Tasten" verkraften, mit Fehlermeldung, aber ohne Absturz.
73 Peter


  
 
 Betreff des Beitrags:
ok,

ich hab die ersten variabelnamen geändert:

[code:u5g7xwn5]tle::tle() {

this->SatelliteName[0] = '\0'; // Name des Sateliten
this->NoradCatalogNumber = 0; // NORAD-Katalog-Nr.
this->Klassification = '\0'; // Klassifizierung
this->InternatonalKlassification[0] = '\0'; // Internationale Klassifizierung
this->InternatonalKlassification[8] = '\0'; // Internationale Klassifizierung
this->Epoche = 0; // Epoche mit Jahr & Tag_Nr. , Tagesbruchteil
this->ResistanceFactorSpg = 0; // Widerstandskoeffizient im SGP-Modell
this->NegligibleResistanceFactorSpg4 = 0; // vernachlässigbarer Widerstandskoeffizient im SGP-Modell
this->ResistanceFactorSpg4 = 0; // Widerstandskoeffizient im SGP4-Modell
this->Ephemeris = 0; // Ephemeridentyp
this->CurrentRecordNumber = 0; // laufende Datensatz-Nummer
this->Checksum1 = 0; // Prüfsumme Modulo 10
this->Checksum2 = 0; // Prüfsumme Modulo 10
this->Inclination = 0; // Inklination
this->RightAscensionOfAscendingNode = 0; // Rektaszension des aufsteigenden Knotens Ω
this->EccentricityOfTheOrbit = 0; // numerische Exzentrizität der Umlaufbahn
this->ArgumentOfPerigee = 0; // Argument des Perigäums ω
this->MeanAnomaly = 0; // Mittlere Anomalie Μ
this->AverageMotion = 0; // Mittlere Bewegung n
this->CirculationNumber = 0; // Umlauf Nr. seit dem Start
}[/code:u5g7xwn5]

Was haltet ihr davon, wenn das euch passen würde mach ich das bei den anderen auch so.

mfg. pointhi


  
 
 Betreff des Beitrags:
Bist du dir sicher, das Klassifizierung auf Englisch "Klassification" heißt? Mir war so, als würde man es mit C schreiben.

Nicht, dass ich jetzt ein Nomenklaturen-Narr wäre, aber wenn du dich offensichtlich auf englische Variablennamen einigst, dann bitte auch konsequent :-)

73, Kim


  
 
 Betreff des Beitrags:
schon geändert :), den großteil hab ich mit googleübersetzer gemacht, nur da hab ich gedacht dass das richtig ist, werd wohl alles jetzt so machen, googleübersetzer ist nicht gut, aber bei so kurzen titeln kann man nicht viel falsch machen. Und ein wenig englisch kann ich auch, und muss es sowieso lernen.

mfg. pointhi


  
 
 Betreff des Beitrags:
[quote]Technisch sollte es funktionieren, nur was ist der sinn von einem zusätzlichen konstruktor. zurzeit wird alles auf 0 gesetzt, wenn ein objekt erstellt wird, und es sind zu viele variablen als dass ich alle schon mit dem konstruktor soubler setzen können. soll man eingeben können alles mit 1 zu initialisieren :)?[/quote]Wieso 1? Ich meinte, dass man ein Objekt tle direkt mit einer den zugehörigen TLE-Dateizeilen erzeugen kann anstatt erst ein tle-Objekt mit dem Standardkonstruktor und anschließend mit einem load-Aufruf.

Oder anderes Beispiel: ich habe eine Klasse Uhr, die u. a. eigene interne Felder hat für Stunden, Minuten und Sekunden. Wenn ich jetzt ein Uhr-Objekt erzeugen will, kann ich z. B. (in C#/Java-Schreibweise) folgendes machen:
Uhr uhr = new Uhr();
D. h. mein uhr-Objekt hat nach Erzeugung 0 h, 0m und 0s. (wenn wir annehmen, dass die Klasse Uhr 0-Werte standardmäßig setzt)
Jetzt stelle ich die Uhr ein:
uhr.Set(10, 46, 37);

Alternativ könnte ich einen zusätzlichen Konstruktor bei der Uhr-Klasse anbieten, der Stunden, Minuten und Sekunden annimmt. Die Objekterzeugung gestaltet sich dann einfacher:
Uhr uhr = new Uhr(10, 46, 17);

Inwiefern sich zusätzliche Konstruktoren in deinem Projekt anbieten (ich beziehe mich nicht speziell auf die Klassen tle und umlb), kannst du natürlich besser beurteilen. Die Erfahrung zeigt aber, dass zusätzliche Konstruktoren sowohl für den Anwender, als auch für den Programmierer einer Bibliothek viele Vorteile bieten.

Das ganze gilt natürlich nicht nur für überladene Konstruktoren, sondern auch für überladene Methodenaufrufe.


Zum Thema Benennungen fällt mir noch ein, dass ja die Felder der Klassen immer im Kontext zu sehen sind. Deshalb würde ich folgende Umbenennungen vornehmen:
SatelliteName -> Name (schon deshalb weil es nicht nur [i:eu46bbxw]echte[/i:eu46bbxw] Satelliten sind)
NoradCatalogNumber -> NoradNumber
EccentricityOfTheOrbit -> Eccentricity

Du hast InternatonalKlassification doppelt. Ist das Absicht? Weiterhin ist ein Schreibfehler enthalten, es fehlt ein i. Und: Es ist wohl eher Designation anstatt Classification gemeint.


Noch eine Kleinigkeit: Du definierst
const long double const_u = 3.986005e14; // Produkt aus Gravitationskonstante G und Masse der Erde

Da würde ich diese Konstante aus den beiden anderen Konstanten definieren (und natürlich sinnvoller umbenennen), also z. B. so:
const long double const_u = xyz * abc; // Produkt aus Gravitationskonstante G und Masse der Erde
Dann wird's klarer.

Alternativ könnte man natürlich beide Ursprungskonstanten separat definieren und dort, wo sie benutzt werden (in tle_to_umlb) auch separat verwenden. Würde ich sogar so vorziehen.


Zur Kommentierung, beispielhaft zu tle_to_umlb:
Du schreibst:
Übergabewerte: satpos::tle_data *ttu_tlein
Was will mir das sagen? Es ist schlechter Stil, wenn man als Kommentar das wiederholt, was eh im Programmcode steht. Guter Stil ist es, das möglichst aussagekräftig und unmissverständlich zu beschreiben.

Weiterhin würde ich nicht mit Angaben zu Einheiten und erlaubten Werten geizen. Z. B. bei den Winkeln oder den Widerstandskoeffizienten. Der Benutzer deiner Bibliothek wird es freuen.


Und noch etwas fachliches zu den TLE-Daten.
Beispiel Epoche: Ich würde 2 getrennte Felder für Jahr und Tag-Nummer nehmen.
Beispiel Classification: Der Buchstabe U wird wohl zwar immer gelten aber hier würde ich ein enum verwenden. Momentan ist eben nur ein bestimmter Wert möglich (ein "U"-Wert) aber wer weiß, ob das nicht irgendwann mal erweitert wird. Weiterhin hat das den Vorteil, dass man (versehentlich) nichts anderes als einen "U"-Wert eingaben kann. Ansonsten sollte eine Fehlermeldung kommen.

Beide Bespiele dienen dazu, die Klassen etwas "abstrakter" zu machen. Ansonsten wären sie eher nur eine 1 zu 1-Übertragung der TLE-Zeilen. Objektorientiert gesehen wäre das nicht so schön. Man will ja schließlich Bahnelemente (im Funkerdeutsch: Kepler-Elemente) verwalten und keine TLE-Zeilen.


  
 
 Betreff des Beitrags:
Kurz zur Programmierung: Initialisierung ist ein Dauerbrenner. Als "gebranntes Kind" würde ich grundsätzlich alle Variablen, die nicht 100pro vor oder mit dem ersten Aufruf als Ziel "gefüllt" werden, auf 0 initializieren (Type entsprechend). Das gibt im compiled Code eine kurze Init-Loop beim Start und führt nicht zu evtl. Problemen. Es gibt je nach Betriebssystem und Compiler bei der storage-allocation keine Garantie, daß die Felder alle auf 0 sind. Der Speicher wird vom BS dynamisch zugewiesen und muß durchaus nicht immer "jungfräulich" sein --- mit dem "herrlichen" Effekt, daß ein Programm mal richtig läuft und mal nicht -- zum debuggen eine Sisyphus-Arbeit.

Weiter: wenn ich schon double precision nutze, dann schreibe ich auch die Konstanten dazu mit 16 wertdarstellenden Ziffern (z.Bspl. PI). Den Code kann man immer wieder in anderen Programmen verwenden (kopieren). Man kann Konstanten auch mehrfach im Source als Konstante schreiben und muß nicht über Variable gehen (hat natürlich je nach Häufigkeit auch Grenzen). Konstanten werden von (vermutlich allen) Compilern in der Regel optimiert und (kann umdefiniert werden) in einer eigenen static section gesammelt, variable werden (in der Regel) mit etwas mehr Aufwand zur run-time eigens allocated, bei Unterprogrammen evtl. sogar mehrfach.

73 Peter


  
 
 Betreff des Beitrags:
[quote]Alternativ könnte ich einen zusätzlichen Konstruktor bei der Uhr-Klasse anbieten, der Stunden, Minuten und Sekunden annimmt. Die Objekterzeugung gestaltet sich dann einfacher:
Uhr uhr = new Uhr(10, 46, 17); [/quote]

das ist eine gute idee, wäre eigentlich nur ein konstruktor der die entsprechende funktion aufruft. Werde mal schauen wie man dass in c++ macht.

[quote]
Zum Thema Benennungen fällt mir noch ein, dass ja die Felder der Klassen immer im Kontext zu sehen sind. Deshalb würde ich folgende Umbenennungen vornehmen:
SatelliteName -> Name (schon deshalb weil es nicht nur echte Satelliten sind)
NoradCatalogNumber -> NoradNumber
EccentricityOfTheOrbit -> Eccentricity [/quote]

Bei der Eccentricity gibt es dann leider das problem dass es noch ein exzentrische Anomalie: wieder gibt,... Ich werde es jetzt ganz genau machen, dann können solche probleme nicht auftreten und ich kann mich auf wichtigeres als die Variabelnamen konzentrieren. Außerdem kann ich bei einer pre-alpha wohl ohne probleme die variablennamen von version auf nächste version ändern (halt bei den ersten 2-3mal), da der code sowieso noch nicht praxiserprobt, auf größere bugs getestet ist.

[quote]Noch eine Kleinigkeit: Du definierst
const long double const_u = 3.986005e14; // Produkt aus Gravitationskonstante G und Masse der Erde

Da würde ich diese Konstante aus den beiden anderen Konstanten definieren (und natürlich sinnvoller umbenennen), also z. B. so:
const long double const_u = xyz * abc; // Produkt aus Gravitationskonstante G und Masse der Erde
Dann wird's klarer. [/quote]

warscheinlich werde ich bei anderen berechnungen die gravitationskonstante oder die masse auch benötigen, und aktuelle compiler optimieren rechnungen ohne variabeln sowieso heutzutage schon problemlos. werde ich sicher übernehmen. Die aktuelle konstante hat natürlich nur die genauigkeit, wie sie in wikipedia angegeben ist. PI ist sowieso in der <maths> schon definiert.
[quote]
Zur Kommentierung, beispielhaft zu tle_to_umlb:
Du schreibst:
Übergabewerte: satpos::tle_data *ttu_tlein
Was will mir das sagen? Es ist schlechter Stil, wenn man als Kommentar das wiederholt, was eh im Programmcode steht. Guter Stil ist es, das möglichst aussagekräftig und unmissverständlich zu beschreiben.

Weiterhin würde ich nicht mit Angaben zu Einheiten und erlaubten Werten geizen. Z. B. bei den Winkeln oder den Widerstandskoeffizienten. Der Benutzer deiner Bibliothek wird es freuen. [/quote]

die komentierung werde ich einerseit in Eckige klammern als einheitenwert machen, anderseits werde ich eine übersicht aller befehle, klassen,... in mediawiki machen. Da kann man dann auch leichter ins detail gehen, als bei einem pdf möglich ist, und das ganze ist dann auch up to date.

[quote]Und noch etwas fachliches zu den TLE-Daten.
Beispiel Epoche: Ich würde 2 getrennte Felder für Jahr und Tag-Nummer nehmen.
Beispiel Classification: Der Buchstabe U wird wohl zwar immer gelten aber hier würde ich ein enum verwenden. Momentan ist eben nur ein bestimmter Wert möglich (ein "U"-Wert) aber wer weiß, ob das nicht irgendwann mal erweitert wird. Weiterhin hat das den Vorteil, dass man (versehentlich) nichts anderes als einen "U"-Wert eingaben kann. Ansonsten sollte eine Fehlermeldung kommen. [/quote]

Das mit der Epoche werde ich sicher übernehmen, das ist eine gute idee. Bei der classification hab ich 1. char zeichen genommen, da auser U noch 2 andere bezeichnungen aktuell exestieren. wenn jemand sie in eine enum haben will ist das wohl kein großer aufwand. und ich glaube nicht dass man diee bibliotek gleich updaten wenn eine neue bezeichnung exestiert :), sonst gibts auf einmal fehlermeldungen weil die bezeichnung unbekannt ist.

[code:3mr0cuwg]
enum classification{classification_u='U'};
[/code:3mr0cuwg]

sollte so funcen, da ascii ja auch nur ein zahlenwert ist.

[quote]
Beide Bespiele dienen dazu, die Klassen etwas "abstrakter" zu machen. Ansonsten wären sie eher nur eine 1 zu 1-Übertragung der TLE-Zeilen. Objektorientiert gesehen wäre das nicht so schön. Man will ja schließlich Bahnelemente (im Funkerdeutsch: Kepler-Elemente) verwalten und keine TLE-Zeilen.[/quote]

abstrakt ist sicher gut, aber die klasse tle hat allgemein den sinn die textdatei in einem für den computer leichter verständlichen variablensalat zu bringen, sonst bräuchte ich in jeder funktion lauter strinoperationen,...

[quote]Kurz zur Programmierung: Initialisierung ist ein Dauerbrenner. Als "gebranntes Kind" würde ich grundsätzlich alle Variablen, die nicht 100pro vor oder mit dem ersten Aufruf als Ziel "gefüllt" werden, auf 0 initializieren (Type entsprechend). Das gibt im compiled Code eine kurze Init-Loop beim Start und führt nicht zu evtl. Problemen. Es gibt je nach Betriebssystem und Compiler bei der storage-allocation keine Garantie, daß die Felder alle auf 0 sind. Der Speicher wird vom BS dynamisch zugewiesen und muß durchaus nicht immer "jungfräulich" sein --- mit dem "herrlichen" Effekt, daß ein Programm mal richtig läuft und mal nicht -- zum debuggen eine Sisyphus-Arbeit. [/quote]

Das wusste ich schon :), wegen soetwas sind auch die konstruktoren bei c++ da :)

Danke für die ausfürliche kritik/verbesserungsvorschläge

(firefox wier immer schlechter, bei diesem text ist er mir 3 mal!!! abgesürzt, zum glück blieb der text erhalten)

mfg. pointhi


  
 
 Betreff des Beitrags:
[quote]Bei der Eccentricity gibt es dann leider das problem dass es noch ein exzentrische Anomalie: wieder gibt[/quote]
... die ja erstens nicht zu den TLE-Daten gehört und die ich zweitens als Variable auch nicht eccentricity, sondern eccentricAnomaly nennen würde. ;-)


  
 
 Betreff des Beitrags:
stimmt auch wieder

werde einfach mal einen ersten entwurf der variablen machen, dann die variablen in den funktionen und dann kommen die ersten überprüfungsroutinen dann. Und die konstanten werde ich auch gleich definieren.

Die beiden bücher liegen auch schon auf meinem schreibtisch, hab sie heute bekommen.

mfg. pointhi


  
 

Elektronikforum Elektroshop PostgreSQL Forum