BaseCamp 3.3.0.3 Beta (Windows)

[JaVaWa]

Tja, maar in BaseCamp kan er maar één waypoint met de naam "knooppunt 10" zijn, waar ook ter wereld...
Daarnaast kunt je ook nog een route "knooppunt 10" hebben en/of een track met dezelfde naam; de "uniekheid" geldt dus per soort item.

[Scheurneus]

Je kan bvb 2 keer knooppunt 10 hebben als de ene in zuid holland ligt en de andere in noord holland

Het feit dat er dubbel knooppunten in NL bestaan is eigenlijk nog veel vreemder

[elsinga]

Binnen kaartmateriaal gelden heel andere beperkingen. Net zoals binnen POI bestanden, daar kun je een "oneindig" aantal punten hebben met dezelfde naam ("boei" of "bos' bijvoorbeeld).

[Scheurneus]

BaseCamp 3.3.0.3 Beta available - zie eerste posting voor link en release notes.

[mac_l]

Beta gedownload en wat aan het proberen.

Ik wordt steeds enthousiaster over BC. Ik laat MS nog niet helemaal los maar dat gaat er wel van komen.
De mappenstructuur is een hele grote stapin de goede richting en ik maak daar dankbaar gebruik van

Al doende kom Ik erachter dat mijn database inmiddels flink vervuild is geraakt met allerlei onbedoelde kopieen en verdere zooi. Ik ben daarom aan het opruimen geslagen.
Het uitgebreide informatie schermpje met de tab ''list'' is daarbij reuze handig.
Ik mis nog wat verdere database hulpmiddelen om op te schonen.
Het kan zijn dat ik die nog niet heb gevonden:

- Het filter van alle zaken die in GEEN lijst voorkomen.
- Het kunnen zoeken of filteren op dubbele namen.
- Het zelf kunnen toevoegen/rangschikken van kolommen in het "data scherm".
- Het ook kunnen filteren van data wanneer het datascherm links onder klein is weergegeven.

Wellicht zijn enkele van deze functies gewoon beschikbaar.
Zo niet dan laat ik mijn wensen/suggesties bij Garmin op het forum achter.

[++ Lex ++]

Echte dubbele namen komen niet voor doordat BC de namen uniek maakt door het toevoegen van volgnummers.

Kolommen in het datascherm kun je niet toevoegen, maar wel rangschikken; je kunt ze verslepen.

Een filter van zaken die in GEEN lijst voorkomen zou inderdaad handig zijn. Door altijd te werken in een lijst, desnoods een kladlijst, kun je deze wezen voorkomen, tenminste zolang je je niet vergist bij het wissen: altijd delete en nooit remove als je compleet wilt verwijderen.
Niettemin kun je deze GEEN lijst-zaken met enige arbeid wel verwijderen zonder alles individueel na te lopen:
1. Maak een back-up.
2. Verwijder alle lijsten met hun inhoud.
3. Exporteer de overgebleven zaken; dit zijn de wezen. Controleer wel of je ze echt wilt verwijderen.
4. Herstel de database.
5. Importeer het wezenbestand.
6. Verwijder deze lijst met inhoud.

[Scheurneus]

- Het ook kunnen filteren van data wanneer het datascherm links onder klein is weergegeven.

Kan wel, zie tandwieltje rechts onderin het datascherm

[mac_l]

Kan wel, zie tandwieltje rechts onderin het datascherm

Gevonden! Handig!

Bedankt

[mac_l]

1. Maak een back-up.
2. Verwijder alle lijsten met hun inhoud.
3. Exporteer de overgebleven zaken; dit zijn de wezen. Controleer wel of je ze echt wilt verwijderen.
4. Herstel de database.
5. Importeer het wezenbestand.
6. Verwijder deze lijst met inhoud.

Je hebt gelijk Lex. Met zorgvuldig werken is vervuilen van de database te voorkomen.
Maar ja, veel ellende stamde uit een tijd dat ik nog niet zo handig was.
En buiten dat: een vergissinkje is wel heel snel gemaakt.

Een en ander resulteerde in een backup van 70 Mb.
De ge-exporteerde wezen vertegenwoordigden 20 MB.
Bijna alles weggegooid.
Dat was de moeite waard.

Wel crashtte basecamp een aantal keren na het (overigens wel succesvol) importeren van een .gdb of .gpx.
Heb fout rapporten gestuurd. Daarvoor is het een beta...nietwaar?

[++ Lex ++]

En buiten dat: een vergissinkje is wel heel snel gemaakt.

Precies mijn ervaring: even een onbedoeld klikje en je hebt alweer een waypoint of een route.
Als je niet in een lijst werkt verdwijnt hij snel in de massa en valt hij niet op.
En zelfs als je wel in een lijst werkt is een logische reactie: delete-toets. En toen was er weer een wees bij.
Sinds ik me hiervan bewust ben werk ik altijd in lijsten zodat je makkelijker kunt zien dat je er rommel hebt bijgemaakt. En dan verwijderen via rechts klikken en verwijderen. Nu gebeurt het me nog maar zelden dat ik me vergis en er toch vervuiling optreedt.

[mac_l]

En buiten dat: een vergissinkje is wel heel snel gemaakt.

Precies mijn ervaring: even een onbedoeld klikje en je hebt alweer een waypoint of een route.

De delete/remove is één.
Het maken van onbedoelde kopieen is een ander.
Er ontstaan wel heel makkelijk meerdere kopieen van dezelfde route of track die alleen in de naam verschillen met het toegevoegde volgnummer.
Daar zou toch functionalitieit kunnen worden toegevoegd om dat te voorkomen.

Vragen om bevestiging bij importeren bijvoorbeeld.
"deze bestaan al onder die naam, weet u het zeker?" of zoiets.
Of zoekfuncties op duplicaten die het opruimen vereenvoudigen.

[++ Lex ++]

Hoe bedoel je dat? Als je een track importeert die al bestaat houdt hij de bestaande naam. Alleen als de tracks niet identiek zijn wordt de naam aangepast om te voorkomen dat er een dubbele naam ontstaat, maar dan gaat het niet om een kopie.

Het is zelfs zo dat als je een track importeert naar het eerste vrije volgnummer gezocht wordt, en als daarbij een identieke track gevonden wordt dit ook de naam van de nieuw geïmporteerde track wordt.

[mac_l]

Ik heb dat nu geprobeerd en daar heb je gelijk in (uiteraard ).
Als ik nu een import doe worden er geen ongewenste kopieen gemaakt van bestaande routes.

Toch heb (had) ik diverse ongewenste kopieen die ogenschijnlijk identiek zijn.
Die zouden kunnen stammen uit een periode met een oude BC versie die die import checks niet zo goed deed.....
Ik heb ze zeker niet handmatig een voor een gemaakt.
Wisselen tussen MS en BC en daarbij versie verschillen misschien nog als oorzaak?
Gebruik van afwisselend .gdb of .gpx?
Is niet meer te achterhalen vrees ik.

Met een opgeruimde database ga ik maar eens kijken of die nu opgeruimd blijft.

[++ Lex ++]

Hoe BC constateert of een track identiek is weet ik niet, maar ik vermoed dat er in de bestanden een code staat die bij elke wijziging gewijzigd wordt; dit kan een tijdstempel zijn.
En als er daarbij iets mis ging bij de oude versies is dat inderdaad een verklaring voor het bestaan van je kopieën.
Een andere mogelijkheid is dat je ongemerkt een minieme wijziging hebt aangebracht.

[++ Lex ++]

Hoe BC constateert of een track identiek is weet ik niet

Inmiddels weet ik het wel: Het werkt, anders dan ik veronderstelde, niet met een code.
Na het bijplaatsen en weer wissen van een extra trackpunt wordt de track toch herkend als identiek met de ongewijzigde track. Kennelijk worden de tracks nagelopen tot er een verschil gevonden wordt. Meestal zal dat vrij snel zijn; alleen als ze identiek zijn moet het hele bestand vergeleken worden.

Die wijzigingen kunnen ontstaan zijn door een onbedoelde klik. Ik kan me ook voorstellen dat oudere versies de bestanden een beetje anders opsloegen, bijvoorbeeld met een ander aantal decimalen. En dat zou dan weer heel goed kunnen betekenen dat de tracks als verschillend worden gezien.