Moin moin,
ein kleiner Unterschied zwischen pbftoosm und osmconvert scheint dennoch zu bestehen:
Wenn ich die spaces aus " />" entferne, ist die von pbftoosm generierte osm
immer noch etwas groesser als die osm von osmconvert.
Ciao,
Frank
@ viw
7zip kenne ich / nutze ich seit Jahren
@ marqqs & viw
Nein, den ganzen planeten nutze ich nicht. Europa reicht mir.
Die Funktion von --drop-history hatte ich dann also zu weit gefaßt verstanden.
An beide vielen Dank für die Erklärungen.
Jetzt mache ich erst mal Tüftelpause.
Ich finde es immer frustrierend, wenn ich wegen einem kleinen Fehler komplett von vorne anfangen muß.
In dem Moment war mir das zu blöd und ich habe den Test abgebrochen. 
Ein Angebot wie: "erwartete Eingabe: … / zurück zum Auswahlmenü / Programm beenden finde ich wesentlich motivierender (pädagogischer 
) als Sackgassen
Da ich vom Programmieren keine Ahnung habe und mir lediglich kleine batches im “Notizblock” zusammenstelle, hab ich allerdings keine Idee, wie so etwas programmiert wird.
Also die Idee mit dem Rücksprung ist doch gar nicht schlecht.
Das Problem beim schreiben der Programme ist genau das gleiche wie wenn du eine Batchdatei schreibst. Nur eine andere Sprache.
Die Arbeitsweise eines Computers war und ist eigentlich immer eins nach dem anderen ab zu arbeiten und dann zu schauen was als nächstes kommt. So hat alles angefangen und so funktioniert es im Prinzip noch heute.
Allerdings gibt es auch Weiterentwicklungen aus einfachen DOS und Linux auf der Kommandozeile sind aufwendige grafische Betriebssystem geworden. Jetzt blockiert das Betriebssystem den Prozessor mit dem Leerlaufprozess. Dieser macht nichts anderes als zu schauen was gibt es zu tun und verteilt die Rechenzeit auf die einzelne Programme.
Dabei stellt es allen Programmen bestimmte Funktionen zur Verfügung. Zum Beispiel das schließen mit dem Kreuz oben in der Titelzeile des Fensters. Oder aber auch ctrl+C für das beenden des Programmes. Dabei wird das Programm nicht wirklich beendet sondern nur ein Signal an das Programm gesendet, mit welchem dieses dann umgehen muss.
Das Ganze kann man natürlich schön verpacken und das heißt dann GUI Grafische Oberfläche für den Benutzer. Der Nachteil ist das man diese grafische Oberfläche für jedes Betriebssystem selber programmieren muss. Marqs ist aber zum Beispiel inzwischen nur noch mit Linux unterwegs und viele andere Programmierer im OSM Umfeld auch. Daher hat er als Kompromiss für Schnelligkeit und plattformübergreifend die Kommandozeile gewählt. Wenn man in den Quelltext schaut, dann stellt man schon hier erschreckt fest, wieviele Anpassungen für Windows nötig waren. Aber das hat er alles schon für uns eingebaut und vor allem übersetzt er die Programme schon für die Windowswelt.
Aber zurück zum Thema wenn man jetzt etwas mehr möchte als das Betriebssystem anbietet, dann muss man selber programmieren. Zunächst einen Händler, welcher sich um Tasturbefehle kümmert. Diese müssen dann in die entsprechenden Signale umgesetzt werden und dann im Programm an geeigneter Stelle ausgewertet werden. Aber damit nicht genug. Es muss quasie für alle Betriebssysteme speziell gemacht werden.
Da dies sehr lästig ist, haben sich Entwickler zusammengetan und ein QT Framework erschaffen, welches plattformübergreifende GUI Elemente anbietet. Allerdings macht dieses Framework das Programm nicht kleiner und es ist dennoch sehr anspruchsvoll damit zu programmieren.
Einen neuen Menübefehl aufzunehmen ist sicherlich einfacher. Allerdings kommt dann das Problem was ist alles sinnvoll? Also marqs hat sich sicher zu erst überlegt was soll mein Programm können. Dann hat er dem Programm das beigebracht und immer wieder neue variablen und Parameter eingeführt um die Funktionalität und Sonderfälle zu berücksichtigen.
Nachdem das Programm jetzt eine Stand erreicht hat mit dem er zufrieden ist, hat er sich gedacht möchte es möglichst vielen Nutzern einfach machen. Vor allem jenen die nicht Wikiseiten lesen und dann Batchdateien schreiben.
Naheliegend war also ein Menü mit was kann ich und was willst du zu bauen. Dabei gabs schon wieder die Schwierigkeiten mit diesem Windows.
Ja und dann gibt es gewisse Bedürfnisse die der Nutzer heute von anderen Programmen kennt. Zeig mir doch alle Dateien an die du findest damit ich die nicht tippen brauch…
All die Sachen sind aber so kompliziert, wenn man sie für alle Betriebssysteme programmieren möchte dass der Nutzen in Frage steht. Schon alleine der Aufruf von Dateien unterscheidet sich während Windows gerne F:\ sieht will Linux F:/ wie also soll man all diese Sonderfälle und wünsche berücksichtigen? Ein Weg ist viele Menschen testen zu lassen. Dinge die einfach zu beheben sind werden wie du siehst sofort behoben. Wenn es Funktionseinschränkungen gibt, wird solange gesucht bis die Ursache gefunden ist.
Aber dann gibt es eben auch Luxus. Da steht der Aufwand in keinem Verhältnis zum Nutzen.
Im Prinzip ist es möglich so ein Menü auch in einer Batchdatei zu schreiben und dann den Programmaufruf zu erzeugen. damit wärst du Herr deines Menüs. Allerdings ist das wie oben geschrieben nicht immer einfach. Vor allem wenn dann andere Nutzer anders denken einfach mit einer anderen Sichtweise an das Problem herangehen und so Dinge anders interpretieren.
Nach der wohlbekannten Vorgehensweise:
sieht es aus, dass pbftoosm wohl (Routen-)Relationen wie z. B. die 1604736 mit auschneidet,
welche aber nicht nach Nürnberg gehören.
Ciao,
Frank
Vielen Dank viw.
Meine Batch-Dateien sind sehr einfach gestrickt.
Mein Anwendungsfall:
Weil ich beim Experimentieren gerne schnell Ergebnisse sehe, entwickelte sich im Composer im Laufe der Zeit eine lange Job-Liste mit den unterschiedlichsten Kartenausschnitten, von denen die meisten so klein sind, daß sie in wenigen Minuten gerendert sind.
Ein weiterer Vorteil ist, daß die Kartenschnitte (also die Kanten) dort liegen, wo ich sie sehen möchte. Den Zuschnitt der Rohdaten hab ich mit batch-Dateien organisiert, indem ich zunächst nach und nach kleine Einzeldateien angelegt habe. Nachdem die erste Datei wie gewünscht funktionierte, brauchte ich sie nur noch unter neuem Namen abspeichern und die Parameter (Koordinaten, Regionsbezeichnung) auszutauschen.
Als die Sammlung groß genug war und mir der Aufruf aus dem Explorer heraus nicht mehr gefiel, baute ich ein einfaches Menübatch, aus dem diese kleinen Batchdateien als Befehle oder Unterroutinen aufgerufen werden.
Diese Menü-Batch-Datei ist folgendermaßen gebaut:
- erläuternder Titel
- Auflistung der wählbaren Kartenausschnitte
- Eingabeaufforderung
- Ansprungpunkte
Jeder Ansprungpunkt enthält den Aufruf einer Batchdatei, die das Ausschneiden des zuvor gewählten Datenausschnittes steuert.
Am Ende dieser Batchdatei hat man die Wahl, auszusteigen, oder zur Menüdatei zurückzukehren.
Wählt man die Rückkehr, passiert nichts anderes als ein erneuter Aufruf.
Soll dem eigentlichen Menü eine ausführliche Erläuterung vorangestellt werden, macht es Sinn, diesen Text in einer separaten Batch unterzubringen. Wenn am Ende des Textes das Menü automatisch aufgerufen wird, sieht das auf dem Bildschirm aus, als würde das zusammengehören. Der Sinn dieser Aufteilung wird deutlich, wenn man am Ende einer fertig abgearbeiteten Unterroutine zum Menü zurückspringt, um den nächsten Kartenausschnitt auszuwählen. Durch die Aufteilung der Menü-Datei in zwei Module kann man nun das Menü ohne den Vorspann aufrufen.
Das ist ein ziemlich simpler Weg, den Rücksprung zu realisieren. Und ich kann mir nicht vorstellen, daß ich mit dieser Schilderung hier jemandem etwas Neues erzähle.
Der Haken an dieser simplen Konstruktion: Sie funktioniert nur so lange, wie die aufgerufenen Pfadangaben passen.
Nein du erzählst hier nichts Neues. Und du präsentierst bereits die Lösung für Bert. Du kannst eine oder mehrere Batchdateien schreiben und damit das Menü anlegen. Wenn du Hilfe für die einzelnen Befehlszeilen brauchst, so werden wir dir gerne helfen. Ist die Datei dann fertig, wäre es schön, wenn die Datei ins Wiki gestellt werden könnte und dann braucht Marqs sich nicht den Kopf mit dem Menü zerbrechen, sondern kann die inhaltliche Arbeit vorantreiben. (Nachteil der Batch wird sein, dass sie nicht bei allen Betriebssystemen funktioniert) Aber wenn wir erstmal Windows und Linux abarbeiten ist denke ich viel gewonnen.
Hi tippeltappel, hi viw,
Sorry, klingt mir nicht wie die Lösung für “Bert”. Eine “GUI” soll dazu dienen für einzelne Befehle.
Da Tippeltappel doch jeden Monat (oder so) eine Vielzahl von Kartenausschnitten rendert, wäre es sinnvoller
den ganzen Prozess (incl. europe.osm.pbf-Aktualisierung) in eine “Batch” zu schreiben.
Die wuselt eine Liste (die man ggf. erweitern kann) von “Kartenabschnitten” ab,
dauert eine Stunde (whatever) und in der Zwischenzeit kann Tippeltappel Tennis spielen oder Hemden bügeln
anstatt vor der Kiste zu sitzen und alle paar Minuten “1”, “2” oder “3” einzutippen.
Ciao,
Frank
Du hast zweifelsohne Recht. Wenn man den ganzen Toolchain in eine Batchdatei schreibt, dann ist das nicht die Lösung für Bert. Aber wenn man das Menü von Bert in einer Batchdatei nachbildet, und dann in einzelnen Parameter übersetzt, dann ist das genau die Lösung. Tippeltappel kennt sich mit den Menüs bereits aus und hat über die Lösung des ihr wichtigen Problems des Rücksprungs gesprochen. Also muss es nur noch umgesetzt werden.
Osmosis bedient man unter Windows übrigens auch mit einer Batchdatei, damit die spezifischen Aufrufe klappen.
Auf meinem 4GB Win7 Laptop ca. 15 Minuten, wenn ich es täglich aufrufe. Die europe.o5m ist knapp 9 GB groß.
Mein Batchfile:
@echo off
cd \osmdata\
del europe.o5m.old
osmup -v --daily --drop-author -B=euro.poly europe.o5m europe2.o5m
rename europe.o5m europe.o5m.old
rename europe2.o5m europe.o5m
pause
Der openptmap-Server braucht für die täglichen Updates des Planet-Files immer ca. 20 Minuten. Ging wahrscheinlich noch schneller, wenn ich osmconvert mit -O3 übersetzt hätte. Aber egal. Wichtig ist ja nur, dass es weniger als einen Tag dauert, weil sonst keine “täglichen Updates” möglich wären. 
@ all
Vielen Dank für Eure Infos.
Wenn ich die nächste Tüftelrunde starte, werde ich mich damit näher befassen.
Da stimme ich mit Frank im Prinzip überein.
Da ich aber nicht jedesmal alle Kartenschnipsel benötige, habe ich im Menü verschieden große Sammelaufrufe und Einzelaufrufe kombiniert. So kann ich steuern, ob der Rechner länger oder nur ganz kurz beschäftigt ist. Sowohl die Einzelaufrufe als auch die Sammelaufrufe starten eine “Ausschneidebatch”. Die von Sammelaufrufen angesprochenen “Ausschneidebatches” enthalten nur halt eben eine längere automatisch arbeitende “Arbeitsliste”/toolchain. Den Rücksprung zum Hauptmenü hab ich eingebaut für den Fall, daß ich eine Kombination von Kartendaten ausschneiden will, für die es keine vorprogrammierte Zusammenfassung gibt.
Das alles arbeitet abgesehen von den im Einstiegsmenü angebotenen Auswahloptionen und den Optionen für Ausstieg und Fortsetzung der Arbeit mit völlig statischen Bedingungen. Die angebotene Auswahl im Menü ruft vorformulierte Bedingungen auf. Die von Marqqs angedachte GUI ist dagegen so konzipiert, daß sie an verschiedenen Stellen auch völlig unerwartete Eingaben verarbeiten kann. Wie man derartiges mit einer Batch-Datei organisiert und ob die wenigen in der help Liste von Dos angezeigten Befehle das hergeben, kann ich nicht sagen. Ist für mich ja auch uninteressant, weil ich bei der Erstellung eines bisher noch nicht gearbeiteten Kartenausschnittes die Batchdateien entsprechend erweitere, wodurch die neue Aufgabe dann ebenfalls statisch eingebunden ist.
Marqqs GUI teste ich trotzdem gerne weiter.
@ Marqqs
Habe eben noch einmal geguckt, was Bert kann.
Die Hilfe für die Grad-Eingabe finde ich jetzt gut.
Nun würde ich mir abgesehen von der Rücksprungschleife noch etwas wünschen, wenn mich eine gute Fee danach fragen würde.
Ist es ohne großen Aufwand möglich, noch eine Routine einzubauen, in der man selbst einen Namen für den Kartenausschnitt eingeben darf?
Es wäre auch ganz nett, wenn das Fenster nicht einfach wegsackt, sobald die Berechnung der neuen Datei fertig ist.
Ich glaube nicht, daß jeder Neueinsteiger sofort auf die Idee kommt, die Entwicklung der Dateigröße im Explorer zu betrachten (sozusagen als behelfsmäßiger Ersatz für eine Statusmeldung) und daher (wenn er das cmd-Fenster nicht beobachtet) ziemlich überrascht sein wird ob dessen “grußlosen” Verschwindens. Die am Schluß angezeigte Meldung ist nicht lesbar (es sei denn, man kommt auf die Idee, im richtigen Moment einen Screenshot zu machen), weil das Fenster wegsackt, sobald die Meldung da ist. Mir kam die Idee zu spät und jetzt reicht meine Neugierde nicht, um noch einmal 11 Minuten zu warten und dann zu “schießen”.
Eine Meldung, wie lang die Berechnung gedauert hat, wäre noch ganz interessant. Dann braucht man nicht extra auf die Zeit zu achten. Dann weiß man das nächste Mal, wieviel Zeit man hat, sich einen Imbiß zu holen.
Wie werden die Koordinaten 7,8,48,49 interpretiert?
Ich frage das, weil mich die Größe der Datei für einen 1°x1° großen Ausschnitt irritiert.
Die Optionen:
osmconvert europe.osm.pbf -b=7,8,48,49 --drop-author --out-osm -o=europe.osm_02.osm
ergeben eine mehr als 2 Mal so große Datei. staun Meine am 22.10 herunter geladene europe.osm.pbf hat 6.902.138KB der 1°x1° große Ausschnitt europe.osm_01.osm und auch die sicherheitshalber noch einmal berechnete europe.osm.02 haben 15.923.182KB
Mit pbftoosmV10 und der Option --drop-history berechnete Querausschnitte von Deutschland und Grenzgebieten, die mit einer Ausdehnung von etwa 3°x9° wesentlich größer sind, ergeben dagegen Dateigrößen die mit 5.000.000 bis 6.000.000KB nur 1/10 so groß sind. Wie paßt das zusammen?
EDIT
Habe die Datei soeben in den Composer gesteckt.
Sieht aus, als würde das was länger dauern …
Das warte ich nicht mehr ab.
Werde Morgen berichten, ob Composer das “gebacken” bekommt.
Ich vermute sehr stark, dass die Zahlen in der Reihenfolge links, unten, rechts, oben interpretiert werden.
In dem Fall hättest du einen 31°x31° großen Ausschnitt definiert.
Probier einfach mal den Parameter mit -b=7,48,8,49
HTH
Edbert (EvanE)
Nicht so viel vermuten
Einfach
osmconvert -h
oder
osmconvert --help
eintippen.
Ergibt
-b=,,, apply a border box
resp.
-b=,,,
If you want to limit the geographical region, you can define
a bounding box. To do this, enter the southwestern and the
northeastern corners of that area. For example:
-b=-0.5,51,0.5,52
Moin Edbert
Die Reihenfolge ergab sich aus der GUI.
Beim Abschreiben der ausgeworfenen Befehlszeile wunderte ich mich auch schon über die Reihenfolge der Zahlen.
Sie entspricht genau der Abfrage
- min Längengrad
- max Längengrad
- min Breitengrad
- max Breitengrad
Wenn man bei Aufforderung 2 den min Breitengrad eingibt und bei 3 den max Längengrad, kommt logischerweise die richtige Optionsfolge zustande.
Wenn Marqqs also in der GUI den Textinhalt von Aufforderung 2 und 3 austauscht, paßt es.
Als ich den PC heute Morgen aus seinem Schlummermodus holte, rechnete Composer immer noch, bzw. weiter. Das 64-bit System war gut beschäftigt. Ich habe das dann kurzerhand abgebrochen. Sonst hätte ich hier nicht lesen können.
Gruß
tippeltappel
Ich finde es schade, dass du mit Frank in dem Fall übereinstimmst. Aber ich gebe dir Recht, dass es für deine Bedürfnisse günstiger ist die Kartenausschnitte in statischen batchdatein anzulegen und diese dann abzuarbeiten.
Meine Idee war, dass du ein Menü baust, in dem man die einzelnen Funktionen von osmconvert auswählen kann. Diese Eingaben speicherst du dann in Variablen und generierst daraus dann den Programmaufruf.
Dann würdest du in der Batchdatei mit if then else und anderen Spielerein das gleiche machen, wie Marqs in seiner Sprache(C++).
Wenn man sich mit solchen Dingen beschäftigt, merkt man auch sehr schnell wie komplex die Sachen werden können.
Zum Beispiel könnte ja der Wunsch bestehen, die Eingabe zu korrigieren. Einfachste Lösung Menü von vorne beginnen (so haben wir alle mal schreiben gelernt in der Schule) Komfortabler ist es aber wenn man diesen Menüpunkt nochmal aufrufen kann. Erfordert aber eine gewisse Logik die erstmal programmiert sein möchte.
Ich wollte einfach mit dieser Aufgabe dein Verständnis dafür wecken, das es erstens nicht einfach ist an alles zu denken und das zweitens Komfort durch große Anstrengungen im Vorfeld zu erreichen sind.
Ein anderes Beispiel ist vielleicht die Entwicklung des Computers. Angefangen hat das alles mit Lochstreifen und einfachen Rechenoperationen. Heute macht das so ein kleine Taschenrechner mit Solarzelle. Da ist keiner mehr Bereit Lochstreifen zu stanzen, damit irgendwelche Mathematischen Probleme einem Computer eingegeben werden können.
Ich habe die Lochstreifen noch erlebt. Und es war ein großer Fortschritt.
@ kellerma
Schon klar.
Diese Hinweise kenne ich schon von pbftoosm.
Nebenbei bemerkt: -b=-0.5,51,0.5,52 ergibt wohl eher eine Linie als ein Gebiet
Beim Testen der GUI mach ich halt brav, was Bert von mir möchte.
Ich war mal einfach davon ausgegangen, daß Marqqs es dem unbedarften Bediener leichter machen wollte und deshalb min/max hintereinander angeordnet hatte. Nur hat dann im Hintergrund das korrekte Hintereinanderstellen der Koordinaten nicht geklappt.
Da nun in der aktualisierten Version für den lernwilligen Nutzer die generierte Befehlszeile angezeigt wird, war der Fehler zum Glück leicht zu entdecken.
Gruß
tippeltappel
Nö, ist es nicht
Denn
-0.5
51
0.5
52
ergibt ein Gebiet.
Leider ist durch die Schrift hier im Forum das Minuszeichen nach dem Gleichheitszeichen leicht zu übersehen.
Als ich im Frühjar die batches gebaut habe, habe ich mit so einem Gedanken gespielt, war mir dann aber zu umständlich.
Aufgrund dieser Diskussion hab ich mal unter Win7 in cmd mit help die eingedampfte DOS-Befehlsliste aufgerufen. Da finde ich zwar if, then und else werden da aber nicht angezeigt.
Als ich nach einer Befehlsliste gegoogelt habe, stieß ich erst mal nur auf alte Befehlslisten oder Listen, die 1:1 aus der help abgeschrieben/übersetzt sind (und viele nette Zurechtweisungen im Sinne von “such mal richtig”). Eine Quelle für nicht dokumentierte unter Win7 funktionierende DOS-Befehle tat sich dabei nicht auf.
Da mein Leben sich für gewöhnlich weit ab von Programmiertätigkeiten abspielt, hab ich aufkeimende Ideen dann lieber gleich wieder ad acta gelegt.
Gruß
tippeltappel
Also meine Meinung ist das nicht soviel Energie in die TUI oder wie ihr immer das nennt (Bert oder so) steckt!
Es soll dem Neuling den Einstieg erleichten aber letzendlich muß es sich doch mit den Batchdateien (oder ähnliches) vertraut machen.
Bei den heutigen Rechnern ist es doch viel effektiver osmconvert mehrmals parallel Auszuführen als hintereinander.
Ich selbst starte osmconvert in bis zu 8 Instanzen - entweder parallel aufruf aus einer Batch oder durch starten meherer Batch. Da wird auch der Prozessor (bzw. Prozessoren) entlich voll ausgelasstet und die Dauer wird nur unwesentlich länger.
Die Beschreibung von osmconvert in der wiki find ich auch für Neueinsteiger ausreichend.
Vielleicht noch nee Zusatzbeschreibung für “Dummys” :(speicher osmconvert in dem Pfad , die osm Datei hierhin und dann muß dein aufruf so aussehen…) aber andererseits muß man schon etwas Ahnung haben sonst wird mit der weiterverarbeitung ja auch nix - da ist comandozeile (ober daran angelehntes [wie bei z.B Maperitive] ) ja auch Grundvoraussetzung
Gruß
Quasilotte