Re: [OSM-talk-fr] Comment faire? forêt broadleaved & needleleaved

[David Marchal via Talk-fr]

Ça risque de faire foirer le rendu, je pense : le motif « arbresque » des 
forêts va s’afficher deux fois, bonjour le rendu crade…

Cordialement.

Gesendet mittels einer sicheren E-Mail von Proton Mail.

--- Original Message ---
pepilepi...@ovh.fr  schrieb am Donnerstag, 8. September 
2022 um 18:17:


> Le 08/09/2022 à 17:49, Jérôme Amagat a écrit :
> > 
> > J'allais faire la même remarque, la relation type=site est une mauvaise
> > idée. C'est à utiliser seulement si ce n'est pas possible de le représenter
> > sous forme surfacique. Ici c'est surfacique donc pas de raison de
> > l'utiliser. Pour moi la moins mauvaise des solutions c'est
> > un (multi)polygon landuse=forest pour toutes la forêt et d'autres
> > plus petit avec aussi landuse=forest et leaftype= *
> 
> 
> 
> C'est pas interdit, ça, mettre le même tag sur le multipolygone et un de
> ses éléments ?

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Comment faire? forêt broadleaved & needleleaved

[David Marchal via Talk-fr]

Salutations, Marc.

Je me doutais bien que je m’attirerais tes foudres en parlant de ce tag ;-) Je 
crains toutefois qu’il n’y ait confusion : si je comprends bien ta réponse, 
pour toi, boundary=forest sous-entend que la zone est exploitée, or ce n’est 
pas le cas. C’était bien le cas pour la deuxième itération de ma proposition, 
mais pas pour la troisième, celle qui a été approuvée, précisément parce que 
mélanger des limites de forêt et un landuse était inacceptable pour nombre de 
contributeurs, dont toi, et avec raison.

boundary=forest, tel qu’approuvé, ne fait que désigner une emprise de forêt, 
qu’elle soit exploitée ou non, boisée ou non, et accepte tout à fait que des 
zones soient exploitées et d’autres non. Elle correspond, en fait, à ce que la 
plupart des gens désignent par "Forêt de Fontainebleau", par exemple : une zone 
essentiellement boisée avec des limites définies. Comme une telle forêt n’est 
pas nécessairement intégralement boisée ou même intégralement exploitée, je 
n’ai pas trouvé mieux que découplér sa représentation des 
landuse=forest/natural=wood. De plus, boundary=forest tel qu’approuvé me semble 
correspondre aux besoins de Marc Mongenet.

Imparfait et plus complexe ? Sans doute. Ça rajoute de la confusion ? Tout à 
fait, car ça ajoute aux pratiques existantes sans rien en supprimer. Toutefois, 
pour représenter une forêt au sens décrit ci-dessus, je n’ai pas trouvé mieux, 
et je ne sache pas qu’une autre proposition ait emporté assez de suffrages pour 
être approuvée, donc, même si c’est imparfait, ça fait le boulot, et ça a 
rencontré assez d’approbation pour un vote fructueux. Je pense donc, mais je 
peux me tromper, que ce n’est pas si mauvais que ça.

Cordialement.

Gesendet mittels einer sicheren E-Mail von Proton Mail.

--- Original Message ---
Marc_marc  schrieb am Montag, 5. September 2022 um 08:53:


> Bonjour David,
> 
> Le 05.09.22 à 07:19, David Marchal via Talk-fr a écrit :
> 
> > C’est précisément pour ce genre de cas que j’avais conçu le tag 
> > boundary=forest
> 
> 
> tu sais bien que pour moi ce tag est un abération qui ne fait
> que rajouter de la confusion
> si on veux tager un landuse, la bonne clef est... landuse
> et non boundary
> 
> > un (multi)polygone type=boundary + boundary=forest + name=… pour 
> > représenter le fait que l’ensemble est une seule et unique forêt,
> 
> 
> ton utilisation est encore pire que ce qui a été voté !
> 
> la surface de "foret de ABC" n'est pas la même que la surface
> de l'exploitation forestière
> il suffit d'un étang, une place Pique-nique au milieu de cet endroit :
> il est compris dans la foret de ABC, mais personne n'utilise l'endroit
> pour la sylviculture
> 
> donc ce tag mal connu ne résout pas le soucis ici,
> puis le soucis c'est : quel tag principal pour un endroit
> composé de différente espace d'arbre, de zone ou pas
> exploité en sylviculture, etc
> 
> Cordialement,
> Marc
> 
> 
> 
> ___
> 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] Comment faire? forêt broadleaved & needleleaved

[David Marchal via Talk-fr]

Bonjour, Marc.

Le tag boundary=forest proposé correspond à "un ensemble de zones, généralement 
boisées, où l’ensemble est considéré comme une forêt". Par exemple, une forêt 
domaniale peut contenir zones marécageuses, zones boisées résineuses, 
clairières… mais ces zones sont considérées comme partie intégrante de la 
forêt, quand bien même elles ne sont pas boisées.

Sinon, pour un cas plus général, il existe place=region : bien que controversé 
car se pose la question des limites exactes de la zone, ce tag permet de créer 
un polygone, généralement assez étendu, qui désigne une région naturelle : 
plaine, marais, cuesta… Par exemple : 
https://www.openstreetmap.org/way/1054478447

Quant au fait que boundary=forest ne soit pas rendu sur le rendu standard 
OSM.org, c’est tout simplement parce que l’usage en est encore trop faible pour 
demander son rendu : une fois qu’il y aura quelques miliers d’entités, le rendu 
pourra être demandé, mais dans l’intervalle, la demande sera sans doute 
rejetée. C’est le problème de tous les nouveaux tags : le fait qu’ils ne soient 
pas rendus n’encourage pas l’adoption, mais ils ne sont pas rendus tant qu’il 
n’y a pas une adoption minimale…

Cordialement.

Gesendet mittels einer sicheren E-Mail von [Proton Mail](https://proton.me/).

--- Original Message ---
Marc Mongenet  schrieb am Dienstag, 6. September 2022 
um 00:37:

> Bonjour,
>
> Le lun. 5 sept. 2022 à 07:21, David Marchal via Talk-fr 
>  a écrit :
>
>> Bonjour, Marc.
>>
>> C’est précisément pour ce genre de cas que j’avais conçu le tag 
>> boundary=forest (cf 
>> https://wiki.openstreetmap.org/wiki/Tag:boundary=forest?uselang=fr pour plus 
>> d’info) : tu cartographies le terrain avec landuse=forest, natural=wetland, 
>> natural=grassland… avec autant de polygones différents qu’il le faut pour 
>> représenter le terrain (par exemple les variations de leaf_type), puis tu 
>> ajoutes par dessus un (multi)polygone type=boundary + boundary=forest + 
>> name=… pour représenter le fait que l’ensemble est une seule et unique 
>> forêt, en dépit des variations de terrain, et quand bien même le terrain 
>> n’est pas landuse=forest ou natural=wood (clairières, zones marécageuses, 
>> étangs…).
>
> Oui, cela semble correspondre exactement à ce que je cherche, au petit détail 
> près que j'en ai d'abord besoin pour un marais (boundary=wetland ?).
>
>> Un exemple ici : 
>> [https://www.openstreetmap.org/j'attendrelation/13897472](https://www.openstreetmap.org/relation/13897472)
>>
>> Soit dit en passant, on peut constater la mauvaise circulation des infos 
>> dans l’écosystème OSM : ce tag a été approuvé il y a des mois, à la 
>> troisième proposition avec la première datant de près de deux ans 
>> maintenant, et pourtant sa simple existence n’est généralement pas connue. 
>> Certes, l’écosystème OSM est complexe, mais il n’empêche…
>
> Je remarque que le nom de la forêt n'apparaît pas sur la carte. S'il n'y a 
> aucun rendu, question circulation de l'information, c'est presque comme si le 
> tag n'existait pas.
>
> Marc Mongenet
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Comment faire? forêt broadleaved & needleleaved

[David Marchal via Talk-fr]

Bonjour, Marc.

C’est précisément pour ce genre de cas que j’avais conçu le tag boundary=forest 
(cf https://wiki.openstreetmap.org/wiki/Tag:boundary=forest?uselang=fr pour 
plus d’info) : tu cartographies le terrain avec landuse=forest, 
natural=wetland, natural=grassland… avec autant de polygones différents qu’il 
le faut pour représenter le terrain (par exemple les variations de leaf_type), 
puis tu ajoutes par dessus un (multi)polygone type=boundary + boundary=forest + 
name=… pour représenter le fait que l’ensemble est une seule et unique forêt, 
en dépit des variations de terrain, et quand bien même le terrain n’est pas 
landuse=forest ou natural=wood (clairières, zones marécageuses, étangs…).

Un exemple ici : https://www.openstreetmap.org/relation/13897472

Soit dit en passant, on peut constater la mauvaise circulation des infos dans 
l’écosystème OSM : ce tag a été approuvé il y a des mois, à la troisième 
proposition avec la première datant de près de deux ans maintenant, et pourtant 
sa simple existence n’est généralement pas connue. Certes, l’écosystème OSM est 
complexe, mais il n’empêche…

Cordialement.


Gesendet mittels einer sicheren E-Mail von Proton Mail.

--- Original Message ---
Marc Mongenet  schrieb am Sonntag, 4. September 2022 
um 23:24:


> Le dim. 4 sept. 2022 à 21:42, osm.sanspourr...@spamgourmet.com a écrit :
> 
> > Pourquoi ne pas faire une "bonne grosse" forêt nommée avec mixed et des
> > sous-parties sans nom et de même clé principale avec les deux types de
> > plantations ?
> > 
> > Jean-Yvon
> 
> Et bien le mixed ne fonctionne pas dans le cas de la zone humide.
> Et puis si la forêt n'a aucune zone mixed, mais des zones bien délimitées
> de needleleaved (plantation d'épicéas par exemple) et de broadleaved, ça ne
> fonctionne pas non plus.
> Et surtout, je veux qu'à la fin, quand on recherche le nom de la forêt, ça
> entoure toute la forêt. Et je veux aussi que le nom de la forêt apparaisse
> dessus, bien centré, et d'une taille proportionnelle à la forêt. Bref, je
> cherche une solution propre, pas une bidouille.
> Je pensais au multipolygone qui entoure tout, comme suggéré par
> pepilepi...@ovh.fr, mais alors je suppose que le nom de la forêt (du
> marais) sera rattaché à un multipolygone sans attribut et ne représentera
> rien, n'est-ce pas ?
> 
> Marc Mongenet
> 
> > ___
> > 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

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Bonnes pratiques pour la délimitation des landuse et autres natural ?

[David Marchal via Talk-fr]

Salutations !

Le problème vient de ce qu’on met dans la route : la banquette, le bord 
herbeux… tout cela est maintenu pour la route, et n’existe que par elle, sinon 
tout cela n’existerait pas, n’aurait pas été construit. Pour ma part, je 
considère que cela est partie intégrante de la route, donc je procède comme 
toi, exception faite du cas où il y a un fossé ou un autre élément du genre.

Par ailleurs, si on fait comme ton second cas, cela veut dire qu’on modélise 
une bande vide de part et d’autre de la route, or ce n’est pas vide : c’est la 
route et son infrastructure, sa bande de roulement, son bas-côté, sa bande 
d’arrêt d’urgence… Aussi peu élégant que ce soit, là encore, la première 
méthode me semble plus proche de la réalité.

En fait, le problème vient, je pense, de ce qu’on fait une ligne pour 
représenter un élément qui a une largeur non nulle, tant s’en faut ; or, en 
géométrie, une ligne a une épaisseur nulle. Logiquement, pour bien faire les 
choses, on devrait mettre l’emprise de la route dans un polygone du genre 
landuse=highway, mais, de mémoire, cette proposition avait été rejetée. On a 
donc une ligne qui représente une surface ; puisque cette surface fait limite 
entre les parcelles adjacentes, il est logique, je trouve, d’utiliser le chemin 
highway=* comme limite des parcelles adjacentes, faute de mieux.

Cordialement.

Gesendet mittels einer sicheren E-Mail von Proton Mail.

--- Original Message ---
pepilepi...@ovh.fr  schrieb am Montag, 11. Juli 2022 um 
15:31:


> Bonjour,
>
> Quand, comme ça arrive très souvent (ici
> https://www.openstreetmap.org/#map=17/44.78529/4.95740, par exemple),
>
> on a une route avec d'un côté un champ cultivé et de l'autre une forêt,
> il est tentant de réutiliser les segments de la route dans la définition
> des landuse. C'est ce que je fais d'habitude, un peu par flemme et
> beaucoup pour ne pas surcharger inutilement la base de données (oui, je
> sais, quand on a dix milliards de noeuds on n'en est pas à dix ou cent
> mille près, mais j'aime pas ça).
>
> Dans certaines zones (ici
> https://www.openstreetmap.org/#map=19/44.85846/4.95959, par exemple)
>
> on voit aussi la route, une limite séparée pour le bois, et une autre
> limite de l'autre côté pour la zone résidentielle.
>
> Certes c'est vrai (en France du moins) qu'en toute rigueur il y a
> toujours une petite bande, un talus ou un fossé, entre la route et le
> champ cultivé. Mais est-ce vraiment la peine de la mentionner ?
>
> Laquelle de ces deux pratiques doit-elle être préférée ?
>
> Bonne journée,
>
> Jean-Pierre
>
>
> --
> 
>
> Si ma réponse n'a pas résolu ton problème, c'est que tu n'as pas posé la
> bonne question
>
> ___
> 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] Nom de zone géographique / touristique

[David Marchal via Talk-fr]

Nicolas,

Note également que cela ne dispense pas de faire des recherches plus 
approfondies. Pour ma part, je fais des recherches sur la région, regarde si 
les différentes sources existantes sont d’accord sur ce qui est dans la région 
naturelle et ce qui ne l’est pas, et tranche en fonction de l’altimétrie et de 
la géologie pour les cas litigieux. Bref, je fais au mieux avec les 
informations que je trouve, et advienne que pourra.

Cordialement.

Gesendet mittels einer sicheren E-Mail von Proton Mail.

--- Original Message ---
David Marchal  schrieb am Samstag, 25. Juni 2022 um 
17:58:


> Salut, Nicolas !
>
> Pour la note, j’utilise le tag note=*, qui sert à donner des précisions aux 
> autres contributeurs, par exemple ici: 
> https://www.openstreetmap.org/relation/14265856
>
> Le BRGM publie la carte géologique harmonisée de la France , par département, 
> à l’adresse suivante : 
> https://www.geocatalogue.fr/Detail.do?fileIdentifier=94636790-8615-11dc-9e02-0050568151b7
>  Je dis harmonisée car, auparavant, chaque carte de la série avait sa propre 
> légende et son propre code couleur. Si, si… Imagine les cartes IGN dont les 
> couleurs changent si tu changes de région…
>
> Il y a aussi un service WMS/WFS (URL pour JOSM: 
> wms:http://geoservices.brgm.fr/geologie?language=fre=image/png=TRUE=1.3.0=WMS=GetMap=SCAN_H_GEOL50_SCAN=={proj}={width}={height}={bbox})
>  utilisable sous les mêmes conditions que le cadastre, c’est-à-dire préciser 
> la source et l’année d’utilisation. Ce service couvre toute la France 
> métropolitaine en un bloc, ce qui est bien plus pratique.
>
> Pour l’altimétrie, tu as différents services WMS ouverts à l’adresse suivante 
> : https://www.terrestris.de/en/hoehenmodell-srtm30-wms/ Ce service reprend 
> les données ouvertes du SRTM que la Nasa a publiées, et les rend disponible 
> en WMS. Pour ma part, j’utilise le calque Hillshade (ombrage), que je mets 
> par dessus la carte géologique avec de la transparence pour distinguer la 
> géologie sous l’ombrage… Et voilà le travail !
>
> Cordialement.
>
>
> Gesendet mittels einer sicheren E-Mail von Proton Mail.
>
>
> --- Original Message ---
> Nicolas Bétheuil nb+...@heloworld.me schrieb am Samstag, 25. Juni 2022 um 
> 12:55:
>
>
>
> > Bonjour
> >
> > Merci David pour toutes ces précisions et formalisation sur des usages
> > qui se rapprochent de l'idée.
> > Quelques questions pratique :
> > Quand tu parles d'une note, tu parles d'une mention dans le tag source
> > ?
> > Comment trouver la couche géologique pour décalquer les contours ?
> > C'est un truc libre ?
> > Le rendu IGN des altitudes (couleur par altitude et pas juste courbe)
> > pourraient être intéressant mais j'imagine pas libre, même si le modèle
> > des courbes de niveau est lui libre (de la NASA j'avais lu ?)
> >
> > On Fri, 2022-06-24 at 17:53 +, David Marchal via Talk-fr wrote:
> >
> > > Bonjour à tous !
> > >
> > > Si c’est pour des régions naturelles, il y a un schéma "non-officiel"
> > > (non approuvé par le processus de discussion/vote Wiki) de
> > > (multi)polygones pour cartographier ça: place=region +
> > > region:type=natural_area ; pour le pays d’Othe, par exemple :
> > > https://www.openstreetmap.org/relation/1241697 (pour info,
> > > OpenTopoMap rend ces informations par un label qui se courbe pour
> > > suivre au mieux les limites de la région :
> > > https://opentopomap.org/#map=8/47.9145/3.9880). Certains
> > > contributeurs utilisent natural=* ou region:type=mountain_range pour
> > > préciser davantage de quel type de région il s’agit.
> > >
> > > Je me sers de ce genre de polygones/relations dans ma région, tout en
> > > mettant une note indiquant que, s’agissant de régions naturelles, les
> > > limites sont par définition contestables, et je constate que je ne
> > > suis pas le seul (https://www.openstreetmap.org/relation/3078437).
> > > Pour ma part, si j’estime pouvoir donner une limite, même imprécise,
> > > je cartographie la région en plaçant cette note ; charge à qui veut
> > > améliorer la limite de le faire, c’est tout le principe d’OSM. Si,
> > > par contre, c’est vraiment trop flou (genre, je n’ai que quelques
> > > noms de localités considérées comme incluses dans la région), je ne
> > > cartographie pas.
> > >
> > > Toutefois, je me suis aperçu que, pour beaucoup de régions
> > > naturelles, utiliser une carte géologique et un modèle numérique de
> > > terrain, qui va indiquer côtes, lignes de crêtes, vallées… permet de
> > > placer assez précisément les l

Re: [OSM-talk-fr] Nom de zone géographique / touristique

[David Marchal via Talk-fr]

Salut, Nicolas !

Pour la note, j’utilise le tag note=*, qui sert à donner des précisions aux 
autres contributeurs, par exemple ici: 
https://www.openstreetmap.org/relation/14265856

Le BRGM publie la carte géologique harmonisée de la France , par département, à 
l’adresse suivante : 
https://www.geocatalogue.fr/Detail.do?fileIdentifier=94636790-8615-11dc-9e02-0050568151b7
 Je dis harmonisée car, auparavant, chaque carte de la série avait sa propre 
légende et son propre code couleur. Si, si… Imagine les cartes IGN dont les 
couleurs changent si tu changes de région…

Il y a aussi un service WMS/WFS (URL pour JOSM: 
wms:http://geoservices.brgm.fr/geologie?language=fre=image/png=TRUE=1.3.0=WMS=GetMap=SCAN_H_GEOL50_SCAN=={proj}={width}={height}={bbox})
 utilisable sous les mêmes conditions que le cadastre, c’est-à-dire préciser la 
source et l’année d’utilisation. Ce service couvre toute la France 
métropolitaine en un bloc, ce qui est bien plus pratique.

Pour l’altimétrie, tu as différents services WMS ouverts à l’adresse suivante : 
https://www.terrestris.de/en/hoehenmodell-srtm30-wms/ Ce service reprend les 
données ouvertes du SRTM que la Nasa a publiées, et les rend disponible en WMS. 
Pour ma part, j’utilise le calque Hillshade (ombrage), que je mets par dessus 
la carte géologique avec de la transparence pour distinguer la géologie sous 
l’ombrage… Et voilà le travail !

Cordialement.

Gesendet mittels einer sicheren E-Mail von Proton Mail.

--- Original Message ---
Nicolas Bétheuil  schrieb am Samstag, 25. Juni 2022 um 
12:55:


> Bonjour
>
> Merci David pour toutes ces précisions et formalisation sur des usages
> qui se rapprochent de l'idée.
> Quelques questions pratique :
> Quand tu parles d'une note, tu parles d'une mention dans le tag source
> ?
> Comment trouver la couche géologique pour décalquer les contours ?
> C'est un truc libre ?
> Le rendu IGN des altitudes (couleur par altitude et pas juste courbe)
> pourraient être intéressant mais j'imagine pas libre, même si le modèle
> des courbes de niveau est lui libre (de la NASA j'avais lu ?)
>
>
> On Fri, 2022-06-24 at 17:53 +, David Marchal via Talk-fr wrote:
>
> > Bonjour à tous !
> >
> > Si c’est pour des régions naturelles, il y a un schéma "non-officiel"
> > (non approuvé par le processus de discussion/vote Wiki) de
> > (multi)polygones pour cartographier ça: place=region +
> > region:type=natural_area ; pour le pays d’Othe, par exemple :
> > https://www.openstreetmap.org/relation/1241697 (pour info,
> > OpenTopoMap rend ces informations par un label qui se courbe pour
> > suivre au mieux les limites de la région :
> > https://opentopomap.org/#map=8/47.9145/3.9880). Certains
> > contributeurs utilisent natural=* ou region:type=mountain_range pour
> > préciser davantage de quel type de région il s’agit.
> >
> > Je me sers de ce genre de polygones/relations dans ma région, tout en
> > mettant une note indiquant que, s’agissant de régions naturelles, les
> > limites sont par définition contestables, et je constate que je ne
> > suis pas le seul (https://www.openstreetmap.org/relation/3078437).
> > Pour ma part, si j’estime pouvoir donner une limite, même imprécise,
> > je cartographie la région en plaçant cette note ; charge à qui veut
> > améliorer la limite de le faire, c’est tout le principe d’OSM. Si,
> > par contre, c’est vraiment trop flou (genre, je n’ai que quelques
> > noms de localités considérées comme incluses dans la région), je ne
> > cartographie pas.
> >
> > Toutefois, je me suis aperçu que, pour beaucoup de régions
> > naturelles, utiliser une carte géologique et un modèle numérique de
> > terrain, qui va indiquer côtes, lignes de crêtes, vallées… permet de
> > placer assez précisément les limites des régions naturelles, qui
> > correspondent assez souvent, par exemple, à un changement de roche
> > mère ou à la brusque apparition d’un pays vallonné. Exemple avec les
> > collines sous-vosgiennes
> > (https://www.openstreetmap.org/relation/14220370) qui correspondent à
> > l’apparition, depuis le plateau lorrain argilo-calcaire, d’un pays de
> > collines gréseuses : avec carte géologique et ombrage des reliefs, ça
> > va tout seul ! Bon, on a une précision à l’hectomètre ou au
> > kilomètre, mais c’est plus précis qu’un nœud au milieu de nulle part,
> > qui ne donne aucune idée, même approximative, de l’emprise.
> >
> > On pourrait ergoter sur les limites précises, car qui peut dire où
> > s’arrête un plateau et où commence la plaine qu’il domine ? À quel
> > niveau de l’escarpement donner la limite ? Toutefois, le fait est que
> > de telles régions existent, même si elles ont des limites floues ; la
>

Re: [OSM-talk-fr] Nom de zone géographique / touristique

[David Marchal via Talk-fr]

Bonjour à tous !

Si c’est pour des régions naturelles, il y a un schéma "non-officiel" (non 
approuvé par le processus de discussion/vote Wiki) de (multi)polygones pour 
cartographier ça: place=region + region:type=natural_area ; pour le pays 
d’Othe, par exemple : https://www.openstreetmap.org/relation/1241697 (pour 
info, OpenTopoMap rend ces informations par un label qui se courbe pour suivre 
au mieux les limites de la région : 
https://opentopomap.org/#map=8/47.9145/3.9880). Certains contributeurs 
utilisent natural=* ou region:type=mountain_range pour préciser davantage de 
quel type de région il s’agit.

Je me sers de ce genre de polygones/relations dans ma région, tout en mettant 
une note indiquant que, s’agissant de régions naturelles, les limites sont par 
définition contestables, et je constate que je ne suis pas le seul 
(https://www.openstreetmap.org/relation/3078437). Pour ma part, si j’estime 
pouvoir donner une limite, même imprécise, je cartographie la région en plaçant 
cette note ; charge à qui veut améliorer la limite de le faire, c’est tout le 
principe d’OSM. Si, par contre, c’est vraiment trop flou (genre, je n’ai que 
quelques noms de localités considérées comme incluses dans la région), je ne 
cartographie pas.

Toutefois, je me suis aperçu que, pour beaucoup de régions naturelles, utiliser 
une carte géologique et un modèle numérique de terrain, qui va indiquer côtes, 
lignes de crêtes, vallées… permet de placer assez précisément les limites des 
régions naturelles, qui correspondent assez souvent, par exemple, à un 
changement de roche mère ou à la brusque apparition d’un pays vallonné. Exemple 
avec les collines sous-vosgiennes 
(https://www.openstreetmap.org/relation/14220370) qui correspondent à 
l’apparition, depuis le plateau lorrain argilo-calcaire, d’un pays de collines 
gréseuses : avec carte géologique et ombrage des reliefs, ça va tout seul ! 
Bon, on a une précision à l’hectomètre ou au kilomètre, mais c’est plus précis 
qu’un nœud au milieu de nulle part, qui ne donne aucune idée, même 
approximative, de l’emprise.

On pourrait ergoter sur les limites précises, car qui peut dire où s’arrête un 
plateau et où commence la plaine qu’il domine ? À quel niveau de l’escarpement 
donner la limite ? Toutefois, le fait est que de telles régions existent, même 
si elles ont des limites floues ; la question est alors de savoir ce qu’on veut 
cartographier. La réalité dans toute son imprécision, ou une version expurgée 
de tout ce qui n’est pas considéré comme suffisamment précis ?

Concernant le Gévaudan, attention : un PETR est une entité administrative, et, 
par expérience, ces entités, même si elles reprennent le nom d’anciennes 
provinces ou de régions naturelles, ne les recouvrent qu’imparfaitement et en 
sont différentes. Selon le principe OSM « Un élément, une entité », le PETR et 
la région naturelle, s’ils sont tous deux cartographiés, devraient l’être, à 
mon sens, avec deux entités.

Enfin, je rappelle tout de même que tout cela n’est que mon avis, mais si ça 
peut servir…

Cordialement.

Gesendet mittels einer sicheren E-Mail von Proton Mail.

--- Original Message ---
Christian Quest  schrieb am Freitag, 24. Juni 2022 um 
17:14:


> Le 24/06/2022 à 15:59, Marc_marc a écrit :
>
> > Bonjour Yannick,
> >
> > Le 24.06.22 à 12:13, Yannick a écrit :
> >
> > > Le 24/06/2022 à 10:48, Marc_marc a écrit :
> > >
> > > > à n'ajouter que si cela a du sens encore aujourd'hui vu que c'est
> > > > vraiement vieux
> > >
> > > Tu ne peux préjuger de ce qui est utile ou non à d'autres.
> >
> > Merci pour ton avis.
> > Juger si c'est utile ou pas n'est pas mon propos.
> > mon propos c'est qu'osm c'est la réalité d'aujourd'hui.
> > osm n'est pas une base de donnée de l'histoire du monde.
> >
> > exemple 1 :
> > le tracé de l'empire romain sans aucune trace sur le terrain
> > est utile à plein de personne mais il n'a pas sa place dans osm,
> > des prrojets style OpenHistoricalMap sont fait pour ce genre
> > de données historiques.
> >
> > exemple 2:
> > Certaines communes fusionnées sont encore utilisée aujourd'hui,
> > des personnes disent encore parfois "j'habite dans l'ancienne
> > commune ABC", des noms de rues changent encore parfois de nom
> > à l'ancienne limite communale. je trouve pertinent de conserver
> > ce genre de donnée dans osm "pour un certain temps"
> >
> > Pour une tracé d'une entité administrative qui n'existe plus
> > depuis la révolution française, j'ai un gros doute, ne sachant pas
> > si Nicolas parlait de l'entité administrative ou "géologique"
> > Si qlq trouve que cela a encore une réalité aujourd'hui,
> > alors cela a sa place dans osm, sinon (et c'est mon impression),
> > c'est une information pour OpenHistoricalMap
> >
> > https://wiki.openstreetmap.org/wiki/FR:Open_Historical_Map
> >
> > Cordialement,
> > Marc
>
>
>
> Je ne sais pas si on parle de la même chose, mais j'ai une maison en
> Bourgogne, dans l'Auxerrois, à côté du Pays d'Othe et de la 

Re: [OSM-talk-fr] JOSM - Désignation des shop=farm

[David Marchal via Talk-fr]

Salut, TopographeFou !

Une modification de traduction bienvenue ; feu vert pour moi.

Cordialement.

Gesendet mittels einer sicheren E-Mail von Proton Mail.
--- Original Message ---
LeTopographeFou  schrieb am Sonntag, 5. Juni 2022 um 
19:14:


> Bonjour à tous,
>
> Soit la clé suivante : shop=farm
>
> JOSM en français la nomme "Primeur" là où le wiki (et je suis d'accord
> avec lui) parle de produits de la ferme. "Primeur", c'est en théorie
> shop=greengrocer (nommée "Fruits et légumes" dans JOSM). A mon avis cela
> a dû créer des erreurs.
>
> Aucun soucis pour que je fasse changer la traduction JOSM de shop=farm
> en "Produits de la ferme" ?
>
> Cordialement,
>
> --
> LeTopographeFou
> ___
> 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] Multipolygone brayé, mais je ne trouve pas où

[David Marchal via Talk-fr]

Bonjour, Christian.

Oui, bon, fatalement, le rendu était tout caca… C’est corrigé, merci beaucoup !

Cordialement.

Sent with ProtonMail Secure Email.

--- Original Message ---

Christian Quest  schrieb am Sonntag, 20. Februar 2022 
um 20:07:

> Le 20/02/2022 à 19:15, David Marchal via Talk-fr a écrit :
>
> > Salut, la liste !
> >
> > Hier, j’ai ajouté un membre inner à un multipolygone 
> > (https://www.openstreetmap.org/relation/297388) mais, maintenant, il 
> > apparaît tout cassé au rendu, alors que le validateur JOSM ne signale rien 
> > d’anormal. Quelqu’un pourrait y jeter un œil et me dire ce qui cloche ? Je 
> > comprends pas…
> >
> > Dans l’attente de vos lumières,
> >
> > Cordialement.
>
> JOSM me détecte ça:
>
> https://www.openstreetmap.org/relation/297388#map=19/48.05379/7.06031
>
>
> --
>
> 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

[OSM-talk-fr] Multipolygone brayé, mais je ne trouve pas où

[David Marchal via Talk-fr]

Salut, la liste !

Hier, j’ai ajouté un membre inner à un multipolygone 
(https://www.openstreetmap.org/relation/297388) mais, maintenant, il apparaît 
tout cassé au rendu, alors que le validateur JOSM ne signale rien d’anormal. 
Quelqu’un pourrait y jeter un œil et me dire ce qui cloche ? Je comprends pas…

Dans l’attente de vos lumières,

Cordialement.

Sent with [ProtonMail](https://protonmail.com/) Secure Email.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Tagger correctement les panneaux entrées de villes & villages

[David Marchal]

> Le 9 févr. 2020 à 13:43, onesime31  a écrit :
> 
> 
> Bonjour,
Bonsoir.

> 
> Nous avons un projet avec une classe de géomaticiens en formation.
> On a une commande et on aimerait faire cela en utilisant OSM, faire une 
> cartoparty dans le cadre de leur formation. La commande est de cartographier 
> les entrées et sorties de villes et villages.
>  
> Pour le panneau d'entrée de village, voici le key et le value qu'on pensait 
> utiliser: traffic_sign=city_limit 
> à priori, il n'y a pas possibilité de préciser si c'est le panneau d'entrée 
> ou de sortie du village? 
> On peut les distinguer via le code EB10 et EB20...  est ce une bonne manière 
> de référencer comme cela:
> - traffic_sign=city_limit
> - traffic_sign=FR:EB20
> ?
À mon avis, il vaudrait mieux garder la convention de mettre un nœud 
traffic_sign=city_limit sur la route, à l’endroit où le panneau est placé, car 
ça permet aux utilisateurs des données de savoir, par exemple, à partir de quel 
point les règles de circulation en agglomération s’appliquent. En revanche, ça 
n’empêche pas de placer un autre nœud traffic_sign=FR:EB20 à l’emplacement 
précis du panneau, et sans lien avec la route. Faire les deux fait plus de 
travail, mais au moins tout le monde est content.

> Il nous faudrait également indiquer s'ils sont zérophyto: c'est à dire que 
> les poteaux de ces panneaux aient un dé ou une dalle béton au pied (et qu'on  
> utilise pas de pesticide pour enlever l'herbe au pied de ceux-ci).
> Pour la fixation du panneau, on pensait utiliser le key "support" puis les 
> value suivant pour les distinguer:
> - support= post quand le panneau est simplement planté (donc pas zerophyto)
> - support = pole si le panneau est scellé au sol (= zerophyto pour nous)
> Existe t-il une autre manière de tagger s'il y a un dé, ou une dalle béton au 
> pied du panneau?
> 
> L'idée serait de travailler sur OSM, et de faire une extraction pour répondre 
> à la commande qui nous est faite.
> 
> Si vous avez des conseils, précisions, ressources, etc. n'hésitez pas.
> 
> Bonne soirée, Onésime.
Cordialement.


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Afficher un flux WMS de l'ONF dans JOSM

[David Marchal]

Bonsoir, Romain.

Essaie avec cette URL-ci : http://ws.carmencarto.fr/WMS/105/ONF_Forets? Ça te 
donne, entre autres, les forêts et parcelles publiques ; attention, les données 
ne sont mises à jour qu’une fois l’an.

Cordialement.

Le 21 janv. 2020 à 20:20, Romain MEHUT 
mailto:romain.me...@gmail.com>> a écrit :

Bonsoir,

Il y a quelque temps déjà j'avais réussi à ajouter un flux WMS 
(http://metadata.carmencarto.fr/geonetwork/105/fre/catalog.search#/metadata/fr-662043116-82880F0D-E1C4-4EF3-80AF-416977F118F1)
 de l'ONF dans JOSM pour visualiser l'emprise des forêts publiques mais 
maintenant j'ai un message d'erreur : "Impossible d'analyser la liste des 
calques WMS. javax.xml.stream.XMLStreamException: ParseError at 
[raw,col]:[109,36] ..."

Sinon il y un autre flux WFS 
(http://metadata.carmencarto.fr/geonetwork/105/fre/catalog.search#/metadata/fr-662043116-7D3DC709-E1EB-470B-9FD0-8ABF8AAFD8E4)
 mais ce n'est pas reconnu par JOSM.

Donc quelqu'un saurait-il comment s'y prendre ?

Merci d'avance.

Romain
___
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] Manque de l'attribution OSM

[David Marchal]

Étrange, vu le profil éditorial de Reporterre, plutôt antilibéral et 
communautaire. Mais bien vu, Émeric !

Cordialement.

Le 8 janv. 2020 à 16:46, emeric Prouteau 
mailto:emeric.prout...@gmail.com>> a écrit :

Bonjour tout le monde,

Je viens d'envoyer un message au journal reporterre car sur la carte suivante 
je n'ai pas trouvé de mentions légales concernant openstreetmap

https://superlocal.team/?s=lemouvement

Bonne journée,

--
Emeric PROUTEAU
emeric.prout...@gmail.com

Avant d'imprimer. Pensons à l'environnement.
Save paper. Do you really need to print this e-mail?
___
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] BD Ortho down... donc UP du plan B

[David Marchal]

Ah, c’était donc ça. Bravo pour la réactivité, Christian !

> Le 7 janv. 2020 à 14:43, Christian Quest  a écrit :
> 
> Le 07/01/2020 à 13:58, Christian Quest a écrit :
>> Les appels de notre proxy à la BD Ortho sont rejetés (403 problème 
>> d'authentification).
>> 
>> Comme le site "pro" de l'IGN est indisponible depuis une dizaine de jours 
>> pour cause de migration version un futur nouveau site plus mieux, impossible 
>> d'aller voir ce qui coince, si il y a une clé à mettre à jour ou autre.
>> 
>> En attendant, je redirige les requêtes vers la couche "tous_fr" de 
>> wms.openstreetmap.fr
>> 
>> Elle ne couvre pas toute la France mais c'est mieux que rien du tout.
>> 
> 
> Rectificatif... l'IGN ne répond plus en HTTP mais uniquement en HTTPS et 
> redirige les requêtes, que le proxy ne suivait pas. C'est désormais corrigé 
> et retour à la normale.
> 
> Désolé pour le bruit !
> 
> 
> -- 
> 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] 1ere mondiale (enfin je crois) : le réseau de transport électrique français est routable

[David Marchal]

Bravo pour le boulot, François ! C’est parfois une plaie de dénouer les lignes, 
même avec les données de RTE.

Cordialement.

Le 7 janv. 2020 à 02:05, François Lacombe 
mailto:fl.infosrese...@gmail.com>> a écrit :

Salut à tous

Mon 1er mail de 2020 ici, donc bonne année à tous !
Que vos projets respectifs se concrétisent et surtout que vous y trouviez une 
satisfaction sans cesse renouvelée

Pour bien commencer, j'attire votre attention sur le changeset suivant :
https://www.openstreetmap.org/changeset/79224080

Il marque une étape importante dans la description du réseau de transport 
électrique, débutée dès 2008 je crois
L'ensemble des tensions 400kV et 225kV sont désormais routables en France, via 
l'emploi de + de 1500 relations cousues-main comme celles-ci
https://www.openstreetmap.org/relation/6194774
Elles représentent une continuité métallique avec plusieurs extrémités parfois. 
C'est expliqué ici :
https://wiki.openstreetmap.org/wiki/Power_networks/France#Circuits_et_routage_sur_le_r.C3.A9seau
Il ne me semble pas que pareil niveau ait été atteint ailleurs dans le monde.
http://overpass-turbo.eu/s/yUw

Le projet a été assorti de la description des postes extrémités, jusqu'aux 
arbres et places de parking
https://twitter.com/InfosReseaux/status/1210984860292206599?s=20

La complétude va permettre d'extraire une dizaine de jeux de données 
thématiques, dont la plupart n'a pas d'équivalent en données ouvertes, dans les 
prochaines semaines et de communiquer sur leur disponibilité.
On pourra parler :
- De la centaine de personnes ayant contribué de ~2008 jusqu'à maintenant
- Des milliers de km et de photos fait sur le terrain
- Des dizaines de milliers de km de lignes tracées sur vues aériennes (avant la 
dispo de l'opendata RTE)
- Des 1200 transformateurs de puissance traqués et positionnés
- Des dizaines d'hectares de pelouse tracées dans les postes (peut directement 
servir à la planification de l'emploi de moutons chez RTE pour limiter l'usage 
de produits phytosanitaires)
- Des milliers de km de jeux de barres, portiques, murs, voirie routière tracés 
dans les mêmes postes
- Des centaines d'arbres positionnés (il me semble)

+ probablement d'autres stats

Bref, c'est vraiment super
A bientôt !

François
___
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] Chemins publics / privés / ouverts / fermés

[David Marchal]

> Le 3 janv. 2020 à 17:37, Arnaud Champollion 
>  a écrit :
> 
> Bonjour,
Bonjoir.
> 
> Les chemins passent parfois sur des parcelles privées (cadastrées) ou zones 
> communales (pas de numéro au cadastre). Il arrive que ces chemins soient 
> fermés au public.
> 
> On a donc, en simplifiant, quatre cas :
> 
> 1) le cas du chemin situé sur parcelle privée, et d'accès privé.
Attention : le fait que ce soit simplement marqué « Privé » ne rend pas l’accès 
privé; seul le terrain, l’emprise a un caractère privé, mais cela ne rend pas 
l’accès privé pour autant. En France, légalement, le fait qu’une voie soit 
d’accès privé doit être matérialisé sans ambiguïté : panneau « Défense d’entrer 
» ou barrage physique. Un panneau « Voie privée » serait donc plutôt 
access=permissive, selon moi.

> 2) le cas du chemin situé sur parcelle privée, mais passage autorisé (c'est 
> le cas concrètement de beaucoup de sentiers de randonnée)
access=permissive me semble tout indiqué.

> 3) le cas du chemin situé sur parcelle publique, et d'accès autorisé
Le access=yes implicite me semble convenir.

> 4) le cas du chemin situé sur parcelle publique, mais "accaparé" par le 
> propriétaire mitoyen
Dans ce cas, je dirais qu’on applique le principe « cartographier le terrain » 
: si le chemin est physiquement inaccessible, un nœud avec barrier=* et 
access=private au-delà.

Cordialement.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Nouvelles données ouvertes sur les réseaux électriques

[David Marchal]

Bonjour, François.

Le réseau souterrain d’Enedis ? Vrai ? Effectivement, excellente nouvelle ; 
bien joué !

Cordialement.

Le 19 déc. 2019 à 15:20, François Lacombe 
mailto:fl.infosrese...@gmail.com>> a écrit :

Bonjour à tous,

Vous le savez, cela fait maintenant plus d'un an que je m’investis activement 
pour motiver les 130 gestionnaires de réseaux de distribution électrique à 
ouvrir la cartographie de leurs réseaux.
https://teamopendata.org/t/les-gestionnaires-de-distribution-electrique/1018

Suite aux deux avis CADA reçus favorables en septembre, les choses se 
débloquent et les échanges sont de plus en plus nombreux avec les acteurs 
concernés.

L'une des plus grosses société contactée, Gérédis dans les Deux-Sevres, a 
libéré récemment la cartographie de son réseau, présumée sous licence ouverte.
https://www.geredis.fr/Open-data

On y trouve le réseau aérien comme souterrain, ce qui est une bonne nouvelle au 
vu du périmètre concerné, plus de 250 communes.

Ce n'est pas tout :
Enedis nous fait également le plaisir de compléter la cartographie déjà libre 
depuis avril 2018 avec son réseau souterrain. Ceci sur l'ensemble de la 
métropole, sois plus de 400 000 km de réseau portant le total à plus d'1 
million de km avec l'aérien.
Le jeu de données des postes est plus complet qu'avant, avec l'ajout des 
installations non visibles (la plupart des postes parisiens par exemple).
https://data.enedis.fr/explore/dataset/reseau-souterrain-hta/map/?location=15,45.14656,1.49646=jawg.streets

De ma compréhension et c'est à souligner, de nombreux mois de travail semblent 
avoir été nécessaires pour élaborer ces jeux de données avec l'investissement 
de plusieurs équipes.
Cela renforce encore la pertinence d'inciter les entreprises à ouvrir leurs 
données, si cela était encore à démontrer. Le sujet intéresse et est utile aux 
structures qui publient.

L'effort devrait se poursuivre en 2020 avec l'établissement d'un standard 
(j'espère), nécessaire pour accompagner les plus petites structures vers 
l'ouverture et harmoniser les licences choisies.
Et pourquoi pas quelques services, si il reste du temps.

Ceci ne serait pas probablement pas possible si la communauté ne contribuait 
pas aussi assidûment sur le sujet. Les acteurs concernés ont bien pris la 
mesure de notre engagement et de ce que nous pouvions apporter au pot commun. 
Ces progrès sont à mettre au crédit de nos efforts à tous.

Bonne fin de semaine

François
___
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

[OSM-talk-fr] Données RTE et BRGM

[David Marchal]

Chers tous,

J’ai mis à jour la page 
https://wiki.openstreetmap.org/wiki/FR:Sources_de_donn%C3%A9es_potentielles/France
 pour deux choses : d’une part, la page mentionnait que RTE ne publiait pas 
encore ses données, donc j’ai corrigé ça avec des liens vers les données et une 
mention à la licence d’utilisation. Cela, vous le saviez sans doute déjà, mais 
à tout hasard… D’autre part, j’ai rajouté une source de données que j’ai pu 
dégoter et qui, à ma connaissance, n’avait pas encore d’équivalent : celles des 
cavités souterraines (gouffres, grottes, ponors…), publiée en licence ouverte 
par le BRGM. S’il en est qui s’intéressent aux karsts, à la géologie ou à la 
spéléologie, ça devrait leur être utile car, à ma connaissance, il y a peu de 
données à ce sujet. Pour savoir comment modéliser les karsts dans OSM, voir 
https://wiki.openstreetmap.org/wiki/Key:sinkhole

Cordialement.


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] highway=motorway_junction : noms ?

[David Marchal]

Jean-Yvon,


Généralement, je ne préviens pas parce que je ne suis pas sûr que ce soit 
pertinent : soit ça date de plusieurs années, et le contributeur a pu apprendre 
depuis, auquel cas il serait impertinent de prétendre lui enseigner comment 
faire, soit il semble raisonnable que le contributeur sache des choses que je 
ne sais pas. En revanche, lorsqu’il est clair qu’une donnée est erronée parce 
qu’un tag a été mal utilisé ou que ça a été mal tagué pour obtenir un rendu 
précis, comme une sortie `highway=motorway_junction` avec `name=Aire de 
machinchose` ou `ref=N 4`, j’ai tendance à prévenir. J’ai un côté prof 
prétentieux que je travaille à modérer, donc j’essaie de ne prévenir que si je 
suis raisonnablement sûr que c’est utile.

Cordialement.


De : osm.sanspourr...@spamgourmet.com 
Envoyé : mardi 24 juillet 2018 13:25
À : talk-fr@openstreetmap.org
Objet : Re: [OSM-talk-fr] highway=motorway_junction : noms ?


Dans le Finistère les échangeurs des voies-express ont des noms (en plus des 
numéros). En breton car c'est le nom du lieu-dit (qui a rarement été francisé).

Comme Philippe je dirais l'échangeur mais comme le numéro de sortie c'est aussi 
le numéro de l'échangeur, je ne vois pas bien la différence.

N. B. : quand tu corriges, pense à avertir l'auteur de la première version.

Jean-Yvon

Le 24/07/2018 à 12:56, JB - jb...@mailoo.org<mailto:jb...@mailoo.org> a écrit :
Les sorties d'autoroute ont-elles un nom ? Je dirais oui : ici, j'interprète 
bien un nom (indiqué avec le numéro de sortie, en italique), et deux 
destinations (en dessous, police classique).
https://www.mapillary.com/app?focus=photo=LvUCqf6SINTILuVhgcwS1A (noscript 
pas franchement apprécié).
JB.

Le 24/07/2018 à 10:49, Philippe Verdy a écrit :
En revanche les interconnexions des bretelles de sorties avec le reste du 
réseau est souvent un rond-point ou un échangeur qui a, lui, très souvent un 
nom, mais qui ne font pas lui-même partie du réseau autoroutier.

Le 24 juillet 2018 à 08:18, David Marchal 
mailto:pene...@live.fr>> a écrit :

Salut, la liste.


Je modifiais récemment des sorties d’autoroute quand je me suis aperçu de 
quelque chose : le tag name=* était parfois utilisé pour la destination de la 
sortie, ce que je corrige, mais il est parfois utilisé pour donner un nom, qui 
n’est pas celui des destinations affichées, par exemple le long de l’A 35 en 
Alsace ; ceci dit, ce nom ne semble pas affiché sur place. Existe-t-il des 
sorties d’autoroute dotées de noms ? Où trouver une telle information, si ce 
n’est sur place ?


Dans l’attente de vos réponses,


Cordialement.

___
Talk-fr mailing list
Talk-fr@openstreetmap.org<mailto:Talk-fr@openstreetmap.org>
https://lists.openstreetmap.org/listinfo/talk-fr





___
Talk-fr mailing list
Talk-fr@openstreetmap.org<mailto:Talk-fr@openstreetmap.org>
https://lists.openstreetmap.org/listinfo/talk-fr





___
Talk-fr mailing list
Talk-fr@openstreetmap.org<mailto: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

[OSM-talk-fr] highway=motorway_junction : noms ?

[David Marchal]

Salut, la liste.


Je modifiais récemment des sorties d’autoroute quand je me suis aperçu de 
quelque chose : le tag name=* était parfois utilisé pour la destination de la 
sortie, ce que je corrige, mais il est parfois utilisé pour donner un nom, qui 
n’est pas celui des destinations affichées, par exemple le long de l’A 35 en 
Alsace ; ceci dit, ce nom ne semble pas affiché sur place. Existe-t-il des 
sorties d’autoroute dotées de noms ? Où trouver une telle information, si ce 
n’est sur place ?


Dans l’attente de vos réponses,


Cordialement.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Itinéraires bis et de substitution

[David Marchal]

Re-bonjour, la liste.


Une autre question qui me taraude : est-ce que les itinéraires bis et de 
substitution sont ajoutés à OSM ? Suivant une relation de type route, je 
suppose, mais avec quelles autres clés ? Y a-t-il des sources de données 
utilisables pour ces itinéraires ?


Dans l’attente de vos réponses,


Cordialement.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Voie véhicules lents

[David Marchal]

Axelos,


Ça correspondrait, mais ça fait un peu franco-français, comme clé, non ?

Cordialement.


De : Axelos 
Envoyé : lundi 25 juin 2018 09:39
À : talk-fr@openstreetmap.org
Objet : Re: [OSM-talk-fr] Voie véhicules lents

Bonjour,

Le 25/06/2018 à 08:57, David Marchal a écrit :
> Ma question est simple : comment on modélise ça ? Je n’ai rien trouvé sur le 
> Wiki, et ça a l’air franco-français.

J'ai étudié moi aussi la question il y a quelques années, et ai pondu
une page wiki de proposition.
https://wiki.openstreetmap.org/wiki/Proposed_features/slow_moving
Proposed features/slow moving - OpenStreetMap 
Wiki<https://wiki.openstreetmap.org/wiki/Proposed_features/slow_moving>
wiki.openstreetmap.org
Couramment appelé à tort "voie réservée aux poids lourds", ce type de voie est 
situé le plus souvent sur les grands axes de circulation types autoroutes et 
voies rapides, principalement dans les fortes montées.




Je ne me rappelle plus pourquoi j'ai mis des jokers sur les valeurs
=*truc|truc|truc

Axel.

___
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

[OSM-talk-fr] Voie véhicules lents

[David Marchal]

Chers tous,


Ma question est simple : comment on modélise ça ? Je n’ai rien trouvé sur le 
Wiki, et ça a l’air franco-français.


Dans l’attente de vos réponses,


Cordialement.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk] iD news - v2.9.0 now with Bing Streetside support

[David Marchal]

Thank you, Frederik.


De : Frederik Ramm 
Envoyé : mardi 19 juin 2018 14:05
À : talk@openstreetmap.org
Objet : Re: [OSM-talk] iD news - v2.9.0 now with Bing Streetside support

Hi.

On 19.06.2018 13:58, David Marchal wrote:
> OK, my bad, then. A remnant of old anti-Microsoft-ism, I assume. Do you
> have heard of a support of this imagery from JOSM, by chance?

https://svn.openstreetmap.org/applications/editors/josm/plugins/MicrosoftStreetside/
though since it hasn't been announced yet it might not be ready for
prime time.

Bye
Frederik

--
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] iD news - v2.9.0 now with Bing Streetside support

[David Marchal]

OK, my bad, then. A remnant of old anti-Microsoft-ism, I assume. Do you have 
heard of a support of this imagery from JOSM, by chance?

Regards.


De : Bryan Housel 
Envoyé : mardi 19 juin 2018 13:46
À : David Marchal
Cc : osm-talk
Objet : Re: [OSM-talk] iD news - v2.9.0 now with Bing Streetside support

Be nice, we’re improving the resolution:
https://github.com/openstreetmap/iD/issues/5078



On Jun 19, 2018, at 7:41 AM, David Marchal 
mailto:pene...@live.fr>> wrote:

Too bad the poor resolution doesn't allow to read destination signs, it would 
have been a great help to add destination[:*] tags. Nice move from Microsoft 
anyway.

Regards.


De : Bryan Housel mailto:bhou...@gmail.com>>
Envoyé : samedi 16 juin 2018 16:32
À : osm-talk
Objet : [OSM-talk] iD news - v2.9.0 now with Bing Streetside support

Happy Summer!  
I just released iD v2.9.0 this week and it’s now available on 
openstreetmap.org<http://openstreetmap.org/> for editing.  If you use street 
level imagery you will like this...



 Bing Streetside now supported
iD now includes a layer for Bing Streetside!  This new layer provides 
360-degree panoramic imagery across large regions of the United States, United 
Kingdom, France, and Spain. Many thanks to Jubal Harpster and the rest of the 
team at Microsoft!
Activate the Bing Streetside layer by opening the Map Data pane (shortcut F)

This pull request includes more details direct from Microsoft clarifying the 
terms of use for mapping with Bing Streetside: 
https://github.com/openstreetmap/iD/pull/5050


 Mapillary Traffic Signs refresh
iD also made some changes in how we process icons, which resulted in a welcome 
refresh for the Mapillary Traffic Signs layer.  We’ve switched from PNG to SVG, 
so the icons look much clearer, we support many more signs, and the traffic 
sign layer is now supported in all browsers!
Activate the Mapillary Traffic Signs layer by opening the Map Data pane 
(shortcut F)


As always, the update includes several other usability improvements and new 
presets - check out the changelog for all the details.

Changelog:
v2.9.0 changelog:  
https://github.com/openstreetmap/iD/blob/master/CHANGELOG.md#290

Twitter:
v2.9.0 announcement:  https://twitter.com/bhousel/status/1007253540589449216
Bing Streetside Manhattan: 
https://twitter.com/bhousel/status/1006997683918245888
Mapillary Street Signs:  https://twitter.com/bhousel/status/1004594196664250369

Blogs:
Bing Maps:  
https://blogs.bing.com/maps/2018-06/bing-maps-streetside-imagery-now-integrated-into-openstreetmap-id-editor
WinBuzzer:  
https://winbuzzer.com/2018/06/15/openstreetmap-id-editor-gets-5-petabytes-of-bing-streetside-imagery-xcxwbn/

Reddit:
Thread:  
https://www.reddit.com/r/openstreetmap/comments/8r24pz/id_290_is_live_for_editing_now_you_can_use_bing/


Follow and star the iD project on GitHub to show your support:  
https://github.com/openstreetmap/iD
And follow me on Twitter https://twitter.com/bhousel for the latest iD news.

Thank you!
❤️ Bryan, and the rest of the  team.

___
talk mailing list
talk@openstreetmap.org<mailto:talk@openstreetmap.org>
https://lists.openstreetmap.org/listinfo/talk

___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] iD news - v2.9.0 now with Bing Streetside support

[David Marchal]

Too bad the poor resolution doesn't allow to read destination signs, it would 
have been a great help to add destination[:*] tags. Nice move from Microsoft 
anyway.

Regards.


De : Bryan Housel 
Envoyé : samedi 16 juin 2018 16:32
À : osm-talk
Objet : [OSM-talk] iD news - v2.9.0 now with Bing Streetside support

Happy Summer!  
I just released iD v2.9.0 this week and it’s now available on 
openstreetmap.org for editing.  If you use street 
level imagery you will like this...



 Bing Streetside now supported
iD now includes a layer for Bing Streetside!  This new layer provides 
360-degree panoramic imagery across large regions of the United States, United 
Kingdom, France, and Spain. Many thanks to Jubal Harpster and the rest of the 
team at Microsoft!
Activate the Bing Streetside layer by opening the Map Data pane (shortcut F)

This pull request includes more details direct from Microsoft clarifying the 
terms of use for mapping with Bing Streetside: 
https://github.com/openstreetmap/iD/pull/5050


 Mapillary Traffic Signs refresh
iD also made some changes in how we process icons, which resulted in a welcome 
refresh for the Mapillary Traffic Signs layer.  We’ve switched from PNG to SVG, 
so the icons look much clearer, we support many more signs, and the traffic 
sign layer is now supported in all browsers!
Activate the Mapillary Traffic Signs layer by opening the Map Data pane 
(shortcut F)


As always, the update includes several other usability improvements and new 
presets - check out the changelog for all the details.

Changelog:
v2.9.0 changelog:  
https://github.com/openstreetmap/iD/blob/master/CHANGELOG.md#290

Twitter:
v2.9.0 announcement:  https://twitter.com/bhousel/status/1007253540589449216
Bing Streetside Manhattan: 
https://twitter.com/bhousel/status/1006997683918245888
Mapillary Street Signs:  https://twitter.com/bhousel/status/1004594196664250369

Blogs:
Bing Maps:  
https://blogs.bing.com/maps/2018-06/bing-maps-streetside-imagery-now-integrated-into-openstreetmap-id-editor
WinBuzzer:  
https://winbuzzer.com/2018/06/15/openstreetmap-id-editor-gets-5-petabytes-of-bing-streetside-imagery-xcxwbn/

Reddit:
Thread:  
https://www.reddit.com/r/openstreetmap/comments/8r24pz/id_290_is_live_for_editing_now_you_can_use_bing/


Follow and star the iD project on GitHub to show your support:  
https://github.com/openstreetmap/iD
And follow me on Twitter https://twitter.com/bhousel for the latest iD news.

Thank you!
❤️ Bryan, and the rest of the  team.

___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk-fr] Bing StreetSide

[David Marchal]

Ah, bonne nouvelle. Dommage que la qualité très moyenne empêche de lire les 
panneaux routiers, ça aurait pu être une très bonne source de données pour les 
tags destinations[:*]. Ou c’est chez moi que ça ne charge pas bien ?

Cordialement.


De : Cédric Frayssinet 
Envoyé : vendredi 15 juin 2018 10:33
À : Discussions sur OSM en français
Objet : [OSM-talk-fr] Bing StreetSide


Bonjour,

Pour ceux, comme moi, qui découvrent, voici une nouveauté iD, de la part de 
Microsoft :

https://blogs.bing.com/maps/2018-06/bing-maps-streetside-imagery-now-integrated-into-openstreetmap-id-editor


En Métropole Lyonnaise, on a quelques images, je suppose que les autres grandes 
villes aussi.

Pour iD, il faut aller dans Données Cartographiques, puis cocher Surcouche 
photo Bing StreetSide, nouvel item en plus de Mapillary et OpenStreetCam.

Cédric


--
En cure de désintoxication de Google ! 
Client d'Enercoop, l'énergie 
militante

Également sur Mastodon : 
@bristow...@framapiaf.org

[Promouvoir et soutenir le logiciel libre]
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Question citoyenne au gouvernement sur la reprise des itinéraires de randonnée

[David Marchal]

Bonsoir.

Ton travail se remarque quand on navigue en France sur 
hiking.waymarkedtrails.org<http://hiking.waymarkedtrails.org> autour de la 
Loire-Atlantique ; chapeau !

Cordialement.

Le 13 juin 2018 à 19:42, Adrien Grellier 
mailto:pe...@adrieng.fr>> a écrit :


Bonjour,

Ce n'est pas vraiment nouveau. En effet, j'ai cartographié tous les GR et GRP 
de Loire-Atlantique depuis 2016, en me basant sur cet OpenData justement. C'est 
d'ailleurs mentionné dans le tag source des relations.

En septembre 2017, j'en ai également parlé sur le wiki, en me positionnant 
contre la volonté de nettoyage des rando :

https://wiki.openstreetmap.org/wiki/WikiProject_France/NettoyageDesItin%C3%A9rairesDeRandonn%C3%A9e

Bonne journée

Adrien

Le 13/06/2018 à 19:07, César Bihler a écrit :

Pour info, il a l'air d'y avoir du nouveau localement, notamment en Loire 
Atlantique pour le GR3 en ODbL (?) :

Lien général : 
https://data.loire-atlantique.fr/explore/?q=randonnee=modified

Exemple d'une portion ODbL : 
https://data.loire-atlantique.fr/explore/dataset/391177847_randonnee-en-loire-atlantique-gr3-le-cellier-thouare-sur-loire/information/?location=16,47.28402,-1.3963=jawg.streets

Le 12-Jun-18 à 22:24, Romain MEHUT a écrit :
Salut,

Voilà où nous en sommes 
https://twitter.com/Romain_MEHUT/status/1003993335634120705 c'est à dire 
toujours au même point !

Romain

Le 12 juin 2018 à 14:07, David Marchal 
mailto:pene...@live.fr>> a écrit :
Salut, les gens.

Pour info, je viens de poser, sur le site Parlement ouvert, une question 
concernant la publication à titre gratuit des données des itinéraires de 
randonnées (https://questions.parlement-ouvert.fr/post/551). Puisque la FFRP ne 
semble pas vouloir avancer sur cette question, une résolution venant de plus 
haut pourrait nous sortir de la situation de type « cul entre deux chaises » 
actuelle. Pour ceux ne connaissant pas le site, la question ne rentre pas dans 
les détails, étant donnée la limitation à 500 caractères, et sert surtout à 
attirer l’attention sur le problème ; tout le monde peut commenter, approuver 
ou désapprouver la question, qu’un député pourra ensuite choisir de poser au 
gouvernement à l’Assemblée. Il est probable qu’une question suscitant des 
réactions, surtout positives, ait plus de chances d’être suivie d’effets.

Cordialement.


___
Talk-fr mailing list
Talk-fr@openstreetmap.org<mailto:Talk-fr@openstreetmap.org>
https://lists.openstreetmap.org/listinfo/talk-fr





___
Talk-fr mailing list
Talk-fr@openstreetmap.org<mailto:Talk-fr@openstreetmap.org>
https://lists.openstreetmap.org/listinfo/talk-fr





___
Talk-fr mailing list
Talk-fr@openstreetmap.org<mailto:Talk-fr@openstreetmap.org>
https://lists.openstreetmap.org/listinfo/talk-fr


___
Talk-fr mailing list
Talk-fr@openstreetmap.org<mailto: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

[OSM-talk-fr] Question citoyenne au gouvernement sur la reprise des itinéraires de randonnée

[David Marchal]

Salut, les gens.


Pour info, je viens de poser, sur le site Parlement ouvert, une question 
concernant la publication à titre gratuit des données des itinéraires de 
randonnées (https://questions.parlement-ouvert.fr/post/551). Puisque la FFRP ne 
semble pas vouloir avancer sur cette question, une résolution venant de plus 
haut pourrait nous sortir de la situation de type « cul entre deux chaises » 
actuelle. Pour ceux ne connaissant pas le site, la question ne rentre pas dans 
les détails, étant donnée la limitation à 500 caractères, et sert surtout à 
attirer l’attention sur le problème ; tout le monde peut commenter, approuver 
ou désapprouver la question, qu’un député pourra ensuite choisir de poser au 
gouvernement à l’Assemblée. Il est probable qu’une question suscitant des 
réactions, surtout positives, ait plus de chances d’être suivie d’effets.


Cordialement.

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Quand Géoportail/IGN fait un "tuto" pour la mesure des parcelles cadastrales...

[David Marchal]

Waouh, super outil ! Et c’est moi, ou il y a un rendu OSM vectoriel ?

Cordialement.


De : PierreV 
Envoyé : jeudi 17 mai 2018 19:55
À : talk-fr@openstreetmap.org
Objet : [OSM-talk-fr] Quand Géoportail/IGN fait un "tuto" pour la mesure des 
parcelles cadastrales...

c'est vraiment navrant de voir que l'IGN est "à la ramasse" pour certains de
ses outils... et en plus ils en ont fier! Tellement qu'ils en font un
tutoriel vidéo (et sans son bien sur...) :
https://www.facebook.com/geoportail/videos/10157347533053709/?hc_ref=ARRnXrzSQDhwjyC46Bs6hmwWyZjLdqqfZrGsmmTjiUsdMUwLxcmvvfONXfAov9RgA5w=nf
[https://scontent-sea1-1.xx.fbcdn.net/v/t15.0-10/29784128_10157347517868709_7680152362840752128_n.jpg?_nc_cat=0=d1c617b6ce5a6f4fddab04410104e203=5B975147]

Géoportail
www.facebook.com
[Tutos] : Le saviez-vous ? Avec le Géoportail, recherchez une parcelle 
cadastrale et mesurez sa superficie facilement... et gratuitement ! 
https://www.geoportail.gouv.fr



ou sur youtube : https://www.youtube.com/watch?v=rbl2sF7zugk

alors qu'il existe un projet qui utilise les données opensource et qui donne
la même chose bien plus précisément et surtout en un seul clic au lieu d'une
méthode en 20 clics sur Géoportail :
https://koumoul.com/s/cadastre/





--
Sent from: http://gis.19327.n8.nabble.com/France-f5380434.html

___
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] Enedis ouvre finalement ses données d'infrastructure

[David Marchal]

Bonjour.


Ah, bonne nouvelle ! Bon, ils le font a minima, si je comprends bien, mais 
c’est toujours bon à prendre. Bien joué, François et consorts !


Cordialement.


De : François Lacombe 
Envoyé : mercredi 16 mai 2018 23:14
À : Discussions sur OSM en français
Objet : [OSM-talk-fr] Enedis ouvre finalement ses données d'infrastructure

Re-bonsoir,

La nouvelle est tombée cet après-midi sur les coups de 15h, 4 jeux de données 
ont été ajoutés à la plateforme opendata d'Enedis concernant les lignes et les 
postes.
https://data.enedis.fr/explore/?sort=modified=Infrastructures
Enedis Open Data  
Explore
data.enedis.fr
Enedis est gestionnaire du réseau public de distribution d'électricité au 
service de 35 millions de clients. Dans le cadre de nos missions nous gérons un 
grand nombre de données, notamment issues des compteurs. En tant qu’entreprise 
de service public, nous sommes responsables du respect de la confidentialité 
des informations personnelles de nos clients. Depuis quelques années, nous nous 
sommes engagés dans une démarche de mise à disposition de données anonymisées 
et gratuites au service de tous les acteurs de la transition énergétique. Nous 
vous invitons à découvrir, partager et réutiliser ces données en Open Data !




https://twitter.com/CoutantFabien/status/996837176770998272
https://twitter.com/pindrow/status/99676883095722

Pour ceux qui connaissent mon engagement en la matière, c'est un aboutissement 
de 5 ans de contribution pour qu'à plusieurs âmes motivées nous arrivions à 
faire évoluer les mentalités en la matière.
La libération de ces données devenait incontournable à partir du moment où OSM 
devenait pertinent et plus complet que le SIG de certains exploitants.
Il le reste, Enedis n'ayant par exemple pas publié d'attributs sur les objets 
libérés.

Les deux jeux de données sur les lignes ne sont pas intégrables en l'état dans 
OSM. Il s'agit de tracés grande échelle qui permettent uniquement aux 
contributeurs à savoir qu'une ligne se trouve dans les environs. Vous pourrez 
comparer avec la BDOrtho pour vous en apercevoir.
Ne pas essayer non plus de considérer les sommets des lignes comme des poteaux, 
ça ne marche pas.

En revanche, le jeu des postes HTA/BT peut être intégré directement dans 
Osmose, à la recherche des objets (batiments, armoires...) power=substation + 
substation=minor_distribution + operator=Enedis
Cela va permettre de qualifier le bâti beaucoup plus finement.
C'est la seule intégration qu'il est possible de faire pour l'instant.
https://github.com/osm-fr/osmose-backend/issues/300

La disponibilité de ces jeux va nous permettre globalement de mieux cibler les 
recherches sur le terrain pour collecter les attributs manquants, qu'il faut 
continuer d'ajouter à OSM


Bonne soirée et bonne carto

François
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Et si on fabriquait notre récepteur/logger GPS ?

[David Marchal]

Euh… Je me représente pas bien le truc : autant une antenne à plat, type patch, 
je vois bien comment l’arranger sur moi, mais ce type d’antenne, je vois pas 
trop.

Cordialement.

> Le 6 avr. 2018 à 09:42, Stéphane Péneau  a écrit :
> 
> À ceux qui souhaitent une antenne interne :
> 
> Pouvoir basculer d'une antenne interne à une antenne externe est quelque 
> chose qui n'est pas simple au niveau électronique, et qui aurait de grandes 
> chances d'entrainer une baisse du niveau de réception.
> 
> Une solution aurait été de proposer 2 modèles, un avec une antenne interne, 
> et l'autre avec un connecteur pour antenne externe. Ce n'est pas idéal car ça 
> complique la fabrication, et un possesseur de récepteur avec antenne interne 
> ne pourra plus utiliser d'antenne externe.
> 
> Je propose de contourner le problème.
> Puisque l'inconvénient d'une antenne externe, c'est le câble, alors l'idée 
> serait que les randonneurs utilisent une antenne de type hélicoïdale qui 
> serait vissée directement sur le connecteur externe. C'est ce type de produit 
> :
> http://www.maxtena.com/products/helicore/m1516hct-p-sma/
> 
> On simplifie la fabrication, et l'utilisateur garde le choix du type 
> d'antenne (solidaire du récepteur, ou déportée au bout d'un câble).
> 
> Qu'en pensez-vous ?
> 
> Stéphane
> 
> 
> 
> ___
> 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

[OSM-talk-fr] leisure=swimming_pool : bassin ou bâtiment ?

[David Marchal]

Salut, tout le monde.

Une modification de ma part, consistant à retirer le tag leisure=swimming_pool 
à un bâtiment hébergeant une piscine, a entraîné un désaccord : un autre 
utilisateur est revenu en arrière, puisque, si le Wiki précise 
(https://wiki.openstreetmap.org/wiki/FR:Tag:leisure%3Dswimming_pool) que ce tag 
est à utiliser sur le bassin, il dit l’inverse ailleurs 
(https://wiki.openstreetmap.org/wiki/FR:Baignade#Piscine). Vu que le rendu du 
bâtiment se fait en bleu avec leisure=swimming_pool, je dirais que ce tag est 
destiné au bassin, mais est-ce bien ça, ou y a-t-il une erreur dans le rendu ? 
À noter que la version anglaise de la seconde page penche également pour mon 
avis, mais ce n’est que mon avis, justement. Qu’en dites-vous ?

Dans l’attente de vos réponses,

Cordialement.

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Et si on fabriquait notre récepteur/logger GPS ?

[David Marchal]

Quelques dizaines d’euros de différence, c’est le pain pour un mois. Les petits 
budgets, dont je suis, apprécieront cette différence de prix ; les pays en voie 
de développement aussi, d’ailleurs. Les contributeurs africains, par exemple, 
seraient sans doute bien contents d’avoir un truc pas cher et tout simple, type 
allumer-enregistrer, plutôt qu’un smartphone avec des dizaines de fonctions 
mais dont une seule, le GPS, les intéresse ; et puis, ça permettrait de laisser 
les moins dégourdis avec la technologie faire des traces, en France ou 
ailleurs. Je pense aussi aux bidouilleurs, qui préféreront reprendre les plans 
du bidule et l’assembler eux-mêmes plutôt que d’acheter un truc tout fait.

Pour la précision, je pense que l’antenne extérieure serait déjà une bonne 
avancée par rapport aux antennes intégrées des smartphones, mais c’est 
totalement subjectif, n’ayant jamais testé réellement la chose.


De : Francois Gouget <fgou...@free.fr>
Envoyé : mercredi 28 mars 2018 00:35
À : Discussions sur OSM en français
Objet : Re: [OSM-talk-fr] Et si on fabriquait notre récepteur/logger GPS ?

On Tue, 27 Mar 2018, David Marchal wrote:

> L’intérêt est, je pense, d’avoir un boîtier discret, simple et pas
> trop cher, qui ne serve qu’à ça pour ne pas avoir besoin d’un
> smartphone au prix supérieur et plus complexe.

Et se passer d'OsmAnd~, Street-Complete et Mapillary / OSC ?
Impensable ;-) !


> Ça pourrait viser, [...] ceux qui n’en ont pas les moyens

On peut trouver un bon smartphone à 150€ (Zenfone 2 ZE551ML). Les plus
basiques commencent à 80€ à tout casser et je n'ai pas l'impression que
leurs GPS soient tellement pire. Donc pour que l'opération ait du sens
d'un point de vue strictement économique il faudrait que ce GPS maison
coûte moins de 60€ (80€ - 20€ pour un dumbphone), ou moins de 95€ si on
retient un prix moyen.


[...]
> Et puis, il y a bien sûr l’histoire de la précision, qui risque fort
> d’être meilleure, ce qui est un gros plus quand on modélise sur OSM.

Je suis sceptique sur les chances d'avoir une précision
significativement meilleure en restant sur les technologies standard et
pas chères ; c'est à dire qui n'exploitent que le signal L1 et sans
techniques type GPS différentiel.

L'email de Stéphane Péneau aurait tendance à me renforcer dans ces
convictions. Mais je ne suis pas un spécialiste des GPS alors peut-être
que je suis trop pessimiste. Ou alors j'attends trop des GPS. Une
précision de +/- 1 m en ville et en forêt, là ça changerait la donne.
Mais déjà à +/- 3 m... bof.


--
Francois Gouget <fgou...@free.fr>  http://fgouget.free.fr/
In theory, theory and practice are the same, but in practice they're different.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Et si on fabriquait notre récepteur/logger GPS ?

[David Marchal]

Deux versions serait peut-être trop demander pour un petit projet de ce genre, 
en tout cas pas tant qu’une des deux n’est pas déjà fonctionnelle et 
expérimentée.


De : Philippe Verdy 
Envoyé : dimanche 25 mars 2018 11:35
À : Discussions sur OSM en français
Objet : Re: [OSM-talk-fr] Et si on fabriquait notre récepteur/logger GPS ?

Rien n'empêche d'avoir les deux options. Donc une batterie interne, le port USB 
et une batterie externe qu'on peut brancher pour plus d'autonomie. Cela reste 
un seul boitier à développer (pas besoin de développer un boiteir externe 
supplémentaire, des batteries externe portables USB ça existe déjà un peu 
partout, et on a foison de chargeurs et adaptateurs USB pour véhicules). On est 
dans le même cas que les smartphones en fait.

En revanche on peut imaginer deux versions de ce boitier GPS:
- autonome avec sa prise antenne externe optionnelle et batterie intégrée
- ou toute petite clé USB à brancher sur un PC ou une planche de bord et sans 
batterie (alimenté par le port USB), et là encore avec un mini port antenne 
optionnel: pour des raisons pratiques, le port USB n'est pas fixé à la mini 
carte-mère, mais relié par un mini-câble, ce qui facilite le placement (le 
reproche qu'on peut faire à plein de clés USB c'est que ce sont des "verrues" 
fragiles, le port USB peut facilement casser, c'est souvent mieux et plus 
résistant avec un mini-câble; même pour mon PC fixe je ne relie jamais mes clés 
externes directement au port du PC mais via un câble intermédiaire, ça évite 
plein d'accident; seule exception: si la clé tient presque entièrement dans le 
port comme les mini-clés USB pour clavier/souris sans fil en Bluetooth, pas 
besoin de câble).
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Et si on fabriquait notre récepteur/logger GPS ?

[David Marchal]

L’intérêt est, je pense, d’avoir un boîtier discret, simple et pas trop cher, 
qui ne serve qu’à ça pour ne pas avoir besoin d’un smartphone au prix supérieur 
et plus complexe. Ça pourrait viser, par exemple, les réfractaires à ces 
menottes technologiques, ceux qui n’en ont pas les moyens ou ceux qui veulent 
profiter de la nature sans surveiller sans arrêt leur smartphone – comme vous 
l’aurez sans doute compris, je parle en connaissance de cause. Et puis, il y a 
bien sûr l’histoire de la précision, qui risque fort d’être meilleure, ce qui 
est un gros plus quand on modélise sur OSM.


Cordialement.


De : Francois Gouget 
Envoyé : vendredi 23 mars 2018 11:25
À : verd...@wanadoo.fr; Discussions sur OSM en français
Objet : Re: [OSM-talk-fr] Et si on fabriquait notre récepteur/logger GPS ?

On Thu, 22 Mar 2018, Philippe Verdy wrote:

> < 1 m en montagne c'est difficile  pour une simple raison: le manque de
> visibilité d'une part et les réflexions/chemin multiples sur les parois, et
> souvent aussi la végétation en zone forestière. Particulièrement sans
> correction si c'est l'objectif et encore plus en monofréquence.
[...]
> L'absence de ces corrections basées sur d'autres observations et mesures
> prises par d'autres satellites ou stations d'observation au sol fait qu'on
> ne peut espérer mieux qu'une précision de 30 mètres en montagne. On peut
> toujours rêver mais il faut comprendre un peut comment et sur quelles
> mesures se basent les systèmes GNSS.

Du coup quel serait l'intérêt d'un tel GPS par rapport à un smartphone ?

Il ne reste guère que l'autonomie et le plaisir d'avoir du matériel
libre mais est-ce vraiment suffisant ou cela ne le condamne-t-il pas à
être diffusé à une douzaine d'exemplaires seulement ?

La précision c'est vraiment le principal reproche que je ferait au GPS
de mon smartphone. Paradoxalement en voiture elle est suffisante pour du
Mapillary mais dès que je me promène en ville à pied il divague beaucoup
(je soupçonne qu'il utilise la vitesse pour restreindre le champ des
possibles de la prochaine position). Étant donné les problèmes de
réflexion et de masquage des satellites je ne vois guère de solution
hors passer justement à un système travaillant à partir de la L5.

La fréquence de mise à jour de la position est potentiellement un
deuxième problème mais il est tout aussi probable que ce soit juste un
bug de Mapillary.

Donc, pour moi, un GPS séparé pourrait éventuellement être intéressant
mais uniquement s'il offre une meilleure précision. Or il y a à présent
assez de satellites qui émettent un signal L5 et on nous promet de
nouveaux smartphones avec des puces GPS qui l'utilisent pour 2018. Du
coup j'attendrai peut-être simplement de changer de smartphone.

https://spectrum.ieee.org/tech-talk/semiconductors/design/superaccurate-gps-chips-coming-to-smartphones-in-2018
[https://spectrum.ieee.org/image/Mjk1NDM3OQ.jpg]

Superaccurate GPS Chips Coming to Smartphones in 2018 
...
spectrum.ieee.org
Broadcom has released the first mass-market GPS chips that use newer satellite 
signals to boost accuracy to 30-centimeters





--
Francois Gouget   http://fgouget.free.fr/
   A man can fail many times, but he isn't a failure
until he begins to blame somebody else.
   -- John Burroughs
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Et si on fabriquait notre récepteur/logger GPS ?

[David Marchal]

Bonjour.


Pour l’écran, en tant que randonneur, ça ne me serait guère utile : la 
navigation en suivant son itinéraire sur la carte papier est plus pratique que 
d’y reporter sans arrêt la position GPS, mais je fais ces choses-là à 
l’ancienne, donc tout le monde ne sera peut-être pas de cet avis.


Le Bluetooth, s’il est présent, devrait être optionnel, et le boîtier devrait 
être capable d’enregistrer sans, car tout le monde n’en aura pas l’utilité, ni 
l’envie de gérer ça pendant une rando : typiquement, on randonne pour se 
désencombrer la tête, donc gérer le boîtier au delà de l’allumer et s’assurer 
que la réception fonctionne, bof… La carte microSD, en revanche, très bonne 
idée ! On insère, on allume, on attend une position stable pour démarrer, et on 
oublie le boîtier jusqu’à l’arrivée.


Pour une batterie interne, pas de souci tant qu’on peut jouer du fer à souder 
pour la changer en cas de besoin, et qu’elle tient la journée ; arrivé au soir, 
on peut la brancher sur une batterie externe pour la recharger, c’est 
suffisamment minime pour ne pas encombrer une soirée à la belle étoile avec un 
surplus de technologie.


Pour l’antenne, bonne idée de l’avoir magnétique pour les voitures, tant qu’on 
peut la fixer sur soi en rando ; j’avais dans l’idée de la mettre sur la 
lanière du sac à dos, sur l’épaule, en hauteur et avec une vue assez dégagée. 
Sur la casquette, ça ne serait guère discret.

Cordialement.

De : Stéphane Péneau 
Envoyé : vendredi 23 mars 2018 16:12
À : talk-fr@openstreetmap.org
Objet : Re: [OSM-talk-fr] Et si on fabriquait notre récepteur/logger GPS ?

Je vais essayer de répondre aux différentes questions :

Licence :

Pas d'inquiétude, notre concepteur (que je prénommerai Hooligan0) est 
parfaitement au courant des différentes licences et de la manière dont elles 
s'appliquent. Le CC-by-SA faisait référence au design technique, pas au code 
nécessaire. Celui-ci sera sous une licence "quivabien".
A ce propos, il n'est pas prévu de remplacer complètement le logiciel U-center 
de Ublox, qui donne accès à des centaines de paramètres de la puce, et qui lui 
n'est pas FOSS. Mais on n'empêchera personne de reprendre la doc du protocole 
Ublox pour en refaire un, libre, et multi plateformes.


Présence ou non d'un écran sur le récepteur :

Ce n'était pas prévu, et cela risque d'augmenter le coût. Synchroniser des 
photos depuis la trace reste possible en photographiant l'écran d'un 
smartphone, qui lui, afficherait en gros l'heure GPS. Je ne sais pas si ça 
existe. A creuser.
S'il y a beaucoup de demandes pour un écran, on regardera.


Protocole de communication avec un smartphone :

C'est le profil SPP du bluetooth, une banale liaison série. C'est compatible 
avec à peu près tout.
Le Bluetooth low energy, rien de certain pour le moment.


Enregistrement des points :

Je ne pense pas que filtrer les points soit pertinent. Il vaut mieux garder les 
infos brutes, et éventuellement filtrer par la suite.
Si le stockage se fait sur une carte microSD, la nbr de points importe peu. Si 
c'est sur de la mémoire flash, passer de 32 à 64Mo, c'est de l'ordre de 5€.

Utilisation sur piles :

Le souci des piles, c'est leurs capacités plus faibles que les batteries Li-ion.
Est-ce qu'une batterie Usb externe pour recharger le récepteur serait 
problématique en situation de trek ?

Boutons pour enregistrer des POI :

J'aimerais beaucoup que ça soit possible. Ça va dépendre en partie du 
microcontrôleur qui sera utilisé. J'imagine aussi assez bien un connecteur pour 
pouvoir déporter ces boutons.

Le projet Centipède :
Centipède c'est avant tout le réseau de bases pour faire du RTK. Là on parle 
plutôt de la partie mobile.
Donc non, ce projet n'a pas de lien particulier avec celui de Julien Ancelin, 
mais pourrait tout à fait s'y insérer pour la partie "rover" si la puce est une 
M8T ou une M8P. De toute façon, je lui en toucherai certainement 2 mots.


La précision :

Alors là, ça va être un peu plus long.
Partons du postulat qu'on utilise un récepteur monofréquence, et je vais 
ignorer tout ce qui est SBAS, RTK, que Galileo promet une meilleure géoloc, 
etc..

Les variations de précision qu'on va obtenir dépendent principalement du nombre 
de satellites en vue directe par l'antenne, et des caractéristiques 
(sensibilité, etc..) de cette dernière.

Si je prends mon smartphone, que je le place dans une zone complètement 
dégagée, ça va très bien fonctionner, sans doute aussi bien qu'un système plus 
performant.

Si je pose mon smartphone sur le tableau de bord de la voiture, alors j'ai déjà 
environ la moitié des satellites qui sont invisibles à cause du toit (ceux qui 
sont derrière le véhicule). Si je passe le long d'une forêt, j'en perd encore, 
ce qui va forcément dégrader le positionnement.
En revanche, si j'ai mon antenne magnétique posée sur le toit de la voiture, 
tous les satellites sont disponibles, et ils resteront bien plus 

Re: [OSM-talk-fr] Et si on fabriquait notre récepteur/logger GPS ?

[David Marchal]

Le 22 mars 2018 à 16:05, Stéphane Péneau 
> a écrit :

Bonjour tout le monde,
Bonjour.

Trouver un récepteur/enregistreur GPS de bonne qualité est un exercice 
compliqué : Il y a peu de modèles récents, la qualité de réception est 
inconnue, l'autonomie pas toujours adaptée, et quasiment aucun ne propose de 
recevoir les satellites Galileo qui nous promettent une meilleur précision.

Il y a eu de nombreuses discussions autour de ces produits ici-même, ou 
ailleurs sur le web, sans trouver le récepteur ultime, celui qui est bien plus 
performant qu'un smartphone, celui que tous les contributeurs Osm rêveraient 
d'avoir dans leur poche ou leur voiture.

J'avais en tête d'en faire un "maison" depuis un moment, mais sans en avoir le 
temps pour avancer vraiment. Il s'agissait d'une ligne sur une todo-list comme 
on en a tous. Une discussion très récente avec Jean-Louis Zimmerman m'a fait 
dire qu'a défaut de m'en charger, on pourrait peut-être faire appel à un 
professionnel pour s'en occuper.

- Coup de chance, j'en connais un tout à fait capable de réaliser ce genre de 
produit. Il m'a déjà aidé pour mes bidouilles autour des caméras.

- Re coup de chance, c'est un libriste convaincu.

- Re-re coup de chance, c'est un contributeur Osm.

- Re-re-re coup de chance, c'est un projet qui l'intéresse.

Bien entendu, ses services de conceptions et de fabrications ne sont pas 
gratuits, mais il est prêt à faire un effort pour la communauté, et s'il a des 
coups de main.

Maintenant, il faut s'occuper du cahier des charges, voilà ou nous en sommes 
pour le moment :

- puce Ublox Neo-M8N (standard) ou Neo-M8T(Raw, RTK en post-traitement ou 
traitement externe) ou Neo-M8P(calcul RTK intégré)
- Enregistrement de la trace sur mémoire interne ou carte µSD
- Connecteur pour antenne externe
- Liaison Bluetooth pour connecter un smartphone/tablette/ordi, etc...
- Batterie intégrée (recharge via connecteur µUsb)

Et maintenant j'ai besoin de toi cher lecteur :

1) Ca t'intéresse ? Tu es prêt à mettre un peu d'argent pour faire des belles 
traces GPS ? Heu non, des belles traces Galileo/Gps/Glonass/Beidou ?
Alors dis-le, car il faudra être un certain nombre pour que ça soit possible.
Clair que ça m’intéresserait, surtout avec Strava qui ne sert plus à grand 
chose.

2) Est-ce que tu préfères utiliser une antenne integrée ou externe ? Une 
antenne externe magnétique, sur le toit de la voiture, sur ta casquette, ça 
marche beaucoup beaucoup mieux.
Pouvoir la déporter permettrait d’améliorer la réception. Et puis, c’est 
classe, une antenne sur la casquette ! Non ?

3) J'imagine que tu veux qu'il fasse enregistreur autonome, c'est prévu. Mais 
sur quelle durée souhaites-tu pouvoir le faire ?
Une demi-journée semble bien.

4) De quelle autonomie as-tu besoin ? 6h ? 12h? 24h ? plus ?
Itou : 12 h paraissent suffisantes, avec de la marge pour les variations de 
capacité de la batterie (usure, froid…)

5) Est-ce que tu poserais quelques limites sur l'encombrement, le poids ?
Ben, pas le poids d’une brique, mais avec un Raspberry dans le ventre, ça 
devrait pas chercher bien loin. Je dis Raspberry parce que c’est l’idée que 
j’avais, mais ça conviendra peut-être pas, hein ?

6) Autre chose ?
Pouvoir ajouter rapidement des notes pourrait être utile. Un exemple : ajouter 
un marqueur sous la forme d’une note audio. On appuie sur un bouton, on parle : 
« Ici, panneau indiquant Nancy sur le chemin au nord. », et, quand on relâche, 
ça ajoute une note audio liée à la position actuelle ; si le marqueur ne peut 
contenir que du texte, un marqueur nommé Note 1 avec un fichier Note 1.wav 
pourrait aller. La programmation sous-jacente resterait relativement simple, de 
même que le matériel nécessaire, et l’utilisation sur place le serait également.

Un récepteur bi-canal pourrait être plus pratique, on aurait une meilleure 
précision sans forcément devoir se taper un post-traitement pour lequel tout le 
monde n’a pas les compétences.

Il vaudrait mieux, je pense, garder le machin simple : un boîtier qui 
enregistre, sans écran, et dont on sort la carte mémoire ou auquel on se 
connecte en USB pour récupérer les infos. Tout le monde n’a pas un smartphone 
ou l’envie de s’en servir en randonnée, ça limiterait le développement 
nécessaire si l’interface est inexistante, et ça serait plus facilement 
utilisable à l’étranger, par exemple dans le Tiers-Monde. Un simple logger, 
plus éventuellement un mécanisme de prise de note, ferait l’affaire, serait 
assez simple, et facilement utilisable.


A bientôt

Stéphane

Joli projet.

Cordialement.

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Zones géographiques informelles

[David Marchal]

Bonjour.


Pour avoir déjà cherché comment faire, je peux te dire que le problème 
principal est de donner les limites de ces zones : comme la limite en est floue 
car non définie avec certitude – on ne peut dire avec certitude, surtout sur 
les bordures, que tel endroit en fait partie et tel autre, non –, on ne peut 
pas les modéliser. Si tu as une source disant que la région, par exemple, 
inclut uniquement telles communes, tu peux modéliser, mais justement, ces 
sources sont généralement inexistantes ou contradictoires, donc, sans bases 
fiables, impossible de modéliser. Autant que je sache, quand c’est flou, on ne 
modélise pas.


Cordialement.


De : djakk djakk 
Envoyé : mercredi 21 février 2018 20:01
À : Discussions sur OSM en français
Objet : [OSM-talk-fr] Zones géographiques informelles

Re-salut,

une question sur le sujet des zones géographiques : comment tagguer celles qui 
sont « informelles » (non-administratives), dont la limite est floue : la 
vallée de la Vésubie, la corniche de Pail, la Beauce ...
On retrouve trace de ces noms dans la presse locale.


djakk
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Itinéraires et balisages randonnée

[David Marchal]

Pas l’intention de reverser ? Ouais, ça m’aurait étonné… Et tant pis si ça 
favoriserait la randonnée, ce qui est exactement leur but déclaré, pourtant.


Pour le balisage, je pensais à la propriété intellectuelle : le balisage FFRP, 
même fait par des tiers, reste propriété intellectuelle de la FFRP, ce qui 
induit un risque juridique pour ceux qui les représenteraient en partant des 
données OSM sur ces itinéraires.

Un truc qui m’étonne, en passant : ce sont des associations d’utilité publique, 
et elles ont le droit de nous interdire de publier leur travail pour en 
faciliter l’usage ? Quelle est l’utilité publique de cette pratique ? Certes, 
ils pensent éviter une diminution de revenus, mais serait-ce vraiment le cas ? 
Un truc qui pourrait aider à les convaincre, ce serait des témoignages d’autres 
associations de randonneurs qui ont laissé leurs itinéraires être publiés sur 
OSM sans conséquences négatives pour eux ; il n’y en avait pas au Bénélux dans 
ce cas là ? Une demande de témoignage de leur part pourrait être très utile à 
l’avenir.

Cordialement.

De : Jean-Claude Repetto <jrepe...@free.fr>
Envoyé : lundi 19 février 2018 17:40
À : Discussions sur OSM en français
Cc : David Marchal
Objet : Re: [OSM-talk-fr] Itinéraires et balisages randonnée

J'ai discuté avec un président départemental de la FFRP lors de
l'annonce de leur "projet numérique", en juillet 2013. Leur but était de
valoriser le travail de leurs bénévoles afin de compenser la baisse des
subventions aux associations (par exemple en éditant plus de
topo-guides). Donc ils n'ont aucune intention de reverser ce travail à
une base de données libre comme OSM.

Dans le 06, le balisage des PR est fait par le département. Donc je ne
pense pas que la FFRP en soit propriétaire.

Jean-Claude
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Itinéraires et balisages randonnée

[David Marchal]

Ça se tient. En tout cas, ça correspond aux retours qu’on a déjà eu de chez 
eux, et c’est leur intérêt légitime, mais quel dommage de rester dans un esprit 
de fermeture au lieu d’ouverture…



De : Axelos 
Envoyé : lundi 19 février 2018 15:13
À : talk-fr@openstreetmap.org
Objet : Re: [OSM-talk-fr] Itinéraires et balisages randonnée

Voilà ma théorie à partir d'un cas similaire :
Garder l'exclusivité de ces données leur permet entre autre d’éviter que
des sociétés opportunistes ne récupère la valeur créé bien souvent
bénévolement par ces clubs, et leurs coupes l'herbe sous les pieds d'un
moyen de revenu.

Même si c'est une vision que je ne partage pas (comme nous tous
contributeurs d'OSM), ça se défend.

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr
Page d'infos de Talk-fr - 
lists.openstreetmap.org
lists.openstreetmap.org
Pour voir tous les messages passés de la liste, visitez les Archives de Talk-fr 
. Utilisation de Talk-fr: Pour envoyer un message à tous les abonnés de ...



___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Itinéraires et balisages randonnée

[David Marchal]

Le CV serait pire que la FFRP ? Bizarre, vu qu’il y a plein d’ouvrages qui 
utilisent leur signalétique ; mais peut-être qu’ils ont tous eu le papelard 
idoine. Après, ils connaissent peut-être mieux ce genre d’outils maintenant, à 
force d’en avoir entendu parler tout le monde autour d’eux depuis 2013.


Pour le leur demander moi-même… Ben, je ne pense pas pouvoir me rendre assez 
disponible pour un tel suivi s’il s’avérait nécessaire. Je veux dire : faire 
des échanges avec la fédération pour leur demander, voire leur expliquer 
comment ça marche, les changements et conséquences que ça implique de part et 
d’autre… ça, je pourrais gérer. Mais faire la tournée des sections locales pour 
en faire de même… je doute être à même de gérer un truc comme ça ; ça risque 
plus de me démotiver et de me faire abandonner.


Si on veut que ça marche, il faut être prêt à faire tout dans les formes : 
expliquer ce qu’est OSM, leur expliquer ce qu’on veut, les avantages pour eux 
comme pour nous, le fait que cela ne contredit pas la vente des itinéraires et 
topoguides papier et peut même les enrichir… S’ils veulent approfondir, il 
faudrait sans doute leur montrer comment se servir de (J)OSM, comment mettre à 
jour les données existantes ou en ajouter, car avoir leur accord puis dire « 
Merci, mais pour la suite, on gère ; ne vous en occupez pas. », c’est moyen, il 
faut plutôt les y impliquer, pour leur faire voir l’intérêt de la chose. Mais 
c’est déjà un travail de faire tout ça pour une fédération, alors faire ça pour 
toutes ses sections, et seul ? Je pense pouvoir affirmer que c’est voué à 
l’échec, en tout cas si c’est Bibi qui s’en occupe tout seul dans son coin. 
Question stupide : la fédération ne serait pas à même de trancher pour tous ? 
Après tout, c’est aussi pour ça qu’une fédération existe, non ?

Cordialement.


De : JB 
Envoyé : lundi 19 février 2018 12:39
À : Discussions sur OSM en français
Objet : Re: [OSM-talk-fr] Itinéraires et balisages randonnée

Bonjour,
Sauf erreur de ma part, la situation n'a pas avancé positivement depuis cette 
époque :
https://lists.openstreetmap.org/pipermail/talk-fr/2012-August/046340.html
http://forum.openstreetmap.fr/viewtopic.php?t=282
J'ai souvenir de retours négatifs de la fédération par un adhérent au CV qui 
aurait abordé le sujet, mais je n'ai retrouvé de traces.
J'ai trouvé une citation dans un mail privé de 2013 : « D'après des dires de 
membres de la FFRP, le Club Vosgien serait encore "pire" au niveau propriété 
intellectuelle... »
À David : adhérent ou pas, ça ne change pas forcément grand chose, si tu veux 
un coup de tampon de l'assoc' en plus, ça m'étonnerait qu'il te soit refusé. Si 
tu veux y aller « sérieusement » (au-delà d'un tweet, d'un mail râgeur ou d'un 
courrier sans suite), c'est chouette. Mais attends-toi à un travail de longue 
haleine, probablement en commençant par convaincre la base pour aller 
chatouiller la tête ensuite. Les groupes locaux vendent des cartes de randonnée 
locales avec leurs balisages en sur-impression, et se sentent dépossédés si 
quelqu'un d'autre pouvait en faire de même. Le numérique, les biens communs, ce 
n'est pas encore leur époque, pour ceux que j'ai pu rencontrer.
JB.
PS : et le CV et la FFRP se disputent toujours la propriété du GR5 dans les 
Vosges, il me semble…

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Itinéraires et balisages randonnée

[David Marchal]

Euh… Ils font dans leur coin ce qu’OSM leur propose depuis des années, 
proposition à laquelle ils n’ont jamais daigné répondre ? Certes, ils veulent 
proposer plus de fonctionnalités que ce que OSM seul propose, comme la remontée 
d’infos sur les sentiers, mais tout de même, je m’interroge : pourquoi ne pas 
avoir impliqué OSM ? À moins que ce soit le cas et qu’on ne le sache pas encore 
? Genre ils ajouteront leur base à celle d’OSM ou la rendront importable dans 
OSM ? J’en doute, vu le passé des échanges avec eux, mais sait-on jamais…


Pour les PR, vu que la FFRP reste propriétaire du balisage, on ne pourrait 
ajouter que l’itinéraire, ce qui est moins utile – ici, c’est le randonneur qui 
parle : sans balisage, un itinéraire est moins pratique à suivre. Et encore, à 
supposer que l’administration en charge veuille bien qu’on ajoute l’itinéraire.



De : Jean-Claude Repetto 
Envoyé : lundi 19 février 2018 14:26
À : talk-fr@openstreetmap.org
Objet : Re: [OSM-talk-fr] Itinéraires et balisages randonnée

La FFRP a déjà une action en cours pour effectuer tous les relevés de
terrain sur les sentiers:
https://www.ffrandonnee.fr/_248/ambitions-itineraires-pratiques-numeriques.aspx
[http://www.ffrandonnee.fr/data/CMS/images/numerique/preview-video-numerique.jpg]

FFRandonnée - Le programme numérique de la 
FFRandonnée
www.ffrandonnee.fr
Le programme numérique de la FFRandonnée. Afin d'assurer au mieux ses missions 
et faciliter la pratique pour les randonneurs, la FFRandonnée s'est lancée dans 
un ...




Dans chaque département, une équipe de bénévoles a parcouru tous les
sentiers balisés et a relevé toutes les informations. Pas seulement le
tracé, mais aussi toutes les informations annexes: panneaux, petit
patrimoine, bancs, etc.

Je pense que leur base de données est bien plus complète que celle
d'OSM, dans laquelle beaucoup de sentiers sont encore absents.

Pour info, dans certains départements, comme le 06, la FFRP ne gère que
les GR. Les PR (balisage jaune) sont gérés par le département.

Jean-Claude

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr
Page d'infos de Talk-fr - 
lists.openstreetmap.org
lists.openstreetmap.org
Pour voir tous les messages passés de la liste, visitez les Archives de Talk-fr 
. Utilisation de Talk-fr: Pour envoyer un message à tous les abonnés de ...



___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Itinéraires et balisages randonnée

[David Marchal]

Aucune mention sur le Wiki, et je n’ai jamais entendu parler d’un accord. Je 
tenterais bien de l’obtenir, mais je ne suis pas membre de l’association OSM-FR 
et, autant que je sache, je n’ai pas de légitimité pour entamer une telle 
demande au nom de la communauté OSM, mais peut-être que ce n’est pas nécessaire 
?


Pour l’interlocuteur, le balisage est la propriété intellectuelle de la 
fédération, bien qu’ils soient assez prodigues dans leurs autorisations d’usage 
pour autant que je sache. Par contre, je ne sais pas qui est responsable des 
itinéraires. Au moins certains comme les interdépartementaux ou les GR dans les 
Vosges dépendent logiquement de la fédération, mais d’autres sont probablement 
du ressort des clubs locaux, donc soit la fédération pourrait parler pour eux 
concernant tous les itinéraires, soit il faudrait voir avec chaque club pour 
les itinéraires de son ressort, ce qui serait moins pratique.


Cet échange pourrait également être l’occasion de leur faire connaître OSM, 
voire, qui sait, leur montrer comment enrichir OSM en s’en servant de base pour 
tenir leurs itinéraires à jour. Ce serait gagnant-gagnant : ils ne dépendraient 
plus de l’IGN pour leurs supports et la mise à jour de leur balisage sur leurs 
cartes, et OSM récupérerait des données en provenance directe de l’opérateur 
des sentiers.


Dans l’attente de vos réponses,


Cordialement


De : marc marc <marc_marc_...@hotmail.com>
Envoyé : dimanche 18 février 2018 18:45
À : talk-fr@openstreetmap.org
Objet : Re: [OSM-talk-fr] Itinéraires et balisages randonnée

Le 18. 02. 18 à 16:38, David Marchal a écrit :
> Autant que je sache, la situation entre OSM et la FFRP est la suivante :
> la FFRP est au courant qu’on cartographie leurs itinéraires avec leur
> balisage, et ils n’ont jamais daigné dire s’ils nous donnaient leur
> accord ou pas. J’ai bon ?

exact.

> Qu’en est-il du Club Vosgien ?

Si quelqu'un a déjà eu un accord avec eu, j'imagine qu'il l'a renseigné
dans le wiki. as-tu fait une recherche ?
sinon, si tu as de bons contacts humains avec eux, tu es un bon candidat
pour essayer e l'obtenir :-)
Surtout que les plus petites structures sont peut-être plus réceptive
à faire connaître leur travail.

Cordialement,
Marc

___
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

[OSM-talk-fr] Itinéraires et balisages randonnée

[David Marchal]

Bonjour, la liste.


Autant que je sache, la situation entre OSM et la FFRP est la suivante : la 
FFRP est au courant qu’on cartographie leurs itinéraires avec leur balisage, et 
ils n’ont jamais daigné dire s’ils nous donnaient leur accord ou pas. J’ai bon ?


Qu’en est-il du Club Vosgien ? Ils ont des milliers de kilomètres de sentiers 
balisés, pas que dans le massif vosgien, et un balisage plus poussé et bien 
utile sur ces sentiers ? A-t-on eu des contacts avec eux ? Peut-on reprendre 
leur balisage et leurs itinéraires ?


Dans l’attente de vos réponses,


Cordialement.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Rendu hydro... avec BD Carthage et BD Topo

[David Marchal]

> Le 9 déc. 2017 à 21:53, Christian Quest  a écrit :
> 
> C'est sûr que la résolution de la BDTopo est meilleure, par contre en terme 
> d'attributs elle est très pauvre comparée à la BD Carthage.
> 
> Pas de code sandre, de classe CEMT, de largeur des cours d'eau, etc. Il 
> faudra attendre la BD Topage qui devrait avoir les attributs de Carthage et 
> la résolution Topo... dans quelques années il me semble.
> 
> Tout ça est à regarder avec la question qu'on se posait au début... 
> importable en l'état ou pas ?
> 

Question stupide (ou pas) : je n’ai jamais entendu parler de cette BD Topo, 
mais la précision m’intéresse pour croiser avec le calque Carthage ; quelle est 
l’URL pour le serveur de tuiles ?

Par ailleurs, les données supplémentaires de la BD Carthage, comme la largeur, 
je n’ai jamais su les y trouver ; comment fait-on ?

Merci d’avance pour vos lumières.

Cordialement.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Publication OpenData du cadastre

[David Marchal]

Bonjour.


En effet, j’ai résolu les problèmes, mais, si ça peut être automatisé, autant 
le faire, je pense, non ?


Cordialement.



De : HELFER Denis (SNCF RESEAU / SIEGE SNCF RESEAU / DT GE APPUI PERFORMANCE) 
<denis.hel...@reseau.sncf.fr>
Envoyé : mercredi 11 octobre 2017 09:09
À : Discussions sur OSM en français
Objet : Re: [OSM-talk-fr] Publication OpenData du cadastre


Hello,



Tu sélectionnes  tous tes objets avec type :way puis tu demandes la  validation 
 des objets puis la réparation et hop JOSM ne râle plus



De : David Marchal [mailto:pene...@live.fr]
Envoyé : mercredi 11 octobre 2017 08:33
À : Discussions sur OSM en français <talk-fr@openstreetmap.org>
Objet : Re: [OSM-talk-fr] Publication OpenData du cadastre



Bonjour.



Je viens de remarquer un bug sur l’import du GéoJSON du bâti : les polygones 
des bâtiments ne sont pas fermés, ce qui fait hurler JOSM ; apparemment, les 
bâtiments sont constitués d’une ligne dont le premier et le dernier point ont 
les mêmes coordonnées, mais ne sont pas le même point. Pour JOSM, le polygone 
n’est pas fermé.



Cordialement.





De : Vincent Privat <vincent.pri...@gmail.com<mailto:vincent.pri...@gmail.com>>
Envoyé : mardi 3 octobre 2017 23:34
À : Discussions sur OSM en français
Objet : Re: [OSM-talk-fr] Publication OpenData du cadastre



Hello,

Quelques compléments d'info sur JOSM.

Le support du cadastre est disponible, il faut utiliser la toute dernière 
version stable (12921) de JOSM et la version 33690 du greffon cadastre-fr.

J'ai annoncé la nouvelle version du greffon il y a quelques jours sur la liste 
dev-fr, et on en a parlé aussi au dernier meeting toulousain, j'ai déjà corrigé 
quelques soucis de jeunesse suite aux tests préliminaires des mappeurs 
toulousains :)



Le greffon permet d'ouvrir les lots Edigéo via file/open, file/open location, 
ou en drag, soit de l'archive tar.bz2, soit du fichier .THF.

Les géométries sont automatiquement simplifiées pour éviter d'avoir des 
piscines avec 500 nœuds. Le souci des bâtiments coupés en 2 au milieu d'une 
limite de parcelle ne se pose pas, vu qu'il s'agit des géométries natives du 
cadastre (sauf dans les cas de bâtiments à cheval sur plusieurs planches).

Actuellement sont chargés le bâti, les limites administratives, les parcelles & 
sections, les adresses, la voirie, et diverses autres choses (puits, pylônes, 
cimetières, bâtiment de culte, etc.). Tout est sourcé avec le tag habituel 
"cadastre-fr ... DGFiP 2017 etc.".

Ne sont pas chargés: les infos de mitoyenneté (mur, fossé) parce que 
représentées par un nœud, et les choses qui sont bizarrement regroupées dans le 
cadastre telles que "terrains de sport et petits ruisseaux" (WTF?!), ou bien 
"parking, terrasse, surplomb", etc.

Pour les curieux la correspondance entre les données du cadastre et les tags 
OSM se fait ici:

https://github.com/openstreetmap/josm-plugins/blob/master/cadastre-fr/src/org/openstreetmap/josm/plugins/fr/cadastre/edigeo/pci/EdigeoPciReader.java#L37

[https://avatars1.githubusercontent.com/u/261431?v=4=400]<https://github.com/openstreetmap/josm-plugins/blob/master/cadastre-fr/src/org/openstreetmap/josm/plugins/fr/cadastre/edigeo/pci/EdigeoPciReader.java#L37>


openstreetmap/josm-plugins<https://github.com/openstreetmap/josm-plugins/blob/master/cadastre-fr/src/org/openstreetmap/josm/plugins/fr/cadastre/edigeo/pci/EdigeoPciReader.java#L37>

github.com

josm-plugins - Mirror of the JOSM plugin repository in Subversion






Les calques chargés ainsi dans JOSM sont flaggués "envoi dissuadé". C'est à 
dire: JOSM va vous crier dessus si vous essayez d'envoyer ces données vers OSM, 
pour sensibiliser tout le monde qu'il y a un gros travail de vérification & 
d'intégration à mener avant de faire ça. Si je vois qu'il y a des dérives et 
des imports massifs sans travail préalable, je basculerai rapidement en mode 
"envoi interdit", ce qui bloquera complètement l'envoi direct à partir de ces 
calques.



Il me manque à exploiter la date de dernière mise à jour (je pense à la mettre 
dans un tag source:date).



J'attends l'API Etalab avec impatience, ça permettra à JOSM de télécharger les 
données du cadastre pour une zone donnée (actuellement il faut connaître le 
numéro de planche du cadastre).



Si vous trouvez des bugs n'hésitez pas à me les remonter :)



A+

Vincent











Le 3 octobre 2017 à 14:47, Christian Quest 
<cqu...@openstreetmap.fr<mailto:cqu...@openstreetmap.fr>> a écrit :

Oui, officiellement dispo depuis hier... :)



Les données brutes de la DGFiP sont au format EDIGEO, format peu courant mais 
ouvrable avec gdal (donc QGis).



Dans cette première livraison, Etalab propose une extraction des principales 
couches d'infos surfaciques remise au format geojson en WGS84: limites de 
communes, de section cadastrale, de parcelle

Re: [OSM-talk-fr] Publication OpenData du cadastre

[David Marchal]

s fichiers EDIGEO permettent bien plus que ce qu'on a pu faire jusqu'à 
maintenant. On a par exemple les dates de création et de dernière modification 
des objets.
On y trouve aussi des filaires portant les noms des voies pour l'habillage des 
plan... j'ai commencé à travailler dessus pour les rapprocher de FANTOIR, il se 
peut que ce type de traitement soit fait sur les données mises à disposition 
par Etalab en geojson.
D'autres traitements sont aussi envisagés par Etalab pour améliorer les 
données, les lier à d'autres, etc. Ceci devrait arriver d'ici la fin de l'année.

Etalab va aussi mettre en place des API pour interroger ces données, comme ça a 
pu être fait en mettant en place un géocodeur pour faciliter la réutilisation 
de la BAN.


Il mes semble utile qu'on réfléchisse ensemble au meilleur moyen d'exploiter 
ces données et surtout de le penser dans le long terme pour les mises à jour. 
Pour cela, évitons de nous précipiter sur des imports à partir de ces données 
pour l'instant très brutes.
Ces données font parti du "Service Public de la Donnée de Référence" dont le 
slogan est "Des données sur lesquelles vous pouvez compter"... c'est donc là 
pour longtemps ;)


Le 3 octobre 2017 à 14:20, David Marchal 
<pene...@live.fr<mailto:pene...@live.fr>> a écrit :

Cher tous,


Je viens de voir que le cadastre, en tout cas certaines informations, viennent 
d’être publiées en OpenData, et en vectoriel, s’il vous plaît : 
https://www.nextinpact.com/brief/le-cadastre-est-accessible-en-open-data-329.htm
 Sans doute ce que Christian Quest disait être dans les tuyaux. D’emblée, je 
vois l’utilisation du GeoJSON pour l’importation du bâti, mais on doit pouvoir 
en tirer beaucoup plus. Merci à la DGFiP et à Etalab pour ça, ça devrait nous 
aider.


Cordialement.

___
Talk-fr mailing list
Talk-fr@openstreetmap.org<mailto:Talk-fr@openstreetmap.org>
https://lists.openstreetmap.org/listinfo/talk-fr




--
Christian Quest - OpenStreetMap France

___
Talk-fr mailing list
Talk-fr@openstreetmap.org<mailto: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] Publication OpenData du cadastre

[David Marchal]

> Le 4 oct. 2017 à 18:28, Christian Quest <cqu...@openstreetmap.fr> a écrit :
> 
> Le 04/10/2017 à 16:30, David Marchal a écrit :
>> * un truc qu’on perd, je trouve, ou alors je n’ai pas compris comment 
>> l’avoir : on ne peut plus connaître l’étendue d’un lieu-dit, ni son code 
>> FANTOIR d’ailleurs, avec les nouvelles données, car on perd le lien entre 
>> l’étiquette du lieu-dit et son emprise, et ces données ne contiennent pas le 
>> FANTOIR ;
> 
> Il y a une couche correspondant aux emprises des lieux-dits, par contre, tout 
> comme les filaires de voirie, il n'y a pas de lien avec FANTOIR... là aussi, 
> un retraitement intermédiaire serait plus utile qu'un accès direct depuis 
> JOSM.
Je crains de ne pas avoir trouvé laquelle ; j’ai trouvé les fichiers pour les 
limites de sections, de feuilles et de communes, mais pas un pour les limites 
de lieux-dits, qui sont apparemment à plusieurs par section, mais je peux me 
tromper. En plus, comme, autant que je sache, les étiquettes de lieu-dit sont 
rarement au barycentre du polygone alors que c’est censé être le cas pour 
l’import sur OSM, si on perd le lien entre l’étiquette et la limite, on a 
beaucoup de mal à vérifier le placement du nœud place=*.
> 
>> * une autre amélioration possible : si la relation des frontières de la 
>> commune est présente, donner la possibilité de télécharger en un clic tout 
>> ou partie des données publiées pour la commune, grâce au code INSEE présent 
>> dans la relation ;
> 
> Dans quel but ? Pour affichage ou pour retravailler dessus et upload ?
> Vu le volume je crains qu'on fasse de l'import sans réel affinage des données.
Pour affichage, pas pour de l’import massif, surtout sans travail dessus. 
Actuellement, il faut télécharger les différentes données manuellement, mais ça 
devrait pouvoir être automatisé si on a le code INSEE.

> Il me semble utile d'expérimenter et d'explorer ces données, mais d'être très 
> prudent dans un premier temps sur la ré-utilisation qu'on peut en faire.
> 
> Il est urgent d'attendre un peu, surtout que pas mal d'autres choses 
> devraient arriver à courte échéance et qui rendra sûrement l'exploitation des 
> EDIGEO moins intéressante.
> 
> -- 
> Christian Quest - OpenStreetMap France
Cordialement.

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Publication OpenData du cadastre

[David Marchal]

e pense à la mettre 
dans un tag source:date).


J'attends l'API Etalab avec impatience, ça permettra à JOSM de télécharger les 
données du cadastre pour une zone donnée (actuellement il faut connaître le 
numéro de planche du cadastre).


Si vous trouvez des bugs n'hésitez pas à me les remonter :)


A+
Vincent



 



 


Le 3 octobre 2017 à 14:47, Christian Quest  <cqu...@openstreetmap.fr> a écrit :

Oui, officiellement dispo depuis hier... :)


Les données brutes de la DGFiP sont au format EDIGEO, format peu courant mais 
ouvrable avec gdal (donc QGis).


Dans cette première livraison, Etalab propose une extraction des principales 
couches d'infos surfaciques remise au format geojson en WGS84: limites de 
communes, de section cadastrale, de parcelle, et l'emprise des bâtiments.


Des données sont téléchargeables par département et par communes pour les 
geojson et par département et feuille cadastrale pour l'EDIGEO.


Ces données seront mises à jour trimestriellement.




Les nouveautés à venir pour les contributeurs:


- la prochaine version de JOSM va pouvoir ouvrir directement les fichier EDIGEO 
de la DGFiP.
- l'extraction du bâti de  cadastre.openstreetmap.fr deviennent en partie 
inutiles
- les script d'extraction d'adresses de  cadastre.openstreetmap.fr et de BANO 
vont aussi pouvoir évoluer prochainement.


Il y a d'autres données provenant du cadastre qui seront bientôt disponibles:
- le PCI Image et  les localisants de parcelles
- l'historique des évolutions des parcelles (la parcelles XXX est séparée en 
YYY et ZZZ)




Les fichiers EDIGEO permettent bien plus que ce qu'on a pu faire jusqu'à 
maintenant. On a par exemple les dates de création et de dernière modification 
des objets.

On y trouve aussi des filaires portant les noms des voies pour l'habillage des 
plan... j'ai commencé à travailler dessus pour les rapprocher de FANTOIR, il se 
peut que ce type de traitement soit fait sur les données mises à disposition 
par Etalab en geojson.
D'autres traitements sont aussi envisagés par Etalab pour améliorer les 
données, les lier à d'autres, etc. Ceci devrait arriver d'ici la fin de l'année.


Etalab va aussi mettre en place des API pour interroger ces données, comme ça a 
pu être fait en mettant en place un géocodeur pour faciliter la réutilisation 
de la BAN.





Il mes semble utile qu'on réfléchisse ensemble au meilleur moyen d'exploiter 
ces données et surtout de le penser dans le long terme pour les mises à jour. 
Pour cela, évitons de nous précipiter sur des imports à partir de ces données 
pour l'instant très  brutes.
Ces données font parti du "Service Public de la Donnée de Référence" dont le 
slogan est "Des données sur lesquelles vous pouvez compter"... c'est donc là 
pour longtemps ;)

  




Le 3 octobre 2017 à 14:20, David Marchal <pene...@live.fr> a écrit :
  



Cher tous,

Je viens de voir que le cadastre, en tout cas certaines informations, viennent 
d’être publiées en OpenData, et en vectoriel, s’il vous plaît : 
https://www.nextinpact.com/brief/le-cadastre-est-accessible-en-open-data-329.htm
 Sans  doute ce que Christian Quest disait être dans les tuyaux. D’emblée, je 
vois l’utilisation du GeoJSON pour l’importation du bâti, mais on doit pouvoir 
en tirer beaucoup plus. Merci à la DGFiP et à Etalab pour ça, ça devrait nous 
aider.

Cordialement.
  
  ___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

  



 -- 


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

[OSM-talk-fr] Publication OpenData du cadastre

[David Marchal]

Cher tous,


Je viens de voir que le cadastre, en tout cas certaines informations, viennent 
d’être publiées en OpenData, et en vectoriel, s’il vous plaît : 
https://www.nextinpact.com/brief/le-cadastre-est-accessible-en-open-data-329.htm
 Sans doute ce que Christian Quest disait être dans les tuyaux. D’emblée, je 
vois l’utilisation du GeoJSON pour l’importation du bâti, mais on doit pouvoir 
en tirer beaucoup plus. Merci à la DGFiP et à Etalab pour ça, ça devrait nous 
aider.


Cordialement.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] GR 5 Jura cartographié ? Et la FFRP ?

[David Marchal]

Salut, les gens.

Je viens de voir que le GR 5 Jura avait été cartographié 
(https://www.openstreetmap.org/relation/6095322), or il me semblait que, dans 
l’attente d’un accord avec la FFRP concernant l’ajout des GR et de leurs autres 
itinéraires dans OSM, on devait ne pas les ajouter pour éviter tout conflit sur 
leurs droits d’auteurs. Aurais-je manqué un épisode ?

Dans l’attente de vos réponses,

Cordialement.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Plus aucun rapprochement entre OSM et la BANO depuis fin juillet

[David Marchal]

Le 31 août 2017 à 14:31, Christian Quest 
> a écrit :

On 2017-08-30 15:20, Christian Quest wrote:
Les données du cadastre vont être très (très) prochainement disponibles
sur leur forme brute et vectorielle et on n'aura plus à faire ce
bricolage complexe et fragile.

La diffusion a été confiée par la DGFiP à Etalab... c'est pour ça que je peux 
confirmer que c'est près de la sortie du tuyau ;)
 Ah, enfin ! Là, ça va bien mieux faire avancer le Schmilblick pour 
l’exploitation des données cadastrales, plutôt que de devoir faire des 
bidouillages sur les sorties PDF qui prennent du temps à développer, maintenir 
et exécuter. Je ne sais pas à qui on doit ça, mais bien joué, qui que ce soit.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Courbes de niveau ?

[David Marchal]

Bonsoir.

Je vois deux raisons, mais il y en a sans doute d’autres :

  1.  d’une part, ça ferait une quantité gigantesque de données par rapport à 
ce qu’OSM s’est fixé pour but, d’autant plus grande qu’elle augmenterait 
exponentiellement avec la résolution ;
  2.  d’autre part parce que ce n’est pas une donnée qui peut être déterminée 
par le quidam : il faut du matériel spécialisé à petite échelle, et sans doute 
les radars d’un satellite pour le faire à grande échelle, donc ce serait hors 
de portée de virtuellement la totalité des contributeurs.

Cordialement.

Le 23 juin 2017 à 15:45, Lionel Allorge 
> a écrit :

Bonjour,

Merci pour vos réponses.

Y a-t-il une raison historique au fait de ne pas avoir ces courbes de
niveau directement dans la base de données d'OSM ?

Librement.

--
Lionel Allorge
April : http://www.april.org
Lune Rouge : http://www.lunerouge.org
Wikimedia France : http://wikimedia.fr
OpenStreetMap France : http://www.openstreetmap.fr/

« J’entends et j’oublie, Je vois et je me souviens, Je fais et je
comprends. » Confucius

___
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] Disputed border between Greece and Turkey near Imia/Kardak in the Aegean Sea (was: Re: [Geocoding] Boundries of Kardak Islands)

[David Marchal]

If I correctly remember, in such cases, both point of views should be used; in 
this case, two boundary segments should be dragged: one including the islets 
with Greece, and the other one including them with Turkey.

It has already been the case: for instance, the matter of the France-Italia 
border around the Mont-Blanc has never been truly solved: French maps says the 
summit is completely French, while Italian ones says the border crosses the 
summit. Even if the border, while unclear, is not really disputed, as both 
countries merely let it pass, the OSM management for such segment of border is 
that both point of views are displayed.

Anyway, as, in your case, the border is actively disputed, we should draw both; 
I understand that, as a Turk, you could not like that, but OSM must look beyond 
such disputes.

Regards.

Le 30 mars 2017 à 21:41, Florian Schäfer 
> a écrit :


Dear İlhami Özer,

These borders are disputed and the island is claimed by both Greece and Turkey.

There was a recent incident near the island in January: "A Turkish navy missile 
boat accompanied with two special-forces speedboats entered the area around the 
islets on 29 January 2017. According to the statement issued by the Defence 
Ministry of Greece, they were blocked and warned by Greek coast guard vessels 
and withdrew from the area after about seven minutes. The Turkish armed forces 
denied that the ships were blocked but did not otherwise deny the incident; 
they stated that the mission was a part of an inspection of the Aksaz Naval 
Base by chief of General Staff Hulusi Akar, who was on board at the time." 
(Source: Wikipedia article about the 
island)

You (I assume it's you, because of the similarity of your 
username and your real name and the 
proximity of time to your e-mail to the list) now changed the borders to 
reflect your point of view in this changeset yesterday: 
https://openstreetmap.org/changeset/47194531 .

I'm not an expert on borders and how disputed borders are handled in OSM, so I 
forward this to the talk-list, because this probably needs more discussion.

Regards,
Florian

Am 27.03.2017 um 10:36 schrieb ilhami özer:
Dear Openstreetmap valuable workers,

This situation is really important for us. The two islands are within 
bounderies of Turkey Republic. As you can see on the image which we sent 
attachment these two islands out of boundries of Turkey on your tile images. We 
did necessary changes on feature parts. Please can you make these changes on 
your basemap.

Kindly request.

--
İlhami ÖZER
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk-fr] Mise à jour des rendus ?

[David Marchal]

> Le 2 mars 2017 à 06:29, David Marchal <pene...@live.fr> a écrit :
> Ah ! Je pensais que je me faisais des idées, mais apparemment non ; une zone 
> modifiée à des degrés divers depuis une semaine me fait la même chose : 
> certaines tuiles se mettent à jour et d’autres non, et ça change selon les 
> niveaux de zoom.
Je précise que j’ai rechargé cette zone en navigation privée plusieurs fois par 
jour depuis, mais rien à faire, ça ne bouge pas.


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Mise à jour des rendus ?

[David Marchal]

Le 1 mars 2017 à 23:14, pepilepi...@ovh.fr a écrit :

Le 01/03/2017 à 22:25, pepilepi...@ovh.fr a écrit :

Un exemple de rendu problématique :

https://www.openstreetmap.org/#map=18/44.84321/5.05402

À gauche l'ancienne tuile avec une grosse zone vide, et à droite le bare_rock 
que j'ai ajouté.

Si on zoome à 19, les deux tuiles sont bonnes. Si on dézoome à 17 les deux sont 
mauvaises...

Ah ! Je pensais que je me faisais des idées, mais apparemment non ; une zone 
modifiée à des degrés divers depuis une semaine me fait la même chose : 
certaines tuiles se mettent à jour et d’autres non, et ça change selon les 
niveaux de zoom.



Vider le cache du navigateur ?

Non.

De toutes façons avec mon firefox je rafraichis toujours par F5 qui force 
un rechargement complet.

De plus j'ai observé ça sur plusieurs PC.

Bien essayé, merci…

Idem : observé depuis plusieurs navigateurs, et plusieurs connexions.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Nom des cours d’eau dans le cadastre

[David Marchal]

Voici le plan en question : 
https://www.dropbox.com/s/3dnmurzhj3x2bqp/Plan.jpg?dl=0 ; si un connaisseur 
arrive à savoir d’où sort le nom du ruisseau…

Cordialement.

Le 3 févr. 2017 à 09:44, Jérôme Seigneuret 
> a écrit :

Bonjour,
il n'y a rien d'incohérent avec une extraction "dite du cadastre" car il existe 
des outils pour les géomètres avec bases de données déjà enrichies pour 
préparer des plans.
Sinon cela peut être extrait du Géoportail avec la surcouche parcelles 
cadastrales et une autre source de données en fond de plan comme la carte IGN 
en niveau de gris.

exemple

Sinon le géomètre à juste enrichi son fichier DWG...

Donc difficile de dire comment le plan a été réellement créé. Un lien pour voir 
le plan serait mieux pour émettre des hypothèses. Le mieux serait de savoir 
comment le géomètre a créé son plan (outils, données)

Pour moi les noms sont très rarement inscrit sur le plan cadastral.  En plus de 
ça, le nom n'est pas forcément à coté de la parcelle cadastrale concernée par 
par l'emprise géographique du plan en question (surtout si les données 
d'affichage sont au format raster ou rasterisé pour faire le fond de plan.

Jérôme
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Nom des cours d’eau dans le cadastre

[David Marchal]

Le 1 févr. 2017 à 09:27, Vincent de Château-Thierry 
> a écrit :

Ca devient l'exception plutôt que la règle, et tant mieux , mais les noms de 
cours d'eau se trouvent au moins sur des planches du cadastre raster, avec en 
prime parfois une flèche pour le sens d’écoulement.

Après recherches, il semblerait que ce soit bien un plan de géomètre extrait du 
cadastre raster, pas du cadastre vecteur ; on peut toujours accéder aux 
cadastre raster par un WMS, une fois la commune vectorisée, ou faut-il aller 
aux archives départementales ?
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Nom des cours d’eau dans le cadastre

[David Marchal]

Le 31 janv. 2017 à 20:51, Christian Quest 
> a écrit :

Je n'ai jamais vu de nom de cours d'eau dans le cadastre, par contre, nous 
avons la BD Carthage disponible et un rendu est disponible pour la visualiser 
dans JOSM: 
http://tile.openstreetmap.fr/?zoom=13=47.62978=2.73532=B000FT

Ben, moi aussi, ça m’a paru bizarre, étant donné que je n’ai vu ça que sur ce 
plan ; je vais tâcher de remettre la main dessus, mais il me semble bien que la 
typographie du nom était celle des textes des plans cadastraux, même si ce 
n’est pas une preuve. J’essaierai de contacter le bureau d’étude pour savoir 
d’où ils sortent les noms, si ça ne parle à personne d’ici.

Je n’avais jamais prêté attention au calque Carthage ; beaucoup plus de 
ruisseaux que le Sandre n’en référence, manifestement. Par contre, ils semblent 
n’avoir pas plus de noms que le Sandre. Les références Sandre de Carthage 
sont-elles correctes ? Ça m’éviterait d’aller constamment fouiller sur le site 
du Sandre, si le calque Carthage donne le code exact.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Nom des cours d’eau dans le cadastre

[David Marchal]

Chers tous,


Je viens de m’apercevoir que, pour un permis de construire qui m’a été délivré, 
le géomètre ayant fait les plans du dossier de demande à partir du cadastre y a 
inclus le nom d’un ruisseau jouxtant la parcelle, nom manifestement sorti du 
cadastre. Est-il normal que le calque WGS84 Cadastre de jOSM n’affiche pas 
cette information, alors qu’elle semble disponible dans les bases cadastrales, 
et que les URLs d’appel des tuiles du cadastre demandent bien les détails 
hydrologiques ? Ça serait bien utile pour nommer tout un tas de ruisseaux trop 
courts pour apparaître dans la base Sandre.


Dans l’attente de votre réponse,


Cordialement.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Itinéraires et balisages FFRP et Club Vosgien

[David Marchal]

Le 26 janv. 2017 à 09:22, Christian Quest 
> a écrit :

Dans l'équilibre économique actuel de la FFRP il y a des coûts tels que des 
licences sur des logiciels et fonds de cartes ou données qui pourraient aussi 
être revus et réduits en passant sur des outils et données libres.
C’est sûr qu’ils ont aussi à gagner de ce côté, mais je comprends qu’il leur 
faille discuter technique pour estimer les gains à en attendre de leur point de 
vue.

J'ai aussi demandé si la même démarche était faite côté Wikipédia, ce qui 
semble envisagé.
Encore mieux ; au moins, il y a de l’écoute à la FFRP.

Cette (re)prise de contact a aussi permis de désamorcé une tension qui s'était 
accumulée suite au silence de la FFRP à nos questions sur la présence des GR 
dans les données OSM, mais aussi à une mauvaise image d'OSM décrit par certains 
comme extrémistes du tout libre et tout gratuit.
Je ne sais pas pourquoi, mais je m’attendais un peu qu’il y en ait avec cette 
image d’OSM à la FFRP. Tant qu’ils ne bloquent pas la collaboration… Et puis, 
ça permettra peut-être de leur faire voir OSM et les autres projets similaires 
sous un meilleur jour.

TL;DR : pas de scoop […]
Printemps 2017 j’entends.
Bon, Rome ne s’est pas faite en un jour, il paraît. Je vois ça plutôt comme un 
verre à moitié plein, mais j’essaye le positivisme, en ce moment, donc c’est 
peut-être ça… ^^


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk] ODbL and source tags

[David Marchal]

Hello, there.

I’m studying asking authorization for data import to a potential provider, and 
have a question about the ODbL: does it mandate the preservation of source 
tags, or at least including their content in the re-using DB disclaimer? The 
potential data provider could be more easily convinced if I could guarantee him 
that.

Awaiting your answer,

Regards.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk-fr] Itinéraires et balisages FFRP et Club Vosgien

[David Marchal]

> Le 22 janv. 2017 à 13:06, sly (sylvain letuffe)  a écrit :
> 
> Puis-je suggérer le wiki.openstreetmap.org ? cela permettra à plus de monde
> à mon avis d'y participer (pas besoin de compte github qui fait d'ailleurs
> un peu "tech") pour ceux ayant déjà un compte sur le wiki et non sur github.
Tu as raison sur ce point ; étant un tech, j’ai l’habitude de Github à tout 
propos.

> Je retrouve d'ailleurs la page :
> https://wiki.openstreetmap.org/wiki/Ffrp-lettre-ouverte
> que j'avais créée en 2012 et qui ressemble pas mal à l'idée que tu as (et
> qui résumait jusqu'en ~2013 ou nous en étions, les liens, les tentatives,
> les non réponses, etc.)
> Peut-être peut on partir de cette page pour lister toutes les initiatives et
> faire un lien vers la lettre que tu vas écrire ?
Je verrai à mesure que j’avance comment lier ça aux pages existantes, mais je 
comptais de toute façon intégrer les arguments déjà cités sur ces pages, mon 
but étant surtout d’arriver à un courrier plus ou moins prêt à l’emploi, pour 
faire avancer les démarches.

> Je soutiens évidement à donf l'initiative et m'impliquerait volontiers pour
> relecture et participation sous toute formes.
Noté. ;)

> Si Christian a en entretient la semaine prochaine, ça ne coûte rien
> d'attendre 7 jours de plus pour lui demander ce que ça à donner et entendre
> un "rien n'a avancé depuis 10 ans" ;-)
De toute façon, ça n’aboutira pas avant plusieurs semaines, donc la réunion et 
ses conséquences ont tout le temps d’arriver.

> Je donne l'impression d'être mauvaise langue mais j'ai une sensation de déjà
> vu, en 2012 quand on a voulu écrire une lettre, on a entendu du : "à mais on
> va avoir un rdv avec eux, ça a de grande chance d'avancer" et puis ça à
> parlé de tout mais les personnes de la FFRP ont systématiquement botté en
> touche ce genre de demandent dans un plus pur style "noyade de poisson"
> 
> En clair, je soutiens encore plus ton initiative et ne pas se laisser
> intoxiquer par des "attendez, on va en discuter en commité machin qui aura
> lieu dans 3 mois »
Même si la FFRP décide de ne pas bouger, un courrier type de ce genre pourrait 
servir pour convaincre d’autres organismes. Je pense notamment au Club Vosgien, 
dont la signalétique ne se limite pas au massif des Vosges, et dont les 
sentiers ont tendance à être plus nombreux et diversifiés. Après, c’est sûr que 
ce courrier serait un bon point de départ pour présenter les avantages et 
questions de droit à d’autres fournisseurs de données intéressantes.

Et puis, ce n’est pas forcément être mauvaise langue ; ce dossier traîne depuis 
des années, sans avancée concrète, et ce n’est manifestement pas faute d’avoir 
essayé. Les contributeurs OSM n’ayant aucune structure réelle, il est normal 
que les questions de ce genre soient plus longues à être traitées, mais, là, je 
ne pense pas que le problème se situe côté OSM.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Itinéraires et balisages FFRP et Club Vosgien

[David Marchal]

> Le 21 janv. 2017 à 22:47, Vincent de Château-Thierry  a 
> écrit :
> 
> Bonsoir,
> @David : ton initiative (quel timing :)) n'a pas forcément besoin de 
> déboucher sur un courrier formel, mais ce peut être une bonne occasion de 
> synthétiser les attentes, régulièrement abordées ici mais avec une passion 
> qui rend certains fils ardus à lire. Je pense par exemple à ce thread monstre 
> (courage) :
> https://lists.openstreetmap.org/pipermail/talk-fr/2012-June/thread.html#44315
> Et si tu es dispo mercredi (10h, Paris XIII), bien sûr, ça le fait.

Effectivement, quelle coïncidence ! Eus-je été sur Paris, ç’eut été avec 
plaisir, mais je ne peux me permettre de faire un tel voyage. Dommage, j’aurais 
été heureux de pouvoir vous assister ; j’attends le compte-rendu avec 
impatience, ça m’aidera à savoir quoi mettre en avant dans mon texte s’il 
s’avère toujours d’actualité après ça. Bonne chance à toi et Christian Quest.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Itinéraires et balisages FFRP et Club Vosgien

[David Marchal]

Chers tous,

Je relance un sujet maintes fois discuté, et pourtant jamais résolu, ni vers 
l’ajout, ni vers la suppression : les itinéraires de randonnées de la FFRP et, 
accessoirement du Club Vosgien. Tout d’abord, avant de faire celui qui sait, y 
aurait-il eu du mouvement à ce sujet ces derniers temps ?

Ensuite, s’il n’y a rien de nouveau, je voulais suggérer quelque chose. Ça me 
trotte dans la tête depuis quelques temps déjà : de nombreuses idées sur le 
comment ont été lancées, mais aucune n’est arrivée à son terme. À mon humble 
avis, étant donné que c’est, autant que je sache, la centrale de la FFRP qui 
déteint les droits sur les itinéraires et les marques GR, GRP et PR, il 
faudrait leur demander l’autorisation. Si des tiers, des clubs locaux ou autres 
voulaient leur disputer cette propriété intellectuelle, ce serait déjà fait, je 
pense, donc, étant donné que la FFRP exerce sereinement cette propriété 
intellectuelle depuis des décennies, on peut partir du principe qu’ils ont, de 
fait, cette propriété intellectuelle, donc que c’est bien à eux qu’il faut 
s’adresser. De plus, si on commence à polémiquer sur le fait qu’ils n’ont pas 
tous les droits qu’ils prétendent avoir, on va se les mettre à dos, et perdre 
toute chance de collaboration, sauf à régler ça au tribunal, mais là, on 
s’embarque dans pire encore, point de vue résultat, frais et bonne volonté de 
part et d’autre, d’autant que, je le répète, personne ne leur conteste ces 
droits. Bref, les prendre à rebrousse-poil serait contreproductif, d’autant que 
les attaquer au nom de droits de tiers qui ne les réclament pas ne me semble 
pas pertinent. 

Afin de ne pas faire les choses dans mon coin, je pensais faire un brouillon de 
courrier que je publierai sur Github, afin de vous permettre à tous d’y 
proposer des modifications, lesquelles seraient ensuite fusionnées au brouillon 
sur avis positif de la majorité. Je me représente ce courrier comme un courrier 
à la centrale qui, sans entrer dans le jargon juridique, leur expliquerait 
clairement les conséquences sur leur propriété intellectuelle, les avantages à 
en retirer pour eux comme pour nous, et le peu d’inconvénient que cela aurait 
pour eux, puisque ces données, même si elles pourraient leur retirer des 
rentrées d’argent, ne devraient en réalité ne pas leur retirer grand-chose, 
étant donné le précédent néerlandais, si ma mémoire est bonne.

Afin de ne pas leur faire trop peur, je pense ne demander l’autorisation que 
pour les itinéraires, les marques GR, PR et GRP et le numéro de sentier pour la 
référence, et les métadonnées éventuelles comme le nom, la difficulté, la 
distance ou le temps de parcours. Cela n’inclurait toutefois pas les marquages 
; d’une part, ils sont assez connus pour que leur omission ne change pas 
grand-chose en pratique pour OSM, d’autant qu’ils sont toujours les mêmes ; 
d’autre part, ça leur laisserait la possibilité de refuser les réutilisations 
payantes sans droits d’auteur, simplement en refusant à l’éditeur le droit 
d’utiliser les marquages. Je pense que ce compromis leur ferait moins peur que 
le tout-ouvert, surtout étant donnés les droits de réutilisations accordés par 
l’ODbL. À ce sujet, l’ODbL oblige bien la préservation des sources de données 
telles que définies dans les tags « source » ? De cette façon, on pourrait leur 
montrer que ce n’est pas du pillage et qu’ils resteront crédités quoi qu’il 
arrive. Enfin, étant donné que la grande majorité des cartes existantes de 
sentiers FFRP est faite sur des fonds de cartes IGN, il faudra tracer leurs 
sentiers par des parcours effectifs, ce qui prendra du temps étant donné , dans 
l’éventualité improbable d’une impact significatif, il sera très progressif.

Pour le Club Vosgien, qui détient les mêmes droits que la FFRP sur une part non 
négligeable des sentiers, au moins ceux du Grand Est, je comptais leur demander 
la même chose, avec de surcroît l’autorisation d’enregistrer leur balisage sur 
les tags « osmc:symbol ». En effet, les sentiers du CV tendent à se recouper 
beaucoup plus souvent que ceux de la FFRP, et le nombre de leurs variations les 
rend beaucoup plus utiles pour se repérer et suivre un sentier que les 3 
marquages de la FFRP. De plus, si les associations PR-jaune, GRP-jaune et rouge 
et GR-blanc et rouge est aisée et connue de nombre de randonneurs, les symboles 
du CV sont plus variés et dotés d’une signification plus complète et moins 
connue : anneau = boucle d’une demi-journée, losange=sentiers 
interdépartementaux… Ils sont également répétés bien plus souvent que ceux de 
la FFRP et sont donc plus utiles en randonnée en cas de doute sur l’itinéraire, 
d’autant plus que les couleurs sont choisies justement pour éviter que deux 
itinéraires au balisage identique ne se croisent. Enfin, en lisant les 
documentations de la FFRP et du CV, et ayant eu des contacts avec des membres 
des deux organismes, j’ai la nette impression que le CV sera plus ouvert à 
l’intégration 

Re: [OSM-talk-fr] massif du mont-blanc

[David Marchal]

Bonjour.

En fait, il n'y a pas encore de modélisation standardisée des massifs 
montagneux ; j'avais posé la question je ne sais plus où, et les diverses 
réponses montraient plusieurs problèmes parmi lesquels :
* la divergence des définitions de ces  massifs, qui ne sont en fait bien 
définis géographiquement que dans les Alpes ; ailleurs, il n'y a pas de 
définition universelle des massifs ;
* la délimitation précise des massifs (fond de vallée ? haut des montagnes 
limitrophes ?)
* sans doute autre chose.

Mais vous pouvez proposer vos idées sur le sujet, si vous le souhaitez.

Cordialement.

De : Florian LAINEZ [winner...@free.fr]
Envoyé : mercredi 19 octobre 2016 15:59
À : Discussions sur OSM en français
Objet : [OSM-talk-fr]  massif du mont-blanc

hello,
je n'arrive pas à trouver la relation qui décrit le massif du mont blanc, c'est 
à dire la délimitation du tour de tout le massif montagneux. J'avais dans 
l'idée de lui adjoindre le tag wikipedia.
Je suis nul ou il n'existe pas encore ? Je n'ai pas trouvé de tag sur le wiki 
pour décrire de massif montagneux donc pas possible de faire de requête 
overpass.
Help !

--

Florian Lainez

[http://twitter.com/favicon.ico]@overflorian

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Accès proxy BD Ortho en HTTPS (pour iD !)

[David Marchal]

Ah, chouette! Merci ! Une visibilité pour la prise en compte dans 
l'autoconfiguration jOSM de ce calque ? Et pour le calque préconfiguré du 
cadastre, tant qu'à faire ?

De : Christian Quest [cqu...@openstreetmap.fr]
Envoyé : lundi 17 octobre 2016 17:04
À : Discussions sur OSM en français
Objet : [OSM-talk-fr] Accès proxy BD Ortho en HTTPS (pour iD !)

Il y a désormais un beau certificat SSL letsencrypt tout neuf sur le
proxy d'accès à la BD Ortho.

Ceci devrait faciliter l'accès depuis iD !

Du coup double A pour
https://www.ssllabs.com/ssltest/analyze.html?d=proxy-ign.openstreetmap.fr


--
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] Différence affichage cadastre iD/jOSM

[David Marchal]

Je connaissait ce mode d'affichage du cadastre, mais il oblige à changer de 
projection et à passer en Lambert, incompatible avec les photos satellites ; 
pour croiser les données, c'est très chiant. Comme ce sont les noms qui 
m'intéressent, le calque Cadastre préconfiguré suffit souvent, mais les textes 
sont souvent tronqués, et devoir changer de projection sans arrêt n'est pas 
pratique ; quitte à utiliser une approximation du vrai cadastre, pourquoi ne 
pas utiliser celle d'iD par défaut, puisqu'elle est apparemment meilleure ?

De : Tyndare [tynd...@wanadoo.fr]
Envoyé : mercredi 12 octobre 2016 16:43
À : talk-fr@openstreetmap.org
Objet : Re: [OSM-talk-fr] Différence affichage cadastre iD/jOSM

iD et JOSM n'utilisent pas la même source de donnée pour déterminer la
liste des images disponibles par défaut selon la région affichée mais
j'ai l'impression que la définition pour les tuiles du cadastre
utilisent pourtant bien le même serveur TMS:
http://tms.cadastre.openstreetmap.fr/*/tout/{zoom}/{x}/{y}.png

Comme expliqué à l'origine par Frédéric Rodrigo, pour éviter les
problèmes de saut aux frontières, il est possible de n'afficher les
tuiles que d'une seule commune en particulier en spécifiant dans
l'éditeur un serveur personnalisé qui utilise l'URL précédant dans
lequel on remplace le * par le code INSEE de la commune voulue:

https://lists.openstreetmap.org/pipermail/talk-fr/2015-February/075223.html

Je crois que la configuration par défaut pour JOSM est définie ici:
https://josm.openstreetmap.de/wiki/Maps/France#Cadastre

et que celle pour iD est définie ici:
https://github.com/osmlab/editor-layer-index/blob/gh-pages/sources/europe/fr/FR-Cadastre.geojson



___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Différence affichage cadastre iD/jOSM

[David Marchal]

Bonjour à tous.

Question idiote : pourquoi l'affichage du cadastre est-il aussi propre sur iD, 
alors que, sur jOSM, il est tout moche : noms tronqués, tracé de limites 
sautant sans arrêt… L'affichage d'iD n'est pas irréprochable, mais il me semble 
bien meilleur que celui de jOSM, alors pourquoi ne pas utiliser le même serveur 
de tuiles ?

Dans l'attente de vos lumières,

Cordialement.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Conflit entre les sources et le terrain sur une limite intercommunale

[David Marchal]

Sinon, il y a ceci : http://ws.carmencarto.fr/WMS/105/ONF_Forets? qui donne 
accès à 2 WMS dans jOSM, un pour les forêts et l'autre pour les parcelles. Pas 
sûr toutefois de la fraîcheur des données, mais ça peut préparer le boulot 
avant d'aller relever. Par contre, comme précisé 
(http://www.onf.fr/onf/sommaire/donnees_publiques/donnees_publiques/20100607-151633-435455/@@index.html),
 ces données représentent ce qui est géré par l'ONF comme une forêt, donc ça 
n'en est pas forcément et il n'y a pas toutes les zones boisées ; c'est 
particulièrement visible quand on compare avec l'imagerie satellite.


Pas besoin de tricher sur les tags pour les parcelles : un (multi)polygone par 
parcelle avec le numéro en ref=*, un multipolygone qui les regroupe pour la 
forêt elle-même, et le tour est joué 
(https://www.openstreetmap.org/search?query=nancy#map=14/48.6688/6.1029). De 
toute façon, la question de savoir si les données sont rendues ou pas est une 
fausse question, à mon avis : si on ne met pas les infos qu'on a, elles ne 
seront jamais rendues, puisqu'il n'y aura rien à afficher ; par ailleurs, ce 
n'est pas parce que les informations ne sont pas rendues qu'elles sont 
inutiles, par exemple les maxspeed=* qui sont surtout destinées aux GPS 
routiers, et pas pour les dessiner sur une carte.


De : Philippe Verdy 
Envoyé : jeudi 6 octobre 2016 12:29
À : Discussions sur OSM en français
Objet : Re: [OSM-talk-fr] Conflit entre les sources et le terrain sur une 
limite intercommunale

Je vois des "old" partout. Pas convaincu qu'on ait un accès direct aux données 
actualisées (à moins de 5 ou 10 ans; ceci dit le cadastre tel qu'il est publié 
n'est souvent pas non plus à jour depuis des années concernant l'at des 
propriétés et constructions).

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Conflit entre les sources et le terrain sur une limite intercommunale

[David Marchal]

ens pour revenir sur un chemin 
balisé, et utiliser une boussole pour éviter de tourner en rond face à des 
obstacles infranchissables (le sol est souvent accidenté sous le couvert 
végétal étagé, même si ça ne se voit pas sur l'imagerie aérienne). Aussi je ne 
vois pas l'intérêt de mettre dans OSM autre chose que les chemins balisés (le 
reste est toujours aux risques et périls du promeneur, même si ce n'est pas 
réellement clôturé autour). Dans les domaines forestiers publics, les 
carrefours forestiers (avec parkings, aires de pique-nique, poubelles, points 
d'eau et parfois des toilettes publiques) ont souvent des panneaux 
d'information signalant les zones déconseillées/dangereuses/en travaux, où il 
vaut mieux ne pas s'aventurer: ce devrait être le lieu de départ de toute 
balade.


Le 5 octobre 2016 à 14:27, David Marchal 
<pene...@live.fr<mailto:pene...@live.fr>> a écrit :

En parlant des données de l'ONF, est-ce que certaines indiquent les noms des 
bois et leurs limites, par exemple « Bois du Hameau » ou « Saint-Pierre Bois », 
au lieu de « Forêt communale de Trifouillis-les-trois-oies » ? Peut-être des 
données utilisables provenant d'autres fournisseurs contiennent ces 
informations ?

Cordialement.

________
De : David Marchal
Envoyé : mercredi 5 octobre 2016 14:22
À : Discussions sur OSM en français
Objet : RE: [OSM-talk-fr] Conflit entre les sources et le terrain sur une 
limite intercommunale


Effectivement, c'est ça : les données de l'ONF confirment que la forêt 
communale de A empiète sur le territoire de P. J'apprends donc qu'il est 
possible qu'une forêt communale ne soit pas entièrement sur le territoire de 
ladite commune ; c'est sans doute parce que la forêt communale relève du 
domaine privé de la commune, lequel n'est pas, que je sache, limité au 
territoire de ladite commune.


Est-ce que cette possibilité est déjà mentionnée sur le Wiki ? Sinon, où 
pourrais-je la mentionner, que d'autres ne tombent pas dans le même panneau.

Cordialement.


De : Jérôme Amagat <jerome.ama...@gmail.com<mailto:jerome.ama...@gmail.com>>
Envoyé : mercredi 5 octobre 2016 12:36
À : Discussions sur OSM en français
Objet : Re: [OSM-talk-fr] Conflit entre les sources et le terrain sur une 
limite intercommunale

la forêt communale de A et peut-être en parti sur la commune de P. Les forêts 
communales peuvent être dans une autre commune.
Il y a les limites des foret communale ici : 
http://carmen.carmencarto.fr/105/ONF_Forets.map


Le 5 octobre 2016 à 11:58, Francescu GAROBY 
<windu...@gmail.com<mailto:windu...@gmail.com>> a écrit :
Bonjour David,

Joli problème que tu nous poses là !
Vu tes explications (claires), il s'agit au mieux d'une erreur commise par A, 
au pire d'une intention malhonnête !
Dans les 2 cas, rien ne venant étayer que A est dans son bon droit (pas de 
traces d'une décision votée en conseil municipal de A et/ou de P ?), je ne 
pense pas que modifier OSM pour coller à la réalité du terrain soit une bonne 
idée. Non seulement, tu cartographierais des données que tu sais fausses, mais 
en plus tu leur donnerais une reconnaissance !

Pour moi, c'est en dehors d'OSM qu'il faut agir, pour soit corriger la 
numérotation des parcelles, soit rendre officielle cette attribution par A 
d'une partie de P.

Francescu

Le 5 octobre 2016 à 11:42, David Marchal 
<pene...@live.fr<mailto:pene...@live.fr>> a écrit :

Chers tous,


J'ai constaté une bizarrerie en explorant les chemins d'un bois à l'aide d'une 
carte IGN 1:25000, et j'aurais voulu avoir votre avis. Le bois dont je parle 
est partagé entre 3 communes – et 2 départements, quoique ce détail n'ait rien 
à voir avec le problème, les deux communes dont je parlerai étant dans le même 
département – et est sillonné de nombreux layons et chemins que je voulais 
explorer pour en préparer la cartographie, le jour où j'aurais un traceur GPS. 
Dans ce bois, les parcelles sont numérotées et portent le nom de la commune, à 
défaut son initiale ; comme les 3 communes ont chacune une initiale différente, 
il n'y a pas de confusion. Je précise que je n'ai aucune source disant que les 
panonceaux numérotant les parcelles communales peuvent porter l'initiale de la 
commune au lieu de son nom complet ; j'ai déduit cette possibilité de mes 
passages dans les bois environnants, et je n'ai jamais pris cette déduction en 
défaut jusqu'alors, malgré des dizaines de visites forestières similaires.


J'ai passé une demi-heure à tourner en rond, ne comprenant pas, d'après mes 
déplacements, où je me trouvais sur la carte IGN, avant de comprendre : 
certaines parcelles d'une commune, P, sont étiquetées avec l'initiale de 
l'autre, A. Tout se passe comme si A avait annexé une partie des bois de P : en 
suivant le chemin traversant le bois depuis A, les numéros de parcelles se 
suivent – 14 et 13, 12 et 11… –, puis, à l'endroit où la carte IGN indique que 
le chemi

Re: [OSM-talk-fr] Conflit entre les sources et le terrain sur une limite intercommunale

[David Marchal]

En parlant des données de l'ONF, est-ce que certaines indiquent les noms des 
bois et leurs limites, par exemple « Bois du Hameau » ou « Saint-Pierre Bois », 
au lieu de « Forêt communale de Trifouillis-les-trois-oies » ? Peut-être des 
données utilisables provenant d'autres fournisseurs contiennent ces 
informations ?

Cordialement.


De : David Marchal
Envoyé : mercredi 5 octobre 2016 14:22
À : Discussions sur OSM en français
Objet : RE: [OSM-talk-fr] Conflit entre les sources et le terrain sur une 
limite intercommunale


Effectivement, c'est ça : les données de l'ONF confirment que la forêt 
communale de A empiète sur le territoire de P. J'apprends donc qu'il est 
possible qu'une forêt communale ne soit pas entièrement sur le territoire de 
ladite commune ; c'est sans doute parce que la forêt communale relève du 
domaine privé de la commune, lequel n'est pas, que je sache, limité au 
territoire de ladite commune.


Est-ce que cette possibilité est déjà mentionnée sur le Wiki ? Sinon, où 
pourrais-je la mentionner, que d'autres ne tombent pas dans le même panneau.

Cordialement.


De : Jérôme Amagat <jerome.ama...@gmail.com>
Envoyé : mercredi 5 octobre 2016 12:36
À : Discussions sur OSM en français
Objet : Re: [OSM-talk-fr] Conflit entre les sources et le terrain sur une 
limite intercommunale

la forêt communale de A et peut-être en parti sur la commune de P. Les forêts 
communales peuvent être dans une autre commune.
Il y a les limites des foret communale ici : 
http://carmen.carmencarto.fr/105/ONF_Forets.map


Le 5 octobre 2016 à 11:58, Francescu GAROBY 
<windu...@gmail.com<mailto:windu...@gmail.com>> a écrit :
Bonjour David,

Joli problème que tu nous poses là !
Vu tes explications (claires), il s'agit au mieux d'une erreur commise par A, 
au pire d'une intention malhonnête !
Dans les 2 cas, rien ne venant étayer que A est dans son bon droit (pas de 
traces d'une décision votée en conseil municipal de A et/ou de P ?), je ne 
pense pas que modifier OSM pour coller à la réalité du terrain soit une bonne 
idée. Non seulement, tu cartographierais des données que tu sais fausses, mais 
en plus tu leur donnerais une reconnaissance !

Pour moi, c'est en dehors d'OSM qu'il faut agir, pour soit corriger la 
numérotation des parcelles, soit rendre officielle cette attribution par A 
d'une partie de P.

Francescu

Le 5 octobre 2016 à 11:42, David Marchal 
<pene...@live.fr<mailto:pene...@live.fr>> a écrit :

Chers tous,


J'ai constaté une bizarrerie en explorant les chemins d'un bois à l'aide d'une 
carte IGN 1:25000, et j'aurais voulu avoir votre avis. Le bois dont je parle 
est partagé entre 3 communes – et 2 départements, quoique ce détail n'ait rien 
à voir avec le problème, les deux communes dont je parlerai étant dans le même 
département – et est sillonné de nombreux layons et chemins que je voulais 
explorer pour en préparer la cartographie, le jour où j'aurais un traceur GPS. 
Dans ce bois, les parcelles sont numérotées et portent le nom de la commune, à 
défaut son initiale ; comme les 3 communes ont chacune une initiale différente, 
il n'y a pas de confusion. Je précise que je n'ai aucune source disant que les 
panonceaux numérotant les parcelles communales peuvent porter l'initiale de la 
commune au lieu de son nom complet ; j'ai déduit cette possibilité de mes 
passages dans les bois environnants, et je n'ai jamais pris cette déduction en 
défaut jusqu'alors, malgré des dizaines de visites forestières similaires.


J'ai passé une demi-heure à tourner en rond, ne comprenant pas, d'après mes 
déplacements, où je me trouvais sur la carte IGN, avant de comprendre : 
certaines parcelles d'une commune, P, sont étiquetées avec l'initiale de 
l'autre, A. Tout se passe comme si A avait annexé une partie des bois de P : en 
suivant le chemin traversant le bois depuis A, les numéros de parcelles se 
suivent – 14 et 13, 12 et 11… –, puis, à l'endroit où la carte IGN indique que 
le chemin traverse la limite communale entre A et P, la numérotation des 
parcelles de A continue – 4 et 3, 2 et 1 –, et les plaques portant les numéros 
portent toujours un A, comme si j'étais toujours sur le territoire de A. C'est 
plusieurs hectomètres plus loin seulement que la numérotation change subitement 
et porte le P de la commune sur laquelle je suis censé me trouver depuis 
plusieurs hectomètres de chemin. J'en déduis donc que la limite communale entre 
A et P a de fait été repoussée, dans ce bois, au détriment de la commune P.


J'ai d'abord pensé que ma carte IGN n'était pas à jour, mais le cadastre ne 
porte pas non plus trace d'un déplacement de cette limite communale, ni sur 
cadastre.gouv.fr<http://cadastre.gouv.fr>, ni sur le Géoportail ; d'ailleurs, 
sur le Géoportail, ni le calque des limites administratives, ni les calques de 
cartes ou plan IGN, ni les calques cadastraux ne montrent la limite communale 
const

Re: [OSM-talk-fr] Conflit entre les sources et le terrain sur une limite intercommunale

[David Marchal]

Effectivement, c'est ça : les données de l'ONF confirment que la forêt 
communale de A empiète sur le territoire de P. J'apprends donc qu'il est 
possible qu'une forêt communale ne soit pas entièrement sur le territoire de 
ladite commune ; c'est sans doute parce que la forêt communale relève du 
domaine privé de la commune, lequel n'est pas, que je sache, limité au 
territoire de ladite commune.


Est-ce que cette possibilité est déjà mentionnée sur le Wiki ? Sinon, où 
pourrais-je la mentionner, que d'autres ne tombent pas dans le même panneau.

Cordialement.


De : Jérôme Amagat <jerome.ama...@gmail.com>
Envoyé : mercredi 5 octobre 2016 12:36
À : Discussions sur OSM en français
Objet : Re: [OSM-talk-fr] Conflit entre les sources et le terrain sur une 
limite intercommunale

la forêt communale de A et peut-être en parti sur la commune de P. Les forêts 
communales peuvent être dans une autre commune.
Il y a les limites des foret communale ici : 
http://carmen.carmencarto.fr/105/ONF_Forets.map


Le 5 octobre 2016 à 11:58, Francescu GAROBY 
<windu...@gmail.com<mailto:windu...@gmail.com>> a écrit :
Bonjour David,

Joli problème que tu nous poses là !
Vu tes explications (claires), il s'agit au mieux d'une erreur commise par A, 
au pire d'une intention malhonnête !
Dans les 2 cas, rien ne venant étayer que A est dans son bon droit (pas de 
traces d'une décision votée en conseil municipal de A et/ou de P ?), je ne 
pense pas que modifier OSM pour coller à la réalité du terrain soit une bonne 
idée. Non seulement, tu cartographierais des données que tu sais fausses, mais 
en plus tu leur donnerais une reconnaissance !

Pour moi, c'est en dehors d'OSM qu'il faut agir, pour soit corriger la 
numérotation des parcelles, soit rendre officielle cette attribution par A 
d'une partie de P.

Francescu

Le 5 octobre 2016 à 11:42, David Marchal 
<pene...@live.fr<mailto:pene...@live.fr>> a écrit :

Chers tous,


J'ai constaté une bizarrerie en explorant les chemins d'un bois à l'aide d'une 
carte IGN 1:25000, et j'aurais voulu avoir votre avis. Le bois dont je parle 
est partagé entre 3 communes – et 2 départements, quoique ce détail n'ait rien 
à voir avec le problème, les deux communes dont je parlerai étant dans le même 
département – et est sillonné de nombreux layons et chemins que je voulais 
explorer pour en préparer la cartographie, le jour où j'aurais un traceur GPS. 
Dans ce bois, les parcelles sont numérotées et portent le nom de la commune, à 
défaut son initiale ; comme les 3 communes ont chacune une initiale différente, 
il n'y a pas de confusion. Je précise que je n'ai aucune source disant que les 
panonceaux numérotant les parcelles communales peuvent porter l'initiale de la 
commune au lieu de son nom complet ; j'ai déduit cette possibilité de mes 
passages dans les bois environnants, et je n'ai jamais pris cette déduction en 
défaut jusqu'alors, malgré des dizaines de visites forestières similaires.


J'ai passé une demi-heure à tourner en rond, ne comprenant pas, d'après mes 
déplacements, où je me trouvais sur la carte IGN, avant de comprendre : 
certaines parcelles d'une commune, P, sont étiquetées avec l'initiale de 
l'autre, A. Tout se passe comme si A avait annexé une partie des bois de P : en 
suivant le chemin traversant le bois depuis A, les numéros de parcelles se 
suivent – 14 et 13, 12 et 11… –, puis, à l'endroit où la carte IGN indique que 
le chemin traverse la limite communale entre A et P, la numérotation des 
parcelles de A continue – 4 et 3, 2 et 1 –, et les plaques portant les numéros 
portent toujours un A, comme si j'étais toujours sur le territoire de A. C'est 
plusieurs hectomètres plus loin seulement que la numérotation change subitement 
et porte le P de la commune sur laquelle je suis censé me trouver depuis 
plusieurs hectomètres de chemin. J'en déduis donc que la limite communale entre 
A et P a de fait été repoussée, dans ce bois, au détriment de la commune P.


J'ai d'abord pensé que ma carte IGN n'était pas à jour, mais le cadastre ne 
porte pas non plus trace d'un déplacement de cette limite communale, ni sur 
cadastre.gouv.fr<http://cadastre.gouv.fr>, ni sur le Géoportail ; d'ailleurs, 
sur le Géoportail, ni le calque des limites administratives, ni les calques de 
cartes ou plan IGN, ni les calques cadastraux ne montrent la limite communale 
constatée sur le terrain. Si les communes avaient changé la limite les 
séparant, il devrait y avoir des traces de cette modification ; j'ai en tout 
cas du mal à croire que rien ne mentionne cet acte : personne dans le village A 
n'a jamais parlé d'un agrandissement de la commune, la question n'a pas été, à 
ma connaissance, posée devant le conseil municipal de A, et aucune carte n'en 
fait mention, pas même le cadastre. En fait, la situation est telle qu'elle 
serait si A avait subitement décidé, officieusement et sans en référer à 
personne, d'agrandir son boi

[OSM-talk-fr] Conflit entre les sources et le terrain sur une limite intercommunale

[David Marchal]

Chers tous,


J'ai constaté une bizarrerie en explorant les chemins d'un bois à l'aide d'une 
carte IGN 1:25000, et j'aurais voulu avoir votre avis. Le bois dont je parle 
est partagé entre 3 communes – et 2 départements, quoique ce détail n'ait rien 
à voir avec le problème, les deux communes dont je parlerai étant dans le même 
département – et est sillonné de nombreux layons et chemins que je voulais 
explorer pour en préparer la cartographie, le jour où j'aurais un traceur GPS. 
Dans ce bois, les parcelles sont numérotées et portent le nom de la commune, à 
défaut son initiale ; comme les 3 communes ont chacune une initiale différente, 
il n'y a pas de confusion. Je précise que je n'ai aucune source disant que les 
panonceaux numérotant les parcelles communales peuvent porter l'initiale de la 
commune au lieu de son nom complet ; j'ai déduit cette possibilité de mes 
passages dans les bois environnants, et je n'ai jamais pris cette déduction en 
défaut jusqu'alors, malgré des dizaines de visites forestières similaires.


J'ai passé une demi-heure à tourner en rond, ne comprenant pas, d'après mes 
déplacements, où je me trouvais sur la carte IGN, avant de comprendre : 
certaines parcelles d'une commune, P, sont étiquetées avec l'initiale de 
l'autre, A. Tout se passe comme si A avait annexé une partie des bois de P : en 
suivant le chemin traversant le bois depuis A, les numéros de parcelles se 
suivent – 14 et 13, 12 et 11… –, puis, à l'endroit où la carte IGN indique que 
le chemin traverse la limite communale entre A et P, la numérotation des 
parcelles de A continue – 4 et 3, 2 et 1 –, et les plaques portant les numéros 
portent toujours un A, comme si j'étais toujours sur le territoire de A. C'est 
plusieurs hectomètres plus loin seulement que la numérotation change subitement 
et porte le P de la commune sur laquelle je suis censé me trouver depuis 
plusieurs hectomètres de chemin. J'en déduis donc que la limite communale entre 
A et P a de fait été repoussée, dans ce bois, au détriment de la commune P.


J'ai d'abord pensé que ma carte IGN n'était pas à jour, mais le cadastre ne 
porte pas non plus trace d'un déplacement de cette limite communale, ni sur 
cadastre.gouv.fr, ni sur le Géoportail ; d'ailleurs, sur le Géoportail, ni le 
calque des limites administratives, ni les calques de cartes ou plan IGN, ni 
les calques cadastraux ne montrent la limite communale constatée sur le 
terrain. Si les communes avaient changé la limite les séparant, il devrait y 
avoir des traces de cette modification ; j'ai en tout cas du mal à croire que 
rien ne mentionne cet acte : personne dans le village A n'a jamais parlé d'un 
agrandissement de la commune, la question n'a pas été, à ma connaissance, posée 
devant le conseil municipal de A, et aucune carte n'en fait mention, pas même 
le cadastre. En fait, la situation est telle qu'elle serait si A avait 
subitement décidé, officieusement et sans en référer à personne, d'agrandir son 
bois au détriment de celui de P.


J'ai donc plusieurs questions :

  1.  suis-je censé, selon le principe Map what's on the ground, modéliser sur 
OSM les limites constatées sur le terrain ?
  2.  en dehors d'OSM, dois-je attirer l'attention de l'administration sur le 
problème, et attendre leur réponse avant d'agir sur OSM ?

Je précise que l'administration de A est connue dans les environs pour son 
interprétation très personnelle des lois et que ses affouagistes ont déjà été 
rappelés à l'ordre par l'ONF pour la dégradation qu'ils causent aux chemins 
forestiers en y passant en tracteur sans les laisser s'assécher suffisamment ; 
de ce fait, cela ne m'étonnerait guère que ce changement de limite ait été 
effectué en douce pour agrandir artificiellement la surface forestière de A au 
bénéfice de ses affouagistes.

Je ne suis pas impartial dans cette histoire, étant en conflit avec 
l'administration de A, mais, même si ce changement de limite était une simple 
erreur – quoique cela me paraisse improbable si la délimitation sur le terrain 
est faite dans les règles de l'art – ou un changement officialisé en bonne et 
due forme – encore plus improbable, puisque ni les habitants, ni l'IGN, ni le 
cadastre, ni les conseils municipaux n'en font mention –, ne faudrait-il pas 
tout de même attirer l'attention de la préfecture sur cette incohérence, 
puisque les limites intercommunales sont de son ressort autant que je sache ?


Dans l'attente de vos réponses,


Cordialement.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Consultation sur la mise en oeuvre du Service public de la donnée

[David Marchal]

Bonjour à tous.

Je viens de voir 
(http://www.nextinpact.com/news/101573-loi-numerique-tous-decrets-sous-six-mois-premiere-consultation-en-ligne.htm)
 que le projet de loi Numérique a été adopté par le Parlement. De nombreux 
décrets d'application sont à définir, dont un qui nous concerne, qui regarde le 
Service public de la donnée - en gros, les bases de données, comme le cadastre, 
qui devront être libres d'accès et de réutilisation. Pour définir ce décret, 
une consultation publique a été lancée ici : 
https://www.etalab.gouv.fr/consultation-spd ; on vous y demande quelles sont 
les bases à ouvrir, et sous quelles conditions, donc n'hésitez pas à y demander 
un meilleur accès au cadastre ou à toute autre base utile à OSM !

Cordialement.

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk] Applicability of wiki tagging and votes: may, should or must

[David Marchal]

Hello, there.On a GitHub issue 
(https://github.com/gravitystorm/openstreetmap-carto/issues/2027#issuecomment-174443685),
 I've been told that Wiki tagging votes are only advisory and that the 
community is only invited, neither required nor recommended, to follow them. As 
I understand this comment, the community MAY follow the Wiki tagging or votes, 
it does not SHOULD nor MUST follow them. I was under the impression that the 
community at least SHOULD apply the votes results, MUST looking unenforceable 
due to the free tagging principle. Am I wrong on that? What is the 
applicability of the Wiki content?Hoping my question isn't too trivial,Regards. 
  ___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Applicability of wiki tagging and votes: may, should or must

[David Marchal]

To: talk@openstreetmap.org
From: ajt1...@gmail.com
Date: Thu, 28 Jan 2016 19:50:11 +
Subject: Re: [OSM-talk] Applicability of wiki tagging and votes: may, should or 
must
More seriously, any dataset that has no rules enforced at the API level must be 
assumed to have data in it that doesn't meet a specification that is written 
down somewhere, but not enforced.  Someone wrote that wiki page long ago but 
didn't actually do anything else, presumably expecting the magic code and 
project management fairies to look after all the other changes that they 
expected to happen.
I know that the free tagging scheme is one of the main strenghts of OSM, and 
I'm aware of its advantages for modelling the real world, which per se contains 
elements that will never fit in a strict tagging scheme. My point is, there are 
multiple references (editors, Wiki, MLs, and, maybe a bit consumers), which 
regularly contradict one another about what they assume to be the "correct" 
tagging; it would be far more coherent to have a single reference, that users 
SHOULD follow whenever possible, which would be the start of each debate, 
transcript its end and the decisi,ons made, and which would centralize tagging 
defs and their modifications. This way, the undocumented tagging could be 
reduced, at least the unnecessary, unnecessarily confusing part, and increase 
the DB usability for consumers, who would be less required to adjust to the 
different, virtually unlimited, existing tagging schemes.
Note: I use SHOULD as defined in the IETF RFCs 
(https://www.ietf.org/rfc/rfc2119.txt), that is: mean that there may exist 
valid reasons in particular circumstances to ignore a particular item, but the 
full implications must be understood and carefully weighed before choosing a 
different course.   ___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk