Le 31 août 2016 à 09:56, operon85 <opero...@orange.fr> a écrit : > Bonjour, > > * 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. >
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. 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. 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 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. > > * " 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. > 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. Il y a un travail à faire de recensement des données sources et de vérification de la qualité de ces informations. * Tracer ces données dans OSM, très ambitieux !!! : Certes mais pas plus > que les passages piéton, les feux tricolores, .... > 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 > * Calcul automatique à partir de CLC : Pas possible pour plusieurs raisons: > - 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. > 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. > - 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). > 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. > > * 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". > 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. > > * 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. > > * Tout à fait d'accord avec Christian, il ne faut pas pointer un usage > particulier. > Ces panneaux sont en place, les contours sont définis, ils peuvent servir > à un ou plusieurs usage. > J'ai pointer en réponses @Paul Desgegranges > > 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. > 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. J'ai vu ce genre de chose mais pour les drônes http://www.aip-drones.fr/carte/aip-drones/ > 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. > Merci à vous > 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.
_______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
