Home

Unsere Basiskarte wird laufend um Informationen ergänzt (zum Beispiel ein Shapefile mit Skipisten). Nach einer solchen Ergänzung soll nicht der gesamte Karten-Cache (mod_tile/renderd) neu gerechnet werden, sondern nur der Ausschnitt in dem Veränderungen stattgefunden haben. Lösung Drei Schritte um die Kartenkacheln neu zu erzeugen: Extent des Shapefiles ermitteln ogrinfo -geom=SUMMARY pp.shp pp ... Extent: (11.015149, 46.848712) - (11.085476, 46.911385) ... Liste der Tiles für diesen Ausschnitt erzeugen Die maximale Zoomstufe meiner Karte ist 17.
Ein Problem, das vermutlich mehrere Entwickler haben, die in einer Web-Applikation mit Javascript auf ein backend zugreifen: Entwicklet wird auf der lokalen Maschine, das backend liegt (zum Entwickeln) auf einem anderen Server. Browser lassen HTTP-Requests in Javascript von localhost auf eine andere Domain nicht zu (hier gilt die same origin policy). Auf den Seiten des Mozilla Developer Network wird sehr übersichtlich erklärt, wie man diese Einschränkung sicher umgehen kann. Da wir im content der requests json verschicken müssten unsere Zugriffe recht aufwändig als preflighted requests behandelt werden.
Die tolle OSMAnd-App für Android bietet ein reichhaltiges Set von Funktionen für mobile Kartenanwendungen. Unter anderem ist es auch möglich, eigene Tile-Layer einzubinden. Hier die einfache Variante für Tiles vom mapnik Server: Im Verzeichnis /sdcard/osmand/tiles einen Ordner anlegen (hier snowhow). In diesem Ordner die Datei .metainfo mit folgendem Inhalt erzeugen: shell@android:/sdcard/osmand/tiles/snowhow $ cat .metainfo [url_template] http://mein.tileserver.com/osm/{0}/{1}/{2}.png [ext] .png [min_zoom] 1 [max_zoom] 17 [tile_size] 256 [img_density] 8 [avg_img_size] 18000 Und wenn die Tiles im TMS-Format vorliegen (also mit umgedrehter y-Achse), auch kein Problem:
Das Backup für PCs und Laptops macht Backuppc sehr fein, aber für die Root-Server braucht es eine andere Lösung. Duplicity macht gpg-verschlüsselte Backups und unterstützt die unterschiedlichsten Endpunkte wie ftp, rsync, scp, ssh, webdav[s] und auch Amazon S3. Hier mein Mini-Bash-Skript mit dem ich meine Server dorthin sichere: #!/bin/bash BDIRS="/etc /home /" LOGDIR='/var/log/duplicity' BAC="s3+http://ihr_bucket_name.s3.amazonaws.com" # symmetrische verschluesselung fuer gpg export PASSPHRASE='einelangeschwierigepassphrase' export AWS_SECRET_ACCESS_KEY="amazon_aws_secret_access_key" export AWS_ACCESS_KEY_ID="amazon_aws_access_key" ##### end of config ########## BCLIENT=$(hostname); for FULL_DIR in $BDIRS do DIR=$(basename $FULL_DIR) if [ $DIR == "
Nachdem der Server eigenartige Verhaltensweisen an den Tag legte und im syslog die Meldung „No space left on device“ erschien, war ich einigermaßen verwundert: Immerhin zeigte df an, dass alle relevanten Partitionen mehr als 50% freien Speicher haben. Ein Lesefehler auf der (virtuellen) Festplatte? Glücklicherweise nicht. Das Kommando tune2fs -l /dev/mapper/vg0-var brachte die entscheidende Information ans Licht: ... Filesystem OS type: Linux Inode count: 10076160 Block count: 40296448 Reserved block count: 2014822 Free blocks: 12087119 Free inodes: 9 First block: 0 Block size: 4096 .