franka en pim

Xaa... vergeet het zegel niet, zodat naderhand altijd te controleren is of de crime scene naderhand nog is betreden!

Wellicht en afgesloten deel op het forum speciaal voor de admins? In dat geval moeten ze ook even de query voord e frontpage aanpassen

Ach... wat is druk. Het is ook een stukje voorbereiding op mijn nieuwe baan in Meppel. Waar ik hoogst waarschijnlijk een aantal GPS gerelateerde projecten moet gaan draaien. Het is dus buiten leuk, ook nog eens een investering in de toekomst. Beetje ervaring op doen enzo. MAar laten we niet te veel offtopic gaan Skip.

Al zou het een instelling zijn, dan nog vind ik +/- 30 graden wel erg veel. De variatie in Nederland is ongeveer ½° west. Variatie is het verschil tussen het magnetische en geografisch (ware) noorden.

Dat is zeker waar, maar in verband met gebruiksvriendelijkheid heb ik expres niet gekozen voor java... Java kan je ook naar een EXE compileren. Volgens mij zelfs zodat je niet hoeft te installeren. Je hebt dan geen JVM nodig. Hoe moeilijk, of makkelijk het daarna te porten is naar Mobile weet ik niet. Ik heb geen ervaring met de Mobile SDK. Enige wat ik weet is dat die aardig is uitgekleed tov de normale SDK. Al verwacht ik niet dat de berekeningen die hier plaats vinden, een probleem zouden vormen voor de Mobile Java. Het is wellicht een experimentje waard, waar ik best wat tijd in wil steken. De formules heb ik uiteraard Dus dat moet geen bottleneck zijn. Allen de ervaring met JAVA Mobile... die mis ik nog. Daar moet ik dus even wat tijd in gaan steken. Ik heb NMEA inmiddels helemaal binnenste buiten gekeerd, dus ben wel weer toe aan een nieuw experimentje

@Bjorri Ik ben redelijk paranoïde wat dit soort dingen betreft. Als er iets mis gaat, gaat het meestal meteen ook goed en/of helemaal mis. Wet van Murphy. Neem de reeds genoemde, niet ongewone situatie: Een GPS kan nog redelijk tegen water... maar een mobieltje... Die van mijn buurman iig niet (toen zijn zoontje het mobieltje, lief bedoeld, ging afwassen "kijk pap, ik ben je mobieltje aan het schoon maken") En wat heb je aan GPS coordinaten, als je ze niet kan doorbellen? Vrij weinig. Dan is het wel zo prettig dat je vanuit de diepte, met je fluitje, de aandacht kan trekken van voorbijgangers, die wellicht wel een werkend mobieltje bij zich hebben. Daarbij kom je met hoog frequent geluid als een fluitsignaal, aanzienlijk verder dan met je eigen 1000 Hz stem geluid. Daarbij kost schreeuwen velen malen meer lucht (en energie) dan een flink fluit signaal.

JA. eXplorist pakt voeding van de USB als hij is aangesloten op de USB. Voor de knutselaars.... Let op..... Aansteker in auto is +12V, USB is +5V Vergeet dus niet een beetje hardware in elkaar te beunen. Beetje spelen met een LM7805. Dit is een +5V spannings regelaar met een maximale belasting van 1000mA (1A) Aansluiting voor de USB: http://pinouts.ws/usb-pinout.html Bij de platte (normale) USB aansluitingen zijn de buitenste twee contacten de +5V en de massa. Even meten om te weten welke wat is.

Ik denk niet dat het een geheim is, als ik zeg dat er genoeg van die dingen op het internet staan. En dat er nog genoeg mensen zijn die het niet zo makkelijk vinden. Wat ik dan zou willen zien, is een oplosser die buiten getallen ook letters aan kan. Ook ik weet dat er genoeg sudoku oplosserr op internet zwerven. weet je dat je die ook voor letter kan gebruiken. maak je gewoon zelf even een vertaal slag. bijvoorbeeld: 1=a 2=b etc....

Doe mij maar gewoon een naamplaatje om mijn nek. Je kan er van alles op laten zetten. En ze kosten rond de 10 euro. Je kan er een hoop aanvullende info op kwijt. Allergie Medicijn gebruik Aandoening die je hebt (bijvoorbeeld epilepsie oid) Bloedgroep etc. zie: www.tagcompany.nl www.identiteitsplaatje.nl

Dat is altijd met dit soort onderwerpen. Het lijkt in eerste instantie heel overdreven.... tot het je overkomt.

Buiten het feit dat ze gewoon leuk zijn, zijn ze geen overbodige luxe. Je komt wel eens op plekken waar het aantal voorbijgangers zeer beperkt is. Je zal je verstappen en je enkel breken. Aan de andere kant.... meeste mensen hebben hun mobieltje wel mee, en weten de GPS coords waar ze op dat moment zijn. In geval van een lege batterij in de telefoon/GPSr, of buiten bereik van het netwerk of de satellieten, dan is zo'n fluitje misschien wel je laatste redmiddel. Ik zou het absoluut geen overbodig luxe vinden.

Euh Ook die heb ik al liggen als php script Weet alleen niet of het echt een toegevoegde waarde is voor de geotools en/of gctool. De meeste mensen weten wel hoe ze een sudoku op moeten lossen. Er is geen speciale kennis voor nodig. Voor de berekeningen van coordinaten, projecties en snijpunten is dat een ander verhaal. Dat is vrij specifieke kennis die niet iedereen heeft of zich aan wil leren. Afgezien van de letter tellingen, coderingen en morse enzo. Al zie ik daar wel weer wat in omdat daar nogal snel fouten in sluipen. De sudoku oplosser is in mijn ogen een stap te ver. Het zou niet leuk zijn voor Knifemen`s First Sudoku (GCWWPQ) bijvoorbeeld.

11 euro http://www.gpsplaza.nl/page.htm?pda-kabel.asp

rijsom staat ook bekend als 'stapeltellen'

Dat komt omdat de decimalen in een apart veld ingevoerd moeten worden. VB ziet het dan als een geheel getal, en zet er voorloop nullen bij. Terwijl het juist een decimaal is, en dan moeten er naloop nullen achter. Daarom heb ik in GEO Tools de invoer ook in 2 velden ipv 3 Dan kunnen de minuten met een . of , worden ingevoerd. Dan ben je van dat probleem af. En nog handiger is het (voor de gebruiker tenminste :-) ) als je maar één invoerveld gebruikt, en het programma zelf laat uitzoeken of N51 51.890 / 51 51 51 / 51,90234 / -5 23,001 staat Maar dat brengt weer technisch een hoop problemen met zich mee. Het kan hoor, daar niet van. (zie google maps) Alleen nog geen tijd en zin gehad om het zo ver door te voeren. Dit was een mooi compromis tussen snel programmeren (kort code) en gebruiks gemak.

Dat komt omdat de decimalen in een apart veld ingevoerd moeten worden. VB ziet het dan als een geheel getal, en zet er voorloop nullen bij. Terwijl het juist een decimaal is, en dan moeten er naloop nullen achter. Daarom heb ik in GEO Tools de invoer ook in 2 velden ipv 3 Dan kunnen de minuten met een . of , worden ingevoerd. Dan ben je van dat probleem af.

Inderdaad... eigen postcode erin. Dat zou ook mijn eerste reactie zijn. Maar het is welk heeeeeeeerlijke materie om in te duiken. Zeker als je met z'n twee bent. (met Martijn - GPSGEK) Dan kan je een hoop van elkaar leren, en kan er ook gerichter getest worden.

Ziet er goed uit Martijn. Lekker bezig! Bij het invoeren van de WGS84 coord MOETen de 3 cijfers achter de punt ingevuld worden. Ook als dat nullen zijn. Zou ik naloop nullen weg laten, gaat de WGS84 -> RD conversie niet goed. N 51° 14.800 E 3° 26.600 N 51° 14.800 E 3° 26.600 N 51° 14.800 E 3° 26.600 moeten allemaal op leveren RDx 19284 RDy 363734 Echter kan het zo'n 120 tot 1400 meter schelen op RD, als ik de naloop nullen er niet bij zet. Op zich is dat redelijk makkelijk op te lossen. Do Text = Text & "0" Loop While LenB(Text) < 3

Oeh... dat is NICE!!!!!! Die wil ik ook wel in mijn GEO-Tools.

Als schrijver van die Postcode conversie wil ik daar graag even op in haken. Als je naar de plot op het kaartje kijkt, die klopt wel. Het probleem in deze zit hem in de gegevens in de database. Er zijn twee dingen die hier gebeuren. Ener zijds, heel sec de conversie van PostCode naar Coordinaat 3862aa = N52 13.330 E5 29.260 Dat klopt dus. Zo ook de plot op het kaartje ter controle. Vandaar dat hij wel netjes Nijkerk met postcode gebied 3860 - 3862 vindt. Bijvoorbeeld 3864DE (Nijkerkerveen) Echter zit in dat laatste deel het probleem.... de coords die aan dit postcode gebied hangen, als zijnde het stads/dorps centrum, kloppen niet. Die zijn van Ferwerderadiel. (er word onderscheid gemaakt tussen exact postcode en postcode gebied daar deze in twee verschillende tabellen staan. Mensen met Database kennis weten waarom) Daardoor komt er een vreemde gemeente en provincie uit rollen. De berekende afstand tot het stad/dorps centrum is dan oko de afstand van Nijkerk naar Ferwerderadiel... en dat is 138km en 859meter in noordelijke richting (17 graden) Een doorwerkende fout dus, veroorzaakt door één onjuist coordinaat in een lijst van 450000 coordinaten. Je hebt er precies een uit te pakken die niet klopt. Tik eens een postcode wat buiten de 3860 - 3862 valt. Zonde dat je dat niet eerder had gemeld, want nu heb je de indruk dat die pagina niet goed zijn werk doet, terwijl het 'slechts' één regel data is die niet klopt. De data is een lijst met zo'n 450000 regels. Het kan dus zijn dat er ergens een foutje in geslopen is. Ik ben niet bij machte om al die 450000 regels te controleren Het up to date houden van die lijst is ook onbegonnen werk omdat deze data tegenwoordig niet meer vrij via internet te verkrijgen is. (www.postcode.nl vraagt GROF geld voor deze gegevens) Een deel van deze lijst komt uit 1995. Dat is het deel van de postcode gebieden, netnummers, gemeente, en dorp/stad centra. Het andere deel is ook niet van vandaag. Dat is het deel waar de koppeling van het exacte postcode en de coordinaat wordt gemaakt. Hoe oud deze lijst precies is weet ik niet. Wat ik wel weet, is dat een wijk in Zoetermeer, ten zuiden van de A12 (bij DE LUS) er niet instaat. Iemand die weet hoe oud deze wijk is? an weten we namelijk ook meteen die minimale leeftijd van de andere lijst die ik gebruik. Bottom line.... fout in de data, waardoor er een doorwerkende rekenfout optreedt. Kortom.... je moet een kraslot gaan kopen. De kans was 1 op 450000 dat je hier tegen aan zou lopen.... en jij hebt hem gewoon!!! Als iemand de juiste coords heeft voor Nijkerk en mij kan voorzien in het postcode gebied van Ferwerderadiel dan kan ik deze fout herstellen. Edit: Ik zie nu ook waar het is mis gegaan. De coord die bij het postcode gebied is gevonden is van "Oosternijkerk" Wellicht dat daardoor de data ooit eens verminkt is geraakt. Nijkerk centrum: N52.222785 , E5.488604 (3860 - 3862) Ferwerderadiel is een gemeente met een bonte verzameling van dorpjes uit de postcode regio 9071 - 9179 In de lijst met postcode gebieden zijn er nog 3000 die niet volledig zijn. Van 2400 stuks zijn de postcode gebieden niet bekend Van 2400 stuks zijn de centrum coordinaten niet bekend Van 1900 stuks zijn beiden niet bekend Genoeg te doen dus

Alle berekeningen zitten (uiteraard) in apparte functions/methodes/subs (hoe worden ze allemaal wel niet genoemd) Isoleren en opsturen is dus relatief makkelijk. Als je mij even je mail adres via PM/PB laat weten, zal ik wat stukken source opsturen. Moet je nog wel even zelf omsleutelen naar VB, maar dat is geen probleem denk ik? Ik heb wel wat VB source voor de plot op een kaart mbv RD, maar die kan ik je op z'n vroegst vanavond pas geven. De PHP source voor hetzelfde heb ik wel na al voor je. Ook nog behoefte aan VB source om vanaf een COM poort NMEA te ontvangen en uit te werken tot info op het scherm... incl satelleit standen, SNR (Signal Noice Ration ~ "signaal sterkte") en kaart plot? Kan ik je vanavond ook wel even sturen.

Martijn.... wellicht moeten wij de koopen even bij elkaar steken. Ik heb voor een web versie van GEOTools (het befaamde geocaching.be excel sheetje) al een en ander aan spullen zitten bakken. Wellicht kunnen we elkaar bijstaan met wat code. Ok.... VB en PHP zijn niet één op één uit te wisselen, maar we kunnen beiden zowel PHP als VB lezen en schrijven. Het scheelt een hoop tijd en denk werk. Ik heb ook nog wel een database met GPS coords -> postcodes (de 6 positie versie) Ook zit er in die database een tabel met wat algemene informatie zoals netnummers, coords van het stads/dorps centrum, NS station en het postcode gebied van die plaats. Ik heb ook al aardig wat werk gehad aan het op een kaart plotten van de positie (inclusief calibratie van het kaartje) Ook het A <-> Z en N <-> Z versleutelen heb ik helemaal klaar (incl. lettertelling) En een morse encoder/decoder. Laat maar even weten of ik wat voor je kan betekeken. www.ronsoft.nl/geotools <- hier is een link te vinden die niet offline is.

SnØg LOL!!

Tot zo ver is het duidelijk, en was het eigenlijk al duidelijk. De kneep zit hem voor mij... hier... Door dit laatste stukje wordt naar mijn idee redelijk duidelijk gemaakt dat een RD<->WGS84 conversie rekening moet houden met een verschuiving. De verschuiving, die ook wel de continentendrift of platentektoniek wordt genoemd en door Alfred Wegener werd ontdekt (en pas 30 jaar later werd geaccepteerd) De absolute verschuiving is niet heeeel erg groot. Te klein om onze geocaching hobby op de korte termijn te verstoren, maar hij is er wel. Bij on conversie naar van WGS84 naar RD, waar RD in meters wordt gegeven, is er geen probleem. Dus GPSGEK... geen nood aan de man. (je moet alleen over 50 a 60 jaar even opnieuw kijken ) Maar het is wel slim om even in het acterhoofd te houden dat bijvoorbeeld Apeldoorn tussen 2000 en 2003, en verschuiving door maakte van 1,4 tot 1,7cm/jaar in oost richting, en tussen de 1,6 en 1,8 cm/jaar in noord richting. Dat komt neer op 2,2 a 2,4 cm verplaatsing per jaar, richting het noordoosten. Bron: http://www.rdnap.nl/

...dat konden weleens heeele dure zakjes worden! Dan ga ik wel even met de bus. Kom er dagelijks langs met de zuid tangent