<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">Le 31 août 2016 à 09:56, operon85 <span dir="ltr"><<a href="mailto:operon85@orange.fr" target="_blank">operon85@orange.fr</a>></span> a écrit :<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF">
<div>Bonjour,<br>
<br>
* Les panneaux EB10/EB20 : Il faut les mettre là où il sont sur le
terrain : Assez souvent ils ne sont pas l'un en face de l'autre
mais à plusieurs dizaine de mètres donc difficile de mettre un
traffic_sign au croisement de la voie de circulation.<br></div></div></blockquote><div> </div><div>C'est ton choix. Nous en avons fait un différent en projetant le point sur le réseau. Jusqu’aù jour où il y a aura une décision réel de prendre un cas ou l'autre. Même combat sur l’implantation des feux de signalisation et d'autres panneaux mais c'est pas le sujet.</div><div>Quand au panneau placé hors réseau, il faudra ajouter des information supplémentaire pour en indiquer l'orientation car le panneau peut aussi être placé à gauche de la voie.</div><div><br></div><div>Le problème sur le décalage est aussi un faux problème car dans ce cas on met deux points et de toute façon on qualifie la vitesse sur le réseau avec maxspeed:forward et maxspeed:backward</div><div>Il y a plein d'endroit on la vitesse est différente selon le sens de circulation. Sachant que le rôle des panneaux EB10 et EB20 n'est que de définir la vitesse par défaut dans l'agglomération et le nom de l'agglomération traversé. Hors le nom on l'à par le découpage communale dans OSM.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF"><div>
<br>
* " avoir accès aux textes (arrêtés municipaux ...) qui
définissent les limites de ces agglomérations... " : C'est le cas
avec la mise en place de RLP et RLPi (intercommunal) qui doivent
comporter la positions des panneaux et le contour des zones. En
2016 la plupart des communes mettre à dispo les arrêtes municipaux
sur internet.<br></div></div></blockquote><div><br></div><div>En effet c'est une source intéressante pour le zonage. Reste à voir si elle est cohérente en terme d'échelle de saisie avec celle des limites d'agglomération défini par le code de la route.</div><div><br></div><div>Il y a un travail à faire de recensement des données sources et de vérification de la qualité de ces informations.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF"><div>
* Tracer ces données dans OSM, très ambitieux !!! : Certes mais
pas plus que les passages piéton, les feux tricolores, ....<br></div></div></blockquote><div> </div><div>Ca c'est clair mais on n'a pas besoin de grand chose sauf voir une ortho et un passage sur le terrain. Ne pas confondre complexité à l'intégration et masse de données à intégrer</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF"><div>
* Calcul automatique à partir de CLC : Pas possible pour plusieurs
raisons:<br>
- CLC, pas assez précis (dans la plupart des cas). CLC est
censé représenté la réalité physique des contours des differentes
zones pas les contours administratifs.<br></div></div></blockquote><div>Qui à parler de ça... J'ai raté un passage? Bref c'est pas une réalité physique mais une réalité de couverture à une échelle de saisie complètement foireuse d'où l'ajout de nouveau landuse là où c'est nécessaire et le coupage des landuse résultant d'un import CLC. OSM à pour but de représenter les info à une précision métrique (voir inférieur) et la CLC c'est une précision de 30m avec des entités d'une superficie minimum ce qui n'est pas le cas dans OSM.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF"><div>
- Les limites des agglomération ne correspondent pas avec "
bâti rapproché". " il y a encore un cas où les panneaux ne
correspondent pas à l'agglomération réelle : quand le maire
prévoit l'étalement urbain et positionne les panneaux là où sera
la limite quand après une révision du PLU les champs auront été
transformés en lotissement." C'est vrai (très souvent) mais la
position des panneaux EB10/EB20 sont ceux qui nous sont opposable
pour la lois (Vitesse par exemple). Sinon il faut (avant que l'on
nous oppose ces limites) à faire annuler l’arrêté municipal
fixant les limites de l'agglomération. D'où la différence entre
CLC (réalité terrain) et Agglomération (réalité administrative).<br></div></div></blockquote><div>J'ai pas compris le rapport mais dans tous les cas on ne peut pas se baser sur une couverture pour définir un espace règlementaire.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF"><div>
<br>
* Pour la publicité, des enclaves pour domaine privé et autres :
C'est un faux problème (pour l'instant) je n'ai encore jamais vu
(par exemple pour les vitesse) une voie privée affublé de
"maxspeed=no_limit".<br></div></div></blockquote><div>Le maxspeed n'a pas de rapport avec la publicité mais clairement un circuit privé n'a pas de vitesse limité. Elle est limité par la personne privé et par la qualité de la route à emprunter.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF"><div>
<br>
* L'article R.110-2 du code de la route et l'Art. R.411-2 du code
de la route ne sont pas antinomique, c'est juste une précision de
Qui (R411) doit fixer les limites dans le respect du R110.<br>
<br>
* Tout à fait d'accord avec Christian, il ne faut pas pointer un
usage particulier.<br>
Ces panneaux sont en place, les contours sont définis, ils peuvent
servir à un ou plusieurs usage.<br></div></div></blockquote><div>J'ai pointer en réponses @Paul Desgegranges</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF"><div>
<br>
Mon usages particulier (mais pas personnel) est la projection
vertical des contours des agglomération pour en faire des zones
aérienne à condition particulières afin de respecter la
réglementation aérienne. Beaucoup utilise leur système de
géoguidage (GPS) sur la route mais moi j'aimerais l'utiliser en
vol parce que déplier une carte de 1 mètre carré pendant que l'on
pilote, c'est pas facile.</div></div></blockquote><div><br></div><div>En clair tu représentes la volumétrie de l'espace aérien. Sauf que dans l'espace aérien la notion d'agglomération est surement différente. </div><div>J'ai vu ce genre de chose mais pour les drônes</div><div><a href="http://www.aip-drones.fr/carte/aip-drones/">http://www.aip-drones.fr/carte/aip-drones/</a><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF"><div>
J'ai eu beau lancer la discussion sur le "Comment taguer" et pas
"doit-on taguer", je me doutais que j'allais lancer des échanges
importants.<br>
Merci à vous<br></div></div></blockquote><div> </div><div>C'est un peut le problème. J'ai redirigé involontairement sur les landuse. Mais avant de savoir comment taguer en voulant créer une nouvelle relation boundary il faut savoir si l'on doit le faire dans OSM ou ailleurs et si c'est possible juste avec les données et les informations dont on dispose. </div></div>
</div></div>