> Encore une fois, code fantoir et adresses sont deux choses > différentes.
A bon? Je comprends pas bien. Le code Fantoir est effectivement un alias des nom de voie, nom de voie qui sont les adresses. Le numéro n'est qu'un élément en plus de l'adresse, mais on peut tres bien avoir comme adresse un voie, sans avoir de numéro, ou pas de voie et juste une pseudo, voie ou un lieu dit, sans numéro ou vaec numéro. Le code FANTOIR c'est justement un élément d'adresse et pas un élément de voirie. L'objectif de FANTOIR ce justement d'établir des liste d'adresse pour pouvoir rapprocher chaque résident entre IRPP et taxe locale, de maniere a éviter les adresse fictive, ou multiple, de les trou dans l'impot foncier et taxe d'habitation etc. Pour cela il faut pour identifier de maniere unique les adresse. Pour les commune c'est facile on a déjà un code INSEE, pour les voies on a donc créée RIVOLI/FANTOIR. Les numéros de rue eux sont naturellement un index a eux seul, meme s'il y a encore des ambiguité de ce coté entre le bis ter, A,B,C ou les communes sans numéros de rue... > Pour éviter de dupliquer le code fantoir, vous allongez > aussi la liste des membres 'street'. Où est le gain ? C'est un probleme logique. D'un coté on a des segment physique de voirie, d'un autre coté on a des élément logique de voirie. Il est intéressant de modéliser ces élément logique, nom, référence, code Fantoir, dans un modele a coté du modele physique justement parce que la réalité logique d'une voie, et assez éloigné de la réalité logique des segment membre en question. > Quand je pense > qu'on me disait que l'impact du tag source=cadastre sur la base était > au final assez négligeable. L'argument de dire qu'on va économiser > quelques octets ici est assez faible. Ce n'est pas un probleme de "poids", c'est un probleme de modele de donnée. On a le meme probleme avec le reférence de voie route antionel numéro machin, département truc. Pour bien faire il faudrait que les segment d'une meme voie au sens de sa référence soit regroupé dans un collection. Reconstruire a posterio la D951 a partir des infos actuel de la base c'est pas évident évident avec les doublons de voie différente ou de meme voie portant la meme référence. Tu me répondras qu'on a qu'a filtrer géographiquement ... mais je vois arriver gros comme une maison des exemples ou cette reconstruction a posteriori va merder. On le fait bien pour les riviere, les voie de chemin de fer, les voies cyclable, j'ai du mal a comprendre pourquoi ca ne se fait pas naturellement pour les voie routière. > Je vais redonner la définition d'associatedStreet : "provide a > connection between housenumber and street.". Rien d'autre. Si vous > migrez le code fantoir, pourquoi ne pas migrer tous les autres tags du > highway: name, ref, oneway, access, etc ? Pourquoi celui-là et pas les > autres ? Restons cohérents. oneway et access sont souvent propre a chaque segments?! seul name et ref est commun a chacune des voie "logique". Il faudrait donc deux collections. Une des nom au sens de l'adresse qui irait naturellement dans associatedstreet, et une des référence "DDE" qui irait dans une relation "associatedroad" ou un sous type de associated street. _______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
