CARTE DE L'EUROPE EN FONCTION DES VISITEURS

Signaler
Messages postés
496
Date d'inscription
mercredi 30 juin 2004
Statut
Membre
Dernière intervention
29 juillet 2009
-
Messages postés
147
Date d'inscription
lundi 16 août 2004
Statut
Membre
Dernière intervention
14 novembre 2009
-
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.

https://codes-sources.commentcamarche.net/source/47464-carte-de-l-europe-en-fonction-des-visiteurs

Messages postés
147
Date d'inscription
lundi 16 août 2004
Statut
Membre
Dernière intervention
14 novembre 2009

Hi!,

C'est vrai que cette table est remarquable!
Ce qui m'a complètement bluffé, c'est l'insertion dans le de courbes de Bézier cubiques, annoncées par la lettre "C". Ces courbes remplacent le tracé d'un certain nombre de points discrets, et si elles sont utilisées à bon escient, elles peuvent entraîner un gain en temps d'exécution ainsi qu'une compression des données. Bien que cette optimisation puisse se faire "à la main", il y a cependant fort à parier qu'elle soit l'oeuvre d'un programme, mais quel programme? (et quel algorithme?)

Dans la rubrique "critique constructive" de ton travail, on peut se demander si la devise de l'auteur de la fonction "rgb2html" n'est pas "pourquoi faire simple quand on peut faire compliqué?" !
Cette fonction se "réduit" sans état d'âme à :

function rgb2html($r,$g,$b)
{
return sprintf('#%02X%02X%02X',$r,$g,$b);
}

A part çà, bon courage pour tes améliorations!

a++
Messages postés
496
Date d'inscription
mercredi 30 juin 2004
Statut
Membre
Dernière intervention
29 juillet 2009
1
Oui!
Comme je l'ai dit la source est plus intéressante pour sa table que pour elle-même!
Merci de tes remarques; je vais en tenir compte pour son amélioration qui est déjà en cours!
Messages postés
147
Date d'inscription
lundi 16 août 2004
Statut
Membre
Dernière intervention
14 novembre 2009

Hi!,

la table "Stats" est dépendante de mon architecture

Tu pouvais en créer une avec des données bidons, de manière à éviter à la personne qui expérimente ton travail (en fait ton "client") des complications inutiles (elle n'a pas forcément une table similaire sous la main, avec les mêmes noms, etc...). L'idéal dans l'absolu étant de fournir une appli immédiatement opérationnelle : on dézippe et hop on exécute, sans même se soucier du fichier à exécuter, qui, censé s'appeler "index.php", doit être positionné à la racine de ton appli. Le hic dans tout çà, c'est l'accès aux bases de données, que l'on doit personnaliser : qu'à celà ne tienne!, tu fournis ton fichier "connexion.php" avec des données bidons, et tout le monde comprendra comment procéder!

le "BOM"

Il s'agit de 3 octets ajoutés par certains éditeurs en début de fichier pour signaler qu'il est codé en UTF.
A ce propos, lire le très instructif :
http://www.envrac.org/index.php/2006/03/11/58-un-tutoriel-sur-le-character-encoding

Pour continuer dans la critique (que j'espère constructive!) de ton travail, on est en droit de se demander l'intérêt de stocker les coordonnées de l'élément SVG dans une base de donnée, puisque SVG c'est du XML, et qu'on peut l'intégrer directement via JavaScript (avec php je suis moins catégorique), mais bon ok, j'ai compris, ton idée était de traiter simultanément le tracé des pays et le calcul de leur "coloration", mais il faut savoir qu'il existe d'autres manières de procéder.

a++
Messages postés
496
Date d'inscription
mercredi 30 juin 2004
Statut
Membre
Dernière intervention
29 juillet 2009
1
Afficher les 7 commentaires