Le 11 mai 2012 13:44, Christian Rogel
christian.ro...@club-internet.fr a écrit :
Le 11 mai 2012 à 12:32, Philippe Verdy a écrit :
Qu'avais-tu besoin de parler de ponctuation et de style?
Ce n'est pas moi qui en ai parlé, j'ai répondu à un message qui ne
parlait QUE de ça, pour me le
Le 11 mai 2012 13:44, Christian Rogel
christian.ro...@club-internet.fr a écrit :
TLPYRS (Trop long pour y répondre sérieusement)
Tu peux rajouter NTS;DS (Nothing to say, don't send).
ABP (abus de bande passante)
Que tu peux adresser à celui auquel je répondais et qui comptait mes
sauts de
Le 11 mai 2012 12:23, Tenshu ten...@gmail.com a écrit :
(2 sauts de lignes par phrase sérieusement?!)
Où ça ? Il n'y a qu'une ligne vide entre deux paragraphes distincts,
pour les distinguer des simples renvois automatiques à la ligne à
cause de la largeur de page.
N'oublie pas que c'est un
Le 11 mai 2012 à 12:32, Philippe Verdy a écrit :
Je ne vois pas absolument en quoi cette ponctuation est incorrecte, et
en tout cas contraire à une quelconque étiquette, ni quel effort tu
veux demander ici.
Sauf si ton but est de continuer à polémiquer inutilement parce que
mon style
Le 11 mai 2012 à 13:48, THEVENON Julien a écrit :
De : Christian Rogel christian.ro...@club-internet.fr
Exemples
TLPYRS (Trop long pour y répondre sérieusement)
ABP (abus de bande passante)
NEWWH (No exit way while horning)
Tu peux rajouter le magnifiquement concis tl;dr ( Too
Je confirme que ton ficher OSM ne marche pas : il correspond
EXACTEMENT à ce que j'avais mis juste avant de scinder le nœud commun
en 4 (regarde l'historique).
Ton fichier ne lève pas du tout l'ambiguité de la façon
d'interconnecter les 4 segments limités par ce point commun, osm2gis
les connecte
Le 04/05/2012 22:31, sly (sylvain letuffe) a écrit :
Le vendredi 4 mai 2012 22:22:55, DH a écrit :
Cet espace est une espèce de trou noir si j'ai bien compris le schéma.
Quelle dimension pour le supertuyau afin de canaliser le superflux ?
PVCompatible ?
ça va ? c'est de la bonne ?
oui c'est
Le 5 mai 2012 10:23, DH dhel...@free.fr a écrit :
Ton lien est très bien et j'étais déjà tombé dessus mais il parle de la
primitive POLYGON de l'OGC pas de la primitive MULTIPOLYGON dont il est
question ici, qui elle autorise que deux polygons distinct se touchent au
sein
d'une primite
ça va ? c'est de la bonne ?
oui c'est de la bonne ; je l'ai acheté dans la même boutique où tu as
trouvé ton dictionnaire.
Ben mince alors, pas terrible donc, je vais changer de boutique et je relirais
mon mail la prochaine fois.
Il me semble que le problème se situe au niveau de
solution et cela ne marchait pas !).
je crois que ce que tu défini par ne marche pas m'échappe.
cela ne marche pas car ton test consiste à créer deux zones fermées
seulement et tu ignores les deux autres zones qui entourent ce point
commun. Bref ton test est incomplet.
Voilà comment
Le samedi 5 mai 2012 07:26:09, Philippe Verdy a écrit :
Note: je suis tombé aussi sur d'autres cas de géométries qui son mal
résolues lors de la conversion OSM vers OGC.
Mon avis est que cette question n'a pas sa place sur cette liste car trop
technique; et, spécifique, à mon avis, à l'outil
Le 5 mai 2012 12:19, sly (sylvain letuffe) li...@letuffe.org a écrit :
Le samedi 5 mai 2012 07:26:09, Philippe Verdy a écrit :
Note: je suis tombé aussi sur d'autres cas de géométries qui son mal
résolues lors de la conversion OSM vers OGC.
Mon avis est que cette question n'a pas sa place sur
Le 5 mai 2012 13:07, Philippe Verdy verd...@wanadoo.fr a écrit (entre autre) :
Tu ne comprends pas le problème visiblement.
Philippe, ce que j'ai beaucoup de mal à comprendre ce sont surtout tes
mails... je ne pense pas être le seul.
Il me semble que le problème se situe au niveau d'osm2gis
Note bien ce qui est écrit dans la doc des multipolygones sur le wiki :
Usage
The intended use of multipolygons is this:
[..]
The direction of the ways does not matter.
The order of the relation members does not matter (but properly sorted
member lists can help human editors to verify
Le 5 mai 2012 14:04, Christian Quest cqu...@openstreetmap.fr a écrit :
Pour moi (et visiblement pour d'autres) il n'y a pas de limitation
côté OSM mais un bug dans osm2gis qui ne gère pas correctement les cas
particuliers que tu as très justement signalé.
Il n'y a pas de limitation dans OSM à
Le 5 mai 2012 14:12, Philippe Verdy verd...@wanadoo.fr a écrit :
Il n'y a pas de limitation dans OSM à condition de changer les règles.
Les règles énoncées dans le wiki sont insuffisantes, je ne maintiens
et je l'ai prouvé. Tant pis si tu ne comprends pas, demande à un
géomètre mathématicien
Le 05/05/2012 14:12, Philippe Verdy a écrit :
Le 5 mai 2012 14:04, Christian Questcqu...@openstreetmap.fr a écrit :
Pour moi (et visiblement pour d'autres) il n'y a pas de limitation
côté OSM mais un bug dans osm2gis qui ne gère pas correctement les cas
particuliers que tu as très justement
Le 5 mai 2012 14:36, Christian Quest cqu...@openstreetmap.fr a écrit :
Le 5 mai 2012 14:12, Philippe Verdy verd...@wanadoo.fr a écrit :
Il n'y a pas de limitation dans OSM à condition de changer les règles.
Les règles énoncées dans le wiki sont insuffisantes, je ne maintiens
et je l'ai prouvé.
Le 5 mai 2012 14:41, Philippe Verdy verd...@wanadoo.fr a écrit :
JOSM y parvient dans certains cas, pas toujours. Le tri obtenu dépend
de l'ordre dans lequel il considère les paires de ways possibles,
lequel semble dépendre de la valeur des id (qui ne devrzit pas être
significative) et donc
Le 5 mai 2012 14:38, Vincent Pottier vpott...@gmail.com a écrit :
Le 05/05/2012 14:12, Philippe Verdy a écrit :
Le 5 mai 2012 14:04, Christian Questcqu...@openstreetmap.fr a écrit :
Pour moi (et visiblement pour d'autres) il n'y a pas de limitation
côté OSM mais un bug dans osm2gis qui ne
Le 5 mai 2012 14:52, Christian Quest cqu...@openstreetmap.fr a écrit :
Sur l'exemple que tu indiquais où 18 géométries étaient possibles dont
9 valides... ces 9 valides sont-elles équivalentes ? Si oui, ne
suffit-il pas d'en choisir une parmi les 9 ?
Non impossible d'en déterminer une : elles
Le samedi 5 mai 2012 14:12:22, Philippe Verdy a écrit :
Je maintiens que ton fichier démo2 reste ambigu selon les règles mêmes
énoncées dans le wiki
Non, il ne l'est pas.
--
sly (sylvain letuffe)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
Le 5 mai 2012 15:24, sly (sylvain letuffe) li...@letuffe.org a écrit :
Le samedi 5 mai 2012 14:12:22, Philippe Verdy a écrit :
Je maintiens que ton fichier démo2 reste ambigu selon les règles mêmes
énoncées dans le wiki
Non, il ne l'est pas.
Regarde mieux !
Tiens compte du fait que l'ordre
Non, il ne l'est pas.
Regarde mieux !
re-lit la page du wiki qui parle des relations multipolygone, elle dit :
the multipolygon relation can be used to build multipolygons in compliance
with the OGC Simple Feature standard
Tiens compte du fait que l'ordre de tri des membres n'est pas
Le 5 mai 2012 16:15, sly (sylvain letuffe) li...@letuffe.org a écrit :
Non, il ne l'est pas.
Regarde mieux !
re-lit la page du wiki qui parle des relations multipolygone, elle dit :
the multipolygon relation can be used to build multipolygons in compliance
with the OGC Simple Feature
Bonsoir,
Le 05/05/2012 21:35, Philippe Verdy a écrit :
(...)
Pour un exemple complet, il faudrait faire le test avec en tentant de
représenter la surface des cases noires d'un échiquier (dont les ways
de délimitation peuvent être dans tous les sens et dans le désordre le
plus complet).
Ton algo ne marche pas, il transforme les cases noires en cases vertes :
http://www.openstreetmap.org/?lat=41.7517375946045lon=-122.933750152588zoom=13
(merci Éric [1] :-) )
Je suppose que c'est de l'humour, en jouant sur les couleurs... de
toute façon mon algo n'a pas été utilisé pour
J'ai un exemple de géométrie pour une commune très complexe (en
Espagne) pour lequel je ne trouve strictement aucun moyen de le
résoudre proprement.
Voir ici :
http://analyser.openstreetmap.fr/cgi-bin/index.py?relation=343332
Cette commune n'est pas une erreur ! Elle est effectivement très
Bonjour,
Le 4 mai 2012 13:29, Philippe Verdy verd...@wanadoo.fr a écrit :
Ici, la commune A possède deux anneaux qui se touchent au point
central, mais ces anneaux n'ont pas d'autre intersection : la surface
de l'intersection des zones est nulle.
Faites une surface dérisoire de liaison
J'avais déjà suggéré cette solution dans mon message. Il n'empêche que
c'est du pseudo-mapping : on ajoute des trucs inexistants (ici des
frontières supplémentaires qui rompent les relations de voisinage à
cause d'un bogue de la conversion des données OSM vers OpenGIS. Ca
montre une limite du
Le 04/05/2012 13:29, Philippe Verdy a écrit :
J'ai un exemple de géométrie pour une commune très complexe (en
Espagne) pour lequel je ne trouve strictement aucun moyen de le
résoudre proprement.
Voir ici :
http://analyser.openstreetmap.fr/cgi-bin/index.py?relation=343332
Cette commune n'est
« S'*il n'y a pas de solution*, *c'est qu*'*il n'y a pas de problème*. »
Devise des Shadoks !
2012/5/4 Marc Sibert m...@sibert.fr
Le 04/05/2012 13:29, Philippe Verdy a écrit :
J'ai un exemple de géométrie pour une commune très complexe (en
Espagne) pour lequel je ne trouve strictement
Préambule par un gars relou et radotteur (moi) mais qui veut ne pas perdre
espoir : je m'étais promis de ne plus répondre à tes mails que je trouve trop
désordonnés et beaucoup trop long pour arriver à en trouver la vrai question
qui tiendrait en 10 lignes, mais c'est dommage car il y en a avec
Le 4 mai 2012 19:24, sly (sylvain letuffe) li...@letuffe.org a écrit :
En cherchant, on fini par tomber sur l'information concernant ce standard qui
dit :
2. The Boundaries of any 2 Polygons that are elements of a
MultiPolygon may not ‘cross’ and may touch
at only a finite number of points.
Le 4 mai 2012 19:16, Marc Sibert m...@sibert.fr a écrit :
Pourquoi ne pas simplement fermer les petites surfaces par des contours
continus et ne pas mutualiser les limites, c'est à dire en faire
plusieurs.
La modélisation restera juste mais non optimale.
Non, ça ne marche pas plus ! Que les
Le 4 mai 2012 19:24, sly (sylvain letuffe) li...@letuffe.org a écrit :
D'apporter tout de suite des solutions à ce que tu crois être un problème,
rentrer dans des constructions compliquées de il faudrait faire si ou ça
alors qu'en fait tu n'a pas attendu les avis des autres qui pourraient
Le vendredi 4 mai 2012 21:23:21, Philippe Verdy a écrit :
Donc, ne change rien, ce que tu as fais est bon conformément à ce que dit
le wiki.
Justement je démontre ici que ce n'est pas vrai.
Alors relis le wiki et dis moi à quel endroit le wiki n'est pas conforme à ce
que tu as fais ?
J'ai attendu 3 semaines en interrogeant diverses sources et n'avaient
obtenu aucune réponse. Tu te trompes.
Excuses moi si je n'ai pas été clair, je parlais de ton mail.
Ta démarche de venir poser ta question sur la liste est louable et valide et
c'est une question pertinente.
Ce que je te
Le 4 mai 2012 21:33, sly (sylvain letuffe) li...@letuffe.org a écrit :
Le vendredi 4 mai 2012 21:23:21, Philippe Verdy a écrit :
Donc, ne change rien, ce que tu as fais est bon conformément à ce que dit
le wiki.
Justement je démontre ici que ce n'est pas vrai.
Alors relis le wiki et dis
Le vendredi 4 mai 2012 21:44:30, Philippe Verdy a écrit :
la preuve que si puisque tu l'as fais.
Non, je ne l'ai pas fait : j'ai supprimé les noeuds d'intersection en
question en faussant légèrement la géométrie pour que le tri des ways
fait par les outils d'export OSM vers OpenGIS ne se
Le 04/05/2012 21:43, sly (sylvain letuffe) a écrit :
.., et surtout dans le cas d'espace, j'avais personnellement tout
compris dès le schéma,
Cet espace est une espèce de trou noir si j'ai bien compris le schéma.
le reste était superflux avant nouvelles questions.
Quelle dimension pour le
Le vendredi 4 mai 2012 22:22:55, DH a écrit :
Cet espace est une espèce de trou noir si j'ai bien compris le schéma.
Quelle dimension pour le supertuyau afin de canaliser le superflux ?
PVCompatible ?
ça va ? c'est de la bonne ?
Self-Ring Intersection ?
Le 4 mai 2012 22:19, sly (sylvain letuffe) li...@letuffe.org a écrit :
Le vendredi 4 mai 2012 21:44:30, Philippe Verdy a écrit :
la preuve que si puisque tu l'as fais.
Non, je ne l'ai pas fait : j'ai supprimé les noeuds d'intersection en
question en faussant légèrement la géométrie pour que
Note: je suis tombé aussi sur d'autres cas de géométries qui son mal
résolues lors de la conversion OSM vers OGC.
Un de ces cas incluait la situation suivante (schématisée ici) :
+---+
|
+---+
| |
| +--+ |
| | A | |
| +-+ +---+ ++ |
|
45 matches
Mail list logo
