Re: [OSM-talk-fr] Bâtiment avec un préau
Hello, Es-ce que l'on peut expliquer pourquoi on ne peut pas le faire avec un multipolygone ? CU et merci d'avance Stéphane Pieren [via GIS] a écrit : 2010/7/15 Stéphane Brunner courr...@stephane-brunner.ch Hello, Il faut faire des multipolygone : http://wiki.openstreetmap.org/wiki/Relation:multipolygon Non, non. Il faut juste veiller à ce que les nodes soient partagés. C'est la réponse de Vincent qui est la bonne. Si après ça, le logiciel de contrôle se plaint encore, c'est son problème (en général, on peut ignorer tout ce qui n'est pas signalé comme 'error' par validator). Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr __ View message @ http://gis.638310.n2.nabble.com/Batiment-avec-un-preau-tp5294746p5297018.html To start a new topic under France, email ml-node+3070341-1406367393-41...@n2.nabble.com To unsubscribe from France, click (link removed) == -- Stéphane Brunner Messagerie instantanée (Jabber - XMPP) : stephane.brun...@jabber.fr -- Il existe 10 sortes de personnes : celles qui connaissent le binaire, et les autres. begin:vcard fn;quoted-printable:St=C3=A9phane Brunner n;quoted-printable:Brunner;St=C3=A9phane email;internet:courr...@stephane-brunner.ch x-mozilla-html:FALSE version:2.1 end:vcard -- View this message in context: http://gis.638310.n2.nabble.com/Batiment-avec-un-preau-tp5294746p5300689.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Bâtiment avec un préau
Bonjour Stéphane, De : Stéphane Brunner Es-ce que l'on peut expliquer pourquoi on ne peut pas le faire avec un multipolygone ? De mon point de vue deux raisons : - un type=multipolygon se justifie si l'entité à construire est composée de polygones en archipel (des bâtiments disjoints comme par exemple sur un campus), ou bien des bâtiments troués (un bâtiment qui remplit tout un ilôt mais avec une cour intérieure) ou bien une combinaison de tout cela. On jouera avec les rôles inner, outer, exclave, etc. Dans le cas des bâtiments A et B de la question initiale, on n'est pas dans cette situation, et je ne vois pas quel(s) rôle(s) on pourrait assigner aux ways A et B. Ca me paraît une raison suffisante pour éviter de construire cette relation. - une raison technique existe aussi : deux polygones adjacents (A et B ont un mur en commun) ne forment pas un multipolygon valide au sens de PostGIS (et de l'OGC), ce qui a comme conséquence de produire des résultats incorrects quand on manipule cette donnée en base. J'en ai fait les frais un certain temps quand je ne parvenais pas à sortir un plan Maposmatic de ma commune : j'avais constitué un multypolygon à partir de bâtiments d'une école, dont certains étaient comme A et B. Maposmatic s'attendant à trouver des géométries conformes, je faisais planter le traitement :-( Un peu de littérature sur ce sujet ici : http://www.postgis.org/documentation/manual-1.5/ch04.html#OGC_Validity 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 http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Bâtiment avec un préau
De : Stéphane Brunner A : talk-fr@openstreetmap.org Mais si on sort un peut de ce cadre il me semble que si on a un très grand polygone 2000 nœud c'est tout de même la solution la plus propre. En fait c'est surtout la seule possible compte tenu des limites données par l'API v0.6 : pas plus de 2000 nodes par way. Mais on parle ici de la constitution d'un polygone en tant que tel, pas forcément d'un multipolygon. Généraliser ce fonctionnement rejoindrait la proposition de sly : on ne dessine pas de polygone en tant que tel mais des ways, jamais superposés, qui via une relation constituent des surfaces. Sans forcément atteindre les 2000 nodes, c'est exactement ce qui se fait déjà pour les emprises administratives. Pour des surfaces plus petites et surtout plus simples à gérer, on reste dans un modèle un peu topologique (les noeuds communs sont 1 seul noeud) et un peu spaghetti [1] (les ways sont distincts par polygone, même s'ils sont superposables exactement). Bref on est entre 2 approches, sly plaide pour le tout topologique [2] (si je ne trahis pas ses propos), ça me plaît aussi mais c'est un gros enjeu pour les interfaces de saisie. S'il faut pour former un polygone dessiner un nouveau way à chaque fois qu'un node est visuellement au croisement de 3 ways puis ensuite éditer une relation polygon pour lister les ways, avec l'ergonomie actuelle de JOSM on n'a pas fini... vincent [1] : http://www.gitta.info/DigitModel/fr/html/Topologies_learningObject1.html [2] : http://www.unites.uqam.ca/dgeo/geo7530/stb3.htm 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 http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Bâtiment avec un préau
Le vendredi 16 juillet 2010 10:31:48, Stéphane Brunner a écrit : Hello, Merci Vincent pour ta réponse. Mais si on sort un peut de ce cadre il me semble que si on a un très grand polygone 2000 nœud c'est tout de même la solution la plus propre. J'ai dirais même plus, ça devient obligatoire, l'API telle qu'elle est configurée actuellement n'accepte pas de chemin de plus de 2000 noeuds. -- sly ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Bâtiment avec un préau
Le vendredi 16 juillet 2010 11:13:10 Vincent de Chateau-Thierry, vous avez écrit : Pour des surfaces plus petites et surtout plus simples à gérer, on reste dans un modèle un peu topologique (les noeuds communs sont 1 seul noeud) et un peu spaghetti [1] (les ways sont distincts par polygone, même s'ils sont superposables exactement). Bref on est entre 2 approches, sly plaide pour le tout topologique [2] (si je ne trahis pas ses propos), ça me plaît aussi mais c'est un gros enjeu pour les interfaces de saisie. S'il faut pour former un polygone dessiner un nouveau way à chaque fois qu'un node est visuellement au croisement de 3 ways puis ensuite éditer une relation polygon pour lister les ways, avec l'ergonomie actuelle de JOSM on n'a pas fini... Le concept me paraît vraiment le bon depuis que j'ai commencé à utiliser les relations (limites admin, multipolygon, site, …). Mon avis, est que plus on va ajouter de données, plus on en aura besoin. On le voit sur les highway avec la cohabitation des différentes routes sur un même way. Bref, dès qu'un même polygone a potentiellement plusieurs usages, même partiellement relativement à sa surface on son linéaire (overlap), on va devoir introduire des relations. Il est clair qu'il va falloir faire évoluer les outils, car déjà aujourd'hui c'est assez compliqué … Je dis ça, je ne suis pas géographe et n'ai pas connaissance des autres solutions SIG pour comparer … -- Nicolas Dumoulin http://wiki.openstreetmap.org/wiki/User:NicolasDumoulin ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Bâtiment avec un préau
De : Nicolas Dumoulin Je dis ça, je ne suis pas géographe Mais si Nicolas :-). Ici on ne parle pas des diplômes etc., mais de ce que nous faisons via OSM : pour moi dans le contexte OSM nous sommes tous géographes, ou plutôt fabricants de géographie. A ce titre le nom Geofabrik est le meilleur résumé que je connaisse. 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 http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Bâtiment avec un préau
Le vendredi 16 juillet 2010 09:44:51, Vincent de Chateau-Thierry a écrit : De mon point de vue deux raisons : - un type=multipolygon se justifie si l'entité à construire est composée de polygones en archipel (des bâtiments disjoints comme par exemple sur un campus), Ben ça alors, c'est exactement le cas où je ne recommanderais pas l'utilisation d'une relation. Si on veut représenter un campus, je dirais que tracer un chemin qui forme la limite du campus marchera très bien, car le campus n'est pas que les bâtiments. Et si je m'en réfère au campus que je connais, chaque bâtiment à un nom différent, et souvent une fonction différente, je ne vois pas trop d'intérêt à les regrouper. Les relations ne sont pas des catégories http://wiki.openstreetmap.org/wiki/FR:Relations/Relations_are_not_Categories (traduite pour l'occasion ;-) ) situation, et je ne vois pas quel(s) rôle(s) on pourrait assigner aux ways A et B. simplement rien - une raison technique existe aussi : deux polygones adjacents (A et B ont un mur en commun) ne forment pas un multipolygon valide au sens de PostGIS (et de l'OGC) ça pête ! Mais c'est du bluff ;-p On parle bien ici du type=multipolygon de openstreetmap et pas de celui de l'OGC, frédérik Ramm a d'ailleurs bien expliqué que le multipolygon au sens OSM n'est pas du tout celui de l'OGC, on peut aller voir les dessins ici http://wiki.openstreetmap.org/wiki/Multipolygon pour s'en convaincre. Je dirais donc non seulement que c'est normal, mais en plus que c'est voulu ! (voulu non pas pour faire la nique à OGC, mais pour permettre de répondre à des contraintes de tailles des chemins et de manipulations humaines) , ce qui a comme conséquence de produire des résultats incorrects quand on manipule cette donnée en base. C'est faux, il suffit d'utiliser le bon outil pour passer des géométries OSM à un format de polygones compatible OGC et tout se passe bien. osm2pgsql, depuis quelques corrections de bugs gère très bien la conversion. PS: Je me fais un peu l'avocat du diable, car je suis d'accord avec tout le monde, sortir des relations pour deux petits bâtiments de 8 nouds est ridicule, car consommateur de temps bien plus que la superposition, mais je défend le principe comme étant tout à fait valable. -- sly ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Bâtiment avec un préau
De : sylvain letuffe - un type=multipolygon se justifie si l'entité à construire est composée de polygones en archipel (des bâtiments disjoints comme par exemple sur un campus), Ben ça alors, c'est exactement le cas où je ne recommanderais pas l'utilisation d'une relation. Mon exemple n'etait là que pour illustrer la configuration en archipel. Et ça n'était pas un bon exemple (mais je persiste sur l'archipel :-) Les relations ne sont pas des catégories http://wiki.openstreetmap.org/wiki/FR:Relations/Relations_are_not_Categories (traduite pour l'occasion ;-) ) +1 Mais où donc es-tu aller chercher l'exemple de la Savoie, on se demande (...) je ne vois pas quel(s) rôle(s) on pourrait assigner aux ways A et B. simplement rien Soit. - une raison technique existe aussi : deux polygones adjacents (A et B ont un mur en commun) ne forment pas un multipolygon valide au sens de PostGIS (et de l'OGC) ça pête ! Mais c'est du bluff ;-p On parle bien ici du type=multipolygon de openstreetmap et pas de celui de l'OGC, frédérik Ramm a d'ailleurs bien expliqué que le multipolygon au sens OSM n'est pas du tout celui de l'OGC, on peut aller voir les dessins ici http://wiki.openstreetmap.org/wiki/Multipolygon pour s'en convaincre. Tu y vas un peu fort en disant pas du tout. On peut lire sur la page que tu cites (traduction synthétique du dernier item de Usage) : Ce qui n'est pas un polygone valide au sens de l'OGC ne sera pas une relation multipolygon valide [dans OSM] à la notable exception des polygones avec plusieurs 'inner' qui partagent une limite. Donc l'ideée est quand même de rester en phase avec ce qui se fait hors OSM, en gérant une exception. , ce qui a comme conséquence de produire des résultats incorrects quand on manipule cette donnée en base. C'est faux, il suffit d'utiliser le bon outil pour passer des géométries OSM à un format de polygones compatible OGC et tout se passe bien. osm2pgsql, depuis quelques corrections de bugs gère très bien la conversion. Non, c'est vrai dans le contexte Maposmatic, où l'idée est de respecter la donnée telle que stockée en base, et pas de la corriger. Thomas Petazzoni le disais il ya peu ici même [1] : Du coté de MapOSMatic, nous nous refusons à faire des filtrages visant à corriger des problèmes de la base de données. Mais ma remarque n'est valable que dans ce contexte, en effet. Pour qui veut, il y a des fonctions de validation de géométrie qui permettent de filtrer les géométries erronées. PS: Je me fais un peu l'avocat du diable, car je suis d'accord avec tout le monde, sortir des relations pour deux petits bâtiments de 8 nouds est ridicule, car consommateur de temps bien plus que la superposition, mais je défend le principe comme étant tout à fait valable. En voilà une bonne conclusion, Et bon appétit... vincent [1] http://lists.openstreetmap.org/pipermail/talk-fr/2010-July/024263.html 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 http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Bâtiment avec un préau
Le vendredi 16 juillet 2010 11:54:16 sylvain letuffe, vous avez écrit : Ben ça alors, c'est exactement le cas où je ne recommanderais pas l'utilisation d'une relation. Si on veut représenter un campus, je dirais que tracer un chemin qui forme la limite du campus marchera très bien, car le campus n'est pas que les bâtiments. Et si je m'en réfère au campus que je connais, chaque bâtiment à un nom différent, et souvent une fonction différente, je ne vois pas trop d'intérêt à les regrouper. Ben moi, sur mon campus, l'IUT est un archipel de bâtiment, qui n'ont pas de fonctions différentes, à part un numéro de salle (à confirmer). -- Nicolas Dumoulin http://wiki.openstreetmap.org/wiki/User:NicolasDumoulin ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Bâtiment avec un préau
Le vendredi 16 juillet 2010 12:21:31, Vincent de Chateau-Thierry a écrit : Mon exemple n'etait là que pour illustrer la configuration en archipel. Et ça n'était pas un bon exemple (mais je persiste sur l'archipel :-) Sur l'archipel, c'est en effet une bonne solution, car le nom est bien donné à l'ensemble des îles et tracer un contour signifierait dire que l'eau porte le nom de l'archipel. Tu as raison de persister ;-) Mais où donc es-tu aller chercher l'exemple de la Savoie, on se demande Pour pas faire trop chauvin, ni me dévoiler, j'ai quand même parlé des lacs d'île de france ;-) Tu y vas un peu fort en disant pas du tout. J'avoue. Il y a bien sûr des similarités, d'ailleurs on peut passer de l'un à l'autre presque tout le temps. Mais la grosse différence est qu'un multipolygon OSM peut parfaitement être créé à partir de X chemins qui font le tour, ce qu'OGC ne conçoit que comme un tout (qu'elle appèlera d'ailleure juste POLYGON s'il n'y a qu'une surface) Ce qui n'est pas un polygone valide au sens de l'OGC ne sera pas une relation multipolygon valide [dans OSM] à la notable exception des polygones avec plusieurs 'inner' qui partagent une limite. Exact, mais ce n'est pas bijectif, une relation multipolygon valide dans OSM devra parfois être transformée pour devenir valide au sens OGC Donc l'ideée est quand même de rester en phase avec ce qui se fait hors OSM, en gérant une exception. Si je m'écoutais, je dirais que cette exception devrait être invalide dans OSM également, le gros de la différence selon moi est celle que j'ai citée, ce qui ne créer pas pour autant une incompatibilité car il suffit de coller les morceaux pour passer à OGC -- sly ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Bâtiment avec un préau
On 16/07/2010 11:50, Vincent de Chateau-Thierry wrote: De : Nicolas Dumoulin Je dis ça, je ne suis pas géographe Mais si Nicolas :-). Ici on ne parle pas des diplômes etc., mais de ce que nous faisons via OSM : pour moi dans le contexte OSM nous sommes tous géographes, ou plutôt fabricants de géographie. A ce titre le nom Geofabrik est le meilleur résumé que je connaisse. vincent Ah, ça fait plaisir. Je vais rajouter ça sur la plaque de ma porte : Vincent Pottier, géographe. -- FrViPofm ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Bâtiment avec un préau
Dans le cas des bâtiments A et B de la question initiale, on n'est pas dans cette situation, et je ne vois pas quel(s) rôle(s) on pourrait assigner aux ways A et B. Ca me paraît une raison suffisante pour éviter de construire cette relation. - une raison technique existe aussi : deux polygones adjacents (A et B ont un mur en commun) ne forment pas un multipolygon valide au sens de PostGIS (et de l'OGC), ce qui a comme conséquence de produire des résultats incorrects quand on manipule cette donnée en base. Je suppose aussi que certains batiments sont découpés en différents morceaux car ils sont composés de blocs de différentes hauteurs, si on les fusionne on ne pourrait plus donner cette hauteur pour chaque partie. Cela pourrait servir pour des représentations en 3D simple et à déjà été essayé il me semble. Mais dans le cas d'un batiment en plusieurs blocs comment le tagguer suivant sa fonction, par exemple une école ? Il faut bien créér une relation et mettre les tags sur celle ci, non ? Vlad. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Bâtiment avec un préau
Hello, Il faut faire des multipolygone : http://wiki.openstreetmap.org/wiki/Relation:multipolygon CU Stéphane Sylvain Collilieux-2 [via GIS] a écrit : Bonjour, Quand un bâtiment contient un bâtiment principal et un préau, comment faire pour insérer cela proprement ? Exemple : __ | | | | A | B | |__|___| La partie gauche (A) est le bâtiment principal : building=yes. La partie droite (B) est le préau building=yes, wall=no. Comment faire pour ne pas dessiner 2 fois le segment entre les 2 parties ? Forcément avec 2 segments qui se recouvrent, le plugiciel de validation affiche une erreur : « bâtiments chevauchants ». Merci -- Stéphane Brunner Messagerie instantanée (Jabber - XMPP) : stephane.brun...@jabber.fr -- Il existe 10 sortes de personnes : celles qui connaissent le binaire, et les autres. begin:vcard fn;quoted-printable:St=C3=A9phane Brunner n;quoted-printable:Brunner;St=C3=A9phane email;internet:courr...@stephane-brunner.ch x-mozilla-html:FALSE version:2.1 end:vcard -- View this message in context: http://gis.638310.n2.nabble.com/Batiment-avec-un-preau-tp5294746p5296845.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Bâtiment avec un préau
2010/7/15 Stéphane Brunner courr...@stephane-brunner.ch Hello, Il faut faire des multipolygone : http://wiki.openstreetmap.org/wiki/Relation:multipolygon Non, non. Il faut juste veiller à ce que les nodes soient partagés. C'est la réponse de Vincent qui est la bonne. Si après ça, le logiciel de contrôle se plaint encore, c'est son problème (en général, on peut ignorer tout ce qui n'est pas signalé comme 'error' par validator). Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Bâtiment avec un préau
2010/7/15 Pieren pier...@gmail.com 2010/7/15 Stéphane Brunner courr...@stephane-brunner.ch Hello, Il faut faire des multipolygone : http://wiki.openstreetmap.org/wiki/Relation:multipolygon Non, non. Il faut juste veiller à ce que les nodes soient partagés. C'est la réponse de Vincent qui est la bonne. Si après ça, le logiciel de contrôle se plaint encore, c'est son problème (en général, on peut ignorer tout ce qui n'est pas signalé comme 'error' par validator). Yup Validator a souvent des erreurs qui n'en sont pas. Emilie Laffray ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Bâtiment avec un préau
Bonjour, Quand un bâtiment contient un bâtiment principal et un préau, comment faire pour insérer cela proprement ? Exemple : __ | | | | A | B | |__|___| La partie gauche (A) est le bâtiment principal : building=yes. La partie droite (B) est le préau building=yes, wall=no. Comment faire pour ne pas dessiner 2 fois le segment entre les 2 parties ? Forcément avec 2 segments qui se recouvrent, le plugiciel de validation affiche une erreur : « bâtiments chevauchants ». Merci -- Sylvain signature.asc Description: OpenPGP digital signature ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Bâtiment avec un préau
Bonsoir, Sylvain Collilieux a écrit : Bonjour, Quand un bâtiment contient un bâtiment principal et un préau, comment faire pour insérer cela proprement ? Exemple : __ | | | | A | B | |__|___| La partie gauche (A) est le bâtiment principal : building=yes. La partie droite (B) est le préau building=yes, wall=no. Comment faire pour ne pas dessiner 2 fois le segment entre les 2 parties ? Forcément avec 2 segments qui se recouvrent, le plugiciel de validation affiche une erreur : « bâtiments chevauchants ». Il faut le dessiner 2 fois le segment commun, mais en prenant soin de s'appuyer sur les mêmes noeuds dans les deux cas. Chaque way (A comme B) doit être un polygone fermé autonome. L'erreur relevée par Validator est à ignorer si tu as pris soin de t'appuyer sur les mêmes nodes. Un test simple : selectionne un des deux ways, et déplace-le. S'il embarque le mur commun et déforme l'autre bâtiment, c'est que c'est bon. Ctrl+Z ensuite bien sûr ;o) vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
