[OSM-talk-fr] Re : Salut et encouragement pour Camille obligée de quitter Ecrans.fr

[THEVENON Julien]

 De : Pieren 


 Camille a été la journaliste qui a parlé de manière la plus complète et 
professionnelle du projet OpenStreetMap. Avec la qualité de son travail, je 
ne 
doute pas qu'elle retrouvera rapidement un job à la hauteur de son talent.

 La communauté OSM France lui doit beaucoup grâce à toutes les occasions 
 qu'elle 
n'a jamais manqué pour parler de notre projet.

+1 ! un grand merci pour ces contributions

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

[OSM-talk-fr] Re : Serveur mutualisé pour rendu du relief

[THEVENON Julien]

 De : hamster 


 je peux le voir ou ce "rendu de sly" ?

je suppose que c est celui la :
http://beta.letuffe.org/?zoom=11&lat=45.18825&lon=5.71263&layers=0B000FFFT

ou celui-ci 
http://www.refuges.info/nav.php?zoom=12&lat=45.19211&lon=5.73183&layers=B000FTTFFFTTT

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

[OSM-talk-fr] Re : Serveur mutualisé pour rendu du relief

[THEVENON Julien]

 De : Romain MEHUT 



 Remarque peut être naïve mais y aurait pas moyen d'aider tout simplement 
 le 
créateur d'Opencyclemap pour que celui-ci soit à jour vis à vis des données 
d'OSM? 


Cela ne bénéficierait qu a Opencyclemap.. alors qu'un serveur mutualisé 
permettrait a beaucoup plus d applications d en bénéficier.
En gros c est le principe de la mutualisation, l intérêt pour tous ;-)

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

Re: [OSM-talk-fr] cadastre-fr, un soucis sur JOSM ?

[Pieren]

Je viens de mettre en ligne une nouvelle version du plugin cadastre-fr qui
corrige ce problème (rev.26228).
Il est probable que cette version ne fonctionne qu'avec JOSM latest (à
partir de rev.4181). Si la mise à jour n'est pas automatique, il est
possible de la faire manuellement depuis le menu des préférences (rafraichir
la liste auparavant).

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

Re: [OSM-talk-fr] Données ouverte sur les transports et plans de ville

[Christian Rogel]

Le 30/06/11 18:20, Ab_fab a écrit :

Oui, mais cela existe déjà en fait, depuis plus d'un an !
http://lists.openstreetmap.org/pipermail/talk-fr/2010-June/022660.html
http://blog.isokron.com/category/cartes-isochrones
"Ces cartes sont obtenues en temps réel en se servant des données
OpenStreetMap . "
http://www.rue89.com/2011/06/12/on-se-retrouve-ou-la-reponse-est-sur-la-carte-isokron-208972
Après des débuts très parisiens, ils ont aussi phosphoré sur Rennes à la
suite de la liberation des données



Effectivement, ils sont aussi en avance et on peut déterminer des lieux 
de RV à mi-chemin.

J'ai trouvé sur leur blog un petit bijou :
Un lundi à Rennes (Monday in Rennes) : comment l'offre de transport fait 
évoluer les temps de parcours sous la forme d'une animation avec fond OSM :

http://blog.isokron.com/monday-in-rennes
Trouvable aussi sur Vimeo.
Leur application, Locomote, est sur IPhone et bientôt sous Android.


Christian



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

Re: [OSM-talk-fr] Salut et encouragement pour Camille obligée de quitter Ecrans.fr

[Pieren]

Camille a été la journaliste qui a parlé de manière la plus complète et
professionnelle du projet OpenStreetMap. Avec la qualité de son travail, je
ne doute pas qu'elle retrouvera rapidement un job à la hauteur de son
talent.

La communauté OSM France lui doit beaucoup grâce à toutes les occasions
qu'elle n'a jamais manqué pour parler de notre projet.

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

[OSM-talk-fr] Imports sauvages de bâti du cadastre

[isnogoud]

Depuis plus d'un mois, un nouveau(?) contributeur se livre à de nombreux 
imports de bâti du cadastre sans effectuer aucune correction.


Je lui ai amicalement signalé la page du wiki décrivant les traitements 
à effectuer avant import et je lui ai proposé de me contacter s'il avait 
besoin d'aide.


Il n'a pas daigné me répondre et poursuit actuellement comme si de rien 
n'était.


Quelqu'un peut-il intervenir pour contenir sa frénésie et limiter les 
dégâts ?


Ses œuvres sont visibles sur Concarneau, Paimpol, Plouha, Condrieu.

Librement

Christophe

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

Re: [OSM-talk-fr] Serveur mutualisé pour rendu du relief

[hamster]

Le 30/06/2011 22:30, yvecai a écrit :

On 30. 06. 11 21:53, hamster wrote:

Le 30/06/2011 21:07, ad...@partir-en-vtt.com a écrit :

Bonsoir,

Concernant les rendus, je pense qu'il faudrait en priorité :

-Une couche sur les courbes de niveau avec étiquette
-Une couche avec l'ombrage du relief


- une couche avec un degrade en fonction de l'altitude

l'ombrage du relief donne une impression visuelle saisissante, mais
trompeuse : on y voit bien les pentes qui sortent en plus sombre et
assez mal celles qui sortent en plus clair
par exemple un plateau traverse par une vallee apparai facilement
comme le bord d'un plateau avec une plaine a son pied, on voit bien la
descente du plateau dans la vallee mais mal la remontee de la vallee
au plateau en face
de plus ca ne permet pas de voir a quelle altitude est un point

Oui, sur mon rendu ombré j'ai fait en sorte de tout gommer sur les
versants ouest et jusqu'aux plaines: c'est encore le meilleur moyen pour
ne pas faire une carte 'grisouille'. C'est joli, mais on a peu d'infos.


on pourrait supperposer l'ombrage aux courbes de niveau, mais suivre
les courbes de niveau en zone urbaine, au milieu des rues, POI et
batiments, est un cauchemar

le degrade en fonction de l'altitude est peut etre moins joli, mais
plus fonctionnel (ce qui n'empeche pas de faire aussi les autres)

Sauf si on colore à la manière du rendu de Sly, là, c'est joli!


je peux le voir ou ce "rendu de sly" ?


Et pour
la précision, à part les courbes de niveaux qui elles sont directement
chiffrées ...


je n'ai pas parle de precision mais de lisibilite
sur cet exemple
http://www.cartes-topographiques.fr/?lt=48.78132&lg=2.314719&zm=13&tp=terrain
on voit bien que le coin de bagneux est a peu pres a la meme hauteur que 
celui de sceaux
c'est pas au metre pres mais y'a pas mal d'usages pour lesquels ca 
suffit, et vu comme c'est urbanise t'aura bien du mal a t'y retrouver 
sur une carte avec lignes de niveau


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

Re: [OSM-talk-fr] Serveur mutualisé pour rendu du relief

[admin]

Il faudrait donc trouver trois ou quatre contributeurs pour trouver les 36€ par mois. 

Après, il faut aussi les compétences qui suivent :

-Création de la donnée brute et valorisation de celle-ci
-Paramétrage/Administration d'un serveur linux et des applications nécessaires 
pour la gestion et la diffusion des données
-Création d'un portail 
-Communication
-Gestion de projet
...


Pour le backup PostGIS les  
courbes la france, pour ceux et celles souhaitant le télécharger ce sera dispo dans une heure trente à ce lien :

http://www.partir-en-vtt.com/stockage/temp/cb_niveauaster_france.backup

Sportivement, Loïc & Flo
www.partir-en-vtt.com




On 30. 06. 11 21:25, ad...@partir-en-vtt.com wrote:
> Ton interrogation est tout à fait justifié mais si se sont des personnes avec 
un revenu fixe qui financent le projet, je ne pense pas que 5 à 10 € par mois 
soit insurmontable sur la durée.
>
> J'ai déjà vécu des cas comme celui-là où cela ne fonctionnait pas car il y 
avait un manque de sérieux. Je ne pense pas que les personnes de la liste OSM 
ne soient pas sérieux !
Manque de sérieux, lassitude, cas de force majeure, ... les conditions 
sont multiples.
> Après cela peut être comme cela au départ, puis après, lorsque le service web 
sera diffusé, peut être pourrons nous trouver un mécène ;-)
C'est encore le meilleur objectif.
> Sportivement, Loïc&  Flo
> www.partir-en-vtt.com
>
>
>
> On 30. 06. 11 21:07, ad...@partir-en-vtt.com wrote:
>> Bonsoir,
>>
>> Je trouve cette idée séduisante que de créer un fond relief sur OSM d'autant
> plus que cela pourrait me servir pour mes randonnées. D'ailleurs ce fond
> remplacerait du coup le fond relief de google qui est ajouté à mon module
> cartographique.
>> J'ai essayé de regarder du côté des données ASTER et je pense que l'on peut
> réussir à générer une base de toutes les données du monde (je fait un essai 
sur
> la france entière en ce moment). Ce qui est sûr, c'est que cela va nécessiter
> un gros traitement à l'origine mais une fois que ce sera fait ce sera fait ! 
La
> question est est-ce que les données ASTER sont compatibles avec OSM ?
> A priori, pas fait pour une utilisation commerciale. Il faudrait
> probablement trouver un accord avec eux pour lancer un truc important.
> J'ai l'impression que les conditions d'utilisation sont floues parce
> qu'il s'agit de données provenant d'origine variées.
>> Concernant les rendus, je pense qu'il faudrait en priorité :
>>
>> -Une couche sur les courbes de niveau avec étiquette
>> -Une couche avec l'ombrage du relief
> +1
>> Ensuite concernant le serveur je pense qu'un dédié de chez Dedibox le 
classic
> à 30 € hors taxe devrait faire l'affaire. Il faudrait juste estimer la 
capacité
> du disque car là c'est un 500 go en raid 1 (duplication).
>> Concernant le mode de financement, je propose un appel aux volontaires. Je
> suis près à mettre de ma poche entre 5 et 10 € par mois si je suis intégré au
> projet.
> La question dans ce cas de figure est comment gérer l'abonnement à
> dedibox? Quelqu'un qui récupère les sous et paye en son nom ne me parait
> pas une solution très pérenne.
>
> Yves
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>
>
>


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



-- 
Loïc et Flo.

Créateurs et administrateurs de www.partir-en-vtt.com.

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

Re: [OSM-talk-fr] Serveur mutualisé pour rendu du relief

[yvecai]

On 30. 06. 11 21:25, ad...@partir-en-vtt.com wrote:

Ton interrogation est tout à fait justifié mais si se sont des personnes avec 
un revenu fixe qui financent le projet, je ne pense pas que 5 à 10 € par mois 
soit insurmontable sur la durée.

J'ai déjà vécu des cas comme celui-là où cela ne fonctionnait pas car il y 
avait un manque de sérieux. Je ne pense pas que les personnes de la liste OSM 
ne soient pas sérieux !
Manque de sérieux, lassitude, cas de force majeure, ... les conditions 
sont multiples.

Après cela peut être comme cela au départ, puis après, lorsque le service web 
sera diffusé, peut être pourrons nous trouver un mécène ;-)

C'est encore le meilleur objectif.

Sportivement, Loïc&  Flo
www.partir-en-vtt.com



On 30. 06. 11 21:07, ad...@partir-en-vtt.com wrote:

Bonsoir,

Je trouve cette idée séduisante que de créer un fond relief sur OSM d'autant

plus que cela pourrait me servir pour mes randonnées. D'ailleurs ce fond
remplacerait du coup le fond relief de google qui est ajouté à mon module
cartographique.

J'ai essayé de regarder du côté des données ASTER et je pense que l'on peut

réussir à générer une base de toutes les données du monde (je fait un essai sur
la france entière en ce moment). Ce qui est sûr, c'est que cela va nécessiter
un gros traitement à l'origine mais une fois que ce sera fait ce sera fait ! La
question est est-ce que les données ASTER sont compatibles avec OSM ?
A priori, pas fait pour une utilisation commerciale. Il faudrait
probablement trouver un accord avec eux pour lancer un truc important.
J'ai l'impression que les conditions d'utilisation sont floues parce
qu'il s'agit de données provenant d'origine variées.

Concernant les rendus, je pense qu'il faudrait en priorité :

-Une couche sur les courbes de niveau avec étiquette
-Une couche avec l'ombrage du relief

+1

Ensuite concernant le serveur je pense qu'un dédié de chez Dedibox le classic

à 30 € hors taxe devrait faire l'affaire. Il faudrait juste estimer la capacité
du disque car là c'est un 500 go en raid 1 (duplication).

Concernant le mode de financement, je propose un appel aux volontaires. Je

suis près à mettre de ma poche entre 5 et 10 € par mois si je suis intégré au
projet.
La question dans ce cas de figure est comment gérer l'abonnement à
dedibox? Quelqu'un qui récupère les sous et paye en son nom ne me parait
pas une solution très pérenne.

Yves

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






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

Re: [OSM-talk-fr] Serveur mutualisé pour rendu du relief

[yvecai]

On 30. 06. 11 21:40, hamster wrote:

Le 30/06/2011 21:09, yvecai a écrit :

est-ce que c'est un degrade de couleurs en fonction de l'altitude ?
Super, je cherchais des équivalents en français mais j'ai laissé 
tomber:)


ben... tu repond pas a mes questions
je suis pas sur du tout de mes traductions

Moi ca me va. Ou alors relief-couleur pour faire plus court pour le dernier.



si oui, est-ce que le meme en niveaux de gris ou en niveaux d'une
seule couleur aurait un interet ?

Pas sûr, faudrait voir un exemple mais je vois pas trop l'interêt
graphique de la chose. Finalement ça revient à sortir des tuiles avec
les données d'altitude sur 8 bits. Peut-être utile pour un rendu coté
client?


faire un rendu qui se supperpose pas trop mal sur un fond arc en ciel 
c'est super dur
quelle que soit la couleur que tu choisisse pour dessiner les elements 
(routes, batiments, eau, etc...) il y a toujours des zones ou ca se 
voit pas parce que de la meme couleur que le fond
finalement la seule possibite qu'il reste c'est de tout dessiner en 
noir, et c'est pas terrible, exemple :
http://www.cartes-topographiques.fr/?lt=48.803641&lg=2.328559&zm=15&tp=terrain 

Oui, un peu psyché, là! LA carte est fonctionnelle, mais pas super 
esthétique.


si le relief est fait par degrade d'une seule couleur, il te suffit 
d'eviter de trop t'approcher de cette couleur pour le rendu des objets

Un exemple?


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

Re: [OSM-talk-fr] Serveur mutualisé pour rendu du relief

[yvecai]

On 30. 06. 11 21:53, hamster wrote:

Le 30/06/2011 21:07, ad...@partir-en-vtt.com a écrit :

Bonsoir,

Concernant les rendus, je pense qu'il faudrait en priorité :

-Une couche sur les courbes de niveau avec étiquette
-Une couche avec l'ombrage du relief


- une couche avec un degrade en fonction de l'altitude

l'ombrage du relief donne une impression visuelle saisissante, mais 
trompeuse : on y voit bien les pentes qui sortent en plus sombre et 
assez mal celles qui sortent en plus clair
par exemple un plateau traverse par une vallee apparai facilement 
comme le bord d'un plateau avec une plaine a son pied, on voit bien la 
descente du plateau dans la vallee mais mal la remontee de la vallee 
au plateau en face

de plus ca ne permet pas de voir a quelle altitude est un point
Oui, sur mon rendu ombré j'ai fait en sorte de tout gommer sur les 
versants ouest et jusqu'aux plaines: c'est encore le meilleur moyen pour 
ne pas faire une carte 'grisouille'. C'est joli, mais on a peu d'infos.


on pourrait supperposer l'ombrage aux courbes de niveau, mais suivre 
les courbes de niveau en zone urbaine, au milieu des rues, POI et 
batiments, est un cauchemar


le degrade en fonction de l'altitude est peut etre moins joli, mais 
plus fonctionnel (ce qui n'empeche pas de faire aussi les autres)
Sauf si on colore à la manière du rendu de Sly, là, c'est joli! Et pour 
la précision, à part les courbes de niveaux qui elles sont directement 
chiffrées ...

Yves


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

Re: [OSM-talk-fr] Salut et encouragement pour Camille obligée de quitter Ecrans.fr

[Ab_fab]

Bonsoir,

Je m'associe à Christian pour souhaiter bon vent à Camille.
J'ai eu le plaisir de découvrir OSM par le biais de sa série d'articles de
l'été 2009, et depuis l'intérêt n'est jamais redescendu, loin s'en faut.
Bon, ma copine aurait bien deux mots à lui dire, mais ça c'est une autre
histoire ;-)

A noter, deux articles de Camille demain qui parlent, je vous le donne en
mille ... d'OpenStreetMap !
http://www.liberation.fr/medias/01012346513-les-geants-du-web-seduits-par-les-amateurs
http://www.liberation.fr/medias/01012346512-openstreetmap-le-wiki-distribue-les-cartes

Le 30 juin 2011 22:00, Christian Rogel  a
écrit :

> Camille Gévaudan s'était acquis la gratitude de la communauté OSM
> francophone par sa série de 6 articles sur Ecrans.fr, un site appartenant au
> quotidien parisien Libération.
> Son contrat à durée déterminée s'arrête aujourd'hui et ne pourrait être
> renouvelé avant trois mois pour des raisons juridiques.
> Elle avait elle-même cherché à comprendre les outils OSM pour faire le plan
> de sa ville de Lorraine et nous avait demandé notre aide.
> Nous étions plusieurs à avoir accepté de voir nos avis sur OSM reproduits
> dans un de ses articles.
> Je crois que nous pouvons lui dire un grand merci et lui souhaiter un
> avenir radieux dans sa profession de journaliste numérique.
>
> Peut-être, à bientôt, Camille,
>
>
> Christian
>
>
>
>
>
>
> __**_
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.**org/listinfo/talk-fr
>



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

Re: [OSM-talk-fr] cadastre-fr, un soucis sur JOSM ?

[Nicolas Frery]

Le 30/06/2011 22:14, Vincent de Chateau-Thierry a écrit :
> Ce scandale :-) a été signalé il y a peu sur le fil qui commence ici :
> http://lists.openstreetmap.org/pipermail/talk-fr/2011-June/033542.html
> 
> vincent

Pour une fois qu'un sujet commençant par « forum: » aurait plus
m'intérésser, je ne le lis pas...

Merci ;)

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

Re: [OSM-talk-fr] cadastre-fr, un soucis sur JOSM ?

[Vincent de Chateau-Thierry]

Bonsoir,

Le 30/06/2011 21:45, Nicolas FRERY a écrit :


Je viens de mettre à jour les plugins de JOSM, depuis il m'est
impossible de charger une commune au format raster !

J'ai le droit à un beau « XXX n'a pas été trouvé ou n'est pas disponible
», et ceux pour toutes les communes !

POST
numerovoie=&indiceRepetition=&nomvoie=&lieuDit=&ville=VIREY+SOUS+BAR&codePostal=&codeDepartement=010&nbResultatParPage=10&x=0&y=0
GET
http://www.cadastre.gouv.fr/scpc/listerFeuillesParcommune.do?keepVolatileSession=&offset=2000
Layer VIREY SOUS BAR destroyed

Quand je vais sur le lien toutes les feuilles sont pourtant listée et
accessible depuis le nivagteur..



Ce scandale :-) a été signalé il y a peu sur le fil qui commence ici :
http://lists.openstreetmap.org/pipermail/talk-fr/2011-June/033542.html

vincent

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

Re: [OSM-talk-fr] Serveur mutualisé pour rendu du relief

[Romain MEHUT]

Le 30 juin 2011 20:03, yvecai  a écrit :

> Celà vaut le coup d'ouvrir un fil dédié, vu que ce sujet du relief revient
> de tant à autre par ici.
>
> Parmi les rendus cités, citons: (rajoutez si j'en oublie)
> * un layer contour transparent
> * un layer 'hillshade' transparent
> * un layer 'relief-coloring'
> * une combinaison de ceux-là (finalement, ca peut juste être un script
> additionnel)
> * un layer landuse OSM
>
> Mais pour celà, il faut:
> * Un plan serveur
> * Un plan hébergement
> Une souscription? Un mécène? Une idée? A part monter une asso (c'est en
> cours pour OSM, mais à priori un serveur de relief n'a pas grand chose à
> voir avec OSM), quelqu'un saurait comment mutualiser 'light'?
>
> Puis ensuite:
> * Définir les styles par consensus (ouille)
> * Choisir la source:
>  - SRTM, domaine public mais un peu juste pour la couverture mondiale.
>  - Aster, plus complet, mais conditions d'obtention et d'utilisations
> bizarres, non-commercial.
> * Que faire des 'voids'
>
> Sur le plan technique:
> * Dimensionnement du serveur
> Pour donner une idée: http://tile.opencyclemap.org/**
> munin/localdomain/localhost.**localdomain/index.html#munin
> OpenCycleMap sort jusqu'à 40Mb/s / 4Metatiles/s
>

Remarque peut être naïve mais y aurait pas moyen d'aider tout simplement le
créateur d'Opencyclemap pour que celui-ci soit à jour vis à vis des données
d'OSM?


> OpenPisteMap à servi ~100Go de tuiles au mois de Janvier.
> * Qu'est-ce qui est en cache?
> * Quoi sert les tuiles?
>
> Yves
> __**_
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.**org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Salut et encouragement pour Camille obligée de quitter Ecrans.fr

[Ab_fab]

C'est Sarrebourg
http://www.ecrans.fr/Les-routards-du-web-3-Sur-la-route,7749.html

Le 30 juin 2011 22:08, Romain MEHUT  a écrit :

> En tant que Lorrain (d'adoption), je peux savoir quelle est la ville
> lorraine en question ?
>
> Romain
>
> Le 30 juin 2011 22:00, Christian Rogel a 
> écrit :
>
> Camille Gévaudan s'était acquis la gratitude de la communauté OSM
>> francophone par sa série de 6 articles sur Ecrans.fr, un site appartenant au
>> quotidien parisien Libération.
>> Son contrat à durée déterminée s'arrête aujourd'hui et ne pourrait être
>> renouvelé avant trois mois pour des raisons juridiques.
>> Elle avait elle-même cherché à comprendre les outils OSM pour faire le
>> plan de sa ville de Lorraine et nous avait demandé notre aide.
>> Nous étions plusieurs à avoir accepté de voir nos avis sur OSM reproduits
>> dans un de ses articles.
>> Je crois que nous pouvons lui dire un grand merci et lui souhaiter un
>> avenir radieux dans sa profession de journaliste numérique.
>>
>> Peut-être, à bientôt, Camille,
>>
>> Christian
>>
>> __**_
>> 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
>
>


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

Re: [OSM-talk-fr] Salut et encouragement pour Camille obligée de quitter Ecrans.fr

[Romain MEHUT]

En tant que Lorrain (d'adoption), je peux savoir quelle est la ville
lorraine en question ?

Romain

Le 30 juin 2011 22:00, Christian Rogel  a
écrit :

> Camille Gévaudan s'était acquis la gratitude de la communauté OSM
> francophone par sa série de 6 articles sur Ecrans.fr, un site appartenant au
> quotidien parisien Libération.
> Son contrat à durée déterminée s'arrête aujourd'hui et ne pourrait être
> renouvelé avant trois mois pour des raisons juridiques.
> Elle avait elle-même cherché à comprendre les outils OSM pour faire le plan
> de sa ville de Lorraine et nous avait demandé notre aide.
> Nous étions plusieurs à avoir accepté de voir nos avis sur OSM reproduits
> dans un de ses articles.
> Je crois que nous pouvons lui dire un grand merci et lui souhaiter un
> avenir radieux dans sa profession de journaliste numérique.
>
> Peut-être, à bientôt, Camille,
>
> Christian
>
> __**_
> 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] Salut et encouragement pour Camille obligée de quitter Ecrans.fr

[Christian Rogel]

Camille Gévaudan s'était acquis la gratitude de la communauté OSM 
francophone par sa série de 6 articles sur Ecrans.fr, un site 
appartenant au quotidien parisien Libération.
Son contrat à durée déterminée s'arrête aujourd'hui et ne pourrait être 
renouvelé avant trois mois pour des raisons juridiques.
Elle avait elle-même cherché à comprendre les outils OSM pour faire le 
plan de sa ville de Lorraine et nous avait demandé notre aide.
Nous étions plusieurs à avoir accepté de voir nos avis sur OSM 
reproduits dans un de ses articles.
Je crois que nous pouvons lui dire un grand merci et lui souhaiter un 
avenir radieux dans sa profession de journaliste numérique.


Peut-être, à bientôt, Camille,


Christian






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

Re: [OSM-talk-fr] Serveur mutualisé pour rendu du relief

[hamster]

Le 30/06/2011 21:07, ad...@partir-en-vtt.com a écrit :

Bonsoir,

Je trouve cette idée séduisante que de créer un fond relief sur OSM d'autant 
plus que cela pourrait me servir pour mes randonnées. D'ailleurs ce fond 
remplacerait du coup le fond relief de google qui est ajouté à mon module 
cartographique.

J'ai essayé de regarder du côté des données ASTER et je pense que l'on peut 
réussir à générer une base de toutes les données du monde (je fait un essai sur 
la france entière en ce moment). Ce qui est sûr, c'est que cela va nécessiter 
un gros traitement à l'origine mais une fois que ce sera fait ce sera fait ! La 
question est est-ce que les données ASTER sont compatibles avec OSM ?

Concernant les rendus, je pense qu'il faudrait en priorité :

-Une couche sur les courbes de niveau avec étiquette
-Une couche avec l'ombrage du relief


- une couche avec un degrade en fonction de l'altitude

l'ombrage du relief donne une impression visuelle saisissante, mais 
trompeuse : on y voit bien les pentes qui sortent en plus sombre et 
assez mal celles qui sortent en plus clair
par exemple un plateau traverse par une vallee apparai facilement comme 
le bord d'un plateau avec une plaine a son pied, on voit bien la 
descente du plateau dans la vallee mais mal la remontee de la vallee au 
plateau en face

de plus ca ne permet pas de voir a quelle altitude est un point

on pourrait supperposer l'ombrage aux courbes de niveau, mais suivre les 
courbes de niveau en zone urbaine, au milieu des rues, POI et batiments, 
est un cauchemar


le degrade en fonction de l'altitude est peut etre moins joli, mais plus 
fonctionnel (ce qui n'empeche pas de faire aussi les autres)


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

[OSM-talk-fr] cadastre-fr, un soucis sur JOSM ?

[Nicolas FRERY]

Bonjour,

Je viens de mettre à jour les plugins de JOSM, depuis il m'est
impossible de charger une commune au format raster !

J'ai le droit à un beau « XXX n'a pas été trouvé ou n'est pas disponible
», et ceux pour toutes les communes !

POST
numerovoie=&indiceRepetition=&nomvoie=&lieuDit=&ville=VIREY+SOUS+BAR&codePostal=&codeDepartement=010&nbResultatParPage=10&x=0&y=0
GET
http://www.cadastre.gouv.fr/scpc/listerFeuillesParcommune.do?keepVolatileSession=&offset=2000
Layer VIREY SOUS BAR destroyed

Quand je vais sur le lien toutes les feuilles sont pourtant listée et
accessible depuis le nivagteur..

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

Re: [OSM-talk-fr] Serveur mutualisé pour rendu du relief

[hamster]

Le 30/06/2011 21:09, yvecai a écrit :

est-ce que c'est un degrade de couleurs en fonction de l'altitude ?

Super, je cherchais des équivalents en français mais j'ai laissé tomber:)


ben... tu repond pas a mes questions
je suis pas sur du tout de mes traductions


si oui, est-ce que le meme en niveaux de gris ou en niveaux d'une
seule couleur aurait un interet ?

Pas sûr, faudrait voir un exemple mais je vois pas trop l'interêt
graphique de la chose. Finalement ça revient à sortir des tuiles avec
les données d'altitude sur 8 bits. Peut-être utile pour un rendu coté
client?


faire un rendu qui se supperpose pas trop mal sur un fond arc en ciel 
c'est super dur
quelle que soit la couleur que tu choisisse pour dessiner les elements 
(routes, batiments, eau, etc...) il y a toujours des zones ou ca se voit 
pas parce que de la meme couleur que le fond
finalement la seule possibite qu'il reste c'est de tout dessiner en 
noir, et c'est pas terrible, exemple :

http://www.cartes-topographiques.fr/?lt=48.803641&lg=2.328559&zm=15&tp=terrain

si le relief est fait par degrade d'une seule couleur, il te suffit 
d'eviter de trop t'approcher de cette couleur pour le rendu des objets


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

Re: [OSM-talk-fr] Rendu coté navigateur ( était :OSM destiné pour un besoin de =?iso-8859-15?q?_=3D=3Fiso-8859-15=3Fq=3F=5Frandonn=3DE9e=3F=3D?=)

[admin]

Il faut la noter celle-ci :)

Le 30/06/2011 17:47, Pieren a écrit :
> Comment gère-t-on les grandes surfaces côté serveur (forêts, lacs) ou 
> côté client (lignes de côte pour l'océan) ?
Le plus simple pour gérer les grande surfaces, c'est encore côté 
caissière ;-)
--
FrViPofm

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



-- 
Loïc et Flo.

Créateurs et administrateurs de www.partir-en-vtt.com.

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

Re: [OSM-talk-fr] Serveur mutualisé pour rendu du relief

[admin]

La création des courbes de niveau pour la France entière (un peu plus) avec une 
fusion des courbes par la hauteur et un lissage avec l'algorithme de McMaster à 
pris 4 heures 22 minutes. Le pc utilisé était à base de xeon quad core et 12 go 
de ram !

Quelqu'un serait capable d'extrapoler pour calculer le temps que cela prendrai 
pour le monde entier ?


J'ai fait un essai avec envoi dans postgis, et cela à généré environ 58 
lignes dans la table.

Si quelqu'un veut le backup qu'il se manifeste, je peux le faire remonter 
quelque part.

Sportivement, Loïc & Flo
www.partir-en-vtt.com



Ton interrogation est tout à fait justifié mais si se sont des personnes avec 
un revenu fixe qui financent le projet, je ne pense pas que 5 à 10 € par mois 
soit insurmontable sur la durée.

J'ai déjà vécu des cas comme celui-là où cela ne fonctionnait pas car il y 
avait un manque de sérieux. Je ne pense pas que les personnes de la liste OSM 
ne soient pas sérieux !

Après cela peut être comme cela au départ, puis après, lorsque le service web 
sera diffusé, peut être pourrons nous trouver un mécène ;-)

Sportivement, Loïc & Flo
www.partir-en-vtt.com



On 30. 06. 11 21:07, ad...@partir-en-vtt.com wrote:
> Bonsoir,
>
> Je trouve cette idée séduisante que de créer un fond relief sur OSM d'autant 
plus que cela pourrait me servir pour mes randonnées. D'ailleurs ce fond 
remplacerait du coup le fond relief de google qui est ajouté à mon module 
cartographique.
>
> J'ai essayé de regarder du côté des données ASTER et je pense que l'on peut 
réussir à générer une base de toutes les données du monde (je fait un essai sur 

la france entière en ce moment). Ce qui est sûr, c'est que cela va nécessiter 
un gros traitement à l'origine mais une fois que ce sera fait ce sera fait ! La 

question est est-ce que les données ASTER sont compatibles avec OSM ?
A priori, pas fait pour une utilisation commerciale. Il faudrait 
probablement trouver un accord avec eux pour lancer un truc important. 
J'ai l'impression que les conditions d'utilisation sont floues parce 
qu'il s'agit de données provenant d'origine variées.
> Concernant les rendus, je pense qu'il faudrait en priorité :
>
> -Une couche sur les courbes de niveau avec étiquette
> -Une couche avec l'ombrage du relief
+1
> Ensuite concernant le serveur je pense qu'un dédié de chez Dedibox le classic 

à 30 € hors taxe devrait faire l'affaire. Il faudrait juste estimer la capacité 

du disque car là c'est un 500 go en raid 1 (duplication).
>
> Concernant le mode de financement, je propose un appel aux volontaires. Je 
suis près à mettre de ma poche entre 5 et 10 € par mois si je suis intégré au 
projet.
>
La question dans ce cas de figure est comment gérer l'abonnement à 
dedibox? Quelqu'un qui récupère les sous et paye en son nom ne me parait 
pas une solution très pérenne.

Yves

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



-- 
Loïc et Flo.

Créateurs et administrateurs de www.partir-en-vtt.com.

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



-- 
Loïc et Flo.

Créateurs et administrateurs de www.partir-en-vtt.com.

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

Re: [OSM-talk-fr] Rendu coté navigateur ( était :OSM destiné pour un besoin de =?iso-8859-15?q?_=3D=3Fiso-8859-15=3Fq=3F=5Frandonn=3DE9e=3F=3D?=)

[Vincent Pottier]

Le 30/06/2011 17:47, Pieren a écrit :
Comment gère-t-on les grandes surfaces côté serveur (forêts, lacs) ou 
côté client (lignes de côte pour l'océan) ?
Le plus simple pour gérer les grande surfaces, c'est encore côté 
caissière ;-)

--
FrViPofm

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

Re: [OSM-talk-fr] Serveur mutualisé pour rendu du relief

[admin]

Ton interrogation est tout à fait justifié mais si se sont des personnes avec 
un revenu fixe qui financent le projet, je ne pense pas que 5 à 10 € par mois 
soit insurmontable sur la durée.

J'ai déjà vécu des cas comme celui-là où cela ne fonctionnait pas car il y 
avait un manque de sérieux. Je ne pense pas que les personnes de la liste OSM 
ne soient pas sérieux !

Après cela peut être comme cela au départ, puis après, lorsque le service web 
sera diffusé, peut être pourrons nous trouver un mécène ;-)

Sportivement, Loïc & Flo
www.partir-en-vtt.com



On 30. 06. 11 21:07, ad...@partir-en-vtt.com wrote:
> Bonsoir,
>
> Je trouve cette idée séduisante que de créer un fond relief sur OSM d'autant 
plus que cela pourrait me servir pour mes randonnées. D'ailleurs ce fond 
remplacerait du coup le fond relief de google qui est ajouté à mon module 
cartographique.
>
> J'ai essayé de regarder du côté des données ASTER et je pense que l'on peut 
réussir à générer une base de toutes les données du monde (je fait un essai sur 
la france entière en ce moment). Ce qui est sûr, c'est que cela va nécessiter 
un gros traitement à l'origine mais une fois que ce sera fait ce sera fait ! La 
question est est-ce que les données ASTER sont compatibles avec OSM ?
A priori, pas fait pour une utilisation commerciale. Il faudrait 
probablement trouver un accord avec eux pour lancer un truc important. 
J'ai l'impression que les conditions d'utilisation sont floues parce 
qu'il s'agit de données provenant d'origine variées.
> Concernant les rendus, je pense qu'il faudrait en priorité :
>
> -Une couche sur les courbes de niveau avec étiquette
> -Une couche avec l'ombrage du relief
+1
> Ensuite concernant le serveur je pense qu'un dédié de chez Dedibox le classic 
à 30 € hors taxe devrait faire l'affaire. Il faudrait juste estimer la capacité 
du disque car là c'est un 500 go en raid 1 (duplication).
>
> Concernant le mode de financement, je propose un appel aux volontaires. Je 
suis près à mettre de ma poche entre 5 et 10 € par mois si je suis intégré au 
projet.
>
La question dans ce cas de figure est comment gérer l'abonnement à 
dedibox? Quelqu'un qui récupère les sous et paye en son nom ne me parait 
pas une solution très pérenne.

Yves

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



-- 
Loïc et Flo.

Créateurs et administrateurs de www.partir-en-vtt.com.

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

Re: [OSM-talk-fr] Serveur mutualisé pour rendu du relief

[yvecai]

On 30. 06. 11 21:07, ad...@partir-en-vtt.com wrote:

Bonsoir,

Je trouve cette idée séduisante que de créer un fond relief sur OSM d'autant 
plus que cela pourrait me servir pour mes randonnées. D'ailleurs ce fond 
remplacerait du coup le fond relief de google qui est ajouté à mon module 
cartographique.

J'ai essayé de regarder du côté des données ASTER et je pense que l'on peut 
réussir à générer une base de toutes les données du monde (je fait un essai sur 
la france entière en ce moment). Ce qui est sûr, c'est que cela va nécessiter 
un gros traitement à l'origine mais une fois que ce sera fait ce sera fait ! La 
question est est-ce que les données ASTER sont compatibles avec OSM ?
A priori, pas fait pour une utilisation commerciale. Il faudrait 
probablement trouver un accord avec eux pour lancer un truc important. 
J'ai l'impression que les conditions d'utilisation sont floues parce 
qu'il s'agit de données provenant d'origine variées.

Concernant les rendus, je pense qu'il faudrait en priorité :

-Une couche sur les courbes de niveau avec étiquette
-Une couche avec l'ombrage du relief

+1

Ensuite concernant le serveur je pense qu'un dédié de chez Dedibox le classic à 
30 € hors taxe devrait faire l'affaire. Il faudrait juste estimer la capacité 
du disque car là c'est un 500 go en raid 1 (duplication).

Concernant le mode de financement, je propose un appel aux volontaires. Je suis 
près à mettre de ma poche entre 5 et 10 € par mois si je suis intégré au projet.

La question dans ce cas de figure est comment gérer l'abonnement à 
dedibox? Quelqu'un qui récupère les sous et paye en son nom ne me parait 
pas une solution très pérenne.


Yves

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

Re: [OSM-talk-fr] Serveur mutualisé pour rendu du relief

[yvecai]

On 30. 06. 11 20:35, hamster wrote:

Le 30/06/2011 20:03, yvecai a écrit :

pour ceux qui sont comme moi trop nuls en anglais :


Parmi les rendus cités, citons: (rajoutez si j'en oublie)
* un layer contour transparent


est-ce que c'est "courbes de niveau" ?


* un layer 'hillshade' transparent


est-ce que c'est "ombre" ?


* un layer 'relief-coloring'


est-ce que c'est un degrade de couleurs en fonction de l'altitude ?

Super, je cherchais des équivalents en français mais j'ai laissé tomber:)
si oui, est-ce que le meme en niveaux de gris ou en niveaux d'une 
seule couleur aurait un interet ?
Pas sûr, faudrait voir un exemple mais je vois pas trop l'interêt 
graphique de la chose. Finalement ça revient à sortir des tuiles avec 
les données d'altitude sur 8 bits. Peut-être utile pour un rendu coté 
client?


Yves


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

Re: [OSM-talk-fr] Serveur mutualisé pour rendu du relief

[admin]

Bonsoir, 

Je trouve cette idée séduisante que de créer un fond relief sur OSM d'autant 
plus que cela pourrait me servir pour mes randonnées. D'ailleurs ce fond 
remplacerait du coup le fond relief de google qui est ajouté à mon module 
cartographique.

J'ai essayé de regarder du côté des données ASTER et je pense que l'on peut 
réussir à générer une base de toutes les données du monde (je fait un essai sur 
la france entière en ce moment). Ce qui est sûr, c'est que cela va nécessiter 
un gros traitement à l'origine mais une fois que ce sera fait ce sera fait ! La 
question est est-ce que les données ASTER sont compatibles avec OSM ?

Concernant les rendus, je pense qu'il faudrait en priorité :

-Une couche sur les courbes de niveau avec étiquette 
-Une couche avec l'ombrage du relief

Ensuite concernant le serveur je pense qu'un dédié de chez Dedibox le classic à 
30 € hors taxe devrait faire l'affaire. Il faudrait juste estimer la capacité 
du disque car là c'est un 500 go en raid 1 (duplication).

Concernant le mode de financement, je propose un appel aux volontaires. Je suis 
près à mettre de ma poche entre 5 et 10 € par mois si je suis intégré au projet.

Sportivement, Loïc & Flo
www.partir-en-vtt.com




Celà vaut le coup d'ouvrir un fil dédié, vu que ce sujet du relief 
revient de tant à autre par ici.

Parmi les rendus cités, citons: (rajoutez si j'en oublie)
* un layer contour transparent
* un layer 'hillshade' transparent
* un layer 'relief-coloring'
* une combinaison de ceux-là (finalement, ca peut juste être un script 
additionnel)
* un layer landuse OSM

Mais pour celà, il faut:
* Un plan serveur
* Un plan hébergement
Une souscription? Un mécène? Une idée? A part monter une asso (c'est en 
cours pour OSM, mais à priori un serveur de relief n'a pas grand chose à 
voir avec OSM), quelqu'un saurait comment mutualiser 'light'?

Puis ensuite:
* Définir les styles par consensus (ouille)
* Choisir la source:
   - SRTM, domaine public mais un peu juste pour la couverture mondiale.
   - Aster, plus complet, mais conditions d'obtention et d'utilisations 
bizarres, non-commercial.
* Que faire des 'voids'

Sur le plan technique:
* Dimensionnement du serveur
Pour donner une idée: 
http://tile.opencyclemap.org/munin/localdomain/localhost.localdomain/index.html#
munin
OpenCycleMap sort jusqu'à 40Mb/s / 4Metatiles/s
OpenPisteMap à servi ~100Go de tuiles au mois de Janvier.
* Qu'est-ce qui est en cache?
* Quoi sert les tuiles?

Yves


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



-- 
Loïc et Flo.

Créateurs et administrateurs de www.partir-en-vtt.com.

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

Re: [OSM-talk-fr] Serveur mutualisé pour rendu du relief

[hamster]

Le 30/06/2011 20:03, yvecai a écrit :

pour ceux qui sont comme moi trop nuls en anglais :


Parmi les rendus cités, citons: (rajoutez si j'en oublie)
* un layer contour transparent


est-ce que c'est "courbes de niveau" ?


* un layer 'hillshade' transparent


est-ce que c'est "ombre" ?


* un layer 'relief-coloring'


est-ce que c'est un degrade de couleurs en fonction de l'altitude ?
si oui, est-ce que le meme en niveaux de gris ou en niveaux d'une seule 
couleur aurait un interet ?


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

[OSM-talk-fr] Serveur mutualisé pour rendu du relief

[yvecai]

Celà vaut le coup d'ouvrir un fil dédié, vu que ce sujet du relief 
revient de tant à autre par ici.


Parmi les rendus cités, citons: (rajoutez si j'en oublie)
* un layer contour transparent
* un layer 'hillshade' transparent
* un layer 'relief-coloring'
* une combinaison de ceux-là (finalement, ca peut juste être un script 
additionnel)

* un layer landuse OSM

Mais pour celà, il faut:
* Un plan serveur
* Un plan hébergement
Une souscription? Un mécène? Une idée? A part monter une asso (c'est en 
cours pour OSM, mais à priori un serveur de relief n'a pas grand chose à 
voir avec OSM), quelqu'un saurait comment mutualiser 'light'?


Puis ensuite:
* Définir les styles par consensus (ouille)
* Choisir la source:
  - SRTM, domaine public mais un peu juste pour la couverture mondiale.
  - Aster, plus complet, mais conditions d'obtention et d'utilisations 
bizarres, non-commercial.

* Que faire des 'voids'

Sur le plan technique:
* Dimensionnement du serveur
Pour donner une idée: 
http://tile.opencyclemap.org/munin/localdomain/localhost.localdomain/index.html#munin

OpenCycleMap sort jusqu'à 40Mb/s / 4Metatiles/s
OpenPisteMap à servi ~100Go de tuiles au mois de Janvier.
* Qu'est-ce qui est en cache?
* Quoi sert les tuiles?

Yves


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

Re: [OSM-talk-fr] Rendu coté navigateur ( était :OSM destiné pour un besoin de =?iso-8859-15?q?_randonn=E9e?=)

[Pierre-Alain Dorange]

Pieren  wrote:

> Cette solution ne marche que pour de l'expérimental, à faible échelle et à
> faible nombre de clients. Parce qu'au lieu de calculer le rendu une fois
> pour toutes, on le fait pour chaque client et à chaque visite (il y a des
> optimisations possibles). Vous allez me dire "on s'en fout, c'est délocalisé
> chez le client". Oui, mais le client va faire une requête bdd pour chaque
> tuile. Le serveur qui fournit les données va rapidement s'écrouler face à la
> demande de requêtes, celles-ci augmentant proportionnellement avec le nombre
> de clients.

A moyen terme la solution sera probablement un mixte entre les 2
extrèmes (tuile images fixes vs requete vecteur et rendu local).
La solution présentée ressemble à ça avec ces "tuiles vecteurs"...

Tout comme l'informatique classique commence a jouer de l'oscillation
entre le modèle central (serveur lourd et client léger modèle des années
70 et qui revient doucement) et le modèle local (client lourd et serveur
léger, je schématise) ; il est probable qu'il faille inventer des
solutions mixtes, c'est souvent là que se trouve les vrais solutions...
-- 
Pierre-Alain Dorange
OSM experiences : 


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

Re: [OSM-talk-fr] Jeu de données ASTER => conversion en courbe de niveau

[yvecai]

J'ai déjà ça pour une bonne partie de l'europe, mais je souhaiterais passer
world wide pour mon rendu et je me heurte a des problèmes soit de
méthodologie, soit de performance machine.
Sans compter que les données ASTER sont à télécharger morceaux par morceaux et
c'est un peu long.

J'en suis là si ça peut gagner du temps :
19G amerique-nord
21G amerique-sud
90G europe
22G oceanie

J'avais lancé une demande de téléchargement, mais j'ai jamais eu de réponse.
C'est un peu lourd leur méthode de distribution ...
Yves

Mais je me heurte au problème des îles, de l'asie et du recouvrement des
dalles que j'ai déjà récupéré.
J'avais rêvé fusionner tout ça en un gros geotiff de la terre de 400 Go pour
lancer ensuite du gdal_contours et du hillshading, hillcoloring dessus, mais
je crois que ça va pas le faire.
Faut que je re-réfléchisse au problème pour faire ça tuile par tuile

gdalbuildvrt permet de faire un fichier XML liant plusieurs tiffs 
ensemble. Ce fichier VRT est ensuite utilisable pour pas mal d'outils gdal.
Ensuite, probable que gdal2tile est modifiable pour créer des contours, 
je ne sais pas. Si çà peut donner des idées, ci-joint le script qui m'a 
généré le hillshade SRTM. Bon, je pense qu'il y a mieux à faire pour les 
effets de bords, je ne me suis préoccuppé que d'avoir un rendu 
graphiquement satisfaisant.


Yves






script2.sh
Description: Bourne shell script
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] tag pour un composteur collectif

[Romain MEHUT]

Je pensais trouver la réponse au tag d'un composteur collectif en allant
voir du côté de la Carte OuVerte de Rennes. Il y a en effet, un POI sur les
composteurs collectifs:
http://rennes.carte-ouverte.org/?zoom=17&lat=48.1123&lon=-1.66094&layers=BTT&checked_categories=65&display_submited=false¤t_feature=725(exemple
près du Parc Oberthur). Mais dans OSM, il n'y a aucun node
correspondant à cet endroit. Quand on clique sur le logo, on apprend que ces
composteurs sont gérés par la coopérative Eisenia. Et une fois sur leur
site, on trouve une carte Google (aucune mention de la Carte Ouverte soit
dit en passant) avec toutes les installations.

Sur le coup je suis vraiment déçu. Moi qui prenait Rennes et la Carte
OuVerte comme un exemple, là on constate que cette carte ne contient pas
l'ensemble des informations de son territoire... Et on n'est pas plus avancé
sur le tag du compostage collectif...

Romain

Le 27 juin 2011 10:54, Romain MEHUT  a écrit :

> Bonjour,
>
> Je n'ai pas la réponse mais le sujet m'intéresse également.
>
> J'en profite pour signaler le site de l'association Compostri de Nantes qui
> promeut le compostage collectif et qui propose une carte de localisation des
> composteurs.
> http://compostri.ouvaton.org/
>
> Je n'ai pas encore pris le temps de les contacter pour leur suggérer de
> profiter de la précision d'OSM. On ne peut pas être sur tous les fronts!
> Est-ce que du coup tu (ou un autre volontaire) souhaiterais les
> sensibiliser?
>
> Romain
>
> Le 27 juin 2011 09:33, Christophe Savigny  a
> écrit :
>
>> **
>> bonjour,
>>
>> je cherche un tag pour un compost collectif de quartier. J'ai pensé à
>> amenity=recycling:garden_waste, c'est bien ça ?
>>
>> bonne journée
>>
>> ___
>> 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] Association OpenStreetMap France !

[Jean-Francois Nifenecker]

Le 28/06/2011 19:56, RatZilla$ a écrit :


Bonnes Nouvelles les ami[e]s,


\o/



Certains contributeurs,  m'ont relancé sur le montage de
l'association. Je remonte donc les dernières avancées.


merci pour ces infos et pour tout le boulot que tu as abattu.


Au Charbon ;-)


vi.

Je serai (aussi) aux RMLL (à partir de dimanche soir). Une rencontre sur 
ce sujet pourrait être utile.


Amitiés,
--
Jean-Francois Nifenecker, Bordeaux

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

Re: [OSM-talk-fr] Tagger les entrées de métro

[Vincent-Xavier JUMEL]

Le 27 juin à 13:24 Pieren a écrit
> 2011/6/27 Vincent-Xavier JUMEL 
> 
> > Par ailleurs, je mets en garde les personnes (j'en ai déjà rencontré)
> > qui seraient tentées, même dans un but louable de cartographier les
> > couloirs du métro. Cela me semble risquer.
> >
> >
> Oui ou les quais aussi. En souterrain, c'est du pifométrique qui en plus
> dérange fortement ceux qui éditent en surface (comme moi).
> Le tag d'entrée de métro, c'est railway=subway_entrance non ? En tout cas,
> c'est comme ça que j'en ai taggué un grand nombre (et non
> "railway_entrance").
Pardon, je viens de prendre le temps de revérifier, et tu avais
raison. Ça correspond aux quelques unes que j'avais fait.

> Il reste encore beaucoup à faire dans ce domaine comme distinguer les
> bouches d'entrée, sortie, les deux, les escalators, la connexion aux autres
> voies pédestres, l'accessibilité, sens des escaliers, zones avec ou sans
> titres de transport (passages publics souterrains, etc...
> 
Une chose qui n'est visiblement pas faite, ou alors, c'est que j'ai
mal compris quelque choses, c'est comment indiquer que telle
subway_entrance permet d'accéder à telle railway_station ?

Peut-être une relation pourrait résoudre ce problème ?

-- 
Vincent-Xavier JUMEL GPG Id: 0x2E14CE70 http://thetys-retz.net

Rejoignez les 5500 adhérents de l'April http://www.april.org/adherer
Parinux, logiciel libre à Paris : http://www.parinux.org

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

Re: [OSM-talk-fr] Données ouverte sur les transports et plans de ville

[Ab_fab]

Oui, mais cela existe déjà en fait, depuis plus d'un an !

http://lists.openstreetmap.org/pipermail/talk-fr/2010-June/022660.html

http://blog.isokron.com/category/cartes-isochrones
"Ces cartes sont obtenues en temps réel en se servant des données
OpenStreetMap . "

http://www.rue89.com/2011/06/12/on-se-retrouve-ou-la-reponse-est-sur-la-carte-isokron-208972

Après des débuts très parisiens, ils ont aussi phosphoré sur Rennes à la
suite de la liberation des données


Le 30 juin 2011 18:05, Christian Rogel  a
écrit :

> Dans le magazine en ligne OWNI, Andréa Fradin a publié une description du
> projet Mapnificent réalisé par un Berlinois, Stefan Wehrmeyer.
> Dans les villes où les données sur le transport public ont été libérées, il
> peut réaliser des isochrones sur un fond de carte Google.
> Voi ici :  http://www.mapnificent.net/ et montrer
> ce qui est accessible par transport public dans un temps donné.
> Il n'y a, apparemment, que les données de Rennes et de Bordeaux qui sont
> disponibles en France.
> http://www.mapnificent.net/**rennes/#/?lat0=48.1117611&**
> lng0=-1.68026540053&t0=15&**lat=48.1117611&lng=-1.**
> 68026540053&zoom=14
> Par défaut, le délai est fixé à 15 minutes.
>
> Lire l'interview de S. Wehrmeyer :
> http://owni.fr/2011/06/13/vos-**deplacements-a-la-carte/
>
> Des idées pour avor ça sur OSM?
>
>
> Christian
>
>
>
> __**_
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.**org/listinfo/talk-fr
>



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

Re: [OSM-talk-fr] Rendu coté navigateur ( était :OSM destiné pour un besoin de =?iso-8859-15?q?_=3D=3Fiso-8859-15=3Fq=3F=5Frandonn=3DE9e=3F=3D?=)

[Ab_fab]

C'est apparemment pris en compte à la génération des tuiles (noeuds aux
limites) et pendant le rendu

"If a polygon or a line crosses a tile boundary, it should be cropped to
only contain points that lie inside or on boundary of a tile, but Kothic JS
will automatically hide edges of polygon which lie on tile boundaries."
https://github.com/kothic/kothic-js/wiki/Tiles-format

Les tuiles sont générées à partir d'une base Postgis, elle même "remplie" a
l'aide d'osm2pgsql
https://github.com/kothic/kothic-js/wiki/json_getter-setup
Donc le processus n'est finalement pas si éloigné de la fabrication de
tuiles images.

Je comprends les problèmes potentiels que tu indiques, mais je n'ai pas vu
de messages mettant en évidence ce genre de bugs dans le fil de discussion
suivant :
http://lists.openstreetmap.org/pipermail/mapcss/2011-June/000196.html


Le 30 juin 2011 17:47, Pieren  a écrit :

>  2011/6/30 Ab_fab 
>
>> J'ai la même compréhension : ce sont des tuiles vectorielles, qui doivent
>> être générées selon une "stratégie" optimisée en fonction de la demande pour
>> les zones géographiques données.
>>
>>
> Mouais. Je voudrais voir comment sont réglés les grands objets dans ce
> système. Si un ou les deux nodes d'un way ne se trouvent pas sur la tuile
> par exemple -> obligation de créer des noeuds virtuels aux limites ? Si on
> fait un way par tuile, comment on fusionne les données pour ne pas créer
> d'artefacts à l'affichage (par exemple un nom affiché sur chaque tuile) ?
> Comment gère-t-on les grandes surfaces côté serveur (forêts, lacs) ou côté
> client (lignes de côte pour l'océan) ? en utilisant les shapefiles de Mapnik
> ?
>
> Pieren
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>
>


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

[OSM-talk-fr] Données ouverte sur les transports et plans de ville

[Christian Rogel]

Dans le magazine en ligne OWNI, Andréa Fradin a publié une description 
du projet Mapnificent réalisé par un Berlinois, Stefan Wehrmeyer.
Dans les villes où les données sur le transport public ont été libérées, 
il peut réaliser des isochrones sur un fond de carte Google.

Voi ici :  http://www.mapnificent.net/ et montrer
ce qui est accessible par transport public dans un temps donné.
Il n'y a, apparemment, que les données de Rennes et de Bordeaux qui sont 
disponibles en France.

http://www.mapnificent.net/rennes/#/?lat0=48.1117611&lng0=-1.68026540053&t0=15&lat=48.1117611&lng=-1.68026540053&zoom=14
Par défaut, le délai est fixé à 15 minutes.

Lire l'interview de S. Wehrmeyer :
http://owni.fr/2011/06/13/vos-deplacements-a-la-carte/

Des idées pour avor ça sur OSM?


Christian



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

Re: [OSM-talk-fr] Rendu coté navigateur ( était :OSM destiné pour un besoin de =?iso-8859-15?q?_=3D=3Fiso-8859-15=3Fq=3F=5Frandonn=3DE9e=3F=3D?=)

[Pieren]

2011/6/30 Ab_fab 

> J'ai la même compréhension : ce sont des tuiles vectorielles, qui doivent
> être générées selon une "stratégie" optimisée en fonction de la demande pour
> les zones géographiques données.
>
>
Mouais. Je voudrais voir comment sont réglés les grands objets dans ce
système. Si un ou les deux nodes d'un way ne se trouvent pas sur la tuile
par exemple -> obligation de créer des noeuds virtuels aux limites ? Si on
fait un way par tuile, comment on fusionne les données pour ne pas créer
d'artefacts à l'affichage (par exemple un nom affiché sur chaque tuile) ?
Comment gère-t-on les grandes surfaces côté serveur (forêts, lacs) ou côté
client (lignes de côte pour l'océan) ? en utilisant les shapefiles de Mapnik
?

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

Re: [OSM-talk-fr] Orthophoto Tours(s) Plus en panne ?

[François Van Der Biest]

Hello,

Vu d'ici http://tms.mapspot.ge/tms/2/nonstandard/18/131614/91840.jpeg
-> http://maps.qualitystreetmap.org/tiles/ortho08/18/131614/170303.jpeg
est OK.

Le service de redirection a dû avoir quelques petits soucis durant un
instant, puisque rien ne m'a été remonté comme alerte au niveau de
qualitystreetmap.org

F.


2011/6/30 Emmanuel Dewaele :
> Bonjour,
>
> Je confirme, JOSM n'affiche pas de tuiles à ce niveau. D'ailleurs sur la
> sortie standard, il y a des messages du genre, failed loading
> 18/131614/91840
> http://tms.mapspot.ge/tms/2/nonstandard/18/131614/91840.jpeg.  Le serveur a
> du subir quelques changements. Il faut voir avec Simon, qui saura vraiment
> d'où vient le problème.
>
> A+
>
> Le 30/06/2011 12:10, cyrille giquello a écrit :
>
> Bonjour,
>
> L'imagerie "Orthophoto Tour(s) Plus" ne fonctionne plus chez moi dans
> JOSM. Est-ce de même chez vous ?
> Merci
>
>
>
> --
>
> Emmanuel Dewaele,
> Doctorant, Université de Tours, Laboratoire d'Informatique
> Ingénieur études et recherche, La Compagnie des mobilités
>
> 64, avenue Portalis
> bureau 202
> 37200 TOURS
>
> ☏ 06 26 94 94 71
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>
>

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

Re: [OSM-talk-fr] Rendu coté navigateur ( était :OSM destiné pour un besoin de =?iso-8859-15?q?_=3D=3Fiso-8859-15=3Fq=3F=5Frandonn=3DE9e=3F=3D?=)

[Ab_fab]

J'ai la même compréhension : ce sont des tuiles vectorielles, qui doivent
être générées selon une "stratégie" optimisée en fonction de la demande pour
les zones géographiques données.
Bref ce que l'on demande à des "machins" (*) qui répondent au doux nom de
Renderd ou Tirex pour des tuiles image.

Je suis d'ailleurs curieux de savoir dans quelle mesure ces outils
pourraient gérer ce genre d'objets.
C'est peut être assez transparent puisque les tuiles image suivent le même
arrangement géographique que les tuiles images.

(*) dénomination adaptée à mes connaissances en la matière
Le 30 juin 2011 14:49, sly (sylvain letuffe)  a écrit :

> On jeudi 30 juin 2011, Pieren wrote:
> > Oui, mais le client va faire une requête bdd pour chaque
> > tuile. Le serveur qui fournit les données va rapidement s'écrouler face à
> la
> > demande de requêtes, celles-ci augmentant proportionnellement avec le
> nombre
> > de clients. Alors que la solution classique avec tuiles ne nécessite cet
> > effort (requête vers la base) qu'une seule fois
>
> Mmmm, je pense que tu perçois la requête comme une lourde tâche alors que
> ça
> n'est pas forcément le cas. Il est question ici de "tuiles vectorielles"
> c'est à dire de l'ensemble des données vecteurs (utile au niveau de zoom
> demandé) présentes sur un carré fixe, défini à l'avance, pas un truc genre
> WMS ou les données sont construites à la volée. Il est envisageable, je
> pense, d'en garder une version "en cache" de la même manière que les
> serveurs
> de tuiles gardent une version image en cache et de la servir au navigateur.
> On pourrait même imaginer se passer de base de donnée pour ce cache et
> stocker
> des fichiers du syle :
> /zoom/x/y.json (.gml, .osm, ou le format qu'on aura décidé de garder à
> fournir
> au client)
>
> --
> ab_fab 
> "Il n'y a pas de pas perdus"
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Rendu coté navigateur (était: OSM destiné pour un besoin de randonnée)

[Eric Marsden]

> "sly" == sly (sylvain letuffe)  writes:

  sly> On pourrait même imaginer se passer de base de donnée pour ce cache et 
stocker 
  sly> des fichiers du syle :
  sly> /zoom/x/y.json (.gml, .osm, ou le format qu'on aura décidé de garder à 
fournir 
  sly> au client)

  C'est effectivement ce qui est fait pour Kothic-JS

http://osmosnimki.ru/vtile/

  et il y a l'air d'avoir un moteur qui met ces tuiles à jour lorsque
  les données correspondantes évoluent (les dates des fichiers .js ne
  sont pas toutes les mêmes). 

-- 
Eric Marsden


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

Re: [OSM-talk-fr] Jeu de données ASTER => conversion en courbe de niveau

[sly (sylvain letuffe)]

On jeudi 30 juin 2011, ad...@partir-en-vtt.com wrote:
> Bonjour,
> 
> J'ai regardé les données ASTER, c'est facilement exploitable. Ci-joint, un
> jeu de données test sur une dalle avec un SHAPE contenant les courbes
> fusionnées selon l’altitude et un autre sans fusion.  

Qu'entends tu par fusion et sans fusion ? 
Avec fusion tu veux dire que pour l'altitude 1000m par exemple tu n'as qu'un 
et un seul enregistrement de type MULTILINESTRING qui contient toutes les 
courbes d'altitude 1000m ?

> S'il faut produire cela à l'échelle Française, je pourrai lancer le
> traitement et vous faire un backup dans une base postgis par exemple. 

J'ai déjà ça pour une bonne partie de l'europe, mais je souhaiterais passer 
world wide pour mon rendu et je me heurte a des problèmes soit de 
méthodologie, soit de performance machine.
Sans compter que les données ASTER sont à télécharger morceaux par morceaux et 
c'est un peu long.

J'en suis là si ça peut gagner du temps :
19G amerique-nord
21G amerique-sud
90G europe
22G oceanie

Mais je me heurte au problème des îles, de l'asie et du recouvrement des 
dalles que j'ai déjà récupéré.
J'avais rêvé fusionner tout ça en un gros geotiff de la terre de 400 Go pour 
lancer ensuite du gdal_contours et du hillshading, hillcoloring dessus, mais 
je crois que ça va pas le faire.
Faut que je re-réfléchisse au problème pour faire ça tuile par tuile

-- 
sly
qui suis-je : http://sly.letuffe.org


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

Re: [OSM-talk-fr] Rendu coté navigateur ( était :OSM destiné pour un besoin de =?iso-8859-15?q?_=3D=3Fiso-8859-15=3Fq=3F=5Frandonn=3DE9e=3F=3D?=)

[sly (sylvain letuffe)]

On jeudi 30 juin 2011, Pieren wrote:
> 2011/6/30 sly (sylvain letuffe) 
> 
> > Pour moi, il est clair que cette solution à vraiment un bel avenir
> >
> >
> Comme d'hab, je ne vais pas être d'accord avec Sly mais on a l'habitude ;-)

Tant mieux ! ça ne serait pas drôle sinon, il faut bien confrontation pour 
avoir de nouvelles idées ou choses qu'on oublie.

> optimisations possibles). Vous allez me dire "on s'en fout, c'est délocalisé
> chez le client". 

on s'en fout, c'est délocalisé chez le client ;-)

J'admet toutefois que sur un tel modèle, l'opération de rendu nécessite au 
final beaucoup plus de temps CPU total puisqu'en effet, elle est exécutée 
chez chaque client (navigateur) plutôt qu'une fois pour tous sur le serveur.

Tout est question de comparer ce qu'il y a à gagner en fonctionnalité et ce 
qu'il y a à perdre en energie totale consommée

> Oui, mais le client va faire une requête bdd pour chaque 
> tuile. Le serveur qui fournit les données va rapidement s'écrouler face à la
> demande de requêtes, celles-ci augmentant proportionnellement avec le nombre
> de clients. Alors que la solution classique avec tuiles ne nécessite cet
> effort (requête vers la base) qu'une seule fois 

Mmmm, je pense que tu perçois la requête comme une lourde tâche alors que ça 
n'est pas forcément le cas. Il est question ici de "tuiles vectorielles" 
c'est à dire de l'ensemble des données vecteurs (utile au niveau de zoom 
demandé) présentes sur un carré fixe, défini à l'avance, pas un truc genre 
WMS ou les données sont construites à la volée. Il est envisageable, je 
pense, d'en garder une version "en cache" de la même manière que les serveurs 
de tuiles gardent une version image en cache et de la servir au navigateur. 
On pourrait même imaginer se passer de base de donnée pour ce cache et stocker 
des fichiers du syle :
/zoom/x/y.json (.gml, .osm, ou le format qu'on aura décidé de garder à fournir 
au client)

> On va me dire : "oui mais on peut mettre tout ça en cache". C'est vrai.
Oups, ça m'apprendra à lire le mail dans son entier, avant ;-)

> Mais 
> il est plus facile et rapide de faire du cache d'images fixes (tuiles) que
> de données dont les requêtes (et les résultats) changent en permanence
> (niveau de zoom, type de rendu, position).

Pas forcément, voir plus haut le modèle auquel je pense.
Qui, bien sûr, présente des défauts par rapport à la requête où on demande ce 
qu'on veut comme on veut sur une zone arbitraire.

Cas typique du client qui ne veut afficher que les cours d'eau alors que la 
tuile contient forêt, cours d'eau, route, amenity, c'est à dire trop de 
données par rapport à l'affichage final souhaité


-- 
sly
qui suis-je : http://sly.letuffe.org


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

[OSM-talk-fr] Jeu de données ASTER => conversion en courbe de niveau

[admin]

Bonjour,

J'ai regardé les données ASTER, c'est facilement exploitable. Ci-joint, un jeu 
de données test sur une dalle avec un SHAPE contenant les courbes fusionnées 
selon l’altitude et un autre sans fusion.


S'il faut produire cela à l'échelle Française, je pourrai lancer le traitement 
et vous faire un backup dans une base postgis par exemple.

téléchargement du jeu de données


Projection : wgs84
Code EPSG : 4326

Dites moi ce que vous en pensez.


-- 
Loïc et Flo.

Créateurs et administrateurs de www.partir-en-vtt.com.___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Début d'interface de génération à la demande des fichiers du cadastre

[Damouns]

>> C'était un bug à la con que j'ai corrigé en ajoutant un trim() sur le
>> nom de la ville.
>
> Accessoirement, j'ai ôté les fichiers concernés : il va falloir
> régénérer vos villes :-)
>
> Pour la génération des départements, j'ajouterai l'option rapidement
> (dimanche ?)

OK merci !

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

Re: [OSM-talk-fr] Début d'interface de génération à la demande des fichiers du cadastre

[Philippe Pary]

Le 30/06/2011 13:45, Philippe Pary a écrit :
> Le 28/06/2011 18:33, Damouns a écrit :
>>> J'ai commencé à développer une interface pour réaliser les fichiers du 
>>> cadastre à la demande.
>>> C'est ultra-sommaire pour l'instant. N'hésitez pas à faire part de vos 
>>> remarques.
>>
>> Les fichiers anciens ne sont pas remplacés par les nouveaux mais ils
>> semblent s'ajouter sur ton serveur : par exemple sur
>> http://cadastre.osm.cleo-carto.org/025/ les fichiers de FRASNE sont en
>> trois exemplaires (j'ai fait la demande 2 fois)
> 
> C'était un bug à la con que j'ai corrigé en ajoutant un trim() sur le
> nom de la ville.


Accessoirement, j'ai ôté les fichiers concernés : il va falloir
régénérer vos villes :-)

Pour la génération des départements, j'ajouterai l'option rapidement
(dimanche ?)

Philippe

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

Re: [OSM-talk-fr] Début d'interface de génération à la demande des fichiers du cadastre

[Philippe Pary]

Le 28/06/2011 18:33, Damouns a écrit :
>> J'ai commencé à développer une interface pour réaliser les fichiers du 
>> cadastre à la demande.
>> C'est ultra-sommaire pour l'instant. N'hésitez pas à faire part de vos 
>> remarques.
> 
> Les fichiers anciens ne sont pas remplacés par les nouveaux mais ils
> semblent s'ajouter sur ton serveur : par exemple sur
> http://cadastre.osm.cleo-carto.org/025/ les fichiers de FRASNE sont en
> trois exemplaires (j'ai fait la demande 2 fois)

C'était un bug à la con que j'ai corrigé en ajoutant un trim() sur le
nom de la ville.

J'ai eu des échanges avec Pierre et quand je reprendrais le dev de ce
machin, je vais recommencer à 0 avec un fonctionnement asynchrone plus
intéressant.

Philippe

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

Re: [OSM-talk-fr] Orthophoto Tours(s) Plus en panne ?

[Emmanuel Dewaele]

Bonjour,

Je confirme, JOSM n'affiche pas de tuiles à ce niveau. D'ailleurs sur la 
sortie standard, il y a des messages du genre, /failed loading 
18/131614/91840 
http://tms.mapspot.ge/tms/2/nonstandard/18/131614/91840.jpeg/.  Le 
serveur a du subir quelques changements. Il faut voir avec Simon, qui 
saura vraiment d'où vient le problème.


A+

Le 30/06/2011 12:10, cyrille giquello a écrit :

Bonjour,

L'imagerie "Orthophoto Tour(s) Plus" ne fonctionne plus chez moi dans
JOSM. Est-ce de même chez vous ?
Merci




--

Emmanuel Dewaele,
Doctorant, Université de Tours, Laboratoire d'Informatique
Ingénieur études et recherche, La Compagnie des mobilités

64, avenue Portalis
bureau 202
37200 TOURS

? 06 26 94 94 71

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

Re: [OSM-talk-fr] Rendu coté navigateur ( était :OSM destiné pour un besoin de =?iso-8859-15?q?_randonn=E9e?=)

[Pieren]

2011/6/30 sly (sylvain letuffe) 

> Pour moi, il est clair que cette solution à vraiment un bel avenir
>
>
Comme d'hab, je ne vais pas être d'accord avec Sly mais on a l'habitude ;-)

Cette solution ne marche que pour de l'expérimental, à faible échelle et à
faible nombre de clients. Parce qu'au lieu de calculer le rendu une fois
pour toutes, on le fait pour chaque client et à chaque visite (il y a des
optimisations possibles). Vous allez me dire "on s'en fout, c'est délocalisé
chez le client". Oui, mais le client va faire une requête bdd pour chaque
tuile. Le serveur qui fournit les données va rapidement s'écrouler face à la
demande de requêtes, celles-ci augmentant proportionnellement avec le nombre
de clients. Alors que la solution classique avec tuiles ne nécessite cet
effort (requête vers la base) qu'une seule fois (à part les actualisations
fréquentes de données qui sont un problème spécifique à OSM).
On va me dire : "oui mais on peut mettre tout ça en cache". C'est vrai. Mais
il est plus facile et rapide de faire du cache d'images fixes (tuiles) que
de données dont les requêtes (et les résultats) changent en permanence
(niveau de zoom, type de rendu, position).

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

Re: [OSM-talk-fr] Rendu coté navigateur ( était :OSM destiné pour un besoin de =?iso-8859-15?q?_randonn=E9e?=)

[sly (sylvain letuffe)]

On part un peu HS là, alors je change le titre

> Allez voir ici l'exemple de Minsk, c'est bluffant de qualité et de rapidité
> http://kothic.org/js/
(...)
> Un jour peut-être ...

Pour moi, il est clair que cette solution à vraiment un bel avenir et du 
potentiel. A l'heure où même les téléphone portable intègrent des processeurs 
doubles coeur à 1.2Ghz, il devient très clairement envisageable (pour la 
masse) de concevoir des serveurs qui n'envoient plus des images figées dans 
la pierre mais bien des données vectorielle que le client pourra rendre selon 
ses souhaits.

Ça existe déjà depuis longtemps avec le protocol WMS, mais c'était compliqué 
car il fallait à chaque fois le logiciel kivabien, une machine assez 
puissante et tout ça avec peu de flexibilité.

L'arrivée de projet de ce type, ou un simple navigateur pourra lancer 
une "petite" application de rendu codée sur mesure en canvas+js ouvre la voie 
à que du bon !

Reste un peu d'optimisation pour accélérer, un peu de standardisation pour le 
format vecteur à envoyer, un peu plus de navigateur qui le supporte et ça 
devrait le faire.
J'ai ouïe dire que openlayers avait un renderer js basé sur canvas... peut 
être que des solutions viendrons aussi de ce coté là

-- 
sly
qui suis-je : http://sly.letuffe.org


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

[OSM-talk-fr] Orthophoto Tours(s) Plus en panne ?

[cyrille giquello]

Bonjour,

L'imagerie "Orthophoto Tour(s) Plus" ne fonctionne plus chez moi dans
JOSM. Est-ce de même chez vous ?
Merci

-- 
Cyrille.

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

Re: [OSM-talk-fr] OSM destiné pour un besoin de randonnée

[Ab_fab]

And now for something completely different ...

Ces histoires de serveurs de tuiles avec des superpositions d'images
difficiles à gérer, cela m'a fait penser à l'approche très originale d'un
développeur russe (Komяpa) pour le rendu des tuiles.

A mon niveau, c'est complexe, je vais essayer de décrire les principes le
plus simplement possible :
L'objectif c'est de basculer la charge de rendu du côté du client, soit en
pratique le navigateur web de l'utilisateur.
Il y a donc un moteur javascript associé à du HTML 5, qui va générer des
images selon des règles de rendu (format mapcss), en allant piocher des
données vectorielles stockées sous forme de tuiles
http://wiki.openstreetmap.org/wiki/Kothic_JS
C'est proche du format GeoJSON, pour ceux qui suivent encore :-)

Allez voir ici l'exemple de Minsk, c'est bluffant de qualité et de rapidité
http://kothic.org/js/
(on a les statistiques de temps de rendu sur la droite de l'écran)
Tout ceci est encore très expérimental, et il n'y a pas de tuiles
disponibles pour de grandes zones géographiques.
Je me demande dans quelle mesure les données d'altimétrie (SRTM ou autres)
pourraient être intégrées à ces tuiles vectorielles et par voie de
conséquence être utilisées pour faire le rendu

Le vrai avantage de tout cela, c'est qu'un seul dépôt de tuiles vectorielles
ouvrirait la possibilité de faire tous les ajustements imaginables dans
les règles de rendu en fonction de l'usage (vélo, ski de fond, rando ...).

Un jour peut-être ...
Le 30 juin 2011 10:16, sly (sylvain letuffe)  a écrit :

>
> > Zut, alors faut que je change le design de mes boutons. Ce sont les deux
> > boutons en bas à droite dans la barre. Les couches ne sont pas actives
> > par défaut par manque de ressources :)
>
> On constate d'ailleurs un des défauts dont je parlais avant, les courbes
> s'affichent par dessus les routes, par dessus les toponymes ce qui nuit un
> peu à la lisibilité parfois.
>
> PS pour yves : ce n'est pas un reproche, j'aide à avancer la
> discussion : "peut-on mutualiser les courbes de niveau"
>
> --
> sly
> qui suis-je : http://sly.letuffe.org
>
>
> ___
>  Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>



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

Re: [OSM-talk-fr] OSM destiné pour un besoin de randonnée

[sly (sylvain letuffe)]

> http://www.openstreetmap.org/?lat=45.23488&lon=5.76347&zoom=16&layers=C
> (SRTM) 
> contre
>http://www.refuges.info/nav.php?lat=45.23493&lon=5.76284&zoom=16&layers=B000FTTFFFTTT
> (DEM3 j'imagine, peut-être que les auteurs pourront confirmer)

J'utilise ASTER uniquement

http://wiki.openstreetmap.org/wiki/Hiking/openhikingmap
-- 
sly
qui suis-je : http://sly.letuffe.org


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

Re: [OSM-talk-fr] OSM destiné pour un besoin de randonnée

[sly (sylvain letuffe)]

> Zut, alors faut que je change le design de mes boutons. Ce sont les deux 
> boutons en bas à droite dans la barre. Les couches ne sont pas actives 
> par défaut par manque de ressources :)

On constate d'ailleurs un des défauts dont je parlais avant, les courbes 
s'affichent par dessus les routes, par dessus les toponymes ce qui nuit un 
peu à la lisibilité parfois.

PS pour yves : ce n'est pas un reproche, j'aide à avancer la 
discussion : "peut-on mutualiser les courbes de niveau"

-- 
sly
qui suis-je : http://sly.letuffe.org


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

Re: [OSM-talk-fr] OSM destiné pour un besoin de randonnée

[sly (sylvain letuffe)]

On mercredi 29 juin 2011, ad...@partir-en-vtt.com wrote:
> Bonjour,
> 
> Il est tout à fait possible de générer des courbes de niveaux avec des
> outils libres comme GDAL avec la commande "gdal_contour" 

"être possible" ne veut pas dire "être facile" ;-)

Pour passer des données SRTM à couverture mondial au format géotif, à des 
courbes de niveau vecteur au format shapefile, à des tuiles allant du zoom 0 
au zoom 20 sur la terre entière, il n'y a peut-être qu'un pas, mais c'est un 
graad pas. 
Et la question que pieren a posé est : arriverait-on à les (les tuiles) 
mutualiser sur un serveur unique ?

-- 
sly
qui suis-je : http://sly.letuffe.org


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

Re: [OSM-talk-fr] OSM destiné pour un besoin de randonnée

[sly (sylvain letuffe)]

> Par contre, pour la réalisation, je vois pas bien. Classiquement, les
> courbes de niveau est une informations que l'on cale sur un calque (si
> je puis dire) que l'on place au-dessus du calque de la nature des sols
> (les beaux pavés de couleurs variées) et en dessous des informations
> plus précises telles les routes. Du coup, je ne vois pas trop, à moins
> de splitter tous les rendus en deux, comment on peut intégrer des
> courbes de niveaux précalculées en raster. A moins qu'on ne parle pas
> de ça et que je sois hors sujet.

Tu as tout à fait raison, mutualiser des tuiles raster de courbes de niveau ne 
peut pas être fait si simplement que ça.

On peut cependant obtenir un résultat disons "à peu prêt pas trop mauvais" 
avec par exemple la méthode suivante :
Un serveur fourni des tuiles raster de représentation des courbes de niveau 
avec les courbes et l'altitude de la courbe au format png, avec un fond 
transparent (et le canal alpha kivabien pour l'anti-aliasing).
Un autre serveur fourni par exemple un fond en png sans transparence des 
ombrages des pentes
Enfin, celui qui veut présenter un rendu spécial le réalise avec un fond 
transparent et demande à openlayers d'aller chercher les 3 tuiles pour que la 
tuile résultante en mémoire et visible à l'écran soit la somme des 3

Le résultat devrait donner quelque chose d'acceptable et mutualisé, avec 
toutefois des défauts :
- la valeur des courbes de niveau va être obscurcie en partie par les surfaces 
de type forêt/prairies/etc.

On pourrait découper le rendu spécial en 2 autres tuiles : le filaire+étendues 
d'eau (qui doivent passer par dessus les courbes de niveau) et le surfacique 
(qui doit passer sous les courbes de niveau)
et faire un rendu coté navigateur par superposition de 4 couches voir plus.

Je constate que j'avais d'ailleurs déjà détaillé ça ici :
http://wiki.openstreetmap.org/wiki/Talk:Hiking/openhikingmap#Contours_sometimes_not_very_readable_.28TODO.29

En résumé, oui, ça serait cool, oui ça peut se faire, mais la résultat ne sera 
pas au mieux.

-- 
sly
qui suis-je : http://sly.letuffe.org


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

Re: [OSM-talk-fr] OSM destiné pour un besoin de randonnée

[Romain MEHUT]

En fait il y a 2 versions du site: http://www.pistes-nordiques.org

Le 29 juin 2011 23:04, Vincent Pottier  a écrit :

> Le 29/06/2011 18:41, yvecai a écrit :
>
>  Un autre exemple ici: http://dev-yves.dyndns.org/**
>> alpha/pistes-nordiques-**backend/
>>
> Excellent !
> Bon, ça n'est pas la forte saison pour le ski, mais je vais faire découvrir
> aux Bisontins !
> --
> FrViPofm
>
>
> __**_
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.**org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr