Wenn ich in Basecamp eine Route von x1 bis y1 in eine Liste speichere, und nun eine neue Route in derselben Liste anlege, wieder von x1 bis y1, dann macht Basecamp daraus x11 bis y11. Was wird da überschrieben?
Versuch doch den beitrag von wildgoose zu lesen und verstehen, anstatt kurse zu empfehlen...
... ich würde euch allgemein raten, erst einen Computerlehrgang zu absolvieren, bevor ihr euch mit Basecamp einlasst.
So nach und nach scheinen sich doch einige Dinge sehr geändert zu haben, die ihr mit euren alten Geräten und Betriebssystemen nicht mitbekommen habt.
Egal, auf welchen PC oder Gerät ich eine Datei mit schon vorhandenem Namen abspeichern will, sie wird angemeckert, und zwar unabhängig vom gerade verwendeten Programm.
Der springende Punkt ist aber der, daß alle Deine Beispiele sich auf ein *Dateisystem* beziehen. Und da war es schon immer so, daß es in einem Directory keine zwei Dateien (bzw. Directories) mit gleichem Namen geben durfte.
Wir reden hier aber nicht von einem Dateisystem, sondern von einer *Datenverwaltung*, auch wenn die baumartige Struktur ein Dateisystem suggeriert. Und hier kann ich - wie von einem Vorredner bereits ausgeführt - durchaus erwarten, daß ich gleiche Namen verwenden kann. Setzt natürlich einen eindeutigen (internen) Identifier in der zugrunde liegenden Datei (DB?) voraus. Und dazu braucht man keinen Computerlehrgang, sondern einfach nur einen Entwickler bzw. Planer, der sich nicht einfach hinstellt und sagt "das ist so", sondern mal über seinen Entwickler-Tellerrand schaut und die Sorgen und Nöte der *Anwender* ernst nimmt und versteht. Nicht jeder Anwender ist nämlich Computerspezialist bzw. Entwickler und weiß, warum das jetzt gerade so gelöst ist (bzw. gelöst werden muß). Wobei nicht zwangsweise der Entwickler "schuld" ist; oft ist es das Management, das es möglichst schnell und billig haben will und den Entwickler zu suboptimalen Lösungen zwingt.
Eigentlich ist das doch ganz normal daß eine eine neue Datei eine alte mit gleichem Namen überschreibt.
Du verwechselst da etwas!
Ich rede aber hier nicht von Dateien, ich rede von Geodaten in einer Applikation. CompeGPS, Fugawi, ESRI, GPSMapEdit, etc. haben mit Wegpunkten gleichen Names keine Probleme. Das ist im GIS Bereich so üblich, dass Elemente gleich heissen können. Auch in GPX Dateien sind gleichlautende Elemente erlaubt. Um bei Garmin zu bleiben: Selbst der POILoader seit der 2.5er Version lässt gleichlautende Wegpunkte zu und zeigt am GPS auch gleichlautende Wegpunkte an !!! Somit wissen wenigstens ein paar bei Garmin, wie der Hase läuft.
Und wenn du schon Geodaten mit Dateien verwechselst, die gleichlautende Namen haben, dann ignoriere nicht die Tatsache, dass ich von unterschiedlichen Listen (wäre bei Dateien unterschiedliche Verzeichnisse/Pfade) gesprochen habe. Somit wieder unlogisch.
lg, Paul
Habe eine GPX importiert, BC legt die Daten in eine eigene Liste unter "meine Sammlung".
Das habe ich wahrscheinlich falsch verstanden.
Wenn ich über "Datei - in (Listenname] importieren" eine Gpx-Datei lade pasiiert bei mir das was Voyager beschrieben hat: Ist irgendwo in meiner Sammlung schon ein Wegpunkt WP1 enthalten und in der importierten Gpx auch dann wird der neu importierte WP1 in WP11 umbenannt.
Es gibt allerdings auch in der Symbolleiste die Schaltflächen "... an das Gerät senden" und "Von Gerät empfangen...". Mir sind die jetzt erst in BC 4 aufgefallen, bisher gab es die glaube ich noch gar nicht. Wurden wahrscheinlich auf Drängen der eingefleichten Mapsource-Fans eingebaut.
Wenn ich mir mit diesem Sybol die Daten vom Gerät oder der Sd-Karte runterziehe passieren tatsächlich so seltsame Dinge wie du sie beschrieben hast.
Ich glaube mbrII hat gerade das gleiche Problem: http://www.naviboard.de/vb/showthread.php?t=53243
Es gibt allerdings auch in der Symbolleiste die Schaltflächen "... an das Gerät senden" und "Von Gerät empfangen...". Mir sind die jetzt erst in BC 4 aufgefallen, bisher gab es die glaube ich noch gar nicht.
Die sind tatsächlich neu. Braucht aber kein Mensch da die Funktion "Senden an" doch schon vorhanden war und ist.
Warum muss das denn doppelt zu aktivieren sein??? Für Analphabeten??
Nick
Ist irgendwo in meiner Sammlung schon ein Wegpunkt WP1 enthalten und in der importierten Gpx auch dann wird der neu importierte WP1 in WP11 umbenannt.
Ist ja auch technisch logisch, nur zum Arbeiten der blanke Horror...
Baue ich jetzt zB [neue Route], so dürfte man dabei keinesfalls einfach so einen neuen WP suchen/anlegen ohne zuvor die 'allwissende Müllhalte' namens [Meine Sammlung] zu durchsuchen ob der bt. WP denn nicht vor 4~5 Jahren schon mal angelegt wurde...
Die [Suche] unterstützt aber [Meine Sammlung] gar nicht... dabei müßte sie, wenn obige Logik korrekt', mit Priorität auf [Meine Sammlung], und erst wenn dort no result die Suche auf Kartenmaterial erweitern...
Eine Warenwirtschaft oder Kundenstammverwaltung schlägt ja auch bereits bei Eingabe im Suchfeld die in DB vorhandenen Einträge an...
Und bei meinem Nüvi30 issue läufts es sowieso etwas anders, da BC es mir eben nicht ermöglicht einen dieser WP001 direkt zu löschen...
Inhalt von /Geräte/Nüvi/Interner Speicher wird lediglich angezeigt, ist jedoch nicht editierbar...
Willst da rein, mußt mit [Senden/Empfangen] arbeiten...
Ist jetzt aber nur Detail am Rande, da IMHO BC sowieso nicht für diese Geräteachitektur gedacht, und somit das falsche Werkzeug...
Die sind tatsächlich neu. Braucht aber kein Mensch da die Funktion "Senden an" doch schon vorhanden war und ist.
Warum muss das denn doppelt zu aktivieren sein??? Für Analphabeten??
Nick
Nein für Mapsource User.
Keine Ironie, leider. Kunden sind ein Hemmschuh für Innovation, gute wie auch schlechte (Innovation). Siehe auch diesen thread...
Da die meisten MS user schon eine leicht seltsame nutzer ergonomie aufweisen (durch MS erzwungen), stellen sie ansprüche...ich kann mich noch erinnern, wie schwierig es war sich in die Garmin und MS Logik einzuarbeiten. Will ich jetzt, dass BC oder andere SW sich dem apassen? Nein, danke..
@ Voyager: Ich brauche da keine 3 Bugs aufzählen, es reicht schon, wenn BC meine Geodaten vernichtet/verändert. Dann kann ich auch nicht mehr weiterarbeiten.
Ich denke man sollte zw. Bug und einem "nicht verstandenen" Datenhaltungskonzept unterscheiden.
Bei BC hat man sich für ein aus dem Softwareprogrammieren , Daten- und Dokumentenmanagement, Mediendatenbanken bekanntes Konzept entschieden -> Objektorientierung. Ein Objekt (wie z.B. ein definierter, mit Geodaten beschriebener Wegpunkt) wird nur ein mal in dem System definiert aber/und mehrmals in verschiedenen Listen, Strecken, Strukturen ... benutz. Und ich würde frech behaupten (ohne das BC im Detail zu kennen), dass diese Mehrfachnutzung (sogenanntes "where used") kann für solche Objekte per Rechtsklick angezeigt werden.
Vorteil: habe ich etwas an dem Punkt korrigiert, ergänzt, wird es in allen Listen sichtbar - ich muss nicht jede einzelne Liste aktualisieren, wo der Punkt verwendet wird (und das ist auch der Sinn und Vorteil des Konzeptes)
Nachteil: wenn ich so einen gemeinsam genutzten Punkt lösche, dann greifen alle Listen, die diesen Punkt benutzen ins Leere
Und wenn ich Daten importiere, die solche in dem System bereits vorhandene Punkte aktualisieren, und den Hinweis darauf ignoriere, dann sollte ich mich über die Auswirkung nicht wundern.
Zum Thema eindeutiger Schlüssel: wenn ich zu faul bin meine definierten Punkte eindeutig zu bezeichnen und die Defaults ä'la Pt1, Pt2 akzeptiere, dann sollte ich mich nicht wundern, wenn die importierten Fremdtracks (von Autoren, die genauso faul waren wie ich und deren Punkte genauso "sinnvoll" bennant wurden wie meine -> Pt1, Pt2) meine Punkte mit den importierten Punkten überschreiben
Wenn man das verstanden hat, gibt es keine Probleme, denn dann handelt man auch entsprechend. Will ich ein Punkt nur für eine spezifische Liste/Track/.. abwandeln, muss ich verständlicherweise zuerst ein Duplikat des "allgemeinen" Punktes anlegen, dieses Duplikat modifizieren und dann in der speziellen Liste zuordnen/ersetzen.
Also, das meiste lässt sich durch Mitdenken erledigen, man muß nur so mitdenken, wie sich die Programmierer von BC das ganze konzeptionel ausgedacht haben.
Es sieht so aus, als ob dieses Konzept (und daraus resultierende vermeintliche "Bugs") die wenigsten verstanden haben
Und bevor hier eine Lavine von Gegenstimmen kommt, gebe ich ein vergleichbares Beispiel dass dieses Konzept absolut selbstverständlich und verbreitet ist -> siehe Fotoverwaltungsysteme wie iPhoto, iMatch, LR, und hunderte von anderen
Ein Foto existiert physikalisch nur ein mal in der DB/auf der Festplatte, aber es wird mehreren Alben/Kategorien zugeordnet (Geburtstage, Orte, Personen, Jahre,...).
Wird es verändert, erscheint es in allen Alben/Kategorien verändert.
Wird es gelöscht, fehlt es in allen Alben/Kategorien.
Will ich das Foto nur in einem bestimmten Album verändern, muss ich eine Kopie des Fotos anlegen.
Wenn ich (trotz Warnung!) ein Foto vom Kumpel auf die Festplatte einspiele, das zufällig genauso heist wie eins meiner Fotos, dann wundere ich mich nicht, dass es meins ersetzt hat!!!
So einfach ist es...
ZitatKunden sind ein Hemmschuh für Innovation
Innovation braucht keine Kunden, eher Menschen mit Vision!
Angeblich Henry Ford (erfinder des Ford T) hat gesagt:
Hätte ich die Kunden danach gefragt, was sie sich wünschen, würden sie antworten "ein schnelleres Pferd"
Die meisten Kunden haben keine Ahnung was sie wollen, das einzige was sie einigermassen wissen ist was sie nicht wollen - nach dem Moto: "ich habe keine Ahnung wie, aber so nicht.."
Ich nenne es Motzen 
Zum Thema eindeutiger Schlüssel: wenn ich zu faul bin meine definierten Punkte eindeutig zu bezeichnen und die Defaults ä'la Pt1, Pt2 akzeptiere, dann sollte ich mich nicht wundern, wenn die importierten Fremdtracks (von Autoren, die genauso faul waren wie ich und deren Punkte genauso "sinnvoll" bennant wurden wie meine -> Pt1, Pt2) meine Punkte mit den importierten Punkten überschreiben
Aus der Praxis scheinen solche markigen Sprüche aber nicht zu kommen, oder? Niemand spammt sich gerne den Bildschirm vom GPS mit exorbitant langen, aber eindeutigen Wegpunktnamen zu. Maximal ein Buchstabe für die Kategorie des Punktes und eine Laufzahl für jedes Projekt von 1 angefangen. Details stehen im Kommentar. Und dann hat man viele Wegpunkte mit gleichem Namen. Und, nein, mit einem eindeutigen Schlüssel ist das überhaupt kein Problem. Und, ja, es gibt Software die das konsequent richtig macht.
Also quatsch uns hier nicht voll mit "zu faul" und "zu dumm". Hier sind ein paar Leute unterwegs die schon lange GPS Geräte in der Praxis einsetzen und wissen was sie wollen. Und es gibt auch welche, die selber zu diesem Thema programmieren und wissen was möglich ist.
Das nenne ich ja mal einen gelungen Foreneinstieg in nur 2 Beiträgen.
ZitatWenn du 2 Ordner mit Urlaubsphotos hast, Ordner Urlaub A und Urlaub B, und du löscht dann Bilder aus Urlaub A, so wird der Ordner Urlaub B nicht angerührt. Egal, was da drinnen ist. Logo. Für BaseCamp aber nicht logo.
Für BC ist es Logo nur für Dich nicht - Du hast es noch nicht verstanden und falsches, upassendes Beispiel genannt -> Du schreibst doch selbst, dass Du die Fotos physikalisch ZWEI MAL vorhanden hast, ein mal in Ordner Urlaub A und ein mal im Ordner Urlaub B (und nicht in beiden Ordner ein und das gleiche Foto, was BTW unter Unix und MacOS per Symbolic oder Hard Links möglich wäre)
Wenn du in BC ein Duplikat anlegst (also ein "physikalisch" getrenntes Objekt -> ähnlich wie deine getrennte Fotos) dann kannst du auch in BC das erste Objekt löschen/ändern, ohne dass das zweite Objekt verschwindet oder sich verändert!!
ZitatNebenbei, warum können Fugawi, CompeGPS Land und TwoNav, TTQV, Ozi, ESRI etc. das alles???
Können sie alles? Nutzen sie auch den relationalen Ansatz? Oder doch redundante (duplizierte) Objekte?
Wenn sie doch das alles können, wozu brauchst Du noch das BC?
ZitatUnd es gibt auch welche, die selber zu diesem Thema programmieren und wissen was möglich ist.
Dann haben sie auch die Logik/Funktionsweise von BC problemlos verstanden bzw. hätten es auch ohne meine Aufklärung wissen müssen 
ZitatDas nenne ich ja mal einen gelungen Foreneinstieg in nur 2 Beiträgen.
Danke
So einfach ist es...
Richtig. Sofern man etwas von den Hintergründen versteht. Tun aber nicht alle, weil nicht alle Informatiker/Programmierer sind. Dagegen hilft, daß man es den nicht-Experten *erklärt*. Und genau das macht Garmin leider nicht. Sondern wirft den ("armen") Anwendern eine Software vor die Füße und die müssen dann damit zurecht kommen.
Ich arbeite selbst seit vielen Jahren in de EDV und befasse mich auch ebenso lange mit Benutzer-Oberflächen. Stichwort für eine gelungen Oberfläche ist "Erwartungskonformität", d.h. ein Programm muß (soll) sich so verhalten, wie ich es erwarte. Da hat Microsoft jahrelang daran rumgedoktert, weil sie es nicht geschafft haben, gleiche Funktionen gleich zu benennen und in die gleichen Menüs zu packen (seit einiger Zeit paßt das jedoch). Eine *Datenbank* spielt jedoch in einer ganz anderen Liga. Und da das Konzept zu erklären ist nicht ganz einfach. Du hast es schön dargestellt, aber die Anworten auf Deinen Beitrag zeigen sehr schön, daß es trotz eindeutiger "Sachlage" nicht einfach ist, das den Leuten zur vermitteln.
Basecamp ist eine kostenlos erhältliche Software !
Wegen der ungestümen Bibilothek rauchen bei mir hin und wieder die Import- und Exportknöpfchen. Scheint mir im Moment die sicherste Methode die eigenen Daten verwalten zu können. So habe ich für einzelne Touren separierte gpx-Files an denen Basecamp nichts verändern kann.
Gruß
Wolfgang
Dann haben sie auch die Logik/Funktionsweise von BC problemlos verstanden bzw. hätten es auch ohne meine Aufklärung wissen müssen
Eben weil die Logik und Funktion verstanden wurde, kommen wir zu dem Ergebnis dass die Datenbankimplementierung von Basecamp blem-blem ist. Wer die Identität eines Datenobjektes am Klarnamen des Objektes festmacht hat doch eine Macke. Das ist zwar aus dem historischen Datengewurstel bei Mapsource und den alten Geräten irgendwie verständlich, aber man muss doch nicht jeden Designfehler mit in die nächste Softwargeneration schleppen. Da hat bei Garmin jemand eine schlechte Entscheidung getroffen, oder geschlafen. Jetzt dem Benutzern vorzuwerfen, sie hätten es einfach nur nicht verstanden ist dreist.
Aber wer sich nicht gerade mit kommerziellen Garminkarten an Mapsource oder Basecamp gebunden hat, kann ja auch anders.
trailsurfer Wir wissen doch, dass es nichts kostenlos bei Garmin gibt. Basecamp wird über die Geräte und Kartenprodukte finanziert.
Damit es klar ist, es ist nicht meine Intention das BC schönzureden (dafür bin ich zu lange in dem IT Geschäft tätig, um zu wissen, dass es keine perfekte Software gibt). Aber ich habe etwas dagegen, dass die rudimentärsten Anwenderfehler auf Softwarebugs geschoben werden -> die einfachste Lösung solcher "Bugs" ist immer noch RTFM. Dafür gibt es aber meistens keine Zeit/Lust. Heutzutage will jeder (kostenlos) runterladen, installieren und sofort loslegen, Handbuch Lesen barucht man nicht
20 Jahre IT Berufserfahrung sagen: in 95% der Fälle sitzt der Software Bug vor dem Computer
Damit es klar ist, es ist nicht meine Intention das BC schönzureden (dafür bin ich zu lange in dem IT Geschäft tätig, um zu wissen, dass es keine perfekte Software gibt). Aber ich habe etwas dagegen, dass die rudimentärsten Anwenderfehler auf Softwarebugs geschoben werden -> die einfachste Lösung solcher "Bugs" ist immer noch RTFM. Dafür gibt es aber meistens keine Zeit/Lust. Heutzutage will jeder (kostenlos) runterladen, installieren und sofort loslegen, Handbuch Lesen barucht man nicht
20 Jahre IT Berufserfahrung sagen: in 95% der Fälle sitzt der Software Bug vor dem Computer
Hm, mit dieser Einstellung bekommt man dann Software wie Basecamp.
ZitatNachteil: wenn ich so einen gemeinsam genutzten Punkt lösche, dann greifen alle Listen, die diesen Punkt benutzen ins Leere
Und übrigens nochmal zu deinem Löschbeispiel: Wenn ich ein Objekt in einer Liste A und einer Liste B habe, dann sind das bei einer relationalen Datenbank einfach zwei Relationen. Wenn der Benutzer das Objekt aus der Liste A löscht, heißt das mitnichten, dass das Objekt gelöscht wird und Liste B ins Leere läuft, sondern nur das die Relation gelöscht wurde. Und wenn der Benutzer auch noch die Relation in Liste B löscht, heißt das noch immer nicht zwingend, dass das Element gelöscht werden muss. Es wird nur nicht mehr referenziert und sollte jetzt auf einer Müllhalde landen. Und wenn es von dieser Müllhalde entfernt wird ist es weg. So wird ein Schuh draus. Und so ist es auch für den Benutzer nachvollziehbar. Alles klar Herr 20 Jahre IT Experte?
