[OSM-dev-fr] outil adresse du plugin JOSM cadastre-fr

Christian Quest cquest at openstreetmap.fr
Jeu 23 Jan 13:32:35 UTC 2014


Je rappelle mon tiercé... 1 3 2

Le tien: 1 2 3

Le cas 1 est facile à gérer pour les bâtiments en bord de voirie. Au pire
si le numéro est "flottant", on peut le reprojeter sur le bâtiment le plus
proche dans un rayon de seulement quelque m. Pour notre intégration, il
faudrait que cette reprojection soit faite de la façon la plus automatique
possible, sinon ça prend un temps fou à faire et on fait ça comme un
robot... donc à automatiser.

Là où ça se complique c'est quand le bâtiment n'est pas en bord de
voirie... là moi je préfère le point adresse en bord de voirie (cas 3, en
gros ce qu'on peut constater sur le terrain, c'est à dire l'endroit où il y
a la plaque ou l'entrée ou la boite aux lettres) et toi tu le fait migrer
sur le bâtiment principal sur la parcelle (2) vu qu'on n'a pas la parcelle.

Si je préfère le 3, c'est qu'on reste sur un modèle plus proche du cas 1,
c'est à dire qu'on a du ponctuel, plus ou moins aligné sur la voirie. J'ai
l'impression que c'est plus cohérent.



Le 23 janvier 2014 14:01, Vincent de Château-Thierry <vdct at laposte.net> a
écrit :

>
> Le 23/01/2014 13:35, Christian Quest a écrit :
>
>  Je comprends tout à fait le besoin de lier tel ou tel objet (comme un
>> bâtiment) à une adresse, mais de là à considérer que c'est le bâtiment
>> qui doit porter l'adresse me semble abusif.
>>
>
> Ça n'est pas la seule solution. Mais encore une fois, celle (la seule) qui
> me rebute est celle où l'adresse est portée par un point isolé, lié à rien.
>
>
>  En fait une adresse c'est comme un point kilométrique sur une voirie
>> d'accès. C'est bien pour ça que les numéros sont liés à la voirie (cas
>> général). Une parcelle de terrain est proche d'un (ou plusieurs) de ces
>> points, mais là aussi il n'y a pas toujours de lien 1 vers 1
>> adresse/parcelle comme pour les bâtiments. Je pense que c'est pour cette
>> raison qu'on a du mal à se mettre d'accord sur un modèle.
>>
>
> Je pense qu'on commence à bien distinguer les approches. D'un côté, ceux
> pour qui adresse = point d'accès. De l'autre, ceux pour qui adresse =
> emprise incluant (notamment) des bâtiments.
> Je suis pour la 2e approche. Dans le cas d'une habitation sur une
> parcelle, avec une seule adresse associée, on ne peut pas mettre d'adresse
> sur l'emprise, vu qu'on ne trace pas les limites de parcelle dans OSM. Le
> bâtiment est alors la solution de repli, puisqu'il matérialise,
> indirectement, l'existence d'une propriété avec une adresse. On aurait les
> parcelles, c'est bien sûr la parcelle qui porterait l'adresse, bien mieux
> que le bâtiment. On saurait par suite
> - emmener à l'adresse, en combinant les infos d'adresse et la situation du
> point entrance
> - donner la surface bâtie de l'adresse
> - donner le périmètre de la propriété de l'adresse
> - etc
> tout simplement parce qu'on aurait un lien entre les infos d'adresse et ce
> qui se situe à cette adresse.
> J'espère vous montrer avec cet exemple que l'intérêt d'un lien entre
> adresse et emprise physique dépasse le simple besoin de se rendre à une
> adresse, dans une optique de routage.
>
>
>  Le minimum sur lequel on semble plutôt d'accord c'est bien cette notion
>> de position ponctuelle lié à un filaire de voirie... non ?
>>
>
> Là je ne comprends pas ce que tu veux dire, car ça m'évoque la solution
> 3), contre laquelle je suis (= le numéros qui flottent dans le vide).
> Mon impression, si on revient au tiercé d'hier, est que le consensus
> serait plutôt sur la solution 1) : les adresses comme des ponctuels (des
> nodes) qui font partie d'un way, de type amenity, building, landuse, etc.
>
> vincent
>
>
> _______________________________________________
> dev-fr mailing list
> dev-fr at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/dev-fr
>



-- 
Christian Quest - OpenStreetMap France
-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://lists.openstreetmap.org/pipermail/dev-fr/attachments/20140123/c9f880fc/attachment-0001.html>


Plus d'informations sur la liste de diffusion dev-fr