Re: [OSM-talk-fr] Proposition pour le projet du mois de avril

[adrien carpentier]

Bonjour,
alors quel projet a été choisi pour avril?
il serait intéressant de le donner rapidement, quitte à laisser les débats
sur l'ordre des suggestions pour les mois suivants, non?
pour que l'on ne perde pas trop de temps au mois d'avril, et que l'on ait
réellement l'ensemble des mois prochains pour les sujets suivants
Merci en tout cas de cette initiative!
@ bientôt
adrien


Le 4 avril 2013 20:33, Jo.  a écrit :

> Pour l'instant étant un peut seul dans mon coin, je fait mon micro mapping
> lors de mes déplacements en ville où je préfère marcher en laissant la
> voiture à l'autre bout de la ville pour éviter les embouteillages.
> Idem pour mes sessions course à pied où je mémorise de tête les éléments
> intéressant en attendant de rentrer à la maison. C'est même l'idéal pour
> contrôler une zone ajoutée depuis Bing.
>
>
> Le 4 avril 2013 20:21, PierreV  a écrit :
>
> Bonsoir,
>>
>> Je souhaite te féliciter pour la relance du projet!
>> J'ai l'impression que mes propositions sur le wiki sont peut être passés
>> "inaperçues", mais pour moi je pense qu'il faudrait des projets qui
>> permettent d'améliorer la qualité "globale" des données d'OSM.
>> C'est pour cela que j'ai proposé que l'on fasse des "projets du mois" sur:
>> Compléter/importer l'emplacement des mairies, églises, cimetières, offices
>> de tourisme, bibliothèques, déchetteries, postes de police et pompiers,
>> hôpitaux, maisons de retraite, pharmacies. Et aussi pour les
>> établissements
>> scolaires, et agences La poste pour lesquels ont a déja des outils de
>> "suivi".
>>
>>
>>
>> --
>> View this message in context:
>> http://gis.19327.n5.nabble.com/Proposition-pour-le-projet-du-mois-de-avril-tp5755340p5755775.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
>>
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>
>


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

Re: [OSM-talk-fr] expérimentations à Orange

[Tony Emery]

kimaidou wrote
> Bonjour,
> 
> Sur l'idée de la base tierce, en effet je me suis un peu emballé. Je
> pensais à une application libre que chacun pourrait installer chez soi
> pour
> gérer les liens entre OSM et ses données métiers, si elles sont privées.
> Par contre, l'idée d'une base commune ferait encore sens pour les bases de
> données métiers libres (par exemple celles en ODBL libérées via
> l'opendata).
> 
> Je ne pensais pas forcément à une super api qui gère les flux. Pourquoi
> pas
> à l'avenir. Mais dans un premier temps, une "simple" table qui stocke les
> liens entre objets osm et objets métiers suffit. On peut ensuite utiliser
> les outils comme osmWatch ou autre (à développer...) pour écouter les
> diffs, vérifier s'ils concernent des liens, puis lancer les actions (rss
> pour laisser manuellement, suppression automatique du lien, etc.). A noter
> qu'il n'est pas obligé d'avoir une "vraie" base de données métiers. Ce
> sytème fonctionnerait aussi bien sûr avec des fichiers de type CSV,
> tableau, etc. Tant que des objets "métiers" ont un identifiant, on peut
> créer un lien.
> 
> Au sujet de la base tierce qui "doit connaître les objets osm" et les
> stocker chez elle, c'est vrai qu'il faut à un moment pouvoir lire les
> liens, par exemple pour comparer la donnée. Mais je ne vois pas de souci
> technique ici. On peut imaginer des outils
> * qui aident à créer les liens
> * qui aident à créer des données "fusionnées" via les liens (par exemple
> prend moi la géométrie OSM et colle y les colonnes A, B et C de ma table
> métier
> * qui alertent les personnes lorsqu'une donnée a été supprimée ou modifiée
> d'un côté ou de l'autre
> * qui montre les liens avec un système sympa de double panneau, etc.

En fait, je dois quand même vous alerter sur un points : les collectivité
sont de plus en plus consciente de l'intérêt de gérer en interne une base
exhaustive de leur voirie. Or, cela sous-entend de pouvoir identifier chaque
voie de manière unique dès la création de cette voie, d'où, l'identifiant.
Qu'avons nous comme identifiant voirie :
- Rivoli : c'est un code créé et géré par la DGFiP
- l'ID de la BDAdresse : idem pour l'IGN

Il faut donc créer un identifiant interne dans la commune car la commune est
la source de cette information.

Or, certaines communes ont déjà travaillé sur ce type de référentiel en
interne, parfois même cartographié leur réseau. On ne peut pas leur demander
de refaire le travail, d'où ma question :

=> OSM est-il capable de supporter un identifiant unique pour la voirie
provenant directement des communes sans en avoir forcément la même structure
(nous, on a pris ) ?

Je pense que oui et que cela permettrait de faciliter les connexions entre
les données de différentes bases (vous savez que je suis fan des
"passerelles" entre bases de données).




--
View this message in context: 
http://gis.19327.n5.nabble.com/experimentations-a-Orange-tp5755270p5755819.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] expérimentations à Orange

[Tony Emery]

Désolé pour le retard de ma réponse. Je vais essayer de vous donner quelques
éléments de réflexion. Après, je suis ouvert à toutes propositions.


Guillaume Allegre wrote
> 1) la boundary est une frontière de canton, qui coïncide avec un bout de
> la frontière communale
> (Orange / Caderousse)
> http://www.openstreetmap.org/?way=171243851 mais qui n'est pas confondue
> (points distincts)
> Selon moi, elle devrait être confondue, en tant que limite communale ET
> limite de canton.

J'ai demandé à Christian, dans le cadre d'une expérimentation pour
l'intégration des bureaux de vote et de la carte électorale, d'importer les
données issues de notre SIG. Il s'agit du découpage officiel et utilisé par
les services pour leurs missions quotidiennes.

On peut comparer ce travail au découpage des zones du document d'urbanisme
(PLU), des Servitudes d'Utilité Publique ou des parcelles de la DGFiP (je
dis bien de la DGFiP). Par conséquent, ces traçés, même si leur précision
n'est pas bonne, est règlementée. Pour info, dans un document d'urbanisme
approuvé, si le dessin d'une zone à été mal fait, qu'il coupe une parcelle
alors qu'il ne le devrait pas, c'est quand même ce découpage qui est
appliqué. Je pense donc, même si ce n'est pas juste, qu'il faut le laisser
tel quel si l'on veut que les collectivités s'investissent dans OSM. Elles
ne le feront pas si les limites officielles ne correspondent pas, à cette
échelle, à ce qu'elles trouvent dans OSM.


Guillaume Allegre wrote
> 2) le way polling_station a une résolution bien plus élevée (1 point par
> mètre dans les courbes),
> suivant les _anciens_ méandres de la Meyne, qui restent la limite
> communale comme ici :
> http://www.openstreetmap.org/?lat=44.08722&lon=4.7789&zoom=17&layers=M
> A mon avis, c'est de la sur-résolution inutile,  mais ça se discute.
> Cela n'enlève rien au point 1 : il faut choisir quelle limite on prend
> (171243851 ou 197278529),
> voire un intermédiaire en simplifiant la limite polling_station, mais il
> faut quand même à terme
> fusionner les deux.

Même réponse qu'au-dessus



Guillaume Allegre wrote
> 3) La relation 2649371 a des attributs bizarres : 
> - pas de nom 
> - un "CANTON=Ouest" pas documenté
> - un "ref=22" pas documenté non plus

Effectivement, peut-être que le "ref" peut devenir le "name"


Guillaume Allegre wrote
> 4) la route http://www.openstreetmap.org/browse/way/195747326 a les
> attributs :
> highway = road
> addr:postcode = |84100
> ref:orange = 84087V99
> En dehors de la typo sur le code postal avec le |, est-ce logique de
> mettre un code postal
> sur une voie ? le wiki ne donne qu'un noeud ou une surface, et j'aurais
> tendance à le suivre
> sur ce point.

J'ai pris le parti d'ajouter addr:postcode = 84100 sur les voies qui se
trouvent dans la commune, en attendant d'avoir un outil qui me permette de
sélectionner tous les objets présents à l'intérieur d'une frontière
administrative. Le fait qu'elles aient |84100 veut dire qu'elles se trouvent
en partie sur le territoire (pas forcément gauche et droite) et que je dois
faire attention quand je les intègre.


Guillaume Allegre wrote
> Ensuite : ref:orange : là, je pense qu'on a un problème à régler. "orange"
> n'est pas suffisamment
> distinctif. Si toutes les communes du monde se mettent à utiliser le même
> schéma, on va multiplier
> les conflits. Comment régler ça ? 

L'objectif est de pouvoir faire un lien systématique entre la voie dans OSM
et celles dans la base communale. J'ai mis, à l'époque, ref:orange parce
qu'il n'y avait rien de similaire et qu'il s'agit d'une réflexion que l'on
mène sur plusieurs communes du Vaucluse. S'il faut changer de clé, cela ne
me pose pas de problème mais il faut savoir que cela concernera d'abord les
communes et non l'INSEE. On m'avait suggéré ref:84087, mais je trouvais cela
redondant car dans mon identifiant,il y a déjà le code INSEE. De plus, c'est
quelque chose qui peut se diffuser sur d'autres communes et nous aurions des
tags ref:84087, ref:75001, ref:13205, etc... Il faudrait plutôt un tag du
type ref:FR:commune= ou dans le genre.


Guillaume Allegre wrote
> Je ne remets pas en cause l'utilisation d'OSM comme support de données
> métiers issues 
> de SIG territoriaux, bien au contraire. 
> Mais si, comme je le suppose, Orange tend à devenir une zone d'exemple et
> de démonstration 
> pour cette convergence, il serait préférable que le schéma suivi soit
> aussi 
> irréprochable que possible quant à l'intégration dans les conventions
> standard OSM.
> Alors, je pense qu'il faut sérieusement se pencher sur :
> - le schéma d'attributs et de références qui conviendrait à tout le monde
> - les conventions de fusion ou juxtaposition de données, et les précisions
> géométriques 
>   minimales/maximales acceptables.

Je suis d'accord et je veux bien y participer



--
View this message in context: 
http://gis.19327.n5.nabble.com/experimentations-a-Orange-tp5755270p5755816.html
Sent from the France mailing list archive 

Re: [OSM-talk-fr] Rendu topo 25000ème - réponses multiples

[Vincent Pottier]

Le 04/04/2013 21:17, Etienne Trimaille a écrit :

Désolé, je ne suis pas allé voir les données 
Concernant l'auteur de cette erreur, il faut l'excuser, il était 
débutant à l'époque :)



Oups...

À J+2, c'est encore excusable ?

Je lui ai tiré les oreilles et il a corrigé !
--
FrViPofm

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

Re: [OSM-talk-fr] Opensnowmap.org

[Christian Quest]

A coupler prochainement avec http://openmeteodata.org !


Le 4 avril 2013 21:33, yvecai  a écrit :
> Chers ami et béta-testeurs préférés,
> Je vous remerci d'avance de cliquer sur le lien ci-dessous et d'aller voir
> dans les coins si tout est comme il faut.
> C'est votre nouvelle carte pour les sports d'hivers :
>
> http://www.opensnowmap.org
>


-- 
Christian Quest - OpenStreetMap France
Synthèse du Week-end "SOTM-FR" à Lyon : http://openstreetmap.fr/synthese-sotmfr

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

[OSM-talk-fr] Opensnowmap.org

[yvecai]

Chers ami et béta-testeurs préférés,
Je vous remerci d'avance de cliquer sur le lien ci-dessous et d'aller 
voir dans les coins si tout est comme il faut.

C'est votre nouvelle carte pour les sports d'hivers :

http://www.opensnowmap.org

   Au menu:
   * Serveur de tuiles
   Avec des données fraiches du jour, tout les matins
   * Infos sur les pistes d'un simple clic
   Plus de mode 'vecteur', beaucoup plus léger et meilleure
   compatibilité sur les navigateurs
   * Recherche des pistes par nom
   Les résultats Nominatim sont augmentés d'une sélection
   'special ski'
   * Routage et dénivelés multi-modaux
  Montée en ski de descente, descente en remontée mécanique et
   raccourcis en raquettes, c'est possible !
   * Forum
 Oui, un canal de plus, mais c'est essentiellement pour assurer
   la viabilité du site à long terme


www.pistes-nordiques.org est ainsi voué à disparaitre au profit de ce 
nouveau site, dédié à l'ensemble des sports d'hiver.


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

Re: [OSM-talk-fr] Rendu topo 25000ème

[Romain MEHUT]

Le 4 avril 2013 16:43, JB  a écrit :

> **
>
> Trop pâle ? C'est vrai que ça ne ressemble pas à Mapnik. Les goûts… et les
> couleurs.
>
> Tout de même, pour expliquer mon choix.
>
> D'autres institutions ont décider de ne pas différencier ces éléments.
>
Oui c'est justement partant de ce constat que je me suis dit que l'on
pourrait faire autrement vu que l'on en a maintenant les moyens.

> C'est forêt, ou pas forêt (ou presque). Comme à mon sens, on peut
> traverser une prairie mais pas forcément un champ cultivé, j'ai choisi de
> les différencier, mais sans vouloir surcharger la carte de couleurs, et
> éviter d'agresser l'œil. Du coup, ça reste pâle, en fait, ça se veut quasi
> invisible tant qu'on ne cherche pas l'information. Et toujours en
> raisonnant en carte papier, et non à l'affichage écran.
>
> Après, comme toujours, tu remplaces le fill-opacity: 0.15 par 0.6, et on
> verra qu'il y a de l'herbe par là. Mais à mon avis, au détriment de la
> lisibilité générale.
>
Faut que je teste...

> JB, toujours ouvert aux commentaires, même si des fois il est têtu…
>
C'est quand même ton projet à l'origine donc c'est normal que tu défendes
ton point de vue ;)

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

Re: [OSM-talk-fr] Rendu topo 25000ème - réponses multiples

[Etienne Trimaille]

Désolé, je ne suis pas allé voir les données 
Concernant l'auteur de cette erreur, il faut l'excuser, il était débutant à
l'époque :)


Le 4 avril 2013 21:12, JB  a écrit :

> **
>
> Bien vu. Et quand deux rendus se plantent sur quelque chose de basique, je
> commence à trouver ça louche.
>
> Ki ki a osé mettre un layer=1 sur un tunnel ? Mais je le connais, en plus…
> Je lui laisserai supprimer ce tag ou l'expliquer…
>
> JB.
>
>
>
> Le 04.04.2013 21:02, Etienne Trimaille a écrit :
>
>  Le 4 avril 2013 20:10, JB  a écrit :
>
>>  C'est en train d'uploader, sous
>> http://osm107.openstreetmap.fr/jbtopo/besancon25.png
>>
> Il y a un petit bug de rendu : le tunnel ferré de Morre :
> http://tile.openstreetmap.fr/?zoom=17&lat=47.22244&lon=6.07422&layers=B0
> Sur ton rendu, il est dessiné par dessus les routes alors qu'il doit être
> en-dessous.
>
> Alors que sur la même extrait de ta carte, le tunnel de Chalezeule est
> dessiné sous les routes  :
>
> http://tile.openstreetmap.fr/?zoom=17&lat=47.25423&lon=6.05837&layers=B0
>
> N'est-il pas possible de réduire un peu la visibilité des tunnels en
> général ? A part les entrées et les tunnels, les tunnels ne sont pas
> visibles ;-)
>
> cquest, les bugs des tunnel est présent aussi sur osmfr, même si ce n'est
> pas très visible.
>
> ___
> Talk-fr mailing 
> listTalk-fr@openstreetmap.orghttp://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] Rendu topo 25000ème - réponses multiples

[JB]

 

Bien vu. Et quand deux rendus se plantent sur quelque chose de
basique, je commence à trouver ça louche. 

Ki ki a osé mettre un
layer=1 sur un tunnel ? Mais je le connais, en plus… Je lui laisserai
supprimer ce tag ou l'expliquer… 

JB. 

Le 04.04.2013 21:02, Etienne
Trimaille a écrit : 

> Le 4 avril 2013 20:10, JB  a
écrit :
> 
>> C'est en train d'uploader, sous
http://osm107.openstreetmap.fr/jbtopo/besancon25.png [1]
> 
> Il y a un
petit bug de rendu : le tunnel ferré de Morre :
http://tile.openstreetmap.fr/?zoom=17&lat=47.22244&lon=6.07422&layers=B0
[3] 
> Sur ton rendu, il est dessiné par dessus les routes alors qu'il
doit être en-dessous.
> 
> Alors que sur la même extrait de ta carte, le
tunnel de Chalezeule est dessiné sous les routes :
>
http://tile.openstreetmap.fr/?zoom=17&lat=47.25423&lon=6.05837&layers=B0
[4] 
> 
> N'est-il pas possible de réduire un peu la visibilité des
tunnels en général ? A part les entrées et les tunnels, les tunnels ne
sont pas visibles ;-)
> 
> cquest, les bugs des tunnel est présent aussi
sur osmfr, même si ce n'est pas très visible. 
> 
>
___
> Talk-fr mailing list
>
Talk-fr@openstreetmap.org
>
http://lists.openstreetmap.org/listinfo/talk-fr [2]




Links:
--
[1]
http://osm107.openstreetmap.fr/jbtopo/besancon25.png
[2]
http://lists.openstreetmap.org/listinfo/talk-fr
[3]
http://tile.openstreetmap.fr/?zoom=17&lat=47.22244&lon=6.07422&layers=B0
[4]
http://tile.openstreetmap.fr/?zoom=17&lat=47.25423&lon=6.05837&layers=B0
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Rendu topo 25000ème - réponses multiples

[Etienne Trimaille]

Le 4 avril 2013 20:10, JB  a écrit :

> **
>
> C'est en train d'uploader, sous
> http://osm107.openstreetmap.fr/jbtopo/besancon25.png
>
Il y a un petit bug de rendu : le tunnel ferré de Morre :
http://tile.openstreetmap.fr/?zoom=17&lat=47.22244&lon=6.07422&layers=B0
Sur ton rendu, il est dessiné par dessus les routes alors qu'il doit être
en-dessous.

Alors que sur la même extrait de ta carte, le tunnel de Chalezeule est
dessiné sous les routes  :
http://tile.openstreetmap.fr/?zoom=17&lat=47.25423&lon=6.05837&layers=B0

N'est-il pas possible de réduire un peu la visibilité des tunnels en
général ? A part les entrées et les tunnels, les tunnels ne sont pas
visibles ;-)

cquest, les bugs des tunnel est présent aussi sur osmfr, même si ce n'est
pas très visible.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Rendu topo 25000ème

[yvecai]

Si jamais, le DEM que j'utilise sur www.pistes-nordiques.org est disponible.
Il s'agit de SRTM, dont les vides sont remplis avec les données ASTER, 
et ASTER complémente également entre 60°N et 72°N.
Donc c'est mieux qu'SRTM, mais pas parfait (jeter un coup d'oeil au 
Cervin, par example. Le Mont Blanc est pas mal).
Comme les données ASTER sont down-samplée pour coller à la résolution 
SRTM, je peux le redistribuer, il faut néanmoins citer ' ASTER GDEM is a 
product of METI and NASA' pour toute utilisation.
Noter que j'ai plus les ressources pour l'instant  pour recalculer 
quelques manques pour le hillshade (Russie et Amerique latine sont 
concernés), mais les données sont corrigées.


L'ensemble fait 19.7 GB, me contacter en MP pour la mise à dispo d'un 
lien de téléchargement (ça mange un peu de bande passante quand même, 
donc demander en cas de besoin seulement).


L'autre solution, dont le résultat est visible là [1], c'est ça [2], 
mais en non-commercial pour du gratuit.


[1] 
http://tools.geofabrik.de/map/?type=Geofabrik_Topo&lon=7.74741&lat=45.93724&zoom=13

[2] http://srtm.csi.cgiar.org/

Yves

On 04/04/2013 12:56 PM, Romain MEHUT wrote:
Le 4 avril 2013 12:32, Jean-Claude Repetto > a écrit :


Le 04/04/2013 12:19, Romain MEHUT a écrit :

Et y aurait pas moyen de faire quelque chose à partir de la Bd
Alti de
l'IGN: http://professionnels.ign.fr/bdalti qui est sous la
licence ouverte ?


Le pas est de 250 mètres, c'est très insuffisant. La version
payante a un pas de 25 mètres.


Ah, merci de la précision!



___
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] Proposition pour le projet du mois de avril

[Jo.]

Pour l'instant étant un peut seul dans mon coin, je fait mon micro mapping
lors de mes déplacements en ville où je préfère marcher en laissant la
voiture à l'autre bout de la ville pour éviter les embouteillages.
Idem pour mes sessions course à pied où je mémorise de tête les éléments
intéressant en attendant de rentrer à la maison. C'est même l'idéal pour
contrôler une zone ajoutée depuis Bing.


Le 4 avril 2013 20:21, PierreV  a écrit :

> Bonsoir,
>
> Je souhaite te féliciter pour la relance du projet!
> J'ai l'impression que mes propositions sur le wiki sont peut être passés
> "inaperçues", mais pour moi je pense qu'il faudrait des projets qui
> permettent d'améliorer la qualité "globale" des données d'OSM.
> C'est pour cela que j'ai proposé que l'on fasse des "projets du mois" sur:
> Compléter/importer l'emplacement des mairies, églises, cimetières, offices
> de tourisme, bibliothèques, déchetteries, postes de police et pompiers,
> hôpitaux, maisons de retraite, pharmacies. Et aussi pour les établissements
> scolaires, et agences La poste pour lesquels ont a déja des outils de
> "suivi".
>
>
>
> --
> View this message in context:
> http://gis.19327.n5.nabble.com/Proposition-pour-le-projet-du-mois-de-avril-tp5755340p5755775.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
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Proposition pour le projet du mois de avril

[PierreV]

Bonsoir,

Je souhaite te féliciter pour la relance du projet!
J'ai l'impression que mes propositions sur le wiki sont peut être passés
"inaperçues", mais pour moi je pense qu'il faudrait des projets qui
permettent d'améliorer la qualité "globale" des données d'OSM.
C'est pour cela que j'ai proposé que l'on fasse des "projets du mois" sur:
Compléter/importer l'emplacement des mairies, églises, cimetières, offices
de tourisme, bibliothèques, déchetteries, postes de police et pompiers,
hôpitaux, maisons de retraite, pharmacies. Et aussi pour les établissements
scolaires, et agences La poste pour lesquels ont a déja des outils de
"suivi".



--
View this message in context: 
http://gis.19327.n5.nabble.com/Proposition-pour-le-projet-du-mois-de-avril-tp5755340p5755775.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] Rendu topo 25000ème - réponses multiples

[JB]

 

C'est en train d'uploader, sous
http://osm107.openstreetmap.fr/jbtopo/besancon25.png 

Ça a l'air d'être
un joli coin, j'ai mis la via romea jusqu'à Ornans. Si tu veux nettoyer
un peu la base puis qu'on régénère, pas de problème. J'ai l'impression
qu'il y a notamment pas mal de piscine sans access=private/no. Et si tu
veux qu'on adapte un chouille la feuille de style (genre ne faire
apparaitre que la Via Romea comme itinéraire balisé, marquer son nom --
si j'y arrive, ou autre), n'hésite pas à demander. 

JB. 

Le 04.04.2013
17:52, Vincent Pottier a écrit : 

> Le 04/04/2013 09:59, JB a écrit :
>

>> - Vincent, je peux faire un rendu pour toi, et encore plus si c'est
pour les chemins de Saint-Jacques, ou tout itinéraire alternatif aux
itinéraires « propriété intellectuelle ». Indique-moi quelle zone
t'intéresse
(http://hiking.waymarkedtrails.org/fr/?zoom=7&lat=44.75573&lon=1.79604#
[1]). Ça permet aussi de tester le rendu sur des zones que je ne connais
pas, et d'avoir des retours locaux.
> 
> Par là :
>
http://hiking.waymarkedtrails.org/fr/?zoom=15&lat=47.22075&lon=6.06171&route=1&hill=1.02
[2]
> 
> Ça me permettra de comparer les données, les styles avec la
carte Top25 
> et de faire des présentations.
> 
> Merci d'avance
> --
>
FrViPofm
> 
> ___
> Talk-fr
mailing list
> Talk-fr@openstreetmap.org
>
http://lists.openstreetmap.org/listinfo/talk-fr [3]




Links:
--
[1]
http://hiking.waymarkedtrails.org/fr/?zoom=7&lat=44.75573&lon=1.79604#
[2]
http://hiking.waymarkedtrails.org/fr/?zoom=15&lat=47.22075&lon=6.06171&route=1&hill=1.02
[3]
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] Proposition pour le projet du mois de avril

[Ista Pouss]

Sur le projet du mois, il faudrait répartir les projets "Bric-à-brac OSM",
type bâtiment qui rentre dans une route, nettoyage du énième problème de
licence, copie de Bing GPS Corine Open Data, et les projets qui se
cartographient à partir de ce qu'on voit sur le terrain, comme c'est censé
faire, comme par exemple le micro-mapping (banc public, squares de jeux,
magasins, trottoir...) (je n'y mets pas les caméras de surveillance parce
que je veux pas apparaître comme anarchiste), ou qui nécessitent des
cartos-parties, et qui engageraient des clubs sur le terrain, au lieu
d'engager des experts en osmose.

Les deux sont bons et intéressants, hein, ne me faites pas dire ce que j'ai
pas dit, mais il me semble qu'il faudrait faire gaffe à équilibrer les
projets geeks et les projets à godasses.




Le 4 avril 2013 16:19, Christian Quest  a écrit :

> Le cadastre peut être bien calé sur une zone de la commune et décalé
> sur une autre.
> Il faut voir comment il a été vectorisé. Si la planche raster
> d'origine était décalée, la place vectorisée a de grande de l'être
> aussi et vu qu'il est vectorisé planche par planche vous voyez que ça
> n'a pas de raison d'être homogène sauf si un vrai travail de recalage
> a été fait en plus de la vectorisation.
>
> C'est donc du cas par cas, feuille par feuille... mais comme on
> n'accède plus directement à la notion de feuille cadastrale c'est pas
> simple !
>
>
> Le 3 avril 2013 22:52, Eric SIBERT  a écrit :
> > Le 03/04/2013 15:56, Jean-Baptiste Holcroft a écrit :
> >
> >> En ayant déjà corrigé de nombreuses, je fais avec cadastre + bing +
> >> traces GPS avoisinantes.
> >> Il y a toujours au moins deux sources qui sont d'accord sinon les trois.
> >
> >
> > C'est une bonne base.
> >
> >
> >> Le cas qui me paraît le plus critique est le cadastre mal
> >> positionné.
> >
> >
> > C'est le cas qui me fait peur. Quand je tombe dessus, je ne sais pas quoi
> > faire. Alors, je laisse en espérant qu'un jour le cadastre sera corriger
> et
> > qu'on pourra refaire le bâti/ Je crains qu'en voulant corriger les
> > intersections, on introduise des erreurs au lieu d'en enlever.
> >
> >
> > Éric
> >
> > ___
> > Talk-fr mailing list
> > Talk-fr@openstreetmap.org
> > http://lists.openstreetmap.org/listinfo/talk-fr
>
>
>
> --
> Christian Quest - OpenStreetMap France
> Synthèse du Week-end "SOTM-FR" à Lyon :
> http://openstreetmap.fr/synthese-sotmfr
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>



-- 
Les dérives de rue :
Le papillon d’hiver (le film)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Rafraichissement des tuiles, sur tile.openstreetmap.fr

[Jocelyn Jaubert]

Le 04/04/2013 08:54, Francescu GAROBY a écrit :
> Bonjour,
> Il semblerait que le rafraichissement des tuiles ne se fasse plus : j'ai
> par exemple cette tuile
>  qui date du 27
> mars, alors que j'ai fait des modifications hier soir (cf. la même tuile
> sur Mapnik ).
> Rien ne se met à jour, malgré des demandes de rafraichissement forcé,
> avec "/dirty".
> 
> La mise à jour serait-elle interrompue ?

Le serveur remarque correctement maintenant.


-- 
Jocelyn

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

[OSM-talk-fr] Re : Rafraichissement des tuiles, sur tile.openstreetmap.fr

[yve...@gmail.com]

Monit aide bien pour se rassurer avec renderd.

- Reply message -
De : "Christian Quest" 
Pour : "Discussions sur OSM en français" 
Objet : [OSM-talk-fr] Rafraichissement des tuiles, sur tile.openstreetmap.fr
Date : jeu., avr. 4, 2013 16:36


renderd va dans le mur de temps en temps... tu peux rajouter un petit
cron pour vérifier son état et le relancer ?

je n'ai pas d'accès ssh là où je suis :(

Le 4 avril 2013 15:43, Jocelyn Jaubert  a écrit :
> On Thu, Apr 04, 2013 at 10:05:53AM +0200, Nicolas Dumoulin wrote:
>> > La mise à jour serait-elle interrompue ?
>>
>> Je crois que le serveur a ses files d'attente pleine. J'ai droit à de belles
>> tuiles "Je suis surchargé […] Achetez-moi un disque SSD pour noël" à certains
>> endroits.
>
> Le serveur n'a pas l'air si chargé que ça pourtant:
> http://munin.openstreetmap.fr/free.org/osm13.openstreetmap.fr/renderd_processed.html
>
> Je regarderais ce soir si il n'y a pas un souci sur mod_tile ou renderd.
>
>> Tiens d'ailleurs, on les a pas d'ailleurs maintenant les SSD? Il faudrait
>> demander autre chose pour noël.
>
> Oui, il faudrait changer le message d'erreur, maintenant qu'on a un SSD :)
>
>
> --
> Jocelyn
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr



-- 
Christian Quest - OpenStreetMap France
Synthèse du Week-end "SOTM-FR" à Lyon : http://openstreetmap.fr/synthese-sotmfr

___
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 topo 25000ème

[JB]

 

Tu peux me donner l'endroit exact ? Chez moi, ça marche sur le
fichier de test que j'ai (l'image jointe). Il doit y avoir une
combinaison de clés particulières. 

JB. 

Le 04.04.2013 18:14, Tetsuo
Shima a écrit : 

> Il me semble qu'il y a un petit "bug" sur le rendu
des col de montagne, ceux sans nom - mais disposant d'une altitude - se
voient affublé d'un label 'location' sur le rendu.
> 
> Le 4 avril 2013
16:43, JB  a écrit :
> 
>> JB, toujours ouvert aux
commentaires, même si des fois il est têtu…
> 
>
___
> Talk-fr mailing list
>
Talk-fr@openstreetmap.org
>
http://lists.openstreetmap.org/listinfo/talk-fr [1]




Links:
--
[1] http://lists.openstreetmap.org/listinfo/talk-fr


col.png
Description: Binary data
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Rendu topo 25000ème

[Tetsuo Shima]

Il me semble qu'il y a un petit "bug" sur le rendu des col de montagne,
ceux sans nom - mais disposant d'une altitude - se voient affublé d'un
label 'location' sur le rendu.

Le 4 avril 2013 16:43, JB  a écrit :

> **
>
> JB, toujours ouvert aux commentaires, même si des fois il est têtu…
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Rendu topo 25000ème - réponses multiples

[Vincent Pottier]

Le 04/04/2013 09:59, JB a écrit :
 - Vincent, je peux faire un rendu pour toi, et encore plus si c'est 
pour les chemins de Saint-Jacques, ou tout itinéraire alternatif aux 
itinéraires « propriété intellectuelle ». Indique-moi quelle zone 
t'intéresse 
(http://hiking.waymarkedtrails.org/fr/?zoom=7&lat=44.75573&lon=1.79604#). 
Ça permet aussi de tester le rendu sur des zones que je ne connais 
pas, et d'avoir des retours locaux.

Par là :
http://hiking.waymarkedtrails.org/fr/?zoom=15&lat=47.22075&lon=6.06171&route=1&hill=1.02

Ça me permettra de comparer les données, les styles avec la carte Top25 
et de faire des présentations.


Merci d'avance
--
FrViPofm

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

Re: [OSM-talk-fr] Rendu topo 25000ème

[JB]

 

Trop pâle ? C'est vrai que ça ne ressemble pas à Mapnik. Les goûts…
et les couleurs. 

Tout de même, pour expliquer mon choix. 

D'autres
institutions ont décider de ne pas différencier ces éléments. C'est
forêt, ou pas forêt (ou presque). Comme à mon sens, on peut traverser
une prairie mais pas forcément un champ cultivé, j'ai choisi de les
différencier, mais sans vouloir surcharger la carte de couleurs, et
éviter d'agresser l'œil. Du coup, ça reste pâle, en fait, ça se veut
quasi invisible tant qu'on ne cherche pas l'information. Et toujours en
raisonnant en carte papier, et non à l'affichage écran. 

Après, comme
toujours, tu remplaces le fill-opacity: 0.15 par 0.6, et on verra qu'il
y a de l'herbe par là. Mais à mon avis, au détriment de la lisibilité
générale. 

JB, toujours ouvert aux commentaires, même si des fois il
est têtu… 

Le 04.04.2013 14:30, Romain MEHUT a écrit : 

> Le 4 avril
2013 14:26, JB  a écrit :
> 
>> Avec un bon zoom, ça
passe mieux : http://osm107.openstreetmap.fr/jbtopo/landuse.png [1]
> 
>
Oui effectivement mais les couleurs sont très très pâles. 
> 
> Romain

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




Links:
--
[1]
http://osm107.openstreetmap.fr/jbtopo/landuse.png
[2]
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] Rafraichissement des tuiles, sur tile.openstreetmap.fr

[Christian Quest]

renderd va dans le mur de temps en temps... tu peux rajouter un petit
cron pour vérifier son état et le relancer ?

je n'ai pas d'accès ssh là où je suis :(

Le 4 avril 2013 15:43, Jocelyn Jaubert  a écrit :
> On Thu, Apr 04, 2013 at 10:05:53AM +0200, Nicolas Dumoulin wrote:
>> > La mise à jour serait-elle interrompue ?
>>
>> Je crois que le serveur a ses files d'attente pleine. J'ai droit à de belles
>> tuiles "Je suis surchargé […] Achetez-moi un disque SSD pour noël" à certains
>> endroits.
>
> Le serveur n'a pas l'air si chargé que ça pourtant:
> http://munin.openstreetmap.fr/free.org/osm13.openstreetmap.fr/renderd_processed.html
>
> Je regarderais ce soir si il n'y a pas un souci sur mod_tile ou renderd.
>
>> Tiens d'ailleurs, on les a pas d'ailleurs maintenant les SSD? Il faudrait
>> demander autre chose pour noël.
>
> Oui, il faudrait changer le message d'erreur, maintenant qu'on a un SSD :)
>
>
> --
> Jocelyn
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr



-- 
Christian Quest - OpenStreetMap France
Synthèse du Week-end "SOTM-FR" à Lyon : http://openstreetmap.fr/synthese-sotmfr

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

Re: [OSM-talk-fr] Usage de relations pour les parcs urbains...

[Christian Quest]

Je n'était peut être pas clair avec mon expression de mitage... je précise.

C'est le mitage par multipolygones qui ne me semble pas des plus
utile, l'exemple de la petite clairière dans la grande forêt.
Ne pas la mettre en inner du multipolygone permet aussi de faciliter
les rendus aux petites échelles, la forêt sera un seul grand polygone
qu'on pourra dessiner sans les petits détails quasi invisibles comme
la clairière.

J'avoue que je n'ai pas d'avis tranché sur la question, c'est plus du
domaine de la réflexion qu'autre chose.

Je me poserai la question d'une façon plus générale sur la notion de
relation implicite et de relation explicite.

Relation implicite: elle peut se déduire par l'analyse (simple) des
données en combinant les dimensions géographiques et sémantiques

Relation explicite: on a besoins de recourir à une relation pour
expliciter le lien entre différents objets.

A mon avis, tant qu'on peut rester au niveau d'une relation implicite,
on devrait éviter de recourir à une relation implicite. C'est l'idée
que je voulais faire passer (et discuter).

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

Re: [OSM-talk-fr] Proposition pour le projet du mois de avril

[Christian Quest]

Le cadastre peut être bien calé sur une zone de la commune et décalé
sur une autre.
Il faut voir comment il a été vectorisé. Si la planche raster
d'origine était décalée, la place vectorisée a de grande de l'être
aussi et vu qu'il est vectorisé planche par planche vous voyez que ça
n'a pas de raison d'être homogène sauf si un vrai travail de recalage
a été fait en plus de la vectorisation.

C'est donc du cas par cas, feuille par feuille... mais comme on
n'accède plus directement à la notion de feuille cadastrale c'est pas
simple !


Le 3 avril 2013 22:52, Eric SIBERT  a écrit :
> Le 03/04/2013 15:56, Jean-Baptiste Holcroft a écrit :
>
>> En ayant déjà corrigé de nombreuses, je fais avec cadastre + bing +
>> traces GPS avoisinantes.
>> Il y a toujours au moins deux sources qui sont d'accord sinon les trois.
>
>
> C'est une bonne base.
>
>
>> Le cas qui me paraît le plus critique est le cadastre mal
>> positionné.
>
>
> C'est le cas qui me fait peur. Quand je tombe dessus, je ne sais pas quoi
> faire. Alors, je laisse en espérant qu'un jour le cadastre sera corriger et
> qu'on pourra refaire le bâti/ Je crains qu'en voulant corriger les
> intersections, on introduise des erreurs au lieu d'en enlever.
>
>
> Éric
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr



-- 
Christian Quest - OpenStreetMap France
Synthèse du Week-end "SOTM-FR" à Lyon : http://openstreetmap.fr/synthese-sotmfr

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

Re: [OSM-talk-fr] Opération Libre à Brocas-les-Forges ce week-end

[Christian Quest]

J'y suis déjà ;)

Aujourd'hui à Bordeaux pour les rencontre des l'Afigéo, de retour à
Broca demain soir.


Le 3 avril 2013 17:05, Sébastien Dinot  a écrit :
> Salut,
>
> Je serai ce week-end à Brocas-les-Forges pour participer à l'événement
> Opération Libre :
>
> http://operation-libre.org/
>
> Par curiosité, d'autres mappeurs inscrits sur cette listes ont-ils prévu
> d'y aller ?
>
> Sébastien
>
> --
> Sébastien Dinot, sebastien.di...@free.fr
> http://sebastien.dinot.free.fr/
> Ne goûtez pas au logiciel libre, vous ne pourriez plus vous en passer !
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr



-- 
Christian Quest - OpenStreetMap France
Synthèse du Week-end "SOTM-FR" à Lyon : http://openstreetmap.fr/synthese-sotmfr

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

Re: [OSM-talk-fr] Rafraichissement des tuiles, sur tile.openstreetmap.fr

[Jocelyn Jaubert]

On Thu, Apr 04, 2013 at 10:05:53AM +0200, Nicolas Dumoulin wrote:
> > La mise à jour serait-elle interrompue ?
> 
> Je crois que le serveur a ses files d'attente pleine. J'ai droit à de belles 
> tuiles "Je suis surchargé […] Achetez-moi un disque SSD pour noël" à certains 
> endroits.

Le serveur n'a pas l'air si chargé que ça pourtant:
http://munin.openstreetmap.fr/free.org/osm13.openstreetmap.fr/renderd_processed.html

Je regarderais ce soir si il n'y a pas un souci sur mod_tile ou renderd.

> Tiens d'ailleurs, on les a pas d'ailleurs maintenant les SSD? Il faudrait 
> demander autre chose pour noël.

Oui, il faudrait changer le message d'erreur, maintenant qu'on a un SSD :)


-- 
Jocelyn

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

Re: [OSM-talk-fr] Rendu topo 25000ème

[Romain MEHUT]

Le 4 avril 2013 14:26, JB  a écrit :

> **
>
> Avec un bon zoom, ça passe mieux :
> http://osm107.openstreetmap.fr/jbtopo/landuse.png
>

Oui effectivement mais les couleurs sont très très pâles.

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

Re: [OSM-talk-fr] Rendu topo 25000ème

[JB]

 

Avec un bon zoom, ça passe mieux :
http://osm107.openstreetmap.fr/jbtopo/landuse.png 

JB. 

Le 04.04.2013
14:00, Romain MEHUT a écrit : 

> Le 4 avril 2013 12:32, JB
 a écrit :
> 
>> Salut Romain, 
>> 
>> Merci pour
l'erreur dans le nom de fichier, c'est corrigé (R25.zip à retélécharger
si nécessaire). 
>> 
>> Dans 5 minutes, va voir
http://osm107.openstreetmap.fr/jbtopo/alsace25.png [1] 
>> 
>> On y voit
clairement la distinction entre les zones cultivées et prairies, sans
surcharge (j'espère) pour l'œil une fois imprimé. Pour les zones
résidentielles, ça ne me semble pas dérangeant.
> 
> Ben, non, je ne
vois pas la distinction?
> 
> Romain 
> 
>
___
> Talk-fr mailing list
>
Talk-fr@openstreetmap.org
>
http://lists.openstreetmap.org/listinfo/talk-fr [2]




Links:
--
[1]
http://osm107.openstreetmap.fr/jbtopo/alsace25.png
[2]
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 topo 25000ème

[Romain MEHUT]

Le 4 avril 2013 14:13, HELFER Denis  a écrit :

>  Pour le secteur de Uttwiller, c’est normal qu’il n’y ait rien encore. Je
> démarrage le remplissage.
>

Sur Uhrwiller, on devrait pourtant voir la distinction.

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

Re: [OSM-talk-fr] Rendu topo 25000ème

[HELFER Denis]

Pour le secteur de Uttwiller, c’est normal qu’il n’y ait rien encore. Je 
démarrage le remplissage.

Denis

De : Romain MEHUT [mailto:romain.me...@gmail.com]
Envoyé : jeudi 4 avril 2013 14:00
À : Discussions sur OSM en français
Objet : Re: [OSM-talk-fr] Rendu topo 25000ème

Le 4 avril 2013 12:32, JB mailto:jb...@mailoo.org>> a écrit :

Salut Romain,

Merci pour l'erreur dans le nom de fichier, c'est corrigé (R25.zip à 
retélécharger si nécessaire).

Dans 5 minutes, va voir http://osm107.openstreetmap.fr/jbtopo/alsace25.png

On y voit clairement la distinction entre les zones cultivées et prairies, sans 
surcharge (j'espère) pour l'œil une fois imprimé. Pour les zones 
résidentielles, ça ne me semble pas dérangeant.
Ben, non, je ne vois pas la distinction?

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

Re: [OSM-talk-fr] Rendu topo 25000ème

[Romain MEHUT]

Le 4 avril 2013 12:32, JB  a écrit :

> **
>
> Salut Romain,
>
> Merci pour l'erreur dans le nom de fichier, c'est corrigé (R25.zip à
> retélécharger si nécessaire).
>
> Dans 5 minutes, va voir http://osm107.openstreetmap.fr/jbtopo/alsace25.png
>
> On y voit clairement la distinction entre les zones cultivées et prairies,
> sans surcharge (j'espère) pour l'œil une fois imprimé. Pour les zones
> résidentielles, ça ne me semble pas dérangeant.
>
Ben, non, je ne vois pas la distinction?

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

Re: [OSM-talk-fr] Réflexion sur les sens uniques (ou pas) dans les ronds-points

[Jean-Marc Liotier]

On 04/04/2013 11:51, Nicolas Moyroud wrote:
L'algorithme de routage pourrait ajouter le sens automatiquement (ce 
que ne fait pas celui de OsmAnd apparemment), mais par exemple dans un 
pays où on roule à gauche il faut qu'il inverse automatiquement le sens.


Un attribut appliqué à la boundary=administrative d'admin_level=2 me 
semble approprié pour informer le routeur du sens de circulation. 
L'inconvénient est que le routeur est obligé de remonter le contexte de 
la route demandée jusqu'à ce niveau élevé.


Je n'ai pas trouvé de tel attribut dans Openstreetmap - seulement une 
page énumérant les pays conduisant à gauche : 
http://wiki.openstreetmap.org/wiki/Right-_and_left-hand_traffic


traffic:side=left-hand ou traffic:side=right-hand ?


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

Re: [OSM-talk-fr] Réflexion sur les sens uniques (ou pas) dans les ronds-points

[Hendrik Oesterlin]

Le 04/04/2013 à 20:51:05 +1100 "Nicolas Moyroud" nmoyr...@free.fr a écrit
Objet: "[OSM-talk-fr] Réflexion sur les sens uniques (ou pas) dans les 
ronds-points" :

> Hier j'ai testé l'application mobile Android OsmAnd et notamment 
> l'exploitation des données OSM pour le routage. Ça marche pas mal, mais
> il y a quand même un gros souci : il ne prend pas en compte le sens pour
> les rond-points sur lesquels oneway=yes n'est pas précisé. Il me semble
> avoir vu il y a quelques temps que cette précision n'était pas utile 
> dans les données OSM car cela est implicite avec le junction=roundabout.
> Certes on ne taggue pas pour le rendu ni pour le routage, mais je me 
> pose la question.
> L'algorithme de routage pourrait ajouter le sens automatiquement (ce que
> ne fait pas celui de OsmAnd apparemment), mais par exemple dans un pays
> où on roule à gauche il faut qu'il inverse automatiquement le sens. Bref
> ça fait beaucoup de cas différents à gérer et ce serait peut-être plus
> simple que les données soient adaptées. Il suffirait alors de gérer les
> sens uniques comme pour les autres routes.
> Vous en pensez quoi ?

J'en pense que Osmand prend bien en charge le sens des rond points et
qu'il ne faut pas mettre un oneway=yes en plus...
Dans les pays en conduite à gauche on dessite les rond points en sens
inverse et le oneway=yes reste implicite, exactement comme en France.
Tu es peut-être en mode piéton et pas en mode voiture voiture?

-- 
Cordialement
Hendrik Oesterlin - Nouvelle-Calédonie


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

Re: [OSM-talk-fr] Réflexion sur les sens uniques (ou pas) dans les ronds-points

[Pieren]

2013/4/4 Nicolas Moyroud 

> souci : il ne prend pas en compte le sens pour les rond-points sur
> lesquels oneway=yes n'est pas précisé.
>
>
Le problème n'est pas forcément une absence de oneway=yes. Depuis toujours,
on a dit que ce tag n'était pas nécessaire lorsqu'il y a un
"junction=roundbout".
Par contre, cela ne dispense pas le contributeur de tracer le "way" dans le
sens de circulation des véhicules. C'est peut-être là que se situait ton
bug. Il suffit juste d'inverser le sens du "way" avec n'importe quel
éditeur. Il est possible qu'osmose signale ce genre de problème. A vérifier.

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

Re: [OSM-talk-fr] Rendu topo 25000ème

[Romain MEHUT]

Le 4 avril 2013 12:32, Jean-Claude Repetto  a écrit :

> Le 04/04/2013 12:19, Romain MEHUT a écrit :
>
>  Et y aurait pas moyen de faire quelque chose à partir de la Bd Alti de
>> l'IGN: 
>> http://professionnels.ign.fr/**bdaltiqui
>>  est sous la licence ouverte ?
>>
>
> Le pas est de 250 mètres, c'est très insuffisant. La version payante a un
> pas de 25 mètres.


Ah, merci de la précision!
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Rendu topo 25000ème

[sly (sylvain letuffe)]

On jeudi 4 avril 2013, Romain MEHUT wrote:

> Et y aurait pas moyen de faire quelque chose à partir de la Bd Alti de
> l'IGN: http://professionnels.ign.fr/bdalti qui est sous la licence ouverte ?

Il faut bien lire jusqu'au bout :
"Accéder au téléchargement de la BD ALTI® aux pas de 250m, 500m et 1000m"

En clair, un truc grossier, on va pas se plaindre car c'est gratuit, mais 
SRTM/ASTER c'est 90m de précision, et la BD ALTI (non gratuite) 25m

-- 
sly, DWG member since 11/2012
Coordinateur du groupe [ga]
http://wiki.openstreetmap.org/wiki/User:Sletuffe

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

Re: [OSM-talk-fr] Rendu topo 25000ème

[Jean-Claude Repetto]

Le 04/04/2013 12:19, Romain MEHUT a écrit :


Et y aurait pas moyen de faire quelque chose à partir de la Bd Alti de
l'IGN: http://professionnels.ign.fr/bdalti qui est sous la licence ouverte ?


Le pas est de 250 mètres, c'est très insuffisant. La version payante a 
un pas de 25 mètres.



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

Re: [OSM-talk-fr] Rendu topo 25000ème

[JB]

 

Salut Romain, 

Merci pour l'erreur dans le nom de fichier, c'est
corrigé (R25.zip à retélécharger si nécessaire). 

Dans 5 minutes, va
voir http://osm107.openstreetmap.fr/jbtopo/alsace25.png 

On y voit
clairement la distinction entre les zones cultivées et prairies, sans
surcharge (j'espère) pour l'œil une fois imprimé. Pour les zones
résidentielles, ça ne me semble pas dérangeant. 

JB. 

Le 04.04.2013
11:12, Romain MEHUT a écrit : 

> Bonjour,
> 
> Merci JB pour ce gros
travail qui va effectivement nous permettre d'en mettre plein la vue à
tous ceux qui se demandent comment on peut exploiter les données OSM.
>

> Un petit retour à chaud: as-tu testé un rendu pour les zones
cultivées, résidentielles et les prairies? Ça peut faire beaucoup de
zones blanches par endroit.
> 
> A noter aussi que dans ton tutoriel, tu
nommes ton fichier de règles en R25.mrules alors que dans ton archive il
se somme rando.mrules. 
> Romain
> 
> Le 3 avril 2013 20:12, JB
 a écrit :
> 
>> Bonjour, 
>> 
>> Ça y est, après
l'avoir sous-entendu au SOTM-FR, après l'avoir montré en avant-première,
sous forme incomplète en carto-partie et sur Grenoble, je suis prêt à
vous le présenter. 
>> 
>> Pour les pressés, les images, c'est par ici
(attention, certains fichiers lourds, merci Guillaume pour le coup de
main) : 
>> 
>> Sur les premiers kilomètres de la ViaAlpina, de notre
coté 108Mo : http://osm101.openstreetmap.fr/jbtopo/ViaAlpina25.png [1]

>> 
>> Sur le sud du Vercors 115Mo :
http://osm101.openstreetmap.fr/jbtopo/Vercors25.png [2] 
>> 
>> En
centre ville, au 15000, à Paris 8Mo :
http://osm101.openstreetmap.fr/jbtopo/NotreDame15.png [3] 
>> 
>> À
Strasbourg au 15000 13Mo :
http://osm101.openstreetmap.fr/jbtopo/Strasbourg15petit.png [4] 
>> 
>>
À Strasbourg au 25000 19Mo :
http://osm101.openstreetmap.fr/jbtopo/Strasbourg25.png [5]
>> 
>> En
périurbain, à Verrières-le-Buisson 8Mo :
http://osm101.openstreetmap.fr/jbtopo/Verrieres25.png [6] 
>> 
>> Avec
sur-impression d'une trace GPS, au-dessus de Grenoble 25Mo :
http://osm101.openstreetmap.fr/jbtopo/LeSappeyGPS.png [7] 
>> 
>> Et
bien sûr, la légende :
http://osm101.openstreetmap.fr/jbtopo/legende4.png [8]
>> 
>> Si vous
voulez d'autres démos, demandez, ou créez-les vous-même (le tuto est là,
avec tout ce qu'il faut… continuez à lire). 
>> 
>> La problématique :

>> 
>> J'ai participé à une formation à OSM à laquelle participaient
plusieurs personnes d'office de tourisme. Un point essentiel est
ressorti : la base de données, l'accès à la donnée brute, c'est bien
beau, mais qu'est-ce qu'on en fait ? On ne sait peut-être pas trop ce
que c'est qu'une base de données, ça ne nous fait pas rêver, par contre,
une carte, on aime, on n'en a pas, et on en veut. 
>> 
>> De mon coté,
je suis intéressé de voir les capacités de la base OSM et des outils
développés autour. J'ai aussi envie de développer un rendu topo/rando.

>> 
>> À partir de là, j'ai commencé à travailler sur ce rendu topo,
avec au fond de la tête l'idée qu'il serait bien utile, entre-autre, aux
offices de tourisme. Est-ce que ce type de rendu pourrait aussi
intéresser de nouvelles personnes au projet ? 
>> 
>> Les choix : 
>>

>> - Maperitive/Tilemill ? On connait maintenant leurs différences
(simplicité, orientation web, …). Comme je vise une mise à disposition
pour les moins bricoleurs en informatique, je me suis rapidement reporté
sur Maperitive 
>> 
>> - Mono-zoom/multi-échelle. Le travail sur un seul
niveau de zoom me semble obliger à trancher plus nettement dans les
données rendues, et ainsi espérer obtenir une carte plus claire. J'ai
choisi de travailler à une échelle seule, pour une impression aux
environs du 25000ème (15000 en milieu urbain). 
>> 
>> - Impression
écran/papier. La résolution de l'écran oblige à utiliser des tailles de
texte et de symboles assez grandes, pas forcément adaptées à une
impression papier. J'ai choisi de privilégier le support papier. 
>> 
>>
- Son nom, R25 pour l'instant, ouvert à toute proposition de
modification.
>> 
>> - Et bien sûr les choix de sélection, de
représentation. Toujours critiquables, critiquez-les… 
>> 
>> Le travail
: 
>> 
>> Plus de 3900 lignes de feuille de style (pour un seul niveau
de zoom…). Si je recommençais demain (non, je ne le ferai pas), la
feuille aurait été organisée légèrement différemment, elle pourrait être
également condensée (mais finalement pas tant que ça). Je n'ai pas
commencé à compter mes heures passées sur le projet, je pense que c'est
mieux ainsi. 
>> 
>> La feuille de style est actuellement sous licence
CC-by-nc-sa, du moins c'est ce qui est écrit partout ; mais je me suis
déjà presque convaincu moi-même, il passe au CC-by-sa dès sa prochaine
version (insistez juste un tout petit peu).
>> 
>> Les défauts connus :

>> 
>> La carte se limite toujours à la donnée disponible. On note que
la donnée SRTM (courbes de niveau et ombrage) est parfois manquante,
notamment dans les zones au relief accidenté. 
>> 
>> Le mono-échelle se
casse les dents sur de

Re: [OSM-talk-fr] Rendu topo 25000ème

[Romain MEHUT]

Le 4 avril 2013 11:30, Etienne Trimaille  a
écrit :

> Bravo pour le rendu JB ;-)
>
> Concernant CycleMap, il précise juste qu'il utilise les données srtm, pas
> aster dans la doc. Alors peut-être qu'il a ré-échantillonner les données
> pour compléter les trous (avec gdal, grass) ?
> Certains complètent les trous avec aster :
> http://georezo.net/forum/viewtopic.php?pid=170977
> ou alors ils utilisent exlusivement aster.
>
> Mais du coup, avec ces techniques, on perd la simplicité de Maperitive à
> ajouter facilement les courbes de niveaux et l'ombrage en 3 clics. Il faut
> passer par des outils annexes pas toujours simples pour manipuler le relief.
>

Et y aurait pas moyen de faire quelque chose à partir de la Bd Alti de
l'IGN: http://professionnels.ign.fr/bdalti qui est sous la licence ouverte ?

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

Re: [OSM-talk-fr] Rendu topo 25000ème - données relief.

[sly (sylvain letuffe)]

On jeudi 4 avril 2013, JB wrote:
> C'est effectivement possible que la source de Cyclemap ne soit pas
> SRTM mais VF. 

Tu peux aussi regarder ASTER[1], c'est pas trop mal (je trouve) dans les alpes 
et tu peux en voir une démo ici :
http://maps.refuges.info/?zoom=11&lat=45.72491&lon=6.58209&layers=B00F

Y'a toujours des trous, mais moins qu'avec SRTM et en contrepartie, certains 
plaines présentes des artefacts cracra

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

-- 
sly, DWG member since 11/2012
Coordinateur du groupe [ga]
http://wiki.openstreetmap.org/wiki/User:Sletuffe

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

Re: [OSM-talk-fr] Rendu topo 25000ème

[Etienne Trimaille]

Bravo pour le rendu JB ;-)

Concernant CycleMap, il précise juste qu'il utilise les données srtm, pas
aster dans la doc. Alors peut-être qu'il a ré-échantillonner les données
pour compléter les trous (avec gdal, grass) ?
Certains complètent les trous avec aster :
http://georezo.net/forum/viewtopic.php?pid=170977
ou alors ils utilisent exlusivement aster.

Mais du coup, avec ces techniques, on perd la simplicité de Maperitive à
ajouter facilement les courbes de niveaux et l'ombrage en 3 clics. Il faut
passer par des outils annexes pas toujours simples pour manipuler le relief.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Rendu topo 25000ème - données relief.

[JB]

 

C'est effectivement possible que la source de Cyclemap ne soit pas
SRTM mais VF. J'essaye désespérément de charger leurs données pour voir
ce que ça donnerait, mais le serveur VF n'a pas l'air en forme, alors
que SRTM3 répond bien : 

 Loading digital elevation model...

Downloading Viewfinder DEM tile 'N45E005.hgt'...
 Error downloading SRTM
data. 

(Je pense que le mot SRTM fait juste partie du message d'erreur
standard) 

JB. 

Le 04.04.2013 09:20, sebastien.di...@free.fr a écrit :


> - Mail original -
> 
>> On Wed, 3 Apr 2013 21:04:21 +0200
Sébastien Dinot  wrote: 
>> 
>>> JB a écrit
:
>> [.../...] 
>> 
 On note que la donnée SRTM (courbes de niveau
et ombrage) est parfois manquante, notamment dans les zones au relief
accidenté.
>>> Je ne connaissais pas ce défaut de SRTM que je n'avais
notamment jamais remarqué dans les Pyrénées. C'est étrange...
>>
http://maperitive.net/docs/Commands/SetDemSource.html [1] VF.Alps: one
arcsecond resolution DEM covering Alps without any major data voids.
Source: http://www.viewfinderpanoramas.org/dem3.html#alps [2]. valable
aussi pour les Pyrénées.
> 
> Pourtant, je me pose une question lorsque
je consulte par exemple cette image :
> 
>
http://osm107.openstreetmap.fr/jbtopo/LeSappeyGPS.png [3]
> 
> Et le
rendu CycleMap de la même zone sur OSM :
> 
>
http://osm.org/go/0CATAqPL-?layers=C [4]
> 
> Les trous constatés sur la
première n'existent pas sur le second. CycleMap utilise-t-il d'autres
données (Aster, autre) ?
> 
> Sébastien

 

Links:
--
[1]
http://maperitive.net/docs/Commands/SetDemSource.html
[2]
http://www.viewfinderpanoramas.org/dem3.html#alps
[3]
http://osm107.openstreetmap.fr/jbtopo/LeSappeyGPS.png
[4]
http://osm.org/go/0CATAqPL-?layers=C
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Rendu topo 25000ème

[Guillaume Allegre]

Le jeu. 04 avril 2013 à 08:42 +0200, clansco a écrit :
> On Wed, 3 Apr 2013 21:04:21 +0200
> Sébastien Dinot  wrote:
> 
> > JB a écrit :
> > 
> [.../...]
> > > On note que la donnée SRTM (courbes de niveau et ombrage) est parfois
> > > manquante, notamment dans les zones au relief accidenté.
> > 
> > Je ne connaissais pas ce défaut de SRTM que je n'avais notamment jamais
> > remarqué dans les Pyrénées. C'est étrange...
> > 
> http://maperitive.net/docs/Commands/SetDemSource.html
>   VF.Alps: one arcsecond resolution DEM covering Alps without any major 
> data voids. 
>   Source: http://www.viewfinderpanoramas.org/dem3.html#alps.
> valable aussi pour les Pyrénées.

A la lecture du site viewfinderpanoramas, il y a quand même une grosse 
incertitude sur 
la source et la licence des données utilisées pour "remplir les blancs".
http://www.viewfinderpanoramas.org/voidfill.html




-- 
 ° /\Guillaume AllègreOpenStreetMap France
  /~~\/\   allegre.guilla...@free.fr  Cartographie libre et collaborative
 /   /~~\tél. 04.76.63.26.99  http://www.openstreetmap.fr


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

[OSM-talk-fr] Réflexion sur les sens uniques (ou pas) dans les ronds-points

[Nicolas Moyroud]

Bonjour à tous,

Hier j'ai testé l'application mobile Android OsmAnd et notamment 
l'exploitation des données OSM pour le routage. Ça marche pas mal, mais 
il y a quand même un gros souci : il ne prend pas en compte le sens pour 
les rond-points sur lesquels oneway=yes n'est pas précisé. Il me semble 
avoir vu il y a quelques temps que cette précision n'était pas utile 
dans les données OSM car cela est implicite avec le junction=roundabout. 
Certes on ne taggue pas pour le rendu ni pour le routage, mais je me 
pose la question.
L'algorithme de routage pourrait ajouter le sens automatiquement (ce que 
ne fait pas celui de OsmAnd apparemment), mais par exemple dans un pays 
où on roule à gauche il faut qu'il inverse automatiquement le sens. Bref 
ça fait beaucoup de cas différents à gérer et ce serait peut-être plus 
simple que les données soient adaptées. Il suffirait alors de gérer les 
sens uniques comme pour les autres routes.

Vous en pensez quoi ?

Nicolas

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

Re: [OSM-talk-fr] Rendu topo 25000ème

[Romain MEHUT]

Bonjour,

Merci JB pour ce gros travail qui va effectivement nous permettre d'en
mettre plein la vue à tous ceux qui se demandent comment on peut exploiter
les données OSM.

Un petit retour à chaud: as-tu testé un rendu pour les zones cultivées,
résidentielles et les prairies? Ça peut faire beaucoup de zones blanches
par endroit.

A noter aussi que dans ton tutoriel, tu nommes ton fichier de règles en
R25.mrules alors que dans ton archive il se somme rando.mrules.

Romain

Le 3 avril 2013 20:12, JB  a écrit :

> **
>
> Bonjour,
>
> Ça y est, après l'avoir sous-entendu au SOTM-FR, après l'avoir montré en
> avant-première, sous forme incomplète en carto-partie et sur Grenoble, je
> suis prêt à vous le présenter.
>
> Pour les pressés, les images, c'est par ici (attention, certains fichiers
> lourds, merci Guillaume pour le coup de main) :
>
> Sur les premiers kilomètres de la ViaAlpina, de notre coté 108Mo :
> http://osm101.openstreetmap.fr/jbtopo/ViaAlpina25.png
>
> Sur le sud du Vercors 115Mo :
> http://osm101.openstreetmap.fr/jbtopo/Vercors25.png
>
> En centre ville, au 15000, à Paris 8Mo :
> http://osm101.openstreetmap.fr/jbtopo/NotreDame15.png
>
> À Strasbourg au 15000 13Mo :
> http://osm101.openstreetmap.fr/jbtopo/Strasbourg15petit.png
>
> À Strasbourg au 25000 19Mo :
> http://osm101.openstreetmap.fr/jbtopo/Strasbourg25.png
>
> En périurbain, à Verrières-le-Buisson 8Mo :
> http://osm101.openstreetmap.fr/jbtopo/Verrieres25.png
>
> Avec sur-impression d'une trace GPS, au-dessus de Grenoble 25Mo :
> http://osm101.openstreetmap.fr/jbtopo/LeSappeyGPS.png
>
> Et bien sûr, la légende :
> http://osm101.openstreetmap.fr/jbtopo/legende4.png
>
> Si vous voulez d'autres démos, demandez, ou créez-les vous-même (le tuto
> est là, avec tout ce qu'il faut… continuez à lire).
>
>
>
> La problématique :
>
> J'ai participé à une formation à OSM à laquelle participaient plusieurs
> personnes d'office de tourisme. Un point essentiel est ressorti : la base
> de données, l'accès à la donnée brute, c'est bien beau, mais qu'est-ce
> qu'on en fait ? On ne sait peut-être pas trop ce que c'est qu'une base de
> données, ça ne nous fait pas rêver, par contre, une carte, on aime, on n'en
> a pas, et on en veut.
>
> De mon coté, je suis intéressé de voir les capacités de la base OSM et des
> outils développés autour. J'ai aussi envie de développer un rendu
> topo/rando.
>
> À partir de là, j'ai commencé à travailler sur ce rendu topo, avec au fond
> de la tête l'idée qu'il serait bien utile, entre-autre, aux offices de
> tourisme. Est-ce que ce type de rendu pourrait aussi intéresser de
> nouvelles personnes au projet ?
>
>
>
> Les choix :
>
> - Maperitive/Tilemill ? On connait maintenant leurs différences
> (simplicité, orientation web, …). Comme je vise une mise à disposition pour
> les moins bricoleurs en informatique, je me suis rapidement reporté sur
> Maperitive
>
> - Mono-zoom/multi-échelle. Le travail sur un seul niveau de zoom me semble
> obliger à trancher plus nettement dans les données rendues, et ainsi
> espérer obtenir une carte plus claire. J'ai choisi de travailler à une
> échelle seule, pour une impression aux environs du 25000ème (15000 en
> milieu urbain).
>
> - Impression écran/papier. La résolution de l'écran oblige à utiliser des
> tailles de texte et de symboles assez grandes, pas forcément adaptées à une
> impression papier. J'ai choisi de privilégier le support papier.
>
> - Son nom, R25 pour l'instant, ouvert à toute proposition de modification.
>
> - Et bien sûr les choix de sélection, de représentation. Toujours
> critiquables, critiquez-les…
>
>
>
> Le travail :
>
> Plus de 3900 lignes de feuille de style (pour un seul niveau de zoom…). Si
> je recommençais demain (non, je ne le ferai pas), la feuille aurait été
> organisée légèrement différemment, elle pourrait être également condensée
> (mais finalement pas tant que ça). Je n'ai pas commencé à compter mes
> heures passées sur le projet, je pense que c'est mieux ainsi.
>
> La feuille de style est actuellement sous licence CC-by-nc-sa, du moins
> c'est ce qui est écrit partout ; mais je me suis déjà presque convaincu
> moi-même, il passe au CC-by-sa dès sa prochaine version (insistez juste un
> tout petit peu).
>
>
>
> Les défauts connus :
>
> La carte se limite toujours à la donnée disponible. On note que la donnée
> SRTM (courbes de niveau et ombrage) est parfois manquante, notamment dans
> les zones au relief accidenté.
>
> Le mono-échelle se casse les dents sur des zones à forte différence de
> densité de données. Le centre de Paris est bien plus lisible si imprimé au
> 15000ème, alors que le 25000 en rando semble généralement bon.
>
>
>
> La suite :
>
> J'ai fini de travailler sur la feuille de style (c'est ce que je dis
> chaque matin depuis 10 jours) ; le tutoriel niveau 0 est prêt, joint à ce
> mél. Au programme : un tutoriel de niveau plus élevé.
>
> Au programme aussi, recevoir vos retours que j'espère (raisonnablement)
> nombreux. Je pense qu'un

Re: [OSM-talk-fr] Rendu topo 25000ème - réponses multiples

[JB]

 

Bonjour, 

Voici le premier lot de réponses (mes méls mettent un peu
de temps à arriver, je ne sais pas où ils se perdent en route). 

- la
licence, c'est bon, elle passe en CC-by-sa dès que je republie tout à
jour. Si quelqu'un en a un besoin plus urgent (que d'attendre une
semaine), je peux aller plus vite. 

- les trous dans les données SRTM
sont un problème connu, notamment dans les zones accidentées. Je ne
connaissais pas l'alternative donnée par Frédéric, je vais aller essayer
ça (est-ce que tu sais si l'alternative est meilleure pour toute la
France ou uniquement les alpes/pyrénées ?) 

- j'ai fait des essais
papier, et ça vaut le coup. J'ai notamment modifié le rendu des forêts
suite à eux. Si quelqu'un essaye une impression grand format, je suis
curieux de voir ce que cela donnera ! 

- sur le rendu : 

 - les
courbes de niveau, bien vu, je ne les ai jamais reprises, je vais
affiner les courbes majeures. 

 - les églises : les symboles ne peuvent
actuellement pas être pivotés, mais il me semble que c'est au programme
du développeur. Par contre, cela ne règlera pas le problème, car on n'a
pas les outils pour calculer leur orientation. A propos de
développements souhaités, n'hésitez pas à aller voter pour celui-ci :
http://maperitive.idea.informer.com/proj/?ia=64935 qui aidera à mieux
différentier les sentiers, et d'autres lignes également, d'ailleurs… 


- Les tennis, je me suis posé la question. Je me suis également posé la
question, de qui, chez les chefs de l'IGN, en faisait, pour autant les
mettre en avant sur leurs cartes T25. Je ne prévois pas de mettre
d'icône à ce jour. Je veux bien essayer de voir ce que ça donne si tu
m'en fournis une. Et sinon, tu ouvres la feuille de style, tu tapes
trois lignes de texte, et c'est fait. Je peux te les donner :
icon-image: /tennis.png icon-width: 8 draw: icon. 

 - Vincent, je peux
faire un rendu pour toi, et encore plus si c'est pour les chemins de
Saint-Jacques, ou tout itinéraire alternatif aux itinéraires « propriété
intellectuelle ». Indique-moi quelle zone t'intéresse
(http://hiking.waymarkedtrails.org/fr/?zoom=7&lat=44.75573&lon=1.79604#).
Ça permet aussi de tester le rendu sur des zones que je ne connais pas,
et d'avoir des retours locaux. 

 Aller, la dernière correction d'hier
soir : le nom des riverbank n'apparait plus (qui a remarqué la Seine là
où elle ne devait pas être, à Paris ?) 

JB. 

Le 04.04.2013 09:27,
Romain MEHUT a écrit : 

> Le 4 avril 2013 08:53,
 a écrit :
> 
>> Bonjour,
>> 
>> - Mail
original -
>> 
>>> Pour la licence, j'appuie sur le côté NC, faut
bien voir auprès de
>> > qui tu souhaite partager ces techniques.
>> 
>>
À propos de licence, je vais faire mon pénible mais alors que je
m'apprêtais à diffuser ce message à des amis, je me suis posé une
question : quelle est la licence du tutoriel ? Là encore, une licence CC
By(-SA) serait la bienvenue pour encourager les contributions.
> 
>
C'est précisé tout à la fin du tutoriel: "_Ce tutoriel a été réalisé par
JB (http://www.openstreetmap.org/user/JBacc1 [2]), il est placé sous une
licence CC-by-sa (http://creativecommons.org/licenses/by-sa/2.0/fr/
[3]). Vous êtes libre de le reproduire, le modifier, sous réserve de
citer l'auteur original, et de publier le nouveau document sous une
licence similaire._"
> 
> Romain 
> 
>
___
> Talk-fr mailing list
>
Talk-fr@openstreetmap.org
>
http://lists.openstreetmap.org/listinfo/talk-fr [1]




Links:
--
[1] http://lists.openstreetmap.org/listinfo/talk-fr
[2]
http://www.openstreetmap.org/user/JBacc1
[3]
http://creativecommons.org/licenses/by-sa/2.0/fr/
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Rafraichissement des tuiles, sur tile.openstreetmap.fr

[Nicolas Dumoulin]

Le jeudi 4 avril 2013 08:54:04 Francescu GAROBY a écrit :
> Bonjour,
> Il semblerait que le rafraichissement des tuiles ne se fasse plus : j'ai
> par exemple cette
> tuilequi date
> du 27 mars, alors que j'ai fait des modifications hier soir (cf.
> la même tuile sur Mapnik
> ).
> Rien ne se met à jour, malgré des demandes de rafraichissement forcé, avec
> "/dirty".
> 
> La mise à jour serait-elle interrompue ?

Je crois que le serveur a ses files d'attente pleine. J'ai droit à de belles 
tuiles "Je suis surchargé […] Achetez-moi un disque SSD pour noël" à certains 
endroits.
Tiens d'ailleurs, on les a pas d'ailleurs maintenant les SSD? Il faudrait 
demander autre chose pour noël.

-- 
Nicolas Dumoulin
http://wiki.openstreetmap.org/wiki/User:NicolasDumoulin

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

Re: [OSM-talk-fr] Rendu topo 25000ème (Bobo)

[sebastien . dinot]

- Mail original -
> C'est précisé tout à la fin du tutoriel

Me voilà donc promu « Boulet du jour »

Sur ce, je retourne dans ma tanière et je me fais oublier...

Sébatien

-- 
Sébastien Dinot, sebastien.di...@free.fr
http://sebastien.dinot.free.fr/
Ne goûtez pas au logiciel libre, vous ne pourriez plus vous en passer !


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

Re: [OSM-talk-fr] Rendu topo 25000ème (Bobo)

[JB]

 

Le tutoriel, c'est écrit dessus (dans les remarques, en bas),
peut-être pas assez mis en évidence, en CC-by-sa. Ça a l'air d'être la
licence privilégiée pour les présentations et tutoriels que j'ai vu
autour d'OSM. 

JB. 

Le 04.04.2013 08:53, sebastien.di...@free.fr a
écrit : 

> Bonjour,
> 
> - Mail original -
> 
>> Pour la
licence, j'appuie sur le côté NC, faut bien voir auprès de qui tu
souhaite partager ces techniques.
> 
> À propos de licence, je vais
faire mon pénible mais alors que je m'apprêtais à diffuser ce message à
des amis, je me suis posé une question : quelle est la licence du
tutoriel ? Là encore, une licence CC By(-SA) serait la bienvenue pour
encourager les contributions.
> 
> Sébastien

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

Re: [OSM-talk-fr] Rendu topo 25000ème

[sebastien . dinot]

- Mail original -
> On Wed, 3 Apr 2013 21:04:21 +0200
> Sébastien Dinot  wrote:
> 
> > JB a écrit :
> > 
> [.../...]
> > > On note que la donnée SRTM (courbes de niveau et ombrage) est
> > > parfois manquante, notamment dans les zones au relief accidenté.
> > 
> > Je ne connaissais pas ce défaut de SRTM que je n'avais notamment
> > jamais remarqué dans les Pyrénées. C'est étrange...
> > 
> http://maperitive.net/docs/Commands/SetDemSource.html
>   VF.Alps: one arcsecond resolution DEM covering Alps without any
>   major data voids.
>   Source: http://www.viewfinderpanoramas.org/dem3.html#alps.
> valable aussi pour les Pyrénées.

Pourtant, je me pose une question lorsque je consulte par exemple cette image :

http://osm107.openstreetmap.fr/jbtopo/LeSappeyGPS.png

Et le rendu CycleMap de la même zone sur OSM :

http://osm.org/go/0CATAqPL-?layers=C

Les trous constatés sur la première n'existent pas sur le second. CycleMap 
utilise-t-il d'autres données (Aster, autre) ?

Sébastien


-- 
Sébastien Dinot, sebastien.di...@free.fr
http://sebastien.dinot.free.fr/
Ne goûtez pas au logiciel libre, vous ne pourriez plus vous en passer !


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

Re: [OSM-talk-fr] Rendu topo 25000ème (Bobo)

[Romain MEHUT]

Le 4 avril 2013 08:53,  a écrit :

> Bonjour,
>
> - Mail original -
> > Pour la licence, j'appuie sur le côté NC, faut bien voir auprès de
> > qui tu souhaite partager ces techniques.
>
> À propos de licence, je vais faire mon pénible mais alors que je
> m'apprêtais à diffuser ce message à des amis, je me suis posé une question
> : quelle est la licence du tutoriel ? Là encore, une licence CC By(-SA)
> serait la bienvenue pour encourager les contributions.
>

C'est précisé tout à la fin du tutoriel: "*Ce tutoriel a été réalisé par JB
(http://www.openstreetmap.org/user/JBacc1), il est placé sous une licence
CC-by-sa (http://creativecommons.org/licenses/by-sa/2.0/fr/). Vous êtes
libre de le reproduire, le modifier, sous réserve de citer l'auteur
original, et de publier le nouveau document sous une licence similaire.*"

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

Re: [OSM-talk-fr] Rendu topo 25000ème

[clansco]

On Wed, 3 Apr 2013 21:04:21 +0200
Sébastien Dinot  wrote:

> JB a écrit :
> 
[.../...]
> > On note que la donnée SRTM (courbes de niveau et ombrage) est parfois
> > manquante, notamment dans les zones au relief accidenté.
> 
> Je ne connaissais pas ce défaut de SRTM que je n'avais notamment jamais
> remarqué dans les Pyrénées. C'est étrange...
> 
http://maperitive.net/docs/Commands/SetDemSource.html
VF.Alps: one arcsecond resolution DEM covering Alps without any major 
data voids. 
Source: http://www.viewfinderpanoramas.org/dem3.html#alps.
valable aussi pour les Pyrénées.



-- 
Frédéric Falsetti
http://clansco.org

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

Re: [OSM-talk-fr] Rendu topo 25000ème (Bobo)

[sebastien . dinot]

Bonjour,

- Mail original -
> Pour la licence, j'appuie sur le côté NC, faut bien voir auprès de
> qui tu souhaite partager ces techniques.

À propos de licence, je vais faire mon pénible mais alors que je m'apprêtais à 
diffuser ce message à des amis, je me suis posé une question : quelle est la 
licence du tutoriel ? Là encore, une licence CC By(-SA) serait la bienvenue 
pour encourager les contributions.

Sébastien

-- 
Sébastien Dinot, sebastien.di...@free.fr
http://sebastien.dinot.free.fr/
Ne goûtez pas au logiciel libre, vous ne pourriez plus vous en passer !


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

[OSM-talk-fr] Rafraichissement des tuiles, sur tile.openstreetmap.fr

[Francescu GAROBY]

Bonjour,
Il semblerait que le rafraichissement des tuiles ne se fasse plus : j'ai
par exemple cette
tuilequi date
du 27 mars, alors que j'ai fait des modifications hier soir (cf.
la même tuile sur Mapnik
).
Rien ne se met à jour, malgré des demandes de rafraichissement forcé, avec
"/dirty".

La mise à jour serait-elle interrompue ?

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