Désolé pour le retard de ma réponse. Je vais essayer de vous donner quelques éléments de réflexion. Après, je suis ouvert à toutes propositions.
Guillaume Allegre wrote > 1) la boundary est une frontière de canton, qui coïncide avec un bout de > la frontière communale > (Orange / Caderousse) > http://www.openstreetmap.org/?way=171243851 mais qui n'est pas confondue > (points distincts) > Selon moi, elle devrait être confondue, en tant que limite communale ET > limite de canton. J'ai demandé à Christian, dans le cadre d'une expérimentation pour l'intégration des bureaux de vote et de la carte électorale, d'importer les données issues de notre SIG. Il s'agit du découpage officiel et utilisé par les services pour leurs missions quotidiennes. On peut comparer ce travail au découpage des zones du document d'urbanisme (PLU), des Servitudes d'Utilité Publique ou des parcelles de la DGFiP (je dis bien de la DGFiP). Par conséquent, ces traçés, même si leur précision n'est pas bonne, est règlementée. Pour info, dans un document d'urbanisme approuvé, si le dessin d'une zone à été mal fait, qu'il coupe une parcelle alors qu'il ne le devrait pas, c'est quand même ce découpage qui est appliqué. Je pense donc, même si ce n'est pas juste, qu'il faut le laisser tel quel si l'on veut que les collectivités s'investissent dans OSM. Elles ne le feront pas si les limites officielles ne correspondent pas, à cette échelle, à ce qu'elles trouvent dans OSM. Guillaume Allegre wrote > 2) le way polling_station a une résolution bien plus élevée (1 point par > mètre dans les courbes), > suivant les _anciens_ méandres de la Meyne, qui restent la limite > communale comme ici : > http://www.openstreetmap.org/?lat=44.08722&lon=4.7789&zoom=17&layers=M > A mon avis, c'est de la sur-résolution inutile, mais ça se discute. > Cela n'enlève rien au point 1 : il faut choisir quelle limite on prend > (171243851 ou 197278529), > voire un intermédiaire en simplifiant la limite polling_station, mais il > faut quand même à terme > fusionner les deux. Même réponse qu'au-dessus Guillaume Allegre wrote > 3) La relation 2649371 a des attributs bizarres : > - pas de nom > - un "CANTON=Ouest" pas documenté > - un "ref=22" pas documenté non plus Effectivement, peut-être que le "ref" peut devenir le "name" Guillaume Allegre wrote > 4) la route http://www.openstreetmap.org/browse/way/195747326 a les > attributs : > highway = road > addr:postcode = |84100 > ref:orange = 84087V999999 > En dehors de la typo sur le code postal avec le |, est-ce logique de > mettre un code postal > sur une voie ? le wiki ne donne qu'un noeud ou une surface, et j'aurais > tendance à le suivre > sur ce point. J'ai pris le parti d'ajouter addr:postcode = 84100 sur les voies qui se trouvent dans la commune, en attendant d'avoir un outil qui me permette de sélectionner tous les objets présents à l'intérieur d'une frontière administrative. Le fait qu'elles aient |84100 veut dire qu'elles se trouvent en partie sur le territoire (pas forcément gauche et droite) et que je dois faire attention quand je les intègre. Guillaume Allegre wrote > Ensuite : ref:orange : là, je pense qu'on a un problème à régler. "orange" > n'est pas suffisamment > distinctif. Si toutes les communes du monde se mettent à utiliser le même > schéma, on va multiplier > les conflits. Comment régler ça ? L'objectif est de pouvoir faire un lien systématique entre la voie dans OSM et celles dans la base communale. J'ai mis, à l'époque, ref:orange parce qu'il n'y avait rien de similaire et qu'il s'agit d'une réflexion que l'on mène sur plusieurs communes du Vaucluse. S'il faut changer de clé, cela ne me pose pas de problème mais il faut savoir que cela concernera d'abord les communes et non l'INSEE. On m'avait suggéré ref:84087, mais je trouvais cela redondant car dans mon identifiant,il y a déjà le code INSEE. De plus, c'est quelque chose qui peut se diffuser sur d'autres communes et nous aurions des tags ref:84087, ref:75001, ref:13205, etc... Il faudrait plutôt un tag du type ref:FR:commune= ou dans le genre. Guillaume Allegre wrote > Je ne remets pas en cause l'utilisation d'OSM comme support de données > métiers issues > de SIG territoriaux, bien au contraire. > Mais si, comme je le suppose, Orange tend à devenir une zone d'exemple et > de démonstration > pour cette convergence, il serait préférable que le schéma suivi soit > aussi > irréprochable que possible quant à l'intégration dans les conventions > standard OSM. > Alors, je pense qu'il faut sérieusement se pencher sur : > - le schéma d'attributs et de références qui conviendrait à tout le monde > - les conventions de fusion ou juxtaposition de données, et les précisions > géométriques > minimales/maximales acceptables. Je suis d'accord et je veux bien y participer -- View this message in context: http://gis.19327.n5.nabble.com/experimentations-a-Orange-tp5755270p5755816.html Sent from the France mailing list archive at Nabble.com. _______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
