[ORP] Diskussion der Import-Klasse

[Mithrandir]

(Prolog: Wie einige von euch sicher wissen, arbeite ich momentan an einem Routenplaner auf Basis der Daten von OpenStreetMap. Um Threads zu kennzeichnen, die sich speziell mit diesem Projekt beschäftigen, nutze ich die Zeichenfolge "[ORP]". ("Orp, orp..." :stupid: )

Hi ihr,

es ist soweit. Der erste Teilschritt auf dem Weg zum Routenplaner ist geschafft. Dabei handelt es sich um die Klasse, die die XML-Datei verarbeitet, die Daten für die Datenbank aufbereitet und in eine Firebird-Datenbank schreibt.

Da mein letztes Delphi-Programm ja schon etwas her ist (tjaja...), wäre es mir ganz lieb, wenn ihr einen Blick auf meine Klassenimplementation werfen könntet.

Ich bekommen, wenn ich den Import abbreche (einfach das Programm schließen) eine Exception, außerdem steigt der Speicherverbrauch aus welchen Gründen auch immer während des Imports exorbitant an. Vermutlich gibt es irgendwo ein oder mehrere Speicherlecks, die ich einfach übersehe. Ich habe mich schon mit MemCheck abgemüht, aber nicht wirklich Erfolg gehabt. Vielleicht kann einer von euch damit besser umgehen?

Um euch das Testen einfacher zu machen, befindet sich im Anhang eine OSM-Testdatei, die ich ein wenig zusammengestaucht habe. Die Originaldatei ist 25 MB groß, diese nur noch 1,5 MB, beinhaltet aber alles, was man zum Testen brauch'. Außerdem würde die Datenbank eigentlich im Anwendungsdatenverzeichnis des akutellen Nutzers liegen. Für Testzwecke liegt sie jetzt aber im Programmverzeichnis, damit ihr nicht erst durch alle Verzeichnisse springen müsst.

Ebenfalls mit dabei ist der Firebird Embedded in der Version 2.1.

Zum erfolgreichen kompillieren benötigt ihr noch die ZEOSLib, der Download dazu findet sich hier [Sourceforge, 1.6 MB]

Das Projekt hat ebenfalls schon einen "richtigen" Namen bekommen: OpenRoutePlanner. Einen entsprechenden Blog dazu gibt es auch schon.

Ich weiß, dass da noch ein riesiger Berg an Arbeit vor mir liegt, aber mit eurer Hilfe klappt das schon... ;)

Noch ein kleiner Hinweis: Die Eingabemaske prüft nicht, ob der eingegebene Pfad korrekt ist. Außerdem wird der Starten-Button nicht deaktiviert. Ich hoffe, ich habe sonst alles beachtet. :stupid:

[DP-Maintenance]

Dieses Thema wurde von "mkinzler" von "Object-Pascal / Delphi-Language" nach "Open-Source" verschoben.
Ist ja ein Projekt, dass im Source vorliegt

[oki]

Hi,

ich glaube, deine Schutzverletzung beim Beenden kommt daher:

Delphi-Quellcode:

procedure TForm1.FormClose(Sender: TObject; var Action: TCloseAction);
begin
  if Assigned(OSMParser) then
    OSMParser.Destroy;
end;

Ich dächte, dass ist sicherer sollte der Thread noch immer da sein:

Delphi-Quellcode:

procedure TForm1.FormClose(Sender: TObject; var Action: TCloseAction);
begin
  if Assigned(OSMParser) then begin
    OSMParser.Terminate;
    OSMParser.WaitFor;
    FreeAndNil(OSMParser);
  end;
end;

Mehr hab ich nich nicht durchgesehen. Compiling ging auch noch nicht. Bei mir werden die Units ZConnection, ZDataSet angemeckert.

Gruß oki

[alzaimar]

Speicherlecks und ähnliche Missgeschicke findet man zuverlässig mit FastMM.

[Mithrandir]

Zitat:

Zitat von oki

Ich dächte, dass ist sicherer sollte der Thread noch immer da sein:

Delphi-Quellcode:

procedure TForm1.FormClose(Sender: TObject; var Action: TCloseAction);
begin
  if Assigned(OSMParser) then begin
    OSMParser.Terminate;
    OSMParser.WaitFor;
    FreeAndNil(OSMParser);
  end;
end;

Ok, das habe ich jetzt mal so umgesetzt. Musste gleichzeitig noch ne andere Schleife anpassen. Jetzt meldet mir FastMM immer noch eine Verletzung...

Zitat:

Zitat von oki

Mehr hab ich nich nicht durchgesehen. Compiling ging auch noch nicht. Bei mir werden die Units ZConnection, ZDataSet angemeckert.

Argh. Mein Fehler. Die beiden angemeckerten Units gehören zur ZEOSLib, download findet sich hier[@Sourceforge, 1.6 MB].

Das Speicherleck konnte ich nicht komplett beheben, der Speicherverbrauch steigt zwar nicht mehr in den riesen Schritten wie vorher, aber er steigt halt immer noch.

Folgende Änderungen habe ich gemacht:

ORP_Extractor.pas, Zeile 538, folgendes hinzugefügt:

Delphi-Quellcode:

FreeAndNil(fRegAttrExpr);

ORP_Extractor.pas, Zeile 219, folgendes hinzugefügt:

Delphi-Quellcode:

  FreeAndNil(fRegEx);

ORP_Extractor.pas, Zeile 202, folgendes kursiv hinzugefügt

Delphi-Quellcode:

 while (fRegEx.MatchAgain) and (dwLenStr - dwCurPos > 20) [i]and not Terminated[/i] do

Ich lade oben gleich mal die neue Version hoch. Was mir beim FastMM-Log aufgefallen ist, ist dass der Trace Stack auch über die Funktionen der ZeosLib rüberläuft. :gruebel: Ich hänge den Log mal hier mit an...

[himitsu]

hab jetzt noch nicht seht weit reingesehn, aber schon in der ersten Datei ...

Delphi-Quellcode:

procedure TForm1.UpdateProgressbar(Sender: TObject; Cur: Integer; Max: Int64);
begin
  ProgressBar1.Max := 100;
  ProgressBar1.Position := Round((Cur / Max)*100);
  Form1.Caption := IntToStr(ProgressBar1.Position) + ' % ' + Format('Speed: %3.3f Sec.', [(GetTickCount - Tick)/1000]);
end;

Delphi-Quellcode:

// warum war Cur als Integer und Max als Int64?
// bei Dateien über 2 GB wäre Cur wohl etwas überlastet
procedure TForm1.UpdateProgressbar(Sender: TObject; const Cur, Max: Int64);
begin
  // kann man auch einmal direkt im OI zuweisen
  //ProgressBar1.Max := 100;

  // weiß jetzt nur nicht was schneller ist,
  // aber vermutlich doch die in der FPU, als emulierten 64-Bit-Operationen ...
  // hab also nix gesagt ._.
  ProgressBar1.Position := (Cur * 100) div Max * 100;

  // wenn eh schon Format da ist, warum nicht gleich weiternutzen ;)
  Form1.Caption := Format('%d%% Speed: %3.3f Sec.', [ProgressBar1.Position, (GetTickCount - Tick) / 1000]);
end;

[Mithrandir]

Zitat:

Zitat von himitsu

Delphi-Quellcode:

// warum war Cur als Integer und Max als Int64?
// bei Dateien über 2 GB wäre Cur wohl etwas überlastet

Dit war noch aus dem ersten Versuch, als ich Max und Position die Werte direkt zugewiesen habe und nicht über die Prozentrechnung gegangen bin... wird gefix... :oops:

Zitat:

Zitat von himitsu

Delphi-Quellcode:

  // wenn eh schon Format da ist, warum nicht gleich weiternutzen ;)
  Form1.Caption := Format('%d%% Speed: %3.3f Sec.', [ProgressBar1.Position, (GetTickCount - Tick) / 1000]);
end;

Wird auch noch angepasst, wobei man ja dazu sagen muss, dass das Fehler sind, die die Unit nicht direkt betreffen. :stupid: Das Testprogramm nutze ich nachher ja nicht weiter...

[himitsu]

Also die Definition der Callbackprozedur ist schon 'ne Sache aus der Unit. :nerd:

[Mithrandir]

Zitat:

Zitat von himitsu

Also die Definition der Callbackprozedur ist schon 'ne Sache aus der Unit. :nerd:

*knirsch* Stümmt... :oops:

[hazard999]

Form1.Caption := Format('%d%% Speed: %3.3f Sec.', [ProgressBar1.Position, (GetTickCount - Tick) / 1000]);

wenn ich sowas schon seh *argh*

Caption := Format('%d%% Speed: %3.3f Sec.', [ProgressBar1.Position, (GetTickCount - Tick) / 1000]);

self.Caption := Format('%d%% Speed: %3.3f Sec.', [ProgressBar1.Position, (GetTickCount - Tick) / 1000]);

was besser gefällt

aber ja nicht Form1...


warum verwendest du das Testprogramm nicht weiter?

super Vorlage für einen Unit-Test oder ein Demo.

[mkinzler]

Spricht eigentlich etwas gegen die Verwendung des Delphi-Tags? :gruebel:

[Mithrandir]

Zitat:

Zitat von hazard999

warum verwendest du das Testprogramm nicht weiter?

super Vorlage für einen Unit-Test oder ein Demo.

Weil ich die Klasse für ein anderes Programm nutze und das Programm eher Mittel zum Zweck ist, um währen der Umsetzung nicht vollends die Übersicht zu verlieren.

Zum Thema "Caption": Man kann natürlich auch die Goldwaage auspacken... ;)

[th_bone]

Hi,

das Projekt scheint ja gestorben zu sein, darf man fragen warum ? Ist Openstreetmap hierfuer noch nicht soweit ?

Tschüss

Ralf

[Mithrandir]

Zitat:

Zitat von th_bone

Hi, das Projekt scheint ja gestorben zu sein, darf man fragen warum ?

Primär: Kaum Zeit. Sekundär: Verlagerung der Interessen. Eventuell lebt es irgendwann nochmal auf, die Domain bleibt jedenfalls erstmal reserviert.

[xZise]

Hallo,
kann es sein, dass http://www.openrouteservice.org/ genau dies hier leistet?

MfG
Fabian

[Mithrandir]

Japp, nur halt als online-app. Mein Ziel ist/war es, eine Offline-Applikation zu entwickeln. Sprich, man hätte sich einmal die Datei für bspw. Deutschland heruntergeladen, und das Programm hätte dann daraus eine Karte generiert, mit Support für GPS-Mäuse und entsprechender, textueller Routenführung. Jedoch ist der Aufwand - immens.