Lex

En ik in mijn onschuld maar denken dat onze GPS-ontvangers waterdicht zijn, zodat een plastic hoesje niet nodig is, ook niet voor kwijl........ :0

Ik heb Mapsource City Select v4.00 zoals die is meegeleverd met de GPS V (met Benelux + Frankrijk). Achteraf heb ik de rest van west-Europa (Duitsland, Zwitserland, Oostenrijk, Groot-Brittannië, Ierland, Spanje, Portugal, Italië, Denemarken en zuid-Zweden) erbij gekocht voor ca. €200. Het is niet overal helemaal op straat-niveau, maar heel vaak wel, ook met huisnummers.

Het gaat mij om mensen, zoals ik, die niet in de Benelux wonen, maar verder in veel opzichten Nederlands, c.q. Belgisch of Luxemburgs, zijn. Dat is dus wel een probleem waar over nagedacht moet worden als je een lijst op basis van nationaliteit van de vinder wilt maken in plaats van op basis van de ligging van de caches.

Bedankt Mumzle, dat ik in ieder geval op jouw lijst zou mogen staan. Maar daar zit het probleem niet. Jij bent voorstander van een lijst van in Nederland gevonden caches, gevonden door wie dan ook. Dit is het systeem van de Dan Millerlijst. En van een cache is bijna altijd wel duidelijk of hij in Nederland ligt of niet. Maar anderen, zoals Krix, willen een lijst van alle caches, waar dan ook, gevonden door Nederlanders. En daar zit mijn probleem, wie telt in dit verband als Nederlander?

Er wordt hier steeds gesproken over Nederlanders. Maar wat is een Nederlander in dit verband? 1. Iemand die in Nederland woont? 2. In Nederland is geboren? 3. Een Nederlands paspoort heeft? 4. Nederlands spreekt en schrijft zonder al te veel fouten? 5. Zich ingeschreven heeft bij geocaching.nl? En hoe controleer c.q. beoordeel je dat? Daar zou toch ook eens over moeten worden nagedacht voor er lijsten met 'Nederlanders' worden aangemaakt. Ik voldoe niet aan 1, wel aan 2, 3 en 5, en denk ook wel aan 4 te voldoen. Maar mag ik meedoen? Overigens zou ik in de competitie hoogstens strijden om de laatste plaats, wegens het gebrek aan caches in mijn omgeving. Edited By lex on sept. 03 2002 at 16:16

Niet met opzet hoor. Ik ben verhuisd, maar mijn telefoon nog niet, daarom lees ik dit forum een beetje gehaast in mijn oude huis. Ik heb je verwijsregel niet herkend, er staat veel meer in dan in het adres van de betreffende pagina (http://www.hydro.nl/articles/artikel2_nl.htm). Ik snap niet wat dat allemaal is. En ik ben waarschijnlijk te lui om een niet-aanklikbare verwijzing altijd te gebruiken. ??? Alleen in Z-N-richting is het 1852 m. In Nederland varieert 1' in W-O-richting van 1172 m in het zuidelijkste tot 1102 m in het noordelijkste gedeelte van het land. Edited By lex on aug. 23 2002 at 10:04

Decimale graden is iets anders dan decimaal verdeelde minuten, zoals in het citaat. Decimale graden (gr) zijn graden van 400 gr in een cirkel, een rechte hoek is dus 100 gr. 1 gr langs de meridiaan (dus Z-N)gemeten = 100 km. Langs de evenaar is 1 gr ook gelijk aan 100 km, maar langs alle andere parallelcirkels (W-O) is het minder (100*cos( km, waarin b de breedte is waarop je je bevindt). Voor gewone graden geldt hetzelfde, maar dan moet i.p.v. 100 km 111 km worden genomen. 1 minuut langs de meridiaan of evenaar is dan 1852 m, dat is 1 zeemijl (en niet toevallig). 0.111' uit het voorbeeld is dus 206 m als het in Z-N-richting is. Maar in O-W-richting is het dus minder. Kortom, m-coördinaten werken handiger, maar de beperking is dat de vertekening van de kaarten te groot wordt als een groter gebied wordt afgebeeld, en dan kan het niet meer.

Zeer informatief om het verschil te leren tussen het datum en coördinaten is dit artikel van de Dienst der Hydrografie van de Marine. Ja, HET datum, dat heb ik hier geleerd. Met dank aan Waterboys voor de verwijzing, die nogal verstopt zit in 'Off topic'.

Een kleine vergissing in een goed stukje, maar het kan lezers op het verkeerde spoor zetten: WGS84 wordt niet alleen in combinatie met lat/lon gebruikt, maar ook met andere coördinatensystemen, zoals bijv. UTM. Edited By lex on aug. 21 2002 at 14:47

Tsjonge, die GPS fabrikanten kijken wat af bij elkaar! Ik ga na mijn verhuizing nakijken of de GPS V (net nieuwe firmware) het nu ook kan. Misschien wel, je weet maar nooit....

Reuze makkelijk hoor, zo'n directe verwijzing. Maar ik vind dat als iemand een nieuwe draad begint over een onderwerp dat er al is, je beter naar de eerste draad kunt verwijzen. Daar staat nog wat extra informatie, en ook nog precies dezelfde verwijzing.

Nee, bij Garmin kan dat helaas niet, tenminste niet bij de typen die ik ken. Maar eigenlijk mis ik het niet zo, want ik vind het handiger om op een kaartje op de GPS te kijken, en niet naar kale getallen en een losse kaart. Edited By lex on aug. 06 2002 at 23:52

Kijk eens naar de draad 'Geocaching Forum > ALGEMEEN > Software > Gezocht: grid-conversie'. Er wordt ook naar een (gratis) programma verwezen.

Handmatig omrekenen is praktisch niet te doen, veel te ingewikkeld, en in elk geval veel meer werk dan het omschakelen van het stelsel. Dat omschakelen hoeft trouwens alleen maar voor het invoeren, want als je de GPS op RD omschakelt zullen alle coördinaten, ook de in HDDDMM.MMM ingevoerde, als RD-coördinaten worden getoond. En dan kan je ze zo opzoeken op de kaart.

Versie 2.07 is uit, 2.06 is overgeslagen, die zal wel te veel bugs bevatten. Het doet me genoegen dat mijn suggesties betreffende de verticale snelheid zijn gevolgd, zelfs meer dan dat, je kunt de eenheden hiervoor nu apart instellen, en daarbij o.a. kiezen uit 0.1 m/s en 1 m/min. De klokfout in de 'indoor'-instelling is er nog wel. De rest zal ik nog op mijn gemak bekijken. Edited By lex on aug. 05 2002 at 23:48

En als het RD-net niet vast is ingebouwd, soms onder de naam 'Dutch Grid', kan je bijna altijd 'User Coordinates' invoeren. Over hoe dit moet is in de rubriek 'Garmin, Magellan en alle andere GPS ontvangers' het onderwerp 'Rd-coordinaten in je gps' te vinden, daar vind je alles wat je daarvoor nodig hebt.

Europa beweegt ca. 2,5 cm/jaar t.o.v. WGS84 (zie citaat even hiervoor). Over 25 jaar dus ca. 60 cm. De normale verstopper van de cache kan, via middeling, een waarschijnlijke fout van ca. 5 m halen. Postprocessing zoals door Prof. Lupardi toegepast laten we even buiten beschouwing, want dat kan vrijwel niemand, en is ook wel erg ingewikkeld. De zoeker heeft, zonder middeling, een waarschijnlijke fout van ca. 10 m, wat samen resulteert in een waarschijnlijke fout van ca. 12 m. De 60 cm verschuiving valt daarbij in het niet. Voor geocaching maakt de continentale verschuiving dus niets uit. Voor de goede werking van de GPS-ontvanger maakt de verschuiving echt helemaal niets uit. De ontvanger bepaalt immers zijn afstand tot elk van de gebruikte satellieten. Elke satelliet geeft zijn eigen positie (ephemeriden=omloopbaangegevens) op in het door de satellieten gebezigde stelsel (WGS84). En behalve naar de satellieten kijkt de ontvanger helemaal nergens naar. Het is natuurlijk wel een heel ingewikkelde zaak om de satellieten hun exacte positie t.o.v. WGS84 te laten kennen, maar daar staat de ontvanger geheel buiten. Edited By lex on aug. 01 2002 at 22:30

Er is nog een complicatie. Veranderingen in de kengetallen van datums biedt geen oplossing voor rotatie van continenten. Je kunt er wel mee schuiven, maar niet mee draaien. En een poging toch één continu systeem te houden door deelsystemen via vloeiende overgangen aan elkaar te verbinden maakt het rekenwerk ingewikkelder met verhoogde kans op verschillen. Bij postprocessing zien we juist dat de hoogtecijfers t.o.v. de eenvoudiger WGS84-ellipsoïde gebruikt worden, en niet de op de GPS-ontvanger weergegeven betere benadering t.o.v. de WGS84-geoïde. (Zie het 'Hoogtemeting'-draadje in de rubriek 'Garmin, Magellan en alle andere GPS ontvangers'.) Edited By lex on juli 30 2002 at 19:31

In het bovenstaande citaat wordt vermeld dat WGS84 was bedoeld voor navigatiedoeleinden, waarbij afwijkingen kleiner dan 1 m er niet toe doen. Als het toegepast gaat worden met een veel grotere meetnauwkeurigheid krijg je een probleem, doordat WGS84 in essentie een doorlopend stelsel voor de gehele aarde is, en de continenten t.o.v. elkaar bewegen. Vergelijk het met een kamer met daarin 3 tafels, waarop glazen staan. Je meet de posities van de glazen uit t.o.v. twee loodrecht op elkaar staande kamerschermen. Als je de drie tafels elk een (verschillend) stukje verplaatst kun je je coördinatenstelsel wel aanpassen (schermen verplaatsen), maar niet zo dat de coördinaten voor alle drie de tafels hetzelfde blijven. Het stelsel kan slechts voor 1 tafel aangepast worden. Ook kan voor de drie tafels worden gemiddeld, zodat de coördinaten op alle tafels veranderen, maar de grootste veranderingen wel minder groot zijn. Het antwoord op de vraag moet dus wel a) zijn. Antwoord is alleen mogelijk als besloten wordt om WGS84 aan het noord-amerikaanse continent vast te pinnen, en het gemarkeerde punt juist op dat continent ligt. Omdat het GPS-stelsel door de Amerikanen wordt bedreven, komt vastpinnen aan een ander continent dan het hunne natuurlijk niet in aanmerking. De oplossing voor nauwkeurige metingen zal gevonden moeten worden in het gebruiken van eigen datums per continent. En de verschillen van deze datums met de door de GPS-satellieten gebruikte datum zullen geregeld moeten worden aangepast. Zou je het gemarkeerde punt in het RD-stelsel hebben gemarkeerd, met de bijbehorende datum, dan is het probleem opgelost, doordat de datum aan Europa is gekoppeld. Over dertig jaar moet je dan wel de dan geldende kengetallen van de datum gebruiken, en niet de nu geldende. Edited By lex on juli 29 2002 at 23:02

Natuurlijk is het leuk en interessant dat je aan beide monumenten hebt meegewerkt, maar 'oer'-punten zijn het geen van beide, noch in de zin dat ze de oorspronkelijke meetpunten waren, noch in de zin dat deze punten een hogere status zouden hebben dan andere (hoofd)meetpunten. Misschien hebben ze wel een lagere status omdat ze een slecht uitzicht hebben. Het is helemaal niet waar dat de andere NAP- en RD-meetbouten op deze geijkt worden, ze worden alle met elkaar vergeleken, en daar wordt een zo goed en constant mogelijk gemiddelde uit gedistilleerd. De RD-coördinaten zijn zo gekozen dat de centrale meridiaan door het kruis van de OL Vrouwentoren loopt, dus bovenop de toren, waarbij dit kruis de coördinaten X=155000, Y=463000 kreeg. Maar je moet niet denken dat als dat kruis 10 cm scheefzakt alle coördinaten in Nederland veranderen. Dan wordt aan de hand van de andere punten, en heus niet alleen dat onder de toren, geconstateerd dat dit punt is verplaatst. En die meter die in Sèvres bij Parijs wordt bewaard is al lang een relikwie. Een interessant museumstuk waar veel over te vertellen valt trouwens. De meter is al tientallen jaren gedefinieerd als een bepaald aantal golflengten van een bepaalde lichtsoort onder bepaalde omstandigheden. Edited By lex on juli 28 2002 at 11:18

Bedankt Prof. voor de aanvullende informatie. Ik heb er nog eens naar gekeken en denk het nu te weten. IJsenbrant vergist zich, NAP ligt ca. 43 m boven, en niet onder de WGS84-ellipsoïde. En ik vergiste me ook, want hierboven staat dat je 43 m moet aftrekken om NAP-hoogte te krijgen, en dus niet optellen, wat zou moeten als NAP onder de WGS84-ellipsoïde zou liggen. Bij postprocessing wordt uitgegaan van de hoogte [b:post_uid0]h[/b:post_uid0] t.o.v. de WGS84-ellipsoïde, en Prof. Lupardi veronderstelde dat dit ook het aangegeven hoogtecijfer op de GPS zou zijn. IJsenbrant stelt echter dat de hoogte [b:post_uid0]H[/b:post_uid0] t.o.v. de WGS84-geoïde wordt aangegeven, en dat verklaart waarom de hoogtecijfers op het scherm ruwweg de hoogte boven NAP aangeven, en niet 43 m te veel. Hij zegt ook dat het aangegeven hoogtecijfer niet wordt beïnvloed door de datuminstelling. En dat kunnen we zelf controleren door de datuminstelling te veranderen. Mijn GPS V, met kant en klaar ingebouwd RD-grid, geeft ook dezelfde hoogte op als onder WGS84. Sterker nog, als ik de positie van mijn huis bekijk worden de RD-coördinaten niet aangegeven (streepjes), omdat de positie buiten het RD-gebied valt. Maar de hoogte van 80 m wordt wel aangegeven. :exclamation: Hoog hè, nog hoger boven zee dan de hoogte van Prof. Lupardi's dakkapel boven de WGS84-ellipsoïde. Maar ja, de onderkant staat dan ook wel heel wat hoger. Edited By lex on juli 25 2002 at 23:13

Voor zover ik weet slaat hij ze altijd op. Dat is ook logisch, want als je geheugen wilt sparen moet je hem maar op 'auto' zetten, dat zet pas zoden aan de dijk.

REFERENTIEVLAK HOOGTEMETING. Weet iemand de waarheid? Ik begrijp het als volgt: Het GPS systeem gebruikt de WGS84-ellipsoïde als referentie. Dit is een benadering voor de vorm van de aarde. De X,Y,Z-coördinaten waarin eigenlijk wordt gerekend worden omgezet in lengte- en breedtegraden en de hoogte h boven deze ellipsoïde. In het boek 'Outdoor GPS Navigatie' van Rento IJsenbrant wordt gesproken over de geoïde. Door plaatselijke variaties van de zwaartekracht, veroorzaakt door dichtheidsverschillen in de aardkorst en het topografisch reliëf, kan het zeeniveau - nauwkeuriger gezegd het equipotentiaalvlak van het zwaartekrachtsveld - plaatselijk hoger of lager liggen dan de ellipsoïde. Het hoogteverschil N tussen deze geoïde en ellipsoïde heet geodetische undulatie of geoïde-ellipsoïde separatie. En deze N is in de vorm van een tabel opgeslagen in de GPS-navigator. De navigator geeft de hoogte weer t.o.v. de geoïde. Andere datuminstellingen hebben geen invloed op het hoogtecijfer. IJsenbrant geeft op dat Normaal Amsterdams Peil in Nederland gemiddeld 43 m onder de WGS84-ellipsoïde ligt. Dit cijfer wordt hierboven door Prof. Lupardi genoemd. Verder geeft IJsenbrant dat de WGS84-geoïde in Nederland 45 m boven de ellipsoïde ligt, zodat de hoogtecijfers zo'n 88 m lager uitkomen dan de hoogte t.o.v. NAP. Nu is er een grote meetfout in de hoogte, maar ik heb de indruk dat de hoogtecijfers gemiddeld toch wel ongeveer de hoogte t.o.v. NAP weergeven. Mijn GPSsen registreerden voor de tracks geen hoogtecijfers, maar met de GPS V, die dit wel doet, heb ik 1 track van Appingedam naar Rotterdam opgenomen, en de 223 punten liggen tussen -23 en +35 m, gemiddeld op +8 m. Slechts 2 % van de waarnemingen ligt onder de -12 m. En in Malta wijkt het gemeten zeeniveau ook zelden meer dan enkele meters af van 0 m. Mijn voorlopige conclusie is als volgt, maar ik geef hem graag voor een betere: IJsenbrant past de correctie N met het verkeerde teken toe, of de WGS84-ellipsoïde ligt niet boven, maar onder NAP. Dan zouden de hoogtecijfers respectievelijk 2 m te hoog of te laag zijn. Met mijn boerenklompenverstand kies ik voor de eerste mogelijkheid, omdat: 1. De WGS84-ellipsoïde gemiddeld over de hele wereld het zeeniveau moet aangeven. Als er bergen of hoogvlakten boven liggen, is er aantrekkingkracht van boven, zodat het zeeniveau iets omhoog getrokken zal worden. In Nederland ontbreken die, zodat het zeeniveau lager dan gemiddeld zal liggen. 2. Hoewel de correctie N niet precies zal kloppen, lijkt het me onwaarschijnlijk dat hij de fout vergroot inplaats van verkleint. En ik vind het helemaal verdacht dat de correctie in absolute waarde maar zo'n 3% mis is (NAP ligt boven het gemiddelde zeeniveau), alleen de verkeerde kant op. Als mijn redenering juist is betekent dat dat de gemeten hoogte gemiddeld ongeveer moet kloppen, maar dat je wel rekening moet houden met een flinke meetfout. Wie weet hoe het echt zit?

Het is niet nodig om te wachten op een nog nieuwere versie als je hier eerst de legend 2.36-firmware ophaalt. Als 2.38 je niet bevalt, kun je direct terug naar 2.36. Meer gegevens vind je in de draad [b:post_uid0]Nieuwe firmware venture, legend en vista![/b:post_uid0] in deze rubriek. Als je met verbinding de internetverbinding bedoelt kan ik je geruststellen. De firmware wordt eerst compleet in je computer geplaatst, daarna stuur je hem in een aparte handeling door naar je GPS. Wat er gebeurt als de verbinding computer-GPS voortijdig wordt verbroken weet ik niet, ik heb het niet gewaagd de proef op de som te nemen! Edited By lex on juli 16 2002 at 15:28

Ik gebruik versie 4.09 van mapsource. Updates zijn te betrekken van de Garmin-site. Als kaart heb ik European City Select v4.00.