Re: [OSM-talk-fr] [OpenStreetMap] Re: Re: Gros problème de correction... Groupe de modifications : 28377712
Bonsoir, Le 11/02/2015 16:28, Philippe Verdy a écrit : Mais en fin de compte puisque ton identifiant utilise un numéro Insee de commune française qui en est à la source, - pourquoi pas "ref:FR:x = Vnn", où x est le code commune à 5 chiffres ? - ou bien ref:FR:x=Vnnn", où "x" est le code SIREN de l'entité qui l'a défini, - ou bien "ref:FR-dd:CCXXX = *" où "CCXXX" est l'abréviation en lettres de l'EPCI et dd est le numéro de département de sa commune siège (donc "ref;FR-87:CCPRO = *" pour ta communauté de communes, puisque "FR-dd" est un code ISO 3166 valide comme l'est aussi "FR"). Au moins avec ref:FR=* on sait que c'est discuté en France, et documenté en français (pas sûr pour autant que nos amis belges ou canadiens nous ait suivi adns le détail, Allez, soyons fous : un des schemas ci-dessus emporte l'adhésion, et est massivement propagé. On se retrouve avec, disons, une centaine de collectivités qui l'adoptent. Résultat, une centaine de tags ref:FR: distincts, stockant chacun des valeurs pour la même notion : un identifiant unique. Et maintenant, un consommateur de données OSM veut appréhender ces données à l'échelle de la France, en exploitant ces identifiants, par exemple pour les afficher sur une carte. Donc une centaine de colonnes distinctes dans une BD, rien que pour récupérer toutes les valeurs des différents émetteurs. Des colonnes vides à 99% évidemment, puisque chacune n'est utilisée que sur un tout petit périmètre géographique. Tout ça fait une donnée très pénible à exploiter, car explosée artificiellement dans différents tags (osm) ou colonnes (de BD relationnelle). Vous voulez faire des stats ? Accrochez-vous... En bref : je suis contre les noms de tags à composante géographique à une maille aussi fine qu'une collectivité territoriale. Pour moi on ne devrait pas descendre en dessous du pays dans les espaces de nom, donc ref:FR ici. Et, ça a été rappelé par Fred, un simple tag local_ref permettrait souvent de s'en sortir. KISS*, comme disait l'autre. vincent * http://fr.wikipedia.org/wiki/Principe_KISS ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Le cadastre vectoriel est accessible en WMS
Le Tue, 10 Feb 2015 17:07:49 +0100,
"lenny.libre" a écrit :
>
> Le 01/02/2015 18:20, Frédéric Rodrigo a écrit :
> > Le 01/02/2015 16:54, Vincent de Château-Thierry a écrit :
> >> Bonjour,
> >>
> >> Jusqu'à présent pour visualiser le cadastre vectoriel, il fallait
> >> utiliser le plugin Cadastre-Fr. Depuis quelques jours, une
> >> alternative apparaît, à l'initiative de la DGFiP. En effet, elle
> >> vient de rendre public son service WMS : le cadastre accessible en
> >> tuiles, directement par le producteur.
> >>
> >> La documentation est ici :
> >> https://www.cadastre.gouv.fr/scpc/aide.do#
> >> => rubrique "Votre service WMS"
> >>
> >> et pour vos réglages JOSM, voici un exemple de ligne à déclarer
> >> (F12 > rubrique 'TMS/WMS') :
> >> wms:http://inspire.cadastre.gouv.fr/scpc/<*code
> >> INSEE*>.wms?service=WMS&request=GetMap&VERSION=1.3&CRS={proj}&WIDTH={width}&HEIGHT={height}&BBOX={bbox}&LAYERS=BU.Building,AMORCES_CAD,CP.CadastralParcel,HYDRO,BORNE_REPERE,DETAIL_TOPO,LIEUDIT,VOiE_COMMUNICATION&STYLES=&FORMAT=image/png
> >>
> >>
> >>
> >>
> >> Il faut adapter 2 éléments de la requête :
> >> - la chaîne '<*code INSEE*>' est à remplacer par les 5 caractères
> >> du code de la commune qui vous intéresse.
> >> - la liste des thèmes affichés (après 'LAYERS=') : cette liste est
> >> modulable selon ce qui vous intéresse.
> >>
> > Pour que ça marche il ne faut pas passer par le wizard de JOSM
> > qui modifie les paramètres lui même.
> >
> > Utiliser directement l'URL que a donné Vincent.
>
> Je n'arrive pas au résultat, j'ai des erreurs, voici ce que j'ai
> fait :
> - "Préférences" / "Paramètres d'imagerie" / "Fournisseurs actifs"
> - clic sur le "+ WMS"
> - dans la zone "Entrez l'URL du service"
>
> avec Brocas, j'ai une erreur dés la recherche
> http://inspire.cadastre.gouv.fr/scpc/40056.wms?service=WMS&request=GetMap&VERSION=1.3&CRS={proj}&WIDTH={width}&HEIGHT={height}&BBOX={bbox}&LAYERS=BU.Building,AMORCES_CAD,CP.CadastralParcel,HYDRO,BORNE_REPERE,DETAIL_TOPO,LIEUDIT,VOiE_COMMUNICATION&STYLES=&FORMAT=image/png
>
>
> En cliquant sur "Obtenir les calques"
>
>
> avec Beauzelle 31056
> http://inspire.cadastre.gouv.fr/scpc/31056.wms?service=WMS&request=GetMap&VERSION=1.3&CRS={proj}&WIDTH={width}&HEIGHT={height}&BBOX={bbox}&LAYERS=BU.Building,AMORCES_CAD,CP.CadastralParcel,HYDRO,BORNE_REPERE,DETAIL_TOPO,LIEUDIT,VOiE_COMMUNICATION&STYLES=&FORMAT=image/png
> Il prend en compte
>
> Puis j'ai une erreur et écran rouge
>
> Même chose avec
> http://inspire.cadastre.gouv.fr/scpc/33119.wms?service=WMS&request=GetMap&VERSION=1.3&CRS={proj}&WIDTH={width}&HEIGHT={height}&BBOX={bbox}&LAYERS=BU.Building,AMORCES_CAD,CP.CadastralParcel,HYDRO,BORNE_REPERE,DETAIL_TOPO,LIEUDIT,VOiE_COMMUNICATION&STYLES=&FORMAT=image/png
>
>
>
> cordialement
> Lenny
>
Il faut mettre directement l'adresse dans le champ Vérifier l'URL WMS
générée. Donc pour Brocas, ça donne :
wms:http://inspire.cadastre.gouv.fr/scpc/40056.wms?service=WMS&request=GetMap&VERSION=1.3&CRS={proj}&WIDTH={width}&HEIGHT={height}&BBOX={bbox}&LAYERS=BU.Building,AMORCES_CAD,CP.CadastralParcel,HYDRO,BORNE_REPERE,DETAIL_TOPO,LIEUDIT,VOiE_COMMUNICATION&STYLES=&FORMAT=image/png
Tu donnes un titre au calque (Cadastre)
Tu télécharges les données OSM de Brocas qui t'intéressent et tu lance
le calque Cadastre (Imagerie/Cadastre)
Lann
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [OpenStreetMap] Re: Re: Gros problème de correction... Groupe de modifications : 28377712
Vu la façon dont tu le décrit, même si le tag vient d'une commune, son usage étant intercommunal, il aurait été plus explciite de mettre "ref:FR:intercom=*" si tu veux généraliser, "intercom" pouvant signifier "iintercommunal" (plusieurs communes) ou "intercommunalité" (EPCI), ou "intercommunication", ou encore "ref:street:local=" puisque cela concerne uniquement le linéraire et pas forcément tout ce qui touche géométriquement l'objet qui peut y être collé. Cependant se passer de "FR:" serait dangereux, pour peu qu'un autre pays se décide à utiliser ce même tag et l'utiliser selon ses propres règles (ils ne sont pas au courant de cette discussion et il ne faudra pas se plaindre en cas de conflit d'usage. Mais en fin de compte puisque ton identifiant utilise un numéro Insee de commune française qui en est à la source, - pourquoi pas "ref:FR:x = Vnn", où x est le code commune à 5 chiffres ? - ou bien ref:FR:x=Vnnn", où "x" est le code SIREN de l'entité qui l'a défini, - ou bien "ref:FR-dd:CCXXX = *" où "CCXXX" est l'abréviation en lettres de l'EPCI et dd est le numéro de département de sa commune siège (donc "ref;FR-87:CCPRO = *" pour ta communauté de communes, puisque "FR-dd" est un code ISO 3166 valide comme l'est aussi "FR"). Au moins avec ref:FR=* on sait que c'est discuté en France, et documenté en français (pas sûr pour autant que nos amis belges ou canadiens nous ait suivi adns le détail, Le 10 février 2015 13:31, Tony Emery a écrit : > Bon, on peut relancer le débat sur le nom du tag et les caractères et > comment > on les mets > > Il s'agit du parti pris que l'on a pris localement pour "harmoniser" nos > bases de données entre Orange, Avignon et les intercommunalités > correspondantes. Pour le coup, on ne réfléchit pas que dans le stricte > cadre > d'OpenStreetMap. Dans notre Base de données, cet identifiant s'appelle > ID_Interne. > > Donc, pour le nom du tag, à l'origine, j'avais ref:orange mais c'était pas > bon pour x raisons. > Vu que c'est un tag qui est, pour le moment, français, on (les > contributeurs > OSM) était parti sur un "ref:FR". > Et vu qu'il s'agit d'un identifiant issu des communes, on a mis > "ref:FR:commune". > Après on peut toujours dire que les bases de données voiries peuvent être > intercommunales, mais elles ne le sont pas toutes et le plus petit > dénominateur commun est, justement, la commune. > > Après, dans les nombreux projets dont l'objectif est d'harmoniser et de > normaliser les données (je vous renvoi à la directive européenne INSPIRE), > les champs attributaires sont le plus contraignants possibles pour éviter > les erreurs de saisie. Donc, on fixe le plus possible un nombre de > caractères pour être sûr de ne pas en oublié un ou d'en mettre un en trop. > > Enfin, pourquoi rajouter des "-" ou des "_" vu que c'est un identifiant et > qu'on n'a pas besoin de lui faire raconter une histoire ? Après tout, le > code FANTOIR marche comme ça, les identifiants parcellaires aussi... > > > > > > - > Tony EMERY > Administrateur OpenStreetMap.fr > Mandataire Grand Sud-Est > Géomaticien & chef de projets > -- > View this message in context: > http://gis.19327.n5.nabble.com/Re-OpenStreetMap-Re-Re-Gros-probleme-de-correction-Groupe-de-modifications-28377712-tp5832528p5833055.html > Sent from the France mailing list archive at Nabble.com. > > ___ > Talk-fr mailing list > Talk-fr@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-fr > ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Mettre à jour la carte d'une commune
Pour ceux qui en doutent en voyant que l'imagerie Bing affiche encore un batiment, il est préférable pendant un temps de transformer "building=*" en "destroyed:building=*" (oui avec aussi une note sur la date de destruction connue ou constatée sur place). Tant qu'il n'y aura pas autre chose reconstruit à la place (et tant que c'est juste un chemin ou une route qui passe au milieu), ce polygone peut rester là, il ne devrait pas gêner beaucoup. Ce n'est que si les imageries Bing et Google, et le cadastre, sont mis à jour et montrent bien la disparition qu'on pourra supprimer ce polygone résiduel qui ne risque plus de revenir. Si le polygone revient (quelqu'un remet le tag "building=*") qu'on peut mettre en plus en URL d'une photo datée et signée, postée sur un site de partage de photos libres, avec une petite explication. Le 5 février 2015 20:01, Christian Quest a écrit : > Le 05/02/2015 10:28, Ludovic Hirlimann a écrit : > > Bonjour, > > > > j'édite depuis peut-être un mois la commune où je viens d’emménager afin > d'y > > ajouter les commerces et services. Je me suis rendu compte qu'il y avait > des > > manques sur la carte OSM - et des bâtiments qui n'existent plus. Quelle > est > > la meilleur marche à suivre pour ajouter le bout de route manquant > ,enlever > > les bâtiments détruit et mettre à jour la carte ? Je suis preneur d'un > petit > > cours pour pouvoir le faire (même si après avoir brièvement lu le guide > > d'import du cadastre je suis beaucoup moins chaud). > > > > Ludovic > > ps la commune en question est Grisolles (82170) > > > > > Si un bâtiment présent sur OSM n'existe plus sur le terrain... et bien > il suffit de le supprimer ! > tu peux aussi conserver le polygone, retirer le tag building et mettre > une note=* pour indiquer que le batiment n'existe plus pour éviter qu'il > ne soit recréé par quelqu'un à partir d'une source qui n'est pas à jour > (cadastre, image aérienne). > > Ajouter un bout de route manquant ? Euh... il suffit de l'ajouter avec > les outils d'édition habituels (en ligne: iD, hors ligne: JOSM). > > -- > Christian Quest - OpenStreetMap France > > > ___ > Talk-fr mailing list > Talk-fr@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-fr > ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Contours des communes dans le Gard
Les contours plus épais que d'autre viennent de l'attribut admin_level présent sur les chemins (c'est lui qui est utilisé et non les diverses valeur de admin_level=* pour les différentes relations qui l'utilisent. Mais comme tu as jugé (à tord) que c'était redondant et décidé de les virer, ces ways n'ont plus le marquage correct. Le résultats c'est comme la frontière de la Chine: plein de trous dans tous les rendus Mapnilk ! Il est très délicat de gérer les styles à donner aux frontières, surtout quand il y a des relations qui sont contradictoires entre elles sur leur valeur donnée à admin_level. Normalement la valeur à utiliser sur les ways devrait être la plus petite des valeurs présentes dans les relations parentes du way et c'est ellle alors qui fixe le style principal de la frontière. Mais au plan inernational il y a des conflits de niveaux entre les pays et ça ne marche pas bien s'il y a des conflits territoriaux entre deux pays (ou un territoire partagé par les deux pays) : dans ce cas l'admin_level 2 sera remplacé par un admin_level 2 seulement dans un seul pays frontalier, mais pas dans l'autre (qui peut n'y voir aucune frontière administrative ou bien une frontière régionale/provinciale/districtale/communale/ Comme on ne peut pas dessiner sur la carte une frontière internationale commune, il reste alors à adopter un admin-level plus grand autout du territoire contesté, ce qui interrompt la frontière internationale visible (mais seulement dans de rares petites zones du monde) En France il n'y a aucun conflit territorial reconnu par l'Etat (et toutes les collecvités y sont soumis, elles ne peuvent décider elles-même d'un changement de frontière sans l'aval du préfet au nom du ministère de l'Intérieur, et du Conseil d'Etat voire du Conseil constitionnel en cas de désaccord par une partie, et une publication de l'arrêté préfectoral ou interpréfectoral au JORF). Il y a juste une petite île sur un fleuve de la frontière franco-espagnole : l'ile passant tous les 6 mois d'un pays à l'autre, le tracé dans OSM peut passer arbitrairement au milieu mais pourrait avoir une superposition de l'Espagne et de la France autour de cette île, dont les ways frontières n'auront pas la valeur 2 mais une valeur 9 ou 10 (supérieur au plus grand niveau des relations administratives françaises et espagnoles. Dans le cadastre des deux pays, cette île est intégrée au pays, mais séparée des communes avec une frontière admin de chaque côté (mais pas la même entre la France et l'Espagne. Il y a encore le cas du partage franco-espagnol du Golfe de Gascogne (une zone où aucun des deux pays n'a la territorialité exclusive). Même au sein de l'Espagne seulement il y a (notamment en Navarre) des communes qui se partagent des territoires communs; le cadastre espagnol n'attribue ce territoire ni à l'une ni à l'autre, mais en fait des quasi-communes (mais sans administration locale : ce sont des forêts, prairies et les communes en possèdent la propriété sous forme de parts de capital dans une société publique hors juridiction des deux communes, mais sous juridication de l'Etat ou de la province, collectant les revenus des terres et coupes d'arbe, et finançant les travaux d'entretien et de surveillance). Les statstiques nationales espagnoles listent les comptes et données de ces territoires (officiellement inhabités de façon permanente et n'ayant aucun électeur) à part des communes Cette co-terriorialité est une vieille tradition basco-navaraise depuis le moyen-âge où les paysans et seigneurs de plusieurs "comarques" (groupements de villages, devenus groupements de communes, mais parfois encore à cheval entre deux provinces) s'étaient mis d'accord pour avoir chacun un droit d'usage partagé, et le cas de la frontière franco-espagnole hérite de cette vielle tradition basco-navaraise. D'autres pays ont aussi des cas de co-territorialité (par exemple entre Chili et Argentine, pour une immense réserve d'eau au milieu des Andes à cheval sur leur frontière). Il est même question d'en créer en Méditerranée (où il n'y a pas encore de zones exclusives) pour faire des réserves naturelles partagées par plusieurs pays, mais les négociations trainent encore (notamment car étendre les eaux territoriales et zones exclusives ne plait pas à des pays dont les eaux territoriales se trouveraient enclavées (et notamment cela ne plait pas du tout à la Russie qui met son veto pour garder un large accès à la Méditerranée et l'Atlantique, et dans les détroits du Bosphore et de Gibraltar, mais aussi dans le détroit de Malte entre les eaux italiennes et tunisiennes). Les Britanniques ont aussi leur cas particulier avec l'Espagne à Gibraltar, ou avec les deux Etats de de Chypre. L'Egypte et le Nord-Soudan revendiquent chacun un territoire commun (sur la base de deux traités différents) mais cette revendication maximale des deux ne couvre pas un petit triangle de désert qui n'est revendiqué par personne: prendre la territorialité de ce triangle aboutira
Re: [OSM-talk-fr] Ajouter le rendu OSM France au site OSM international?
En fiat, mon idée était surtout de permettre aux personnes qui seront présentes au prochain SOTM et qui ne sont pas forcément à l'aise avec l'infrastructure informatique de comprendre le fonctionnement d'OSM et les enjeux qui sont derrière. Ton schéma est sûrement compréhensibles pour des informaticiens mais je t'assures que c'est autrement plus compliqué pour les autres de comprendre. D'où mon "Mais un truc simple à la Fred et Jamie dans "C'est pas Sorcier"", avec des dessins et des noms qu'on connait. Par exemple dans ton schéma, où est le site OpenStreetMap.org ? il y est, mais on ne le voit pas assez alors que c'est ce qui devrait sauter aux yeux. - Tony EMERY Administrateur OpenStreetMap.fr Mandataire Grand Sud-Est Géomaticien & chef de projets -- View this message in context: http://gis.19327.n5.nabble.com/Ajouter-le-rendu-OSM-France-au-site-OSM-international-tp5832979p5833140.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
