Spring naar bijdragen

Gotcha!

Leden
  • Aantal bijdragen

    229
  • Geregistreerd

  • Laatst bezocht

Alles door Gotcha! geplaatst

  1. Als de aarde een perfecte bol zou zijn dan zouden we misschien ook nog wel op een eenduidige systeem kunnen rekenen. Maar zover zijn we nog niet
  2. Raar, ik had onderhand wel een opmerking verwacht dat het strand ook een biotoop is die je niet moet verstoren.
  3. Del1 evenmin gevonden, maar dat is een kwetsbaar gebied, en we hadden geen prikstok bij. Klok1 wel gevonden, zonder prikstok is die niet mogelijk, maar hier volstaat een breinaald. Schade aan het gebied is niet nodig.
  4. Niets van belang Lex 't was even een poging om te kijken of je hier een fatsoenlijke tabel kon plaatsen. Dit nav jouw lijstje. Werkt dus niet
  5. Test Excell-html tool <TABLE BORDER CELLSPACING=1 CELLPADDING=2><TR><TD>Afstand</TD><TD>breedte</TD><TD>verschil in afstand</TD><TD>verschil in richting</TD></TR><TR><TD>600 zm</TD><TD><P ALIGN="RIGHT">0</TD><TD>0 km</TD><TD>0°</TD></TR><TR><TD>&nbsp</TD><TD><P ALIGN="RIGHT">36</TD><TD><P ALIGN="RIGHT">0.75</TD><TD><P ALIGN="RIGHT">3.6</TD></TR><TR><TD>&nbsp</TD><TD><P ALIGN="RIGHT">52</TD><TD><P ALIGN="RIGHT">2.32</TD><TD><P ALIGN="RIGHT">6.4</TD></TR><TR><TD>&nbsp</TD><TD><P ALIGN="RIGHT">66.5</TD><TD><P ALIGN="RIGHT">7.47</TD><TD><P ALIGN="RIGHT">11.5</TD></TR><TR><TD>1200 zm</TD><TD><P ALIGN="RIGHT">0</TD><TD><P ALIGN="RIGHT">0</TD><TD><P ALIGN="RIGHT">0</TD></TR><TR><TD>&nbsp</TD><TD><P ALIGN="RIGHT">36</TD><TD><P ALIGN="RIGHT">6.02</TD><TD><P ALIGN="RIGHT">7.3</TD></TR><TR><TD>&nbsp</TD><TD><P ALIGN="RIGHT">52</TD><TD><P ALIGN="RIGHT">18.66</TD><TD><P ALIGN="RIGHT">12.9</TD></TR><TR><TD>&nbsp</TD><TD><P ALIGN="RIGHT">66.5</TD><TD><P ALIGN="RIGHT">59.9</TD><TD><P ALIGN="RIGHT">23.2</TD></TR></TABLE> Keurige tabel of niet ?
  6. Juist met een prikstok breng je minder schade aan dan zonder. Helaas jammer van die muis, toevalstreffer. Ik hou me aanbevolen voor zo'n prikstok.
  7. En dan werkt ut dus naar behoren, met RD als secundaire grid en secundaire datum
  8. Tja Kees, Dat probleem heb ik nou ook. Toch met redelijke zekerheid a,b en f,g kunnen bepalen, uiterste grenzen liggen dan op 1 minuut. En ben ook niet zo'n goede zwemmer dat ik dat buitenduins in de oude roompot wil gaan proberen. J@S (team Gotcha!)
  9. En het raadsel lijkt nu opgelost. De parameters voor de user-datum worden wel opgeslagen indien dat voor de primaire datum wordt ingesteld. Vervolgens kan de primaire datum weer worden ingesteld voor wgs84. En de secundaire datum op user grid. Door enteren is dan voldoende, eventuele correcties moeten voor de user-grid als primaire datum worden aangebracht.
  10. Grrrrr. User grid en datum (RD) ingesteld als primair systeem en WGS84 lat/long als secundair systeem werkt op de sportak dus wel. Ook de datum parameters van de user grid zijn vervolgens keurig af te lezen. Helaas wil ik werken met WGS84 en RD als secundair. Kijken of we dat nog uitgevogeld krijgen.
  11. Verdere test RD datum en grid op Sportrak, met een toegepaste schuif als eerder vermeld op RD 89112 SCHWEIZER KIRCHE EMDEN -D-- wGS84 53º 21,939 7º 12,128 RD E 275810 N 599220 levert na invoer van de WGS84 coordinaat een RD van E275802 en N599226. Schuif voor dit punt zou dan 155038 en resp 463105 RD 629322 R-K-K- VAALS RD 199820 309110 WGS84 50º 46,211 6º 1,351 levert RD's 199812 en 309117 RD 0 0 nulpunt RD WGS84 47º 58,4860 en 3º 18,814 levert: 000194 en 000138 (Minder relevant natuurlijk maar moest toch ook een westelijke postitie meenemen.) Dat lijkt er dus wel erg sterk op dat de software niet goed omgaat met de ingestelde secundaire user-datum. Blijft de vraag of een primair ingestelde user-datum dan wel correct zou werken. De nullen bij de review van de datum parameters had ik als waarschuwing moeten zien :-( Software versie 1.06 is inmiddels wel bijgewerkt naar 1.1. Echter in de release notes is hierover niets te vinden. Dan toch maar nieuwe software laden :--( en anders magellan eens contacteren. wordt vervolgd.
  12. Q: Als ik mij niet vergis kan je tegelijk in beeld hebben op de Sportrak de WGS84 positie in graden en de RD-positie in meters. A: Klopt, met RD datum en RD grid beide als secundairie ingesteld krijg je ze beide inbeeld. Vanuit het positie scherm na enter krijg je een projectie scherm, waarbij je dan wel een projectie kunt opgeven, maar ook een positie naar keuze in de primaire dan wel secundaire datum en grid. Op die manier kan ik dus alle mogelijke posities laten bereken. Q: Ik zou zeggen: probeers eens of je overal dat schuifverschil hebt: niet alleen in het centrum van het raster maar ook aan de randen. (NO-Groningen, Zuidlimburg) A: Yep dat zal ik eens gaan doen en had ik eerder ook ingedachte of ik iets over het hoofd zag. Kan e.e.a natuurlijk makelijk met RD data testen. Ik hou je wel op de hoogte. Q: parameters? Neemt die echt alle ingetypte cijfers mee (zoals van vertrekpt in decimale graden) of niet? Rond/kapt die af? Wat zeggen je schermjes over die parameters als je ze terugkijkt na invoer? A: Dat is een vreemd verschijnsel op zich. De paramaters voor de secundaire grid zijn keurig terug te lezen en komen dan exact overeen met het ingevoerde. Van verdere afronding lijkt hier geen sprake te zijn. De parameters voor de secundaire datum zijn echter niet terug te lezen en staan dan alle op 0. Indien je de procedure door entert dan blijkt daarna de berekeningen inderdaad terug te voeren op WGS84 ipv op de voorheen ingestelde datum. Opnieuw netjes alle parameters weer invoeren is dan noodzakelijk om de userdatum weer correct op RD te krijgen.
  13. Loxodroom of grootcirkel, voor afstanden <= 600 Nm ( pakweg 1100km) maakt het nauwelijks iets uit.
  14. Klopt ik gebruik CC 4.0 van het ministerie op http://www.minvenw.nl/rws/mdi/plaatsbep/ho...calculator.html voor de controle. Aanvankelijk miswijzing in het veld geconstateerd. Schuif vastgesteld adhv de DOM en de OLV kerk te A'foort. Enkele andere punten eveneens aan hand van de omrekenaar en bovendien mbv van Ozi gecontroleerd. Waarom deze afwijkende schuif nodig is is mij ook een raadsel ? Wel gebruik ik nog versie 1.06 voor de Sportrak, er is inmiddels wel een nieuwe release, maar ben nog onvoldoende vertrouwd met het ding om deze al aan te brengen. "Wel Gotcha, het is goed te horen dat ik al die dingen over RD in GPS-en zetten niet voor niets heb gedaan. Nu moet ik dus ook iets voor/over de Sportrak gaan vermelden." Ach en ondanks dat ik als zeiler toch al lang jaren vertrouwd ben met Decca,GPS Mapdatums ED50 en WGS84 heb ik toch veel opgestoken van jouw verhandelingen met name ivm de verhoogde nauwkeurigheid die voorheen niet mogelijk (SA) en niet noodzakelijk was. Hierdoor kan mijn status binnenkort opgewaardeerd worden tot near-expert, waarvoor dan ook mijn dank.
  15. Ut heeft me nogal wat moeite gekost om onze Magellan Sportrak goed in te stellen, maar dat lijkt nu toch gelukt. Navolgende instellingen van Prof waren het uitgangspunt: Magellan Meridian Gold and Platinum From the Position Screen take Menu CoordSys and give an [enter]. There is a choice now: Primair of secundair, (secundair is a good choice) [enter] Gebr.rast. [enter] Projectie => Trans Merc [enter] Geograf. brdte vertrekpt = 52.15617N [enter] Geograf. lte vertrekpt = 005.38763E [enter] volg [enter] nvt op Sportrak Schaalfactor = 0.99990790 [cursor] Eenheid tot meter omz = 1.00000000 Fout O bij vertrek = 00155000.0 Fout N bij vertrek = 00463000.0 Now you are ready and do an [enter] nvt voor Sportrak Then the next things: Datum kaart [enter] primair of secundair [enter] USER [enter] Delta A (meters) = +0740.000 [cursor] Delta F (meters) = +0.10037480 Delta X (meters) = +593.0 Delta Y (meters) = +0026.0 Delta Z (meters) = +0478.0 Opsl. [enter] nvt voor Sportrak Echter de sportrak blijkt dan stevast 29 meter te westelijk en 111 meter te zuidelijk uit te komen. met Fout O bij vertrek = 00155029.0 (ipv 155000) Fout N bij vertrek = 00463111.0 (ipv 463000) Blijkt e.e.a. wel te werken tenminste voor de door mij gecontroleerde punten. Of zie ik nu iets over het hoofd ?
×
×
  • Nieuwe aanmaken...