<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p>
<blockquote type="cite">J'ai basculé ces "type=multipolygon" en
"type=boundary"... et tout rentre dans l'ordre comme je l'avais
imaginé dans mon précédent message qui n'a visiblement pas été
lu ;)</blockquote>
Bonjour et merveilleux !! Je n'avais pas compris le sous-entendu.
Merci.<br>
</p>
<p>
<blockquote type="cite">En terme de logique de tagging je verrai
plutôt quelque chose comme:<br>
type=boundary (il s'agit d'une frontière qui découpe un ensemble
plus grand)<br>
boundary=forest (frontière forestière)<br>
forest=section (il s'agit d'une section)<br>
<br>
Mais ça mérite discussion sur le wiki plutôt que d'y aller à
l'arrache... [...]<br>
</blockquote>
Tout là fait d'accord (sans rentrer dans la discussion ici :
j'aime bien ta proposition, elle est plus proche de l'existant et
donc plus naturelle que la proposition Section).</p>
<p>Pour info il se trouve que j'ai eu un échange de mail avec
l'auteur de la proposition Section cet été (à propos d'un
cimetière que je visitais/cartographiais à l'époque) et il m'a dit
qu'il n'avait pas eu le courage pour animer sa proposition
jusqu'au bout. Il m'a encouragé à la retravailler voir à faire une
contre-proposition, car il reste persuadé du besoin initial
(parcelles forestières, sections dans un cimetière...).<br>
</p>
<p>
<blockquote type="cite"><br>
<div>Mais ça mérite discussion sur le wiki plutôt que d'y aller
à l'arrache... surtout que l'import des données est pas génial
non plus car les données d'origine ne sont pas forcément bien
calées...<br>
<br>
</div>
Exemple: <a moz-do-not-send="true"
href="http://umap.openstreetmap.fr/en/map/test-rendu-osmfr_99740#18/48.53494/1.97682">http://umap.openstreetmap.fr/en/map/test-rendu-osmfr_99740#18/48.53494/1.97682</a></blockquote>
Alors là c'est drôle car pendant que tu changeais le type de
relation je recalais exactement l'endroit que tu cite (ce qui m'a
valu de résoudre quelques conflits d'éditions quand j'ai voulu
envoyer sur le serveur). Donc en me basant sur le cadastre j'ai
regroupé hier ce qui devait l'être dans la zone (je n'ai pas
déplacé les frontières administratives mais les layons, chemins et
bordures de forêt. Il reste encore une bonne partie du périmètre à
recaler) et j'en avais profité pour ajouter un gros morceau de
forêt manquant côté Yvelines (<a
href="http://www.openstreetmap.org/relation/6770020">http://www.openstreetmap.org/relation/6770020</a>).</p>
<p>Bref il reste du boulot mais problème de rendu de parcelle réglé,
je déploierai la solution sur les forêts alentours qui ont le même
soucis, merci !<br>
</p>
<p>Cordialement<br>
</p>
<pre class="moz-signature" cols="72">LeTopographeFou</pre>
<div class="moz-cite-prefix">Le 05/12/2016 à 23:18, Christian Quest
a écrit :<br>
</div>
<blockquote
cite="mid:CAAXY6DNN6AED+jtwMLjic337avtv-O9hNhQULE+LTHb3jZdJ=Q@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>
<div>
<div>
<div>
<div>J'ai basculé ces "type=multipolygon" en
"type=boundary"... et tout rentre dans l'ordre comme
je l'avais imaginé dans mon précédent message qui n'a
visiblement pas été lu ;)<br>
<br>
</div>
Ces sections forestières sont bien des frontières et ça
évite à osm2pgsql de chercher à savoir par une
euristique imparfaite ce que sont ces multipolygones
mystérieux...<br>
<br>
</div>
En terme de logique de tagging je verrai plutôt quelque
chose comme:<br>
</div>
type=boundary (il s'agit d'une frontière qui découpe un
ensemble plus grand)<br>
</div>
boundary=forest (frontière forestière)<br>
</div>
<div>forest=section (il s'agit d'une section)<br>
<br>
</div>
<div>Mais ça mérite discussion sur le wiki plutôt que d'y aller
à l'arrache... surtout que l'import des données est pas génial
non plus car les données d'origine ne sont pas forcément bien
calées...<br>
<br>
</div>
<div>Exemple: <a moz-do-not-send="true"
href="http://umap.openstreetmap.fr/en/map/test-rendu-osmfr_99740#18/48.53494/1.97682">http://umap.openstreetmap.fr/en/map/test-rendu-osmfr_99740#18/48.53494/1.97682</a><br>
<br>
</div>
<div>Les tuiles sont en train de se remettre à jour... un peu de
patience.<br>
</div>
<div><br>
</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">Le 5 décembre 2016 à 22:17, <span
dir="ltr"><<a moz-do-not-send="true"
href="mailto:osm.sanspourriel@spamgourmet.com"
target="_blank">osm.sanspourriel@spamgourmet.com</a>></span>
a écrit :<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="transparent" text="#000000">
<p>Le 05/12/2016 à 21:57, LeTopographeFou - <a
moz-do-not-send="true"
class="m_1589418262703252056moz-txt-link-abbreviated"
href="mailto:letopographefou@gmail.com"
target="_blank">letopographefou@gmail.com</a> a
écrit :<br>
</p>
<blockquote type="cite">
<p>Bonsoir à tous,</p>
<span class="">
<p>A vrai dire je croyais que le moteur ne dessinait
que les objets issus d'une requête (donc les objets
connus) et pas tous les objets. Visiblement ce n'est
pas le cas.</p>
</span></blockquote>
Jusqu'à peu c'était le cas. J'ai vu que maintenant les
"noms" des transformateurs apparaissent sur la carte.<br>
Assez absurde pour une carte générique.<span class=""><br>
<br>
<blockquote type="cite">
<p>Entre nous, ce système de "je fais remonter les
valeurs communes" me parait biaisé et n'incite pas à
correctement tagger. Je préfère 100x plus un moteur
de rendu stricte et exigent qui pousse à bien faire
mais dessine avec ce qu'on lui donne plutôt qu'un
qui interprète les données avec des attributs qui
n'existent pas et dessine des relations qu'il ne
connait pas (avec 50% de risque de se planter). Si
le moteur ne connait pas une relation, il devrait
l'ignorer. Si il lui manque une propriété, il
devrait pouvoir faire sans. Dixit un gars qui n'a
pas sué dans le développement de ces beaux outils
:-) .<br>
</p>
</blockquote>
</span> Si c'est une info commune, pourquoi pas ? Je dis
bien commune c'est à dire identique dans tous les membres.<br>
Sinon c'est éventuellement un candidat pour un outil
d'assurance qualité (que des noms identiques ou pas de
noms : peut-être que les sans noms devraient avoir le même
nom, ça peut avoir du sens pour des réseaux, des trajets
tels que des pistes cyclables sans nom connectés à
d'autres pistes cyclables ayant un nom... ou une
référence).<br>
<br>
Jean-Yvon<br>
</div>
<br>
______________________________<wbr>_________________<br>
Talk-fr mailing list<br>
<a moz-do-not-send="true"
href="mailto:Talk-fr@openstreetmap.org">Talk-fr@openstreetmap.org</a><br>
<a moz-do-not-send="true"
href="https://lists.openstreetmap.org/listinfo/talk-fr"
rel="noreferrer" target="_blank">https://lists.openstreetmap.<wbr>org/listinfo/talk-fr</a><br>
<br>
</blockquote>
</div>
<br>
<br clear="all">
<br>
-- <br>
<div class="gmail_signature" data-smartmail="gmail_signature">
<div dir="ltr">Christian Quest - OpenStreetMap France</div>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Talk-fr mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Talk-fr@openstreetmap.org">Talk-fr@openstreetmap.org</a>
<a class="moz-txt-link-freetext" href="https://lists.openstreetmap.org/listinfo/talk-fr">https://lists.openstreetmap.org/listinfo/talk-fr</a>
</pre>
</blockquote>
<br>
</body>
</html>