Open jusabatier opened 4 years ago
générer un document attestant de la propriété de cette parcelle
Attention rappel : seul un document notarial / des hypothèques peut établir la propriété d'une parcelle. Tout ce qui sort de cadastrapp est "pour infomation et n'a pas de valeur légale". J'ai veillé à ça il y a qqs mois pour les mentions légales.
Découverte ! J'en ai 10 chez moi.
select * from cadastre_qgis.proprietaire
where ddenom ~ 'BND'
Reste à aller voir la requête qui est jouée maintenant.
Et du coup est-ce que tu as les subdivisions fiscales qui remontent correctement sur les BND ?
Chez nous j'ai constaté qu'elles ne remontaient pas, alors que via l'addon QGis on les voit bien apparaitre.
RP coproprio : vide / ne liste pas cette parcelle
Pour les co-propriétaires, il semblerai que dans Cadastrapp et en base il n'y ai pas de remonté de propriété(s) pour un compte communal d'un des co-propriétaire, pour le cas testé du moins.
Je vais regarder plus dans les bases et dans le plugin pour plus d'infos.
@jusabatier Testé avec la parcelle 4301260000A0061 - 1 propriété non bâtie.
Pour le compte communal du propriétaire BND on a bien une propriété non bâtie qui remonte de la table proprietenonbatie
.
A partir du compte communal d'un des co-propriétaire, il n'y a aucun résultat.
Dans Cadastrapp, c'est cette requête qui est réalisée pour la liste des propriétés (bâtie / non bâtie) pour un compte communal :
select * from cadastre.proprietenonbatie pnb where pnb.comptecommunal = 'xxxxx';
Ensuite on regarde si l'identifiant de la parcelle est dans ce résultat. Ce qui n'est pas le cas. Si on recherche le compte communal pour cette parcelle, c'est bien le propriétaire BND qui ressort. N'ayant pas de résultat pour un de nos co-propriétaire de cette parcelle, le RP n'affichera actuellement aucune propriété. Ce qui est logique vu la requête réalisée face au résultat retourné.
En recherchant le compte communal d'un de nos co-propriétaire dans la table parcelle
, je ne vois pas la parcelle 4301260000A0061 dans les résultats.
Car une fois encore, c'est notre compte communal du propriétaire BND qui est stocké pour cette parcelle.
Les scripts de génération de la table proprietenonbatie
est issue d'une jointure de la table parcelle, ce qui explique que notre table proprietenonbatie
ne nous permette pas de retrouver notre bien non bâti avec le compte communal de notre co-propriétaire.
En passant par le modèle Cadastrapp, on peut retrouver notre parcelle 4301260000A0061 dans la table co_propriete_parcelle
. C'est le compte communal de notre co-propriétaire qui sera là stocké pour la parcelle.
en generant un RP pour toutes les parcelle du copropriétaire, on ne voit pas apparaitre celle du BND dedans
Ce qui explique ce cas également.
On a l'identifiant de la parcelle et le co-propriétaire. Avec une jointure on peut obtenir le propriétaire BND pour cette parcelle et le co-propriétaire en face. Ce qui permet ensuite de réaliser une recherche sur le propriétaire BND dans la table bâti / non bâti afin de pouvoir remonter la propriété dans le cas où nous faisons une recherche via le compte communal du co-propriétaire .
Idem pour la génération d'un BP pour ces parcelles, on a que le propriétaire BND qui remonte dans le pdf et aucun des co-propriétaires.
C'est toujours la table proprietaire_parcelle et non co_proprietaire_parcelle qui est utilisée pour le service /createBordereauParcellaire.
Etant dans l'onglet "propriétaire" pour générer le BP, on peut aussi considérer qu'on ne veut que le propriétaire identifié (le BND) peut être ?
Dans un BP, il n'y a toujours eu que les propriétaires.
Le but recherché au niveau des RP serait que si on le génère à partir de l'onglet propriétaire, on ait le RP du propriétaire, mais il faudrait autant que possible que dans le cas d'un copropriétaire on puisse également générer un RP par l'onglet "copropriétaire".
Ce qui est génant est le fait qu'actuellement au niveau d'un copropriétaire, si on edite un RP, on ne voit pas du tout apparaitre le bien correspondant au BND.
De même pour ce BND, l'onglet subdivision fiscale est complètement vide, alors que via l'addon QGis, on retrouve ces infos, donc elles existent au niveau de la BDD générée par QGis.
alors que via l'addon QGis, on retrouve ces infos, donc elles existent au niveau de la BDD générée par QGis
En effet, dans la table parcelle
du module Qgis, c'est bien le BND qui est lié à la parcelle. Dans la table suf
(subdivision fiscales) ce sont les compte communaux des co-propriétaires.
Pour cet onglet subdivision, c'est la table table proprietenonbatie
qui est interrogée pour avoir les informations.
Pour générer la table proprietenonbati
le script réalise une jointure entre la table parcelle et la table suf
sur le compte communal et l'identifiant de la parcelle.
Si je ne me trompe pas, c'est ce qui ne permet pas de remonter les suf pour le propriétaire BND étant donné que ce compte communal de notre BND est inconnu dans la table suf.
Bonjour,
Aujourd'hui j'ai une de nos mairie qui nous a appelé car elle avait besoin de générer un relevé de propriété sur un bien non délimité (BND).
En allant sur la fiche d'info de la parcelle concernée, on a un seul propriétaire qui est : PROPRIETAIRES DU BND XXXXXXXXX
On retrouve ensuite les noms des propriétaires physiques dans l'onglet copropriétaire de l'addon.
La génération du RP sur le propriétaire fonctionne correctement, en revanche si on essaye de générer le RP depuis un des copropriétaire, celui-ci est vierge. Aussi, en generant un RP pour toutes les parcelle du copropriétaire, on ne voit pas apparaitre celle du BND dedans.
Ceci pose un problème car il est alors impossible de générer un document attestant de la propriété de cette parcelle par le copropriétaire, et de la surface qu'il possède.
Autre souci constaté sur cette parcelle : je ne vois apparaitre aucune subdivision fiscale En passant par le plugin QGis, on en voit apparaitre deux, avec leur identifiant, contenance, type et surface. Il semble donc que cette donnée ne remonte pas correctement dans cadastrapp.
Pour info, les tests ont été fait sur la dernière version de cadastrapp, avec les données MAJIC et EDIGEO de Janvier 2019.
Cordialement