[OSM-talk-fr] à cartographier, les zones franches urbaines

[Philippe Verdy]

Décret n° 2004-219 du 12 mars 2004 portant délimitation des zones franches
urbaines créées en application de l'article 23 de la loi du 1er août 2003
d'orientation et de programmation pour la ville et la rénovation urbaine.

Voir un facsimile sur
http://www.sante.gouv.fr/fichiers/bo/2004/04-11/a0110847.htm

:: Question : quoi mettre comme tag pour les zones franches urbaines ? (à
priori je penche pour "boundary=tax", en anglais pour "fiscal", avec un
éventuel sous-type "tax_type=FR:*")



Noter que ce décret fait également directement référence à des
délimitations de sections cadastrales (que pour l'instant on n'a pas
cartographiées directement.

:: Question : quoi comme tag pour les sections cadastrales ? (à priori je
penche aussi pour "boundary=tax", avec un éventuel sous-type
"tax_type=FR:*")



Noter aussi l'article 1 du décret :

:: Lorsque la limite d'une zone franche urbaine correspond à une voie
publique, elle est réputée suivre l'axe central de cette voie, sauf mention
contraire dans les annexes.

[TL;DR La suite est plus longue, sautez si ça ne vous intéresse pas, car ce
sont juste mes commentaires ou avis]

Autrement dit aucune raison de distinguer ces tracés entre frontières et
voirie car c'est explicitement dans le texte légal : il faut explicitement
une mention contraire. Et c'est un usage attesté dans plusieurs plein
d'autres textes légaux (zonage électoral, zones hospitalières ou d'aides
sociales, zonage judiciaire ou de police...)

Pour garder ces tracés superposés, en cas de déplacement de voirie, les
collectivités ont l'habitude de procéder à des échanges (plus rarement des
cessions) de parcelles inhabitées (pour ne pas modifier les poids
électoraux et éviter de nouvelles élections partielles, et de régler les
litiges fiscaux (ou autres questions réglementaires liées à l'appartenance
d'un terrain à une zone ou une autre) avec les propriétaires concernés, par
des arrangement négociés par le préfet et les collectivités concernées
(sinon c'est leur recours au tribunal administratif qui déterminera la
suite des compensations à donner aux propriétaires).

Comme ces modifications de frontières ont déjà fait l'objet d'une
consultation du Conseil d'Etat avant la publication des arrêtés par le
ministre de l'Intérieur, ces arrangements ont normalement déjà eu lieu (et
les expropriations éventuelles aussi, sans préjudice de l'action judiciaire
qui pourrait avoir lieu pour indemniser, mais sans effet sur
l'applicabilité de ces décrets en terme de définition de frontières), et
les disputes assez rares

(si ce n'est que fiscal, une exception est trouvée pendant un certain
temps, ou une compensation financière forfaitaire, les plus grosses
difficultés pourraient venir d'un changement de réglementation, par exemple
sur des zones classées ou des zones d'appellation protégées définies
simplement par une liste de communes par exemple).

Bref une bonne raison de s'opposer à la séparation par des outils
"automatiques" comme croient pouvoir le faire certains, ou même par des
opérations manuelles (où on duplique arbitrairement des noeuds par copie
décalée dans une direction et sur une distance arbitraire, avec aussi des
créations indésirables d'intersections entre les deux tracés si le tracé
dupliqué n'est pas linéaire).
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] HANDICAP : quelques idées pour tile.osm.fr

[ZIMMY]

En continuant de ragrder les ressources handicap sur internet j'ai trouvé 2
images qui sont explicites :

la première résume l'importance de visualiser les bancs dans la ville
http://www.flickr.com/photos/jeanlouis_zimmermann/8751026225/in/photostream/lightbox/

la deuxième issue du circuit confort d'Angers qui a été primé, valorise sur
le plan : traversée de chaussée (OK), téléphone public (OK), WC (OK),
*ascenseur* (ABSENT), *bancs* (ABSENT), *parking bus* (ABSENT).
http://www.flickr.com/photos/jeanlouis_zimmermann/

Bref, il y a déjà pas de choses qui existent à grande échelle !!!
Ajouter :
- bancs (zoom 19?&20)
- ascenseurs (zoom 20?)
- parking bus (zoom idem que parking voiture et même avant)



-
Cordialement,
ZIMMY
Jean-Louis ZIMMERMANN
Développeur territorial (ville d'Orange,FR84)
Mandataire OSM-France sur le Grand-Sud-est
--
View this message in context: 
http://gis.19327.n5.nabble.com/HANDICAP-quelques-idees-pour-tile-osm-fr-tp5761733.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] Nouvelles analyses Osmose : maxheight

[Jo.]

Pourquoi chercher à tagguer à tout pris pour être conforme avec Osmose ??
Il suffit de déclarer un faux positif non ?

Je roule souvent en poids lourd et en l'absence de restriction je sais que
tout véhicule lourds (hors convois exceptionnel) peut passer sans ce poser
de question.

Les pointage maxheight d'Osmose permettent donc de mettre en évidence ceux
qui ne sont pas classé comme faux positif (pas de panneaux) et qui n'ont
pas encore de limite définie.

(désolé pour les constructions de phrase, je fatigue)


Le 18 mai 2013 23:53, Vincent Pottier  a écrit :

> Le 18/05/2013 23:22, Eric Sibert a écrit :
>
>
>> Mais je maintiens mon analyse que ce test n'est pas pertinent car dans la
>> majorité des cas, la valeur est au-delà des limites légales, non indiquée
>> sur le terrain et difficile à mesurer. Ou alors, il faut tagger
>> explicitement quand on a constaté qu'il n'y avait pas de limite de hauteur
>> indiquée, du style maxheight=no.
>>
> +1
>
> maxheight=no c'est quand c'est à ciel ouvert... C'est un peu ambigu.
> --
> FrViPofm
>
>
> __**_
> 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] Tracé des limites communales : la Corrèze (19)

[Vincent de Château-Thierry]

Le 16/05/2013 21:24, Vincent de Château-Thierry a écrit :


Ça peut valoir le coup de mettre ça sur une page de wiki avec quelques
copies d'écran. Faut juste trouver le temps :-)


Hop là :
http://wiki.openstreetmap.org/wiki/FR:MapCraft/Faire_un_diagramme_avec_le_GeoFLA

vincent

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

Re: [OSM-talk-fr] Un "robot" pour séparer les frontières des autres éléments

[Jo.]

Merci, j'avais pas envisagé ça sous la forme d'un greffon pour JOSM. J'ai
également oublié d'indiqué que ContourMerge et l'outil "créer des chemins
parallèle" sont ceux que j'utilise le plus souvent voir même toute les 10
minutes d'éditions.
Le Ctrl+Alt+V pour les relations je ne connaissait pas, ça va énormément me
servir.

Pour le "presets", c'est la première fois et je n'ai pas tout saisi même si
le code est simple à comprendre, je n'ai pas saisi comment l'utiliser.
Peut tu développer ? Ça m’intéresse grandement

Le 19 mai 2013 00:28, Jo  a écrit :

> 2013/5/18 Vincent de Château-Thierry 
>
>>
>> Le 18/05/2013 23:36, Jo a écrit :
>>
>>  Vincent,
>>>
>>> Je pense qu'il y a 2 plugins qui pourraient être utile. L'un s'appell
>>> contourMerge et il permet de faire plus vite ce que l'on peut réaliser
>>> avec f(ollow).
>>>
>>> L'autre permet de faire des copies parallèlles de chemins. Il me semble
>>> très pratique pour détacher les frontières des autres ways.
>>>
>>>
>> Pour contourMerge je ne vois pas trop ? Mais vu que je ne m'en sers pas,
>> mon avis se borne à la doc JOSM à l'instant.
>> Sinon d'accord avec toi pour l'outil de copie parallèle (Maj+P), qui est
>> très bien fait. Il gère les portions convexes et concaves, ce que ne fait
>> pas un copier/coller/décaler. De quoi améliorer la première étape de ce que
>> décrivait Jo initialement. Restent les étapes de "coutures" en tous genres
>> (relations, connexité aux extrémités, choix des tags)...
>>
>
> Je pense que contourMerge fait l'inverse de ce que tu veux faire. Il y
> avait quelqu'un dans le fil qui proposait d'utiliser f(ollow)...
>
> Tu sais que tu peux faire un copier/coller de tous les tags avec
> Ctrl-c/Ctrl-Shift-V? Et pour les relations c'est Ctrl-Alt-v.
>
> Il te reste puis d'enlever ceux qui ne doivent pas figurer sur le way en
> question. Pour 'automatiser' cela tu peux faire 2 presets. Si dans tes
> presets tu ajoutes une clé sans ajouter de valeur:
>
> 
> http://josm.openstreetmap.de/tagging-preset-1.0";
> 
>  icon="presets/bench.png" type="way">
> 
> 
> 
> 
> 
> 
>  icon="presets/bench.png" type="way">
> 
> 
> 
> 
> 
> 
> 
>
> Ces clés seront enlevés, tandis que les autres resteront.
>
> F12 "Map settings", "Tagging presets" pour ajouter une référence vers ce
> fichier.
>
> Puis tu le retrouveras dans Presets/Astuces (A renommer...)
>
>
> Maintenant tout ce qui manque c'est d'ajouter un bouton sur la barre de
> taches pour accéder rapidement ces 2 presets.
>
> F12 "customize the elements on the toolbar"
>
>
> Voilà une des choses que je pense démontrer aux RMLL à Bruxelles en
> juillet... Fais signe si ce n'est pas assez claire.
>
> Un pas plus loin serait un petit script Python qui fonctionne au sein du
> scripting plugin de JOSM. Si tu veux essayer cela, il faut installer le
> scripting plugin et Jython. Mais attention, une fois que tu auras le goût
> il sera difficile d'arrêter d'automatiser quoi que ce soit...  :-)
>
> Jo
>
> ___
> 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] Nouvelles analyses Osmose

[Philippe Verdy]

J'ai repris seulement le mot présent dans le message d'Osmose (qui a
d'autres fautes dedans aussi).


Le 19 mai 2013 00:46, Jean-Francois Nifenecker <
jean-francois.nifenec...@laposte.net> a écrit :

> Le 18/05/2013 22:14, Philippe Verdy a écrit :
>
>
>> Il n'y a souvent pas d'inconsistance,
>>
>
> Et pi on dit "incohérence" et non pas "inconsistance" (faux-ami)
>
> --
> Jean-Francois Nifenecker, Bordeaux
>
>
> __**_
> 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] Nouvelles analyses Osmose

[Jean-Francois Nifenecker]

Le 18/05/2013 22:14, Philippe Verdy a écrit :


Il n'y a souvent pas d'inconsistance,


Et pi on dit "incohérence" et non pas "inconsistance" (faux-ami)

--
Jean-Francois Nifenecker, Bordeaux

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

Re: [OSM-talk-fr] tile.osm.fr & mall

[Jean-Francois Nifenecker]

Le 18/05/2013 22:18, Marc Sibert a écrit :

Bonjour,

Ce matin, je me suis "fait" un centre commercial pour voir avec comme
description générale shop=mall et chaque boutique...
http://tile.openstreetmap.fr/?zoom=18&lat=48.92809&lon=2.14527&layers=B0F



"La Grande Récrée" -> "La Grande Récré"

-> http://www.lagranderecre.fr/?home
--
Jean-Francois Nifenecker, Bordeaux

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

Re: [OSM-talk-fr] Un "robot" pour séparer les frontières des autres éléments

[Jo]

2013/5/18 Vincent de Château-Thierry 

>
> Le 18/05/2013 23:36, Jo a écrit :
>
>  Vincent,
>>
>> Je pense qu'il y a 2 plugins qui pourraient être utile. L'un s'appell
>> contourMerge et il permet de faire plus vite ce que l'on peut réaliser
>> avec f(ollow).
>>
>> L'autre permet de faire des copies parallèlles de chemins. Il me semble
>> très pratique pour détacher les frontières des autres ways.
>>
>>
> Pour contourMerge je ne vois pas trop ? Mais vu que je ne m'en sers pas,
> mon avis se borne à la doc JOSM à l'instant.
> Sinon d'accord avec toi pour l'outil de copie parallèle (Maj+P), qui est
> très bien fait. Il gère les portions convexes et concaves, ce que ne fait
> pas un copier/coller/décaler. De quoi améliorer la première étape de ce que
> décrivait Jo initialement. Restent les étapes de "coutures" en tous genres
> (relations, connexité aux extrémités, choix des tags)...
>

Je pense que contourMerge fait l'inverse de ce que tu veux faire. Il y
avait quelqu'un dans le fil qui proposait d'utiliser f(ollow)...

Tu sais que tu peux faire un copier/coller de tous les tags avec
Ctrl-c/Ctrl-Shift-V? Et pour les relations c'est Ctrl-Alt-v.

Il te reste puis d'enlever ceux qui ne doivent pas figurer sur le way en
question. Pour 'automatiser' cela tu peux faire 2 presets. Si dans tes
presets tu ajoutes une clé sans ajouter de valeur:


http://josm.openstreetmap.de/tagging-preset-1.0";

















Ces clés seront enlevés, tandis que les autres resteront.

F12 "Map settings", "Tagging presets" pour ajouter une référence vers ce
fichier.

Puis tu le retrouveras dans Presets/Astuces (A renommer...)


Maintenant tout ce qui manque c'est d'ajouter un bouton sur la barre de
taches pour accéder rapidement ces 2 presets.

F12 "customize the elements on the toolbar"


Voilà une des choses que je pense démontrer aux RMLL à Bruxelles en
juillet... Fais signe si ce n'est pas assez claire.

Un pas plus loin serait un petit script Python qui fonctionne au sein du
scripting plugin de JOSM. Si tu veux essayer cela, il faut installer le
scripting plugin et Jython. Mais attention, une fois que tu auras le goût
il sera difficile d'arrêter d'automatiser quoi que ce soit...  :-)

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

Re: [OSM-talk-fr] Nouvelles analyses Osmose : maxheight

[Vincent Pottier]

Le 18/05/2013 23:22, Eric Sibert a écrit :


Mais je maintiens mon analyse que ce test n'est pas pertinent car dans 
la majorité des cas, la valeur est au-delà des limites légales, non 
indiquée sur le terrain et difficile à mesurer. Ou alors, il faut 
tagger explicitement quand on a constaté qu'il n'y avait pas de limite 
de hauteur indiquée, du style maxheight=no.

+1

maxheight=no c'est quand c'est à ciel ouvert... C'est un peu ambigu.
--
FrViPofm

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

Re: [OSM-talk-fr] Un "robot" pour séparer les frontières des autres éléments

[Vincent de Château-Thierry]

Le 18/05/2013 23:36, Jo a écrit :

Vincent,

Je pense qu'il y a 2 plugins qui pourraient être utile. L'un s'appell
contourMerge et il permet de faire plus vite ce que l'on peut réaliser
avec f(ollow).

L'autre permet de faire des copies parallèlles de chemins. Il me semble
très pratique pour détacher les frontières des autres ways.



Pour contourMerge je ne vois pas trop ? Mais vu que je ne m'en sers pas, 
mon avis se borne à la doc JOSM à l'instant.
Sinon d'accord avec toi pour l'outil de copie parallèle (Maj+P), qui est 
très bien fait. Il gère les portions convexes et concaves, ce que ne 
fait pas un copier/coller/décaler. De quoi améliorer la première étape 
de ce que décrivait Jo initialement. Restent les étapes de "coutures" en 
tous genres (relations, connexité aux extrémités, choix des tags)...


vincent

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

Re: [OSM-talk-fr] tile.osm & déchèteries

[Vincent Pottier]

Le 18/05/2013 19:35, Christian Quest a écrit :

Rajouté... et voilà ce que ça donne:
http://tile.openstreetmap.fr/?zoom=17&lat=47.88948&lon=3.41664


2013/5/18 Vincent Pottier :

Un rendu possible pour les déchetteries taguées en area sur tile ?
Merci...
--
FrViPofm




Merci,
pour le coup, il y a un picto à l'Ademe pour les déchèteries,
Et un par type de produit si nécessaire.
http://optigede.ademe.fr/decheteries
--
FrViPofm

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

Re: [OSM-talk-fr] Un "robot" pour séparer les frontières des autres éléments

[Jo]

Vincent,

Je pense qu'il y a 2 plugins qui pourraient être utile. L'un s'appell
contourMerge et il permet de faire plus vite ce que l'on peut réaliser avec
f(ollow).

L'autre permet de faire des copies parallèlles de chemins. Il me semble
très pratique pour détacher les frontières des autres ways.

Jo

2013/5/18 Vincent de Château-Thierry 

>
> Le 18/05/2013 22:54, Jo. a écrit :
>
>>
>> *Pour revenir à la création d'un robot, est ce que vous pensez que c'est
>>
>> techniquement faisable ou pas ? Si oui on peut continuer à en discuter.
>> Si non on peut clore la discutions avant de faire un hors sujet
>> collectif.*
>>
>
> Marc a bien décrit le casse-tête de réattribution des tags objet par
> objet. Et encore, il supposait que la géométrie des ways était inchangée
> ("en réutilisant les nodes"), et c'était déjà coton.
> Mais si en plus il s'agit de décaler un des objets, alors à mon avis,
> comme tu dis, on peut clore la discussion.
>
>
> vincent
>
> __**_
> 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] tile.osm.fr & mall

[ZIMMY]

J'en ai profité pour mettre en avant la carto dans la cartothèque coups de
coeur du wiki
http://wiki.openstreetmap.org/wiki/FR:Cartotheque#Zones_commerciales



-
Cordialement,
ZIMMY
Jean-Louis ZIMMERMANN
Développeur territorial (ville d'Orange,FR84)
Mandataire OSM-France sur le Grand-Sud-est
--
View this message in context: 
http://gis.19327.n5.nabble.com/tile-osm-fr-mall-tp5761703p5761719.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] Un "robot" pour séparer les frontières des autres éléments

[Vincent Pottier]

Le 18/05/2013 22:54, Jo. a écrit :


*Pour revenir à la création d'un robot, est ce que vous pensez que 
c'est techniquement faisable ou pas ? Si oui on peut continuer à en 
discuter. Si non on peut clore la discutions avant de faire un hors 
sujet collectif.*


Un robot, j'en doute. Un outil JOSM, proche de celui de gestion des 
conflits, fonctionnant à l'envers : d'un objet, on en fait deux... 
peut-être.

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

Re: [OSM-talk-fr] Un "robot" pour séparer les frontières des autres éléments

[Vincent Pottier]

Le 18/05/2013 22:35, ZIMMY a écrit :

Je suis très intéressé par vos réflexion. Pour affiner la description du
territoire, il est bon de faciliter l'attrapage des objets géographiques.
Là où je commence à être inquiet c'est à Valence où le moindre recoin
devient complexe à outrance : des relations partout des terres
http://www.openstreetmap.org/edit?zoom=17&lat=44.90406&lon=4.91378&layers=B0F
, partout, partout jusqu'aux logements
http://www.openstreetmap.org/edit?editor=potlatch2&lat=44.928856&lon=4.895372&zoom=18


Oui, j'ai horreur de ce mode de mapping qui abuse des relations !
C'est ingérable pour un néophyte. Ça ne ressemble à rien.
Je m'empresse de restituer des objets quand je vois ça !

Mais je ne crois pas que l'idée du robot était pour produire cet espèce 
d'éclaté.

Au contraire.
--
FrViPofm

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

Re: [OSM-talk-fr] Nouvelles analyses Osmose : maxheight

[Eric Sibert]

Pour maxheight, ce sont ces deux trac qui sont à l'origine de  
l'analyse, il y plus d'info dedans :

- http://trac.openstreetmap.fr/ticket/95
- http://trac.openstreetmap.fr/ticket/295


Merci pour ces liens, surtout le premier qui répond à nos questions  
sur les valeurs par défaut.


Mais je maintiens mon analyse que ce test n'est pas pertinent car dans  
la majorité des cas, la valeur est au-delà des limites légales, non  
indiquée sur le terrain et difficile à mesurer. Ou alors, il faut  
tagger explicitement quand on a constaté qu'il n'y avait pas de limite  
de hauteur indiquée, du style maxheight=no.




Eric


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

Re: [OSM-talk-fr] Un "robot" pour séparer les frontières des autres éléments

[Jo.]

Déjà pour un humain c'est de la gymnastique intellectuelle ce travail mais
pour un programme ça doit être bien coton.


Le 18 mai 2013 23:10, Vincent de Château-Thierry  a écrit
:

>
> Le 18/05/2013 22:54, Jo. a écrit :
>
>>
>> *Pour revenir à la création d'un robot, est ce que vous pensez que c'est
>>
>> techniquement faisable ou pas ? Si oui on peut continuer à en discuter.
>> Si non on peut clore la discutions avant de faire un hors sujet
>> collectif.*
>>
>
> Marc a bien décrit le casse-tête de réattribution des tags objet par
> objet. Et encore, il supposait que la géométrie des ways était inchangée
> ("en réutilisant les nodes"), et c'était déjà coton.
> Mais si en plus il s'agit de décaler un des objets, alors à mon avis,
> comme tu dis, on peut clore la discussion.
>
>
> vincent
>
> __**_
> 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] Un "robot" pour séparer les frontières des autres éléments

[Vincent de Château-Thierry]

Le 18/05/2013 22:54, Jo. a écrit :


*Pour revenir à la création d'un robot, est ce que vous pensez que c'est
techniquement faisable ou pas ? Si oui on peut continuer à en discuter.
Si non on peut clore la discutions avant de faire un hors sujet collectif.*


Marc a bien décrit le casse-tête de réattribution des tags objet par 
objet. Et encore, il supposait que la géométrie des ways était inchangée 
("en réutilisant les nodes"), et c'était déjà coton.
Mais si en plus il s'agit de décaler un des objets, alors à mon avis, 
comme tu dis, on peut clore la discussion.


vincent

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

Re: [OSM-talk-fr] tile.osm.fr & mall

[ZIMMY]

Pour moi la qualification du building est déjà suffisante.
Mais bon il faut tenter. J'ai bien aimé la qualification du cheminement
piéton intérieur ;-)

J'ai mis ma petite touche qui est valorisée dans Mapnik-FR
http://tile.openstreetmap.fr/?zoom=18&lat=48.92801&lon=2.14468&layers=B0F
il faudra finir car je n'ai pas pu attraper certaines cellules commerciales
...

en m'inspirant de ce que j'ai poussé grâce aux aides OSMiennes sur Avignons
http://tile.openstreetmap.fr/?zoom=18&lat=43.98179&lon=4.88151&layers=B0F



-
Cordialement,
ZIMMY
Jean-Louis ZIMMERMANN
Développeur territorial (ville d'Orange,FR84)
Mandataire OSM-France sur le Grand-Sud-est
--
View this message in context: 
http://gis.19327.n5.nabble.com/tile-osm-fr-mall-tp5761703p5761713.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] tile.osm et Osmose

[Jo.]

Bonsoir,


Maintenant que le rendu FR est fort bien avancé (merci Christian), peut
être est ce le moment de le proposer comment rendu alternatif dans Osmose ??

J'aimerai bien l'obtenir avec l'application Android OSMand ou OruxMap, ce
serait plus parlant sur le terrain que le rendu Mapnik
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] tile.osm.fr & mall

[Jo.]

Le 18 mai 2013 22:18, Marc Sibert  a écrit :

> Bonjour,
>
> Ce matin, je me suis "fait" un centre commercial pour voir […]
>

T'a mis une capote j'espère… !? :-D

désolé c'était plus fort que moi, c'était trop tentant et encore je passe à
coté du "Conclusion le "mall" mange tout" parce que le mâle c'est mal.

(ok je sort, désolé pour le hors sujet)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Un "robot" pour séparer les frontières des autres éléments

[Jo.]

Le 18 mai 2013 19:57, Philippe Verdy  a écrit :

> Déplacer légèrement la frontière pour éviter la superposition donne un
> résultat faut. La superposition de traits (en conservant les noeuds,
> n'empêchera pas que les deux lignes soient déplacées en même temps, et elle
> pose le problème que tout ajout de POI sur ces traits se fera sur un chemin
> ambigu (par exemple mauvaise interconnexion de routes en prenant le mauvais
> trait, pose de feux de signalisation ou de passages piétons sur la
> frontière et non pas sur la route, limitations de vitesse et radars posés
> sur la frontière et non sur la route, etc...)
>

Par défaut* j'opte toujours pour ne pas toucher aux frontières* sans avoir
des informations complémentaire. Les nouveaux éléments sont toujours
attribué pour les cours d'eau et voirie. Cela évite de casser les relations
des frontières.

Parfois je sépare de petite portions qui suivent assez fidèlement une
voirie mais cela permettra à un contributeur utilisant Potlach (ou autre
éditeur en ligne) de faire évoluer géométriquement les deux éléments
séparément.

Je rappel qu'il y a toujours des risques de suppression d'éléments fusionné
sans qu'on s'en rende compte. Que des terrains disparaissent par erreur ce
n'est pas si grave mais qu'une frontière ou un route saute sans s'en rendre
compte c'est plus fâcheux. Il n'y a pas temps de contributeur confirmé que
ça… et l'erreur est humaine.

*Pour revenir à la création d'un robot, est ce que vous pensez que c'est
techniquement faisable ou pas ? Si oui on peut continuer à en discuter. Si
non on peut clore la discutions avant de faire un hors sujet collectif.*
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Un "robot" pour séparer les frontières des autres éléments

[Vincent de Château-Thierry]

Le 18/05/2013 22:41, Vincent de Château-Thierry a écrit :

il suffit de se baiser pour en trouver.


Oops. baisser !


(fatigue)


confirmée :-)

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

Re: [OSM-talk-fr] Un "robot" pour séparer les frontières des autres éléments

[Vincent de Château-Thierry]

Le 18/05/2013 19:57, Philippe Verdy a écrit :

JE ne suis pas sûr de l'intérêt non plus car très souvent, peu importe
ce qui est dans le cadastre, ce n'est même pas la source officielle qui
est :
- soit un texte de loi ou arrêté qui précise que la frontière passe par
l'axe d'une voirie (peu importe si cet axe bouge un peu à l'occasion de
l'aménagement d'un carrefour !)
- soit le bornage effectué sur le terrain (pas au milieu de la route ou
de la rivière mais dans ce cas sur une rive (et donc déjà pas superposé
du tout), dont le cadastre enregistre le métrage effectué à ce moment là
s'il n'y a pas de raison pour qu'il ait bougé sans autorisation ni accident.


Je dois repréciser : quand je dis que je ne vois pas l'intérêt, c'est 
pour une limite qui géométriquement est raccord avec un élément du 
paysage : axe ou bord de voie routière, limite de construction. Si la 
limite est l'axe de la route, je ne vois pas l'intérêt de dédoubler les 
noeuds et de fabriquer deux ways parallèles. À l'inverse dans les cas 
(nombreux) où il y a divergence de géométrie la question ne se pose pas 
: chaque objet doit être géométriquement autonome. Le cas le plus 
flagrant étant celui des cours d'eau.
Et dis toi bien que la seule source dont on dispose sans ambiguïté (ni 
trop de difficulté) ce sont les plans du cadastre. Un texte définissant 
une limite relativement à des éléments topographiques, fige la géométrie 
de la limite communale en fonction du terrain _de l'époque_, pas de 
l'actuel. Tu devrais relire ce mail :

http://lists.openstreetmap.org/pipermail/talk-fr/2013-May/058594.html


Il n'y a aucun cas où une voirie ou une rivière se déplace "toute seule"
de façon significative sans que cela ne déclenche une mise à jour
cadastrale. Et on en sera les derniers informés de toutes façon (car les
planches cadastrales qu'on veut consulter en ligne ne seront pas
immédiatement en ligne). Bref le terrain prévaut. Une rivière ne bouge
pas toute seule de façon significative et son lit est assez large pour
que la ligne "virtuelle" qu'on place totalement arbitrairement au milieu
du lit reste malgré tout dans ce lit même s'il a légèrement bougé. Il
n'y aura pas de construction qui tienne légalement dans ces zones
inondables.

Les seuls cas compliqués sont quand la frontière ne suit ni une voirie
ni une rivière. C'est très rare et cela ne se produit pratiquement qu'en
milieu urbain, car même en milieu rural on trouvera au moins des bornes
d'alignement en bordure des champs remembrés (historiquement il y avait
des chemins communaux autour de ces frontières, ou alors c'était
toujours une ligne naturelle (rivière, ligne de crète, bordure de
falaise ou une clôture de propriété.


Ces deux paragraphes soulignent juste que tu n'as jamais dû passer plus 
de 5mn d'affilée sur du cadastre. La mise à jour du cadastre, même pour 
du bâti, peut attendre plusieurs années. Alors ton "déclenchement" de 
mise à jour, il me fait bien rigoler.
Quant aux rivières... balade toi un peu sur les planches de communes de 
l'Allier, au droit des cours d'eau, tu auras du mal à reconnaître sur la 
cadastre ce que tu observeras sur bing. Je parle de l'Allier parce que 
c'est récent pour moi, mais le cas se retrouvera forcément ailleurs.
Et les limites qui ne sont ni une voirie ni une rivière : pas compliqué, 
elles sont légion ! Avec bing en fond et le cadastre en transparence, il 
suffit de se baiser pour en trouver.


(fatigue)

vincent

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

Re: [OSM-talk-fr] Un "robot" pour séparer les frontières des autres éléments

[ZIMMY]

Je suis très intéressé par vos réflexion. Pour affiner la description du
territoire, il est bon de faciliter l'attrapage des objets géographiques.
Là où je commence à être inquiet c'est à Valence où le moindre recoin
devient complexe à outrance : des relations partout des terres
http://www.openstreetmap.org/edit?zoom=17&lat=44.90406&lon=4.91378&layers=B0F
, partout, partout jusqu'aux logements 
http://www.openstreetmap.org/edit?editor=potlatch2&lat=44.928856&lon=4.895372&zoom=18


verdy_p wrote
> JE ne suis pas sûr de l'intérêt non plus car très souvent, peu importe ce
> qui est dans le cadastre, ce n'est même pas la source officielle qui est :
> - soit un texte de loi ou arrêté qui précise que la frontière passe par
> l'axe d'une voirie (peu importe si cet axe bouge un peu à l'occasion de
> l'aménagement d'un carrefour !)
> - soit le bornage effectué sur le terrain (pas au milieu de la route ou de
> la rivière mais dans ce cas sur une rive (et donc déjà pas superposé du
> tout), dont le cadastre enregistre le métrage effectué à ce moment là s'il
> n'y a pas de raison pour qu'il ait bougé sans autorisation ni accident.
> 
> Le cas des accidents (crues) est à part. Il est toujours géré au cas par
> cas avec des géomètres qui viennet sur place constater ce qu'il faut faire
> et si de nouvelles bornes doivent être établies. Dans ce cas le cadastre
> sera mlis à jour et on devra alors nous aussi se mettre à jour.
> 
> Il n'y a aucun cas où une voirie ou une rivière se déplace "toute seule"
> de
> façon significative sans que cela ne déclenche une mise à jour cadastrale.
> Et on en sera les derniers informés de toutes façon (car les planches
> cadastrales qu'on veut consulter en ligne ne seront pas immédiatement en
> ligne). Bref le terrain prévaut. Une rivière ne bouge pas toute seule de
> façon significative et son lit est assez large pour que la ligne
> "virtuelle" qu'on place totalement arbitrairement au milieu du lit reste
> malgré tout dans ce lit même s'il a légèrement bougé. Il n'y aura pas de
> construction qui tienne légalement dans ces zones inondables.
> 
> Les seuls cas compliqués sont quand la frontière ne suit ni une voirie ni
> une rivière. C'est très rare et cela ne se produit pratiquement qu'en
> milieu urbain, car même en milieu rural on trouvera au moins des bornes
> d'alignement en bordure des champs remembrés (historiquement il y avait
> des
> chemins communaux autour de ces frontières, ou alors c'était toujours une
> ligne naturelle (rivière, ligne de crète, bordure de falaise ou une
> clôture
> de propriété.
> 
> Déplacer légèrement la frontière pour éviter la superposition donne un
> résultat faut. La superposition de traits (en conservant les noeuds,
> n'empêchera pas que les deux lignes soient déplacées en même temps, et
> elle
> pose le problème que tout ajout de POI sur ces traits se fera sur un
> chemin
> ambigu (par exemple mauvaise interconnexion de routes en prenant le
> mauvais
> trait, pose de feux de signalisation ou de passages piétons sur la
> frontière et non pas sur la route, limitations de vitesse et radars posés
> sur la frontière et non sur la route, etc...)
> 
> Ne pas superposer les traits c'est hautement préférable. Cela allège la
> base et les traitements en évitant les duplications et cela facilite
> nettement la maintenance et l'ajout d'autres données. De même ne pas les
> copier sur des lignes parallèles qui n'ont aucune justification légale (il
> faut bien noter que le tracé linéaire des routes est totalement virtuel la
> route est plus large que le trait : si la frontière passe sur la chaussée
> de la route, peu importe alors s elle bouge légèrement, elle continue à
> passer sur l'axe de cette route.
> 
> Le seul cas problématique c'est quand la route est séparée en deux
> chaussées : l'axe central de la route est alors un terre-plein ou une
> barrière mais on ne sait pas si une seconde chaussée a été aménagée sur le
> territoire d'une seule collectivité, en conservant pour l'autre sens la
> chaussée existante dont l'axe central reste la frontière.
> 
> Je ne vois QUE le cas des chaussées séparées (y compris les aménagements
> de
> rond-points) pour lesquels on doit séparer la frontière du tracé des
> routes. Pour tout le reste, on devrait partager tous les noeuds et chemins
> qui y passent tant que la route ou la rivière n'est représentée QUE par un
> filaire central qui n'existe pas réellement, et partout où la frontière
> reste dans le lit réel de rivière ou la chaussée chaussée
> 
> 
> Le 18 mai 2013 17:36, Vincent de Château-Thierry <

> vdct@

> > a écrit
> :
> 
>> Bonjour,
>>
>>
>> Le 18/05/2013 16:48, Jo. a écrit :
>>
>>>
>>> Cela fait des mois qu'à chaque amélioration en précision de cours d'eau,
>>> route et terrain fusionné avec une frontière que je perd de long moment
>>> à séparer ces chemins. Le plus long étant de contrôler chaque extrémité
>>> de segments et les relations impactées.
>>>
>>> Est ce qu'une personne aurait les connaissances pou

[OSM-talk-fr] tile.osm.fr & mall

[Marc Sibert]

Bonjour,

Ce matin, je me suis "fait" un centre commercial pour voir avec comme 
description générale shop=mall et chaque boutique...

http://tile.openstreetmap.fr/?zoom=18&lat=48.92809&lon=2.14527&layers=B0F

Conclusion le "mall" mange tout. Une idée ? un meilleur tag pour 
l'ensemble du centre commercial ou... une modification du rendu pour 
soit mettre le "mall" en-dessous ou bien le rendre plus transparent ?


Merci,

A+

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


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

Re: [OSM-talk-fr] défi d'OpenStreetMap pour 2015 : le HANDICAP

[ZIMMY]

Merci Cédric de cette réflexion,

Dans la question du handicap 2 points peuvent voir une réponse immédiate
dans le rendu français (optimisée à terme) :

- *handicap mental* : il permet de mieux décrire notre environnement pour le
rendre encore plus compréhensible. La richesse de la représentation de
tile.openstreetmap.fr permet d'avoir accès à beaucoup de contenu sans
manipulation particulière.

- *handicap visuel* : c'est pour l'instant le gros problème des
représentations d'OpenStreetMap en général. La taille des caractères est
souvent trop petite, le choix d'expression ton sur ton (pastel) en fait un
support pour les jeunes principalement. Enfin, il restera comme tu le
formules l'optimisation de la répartition des informations en dimensionnant
les pictogrammes pour qu'ils restent lisibles.
Cédric Moro wrote
> Bonjour Zimmy,
> 
> Oui le site est très intéressant sur le fond mais plus critiquable sur la
> forme.
> 
> En effet, le site reste peu adapté aux malvoyants même si à première vue
> on y voit des options pour aggrandir les polices.
> 
> Je m'explique, ce site n'est pas du tout adapté à une lecture sur
> téléphone mobile. Déjà qu'il est difficile à lire sur un smartphone pour
> un voyant, j'imagine pour une personne ayant moins de capacités dans ce
> domaine.
> 
> Un thème visuel "responsive" comme bootstrap (c'est à dire dont les
> éléments s'imbriquent en largeur ou en hauteur selon l'espace disponible
> sur la largeur de l'écran) aurait permis :
> - d'avoir une carte pleine page, 
> - les éléments du menu en haut les uns sous les autres donc plus gros 
> - le fameux carré bleu sous ou au dessus de la carte...
> 
> Tout aurait donc été bien plus gros en disposant les éléments sur la
> hauteur pour les téléphones mobiles, là où la largeur (et résolution) des
> écrans fait défaut.
> 
> Pour le code, mais aussi pour un exemple concret de thème responsive,
> aller sur :
> http://twitter.github.io/bootstrap/
> Si vous redimensionnez la fenêtre de votre navigateur, vous verrez que ce
> site s'adapte et ses blocs se redisposent en fonction de la largeur
> disponible. De même, si vous le consultez avec un téléphone mobile, vous
> verrez que sa lecture est très aisée.
> 
> Vous pouvez aussi regarder cette infographie sur le thème responsive :
> http://pinterest.com/pin/372813675373314953/
> 
> Bon, nous sommes loin d'OSM mais OSM s'inscrit aussi dans un environnement
> web en mutation dont il peut être intéressant de connaître quelques
> évolutions récentes et majeures.
> 
> Merci Zimmy pour ce post très intéressant et à bientôt,
> 
> Cédric
> 
> 
> 
> 
> 
> Date: Sat, 18 May 2013 11:05:21 +0200
> From: 

> istaous@

> To: 

> talk-fr@

> Subject: Re: [OSM-talk-fr]défi d'OpenStreetMap pour 2015 : le HANDICAP
> 
> Le 16 mai 2013 23:15, ZIMMY <

> jeanlouis.zimmermann@

> > a écrit :
> 
> 
> Le site internet Handistrict a un site intéressant à deux titre : il
> 
> considère les handicaps de manière globale et les données qualifiées sont
> 
> libres.
> 
> http://handistrict.com/handistrict/about
> 
> 
> 
> J'ai l'impression que ce site s'adresse surtout aux handicaps moteurs : je
> ne vois pas grand chose sur les handicaps mentaux. 
> 
> Niveau handicap moteur, il est sans doute possible de les penser de
> manière globale, si le handicap n'est pas trop fort. Mais les handicaps
> mentaux ça m'étonne qu'on puisse les penser de manière globale, mais tout
> se discute.
> 
> 
> 
> Sous cette réserve mentaux/moteurs, je trouve que le travail est très bien
> fait, et probablement très utile.
> 
>  
> 
> 
> C'est la raison pour laquelle nous souhaitons avec Jérémie Valentin
> 
> promoteur des cartoparties handicap à Montpellier nous souhaitons
> transposer
> 
> l'ontologie OSM sur la grille Handistrict afin de les aider à s'approprier
> 
> la base OpenStreetMap. Vos aides sont bienvenues.
> 
> https://docs.google.com/spreadsheet/ccc?key=0AoBuAP_kINa7dEMwSW1BOUlEUW9IZ3VrR3hIYWc4NXc#gid=10
> 
> 
> 
> 
> 
> 
> 
> Je ne comprends pas bien comment et pourquoi s'utilise ou se manipule ce
> document, qui à l'air intéressant quand même.
> 
> "Transposer l'ontologie OSM" ?... J'imagine qu'il s'agit de prendre les
> clefs-valeurs d'OSM et de dire comment elles correspondent aux ids de ce
> fichier ?
> 
> 
> 
> À terme, est-ce pour faire des correspondances d'enregistrement de données
> entre les deux bases ? Par exemple, un hotel dans handiscrict et un hotel
> dans osm ? Ou que la sémantique soit la même sans forcément être capables
> de faire la relation des identificateurs ? Ou que les humains collaborent
> plus facilement aux deux projets ? Ou tout, ou rien ?
> 
> 
> Pour ce qui est de donner un coup de main, en ce moment, impossible pour
> moi, désolé. Mais fin mai / début juin peut être ?
> 
> 
> Cordialement.
> 
> 
> 
> ___
> Talk-fr mailing list

> Talk-fr@

> http://lists.openstreetmap.org/listinfo/talk-fr   
>   
> ___

Re: [OSM-talk-fr] Nouvelles analyses Osmose

[Philippe Verdy]

Problème:
*Tag population inconsistant entre la relation et le admin_centre*
Population du rôle admin_centre (952) suppérieure à la polulation de la
relation (852)
*relation 1993528 *
rawedit 
analyse1

Les fautes d'orthographe dans le message 'suppérieure, polulation,
sic!) sont copiées ici telles quelles. Et puis un rôle n'a pas de tag
(ambiguité qui ici cependant n'est pas grave, on sous-entend la population
renseignée dans un tag pour l'objet mentionné en admin_centre).

Il n'y a souvent pas d'inconsistance, c'est juste que les chiffres ne
portent pas sur les mêmes années (et pas toujours disponibles la même année
avec le même niveau de détail selon qu'on parle de la commune entière
(relation) ou d'une de ses agglomérations ou d'un niveau plus fin (noeud).

A mon avis, la population d'un noeud n'a de toute façon strictement AUCUN
sens (pas plus d'ailleurs que le code INSEE, ou un autre code similaire
comme en Espagne où les membres de rôle "admin_centre" sont détaillés avec
un noeud jusqu'au niveau plus fin du "noyau de peuplement" aussi petit
qu'un hameau qui a sa propre codification fine à 11 chiffres là où la
commune entière est codée sur 5 chiffres et très souvent nommée
différemment...), seule la population de la relation a un sens.

Je vois plutôt une obsolescence totale (dépréciation) de la population au
niveau d'un noeud pour n'avoir à maintenir que la population au niveau de
la relation (et dans ce cas le noeud "place" n'a plus de population mais
n'est qu'un subsitut paliatif à une ou plusieurs relations qu'il représente
(par une icone ou juste un libellé) quand ces relations ne sont pas
représentables. Et aussi la promotion des "admin_center" pour pouvoir
préciser non pas un noeud membre mais une relation membre (incluant
elle-même ses frontières et son propre admin_centre)

D'autant plus que des tas de territoires en Europe (et pas qu'en Europe
d'ailleurs) ont pour chacun seuls plusieurs chef-lieux ou capitales, et
qu'un même chef-lieu peut être partagé pour plusieurs territoires
complètement distincts, dont un seul (voire aucun) pourrait contenir le
chef-lieu lui-même (en France on a le cas en Alsace et Moselle) mais pas
les autres (cas fréquent des chef-lieux de cantons).

Au niveau le plus fin les noeuds place n'ont pas plus de sens : si c'est
une mairie pour la commune, c'est le bâtiment de la marie qu'on devrait
pouvoir indiquer (mais la loi précise qu'en fait le chef-lieu d'une commune
ce n'est pas le bâtiment de la mairie lui-même mais un point proche du
centre de sa principale agglomération ou son principal hameau). Avec les
communes associées ou déléguées cela se complique : la commune entière n'a
le nom d'aucune de ses sous-communes ou agglomérations, mais un nom adhoc
désignant la collectivité dans son territoire tout entier.

Alors quel est le sens donné à la valeur de "place=*" ? à mon avis il n'en
a aucun : la vraie information est dans les relations que la représentation
de ce noeud vient remplacer. Ce qui en fin de compte rend très peu
pertinent ces *noeuds* de type "place=*" (mais là je ne parle pas du rôle
"admin_centre" qui a son utilité certaine mais pas vocation à rester
associé à un seul noeud).

Alors que des relations pourraient avoir un type "place=*" qui a plus de
sens d'autant plus que la relation, elle, a une population définie sur un
territoire de surface non nulle (donc aussi une densité moyenne calculable).

En conséquence, les noeuds devraient même ne plus être nécessaires du tout
: les admin_centre devraient devenir à terme des polygones ou relations
(eux-mêmes pas toujours dans le même territoire). (IMPORTANT : je n'ai PAS
dit ici que le rôle admin_centre ne servirait à rien juste qu'il n'est pas
utilisé de la meilleure façon !)

Mais on a d'autres difficultés : selon ce que représente l'objet désigné
par admin_center : la collectivité locale qui trouve son territoire, ou
bien la représentation locale de l'autorité qui détient le contrôle sur le
sous-territoire ? ou toute administration qui trouverait le même territoire
d'exercice ? Ou juste un point "central" (principal carrefour de
communication et d"interconnexion des principaux axes dans une commune) ?
Ou une position plus favorable sur la carte évitant certaines concatités
(ce qui est plutôt dévolu au rôle "label" dont le seul but est de préciser
la position d'un noeud unique)

Selon le cas ce pourrait donc être :
- une mairie d'arrondissement ou mairie annexe ou déléguée
- une mairie pleine
- le conseil général/départemental
- le conseil communautaire
- la conférence territoriale
- le conseil régional
- la préfecture de région, de département ou la sous-préfecture
- la préfecture de police
- le quartier de gendarmerie ou commissariat de police
- le tribunal d'instance ou une cours d'une autre juridiction
- etc.
___
Talk-fr mailing list
Tal

Re: [OSM-talk-fr] tile.osm & déchèteries

[ZIMMY]

Une autre version plus détaillée en Vaucluse ;-)
http://tile.openstreetmap.fr/?zoom=18&lat=44.11246&lon=4.84109&layers=B0F



-
Cordialement,
ZIMMY
Jean-Louis ZIMMERMANN
Développeur territorial (ville d'Orange,FR84)
Mandataire OSM-France sur le Grand-Sud-est
--
View this message in context: 
http://gis.19327.n5.nabble.com/tile-osm-decheteries-tp5761612p5761700.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] Un "robot" pour séparer les frontières des autres éléments

[Philippe Verdy]

JE ne suis pas sûr de l'intérêt non plus car très souvent, peu importe ce
qui est dans le cadastre, ce n'est même pas la source officielle qui est :
- soit un texte de loi ou arrêté qui précise que la frontière passe par
l'axe d'une voirie (peu importe si cet axe bouge un peu à l'occasion de
l'aménagement d'un carrefour !)
- soit le bornage effectué sur le terrain (pas au milieu de la route ou de
la rivière mais dans ce cas sur une rive (et donc déjà pas superposé du
tout), dont le cadastre enregistre le métrage effectué à ce moment là s'il
n'y a pas de raison pour qu'il ait bougé sans autorisation ni accident.

Le cas des accidents (crues) est à part. Il est toujours géré au cas par
cas avec des géomètres qui viennet sur place constater ce qu'il faut faire
et si de nouvelles bornes doivent être établies. Dans ce cas le cadastre
sera mlis à jour et on devra alors nous aussi se mettre à jour.

Il n'y a aucun cas où une voirie ou une rivière se déplace "toute seule" de
façon significative sans que cela ne déclenche une mise à jour cadastrale.
Et on en sera les derniers informés de toutes façon (car les planches
cadastrales qu'on veut consulter en ligne ne seront pas immédiatement en
ligne). Bref le terrain prévaut. Une rivière ne bouge pas toute seule de
façon significative et son lit est assez large pour que la ligne
"virtuelle" qu'on place totalement arbitrairement au milieu du lit reste
malgré tout dans ce lit même s'il a légèrement bougé. Il n'y aura pas de
construction qui tienne légalement dans ces zones inondables.

Les seuls cas compliqués sont quand la frontière ne suit ni une voirie ni
une rivière. C'est très rare et cela ne se produit pratiquement qu'en
milieu urbain, car même en milieu rural on trouvera au moins des bornes
d'alignement en bordure des champs remembrés (historiquement il y avait des
chemins communaux autour de ces frontières, ou alors c'était toujours une
ligne naturelle (rivière, ligne de crète, bordure de falaise ou une clôture
de propriété.

Déplacer légèrement la frontière pour éviter la superposition donne un
résultat faut. La superposition de traits (en conservant les noeuds,
n'empêchera pas que les deux lignes soient déplacées en même temps, et elle
pose le problème que tout ajout de POI sur ces traits se fera sur un chemin
ambigu (par exemple mauvaise interconnexion de routes en prenant le mauvais
trait, pose de feux de signalisation ou de passages piétons sur la
frontière et non pas sur la route, limitations de vitesse et radars posés
sur la frontière et non sur la route, etc...)

Ne pas superposer les traits c'est hautement préférable. Cela allège la
base et les traitements en évitant les duplications et cela facilite
nettement la maintenance et l'ajout d'autres données. De même ne pas les
copier sur des lignes parallèles qui n'ont aucune justification légale (il
faut bien noter que le tracé linéaire des routes est totalement virtuel la
route est plus large que le trait : si la frontière passe sur la chaussée
de la route, peu importe alors s elle bouge légèrement, elle continue à
passer sur l'axe de cette route.

Le seul cas problématique c'est quand la route est séparée en deux
chaussées : l'axe central de la route est alors un terre-plein ou une
barrière mais on ne sait pas si une seconde chaussée a été aménagée sur le
territoire d'une seule collectivité, en conservant pour l'autre sens la
chaussée existante dont l'axe central reste la frontière.

Je ne vois QUE le cas des chaussées séparées (y compris les aménagements de
rond-points) pour lesquels on doit séparer la frontière du tracé des
routes. Pour tout le reste, on devrait partager tous les noeuds et chemins
qui y passent tant que la route ou la rivière n'est représentée QUE par un
filaire central qui n'existe pas réellement, et partout où la frontière
reste dans le lit réel de rivière ou la chaussée chaussée


Le 18 mai 2013 17:36, Vincent de Château-Thierry  a écrit
:

> Bonjour,
>
>
> Le 18/05/2013 16:48, Jo. a écrit :
>
>>
>> Cela fait des mois qu'à chaque amélioration en précision de cours d'eau,
>> route et terrain fusionné avec une frontière que je perd de long moment
>> à séparer ces chemins. Le plus long étant de contrôler chaque extrémité
>> de segments et les relations impactées.
>>
>> Est ce qu'une personne aurait les connaissances pour créer un robot
>> permettant d'automatiser tout cela ? Avec le temps j'ai fait le tour des
>> cas particulier et des méthodes pour arriver à un résulta fonctionnel et
>> exploitable par tous le monde.
>>
>>  1. je duplique le segment en le collant au plus près du segment d'origine
>>  2. je reconnecte les nouveau segments entre eux
>>  3. je reconnecte les segments qui coupent ou finissent sur la frontière
>>  4. je supprime les tag redondant (border et similaire d'un coté puis
>>
>> tous les autres tag sur le nouveau segment)
>>  5. je met à jour les relations (route, river, highking, …) en
>>
>> interchangeant les frontière avec les nouveaux segments
>>  6. val

Re: [OSM-talk-fr] Un "robot" pour séparer les frontières des autres éléments

[Hélène PETIT]

Le 18/05/2013 19:11, Jo. a écrit :
> Voici un cas pratique : http://osm.org/go/xVlCL3zZX-
> Avant je fusionnai systématiquement cours d'eau et frontière et depuis
> ce cas, je sépare systématiquement cours d'eau et frontière. Cette
> rivière subie plusieurs crue dans l'hiver et son cours d'eau est
> changeant, (comme dans toutes les garrigues d'ailleurs).

+1
je dédouble assez souvent, moi aussi ;
les cours d'eau sont très changeants, je confirme ; dans la plus part
des cas la frontière de la commune reste au même endroit alors que le
lit du cours d'eau a été redressé exprès par des gens ; exemple ici :
http://osm.org/go/xVNTslY8J-
Idem pour les routes, redressées, recourbées alors que la limite de
commune, elle, n'a pas bougé. J'ai eu des dizaines de cas.




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

Re: [OSM-talk-fr] tile.osm & déchèteries

[Christian Quest]

Rajouté... et voilà ce que ça donne:
http://tile.openstreetmap.fr/?zoom=17&lat=47.88948&lon=3.41664


2013/5/18 Vincent Pottier :
> Un rendu possible pour les déchetteries taguées en area sur tile ?
> Merci...
> --
> FrViPofm
>


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

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

Re: [OSM-talk-fr] Un "robot" pour séparer les frontières des autres éléments

[Jo.]

Je peut rédiger un texte explicatif pour chacun des cas qui peut servir à
la création du robot mais ça risque de faire un pavé et prendre pas mal de
temps de mon coté que je préfère utiliser pour autre chose.

Pour faire simple l'idée est de :

   1. Séparer une frontière fusionnée en deux éléments distinct non
   superposé ;
   2. Déplacer tous les tag qui ne concerne pas les frontière sur le
   nouveau segment ;
   3. Modifier les relations type=waterway, type=route et autre pour
   remplacer les segment de frontière par les nouveaux segments
   4. Contrôler la continuité des tracé formé par les nouveaux segment
   (idem pour les intersections)



Le 18 mai 2013 18:51, Marc Sibert  a écrit :

>  Le 18/05/2013 16:48, Jo. a écrit :
>
>   Bonjour,
>
>
>  Cela fait des mois qu'à chaque amélioration en précision de cours d'eau,
> route et terrain fusionné avec une frontière que je perd de long moment à
> séparer ces chemins. Le plus long étant de contrôler chaque extrémité de
> segments et les relations impactées.
>
>  Est ce qu'une personne aurait les connaissances pour créer un robot
> permettant d'automatiser tout cela ? Avec le temps j'ai fait le tour des
> cas particulier et des méthodes pour arriver à un résulta fonctionnel et
> exploitable par tous le monde.
>
>1. je duplique le segment en le collant au plus près du segment
>d'origine
>2. je reconnecte les nouveau segments entre eux
>3. je reconnecte les segments qui coupent ou finissent sur la frontière
> 4. je supprime les tag redondant (border et similaire d'un coté puis
>tous les autres tag sur le nouveau segment)
>5. je met à jour les relations (route, river, highking, …) en
>interchangeant les frontière avec les nouveaux segments
>6. validation JOSM pour contrôle
>
> C'est un travail assez abrutissant et rébarbatif, est ce qu'il serait
> possible d'automatiser tout cela ??? J'offre l'apéro à celui qui répondra à
> ma demande ;-P ce serait l'occasion de ce rencontrer dans le sud...
>
>
> ___
> Talk-fr mailing 
> listTalk-fr@openstreetmap.orghttp://lists.openstreetmap.org/listinfo/talk-fr
>
>  Je pense que tu parles de séparer les ways en réutilisant les nodes.
>
> La problématique n'est pas triviale pour un "robot", car :
>
>- Plusieurs éléments géographiques sont portés par un seul way --> il
>faut donc séparer les tags en groupes pour chacune des "fonctions", les
>boundary, les highway, les waterway, mais surtout leurs tags de
>spécialisation en même temps ; imagine : highway=service +
>service=parking_aisle
>- En plus ces ways peuvent être inclus dans des associations
>(boundary, waterway, road, etc.) --> il se pose le même problème qu'avant :
>à quel groupe va une relation ?
>
> Des idées ? Mais pour moi rien de facilement automatisable en l'état.
>
> A+
>
> --
> Marc Sibertmailto:m...@sibert.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] Un "robot" pour séparer les frontières des autres éléments

[Jo.]

La séparation me semble importante car au fils des années le tracé des
petits cours d'eaux ce déplace assez rapidement (tout est relatif), si les
frontières suivent les évolutions des cours d'eau, les parcelles doivent
être également mise à jour et certaines peuvent changer de commune tous les
10 ans.

Voici un cas pratique : http://osm.org/go/xVlCL3zZX-
Avant je fusionnai systématiquement cours d'eau et frontière et depuis ce
cas, je sépare systématiquement cours d'eau et frontière. Cette rivière
subie plusieurs crue dans l'hiver et son cours d'eau est changeant, (comme
dans toutes les garrigues d'ailleurs).

Si une route est fusionnée, en cas de modification de la voirie (rond
point, double voie), est ce qu'on doit coller à la route ou pas ? Consulter
systématiquement le cadastre ne semble pas être courant chez les nouveaux
venu ;-/


Le 18 mai 2013 17:34, Christophe Merlet  a écrit :

> Le 18/05/2013 16:48, Jo. a écrit :
>
>  Bonjour,
>>
>>
>> Cela fait des mois qu'à chaque amélioration en précision de cours d'eau,
>> route et terrain fusionné avec une frontière que je perd de long moment
>> à séparer ces chemins. Le plus long étant de contrôler chaque extrémité
>> de segments et les relations impactées.
>>
>
> Si au départ la frontière suis un cours d'eau ou un autre élément naturel,
> améliorer la précision de cet élément améliore la frontière... Pour quoi
> les séparer ? Les frontière du cadastre n'ont qu'une précision limitée.
>
>
> Librement,
> --
> Christophe Merlet (RedFox)
>
> __**_
> 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] Un "robot" pour séparer les frontières des autres éléments

[Marc Sibert]

Le 18/05/2013 16:48, Jo. a écrit :

Bonjour,


Cela fait des mois qu'à chaque amélioration en précision de cours 
d'eau, route et terrain fusionné avec une frontière que je perd de 
long moment à séparer ces chemins. Le plus long étant de contrôler 
chaque extrémité de segments et les relations impactées.


Est ce qu'une personne aurait les connaissances pour créer un robot 
permettant d'automatiser tout cela ? Avec le temps j'ai fait le tour 
des cas particulier et des méthodes pour arriver à un résulta 
fonctionnel et exploitable par tous le monde.


 1. je duplique le segment en le collant au plus près du segment d'origine
 2. je reconnecte les nouveau segments entre eux
 3. je reconnecte les segments qui coupent ou finissent sur la frontière
 4. je supprime les tag redondant (border et similaire d'un coté puis
tous les autres tag sur le nouveau segment)
 5. je met à jour les relations (route, river, highking, ...) en
interchangeant les frontière avec les nouveaux segments
 6. validation JOSM pour contrôle

C'est un travail assez abrutissant et rébarbatif, est ce qu'il serait 
possible d'automatiser tout cela ??? J'offre l'apéro à celui qui 
répondra à ma demande ;-P ce serait l'occasion de ce rencontrer dans 
le sud...



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

Je pense que tu parles de séparer les ways en réutilisant les nodes.

La problématique n'est pas triviale pour un "robot", car :

 * Plusieurs éléments géographiques sont portés par un seul way --> il
   faut donc séparer les tags en groupes pour chacune des "fonctions",
   les boundary, les highway, les waterway, mais surtout leurs tags de
   spécialisation en même temps ; imagine : highway=service +
   service=parking_aisle
 * En plus ces ways peuvent être inclus dans des associations
   (boundary, waterway, road, etc.) --> il se pose le même problème
   qu'avant : à quel groupe va une relation ?

Des idées ? Mais pour moi rien de facilement automatisable en l'état.

A+

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

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

Re: [OSM-talk-fr] défi d'OpenStreetMap pour 2015 : le HANDICAP

[Cédric Moro]

Bonjour Zimmy,

Oui le site est très intéressant sur le fond mais plus critiquable sur la forme.

En effet, le site reste peu adapté aux malvoyants même si à première vue on y 
voit des options pour aggrandir les polices.

Je m'explique, ce site n'est pas du tout adapté à une lecture sur téléphone 
mobile. Déjà qu'il est difficile à lire sur un smartphone pour un voyant, 
j'imagine pour une personne ayant moins de capacités dans ce domaine.

Un thème visuel "responsive" comme bootstrap (c'est à dire dont les éléments 
s'imbriquent en largeur ou en hauteur selon l'espace disponible sur la largeur 
de l'écran) aurait permis :
- d'avoir une carte pleine page, 
- les éléments du menu en haut les uns sous les autres donc plus gros 
- le fameux carré bleu sous ou au dessus de la carte...

Tout aurait donc été bien plus gros en disposant les éléments sur la hauteur 
pour les téléphones mobiles, là où la largeur (et résolution) des écrans fait 
défaut.

Pour le code, mais aussi pour un exemple concret de thème responsive, aller sur 
:
http://twitter.github.io/bootstrap/
Si vous redimensionnez la fenêtre de votre navigateur, vous verrez que ce site 
s'adapte et ses blocs se redisposent en fonction de la largeur disponible. De 
même, si vous le consultez avec un téléphone mobile, vous verrez que sa lecture 
est très aisée.

Vous pouvez aussi regarder cette infographie sur le thème responsive :
http://pinterest.com/pin/372813675373314953/

Bon, nous sommes loin d'OSM mais OSM s'inscrit aussi dans un environnement web 
en mutation dont il peut être intéressant de connaître quelques évolutions 
récentes et majeures.

Merci Zimmy pour ce post très intéressant et à bientôt,

Cédric





Date: Sat, 18 May 2013 11:05:21 +0200
From: ista...@gmail.com
To: talk-fr@openstreetmap.org
Subject: Re: [OSM-talk-fr]  défi d'OpenStreetMap pour 2015 : le HANDICAP

Le 16 mai 2013 23:15, ZIMMY  a écrit :


Le site internet Handistrict a un site intéressant à deux titre : il

considère les handicaps de manière globale et les données qualifiées sont

libres.

http://handistrict.com/handistrict/about



J'ai l'impression que ce site s'adresse surtout aux handicaps moteurs : je ne 
vois pas grand chose sur les handicaps mentaux. 

Niveau handicap moteur, il est sans doute possible de les penser de manière 
globale, si le handicap n'est pas trop fort. Mais les handicaps mentaux ça 
m'étonne qu'on puisse les penser de manière globale, mais tout se discute.



Sous cette réserve mentaux/moteurs, je trouve que le travail est très bien 
fait, et probablement très utile.

 


C'est la raison pour laquelle nous souhaitons avec Jérémie Valentin

promoteur des cartoparties handicap à Montpellier nous souhaitons transposer

l'ontologie OSM sur la grille Handistrict afin de les aider à s'approprier

la base OpenStreetMap. Vos aides sont bienvenues.

https://docs.google.com/spreadsheet/ccc?key=0AoBuAP_kINa7dEMwSW1BOUlEUW9IZ3VrR3hIYWc4NXc#gid=10







Je ne comprends pas bien comment et pourquoi s'utilise ou se manipule ce 
document, qui à l'air intéressant quand même.

"Transposer l'ontologie OSM" ?... J'imagine qu'il s'agit de prendre les 
clefs-valeurs d'OSM et de dire comment elles correspondent aux ids de ce 
fichier ?



À terme, est-ce pour faire des correspondances d'enregistrement de données 
entre les deux bases ? Par exemple, un hotel dans handiscrict et un hotel dans 
osm ? Ou que la sémantique soit la même sans forcément être capables de faire 
la relation des identificateurs ? Ou que les humains collaborent plus 
facilement aux deux projets ? Ou tout, ou rien ?


Pour ce qui est de donner un coup de main, en ce moment, impossible pour moi, 
désolé. Mais fin mai / début juin peut être ?


Cordialement.



___
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] Cartes Garmin... Update ?

[Frédéric Bonifas]

Bonjour,

Je vais essayer de faire une mise à jour dans le week-end. Je n'ai pas
mon GPS avec moi donc j'essaierai de tester au mieux que tout s'est
bien passé, et je reposte ici une fois que c'est fait.

Fred

Le 18 mai 2013 14:20, Vincent Pottier  a écrit :
> Bonjour,
> http://fredericbonifas.free.fr/osm/garmin.html
>
> Les cartes ont plus de trois mois...
> Un petit update ?
> Et si c'est d'ici mercredi... un immense merci.
> Ce serait top ! Je pourrai partir avec des cartes fraîches dans mon GPS.
>
> http://hiking.waymarkedtrails.org/fr/relation/2918033
> 300 km sur des chemins peu balisés. J'ai beaucoup tracé en chair mapping
> avec une trace GPX que m'a envoyé  un romieux qu'on a accueilli.
> Du coup, je ferrai du foot mapping.
>
> 
> J'ai vu qu'il y a des MUL sur OSM et des OSMeurs sur randoner-léger.
> Ce sera 300 km MUL et carto orientée MUL.
>
> On pourrait faire un osmecum pour les MUL...
> 
>
> D'avance, merci.
> --
> FrViPofm



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

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

Re: [OSM-talk-fr] Nouvelles analyses Osmose

[Frédéric Rodrigo]

Le 18/05/2013 17:54, Jo a écrit :> J'aimerais bien savoir comment 
ajouter des erreur que je détectee avec

> mes propres scripts. Il s'agit surtout de relations route itinéraire
> cycliste, randonnée et des arrêts de bus.

Il y a plusieurs possibilité. Le site web (le frontent) affiche juste 
les erreurs reportées. Elles lui sont transmise par des backends. Il 
faut lui envoyer un fichier XML des erreurs dans le bon format.


Le backend principal d'Osmose est en python et est un framework pour 
générer ces listes d'erreurs. Il y a actuellement trois instances en 
France et une en Islande de ce backend, Pourquoi pas une Belgique. Mais 
on peut faire sans.


Tes scripts peuvent être intégré au backend ou non.

> Depuis très récemment la région Bruxelloise a libére tous ses données
> géographiques. Cela veut dire que l'on pourra ajouter tous les bâtiments
> et leurs adresses. Moi, j'aimerais faire cela d'une façon qui impacte 
> le  moindre possible l'historique (il y a déjà beaucoup de bâtiments

> qui sont dans la base.

La dernière rubrique d'Osmose est de l'aide à l'intégration. On peut 
rajouter tes sources d'OpenData dedans. Elle se basent sur une analyseur 
spécial qu'il faut paramétrer en fonction du jeux de donnée. C'est assez 
rapide d'intégrer de nouvelles sources de données.


Frédéric.

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

Re: [OSM-talk-fr] Nouvelles analyses Osmose

[Jo]

déjà beaucoup de bâtiments qui sont dans la base.

(Apparemment j'ai appuyé sur une touche qui a envoyé mon courrier un peu
précoce... mes excuses)

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

Re: [OSM-talk-fr] Nouvelles analyses Osmose

[Jo]

Salut Frédéric,

J'aimerais bien savoir comment ajouter des erreur que je détectee avec mes
propres scripts. Il s'agit surtout de relations route itinéraire cycliste,
randonnée et des arrêts de bus.

Depuis très récemment la région Bruxelloise a libére tous ses données
géographiques. Cela veut dire que l'on pourra ajouter tous les bâtiments et
leurs adresses. Moi, j'aimerais faire cela d'une façon qui impacte le
moindre possible l'historique (il y a déj
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Nouvelles analyses Osmose

[Frédéric Rodrigo]

Le 18/05/2013 14:59, Black Myst a écrit :
> D'après les graphs Osmose, on passe de 1M à presque 2M d'erreurs en
> base :-(
> Va y avoir du travail.
Pas tout à fait,
> Suppression de l'analyse "parent", trop d'effet de bord (en
> Belgique) et pas pertinent dans les erreurs
C'est cette analyse que l'on a supprimé qui produisait beaucoup trop 
d'erreur a tord. Il faut attendre que les statistiques soient recalculée.


Le 18/05/2013 15:38, Eric SIBERT a écrit :>> Analyses des relations de 
type restriction

>> http://osmose.openstreetmap.fr/fr/map/?level=1,2,3&item=3180
> Intéressant. Je découvre que je suis l'auteur initiale de presque toutes
> les relations incorrectes autour de chez moi, relations qui ont été
> endommagées par d'autres contributeurs suite à des changement sur les
> highways. Il y a quand même un blême sur les outils d'édition.
C'est souvent des problèmes d'incompréhension du modèle de la relation 
et un peu aussi d'inversion entre droite et gauche ;).


Pour maxheight, ce sont ces deux trac qui sont à l'origine de l'analyse, 
il y plus d'info dedans :

- http://trac.openstreetmap.fr/ticket/95
- http://trac.openstreetmap.fr/ticket/295


Le 18/05/2013 17:28, Jo. a écrit :

Juste pour précision, en France la hauteur libre en deçà de 4,30 mètres
doit être explicitement indiqué, autrement c'est facultatif.

Je n'ai pas de source très précise à citer mais le J.O. du sénat en 2008
(entre autre) cite cette information


Le 18 mai 2013 17:02, Eric SIBERT mailto:courr...@eric.sibert.fr>> a écrit :

il exisite une classification des routes:

http://cartelie.application.__developpement-durable.gouv.fr/__cartelie/voir.do?carte=__functionalroadclass&service=__SETRA


mais je n'ai pas trouvé de lien entre cette classification et le
"gabari
europeen de 4.50", comme pour la vitesse (130km/h sur autoroute sauf
indication contraire) il y aurait un maxheight en valeur par defaut.


Après, j'ai un contre-exemple qui est l'autoroute de Maurienne. Il y
a des panneaux indiquant que la hauteur limite est de 4,5m, ce qui
est contradictoire avec le fait que ce soit une hauteur implicite.

Ma compréhension du transport routier, c'est que au-delà d'un
certain gabarit (hauteur, largeur, poids, longueur?), tu passes en
convoi exceptionnel avec autorisation à demander à la préfecture à
chaque transport. La préfecture connaît les restrictions hors
gabarit qui ne sont pas indiquées sur le terrain et te fait le routage.

Pour conclure, les infos existent mais c'est confidentiel en terme
d'usage et je ne vois pas l'intérêt de considérer ça comme un manque
dans OSM.

Éric

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





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




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

Re: [OSM-talk-fr] Un "robot" pour séparer les frontières des autres éléments

[Vincent de Château-Thierry]

Bonjour,

Le 18/05/2013 16:48, Jo. a écrit :


Cela fait des mois qu'à chaque amélioration en précision de cours d'eau,
route et terrain fusionné avec une frontière que je perd de long moment
à séparer ces chemins. Le plus long étant de contrôler chaque extrémité
de segments et les relations impactées.

Est ce qu'une personne aurait les connaissances pour créer un robot
permettant d'automatiser tout cela ? Avec le temps j'ai fait le tour des
cas particulier et des méthodes pour arriver à un résulta fonctionnel et
exploitable par tous le monde.

 1. je duplique le segment en le collant au plus près du segment d'origine
 2. je reconnecte les nouveau segments entre eux
 3. je reconnecte les segments qui coupent ou finissent sur la frontière
 4. je supprime les tag redondant (border et similaire d'un coté puis
tous les autres tag sur le nouveau segment)
 5. je met à jour les relations (route, river, highking, …) en
interchangeant les frontière avec les nouveaux segments
 6. validation JOSM pour contrôle

C'est un travail assez abrutissant et rébarbatif, est ce qu'il serait
possible d'automatiser tout cela ??? J'offre l'apéro à celui qui
répondra à ma demande ;-P ce serait l'occasion de ce rencontrer dans le
sud...


Je ne suis pas sûr d'avoir compris le but de ta manip. Est-ce que ce 
serait illustré par les images d'ici :

http://wiki.openstreetmap.org/wiki/WikiProject_France/Tracer_les_limites_administratives#Proposition_1
en considérant que tu veux passer du schéma 1 au schéma 2 ?

Si oui alors le plus efficace serait que tu utilises, dans JOSM, la 
touche F (raccourci pour 'Follow' : suivre), pour avoir 2 ways distincts 
mais utilisant les mêmes noeuds. Tu commences à tracer le 2è way en 
accrochant les noeuds du premier, puis 'F', 'F', 'F' tu verras c'est 
magique.


Si ça n'est pas ça, à savoir que tu veux avoir des noeuds distincts, 
mais des ways au final très proches, parallèles, alors la manip est la 
même, mais ensuite il faut sélectionner le nouveau way, sélectionner en 
plus ses noeuds, taper sur la touche 'G' pour créer _pour ce way_ des 
noeuds distincts, ce qui permet enfin de déplacer le way de qq pixels.

Mais bon... pas sûr de l'intérêt.

vincent



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

Re: [OSM-talk-fr] Nouvelles analyses Osmose

[Eric SIBERT]

Après, j'ai un contre-exemple qui est l'autoroute de Maurienne. Il y a
des panneaux indiquant que la hauteur limite est de 4,5m, ce qui est
contradictoire avec le fait que ce soit une hauteur implicite.



d'accord,
alors dans ce cas l'analyse osmose est vraiment pertinante !
http://osmose.openstreetmap.fr/fr/map/?zoom=16&lat=45.6062&lon=5.23729&item=7130&level=1,2,3


Ce n'est pas l'autoroute de Maurienne. Elle commence là:

http://osmose.openstreetmap.fr/fr/map/?zoom=16&lat=45.55659&lon=6.24593&layers=BFFT&item=7130&level=1,2,3

La limite de hauteur commence au même endroit. Et normalement, je 
l'avais mis (sur l'axe principal, pas dans les branches d'échangeur).


Éric

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

Re: [OSM-talk-fr] Un "robot" pour séparer les frontières des autres éléments

[Christophe Merlet]

Le 18/05/2013 16:48, Jo. a écrit :

Bonjour,


Cela fait des mois qu'à chaque amélioration en précision de cours d'eau,
route et terrain fusionné avec une frontière que je perd de long moment
à séparer ces chemins. Le plus long étant de contrôler chaque extrémité
de segments et les relations impactées.


Si au départ la frontière suis un cours d'eau ou un autre élément 
naturel, améliorer la précision de cet élément améliore la frontière... 
Pour quoi les séparer ? Les frontière du cadastre n'ont qu'une précision 
limitée.



Librement,
--
Christophe Merlet (RedFox)

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

Re: [OSM-talk-fr] Nouvelles analyses Osmose

[Jo.]

Juste pour précision, en France la hauteur libre en deçà de 4,30 mètres
doit être explicitement indiqué, autrement c'est facultatif.

Je n'ai pas de source très précise à citer mais le J.O. du sénat en 2008
(entre autre) cite cette information


Le 18 mai 2013 17:02, Eric SIBERT  a écrit :

> il exisite une classification des routes:
>> http://cartelie.application.**developpement-durable.gouv.fr/**
>> cartelie/voir.do?carte=**functionalroadclass&service=**SETRA
>> mais je n'ai pas trouvé de lien entre cette classification et le "gabari
>> europeen de 4.50", comme pour la vitesse (130km/h sur autoroute sauf
>> indication contraire) il y aurait un maxheight en valeur par defaut.
>>
>
> Après, j'ai un contre-exemple qui est l'autoroute de Maurienne. Il y a des
> panneaux indiquant que la hauteur limite est de 4,5m, ce qui est
> contradictoire avec le fait que ce soit une hauteur implicite.
>
> Ma compréhension du transport routier, c'est que au-delà d'un certain
> gabarit (hauteur, largeur, poids, longueur?), tu passes en convoi
> exceptionnel avec autorisation à demander à la préfecture à chaque
> transport. La préfecture connaît les restrictions hors gabarit qui ne sont
> pas indiquées sur le terrain et te fait le routage.
>
> Pour conclure, les infos existent mais c'est confidentiel en terme d'usage
> et je ne vois pas l'intérêt de considérer ça comme un manque dans OSM.
>
> Éric
>
> __**_
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.**org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Nouvelles analyses Osmose

[didier2020]

Le samedi 18 mai 2013 à 17:02 +0200, Eric SIBERT a écrit : 
> > il exisite une classification des routes:
> > http://cartelie.application.developpement-durable.gouv.fr/cartelie/voir.do?carte=functionalroadclass&service=SETRA
> > mais je n'ai pas trouvé de lien entre cette classification et le "gabari
> > europeen de 4.50", comme pour la vitesse (130km/h sur autoroute sauf
> > indication contraire) il y aurait un maxheight en valeur par defaut.
> 
> Après, j'ai un contre-exemple qui est l'autoroute de Maurienne. Il y a 
> des panneaux indiquant que la hauteur limite est de 4,5m, ce qui est 
> contradictoire avec le fait que ce soit une hauteur implicite.
d'accord,
alors dans ce cas l'analyse osmose est vraiment pertinante !
http://osmose.openstreetmap.fr/fr/map/?zoom=16&lat=45.6062&lon=5.23729&item=7130&level=1,2,3

> Ma compréhension du transport routier, c'est que au-delà d'un certain 
> gabarit (hauteur, largeur, poids, longueur?), tu passes en convoi 
> exceptionnel avec autorisation à demander à la préfecture à chaque 
> transport. La préfecture connaît les restrictions hors gabarit qui ne 
> sont pas indiquées sur le terrain et te fait le routage.
> 
> Pour conclure, les infos existent mais c'est confidentiel en terme 
> d'usage et je ne vois pas l'intérêt de considérer ça comme un manque 
> dans OSM.
> 
> Éric
> 
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr



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

Re: [OSM-talk-fr] Circonscriptions sénatoriales

[Christian Rogel]

Le 18 mai 2013 à 00:42, Philippe Verdy  a écrit :
> Le 17 mai 2013 23:40, Christian Rogel  a 
> écrit :
>> Quand un député n'agit que pour sa circonscription, il trahit son mandat.
>  
> Autant je comprend que les sénateurs aien un autre mandat territorial, mais 
> on a eu des tonnes de députés-maires avec un conflit d'intérêt entre 
> représentant de la "Nation" (une et indivisible selon la Constitution) et 
> représentant territorial.
> 
> Pourtant les électeurs pour la plupart n'élisent aucun sénateur mais sont 
> représentés au plan national par "leur" député qui ne défendraient pas leurs 
> intérêts ? Il n'y aurait donc pas de représentation directe des citoyens au 
> plan national mais uniquement au plan local. Mais là j'ai de gros doutes. Les 
> députés ont toujours agi en fonction de leur territoire d'élection (on 
> appelle ça "clientélisme") ...

Tes interrogations politiques et tes lacunes en instruction civique que j'ai eu 
le tort de souligner, ne concernent personne sur cette liste.
Aurais-tu l'amabilité d'aller bloguer ailleurs?

Christian 


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

Re: [OSM-talk-fr] Nouvelles analyses Osmose

[Eric SIBERT]

il exisite une classification des routes:
http://cartelie.application.developpement-durable.gouv.fr/cartelie/voir.do?carte=functionalroadclass&service=SETRA
mais je n'ai pas trouvé de lien entre cette classification et le "gabari
europeen de 4.50", comme pour la vitesse (130km/h sur autoroute sauf
indication contraire) il y aurait un maxheight en valeur par defaut.


Après, j'ai un contre-exemple qui est l'autoroute de Maurienne. Il y a 
des panneaux indiquant que la hauteur limite est de 4,5m, ce qui est 
contradictoire avec le fait que ce soit une hauteur implicite.


Ma compréhension du transport routier, c'est que au-delà d'un certain 
gabarit (hauteur, largeur, poids, longueur?), tu passes en convoi 
exceptionnel avec autorisation à demander à la préfecture à chaque 
transport. La préfecture connaît les restrictions hors gabarit qui ne 
sont pas indiquées sur le terrain et te fait le routage.


Pour conclure, les infos existent mais c'est confidentiel en terme 
d'usage et je ne vois pas l'intérêt de considérer ça comme un manque 
dans OSM.


Éric

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

[OSM-talk-fr] Un "robot" pour séparer les frontières des autres éléments

[Jo.]

Bonjour,


Cela fait des mois qu'à chaque amélioration en précision de cours d'eau,
route et terrain fusionné avec une frontière que je perd de long moment à
séparer ces chemins. Le plus long étant de contrôler chaque extrémité de
segments et les relations impactées.

Est ce qu'une personne aurait les connaissances pour créer un robot
permettant d'automatiser tout cela ? Avec le temps j'ai fait le tour des
cas particulier et des méthodes pour arriver à un résulta fonctionnel et
exploitable par tous le monde.

   1. je duplique le segment en le collant au plus près du segment d'origine
   2. je reconnecte les nouveau segments entre eux
   3. je reconnecte les segments qui coupent ou finissent sur la frontière
   4. je supprime les tag redondant (border et similaire d'un coté puis
   tous les autres tag sur le nouveau segment)
   5. je met à jour les relations (route, river, highking, …) en
   interchangeant les frontière avec les nouveaux segments
   6. validation JOSM pour contrôle

C'est un travail assez abrutissant et rébarbatif, est ce qu'il serait
possible d'automatiser tout cela ??? J'offre l'apéro à celui qui répondra à
ma demande ;-P ce serait l'occasion de ce rencontrer dans le sud...
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Nouvelles analyses Osmose

[didier2020]

Le samedi 18 mai 2013 à 15:55 +0200, Jo. a écrit : 
> Après 3 semaines d'absence quand j'ai vu mon stats d'erreur passé de
> moins de 2 à plus de 300 j'ai deviné qu'il y a eu du changement. Pas
> mal tout ça surtout pour les cours d'eau même si ça demande beaucoup
> de travail.
> 
> 
> Je plussois la remarque de Eric Sibert, les hauteurs ne sont indiquée
> que si elles sont inférieure aux règles du code de la route. J'aimerai
> avoir un peut plus d'information sur ce qu'il faut faire.
> 
> 
> Je suppose qu'en absence de limitation explicite, on peut oublier
> l'utilisation du tag maxheight et indiquer un "faux positif". Est ce
> que j'ai bon ? Il faudrait l'indiquer sur le wiki d'Osmose.
> 
> 
> 
> Le 18 mai 2013 15:38, Eric SIBERT  a écrit :
> Analyses des relations de type restriction
> http://osmose.openstreetmap.fr/fr/map/?level=1,2,3&item=3180
> 
> 
> Intéressant. Je découvre que je suis l'auteur initiale de
> presque toutes les relations incorrectes autour de chez moi,
> relations qui ont été endommagées par d'autres contributeurs
> suite à des changement sur les highways. Il y a quand même un
> blême sur les outils d'édition. 
> 
> 
> 
> Pont et tunnel, maxheight dans un tunnel ou sous un
> pont manquant,
> détection la tag layer manquant
> http://osmose.openstreetmap.fr/fr/map/?level=1,2,3&item=7130
> 
> 
> Je suis dubitatif. Quand j'ai passé le permis de conduire, les
> limites de hauteurs ne devaient être indiquées que lorsque
> elles étaient inférieures à 4,5 m (6 m  pour les caténaires).
> Pour moi, c'est normal quand maxheight n'est pas renseigné. Et
> je n'ai pas envie de m'arrêter sur l'autoroute sous chaque
> pont croisé pour mesurer la hauteur :-p

il exisite une classification des routes:
http://cartelie.application.developpement-durable.gouv.fr/cartelie/voir.do?carte=functionalroadclass&service=SETRA
mais je n'ai pas trouvé de lien entre cette classification et le "gabari
europeen de 4.50", comme pour la vitesse (130km/h sur autoroute sauf
indication contraire) il y aurait un maxheight en valeur par defaut. Je
me renseigne mardi.

didier

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



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

Re: [OSM-talk-fr] Nouvelles analyses Osmose

[Jo.]

Après 3 semaines d'absence quand j'ai vu mon stats d'erreur passé de moins
de 2 à plus de 300 j'ai deviné qu'il y a eu du changement. Pas mal tout ça
surtout pour les cours d'eau même si ça demande beaucoup de travail.

Je plussois la remarque de Eric Sibert, les hauteurs ne sont indiquée que
si elles sont inférieure aux règles du code de la route. J'aimerai avoir un
peut plus d'information sur ce qu'il faut faire.

Je suppose qu'en absence de limitation explicite, on peut oublier
l'utilisation du tag maxheight et indiquer un "faux positif". *Est ce que
j'ai bon ?* Il faudrait l'indiquer sur le wiki d'Osmose.


Le 18 mai 2013 15:38, Eric SIBERT  a écrit :

> Analyses des relations de type restriction
>> http://osmose.openstreetmap.**fr/fr/map/?level=1,2,3&item=**3180
>>
>
> Intéressant. Je découvre que je suis l'auteur initiale de presque toutes
> les relations incorrectes autour de chez moi, relations qui ont été
> endommagées par d'autres contributeurs suite à des changement sur les
> highways. Il y a quand même un blême sur les outils d'édition.
>
>
>
>  Pont et tunnel, maxheight dans un tunnel ou sous un pont manquant,
>> détection la tag layer manquant
>> http://osmose.openstreetmap.**fr/fr/map/?level=1,2,3&item=**7130
>>
>
> Je suis dubitatif. Quand j'ai passé le permis de conduire, les limites de
> hauteurs ne devaient être indiquées que lorsque elles étaient inférieures à
> 4,5 m (6 m  pour les caténaires). Pour moi, c'est normal quand maxheight
> n'est pas renseigné. Et je n'ai pas envie de m'arrêter sur l'autoroute sous
> chaque pont croisé pour mesurer la hauteur :-p
>
>
> Éric
>
>
> __**_
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.**org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Nouvelles analyses Osmose

[Eric SIBERT]

Analyses des relations de type restriction
http://osmose.openstreetmap.fr/fr/map/?level=1,2,3&item=3180


Intéressant. Je découvre que je suis l'auteur initiale de presque toutes 
les relations incorrectes autour de chez moi, relations qui ont été 
endommagées par d'autres contributeurs suite à des changement sur les 
highways. Il y a quand même un blême sur les outils d'édition.




Pont et tunnel, maxheight dans un tunnel ou sous un pont manquant,
détection la tag layer manquant
http://osmose.openstreetmap.fr/fr/map/?level=1,2,3&item=7130


Je suis dubitatif. Quand j'ai passé le permis de conduire, les limites 
de hauteurs ne devaient être indiquées que lorsque elles étaient 
inférieures à 4,5 m (6 m  pour les caténaires). Pour moi, c'est normal 
quand maxheight n'est pas renseigné. Et je n'ai pas envie de m'arrêter 
sur l'autoroute sous chaque pont croisé pour mesurer la hauteur :-p



Éric

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

Re: [OSM-talk-fr] Cartes Garmin... Update ?

[Guillaume Castagnino]

Le samedi 18 mai 2013 14:20:49 Vincent Pottier a écrit :
> Bonjour,
> http://fredericbonifas.free.fr/osm/garmin.html
> 
> Les cartes ont plus de trois mois...
> Un petit update ?
> Et si c'est d'ici mercredi... un immense merci.
> Ce serait top ! Je pourrai partir avec des cartes fraîches dans mon
> GPS.

Bonjour,

Pour ma part, je charge celle ci : 
http://garmin.openstreetmap.fr/garmin-lann/ elle est mise à jour tous 
les vendredis semble-t-il. Version avec et sans données SRTM.

Après, je n'ai pas réussi à déterminer s'il vaut mieux utiliser celle là 
ou celle de Frédéric Bonifas (hors-mis la fraicheur des données).

Cdt,

-- 
Guillaume Castagnino
ca...@xwing.info / guilla...@castagnino.org


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

Re: [OSM-talk-fr] Nouvelles analyses Osmose

[Black Myst]

D'après les graphs Osmose, on passe de 1M à presque 2M d'erreurs en base :-(
Va y avoir du travail.

En tout cas, bravo tous ceux qui participe à la maintenance de cet outil.
Black Myst


Le 18 mai 2013 14:04, Frédéric Rodrigo  a écrit :

> Bonjour,
>
> Pour ce qui ne le saurait pas encore Osmose est un outil qualité qui
> détecte des anomalies :
> http://osmose.openstreetmap.fr
> http://wiki.openstreetmap.org/**wiki/FR:Osmose
>
> Il n'y avait pas eu de nouvelles analyses dans Osmose depuis un moment,
> mais là il y en a plusieurs à la fois :
>
> Généralisation de la détection de voies qui devraient toujours être
> connectées en fonction de leur nature
> http://osmose.openstreetmap.**fr/fr/map/?level=1,2,3&item=**1210
>
> Cours d'eau non connectés ou sens d'écoulement incorrect
> http://osmose.openstreetmap.**fr/fr/map/?level=1,2,3&item=**1220
>
> Suppression de l'analyse "parent", trop d'effet de bord (en Belgique) et
> pas pertinent dans les erreurs
>
> Détection des pages piétons taggé en double, sur le passage et au carrefour
> http://osmose.openstreetmap.**fr/fr/map/?level=1,2,3&item=**2090
>
> Tag maxspeed incohérent entre highway et zone
> http://osmose.openstreetmap.**fr/fr/map/?level=1,2,3&item=**
> 3032&class=30324
>
> Analyses des relations de type restriction
> http://osmose.openstreetmap.**fr/fr/map/?level=1,2,3&item=**3180
>
> Analyses des relations de type boundary
> http://osmose.openstreetmap.**fr/fr/map/?level=1,2,3&item=**7120
>
> Pont et tunnel, maxheight dans un tunnel ou sous un pont manquant,
> détection la tag layer manquant
> http://osmose.openstreetmap.**fr/fr/map/?level=1,2,3&item=**7130
>
> Ajout de la détection des adresses manquantes à Nantes et Bordeaux depuis
> l'OpenData (en plus de Toulouse)
> http://osmose.openstreetmap.**fr/fr/map/?level=1,2,3&item=**8080
>
> Et pour finir, Osmose est disponible sur un nouveau pays : Monaco.
>
> Si vous avez des remarques ou des questions on est bien sûr toujours
> preneurs.
>
> Frédéric.
>
> __**_
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.**org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Cartes Garmin... Update ?

[OpenSourceWay]

Salut,

Je veux bien participer à l'osmecun, je me fait la HRP en MUL cet été.

D'ailleurs, je suis à la recherche d'un datalogger à louer (stock épuisé 
pour la vente), c'est pour une trace de 800km, donc autonome en énergie, 
et léger !

Pour le mois de juillet.

Léo

Le 18/05/2013 13:20, Vincent Pottier a écrit :

Bonjour,
http://fredericbonifas.free.fr/osm/garmin.html

Les cartes ont plus de trois mois...
Un petit update ?
Et si c'est d'ici mercredi... un immense merci.
Ce serait top ! Je pourrai partir avec des cartes fraîches dans mon GPS.

http://hiking.waymarkedtrails.org/fr/relation/2918033
300 km sur des chemins peu balisés. J'ai beaucoup tracé en chair 
mapping avec une trace GPX que m'a envoyé  un romieux qu'on a accueilli.

Du coup, je ferrai du foot mapping.


J'ai vu qu'il y a des MUL sur OSM et des OSMeurs sur randoner-léger.
Ce sera 300 km MUL et carto orientée MUL.

On pourrait faire un osmecum pour les MUL...


D'avance, merci.
--
FrViPofm

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


--
OpenSourceWay
  skype : opensourceway
  opensourceway.fr.nf


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

[OSM-talk-fr] Cartes Garmin... Update ?

[Vincent Pottier]

Bonjour,
http://fredericbonifas.free.fr/osm/garmin.html

Les cartes ont plus de trois mois...
Un petit update ?
Et si c'est d'ici mercredi... un immense merci.
Ce serait top ! Je pourrai partir avec des cartes fraîches dans mon GPS.

http://hiking.waymarkedtrails.org/fr/relation/2918033
300 km sur des chemins peu balisés. J'ai beaucoup tracé en chair mapping 
avec une trace GPX que m'a envoyé  un romieux qu'on a accueilli.

Du coup, je ferrai du foot mapping.


J'ai vu qu'il y a des MUL sur OSM et des OSMeurs sur randoner-léger.
Ce sera 300 km MUL et carto orientée MUL.

On pourrait faire un osmecum pour les MUL...


D'avance, merci.
--
FrViPofm

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

[OSM-talk-fr] Nouvelles analyses Osmose

[Frédéric Rodrigo]

Bonjour,

Pour ce qui ne le saurait pas encore Osmose est un outil qualité qui 
détecte des anomalies :

http://osmose.openstreetmap.fr
http://wiki.openstreetmap.org/wiki/FR:Osmose

Il n'y avait pas eu de nouvelles analyses dans Osmose depuis un moment, 
mais là il y en a plusieurs à la fois :


Généralisation de la détection de voies qui devraient toujours être 
connectées en fonction de leur nature

http://osmose.openstreetmap.fr/fr/map/?level=1,2,3&item=1210

Cours d'eau non connectés ou sens d'écoulement incorrect
http://osmose.openstreetmap.fr/fr/map/?level=1,2,3&item=1220

Suppression de l'analyse "parent", trop d'effet de bord (en Belgique) et 
pas pertinent dans les erreurs


Détection des pages piétons taggé en double, sur le passage et au carrefour
http://osmose.openstreetmap.fr/fr/map/?level=1,2,3&item=2090

Tag maxspeed incohérent entre highway et zone
http://osmose.openstreetmap.fr/fr/map/?level=1,2,3&item=3032&class=30324

Analyses des relations de type restriction
http://osmose.openstreetmap.fr/fr/map/?level=1,2,3&item=3180

Analyses des relations de type boundary
http://osmose.openstreetmap.fr/fr/map/?level=1,2,3&item=7120

Pont et tunnel, maxheight dans un tunnel ou sous un pont manquant, 
détection la tag layer manquant

http://osmose.openstreetmap.fr/fr/map/?level=1,2,3&item=7130

Ajout de la détection des adresses manquantes à Nantes et Bordeaux 
depuis l'OpenData (en plus de Toulouse)

http://osmose.openstreetmap.fr/fr/map/?level=1,2,3&item=8080

Et pour finir, Osmose est disponible sur un nouveau pays : Monaco.

Si vous avez des remarques ou des questions on est bien sûr toujours 
preneurs.


Frédéric.

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

Re: [OSM-talk-fr] Circonscriptions sénatoriales

[Pierre-Alain Dorange]

Philippe Verdy  wrote:

> C'est assez concasse quand le Sénat se décrit lui-même comme représentant
> les territoires (et tous les sénateurs ont aussi un autre mandat local,
> soit dans la région, soit le département, soit dans la commune (et en 2014
> aussi l'EPCI), voire dans l'arrondissement communal (P-L-M) en tant que
> président/maire ou que membre des conseils associés.
> [...]

Cocasse ou pas, les circonscriptions sénatorailes sont déjà représentés
dans OSM, ce sont bien les départements.

Si ça te motive, par contre tu peux peut être imaginer, proposer puis
créer une relation qui regrouperait ces circonscriptions en indiquant
qu'il s'agit du découpage électorale pour les sénatoriales...

Bien que les relations ne soient a priori pas faite pour faire des
regroupements, mais ça j'ai jamais trop bien compris...

-- 
Pierre-Alain Dorange
OSM experiences : 


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

Re: [OSM-talk-fr] Les limites de communes sont terminées dans la région Languedoc-Roussillon

[Pierre-Alain Dorange]

Philippe Verdy  wrote:

> Puisque le Conseil d'Etat doit maintenant tout avoir au sujet des cantons
> existants (avant leur réforme), peut-être que c'est lui qu'il faut
> contacter pour avoir les textes.

Vas-y, n'hésite pas.

-- 
Pierre-Alain Dorange
OSM experiences : 


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

Re: [OSM-talk-fr] Gael au repos...

[Christian Quest]

Quelques nouvelles de Gaël après l'après-midi passée hier avec lui.

Il se remet d'une belle péritonite avec complication. Encore quelques
tuyaux de branchés, mais moins que d'ordinateurs et de piratebox !

Le moral est bon, malgré les kilomètres qui le séparent de sa famille
ce qui fait que les visites sont peu nombreuses et les journées
longues.

Une petite visite des mappeurs de Caen lui ferait sûrement plaisir, il
est au CHU au moins jusque mardi.
Pour les détails... envoyez-lui un mail à ratzil...@gmail.com

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

Re: [OSM-talk-fr] re rhone alpes

[OpenSourceWay]

Salut,

Je me permet d'ajouter trois choses,

1. Un lien avec des infos pour les nouveaux venus :
   http://openstreetmap.fr/bienvenue (Merci Christian ;))
2. OpenStreetMap diffuse ses données librement, il est évidemment
   interdit d'y ajouter des données privées (qui se retrouveraient
   alors diffusée librement), dons hors de question de se servir de tes
   DVD pour enrichir la base de donnée.
3. Il est plus agréable pour moi si tu faisais un petit effort sur
   l'écriture de tes mails ;), et ta boite mail nous colle des images
   dans chacun de tes mails.

Sur ceux, à bientôt parmi nous !

Léo


Le 18/05/2013 11:30, mic...@bersio.com a écrit :
merci pour ces tuyaux ,je maitrise  l'informatique,mais je faisais mes 
traces soit avec ozi  ,igo8 ,ou compsgps mais ne connais pas vos 
systemes ,je possede la France complete par région ,sur dvd  (ign 
25000 )et je voudrais la mettre a jour ,vaste question,

quand je disais stress,je plaisantais ,je suis d'une extreme patiente


--
OpenSourceWay
  skype : opensourceway
  opensourceway.fr.nf

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

[OSM-talk-fr] re rhone alpes

[mic...@bersio.com]

merci pour ces tuyaux ,je maitrise  l'informatique,mais je faisais mes
traces soit avec ozi  ,igo8 ,ou compsgps mais ne connais pas vos systemes 
je possede la France complete par région ,sur dvd  (ign 25000 )et je
voudrais la mettre a jour ,vaste question,
quand je disais stress,je plaisantais ,je suis d'une extreme patiente <><>___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] tile.osm & déchèteries

[Vincent Pottier]

Un rendu possible pour les déchetteries taguées en area sur tile ?
Merci...
--
FrViPofm

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

Re: [OSM-talk-fr] défi d'OpenStreetMap pour 2015 : le HANDICAP

[Ista Pouss]

Le 16 mai 2013 23:15, ZIMMY  a écrit :

> Le site internet Handistrict a un site intéressant à deux titre : il
> considère les handicaps de manière globale et les données qualifiées sont
> libres.
> http://handistrict.com/handistrict/about
>
>
J'ai l'impression que ce site s'adresse surtout aux handicaps moteurs : je
ne vois pas grand chose sur les handicaps mentaux.

Niveau handicap moteur, il est sans doute possible de les penser de manière
globale, si le handicap n'est pas trop fort. Mais les handicaps mentaux ça
m'étonne qu'on puisse les penser de manière globale, mais tout se discute.

Sous cette réserve mentaux/moteurs, je trouve que le travail est très bien
fait, et probablement très utile.



> C'est la raison pour laquelle nous souhaitons avec Jérémie Valentin
> promoteur des cartoparties handicap à Montpellier nous souhaitons
> transposer
> l'ontologie OSM sur la grille Handistrict afin de les aider à s'approprier
> la base OpenStreetMap. Vos aides sont bienvenues.
>
> https://docs.google.com/spreadsheet/ccc?key=0AoBuAP_kINa7dEMwSW1BOUlEUW9IZ3VrR3hIYWc4NXc#gid=10
>
>
>
Je ne comprends pas bien comment et pourquoi s'utilise ou se manipule ce
document, qui à l'air intéressant quand même.

"Transposer l'ontologie OSM" ?... J'imagine qu'il s'agit de prendre les
clefs-valeurs d'OSM et de dire comment elles correspondent aux ids de ce
fichier ?

À terme, est-ce pour faire des correspondances d'enregistrement de données
entre les deux bases ? Par exemple, un hotel dans handiscrict et un hotel
dans osm ? Ou que la sémantique soit la même sans forcément être capables
de faire la relation des identificateurs ? Ou que les humains collaborent
plus facilement aux deux projets ? Ou tout, ou rien ?

Pour ce qui est de donner un coup de main, en ce moment, impossible pour
moi, désolé. Mais fin mai / début juin peut être ?

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

[OSM-talk-fr] pour les anglophones : ressources des Nations Unis pour le HANDICAP

[ZIMMY]

L'innovation dans OpenStreetMap va franchir un nouveau pas en se distingant
qualitativement des autres fournisseurs de données dans une expertise
délaissée celle du handicap.

J'ai trouvé ce document des Nations Unis qui est très riche. Son avantage
est de donner un standard international qui sera pratique dans notre
démarche mondiale d'harmonisation des méthodes de relevé (tags OSM) :
*Accessibility for the Disabled
A Design Manual for a Barrier Free Environment*
http://www.un.org/esa/socdev/enable/designm/index.html

Du coup j'en ai profité pour mettre à jour l'onglet de transposition du
fichier Handistrict
https://docs.google.com/spreadsheet/ccc?key=0AoBuAP_kINa7dEMwSW1BOUlEUW9IZ3VrR3hIYWc4NXc#gid=10

Un petit coup de main sera bienvenu



-
Cordialement,
ZIMMY
Jean-Louis ZIMMERMANN
Développeur territorial (ville d'Orange,FR84)
Mandataire OSM-France sur le Grand-Sud-est
--
View this message in context: 
http://gis.19327.n5.nabble.com/pour-les-anglophones-ressources-des-Nations-Unis-pour-le-HANDICAP-tp5761602.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] tablette Android ?

[Sylvain Naudin]

Le 18 mai 2013 08:42, Sylvain Naudin  a écrit :

> peut-être avec une version précédente d'Android.



Bon, avec une version en 4.1 sur tablette ça
fonctionne
.

Il faudra que j'attende une mise à jour pour mes Nexus.


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

Re: [OSM-talk-fr] region rhone-Alpes

[Ista Pouss]

Le 18 mai 2013 08:40, mic...@bersio.com  a écrit :

>Bonjour a tous,depuis longtemps je regarde OSM,et ce jour je saute le
> pas ,je vais contribuer ;je suis entre Beaurepaire et Chanas,beaucoup de
> villages pas mis a jour,je vais contribuer a faire avancer ce site,mais il
> faut que je puisse maitrisé  l'outil , vous pouvez m'envoyer des liens
> d'explications, pour que je démare sans sterss
>  a bientot de vous lire
> michel
>
>
Le mieux je pense est de trouver un club osm à proximité et d'y participer,
même rarement. C'est la rencontre qui est importante. Il y a un groupe
local à Grenoble, par exemple :
http://wiki.openstreetmap.org/wiki/Grenoble_groupe_local

Ensuite si vous êtes vraiment archi débutant, peut être utiliser le nouveau
système d'annotation : sur la carte osm, en bas, à droite, vous voyez un
lien "ajouter une note" ; vous en mettez une dizaine avec vos remarques, et
peut être un contributeur plus chevronné les appliquera-t-il, et alors vous
n'aurez plus qu'à regarder ce qu'il a fait ; ça vous apprendra à repérer
les constituants de la carte osm, grâce au lien "parcourir les données de
la carte".

Et sinon... http://wiki.openstreetmap.org/wiki/FR:Main_Page ... comme
éditeur de carte je vous conseille Josm, mais si vous êtes pas familier
avec l'informatique c'est déjà coton. Mais vous pouvez avancer comme la
tortue, comme nous tous... mais sans stress ?? hu... là vous en
demandez trop, je crois ?

Cordialement.


-- 
Les dérives de rue :
Profession émotion 
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr