RECHERCHE DES VILLES ET CODES POSTAUX FRANÇAIS
FhX
Messages postés
2350
Date d'inscription
mercredi 13 octobre 2004
Statut
Membre
Dernière intervention
18 avril 2015
-
7 mars 2006 à 19:04
cs_jcreno Messages postés 2 Date d'inscription lundi 5 mars 2007 Statut Membre Dernière intervention 28 octobre 2008 - 28 oct. 2008 à 10:24
cs_jcreno Messages postés 2 Date d'inscription lundi 5 mars 2007 Statut Membre Dernière intervention 28 octobre 2008 - 28 oct. 2008 à 10:24
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/36429-recherche-des-villes-et-codes-postaux-francais
https://codes-sources.commentcamarche.net/source/36429-recherche-des-villes-et-codes-postaux-francais
28 oct. 2008 à 10:24
(http://www.manuelphp.com/php/language.oop5.paamayim-nekudotayim.php)
comment traduire cela en php4 ?
J'avoue que j'ai un peu de mal là... est-ce que quelqu'un a réussi à faire fonctionner ce script en php 4 ?
merci
JC
28 oct. 2008 à 09:30
je ne comprends pas pourquoi j'ai cette erreur :
Parse error: parse error, unexpected T_STRING, expecting T_OLD_FUNCTION or T_FUNCTION or T_VAR or '}' in /var/*****/php4/ocity.cls.php on line 84
J'utilise bien le repertoire php4
ma version php : PHP Version 4.3.10-22
c'est le début de la fonction public function getSearch () {
merci pour vos lumières !
jc
4 mai 2008 à 17:24
c'est ça que n'aiment pas tes hébergeurs parce qu'ils sont en short_tags à On.
<?xml version="1.0" encoding="UTF-8"?>
Vire cette déclaration, elle n'est pas indispensable.
4 mai 2008 à 17:01
j'ai une erreur sur plusieurs hébergeur 1and1 lycos.fr seconde.fr
fallait-il faire quelque chose avant ?
Parse error: syntax error, unexpected T_STRING in /data/members/free/multimania/fr/m/a/r/marseille13015/htdocs/villes/index.php on line 4
le même message chez tous les hébergeur
Merci d'avance
2 avril 2007 à 20:18
Ca sert à quoi la possibilité de générer un fichier data2.dat ?
sinon j'ai testé et adopté sur mon serveur perso tellement ca va me rendre la vie facile...
Merci pour la réponse
Bonne prog.
@+ JLN
2 mars 2007 à 14:21
J'ai la meme erreur que jack_bauer42rn cad :
Parse error: parse error in c:\documents and settings\mat\mes documents\mon site web\projets\topcoloc\search city\villes_normal\index.php on line 4
Mais j'inclue bien les classes php4
Si je commente la ligne :
<?xml version="1.0" encoding="UTF-8"?>
en début de script, cela marche mais quand je clic sur chercher :
Warning: Invalid argument supplied for foreach() in c:\documents and settings\mat\mes documents\mon site web\projets\topcoloc\search city\villes_normal\php4\ocity.cls.php on line 105
Quelqu'un aurait une idée ? Sachant que je sais pas si je dois configurer quelquechose dans easyphp, j'ai la config par defaut.
23 oct. 2006 à 11:46
c:\program files\easyphp1-8\www\zz\villes\php5\ocity.cls.php on line 6
Tu utilises les classes PHP5, et tu es en PHP4...
Tu dois modifier les require_once du fichier index, pour inclure les classes PHP4 à la place des PHP5.
22 oct. 2006 à 09:35
merci de bien m'éclaircir afin de pouvoir exécuter le script
9 mai 2006 à 09:46
9 mai 2006 à 09:43
j'ai utilisé 2 fichiers différents, coup sur coup. Le 1er venait du site de l'université de Nice (me souviens plus l'adresse, mais c'est facile à retrouver), et l'autre, d'une source ici sur phpcs (pareil, me souviens plus de la source lol, mais en cherchant à code postal, ou villes, tu devrais retrouver) qui donnait juste cette liste à disposition.
7 mai 2006 à 18:01
C'est juste que j'ai besoin de travailler sur les villes et codes postaux et j'aurais besoin de savoir comment tu t'es débrouillé pour avoir tout ça trié par ordre alphabétique en plus.
25 avril 2006 à 15:07
19 avril 2006 à 07:47
18 avril 2006 à 19:38
Quelqu'un peut m'expliquer le 0.990585013528 ?
15 avril 2006 à 20:15
Rectification : 31 octets :) Un champs de type VARCHAR(x) prend comme place x + 1 octet =) Mais ca c'est de la broutille je reconnais :p
Maintenant, quand tu fais une recherche sur un champ en particulier... autant mettre ce champ en INDEX. Ta recherche ira beaucoup plus rapidement du fait de l'indexage.
En théorie bien sur ... !
14 avril 2006 à 18:31
CREATE TABLE `codepostal` (
`idcodepostal` int(2) unsigned NOT NULL auto_increment,
`ville` varchar(30) NOT NULL default '',
`code` int(3) NOT NULL default '0',
KEY `idcodepostal` (`idcodepostal`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1 AUTO_INCREMENT=39283 ;
Comme tu vois, rien que du très ordinaire, j'ai ajouté un champs autoincrément pour que cette table puisse
être gérée correctement depuis une interface administrateur que j'ai, le champ "ville" est exprimé sur 30 octets car la ville la plus "longue" a 27 caractères, quant au champ "code", j'ai opté pour un type numérique codé sur 3 octets, moins gourmand en octets qu'un type "varchar" qui lui aurait nécessité 6
octets.
La place occupée par la table en mémoire est de 1317 Ko, répartis sur 3 fichiers.
Je laisse (momentanément ?) la piste "BD" de côté pour me recentrer sur la piste "fichier texte", avec un
fichier préalablement ordonné et "nettoyé" (si tu supprimes les espaces ton fichier diminue de moitié), sur lequel on puisse procéder directement à une
"fouille dichotomique".
Amicalement.
14 avril 2006 à 07:56
Heu non, je ne te crois pas. lol.
C'est très curieux en effet...très!
Tu as intégré ça de quelle manière ? (quels sont les champs de la table?).
Enfin bon, si j'ai le temps aujourd'hui, je me penche à nouveau sur tout ça, et aussi sur une version mysql (ça, j'ai déja la structure, reste à adapter ces recherches).
14 avril 2006 à 01:21
Bref, j'ai intégré ton fichier dans une base de données MySQL, eh bien tu vas pas me croire, mais l'affichage de toutes les données prend dans ce cas plus de temps (dans les 24 secondes) qu'avec ta méthode du fichier texte (dans les 17 secondes).
Tout ceci me laisse plutôt perplexe.
Amicalement.
13 avril 2006 à 23:46
dis donc, je te trouve limite agressif, quand même, et je me demande bien pourquoi? M'enfin, c'est pas très grave :-) Ceci dit, je vais quand même y répondre...
Je me contre fiche que tu penses que ce soit de la flemme ou un manque de rigueur : j'ai trouvé ce fichier, je me suis dis que ça pourrait être marrant de l'exploiter de cette manière, parce que j'avais déjà dans l'idée de l'appliquer à mon amusement : coder les algo phonex et soundex2 en php.
Bref, j'ai fait ce code pour m'amuser.
Maintenant, un mec l'utilise! Bien :-) Tant mieux si ça peut-être utile.
Il commence par être content, propose des changements parce que ça ne marche pas en php4, alors évidemment j'essaye de l'aider.
Il découvre un bug...bon, ça arrive, et c'est bien : je ne l'aurais pas trouvé tout seul vu que je l'ai intégré très différemment dans un projet. Maintenant, les bugs, je n'aime pas ça, et je compte bien, le règler, dès que j'aurai 5mn.
Ceci dit, inutile de le prendre sur ce ton : ça te plait pas, tu n'utilises pas. Ou tu modifies. Et je prends en compte les critiques, et propositions d'amélioration.
Mais les critiques et les propositions, ça se fait d'une autre manière, dans une société civilisée. Du moins, c'est comme ça que j'ai toujours vu les choses.
J'en viens à la fin de ton commentaire :
"Ceci dit le boulot du développeur, c'est certe développer, mais c'est aussi se documenter sur les thèmes qu'il aborde (et auxquels il peut, dans un premier temps, ne rien comprendre), tester et retester son code, et surtout, le faire tester par d'autres !"
Merci, je connais le boulot de développeur. Et je teste, et reteste ce que je fais au boulot, qui est autrement plus important que ce que je fais ici, et pour lequel je prends évidemment plus de temps. Il est clair que si j'avais à intégrer ce code tel quel dans un projet, il serait très différent, et j'y aurais passé beaucoup plus de temps. Je suis ingénieur développeur web depuis un petit moment, et j'ai bossé dans un tas de domaines très différents, tels que les SIG, la logistique, les réseaux de transport...des domaines auxquels en effet je ne connaissais rien, et sur lesquels j'ai du me documenter, et tout faire pour en comprendre les mécanismes. Tu as donc tout à fait raison là-dessus.
Mais ça, c'est du BOULOT, c'est ma profession, et j'y consacre bien plus de temps qu'à ce que je code pour mes loisirs, pour m'amuser. Ne t'en déplaise, d'ailleurs.
Bref : j'ai pris note du bug, et de l'erreur de conception que j'ai commise par ignorance, merci, et je vais le corriger. Le jour où je coderai n'importe quoi, du premier coup, sans bug, sans erreur...sera un bien triste jour...je n'aurais plus aucun intérêt à coder.
Amicalement aussi (mais sur le même ton, c'est de bonne guerre ;-) )
13 avril 2006 à 20:23
J'ai de la chance (si on peut dire !), j'ai habité un village qui n'était pas dans ta liste, et c'est seulement ce matin que j'ai lancé une recherche directement dans "data.dat" et que j'ai découvert le "pot aux roses".
En fait, que plusieurs localités puissent avoir le même code postal semble être la règle plutôt que l'exception : je sais maintenant afficher toutes les localités, j'en dénombre 39282 alors qu'avant j'en avais seulement 6426 ! (quant au temps d'affichage, je préfère pas en parler)
C'est dire que le "manque" était important, et, à moins d'être aveugle, qu'il était difficile de ne pas s'en apercevoir !
Ceci dit le boulot du développeur, c'est certe développer, mais c'est aussi se documenter sur les thèmes qu'il aborde (et auxquels il peut, dans un premier temps, ne rien comprendre), tester et retester son code, et surtout, le faire tester par d'autres !
Amicalement.
13 avril 2006 à 13:02
13 avril 2006 à 12:47
Le code incriminé (dans ta classe "ocity") :
$this->aVilles[trim(substr($line,-6))]=strtolower(trim(substr($line,0,strlen($line)-6)));
Mais prenons un exemple :
Si une première ville "ville1" avec le code 123450 se présente, elle est stockée, ce qui donne :
$this->aVilles[123450]="ville1";
Ok, jusque là tout va bien.
Si une deuxième ville "ville2" avec le même code 123450 se présente, elle est stockée, ce qui donne :
$this->aVilles[123450]="ville2";
Et là, rien ne va plus, puisque cette opération écrase "ville1" qui disparaît de ce fait du tableau !
Donc, y'a encore du boulot ! (et pour cette erreur grossière, j'irai bien diminuer la note que je t'ai donné, mais bon...)
Amicalement.
13 avril 2006 à 07:29
je vais tâcher de répondre point par point :
- fichier de données incomplet. Oui, je le sais! Mais je m'en fiche, lol, pour une raison simple : les dernières versions de ce code utilise un fichier de type csv (si ce n'est pas le cas, c'est que j'ai oublié d'uploader la dernière version, je vérifierai), donc facile à reproduire. Et on peut donc imaginer que n'importe qui pourra fournir ces propres données.
Par contre, je ne savais pas que plusieurs villages pouvaient partager le même code postal. C'est nettement plus ennuyeux, il faut effectivement réécrire le tableau, et donc le parsing du tableau. "Et toi tu exploites cette propriété pour établir ton tableau $aVilles, qui à chaque clé fait correspondre une valeur (ce qui, en matière de tri, est plutôt relax)." => ben oui, pensant que cela fonctionnait ainsi, je n'allais pas compliquer inutilement les choses?
Je n'ai pas voulu avoir un code forcément très rapide (sans quoi, j'aurais pris une bdd). Il y a pas mal de choses à faire pour le rendre plus rapide : virer soundex2 et phonex en effet (il y a normalement une version sans, d'ailleurs, dans le zip) qui sont là pour le fun. Et puis il serait inutile d'utiliser les deux.
En résumé, tu as eu tout à fait raison d'adapter le code, et de le réécrire pour l'adapter à tes besoins. Virer la POO est évidemment une bonne idée quand on recherche la performance :-) Toujours!
Ceci dit, les deux gros points noirs sont : absence de bdd (et donc stockage en mémoire!), et algos phonex et soundex. Virer les algos fait déjà énormément. Une bdd rendrait le truc quasi instantannée.
ceci dit, tu m'as donné des idées...on peut voir à réécrire le tout pour laisser des choix :-) Enfin on verra, j'ai vraiment plus le temps en ce moment.
13 avril 2006 à 01:07
Un gros soucis : ton fichier de données "data.dat" est incomplet.
En effet, dans les campagnes, il arrive souvent que des villages appartenant au même secteur géographique aient le même code postal (pour des raisons d'ailleurs que j'ignore mais on peut demander pourquoi au facteur et pourquoi aussi le dernier chiffre du code est toujours 0, çà supprime des possibilités de codage, mais bon, on n'est pas là pour réformer l'administation, bref).
Ton fichier exprime donc une vision réductrice de la réalité en associant à chaque code une ville et une seule (inversement, à une ville peut correspondre plusieurs codes, mais çà, on s'en fiche).
Et toi tu exploites cette propriété pour établir ton tableau $aVilles, qui à chaque clé fait correspondre une valeur (ce qui, en matière de tri, est plutôt relax).
En résumé : ton appli n'est pas vraiment opérationnelle, non pas à cause de ton code, mais à cause des données, dont sont absentes beaucoup de petites localités !
Cependant, en admettant que tu disposes du "vrai" fichier avec toutes les villes (un fichier forcément plus gros), tu serais amené à reformuler ton tableau, ainsi que revoir le code pour le traiter, entrainant un temps d'exécution forcément plus important.
Tu l'auras peut-être compris, mon soucis majeur dans ce type d'application c'est l'optimisation du code, laquelle représente un véritable challenge.
C'est pourquoi je ne me suis guère préoccupé des aspects "phonex" et "soundex" que tu as développé (et qui pourtant m'intéressent), à cause de leurs temps d'exécution vraiment trop monstrueux.
Aussi ne le prends pas mal si je te dis que j'ai réécris ton code : pas de POO, tout dans le même fichier, séparation du style (en fait un code très basique pour débutant que je tiens à ta disposition). Je ne sais pas si le gain de temps est du côté serveur ou du côté client, mais le résultat est là : pour afficher toutes les villes en tapant "*", mon temps d'exécution est divisé par 3 !
Pourtant les modifs effectuées ne sont pas vraiment des optimisations !
Par "optimisation" on pourrait par exemple envisager des fichiers de données déjà triés (un fichier trié par ville et un autre trié par code) sur lesquels on pourrait faire des recherches dichotomiques pour éviter le parcours séquentiel de tout le tableau, on pourrait y mettre le nom des villes directement en minuscules (si l'affichage doit se faire ainsi), on pourrait voir ce que celà donne avec les bases de données, etc...
Voilà, j'espère ne pas t'avoir trop saoulé avec ce roman.
Je te mets 8.
Amicalement.
21 mars 2006 à 19:15
20 mars 2006 à 20:50
Ouais c'est vite dit ca :D
Ah ah ah :p :p :p
17 mars 2006 à 11:34
J'ai laissé l'ancienne version, dans le répertoire 'villes_normal'.
L'autre s'appelle 'ville' et intègre donc les recherches soundex2, phonex et le tri par pertinence.
Attention, c'est plus lent!
17 mars 2006 à 09:14
La doc, c'est une erreur de ma part si j'ai mis les versions anglaises et allemandes, je vais les virer, elles n'ont rien à faire sur cs, site français.
Tu as raison su le fait qu'un code en apparence énorme peut faire peur...ne même temps, je ne le vends pas, ce code, je le donne, alors si il ne marche pas spécialement, je m'en tape un peu lol ;-)
Et puis quoi, je suis malalam, les utilisateurs de CS me connaissent, ils savent à quel point je fais de bons codes ;-) (je plaisante hein).
Et puis pour être honnête, c'est un peu pour faire connaître ClassFuncDoc, mon outil de génération de documentations. Je ne le vends pas non plus, mais j'y ai passé du temps (j'en passe encore), je pense que c'est réellement une bonne appli, et là, ça me ferait plaisir que les gens l'apprécient et l'utilisent, par contre :-)
Je vais faire un ajout à ce code, aujourd'hui si j'ai le temps. Je vais rajouter 2 types de recherche (ce qui fait que le code va s'allonger lol, mais comme je vais virer les docs non françaises...ça équilibrera ;-) ). Je vais ajouter, donc, les recherches soundex2 et phonex, pour mettre en application mes 2 derniers codes : soundex2 et phonex...(je sais, c'est orioginal lol). Bref, des recherches phonétiques, que je vais coupler à Levenshtein pour avoir un tri par pertinence.
Enfin, vous verrez, pour ceux qui testeront ;-)
17 mars 2006 à 00:40
Tout çà pour te dire que mettre en ligne une multitude de fichiers c'est prendre le risque de faire fuir d'éventuels "clients" qui vont se dire : encore une appli monstrueuse qui veut en mettre plein la vue mais qui va planter à la première occasion !
J'ai pas noté ton code vu que je ne l'ai pas vraiment étudié (n'ayant pas tous les éléments pour le faire).
Je viens de télécharger tout un tas de tutoriaux sur XML, ce n'est donc que partie remise.
Amicalement.
16 mars 2006 à 07:37
Très honnêtement, la plupart de mes codes prennent en compte que short_open_tag est à Off, register_globals à Off, et autres broutilles du genre ;-) Sans se soucier d'un autre réglage.
J'aimerais bien, vraiment, que les développeurs de PHP virent enfin ce short tag incompatible avec la norme XHTML.
Merci, sinon :-)
15 mars 2006 à 21:32
Je voudrai signaler un petit désagrément imputable à la variable "short_open_tag" de php.ini, quand celle-ci est à "on" (EasyPhp par défaut, Free, etc...) : concrètement çà revient à assimiler <? au tag d'ouverture du code php.
Or, au début de "index.php" on a :
<?xml version="1.0" encoding="UTF-8"?>
très bon code s'il en est, mais source de plantage s'il est considéré comme du php.
Une solution immédiate consiste à transférer ce code à l'intérieur des balises php sous la forme :
echo "<?xml version='1.0' encoding='UTF-8'?>";
Ceci-dit, celà ne dispense pas de mettre "short_open_tag" à "off" (quand c'est possible) et de commencer le php par <?php
Amicalement.
15 mars 2006 à 07:54
ici :
$aTmp = array_filter (array_flip ($this -> aVilles), array ('self', 'getFirst'));
et ici :
$aTmp = array_filter ($this -> aVilles, array ('self', 'getFirst'));
remplace le
array ('self', 'getFirst')
par
array ($this, 'getFirst')
15 mars 2006 à 07:38
J'ai testé ma version php4 avec un serveur en php5, alors je me suis peut-être manqué, et j'ai mon idée du pourquoi...
Je te donnerai un test à faire (des modifications) dans la journée :-)
Je pense qu'on a un problème avec la méthode callback.
15 mars 2006 à 01:50
Warning: array_filter(): The second argument, 'self::getFirst', should be a valid callback in ..\php4\ocity.cls.php on line 57
Warning: array_flip(): The argument should be an array in ..\php4\ocity.cls.php on line 58
Warning: ksort() expects parameter 1 to be array, boolean given in ..\php4\ocity.cls.php on line 60
Warning: Invalid argument supplied for foreach() in ..\php4\ocity.cls.php on line 74
Sachant que j'ai fait le nécessaire dans Index.php pour que ton code fonctionne avec php4, que la version du code est celle du 13/03/2006 à 20h, et que, en dehors des warnings indiqués plus-haut ne s'affiche qu'un cadre avec dedans marqué "Code" et
"Ville", tu auras je pense en ta possession les éléments pour solutionner cette misérable broutille.
Mieux vaut un qui sait que dix qui cherchent.
Amicalement.
7 mars 2006 à 19:28
pour le static, t'as raison, j'y ai pas pensé.
Pour le is_array (), c'est un reste d'une autre manière de faire lol. Je l'enlèverai ouai.
Pour le trim...heu...mea culpa, mauvaise habitude prise parce que mon boss veut faire ça comme ça, même si je lui ai proubé que c'était con lol.
Exact pour $sSearch, tien.
Marci sinon :-)
Je ferai quelques modifs demain.
;-)
7 mars 2006 à 19:04
J'aurais mis getFirst en statique moi étant donné que c'est une méthode de callback :)
"array_filter() retourne un tableau contenant les éléments du tableau input, filtrés grâce à la fonction callback. Si input est un tableau associatif, les clés sont préservées."
Donc plus besoin du if(is_array($aTmp)) dans ta méthode getSearch() :)
"&& '' !== trim ($_POST['data']))" rhoo t'as pas honte ?? ;)
if ( isset($_POST['data']) && !empty(trim($_POST['data'])) ) { // }
" $this -> sSearch = strtolower ($_POST['data']); "
T'as oublié de définir sSearch dans tes propriétés ;)
Pas mal pas mal sinon :)