oke merci.
Le 19 octobre 2010 21:15, Denis <dhel...@free.fr> a écrit : > Le 19/10/2010 18:40, alexis gayte a écrit : > >> bonjour, >> >> >> on peut remarquer que si l'on prend 2 communes du le cadastre leurs >> limites ne sont pas superposées. >> peut on, doit on , le signaler au autorité compétente ? car je suppose que >> meme pour eux cela doit poser des problèmes non ? >> >> > C'est probablement même une règle générale, malheureusement. > L'unité maximale de travail de la DGFiP est la commune. A ses yeux, c'est > un ilôt. Cela veut dire que les règles de topologie (superposition des > différents composants) ne s'appliquent qu'à l'intérieur de la commune. Ainsi > les parcelles forment les sous-section (feuilles cadastrales) qui forment > les sections qui forment la commune. A noter aussi que les parcelles forment > les lieux-dit qui sont donc aussi des polygones topologiquement connectés. > Il est arrivé récemment (à l'échelle de notre bicentenaire cadastre) > l'avénement des SIGs, des regroupements de communes (EPCI, Communautés > urbaines et al.) qui a conclu à l'extension du territoire de compétences, au > nécessaire établissement d'un continuum géographique. > Face à ce défi, les services cadastraux ont édicté des règles de calage > entre "limes" (limites de l'Empire) avec des calculs de tolérence d'erreur > acceptable dont l'administration fiscale a le secret et dont la pudeur (et > le manque d'énergie) m'empêchent d'évoquer le moindre commencement > d''explication sur cette liste. > Face à ce défi, l'IGN a établi, sur la base des données cadastrales, > -mais hors de toute obligatoire règlementaire ou statutaire- les limites > communales figurées sur le scan25, puis transformé en BD Carto, puis en BD > Topo/Pays. > Face à ce défi, OSM est en train d'établir une base contradicoire des > limites communales françaises. > > <abstract> > Oui, c'est normal que les limites communales ne se superposent pas. > Non, ce n'est pas utile de signaler à l'administration fiscale cet état de > fait. > Oui cela peut leur poser problème, mais ce n'est pas la vocation d'OSM, > AMHA, d'intervenir dans un mécanisme qui n'est pas de notre ressort. > </abstract> > > Denis > > > _______________________________________________ > Talk-fr mailing list > Talk-fr@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-fr > -- Cordialement, alexis GAYTE
_______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
