Ik kom niet uit het volgende. Mocht iemand me even kunnen helpen, bedankt.
Ik wil waarden zetten in rijen van mijn tabel die gegenereerd worden uit waarden uitdezelfde rijen. Hier gebruik ik de PHP functie getting_the_closest(53.2045314315038,5.77743964367885); voor die resulteert in dit voorbeeld als output: 391.28,53.206656065508,5.7821233028534
Ik gebruik deze functie om de waarden uit de kolommen lat en lng van elke rij in te lezen.
Zegmaar als voorbeeld:
lat lng
53.2045314315038 5.77743964367885
De output van deze functie wil ik in dezelfde rij krijgen gezet in de kolommen meters_closest lat_closest lng_closest zoals in dit voorbeeld.
De waarden in lat en lon staan dus al vast en de overige rijen van mijn kolommen meters_closest, lat_closest en lng_closest moeten dus gevuld worden met de berekening die getting_the_closest maakt met input van waarden uit elke zelfde rij van de table1. Het is de bedoeling dat ik alle rijen in de tabel table1 zo gevuld krijg.
Waar loop je vast want je hebt al een complete specificatie van wat er moet gebeuren? Wat je waarschijnlijk nog moet doen is alle coordinatenparen doorlopen en dan kijken wat de kleinste meters_closest is?
En kan het ook niet voorkomen dat een specifieke lat, lng combinatie meerdere "closest" coordinaten heeft? Dus misschien zou je een aparte "closest" tabel moeten introduceren voor een-op-veel relatie?
Nou, gezien de precisie van lat/lon ga er vanuit dat er altijd 1 de closeste is. Misschien scheelt het maar een mm, maar dan heeft ie toch gewonnen ;-)
Ik heb niet de ervaring om de rijen door te lopen en op te vullen. De functie getting_the_closest heb ik al in PHP geschreven. Dit is een aangepaste versie van https://www.geodatasource.com/developers/php Ik gebruik mysql meestal gewoon vanuit navicat of phpmyadmin voor dit soort dingen. Alleen ik ben nu afhankelijk van de functie waarbij ik ook PHP nodig heb.
Ik heb uiteraard wel een database verbinding en mogelijkheid voor queries te maken enzo. In dit geval PDO maar alles is welkom.
Maar je zult alle coordinatenparen af moeten lopen om te kunnen constateren welke relatief gezien het dichtste bij is ten opzichte van een opgegeven coordinatenpaar? Dit kun je prima in PHP doen. Haal alle lat-lon paren op, bereken de afstand ten opzichte van dit opgegeven paar en onthoud de laagste afstand die je tegenkomt, en welk record hier bij hoort. Vervolgens kun je een UPDATE doen op het record met het dichtsbijzijnde paar. Of ik begrijp niet hoe je al deze paren wenst te combineren.
Idealiter refereer je aan dit record via een (intern auto-increment) id, en niet de specifieke lat-lon waarden.
Stel echter dat je de coordinatenparen A, B en C in je database hebt zitten.
Vervolgens heb je een paar X, waarvan je wilt weten of deze het dichtst bij A, B of C ligt. Hier komt bijvoorbeeld B uit. Maar nu heb je een ander paar Y, verschillende van X, waarbij de uitkomst ook B is. Wordt X dan door Y vervangen als Y dichterbij is, of zijn beide resultaten relevant en zul je dus de mogelijkheid moeten hebben om meerdere paren op te hangen aan B?
Rob Doemaarwat op 30/10/2019 16:11:29
Nou, gezien de precisie van lat/lon ga er vanuit dat er altijd 1 de closeste is. Misschien scheelt het maar een mm, maar dan heeft ie toch gewonnen ;-)
Zeg nooit nooit :). En wie zegt dat een verschil onder, ik zeg maar wat, de vijf(tig) meter inhoudt dat beide coordinaten "gelijkwaardig" zijn? Als dit bijvoorbeeld bushaltes en openbare toiletten zijn ofzo, dan zijn beide relevant, en maakt het niet zoveel uit welke je kiest. Je sluit dan in ieder geval niet op voorhand een keuze uit.
Thomas, achter de functie getting_the_closest hangen een aantal lengte en breedtegraad punten van kantoren. Als ik die functie dus vergelijk met een lengte en breedtegraad uit de tabel dan zal automatisch het dichtsbijzijnde kantoor gekoppeld worden. Dus het aantal meters en de lengte en breedtegraad punten. Als die eenmaal in de tabel staan kan ik die weer met een JOIN koppelen aan de adressen hier van.
Zou je de kantoren dan niet als uitgangspunt moeten nemen? Waar komen deze lengte- en breedtegraden in de tabel vandaan dan, en wat voor relevantie hebben deze? En zou je die coordinaten dan niet aan een kantoor(id) moeten koppelen in plaats van de lengte- en breedtegraden van de desbetreffende kantoren?
Thomas, dit zijn gewoon kadastrale adressen. Er zijn ook nog meerdere kolommen. De tabel table1 heeft bijvoorbeeld al een kolom ID Maar om de complexiteit te beperken van de vraag heb ik die uitgesloten in dit onderwerp.
Het databaseontwerp zou in ieder geval voort moeten vloeien uit een functionele spec, en in dienst moeten staan van de dingen die je hier mee wilt kunnen doen.
Zolang je niet aangeeft wat dit alles zou moeten doen kunnen we je met geen goed fatsoen adviseren wat te doen. Hierbij helpt het dus om een (zo) volledig (mogelijk) plaatje te schetsen, anders wordt het zo'n schaakspel om informatie los te peuteren.
Ik kijk in eerste instantie naar aanpak, en geef niet zomaar een directe "oplossing", simpelweg omdat het heel vaak niet vaststaat of het wel een oplossing is, of dat de ingeslagen oplossingsrichting uberhaupt een juiste/slimme is.
Met de onvolledige informatie die ik nu hebt lijkt het er op dat de database nog niet helemaal (of helemaal niet) uitgenormaliseerd is, of die functie getting_the_closest() moet informatie vissen uit een andere tabel waar we geen weet van hebben.
En als je dan verbanden hebt tussen informatie in verschillende tabellen, dan lijkt het mij het beste om deze verbanden echt vast te leggen in (foreign) keys / constraints, zodat je uiteindelijk ook echt een relationele database hebt, in plaats van tabellen die als los zand aan elkaar hangen via coordinatenparen.
Ik weet niet hoeveel coördinaten er in je tabel zitten, maar om te voorkomen dat je steeds getting_the_closest() voor elk coördinaten paar door moet rekenen zou je ook in je query al een hele grove benadering kunnen doen, en dan de top zoveel ophalen. Alleen met die top zoveel ga je dan de closeste op 6 cijfers achter de komma bepalen (en dus meteen de meters_closest).
select * from tabel
order by power(lat - :lat_kantoor,2) + power(lon - :lon_kantoor,2)
limit 10
