[OSM-dev-fr] [OSM-talk-fr] Tr : [OSM-talk] New OpenStreetMap tile server

[Philippe Verdy]

2012/12/20 Christophe Merlet <redfox at redfoxcenter.org>

> 1355960486.937      0 93.31.155.175 TCP_HIT/200 25368 GET
> http://tile.openstreetmap.org/15/16500/11681.png - NONE/- image/png


L'expression régulière ne doit traiter que les URL d'une tuile et pas les
URL d'autres pages qui seront ignorées (s'il y en a aussi dans le log).

En ignorant le reste de la ligne sur les statuts (si on ne veut que mesurer
la charge du serveur) il n'y a que 4 champs à prendre par ligne avec une
unique expression régulière par ligne. Pas besoin de base, un script PHP
peut lire plusieurs milliions de lignes comme ça en moins de 2 secondes
pour obtenir le quadruplet:

(1355960486.937, 15, 16500, 11681)

Autrement dit le timestamp en secondes qui sert juste à déterminer
l'intervalle de date pour le calcul de moyenne, et les numéros de tuile
pour chaque niveau de zoom.

On peut ignorer l'adresse IP du client (ici 93.31.155.175 : c'est une
donnée PRIVÉE, à ne pas publier elle gélolocalise le client et peut
l'identifier précisément avec le timestamp...), et le protocole utilisé
(TCP), le statut du cache (HIT) et de la réponse (200).

A priori on peut ignorer aussi le verbe de requête (GET) et le MediaType
retourné (image/png) même si la réponse du serveur a été une erreur
(requête invalide). Cela dépend des autres requêtes qui passent par ce même
proxy et présentes aussi dans le même log.

Cependant si le serveur a une erreur 5xx, cela peut signifier son anomalie
temporaire, et on peut marquer le timestamp où ça se produit et celui où ça
s'arrête pour soustraire ce temps de l'intervalle de temps (qui sert à
calculer la moyenne horaire des hits). Si l'ntervalle de temps n'a aucune
période sans erreur 5xx, le serveur a un problème et on peut retourner une
couleur par défaut distincte (gris par exemple au lieu d'un dégradé du
blanc au rouge). Sinon on traite cette ligne dans les cumuls :

Il n'y a plus qu'à retourner pour un niveau donné (pour une "tuile")
l'image correspondant au nombre de tuiles dans un "bucket" formé par le
numéro de tuile demandé et autour (si on demande la tuile statistique au
niveau "n" en "x", "y", on peut cumuler le nombre de hits trouvés sur:
- (x-16..x+15) et y +/- 14 pour le niveau n+4
- (x-8..x+7) et y +/- 7 pour le niveau n+3
- (x-4..x+3) et y +/- 3 pour le niveau n+2
... (recoller les largeurs d'intervalles x/y en fonction du découpage des
tuiles entre un niveau de zoom n et le niveau n+1, pour qu'elles occupent
la même surface réelle, si ce n'est pas comme ici une division du niveau N
en 4 tuiles du niveau N+1). Pour les valeurs x +/- i faire le calcul modulo
l'intervalle couvrant les 360° de longitude, pour les y (latitudes) borner
avec un min/max sur l'intervalle couvrant les 180° de latitude.

On ignore toutes les lignes qui sortent de ces cadres et celles sortant de
l'intervalle de timestamp, on divise par la durée de l'intervalle de
recherche. Si on veut, on peut cumuler non pas les hits mais la taille en
octets des requêtes (qui est aussi dans chaque ligne, ici 25368 octets).

Le tout se fait en cumulant dans un unique entier pour parser tout le
fichier log. Aucune base de données nécessaire, il faut juste pouvoir
accéder au fichier log pour le lire.

Ceci fait on a un seul nombre qu'on normalise dans un intervalle de 0 à 100
pour retourner une image statique selon la note obtenue. 2 pages de code
PHP suffiront largement pour ça. Autour on met une autre page PHP statique
pour déclarer la ressource WMS et c'est tout. Il reste à créer le dossier
contenant les 100 images de tuiles (on peut aussi générer le PNG par le
même script, c'est juste inutilement compliqué à coder quand un nombre fini
d'images statiques suffit).

Le test à faire ensuite c'est pour les constantes de normalisation (pour
éviter d'avoir une carte toute blanche ou toute rouge), le nombre de
sous-tuiles à moyenner autour d'une coordonnée zoom/x/y, et pour régler la
longueur de l'intervalle de temps (à voir avec un log complet sur le cas
pratique, bien qu'on puisse aussi normaliser en gardant trace de la
statistique maximale obtenue sur des logs plus longs).
-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://lists.openstreetmap.org/pipermail/dev-fr/attachments/20121220/a5d4a8d1/attachment.html>