Re: [OSM-talk-fr] EPCIs & arrondissements

[Christian Rogel]

Le 24/03/11 00:02, Vincent de Chateau-Thierry a écrit :


L'INSEE ajoute les syndicats d'agglomération nouvelle, les omets-tu
volontairement ?


Sur les 9 créés en 1984, 4 ont disparus et cela m'étonnerait que les 5 
restants ne se transforment pas, comme les autres,  en communauté d'agglo.



Mais d'ici là, parler des cantons aujourd'hui "à titre historique",
entre deux tours d'élection cantonale, allons :-)


Les conseillers généraux ne sont, cette fois-ci élus que pour 3 ans.
En 2014, les conseillers territoriaux seront élus selon un quota par 
département qui, nulle part, ne correspond aux cantons.

Le faire-part de ceux-ci est déjà envoyé, mais pas de précipitation...


Christian




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

Re: [OSM-talk-fr] EPCIs & arrondissements

[Vincent de Chateau-Thierry]

Le 23/03/2011 22:42, Christian Rogel a écrit :


Entendons-nous bien, je cherche à tracer la limite entre une carte où la
moindre délimitation de bassins, teritoires, micro-région de 3 hectares
serait incluse alors que seulement 30 pékins sauraient les maintenir en
opposition avec des éléments que le "citoyen lambda" ne perçoit pas,
mais dont il a besoin, au moins en arrière plan.
Le critère implicite est le fonctionnement institutionnel, dans lequel
il est personnellement impliqué, soit parce qu'il élit, soit parce qu'il
paye en le sachant (il le voit écrit sur sa feuille d'impôt).
Un autre critère est une forme de pérennité, d'où ce que je dis sur les
modifications en cours.
Dans l'état actuel des choses, les communes, les communautés de communes
(et assimilés), les départements et les régions ont des chances
raisonnables d'exister encore dans 10 ans.
Tout le reste est ou sera remanié, éventuellement en fonction des
alternances politiques.
Pieren a raison de pointer l'abus du sigle EPCI qui obscurcit le débat,
d'autant que ceux-ci peuvent avoir des objectifs et des natures très
différents.
Je propose de s'en tenir à "communauté de communes", "communautés
d'agglomération" et "communautés urbaines".
Les cantons et les arrondissements, à titre historique?

L'INSEE ajoute les syndicats d'agglomération nouvelle, les omets-tu 
volontairement  ?


Je te rejoins sur le recours au critère de pérennité. Néanmoins, je ne 
cherche pas à mapper par anticipation, en ne considérant des découpages 
qu'à la condition qu'ils soient toujours la dans x années. Ça me semble 
un horizon bien lointain à l'échelle de nos actions, a fortiori quand on 
lui rajoute un aléa dû aux alternances politiques. Le jour où cantons, 
et/ou arrondissements deviennent des découpages obsolètes, le seul 
traitement à leur réserver dans OSM, à mon avis, c'est la suppression. 
Mais d'ici là, parler des cantons aujourd'hui "à titre historique", 
entre deux tours d'élection cantonale, allons :-)


vincent

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

Re: [OSM-talk-fr] EPCIs & arrondissements

[Christian Rogel]

Le 23/03/11 13:39, Vincent de Chateau-Thierry a écrit :


Je refuse de recourir au "citoyen lambda" pour cautionner ce qui doit
être mappé, et surtout ce qui ne doit pas l'être. En réduisant la base à
un dénominateur commun des intérêts de tous, on n'aurait à peu près rien
dans OSM ! On aurait, au mieux, le réseau routier, et encore.
Je vois OSM diamétralement à l'opposé de ta vision : comme la somme des
intérêts / motivations individuel(le)s de chaque mappeur. A suivre ton
raisonnement, on n'aurait pas d'objets avec un nom traduit en breton
dans la base, j'en ai peur ;-)

vincent


Entendons-nous bien, je cherche à tracer la limite entre une carte où la 
moindre délimitation de bassins, teritoires, micro-région de 3 hectares 
serait  incluse alors que seulement 30 pékins sauraient les maintenir en 
opposition avec des éléments que le "citoyen lambda" ne perçoit pas, 
mais dont il a besoin, au moins  en arrière plan.
Le critère implicite est le fonctionnement institutionnel, dans lequel 
il est personnellement impliqué, soit parce qu'il élit, soit parce qu'il 
paye en le sachant (il le voit écrit sur sa feuille d'impôt).
Un autre critère est une forme de pérennité, d'où ce que je dis sur les 
modifications en cours.
Dans l'état actuel des choses, les communes, les communautés de communes 
(et assimilés), les départements et les régions ont des chances 
raisonnables d'exister encore dans 10 ans.
Tout le reste est ou sera remanié, éventuellement en fonction des 
alternances politiques.
Pieren a raison de pointer l'abus du sigle EPCI qui obscurcit le débat, 
d'autant que ceux-ci peuvent avoir des objectifs et des natures très 
différents.
Je propose de s'en tenir à "communauté de communes", "communautés 
d'agglomération" et "communautés urbaines".

Les cantons et les arrondissements, à titre historique?
S'y ajoutent les syndicats de communes gérant les espaces naturels : 
parcs naturels régionaux.
On met aussi les espaces naturels non communaux  : parcs naturels 
nationaux, Conservatoire du littoral, réserves naturelles publiques ou 
privées, mais parce que c'est éventuellement "visitable".


Christian

Note : les autres langues que celles qu'il croit maîtriser  ne relèvent 
pas du citoyen lambda, mais de quelque chose qui le dépasse : les Droits 
de l'Homme.




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

Re: [OSM-talk-fr] Relations routes pour définir des... routes ?

[sylvain letuffe]

Le mercredi 23 mars 2011 20:45:15, Marc Sibert a écrit :

> (...) toutefois les
> relations n'étant pas des catégories («The "relations" we have in
> OpenStreetMap are *not* categories.»), 

Je me répète, mais j'ai peur que l'un de nous deux n'ait pas compris le sens 
de cette phrase
cf : 
http://wiki.openstreetmap.org/wiki/Talk:Relations/Proposed/Collected_Ways_Simple

A noter que je ne prétend pas pour autant être sûr de l'avoir compris, mais 
notre interprétation respective semble différente.

> Par ailleurs, les relations type=route sont à réserver aux circuits
> (attention au faux-ami) et aux regroupements spécifiques (E-road par
> exemple) qui possèdent une référence spécifique au circuit et qui n'a
> souvent rien à voir avec la référence de la voie qui le supporte.

A mon avis, la relation type=route + route=road dont il est question ici n'est 
justement pas un "circuits"

J'ai cependant honte d'indiquer le lien suivant :
http://wiki.openstreetmap.org/wiki/Tag:route=road

Tant le contenu de cette page est incompréhensible.

A compléter avec ce qu'on arrive à tirer de :
http://wiki.openstreetmap.org/wiki/Relation:route

--
sly


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

Re: [OSM-talk-fr] Relations routes pour définir des... routes ?

[Francisco DOS SANTOS]

Une "collection" de tag, ça existe :
http://wiki.openstreetmap.org/wiki/Relations/Proposed/Collected_Ways

Reste à savoir si c'est répandu et reconnu ...

Le mercredi 23 mars 2011 à 21:04 +0100, Greg a écrit :
> Justement, c'est pas idiot cette idée de pouvoir factoriser les tags
> dans une relation...
> Une relation sans type avec en tags "highway=residential", "name=Rue
> des Roses" me choque pas. Mais je ne sais pas si ça se fait ni si
> c'est reconnu.
> 
> 
> Ensuite, c'est sûr que le type=route me semble aussi inadapté.
> 
> 
> 2011/3/23 Marc Sibert 
> Le 23/03/2011 17:39, Vladimir Vyskocil a écrit : 
> 
> > Je rencontre de plus en plus fréquemment des relations route
> > qui ne servent qu'a mettre ensemble des tronçons de chemin
> > avec le même ref et le tag ref n'apparait plus sur les
> > tronçons en eux même. 
> > Par exemple : 
> > 
> > 
> > http://www.openstreetmap.org/browse/relation/312768
> > ref = D 504
> > route = road
> > type = route
> > 
> > 
> > Cela me semble étrange comme usage et ne semble pas
> > correspondre aux cas décrit par le wiki
> > (http://wiki.openstreetmap.org/wiki/FR:Relation:route) qui
> > par exemple décrit plutot des usages comme le regroupement
> > d'autoroutes nationales en itinéraire "E"  européen, ce que
> > je comprend car au niveau chemin les ref sont les refs
> > nationaux et un cran au dessus la relation porte le ref de
> > l'itinéraire européen.
> > 
> > 
> > Qu'en pensez vous ?
> > 
> > 
> > Vlad.
> Bonjour,
> 
> Je suis très circonspect sur cette pratique. Effectivement,
> cela ne semble pas contrevenir à la finalité des relations,
> toutefois les relations n'étant pas des catégories («The
> "relations" we have in OpenStreetMap are not categories.»), je
> ne pense pas que ce soit un bon usage qui plus est dans la
> référence est "factorisée" sur la relation. Je pense que la
> ref et le name sont des attributs obligatoires (si ils
> existent) de tout "highway".
> 
> Par ailleurs, les relations type=route sont à réserver aux
> circuits (attention au faux-ami) et aux regroupements
> spécifiques (E-road par exemple) qui possèdent une référence
> spécifique au circuit et qui n'a souvent rien à voir avec la
> référence de la voie qui le supporte.
> 
> Je dis donc pour cet usage : -1
> 
> mes 0,02 €
> -- 
> Marc Sibert
> 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



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

Re: [OSM-talk-fr] Relations routes pour définir des... routes ?

[sylvain letuffe]

> Cela me semble étrange comme usage et ne semble pas correspondre aux cas
> décrit par le wiki (http://wiki.openstreetmap.org/wiki/FR:Relation:route)
> qui par exemple décrit plutot des usages comme le regroupement
> d'autoroutes nationales en itinéraire "E"  européen, ce que je comprend
> car au niveau chemin les ref sont les refs nationaux et un cran au dessus
> la relation porte le ref de l'itinéraire européen.
> 
> Qu'en pensez vous ?


J'en pense que la relation type=route est devenu le fourre tout pour décrire 
n'importe quoi qui forme une ligne brisée composée d'autres ways

Et que la notion de "route" (c'est à dire "parcours" ou itinéraire en 
français) a disparu de nombre des cas d'utilisation et de propositions sur 
wiki.

J'aurais préféré qu'on utilise un truc comme type=linestring (pour rester plus 
cohérent avec type=multipolygon) mais j'ai l'impression que c'est route qui 
est devenu le mot clef utilisé et je fais avec.

Au delà de cette considération purement de "mot" inadapté, je trouve en 
revanche l'idée très bonne :
Un seul objet la/le représente, factorisation des ref et noms, règle le 
problème des doubles noms pont/tunnels/...

--
sly


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

Re: [OSM-talk-fr] Relations routes pour définir des... routes ?

[hpmt]

Marc Sibert a écrit , Le 23/03/2011 20:45:

Par ailleurs, les relations type=route sont à réserver aux circuits
Je ne sais pas trop comment c'est utilisé dans osm, mais en anglais 
courant "route" est l'équivalent de "itinéraire" en français ;
"circuit" en français (quand il s'agit de tourisme et de voyage), c'est 
"tour" en anglais ; mais bon ...



Hélène


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

Re: [OSM-talk-fr] Relations routes pour définir des... routes ?

[Greg]

Justement, c'est pas idiot cette idée de pouvoir factoriser les tags dans
une relation...
Une relation sans type avec en tags "highway=residential", "name=Rue des
Roses" me choque pas. Mais je ne sais pas si ça se fait ni si c'est reconnu.

Ensuite, c'est sûr que le type=route me semble aussi inadapté.


2011/3/23 Marc Sibert 

>  Le 23/03/2011 17:39, Vladimir Vyskocil a écrit :
>
> Je rencontre de plus en plus fréquemment des relations route qui ne servent
> qu'a mettre ensemble des tronçons de chemin avec le même ref et le tag ref
> n'apparait plus sur les tronçons en eux même.
> Par exemple :
>
>  http://www.openstreetmap.org/browse/relation/312768
>   ref  = D 504
> route  = 
> road
> type  = route
>
>  Cela me semble étrange comme usage et ne semble pas correspondre aux cas
> décrit par le wiki (http://wiki.openstreetmap.org/wiki/FR:Relation:route)
> qui par exemple décrit plutot des usages comme le regroupement d'autoroutes
> nationales en itinéraire "E"  européen, ce que je comprend car au niveau
> chemin les ref sont les refs nationaux et un cran au dessus la relation
> porte le ref de l'itinéraire européen.
>
>  Qu'en pensez vous ?
>
>  Vlad.
>
> Bonjour,
>
> Je suis très circonspect sur cette pratique. Effectivement, cela ne semble
> pas contrevenir à la finalité des relations, toutefois les relations n'étant
> pas des catégories («The "relations" we have in OpenStreetMap are 
> *not*categories.»), je ne pense pas que ce soit un bon usage qui plus est 
> dans la
> référence est "factorisée" sur la relation. Je pense que la ref et le name
> sont des attributs obligatoires (si ils existent) de tout "highway".
>
> Par ailleurs, les relations type=route sont à réserver aux circuits
> (attention au faux-ami) et aux regroupements spécifiques (E-road par
> exemple) qui possèdent une référence spécifique au circuit et qui n'a
> souvent rien à voir avec la référence de la voie qui le supporte.
>
> Je dis donc pour cet usage : -1
>
> mes 0,02 €
>
> --
> Marc sibertm...@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] Relations routes pour définir des... routes ?

[Marc Sibert]

Le 23/03/2011 17:39, Vladimir Vyskocil a écrit :
Je rencontre de plus en plus fréquemment des relations route qui ne 
servent qu'a mettre ensemble des tronçons de chemin avec le même ref 
et le tag ref n'apparait plus sur les tronçons en eux même.

Par exemple :

http://www.openstreetmap.org/browse/relation/312768
ref  = D 504
route  = road 


type  = route


Cela me semble étrange comme usage et ne semble pas correspondre aux 
cas décrit par le wiki 
(http://wiki.openstreetmap.org/wiki/FR:Relation:route) qui par exemple 
décrit plutot des usages comme le regroupement d'autoroutes nationales 
en itinéraire "E"  européen, ce que je comprend car au niveau chemin 
les ref sont les refs nationaux et un cran au dessus la relation porte 
le ref de l'itinéraire européen.


Qu'en pensez vous ?

Vlad.

Bonjour,

Je suis très circonspect sur cette pratique. Effectivement, cela ne 
semble pas contrevenir à la finalité des relations, toutefois les 
relations n'étant pas des catégories («The "relations" we have in 
OpenStreetMap are *not* categories.»), je ne pense pas que ce soit un 
bon usage qui plus est dans la référence est "factorisée" sur la 
relation. Je pense que la ref et le name sont des attributs obligatoires 
(si ils existent) de tout "highway".


Par ailleurs, les relations type=route sont à réserver aux circuits 
(attention au faux-ami) et aux regroupements spécifiques (E-road par 
exemple) qui possèdent une référence spécifique au circuit et qui n'a 
souvent rien à voir avec la référence de la voie qui le supporte.


Je dis donc pour cet usage : -1

mes 0,02 EUR

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

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

Re: [OSM-talk-fr] Re : Re : OsmJumper pour firefox 4 ?

[Vincent Privat]

Tout pareil :)
Super pratique !

Le 23 mars 2011 14:29, Florian LAINEZ  a écrit :

> merci (je découvre et adopte cet addon aujourd'hui même :))
>
> Le 23 mars 2011 14:01, THEVENON Julien  a écrit
> :
>
>>  *De :* rldhont 
>> **
>>  ça y est c'est compatible!
>>
>> Quelle reactivite !
>> ca marche nickel
>>
>> Merci
>> Julien
>>
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/talk-fr
>>
>>
>
>
> --
>
> *Florian Lainez*
> http://twitter.com/overflorian
> http://www.nouslesgeeks.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] Exercice Tsunami Zone Caraïbe - Caribe Wave 11

[simon]

Les lèves tôt ont pus apprécier l'interview de Ratzilla ce matin dans le
journal de l'outre mer sur France inter à 5H30 pour nous annoncer la
simulation.
Podcast ici
http://sites.radiofrance.fr/franceinter/em/un-jour-tout-neuf/index.php?id=102697
 à 31 min environ

Le mercredi 23 mars 2011 à 03:32 +0100, RatZilla$ a écrit : 
> Bonsoir @tou[te]s
> 
> Un exercice de simulation de tsunami est prévu dans la zone Caraïbe 
> aujourd'hui.
> 
> Il est organisé par l'UNESCO pour favoriser la collaboration et la
> transversalité entre les agences en charges des alertes et des
> secours.
> Le Scénario est basé sur un tsunami ayant touché les côtes de la
> Guadeloupe en 1867 avec une hauteur de vague estimée de 10m à
> Sainte-Rose et Deshaies : http://osm.org/go/YzUHcPt
> 
> J'ai ouvert à cette occasion:
> 
> Une page ressource sur le Wiki:
> http://wiki.openstreetmap.org/wiki/WikiProject_France/Caribe_Wave_11
> 
> Elle sera modifiée/(traduite dans la semaine) en cours de journée pour
> suivre l'évolution de la simulation.
> 
> Une Crowdmap:
> http://cw11.crowdmap.com
> 
> Cette page permet de faire des remontées d'incidents et des rapports.
> 
> La simultation commence à 14h00 heure de Paris.
> 
> Le QG est @LaCantine.
> 
> N'hésitez pas à Twitter / Facebooker
> /!\ Bien préciser EXERCICE pour éviter les fausses alertes /!\
> 
> Hashtags #CW11 #CrisisCampParis ou #Exercise_CW11
> 
> Toute la semaine vous pourrez faire des edits et des rapports sur la
> zone comme en cas de crise réel.
> Pour ceux qui veulent s'y mettre et tester la gestion de crise: C'est le 
> moment.
> Les ortho Bing sont plutot bonnes sur la Caraïbe (zone touristique
> oblige) donc n'hésitez pas à mapper (en plus ce sont de jolie iles ;-)
> 
> Bonne Simulation.
> @Bientôt
> 
> ___
> 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

[OSM-talk-fr] nouvelle version de Show Your Journey

[arno]

salut :)
Je viens de mettre en ligne une nouvelle version de Show Your Journey.

Pour ceux qui ne connaissent pas, il s'agit d'un site qui permet de mettre en 
ligne et partager des itinéraires. Exemples: 
http://osm-syj.crans.org/idx/723
http://syj.renevier.net/idx/857

Il y a plusieurs améliorations mineures et corrections de bugs (et même 
probablement quelques ajouts de bugs!) Mais la chose la plus visible, c'est la 
possibilité d'uploader un chemin (kml, gpx, geojson). C'est une fonctionnalité 
qui ne m'est personnellement pas utiles, mais qui était demandée par pas mal 
de monde. Donc voila, c'est fait.

Le truc, c'est que moi, j'avais assez peu de fichiers pour tester, donc si 
jamais il y a des fichiers que vous n'arrivez pas à uploader, n'hésitez pas à 
m'en envoyer une copie pour que je corrige.

Sinon, le site a changé d'url:
http://syj.renevier.net/

l'ancienne url est toujours accessible. Prochainement, l'ancienne url sera 
redirigé sur la nouvelle. C'est à dire qu'elle fonctionnera toujours, mais 
c'est quand même mieux de mettre à jour vos marque-pages dès maintenant.

Voila.
Comme d'hab, je suis ouvert à toutes remarques et critiques sur le site.

a+
arno

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

[OSM-talk-fr] Relations routes pour définir des... routes ?

[Vladimir Vyskocil]

Je rencontre de plus en plus fréquemment des relations route qui ne servent 
qu'a mettre ensemble des tronçons de chemin avec le même ref et le tag ref 
n'apparait plus sur les tronçons en eux même.
Par exemple : 

http://www.openstreetmap.org/browse/relation/312768
ref = D 504
route = road
type = route

Cela me semble étrange comme usage et ne semble pas correspondre aux cas décrit 
par le wiki (http://wiki.openstreetmap.org/wiki/FR:Relation:route) qui par 
exemple décrit plutot des usages comme le regroupement d'autoroutes nationales 
en itinéraire "E"  européen, ce que je comprend car au niveau chemin les ref 
sont les refs nationaux et un cran au dessus la relation porte le ref de 
l'itinéraire européen.

Qu'en pensez vous ?

Vlad.


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

Re: [OSM-talk-fr] "Water makes money"

[Ab_fab]

Sur ce point, Geovelo est un bon très exemple pour démontrer qu'arriver à
une bonne "Experience Utilisateur" avec des outils et des données
cartographiques libres n'est pas impossible (à condition de s'en donner la
peine).

Le 23 mars 2011 17:14, Vincent de Chateau-Thierry  a écrit
:

>
>
> Le 23/03/2011 17:05, Romain MEHUT a écrit :
>
> Qu'est-ce qu'il faut entendre par "une bonne UX"?
>>
>>
> UX pour "User eXperience", autrement dit une bonne "Experience Utilisateur"
> : l'ergonomie, la qualité de l'interface, son caractère intuitif, etc.
>
> vincent
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>



-- 
--
ab_fab

"Il n'y a pas de pas perdus"
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] "Water makes money"

[Sylvain Maillard]

http://circulation.arles.fr/

Le 23 mars 2011 16:30, Romain MEHUT  a écrit :

> La réponse:"*nkb: Nous aimerions beaucoup travailler avec OSM, que nous
> connaissons bien (l’équipe et le service). Maintenant, lorsque nous
> développons pour des clients avec des exigences en termes d’interface
> utilisateur, nous sommes obligés de passer par Google Maps. Si vous avez des
> exemples d’app utilisant OSM avec une bonne UX, je suis preneur!*"
>
> Vous avez des exemples à proposer?
>
> Le 23 mars 2011 14:41, Romain MEHUT  a écrit :
>
>> Bonjour,
>>
>> Suite aux échanges précédents sur 
>> Owni:http://www.mail-archive.com/talk-fr@openstreetmap.org/msg27644.html
>>
>> Une nouvelle application est en ligne depuis hier sur le prix de 
>> l'eau:http://owni.fr/2011/03/22/prix-de-l-eau-crowdsourcing/
>>
>> J'ai laissé un commentaire pour suggérer d'employer OSM:
>> http://owni.fr/2011/03/22/prix-de-l-eau-crowdsourcing/#comment-57182
>>
>> A vous de jouer...
>>
>> Romain
>>
>
>
> ___
> 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] EPCIs & arrondissements

[Christian Rogel]

Le 23/03/11 12:10, Guillaume Allegre a écrit :


Le mer. 23 mars 2011 à 11:34 +0100, Christian Rogel a ecrit :


Donc :
- Ne pas s'inquiéter de limites à vocation éphémère
- Se maintenir au niveau du besoin du citoyen lambda, c'est-à-dire
de ce dont il est amené à parler avec ses voisins et ses collègues.
Les EPCI en font partie , car ils lèvent l'impôt et mettent des
panneaux sur les routes.
Les autres devraient être des couches distinctes.


OK, mais puisqu'on n'a pas de "couches" dans OSM,


J'ai été trop rapide, car, dans mon esprit, je limitais les EPCI à ceux 
qui lèvent l'impôt en mettant dans une autre catégorie ceux n'ont pas de 
fiscalité votée en assemblée, c'est-à-dire ceux qui vivent de taxes 
paraficales et de redevances.
Les limites de ces EPCI de second niveau doivent être  mis dans des 
openlayers pour des besoins spécifiques, afin de créer des couches 
ayant des icônes et des polygones particuliers.
L'un des exemples les plus connus, basé sur une application avec une 
interface de saisie conviviale, est la Carte ouVerte de Rennes.

http://rennes.carte-ouverte.org/


qu'est-ce que tu entends par là _pour OSM_ ? qu'il faut s'occuper seulement des
"EPCI exclusifs", et ne pas chercher à faire un modèle générique ?


Oui, seulement des EPCI qui prennent des décisions politiques 
généralistes, comme les communautés de communes et assimilées, dont les 
conseils sont élus par des gens élus dans les communes.
Les autres EPCI, qui sont aussi élus au deuxième degré, ont en charge 
des politiques extrêmement limitées dans leur objet (maintien des 
ressources en eau, gestion d'incinérateurs, électrification, lutte 
contre les dangers naturels...) en opposition avec les compétences des 
CdC qui peuvent être l'économie, le tourisme, la voirie, parfois la 
jeunesse ou le culturel (plus les ordures ménagères qui sont obligatoires).
Il me semble que c'est aux gens intéressées par les politiques très 
spécifiques de créer ou faire créer les couches spécialisées.


Christian




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

Re: [OSM-talk-fr] Fwd: [job] [STAGE] Intégration données dans MaxSea TimeZero - Bidart (64)

[Vincent de Chateau-Thierry]

Le 23/03/2011 16:51, Nicolas Moyroud a écrit :

Le 23/03/2011 15:59, Rodolphe Quiedeville a écrit :

Aucune mention de :

- s'assurer de la compatibilité légales des imports

Dommage :)


C'est "juste" le point le plus crucial, en effet. La licence passe avant 
la technique...



Oui surtout qu'ils ont l'air de penser que les données Google Earth sont
"libres de droits"...



Oui. Pour info, j'ai déjà remonté ce point au recruteur.

vincent

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

Re: [OSM-talk-fr] "Water makes money"

[Vincent de Chateau-Thierry]

Le 23/03/2011 17:05, Romain MEHUT a écrit :

Qu'est-ce qu'il faut entendre par "une bonne UX"?



UX pour "User eXperience", autrement dit une bonne "Experience 
Utilisateur" : l'ergonomie, la qualité de l'interface, son caractère 
intuitif, etc.


vincent

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

Re: [OSM-talk-fr] "Water makes money"

[Romain MEHUT]

Qu'est-ce qu'il faut entendre par "une bonne UX"?

Le 23 mars 2011 17:02, Pierre-André Le Ny  a écrit :

> Bonjour à tous,
>
> http://open.mapquest.com/
> La version qui utilise OSM.
>
> sinon GéoBretagne.
>
> http://www.geobretagne.org
>
> ++
> PA
>
>
> Le 23 mars 2011 16:47, Florian LAINEZ  a écrit :
>
> http://www.mapquest.com ?
>> http://vgps.paris.fr ?
>>
>> moi aussi ça m'intéresse d'avoir d'autres exemples !
>>
>> Le 23 mars 2011 16:30, Romain MEHUT  a écrit :
>>
>>> La réponse:"*nkb: Nous aimerions beaucoup travailler avec OSM, que nous
>>> connaissons bien (l’équipe et le service). Maintenant, lorsque nous
>>> développons pour des clients avec des exigences en termes d’interface
>>> utilisateur, nous sommes obligés de passer par Google Maps. Si vous avez des
>>> exemples d’app utilisant OSM avec une bonne UX, je suis preneur!*"
>>>
>>> Vous avez des exemples à proposer?
>>>
>>> Le 23 mars 2011 14:41, Romain MEHUT  a écrit :
>>>
 Bonjour,

 Suite aux échanges précédents sur 
 Owni:http://www.mail-archive.com/talk-fr@openstreetmap.org/msg27644.html

 Une nouvelle application est en ligne depuis hier sur le prix de 
 l'eau:http://owni.fr/2011/03/22/prix-de-l-eau-crowdsourcing/

 J'ai laissé un commentaire pour suggérer d'employer OSM:
 http://owni.fr/2011/03/22/prix-de-l-eau-crowdsourcing/#comment-57182

 A vous de jouer...

 Romain

>>>
>>>
>>> ___
>>> Talk-fr mailing list
>>> Talk-fr@openstreetmap.org
>>> http://lists.openstreetmap.org/listinfo/talk-fr
>>>
>>>
>>
>>
>> --
>>
>> *Florian Lainez*
>> http://twitter.com/overflorian
>> http://www.nouslesgeeks.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
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] "Water makes money"

[Pierre-André Le Ny]

Bonjour à tous,

http://open.mapquest.com/
La version qui utilise OSM.

sinon GéoBretagne.

http://www.geobretagne.org

++
PA


Le 23 mars 2011 16:47, Florian LAINEZ  a écrit :

> http://www.mapquest.com ?
> http://vgps.paris.fr ?
>
> moi aussi ça m'intéresse d'avoir d'autres exemples !
>
> Le 23 mars 2011 16:30, Romain MEHUT  a écrit :
>
>> La réponse:"*nkb: Nous aimerions beaucoup travailler avec OSM, que nous
>> connaissons bien (l’équipe et le service). Maintenant, lorsque nous
>> développons pour des clients avec des exigences en termes d’interface
>> utilisateur, nous sommes obligés de passer par Google Maps. Si vous avez des
>> exemples d’app utilisant OSM avec une bonne UX, je suis preneur!*"
>>
>> Vous avez des exemples à proposer?
>>
>> Le 23 mars 2011 14:41, Romain MEHUT  a écrit :
>>
>>> Bonjour,
>>>
>>> Suite aux échanges précédents sur 
>>> Owni:http://www.mail-archive.com/talk-fr@openstreetmap.org/msg27644.html
>>>
>>> Une nouvelle application est en ligne depuis hier sur le prix de 
>>> l'eau:http://owni.fr/2011/03/22/prix-de-l-eau-crowdsourcing/
>>>
>>> J'ai laissé un commentaire pour suggérer d'employer OSM:
>>> http://owni.fr/2011/03/22/prix-de-l-eau-crowdsourcing/#comment-57182
>>>
>>> A vous de jouer...
>>>
>>> Romain
>>>
>>
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/talk-fr
>>
>>
>
>
> --
>
> *Florian Lainez*
> http://twitter.com/overflorian
> http://www.nouslesgeeks.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] Fwd: [job] [STAGE] Intégration données dans MaxSea TimeZero - Bidart (64)

[Nicolas Moyroud]

  
  
Le 23/03/2011 15:59, Rodolphe Quiedeville a écrit :

  Aucune mention de :

- s'assurer de la compatibilité légales des imports

Dommage :)


Oui surtout qu'ils ont l'air de penser que les données Google Earth
sont "libres de droits"...
  


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

Re: [OSM-talk-fr] "Water makes money"

[Florian LAINEZ]

http://www.mapquest.com ?
http://vgps.paris.fr ?

moi aussi ça m'intéresse d'avoir d'autres exemples !

Le 23 mars 2011 16:30, Romain MEHUT  a écrit :

> La réponse:"*nkb: Nous aimerions beaucoup travailler avec OSM, que nous
> connaissons bien (l’équipe et le service). Maintenant, lorsque nous
> développons pour des clients avec des exigences en termes d’interface
> utilisateur, nous sommes obligés de passer par Google Maps. Si vous avez des
> exemples d’app utilisant OSM avec une bonne UX, je suis preneur!*"
>
> Vous avez des exemples à proposer?
>
> Le 23 mars 2011 14:41, Romain MEHUT  a écrit :
>
>> Bonjour,
>>
>> Suite aux échanges précédents sur 
>> Owni:http://www.mail-archive.com/talk-fr@openstreetmap.org/msg27644.html
>>
>> Une nouvelle application est en ligne depuis hier sur le prix de 
>> l'eau:http://owni.fr/2011/03/22/prix-de-l-eau-crowdsourcing/
>>
>> J'ai laissé un commentaire pour suggérer d'employer OSM:
>> http://owni.fr/2011/03/22/prix-de-l-eau-crowdsourcing/#comment-57182
>>
>> A vous de jouer...
>>
>> Romain
>>
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>
>


-- 

*Florian Lainez*
http://twitter.com/overflorian
http://www.nouslesgeeks.fr
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] "Water makes money"

[Romain MEHUT]

La réponse:"*nkb: Nous aimerions beaucoup travailler avec OSM, que nous
connaissons bien (l’équipe et le service). Maintenant, lorsque nous
développons pour des clients avec des exigences en termes d’interface
utilisateur, nous sommes obligés de passer par Google Maps. Si vous avez des
exemples d’app utilisant OSM avec une bonne UX, je suis preneur!*"

Vous avez des exemples à proposer?

Le 23 mars 2011 14:41, Romain MEHUT  a écrit :

> Bonjour,
>
> Suite aux échanges précédents sur 
> Owni:http://www.mail-archive.com/talk-fr@openstreetmap.org/msg27644.html
>
> Une nouvelle application est en ligne depuis hier sur le prix de 
> l'eau:http://owni.fr/2011/03/22/prix-de-l-eau-crowdsourcing/
>
> J'ai laissé un commentaire pour suggérer d'employer OSM:
> http://owni.fr/2011/03/22/prix-de-l-eau-crowdsourcing/#comment-57182
>
> A vous de jouer...
>
> Romain
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Fwd: [job] [STAGE] Intégration données dans MaxSea TimeZero - Bidart (64)

[Rodolphe Quiedeville]

Le 23/03/2011 15:13, Vincent de Chateau-Thierry a écrit :
> Vu sur Georezo. Un stage qui, potentiellement, donne l'opportunité de
> manipuler de la donnée OSM.
> 
[...]
> [STAGE] Intégration données libres dans MaxSea TimeZero - Bidart (64)
> 
> Au sein de l’entité MapMedia (intégrateur de contenus cartographiques
> pour la société MaxSea International), le stage consistera à proposer
> une solution technique, en accord avec l’équipe de développement, visant
> à transformer des objets géographiques libres de droit (issus
> d’OpenStreetMap, de GoogleEarth,…) afin d’assurer leur compatibilité
> avec notre logiciel de navigation maritime TimeZero.
> 
> Ce stage sera réalisé en plusieurs étapes :
> - Recenser les sources de données disponibles
> - Faire une bibliographie des normes
> - Assurer une méthode d’acquisition cohérente avec notre modèle de donnée
> - Transformer et intégrer les données
> - Proposer une maquette du rendu dans le logiciel MaxSea TimeZero
> - Aborder le sujet de l’intégration d’objets 3D (Google SketchUp,…)
> - Rédiger un rapport de stage

Aucune mention de :

- s'assurer de la compatibilité légales des imports

Dommage :)

-- 
Rodolphe Quiédeville
http://cartosm.eu - Intégration de carte libre sur site web
Blog : http://blog.rodolphe.quiedeville.org/
SIP/XMPP : rodol...@quiedeville.org

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

[OSM-talk-fr] Fwd: [job] [STAGE] Intégration données dans MaxSea TimeZero - Bidart (64)

[Vincent de Chateau-Thierry]

Vu sur Georezo. Un stage qui, potentiellement, donne l'opportunité de 
manipuler de la donnée OSM.


vincent

 Message original 
Sujet: [job] [STAGE] Intégration données dans MaxSea TimeZero - Bidart (64)
Date : Wed, 23 Mar 2011 12:28:32 +0100
De : j...@georezo.net
Répondre à : j...@georezo.net
Pour : j...@ml.georezo.net


Annonce postée par : MapMedia (arnaud.r...@maxsea.fr)



[STAGE] Intégration données libres dans MaxSea TimeZero - Bidart (64)

Au sein de l’entité MapMedia (intégrateur de contenus cartographiques 
pour la société MaxSea International), le stage consistera à proposer 
une solution technique, en accord avec l’équipe de développement, visant 
à transformer des objets géographiques libres de droit (issus 
d’OpenStreetMap, de GoogleEarth,…) afin d’assurer leur compatibilité 
avec notre logiciel de navigation maritime TimeZero.


Ce stage sera réalisé en plusieurs étapes :
- Recenser les sources de données disponibles
- Faire une bibliographie des normes
- Assurer une méthode d’acquisition cohérente avec notre modèle de donnée
- Transformer et intégrer les données
- Proposer une maquette du rendu dans le logiciel MaxSea TimeZero
- Aborder le sujet de l’intégration d’objets 3D (Google SketchUp,…)
- Rédiger un rapport de stage

Durée du stage : de 4 à 6 mois

Profil :
- Minimum BAC + 3 en géomatique ou fin d'études d'ingénieur
- Connaissance des outils standards SIG
- Bases de données (SQL Server, Postgres/PostGIS,...)
- Notions en développement informatique

Lieu du stage : Bidart (64) dans les locaux de Maxsea International / 
MapMedia


Gratification : à déterminer

Contact : Arnaud REMY - Directeur Technique MapMedia
arnaud.r...@maxsea.fr



L'annonce est située 
http://georezo.net/forum/viewtopic.php?pid=188380#p188380

Pour vous désabonner connectez-vous sur le forum puis Profil / Abonnement


--
Association GeoRezo - le portail géomatique
http://georezo.net

(Message généré automatiquement. Ne pas répondre à ce message, utiliser 
les coordonnées contenues dans l'annonce)




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

[OSM-talk-fr] "Water makes money"

[Romain MEHUT]

Bonjour,

Suite aux échanges précédents sur
Owni:http://www.mail-archive.com/talk-fr@openstreetmap.org/msg27644.html

Une nouvelle application est en ligne depuis hier sur le prix de
l'eau:http://owni.fr/2011/03/22/prix-de-l-eau-crowdsourcing/

J'ai laissé un commentaire pour suggérer d'employer OSM:
http://owni.fr/2011/03/22/prix-de-l-eau-crowdsourcing/#comment-57182

A vous de jouer...

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

Re: [OSM-talk-fr] Re : Re : OsmJumper pour firefox 4 ?

[Florian LAINEZ]

merci (je découvre et adopte cet addon aujourd'hui même :))

Le 23 mars 2011 14:01, THEVENON Julien  a écrit :

>  *De :* rldhont 
> **
>  ça y est c'est compatible!
>
> Quelle reactivite !
> ca marche nickel
>
> Merci
> Julien
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>
>


-- 

*Florian Lainez*
http://twitter.com/overflorian
http://www.nouslesgeeks.fr
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] EPCIs & arrondissements

[Vincent de Chateau-Thierry]

Le 23/03/2011 13:54, Guillaume Allegre a écrit :


Le mer. 23 mars 2011 à 13:29 +0100, Vincent de Chateau-Thierry a ecrit :


Moins nombreux ? Prenons un damier, soit 8 x 8 cases. Pour 64 cases,
seules 8+8+6+6=28 cases partagent une limite avec l'extérieur. Si tu
transposes ce damier en une comcom (une case = une commune), la
relation que tu souhaites aurait 64 membres, celle que je propose 29
(les 28 limites + un admin_centre), voire un peu plus que 29 car
certaines limites seraient scindées du fait des découpages des
communes hors comcom.


*beaucoup plus* que 29 : de nombreuses communes ont leurs limites scindées
en d'autres points qu'un changement de commune voisine :
souvent quand une limite entre communes change de "support"
(passe d'une route à une autre route, ou un cours d'eau, etc.).


Si tu traces en t'appuyant sur les routes et cours d'eau, en effet. De 
mon côté je trace toujours un way à part, quitte à reprendre des nodes 
utilisés par des routes ou rivières. D'où une plus faible inflation.





Concrètement, on a ce cas par exemple avec le département 86 : 281
communes, et seulement 178 membres dans la relation qui décrit le
contour de département.


Ton exemple est spécieux : j'ai bien expliqué ma position pour les EPCI,
pas pour les départements et régions.
Pour les départements (et encore plus les régions), les communes frontières
sont proportionnellement bien moins nombreuses que pour des EPCI.


Arf :-) Le but n'était pas de dévier, mais de montrer que la situation 
que je décrivais en théorie (le damier) se retrouve concrètement.





Donc aucune règle ne te dira combien de limites sont nécessaires en
fonction du nombre de surfaces considérées, l'argument de la
complexité d'édition ne tient pas.


D'une part, je pense qu'il tient, d'autre part dans la "complexité d'édition",
il n'y a pas que le nombre d'objets, mais aussi le fait que les objets soient
facilement compréhensibles par l'utilisateur.
Et un objet way 39078124 est largement moins facile à manipuler que
l'objet relation "MaCommune", donc plus sujet à erreurs.

Là dessus, je ne te rejoins pas. Manipuler des relations de relations, 
je trouve ça plus compliqué / plus abstrait que manipuler des relations 
de ways "bruts".




Tout comme un département, voire une région ou un pays. Tous ces
niveaux peuvent être définis par une accumulation de communes, ça
n'empêche pas le modèle actuel (par limites) de fonctionner.


Ah, on tourne en rond dans l'argumentation là.


:-)


Je ne dis pas que le modèle actuel ne fonctionne pas, au contraire.
Je dis que dans le cas des EPCI on peut trouver un meilleur modèle, plus 
"moderne"
et que ça vaut le coup d'essayer pour simplifier la tâche des utilisateurs
qui vont se charger de la saisie.


Ok, je comprends cette motivation (simplifier la tâche), en revanche je 
trouve plus compliqué ce que tu trouve plus simple (voir ci-dessus).



Dans le fil actuel, on ne parle en effet que des EPCIs à fiscalité
propre. Chaque commune ne peut appartenir qu'à un seul de ces EPCIs
à la fois. Il n'y a pas, que je sache, d'opposition particulière à
mapper les autres EPCIs, il manque juste des "porteurs" pour le
sujet, bref avis aux motivés : imaginer le modèle géométrique, le
modèle de tags, discuter le tout... yapluka :-)


Ben voilà, on y est : la proposition de relation de relations-communes
(ou somme de surfaces) a le mérite d'avoir un seul modèle applicable à
tous les EPCI (donc à fiscalité propre ou pas).


Le modèle par limites est tout autant applicable. Ce débat sur le modèle 
géométrique, encore une fois, est récurrent, et les deux façons 
(surfaces vs limites) permettent grosso-modo d'arriver aux mêmes fins. 
Mon "yapluka" s'applique surtout au choix des tags pour décrire un SIVOM 
ou autre. Les tags existants suffisent-ils ? Les valeurs existantes ? 
Que faut-il créer comme nouveaux tags, nouvelles valeurs ? C'est à mon 
avis sur ce point que la discussion doit explorer.


vincent

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

[OSM-talk-fr] Re : Re : OsmJumper pour firefox 4 ?

[THEVENON Julien]

 De : rldhont 


  ça y est c'est compatible!

Quelle reactivite !
ca marche nickel

Merci
Julien



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

Re: [OSM-talk-fr] EPCIs & arrondissements

[Guillaume Allegre]

Le mer. 23 mars 2011 à 13:29 +0100, Vincent de Chateau-Thierry a ecrit :
> 
> 
> Le 23/03/2011 10:47, Guillaume Allegre a écrit :
> >
> >Le mer. 23 mars 2011 à 09:35 +0100, Damouns a ecrit :
> >>>L'avantage des EPCIs "relations de communes", c'est qu'il serait bien plus 
> >>>facile de les éditer,
> >>>puisqu'elles regrouperaient :
> >>>- des objets moins nombreux et de plus haut niveau
> 
> Moins nombreux ? Prenons un damier, soit 8 x 8 cases. Pour 64 cases,
> seules 8+8+6+6=28 cases partagent une limite avec l'extérieur. Si tu
> transposes ce damier en une comcom (une case = une commune), la
> relation que tu souhaites aurait 64 membres, celle que je propose 29
> (les 28 limites + un admin_centre), voire un peu plus que 29 car
> certaines limites seraient scindées du fait des découpages des
> communes hors comcom.

*beaucoup plus* que 29 : de nombreuses communes ont leurs limites scindées
en d'autres points qu'un changement de commune voisine :
souvent quand une limite entre communes change de "support"
(passe d'une route à une autre route, ou un cours d'eau, etc.).


> Concrètement, on a ce cas par exemple avec le département 86 : 281
> communes, et seulement 178 membres dans la relation qui décrit le
> contour de département.

Ton exemple est spécieux : j'ai bien expliqué ma position pour les EPCI,
pas pour les départements et régions.
Pour les départements (et encore plus les régions), les communes frontières
sont proportionnellement bien moins nombreuses que pour des EPCI.


> Donc aucune règle ne te dira combien de limites sont nécessaires en
> fonction du nombre de surfaces considérées, l'argument de la
> complexité d'édition ne tient pas.

D'une part, je pense qu'il tient, d'autre part dans la "complexité d'édition",
il n'y a pas que le nombre d'objets, mais aussi le fait que les objets soient
facilement compréhensibles par l'utilisateur.
Et un objet way 39078124 est largement moins facile à manipuler que 
l'objet relation "MaCommune", donc plus sujet à erreurs.




> >>>- les données "naturelles" dans ce contexte : une ComCom est toujours 
> >>>définie par la liste
> >>>des communes adhérentes, pas par ses limites
> 
> Tout comme un département, voire une région ou un pays. Tous ces
> niveaux peuvent être définis par une accumulation de communes, ça
> n'empêche pas le modèle actuel (par limites) de fonctionner.

Ah, on tourne en rond dans l'argumentation là.
Je ne dis pas que le modèle actuel ne fonctionne pas, au contraire.
Je dis que dans le cas des EPCI on peut trouver un meilleur modèle, plus 
"moderne"
et que ça vaut le coup d'essayer pour simplifier la tâche des utilisateurs
qui vont se charger de la saisie.


> >Je ne connais pas bien le sujet, mais il me semble qu'on devrait aussi
> >englober des syndicats de communes, comme les syndicats de gestion des cours
> >d'eau, etc. qui ne sont pas exclusifs.
> >À moins que ce point ait déjà été discuté ici et tranché en faveur des EPCI
> >exclusifs uniquement, mais je n'en ai pas le souvenir.
> >
> Dans le fil actuel, on ne parle en effet que des EPCIs à fiscalité
> propre. Chaque commune ne peut appartenir qu'à un seul de ces EPCIs
> à la fois. Il n'y a pas, que je sache, d'opposition particulière à
> mapper les autres EPCIs, il manque juste des "porteurs" pour le
> sujet, bref avis aux motivés : imaginer le modèle géométrique, le
> modèle de tags, discuter le tout... yapluka :-)

Ben voilà, on y est : la proposition de relation de relations-communes
(ou somme de surfaces) a le mérite d'avoir un seul modèle applicable à
tous les EPCI (donc à fiscalité propre ou pas).



-- 
 ° /\Guillaume AllègreMembre de l'April
  /~~\/\   allegre.guilla...@free.fr  Promouvoir et défendre le logiciel libre
 /   /~~\tél. 04.76.63.26.99  http://www.april.org

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

Re: [OSM-talk-fr] EPCIs & arrondissements

[Vincent de Chateau-Thierry]

Le 23/03/2011 11:34, Christian Rogel a écrit :



Comme je l'ai déjà souligné, les structures administratives de la France
sont en plein bouleversement.
Une loi sur la fusion des postes de conseillers généraux et de
conseillers régionaux vient d'être votée et elle appelle d'autres
modifications comme la suppression des cantons et probablement celle des
arrondissements..
Les syndicats locaux d'électrification devraient être fusionnés en un
seul syndicat départemental.
La prochaine élection présidentielle peut apporter encore d'autres
changements.
Donc :
- Ne pas s'inquiéter de limites à vocation éphémère
- Se maintenir au niveau du besoin du citoyen lambda, c'est-à-dire de ce
dont il est amené à parler avec ses voisins et ses collègues.


Je refuse de recourir au "citoyen lambda" pour cautionner ce qui doit 
être mappé, et surtout ce qui ne doit pas l'être. En réduisant la base à 
un dénominateur commun des intérêts de tous, on n'aurait à peu près rien 
dans OSM ! On aurait, au mieux, le réseau routier, et encore.
Je vois OSM diamétralement à l'opposé de ta vision : comme la somme des 
intérêts / motivations individuel(le)s de chaque mappeur. A suivre ton 
raisonnement, on n'aurait pas d'objets avec un nom traduit en breton 
dans la base, j'en ai peur ;-)


vincent

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

Re: [OSM-talk-fr] Re : OsmJumper pour firefox 4 ?

[rldhont]

ça y est c'est compatible!



Le 23/03/2011 12:41, THEVENON Julien a écrit :

 *De :* rldhont 
  **Le 23/03/2011 11:47, Erik Amzallag a écrit :
  La version actuelle de OsmJumper n'est pas compatible avec 
Firefox 4.

  Un portage est-il prévu ? :)


 Oui, faut juste trouver le temps ;-)

Cool je me posais la meme questions, merci d avance

Julien


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


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

Re: [OSM-talk-fr] EPCIs & arrondissements

[Vincent de Chateau-Thierry]

Le 23/03/2011 10:47, Guillaume Allegre a écrit :


Le mer. 23 mars 2011 à 09:35 +0100, Damouns a ecrit :

L'avantage des EPCIs "relations de communes", c'est qu'il serait bien plus 
facile de les éditer,
puisqu'elles regrouperaient :
- des objets moins nombreux et de plus haut niveau


Moins nombreux ? Prenons un damier, soit 8 x 8 cases. Pour 64 cases, 
seules 8+8+6+6=28 cases partagent une limite avec l'extérieur. Si tu 
transposes ce damier en une comcom (une case = une commune), la relation 
que tu souhaites aurait 64 membres, celle que je propose 29 (les 28 
limites + un admin_centre), voire un peu plus que 29 car certaines 
limites seraient scindées du fait des découpages des communes hors comcom.
Concrètement, on a ce cas par exemple avec le département 86 : 281 
communes, et seulement 178 membres dans la relation qui décrit le 
contour de département.
Donc aucune règle ne te dira combien de limites sont nécessaires en 
fonction du nombre de surfaces considérées, l'argument de la complexité 
d'édition ne tient pas.



- les données "naturelles" dans ce contexte : une ComCom est toujours définie 
par la liste
des communes adhérentes, pas par ses limites


Tout comme un département, voire une région ou un pays. Tous ces niveaux 
peuvent être définis par une accumulation de communes, ça n'empêche pas 
le modèle actuel (par limites) de fonctionner.




Dans ce cas j'ai l'impression (personnelle) qu'OSM n'apporterait
aucune valeur ajoutée par rapport aux sites officiels (INSEE...) qui
donnent pour chaque EPCI la liste de ses communes. En outre, les
relations de relation, c'est encore mal géré par les outils autour
d'OSM (mais bon, ça c'est un problème d'outil).


+1



Je ne connais pas bien le sujet, mais il me semble qu'on devrait aussi
englober des syndicats de communes, comme les syndicats de gestion des cours
d'eau, etc. qui ne sont pas exclusifs.
À moins que ce point ait déjà été discuté ici et tranché en faveur des EPCI
exclusifs uniquement, mais je n'en ai pas le souvenir.

Dans le fil actuel, on ne parle en effet que des EPCIs à fiscalité 
propre. Chaque commune ne peut appartenir qu'à un seul de ces EPCIs à la 
fois. Il n'y a pas, que je sache, d'opposition particulière à mapper les 
autres EPCIs, il manque juste des "porteurs" pour le sujet, bref avis 
aux motivés : imaginer le modèle géométrique, le modèle de tags, 
discuter le tout... yapluka :-)


vincent

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

Re: [OSM-talk-fr] EPCIs & arrondissements

[Pieren]

2011/3/23 Christian Rogel 

> Se maintenir au niveau du besoin du citoyen lambda, c'est-à-dire de ce dont
> il est amené à parler avec ses voisins et ses collègues.
> Les EPCI en font partie
>
>
Euh, on doit pas avoir la même idée du citoyen lambda alors. Même si tout le
monde a une vague idée de ce que veut dire 'communauté de
communes/agglomérations/urbaines', la plutpart ne savent pas que ça
s'appelle "EPCI" et quelles en sont les compétences.

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

[OSM-talk-fr] Re : OsmJumper pour firefox 4 ?

[THEVENON Julien]

 De : rldhont 

  Le 23/03/2011 11:47, Erik Amzallag a écrit : 
   La version actuelle de OsmJumper n'est pas compatible avec Firefox   
  
4.
>   Un portage est-il prévu ? :)
>
 Oui, faut juste trouver le temps ;-)

Cool je me posais la meme questions, merci d avance

Julien



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

Re: [OSM-talk-fr] OsmJumper pour firefox 4 ?

[rldhont]

Le 23/03/2011 11:47, Erik Amzallag a écrit :

Bonjour,

La version actuelle de OsmJumper n'est pas compatible avec Firefox 4.
Un portage est-il prévu ? :)


Oui, faut juste trouver le temps ;-)



Erik


___
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] EPCIs & arrondissements

[Guillaume Allegre]

Le mer. 23 mars 2011 à 11:34 +0100, Christian Rogel a ecrit :

> Donc :
> - Ne pas s'inquiéter de limites à vocation éphémère
> - Se maintenir au niveau du besoin du citoyen lambda, c'est-à-dire
> de ce dont il est amené à parler avec ses voisins et ses collègues.
> Les EPCI en font partie , car ils lèvent l'impôt et mettent des
> panneaux sur les routes.
> Les autres devraient être des couches distinctes.

OK, mais puisqu'on n'a pas de "couches" dans OSM, 
qu'est-ce que tu entends par là _pour OSM_ ? qu'il faut s'occuper seulement des 
"EPCI exclusifs", et ne pas chercher à faire un modèle générique ?


-- 
 ° /\Guillaume AllègreMembre de l'April
  /~~\/\   allegre.guilla...@free.fr  Promouvoir et défendre le logiciel libre
 /   /~~\tél. 04.76.63.26.99  http://www.april.org

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

[OSM-talk-fr] OsmJumper pour firefox 4 ?

[Erik Amzallag]

Bonjour,

La version actuelle de OsmJumper n'est pas compatible avec Firefox 4.
Un portage est-il prévu ? :)

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

Re: [OSM-talk-fr] Exercice Tsunami Zone Caraïbe - Caribe Wave 11

[RatZilla$]

Oui l'exercice est prévu depuis près d'un an. Vu le nombre
d'intervenants c'est un peu normal. Des exercices de ce genre ont
lieux régulièrement le prochain c'est le X24 Europe la  semaine
prochaine ;-)

https://sites.google.com/a/inrelief.org/24/

La probabilité d'un tsunami dans la Caraïbe est très forte car on y
retrouve les même problématiques qu'au Japon, 3 plaques en contact,
volcanisme. Se rajoute à cela de redoutables ouragans.

On estime à 75 le nombre de raz de marée en 500 ans dans la région.

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

Re: [OSM-talk-fr] EPCIs & arrondissements

[Christian Rogel]

Le 23/03/11 10:47, Guillaume Allegre a écrit :


Je ne connais pas bien le sujet, mais il me semble qu'on devrait aussi
englober des syndicats de communes, comme les syndicats de gestion des cours
d'eau, etc. qui ne sont pas exclusifs.
À moins que ce point ait déjà été discuté ici et tranché en faveur des EPCI
exclusifs uniquement, mais je n'en ai pas le souvenir.



Comme je l'ai déjà souligné, les structures administratives de la France 
sont en plein bouleversement.
Une loi sur la fusion des postes de conseillers généraux et de 
conseillers régionaux vient d'être votée et elle appelle d'autres 
modifications comme la suppression des cantons et probablement celle des 
arrondissements..
Les syndicats locaux d'électrification devraient être fusionnés en un 
seul syndicat départemental.
La prochaine élection présidentielle peut apporter encore d'autres 
changements.

Donc :
- Ne pas s'inquiéter de limites à vocation éphémère
- Se maintenir au niveau du besoin du citoyen lambda, c'est-à-dire de ce 
dont il est amené à parler avec ses voisins et ses collègues.
Les EPCI en font partie , car ils lèvent l'impôt et mettent des panneaux 
sur les routes.

Les autres devraient être des couches distinctes.

Christian





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

Re: [OSM-talk-fr] EPCIs & arrondissements

[Guillaume Allegre]

Le mer. 23 mars 2011 à 09:35 +0100, Damouns a ecrit :
> > L'avantage des EPCIs "relations de communes", c'est qu'il serait bien plus 
> > facile de les éditer,
> > puisqu'elles regrouperaient :
> > - des objets moins nombreux et de plus haut niveau
> > - les données "naturelles" dans ce contexte : une ComCom est toujours 
> > définie par la liste
> > des communes adhérentes, pas par ses limites
> 
> Dans ce cas j'ai l'impression (personnelle) qu'OSM n'apporterait
> aucune valeur ajoutée par rapport aux sites officiels (INSEE...) qui
> donnent pour chaque EPCI la liste de ses communes. En outre, les
> relations de relation, c'est encore mal géré par les outils autour
> d'OSM (mais bon, ça c'est un problème d'outil).

Ben ça c'est un argument qu'on pourrait appliquer à d'autres objets qui sont
déjà dans la base : repères géodésiques, CLC, etc.
La valeur ajoutée reste la même : faire apparaître les EPCIS dans le rendu OSM
(par limites ou par surfaces ;-)


> Autre argument : dans la page "Relations are not Categories" [1] on a
> la consigne suivante : "Les relations de groupement n'ont de sens que
> quand la relation n'est ni géographique, ni exclusive". Or dans ce
> cas, elle est exclusive (si on se limite aux EPCI à fiscalité propre).

Je ne connais pas bien le sujet, mais il me semble qu'on devrait aussi
englober des syndicats de communes, comme les syndicats de gestion des cours
d'eau, etc. qui ne sont pas exclusifs.
À moins que ce point ait déjà été discuté ici et tranché en faveur des EPCI
exclusifs uniquement, mais je n'en ai pas le souvenir.


-- 
 ° /\Guillaume AllègreMembre de l'April
  /~~\/\   allegre.guilla...@free.fr  Promouvoir et défendre le logiciel libre
 /   /~~\tél. 04.76.63.26.99  http://www.april.org

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

Re: [OSM-talk-fr] EPCIs & arrondissements

[Damouns]

> L'avantage des EPCIs "relations de communes", c'est qu'il serait bien plus 
> facile de les éditer,
> puisqu'elles regrouperaient :
> - des objets moins nombreux et de plus haut niveau
> - les données "naturelles" dans ce contexte : une ComCom est toujours définie 
> par la liste
> des communes adhérentes, pas par ses limites

Dans ce cas j'ai l'impression (personnelle) qu'OSM n'apporterait
aucune valeur ajoutée par rapport aux sites officiels (INSEE...) qui
donnent pour chaque EPCI la liste de ses communes. En outre, les
relations de relation, c'est encore mal géré par les outils autour
d'OSM (mais bon, ça c'est un problème d'outil).

Autre argument : dans la page "Relations are not Categories" [1] on a
la consigne suivante : "Les relations de groupement n'ont de sens que
quand la relation n'est ni géographique, ni exclusive". Or dans ce
cas, elle est exclusive (si on se limite aux EPCI à fiscalité propre).
Donc il suffirait d'un tag epci=Communauté de communes de Parthenay
(ou epci=Parthenay ;-P ) pour pouvoir retrouver les communes de chaque
EPCI.

[1] http://wiki.openstreetmap.org/wiki/FR:Relations/Relations_are_not_Categories

Damouns

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

Re: [OSM-talk-fr] Exercice Tsunami Zone Caraïbe - Caribe Wave 11

[Guillaume Allegre]

Le mer. 23 mars 2011 à 03:32 +0100, RatZilla$ a ecrit :
> Bonsoir @tou[te]s
> 
> Un exercice de simulation de tsunami est prévu dans la zone Caraïbe 
> aujourd'hui.

Par curiosité, c'est fréquent ce genre d'exercices ?

Il paraît avoir été prévu bien avant la catastrophe japonaise, mais la 
concommitance est frappante.


-- 
 ° /\Guillaume AllègreMembre de l'April
  /~~\/\   allegre.guilla...@free.fr  Promouvoir et défendre le logiciel libre
 /   /~~\tél. 04.76.63.26.99  http://www.april.org

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

Re: [OSM-talk-fr] EPCIs & arrondissements

[Guillaume Allegre]

Le lun. 21 mars 2011 à 23:44 +0100, Vincent de Chateau-Thierry a ecrit :
> Bonsoir,
> - le modèle "somme de surface" et le modèle "somme de limites" ont
> chacun leurs avantages
> - le modèle que je pousse pour les EPCIs (somme de limites) permet
> de tracer les emprises d'EPCIs comme on trace aujourd'hui les
> emprises de communes, cantons [2], arrondissements, départements et
> régions : en regroupant dans une relation leurs limites pour former
> un contour fermé : ça donne une homogénéité à l'ensemble puisque ces
> différents découpages partent de la même unité : la commune. C'est
> pour moi le principal argument : la cohérence de modélisation des
> différents découpages,
> - le modèle par limites est déja utilisé pour les EPCIs qui
> recourent a tag admin_level=7 : la transition vers un nouveau modèle
> par limites est directe et simple
> - le modèle par limites permet de définir des zones sans forcément
> disposer de toutes les emprises qui les constituent, à l'inverse du
> modèle par surfaces, qui nécessite que toutes les surfaces (des
> communes) constituantes soient présentes, faute de quoi on forme des
> surfaces d'EPCIs trouées. En l'état de la couverture en limites
> communales (~70%) le modèle par somme de surfaces pénaliserait pas
> mal de territoires. Appliqué aux départements, voire (pire !) aux
> régions, il donnerait une France metropolitaine pleine de vide.

Je comprends bien les arguments que tu donnes, mais ils se résument à deux
objectifs :
- compatibilité avec la situation actuelle (admin_level = 7)
  et les conventions antérieures (modèle admin_level hiérarchique : 4, 6, 8)
- éviter des trous temporaires

Il me semble que l'idée des admin_level hiérarchiques dans OSM est antérieure à 
l'apparition
des relations, et que donc "on n'avait que ça" à l'époque.
À l'inverse, si on réfléchit pour le futur, on peut essayer de repartir sur des 
bases
différentes, puisque la solution "conservatrice" (admin_level=7) n'est 
clairement
pas satisfaisante.

L'avantage des EPCIs "relations de communes", c'est qu'il serait bien plus 
facile de les éditer,
puisqu'elles regrouperaient :
- des objets moins nombreux et de plus haut niveau
- les données "naturelles" dans ce contexte : une ComCom est toujours définie 
par la liste
des communes adhérentes, pas par ses limites

Je ne préconise pas de "faire la révolution" pour les départements et les 
régions en les 
passant à une relation de communes, mais plutôt de roder ce nouveau modèle 
uniquement pour 
les EPCIs dans un premier temps.



-- 
 ° /\Guillaume AllègreMembre de l'April
  /~~\/\   allegre.guilla...@free.fr  Promouvoir et défendre le logiciel libre
 /   /~~\tél. 04.76.63.26.99  http://www.april.org

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

Re: [OSM-talk-fr] EPCIs & arrondissements

[Vincent Pottier]

Le 23/03/2011 08:42, Damouns a écrit :

Je suis aussi d'avis de ne mettre le nom de l'arrondissement sans «
Arrondissement de » dans le tag name. Et idem pour les cantons. On le fait
déjà pour les communes et pourtant il y a bien une différence entre une
ville et sa commune. Mais les données permettent de savoir à quel type
d'objet on a affaire.

S'il y a une majorité pour, je suis prêt à m'incliner ! Y a-t-il
d'autres avis en faveur du nom avec "Arrondissement de " ? Apparemment
on n'est que 2 !

Damouns

+1
--
FrViPofm

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

Re: [OSM-talk-fr] EPCIs & arrondissements

[Damouns]

> Je suis aussi d'avis de ne mettre le nom de l'arrondissement sans «
> Arrondissement de » dans le tag name. Et idem pour les cantons. On le fait
> déjà pour les communes et pourtant il y a bien une différence entre une
> ville et sa commune. Mais les données permettent de savoir à quel type
> d'objet on a affaire.

S'il y a une majorité pour, je suis prêt à m'incliner ! Y a-t-il
d'autres avis en faveur du nom avec "Arrondissement de " ? Apparemment
on n'est que 2 !

Damouns

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