Si on commence à parler de vandalisme, le problème est nettement plus élevé
sur Wikipédia où il sévit fortement, que sur OSM où le vandalisme est très
vite remarqué (sauf pour d'obscurs éléments peu connus dans des recoins
reculés : moins ils sont connus, moins il est tentant de les vandaliser car
Concernant Wikipédia (version française), comme il utilise son propre
moteur de rendu (sur le Toolserver) c'est sur ce serveur qu'une
amélioration est nécessaire aussi (mais je ne pense pas que Wikipédia fassr
quoi que ce soit pour l'instant car l'urgence c'est de migrer les outils du
Toolserver ve
Le 12 juin 2013 16:41, Christian Quest a écrit :
> Il ne faut pas confondre non plus l'erreur dans les données et
> l'erreur dans l'exploitation des données.
>
> Le cas du "Rouen" qui s'affiche là où il ne devrait pas fait
> semble-t-il partie du second cas.
>
> C'est sûr que la qualité des donné
Il ne faut pas confondre non plus l'erreur dans les données et
l'erreur dans l'exploitation des données.
Le cas du "Rouen" qui s'affiche là où il ne devrait pas fait
semble-t-il partie du second cas.
C'est sûr que la qualité des données OSM ne peut être garantie, mais
elle est quand même d'un bon
Le 12 juin 2013 13:35, Philippe Verdy a écrit :
> Ton problème d'affichage de "Rouen" sur le rocher de Tombelaine n'est PAS
> une erreur des données mais de l'interprétation que tu en fais et
> d'incompréhension.
>
>
Bin dis donc !
> [couic]
> Ne confonds donc pas les problèmes, et ne va pas "
Ton problème d'affichage de "Rouen" sur le rocher de Tombelaine n'est PAS
une erreur des données mais de l'interprétation que tu en fais et
d'incompréhension.
Il fait partie d'une commune fiasant partie de l'évêché de Rouen. Mais le
problème de rendu sur d'OSM.org est lié au fait qu'il ne sait fai
Le 12/06/2013 12:24, Ista Pouss a écrit :
Non, je pense que la fiabilité n'est pas aussi claire qu'on peut le
penser.
Par exemple dans un de mes précédents post, j'ai remarqué que le
rocher de tombelaine pouvait se nommer "Rouen" sur OSM, alors que
cette ville est quand même à plusieurs ce
Le 11 juin 2013 16:10, Nicolas Moyroud a écrit :
>
> - OSM est à la foi connu et méconnu sur wikipedia, il me semble. Il y a
>> des gens qui aiment bien mais aussi beaucoup de partis pris, souvent
>> étonnant de la part de wikipédiens, du style "Mais si tout le monde peut
>> modifier la carte alo
Au temps pour moi, Bruno n'avait pas donné le lien vers le bon Bages. Le
mien c'est celui de l'Aude pas des Pyrénées-Orientales :
http://openstreetmap.fr/outils/etat-commune?insee=11024
J'obtiens bien la même valeur avec QGIS. Ouf ! ;-)
Ça me fait penser à un truc. Puisque tout ceci est déjà cal
Le 11/06/2013 15:57, Christian Quest a écrit :
C'est calculé par PostGIS avec un ST_Area(ST_Transform(way,2154)) à
partir du polygone OSM sauf il y n'existe pas et dans ce cas c'est
GEOFLA (que Freed a mis à jour, donc maintenant les scripts s'appuient
sur GEOFLA2013).
Euh ce n'est pas du tout
Le 11/06/2013 15:25, Ista Pouss a écrit :
Solution 0 : tu fais les modifs.
Solution 1 : tu t'inscris, tu les fais.
Euh faire à la main les 36XXX communes de France je sais pas pourquoi
mais je le sens pas ! ;-)
Si on leur propose un jeu de données prêt à intégrer ils pourraient
peut-être fair
Le 11 juin 2013 12:00, Bruno Cortial a écrit :
>
> Le formulaire osm.fr semble indiquer la bonne superficie, mais est-elle
> basée sur le polygone OSM ?
> http://openstreetmap.fr/outils/etat-commune?insee=66011
>
C'est calculé par PostGIS avec un ST_Area(ST_Transform(way,2154)) à
partir du polygo
Le 11 juin 2013 13:14, Nicolas Moyroud a écrit :
> Ce serait peut-être bien de leur proposer de recalculer tout ça à partir
> des données OSM. Ils pourraient afficher la superficie totale + la
> superficie des terres émergées. Quelqu'un aurait un contact chez eux pour
> leur proposer cette idée ?
Lisez aussi l'article suivant :
http://acign.blog.free.fr/index.php?post/2013/05/19/Superficie-de-la-Gironde-Pas-si-simple...
qui explique que c’est la somme des surfaces « hors eaux » des
sections cadastrales qui a servi pour le calcul des superficies par la
DGI dans les années 1970 et reprises p
2013/6/11 Nicolas Moyroud :
> Je trouve quand même qu'ils sont un peu légers sur wikipédia
Il n'y a pas qu'eux. Je n'ai pas trouvé sur le site de l'insee leur
source pour les surfaces communales. IGN ? cadastre ? Avec ou sans
lacs ? avec ou sans domaine public ? somme des parcelles ?
Le seul truc
Je trouve quand même qu'ils sont un peu légers sur wikipédia concernant
le sens des chiffres superficie et densité de population. Franchement
quand je vois ça écrit comme ça pour moi c'est la valeur de la
superficie totale des communes et densité calculée sur la superficie
totale. Or ce sont le
Et hop, petite précision ajoutée sur wikipédia :
http://fr.wikipedia.org/wiki/Superficie#Superficie_des_entit.C3.A9s_administratives_fran.C3.A7aises
Ça évitera au prochain de se prendre la tête sur la même chose. ;-)
Nicolas
___
Talk-fr mailing list
Le 11/06/2013 12:24, Sylvain Perrinel a écrit :
Oui je crois que l'INSEE et GeoFLA ne prennent en compte que les
terres immergées.
D'où cette différence...
Non d'après ce que je vois la source INSEE ne prend en compte que les
terres émergées, mais pour la source GEOFLA c'est bien l'ensemble d
Ah oui pas bête j'avais pensé à la mer, mais pas aux étangs.
Effectivement il y a bien cet effet de concentrations des erreurs dans
le coin des étangs !
Enfin bon pour ce qui intéresse SIG-LR, c'est la valeur étang compris
qu'on va retenir. Du coup tout va bien avec la méthode de calcul que
j'a
superficie ?
>
> franckG
>
> --
> *De: *"Nicolas Moyroud"
> *À: *"Discussions sur OSM en français"
> *Envoyé: *Mardi 11 Juin 2013 11:39:56
> *Objet: *[OSM-talk-fr] Erreurs importantes concernant la superficie
> descommune
Ah merci Brice je ne savais pas que dans le GEOFLA c'était la valeur de
la surperficie avant simplification du polygone.
Bilan : les grosses erreurs semblent venir de la source wikipédia.
Pourtant j'ai trouvé exactement les mêmes valeurs sur d'autres sources
comme par exemple annuaire-des-mairie
La suppression des îles et enclaves peut donner des différences
importantes... Pas bon, donc.
Les traits de côtes ont aussi pu changer avec les lois du littoral
(contestées par certaines communes, leur cadastre peut ignorer pas mal de
choses au plan légal).
Le 11 juin 2013 12:03, Brice Person a
Différences entre terres émergées (hors mer, lacs, fleuves) et territoire
total (très variable selon les définitions des traits de côte, et si des
fleuves servent de frontière physique entre communes, selon qu'on prend la
moitié du cours d'eau ou pas) ?
A priori les surfaces devraient être telles
Juin 2013 11:39:56
Objet: [OSM-talk-fr] Erreurs importantes concernant la superficie des communes
de l'Aude
Bonjour à tous,
L'association SIG-LR souhaiterait publier sur son portail le jeu de
données sur les communes du Languedoc-Roussillon extrait depuis OSM. Du
coup depuis hier je
A noter que le champ "SUPERFICIE" du Geofla peut aussi servir à comparer
puisque d'après sa description :
Type : entier
Superficie de la commune en hectares. C'est la somme des surfaces des
faces BD CARTO®
composant la commune (avant allégement géométrique et suppression des
îles et enclaves).
Le formulaire osm.fr semble indiquer la bonne superficie, mais est-elle
basée sur le polygone OSM ?
http://openstreetmap.fr/outils/etat-commune?insee=66011
Bruno
Le 11 juin 2013 11:57, Nicolas Moyroud a écrit :
> J'étais en train de le faire au moment même de l'envoi de ton mail. :-)
> Pas de d
J'étais en train de le faire au moment même de l'envoi de ton mail. :-)
Pas de différence majeure sur les communes incriminées... Je commence
vraiment à avoir des doutes sur l'algo de calcul des superficies de QGIS
! Je vais tester tout ça avec PostGIS pour voir ce que ça donne.
Nicolas
Le 11
Une superposition avec Geofla pour localiser rapidement des grosses
différences ?
Le 11 juin 2013 11:39, Nicolas Moyroud a écrit :
> Bonjour à tous,
>
> L'association SIG-LR souhaiterait publier sur son portail le jeu de
> données sur les communes du Languedoc-Roussillon extrait depuis OSM. Du
Bonjour à tous,
L'association SIG-LR souhaiterait publier sur son portail le jeu de
données sur les communes du Languedoc-Roussillon extrait depuis OSM. Du
coup depuis hier je suis en train de tester les données OSM sur les
communes de l'Aude. J'ai notamment réalisé avec QGIS un reprojection e
29 matches
Mail list logo
