Autor Thema: Entfernungen bestimmen (Gelesen 27883 mal)

eknori · « **Antwort #40 am:** 07.03.04 - 06:25:56 »

das sieht doch schon mal gut aus

eknori · « **Antwort #41 am:** 07.03.04 - 07:15:22 »

Hier die importierten Daten.

Axel_Janssen · « **Antwort #42 am:** 07.03.04 - 11:10:34 »

Als ich vor lauter Begeisterung anfing eine Maske zu basteln, stellte ich fest, dass die Namen der Städte in einer Dialogliste die 65 kb Grenze sprengt.

Muß jetzt wohl Picklist nehmen.

Danke auf jeden Fall für die Daten.

Gruß Axel

eknori · « **Antwort #43 am:** 07.03.04 - 16:21:16 »

habe hier noch einen Link mit recht umfangreichen Koordinaten gefunden http://opengeodb.de/index.php
Darüber hinaus bietet die Seite noch Scripte in PHP zur Umkreissuche. Da sollte sich doch rausfinden lassen, wie man das nach LS portiert.

Ulrich

eknori · « **Antwort #44 am:** 07.03.04 - 16:41:08 »

Ich habe den gestern auf meiner Webseite goposteten Code noch einmal überarbeitet. Es können jetzt Koordinaten aller Himmesrichtungen verwender werden. Daher ist nun eine weltweite Erntfernungsbestimmung möglich ...
http://www.eknori.de/downloads/detail.php?nr=509&kategorie=downloads

Onkel Domino · « **Antwort #45 am:** 07.03.04 - 16:46:53 »

Zitat von: eknori am 07.03.04 - 16:21:16

habe hier noch einen Link mit recht umfangreichen Koordinaten gefunden http://opengeodb.de/index.php

Super Sache! Da ist ja alles drin was wir gebraucht haben und ich kann mir die Arbeit mit den PLZ sparen :-)

Habe das mal soweit nach PLZ, Ort, Breiten- und Längengrad umgestellt.

Onkel Domino · « **Antwort #46 am:** 07.03.04 - 17:02:09 »

Bezüglich der Umkreissuche habe ich mir auch nochmal Gedanken gemacht. Vielleicht war Don's Idee das als Graphen zu modellieren (Adjazenzmatrix) doch gar nicht mal so schlecht. Dazu bräuchte man allerdings die jeweiligen Entfernungen zwischen den PLZ.

Wir bauen uns den Graphen mit den PLZ als Knoten und den Entfernungen als Kanten. Jetzt nehmen wir allerdings keine Matrix, sonder stellen den Graph als Adjazenzliste dar. Die Liste müssen wir allerdings noch ein wenig modifizieren und zwar in soweit, dass sie uns nicht nur die nächste PLZ angibt, sondern ein Tupel bestehend aus (PLZ x Entfernung).

Wenn man nun der Funktion die PLZ und die Entfernung übergibt, geht es damit durch die Adjazenzliste, liefert die angrenzenden PLZ und zieht jedesmal die in der Liste hinterlegte Entfernung ab bis die übergebene Entfernung kleiner gleich null ist.

So sollte das theoretisch klappen.

Leider habe ich nicht die Programmierkenntnisse das umzusetzen. Vielleicht gibt es aber auch noch einen einfacheren Weg?!

Viele Grüße,
Markus

eknori · « **Antwort #47 am:** 07.03.04 - 17:05:14 »

Super, hatte ich auch gerade fertig

Da die Längen und Breitengrade ja schon umgerechnet sing, kann man mein COding noch weiter abspecken. Jetzt müssen die Daten lediglich noch mit RADIAN multipliziert werden und können dann gleich an die Formel übergeben werden.

eknori · « **Antwort #48 am:** 07.03.04 - 17:24:38 »

wenn du über Deutschland hinausgehende infos brauchst ...

http://earth-info.nima.mil/gns/html/cntry_files.html

das Thema macht spass, so als kleines Wochenend Chillout ...

und weil das Forschen so viel Spass macht, hier noch gleich die Koordinaten der Grenzen der Bunten Republik Deutschland

http://www.maproom.psu.edu/dcw_data/germany2pts.txt

Glombi · « **Antwort #49 am:** 07.03.04 - 18:27:38 »

Hallo Ihr!
Kaum ist man 2 Tage nicht Online und schon ist die Diplomarbeit von Onkel Domino fertig

Beeindruckend, sehr beeindruckend

Ich muss mir das alles mal in Ruhe ansehen.

Andreas

eknori · « **Antwort #50 am:** 07.03.04 - 18:29:39 »

vergiss nicht, die Formel zur Umkreisberechnung auf Grundlage der Koordinaten zu posten, bitte

eknori · « **Antwort #51 am:** 07.03.04 - 18:46:27 »

Habe gerade noch ein bisschen rumgespielt. man kann doch die Suche entsprechend vordefinieren und 10, 20 .. 50 .. 100 km anbieten. Damit sind auch die Bogenminuten bekannt, die zum aktuellen Standort in nördlicher und östlicher Richtung hinzuaddiert und in südlicher und westlicher Richtung abgezogen werden müssen.
Damit stehen auch die Koordinaten des sich ergebenden Rechteckes fest. ( wg. der Abflachung der Erde kein quadrat )
Und mit diesen Angaben müsste doch ein entsprechendes db.Search zu definieren sein.

Ulrich

Onkel Domino · « **Antwort #52 am:** 07.03.04 - 19:30:44 »

Hi Andreas,

ja der Ulrich war sehr fleissig und hat uns viel nützliche Links sowie eine erste DB geliefert

@Ulrich:
Das mit der vordefinierten Such ist eine gute Idee! Ist auch viel einfacher das "direkt" auszurechnen als über eine verkettete Liste. Da hätte ich dann wohl mit Kanonen auf Spatzen geschossen

Axel_Janssen · « **Antwort #53 am:** 07.03.04 - 21:47:40 »

Zitat von: eknori am 07.03.04 - 18:46:27

Habe gerade noch ein bisschen rumgespielt. man kann doch die Suche entsprechend vordefinieren und 10, 20 .. 50 .. 100 km anbieten. Damit sind auch die Bogenminuten bekannt, die zum aktuellen Standort in nördlicher und östlicher Richtung hinzuaddiert und in südlicher und westlicher Richtung abgezogen werden müssen.
Damit stehen auch die Koordinaten des sich ergebenden Rechteckes fest. ( wg. der Abflachung der Erde kein quadrat )
Und mit diesen Angaben müsste doch ein entsprechendes db.Search zu definieren sein.

Hi,

Es scheint jetzt darum zu gehen, die Suche zu optimieren, cierto?
Ein brute force Vergleich aller Entfernungen von Wert Kunde bis Wert Niederlassung dauert möglicherweise dann doch zu lang.

Das Zielquadrat sind ja von/bis Werte.
Man bräuchte also eine Art "and"-Verknüpfung.
Es ist vermutlich, wenn man die Koordinaten in Zahlen umrechnet.

Köln ist als Breitengrad: 50N5633
also (50 * 10000) + (5633 * 1)

Gruß Axel

bin auch nicht so der Mathe-Bär. Find die Aktion klasse.

eknori · « **Antwort #54 am:** 08.03.04 - 07:11:35 »

dann sollten wir gleich die Daten aus der openGeoDB nehmen, das erspart dann das Umrechnen.

Glombi · « **Antwort #55 am:** 08.03.04 - 08:27:36 »

Ich habe das schon mal gemacht und werde es heute Abend rauskramen (zur Zeit bin ich unterwegs und komme da nicht heran...).
Prinzipiell geht es so: Die Koordinaten müssen von der Form GG MM SS,SSSS (Grad Minuten Sekunden) in die Form GG,GGGGGG umgerechnet werden. Dort dann denn Offset (d.h. den gewünschten Radius = Umkreis) addieren und alles was dann kleiner ist, gehört dazu.
Zu bedenken ist noch, das Notes in Rad und nicht in Grad rechnet, also muss noch transformiert werden.

Andreas

eknori · « **Antwort #56 am:** 08.03.04 - 08:35:52 »

Andreas:

die DEG - RAD Tranformation ist bereits in der Formel berücksichtigt.

eknori · « **Antwort #57 am:** 08.03.04 - 17:14:03 »

Hier die openGeoDB Daten in Notesform ( PLZ, City, Länge, Breite ) ca 14.000 EInträge

eknori · « **Antwort #58 am:** 08.03.04 - 18:20:45 »

habe mal meine Idee zur Umkreissuche al kurz aufgesribbelt. Sollte aber im Prinzip so funktionieren.
Man möge mir meine mathematischen Unzulänglichkeiten entschuldigen . Aber ich denke mal, es kommt rüber, wie es gemeint ist

P1
|
|
|
|
|
|
|
|

P4<----------------P0------------------>P2
|
|
|
|
|
|
|
|
P3

P0 wird beschrieben durch l0 und b0

bei einem Umkreis von 10km ergibt sich ein Offset_L von 5'24'' und ein Offset_B von 8'38''

also gilt

P1 = l0 + Offset_L
P3 = l0 - Offset_L
P2 = b0 + Offset_B
P4 = b0 - Offset_B

Gültige Werte z.B. für das durch P0,P1 und P4 definierte Rechteck werden beschrieben durch

coord = AllDocs (<= P1 & >= P4)

wobei P1 und P4 Länge und Breite des Docs repräsentieren

Stellt man nun für alle Rechtecke ausgehend von P0 die Formeln aus und vereinfacht man diese anschließend, so werden
die gültigen Dokumente durch die Formel

collection = AllDocs ( =<P1 & >= P3 ) & ( >= P4 & =< P2 ) beschrieben

Ulrich

anzumerken ist noch folgendes: ich reduziere/ erweitere (?) die Umkreissuche zwar auf eine Planquadratsuche. Dieses Planquadrat ist natürlich flächenmäßig größer als die Fläche des Kreises. Aufgrund der natürlichen Streuung der Städte sollte sich aber eine genügende Genauigkeit ergeben.

Glombi · « **Antwort #59 am:** 08.03.04 - 21:41:51 »

Hi,
ich habe leider wenig Zeit, daher in Kürze das Wesentliche...

Anbei das was ich damals gerechnet habe:
1. Die Koordinaten der Form GG MM SS,SSSSS werden in GG,GGGGGGGG umgerechnet.
Formel: GG,GGGGGGGG = GG + (MM + SS,SSSSS / 60) / 60

In Script dann die Variablen
DezGrad_Laenge
DezGrad_Breite

2. Offset Breite bei Radius R in [km]
Es ist 1 GG (1 Grad) = 60 NM (Nautische Meilen), also 1 GG = 60 * 1,852 km

Offset Breite = R / (60 * 1,852 km)

Offset Länge = Cos(Grad Breite)

In Script

'grad_breite = GG Angabe in GG MM SS...

offset_breite = radius_km / (60 * 1.852)
'Hinweis: Script rechnet Cos Funktion mit Radiant, daher erst von Grad nach Rad umwandeln
grad_rad_breite = grad_breite * (Pi / 180)
cos_grad_rad_breite = Cos(grad_rad_breite)
offset_laenge = offset_breite / cos_grad_rad_breite

'***** Berechne untere und obere Grenze für die dez. Koordinaten
LBound_DezGrad_Laenge = DezGrad_Laenge - offset_laenge
UBound_DezGrad_Laenge = DezGrad_Laenge + offset_laenge

LBound_DezGrad_Breite = DezGrad_Breite - offset_breite
UBound_DezGrad_Breite = DezGrad_Breite + offset_breite

'Abfrage aller Punkte, ob diese im Umkreis liegen

'***** Prüfe ob Koord. im Intervall (Quadrat) liegen
      If ( (LBound_DezGrad_Laenge <= DezGrad_Laenge_Target) And (UBound_DezGrad_Laenge >= DezGrad_Laenge_Target) ) And _
      ( (LBound_DezGrad_Breite <= DezGrad_Breite_Target) And (UBound_DezGrad_Breite >= DezGrad_Breite_Target) ) Then

'Koord. liegt im Umkreis

end if

Das sollte sich eigentlich mit dem bereits geleisten Arbeiten von eknori decken...

Gruß
Andreas

Autor Thema: Entfernungen bestimmen (Gelesen 27883 mal)

Glombi

Glombi

Glombi