Re: [OSM-talk-fr] Generation de cartes raster à la volée

2016-01-22 Par sujet JB 

Salut Nicolas,
C'est la même technique que celle que j'avais utilisée après la 
cartopartie à Saint-Côme-et-Marjevols. Elle est décrite en accéléré ici 
: 
http://forum.openstreetmap.fr/viewtopic.php?f=22=2203=isonoe=10 
. Comme tu bidouilles régulièrement les données OSM et maperitive, ça ne 
devrait pas trop te poser de problèmes, sinon, demande !

JB.

Le 22/01/2016 09:47, Nicolas Moyroud a écrit :
J'allais proposer la même chose : scriptage Maperitive. Avec cerise 
sur le gâteau la possibilité d'utiliser le magnifique style R25 mis au 
point par notre ami JB :-)
Bon évidemment ça ne reste utilisable que sur des petites zones mais 
là ça à l'air d'être le cas.
Tiens en passant petite question pour JB : comment fais-tu le masque 
sur les contours de la commune dans ton exemple ?


Nicolas

Le 22/01/2016 08:32, JB a écrit :
Méthode crado que j'utiliserais à petite échelle et pour des petites 
surfaces parce que ce sont les outils que je connais : un peu de 
scriptage de maperitive : taper dans une base pour récupérer les 
données, appliquer une feuille de style, éventuellement ajouter tes 
données à toi directement à ce niveau-là, exporter la zone à la 
demande. Il y a aussi la possibilité d'utiliser des dalles 
disponibles (osm défaut ou autre), mais j'ai l'impression qu'il y a 
toujours un tout petit filet entre les dalles. Peu visible, mais à 
mon avis, dérangeant pour une impression propre (par exemple : 
http://jb.isonoe.net/temp/demo1.png).

JB.



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



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

Re: [OSM-talk-fr] Import de défibrillateurs sur Toulouse

2016-01-22 Par sujet osm . sanspourriel 

OK pour les autres autres propositions.
Pour l'intégrité des données, normalement quand tu importes ou ajoute 
des objets, tu vérifie l'intégrité.

Avec la source qui voudra pourra vérifier la qualité du travail.
Ajoute une note plus précise sur le changeset si tu le trouves utile.

Jean-Yvon

Le 22/01/2016 13:48, Tyndare - tynd...@wanadoo.fr a écrit :

Mais pour le reste, tout ce qui correspond à l'adresse le nom du site et le 
"type_structure"
1) on les zappe tout simplement ?
Ca pourrait quand même utile pour vérifier l'intégrité des données.
2) On agrège les valeurs dans un tag "note" ?
3) On crée un nouveau tag "defibrillator:addr"  ?
4) ou  "defibrillator:addr:*" ?

On pourrait agréger de cette manière :
«nom_site (type_structure) adresse commune»
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Import de défibrillateurs sur Toulouse

2016-01-22 Par sujet Christian Quest 
Non, désolé, addr:* ça sert à décrire dans OSM une adresse, et la règle
générle est de ne décrire un objet qu'une fois.

La position du défibrillateur n'est pas la position de l'adresse en elle
même. Il est dans un bâtiment qui est à une certaine adresse, mais il ne
faut pas tout mélanger.

Quand on a plusieurs addr:number on fait comment ? On a N fois l'adresse ?
Non bien sûr.

C'est à ça aussi que sert contact:* à indiquer l'adresse correspondant à un
POI, même si le POI N'EST PAS l'adresse.


Le 22 janvier 2016 à 12:57, Philippe Verdy  a écrit :

> Je ne suis pas d'accord, l'un et l'autre auraient du sens. addr:* pour
> l'adresse de localisation physique, l'autre pour l'adresse du service
> responsable de l'installation et l'entretien. Et ceci même si un
> défibrillateur n'est pas une adresse de "résidence" (il n'y a pas
> d'occupant dans ce micro-lieu).
>
> Il n'y a RIEN qui précise que addr:* ou contact:* sont réservés uniquement
> aux objets qui sont des résidences ou locaux commerciaux. Là je crois que
> tu tombes dans la volonté de voulkoir unifier avec BANO, mais même la base
> adresse source du cadastre (ou d'autres services) ne fait pas une telle
> réservation et stocke des adresses pour d'autre choses que les seules
> personnes physiques (et OSM n'est pas réservé non plus à la géolocalisation
> des seules personnes physiques).
>
> On ferait la même remarique pour une bpite à lettres, une cabine
> téléphonique, un container de recyclage, une armoire technique de rue, un
> transformateur électrique, une bouche d'égout, une antenne mobile. Si cela
> est utile je ne vois pas pourquoi on ne pourrait pas utiliser addr:* et/ou
> contact:*, même s'il n'y a aucun courrier qui peut arriver à ces adresses.
> OSM n'est pas réservé aux utilisations postales.
>
> Le 22 janvier 2016 à 11:45, Christian Quest  a
> écrit :
>
>> addr:* n'a rien à faire sur un défibrillateur... ni même contact:*
>>
>>
>> On 21/01/2016 13:58, Tyndare wrote:
>> > Bonjour,
>> >
>> > J'ai remarqué un import des défribilateurs
>> > dont la liste est dispo en ODBL pour Toulouse.
>> >
>> > Autant je suis d'accord sur l'utilité des données autant je pense que
>> le choix des tags annexes aurait mérite d'être discuté:
>> >
>> > On peut voir les tags originaux dans l'historique:
>> >
>> > https://www.openstreetmap.org/node/3953673079/history
>> >
>> > Je ne suis pas sur qu'utiliser addr:* et loc_ref soit une bonne idée.
>> >
>> > Quelles sont vos propositions pour corriger ?
>> >
>> >
>> > Tyndare.
>> >
>> >
>> > ___
>> > Talk-fr mailing list
>> > Talk-fr@openstreetmap.org
>> > https://lists.openstreetmap.org/listinfo/talk-fr
>>
>> --
>> Christian Quest - OpenStreetMap France
>>
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>


-- 
Christian Quest - OpenStreetMap France
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Generation de cartes raster à la volée

2016-01-22 Par sujet Nicolas Moyroud 
J'allais proposer la même chose : scriptage Maperitive. Avec cerise sur 
le gâteau la possibilité d'utiliser le magnifique style R25 mis au point 
par notre ami JB :-)
Bon évidemment ça ne reste utilisable que sur des petites zones mais là 
ça à l'air d'être le cas.
Tiens en passant petite question pour JB : comment fais-tu le masque sur 
les contours de la commune dans ton exemple ?


Nicolas

Le 22/01/2016 08:32, JB a écrit :
Méthode crado que j'utiliserais à petite échelle et pour des petites 
surfaces parce que ce sont les outils que je connais : un peu de 
scriptage de maperitive : taper dans une base pour récupérer les 
données, appliquer une feuille de style, éventuellement ajouter tes 
données à toi directement à ce niveau-là, exporter la zone à la 
demande. Il y a aussi la possibilité d'utiliser des dalles disponibles 
(osm défaut ou autre), mais j'ai l'impression qu'il y a toujours un 
tout petit filet entre les dalles. Peu visible, mais à mon avis, 
dérangeant pour une impression propre (par exemple : 
http://jb.isonoe.net/temp/demo1.png).

JB.



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

Re: [OSM-talk-fr] OpenEvacMap...

2016-01-22 Par sujet dHuy Pierre 
Bah les plans d'évacuation incendie réfère à la loi sur les ERPs (établissement 
recevant du public), les rendant obligatoire et visible (plan complet à 
l'entrée principale, un plan d'étage par étage...). De plus un plan complet 
doit être déposé (chez les pompiers de mémoire). D'où ma question de 
participation des instances publiques à ce projet :) 

Le Jeudi 21 janvier 2016 23h52, "osm.sanspourr...@spamgourmet.com" 
 a écrit :
 

  
 Le 21/01/2016 11:47, Christian Quest - cqu...@openstreetmap.fr a écrit :
  
 
 On 21/01/2016 10:22, Otourly Wiki wrote:
 
 
 Hello, Curieux ici le site n'en fini pas de mouliner.  La géoloc est 
obligatoire... sans elle, rien ne s'affichera.
 Effectivement en acceptant la géolocalisation, ça marche.
 Sauf que la géolocalisation à partir d'une ligne fixe au moins dans mon cas ça 
donne le centre le la commune.
 Il faudrait donc pouvoir choisir à l'intérieur de cette zone (graphiquement, 
par saisie d'une adresse, dans une liste si c'est raisonnable).
 Sinon il faut truander l'API de géolocalisation.
 
 
 
  Par contre certains propriétaires pourraient être réticents à l'idée de voir 
des plans de leur commerce sur un site...  
 
 Une option serait un formulaire de demande de "take down" comme disent les 
ricains...
 
 Toujours la question : opt-in ou opt-out ?
 
 Et on peut imaginer que suivant la possibilité d'accéder à l'information, les 
gens sont d'accord (par exemple si c'est pour les services de secours) ou pas 
(certains lieux peuvent être sensibles).
 Pourtant si la centrale nucléaire est sûre, ce n'est pas parce que l'on sait 
comment l'évacuer qu'elle sera plus dangereuse.
 Ah, c'est vrai j'ai dit "si" ;-).
 
 Quant aux droits intellectuels, il faudrait être vraiment mauvais coucheur 
pour reprocher la reproduction d'une police de caractères sur un plan 
d'évacuation.
 
 N. B. : le droit n'est pas trop mal fait, il est parfaitement légal de 
défoncer une porte pour évacuer une personne. "nécessité fait loi". La 
publication des plans d'évacuation peut sans doute s'y référer.
 
 Jean-Yvon
 
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


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

Re: [OSM-talk-fr] historic=citywalls et barrier=retaining_wall

2016-01-22 Par sujet lenny.libre 

Bonjour,
Peut-être pourrions-nous jumeler les deux messages : 
http://gis.19327.n5.nabble.com/ville-fortifieee-tp5864154.html


lenny

Le 22/01/2016 00:48, Muselaar a écrit :

Bonsoir,

J'ai cru bon, pour les murs restants d'un ancien fort (1865-70) qui 
comportaient comme unique tag barrier=city_wall, de le remplacer par 
historic=citywalls, et d'ajouter barrier=retaining_wall.
Il me semblait que c'est correct, dans la mesure où ces murs se 
présentent comme des remparts, mais sont également des murs de 
soutènement, puisque du côté « intérieur », ils sont en fait soit 
surmontés d'un talus de terre, avec végétation, ou servent réellement 
de soutènement en raison de la dénivellation du terrain naturel.


Mais je suis un peu surpris du rendu :

Sur Mapnik, cela fait deux gros traits gris parallèles (il y a un 
fossé tout le tour du fort), qui sautent aux yeux en faisant un pâté 
dès le zoom 14. Pas forcément très pertinent.


Du coup, je me demande : ai-je traité correctement cet élément ?Ou 
bien est-ce que c'est le rendu qui doit être adapté pour des cas de ce 
type ?


http://www.openstreetmap.org/way/212114048

Qu'en pensez-vous ?

Muselaar

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



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

Re: [OSM-talk-fr] Jeux de données OSM

2016-01-22 Par sujet Nicolas Dumoulin 
Salut,

Le Friday 22 January 2016, 09:41:05 Nicolas Moyroud a écrit :
> et j'ai bidouillé une interface carto qui liste une partie de
> ces
> données (seulement les couches de points) :
> https://cartosm.teledetection.fr/osmlr/
> Il faudrait que j'améliore cette interface (notamment avec du LizMap)
> mais je n'ai pas encore eu le temps de m'y mettre.

Super ! Sérieux, ton interface vaut bien celle de lizmap. Peut-être moins 
riche et clinquante, mais super légère et efficace.
Il manque juste le crédit OSM (rholala) et un petit lien vers le code source 
php :-)

Merci

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


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

Re: [OSM-talk-fr] Generation de cartes raster à la volée

2016-01-22 Par sujet Christian Quest 
Comme Thomas, je m'appuierai sur les vrt de GDal.

C'est le plus simple à mettre en oeuvre.

-- 
Christian Quest - OpenStreetMap France


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

Re: [OSM-talk-fr] Import de défibrillateurs sur Toulouse

2016-01-22 Par sujet Christian Quest 
addr:* n'a rien à faire sur un défibrillateur... ni même contact:*


On 21/01/2016 13:58, Tyndare wrote:
> Bonjour,
>
> J'ai remarqué un import des défribilateurs
> dont la liste est dispo en ODBL pour Toulouse.
>
> Autant je suis d'accord sur l'utilité des données autant je pense que le 
> choix des tags annexes aurait mérite d'être discuté:
>
> On peut voir les tags originaux dans l'historique:
>
> https://www.openstreetmap.org/node/3953673079/history
>
> Je ne suis pas sur qu'utiliser addr:* et loc_ref soit une bonne idée.
>
> Quelles sont vos propositions pour corriger ?
>
>
> Tyndare.
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr

-- 
Christian Quest - OpenStreetMap France


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

Re: [OSM-talk-fr] OpenEvacMap...

2016-01-22 Par sujet Christian Quest 
On 21/01/2016 12:14, dHuy Pierre wrote:
> @Cquest: Je m'étais renseigné lors de la création de la page sur la
> cartographie Indoor et nous avons le droit d'utiliser dans le cadre
> "d'un plan capté dans l'espace public" mais la diffusion est sujette
> au droit d'auteur du fait des mesures prises des styles d'impression
> propre à chaque entreprise... Je peux relancer l'avocat avec qui j'en
> avais discuté mais si il y a un avocat ici ça serait plaisant :)
> + pour le formulaire de takedown. L'upload peut être anonymisé?
>

Style d'impression ? WTF... tout ça est normé et réglementaire.

L'objectif est aussi de collecter ces plans directement auprès des
sociétés qui les réalisent, voire de rendre systématique le versement
dans une base nationale.

-- 
Christian Quest - OpenStreetMap France

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

Re: [OSM-talk-fr] OpenEvacMap...

2016-01-22 Par sujet Christian Quest 
On 22/01/2016 10:22, dHuy Pierre wrote:
> Bah les plans d'évacuation incendie réfère à la loi sur les ERPs
> (établissement recevant du public), les rendant obligatoire et visible
> (plan complet à l'entrée principale, un plan d'étage par étage...). De
> plus un plan complet doit être déposé (chez les pompiers de mémoire).
> D'où ma question de participation des instances publiques à ce projet :)
>

Les pompiers sont loin d'avoir tout... il y a toujours une différence
entre la théorie et la pratique.

Qu'en j'ai exposé l'idée aux Pompiers de Paris, ils m'ont tout d'abord
déroulé la théorie et quand on est arrivé à la pratique, là l'idée leur
a paru très bonne car complémentaire de ce qu'ils arrivent réellement à
collecter et à avoir à jour.

Pour info, sur l'intervention de janvier à l'Hyper Casher, les plans
obtenus après pas mal de recherche dataient des années 70... et ne
décrivaient pas du tout une supérette (on m'a parlé d'écuries).

-- 
Christian Quest - OpenStreetMap France

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

Re: [OSM-talk-fr] Import de défibrillateurs sur Toulouse

2016-01-22 Par sujet Philippe Verdy 
operator ne renseigne pas grand chose puisqu'on ne peut pas le trouver dans
OSM, les labels utilisés sont ambigus, les mêmes pour de larges collections
d'objets, et l'adresse réelle de l'opérateur n'est renseignée nulle part ou
pas associée.

Si un défibrilateur est installé c'est à une adresse précise, même si on
n'y écrit pas. Cette adresse existe bien quelque part et c'est celle du
lieu qui l'accuerille mais qui n'est pas tagué au même endroit. La
géolocalisation elle-même ne donne pas son adresse...


Le 22 janvier 2016 à 18:10,  a écrit :

> addr: c'est pour des adresses postales, et on n'écrit pas souvent à un
> défibrillateur.
> De même on ne contacte pas souvent un défibrillateur.
>
> La localisation d'un défibrillateur c'est par ses coordonnées
> géographiques.
> C'est tout ce qui t'intéresse : le plus proche et accessible.
>
> Pour l'entretien, c'est operator par exemple qui permettra de le
> renseigner.
>
> Jean-Yvon
>
> Le 22/01/2016 12:57, Philippe Verdy - verd...@wanadoo.fr a écrit :
>
> Je ne suis pas d'accord, l'un et l'autre auraient du sens. addr:* pour
> l'adresse de localisation physique, l'autre pour l'adresse du service
> responsable de l'installation et l'entretien. Et ceci même si un
> défibrillateur n'est pas une adresse de "résidence" (il n'y a pas
> d'occupant dans ce micro-lieu).
>
> Il n'y a RIEN qui précise que addr:* ou contact:* sont réservés uniquement
> aux objets qui sont des résidences ou locaux commerciaux. Là je crois que
> tu tombes dans la volonté de voulkoir unifier avec BANO, mais même la base
> adresse source du cadastre (ou d'autres services) ne fait pas une telle
> réservation et stocke des adresses pour d'autre choses que les seules
> personnes physiques (et OSM n'est pas réservé non plus à la géolocalisation
> des seules personnes physiques).
>
> On ferait la même remarique pour une bpite à lettres, une cabine
> téléphonique, un container de recyclage, une armoire technique de rue, un
> transformateur électrique, une bouche d'égout, une antenne mobile. Si cela
> est utile je ne vois pas pourquoi on ne pourrait pas utiliser addr:* et/ou
> contact:*, même s'il n'y a aucun courrier qui peut arriver à ces adresses.
> OSM n'est pas réservé aux utilisations postales.
>
> Le 22 janvier 2016 à 11:45, Christian Quest  a
> écrit :
>
>> addr:* n'a rien à faire sur un défibrillateur... ni même contact:*
>>
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Generation de cartes raster à la volée

2016-01-22 Par sujet Dominique Rousseau 
Le Thu, Jan 21, 2016 at 08:06:59PM +0100, François Lacombe 
[fl.infosrese...@gmail.com] a écrit:
> Bonsoir à tous,
> 
> Comme j'ai pu en discuter avec certains depuis quelques temps, je suis
> à la recherche d'un moyen permettant de générer des extraits jpeg/png
> d'OSM à la volée.

Sur osm.org tu as le lien "partager" qui permet d'avoir un bout de HTML
pour l'integration, ou de produire un fichier PNG.
L'url de production de l'image a cette forme là :
(la, c'est la cathedrale d'Amiens)

http://render.openstreetmap.org/cgi-bin/export?bbox=2.300434112548828,49.89362531124532,2.3037707805633545,49.89547067579316=2787=png

Pour un usage relativement occasionnel, je pense que ca conviendrait a
ce que tu veux, non ?

Sinon, gdal, mapnik, etc. comme cité par les autres...

-- 
Dominique Rousseau
d...@lee-loo.net - 06 82 43 12 27

A l'instant où l'esclave décide qu'il ne sera plus esclave,
ses chaînes tombent.  -- Mahatma Gandhi

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

Re: [OSM-talk-fr] Jeux de données OSM

2016-01-22 Par sujet Nicolas Moyroud 
Super ! Merci pour l'info. J'aime bien leur interface web. C'est une 
bonne ressource à garder sous le coude.
Sinon petit rappel, j'ai aussi mis en place un extracteur de données 
OSM, mais uniquement sur la région Languedoc-Roussillon :

https://libreavous.teledetection.fr/index.php/geomatique/30-donnees/75-publication-de-donnees-geographiques-issues-dopenstreetmap-sur-la-region-languedoc-roussillon
et j'ai bidouillé une interface carto qui liste une partie de ces 
données (seulement les couches de points) :

https://cartosm.teledetection.fr/osmlr/
Il faudrait que j'améliore cette interface (notamment avec du LizMap) 
mais je n'ai pas encore eu le temps de m'y mettre.


Nicolas

Le 22/01/2016 01:08, Donat ROBAUX a écrit :


Bonjour à tous,

Je voulais  vous signaler l'existence d'un site internet proposant des 
jeux de données pré-machées d'OSM. Je n'ai pas de mérite, c'est 
Florian (overflorian) qui l'a trouvé.


Ça se passe sur pakku.io  et ils demandent un 
feedback sur feedback.pakku.io 


Si vous avez l'occasion de tester, ça peut être pas mal pour favoriser 
la diffusion des données libres et qui ne sont pas faciles d'abord 
pour des néophytes.


Donat




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

Re: [OSM-talk-fr] Import de défibrillateurs sur Toulouse

2016-01-22 Par sujet Philippe Verdy 
Je ne suis pas d'accord, l'un et l'autre auraient du sens. addr:* pour
l'adresse de localisation physique, l'autre pour l'adresse du service
responsable de l'installation et l'entretien. Et ceci même si un
défibrillateur n'est pas une adresse de "résidence" (il n'y a pas
d'occupant dans ce micro-lieu).

Il n'y a RIEN qui précise que addr:* ou contact:* sont réservés uniquement
aux objets qui sont des résidences ou locaux commerciaux. Là je crois que
tu tombes dans la volonté de voulkoir unifier avec BANO, mais même la base
adresse source du cadastre (ou d'autres services) ne fait pas une telle
réservation et stocke des adresses pour d'autre choses que les seules
personnes physiques (et OSM n'est pas réservé non plus à la géolocalisation
des seules personnes physiques).

On ferait la même remarique pour une bpite à lettres, une cabine
téléphonique, un container de recyclage, une armoire technique de rue, un
transformateur électrique, une bouche d'égout, une antenne mobile. Si cela
est utile je ne vois pas pourquoi on ne pourrait pas utiliser addr:* et/ou
contact:*, même s'il n'y a aucun courrier qui peut arriver à ces adresses.
OSM n'est pas réservé aux utilisations postales.

Le 22 janvier 2016 à 11:45, Christian Quest  a
écrit :

> addr:* n'a rien à faire sur un défibrillateur... ni même contact:*
>
>
> On 21/01/2016 13:58, Tyndare wrote:
> > Bonjour,
> >
> > J'ai remarqué un import des défribilateurs
> > dont la liste est dispo en ODBL pour Toulouse.
> >
> > Autant je suis d'accord sur l'utilité des données autant je pense que le
> choix des tags annexes aurait mérite d'être discuté:
> >
> > On peut voir les tags originaux dans l'historique:
> >
> > https://www.openstreetmap.org/node/3953673079/history
> >
> > Je ne suis pas sur qu'utiliser addr:* et loc_ref soit une bonne idée.
> >
> > Quelles sont vos propositions pour corriger ?
> >
> >
> > Tyndare.
> >
> >
> > ___
> > Talk-fr mailing list
> > Talk-fr@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-fr
>
> --
> Christian Quest - OpenStreetMap France
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Generation de cartes raster à la volée

2016-01-22 Par sujet Antoine Riche 
Tu peux aussi utiliser l'API static map de Mapquest : 
http://www.mapquestapi.com/staticmap/

Pour quelques cartes par jour ça devrait pas poser de problème.

Le 21/01/2016 22:44, François Lacombe a écrit :

Bonsoir Jean-Yvon et merci :)

Le 21 janvier 2016 à 22:33,   a écrit :

Tu peux toujours monter un serveur WMS (il y en a aussi des publics) sur des
tuiles OSM et demander une image "qui va bien".

Non je ne souhaite pas installer ce genre de composant pour ce projet.

Par contre utiliser un WMS public qui me permettrait de générer
quelques dalles par jour ca serait le top



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

Re: [OSM-talk-fr] Jeux de données OSM

2016-01-22 Par sujet Philippe Verdy 
Le lien vers le code source PHP n'est pas du tout une obligation d'OSM,
chaque site a le droit de conserver et gérer son code. OSM ne demande un
accès et le crédit des sources QUE pour les données utilisées. Le code
source d'un site ou service n'est pas des données dérivées.

Bref libre à l'auteur de choisir s'il veut ou pas publier le code de son
site et de choisir ses termes de licence pour ça (les crédits s'imposent
seulement en cas d'utilisation de logiciels tiers selon les termes de
licence ces logiciels tiers). Libre à lui de voir quelles mentions légales
il a besoin de mettre (crédits, restrictions, responsabilité, etc.) pour
le/les auteurs ou/et les gestionnaires du site ou prestataires externes
selon les termes des contrats avec eux ou la législation locale.



Le 22 janvier 2016 à 11:39, Nicolas Dumoulin <
nicolas_openstreetmap@dumoulin63.net> a écrit :

> Salut,
>
> Le Friday 22 January 2016, 09:41:05 Nicolas Moyroud a écrit :
> > et j'ai bidouillé une interface carto qui liste une partie de
> > ces
> > données (seulement les couches de points) :
> > https://cartosm.teledetection.fr/osmlr/
> > Il faudrait que j'améliore cette interface (notamment avec du LizMap)
> > mais je n'ai pas encore eu le temps de m'y mettre.
>
> Super ! Sérieux, ton interface vaut bien celle de lizmap. Peut-être moins
> riche et clinquante, mais super légère et efficace.
> Il manque juste le crédit OSM (rholala) et un petit lien vers le code
> source
> php :-)
>
> Merci
>
> --
> Nicolas Dumoulin
> http://wiki.openstreetmap.org/wiki/User:NicolasDumoulin
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Import de défibrillateurs sur Toulouse

2016-01-22 Par sujet Tyndare 

Si on reprend les données originales, a priori on a tout ça comme informations:

 - adresse=114 AV DE LESPINET
 - commune=TOULOUSE
 - id=27.0
 - implantation=A l'entrée à droite dans vestiares des tribunes
 - nom_site=Stade Struxiano
 - source=ToulouseMetropole
 - source:date=2015-02-14
 - type_structure=salles ERP sports


Pour la valeur "id" je pense qu'il faudrait un tag du style 
"ref:FR:ToulouseMetropole"
des objections?


Pour la valeur  "implantation", sur le wiki en anglais j'ai trouvé le tag 
"defibrillator:location" qui semble bien adapté.

defibrillator:location =* a textual description where the device is located 
(e.g. "in the porter's longue")

https://wiki.openstreetmap.org/wiki/Tag:emergency%3Ddefibrillator


On garde les tag "source" et "source:date"

Mais pour le reste, tout ce qui correspond à l'adresse le nom du site et le 
"type_structure"
1) on les zappe tout simplement ?
Ca pourrait quand même utile pour vérifier l'intégrité des données.
2) On agrège les valeurs dans un tag "note" ?
3) On crée un nouveau tag "defibrillator:addr"  ?
4) ou  "defibrillator:addr:*" ?

On pourrait agréger de cette manière :
«nom_site (type_structure) adresse commune»




Le 22 janvier 2016 11:45:25 GMT+01:00, Christian Quest 
 a écrit :
>addr:* n'a rien à faire sur un défibrillateur... ni même contact:*
>
>
>On 21/01/2016 13:58, Tyndare wrote:
>> Bonjour,
>>
>> J'ai remarqué un import des défribilateurs
>> dont la liste est dispo en ODBL pour Toulouse.
>>
>> Autant je suis d'accord sur l'utilité des données autant je pense que
>le choix des tags annexes aurait mérite d'être discuté:
>>
>> On peut voir les tags originaux dans l'historique:
>>
>> https://www.openstreetmap.org/node/3953673079/history
>>
>> Je ne suis pas sur qu'utiliser addr:* et loc_ref soit une bonne idée.
>>
>> Quelles sont vos propositions pour corriger ?
>>
>>
>> Tyndare.
>>
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>
>-- 
>Christian Quest - OpenStreetMap France
>
>
>___
>Talk-fr mailing list
>Talk-fr@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/talk-fr


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

Re: [OSM-talk-fr] ville fortifiéee

2016-01-22 Par sujet Muselaar 

Bonjour,

Youpi ! Un interlocuteur ! Nous sommes donc deux. À première vue, ça me 
semble pas mal, ce que tu proposes…


Comme tu as pu voir, j'ai utilisé deux tags conjointement. Peut-être 
pourrais-tu faire de même ?


Mais je suis plutôt novice, donc je ne pourrais pas en dire plus sur cet 
usage.


Muselaar


Le 22/01/2016 11:00, lenny.libre a écrit :
> Bonjour,
> Peut-être pourrions-nous jumeler les deux messages : 
http://gis.19327.n5.nabble.com/ville-fortifieee-tp5864154.html

>
> lenny
>
> Le 22/01/2016 00:48, Muselaar a écrit :
>> Bonsoir,
>>
>> J'ai cru bon, pour les murs restants d'un ancien fort (1865-70) qui 
comportaient comme unique tag barrier=city_wall, de le remplacer par 
historic=citywalls, et d'ajouter barrier=retaining_wall.
>> Il me semblait que c'est correct, dans la mesure où ces murs se 
présentent comme des remparts, mais sont également des murs de 
soutènement, puisque du côté « intérieur », ils sont en fait soit 
surmontés d'un talus de terre, avec végétation, ou servent réellement de 
soutènement en raison de la dénivellation du terrain naturel.

>>
>> Mais je suis un peu surpris du rendu :
>>
>> Sur Mapnik, cela fait deux gros traits gris parallèles (il y a un 
fossé tout le tour du fort), qui sautent aux yeux en faisant un pâté dès 
le zoom 14. Pas forcément très pertinent.

>>
>> Du coup, je me demande : ai-je traité correctement cet élément ?Ou 
bien est-ce que c'est le rendu qui doit être adapté pour des cas de ce 
type ?

>>
>> http://www.openstreetmap.org/way/212114048
>>
>> Qu'en pensez-vous ?
>>
>> Muselaar

Le 06/01/2016 20:36, lenny.libre a écrit :

Bonjour.
J'ai visité la petite ville fortifiée de Navarrenx et rien ne 
l'indique dans OSM, je vais donc essayer de le faire ...


Quand je cherche dans osm les tags qui seraient adaptés.
Les cités que j'ai vu ne me semblent pas correspondre.
J'ai fait un petit schéma (très simplifié) : 
http://www.cjoint.com/c/FAgtvwb75Xz

- voie secondaire
- muraille
- chemin de ronde
- talus
- muret
- voie résidentielle

Les tags qui conviendraient (je n'ai pas indiqué ceux des voies)
- pour la muraille, j'ai trouvé 2 tags différents dommage
historic=citywalls (taginfo m'en ramène 259)
ou
barrier=city_wall : je préférerais histtoric, mais celui-ci 
présente l'avantage d'indiquer si un côté est plus bas que l'autre 
(taginfo m'en ramène 1938)


- higway= pedestrian pour le chemin de ronde

- en ce qui concerne le talus, je n'ai trouvé que la page 
http://wiki.openstreetmap.org/wiki/FR:IOF_mapping


Talus en terre. Pour une petit talus utilisez un seul noeud 
size=_normal_/high (?) 	IOFearth bank.png 
 	barrier 
=earth_bank 
 
ou man_made 
=embankment 
. Pour 
les talus le long du bord d'un chemin embankment 
=yes 
 
ou cutting =yes 
. optionnel: 
height =* so that 
the renderer can decide wether a slope is high or not. Peut être 
cartographié comme une aire ?



Le mieux se serait certainement barrier=earth_bank, car embankment me 
semble plus lié à une digue le long de plan/cours d'eau ?


Je vous envoie mes Meilleurs Vœux pour 2016 et merci d'avance de vos 
remarques.

Lenny



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

[OSM-talk-fr] Rencontre parisienne jeudi 28 janvier 2016

2016-01-22 Par sujet Donat ROBAUX 
Bonjour à tous,

Tout est expliqué par ici ;)
https://forum.openstreetmap.fr/viewtopic.php?f=18=3216

Au plaisir de vous revoir tous.

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

Re: [OSM-talk-fr] Import de défibrillateurs sur Toulouse

2016-01-22 Par sujet osm . sanspourriel 
addr: c'est pour des adresses postales, et on n'écrit pas souvent à un 
défibrillateur.

De même on ne contacte pas souvent un défibrillateur.

La localisation d'un défibrillateur c'est par ses coordonnées géographiques.
C'est tout ce qui t'intéresse : le plus proche et accessible.

Pour l'entretien, c'est operator par exemple qui permettra de le renseigner.

Jean-Yvon

Le 22/01/2016 12:57, Philippe Verdy - verd...@wanadoo.fr a écrit :
Je ne suis pas d'accord, l'un et l'autre auraient du sens. addr:* pour 
l'adresse de localisation physique, l'autre pour l'adresse du service 
responsable de l'installation et l'entretien. Et ceci même si un 
défibrillateur n'est pas une adresse de "résidence" (il n'y a pas 
d'occupant dans ce micro-lieu).


Il n'y a RIEN qui précise que addr:* ou contact:* sont réservés 
uniquement aux objets qui sont des résidences ou locaux commerciaux. 
Là je crois que tu tombes dans la volonté de voulkoir unifier avec 
BANO, mais même la base adresse source du cadastre (ou d'autres 
services) ne fait pas une telle réservation et stocke des adresses 
pour d'autre choses que les seules personnes physiques (et OSM n'est 
pas réservé non plus à la géolocalisation des seules personnes physiques).


On ferait la même remarique pour une bpite à lettres, une cabine 
téléphonique, un container de recyclage, une armoire technique de rue, 
un transformateur électrique, une bouche d'égout, une antenne mobile. 
Si cela est utile je ne vois pas pourquoi on ne pourrait pas utiliser 
addr:* et/ou contact:*, même s'il n'y a aucun courrier qui peut 
arriver à ces adresses. OSM n'est pas réservé aux utilisations postales.


Le 22 janvier 2016 à 11:45, Christian Quest > a écrit :


addr:* n'a rien à faire sur un défibrillateur... ni même contact:*



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