Re: [OSM-talk-fr] Opensnowmap.org

[Fabien]

Super merci ! Je cherchais récemment un démonstrateur pour les pistes de ski.

Par contre, ça fait bizarre d'avoir les skieurs à l'envers sur le
tire-fesses : 
http://www.opensnowmap.org/?zoom=16&lat=45.913&lon=6.58931&layers=&e=false&m=raster

Fabien

Le 4 avril 2013 21:33, yvecai  a écrit :
> Chers ami et béta-testeurs préférés,
> Je vous remerci d'avance de cliquer sur le lien ci-dessous et d'aller voir
> dans les coins si tout est comme il faut.
> C'est votre nouvelle carte pour les sports d'hivers :
>
> http://www.opensnowmap.org
>
> Au menu:
> * Serveur de tuiles
>Avec des données fraiches du jour, tout les matins
> * Infos sur les pistes d'un simple clic
>Plus de mode 'vecteur', beaucoup plus léger et meilleure
> compatibilité sur les navigateurs
> * Recherche des pistes par nom
>Les résultats Nominatim sont augmentés d'une sélection 'special ski'
> * Routage et dénivelés multi-modaux
>   Montée en ski de descente, descente en remontée mécanique et
> raccourcis en raquettes, c'est possible !
> * Forum
>  Oui, un canal de plus, mais c'est essentiellement pour assurer la
> viabilité du site à long terme
>
>
> www.pistes-nordiques.org est ainsi voué à disparaitre au profit de ce
> nouveau site, dédié à l'ensemble des sports d'hiver.
>
> Yves
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>

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

Re: [OSM-talk-fr] Opensnowmap.org

[Nicolas Dumoulin]

Le jeudi 4 avril 2013 21:33:46 yvecai a écrit :
> Chers ami et béta-testeurs préférés,
> Je vous remerci d'avance de cliquer sur le lien ci-dessous et d'aller
> voir dans les coins si tout est comme il faut.
> C'est votre nouvelle carte pour les sports d'hivers :
> 
> http://www.opensnowmap.org

Merci Yves pour ce site.
J'ai découvert récemment qu'un foyer de ski de fond près de chez moi utilisait 
des fond de carte OSM pour son dépliant. Ça m'a motivé pour avancer la 
cartographie de leur petit domaine, et leur montrer ton site pour la prochaine 
saison.
Avec ce nouveau rendu, c'est encore plus beau :-)
Il me semble qu'avant les différentes pistes étaient superposées ?
En tout cas, là c'est bien clair.

> * Infos sur les pistes d'un simple clic
> Plus de mode 'vecteur', beaucoup plus léger et meilleure
> compatibilité sur les navigateurs

Là, par contre, je n'y arrive pas.
Par ailleurs, une petite légende sur le bouton "i" qui est sur le cartouche 
serait pas mal.

Suggestion : ajouter d'autres POI, comme les lieu de restauration, les foyers 
hors-sac, la billeterie, le départ des pistes, …

Merci

-- 
Nicolas Dumoulin
http://wiki.openstreetmap.org/wiki/User:NicolasDumoulin

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

Re: [OSM-talk-fr] Opensnowmap.org

[Nicolas Dumoulin]

Le vendredi 5 avril 2013 09:05:20 Nicolas Dumoulin a écrit :
> > * Infos sur les pistes d'un simple clic
> > 
> > Plus de mode 'vecteur', beaucoup plus léger et meilleure
> > 
> > compatibilité sur les navigateurs
> 
> Là, par contre, je n'y arrive pas.
> Par ailleurs, une petite légende sur le bouton "i" qui est sur le cartouche
> serait pas mal.

Bon, en fait, en cliquant sur ce "i" puis sur une piste, ça démarre le calcul 
d'itinéraire et affiche les pistes empruntées. Mais je n'arrive pas à obtenir 
des détails sur les pistes elles-mêmes.

-- 
Nicolas Dumoulin
http://wiki.openstreetmap.org/wiki/User:NicolasDumoulin

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

Re: [OSM-talk-fr] Rendu topo 25000ème - réponses multiples

[Nicolas Dumoulin]

Le jeudi 4 avril 2013 20:10:20 JB a écrit :
> C'est en train d'uploader, sous
> http://osm107.openstreetmap.fr/jbtopo/besancon25.png

Ha oui, c'est assez joli comme rendu. J'aurai préféré du mapnik, mais là je 
dois avouer que j'oublie presque que c'est du maperitive ;-)
Beau boulot !

-- 
Nicolas Dumoulin
http://wiki.openstreetmap.org/wiki/User:NicolasDumoulin

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

Re: [OSM-talk-fr] Rendu topo 25000ème - réponses multiples

[JB]

 

Voici deux essais de diminution de la visibilité des tunnels
ferroviaires. J'ai tendance à préférer le plus discret des deux. Et vous
? 

http://osm107.openstreetmap.fr/jbtopo/tunnel1.png


http://osm107.openstreetmap.fr/jbtopo/tunnel.png , plus discret 

JB.


(oui, je sais, la voie ferrée est encore au dessus. Les courbes de
niveau aussi, d'ailleurs) 

Le 04.04.2013 21:02, Etienne Trimaille a
écrit : 

> Le 4 avril 2013 20:10, JB  a écrit :
> 
>>
C'est en train d'uploader, sous
http://osm107.openstreetmap.fr/jbtopo/besancon25.png [1]
> 
> Il y a un
petit bug de rendu : le tunnel ferré de Morre :
http://tile.openstreetmap.fr/?zoom=17&lat=47.22244&lon=6.07422&layers=B0
[3] 
> Sur ton rendu, il est dessiné par dessus les routes alors qu'il
doit être en-dessous.
> 
> Alors que sur la même extrait de ta carte, le
tunnel de Chalezeule est dessiné sous les routes :
>
http://tile.openstreetmap.fr/?zoom=17&lat=47.25423&lon=6.05837&layers=B0
[4] 
> 
> N'est-il pas possible de réduire un peu la visibilité des
tunnels en général ? A part les entrées et les tunnels, les tunnels ne
sont pas visibles ;-)
> 
> cquest, les bugs des tunnel est présent aussi
sur osmfr, même si ce n'est pas très visible. 
> 
>
___
> Talk-fr mailing list
>
Talk-fr@openstreetmap.org
>
http://lists.openstreetmap.org/listinfo/talk-fr [2]




Links:
--
[1]
http://osm107.openstreetmap.fr/jbtopo/besancon25.png
[2]
http://lists.openstreetmap.org/listinfo/talk-fr
[3]
http://tile.openstreetmap.fr/?zoom=17&lat=47.22244&lon=6.07422&layers=B0
[4]
http://tile.openstreetmap.fr/?zoom=17&lat=47.25423&lon=6.05837&layers=B0
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Rendu topo 25000ème - réponses multiples

[Nicolas Dumoulin]

Le vendredi 5 avril 2013 09:18:35 JB a écrit :
> Voici deux essais de diminution de la visibilité des tunnels
> ferroviaires. J'ai tendance à préférer le plus discret des deux. Et vous
> ?
> 
> http://osm107.openstreetmap.fr/jbtopo/tunnel1.png
> 
> 
> http://osm107.openstreetmap.fr/jbtopo/tunnel.png , plus discret

Je suis d'accord, le second est plus joli

-- 
Nicolas Dumoulin
http://wiki.openstreetmap.org/wiki/User:NicolasDumoulin

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

[OSM-talk-fr] Re : Opensnowmap.org

[yve...@gmail.com]

Quel détails te manque t il ?
Normalement, il s'affichent dans la boîte qui s'ouvre après un clic sur la 
piste.
Yves

- Reply message -
De : "Nicolas Dumoulin" 
Pour : "Discussions sur OSM enfrançais" 
Objet : [OSM-talk-fr] Opensnowmap.org
Date : ven., avr. 5, 2013 09:10


Le vendredi 5 avril 2013 09:05:20 Nicolas Dumoulin a écrit :
> > * Infos sur les pistes d'un simple clic
> > 
> > Plus de mode 'vecteur', beaucoup plus léger et meilleure
> > 
> > compatibilité sur les navigateurs
> 
> Là, par contre, je n'y arrive pas.
> Par ailleurs, une petite légende sur le bouton "i" qui est sur le cartouche
> serait pas mal.

Bon, en fait, en cliquant sur ce "i" puis sur une piste, ça démarre le calcul 
d'itinéraire et affiche les pistes empruntées. Mais je n'arrive pas à obtenir 
des détails sur les pistes elles-mêmes.

-- 
Nicolas Dumoulin
http://wiki.openstreetmap.org/wiki/User:NicolasDumoulin

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

Re: [OSM-talk-fr] Rendu topo 25000ème

[Romain MEHUT]

Autre question: as-tu testé l'affichage des noms de rues pour les fort
zoom?

Romain

Le 4 avril 2013 21:33, Romain MEHUT  a écrit :
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Rendu topo 25000ème - réponses multiples

[Jean-Claude Repetto]

Le 05/04/2013 09:18, JB a écrit :

Voici deux essais de diminution de la visibilité des tunnels
ferroviaires. J'ai tendance à préférer le plus discret des deux. Et vous ?

http://osm107.openstreetmap.fr/jbtopo/tunnel1.png

http://osm107.openstreetmap.fr/jbtopo/tunnel.png , plus discret

JB.



Désolé de renouveler ma demande, mais je pense que tu ne l'as pas lue la 
première fois.

N'envoie pas tes messages au format HTML, utilise du texte simple.

Merci d'avance.



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

Re: [OSM-talk-fr] Rendu topo 25000ème

[JB]

Non… parce que je n'ai pas prévu les zooms forts.

Ça pose beaucoup de nouvelles problématiques, dont certaines encore mal 
gérées par maperitive (voir le nombre de votes pour cette proposition : 
http://maperitive.idea.informer.com/proj/?ia=25923). Et je pense que si 
je veux le faire, il faut que je fasse un réel multi-zoom pour adapter 
la largeur des voies pour que le texte rendre dedans et ne déborde pas 
sur les bâtiments autour (c'est souvent la rue qui déborde dessus, et le 
texte sur la rue). Francetopo commence à faire apparaitre les noms de 
rue avec parcimonie au 5000ème, soit 25 fois plus d'espace qu'au 25000.


JB.


Le 05.04.2013 09:26, Romain MEHUT a écrit :


Autre question: as-tu testé l'affichage des noms de rues pour les fort
zoom?

Romain

Le 4 avril 2013 21:33, Romain MEHUT  a écrit :

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




Links:
--
[1] http://lists.openstreetmap.org/listinfo/talk-fr

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

Re: [OSM-talk-fr] Re : Opensnowmap.org

[Nicolas Dumoulin]

Le vendredi 5 avril 2013 09:21:29 yve...@gmail.com a écrit :
> Quel détails te manque t il ?
> Normalement, il s'affichent dans la boîte qui s'ouvre après un clic sur la
> piste. Yves

Ben moi, j'aimerai que cliquer une piste me mette en évidence la piste pour la 
distinguer des autres, car deux pistes peuvent avoir des tronçons en commun, 
par exemple ici :
http://www.opensnowmap.org/?zoom=15&lat=45.62994&lon=2.87237&layers=&e=false&m=raster
Si je clique sur la piste rouge qui part à l'ouest, ça me dit "Chevalard", OK. 
Mais par où passe cette piste après avoir rejoint la bleu ? Quelle distance 
fait-elle ? Quel est son profil ?
Je peux avoir les infos d'un itinéraire en ajoutant mes points, mais je peux 
aussi me dire « si je suis la piste machin, ça fait quoi ? »

En passant, la liste des pistes empruntées ont une petite icône sur la gauche. 
Mais dans mon cas, l'URL est à undefined. Peut-être une histoire de tag 
nordic/skating … ?

Merci

-- 
Nicolas Dumoulin
http://wiki.openstreetmap.org/wiki/User:NicolasDumoulin

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

Re: [OSM-talk-fr] expérimentations à Orange

[Christian Quest]

Il me semble qu'un numéro de référence unique de la voirie doit
effectivement se baser sur le code rivoli/fantoir et le code insee de
la commune.

Comme toujours, il faut regarder les cas particuliers... par exemple
comment gérer une rue qui est la limite entre deux communes ?

Ce simple cas particulier me laisse penser qu'il faudrait une
référence combinée INSEE+FANTOIR et ça sera plus léger que d'avoir 2
tags.

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

[OSM-talk-fr] Forum ESRI - Aix-en-Provence

[Tony Emery]

Bonjour à tous,

ESRI à organise chaque année une série de 9 forums décentralisés. Le premier
d'entre-eux à eu lieu hier (le 4 avril) à Aix-en-Provence.

ESRI m'a proposé d'intervenir comme témoin sur le thème " Ouvrir son SIG :
l'expérience de la Ville d'Orange  
"

Pour ceux qui étaient présents au SOTM à Lyon en février, j'ai présenté le
travail fait sur l'adressage.
Du coup, j'ai eu des discutions intéressantes par la suite et je vous donne
les grandes lignes :
- Outre les collectivités qui veulent mettre en place la même démarche, des
sociétés s'intéressent à OSM et souhaitent développer des solutions autour
d'OSM.
- ERSI France souhaite aller plus loin dans l'utilisation des données OSM et
proposer des outils et des solutions à leur clients et, notamment développer
ce marché sur le continent africain.
- l'AITF, via Yves MEO, Animateur du groupe de travail Régional SIG/TOPO,
souhaite organiser un séminaire en fin d'année et nous inviter pour
présenter notre travail et que l'AITF se penche sérieusement sur
l'utilisation des données OSM dans les collectivité. 
- Etant aussi le chef du service de l'Information Géographique de la
CommunautéUrbaine Marseille Provence Métropole (MPM), Yves Méo a été
intéressé par la démarche.
- l'IGN confirme son intérêt pour OSM et j'ai proposé qu'on puisse
travailler sur l'adressage.




--
View this message in context: 
http://gis.19327.n5.nabble.com/Forum-ESRI-Aix-en-Provence-tp5755839.html
Sent from the France mailing list archive at Nabble.com.

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

Re: [OSM-talk-fr] expérimentations à Orange

[Tony Emery]

cquest wrote
> Il me semble qu'un numéro de référence unique de la voirie doit
> effectivement se baser sur le code rivoli/fantoir et le code insee de
> la commune.
> 
> Comme toujours, il faut regarder les cas particuliers... par exemple
> comment gérer une rue qui est la limite entre deux communes ?
> 
> Ce simple cas particulier me laisse penser qu'il faudrait une
> référence combinée INSEE+FANTOIR et ça sera plus léger que d'avoir 2
> tags.

Les collectivités ne pourront pas utiliser les codes fantoir de la DGFiP :
- parce qu'ils sont créés par la DGFiP a posteriori, après que la commune
ait transmis la délibération aux impôts, que ces derniers aient intégré ces
infos dans leur base et que ces données aient été renvoyées aux communes. Il
peut se passer plusieurs mois, voire plus.
- il y a des doublons dans les fantoir, et des codes fantoir qui pointent
sur des voies qui n'existent plus.

Si les communes qui se sont penché sur le problème ont décidé de créer leur
propre identifiant unique, c'est que c'était la seule solution.
L'inconvénient étant que la très grande majorité des communes n'ont pas
encore fait ce travail.



--
View this message in context: 
http://gis.19327.n5.nabble.com/experimentations-a-Orange-tp5755270p5755840.html
Sent from the France mailing list archive at Nabble.com.

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

Re: [OSM-talk-fr] Rendu topo 25000ème - réponses multiples

[HELFER Denis]

-Message d'origine-
De : Nicolas Dumoulin [mailto:nicolas_openstreetmap@dumoulin63.net] 
Envoyé : vendredi 5 avril 2013 09:21
À : Discussions sur OSM en français
Objet : Re: [OSM-talk-fr] Rendu topo 25000ème - réponses multiples

Le vendredi 5 avril 2013 09:18:35 JB a écrit :
> Voici deux essais de diminution de la visibilité des tunnels 
> ferroviaires. J'ai tendance à préférer le plus discret des deux. Et 
> vous ?
> 
> http://osm107.openstreetmap.fr/jbtopo/tunnel1.png
> 
> 
> http://osm107.openstreetmap.fr/jbtopo/tunnel.png , plus discret

Je suis d'accord, le second est plus joli

Pareil.
Pour ailleurs, je trouve le rendu des lignes ferrées perfectible (un peu pâté) 
quand celles-ci sont tracées à la voie.  L'emprise de la voie (file de rails + 
intervoie) est d'environ 6 mètres soit 0,4 mm pour une carte au 1:25.000. A 
voir si tu ne peux pas affiner un peu le rendu.

Denis

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

[OSM-talk-fr] Compteur électrique

[Tony Emery]

Bonjour à tous,

J'ai eu une bonne question de la part d'un de mes collègues.
Peut-on localiser dans OSM les compteurs électriques (techniquement et
légalement) ?
Si oui, comment ?

Si c'est possible, il nous faudra une petite application permettant de
localiser le compteur, d'inscrire son numéro et de prendre une photo.

Développeurs, à vos souris...



--
View this message in context: 
http://gis.19327.n5.nabble.com/Compteur-electrique-tp5755843.html
Sent from the France mailing list archive at Nabble.com.

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

Re: [OSM-talk-fr] Compteur électrique

[Ista Pouss]

Je ne comprends pas. Vous voulez situer tous les compteurs électriques de
toutes les maisons ??


Le 5 avril 2013 09:51, Tony Emery  a écrit :

> Bonjour à tous,
>
> J'ai eu une bonne question de la part d'un de mes collègues.
> Peut-on localiser dans OSM les compteurs électriques (techniquement et
> légalement) ?
> Si oui, comment ?
>
> Si c'est possible, il nous faudra une petite application permettant de
> localiser le compteur, d'inscrire son numéro et de prendre une photo.
>
> Développeurs, à vos souris...
>
>
>
> --
> View this message in context:
> http://gis.19327.n5.nabble.com/Compteur-electrique-tp5755843.html
> Sent from the France mailing list archive at Nabble.com.
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>



-- 
Les dérives de rue :
Le papillon d’hiver (le film)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Compteur électrique

[Tony Emery]

Ista Pouss wrote
> Je ne comprends pas. Vous voulez situer tous les compteurs électriques de
> toutes les maisons ??

Non, ouf!! ceux qui concernent des bâtiments municipaux



--
View this message in context: 
http://gis.19327.n5.nabble.com/Compteur-electrique-tp5755843p5755847.html
Sent from the France mailing list archive at Nabble.com.

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

[OSM-talk-fr] Réunion des contributeurs ardéchois

[Henry-Pascal ELDIN]

Bonjour,

Réunion des contributeurs ardéchois et
des personnes interressés par le projet  :
le mercredi 10 avril 2013 de 18h à 20h à la salle de
réunion des Inforoutes, ZI du Lac, InnoParc à Privas 07.

Nouveau : une liste de diffusion spécifique à notre département :
inscrivez vous sur
http://listes.openstreetmap.fr/wws/subscribe/local-ardeche



 Détails sur http://wiki.openstreetmap.org/wiki/Mappeurs_Ardechois

 Contact : Henry-Pascal ELDIN, el...@inforoutes.fr , 06 84 11 70 35
 04 75 30 79 15

http://www.openstreetmap.org/?lat=44.717213&lon=4.609967&zoom=18&layers=M




-- 
Cordialement,  
Henry-Pascal ELDIN   Courayon, Route de St Bauzile  07210 CHOMERAC, FRANCE
 Tel 04 75 65 19 93 Orange 06 80 75 74 80
http://www.eldin.net

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

Re: [OSM-talk-fr] Rendu topo 25000ème - réponses multiples

[JB]

Après affinage des voies ferrées : 
http://osm107.openstreetmap.fr/jbtopo/rail.png
Je ne pense pas que j'irai plus loin. Il n'y a pas toujours un lien 
exact entre la largeur d'un élément sur la carte et dans la réalité 
(largeur des routes et les autoroutes ?).


Les voies ferrées posent un problème supplémentaire : une voie ferrée 
seule, ça va. Deux voies ou plus, ça fait des dégâts. La superposition 
des dessins de l'une avec l'autre ne donne pas toujours des résultats 
très heureux. Les pointillés blanc-noir, je n'aime pas beaucoup, les 
traits en travers, c'est pas très heureux, d'où ce dessin « paté », qui 
permet de passer pour une voie seule, ou deux voies parallèles sans 
faire de rupture de style.


JB.



Le 05.04.2013 09:49, HELFER Denis a écrit :


-Message d'origine-
De : Nicolas Dumoulin 
[mailto:nicolas_openstreetmap@dumoulin63.net]

Envoyé : vendredi 5 avril 2013 09:21
À : Discussions sur OSM en français
Objet : Re: [OSM-talk-fr] Rendu topo 25000ème - réponses multiples

Le vendredi 5 avril 2013 09:18:35 JB a écrit :


Voici deux essais de diminution de la visibilité des tunnels
ferroviaires. J'ai tendance à préférer le plus discret des deux. Et
vous ? http://osm107.openstreetmap.fr/jbtopo/tunnel1.png [1]
http://osm107.openstreetmap.fr/jbtopo/tunnel.png [2] , plus discret


Je suis d'accord, le second est plus joli

Pareil.
Pour ailleurs, je trouve le rendu des lignes ferrées perfectible (un 
peu

pâté) quand celles-ci sont tracées à la voie. L'emprise de la voie
(file de rails + intervoie) est d'environ 6 mètres soit 0,4 mm pour 
une

carte au 1:25.000. A voir si tu ne peux pas affiner un peu le rendu.

Denis

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




Links:
--
[1] http://osm107.openstreetmap.fr/jbtopo/tunnel1.png
[2] http://osm107.openstreetmap.fr/jbtopo/tunnel.png
[3] http://lists.openstreetmap.org/listinfo/talk-fr

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

Re: [OSM-talk-fr] Réflexion sur les sens uniques (ou pas) dans les ronds-points

[Nicolas Moyroud]

Non le bug ne se situait pas dans le sens de traçage du rond-point car 
il m'a inversé le sens pendant que je faisais le tour du rond-point.
Tu as peut-être raison Hendrik, je vais vérifier si je n'avais pas 
activé le mode piéton par mégarde. :-)


Nicolas


J'en pense que Osmand prend bien en charge le sens des rond points et
qu'il ne faut pas mettre un oneway=yes en plus...
Dans les pays en conduite à gauche on dessite les rond points en sens
inverse et le oneway=yes reste implicite, exactement comme en France.
Tu es peut-être en mode piéton et pas en mode voiture voiture?




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

Re: [OSM-talk-fr] Rendu topo 25000ème - réponses multiples

[HELFER Denis]

-Message d'origine-
De : JB [mailto:jb...@mailoo.org] 
Envoyé : vendredi 5 avril 2013 10:51
À : Discussions sur OSM en français
Objet : Re: [OSM-talk-fr] Rendu topo 25000ème - réponses multiples

Après affinage des voies ferrées : 
http://osm107.openstreetmap.fr/jbtopo/rail.png
Je ne pense pas que j'irai plus loin. Il n'y a pas toujours un lien exact entre 
la largeur d'un élément sur la carte et dans la réalité (largeur des routes et 
les autoroutes ?).

Les voies ferrées posent un problème supplémentaire : une voie ferrée seule, ça 
va. Deux voies ou plus, ça fait des dégâts. La superposition des dessins de 
l'une avec l'autre ne donne pas toujours des résultats très heureux. Les 
pointillés blanc-noir, je n'aime pas beaucoup, les traits en travers, c'est pas 
très heureux, d'où ce dessin « paté », qui permet de passer pour une voie 
seule, ou deux voies parallèles sans faire de rupture de style.

JB.

Oui, les voies ferrées c'est compliqué, je ne dirais pas le contraire. Je me 
pencherai sur la question de manière plus approfondie dès que j'aurai un moment.
On pourrait juste voir que cela donne sur un triage, genre Metz-Sablon 
(http://osm.org/go/0DF5G2aT--) ou Hausbergen (http://osm.org/go/0DMuuZku--) ?

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

Re: [OSM-talk-fr] cadastre.openstreetmap.fr HS

[Nicolas Moyroud]

Des nouvelles concernant le retour de cadastre.openstreetmap.fr ?
C'est pas que je suis en manque, mais presque... ;-)

Nicolas


Le 25/03/2013 23:23, Cyrille Giquello a écrit :

Merci Jocelyn !



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

Re: [OSM-talk-fr] cadastre.openstreetmap.fr HS

[Nicolas Dumoulin]

Le vendredi 5 avril 2013 11:14:12 Nicolas Moyroud a écrit :
> Des nouvelles concernant le retour de cadastre.openstreetmap.fr ?
> C'est pas que je suis en manque, mais presque... ;-)

+1
J'ai la flemme de construire les fichiers moi-même, et j'aimerai mettre à jour 
mon coin.

-- 
Nicolas Dumoulin
http://wiki.openstreetmap.org/wiki/User:NicolasDumoulin

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

Re: [OSM-talk-fr] expérimentations à Orange

[Pieren]

2013/4/5 Tony Emery 

> Qu'avons nous comme identifiant voirie :
> - Rivoli : c'est un code créé et géré par la DGFiP
> - l'ID de la BDAdresse : idem pour l'IGN
> Il faut donc créer un identifiant interne dans la commune car la commune
> est
> la source de cette information.
>
>
Donc chaque rue a trois identifiants "uniques".

Qui a parlé de simplification administrative ?

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

Re: [OSM-talk-fr] Rendu topo 25000ème - réponses multiples

[JB]

Ha, la zone que je me suis interdit de faire, en pensant que ça 
donnerait un paté noir au 25000 : 
http://osm107.openstreetmap.fr/jbtopo/triage.png


Ça ne gagnerait pas un concours de beauté, mais je pense que ça montre 
ce que c'est : plein de rails (euh, je retire, il ne faut surement pas 
dire ça à quelqu'un qui travaille sur les voies ferrées…), leur 
orientation, ce n'est pas encore un aplat noir.


Il me semble que tu disais travailler sur un rendu rail, si tu as des 
suggestions pour rendre une voie ferrée qui évite tous les problèmes 
indiqués, je suis preneur.


JB.

(Tiens, ça me montre que j'avais une boulette sur area[turn_table]…)


Le 05.04.2013 11:02, HELFER Denis a écrit :


-Message d'origine-
De : JB [mailto:jb...@mailoo.org]
Envoyé : vendredi 5 avril 2013 10:51
À : Discussions sur OSM en français
Objet : Re: [OSM-talk-fr] Rendu topo 25000ème - réponses multiples

Après affinage des voies ferrées :
http://osm107.openstreetmap.fr/jbtopo/rail.png [1]
Je ne pense pas que j'irai plus loin. Il n'y a pas toujours un lien 
exact

entre la largeur d'un élément sur la carte et dans la réalité
(largeur des routes et les autoroutes ?).

Les voies ferrées posent un problème supplémentaire : une voie ferrée
seule, ça va. Deux voies ou plus, ça fait des dégâts. La
superposition des dessins de l'une avec l'autre ne donne pas toujours 
des

résultats très heureux. Les pointillés blanc-noir, je n'aime pas
beaucoup, les traits en travers, c'est pas très heureux, d'où ce 
dessin

« paté », qui permet de passer pour une voie seule, ou deux voies
parallèles sans faire de rupture de style.

JB.

Oui, les voies ferrées c'est compliqué, je ne dirais pas le contraire.
Je me pencherai sur la question de manière plus approfondie dès que
j'aurai un moment.
On pourrait juste voir que cela donne sur un triage, genre Metz-Sablon
(http://osm.org/go/0DF5G2aT-- [2]) ou Hausbergen
(http://osm.org/go/0DMuuZku-- [3]) ?

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




Links:
--
[1] http://osm107.openstreetmap.fr/jbtopo/rail.png
[2] http://osm.org/go/0DF5G2aT--
[3] http://osm.org/go/0DMuuZku--
[4] http://lists.openstreetmap.org/listinfo/talk-fr

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

Re: [OSM-talk-fr] expérimentations à Orange

[Pieren]

2013/4/5 Tony Emery 

> Par conséquent, ces traçés, même si leur précision
> n'est pas bonne, est règlementée. Pour info, dans un document d'urbanisme
> approuvé, si le dessin d'une zone à été mal fait, qu'il coupe une parcelle
> alors qu'il ne le devrait pas, c'est quand même ce découpage qui est
> appliqué. Je pense donc, même si ce n'est pas juste, qu'il faut le laisser
> tel quel si l'on veut que les collectivités s'investissent dans OSM.
>

Ce point est capital avec OSM. C'est la violation d'un principe de base du
projet : les données doivent pouvoir être améliorées par les contributeurs,
sinon elles n'ont pas leur place dans la base. Aucune donnée ne doit
pouvoir être bloquée dans OSM sous prétexte d'officialité, encore plus si
elles sont mauvaises.
Je renverrais la lecture d'un fil de discussion de référence sur ce thème
(en anglais) :
http://lists.openstreetmap.org/pipermail/talk/2009-March/034948.html

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

Re: [OSM-talk-fr] expérimentations à Orange

[Tony Emery]

Pieren wrote
> 2013/4/5 Tony Emery <

> tony.emery@

> >
> 
>> Qu'avons nous comme identifiant voirie :
>> - Rivoli : c'est un code créé et géré par la DGFiP
>> - l'ID de la BDAdresse : idem pour l'IGN
>> Il faut donc créer un identifiant interne dans la commune car la commune
>> est
>> la source de cette information.
>>
>>
> Donc chaque rue a trois identifiants "uniques".
> 
> Qui a parlé de simplification administrative ?
> 
> Pieren

Effectivement, sans parler de l'ID de la BDAdresse que je n'utilise pas,
j'ai :
- le RIVOLI de la DGFIP (en plus, j'ai 44 voies sur les 730 qui n'ont pas de
rivoli)
- l'identifiant interne géré par la mairie
- l'identifiant OSM

Après, on ne peut pas parler de simplification administrative puisqu'il ne
s'agit pas de la même institution.
Je pense que tu dois avoir la même chose à la poste, au niveau des conseil
généraux, ...



--
View this message in context: 
http://gis.19327.n5.nabble.com/experimentations-a-Orange-tp5755270p5755862.html
Sent from the France mailing list archive at Nabble.com.

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

Re: [OSM-talk-fr] Rendu topo 25000ème - réponses multiples

[HELFER Denis]

-Message d'origine-
De : JB [mailto:jb...@mailoo.org] 
Envoyé : vendredi 5 avril 2013 11:31
À : Discussions sur OSM en français
Objet : Re: [OSM-talk-fr] Rendu topo 25000ème - réponses multiples

Ha, la zone que je me suis interdit de faire, en pensant que ça donnerait un 
paté noir au 25000 : 
http://osm107.openstreetmap.fr/jbtopo/triage.png

Ça ne gagnerait pas un concours de beauté, mais je pense que ça montre ce que 
c'est : plein de rails (euh, je retire, il ne faut surement pas dire ça à 
quelqu'un qui travaille sur les voies ferrées…), leur orientation, ce n'est pas 
encore un aplat noir.

Il me semble que tu disais travailler sur un rendu rail, si tu as des 
suggestions pour rendre une voie ferrée qui évite tous les problèmes indiqués, 
je suis preneur.

JB.

(Tiens, ça me montre que j'avais une boulette sur area[turn_table]…)

Franchement, c'est pas (trop) mal.
J'ai dit que j'allais consacrer un peu de temps dès que j'en aurai de rab. S'il 
y a des choses intéressantes, je ne manquerai pas de les partager.

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

Re: [OSM-talk-fr] expérimentations à Orange

[Pieren]

2013/4/5 Tony Emery 

> Après, on ne peut pas parler de simplification administrative puisqu'il ne
> s'agit pas de la même institution.
>

Il y a aussi le serpent de mer de la base adresse unifiée. Parce que pour
l'instant, chaque institution construit la sienne à grands frais (enfin,
surtout aux frais des contribuables et des usagers).
Mon rêve : une base adresse unifiée, publique, réutilisable librement et
avec un code de voie vraiment "unique" adoptée par toutes les institutions.
Vous avez dit "trop simple" ?

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

Re: [OSM-talk-fr] Proposition pour le projet du mois de avril

[Jean-Baptiste Holcroft]

J'ai écrit une proposition "godasse" pour OpenStreeetBugs, n'hésitez pas à
enrichir.
 - http://wiki.openstreetmap.org/wiki/FR:Project_of_the_month/OpenStreetBugs

A la fin il y a la possibilité de faire des statistiques, mais je ne sais
pas extraire les statistiques française depuis les fichiers SQL quotidien,
la ville la plus proche est systématiquement indiqué et le code [FR] est
présent, cela devrait être facile.
--
Jean-Baptiste Holcroft


Le 5 avril 2013 08:52, adrien carpentier  a écrit :

> Bonjour,
> alors quel projet a été choisi pour avril?
> il serait intéressant de le donner rapidement, quitte à laisser les débats
> sur l'ordre des suggestions pour les mois suivants, non?
> pour que l'on ne perde pas trop de temps au mois d'avril, et que l'on ait
> réellement l'ensemble des mois prochains pour les sujets suivants
> Merci en tout cas de cette initiative!
> @ bientôt
> adrien
>
>
> Le 4 avril 2013 20:33, Jo.  a écrit :
>
> Pour l'instant étant un peut seul dans mon coin, je fait mon micro mapping
>> lors de mes déplacements en ville où je préfère marcher en laissant la
>> voiture à l'autre bout de la ville pour éviter les embouteillages.
>> Idem pour mes sessions course à pied où je mémorise de tête les éléments
>> intéressant en attendant de rentrer à la maison. C'est même l'idéal pour
>> contrôler une zone ajoutée depuis Bing.
>>
>>
>> Le 4 avril 2013 20:21, PierreV  a écrit :
>>
>> Bonsoir,
>>>
>>> Je souhaite te féliciter pour la relance du projet!
>>> J'ai l'impression que mes propositions sur le wiki sont peut être passés
>>> "inaperçues", mais pour moi je pense qu'il faudrait des projets qui
>>> permettent d'améliorer la qualité "globale" des données d'OSM.
>>> C'est pour cela que j'ai proposé que l'on fasse des "projets du mois"
>>> sur:
>>> Compléter/importer l'emplacement des mairies, églises, cimetières,
>>> offices
>>> de tourisme, bibliothèques, déchetteries, postes de police et pompiers,
>>> hôpitaux, maisons de retraite, pharmacies. Et aussi pour les
>>> établissements
>>> scolaires, et agences La poste pour lesquels ont a déja des outils de
>>> "suivi".
>>>
>>>
>>>
>>> --
>>> View this message in context:
>>> http://gis.19327.n5.nabble.com/Proposition-pour-le-projet-du-mois-de-avril-tp5755340p5755775.html
>>> Sent from the France mailing list archive at Nabble.com.
>>>
>>> ___
>>> Talk-fr mailing list
>>> Talk-fr@openstreetmap.org
>>> http://lists.openstreetmap.org/listinfo/talk-fr
>>>
>>
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/talk-fr
>>
>>
>
>
> --
> http://www.virage-energie-npdc.org/
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] expérimentations à Orange

[kimaidou]

Pieren,

Je plussoie ! On parle d'opendata, mais cette base unifiée dont tu parles,
en ODBL, avec une api sympa pour y accéder, ce serait l'idéal !


Le 5 avril 2013 11:54, Pieren  a écrit :

> 2013/4/5 Tony Emery 
>
>> Après, on ne peut pas parler de simplification administrative puisqu'il ne
>> s'agit pas de la même institution.
>>
>
> Il y a aussi le serpent de mer de la base adresse unifiée. Parce que pour
> l'instant, chaque institution construit la sienne à grands frais (enfin,
> surtout aux frais des contribuables et des usagers).
> Mon rêve : une base adresse unifiée, publique, réutilisable librement et
> avec un code de voie vraiment "unique" adoptée par toutes les institutions.
> Vous avez dit "trop simple" ?
>
> Pieren
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Re : Re : Opensnowmap.org

[Nicolas Dumoulin]

Le vendredi 5 avril 2013 12:19:15 yve...@gmail.com a écrit :
> Oui, un retour genre surbrillance au survol de la liste sera sûrement
> implanté, mais j'ai pas encore la solution. C'est sur quelle piste ce pb
> d'icône?

Sur à peu près toutes les pistes du domaine de Pessade :
http://www.opensnowmap.org/?zoom=15&lat=45.62994&lon=2.87237&layers=&e=false&m=raster


-- 
Nicolas Dumoulin
http://wiki.openstreetmap.org/wiki/User:NicolasDumoulin

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

Re: [OSM-talk-fr] Proposition pour le projet du mois de avril

[thevenon . julien]

> De: "Jean-Baptiste Holcroft" 

> J'ai écrit une proposition "godasse" pour OpenStreeetBugs, n'hésitez pas à 
> enrichir. 
> - http://wiki.openstreetmap.org/wiki/FR:Project_of_the_month/OpenStreetBugs 

Salut,

En cliquant sur le lien j obtiens une page wiki vide indiquant qu elle ne 
contient pas de texte

> A la fin il y a la possibilité de faire des statistiques, mais je ne sais pas 
> extraire les statistiques française depuis les fichiers SQL quotidien, la 
> ville la plus proche est
> systématiquement indiqué et le code [FR] est présent, cela devrait être 
> facile. 

Si les personnes effectuant des corrections le font dans des changesets dedies 
et ajoutent un tag particulier ( a definir ) sur leurs changesets ou dans le 
commentaire du changesets je pourrais extraire des stats

Julien

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

Re: [OSM-talk-fr] Opensnowmap.org

[David Crochet]

Bonjour

Le 04/04/2013 21:33, yvecai a écrit :

Chers ami et béta-testeurs préférés,
Je vous remerci d'avance de cliquer sur le lien ci-dessous et d'aller 
voir dans les coins si tout est comme il faut.


Est-ce un bug ou une mal interprétation des étiquettes :
Super-Besse

Les pistes de ski sont étiquetées de 2 façons (comme les cours d'eau) : 
le chemin qui définit la piste, mais une zone qui définit l'emplacement 
de surface que prend la piste.


Or, Opensnowmap intégre les zones comme étant une piste.

l'étiquette snow_park dessine bien une zone concernant l'emprise du parc.

Il faudrait peut-être que les zones définies par les étiquettes area=yes 
associé à piste:type=donwhill désinnent une zone de couleur lié à 
l'étiquette piste:difficulty sur la carte et non un trait


Cordialement

--
David Crochet


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

Re: [OSM-talk-fr] Compteur électrique

[François Lacombe]

Bonjour,

Il y a actuellement deux propositions en cours de construction sur le Wiki
concernant ce genre d'item. Je vous invite à les consulter et à prendre
part aux échanges si vous pensez pouvoir proposer un tel ajout dans l'une
d'entre-elles.

La 1ere concerne le transport de l'électricité, de la production au
consommateur et donc sur des réseaux en partie basse tension munis de
compteurs (pouvant symboliser la toute fin de la chaine).
http://wiki.openstreetmap.org/wiki/Proposed_features/Power_transmission_refinement

La 2nde est orientée poste de transformation, dont le "street-level" avec
les armoires de répartition pouvant contenir des compteurs.
http://wiki.openstreetmap.org/wiki/Proposed_features/Substation_refinement


Une petite question: qu'est-ce qui pourrait différencier le compteur d'un
bâtiment municipal et celui d'une emprise privée?


Bonne journée.



Le 5 avril 2013 10:14, Tony Emery  a écrit :

> Ista Pouss wrote
> > Je ne comprends pas. Vous voulez situer tous les compteurs électriques de
> > toutes les maisons ??
>
> Non, ouf!! ceux qui concernent des bâtiments municipaux
>
>
>
> --
> View this message in context:
> http://gis.19327.n5.nabble.com/Compteur-electrique-tp5755843p5755847.html
> Sent from the France mailing list archive at Nabble.com.
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>



-- 
*François Lacombe*

francois dot lacombe At telecom-bretagne dot eu
http://www.infos-reseaux.com
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] expérimentations à Orange

[Ista Pouss]

Le 5 avril 2013 12:27, kimaidou  a écrit :

> Pieren,
>
> Je plussoie ! On parle d'opendata, mais cette base unifiée dont tu parles,
> en ODBL, avec une api sympa pour y accéder, ce serait l'idéal !
>
>
> Le 5 avril 2013 11:54, Pieren  a écrit :
>
>>
>> 2013/4/5 Tony Emery 
>>
>>> Après, on ne peut pas parler de simplification administrative puisqu'il
>>> ne
>>> s'agit pas de la même institution.
>>>
>>
>> Il y a aussi le serpent de mer de la base adresse unifiée. Parce que pour
>> l'instant, chaque institution construit la sienne à grands frais (enfin,
>> surtout aux frais des contribuables et des usagers).
>> Mon rêve : une base adresse unifiée, publique, réutilisable librement et
>> avec un code de voie vraiment "unique" adoptée par toutes les institutions.
>> Vous avez dit "trop simple" ?
>>
>>
Je n'y crois pas du tout. Peut être est-ce bon pour l'Administration, mais
il est sûr que c'est mauvais pour la géographie, et il n'est pas clair que
ce soit bon pour la cartographie. Quand à savoir si c'est bon pour
l'humain...

Que l'Administration n'y arrive même pas, alors que ça parait si "trop
simple", devrait donner quelques doutes sur l'idée... mais pour les
certitudes il est plus facile d'invoquer la lourdeur administrative,
j'admets.

Quelques éléments de doute ?... comment une adresse est-elle en rapport
avec une voie ? comment se fait la synchronisation personne-adresse-voie ?
et j'en passe.

En informatique, si les identifiants uniques restent un outil majeur, les
identifiants par rapport à un contexte, une identité, et quelques fois à un
ordre, gagnent de plus en plus de terrain, c'est pas pour des prunes. XML
Schéma, par exemple, les définit ainsi, contredisant (reculant, dirais-tu ?
) le système des DTD qui définissait les identifiants de façon absolue.
C'est pas pour se faire plaisir, mais parce que dans un contexte hétérogène
les identifiants uniques ça coince très vite.

(à mais oui c'est vrai que XML c'est looouuud)

OSM, je crois, est trop centré "administration française". C'est pour ça
qu'on croit voir sur le terrain tant de "objets" qui pourraient avoir un
identifiant unique... et que, finalement, on ne sache même pas si une
clairière est un "trou" ou un "objet" qui ferait ou non partie de la forêt.

Que la collaboration avec l'administration aide à se valoriser, à
travailler, à faire son mai 68 open data est une chose. Mais qu'on se mette
à donner des leçons à cet administration en est une autre. Et que l'on
comprenne comment est-ce que l'on peut rendre compte du terrain sur une
carte, encore une autre. Pour ça les questions d'identités, non les
numéros, sont The Good Way To Do May Be.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] cadastre.openstreetmap.fr HS

[Francescu GAROBY]

+ 1000
D'autant que j'ai une formation à Josm ce soir (à 19h) et que j'aurais aimé
l'avoir, pour expliquer l'import cadastral.

Francescu


Le 5 avril 2013 11:17, Nicolas Dumoulin <
nicolas_openstreetmap@dumoulin63.net> a écrit :

> Le vendredi 5 avril 2013 11:14:12 Nicolas Moyroud a écrit :
> > Des nouvelles concernant le retour de cadastre.openstreetmap.fr ?
> > C'est pas que je suis en manque, mais presque... ;-)
>
> +1
> J'ai la flemme de construire les fichiers moi-même, et j'aimerai mettre à
> jour
> mon coin.
>
> --
> Nicolas Dumoulin
> http://wiki.openstreetmap.org/wiki/User:NicolasDumoulin
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>



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

Re: [OSM-talk-fr] cadastre.openstreetmap.fr HS

[Emmanuel Lesouef]

Le Fri, 5 Apr 2013 14:26:29 +0200,
Francescu GAROBY  a écrit :

> + 1000
> D'autant que j'ai une formation à Josm ce soir (à 19h) et que
> j'aurais aimé l'avoir, pour expliquer l'import cadastral.
> 
> Francescu

+1001
J'assiste à cette formation :)

-- 
Emmanuel Lesouef
http://ecozac.louvigny.free.fr


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

Re: [OSM-talk-fr] Compteur électrique

[Tony Emery]

François Lacombe wrote
> Une petite question: qu'est-ce qui pourrait différencier le compteur d'un
> bâtiment municipal et celui d'une emprise privée?

Si c'est l'angle de la saisie, l'idée que nous avons est de localiser tous
les compteurs électriques des bâtiments publics municipaux et pour lesquels
nous avons une liste.

Si c'est l'angle du compteur lui-même, je n'ai aucune idée de la différence
entre le compteur d'un bâtiment public et celui d'un particulier ou d'une
entreprise.



--
View this message in context: 
http://gis.19327.n5.nabble.com/Compteur-electrique-tp5755843p5755891.html
Sent from the France mailing list archive at Nabble.com.

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

Re: [OSM-talk-fr] expérimentations à Orange

[Pieren]

2013/4/5 Ista Pouss 

>
> Que la collaboration avec l'administration aide à se valoriser, à
> travailler, à faire son mai 68 open data est une chose. Mais qu'on se mette
> à donner des leçons à cet administration en est une autre.
>
>
Quand je parle de serpent de mer, c'est au sein même de l'administration.
Un peu de lecture s'impose:
http://www.afigeo.asso.fr/documentation/category/12.html?download=463%3Aafigeo-gt-adresse-rapport-2011

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

Re: [OSM-talk-fr] Rendu topo 25000ème - réponses multiples

[Philippe Verdy]

Le 5 avril 2013 09:18, JB  a écrit :
> Voici deux essais de diminution de la visibilité des tunnels ferroviaires.
> J'ai tendance à préférer le plus discret des deux. Et vous ?
>
> http://osm107.openstreetmap.fr/jbtopo/tunnel1.png
> http://osm107.openstreetmap.fr/jbtopo/tunnel.png , plus discret

> (oui, je sais, la voie ferrée est encore au dessus. Les courbes de niveau
> aussi, d'ailleurs)

La trop grande discrétion pourrait rendre la distinction du tunnel
moins visible au opint de faire croire que c'est encore une voie de
surface (surtout quand elle traverse des zones "multicolores".

Ceci dit le rendu sous forme de barres alternées noires et blanches
fait plutôt penser à une voie en construction ou qui n'est plus en
état et fermée.

Concernant les lignes de niveau ce n'est pas aberrant de les afficher
par dessus puisque le tunnel passe justement sous la durface
représentée par les lignes de niveau.

Mais cela voudrait dire faire un rendu des tunnels (routiers ou
ferroviaires) dans une couche séparée, après le remplissage des
terrains et rivières dans tous les cas, mais avant les lignes de
niveau pour les parties en tunnel, puis les lignes de niveau, puis les
constructions, puis les routes et voies ferrées hors tunnel, puis les
icônes et libellés.

Le découpage et le tri des couches (y compris avec la combinaison du
tag "layer=*" est une étape délicate d'autant plus que les lignes de
niveau ne viennent pas d'OSM et n'ont pas de "layer" assignable et se
mélangent au layer=0 avec les autres objets OSM sans layer=*).

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

Re: [OSM-talk-fr] expérimentations à Orange

[Christian Quest]

Le sujet des adresses est revenu à de très nombreuses fois durant les
rencontres de l'Afigéo à Bordeaux (qui se terminent ce soir). Hier,
l'IGN a signé à ce sujet un partenariat avec PIGMA, la plateforme
d'échange d'infos géographiques d'Aquitaine.

Il y a aussi beaucoup d'infos à récupérer de la DGFiP car les adresses
figurent dans le cadastre vectoriel et de ce côté, il est bien
possible qu'on ai accès à court terme à diverses données vectorielles
du cadastre dans leur format d'origine (donc récupération de la voirie
et des adresses, voire de quelques POI ou même des parcelles ce qui
permet d'affiner les landuse).

-- 
Christian Quest - OpenStreetMap France
Synthèse du Week-end "SOTM-FR" à Lyon : http://openstreetmap.fr/synthese-sotmfr

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

Re: [OSM-talk-fr] cadastre.openstreetmap.fr HS

[Nicolas Moyroud]

Ma question de ce matin n'était pas désintéressée parce que je vais moi 
aussi proposer une formation à JOSM avec ajout du bâti depuis le 
cadastre dans le cadre du groupe OSM local-herault. Mais bon c'est le 24 
avril donc d'ici là j'ai bon espoir que ça remarche. :-)


Nicolas

Le 05/04/2013 14:35, Emmanuel Lesouef a écrit :

+1001 J'assiste à cette formation :)



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

Re: [OSM-talk-fr] Proposition pour le projet du mois de avril

[Jean-Baptiste Holcroft]

ça doit être un bug de rafraichissement de cache ou une histoire de droits

La page en question :
http://wiki.openstreetmap.org/w/index.php?title=FR:Project_of_the_month/OpenStreetBugs&oldid=888606

Une autre modification qui n'est pas passée en cache :
http://wiki.openstreetmap.org/w/index.php?title=FR:Project_of_the_month&action=history

Ou alors faut-il des autorisations particulières pour modifier les pages ?

Concernant les statistiques, on peu récupérer des fichiers SQL à cet
adresse : http://openstreetbugs.schokokeks.org/dumps/
Dans cette export, il y a clairement indiqué la ville et le pays, les dates
d'ouvertures et de fermeture.
Est-ce que cela suffit ?
--
Jean-Baptiste Holcroft


Le 5 avril 2013 12:45,  a écrit :

> > De: "Jean-Baptiste Holcroft" 
>
> > J'ai écrit une proposition "godasse" pour OpenStreeetBugs, n'hésitez pas
> à enrichir.
> > -
> http://wiki.openstreetmap.org/wiki/FR:Project_of_the_month/OpenStreetBugs
>
> Salut,
>
> En cliquant sur le lien j obtiens une page wiki vide indiquant qu elle ne
> contient pas de texte
>
> > A la fin il y a la possibilité de faire des statistiques, mais je ne
> sais pas extraire les statistiques française depuis les fichiers SQL
> quotidien, la ville la plus proche est
> > systématiquement indiqué et le code [FR] est présent, cela devrait être
> facile.
>
> Si les personnes effectuant des corrections le font dans des changesets
> dedies et ajoutent un tag particulier ( a definir ) sur leurs changesets ou
> dans le commentaire du changesets je pourrais extraire des stats
>
> Julien
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] expérimentations à Orange

[Tony Emery]

Pieren wrote
> Il y a aussi le serpent de mer de la base adresse unifiée. Parce que pour
> l'instant, chaque institution construit la sienne à grands frais (enfin,
> surtout aux frais des contribuables et des usagers).
> Mon rêve : une base adresse unifiée, publique, réutilisable librement et
> avec un code de voie vraiment "unique" adoptée par toutes les
> institutions.
> Vous avez dit "trop simple" ?

Je vais essayer d'être concis...

Effectivement, je ne suis pas d'accord avec ça et pour plusieurs raisons :
- une commune n'est pas l'administration française mais est une
*collectivité locale autonome*. A moins d'accord particulier, rien de permet
de croire que 2 communes puissent travailler de la même manière, qu'elles
soient voisines ou, pire encore, aux quatre coins de la France.
- Les communes ont des *moyens financiers et humains* très différents. Si
les grandes villes et les villes moyennes ont les compétences internes pour
gérer la voirie en référentiel unique, ce n'est pas forcément le cas pour
les petites villes et certainement pas le cas pour les 30.000 communes de
moins de 1.000 habitants (à vue de nez).
- Vous me direz, il y a les intercommunalités. Ce ne sont pas des
collectivités locales et n'ont aucun contrôle sur les communes de son
territoire. Elles n'ont pas forcément comme compétence la gestion de la
voirie et, si c'est le cas, cela ne concerne en général que la voirie dite
"communautaire". La compétence voirie reste donc *essentiellement une
compétence communale*.

Là, je ne parle que de l'aspect création d'une base unique. Il reste le
problème de la maintenance de cette base unique. Et, là encore, la commune
est la source unique de l'information.
C'est bien pour tout cela que je parle de *référencement interne à la
commune de la voirie*. 

Croyez-moi, le sujet est loin d'être aussi simple. Il est complexe (pas
compliqué) mais c'est pour cela qu'il est intéressant...



--
View this message in context: 
http://gis.19327.n5.nabble.com/experimentations-a-Orange-tp5755270p5755899.html
Sent from the France mailing list archive at Nabble.com.

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

Re: [OSM-talk-fr] expérimentations à Orange

[Tony Emery]

cquest wrote
> Il y a aussi beaucoup d'infos à récupérer de la DGFiP car les adresses
> figurent dans le cadastre vectoriel et de ce côté, il est bien possible
> qu'on ai accès à court terme à diverses données vectorielles du cadastre
> dans leur format d'origine (donc récupération de la voirie et des
> adresses, voire de quelques POI ou même des parcelles ce qui permet
> d'affiner les landuse).

Attention, il n'existe pas de données graphiques concernant la voirie dans
le cadastre de la DGFiP. Il s'agit, en fait, d'une couche d'étiquettes du
nom des voies qui sont positionnées dans les espaces entre les parcelles. Au
mieux, il y a une couche d'habillage qui correspond (pas toujours) aux
bordures de trottoir...



--
View this message in context: 
http://gis.19327.n5.nabble.com/experimentations-a-Orange-tp5755270p5755901.html
Sent from the France mailing list archive at Nabble.com.

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

Re: [OSM-talk-fr] Proposition pour le projet du mois de avril

[thevenon . julien]

> De: "Jean-Baptiste Holcroft" 

> ça doit être un bug de rafraichissement de cache ou une histoire de droits 

> La page en question : 
> http://wiki.openstreetmap.org/w/index.php?title=FR:Project_of_the_month/OpenStreetBugs&oldid=888606
>  

Avec ce lien c est bon j ai l acces

> Concernant les statistiques, on peu récupérer des fichiers SQL à cet adresse 
> : http://openstreetbugs.schokokeks.org/dumps/ 
> Dans cette export, il y a clairement indiqué la ville et le pays, les dates 
> d'ouvertures et de fermeture. 
> Est-ce que cela suffit ? 

En fait je pensais faire directement des stats par l analyse des diffs OSM 
comme pour le projet du mois Wikipedia
Cela permet de savoir combien d utilisateurs se sont impliques dans le 
projet,faire un classement le nombre d objets OSM modifies, les modifs 
apportees etc

Julien

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

[OSM-talk-fr] Config tile.openstreetmap.fr [était Re: Rafraichissement des tuiles, sur tile.openstreetmap.fr]

[Marc SIBERT]

Bonjour,

Je squatte ce fil pour savoir comment est configuré cet ensemble. J'ai
suivi la pres avec attention à SOTM-FR, mais je n'ai pas gardé souvenir
d'info sur la config.

Un howto récent quelque part ?

A+

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

[OSM-talk-fr] fiabilité des codes postaux sur Nominatim pour la géolocalisation inverse d'adresses

[Philippe Verdy]

Pour l'instant en France on a privilégié la saisie dans OSM des codes
postaux au niveau des noeuds, parfois des relations administratives
(mais par pour les communes à codes postaux multiples).

Mais on a un problème : la principale utilisation des codes postaux
est pour servir de source à la géolocalisation des adresses dans
Nominatim. Mais Nominatim a depuis longtemps des tonnes de problèmes
avec la gestion des codes postaux : une fois qu'un codes postal y a
été injecté, il ne disparaît plus jamais (Nominatim garde un noueud
même s'il n'est plus attaché à **aucun** objet OSM, parce qu'il a été
saisi par erreur et supprimé, ou parce que le code a depuis été
corrigé (erreur sur un chiffre).

[Il y a un problème annexe (mais pas insurmontable) concernant la
recherche des adresses dans Nominatim contenant des codes postaux mais
non reconnus comme tel (par exemple les adresses contenant un préfixe
de pays comme "F-35000 Rennes" au lieu de "35000 Rennes, France", qui
font échouer la recherche des adresses). Le solution n'est pas dans la
base Nominatim elle-même mais dans la préparation des adresses à
géolocaliser avant d'interroger Nominatim.]

Mais le plus gênant reste que Nominatim est largement pollué dans sa
**propre** base par des codes postaux faux jamais corrigé, car il
garde tout. Quand on regarde les résultats d'une recherche Nominatim
contenant un code postal faux, on se rend compte qu'il a garé et
continue de référencer un de ses propres noeuds "place" qui n'est plus
attaché à **aucun** objet OSM.

Même si on a corrigé dans OSM avec une autre valeur ou avec des
polygones englobants (dans une relation administrative par exemple, ou
une relation multipolygone créée ad hoc pour les limites des zones
postales), cette donnée n'est visiblement plus prise en compte par
Nominatim qui continue de voir son ancien objet code postal en
priorité sur tout ce qu'on a pu mettre ensuite.

La seule solution actuelle consiste à ouvrir un ticket sur le Trac de
Nominatim afin qu'un adminsitrateur fasse le nettoyage à la main dans
la base Nominatim. Ce qui n'est pas viable, trop long, trop couteux.
Bref tout le monde y renonce. Et petit à petit, la géolocalisation via
Nominatim devient de moins en moins utilisable, des adresses qu'on
pouvait géolocaliser dans le passé ne passent plus à cause de la
survenance inattendue d'un code postal faux à proximité.

Quelle stratégie adopter ? Si Nominatim ne peut plus être utilisé pour
la géolocalisation des adresses, alors comment faire ?
- créer une autre base pour les codes postaux ?
- ne plus saisir les codes postaux dans OSM puisque Nominatim en est
pratiquement le seul utilisateur réel et qu'il en fait absolument
"n"importe quoi" en choisissant ses données "à sa guise"...

Note : ce problème affecte avant tout les codes postaux enregistrés
dans Nominatim sous forme de noeuds. Il est beaucoup moins critique
pour les codes postaux sous forme de polygones, mais visiblement
Nominatim fait une transformation des polygones posaux en créant
*lui-même* un noeud place dans sa base, utilisé à la place du polugone
réel dans OSM, qu'il n'enregistre pas ! Cela peut expliquer pourquoi
Nominatim ajoute des tas de noeuds postaux qu'il ne sait ensuite plus
jamais purger ou corriger pusique jamais attaché à l'objet OSM qui en
était à l'origine (Nominatim est ensuite incpable de détecter les
changements et corrections, que celles-ci étaient dans des noeuds ou
des polygones OSM).

Y a-t-il une réflexion menée pour que Nominatim soit corrigé et pour
rendre les codes postaux enfin utilisables pour la géolocalisation
inverse à partir d'une adresse ?

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

Re: [OSM-talk-fr] expérimentations à Orange

[HELFER Denis]

Damned ! tu aurais des scoops avant la réunion du 9 ?
Gaël, au fait, si tu as des précisions sur le lieu exact du rendez-vous, je 
suis preneur.

Denis

-Message d'origine-
De : Christian Quest [mailto:cqu...@openstreetmap.fr] 
Envoyé : vendredi 5 avril 2013 14:52
À : Discussions sur OSM en français
Objet : Re: [OSM-talk-fr] expérimentations à Orange

Le sujet des adresses est revenu à de très nombreuses fois durant les 
rencontres de l'Afigéo à Bordeaux (qui se terminent ce soir). Hier, l'IGN a 
signé à ce sujet un partenariat avec PIGMA, la plateforme d'échange d'infos 
géographiques d'Aquitaine.

Il y a aussi beaucoup d'infos à récupérer de la DGFiP car les adresses figurent 
dans le cadastre vectoriel et de ce côté, il est bien possible qu'on ai accès à 
court terme à diverses données vectorielles du cadastre dans leur format 
d'origine (donc récupération de la voirie et des adresses, voire de quelques 
POI ou même des parcelles ce qui permet d'affiner les landuse).



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

Re: [OSM-talk-fr] expérimentations à Orange

[Ista Pouss]

Le 5 avril 2013 14:42, Pieren  a écrit :

>
>
> Quand je parle de serpent de mer, c'est au sein même de l'administration.
> Un peu de lecture s'impose:
>
> http://www.afigeo.asso.fr/documentation/category/12.html?download=463%3Aafigeo-gt-adresse-rapport-2011
>
>
Ouais enfin bon merci de ne me donner que 30 pages de lecture sur les
serpents de mer dans l'administration, mais j'ai quelque mal à comprendre,
à la lecture (rapide, excuse moi) de ce document, comment est-ce que l'on
peut en conclure que l'adresse est un problème simple, quand bien même
l'administration est mal foutue.

... et sur mon opinion que OSM est trop orienté administratif, qu'en
penses-tu ? (sans me donner 30 pages de plus à lire).


-- 
Les dérives de rue :
Le papillon d’hiver (le film)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Proposition pour le projet du mois de avril

[Philippe Verdy]

Le 5 avril 2013 14:55, Jean-Baptiste Holcroft  a écrit :
> ça doit être un bug de rafraichissement de cache ou une histoire de droits
>
> La page en question :
> http://wiki.openstreetmap.org/w/index.php?title=FR:Project_of_the_month/OpenStreetBugs&oldid=888606

Une des propositions concerne les limites infracommunales des cantons
dans les communes divisées en fractions cantonales.

Le problème est que souvent on n'a pas de données publiée par la
commune elle-même (ou son EPCI) à ce sujet et que la source est un
texte réglementaire et que cette source est souvent totalement
introuvable (la plupart des communes actuellement non découpées dans
OSM ont eu leur fractionnement cantonal défini il y a fort longtemps
dans d'anciens arrêtés, et que le texte de ces arrêtés n'est même pas
disponible en ligne, on ne retrouve rien par exemple sur Legifrance si
l'arrêté date de 1974 ou d'avant... bon nombre de fractionnement
cantonaux ayant eu lieu lors de la réforme administrative au début de
la 5e république, juste après l'indépendance de l'Algérie à partir de
1962 environ, bon nombre de ces fractionnement ayant eu lieu vers
1962-1968, si on regarde les références fréquemment trouvées aux noms
de ces cantons dans le code Rural, lequel en revanche ne précise
jamais comment ces cantons sont délimités).

On n'a de détails dans LégiFrance (avec la liste exhaustives des rues,
même si parfois elles ont pu changer de nom, ce qui n'est pas
insoluble) que pour les arrêtés publiés après 1974, mais très rarement
ceux publiés avant. Hors de Légifrance, toutes les recherches dans les
archives du JORF échouent aussi avant 1974 (environ).

Bref si on n'a pas d'info en ligne, malgré la demande pourtant
effectuée officiellement il y a quelques mois par le Sénat qui voulait
obtenir une liste exhaustive des cantons français, une liste qui est
sans doute parue dans un obscur rapport parlementaire dont on sait
qu'il a existé mais dont le ne parviens pas à trouver l'annexe
contenant le tableau détaillé. Pourtant cette liste devrrait faire
partie intégrante du Code électoral (lequel ne fait QUE lister les
cantons, sans pratiquement jamais les détailler concernant les
fractionnements de communes)

L'Insee elle-même est visiblement incapable de fournir ces données
(d'où pour les communes découpées en fractions cantonales, la
représentation des cantons concernés en excluant la commune découpée
de ces cantons, et en ajoutant un pseudo-canton-ou-ville pour la
commune elle-même).

Comment faire alors dans OSM ? Pourrait-on adopter la solution
actuelle de l'Insee, en fermant au moins les cantons en incluant les
parties de cantons hors des communes fractionnées, quitte à laisser un
trou hors de tout canton OSM pour la commune découpée dont on n'a
aucune idée du fractionnement cantonal ?

Faudra-t-il une 'task force" OSM pour aller consulter et scanner les
anciennes archives préfectorales ? Doit-on plutôt interroger chaque
commune une par une pour lui demander de retrouver copie du texte
du/des arrêté(s) ayant conduit à leur découpage cantonal ?

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

Re: [OSM-talk-fr] expérimentations à Orange

[Philippe Verdy]

Le 5 avril 2013 14:58, Tony Emery  a écrit :
> problème de la maintenance de cette base unique. Et, là encore, la commune
> est la source unique de l'information.

C'est peut-être vrai pour les communes de taille raisonnable (disons
au moins 1500 habitants), mais aujourd'hui plus aucune des plus
petites communes rurales n'a les moyens ni la compétence de maintenir
seule ces données.

Et que pour des raisons pratiques évidentes, elles ont fait gérer leur
SIG depuis longtemps par des tiers (peut-être au départ via des
prestataires privés intervenant sur de nombreuses autres communes),
mais aujourd'hui plus souvent par l'EPCI dont elles sont membres (même
si l'EPCI peut ausssi faire appel à des prestataires externes, au
moins l'EPCI dispose de son SIG et a un accès directe et on contrôle
des données qui sont dedans).

Il me semble que de plus en plus la source des infos et leur
maintenance a été transférée aux EPCI qui disposent de plus de moyens
(et de personnels) avec au passage des économies d'échelle en terme de
coût. Et qu'en fin de compte il ne reste que les communes de taille
suffisante, avec des budgets suffisants (en hausse constante), à
encore gérer elles-mêmes leur propre SIG : ces communes seront de
moins en moins nombreuses et même si elles conservent encore un SIG,
une bonne partie de leur données seront toute de même transférées pour
être gérées par l'EPCI (même si la commune fournit de temps en temps
des données et y a un accès continu en cas de besoin).

C'est à l'occasion de ces transferts vers l'EPCI que des travaux
d'uniformisation sont entrepris, et qu'au passage les EPCI se
concertent aussi entre eux pour évaluer les solutions choisies (les
EPXI aussi veulent faire des économies d'échelle et n'ont probablement
pas envie de développer des solutions totalement propriétaires
incompatibles avec ce que font les autres). Au delà de ça, il y a
aussi les SIG des départements et régions qui eux aussi proposent
leurs solutions d'intégration.

Certes il n'y a pas encore d'uniformisation au plan national (avec des
agences partenaires au plan national comme l'Insee ou l'IGN, ou
interrégionales comme les agences de bassin, parfois aussi des agences
européennes ou des structures de coopération transfrontalières,
notamment pour les transports, l'environnement et le développement
touristique ou économique), mais on doit constater tout de même une
convergence progressive entre les différents modèles de représentation
des données entre les différents niveaux territoriaux jusqu'à l'Etat
lui-même, même si certaines agences ont des besoins spécifiques
supplémentaires qui sortent du cadre actuel des tentatives
d'uniformisation/normalisation, faute d'avoir d'autres acteurs
intéressés pour maintenir ces données spécifiques.

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

Re: [OSM-talk-fr] Proposition pour le projet du mois de avril

[Francescu GAROBY]

De toute façon, pour le découpage des cantons, je recommande vivement
d'attendre !
Une loi, actuellement à l'étude au Parlement, envisage de revoir en
profondeur le fonctionnement des conseils généraux (renommés conseils
départementaux) et, c'est ce point qui concerne OSM, de diviser par 2 le
nombre total de cantons.
Et comme il y a fort à parier qu'il n'y aura pas simplement une fusion de
cantons limitrophes pour arriver à cette division par 2, mais un
redécoupage complet (entre autre pour des raisons démographiques), je
réitère mon propos : il est urgent d'attendre, sous peine de se taper un
gros boulot qui sera rendu inutile dans les prochains mois.

De plus, ce redécoupage complet entrainera la publication (au JO) des
nouvelles limites de cantons : nous aurons alors une source fiable,
complète et récente.

Francescu


Le 5 avril 2013 15:34, Philippe Verdy  a écrit :

> Le 5 avril 2013 14:55, Jean-Baptiste Holcroft  a
> écrit :
> > ça doit être un bug de rafraichissement de cache ou une histoire de
> droits
> >
> > La page en question :
> >
> http://wiki.openstreetmap.org/w/index.php?title=FR:Project_of_the_month/OpenStreetBugs&oldid=888606
>
> Une des propositions concerne les limites infracommunales des cantons
> dans les communes divisées en fractions cantonales.
>
> Le problème est que souvent on n'a pas de données publiée par la
> commune elle-même (ou son EPCI) à ce sujet et que la source est un
> texte réglementaire et que cette source est souvent totalement
> introuvable (la plupart des communes actuellement non découpées dans
> OSM ont eu leur fractionnement cantonal défini il y a fort longtemps
> dans d'anciens arrêtés, et que le texte de ces arrêtés n'est même pas
> disponible en ligne, on ne retrouve rien par exemple sur Legifrance si
> l'arrêté date de 1974 ou d'avant... bon nombre de fractionnement
> cantonaux ayant eu lieu lors de la réforme administrative au début de
> la 5e république, juste après l'indépendance de l'Algérie à partir de
> 1962 environ, bon nombre de ces fractionnement ayant eu lieu vers
> 1962-1968, si on regarde les références fréquemment trouvées aux noms
> de ces cantons dans le code Rural, lequel en revanche ne précise
> jamais comment ces cantons sont délimités).
>
> On n'a de détails dans LégiFrance (avec la liste exhaustives des rues,
> même si parfois elles ont pu changer de nom, ce qui n'est pas
> insoluble) que pour les arrêtés publiés après 1974, mais très rarement
> ceux publiés avant. Hors de Légifrance, toutes les recherches dans les
> archives du JORF échouent aussi avant 1974 (environ).
>
> Bref si on n'a pas d'info en ligne, malgré la demande pourtant
> effectuée officiellement il y a quelques mois par le Sénat qui voulait
> obtenir une liste exhaustive des cantons français, une liste qui est
> sans doute parue dans un obscur rapport parlementaire dont on sait
> qu'il a existé mais dont le ne parviens pas à trouver l'annexe
> contenant le tableau détaillé. Pourtant cette liste devrrait faire
> partie intégrante du Code électoral (lequel ne fait QUE lister les
> cantons, sans pratiquement jamais les détailler concernant les
> fractionnements de communes)
>
> L'Insee elle-même est visiblement incapable de fournir ces données
> (d'où pour les communes découpées en fractions cantonales, la
> représentation des cantons concernés en excluant la commune découpée
> de ces cantons, et en ajoutant un pseudo-canton-ou-ville pour la
> commune elle-même).
>
> Comment faire alors dans OSM ? Pourrait-on adopter la solution
> actuelle de l'Insee, en fermant au moins les cantons en incluant les
> parties de cantons hors des communes fractionnées, quitte à laisser un
> trou hors de tout canton OSM pour la commune découpée dont on n'a
> aucune idée du fractionnement cantonal ?
>
> Faudra-t-il une 'task force" OSM pour aller consulter et scanner les
> anciennes archives préfectorales ? Doit-on plutôt interroger chaque
> commune une par une pour lui demander de retrouver copie du texte
> du/des arrêté(s) ayant conduit à leur découpage cantonal ?
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>



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

Re: [OSM-talk-fr] Proposition pour le projet du mois de avril

[Philippe Verdy]

Le 5 avril 2013 16:09, Francescu GAROBY  a écrit :
> De toute façon, pour le découpage des cantons, je recommande vivement
> d'attendre !
> Une loi, actuellement à l'étude au Parlement, envisage de revoir en
> profondeur le fonctionnement des conseils généraux (renommés conseils
> départementaux) et, c'est ce point qui concerne OSM, de diviser par 2 le
> nombre total de cantons.

Ce ne pourra pas être un changement radical, car les cantons ne
servent pas qu'aux élections et sont **très** fréquemment référencés
dans le Code rural.

L'échelle de base utilisée est alors souvent celle utilisée par
l'Insee (avec ses "cantons-ou-villes") ce qui justifierait alors de
saisir dans OSM ces cantons-ou-villes de façon exhaustive dans OSM,
même si cela implqiue des ambiguités au plan purement électoral des
conseils généraux.

Déjà on commence à discuter des limites des bureaux de vote dans les
communes (mais cela demandera baucoup d'efforts aussi, et on ne doit
pas se contenter "d'attendre").

La loi dont tu parles est envoyées aux calendes grecques : les travaux
initiés par Sarkozy avec la volonté de réformer les "conseillers
territoriaux" ont été rejetés, et depuis longtemps (depuis le début de
le Ve république en fait et même avant depuis l'Empire), les questions
relatives au découpage électoral (révisé pratiquement à chaque
législature ou changement de gouvernement, et toujours avec des
protestations des groupes parmentaires d'opposition qui y voient des
intentions de manipulations électoralistes) ont toujours été
épineuses.

Derrière cette réforme il y a aussi les questions relatives au mode de
scrutin (plus ou moins de proportionnel par exemple). Mais que même
dans ce cas, si les cantons sont mal connus et manipulés au plan
électoral, leur omniprésence dans les textes réglementaires (notamment
dans le code Rural et de l'environnement, par exemple dans les arrêtés
de catastrophe naturelle, la prévention des risques, la protection de
l'environnement) interdit des changements radicaux : même si les
conseillers territoriaux sont réformés, les cantons persisteront (même
si le fractionnement cantonal des communes disparaît pour aller
davantage vers la solution actuelle de l'Insee avec ses
"villes-ou-cantons").

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

Re: [OSM-talk-fr] Proposition pour le projet du mois de avril

[Francescu GAROBY]

Je parlais des conseillers départementaux (réforme Hollande), et non des
conseilles territoriaux (réforme Sarkozy rejetée par l'actuelle majorité).
Et non, la loi dont je parle n'a pas été rejetée aux calendes grecques. Je
t'invite à consulter l'historique de ce projet de loi, clairement expliqué
sur le site officiel du Sénat :
http://www.senat.fr/dossier-legislatif/pjl12-166.html
(mais il est cependant vrai que la commission mixte paritaire a tout
récemment indiqué "ne pouvoir parvenir à élaborer un texte commun". Ce qui
ne signifie pas pour autant un rejet aux calendes grecques).

Bref, en attendant d'en savoir plus, et parce que les limites officielles
de cantons sont toujours introuvables, je maintiens ma proposition de ne
pas retenir cela comme projet du mois : il y a bien d'autres sujets plus
prêts à être traités.

Francescu



Le 5 avril 2013 16:23, Philippe Verdy  a écrit :

> Le 5 avril 2013 16:09, Francescu GAROBY  a écrit :
> > De toute façon, pour le découpage des cantons, je recommande vivement
> > d'attendre !
> > Une loi, actuellement à l'étude au Parlement, envisage de revoir en
> > profondeur le fonctionnement des conseils généraux (renommés conseils
> > départementaux) et, c'est ce point qui concerne OSM, de diviser par 2 le
> > nombre total de cantons.
>
> Ce ne pourra pas être un changement radical, car les cantons ne
> servent pas qu'aux élections et sont **très** fréquemment référencés
> dans le Code rural.
>
> L'échelle de base utilisée est alors souvent celle utilisée par
> l'Insee (avec ses "cantons-ou-villes") ce qui justifierait alors de
> saisir dans OSM ces cantons-ou-villes de façon exhaustive dans OSM,
> même si cela implqiue des ambiguités au plan purement électoral des
> conseils généraux.
>
> Déjà on commence à discuter des limites des bureaux de vote dans les
> communes (mais cela demandera baucoup d'efforts aussi, et on ne doit
> pas se contenter "d'attendre").
>
> La loi dont tu parles est envoyées aux calendes grecques : les travaux
> initiés par Sarkozy avec la volonté de réformer les "conseillers
> territoriaux" ont été rejetés, et depuis longtemps (depuis le début de
> le Ve république en fait et même avant depuis l'Empire), les questions
> relatives au découpage électoral (révisé pratiquement à chaque
> législature ou changement de gouvernement, et toujours avec des
> protestations des groupes parmentaires d'opposition qui y voient des
> intentions de manipulations électoralistes) ont toujours été
> épineuses.
>
> Derrière cette réforme il y a aussi les questions relatives au mode de
> scrutin (plus ou moins de proportionnel par exemple). Mais que même
> dans ce cas, si les cantons sont mal connus et manipulés au plan
> électoral, leur omniprésence dans les textes réglementaires (notamment
> dans le code Rural et de l'environnement, par exemple dans les arrêtés
> de catastrophe naturelle, la prévention des risques, la protection de
> l'environnement) interdit des changements radicaux : même si les
> conseillers territoriaux sont réformés, les cantons persisteront (même
> si le fractionnement cantonal des communes disparaît pour aller
> davantage vers la solution actuelle de l'Insee avec ses
> "villes-ou-cantons").
>



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

Re: [OSM-talk-fr] Compteur électrique

[Tetsuo Shima]

"nous avons une listes"

Tu travailles pour une municipalité? tu souhaites faire une carte pour
faciliter le travail des agent techniques de la municipalité? si oui il y a
moyen d'éviter de rajouter des infos dans la base OSM tout en superposants
sur un fond de carte OSM ...


Le 5 avril 2013 14:36, Tony Emery  a écrit :

> François Lacombe wrote
> > Une petite question: qu'est-ce qui pourrait différencier le compteur d'un
> > bâtiment municipal et celui d'une emprise privée?
>
> Si c'est l'angle de la saisie, l'idée que nous avons est de localiser tous
> les compteurs électriques des bâtiments publics municipaux et pour lesquels
> nous avons une liste.
>
> Si c'est l'angle du compteur lui-même, je n'ai aucune idée de la différence
> entre le compteur d'un bâtiment public et celui d'un particulier ou d'une
> entreprise.
>
>
>
> --
> View this message in context:
> http://gis.19327.n5.nabble.com/Compteur-electrique-tp5755843p5755891.html
> Sent from the France mailing list archive at Nabble.com.
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Proposition pour le projet du mois de avril

[Philippe Verdy]

Je serais partant pour compléter les cantons selon la définition
actuelel de l'Insee, étant donné la quantité impressionnante de textes
légaux ou réglementaires qui y con t référence.

Autrement dit : créer des cantons "incomplets" excluant les communes
fractionnées, pour aller jusqu'au même niveau que la brique de base
clairement définie par l'Insee, et stable.

Les questions relatives au code électoral lui-même et son utilisation
du découpage cantonal en revanche mérite qu'on ne s'attarde pas trop
dessus (je suis donc plutôt défavorable à ce qu'on cartographie les
bureaux de vote qui peuvent changer chaque année, après la mise à jour
et la validation légale des listes électorales fermées l'année
précédente, et conduisant à la carte électorale décidée alors pour
être applicable pour les scrutins de l'année suivante).

Dans les communes où on a le détail du fractionnement cantonal, on
garde ce détail (on ne l'a pratiquement que dans les grandes villes
justement parce que leur population électorale a beaucoup changé
régulièrement au point que des cantons ont plus fréquemment été
modifiés et qu'on dispose donc de textes récents, numérisés et
accessibles facilement).

L'échelon Insee "canton-ou-ville" ira très bien partout, et on n'aura
pas besoin d'attendre des années pour faire correspondre alors
l'énorme quantité de textes (surtout réglementaires d'origine
préfectorale). Le jour où il y aura un nouveau texte (on peut attendre
longtemps), on fera les changements nécessaires dans la base. Et cela
permettra malgré tout de dessiner des cartes électorales, m^me si on
ne peut pas détailler sur la carte les communes découpées (mais les
résultats de scrutins sont aussi publiés à l'échelle de la commune).

Pour compléter jusqu'au niveau "canton-ou-ville", on a des données de
référence stables, facilement accessibles, et cela peut marcher dans
le cadre d'un projet du mois (note : je ne demande pas à ce qu'on
supprime les fractions cantonales de communes, là où on les a ; tout
le monde reste tagué comme un "political_divsion=canton", même si on
peut aussi boucher les trous laissés par les communes fractionnées en
ajoutant le même tag "political_division=canton" à la relation de
cette commune, et en laissant de côté le code pseudo-cantonal à 4
chiffres attribué par l'Insee à la commune entière).

Avec cette idée, on a alors une couverture à 100% de la France, qui
n'exclue pas de créer le fractionnement là où on en trouve (et là au
moins on n'est pas obligé d'attendre une réforme de loi dont on n'a
absolument aucune idée si elle aboutira à quelquechose avant
l'échéance des prochaines élections cantonales et régionales qui ont
déjà été repoussées de 2 ans, mais qu'il sera impossible de repousser
une nouvelle fois par un nouvel allongement des mandats électoraux).
Il est fort probable que cette réforme ne soit même pas passée à tant
pour les prochaines élections, et que cela repoussera alors
l'application effective de la réforme du découpage territorial de 6
années de plus.

Sans compter qu'il n'y aura pas réécritue des milliers de pages
d'arrêtés et décrets qui mentionnent ces cantons (pour que les
nouveaux décrets n'y fassent plus référence, il faudrait qu'ils
listent exhaustivement des listes bien plus longues de communes, avec
tous les risques d'oublis, de communes classées deux fois dans des
catégories contradictoires pour les même arrêtés et décrets);

Alors oui les cantons n'ont plus une grande importance sur le terrain
(ils ne sont pas des collectivités) mais leur importance reste encore
très élevée dans une quantité énorme de textes, qu'il n'est pas
question de réécrire et qui mettront des décennies avant d'être
abrogés ou réécrits, et qui très largement utilisent déjà la brique
"canton-ou-ville" de l'Insee, transcrite dans les textes
réglementaires sous une forme telle que:

"- canton d'Amiens-Nord (sauf la commune d'Amiens) ; commune d'Amiens; etc."

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

Re: [OSM-talk-fr] Compteur électrique

[teuxe]

Un "PrintScreen" et un stylo ou marqueur, c'est ça ? :)


- Mail original -
De: "Tetsuo Shima" 
À: "Discussions sur OSM en français" 
Envoyé: Vendredi 5 Avril 2013 17:01:34
Objet: Re: [OSM-talk-fr] Compteur électrique




"nous avons une listes" 

Tu travailles pour une municipalité? tu souhaites faire une carte pour 
faciliter le travail des agent techniques de la municipalité? si oui il y a 
moyen d'éviter de rajouter des infos dans la base OSM tout en superposants sur 
un fond de carte OSM ... 




Le 5 avril 2013 14:36, Tony Emery < tony.em...@yahoo.fr > a écrit : 


François Lacombe wrote 

> Une petite question: qu'est-ce qui pourrait différencier le compteur d'un 
> bâtiment municipal et celui d'une emprise privée? 

Si c'est l'angle de la saisie, l'idée que nous avons est de localiser tous 
les compteurs électriques des bâtiments publics municipaux et pour lesquels 
nous avons une liste. 

Si c'est l'angle du compteur lui-même, je n'ai aucune idée de la différence 
entre le compteur d'un bâtiment public et celui d'un particulier ou d'une 
entreprise. 



-- 
View this message in context: 
http://gis.19327.n5.nabble.com/Compteur-electrique-tp5755843p5755891.html 


Sent from the France mailing list archive at Nabble.com. 

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


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

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

Re: [OSM-talk-fr] expérimentations à Orange

[Pieren]

2013/4/5 Ista Pouss 

>  comment est-ce que l'on peut en conclure que l'adresse est un problème
> simple, quand bien même l'administration est mal foutue.
>

Quand je parle de "simple", c'est par rapport à la simplification
administrative qui ferait qu'une seule autorité serait chargée de maintenir
une base unique. Elle pourrait bien-sûr être abondée par les créateurs
d'adresses (les communes) mais aussi pouvoir être corrigée et améliorée par
les institutions utilisatrices (INSEE, DGFiP, police, la poste, etc). Seule
la partie anonymisée serait publique et réutilisable. La partie nominative
serait plus facilement entretenue si elle était couplée à une obligation
légale de déclaration dominiliaire (se déclarer en mairie lors de
l'installation) comme pratiquement partout ailleurs en Europe.


> ... et sur mon opinion que OSM est trop orienté administratif, qu'en
> penses-tu ?
>

Je suis d'accord. Mes coups de gueule sur les références récurentes au code
INSEE en témoignent. Ou les noms des cantons qui sont aussi les noms des
villes et qu'on retrouve dans les résultas de recherche. Les contributeurs
moyens d'OSM sont trop éloignés de ce vocabulaire. Il faut faire attention
à ne pas se déconnecter du moteur du projet : le contributeur lambda. J'ai
cru comprendre qu'au dernier SOTM-fr, il n'y en avait pratiquement aucun.
C'est un danger qui gu

(sans me donner 30 pages de plus à lire).
>

J'ai bon ?

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

[OSM-talk-fr] Prochaine réunion des contributeurs de la région de Marseille le lundi 8 / 04 / 2013 // 20h00 à La Bo@te.

[Olivier Griffet]

*Bonjour à toutes et à tous.


Je rappel que les contributeurs d' Openstreetmap de la région de Marseille
se réunissent le lundi 8 avril 2013,

à partir de 20h00 à La Bo@te ( dates suivantes en fin de message ).

*
*Avant cette réunion, est proposé par Fabien, une Carto-partie sur le Cours
Honoré d'Estienne d'Orves, rendez-vous dès 19h00 devant l'entrée de Boate.

*
*Détails et compléments d'informations, voir ce lien :
http://listes.openstreetmap.fr/wws/arc/local-marseille/2013-03/msg1.html
*
*


Pour ceux qui compterais participez à la réunion et qui viennent pour la
première fois,

nous avons pour habitude que chacun(e) amène quelque chose à boire et/ou à
grignoter.


Lien du plan de l'accès à La Bo@te :
http://www.openstreetmap.org/?lat=43.29213&lon=5.3730645&zoom=18&layers=M&mlat=43.29210&mlon=5.37297


Lien de la page du Wiki d' Openstreetmap sur les réunions de Marseille :

http://wiki.openstreetmap.org/wiki/Marseille/R%C3%A9unions_2013


Archives de l'année 2012 :

http://wiki.openstreetmap.org/wiki/Marseille/R%C3%A9unions_2012



Pour confirmer votre présence éventuel, vous pouvez répondre à ce message,

merci.


Nota : Calendrier des réunions suivantes pour 2013, même lieu, même horaire.


*
**
*
- lundi 6 mai 2013.
*
*
- lundi 3 juin 2013.
*
*
- lundi 1er juillet 2013.
*
*
- lundi 5 aout 2013.
*
*
- lundi 2 septembre 2013.
*
*
- lundi 7 octobre 2013.
*
*
- lundi 4 novembre 2013.
*
*
- lundi 2 décembre 2013.
*
***


À bientôt...


Amicales salutations.**

Olivier Griffet 

| Contributeur OpenStreetMap =>
http://www.openstreetmap.org/user/olivier_griffet_83660_carnoules  |

| Téléphone (Ligne ADSL) N° 09 61 23 65 40 Répondeur / messagerie |
| Mobile GSM => 07 88 36 87 42 Répondeur / messagerie  |

| Habitant de 
83660-
Carnoules  - Var | Adhérent de GULLIVAR et ToulonuX |

Utilisateur de GNU/LINUX > de Linux Mint 11 [ Gnome ] + (X)Ubuntu 12.04 [
XFCE ] ; Lives USB >> ASRI.EDU.2.1a ; Etc...

Site web de GULLIVAR : http://gullivar.org/

Site web de ToulonuX : http://toulonux.tuxfamily.org/
*
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Opensnowmap.org

[yvecai]

On 04/05/2013 09:01 AM, Fabien wrote:

Par contre, ça fait bizarre d'avoir les skieurs à l'envers sur le
tire-fesses : 
http://www.opensnowmap.org/?zoom=16&lat=45.913&lon=6.58931&layers=&e=false&m=raster

Ah non, je laisse, je trouve ça rigolo :)
Sans blague, je ne sais pas si j 'arriverai à gérer ça avec mapnik ou 
postgis, mais j'essaierai, c'est sûr.


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

Re: [OSM-talk-fr] Opensnowmap.org

[yvecai]

On 04/05/2013 12:56 PM, David Crochet wrote:

Est-ce un bug ou une mal interprétation des étiquettes :
Super-Besse

Les pistes de ski sont étiquetées de 2 façons (comme les cours d'eau) 
: le chemin qui définit la piste, mais une zone qui définit 
l'emplacement de surface que prend la piste.


Alors, c'est pas un bug, ni une mauvaise interprétation, c'est une 
'feature request'.  Je vais regarder ça.


Yves

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

Re: [OSM-talk-fr] Re : Re : Opensnowmap.org

[yvecai]

On 04/05/2013 12:31 PM, Nicolas Dumoulin wrote:

Le vendredi 5 avril 2013 12:19:15 yve...@gmail.com a écrit :

Oui, un retour genre surbrillance au survol de la liste sera sûrement
implanté, mais j'ai pas encore la solution. C'est sur quelle piste ce pb
d'icône?

Sur à peu près toutes les pistes du domaine de Pessade :
http://www.opensnowmap.org/?zoom=15&lat=45.62994&lon=2.87237&layers=&e=false&m=raster
Ben oui, piste:type=nordic n'est pas renseigné sur les *ways*, sur ce 
domaine.



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

Re: [OSM-talk-fr] expérimentations à Orange

[Christian Rogel]

Le 5 avr. 2013 à 17:36, Pieren a écrit :
> ... et sur mon opinion que OSM est trop orienté administratif, qu'en 
> penses-tu ?
> 
> Je suis d'accord. Mes coups de gueule sur les références récurentes au code 
> INSEE en témoignent. Ou les noms des cantons qui sont aussi les noms des 
> villes et qu'on retrouve dans les résultas de recherche. Les contributeurs 
> moyens d'OSM sont trop éloignés de ce vocabulaire. Il faut faire attention à 
> ne pas se déconnecter du moteur du projet : le contributeur lambda. J'ai cru 
> comprendre qu'au dernier SOTM-fr, il n'y en avait pratiquement aucun. 


Je ne sais pas qui est trop orienté administratif, car, il me semble avoir 
parfois, contredit Pieren, sur des points marginaux qui tenaient à
l'acceptation sans contrôle des données de l'administration, dont la réputation 
de cohérence et de logique est parfois usurpée.

Tony faisait le distinguo entre collectivité publique autonome et 
administration de l'Etat.
C'est sur l'anarchie admistrative français qu'il met le doigt :
Les lois qui concernent l'environnement sont uniformes, malgré la diversité des 
climats et des écosystème, et, pourtant, t il semble admissible que les unités 
de
base n'aient pas un minimum de référentiel commun pour des questions qui n'ont 
rien de politique, sinon, d'énormes efforts pour maintenir l'inertie 
et la désorganisation.

Pour ce qui concerne, les références administratives, il est clair qu'il s'agit 
d'un débat qui ne concerne pas le supposé contributeur lambda.
Il peut, éventuellement, être concerné par un alourdissement d ela BDD, mais, 
c'est tout.

Ces références ou référentiels ne peuvent qu'être introduit que mécaniquement.

Le lieu naturel pour trancher, sous la forme d'une recommandation qui deviendra 
vite une norme, est OSM- France, la liste étant un outil pour
faire émerger les questions débroussailler les problèmes et indiquer les voies 
à suivre.

J'ignore ce que Pieren désigne par contributeur lambda. Cela s'oppose à 
contributeur non-lambda.
S'agit-il des codeurs, souvent appelés et inexactement  geeks dans le langage 
courant?
Il me semble que j'en ai rencontré quelques non-codeurs à SOTM-Fr, mais, moi 
qui ne code rien, j'étais content de discuter avec des gens qui
me parlaient de codage, en termes généraux, bien sûr.



Christian R. 

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

Re: [OSM-talk-fr] expérimentations à Orange

[Guillaume Allegre]

Le ven. 05 avril 2013 à 11:34 +0200, Pieren a écrit :
> 2013/4/5 Tony Emery 
> 
> > Par conséquent, ces traçés, même si leur précision
> > n'est pas bonne, est règlementée. Pour info, dans un document d'urbanisme
> > approuvé, si le dessin d'une zone à été mal fait, qu'il coupe une parcelle
> > alors qu'il ne le devrait pas, c'est quand même ce découpage qui est
> > appliqué. Je pense donc, même si ce n'est pas juste, qu'il faut le laisser
> > tel quel si l'on veut que les collectivités s'investissent dans OSM.
> >
> 
> Ce point est capital avec OSM. C'est la violation d'un principe de base du
> projet : les données doivent pouvoir être améliorées par les contributeurs,
> sinon elles n'ont pas leur place dans la base. Aucune donnée ne doit
> pouvoir être bloquée dans OSM sous prétexte d'officialité, encore plus si
> elles sont mauvaises.
> Je renverrais la lecture d'un fil de discussion de référence sur ce thème
> (en anglais) :
> http://lists.openstreetmap.org/pipermail/talk/2009-March/034948.html

Je plussoie entièrement Pieren sur ce point.

OSM ne doit pas devenir un dépôt où les "institutions" accepteraient de
verser leurs données à condition que personne n'y touche. 

OSM c'est du crowdsourcing avant tout ; l'open data est un complèment, 
bienvenu mais pas essentiel.
Il faut qu'on travaille au maximum pour intégrer l'open data dans OSM, mais si
on tombe sur un conflit entre les deux, OSM laissera tomber l'open data et 
privilégiera toujours le crowdsourcing.

Ce point est très important pour les discussions avec les collectivités, et 
il est non négociable, comme la licence.
En un mot : aucune donnée ne doit être verrouillée dans OSM.




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


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

Re: [OSM-talk-fr] expérimentations à Orange

[Guillaume Allegre]

Le jeu. 04 avril 2013 à 23:50 -0700, Tony Emery a écrit :

> En fait, je dois quand même vous alerter sur un points : les collectivité
> sont de plus en plus consciente de l'intérêt de gérer en interne une base
> exhaustive de leur voirie. Or, cela sous-entend de pouvoir identifier chaque
> voie de manière unique dès la création de cette voie, d'où, l'identifiant.
> Qu'avons nous comme identifiant voirie :
> - Rivoli : c'est un code créé et géré par la DGFiP
> - l'ID de la BDAdresse : idem pour l'IGN
> 
> Il faut donc créer un identifiant interne dans la commune car la commune est
> la source de cette information.

Pas la peine de partir dans les rêves de Grande Unification, je pense qu'on
peut en déduire une chose : il faut que le schéma "opendata" utilisé accepte
plusieurs identifiants provenant de plusieurs bases différentes.

Donc, exit le ref:source=, et je ne vois pas d'autre solution que
le ref:FR:=

Je pense qu'on ne pourra pas se passer de l'identifiant DGFiP, puisque c'est 
déjà le référentiel pour les imports de cadastre (et qu'on peut espérer négocier
une seule fois pour toute la France, et pas commune par commune).
Bref, la DGFiP, c'est l'identifiant le plus utile à plus court terme.

Ensuite, rien n'empêche d'ajouter un identifiant par commune participante.

Et puis, dans dix ans, quand l'IGN aura vu la lumière (ou sera morte et 
enterrée) 
on pensera à mettre l'ID de la BDAdresse.


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


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

Re: [OSM-talk-fr] cadastre.openstreetmap.fr HS

[Jocelyn Jaubert]

Le 05/04/2013 14:54, Nicolas Moyroud a écrit :
> Ma question de ce matin n'était pas désintéressée parce que je vais moi
> aussi proposer une formation à JOSM avec ajout du bâti depuis le
> cadastre dans le cadre du groupe OSM local-herault. Mais bon c'est le 24
> avril donc d'ici là j'ai bon espoir que ça remarche. :-)

Puisque vous insistez, j'ai relancé cadastre.openstreetmap.fr
temporairement :)

On va espérer que ça tient plus de quelques jours. D'ici là, j'espère
que les blades seront installés.


-- 
Jocelyn

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

Re: [OSM-talk-fr] Compteur électrique

[François Lacombe]

Quoi qu'il en soit il faudra trouver une manière cohérente de documenter
ces compteurs de puissance.

La nature de ce qui est alimenté derrière importe peu, il y a des
propriétés qui reviennent et qui doivent apparaitent dans un modèle global
intégrable dans OSM.

Si derrière vous voulez intégrer votre jeu de données qui ne concerne d'un
ensemble partiel de compteurs ca n'est pas un problème en soi.


Le 5 avril 2013 17:18,  a écrit :

> Un "PrintScreen" et un stylo ou marqueur, c'est ça ? :)
>
>
> - Mail original -
> De: "Tetsuo Shima" 
> À: "Discussions sur OSM en français" 
> Envoyé: Vendredi 5 Avril 2013 17:01:34
> Objet: Re: [OSM-talk-fr] Compteur électrique
>
>
>
>
> "nous avons une listes"
>
> Tu travailles pour une municipalité? tu souhaites faire une carte pour
> faciliter le travail des agent techniques de la municipalité? si oui il y a
> moyen d'éviter de rajouter des infos dans la base OSM tout en superposants
> sur un fond de carte OSM ...
>
>
>
>
> Le 5 avril 2013 14:36, Tony Emery < tony.em...@yahoo.fr > a écrit :
>
>
> François Lacombe wrote
>
> > Une petite question: qu'est-ce qui pourrait différencier le compteur d'un
> > bâtiment municipal et celui d'une emprise privée?
>
> Si c'est l'angle de la saisie, l'idée que nous avons est de localiser tous
> les compteurs électriques des bâtiments publics municipaux et pour lesquels
> nous avons une liste.
>
> Si c'est l'angle du compteur lui-même, je n'ai aucune idée de la différence
> entre le compteur d'un bâtiment public et celui d'un particulier ou d'une
> entreprise.
>
>
>
> --
> View this message in context:
> http://gis.19327.n5.nabble.com/Compteur-electrique-tp5755843p5755891.html
>
>
> Sent from the France mailing list archive at Nabble.com.
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>



-- 
*François Lacombe*

francois dot lacombe At telecom-bretagne dot eu
http://www.infos-reseaux.com
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Opensnowmap.org

[yvecai]

Alors voilà, c'est fait, je prends en compte area=yes pour 
piste:type=downhill.
Forcément, ca fait un peu des gros patés quand on zoome beaucoup, mais 
c'est comme les forêts: faudra s'habituer à rajouter un point ou deux 
dans les angles trop pointus.


Yves

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

Re: [OSM-talk-fr] Re : Re : Opensnowmap.org

[Nicolas Dumoulin]

Le vendredi 5 avril 2013 18:32:24 yvecai a écrit :
> On 04/05/2013 12:31 PM, Nicolas Dumoulin wrote:
> > Le vendredi 5 avril 2013 12:19:15 yve...@gmail.com a écrit :
> >> Oui, un retour genre surbrillance au survol de la liste sera sûrement
> >> implanté, mais j'ai pas encore la solution. C'est sur quelle piste ce pb
> >> d'icône?
> > 
> > Sur à peu près toutes les pistes du domaine de Pessade :
> > http://www.opensnowmap.org/?zoom=15&lat=45.62994&lon=2.87237&layers=&e=fal
> > se&m=raster
> Ben oui, piste:type=nordic n'est pas renseigné sur les *ways*, sur ce
> domaine.

Oui, ben il faudrait voir avec le wiki qui ne dit pas ça :
http://wiki.openstreetmap.org/wiki/Tag:route%3Dpiste#Tags_in_Relation:route

De ce que j'ai compris le piste:type va sur la relation, ce qui me semble un 
peu logique. La difficulté est inhérente au way, qui peut être partagé par 
plusieurs pistes et varier sur une même piste selon les portions de way. Le 
type de piste va sur la relation.

Bon par contre ta doc est cohérente avec ce que tu dis :-)
http://www.opensnowmap.org/iframes/how-to-fr.html
Mais alors mettre un même tag sur la relation et les ways …

Bon après, je peux le faire, mais je trouve ça bizarre.

Merci d'ailleurs pour ta doc ;-)

-- 
Nicolas Dumoulin
http://wiki.openstreetmap.org/wiki/User:NicolasDumoulin

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

Re: [OSM-talk-fr] Re : Re : Opensnowmap.org

[yvecai]

On 04/05/2013 09:57 PM, Nicolas Dumoulin wrote:

Le vendredi 5 avril 2013 18:32:24 yvecai a écrit :

On 04/05/2013 12:31 PM, Nicolas Dumoulin wrote:

Le vendredi 5 avril 2013 12:19:15 yve...@gmail.com a écrit :

Oui, un retour genre surbrillance au survol de la liste sera sûrement
implanté, mais j'ai pas encore la solution. C'est sur quelle piste ce pb
d'icône?

Sur à peu près toutes les pistes du domaine de Pessade :
http://www.opensnowmap.org/?zoom=15&lat=45.62994&lon=2.87237&layers=&e=fal
se&m=raster

Ben oui, piste:type=nordic n'est pas renseigné sur les *ways*, sur ce
domaine.

Oui, ben il faudrait voir avec le wiki qui ne dit pas ça :
http://wiki.openstreetmap.org/wiki/Tag:route%3Dpiste#Tags_in_Relation:route

De ce que j'ai compris le piste:type va sur la relation, ce qui me semble un
peu logique. La difficulté est inhérente au way, qui peut être partagé par
plusieurs pistes et varier sur une même piste selon les portions de way. Le
type de piste va sur la relation.

Bon par contre ta doc est cohérente avec ce que tu dis :-)
http://www.opensnowmap.org/iframes/how-to-fr.html
Mais alors mettre un même tag sur la relation et les ways …

Bon après, je peux le faire, mais je trouve ça bizarre.

Merci d'ailleurs pour ta doc ;-)

Bon après, le juge de paix, c'est aussi (et surtout): 
http://wiki.openstreetmap.org/wiki/Proposed_features/Piste_Maps


En fait, la relation route décrit une *route*[1] de ski de fond. Mais 
surtout, au sol, il y a bien une voie (way, chemin, ) [2] qui est 
une piste de ski de fond.


[1] http://wiki.openstreetmap.org/wiki/Route
[2] http://wiki.openstreetmap.org/wiki/Way


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

Re: [OSM-talk-fr] Re : Re : Opensnowmap.org

[Nicolas Dumoulin]

Le vendredi 5 avril 2013 22:10:41 yvecai a écrit :
> Bon après, le juge de paix, c'est aussi (et surtout):
> http://wiki.openstreetmap.org/wiki/Proposed_features/Piste_Maps

Ok, merci, j'avais oublié cette page, il faudrait que ça se stabilise cette 
affaire.
 
> En fait, la relation route décrit une *route*[1] de ski de fond. Mais
> surtout, au sol, il y a bien une voie (way, chemin, ) [2] qui est
> une piste de ski de fond.

Hmm soit. « il y a bien une voie qui est une piste de ski de fond », ça reste 
à discuter. Il y a des cas où c'est une voie qui est aménagée comme piste de 
ski de fond une petit partie de l'année et qui n'empêche pas d'autre activité 
d'ailleurs. Mais bon, je pinaille là, mais je trouve bizarre d'avoir besoin de 
l'étiquette sur le chemin et la relation.

Mais OK, je te suis :-)

Merci pour ton explication

-- 
Nicolas Dumoulin
http://wiki.openstreetmap.org/wiki/User:NicolasDumoulin

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

Re: [OSM-talk-fr] Re : Re : Opensnowmap.org

[yvecai]

On 04/05/2013 10:22 PM, Nicolas Dumoulin wrote:

Le vendredi 5 avril 2013 22:10:41 yvecai a écrit :

Bon après, le juge de paix, c'est aussi (et surtout):
http://wiki.openstreetmap.org/wiki/Proposed_features/Piste_Maps

Ok, merci, j'avais oublié cette page, il faudrait que ça se stabilise cette
affaire.
  

En fait, la relation route décrit une *route*[1] de ski de fond. Mais
surtout, au sol, il y a bien une voie (way, chemin, ) [2] qui est
une piste de ski de fond.

Hmm soit. « il y a bien une voie qui est une piste de ski de fond », ça reste
à discuter. Il y a des cas où c'est une voie qui est aménagée comme piste de
ski de fond une petit partie de l'année et qui n'empêche pas d'autre activité
d'ailleurs.
On doit pas être loin de 100% des cas, même. Y'a juste celle là [1] qui 
est démontée l'hiver :)

Mais bon, je pinaille là, mais je trouve bizarre d'avoir besoin de
l'étiquette sur le chemin et la relation.
Et puis c'est aussi une question d'usage. Tu imagine bien que les 
contributeurs n'ont pas attendu route=ski ou route=piste pour mapper les 
pistes de fond, loin s'en faut.


[1]http://www.opensnowmap.org/?zoom=15&lat=-77.80979&lon=166.82308&layers=&e=false&m=raster

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