date:20130621

Wikipédia a souvent des conventions inconsistantes pour ses noms de pages.
Mais c'est difficile à appliquer (alors que cela simplifierait bien des
situations et des modèles comme la production et la maintenance des
palettes de navigation et infobox). Souvent la règle de la dénomination la
plus courante emporte et on n'ajoute pas la précision sur un des articles
homonymes (chois souvent subjectif et basé sur la popularité dans un pays
donné).

Sur Commons le problème est plus aigu encore quand les noms retenus pour
des toponymes situés en France ne sont pas toujours en français (on en
trouve aussi en anglais, exemple : Corsica; les précisions ajoutées sur
Commons utilisent les conventions soit francophones (entre parenthèses)
soit anglophones (après une virgule, ou rien avant un terme générique avec
ou sans majuscule comme River ou river, plus les conflits entre
orthographes anglophones), la seule règle étant premier créé, premier servi.

Les noms de pages n'obéissent à aucune règle précise, surtout en cas
d'homonymies. les liens de redirection posent aussi problèmes régulièrement
(direct vers un des articles, tous les autres devant être modifiés, et pas
de page d'homonymie unique ou ne devrait y avoir que de très courts
paragraphes pour chaque usage, même si aucune ébauche d'article séparée
n'est créé qui n'apporterait rien de plus). Et c'est encore pire pour es
noms de personnalités avec les alias, les noms avant ou après les mariages,
les titres honorifiques, les nombre de prénoms, les translitérations, etc.
même si Wikidata commence à y mettre de l'ordre (mais tend aussi à figer
les situations pour limiter les renommages)...



Le 21 juin 2013 09:29, Francescu GAROBY windu...@gmail.com a écrit :

 Sur Wikipedia, je n'ai jamais compris pourquoi la page vers
 l'arrondissement de Caen ne s'appelait pas Caen (arrondissement), comme
 c'est l'usage pour beaucoup d'autres pages homonymes...
 Une telle façon de nommer les pages élimineraient de facto les nombreuses
 erreurs à cause des de,du,d',de la, que soulève Nicolas.

 Francescu


 Le 21 juin 2013 08:08, Damouns damo...@gmail.com a écrit :

 Le 20 juin 2013 20:55, Nicolas Moyroud nmoyr...@free.fr a écrit :
  Dans wikipedia je rajoute donc un nom aux liens sans aucun morceau
 ajouté,
  juste le nom de l'entité. Le lien lui-même donne déjà la version
 complète
  Canton de... mais plus le texte affiché dans l'infobox sur la page.

 Dans le cas de l'infobox c'est écrit Canton : Untel donc évidemment
 que c'est superflu d'écrire Canton de...

 Mon idée est que dans une phrase en français courant, 99,9% des
 phrases contenant Pontarlier ou Issoire désignent la commune, et
 pas le canton de Pontarlier ni l'arrondissement d'Issoire. Et ce même
 dans un contexte où on parle du canton : Aux dernières élections
 cantonales Blaye a voté pour... moi je le comprends comme la commune
 de Blaye a voté pour...

 Damouns

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




 --
 Cordialement,
 Francescu GAROBY

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


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

Re: [OSM-talk-fr] Parcelle numérotée - Forêt domaniale

2013-06-21 Par sujet Vincent Pottier


Le 21/06/2013 10:12, PhQ a écrit :

Au sujet des numéros de Parcelle des surfaces forestières gérées par l'ONF :

La surface forestière est stable sur des périodes longues, car en dehors des
acquisitions ou des échanges, la vente est soumis à autorisation du
Parlement, sauf présence de bande(s) organisée(s) - foret/hippodrome de
Compiègne.

En revanche, les numéros de Parcelle peuvent changer tous les quinze ou
vingt ans en fonction de l'humeur productiviste du responsable (changement
de pratique sylvicole) nécessitant une réorganisation du découpage et de la
numérotation des dites parcelles.

Il n'en demeure pas moins vrai que dans les grandes unités forestières,
cette numérotation constitue un repère significatif pour s'orienter (en
l'absence de GPS).
On trouvera tous les numéros de parcelle sur
http://carmen.carmencarto.fr/105/ONF_Forets.map
mais j'émets un doute sur la mise à jour de ces données.
Par exemple en auvergne, des restructurations juridiques de forets
sectionales  en entité de Syndicat Mixte de Gestion Forestière (SMGF)
communales ne sont pas pris en compte alors que leur création date d'au
moins 15 ans 

le tag name me semble approprié pour ces parcelles qui devrait être découpé
selon les wiki avec des cutline
Hum... étrange de mettre un numéro de parcelle dans un name... Un 
ref:FR:ONF ne seraiat pas plus adéquat ?

--
FrViPofm

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

Re: [OSM-talk-fr] Balise name/short_description (était : Parcelle numérotée - Forêt domaniale)

2013-06-21 Par sujet JB

 

+1. 

Il faudra quand même que je l'écrive, ce mél sur la balise name. Mais en
gros, pour moi, il manque une alternative à cette balise name, du genre
short_description, qui serait utilisée pour le rendu en l'absence de
balise name. Les Église de Trifouillis, Cimetières de Les-Oies, Gite
d'Étape, Fontaine, Linteau 1452, Mairie (2845 selon Taginfo), Chemin
Rural, Cimetière (1800), Calvaire (1500), Église (1200), etc, etc, etc… 

Quand je suis de bon poil, je les déplace vers « description », quand je
suis de mauvaise humeur, je les supprime, quand je suis calme, je n'y
touche pas. Mais pour moi, on est dans du taggage pour le rendu, et
puisque les débutants tagguent souvent pour le rendu, il leur faudrait
cette alternative au name. 

Et lors de cartopartie, je mets toujours une couche pour dire que «
Cimetière », ce n'est pas un nom. Ni « Église », ni « Parking ». 

Est-ce que certains se reconnaissent là-dedans ? Est-ce que ça vous
semble une idée à creuser ou à enterrer vite fait ? 

JB. 

Le 21.06.2013 10:22, Vincent Pottier a écrit : 

 Le 21/06/2013 10:12, PhQ a écrit :
 
 Au sujet des numéros de Parcelle des surfaces forestières gérées par l'ONF : 
 La surface forestière est stable sur des périodes longues, car en dehors des 
 acquisitions ou des échanges, la vente est soumis à autorisation du 
 Parlement, sauf présence de bande(s) organisée(s) - foret/hippodrome de 
 Compiègne. En revanche, les numéros de Parcelle peuvent changer tous les 
 quinze ou vingt ans en fonction de l'humeur productiviste du responsable 
 (changement de pratique sylvicole) nécessitant une réorganisation du 
 découpage et de la numérotation des dites parcelles. Il n'en demeure pas 
 moins vrai que dans les grandes unités forestières, cette numérotation 
 constitue un repère significatif pour s'orienter (en l'absence de GPS). On 
 trouvera tous les numéros de parcelle sur 
 http://carmen.carmencarto.fr/105/ONF_Forets.map [1] mais j'émets un doute 
 sur la mise à jour de ces données. Par exemple en auvergne, des 
 restructurations juridiques de forets sectionales en en
 tité de
Syndicat Mixte de Gestion Forestière (SMGF) communales ne sont pas pris en 
compte alors que leur création date d'au moins 15 ans  le tag name me 
semble approprié pour ces parcelles qui devrait être découpé selon les wiki 
avec des cutline
 
 Hum... étrange de mettre un numéro de parcelle dans un name... Un 
 ref:FR:ONF ne seraiat pas plus adéquat ?
 --
 FrViPofm
 
 ___
 Talk-fr mailing list
 Talk-fr@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-fr [2]

 

Links:
--
[1] http://carmen.carmencarto.fr/105/ONF_Forets.map
[2] http://lists.openstreetmap.org/listinfo/talk-fr
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Outil d'import des adresses : Bordeaux, Montpellier, Lyon


Bonjour,

Le même outil que pour l'import des adresses de Nantes Métropole à été 
mise en place pour :

- Communauté Urbaine de Bordeaux
http://osm7.openstreetmap.fr/~fred/adresses/bordeaux/
- Grand Lyon
http://osm7.openstreetmap.fr/~fred/adresses/lyon
- Ville de Montpellier
http://osm7.openstreetmap.fr/~fred/adresses/montpellier

Voilà ce qui avait été mis en place pour Nantes :
http://wiki.osm.org/Nantes/Adresses_postales_Nantes_M%C3%A9tropole

Également disponible deux analyses Osmose :
- détection des manques depuis les données OpenData
http://osmose.openstreetmap.fr/fr/errors/?item=8080
- analyses sur les numéros des rues
http://osmose.openstreetmap.fr/fr/errors/?item=2060

Frédéric.

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

Re: [OSM-talk-fr] Parcelle numérotée - Forêt domaniale

2013/6/21 david.croc...@online.fr:

Que faire de cette information : Ref: , Name: ou autre ou rien ou bof.

D'abord, il faut voir si ce parcellaire est disponible pour nous (et
pas aller voir chez l'IGN comme on le lit sur le forum, hein). Je
trouve une source sur le site de l'ONF qui donne des conditions
d'utilisation incompatibles OSM: [1] (La revente de ces données est
interdite.)
Depuis le site data.gouv.fr, on trouve ([2]) un WMS ([3]) avec une
license LO/OL.
On peut juste espérer que le site data.gouv.fr ne se trompe pas et que
le site de l'ONF est en retard. Mais comme on a déjà trouvé des
données pas vraiment libres chez-eux, il faudrait peut-être demander à
l'ONF avant d'aller plus loin.

Plus généralement, je suis assez réfractaire à l'ajout des contours
parcellaires dans OSM, on le sait. Le même débat a eu lieu dans
d'autres pays où cette info est disponible mais les expérimentations
sont restées très limitées. Il y a un réel problème de
complexification de la représentation du territoire pour les
contributeurs moyens. Un landuse=forest se retrouve découpé en une
multitude de petits polygones. Il faudrait par exemple mettre le nom
de la forêt sur une relation regroupant toutes ces polygones de
parcelles, sans être sûr que tous les polygones soient bien du
forestier, etc...
De plus, le découpage parcellaire est administratif et ne correspond
pas toujours exactement au couvert forestier. Si on accepte cette
démarche, on ne pourra ensuite pas empêcher l'ajout des parcelles
privées, qui représentent les 3/4 des forêts en France ([4]).
Par contre, je comprends bien l'utilité des panneaux pour le repérage
des randonneurs le long des sentiers/routes. Pourquoi ne pas
cartographier simplement ces panneaux ? avec un tag du genre
information=guidepost ou une autre valeur à inventer ?

Pieren

[1]
http://www.onf.fr/onf/sommaire/donnees_publiques/donnees_publiques/20100607-151633-435455/4/++files++/1
[2] http://www.data.gouv.fr/DataSet/551053
[3] http://carmen.carmencarto.fr/105/ONF_Forets.map
[4]
http://fr.wikipedia.org/wiki/For%C3%AAt_en_France#La_propri.C3.A9t.C3.A9_de_la_for.C3.AAt_en_France
[5] http://wiki.openstreetmap.org/wiki/Tag:information=guidepost?uselang=en

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

Re: [OSM-talk-fr] Balise name/short_description (était : Parcelle numérotée - Forêt domaniale)

2013-06-21 Par sujet Christian Rogel

Le 21 juin 2013 à 10:42, JB jb...@mailoo.org a écrit :

Il faudra quand même que je l'écrive, ce mél sur la balise name. Mais en gros, 
pour moi, il manque une alternative à cette balise name, du genre 
short_description, qui serait utilisée pour le rendu en l'absence de balise 
name. Les Église de Trifouillis, Cimetières de Les-Oies, Gite d'Étape, 
Fontaine, Linteau 1452, Mairie (2845 selon Taginfo), Chemin Rural, Cimetière 
(1800), Calvaire (1500), Église (1200), etc, etc, etc…
 Quand je suis de bon poil, je les déplace vers « description », quand je suis 
 de mauvaisep://l
 

Dans toute cette liste, il n'y a que 2 ou 3 éléments qui me semblent 
discutables.
Il est normal de de mettre de qui est écrit à la porte et sur les panneaux.
Dire que c'est taguer pour le rendu est une forme d'extrémisme.
Pourtant, il n'y a pas que des éléments de terrain qui doivent être pris en 
compte.
Une normalisation peut intervenir à la marge.
C'est le cas des églises et chapelles qui doivent être complétés, quand il n'y 
a pas d'inscription par le nom du saint auquel elles sont dédiées. Eglise de 
Trifouillis-les-Oies est donc fautif, mais pas pour la raison que tu indiques.
les Mosquées et les synagogues ont aussi des noms et il est normal d'indiquer 
mosquée X.
C'est leur nom.
Les Allemand écrivent Nom du saintkirche; les distingués germanistes de la 
liste peuvent-ils nous dire, s'ils sont agités par cette fièvre purificatrice 
qui conduit à vouloir les rendus basiques de plus en plus abstraits et éloignés 
des gens au noms de les logiciels font tout.
Un peu de mesure dans le geekisme ne serait pas inapproprié.

Christian R.___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Balise name/short_description (était : Parcelle numérotée - Forêt domaniale)

2013-06-21 Par sujet Christian Quest

Le 21 juin 2013 10:42, JB jb...@mailoo.org a écrit :

 **

 +1.

 Il faudra quand même que je l'écrive, ce mél sur la balise name. Mais en
 gros, pour moi, il manque une alternative à cette balise name, du genre
 short_description, qui serait utilisée pour le rendu en l'absence de balise
 name. Les Église de Trifouillis, Cimetières de Les-Oies, Gite d'Étape,
 Fontaine, Linteau 1452, Mairie (2845 selon Taginfo), Chemin Rural,
 Cimetière (1800), Calvaire (1500), Église (1200), etc, etc, etc…

 Quand je suis de bon poil, je les déplace vers « description », quand je
 suis de mauvaise humeur, je les supprime, quand je suis calme, je n'y
 touche pas. Mais pour moi, on est dans du taggage pour le rendu, et puisque
 les débutants tagguent souvent pour le rendu, il leur faudrait cette
 alternative au name.

 Et lors de cartopartie, je mets toujours une couche pour dire que «
 Cimetière », ce n'est pas un nom. Ni « Église », ni « Parking ».

 Est-ce que certains se reconnaissent là-dedans ? Est-ce que ça vous semble
 une idée à creuser ou à enterrer vite fait ?



Tout ce qui peut être décrit par les tags adapté ne devrait pas figurer en
name=* sauf lorsque cela fait vraiment partie du nom (distinction entre une
description et un nom).

Souvent c'est une forme de tag pour le rendu, mais aussi lié à l'éditeur
avec une tendance à vouloir remplir un maximum de champs proposés par
celui-ci qui fait qu'on a ce genre de redondance.
Les contributeurs débutant se sentent invités à remplir un maximum de
champs...

Il m'est arrivé de faire du nettoyage en virant par exemple les
name=Boulangerie sur des shop=bakery

-- 
Christian Quest - OpenStreetMap France
Un nouveau serveur pour OSM... http://donate.osm.org/server2013/
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Balise name/short_description (était : Parcelle numérotée - Forêt domaniale)

2013-06-21 Par sujet Eric Sibert


Dans la catégorie, on tag pour le rendu, j'ai trouvé récemment :

amenity=parking
name=gratuit

building=yes
name=Hôtel de Ville
(il faut que j'aille voir su le terrain, ce n'est certainement pas la  
mairie en plus)


tourims=attraction
name=Casino

Avant de l'embrouiller sur des short_description, faut peut-être lui  
expliquer qu'on ne tag pas pour le rendu :-p


Eric



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

Re: [OSM-talk-fr] (Etait: IGN Route 500 ...) enfin un moyen pour uniformiser notre classification des highway ?

2013-06-21 Par sujet Francescu GAROBY

Ton classement est intéressant, mais tu as oublié le highway=trunk, que
l'on attribuerait aux vocation=Type autoroutier sans
class_adm=autoroute (correspondant aux highway=motorway.

Francescu


Le 19 juin 2013 12:02, Pieren pier...@gmail.com a écrit :

 2013/6/19 V de Chateau-Thierry v...@laposte.net:
  Bonjour,
  Il ne me semble pas avoir déjà vu passer cette info : la base
 vectorielle de l'IGN
  Route 500 est disponible en téléchargement sur le site de l'IGN, sous
 licence LO/OL.

 Je trouve la documentation suivante sur la classification des routes:

 Champ ID_RTE500
 Définition : identifiant ROUTE 500® du tronçon de route
 Type : numérique
 Champ VOCATION
 Définition : vocation de la liaison. Ce champ matérialise une
 hiérarchisation du réseau routier basée, non pas sur un critère
 administratif, mais sur l’importance des tronçons de route pour le
 trafic routier. Ainsi, les quatre valeurs « type autoroutier », «
 liaison principale », « liaison régionale » et « liaison locale »
 permettent un maillage de plus en plus dense du territoire.
 Type : chaîne
 Valeurs possibles :
 - Type autoroutier
 - Liaison principale
 - Liaison régionale
 - Liaison locale
 - Bretelle
 - Inconnue

 J'y vois enfin un moyen de résoudre un problème récurrent dans OSM,
 celui des différentes interprétrations des classifications de highway.
 Ici, nous avons un moyen de nous accorder sur une source de référence.
 Bien-sûr, comme la source est souvent en retard, il faudrait rester
 flexible mais il faudrait justifier tout changement par rapport à la
 référence. On peut imaginer une correspondance:
 - Type autoroutier = highway=motorway
 - Liaison principale = highway=primary
 - Liaison régionale = highway=secondary
 - Liaison locale = highway=tertiary et inférieur (unclassified,
 residential)
 - Bretelle = highway=*_link
 - Inconnue = ?

 Cela nous permettrait déjà de corriger les problèmes de
 primary/secondary assez rapidement et de manière cohérente sur
 toute la métropole, non ?

 Pieren

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




-- 
Cordialement,
Francescu GAROBY
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Parcelle numérotée - Forêt domaniale

2013-06-21 Par sujet PhQ

Pour la constitution des données parcellaires domaniales: l'Etat via la
gestion de l'ONF (domaine privé de l'Etat)

Pour les forets de collectivités (Communes, Département, Caisse d’Épargne
etc) :
le parcellaire est un élément de l'aménagement qui est soumis à
l'approbation des collectivités et dont la mise en place est payé par les
dites collectivités 

Je me garderais bien de définir un droit de propriété intellectuel sur ces
limites, en l'absence d'expérience sur le sujet même après 35 ans d'activité
à l'ONF



--
View this message in context: 
http://gis.19327.n5.nabble.com/Parcelle-numerotee-Foret-domaniale-tp5766304p5766345.html
Sent from the France mailing list archive at Nabble.com.

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

Re: [OSM-talk-fr] Parcelle numérotée - Forêt domaniale

Sans aller jusqu'au découpage des parcelles, le repérage des sections
forestières est celui utilisé sur les panneaux (ou marquages peints sur
les arbres), et c'est lui qui sera utile au randonneur.

Cependant ces numéros de sections sont souvent placés le long d'un sentier,
qui devrait être cartographié. Du coup autant mettre les numéros de section
sur les noeuds de ces sentiers, à proximité immédiate de leurs
intersections.

C'est là d'ailleurs, sur ces intersections de sentiers, que l'information
sera recherchée et la plus utile, là que le couvert forestier est le plus
dégagé et où un GPS capterait mieux la position la plus précise, qui peut
sinon être assez approximative en milieu de parcelle où on zigzague entre
les arbres, ou la couverture végétale du sous-bois, les ronces, et les
fossés de drainage (qui pourraient être représentés aussi dans OSM, de même
que les passerelles facilement franchissables sans détremper ses
chaussures, ni faire un saut périlleux au risque de se fouler une cheville
ou s'étaler dans le trou an martyrisant son sweet-shirt ou déchirant son
pantalon, au mieux, ou en s'écorchant les genoux, mains et coudes pour se
rattraper ou les fesses).



Le 21 juin 2013 11:15, Pieren pier...@gmail.com a écrit :

 2013/6/21  david.croc...@online.fr:

  Que faire de cette information : Ref: , Name: ou autre ou rien ou bof.

 D'abord, il faut voir si ce parcellaire est disponible pour nous (et
 pas aller voir chez l'IGN comme on le lit sur le forum, hein). Je
 trouve une source sur le site de l'ONF qui donne des conditions
 d'utilisation incompatibles OSM: [1] (La revente de ces données est
 interdite.)
 Depuis le site data.gouv.fr, on trouve ([2]) un WMS ([3]) avec une
 license LO/OL.
 On peut juste espérer que le site data.gouv.fr ne se trompe pas et que
 le site de l'ONF est en retard. Mais comme on a déjà trouvé des
 données pas vraiment libres chez-eux, il faudrait peut-être demander à
 l'ONF avant d'aller plus loin.

 Plus généralement, je suis assez réfractaire à l'ajout des contours
 parcellaires dans OSM, on le sait. Le même débat a eu lieu dans
 d'autres pays où cette info est disponible mais les expérimentations
 sont restées très limitées. Il y a un réel problème de
 complexification de la représentation du territoire pour les
 contributeurs moyens. Un landuse=forest se retrouve découpé en une
 multitude de petits polygones. Il faudrait par exemple mettre le nom
 de la forêt sur une relation regroupant toutes ces polygones de
 parcelles, sans être sûr que tous les polygones soient bien du
 forestier, etc...
 De plus, le découpage parcellaire est administratif et ne correspond
 pas toujours exactement au couvert forestier. Si on accepte cette
 démarche, on ne pourra ensuite pas empêcher l'ajout des parcelles
 privées, qui représentent les 3/4 des forêts en France ([4]).
 Par contre, je comprends bien l'utilité des panneaux pour le repérage
 des randonneurs le long des sentiers/routes. Pourquoi ne pas
 cartographier simplement ces panneaux ? avec un tag du genre
 information=guidepost ou une autre valeur à inventer ?

 Pieren

 [1]
 http://www.onf.fr/onf/sommaire/donnees_publiques/donnees_publiques/20100607-151633-435455/4/++files++/1
 [2] http://www.data.gouv.fr/DataSet/551053
 [3] http://carmen.carmencarto.fr/105/ONF_Forets.map
 [4]
 http://fr.wikipedia.org/wiki/For%C3%AAt_en_France#La_propri.C3.A9t.C3.A9_de_la_for.C3.AAt_en_France
 [5]
 http://wiki.openstreetmap.org/wiki/Tag:information=guidepost?uselang=en

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

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

Re: [OSM-talk-fr] Outil d'import des adresses : Bordeaux, Montpellier, Lyon

2013-06-21 Par sujet rldhont


Bonjour Frédérico,

Comment peut-on proposer un nouveau jeu de données et donc intégrer de 
nouvelles données ?


Je pense à Arles dont les données sont disponibles ici :
http://opendata.regionpaca.fr/donnees/detail/base-de-donnees-adresses-de-laccm.html

René-Luc

Le 21/06/2013 10:49, Frédéric Rodrigo a écrit :

Bonjour,

Le même outil que pour l'import des adresses de Nantes Métropole à été 
mise en place pour :

- Communauté Urbaine de Bordeaux
http://osm7.openstreetmap.fr/~fred/adresses/bordeaux/
- Grand Lyon
http://osm7.openstreetmap.fr/~fred/adresses/lyon
- Ville de Montpellier
http://osm7.openstreetmap.fr/~fred/adresses/montpellier

Voilà ce qui avait été mis en place pour Nantes :
http://wiki.osm.org/Nantes/Adresses_postales_Nantes_M%C3%A9tropole

Également disponible deux analyses Osmose :
- détection des manques depuis les données OpenData
http://osmose.openstreetmap.fr/fr/errors/?item=8080
- analyses sur les numéros des rues
http://osmose.openstreetmap.fr/fr/errors/?item=2060

Frédéric.

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



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

Re: [OSM-talk-fr] Noms de cantons et d'arrondissements (était : Recherche d'une adresse par Nominatim)

2013/6/21 Damouns damo...@gmail.com:

 Mon idée est que dans une phrase en français courant, 99,9% des
 phrases contenant Pontarlier ou Issoire désignent la commune

Il est évident que tout document, officiel ou pas, citant Caen ou
Pontarlier tout seul, fait référence à la ville.
Notre malheur est que le COG présente les cantons dans un tableau avec
le nom du chef-lieu en dessous de la colonne marquée Canton et que
certains ont pris le nom de ce chef-lieu pour le nom du canton
lui-même.
Exemple:
http://www.insee.fr/fr/methodes/nomenclatures/cog/canarr.asp?codedep=14codearr=2

Alors que lorsqu'on va dans la fiche détail d'un canton:
http://www.insee.fr/fr/methodes/nomenclatures/cog/comcan.asp?codedep=14codecan=06

on parle bien de Canton de Bourguébus (06).
(à noter, le bug du COG sur Canton de Caen 1er Canton (08)

100% favorable pour nommer les choses par leur nom. Mettez canton de
au début ou (canton) à la fin, peu importe, mais évitons les
homonymies inutiles avec un peu de bon sens commun.

Pieren

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

Re: [OSM-talk-fr] Balise name/short_description (était : Parcelle numérotée - Forêt domaniale)

2013/6/21 Christian Quest cqu...@openstreetmap.fr:
 quand je suis de mauvaise humeur, je les supprime,

 Il m'est arrivé de faire du nettoyage en virant par exemple les
 name=Boulangerie sur des shop=bakery

Wow, wow, wow !!! Je trouve que vous y allez fort. Cool down.
La boulangerie a sûrement un nom. Utiliser un tag name est donc
correct. Y mettre juste Boulangerie, c'est incomplet, mais pas faux.
C'est sûr que ça me dérange aussi, un nom incomplet mais il suffit de
soit ajouter les infos manquantes, soit passer son chemin.
De même, mettre name=Chemin rural ou Chemin d'exploitation sur un
highway=track est une vrai information (on a parlé sur un autre fil
des conséquences qui peuvent être juridiques).
Allez-y molo avec les suppressions et respectez d'avantage les
contributions des autres.

Pieren

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

Re: [OSM-talk-fr] (Etait: IGN Route 500 ...) enfin un moyen pour uniformiser notre classification des highway ?

2013/6/21 Francescu GAROBY windu...@gmail.com:
 Ton classement est intéressant, mais tu as oublié le highway=trunk, que
 l'on attribuerait aux vocation=Type autoroutier sans class_adm=autoroute
 (correspondant aux highway=motorway.

Oui, c'est sans doute à affiner. Et à mettre proprement sur le wiki si
on peut se mettre d'accord pour s'en servir à harmoniser les types de
highway dans OSM.

Pieren

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

Re: [OSM-talk-fr] (Etait: IGN Route 500 ...) enfin un moyen pour uniformiser notre classification des highway ?

On a aussi la classification des (auto)routes européennes en deux classes A
et B, la première ayant aussi deux sous-classes.

Avec les amendements de la norme initale (vers 1973 pour la première
version il me semble) et l'extension de la classification vers l'Est et le
Sud de l'Europe, jusqu'à aujourd'hui l'Asie mineure et centrale (voire
probablement aussi au delà en Afrique du Nord), la classification basée sur
le format du numéro à 2 ou 3 chiffres n'est déjà plus suffisante, et celle
basée sur les tranches de numéros, la parité et les dizaines ne suffit plus
(quand viennent s'y ajouter les diverses liaisons et interconnections).

Cette norme européenne (en fait 'une agence européenne de l'ONU) d'ailleurs
a déjà subi un profond bouleversement de sa numérotation, et il est
probable qu'elle sera revue (tout en tenant compte du besoin exprimé par
certains pays de ne pas avoir à changer leur signalisation existante non
seulement sur ces itinéraires, mais aussi sur leur réseau secondaire à
proximité, le coût étant prohibitif.

De fait les règles initiale de numérotation sont de moins en moins
indicatives, et certains pays militent pour une classification européenne
tenant compte des capacités et formats des routes empruntées (notamment
pour le transport routier international des camions et cars), et prenant en
compte aussi les voies de ferroutage lentement en cours d'aménagement, les
liaisons maritimes, voire de possibles liaisons fluviales pour les
containers sur des barges ou péniches pour un transport certes plus lent
mais plus économique et plus écologique, adapté à de nombreuses charges pas
trop rapidement périssables:

Comme le bois de construction, le ciment, le sable les graviers qu'on va
chercher de plus en plus loin, les produits de déblayage ou de remblais
recyclés de chantiers et destinés à des lieux de stockage et
redistribution, les matériaux métalliques, les fenêtres et huisseries,
portes, volets,, la quincaillerie, les meubles, les tubes, le câblage, les
peintures, détergents, solvants et divers produits chimiques de l'industrie
ou ménagers, les semences, terraux et engrais (agricoles ou de jardinage),
l'outillage, les films plastique et bâches, les clôtures et même le papier
ou cartonnag en grosse capacité, ainsi que les besoins de transport de
matières brutes alimentant les filières de recyclage.

Cette classification européenne devrait aussi qualifier des sous-réseaux
adaptés à certains transports potentiellement dangereux ou polluants ou à
surveiller, ainsi que les besoin de planification des transports pour la
longue distance favorisant l'écartement des aires urbaines.



Le 21 juin 2013 11:35, Francescu GAROBY windu...@gmail.com a écrit :

 Ton classement est intéressant, mais tu as oublié le highway=trunk, que
 l'on attribuerait aux vocation=Type autoroutier sans
 class_adm=autoroute (correspondant aux highway=motorway.

 Francescu


 Le 19 juin 2013 12:02, Pieren pier...@gmail.com a écrit :

 2013/6/19 V de Chateau-Thierry v...@laposte.net:
  Bonjour,
  Il ne me semble pas avoir déjà vu passer cette info : la base
 vectorielle de l'IGN
  Route 500 est disponible en téléchargement sur le site de l'IGN, sous
 licence LO/OL.

 Je trouve la documentation suivante sur la classification des routes:

 Champ ID_RTE500
 Définition : identifiant ROUTE 500® du tronçon de route
 Type : numérique
 Champ VOCATION
 Définition : vocation de la liaison. Ce champ matérialise une
 hiérarchisation du réseau routier basée, non pas sur un critère
 administratif, mais sur l’importance des tronçons de route pour le
 trafic routier. Ainsi, les quatre valeurs « type autoroutier », «
 liaison principale », « liaison régionale » et « liaison locale »
 permettent un maillage de plus en plus dense du territoire.
 Type : chaîne
 Valeurs possibles :
 - Type autoroutier
 - Liaison principale
 - Liaison régionale
 - Liaison locale
 - Bretelle
 - Inconnue

 J'y vois enfin un moyen de résoudre un problème récurrent dans OSM,
 celui des différentes interprétrations des classifications de highway.
 Ici, nous avons un moyen de nous accorder sur une source de référence.
 Bien-sûr, comme la source est souvent en retard, il faudrait rester
 flexible mais il faudrait justifier tout changement par rapport à la
 référence. On peut imaginer une correspondance:
 - Type autoroutier = highway=motorway
 - Liaison principale = highway=primary
 - Liaison régionale = highway=secondary
 - Liaison locale = highway=tertiary et inférieur (unclassified,
 residential)
 - Bretelle = highway=*_link
 - Inconnue = ?

 Cela nous permettrait déjà de corriger les problèmes de
 primary/secondary assez rapidement et de manière cohérente sur
 toute la métropole, non ?

 Pieren

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




 --
 Cordialement,
 Francescu GAROBY

 ___
 Talk-fr mailing list

[OSM-talk-fr] Code postal de Dampierre-sur-Avre

2013-06-21 Par sujet Aurélien FILEZ

Bonjour à tous,

En exploitant les code postaux des villes françaises dans OpenStreetMap, je
me suis aperçu d'une faute de frappe dans celui de Dampierre-sur-Avre :

http://www.openstreetmap.org/browse/relation/1903407

Le code postal n'est pas 282350 mais 28350.

En revanche, je ne sais pas comment corriger ça, car avec l'éditeur
Potlatch, lorsque je sélectionne la relation, ça ne sélectionne que des
way frontières avec les villes limitrophes.

Est-ce que quelqu'un peut corriger ça ? Ou mieux, m'expliquer comment je
peux le faire moi même via Potlatch.

Merci à vous,

A bientôt,

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

Re: [OSM-talk-fr] Parcelle numérotée - Forêt domaniale

2013/6/21 PhQ pierre.que...@sfr.fr:

 Je me garderais bien de définir un droit de propriété intellectuel sur ces
 limites, en l'absence d'expérience sur le sujet même après 35 ans d'activité
 à l'ONF

Les conditions d'utilisation qu'on trouve sur le site internet de
l'ONF et dont j'ai donné le lien dans mon précédent message parle bien
de propriété intellectuel, page 1:

Les droits de propriété intellectuelle associés aux données et aux
informations mises à disposition demeurent en toute circonstance à
l'Office National des Forêts (dénommé ONF), producteur et dépositaire
des données.
Mais c'est une mention normale dans les données publiques. Et ça n'est
pas incompatible avec une Licence Ouverte.

Pieren

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

Re: [OSM-talk-fr] Code postal de Dampierre-sur-Avre

2013-06-21 Par sujet Aurélien FILEZ

De la même manière il y a la ville Rollens dont le code postal est 11290
mais où un . a été rajouté à la fin de

http://www.openstreetmap.org/browse/relation/1975477

Plus facile à gérer par la suite mais bon, si je peux nettoyer ce genre de
petite bricole lorsque je tombe dessus, ça ne serait pas de trop ;)

A bientôt,

Kin

2013/6/21 Aurélien FILEZ kinj...@gmail.com

 Bonjour à tous,

 En exploitant les code postaux des villes françaises dans OpenStreetMap,
 je me suis aperçu d'une faute de frappe dans celui de Dampierre-sur-Avre :

 http://www.openstreetmap.org/browse/relation/1903407

 Le code postal n'est pas 282350 mais 28350.

 En revanche, je ne sais pas comment corriger ça, car avec l'éditeur
 Potlatch, lorsque je sélectionne la relation, ça ne sélectionne que des
 way frontières avec les villes limitrophes.

 Est-ce que quelqu'un peut corriger ça ? Ou mieux, m'expliquer comment je
 peux le faire moi même via Potlatch.

 Merci à vous,

 A bientôt,

 Kin

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

Re: [OSM-talk-fr] Code postal de Dampierre-sur-Avre

2013-06-21 Par sujet didier2020

c'est fait pour les 2 !


Le vendredi 21 juin 2013 à 12:37 +0200, Aurélien FILEZ a écrit :
 De la même manière il y a la ville Rollens dont le code postal est
 11290 mais où un . a été rajouté à la fin de
 
 
 http://www.openstreetmap.org/browse/relation/1975477
 
 
 Plus facile à gérer par la suite mais bon, si je peux nettoyer ce
 genre de petite bricole lorsque je tombe dessus, ça ne serait pas de
 trop ;)
 
 
 A bientôt,
 
 
 Kin 
 
 2013/6/21 Aurélien FILEZ kinj...@gmail.com
 Bonjour à tous, 
 
 
 En exploitant les code postaux des villes françaises dans
 OpenStreetMap, je me suis aperçu d'une faute de frappe dans
 celui de Dampierre-sur-Avre : 
 
 
 http://www.openstreetmap.org/browse/relation/1903407 
 
 
 Le code postal n'est pas 282350 mais 28350. 
 
 
 En revanche, je ne sais pas comment corriger ça, car avec
 l'éditeur Potlatch, lorsque je sélectionne la relation, ça ne
 sélectionne que des way frontières avec les villes
 limitrophes. 
 
 
 Est-ce que quelqu'un peut corriger ça ? Ou mieux, m'expliquer
 comment je peux le faire moi même via Potlatch. 
 
 
 Merci à vous, 
 
 
 A bientôt, 
 
 
 Kin 
 
 
 ___
 Talk-fr mailing list
 Talk-fr@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-fr



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

Re: [OSM-talk-fr] Code postal de Dampierre-sur-Avre


Il n'est reste plus que 1164 en erreur alors !

http://osmose.openstreetmap.fr/fr/errors/?item=3190country=france*limit=2000

Mais tous ne sont pas sur des relations. On peut trier sur la colonne 
elem pour avoir les relations.


Frédéric.


Le 21/06/2013 12:41, didier2020 a écrit :

c'est fait pour les 2 !


Le vendredi 21 juin 2013 à 12:37 +0200, Aurélien FILEZ a écrit :

De la même manière il y a la ville Rollens dont le code postal est
11290 mais où un . a été rajouté à la fin de


http://www.openstreetmap.org/browse/relation/1975477


Plus facile à gérer par la suite mais bon, si je peux nettoyer ce
genre de petite bricole lorsque je tombe dessus, ça ne serait pas de
trop ;)


A bientôt,


Kin

2013/6/21 Aurélien FILEZ kinj...@gmail.com
 Bonjour à tous,


 En exploitant les code postaux des villes françaises dans
 OpenStreetMap, je me suis aperçu d'une faute de frappe dans
 celui de Dampierre-sur-Avre :


 http://www.openstreetmap.org/browse/relation/1903407


 Le code postal n'est pas 282350 mais 28350.


 En revanche, je ne sais pas comment corriger ça, car avec
 l'éditeur Potlatch, lorsque je sélectionne la relation, ça ne
 sélectionne que des way frontières avec les villes
 limitrophes.


 Est-ce que quelqu'un peut corriger ça ? Ou mieux, m'expliquer
 comment je peux le faire moi même via Potlatch.


 Merci à vous,


 A bientôt,


 Kin


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




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




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

Re: [OSM-talk-fr] Balise name/short_description (était : Parcelle numérotée - Forêt domaniale)

Pour moi le champ description est plutôt destiné à être affiché verbatim
sur un panneau de propriétés détaillées d'un élément sélectionné sur la
carte, il sert avant tout à inclure des infos qui ne rentrent pas dans la
classification (et que le même panneau affichera aussi).
Le champ name est un champ ultra résumé servant juste à identifier
localement un objet.

Pour le reste la carte représenter déjà d'une façon ou d'une autre le type
de cet objet (couleurs, styles de traits, tailles et styles de polices,
icône, texturage de surface...). La séparation des éléments constitutifs
d'un name=* offre beaucoup plus de possibilités d'adaptation du rendu selon
les besoins (y compris la possibilité de constituer à partir de ces
éléments des libellés composés affichant les précisions, si c'est
réellement nécessaire pour des distinctions que le rendu ne sait pas
distinguer autrement, et aussi de créer des libellés composés contenant des
éléments traduits et d'autres laissés dans leur dénomination d'origine ou
translittérés par algorithme.

Si on prend le cas des translittérations, un truc du genre Commune de
Trifouillis rendra un truc incompréhensible en bulgare ou en hébreu, alors
que Trifouillis restera lisible une fois translitéré tandis que Commune
de pourra être traduit. Et cela ne demandera pas non plus une connaissance
approfondie de la langue d'origine (qui en plus n'est pas connue dans le
champ name=* qui ne précise ni sa langue réelle (contrairement à
name:fr=*), sachant qu'on a en France aussi des name=* en d'autres
langues (sans même préciser un autre name:fr=*) !

Même avec l'indication de la langue, la translitération ne peut pas être
complètement phonétique (essayez donc avec l'anglais !) Faudrait-il alors
préciser :

- phonetic:name=* ou phonetic:name:fr=* ? (quoique BCP 47 permet de
coder cela dans un tag de langue, de même que les translittérations pour
plusieurs systèmes normalisés comme US-BGN ou UN-GEGN ou les romanisations
cyrilliques et chinoises)
- Voire aussi audio:name=* avec une URI en valeur vers un fichier audio
.wav/.mp3/.ogg ?
- Ou encore video:name=* pour une présentation vidéo ou une animation GIF
ou SVG en langue des signes ?
- Ou encore image:name=* pour les écritures non linéaires comme
SignWriting ? Voire une photo d'un panneau difficile à transcrire en texte
car composé de symboles non codés Unicode ou d'un logo privé ?
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Noms de cantons et d'arrondissements (était : Recherche d'une adresse par Nominatim)

Le COG n'inclue pas le nom complet, c'est une présentation faite sur le
site à partir d'un assemblage de données codifiées individuellement, pour
donner un titre de section ou sous-section dans la page (c'est juste plus
joli que de mettre Canton: Caen 1er Canton.

L'exemple que tu cites le démontre clairement. La ligne  Canton de Caen
1er Canton (08) est bien issu de cet assemblage d'éléments codés
individuellement. Si c'était vraiment joli cela devrait être 1er canton de
Caen, voire Premier canton de Caen, quoique les textes de loi du code
rural et l'arrêté de création le nomment canton de Caen-I (noter la
minuscule initiale, ce n'est pas un nom propre, car ni le canton ni
l'arrondissement n'ont la personnalité juridique comme les EPCI qui
choisissent un nom propre souvent différent de leur statut réel, par
exemple ceux qui se nomment métropoles ou pays de) mais quand des
listes de cantons sont dressés les termes canton de sont supprimés et
remplacés contextuellement par un entête de liste mentionnant cantons de
au pluriel

(les chiffres entre parenthèses de ton exemple sont le code du canton dans
le département, mais ce n'est pas évident en première lecture de ce seule
libellé composé, cela ne se déduit que par le contexte de la page, mais ils
témoignent là aussi que le libellé est assemblé automatiquement, il ne fait
pourtant pas non plus partie du nom du canton qui se suffit sans ce numéro,
et ce numéro affiché n'est pas utilisable seul non plus comme identifiant
sans préciser le code du département...).



Le 21 juin 2013 12:10, Pieren pier...@gmail.com a écrit :

 2013/6/21 Damouns damo...@gmail.com:

  Mon idée est que dans une phrase en français courant, 99,9% des
  phrases contenant Pontarlier ou Issoire désignent la commune

 Il est évident que tout document, officiel ou pas, citant Caen ou
 Pontarlier tout seul, fait référence à la ville.
 Notre malheur est que le COG présente les cantons dans un tableau avec
 le nom du chef-lieu en dessous de la colonne marquée Canton et que
 certains ont pris le nom de ce chef-lieu pour le nom du canton
 lui-même.
 Exemple:

 http://www.insee.fr/fr/methodes/nomenclatures/cog/canarr.asp?codedep=14codearr=2

 Alors que lorsqu'on va dans la fiche détail d'un canton:

 http://www.insee.fr/fr/methodes/nomenclatures/cog/comcan.asp?codedep=14codecan=06

 on parle bien de Canton de Bourguébus (06).
 (à noter, le bug du COG sur Canton de Caen 1er Canton (08)

 100% favorable pour nommer les choses par leur nom. Mettez canton de
 au début ou (canton) à la fin, peu importe, mais évitons les
 homonymies inutiles avec un peu de bon sens commun.

 Pieren

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

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

Re: [OSM-talk-fr] Noms de cantons et d'arrondissements (était : Recherche d'une adresse par Nominatim)


Bonjour,

Le 21/06/2013 12:10, Pieren a écrit :

2013/6/21 Damouns damo...@gmail.com:


Mon idée est que dans une phrase en français courant, 99,9% des
phrases contenant Pontarlier ou Issoire désignent la commune


Il est évident que tout document, officiel ou pas, citant Caen ou
Pontarlier tout seul, fait référence à la ville.
Notre malheur est que le COG présente les cantons dans un tableau avec
le nom du chef-lieu en dessous de la colonne marquée Canton et que
certains ont pris le nom de ce chef-lieu pour le nom du canton
lui-même.
Exemple:
http://www.insee.fr/fr/methodes/nomenclatures/cog/canarr.asp?codedep=14codearr=2
Alors que lorsqu'on va dans la fiche détail d'un canton:
http://www.insee.fr/fr/methodes/nomenclatures/cog/comcan.asp?codedep=14codecan=06


Si ce 2e lien doit servir ton argumentaire, alors ça me paraît mal parti 
: la même page, où le nommage du canton t'arrange, ne parle pas de 
Basse-Normandie mais Région Basse-Normandie, Calvados y est appelé 
Département du Calvados. Sans parler, bien sûr, de l'arrondissement de 
Caen. On renomme tous les niveaux, tant qu'on y est ?



on parle bien de Canton de Bourguébus (06).
(à noter, le bug du COG sur Canton de Caen 1er Canton (08)

100% favorable pour nommer les choses par leur nom.


Manifestement non, puisque tu proposes de compléter le nom :

Mettez canton de

au début ou (canton) à la fin, peu importe, mais évitons les
homonymies inutiles avec un peu de bon sens commun.


Les homonymies sont un fait. J'ai déjà parlé dans un fil analogue [1] en 
évoquant les communes françaises nommées Saint-Nicolas. Il y en a un 
paquet, est-ce pour autant qu'on va trafiquer leur tag name=* pour s'y 
retrouver ?


Une fois de plus, ce sujet du nommage revient, et une fois de plus il 
s'appuie sur les approximations d'un outil (Nominatim), approximations 
qu'il faudrait compenser non pas dans l'outil, mais dans la donnée. Ce 
raisonnement se défendrait si seul cet outil utilisait les données. Mais 
que je sache, on contribue à la constitution d'une base de données, pas 
d'un outil. Et avec l'espoir que cette base servira dans de nombreux 
contextes (pas juste Nominatim). Aussi, quand on le peut, donner à cette 
base un peu de cohérence, d'homogénéité, pour lui faire gagner du crédit 
auprès de ses utilisateurs potentiels, ça me paraît nécessaire. Ce qui 
se traduit, dans notre sujet, par le fait de mettre comme valeur du tag 
name le nom _strict_ d'une entité, surtout lorsqu'un référentiel externe 
nous le propose.


vincent

[1] : 
http://lists.openstreetmap.org/pipermail/talk-fr/2013-February/054404.html



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

Re: [OSM-talk-fr] Balise name/short_description (était : Parcelle numérotée - Forêt domaniale)

2013-06-21 Par sujet Jean-Baptiste Holcroft

Idem, il existe des cas d'églises protestantes où le panneau indique église
de VILLE, la nuance entre boulangerie et boulangerie-pâtisserie est plus
intéressante/importante que le nom officiel de la société.
Je parie qu'on peu trouver la même chose pour les cimetières, où est il
plus pertinent de marquer cimetière de VILLE vs cimetière vs rien car c'est
dans la limite administrative de la ville ?
Dans une optique d'usage, je préfère également voir un texte générique à
améliorer qu'un vide qui donne l'impression que personne ne s'est intéressé
une seconde au patelin et à juste mis un point à l'arrache.
Enfin, les coueurs des différents outils ne permettent pas forcément de
distinguer un item d'un autre, voir écrit eglise ne me choque pas. Si le
rendu ne souhaite pas indiquer les noms d'église, c'est son problème.
Incomplet n'est pas forcément pire que vide.
Le 21 juin 2013 12:23, Pieren pier...@gmail.com a écrit :

 2013/6/21 Christian Quest cqu...@openstreetmap.fr:
  quand je suis de mauvaise humeur, je les supprime,

  Il m'est arrivé de faire du nettoyage en virant par exemple les
  name=Boulangerie sur des shop=bakery

 Wow, wow, wow !!! Je trouve que vous y allez fort. Cool down.
 La boulangerie a sûrement un nom. Utiliser un tag name est donc
 correct. Y mettre juste Boulangerie, c'est incomplet, mais pas faux.
 C'est sûr que ça me dérange aussi, un nom incomplet mais il suffit de
 soit ajouter les infos manquantes, soit passer son chemin.
 De même, mettre name=Chemin rural ou Chemin d'exploitation sur un
 highway=track est une vrai information (on a parlé sur un autre fil
 des conséquences qui peuvent être juridiques).
 Allez-y molo avec les suppressions et respectez d'avantage les
 contributions des autres.

 Pieren

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

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

Re: [OSM-talk-fr] (Etait: IGN Route 500 ...) enfin un moyen pour uniformiser notre classification des highway ?

2013-06-21 Par sujet PierreV

@ Philippe: cool ton explication... manque juste les sources de ce que tu
avances;-)  et le rapport avec les routes 500 de la france métropolitaine? 

@ tout le monde: bref, j'ai zieuté le contenu de ses nouveaux fichiers.
En plus des routes ce qui est intéressant c'est le fichier des fleuves et
rivières. Certes la précision est très médiocre pour etre importé tel quel
dans OSM, mais si un outil de comparaison des manques est monté pour les
routes il serait facile de faire de même pour les rivières?

Sinon concernant les routes et les liaisons locales faut faire très
attention... par chez moi j'en ai trouvé une qui correspond a une piste
cyclable (appelé chemins blancs localement...) qui n'a jamais été une
route pour voitures!



--
View this message in context: 
http://gis.19327.n5.nabble.com/Etait-IGN-Route-500-enfin-un-moyen-pour-uniformiser-notre-classification-des-highway-tp5766047p5766366.html
Sent from the France mailing list archive at Nabble.com.

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

Re: [OSM-talk-fr] Outil d'import des adresses : Bordeaux, Montpellier, Lyon

2013-06-21 Par sujet Sylvain Maillard

Salut,

merci pour ce travail qui va faciliter l'intégration ;)

2 questions:
- juste à titre informatif, est-ce qu'il serait possible d'avoir la
méthodologie utilisée pour générer les fichiers xml derrière tout ça ?
j'avais généré ce genre de fichiers et posé la question à isnogoud (qui m'a
transmis les fichiers de Nantes en exemple) mais je n'ai pas encore eu de
retour ...
- pour les adresses de Lyon, tu as utilisé quel jeux de données ? il
semblerait que ce soit les données point_adressage_sur_batiment (adresses
au milieu du polygone bâtiment) ... dans un souci d'homogénéisation avec ce
qui est fait sur les autres grandes métropoles et également ce qui a déjà
été fait en centre de Lyon, il vaudrait mieux utiliser les données
adr_voie_lieu.adrnumerovoie qui positionnent les points adresses à la
limite bâtiment/rue !


Sylvain



Le 21 juin 2013 12:05, rldhont rldh...@gmail.com a écrit :

 Bonjour Frédérico,

 Comment peut-on proposer un nouveau jeu de données et donc intégrer de
 nouvelles données ?

 Je pense à Arles dont les données sont disponibles ici :
 http://opendata.regionpaca.fr/**donnees/detail/base-de-**
 donnees-adresses-de-laccm.htmlhttp://opendata.regionpaca.fr/donnees/detail/base-de-donnees-adresses-de-laccm.html

 René-Luc

 Le 21/06/2013 10:49, Frédéric Rodrigo a écrit :

  Bonjour,

 Le même outil que pour l'import des adresses de Nantes Métropole à été
 mise en place pour :
 - Communauté Urbaine de Bordeaux
 http://osm7.openstreetmap.fr/~**fred/adresses/bordeaux/http://osm7.openstreetmap.fr/~fred/adresses/bordeaux/
 - Grand Lyon
 http://osm7.openstreetmap.fr/~**fred/adresses/lyonhttp://osm7.openstreetmap.fr/~fred/adresses/lyon
 - Ville de Montpellier
 http://osm7.openstreetmap.fr/~**fred/adresses/montpellierhttp://osm7.openstreetmap.fr/~fred/adresses/montpellier

 Voilà ce qui avait été mis en place pour Nantes :
 http://wiki.osm.org/Nantes/**Adresses_postales_Nantes_M%C3%**A9tropolehttp://wiki.osm.org/Nantes/Adresses_postales_Nantes_M%C3%A9tropole

 Également disponible deux analyses Osmose :
 - détection des manques depuis les données OpenData
 http://osmose.openstreetmap.**fr/fr/errors/?item=8080http://osmose.openstreetmap.fr/fr/errors/?item=8080
 - analyses sur les numéros des rues
 http://osmose.openstreetmap.**fr/fr/errors/?item=2060http://osmose.openstreetmap.fr/fr/errors/?item=2060

 Frédéric.

 __**_
 Talk-fr mailing list
 Talk-fr@openstreetmap.org
 http://lists.openstreetmap.**org/listinfo/talk-frhttp://lists.openstreetmap.org/listinfo/talk-fr



 __**_
 Talk-fr mailing list
 Talk-fr@openstreetmap.org
 http://lists.openstreetmap.**org/listinfo/talk-frhttp://lists.openstreetmap.org/listinfo/talk-fr

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

[OSM-talk-fr] Vidéo 3d avec fond OSM grenoblois

2013-06-21 Par sujet Guillaume Allegre

Salut,

J'ai trouvé par hasard une vidéo faite par le Collectif Collège de Proximité
qui demande la construction d'un nouveau collège dans le Nord-Ouest de Grenoble.
Le point intéressant (pour nous), c'est qu'ils ont fait une vidéo explicative
pas mal du tout, avec du matériel provenant d'OSM.
http://www.youtube.com/watch?feature=player_embeddedv=bbjkTSkyBm4

Curieux, j'ai demandé des infos :

 Le fond de carte a été extrait avec Mapnik.
 Les emprises des batiments sont également d'OpenStreetMap : nettoyer
 avec Josm puis transformer en svg avec osmarender.
 Les formes svg ont été ensuite importées dans blender puis extrudées
 pour faire les batiments de la vidéo.


J'ai aussi signalé qu'ils auraient dû créditer OSM pour les données,
c'est en cours.



-- 
 ° /\Guillaume AllègreOpenStreetMap France
  /~~\/\   allegre.guilla...@free.fr  Cartographie libre et collaborative
 /   /~~\tél. 04.76.63.26.99  http://www.openstreetmap.fr


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

Re: [OSM-talk-fr] Code postal de Dampierre-sur-Avre

2013/6/21 Frédéric Rodrigo fred.rodr...@gmail.com:
 Il n'est reste plus que 1164 en erreur alors !

 http://osmose.openstreetmap.fr/fr/errors/?item=3190country=france*limit=2000

 Mais tous ne sont pas sur des relations. On peut trier sur la colonne elem
 pour avoir les relations.


Voila qui ferait un beau projet du mois. Un but atteignable (+/-
1000 erreurs) et des tags simples et incontestés ;-)

Pieren

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

Re: [OSM-talk-fr] Outil d'import des adresses : Bordeaux, Montpellier, Lyon

2013-06-21 Par sujet Sylvain Maillard

d'ailleurs en y regardant de plus près, il n'y a pas eu de conflation avec
les adresses déjà existantes ?

C'est ce que j'avais trouvé super l'import des adresses sur Nantes: en
chargeant une rue dans JOSM, il y avait directement les nouveaux points
adresses + les points déjà existants + les tronçons de rues déjà intégrés
dans la relation à créer ...



Sylvain



Le 21 juin 2013 13:32, Sylvain Maillard sylvain.maill...@gmail.com a
écrit :

 Salut,

 merci pour ce travail qui va faciliter l'intégration ;)

 2 questions:
 - juste à titre informatif, est-ce qu'il serait possible d'avoir la
 méthodologie utilisée pour générer les fichiers xml derrière tout ça ?
 j'avais généré ce genre de fichiers et posé la question à isnogoud (qui m'a
 transmis les fichiers de Nantes en exemple) mais je n'ai pas encore eu de
 retour ...
 - pour les adresses de Lyon, tu as utilisé quel jeux de données ? il
 semblerait que ce soit les données point_adressage_sur_batiment (adresses
 au milieu du polygone bâtiment) ... dans un souci d'homogénéisation avec ce
 qui est fait sur les autres grandes métropoles et également ce qui a déjà
 été fait en centre de Lyon, il vaudrait mieux utiliser les données
 adr_voie_lieu.adrnumerovoie qui positionnent les points adresses à la
 limite bâtiment/rue !


 Sylvain



 Le 21 juin 2013 12:05, rldhont rldh...@gmail.com a écrit :

 Bonjour Frédérico,

 Comment peut-on proposer un nouveau jeu de données et donc intégrer de
 nouvelles données ?

 Je pense à Arles dont les données sont disponibles ici :
 http://opendata.regionpaca.fr/**donnees/detail/base-de-**
 donnees-adresses-de-laccm.htmlhttp://opendata.regionpaca.fr/donnees/detail/base-de-donnees-adresses-de-laccm.html

 René-Luc

 Le 21/06/2013 10:49, Frédéric Rodrigo a écrit :

  Bonjour,

 Le même outil que pour l'import des adresses de Nantes Métropole à été
 mise en place pour :
 - Communauté Urbaine de Bordeaux
 http://osm7.openstreetmap.fr/~**fred/adresses/bordeaux/http://osm7.openstreetmap.fr/~fred/adresses/bordeaux/
 - Grand Lyon
 http://osm7.openstreetmap.fr/~**fred/adresses/lyonhttp://osm7.openstreetmap.fr/~fred/adresses/lyon
 - Ville de Montpellier
 http://osm7.openstreetmap.fr/~**fred/adresses/montpellierhttp://osm7.openstreetmap.fr/~fred/adresses/montpellier

 Voilà ce qui avait été mis en place pour Nantes :
 http://wiki.osm.org/Nantes/**Adresses_postales_Nantes_M%C3%**A9tropolehttp://wiki.osm.org/Nantes/Adresses_postales_Nantes_M%C3%A9tropole

 Également disponible deux analyses Osmose :
 - détection des manques depuis les données OpenData
 http://osmose.openstreetmap.**fr/fr/errors/?item=8080http://osmose.openstreetmap.fr/fr/errors/?item=8080
 - analyses sur les numéros des rues
 http://osmose.openstreetmap.**fr/fr/errors/?item=2060http://osmose.openstreetmap.fr/fr/errors/?item=2060

 Frédéric.

 __**_
 Talk-fr mailing list
 Talk-fr@openstreetmap.org
 http://lists.openstreetmap.**org/listinfo/talk-frhttp://lists.openstreetmap.org/listinfo/talk-fr



 __**_
 Talk-fr mailing list
 Talk-fr@openstreetmap.org
 http://lists.openstreetmap.**org/listinfo/talk-frhttp://lists.openstreetmap.org/listinfo/talk-fr



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

Re: [OSM-talk-fr] Code postal de Dampierre-sur-Avre

2013-06-21 Par sujet didier2020

+1

apres avoir fait quelques corrections, il y a parfois melange des tag
(addr:postcode a la place de name , addr:street ou addr:housenumber)

quelqu'un sait s'il y a une carte des surfaces codepostal dans le style
layers.openstreetmap.fr ?

didier



Le vendredi 21 juin 2013 à 13:39 +0200, Pieren a écrit : 
 2013/6/21 Frédéric Rodrigo fred.rodr...@gmail.com:
  Il n'est reste plus que 1164 en erreur alors !
 
  http://osmose.openstreetmap.fr/fr/errors/?item=3190country=france*limit=2000
 
  Mais tous ne sont pas sur des relations. On peut trier sur la colonne elem
  pour avoir les relations.
 
 
 Voila qui ferait un beau projet du mois. Un but atteignable (+/-
 1000 erreurs) et des tags simples et incontestés ;-)
 
 Pieren
 
 ___
 Talk-fr mailing list
 Talk-fr@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-fr



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

Re: [OSM-talk-fr] Code postal de Dampierre-sur-Avre

2013-06-21 Par sujet Emmanuel Lesouef

Le Fri, 21 Jun 2013 12:48:53 +0200,
Frédéric Rodrigo fred.rodr...@gmail.com a écrit :

 Il n'est reste plus que 1164 en erreur alors !
 
 http://osmose.openstreetmap.fr/fr/errors/?item=3190country=france*limit=2000
 
 Mais tous ne sont pas sur des relations. On peut trier sur la colonne 
 elem pour avoir les relations.
 
 Frédéric.

J'en ai corrigé quelques uns en Basse-Normandie. Par contre, je ne sais
pas comment les marquer comme corrigés.

Il ne devrait en rester que deux :

http://www.openstreetmap.org/browse/relation/149197

et 

http://www.openstreetmap.org/browse/node/412476714

Le souci c'est que dans mon souvenir, les deux codes postaux sont
corrects pour la ville de Caen.

Il y a une différence mais je ne me souviens plus laquelle...

-- 
Emmanuel Lesouef


signature.asc
Description: PGP signature
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Outil d'import des adresses : Bordeaux, Montpellier, Lyon


Le 21/06/2013 12:05, rldhont a écrit :

Bonjour Frédérico,

Comment peut-on proposer un nouveau jeu de données et donc intégrer de
nouvelles données ?


Comme ça !


Je pense à Arles dont les données sont disponibles ici :
http://opendata.regionpaca.fr/donnees/detail/base-de-donnees-adresses-de-laccm.html


Je l'ai ajouté, c'est disponible (mais pas encore disponible dans Osmose) :

http://osm7.openstreetmap.fr/~fred/adresses/arles/

Frédéric.


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

Re: [OSM-talk-fr] Code postal de Dampierre-sur-Avre



Le 21/06/2013 13:57, Emmanuel Lesouef a écrit :


Il ne devrait en rester que deux :

http://www.openstreetmap.org/browse/relation/149197

et

http://www.openstreetmap.org/browse/node/412476714

Le souci c'est que dans mon souvenir, les deux codes postaux sont
corrects pour la ville de Caen.

Il y a une différence mais je ne me souviens plus laquelle...


Cette page ne connaît aucune correspondance avec le code 14300 :
http://www.laposte.fr/sna/rubrique.php3?id_rubrique=59

et ce code est aussi absent des données proposées en OpenData sur les 
bureaux de poste. En revanche, une recherche web sur 'Caen 14300' 
ratisse plein de choses : http://lmgtfy.com/?q=caen+14300


Un code ancien (obsolète) ?

vincent

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

Re: [OSM-talk-fr] Outil d'import des adresses : Bordeaux, Montpellier, Lyon


Le 21/06/2013 13:45, Sylvain Maillard a écrit :
 merci pour ce travail qui va faciliter l'intégration ;)

 2 questions:
 - juste à titre informatif, est-ce qu'il serait possible d'avoir la
 méthodologie utilisée pour générer les fichiers xml derrière tout ça
 ?

Tout est disponible là :
http://osm7.openstreetmap.fr/~fred/adresses/Data/
En gros c'est : shp2pgsql, script SQL pour convertir au format Osmosis, 
Osmosis pour extraire en .osm, un bout de code ruby pour spliter le gros 
.osm en un .osm par relation.


 - pour les adresses de Lyon, tu as utilisé quel jeux de données ? il
 semblerait que ce soit les données point_adressage_sur_batiment
 (adresses au milieu du polygone bâtiment) ... dans un souci
 d'homogénéisation avec ce qui est fait sur les autres grandes
 métropoles et également ce qui a déjà été fait en centre de Lyon, il
 vaudrait mieux utiliser les données adr_voie_lieu.adrnumerovoie qui
 positionnent les points adresses à la limite bâtiment/rue !

Effectivement j'ai bien vu les deux.
- Point de débouché d'une adresse du Grand Lyon (Voies et adresses)
Projection de l'adresse postale ou numéro sur le tronçon de voirie au 
droit de ce numéro. Ce point est en relation avec le numéro de voirie. 
Il permet la recherche topologique d'adresses sur les tronçons.

- Point d'adressage sur bâtiment (Voies et adresses)
Indique le ou les parcelle(s), le ou les bâtiment(s) se rattachant à un 
numéro de voirie. Permet un lien géographique entre le numéro de voirie 
et le territoire géographique adressé.


Le premier a les points sur l'axe de la voie. J'ai donc pris le deuxième.

Je viens de découvrir qu'il y a aussi :
- Numéro de voirie du Grand Lyon (Voies et adresses)
Adresse postale, sur voie ou sur bâtiment, localisée à l'aplomb de la 
plaque, ou au plus proche de l'accès du bâtiment ou de la parcelle à 
référencer. Les communes fournissent les nouvelles numérotations. Pour 
la ville de Lyon, la numérotation est déléguée au Grand Lyon. Cette 
information est en relation avec le nom de la rue.


C'est peut-être celui qu'il faut prendre.

Tu peux regarder et me dire le quel il faut ?


d'ailleurs en y regardant de plus près, il n'y a pas eu de conflation
avec les adresses déjà existantes ?


Non, j'ai fait ce travail pour Bordeaux ou il n'y a pas besoin de 
conflation. Puis je l'ai répliqué. Si d'autres personnes veulent prendre 
la main, c'est ouvert ;).



C'est ce que j'avais trouvé super l'import des adresses sur Nantes: en
chargeant une rue dans JOSM, il y avait directement les nouveaux points
adresses + les points déjà existants + les tronçons de rues déjà
intégrés dans la relation à créer ...

Sylvain


Frédéric.


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

Re: [OSM-talk-fr] Signature partenariat SNCF/OSM autour de l'accessibilité

2013-06-21 Par sujet Sylvain Naudin

Bonjour,

Empruntant tous les jours la ligne, et ne partant pas en vacances cet été,
c'est avec plaisir que je contribuerai dans le secteur Juvisy/Bretigny :)

Faudra par contre effectivement organiser une rencontre avant afin d'être
le plus efficace.


Sylvain, qui ayant mis un filtre sur les messages ne consulte plus les
mails de la liste, mais qui a vu l'info sur le site ;)
Mail : sylv...@naud.in
Web : http://sylvain.naud.in

Une plateforme de blog pour votre association : *Kynä* !
http://www.kyna.eu

Culture Libre  Créations Collectives - CLiCC
http://libre.cc
@CultureLibreCC http://twitter.com/CultureLibreCC


Le 20 juin 2013 16:11, Christian Quest cqu...@openstreetmap.fr a écrit :

 J'ai fait un tour à la gare de Juvisy aujourd'hui, une gare assez complexe
 où le mélange entre N° de voie et nom (lettre) du quai apporte une
 confusion sûrement à un public plus large !

 Demie-heure intéressante en gare où j'ai découvert un quai en pente
 (courbe) et donc interdit d'un côté aux fauteuils roulants car trop
 dangereux... sauf avec de bons freins ;)


 Le 20 juin 2013 15:22, Ista Pouss ista...@gmail.com a écrit :

 Comme il n'y a aucun risque que je participe je m'en vais faire deux
 suggestions à propos du handicap mental qui n'engagent personne :

 - cartographie des zones de bruit, car le bruit perturbe de nombreux
 handicapés mentaux bien plus que les gens normaux
 - cartographie des zones de cohérence signalitique ; en fait, pour les
 mêmes raisons que le bruit : la surcharge de prétendus signaux panique
 complètement les autistes, par ex. (mais peut être est-il difficile à la
 sncf d'admettre que avec la pub, les annonces sonores/télévisuelles, etc,
 c'est plutôt le bordel ? ) (et de toutes façons les gens normaux ne le
 vivent bien que parce qu'ils ont du fric) (fin des remarques perso)

 ... pas sûr que ces deux idées suffisent à résoudre tous les problèmes...
 faites comme vous pouvez.


 -



 Le 20 juin 2013 14:25, Marc SIBERT m...@sibert.fr a écrit :

 Je prépare une page sur OSM.fr avec comme titre de l'opération Cahiers
 de Vacances 2013 OSM_FR

 L'opération se déroule sur les 2 mois d'été et a comme vocation d'être
 le projet de l'été de la section IdF d'OSM, si vous le voulez bien :-)

 Ce dimanche 23, je passe à Chamarande où se tient la Grande fête pour
 tous de 10h à 18h avec pour objectif de rencontrer CG91 et assos de
 soutien aux personnes handicapées (tous handicaps).

 N'hésitez pas à vous faire connaitre, le programme s'étalera sur les
 week-end de juillet et d'aout suivant la vitesse de progression (quand la
 ligne RER C sera terminée, il y aura la Ligne L à faire aussi).
 Toutes les bonnes volontés seront les bien venues, c'est aussi
 l'occasion de faire de l'accompagnement ou de l'initiation à la cartopartie.
 N'hésitez pas à en parler autour de vous.

 Il est aussi possible de faire de la carto en fauteuil ;-) armchair
 contributing afin de passer l'ensemble du réseau RER C au modèle
 public_transport (avec plein de relations dedans, humm ).

 http://fr.wikipedia.org/wiki/Ligne_C_du_RER_d%27%C3%8Ele-de-France

  A+

 Marc


 Le 19 juin 2013 12:30, Christian Quest cqu...@openstreetmap.fr a
 écrit :

 J'ai signé ce matin pour OSM-FR une convention de partenariat avec la
 SNCF pour le mapping de l'accessibilité des certaines gares du réseau
 Transilien.

 Le but : mapper en détail l'accessibilité dans les gares de banlieue
 sur les lignes C et L en vue de l'organisation d'un hackathon à
 l'automne autour de ces nouvelles données co-produites.

 L'intérêt :
 - faire progresser le mapping des gares et autour,
 - faire connaitre OSM aux voyageurs et personnels de la SNCF,
 - avancer sur le projet accessibilité qui est très porteur en général
 (il ouvre facilement les portes des collectivités)
 - profiter de la comm de la SNCF qui va être faite autour,
 et sûrement plein d'autres choses !

 Prochaines étapes :
 - ce vendredi matin j'ai rdv avec le responsable de la sécurité sur la
 ligne C pour une sensibilisation à la sécurité en gare
 - mobiliser les associations liées au handicap qui voudraient
 participer à la collecte sur le terrain et la sensibilisation aux
 différents handicaps
 - mobiliser les contributeurs existants dans la région et aussi à
 distance (pour le chair mapping préparatoire qui pourrait être fait
 sur base des plans de situation de la SNCF)

 Le timing est serré, car il faut collecter un max de données d'ici
 septembre. La ligne C c'est 50 gares, la L 40... on va démarrer par la
 ligne C.

 Une page de wiki dédiée pour la ligne C:
 http://wiki.openstreetmap.org/wiki/WikiProject_France/RER/C

 --
 Christian Quest - OpenStreetMap France
 Un nouveau serveur pour OSM... http://donate.osm.org/server2013/

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




 --
 Marc Sibert
 m...@sibert.fr

 ___
 Talk-fr mailing list

Re: [OSM-talk-fr] Noms de cantons et d'arrondissements (était : Recherche d'une adresse par Nominatim)

2013/6/21 Vincent de Château-Thierry v...@laposte.net:
 On renomme tous les niveaux, tant qu'on y est ?

Euh ,y a une ville qui s'appelle Basse Normandie ? Si la région
s'appelait Caen, on pourrait en rediscuter. Ici, il s'agit de lever
une ambiguité facilement.

 il s'appuie sur les approximations d'un outil (Nominatim)...
 le nom _strict_ d'une entité, surtout lorsqu'un référentiel externe
 nous le propose.

Ca me rappelle les discussion sur la super-relation boundary pour la
France. Si quelqu'un n'avait pas remis une énorme relation simple, il
n'y aurait tout simplement pas de géolocalisation correcte pour la
France. En trois ans, personne n'a adapté les outils pour prendre en
compte les super-relations.

Je ne connais pas d'autres pays qui ont un problème avec une entité
administrative qui porte exactement le même nom à différents niveaux
dans OSM. De ce que j'ai pu voir, ils n'hésitent pas à ajouter un
identifant dans le nom (comme Orange County, Californie [1] ou
Canton Capellen au Luxembourg [2]) alors que dans les deux cas, le
nom officiel est aussi le nom du chef-lieu.
Pourquoi serions-nous moins pragmatiques que les autres ?
Pourquoi ne pas faire un compromis comme aux USA avec name=Orange
County + county:name=Orange ?
Si on ne fait rien, ça sera comme avec la super-relation: ça reviendra
régulièrement sur le tapis. Et si vous espérez une adaptation de tous
les outils de tous les pays pour tenir compte de notre petit
particularisme, vous risquez d'attendre très, très, très longtemps.

Pieren

[1] http://www.openstreetmap.org/browse/relation/396466
[2] http://www.openstreetmap.org/browse/relation/407813

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

Re: [OSM-talk-fr] Outil d'import des adresses : Bordeaux, Montpellier, Lyon

2013-06-21 Par sujet rldhont


Merci Frédéric !

Par contre il semble y avoir un problème avec les liens vers les 
fichiers OSM.

L'adresse suivante ne donne rien
http://osm7.openstreetmap.fr/~fred/adresses/arles//100/5471858312712767972.osm

René-Luc D'Hont

Le 21/06/2013 14:04, Frédéric Rodrigo a écrit :

Le 21/06/2013 12:05, rldhont a écrit :

Bonjour Frédérico,

Comment peut-on proposer un nouveau jeu de données et donc intégrer de
nouvelles données ?


Comme ça !


Je pense à Arles dont les données sont disponibles ici :
http://opendata.regionpaca.fr/donnees/detail/base-de-donnees-adresses-de-laccm.html 



Je l'ai ajouté, c'est disponible (mais pas encore disponible dans 
Osmose) :


http://osm7.openstreetmap.fr/~fred/adresses/arles/

Frédéric.




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

Re: [OSM-talk-fr] Outil d'import des adresses : Bordeaux, Montpellier, Lyon

C'est corrigé ! J'avais cassé tous les liens symboliques en déplacement 
un répertoire.


Le 21/06/2013 14:36, rldhont a écrit :

Merci Frédéric !

Par contre il semble y avoir un problème avec les liens vers les
fichiers OSM.
L'adresse suivante ne donne rien
http://osm7.openstreetmap.fr/~fred/adresses/arles//100/5471858312712767972.osm


René-Luc D'Hont

Le 21/06/2013 14:04, Frédéric Rodrigo a écrit :

Le 21/06/2013 12:05, rldhont a écrit :

Bonjour Frédérico,

Comment peut-on proposer un nouveau jeu de données et donc intégrer de
nouvelles données ?


Comme ça !


Je pense à Arles dont les données sont disponibles ici :
http://opendata.regionpaca.fr/donnees/detail/base-de-donnees-adresses-de-laccm.html



Je l'ai ajouté, c'est disponible (mais pas encore disponible dans
Osmose) :

http://osm7.openstreetmap.fr/~fred/adresses/arles/

Frédéric.






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

Re: [OSM-talk-fr] Parcelle numérotée - Forêt domaniale

2013-06-21 Par sujet david . crochet

Bonjour

 Sans aller jusqu'au découpage des parcelles, le repérage des sections 
 forestières est celui utilisé sur les panneaux (ou marquages peints sur les 
 arbres), et c'est lui qui sera utile au randonneur. 

Si le découpage n'est pas physiquement visible, son indication dans la base de 
données est limité voire peut-être inutile.

Il peut y avoir un découpage provoqué par un sentier plus ou moins marqué, un 
ruisseau, une rigole ou dans ce cas là le découpage, sans l'indiqué est 
implicite par l'existence de l'autre élément.

D'après ce que j'ai pu voir dans cette forêt, certaine parcelle ne se distingue 
pas de leur voisin, sauf année d'abatage des arbres qui sont plus ou moins 
jeune par la suite


 Cependant ces numéros de sections sont souvent placés le long d'un sentier, 
 qui devrait être cartographié. Du coup autant mettre les numéros de section 
 sur les noeuds de ces sentiers, à proximité immédiate de leurs intersections. 

Par quel type d'étiquette ?

Justement, je pensais étiqueter la parcelle, mais vu que la politique c'est 
de numériser le réel, il est tout a fait logique de numériser l'élément 
support du numéro.
et quel étiquette afin d'harmoniser les pratique et éviter le n'importe quoi 
(quoique il vaut mieux une donnée primo-mal-indiqué que pas de données du tout)


Cordialement
-- 
David Crochet


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

Re: [OSM-talk-fr] Outil d'import des adresses : Bordeaux, Montpellier, Lyon

2013-06-21 Par sujet Sylvain Maillard

oui, c'est bien le dernier fichier (adresses localisée à l'aplomb de la
plaque) qu'il fraudait utiliser !

je vais essayer de recontacter l'équipe nantaise pour voir comment ils ont
fait la conflation avec l'existant ;)
pour ma part j'ai écris un petit bout de code en python pour générer les
fichiers xml par rue. Du coup je pense que ça ne devrais pas être trop
difficile de rajouter quelques requêtes XAPI pour vérifier tout ça ...





Le 21 juin 2013 14:40, Frédéric Rodrigo fred.rodr...@gmail.com a écrit :

 C'est corrigé ! J'avais cassé tous les liens symboliques en déplacement un
 répertoire.

 Le 21/06/2013 14:36, rldhont a écrit :

  Merci Frédéric !

 Par contre il semble y avoir un problème avec les liens vers les
 fichiers OSM.
 L'adresse suivante ne donne rien
 http://osm7.openstreetmap.fr/~**fred/adresses/arles//100/**
 5471858312712767972.osmhttp://osm7.openstreetmap.fr/~fred/adresses/arles//100/5471858312712767972.osm


 René-Luc D'Hont

 Le 21/06/2013 14:04, Frédéric Rodrigo a écrit :

 Le 21/06/2013 12:05, rldhont a écrit :

 Bonjour Frédérico,

 Comment peut-on proposer un nouveau jeu de données et donc intégrer de
 nouvelles données ?


 Comme ça !

  Je pense à Arles dont les données sont disponibles ici :
 http://opendata.regionpaca.fr/**donnees/detail/base-de-**
 donnees-adresses-de-laccm.htmlhttp://opendata.regionpaca.fr/donnees/detail/base-de-donnees-adresses-de-laccm.html


 Je l'ai ajouté, c'est disponible (mais pas encore disponible dans
 Osmose) :

 http://osm7.openstreetmap.fr/~**fred/adresses/arles/http://osm7.openstreetmap.fr/~fred/adresses/arles/

 Frédéric.




 __**_
 Talk-fr mailing list
 Talk-fr@openstreetmap.org
 http://lists.openstreetmap.**org/listinfo/talk-frhttp://lists.openstreetmap.org/listinfo/talk-fr

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

Re: [OSM-talk-fr] Noms de cantons et d'arrondissements (était : Recherche d'une adresse par Nominatim)



Le 21/06/2013 14:27, Pieren a écrit :

2013/6/21 Vincent de Château-Thierry v...@laposte.net:

On renomme tous les niveaux, tant qu'on y est ?


Euh ,y a une ville qui s'appelle Basse Normandie ?


Pas que je sache. Mais tu citais cette page pour illustrer que le nom du 
canton devrait contenir 'canton de '. Si cette page fait référence, 
alors soyons un peu logiques :-) .
Autant je ne considère pas OSM comme une base référentielle (le mot est 
dit), autant, sur la thématique des découpages administratifs, on doit 
pouvoir coller au mieux aux référentiels externes. On ne va pas 
inventer, ni même déduire du terrain, par où passe une limite indiquée 
par le cadastre, ou la valeur d'un code émis par l'INSEE. On les prend 
tels qu'ils sont. Pourquoi déroger pour le nom ? En le faisant, on 
dévalorise notre contenu.



Je ne connais pas d'autres pays qui ont un problème avec une entité
administrative qui porte exactement le même nom à différents niveaux
dans OSM. De ce que j'ai pu voir, ils n'hésitent pas à ajouter un
identifant dans le nom (comme Orange County, Californie [1] ou
Canton Capellen au Luxembourg [2]) alors que dans les deux cas, le
nom officiel est aussi le nom du chef-lieu.
Pourquoi serions-nous moins pragmatiques que les autres ?


Tout est affaire d'exemples. Tu observeras le pragmatisme des italiens :
http://www.openstreetmap.org/browse/relation/41313 (Rome au niveau 6)
inclut
http://www.openstreetmap.org/browse/relation/41485 (Rome au niveau 8)
Les deux ont le même tag name, et un tag officiel_name différent. Comme 
quoi, ce qui aurait pu les désambiguïser n'est même pas pris en compte 
pour le nom principal. C'est un homonyme, assumé.



Pourquoi ne pas faire un compromis comme aux USA avec name=Orange
County + county:name=Orange ?


compromis me paraît diamétralement opposé à référentiel, évoqué plus 
haut. On ne conciliera pas les deux, pour sûr. Quand je pense 
référentiel, c'est avec en tête l'usage qui sera fait de la donnée par 
des gens que je ne connais pas, dans des applications que je ne connais 
pas non plus. En introduisant de la bidouille,  je pense qu'on ne donne 
pas de bons arguments pour populariser l'utilisation de notre contenu.


vincent

ps. ça ne nous dit pas ce qu'on fait pour désambiguïser les ~50 
Saint-Nicolas français ;-)


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

Re: [OSM-talk-fr] Code postal de Dampierre-sur-Avre

2013-06-21 Par sujet Emmanuel Lesouef

Le Fri, 21 Jun 2013 14:14:10 +0200,
Vincent de Château-Thierry v...@laposte.net a écrit :

 
 Le 21/06/2013 13:57, Emmanuel Lesouef a écrit :
 
  Il ne devrait en rester que deux :
 
  http://www.openstreetmap.org/browse/relation/149197
 
  et
 
  http://www.openstreetmap.org/browse/node/412476714
 
  Le souci c'est que dans mon souvenir, les deux codes postaux sont
  corrects pour la ville de Caen.
 
  Il y a une différence mais je ne me souviens plus laquelle...
 
 Cette page ne connaît aucune correspondance avec le code 14300 :
 http://www.laposte.fr/sna/rubrique.php3?id_rubrique=59
 
 et ce code est aussi absent des données proposées en OpenData sur les 
 bureaux de poste. En revanche, une recherche web sur 'Caen 14300' 
 ratisse plein de choses : http://lmgtfy.com/?q=caen+14300
 
 Un code ancien (obsolète) ?
 
 vincent
 

Effectivement. Assez ancien.

J'imagine que théoriquement on devrait pouvoir l'enlever de ce nœud et
de cette relation.

Pas d'opposition ?

-- 
Emmanuel Lesouef


signature.asc
Description: PGP signature
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Noms de cantons et d'arrondissements (était : Recherche d'une adresse par Nominatim)

2013/6/21 Vincent de Château-Thierry v...@laposte.net:

 Pourquoi déroger pour le nom ? En le faisant, on dévalorise notre contenu.

Au contraire, on clarifie là où c'est nécessaire. Comme tu le dis, OSM
n'est pas un référentiel. Si quelqu'un veut la liste officielle des
noms officiels des cantons/arrondissements de France, il peut déjà les
trouver dans le COG.
Ici, on essaie de lever une ambiguité dans OSM, pour OSM. Les données
extérieures doivent servir à enrichir la base mais avec la condition
de pouvoir être modifiées. Sinon, tu donnes des billes à ceux qui sont
contre toute forme d'import. Si c'est pour importer des données pour
ensuite bloquer tout changement sous prétexte qu'il faut coller au
référentiel, cela n'a pas sa place dans OSM.

 Les deux ont le même tag name, et un tag officiel_name différent. Comme
 quoi, ce qui aurait pu les désambiguïser n'est même pas pris en compte pour
 le nom principal. C'est un homonyme, assumé.

Assumé, c'est vite dit. Peut-être se sont-ils basés sur les données
actuelles en France en pensant que c'était assumé chez-nous ;-)

 compromis me paraît diamétralement opposé à référentiel, évoqué plus
 haut. On ne conciliera pas les deux, pour sûr. Quand je pense référentiel,
 c'est avec en tête l'usage qui sera fait de la donnée par des gens que je ne
 connais pas, dans des applications que je ne connais pas non plus.

Mouais, bon. C'est un référentiel ou pas un référentiel, finalement ?
On peut et on doit se rapprocher autant que possible des données
officielles. Mais on ne peut pas bloquer des données importées sous
prétexte qu'elles pourraient diverger de la source. Sinon, on n'est
plus le wikipedia des cartes mais juste un aggrégateur de données
publiques.

Pieren

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

Re: [OSM-talk-fr] Noms de cantons et d'arrondissements (était : Recherche d'une adresse par Nominatim)



Le 21/06/2013 16:39, Pieren a écrit :

2013/6/21 Vincent de Château-Thierry v...@laposte.net:


Pourquoi déroger pour le nom ? En le faisant, on dévalorise notre contenu.


Ici, on essaie de lever une ambiguité dans OSM, pour OSM.


Oui mais on n'est pas en vase clos. Quand je lis pour OSM, j'ai 
l'impression que ce qui peut advenir du contenu OSM en dehors de notre 
microcosme de contributeurs n'a pas d'intérêt :-(



Les deux ont le même tag name, et un tag officiel_name différent. Comme
quoi, ce qui aurait pu les désambiguïser n'est même pas pris en compte pour
le nom principal. C'est un homonyme, assumé.


Assumé, c'est vite dit. Peut-être se sont-ils basés sur les données
actuelles en France en pensant que c'était assumé chez-nous ;-)


Joli ! :-)


compromis me paraît diamétralement opposé à référentiel, évoqué plus
haut. On ne conciliera pas les deux, pour sûr. Quand je pense référentiel,
c'est avec en tête l'usage qui sera fait de la donnée par des gens que je ne
connais pas, dans des applications que je ne connais pas non plus.


Mouais, bon. C'est un référentiel ou pas un référentiel, finalement ?


Toujours pas :-) C'est surtout l'idée de fiabilité que je voulais 
exprimer ici. Parmi les aspects déroutants pour ceux qui cherchent à 
utiliser nos données, il y a l'absence de cahier des charges (je 
résume). Si on sait montrer que certaines thématiques (ici 
l'administratif) sont fabriquées avec rigueur, sont un peu carrées, et 
donc réutilisables en confiance, ça ne peut qu'aider à faire adhérer. 
Enfin, c'est mon avis.


vincent (un peu borné sur l'idée que les contributeurs d'après-demain 
sont les consommateurs de demain :-) )



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

[OSM-talk-fr] Proposition de stage sur Tilemill à Makina Corpus

2013-06-21 Par sujet Frédéric Bonifas

Bonjour,

Makina Corpus propose un stage à Toulouse autour de l'utilisation de
Tilemill et de la représentation des données OSM notamment. Vous
trouverez plus d'informations ici :
http://www.makina-corpus.com/stage-cartographie

Pour plus de renseignements, vous pouvez écrire à recrutem...@makina-corpus.com

N'hésitez pas à diffuser cette offre auprès de personnes qui
pourraient être intéressées.

Frédéric

--
Frédéric Bonifas
+33672652807 skype:fredericbonifas

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

Re: [OSM-talk-fr] Noms de cantons et d'arrondissements (était : Recherche d'une adresse par Nominatim)

Le 21 juin 2013 13:25, Vincent de Château-Thierry v...@laposte.net a
écrit :


 Une fois de plus, ce sujet du nommage revient, et une fois de plus il
 s'appuie sur les approximations d'un outil (Nominatim), approximations
 qu'il faudrait compenser non pas dans l'outil, mais dans la donnée.


D'une part il n'est pas nécessaire de compenser dans la donnée puisque les
données sont déjà présentes. De plus Nominatim fait déjà les différences
nécessaires. Il faut savoir utiliser l'outil et surtout lire ce qu'il
affiche et qui est très clair.

Mais une recherche Nominatim dans JOSM fait certanes différences (JOSM
affichant en plus la carte). Toute recherche par nom de toute façon pourra
ramener des homonymes, en classant selon des degrés de pertinence, ce que
Niminatim fait déjà. On ne doit pas se contenter de ne lire que le premier
résultat affiché quand Nominatim en fournit déjà une liste visible au
premier coup d'oeil !

Ensuite les moteurs de rendus affichent aussi des différences
significatives, même si leur rendu peut parfois être amélioré. Mais là
encore on ne parle pas de la base dont les données sont déjà correctes,
suffisantes,  claires, et non ambiguës. Dans une base de données on ne
mélange pas dans un me^me champ des informations appartenant à des axes
d'analyse et de classification distincts.

Ca s'appelle la modélisation, et c'est ce qui fait l'utilité d'une base
de données et permet sa réutilisabilité pour divers types de requêtes selon
des besoins différents, où les précisions ajoutées et mélangées sont plus
nuisibles qu'utiles.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Parcelle numérotée - Forêt domaniale

Relis ce que j'ai écrit : je parlais bien du repérage présent des sections
forestières, pour l'orientation. PAS des limites de parcelles ou des années
de plantation et plans d'abattage (dont les distinctions deviennent de plus
en plus difficiles à percevoir avec le temps, les plans d'éclaircissement
par abattage sélectif changeant de façon désordonnée l'apparence des
parcelles qui par aileurs peuvent avoir des coupes partielles.

Les parcelles c'est une notion de limite de propriété et de droit, pas une
indication des plans de plantation et d'entretien ou d'abattage.

En revanche les sections forestières sont bel et bien mentionnées sur les
routes et chemins forestiers, par des panneaux ou marquages peints sur les
arbres. Ce sont ces éléments visibles qui sont pertinents, vérifiables sur
le terrain (et indépendants en fait des parcelles qui ne suivent pas le
même découpage ou nécessite un oeil d'expert pour comprendre certains
marquages plus techniques sur les arbres ou sur certaines bornes plantées
au milieu des sous-bois, et que seul un expert trouvera facilement.

Mais pas un randonneur qui n'est pas habilité à toucher sans autorisation à
la végétation pour la nettoyer, si à ces endroits la politique est de
garder des abris végétaux en sous-bois naturels pour la petite faune, les
rongeurs, les serpents, les batraciens dans des sols humides, les insectes,
ou permettre le développement de bancs de champignons, des espèces florales
pour les abeilles avec des bois morts laissés volontairement à l'abandon et
qui enrichissent la diversité biologique, etc.)

Cette végétation des sous-bois constitue aussi des barrières naturelles
utiles contre le développement de décharges sauvages, elle protège le
milieu, simplifie aussi le travail de dépollution des lisières, elle limite
la circulation et laisse la faune tranquille (les sociétés de chasse,
elles, connaissent mieux le terrain et savent mieux le protéger pour ne pas
le dégrader, souvent elles donnent des coups de main lorsque des nettoyages
sont nécessaires (barrières coupe-feu, limitation des espèces en surnombre,
dégagement des bois morts en surnombre après une tempête, qui bloquent les
sentiers, etc.) en travaillant de concert avec les propriétaires foncier
qui font appel à eux, comme à d'autres associations de défense des milieux
naturels).



Le 21 juin 2013 14:45, david.croc...@online.fr a écrit :

 Bonjour

  Sans aller jusqu'au découpage des parcelles, le repérage des sections
 forestières est celui utilisé sur les panneaux (ou marquages peints sur
 les arbres), et c'est lui qui sera utile au randonneur.

 Si le découpage n'est pas physiquement visible, son indication dans la
 base de données est limité voire peut-être inutile.

 Il peut y avoir un découpage provoqué par un sentier plus ou moins marqué,
 un ruisseau, une rigole ou dans ce cas là le découpage, sans l'indiqué est
 implicite par l'existence de l'autre élément.

 D'après ce que j'ai pu voir dans cette forêt, certaine parcelle ne se
 distingue pas de leur voisin, sauf année d'abatage des arbres qui sont plus
 ou moins jeune par la suite


  Cependant ces numéros de sections sont souvent placés le long d'un
 sentier, qui devrait être cartographié. Du coup autant mettre les numéros
 de section sur les noeuds de ces sentiers, à proximité immédiate de leurs
 intersections.

 Par quel type d'étiquette ?

 Justement, je pensais étiqueter la parcelle, mais vu que la politique
 c'est de numériser le réel, il est tout a fait logique de numériser
 l'élément support du numéro.
 et quel étiquette afin d'harmoniser les pratique et éviter le n'importe
 quoi (quoique il vaut mieux une donnée primo-mal-indiqué que pas de données
 du tout)


 Cordialement
 --
 David Crochet


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

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

Re: [OSM-talk-fr] Parcelle numérotée - Forêt domaniale

2013-06-21 Par sujet PhQ


Relis ce que j'ai écrit : je parlais bien du repérage présent des sections 
- section ? quesaco
forestières, pour l'orientation. PAS des limites de parcelles ou des années
de plantation et plans d'abattage (dont les distinctions deviennent de plus
en plus difficiles à percevoir avec le temps, les plans d'éclaircissement
par abattage sélectif changeant de façon désordonnée l'apparence des
parcelles qui par aileurs peuvent avoir des coupes partielles. --- oui ça
c'est vrai

/Les parcelles c'est une notion de limite de propriété et de droit, pas une
indication des plans de plantation et d'entretien ou d'abattage./


non pas du tout, une parcelle forestière est une unité d'AMENAGEMENT (règle
interne de gestion de la foret) Les limites de forets sont (souvent) des
limites de propriétés



En revanche les sections forestières sont bel et bien mentionnées sur les
routes et chemins forestiers, par des panneaux ou marquages peints sur les
arbres. Ce sont ces éléments visibles qui sont pertinents, vérifiables sur
le terrain (et indépendants en fait des parcelles qui ne suivent pas le
même découpage ou nécessite un oeil d'expert pour comprendre certains
marquages plus techniques sur les arbres ou sur certaines bornes plantées
au milieu des sous-bois, et que seul un expert trouvera facilement.

?? Un exemple serait bien venu

Mais pas un randonneur qui n'est pas habilité à toucher sans autorisation à
la végétation pour la nettoyer, si à ces endroits la politique est de
garder des abris végétaux en sous-bois naturels pour la petite faune, les
rongeurs, les serpents, les batraciens dans des sols humides, les insectes,
ou permettre le développement de bancs de champignons, des espèces florales
pour les abeilles avec des bois morts laissés volontairement à l'abandon et
qui enrichissent la diversité biologique, etc.)

seuls les agents forestiers sont autorisés à appliquer une politique de
gestion forestière. Tout acte dans le domaine* privé
*
de l'Etat ou des communes est subordonné à leur autorisation; Par dérogation
(pas toujours) le ramassage des champignons est TOLERE pour la consommation
personnel. 


/Cette végétation des sous-bois constitue aussi des barrières naturelles
utiles contre le développement de décharges sauvages, elle protège le
milieu, simplifie aussi le travail de dépollution des lisières, elle limite
la circulation et laisse la faune tranquille (les sociétés de chasse,
elles, connaissent mieux le terrain et savent mieux le protéger pour ne pas
le dégrader, souvent elles donnent des coups de main lorsque des nettoyages
sont nécessaires (barrières coupe-feu, limitation des espèces en surnombre,
dégagement des bois morts en surnombre après une tempête, qui bloquent les
sentiers, etc.) en travaillant de concert avec les propriétaires foncier
qui font appel à eux, comme à d'autres associations de défense des milieux
naturels)./

rien à voir avec le parcellaire forestier au sens strict

P. QUENEE CATE en retaite de l'ONF





--
View this message in context: 
http://gis.19327.n5.nabble.com/Parcelle-numerotee-Foret-domaniale-tp5766304p5766434.html
Sent from the France mailing list archive at Nabble.com.

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

Re: [OSM-talk-fr] Parcelle numérotée - Forêt domaniale

Bah toi tu te restreins aux forêts domaniales (propriétés de l'Etat ou des
collectivités). Mais j'ai bel et bien vu les numéros de section forestières
marqués explicitement sur les panneau, ou sur les routes forestières
(peints sur la chaussée, si cette route de service est goudronnée pour les
cyclistes ou véhicules de service, sinon sur les panneaux aux carrefours de
ces routes), même dans les forêts domaniales.


Le 21 juin 2013 20:37, PhQ pierre.que...@sfr.fr a écrit :


 Relis ce que j'ai écrit : je parlais bien du repérage présent des sections
 
 - section ? quesaco
 forestières, pour l'orientation. PAS des limites de parcelles ou des années
 de plantation et plans d'abattage (dont les distinctions deviennent de plus
 en plus difficiles à percevoir avec le temps, les plans d'éclaircissement
 par abattage sélectif changeant de façon désordonnée l'apparence des
 parcelles qui par aileurs peuvent avoir des coupes partielles. --- oui ça
 c'est vrai

 /Les parcelles c'est une notion de limite de propriété et de droit, pas une
 indication des plans de plantation et d'entretien ou d'abattage./


 non pas du tout, une parcelle forestière est une unité d'AMENAGEMENT (règle
 interne de gestion de la foret) Les limites de forets sont (souvent) des
 limites de propriétés



 En revanche les sections forestières sont bel et bien mentionnées sur les
 routes et chemins forestiers, par des panneaux ou marquages peints sur les
 arbres. Ce sont ces éléments visibles qui sont pertinents, vérifiables sur
 le terrain (et indépendants en fait des parcelles qui ne suivent pas le
 même découpage ou nécessite un oeil d'expert pour comprendre certains
 marquages plus techniques sur les arbres ou sur certaines bornes plantées
 au milieu des sous-bois, et que seul un expert trouvera facilement.

 ?? Un exemple serait bien venu

 Mais pas un randonneur qui n'est pas habilité à toucher sans autorisation à
 la végétation pour la nettoyer, si à ces endroits la politique est de
 garder des abris végétaux en sous-bois naturels pour la petite faune, les
 rongeurs, les serpents, les batraciens dans des sols humides, les insectes,
 ou permettre le développement de bancs de champignons, des espèces florales
 pour les abeilles avec des bois morts laissés volontairement à l'abandon et
 qui enrichissent la diversité biologique, etc.)

 seuls les agents forestiers sont autorisés à appliquer une politique de
 gestion forestière. Tout acte dans le domaine* privé
 *
 de l'Etat ou des communes est subordonné à leur autorisation; Par
 dérogation
 (pas toujours) le ramassage des champignons est TOLERE pour la consommation
 personnel.


 /Cette végétation des sous-bois constitue aussi des barrières naturelles
 utiles contre le développement de décharges sauvages, elle protège le
 milieu, simplifie aussi le travail de dépollution des lisières, elle limite
 la circulation et laisse la faune tranquille (les sociétés de chasse,
 elles, connaissent mieux le terrain et savent mieux le protéger pour ne pas
 le dégrader, souvent elles donnent des coups de main lorsque des nettoyages
 sont nécessaires (barrières coupe-feu, limitation des espèces en surnombre,
 dégagement des bois morts en surnombre après une tempête, qui bloquent les
 sentiers, etc.) en travaillant de concert avec les propriétaires foncier
 qui font appel à eux, comme à d'autres associations de défense des milieux
 naturels)./

 rien à voir avec le parcellaire forestier au sens strict

 P. QUENEE CATE en retaite de l'ONF





 --
 View this message in context:
 http://gis.19327.n5.nabble.com/Parcelle-numerotee-Foret-domaniale-tp5766304p5766434.html
 Sent from the France mailing list archive at Nabble.com.

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

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

Re: [OSM-talk-fr] Parcelle numérotée - Forêt domaniale

2013-06-21 Par sujet Vincent Pottier


Le 21/06/2013 20:37, PhQ a écrit :

Le 21/06/2013 12:54, Philippe Verdy a écrit :

...

- section ? quesaco

...

non pas du tout, une parcelle forestière est une unité d'AMENAGEMENT (règle
interne de gestion de la foret) Les limites de forets sont (souvent) des
limites de propriétés

...

?? Un exemple serait bien venu

...

rien à voir avec le parcellaire forestier au sens strict

P. QUENEE CATE en retaite de l'ONF


@PhQ,
Ne cherche pas... Tu auras tord...

On a l'habitude que Philippe parle doctement de ce qu'il ne connaît pas...

Le 21/06/2013 21:05, Philippe Verdy a écrit :
Bah toi tu 
...et qu'il trouve les tords chez les autres. Tu auras beau être 
l'expert planétaire de la question.

--
FrViPofm

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

Re: [OSM-talk-fr] Parcelle numérotée - Forêt domaniale