Le 11 mai 2012 13:44, Christian Rogel
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 lignes standards dans un message
Le 11 mai 2012 13:44, Christian Rogel
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 reprocher (sans compter que ce
me
Le 11 mai 2012 à 13:48, THEVENON Julien a écrit :
> De : Christian Rogel
> 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 Long ;
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
Le 11 mai 2012 12:23, Tenshu 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 email en texte se
Je suis désolé Philippe,
J'aurais sincèrement aimé participé à cette discussion.
Mais tes messages sont proprement inintelligibles.
- Trop longs
- Trop compliqués
- Et sérieusement arrêtes vide de couper tes phrases en morceaux
Je suppose que c'est de l'humour, en jouant sur les couleurs... de
> Ton algo ne marche pas, il transforme les cases noires en cases vertes :
> http://www.openstreetmap.org/?lat=41.7517375946045&lon=-122.933750152588&zoom=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 p
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).
Le 5 mai 2012 16:15, sly (sylvain letuffe) 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 standard"
> > 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
Le 5 mai 2012 15:24, sly (sylvain letuffe) 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 de tri des
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.or
Le 5 mai 2012 14:52, Christian Quest 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 sont toutes valides a
Le 5 mai 2012 14:38, Vincent Pottier a écrit :
> Le 05/05/2012 14:12, Philippe Verdy a écrit :
>>
>> Le 5 mai 2012 14:04, Christian Quest 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
Le 5 mai 2012 14:41, Philippe Verdy 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 de l'ordre de c
Le 5 mai 2012 14:36, Christian Quest a écrit :
> Le 5 mai 2012 14:12, Philippe Verdy 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, d
Le 05/05/2012 14:12, Philippe Verdy a écrit :
Le 5 mai 2012 14:04, Christian Quest 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é.
Je maintiens que
Le 5 mai 2012 14:12, Philippe Verdy 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 et qui comprend
Le 5 mai 2012 14:04, Christian Quest 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 à condition de changer
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 completenes
Le 5 mai 2012 13:07, Philippe Verdy 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 qui fait une
conver
Le 5 mai 2012 12:19, sly (sylvain letuffe) 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 cette list
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
> "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à comme
> > ç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 l
Le 5 mai 2012 10:23, DH 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 MULTIPOLYG
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 d
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
> +---+
> | |
> | +--+ |
> | | A | |
> | +-+ +---+ ++ |
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) :
+---+
| |
Le 4 mai 2012 22:19, sly (sylvain letuffe) 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 le tri d
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 ?
> http://workshops.opengeo.org/po
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 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
Le 4 mai 2012 21:33, sly (sylvain letuffe) 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 moi à
> 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 p
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
Le 4 mai 2012 19:24, sly (sylvain letuffe) 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
> t'apporter une aut
Le 4 mai 2012 19:16, Marc Sibert 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 limites so
Le 4 mai 2012 19:24, sly (sylvain letuffe) 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."
>
> Donc, ne
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
« 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
> 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 d
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 pa
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 modèl
Bonjour,
Le 4 mai 2012 13:29, Philippe Verdy 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 (quelques mètres voire
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
fragm
46 matches
Mail list logo
