Danke Georg, ich werde sie, wenn ich Zeit habe und es niemand anders vor mir tut, nochmal einem Lektorat unterziehen, aber dann ist es sicher eine gute Sache. Eins fehlt aber noch - wie schon erwähnt: Die Umrechnung von Koordinaten in Kacheln. Wenn es dazu keinen passenden “Rechner” gibt, muss ich mal selber einen schreiben. Am besten gucke ich erstmal hier im Forum.
Danke schon mal für die ganze mühe… ist echt wahnsinn… vielen dank an georg… karte sieht jetzt auf den ersten blick schon mal echt nice aus, werd das ganze mal ausdrucken und anschaun. und kristian: ich render das ding mal und schau an was bei rum kommt… dauert mit sicherheit ne ganze weile… letztes mal hat die render-geschichte tage gedauert als die karte so groß war. aber ich sag dir dann bescheid wies ausschaut. danke so oder so… achso und wie hast du es geschafft die layers zu verbinden???
hey georg, bist du bei den maßen sicher? irgendwas stimmt mit dem seitenverhältnis nicht… habs jetzt mal ausgedruckt auf a3, also entsprechend skaliert. das war nicht so wirklich was. oder liegt das an dem format und das geht gar nicht?
@ corinna du hast Recht, meine Angaben (…ziemlich genau A0) stimmen nicht ganz. Kristian hat noch mal nachgerechnet.
Das sollte passen. Hoffe du k
Hallo Zusammen, die Umrechnung lon/lat nach Tiles kann damit erfolgen: http://almien.co.uk/OSM/Tools/Coord/? ist im Wiki hinterlegt. Ich bin dabei das Coding zu erweitern um einen direkten Link zum Bigmap zu ermöglichen. Gruss Zapfen
@ georg: sorry, war mir irgendwie entgangen…temporär verwirrt! @zapfen: was genau kann man denn dann damit anfangen?
Das ist ja alles ein umstand um eine hochauflösende Karte im größeren Format zu drucken. Auch das sollte mal angegangen werden damit´s einfacher per Klick machbar ist.
@corinna: Damit kannst Du aufgrund von lon/lat Angaben die x: y: Koordinaten für das Bigmap Script berechnen lassen. Gruss Zapfen
Aha, das gucke ich mir mal an … Hm … ist nur der Recher selbst, aber nicht der Code …
Ich bin mir sicher, dass ich das in irgendeiner Wiki gelesen hatte. Aber in welcher? Hast Du den Link? Das war irgendwie im Zusammenhang mit orp, glaube ich, aber ich finde es nicht wieder, und die Seite von oben referenziert es auch nicht.
Gut zu wissen, war nämlich auch schon dran, und nach meinem Reverse-Engineering hatte ich auch eine Formel für die Tiles entwickelt, aber ich liege damit komischerweise immer 40 bzw. 20° (l/v) daneben. Den Fehler kann ich nicht erkennen, es sei denn, es gibt eine Nichtlinearität, die ich nicht kenne - das ist eigentlich die einzige Erklärung, die ich dafür habe. Wie gesagt, wenn Du die Wiki nochmal da hast … Danke, Kristian
Oben rechts erscheinen die einzelnen Layer. Daneben oder darunter ist u.a. ein Button zum mergen. Oder war es im Kontext-Menü (Rechtsklick)? Musst Du mal probieren.
@zapfen, bist du noch am basteln? Irendwie komme ich mit deinem Converter nicht weiter… Entweder es passiert gar nichts oder es kommt ein Hinweis auf eine nicht vorhandene Seite? Georg
Also bei mir funktioniert die von ihm angegebene Seite, also das Formular für Hin- und Rückrechnung. Koordinaten eingeben, Knopf drücken, Kachelnummern für die jeweiligen Zoomstufen ablesen. Es fehlt da nur der Link zu bigmap, aber das wäre ja ein Kinderspiel, das noch zu ergänzen. Und wenn ich Zapfen richtig verstanden habe, ist er genau da dran.
In Bigmap hat Zapfen das Ganze schon eingebaut. Hhhmm werde da wohl noch ein bischen probieren müssen… 
Georg
Hm? Achso, Du meinst den Link auf das o.g. Umrechnungsformular. Ich meinte eine Ergänzung dieses Formulars um die Links auf bigmap.
Jetzt weiß ich auch, was Du meintest - ja, die Links, die den Zoomstufen zugeordnet sind, funktionieren nicht - warum auch immer. Aber guck Dir mal an, wo die hinzeigen: Das hat mit bigmap nichts zu tun. Aber so ähnlich stelle ich es mir vor. Es fehlt wie gesagt nur der korrekte Algorithmus. Meiner ist fehlerhaft.
Hallo Zusammen, ja genau das war auch meine Idee, zusätzlich habe ich noch die Tiles eingebaut. Erst jetzt habe ich das System richtig verstanden 
Hier der neue Link: http://oms.wff.ch/calc.php?long=7.6&lat=47.6 Damit solle es einfacher sein ins BigMap einzusteigen. Viel Spass Zafen P.S.: Hier war der Link: http://wiki.openstreetmap.org/index.php/Slippy_map_tilenames
WOW! Hut ab! Das ist ne tolle Arbeit. Ein absoluter Gewinn. Mann, wenn ich so etwas mal hinbekomme… RESPEKT Georg
@Hobby Navigator ja danke ich hab’s ja nicht erfunden nur erweitert 
Zapfen
Ja genau, danke für den Link zur Wiki, Zapfen. Vermutlich ist es der, den ich meine … ja, sieht so aus. Und irgendwie habe ich das dumpfe Gefühl, dass ich die ganze Sache schon mal in Excel geschrieben hatte … nein, das war die Umrechnung von GPS in Meter und umgekehrt, aber das ist ja fast das gleiche … das war nämlich die besagte Nichtlinearität. Sehr gut! Ich hätte nur statt der Auflistung der Kacheln das Original-Formular von bigmap kopiert und lediglich die Wahl zwischen der Eingabe von Kachel-Nummern und GPS-Werten hinzugefügt plus die Möglichkeit, das Zentrum als GPS-Punkt anzugeben und die Anzahl der Kacheln ringsum. Du hast quasi letzteres implementiert und das Ergebnis auf 3x3 Kacheln festgelegt. Du solltest diese Ergänzung an Frederik schicken, damit er sie direkt bei sich einbinden kann, oder? Kristian
@krza: Ja genau, das wäre noch einfacher gewesen, ist das Bigmap von Frederik Ramm? Das Problem ist nur Bigmap ist in Perl (CGI) geschrieben und mein Coding in PHP. Und Perl kann ich (noch) nicht :-). Ich werde jedoch noch den Tilesource bei mir einbauen
Das Teil ist von Frederik Ramm, soweit ich weiß, ja. Erstens wurde es oben irgendwo erwähnt, und zweitens ist gryph.de auf ihn registriert. Beides zusammen lässt die Wahrscheinlichkeit recht hoch erscheinen Perl und PHP sind fast identisch, was das betrifft. Die paar Syntax-Unterschiede fallen kaum auf, glaube ich. Wichtig ist, dass das HTML-Gerüst für das Formular steht und der Algorithmus. Ich persönlich hätte es ohnehin nicht serverseitig gemacht, sondern clientseitig mit JavaScript. Das geht viel schneller und entlastet den Server. Der Schritt von Perl und PHP zu JS ist in diesem Falle wieder sehr einfach, würde ich sagen. Ist halt von der Basis-Syntax her alles fast das gleiche. Das Problem mit dem Range sehe ich ehrlich gesagt nicht. Du hast zwei Punkte (z.B. links oben und rechts unten) und bekommst dafür zwei Kacheln. Die siehst Du als die Eck-Kacheln an und füllst das entstehende Rechteck einfach auf. Im einfachsten Fall liegen beide Punkte auf einer einzigen Kachel. Und wenn man´s robust macht, ist es egal, in welcher Reihenfolge die Kacheln angegeben werden. Man muss dazu nur die Absolutwerte der Kachelnummer-Differenzen verwenden. Kristian PS @Georg: Ach dort hatte ich das gelesen … Da muss ich vorhin genau diese Zeile letzte übersehen haben.