Re: [OSM-talk-fr] Développement pour lien avec Open-Sankoré ?

[Frédéric Rodrigo]

Bonjour,

Ce que vous demandez est tout à fait réalisable.

Toutes fois pouvez clarifier votre souhait de travailler avec des
associations. L'écosystème du libre est soutenu par des associations
plutôt dans un cadre bénévole, mais aussi par des sociétés, des
indépendants... Je ne connais pas d'association dont la vocation est
de faire du portage salarial en logiciels libres. Théoriquement
l'association OpenStretMap-France pourrait le faire, mais j'ai bien
peur que pour l'instant elle n'ai pas les épaules assez largues.
Financer des développements en logiciels libres c'est déjà soutenir le libre.

Frédéric Rodrigo

Le 21 février 2012 13:03, François BOCQUET
 a écrit :
> Bonjour,
> Je fais partie du projet open-Sankoré et suis à votre disposition pour
> répondre aux questions.
> Nous souhaiterions effectivement pouvoir remplacer un composant
> utilisant Google Maps par un identique utilisant les données 
> d'Open-Street-Map.
> Dans l'idéal il serait également souhaitable que nous puissions disposer d'une
> version fonctionnant en mode non connecté (off line) car la plupart des
> utilisateurs en Afrique ne disposent pas de connexion internet.
> Nous souhaitons travailler avec des associations pour soutenir le mouvement
> associatif autour du logiciel libre.
> A disposition pour en discuter.

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

Re: [OSM-talk-fr] Développement pour lien avec Open-Sankoré ?

[Frédéric Rodrigo]

Bonjour,

Je vous ai déjà répondu en partie en public sur la liste d'OpenStreetMap.
Je voulais ajouter que je me lance actuellement comme indépendant pour
effectuer de la géomatique et des développements en logiciels libres,
principalement autours du sujet d'OpenStreetMap que je maîtrise le
plus.

N'hésitez pas à me contacter pour en discuter plus amplement. Je peux
vous fournir mon CV si vous le souhaitez.

Cordialement

-- 
Frédéric Rodrigo
Carte-Libre
Néogéographie, web mappeur indépendant
06 89 55 75 42
http://carte-libre.fr/ - frede...@carte-libre.fr

Le 21 février 2012 13:03, François BOCQUET
 a écrit :
> Bonjour,
> Je fais partie du projet open-Sankoré et suis à votre disposition pour
> répondre aux questions.
> Nous souhaiterions effectivement pouvoir remplacer un composant
> utilisant Google Maps par un identique utilisant les données 
> d'Open-Street-Map.
> Dans l'idéal il serait également souhaitable que nous puissions disposer d'une
> version fonctionnant en mode non connecté (off line) car la plupart des
> utilisateurs en Afrique ne disposent pas de connexion internet.
> Nous souhaitons travailler avec des associations pour soutenir le mouvement
> associatif autour du logiciel libre.
> A disposition pour en discuter.
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr

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

Re: [OSM-talk-fr] Une carte orientée biologie ? (arbres, insectes, oiseaux, plantes)

[Romain MEHUT]

Un autre exemple (sans OSM) pour les oiseaux:
http://www.faune-lorraine.org/index.php?m_id=505

Le 21 février 2012 23:24, Brice  a écrit :

> Bonsoir,
>
> Peut-être connaît il déjà mais il existe un site collaboratif pour les
> botanistes : http://www.tela-botanica.org
>
> avec possibilité de cartographier ses observations :
> http://www.tela-botanica.org/widget:cel:carto
> (fond google par défaut mais couche OSM disponible !)
>
>
> 
> Brice Mallet
>
> 
>
>
>
> Le 21 févr. 2012 à 19:41, Christian Quest a écrit :
>
> Question reçue sur le formulaire de contact d'openstreetmap.fr à
> laquelle j'ai bien du mal à répondre...
>
> "Bonjour,
>
> J'organise une sortie terrain avec des élèves et j'aurais souhaité savoir
> si il existe des sites internet avec des icônes et/ou données
> biologiques/scientifiques version nature?
>
> Plus précisément, peut-on indiquer quelle espèce d'arbre est présente à
> un endroit précis ou quelle espèce d'insecte vit dans tel ou tel parc ?
> Je connais CARTOCLIC mais j'aurai voulu intégrer plus que seulement des
> arbres comme par exemple des insectes, oiseaux, plantes ...
>
> Si ce n'est pas le cas chez OSM connaissez-vous ou avez-vous entendu parler
> de ce genre de site internet ?
>
> Merci beaucoup pour votre aide.
> Passez une excellente journée."
>
>
> --
> Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Une carte orientée biologie ? (arbres, insectes, oiseaux, plantes)

[Samy Mezani]

Bonjour,
En ce qui concerne la récolte collaborative de données naturalistes, 
autant dire que c'est encore la préhistoire par rapport aux outils 
techniques que l'on pourrait exploiter...
Romain nous montre un exemple de grosse base de données en ligne très à 
la mode en ce moment car utilisé par les grandes associations 
ornithologiques françaises (LPO), allemandes, suisses, etc. L'outil se 
nomme Visio-Nature, et développé par la société Biolovision. Très 
prometteur, il n'en est encore qu'à ses débuts et des fonctionnalités 
importantes manquent. Son coût est exhorbitant je trouve pour le 
déployer dans une association. En plus les cartes n'utilisent que les 
photos de Google Maps, ce n'est pas forcément très pratique...
Il existe aussi WNat, développé par la société SAXRUB Informatique. 
Beaucoup moins cher, peut-être moins bling-bling, mais surtout réservé à 
des utilisateurs enregistrés par les associations naturalistes. WNat 
s'appuie sur l'API Geoportail, avec deux couches : photos aériennes, 
cartes IGN.
D'autres organismes créent chacun de leur côté leur propre outil mais 
cela devient vite problématique quand il faut utiliser x sites Internet 
pour saisir ses données ornitho-, entomo-, mamma-, herpéto-, 
batraco-logiques...


Bref, personne n'utilise encore OSM dans ce monde là, et on est encore 
loin d'avoir des logiciels libres à disposition. Je rêve parfois d'une 
appli sur mon Freerunner qui me permettrait de saisir simplement des 
relevés naturalistes sur le terrain en utilisant son GPS et OSM... Mais 
bon je rêve là... Pourtant la science participative aurait à y gagner.


Samy


le 22/02/2012 13:47, Romain MEHUT a écrit:

Un autre exemple (sans OSM) pour les oiseaux:
http://www.faune-lorraine.org/index.php?m_id=505

Le 21 février 2012 23:24, Brice mailto:brice.mal...@free.fr>> a écrit :

Bonsoir,

Peut-être connaît il déjà mais il existe un site collaboratif pour
les botanistes : http://www.tela-botanica.org

avec possibilité de cartographier ses observations :
http://www.tela-botanica.org/widget:cel:carto
(fond google par défaut mais couche OSM disponible !)


Brice Mallet




Le 21 févr. 2012 à 19:41, Christian Quest a écrit :


Question reçue sur le formulaire de contact d'openstreetmap.fr
 à
laquelle j'ai bien du mal à répondre...

"Bonjour,

J'organise une sortie terrain avec des élèves et j'aurais souhaité
savoir
si il existe des sites internet avec des icônes et/ou données
biologiques/scientifiques version nature?

Plus précisément, peut-on indiquer quelle espèce d'arbre est
présente à
un endroit précis ou quelle espèce d'insecte vit dans tel ou tel
parc ?
Je connais CARTOCLIC mais j'aurai voulu intégrer plus que
seulement des
arbres comme par exemple des insectes, oiseaux, plantes ...

Si ce n'est pas le cas chez OSM connaissez-vous ou avez-vous
entendu parler
de ce genre de site internet ?

Merci beaucoup pour votre aide.
Passez une excellente journée."


--
Christian Quest - OpenStreetMap France -
http://openstreetmap.fr/u/cquest

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



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




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


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

[OSM-talk-fr] téléchargement d'une zone trop grande

[sukran . geo sukran . geo]

Bonjour,   J'ai une zone dans OSM que je veux télécharger, mais... apparemment, 
elle est trop grande, et voici le message qui s'affiche. (voir JPEG Joint) J'ai 
ensuite téléchargé le fichier de Geofabrik, mais idem, pb de taille. Que faire 
? Il me faut toute la zone, et je ne veux pas pas faire plein de petits 
morceaux.

Cordialement.


let's be pleased with the environment <>___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] téléchargement d'une zone trop grande

[sly (sylvain letuffe)]

On mercredi 22 février 2012, sukran.geo sukran.geo wrote:
> 
> Bonjour,   J'ai une zone dans OSM que je veux télécharger, mais...
> apparemment, elle est trop grande, et voici le message qui s'affiche. (voir
> JPEG Joint) J'ai ensuite téléchargé le fichier de Geofabrik, mais idem, pb
> de taille. Que faire ? Il me faut toute la zone, et je ne veux pas pas faire
> plein de petits morceaux.

Elle est grosse comment ta zone ?

Parce que si tu veux ouvrir un département complet dans JOSM, il vaut mieux 
oublier tout de suite et faire autrement ;-)

Si c'est raisonnablement petit, mais que l'api officielle te bloque, dans JOSM 
tu peux tenter de remplacer api.openstreetmap.org par api.openstreetmap.fr 
les limites en téléchargement son plus élevées


-- 
sly
qui suis-je : http://sly.letuffe.org
email perso : sylvain chez letuffe un point org

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

Re: [OSM-talk-fr] téléchargement d'une zone trop grande

[Philippe Verdy]

C'est pourtant la seule chose que tu puisses faire: charger par petits
morceaux. Tout en sacahnt que cela prendra du temps.

En général pour les grandes zones, ce n'est pas la totalité des
données de cette zone qu'on charge, mais on procède par chargement
plus sélectif en chargent les éléments incomplets, en commençant par
charger des micro-zones autour des points d'intersection.

Tu verras facilement qu'au bout d'un moment ton fichier JOSM grossit
de façon conséquente. Mais le serveur ne peut pas répondre à une
requête qui demanderait juste pour toi de préparer un jeu de résultats
de plusieurs millions de points (il a déjà bien du mal avec quelques
milliers).

Donc à toi de gérer ton cache local de données, sans non plus demander
à le remettre à jour dans sa totalité, mais en mettant seulement à
jour les seules relations que tu t'apprêtes à modifier, pour t'éviter
des conflits ultérieurs lors de l'enregistrement (car les conflits
sont bien plus compliqués à résoudre et leur résolution est source de
nombreuses erreurs ou ambiguïtés, même dans JOSM qui ne permet
toujours pas de faire facilement les comparaisons en chargeant les
versions en confits dans de *vrais* calques séparés, et non dans de
simples listes où l'on ne peut comparer correctement que les attributs
mais pas les géométries qui sont pourtant les briques de base
essentielles de la base OSM).

Le 22 février 2012 15:44, sukran.geo sukran.geo  a écrit :
>
> Bonjour,
>
>
>
> J'ai une zone dans OSM que je veux télécharger, mais... apparemment, elle
> est trop grande, et voici le message qui s'affiche. (voir JPEG Joint) J'ai
> ensuite téléchargé le fichier de Geofabrik, mais idem, pb de taille.
>
> Que faire ? Il me faut toute la zone, et je ne veux pas pas faire plein de
> petits morceaux.
>
> Cordialement.
>
>
>
> let's be pleased with the environment
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>

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

Re: [OSM-talk-fr] Une carte orientée biologie ? (arbres, insectes, oiseaux, plantes)

[Florian LAINEZ]

just do it :p

Le 22 février 2012 14:20, Samy Mezani  a écrit :

> Bonjour,
> En ce qui concerne la récolte collaborative de données naturalistes,
> autant dire que c'est encore la préhistoire par rapport aux outils
> techniques que l'on pourrait exploiter...
> Romain nous montre un exemple de grosse base de données en ligne très à la
> mode en ce moment car utilisé par les grandes associations ornithologiques
> françaises (LPO), allemandes, suisses, etc. L'outil se nomme Visio-Nature,
> et développé par la société Biolovision. Très prometteur, il n'en est
> encore qu'à ses débuts et des fonctionnalités importantes manquent. Son
> coût est exhorbitant je trouve pour le déployer dans une association. En
> plus les cartes n'utilisent que les photos de Google Maps, ce n'est pas
> forcément très pratique...
> Il existe aussi WNat, développé par la société SAXRUB Informatique.
> Beaucoup moins cher, peut-être moins bling-bling, mais surtout réservé à
> des utilisateurs enregistrés par les associations naturalistes. WNat
> s'appuie sur l'API Geoportail, avec deux couches : photos aériennes, cartes
> IGN.
> D'autres organismes créent chacun de leur côté leur propre outil mais cela
> devient vite problématique quand il faut utiliser x sites Internet pour
> saisir ses données ornitho-, entomo-, mamma-, herpéto-, batraco-logiques...
>
> Bref, personne n'utilise encore OSM dans ce monde là, et on est encore
> loin d'avoir des logiciels libres à disposition. Je rêve parfois d'une
> appli sur mon Freerunner qui me permettrait de saisir simplement des
> relevés naturalistes sur le terrain en utilisant son GPS et OSM... Mais bon
> je rêve là... Pourtant la science participative aurait à y gagner.
>
> Samy
>
>
> le 22/02/2012 13:47, Romain MEHUT a écrit:
>
>> Un autre exemple (sans OSM) pour les oiseaux:
>> http://www.faune-lorraine.org/**index.php?m_id=505
>>
>> Le 21 février 2012 23:24, Brice > > a écrit :
>>
>>
>>Bonsoir,
>>
>>Peut-être connaît il déjà mais il existe un site collaboratif pour
>>les botanistes : http://www.tela-botanica.org
>>
>>avec possibilité de cartographier ses observations :
>>
>> http://www.tela-botanica.org/**widget:cel:carto
>>(fond google par défaut mais couche OSM disponible !)
>>
>>--**--**
>> 
>>Brice Mallet
>>--**--**
>> 
>>
>>
>>
>>Le 21 févr. 2012 à 19:41, Christian Quest a écrit :
>>
>> Question reçue sur le formulaire de contact d'openstreetmap.fr
>>> à
>>>
>>>laquelle j'ai bien du mal à répondre...
>>>
>>>"Bonjour,
>>>
>>>J'organise une sortie terrain avec des élèves et j'aurais souhaité
>>>savoir
>>>si il existe des sites internet avec des icônes et/ou données
>>>biologiques/scientifiques version nature?
>>>
>>>Plus précisément, peut-on indiquer quelle espèce d'arbre est
>>>présente à
>>>un endroit précis ou quelle espèce d'insecte vit dans tel ou tel
>>>parc ?
>>>Je connais CARTOCLIC mais j'aurai voulu intégrer plus que
>>>seulement des
>>>arbres comme par exemple des insectes, oiseaux, plantes ...
>>>
>>>Si ce n'est pas le cas chez OSM connaissez-vous ou avez-vous
>>>entendu parler
>>>de ce genre de site internet ?
>>>
>>>Merci beaucoup pour votre aide.
>>>Passez une excellente journée."
>>>
>>>
>>>--
>>>Christian Quest - OpenStreetMap France -
>>>http://openstreetmap.fr/u/**cquest 
>>>
>>>__**_
>>>Talk-fr mailing list
>>>Talk-fr@openstreetmap.org 
>>> >> >
>>>
>>> http://lists.openstreetmap.**org/listinfo/talk-fr
>>>
>>
>>
>>__**_
>>Talk-fr mailing list
>>Talk-fr@openstreetmap.org 
>> > >
>>
>>
>> http://lists.openstreetmap.**org/listinfo/talk-fr
>>
>>
>>
>>
>> __**_
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> http://lists.openstreetmap.**org/listinfo/talk-fr
>>
>
> __**_
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.**org/listinfo/talk-fr
>



-- 

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

Re: [OSM-talk-fr] téléchargement d'une zone trop grande

[Tristram Gräbener]

Tu peux utiliser un export geofabrik puis utiliser osmose pour
découper la zone que tu veux

2012/2/22 Philippe Verdy :
> C'est pourtant la seule chose que tu puisses faire: charger par petits
> morceaux. Tout en sacahnt que cela prendra du temps.
>
> En général pour les grandes zones, ce n'est pas la totalité des
> données de cette zone qu'on charge, mais on procède par chargement
> plus sélectif en chargent les éléments incomplets, en commençant par
> charger des micro-zones autour des points d'intersection.
>
> Tu verras facilement qu'au bout d'un moment ton fichier JOSM grossit
> de façon conséquente. Mais le serveur ne peut pas répondre à une
> requête qui demanderait juste pour toi de préparer un jeu de résultats
> de plusieurs millions de points (il a déjà bien du mal avec quelques
> milliers).
>
> Donc à toi de gérer ton cache local de données, sans non plus demander
> à le remettre à jour dans sa totalité, mais en mettant seulement à
> jour les seules relations que tu t'apprêtes à modifier, pour t'éviter
> des conflits ultérieurs lors de l'enregistrement (car les conflits
> sont bien plus compliqués à résoudre et leur résolution est source de
> nombreuses erreurs ou ambiguïtés, même dans JOSM qui ne permet
> toujours pas de faire facilement les comparaisons en chargeant les
> versions en confits dans de *vrais* calques séparés, et non dans de
> simples listes où l'on ne peut comparer correctement que les attributs
> mais pas les géométries qui sont pourtant les briques de base
> essentielles de la base OSM).
>
> Le 22 février 2012 15:44, sukran.geo sukran.geo  a écrit :
>>
>> Bonjour,
>>
>>
>>
>> J'ai une zone dans OSM que je veux télécharger, mais... apparemment, elle
>> est trop grande, et voici le message qui s'affiche. (voir JPEG Joint) J'ai
>> ensuite téléchargé le fichier de Geofabrik, mais idem, pb de taille.
>>
>> Que faire ? Il me faut toute la zone, et je ne veux pas pas faire plein de
>> petits morceaux.
>>
>> Cordialement.
>>
>>
>>
>> let's be pleased with the environment
>>
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/talk-fr
>>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr

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

Re: [OSM-talk-fr] téléchargement d'une zone trop grande

[Etienne Trimaille]

Comme le signale Sly, il faut que tu nous en dise plus sur ton but :

- quelle est la taille de ta zone ? (région, département, communauté de
commune) Il n'y pas que la solution du téléchargement par petit paquet ;-)
- pour en faire quoi ? Pour éditer sous JOSM ou autre ? (Oublie si tu veux
charger directement un fichier Geofabrik dans JOSM, il va cruellement
lagger)

Le 22 février 2012 15:44, sukran.geo sukran.geo  a
écrit :

>
> Bonjour,
>
>
>
> J'ai une zone dans OSM que je veux télécharger, mais... apparemment, elle
> est trop grande, et voici le message qui s'affiche. (voir JPEG Joint) J'ai
> ensuite téléchargé le fichier de Geofabrik, mais idem, pb de taille.
>
> Que faire ? Il me faut toute la zone, et je ne veux pas pas faire plein de
> petits morceaux.
>
> Cordialement.
>
>
>
> *let's be pleased with the environment*
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] téléchargement d'une zone trop grande

[Philippe Verdy]

Le 22 février 2012 15:49, sly (sylvain letuffe)  a écrit :
> On mercredi 22 février 2012, sukran.geo sukran.geo wrote:
>> Bonjour,   J'ai une zone dans OSM que je veux télécharger, mais...
>> apparemment, elle est trop grande, et voici le message qui s'affiche. (voir
>> JPEG Joint) J'ai ensuite téléchargé le fichier de Geofabrik, mais idem, pb
>> de taille. Que faire ? Il me faut toute la zone, et je ne veux pas pas faire
>> plein de petits morceaux.
>
> Elle est grosse comment ta zone ?
> Parce que si tu veux ouvrir un département complet dans JOSM, il vaut mieux
> oublier tout de suite et faire autrement ;-)
> Si c'est raisonnablement petit, mais que l'api officielle te bloque, dans JOSM
> tu peux tenter de remplacer api.openstreetmap.org par api.openstreetmap.fr
> les limites en téléchargement son plus élevées

Mais c'est vrai aussi qu'il manque à la base OSM un vrai système de
réplication sur des miroirs synchronisés, capables de répondre de
concert à une même requête.

Quelques idées suivent...

Une sorte de RSYNC mais adapté aux bases de données (et non à un
système de fichiers hiérarchique), par lequel toute modification
enregistrée dans la base principale permet d'alimenter un flux de
redistribution des transactions "committées" vers un ensemble de bases
miroirs. De tels systèmes de réplication sont dans tous les RDMBS
commerciaux, mais pas toujours dans les RDBMS libres où ce sont
souvent des greffons mal intégrés ne garantissant pas la
synchrinisation de l'ensemble et la cohérence relationelle des
transactions annulées par un "rollback".

Cela nécessite des systèmes réellement transactionnels pour valider
l'état réel des modifications confirmées sur une base centrale, mais
aussi un système de "rattrapage" permettant même de resynchroniser une
base esclave qui aurait perdu à un moment donné le fil et devrait se
remettre à jour (par exemple en cas d'arrêt momentané pour une
maintenance, ou à cause d'un problème réseau temporaire, ou simplement
pour démarrer une nouvelle base esclave au départ vierge, avec une
synchronisation qui va progressivement charger les donnés manquantes).

Enfin si une telle réplication était réellement opérationnelle et
assez rapide pour qu'un ensemble de bases miroirs puissent toutes
répondre à une demande de chargement de données (je ne parle pas des
requêtes de modification de ces données), une déclaration de ces bases
miroirs opérationnelle pourrait avoir lieu dans le système DNS afin
que ces requêtes soient distribuées au hasard sur n'importe laquelle
de ces bases et pas forcément la base centrale qui est bien plus utile
et seulement nécessaire pour valider les transactions de modification.

Cela imposerait d'avoir deux adresses (URL) de bases de données dans
les éditeurs : une pour les chargements et mises à jour, l'autre pour
les modifications, sachant que ce n'est qu'au moment où on va valider
les données (dans un système de « validation en deux phases ») que la
première chose qui sera faite sera de comparer les versions provenant
des miroirs et celles actuellement dans la base, afin qu'à ce seul
moment-là le serveur central puisse fournir une URL vers les données à
jour dans un des miroirs disponibles sur lequel le serveur central
pourrait poser un verrou temporaire sur les objets correspondants,
pour la validation en deux phases, jusqu'à ce que soit la transaction
soit validée par un "commit" soit annulée par un "rollback", soit que
cette annulation ait lieu automatiquement après un délai raisonnable,
le client devant alors refaire ses transactions et étant prévenu que
sa dernière transaction a été annulée).

Bote: les transations sont autre chose que les groupes de
modifications qui sont des regroupements logiques effectués
utilisateur par utilisateur (selon leur propre logique et leur
déploiement car un même utilisateur peut utiliser simultanément
plusieurs outils et donc avoir plusieurs groupes de modification
ouverts. Ces groupes sont ouverts pour une durée relativement longue
(la fermeture automatique n'a lieu qu'au bout de deux heures
d'inactivité sur ce groupe, en théorie du moins car j'ai déjà vu le
serveur fermer prématurément un groupe en moins de 5 minutes, et même
parfois au beau milieu d'un enregistrement, les autres modifications
non envoyées étant alors rejetées mais devant être enregistrées dans
un autre groupe).

Pour moi la fermeture automatique des groupes n'est pas nécessaire,
sauf pour leur attacher quelques attributs en commun. Notamment le
suivi des attributs indiquant quel est logiciel utilisé, qui l'a créé,
quand il a commencé et quand *l'utilisateur* a indiqué qu'il avait
terminé, et finalisé son commentaire.

Le commentaire ne devrait être finalisé que si *toutes* les modifs ont
pu être envoyées. En cas de conflit d'édition, un groupe de modifs
peut rester ouvert relativement longtemps, le temps pour l'utilisateur
de régler ces conflits avant de soumettre les autres données, dont bon
nombre d'ailleurs ne sont pas en conflit.

Mais le ser

Re: [OSM-talk-fr] téléchargement d'une zone trop grande - Mirroirs de la base OSM

[sly (sylvain letuffe)]

On mercredi 22 février 2012, Philippe Verdy wrote:
> Mais c'est vrai aussi qu'il manque à la base OSM un vrai système de
> réplication sur des miroirs synchronisés, capables de répondre de
> concert à une même requête.
> 
> Quelques idées suivent...
(...)
TL;DR
yaka
http://lists.openstreetmap.org/pipermail/dev/2011-December/023976.html
FDIY

ps: Zut je m'étais promis de ne pas craquer, au moins la moyenne de nos deux 
messages atteignent presque une taille raisonnable.

-- 
sly
qui suis-je : http://sly.letuffe.org
email perso : sylvain chez letuffe un point org

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

Re: [OSM-talk-fr] téléchargement d'une zone trop grande - Mirroirs de la base OSM

[Emilie Laffray]

Hello,

Je peux en partie repondre pourquoi il n'y a pas encore replication
postgresql en streaming: Postgresql merde quand il y a des tables
temporaires. C'est un bug connu qu'on espere voir corrige dans 9.2.

Emilie Laffray

2012/2/22 sly (sylvain letuffe) 

> On mercredi 22 février 2012, Philippe Verdy wrote:
> > Mais c'est vrai aussi qu'il manque à la base OSM un vrai système de
> > réplication sur des miroirs synchronisés, capables de répondre de
> > concert à une même requête.
> >
> > Quelques idées suivent...
> (...)
> TL;DR
> yaka
> http://lists.openstreetmap.org/pipermail/dev/2011-December/023976.html
> FDIY
>
> ps: Zut je m'étais promis de ne pas craquer, au moins la moyenne de nos
> deux
> messages atteignent presque une taille raisonnable.
>
> --
> sly
> qui suis-je : http://sly.letuffe.org
> email perso : sylvain chez letuffe un point org
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] téléchargement d'une zone trop grande

[Philippe Verdy]

Le 22 février 2012 15:44, sukran.geo sukran.geo  a écrit :
>
> Bonjour,
>
> J'ai une zone dans OSM que je veux télécharger, mais... apparemment, elle
> est trop grande, et voici le message qui s'affiche. (voir JPEG Joint) J'ai
> ensuite téléchargé le fichier de Geofabrik, mais idem, pb de taille.
>
> Que faire ? Il me faut toute la zone, et je ne veux pas pas faire plein de
> petits morceaux.

Ceci soulève tout de même un petit problème de conception de JOSM, ou
de l'API OSM, voire les deux.

En effet, la base de données OSM est d'abord à la base une base
purement relationnelle, mais dont une des tables, la table des nœuds,
contient un attribut de type coordonnées en 2D, cette table étant
indexée sur cet attribut avec un index spécial permettant de l'indexer
simultanément sur chaque coordonnée, et de façon à équilibrer dans
l'arbre de recherche le poids des éléments dans l'arbre.

Globalement un tel index "géométrique", quand il doit créer une
branche dans son arbre, car choisir de faire un découpage sur la
première ou la seconde coordonnée, avec une valeur intermédiaire
séparant chaque partie en deux groupes équilibrés en terme de nombre
d'objets, et en alternant si possible entre un découpage selon la
première ou la seconde coordonées ; l'index contient donc le numéro de
la coordonnée utilisée et les valeurs de seuil de découpage selon
cette coordonnée dans une page de données de taille maximale fixe,
contenant par ailleurs les références aux objets feuilles dans la
table relationnelle des nœuds).

Donc normalement le serveur de base de données est capable, grace à
cet index 2D, de non seulement trouver la liste de touts les points
dans un rectangle donné, mais aussi de répondre TRES EFFICACEMENT à
une requête similaire à :

  SELECT COUNT(*) FROM nodes
  WHERE (nodes.x, nodes.y) BETWEEN ($x0, $y0) AND ($x1, $y1)

-- Ne tenez pas compte de la syntaxe SQL réelle, cela dépend du moteur
SQL utilisé, la seule chose qui lui est demandée est de savoir gérer
un index multidimensionnel, au lieu des requêtes relationnelles basées
sur des valeurs simples telles que:

  SELECT COUNT(*) FROM nodes
  WHERE nodes.x >= $x0 AND  nodes.x <= x1
  AND nodes.y >= $y0 AND nodes.y <= $y1

où on ne dispose que d'un ou plusieurs index classiques privilégiant
un attribut unidemensionnel de coordonnée à un autre (par exemple x
puis y), ce qui n'est pas efficace du tout pour les requêtes
cartographiques (ou n'importe quel système contenant des données
multidimensionnelles, trop dépendantes de la projection utilisée et de
son orientation au départ totalement arbitraire mais très déterminante
avec des index simples).

On peut noter que les extensions "mutlidimentionnelles" des serveurs
relationnels ne se limitent pas aujourd'hui aux seules coordonnées
d'un système numérique homogène, mais peuvent s'utiliser même pour des
dimensions non numériques, l'index multidimensionnel étant optimisé de
façon à répartir les axes de découpage, là encore en sélectionnant
automatiquement (sur des critères de poids statistique) les valeurs
(non nécessairement numériques, du moment que leur type dispose d'un
ordre au moins partiel) de seuil sur chaque dimension. De même le
nombre de dimensions indexées ensembles n'est pas nécessairement
restreint à 2 ou 3.

Avec ce type de requête, le serveur n'aura pas à renvoyer au client
systématiquement la longue liste de noeuds contenus dans un rectangle
donné (donc pas non plus les chemins et relations qui référencent ces
points). Le serveur peut donc estimer correctement le volume d'une
telle liste, et répondre au client avec cette estimation, lui
demandant de subdiviser sa requête en autant de sous-rectangles que
nécessaires pour que le volume des noeuds de chaque sous-rectangle
reste sous une limite donnée.

De la même façon le serveur pourra aussi estimer correctement et assez
efficacement le nombre de chemins et de relations concernées. Le
serveur peut aussi indiquer au client les limites de volume qu'il
supporte.

Dès lors, la première chose effectuée par un client ne serait pas de
demander la liste des objets dans une zone, mais leur nombre !

Afin que le client s'adapte automatiquement à ce que le serveur
supporte, et que le client puisse informer l'utilisateur et lui
demander s'il souhaite poursuivre avant de procéder au redécoupage de
la zone demandée en autant de sous-rectangle que nécessaire.

De même le client pourra interrompre à tout moment (notamment s'il en
est averti par d'autres moyens) de ralentir le nombre de requêtes pour
ces sous-rectangles, voire aussi pour faire des requêtes plus
sélectives (en ajoutant un filtre sur le type d'objets demandés,
sachant que le logiciel client peut conserver la trace qu'un
sous-rectangle a pu être chargé complètement ou sélectivement avec un
filtre, ainsi que la trace datée de son dernier chargement, pour que
ce client puisse s'abstenir de faire certaines demandes de remises à
jour trop fréquentes, et inutiles si la requête n'a pas pour but de
modifier un 

Re: [OSM-talk-fr] téléchargement d'une zone trop grande

[Emilie Laffray]

Salut,

c'est fort intéressant mais plutôt que nous abreuver de ce genre de détails
peut être faudrait il en parler sur la liste de Développement en anglais,
la ou toutes les réelles discussions techniques ont lieu.
De plus, il y a des raisons historiques et de performances pour le
comportement de l'API. Déjà, c'est un choix volontaire de réduire la taille
car c'est une API pour les contributeurs. Quand le point est soulevé, on
pointe vers le fichier planète avec synchronisation.
Ce que tu offres c'est un peu un raisonnement un peu déconnectée de la
réalité. De plus, la réplication est déjà possible. Passer vers une
solution décentralisée avec une signature ne résoudra pas grand chose et le
coup de calcul des signatures sera important, sans parler le coup de la
synchronisation (il suffit de demander aux gens qui ont des miroirs ici)
rend une vrai solution décentralisée extrêmement compliquée.
Ta solution de la signature si elle n'est pas valide obligerait de rappeler
l'API et donc de rajouter une charge supplémentaire.

Emilie Laffray

2012/2/22 Philippe Verdy 

> Le 22 février 2012 15:49, sly (sylvain letuffe)  a
> écrit :
> > On mercredi 22 février 2012, sukran.geo sukran.geo wrote:
> >> Bonjour,   J'ai une zone dans OSM que je veux télécharger, mais...
> >> apparemment, elle est trop grande, et voici le message qui s'affiche.
> (voir
> >> JPEG Joint) J'ai ensuite téléchargé le fichier de Geofabrik, mais idem,
> pb
> >> de taille. Que faire ? Il me faut toute la zone, et je ne veux pas pas
> faire
> >> plein de petits morceaux.
> >
> > Elle est grosse comment ta zone ?
> > Parce que si tu veux ouvrir un département complet dans JOSM, il vaut
> mieux
> > oublier tout de suite et faire autrement ;-)
> > Si c'est raisonnablement petit, mais que l'api officielle te bloque,
> dans JOSM
> > tu peux tenter de remplacer api.openstreetmap.org par
> api.openstreetmap.fr
> > les limites en téléchargement son plus élevées
>
> Mais c'est vrai aussi qu'il manque à la base OSM un vrai système de
> réplication sur des miroirs synchronisés, capables de répondre de
> concert à une même requête.
>
> Quelques idées suivent...
>
> Une sorte de RSYNC mais adapté aux bases de données (et non à un
> système de fichiers hiérarchique), par lequel toute modification
> enregistrée dans la base principale permet d'alimenter un flux de
> redistribution des transactions "committées" vers un ensemble de bases
> miroirs. De tels systèmes de réplication sont dans tous les RDMBS
> commerciaux, mais pas toujours dans les RDBMS libres où ce sont
> souvent des greffons mal intégrés ne garantissant pas la
> synchrinisation de l'ensemble et la cohérence relationelle des
> transactions annulées par un "rollback".
>
> Cela nécessite des systèmes réellement transactionnels pour valider
> l'état réel des modifications confirmées sur une base centrale, mais
> aussi un système de "rattrapage" permettant même de resynchroniser une
> base esclave qui aurait perdu à un moment donné le fil et devrait se
> remettre à jour (par exemple en cas d'arrêt momentané pour une
> maintenance, ou à cause d'un problème réseau temporaire, ou simplement
> pour démarrer une nouvelle base esclave au départ vierge, avec une
> synchronisation qui va progressivement charger les donnés manquantes).
>
> Enfin si une telle réplication était réellement opérationnelle et
> assez rapide pour qu'un ensemble de bases miroirs puissent toutes
> répondre à une demande de chargement de données (je ne parle pas des
> requêtes de modification de ces données), une déclaration de ces bases
> miroirs opérationnelle pourrait avoir lieu dans le système DNS afin
> que ces requêtes soient distribuées au hasard sur n'importe laquelle
> de ces bases et pas forcément la base centrale qui est bien plus utile
> et seulement nécessaire pour valider les transactions de modification.
>
> Cela imposerait d'avoir deux adresses (URL) de bases de données dans
> les éditeurs : une pour les chargements et mises à jour, l'autre pour
> les modifications, sachant que ce n'est qu'au moment où on va valider
> les données (dans un système de « validation en deux phases ») que la
> première chose qui sera faite sera de comparer les versions provenant
> des miroirs et celles actuellement dans la base, afin qu'à ce seul
> moment-là le serveur central puisse fournir une URL vers les données à
> jour dans un des miroirs disponibles sur lequel le serveur central
> pourrait poser un verrou temporaire sur les objets correspondants,
> pour la validation en deux phases, jusqu'à ce que soit la transaction
> soit validée par un "commit" soit annulée par un "rollback", soit que
> cette annulation ait lieu automatiquement après un délai raisonnable,
> le client devant alors refaire ses transactions et étant prévenu que
> sa dernière transaction a été annulée).
>
> Bote: les transations sont autre chose que les groupes de
> modifications qui sont des regroupements logiques effectués
> utilisateur par utilisateur (selon leur pro

Re: [OSM-talk-fr] téléchargement d'une zone trop grande

[Philippe Verdy]

Non, la signature numérique ne modifie pas du tout l'API car cela
n'apparaîtra que comme des attributs de plus parmi d'autres.

Le 22 février 2012 18:29, Emilie Laffray  a écrit :
> Salut,
>
> c'est fort intéressant mais plutôt que nous abreuver de ce genre de détails
> peut être faudrait il en parler sur la liste de Développement en anglais, la
> ou toutes les réelles discussions techniques ont lieu.
> De plus, il y a des raisons historiques et de performances pour le
> comportement de l'API. Déjà, c'est un choix volontaire de réduire la taille
> car c'est une API pour les contributeurs. Quand le point est soulevé, on
> pointe vers le fichier planète avec synchronisation.
> Ce que tu offres c'est un peu un raisonnement un peu déconnectée de la
> réalité. De plus, la réplication est déjà possible. Passer vers une solution
> décentralisée avec une signature ne résoudra pas grand chose et le coup de
> calcul des signatures sera important, sans parler le coup de la
> synchronisation (il suffit de demander aux gens qui ont des miroirs ici)
> rend une vrai solution décentralisée extrêmement compliquée.
> Ta solution de la signature si elle n'est pas valide obligerait de rappeler
> l'API et donc de rajouter une charge supplémentaire.
>
> Emilie Laffray
>
> 2012/2/22 Philippe Verdy 
>>
>> Le 22 février 2012 15:49, sly (sylvain letuffe)  a
>> écrit :
>> > On mercredi 22 février 2012, sukran.geo sukran.geo wrote:
>> >> Bonjour,   J'ai une zone dans OSM que je veux télécharger, mais...
>> >> apparemment, elle est trop grande, et voici le message qui s'affiche.
>> >> (voir
>> >> JPEG Joint) J'ai ensuite téléchargé le fichier de Geofabrik, mais idem,
>> >> pb
>> >> de taille. Que faire ? Il me faut toute la zone, et je ne veux pas pas
>> >> faire
>> >> plein de petits morceaux.
>> >
>> > Elle est grosse comment ta zone ?
>> > Parce que si tu veux ouvrir un département complet dans JOSM, il vaut
>> > mieux
>> > oublier tout de suite et faire autrement ;-)
>> > Si c'est raisonnablement petit, mais que l'api officielle te bloque,
>> > dans JOSM
>> > tu peux tenter de remplacer api.openstreetmap.org par
>> > api.openstreetmap.fr
>> > les limites en téléchargement son plus élevées
>>
>> Mais c'est vrai aussi qu'il manque à la base OSM un vrai système de
>> réplication sur des miroirs synchronisés, capables de répondre de
>> concert à une même requête.
>>
>> Quelques idées suivent...
>>
>> Une sorte de RSYNC mais adapté aux bases de données (et non à un
>> système de fichiers hiérarchique), par lequel toute modification
>> enregistrée dans la base principale permet d'alimenter un flux de
>> redistribution des transactions "committées" vers un ensemble de bases
>> miroirs. De tels systèmes de réplication sont dans tous les RDMBS
>> commerciaux, mais pas toujours dans les RDBMS libres où ce sont
>> souvent des greffons mal intégrés ne garantissant pas la
>> synchrinisation de l'ensemble et la cohérence relationelle des
>> transactions annulées par un "rollback".
>>
>> Cela nécessite des systèmes réellement transactionnels pour valider
>> l'état réel des modifications confirmées sur une base centrale, mais
>> aussi un système de "rattrapage" permettant même de resynchroniser une
>> base esclave qui aurait perdu à un moment donné le fil et devrait se
>> remettre à jour (par exemple en cas d'arrêt momentané pour une
>> maintenance, ou à cause d'un problème réseau temporaire, ou simplement
>> pour démarrer une nouvelle base esclave au départ vierge, avec une
>> synchronisation qui va progressivement charger les donnés manquantes).
>>
>> Enfin si une telle réplication était réellement opérationnelle et
>> assez rapide pour qu'un ensemble de bases miroirs puissent toutes
>> répondre à une demande de chargement de données (je ne parle pas des
>> requêtes de modification de ces données), une déclaration de ces bases
>> miroirs opérationnelle pourrait avoir lieu dans le système DNS afin
>> que ces requêtes soient distribuées au hasard sur n'importe laquelle
>> de ces bases et pas forcément la base centrale qui est bien plus utile
>> et seulement nécessaire pour valider les transactions de modification.
>>
>> Cela imposerait d'avoir deux adresses (URL) de bases de données dans
>> les éditeurs : une pour les chargements et mises à jour, l'autre pour
>> les modifications, sachant que ce n'est qu'au moment où on va valider
>> les données (dans un système de « validation en deux phases ») que la
>> première chose qui sera faite sera de comparer les versions provenant
>> des miroirs et celles actuellement dans la base, afin qu'à ce seul
>> moment-là le serveur central puisse fournir une URL vers les données à
>> jour dans un des miroirs disponibles sur lequel le serveur central
>> pourrait poser un verrou temporaire sur les objets correspondants,
>> pour la validation en deux phases, jusqu'à ce que soit la transaction
>> soit validée par un "commit" soit annulée par un "rollback", soit que
>> cette annulation ait lieu automatiquement après 

Re: [OSM-talk-fr] téléchargement d'une zone trop grande - Mirroirs de la base OSM

[sly (sylvain letuffe)]

On mercredi 22 février 2012, Emilie Laffray wrote:
> Postgresql merde quand il y a des tables
> temporaires. C'est un bug connu qu'on espere voir corrige dans 9.2.

Que postgresql s'améliore sur ce point c'est bien, mais je ne suis pas sûr que 
ça soit la meilleure voie car cela restreindrait à postgresql là ou 
des "mirroirs" dans d'autres schémas, base, formats pourraient profiter d'une 
réplication temps réél.

Mais quoi qu'il en soit, ça sera du boulot et je souhaite beaucoup de courage 
à ceux qui vont se lancer dans le projet

-- 
sly
qui suis-je : http://sly.letuffe.org
email perso : sylvain chez letuffe un point org

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

Re: [OSM-talk-fr] Rencontre entre contributeurs à Marseille

[Charles Nepote]

Notez qu'on va démarrer à 18h, certains ne pouvant rester au-delà de 
19h45...

Charles.


Le 21/02/2012 11:56, Christian Quest a écrit :

Le 20 février 2012 23:44, Gilles Bassière  a écrit :

Bonsoir,

Nous serons une poignée de contributeurs à nous réunir ce jeudi 23
février à 18h30 à la brasserie "Les Danaïdes" à Marseille. Le but est de
se rencontrer et d'initier un groupe d'utilisateurs local. L'idée est
décrite ici : http://wiki.openstreetmap.org/wiki/Talk:Marseille.

S'il y a sur cette liste des gens de Marseille ou des alentours (ou même
de passage dans la région), n'hésitez pas à vous joindre à nous. Vous
êtes les bienvenus.

Cordialement
--
Gilles Bassière - Web/GIS software engineer
http://gbassiere.free.fr/


Et hop: http://www.openstreetmap.fr/2012-02-23-marseille





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

Re: [OSM-talk-fr] téléchargement d'une zone trop grande

[Philippe Verdy]

Enfin je me suis expliqué plus longuement pourquoi une requête de
simple comptage peut être très efficace et soulager énormément le
serveur.

Car les technologies d'indexation multidimensionnelle dans une base de
données relationnelle existent depuis longtemps (plusieurs dizaines
d'années qu'elles sont proposées au départ comme extensions dans les
SGBD, puis intégrées totalement à ces systèmes qui incluent nativement
la création de tels index, pour différentes applications y compris les
"métacubes" qui effectuent des agrégations complexes de données au
départ purement relationnelles et à valeur simples).

La syntaxe de création de tels index multidimensionels peut être aussi
simple que:

CREATE INDEX nodes_coords ON nodes ((x, y))

où les parenthèses internes indiquent que les attributs indiqués ne
privilégient pas un ordre d'indexation d'un attribut par rapport à un
autre, mais demandent à l'index de maintenir automatiquement un
parcours équilibré de l'index entre les dimensions indiquées.

En l'absence de tels index multidimensionnels intégrés au moteur SQL,
il fallait d'abord créer dans la table de noeuds une valeur d'attribut
supplémentaire, produite par une transformée alternant les bits de
données successifs de chaque coordonnées, et ensuite créer un index
basé sur la valeur de cet attribut spécial.

Mais c'était coûteux en espace, et pas optimal non plus car la
transformation était prédéterminée en fixant dès le départ le mode de
découpage strictement alterné entre les dimensions, sans tenir compte
du poids statistique réel de chaque découpe fixée aussi sur des
valeurs de seuil prédéterminées (sans tenir compte de la densité
réelle des éléments dans chaque découpe : l'arbre de découpage n'était
pas bien équilibré à cause justement de cette transformation
arbitrairement prédéterminée sur des seuils fixes, là où un index
multidimensionnel détermine localement et automatiquement les seuils
les plus adéquats pour maintenir le meilleur équilibre statistique et
une densité à peu près constante dans tous les parcours possibles et à
tous les niveaux de l'arbre).

Le 22 février 2012 18:31, Philippe Verdy  a écrit :
> Non, la signature numérique ne modifie pas du tout l'API car cela
> n'apparaîtra que comme des attributs de plus parmi d'autres.
>
> Le 22 février 2012 18:29, Emilie Laffray  a écrit :
>> Salut,
>>
>> c'est fort intéressant mais plutôt que nous abreuver de ce genre de détails
>> peut être faudrait il en parler sur la liste de Développement en anglais, la
>> ou toutes les réelles discussions techniques ont lieu.
>> De plus, il y a des raisons historiques et de performances pour le
>> comportement de l'API. Déjà, c'est un choix volontaire de réduire la taille
>> car c'est une API pour les contributeurs. Quand le point est soulevé, on
>> pointe vers le fichier planète avec synchronisation.
>> Ce que tu offres c'est un peu un raisonnement un peu déconnectée de la
>> réalité. De plus, la réplication est déjà possible. Passer vers une solution
>> décentralisée avec une signature ne résoudra pas grand chose et le coup de
>> calcul des signatures sera important, sans parler le coup de la
>> synchronisation (il suffit de demander aux gens qui ont des miroirs ici)
>> rend une vrai solution décentralisée extrêmement compliquée.
>> Ta solution de la signature si elle n'est pas valide obligerait de rappeler
>> l'API et donc de rajouter une charge supplémentaire.
>>
>> Emilie Laffray
>>
>> 2012/2/22 Philippe Verdy 
>>>
>>> Le 22 février 2012 15:49, sly (sylvain letuffe)  a
>>> écrit :
>>> > On mercredi 22 février 2012, sukran.geo sukran.geo wrote:
>>> >> Bonjour,   J'ai une zone dans OSM que je veux télécharger, mais...
>>> >> apparemment, elle est trop grande, et voici le message qui s'affiche.
>>> >> (voir
>>> >> JPEG Joint) J'ai ensuite téléchargé le fichier de Geofabrik, mais idem,
>>> >> pb
>>> >> de taille. Que faire ? Il me faut toute la zone, et je ne veux pas pas
>>> >> faire
>>> >> plein de petits morceaux.
>>> >
>>> > Elle est grosse comment ta zone ?
>>> > Parce que si tu veux ouvrir un département complet dans JOSM, il vaut
>>> > mieux
>>> > oublier tout de suite et faire autrement ;-)
>>> > Si c'est raisonnablement petit, mais que l'api officielle te bloque,
>>> > dans JOSM
>>> > tu peux tenter de remplacer api.openstreetmap.org par
>>> > api.openstreetmap.fr
>>> > les limites en téléchargement son plus élevées
>>>
>>> Mais c'est vrai aussi qu'il manque à la base OSM un vrai système de
>>> réplication sur des miroirs synchronisés, capables de répondre de
>>> concert à une même requête.
>>>
>>> Quelques idées suivent...
>>>
>>> Une sorte de RSYNC mais adapté aux bases de données (et non à un
>>> système de fichiers hiérarchique), par lequel toute modification
>>> enregistrée dans la base principale permet d'alimenter un flux de
>>> redistribution des transactions "committées" vers un ensemble de bases
>>> miroirs. De tels systèmes de réplication sont dans tous les RDMBS
>>> commerciaux, mais pas 

Re: [OSM-talk-fr] Une carte orientée biologie ? (arbres, insectes, oiseaux, plantes)

[Samy Mezani]

le 22/02/2012 17:13, Florian LAINEZ a écrit:

just do it :p


Si seulement j'avais les compétences, je n'hésiterais pas ! :)


Le 22 février 2012 14:20, Samy Mezani 

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

Re: [OSM-talk-fr] téléchargement d'une zone trop grande

[Emilie Laffray]

C'est pour ça qu'il y a le type gist sous postgresql. Mais je te conseille
vraiment de pousser l'idée sur la mailing list internationale de
développement.

Emilie Laffray

2012/2/22 Philippe Verdy 

> Enfin je me suis expliqué plus longuement pourquoi une requête de
> simple comptage peut être très efficace et soulager énormément le
> serveur.
>
> Car les technologies d'indexation multidimensionnelle dans une base de
> données relationnelle existent depuis longtemps (plusieurs dizaines
> d'années qu'elles sont proposées au départ comme extensions dans les
> SGBD, puis intégrées totalement à ces systèmes qui incluent nativement
> la création de tels index, pour différentes applications y compris les
> "métacubes" qui effectuent des agrégations complexes de données au
> départ purement relationnelles et à valeur simples).
>
> La syntaxe de création de tels index multidimensionels peut être aussi
> simple que:
>
> CREATE INDEX nodes_coords ON nodes ((x, y))
>
> où les parenthèses internes indiquent que les attributs indiqués ne
> privilégient pas un ordre d'indexation d'un attribut par rapport à un
> autre, mais demandent à l'index de maintenir automatiquement un
> parcours équilibré de l'index entre les dimensions indiquées.
>
> En l'absence de tels index multidimensionnels intégrés au moteur SQL,
> il fallait d'abord créer dans la table de noeuds une valeur d'attribut
> supplémentaire, produite par une transformée alternant les bits de
> données successifs de chaque coordonnées, et ensuite créer un index
> basé sur la valeur de cet attribut spécial.
>
> Mais c'était coûteux en espace, et pas optimal non plus car la
> transformation était prédéterminée en fixant dès le départ le mode de
> découpage strictement alterné entre les dimensions, sans tenir compte
> du poids statistique réel de chaque découpe fixée aussi sur des
> valeurs de seuil prédéterminées (sans tenir compte de la densité
> réelle des éléments dans chaque découpe : l'arbre de découpage n'était
> pas bien équilibré à cause justement de cette transformation
> arbitrairement prédéterminée sur des seuils fixes, là où un index
> multidimensionnel détermine localement et automatiquement les seuils
> les plus adéquats pour maintenir le meilleur équilibre statistique et
> une densité à peu près constante dans tous les parcours possibles et à
> tous les niveaux de l'arbre).
>
> Le 22 février 2012 18:31, Philippe Verdy  a écrit :
> > Non, la signature numérique ne modifie pas du tout l'API car cela
> > n'apparaîtra que comme des attributs de plus parmi d'autres.
> >
> > Le 22 février 2012 18:29, Emilie Laffray  a
> écrit :
> >> Salut,
> >>
> >> c'est fort intéressant mais plutôt que nous abreuver de ce genre de
> détails
> >> peut être faudrait il en parler sur la liste de Développement en
> anglais, la
> >> ou toutes les réelles discussions techniques ont lieu.
> >> De plus, il y a des raisons historiques et de performances pour le
> >> comportement de l'API. Déjà, c'est un choix volontaire de réduire la
> taille
> >> car c'est une API pour les contributeurs. Quand le point est soulevé, on
> >> pointe vers le fichier planète avec synchronisation.
> >> Ce que tu offres c'est un peu un raisonnement un peu déconnectée de la
> >> réalité. De plus, la réplication est déjà possible. Passer vers une
> solution
> >> décentralisée avec une signature ne résoudra pas grand chose et le coup
> de
> >> calcul des signatures sera important, sans parler le coup de la
> >> synchronisation (il suffit de demander aux gens qui ont des miroirs ici)
> >> rend une vrai solution décentralisée extrêmement compliquée.
> >> Ta solution de la signature si elle n'est pas valide obligerait de
> rappeler
> >> l'API et donc de rajouter une charge supplémentaire.
> >>
> >> Emilie Laffray
> >>
> >> 2012/2/22 Philippe Verdy 
> >>>
> >>> Le 22 février 2012 15:49, sly (sylvain letuffe)  a
> >>> écrit :
> >>> > On mercredi 22 février 2012, sukran.geo sukran.geo wrote:
> >>> >> Bonjour,   J'ai une zone dans OSM que je veux télécharger, mais...
> >>> >> apparemment, elle est trop grande, et voici le message qui
> s'affiche.
> >>> >> (voir
> >>> >> JPEG Joint) J'ai ensuite téléchargé le fichier de Geofabrik, mais
> idem,
> >>> >> pb
> >>> >> de taille. Que faire ? Il me faut toute la zone, et je ne veux pas
> pas
> >>> >> faire
> >>> >> plein de petits morceaux.
> >>> >
> >>> > Elle est grosse comment ta zone ?
> >>> > Parce que si tu veux ouvrir un département complet dans JOSM, il vaut
> >>> > mieux
> >>> > oublier tout de suite et faire autrement ;-)
> >>> > Si c'est raisonnablement petit, mais que l'api officielle te bloque,
> >>> > dans JOSM
> >>> > tu peux tenter de remplacer api.openstreetmap.org par
> >>> > api.openstreetmap.fr
> >>> > les limites en téléchargement son plus élevées
> >>>
> >>> Mais c'est vrai aussi qu'il manque à la base OSM un vrai système de
> >>> réplication sur des miroirs synchronisés, capables de répondre de
> >>> concert à une même requête.
> >>>
> >>> Quelque

Re: [OSM-talk-fr] téléchargement d'une zone trop grande

[Philippe Verdy]

Le 22 février 2012 18:29, Emilie Laffray  a écrit :
> Ce que tu offres c'est un peu un raisonnement un peu déconnectée de la
> réalité. De plus, la réplication est déjà possible. Passer vers une solution
> décentralisée avec une signature ne résoudra pas grand chose et le coup de
> calcul des signatures sera important, sans parler le coup de la
> synchronisation (il suffit de demander aux gens qui ont des miroirs ici.

Justement elle est tout à fait appropriée quand on regarde la
difficulté et le coût de la synchronisation. C'est là que des
solutions sont à discuter, développer et déployer.

Je persiste qu'un développement est possible de ce côté là (et que de
tels systèmes existent déjà dans les SGBD commerciaux comme Oracle,
Sybase, MS SQL...) qui supportent des synchronisations très fiables, y
compris pour des opérations asynchrones, qui permettent à un miroir de
rattraper facilement son retard, mais aussi d'assurer la cohérence des
données (sans en oublier, ni les corrompre).

Car si vous ne comptez que que la réplication avec quelques
partenaires choisis, cela ne tiendra pas longtemps, et cela continuera
à imposer les plus forts coûts sur ceux qui maintiennent la base
centrale, dont la bande passante (et la puissance de calcul de son
moteur sollicité) ne suffira pas, tandis que les rares partenaires de
réplication choisis ne suivront plus non plus car ils devraient être
plus nombreux.

Après cela il reste la solution des dumps complets, mais ils sont de
plus en plus coûteux aussi à générer de façon assez fréquente, et
extrêmement lourds à réutiliser sur un site qui voudrait en faire un
miroir (forcément de moins en moins à jour). CEs dumps ne servent au
mieux que comme solution de sauvegarde (pour produire un snapshot à un
instant T, sachant qu'on ne peut pas les faire aussi souvent qu'on le
voudrait à cause de leur volume conséquent), pas comme solution de
réplication.

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

[OSM-talk-fr] Je suis le sujet dev-hors-sujet

[Yves]

Sautez-moi dessus, épanchez-vous, je suis là pour cela!___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] téléchargement d'une zone trop grande

[Philippe Verdy]

Le 22 février 2012 19:03, Emilie Laffray  a écrit :
> C'est pour ça qu'il y a le type gist sous postgresql. Mais je te conseille
> vraiment de pousser l'idée sur la mailing list internationale de
> développement.

Je connais ce type. Il est malheureusement bien plus limité dans son
usage que la solution très générale des index multidimensionnels, qui
sont aussi optimum en terme de distribution statistique des données
puisque 'autoadaptatifs" et ne nécessitant *aucune* prétransformation
avec un découpage prédéterminé arbitraire (ce que fait le type gist en
question).

J'ai l'habitude d'utiliser des index multidimensionnels sour Oracle,
et cela ne change strictement rien au modèle relationnel lui-même : on
n'a pas besoin du tout de type spécial pour des valeurs
multidimensionnelles (même si de tels moteurs savent par exemple
déclarer un attribut de type "nombre complexe", adéquat pour
représenter une coordonnée 2D), voire parfois aussi des valeurs de
type vecteur ou matrice (avec des dimensions et tailles
prédéterminées), pour ne pas avoir à nommer chaque coordonnée dans un
attribut séparé, ni non plus individuellement leur type, quand les
coordonnées sont de type homogène, généralement numérique (entier mais
le plus souvent ou réel en simple ou double précision), ce qui est
fort pratique pour les valeurs complexes.

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

Re: [OSM-talk-fr] téléchargement d'une zone trop grande

[Philippe Verdy]

Pas besoin de cette usine à gaz. Elle n'apporte rien de plus en terme
de facilité que ce qu'on peut faire manuellement en interrogeant
correctement la base et en gérant son cache local dans un fichier JOSM
adapté à ce qu'on veut faire, et où on arrive à n'y stocker
pratiquement que les données dont on a besoin (avec seulement les
détails complet sur des zones extrêmement petites, sélectionnées à un
niveau de zoom élevé).

Maintenant ce genre d'opérations manuelles demanderait tout de même à
être facilité par un contrôle "à priori" de la volumétrie, ce qui est
parfaitement développable aussi bien dans JOSM qu'avec le concours du
serveur capable de répondre très efficacement à des requêtes de
comptage dans une zone et pas seulement des requêtes de listes
d'objets dans une zone ou des requêtes de listes d'objets référencés
par d'autres (même avec des filtres de sélection par type d'objet).

Le 22 février 2012 17:22, Tristram Gräbener  a écrit :
> Tu peux utiliser un export geofabrik puis utiliser osmose pour
> découper la zone que tu veux

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

Re: [OSM-talk-fr] téléchargement d'une zone trop grande

[simon]

> Le 22 février 2012 19:03, Emilie Laffray  a écrit :
> > Mais je te
> > conseille vraiment de pousser l'idée sur la mailing list internationale
> > de développement.


>Le 22 février 2012 18:29, Emilie Laffray  a écrit :
>c'est fort intéressant mais plutôt que nous abreuver de ce genre de détails
>peut être faudrait il en parler sur la liste de Développement en anglais,


talk it in the english development list

sprechen sie Englisch in der Entwicklung Liste

hablar de él en la lista de desarrollo Inglés



ps : désolé pour la traduction j'ai utilisé google translate

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

Re: [OSM-talk-fr] téléchargement d'une zone trop grande - Mirroirs de la base OSM

[Philippe Verdy]

L'autre problème du système Postgresql c'est qu'il est totalement lié
à la version même du moteur. Ça manque d'ouverture et c'est une
solution technique insurmontable pour un vrai travail collaboratif,
alors qu'on a un schéma d'échange en XML parfaitement viable et
utilisable pour l'alimentation en streaming, et indépendant du moteur
utilisé.

Bref, si le système de réplication Postgres est utilisé, il servira
surtout à alimenter un second système local, lequel produira un stream
XML qui peut alors être souscrit et diffusé efficacement (et si un
client veut s'inscrire en partant de rien, il doit exister des
serveurs permettant d'obtenir, en un temps plus ou moins long une
image XML de base produite par un snapshot daté, tandis que le même
client reçoit déjà le stream live qui contient les autres mises à
jour: le premier objet du stream qu'il reçoit contient un marqueur de
la date de référence à demander au serveur de snapshot, de sorte qu'en
chargeant ensuite ce snapshot, les objets déjà reçus depuis le stream,
et qui sont davantage à jour, ne seront pas écrasés par d'anciennes
versions provenant du snapshot reçu et chargé ultérieurement).

Si on ne veut pas avoir à générer autant de snapshots que de client,
pour des raisons de coût/performance/espace, on peut aussi sur le
serveur de snapshots n'en garder qu'un ou quelques-uns, lequel serveur
peut aussi fournir aussi un stream contenant tous les objets depuis ce
snapshot jusqu'à une date assez récente (qui sera postérieure à la
date de souscription au stream "live" que le client lit déjà).

Il reste donc juste à s'assurer que les objets du stream et ceux di
serveur contiennent bien leur numéro de version afin de pouvoir
retenir celui qui est le plus avancé. On n'est pas non plus obligé de
mettre dans le stream ni dans le snapshot toutes les versions passées.
Pour les recherches d'historique, cela se fait plutôt à la demande,
objet par objet, et on peut malgré tout imaginer que les historiques
soient servis par une autre base de données sur un autre serveur,
destiné à la consultation des archives.

Le 22 février 2012 18:35, sly (sylvain letuffe)  a écrit :
> On mercredi 22 février 2012, Emilie Laffray wrote:
>> Postgresql merde quand il y a des tables
>> temporaires. C'est un bug connu qu'on espere voir corrige dans 9.2.
>
> Que postgresql s'améliore sur ce point c'est bien, mais je ne suis pas sûr que
> ça soit la meilleure voie car cela restreindrait à postgresql là ou
> des "mirroirs" dans d'autres schémas, base, formats pourraient profiter d'une
> réplication temps réél.
>
> Mais quoi qu'il en soit, ça sera du boulot et je souhaite beaucoup de courage
> à ceux qui vont se lancer dans le projet
>
> --
> sly
> qui suis-je : http://sly.letuffe.org
> email perso : sylvain chez letuffe un point org
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr

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

[OSM-talk-fr] rencontre mappeurs Paris 6 mars

[Florian LAINEZ]

Bonjour les parisiens,
ça vous dirait une rencontre IRL dans un bar histoire de parler de nos
dernières sessions de mapping ? On en a parlé au FOSDEM : à Paris on ne se
voit jamais ! C'est vraiment dommage, let's fix it ;)

Je propose le *mardi 6 mars au Hall's beer Tavern à Châtelet* (68 rue saint
denis
http://www.openstreetmap.org/?lat=48.861587&lon=2.349264&zoom=18&layers=M)
: c'est central et ça permettra à ceux qui ne connaissent pas encore la
Chouffe de découvrir cette bière inoubliable ^^
Motivés ?

-- 

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

Re: [OSM-talk-fr] rencontre mappeurs Paris 6 mars

[Vincent de Chateau-Thierry]

Bonsoir,

Le 22/02/2012 20:29, Florian LAINEZ a écrit :

Bonjour les parisiens,
ça vous dirait une rencontre IRL dans un bar histoire de parler de nos
dernières sessions de mapping ? On en a parlé au FOSDEM : à Paris on ne
se voit jamais ! C'est vraiment dommage, let's fix it ;)

Je propose le _mardi 6 mars au Hall's beer Tavern à Châtelet_ (68 rue
saint denis
http://www.openstreetmap.org/?lat=48.861587&lon=2.349264&zoom=18&layers=M 
)
: c'est central et ça permettra à ceux qui ne connaissent pas encore la
Chouffe de découvrir cette bière inoubliable ^^
Motivés ?



Merci pour l'initiative ! Enfin... si les banlieusards sont acceptés :-)
Malheureusement, pour moi, le 6 n'est pas possible. Je propose le jeudi 
8 au cas où.


À suivre,
vincent

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

Re: [OSM-talk-fr] Rencontre entre contributeurs à Marseille

[Romain MEHUT]

Vous avez convié le Collectif Vélos en Ville?

Romain

Le 22 février 2012 18:43, Charles Nepote  a écrit :

> Notez qu'on va démarrer à 18h, certains ne pouvant rester au-delà de
> 19h45...
> Charles.
>
> Le 21/02/2012 11:56, Christian Quest a écrit :
>
>> Le 20 février 2012 23:44, Gilles Bassière  a écrit :
>>
>>  Bonsoir,
>>>
>>> Nous serons une poignée de contributeurs à nous réunir ce jeudi 23
>>> février à 18h30 à la brasserie "Les Danaïdes" à Marseille. Le but est de
>>> se rencontrer et d'initier un groupe d'utilisateurs local. L'idée est
>>> décrite ici : 
>>> http://wiki.openstreetmap.org/**wiki/Talk:Marseille
>>> .
>>>
>>> S'il y a sur cette liste des gens de Marseille ou des alentours (ou même
>>> de passage dans la région), n'hésitez pas à vous joindre à nous. Vous
>>> êtes les bienvenus.
>>>
>>> Cordialement
>>> --
>>> Gilles Bassière - Web/GIS software engineer
>>> http://gbassiere.free.fr/
>>>
>>>  Et hop: 
>>> http://www.openstreetmap.fr/**2012-02-23-marseille
>>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.**org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Une carte orientée biologie ? (arbres, insectes, oiseaux, plantes)

[partir-en-vtt]

Il faut se donner les moyens ! Un projet libre dans ce domaine n'est pas
utopiste. Il suffit de trouver des personnes motivées et compétentes dans le
domaine ;-)

Personnellement, je veux bien m'investir si un noyau se forme sur un projet
comme celui-ci.

Mes compétences : 

SIG
Développement PHP/mysql/CSS/postgresql/postgis
modélisation base de données en Merise
connaissances dans le monde naturaliste
ETL FME



--
View this message in context: 
http://gis.19327.n5.nabble.com/Une-carte-orientee-biologie-arbres-insectes-oiseaux-plantes-tp5503037p5506156.html
Sent from the France mailing list archive at Nabble.com.

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

Re: [OSM-talk-fr] Réponse à un service SIG : avis et compléments souhaités

[Philippe Verdy]

Le 21 février 2012 15:08, Christian Rogel
 a écrit :
> Les techniciens des SIG seront plus à même de justifier l'emploi des outils
> OSM
> et la collaboration avec des mappeurs bénévoles, si des exemples qui
> marchent
> leur sont indiqués.
> Certains sont dans l'attente d'une valorisation publique de leur travail,
> car, ils sont
> dans le backoffice (comme l'informatique et les ressources humaines) et
> aimeraient beaucoup déployer des outils grand public, du moment que
> le coût reste faible.

Si c'est pour montrer des cartes destinées à afficher la disponibilité
de certains services, c'est déjà fait (je cite l'exemple de la ville
de Rennes OuVerte, avec un carte certes limitée à l'agglomération,
développée par des assos en collaboration avec la communauté urbaine).

En revanche c'est moins évident de montrer les outils d'analyse et de
suivi des différences constatées entre les sources SIG ouvertes et
OSM. Pourtant ces outils sont bien là.

Et justement si des utilisateurs sont ici et travaillent pour les SIG,
ils ont l'occasion d'utiliser les mêmes outils puisque leurs
compte-rendus d'analyse peut servir dans les deux sens, même s'ils
n'importent pas directement les données d'OSM. Car justement toutes
les erreurs ou manques relevés ne sont ps nécessairement dans la base
OSM mais dans la base SIG, qui ne demandait qu'à être mise à jour,
sans savoir où, et pas avec les petits budgets qu'ils ont pour faire
des recherches.

Et ils peuvent justement, s'ils sont ici, soit vouloir corriger la
base OSM, soit corriger ou compléter le SIG (ou justifier des demandes
de budget s'il faut des moyens pour le faire, lorsque de coûteux
contrôles officiels sont un préalable, ou pour financer une mission
demandée à l'Insee ou à l'IGN ou à réaliser dans un nouveau marché
public).

Donc pour eux, savoir où il y a des manques, et savoir aussi via OSM
ce qui intéresse la population, c'est déjà un progrès qui peut aider à
soutenir l'action des SIG avec plus de moyens (ou au minimum en leur
conservant leurs moyens, ou en développant de nouvelles collaborations
avec d'autres SIG ou d'autres fournisseurs commerciaux des régies
publiques qui distillent leurs données avec parcimonie, mais à qui la
population comme les politiques veulent pouvoir demander des comptes
sur la qualité de leurs services et leur efficacité quant aux services
effectivement rendus, surtout s'il y a un contraste entre ce que
perçoit la population, et mise à jour partiellement au moins dans la
base OSM, et ce que leur rapporte ces fournisseurs de marchés
publics).

Qui ne s'est jamais plaint par exemple des cartes de couverture pour
la téléphonie et l'internet mobile, ou pour les services de télévision
câblé ou par fibre? Ou encore d'une carte scolaire inadaptée, de
services publics municipaux ou communautaires mal répartis (le fait
étant masqué par la surchrge qui de toute façon ne permet de rien voir
d'autre), d'un réseau routier accidentogène ou avec des points noirs
trop congestionnés de façon imprévue suite à des modifications faites
bien ailleurs, d'un réseau de transport qui oublie des quartiers, d'un
manque de concurrence dans certaines zones pour les services
commerciaux ?

Tout ça ce sont des informations perçues par la population, mais pas
toujours rendue par les fournisseurs de marchés publics qui montrent
des rapports d'activité souvent trop optimistes sur la situation
réelle, en dépit des contrôles limités effectués.

Et puis même pour un politique qui défend un projet, c'est nettement
plus facile s'il dispose d'une carte fiable (surtout si le projet doit
comprendre des expropriations ou induire une gêne dans certaines
zones). Aujourd'hui les politiques sont plus prudents car ils sont
beaucoup plus souvent poursuivis devant les tribunaux (parfois même à
titre personnel), parce que des enquêtes publiques ont été
insuffisantes ou mal conduites, ou pas là où il aurait fallu les
faire. Un manque d'informations vérifiables par d'autres moyens que la
seule volonté affirmée des fournisseurs de marchés publics peut avoir
des conséquences sérieuses. Une communauté se doit donc de chercher
les moyens de rendre son action plus transparente, que ce soit dans
les prises de décision, ou dans le suivi et le maintien ou non d'un
service public.

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

[OSM-talk-fr] Sens interdit sauf pour les résidents ?

[Vladimir Vyskocil]

Bonsoir,

Je n'ai pas trouvé comment représenter une rue a sens unique sauf pour les 
résidents... c'est faisable ?

Merci d'avance,
Vlad.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Sens interdit sauf pour les résidents ?

[Etienne Trimaille]

Dans mon coin ce genre de rues sont en sens interdit dans les 2 sens et ne
sont accessibles que aux résidents. Peut être que c'est la même situation
chez toi, non ?

Je n'ai pas taggé les sens interdits  avec 2 tags oneway (un peu idiot
sinon), mais juste avec access=destination
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Sens interdit sauf pour les résidents ?

[Vladimir Vyskocil]

Actuellement cette rue est taggé comme tu le dis : access=destination mais je 
suis "tombé" sur un panneau sens-interdit avec en dessous sauf riverains d'un 
coté et il faut que j'aille vérifier de l'autre coté car il me semble qu'il n'y 
a rien...
Merci pour la réponse.

Vlad.

On 22 févr. 2012, at 22:58, Etienne Trimaille wrote:

> Dans mon coin ce genre de rues sont en sens interdit dans les 2 sens et ne 
> sont accessibles que aux résidents. Peut être que c'est la même situation 
> chez toi, non ?
> 
> Je n'ai pas taggé les sens interdits  avec 2 tags oneway (un peu idiot 
> sinon), mais juste avec access=destination
> 
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr

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

Re: [OSM-talk-fr] rencontre mappeurs Paris 6 mars

[didier2020]

- Mail d'origine -
De: Vincent de Chateau-Thierry 
À: Discussions sur OSM en français 
Envoyé: Wed, 22 Feb 2012 20:50:17 +0100 (CET)
Objet: Re: [OSM-talk-fr] rencontre mappeurs Paris 6 mars

Bonsoir,

Le 22/02/2012 20:29, Florian LAINEZ a écrit :
> Bonjour les parisiens,
> ça vous dirait une rencontre IRL dans un bar histoire de parler de nos
> dernières sessions de mapping ? On en a parlé au FOSDEM : à Paris on ne
> se voit jamais ! C'est vraiment dommage, let's fix it ;)
>
> Je propose le _mardi 6 mars au Hall's beer Tavern à Châtelet_ (68 rue
> saint denis
> http://www.openstreetmap.org/?lat=48.861587&lon=2.349264&zoom=18&layers=M 
> )
> : c'est central et ça permettra à ceux qui ne connaissent pas encore la
> Chouffe de découvrir cette bière inoubliable ^^
> Motivés ?
>

Merci pour l'initiative ! Enfin... si les banlieusards sont acceptés :-)
=> idem
Malheureusement, pour moi, le 6 n'est pas possible. Je propose le jeudi 
8 au cas où.
=> je suis partant pour le 6 ou le 8

didier
--mapeur amateur--

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

Re: [OSM-talk-fr] rencontre mappeurs Paris 6 mars

[Po G]

Salut

Très bonne idée. Je suis partant pour les deux dates.

POG


2012/2/23 

>
> - Mail d'origine -
> De: Vincent de Chateau-Thierry 
> À: Discussions sur OSM en français 
> Envoyé: Wed, 22 Feb 2012 20:50:17 +0100 (CET)
> Objet: Re: [OSM-talk-fr] rencontre mappeurs Paris 6 mars
>
> Bonsoir,
>
> Le 22/02/2012 20:29, Florian LAINEZ a écrit :
> > Bonjour les parisiens,
> > ça vous dirait une rencontre IRL dans un bar histoire de parler de nos
> > dernières sessions de mapping ? On en a parlé au FOSDEM : à Paris on ne
> > se voit jamais ! C'est vraiment dommage, let's fix it ;)
> >
> > Je propose le _mardi 6 mars au Hall's beer Tavern à Châtelet_ (68 rue
> > saint denis
> >
> http://www.openstreetmap.org/?lat=48.861587&lon=2.349264&zoom=18&layers=M<
> http://www.openstreetmap.org/?lat=48.861587&lon=2.349264&zoom=18&layers=M
> >)
> > : c'est central et ça permettra à ceux qui ne connaissent pas encore la
> > Chouffe de découvrir cette bière inoubliable ^^
> > Motivés ?
> >
>
> Merci pour l'initiative ! Enfin... si les banlieusards sont acceptés :-)
> => idem
> Malheureusement, pour moi, le 6 n'est pas possible. Je propose le jeudi
> 8 au cas où.
> => je suis partant pour le 6 ou le 8
>
> didier
> --mapeur amateur--
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Comment tagger un cassis ?

[Fabien]

Le 20 février 2012 21:41, Christian Quest  a écrit :
> Ca fait penser aux radiers qu'on trouve à la Réunion, qui servent
> pendant les grosses pluies, mais qui obligent aussi à ralentir...
>
> Le 20 février 2012 21:11, Fabien  a écrit :
>> Le 20 février 2012 21:05, Christian Quest  a écrit :
>>> wiktionary indique qu'un cassis est un dommage sur la chaussée, pas
>>> vraiment un ralentisseur.
>>>
>>> traffic_calming=yes serait peut-être mieux vu la page du wiki, à moins
>>> de créer une nouvelle valeur ?
>>>
>>>
>>> Le 20 février 2012 21:01, Fabien  a écrit :
 Bonjour,

 Hier en faisant une petite promenade cartographique j'ai voulu rendre
 compte d'un cassis. Pour ceux qui ne savent pas ce que c'est : c'est
 un dos d'âne sauf qu'à la place d'être une bosse c'est un trou. Dans
 mon cas en fait c'est un caniveau qui sert de cassis (assez usuel dans
 les rues de Marseille).

 Donc je vais sur le wiki :
 http://wiki.openstreetmap.org/wiki/FR:Key:traffic_calming
 Mais là je n'ai pas la possibilité de définir le cassis, j'ai mis
 traffic_calming=cassis
 (http://www.openstreetmap.org/browse/node/1639383300). Je sais bien
 que le type n'existe pas mais rien que dans un rayon de 5 km autour de
 moi j'en connais déjà 10 des zones comme cela... Est-ce que quelqu'un
 connait le bon tag à mettre ?

 Merci,
 Fabien

 PS : Je crois que j'ai fait l'une des plus grosses boulettes en
 postant ce message =>
 http://lists.fedoraproject.org/pipermail/trans-fr/2012-February/009065.html
 Franchement envoyer sur la mauvaise ML !

 ___
 Talk-fr mailing list
 Talk-fr@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-fr
>>>
>>>
>>>
>>> --
>>> Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest
>>>
>>> ___
>>> Talk-fr mailing list
>>> Talk-fr@openstreetmap.org
>>> http://lists.openstreetmap.org/listinfo/talk-fr
>>
>> Bonjour,
>>
>> Oui c'est vrai dans certains cas, mais là c'est de grandes rigoles qui
>> sont même délimitées par des pavés (je ferais une photo demain si j'ai
>> le temps). Je sais bien que mettre yes pourrait être une bonne idée
>> surtout si personne n'en trouve d'autres dans leur région... Dans ce
>> cas-là on ne peut vraiment pas considérer que c'est du même type que
>> des nids de poule.
>>
>> Fabien
>>

Bonjour,

Je ne sais pas trop à quoi sert des radiers mais clairement oui c'est
à cause des grosses pluies. Ce matin j'ai tenté de faire une image.
Voici à quoi cela ressemble (dans un des cas) :
http://imageshack.us/photo/my-images/593/img20120223082800.jpg/

Dommage j'ai pas réussi à prendre l'image avec une voiture qui a les
roues dans le « trou » pour montrer la profondeur... On va dire que
presque une voiture sur 2 a le pare-choc avant qui touche en passant.

Fabien

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