Re: [OSM-talk-fr] Utiliser les serveurs de l'asso osm-fr

[Philippe Verdy]

Je ne suis pas convaincu par ce concept, qui a aussi le défaut de ne
pas permettre une liberté de déploiement. D'ailleurs en prétendant
pouvoir supporter différentes distributions de Linux sur une même base
Linux, les techniques de "paravirtualisation" deviennent nécessaires,
avec pour conséquence de devoir modifier les installations des
machines virtuelles installées, et de les lier assez fortement au
système hôte.

Je ne suis pas non plus convaincu de la sécurité (elle peut être
logicielle mais ne pas survivre à un crash d'un VM et pas sans effet
non plus sur les autres VM).

Le monde est plutôt parti sur la technologie des hyperviseurs, qui
souffre de moins en moins des problèmes de performance passés, et
permet beaucoup plus de contrôle par l'hyperviseur que par le
micro-noyau utilisé dans le concept des containers, et qui n'offre pas
assez de services ni de réelle sécurité, malgré l'isolation qu'ils
sont sensés apporter. De plus cela impose des contraintes très fortes
sur les possibilités de migration d'une machine virtuelle vers une
autre avec un autre OS, puisqu'il sera très rarement possible de les
migrer toutes en même temps.

L'avantage en terme de performance ne va qu'en décroissant, les
plateformes utilisées pour la virtualisation employant de plus en plus
les processeurs modernes effectuant une virtualisation très sure au
niveau du matériel, même sans utiliser aucune instruction privilégiée
dans l'OS invité. Si instruction privilégiée il y a, ce n'est pas pour
les OS invités mais pour l'hyperviseur lui-même, et ce sera le cas
aussi dans le cas du micro-noyau supportant le principe du container.

Reste alors à savoir s'il n'y a pas un juste milieu entre les deux
approches, où une partie significative des services serait assurée par
l'hyperviseur au lieu d'être répliquée dans chaque VM des OS invités.
Là interviennent les techniques de paravirtualisation qui sont déjà
très efficaces pour obtenir des performances élevées.

Cela passe par des pilotes de périphérique installables de façon
normale sur les OS invités, mais qui effectivement font des appels
privilégiés à l'hyperviseur, qui d'abord s'assurera de conserver
l'isolation et la sécurité, et du respect du partage des ressources
entre les utilisations demandées par les OS invités dans leur VM. La
paravirtualisation ne fonctionne en effet bien que si les invités sont
à peu près homogènes dans leurs fonctions (mais on peut aussi dire que
les OS diffèrent de moins en moins en ce qui concerne ce qu'ils
supportent et demandent à leur plateforme hôte, car des tas de nomes
sont passées par là, y compris le Plug-n-Play, le standard PCI, les
bus utilisés dont les quasi-universels USB et Ethernet, les normes
graphiques comme OpenGL)

De fait, les trois techniques sont appelées à converger au point qu'on
ne pourra plus les distinguer, permettant de la souplesse entre ce
qu'on laisse faire dans chaque VM d'invité, et ce qu'on peut faire
dans l"hyperviseur, fonctionnant aussi comme un OS classique, capable
sans doûte dans le futur d'être lui-même virtualisé et remplaçable
même à la volée sans que les VM invitées ne s'en aperçoivent (hormis
peut-être juste une courte pause lors du déplacement, comparable à ce
qu'aurait produit une mise en veille et les différentes techniques
d'économie d'énergie qu'on trouve maintenant, le but à atteindre étant
de ne presque plus jamais avoir à rebooter un OS invité, ni même
l'hyperviseur ; on n'en est plus très loin, et ensuite on sera à l'ère
du tout "cloud" extensible à l'infini aussi bien sur un réseau privé
que chez des hébergeurs externes, et plus tard aussi sur des machines
au départ inconnues ayant de la puissance de calcul immédiatement
accessible à la demande pour du calcul distribué...).

Le 25 février 2012 00:30, Christian Quest  a écrit :
> openvz n'est pas un hyperviseur au sens de VirtualBox, VMware ou autre
> virtualiseur de hardware et peut donc difficilement leur être comparé.
>
> On utilise plutôt le terme de container à envisager comme un super
> chroot qui ne se limite pas aux fichiers mais à tout ce qui touche au
> kernel.
>
> C'est donc une virtualisation au niveau OS, qui permet d'être "root"
> dans son container sans être root sur la machine et facilite
> grandement la migration d'un serveur virtuel d'une machine à l'autre.
> Un seul noyau linux (modifié) tourne sur la machine physique ce qui
> permet une bien plus grande densité (nombre de VM exploitables pour un
> même hardware) et une meilleure coordination de l'ensemble.
> Par exemple, la RAM utilisée est vraiment minimisée car limitée aux
> seuls besoin réels des process qui tournent et donc des applis.
>
> openvz ne nécessite donc aucune technologie additionnelle au niveau du
> CPU pour être (à peut près) efficace.
>
> Sa principale (seule ?) limite est de n'offrir que de la
> virtualisation linux/linux mais vu que l'immense majorité des
> logiciels que nous utilisons sur nos serveurs viennent de ce monde,
> cela n'est pas vraiment une limita

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

[Christian Quest]

Le 24 février 2012 20:01, Emilie Laffray  a écrit :
> Bonjour,
>
> suite a ces discussions fortes interessantes sur le bon usage de la langue
> anglaise par des francais, je suis allee demander a des gens qui pratiquent
> l'anglais depuis leur naissance histoire d'avoir un avis eclaire sur le
> sujet.
> J'ai donc procede en leur presentant les mots qui ont ete propose i.e. dip,
> hollow et groove.
> On m'a clairement repondu dip avec un traffic_calming=dip avec ce genre
> d'icone
> http://ts3.mm.bing.net/images/thumbnail.aspx?q=1593058400322&id=f1652b269c03bf952fb45b21bf286991&url=http%3a%2f%2fwww.picturesof.net%2f_images_300%2fDip_In_Road_Warning_Sign_Royalty_Free_Clipart_Picture_090616-191408-967048.jpg
>
> J'espere que cela permettra de choisir la meilleure chose :)
>

Je crois d'ailleurs avoir vu des panneaux routiers indiquant "dip" aux USA.

Confirmé par la recherche d'images de Google sur "dip road sign"

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

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

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

[Christian Quest]

Le 24 février 2012 11:13, Vladimir Vyskocil
 a écrit :
> Je suis allé voir sur le terrain et la route a bien un panneau "sens interdit 
> sauf riverain" à chaque bout, donc la solution acces=destination est la bonne.

Oui, dans ce cas (sens interdit "sauf riverain" aux deux bouts) c'est
bien access=destination et pas oneway et encore moins un double tracé
!

> A la base je me suis interrogé car en essayant le logiciel Waze j'ai vu qu'il 
> routait par ce chemin... Ils gagneraient beaucoup en qualité de routage a 
> passer sur OSM... Et OSM y gagnerait surement aussi, mais bon c'est comme ça.
>

Sûrement à cause d'un riverain qui doit utiliser Waze... ;)


Pour le tracé par surface non corrigé, j'ai moi aussi parfois du mal à
supprimer le travail d'un précédent contributeur quand j'imagine le
temps passé !

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

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

Re: [OSM-talk-fr] Utiliser les serveurs de l'asso osm-fr

[Christian Quest]

openvz n'est pas un hyperviseur au sens de VirtualBox, VMware ou autre
virtualiseur de hardware et peut donc difficilement leur être comparé.

On utilise plutôt le terme de container à envisager comme un super
chroot qui ne se limite pas aux fichiers mais à tout ce qui touche au
kernel.

C'est donc une virtualisation au niveau OS, qui permet d'être "root"
dans son container sans être root sur la machine et facilite
grandement la migration d'un serveur virtuel d'une machine à l'autre.
Un seul noyau linux (modifié) tourne sur la machine physique ce qui
permet une bien plus grande densité (nombre de VM exploitables pour un
même hardware) et une meilleure coordination de l'ensemble.
Par exemple, la RAM utilisée est vraiment minimisée car limitée aux
seuls besoin réels des process qui tournent et donc des applis.

openvz ne nécessite donc aucune technologie additionnelle au niveau du
CPU pour être (à peut près) efficace.

Sa principale (seule ?) limite est de n'offrir que de la
virtualisation linux/linux mais vu que l'immense majorité des
logiciels que nous utilisons sur nos serveurs viennent de ce monde,
cela n'est pas vraiment une limitation

Pour plus d'info, vous pouvez consulter cette présentation au FOSDEM
2012 au sujet d'openvz:
http://video.fosdem.org/2012/maintracks/janson/Linux_containers_and_OpenVZ.webm

Et pour une version courte le wiki d'openvz:
http://wiki.openvz.org/Introduction_to_virtualization

Ca m'évitera d'en faire un pseudo copier/coller.
-- 
Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest

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

Re: [OSM-talk-fr] Changements incomplets sur les différents niveaux de zoom

[Philippe Verdy]

Le 24 février 2012 18:59, sly (sylvain letuffe)  a écrit :
> On vendredi 24 février 2012, Philippe Verdy wrote:
>
>> Et dans ce cas il n'est pas absurde d'augmenter la précision des
>> tracés selon la précision que l'on demande ensuite pour les rendus
>
> si
>
> Le nombre de point n'a pas a être augmenté artificiellement dans la base OSM
> si celui-ci n'améliore pas la précision.

C'est bien ce que je dis non ? J'ai bien parlé d'augmenter la
précision, peut-être que tu préfère les termes améliorer la précision,
mais personnellement je ne vois pas la différence.

Une augmentation artificielle en revanche serait de placer un point au
milieu d'un segment tout en conservant son strict alignement. C'est
pourtant nécessaire au delà d'une certaine distance, sur des lignes
qui sont par nature complètement droites.

Ces lignes ne sont que de rares frontières administratives, et encore
on peut trouver des exceptions assez souvent sur un tracé initialement
droit qui a été adapté localement à la réalité du terrain, car pour le
reste il n'y a rien qui soit absolument droit sur des distances très
longues, et les frontières maritimes sont très rarement droites sur
des distances très longues, mais résultent d'arrangements frontaliers
entre deux pays, avec des segments ne dépassant pas la centaine de
kilomètres, et uniquement en pleine mer, le tracé prenant la forme de
plusieurs segments en fonction des points où peuvent être posés des
balises de repérage, donc finalement pas si loin des côtes d'un pays
ou d'un autre.

Ensuite il reste des frontières administratives intérieures à un même
pays; là encore la réalité du terrain vient les modifier assez
régulièrement même si le changement est minime à l'échelle de la
frontière entière. Et sinon il reste les délimitations régionales en
mer, qui ne vont pas au delà des 12 miles.

Que reste-t-il enfin de "droit" ?

Des rues ? il y a souvent bien assez d'occasions pour ajouter des
points sur des passages piétons et branchements vers d'autres rues ou
voies de service ou privées mineures.

Des autoroutes peut-être (et encore, elles ne sont que rarement toute
droites sur des distances longues).

Je n'ai pas vu de cas encore où il n'était pas possible d'améliorer la
précision d'un tracé, même sans ajouter de nœuds mais en rectifiant le
parallélisme avec d'autres voies, le centrage d'un carrefour, ou la
disposition de séparation des voies d'une route. On trouve assez de
ponts et carrefours pour nécessiter des ajustements (plus que la
distance entre les points c'est souvent l'angle entre les segments qui
demande à être mieux représenté). Ensuite il y aura bien assez de
changements à faire car les cartes sont vivantes comme l'est aussi la
réalité.

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

Re: [OSM-talk-fr] Utiliser les serveurs de l'asso osm-fr

[Philippe Verdy]

Le 24 février 2012 20:53, Christian Quest  a écrit :
> Le "sous peu" dépend de Dell, en rupture de disque-durs... et de la
> signature d'une convention.
>
> Sinon, côté virtualisation, virtualbox c'est utile si on veut faire
> tourner du non-linux, sinon, il vaut mieux se tourner vers openvz,
> nettement plus efficace et économe en ressources.

Peu importe, les machines virtuelles pour divers OS (pas que Windows
ou Linux) peuvent normalement fonctionner sur différents types
d'hyperviseurs, que ce soit VirtualBox, OpenVZ, ou des hyperviseurs
commerciaux comme Windows Virtual Server ou VMware, et d'autres
hyperviseurs "maison" gérés et fournis par les hébergeurs (selon ce
qu'ils veulent facturer : espace disque, mémoire, CPU, bande passante,
services de sauvegarde, systèmes redondants, avec ou sans
mutualisation du matériel, sachant que les techniques actuelles
évoluent en faveur de la mutualisation de matériels pour privilégier
la redondance, le maintien du service et l'évolutivité d'échelle, la
mutualisation n'étant pas un frein en terme de performance garantie,
ni de faculté de déploiement sur des sites multiples suivant le
principe très à la mode du "cloud").

Cependant, certains OS invités peuvent demander l'installation dans la
machine virtuelle de certains pilotes spécifiques à l'hyperviseur,
pour obtenir des performances acceptables ou certaines fonctions. En
général cela concerne l'interface réseau virtuelle, le support d'une
interface graphique 2D/3D avec de bonnes performances OpenGL ou la
programmation native ultraparallélisée pour GPU, et quelques
interfaces de supervision donnant accès à certaines fonctions de
l'hyperviseur telles que le démarrage à distance, ou le déclenchement
des sauvegardes dans un état stable. Ces pilotes spécifiques devraient
normalement être "plug-n-play" et donc se désactiver tous seuls si on
déplace une machine virtuelle vers un autre type d'hyperviseur ou sur
une autre architecture (par exemple changement de technologie du
processeur entre Intel et AMD, le contrôle de l'affectation des cœurs
de CPU utilisés par l'OS invité). Ce n'est pas toujours le cas
cependant car un OS a pu être installé avec le support d'APIC et ne
pas supporter la transition vers un hyperviseur qui n'offre pas ce
support (c'est le cas de Windows qui ne permet que la transition
inverse, non réversible une fois qu'APIC a été activé dans l'OS
invité, sinon ça plante complètement et c'est difficilement
réparable).

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

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

[Vincent Calame]

Le 24/02/2012 16:44, Gilles Bassière a écrit :
- les naturalistes sont souvent cramponnés au secret de leur données, 
comment alors organiser la collecte et le partage d'information ? 
Cordialement 


Une petite précision : la confidentialité des données a aussi une raison 
objective, celle de la protection des espèces. On n'indique pas 
l'emplacement de l'aire d'un hibou grand duc à 5m près, les risques de 
destruction ou de dénichage sont trop grands.


Pour ce qui j'ai pu lire des informations de la LPO, le recensement des 
oiseaux se fait sur la base de carrés de 5 km de côté (je dis ça de 
mémoire) choisi suivant des méthodes statistiques.


Cela n'enlève en rien l'intérêt d'un SIG, bien sûr, mais si on voulait 
les convaincre avec une belle carte, il faudrait mieux travailler à 
l'échelle du kilomètre.


Vincent


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

Re: [OSM-talk-fr] Utiliser les serveurs de l'asso osm-fr

[sly (sylvain letuffe)]

On vendredi 24 février 2012, Gilles Bassière wrote:
> Cela dit, je pense surtout à des "petits services pas trop
> perturbateurs" : maintenir à jour une (ou plusieurs) pyramides de tuiles
> à l'échelle de l'agglomération de Marseille. Si on considère que la base
> de données sous-jacente est mutualisée (osm7 si j'ai bien compris) et
> qu'on s'en tient à une fréquence de mise à jour basse, alors la charge
> n'est pas colossale.

J'ai nettoyer cette page au karsher :
http://wiki.openstreetmap.org/wiki/FR:Servers

Il y a maintenant une place tout indiquée pour les projets "a l'état d'idées" 
(préparer le terrain afin d'éviter au dernier moment de se retrouver avec un 
refus)

Et une place pour les projets à l'état de "cherche maison"

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

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

Re: [OSM-talk-fr] Utiliser les serveurs de l'asso osm-fr

[Christian Quest]

Le "sous peu" dépend de Dell, en rupture de disque-durs... et de la
signature d'une convention.

Sinon, côté virtualisation, virtualbox c'est utile si on veut faire
tourner du non-linux, sinon, il vaut mieux se tourner vers openvz,
nettement plus efficace et économe en ressources.

Si vous avez besoin d'aide pour vous lancer avec openvz, demandez-moi,
je le pratique depuis déjà quelques temps.

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

Re: [OSM-talk-fr] Utiliser les serveurs de l'asso osm-fr (était : Re: Une carte orientée biologie ? (arbres, insectes, oiseaux, plantes))

[Christian Quest]

Le 24 février 2012 19:01, Gilles Bassière  a écrit :
> Le vendredi 24 février 2012 à 18:06 +0100, Ab_fab a écrit :
>
>> Par contre, imaginons qu'une structure impliquée dans la géomatique
>> libre et plus précisément OSM ait accès à
>> _ un hébergement confortable
>> _ des machines non moins confortables
>> _ la possibilité d'y monter des machines virtuelles adaptées aux
>> besoins des développeurs
>>
>> Elle pourrait mettre à disposition un espace pilote, permettant le
>> défrichage technique pour ce type d'applications "de niche".
>>
>> Si l'usage décolle et charge le système, la structure peut décréter
>> que ses ressources matérielles n'ont pas pour vocation prioritaire
>> d'héberger ce genre de projets "périphériques" à son coeur d'activité.
>>
>> Mais dans le même temps, c'est le signe que la masse critique sera
>> atteinte pour aller ouvrir un serveur chez un hébergeur ou bien lancer
>> un service commercial indépendant de prestation, aux coûts de
>> fonctionnements mutualisés entre les utilisateurs
>>
>> Bref, même si cela sort du contexte pur et dur OSM, en tant
>> qu'adhérent de l'asso osm-fr, je ne serais vraiment pas choqué que ce
>> genre d'initiative soit mis en place sur les serveurs de l'asso.
>
>
> Effectivement, les applis tournant autour d'OSM ont des besoins que peu
> d'hébergements mutualisés peuvent satisfaire. Et tous les développeurs
> n'ont pas les moyens ou l'envie de louer et gérer un serveur dédié. Il
> serait donc intéressant de pouvoir mutualiser des serveurs/services.
>
> Lors de la rencontre entre mappeurs hier à Marseille [1], nous avons
> évoqués plusieurs idées dont la réalisation demanderait notamment : une
> réplique de la BD mise à jour automatiquement, de quoi générer des
> tuiles, un serveur Web, etc.
>
> Ces idées sont encore très floues (ce ne sont que des idées, pas encore
> des projets). Mais en y repensant, j'en suis quand même arrivé aux mêmes
> questions qu'Ab_fab. En particulier, je me demandais s'il était possible
> d'occuper un peu d'espace sur le parcs de serveur dont dispose
> l'association [2]. Est-ce qu'une politique a déjà été définie au sein de
> l'association à ce sujet ?
>
> [1] http://wiki.openstreetmap.org/wiki/Marseille/R%C3%A9unions_2012
> [2] http://wiki.openstreetmap.org/wiki/FR:Servers
>
> Cordialement
> --
> Gilles Bassière - Web/GIS software engineer
> http://gbassiere.free.fr/
>


Bonsoir Gilles,

L'association a aussi pour vocation de mettre en commun des ressources
techniques.
Nous avons déjà un ensemble de serveurs qui sont effectivement décrits
sur http://wiki.openstreetmap.org/wiki/FR:Servers

Nous devrions compléter ceux-ci très prochainement par plusieurs
nouveaux serveurs, soit du même type, soit nettement plus puissants.

La mise en commun permet aussi de se répartir les tâches ou de les
mutualiser. Par exemple, sur osm7 une base France est disponible avec
les 2 schémas osmosis et osm2pgsql. Ceci me permet sur le site web de
faire des pages d'outil qui interrogent cette base, sans avoir à me
préoccuper de la maintenance de cette base (merci Jocelyn et Fred).

Nous avons une ML technique: t...@listes.openstreetmap.fr  dispo sur
http://listes.openstreetmap.fr/wws/info/tech
-- 
Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest

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

Re: [OSM-talk-fr] Utiliser les serveurs de l'asso osm-fr

[Jocelyn Jaubert]

Le 24 février 2012, sly (sylvain letuffe) a écrit :
> 
> > Ok. J'avais bêtement cru que les 4 serveurs qui sont en orange avec
> > un hébergement n'attendaient plus qu'un OS et des développeurs
> > faire monter la charge :)
> 
> Alors j'avoue que je ne me suis même pas posé la question, pour moi :
> "pas installé" ça voulait dire : "serveur dans ma cave en attente
> d'une vrai maison"

C'est bien le cas: tous les serveurs marqués "pas installé" sont
rangés, et attendent un hébergement. À noter que ces machines n'ont pas
beaucoup de disque dur de base, et qu'il faut faire des modifications
si on veut plus de 100 Go.


> > Si on considère que la base 
> > de données sous-jacente est mutualisée (osm7 si j'ai bien compris)
> > et qu'on s'en tient à une fréquence de mise à jour basse, alors la
> > charge n'est pas colossale.
> 
> Tout à fait, osm7 me semble avoir encore un peu de marge et je
> m'occupe de maintenir la base france à jour, mais j'ai cru comprendre
> que la BP disponible devrait être gardée basse et donc les tuiles ne
> sont pas forcément les bien venus, mais je pense que c'est surtout
> que si 1 mois après la mise en place on vous demande de déménager,
> c'est relou.

Yep, osm7 et osm8 doivent garder une BP faible. Il est quand même
possible d'y mettre des services qui ont besoin d'une base de donnée,
tant que ce n'est pas du rendu de tuiles.

Normalement, on devrait avoir des machines sous peu avec plus de bande
passante - c'est juste le "sous peu" que je ne peux pas quantifier :)


-- 
Jocelyn

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

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

[Philippe Verdy]

Selon la nature et la fonction du cassis, il peut y avoir plusieurs traductions.
- si c'est un dommage accidentel ou fortuit, il n'est pas forcément à
cartographier, et reste temporaire jusqu'à sa réparation
- si c'est pour évacuer les eaux, on a le terme "drain" en anglais.
- sinon c'est un ralentisseur, et ça se cartographie comme tel avec
"traffic_calming".

Le 24 février 2012 19:51, Emilie Laffray  a écrit :
> 
> Non mais hollow ca fait plutot vide de sens
> 
>
> Ce fut une tentative d'humour foireuse d'Emilie Laffray.
> Plus serieusement, hollow ou groove bien que le dictionnaire donne une
> definition correct ne sont generalement pas utilises dans ces sens la. Donc
> attention a trop se fier a un dictionnaire qui peut mener a des sens parfois
> bizarre pour des natifs.
>
> Emilie Laffray
>
>
> 2012/2/24 Fabien 
>>
>> Le 23 février 2012 22:28, Philippe Verdy  a écrit :
>> > Le 23 février 2012 13:05, Christian Rogel
>> >  a écrit :
>> >> - pothole, mais c'est apparemment dans le sens d'un dommage qui peut
>> >> être un trou ou un effondrement.
>> >> Cela semble plus proche du sens de cassis
>> >
>> > A mon avis ça traduit mieux ce qu'on connait comme des « nids de poule
>> > », jamais souhaités, souvent causés par le dégel et le passage
>> > d'engins trop lourds,  et à priori provisoires jusqu'à leur rebouchage
>> > (quand la route est un minimum entretenue).
>> >
>> >> - dip, mais cela désigne plutôt les variations d'altitude le la route.
>> >>
>> >> Pothole est un bon candidat.
>> >
>> > Moi je traduirais plutôt "hollow" (et son contraire le "ridge" qui est
>> > un dos d'âne très étroit qu'il vaut mieux aussi ne pas prendre à
>> > grande vitesse si on ne veut pas se cogner la tête, déchausser ou
>> > éclater un pneu, ou encore défoncer sa suspension, bien que le terme
>> > "ridge" soit un peu trop large et recouvre n'importe quelle crête,
>> > voire aussi un récif sur un rivage, ou encore une corniche surplombant
>> > un ravin).
>> >
>> > On a aussi "groove" peut-être mieux adapté aux petits creux linéaires
>> > (on trouve les deux termes "ridge" et "groove" souvent utilisés en
>> > opposition, pour désigner le style de fine bordure, en relief ou en
>> > creux, des cadres en CSS), et qu'on traduit comme "rainure",
>> > "cannelure", "rigole", "strie", "gorge"...
>> >
>> > ___
>> > Talk-fr mailing list
>> > Talk-fr@openstreetmap.org
>> > http://lists.openstreetmap.org/listinfo/talk-fr
>>
>> Salut,
>>
>> hollow me plait pas mal. D'après le Oxford English Dictionary : a
>> surface concavity, more or less deep, an excavation, a depression on
>> any surface.
>>
>> Par contre groove, dans le Oxford : A channel or hollow, cut by
>> artificial means, in metal, wood, etc.; e.g. the spiral rifling of a
>> gun, one of the air-passages leading from the wind-chest to the pipes
>> of an organ, etc.
>> Indique channel :  The watercourse in a street or by a roadway, the gutter
>>
>> Bon j'attends que mon contact (professeur d'anglais) me réponde et
>> après je tranche.
>>
>> Fabien
>>
>> ___
>> 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] Utiliser les serveurs de l'asso osm-fr

[sly (sylvain letuffe)]

> Ok. J'avais bêtement cru que les 4 serveurs qui sont en orange avec un
> hébergement n'attendaient plus qu'un OS et des développeurs faire monter
> la charge :)

Alors j'avoue que je ne me suis même pas posé la question, pour moi : "pas 
installé" ça voulait dire : "serveur dans ma cave en attente d'une vrai 
maison"

Mais en effet, vu que ça donne le nom d'un hébergeur, ça vaut le coût de 
savoir ce qu'il en ait vraiment, je vais donc poser la question à Mat, en 
copie, qui est listé comme le mainteneur de ces 4 serveurs.

> Cela dit, je pense surtout à des "petits services pas trop
> perturbateurs" : maintenir à jour une (ou plusieurs) pyramides de tuiles
> à l'échelle de l'agglomération de Marseille. 

En effet, ça devrait pas être la mort. 
Si j'ai bien compris les plans futurs, une nouvelle machine pourrait être mise 
en batterie pour faire des rendus, ce qui impliquera sans doute une base 
osm2pgsql france, ou même europe ou monde sur laquelle pourrons se greffer 
plein de projet de rendu spécifiques/test de plusieurs développeurs sans que 
l'on ait besoin de maintenir N bases de ce type.

> Si on considère que la base 
> de données sous-jacente est mutualisée (osm7 si j'ai bien compris) et
> qu'on s'en tient à une fréquence de mise à jour basse, alors la charge
> n'est pas colossale.

Tout à fait, osm7 me semble avoir encore un peu de marge et je m'occupe de 
maintenir la base france à jour, mais j'ai cru comprendre que la BP 
disponible devrait être gardée basse et donc les tuiles ne sont pas forcément 
les bien venus, mais je pense que c'est surtout que si 1 mois après la mise 
en place on vous demande de déménager, c'est relou.

A discuter sur t...@liste.openstreetmap.fr avec le "chef de groupe"

> Attendons alors ! :)

Avec une dead line et solution de repli ;-)



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

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

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

[Emilie Laffray]

Bonjour,

suite a ces discussions fortes interessantes sur le bon usage de la langue
anglaise par des francais, je suis allee demander a des gens qui pratiquent
l'anglais depuis leur naissance histoire d'avoir un avis eclaire sur le
sujet.
J'ai donc procede en leur presentant les mots qui ont ete propose i.e. dip,
hollow et groove.
On m'a clairement repondu dip avec un traffic_calming=dip avec ce genre
d'icone
http://ts3.mm.bing.net/images/thumbnail.aspx?q=1593058400322&id=f1652b269c03bf952fb45b21bf286991&url=http%3a%2f%2fwww.picturesof.net%2f_images_300%2fDip_In_Road_Warning_Sign_Royalty_Free_Clipart_Picture_090616-191408-967048.jpg

J'espere que cela permettra de choisir la meilleure chose :)

Emilie Laffray

2012/2/24 Fabien 

> Le 23 février 2012 22:28, Philippe Verdy  a écrit :
> > Le 23 février 2012 13:05, Christian Rogel
> >  a écrit :
> >> - pothole, mais c'est apparemment dans le sens d'un dommage qui peut
> être un trou ou un effondrement.
> >> Cela semble plus proche du sens de cassis
> >
> > A mon avis ça traduit mieux ce qu'on connait comme des « nids de poule
> > », jamais souhaités, souvent causés par le dégel et le passage
> > d'engins trop lourds,  et à priori provisoires jusqu'à leur rebouchage
> > (quand la route est un minimum entretenue).
> >
> >> - dip, mais cela désigne plutôt les variations d'altitude le la route.
> >>
> >> Pothole est un bon candidat.
> >
> > Moi je traduirais plutôt "hollow" (et son contraire le "ridge" qui est
> > un dos d'âne très étroit qu'il vaut mieux aussi ne pas prendre à
> > grande vitesse si on ne veut pas se cogner la tête, déchausser ou
> > éclater un pneu, ou encore défoncer sa suspension, bien que le terme
> > "ridge" soit un peu trop large et recouvre n'importe quelle crête,
> > voire aussi un récif sur un rivage, ou encore une corniche surplombant
> > un ravin).
> >
> > On a aussi "groove" peut-être mieux adapté aux petits creux linéaires
> > (on trouve les deux termes "ridge" et "groove" souvent utilisés en
> > opposition, pour désigner le style de fine bordure, en relief ou en
> > creux, des cadres en CSS), et qu'on traduit comme "rainure",
> > "cannelure", "rigole", "strie", "gorge"...
> >
> > ___
> > Talk-fr mailing list
> > Talk-fr@openstreetmap.org
> > http://lists.openstreetmap.org/listinfo/talk-fr
>
> Salut,
>
> hollow me plait pas mal. D'après le Oxford English Dictionary : a
> surface concavity, more or less deep, an excavation, a depression on
> any surface.
>
> Par contre groove, dans le Oxford : A channel or hollow, cut by
> artificial means, in metal, wood, etc.; e.g. the spiral rifling of a
> gun, one of the air-passages leading from the wind-chest to the pipes
> of an organ, etc.
> Indique channel :  The watercourse in a street or by a roadway, the gutter
>
> Bon j'attends que mon contact (professeur d'anglais) me réponde et
> après je tranche.
>
> Fabien
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

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

[Emilie Laffray]

Non mais hollow ca fait plutot vide de sens


Ce fut une tentative d'humour foireuse d'Emilie Laffray.
Plus serieusement, hollow ou groove bien que le dictionnaire donne une
definition correct ne sont generalement pas utilises dans ces sens la. Donc
attention a trop se fier a un dictionnaire qui peut mener a des sens
parfois bizarre pour des natifs.

Emilie Laffray

2012/2/24 Fabien 

> Le 23 février 2012 22:28, Philippe Verdy  a écrit :
> > Le 23 février 2012 13:05, Christian Rogel
> >  a écrit :
> >> - pothole, mais c'est apparemment dans le sens d'un dommage qui peut
> être un trou ou un effondrement.
> >> Cela semble plus proche du sens de cassis
> >
> > A mon avis ça traduit mieux ce qu'on connait comme des « nids de poule
> > », jamais souhaités, souvent causés par le dégel et le passage
> > d'engins trop lourds,  et à priori provisoires jusqu'à leur rebouchage
> > (quand la route est un minimum entretenue).
> >
> >> - dip, mais cela désigne plutôt les variations d'altitude le la route.
> >>
> >> Pothole est un bon candidat.
> >
> > Moi je traduirais plutôt "hollow" (et son contraire le "ridge" qui est
> > un dos d'âne très étroit qu'il vaut mieux aussi ne pas prendre à
> > grande vitesse si on ne veut pas se cogner la tête, déchausser ou
> > éclater un pneu, ou encore défoncer sa suspension, bien que le terme
> > "ridge" soit un peu trop large et recouvre n'importe quelle crête,
> > voire aussi un récif sur un rivage, ou encore une corniche surplombant
> > un ravin).
> >
> > On a aussi "groove" peut-être mieux adapté aux petits creux linéaires
> > (on trouve les deux termes "ridge" et "groove" souvent utilisés en
> > opposition, pour désigner le style de fine bordure, en relief ou en
> > creux, des cadres en CSS), et qu'on traduit comme "rainure",
> > "cannelure", "rigole", "strie", "gorge"...
> >
> > ___
> > Talk-fr mailing list
> > Talk-fr@openstreetmap.org
> > http://lists.openstreetmap.org/listinfo/talk-fr
>
> Salut,
>
> hollow me plait pas mal. D'après le Oxford English Dictionary : a
> surface concavity, more or less deep, an excavation, a depression on
> any surface.
>
> Par contre groove, dans le Oxford : A channel or hollow, cut by
> artificial means, in metal, wood, etc.; e.g. the spiral rifling of a
> gun, one of the air-passages leading from the wind-chest to the pipes
> of an organ, etc.
> Indique channel :  The watercourse in a street or by a roadway, the gutter
>
> Bon j'attends que mon contact (professeur d'anglais) me réponde et
> après je tranche.
>
> Fabien
>
> ___
> 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] Utiliser les serveurs de l'asso osm-fr

[Gilles Bassière]

Le vendredi 24 février 2012 à 19:15 +0100, sly (sylvain letuffe) a
écrit :
> > Effectivement, les applis tournant autour d'OSM ont des besoins que peu
> > d'hébergements mutualisés peuvent satisfaire. Et tous les développeurs
> > n'ont pas les moyens ou l'envie de louer et gérer un serveur dédié. Il
> > serait donc intéressant de pouvoir mutualiser des serveurs/services.
> 
> Ce projet était à l'un des ordres du jour du groupe technique auquel j'ai 
> participé et j'ai pas mal avancé sur ce projet dont les grandes lignes sont :
> - fournir des machines virtuelles "socle" sous virtualbox avec les outils 
> nécessaires aux opérations de rendu, import de base osm ce qui permettrait de 
> faire des tests/dev et éventuellement mise en place à long terme 
> d'applications.
> Ces machines virtuelles tourneraient et pourraient aussi être 
> dupliquée/téléchargées pour usage locale/ailleurs et auraient pour but de 
> simplifier l'accès aux développeurs souhaitant mettre en oeuvre des outils.
> 
> Mon premier prototype est prêt et je commence à maîtriser suffisamment 
> virtualbox pour une mise en place.

Ok, bravo pour cet effort ! :)

> N'étant pas membre de l'association, je ne me prononcerais pas sur le public 
> visé et ceux pouvant en profiter, mais mon avis personnel et que les serveurs 
> de l'asso devraient avant tout servir les contributeurs, mais ce n'est que 
> mon avis.
> 
> > En particulier, je me demandais s'il était possible
> > d'occuper un peu d'espace sur le parcs de serveur dont dispose
> > l'association [2]. Est-ce qu'une politique a déjà été définie au sein de
> > l'association à ce sujet ?
> 
> Si je suis en stand-by, c'est que tout le problème est là, les machines 
> actuelles sont vieillissantes et déjà pleines à craquer ou presque et il est 
> difficile d'ajouter autre chose que des petits services pas trop 
> perturbateurs.

Ok. J'avais bêtement cru que les 4 serveurs qui sont en orange avec un
hébergement n'attendaient plus qu'un OS et des développeurs faire monter
la charge :)

Cela dit, je pense surtout à des "petits services pas trop
perturbateurs" : maintenir à jour une (ou plusieurs) pyramides de tuiles
à l'échelle de l'agglomération de Marseille. Si on considère que la base
de données sous-jacente est mutualisée (osm7 si j'ai bien compris) et
qu'on s'en tient à une fréquence de mise à jour basse, alors la charge
n'est pas colossale.

> Mais j'espère que christian va nous annoncer bientôt une bonne nouvelle 
> concernant de nouvelles machines ;-)

Attendons alors ! :)

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



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

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

[Christian Rogel]

Le 24 févr. 2012 à 09:07, rldhont a écrit :

> Juste une précision sur la directive INSPIRE :
> * Les Etats membres se sont engagés à publier des données spatiales liées à 
> l'ENVIRONNEMENT mais pas toutes les données spatiales. Disons que c'est le 
> seul domaine dans lequel les états membres ont pensés qu'il n'y avait pas de 
> perte de souveraineté.
> 


Je ne crois pas que ce soit une question de souveraineté. Parmi les 34 thèmes 
concernés par la Directive et pour laquelle les Etats doivent mettre en place
des serveurs accessibles au public, il y a les unités administratives, les 
réseaux de transport, les services d'utilité publique et services publics et 
même 
les ressources minérales.

Cela est expliqué sur le site du  Ministère de l'Ecologie, du Développement 
durable, du Transport et du Logement :
http://www.developpement-durable.gouv.fr/La-directive-europeenne-Inspire-de.html

C'est l'existence de la a Convention d'Aarhus, signée par 39 Etats en 1998 qui 
a donné la couleur environnementale.

toute collectivité doit donner toute l'information qu'elle détient  en matière 
d'environnement à toute personne qui la lui demande (sans que cette personne
ait à justifier son identité ni du pourquoi de la demande). 
Toutefois, l'accès peut en être restreint dans le cadre de nuisances aux 
relations internationales, à la sécurité publique ou à la défense nationale.

Dans cette directive, les États sont aussi considérés comme des collectivités.
Voir : http://fr.wikipedia.org/wiki/Convention_d%27Aarhus

A noter qu'il n'est nul part indiqué que les données doivent être gratuites. 
Elles peuvent être fournies sur papier avec paiement du coût de reproduction,
mais, si une forme numérique existe, les fichiers doivent être disponibles.

La Directive Inspire concernant les données géographiques, il y a un lien 
évident avec l'environnement et ce n'est donc pas étonnant que les
34 thèmes concernent majoritairement celui-ci, car la Convention avait balisé 
le terrain et c'était donc plus simple.

C'est en application de la Convention qu'a été mis en place Corine Land Cover.

L'IGN explique que Inspire est arrivé dans le cadre défini par la Convention, 
donc, plutôt en tant que méthodologie.
http://inspire.ign.fr/index.php/inspire

Malheureusement, la France a attendu le 18 octobre 2007 pour décliner en droit 
français la Convention d'Aarhus dans une circulaire non publiée au JO. 

Et, il a fallu attendre 2009, avec un léger retard* par rapport à la date 
limite, pour  que que la Directive Inspire soit effectivement transposée en 
droit français.

D'où un retard énorme, par rapport aux Pays de l'Est européen, par exemple.

* On ne peut que soupçonner le motif du retard , mais, à l'époque, on avait des 
rumeurs de batailles rangées entre les différents organismes concernés.
  Encore une belle tradition française que le monde nous envie… ;-)



Christian (sans tirets)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Utiliser les serveurs de l'asso osm-fr

[sly (sylvain letuffe)]

> Effectivement, les applis tournant autour d'OSM ont des besoins que peu
> d'hébergements mutualisés peuvent satisfaire. Et tous les développeurs
> n'ont pas les moyens ou l'envie de louer et gérer un serveur dédié. Il
> serait donc intéressant de pouvoir mutualiser des serveurs/services.

Ce projet était à l'un des ordres du jour du groupe technique auquel j'ai 
participé et j'ai pas mal avancé sur ce projet dont les grandes lignes sont :
- fournir des machines virtuelles "socle" sous virtualbox avec les outils 
nécessaires aux opérations de rendu, import de base osm ce qui permettrait de 
faire des tests/dev et éventuellement mise en place à long terme 
d'applications.
Ces machines virtuelles tourneraient et pourraient aussi être 
dupliquée/téléchargées pour usage locale/ailleurs et auraient pour but de 
simplifier l'accès aux développeurs souhaitant mettre en oeuvre des outils.

Mon premier prototype est prêt et je commence à maîtriser suffisamment 
virtualbox pour une mise en place.

N'étant pas membre de l'association, je ne me prononcerais pas sur le public 
visé et ceux pouvant en profiter, mais mon avis personnel et que les serveurs 
de l'asso devraient avant tout servir les contributeurs, mais ce n'est que 
mon avis.

> En particulier, je me demandais s'il était possible
> d'occuper un peu d'espace sur le parcs de serveur dont dispose
> l'association [2]. Est-ce qu'une politique a déjà été définie au sein de
> l'association à ce sujet ?

Si je suis en stand-by, c'est que tout le problème est là, les machines 
actuelles sont vieillissantes et déjà pleines à craquer ou presque et il est 
difficile d'ajouter autre chose que des petits services pas trop 
perturbateurs.

Mais j'espère que christian va nous annoncer bientôt une bonne nouvelle 
concernant de nouvelles machines ;-)

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

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

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

[Philippe Verdy]

Pour ceux que le sujet des index multidimensionnels intéressent, sur
le plan technique, et pourquoi c'est quelquechose de complexe à gérer
dans une base de données, même avec des etensions GIS, quelques saines
lectures exposant comment on peut découper l'espace en une structure
hiérarchique adaptée aux recherches :

"Multidimensional Index Structures in Relational Databases", article
PDF de recherche :
http://wotan.liu.edu/docis/lib/sisl/rclis/dbl/jiisji/(2000)15%253A1%253C51%253AMISIRD%253E/www.stb-ag.com%252Fstb%252Fpapers%252FJIIS.pdf

"Multidimensional Index Structures", une présentation Powerpoint qui
satisfera les moins initiés sous une forme plus graphique et plus
parlante:
ftp://www.sacbusiness.org/downloads/cs/HardingG/cs231/Lecture-11-IndexedSequential-B%2B%2FMultiIndexStructures.ppt

D'autres travaux ont concerné les modifications aux algorithmes
classiques de gestion de B-arbres dans les index. Mais on peut retenir
qu'une base relationelle classsique peut, même avec ses index
unidimensionnels, gérer des données multidimensionnels à l'aide d'une
transformation de l'espace 2D en 1D, par une structure de découpage
hiérarchique (dont un exemple visible sur nos projets est le découpage
hiérarchique des tuiles de rendu).

Le sujet ne concerne pas que les données GIS mais concerne n'importe
quelle donnée multidimensionnelle par exemple dans les cubes OLAP
(très utilisés dans les applications d'analyse financière ou
statistique, et dans plein de domaines scientifiques où des données
sont disponibles selon plusieurs axes d'analyse sélectionnables et
permutables, même quand leur dimension de mesure n'est pas homogène,
par exemple pas seulement des longueurs, ni nécessairement non plus
continu, auquel cas il faut parfois utiliser un premier mapping d'une
coordonnée vers un espace numérique à peu près équitablement
distribué, en déterminant une relation d'ordre permettant de fixer
l'énumération et la numéroter).

La situation est plus compliquée si une des dimension n'est pas
énumérable selon un ordre clairement défini (la complexité venant
alors de la fixation d'une limite de précision, ou d'un système de
sous-classification permettant de numéroter les classes énumérables).

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

[OSM-talk-fr] Utiliser les serveurs de l'asso osm-fr (était : Re: Une carte orientée biologie ? (arbres, insectes, oiseaux, plantes))

[Gilles Bassière]

Le vendredi 24 février 2012 à 18:06 +0100, Ab_fab a écrit :

> Par contre, imaginons qu'une structure impliquée dans la géomatique
> libre et plus précisément OSM ait accès à
> _ un hébergement confortable
> _ des machines non moins confortables
> _ la possibilité d'y monter des machines virtuelles adaptées aux
> besoins des développeurs
> 
> Elle pourrait mettre à disposition un espace pilote, permettant le
> défrichage technique pour ce type d'applications "de niche".
> 
> Si l'usage décolle et charge le système, la structure peut décréter
> que ses ressources matérielles n'ont pas pour vocation prioritaire
> d'héberger ce genre de projets "périphériques" à son coeur d'activité.
> 
> Mais dans le même temps, c'est le signe que la masse critique sera
> atteinte pour aller ouvrir un serveur chez un hébergeur ou bien lancer
> un service commercial indépendant de prestation, aux coûts de
> fonctionnements mutualisés entre les utilisateurs
> 
> Bref, même si cela sort du contexte pur et dur OSM, en tant
> qu'adhérent de l'asso osm-fr, je ne serais vraiment pas choqué que ce
> genre d'initiative soit mis en place sur les serveurs de l'asso.


Effectivement, les applis tournant autour d'OSM ont des besoins que peu
d'hébergements mutualisés peuvent satisfaire. Et tous les développeurs
n'ont pas les moyens ou l'envie de louer et gérer un serveur dédié. Il
serait donc intéressant de pouvoir mutualiser des serveurs/services.

Lors de la rencontre entre mappeurs hier à Marseille [1], nous avons
évoqués plusieurs idées dont la réalisation demanderait notamment : une
réplique de la BD mise à jour automatiquement, de quoi générer des
tuiles, un serveur Web, etc.

Ces idées sont encore très floues (ce ne sont que des idées, pas encore
des projets). Mais en y repensant, j'en suis quand même arrivé aux mêmes
questions qu'Ab_fab. En particulier, je me demandais s'il était possible
d'occuper un peu d'espace sur le parcs de serveur dont dispose
l'association [2]. Est-ce qu'une politique a déjà été définie au sein de
l'association à ce sujet ?

[1] http://wiki.openstreetmap.org/wiki/Marseille/R%C3%A9unions_2012
[2] http://wiki.openstreetmap.org/wiki/FR:Servers

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



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

Re: [OSM-talk-fr] Changements incomplets sur les différents niveaux de zoom

[sly (sylvain letuffe)]

On vendredi 24 février 2012, Philippe Verdy wrote:

> Et dans ce cas il n'est pas absurde d'augmenter la précision des
> tracés selon la précision que l'on demande ensuite pour les rendus 

si

Le nombre de point n'a pas a être augmenté artificiellement dans la base OSM 
si celui-ci n'améliore pas la précision.

Après si tu veux l'augmenter logiciellement dans une copie ultérieure pourquoi 
pas, mais je répondais à ton message pas clair du tout qui semblait 
recommander d'augmenter le nombre de point dans la base OSM sans que ça 
n'améliore la qualité du tracé.


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

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

Re: [OSM-talk-fr] Changements incomplets sur les différents niveaux de zoom

[Philippe Verdy]

Le 24 février 2012 17:33, sly (sylvain letuffe)  a écrit :
> On vendredi 24 février 2012, Philippe Verdy wrote:
>> La base OSM ne retourne pas toujours non plus les ways
>
> La base OSM ne retourne rien, c'est un stockage, tu parles donc de l'API 0.6
>  codée en ruby que l'on peut interroger par http://api.openstreetmap.org/api
> et qui elle va chercher dans la base.

Oui, ne jouons pas sur le mots ici. Une base, n'importe laquelle, ne
retourne rien, elle stocke, il n'y a que les requêtes qu'on y
effectue, toujours via une API quelle qu'elle soit.

>> qui traversent
>> le rectangle mais sans y avoir aucun nœud dans ce rectangle.
>
> Ce n'est pas vraiment un bug car c'est voulu afin de limiter la charge du
> serveur qui gère l'API qui est bien souvent déjà très occupée.
>
> Je suis d'ailleurs en train d'améliorer mon "proxy d'api"
> (http://api.openstreetmap.fr/api) pour qu'il puisse supporter cette
> fonctionnalité qui serait un plus.
>
>> Hors, les moteurs de rendu procèdent ainsi pour connaître les données
>> à afficher dans un rectangle.
>
> non, ils utilisent l'opérateur && de PostGIS qui calcul l'intersection des
> bbox avec le point de vue.

Lequel opérateur, tu l'oublies, font tout de même ce genre de calcul,
et peut aussi omettre les mêmes données.

>> Bref, pour de tels cas, il n'y a pas d'autres moyens que d'affiner les
>> tracés en ajoutant des nœuds, c'est possible pour les chemins, mais
>> pas toujours concernant les libellés de nœuds qu'on ne peut pas
>> déplacer.
>
> Il ne faut pas faire ça, l'amélioration doit être faite dans l'API. Il ne faut
> pas rajouter des points inutiles dans le seul but de régler un problème
> d'édition.

Il n'y a techniquement aucun autre moyen que d'aller chercher des
points hors de la zone demandée si on veut une liste complète. L'autre
solution, c'est que les chemins liant les points aient eux-mêmes été
indexés sur la totalité des tuiles qu'ils traversent, ce qui impose
alors des calcul de points supplémentaires, là où ces chemins
traversent les frontières de tuiles.

On en revient au problème initial. La seule différence étant l'endroit
où on stocke ces points supplémentaires nécessaires pour une
couverture complète.

D'ailleurs PostGIS augmente largement les données sources de données
dérivées, qu'il stocke naturellement dans son propre schéma de base
pour séparer les choses et faciliter les mises à jour ultérieures. Il
n'empêche que ces points ajoutés augmente la volumétrie totale, même
si elle améliore et accélère considérablement les recherches locales
pour une couverture lus complète.

Un opérateur lui-même ne fait rien de mieux : il peut utiliser les
données issues de la base principale, mais comme cela ne suffit pas,
il se sert aussi des données dérivées. La question étant alors comment
et quand calculer ces données dérivées pour que cela ne surcharge pas
toutes les requêtes ni que l'essentiel de la puissance de calcul soit
consacré à mettre à jour en permanence ces données dérivées.

C'est pas si évident que ça quand les données sources sont déjà
particulièrement volumineuses.

Tu noteras tout de même que les moteurs de vérification essaye de
soulager la charge générale en identifiant les segments trop longs,
sur lesquels il est hautement souhaitable d'augmenter la précision
avec des points intermédiaires supplémentaires, afin d'éviter d'avoir
toujours à rechercher des points très au delà de la zone de recherche
demandée.

Et dans ce cas il n'est pas absurde d'augmenter la précision des
tracés selon la précision que l'on demande ensuite pour les rendus :
indépendamment des styles de rendus, si on cherche à terme une
précision métrique, il faudra ces points qui ne seront pas distancés
au delà de quelques centaines de mètres au maximum de la zone de
recherche.

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

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

[Ab_fab]

Base de données indépendante d'OSM, l'affaire est (pour moi) entendue.

Par contre, imaginons qu'une structure impliquée dans la géomatique libre
et plus précisément OSM ait accès à
_ un hébergement confortable
_ des machines non moins confortables
_ la possibilité d'y monter des machines virtuelles adaptées aux besoins
des développeurs

Elle pourrait mettre à disposition un espace pilote, permettant le
défrichage technique pour ce type d'applications "de niche".

Si l'usage décolle et charge le système, la structure peut décréter que ses
ressources matérielles n'ont pas pour vocation prioritaire d'héberger ce
genre de projets "périphériques" à son coeur d'activité.

Mais dans le même temps, c'est le signe que la masse critique sera atteinte
pour aller ouvrir un serveur chez un hébergeur ou bien lancer un service
commercial indépendant de prestation, aux coûts de fonctionnements
mutualisés entre les utilisateurs

Bref, même si cela sort du contexte pur et dur OSM, en tant qu'adhérent de
l'asso osm-fr, je ne serais vraiment pas choqué que ce genre d'initiative
soit mis en place sur les serveurs de l'asso.

**
Les outils qui permettent le fonctionnement d'OSM ont le grand avantage de
pouvoir aussi faire fonctionner une base indépendante construite sur le
même modèle.

Eric Wolf [1] travaille à l'USGS, qui est l'équivalent américain du BRGM
français.
Dans le cadre de son travail, il a remonté l'ensemble de la file de
contribution, depuis Potlatch jusqu'à la base de données qui enregistre les
changesets, les noeuds, les ways tout ça tout ça [2] et [3]

Cela pourrait être une belle source d'inspiration pour ce genre de projet
ambitieux de carte orientée biologie

PS : retenez-moi si je dis trop n'importe quoi ;-)

[1] https://wiki.openstreetmap.org/wiki/User:Ebwolf
[2] http://lists.openstreetmap.org/pipermail/dev/2010-July/019971.html
[3]
http://www.asifanyonecares.com/2011/02/using-national-map-with-openstreetmap.html

Le 24 février 2012 17:06, sly (sylvain letuffe)  a écrit
:

>
> Le problème à mon avis dans "SIG pour tous" tel que cyrille le
> souhaiterais,
> c'est la non disponibilité de bases spatiales chez la plupart des
> hébergeurs "à pas cher" et ça, ça va être difficile de s'en dépêtrer.
>
> --
> sly
> qui suis-je : http://sly.letuffe.org
> email perso : sylvain chez letuffe un point org
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>



-- 
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] [help] découpe de tuiles

[didier2020]

Le vendredi 24 février 2012 à 17:37 +0100, Cyrille Giquello a écrit :
> Salut,
> 
> J'ai besoin d'aide. J'ai des tuiles en projection NTF Lambert II.
> J'aimerai les rendre disponibles sur le net au format Slippy Map qui
> est simple et ne nécessite pas de serveur autre que http.
> 
> J'ai lu http://wiki.openstreetmap.org/wiki/FR:Slippy_Map et regardé la
> doc des outils de GDAL mais je bloque.
> 
> Premièrement, j'ai des tuiles avec leur coordonnées dans un fichier
> WLD (ESRI World File), mais il me manque la taille du rectangle ...
> Enfin je ne vois pas commencer. Si quelqu'un peu regarder et
> m'expliquer les manips ?
> 
> La liste des urls des fichiers des tuiles d'origine est ici :
> http://www.nosdonnees.fr/package/liste-des-tuiles-des-orthophotographies-de-la-communaute-urbaine-de-nantes
> 
> Pour l'exemple j'ai ouvert un des fichiers de tuile, par exemple:
> http://data.nantes.fr/fileadmin/data/datastore/3-publication/_orthophoto_/nantesmetropole_ortho_2005_1360_6237.zip
> 
> Merci pour votre aide.
> 

je pense que cela devrait plus te convenir
http://comments.gmane.org/gmane.comp.gis.openstreetmap.region.fr/28972

trop rapide j'ai été...
didier



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

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

[Philippe Verdy]

C'est vrai que MySQL ici montre ses limites. Faute justement
d'intégrer un vrai système d'indexation géographique ou de permettre
d'utiliser un tel plugin (pour remplacer ses index classiques
hiérarchisés, incompatibles avec toute info 2D, ni aucun type de
données 2D, pas même un nombre complexe qu'il ne saurait pas indexer
correctement pour les recherches).

Il y a des solutions de contournement (partiel). J'en ai déjà parlé
ici : on peut convertir un couple de coordonnées sous une forme
binaire entrelacée, permettant d'avoir un index à peu près efficace
(même si cela impose un découpage bidimensionnel sur des seuils
arbitraires de coordonnées). En gros cela consiste à diviser l'espace
2D alternativement en deux suivant l'axe horizontal, puis sur l'axe
vertical, en alternant. La position de coupure est arbitraire (on peut
prendre le milieu même si les deux parties ne sont pas équilibrées en
terme de volumétrie). Pour cela la donnée binaire va devoir stocker
suffisamment de chiffres significatifs de chaque coordonnée.

Si on utilise un "double" pour la donnée transformée à indexer, ses 48
bits de précision permettent de stocker 24 bits de précision de chaque
coordonnée 2D. On peut aussi utiliser un entier 64 bits pour stocker
32 bits entrelacés de précision de chaque coordonnée 2D exprimée sur
un entier (les coordonnées d'OSM sont de type longitude/latitude dans
la projection sur le géoïde WGS84, comme ce sont des angles dans un
intervalle bien défini, on peut donc sur 32 bits représenter une
précision angulaire meilleure de l'ordre de quelques dixièmes de
milliseconde d'arc, bien au delà de la précision nécessaire; en fait
21 bits suffisent par coordonnée pour une précision d'1 seconde d'arc,
raison pour laquelle on n'a pas besoin des double non plus pour
stocker les coordonnées de longitude ou de latitude).

Un vrai indexeur spacial s'il effectue aussi un découpage alterné, se
distingue en ne prédéterminant pas les valeurs seuils de coupure. Il
gère son index de façon à maintenir chaque partie à peu près égale en
volumétrie (dans une fourchette de tolérance). Il peut aussi faire un
découpage sur une grille plus grande que 1x2 ou 2x1, par exemple 2x2,
3x3 ou plus, et peut même changer ce découpage dynamiquement, selon
les données qui se présentent ou sont modifiées, il peut même
identifier dans des grilles de découpage 3x3 et supérieures plusieurs
cases à indexer ensemble, pour que la volumétrie de chaque case soit à
peu près équilibrée avec les autres cases regroupées de la même
grille.

Ensuite, les autres extensions offertes par les plugins sont les
extensions de calcul (intersection par exemple), mais impossible de
les implémenter efficacement sans avoir un vrai indexeur
multidimensionnel efficace. MySQL ne pourra rien offrir là dessus, ce
genre de requête se fera donc de façon externe. Ces plugins ne
changent pas la méthode de stockage ou d'indexation de la base, leur
intérêt c'est qu'ils s'exécutent directement au sein du moteur, et
font donc l'économie de pas mal d'interfaces de communication pour
éviter le goulot de la bande passante nécessaire en sortie du moteur
SQL. En revanche ces plugins d'extension ne font aucune économie en
terme de bande passante sur les accès disques (raison pour laquelle il
faut des index très efficaces et si possible optimums pour les
recherches d'objets dans des espaces délimités le plus souvent par un
rectangle).

Le 24 février 2012 17:06, sly (sylvain letuffe)  a écrit :
>
>> Au risque de nourrir un troll...
>
> Ouais mais on peut, c'est trolldis ;-)
>
>> PHP dispose de peu de modules pour traiter l'information géographique
>
> Il est vrai, mais c'est pas très important car il est possible de faire une
> grosse partie du traitement géographique du coté du moteur spatial.
>
> php, ce n'est que la "colle" entre le moteur de base de donnée et l'interface
> utilisateur (html/navigateur/javascript)
>
> Le problème à mon avis dans "SIG pour tous" tel que cyrille le souhaiterais,
> c'est la non disponibilité de bases spatiales chez la plupart des
> hébergeurs "à pas cher" et ça, ça va être difficile de s'en dépêtrer.
>
> Pour avoir développé sur www.refuges.info de nombreux éléments qui
> s'approchent des SIG (polygones, intersections, appartenance, recherche de
> proximité) je peux dire que le problème n'a pas vraiment été php, mais bien
> le moteur MySQL sous-jacent que j'ai converti misérablement et à grand frais
> de CPU perdu et redondance en moteur à peine spatial. (et quand je vois le
> résultat, je tire mon chapeau à l'équipe postgis !)
>
>
>
> --
> sly
> qui suis-je : http://sly.letuffe.org
> email perso : sylvain chez letuffe un point org
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr

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

Re: [OSM-talk-fr] [help] découpe de tuiles

[didier2020]

Le vendredi 24 février 2012 à 17:37 +0100, Cyrille Giquello a écrit :
> Salut,
> 
> J'ai besoin d'aide. J'ai des tuiles en projection NTF Lambert II.
> J'aimerai les rendre disponibles sur le net au format Slippy Map qui
> est simple et ne nécessite pas de serveur autre que http.
> 
> J'ai lu http://wiki.openstreetmap.org/wiki/FR:Slippy_Map et regardé la
> doc des outils de GDAL mais je bloque.
> 
> Premièrement, j'ai des tuiles avec leur coordonnées dans un fichier
> WLD (ESRI World File), mais il me manque la taille du rectangle ...
http://wiki.openstreetmap.org/wiki/Slippy_map_tilenames

> Enfin je ne vois pas commencer. Si quelqu'un peu regarder et
> m'expliquer les manips ?
> 
> La liste des urls des fichiers des tuiles d'origine est ici :
> http://www.nosdonnees.fr/package/liste-des-tuiles-des-orthophotographies-de-la-communaute-urbaine-de-nantes
> 
> Pour l'exemple j'ai ouvert un des fichiers de tuile, par exemple:
> http://data.nantes.fr/fileadmin/data/datastore/3-publication/_orthophoto_/nantesmetropole_ortho_2005_1360_6237.zip
> 
> Merci pour votre aide.
> 



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

[OSM-talk-fr] [help] découpe de tuiles

[Cyrille Giquello]

Salut,

J'ai besoin d'aide. J'ai des tuiles en projection NTF Lambert II.
J'aimerai les rendre disponibles sur le net au format Slippy Map qui
est simple et ne nécessite pas de serveur autre que http.

J'ai lu http://wiki.openstreetmap.org/wiki/FR:Slippy_Map et regardé la
doc des outils de GDAL mais je bloque.

Premièrement, j'ai des tuiles avec leur coordonnées dans un fichier
WLD (ESRI World File), mais il me manque la taille du rectangle ...
Enfin je ne vois pas commencer. Si quelqu'un peu regarder et
m'expliquer les manips ?

La liste des urls des fichiers des tuiles d'origine est ici :
http://www.nosdonnees.fr/package/liste-des-tuiles-des-orthophotographies-de-la-communaute-urbaine-de-nantes

Pour l'exemple j'ai ouvert un des fichiers de tuile, par exemple:
http://data.nantes.fr/fileadmin/data/datastore/3-publication/_orthophoto_/nantesmetropole_ortho_2005_1360_6237.zip

Merci pour votre aide.

-- 
Cyrille.

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

Re: [OSM-talk-fr] Changements incomplets sur les différents niveaux de zoom

[sly (sylvain letuffe)]

On vendredi 24 février 2012, Philippe Verdy wrote:

> > Ce que dit Philippe semble coller avec ce que j'ai fait : j'ai uploadé la
> > zone forestière en 3 fois au lieu de l'uploader en une fois. Peut être le
> > mieux pour la suite serait de sauvegarder mes modifs dans JOSM puis
> > lorsque 
> > c'est complet, envoyer le tout ?
> 
> Malheureusement la solution d'envoyer tout en une seule fois ne marche
> pas toujours.

Je ne recommande vraiment pas cette solution, il est préférable de sauvegarder 
régulièrement pour :
1) ne pas perdre son travail
2) limiter le risque de conflit
3) limiter l'impact d'une erreur de transmission
4) faciliter une annulation ultérieure


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

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

Re: [OSM-talk-fr] Changements incomplets sur les différents niveaux de zoom

[sly (sylvain letuffe)]

On vendredi 24 février 2012, Philippe Verdy wrote:
> La base OSM ne retourne pas toujours non plus les ways 

La base OSM ne retourne rien, c'est un stockage, tu parles donc de l'API 0.6
 codée en ruby que l'on peut interroger par http://api.openstreetmap.org/api 
et qui elle va chercher dans la base.

> qui traversent  
> le rectangle mais sans y avoir aucun nœud dans ce rectangle. 

Ce n'est pas vraiment un bug car c'est voulu afin de limiter la charge du 
serveur qui gère l'API qui est bien souvent déjà très occupée.

Je suis d'ailleurs en train d'améliorer mon "proxy d'api" 
(http://api.openstreetmap.fr/api) pour qu'il puisse supporter cette 
fonctionnalité qui serait un plus.

> Hors, les moteurs de rendu procèdent ainsi pour connaître les données
> à afficher dans un rectangle. 

non, ils utilisent l'opérateur && de PostGIS qui calcul l'intersection des 
bbox avec le point de vue.

> Bref, pour de tels cas, il n'y a pas d'autres moyens que d'affiner les
> tracés en ajoutant des nœuds, c'est possible pour les chemins, mais
> pas toujours concernant les libellés de nœuds qu'on ne peut pas
> déplacer.

Il ne faut pas faire ça, l'amélioration doit être faite dans l'API. Il ne faut 
pas rajouter des points inutiles dans le seul but de régler un problème 
d'édition.
 


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

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

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

[Samy Mezani]

Bonjour,

le 24/02/2012 16:44, Gilles Bassière a écrit:

Pour remettre un pied dans le sujet, je dirais qu'un projet de collecte
de données naturalistes libre serait super intéressant mais :
- je n'imagine pas mettre des observations (au moins de faune) dans la
base OSM, il y aurait donc une BD propre à ce projet


Bien sûr OSM n'a pas vocation à être une base de données naturaliste. 
Mais les naturalistes pourraient utiliser OSM et surtout y contribuer 
par leur forte présence sur le terrain.
Un projet libre de collecte de données ne viserait pas forcément à 
centraliser les données dans une seule BD, mais à fournir un outil 
déployable localement et utilisable par le plus grand nombre.



- les naturalistes sont souvent cramponnés au secret de leur données,
comment alors organiser la collecte et le partage d'information ?


Ce n'est vraiment plus le cas quand on voit la diffusion actuelle des 
données via Visio-Nature ! Même les assocs de naturalistes "cramponnés" 
à leurs données s'y mettent.
Et comme je le disais un projet d'outil libre laisserait la liberté de 
gestion des données à l'utilisateur. On ne lui imposerait pas la 
centralisation comme c'est le cas actuellement ; on développerait un 
outil utilisé par le plus grand nombre dont l'objectif est l'ergonomie, 
l'interopérabilité, etc, etc.


J'entame, avec Loïc ou Flo de partir-en-vtt.com, une réflexion sur 
l'opportunité de monter un éventuel projet de développement.


Je fais le tour de ce qui existe pour l'instant (projets proprio et 
libres). Il y a déjà des outils excellents, y compris sur smartphone, 
mais tout reste inachevé ou incomplet ou perfectible. Devinez 
pourquoi... ben chacun dans son coin quoi ! Et trop d'outils sont basés 
sur des logiciels et données géographiques proprios.


Je vais rédiger prochainement une sorte de cahier des charges qui 
pourrait servir de moteur au démarrage d'un projet. Y a rien de fait 
hein mais bon...


Il serait intéressant à notre avis de créer un petit groupe de travail 
et de réflexion sur ce thème. Si ça intéresse des gens, merci de me le 
faire savoir, histoire qu'on se fasse un petit groupe "bio-osm" !


Samy

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

Re: [OSM-talk-fr] Changements incomplets sur les différents niveaux de zoom

[sly (sylvain letuffe)]

On vendredi 24 février 2012, Philippe Verdy wrote:

> OK, donc le problème est ailleurs. Osmosis sans doûte puisque c'est
> par lui que ça transite et non l'API utilisée par les éditeurs. Mais
> comment fait alors  Mapquest qui passe aussi par Osmosis ?

Sauf erreur, c'est osm2pgsql qui sert à construire et maintenir à jour les 
bases de la quasi totalité des rendus en ligne par tuiles. (J'exclus les 
rendu dynamiques offline que l'on trouve sur android/garmin/iOS) 


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

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

Re: [OSM-talk-fr] Changements incomplets sur les différents niveaux de zoom

[Philippe Verdy]

Le 24 février 2012 16:39, Ab_fab  a écrit :
> Les transactions entre JOSM et l'API du projet et le rendu des tuiles sont
> des processus finalement assez éloignés. Et ils ne mettent pas en jeu les
>
> Il y a quelques étapes intermédiaires, que l'on voit sur ce schéma :
> http://wiki.openstreetmap.org/wiki/File:OSM_Components.png
>
> Il ne faut pas confondre :
>
> _ la base de données "PostgreSQL backend" (en vert) qui envoie les données
> vers JOSM et en reçoit ensuite les modification. Elle se trouve sur ce
> serveur : http://wiki.openstreetmap.org/wiki/Servers/smaug
>
> _ la base postgis (en jaune) qui est mise à jour par les "planet diffs" et
> qui fournit les données au moteur de rendu pour la création de tuiles. Pour
> le rendu "Mapnik" du site principal openstreetmap.org , c'est ce serveur qui
> s'y colle : http://wiki.openstreetmap.org/wiki/Servers/yevaud

OK, donc le problème est ailleurs. Osmosis sans doûte puisque c'est
par lui que ça transite et non l'API utilisée par les éditeurs. Mais
comment fait alors  Mapquest qui passe aussi par Osmosis ?

Il y a tellement de composants finalement (au delà de la base Backend
d'OSM qui sert de référence commune pour tout le monde), qu'on peut
tout de même s'interroger sur lequel provoque ces incohérences lorsque
chacun d'eux recalcule (simplifie ou synthétise) des géométries et
gère ses listes de tâches à faire (ou refaire).

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

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

[sly (sylvain letuffe)]

> Au risque de nourrir un troll...

Ouais mais on peut, c'est trolldis ;-)
 
> PHP dispose de peu de modules pour traiter l'information géographique

Il est vrai, mais c'est pas très important car il est possible de faire une 
grosse partie du traitement géographique du coté du moteur spatial.

php, ce n'est que la "colle" entre le moteur de base de donnée et l'interface 
utilisateur (html/navigateur/javascript)

Le problème à mon avis dans "SIG pour tous" tel que cyrille le souhaiterais, 
c'est la non disponibilité de bases spatiales chez la plupart des 
hébergeurs "à pas cher" et ça, ça va être difficile de s'en dépêtrer.

Pour avoir développé sur www.refuges.info de nombreux éléments qui 
s'approchent des SIG (polygones, intersections, appartenance, recherche de 
proximité) je peux dire que le problème n'a pas vraiment été php, mais bien 
le moteur MySQL sous-jacent que j'ai converti misérablement et à grand frais 
de CPU perdu et redondance en moteur à peine spatial. (et quand je vois le 
résultat, je tire mon chapeau à l'équipe postgis !)



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

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

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

[Philippe Verdy]

Moi ce qui me plait mieux dans groove (par rapport à hollow) c'est son
caractère artificiel, le fait qu'il ne soit pas fortuit mais créé "ad
hoc". Si on en trouve au milieu d'une route circulable, ce n'est pas
par accident (pas comme les nids de poule, ni les effondrements de
chaussée, emportées par exemple par une inondation, un glissement de
terrain, une excavation souterraine instable, ou toute autre perte des
soutiens de la chaussée, par exemple dans les routes de montagne).

Si on construit de tels cassis, destinés à faciliter l'écoulement des
eaux, c'est justement pour éviter les dommages à la route en cas de
forte plus: la cassis est construit pour résister mieux au passage de
l'eau, et pour éviter l'accumulation de celle-ci sur un des côtés, au
risque de détremper et déstabiliser un terrain soutenant la route, et
de l'emporter dans sa totalité avec la pression des eaux accumulées.

Normalement on évite le problème avec une canalisation enterrée sous
la chaussée, mais ce n'est pas toujours techniquement possible pour
collecter les eaux, car il n'y a pas forcément la place de construire
un fossé collecteur prenant la place sur le côté de routes déjà
étroites et qu'on ne peut pas élargir (par exemple si cela imposait de
lourds et très coûteux travaux de démolition d'une colline attenante
d'où proviennent pourtant les eaux à évacuer). Bref ces cassis le plus
souvent à sec deviennent des gués en cas de précipitation. Ils peuvent
être temporairement infranchissables quand ils sont pleins, mais
protègent le reste de l'ouvrage et les terrains voisins contre un
risque encore plus dangereux de glissement de terrain, en créant une
zone d'écoulement, renforcée pour résister aux écoulements, souvent
par le coulage de béton au lieu de la surface légère habituelle (et
souvent drainante pour justement améliorer la tenue de route en cas de
pluie modérée, un drainage qui en revanche emportera la route si
l'écoulement est trop fort).

De plus "hollow" peut être très marqué, très prononcé, cela pourrait
alloer jusqu'à la tranchée fermant la route complètement. Hollow me
semble trop large dans sa définition, raison de plus pour le fait que
la définition de "groove" cite "hollow" mais en lui ajoutant son
caractère artificiel et ad hoc.

Ce qui me plait aussi dans "groove" est qu'il est classiquement
utilisé en opposition à "ridge" (nos dos d'âne rentrent dans la
définition d'un "ridge"). Il traduit aussi une extension limitée
(moins marquée que ce que pourrait être une tranchée ou un fossé avec
"hollow"), incluant aussi les pentes douces et peu profondes,
suffisantes pour être traversées sans danger ni dommage à vitesse
raisonnable (même si cela veut dire la traverser au pas), et sans non
plus décoller de la route et perdre l'adhérence (à vitesse élevée, où
la roue survolerait le cassis), ce qui est aussi un danger à cause de
la perte de contrôle momentanée du véhicule (cependant les limitations
usuelles de vitesse de la route empêchent normalement de se trouver
dans ce cas).

Le 24 février 2012 15:15, Fabien  a écrit :
> Le 23 février 2012 22:28, Philippe Verdy  a écrit :
>> Le 23 février 2012 13:05, Christian Rogel
>>  a écrit :
>>> - pothole, mais c'est apparemment dans le sens d'un dommage qui peut être 
>>> un trou ou un effondrement.
>>> Cela semble plus proche du sens de cassis
>>
>> A mon avis ça traduit mieux ce qu'on connait comme des « nids de poule
>> », jamais souhaités, souvent causés par le dégel et le passage
>> d'engins trop lourds,  et à priori provisoires jusqu'à leur rebouchage
>> (quand la route est un minimum entretenue).
>>
>>> - dip, mais cela désigne plutôt les variations d'altitude le la route.
>>>
>>> Pothole est un bon candidat.
>>
>> Moi je traduirais plutôt "hollow" (et son contraire le "ridge" qui est
>> un dos d'âne très étroit qu'il vaut mieux aussi ne pas prendre à
>> grande vitesse si on ne veut pas se cogner la tête, déchausser ou
>> éclater un pneu, ou encore défoncer sa suspension, bien que le terme
>> "ridge" soit un peu trop large et recouvre n'importe quelle crête,
>> voire aussi un récif sur un rivage, ou encore une corniche surplombant
>> un ravin).
>>
>> On a aussi "groove" peut-être mieux adapté aux petits creux linéaires
>> (on trouve les deux termes "ridge" et "groove" souvent utilisés en
>> opposition, pour désigner le style de fine bordure, en relief ou en
>> creux, des cadres en CSS), et qu'on traduit comme "rainure",
>> "cannelure", "rigole", "strie", "gorge"...
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/talk-fr
>
> Salut,
>
> hollow me plait pas mal. D'après le Oxford English Dictionary : a
> surface concavity, more or less deep, an excavation, a depression on
> any surface.
>
> Par contre groove, dans le Oxford : A channel or hollow, cut by
> artificial means, in metal, wood, etc.; e.g. the spiral rifling of a
> gun, one of the air-passages leading from the wind-

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

[rldhont]

GeoPHP ?

Le 24/02/2012 16:44, Gilles Bassière a écrit :

Le vendredi 24 février 2012 à 16:15 +0100, Cyrille Giquello a écrit :

Le 22 février 2012 21:31, partir-en-vtt  a écrit :

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

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

Mes compétences :

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

Je suis justement en pleine réflexion sur la démocratisation. Je suis
parti de Chimère [1] et mon 1er postula est qu'une appli écrite en
Python et utilisant PostGis n'est pas démocratique car elle ne peut
être installée sur un serveur mutualisé à faible coût (<5€/mois).
Alors qu'un équivalent à Chimère écrit en Php et utilisant MySql ou
SQLite pourrait s'installer partout (ou presque) pour un prix de
revient modique. De cette façon, une communauté, une petite commune,
... peu s'équiper d'un petit 'SIG' à 2 balles mais qui le fait bien.



Cyrille.

[1] http://redmine.peacefrogs.net/projects/chimere/

Au risque de nourrir un troll...

PHP dispose de peu de modules pour traiter l'information géographique
(hormis mapscript, c'était le désert la dernière fois que je m'y suis
intéressé). C'est la raison pour laquelle Python ou Java sont souvent
préférés pour des applications géographiques.

La dernière fois que j'ai jeté un œil à Chimère, le code m'a laissé une
impression de qualité (et c'est rare !). Je trouve donc dommage de
balayer Chimère sur le seul argument de l'hébergement. D'autant plus
qu'on trouve des hébergement Python de qualité à des tarifs tout à fait
abordables :
https://www.alwaysdata.com/plans/shared/

Pour remettre un pied dans le sujet, je dirais qu'un projet de collecte
de données naturalistes libre serait super intéressant mais :
- je n'imagine pas mettre des observations (au moins de faune) dans la
base OSM, il y aurait donc une BD propre à ce projet
- les naturalistes sont souvent cramponnés au secret de leur données,
comment alors organiser la collecte et le partage d'information ?

Cordialement



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

Re: [OSM-talk-fr] Changements incomplets sur les différents niveaux de zoom

[Ab_fab]

Je te propose d'attendre quelques heures pour voir le résultat de ces
ajustements.
Normalement, tout va bien du côté de la base de données principale d'OSM,
et c'est ... le principal.

Tu peux passer à une autre zone et continuer tes contributions.

Le rendu Mapnik principal devrait se corriger tout seul dans les prochains
jours / prochaines heures et oui, désormais ce que tu as renseigné via JOSM
est désormais (*) disponible pour tous les usages de OSM

_ les multiples rendus de carte en ligne (en commençant par ceux présentés
sur openstreetmap.org, mais pas que)
_ les fichiers de données régionales (
http://download.geofabrik.de/osm/europe/france/)
_ les cartes pour GPS Garmin, Android, ...

(*) ou sera tout prochainement

Le 24 février 2012 16:39, aa mail  a écrit :

> OK, je vais donc ajouter l'attribut manquant "highway".
> Pour le reste que dois-je faire ? Les modifications que j'ai faites
> vont-elles apparaitre correctement prochainement ou dois-je me faire à
> l'idée que ce sera toujours ainsi ? Il n'y a pas de solution pour y
> remédier ?
> Concernant Mapquest, je n'y connais pas grand chose étant débutant. Les
> modification que j'ai apporté à OSM via JOSM sont censées apparaitre aussi
> sur Map Quest ?
>
> Mapscrib
>
> ___
> 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] Changements incomplets sur les différents niveaux de zoom

[Emilie Laffray]

Tout site de cartographie qui utilise OSM comme fond de carte se mettra a
jour avec tes donnees.
Mapquest est un utilisateur des donnees de OSM et sera donc mis a jour avec
tes modifications. Le site officiel est open.mapquest.fr mais c'est vrai
pour la totalite des sites qui sont synchronises avec la base OSM.

Emilie

2012/2/24 aa mail 

> OK, je vais donc ajouter l'attribut manquant "highway".
> Pour le reste que dois-je faire ? Les modifications que j'ai faites
> vont-elles apparaitre correctement prochainement ou dois-je me faire à
> l'idée que ce sera toujours ainsi ? Il n'y a pas de solution pour y
> remédier ?
> Concernant Mapquest, je n'y connais pas grand chose étant débutant. Les
> modification que j'ai apporté à OSM via JOSM sont censées apparaitre aussi
> sur Map Quest ?
>
> Mapscrib
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

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

[Gilles Bassière]

Le vendredi 24 février 2012 à 16:15 +0100, Cyrille Giquello a écrit :
> Le 22 février 2012 21:31, partir-en-vtt  a écrit :
> > Il faut se donner les moyens ! Un projet libre dans ce domaine n'est pas
> > utopiste. Il suffit de trouver des personnes motivées et compétentes dans le
> > domaine ;-)
> >
> > Personnellement, je veux bien m'investir si un noyau se forme sur un projet
> > comme celui-ci.
> >
> > Mes compétences :
> >
> > SIG
> > Développement PHP/mysql/CSS/postgresql/postgis
> > modélisation base de données en Merise
> > connaissances dans le monde naturaliste
> > ETL FME
> 
> Je suis justement en pleine réflexion sur la démocratisation. Je suis
> parti de Chimère [1] et mon 1er postula est qu'une appli écrite en
> Python et utilisant PostGis n'est pas démocratique car elle ne peut
> être installée sur un serveur mutualisé à faible coût (<5€/mois).
> Alors qu'un équivalent à Chimère écrit en Php et utilisant MySql ou
> SQLite pourrait s'installer partout (ou presque) pour un prix de
> revient modique. De cette façon, une communauté, une petite commune,
> ... peu s'équiper d'un petit 'SIG' à 2 balles mais qui le fait bien.
> 
> Cyrille.
> 
> [1] http://redmine.peacefrogs.net/projects/chimere/

Au risque de nourrir un troll...

PHP dispose de peu de modules pour traiter l'information géographique
(hormis mapscript, c'était le désert la dernière fois que je m'y suis
intéressé). C'est la raison pour laquelle Python ou Java sont souvent
préférés pour des applications géographiques.

La dernière fois que j'ai jeté un œil à Chimère, le code m'a laissé une
impression de qualité (et c'est rare !). Je trouve donc dommage de
balayer Chimère sur le seul argument de l'hébergement. D'autant plus
qu'on trouve des hébergement Python de qualité à des tarifs tout à fait
abordables :
https://www.alwaysdata.com/plans/shared/

Pour remettre un pied dans le sujet, je dirais qu'un projet de collecte
de données naturalistes libre serait super intéressant mais :
- je n'imagine pas mettre des observations (au moins de faune) dans la
base OSM, il y aurait donc une BD propre à ce projet
- les naturalistes sont souvent cramponnés au secret de leur données,
comment alors organiser la collecte et le partage d'information ?

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



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

Re: [OSM-talk-fr] Changements incomplets sur les différents niveaux de zoom

[aa mail]

OK, je vais donc ajouter l'attribut manquant "highway".
Pour le reste que dois-je faire ? Les modifications que j'ai faites
vont-elles apparaitre correctement prochainement ou dois-je me faire à
l'idée que ce sera toujours ainsi ? Il n'y a pas de solution pour y
remédier ?
Concernant Mapquest, je n'y connais pas grand chose étant débutant. Les
modification que j'ai apporté à OSM via JOSM sont censées apparaitre aussi
sur Map Quest ?

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

Re: [OSM-talk-fr] Changements incomplets sur les différents niveaux de zoom

[aa mail]

OK, je vais donc ajouter l'attribut manquant "highway".
Pour le reste que dois-je faire ? Les modifications que j'ai faites
vont-elles apparaitre correctement prochainement ou dois-je me faire à
l'idée que ce sera toujours ainsi ? Il n'y a pas de solution pour y
remédier ?
Concernant Mapquest, je n'y connais pas grand chose étant débutant. Les
modification que j'ai apporté à OSM via JOSM sont censées apparaitre aussi
sur Map Quest ?

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

Re: [OSM-talk-fr] Changements incomplets sur les différents niveaux de zoom

[Ab_fab]

Les transactions entre JOSM et l'API du projet et le rendu des tuiles sont
des processus finalement assez éloignés. Et ils ne mettent pas en jeu les

Il y a quelques étapes intermédiaires, que l'on voit sur ce schéma :
http://wiki.openstreetmap.org/wiki/File:OSM_Components.png

Il ne faut pas confondre :

_ la base de données "PostgreSQL backend" (en vert) qui envoie les données
vers JOSM et en reçoit ensuite les modification. Elle se trouve sur ce
serveur : http://wiki.openstreetmap.org/wiki/Servers/smaug

_ la base postgis (en jaune) qui est mise à jour par les "planet diffs" et
qui fournit les données au moteur de rendu pour la création de tuiles. Pour
le rendu "Mapnik" du site principal openstreetmap.org , c'est ce serveur
qui s'y colle : http://wiki.openstreetmap.org/wiki/Servers/yevaud

-> Il y a une (1) base de transaction principale.
Mais il peut (et il y a) de multiples bases de données synchronisées par
les diffs et permettant la création de rendus (*)

Bref, ce n'est pas parce que quelqu'un consulte les tuiles d'une zone dans
son navigateur sur osm.org que cela va entrainer un engorgement lors de
l'envoi de données par un autre utilisateur vers l'API pour cette même zone.

Un conflit d'édition, c'est quand plusieurs personnes chargent la même zone
dans JOSM, et font des modifications différentes sur les mêmes noeuds. Au
moment de l'envoi par l'API, il y a un problème potentiel.

Hors le contexte particulier de
_ mapping parties frénétiques sur des espaces très réduits,
_ de modifications concernant une zone très étendue (#jdçajdr ...),
_ de zones travaillées en local pendant de longues heures

mon avis est que ce genre de péripétie est possible, mais relève plutôt du
fantasme en pratique.
Et en particulier pour des zones rurales. Suffit d'utiliser OSM Watch List
pour savoir que la probabilité d'y voir sévir deux contributeurs au même
moment est très faible.

(*) c'est donc la bonne nouvelle : OUI Mapnik a déjà sa base de données
rien qu'à lui !
Et de par la moulinette osm2pgsql, les données sont en plus pré-travaillées
pour lui faciliter le rendu ensuite.
Comme quoi, ça a déjà dû être cogité

Le 24 février 2012 16:08, Philippe Verdy  a écrit :

> Le 24 février 2012 14:46, aa mail  a écrit :
> > OK, merci pour beaucoup pour ces infos.
> > Voici un permalink vers une des zones concernées :
> > http://www.openstreetmap.org/?lat=47.5163&lon=-1.8003&zoom=16&layers=M
> > Là, le rond point appelé "rond point de la belle étoile" ne s’affiche
> pas.
> > Vous pouvez aussi voir que sur la route en pointillée qui part vers nord
> > Nord-Est, il n'y a que le "R" de route d'indiqué. Si l'on zoom une fois,
> il
> > ne s'affiche que "route forestière de". Encore un zoom, et de même, le
> nom
> > ne s'affiche qu'en partie, puis une autre partie bout est répétée plus
> loin
> > sur la route. A droite de cette route (toujours pour ce niveau de zoom)
> on
> > trouve aussi un "r" perdu dans la forêt ;-).
> > Ce que dit Philippe semble coller avec ce que j'ai fait : j'ai uploadé la
> > zone forestière en 3 fois au lieu de l'uploader en une fois. Peut être le
> > mieux pour la suite serait de sauvegarder mes modifs dans JOSM puis
> lorsque
> > c'est complet, envoyer le tout ?
>
> Malheureusement la solution d'envoyer tout en une seule fois ne marche
> pas toujours. Car on n'est souvent pas seul à travailler sur une même
> zone. De fait celle-ci sera redessinée à un niveau de zoom donné pour
> un autre utilisateur qui a demandé ce niveau de zoom avant vous.
>
> Et puis il y a le cas des conflits d'édition qui prennent du temps à
> résoudre. Pendant ce temps-là Mapnik commence à raffraîchir certaines
> tuiles concernées mais pas toutes. puis une autre modif arrive, Mapnik
> va redessiner des tuiles concernées dans un autre ordre, et croire que
> les tuiles voisines  également concernées ont déjà été redessinées.
>
> Mapnik a un problème à identifier précisément les tuiles qui sont
> réellement concernées par une modification, et taille un peu "à la
> louche", alors qu'il devrait gérer ces tuiles à redessiner en fonction
> de la géométrie de sa propre charte graphique (qui se surimpose à la
> géométrie dans la base, dès lors qu'il convertit un trait en surface
> ou qu'il positionne un libellé dont la surface occupée n'est pas dans
> les données OSM puisque cela dépend des polices et tailles de police
> utilisées, ou d'autres paramètres de mise en forme de ce texte tel que
> des sauts de ligne pour les longs libellés attachés à un seul noeud,
> tels que les noms de localités).
>
> Bref il oublie des tas de trucs dans son propre calcul de géométrie.
> On arrive parfois à le corriger uniquement en modifiant un tout petit
> peu la position d'un nœud isolé au milieu de la tuile concernée (on
> peut presque toujours trouver au moins un nœud dont la position peut
> être améliorée : pas besoin de le forcer à raffraîchir une tuile qu'il
> a oubliée, ce seul nœud modifié devrait suffire à Mapnik pour lever
> les cas ambigus ou

Re: [OSM-talk-fr] Changements incomplets sur les différents niveaux de zoom

[Philippe Verdy]

Cependant il y a un autre cas où le bogue ne vient pas directement du
moteur de rendu, mais de la façon qu'a la base OSM de répondre à une
demande de chargement des données dans une zone rectangulaires :

La base OSM ne retourne pas toujours non plus les ways qui traversent
le rectangle mais sans y avoir aucun nœud dans ce rectangle. On peut
résoudre en partie le problème en demandant à télécharger des données
sur une zone rectangle qui déborde un peu le cadre réellement voulu.
Mais cette extension n'est pas toujours suffisante pour y trouver au
moins un nœud.

Hors, les moteurs de rendu procèdent ainsi pour connaître les données
à afficher dans un rectangle. Mapnik semble demander les données
couvrant toutes les 8 tuiles voisines du même niveau de zoom, ce qui
ne suffit pas toujours non plus !

Bref, pour de tels cas, il n'y a pas d'autres moyens que d'affiner les
tracés en ajoutant des nœuds, c'est possible pour les chemins, mais
pas toujours concernant les libellés de nœuds qu'on ne peut pas
déplacer.

La seule solution est alors pour Mapnik (ou n'importe quel autre
moteur de rendu) de mettre en place une liste de suivi, tuile par
tuile, contenant la liste d'objets présents seulement dans une tuile
voisine mais dont le tracé dépend de la géométrie de rendu calculée
dans la tuile d'origine: dès qu'il s'occupera de la tuile contenant un
objet dans la base, il modifiera les listes de suivi des autres tuiles
concernées par la géométrie qu'il calcule non seulement pour la tuiles
en cours mais aussi pour les tuiles voisines.

Et pour cela, Mapnik DOIT se faire sa propre base de données,
contenant sa propre géométrie calculée. Une telle base sera alors
évidemment beaucoup plus volumineuse que la base OSM elle-même pusique
non seulement elle modifie et complexifie les géométries, mais aussi
parce que ces géométries dérivées (propres au rendu lui-même) sont
spécifiques à chaque niveau de zoom (elles ne se superposent pas : à
faible niveau de zoom, une route dessinée par exemple occupe une
surface plus importante qu'au niveau de zoom suivant plus détaillé).
Cela veut dire autant de bases de données de géométrie dérivée que de
niveau de zoom supporté par le moteur (d'autant plus que chaque niveau
de zoom n'affiche pas la même quantité d'informations).

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

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

[Cyrille Giquello]

Le 22 février 2012 21:31, partir-en-vtt  a écrit :
> Il faut se donner les moyens ! Un projet libre dans ce domaine n'est pas
> utopiste. Il suffit de trouver des personnes motivées et compétentes dans le
> domaine ;-)
>
> Personnellement, je veux bien m'investir si un noyau se forme sur un projet
> comme celui-ci.
>
> Mes compétences :
>
> SIG
> Développement PHP/mysql/CSS/postgresql/postgis
> modélisation base de données en Merise
> connaissances dans le monde naturaliste
> ETL FME

Je suis justement en pleine réflexion sur la démocratisation. Je suis
parti de Chimère [1] et mon 1er postula est qu'une appli écrite en
Python et utilisant PostGis n'est pas démocratique car elle ne peut
être installée sur un serveur mutualisé à faible coût (<5€/mois).
Alors qu'un équivalent à Chimère écrit en Php et utilisant MySql ou
SQLite pourrait s'installer partout (ou presque) pour un prix de
revient modique. De cette façon, une communauté, une petite commune,
... peu s'équiper d'un petit 'SIG' à 2 balles mais qui le fait bien.

Cyrille.

[1] http://redmine.peacefrogs.net/projects/chimere/

>
>
>
> --
> View this message in context: 
> http://gis.19327.n5.nabble.com/Une-carte-orientee-biologie-arbres-insectes-oiseaux-plantes-tp5503037p5506156.html
> Sent from the France mailing list archive at Nabble.com.
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr



-- 
Cyrille.

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

Re: [OSM-talk-fr] Changements incomplets sur les différents niveaux de zoom

[Philippe Verdy]

Le 24 février 2012 14:46, aa mail  a écrit :
> OK, merci pour beaucoup pour ces infos.
> Voici un permalink vers une des zones concernées :
> http://www.openstreetmap.org/?lat=47.5163&lon=-1.8003&zoom=16&layers=M
> Là, le rond point appelé "rond point de la belle étoile" ne s’affiche pas.
> Vous pouvez aussi voir que sur la route en pointillée qui part vers nord
> Nord-Est, il n'y a que le "R" de route d'indiqué. Si l'on zoom une fois, il
> ne s'affiche que "route forestière de". Encore un zoom, et de même, le nom
> ne s'affiche qu'en partie, puis une autre partie bout est répétée plus loin
> sur la route. A droite de cette route (toujours pour ce niveau de zoom) on
> trouve aussi un "r" perdu dans la forêt ;-).
> Ce que dit Philippe semble coller avec ce que j'ai fait : j'ai uploadé la
> zone forestière en 3 fois au lieu de l'uploader en une fois. Peut être le
> mieux pour la suite serait de sauvegarder mes modifs dans JOSM puis lorsque
> c'est complet, envoyer le tout ?

Malheureusement la solution d'envoyer tout en une seule fois ne marche
pas toujours. Car on n'est souvent pas seul à travailler sur une même
zone. De fait celle-ci sera redessinée à un niveau de zoom donné pour
un autre utilisateur qui a demandé ce niveau de zoom avant vous.

Et puis il y a le cas des conflits d'édition qui prennent du temps à
résoudre. Pendant ce temps-là Mapnik commence à raffraîchir certaines
tuiles concernées mais pas toutes. puis une autre modif arrive, Mapnik
va redessiner des tuiles concernées dans un autre ordre, et croire que
les tuiles voisines  également concernées ont déjà été redessinées.

Mapnik a un problème à identifier précisément les tuiles qui sont
réellement concernées par une modification, et taille un peu "à la
louche", alors qu'il devrait gérer ces tuiles à redessiner en fonction
de la géométrie de sa propre charte graphique (qui se surimpose à la
géométrie dans la base, dès lors qu'il convertit un trait en surface
ou qu'il positionne un libellé dont la surface occupée n'est pas dans
les données OSM puisque cela dépend des polices et tailles de police
utilisées, ou d'autres paramètres de mise en forme de ce texte tel que
des sauts de ligne pour les longs libellés attachés à un seul noeud,
tels que les noms de localités).

Bref il oublie des tas de trucs dans son propre calcul de géométrie.
On arrive parfois à le corriger uniquement en modifiant un tout petit
peu la position d'un nœud isolé au milieu de la tuile concernée (on
peut presque toujours trouver au moins un nœud dont la position peut
être améliorée : pas besoin de le forcer à raffraîchir une tuile qu'il
a oubliée, ce seul nœud modifié devrait suffire à Mapnik pour lever
les cas ambigus oubliés).

Néanmoins ces incohérences de rendu liées à une géométrie défectueuse
de Mapnik sont un problème et des bogues d'algorithmes de Mapnik. Là
encore, Mapquest fait beaucoup mieux et ne semble pas faire autant
d'oublis.

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

[OSM-talk-fr] tracer les voies [était "Sens interdit sauf pour les résidents ?"]

[Pieren]

2012/2/24 Philippe Verdy :

> Donc oui on trace des voies ("lanes") séparées qui n'offrent aucune
> difficulté particulière d'interprétation, dans les cas où il n'est
> plus possible de gérer correctement chaque sens avec des attributs
> communs.

Je préfère le terme de "file" que "voie" qui est assez ambigüe en français.
Il y a pour l'instant d'avantages de propositions pour tagguer les
lanes/voies/files dans un seul way que de les tracer individuellement
pour divers raisons (difficulté d'édition, intérêt peu marqué).

Pour ceux que le sujet intéresse, voici quelques liens:
- un tableau récapitulatif des différentes propositions:
http://wiki.openstreetmap.org/wiki/Lane_tagging_comparison
- une proposition avancée
http://wiki.openstreetmap.org/wiki/Proposed_features/Turn_Lanes
- les 267 messages sur ce forum (en allemand):
http://forum.openstreetmap.org/viewtopic.php?id=14710

Pieren

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

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

[Philippe Verdy]

Le 24 février 2012 15:03, Pieren  a écrit :
> 2012/2/24 Philippe Verdy :
>
>> Si une rue a des accès possibles dans les deux sens, mais avec des
>> conditions différentes, c'est tout à fait normal de vouloir tracer une
>> voie dans chaque sens, même s'il n'y a qu'une seule chaussée.
>
> Non. Ce que tu traces dans ce cas, ça n'est plus les "highway" mais
> des "lanes".

C'est bien ce que j'ai dit, pas la peine de rajouter "non". Un "lane"
c'est en français une voie (de circulation). Une voie ce n'est pas une
rue ou une route (highway).

Donc oui on trace des voies ("lanes") séparées qui n'offrent aucune
difficulté particulière d'interprétation, dans les cas où il n'est
plus possible de gérer correctement chaque sens avec des attributs
communs.

Pour les rues, qui sont un regroupement de ces voies, il y a déjà des
relations, avec lesquelles on peut aussi déjà associer
(associatedStreet) les noeuds d'adresse. Pareil pour les réseaux de
transport (où les lignes de transport doivent être modélisées souvent
séparément dans chaque sens pour prendre en compte les arrêts
corrects, qui ne sont que très rarement les mêmes dans chaque sens,
faute de quoi on ne sait plus d'où elles partent et où elles vont,
particulièrement si un seul sens inclue le passage par une
bifurcation, ou si la ligne suit un schéma comprenant des Y avec 3
passages au même point).

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

Re: [OSM-talk-fr] Changements incomplets sur les différents niveaux de zoom

[Pieren]

2012/2/24 Ab_fab :

> Pour la route qui part vers le nord-est, c'est probablement un bug de rendu.
> Je ne vois pas bien ce qui peut clocher.

C'est un bug de rendu effectivement. Les tuiles ont été rafraichies
plusieurs fois dans les derniers instants et le nom est toujours
coupé. Il faudrait écrire un rapport d'erreur pour Mapnik en joignant
un lien vers cet endroit (mais à mon avis, un bug aussi gros doit déjà
être signalé).

Pieren

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

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

[Philippe Verdy]

Le 24 février 2012 15:09, Vincent de Chateau-Thierry
 a écrit :
>> Au contraire, représenter les voies par leur surface au lieu d'un
>> simple vecteur complique énormément le travail d'édition et
>> d'interprétation.

Certes, cela complique le travail d'édition (c'est le même cas pour
les rivières). Mais certainement pas celui d'interprétation
(d'ailleurs est-ce à OSM de fournir cette "interprétation" ?). Il faut
bien admettre d'avoir de telles complications locales pour que le
modèle soit cohérent, et justement lever les ambiguïtés.

Car physiquement les rues ne sont jamais restreintes à un seul trait,
elles ont toutes une largeur (au minimum estimée, ou renseignée avec
une moyenne), et des extensions en largeur qui ne concernent pas tous
les "véhicules" (piétons inclus) : les trottoirs en sont un bon
exemple, et la carte est difficile, voire impossible à utiliser selon
une interprétation pour piétons, alors que ceux-ci imposent aussi des
passages piétons, des sections sans trottoir public... L'estimation
des largeurs est hasardeuse (d'autant qu'elle est souvent non
renseignée, ou ne peut l'être que par une largeur moyenne oubliant des
parties moins larges).

De même on oublie souvent les changements du nombre de voies
circulables, des voies fermées (par zébrures ou par plots, ou par des
changements constants du côté de stationnement... un cas qui se
multiplie dans les villes où on impose maintenant des "slaloms" pour
ralentir la circulation, au point parfois que des rues qui au départ
n'offraient aucune difficulté pour la circulation en deux sens
imposent une circulation alternée, avec des points d'attente, même pas
matérialisés ni même signalés pour savoir quel sens a la priorité de
passage !).

Malgré tout, les rares rues qui n'ont qu'une seule voie de circulation
(lane) qui peuvent être utilisées dans les deux sens, sont restreintes
de la même façon (aux riverains) dans les deux sens : ce sont des
impasses. Ce cas est simple et ne pose pas de problème, on trace une
seule voie, avec la même restriction "destination" pour les deux sens.

Sinon ce sont des rues dont soit il serait impossible d'y entrer, soit
impossible d'en sortir, et il y a alors une erreur évidente parmi les
restrictions renseignées (ou alors on est dans le cas du célèbre
sketch des sens interdits de Raymond Devos).

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

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

[Fabien]

Le 23 février 2012 22:28, Philippe Verdy  a écrit :
> Le 23 février 2012 13:05, Christian Rogel
>  a écrit :
>> - pothole, mais c'est apparemment dans le sens d'un dommage qui peut être un 
>> trou ou un effondrement.
>> Cela semble plus proche du sens de cassis
>
> A mon avis ça traduit mieux ce qu'on connait comme des « nids de poule
> », jamais souhaités, souvent causés par le dégel et le passage
> d'engins trop lourds,  et à priori provisoires jusqu'à leur rebouchage
> (quand la route est un minimum entretenue).
>
>> - dip, mais cela désigne plutôt les variations d'altitude le la route.
>>
>> Pothole est un bon candidat.
>
> Moi je traduirais plutôt "hollow" (et son contraire le "ridge" qui est
> un dos d'âne très étroit qu'il vaut mieux aussi ne pas prendre à
> grande vitesse si on ne veut pas se cogner la tête, déchausser ou
> éclater un pneu, ou encore défoncer sa suspension, bien que le terme
> "ridge" soit un peu trop large et recouvre n'importe quelle crête,
> voire aussi un récif sur un rivage, ou encore une corniche surplombant
> un ravin).
>
> On a aussi "groove" peut-être mieux adapté aux petits creux linéaires
> (on trouve les deux termes "ridge" et "groove" souvent utilisés en
> opposition, pour désigner le style de fine bordure, en relief ou en
> creux, des cadres en CSS), et qu'on traduit comme "rainure",
> "cannelure", "rigole", "strie", "gorge"...
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr

Salut,

hollow me plait pas mal. D'après le Oxford English Dictionary : a
surface concavity, more or less deep, an excavation, a depression on
any surface.

Par contre groove, dans le Oxford : A channel or hollow, cut by
artificial means, in metal, wood, etc.; e.g. the spiral rifling of a
gun, one of the air-passages leading from the wind-chest to the pipes
of an organ, etc.
Indique channel :  The watercourse in a street or by a roadway, the gutter

Bon j'attends que mon contact (professeur d'anglais) me réponde et
après je tranche.

Fabien

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

Re: [OSM-talk-fr] Changements incomplets sur les différents niveaux de zoom

[Ab_fab]

Pour le rond-point de la belle-étoile, le problème vient du fait que tu ne
lui as donné qu'un nom.
Il n'y a pas d'attribut "highway = ..."

Pour la route qui part vers le nord-est, c'est probablement un bug de rendu.
Je ne vois pas bien ce qui peut clocher.

Le 24 février 2012 14:46, aa mail  a écrit :

> OK, merci pour beaucoup pour ces infos.
> Voici un permalink vers une des zones concernées :
> http://www.openstreetmap.org/?lat=47.5163&lon=-1.8003&zoom=16&layers=M
> Là, le rond point appelé "rond point de la belle étoile" ne s’affiche pas.
> Vous pouvez aussi voir que sur la route en pointillée qui part vers nord
> Nord-Est, il n'y a que le "R" de route d'indiqué. Si l'on zoom une fois, il
> ne s'affiche que "route forestière de". Encore un zoom, et de même, le nom
> ne s'affiche qu'en partie, puis une autre partie bout est répétée plus loin
> sur la route. A droite de cette route (toujours pour ce niveau de zoom) on
> trouve aussi un "r" perdu dans la forêt ;-).
> Ce que dit Philippe semble coller avec ce que j'ai fait : j'ai uploadé la
> zone forestière en 3 fois au lieu de l'uploader en une fois. Peut être le
> mieux pour la suite serait de sauvegarder mes modifs dans JOSM puis lorsque
> c'est complet, envoyer le tout ?
>
> Mapscrib
>
> ___
> 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] Sens interdit sauf pour les résidents ?

[Vincent de Chateau-Thierry]

> De : "Pieren" 

> 
> > Si une rue a des accès possibles dans les deux sens, mais avec des
> > conditions différentes, c'est tout à fait normal de vouloir tracer une
> > voie dans chaque sens, même s'il n'y a qu'une seule chaussée.
> 
> Non. Ce que tu traces dans ce cas, ça n'est plus les "highway" mais
> des "lanes". Il y a de nombreuses discussions sur comment tracer ou
> tagguer individuellement chaque file d'une voie de circulation mais
> pour l'instant, la convention pour un highway (ou "route" ou "rue")
> est de scinder en deux les voies qui ont des séparations physiques
> uniquement.
> 
> > et justement parce
> > qu'on ne tague pas pour le rendu c'est possible de représenter des
> > voies pour chaque direction
> 
> Peut-être. Mais pas taggué avec "highway=*". Il est, en plus, probable
> que dans le cas cité, il n'y ait qu'une seule voie, donc un seul
> "lane". Tracer deux ways superposés pour simplifier le balisage des
> restrictions d'accès n'a pas plus de sens que de tagguer pour le
> rendu.
> 
> > On n'aurait pas de soucis d'interprétation des données de la base OSM
> > si on devait tracer non pas un chemin unique pour une rue, mais si on
> > les représentait comme des surfaces
> 
> Au contraire, représenter les voies par leur surface au lieu d'un
> simple vecteur complique énormément le travail d'édition et
> d'interprétation.
> 

+1

Pour les rues modélisées en surfaces (tiens, tiens...), voir une discussion de 
2010 :
http://lists.openstreetmap.org/pipermail/talk-fr/2010-August/026249.html 

À noter que les données sont toujours dans le même état :
http://www.openstreetmap.org/?lat=45.402009&lon=3.770273&zoom=18&layers=M

vincent

Une messagerie gratuite, garantie à vie et des services en plus, ça vous tente ?
Je crée ma boîte mail www.laposte.net

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

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

[Philippe Verdy]

Le 24 février 2012 15:03, Pieren  a écrit :
> 2012/2/24 Philippe Verdy :
>> et justement parce
>> qu'on ne tague pas pour le rendu c'est possible de représenter des
>> voies pour chaque direction
>
> Peut-être. Mais pas taggué avec "highway=*". Il est, en plus, probable
> que dans le cas cité, il n'y ait qu'une seule voie, donc un seul
> "lane". Tracer deux ways superposés pour simplifier le balisage des
> restrictions d'accès n'a pas plus de sens que de tagguer pour le
> rendu.

P.. JAMAIS j'ai dit ça ! J4ai même précisé que ces voies
ne sont pas superposées. Tu inventes.

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

Re: [OSM-talk-fr] Convoyeur de minerai

[Vincent Pottier]

Le 24/02/2012 14:49, te...@free.fr a écrit :

Bonjour à tous,

Quelqu'un a-t-il une idée de comment mapper un convoyeur de minerai ("conveyor 
belt") pour charbon, pierre, etc. ? Ce n'est pas un highway, ni a priori un 
railway...
Merci,

Teuxe



http://taginfo.openstreetmap.org/keys/man_made#values

rechercher conveyor
--
FrViPofm

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

Re: [OSM-talk-fr] Convoyeur de minerai

[Ab_fab]

man_made = conveyor_belt

Même si ce genre d'équipement n'est pas listé sur la page wiki "man_made",
l'idée est là
http://wiki.openstreetmap.org/wiki/Key:man_made

J'ai quelques photos de celui qui s'annonce sur une future mine en Nouvelle
Calédonie.
11 km de long, on ne pourra pas l'ignorer :-(
http://koneenne.blogvie.com/2011/12/18/louis-au-travail/

Le 24 février 2012 14:49,  a écrit :

> Bonjour à tous,
>
> Quelqu'un a-t-il une idée de comment mapper un convoyeur de minerai
> ("conveyor belt") pour charbon, pierre, etc. ? Ce n'est pas un highway, ni
> a priori un railway...
> Merci,
>
> Teuxe
>
> ___
> 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] Sens interdit sauf pour les résidents ?

[Pieren]

2012/2/24 Philippe Verdy :

> Si une rue a des accès possibles dans les deux sens, mais avec des
> conditions différentes, c'est tout à fait normal de vouloir tracer une
> voie dans chaque sens, même s'il n'y a qu'une seule chaussée.

Non. Ce que tu traces dans ce cas, ça n'est plus les "highway" mais
des "lanes". Il y a de nombreuses discussions sur comment tracer ou
tagguer individuellement chaque file d'une voie de circulation mais
pour l'instant, la convention pour un highway (ou "route" ou "rue")
est de scinder en deux les voies qui ont des séparations physiques
uniquement.

> et justement parce
> qu'on ne tague pas pour le rendu c'est possible de représenter des
> voies pour chaque direction

Peut-être. Mais pas taggué avec "highway=*". Il est, en plus, probable
que dans le cas cité, il n'y ait qu'une seule voie, donc un seul
"lane". Tracer deux ways superposés pour simplifier le balisage des
restrictions d'accès n'a pas plus de sens que de tagguer pour le
rendu.

> On n'aurait pas de soucis d'interprétation des données de la base OSM
> si on devait tracer non pas un chemin unique pour une rue, mais si on
> les représentait comme des surfaces

Au contraire, représenter les voies par leur surface au lieu d'un
simple vecteur complique énormément le travail d'édition et
d'interprétation.

> Si on était en coordonnées 3D, il n'y aurait pas de surface non plus
> mais des volumes prenant en compte les limites de hauteur.

Qu'est-ce que la 3D vient faire dans cette discussion ?

Pieren

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

[OSM-talk-fr] Convoyeur de minerai

[teuxe]

Bonjour à tous,

Quelqu'un a-t-il une idée de comment mapper un convoyeur de minerai ("conveyor 
belt") pour charbon, pierre, etc. ? Ce n'est pas un highway, ni a priori un 
railway...
Merci,

Teuxe

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

Re: [OSM-talk-fr] Changements incomplets sur les différents niveaux de zoom

[aa mail]

OK, merci pour beaucoup pour ces infos.
Voici un permalink vers une des zones concernées :
http://www.openstreetmap.org/?lat=47.5163&lon=-1.8003&zoom=16&layers=M
Là, le rond point appelé "rond point de la belle étoile" ne s’affiche pas.
Vous pouvez aussi voir que sur la route en pointillée qui part vers nord
Nord-Est, il n'y a que le "R" de route d'indiqué. Si l'on zoom une fois, il
ne s'affiche que "route forestière de". Encore un zoom, et de même, le nom
ne s'affiche qu'en partie, puis une autre partie bout est répétée plus loin
sur la route. A droite de cette route (toujours pour ce niveau de zoom) on
trouve aussi un "r" perdu dans la forêt ;-).
Ce que dit Philippe semble coller avec ce que j'ai fait : j'ai uploadé la
zone forestière en 3 fois au lieu de l'uploader en une fois. Peut être le
mieux pour la suite serait de sauvegarder mes modifs dans JOSM puis lorsque
c'est complet, envoyer le tout ?

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

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

[Philippe Verdy]

Le 23 février 2012 23:34, Vincent de Chateau-Thierry
 a écrit :
> Le 23/02/2012 23:04, Philippe Verdy a écrit :
>> Dans ce cas on peut toujours créer deux voies parallèles, une pour
>> chaque sens, avec des tags access distincts (même si ça complique un
>> peu le mapping des intersections, pour un routage correct, et aussi
>> les relations de rues pour les adresses, ou les relations de lignes de
>> transport devant prendre en compte le sens).
>>
>
> Dessiner 2 voies alors qu'il n'y a qu'une chaussée sur le terrain ?  On ne
> taggue pas "pour l'itinéraire", pas plus que pour le rendu, et surtout pas
> en créant des voies qui n'existent pas... Et au passage, je ne vois pas en
> quoi ça améliorerait le calcul d'itinéraire, par rapport à une voie tagguée
> access=destination.

Oui mais dans le cas évoqué, access=destination s'appliquerait aux
deux sens, ce qui n'est pas le cas.

>> D'ailleurs le cas beaucoup plus courant est qu'un sens soit autorisé à
>> tous véhicules, tandis que l'autre sens est réservé aux bus et cycles
>> (mais encore interdit aussi aux riverains).
>>
>> Là encore on se retrouve à mapper des voies parallèles,
>
>
> Non, ces cas sont déjà traités sur cette page :
> http://wiki.openstreetmap.org/wiki/Access
> avec la famille de valeurs autour de "opposite".

Ces valeurs pour "opposite" ne s'appliquent qu'aux rues en sens unique
"oneway=yes/-1" (ce qu'elles ne sont pas dans le cas évoqué). Il y
diverses restrictions applicables à certains types de véhicules et
différentes selon la direction. Et puis ces tag "opposite" sont assez
mal définis et encore plus mal utilisés.

Si une rue a des accès possibles dans les deux sens, mais avec des
conditions différentes, c'est tout à fait normal de vouloir tracer une
voie dans chaque sens, même s'il n'y a qu'une seule chaussée. Ces
voies parallèles seront sans doute très proches, et justement parce
qu'on ne tague pas pour le rendu c'est possible de représenter des
voies pour chaque direction (même si on regroupe les voies multiples
dans la même direction sur un seul chemin en indiquant leur nombre
avec "lanes=", et oneway="yes" pour chaque sens, ainsi qu'une largeur
éventuelle des voies pour chaque sens, si l'indication de "lanes=" ne
permet pas une estimation correcte de la largeur, voisine de 3 mètres
par "lane" pour les voies routières).

Pour le reste, les moteurs derendus se débrouilleront pour superposer
ces voies parallèles en un seul trait, s'ils n'ont pas la place de les
séparer visuellement à un niveau de zoom donné. Ce travail de
simplification de la géométrie c'est le leur, pas celui d'OSM.

Car les voies dans que sens existent bien géographiquement, même
lorsqu'elles ne sont pas toujours matérialisées par au moins un
marquage au sol. Si réellement une rue est si étroite qu'elle ne peut
faire circuler les véhicules que dans un sens à la fois, cela ne veut
pas dire non plus que la circulation est interdite dans un sens ou
l'autre : la circulation alternée (ou avec un sens prioritaire), ça
existe aussi...

Et ça n'empêche pas de pouvoir tracer chaque sens de façon parallèle
mais séparée (non superposée) dans la largeur de la chaussée (d'autant
que les tags indiqués dans la plupart des rues ne mentionne souvent
rien du tout de ce qui se trouve sur leurs côtés comme les trottoirs,
fossés, voire même assez souvent les limites de propriétés entre la
rue et les bâtiments...).

On n'aurait pas de soucis d'interprétation des données de la base OSM
si on devait tracer non pas un chemin unique pour une rue, mais si on
les représentait comme des surfaces, découpables elles-même en voies,
trottoirs, terre-pleins central, murs et clotures de sépation... Car
la réalité des cartes c'est qu'il n'existe rien de matériel qui ne
soit un qu'un seul trai (d'une façon ou d'une autre il faut alors
estimer la largeur d'emprise de ce qui est représenté par ces traits).

Les seules lignes réelles sont les limites administratives (et
encore... car ces lignes servent aussi à délimiter des surfaces).

Si on était en coordonnées 3D, il n'y aurait pas de surface non plus
mais des volumes prenant en compte les limites de hauteur.

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

Re: [OSM-talk-fr] Changements incomplets sur les différents niveaux de zoom

[Vincent de Chateau-Thierry]

Bonjour

> De : "Philippe Verdy" 
> 
> Bref la seule chose à faire, c'est d'être patient, l'ensemble des
> modifs apparaîtra dans la semaine suivante si une partie seulement est
> prise en compte.

...et dans la mesure où les éléments édités sont repris dans la charte graphique
du rendu Mapnik. Tout ce qui est dans la base n'apparaît pas sur la carte. Et 
ce qui
apparaît à un niveau de zoom peut tout à fait disparaître à un niveau de zoom 
suivant/précédent.
C'est trivial mais ça va mieux en le disant :-)

vincent

Une messagerie gratuite, garantie à vie et des services en plus, ça vous tente ?
Je crée ma boîte mail www.laposte.net

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

Re: [OSM-talk-fr] Changements incomplets sur les différents niveaux de zoom

[Philippe Verdy]

Le 24 février 2012 13:24, Vladimir Vyskocil
 a écrit :
> La plupart du temps le ctrl-shit-r suffit SAUF pour les modifications de la 
> "coastline" mais dans ce cas il y a un délai très long (généralement 
> plusieurs semaines) avant que les modifications soit prise en compte dans la 
> base de production du fond de carte (la coastline est gérée à part) donc un 
> /dirty ne sert a rien avant que cela soit le cas. Quand les modifications de 
> la coastline sont prises en compte il est souvent nécessaire de forcer un 
> rendu sinon la tuile n'est pas recalculée tant qu'une modification de son 
> contenu (autre que la coastline) ne le déclenche.
> Il parrait qu'il y a également des recalculs forcé du fond de carte dont je 
> ne connais pas la fréquence (surement très peu souvent).

Il n'y a pas que la coastline... On voit ce problème aussi dans des
zones très denses en infos (et souvent modifiées dans certains
détails), par exemple à Paris. J'ai déjà eu des modifs pour lesquelles
il a fallu attendre plusieurs semaines pour que Mapnik les affiche.

Avec pour conséquences visibles des noms de rues mal affichés (cassés
en une partie visible et une autre invisible) ou qui ne s'alignent pas
(quand la géométrie a changé) ou ne changent pas de couleur (quand le
statut de type de rue a changé), ou avec des tronçons manquants (cas
assez fréquent quand un segment de rue commence par un nœud situé dans
une tuile et finit par un nœoud dans une autre tuiles en passant par
une troisième où elle n'a aucun noeud, car Mapnik, en ayant détecté
une modif sur un chemin, oublie encore parfois de marquer ces tuiles
intermédiaires comme étant aussi à remettre à jour; un autre cas moins
fréquent concerne des segments de rues dont seule une surcroissance
d'épaisseur déborde un peu sur une tuile voisine, car ce débord ne
figure nulle part des données OSM et ne peut même pasen être déduit
par un simple test géométrique, sans prendre en compte aussi des
paramètres propres au moteur de rendu qui sont l'épaisseur relative
des traits, et la taille des polices utilisées pour le texte).

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

Re: [OSM-talk-fr] Changements incomplets sur les différents niveaux de zoom

[Philippe Verdy]

Il me semble que les tuiles sont raffraîchies une fois puis un délai
est donné avant qu'elles soient raffraîchies à nouveau. Ce délai
visiblement peut atteindre plus d'une semaine pour Mapnik (voire
plus).
On voit ça quans une zone est modifiée plusieurs fois en plusieurs
séries d'opérations. Une mise à jour a lieu mais ne prend pas en
compte les autres modifs qui suivent.
Et ce n'est pas causé par un cache du navigateur (déjà vérifié).

S'il y a un cache il est peut-être ailleurs, et pourrait bien être
dans un proxy placé devant le serveur Mapnik lui-même (même si j'ai
des doutes sur le fait qu'un tel proxy se donne une validité de son
cache supérieure à une semaine.
Je pense sincèrement qu'il y a un limiteur directement dans le serveur
de tuiles, qui sert à réduire sa charge, afin de répartir la charge
sur les tuiles restant à faire, ou à refaire, et qu'il ne veut pas
mettre à jour aussi souvent que ce que demandent les visiteurs.

Bref la seule chose à faire, c'est d'être patient, l'ensemble des
modifs apparaîtra dans la semaine suivante si une partie seulement est
prise en compte.
Le 24 février 2012 12:50, aa mail  a écrit :
> Bonjour Pieren, merci.
> Il y a quelque chose que je n'ai pas du saisir :
> J'ai uploadé ces fichiers il y a 2 jours. Et certains éléments
> n'apparaissent pas pour différents niveaux de zoom, aujourd'hui. J'ai
> rafraichi le cache avec CTRL+Shift+R et ça ne change rien : les éléments
> uploadés n'apparaissent toujours pas. Mon problème et ma question est donc :
> comment faire pour qu'ils apparaissent ?
> J'ai pourtant passé les éléments ajoutés au Validator sous JOSM et tout est
> OK. Pourquoi les éléments uploadés n'apparaissent pas? J'ai loupé quelque
> chose ?
>
> Mapscrib
>
> Le 24 février 2012 12:37, Pieren  a écrit :
>
>> 2012/2/24 aa mail :
>>
>> > De plus, je ne me vois pas copier chaque adresse de tuile modifiée et
>> > ajouter "/dirty" pour forcer son rafraichissement.
>> > Une solution ?
>>
>> L'usage du /dirty est exceptionnel. Le rafraichissement du cache de
>> ton navigateur devrait suffire la plupart du temps si rien ne change
>> quelques minutes après l'upload.
>> Les niveaux de zooms les plus faibles ne sont pas non plus actualisés
>> en instantané.
>> Et il existe d'autres cartes en lignes avec les données OSM comme
>> http://open.mapquest.fr/ par exemple.
>>
>> Pieren
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/talk-fr
>
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>

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

Re: [OSM-talk-fr] Changements incomplets sur les différents niveaux de zoom

[Vladimir Vyskocil]

On 24 févr. 2012, at 12:12, aa mail wrote:

> Merci pour ta réponse,
> j'ai donc suivi ce qui est indiqué dans la page que tu m'as indiqué.
> J'ai ajouté donc "/dirty" à la fin de l'adresse d'une tuile pour forcer son  
> : pour l'une ça a marché après avoir deplus fait " [ctrl]+[shift]+[r] " mais 
> pour les autres ça ne change rien... 
> De plus, je ne me vois pas copier chaque adresse de tuile modifiée et ajouter 
> "/dirty" pour forcer son rafraichissement.
> Une solution ?

Le /dirty sur une tuile a un effet également sur les voisines (du même niveau 
de zoom). 

La plupart du temps le ctrl-shit-r suffit SAUF pour les modifications de la 
"coastline" mais dans ce cas il y a un délai très long (généralement plusieurs 
semaines) avant que les modifications soit prise en compte dans la base de 
production du fond de carte (la coastline est gérée à part) donc un /dirty ne 
sert a rien avant que cela soit le cas. Quand les modifications de la coastline 
sont prises en compte il est souvent nécessaire de forcer un rendu sinon la 
tuile n'est pas recalculée tant qu'une modification de son contenu (autre que 
la coastline) ne le déclenche. 
Il parrait qu'il y a également des recalculs forcé du fond de carte dont je ne 
connais pas la fréquence (surement très peu souvent).

Vlad.


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

Re: [OSM-talk-fr] Changements incomplets sur les différents niveaux de zoom

[Pieren]

2012/2/24 aa mail :

> J'ai pourtant passé les éléments ajoutés au Validator sous JOSM et tout est
> OK. Pourquoi les éléments uploadés n'apparaissent pas? J'ai loupé quelque
> chose ?

Est-ce que tu pourrais nous envoyer un permalien de la zone (c'est un
lien que tu peux générer en cliquant sur le "permalien" ou "permalink"
en bas à droite de la carte en ligne de la forme
"http://www.openstreetmap.org/?lat=45.77168&lon=3.08546&zoom=17&layers=M";
par exemple. On peut aussi trouver dans ce lien le niveau de zoom dans
la partie "&zoom=xx") ?
ou le nom de la commune ou des données modifiées (ton pseudo OSM
devrait suffire puisque tout un chacun peut ensuite voir ce qui tu as
édité) ?
Et nous dire dans le détail (par exemple la route D28 entre VillageA
et VillageB) quelles sont les choses que tu as modifié et qui ne se
reflètent pas sur la carte.
Ou nous donner la référence (l'URL) d'une tuile qui nécessiterait de
ton point de vue un /dirty (sans le faire).
Sans ces détails, il nous est difficile d'en dire plus.

Pieren

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

Re: [OSM-talk-fr] Changements incomplets sur les différents niveaux de zoom

[aa mail]

Bonjour Pieren, merci.
Il y a quelque chose que je n'ai pas du saisir :
J'ai uploadé ces fichiers il y a 2 jours. Et certains éléments
n'apparaissent pas pour différents niveaux de zoom, aujourd'hui. J'ai
rafraichi le cache avec CTRL+Shift+R et ça ne change rien : les éléments
uploadés n'apparaissent toujours pas. Mon problème et ma question est donc
: comment faire pour qu'ils apparaissent ?
J'ai pourtant passé les éléments ajoutés au Validator sous JOSM et tout est
OK. Pourquoi les éléments uploadés n'apparaissent pas? J'ai loupé quelque
chose ?

Mapscrib

Le 24 février 2012 12:37, Pieren  a écrit :

> 2012/2/24 aa mail :
>
> > De plus, je ne me vois pas copier chaque adresse de tuile modifiée et
> > ajouter "/dirty" pour forcer son rafraichissement.
> > Une solution ?
>
> L'usage du /dirty est exceptionnel. Le rafraichissement du cache de
> ton navigateur devrait suffire la plupart du temps si rien ne change
> quelques minutes après l'upload.
> Les niveaux de zooms les plus faibles ne sont pas non plus actualisés
> en instantané.
> Et il existe d'autres cartes en lignes avec les données OSM comme
> http://open.mapquest.fr/ par exemple.
>
> Pieren
>
> ___
> 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] Changements incomplets sur les différents niveaux de zoom

[Pieren]

2012/2/24 aa mail :

> De plus, je ne me vois pas copier chaque adresse de tuile modifiée et
> ajouter "/dirty" pour forcer son rafraichissement.
> Une solution ?

L'usage du /dirty est exceptionnel. Le rafraichissement du cache de
ton navigateur devrait suffire la plupart du temps si rien ne change
quelques minutes après l'upload.
Les niveaux de zooms les plus faibles ne sont pas non plus actualisés
en instantané.
Et il existe d'autres cartes en lignes avec les données OSM comme
http://open.mapquest.fr/ par exemple.

Pieren

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

[OSM-talk-fr] Projet "cartographies web partagées" à Ivry-sur-Seine

[Romain MEHUT]

Bonjour,

Au hasard je suis tombé sur http://www.atravers.org/Presentation-du-projet

Le prochain atelier est le 7 mars:
http://www.atravers.org/Atelier-hebdomadaire

Aucune information si OSM est la solution retenue. Quelqu'un en a-t-il
entendu parler?

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

Re: [OSM-talk-fr] Changements incomplets sur les différents niveaux de zoom

[aa mail]

Merci pour ta réponse,
j'ai donc suivi ce qui est indiqué dans la page que tu m'as indiqué.
J'ai ajouté donc "/dirty" à la fin de l'adresse d'une tuile pour forcer
son  : pour l'une ça a marché après avoir deplus fait " [ctrl]+[shift]+[r]
" mais pour les autres ça ne change rien...
De plus, je ne me vois pas copier chaque adresse de tuile modifiée et
ajouter "/dirty" pour forcer son rafraichissement.
Une solution ?

Mapscrib

Le 24 février 2012 10:20, Fabien  a écrit :

> Le 24 février 2012 10:15, aa mail  a écrit :
> > bonjour,
> > Je viens de m'inscrire et ai commencé à contribuer pour la zone grand
> ouest.
> > Pour certaines modifications, les modifications ne sont actualisées sur
> le
> > site OSM pour tous les niveaux de zoom : c'est à dire que pour certains
> > niveaux de zoom, les routes tracées ont des tronçons manquant... Le
> tutoriel
> > dit que cela peut prendre quelques heures, mais cela fait déjà deux
> jours!
> > Quelqu'un pourrait-il me dire comment y remédier ?
> > Merci,
> > Mapscrib
> >
>
> Bonjour,
>
> Un élément de réponse :
> http://lists.openstreetmap.org/pipermail/talk-fr/2011-September/035849.html
>
> Sinon peut-être fait un [ctrl]+[shift]+[r] pour voir si ce n'est pas
> une tuile en cache dans le navigateur ?
>
> Fabien
>
> ___
> 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] Sens interdit sauf pour les résidents ?

[Pieren]

2012/2/24  :
> Sur le fond de la discussion, ce type de panneau "sens interdit sauf 
> riverains" (ou desserte locale) n'a aucune connotation de "sens unique", mais 
> plutôt d'accès restreint. D'ailleurs un "sens interdit" comme on l'appelle, 
> ne signifie pas forcément qu'on puisse passer dans l'autre sens :)

Mouais. Les rues interdites dans les deux sens sans être piétonnes
sont quand même exceptionnelles (je n'en connais qu'une seule dans ma
région) et bien moins fréquentes que le "sens unique sauf riverains".
Du point de vue du principe, je trouve même cela assez scandaleux.
Cela revient à privatiser une rue de fait (puisque théoriquement, le
public ne peut plus traverser cet espace, à part les piétons).

Pieren

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

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

[Vladimir Vyskocil]

On 24 févr. 2012, at 11:23, te...@free.fr wrote:

> Salut,

Salut,

> 
> Waze est TRES limité en termes de fonctionnalités, comparé à OSM !
> Il mime en quelque sorte les techniques d'orientation des fourmis, à savoir 
> si quelqu'un est passé avant toi par ce chemin, alors tu dois pouvoir 
> passer...

C'est un peu plus évolué que ça quand même, d'après ce que j'ai compris suivant 
les pays ils ont des accords pour exploiter des données carto (non libre) comme 
base de départ et la communauté remonte les problèmes/ou pas soit en mode 
fourmis (plutot Pac Man dans leur cas) comme tu dis, soit avec des outils assez 
rudimentaires (très loin de Potlach par exemple). En france le réseau de départ 
semble très mauvais...

> 
> Sur le fond de la discussion, ce type de panneau "sens interdit sauf 
> riverains" (ou desserte locale) n'a aucune connotation de "sens unique", mais 
> plutôt d'accès restreint. D'ailleurs un "sens interdit" comme on l'appelle, 
> ne signifie pas forcément qu'on puisse passer dans l'autre sens :)
> 
> Teuxe
> 


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

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

[teuxe]

Salut,

Waze est TRES limité en termes de fonctionnalités, comparé à OSM !
Il mime en quelque sorte les techniques d'orientation des fourmis, à savoir si 
quelqu'un est passé avant toi par ce chemin, alors tu dois pouvoir passer...

Sur le fond de la discussion, ce type de panneau "sens interdit sauf riverains" 
(ou desserte locale) n'a aucune connotation de "sens unique", mais plutôt 
d'accès restreint. D'ailleurs un "sens interdit" comme on l'appelle, ne 
signifie pas forcément qu'on puisse passer dans l'autre sens :)

Teuxe

- Mail Original -
De: "Vladimir Vyskocil" 
À: "Discussions sur OSM en français" 
Envoyé: Vendredi 24 Février 2012 11h13:08 GMT +01:00 Amsterdam / Berlin / Berne 
/ Rome / Stockholm / Vienne
Objet: Re: [OSM-talk-fr] Sens interdit sauf pour les résidents ?

Je suis allé voir sur le terrain et la route a bien un panneau "sens interdit 
sauf riverain" à chaque bout, donc la solution acces=destination est la bonne.
A la base je me suis interrogé car en essayant le logiciel Waze j'ai vu qu'il 
routait par ce chemin... Ils gagneraient beaucoup en qualité de routage a 
passer sur OSM... Et OSM y gagnerait surement aussi, mais bon c'est comme ça.

On 22 févr. 2012, at 23:12, Vladimir Vyskocil wrote:

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



___
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] Sens interdit sauf pour les résidents ?

[Vladimir Vyskocil]

Je suis allé voir sur le terrain et la route a bien un panneau "sens interdit 
sauf riverain" à chaque bout, donc la solution acces=destination est la bonne.
A la base je me suis interrogé car en essayant le logiciel Waze j'ai vu qu'il 
routait par ce chemin... Ils gagneraient beaucoup en qualité de routage a 
passer sur OSM... Et OSM y gagnerait surement aussi, mais bon c'est comme ça.

On 22 févr. 2012, at 23:12, Vladimir Vyskocil wrote:

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



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

Re: [OSM-talk-fr] Compte-rendu d'une sortie découverte en VTT

[Romain MEHUT]

Le 24 février 2012 10:45, Pieren  a écrit :

> 2012/2/24 Romain MEHUT :
>
> Est-ce que cet itinéraire est balisé sur le terrain ? Est-il définit
> par une quelconque autorité ?
>

Oui comme je viens de le dire. Il lui manque cependant un nom...


> D'après moi (et d'autres), c'est une condition indispensable pour
> importer des itinéraires dans OSM.
>
> Pieren
>  ___
> 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] Compte-rendu d'une sortie découverte en VTT

[Romain MEHUT]

Le 24 février 2012 10:44, Guillaume Allegre  a
écrit :

> Le ven. 24 fevr. 2012 à 10:21 +0100, Romain MEHUT a ecrit :
>
> > Dans le langage OSM, pour construire un itinéraire il s'agit de créer une
> > relation en sélectionnant les différents membres de cet itinéraire. Le
> > détail est ici * *http://www.openstreetmap.org/browse/relation/2048957soit
> > 84 membres.
>
> Juste pour bien comprendre, c'est un itinéraire "perso" pour l'instant,
> mais ça a vocation a devenir un itinéraire répertorié/balisé par la
> commune,
> donc officiel ?
>
> Parce que dans l'hypothèse où il ne serait pas "officialisé", il faudra
> bien
> supprimer cette relation un jour, et donc dans quel délai, etc ?
>

Oui oui rassurez-vous, cet itinéraire est bien balisé, enfin certaines
portions sont un peu limites mais l'objectif de la commission chemins est
bien de proposer un itinéraire de randonnée autour de la commune.


> Une autre petite question annexe : la forêt qui longe le Plancoët, c'est
> vraiment une forêt ? exploitée ? Parce que si c'est une ripisylve standard
> (végétation spontanée, pas spécialement entretenue), ce serait plutôt
> natural=wood
> (l'import CLC était un peu abrupt sur ce point).
>
> A vrai dire, je ne me suis pas occupé de toucher au landuse sur Plancoët
et ses environs. L'imagerie Bing disponible est trop imprécise pour le
moment. Par contre j'y pense est-ce que l'on peut exploiter dans JOSM la
photographie aérienne composite que l'on voir sur le visualeur de
Géobretagne http://geobretagne.fr/mapfishapp/ ? Si j'ai bien compris ce
serait une imagerie différente de celles proposées *via* le WMS ouvert?


> A part ça, bravo pour l'initiative d'encadrement cartographique d'une
> sortie.
>
> --
>  ° /\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
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Compte-rendu d'une sortie découverte en VTT

[Pieren]

2012/2/24 Romain MEHUT :

Est-ce que cet itinéraire est balisé sur le terrain ? Est-il définit
par une quelconque autorité ?
D'après moi (et d'autres), c'est une condition indispensable pour
importer des itinéraires dans OSM.

Pieren

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

Re: [OSM-talk-fr] Compte-rendu d'une sortie découverte en VTT

[Guillaume Allegre]

Le ven. 24 fevr. 2012 à 10:21 +0100, Romain MEHUT a ecrit :

> Dans le langage OSM, pour construire un itinéraire il s'agit de créer une
> relation en sélectionnant les différents membres de cet itinéraire. Le
> détail est ici * *http://www.openstreetmap.org/browse/relation/2048957 soit
> 84 membres.

Juste pour bien comprendre, c'est un itinéraire "perso" pour l'instant, 
mais ça a vocation a devenir un itinéraire répertorié/balisé par la commune,
donc officiel ?

Parce que dans l'hypothèse où il ne serait pas "officialisé", il faudra bien
supprimer cette relation un jour, et donc dans quel délai, etc ?


Une autre petite question annexe : la forêt qui longe le Plancoët, c'est
vraiment une forêt ? exploitée ? Parce que si c'est une ripisylve standard
(végétation spontanée, pas spécialement entretenue), ce serait plutôt 
natural=wood
(l'import CLC était un peu abrupt sur ce point).


A part ça, bravo pour l'initiative d'encadrement cartographique d'une sortie.



-- 
 ° /\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

Re: [OSM-talk-fr] Changements incomplets sur les différents niveaux de zoom

[Fabien]

Le 24 février 2012 10:15, aa mail  a écrit :
> bonjour,
> Je viens de m'inscrire et ai commencé à contribuer pour la zone grand ouest.
> Pour certaines modifications, les modifications ne sont actualisées sur le
> site OSM pour tous les niveaux de zoom : c'est à dire que pour certains
> niveaux de zoom, les routes tracées ont des tronçons manquant... Le tutoriel
> dit que cela peut prendre quelques heures, mais cela fait déjà deux jours!
> Quelqu'un pourrait-il me dire comment y remédier ?
> Merci,
> Mapscrib
>

Bonjour,

Un élément de réponse :
http://lists.openstreetmap.org/pipermail/talk-fr/2011-September/035849.html

Sinon peut-être fait un [ctrl]+[shift]+[r] pour voir si ce n'est pas
une tuile en cache dans le navigateur ?

Fabien

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

[OSM-talk-fr] Changements incomplets sur les différents niveaux de zoom

[aa mail]

bonjour,
Je viens de m'inscrire et ai commencé à contribuer pour la zone grand ouest.
Pour certaines modifications, les modifications ne sont actualisées sur le
site OSM pour tous les niveaux de zoom : c'est à dire que pour certains
niveaux de zoom, les routes tracées ont des tronçons manquant... Le
tutoriel dit que cela peut prendre quelques heures, mais cela fait déjà
deux jours! Quelqu'un pourrait-il me dire comment y remédier ?
Merci,
Mapscrib
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

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

[rldhont]

Juste une précision sur la directive INSPIRE :
* Les Etats membres se sont engagés à publier des données spatiales 
liées à l'ENVIRONNEMENT mais pas toutes les données spatiales. Disons 
que c'est le seul domaine dans lequel les états membres ont pensés qu'il 
n'y avait pas de perte de souveraineté.



Le 23/02/2012 19:27, Cyrille Giquello a écrit :

Vite fait: n'oublie pas la directive européenne INSPIRE qui oblige a
publier toutes les données spatiales (géo). La question de la
responsabilité est donc un faux problème. Cyrille

Le 20/02/12, Brice  a écrit :

Bonsoir,

Le responsable SIG (cf. mél précédent ci-dessous) m'a re-contacté avec les
demandes suivantes :

Pour alimenter notre réflexion sur ce sujet pourriez-vous me transmettre les
documents suivants :
-  Exemple de partenariat collectivité territoriale / OSM.
-  Le modèle de données de la base géographique.
-  Le manuel qualité de la base.
Pourriez vous me confirmer les points suivants :
-  La traçabilité de l’information stockée dans la base est assurée
(qui produit quoi quand )
-  La question juridique de la responsabilité du producteur de la
données géographique n’est pas encore tranchée.
-  Le risque de malveillance vis-à-vis de la donnée existe mais
reste minime.
-  Le retour de la communauté vis-à-vis de la libération de la
donnée publique est positif et stimule l’actualisation.


Voici la réponse que je prévois de lui transmettre,
je suis preneur de vos corrections / compléments, merci d'avance.


-  Exemples de partenariat collectivité territoriale / OSM :
Brest qui a mis à disposition de la communauté OpenStreetMap des orthophotos
et ses données géographiques
(http://wiki.openstreetmap.org/wiki/Brest#Donn.C3.A9es_de_la_Communaut.C3.A9_Urbaine)
idem pour la Communauté de Communes de Concarneau Cornouaille
(http://wiki.openstreetmap.org/wiki/WikiProject_France/Donn%C3%A9es_de_la_Communaut%C3%A9_de_Communes_de_Concarneau_Cornouaille)
et bien d'autres, la page
(http://wiki.openstreetmap.org/wiki/Category:WikiProject_France/Imports)
recense les accords donnés par des institutions avec pour conséquence des
imports dans  OpenStreetMap

-  Le modèle de données de la base géographique.
http://wiki.openstreetmap.org/wiki/FR:Component_overview

-  Le manuel qualité de la base.
http://wiki.openstreetmap.org/wiki/FR:Quality_Assurance
***>>>  un petit texte serait le bienvenue, y a t'il quelquechose sur le
wiki, à votre connaissance ?

-  La traçabilité de l’information stockée dans la base est assurée
(qui produit quoi quand )
Toute contribution est enregistrée dans la base avec l'auteur (il n'y a pas
de contribution anonyme), tous les enregistrements (créations ex-nihilo,
modifications, suppressions) sont conservées sans limitation de durée.


-  La question juridique de la responsabilité du producteur de la
données géographique n’est pas encore tranchée.
Cette question juridique dépend plus des conditions de mise à disposition
par le producteur de données que l'utilisation qui en est faite par la
communauté OpenStreetMap.
La diffusion d'information des données publiques, souhaitée par l'État
(http://www.data.gouv.fr/Articles/La-politique-de-la-France-en-matiere-d-ouverture-des-donnees-publiques)
doit encourager la réutilisation de celles-ci par une mise à disposition
gratuite et l'application d'une licence ouverte. C'est dans ce cadre
qu'Etalab a conçu la "Licence Ouverte / Open Licence"
(http://www.etalab.gouv.fr/pages/licence-ouverte-open-licence-5899923.html).

Extraits de cette licence :
- "Cette mention de paternité ne doit ni conférer un caractère officiel à la
réutilisation de « l’Information », ni suggérer une quelconque
reconnaissance ou caution par le « Producteur », ou par toute autre entité
publique, du « Réutilisateur » ou de sa réutilisation. "
- "Responsabilité
L’Information » est mise à disposition telle que produite ou reçue par le «
Producteur », sans autre garantie expresse ou tacite qui n’est pas prévue
par la présente licence.
Le « Producteur » garantit qu’il met à disposition gratuitement «
l’Information » dans les libertés et les conditions définies par la présente
licence. Il ne peut garantir l’absence de défauts ou d’irrégularités
éventuellement contenues dans « l’Information ». Il ne garantit pas la
fourniture continue de « l’Information ». Il ne peut être tenu pour
responsable de toute perte, préjudice ou dommage de quelque sorte causé à
des tiers du fait de la réutilisation.
Le « Réutilisateur » est le seul responsable de la réutilisation de «
l’Information ». La réutilisation ne doit pas induire en erreur des tiers
quant au contenu de « l’Information », sa source et sa date de mise à jour."


-  Le risque de malveillance vis-à-vis de la donnée existe mais
reste minime.
Comme tout système collaboratif sur le mode wiki, toute personne, après
création d'un compte peur modifier les données, le risque de malveillance
e