from:"Benoît ROUSSEAU"



  
  
Le 01/10/2010 00:30, Vincent de Chateau-Thierry a écrit :

  
  
  Le 01/10/2010 00:24, Benoît ROUSSEAU a écrit :
  
  Ok.

Ne voyant rien non loggué sur

http://wiki.openstreetmap.org/wiki/WikiProject_France/Tracer_les_limites_administratives/Mise_au_point_du_modele_des_EPCI

j'ai cru qu'il n'y avait rien (je viens de vérifier en me
loguant en

voyant ton mail) donc j'ai continué à mettre à jour

http://wiki.openstreetmap.org/wiki/User:Vincent_95/draft/synthese_limites_administratives.

Zuteu zuteu zut !

  
  Argh.
  

Oui, mais je réparerai...

  
  Est-ce normal que rien n'apparaisse sur la
page quand on est pas loggué ?

  
  Je suis tenté de dire non... pas un problème de cache chez toi ?
  

Bingo, le Ctrl+F5 a réglé le pb... C'est tout de même étrange je
suis config vérif à chaque connexion.

  
  vincent
  

Benoît R.
  




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

Re: [OSM-talk-fr] Nouvelle page pour la réflexion su r les communautés de commune



  
  
Le 30/09/2010 23:52, Vincent de Chateau-Thierry a écrit :
Le
  30/09/2010 23:36, Benoît ROUSSEAU a écrit :
  
  Donc on garde les deux pages avec une
spécifique aux EPCI et je peux

continuer sur :

http://wiki.openstreetmap.org/wiki/User:Vincent_95/draft/synthese_limites_administratives

pour la discussion générale ?

  
  
  Pour l'instant, la nouvelle page reprend intégralement le contenu
  de celle hébergée sous mon compte. C'est vrai que les sujets
  abordés dépassent les EPCI, mais ce point me paraît suffisamment
  "massif" pour hériter d'une page avec un titre explicite.
  
  Pour les sujets connexes, comme par exemple les arrondissements
  départementaux, je ne sais pas s'il faut créér un espace
  différent, les choix pour les EPCI auront a priori des
  conséquences sur le choix des tags des arrondissements.
  
  Pour la discussion sur les quartiers et les communes associées, et
  celle sur les cantons, je suis favorable à l'amorce d'autres
  pages, débarrassées du verbatim sur les EPCI, et qui permettraient
  d'y voir plus clair et de faire avancer les sujets en propre,
  chacun à leur rythme.
  
  
  vincent
  

Ok.
Ne voyant rien non loggué sur  http://wiki.openstreetmap.org/wiki/WikiProject_France/Tracer_les_limites_administratives/Mise_au_point_du_modele_des_EPCI
j'ai cru qu'il n'y avait rien (je viens de vérifier en me loguant en
voyant ton mail) donc j'ai continué à mettre à jour http://wiki.openstreetmap.org/wiki/User:Vincent_95/draft/synthese_limites_administratives.
Zuteu zuteu zut !
Est-ce normal que rien n'apparaisse sur la page quand on est pas
loggué ? 
Benoît R.
  




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

Re: [OSM-talk-fr] Nouvelle page pour la réflexion su r les communautés de commune



  
  
Le 30/09/2010 21:56, Vincent de Chateau-Thierry a écrit :
Bonsoir,
  
  
  La synthèse des discussions récentes sur les EPCIs a été déplacée
  à cette adresse :
  
http://wiki.openstreetmap.org/wiki/WikiProject_France/Tracer_les_limites_administratives/Mise_au_point_du_modele_des_EPCI
  
  
  L'adresse a changé, mais le but reste le même : élaborer le modèle
  de tags et de relation pour ces entités.
  
  
  Tous les grains de sel sont les bienvenus :-)
  
  
  vincent
  
  

Donc on garde les deux pages avec une spécifique aux EPCI et je peux
continuer sur :
http://wiki.openstreetmap.org/wiki/User:Vincent_95/draft/synthese_limites_administratives
pour la discussion générale ?
Benoît R.
  




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

Re: [OSM-talk-fr] qualité de la carte



  
  
Le 30/09/2010 14:33, Pieren a écrit :

  2010/9/30 Christophe Merlet 

  
  Et je vote pour la mise en place d'une équipe chargé de
  l'Assurance
  Qualité chargé de rappeler régulièrement les bonnes méthodes
  de
  contribution, et le cas échéant d'engueuler les gougnafiers !
  


  Ben, ça sert à rien de trépignier sur place en serrant ses
  petits poings et en criant "je veux ! je veux !" comme Joe
  Averell. 
  Si tu veux utiliser les outils de contrôle et parler à ceux
  qui font des erreurs évidentes (pas les points discutables),
  vas-y. Si tu le souhaites, tu peux même créer un wikiProject
  et t'autoproclamer "QA group leader for France" en mettant ton
  nom en haut de la liste, personne ne te retiendra. Les "yaka,
  fokon" n'ont jamais fait avancer ce projet.

  
  
  Pieren


Grrr... :p

Christophe veux tu coordonner et suivre les initiatives qualité.
Comme tu le dis ce serait une bonne chose, rien n'empêche d'essayer.
Si ça ne fonctionne pas on laissera tomber sans t'incriminer car tu
auras essayé. Comme l'arrêt du tabac, on sait qu'il faut arrêter
mais il faut parfois rater plusieurs essais.

Benoît R.

  




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

Re: [OSM-talk-fr] Re : Tag:boundary=administrative / limites en France



  
  
Le 30/09/2010 11:50, LEON Frédéric a écrit :

  Bonjour,
[...]

Voila, en espérant ne pas polluer la discussion avec cette info qui n'est pas directement
Liée à OSM.

A bientôt.

Fred


Merci. C'est directement lié à OSM qui ne nécessite pas que JOSM
pour arriver à ses fins. C'est directement lié à OSM, au fil de
discussion et absolument pas une pollution.
Benoît.
  




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

Re: [OSM-talk-fr] Re : Tag:boundary=administrative / limites en France



  
  
Le 30/09/2010 12:44, Vincent Pottier a écrit :
On
  30/09/2010 11:50, LEON Frédéric wrote:
  
  
  Bienvenu Léon
  
  Le 29/09/2010 08:52, Vincent Pottier a
écrit :


Il me semble qu'il existe une extension OpenOffice pour
exporter en format mediawiki. Je n'ai jamais testé.




Je ne savais pas, je vais chercher. Merci.


Accessoirement je m'occupe également du site wiki-brest et je
peux donc confirmer l'existence de cette fonctionnalité, il ne
s'agit pas d'une extension mais bien d'une

Option d'exportation de votre document en utilisant la syntaxe
mediawiki.

On la trouve sous le menu "Fichier">  "Exporter", puis dans
la boite de dialogue sélectionner le "format de fichier"
mediawiki.

   
  Ça n'est pas natif dans OOo.
  
  L'extension est ici :
  
  http://extensions.services.openoffice.org/fr/node/738?
  
  Voila, en espérant ne pas polluer la
discussion avec cette info qui n'est pas directement

Liée à OSM.


   
  Si ça encourage l'écriture de doc/tuto en français dans le wiki
  osm, c'est le bienvenu !
  
  --
  
  FrViPofm
  
  

Merci pour toutes ces infos. Oui ça va encourager la doc !
Benoît.
  




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

Re: [OSM-talk-fr] qualité de la carte



  
  
Le 30/09/2010 12:36, sly (sylvain letuffe) a écrit :

  On jeudi 30 septembre 2010, Pieren wrote:

  
Pour le reste, les outils surveillant la qualité des contributions, il y en
a déjà beaucoup (même trop). 

  
  
Et bien moi, je ne pense pas. Je dirais pas vraiment qu'il n'y en a pas assez, 
mais je dirais qu'il leur manque surtout quelques fonctionnalités, et cela 
influe (à mon avis) sur le problème suivant :


  
Mais ils ne servent à rien si personne ne s'en 
sert pour corriger les erreurs signalées.

  

Réfléchir à réaliser un agrégateur des avertissements des d'outils
de surveillance. Un programme qui regroupe sur une carte l'ensemble
des erreurs repérées par les différents outils. Les cartes
pourraient faire peur, mais il serait pratique de n'avoir et de ne
donner qu'une adresse pour voir les avertissements sur une zone. Je
vais tenter un programme d'essai pour évaluer les pb (faut-il
définir un format d'échange commun ?, ...).

Pour les imports et corrections (semi-)automatiques, il faudrait au
moins un semblant de coordination. Dans ce cas, un groupe et une
liste à part, mais qui passe l'info digérée, sur la liste principale
serait peut-être utile. J'ai en tête le revert de suppression de
points orphelins ou j'ai foiré un import CLC de Simon.

Benoît R.

  




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

Re: [OSM-talk-fr] qualité de la carte



  
  
Le 30/09/2010 09:49, Guilhem Bonnefille a écrit :

  Le 30 septembre 2010 09:33, Jean-Francois Nifenecker
 a écrit :

  

Le 30/09/2010 00:24, Benoît ROUSSEAU a écrit :


  
La seule solution c'est de bosser :
- faire UN vrai tutoriel, sans espérer cela des CUM format A5 destinés
aux expérimentés,
- chercher des références,
- discuter des solutions argumentées,
- mettre à jour le wiki,
- le tout sans œillères en gardant un esprit critique face à l'existant.




je partage complètement ces idées.

  
  
Moi aussi.
Mais je n'attend pas que TOUS les contributeurs OSM participent à ces
actions. A mon sens, cela incombe à une élite que je classerait dans
le groupe QA.



"Élite" est peut être stigmatisant :p et ce n'est peut être pas une
bonne idée que de mettre des personnes à part dans un groupe QA.  Je
pense que les discussions qualité ne doivent en aucun cas être
traitées par un groupe "fixe" en dehors de la communauté globale.
Les discussions QA doivent pouvoir bénéficiées de l'expérience de
tous dans des domaines qui vont bien au delà de la cartographie :
politique, informatique, statistiques, hydrographie, ... Et ça
permet à tous de s'enrichir de tous. Moi j'ai beaucoup appris à lire
des discussions QA.

Je m'explique... Si on crée un groupe QA, il risque d'être fort
orienté par sur représentation d'une spécialité (Cratographes,
Hydrographes, fortes gueules, ...) ou de "secteurs géographiques"
(Les villes). Il y a des chances que ce ne soit pas le cas, mais on
ne peux le garantir puisqu'on n'en a pas la maîtrise. 

Pour prendre l'exemple de la discussion des limites administratives
fr. Si elle avait eu lieu à part en petit comité, le groupe
aurait-il bénéficier des connaissances de tous ? Je pense au
signalement de l'existence des Conseils de quartier avec une
certaine autonomie et des communes associées. 

Benoît R.


  




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

Re: [OSM-talk-fr] Re : Tag:boundary=administrative / limites en France



  
  
Le 29/09/2010 23:08, Vincent de Chateau-Thierry a écrit :

  
  Le 29/09/2010 09:17, sly (sylvain letuffe) a écrit :
  
  

On mercredi 29 septembre 2010, Vincent de Chateau-Thierry wrote:

J'ai amorcé une mise en forme sommaire
  en m'appuyant sur ton PDF. Pour
  
  l'instant la page est ici :
  
  

http://wiki.openstreetmap.org/wiki/User:Vincent_95/draft/synthese_limites_administratives

Il faudrait la placer ailleurs (mais où
  ? je n'ai pas pris l'initiative)
  
  puis faire évoluer le contenu de la page.
  


J'ai déjà des trucs à dire fond/forme ;-)

On la place quelque part de rangé ?

Liée depuis cette page par exemple :

http://wiki.openstreetmap.org/wiki/WikiProject_France/Limites_administratives/Tracer_les_limites_administratives

?

  
  
  Benoît a placé un lien, qui pour l'instant pointe vers la page
  déjà citée [1]. La page peut changer de place ou rester, je n'ai
  pas trop d'avis, étant entendu que c'est en soi une page de
  discussion / maturation du sujet. Que les experts en organisation
  de wiki n'hésitent pas à mettre de l'ordre. Quand le contenu de la
  page sera stabilisé, on aura (espérons) un consensus sur une
  manière de gérer les EPCI, ou au moins des argumentaires lisibles
  et synthétiques pour que d'autres que les participants à la
  discussion puissent se faire un avis.
  
  
  Enfin, le moment venu, il faudra augmenter la page de méthodo sur
  les limites administratives, voire créér une section dédiée aux
  EPCI.
  
  
  La discussion est ouverte, sur la forme ET sur le fond :-), pour
  l'instant donc ici [1].
  
  
  Merci pour vos contributions,
  
  vincent
  
  
  [1] :
http://wiki.openstreetmap.org/wiki/User:Vincent_95/draft/synthese_limites_administratives
  
  ___
  
  Talk-fr mailing list
  
  Talk-fr@openstreetmap.org
  
  http://lists.openstreetmap.org/listinfo/talk-fr
  

Bonjour,
T'es le bienvenu pour les remarques Sly.
J'ai mis à jour la page, mais je suis loin d'avoir terminé, c'est
encore en chantier. Maintenant c'est dodo.
N'hésitez pas à ajouter vos remarques, ou à les exprimer sur la
liste. Il est parfois difficile de ne pas être partisan au moment de
la synthèse, même avec de la bonne volonté.
Benoît R.
  




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

Re: [OSM-talk-fr] qualité de la carte



  
  
Désolé mais je remets ma cape de ronchon râleur.

Le 29/09/2010 22:18, Pierre BOIZOT a écrit :
Merci pour cette Belle intervention. qui à mon sens
  nous ramène à plusieurs point déjà débattu dans diverses
  interventions.

[...]

  Ma réponse :  parce que le processus est itératif, que
  l'organisation doit être souple pour intégrer de nouveaux
  contributeurs, parce qu'aujourd'hui il est plus important
  d'engranger des données même partielles, même fausses que de
  qualifier finement.
  

Itératif n'implique pas de ne jamais s'arrêter pour regarder en
arrière et corriger.

Donc, pour ma part :
- l'itératif à bon dos, parlez en avec les Maîtres des méthodes
agiles, il y en a sur la liste. Itératif n'implique pas foutoir ;
- l'intégration est pour le moins souple mais elle ne facilite pas
l'intégration (certains ont été reçus de manière très souple sur la
liste) ;
- jouer à celui "qu'a la plus grande" en comparant la taille des
fichiers Allemagne/France/Angleterre, remplir à la pelle puis
réfléchir en 2020, n'est pas une solution.

La seule solution c'est de bosser :
- faire UN vrai tutoriel, sans espérer cela des CUM format A5
destinés aux expérimentés,
- chercher des références,
- discuter des solutions argumentées,
- mettre à jour le wiki,
- le tout sans œillères en gardant un esprit critique face à
l'existant.

[...]

  Une mailling liste qui soit éclater en au moins 5 traffics:
  
  Dev 
  Debutant
  Question Mapping general
  Question mapping France
  Info diverse, annonces.
  

La liste "dev" à déjà un pied dans la tombe. La dernière discussion
prog s'est tenue sur cette liste. La mailling liste "débutants"
reviendrait à passer ses journées à répondre aux même questions,
autant faire LE tutoriel ou au moins une FAQ ferai très bien
l'affaire. Quant aux autres...
Salut a tous.
  Pierre


Benoît R.

  




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

Re: [OSM-talk-fr] Re : Tag:boundary=administrative / limites en France



  
  
Le 29/09/2010 08:05, Vincent de Chateau-Thierry a écrit :
Bonjour,
  
  
  Le 29/09/2010 05:10, Benoît ROUSSEAU a écrit :
  
    Le 29/09/2010 02:27, THEVENON Julien a
écrit :

>>>> *De :* Benoît ROUSSEAU
  
  
  **
  
  >>>> J'ai changé l'objet de la discussion.
  
  >>>> Vous trouverez ici la première partie de la
  synthèse :
  
http://adresseimpossible.free.fr/fichiers/osm/Synth%C3%A8se%20BA.pdf
  
  >>>> Indiquez moi les erreurs, les oublis et les
  traitements partisans
  
  des sujets.
  
  
  Beau travail de synthese vu le nombre de mails echanges !
  
  Par contre est ce qu une page wiki ne serait pas plus simple
  pour
  
  permettre aux differentes intervenants d eventuellement
  completer la
  
  synthese, avec commentaires dans la partie discussion. Cela a
  aussi l
  
  avantage de laisser une trace dans la doc
  
  
  My 2 cents
  
  Julien
  
  
  

Merci. Oui c'est long, une copie bout a bout des messages
(doublons

textes, bla bla des anti-virus, ...) c'est 65 pages A4 en 12pt.

D'accord pour le wiki, mais une mise en forme s'impose avec un

traitement de texte d'abord. Le navigateur sous Writer est par
exemple

pratique pour isoler les liens, ... J'ai peur que travailler
directement

sur une page du wiki soit galère. Si nous l'avions complétée au
fur et à

mesure oui.

Benoît R.

  
  
  Merci Benoît pour tout ce boulot.
  
  J'ai amorcé une mise en forme sommaire en m'appuyant sur ton PDF.
  Pour l'instant la page est ici :
  
http://wiki.openstreetmap.org/wiki/User:Vincent_95/draft/synthese_limites_administratives
  
  Il faudrait la placer ailleurs (mais où ? je n'ai pas pris
  l'initiative) puis faire évoluer le contenu de la page.
  

Super ! Merci.

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


Ce message entrant est certifié sans virus connu.
Analyse effectuée par AVG - www.avg.fr 
Version: 9.0.856 / Base de données virale: 271.1.1/3164 - Date: 09/28/10 08:34:00




  




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

Re: [OSM-talk-fr] Re : Tag:boundary=administrative / limites en France

Le 29/09/2010 08:52, Vincent Pottier a écrit :

On 29/09/2010 05:10, Benoît ROUSSEAU wrote:

Le 29/09/2010 02:27, THEVENON Julien a écrit :

>>>>
De :
Benoît ROUSSEAU

>>>>
J'ai
changé l'objet de la discussion.
>>>>
Vous
trouverez ici la première partie de la synthèse : http://adresseimpossible.free.fr/fichiers/osm/Synth%C3%A8se%20BA.pdf
>>>>
Indiquez
moi les erreurs, les oublis et les traitements partisans
des sujets.

Beau travail de synthese vu le nombre de mails echanges
!
Par contre est ce qu une page wiki ne serait pas plus
simple pour
permettre aux differentes intervenants d eventuellement
completer la
synthese, avec commentaires dans la partie discussion.
Cela a aussi l
avantage de laisser une trace dans la doc

My 2 cents
Julien

Merci. Oui c'est long, une copie bout a bout des messages
(doublons
textes, bla bla des anti-virus, ...) c'est 65 pages A4 en 12pt.
D'accord pour le wiki, mais une mise en forme s'impose avec un
traitement de texte d'abord. Le navigateur sous Writer est par
exemple
pratique pour isoler les liens, ... J'ai peur que travailler
directement sur une page du wiki soit galère. Si nous l'avions
complétée au fur et à mesure oui.
Benoît R.

Il me semble qu'il existe une extension OpenOffice pour exporter
en
format mediawiki. Je n'ai jamais testé.

Je ne savais pas, je vais chercher. Merci.

--
FrViPofm

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

Ce message entrant est certifié sans virus connu.
Analyse effectuée par AVG - www.avg.fr
Version: 9.0.856 / Base de données virale: 271.1.1/3164 - Date: 09/28/10 08:34:00

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

Re: [OSM-talk-fr] Re : Tag:boundary=administrative / limites en France



  
  
Le 29/09/2010 02:27, THEVENON Julien a écrit :

  
  >>>> De : Benoît ROUSSEAU


  
>>>> 
J'ai changé l'objet de la discussion.
>>>> 
Vous trouverez ici la première partie de la synthèse : http://adresseimpossible.free.fr/fichiers/osm/Synth%C3%A8se%20BA.pdf
>>>> 
Indiquez moi les erreurs, les oublis et les traitements
partisans des sujets.

Beau travail de synthese vu le nombre de mails echanges !
Par contre est ce qu une page wiki ne serait pas plus simple
pour permettre aux differentes intervenants d eventuellement
completer la synthese, avec commentaires dans la partie
discussion. Cela a aussi l avantage de laisser une trace
dans la doc

My 2 cents
Julien
  

  
  
  



Merci. Oui c'est long, une copie bout a bout des messages (doublons
textes, bla bla des anti-virus, ...) c'est 65 pages A4 en 12pt.
D'accord pour le wiki, mais une mise en forme s'impose avec un
traitement de texte d'abord. Le navigateur sous Writer est par
exemple pratique pour isoler les liens, ... J'ai peur que travailler
directement sur une page du wiki soit galère. Si nous l'avions
complétée au fur et à mesure oui.
Benoît R.
  




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

[OSM-talk-fr] Tag:boundary=administrative / limites en France



  
  
J'ai changé l'objet de la discussion.
Vous trouverez ici la première partie de la synthèse : http://adresseimpossible.free.fr/fichiers/osm/Synth%C3%A8se%20BA.pdf
Indiquez moi les erreurs, les oublis et les traitements partisans
des sujets.
Benoît R.

  




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

Re: [OSM-talk-fr] niveaux admin_level=7 (était : Limites,, communales)

Le 27/09/2010 22:43, Pieren a écrit :

2010/9/27 Benoît ROUSSEAU <adressepossi...@free.fr>

Stop au suivi
systématique ! Est-ce que le sens des quartiers Allemands
est le même que celui en France ? ? ? Connaissant la
réputation Allemande face a la latine, je pense quelle est
cohérente. Pour autant, sans nous mettre des œillères,et ne
pas allez voir autour ce qui se fait, on peux aussi
réfléchir par nous même. Par exemple, quand Émilie nous
parle des usages de subarea dans le découpage en Espagne
elle ne semble franchement prête à l'appliquer en France.

Si on regarde le tableau ici:
http://wiki.openstreetmap.org/wiki/Tag:boundary%3Dadministrative

j'ai rapidement compté les admin_level correspondant à la
municipalité:
1 pays au niveau 5,
2 au niveau 6,
5 au niveau 7,
40 au niveau 8,
1 au niveau 9 (l'Australie),
1 au niveau 10.
Le solde contient ceux que je n'ai pas pu déterminer (comme la
Chine) ou qui est inapplicable ou indéterminé. Le niveau
administratif inférieur est souvent le "suburb" qui se trouve
mieux répartit entre les admin_level 9 et 10.

Bonne idée ton tableau. Merci.
Notez tout en bas de la page "Current import of US states has begun
to use an extension, border_type=* to give the name of the
boundary's type." qui a la même vocation ma proposition d'ajouter
"nature". Mais cela exite t'il encore ou est-ce une trace
archéologique ? Je n'ai pas vérifié. En tous cas d'autres pays se
posent des questions sur l'usage de boundary=administrative pour des
entités de même niveau administratif.
Donc, à part quelques cas qui se distinguent, on a
conservé une structure à peu près cohérente de niveau 8 pour les
municipalités (NUTS 5, y compris en Allemagne), 6 pour les
départements (NUTS 3) et 4 pour les régions (NUTS 2) (http://en.wikipedia.org/wiki/Nomenclature_of_Territorial_Units_for_Statistics).
Les allemands sont deux fois dans le tableau avec 10 ou 11
niveaux. J'en conclus qu'il y a controverse chez-eux aussi (pour
ce qui concerne les niveaux inférieurs au Gemeinde).

Merci pour le lien NUTS. Ma remarque est que comme pour l'INSEE,
c'est un découpage à vocation statistique. Il sert à beaucoup comme
référence à un découpage administratif et peux conduire à des
aberrations et des contresens.

Alors, c'est vrai, on peut adapter les tags à nos particularismes
mais j'aimerais que nous conservions au moins les niveaux 2,4,6,8
comme ils sont actuellement. Pour le reste, la discussion est
ouverte (et ne m'intéresse pas beaucoup, je dois avouer).

Les spécification "fr" actuelles pour 2,4,6 et 8 ne posent de pb à
personne sous l'étiquette boundary=administrative avec le seul tag
admin_level, telles quelles sont définies actuellement. Les
discussions actuelles pose la question des EPCI en 7, qui devraient
être en 8, des quartiers qui ne devraient pas êtres étiquetées
systématiquement en divisions administratives, des arrondissements
départementaux et communes associées qui ne sont pas représentés et
de l'usage qui y inclus parfois les cantons.

Pieren

Benoît R.

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

Re: [OSM-talk-fr] niveaux admin_level=7 (était : Limites,, communales)



  
  
Le 27/09/2010 22:10, Christian Rogel a écrit :
Le
  27/09/10 21:52, Benoît ROUSSEAU a écrit :
  
  
  
Cette catégorie de commune souvent
  oubliée dans les décomptes de
  
  communes nécessite, à elle-seule, d'avoir un échelon
  infra-communal.
  

Je ne connais pas, je vais chercher une source. As-tu un exemple
?

  
  
  Le Wikipédia est une source souvent de valeur :
  
  http://fr.wikipedia.org/wiki/Commune_associée
  
  
  Les communes associées ont été crées en 1971
  
  710 communes associées (ça a tendance à diminuer)
  
  
  2 communes ont 9 communes associées (Isigny-le-Buat et
  Val-de-Meuse) et 2 autres en ont huit!
  
  Certains départements doivent n'en avoir aucune.
  
  En Finistère, il n'y a que Kernével, commune associée de
  Rosporden.
  
  
  
  Christian
  

Je dirai oui en tant que limite administrative au vu de "un officier
d'état civil et officier de police judiciaire,"... 
Je ne soupçonnais même pas l'existence de ces communes associées !
Merci Christian pour cette info.
Benoît R.
  




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

Re: [OSM-talk-fr] niveaux admin_level=7 (était : Limites,, communales)

2010-09-27 Par sujet Benoît ROUSSEAU

Le 27/09/2010 21:31, Christian Rogel a écrit :
Le
26/09/10 14:25, Benoît ROUSSEAU a écrit :

Du coup je suis allé voir à la source :

http://www.legifrance.gouv.fr/affichCodeArticle.do?cidTexte=LEGITEXT06070633&idArticle=LEGIARTI06390128&dateTexte=&categorieLien=cid

. Pourquoi pas. Mais strictement parlant, en
boundary=administrative,

nous ne devrions tracer que les contours que des quartiers ayant
un

Conseil de quartier qui a obtenu des délégations de la Mairie.

Admin_level poserait alors le même problème que pour les EPCI
puisque ce

n'est pas un sous-niveau administratif à la Commune mais un
découpage

territorial.

Les quartiers sont ce qu'on appelle des lieux-dit dans les
communes

rurales, il devraient être traités en tant que tel même si la
densité de

population est plus élevée en ville.

Benoît R.

Je n'ai pas eu le courage d'aller voir la source, mais je signale
que le territoire infra-communal qui doit être tracé en premier
lieu, c'est celui de la commune associée, car elle seule a une
existence administrative indiscutable : son corps électoral élit
des conseillers particuliers qui s'intègrent au conseil municipal
général.

Cette catégorie de commune souvent oubliée dans les décomptes de
communes nécessite, à elle-seule, d'avoir un échelon
infra-communal.

Je ne connais pas, je vais chercher une source. As-tu un exemple ?

Si un niveau 11 a déjà été mis en place dans le monde, prenons-le,
mais en vérifiant que l'échelon "communal" allemand correspond
bien à nos communes, i.e. être l'avant-dernier échelon de la
pyramide.

Par ailleurs, je redis que la notion de quartier est floue (sauf à
Paris) : dans ma ville, on a pris la mauvaise habitude d'appeler
"quartier" les anciennes communes fusionnées (qui ont un adjoint
spécial),ça fait de beaux "quartiers" de 3000 ha, mais quid des
quartiers réels, au raz de la vie des gens?

A la campagne, au moins par ici, il y avait (a?) des quartiers
regroupant un nombre variable de hameaux desservis par une
chapelle;

En tout cas, je ne vois pas la correspondance quartier/lieu-dit.

Christian

Habitant d'un immense "quartier", 1/4 urbain - 3/4 rural

Benoît R.

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

Re: [OSM-talk-fr] niveaux admin_level=7 (était : Limites,, communales)

2010-09-27 Par sujet Benoît ROUSSEAU

Le 27/09/2010 20:34, Pierre-Alain Dorange a écrit :

Le 26 sept. 10 à 14:25, Benoît ROUSSEAU a écrit :

Du coup je suis allé
voir à la source : http://www.legifrance.gouv.fr/affichCodeArticle.do?cidTexte=LEGITEXT06070633&idArticle=LEGIARTI06390128&dateTexte=&categorieLien=cid . Pourquoi pas. Mais
strictement parlant, en boundary=administrative, nous ne
devrions tracer que les contours que des quartiers ayant un
Conseil de quartier qui a obtenu des délégations de la
Mairie. Admin_level poserait alors le même problème que pour
les EPCI puisque ce n'est pas un sous-niveau administratif à
la Commune mais un découpage territorial.
Les quartiers sont ce qu'on appelle des lieux-dit dans les
communes rurales, il devraient être traités en tant que tel
même si la densité de population est plus élevée en ville.

Je ne suis pas sur du bien comprendre cette "obligation" de
voir un système strictement hiérarchique dans les différents
niveaux des boundary=administrative. Rien n'oblige a suivre
cette idée.
boundary=administrative ne définit que des frontières
administratives. Un quartier avec conseil local et budget
autonome entre à priori dans ce cadre, de même qu'un
arrondissement préfectoral ou même un EPCI...

Euh, j'attends de faire la synthèse, mais personne n'a dit ça. C'est
venu dans la discussion essentiellement comme des questionnements.
Ce qui a été dit c'est qu'on ai un système qui puisse intégrer
l'ordre établi au niveau international sans le bouleverser. Donc
implémenter le schéma boundary=administrative pour tout ce qui y
entre naturellement.

Ce qui bloque réellement, à mon avis, c'est l'usage des
admin_level (3 à 10)... laissant pas assez de places
actuellement pour y insérer d'autres frontières administratives.
On notera que quelques pays (allemagne et pays-bas) ont déjà
étendu au admin_level=11 pour les quartiers.
Stop au suivi systématique ! Est-ce que le sens des quartiers
Allemands est le même que celui en France ? ? ? Connaissant la
réputation Allemande face a la latine, je pense quelle est
cohérente. Pour autant, sans nous mettre des œillères,et ne pas
allez voir autour ce qui se fait, on peux aussi réfléchir par nous
même. Par exemple, quand Émilie nous parle des usages de subarea
dans le découpage en Espagne elle ne semble franchement prête à
l'appliquer en France.

Sur la discussion actuelle on voit bien que les définitions
sont délicates et que certains niveaux admin ne sont pas
compatible avec la règle "implicite" d'inclusion dans les
niveaux supérieurs et inférieurs (les cantons par exemple).

Les cantons ne sont pas des limites administratives mais
électorales. Voir les discussions précédentes ou la synthèse à
venir. Donc effectivement ils sont délicats à intégrer car ils ne
devraient pas y être intégrés.

J'aurai tendance a dire qu'il faudrait conserver les système
actuels des boundary pour les niveaux déjà utilisés (région,
département, commune) y définir 7 plutôt pour les
arrondissements préfectoraux.
Et expérimenter le système proposé de relation region pour
les EPCI par inclusion des relation de communes.

Les deux ne sont pas incompatibles. On peux passer de l'un à l'autre
donc il faudra trancher mais les conséquences seront minimes si à
l'usage le choix s'avérait être le moins pratique. On pourrait
passer à l'autre modèle par traitement automatique.

Mais on pourrait aussi imaginer de n'utiliser la relation
frontière que pour les communes et les cantons et de construire
les autres niveaux par addition (relation type region) des
communes qui constitue. Evidemment ça pose certains problèmes
(évoqué par d'autres) puisque toutes les communes ne sont pas
définis à ce jour, mais c'est théoriquement un modèle conforme.
Toutefois je suis d'accord qu'il ne puisse s'appliquer que
pour un nombre restreint de communes (EPCI par exemple).

C'est dans le tas des pr

Re: [OSM-talk-fr] niveaux admin_level=7 (était : Limites,, communales)

2010-09-27 Par sujet Benoît ROUSSEAU



  
  
Le 26/09/2010 22:45, Vincent de Chateau-Thierry a écrit :

  
  
  Le 26/09/2010 02:30, Benoît ROUSSEAU a écrit :
  
  Selon moi, le niveau 7 correspondrait aux
arrondissements

départementaux. Voir :

http://fr.wikipedia.org/wiki/D%C3%A9concentration#Cadre chapitre
"Cadre"

  
  
  Je suis d'accord avec toi, et même avec moi :-), sachant que je
  proposais ceci au début du fil. Il reste pour appliquer ça à
  statuer sur les com'com qui occupent cet admin_level [1].
  
  
  Comment continuer sur le sujet des com'com ? Il y a -au moins-
  deux propositions de modélisation de la relation, par boundary=*
  et par region=*, ainsi que des tags spécifiques à établir
  (typologie des EPCI, etc).
  
  
  Une nouvelle page de wiki et son onglet discussion ?
  
  
  :-). Pour ma part sans enlever les
références au COG, je me baserai sur

le découpage du chapitre "Cadre" de

http://fr.wikipedia.org/wiki/D%C3%A9concentration#Cadre avec les

communes et les arrondissements municipaux en plus. Il y aurait
ainsi

seulement 6 niveaux administratifs : A - Pays, B - Régions, C -

Départements(Préfectures), D - Sous-Préfectures (sachant
qu'elles sont

"sous tutelle" de la Préfecture au niveau départemental), E -
Communes,

F- Arrondissements municipaux. Avec une hésitation pour les

Sous-préfectures... Avec ce découpage, les territoires
s'emboitent, les

limites communales sont partagées entre les niveaux et il me
semble que

le sens premier de boundary=administative est respecté et
compréhensible.

  
  
   +1
  
  
  vincent
  
  
  [1] :
http://wiki.openstreetmap.org/wiki/WikiProject_France/Tracer_les_limites_administratives#En_proposition_:_.C3.89tablissements_publics_de_coop.C3.A9ration_intercommunale
  

Je vais déjà préparer une synthèse avec des exemples pour que tout
le monde puisse suivre et voir, si, à se répondre sur des points de
détail on ne s'est fourvoyés globalement.
Un vote serait ensuite une bonne chose...
Benoît R.
  




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

Re: [OSM-talk-fr] niveaux admin_level=7 (était : Limites,, communales)

2010-09-26 Par sujet Benoît ROUSSEAU

Le 26/09/2010 11:51, Vincent Pottier a écrit :

On 26/09/2010 02:30, Benoît ROUSSEAU wrote:

Les conseils de quartiers peuvent avoir un petit bout
d'administration
local, particulièrement en animation : "l'initiative locale" un
budget
voté en amont par le conseil municipal. Et, en lien avec un
adjoint,
prendre des décisions mineurs sur l'aménagement, l'entretien...
L'importance dépend de la politique municipale.

Du coup je suis allé voir à la source : http://www.legifrance.gouv.fr/affichCodeArticle.do?cidTexte=LEGITEXT06070633&idArticle=LEGIARTI06390128&dateTexte=&categorieLien=cid
. Pourquoi pas. Mais strictement parlant, en
boundary=administrative, nous ne devrions tracer que les contours
que des quartiers ayant un Conseil de quartier qui a obtenu des
délégations de la Mairie. Admin_level poserait alors le même
problème que pour les EPCI puisque ce n'est pas un sous-niveau
administratif à la Commune mais un découpage territorial.
Les quartiers sont ce qu'on appelle des lieux-dit dans les communes
rurales, il devraient être traités en tant que tel même si la
densité de population est plus élevée en ville.

--
FrViPofm

Benoît R.

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

Re: [OSM-talk-fr] Carte de grasse



  
  
Le 26/09/2010 02:03, Vincent Meurisse a écrit :

  bonjour,

Profitant d'un peu de temps libre ce WE, je me suis amusé à faire une petite 
carte interactive de Grasse.
Au menu:
- Carte OSM
- Orthophotos
- Intégration avec openstreetbug pour permettre au plus grand nombre de 
signaler les erreurs

Les utilisateurs de navigateurs modernes (chrome, opera ou safari) aurons la 
joie de pouvoir changer l'opacité de la couche OSM avec un slider. Les autres 
devrons se contenter d'un champ texte.

Amusez vous bien sur 



Beau boulot ! J'ai noté quelques décalages de bâtiments juste pour
tester.
Benoît R.
  




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

Re: [OSM-talk-fr] niveaux admin_level=7 (était : Limites,, communales)

Le 25/09/2010 23:58, Vincent de Chateau-Thierry a écrit :
Le
25/09/2010 20:24, Benoît ROUSSEAU a écrit :

Euh... ;-) ok.

Pourquoi "mais il ne faut surtout pas boundary=administative" ?
Après

tout c'est bien une limite administrative du même ordre que les
communes

?Seule la nature change, par délégation de pouvoirs.

L'intérêt de "nature" (ou autre) est qu'on pourrait en plus
décomposer

les différentes natures administratives (les académies avec
"education",

les préfectures (même si incluses dans les arrondissements avec
"police,

les zones des centres d'impôts avec "fiscal", ...).

Réponse globale avant : Ca ne me gène pas de
faire le distinguo dès le boundary. C'était une réflexion sur la
notion de com2com qui n'est pas trahie par une différentiation
immédiate.
Tout
à fait d'accord pour rentrer en base différentes natures de
limites comme celles que tu cites. Cependant, je préfère une
distinction dès le tag "boundary=*", plutôt que de coller
"boundary=administrative" et devoir via un tag nature=* distinguer
les types de limites. Je ne verrais de commun à toutes ces limites
que le tag de premier niveau, à savoir type=boundary. Ensuite,
pourquoi pas des boundary=électorale, statistique, linguistique,
militaire, académique (?), etc. A traduire bien sûr :-).

L'usage jusque là, donné par le wiki, est d'associer
boundary=administrative au tag admin_level=*. Et j'imagine mal
placer dans le grand tableau _mondial_ du wiki[1] de multiples
notions autres que la commune pour l'admin_level 8, avec un
distingo "nature=*".

Pour garder homogène le "grand tableau
mondial" ok.
Selon moi, le niveau 7 correspondrait aux
arrondissements départementaux. Voir : http://fr.wikipedia.org/wiki/D%C3%A9concentration#Cadre
chapitre "Cadre" pour ce qui est du thème de l'administration.
Pour ce qui est des quartiers en niveau 10, je ne sais pas quoi en
penser, car je ne sais pas s'il existe "légalement" des organismes
d'administration des quartiers. Les Conseils de quartier par
exemple, n'ont qu'un avis consultatif selon http://fr.wikipedia.org/wiki/Conseil_de_quartier.
Pour
résumer mon point de vue là-dessus, à l'exception du niveau
cantonal, essayons de garder boundary=administative et
admin_level=* pour les découpages du territoires donnés par le COG
[2], et déclinons d'autres valeurs du tag boundary=* pour les
autres styles de découpage, quitte à ce qu'ils s'appuient
eux-mêmes sur les unités du COG, comme les communes. Tiens, ça me
rappelle les communautés de communes, ça :-)

:-). Pour ma part sans enlever les références
au COG, je me baserai sur le découpage du chapitre "Cadre" de http://fr.wikipedia.org/wiki/D%C3%A9concentration#Cadre
avec les communes et les arrondissements municipaux en plus. Il y
aurait ainsi seulement 6 niveaux administratifs : A - Pays, B -
Régions, C - Départements(Préfectures), D - Sous-Préfectures
(sachant qu'elles sont "sous tutelle" de la Préfecture au niveau
départemental), E - Communes, F- Arrondissements municipaux. Avec
une hésitation pour les Sous-préfectures... Avec ce découpage, les
territoires s'emboitent, les limites communales sont partagées
entre les niveaux et il me semble que le sens premier de
boundary=administative est respecté et compréhensible.

vincent

[1] : http://wiki.openstreetmap.org/wiki/Admin_level

[2] :
http://insee.fr/fr/methodes/nomenclatures/cog/carte_regions.asp

Benoît R.

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

Re: [OSM-talk-fr] niveaux admin_level=7 (était : Limites,, communales)



  
  
Le 25/09/2010 17:24, Vincent de Chateau-Thierry a écrit :

  
  
  Le 25/09/2010 16:51, Benoît ROUSSEAU a écrit :
  
    Autre proposition :


Actuellement pour les limites administratives des communes ont
utilise

quelque chose :


des way décrits comme suit :


version="1" changeset="1221617" user="monsieur a"
uid="97101">




















des relations d'appartenance décrites comme suit :


version="6" changeset="3344785" user="MrsPeel" uid="206119">



























version="4" changeset="3072415" user="EtienneChoveBot"
uid="183561">
































Pourquoi ne pas simplement ajouter des relations com2com comme
suit avec

un tag "nature" (les anglophones traduiront) pour les
distinguées des

communes au même niveau et ca résout le pb :


version="4" changeset="30724185" user="quidam" uid="1883561">























EPCI" />




Ca ne change quasiment rien au schéma actuel puisque c'est de la
même

veine que le tag natural=coastline. Pas de region pas de
subarea, ... et

si j'ai bien compris c'est la proposition exprimée par Vincent
de

Château-Thierry.


  
  
  Euh...:-)
  
  Une différence avec ce que je propose, c'est que dans une relation
  com'com basée sur des limites, il faut le tag type=boundary 
  (puisqu'on parle de limites), mais il ne faut surtout pas
  boundary=administative. D'où ma proposition de
  boundary=local_authority.
  
  
  Après oui, si on regarde par exemple la définition actuelle de
  Saint-Quentin-en-Yvelines :
  
  
  
  
  
  
  
  (...)
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  pour la "convertir" dans le modèle que j'imagine, il y a très peu
  à changer :
  
  - supprimer admin_level=7
  
  - changer boundary=administrative en boundary=local_authority (ou
  autre si on trouve mieux)
  
  - ajouter les tags relatifs à la nature et aux compétences de
  l'EPCI
  
  ...et c'est tout.
  
  
  vincent
  

Euh... ;-) ok.

Pourquoi "mais il ne faut surtout pas boundary=administative" ?
Après tout c'est bien une limite administrative du même ordre que
les communes ? Seule la nature change, par délégation de pouvoirs. 
L'intérêt de "nature" (ou autre) est qu'on pourrait en plus
décomposer les différentes natures administratives (les académies
avec "education", les préfectures (même si incluses dans les
arrondissements avec "police,  les zones des centres d'impôts avec
"fiscal", ...).

Benoît R.

  




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

Re: [OSM-talk-fr] niveaux admin_level=7 (était : Limites,, communales)



  
  
compris.

Le 25/09/2010 19:10, Emilie Laffray a écrit :

  Petite clarification. Ce qui me gêne c'est l'utilisation qu'il
en fait en Espagne et en Pologne où les données géométriques
sont mélangées avec des relations avec le rôle subarea. Pour moi
cela n'a aucun sens.
Dans le cas d'une relation boundary, si les données géo ne sont
pas mélangées, ça ne me gêne pas.
  Emilie Laffray
  On 25 Sep 2010 12:28, "Benoît ROUSSEAU"
<adressepossi...@free.fr>
wrote:
> ___
> 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

  


Ce message entrant est certifié sans virus connu.
Analyse effectuée par AVG - www.avg.fr 
Version: 9.0.856 / Base de données virale: 271.1.1/3158 - Date: 09/25/10 08:34:00




  




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

Re: [OSM-talk-fr] niveaux admin_level=7 (était : Limites,, communales)



  
  
Autre proposition :

Actuellement pour les limites administratives des communes ont
utilise quelque chose :

des way décrits comme suit :

   
   
   
   
   
   
   
   


des relations d'appartenance décrites comme suit :

   
   
   
   
   
   
   
   
   
   
   



   
   
   
   
   
   
   
   
   
   
   
   
   
   


Pourquoi ne pas simplement ajouter des relations com2com comme suit
avec un tag "nature" (les anglophones traduiront) pour les
distinguées des communes au même niveau et ca résout le pb :

   
   
   
   
   
   
   
   
   
   
  
  


Ca ne change quasiment rien au schéma actuel puisque c'est de la
même veine que le tag natural=coastline. Pas de region pas de
subarea, ... et si j'ai bien compris c'est la proposition exprimée
par Vincent de Château-Thierry.

Benoît R.


  




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

Re: [OSM-talk-fr] niveaux admin_level=7 (était : Limites,, communales)



  
  
Le 25/09/2010 15:09, Vincent de Chateau-Thierry a écrit :

  
  
  Le 25/09/2010 14:38, Vincent Pottier a écrit :
  
  Il me semble qu'il y a une différence de
nature entre un département et

une communauté de commune.

Un département n'est pas une agrégation de commune, mais un
territoire,

une collectivité territoriale dont les limites coïncident avec
elles de

M, N

Une communauté de commune, quant à elle, est une agrégation de
communes

à laquelle adhèrent M, N...

  

Posons-nous la question : si on voulait un jour récupérer ces
informations de découpage administratif comment voudrions nous les
voir représentées ? Je ne parle pour l'instant que du découpage,
ensuite on verra comment intégrer les informations connexes. Le
découpage administratif de manière général est un arbre, pas une
pile. On sait décrire un arbre en XML. Commençons par la structure
avec des tags fictifs pour débuter, piochons dans l'existant puis
nous définirons ce qui manque.

  
  Oui. Mon raisonnement pour parler d'agrégation est à voir sous
  l'angle des primaires géométriques dans la base, avec en tête une
  question : comment rendre la base cohérente en terme de
  construction, à la fois pour ceux qui la constituent (nous) et
  pour ceux qui s'en servent/serviront (nous aussi, entre autres).
  
  Dans les 2 cas, depts et com'com, la construction _dans osm_se
  fait en assemblant un puzzle dont les pièces sont des communes
  (*). Et je ne trouve pas d'argument pour dire : en fonction du
  nombre de pièces du puzzle, je vais prendre des pièces "limites"
  ou des pièces "surfaces".
  

Sous l'angle des primaires géométriques, difficile de trancher, car
dans le cas des limites administratives puisque définissons des
limites (frontières) de surfaces (territoires), qui donc doivent
boucler. Ces limites donc pourraient très bien être des définies en
surfaces sans en changer le sens. Pour ma part je préférerai des
area en place des boundary, mais définir des boundary n'est pas
moins illogique..

  
  

Mais bon, je ne suis pas spécialiste...

  
  
  Alors on est 2 :-)
  
  
  vincent
  
  
  (*) Je mets de côté la démarche "Cartographes Associés" qui
  partait directement de l'échelle "département" pour les
  constituer, vu qu'on supprime cette source doucement mais
  sûrement, pour lui substituer une géométrie et un maillage plus
  fins.
  
  
  ___
  
  Talk-fr mailing list
  
  Talk-fr@openstreetmap.org
  
  http://lists.openstreetmap.org/listinfo/talk-fr
  
  


Ce message entrant est certifié sans virus connu.
Analyse effectuée par AVG - www.avg.fr 
Version: 9.0.856 / Base de données virale: 271.1.1/3158 - Date: 09/25/10 08:34:00




  




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

Re: [OSM-talk-fr] niveaux admin_level=7 (était : Limites,, communales)



  
  
Le 25/09/2010 14:16, Vincent de Chateau-Thierry a écrit :
Bonjour,
  
  
  Le 25/09/2010 13:27, Benoît ROUSSEAU a écrit :
  
  

Pour les subarea je n'est remarqué aucun consensus, Pierre
Quenee nous a

proposé, comme base de travail, l'adaptation sur un modèle
existant et

Émilie à évoqué subarea en nous disant "ca ne me plait pas mais
ça

existe par ailleurs".

  
  Oui, tout à fait. Mais hier soir je disais : "_si_ il y a
  consensus".
  

Je reformule :p avec avoir en prime : je n'ai pas remarqué qu'on se
dirigeai vers un consensus... 

  
  Mis a part le modèle proposer qui reste à
affiner, renommer les tags, le

compléter, il n'y a pas incohérence avec le modèle actuel bien
au

contraire c'est un complément indispensable ! C'est le modèle
actuel qui

nous amène à l'incohérence. Soit en hiérarchisant de haut en bas
: des

éléments qui pour certains ne sont pas des limites
administratives ou

des élément qui devraient être au même niveau administratif sur
des

niveaux différents. Même si nous rajoutions une numérotation de
niveau a

plus de 10 échelons, ce serait faux ! Ce n'est pas parce que le
modèle

qui fait consensus dans la base est limité que nous devons le
reproduire

bêtement à l'infini en entrant des données dedans au chausse
pied en

considérant que c'est un fourre tout. Tagguer un admin level 7
pour une

communauté de commune est une erreur si les communes sont en 8 !
Ou

alors il faut compléter le modèle actuel en ajoutant des
compléments

d'information pour distinguer les limites administratives
placées au

même niveau.

  
  
  Je viens de relire ce que je disais hier, et ça prête à confusion,
  je comprends ta réponse. Je ne parlais (ne voulais parler) que de
  la manière de construire l'objet com'com : par une relation de
  type boundary=*, ou par une autre de type region=*. Il est clair
  pour moi que dans un cas comme dans l'autre, le tag admin_level=*
  n'a rien à faire dans cette relation. En revanche, il est présent
  dans chacun des membres de la relation.
  
  En essayant de reformuler : "quand on agrège des communes pour
  construire un département, on utilise boundary=*, pourquoi ne pas
  utiliser aussi boundary="autre chose" pour agréger des communes à
  l'échelle d'une com'com."
  

Là, il va me falloir du temps pour simuler avec un cas concret pour
bien comprendre avant de répondre.

  
  La solution de la relation est très
pratique et flexible puisqu'elle

évite d'avoir nécessairement à ressaisir les contours en
incluant les

contours des communes. L'argument comment on fait s'il n'y à pas
de

contours de communes ne tient pas, il faut les tracer.

  
  Facile à dire, et j'aimerais être d'accord avec ça, mais il faut
  être lucide, la courbe de croissance des limites admin est plutôt
  faible. Construire une version temporaire de com'com, avec les
  nodes place=* permet déjà d'identifier la com'com et ses communes
  constituantes (via leur ref:INSEE) ainsi que, au mieux, ses
  domaines de compétence. Le jour où les contours de commune
  existent, on remplace le node place=* par la relation
  boundary=administrative, mais au moins comme ça on ne créé pas
  d'adhérence entre les objets com'com et limite admin. Utiliser le
  node place=* est une suggestion pour gérer une situation
  transitoire, pas ce qui devrait être le modèle définitif.
  

Courbe de croissance faible oui. Je m'éloigne du sujet précis pour
illustration

Pour exemple je vais prendre mon comportement face aux adresses et
aux rivières. Les rivières j'ai essayé, j'ai arrêté après avoir lu
le wiki et ses 50 (exagéré) manières de faires et les discussions
sur la liste qui en amenaient encore d'autres. Les adresses c'est en
stanby alors que j'ai les moyens d'importer des millions d'adresses
(j'ai fait les essais) automatiquement car le modèle "Karl", est
passé de proposition à norme et aujourd'hui à standard
indéboulonnable. Il me semble inapproprié, car lui aussi mélange
différents ty

Re: [OSM-talk-fr] niveaux admin_level=7 (était : Limites,, communales)



  
  
Le 24/09/2010 23:03, Vincent de Chateau-Thierry a écrit :
Bonsoir,
  
  
  Le 24/09/2010 22:03, Pierre-Alain Dorange a écrit :
  
  

Pieren  wrote:



  En ce qui concerne les rôles :
admin_center



  
  Attention à la syntaxe anglaise : admin_centre (et non
  admin_center). Erreur
  
  très courante, en particulier chez les français (on se demande
  pourquoi ;-)
  


Concernant les EPCI je crois pas que admin_centre soit pertinent
; il

n'y a pas de réel centre administratif (un adresse postale c'est
tout).

Aucune commune n'a d'égénomie (en théorie, car souvent c'est la
ville

principale qui assume ce rôle).


Mais la relation proposée est très intéressante.

  
  
  Oui, et à double titre, puisqu'elle permet de "faire la place"
  pour les arrondissements départementaux ;o)
  
  
  Pour revenir sur les propositions d'aujourd'hui, je reste partisan
  du modèle par limite (boundary=*) plutôt que par surface
  (region+subarea), pour la raison invoquée hier : la capacité de
  définir le périmètre de la com'com même en l'absence des limites
  admin de certains villes constituantes. Même si, comme le dit
  justement Pieren, les regroupements dans ce cas concernent bien
  peu de communes en comparaison de ce que regroupe un département.
  Néanmoins, un autre point, déjà évoqué, est celui de la cohérence
  de modèle. Je trouve dommage de s'éparpiller sur 2 modélisations
  pour, finalement, la "même" chose (avec quelques guillemets) : la
  définition d'une zone par agrégat de communes. Je ne vois pas de
  raison majeure pour faire de 2 manières distinctes : somme de
  limites versus somme de surfaces. Et l'usage boundary=* étant un
  consensus pour les contours administratifs à l'échelle de toute la
  base OSM, je trouve que ça légitime d'autant plus de continuer
  pour la déclinaison com'com.
  
  Maintenant s'il y a consensus sur region+subarea, je
  l'appliquerai, que ce soit clair, mais bon... en grognant :-)
  


2
  autres points :
  
  - il faut prévoir la situation où l'on veut définir une com'com en
  l'absence de limites communales. Comment inclure une commune sans
  limites administatives tracées ? A priori en plaçant dans la
  relation com'com le node place=* qui représente la commune ? Le
  rôle subarea ne me plaît pas s'agissant d'un node. Peut-être
  peut-on laisser le node sans rôle ?
  
  - je vois dans l'exemple "cobaye" de Pierre Quenee ma proposition
  de tag "local_authority". Ca n'est qu'une proposition, faut-il le
  rappeler.
  
  
  vincent
  

Pour les subarea je n'est remarqué aucun consensus, Pierre Quenee
nous a proposé, comme base de travail, l'adaptation sur un modèle
existant et Émilie à évoqué subarea en nous disant "ca ne me plait
pas mais ça existe par ailleurs".
Mis a part le modèle proposer qui reste à affiner, renommer les
tags, le compléter, il n'y a pas incohérence avec le modèle actuel
bien au contraire c'est un complément indispensable ! C'est le
modèle actuel qui nous amène à l'incohérence. Soit en hiérarchisant
de haut en bas : des éléments qui pour certains ne sont pas des
limites administratives ou des élément qui devraient être au même
niveau administratif sur des niveaux différents. Même si nous
rajoutions une numérotation de niveau a plus de 10 échelons, ce
serait faux ! Ce n'est pas parce que le modèle qui fait consensus
dans la base est limité que nous devons le reproduire bêtement à
l'infini en entrant des données dedans au chausse pied en
considérant que c'est un fourre tout. Tagguer un admin level 7 pour
une communauté de commune est une erreur si les communes sont en 8 !
Ou alors il faut compléter le modèle actuel en ajoutant des
compléments d'information pour distinguer les limites
administratives placées au même niveau.
La solution de la relation est très pratique et flexible puisqu'elle
évite d'avoir nécessairement à ressaisir les contours en incluant
les contours des communes. L'argument comment on fait s'il n'y à pas
de contours de communes ne tient pas, il faut les tracer. Personne
ne se pose la question de tracer une route sans ways ou d'indiquer
des sorties d'autoroutes sans l'autoroute. Qui plus est la relation
permet d'ajouter un contour propre à la com'com.
Le plus important même si l'on tâtonne en base est d'avoir
l'ensemble des informations cohérentes pour transtyper
automatiquement ces éléments si nécessaire dans le futur. Ca la
rel

Re: [OSM-talk-fr] niveaux admin_level=7 (était : Limites,, communales)

2010-09-24 Par sujet Benoît ROUSSEAU



  
  
Le 24/09/2010 10:29, Pierre Quenee a écrit :
Bonjour,
  
  
  Merci de vos éclairages divers, parfois contradictoire mais
  néanmoins enrichissants.
  
  
  J'ai creusé le problèmes des relations et je suis tombé sur :
  
  
  http://wiki.openstreetmap.org/wiki/Relations/Proposed/Region
  
  
  qui n'est bien sur qu'une proposition, mais qui correspond bien au
  problème posé.
  
  
  J'ai donc amendé ma proposition
  
  
  http://www.openstreetmap.org/browse/relation/1187442
  
  
  en la structurant ainsi
  
  
  type = region
  
  region_category = administrative
  
  region_type = EPCI
  
  
  (local_authority:FR:)EPCI = CC -- une labelisation à approfondir
  
  
  Citation de Vincent de Chateau-Thierry
  
  
  Je pense par ailleurs qu'on n'échappera pas à un espace de noms du
  style
  
  local_authority:FR un peu sur le modèle de school:FR si on veut
  
  introduire la typologie des EPCI (cf. doc de l'INSEE ci-dessus) :
  
  "Les communautés urbaines (CU), communautés d'agglomération (CA),
  
  communautés de communes (CC), syndicats d'agglomération nouvelle
  (SAN)"
  
  
  
  ref:EPCI  = 123456789  ou 123 456 789  (forme SIRET)  le numéro
  est le même, mais le numéro SIRET fait parti de bases de données
  (infogreffe) dont les droits sont réservés ...
  
  
  admin_level=8  (Organisation horizontale avec délégués se situant
  donc sur le même niveau hiérarchique que la commune)  ou
  considérant que l'information figure déja dans chaque commune
  abandon de cette référence ?
  
  
  et dans la rubrique facultatif :
  
  
  adress = adresse postale mais aussi situation de la maison de la
  communauté distincte des Mairies.
  
  website = http://...
  
  
  En ce qui concerne les rôles : admin_center  (commune de situation
  de la maison de la communauté), et subarea (proposé par défaut
  dans JOSM)  ou subregion (proposé dans la page wiki sus
  référencés.
  
  
  Merci pour tout.
  
  
  
  
  Pour le code postal de la première version, c'était une séquelle
  de copier/coller, mais les erreurs font parfois surgir des
  suggestions tout à fait pertinentes.
  
  

Bonjour,

Ca plait bien ça. Vis à vis des précédente discussions, à première
vue, ça concilie le plus d'avantages et il me semble qu'on peut en
obtenir tout le nécessaire à un traitement utile. Ce qui suit n'est
que pinailleries positives.

Je recopie le code avec des annotations en (x)
: 

 
- 
- 
  admin_center"
/> (1)
  subarea" /> (2)
  subarea" /> 
  subarea" /> 
  subarea" /> 
  subarea" /> 
  subarea" /> 
   (3)
   
   
  

  "ref:EPCI" v="246 301 105"
/> (4)
   
   
   
  "http://www.cc-ambert.com/" /> 
  
  

(1) - Je ne suis pas certain qu'il faille
donner plus d'importance à l'une des communes. Le "admin_centre" (voir courrier Pieren et "It is British
vs Americal English issue." dans la page de proposition) laisse
supposer qu'il y a un "chef". Dans le cas des communautés de
communes, même si c'est parfois le cas dans le poids de chaque vote,
je ne crois pas que ce soit exacte et général. Je les mettrai tous
au même niveau.
(2) - Dans ce cas, pour le rôle des limites communales
  membres, je préfererai un subboundary à un subarea. Avec
un subarea, je m'attends a trouver un area en ref.
(3) - je pense qu'il faudrait quelque chose du
type "address:centre" pour indiquer l'adresse du siège. Mais je
connais pas l'usage.
(4) - je penche pour une ref INSEE en priorité et/ou
indiquer le type de source ref. dans le cas présenté, on a une
référence mais on ne sait pas à quelle nomenclature elle fait
référence donc difficile à utiliser par la suite => "ref:SIRET" v="246 301 105" /> "ref:INSEE" v="246301105" />. puisqu'on est dans une
  relation contenant je ne répèterai pas nécessairement EPCI dans la
référence.

En tous cas cette proposition offre une solution et permettrai une
évolution future vers d'autres solutions car il semble que tout y
est, tant au niveau géométrique que hiérarchique. Donc, si a
l'avenir une meilleure représentation pour traiter le pb venait à
apparaitre, un traitement automatisé permettrai la conversion. Ce
point me semble le plus important. Je pense que c'est donc une
solution plus satisfaisante que l'existant, même si ce n'est pas la
seule.

Benoît R.
  




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

Re: [OSM-talk-fr] niveaux admin_level=7 (était : Limites, communales)

Le 23/09/2010 23:21, Vincent de Chateau-Thierry a écrit :
Bonsoir,

Le 23/09/2010 15:25, Benoît ROUSSEAU a écrit :

Le 23/09/2010 14:44, Pieren a écrit :

2010/9/23 Benoît ROUSSEAU
<adressepossi...@free.fr

Reste à déterminer l'étiquetage ? Des propositions ?

Benoît R.

Je suis d'accord qu'il faut revoir l' "étiquetage". Avec la

proposition actuelle:

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

je vois quelques problèmes dont le principal est de mélanger
des

relations définissant des limites (somme de frontières
extérieures

formant une surface) avec des regroupements de communes (somme
de

surfaces) en utilisant la même famille de tags (type=boundary;

boundary=administrative). Donner un "role=relation" n'est pas

suffisament distinctif ce qui pourrait compliquer leur
exploitation

par logiciel, amha (on ne tague pas pour les logiciels mais il
faut

garder une certaine cohérence tout de même; la question s'est
déjà

posée pour les départements, régions, etc).

Je suis d'accord avec ça. Je penche pour le recours à la même
modélisation que celle utilisée pour les départements, à savoir
une somme de ways qui forment un contour. Il y a la raison de
cohérence que donne Pieren, et j'en ajouterai une autre : avoir
une somme de limites / bordures permet de définir l'emprise
complète du territoire sans disposer de tous ses constituants.
L'exemple des départements plaide pour ça : on a aujourd'hui la
définition des limites de tous les départements, tout en ayant (et
de loin :-( ) pas encore toutes les limites de communes. Si on
avait défini les départements comme des sommes de surfaces
communales, on ne saurait pas proposer un découpage départemental
complet de la France. Et encore pour un petit bout de temps...

Ok pour moi, je suis convaincu par tes
arguments => contours. En plus ecla facilite le tracé et le
rendu même si "on ne tag pas...".

Un autre problème dans

cette proposition est d'y avoir ajouter
le code postal qui se trouve

déjà dans les sous-relations. Je ne sais pas si la création de

communautés de communes implique toujours la fusion en un seul
code

postal mais les codes postaux devraient figurer dans une seule

relation à la fois pour éviter les risques d'incohérences
ultérieures.

Autant que je sache, il n'y a pas de fusion des CPs à la création
d'une communauté de communes. Et si cela arrive, ça n'est pas une
règle. En France, hormis pour quelques communes avec plusieurs
codes postaux, le niveau "commuune entière" reste le plus
pertinent pour stocker cette info. donc dans osm la relation
d'admin_level=8

Tout a fait d'accord, le type "boundary"
ne convient pas. Pour les

surfaces il y aurait "area". De même pour le code postal qui n'a
rien à

faire ici. Par contre l'INSSE donne un code EPCI pour ces
regroupement

dans le document téléchargeable ici :

http://www.statistiques-locales.insee.fr/esl/baseTelechProduit.asp?strProd=1637&IdSousTheme=2&IdSource=&NomThemeOuSource=R%C3%A9gions%2C+d%C3%A9partements+et+villes+de+France

Ce code pourrait être inclu.

Chouette, un nouveau ref:INSEE :-)

Il faudrait, a discuter, voir en terme de
groupement, car relation

exprime un regroupement administratif de territoires. Ce n'est
pas une

description géométrique qui est déjà définie par les limites des

communes concernées. Je ne pense donc pas qu'il faille définir
un

contour pour les communautés de communes car 1- il est
intrinsèque 2 -

les communauté de communes changes relativement rapidement.
Utiliser une

relation permet d'inclure ou d'exclure des communes facilement.

Plutôt pas d'accord (voir + haut)

Ok voir plus

Re: [OSM-talk-fr] niveaux admin_level=7 (était : Limites, communales)

Le 23/09/2010 14:44, Pieren a écrit :

2010/9/23 Benoît ROUSSEAU <adressepossi...@free.fr>

Reste à déterminer
l'étiquetage ? Des propositions ?
Benoît R.

Je suis d'accord qu'il faut revoir l' "étiquetage". Avec la
proposition actuelle:
http://www.openstreetmap.org/browse/relation/1187442

je vois quelques problèmes dont le principal est de mélanger
des relations définissant des limites (somme de frontières
extérieures formant une surface) avec des regroupements de
communes (somme de surfaces) en utilisant la même famille de
tags (type=boundary; boundary=administrative). Donner un
"role=relation" n'est pas suffisament distinctif ce qui
pourrait compliquer leur exploitation par logiciel, amha (on
ne tague pas pour les logiciels mais il faut garder une
certaine cohérence tout de même; la question s'est déjà posée
pour les départements, régions, etc). Un autre problème dans
cette proposition est d'y avoir ajouter le code postal qui se
trouve déjà dans les sous-relations. Je ne sais pas si la
création de communautés de communes implique toujours la
fusion en un seul code postal mais les codes postaux devraient
figurer dans une seule relation à la fois pour éviter les
risques d'incohérences ultérieures.

Pieren

Tout a fait d'accord, le type "boundary" ne convient pas. Pour les
surfaces il y aurait "area". De même pour le code postal qui n'a
rien à faire ici. Par contre l'INSSE donne un code EPCI pour ces
regroupement dans le document téléchargeable ici : http://www.statistiques-locales.insee.fr/esl/baseTelechProduit.asp?strProd=1637&IdSousTheme=2&IdSource=&NomThemeOuSource=R%C3%A9gions%2C+d%C3%A9partements+et+villes+de+France.
Ce code pourrait être inclu.

Il faudrait, a discuter, voir en terme de groupement, car relation
exprime un regroupement administratif de territoires. Ce n'est pas
une description géométrique qui est déjà définie par les limites des
communes concernées. Je ne pense donc pas qu'il faille définir un
contour pour les communautés de communes car 1- il est intrinsèque 2
- les communauté de communes changes relativement rapidement.
Utiliser une relation permet d'inclure ou d'exclure des communes
facilement.

J'arrête le franglish => un truc type=groupe ou
groupement_administratif seraient ils trop simples et pas assez
descriptif ?

Benoît R.

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

Re: [OSM-talk-fr] Possibilité d'extraction des lim ites de départements avec la XAPI OSM ?



  
  
Ptet utiliser la liste dev...@openstreetmap.org la prochaine fois
pour qu'elle ne meure pas :p.
Benoît R.

Le 23/09/2010 11:27, Nicolas Moyroud a écrit :
Bonjour
  à tous,
  
  
  Pour un projet de webmapping utilisant OpenLayers, j'aurai besoin
  d'afficher la couche des départements français. J'ai essayé
  d'utiliser la XAPI d'OSM pour les récupérer. J'ai trouvé quelques
  exemples et je m'en suis inspiré, mais j'obtiens une erreur. Je
  pense en fait que la zone est trop grande (France entière) et que
  du coup la requête est refusée. Avec Firebug j'obtiens un status
  "200 OK" mais la réponse retournée est vide.
  
  Y a t'il un moyen de récupérer les limites administratives en
  tenant compte du niveau de zoom ? Du style récupérer des limites
  plus grossières à l'affichage de la France entière puis de plus en
  plus détaillées en zoomant sur une zone précise. Je ne sais pas
  comment faire ça avec OpenLayers. Quelqu'un aurait-il une idée ?
  
  
  
  
  
  
  ___
  
  Talk-fr mailing list
  
  Talk-fr@openstreetmap.org
  
  http://lists.openstreetmap.org/listinfo/talk-fr
  
  


Ce message entrant est certifié sans virus connu.
Analyse effectuée par AVG - www.avg.fr 
Version: 9.0.856 / Base de données virale: 271.1.1/3153 - Date: 09/22/10 20:40:00




  




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

Re: [OSM-talk-fr] niveaux admin_level=7 (était : Limites, communales)



  
  
Le 23/09/2010 13:25, Pierre-Alain Dorange a écrit :

  Pierre Quenee  wrote:


  
Est ce que le codage des Communautés de Communes peut être codé en 
relation père ?
par exemple :

http://www.openstreetmap.org/api/0.6/relation/1187442

auquel cas l'intéret d'un niveau 7 devient relatif.

En effet, si à (long) terme les communautés devait se substituer aux 
communes
l'application du même niveau 8 pour cette structure se révélerait 
pertinente.

  
  
C'est une excellente proposition.



Reste à déterminer l'étiquetage ? Des propositions ?
Benoît R.
  




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

Re: [OSM-talk-fr] Possibilité d'extraction des lim ites de départements avec la XAPI OSM ?



  
  

J'ai chargé cette zone sous JOSM et a première vue JOSM ne charge
pas d'admin_level 6 sur cette zone. J'ai trouvé des 4 et des 8 ...
Essai avec l'un de ces niveaux administratif. Il n'y a peut être
simplement pas de niveau 6.

Benoît R.

Le 23/09/2010 12:13, Nicolas Moyroud a écrit :

  
  
  sly (sylvain letuffe) a écrit :
  
  Couche vectorielle ou bitmap ?

  
  Une couche vectorielle.
  
  En fait je viens de tester avec une toute petite zone, et ça me
  fait toujours la même erreur. Ça n'a pas l'air lié à la taille de
  la zone. Du coup, je ne comprends pas vraiment pourquoi ça ne
  marche pas...
  
  Voici un extrait de mon code js utilisant OpenLayers :
  
  
     var dept = new OpenLayers.Layer.Vector(
  
     "Départements",
  
     {
  
     strategies:[
  
     new OpenLayers.Strategy.Fixed(),
  
     ],
  
     protocol: new OpenLayers.Protocol.HTTP({
  
     url:
"http://xapi.openstreetmap.org/api/0.6/way[admin_level=6][bbox=2.98899,43.70518,3.17507,43.85118]",
     format: new OpenLayers.Format.OSM()
  
     }),
  
     projection: new OpenLayers.Projection("EPSG:4326"),
  
     styleMap:new OpenLayers.StyleMap({
  
     "default": {
  
     strokeColor: "#00"
  
     }
  
     })
  
     }
  
     );
  
     map.addLayer(dept);
  
  
  J'ai aussi essayé en ajoutant dans l'URL
  [boundary=administrative], mais ça ne change rien.
  
  
  je ferais comme ça :

- récupération d'un fichier france-large.osm

- import avec osm2pgsql des frontières uniquements

- utilisation de la fonction st_simplify de postgis pour
pré-calculer plusieurs niveaux de détails


Au choix, utilisation de mapnik pour faire un rendu bitmap, ou
utiliser les fonctions openlayers d'affichage de polygones

  
  
  En fait mon idée c'était d'éviter d'utiliser un serveur postgres
  juste pour ça. Mais si je n'arrive pas à le faire directement avec
  la XAPI je m'y résoudrais...
  
  
  ___
  
  Talk-fr mailing list
  
  Talk-fr@openstreetmap.org
  
  http://lists.openstreetmap.org/listinfo/talk-fr
  
  


Ce message entrant est certifié sans virus connu.
Analyse effectuée par AVG - www.avg.fr 
Version: 9.0.856 / Base de données virale: 271.1.1/3153 - Date: 09/22/10 20:40:00




  




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

Re: [OSM-talk-fr] niveaux admin_level=7 (était : Limites, communales)



  
  
Le 23/09/2010 09:40, Pierre Quenee a écrit :
Bonjour,
  
  Est ce que le codage des Communautés de Communes peut être codé en
  relation père ?
  
  par exemple :
  
  
  http://www.openstreetmap.org/api/0.6/relation/1187442
  
  
  auquel cas l'intéret d'un niveau 7 devient relatif.
  
  
  En effet, si à (long) terme les communautés devait se substituer
  aux communes
  
  l'application du même niveau 8 pour cette structure se révélerait
  pertinente.
  
  
  Par ailleurs j'ai cru comprendre que les outils de rendu avait des
  problèmes avec ces structures complexes, mais est ce une raison
  pour ne pas les utiliser ?
  
  
  Quelles rôles (au sens JOSM) doit t'on appliquer à chaque membre
  (Validator ne semble pas aimer les roles vides)
  
  
  Merci pour vos éclairages
  
  
  
  ___
  
  Talk-fr mailing list
  
  Talk-fr@openstreetmap.org
  
  http://lists.openstreetmap.org/listinfo/talk-fr
  
  




+5
L'idée de relation pour les communautés de communes, les communautés
d'agglomérations, ... est une bonne idée qui représente bien la
structure. Ca me semble cohérent. Le même niveau d'admin rend bien
compte de la situation actuelle ou ces communauté se substutuent sur
certains point de gestion, le ramassage des ordures, les transports
en commun, ...
Benoît R.
  




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

Re: [OSM-talk-fr] niveaux admin_level=7 (était : Limites communales)



  
  
Dans ce cas on arrête les routes :p "avec le nombre de projets de
déviations et de constructions, ca ne sert à rien". La réforme
territoriale elle se fera, mais ça ne résoudra pas nos pb pour
autant de prendre des décisions quant à comment l'arbre. Les mêmes
problèmes se poseront.
Benoît R.

Le 23/09/2010 10:09, g.d a écrit :

  
me demande s'il est utile

  
  
Hm, ouaipch, probablement tu n'as pas tort...

Peut-être vaudrait-il mieux, d'attendre voir ce qui adviendra,
et s'atteler à décrire le résultat ensuite, une fois qu'ils auront décidé,

au lieu de maintenant y engager la sueur du front,
pour dans quelque temps devoir re-modifier ?
Parfois, il peut être urgent, d'attendre.

L'énergie des osm'eurs est tellement précieuse, 
et nous avons déjà tellement à faire, à re-caoutchouter les ways (and means...) suite aux imports en masse, 
à éviter que les rues traversent les maisons, éviter que l'arrêt de bus se retrouve dans l'arrière-cour, éviter que des hameaux se retrouvent dans du landuse:forest, "port du casque obligatoire" ? , il y a du boulot sur la planche...

Oups, pardon ! c'est juste my two cents ! En aucun cas je voudrais empêcher qui que ce soit, de faire ce qu'il veut faire !
C'est simplement, que je trouverais triste, si de l'énergie précieuse soit engagée là où probablement dans deux, trois ans il faudra reprendre, et que personne pour l'instant encore ne sait ni quoi ni comment...
Amicalement
Gerhard
---

Le 23 sept. 2010 à 00:44, Christian Rogel a écrit :


  
Dans une discussion similaire, j'ai rappelé que l'actuelle réforme territoriale a pour ambition de supprimer le canton et de le remplacer par un territoire dans lequel serait élu un conseiller territorial.
Il a été avancé que les communautés de communes (après des fusions obligatoires après 2013) pourraient être cette circonscription.

De mauvaises langues disent que la réforme sera finalement sabordée.
En attendant la fin de ce suspense, je me demande s'il est utile de s'intéresser à une bagarre canton versus communauté.

Christian

  
  


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

  


Ce message entrant est certifié sans virus connu.
Analyse effectuée par AVG - www.avg.fr 
Version: 9.0.851 / Base de données virale: 271.1.1/3152 - Date: 09/22/10 08:34:00




  




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

Re: [OSM-talk-fr] niveaux admin_level=7 (était : Limites communales)



  
  
Le 22/09/2010 22:56, Vincent de Chateau-Thierry a écrit :

  
  
  Le 22/09/2010 21:43, Benoît ROUSSEAU a écrit :
  
    Le 22/09/2010 21:32, Benoît ROUSSEAU a
écrit :

Le 22/09/2010 20:26, Pierre-Alain
  Dorange a écrit :
  
  Vincent de Chateau-Thierry

  wrote:


Le problème, c'est que la logique
  "arborescente" des niveaux
  
  adminsitratifs en France ne colle pas avec les
  regroupements de communes
  
  types CA/CU. Rien n'empêche des communes de départements
  différents de se
  
  regrouper au sein d'une communauté.
  

En effet mais il en va un peu de même pour les cantons par
exemple.

De plus cette "logique" arborescente qui existe pour
certains

admin_level n'est pas définit (je n'en trouve pas de traces
dans le

wiki).

Certes c'est pratique etça parait logique et plus simple,
mais est-ce

une nécessité  des admin_level ?


Mais (voir mon autre message dans l'ancienne enfilade) les

intercommunalités ont aussi des caractéristiques différentes
des autres

: les représentants ne sont pasélus au suffrage direct
(maisça

pourrait changer un jour), la division ne me semble pas
administrative

(dans le sens décidé  par l'administration) ; il s'agit de
regroupement

autour de compétences.


L'autre problème c'est de placer les cantons et
arrondissement qui vont

aussi entre le département et la commune...


  
  A mon sens les cantons ne sont pas des "admin_level" au sens
  
  administratif, mais électoral. La partie administrative est le
  
  département pour les cantons, car les conseillers généraux
  siègent au
  
  Conseil général. Ce sont des représentants politiques, pas des
  des
  
  fonctionnaires dans cette fonction (même s'il peuvent l'être
  par
  
  ailleurs). C'est le Conseil général qui gère
  administrativement, selon
  
  ses prérogatives, le département dont la population est
  représentée
  
  par des élus de fractions électorales de ce territoire. Même
  si les
  
  conseillers municipaux sont élus sur des secteurs électoraux
  ont ne
  
  tag pas ces secteurs en admin_level mais on tag les quartiers
  qui n'y
  
  correspondent pas... et qui d'ailleurs ne sont pas a
  proprement parler
  
  des admin_level, sauf si les conseils de quartiers... sont
  légalement
  
  obligatoires et on un rôle administratif (je ne sais pas à
  vérifier).
  
  
  Les Sous-préfectures avec leurs arrondissements administratifs
  oui,
  
  c'est une fraction de territoire de police, avec des
  fonctionnaires. A
  
  ce titre, les Académies auraient plus leur place, en
  admin_level, que
  
  les cantons. Les Académies sont bien des fractions
  administratives de
  
  l'état, elles déterminent, par exemple, par ricoché les
  périodes de
  
  congés scolaires, l'endroit où inscrire les enfants à l'école
  
  publique, ...
  
  
  Le découpage électoral ne suit pas le découpage administratif,
  nous
  
  sommes tous d'accord. Mais c'est à mon avis une erreur de
  vouloir les
  
  intégrer au niveau d'admin_level il faudrait un découpage
  électoral à
  
  part, qui existe je crois. D'ailleurs on risque d'avoir le
  même pb à
  
  l'inverse quand on voudra monter le découpage électoral, des
  morceaux
  
  seront en admin_level, les autres en "electoral_level", ...
  
  
  Benoît R.
  

Je poursuis avec un complément...


Quant au n° de niveau administratif, vouloir "emboiter" les
niveaux

Re: [OSM-talk-fr] niveaux admin_level=7 (était : Limites communales)



  
  
Le 22/09/2010 21:32, Benoît ROUSSEAU a écrit :

  
  Le 22/09/2010 20:26, Pierre-Alain Dorange a écrit :
  
Vincent de Chateau-Thierry
 wrote:



  Le problème, c'est que la logique "arborescente" des niveaux
adminsitratifs en France ne colle pas avec les regroupements de communes
types CA/CU. Rien n'empêche des communes de départements différents de se
regrouper au sein d'une communauté.


En effet mais il en va un peu de même pour les cantons par exemple.
De plus cette "logique" arborescente qui existe pour certains
admin_level n'est pas définit (je n'en trouve pas de traces dans le
wiki).
Certes c'est pratique et ça parait logique et plus simple, mais est-ce
une nécessité des admin_level ?

Mais (voir mon autre message dans l'ancienne enfilade) les
intercommunalités ont aussi des caractéristiques différentes des autres
: les représentants ne sont pas élus au suffrage direct (mais ça
pourrait changer un jour), la division ne me semble pas administrative
(dans le sens décidé par l'administration) ; il s'agit de regroupement
autour de compétences.

L'autre problème c'est de placer les cantons et arrondissement qui vont
aussi entre le département et la commune...


  
  A mon sens les cantons ne sont pas des "admin_level" au sens
  administratif, mais électoral. La partie administrative est le
  département pour les cantons, car les conseillers généraux siègent
  au Conseil général. Ce sont des représentants politiques, pas des
  des fonctionnaires dans cette fonction (même s'il peuvent l'être
  par ailleurs). C'est le Conseil général qui gère
  administrativement, selon ses prérogatives, le département dont la
  population est représentée par des élus de fractions électorales
  de ce territoire. Même si les conseillers municipaux sont élus sur
  des secteurs électoraux ont ne tag pas ces secteurs en admin_level
  mais on tag les quartiers qui n'y correspondent pas... et qui
  d'ailleurs ne sont pas a proprement parler des admin_level, sauf
  si les conseils de quartiers... sont légalement obligatoires et on
  un rôle administratif (je ne sais pas à vérifier).
  
  Les Sous-préfectures avec leurs arrondissements administratifs
  oui, c'est une fraction de territoire de police, avec des
  fonctionnaires. A ce titre, les Académies auraient plus leur
  place, en admin_level, que les cantons. Les Académies sont bien
  des fractions administratives de l'état, elles déterminent, par
  exemple, par ricoché les périodes de congés scolaires, l'endroit
  où inscrire les enfants à l'école publique, ...
  
  Le découpage électoral ne suit pas le découpage administratif,
  nous sommes tous d'accord. Mais c'est à mon avis une erreur de
  vouloir les intégrer au niveau d'admin_level il faudrait un
  découpage électoral à part, qui existe je crois. D'ailleurs on
  risque d'avoir le même pb à l'inverse quand on voudra monter le
  découpage électoral, des morceaux seront en admin_level, les
  autres en "electoral_level", ... 
  
  Benoît R.

Je poursuis avec un complément...

Quant au n° de niveau administratif, vouloir "emboiter" les niveaux
comme des poupées russes avec un seul type par niveau est une
erreur. Si on prends Académie et préfecture (sauf erreur - mais
qu'importe pour la démo) elle devrait être au même niveau, l'une est
juste sous l'état France par le Ministère de l'éducation, l'autre
par le Ministère de l'intérieur. Et il existe d'autres découpages
administratifs, comme par exemple celui des centres d'impôts, qui ne
correspond à aucun autre, ...

Benoît R.
  




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

Re: [OSM-talk-fr] niveaux admin_level=7 (était : Limites communales)



  
  
Le 22/09/2010 20:26, Pierre-Alain Dorange a écrit :

  Vincent de Chateau-Thierry
 wrote:


  
Le problème, c'est que la logique "arborescente" des niveaux
adminsitratifs en France ne colle pas avec les regroupements de communes
types CA/CU. Rien n'empêche des communes de départements différents de se
regrouper au sein d'une communauté.

  
  
En effet mais il en va un peu de même pour les cantons par exemple.
De plus cette "logique" arborescente qui existe pour certains
admin_level n'est pas définit (je n'en trouve pas de traces dans le
wiki).
Certes c'est pratique et ça parait logique et plus simple, mais est-ce
une nécessité des admin_level ?

Mais (voir mon autre message dans l'ancienne enfilade) les
intercommunalités ont aussi des caractéristiques différentes des autres
: les représentants ne sont pas élus au suffrage direct (mais ça
pourrait changer un jour), la division ne me semble pas administrative
(dans le sens décidé par l'administration) ; il s'agit de regroupement
autour de compétences.

L'autre problème c'est de placer les cantons et arrondissement qui vont
aussi entre le département et la commune...



A mon sens les cantons ne sont pas des "admin_level" au sens
administratif, mais électoral. La partie administrative est le
département pour les cantons, car les conseillers généraux siègent
au Conseil général. Ce sont des représentants politiques, pas des
des fonctionnaires dans cette fonction (même s'il peuvent l'être par
ailleurs). C'est le Conseil général qui gère administrativement,
selon ses prérogatives, le département dont la population est
représentée par des élus de fractions électorales de ce territoire.
Même si les conseillers municipaux sont élus sur des secteurs
électoraux ont ne tag pas ces secteurs en admin_level mais on tag
les quartiers qui n'y correspondent pas... et qui d'ailleurs ne sont
pas a proprement parler des admin_level, sauf si les conseils de
quartiers... sont légalement obligatoires et on un rôle
administratif (je ne sais pas à vérifier).

Les Sous-préfectures avec leurs arrondissements administratifs oui,
c'est une fraction de territoire de police, avec des fonctionnaires.
A ce titre, les Académies auraient plus leur place, en admin_level,
que les cantons. Les Académies sont bien des fractions
administratives de l'état, elles déterminent, par exemple, par
ricoché les périodes de congés scolaires, l'endroit où inscrire les
enfants à l'école publique, ...

Le découpage électoral ne suit pas le découpage administratif, nous
sommes tous d'accord. Mais c'est à mon avis une erreur de vouloir
les intégrer au niveau d'admin_level il faudrait un découpage
électoral à part, qui existe je crois. D'ailleurs on risque d'avoir
le même pb à l'inverse quand on voudra monter le découpage
électoral, des morceaux seront en admin_level, les autres en
"electoral_level", ... 

Benoît R.
  




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

Re: [OSM-talk-fr] Import bâtiments en France



  
  
Le 22/09/2010 17:07, Etienne Trimaille a écrit :
Le 22 septembre 2010 16:36, Benoît ROUSSEAU <adressepossi...@free.fr>
  a écrit :
  

   Le logiciel d'éclatement des fichiers d'import bâti est
prêt en v0.1. Si qqun veux tester :
  http://adresseimpossible.free.fr/
Il fonctionne sous Windows en .Net Framework 4
Il y a pas mal de limitations pour l'instant comme :
- extension des fichiers en minuscules ".osm" ;
- ne travaille que sur un dossier, pas de ftp ;
- extrait les amenity=swimming_pool mais le script à je
crois évolué vers "leisure" ;
- ...
Benoît R.
  


  Ton logiciel éclate un fichier .osm en séparant les buildings,
  piscines,.. ?

  

Oui.

  

  Juste pour information, osmosis permet de le faire le tag
  filter : 
  http://wiki.openstreetmap.org/wiki/Osmosis/Detailed_Usage#--tag-filter_.28--tf.29
  

  

Bien vu. Pourquoi la question n'a pas été traité avant ? Mystère...
Ca m'a fait travailler les neurones c'est déjà ça.
Donc aucun pb a fractionner les fichiers d'imports...

  
Bon, surement que osmosis est moins accessible que ton
  outils.

  
  

Oui, quoi que la bêta est rudimentaire.

Benoît R.

  




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

Re: [OSM-talk-fr] Import bâtiments en France



  
  
Le 22/09/2010 03:33, Benoît ROUSSEAU a écrit :

  
  
  Le 21/09/2010 17:29, Jean-Francois Nifenecker a écrit :
   
Le 21/09/2010 14:25, Vincent Pottier a écrit : 
+1. 
  Et la séparation building - water est pertinente. Les travaux
  de 
  contrôle sur le layer building n'ont rien à voir avec les
  retouches de 
  polygones water. 


+1 sur ça aussi. Waterway et building sont des entités
différentes qu'il faut traiter différemment. Il serait donc
(très) utile de séparer les fichiers les contenant. 

  
  Suite aux messages, je bosse sur un logiciel d'extraction des
  différents éléments depuis les fichiers existants. Ca extrait déjà
  les "buildings" dans un fichier séparé, autant dire que les
  "river" et les "swinming-pool" vont arriver très vite.
  
  Pour vérifier que je ne détruit pas de données, je regarde si le
  fond de cadastre correspond aux "buildings" extraits... Et là,
  SURPRISE ! Mon extraction SVG de référence, faite au début de
  l'apparition du script, comporte plus de bâtiments que le fond
  Cadastre sous JOSM ! Alors qui quoi où comment ? ? ? Ma voiture
  étant en panne je ne pourrais pas rapidement aller vérifier si les
  bâtiments existent en "vrai".
  
  La mise à jour me paraît bien rapide... et c'est la moitié d'un
  hameau, ça me paraît bizarre. Encore que...
  
  QQun a t'il remarqué des pb similaires ?
  
  Benoît R.
  
  



Le logiciel d'éclatement des fichiers d'import bâti est prêt en
v0.1. Si qqun veux tester :
  http://adresseimpossible.free.fr/
Il fonctionne sous Windows en .Net Framework 4
Il y a pas mal de limitations pour l'instant comme :
- extension des fichiers en minuscules ".osm" ;
- ne travaille que sur un dossier, pas de ftp ;
- extrait les amenity=swimming_pool mais le script à je crois évolué
vers "leisure" ;
- ...
Benoît R.




  




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

Re: [OSM-talk-fr] Import bâtiments en France



  
  
Le 22/09/2010 09:19, Julien Balas a écrit :

  

   Pour vérifier que je ne
détruit pas de données, je regarde si le fond de cadastre
correspond aux "buildings" extraits... Et là, SURPRISE ! Mon
extraction SVG de référence, faite au début de l'apparition
du script, comporte plus de bâtiments que le fond Cadastre
sous JOSM ! Alors qui quoi où comment ? ? ? Ma voiture étant
en panne je ne pourrais pas rapidement aller vérifier si les
bâtiments existent en "vrai".
  



  
  Certaines batiments sont dupliqués 4-5-6 fois dans le cadastre,
  c'est peut-etre l'explication.
  Tes bâtiments "en plus" sont peut-etre dans cette catégorie.
  
  -- 
  JB
  



Là c'est l'inverse ils n'existent plus sur le Cadastre en ligne.
Benoît R.
  




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

Re: [OSM-talk-fr] Import bâtiments en France



  
  
Le 21/09/2010 17:29, Jean-Francois Nifenecker a écrit :

  
  Le 21/09/2010 14:25, Vincent Pottier a écrit :
  
  +1.

Et la séparation building - water est pertinente. Les travaux de

contrôle sur le layer building n'ont rien à voir avec les
retouches de

polygones water.

  
  
  +1 sur ça aussi. Waterway et building sont des entités différentes
  qu'il faut traiter différemment. Il serait donc (très) utile de
  séparer les fichiers les contenant.
  
  

Suite aux messages, je bosse sur un logiciel d'extraction des
différents éléments depuis les fichiers existants. Ca extrait déjà
les "buildings" dans un fichier séparé, autant dire que les "river"
et les "swinming-pool" vont arriver très vite.

Pour vérifier que je ne détruit pas de données, je regarde si le
fond de cadastre correspond aux "buildings" extraits... Et là,
SURPRISE ! Mon extraction SVG de référence, faite au début de
l'apparition du script, comporte plus de bâtiments que le fond
Cadastre sous JOSM ! Alors qui quoi où comment ? ? ? Ma voiture
étant en panne je ne pourrais pas rapidement aller vérifier si les
bâtiments existent en "vrai".

La mise à jour me paraît bien rapide... et c'est la moitié d'un
hameau, ça me paraît bizarre. Encore que...

QQun a t'il remarqué des pb similaires ?

Benoît R.

  




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

Re: [OSM-talk-fr] Utilisation de bulk_upload & bulk_upload_sax



  
  
Le 21/09/2010 17:17, Emilie Laffray a écrit :

  
  2010/9/21 Benoît ROUSSEAU <adressepossi...@free.fr>

   
On a avancé :
1 - il y a un pb côté JOSM a coup sûr => donc avertir
l'équipe de JOSM ;
2 - les serveurs sont PROBABLEMENT surchargés et donc ce pb
est plus fréquent et ne passe plus inaperçu => SIMILI pb
côté charge serveur.

note : en gras, termes prudents, même si cela semble
confirmées par Émilie, mais...
  

  
  
  Oui surtout que je n'ai rien confirmé :) J'ai juste parle que l'on
  allait avoir une nouvelle machine plus puissante, mais je ne suis
  pas sure de l'utilisation de la machine (pas sure qu'elle soit la
  pour la base de donnée). Comme je l'ai indiqué plutôt, je
  demanderais aux admins s'ils sont au courant d'un quelconque
  problème.
  Les problèmes rencontrés par les serveurs récemment étaient liés a
  un contrôleur RAID défectueux, qui a été changé depuis.
  
  Emilie Laffray

Ouaip je n'ai pas été assez prudent sur les termes... +1  désolé tes
propos étaient clairs.
Benoît R.
  




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

Re: [OSM-talk-fr] Utilisation de bulk_upload & bulk_upload_sax



  
  
Le 21/09/2010 15:30, Tenshu a écrit :
2010/9/21 Vincent Pottier 
  

  
Quoi qu'il en soit du respect des protocoles, je trouve JOSM
peu clair
au moment de la transaction ou de son échec.
Il me semble que dans des versions précédentes de JOSM (il y
a 6 mois
environ), lors d'un upload par paquet, les objets en local
étaient mis
à jour paquet par paquet (id et statut), ce qui, me
sembl-t-il n'est
plus le cas. Lors d'un upload de 20 paquets, si la
transaction est
interrompue (volontairement ou non) au 10e, j'ai
l'impression que les 9
paquets envoyés ne sont pas mis à jour dans JSOM, ce qui
fait qu'une
relance de la transaction renvoie les nouveaux objets en
double.
Mais, bon, je n'ai pas de certitude...
  


  C'est exactement ça le problème. 

  
  
  -- 

On a avancé :
1 - il y a un pb côté JOSM a coup sûr => donc avertir l'équipe de
JOSM ;
2 - les serveurs sont PROBABLEMENT surchargés et donc ce pb est plus
fréquent et ne passe plus inaperçu => SIMILI pb côté charge
serveur.

note : en gras, termes prudents, même si cela semble confirmées par
Émilie, mais...

Reste à rédiger une note à destination de l'équipe JOSM pour ceux
qui ont une expérience du pb et leur transférer : "Il y a 6 mois on
n'avait pas ce pb parce que mise à jour locale des paquets.
Aujourd'hui ce n'est plus le cas mais ça pose pb avec les imports
massifs quand pb en cours d'export vers le serveur..."

Benoît R.

  




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

Re: [OSM-talk-fr] La France, lanterne rouge des erre urs dans OSM ? (était: Route non connectée)



  
  
+1

Le 21/09/2010 13:44, Guilhem Bonnefille a écrit :

  Je ne suis pas vraiment actif dans la communauté OSM. Toutefois, en
suivant quelques échanges, je ne peux que constater que l'équipe QA-fr
semble exister, au moins informellement. En effet, il y a déjà pas mal
de personnes qui relaye ce type d'information sur la liste, ou qui
mette au point des outils.

Pour exemple, il n'y a qu'à regarder quelques jours en arrière,
lorsqu'un outil de mesure de l'avancement des autoroutes a été
annoncé, instantanément plusieurs contributeurs se sont attaché à ce
projet d'amélioration de la "qualité" des représentations des
autoroutes dans OSM/France.

Du coup, mon avis est qu'il manque simplement à concrétiser ce groupe QA-fr :
* une ML ?-),
* une page wiki,
* un code pour les titres de mails,
* une signature à insérer dans les mails des membres de ce groupe.
Pourquoi concrétiser ? Simplement parce que parfois, l'appartenance à
un groupe reconnu et clairement identifié par les autres peut aider à
contribuer.

Il serait certainement utile de réorganiser les informations du wiki
autour de ce thème QA-fr, à commencer par une traduction de
http://wiki.openstreetmap.org/wiki/Quality_Assurance

Mais bon, c'est mon regard de gugusse qui parle beaucoup et qui fait rien.

Le 20 septembre 2010 13:28, Emilie Laffray  a écrit :

  


2010/9/20 Guilhem Bonnefille 


  
Comme dans les gros projets, va falloir monter une team "QA" pour
veiller à la qualité des données et remédier aux erreurs (ou du moins,
mettre en oeuvre des plan d'actions pour les résorber).



Je pense qu'une team QA sera assez difficile a mettre en oeuvre meme si
c'est une tres bonne idee. Je pense que certains d'entre nous passont deja
un certain nombre de temps a corriger de nombreuses erreurs mais l'essentiel
serait déjà d'avoir des outils qui évitent de créer les erreurs en premier
lieu.

Emilie Laffray

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



  
  



  


Ce message entrant est certifié sans virus connu.
Analyse effectuée par AVG - www.avg.fr 
Version: 9.0.851 / Base de données virale: 271.1.1/3149 - Date: 09/21/10 08:34:00




  




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

Re: [OSM-talk-fr] Utilisation de bulk_upload & bulk_upload_sax



  
  
Le 21/09/2010 13:11, Emilie Laffray a écrit :

  
  2010/9/21 Benoît ROUSSEAU <adressepossi...@free.fr>

   
Ces investigations et/ou des essais pourraient très bien
être menés en coordination avec l'équipe OSM en charge des
serveurs en attaquant la vraie base avec des objets générés
sur des zones de "tirs" (pourquoi pas les champs de tirs
militaires inscrits dans la base), ...

Dans un premier temps, Émilie, pourrais-tu nous obtenir
l'avis de l'équipe qui gère les serveurs sur l'origine
possible ou avérée de tous ces doublons d'après eux ?
  

  
  
  J'en parlerais. Je ne sais pas quand forcement mais la semaine
  prochaine il y a une réunion du Technical Working Group (les
  admins et les devs), donc il est certain qu'on aura une discussion
  la dessus, puisqu'un des sujets est comment améliorer les
  performances.
  Il faut noter qu'un nouveau serveur va être bientôt acheté.
  
  Emilie Laffray
  



Merci :p. En espérant qu'on y verra plus clair.
Il est pratique d'avoir des francophones au sein des instances
dirigeantes.
Benoît R.
  




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

Re: [OSM-talk-fr] Utilisation de bulk_upload & bulk_upload_sax



  
  
Le 21/09/2010 12:06, Tenshu a écrit :
Visiblement JOSM semble trop instable pour les
  imports, je pense que certain comme moi en ont fait les frais.
  Par ailleurs j'ai moi même tenté d'utiliser bulk_upload_sax.py
  sur la commune de Corbeil-Essonnes, le script a commencé à envoyer
  des nodes dupliqués en 10 à 20 exemplaires.
  Est qu'il serait envisageable de détailler la doc sur ce script,
  voir de le présenter dans le wiki comme une mini-formation à
  l'import de gros documents?
  
  -- 
  Mon weblog - http://www.tenshu.fr/
  Je soutiens le Logiciel Libre, j'adhère à l'APRIL !
  

Je repose la question du côté serveur... Sommes nous certains que
les serveurs tiennent la charge et respectent leur engagement
protocolaires ? C'est une histoire à deux bouts les transactions
d'import !

- Je veux bien accepter que JOSM déconne mais il a fait ces preuves
par le passé - mais cela peut être simplement un pb de temps de
réponse exigé pour le serveur par JOSM qui devrait être allongé ;
- je veux bien croire que bulk_upload_sax.py déconne mais même sans
documentation je ne le l'imagine pas, spontanément ou par défaut,
être configuré pour générer des doublons ;
- lors de mes connexions à l'API sur, par exemple 45 000 points
traités en 6-8 heures, il y a régulièrement quelques requêtes non
satisfaites, ...
- je note qu'on ne parle de ce type de pb qu'avec l'apparition d'une
charge importante des serveurs depuis l'import bâti et sûrement la
mise en branle de nouveaux pays.

Je veux bien mettre en accusation JOSM, BULK_UPLOAD et d'autres
clients API si on me prouve qu'effectivement il ne respectent pas
l'API, les protocoles, ... Cela devrait être faisable par des
programmeurs dans ces langages, étant donné qu'ils sont open-source.


Sommes nous sûr que la bases, le matériel, ... côté serveur tiennent
la charge à tout moment ? A ton testé, prouvé, ... ? Peux t-on
reproduire ces pb sur des serveurs "perso" ? Peux t'on répéter
exactement et à coup sûr ces pbs ? Si on refait un import "merdé" a
t'on les mêmes pbs ? ...

Ces investigations et/ou des essais pourraient très bien être menés
en coordination avec l'équipe OSM en charge des serveurs en
attaquant la vraie base avec des objets générés sur des zones de
"tirs" (pourquoi pas les champs de tirs militaires inscrits dans la
base), ...

Dans un premier temps, Émilie, pourrais-tu nous obtenir l'avis de
l'équipe qui gère les serveurs sur l'origine possible ou avérée de
tous ces doublons d'après eux ?

Benoît R.
  




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

Re: [OSM-talk-fr] Import bâtiments en France

2010-09-20 Par sujet Benoît ROUSSEAU



  
  
Le 20/09/2010 18:07, Tenshu a écrit :
2010/9/20 Emilie Laffray 
  

  
  Quant a l'utilisation de JOSM pour un import quelconque, je ne
  commenterais pas mais je n'en pense pas moins. C'est toutefois
  l'outil le plus pratique a l'heure actuelle.
  
Emilie Laffray

  
  
  C'est bien beau de dire ça, j'utilise Linux au quotidien et je me
  dit youpi utilisons bulk_upload pour importer les bâtiments depuis
  le cadastre.
  Et bien totu semblait rouler mais sur Corbeil-Essonnes ils c'est
  mis en tête de créer chaque éléments en 10-20-30-50 exemplaires.
  J'ai sué sang et eau pour revert tout ce foutoir.
  
  Et pendant ce temps personne n'a été capable de me décrire comment
  cet outil fonctionne etc.
  Alors j'ai utilisé JOSM sur Draveil, mais il m'a dupliqué 1700 way
  et leur nodes.
  
  Depuis je n'ai plus importé de bâtiments en me disant que
  j'attendrais que le bon outil soit disponible.
  Et c'est pas la découverte des (centaines) de milliers d'overlap
  entre bâtiments qui va me faire changer d'avis.
  
  -- 
  Mon weblog - http://www.tenshu.fr/
  Je soutiens le Logiciel Libre, j'adhère à l'APRIL !
  

Pour faire suite à la conversation dans son ensemble et pas ce
courrier en particulier avec lequel je suis en accord...

Pour ma part, je pense que ça merdx au moins pour une part côté
serveurs. Que les outils ne sont pas la cause et la source de tous
les mots mais que la charge de travaille imposée par l'import massif
en France couplé à l'émergence d'autres pays, les traitements
massifs de différents sites, fait que ça révèle des faiblesses au
niveau serveurs. Quand je dis serveurs c'est à prendre de manière
générique, cela peut être logiciel, matériel, ...
J'ai pour la suppression des points orphelins, des requêtes qui
n'aboutissent jamais, ... Sans conséquences dans ce cas, mais
révélateur. Il m'est difficile de croire que JOSM ne respecte pas
les protocoles et ne gère pas correctement les erreurs même si c'est
possible. Je dis qu'il faudrait ptet voir côté serveur et protocoles
avant de taper sur les clients. Et ce n'est pas Potlatch V2 qui va
changer la face du monde OSM.

Benoît R.
  




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

Re: [OSM-talk-fr] La France, lanterne rouge des erre urs dans OSM ? (était: Route non connectée)

2010-09-20 Par sujet Benoît ROUSSEAU



  
  
Le 20/09/2010 13:14, Pieren a écrit :

  On pourrait le croire si on regarde ces
quelques statisques de routes non connectées détectées par
l'outil OSM Inspector mis à disposition par Geofabrik:
Pour l'Europe.
http://neis-one.org/wp-content/uploads/2010/09/20100918_Stats_EU.png

Plus détaillé pour les 6 "premiers":
http://neis-one.org/wp-content/uploads/2010/09/20100918_Stats_EU_top6.png

  
  
  (vu sur le blog de Pascal Neis)
  Pieren
  



Ca va générer du trafic sur la liste dev pour ce qui concerne les
ways dupliqués et ça donne une info : "la France est en chantier".
Pour ce qui est des classements... c'est comme pour la taille du BZ
France... on est pas en compétition.

Benoît R.
  




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

Re: [OSM-talk-fr] chemin recouvert à marée haute

2010-09-14 Par sujet Benoît ROUSSEAU



  
  
Le 14/09/2010 21:33, Vincent de Chateau-Thierry a écrit :

  
  Le 14/09/2010 20:54, g.d a écrit :
  
  

Il y a eu déjà une discussion à ce sujet, ne sais plus quand, ni
qu'en

est sorti.

Par exemple il y a ceci :

http://www.openstreetmap.org/?lat=46.927&lon=-2.1176&zoom=14&layers=O

mais je trouve le "waterway:tidal" pas heureux.

Ce n'est pas la D 948 qui par marée haute se transformerait en
un canal

navigable.

La carte n'affiche pas la contrainte.


  
  Bien d'accord. "tidal" devrait concerner une zone de part et
  d'autre de la route, qui montre la surface approximativement
  dégagée à marée basse.
  
  
  Il nous faudrait peut-être un tag qui
indique, qu'une route n'est

praticable que temporairement,

dans le groupe des "restrictions",

avec différents valeurs qui indiqueraient les causes.

  
  (...)
  
  

Les Champs Elysées à Paris les 14 juillet se laissent taguer
avec

date_on / date_off.

Un centre ville impraticable chaque samedi à cause du marché se
laisse

taguer avec day_on / day_off.


Mais,

une route (passage du Gois)

ou un chemin de fer

(http://www.openstreetmap.org/?lat=54.679&lon=8.7236&zoom=12&layers=O)

peuvent être inondables par la marée,


  
  (..)
  
  > blubb-blubb sponge-bob.
  
  
  Dans le cas du Gois, qui ressemble à ce que Ziva indiquait dans sa
  question, on ne peut pas indiquer d'horaire, sachant que le
  passage est possible 2 x 3 heures par tranche de 24 heures, et que
  les créneaux changent quotidiennement, puisqu'ils encadrent les
  heures de basse mer. On pourrait imaginer un tag relatif plutôt
  qu'absolu, sur le principe des Access time restrictions :
  
  hour_on : 90 mn to low tide
  
  hour_off : 90 mn past low tide
  
  ou qqch du genre.
  
  
  vincent
  


Juste une remarque l'abréviation de "minute" est "min" : http://www.industrie.gouv.fr/metro/aquoisert/si.htm#ut.
Benoît R.
  




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

Re: [OSM-talk-fr] Traces GPS orphelines - comment les dénicher ?

2010-09-14 Par sujet Benoît ROUSSEAU



  
  
Le 14/09/2010 17:00, Bruno Cortial a écrit :

  Bonjour,
   
  Existe-t-il un outil ou une carte qui nous indique les traces
GPS remontées dans OSM et qui n'ont pas fait l'objet d'une
édition dans OSM ? Par exemple des traces qui n'ont pas de
highway OSM à x mètres. Je fais des imports de bâti dans des
coins en peu désoeuvrés côté carto, et il n'est pas rare que je
découvre sous JOSM des traces non exploitées. C'est bien domage
de laisser ces contributions en friche et invisibles parce qu'il
n'y a pas de contributeur-éditeur dans le coin.
Elle peuvent sans doute être taguées au moins en road, croisées
avec le cadastre...
   
  Pour trouver ce genre de trace je télécharge une large zone
jous josm avec les traces, je filtre pour n'afficher que les
highway et choisi une couleur bien contrastée pour les traces.
Avec le bâti  télécharger une large zone sous JOSM devient
impossible, mais l'import du bati n'est pas le sujet ;-)
   
  Autres questions:
  * il n'y a pas d'export global de traces façon planet.osm ?
  * On peut suivre les éditions OSM d'une zone via un flux RSS
ou l'outil OSM Mapper. Et les traces ?
  * Quelqu'un a-t-il un avis positif sur le système de
tag associés aux traces ?
   
  A+
  BrunoC
   
  

C'est une bonne idée que de les découvrir et les les indiquer.
Les passer automatiquement en "road" je suis moins sûr.
Benoît R.
  




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

Re: [OSM-talk-fr] Quelles évolutions pour une meille ure prise en charge des nouveaux venus (et des moins nou veaux) ? ( était : Changement de licence [etc .])

2010-08-26 Par sujet Benoît ROUSSEAU





Emilie Laffray a écrit :

  
  2010/8/26 Eric 
  

+10

Moi  j'avoue ne pas du tout aimer les Wikis au sens large sans vouloir
troller  on  plus.  Je  trouve  que très souvent, ils se résument à un
catalogue  de  liens  et au bout de 2 ou 3 clicks sur des liens, on ne
sait  pas  d'où  on  est parti donc impossible de revenir.

Il est donc impossible de parcourir l'arbre, on peut passer 20x à coté
d'une  page interessante. Il y a dejà quelques mois, quelqu'un s'etait
dévoué pour faire un PDF pour le B-A-BA mais il avait eu des réactions
très froides (un PDF c'est pas bien, c'est figé, ...) mais ce début de
tutorial  m'avait bien aidé. Des pages dont 20% de l'espace en haut et
à gauche sont "perdus" en habillage et dont le contenu et une liste de
liens  vers  d'autres points du wiki, c'est frustrant je trouve.

Donc, en résumé, pour moi, Wiki:0 PDF:1
  
  
  
Je partage ton analyse :)
Donc +1
  
Emilie Laffray
  


+1. Un bon vieux PDF imprimable.
Benoît R.





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

Re: [OSM-talk-fr] [Tech] Noeuds orphellins

2010-08-18 Par sujet Benoît ROUSSEAU





Ce sont les nœuds dupliqués en France uniquement ?

Xinfe Ewalavir a écrit :
Hummm, c'est sur la bonne voie :
  http://matt.dev.openstreetmap.org/dupe_nodes/dupe_nodes.png
  
Bien joué !
  
  2010/8/18 Benoît ROUSSEAU <adressepossi...@free.fr>
  
J'ai effacé tous les nœuds
orphelins trouvés jusqu'au 27 juillet 2010.
Soit moins de 56.089 nœuds en 3-4 jours.

J'ai arrêté au 27 juillet car je suis tombé sur un import CLC a cette
date et dont les points ne sont toujours pas reliés. J'ai écrit à
l'auteur sans réponse pour l'instant. Est-ce un import abandonné ? Je
n'ai pas compris ce qui été en cours, pas en cours et depuis quand sur
la page wiki d'import des CLC. Donc si qqun sait...

Il y a d'autres imports bizarres mais comme les serveurs OSM ont l'air
sur les rotules, "wait and see" les points seront peut-être connectés
un jour.

Benoît R.

  
  





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

[OSM-talk-fr] [Tech] Noeuds orphellins

2010-08-18 Par sujet Benoît ROUSSEAU





J'ai effacé tous les nœuds orphelins trouvés jusqu'au 27 juillet 2010.
Soit moins de 56.089 nœuds en 3-4 jours.

J'ai arrêté au 27 juillet car je suis tombé sur un import CLC a cette
date et dont les points ne sont toujours pas reliés. J'ai écrit à
l'auteur sans réponse pour l'instant. Est-ce un import abandonné ? Je
n'ai pas compris ce qui été en cours, pas en cours et depuis quand sur
la page wiki d'import des CLC. Donc si qqun sait...

Il y a d'autres imports bizarres mais comme les serveurs OSM ont l'air
sur les rotules, "wait and see" les points seront peut-être connectés
un jour.

Benoît R.



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

Re: [OSM-talk-fr] Diff import bâti [Tech]

2010-08-06 Par sujet Benoît ROUSSEAU





Steven Le Roux a écrit :

  2010/8/6 Christophe Merlet :
  
  
Bonjour,


J'ai constaté que depuis mes derniers imports semi-auto du bâti, le
cadastre avait était mis à jour et que de nouveaux bâtiments avait fait
leur apparition.

Existe t'il une méthode qui me permettrait de déterminer les nouveaux
bâtiments et de les importer ?

Sachant que, pour simplifier la création de diff, je possède les pdf de
mes précédents imports et je peux recréer les .osm correspondants.

Ce script va devenir indispensable, voire primordiale avec le temps...

Si la méthode du diff entre 2 fichiers .osm du bâti cadastre s'avère la
plus simple et facile pour gérer les mises à jour, il faut prévoir de
conserver ces fichiers car il est à ma connaissance impossible de
demander l'état du cadastre vectoriel à une date t.


  
  
Plutôt que de conserver des osm ou pdf, il vaut mieux avant chaque
diff, le faire sur la base existante. Ce que tu avais dans ton fichier
originel a pu être modifié.
Il faudra donc récupérer un extrait du planet sur ta zone d'import,
faire le diff, puis injecter les nouvelles données.

  

Avant de tout jeter, pdf et osm, attendre de voir.
Si une comparaison avec l'existant en base est nécessaire, un
prétraitement sur des données plus légères pourrait accélérer et
faciliter les choses.
Par exemple, plutôt que d'attaquer le boulot sur Paris en entier pour
10 bâtiments, ne comparer avec l'existant que sur des zones plus
restreintes.

Benoît R.


  Mais ça va être plus compliqué que pour du filaire, notament pour les
extentions de batiments. Car on risque de ne pas voir facilement que
les noeuds ne sont pas connectés. Ou alors il faudra l'intégrer à un
script de vérif, ou faire un check à posteriori avec les outils le
permettant déjà.


  
  
       Librement,
--
Christophe Merlet (RedFox)


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


  
  


  
  


Ce message entrant est certifié sans virus connu.
Analyse effectuée par AVG - www.avg.fr 
Version: 9.0.851 / Base de données virale: 271.1.1/3052 - Date: 08/05/10 08:35:00

  





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

Re: [OSM-talk-fr] [Vote] Nouvelles listes de discussion

2010-08-02 Par sujet Benoît ROUSSEAU





Christophe Merlet a écrit :

  
Cette liste existe déjà. Elle s'appelle talk-fr !


Un sondage a eu lieu avec des questions parfaitement claires. Inutile
d'essayer de donner un tout autre sens aux questions et aux résultats du
vote !

Créons la liste dev-fr et redirigeons y toutes les discussions
éminemment techniques.


	Librement,
  
  


+1 sinon ce n'est pas la peine de faire un sondage.
Tout le monde à donné son avis et la majorité s'est orienté vers "les
devs à l'écart". Si ça ne fonctionne pas tant pis on en rediscutera.
Mais personne n'empêche personne de monter sa liste son blog, son
service de news, ...
Benoît R.




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

Re: [OSM-talk-fr] Alerte ! Les doublons, ça grossi t sans arrêt

2010-07-28 Par sujet Benoît ROUSSEAU





Benoît ROUSSEAU a écrit :

  
  
Marc Sibert a écrit :
  


Le 26/07/2010 11:52, Marc SIBERT a écrit :
Bonjour,
  
Voilà, j'ai envoyé le dernier lot de suppressions ce matin : http://www.openstreetmap.org/browse/changeset/5318380
  
Enfin, pour Osmose, il en reste encore : http://osmose.openstreetmap.fr/cgi-bin/all-update.py?source=64
  
A+
  
-- 
Marc Sibert
  m...@sibert.fr

Encore un petit 10k way de supprimés : http://www.openstreetmap.org/browse/changeset/5343124

Bon, je vais insisté, faut tuer le problème dans l'œuf.
Et pendant que j'y suis je suggère un coup de râteau sur les nœuds
orphelins.

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

  
Ok je lance le ratissage... 
  


Le râteau demande aujourd'hui des capacités mémoire que je n'ai pas et
qui sont indécentes. Je vais changer l'ago pour que ça tourne dans des
limites raisonnables. Nouveau ratissage au plus tard dimanche.

Benoît R.



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

Re: [OSM-talk-fr] Alerte ! Les doublons, ça grossi t sans arrêt

2010-07-28 Par sujet Benoît ROUSSEAU





Marc Sibert a écrit :

  
  
Le 26/07/2010 11:52, Marc SIBERT a écrit :
  Bonjour,

Voilà, j'ai envoyé le dernier lot de suppressions ce matin : http://www.openstreetmap.org/browse/changeset/5318380

Enfin, pour Osmose, il en reste encore : http://osmose.openstreetmap.fr/cgi-bin/all-update.py?source=64

A+

-- 
Marc Sibert
m...@sibert.fr
  
Encore un petit 10k way de supprimés :
  http://www.openstreetmap.org/browse/changeset/5343124
  
Bon, je vais insisté, faut tuer le problème dans l'œuf.
Et pendant que j'y suis je suggère un coup de râteau sur les nœuds
orphelins.
  
A+
  -- 
Marc Sibert
m...@sibert.fr
  


Ok je lance le ratissage... 



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

Re: [OSM-talk-fr] Systèmes de numérotation des voi es en France. Suite, c'est moins tranché.





julien balas a écrit :

  Ca pose pas de pb en "manuel". Dans le cadre
de la reco. semi auto., les

points peuvent être correctement placés et reliés à la rue s'il sont ni

trop près ni trop loin de celle-ci. Sinon, il faudra quand même
corriger

des placements à la main. On peut aussi imaginer considérer les

"footway" et les allées privées comme faisant partie de la rue à

laquelle elle sont connectées et pour moitié si elle sont connectée à 2

rues.

  
  
Si on parle d'une chaine qui
  
- extrait automatiquement les PDF du site du cadaste
  
- les converti automatiquement en SVG
  
- puis en OSM
  
- puis cree les adresses des maisons
  
- puis cree les relations sur les rues
  
  
Est ce qu'on peut toujours parler de "semi" automatique ?
  
Est ce qu'on est toujours dans ce fameux travail "composite" qui nous a
autorisé l'acces au cadastre ?
  
  

Oui.
1 - Les adresses sont reconnues par leur forme graphique.
2 - Tout n'est pas parfaitement reconnu a, b, c, bis, ter, quater, ...
3 - Les adresses sont généralement repositionnées et ne sont pas à
l'emplacement signifiées par le cadastre, on change leur localisation.
4 - Parce qu'il faut ensuite corriger manuellement les erreurs et
prendre des décisions concernant les incertitudes.

Benoît R.



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

Re: [OSM-talk-fr] [Tech] Question sur l'aide à la saisie d'adresses du plugin Cadastre.





Pieren a écrit :

  2010/7/25 Benoît ROUSSEAU <adressepossi...@free.fr>
  
Mais elles
sont finalement toutes regroupées dans la même relation associée à la
voie en magenta. Pour moi c'est une erreur. Quand est-il réellement ?

  
  
  
La doc sur la relation ne dit rien sur cette question.
"Next to a street", "Next to a way", plus le petit schéma dans "Associating a building-polygon with a street" me
semble faire parties du concept global.  
Mais j'en ai une autre : la relation lie un noeud avec un
numéro et un way avec un nom. Quel intérêt d'associer le bout de rue le
plus proche du moment que l'association est correcte et que le noeud
désigne la bonne position ? 

Faciliter les éditions et les corrections manuelles par la suite.
Il serait d'ailleurs plus logique d'utiliser une relation type http://wiki.openstreetmap.org/wiki/Relations/Proposed/Street
qui lie l'ensemble des éléments d'une rue et non des adresses à un
segment puis un un nom comme proposé dans le schéma commun.

Pieren

Benoît R.


  




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

Re: [OSM-talk-fr] Systèmes de numérotation des voi es en France. Suite, c'est moins tranché.





simon a écrit :

  Le dimanche 25 juillet 2010 à 11:46 +0200, Pierre-Alain Dorange a
écrit :
  
  
Le 25 juil. 10 à 11:35, simon a écrit :



  

  Vous avez deux références différentes qui couvre l'ensemble de
nos
discussions passées et pointe un manquement dans le schéma
actuel :
le simple positionnement d'un n° de voie type accès. Si vous
avez
des propositions, ... 
  


Je suis pas sur d'avoir tout bien suivi, mais dans OSM l'intérêt
des
adresses (numérotation) est de faire du routage. Donc de permettre
à
un utilisateur de trouver l'adresse qu'il recherche, donc le point
d'accès depuis depuis la rue.

  
  Pas forcément, un immeuble peut avoir plusieurs numéro dans une
coure
intérieur avec un ou deux accès sur la rue. Dans ce cas si utilise
un
rendu papier, la numérotation sur l'entrée est plus utile (cela
évite de
faire trois fois le tours de la cours ou de prendre l'entrée à
l'opposé. 
  


On est dans une situation de micromapping là, mais rien n'empêche de
tracer la voie qui mène à la cour, voir la cour pour y apposer les
numéros. Ce serait même indispensable pour du routage jusqu'au bout.
Car sans voies (highway) pour accéder numéro le routage ne sera
qu'approximatif.
Pour que le routage soit pleinement opérationnel au niveau de numéro
il faut que ces numéros soit sur (ou très proche) une voie afin de
lever les ambiguités.


  
  Je pensait a ce genre de cas
http://maps.google.com/?ie=UTF8&t=k&ll=47.380604,0.672038&spn=0.001707,0.005284&z=18

toutes les entrées sont à l'intérieur de la cour, interdite aux véhicule
a moteur.


  

Ca pose pas de pb en "manuel". Dans le cadre de la reco. semi auto.,
les points peuvent être correctement placés et reliés à la rue s'il
sont ni trop près ni trop loin de celle-ci. Sinon, il faudra quand même
corriger des placements à la main. On peut aussi imaginer considérer
les "footway" et les allées privées comme faisant partie de la rue à
laquelle elle sont connectées et pour moitié si elle sont connectée à 2
rues.

Benoît R.



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

Re: [OSM-talk-fr] Systèmes de numérotation des voi es en France. Suite, c'est moins tranché.





Pierre-Alain Dorange a écrit :

  
  Le 25 juil. 10 à 10:08, Benoît ROUSSEAU a écrit :
  
  Vous
avez deux références différentes qui couvre l'ensemble de nos
discussions passées et pointe un manquement dans le schéma actuel : le
simple positionnement d'un n° de voie type accès. Si vous avez des
propositions, ...
  
  
  
Je suis pas sur d'avoir tout bien suivi, mais dans OSM l'intérêt des
adresses (numérotation) est de faire du routage. Donc de permettre à un
utilisateur de trouver l'adresse qu'il recherche, donc le point d'accès
depuis depuis la rue.
  Le bâtiment a une moindre importance ici, ce qui compte c'est de
tracer une route pour permettre a l'utilisateur de trouver l'accès
qu'il cherche. Une fois devant, il n'a qu'a pousser la porte et entrer.
  Dans cette "vision", le numéro doit se trouver en limite
rue/parcelle par sur les bâtiments qui peuvent être éloigné de la rue
et conduire à des erreurs de routage (si le bâtiment est loin de sa rue
d'accès mais proche de celle de derrière ou il n'y a pas d'accès)...
   
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  -- 
  Pierre-Alain
Dorange, 
  Blog Citoyen de Cognac : <http://cognac-citoyen.blogspot.com/>
  
  
  
  
  
  
  
  Twitter : <https://twitter.com/padorange>
- Facebook : <http://www.facebook.com/pa.dorange>
  
  
  
  
  
  
  
   
  
  
  


L'idée de base du premier message était de dire que Pieren n'avait pas
tord et du second que les partisans du "surtout routing, placement en
limite de parcelle" non plus. Dans "la réalité", les deux conceptions
se croisent aussi. C'est l'usage des utilisateurs qui détermine le
point de vue. Comme il n'y a pas de directives au sein d'OSM, après "On
ne tag pas pour le rendu" on risque d'avoir "on ne tag pas que pour le
routing." ou "on ne tag pas dresser un annuaire" :).

Si personne n'a tord ou raison, le placement en limite de parcelle est
celui qui offre le plus d'alternatives. Reste que le "tagguer"
role=house dans une relationStreet me gène. M'enfin, ...

Benoît R.





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

Re: [OSM-talk-fr] Systèmes de numérotation des voi es en France. Suite, c'est moins tranché.

Benoît ROUSSEAU a écrit :
Re...

Selon : http://fr.wikipedia.org/wiki/Num%C3%A9rotation_des_voies#France
ce sont bien les bâtiments qui sont numérotés en
France. Ni les parcelles, ni la rue elle même.
Donc je revois ma copie sur l'import semi-auto des adresses pour
associer les adresses aux bâtiments "wall=yes" quand c'est possible,
sinon à limite parcellaire la plus proche et à défaut à sa position
dans la voie sur le Cadastre.

Benoît R.

Suite à mon précédent message, j'ai continué mes recherches parce que
pour moi ce sont les entrées qui devraient être numérotée et non les
immeubles tout en pensant que l'objectif du Cadastre est la perception
de taxes sur l'immobilier.

Donc une autre source jette le flou : http://www.laposte.fr/sna/IMG/pdf/BAT_LIVRET_comprendre_ladresse_2008.pdf.

Effectivement les objectifs de ces deux institutions de l'adressage ne
sont pas identiques, donc leur attentes diffèrent. Mais il y est noté
dans ce document : "un numéro : tous les accès donnant sur une voie
doivent être numérotés." ce qui est en contradiction avec l'article de
Wikipédia. Mais aussi "En France, seules les mairies ont autorité à
initier la dénomination d’une voie ainsi que sa numérotation." et en
dernier lieu en informe "[...] divers organismes : [...] et de manière
obligatoire : le cadastre et la DGI (Direction Générale des Impôts).".
Ce qui laisse donc entendre que ce sont les accès qui numérotés "par"
la Mairie qui en informe le Cadastre.

Pour ma part j'interprète "accès" comme l'interface entre voie et un
bâtiment dans le sens limite parcellaire.

Au final, les deux systèmes semblent valables même s'ils ne recouvrent
pas les même usages. Les relations type "associatedStreet" ne proposent
que la prise en compte de la numérotation des bâtiments avec les
membres "role=house".

Vous avez deux références différentes qui couvre l'ensemble de nos
discussions passées et pointe un manquement dans le schéma actuel : le
simple positionnement d'un n° de voie type accès. Si vous avez des
propositions, ...

Benoît R.

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

[OSM-talk-fr] Systèmes de numérotation des voi es en France.

2010-07-24 Par sujet Benoît ROUSSEAU





Re...

    Selon : http://fr.wikipedia.org/wiki/Num%C3%A9rotation_des_voies#France
ce sont bien les bâtiments qui sont numérotés en
France. Ni les parcelles, ni la rue elle même.
    Donc je revois ma copie sur l'import semi-auto des adresses pour
associer les adresses aux bâtiments "wall=yes" quand c'est possible,
sinon à limite parcellaire la plus proche et à défaut à sa position
dans la voie sur le Cadastre.

Benoît R.




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

[OSM-talk-fr] [Tech] Question sur l'aide à la saisie d'adresses du plugin Cadastre.

2010-07-24 Par sujet Benoît ROUSSEAU

Bonjour,

J'ai classé ça en [Tech] parce que je pense que c'est plus une
question technique qu'autre chose.

Pour le contexte : afin de rendre interopérable les outils de
gestion d'adresses avec la saisie semi auto je regardais comment le
plugin d'aide à la saisie du plugin Cadastre gérait le nommage des
relations associatedStreet pour les rues en plusieurs segments pour m'y
conformer. L'exemple classique, c'est une rue qui comporte un pont, un
tunnel, comporte une mini allée, une piste cyclable commence ou
s'arrête, ... et de fait elle est décomposée en plusieurs segments pour
le même nom de rue.

Concernant la gestion des relation d'adressage, la page de
référence est, me semble t'il :
http://wiki.openstreetmap.org/wiki/Proposed_features/House_numbers/Karlsruhe_Schema.
D'après ce que je comprends c'est une relation par segment de rue
"street : one / house : one or more".

Quand j'essaie avec l'aide à la saisie d'adresses du plugin
Cadastre de saisir des adresses sur plusieurs segments de la même rue,
seule une relation est crée pour le premier segment, une relation par
nom de rue. Les autres adresses qui sont ajoutées par la suite sur
d'autres segments d'une même rue sont ensuite tous associés à ce
premier segment. Est-ce normal et conforme au Karlsruhe_Schema ?

Illustration bidon pour l'exemple :

Les deux segments portent le même nom de rue "name". Les adresses
encadrées en vert ont été saisies en sélectionnant la voie en magenta,
celles encadrées en rouge en sélectionnant la voie en gris. Mais elles
sont finalement toutes regroupées dans la même relation associée à la
voie en magenta. Pour moi c'est une erreur. Quand est-il réellement ?

Benoît R.

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

Re: [OSM-talk-fr] Google copie sur OpenStreetMap

2010-07-23 Par sujet Benoît ROUSSEAU





Etienne Chové a écrit :
Le
23/07/2010 10:31, Tanguy JACQ a écrit :
  
  Bonjour,


Je viens de m'apercevoir que google avait commencé a intégrer les

bâtiments sur google map en pseudo 3d, je ne sais pas si ça fait

longtemps qu'ils ont commencé ...



http://maps.google.com/maps?client=ubuntu&channel=fs&q=montbeliard&oe=utf-8&ie=UTF8&ei=8k9JTIiUKpa6jAfeiu3LDg&ved=0CBMQ_AU&hq=&hnear=Montb%C3%A9liard,+Doubs,+Franche-Comt%C3%A9,+France&ll=47.510266,6.798327&spn=0.0055,0.013894&z=17



  
  
Ce qui montre que le calage de leur rues et/ou bâtiment n'est pas
terrible. Ca a l'air d'être fait à partir du cadastre, car on voit des
traits fins à la limite wall=yes/no.
  

Et des limites parcellaires qui coupent le bâti :p



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

Re: [OSM-talk-fr] Autre anomalie dans le rendu des limites administratives

2010-07-22 Par sujet Benoît ROUSSEAU





Bonsoir,

C'est un pb récurent, les travaux sur les zones cyclables, ...

Est-ce que passer tout ça sur un calque avec open layer n'arrangerait
pas tout le monde ?
- Pour les auteurs des données historiques (pour une utilisation
actuelle j'ai bien noté) en séparant leurs données des données actuels
tout en pouvant les manipuler plus facilement ;
- Les réticents d'OSM en fournissant un fond de carte OSM sans limites
historiques incluses, ceci participant à la promotion d'OSM, ...

Christian, avez vous envisagé cette possibilité ? Seraît-elle
satisfaisante ?

Benoît R.

Christian Rogel a écrit :
1/
Il ne s'agit pas de mettre une limite historique sur le même plan que
les "officielles
  
2/ Il s'agit de savoir s'il y a une solution pour ceux qui en ont
besoin, ce besoin ayant autant de valeur qu'un autre.
  
Il a un potentiel de réalisation important, puisque touchant beaucoup
de domaines.
  
OSM sert à faire des cartes pour des livres ou des affiches, pas
seulement à se balader.
  
  
Les réflexions sur la Savoie libre (et même la Corse) sont parfaitement
déplacées, car hors sujet. Savoie aurait suffi, sinon, c'est politiser
la question. Et si c'est sans même avoir vécu dans les endroits
concernés...
  
  
Christian
  
  
  
Marc Sibert a écrit :
  
  
Le 23/07/2010 00:17, Art Penteur a écrit :

Le 22 juillet 2010 23:20, Christophe
Merlet  a écrit :
  
  
 
  Et puis on est au pays des bisounours,
tout le monde fait ce qu'il veut

avec la base OSM, non ?

Qu'est-ce qui empêche quiconque de le faire, puisque c'est possible ?


 
   ...
  
   Tiens, j'ai acheté un autocollant "GRD". Je vais mettre une
  
"admin_level=2; name=Groland" autour de ma parcelle cadastrale.
  
  
Art.
  
   
Ben tiens +1


Et une admin_level=2; name="Savoie Libre" au milieu de l'Essonne. «
Chacun fait, fait, fait c'qui lui plait, plait, plait ! » C'est un
projet libre, ou bien ?


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


Ce message entrant est certifié sans virus connu.
Analyse effectuée par AVG - www.avg.fr 
Version: 9.0.851 / Base de données virale: 271.1.1/3021 - Date: 07/22/10 08:36:00

  





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

Re: [OSM-talk-fr] [Urgent][Serveurs FREE] Stoc kage/répartition des serveurs

2010-07-22 Par sujet Benoît ROUSSEAU





Yoann ARNAUD a écrit :

  Salut à tous,

Voilà la problématique qui se pose :

Je stocke actuellement chez moi, dans mon garage, une dizaine de
serveurs, qui ont été donnés par la fondation free, il y a quelques mois.

Je vais quitter Nantes à la fin du mois de juillet pour rejoindre la
"douce et charmante ville" de Montbéliard.

Donc je fais quoi de ces serveurs ?

Certes, je pourrai tous les emmener avec moi, mais je ne vois pas trop
l'utilité.

Ce que je proposerai, c'est que l'on répartisse les machines sur le
territoire. L'avantage serait d'avoir de multiples interlocuteurs, si
jamais un jour quelqu'un a besoin d'un serveur ou juste d'une pièce de
rechange (on a déjà des disques qui ont claqué, ça peut se reproduire)
et ainsi d'agir avec plus d'efficacité.

Je suis bien sûr volontaire, pour en garder 2 ou 3 avec moi dans l'Est.
Etienne en a aussi sous le coude. J'ai discuté avec un membre de LOGIN,
récemment, qui va demander ce qu'il est possible de faire (pour rappel
LOGIN est l'association qui a reçu officiellement le don de serveurs).
On a donc potentiellement 2-3 serveurs dans l'Est, 3-4 dans le grand Ouest.

Qui serait volontaire pour en stocker sur Paris (j'y passe de temps en
temps) ? Dans le Sud-Ouest (j'y passerai sûrement pendant l'été) ?
Ailleurs ?


  
  


Je peux stocker sans limites sur Poitiers. Voir aussi avec Mickey86 si
il a des idées ou des contacts pour une connexion dans le coin.
Benoît R.



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

Re: [OSM-talk-fr] [Technique] Fwd: [OSM-dev] Help with implementation of multiplicatively weighted Voronoi diagram for nominatim

2010-07-22 Par sujet Benoît ROUSSEAU


Vincent de Chateau-Thierry a écrit :


C'est pour tendre vers cette unicité que Nominatim recourt à des polygones de 
Voronoï, en substitut de limites
administratives ou postales. Le but reste de pouvoir associer sans trop 
d'ambiguïté un nom de rue à un nom de ville/village
dont l'emprise, si elle n'existe pas, aura été approximée par un polygone dépendant de 
l'importance supposée de la "place" :
c'est la pondération ("weighted") recherchée dans le message initial.

vincent

  

Intéressant, je ne connaissais que la version "points" Delaunay/Voronoï.
De quoi sont composés les limites des cellules ? D'une combinaison 
d'arcs de cercles et de segments de droites.

Benoît R.

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

Re: [OSM-talk-fr] [Technique] Fwd: [OSM-dev] Help with implementation of multiplicatively weighted Voronoi diagram for nominatim

2010-07-21 Par sujet Benoît ROUSSEAU





Emilie Laffray a écrit :

  
  2010/7/21 Benoît ROUSSEAU <adressepossi...@free.fr>
  
Bonjour,
    LA référence c'est http://www.cs.cmu.edu/~quake/triangle.html.
Peut être voir avec son auteur.
    Voir aussi pour info le site dans son ensemble (une des pages) : http://www.voronoi.com/wiki/index.php?title=Voronoi_Applications.
Benoît R.

Sont adresse openstreet...@brian.quinion.co.uk
n'est pas la bonne je vous laisse lui transférer.

  
  
  
Tu peux me tutoyer :)
Le lien que tu as donne ne permet pas de faire ce qu'il veut notamment
de creer un poids pour chacun des noeuds. L'implementation que tu
pointes est juste un diagramme de Voronoi de base. C'est pour cela
qu'il regarde l'implementation dans CGAL, notamment une implementation
de Appolinaris.
  
Emilie Laffray

Ouaip, bah je "m'a trompé" dans ces intentions, alors qu'il dit bien
qu'il a une implémentation de base fonctionnelle.
Halala lecture en diagonale, réponse trop rapide > trafic inutile.
Je sors le fouet...
Mais j'aurai appris l'existence de ces graphs avec poids. Faut que je
regarde la chose  :)
Benoît R.



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

Re: [OSM-talk-fr] Entreprise de cartographie collabora tive basée sur OSM

2010-07-21 Par sujet Benoît ROUSSEAU





Shnoulle a écrit :

  -BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Le 21/07/2010 11:16, François Van Der Biest a écrit :

  
  
 et je vais
certainement m'installer en tant qu'auto entrepreneur 
Lionel RAUCH, co président de l'association C2iC


  
  Si je n'ai qu'un conseil à donner, si possible éviter le statut
d'auto-entrepreneur.

C'est un statut trop bancal qui amène plus de problèmes au final que de
solutions.
Il est bien pour : les retraités, les personnes travaillant à 3/4 temps
1/2 temps avec certitude de conserver leur poste jusque démission.

Sinon, trouver une autre solution avec l'aide d'organisme est sans doute
la meilleure solution (ce tyoe d'organisme ne peut prendre en charge
l'aide nécessaire que pour les entreprises dont le SIRET date de moins
d'un an)

:)

  

+1
Benoît R.



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

Re: [OSM-talk-fr] [Technique] Fwd: [OSM-dev] Help with implementation of multiplicatively weighted Voronoi diagram for nominatim

2010-07-21 Par sujet Benoît ROUSSEAU





Bonjour,
    LA référence c'est http://www.cs.cmu.edu/~quake/triangle.html.
Peut être voir avec son auteur.
    Voir aussi pour info le site dans son ensemble (une des pages) : http://www.voronoi.com/wiki/index.php?title=Voronoi_Applications.
Benoît R.

Sont adresse openstreet...@brian.quinion.co.uk
n'est pas la bonne je vous laisse lui transférer.

Emilie Laffray a écrit :
Bonjour,
  
je sais qu'il y a des gens tres pointus ici, donc je me permets de
reposter. Le createur de Nominatim a besoin d'aide pour implementer un
weighted Voronoi diagram utilisant CGAL. Donc s'il y a des gens qui
peuvent aider, lui envoyer un message.
  
Emilie Laffray



  -- Forwarded message --
From: Brian Quinion 
Date: 21 July 2010 13:20
Subject: [OSM-dev] Help with implementation of multiplicatively
weighted Voronoi diagram for nominatim
To: d...@openstreetmap.org
  
  
Hi,
  
I've been trying to get a working implementation of a multiplicatively
weighted Voronoi diagram written now for nearly a week and I'm really
struggling.
  
The intention is to use it to improve the the indexing quality and
speed of nominatim with regards to mixing city, town and village
points in some layers - I'm sure many of you have noticed the current
problem were towns and villages end up inside city boundaries
(producing weird addresses).
  
I have a working implementation for a non-weighted algorithm using
Fortune's algorithm [1] - if anyone has the time and maths skills to
adapt that it would be wonderful (can Fortune's algorithm even do
multiplicatively weighted Voronoi diagrams?) beyond that I've been
looking at adapting the demo from cgal [2] but I'm struggling due to
my poor C++ skills (and the fact that the c++ code makes use of insane
numbers of templates).  For someone who is really good with c++ or
already familiar with cgal it would probably be fairly easy.
  
Alternatively if anyone is aware of any other implementation or is
able to implement anything based on a different library that would
also be good.  I think it really has to be c or c++ - anything else
would be tricky to integrate.  Potentially an implementation in R [3]
using the postgresql module is another possibility.
  
If anyone can help let me know - otherwise I will struggle onwards and
hope to get somewhere!
  
--
 Brian
  
  
[1] http://en.wikipedia.org/wiki/Fortune's_algorithm
  
[2] http://www.cgal.org/Manual/latest/doc_html/cgal_manual/Apollonius_graph_2/Chapter_main.html
  
[3] http://www.r-project.org/
  
___
dev mailing list
  d...@openstreetmap.org
  http://lists.openstreetmap.org/listinfo/dev
  
  
  

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


Ce message entrant est certifié sans virus connu.
Analyse effectuée par AVG - www.avg.fr 
Version: 9.0.851 / Base de données virale: 271.1.1/3019 - Date: 07/21/10 08:36:00

  





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

Re: [OSM-talk-fr] [Tech] Extraction des adresses...





Denis a écrit :
Benoît
ROUSSEAU a écrit :
  
  
  Donc l'idée serai, par exemple, de pouvoir
monter un annuaire en plaçant directement les adresses directement en
tant que noeud sur les bâtiments quand ils existent.

  
  
Pas plus qu'OSM ne doit tagger pour le rendu, nous ne devons pas
modéliser pour des applications particulières , amha.
  
J'avoue que la question de l'adressage est très loin d'être simple à
gérer pour un projet comme le nôtre. Outre les questions de toponymie,
d'évaluation de l'exhaustivité (notion importante pour la plupart des
acteurs publics qui pourraient s'appuyer sur notre travail), des outils
mis en test en ce moment (qui me font assez peur, pour le moment), il
est nécessaire de se poser la question de savoir ce que nous voulons :
un référentiel -même incomplet ou imparfait- pour des services de
secours, une base pour du calcul d'itinéraire "porte-à-porte", etc.
  
J'ai peur qu'on ne se soit lancé dans défi encore au-dessus de notre
portée. Je m'explique plus bas.
  

Houla ! Sortie de son contexte, la phrase laisserai penser que je fais
la promotion de cette idée. Ce n'est absolument pas le cas.

  
En automatique, je réponds non une nième fois. La qualité n'étant pas
assurée, ni si je le fais, ni si c'est fait après.

Je prends l'exemple d'un centre commercial de Poitiers, l'îlot des
Cordeliers. Il occupe un paté de maisons et ouvre avec des adresses sur
trois rues. Il inclut un parking souterrain, des magasins en galerie,
des magasins en "façade" et des logements privé. Les bâtiments en
façade ont une adresse et ne sont pas accessible depuis les autres. Les
appartements ont une ou deux adresses, le parking, une adresse pour
l'entrée sortie, et les magasins de la galerie sont accessibles
quelques adresses. Associer tout ce petit monde au bâtiment est exacte,
associer tous ces commerces et résidences à toutes les adresses est
faux, choisir pour chacun l'adresse la plus proche est faux aussi.


Créer des relations entre les différents services et les adresses
serait par contre une possibilité. Ou alors, éventuellement, rapprocher
les POI services de leur adresse préférentielle pour qu'un calcul de
proximité puisse être fait. Auquel cas le calcul peut tout aussi bien
être fait en direct.

  
  
Je crois (c'est donc un acte de foi) qu'OSM a vocation à interpréter le
monde tel qu'il le conçoit et/ou le constate. Cela implique que la même
"réalité" soit vue différemment suivant les contributeurs. L'effet
communauté doit conduire à ce qu'une boulangerie à Brest, Toulouse,
Grenoble ou Strasbourg soit identifiable comme telle partout.
  
En quoi une adresse postale est-elle différente d'une boulangerie (sous
l'angle du tag) ?
  
Je crois qu'une adresse est un moyen, pas une fin. Elle sert à
identifier un point de départ ou d'arrivée dans une application de
calcul d'itinéraire (peu importe ce que ces adresses desservent). Elle
sert aussi à identifier des personnes (physiques ou morales) ; c'est le
fameux argument de la CNIL (localisant indirect).
  
La même adresse peut concerner plusieurs acteurs et un même acteur peut
avoir plusieurs adresses (certaines même difficilement localisables
-penser Boite Postale, CEDEX-)
  
Je ne crois qu'il est pas du ressort d'OSM de gérer cette relation n-n.
En revanche, nous avons toute légitimité pour indiquer que telle
adresse postale est géolocalisée par un couple de coordonnées.
  

Je suis bien d'accord. Peut être aurais-tu dû répondre à Pieren peut
être.

Je suis avec beaucoup d'intérêt les tous derniers outils de traitement
des données cadastrales ; il y a des avancées indéniables, mais aussi
des écueils dont il faut se méfier.
  
  
J'ai appris, ces derniers temps à me méfier de mes propres
contributions dans le domaine de l'adressage.
  
La vérité est dure à trouver : elle n'est ni dans le cadastre, ni dans
les pages jaunes, ni même dans les bases de données "pro", mais partout
à la fois (parfois nulle part).
  

Donc ne pas ajouter des erreurs aux erreurs inévitables qui vont déjà
s'y glisser tout en indiquant source et traitement.

Qu'une "entrée-sortie" (oximore ou I/O ?) de parking ait une adresse me
laisse, à titre personnel, perplexe, mais je suis comme Saint-Thomas,
je peux me laisser convaincre par des preuves.
  

En ce qui concerne le parking, c'est une société en elle même pas le
parking d'une autre.

Denis
  

Benoît R.



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

Re: [OSM-talk-fr] [Tech] Extraction des adresses...





Pieren a écrit :

  2010/7/20 Benoît ROUSSEAU <adressepossi...@free.fr>
  
Dans le même ordre d'idée,
trouves-tu alors normal d'avoir à calculer
l'inclusion en temps réel de POI services (beaucoup plus couteux en
temps) où places-tu les POI sur le way des bâtiments y compris pour
ceux inclus (restaurant dans ton exemple).


  
  
Les POI peuvent être sur le way du bâtiment, sur un node attaché au way
ou un node à l'intérieur du polygone. Tous les cas de figures sont
possibles puisque personne n'est forcé d'en respecté un en particulier.
Mais la plupart des contributeurs vont utiliser le polygone comme point
de repère ("mon boulanger se trouve dans ce bâtiment-là"). Il faut donc
pouvoir lier ce polygone avec son adresse avec le moins de doute
possible, en y mettant les tags adresses soit sur le way, soit sur un
node, peu importe.
  
  
Je n'ai pas compris ta question sur l'inclusion de POI services. Mais
si tu parles de mon exemple de liste des pharmacies d'une ville, ça
devrait pouvoir se faire dans un prétraitement automatique et non en
temps réel (mais pourquoi pas). Si les adresses ne sont pas liées aux
POIs à travers le polygone du bâti, cela devient plus compliqué et plus
incertain pour tous ceux qui voudront exploiter ces adresses dans le
futur (avec des résultats qui pourront varier d'une appli à l'autre).
Il restera toujours les cas plus complexes comme celui que tu cites qui
nécessiteront probablement d'avoir le tag addr sur chaque POI (une
pratique qu'il faudrait réserver à ce genre de cas). Mais ces cas
seront ultra-minoritaires.
  
Pieren
  

  

Ok,

Pour simplifier mon propos, je pense que ça passe par une relation
supplémentaire pour être générique. Ce qui permettrai d'avoir le
routage tout de suite et les relations supp par dessus dès maintenant
ou plus tard. Faut-il attendre que toutes les pharmacies soient
"tagguer" pour importer des adresses et ainsi de suite si qqun veux :
un annuaire des boulangeries, ... ? Ce n'est pas un troll pour discuter
de l'utilisation des relations ou de leur multiplication. Quant à
l'incertitude, elle ne peut être levée qu'humainement, je ne ferai pas
mieux en pré traitement qu'en traitement temps réel et je ne veux pas
ajouter des erreurs supplémentaires. J'ai presque l'impression qu'on
est d'accord, mais reste un truc, un quiproquo, va falloir laisser un
peu d'eau couler sous les ponts à ce sujet. J'ai testerai sur Quincay
(86), on verra à l'usage quelles solutions peuvent être apportées pour
satisfaire le plus grand nombre.

Donc veux tu bien qu'on regarde ensemble la procédure d'import
SEMI-auto des adresses ? Vous êtes tous invités, il y a pas mal à
déblayer.

A- Il faut des rues pour y attacher les panneaux d'adresses.

    Deux possibilités :
 1 - on ne monte que les adresses pour les voies nommées ;
 2 - on nomme la voie avec un nom particulier "Voie non nommée X"
plus fixme et on monte les adresses, c'est repérable et prêt pour celui
qui trouvera le nom.

B - Une ou des relations existent déjà pour la voie en base.

    1 - on écrase si plus d'adresses ;
    2 - on propose une fusion en complétant avec les n° manquants ;
    3 - on en ajoute une avec les n° manquants ;
    4 - on n'importe rien.

C - Faut-il proposer une importation par rue ? Je souhaite extraire les
éléments d'adresse de la rue "Rue du chêne" pour une importation. et/ou
une commune ?

D - Faut-il "tagguer" ces adresses avec un "tag" spécifique genre
"note=import-adr-auto " pour pouvoir les repérer par la suite ?

D - est qu'un logiciel d'import interactif spécifique  (qui visualise
et pose des questions spécifiques) serait mieux que de charger sous
JOSM ?

Benoît R.



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

Re: [OSM-talk-fr] [Tech] Extraction des adresses...





Pieren a écrit :

  2010/7/20 Benoît ROUSSEAU <adressepossi...@free.fr>
  

    J'aimerai bien que tu me dise ce qui est la "partie la plus utile"
parce que j'ai beau chercher je ne vois pas. Un exemple ?
    Je vais attaquer la finalisation alors autant ne pas passer à côté.


  
  
C'est le lien entre le node addr: et un polygone building qui peut
contenir des POI. De nombreux bâtiments abritent plusieurs activités
(restauration, commerce, services sociaux) et chacun est symbolisé par
un node. On ne place finalement l'information sur le polygone lui-même
que lorsque c'est l'ensemble du bâtiment qui est concerné (ou lorsque
c'est l'activité principale comme un hôtel avec juste un node pour le
restaurant par exemple). 
Pour les applications qui n'utilisent qu'une adresse, il n'y a pas de
problèmes (navigation). Pour celles qui, par exemple, voudraient
dresser la liste des pharmacies d'une ville avec leur addresse, il faut
pouvoir retrouver ce lien.
  
  
  
Pieren
  


Donc l'idée serai, par exemple, de pouvoir monter un annuaire en
plaçant directement les adresses directement en tant que noeud sur les
bâtiments quand ils existent.

En automatique, je réponds non une nième fois. La qualité n'étant pas
assurée, ni si je le fais, ni si c'est fait après.
Je prends l'exemple d'un centre commercial de Poitiers, l'îlot des
Cordeliers. Il occupe un paté de maisons et ouvre avec des adresses sur
trois rues. Il inclut un parking souterrain, des magasins en galerie,
des magasins en "façade" et des logements privé. Les bâtiments en
façade ont une adresse et ne sont pas accessible depuis les autres. Les
appartements ont une ou deux adresses, le parking, une adresse pour
l'entrée sortie, et les magasins de la galerie sont accessibles
quelques adresses. Associer tout ce petit monde au bâtiment est exacte,
associer tous ces commerces et résidences à toutes les adresses est
faux, choisir pour chacun l'adresse la plus proche est faux aussi.

Créer des relations entre les différents services et les adresses
serait par contre une possibilité. Ou alors, éventuellement, rapprocher
les POI services de leur adresse préférentielle pour qu'un calcul de
proximité puisse être fait. Auquel cas le calcul peut tout aussi bien
être fait en direct.

Dans le même ordre d'idée, trouves-tu alors normal d'avoir à calculer
l'inclusion en temps réel de POI services (beaucoup plus couteux en
temps) où places-tu les POI sur le way des bâtiments y compris pour
ceux inclus (restaurant dans ton exemple).

Benoît R.



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

Re: [OSM-talk-fr] extraction des lignes HT





hamster a écrit :

  
  
sous terre ?
en fait je parlais d'une ligne aerienne, avec des grands poteaux qu'on
voit bien de loin et des cables qui font b quand y'a du
brouillard
:p le pointillé ma trompé.

  






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

Re: [OSM-talk-fr] Présentation





sacha bogdanov a écrit :

  
  
  Bonjour, 
   
  Je suis nouvel inscrit sur cette liste 
Je connais le projet depuis quelques temps car je travaille avec un
serial mappeur (Marc Sibert).
Je vis en Seine et Marne mais suis originaire de Guadeloupe pour qui la
carte a été initiée et qu'à l'occasion de prochaines vacances, je
compte compléter.
  A bientôt à tous.
   
   
  

Bienvenue,
    Avec un parrain pareil, on présage du meilleur.  :p
Benoît R.



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

Re: [OSM-talk-fr] Alerte ! Les doublons, ça grossi t sans arrêt - Était :Bâtiments se superposant





V a écrit :

  Le 19 juillet 2010 11:52, Pieren  a écrit :
  
  
Sur le script, je suis d'accord qu'il faut d'avantage mettre en avant ces
problèmes. Personne ne semble vouloir faire l'effort d'en corriger les
défauts, en particulier son auteur original.

  
  
Selon moi, le script n'a pas de défaut, dans le sens où il remplit
parfaitement son rôle qui est de prendre les données vectoriels bruts
du cadastre et d'en faire un fichier osm qui peut ensuite être
retraité comme bon semble à son usager. Après s'il s'avère que les
données en double sont créées par le script j'essaierai de corriger ce
bug mais il me semble que les doublons sont déjà dans le pdf (sur les
rares exemples que j'ai pu voir). Après, le code est sur le svn, donc
il est finalement assez facile de proposer un patch :-),

  
  
'V', si tu nous lis, est-ce que tu cherches à corriger ces problèmes de
dublons dans le script ?

  
  
Pas du tout, j'ai vu des cas tellement tordus (encore une fois
surement pour privilégier le rendu) sur les quelques villages où j'ai
pu chercher à importer le bâti, que je ne me risquerai pas à essayer
d'automatiser cela. Je pense qu'il risque d'être difficile d'enlever
le "semi" de "semi-automatique" et qu'il serait préférable d'améliorer
par exemple le validator de josm (certains ont parlé de la méthode
utilisée pour CLC qui si j'ai bien compris calcule l'aire d'overlap
entre deux polygones, je n'ai pas trouvé de code mais peut être cela
peut il s'adapter pour améliorer le validator). Même les auteurs du
validator ne font pas d'effort pour corriger les erreurs des
utilisateurs. _o_

___
  

Juste concernant le Cadastre on voit dans les données pour tracer
nombre de quadrilatères type parcelles, des séquences comme : pt1 >
pt2 > pt2 > pt1 > pt2 > pt3 > pt4 > pt1. Ca explique
peut-être des duplications de points sur les bâtiments et d'autres
choses.
Tout ce qui sort du Cadastre sera SEMI-automatique et demandera un
effort d'interprétation, qui plus est, conformément à notre engagement
de ne pas pomper sans retravailler.
Tout ça se transforme petit à petit en avantages, la nature à horreur
du vide.
Benoît R.



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

Re: [OSM-talk-fr] extraction des lignes HT





jul...@krilin.org a écrit :

  
Moi j'"imprime" la zone concernée sur le site du cadastre pour ne pas
avoir un énorme pdf comme cela peut l'être sur tout un village, je la
passe ensuite au pdf2svg et j'utilise l'éditeur xml d'inkscape pour
identifier rapidement les attributs correspondant à ce que j'ai
selectionné sur le dessin.

  
  
Après reste a savoir si le cadastre est une "bonne" source pour les lignes
a Haute Tension. Des taxes sont payées lié a l'implantation des pylones ?

  
  


Où c'est une obligation légale lié à la santé publique ou autre que
d'être informer quand tu achète un terrain qu'il est bâti sur une ligne
à haute tension.
Où un pb d'organisation des travaux pour la ville.
De toutes manières je ne pense pas que les agents de la DGI soient
aller vérifier sous terre. La source doit être un import de données
avec pour source ERDF.
Benoît R.



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

Re: [OSM-talk-fr] extraction des lignes HT

V a écrit :

Le 20 juillet 2010 06:10, Benoît ROUSSEAU a écrit :

Pour extraire quelque chose des SVG du Cadastre, si on ne peux s'appuyer sur
la couleur, il faut en connaître une particularité, comme par exemple
l'attribut "style" du "path".

Dans le SVG tu as des balises type . Si tu me donnes le
style correspondant je te fais l'extraction. Dans ton cas il est
probablement vraiment spécifique.

L'attribut est 'style="fill:none;stroke-width:1.18;stroke-linecap:butt;stroke-linejoin:miter;stroke:rgb(0%,0%,0%);stroke-opacity:1;stroke-miterlimit:4;"'

Cool !

mais chaque motif est sur un path séparé.

Challenge !
Pourrais t'on me joindre un petit svg par retour en privé (hors liste)
? Pour essayer.

Pour ma part, pour trouver j'y vais à tâtons en supprimant des tags du SVG
progressivement.

Moi j'"imprime" la zone concernée sur le site du cadastre pour ne pas
avoir un énorme pdf comme cela peut l'être sur tout un village, je la
passe ensuite au pdf2svg et j'utilise l'éditeur xml d'inkscape pour
identifier rapidement les attributs correspondant à ce que j'ai
selectionné sur le dessin.

Je fais pareil pour les petits SVG :p. Mais j'ai eu des diff entre
impression interactive depuis le Cadastre et les exports SVG de ton
script. Ais-je rêvé ? Était-ce lié au changement de projection dans mon
coin ? Je vais réessayer.

Benoît R.

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

Re: [OSM-talk-fr] [Tech] Extraction des adresses...





Pieren a écrit :

[...]

  
  C'est justement ma crainte. C'est de faire faire la partie la
plus utile mais la plus difficile par d'autres, plus tard. Il vaut
mieux placer l'adresse au meilleur endroit au moment de sa création que
d'espérer que chaque application ira spéculer sans trop se planter dans
les relations entre adresses et autres POIs. Mais j'ai bien conscience
que c'est un vrai challenge au niveau logiciel.
  
Pieren
  
  
  

Bonjour,

    J'aimerai bien que tu me dise ce qui est la "partie la plus utile"
parce que j'ai beau chercher je ne vois pas. Un exemple ?
    Je vais attaquer la finalisation alors autant ne pas passer à côté.

Benoît R.



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

Re: [OSM-talk-fr] extraction des lignes HT





hamster a écrit :
hamster
a écrit :
  
  dans le cadastre je suis tombe sur un trait
pointille avec 2 traits une fleche, 2 traits une fleche (voir piece
jointe)


sur le terrain ca correspont a une ligne a haute tension


peut etre quelqu'un qui sait pourrait coder ce qui va bien pour les
extraire automatiquement ?


___

Talk-fr mailing list

Talk-fr@openstreetmap.org

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

  

Bonjour Hamster,

Pour extraire quelque chose des SVG du Cadastre, si on ne peux
s'appuyer sur la couleur, il faut en connaître une particularité, comme
par exemple l'attribut "style" du "path".

Dans le SVG tu as des balises type . Si tu
me donnes le style correspondant je te fais l'extraction. Dans ton cas
il est probablement vraiment spécifique.

Pour ma part, pour trouver j'y vais à tâtons en supprimant des tags du
SVG progressivement.

Benoît R.



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

Re: [OSM-talk-fr] [Tech] Extraction des adresses...





Pieren a écrit :

  2010/7/19 Benoît ROUSSEAU <adressepossi...@free.fr>
  


  Ta proposition est assez délicate à mettre en
place vu que
l'outil d'extraction du pdf ne distingue pas les limites parcellaires.
Et il y a de nombreux endroits où les sont dessinés entre le milieu de
la route et la parcelle.
  
Pieren
  
  

Les quoi entre le milieu de la route et la parcelle ? 

  
  
Oups, les "trottoirs". Pardon. 
  
  


En ce qui concerne le chargement des limites parcellaires actuellement
ça donne ça : (voir image à la suite). Donc on peux faire le distingo
avec ce qu'on a... 

Le filtrage élimine les ponts, les traits de renvoi des n° aux
parcelles, les terre-pleins et certains trottoirs (peut-être en reste
t'il selon comment ils sont saisis). Ceci, dans la version que j'ai
d'un SVG. Reste que c'est le bazar par endroits. C'est à se demander si
la vectorisation n'est pas faite pour le rendu qui serait obtenu par
superposition de couches (dans le même calques). Ca reste une hypothèse
à vérifier...

Donc pour le calage des adresses en limite de parcelles, c'est
possible. Est-ce que ça générera plus d'erreurs de positionnement des
adresses ? Mystère ! Disons que le Cadastre est parfois surprenant :
des maisons en parcelles, des raccords approximatifs, ... On ne va pas
s'en plaindre il n'est pas destiné à l'usage que nous en faisons.

On peux aussi envisager, de plus en plus, l'extraction d'autres
éléments comme les cimetières, ... car les calques sont présents dans
les svg sous forme de groupes (si ça donne des idées à d'autres).
Auquel cas, limiter la reconnaissance des symboles sur une couche
particulière est plus aisé et l'on doit pouvoir par la suite retrouver
la/les parcelle/s (pour les cimetières, ...) ou les bâtiments (églises,
...) liés en superposition.

Benoît R.




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

Re: [OSM-talk-fr] Motivations des contributeurs d'OSM





Arnaud Vandecasteele a écrit :

  Bonjour a tous,
  Il me semble avoir vu passer un document listant les motivations
des contributeurs d'OSM. Ce document a été publié lors du SOTM2010.
Cela vous rappelle-t-il quelque chose ?
  De plus toujours à ce sujet, je m'interroge sur les motivations
premières qui nous ont poussés à participer à OSM et à surtout à
continuer . Je ne parle pas des motivations d'aujourd'hui maintenant
que vous êtes des habitués, mais de celles du tout début quand vous
saviez à peine a quoi correspondait l'acronyme OSM :)
  
  Me basant sur mon expérience personnelle, j'en ai listé
quelques-unes :
  * la liberté de création
* l'importante communauté 
* côté fun 
* le fait de pouvoir se tromper
* la sensation s'explorer de nouveaux territoires 
* le fait de pouvoir s'impliquer progressivement
* participer a un projet libre
  avez vous d'autres facteurs qui vous ont incité à contribuer et
surtout qui vous a donné envie de continuer?
  Arnaud
  


- disposer de cartes libres pour différents projets.
- libérer des données publiques (va falloir que j'avance d'ailleurs)
car il est très difficile d'obtenir certaines données pourtant
théoriquement "publiques" ou de pouvoir les exploiter.
- intérêt pour le monde (si petit).
- se côté défi, si on s'y met tous on peux.

Puis, je n'ai non pas re découvert, mais, découvert mon environnement
proche, celui de mon enfance, ... Un grande surprise de voir que je ne
le connaissais pas ! Et pourtant...

Benît R.



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

Re: [OSM-talk-fr] Alerte ! Les doublons, ça grossi t sans arrêt - Était :Bâtiments se superposant





Pierre-Alain Dorange a écrit :

  
  Le 19 juil. 10 à 17:57, Pieren a écrit :
  
  Je
viens d'envoyer un message à 'square' pour lui dire d'employer une
méthode plus carrée.
  
  
  
J'ai aussi contacté Square cet après-midi et effectivement il c'était
aperçu depuis hier qu'il y avait un problème et a déjà commencé à y
travailler, tout en s'excusant.
  Il chercher éventuellement un moyen de rattraper les erreurs
rapidement...
  
   
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  -- 
  Pierre-Alain
Dorange, 
  Blog Citoyen de Cognac : 
  
  
  
  
  
  
  
  Twitter : 
- Facebook : 
  
  
  
  
  
  
  
   
  
  
  


Juste un avis, le traitement sera plus rapide en automatique même si
Marc fait pour l'instant à la main. Je vais voir avec lui pour modifier
mon logiciel afin qu'il ai moins de traitements manuels et l'aider pour
aller plus vite.

Le plus important c'est surtout de ne plus générer de doublons, n'en
j'tez plus.

Benoît R.



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

Re: [OSM-talk-fr] [Tech] Extraction des adresses...





Pieren a écrit :

  2010/7/19 Benoît ROUSSEAU <adressepossi...@free.fr>
  


  Ta proposition est assez délicate à mettre en
place vu que
l'outil d'extraction du pdf ne distingue pas les limites parcellaires.
Et il y a de nombreux endroits où les sont dessinés entre le milieu de
la route et la parcelle.
  
Pieren
  
  

Les quoi entre le milieu de la route et la parcelle ? 

  
  
Oups, les "trottoirs". Pardon. 
  
  


Je vais voir ce que ça donne, sur une ville. Comme je dois distinguer
les n° de parcelles, on pourrait imaginer de trouver le polygone
parcelle autour. ... C'est une hypothèse, une piste, pas un engagement,
car les petites parcelles ont leur numéro déplacé au bout d'un trait..
Benoît R.



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

Re: [OSM-talk-fr] [Tech] Extraction des adresses...





Pieren a écrit :
Ta proposition est assez délicate à mettre en place vu que
l'outil d'extraction du pdf ne distingue pas les limites parcellaires.
Et il y a de nombreux endroits où les sont dessinés entre le milieu de
la route et la parcelle.
  
Pieren
  


Les quoi entre le milieu de la route et la parcelle ? 
Benoît R.




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

Re: [OSM-talk-fr] [Tech] Extraction des adresses...





Pieren a écrit :

  2010/7/19 Benoît ROUSSEAU <adressepossi...@free.fr>
  
    En zone urbaine, à mon
avis, pas encore testé, bosser avec ton ton
plug va plus vite. Les adresses sont proches, ça va vite. Comme déjà
évoqué, à mon avis ce sera plus utile en campagne.

  
  
C'est risqué parce que ton outil sera utilisé pour tous les cas de
figure une fois disponible. Et on le voit en ce moment avec les
doublons ou avec d'autres outils, certains attachent plus d'importance
à la quantité qu'à la qualité.
  
  

Arrête, j'en tremble déjà. Bon j'ai peut-être des solutions mais c'est
à tester.

  
  
 
  
    La règle des BALs c'est
terminé en campagne les BALs persos au
portail sont remplacées par des totems en "milieu" d'îlot.

  
  
Ca dépend de l'ancienneté du bâti.
  
  

Pas chez nous.

  
   
  
        Tous ce que tu
évoques comme relation d'informations
supplémentaires à adresses peut se faire comme tu le dis, mais par la
suite. Attaquer l'api et calculer la façade la plus proche où dans la
visée ortho n'est ni complexe ni gourmand en calculs.


  
  
C'est justement ma crainte. C'est de faire faire la partie la plus
utile mais la plus difficile par d'autres, plus tard. Il vaut mieux
placer l'adresse au meilleur endroit au moment de sa création que
d'espérer que chaque application ira spéculer sans trop se planter dans
les relations entre adresses et autres POIs. Mais j'ai bien conscience
que c'est un vrai challenge au niveau logiciel.
  
  

Ca n'a rien de difficile, c'est déjà dans le logiciel et c'est de loin
le plus simple que j'ai eu à coder, c'est quelques lignes. Entre les
projections, les communications avec le cadastre et l'api, le parser
SVG, le reconnaissance des chiffres, ... Comme tu le dis au dessus, je
ne veux pas générer des erreurs en nombre automatiquement, j'aimerai
rester dans l'acceptable. Et dans ce cas, à moins de m'expliquer une
méthode pour assurer un nombre tolérable d'erreur, pour ma part je ne
m'engage pas là dessus. Mais rien n'empêche par la suite d'associer
automatiquement les adresses aux bâti les plus proches, ca n'a rien de
difficile même à l'échelle de la France car c'est finalement très peu
de points. Je donnerai tous les éléments si qqun souhaite le faire.

        double Distance(ref PointD pt1seg, ref PointD pt2seg)
    {
    double ampx = pt2seg.X - pt1seg.X;
    double ampy = pt2seg.Y - pt1seg.Y;
    return Math.Sqrt((ampx * ampx) + (ampy * ampy));
    }

    PointD IntersectionOrthoPointSegment(PointD ptadr, PointD
ptseg1, PointD ptseg2)
    {
    PointD ptintersec = new PointD(Double.NaN, Double.NaN);
    
    double longueur = Distance(ref ptseg1, ref ptseg2);
    double déterminant = (((ptadr.X - ptseg1.X) * (ptseg2.X -
ptseg1.X)) + ((ptadr.Y - ptseg1.Y) * (ptseg2.Y - ptseg1.Y))) /
(longueur * longueur);
    if (déterminant < 0.0 || déterminant > 1.0)
    return ptintersec;   // le point n'est pas dans le
segment

    ptintersec.X = ptseg1.X + déterminant * (ptseg2.X -
ptseg1.X);
    ptintersec.Y = ptseg1.Y + déterminant * (ptseg2.Y -
ptseg1.Y);
    
    return ptintersec;
    }

        IntersectionVoie VoieLaPlusProche(Adresse adresse,
double distancemax)
    {
    IntersectionVoie intersection = new IntersectionVoie();
    PointD ptcoords = new PointD(adresse.Lon, adresse.Lat);
    PointD pttmp = new PointD();

    double distancemin = double.MaxValue;
    double distance = double.MaxValue;

    foreach (VoieAdressable voie in g_Voies)
    {
    for (int i = 0; i < voie.Points.Count - 1; i++)
    {
    pttmp = IntersectionOrthoPointSegment(ptcoords,
voie.Points[i], voie.Points[i + 1]);

    if (Double.IsNaN(pttmp.X))
    continue;

    distance = Distance(ref ptcoords, ref pttmp);

    if (distance > distancemax)
    continue;

    if (distance > distancemin)
    continue;

    distancemin = distance;
    intersection.Point = pttmp;
    intersection.IdVoie = voie.IdWay;
    }
    }


  
  
Pieren
  
  
  

Benoît R.



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

Re: [OSM-talk-fr] [Tech] Extraction des adresses...





Pieren a écrit :

  2010/7/19 Benoît ROUSSEAU <adressepossi...@free.fr>
  


Beaucoup de parcelles ou de bâtiments sont loin de leur n° de voie
(allées privées, bât imbriqués, ...) ou proches d'une autre (toutes les
intersections, ..).  Les bâtiments sont parfois nombreux pour une
adresse. Faut-il tous les n°ter, faut-il risquer de n°ter la grange ? A
avoir bossé sur les adresses, j'ai changé d'avis sur les méthodes de
numérotation. J'ai essayé les deux systèmes de n°tation bât et plaques.
La signification première de ces numéros c'est un repérage lié à et
dans la rue. Donner un n° à un bâtiment à moins de sens et quand on
cherche un n° de rue on cherche à se positionner au sein de cette rue.
Et penser aux bâtiments à plusieurs adresses (aux croisements, ceux qui
donnent sur deux rues devant derrière, ...). Finalement les plaques de
n° sont les plus utiles et ce qui fait le plus sens, le n° est bien lié
à la rue.

Benoît R.


  
  
Je préfère le numéro sur un node attaché à la façade du bâtiment parce
que j'y trouve plusieurs avantages:
- on fait la différence entre le bâtiment principal et le garage ou la
grange
- on identifie la façade du bâti (si le cadastre respecte la règle de
placer le numéro sur les boîtes aux lettres, ce qui n'est pas toujours
le cas)
- on gère les numéros multiples sur un polygone sans problèmes ni
questions
- on lie par une méthode graphique (éditeur) plusieurs informations si
le polygone contient d'autre part des tags (amenity, shop, etc) sur le
way ou sur d'autres nodes/POI à l'intérieur.
  
Personnellement, je préfererais que l'outil cherche le mur
perpendiculaire à la route le plus proche (en face du numéro), ce qui
devrait assez souvent fonctionner, surtout en zone urbaine. Et s'il y a
un doute, de le faire à la main.
  
Pieren
  
  
  
  


Bonjour,

    En zone urbaine, à mon avis, pas encore testé, bosser avec ton ton
plug va plus vite. Les adresses sont proches, ça va vite. Comme déjà
évoqué, à mon avis ce sera plus utile en campagne.
    La règle des BALs c'est terminé en campagne les BALs persos au
portail sont remplacées par des totems en "milieu" d'îlot.
    
    Tous ce que tu évoques comme relation d'informations
supplémentaires à adresses peut se faire comme tu le dis, mais par la
suite. Attaquer l'api et calculer la façade la plus proche où dans la
visée ortho n'est ni complexe ni gourmand en calculs. Je préfèrerai que
l'erreur faite soit à ce moment là, plutôt qu'au placement du numéro.
Pour ma part, je m'interdit d'intervenir automatiquement sur la
structure des bâtiments en ajoutant un ou des points sur une façade.
Puis, en cas d'erreur, à grande échelle, en semi auto, woooh ! Par
contre, si certains veulent tenter la chose (en java multi-plateforme
par exemple), je vous donne tous les éléments pour.

    Ce que je vous propose d'essayer, Hamster, Mickey86 et Pierren,
C'est de positionner la plaque à "l'intersection orthogonale" du
segment le plus proche dans les x mètres. Si c'est une façade, si c'est
une limite parcellaire, un mur, ... Ca devrait convenir à tous le
monde. La plaque n'est pas éloignée de plus de x mètres de la voie et
si un élément est sur le trajet, il emporte le placement.

    

    Est-il légal et souhaitable (éthique) d'identifier un bâti
directement par son adresse ? Facilité accrue de croiser des
informations personnelles et d'en déduire des revenus en fonction de la
taille de la maison, ... Là je ne sais pas répondre ni où chercher des
infos. S'il y a des juristes...

Benoît R.


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

Re: [OSM-talk-fr] [Tech] Extraction des adresses...