Springen naar inhoud

Veel data samenvoegen tot pooldiagram


  • Log in om te kunnen reageren

#1

pientertje

    pientertje


  • 0 - 25 berichten
  • 13 berichten
  • Gebruiker

Geplaatst op 23 maart 2012 - 15:42

Hallo,

Ik ben bezig met het ontwikkelen van een systeem dat de prestaties van een zeilboot meet en deze gebruikt om een route te plannen. Belangrijke gegevens zijn windkracht, hoek van inval van de wind en de snelheid. Je zou voor een bepaalde windkracht een pooldiagram kunnen maken waarin snelheid en invalshoek van de wind afgebeeld staan. Als je daarbij ook nog eens uitgaat van de symmetrie krijg je zoiets:
Geplaatste afbeelding

Een systeem om de data te loggen is niet het probleem, maar ik weet niet hoe ik de verwerking van de data moet aanpakken. Ik krijg heel veel datapunten waar ik per punt drie gegevens nodig heb, namelijk windkracht, invalshoek van de wind en de snelheid. Wat ik echter nodig heb bij het plannen van de route en het maken van de diagrammen is een systeem waaraan ik kan vragen: "Wat is de snelheid bij 12 knopen wind en een invalshoek van 38 graden?". Een waarde die hoogstwaarschijnlijk niet gemeten is. Ook als het punt wel gemeten is, is deze enkele meting niet precies genoeg.

Mijn probleem bestaat dus eigenlijk uit de volgende twee vragen:
- Hoe sla ik de grote hoeveelheden data efficiŽnt op? Moet alle data bewaard blijven, of kan ik punten samenvoegen als ik bijvoorbeeld van tevoren zeg dat 1 graad resolutie genoeg is?
- Hoe haal ik uit al deze (drie dimensionale) punten een nieuw waarde? En dan wil ik niet alleen interpoleren, maar ook een soort van gewogen gemiddelde uit meerdere waarden om eventuele uitschieters te filteren.

Alvast bedankt!

Dit forum kan gratis blijven vanwege banners als deze. Door te registeren zal de onderstaande banner overigens verdwijnen.

#2

P12

    P12


  • 0 - 25 berichten
  • 2 berichten
  • Gebruiker

Geplaatst op 24 maart 2012 - 20:26

Als ik snel even analyseer wat je schrijft, heb ik mijn twijfels bij het begrip veel data.
Stel we hebben een resultie van 1 graad en 1 knoop.
Dan zouden we met 10 metingen voor elke 360 graden en elke 40 knopen (Even van zeilbare windsnelheden
uitgaande) komen op 144000 meetpunten. Dat is nou niet echt veel te noemen vanuit een data-beheer oogpunt.

Zelf zou ik kiezen om een x aantal punten (bijvoorbeeld 50) te kiezen die het dichtst bij de opgegeven waarde komen,
en dan, zoals je zelf al sugereerde, hieruit een gewogen gemiddelde te berekenen.

Klinkt als appeltje eitje.

#3

pientertje

    pientertje


  • 0 - 25 berichten
  • 13 berichten
  • Gebruiker

Geplaatst op 25 maart 2012 - 14:40

Het is een database waar maanden lang aan data in komt, met een snelheid van 1 sample per seconde zijn dat een hoop punten (2,6 miljoen per maand).

Klopt deze berekening dan?

1 - Neem (bijvoorbeeld) 50 punten die het dichtste bij het te berekenen punt liggen.
2 - Vermenigvuldig elk van de drie coŲrdinaten van dat punt (snelheid, hoek en windkracht) met ťťn gedeeld door de drie dimensionale afstand tot het te berekenen punt (3d- pythagoras).
3 - Tel alles op
4 - Deel door de som van alle (1/afstand)

Veranderd door pientertje, 25 maart 2012 - 14:40


#4

P12

    P12


  • 0 - 25 berichten
  • 2 berichten
  • Gebruiker

Geplaatst op 26 maart 2012 - 07:50

Ik had begrepen dat je een vraag had over het opslaan van grote hoeveelheden data. Maar ik zie nu dat je die al in een database opslaat. Dan ga ik er even van uit dat je ook weet hoe je die gegevens er weer uit haalt.

Voor elk van de 50 punten moet je een wegingsfactor inbouwen. Elke waarde van een punt vermenigvuldig je met de wegingsfactor, en het totaal deel je door de som van de wegingsfactoren. In je voorbeeld doe je dat inderdaad goed.

Toch zijn er nog twee opmerkingen te maken, waar je je voordeel mee kunt doen.

1. Er klopt iets niet aan mijn eerste idee om de 50 dichtstbijzijnde waardes te nemen. Stel even een tweedimensionaal probleem voor met een gegeven x en een y die je wilt berekenen. Dan zou het kunnen zijn de 50 dichtstbijzijnde punten allemaal links van het gegeven punt liggen, waardoor een gemiddelde dus niet overeenkomt met je x. Om preciezer te zijn, zou je 50 punten dicht om x moeten vinden, waarvan het gewogen gemiddelde x goed benaderd. Ik moet nog even denken hoe je dat het snelst kune bereiken. Hier kom ik nog op terug.

2. De wegingsfactor die jij in je voorbeeld neemt is omgekeerd rechtevenredig met de afstand. Omdat we hier iets fysisch berekenen, dat ook nog eens met snelheid te maken heeft denk ik dat het ook zo zou kunnen zin dat de wegingsfactor een kwadratische/wortel relatie heeft met de afstand. Ik zou als ik punten verzameld heb een echt meetpunt nemen en met verschillende factoren een berekening maken via andere punten. Degene die het dichtst bij de meetwaardes komt zou ik dan als standaard formule gebruiken. Dus gewoon wetenschappelijk werken: Meetgegevens verzamelen, en hierbij de best passende formule vinden.

Nog 2 andere dingen:

1. Als je een verzameling van 2,6 miljoen meetpunten hebt die verdeeld zijn over 360*40 =14400 waardes, dan is de kans bijna nul dat je een specifieke waarde niet hebt (Een optie die je oorspronkelijk aangaf.) Dit is natuurlijk als de kansen gelijkwaardig verdeeld zijn, wat natuurlijk niet is.

2. Ik snap niet hoe je 24 uur per dag elke seconde meetgegevens binnenkrijgt? Ga je een reis om de wereld zeilen? Bonvendien zul je dan vooral lange rakken zeilen met continue ongeveer dezelfde hoek, windsnelheid en rompsnelheid. Dus vraag ik me dan af wat de waarde is van 3600 meetpunten per uur die bijna allemaal gelijk zijn.

Veranderd door P12, 26 maart 2012 - 07:52






0 gebruiker(s) lezen dit onderwerp

0 leden, 0 bezoekers, 0 anonieme gebruikers

Ook adverteren op onze website? Lees hier meer!

Gesponsorde vacatures

Vacatures