Re: [OSM-talk-fr] Voies récentes dans Fantoir, absentes d'OSM

[Pierre Knobel]

?oi je vois bien des noms de rues, et pas des "rue numéro 1"... etc,
sur le lien de Vincent.

Ca ressemble à un problème de cache de ton navigateur, mais c'est
curieux que les rues se soient bien affichées pendant 2 mois et que
soudainement ça revient au nom précédent. Est-ce que tu peux
visualiser la zone sur un autre PC ou un autre smartphone, pour voir
si c'est spécifique à ta machine ?
Tu peux essayer aussi
https://fr.wikipedia.org/wiki/Aide:Purge_du_cache_du_navigateur

On 10/19/15, Mathias Jérôme  wrote:
> De fait, ce soir, lorsque je me connecte et que je fais "modifier" sur la
> carte, jeretombe bien les libellés de rue tel que je les ai modifié et
> telles qu'ils apparaissaient par la suite dans OSM depuis mes modifications
> (donc avec les noms que j'avais modifié), sauf ce soir où je ne vois plus
> que les anciens noms.
> Je ne comprend pas grand chose à ce qu'il se passe à vrai dire !
>
>
>>  Le Lundi 19 octobre 2015 22h46, Vincent de Château-Thierry a écrit :
>>  http://www.openstreetmap.org/changeset/33224729

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

Re: [OSM-talk-fr] Zone de rencontre sur grand axe routier

[Pierre Knobel]

Est-ce que favoriser la cohérence du réseau routier ne revient pas un peu à
tagguer pour le rendu ?

Pour moi c'est clair que la réalité du terrain prime sur les principes
esthétiques généraux. S'il n'y a pas de route primaire digne de ce nom qui
permet de traverser la ville confortablement, il ne faut pas en inventer.

Concernant le routage, je dirais que les logiciels fonctionneront mieux si
l'information est la plus spécifique et la plus neutre possible. Ce n'est
pas au contributeur OSM de décider qu'une route donnée est la meilleure
manière de traverser une ville, c'est les algorithmes qui doivent s'en
occuper. Et les algorithmes ont besoin de savoir qu'un tronçon de route est
limité à 20 km/h avec la priorité aux piétons.
Le 14 juil. 2015 19:34, rainerU ra...@sfr.fr a écrit :

 Am 14.07.2015 um 15:55 schrieb Jean-Francois Nifenecker:

 Au demeurant, tout comme Eric, je pense que le centre ville
 de Nancy est trop densément tagué en primary.


 Ça saute aux yeux quand on compare avec route500 qui n'est certes pas très
 à jour et des fois imprécis, mais pas à ce point.



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

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

Re: [OSM-talk-fr] bano - nom de voie - point bleu

[Pierre Knobel]

Ce sont les voies qui sont dans OSM, qui correspondent à une voie
FANTOIR, mais qui n'ont pas de point adresse dans le cadastre et qui
ne peuvent donc pas être géolocalisé à partir de cette source. La
position du point sur le rendu BANO correspond il me semble au milieu
du way OSM qui a le tag name=Rue du Colombier. C'est probablement un
way OSM qui déborde sur deux ou trois communes et qui devrait être
coupé à la limite communale pour changer de nom.

On 5/24/15, didier2020 didier2...@free.fr wrote:
 un petit exemple :
 http://tile.openstreetmap.fr/~cquest/leaflet/bano.html#18/49.54018/1.36171

 c'est quoi les points bleu ...
 celui-ci est largement eloigné de sa commune



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


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

Re: [OSM-talk-fr] OSM 1 : Google 0

[Pierre Knobel]

2015-05-12 11:41 GMT+02:00 Jean-Marc Liotier j...@liotier.org:


 N'en glosons pas trop - la seule raison pour laquelle OSM n'a pas à
 affronter un tel vandalisme est qu'il n'est pas aussi populaire que Google.


Je pense au contraire que plus on est populaire, plus les vandalismes sont
signalés ou corrigés rapidement par la communauté. Pour moi c'est une
victoire du modèle ouvert et transparent d'OSM  sur le modèle fermé de
Google qui n'attire pas les foules.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] BANO : Ref Fantoir sur nom d'immeuble

[Pierre Knobel]

Je rencontre des cas similaires assez souvent, moi aussi. Il est probable
que ce genre d'information soit effectivement utilisé en complément
d'adresse:

 Jean Dupont
 Résidence Les Tartentules
 666 Rue des Arachnides
 6 Octopolis-Les-Bains

Donc c'est une bonne idée de mettre le nom et/ou la ref FANTOIR de
l'immeuble sur le bâtiment et le nom de la rue sur la route, et espérer que
dans le futur cette information soit exploitée par BANO. Je trouve que la
limitation actuelle aux objets de type highway=* + name=* pour les
rapprochements OSM/FANTOIR est trop restrictive (peut-être centrée sur une
problématique de calcul d'itinéraire ?). On pourrait imaginer rapprocher
aussi les building=*, les leisure=park... etc


2015-04-08 9:47 GMT+00:00 Simon Miniou simon.min...@gmail.com:

 Bonjour,

 petite question que je me pose depuis quelques temps sur les immeubles de
 ma commune.

 ils ont quasi tous une ref fantoir qu'on retrouve dans les voies FANTOIR
 sans rapprochement OSM :
 http://cadastre.openstreetmap.fr/fantoir/#insee=51649

 Sachant que cette référence correspond à des immeubles qui sont déjà
 rattaché à une voie (plusieurs numéros par immeuble) ;
 *Que faut-il faire ? Rajouter la référence sur le bâtiment ? considérer
 cette référence supplémentaire en erreur?*
 Exemple :
 Rue des Saules (516492000L) :
 https://www.openstreetmap.org/relation/3874169
 Bâtiment des saules (51649A510L) :
 https://www.openstreetmap.org/way/170937588#map=19/48.72000/4.58227

 Merci,
 ++
 Simon

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


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

[OSM-talk-fr] Publications libres

[Pierre Knobel]

Bonjour,

En farfouillant sur un site de publications scientifiques libres, j'ai
découvert qu'on y trouvait un certain nombre d'articles qui nous
concernent. Je n'ai pas encore trouvé comment faire une recherche
incluant le corps de l'article, mais rien qu'en cherchant dans les
titres on trouve déjà de belles choses :
http://www.mdpi.com/search?q=openstreetmapsearch=Search
http://www.mdpi.com/search?q=volunteeredsearch=Search
http://www.mdpi.com/search?q=mapsubjects=computer-math%2Cengineering%2Cenvironment%2Carts-humanity

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

Re: [OSM-talk-fr] FFRandonnée 44 et l'open data

[Pierre Knobel]

A modèle à suivre dans tous les départements.

Ca m'intéresserait de faire pareil ailleurs monter un club de rando
spécialisé dans les sorties avec GPS sur les sentiers et chemins
encore absents d'OSM. Avec une subvention de 7000E on peut facilement
acheter une flotte de bon GPS de rando, et louer une salle
régulièrement pour former les membres du club sur l'utilisation du
récepteur et la saisie des infos dans JOSM.

Une grande question c'est qu'est-ce que j'ai le droit de relever ? On
est plus que jamais dans le flou total concernant le droit d'auteur
des marquages GR, GRP, PR et les nombreux logos du Club Vosgien
(http://www.club-vosgien.eu/_media/12554-affiche-club-vosgien-a4-fr.pdf‎).
S'il s'avère qu'on ne
peut pas mettre ces infos dans OSM, peut-on envisager de créer un
marquage concurrent ? Ou bien est-ce qu'on est dans une situation de
monopole total de la FFRP ?

Cet exemple en Loire-Atlantique me fait penser que la signalétique sur
le terrain peut-être distribué en Open Data sans problème. Même pas la
peine de mentionner le GR, on dit juste que sur ce rocher il y a un
trait rouge et un trait blanc parallèles de 20 cm, orienté en
direction du NE.

Les autres problèmes c'est évidemmment de trouver des membres pour
monter le club et la subvention pour équiper les membres en GPS,
papier et crayons :)

ps : un peu de lecture comprendre les enjeux de la mise en place d'un
balisage www.club-vosgien-masevaux.fr/pdf/balisage.pdf
‎

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

Re: [OSM-talk-fr] Présentation Adresses, OSM et BANO

[Pierre Knobel]

Et maintenant pour la partie pratique on se lance dans le gros chantier :
dégommer du rouge en Isère http://mapcraft.nanodesu.ru/pie/472

Toute aide est bienvenue, même si c'est juste pour traiter un seul petit
village facile.

S'il y a des Lyonnais qui lisent cette liste, on a beaucoup de travail
près de chez vous dans le Nord Isère. On connait très peu ce coin, c'est du
mauvais côté de la montagne pour nous Grenoblois :
http://tile.openstreetmap.fr/~cquest/leaflet/bano.html#13/45.7634/5.1366

2015-03-06 7:50 GMT+01:00 Pierre Knobel pierr...@gmail.com:

 Bonjour,

 Je partage avec vous la Adresses, OSM et BANO d'hier soir à la réunion
 mensuelle du groupe local de Grenoble. J'ai essayé d'aborder rapidement et
 très synthétiquement tous les aspects de BANO, en fournissant des liens
 vers la doc et les outils pour ceux que ça intéresse.

 J'ai oublié de préciser sur cette version, mais c'est évidemment libre
 (CC-BY). La version éditable en .odp est également dispo sur demande.


 http://fr.slideshare.net/onpeutchangersonadresseuneseulefois/bano-osm-grenoble20150305

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

Re: [OSM-talk-fr] Présentation Adresses, OSM et BANO

[Pierre Knobel]

la présentation

2015-03-06 7:50 GMT+01:00 Pierre Knobel pierr...@gmail.com:

 Bonjour,

 Je partage avec vous la Adresses, OSM et BANO d'hier soir à la réunion
 mensuelle du groupe local de Grenoble. J'ai essayé d'aborder rapidement et
 très synthétiquement tous les aspects de BANO, en fournissant des liens
 vers la doc et les outils pour ceux que ça intéresse.

 J'ai oublié de préciser sur cette version, mais c'est évidemment libre
 (CC-BY). La version éditable en .odp est également dispo sur demande.


 http://fr.slideshare.net/onpeutchangersonadresseuneseulefois/bano-osm-grenoble20150305

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

[OSM-talk-fr] Présentation Adresses, OSM et BANO

[Pierre Knobel]

Bonjour,

Je partage avec vous la Adresses, OSM et BANO d'hier soir à la réunion
mensuelle du groupe local de Grenoble. J'ai essayé d'aborder rapidement et
très synthétiquement tous les aspects de BANO, en fournissant des liens
vers la doc et les outils pour ceux que ça intéresse.

J'ai oublié de préciser sur cette version, mais c'est évidemment libre
(CC-BY). La version éditable en .odp est également dispo sur demande.

http://fr.slideshare.net/onpeutchangersonadresseuneseulefois/bano-osm-grenoble20150305
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Modélisation des points d'eau incendie - Projet d'import des données du SDIS de l'Essonne

[Pierre Knobel]

Dans ce cas précis, si j'ai bien compris, on parle d'un import et d'une
maintenance régulière des données par les SDIS. Dans ce cadre là, ça ne me
choque pas qu'on ait des informations non vérifiables par le grand public.
Ce qu'on peut suggérer, c'est que les SDIS publient en parallèle sur un
autre support qu'OSM (data.gouv.fr peut-être ?) les données officielles
dans un format non modifiable par le public pour que chacun puisse vérifier
l'info à la source.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] OSM hors ligne

[Pierre Knobel]

Ma nouvelle option #1 c'est le serveur de tuiles sur un Raspberry Pi 2. En
cherchant un peu, j'ai trouvé que ça a déjà été testé  (mais pas vraiment
documenté, à ma connaissance) :
http://vimeopro.com/openstreetmapus/state-of-the-map-us-2013/video/68087551

J'ai commandé la bête, je pense pouvoir mettre les mains dans le cambouis
ce week-end.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Ajouter le rendu OSM France au site OSM international?

[Pierre Knobel]

D'accord. Je ne connais pas cette fonction Query Features, à moins que ça
ait un rapport avec afficher les données qui met kes données vectorielles
en surcouche ?

Peut-être que tu peux faire quelque chose d'équivalent en affichant le
rendu fr dans JOSM et en faisant une requête sur une petite zone quand tu
as besoin de voir un objet en particulier.

C'est un petit peu moins simple vu que ça rajoute des opérations, mais je
trouve que l'affichage des données dans JOSM est plus fluide que sur osm.org.

Le 9 févr. 2015 20:52, George Kaplan georgekaplan...@hotmail.fr a écrit
:


 Le 9 févr. 2015 à 17:10, Pierre Knobel pierr...@gmail.com a écrit :

  http://tile.openstreetmap.fr/

 Ça ne répond pas vraiment au besoin : je me sers du site .org pour
 identifier les tags ou l'historique d'un objet, pour consulter les objets
 avec la nouvelle fonction Query features. Ni layers ni tile ne propose
 ces fonctions, c'est là où je regrette aussi de ne pas avoir le rendu FR
 sur le site .org.
 ___
 Talk-fr mailing list
 Talk-fr@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-fr

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

Re: [OSM-talk-fr] [OpenStreetMap] Re: Re: Gros problème de correction... Groupe de modifications : 28377712

[Pierre Knobel]

Je trouve dommage de fixer la longueur du code à 6 caractères. Avec le
préfixe INSEE+V à 6 chiffres, ce serait possible de laisser le choix
du nombre de caractères aux collectivités en fonction de leur besoin.
A mon avis le plus simple pour le décodage automatique est un code à
longueur variable avec des séparateurs clairs entre les différents
éléments du code :
insee-type d'objet-code unique

Par exemple : 84007-V-4012,
Encore mieux : 84007-voirie-4012 (lisibilité)

 Le 10/02/2015 11:12, Tony Emery a écrit :

 J'attends vos remarques constructives...


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

Re: [OSM-talk-fr] [OpenStreetMap] Re: Re: Gros problème de correction... Groupe de modifications : 28377712

[Pierre Knobel]

On 2/10/15, Tony Emery tony.em...@yahoo.fr wrote:

 Enfin, pourquoi rajouter des - ou des _ vu que c'est un identifiant et
 qu'on n'a pas besoin de lui faire raconter une histoire ? Après tout, le
 code FANTOIR marche comme ça, les identifiants parcellaires aussi...


Les codes FANTOIR et les identifiants parcellaires sont des vieux
outils mis en place il y a longtemps, quand les langages de
programmation ne permettait pas facilement de faire des opérations du
genre :

(code_INSEE, type_objet, ref_unique) = '-'.split(ref_fr_commune_osm)

et qu'il fallait faire :

char code_insee[5], type_objet[1], ref_unique[6];
strncpy(code_insee, ref_fr_commune, 5)
strncpy(type_objet, ref_fr_commune+5, 1)
strncpy(ref_unique, ref_fr_commune+6, 6)

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

Re: [OSM-talk-fr] Ajouter le rendu OSM France au site OSM international?

[Pierre Knobel]

http://tile.openstreetmap.fr/

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

Re: [OSM-talk-fr] OSM hors ligne

[Pierre Knobel]

Je ferais tous les tests en rentrant. En attendant je collecte les
idées et je commence à voir dans les diverses documentations qu'est-ce
que ça implique en terme de logiciels, systèmes d'exploitation et de
matériel nécessaire.

Donc merci pour toutes les idées déjà proposées :)

L'idéal serait vraiment d'avoir tout ce qu'il faut sur un disque USB,
donc les solutions qui nécessitent un serveur ne seront pas
prioritaires sur ma liste de tests. Mais je m'intéresse de près aux
serveurs portables du style xampp
(http://portableapps.com/apps/development/xampp).

Je récapitule les idées que j'ai retenues pour l'instant, en vrac :
- trouver une appli d'affichage de cartes avec son propre format de
données vectorielles
  parmis http://wiki.openstreetmap.org/wiki/Software/Desktop
- peut-être OSMAnd à travers un émulateur Android (beau rendu)
- cahier des charges minimum : affichages au minimum des
occupations de sol, routes,
  chemins, sentiers, divers POI (magasins, tourisme, batiments
publics...), ombrage du
  relief ou courbes de niveau...
- précalculer des tuiles et les afficher directement
  (http://wiki.openstreetmap.org/wiki/OpenLayers_Local_Tiles_Example)
  problème : espace disque, zone de couverture et/ou niveaux de zooms
trop limités.
- faire tourner un serveur de tuiles. Problèmes :
- 500 Go de base de données... est-ce qu'on peut filtrer
efficacement les données OSM
  en amont pour ne garder que ce qui est vraiment nécessaire au rendu ?
- puissance de calcul nécessaire pour le rendu des premiers
niveaux de zoom et
  complexité de la solution pour avoir les belles tuiles avec les
landuse comme sur
  osm-fr  (appel du pied pour récupérer les tuiles osm-fr jusqu'au
niveau 8, 9 ou 10)
- pas sur d'arriver à quelque chose de portable, il va peut-être
me falloir un serveur de
  rendu dédié sur le terrain (ça pourrait éventuellement le faire
pour moi, mais ça ne
  profitera pas à tout le monde avec un simple ordi portable à disposition)

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

Re: [OSM-talk-fr] OSM hors ligne

[Pierre Knobel]

J'ai fait une estimation rapide de l'espace disque nécessaire pour
chaque niveau de zoom, et j'en conclus que l'option de préparer et
stocker les tuiles n'est pas très réaliste, ou alors avec un niveau de
zoom très limité.

En partant du zoom 3 qui fait à peu près 580 Ko, et en multipliant par
4 à chaque niveau de zoom suivant, j'arrive à environ 200 Go de
données mondiales pour les niveaux de zoom 3 à 12. Au delà, on arrive
à des quantités de données qui me semblent excessives. Peut-être qu'en
optimisant, en ignorant les océans, on pourrait arriver au niveau 13
ou 14.

Pour ce qui est des villes individuelles, j'ai fait le test sur Paris
(http://a.tile.openstreetmap.fr/osmfr/10/518/352.png) et j'arrive à
900 Mo de données pour les niveaux de zoom 13 à 18. Je dirais que
Paris est plutôt plus dense que la moyenne des capitales, donc la
taille moyenne des villes risque d'être plus élevées. Ca limite à 100
ou 200 le nombre de villes qu'on peut envisager de mettre sur un
disque dur portable.

Ce n'est pas un calcul hyper-rigoureux, mais ça donne des ordres de grandeur.

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

Re: [OSM-talk-fr] OSM hors ligne

[Pierre Knobel]

Je continue à réfléchir au sujet, et je suis en train de me dire que
le plus simple serait d'avoir quelque chose d'équivalent à ce que fait
Kiwix pour wikipedia : un petit executable qui se contente d'afficher
des données (tuiles précalculées) stockées localement sur un disque
dur externe.

Pour économiser l'espace disque nécessaire, j'envisage de n'afficher
les tuiles à l'échelle mondiale que pour les premier niveaux de zooms.
Reste à voir jusqu'à quel niveau je pourrais aller en fonction fde
l'espace disque que ça consommerais.
Pour les niveaux de zooms suivants, l'idée serait de récupérer les
images uniquement pour les villes de plus de N habitants, N à
déterminer en fonction de l'espace disque nécessaire.

Premier problème : obtenir une liste de villes de plus de N habitants
Je ne sais pas si le tag population est suffisamment fiable dans OSM
ou si je dois utiliser des sources externes
(http://fr.wikipedia.org/wiki/Cat%C3%A9gorie:Liste_de_villes).

Deuxième problème : obtenir les bounding boxes de chaque vile de la liste.
Je dois pouvoir récupérer les limites de villes avec overpass-api et
faire un simple min/max sur les latitudes/longitudes des points que je
récupère: http://overpass-turbo.eu/s/7s5
Question : est-ce que les relations admin_level=8 sont présentes dans
OSM pour toutes les grandes villes ? Il y a déjà un problème pour le
deuxième test que je fais après Paris : Krasnodar en Russie
http://overpass-turbo.eu/s/7s7

Troisème problème : installeur un serveur de tuile et calculer les
données pour les zones qui m'intéressent et aux niveaux de zoom qui
m'intéressent. Sur ce point je pars de 0.

Quatrième problème : l'affichage des données
L'idéal serait un exécutable simple avec un menu open data qui
permet de sélectionner le dossier contenant toutes les tuiles, et qui
s'occupe d'afficher et de fournir les contrôles souris habituels (zoom
avec la molette, pan avec un clic gauche + mouvement de la souris).
Pour commencer, je dois pouvoir me débrouiller avec Firefox +
OpenLayers : http://wiki.openstreetmap.org/wiki/OpenLayers_Local_Tiles_Example

Commentaires et conseils bienvenus :)

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

Re: [OSM-talk-fr] OSM hors ligne

[Pierre Knobel]

On 2/3/15, sly (sylvain letuffe) lis...@letuffe.org wrote:

 ça manque encore de précisions il me semble, tu as besoin de quoi par
 services cartographiques ?


Initialement je pensais à plusieurs services : tuiles, routage type
OSRM et minage de la base de données (requêtes overpass). Mais là pour
l'instant je pense qu'avoir les tuiles serait déjà pas mal, même à un
niveau de zoom limité.

Un rendu à la volée à partir des données d'OSMAnd serait effectivement
une bonne solution. En additionnant toutes les tailles sur la page
http://download.osmand.net/list.php on arrive à seulement 31Go. Reste
à trouver un moteur de rendu qui digère les fichier OBF et  fonctionne
sous Windows ou Linux. Ou un émulateur Android.

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

Re: [OSM-talk-fr] OSM hors ligne

[Pierre Knobel]

Donc ce n'est pas possible d'utiliser une seule base pour Overpass et le rendu ?

Et si on envisageait de produire toutes les tuiles en PNG une fois
pour toutes à tous les niveaux de zoom, est-ce que ça serait faisable
? Je m'attend à beaucoup de ressources nécessaires, mais ça pourrait
être fait à terre dans de meilleures conditions (calculs distribué sur
plusieurs machines). J'imagine que l'espace disque nécessaire serait
plus élevé, même en optimisant (pas de rendu sur les océans).


On 1/31/15, Christian Quest cqu...@openstreetmap.fr wrote:
 Une base planet pour du rendu c'est environ 500Go atuellement
 Une base overpass c'est du même ordre (et plus avec la gestion des
 historiques).
 Ce qu'il faut c'est la RAM mais surtout un SSD (de plus en plus abordable).
 Côté CPU, pas besoin de se ruiner vu le nombre d'utilisateurs et ce sont
 surtout les I/O qui sont la limitation.

 Le 31/01/2015 21:46, Pierre Knobel a écrit :

 Bonsoir.

 Je suis en train de me demander s'il existe des solutions pour
 consulter l'intégralité d'OSM sans accès internet.

 Mon problème c'est que je travaille dans un environnement où l'accès
 Internet est très lent et très cher, et où il est impossible de
 télécharger plus de quelques Mo de données par heure sans impacter la
 bande passante de mes collègues. On se partage une connexion satellite
 pour 50 personnes, et la majorité de la bande passante est allouée aux
 usages professionnels, sans rapport avec OSM.

 Je ne m'attends pas à trouver une solution toute prête pour OSM comme
 on en trouve pour Wikipedia (
 http://fr.m.wikipedia.org/wiki/Wikip%C3%A9dia:Wikip%C3%A9dia_hors-connexion),
 donc je me demande quel type de matériel il me faudrait pour héberger
 la base de données complète planet, un serveur de tuiles et
 overpass-turbo. Il n'y aurait pas besoin de grosses performances, le
 plus souvent il n'y aurait qu'un seul utilisateur à la fois, et jamais
 plus de deux ou trois (dans le cas où je parviendrais à faire marcher
 les serveurs sur l'intranet).

 Est-ce que vous pensez qu'un PC de bureau récent avec une petite
 rallonge d'espace disque (1 ou 2 To) pourrait faire l'affaire ?

 En admettant que j'arrive à faire tourner tout ça, est-ce qu'il existe
 une solution pour mettre à jour la base de données de manière
 intermittente (une fois tous les deux mois dans mon cas) sans devoir
 réimporter l'intégralité de la base de données ?

 Je précise que je pars de loin, et qu'il me faudrait une bonne doc
 pour réussir à installer tous les composants logiciels nécessaires.
 J'ai déjà installé une base de données géospatiale et un serveur Web
 pour jouer avec GeoDjango, mais j'avais bêtement suivi des tutoriaux.
 Donc ce n'est pas évident que mon projet se concrétise.



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

 --
 Christian Quest - OpenStreetMap France



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

Re: [OSM-talk-fr] OSM hors ligne

[Pierre Knobel]

On 2/1/15, Eric SIBERT courr...@eric.sibert.fr wrote:
 Non parce que si tu te retrouves sur un bateau avec une connexion
 internet limitée, globalement, je ne vois pas comment tu peux faire pour
 contribuer à OSM. Non seulement l'accès à la base OSM est difficile mais
 qu'en est-il d'autres sources de données?

 L'upload n'est pas
 nécessairement problématique car tu n'envoies que ce que tu as modifié.
 Par contre, attendre un mois, c'est risquer les conflits d'édition.


J'ai pas répondu clairement à ça, désolé. Pour l'instant la bande
passante est suffisament correcte pour permettre d'accéder aux
quelques Mo de données dans JOSM en téléchargement ainsi qu'en export.
Mais comme je le dis dans mon autre e-mail, j'anticipe une
dégradation. Ca signifiera pour moi que je ne pourrais plus contribuer
pendant mes périodes en mer. Il n'est pas question de télécharger des
données et de les emporter sur mon disque dur pour travailler dessus
offline.

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

Re: [OSM-talk-fr] OSM hors ligne

[Pierre Knobel]

Pour ce qui est de la contribution depuis un bateau, c'est armchair
mapping (adresses, landuse à partir d'imageries aériennes, dégommage
de rouge dans la couche BANO... etc). De temps en temps on fait un
arrêt au port et on peut aller faire quelques bonnes contributions
issues du terrain ;) .

Mais là il ne s'agit pas de contribuer, juste d'avoir accès à des
services cartographiques pour économiser les accès web à GoogleMaps et
OSM, histoire de pouvoir continuer à explorer le monde et planifier
les prochaines vacances même quand internet nous lâche au boulot.
J'anticipe aussi des restrictions de plus en plus importantes dans les
conditions d'utilisation de la connexion internet, c'est un peu la
crise dans notre secteur et réduire la bande-passante permet de faire
quelques économies.

L'accès à Overpass-Turbo est un peu du luxe, c'est juste que le sujet
m'intéresse et que j'ai envie de pouvoir continuer à jouer avec pour
faire du minage dans les données.

Je pense que toute la question de l'accès aux données OSM hors ligne
reste à défricher et que ça pourrait avoir des applications plus
éducatives et d'un intérêt plus général que mon problème particulier.
On peut déjà utiliser une petite partie des données sur un GPS ou un
téléphone mobile pour faire de la navigation, mais on n'a pas encore
de bonne solution pour la problématique Je suis dans la brousse avec
mon ordinateur portable, j'aimerais bien savoir à quoi ressemble Tokyo
ou Reykjavik.

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

[OSM-talk-fr] OSM hors ligne

[Pierre Knobel]

Bonsoir.

Je suis en train de me demander s'il existe des solutions pour consulter
l'intégralité d'OSM sans accès internet.

Mon problème c'est que je travaille dans un environnement où l'accès
Internet est très lent et très cher, et où il est impossible de télécharger
plus de quelques Mo de données par heure sans impacter la bande passante de
mes collègues. On se partage une connexion satellite pour 50 personnes, et
la majorité de la bande passante est allouée aux usages professionnels,
sans rapport avec OSM.

Je ne m'attends pas à trouver une solution toute prête pour OSM comme on en
trouve pour Wikipedia (
http://fr.m.wikipedia.org/wiki/Wikip%C3%A9dia:Wikip%C3%A9dia_hors-connexion),
donc je me demande quel type de matériel il me faudrait pour héberger la
base de données complète planet, un serveur de tuiles et overpass-turbo. Il
n'y aurait pas besoin de grosses performances, le plus souvent il n'y
aurait qu'un seul utilisateur à la fois, et jamais plus de deux ou trois
(dans le cas où je parviendrais à faire marcher les serveurs sur
l'intranet).

Est-ce que vous pensez qu'un PC de bureau récent avec une petite rallonge
d'espace disque (1 ou 2 To) pourrait faire l'affaire ?

En admettant que j'arrive à faire tourner tout ça, est-ce qu'il existe une
solution pour mettre à jour la base de données de manière intermittente
(une fois tous les deux mois dans mon cas) sans devoir réimporter
l'intégralité de la base de données ?

Je précise que je pars de loin, et qu'il me faudrait une bonne doc pour
réussir à installer tous les composants logiciels nécessaires. J'ai déjà
installé une base de données géospatiale et un serveur Web pour jouer avec
GeoDjango, mais j'avais bêtement suivi des tutoriaux. Donc ce n'est pas
évident que mon projet se concrétise.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Comment afficher les noms de lieux en français sur toute la planète ?

[Pierre Knobel]

Le lien : http://tile.openstreetmap.fr/

On 1/26/15, Philippe Verdy verd...@wanadoo.fr wrote:

 Sinon pour voir l'existant tu peux utiliser la carte du rendu OSM
 francophone (qu'on voit sur plusieurs outils francophones comme Osmose ou
 Layers).

 Le 26 janvier 2015 22:27, Lionel Allorge lionel.allo...@lunerouge.org a
 écrit :

 Bonjour,

 Est-il possible de faire afficher les noms de lieux en français sur toute
 la
 planète lorsque l'on navigue sur OSM ?

 Merci d'avance.

 Bonne continuation.

 --

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

Re: [OSM-talk-fr] [Tagging] Deprecation of associatedStreet-relations

[Pierre Knobel]

J'avais compris que l'alternative proposé était la solution sans
relation (addr:street sur noeud) et j'ai voté en fonction.

Si l'alternative est la relation Street, je n'ai pas d'avis, c'est
vraiment équivalent. S'il faut renommer le role house et rajouter un
role associated dans AssociatedStreet, ca ne me dérange pas non plus.

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

Re: [OSM-talk-fr] Guide du débutant

[Pierre Knobel]

Il y a un problème sur http://learnosm.org/fr/beginner/introduction/ :
quand on atteint le bas de la première page qui présente l'utilité des
cartes en général, je ne trouve pas de lien ou de bouton pour
continuer vers la suite.

Sur la page anglaise, on a :
--
Moving Forward

Click on the link for further reading on:

* Getting started on OpenStreetMap.org
* Getting started with the iD editor
* Getting started with the JOSM editor
--

J'ai oublié comment fonctionne github, si quelqu'un d'autre pouvait
réparer ça, ce serait sympa.




On 1/17/15, Yves Pratter yves.prat...@gmail.com wrote:
 Pour l'instant le point d'entrée des débutants que j'ai trouvé sur le Wiki
 est :
 http://wiki.openstreetmap.org/wiki/FR:Beginners%27_guide
 http://wiki.openstreetmap.org/wiki/FR:Beginners%27_guide

 J'ai ajouté son lien sur la page d'accueil francophone
 http://wiki.openstreetmap.org/wiki/FR:Page_principale du wiki à la
 section Apprendre à contribuer’.

 Tu peux rajouter un lien vers http://learnosm.org/fr/
 http://learnosm.org/fr/ :-)

 —
 Yves



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

Re: [OSM-talk-fr] Guide du débutant

[Pierre Knobel]

La section Moving forward manque sur d'autres pages en français,
peut-être toutes.

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

Re: [OSM-talk-fr] Base d’adresse : union de raison entre l’IGN et OpenStreetMap

[Pierre Knobel]

On 11/18/14, Ronan Morin ronan_mo...@hotmail.com wrote:
 J'avoue ne pas bien voir l'interet de l'état/IGN/La Poste de s'associer avec
 nous alors qu'on ne leur apportera pas nos données alors qu'on profite de
 leurs et que notre fichier BAN(O) sera en concurrence avec le leur et
 théoriquement meilleur(à terme, avec les infos de la BAN(O) plus les
 corrections OSM, on aura une base plus précise).

Je crois que l'idée c'est :
- on nous met les adresses à disposition, donc on les met dans OSM
- dans OSM elles peuvent être corrigée, et peut-être qu'un programme
élaboré peut surveiller ces corrections et souligner les différences
pour aider à la mise à jour de BAN

Plus directement, on peut imaginer un mécanisme de contribution qui
puisse mettre à jour à la fois OSM et la BAN, pour les contributeurs
qui ne voient pas d'objection à la double licence. Un plugin JOSM, ou
un éditeur dédié en ligne. Vous en pensez quoi ?

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

Re: [OSM-talk-fr] Base d'adresse : union de raison entre l'IGN et OpenStreetMap

[Pierre Knobel]

On 11/18/14, Yves Pratter yves.prat...@gmail.com wrote:
 J’espère que coté OSM on ne saisira plus d’adresses, mais que les
 contributeurs le feront coté BAN ?

 C’est possible techniquement de mettre un « filtre » sur le serveur OSM pour
 empêcher les modifications d’adresses en France et ne laisser passer que
 celles qui viendraient de la BAN ?


Oula, surtout pas !
C'est un point qui me fait un peu peur dans cette affaire : comment
est-ce qu'on va éviter que de bonnes contributions dans OSM soient
écrasées par des imports massifs de données officielles ?

Il y aura des utilisateurs qui ne seront pas conscient qu'ils peuvent
participer directement dans la base commune, d'autres qui ne voudront
pas alimenter une base de données qui va profiter à des compagnies
privées.

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

Re: [OSM-talk-fr] Base d'adresse : union de raison entre l'IGN et OpenStreetMap

[Pierre Knobel]

Le 18 nov. 2014 11:00, Yves Pratter yves.prat...@gmail.com a écrit :

 D’un autre côté, si on n’utilise pas la BAN, on ne cherchera pas à la
corriger ;-)

On est d'accord, il faut faire le maximum pour encourager les améliorations
dans la BAN. Mais il restera toujours des utilisateurs qui voudront
corriger une adresse dans OSM juste pour que leur maison apparaisse bien
sur le rendu principal (openstreetmap.org), en cliquant sur Modifier.  Je
pense que si au moment de faire la modif on leur dit ah mais non, c'est
pas comme ça qu'on fait en France, il faut passer par l'autre interface et
lire les termes de la double licence, une partie d'entre eux va laisser
tomber l'affaire.


  d'autres qui ne voudront pas alimenter une base de données qui va
profiter à des compagnies privées
 C’est gagnant / gagnant, non ?

Bof, je ne suis pas convaincu. Qui sait, en utilisant uniquement les
données DGFIP/cadastre et les contributions issues du terrain on aurait
peut-être pu en quelques années aboutir à une base rivalisant avec La Poste
et purement en Odbl.
Je trouve que c'est une énorme concession qu'on leur fait, de les autoriser
à vendre nos contributions à Google (si on choisit de contribuer à  la
BAN... pour ma part ce n'est pas encore décidé).
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Cartographie sentiers de randonnée du topoguide du Pays d'Ambert

[Pierre Knobel]

Je m'étonne que personne n'énonce clairement la solution simple et élégante
à ce problème récurrent sur le champ d'application de la propriété
intellectuelle : abolition de la propriété intellectuelle.

Si c'est tellement compliqué de définir ce que la propriété intellectuelle
doit protéger et ce qui doit rester libre, si on a besoin de rédiger des
licences de plusieurs pages pour s'en servir de béquille pour protéger OSM
contre Google, si on a des guerres de brevets sur la forme d'une tablette,
si on se retrouve à ne pas pouvoir illustrer un article wikipédia avec une
photo bâtiment remarquable ou d'une sculpture dans un parc...etc c'est
peut-être que le concept de propriété intellectuel est complètement bancal
à la base.

Essayez d'imaginer un monde sans propriété intellectuelle. Oubliez les
quelques conséquences négatives à court/moyen terme sur les industries qui
ont basé leur business model sur ce concept, regardez plus loin dans le
futur. Personnellement je ne vois que du positif.

Sur ce, je vais aller me coucher et continuer à rêver les yeux fermés.


2014-10-20 21:02 GMT+02:00 PhQ pierre.que...@sfr.fr:

 J'ai trouvé ce document que nous devrions avoir comme référence pour nos
 prochains échanges sur le sujet.

 http://tyrando.free.fr/guidejuridique_rando0908.pdf

 (Je ne fournis pas l'aspirine)

 Si, bien évidement, le droit à la cartographie n'est pas abordé dans cet
 opuscule, nous apprendrons néanmoins en page 12 sur 80 que

  Ainsi, un simple aménagement et/ou entretien d’un
 sentier de randonnée est considéré comme ouvrage
 public.
 ...
 je vous laisse le soin d'apprécier la pertinence de cette phrase dans son
 contexte.

 N'est il pas amusant de constater qu'un chemin balisé n'est en sorte
 qu'un
 ouvrage comme un autre, une route, un pont (on a demandé l'autorisation de
 cartographier le viaduc de Millau à son architecte et à Eiffage (c) ?), un
 banc (public) etc etc

 Dans l'absolu, s'il existait quelque part une convention entre la seule
 association et un particulier pour convenir de l'usage particulier d'un
 chemin pour l'usage des seules membres de l'association, nous ne serions
 pas
 libre sans autorisation d'en faire état, dans le cadre de la
 confidentialité
 des affaires privés.

 Dans la pratique,( c'est à vérifier), le document parle de conventions
 tripartites concernant des chemins privés, dont une des parties est une
 collectivité publique, et donc engage la responsabilité publique, et la
 connaissance par le citoyen des conventions qu'on signe en son nom.

 C'est pourquoi, je propose que le contributeur OSM éclairé puisse se lancer
 dans le recollement des conventions  de toute nature PLU ZAC ZUP ..   et
 aussi d'ouverture au public de chemin de randonnée,  toutes ces conventions
 étant par  nature  publiques... en mentionnant bien entendu les
 contractants
 :)

 CQFD ?




 --
 View this message in context:
 http://gis.19327.n5.nabble.com/Cartographie-sentiers-de-randonnee-du-topoguide-du-Pays-d-Ambert-tp5820849p5820983.html
 Sent from the France mailing list archive at Nabble.com.

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

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

Re: [OSM-talk-fr] Import automatique de traces GPS, bien ou mal ?

[Pierre Knobel]

Bonjour.

Je dirais que c'est bien. Une trace GPS brute a un peu trop
d'imprécision, avec 200 traces on doit commencer à pouvoir bien
localiser les différentes voies en faisant une carte de densité de
points.
Il y aussi les fait que les rues changent, des ronds points sont
ajoutés... C'est bien d'avoir des traces ajoutées régulièrement, ça
serait encore mieux si on pouvait spécifier un intervalle de date au
moment de charger les traces GPX dans JOSM pour virer les anciennes
traces quand on sait qu'un endroit a été modifié récemment.

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

Re: [OSM-talk-fr] fichier history france

[Pierre Knobel]

Bonjour,

Je serais assez interessé par:
- l'évolution du nombre de kilomètres de highway=path, le nombre de
kilomètres de highway=path + sac_scale=*, le nombre de km de
highway=track et le nombre de kilomètres de highway=track +
tracktype=*, pour voir le boulot abbatu par les randonneurs et les
amateurs de grand air.
- l'évolution de la surface de polygones landuse en excluant ceux
qui contiennent CORINE dans la source, mais je ne sais pas si c'est
facile de gérer les multipolygones.

Merci d'avance!
Pierre

On 9/22/14, didier2020 didier2...@free.fr wrote:
 bonjour,

 pour voir j'ai importé le fichier history france
 24H de traitement, 393 Millions de nodes

 j'ai détaillé ce que j'ai fais ici :
 https://wiki.openstreetmap.org/wiki/User:Didier2020/Utilisation_fullhistory

 je n'ai pas été plus loin que l'analyse du km de voie et du nombre de
 batiment mais si quelqu'un veut une analyse particuliere, y a ka
 demander...


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


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

Re: [OSM-talk-fr] fichier history france

[Pierre Knobel]

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

Re: [OSM-talk-fr] Multipolygone et landuse avec des valeurs différentes

[Pierre Knobel]

Je n'ai jamais créé de multipolygone pour un batiment dans une forêt.
Parfois quand je repère un jardin ou un parking à coté du bâtiment je
crée un membre landuse=residential en inner de la forêt qui englobe
la maison.

Je trouve les multipolygones assez fastidieux et inutiles dans la
plupart des cas, sachant qu'un algorithme de rendu bien programmé
pourrait généralement se débrouiller tout seul les créer à partir de
règles de bon sens. Par exemple si un landuse=meadow est inclus dans
un landuse=forest, c'est forcément un multipolygone ; si un
leisure=pitch est inclus dans un leisure=park, ce n'est pas un
multipolygone parce que le terrain de sport fait par défaut partie du
parc englobant, sauf  si on spécifie le contraire en créant le
multipolygone pour préciser... etc

Créer des multipolygones systématiquement pour les occupations de sol
c'est un peu l'équivalent de mettre oneway=no et motor_vehicle=yes
sur toutes les routes départementales.

Mais comme je n'aime pas faire hurler les outils de validation, je me
plie aux règles.

On 9/17/14, Félix Marty felixma...@outlook.com wrote:
 Dans le cas d'un bâtiment dans une forêt, il faudrait créer un multipolygone
 et inclure le batiment avec inner, ou c'est quelque chose de facultatif ?

 Date: Wed, 17 Sep 2014 11:52:45 +0200
 From: pier...@gmail.com
 To: talk-fr@openstreetmap.org
 Subject: Re: [OSM-talk-fr]   Multipolygone et landuse avec des valeurs
 différentes

 2014-09-16 19:49 GMT+02:00 Jérôme Seigneuret jseigneuret-...@yahoo.fr:
  Je vois pas le problème j'ai fait un test bidon voici le résultat.
  Si tu veux matérialiser les bois d'un parc, tu es bien obligé de faire
  un
  multipolygone pour en isoler les fermes agricole... et autres
  activités.

 Dans le cas mentionné sur ce fil, on n'a pas un landuse à l'intérieur
 d' un autre landuse mais deux landuse côte à côte:
 http://www.openstreetmap.org/way/201745108
 http://www.openstreetmap.org/way/42117058

 Pieren

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


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

Re: [OSM-talk-fr] Utilisation du logo OSM possible sans attribution ?

[Pierre Knobel]

D'un point de vue du droit d'auteur, c'est cc-by-sa 3.0
(http://wiki.openstreetmap.org/wiki/File:Public-images-osm_logo.svg),
donc normalement il faut une attribution. Mais peut-être qu'il y a des
exceptions à la règle quand il s'agit d'une petite icône servant de
logo, j'ai du mal à voir comment on pourrait placer l'attribution de
manière raisonnable sans que ça occupe plus de place que le logo
lui-même.

D'un point de vue du droit des marques, c'est plus compliqué il me
semble.Sur http://commons.wikimedia.org/wiki/File:Openstreetmap_logo.svg
je vois Permission: None, Trade Mark UK2500155 at ipo.gov.uk for
Class 41 to Proprietor Steve Coast, Surrey, UK



On 9/14/14, George Kaplan georgekaplan...@hotmail.fr wrote:
 Bonjour,
 En visitant le site web de la ville de Mouans-Sartoux
 (http://www.mouans-sartoux.net), j'ai remarqué le logo OSM agrémenté du logo
 de la ville. Je m'attendais à tomber sur un plan de la ville sur fond OSM.
 Déception, la page affiche un fond Google Maps.
 Bref, on voit souvent passer des manques d'attributions sur les cartes mais
 quid du logo ? Quelle est la licence du logo ? Est-il possible de le
 modifier ?
 George
 ___
 Talk-fr mailing list
 Talk-fr@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-fr


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

Re: [OSM-talk-fr] Oubliez l'imagerie aérienne pour les sentiers en montagne !

[Pierre Knobel]

2014-09-05 8:37 GMT+02:00 Charles Nepote char...@nepote.org:


 Pour ma part quand je vais dans des endroits sauvages je croise toujours
 mes infos OSM avec d'autres sources. La montagne par exemple ça ne rigole
 pas.


Le pire dans cette histoire c'est que j'avais d'abord trouvé le bon départ
du sentier en suivant un topo (c2c), mais que je me suis dit c'est pas
possible, c'est beaucoup trop loin du tracé OSM, ça doit être un des
nombreux départ de sentiers qui se perdent rapidement dans les falaise.
J'ai fait demi-tour, j'ai essayé de coller au tracé OSM en voyant très bien
que la connexion des sentiers n'était pas là, mais que ça partait droit
dans la pente. Je suis rapidement tombé sur un sentier pratiquable, et
quand il a fini par se perdre j'étais trop loin pour faire demi-tour (ça
aurait été pénible à cause des nombreux passages très raides). Et comme à
ce moment là je voyais le bon sentier beaucoup mieux tracé que celui où
j'étais un peu plus haut, j'ai tenté l'option grimpe dans les petits bouts
de falaise. Et c'est ça qui a mené au moment vraiment désagréable à
mi-grimpe, incapable de désescalader et avec  deux derniers pas à faire sur
des prises vraiments moisies que j'avais mal jugées vues d'en-bas.

Bref, une série d'erreurs de jugement que je n'aurais pas faites sans la
pression du mental (1200 m de déniv dans les pattes, nécessité d'arriver au
sommet avant le coucher de soleil pour redescendre en parapenteetc). Ca
suffit pas toujours de savoir que quelque chose est dangereux pour ne pas
le faire. Et donc ça ne suffit pas de savoir qu'une carte peut-être
défaillante pour ne pas s'appuyer dessus dans un moment difficile.

J'ai moi même tracé des sentiers dans le même secteur en m'appuyant sur
Bing, à mes débuts, avant de me rendre compte que j'étais en train de
tracer des trucs incertains en bord d'une falaise de 300 m et de vérifier
sur le terrain que la géométrie était fausse à cause de
l'orthorectification basée sur le modèle de terrain trop lissé. Donc je ne
jette la pierre à personne. J'ai juste jugé bon de partager mon expérience
pour peut-être éviter à autres de devoir passer pa
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Oubliez l'imagerie aérienne pour les sentiers en montagne !

[Pierre Knobel]

Désolé, message parti trop tôt.

J'ai juste jugé bon de partager mon expérience pour peut-être éviter à
d'autres débutants de devoir passer par les mêmes erreurs.

En tout cas je suis content de voir que ce sujet lance une discussion sur
l'amélioration des données hors-asphalte ;)
J'ai deux idées qui pourraient aider à améliorer OSM pour la rando :
- création d'un club ffcam/ffrp et OSM (rando-carto), ou au moins
l'infiltration d'un club existant
- un truc similaire aux notes d'OSM pour permettre aux non-contributeurs de
signaler facilement des sentiers manquants dans une surcouche OSM, avec un
éventuellement un tracé approximatif et des détails (lien vers un topo)
pour donner des idées de rando à des contributeurs OSM.

Bonne journée,
Pierre


2014-09-05 12:12 GMT+02:00 Pierre Knobel pierr...@gmail.com:


 2014-09-05 8:37 GMT+02:00 Charles Nepote char...@nepote.org:


 Pour ma part quand je vais dans des endroits sauvages je croise
 toujours mes infos OSM avec d'autres sources. La montagne par exemple ça ne
 rigole pas.


 Le pire dans cette histoire c'est que j'avais d'abord trouvé le bon départ
 du sentier en suivant un topo (c2c), mais que je me suis dit c'est pas
 possible, c'est beaucoup trop loin du tracé OSM, ça doit être un des
 nombreux départ de sentiers qui se perdent rapidement dans les falaise.
 J'ai fait demi-tour, j'ai essayé de coller au tracé OSM en voyant très bien
 que la connexion des sentiers n'était pas là, mais que ça partait droit
 dans la pente. Je suis rapidement tombé sur un sentier pratiquable, et
 quand il a fini par se perdre j'étais trop loin pour faire demi-tour (ça
 aurait été pénible à cause des nombreux passages très raides). Et comme à
 ce moment là je voyais le bon sentier beaucoup mieux tracé que celui où
 j'étais un peu plus haut, j'ai tenté l'option grimpe dans les petits bouts
 de falaise. Et c'est ça qui a mené au moment vraiment désagréable à
 mi-grimpe, incapable de désescalader et avec  deux derniers pas à faire sur
 des prises vraiments moisies que j'avais mal jugées vues d'en-bas.

 Bref, une série d'erreurs de jugement que je n'aurais pas faites sans la
 pression du mental (1200 m de déniv dans les pattes, nécessité d'arriver au
 sommet avant le coucher de soleil pour redescendre en parapenteetc). Ca
 suffit pas toujours de savoir que quelque chose est dangereux pour ne pas
 le faire. Et donc ça ne suffit pas de savoir qu'une carte peut-être
 défaillante pour ne pas s'appuyer dessus dans un moment difficile.

 J'ai moi même tracé des sentiers dans le même secteur en m'appuyant sur
 Bing, à mes débuts, avant de me rendre compte que j'étais en train de
 tracer des trucs incertains en bord d'une falaise de 300 m et de vérifier
 sur le terrain que la géométrie était fausse à cause de
 l'orthorectification basée sur le modèle de terrain trop lissé. Donc je ne
 jette la pierre à personne. J'ai juste jugé bon de partager mon expérience
 pour peut-être éviter à autres de devoir passer pa

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

Re: [OSM-talk-fr] Oubliez l'imagerie aérienne pour les sentiers en montagne !

[Pierre Knobel]

Je n'aime pas le concept de travail itératif dans ce contexte de tracé de
sentiers de rando, surtout dans les zones peu fréquentées. Comme dit, il y
a trop peu de randonneurs qui contribuent activement à OSM, et ceux comme
moi qui le font choisissent généralement leurs sorties pour récolter des
traces GPS de sentiers encore inexistant dans la base. Donc si on trace un
sentier incorrect à partir d'une image Bing incorrectement orthorectifiée,
ça va prendre très longtemps (des années) avant qu'il ne soit corrigée et
on prend le risque de perdre quelques utilisateurs non contributeurs de la
donnée entre temps.

 J avais essaye avec mon GPS de rando au cirque de Saint Meme en
Chartreuse la trace faisait n importe quoi. Il faut
 dire qu a cet endroit la falaise est quasi verticale en forme de fer a
cheval et le sentier monte la dedans ainsi qu un
 petit pas equipe via ferrata. Dans ces conditions meme avec le GPS et les
images aeriennes il est tres difficle de
 realiser un trace correct

Le cirque de Saint Meme est un cas extrême pour lequel on a une très grosse
portion du ciel bouché, mais le plus souvent on a au moins la moitié du
ciel dégagé et un bon GPS+glonass (mon Etrex 20 par exemple) garde une
précision de 10 mètres.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Sport=climbing pour escalade sur falaises et arêtes

[Pierre Knobel]

Bonjour,

J'ai du mal à comprendre sur quels objets on peut rajouter
sport=climbong. JOSM me donne une erreur sport without physical feature
quand je rajoute ce tag sur une falaise ou une arête.

Exemples :
https://www.openstreetmap.org/way/300954193 (école d'escalade sur falaise)
https://www.openstreetmap.org/way/300954192 (arête avec passages d'escalade
: http://www.camptocamp.org/routes/55445/fr/l-ecoutoux-l-arete-a-jojo)

Comment est-ce que vous faites ?

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

Re: [OSM-talk-fr] Eclairs et réseau électrique

[Pierre Knobel]

Quant on voit la portée des stations de mesures - en ce moment
certaines stations en République Tchèque détectent des impacts de
foudre dans le sud-ouest - on se dit que c'est pas nécessaire d'avoir
un réseau hyper dense.

On 8/8/14, David Crochet david.croc...@free.fr wrote:
 Bonjour

 Entre une version officiel [1] qui indique le taux de présence d'orage
 par département et une version collaborative, qui indique une présence
 aux alentours, je crois que le choix est vite fait.

 Si tu cherches un site d'impact de foudre en temps réel, ils ont
 majoritairement tous la même source.


 Cordialement

 [1] http://www.meteorage.fr/

 --
 David Crochet

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


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

Re: [OSM-talk-fr] effacement volontaire de radar

[Pierre Knobel]

Le ne sais pas si ça peut aider, voilà quelques bases théoriques à
propos d'enforcement : http://what-if.xkcd.com/87/


On 7/25/14, willemijns sebast...@willemijns.com wrote:
 oui, j'arrive toujours pas a comprendre le truc...



 --
 View this message in context:
 http://gis.19327.n5.nabble.com/effacement-volontaire-de-radar-tp5812599p5812757.html
 Sent from the France mailing list archive at Nabble.com.

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


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

[OSM-talk-fr] Sentiers de randonnée sur Google Maps

[Pierre Knobel]

J'ai l'impression que le nombre de sentiers de randonnée a récemment
(~un an) explosé sur Google Maps. Certains de ces sentiers ne sènt pas
encore visibles sur les cartes IGN du commerce, mais on les retrouve
en zoomant à fond sur Géoportail.

Exemple : 
https://maps.google.co.uk/maps?ll=45.453739,5.919965spn=0.002013,0.003106sll=53.800651,-4.064941sspn=13.914195,25.444336t=mz=19
C'est un tout petit sentier assez scabreux et peu visible sur le
terrain qui relie le passage de Tencovaz et la Balme à Colon sous la
face ouest du mont Granier à la frontière entre Isère et Savoie, je
l'ai découvert grace à un topo dans le livre « Les nouvelles
randonnées du vertige - Chartreuse et Vercors ».

D'où pensez-vous que proviennent ces données ? Est-ce que ça a un
rapport avec la campagne de numérisation des sentiers par la FFRP ?

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

Re: [OSM-talk-fr] Noms de voies suffixés

[Pierre Knobel]

Les fusions et associations de communes ont parfois pour effet de causer
l'incorporation de deux rues avec le même nom dans une commune donnée, ce
qui rend nécessaire de préciser le nom de la commune d'origine en
complément d'adresse. Ou peut-être qu'il est juste nécessaire de rajouter
ce complément pour simplifier la vie des livreurs et facteurs,  même quand
on ne se retrouve pas avec deux noms de rues identiques dans la commune
officielle résultant de la fusion. Il semblerait que dans la base FANTOIR
ce complément d'adresse ait été rajouté à la suite du nom de la voie plutôt
que dans un champ à part.  Bref,  c'est ce qui explique que quand on
regroupe les voies proches qui ont un suffixe commun on se retrouve avec
les zones de communes associées/fusionnées.

L'enjeu de ce dont on parle ici c'est de faire le rapprochement entre les
rues dans OSM (qui n'ont pas ce complément d'adresse à la fin du champ
name=*,  vu que ça ne correspond pas à  la réalité du terrain)  et les
voies correspondantes du FANTOIR. Et on fait ça parce que ça permet de
rapprocher automatiquement les points d'adresses du cadastre à leur rues
d'OSM. J'explique parce que pour ceux qui ne sont pas activement impliqués
dans la saisie d'adresses depuis le cadastre ou le rapprochement des voies
en rouge du rendu BANO,  ce n'est pas forcément très clair.
Le 7 juil. 2014 01:48, Dominique Rousseau d...@lee-loo.net a écrit :

 Le Sun, Jul 06, 2014 at 12:18:26PM +0200, Vincent de Château-Thierry [
 v...@laposte.net] a écrit:
 [...]
 
  Si ça vous inspire des remarques sur des manques, des incohérences
  ou autre, c'est l'endroit :)

 C'est marrant.
 Sur Lille, ça trouve la délimitation de 2 communes associées « récemment
 » (vers 2000), Hellemmes et Lomme :

 http://osm.vdct.free.fr/hameaux/index.html#zoom=13lat=50.6343lon=3.0639


 --
 Dominique Rousseau
 d...@lee-loo.net - 06 82 43 12 27

 A l'instant où l'esclave décide qu'il ne sera plus esclave,
 ses chaînes tombent.  -- Mahatma Gandhi

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

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

Re: [OSM-talk-fr] Noms de voies suffixés

[Pierre Knobel]

C'est bien, ça va dégommer beaucoup de rouge sur la couche BANO. Je n'ai
qu'une remarque : est
Le 6 juil. 2014 04:19, Vincent de Château-Thierry v...@laposte.net a
écrit :

 Bonjour,
 Suite à un ticket ouvert dans Bano [1], j'ai cherché à détecter les zones
 où un suffixe de voie est suffisamment fréquent pour former une zone. Ça
 donne cette visualisation :
 http://osm.vdct.free.fr/hameaux/index.html#zoom=6lat=46.76lon=2.85
 où on croise souvent (en orange) des noms de hameaux, mais pas seulement.
 La couche bano est disponible en haut à droite pour voir quels noms de
 voies ont permis de constituer une zone (à fort zoom).
 Pour l'instant la constitution d'une zone est influencée par la
 combinaison de:
 - au moins 5 voies avec le même suffixe de 1 ou 2 mots
 - la présence d'adresses sur ces voies
 - la proximité spatiale suffisante des adresses pour former un agrégat

 La finalité c'est de faire grâce à cette couche de polygones le
 rapprochement entre voies Fantoir et Cadastre (suffixées) et voies d'OSM,
 évidemment pas suffixées.

 Si ça vous inspire des remarques sur des manques, des incohérences ou
 autre, c'est l'endroit :)

 merci
 vincent

 [1] : https://github.com/osm-fr/bano/issues/10

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

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

Re: [OSM-talk-fr] Noms de voies suffixés

[Pierre Knobel]

Désolé, je répond sur une tablette et j'ai des gros doigts. Je disais que
je me demande si on ne pouvait pas descendre le seuil de 5 à 3, voir 2, si
on ne s'intéresse qu'aux voies qui n'ont pas déjà été rapprochées par les
autres méthodes.

Je n'ai pas regardé de près le code source des outils de rapprochement,
mais j'imagine quelque  chose du genre : sur une commune donnée,  on trouve
d'abord toutes les voies dont le nom FANTOIR est identique à  celui d'OSM,
puis sur les voies restantes on essaye de résoudre les abréviations, et
pour finir on s'intéresse à toutes les voies restantes qui ont le même
suffixe. Si en enlevant le suffixe on trouve une correspondance dans OSM,
bingo.
Je ne vois pas de gros risque d'effet de bord à appliquer ça dès qu'on a
deux rues avec un suffixe commun. Peut-être même qu'il faudrait aller
jusqu'à tenter de virer le dernier mot des rues uniques pour voir si ça ne
permet pas le rapprochement.

Ça permettrait de traiter les nombreux touts petits hameaux.
Le 6 juil. 2014 14:55, Pierre Knobel pierr...@gmail.com a écrit :

 C'est bien, ça va dégommer beaucoup de rouge sur la couche BANO. Je n'ai
 qu'une remarque : est
 Le 6 juil. 2014 04:19, Vincent de Château-Thierry v...@laposte.net a
 écrit :

 Bonjour,
 Suite à un ticket ouvert dans Bano [1], j'ai cherché à détecter les zones
 où un suffixe de voie est suffisamment fréquent pour former une zone. Ça
 donne cette visualisation :
 http://osm.vdct.free.fr/hameaux/index.html#zoom=6lat=46.76lon=2.85
 où on croise souvent (en orange) des noms de hameaux, mais pas seulement.
 La couche bano est disponible en haut à droite pour voir quels noms de
 voies ont permis de constituer une zone (à fort zoom).
 Pour l'instant la constitution d'une zone est influencée par la
 combinaison de:
 - au moins 5 voies avec le même suffixe de 1 ou 2 mots
 - la présence d'adresses sur ces voies
 - la proximité spatiale suffisante des adresses pour former un agrégat

 La finalité c'est de faire grâce à cette couche de polygones le
 rapprochement entre voies Fantoir et Cadastre (suffixées) et voies d'OSM,
 évidemment pas suffixées.

 Si ça vous inspire des remarques sur des manques, des incohérences ou
 autre, c'est l'endroit :)

 merci
 vincent

 [1] : https://github.com/osm-fr/bano/issues/10

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


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

Re: [OSM-talk-fr] Les communes associées

[Pierre Knobel]

J'ai commencé à utiliser le tag addr:place systématiquement pour les
communes qui ont disparu dans les communes associées et les communes
fusionnées. J'ai un peu hésité avec le tag addr:hamlet, les deux pourraient
fonctionner. C'est clair qu'il faut un tag spécifique, ne serait-ce que
pour gérer les noms de rues en double dans certaines communes fusionnées
résultantes.


2014-06-23 16:11 GMT+02:00 Philippe Verdy verd...@wanadoo.fr:

 Pour BANO, ce qui nous intéresse ce sont les adresses, pas les limits
 adminsitratives.

 Encore une fois on tombe sur quelque chose qui est résolu dans les autres
 pays (même juste à cpoté de nous par exemple en BElgique ou en Allemagne,
 et même au Royaume-Uni), avec des relations pour les zones postales
 (boundary=postal_area).

 Une adresse postale n'est pas une entité administrative en tant que telle
 (et encore moins depuis que les services postaux sont ouverts à la
 concurrence, on ne parlera bientôt même plus d’administration postae, même
 si les salariés de la Poste conservent leur statut public, employé dans une
 société semi-publique qui a elle-même des actionnaires autres que l'Etat et
 joue déjà sur les marchés internationaux avec tout un tas de filiales, même
 en France comme Chronoposte).

 Bref il serait tant de tracer des zones postales (liées non pas au code
 INSEE d'une commune (ce qui n'a souvent pas de sens dans des adresses en
 bordure de commune desservies par le bureau d'une autre), qui ne suit pas
 non plus les évolutions du mille-feuille adminsitratif, mais bel et bien
 lié au code postal (quitte à mettre dans une zone donnée pour un même code
 postal un sous-découpage communal, ou infracommunal pour les communes
 associées ou anciennes communes.

 Ce découpage aura aussi l'avantage de conserver les noms des zones
 postales (communes ou sous-communes) les plus appropriés pour le courrier
 et la géolocalisation (le découpage postal est plus utile en fait que le
 découpage administratif pour la géolocalisation et on sait l'importance
 qu'a la géolocalisation pour utiliser nos cartes et y positionner des tas
 de services qui n'ont rien d'adminsitratif)


 Le 23 juin 2014 15:23, Christian Quest cqu...@openstreetmap.fr a écrit :

 Le problème c'est que ces communes associées sont un résidu de
 fusion-association mais ne sont pas des communes en tant que telles.

 Elles ne figurent plus dans la liste des communes actuelles, leur code
 INSEE semble conservé à titre plus ou moins historique mais n'a en fait
 plus d'usage...
 Elle ne figure que dans le fichier historique disponible en
 téléchargement.

 FANTOIR ne les connait plus non plus.

 Donc pour moi, ce code INSEE n'est plus actuel car plus utilisé. Pour
 les problèmes d'adresse postale, il faut indiquer le nom de l'ancienne
 commune pour lever l'ambiguité sur les noms de rues communs (plus de 100
 cas de ce type à Lille)... parfois il reste un bureau distributeur (cas des
 grosses agglos comme Lille), parfois il n'y en a pas (fusion de communes
 rurales).

 Entièrement d'accord pour trouver une modélisation adapté dans OSM, BANO
 s'adaptera et pas l'inverse.

 Pour les relations avec admin_level=10, elles ont été utilisées pour les
 fusions récentes de communes dont on connaissait les limites, afin de les
 conserver. C'est peut être pas idéal, mais au moins, on a gardé l'info
 plutôt que de la perdre. On voit que c'est c'est utile car pour Neuville
 connaitre la limite serait bien utile.

 ah oui... Neuville-les-Dieppe a pour code postal 76370 alors que c'est
 76200 pour Dieppe, donc c'est bien un bureau distributeur différent

 C'est peut être à gérer comme une frontière de code postal ?
 http://wiki.openstreetmap.org/wiki/Tag:boundary%3Dpostal_code auquel il
 faudrait ajouter un postal_code:name ?





 Le 23 juin 2014 14:53, Pieren pier...@gmail.com a écrit :

 2014-06-23 14:06 GMT+02:00 Christian Quest cqu...@openstreetmap.fr:
  Oui, encore une particularité à gérer et pas facile à gérer. Il y a
 plus de
  700 communes associées d'après
  https://fr.wikipedia.org/wiki/Commune_associ%C3%A9e

 Il faut d'abord régler le problème de modélisation dans OSM avant de
 le faire avec BANO. Si je comprend bien, il y a une seule commune du
 point de vue du cadastre (Dieppe) mais deux du point de vue de
 l'INSEE (COG) :  Dieppe 76217  et Neuville-Lès-Dieppe  76466.
 En regardant un peu, je tombe sur un cas similaire, Lomme, commune
 associée à Lille, qui est en admin_level 10 dans OSM

 http://www.openstreetmap.org/relation/58409#map=13/50.6440/3.0083layers=D
 dans un commentaire dit que le code INSEE 59355 n'est plus valide
 (alors qu'il l'est encore dans le COG). Le noeud place est en
 town, et non suburb comme pour les quartiers

 Pour OSM, je trouverais assez malin cette solution qui distingue les
 quartiers périphériques (place=suburb/neighbourhood) et les communes
 associées (place=town/village), non pas sur l'admin_level 10 de la
 relation (s'il y en a une) mais sur la valeur du tag place.
 Mais pour le 

Re: [OSM-talk-fr] En route pour SOTM-EU !

[Pierre Knobel]

2014-06-14 12:45 GMT+02:00 rainerU ra...@sfr.fr:

 Les vidéos sont disponibles sur

 http://ftp5.gwdg.de/pub/misc/openstreetmap/

 Je n'ai pas compris la systématique des noms de fichiers



On trouve aussi des vidéos sur Youtube avec des titres plus descriptifs :
https://www.youtube.com/user/sotmeu
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] En route pour SOTM-EU !

[Pierre Knobel]

Je n'arrive pas à trouver les images ou des photos des posters du concours,
ni sur le flux twitter ni sur https://www.sotm-eu.org . Quelqu'un sait où
trouver ça ?



2014-06-14 18:30 GMT+02:00 Pierre Knobel pierr...@gmail.com:




 2014-06-14 12:45 GMT+02:00 rainerU ra...@sfr.fr:

 Les vidéos sont disponibles sur

 http://ftp5.gwdg.de/pub/misc/openstreetmap/

 Je n'ai pas compris la systématique des noms de fichiers



 On trouve aussi des vidéos sur Youtube avec des titres plus descriptifs :
 https://www.youtube.com/user/sotmeu


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

Re: [OSM-talk-fr] Tracer les anciens éléments (Était : Relations)

[Pierre Knobel]

Bonjour,

Je suis d'accord avec ça. J'utiliserais railway=disused uniquement si les
anciens rails sont toujours en place, pas si ça a été reconverti en piste
cyclable.

Pierre


2014-06-05 10:59 GMT+02:00 Marc SIBERT m...@sibert.fr:

 Bonjour,

 Perso, je ne vois pas d'intéret à conserver des informations sur des
 éléments disparus dans OSM. SI l'ancienne voie ferrée n'en est plus une,
 ben... c'en est plus une, c'est devenue une piste cyclable. J'imagine que
 le terrassement sera refait et qu'il ne reste pas de trace de la voie
 initiale.

 mes 0.02€

 A+


 Le 5 juin 2014 08:32, Mides mides@gmail.com a écrit :

 Tout à fait, ma question porte sur ce point bien précis : faut il tracer
 deux voie ou pas ? La logique m'orienterait moi aussi vers une seule voie
 reprenant le cas échéant les différentes informations aux travers des tags.
  Et apparemment c'est bien dans ce sens qu'il nous faut aller.

 Michel


 Le 5 juin 2014 08:22, Francescu GAROBY windu...@gmail.com a écrit :

 Si je comprends bien : tu demandes s'il faut tracer 2 ways, une pour
 l'ancienne voie ferrée, l'autre pour la piste cyclable . Sachant que cette
 dernière est sur la première ? Dans ce cas, la réponse est non !
 La piste cyclable et l'ancienne voie ferrée sont une seule et même way,
 qui cumule les tags pour les 2, comme le montre cet exemple
 http://www.openstreetmap.org/way/4610017.

 Francescu


 Le 5 juin 2014 08:08, Mides mides@gmail.com a écrit :

 Prenons un exemple concret.

 Dans ce cas de figure nous avons un tronçon de way qui est sur le
 terrain une piste cyclable, cette dernière se situant sur l'emprise d'une
 ancienne voie ferrée désaffectée  et sera très certainement intégrée dans
 un futur proche, ou pas, dans voie cyclable de plus grande envergure.

 http://www.openstreetmap.org/#map=18/43.00468/1.13042

 Doit on tracer, ou pas,  deux voies parallèles pour refléter ces
 informations ? Mon interrogation est à ce niveau.

 Michel


 Le 5 juin 2014 01:43, Copro Grammes coprogram...@yahoo.fr a écrit :

 Pour une ligne de chemin de fer (au sens d'ensemble de voies, pas de
 service commercial), on peut utiliser une relation type=route +
 route=railway (
 http://wiki.openstreetmap.org/wiki/Tag:route%3Drailway)
  Une partie de la ligne, voire la totalité, pouvant être abandonnée,
 je ne vois pas ce qui empêcherait d'y regrouper des railway=disused.
 Zigeuner




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




 --
 Cordialement,
 Francescu GAROBY

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



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




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

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


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

Re: [OSM-talk-fr] Ordonner les segments d'un fichier gpx

[Pierre Knobel]

En regardant le fichier GPX, on voit qu'il s'agit de l'export d'une
relation OSM : http://www.openstreetmap.org/relation/555705

En cherchant Trnavská stovka sur http://hiking.waymarkedtrails.org/en/ on
trouve un lien pour télécharger le parcours :
http://hiking.waymarkedtrails.org/en/routebrowser/555705/gpx

Il y a moins de segments, reste à vérifier que les points sont dans le bon
ordre.

Si quelqu'un connait une méthode plus générique pour exporter une relation
route en gpx avec les points ou segments dans le bon ordre, je suis
preneur.





2014-06-05 17:25 GMT+02:00 f.dos.san...@free.fr:

 Bonjour,

 Si tu cherches un outil pour éditer un gpx je te conseille viking :

 http://sourceforge.net/projects/viking


 - Mail original -
 De: Benoit Doury benoit.do...@gmail.com
 À: talk-fr talk-fr@openstreetmap.org
 Envoyé: Jeudi 5 Juin 2014 17:12:18
 Objet: [OSM-talk-fr] Ordonner les segments d'un fichier gpx





 Bonjour tout le monde,


 Je me présente : Benoit, je suis nouveau sur la liste de diffusion. Mon
 frère qui est un grand habitué m'a conseillé de vous rejoindre pour avoir
 la réponse a une question relative a l'usage du format gpx.


 Voici le problème que je rencontre: j'ai téléchargé une trace GPS pour un
 trek de 100 km en Slovaquie, au format GPX. La trace est assez riche
 (environ 2500 points) mais divisée en 130 segments de tailles différentes.
 Au sein de chaque segment, les points sont ordonnés correctement (tels
 qu'ils ont été acquis), mais l'ordre des segments ne semble répondre a
 aucune logique : le premier segment est en début de trace, le deuxième en
 fin de trace, etc...
 Le fichier GPX que j'ai téléchargé ne contient que les informations de
 latitude et de longitude (pas de temps ni d'altitude).


 Je cherche une méthode pour ré-ordonner les segments et ainsi avoir une
 trace propre et une bonne estimation de la distance a parcourir.
 J'essaie d’éviter l’écueil de trier les segments manuellement. Auriez-vous
 des suggestions ?


 Le fichier GPX peut etre telecharge ici :
 http://download.freemap.sk/export/gpx/t100.gpx


 Merci d'avance !


 Benoit





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

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

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

Re: [OSM-talk-fr] Rendu BANO

[Pierre Knobel]

Désolé de squatter ta question, mais j'aimerais bien qu'on discute un
peu plus en détail de cette recommandation de ne pas se précipiter sur
l'intégration d'adresses avant de mettre en place des mesures pour la
favoriser. Je comprend que dans l'idéal il vaudrait mieux attendre
d'avoir une position commune sur le placement des adresses avant de
les intégrer plutôt que d'y aller en ordre dispersé, mais est-ce que
vous pensez réellement qu'on aura un consensus sur ce point dans un
futur proche ?

Est-ce qu'on attend l'avis d'acteurs institutionnels, sachant qu'ils
n'ont pas avancé sur le dossier BAN depuis plusieurs années et qu'on
risque d'attendre longtemps ?

Est-ce qu'il ne faudrait pas adopter plutôt l'approche itérative
traditionnelle d'OSM qui est de se mettre à l'intégration tout de
suite, et d'adopter à posteriori un standard en fonction de la
solution favorisée par les premiers contributeurs, en changeant
éventuellement de méthode plus tard si des problèmes apparaissent à
l'usage ?

De mon point de vue on pourrait gagner en efficacité en combinant les
étapes de l'intégration des adresses, de la correction des noms de
rues grace au croisement avec FANTOIR et de l'ajout du code FANTOIR
quand le rapprochement est impossible automatiquement. L'outil
d'import semi-automatique produit les relations AssociatedStreet, il
n'y a plus qu'à y rajouter les tronçons de rues non détectés après
avoir corrgé leur nom.

Pierre

On 5/24/14, Thibault Drevet thibault.dre...@gmail.com wrote:
 Bonjour à tous,

 Je me faisais une remarque au sujet du rendu BANO (
 http://tile.openstreetmap.fr/~cquest/leaflet/bano.html) : étant donné que
 la priorité est dans un premier temps de passer du rouge au bleu, est-il
 pertinent d'afficher à côté du nom des villes le pourcentage d’adresses osm
 par rapport au nombre total d'adresses identifiées?

 En effet, lorsque je vois Ville (0%) ; osm:0 ; cadastre:970, ma première
 réaction est de vouloir améliorer ce pourcentage.

 Dans tous les cas: félicitations pour ce super boulot !

 Thibault


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

Re: [OSM-talk-fr] BANO: 100% des départements traités !

[Pierre Knobel]

 Je ne crois pas que cela ait déjà été signalé, pour le rapprochement :
 oe et œ (exemple : sœur).


Peut-être aussi ae et ä (exemple http://www.openstreetmap.org/way/41940309).

Pour le problème des communes fusionnées avec le nom de l'ancienne
commune rajouté après le nom des rues, on doit aussi pouvoir faire
quelque chose. On pourrait compter le nombre d'occurences pour le
dernier mot de chaque nom de voie qui n'a pas pu être rapprochée, et
pour ceux qui apparaissent plusieurs fois retenter le rapprochement
après avoir supprimé ce dernier mot. Si ça marche, rajouter un
addr:place=dernier mot et un fixme:vérifier addr:place dans le
résultat de l'outil d'intégration.

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

Re: [OSM-talk-fr] Rendu BANO

[Pierre Knobel]

On a ce problème sur toutes les communes fusionnées. Il faudra faire
attention, au moment de créer la relation AssociatedStreet, de bien
préciser le nom de l'ancienne commune d'une manière ou d'une autre
(j'utilise addr:place) pour éviter les noms de rues en double à
l'intérieur d'une unique limite communale. Peut-être même qu'il
faudrait rajouter l'info sur les tronçons de rues, si on part du
principe que c'est une bonne pratique de doubler l'info pour les
exploitants qui ne gèrent pas les relations (comme on le fait déjà
avec name=*).

On 5/22/14, Christian Quest cqu...@openstreetmap.fr wrote:
 Même chose sur Lille... bien sûr il ne faut pas reprendre les libellés du
 cadastre !

 Nous allons devoir traiter ça en exception...


 Le 22 mai 2014 08:15, Vincent Bergeot vinc...@bergeot.org a écrit :

  Le 21/05/2014 17:02, Francescu GAROBY a écrit :

 Si on fait un jeu celui qui a la plus grande zone rouge erronée a
 gagné,
 je crois que je pars bien, avec l'avenue Albert 1er, à
 Caenhttp://layers.openstreetmap.fr/?zoom=16lat=49.17165lon=-0.33986layers=00B00FFT
 (le
 grand triangle rouge, au milieu).

 alors je ne sais pas et je ne veux pas jouer la comparaison mais si l'on
 regarde cette zone :

 http://layers.openstreetmap.fr/?zoom=16lat=44.84862lon=-0.61048layers=00B00FFT

 on peut noter que quasiment toutes les valeurs du cadastre se termine par
 Caud, abréviation de Caudéran, ancienne commune rattachée à Bordeaux en
 1965 :)

 Bonne journée et merci pour cette BANO

 --
 Vincent Bergeot


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




 --
 Christian Quest - OpenStreetMap France


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

Re: [OSM-talk-fr] Un MOOC OSM ?

[Pierre Knobel]

Je suis aussi d'avis qu'il est nécessaire de présenter JOSM. Les débutants
prêts à s'investir dans un MOOC seront surement assez motivés et compétents
pour comprendre les relations (multipolygones pour les iles sur les lacs,
les clairieres dans les forets...), et ils auront besoin de JOSM tôt dans
leur progression.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Trouver les nœuds non rapportés à un bâtiment avec JOSM

[Pierre Knobel]

Pour ma part, je passe systématiquement par une fusion de calques, celui
généré par l'outil pour chaque rue et le calque général pour toute la zone
que j'ai préalablement chargé. Et après seulement je commence à rattacher
les quelques noeuds isolés à leur bâtiment, si j'en trouve un. Je vérifie
aussi toutes les adresses déjà rattachée à un bâtiment, pour vérifier
qu'elles ne sont pas rattachées à un garage, à un entrepôt secondaire ou à
la maison mais côté jardin. Pour retrouver tous les noeuds je fais un zoom
arrière pour englober toute la rue et une bonne marge, puis je sélectionne
la relation pour surligner tous les membres. S'il y a un noeud en dehors de
ma fenêtre d'affichage il me sera signalé au moment d'uploader par un
avertissement adresse trop loin de la rue.


J'ai une petite question, peut-être que quelqu'un saura me répondre :
est-ce qu'il est possible de proprement décoller un point d'un chemin sans
laisser un point inutile sans rôle dans la relation ?

C'est ce qui me fait perdre le plus de temps dans cette affaire,
décoller-déplacer-recoller un adresse puis sélectionner-effacer-confirmer
la suppression de la relation du point inutile.


2014-05-18 8:36 GMT+00:00 Vincent de Château-Thierry v...@laposte.net:

 Bonjour,

 Le 16/05/2014 13:09, Nicolas Dumoulin a écrit :

  Bonjour,

 J'essaie d'affiner la méthode pour importer les adresses. J'ai choisi
 d'utiliser
 les données associatedStreet_point_sur_batiment.
 Donc, je vérifie un par un (visuellement d'un seul coup pour une petite
 rue
 avec moins de 20 adresses) les points, et je m'attarde sur les nœuds qui
 n'ont
 pas trouvé de bâtiment à qui se rattacher. Et là, comment faire ? La
 réponse
 est en lançant cette recherche dans JOSM :
 addr:housenumber=* - child type:way


 J'utilise une variante :
 type:node  housenumber - child building

 mais on doit converger dans 99.99% des cas. Au moins :)

 vincent

 ps. BANO a passé hier soir le cap des 10.000.000 de points adresses (et
 couvre désormais le 63)


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

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

Re: [OSM-talk-fr] Projet BANO : bonne manière de taguer

[Pierre Knobel]

Le 18 mai 2014 09:34, Jean-Marc Liotier j...@liotier.org a écrit :

 Seuls les noeuds flottants, indépendant de toute feature semblent faire
 l'unanimité à leur encontre.


Il n'y a pas d'unanimité sur ce point non plus,  je crois.  Les partisans
de l'adresse sur la position de la boîte aux lettres ou de l'entrée de la
propriété privée en bord de parcelle ont de bons arguments également.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Trouver les noeuds non rapportés à un bâtiment avec JOSM

[Pierre Knobel]

Je n'ai pas d'avis tranché entre le point sur boîte aux lettre et point sur
façade près de l'entrée du bâtiment. Sur les communes que j'ai traité dans
les Bas-Rhin ces derniers mois j'ai choisi la façade pour rester consistant
avec les adresses déjà importées par les autres contributeurs sur la moitié
du département déjà complète. Quand je travaillais avec le plugin cadastre
sur fond de cadastre vectoriel ça me mettait mal à l'aise de faire comme ça
parce que souvent on ne peut pas deviner si on met le point sur une maison
et pas une grange ou un garage. Par défaut je mettait toujours le point sur
la façade la plus proche de la route dans une parcelle donnée.  Maintenant
qu'on a l'outil qiui digère le cadastre, je met l'imagerie en fond pour
mieux reconnaître les maisons et les entrées.

Si j'avais eu à choisir moi même j'aurais opté soit pour le tag sur
polygone de bâtiment (pas besoin de deviner  où est l'entrée) ou le point
flottant à 3m de la rue (pas d'interprétation nécessaire,  et quelqu'un
avec la connaissance du terrain aurait plus facilement pu déplacer le point
sur une façade plus tard).
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] BANO... premiers pas...

[Pierre Knobel]

Sur les communes sans cadastre vectoriel on ne voit aucune adresse sur le
rendu, même pas des adresses d'OSM. Par exemple Reutenbourg possède :
- aucune adresse sur le rendu BANO :
http://layers.openstreetmap.fr/?zoom=14lat=48.68964lon=7.41933layers=00B00FFT
- plus de 80% des adresses d'apres le rendu de Denis :
http://listes.openstreetmap.fr/wws/d_read/local-alsace/cartes/tx_couv_adresses_20140503.pdf

A côté on a un village avec 166% d'adresses, peut-être que les adresses ont
été comptées dans le mauvais village ? Est-ce que c'est possible de
vérifier qu'elles ont bien été collectées dans BANO ?

L'autre question que je me pose c'est comment le bâti et les adresses  ont
été importé si on n'a pas le cadastre ? Est-ce que c'est possible que le
cadastre vectoriel disparaisse temporairement pendant une mise à jour et
réapparaisse plus tard ?


2014-05-13 16:04 GMT+00:00 Christian Quest cqu...@openstreetmap.fr:

 Pour intégrer des adresses, BANO ne fera pas mieux que les extractions
 déjà disponibles sur http://cadastre.openstreetmap.fr/

 BANO sert avant toute autre chose à proposer un jeu complet, composite
 pour des usages hors OSM et s'enrichira de toutes les améliorations
 apportées dans OSM.


 Le 13 mai 2014 17:18, Steve Grosbois steve.grosb...@gmail.com a écrit :

 Le 13 mai 2014 16:42, Christian Quest cqu...@openstreetmap.fr a écrit :

 J'ai aussi utilisé la couche BANO dans JOSM pour compléter, c'est
 vraiment super pratique !


 J'ai eu la même idée, et oui : super pratique !!
 Merci pour ce boulot !!!



 Je vais voir pour utiliser non pas uniquement le rouge, mais plusieurs
 couleurs pour différencier les rues et adresses correspondant pour que ça
 soit plus lisible sur des coin où aucune rue n'est nommée. Bien sûr ça ne
 serait que sur les plus forts zoom, pour mapper.

 Voici une copie d'écran de mon JOSM: http://cl.ly/image/0T1C2l0O133h

 J'ai un filtre qui ne me montre que les highway=* sans name=*



 Le 13 mai 2014 16:35, Pierre Knobel pierr...@gmail.com a écrit :

 Super.  J'ai commencé à corriger des noms de rues dans OSM pour dégommer
 le rouge autant que possible dans les coins que je connais bien.

 Une question à propos du tableau : est ce que le chiffre dans la
 colonne cadastre correspond à  toutes les adresses dans le cadastre ou
 seulement celle qui n'ont pas encore été identifiées dans OSM ?
 Le 13 mai 2014 04:51, Christian Quest cqu...@openstreetmap.fr a
 écrit :

  Voici un tableau pour avoir un aperçu du contenu de BANO (en live) :

 https://openstreetmap.fr/outils/bano/status

 J'ai aussi modifié le rendu pour indiquer le code FANTOIR des voies
 sur lesquelles on n'a pas pu faire de rapprochement avec OSM.
 Ceci permet d'indiquer le ref:FR:FANTOIR plus facilement dans OSM et
 permettre le rapprochement à la prochaine itération de BANO.

 --
 Christian Quest - OpenStreetMap France

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


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




 --
 Christian Quest - OpenStreetMap France

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



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




 --
 Christian Quest - OpenStreetMap France

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


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

Re: [OSM-talk-fr] BANO... premiers pas...

[Pierre Knobel]

OK, je vois les adresses en vert maintenant.


2014-05-16 21:19 GMT+00:00 Vincent de Château-Thierry v...@laposte.net:


 Le 16/05/2014 23:12, Pierre Knobel a écrit :

  Sur les communes sans cadastre vectoriel on ne voit aucune adresse sur
 le rendu, même pas des adresses d'OSM. Par exemple Reutenbourg possède :
 - aucune adresse sur le rendu BANO :
 http://layers.openstreetmap.fr/?zoom=14lat=48.68964lon=7.41933layers=
 00B00FFT


 Peut-être un souci de cache chez toi car avec ton lien je vois plein de
 points verts sur Reutenbourg à l'instant.


  - plus de 80% des adresses d'apres le rendu de Denis :
 http://listes.openstreetmap.fr/wws/d_read/local-alsace/
 cartes/tx_couv_adresses_20140503.pdf

 A côté on a un village avec 166% d'adresses, peut-être que les adresses
 ont été comptées dans le mauvais village ? Est-ce que c'est possible de
 vérifier qu'elles ont bien été collectées dans BANO ?


 Les adresses sur Westouse-M dans OSM couvrent au sud-ouest un lotissement
 qui n'est peut-être pas à jour dans le cadastre ? Je vois du vert et pas de
 bleu.


  L'autre question que je me pose c'est comment le bâti et les adresses
 ont été importé si on n'a pas le cadastre ? Est-ce que c'est possible
 que le cadastre vectoriel disparaisse temporairement pendant une mise à
 jour et réapparaisse plus tard ?


 Bonne question. Cas fréquent lors du passage du raster au vecteur, mais
 pour des communes déjà vectorielles je n'ai pas l'expérience.

 vincent


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

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

Re: [OSM-talk-fr] Trouver les noeuds non rapportés à un bâtiment avec JOSM

[Pierre Knobel]

Le soucis c'est qu'il y a beaucoup de rouge qui provient de
différences entre le terrain et FANTOIR ou le cadastre, donc ce n'est
pas forcément possible de corriger sans connaissance du terrain non
plus. Il faudrait commencer par faire une liste des problèmes
classiques et des recommandations sur la manière de les corriger.

Des exemples erreurs que je vois le plus souvent sont :
- ambitguité entre Rue de ..., Route de ..., Chemin de ...
- Rue Diderot vs. Rue Denis Diderot
- Rue du Bosquet vs. Rue des Bosquets
- Rue Albert Schweitzer vs. Rue du Docteur Schweitzer
- Rue de la Gare (confirmé sur terrain) vs. Rue de l'Ancienne Gare

Est-ce qu'on doit standardiser ces cas de figure dans OSM  ou plutôt
considérer que les différentes formes sont acceptables et simplement
faire le rapprochement avec le ref:fantoir ?

Je ne voudrais pas modifier des noms de rues dans OSM en me basant sur
une référence pas toujours juste en risquant de détruire le travail
d'un contributeur qui connaissait le terrain.



On 5/16/14, Christian Quest cqu...@openstreetmap.fr wrote:

 Donc, dans l'immédiat, il me semble surtout opportun de remplacer non pas
 du rouge par du vert (import dans OSM), mais par du bleu (compléter OSM sur
 la voirie pour permettre les rapprochements automatiques).


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

Re: [OSM-talk-fr] Un MOOC OSM ?

[Pierre Knobel]

C'est poossible de géolocaliser un tweet, mais je ne crois pas qu'il y
ait une option pour filtrer les tweets de cette manière pour les
suiveurs.

www.autour.com est un réseau social à la twitter qui pourrait aussi
être utilisé pour ce genre de passerelle avec les notes, vu qu'il est
basé sur un fond de carte OSM. Dommage qu'en s'inscrivant le premier
truc qu'on voit sont des listes interminables de petites annonces et
de pubs, c'est pas idéal pour attirer de nouveaux utilisateurs. Ou
alors j'ai mal compris et c'est avant tout un site de petites annonces
géolocalisées ?

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

Re: [OSM-talk-fr] BANO... premiers pas...

[Pierre Knobel]

Super.  J'ai commencé à corriger des noms de rues dans OSM pour dégommer le
rouge autant que possible dans les coins que je connais bien.

Une question à propos du tableau : est ce que le chiffre dans la colonne
cadastre correspond à  toutes les adresses dans le cadastre ou seulement
celle qui n'ont pas encore été identifiées dans OSM ?
Le 13 mai 2014 04:51, Christian Quest cqu...@openstreetmap.fr a écrit :

 Voici un tableau pour avoir un aperçu du contenu de BANO (en live) :

 https://openstreetmap.fr/outils/bano/status

 J'ai aussi modifié le rendu pour indiquer le code FANTOIR des voies sur
 lesquelles on n'a pas pu faire de rapprochement avec OSM.
 Ceci permet d'indiquer le ref:FR:FANTOIR plus facilement dans OSM et
 permettre le rapprochement à la prochaine itération de BANO.

 --
 Christian Quest - OpenStreetMap France

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


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

Re: [OSM-talk-fr] Adresses : Problème des noms de rue identiques dans des communes associées

[Pierre Knobel]

OK pour utiliser addr:place pour les communes associée, si personne n'y
vois d'objection. Je vais commencer la traduction de
http://wiki.openstreetmap.org/wiki/Key:addr:place et à rajouter l'info sur
les relations AssociatedStreet.


2014-05-12 9:46 GMT+00:00 Pieren pier...@gmail.com:

 2014-05-12 11:26 GMT+02:00 Christian Quest cqu...@openstreetmap.fr:

  J'éviterai de retirer les tags existant (pour ne pas impacter leurs
  ré-utilisateurs),

 A terme, les réutilisateurs devront supporter les deux modèles. Je
 n'aime pas les redondances. Mais on peut les conserver dans la base
 sur une période transitoire (les allemands n'ont pas encore fait de
 nettoyage d'ailleurs).

 Pieren

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

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

Re: [OSM-talk-fr] Tag lotissement

[Pierre Knobel]

Est-ce que tu avais bien mis l'attribut landuse=residential sur la
relation multipolygon et pas sur le polygon outer ?



 Le 12 mai 2014 11:40, Pieren  pier...@gmail.com  a écrit :


 2014-05-12 11:13 GMT+02:00 Mides  mides@gmail.com :

  J'ai loupé quelque chose ?


 Oui. A priori, tu as dû foirer quelque part dans le multipolygon.
 Comme dit Christophe, il faudrait un lien vers les données si tu veux
 qu'on étudie les détails.

 Pieren

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


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

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

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

Re: [OSM-talk-fr] Adresses : Problème des noms de rue identiques dans des communes associées

[Pierre Knobel]

Quelques modifications sur le wiki :
- http://wiki.openstreetmap.org/wiki/FR:Key:addr:place (Il y a une
contradiction avec la page anglaise qui dit qu'on ne peut pas mélanger
addr:street et addr:place, mais je crois que la page anglaise se
contredit elle-même)
- 
http://wiki.openstreetmap.org/w/index.php?title=Template%3AFR%3AMap_Features%3Aaddrdiff=1037529oldid=944754

Je trouve que addr:place et addr:hamlet font un peu doublon.

Est-ce qu'il faut en discuter sur la liste tagging ?


On 5/12/14, Pierre Knobel pierr...@gmail.com wrote:
 OK pour utiliser addr:place pour les communes associée, si personne n'y
 vois d'objection. Je vais commencer la traduction de
 http://wiki.openstreetmap.org/wiki/Key:addr:place et à rajouter l'info sur
 les relations AssociatedStreet.


 2014-05-12 9:46 GMT+00:00 Pieren pier...@gmail.com:

 2014-05-12 11:26 GMT+02:00 Christian Quest cqu...@openstreetmap.fr:

  J'éviterai de retirer les tags existant (pour ne pas impacter leurs
  ré-utilisateurs),

 A terme, les réutilisateurs devront supporter les deux modèles. Je
 n'aime pas les redondances. Mais on peut les conserver dans la base
 sur une période transitoire (les allemands n'ont pas encore fait de
 nettoyage d'ailleurs).

 Pieren

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



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

Re: [OSM-talk-fr] Tag lotissement

[Pierre Knobel]

Je viens de regarder sur le wiki
(http://wiki.openstreetmap.org/wiki/FR:Relation:multipolygon) et
effectivement c'est confus concernant où placer les tags.
Sur une ligne on dit :
   - Les étiquettes qui décrivent les polygones multiples (exemple:
landuse=forest) doivent s'appliquer à la relation. Les chemins du
contour externes ne doivent pas être étiquetés, à moins qu'ils
décrivent un élément de manière indépendante. Par exemple, une forêt
peut être délimitée par quatre routes qui seront étiquetées en highway
mais qui pourront être utilisées comme membres externes de la relation
forêt.

Sur la ligne suivante :
   - Si vous avez un chemin fermé qui forme le contour extérieur et
qu'il ne décrit rien à lui seul, vous pouvez également ajouter ces
étiquettes à ce contour et laisser la relation non étiquetée. si vous
avez plus d'un chemin externe (voir plus bas), alors, ça n'a plus de
sens. Il est alors suggéré de toujours étiqueter sur la relation.

De mon point de vue la deuxième solution est fausse, tous les tags
relatif à des surfaces placés sur un chemin fermé / polygone devraient
concerner tout ce qui est à l'intérieur du polygone, et tous ceux
placés sur la relation doivent concerner le multipolygone (donc pas
les surfaces délimitées par des membres inner).  Sinon c'est ambigu.

Dans le cas du polygone intérieur, pas de soucis pour placer des tags
directement sur le polygone (sauf cas tordu de mutlipolygon dans un
multipolygon).

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

Re: [OSM-talk-fr] BANO... premiers pas...

[Pierre Knobel]

Je vois quelques problèmes d'encodage sur les caractères accentués du
rendu BANO, les 'é' et les 'ê' sont remplacés pas des losanges.

http://layers.openstreetmap.fr/?zoom=18lat=49.03166lon=7.96925layers=00B00FFT

On 5/11/14, Christian Quest cqu...@openstreetmap.fr wrote:
 Le 10 mai 2014 22:40, Paul Mallet cont...@paulmallet.net a écrit :

 Hello,

 Si j'ai bien compris les adresses déjà intégrées dans OSM sont
 prioritaires sur celles du cadastre.


 Elles le seront dans la BANO en cas de doublon (ou triplon avec
 l'opendata).
 Elles le sont aussi d'une certaine façon dans ce rendu (vert par dessus
 bleu et rouge lorsqu'il y a doublon).



 Du coup je ne comprends pas trop pourquoi aucune des adresses de
 Boulogne-Billancourt (92) et beaucoup des adresses de Paris ne sont pas
 prises en compte (du coup il y a doublon avec celles venant de l'import
 cadastral, est ce un problème du script d'import ou manque t-il des infos
 dans OSM pour faire la liaison ?


 Il manque le traitement des adresses OSM mises sur les polygones des
 bâtiments. C'est dans le tuyau...



 De même quoi faire quand les noms de rues du cadastre ne correspondent
 pas
 au terrain (et a OSM), et que du coup les adresses ressortent en rouge ?


 Comme dans toutes les comparaisons avec des jeux de données... le terrain
 prime.
 Ce n'est pas parce que l'INSEE indique qu'il y a des habitants dans tel
 carré, qu'on va y ajouter des bâtiments.
 Pour les orthographes différentes de nom, on peut utiliser alt_name,
 official_name et affiner les scripts de rapprochement pour qu'ils les
 exploitent en plus du seul name=*



 En tout cas bravo pour le taf, c'est très prometteur !



 C'est en chantier et on a préféré ouvrir le chantier au public dans
 l'esprit du release early, release often.
 Ca permet aussi les remontées rapides pour améliorer dès les fondations et
 pas une fois qu'on en est à la peinture.

 --
 Christian Quest - OpenStreetMap France


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

[OSM-talk-fr] Adresses : Problème des noms de rue identiques dans des communes associées

[Pierre Knobel]

Bonjour,

Le consensus actuel pour les adresses semble être de ne pas rajouter de tag
addr:city sur les relations AssociatedStreet parce qu'on peut déduire
l'info de la commune à partir des limites administratives. Mais ça pose des
problèmes dans les communes fusionnées / associées qui partagent sont
englobés dans une limite administrative unique mais qui peuvent avoir des
noms de rues en doublon.

Voir : http://fr.wikipedia.org/wiki/Commune_associ%C3%A9e#Remarque

Je n'aime pas la solution du cadastre qui est de rajouter le nom de
l'ancienne commune à la suite du nom de rue. Par exemple la Rue
Principale à Bremmelbach (commune de Cleebourg) ne devrait pas à mon avis
s'appeler la Rue Principale Bremmelbach :
http://layers.openstreetmap.fr/?zoom=17lat=48.98551lon=7.90047layers=00B00FFT


Sur une adresse postale, l'information du nom de l'ancien village viendrait
sur une ligne séparée :
Hans Schmitt
6 Rue Principale
Bremmelbach
67160 Cleebourg

Donc de mon point de vue l'info Bremmelbach devrait exister dans OSM ou
BANO dans un tag séparé du tag name / addr:street. Des idées ?
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] BANO... premiers pas...

[Pierre Knobel]

Bonjour,

C'est très prometteur, j'ai hâte de voir ce que ça donne sur les Bas-Rhin
et l'Isère.
Est-ce qu'on a une idée de combien de temps l'extraction du cadastre va
prendre pour toute la France ?



2014-05-10 10:52 GMT+00:00 Vincent de Château-Thierry v...@laposte.net:

 Bonjour,

 Le 10/05/2014 10:57, didier2020 a écrit :

  c'est bizarre cette carte, je croyais le val de marne + rouge ...


 :)


  plus serieusement, la legende des couleurs c'est 


 bleu : adresses issues du cadastre en direct
 vert : adresses extraites d'OSM
 bien garder à l'esprit que c'est un work in progress, hein...

 vincent


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

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

Re: [OSM-talk-fr] BANO... premiers pas...

[Pierre Knobel]

Pas d'import automatique si j'ai bien compris, juste la création d'une base
de données d'adresses externe à OSM. Cette base utilise OSM en priorité
comme source, mais quand l'adresse n'existe pas dans OSM on prend celle du
cadastre. Sinon, l'adresse extraite du cadastre doit juste servir pour le
contrôle qualité des adresses dans OSM.

L'outil d'extraction des adresses utilise les batiments déjà importé dans
OSM pour positionner les noeuds d'adresse sur une façade, donc il faut
continuer à importer le cadastre semi-manuellement dans OSM.

Corrigez moi si je me trompe.


2014-05-10 12:50 GMT+00:00 nono pingven...@free.fr:

 Salut

 Le samedi 10 mai 2014 à 14:20 +0200, Christian Quest a écrit :
  On va y aller calmement... plutôt le soir et week-end histoire de ne
  pas faire surchauffer les serveurs de Bercy lorsqu'ils sont les plus
  sollicités.
 
 
  L'Alsace est en cours d'extraction... on met la priorité sur les
  régions les plus complètes en bâti/voirie, histoire d'avoir un maximum
  de rapprochements avec les données OSM, d'où le choix
  Nord-Pas-de-Calais, Alsace, Pays-de-la-Loire...

 Je lis ce fil mais n'y comprends pas grand chose, donc je me pose des
 questions ;-)

 Vous semblez tester un import automatique du cadastre.

 Donc faut-il que je continue à importer les bâtis du cadastre des
 patelins de mon coin et les mettre à jour manuellement ?

 Dans le cas d'un import automatique comme le vôtre, que fait-il
 exactement ?
 Supprime-t-il les build déjà présents dans osm pour y mettre les siens ?

 En bref, en tant que contributeur, faut-il continuer à consacrer du
 temps individuel sur l'import cadastral ?

 nono




 --
 Chuck Norris est au courant de l'existence des extraterrestres. Du moins
 les races qu'il a exterminées.

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


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

Re: [OSM-talk-fr] Tag lotissement

[Pierre Knobel]

Salut,

JOSM te prévient juste que tu fais un trou dans une zone pour la remplir
avec une zone du même type. Si tu penses que les deux zones doivent être
distinctes à cause d'un attribut différent- dans ton cas le name=*- il faut
que tu ignore l'avertissement.

Je m'étais posé la même question en travaillant sur des forêts
principalement feuillues qui avaient des trous pour les morceaux de forêt
couverts de conifères.
Le 10 mai 2014 12:57, Mides mides@gmail.com a écrit :

 Bonsoir,

 j'en reviens sur mon affaire. :-)

 Je suis face à l'intégration d'un lotissement,  mais dont la zone se
 trouve, cette fois,  dans un autre landuse:résidential qui est le principal
 englobant la ville.

 J'ai bien une relation de type multypolygone, avec outer pour le polygone
 extérieur et inner pour celui concernant le lotissement, seulement, voilà,
 j'ai un problème !!!

 Le message Josm est  : Le style du chemin intérieur est égal à
 multipolygon(1), ce qui peut paraître logique dans la mesure où j'ai deux
 landuse:residential.

 Comment puis je m'y prendre ?

 Michel


 Le 5 mai 2014 08:11, Pierre-Alain Dorange pdora...@mac.com a écrit :

 Mides mides@gmail.com wrote:

  En gros, et pour résumer, est il judicieux de déclarer une emprise sur
 le
  terrain ou pas ?  Tu me diras, on pratique de la sorte pour un
  landuse:retail, qui se trouve parfois au milieu d'une zone
  landuse:residential et donc en surcouche.

 Perso je pratique pas ce type de surcouche.
 Pour moi un terrain n'a qu'un seul usage (landuse) donc pas de
 surcouche.
 Si une zone est englobé par une autre, je perce (multipolygone, outer,
 inner) la plus grande pour ensuite placer celle incluse. Ainsi une zone
 n'a qu'un seul usage (landuse).

 Bien sur comme indiqué par le wiki, on ne crée une zone (landuse) que si
 cela est signaificatif. Un seul magasin ne justifie pas la création d'un
 landuse, il faut une taille conséquente (plusieurs, je sais c'est mal
 définit).



 --
 Pierre-Alain Dorange
 OSM experiences : http://www.leretourdelautruche.com/map/


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



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


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

Re: [OSM-talk-fr] Un MOOC OSM ?

[Pierre Knobel]

Je suis très intéressé, mais je ne pourrais pas suivre le MOOC de l'ENS
(connection internet bas débit).

Ca fait longtemps que je dis que je vais rédiger des tutoriaux à
destination de débutants complets pour la cartographie intégrale d'un
village, mais je procrastine.


2014-05-04 21:06 GMT+00:00 Christian Quest cqu...@openstreetmap.fr:

 Qui serait intéressé pour créer (collaborativement) un MOOC* ?

 Voici un MOOC proposé par l'ENS Cachan sur la création de MOOC... et ça
 démarre le 11 mai.


 https://www.france-universite-numerique-mooc.fr/courses/ENSCachan/20002/Trimestre_2_2014/about

 * Massive Open Online Courses
 --
 Christian Quest - OpenStreetMap France

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


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

[OSM-talk-fr] Rapport nombre de bâtiments par adresse, pour contrôle qualité

[Pierre Knobel]

Bonjour,

En même temps que je rajoute les adresses j'en profite pour fusionner les
bâtiments les plus fragmentés, et je me dit que ça pourrait faire un bon
outil de contrôle qualité d'avoir une couche de polygônes de communes
coloriés par leur rapport nombre de bâtiments sur nombre de tags
addr:housenumber pour toute la France.

Je ne m'attend pas à ce que ce soit un indicateur rigoureux, mais ça
permettrait d'avoir un rapide aperçu de l'état d'avancement du projet
adresses à intervalle régulier. Et pour les zones dont on sait que les
adresses ont été importées, on pourrait utiliser ça comme indicateur de
fragmentation des bâtiments.

Je m'attend à ce que le rapport soit proche de 2:1 pour les zones bien
cartographiées. Entre 2:1 et 1:1 je verrais bien un dégradé du vert clair
au vert foncé. De 2:1 à l'infini il faudrait un dégradé du vert au rouge.
En dessous de 1:1, quand on a plus de noeuds d'adresses que de bâtiments,
je mettrais une couleur à part, par exemple le jaune.

Qu'est-ce que vous en pensez ? Est-ce que ça vous semble utile ? Est-ce que
c'est compliqué à mettre en place ? J'imagine que ça fait un gros volume de
données à traiter et à maintenir à jour.


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

[OSM-talk-fr] Recherche et visualisation de groupes de modifications récents

[Pierre Knobel]

Bonjour,

Je ne sais pas si c'est déjà passé sur la liste, il y a un nouvel outil
pour afficher les groupes de modifications des 7 derniers jours en faisant
une recherche sur les commentaires :
http://neis-one.org/2014/02/osm-changesets/

Par exemple pour voir les groupes de modifications comprenant le morceau de
mot adresse (ça inclue les *adresse*s et *Adresse*n) :
http://resultmaps.neis-one.org/osm-changesets?comment=adresses#6/43.525/12.096

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

Re: [OSM-talk-fr] Revert et contact à prendre

[Pierre Knobel]

Je corrige et je tente de prendre contact.

2014-04-15 9:50 GMT+02:00 JB jb...@mailoo.org:
 Bonjour,
 Si quelqu'un à le courage :
 https://www.openstreetmap.org/changeset/21687571
 J'ai déjà fait mon contact personnel ce matin…
 JB.

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

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

Re: [OSM-talk-fr] Revert et contact à prendre

[Pierre Knobel]

En fait je ne vais pas corriger, c'est au-dessus de mon niveau (17
groupres de modifications, conflits, relations frontières
affectées... etc). Mais je vais le contacter pour lui demander quel
était le but de la manoeuvre.

2014-04-15 11:49 GMT+02:00 Pierre Knobel pierr...@gmail.com:
 Je corrige et je tente de prendre contact.

 2014-04-15 9:50 GMT+02:00 JB jb...@mailoo.org:
 Bonjour,
 Si quelqu'un à le courage :
 https://www.openstreetmap.org/changeset/21687571
 J'ai déjà fait mon contact personnel ce matin…
 JB.

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

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

[OSM-talk-fr] Fwd: [OpenStreetMap] Re: modifications incompréhensibles Pontcharra

[Pierre Knobel]

Je leur glisserait un mot à propos de umap ce soir.
-- Message transféré --
De : Amicale m-425288-5c5...@messages.openstreetmap.org
Date : 15 avr. 2014 14:51
Objet : [OpenStreetMap] Re: modifications incompréhensibles Pontcharra
À : knobel.pie...@gmail.com
Cc :

Bonjour PiRK,

Amicale http://www.openstreetmap.org/user/Amicale vous a envoyé un
message depuis OpenStreetMap avec le sujet Re: modifications
incompréhensibles Pontcharra :
==

Bonjour,

Désole du desagrement, ce n'etait pas le but rechercher! Les plans ont ete
modifié car nous sommes une amicale de sapeurs pompiers et dans le cadre de
notre tournee de calendrier nous utilisons votre site afin de faciliter nos
secteurs de distribution, c'est pour cela que nous modifions les cartes
mais nous ne savions pas que cela avait une incidence sur le site.

Nous feront maintenant differement.

Restant a votre disposition.

Cordialement.

Le 15 avril 2014 12:02, PiRK m-425233-b6b...@messages.openstreetmap.org a
écrit :

 Bonjour Amicale,

 PiRK http://www.openstreetmap.org/user/PiRK vous a envoyé un message
 depuis OpenStreetMap avec le sujet modifications incompréhensibles
 Pontcharra :
 ==

 Bonjour,

 Vous avez effectué 17 modifications ces vingt derniers jours du côté de
 Pontcharra. Je ne comprend pas le but de ces modifications, vous avez
 ajouté des ponts un peu partout sur de longues routes et changé le type
de
 routes de rues résidentielles à entrée/sortie de voie rapide.

 Vos modifications seront probablement annulées très prochainement par un
 administrateur ou un contributeur expérimenté, car elles ont été
signalées
 sur la liste de discussion francophone du projet OpenStreetMap.

 Si vous cherchez de l'aide, je suis à votre disposition. Si vous
 m'expliquez quel était le but de vos modifications, je peux essayer de
vous
 expliquer comment procéder.

 Cordialement, Pierre
 ==

 Vous pouvez aussi lire le message à
 http://www.openstreetmap.org/message/read/425233 et vous pouvez y
 répondre à http://www.openstreetmap.org/message/reply/425233

==

Vous pouvez aussi lire le message à
http://www.openstreetmap.org/message/read/425288 et vous pouvez y répondre
à http://www.openstreetmap.org/message/reply/425288
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Problème de décalage du cadastre vs GPS sur une commune

[Pierre Knobel]

Bonsoir,

J'ai un soucis avec le cadastre sur le Hameau de Wengelsbach (commune
de Niedersteinbach) : http://osm.org/go/0DN6pIou?layers=C

Le premier problème est que le cadastre semble décalé par rapport aux
traces GPS. Je compte y faire un tour pour enregistrer quelques
nouvelles traces avec un récepteur GPS auquel je fais confiance pour
confirmer que ce n'est pas juste des traces GPS de mauvaise qualité.

Le deuxième problème est que les positions des maisons sur le cadastre
actuel ne correspond pas aux positions des maisons importés. Ce n'est
pas juste un problème de décalage linéaire, car quand je sélectionne
tous les bâtiments et que je les déplace ensemble  je n'arrive pas à
trouver un décalage qui leur convienne à tous. Je ne sais pas si c'est
dû à une mise à jour du cadastre, ou si lors de l'import initial les
bâtiments ont été corrigés un par un en se basant sur l'imagerie
aérienne (peut-être mal orthorectifiée, vu que je n'arrive pas à la
faire coller proprement aux traces GPS non plus).

Au final c'est un gros casse tête pour essayer de placer les bâtiments
proprement en respectant la position des rues basée sur les traces
GPS. J'ai laissé tomber pour le moment, mais ça m'embête parce qu'il
faudrait que la positions des maisons soit correcte avant que je
puisse importer les adresses.

Est-ce que quelqu'un a déjà eu à gérer un problème similaire ? Des conseils ?

Pierre

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

Re: [OSM-talk-fr] Problème de décalage du cadastre vs GPS sur une commune

[Pierre Knobel]

Merci pour les conseils. Ça m'étonne parce que c'est la première fois
que je vois ce genre de soucis après avoir traité une petite centaines
de communes sans problèmes. On doit avoir du bol avec notre cadastre.

On fait comment pour charger les sections séparément ?

Je ferais un tour sur place à mon prochain passage dans la région pour
relever tous les chemins, les routes et quelques points d'intérêt au
GPS, ça devrait suffire pour déterminer tous les décalages et corriger
en conséquence.

2014-04-10 22:15 GMT+02:00 DH dhel...@free.fr:
 Le 10/04/2014 21:09, Pierre Knobel a écrit :

 Bonsoir,

 J'ai un soucis avec le cadastre sur le Hameau de Wengelsbach (commune
 de Niedersteinbach) : http://osm.org/go/0DN6pIou?layers=C

 Le premier problème est que le cadastre semble décalé par rapport aux
 traces GPS. Je compte y faire un tour pour enregistrer quelques
 nouvelles traces avec un récepteur GPS auquel je fais confiance pour
 confirmer que ce n'est pas juste des traces GPS de mauvaise qualité.

 Le deuxième problème est que les positions des maisons sur le cadastre
 actuel ne correspond pas aux positions des maisons importés. Ce n'est
 pas juste un problème de décalage linéaire, car quand je sélectionne
 tous les bâtiments et que je les déplace ensemble  je n'arrive pas à
 trouver un décalage qui leur convienne à tous. Je ne sais pas si c'est
 dû à une mise à jour du cadastre, ou si lors de l'import initial les
 bâtiments ont été corrigés un par un en se basant sur l'imagerie
 aérienne (peut-être mal orthorectifiée, vu que je n'arrive pas à la
 faire coller proprement aux traces GPS non plus).

 Au final c'est un gros casse tête pour essayer de placer les bâtiments
 proprement en respectant la position des rues basée sur les traces
 GPS. J'ai laissé tomber pour le moment, mais ça m'embête parce qu'il
 faudrait que la positions des maisons soit correcte avant que je
 puisse importer les adresses.

 Est-ce que quelqu'un a déjà eu à gérer un problème similaire ? Des
 conseils ?

 Pierre


 Trace et enregistre sur un calque séparé les 13 sections de la commune et tu
 découvriras probablement les sections qui posent problèmes (dont Wengelsbach
 probablement). La feuille cadastrale est l'unité de travail ; les raccords
 entre feuilles ne sont redressés que dans des marges normées dans les
 cahiers des charges de digitalisation (comme aux limites communales). A
 Niedersteinbach, on est quand même en bordure des Vosges du Nord (effet
 relief soudain en bordure de feuille même si c'est pas les Alpes ;-). Le
 fait que le cadastre soit vectorisé indique juste que les erreurs du plan
 cadastral papier ont été numérisées.
 Bravo pour ton travail sur l'Alsace du Nord et n'hésites pas à me solliciter
 en cas de besoin sur la liste locale.

 Denis
 PS : le tracé de la Réserve Naturelle Régionale de Wegscheid (fin fond du
 Haut-Rhin côté massif vosgien) m'avait coûté des heures en raison de
 sections cadastrales complètement nazes. Je compatis donc


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

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

Re: [OSM-talk-fr] Service de pré-intégration d'adresses

[Pierre Knobel]

J'ai une question à propos de l'outil : j'ai trouvé une commune qui a
un mélange de numérotation normale et de numérotation métrique :
Wintzenbach. L'outil me donne une rue Schongauer avec un numéro, mais
quand je regarde sur le cadastre que j'ai dans JOSM je ne trouve pas
cette rue. En vérifiant sur Google Maps, je trouve bien la rue à
l'endroit où l'outil m'a placé le numéro. Du coup je m'interroge :
est-ce que l'outil utilise bien la même source du cadastre que le
plugin JOSM ? Est-ce que c'est possible que certaines infos dans le
fichier PDF du cadastre soient présentes mais ne soient pas visible
dans JOSM ? Ca expliquerait peut-être beaucoup de problèmes de numéros
manquants sur des portions de rues.

Une autre question à propos de JOSM : est-ce qu'il y a un moyen de
changer le style d'affichage de certaines infos ? J'aimerais beaucoup
agrandir et changer la couleur des numéros d'adresse, en l'état ils
sont illisibles et obligent à cliquer sur le noeud pour lire la valeur.

Encore merci pour l'outil.
Pierre

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

Re: [OSM-talk-fr] Service de pré-intégration d'adresses

[Pierre Knobel]

OK, merci pour l'explication. Ça explique quelques noms de rues
difficiles à déchiffrer, mais c'est peu probable que ça ait un rapport
avec mes problèmes de numéros systématiquement manquants pour tout un
côté d'une longue rue.

2014-04-07 17:00 GMT+02:00 V de Chateau-Thierry v...@laposte.net:

 De : Pierre Knobel

 J'ai une question à propos de l'outil : j'ai trouvé une commune qui a
 un mélange de numérotation normale et de numérotation métrique :
 Wintzenbach. L'outil me donne une rue Schongauer avec un numéro, mais
 quand je regarde sur le cadastre que j'ai dans JOSM je ne trouve pas
 cette rue. En vérifiant sur Google Maps, je trouve bien la rue à
 l'endroit où l'outil m'a placé le numéro. Du coup je m'interroge :
 est-ce que l'outil utilise bien la même source du cadastre que le
 plugin JOSM ? Est-ce que c'est possible que certaines infos dans le
 fichier PDF du cadastre soient présentes mais ne soient pas visible
 dans JOSM ? Ca expliquerait peut-être beaucoup de problèmes de numéros
 manquants sur des portions de rues.

 Oui la source est la même, en revanche la stratégie requise par le plugin, à 
 savoir
 appeler par tuiles de taille fixe, induit un biais d'affichage. C'est un 
 constat fréquent
 sur les noms de rue, qui plus est s'ils sont longs : ne sont affichés dans 
 JOSM que les
 caractères du nom inclus dans la tuile où figure le premier mot, qui a le 
 point
 d'accroche du texte avec lui. Pour les portions du texte situées sur d'autres 
 pavés, le
 point d'accroche n'étant pas dans le même pavé, le texte n'est pas affiché. 
 Il manque
 la logique de meta-tuiles de Mapnik ici :(
 Dans ces cas-là, pour vérifier qu'un nom, invisible dans JOSM, existe bien au 
 cadastre,
 il faut se replier sur un affichage directement sur 
 http://www.cadastre.gouv.fr/ car
 l'affichage carto n'y rencontre pas le même biais.

 vincent

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

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

Re: [OSM-talk-fr] Service de pré-intégration d'adresses

[Pierre Knobel]

 Une autre question à propos de JOSM : est-ce qu'il y a un moyen de
 changer le style d'affichage de certaines infos ? J'aimerais beaucoup
 agrandir et changer la couleur des numéros d'adresse, en l'état ils
 sont illisibles et obligent à cliquer sur le noeud pour lire la valeur.


Je me répond à moi-même pour cette question, peut-être que ça pourra
servir à d'autres : c'est dans Affichage  Coloriage  Préférences. Là
il faut rajouter le modèle Coloured Streets qui affiche les adresses
de manière lisible, puis valider. Après on peut sélectionner ou
désélectionner le modèle directement depuis le menu affichage.

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

Re: [OSM-talk-fr] Service de pré-intégration d'adresses

[Pierre Knobel]

Bonjour,

Je viens de tester l'outil après avoir suivi la présentation sotm-fr en
streaming.

Vu le nombre impressionnant de paramètres à prendre en compte pour le
positionnement de l'adresse sur une façade, je suis impressionné par la
fiabilité. Cela dit, je trouve que dans la plupart des cas que c'est
toujours un peu plus long de vérifier visuellement les adresses, puis de
corriger les 5% d'erreur, puis de fusionner les données que de positionner
les adresses d'un clic avec le plugin cadastre-fr. Peut-être que c'est
juste un problème de ma part, j'utilise intensivement le plugin cadastre-fr
depuis plusieurs mois et donc j'ai appris à optimiser tous mes clics,
peut-être que je m'en sortirais mieux après avoir utilisé cet outil pendant
un bout de temps. J'ai fait mon test sur une petite commune avec de
nombreuses rues courtes, peut-être que la situation serait différente si la
longueur des rues était plus importante (meilleur ratio nombre d'adresse
sur opération de fusion de calques).
Le cas où l'utilisation de cet outil serait clairement plus efficace que de
cliquer sur chaque adresse est celui des numérotations pas incrémentales,
quand le numéro de la maison correspond à la distance métrique depuis le
début de la rue.

Un petit problème qu'il faudrait probablement corriger c'est la présence
d'espace dans le cas des numéros préfixés d'une lettre (25 A, 36 B...etc).
En Alsace je crois qu'on ne met pas d'espace.

Pourquoi ne pas faire tourner automatiquement l'outil sur toute la France
pour générer une base de donnée libre temporaire - en-dehors de la base OSM
officielle - en attendant qu'une saisie manuelle plus précise soit dispo ?
Ca pourrait servir de base à d'autres outils d'aide à l'import, ou a des
outils de contrôle qualité.

En tout cas, bravo pour le boulot.

Pierre


2014-03-13 1:21 GMT+01:00 Tyndare tynd...@wanadoo.fr:


 Tout à fait. Normalement c'est corrigé.

 Le 13 mars 2014 00:37, Yoann Cornec yoanncor...@gmail.com a écrit :

 Après quelques tests ici et là, j'observe l'erreur suivante :
 Les fichiers *addrstreet_point_sur_batiment* sont exactement les mêmes
 que *addrstreet_tag_sur_batiment*.
  Je ne retrouve pas l'anomalie en *associatedStreet*.

 Petite erreur de copier-coller dans le code du script ?


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


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

Re: [OSM-talk-fr] [osm-alsace] combien d'adresses en Alsace ?

[Pierre Knobel]

Bonjour à tous,

J'ai créé un gâteau mapcraft pour les adresses du Bas-Rhin, au cas où ça
intéresse quelqu'un de participer à la saisie des adresses depuis le
cadastre.

C'est ici : http://mapcraft.nanodesu.ru/pie/388

Ce n'est pas encore à jour, il y a beaucoup plus de communes déjà
complétées qu'il suffira de passer en vert. Denis vient de mettre à jour
l'état d'avancement de la région :
http://listes.openstreetmap.fr/wws/d_read/local-alsace/cartes/tx_couv_adressses_20140403.pdf

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

Re: [OSM-talk-fr] Impression de cartes

[Pierre Knobel]

Bonsoir,

Maposmatic permet de choisir la taille d'impression et propose même du A0.
Si tu choisis une zone trop grande tu ne pourras pas sélectionner une
petite taille d'impression, mais je crois que les grandes tailles sont
toujours disponibles. Le choix se fait à la 3e étape, après la sélection de
la zone et le choix de la feuille de style.

Bonne nuit,
Pierre


2014-04-02 23:26 GMT+02:00 Mides mides@gmail.com:

 Bonsoir,

 Existe t-il un site similaire à celui-ci, http://www.maposmatic.org/ ,
 mais permettant de créer des fichiers en vue d'une impression papier sur
 une format un peu plus grand que le A4, ou sinon,  quelle peut être
 l'approche la plus simple.

 Bonne fin de soirée.

 Michel

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


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

[OSM-talk-fr] natural=cloud

[Pierre Knobel]

Bonjour,

Un nouveau tag pour la carto 3D :
https://wiki.openstreetmap.org/wiki/Tag:natural%3Dcloud . Ne pas oublier de
rajouter un layer=*.

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

Re: [OSM-talk-fr] natural=cloud

[Pierre Knobel]

Je me colle à la traduction.


2014-04-01 8:32 GMT+02:00 Pierre-Yves Berrard pierre.yves.berr...@gmail.com
:

 Génial !
 On l'attendait avec impatience.


 2014-04-01 8:28 GMT+02:00 Christian Quest cqu...@openstreetmap.fr:

 Personne pour la traduction en français ?


 2014-04-01 8:02 GMT+02:00 Pierre Knobel pierr...@gmail.com:

 Bonjour,

 Un nouveau tag pour la carto 3D :
 https://wiki.openstreetmap.org/wiki/Tag:natural%3Dcloud . Ne pas
 oublier de rajouter un layer=*.

 Pierre

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




 --
 Christian Quest - OpenStreetMap France
 Conférence State Of The Map France du 4 au 6 avril à 
 Parishttp://openstreetmap.fr/sotmfr

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



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


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

Re: [OSM-talk-fr] natural=cloud

[Pierre Knobel]

https://wiki.openstreetmap.org/wiki/FR:Tag:natural%3Dcloud


2014-04-01 8:53 GMT+02:00 djo_man djo_...@laposte.net:

  bonjour,

 J'ai testé et ça marche !
 Il pleut vraiment à cet endroit

 http://www.openstreetmap.org/way/270790379


 djo_man



 Le 01/04/2014 08:46, Pierre Knobel a écrit :

 Je me colle à la traduction.


 2014-04-01 8:32 GMT+02:00 Pierre-Yves Berrard 
 pierre.yves.berr...@gmail.com:

 Génial !
 On l'attendait avec impatience.


  2014-04-01 8:28 GMT+02:00 Christian Quest cqu...@openstreetmap.fr:

  Personne pour la traduction en français ?


  2014-04-01 8:02 GMT+02:00 Pierre Knobel pierr...@gmail.com:

  Bonjour,

 Un nouveau tag pour la carto 3D :
 https://wiki.openstreetmap.org/wiki/Tag:natural%3Dcloud . Ne pas
 oublier de rajouter un layer=*.

  Pierre

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




  --
 Christian Quest - OpenStreetMap France
 Conférence State Of The Map France du 4 au 6 avril à 
 Parishttp://openstreetmap.fr/sotmfr

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



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




 ___
 Talk-fr mailing 
 listTalk-fr@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-fr




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


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

Re: [OSM-talk-fr] natural=cloud

[Pierre Knobel]

C'est posté sur tagging@. Je n'avais pas pu le faire avant parce que
j'étais dans le train et que ma connexion coupait tout le temps.
Il y a eu des ajouts intéressant sur la page du wiki en anglais:
http://wiki.openstreetmap.org/w/index.php?title=Tag%3Anatural%3Dclouddiff=1010437oldid=1010380
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Voies vertes : le retour

[Pierre Knobel]

Moi je trouve ça un peu gênant de ne pas avoir de tags bien distincts pour
un sentier de haute montagne avec des rochers en travers du chemin et une
voie goudronnée en ville, alors qu'on distingue des concepts bien plus
similaires du genre highway=tertiary vs highway=unclassified. La clé
highway elle même m'a toujours choqué, ça m'intéresserait bien de
comprendre ce qui a motivé les premiers contributeurs à l'utiliser pour des
rues et des chemins en terre. Je sais qu'on peut rajouter des infos comme
sac_scale=mountain_hiking, surface=*, mais je trouve que ce sont des
béquilles qui illustrent le manque d'ambition initiale du projet.

Quand est-ce qu'on passera enfin d'OpenStreetMap à OpenWorldMap ?


2014-03-03 8:58 GMT+00:00 Eric Sibert courr...@eric.sibert.fr:

 Les rues piétonnes en villes seraient des sentiers si on suivait la logique
 du wiki...


 Entre temps, je me suis replongé dans le wiki en particulier pour
 highway=path :
 
 Description : Un chemin générique



 Certes.

 
 Un chemin ouvert au public qui n'est pas destiné aux véhicules à moteur,
 sauf si taggué séparément. Ceci inclut les pistes équestres, pour vélos,
 VTT, motoneiges, de ski de fond et les chemins ou sentiers pour piétons et
 randonneurs ou encore une combinaison de ceux-ci ainsi que d'autres modes
 de transport.



 Ca colle à la Voie Verte.

 
 Ces chemins peuvent avoir tout type de surface.




 Toujours bon.

 
 Par défaut, la restriction d'accès est ouvert à tous les véhicules
 non-motorisés (motor_vehicle=no), mais les véhicules de secours peuvent y
 avoir accès (emergency=destination) (les règles d'accès pour véhicules à
 moteur peuvent varier d'un pays à l'autre).



 Toujours bon.

 
 Ce tag est utilisé pour les chemins pour lesquels highway=footway,
 highway=cycleway et highway=bridleway ne seraient pas appropriés ou
 inadéquates (ou simplement suffisants), mais qui toutefois restent
 utilisables pour les déplacements. Ces chemins peuvent ne pas être destinés
 à un usage particulier or l'être pour plusieurs types d'usagers. Les types
 d'usages visés peuvent être précisés avec les tags access=designated.



 On retombe sur le cas générique.

 
 Si un chemin est suffisament large pour des véhicules à quatre roues, et
 qu'il n'est pas légalement restreint aux piétons, cyclistes ou chevaux, on
 recommande en général le tag highway=track.



 Toujours bon pour la Voie Verte.

 Après, il reste la photo du wiki qui montre un sentier dans la forêt.



  Pourquoi alors ne pas faire comme les rues piétonnes en ville ? (Certaines
 restent ouvertes aussi aux cyclistes, comme les voies vertes en question
 qui doivent l'être aussi pour la plupart)


 Parce que highway=pedestrian convient mieux avec la définition:

 La valeur pedestrian de la clé highway est utilisée pour représenter des
 rues exclusivement piétonnes.

 En VO :

 For town centres and civic areas, where wide expanses of hard surface are
 provided for pedestrians to walk (often between shops).


 Civic areas, vous comprenez quoi?



 Eric


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

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

Re: [OSM-talk-fr] Nouvel arrivant v2

[Pierre Knobel]

Je suis d'accord avec Nicolas qu'un bon GPS est encore absolument vital
pour tracer les sentiers en forêt et en montagne. Effectivement la qualité
est altérée par la végétation, mais un bon récepteur bien sensible qui
capte à la fois les satellites GPS et les GLONASS marche encore très très
bien. Et la différence entre les traces GPS et les photos satellites, c'est
qu'on peut enregistrer les traces en hiver quand il n'y a plus de feuilles,
alors que les photos satellites sont toutes prises en été.
Pour ce qui est des smartphones, rares sont ceux avec un bon GPS qui ne
perdent pas leur géolocalisation dans les vallons ou dans la forêt.


2014-02-24 11:18 GMT+00:00 Pieren pier...@gmail.com:

 2014-02-24 11:05 GMT+01:00 Nicolas Moyroud nmoyr...@free.fr:

  Les traces GPS restent aussi très utiles pour tracer les sentiers de
  randonnées dans les zones de forêts,

 Malheureusement, la précision des GPS part en vrille dès qu'il y a
 trop d'arbres...

  relever la position des commerces et équipements publics, etc, etc.

 Depuis qu'on peut combiner imagerie aérienne, bâti cadastral et photos
 prises sur le terrain (pas obligatoirement géolocalisée), l'intérêt
 d'un tracé GPS a fortement baissé. Je n'utilise pratiquement plus le
 mien. Dommage pour le côté geek original, maintenant n'importe qui
 peut faire mieux avec son smartphone ;-)

 Pieren

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

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

Re: [OSM-talk-fr] combien d'adresses en Alsace ?

[Pierre Knobel]

Pour en revenir à l'image du taux de couverture, il y a un nombre
significatif de village que je pense avoir complété avec toutes les
adresses que j'arrive à distinguer sur le cadastre mais qui apparaissent en
vert clair (60-80%). Un exemple : Lembach, tout au nord de la région.
Est-ce que ça veut dire que la base cadastrale à laquelle tu avais accès
était plus complète que celle qu'on peut télécharger avec le plugin de JOSM
cadastre-fr ? J'ai remarqué qu'il manquait un certain nombre de numéros,
parfois tout un côté de la rue, mais je pensais que ces données étaient
complètement absentes de la base cadastrale.


2014/1/13 HELFER Denis denis.hel...@rff.fr

  Pour déterminer les règles d’usage, vous pouvez vous servir de la page
 wiki ad hoc : http://wiki.openstreetmap.org/wiki/Mulhouse/MulhouseData. A
 ce propos, l’import de l’opendata mulhousien avance bien. Bravo eiger



 Denis



 *De :* Matthias Dietrich [mailto:eiger@gmail.com]
 *Envoyé :* samedi 11 janvier 2014 18:54
 *À :* Discussions sur OSM en français
 *Objet :* Re: [OSM-talk-fr] combien d'adresses en Alsace ?



 Le 11 janvier 2014 18:06, Jean-Baptiste Holcroft jb.holcr...@gmail.com
 a écrit :

 Quelle est la règle actuelle ?
 REF:FR:M2A ?

 Il n'y en a pas ;-) (de règle), mais cela pourrait en effet devenir
 ref:FR:M2A.

 Les jeux de données de la M2A ne comportent pas tous d'identifiant ou de
 référence. Les stations Vélocité ont été importées depuis plus longtemps à
 partir des fichiers mis à disposition par JCDecaux, avec un simple
 ref=numéro de station. La plupart des autres objets n'ont pas de
 d'identifiant.

 Pour parler concrètement : est-ce que tu souhaites procéder à l'import des
 arbres de la M2A ? Il faudrait s'accorder sur ce qu'on fait des attributs
 disponibles (diamètre de la couronne, etc.).



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


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

Re: [OSM-talk-fr] combien d'adresses en Alsace ?

[Pierre Knobel]

D'accord, donc dans ce cas particuliers ça s'explique bien par la quantité
d'adresses placées sur le bâti (Pfafenbronn et aussi Mattstall). Pour les
autres villages il va falloir que je jette un deuxième coup d'oeil,
l'explication des adresses sur polygones ne fonctionne que pour Lembach ;-)
http://tools.geofabrik.de/osmi/?view=addresseslon=7.74758lat=48.94608zoom=12overlays=buildings_with_addresses,nodes_with_addresses_defined,nodes_with_addresses_interpolated,no_addr_street,street_not_found,nearest_roads

Autre question : Est-ce qu'on a une technique pour les villages qui n'ont
pas de cadastre vectoriel (Dambach) ?


2014/1/13 HELFER Denis denis.hel...@rff.fr

  Plusieurs éléments de réponse :

 · La base cadastrale sur laquelle je me suis appuyé contient plus
 d’éléments que de réelles adresses. J’avais empiriquement pris uniquement
 92% de ce résultat pour tenir compte de cas particuliers que j’avais
 repéré : poste de transformation électrique qui avait une adresse, adresses
 placées alors qu’aucun bâtiment n’existe (cas dans des lotissements où
 l’adresse est prévisible), hangars agricoles avec adresse, etc.

 · L’ensemble des adresses n’est pas affiché sur le plan
 cadastral. Parfois, il faut aller sur le site du cadastre, choisir une
 parcelle et afficher les informations. Il faut donc jongler entre JOSM et
 le cadastre à moins qu’une développeur fou ne nous permette de remonter
 l’info dans JOSM. Une bière (ou plus si affinités) à la clé !

 · Comme déjà évoqué, il ne faut pas prendre les chiffres à la
 lettre (elle est bonne celle là ;-) Il s’agit plutôt d’un indicateur que
 l’on pourrait remplacer par : rien, un tout petit peu, un petit peu, un
 peu, pas mal, vraiment beaucoup, top moumoute. Prochaine version.

 · Il faut tenir compte que la base de comparaison commence à
 dater un peu et fausse encore plus les calculs

 · Enfin, il faut repasser régulièrement sur les communes, au
 moins annuellement. Les plans cadastraux évoluent pas mal surtout s’ils
 sont vectorisés.



 Pour le cas particulier de Lembach, il y a une centaine d’adresses
 attribut de bâti qui ne sont pas comptées sur Pfaffenbronn (je ne compte
 que les points par pure fainéantise). Sur la rue André Maginot, tu peux
 raisonnablement interpoler les n°11 et 13. L’impasse des Noyers a 6
 adresses, etc.

 Tu dois pouvoir basculer très rapidement dans la catégorie « pas mal »
 voire même « vraiment beaucoup ».

 Je referai une analyse début février.



 Denis



 *De :* Pierre Knobel [mailto:pierr...@gmail.com]
 *Envoyé :* lundi 13 janvier 2014 11:58

 *À :* Discussions sur OSM en français
 *Objet :* Re: [OSM-talk-fr] combien d'adresses en Alsace ?



 Pour en revenir à l'image du taux de couverture, il y a un nombre
 significatif de village que je pense avoir complété avec toutes les
 adresses que j'arrive à distinguer sur le cadastre mais qui apparaissent en
 vert clair (60-80%). Un exemple : Lembach, tout au nord de la région.
 Est-ce que ça veut dire que la base cadastrale à laquelle tu avais accès
 était plus complète que celle qu'on peut télécharger avec le plugin de JOSM
 cadastre-fr ? J'ai remarqué qu'il manquait un certain nombre de numéros,
 parfois tout un côté de la rue, mais je pensais que ces données étaient
 complètement absentes de la base cadastrale.



 2014/1/13 HELFER Denis denis.hel...@rff.fr

 Pour déterminer les règles d’usage, vous pouvez vous servir de la page
 wiki ad hoc : http://wiki.openstreetmap.org/wiki/Mulhouse/MulhouseData. A
 ce propos, l’import de l’opendata mulhousien avance bien. Bravo eiger



 Denis



 *De :* Matthias Dietrich [mailto:eiger@gmail.com]
 *Envoyé :* samedi 11 janvier 2014 18:54
 *À :* Discussions sur OSM en français
 *Objet :* Re: [OSM-talk-fr] combien d'adresses en Alsace ?



 Le 11 janvier 2014 18:06, Jean-Baptiste Holcroft jb.holcr...@gmail.com
 a écrit :

 Quelle est la règle actuelle ?
 REF:FR:M2A ?

 Il n'y en a pas ;-) (de règle), mais cela pourrait en effet devenir
 ref:FR:M2A.

 Les jeux de données de la M2A ne comportent pas tous d'identifiant ou de
 référence. Les stations Vélocité ont été importées depuis plus longtemps à
 partir des fichiers mis à disposition par JCDecaux, avec un simple
 ref=numéro de station. La plupart des autres objets n'ont pas de
 d'identifiant.

 Pour parler concrètement : est-ce que tu souhaites procéder à l'import des
 arbres de la M2A ? Il faudrait s'accorder sur ce qu'on fait des attributs
 disponibles (diamètre de la couronne, etc.).




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



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


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

Re: [OSM-talk-fr] combien d'adresses en Alsace ?

[Pierre Knobel]

J'ai travaillé sur le nord est (Vosges du nord et outre foret). Je m'y
remettrai a nouveau  quand j'aurais du temps libre, mais je ne sais pas
quand.
C'est bizarre, je croyais que le taux de couverture etait bcp plus
important dans le Bas-Rhin.

En tout cas bravo pour les statistiques!


On Wednesday, January 8, 2014, HELFER Denis denis.hel...@rff.fr wrote:
 Bonjour et bonne année à tous,



 Je suis particulièrement l’évolution de la saisie des adresses dans OSM
tout particulièrement en Alsace depuis quelques années. C’est actuellement
et, entre autres, pour un projet important de collectivités alsaciennes,
une donnée clé pour appuyer des applications porte-à-porte sur la base OSM.

 Pour l’Alsace, le volume total d’adresses à saisir est plus que
conséquent : il dépasse les 520.000 !

 Fin 2009, nous en avions un peu moins de 14.000 dans la base ; plus de
110.000 en mai 2011 ; 256.000 à la toute fin de 2013. Que de chemin
parcouru …  mais il en reste encore la moitié à faire.

 Vous me direz : mais où ?



 La réponse en image :
http://listes.openstreetmap.fr/wws/d_read/local-alsace/cartes/tx_couv_adresses_20140103.jpg

 Et en graphique :
http://listes.openstreetmap.fr/wws/d_read/local-alsace/cartes/progression_adresses_OSM_20131230.jpg



 Quelques mots d’explication :

 Le taux de couverture est obtenu en comparant le nombre d’adresses
présentes dans OSM par commune (géotraitement) et celui issu de la base
cadastrale (à laquelle j’avais accès dans une autre vie et qui date de
2009-2010). Ce n’est pas scientifiquement irréprochable, mais c’est une
première approche.



 Vous l’avez bien compris, je cherche de l’aide !!! Pour ma part, je
poursuis l’intégration des adresses opendata de l’agglomération de Mulhouse
(http://addr.openstreetmap.fr/mulhouse/ ) pour que celle-ci devienne n°1
dans ce chart : http://addr.openstreetmap.fr/stats.php en attendant les
adresses sur la communauté urbaine de Strasbourg prévues pour le printemps
2014.



 A vot’ bon coeur



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

Re: [OSM-talk-fr] Outil d'intégration des adresses

[Pierre Knobel]

Plutôt une courbe qui montre le nombre de tags ajoutés en fonction du
temps, dans le genre
http://wiki.openstreetmap.org/wiki/Stats#Node.2C_way_and_relation_creationmais
filtré pour une clé donnée.


2013/11/12 adrien carpentier ad.carpent...@gmail.com

 Le 10 novembre 2013 15:45, Pierre Knobel pierr...@gmail.com a écrit :

 Est-ce qu'il y a une manière de voir quelques statistiques pour un tag en
 particulier en France ? Un truc simple comme une courbe du nombre total de
 tags addr:housenumber ferait bien l'affaire.


 genre ça? :
 http://taginfo.openstreetmap.fr/keys/addr%3Ahousenumber



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


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

Re: [OSM-talk-fr] Outil d'intégration des adresses

[Pierre Knobel]

Est-ce qu'il y a une manière de voir quelques statistiques pour un tag en
particulier en France ? Un truc simple comme une courbe du nombre total de
tags addr:housenumber ferait bien l'affaire.

En attendant j'ai contribué saisir les adresses des villages du Bas-Rhin à
partir du cadastre. Je pense qu'en s'y mettant à plusieurs on devrait assez
facilement être capable de finir tout le département avant la fin de
l'année. Ca ferait un chouette sujet de communication. Avis aux intéressés
;)

http://tools.geofabrik.de/osmi/?view=addresseslon=7.76852lat=48.81699zoom=10overlays=buildings,buildings_with_addresses,nodes_with_addresses_defined,nodes_with_addresses_interpolated,no_addr_street,street_not_found


2013/11/10 Christian Quest cqu...@openstreetmap.fr

 Je pense que le récapitulatif n'est lié qu'au villes pour lesquels l'outil
 d'intégration possède des données. Il y a bien plus de villes qui ont des
 adresses dans OSM !


 Le 10 novembre 2013 13:26, Tony Emery tony.em...@yahoo.fr a écrit :

 Les adresses de la ville d'Orange sont toutes sur OSM. Pourtant, cette stat
 n’apparaît pas dans ton outils...



 -
 Tony EMERY
 Administrateur OpenStreetMap.fr
 Mandataire Grand Sud-Est
 Géomaticien  chef de projets
 --
 View this message in context:
 http://gis.19327.n5.nabble.com/Outil-d-integration-des-adresses-tp5784572p5784832.html
 Sent from the France mailing list archive at Nabble.com.

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




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

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


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

Re: [OSM-talk-fr] Tracé des limites communales d'Aquitaine terminé

[Pierre Knobel]

Oui, un grand bravo à tous les participants à ce gigantesque chantier.

Est-ce que vous avez déjà un prochain grand projet en vue quand vous aurez
fini ? Peut-être la saisie des adresses dans les villages depuis le
cadastre ?


2013/10/9 Greg ewala...@gmail.com

 Bravo pour le travail. Bientôt la France (métropolitaine?) complète il
 semblerait.

 Que de travail accompli ces dernières années. Les fourmis avancent
 lentement mais surement.



 Greg


 2013/10/9 Vincent de Château-Thierry v...@laposte.net

 Bonsoir,
 En 3 semaines et des miettes, nous avons bouclé le tracé des 222 limites
 communales qui manquaient en Aquitaine. La petite troupe comptait cette
 fois-ci 9 contributeurs, merci à tous.
 On peut dire au passage que le croisillon est denrée rare en Dordogne...
 À l'issue de ce chantier, on peut noter que la moitié sud de la France
 est intégralement couverte. En effet, la Haute-Corse, qui avait encore
 quelques trous, a été complétée sur la même période. Bien joué Marc :-)

 http://layers.openstreetmap.**fr/?zoom=6lat=46.4lon=2.**3508layers=**
 BThttp://layers.openstreetmap.fr/?zoom=6lat=46.4lon=2.3508layers=BT

 Il nous reste, en tout, à peine plus de 1000 communes sans limites sur la
 France. Un petit tiers (307) est concentré sur un seul département, qui va
 être la cible de notre prochain gâteau : les Ardennes.
 Il y en aura une fois de plus pour tout le monde :-)
 Vous êtes les bienvenus par ici :
 http://mapcraft.nanodesu.ru/**pie/318#http://mapcraft.nanodesu.ru/pie/318#

 merci,
 vincent

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



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


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

Re: [OSM-talk-fr] Un peu d'exotisme depuis votre fauteuil : tracé des routes à Pemba (Mozambique)

[Pierre Knobel]

Bon, c'est encore très loin d'être complet, mais c'est mieux que la
zone blanche de la semaine dernière :
http://www.openstreetmap.org/#map=14/-12.9666/40.5128 . Merci à ceux
qui ont contribué.

Maintenant je suis parti sur une highway=secondary pour explorer un
peu le pays : http://www.openstreetmap.org/browse/way/240182157 Je me
demande si je verrais un éléphant.

On 9/26/13, Arnaud Vandecasteele arnaud@gmail.com wrote:
 Super, j'avais justement besoin d'une zone un peu vierge pour mon cours
 de cet aprèm !
 20 étudiants qui vont mapper ce petit bout d'Afrique :)

 A.


   On 13-09-26 08:46 AM, Pierre Knobel wrote:
 Bonjour,

 Pour les passionnés d'armchair mapping, j'ai trouvé un morceau de zone
 blanche assez intéressant avec une imagerie satellite suffisante pour
 bien tracer les routes : Pemba au Mozambique.

 C'est une ville assez atypique en Afrique, d'après mon expérience
 personnelle. Il y a de larges avenues datant de l'ère coloniale
 Portugaise qui a assez significativement influencée l'architecture, et
 un réseau assez cohérent de rues, mais quasiment pas de circulation
 automobile. Dans les autres villes que j'ai visité sur la côte Est
 (Nairobi, Mombasa, Dar es-Salaam) c'était plutôt l'inverse, des
 mauvaises routes bouchées le plus souvent, architecture pas vraiment
 influencée par les colons...

 J'ai commencé à tracer des rues résidentielles, avant ça il n'y avait
 qu'une primaire et quelques secondaires. La difficulté est un peu
 supérieure dans les quartiers pauvres de la banlieue, c'est difficile
 de deviner si les chemins sont carrossables ou piétons, à cause
 l'absence totale de voiture sur les photos satellite. Et on trouve
 quelques exemples de grand carrefours déserts en terre qui méritent
 probablement des polygônes highway=residential avec area=yes, à moins
 que quelqu'un ait le courage de déterminer un filaire satisfaisant ;)

 Ça se passe ici :
 http://www.openstreetmap.org/#map=14/-12.9762/40.5260



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

 --
 
 Arnaud Vandecasteele
 SIG - WebMapping - Spatial Ontology - GeoCollaboration

 Web Site
 http://geotribu.net/



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