BaseCamp blem-blem

Lies Dich mal durch das Werksforum von Garmin-Basecamp : https://forum.garmin.de/forumd…e-Basecamp-amp-MapInstall. Was dort auch von eingefleischten Befürwortern schöngeredet wird, ist abschreckend. Überwiegend werden dort aber Mängel der Beta 4.0.1 aufgezeigt, die nur eine Schlußfolgerung zulassen : Dort programmieren mit verlaub gesagt verbohrte Betonköpfe. Die sind von ihrer Strategie nicht abzubringen, aber auch noch unfähig genug, mit Betas die letzten Befürworter zu verschrecken. Basecamp wandelt sich, wird komplizierter und ich vermute fast, dass die selbst nicht mehr durchblicken. Sonst sollten solche haarsträubenden Probleme, die neuesten Topo Pro werden nicht mehr erkannt usw., wie im Werkforum berichtet, nicht vorkommen. Solange ich keine Rasterkarten brauche, spar ich mir weitere Mühe mit BC. Vielleicht ist es in einigen Jahren mal zumutbar.

Zitat von Voyager

...

Zitat von morgen1

Dort programmieren mit verlaub gesagt verbohrte Betonköpfe.

Bewirb Dich doch bei Garmin als genialer Programmierer!

Ich ärgere mich auch über etwas obskure Ansichten und Programmierungen bei Garmin. Aber Programmierung ist i.d.R. recht komplex. Dazu kommt, daß Programmierer oft nicht die Zeit bekommen für ihre Programme, die sie eigentlich benötigen. Und dann ist da noch die praktisch nicht vorhandene Qualitätssicherung. Eine seriöse Firma liefert kein Programm ohne QA aus (ich hab vor 27 Jahre selbst in so einem Bereich angefangen und gearbeitet). Die Krux ist in aller Regel, daß Programmierer ihre eigenen Denkweise haben und selten anwenderorientiert denken. Wenn denen keine rsagt, wo's lang geht, dann kann man's vergessen. Beispiele dafür kann ich - gerade am Beispiel Garmin - zuhauf nennen.

Trotz allem würde ich Programmierer nicht Beton- oder Schwachköpfe nennen (Grund: s.o.). Der Entwickler von BC ist sehr engagiert und kümmert sich im Gegensatz zu anderen Entwicklern bei Garmin wirklich um Anwenderwünsche. Im Garmin-Forum ist er präsent und diskutiert mit (hier teilw. auch). Das kenne ich von anderen nicht.

Zu Deinem Problem: Solange BC nicht mit einer richtigen Datenbank arbeitet sondern mit einer xml-Struktur, wird es immer Konflikte mit Bezeichnungen geben. Aber eine Umstellung auf eine DB kostet Zeit und muß vom Management auch gewünscht und genehmigt werden. Spätestens da liegt der Hase im Pfeffer!

Ich hoffe das ihr alle abgestimmt habt.

Zitat von Handi

Solange BC nicht mit einer richtigen Datenbank arbeitet

tuts das nicht? Wenn ich das mit einem Resource viewer ansehe sehe ich durchaus eine SQL-lite Datenbank, die integriert ist.

Zitat von wildgoose

Tja, ist traurig und schade. Weder bei Compe noch bei Fugawi ist mir sowas passiert wie mit BC. Aber zum Glück gibts ja MapSource, welches noch lange mein Hauptplanungstool bleibt.

lg, Paul

Was du da gefunden hast ist in der tat ein peinlicher bug. Nur, wie schaust du dir "schnell" alle deine track/routen in einer region an mit mapsource? Gerade da hat bc einen vorteil. Wg ähnlicher probleme wie du, benutze ich bc zwar zur planung, öffne aber alle gpx die ich runterlade per default in ms. So kommen mir nur "saubere" und bereingte daten ins bc. Umständlich...
Hast du das im Garmin Forum gemeldet?

...und es gibt eine backup funktion in bc...

Zitat von AndreasL

tuts das nicht? Wenn ich das mit einem Resource viewer ansehe sehe ich durchaus eine SQL-lite Datenbank, die integriert ist.

Ok, ich hab mich von der Endung "gdb" verwirren lassen
Aber Falagar hat ja selbst geschrieben, daß gleiche Name für Objekte in unterschiedlichen Ordnern erst mit einer (relationalen?) Datenbank möglich sein werden.

Zitat von Handi

...Eine seriöse Firma liefert kein Programm ohne QA aus (ich hab vor 27 Jahre selbst in so einem Bereich angefangen und gearbeitet). Die Krux ist in aller Regel, daß Programmierer ihre eigenen Denkweise haben und selten anwenderorientiert denken. Wenn denen keine rsagt, wo's lang geht, dann kann man's vergessen. Beispiele dafür kann ich - gerade am Beispiel Garmin - zuhauf nennen.

Trotz allem würde ich Programmierer nicht Beton- oder Schwachköpfe nennen (Grund: s.o.). Der Entwickler von BC ist sehr engagiert und kümmert sich im Gegensatz zu anderen Entwicklern bei Garmin wirklich um Anwenderwünsche. Im Garmin-Forum ist er präsent und diskutiert mit (hier teilw. auch). Das kenne ich von anderen nicht!

Ich zweifle in keinster Weise am IQ und auch nicht an den handwerklichen, programiertechnischen Fähigkeiten der Programmierer. Mit 'Beton-kopf' meine ich aber, das die ein allerseits auf Unverständniss stoßendes Konzept der Datenverwaltung beibehalten. Und dieses Konzept nicht programmiertechnisch sauber hinbekommen. Auch für anfängliche Bugs's habe ich Verständniss, nur langsam sollten die mal weniger werden, Stattdessen tauchen aber in jeder neuen Version weitere auf. Der Leistungsumfang wird aufgebläht mit neuen Menüs, die nur Wenige wirklich brauchen, nur besser zu bedienen ist es nicht und prinzipielle Bugs, wie die vom Wildgoose geschilderten bleiben drin. Da muß ich voll zustimmen :

Zitat

Wenn denen keine rsagt, wo's lang geht, dann kann man's vergessen. Beispiele dafür kann ich - gerade am Beispiel Garmin - zuhauf nennen.

Ich denke auch, die benutzen ihr eigenes Progranmm zu wenig selbst, sonst würden die doch selbst auf die Ungereimtheiten stoßen.

Zitat von morgen1

Ich denke auch, die benutzen ihr eigenes Progranmm zu wenig selbst, sonst würden die doch selbst auf die Ungereimtheiten stoßen.

Sag' das nicht, die verwenden es wahrscheinlich und sind glücklich damit weil nur sie die schräge Bedienung "können".

BC hat 2 Gesichter: einerseits geniale Features drin und gleich daneben die totale Sche..se. Habe heute mit der 4.0.1 meine Tour auswertet, bearbeitet, archiviert usw. Beispiel gefällig: 630 km Track gewandelt in Route für zukünftiges abfahren==> perfekt. Dieselbe Route umgedreht ergibt 22 Tkm Strecke, der komplette Unfug. Licht und Schatten dieses Programmes bringen mich noch zur Verzweiflung. Da schont MS noch die Nerven, auch wenn es einiges nicht kann, den Rest dafür aber fehlerfrei.

@ wildgoose - zugegeben der überschreib-bug in bc ist heftig. Aber auch bei ms ist am ende nie klar welche gpx datei du nun sicherst und es kann ebenso geschehen, dass du files ungewollt veränderst...hast den bug übrigens im us forum gemeldet?

Ich sehe es so wie morgen1...

In meinen Augen hätte Basecamp 4 wirklich ein schönes Program werden können.
Leider hat sich Garmin aber wahrscheinlich zusehr auf die (für mich sinnlosen) Adventures konzentriert und sich dafür etliche "NoGos" geleistet. Brauchen wir wirklich neben Gpsies, Outdooractive, Garmin Connect, Gipfelbuch, Gps Tour Info, Breadcrumbs usw noch so ein Exhibitionisten-Portal???

Wenn man sich verscheidene Programme so anschaut (Kompass digital, Magic Maps, QLandkarte, Basecamp ..) dann arbeiten doch alle so ziemlich nach dem gleichen Prinzip. Meist steckt in irgendeiner Form ein SQLite-Datenbank dahinter.
Mit der Struktur von Basecamp sollten eigentlich die Pinguine noch am besten zurechtkommen. Alle Ordner und Dateien ("Listen") hängen untereinander in der selben Root ("Meine Sammlung") und werden bei Bedarf gemountet. Alerdings gibt es Basecamp ausgerechnet für Linux nicht.
Die SQLite-Datenbanken finden auch bei Branchensoftware immer größere Verbreitung. Irgendwann wird auch mein Bildbearbeitungs- oder Tabellenkalkulationsprogramm mit solch einer Datenbank arbeiten. Früher oder später wird man sich sowieso dran gewöhnen müssen.

Eigentlich ist das doch ganz normal daß eine eine neue Datei eine alte mit gleichem Namen überschreibt. Wenn ich ein "Bild.jpg" in einen Ordner speichere in dem bereits ein Bild.jpg vorhanden ist dann ist das alte Bild weg. Wenn ich ein "Brief.doc" in einen Ordner speichere in dem bereits ein Brief.doc vorhanden ist dann ist der alte Brief weg.
Und wenn ich eine "Matterhorn.gpx" in meine Sammlung speichere in der bereits eine Matterhorn.gpx drin ist dann verschwindet auch mein altes Matterhorn. Ist in dem Fall zwar immer noch besser als wie wenn ich auf einmal 5 Matterhörner in meiner Sammlung hätte.

Das liegt jetzt noch nicht mal an Basecamp oder Garmin. Hat auch nicht mal was mit Windows zu tun, ist bei allen anderen Betriebssystemen doch das Gleiche.

Aber:
Da bekomme ich wenigsten eine Warnung das bereits eine solche Datei vorhanden ist und ob ich sie wirklich überschreiben will. Meist wird mir angeboten die Datei umzubenennen.
Herrgott, das dürfte doch hoffentlich nicht allzu schwierig sein daß Garmin das mal auf die Reihe bekommt?!

Ich finde es nicht normal, wenn ein Wegpunkt mit dem Namen "Wpt1" einen anderen mit dem Namen "Wpt1" überschreibt Ich sehe aber bei dem ganzen Geodatenzeugs eine riesen Schwäche, die meiner Meinung nach von der verkorksten GPX Definition stammt. Es fehlt bei der Spezifikation für jedes Element ein Feld für einen eindeutigen Schlüssel. Damit könnte man jeden Punkt, Track oder was auch immer eindeutig identifizieren.

Fehlt bei allen mir bekannten Herstellern. QLandkarte hat so einen Schlüssel und versteckt den in der GPX Datei (<extensions>) und auch in den WPT und TRK Dateien von TwoNav. Damit werden alle Element wieder erkannt, keines dupliziert und keines überschrieben. Das gilt natürlich nicht für Elemente die auf den Geräten erstellt wurden.

Naja und sicher, eine echte Datenbank ist schon was Feines. SqLite ist ganz nett weil einfach. Hat aber auch irgendwo seine Grenzen, wenn es viele Daten werden. Und es gibt auch bei QLandkarte Nutzer, die mit den Ideen hinter einer Datenbank nicht zurecht kommen, weil sie in ihrer Denke zu sehr auf ein Dateiverzeichnis fixiert sind. Allen kann man es nicht recht machen.