Wally

Hoe gemakkelijk kan een eigen server opgezet worden op een XP professional systeem? Hoe heb jij dat .net script draaien?

Bedankt voor de reacties tot zover. Dj bel, je komt met mogelijke problemen in de NMEA interface e.d. Echter, ik zit nog in de testfase van het perl script zelf. Door in de internet explorer op mijn pc naar het script te gaan kan de juiste werking reeds getoetst worden zonder eerst alle hardware + GPS te configureren. De door mij geprobeerde commando's komen dus uit de help. Ze zijn bedoeld om het script zelf te testen. In elk geval heb ik al eerder succesvol m'n GPS aan m'n pocketpc pda gekoppeld (NMEA) en ook al GPRS werkend kunnen krijgen (maar dat is hier dus nog niet van toepassing omdat ik eerst de test doorloop). japi, je spreekt over de .net variant van het script. Wat heb je nodig om zo'n script te draaien? Kan dat vanaf de homepage ruimte van de eerste de beste Internet provider?

NetGPS is a companion system to Oziexplorer. It makes it possible to transmit coordinate data from a PC, across a network to another PC running Oziexplorer’s moving-map system. Meer info over NetGPS In mijn geval wil ik de PocketPC variant als remote laten werken en via GPRS positiegegevens doorsturen. Daarvoor heb ik het standaard perl script wat bij de software komt geupload naar een subdirectory onder de root van een webserver van derden, waar ik voor de gelegenheid wat ruimte op heb gekregen. Vervolgens ben ik de tests gaan doorlopen zoals die in de handleiding aanbevolen worden, m.b.t. de webserver. Test Step 1 Test: Invalid Access Input: http://servername/netgps.pl Expected Result: "GPSERROR:Invalid Parameters" Ik krijg: "GPSERROR:Incorrect password/unknown username.:" Test Step 2 Test: No user data found for Receiver. Input: "http://servername/netgps.pl?un=joe&pw=bloggs"'>http://servername/netgps.pl?un=joe&pw=bloggs" Expected Result: "GPSERROR:No user data found." Ik krijg: "GPSERROR:Proc error: RCV-FN1:" Test Step 3 Test: Valid Remote input. Input: "http://servername/netgps.pl?un=joe&pw=bloggs&cds=$GPRMC,065954,V,3244.2749,S,1480 9.9369,E,21.6,0.0,211202,11.8,E,S*07 Expected Result: "GPSOK" Ik krijg: "GPSERROR:Invalid NMEA data: '$GPRMC,065954,V,3244.2749,S,1480 9.9369,E,21.6,0.0,211202,11.8,E,S*07' Code IV:" Test Step 4 Test: Valid Receiver input. Input: "http://servername/netgps.pl?un=joe&pw=bloggs" Expected Result: "GPSOK$GPRMC,065954,V,3244.2749,S,14809.9369,E,21.6,0.0,211202,11.8,E,S*07" Ik krijg: "GPSERROR:Incorrect password/unknown username.:" tot zover m'n tests, test 5 sla ik maar even over omdat 1 t/m 4 al niet werken. Ik heb zelf weinig verstand van perl scripts, de oorzaak van deze fouten kan ik dus niet achterhalen. Wellicht dat ik nog wat moet regelen op de webserver zelf (die ik overigens via WS-FTP kan benaderen). Wellicht dat iemand hier ervaring mee heeft en kan helpen?

De punten van een basisstation worden in de praktijk ook wel met theodoliet ingemeten, maar langdurig met GPS kan natuurlijk ook. Bij een verbinding met het 'mobieltje' is er meestal sprake van een continue verbinding met het basisstation, zodat je realtime je positie hebt. Let wel, het basisstation is in deze gevallen een zelf opgezet basisstation door de landmeter zelf, meestal op een goed verankerd en uiteraard nauwkeurig bekend punt wat uitsluitend door deze ene landmeter gebruikt wordt. Er zijn ook 'gemeenschappelijke' basisstations, die veelal mbv radiotransmissie werken en dus toegankelijk zijn voor meerdere landmeters/uitzetters/machines tegelijkertijd. In principe kan het GPS spul op een machine (HGM/bulldozer) ook met GSM werken, de bandbreedte hiervoor is voldoende. Echter praktisch minder haalbaar, omdat je voor elke machine een GSM op de basis moet hebben of zelfs een aparte basis voor elke machine. In de praktijk wordt er bij mijn werkgever dus gewerkt met referentie via radio, zodat zowel landmeter als machinist er wat aan hebben. Dit werkt bij GPS op de bulldozer prima, omdat dat spul ook van Trimble is, net als het materiaal dat de uitzetters op mijn werk gebruiken. De gps set op de HGM werkt met een ander merk ontvangers, waardoor alsnog een apart basisstation nodig is.

Nee, deze nauwkeurigheid wordt met de RTK technologie zelfs realtime gehaald! De meeste professionele ontvangers updaten de positie elke 1/10 seconde met deze nauwkeurigheid. Daardoor kan ook een Hydraulische GraafMachine (HGM) met grote nauwkeurigheid werken zonder te hoeven wachten. Voor de realtime nauwkeurige positie moet de apparatuur wel eerst een fix hebben, dat kan even duren, maar zodra die er is kan de landmeter of uitzetter productie maken! De genoemde straal van 10 km is ongeveer een richtlijn ivm plaatselijke afwijkingen in ontvangst tussen basisstation en 'rover' door bijvoorbeeld de atmosfeer. Hoe verder je gaat, hoe onnauwkeuriger je gaat werken omdat de omstandigheden op gemeten positie in het veld anders zijn dan t.p.v. het basisstation. Maar als dit 15 km is zou de nauwkeurigheid ook voldoende kunnen zijn. De beperkende factor is het communicatiemiddel tussen basis en rover. Als dit een radio-verbinding is dan zal dat inderdaad rond de 10 km liggen, ook afhankelijk van obstakels zoals hoge gebouwen etc. Wanneer gecommuniceerd wordt via GSM (dataverbinding) is natuurlijk de dekking van het GSM net bepalend.

Zo'n zelfde plaat met tekst erop is ook te vinden op de hellegatsdam.

Yep, idd met een basisstation. Zie ook de berichten hiervoor, daar staat het al wat uitgebreider.

Nog even wat verheldering m.b.t. het gebruik van GPS onder water. Inderdaad bevindt de meeste apparatuur zich boven water, op de machine. Een hydraulische graafmachine (HGM) heeft 'achterop' 2 GPS antennes, op die manier is de verdraaiing van de machine bekend. Op elk knikpunt van de graafarm zijn knikopnemers gemonteerd die zeer nauwkeurig de hoek meten waarin het geheel zich bevindt. Met behulp van een computer en de 2 GPS ontvangers wordt op die manier de positie van de graafbak van de HGM bepaald, ook als die onder water is. Deze positie is horizontaal erg nauwkeurig (1~2 cm), de verticale nauwkeurigheid iets minder nauwkeurig maar goed genoeg om mee te werken.

Inderdaad, met een 'roterende laser' zoals dat in vakjargon heet kun je, m.b.v. een laserontvanger op de machine zeer nauwkeurig in het verticale vlak werken. Met zo'n roterende laser kun je ook hoogtes meten, door steeds de handontvanger gemonteerd op bijvoorbeeld een baak in de laserstraal te positioneren. Dit uiteraard metend vanaf een bekende hoogte. De ontvanger pakt een vrij breed gedeelte op (10~15 cm ofzo), zodat hij gaat piepen wanneer je deze in de laser houdt. Hij geeft dan dmv de snelheid van de piepjes aan of je omhoog of omlaag moet. Wanneer je precies goed zit geeft hij een continue toon. Overigens wordt GPS ook al in de landbouw gebruikt. Vooral het merk Trimble is hier erg ver mee met diverse producten. Uit ervaring weet ik dat, althans voor wat betreft de weg- en waterbouw, niet alles gaat om het 'vlak maken'. Denk aan de vele dijken, infrastructuur, watergangen, natuurvriendelijke oevers enz. Bij dit grote grondverzet komt aardig wat kijken, waarbij GPS een meer dan welkome aanvullig is. Zo kan met GPS onder water zeer nauwkeurig taluds afgewerkt worden en kan onder water ontgraven worden tussen bijvoorbeeld heipalen van een fundering van een tunnelbak. Of nauwkeurig baggeren vanaf een ponton.

Nou, aangezien ik ook wat ervaring heb met het landmeetgebeuren kan ik hier al een tip van de sluier lichten. Het gebeurd inderdaad met een basisstation, waarvan de positie exact bekend is. Door middel van correctiesignalen van de basis richting de 'rover' (de GPS in het veld waar de landmeter mee loopt) kan een nauwkeurigheid van 1-2 cm horizontaal en iets grotere afwijking verticaal behaald worden. Correctiesignalen kunnen ofwel via GSM ofwel via radio-signalen doorgeven worden. De techniek heet 'Real Time Kinematic' ofwel RTK, welke een hoge nauwkeurigheid mogelijk maakt. De preciese techniek is mij niet bekend, mocht je daarin geinsteresseerd zijn dan zal de prof je vast verder kunnen helpen Zelf heb ik ervaring met Trimble, Leica en Ashtec i.c.m. een pencomputer met penmap software. De hoge nauwkeurigheid is ook mogelijk op machines, bijvoorbeeld bulldozer en hydraulische graafmachine wat ook met een basisstation werkt. Zo is er sinds enkele maanden de eerste bulldozer met Trimble GPS plaatsbepaling operationeel in Nederland, waarbij het blad van de bulldozer gesteld wordt aan de hand van een DTM (Digitaal Terrein Model) - het blad volgt het te maken ontwerp (3d model).

Ik zal het in overleg met Des aanpassen.

De nederlandstalige gebruikersgroep voor OziExplorer is beschikbaar op: http://groups.yahoo.com/group/Ozi-UsersNL Een Yahoo account is vereist. Tip: stel de berichtbezorging in als text, dit beperkt het dataverkeer m.b.t. advertenties aanzienlijk.

Gebruik ook eens de zoekfunctie van het forum.

Ja, wat ik uit previews heb begrepen (en ook reviews van andere toestellen) betekend zo'n 3-axis compass dat je de GPS niet perse horizontaal hoeft te houden. Of je altijd dezelfde nauwkeurigheid hebt weet ik niet, maar makkelijk is het natuurlijk wel.

Bernez, Aanpassen heeft weinig zin omdat Ozi die bestanden steeds genereerd uit de .map files, dit zijn de index bestanden. Reden hiervoor is dat het zoeken naar kaarten dan veel sneller gaat. Maar met de laatste dev versie + even opschonene van je system files directorie levert een weer werkend geheel op! Dus, gewoon de laatse development versie installeren, hoef je ook niet meer moeilijk te doen met andere software.

Het probleem is nu wat minder urgent geworden. Des Newman schreef het volgende in een mailbericht aan mij: Een kijkje op de OziExp pagina leert ons dat een nieuwe dev. versie beschikbaar is:

Het probleem lijkt in ieder geval niet alleen aanwezig te zijn bij de NL versie, wanneer ik het taal-bestand hernoem start ozi in het engels. Ook hier geeft de development versie wederom alleen de door mij eerder genoemde files aan op de index kaart.

Om een 100% ozi file als voorbeeld te krijgen, kun je het volgende doen: Kies 'calibratie van kaart controleren' via het bestand menu. Vervolgens wijzig je absoluut niets en klik je op opslaan. De map file wordt dan bijgewerkt volgens het juiste formaat. Ik heb dit getest, het bestand wordt dan wel door ozi herkend en verschijnt bij het door mij eerder genoemde lijstje met kaarten in de index map. Voor mij voldoende bewijs dat ozi er een werkend bestand van heeft gemaakt. Een snelle test van de bijgewerkte .map files kun je doen door de index kaart op te roepen en te controleren of alle kaarten omlijnd worden (rode rand) en aanklikbaar zijn. Kaarten die niet aanklikbaar zijn zijn dan dus niet goed bijgewerkt.

Voor zover ik het heb kunnen testen maakt het pad wat is ingesteld in de .map file niets meer uit. Ozi kijkt namelijk ook in het pad wat ingesteld is onder Bestand -> configuratie -> kaartpaden.

Helaas werkt nog niet alles naar behoren met de nieuwe .map files, althans bij mij in ieder geval niet. Ozi indexeert slechts de volgende .map files correct (zichtbaar op de index kaart): 01H Ameland 02G schiermonnikoog 03C Pieterburen 03a Rottumeroog 17C Hoogeveen 21D kampen 21G Zwolle 27E Wijhe 28A Hellendoorn Wie o wie heeft ook dit probleem?

Mensen, het is (wederom) geweldig wat voor een staaltje kennis en kunde hier weer geleverd wordt! Ik heb wel van Mathlab gehoord, ik begreep dat dit een soort wiskundig pakket was (zoals bv Maple waar ik wel wat ervaring mee heb) maar dat dit soort zaken ook met zo'n programma geregeld kan worden is geweldig. Overigens, hieronder nog een antwoord dat ik van Des kreeg betreffende dit probleem:

@Prof: klopt het dat de .map files dus via een ander programma (mathcad ofzo) aangemaakt zijn, of is het wel met Ozi gedaan? Dan kan ik Des daarover inlichten.

Van Des Newman heb ik een bevestiging ontvangen dat de door mij gebruikte .map bestanden van de KabouterCD's niet volgens de specificaties aangemaakt zijn: Ook gaf Des aan dat er meer probleemgevallen gemeld zijn. Mijn vraag bij deze is dan ook of er actuele .map bestanden beschikbaar zijn voor de kabouterkaarten? En heeft iemand misschien een idee of de .map bestanden van de cd's m.b.v. ozi aangemaakt zijn of met een ander tooltje?

GPX is inderdaad een op XML gebaseerd bestandsformaat. Door de XML structuur dus ook zeer goed door mensen te lezen. De achterliggende gedachte is een standaard uitwisselingsformaat (vooral handig op internet). GPX (GPS eXchange Format) is ontwikkeld door Topografix, zie deze pagina voor officiele informatie. Ook is er een Yahoo group over GPX, deze volg ik nu al een aantal maanden. De groep is erg rustig, af en toe komt er een berichtje voorbij m.b.t. de implementatie van GPX in diverse applicaties. Ik heb het formaat ook voorgesteld aan P-terminator, de maker van GarTrax. Of het daadwerkelijk in het programma komt weet ik niet, hij zou er naar kijken.

Vandaag een reactie gehad op mijn e-mail, dit keer van Allan Brandon. Hij schrijft: Ik heb ook gewezen op het feit dat de Kabouterkaarten die ik gebruik versie 2.1 .map bestanden bevatten. De reactie van Allan: Bij mij wilt het nog niet goed werken, alhoewel versie 2.1 map files geen problemen zouden mogen geven. Ik heb een .map bestand opgestuurd met het verzoek om aan te geven waar het mis gaat: zijn de map files niet volgens de 2.1 specificatie of is er misschien toch een bug in het programma?