<div dir="ltr">Je me suis mal exprimé...<div><br></div><div>J'éviterai de retirer les tags existant (pour ne pas impacter leurs ré-utilisateurs), mais je ne suis pas du tout opposé à un zonage des codes postaux s'appuyant sur des relations boundary=*, au contraire... c'est juste que l'on va avoir la remarque immanquable sur la redondance (que j'aime bien).</div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">Le 12 mai 2014 10:57, V de Chateau-Thierry <span dir="ltr"><<a href="mailto:vdct@laposte.net" target="_blank">vdct@laposte.net</a>></span> a écrit :<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Bonjour,<br>
<br>
> De : "Christian Quest"<br>
<div class="">><br>
> Le 12 mai 2014 10:36, Pieren<br>
</div>a écrit :<br>
<div class="">><br>
> > Ces 2 adresses sont dans la commune de St Maur des Fossés (code INSEE<br>
> > 94068), mais on n'indique jamais St Maur sur un courier qui va à La Varenne<br>
> > (ou par erreur)... certaines personnes pensent même que c'est une commune à<br>
> > part entière.<br>
><br>
> Concernant le tag "place", il ne doit pas y avoir de problème puisque<br>
> le cas d'un polygone avec plusieurs "places" est fréquent. Par contre,<br>
> pour le code postal, je reviens sur ma proposition de faire comme les<br>
> allemands (qui ont les mêmes problèmes que nous): déplacer touts les<br>
> codes postaux dans leur propre relation/polygone de type<br>
> "boundary=postal_code":<br>
> <a href="http://wiki.openstreetmap.org/wiki/DE:Konsolidierung_der_PLZ-" target="_blank">http://wiki.openstreetmap.org/wiki/DE:Konsolidierung_der_PLZ-</a><br>
Relationen_in_Deutschland_2013<br>
> <a href="http://wiki.openstreetmap.org/wiki/Tag:boundary%3Dpostal_code" target="_blank">http://wiki.openstreetmap.org/wiki/Tag:boundary%3Dpostal_code</a><br>
><br>
<br>
><br>
> De mémoire c'est ce que j'ai fait pour mon cas local particulier.<br>
> Le généraliser à tout les codes postaux alors qu'on a l'info modéliser autrement en<br>
> France, ça me semble bien lourd et surtout l'impact sur des utilisateurs actuels n'est<br>
> pas négligeable. J'éviterai.<br>
<br>
</div>Pourquoi éviter ? Propager ce modèle aurait surtout des avantages, je trouve :<br>
- cohérent avec celui de nos voisins<br>
- compatible avec notre granularité de codes postaux, qui navigue entre multi-communal<br>
et infra-communal<br>
- cerise sur le gâteau : ça peut se faire en douceur, sans impact sur les modèles<br>
actuels (essentiellement le addr:postcode sur les relations admins), en procédant par<br>
ajout de ces nouvelles zones, sans suppression du tag addr:postcode sur les relations<br>
admins. Quitte ensuite, et ce sera souhaitable, à communiquer sur l'obsolescence du<br>
modèle actuel et inciter les consommateurs à basculer sur le nouveau.<br>
<br>
Bon après, ça s'appuie sur le tag postal_code au lieu de addr:postcode, ce qui je trouve<br>
est une mauvaise idée (2 tags pour la même notion), mais bon...<br>
<br>
vincent<br>
<div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
Talk-fr mailing list<br>
<a href="mailto:Talk-fr@openstreetmap.org">Talk-fr@openstreetmap.org</a><br>
<a href="https://lists.openstreetmap.org/listinfo/talk-fr" target="_blank">https://lists.openstreetmap.org/listinfo/talk-fr</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr">Christian Quest - OpenStreetMap France<div><a href="http://openstreetmap.fr/sotmfr" target="_blank">Conférence "State Of The Map" France du 4 au 6 avril à Paris</a></div>
</div>
</div>