Sorry für die späte Antwort - irgendwie gehen die AHK - Benachrichtigungen vorbei.

[quote="just me" post_id=544677 time=1698401813 user_id=148]
...Hast Du Lust und Zeit, das auch einmal zu probieren? ...[/quote]
Danke, derzeit nicht. Es läuft derzeit gut und in andere Kleinfunktionen eingepackt - da bin ich derzeit zufrieden.

Moin [mention]Peter2[/mention],

ich habe das jetzt mal mit der 0.5-Datei auf meinem lüfterlosen Mini-PC mit Celeron N5100, 8 GB RAM, einer SSD der unteren Preisklasse und Win 10 Pro /AHK 64-Bit ausprobiert.

Das Überführen der 4 Millionen Datensätze in deine SQLite-Datenbank mit passendem Index dauert - wenn man alle notwendigen Schritte kennt - nicht einmal eine Minute. Die Dauer vom Start eines AHK-Skripts für die Abfrage mit den X/Y-Koordinaten des Datensatzes 3999999 bis zur Ausgabe der Z-Koordinate ist für mein Zeitempfinden kaum spürbar. Hast Du Lust und Zeit, das auch einmal zu probieren? Ich würde dann hier eine Anleitung für das Erstellen der DB und ein Testskript einstellen.

Also die Daten sind hier frei verfügbar:
https://www.swisstopo.admin.ch/de/geodata/height/alti3d.html#dokumente

Bei 0.5m hat man 4 Mill. Zeilen, und man kann mehrere Dateien auch mergen und d en Computer quälen.

Hallo [mention]Peter2[/mention],

wenn Du hast, was Du brauchst, ist das ok.
Trotzdem schade, es hätte mich interessiert, wie schnell SQLite mit 4 Millionen Tabellenzeilen arbeiten kann.

Mach's gut,
just me

Servus [mention]just me[/mention]
danke für den Hinweis mit den zwei Skripts. Ist für die weitere Zukunft auch in anderen Dingen sicher eine Option. Das SQl-Thema ist sicher sehr ausgetüftelt, aber ich bin derzeit wirklich unter einer Sekunde im Gesamtablauf - "Autocad - Aufruf AHK - Rückgabe an Autocad", und damit kann ich leben, zumal das Programm nicht 24/7/52/365 laufen wird.

:bravo:

Moin [mention]Peter2[/mention],

wenn Du ein mehrfaches Einlesen verhindern willst, fallen mir spontan zwei 'einfache' Lösungen ein.

[list=1][*]Du verteilst die Suche auf zwei Skripte.
Das erste wird einmal gestartet, liest die Datei ein und 'wartet' dann in einer Schleife darauf, dass eine Datei mit einem Koordinatepaar gefüllt wird. Die werden dann eingelesen, die dritte Koordinate wird ermittelt und die Datei dann gelöscht.
Das zweite Skript schreibt nur die Koordinatepaare in die Datei.
[*]Du schreibts die Koordinaten in eine SQLite-Datenbank. Das hört sich vielleicht schlimmer an, als es ist. Dann kannst Du per SQL-Anweisung direkt aud die DAten zugreifen, ohne vorher lesen zu müssen. Ich bin gern bereit, Dich bei der Umstellung zu unterstützen.[/list]

Außerdem mag es sich anbieten, das Skript einmal zu starten, die Datei einzulesen und dann die Eingabe der gesuchten Koordinaten per Hotkey auszulösen.

[quote="just me" post_id=544007 time=1697888149 user_id=148]
....Du könntest mal RegExMatch() ausprobieren:...
Das mag aber bei sehr großen Datenmengen Probleme bereiten.
[/quote]
Fantastisch. Für den gleichen Suchlauf jetzt 0.3 sec. statt 3.5. Damit ist das andere Thema - die Zeit für das Einlesen - eigentlich erledigt.

Danke, werde ich gleich testen.

Aber derzeit wurschtle ich bei einem anderen "Zeitfresser-Problem" herum.

Der Code hat den Ablauf:
a) lese die Datei in eine Variable
b) durchsuche die Variable

Schritt a) wiederholt sich jedesmal, was ja eigentlich sinnlos ist. ich müsste nur einmal lesen, dann immer wieder die Variable durchsuchen.

Da stolpere ich aber über die Grundlogik "Programmaufruf - Programm ruhen - Programm im zweiten Schritt aufrufen".
Ist für Kenner sicher mit zwei (richtigen) Zeilen erledigt.
Welche sind das?

#NoEnv
#Persistent
SetBatchLines, -1
SetWinDelay, 0
#SingleInstance,Force

FileRead, DateiInhalt, d:\05.xyz
MsgBox Eingelesen!
X := "2698575.25"
Y := "1280000.25"
If RegExMatch(DateiInhalt, "m)^" . X . " " . Y . " \K.+$", Z)
   MsgBox, %Z%
Else
   MsgBox, Kein Treffer für %X%/%Y%!

Moin,

Du könntest mal RegExMatch() ausprobieren:
[code]#NoEnv
#Persistent
SetBatchLines, -1
SetWinDelay, 0
#SingleInstance,Force

FileRead, DateiInhalt, d:\05.xyz
MsgBox Eingelesen!
X := "2698575.25"
Y := "1280000.25"
If RegExMatch(DateiInhalt, "m)^" . X . " " . Y . " \K.+$", Z)
MsgBox, %Z%
Else
MsgBox, Kein Treffer für %X%/%Y%!
[/code]
Das mag aber bei sehr großen Datenmengen Probleme bereiten.

#NoEnv
#Persistent
SetBatchLines, -1
SetWinDelay, 0
#SingleInstance,Force


FileRead, OutputVar, d:\05.xyz
msgbox eingelesen

Loop, parse, OutputVar, `n, `r  ; Specifying `n prior to `r allows both Windows and Unix files to be parsed.
{
    zeile := StrSplit(A_LoopField, A_Space)
   if (zeile[1] = 2698575.25 and zeile[2] = 1280000.25)
   {
    hoehe := zeile[3]
      MsgBox %hoehe%
    }
}
msgbox fertig

So, mit diesem Standardcode komme ich auf ca. 5 sek bei Sucherfolg in der 4-Millionsten-Zeile, somit im Durchschnittsbereich 2-3 sek. Bin fürs erste zufrieden, aber schneller geht immer.

[code]#NoEnv
#Persistent
SetBatchLines, -1
SetWinDelay, 0
#SingleInstance,Force


FileRead, OutputVar, d:\05.xyz
msgbox eingelesen

Loop, parse, OutputVar, `n, `r ; Specifying `n prior to `r allows both Windows and Unix files to be parsed.
{
zeile := StrSplit(A_LoopField, A_Space)
if (zeile[1] = 2698575.25 and zeile[2] = 1280000.25)
{
hoehe := zeile[3]
MsgBox %hoehe%
}
}
msgbox fertig[/code]

Edit:
Thema passabel gelöst, aber als Challenge bin ich auf Verbesserungen gespannt.

-------------------------------------------------------

Ich habe Textdateien, die enthalten bis zu 4 Mill. Zeilen Koordinaten - einfache XYZ-Sammlungen.

123456.50 568412.75 123.25
....

Das erstmalige Einlesen der Datei selbst darf die entsprechenden Sekunden dauern, dann sollte das im Speicher bleiben.

Jetzt geht es darum, durch einen CLI-Aufruf eines anderen Programms aus dieser Variable den dritten Wert zu suchen, also...
- suche 123456.50 568412.75
- ermittle den dritten Wert
- gib den dritten Wert irgendwie zurück

Dass ich das "irgendwie" schaffe hoffe ich schon, aber bevor ich da lange in die falsche Richtung laufe:
- Welche Funktionen empfehlen sich für eine möglichst [b]schnelle [/b] Lösung?
- Das sollte auf "klick-zack" funktionieren ;-)
- Und das natürlich immer wieder

Danke im voraus und schönes Wochenende
Peter