Re: [OSM-talk-fr] Limites administratives, le modèle "pyramidal", un échec ?
> Le problème des autres outils qui > fonctionnent en flux (ala osm2pgsql), > c'est que cette modélisation > implique un double passage sur les relations au minimum ou un stockage > séparé des relations-segments. Je ne sais pas trop où tu veux en venir, mais si c'est pour préciser que l'algorithme de traitement entre une relation construite en pyramide de relation et celle sans ne sera pas le même, en effet, il n'y a pas de doute. Mais osm2pgsql, tel qu'existant aujourd'hui, pour construire des géométries à partir de fichiers .osm et .pbf ne fonctionne pas en flux dans le sens "être capable de construire toutes les géométries en une lecture continue du fichier de donnée sans stockage" ogr2ogr qui dispose aussi d'un drivers de lecture des fichiers .osm et .pbf passe, lui aussi par un stockage temporaire. Enfin bref, avec ou sans modèle pyramide, que ça soit dans 400Go de RAM si on les as (osm2pgsql sans le --slim), une base sur disque (mode --slim) ou base sqlite temporaire (ogr2ogr) il faut de toute façon un algo avec stockage temporaire pour passer des données osm monde à des géométries (way, relation, ou pyramides de relations). Et si ce sur quoi tu t'interroges à la fin c'est la vitesse de construction des géométries avec chaque modèles sur un ordinateur qui existe, bien que ça dépende de la manière de faire l'algo, je pense que de deux algo bien réalisés, celui qui traite la pyramide sera le plus rapide car il y a factorisation du stockage sur disque d'une relation de frontière et sa construction (car ré-utilisée par les deux polygones qui se touchent) Mais je pense que ces considérations sont vraiment secondaires, laissons aux développeurs ces questions et posons nous plutôt la question du temps passé par le contributeur, sa difficulté à comprendre la construction, et les possibilités offerte pour maintenir des relations géantes avec les deux modèles. -- sly (sylvain letuffe) pour me contacter / to contact me : sylvain(A)letuffe(.)org -- View this message in context: http://gis.19327.n5.nabble.com/Re-Limites-administratives-le-modele-pyramidal-un-echec-tp5779415.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Limites administratives, le modèle "pyramidal", un échec ?
2013/9/29 sylvain letuffe : > http://osm102.openstreetmap.fr/~jocelyn/polygons/index.py > https://github.com/jocelynj/osm/blob/master/tools/mega-relation-analyser.py A noter que ces outils fonctionnent avec un identifiant en entrée, ce qui rend la chose facile. Le problème des autres outils qui fonctionnent en flux (ala osm2pgsql), c'est que cette modélisation implique un double passage sur les relations au minimum ou un stockage séparé des relations-segments. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Limites administratives, le modèle "pyramidal", un échec ?
hello aux manieurs de balais (que je soutiens presque toujours) ! Pieren wrote > L'idée remonte à début 2010 et 3 ans plus-tard, il n'y a toujours > aucun logiciel qui s'en sert. Il faut parfois admettre que même les > bonnnes idées peuvent ne pas être suivies d'effets. L'outil développé par jocelyn accessible ici : http://osm102.openstreetmap.fr/~jocelyn/polygons/index.py permet depuis plus d'un an d'exporter tout type de relation représentant un polygone que celle-ci utilise (ou pas) une construction pyramidale. On s'en sert pour construire le polygone "France" (avec dom/tom) et l'utiliser ensuite avec postresql et faire des requêtes limitées à la france. Pour vérifier ce type de relation pyramidale, on dispose aussi de : https://github.com/jocelynj/osm/blob/master/tools/mega-relation-analyser.py un autre, plus performant et accessible en ligne dont j'ai paumé l'adresse et osmose (il me semble) l'utilise dans un de ces tests. Pieren wrote > et nous distingue encore une fois de tous nos voisins du monde Il est vrai que très peu de relation sont construites sur ce modèle mais on trouve : l'allemagne : http://www.openstreetmap.org/browse/relation/111 et l'ensemble des pays à majorité germanophone : http://www.openstreetmap.org/browse/relation/2463632 en plus des deux nôtres, c'est quand même pas nouveau que France et Allemagne soit le moteur de l'europe non ? ;-) On peut même découvrir les prémisses d'une éventuelle future intégration possible des mers dans osm : http://www.openstreetmap.org/browse/relation/1628011 Beaucoup en rêve, personne ne sait comment faire, mais il me semble que ça vaut le coup de continuer à laisser sa chance à ce modèle (c'est à dire sans l'éradiquer trop vite) car je ne vois pas le modèle actuel relation<-ways résoudre le cas des mers/océans. Pieren wrote > Des opinions ? Oui, lui laisser encore du temps. La contre-indication d'avoir un way de frontière qui appartient à une relation de plus qu'est la frontière entre deux pays ne me semble pas suffisamment pénible (quand on sait qu'un way admin_level=8 de frontière franco/italienne est membre de 12 relations : http://www.openstreetmap.org/browse/way/202492188 ) 1 de plus me semble tolérable compte tenu de l'espoir que cela porte à la simplification autant qu'a l'expansion à des relation de plus grosse tailles (mers/océans/continents/ensemble économique comme l'UE) A noter qu'une telle discussion pourrait sans doute être portée sur tagging, certains de nos voisins ayant semblent-il eux aussi des idées concernant l'utilisation de ce modèle. -- sly -- View this message in context: http://gis.19327.n5.nabble.com/Limites-administratives-le-modele-pyramidal-un-echec-tp5778241p5779397.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Limites administratives, le modèle "pyramidal", un échec ?
2013/9/21 Vincent de Château-Thierry : > http://www.openstreetmap.org/browse/relation/1362232 , non ? vi et remettre la 11980 en ordre Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Limites administratives, le modèle "pyramidal", un échec ?
Le 20/09/2013 17:13, Pieren a écrit : 2013/9/20 V de Chateau-Thierry : J'aurais peut-être dû insister sur le fait que le concept fait "doublon" avec l'ancien modèle. Et, oui, quand on bouge un noeud ou qu'on en rajoute un sur une frontière ou ligne de côte, cela ne change pas grand chose. On ne le remarque que lorsque la relation elle-même est affectée (en gros, si des ways sont ajoutés ou supprimés suite, par exemple, à des fusions ou des scissions). Mon soucis, c'est la clareté. Et la difficulté à expliquer aux nouveaux arrivants que, ben oui, on a deux relations pour la France dont l'une ne sert à rien depuis 3 ans et demi mais qu'elle présente un concept si intéressant que personne d'autre n'a jugé bon de l'adopter. J'ai toujours été pour les expérimentations mais à un moment, il faut aussi savoir arrêter les fraits. J'ai chargé la relation 1403916 et elle est des plus classiques : des ways membres, sans relation intermédiaire type multilinestring. Celle que tu veux supprimer, ce serait plutôt celle-ci : http://www.openstreetmap.org/browse/relation/1362232 , non ? vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Limites administratives, le modèle "pyramidal", un échec ?
Oups... clarté et frais... ;-þ Le 20 septembre 2013 17:13, Pieren a écrit : > Mon soucis, c'est la clareté. Et la difficulté à expliquer aux > nouveaux arrivants que, ben oui, on a deux relations pour la France > dont l'une ne sert à rien depuis 3 ans et demi mais qu'elle présente > un concept si intéressant que personne d'autre n'a jugé bon de > l'adopter. J'ai toujours été pour les expérimentations mais à un > moment, il faut aussi savoir arrêter les fraits. > ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Limites administratives, le modèle "pyramidal", un échec ?
2013/9/20 V de Chateau-Thierry : J'aurais peut-être dû insister sur le fait que le concept fait "doublon" avec l'ancien modèle. Et, oui, quand on bouge un noeud ou qu'on en rajoute un sur une frontière ou ligne de côte, cela ne change pas grand chose. On ne le remarque que lorsque la relation elle-même est affectée (en gros, si des ways sont ajoutés ou supprimés suite, par exemple, à des fusions ou des scissions). Mon soucis, c'est la clareté. Et la difficulté à expliquer aux nouveaux arrivants que, ben oui, on a deux relations pour la France dont l'une ne sert à rien depuis 3 ans et demi mais qu'elle présente un concept si intéressant que personne d'autre n'a jugé bon de l'adopter. J'ai toujours été pour les expérimentations mais à un moment, il faut aussi savoir arrêter les fraits. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Limites administratives, le modèle "pyramidal", un échec ?
Le 20 septembre 2013 15:55, Pieren a écrit : > Bonjour, > > En examinant le "b...l", pardon, le chaos actuel dans les limites > administratives, je me suis demandé s'il était encore pertinent de > conserver 2 relations pour les limites de la France, une avec l'ancien > modèle, et une avec les segments/multilinestring. > L'idée remonte à début 2010 et 3 ans plus-tard, il n'y a toujours > aucun logiciel qui s'en sert. En es-tu réellement sûr? Dans ce cas ces loficiels ne seraient pas du tout capable de traiter les multilinestring et la France n'existerait pas du tout. Il faut peut-être rappeler la raison des multilinestrings : au delà d'une certaine limite, il devient très compliqué de modifier une liste énorme de chemins dans une relation, et les éditeurs ne parviennent me^me plus à charger l'objet (particulièrement les éditeurs en ligne, avec du Javascript et dans un navigateur 32 bits où la mémoire d'un onglet de navigation sature autour de 256Mo avant de commencer à "swapper" énormément ou de tout bonnement se bloquer et refuser de grossir; Et avec les éditeurs écrits en Flash c'est encore plus flagrant). Pour ça on avait donné une estimation de ce qu'une relation raisonnable ne devrait pas dépasser, de l'ordre de 200 membres, même si certaines relations en ont plus (par exemple les relations de régions littorales avec une grande quantité d'îles et îlots ; on sait le problème que ça pose en Bretagne et d'autre régions comparables ailleurs qu'en France comme la Galice, ou plus loin de nous au Canada, en Indonésie, et dans toute la zone pacifique de Polynésie et Mélanésie, où le problème est un peu simplifié en ne créant pas les frontières de base, mais celles des frontières territoriales à 12 nm en s'affranchissant de la complexité des lignes de côtes utilisées plus ou moins comme lignes de base). Oui certains peuvent utiliser un plus gros PC avec plus de 4Go de RAM, un CPU multicoeur rapide, un OS 64 bits et un navigateur ou un éditeur 64 bits mais la tendance est plutôt vers les solutions mobiles plus légères (et moins gourmandes en énergie). En revacnehe du côté des serveurs (y compris les serveurs de rendu) on n'a pas de telles limitations et ils peuvent tout charger et n'ont pas grand peine à charger récursivement des multilinestrings ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Limites administratives, le modèle "pyramidal", un échec ?
Bonjour, > De : "Pieren" > > En examinant le "b...l", pardon, le chaos actuel dans les limites > administratives, je me suis demandé s'il était encore pertinent de > conserver 2 relations pour les limites de la France, une avec l'ancien > modèle, et une avec les segments/multilinestring. > L'idée remonte à début 2010 et 3 ans plus-tard, il n'y a toujours > aucun logiciel qui s'en sert. Il faut parfois admettre que même les > bonnnes idées peuvent ne pas être suivies d'effets. > Comme cela alourdie inutilement les éditions (et nous distingue encore > une fois de tous nos voisins du monde), je propose de ne conserver que > l'ancien modèle, en le remettant dans la relation d'origine pour les > frontières terrestres (la 11980) et supprimer la relation 1403916 qui > ferrait alors doublon ainsi que toutes les relations multilinestring > afférantes. > Des opinions ? Sur le principe, j'ai toujours un souci avec une justification comme : "personne ne s'en sert, alors on peut supprimer l'objet xxx". Il est facile de tester osm2pgsql ou imposm pour constater comment ils digèrent (ou pas) ces relations. Mais même si eux ne savent pas s'en dépatouiller, pour moi ça ne permet pas de dire "personne ne s'en sert". C'était une remarque générale car ce type d'argument revient parfois. Quant à la lourdeur d'édition, j'ai aussi du mal avec cet argument concernant les limites admins. Comme d'autres, je répare régulièrement ce contenu (sur la France) et je n'ai jamais eu à récupérer entièrement des entités de type région ou pays pour les remettre d'aplomb. Un site comme http://layers.openstreetmap.fr/ permet de grosses économies de chargement, en permettant de cerner où sont les cassures. Pour revenir au cas présent, ça ne me dérange pas qu'on supprime cette relation si, plutôt que de dire "il n'y a toujours aucun logiciel qui s'en sert", on constate qu'elle est cassée depuis une éternité, et donc non maintenue. Ça me semble un meilleur signe de non-utilisation que l'état des techniques de nous connues qui permettraient de l'exploiter. (Reste à définir l'éternité... ) vincent Une messagerie gratuite, garantie à vie et des services en plus, ça vous tente ? Je crée ma boîte mail www.laposte.net ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Limites administratives, le modèle "pyramidal", un échec ?
Bonjour, En examinant le "b...l", pardon, le chaos actuel dans les limites administratives, je me suis demandé s'il était encore pertinent de conserver 2 relations pour les limites de la France, une avec l'ancien modèle, et une avec les segments/multilinestring. L'idée remonte à début 2010 et 3 ans plus-tard, il n'y a toujours aucun logiciel qui s'en sert. Il faut parfois admettre que même les bonnnes idées peuvent ne pas être suivies d'effets. Comme cela alourdie inutilement les éditions (et nous distingue encore une fois de tous nos voisins du monde), je propose de ne conserver que l'ancien modèle, en le remettant dans la relation d'origine pour les frontières terrestres (la 11980) et supprimer la relation 1403916 qui ferrait alors doublon ainsi que toutes les relations multilinestring afférantes. Des opinions ? Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
