Re: [OSM-dev-fr] glonflement des tables osm2pgsql...
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) Le 12 août 2014 17:11, Christian Quest cqu...@openstreetmap.fr a écrit : A voir pourquoi ça a été codé comme ça dans osm2pgsql... il y a peut être une bonne raison. Celle que je vois est liée à l'absence de commande REPLACE comme on la trouve dans MySQL. Du coup, il faudrait différencier les créations des mises à jour, ce qui aurait un effet de bord important si on rejoue des diffs dans le désordre ou alors compliquer sérieusement chaque UPDATE pour le doubler par un INSERT en cas d'échec, mais ça peut valoir le coup. Pour le fillfactor, Philippe a grosso-modo couvert le sujet. Dans le cas des données OSM, on a une part de mise à jour somme toute faible par rapport au volume global de la base et surtout pas mal d'ajouts. On peut rester sur des fillfactor élevés pour données et index qui ont un impact potentiellement négatif sur les mises à jour, mais très positif sur les lectures. Pour une base osm2pgsql servant à générer beaucoup de tuiles, les lectures sont très majoritaires. L'autre aspect important est qu'en ayant des pages très remplies (fillfactor élevé), on en a moins globalement et donc à quantité de RAM égale on peut avoir une proportion plus importante de données en cache... toujours plus rapide que des IO sur un SSD et à fortiori des IO sur HDD ! Le 12 août 2014 13:47, Francescu GAROBY f.gar...@gmail.com a écrit : Et ça ne vaudrait pas le coup de modifier la fonction pgsql_modify_node que tu pointes pour lui faire faire un UPDATE, plutôt qu'un INSERT/DELETE ? La modification ne me paraît pas compliquée et si ça peut faciliter votre histoire de fillfactor (j'avoue ne pas comprendre de quoi il s'agit)... Francescu Le 12 août 2014 12:47, Christian Quest cqu...@openstreetmap.fr a écrit : Par défaut le fillfactor sur les data est de 100%, d'où l'idée de le baisser un peu... mais l'efficacité dépendra aussi de comment osm2pgsql met à jour les données et vu le code ça semble malheureusement se faire à coup de DELETE/INSERT et pas d'UPDATE... https://github.com/openstreetmap/osm2pgsql/blob/master/output-pgsql.c#L1432 Je ne suis pas sûr dans ces conditions que ça serve à grand chose. Le 12 août 2014 11:37, Christophe Merlet red...@redfoxcenter.org a écrit : Le 12/08/2014 10:10, Christian Quest a écrit : Vu qu'on a 2 bases osm2pgsql monde à la structure identique sur les serveurs tile et layers, j'ai comparé l'espace occupé par les tables car celui-ci est compté actuellement sur nos SSD de 480 (tile) et 512Go (layers). Il y a des différentes plus ou moins importantes. La plus étonnante concerne planet_osm_line qui pour les seules data fait 55Go sur tile et 39Go sur layers, soit une différence de 40%. Je m'explique difficilement ces différences. Je viens de recopier la table (CREATE TABLE line as SELECT * FROM planet_osm_line) et j'ai une table de 35Go. Il y a donc des trous dans les data ou alors c'est un auto-vacuum en cours qui provoque ce gonflement alors que je pensais qu'il prenait des données en fin de fichier pour les remettre dans les trous. Des idées de votre côté ? L'auto vacuum est extrêmement limité. Il ne fait qu'indiquer les espaces réutilisables sans forcer leur réutilisation. C'est le VACUUM FULL qui permet de regagné l'espace disque. Mais pour se faire il faut au moins avoir l'équivalent de la plus grosse table en espace disponible et verrouiller les tables en cours de traitement. Par ailleurs regagner l'espace disque n'est pas forcément une bonne idée, car, si je ne m'abuse, pgsql essaye d'insérer les données au bon endroit. S'il y a des trous dans la base au bon endroit à cause d'une suppression précédente, c'est gagné, sinon il met là ou il peut. Ce sont les stats qui indique la meilleur stratégie. D'ailleurs, suivant l'espace disque disponible, il peut être judicieux de diminuer le fillfactor. ça laisse volontairement des trous dans la base pour insérer les nouvelles données Librement, -- Christophe Merlet (RedFox) ___ dev-fr mailing list dev-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev-fr -- Christian Quest - OpenStreetMap France ___ dev-fr mailing list 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 -- Christian Quest - OpenStreetMap
Re: [OSM-dev-fr] Simplifier nos limites admin...
Je en comprends pas tout à ce que fait cette requête, mais pourquoi tu as p2.osm_id ** p.osm_id dans ta clause ON ? Ca ne devrait pas être p2.osm_id *=* p.osm_id, plutôt ? Francescu Le 11 décembre 2013 16:58, Christian Quest cqu...@openstreetmap.fr a écrit : Les limites admins sont super définies mais pour des usages à petite ou moyenne échelle ça fait quelques chose de trop défini et trop volumineux à traiter. Qui peut le plus peut le moins ! J'ai commencé à m'attaquer à ça pour produire des version plus légères de nos limites admins. Pour l'instant, je joue avec ST_Touches pour sélectionner les polygones limitrophes, puis ST_Intersection, ST_LineMerge et ST_Simplify pour obtenir un linestring simplifié par frontière entre 2 communes. Ca semble ok sauf que j'ai des manques. voici la tête de la requête si quelqu'un a une idée: SELECT ST_Simplify(ST_LineMerge (st_intersection(p.way,p2.way)),10) as limite, concat(p.name ,' - ', p2.name) as nom from planet_osm_polygon p join planet_osm_polygon p2 on (st_touches(p.way,p2.way) and p2.ref:INSEE is not null and p2.admin_level='8' and p2.boundary='administrative' and p2.osm_idp.osm_id) where p.way !bbox! and p.ref:INSEE is not null and p.admin_level='8' and p.boundary='administrative'; -- 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 ___ dev-fr mailing list dev-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev-fr
Re: [OSM-dev-fr] fichiers garmin routables
Octobre ? Il doit peut-être manquer aussi la fermeture du Pont-Mathilde, à Rouen, en date du 29 octobre. Francescu Le 14 février 2013 11:34, Sylvain Maillard sylvain.maill...@gmail.com a écrit : Salut, qui s'occupe de la mise à jour des fichiers garmin ? il y a bien lann qui fait des mises à jour régulières, mais il ne s'agit que du fond de carte, les fichiers routables datent eux du mois d'octobre ... Avec la fermeture du tunnel de croix-rousse au mois d'octobre et l'ouverture de l'A89 en janvier, ça fait de gros changements en région lyonnaise qui ne sont pas dans les fichiers pour GPS ... Sur IRC, on me souffle que ça serait le contributeur FredB (en copie) qui s'en charge, est-ce toujours le cas, et est-ce qu'il ne serait pas possible de migrer/automatiser ça sur un des nouveaux serveur de l'asso ? Sinon je peux proposer de mettre ça sur mon serveur perso à la maison, avec transfert régulier des fichiers ... Sylvain ___ dev-fr mailing list dev-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev-fr ___ dev-fr mailing list dev-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev-fr
Re: [OSM-dev-fr] Nouvelle interface web sur beta.osmose.openstreetmap.fr
À l'instant où je vous parle, le site semble inaccessible... Francescu Le 1 décembre 2012 19:20, Ista Pouss ista...@gmail.com a écrit : Je viens de faire un essai basique, et j'ai l'impression que ça marche mille fois mieux ! Une problème, sinon à quoi ça servirait que je fasse un test : si je fais page suivante page précédente, je reviens pas dans la même config : je reviens à la France, même si j'avais zoomé sur Paris. Pas bien. Le 1 décembre 2012 18:13, Jocelyn Jaubert jocelyn.jaub...@gmail.com a écrit : Bonjour, Le site web d'Osmose a changé de framework, en passant à bottle [http://bottlepy.org], un framework simple en Python. Ça a impliqué de gros changements dans le code, réalisé pour la grande majorité par Frédéric. Du coup, je voudrais qu'un maximum de gens teste l'url suivante, afin en particulier de comparer avec les perfs du site officiel (les deux sites sont hébergés sur la même machine, et utilisent la même base de donnée): http://beta.osmose.openstreetmap.fr/ Même si l'interface reste basiquement la même, un grand nombre d'améliorations ont pu être faites: - les bulles s'affichent tout de suite, et la popup n'est chargé qu'au survol de la souris - une heatmap a été rajouté, qui affiche les erreurs sous forme de tuiles - très utile quand on atteint la limite des 100 marqueurs affichés. Cette heatmap est accessible dans la liste des layers. - un layer Bing photo a été rajoute - raccourcissement de la taille des permalink sur la liste des items - affichage du nombre d'erreur par item/level au survol de la souris sur les bulles dans le menu - un flux RSS par utilisateur, en expérimentation. À noter que ça ne marche toujours pas sur Internet Explorer 9, et je n'ai pas le temps ni les logiciels pour investiguer le problème. Les traductions auraient aussi besoin d'un coup de main, surtout en allemand, néerlandais ou italien, d'après http://beta.osmose.openstreetmap.fr/control/i18n Les fichiers à traduire sont disponibles ici, et il est possible de rajouter d'autres langues: https://gitorious.org/osmose/frontend/trees/dev/po Merci, Jocelyn ___ dev-fr mailing list dev-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev-fr ___ dev-fr mailing list dev-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev-fr ___ dev-fr mailing list dev-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev-fr
Re: [OSM-dev-fr] calcul d'erreurs
Bonjour, Pour la dernière question, la réponse me semble simple : le node fait partie du way si et seulement s'il est déclaré comme un des nodes du way en question, non ? Francescu Le 2 octobre 2012 12:18, didier2020 didier2...@free.fr a écrit : bonjour, but :essayer de corriger les erreurs detectées par osmose (chevauchements et interstice) sur les fichiers cadastre.openstreetmap.fr par projection orthogonale d'un point sur un segment il me manque le filtre. qadastre utilise des float pendant son traitement mais lors de l'écriture les coordonnées ont 6 décimales les coordonnées stockées dans openstreetmap ont 7 décimales cadastre- qadastre - openstreetmap virtuel 0.123456789 - 0.123457 - 0.1234568 0.987654321 - 0.987654 - 0.9876543 question: + les nodes ont une précision de +- ? + la distance entre 2 nodes est a +- ? + quel est la distance maximum entre un node et un way pour que le node fasse parti du way ? merci au mateux didier ___ dev-fr mailing list dev-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev-fr ___ dev-fr mailing list dev-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev-fr
