Ik ben bezig met een hobby project ideetje om plaatsen op een kompas schijf te zetten, zodat je een beetje weet waar een plaats zich bevind. Een beetje ala de screenshot beneden (compas city uit 2009, maar nu onvindbaar).
Dus op basis van een GPS coördinaaten moet ik plaatsen op de kompas schijf zetten.
Vragen:
Weet iemand of er nog soortgelijke applicaties live zijn?
Ik ben redelijk nieuw in het geo gebeuren, dus ik zoek even wat (engelse) geo termen en wat ideeën om van start te gaan. Op basis van lat/lon data van eigen locatie en locaties van plaatsen moet ik alles op een schijf zetten. Ik mis wat vaktermen om verder te komen qua onderzoek over het plaatsen op een kompas.
Je wil voor iedere plaats op de schrijf op basis van de geografische coördinaten (Engels: geographic coordinates) lengte en breedte (Engels: longitude and latitude) in het coördinatenstelsel (Engels: Coordinate Reference System) WGS84 dus het azimut van de kompasrichting (Engels: azimuth of compass bearing) en de hemelsbrede afstand via de geodetische lijn / grootcirkel (Engels: geodesic / great circle) over de ellipsoïde (Engels: ellipsoidal distance) berekenen zodat je deze poolcoördinaten (Engels: polar coordinates) op schaal kan afbeelden (Engels: plot)?
Je hebt dan een lijstje met WGS84-coördinaten van plaatsen nodig. Op basis daarvan wil je de richting en afstand uitrekenen. Tenslotte heb je tools nodig om de teksten zonder overlap mooi af te afbeelden. Van deze 3 deeltaken kan ik je helpen bij de 2e.
Met de gratis open source software-bibliotheek PROJ kun je richtingen en afstanden tussen geografische posities exact berekenen. Dat kan bijvoorbeeld met de command line tool (OSGeo4W Shell) die met QGIS meegeleverd wordt. Met onderstaand commando voor de berekening van de geodetische lijn van punt 52,0000°NB; 5,0000°OL naar punt 53,0000°NB; 5,1000°OL krijg je output met 1 cijfer achter de komma (-f %f.1)
De output is dat vanaf punt 1 naar 2 het azimut 3,5 graden is, dat in punt 2 het azimut terug -176,5 graden is en dat de afstand tussen de twee punten 111483.823 meter is.
NB: Geografische coördinaten zijn zijn niet-Cartesisch (dus niet rechthoekig), de kortste verbinding tussen New York en Napels (die op dezelfde noorderbreedte liggen) gaat veel noordelijker over de Atlantische Oceaan. Het azimut van vertrek en aankomst is daardoor dus niet 90° en -90° (oost-west) maar in dit geval 57,6° en -57,6°:
Voor een waaier naar plaatsen over de hele wereld gaat deze aanpak met QGIS een behoorlijk onjuiste weergave van de richtingen en/of afstanden geven (afhankelijk van welke projectie je kiest)?
Voor binnen Nederland is RD (28992) inderdaad een prima oplossing. Misschien lukt het met een custom gnomische projectie voor het middelpunt ook redelijk voor plaatsen over de hele wereld? Mijn ervaring is echter dat de rendering van QGIS traag wordt en lelijke artefacten geeft als je zo’n projectie voor de hele wereld probeert te gebruiken. Met de gebruikelijke EPSG-codes, zoals latlon (4326), pseudo-Mercator (3857) of Mercator (3395), gaat het in ieder geval een behoorlijk vertekende weergave van de richtingen en afstanden geven. Vandaar mijn advies om de functie geod van PROJ te gebruiken.
De RD-projectie is niet afstandsgetrouw. Buiten Nederland kloppen de afstanden in de kaart niet. Of de afstanden die QGIS buiten Nederland berekent ook heel erg fout zijn of toch enigszins kloppen is afhankelijk van welke optie (respectievelijk Cartesisch of ellipsoïdisch) je in QGIS gebruikt voor het berekenen van de afstanden (zie mijn reactie in Hoe zit het nou met Cartesiaans en Ellipsoïdisch bij RD in QGIS? - QGIS - Geoforum).
Klopt, dat schreef ik ook al. Ik heb gewoon de RD-lijn-lengtes gebruikt, dus die kloppen echt niet. Maar binnen Europa een aardige benadering (niet nagerekend hoor) en ik neem aan dat deze vraag niet voor een wetenschappelijk onderzoek bedoeld is.
En, QGIS geeft geen rare artefacten (meer?) als je de hele wereld in RD toont.
Misschien lezen ze in Noord Korea wel mee om er zo achter te komen hoe ze hun raketten naar de andere kant van de wereld kunnen afvuren
Het deed me denken hoe complex de berekening was voor de eerste raket naar de maan, dat werd allemaal handmatig berekend. Naast de baanberekeningen werden er ook kaarten gemaakt met bekende sterren die als richtpunt gebruikt werden. Dat handmatige hoeft nu gelukkig niet meer en ik denk ook dat topicstarter het niet zo nauwkeurig hoeft
Ik heb geen idee hoe je dit soort kaartjes noemt, zou het een naam hebben?
@Jochem Dank voor alle termen, dat geeft me wat duidelijke aanknopingspunten.
@Anton@raymondnijssen Mooi te zien dat m’n vraag wat QGIS experimenten heeft getriggerd.
Idd niet zeer wetenschappelijk, meer informatief. Vergelijk het soms met die bordjes die ergens staan hoe ver een lokatie is verwijderd van een bep. wereldstad. Ik update dit draadje wel met mijn voortgang, bevindingen en demo’s.
Ik weet hier geen verzamelnaam voor maar het zijn kaartjes in een azimutale-equidistante projectie, waarbij de richtingen en afstanden vanuit een bepaalde locatie kloppen.
Dat is wat ik bedoelde met een custom projectie. Volgens mij gaat hier wel nog iets mis. Ik denk dat het lat_0=52 moet zijn in plaats van y_0=52. Deze aanpak lijkt me prima voor de weergave. De fout door bijvoorbeeld de 21 km afplatting van de aarde te verwaarlozen ga je met het blote oog niet zien. Als je echter bij de richtingen een getal zet voor de afstand in km dan is het jammer als dat niet ook wel ongeveer op de km klopt. Dus daarvoor is de functie geod toch nog wel handig.
Qua projecties kan ik het deels volgen. Niettemin wikipedia legt verschillen redelijk duidelijk uit.
Ook deze pagina is handig. Mijn doel is om het meeste in javascript (web) te berekenen, tenzij ik performance problemen merk (dan kan ik een backend gebruiken).
Als je ipv R een parameter ‘ellps’ meegeeft aan de projectiestring, gaat het dan wel goed?
Verder zou ik eerder een R van 6378137 meegeven (de waarde van de semi major axis in WGS84) of het gemiddelde van de semi major axis en semi minor axis (6356…) meegeven voor een iets betere schatting.
