Open jusabatier opened 7 years ago
Bonjour @jusabatier
Est-ce que tu as investigué un peu plus sur ce problème ? Est-ce que les données brutes EDIGEO sont identiques à ce que tu constates en base ?
Je n'ai pas investigué plus loin car je ne sais pas du tout comment sont formattés les fichiers EDIGEO.
Je peux juste dire que le problème est toujours présent à l'heure actuelle suite à l'integration des données de janvier 2019.
Tu peux STP me filer la requête SQL pour regarder ce qu'on a chez nous ? merci.
Je n'ai pas fait de requête SQL.
C'est dans la table geo_tline, je conseille plutôt de regarder via mapfishapp en interrogeant la couche, c'est plus parlant pour localiser un terrain de foot, des bordures de trottoir, etc...
Le champ concerné est geo_sym.
Bonjour @jusabatier ton problème est toujours d'actualité ?
Dans le millesime 2020, j'ai toujours un terrain de foot représenté avec un geo_sym à 23 donc j'aurais tendance a penser que oui.
Bonjour,
En étudiant le rendu d'un import du cadastre sur notre solution SIG, je me suis aperçu que les valeurs geo_sym des élements de la table geo_tline étaient faussées.
Par exemple sur notre export, on a des terrains de foot avec un geo_sym à 23 qui est censé representer des trottoirs et sentiers, et en parallèle on a des trottoirs avec un geo_sym à 62 qui est censé être la valeur des terrains de sport.
Est-ce que d'autres utilisateurs ont constaté le même problème ?
Notre millésime de cadastre est le 2016.
Si ce problème est généralisé, il faudrait peut-être revoir les correspondances entre valeur et libellé de la table geo_sym.
Cordialement