Re: [OSM-dev-fr] Intégration toponymes Occitan
Le 03/10/2014 14:30, Frédéric Rodrigo a écrit : Le 03/10/2014 14:20, Christophe Merlet a écrit : Le 03/10/2014 13:44, Frédéric Rodrigo a écrit : Avec les ref insee c'est quand même bien mieux. Mais je ne suis pas sûr que la qualité des données soit pour l'instant suffisante. Tu peux remonté les problèmes et/ou obtenir des éclaircissements ? - certaines traduction qui contienne des virgules, des slashs ou des tirets quadratins mal utilisé je pense : Sent Perdon – Isac : Saint-Pardoux-Isaac c'est la traduction des noms des communes, ou des noms des villages ? - le texte entre parenthèse doit probablement être ignoré (à confirmer ?) - Les-Artigues-de-Lussac : Les Artigues-de-Lussac, des fois il y a des tirets, mais dans la plus part des cas ils n'y sont pas. - L'article n'est pas systématiquement passé entre parenthèse, c'est volontaire ? - le détrompeur est parfois présent, parfois absent : Castèthnau dau Medòc : Castelnau-de-Médoc Castra : Castres-Gironde - les capitales sur les article ne sont pas toujours homogènes: Senta Fe La Granda : Sainte-Foy-la-Grande Sent Feliç de font Cauda : Saint-Félix-de-Foncaude Je suis à la recherche d'une **solution technique** pour mettre à jour des tags depuis un fichier CSV, pas d'un audit qualité. Techniquement cela ne pas de problème, en tout cas pour moi. Faire un script et intégrer les données dans OSM est l'affaire d'une-demi heure. Je n'en ai jamais douté ! Et je constate que tu ne donne toujours aucune piste pour permettre à quelqu'un d'autre de travailler efficacement sur cet import. Rien n’empêche d'importer les communes qui ne pose aucun problèmes, et ça en fait des milliers, au lieu de reporter depuis plusieurs mois cet import. Surtout que les problèmes que tu soulèves sont triviaux et se corrigent par un simple regexp. Je pense qu'il vaut quand même mieux corriger les données à la source et importer dans OSM les mêmes données que celles publiées par Lo Congrès. Ce serait la première fois que l'on attends d'une source potentiel de données qu'elle se mette au standard qualité d'OSM au lieu d'effectuer nous-même ce travail. (ROUTE 500, Cadastre, FANTOIR, ...) La question est la même que pour la mise à jour des populations de communes qui aurait du idéalement être fait dés la publication par l'INSEE des chiffres officiels de 2014. Idem. Je pense que personne ne le fait parce que l'intérêt est assez faible. Ceux qui y ont un intérêt ne le font pas car il ne savent pas automatiser une tâche qui nécessite plus de 72000 éditions, et ceux qui savent automatiser la tache ne le font pas parce qu'ils n'y voit aucun intérêt. Ce n'est pas très productif. Et depuis quand avoir la population à jour dans OSM serait sans intérêt ? Librement, -- Christophe Merlet (RedFox) ___ dev-fr mailing list dev-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev-fr
[OSM-dev-fr] Intégration toponymes Occitan
Bonjour, Lo Congrès m'a fait parvenir une mise à jour de son fichier de plus de 4500 toponymes en Occitan indexés sur le code INSEE des communes. Y a t'il un volontaire pour scripter l'import automatique de ces traductions sur les limites communales et les node place correspondant ? Le fichier est téléchargeable à l'adresse https://owncloud.redfoxcenter.org/public.php?service=filest=f644eccca351c5657e95ab24183edff4 Ce serait bien de le faire car il y a actuellement beaucoup de demande pour une carto en occitan. De plus, un colloque est en train d'être organisé par la DGLFLF (Délégation générale de la langue française et des langues de France, un département du Ministère de la culture et de la communication) pour février 2015 sur les ressources numériques des langues de France. Ce serait pas mal qu'OSM puisse y présenter une carto en Occitan la plus exhaustive possible à cette occasion. Librement, -- Christophe Merlet (RedFox) ___ dev-fr mailing list dev-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev-fr
[OSM-dev-fr] Fwd: Re: [OSM-dev] Wikimedia Foundation Job Offering
Message transféré Sujet : Re: [OSM-dev] Wikimedia Foundation Job Offering Date : Fri, 12 Sep 2014 01:09:16 +0200 De :Cristian Consonni kikkocrist...@gmail.com Pour : Simon Poole si...@poole.ch Copie à : d...@openstreetmap.org Il 11/Set/2014 23:26 Simon Poole si...@poole.ch mailto:si...@poole.ch ha scritto: I believe this hasn't actually been posted here (it has been on osmf-talk and a couple of other places): http://boards.greenhouse.io/wikimedia/jobs/24983?t=4w5iyb#.VBIBukiFUZw Oh, right. I just posted it on talk@. C ___ dev mailing list d...@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev ___ dev-fr mailing list dev-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev-fr
Re: [OSM-dev-fr] glonflement des tables osm2pgsql...
Le 12/08/2014 18:47, Philippe Verdy a écrit : DELETE/INSERT la plupart du temps va réutiliser la page dans laquelle il vient de créer un trou, mais au passage il peut aussi utiliser n'importe quelle autre page déjà en mémoire si cette autre page permet un meilleur équilbrage de l'arbre que de réutiliser l'ancienne page: le but est d'équilibrer les trous dans les pages pour éviter de se retrouver dans le cas au pire (le pire cas c'est une insertion au milieu d'une page déjà pleine, quand toutes les pages racines sont déjà pleines, ce qui arrive justement après une compression maximale de la table: c'est là qu'on a le plus d'I/O puisqu'il faut non seulement scinder la page en deux, lire les pages voisines avant et après, et restructurer aussi les pages parentes dans l'arbre de la même façon). Je n'ai pas eu souvent à mettre dans une base SQL un fill factor supérieur à 85% (au moins pour les pages feuilles). pour les tables de données, ni supérieur à 95% pour les index secondaires à clé courte. 97% est un taux exceptionnel et au delà ça rame dès qu'il y a plus de 3 ou 4 accès concurrents (même en lecture, à cause des nombreux locks de pages causés sur une grande partie des pages y compris les pages mères, et à cause des volumes d'I/O). Je te signale quand même que PostgreSQL a un fillfactor par defaut de 100 pour les data et de 90 pour les index B-tree. J'imagine que les dev auraient choisi d'autres valeurs si cela était si impactant sur les performances. Il serait plus intéressant que tu donnes les bonnes valeurs à utiliser dans le cas d'une base mapnik monde mise à jour toutes les minutes... Si on veut une base rapide, on doit accepter qu'il y ait des trous à un taux raisonnable dans les tables volumineuses ayant de nombreux accès concurrents (surtout que pour ce type de base on à toutes sortes de types d'accès: séquentiels comme aléatoires, par une grande diversité de requêtes utilisant des filtres très différents, et des sélectivités de clés imprévisibles dans les données OSM). Le 12 août 2014 18:36, Christophe Merlet red...@redfoxcenter.org mailto:red...@redfoxcenter.org a écrit : Le 12/08/2014 17:30, Francescu GAROBY a écrit : Je pensais plutôt à tester la présence (via un SELECT sur l'osm_id, qui doit être un champ indexé, je suppose...) et, selon la réponse, à faire un INSERT ou un UPDATE. Si un SELECT est sensiblement aussi rapide qu'un DELETE, et un INSERT aussi rapide qu'un UPDATE, tu ne verras pas de différence notable sur le temps de traitement, mais tu auras résolu ton problème de trous de partout. Francescu, (qui est développeur, pas DBA) Généralement DELETE/INSERT est plus rapide que UPDATE. Et de ce que j'ai pu lire sur pgsql, UPDATE execute en interne un DELETE/INSERT avec donc la création de trou dans la base. Librement, -- Christophe Merlet (RedFox) ___ dev-fr mailing list dev-fr@openstreetmap.org mailto:dev-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev-fr ___ dev-fr mailing list dev-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev-fr -- Christophe Merlet (RedFox) ___ dev-fr mailing list dev-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev-fr
Re: [OSM-dev-fr] glonflement des tables osm2pgsql...
Le 12/08/2014 21:38, Christian Quest a écrit : Le 12 août 2014 21:07, Christophe Merlet red...@redfoxcenter.org mailto:red...@redfoxcenter.org a écrit : Le 12/08/2014 20:44, Christian Quest a écrit : Ah bon, postgres n'essaye pas de faire un update sur place quand c'est possible ? Non. UPDATE étant une opération de type DELETE/INSERT ( http://postgresql.todaysummary.com/q_postgresql_32709.html ) Marrant je n'ai pas la même lecture que toi... je ne vois pas de référence au DELETE dans ces explications, juste une proposition pour faire l'équivalent du REPLACE de mysql qui fait soit un INSERT soit un UPDATE si la ligne existe déjà. Ho zut, je me suis trompé de lien oO rien à voir !! C'est celui là http://www.postgresql.org/message-id/482e80323a35a54498b8b70ff2b879800458c31...@azsmsx504.amr.corp.intel.com alors les mises à jour sont faites là où il y a de la place même avec un CLUSTER. http://www.postgresql.org/docs/9.3/interactive/sql-cluster.html Clustering is a one-time operation: when the table is subsequently updated, the changes are not clustered. That is, no attempt is made to store new or updated rows according to their index order. SAUF si la table est CLUSTERé avec un fillfactor 100 , ça peut rester dans la même page. Also, setting the table's FILLFACTOR storage parameter to less than 100% can aid in preserving cluster ordering during updates, since updated rows are kept on the same page if enough space is available there. Tel que je le comprends, ce since updated rows are kept on the same page if enough space is available there ne me semble pas être lié au fait que la table ait été CLUSTERisée ni lié à la valeur de fillfactor. Ca serait assez logique d'un point de vue perf qu'un UPDATE d'une ligne essaye de le faire dans la même page tant qu'à faire. Je pense donc qu'un UPDATE est vraiment géré de façon différente d'un DELETE, puis d'un INSERT qui sont traités de façon totalement indépendantes. Même la mise à jour des index bénéficie d'un UPDATE sur place... seuls les index concernant les colonnes modifiées ont dans ce cas besoin d'être remis à jour si on fait ça bien, alors qu'avec un DELETE+INSERT il faudra les mettre à jour eux aussi 2 fois systématiquement. Un courageux pour jeter un oeil sur le code de postgres ? J'ai un peu regardé... mais je me suis vite perdu ! :( Bref, tant qu'un (auto)vacuum n'a pas indiqué explicitement qu'une lignes est obsolete, son emplacement n'est pas dispo à la réutilisation dans une page, même en cas d'UPDATE. auto-vacuum fonctionne-t-il réellement comme ça ? Je n'ai pas non plus l'impression. C'est comme ça que je comprend la doc http://www.postgresql.org/docs/current/static/sql-vacuum.html VACUUM reclaims storage occupied by dead tuples. In normal PostgreSQL operation, tuples that are deleted or obsoleted by an update are not physically removed from their table; they remain present until a VACUUM is done. Therefore it's necessary to do VACUUM periodically, especially on frequently-updated tables. Quand efface une ligne, la fsm (free space map) est mise à jour pour la page pour noter que de l'espace est dispo sur cette page. Quand postgres a besoin d'espace il commence à regarder par là. Il y a une extension qui permet d'explorer ça si on veut: pg_freespacemap -- Christophe Merlet (RedFox) ___ dev-fr mailing list dev-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev-fr
Re: [OSM-dev-fr] Shapé les admin_level=boundary
Le 17/12/2013 11:43, Christian Quest a écrit : Je confirme, très très lent... 69 secondes pour transformer 8 linestring en topo... à ce rythme, vu qu'il y en a 109902, ça va mettre plus de 10j ! Donc si je veux avoir des limites simplifiées d'ici demain 16h30 je retourne à mes requêtes ;) Je viens de simplifier manuellement les limites de régions une par une à 1m (quasi l'épaisseur du trait dans le cadastre) dans JOSM en moins de 3 mn Statistiquement ça a supprimé 130 833 nœuds sur 619 858. sur 7759 chemins. Il serait sans doute intéressant de pouvoir extraire de JOSM cet algo, ou rendre JOSM scriptable sans avoir besoin d'afficher le fichier osm à l'écran. 2ème point. Il serait bon de simplifier dans OSM ces limites de communes abusivement et inutilement détaillées. Les limites de 2 communes limitrophes ne se superposent déjà pas dans le cadastre, alors ce n'est pas en les dessinant avec énormément de points, quelles seront plus précises. Je vais faire une simplification à 10m et à 100m pour voir... Librement, -- Christophe Merlet (RedFox) ___ dev-fr mailing list dev-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev-fr
Re: [OSM-dev-fr] Shapé les admin_level=boundary
Le 17/12/2013 12:01, Christophe Merlet a écrit : Le 17/12/2013 11:43, Christian Quest a écrit : Je confirme, très très lent... 69 secondes pour transformer 8 linestring en topo... à ce rythme, vu qu'il y en a 109902, ça va mettre plus de 10j ! Donc si je veux avoir des limites simplifiées d'ici demain 16h30 je retourne à mes requêtes ;) Je viens de simplifier manuellement les limites de régions une par une à 1m (quasi l'épaisseur du trait dans le cadastre) dans JOSM en moins de 3 mn Statistiquement ça a supprimé 130 833 nœuds sur 619 858. sur 7759 chemins. Il serait sans doute intéressant de pouvoir extraire de JOSM cet algo, ou rendre JOSM scriptable sans avoir besoin d'afficher le fichier osm à l'écran. 2ème point. Il serait bon de simplifier dans OSM ces limites de communes abusivement et inutilement détaillées. Les limites de 2 communes limitrophes ne se superposent déjà pas dans le cadastre, alors ce n'est pas en les dessinant avec énormément de points, quelles seront plus précises. Je vais faire une simplification à 10m et à 100m pour voir... à 10m je supprime 435 367 noeuds... à 100m, j'en supprime 578 441 soit plus de 93% Pour faire mieux dans JOSM, il faudrait refusionner les chemins qui composent les limites de régions avant de lancer la simplification. Librement, -- Christophe Merlet (RedFox) ___ dev-fr mailing list dev-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev-fr
Re: [OSM-dev-fr] Shapé les admin_level=boundary
Le 17/12/2013 12:15, Pieren a écrit : 2013/12/17 Christophe Merlet red...@redfoxcenter.org: 2ème point. Il serait bon de simplifier dans OSM ces limites de communes abusivement et inutilement détaillées. Finalement, c'est comme dans OSM ;-) Ils ont des contributeurs à précision géométrique variable ;-) Les limites de 2 communes limitrophes ne se superposent déjà pas dans le cadastre, alors ce n'est pas en les dessinant avec énormément de points, quelles seront plus précises. Pour quelqu'un qui cherche sa parcelle, le niveau de détail peut avoir son importance (c'est toujours une question d'échelle). Et on peut toujours simplifier alors que l'inverse n'est pas possible. Le fait qu'elles ne se superposent pas d'une commune à l'autre n'est pas lié à leur niveau de détails. En plus, ça serait directement faire mentir le communiqué de presse qui vante le nombre de points 15 fois supérieur à geofla ;-) On peut dessiner une ligne droite avec 30 points, elle ne sera pas plus précise que celle qui se contente de 2 points. Librement, -- Christophe Merlet (RedFox) ___ dev-fr mailing list dev-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev-fr
Re: [OSM-dev-fr] Shapé les admin_level=boundary
Le 17/12/2013 12:24, Christian Quest a écrit : Ah si... on est sûr qu'elle est droite et pas simplifiée ;) Toute la subtile différence entre résolution et précision :) Le 17 décembre 2013 12:23, Christophe Merlet red...@redfoxcenter.org mailto:red...@redfoxcenter.org a écrit : Le 17/12/2013 12:15, Pieren a écrit : 2013/12/17 Christophe Merlet red...@redfoxcenter.org mailto:red...@redfoxcenter.org: 2ème point. Il serait bon de simplifier dans OSM ces limites de communes abusivement et inutilement détaillées. Finalement, c'est comme dans OSM ;-) Ils ont des contributeurs à précision géométrique variable ;-) Les limites de 2 communes limitrophes ne se superposent déjà pas dans le cadastre, alors ce n'est pas en les dessinant avec énormément de points, quelles seront plus précises. Pour quelqu'un qui cherche sa parcelle, le niveau de détail peut avoir son importance (c'est toujours une question d'échelle). Et on peut toujours simplifier alors que l'inverse n'est pas possible. Le fait qu'elles ne se superposent pas d'une commune à l'autre n'est pas lié à leur niveau de détails. En plus, ça serait directement faire mentir le communiqué de presse qui vante le nombre de points 15 fois supérieur à geofla ;-) On peut dessiner une ligne droite avec 30 points, elle ne sera pas plus précise que celle qui se contente de 2 points. Librement, -- Christophe Merlet (RedFox) ___ dev-fr mailing list dev-fr@openstreetmap.org mailto:dev-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev-fr -- Christian Quest - OpenStreetMap France Un nouveau serveur pour OSM... http://donate.osm.org/server2013/ ___ dev-fr mailing list dev-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev-fr -- Christophe Merlet (RedFox) ___ dev-fr mailing list dev-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev-fr
Re: [OSM-dev-fr] Shapé les admin_level=boundary
Le 16/12/2013 15:31, Christophe Merlet a écrit : Le 16/12/2013 15:01, Rodolphe Quiédeville a écrit : Bonjour, Est-ce que quelqu'un à par devers lui les limites administratives extraites d'OSM au format shapefile ? Soit les données, soit le script pour le faire, voir une méthode à implémenter. Pour les départements j'ai utilisé Geofla, mais il me faudrait les limites nationales des pays européens désormais. http://www.data.gouv.fr/DataSet/30383060 J'essaie d'extraire les données en utilisant l'Overpasse API. C'est pas la joie. Voici ce que j'ai utilisé pour les régions... Dans un fichier nommé oapi_region.xml union query type=relation has-kv k=boundary v=administrative/ has-kv k=admin_level v=4/ has-kv k=ref:INSEE/ /query recurse type=relation-node into=nodes/ recurse type=relation-way/ recurse type=way-node/ /union print mode=meta/ Puis avec wget : $ wget -O oapi_region.osm --post-file=oapi_region.xml http://oapi-fr.openstreetmap.fr/oapi/interpreter J'obtiens un fichier oapi_region.osm de 125 Mo utilisable dans JOSM. Pour d'autres frontières, il faut jouer avec les balises has-kv Et sur l'ensemble de l'Europe, utiliser un autre serveur oapi que celui de l'exemple qui est restreint à la France. Je viens de regarder pour extraire les frontières des pays d'Europe de cette manière. Ce n'est pas évident de faire le tri entre les frontières Terre et Maritime et ne sélectionner que les pays d'Europe. Il faudrait au préalable, me semble t'il, harmoniser les diverses relations de pays et y rajouter quelques balises comme is_in:continent Librement, -- Christophe Merlet (RedFox) ___ dev-fr mailing list dev-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev-fr
Re: [OSM-dev-fr] Shapé les admin_level=boundary
Le 16/12/2013 15:53, Christophe Merlet a écrit : Le 16/12/2013 15:31, Christophe Merlet a écrit : Le 16/12/2013 15:01, Rodolphe Quiédeville a écrit : Bonjour, Est-ce que quelqu'un à par devers lui les limites administratives extraites d'OSM au format shapefile ? Soit les données, soit le script pour le faire, voir une méthode à implémenter. Pour les départements j'ai utilisé Geofla, mais il me faudrait les limites nationales des pays européens désormais. http://www.data.gouv.fr/DataSet/30383060 J'essaie d'extraire les données en utilisant l'Overpasse API. C'est pas la joie. Voici ce que j'ai utilisé pour les régions... Dans un fichier nommé oapi_region.xml union query type=relation has-kv k=boundary v=administrative/ has-kv k=admin_level v=4/ has-kv k=ref:INSEE/ /query recurse type=relation-node into=nodes/ recurse type=relation-way/ recurse type=way-node/ /union print mode=meta/ Puis avec wget : $ wget -O oapi_region.osm --post-file=oapi_region.xml http://oapi-fr.openstreetmap.fr/oapi/interpreter J'obtiens un fichier oapi_region.osm de 125 Mo utilisable dans JOSM. Pour d'autres frontières, il faut jouer avec les balises has-kv Et sur l'ensemble de l'Europe, utiliser un autre serveur oapi que celui de l'exemple qui est restreint à la France. Je viens de regarder pour extraire les frontières des pays d'Europe de cette manière. Ce n'est pas évident de faire le tri entre les frontières Terre et Maritime et ne sélectionner que les pays d'Europe. Il faudrait au préalable, me semble t'il, harmoniser les diverses relations de pays et y rajouter quelques balises comme is_in:continent Si j'en crois le wiki http://wiki.openstreetmap.org/wiki/Relation:boundary Il faudrait les balises suivantes sur les frontières terrestres pour les extraire facilement : has-kv k=land_area v=administrative/ has-kv k=admin_level v=2/ has-kv k=is_in:continent v=Europe/ Malheureusement, il semblerait qu'aucune limite de pays ne répondent a ces critères ! Ce n'est pas insurmontable, cela ne concernent que 42 relations déjà existante si l'on parle d'Europe continentale... Librement, -- Christophe Merlet (RedFox) ___ dev-fr mailing list dev-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev-fr
Re: [OSM-dev-fr] Shapé les admin_level=boundary
Le 16/12/2013 17:54, Pierre Béland a écrit : J'ai ajouté à ta requête les instructions pour délimiter la zone où extraire les données. Le paramètre area-query ref=1403916/ permet d'extraire les données pour la France. C'est une requête prend beaucoup de temps à exécuter. A partir du site http://overpass-api.de, la requête suivante me permet d'extraire les limites administratives. osm-script timeout=360 union query type=relation has-kv k=boundary v=administrative/ has-kv k=admin_level v=4/ has-kv k=ref:INSEE/ /query recurse type=relation-node into=nodes/ recurse type=relation-way/ recurse type=way-node/ area-query ref=1403916/ /union print mode=meta/ /osm-script C'est super comme paramètre, mais tu l'as déniché où ? Je ne l'ai pas trouvé dans la doc :/ Librement, -- Christophe Merlet (RedFox) ___ dev-fr mailing list dev-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev-fr
Re: [OSM-dev-fr] Proposition d'amélioration de la gestion du cache
Le 06/05/2013 14:09, Philippe Verdy a écrit : Là aussi on peut penser à une autre piste: JUST DO IT Librement, -- Christophe Merlet (RedFox) ___ dev-fr mailing list dev-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev-fr
[OSM-dev-fr] Stats cache de tuiles OSM
Bonjour, Après quelques jours de fonctionnement du cache de tuiles OSM de Pau, je suis en mesure de fournir quelques stats. Je voulais pouvoir afficher des stats sur les tuiles consultés (hits, urls et bande passante par niveau de zoom) Je voulais savoir de quel pays proviennent les visiteurs et combien il y en avait. Je voulais savoir de quelles FAI proviennent les visiteurs. Je voulais savoir de quelles AS (système autonome) proviennent les visiteurs. Les fichiers de Logs dépassent le Go et les 9 millions de lignes. Il faut un outil assez rapide... tant qu'a faire ! Le serveur a tenu jusqu'à 600 000 hits dans l'heure. J'ai testé quelques solutions d'analyse de logs Squid et je n'en ai trouvé qu'un seul capable de trier sur les AS : webalizer_asn http://www.init7.com/webalizer_asn/readme_asn.php Une version patchée de webalizer Malheureusement cette solution est obsolète... j'y reviendrais... Les résultats d'analyses avec webalizer_asn et webalizer : http://nominatim.paulla.asso.fr/webalizer-asn/usage_201212.html http://nominatim.paulla.asso.fr/webalizer/usage_201212.html Je disais donc que webalizer_asn est obsolète. Init7 fournit un fichier d'AS vieux de presque 2 ans généré par un collecteur BGP (Piranha) qui n'a pas été mis à jour depuis plus de 7 ans :( Résultat, 16% d'IP non résolu, et je ne sais combien d'attribué au mauvais AS De plus, Webalizer n'affiche pas directement le propriétaire de l'AS, il faut cliquer sur un lien cassé pour l'obtenir. Et il ne gère pas l'IPv6. Webalizer lui même a d'autres problèmes : A partir du moment ou l'on active la résolution DNS des adresses IP, les stats sur les Pays sont farfelus car se basant sur le nom d'hôtes résolus et non plus sur GeoIP ou GeoDB. Résultat, on a 30% de .net, 5% de .com, etc. Ce qui n'a rien à voir avec la localisation géographique des visiteurs. Bref, si un codeur ne sait pas comment occuper ses vacances de Noël, je lui propose de faire un joli patch pour la dernière version de Webalizer permet de gérer les AS (IPv4 et éventuellement IPv6) avec les bases à jour de Maxmind https://www.maxmind.com/en/asnum Sachant que Webalizer utilise déjà GeoIP pour les pays, http://dev.maxmind.com/geoip/geolite On doit presque pouvoir dupliquer quelques bouts de code pour le faire ;o) et s'inspirer fortement de webalizer_asn... Et en profiter pour corriger le bug des stats par pays avec GeoDB/GeoIP lorsque la résolution DNS est activé. J'ai par ailleurs le sentiment que Webalizer peut être accéléré si il travaille uniquement sur les IP et ne fait les résolutions IP-hostname IP-GeoIP et IP-AS qu'à la fin. Si vous connaissez un volontaire ? Librement, -- Christophe Merlet (RedFox) signature.asc Description: This is a digitally signed message part ___ dev-fr mailing list dev-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev-fr
Re: [OSM-dev-fr] Stats cache de tuiles OSM
Le dimanche 23 décembre 2012 à 20:01 +0100, Christophe Merlet a écrit : Bonjour, Bref, si un codeur ne sait pas comment occuper ses vacances de Noël, je lui propose de faire un joli patch pour la dernière version de Webalizer permet de gérer les AS (IPv4 et éventuellement IPv6) avec les bases à jour de Maxmind https://www.maxmind.com/en/asnum Sachant que Webalizer utilise déjà GeoIP pour les pays, http://dev.maxmind.com/geoip/geolite On doit presque pouvoir dupliquer quelques bouts de code pour le faire ;o) et s'inspirer fortement de webalizer_asn... Et j'oublie la possibilité d’agréger les AS appartenant au même backbone. Exemple AS-RENATER qui est composé de plusieurs dizaines d'AS publiques http://bgp.he.net/irr/as-set/AS-RENATER , AS-LDCOMNET http://bgp.he.net/irr/as-set/AS-LDCOMNET ou AS-OPENTRANSIT http://bgp.he.net/irr/as-set/AS-OPENTRANSIT Et en profiter pour corriger le bug des stats par pays avec GeoDB/GeoIP lorsque la résolution DNS est activé. J'ai par ailleurs le sentiment que Webalizer peut être accéléré si il travaille uniquement sur les IP et ne fait les résolutions IP-hostname IP-GeoIP et IP-AS qu'à la fin. Si vous connaissez un volontaire ? Librement, -- Christophe Merlet (RedFox) signature.asc Description: This is a digitally signed message part ___ dev-fr mailing list dev-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev-fr
Re: [OSM-dev-fr] [OSM-talk-fr] Tr : [OSM-talk] New OpenStreetMap tile server
pour openmapquest, inciter (férocement) à re-router du trafic là bas, mettre en valeur les serveurs alternatifs et admettre que non, on ne peut pas gérer la distribution à tous pour tous nous sur yevaud. - séparer mes objectifs 1) et 2) en deux serveurs/services distincts car je ne crois pas que l'on puisse couvrir 1) et 2) avec les mêmes configs Je crois aussi 2) passerais sur le CDN, dont le serveur de génération principal ne serait pas chez les anglais = règlement de la question de BP, de charge et presque de failure, d'un coup 1) resterait sur yevaud Librement -- Christophe Merlet (RedFox) signature.asc Description: This is a digitally signed message part ___ dev-fr mailing list dev-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev-fr
Re: [OSM-dev-fr] [OSM-talk-fr] Tr : [OSM-talk] New OpenStreetMap tile server
Le mercredi 19 décembre 2012 à 16:52 +0100, Christophe Merlet a écrit : Le mercredi 19 décembre 2012 à 14:40 +0100, sly (sylvain letuffe) a écrit : Yevaud est le générateur de tuiles. Il est effectivement tout seul pour effectuer cette tache. Par contre il ne fait pas partie du réseau GeoDNS, c'est Orm qui distribue la majorité des tuiles à la planète. Cependant, Yevaud est le cache_peer des Squid du GeoDNS. Du moins c'est ce qu'indique la doc. A cet instant dig donne d'autres résultat... Non, en fait dig confirme, j'ai juste fait une typo sur le domaine et tombé sur un cyber squatteur :/ Librement, -- Christophe Merlet (RedFox) signature.asc Description: This is a digitally signed message part ___ dev-fr mailing list dev-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev-fr
Re: [OSM-dev-fr] [OSM-talk-fr] Tr : [OSM-talk] New OpenStreetMap tile server
Le mercredi 19 décembre 2012 à 21:10 +0100, Jocelyn Jaubert a écrit : On Wed, Dec 19, 2012 at 07:56:56PM +0100, sly (sylvain letuffe) wrote: De prim abord, je pense que la puissance nécessaire à faire un rendu sur la terre, bien que pas vraiment possible avec mon smartphone, n'est pas non plus impossible. Je prouverais (dès que cquest c'est occupé de ma VM au lieu de jouer avec des kernels :-p ) , que c'est possible avec les serveurs que la fondation free a eu le bon goût de nous fournir. Yep, je suis d'accord que c'est la bonne solution à investiguer pour le moment. Avec un peu de chance, les machines de Free seront assez puissantes pour faire du rendu rapide en temps réel. J'ai déjà communiqué ce lien et fait une explication de texte autour http://tile.paulla.asso.fr/osm-fr/renderd_sorted.log Ce sont des stats de rendu de tuiles du zoom 0 à 15... On est loin du temps réel pour un paquet de tuiles... Manque de chance ce sont les plus denses et curieusement, les plus sollicités Librement, -- Christophe Merlet (RedFox) signature.asc Description: This is a digitally signed message part ___ dev-fr mailing list dev-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev-fr
Re: [OSM-dev-fr] [OSM-talk-fr] Tr : [OSM-talk] New OpenStreetMap tile server
Le mercredi 19 décembre 2012 à 21:28 +0100, Philippe Verdy a écrit : Le 19 décembre 2012 21:21, Christophe Merlet red...@redfoxcenter.org a écrit : Ce sont des stats de rendu de tuiles du zoom 0 à 15... On est loin du temps réel pour un paquet de tuiles... Manque de chance ce sont les plus denses et curieusement, les plus sollicités Et c'est justement pour ces tuiles (en fait niveau 0 à 12, voire un peu moins) qu'il est payant de mettre en place des proxy-caches. Au delà les caches n'ont plus beaucoup d'intérêt car les tuiles mises en cache serviront presque tout le temps à un seul client qui ne les demandera le plus souvent qu'une seule fois, sauf intérêt particulier soulevé par une discussion publique. Pour les niveaux plus élevés, les données sont beaucoup plus petites mais il y a beaucoup plus de tuiles et s'il y a du monde, le travail pour récupérer les données de la base sera presque aussi important que pour mettre à jours les tuiles des premiers niveaux. Mais il peut se faire sans cache de tuiles (juste un cache pour les données) à la demande, même si le temps de réponse est un peu plus long (au pire on définit une date de péremption plus précoce de ces tuiles pour pouvoir les purger plus vite du cache que les tuiles des premiers niveaux. Je te propose de me faire un script d'analyse des logs de Squid capable de m'afficher la fréquentation de chaque tuile avec un style mapnik... bref, une sorte de hotmap just do it ! Librement, -- Christophe Merlet (RedFox) signature.asc Description: This is a digitally signed message part ___ dev-fr mailing list dev-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev-fr
Re: [OSM-dev-fr] [OSM-talk-fr] Tr : [OSM-talk] New OpenStreetMap tile server
Le mercredi 19 décembre 2012 à 22:03 +0100, Philippe Verdy a écrit : Le 19 décembre 2012 21:46, Christophe Merlet red...@redfoxcenter.org a écrit : Je te propose de me faire un script d'analyse des logs de Squid capable de m'afficher la fréquentation de chaque tuile avec un style mapnik... bref, une sorte de hotmap Je n'ai pas la bande passante et la connectivité pour faire tourner un serveur Squid à l'échelle de ce qu'on cherche. tu fais juste le script, je le ferais tourner sur les vrais logs Et je n'ai pas accès non plus à ce genre de logs (qui sont des données privatives pour l'essentiel, donc non publiées). Les logs squid sont standardisés, comme les logs apache. Je peux te montrer une dizaine de ligne si tu veux Ensuite pas les ressources (en bande passante, même si j'ai ce qu'il faut en matériel) pour monter un serveur de tuiles (sauf pour un usage par une ou deux personnes). Je fait tourner un mapnik sur mon netbook avec l'aquitaine. c'est bien suffisant pour développer et tester J'ai bien de l'hébergement dispo mais pas avec les capacités nécessaires (c'est juste du PHP/MySQL de base pour la partie libre que je peux utiliser, sinon le reste n'est pas pour ça et pas réellement à ma disposition, mais pas de quoi y mettre une appli comme Mapnik ni même une base pgSQL), même si pour ça je pourrais utiliser un des serveurs de projets de rendus de cartes libres, offrant une base pqDSL déjà chargée et requêtable. Pourquoi de l'hébergement, ça tourne en local. Pour ce genre d'appli de toute façon ce n'est pas une appli du genre Mapnik qu'il faut puisqu'il suffirait seulement de servir des tuiles monochromes semi-transparentes, uniquement en protocole WMS sans rien tracer d'autre : une tuile plus ou moins transparente ou avec une transparence unique de 50%, 100% de luminosité, 100% de saturation et en variant la couleur pour former un dégradé de couleurs en HSV : pour chaque tuiles WMS de Mapnik on génère une tuile de même taille et de même coordonnées monochrome (on peut mettre dans cette tuile uniquement une tâche colorée centrale surface variable, le tour étant totalement transparent). Just do it. Fais ce que tu maitrises le mieux ! Bref aucun calcul de géométrie à faire, ni aucun besoin d'une base SQL carto, puisque alors on a juste à compter les tuiles numérotées dans un rectangle tout autour dans un même niveau de zoom et faire une moyenne horaire pour déterminer la couleur de la tuile à retourner (ces tuiles pouvant être des images précalculées, 100 images dans un même dossier suffiront, ces images étant microscopiques en taille). Tu maitrises plus que moi. Je te fais confiance. Je ne peux pas t'en dire plus puisque je n'ai pas les logs pour le faire. Voilà, voilà. cadeau. 1355960480.687 0 93.31.155.175 TCP_MEM_HIT/200 18093 GET http://tile.openstreetmap.org/6/30/20.png - NONE/- image/png 1355960480.688 0 93.31.155.175 TCP_MEM_HIT/200 553 GET http://tile.openstreetmap.org/6/29/21.png - NONE/- image/png 1355960480.688 0 93.31.155.175 TCP_MEM_HIT/200 553 GET http://tile.openstreetmap.org/6/29/22.png - NONE/- image/png 1355960480.689 0 93.31.155.175 TCP_MEM_HIT/200 553 GET http://tile.openstreetmap.org/6/29/20.png - NONE/- image/png 1355960480.722 0 93.31.155.175 TCP_MEM_HIT/200 553 GET http://tile.openstreetmap.org/6/29/23.png - NONE/- image/png 1355960481.279 1 93.31.155.175 TCP_MEM_HIT/200 30854 GET http://tile.openstreetmap.org/8/127/89.png - NONE/- image/png 1355960481.318 40 93.31.155.175 TCP_MEM_HIT/200 38644 GET http://tile.openstreetmap.org/8/128/89.png - NONE/- image/png 1355960481.320 0 93.31.155.175 TCP_MEM_HIT/200 33078 GET http://tile.openstreetmap.org/8/128/88.png - NONE/- image/png 1355960481.320 42 93.31.155.175 TCP_MEM_HIT/200 40511 GET http://tile.openstreetmap.org/8/129/89.png - NONE/- image/png 1355960481.326 2 93.31.155.175 TCP_MEM_HIT/200 24197 GET http://tile.openstreetmap.org/8/126/88.png - NONE/- image/png 1355960481.326 2 93.31.155.175 TCP_MEM_HIT/200 30844 GET http://tile.openstreetmap.org/8/127/88.png - NONE/- image/png 1355960481.326 2 93.31.155.175 TCP_MEM_HIT/200 29727 GET http://tile.openstreetmap.org/8/126/89.png - NONE/- image/png 1355960481.326 2 93.31.155.175 TCP_MEM_HIT/200 34569 GET http://tile.openstreetmap.org/8/130/88.png - NONE/- image/png 1355960481.367 42 93.31.155.175 TCP_MEM_HIT/200 35350 GET http://tile.openstreetmap.org/8/129/88.png - NONE/- image/png 1355960481.370 44 93.31.155.175 TCP_MEM_HIT/200 39964 GET http://tile.openstreetmap.org/8/130/89.png - NONE/- image/png 1355960482.009 5 93.31.155.175 TCP_MEM_HIT/200 43957 GET http://tile.openstreetmap.org/10/515/364.png - NONE/- image/png 1355960482.009 5 93.31.155.175 TCP_MEM_HIT/200 34837 GET http://tile.openstreetmap.org/10/514/364.png - NONE/- image/png 1355960482.011 6 93.31.155.175 TCP_HIT/200
[OSM-dev] Map rendering issue
Hi I have the same bug as you can see. http://tile.paulla.asso.fr/slippymap.html Ubuntu 12.04 LTS + Kai krueger paquets Import planet-120508.osm.pbf + minute diff Bug in the planet or in the setup ? I lost my hair :( Librement, -- Christophe Merlet (RedFox) ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
[OSM-dev] Map rendering issue
Hi I have the same bug as you can see. http://tile.paulla.asso.fr/slippymap.html Ubuntu 12.04 LTS + Kai krueger paquets Import planet-120508.osm.pbf + minute diff Bug in the planet or in the setup ? I lost my hair :( Librement, -- Christophe Merlet (RedFox) ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Map rendering issue
Le mercredi 13 juin 2012 à 15:56 -0500, Ian Dees a écrit : On Wed, Jun 13, 2012 at 3:46 PM, Lynn W. Deffenbaugh (Mr) ldeff...@homeside.to wrote: Without changing zoom, drag over and down South America. Watch it go white (gray). Then move on over to the blank face of Australia. That's the bug. It looks like you included a bounding box for your initial import, preventing data above 76.6deg and below -35deg latitude from being imported to your database. It look like... but it's not the case ! I you look a little closer to the map, you can see it's a little more complicated than that. My import command. $ time osm2pgsql -H lurien -W -d mapnik_new --tablespace-main-data data --tablespace-main-index index --tablespace-slim-data data --tablespace-slim-index index -p planet_osm -s -C 16000 --hstore-all planet-120508.osm.pbf Librement, -- Christophe Merlet (RedFox) ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Map rendering issue
Le mercredi 13 juin 2012 à 22:22 +0100, Jon Burgess a écrit : On Wed, 2012-06-13 at 16:46 -0400, Lynn W. Deffenbaugh (Mr) wrote: Without changing zoom, drag over and down South America. Watch it go white (gray). Then move on over to the blank face of Australia. That's the bug. The key question is whether the data is in the database or not. Can you run a query like the one below which should return a single node for an aerodrome near the southern tip of South America: http://www.openstreetmap.org/?node=1042020307 gis= select osm_id,name,aeroway,astext(st_transform(way,4326)) from planet_osm_point where osm_id=1042020307; osm_id |name| aeroway | astext ++---+ 1042020307 | Los Cerros Airport | aerodrome | POINT(-67.8329009905576 -54.3441009947259) (1 row) Jon Thanks for your help. Here the result : ubuntu@lurien:~$ psql -d mapnik_cc -h lurien -U mapnik Password for user mapnik: psql (9.1.4) SSL connection (cipher: DHE-RSA-AES256-SHA, bits: 256) Type help for help. mapnik_cc= select osm_id,name,aeroway,astext(st_transform(way,4326)) from planet_osm_point where osm_id=1042020307; osm_id |name| aeroway | astext ++---+ 1042020307 | Los Cerros Airport | aerodrome | POINT(-67.8329009905576 -54.3441009947259) (1 row) mapnik_cc= Librement, -- Christophe Merlet (RedFox) ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Map rendering issue
Le mercredi 13 juin 2012 à 23:31 +0200, Christophe Merlet a écrit : Le mercredi 13 juin 2012 à 22:22 +0100, Jon Burgess a écrit : OK, good, so that data has imported OK. The last time I saw something like this on the rendering side it was due to using the 'estimated extent' feature of postgis. Can you tell us what extent setting you have in your datasource file, e.g: [jburgess at shark mapnik]$ grep extent inc/datasource-settings.xml.inc Parameter name=estimate_extentfalse/Parameter Parameter name=extent-20037508,-19929239,20037508,19929239/Parameter There are a few items on the rendering side which may be relevant to this. Can you tell us the version of the items below. Also let us know whether you built from source or used a package from somewhere: - postgis - mapnik - mod_tile - the 'map style' (osm.xml etc) I use Ubuntu 12.04 and packages from Kai Krueger https://launchpad.net/~kakrueger/+archive/openstreetmap # cat datasource-settings.xml.inc !-- Settings for your postgres setup. Note: feel free to leave password, host, port, or use blank -- Parameter name=typepostgis/Parameter Parameter name=password!!!snip!!!/Parameter Parameter name=hostlurien.paulla.asso.fr/Parameter !-- Parameter name=port%(port)s/Parameter -- Parameter name=usermapnik/Parameter Parameter name=dbnamemapnik_cc/Parameter !-- this should be 'false' if you are manually providing the 'extent' -- Parameter name=estimate_extenttrue/Parameter !-- manually provided extent in epsg 900913 for whole globe -- !-- providing this speeds up Mapnik database queries -- !-- Parameter name=extent%(extent)s/Parameter -- I'll try your settings... Librement, -- Christophe Merlet (RedFox) ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Map rendering issue
Le jeudi 14 juin 2012 à 00:18 +0200, Christophe Merlet a écrit : Le mercredi 13 juin 2012 à 23:31 +0200, Christophe Merlet a écrit : Le mercredi 13 juin 2012 à 22:22 +0100, Jon Burgess a écrit : OK, good, so that data has imported OK. The last time I saw something like this on the rendering side it was due to using the 'estimated extent' feature of postgis. Can you tell us what extent setting you have in your datasource file, e.g: [jburgess at shark mapnik]$ grep extent inc/datasource-settings.xml.inc Parameter name=estimate_extentfalse/Parameter Parameter name=extent-20037508,-19929239,20037508,19929239/Parameter There are a few items on the rendering side which may be relevant to this. Can you tell us the version of the items below. Also let us know whether you built from source or used a package from somewhere: - postgis - mapnik - mod_tile - the 'map style' (osm.xml etc) I use Ubuntu 12.04 and packages from Kai Krueger https://launchpad.net/~kakrueger/+archive/openstreetmap # cat datasource-settings.xml.inc !-- Settings for your postgres setup. Note: feel free to leave password, host, port, or use blank -- Parameter name=typepostgis/Parameter Parameter name=password!!!snip!!!/Parameter Parameter name=hostlurien.paulla.asso.fr/Parameter !-- Parameter name=port%(port)s/Parameter -- Parameter name=usermapnik/Parameter Parameter name=dbnamemapnik_cc/Parameter !-- this should be 'false' if you are manually providing the 'extent' -- Parameter name=estimate_extenttrue/Parameter !-- manually provided extent in epsg 900913 for whole globe -- !-- providing this speeds up Mapnik database queries -- !-- Parameter name=extent%(extent)s/Parameter -- I'll try your settings... Seems to work. I'll regenerate tiles to be sure... Many thanks for your help. Librement, -- Christophe Merlet (RedFox) ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
