Dans Openlayers, le niveau de zoom min ou max ne dépend pas de la carte, mais de chaque couche : ainsi, si on ne veut fournir que certaines résolutions pour une couche wmts, il faut utiliser les paramètres resolutions et serverResolutions à la création des couches, sans modifier les paramètres de la carte :
resolutions:[5000,2500,1500,1000,750], serverResolutions: [null,null ,null, null, null, null, 2445.9849047851562, 1222.9924523925781, 611.4962261962891, 305.74811309814453, 152.87405654907226, 76.43702827453613, 38.218514137268066, 19.109257068634033, 9.554628534317017, 4.777314267158508],
Ainsi, on indique que :
- Quand la couche avec laquelle on a défini ces paramètres est la couche de base, alors les niveaux de zoom disponibles pour la carte correspondent au tableau resolutions de la couche : zoom 0 -> résolution 5000, zoom 4 -> résolution 750.
- Le serveur wmts fournit les résolutions 2445 à 4.77. Ainsi, en fonction de la résolution demandée pour la carte (dans le tableau resolutions), OpenLayers demandera la couche dont la résolution est la plus proche de la résolution carte. Par exemple, pour la résolution carte 5000, on va requêter la résolution 2455. Les éléments null viennent du fait que serverResolutions est utilisé pour faire la correspondande tilematrix/résolution : si je veux la résolution 1222, je vais requêter la TM 7. Or pour cette couche du WMTS, les tilematrixes 1 à 5 ne sont pas disponibles.
Ajouter un commentaire
- Détails
- Écrit par Thomas Bouffon
MacBook:~ thomas$ time nslookup mail.yahoo.com
Server: 212.27.40.241
Address: 212.27.40.241#53
Non-authoritative answer:
mail.yahoo.com canonical name = login.yahoo.com.
login.yahoo.com canonical name = login-global.lgg1.b.yahoo.com.
login-global.lgg1.b.yahoo.com canonical name = eulogin.lga1.b.yahoo.com.
eulogin.lga1.b.yahoo.com canonical name = eu-eulogin.lga1.b.yahoo.com.
Name: eu-eulogin.lga1.b.yahoo.com
Address: 188.125.82.242
Name: eu-eulogin.lga1.b.yahoo.com
Address: 217.146.187.123
real 0m2.350s
user 0m0.005s
sys 0m0.005s
Plus de 2 socondes ? Ce n'est plus un DNS, c'est un annuaire papier !?
Pour comparaison :
MacBook:~ thomas$ time nslookup mail.yahoo.com 8.8.8.8
Server: 8.8.8.8
Address: 8.8.8.8#53
Non-authoritative answer:
mail.yahoo.com canonical name = login.yahoo.com.
login.yahoo.com canonical name = login-global.lgg1.b.yahoo.com.
login-global.lgg1.b.yahoo.com canonical name = login.lga1.b.yahoo.com.
Name: login.lga1.b.yahoo.com
Address: 98.139.237.162
real 0m0.048s
user 0m0.005s
sys 0m0.005s
- Détails
- Écrit par Thomas Bouffon
Vu dans un article sur buzzfeed sur les copies de franchises en iran :
Trop fort !
- Détails
- Écrit par Thomas Bouffon
J'ai souvent entendu que la copie cachée n'était pas une bonne pratique, mais souvent pour des raisons qui ne m'ont pas convaincu.
Pour rappel, la copie cachée (en anglais BCC ou blind carbon copy) permet de mettre en copie des destinataires supplémentaires qui seront invisibles des destinataires originaux.
Ce que j'ai entendu le plus souvent me paraissaint loin de la logique : si le destinataire original d'un message avec destinataires supplémentaires en BCC répondait, il répondrait, sans le savoir, à tous les destinataires, incluant les destinataires cachés. Ce qui semble surprenant, car pour que les destinataires soient cachés, il ne peuvent pas apparaître dans les entêtes du mail reçu, et ainsi le client mail du destinataire n'a aucun moyen de mettre en copie les destinataires cachés.
J'ai donc entrepris quelques recherches sur le web pour démonter cet argument... Pour me rendre compte qu'il était valable !
Effectivement, certains serveurs ou clients de mails peuvent être mal fichus et ne pas enlever le champ BCC, exposant la liste des destinataires (voir la RFC-2821 ou ce papier sur stanford.edu). Le problème, c'est que ceci est valable pour l'utilisation "liste de diffusion" du BCC (uniquement des destinataires cachés, ce qui fait apparaître "undisclosed recipients") largement répandue. Heureusement, cela concerne des systèmes anciens.
Cependant, le risque principal est surtout pour une personne en BCC : si jamais elle clique malencontreusement sur "répondre à tous", le destinataire original découvrira qu'il y avait des personnes en BCC.
Ces 2 points indiquent que c'est surtout les destinataires en copie cachée qui peuvent pâtir de son utilisation.
Enfin, l'émetteur d'un email avec des destinataires en BCC apparaîtra aux yeux des destinataires cachés comme "le genre de personne qui écrit des mails avec copie cachée"
En revanche, sur le fond, utiliser la copie cachée ne diffère en rien du transfert d'un mail envoyé sans en avertir le destinataire orginal, pratique largement répandue.
En résumé,
- il ne faut pas utiliser la copie cachée car c'est dangereux pour les personnes en copie cachée
- il ne faut ni utiliser la copie cachée, ni transférer de mails sans en avertir les correspondants originaux parce que c'est mal. Mais ça n'a pas de rapport technique avec la copie cachée.
- Détails
- Écrit par Thomas Bouffon
Après que ETickets4Hikashop ait cessé de fonctionner avec PayPal, j'ai pas mal cherché et ai finalement corrigé le bug.
Voici donc ETickets4Hikashop-1.0.5, qui :
- corrige le bug PayPal
- ne pèse plus que 1.7 Mo contre 12 auparavant (au prix de la suppression de toutes le polices TCPDF sauf Helvetica et Courier
- ne logge plus rien par défaut, et si on modifie $this->debug dans etickets.php, écrit proprement dans logs/plg_hikashop_etickets.errors.php
Au passage, j'ai remis sur pied et à jour le site de démo, sur lequel vous pouvez commander des billets gratuits pour voir le coté client, et même un billet 2 euros pour essayer le paiement PayPal. Mais attention, si vous allez au bout, vous m'offres une bière ;)
- Détails
- Écrit par Thomas Bouffon
- Vous êtes ici :
-
Home
- Blog