Re: [OSM-talk-fr] Liste des outils d'OSM FR

2018-01-07 Par sujet sly (sylvain letuffe)
Vincent Frison wrote
>> Tu ne connais pas http://openstreetmap.fr/outils
> 
> Ba voila c'est exactement la page que j'imaginais !

Le problème c'est que sa dernière mise à jour date de 2013 et que plusieurs
outils ne sont plus opérationnels depuis. 
Au final, la plus à jour, et que toute personne avec un compte sur le wiki
d'osm.org peut aider à compléter/corriger c'est là :
https://wiki.openstreetmap.org/wiki/FR:Serveurs_OpenStreetMap_France#Liste_des_services_web_sur_le_domaine_openstreetmap.fr





-
-- 
sly, contact direct : sylvain /a\ letuffe o r g
http://wiki.openstreetmap.org/wiki/User:Sletuffe
--
Sent from: http://gis.19327.n8.nabble.com/France-f5380434.html

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


Re: [OSM-talk-fr] highway=path + bicycle=yes

2017-12-15 Par sujet sly (sylvain letuffe)
Marc a dit correctement ce que sont les règles actuelles du tagging :
bicycle=yes c'est une autorisation.


Simon Réau wrote
> Je me pose la question de la pertinence du bicycle=yes
> (...)
> Pour le calcule d'itinéraire chez Géovélo cela nous pose un problème 

L'utilisation modèle le tagging, si vous tentez d'interpréter un tag pour ce
qu'il n'est pas, vous allez créer de la distorsion chez les contributeurs
qui utilisent géovélo : ils risquent de mettre ou enlever des bicycle=yes
pour corriger votre routeur tandis que d'autres les enlèverons pour
appliquer le wiki.
Profitez de votre notoriété pour éduquez et indiquer les bons tags à
utiliser pour marquer qu'un vélo de course ne passe pas alors qu'un vtt y
passe.

La bonne solution alors me semble être d'ignorer des bicycle=yes sur des
highway=path 




-
-- 
sly, contact direct : sylvain /a\ letuffe o r g
http://wiki.openstreetmap.org/wiki/User:Sletuffe
--
Sent from: http://gis.19327.n8.nabble.com/France-f5380434.html

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


Re: [OSM-talk-fr] Abri en pierres sèches

2017-11-28 Par sujet sly (sylvain letuffe)
Patrice Krupka wrote
> mais à l'envoi des modifications osm avertit que shelter_type est
> utilisé sans amenity=shelter.

La page du wiki https://wiki.openstreetmap.org/wiki/Key:shelter_type qui
décrit l'usage du tag "shelter_type" dit que c'est un complément de
amenity=shelter mais rien n'indique qu'il peut accompagner historic=shelter
qui d'ailleurs n'est pas documenté

Je vois donc deux choix valables : 
- ajouter amenity=shelter
ou
- enlever shelter_type=basic_hut

(le 3ème étant de lancer une consultation pour voir si
shelter_type=basic_hut pourrait accompagner un tag qui indique une chose qui
fût mais qui n'est plus mais si on trouve rien de mieux !)


Patrice Krupka wrote
> Avez-vous un conseil sur la meilleur façon de faire ?

Je dirais que ça va dépendre de la "cazelle" concernée. (object que je ne
connais pas par chez moi)

* amenity=shelter : je le mettrais si elle est utilisable comme abri contre
vent et pluie, qu'il est autorisé d'y rentrer
* shelter_type=basic_hut en revanche, c'est pour ça :
https://wiki.openstreetmap.org/wiki/Tag:shelter_type%3Dbasic_hut
Pour y avoir "droit" Il faut donc que la cazelle dispose :
- d'emplacements prévus et adaptés pour dormir
("adapté" ne voulant pas dire "possible" : dans une grotte on peut dormir, à
la belle étoile on peu dormir, mais là, il faut une volonté, toujours
actuelle, d'en permettre le dormage)
- soit entièremt sellé (en gros qu'une isolation thermique non négligeable
soit fournie)

* historic=yes si elle est d'intérêt historique : oui c'est subjectif, à
l’appréciation du mappeur

Pour l'option du historic=shelter, je ne suis pas sûr avec la longue page
wikipedia d'avoir bien compris l'usage ancestrale :
Avant, sa vocation était d'être un abri ouvert à tous ?
Ou c'était plutôt un outil de travail pour bergers qu'il ne valait mieux pas
squatter sous peine de se faire dégager ?

historic=shelter évoque pour moi le fait qu'il s'agissait avant d'un
amenity=shelter (un abri public) ayant perdu sa fonction de nos jours.





-
-- 
sly, contact direct : sylvain /a\ letuffe o r g
http://wiki.openstreetmap.org/wiki/User:Sletuffe
--
Sent from: http://gis.19327.n8.nabble.com/France-f5380434.html

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


Re: [OSM-talk-fr] Stats serveurs de tuiles OSM-FR...

2017-11-20 Par sujet sly (sylvain letuffe)
Il est très sexy ce goaccess, mais si on gratte, il manque quand même
quelques trucs bien utiles (c'est p'tet un truc qui s'active) :

Dans les referers il annonce "www.free.fr" en 14ème place mais fouiller tout
leur site pour trouver à quelle page ils s'en servent, c'est pas aisé !
( Referrers URLs: If the host in question accessed the site via another
resource, or was linked/diverted to you from another host, the URL they were
referred from will be provided in this panel. See `--ignore-panel` in your
configuration file to enable it. (disabled by default) )

Y'a un truc pour changer la période d'analyse ?
Là on a 31/Dec/2016 — 20/Nov/2017
Mais si je veux savoir comment a évolué la provenance des internautes entre
décembre 2016 et décembre 2017 ?






-
-- 
sly, contact direct : sylvain /a\ letuffe o r g
http://wiki.openstreetmap.org/wiki/User:Sletuffe
--
Sent from: http://gis.19327.n8.nabble.com/France-f5380434.html

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


Re: [OSM-talk-fr] Marquage et jalonnement en randonnée

2017-11-20 Par sujet sly (sylvain letuffe)
Nicolas Dumoulin-2 wrote
> Quelques exemples ici :

Et ben mon vieux ! Tu nous illustres le fait de tagguer "name" sur les
panneaux de rando et on a un contre jour, un flou, et un arraché.
Pas évident de juger de la pertinence du "name" sur tes exemples :-)
Mais je suppose que ceux qui participent au débat ici on bien en tête ce
qu'est un panneaux de rando avec un nom indiqué dessus.


Nicolas Dumoulin-2 wrote
> En effet, il s'agit ici du nom du "nœud" dans le réseau de randonnée.
> (...)
> (Exemple avec) le nom des gares ou des arrêts de bus reprenant les
> toponyme.

Je n'avais pas pensé à cette manière de voir les panneaux de rando comme "un
réseau interconnecté".
Dans cette optique là, en effet, un panneaux pourrait avoir un nom du "point
du réseau" même s'il est éventuellement identique à celui du truc réél non
loin.
Ainsi, comme pour les lignes de Bus/métro/.., lorsque l'on considère
l'ensemble des arrêts d'une ligne, au sein de cette ligne, chacun à un nom.
Mouais.
Je pourrais me laisser convaincre par cette argumentation, si ce n'est que
je n'ai pas l'impression, quand je fais mes rando de voir "des lignes ou
réseau de panneaux".
Il m'arrive de croiser des "bout de carte" qui décrivent des randos
suggérées (des itinéraires quoi), mais je doute que tous les panneaux y
figurent, et j'ai plus l'impression qu'on me pointe les éléments du terrains
plutôt que des panneaux de repérage.


Nicolas Dumoulin-2 wrote
> Par rapport à l'exemple du col, dont on ne préciserait pas le nom car un 
> poteau avec le nom du col existe déjà : j'ai un peu envie de dire que 
> c'est la faute du rendu ou de l'outil. Si on affiche "panneau indicateur 
> 'col truc'", ça lève un peu l'ambiguïté. 

Comme je disais, je pense que les outils d'usage finiront par ignorer les
name des panneaux pour éviter la confusion et les doublons, donc ce
désagrément devrait être réduit. Par contre, les outils d'édition eux ont
pour rôle de montrer ce qui est dans la base, donc ils devaient logiquement
continuer à indiquer "col truc" sur le panneau et, j'en ai peur, dissuader
de l'ajouter.
D'où ma dernière suggestion sur le wiki, de bien indiquer que le nom sur le
panneaux ne remplace pas le nom sur le point réél, et espérer que les
éditeurs auront une démarche visant à réduire les risques d'oubli
("panneau du col truc", "icône en gros", "texte en petit", que sais-je
d'autre comme bonne idée)




-
-- 
sly, contact direct : sylvain /a\ letuffe o r g
http://wiki.openstreetmap.org/wiki/User:Sletuffe
--
Sent from: http://gis.19327.n8.nabble.com/France-f5380434.html

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


Re: [OSM-talk-fr] Importation des arbres municipaux de Grenoble

2017-11-17 Par sujet sly (sylvain letuffe)
Vincent Frison wrote
> Le voici donc, valide pendant un mois: https://files.fm/u/shq299cz

J'ai fais de nombreux sondages aléatoires à l'aide des photos aériennes
récentes et ça à l'air de la bonne qualité, très cohérent avec l'existant,
et sans doublons trouvés.
Je ne passe toutefois pas assez souvent sur Grenoble pour tenter une vérif
"in situ".

L'algo a donc l'air de bien bosser en plus d'une donnée source de bonne
qualité, c'est tout bon !

Note: Il semble qu'un double encodage UTF-8 se soit glissé dans
l'incorporation des genus/species 
Fichier genfile-for-creation.osm ligne 1670 par exemple :
   

  






-
-- 
sly, contact direct : sylvain /a\ letuffe o r g
http://wiki.openstreetmap.org/wiki/User:Sletuffe
--
Sent from: http://gis.19327.n8.nabble.com/France-f5380434.html

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


Re: [OSM-talk-fr] Importation des arbres municipaux de Grenoble

2017-11-16 Par sujet sly (sylvain letuffe)
Si tu as déjà fait l'outil, ça serait bien de fournir si c'est possible le
fichier osm résultant, plusieurs personnes, et surtout ceux de grenoble
pourront ainsi faire un sondage sur quelques arbres et juger de la qualité
du fichier d'origine et du process.

J'ai grand grand peur que des arbres puissent atterrir dans un bâtiment
privé, sur une route, dans une fontaine, etc.

Et je sais qu'il est tentant de dire : c'est les autres qui ont mal
positionné leur fontaine/batiment/etc. mais osm n'est pas une base ou on
empile des datas opensource, la cohérence relative des éléments les uns par
rapport aux autres me semble préférable en étant décalé de 5m qu'un arbre
sur un toit.
Ou alors, la tâche d'importation est manuelle, un par un et s'occupe de
vérifier qui à tort qui a raison et consiste à recaller les éléments autour.



-
-- 
sly, contact direct : sylvain /a\ letuffe o r g
http://wiki.openstreetmap.org/wiki/User:Sletuffe
--
Sent from: http://gis.19327.n8.nabble.com/France-f5380434.html

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


Re: [OSM-talk-fr] Marquage et jalonnement en randonnée

2017-11-16 Par sujet sly (sylvain letuffe)
Pour le rendu qui peut évoluer, ça, j'ai peur que ça soit : ne plus afficher
les name des panneaux !
Et c'est pas une erreur du rendu vu que ce qui est écrit sur le panneau
c'est le nom du col non loin, pas le nom du panneau.


emeric Prouteau wrote
> Par contre ne pas les indiquer serrait à mon avis dommage car si on
> indique
> des relations de type direction_sign pour un éventuel futur outil de
> routing de rando, le nom d'un bois (Décrivant le bois) identique au nom
> d'un poteau serait moins précis que le poteau qui correspond lui à une
> distance précise par rapport à un autre poteau.

J'entrevois l'idée derrière qui consisterait à réduire le bois, le lac, bref
une surface à un point afin d'avoir des temps de marche plus précis depuis
le précédent panneau, mais je vois bien l'embrouille qui peut naître du cas
suivant : Si ton bois est assez large (disons qu'il faut 30mn pour le
traverser) y'a de grande chance qu'on trouve des panneaux à chaque entrée du
bois. 

A--15mn-Bois--30mn---Bois--15mn--B

Depuis B il faut 15mn pour aller au bois, depuis A 15mn aussi, mais pour
faire A->B il faudra 1h.
Bref, derrière cette louable idée d'aider un "routeur de rando" j'ai peur
que tant qu'on l'a pas codé, on ne crééer une distorsion de la réalité qui
au contraire embrouille l'usage qui peut en être fait. Surtout quand le
panneau commence à se situer de plus en plus loin de l'objet qu'il indique.

Bon, si encore ça ne restait qu'une donnée morte, on pourrait tenter le coup
et attendre que quelqu'un s'en serve, mais j'ai plusieurs exemple ou le name
est mis sur le panneau par le contributeur, et, pensant qu'il a fait le
nécessaire, ne l'ajoute pas sur l'objet indiqué.
Ou constate qu'un panneau avec ce nom existe déjà dans OSM ne saisi pas le
col, le sommet, le bois.

Bref, je reste pour l'instant sur l'idée que ça fait plus de mal que de
bien. 




-
-- 
sly, contact direct : sylvain /a\ letuffe o r g
http://wiki.openstreetmap.org/wiki/User:Sletuffe
--
Sent from: http://gis.19327.n8.nabble.com/France-f5380434.html

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


Re: [OSM-talk-fr] Marquage et jalonnement en randonnée

2017-11-16 Par sujet sly (sylvain letuffe)
marc marc wrote
> A l'entrée d'une ville, un panneau indiquant le nom de la ville se tag 
> ainsi :
> traffic_sign=city_limit
> name="la ville"

Quelle drôle d'idée je trouve...
Sur le wiki en tout cas :
https://wiki.openstreetmap.org/wiki/Key:traffic_sign
name n'est nulle part suggéré.

Cette histoire d'utiliser la clé name=x pour le panneau qui indique quelque
chose en rapport à x me semble appeler à des problèmes d'interprétation des
données.
Je verrais quand même mieux ça dans le tag description ou content.
Va-t-on avoir un name: sur chaque panneaux d'entrée de ville ?

Bon, je m'inquiète pas trop pour l'usage, pour éviter doublons triplons et +
les utilisateurs auront leur liste blanche d'objet qui ont un name pertinent
et les panneaux n'en feront pas partie mais n'embrouille-t-on pas le
contributeur qui en fini par perdre son temps ?





-
-- 
sly, contact direct : sylvain /a\ letuffe o r g
http://wiki.openstreetmap.org/wiki/User:Sletuffe
--
Sent from: http://gis.19327.n8.nabble.com/France-f5380434.html

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


Re: [OSM-talk-fr] Marquage et jalonnement en randonnée

2017-11-15 Par sujet sly (sylvain letuffe)
emeric Prouteau wrote
> J'a relevé lors de mes randonnées de nombreux poteaux indicateurs avec un
> nom

Une parenthèse en passant : A mon avis, c'est une mauvaise idée que de
mettre le nom indiqué sur le poteaux sur le noeud information=guidepost
J'ai détaillé mon opinion ici :
https://wiki.openstreetmap.org/wiki/Talk:Tag:information%3Dguidepost#a_guidepost.27s_name_.3F


emeric Prouteau wrote
> Je pensais enlever le nom qui pour moi n'en ai pas un et plutôt le mettre
> dans 'observation'. Est ce bon ?

Quand tu parles de "jalon" tu veux dire un marquage de couleur sur une
pierre, un tronc, ou autre élément naturel ?
Ou sur un piquet artificiel de type
https://wiki.openstreetmap.org/wiki/File:Marked_trail_pole.jpeg
Si cas 1, hé bé, faut vraiment être sacrément motivé pour tagguer ça car
j'ai un peu peur de leur pérennité. Rien ne dit qu'après 5 années de pluie
il soit replacé sur le même cailloux !
Quoi qu'il en soit, oui, dans le nom ça ne va pas.
"observation" je ne connais pas ce tag, description (ce que tu as fais
semble aller)


emeric Prouteau wrote
> De plus, y-a t-il un tag pour différentier un poteau physique avec des
> directions et le jalonnement de type peinture.

Si on parle bien d'un truc comme ça :
https://www.altituderando.com/IMG/jpg/8/b/a/P1060873_Copie1200x900_.jpg
Selon moi, ça ne devrait pas être targué avec information=guidepost

Un guidepost c'est, d'après le wiki "to indicate the directions to different
destinations" donc selon moi il faut a minima que ça indique une direction à
prendre, d'une façon ou d'une autre (genre une fleche ou une orientation du
panneau)

Genre celui là :
https://wiki.openstreetmap.org/wiki/File:Tree_mounted_guidepost.jpeg
Est le stricte minimum pour être qualifié de "guidepost"

Même celui-là :
https://wiki.openstreetmap.org/wiki/File:Simple_guidepost.jpg
que j'ai taggué pendant un temps comme guidepost, maintenant j'hésite.



-
-- 
sly, contact direct : sylvain /a\ letuffe o r g
http://wiki.openstreetmap.org/wiki/User:Sletuffe
--
Sent from: http://gis.19327.n8.nabble.com/France-f5380434.html

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


Re: [OSM-talk-fr] requête Overpass en ligne de commande

2017-09-11 Par sujet sly (sylvain letuffe)
Samy Mezani wrote
> Je teste en ce moment même avec ogr2ogr (qui me renvoie des erreurs de 
> segmentation sur Debian...)

Par curiosité, j'ai voulu essayer et ça à l'air de presque quasiment le
faire avec ogr2ogr :
http://sly.letuffe.org/echange/old-bourgogne.zip

Sur une debian 8
$ ogr2ogr --version
GDAL 1.10.1, released 2013/08/26

$ ogr2ogr -overwrite -f "ESRI Shapefile" test.shp test.osm -sql 'select *
from multipolygons'

ça s'ouvre nikel avec Qgis, mais le seul soucis qui semble  (semble car je
ne suis pas expert Qgis) rester ce sont les 2 communes au Sud Est qui
appartiennent à la région voisine, qui sont donc des enclaves appartenant à
la région d'a coté et qui devrait alors être des "trous" de la ex-région
bourgogne mais qui ne semble pas être traité comme des trous.
Peut-être une "non fonctionnalité" de ce driver ogr2ogr qui ne gère pas les
role inner
https://wiki.openstreetmap.org/wiki/Relation:multipolygon#One_outer_and_one_inner_ring






-
-- 
sly, contact direct : sylvain /a\ letuffe o r g
http://wiki.openstreetmap.org/wiki/User:Sletuffe
--
Sent from: http://gis.19327.n8.nabble.com/France-f5380434.html

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


Re: [OSM-talk-fr] requête Overpass en ligne de commande

2017-09-11 Par sujet sly (sylvain letuffe)
Samy Mezani wrote
> Je veux simplement obtenir le multipolygone de son ancien contour.

A mon avis, le problème qui fait que tu n'obtiens pas les réponses que tu
attends tient dans l'expression de ton besoin.
Je pense comprendre (je peux me tromper) que ce que tu veux c'est un
multipolygone au sens GIS (postgis, shapefile) du terme alors que les
réponses qui t'ont été données expliquent comment avoir un multipolygone au
sens OSM du terme :
https://wiki.openstreetmap.org/wiki/Relation:multipolygon
(c'est à dire un objet de type"relation")

Car la requête que tu as faite sur l'overpass te donne, selon la
terminologie OSM, le multipolygone de l'ancienne-Bourgogne et tous les
éléments qu'il faut pour en construire un (multi-)polygone (au sens GIS du
terme)
(Pour s'en convaincre, ajoute out meta; et ouvre le avec josm, tu verra que
tu as bien le contour)

Ce que tu cherches (peut-être) maintenant c'est un convertisseur, et
overpass ne fait pas ça.

osm2pgsql sait le faire pour importer dans postgres/postGIS
ogr2ogr semble le faire aussi :
http://www.gdal.org/drv_osm.html

Mais ça nous aider, tu veux quel format à la fin pour le traiter dans ta
chaîne "en ligne de commande" ?



-
-- 
sly, contact direct : sylvain /a\ letuffe o r g
http://wiki.openstreetmap.org/wiki/User:Sletuffe
--
Sent from: http://gis.19327.n8.nabble.com/France-f5380434.html

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


Re: [OSM-talk-fr] Sécuriser Overpass API : quelles solutions ?

2017-07-24 Par sujet sly (sylvain letuffe)
marc marc wrote
> pourrais-tu lire mon autre threat et y répondre à mes questions ?
> (...)
> on en pale sur l'autre thread ou sur la ml tech, comme tu préfères

Si je peux aider avec un retour d'expé bien sûr. Si cela concerne
particulièrement la mise en place de l'API sur l'infrastructure
openstreetmap France je suggère en effet de passer sur la ml [tech] ça sera
plus ciblé et ça pourrait aider à réduire la "dispersion" en étant moins
générique que le sujet ici.

Rodolphe (qui est intervenu sur ce sujet) est en train d'avancer la mise en
oeuvre si j'ai bien suivi. (et est inscrit sur la liste tech)

Donc oui, peux-tu reposer là bas tes questions en lien avec la mise en
oeuvre de l'api Overpass maintenu par l'association fr ?

--
sly



-
-- 
sly, contact direct : sylvain /a\ letuffe o r g
http://wiki.openstreetmap.org/wiki/User:Sletuffe
--
View this message in context: 
http://gis.19327.n8.nabble.com/Securiser-Overpass-API-quelles-solutions-tp5899532p5899687.html
Sent from the France mailing list archive at Nabble.com.

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


Re: [OSM-talk-fr] Sécuriser Overpass API : quelles solutions ?

2017-07-23 Par sujet sly (sylvain letuffe)
overflorian wrote
> Est-ce que vous sauriez à quoi cela est dû ? 

Cette page liste l'historique des problèmes rencontrés  par les 2 instances
"principales" :
https://wiki.openstreetmap.org/wiki/Overpass_API/status


overflorian wrote
> Quelles en sont les causes profondes ?

Je pense que ça se résume simplement :
- Trop de gens tirent dessus et trop peu de gens installent d'instances
publiques (pour répartir la charge, offrir une possibilité de redondance) ou
participent à la maintenance.

Comme on peut le voir d'un coup d'oeil sur :
https://wiki.openstreetmap.org/wiki/Overpass_API#Introduction

Il n'y a plus que 2 instances fonctionnelles dont une seule avec des disques
SSD


overflorian wrote
> Y aurait-il une solution que nous pourrions mettre en place pour venir en
> soutien à nos amis les teutons qui gèrent le bouzin ?

Le meilleur endroit pour cette question est sans doute la liste dédiée à
l'overpass

Mon avis, c'est qu'avant toutes les suggestions que j'ai lu ici sur des
proxy, des ha, des redondances dns, des caches il faut des instances
supplémentaires à la base pour répartir la charge. (que ça soit une charge
de ressources, ou une charge de travail)
Ensuite, des conseils ou documentations mieux écrites décrivant les bonnes
pratiques d'usage pour réduire les usages "excessif" (j'ai vu de bonnes
suggestions de surtout éviter le cron toutes les minutes qui bourrine des
requêtes qui prennent 10 secondes !)


overflorian wrote
> Est-ce plutôt un besoin de dev ou d’hébergement ?

Pas de dév, l'outil est très bien déjà. Mais d'administrateurs
système/applicatif pour entretenir d'autres instances qui permettrait de
pérenniser et d'envisager des outils ou code pour de la redondance.
Puis ensuite, de l'hébergement, ces p'tits outils là ne tournent pas sur une
dédibox à 5 € /mois

Évidement, de l'argent pourrait aussi régler les 2 problèmes d'avant, mais
on trouve peu de mécène volontaires pour filer ~300 €/mois afin de fournir
un service gratuit...


overflorian wrote
> Bref, on résout le problème ? ;)

Le dire ne suffit pas, mais pour ceux qui veulent se retrousser les manches,
a mon avis, un bon point de départ c'est d'aider à la remise en service de
l'instance fr (détails ici) :
https://listes.openstreetmap.fr/wws/arc/tech/2017-05/msg0.html
https://listes.openstreetmap.fr/wws/arc/tech/2017-06/msg0.html

Pour avoir géré cette API pendant ~5 ans seul, je peux dire qu'on est pas
trop de plusieurs admin pour la surveiller, les raisons que ça plante ne
manquent pas !




-
-- 
sly, contact direct : sylvain /a\ letuffe o r g
http://wiki.openstreetmap.org/wiki/User:Sletuffe
--
View this message in context: 
http://gis.19327.n8.nabble.com/Securiser-Overpass-API-quelles-solutions-tp5899532p5899663.html
Sent from the France mailing list archive at Nabble.com.

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


Re: [OSM-talk-fr] Sécuriser Overpass API : quelles solutions ?

2017-07-23 Par sujet sly (sylvain letuffe)
marc marc wrote
> Je sais pas s'il y a une liste entre sysadmin d'overpass api ?

Oui, y'a, et c'est indiqué sur la page principale de documentation de
l'Overpass API au chapitre 3 :
https://wiki.openstreetmap.org/wiki/Overpass_API

C'est une liste de diffusion hébergée par l'association Openstreetmap
France.





-
-- 
sly, contact direct : sylvain /a\ letuffe o r g
http://wiki.openstreetmap.org/wiki/User:Sletuffe
--
View this message in context: 
http://gis.19327.n8.nabble.com/Securiser-Overpass-API-quelles-solutions-tp5899532p5899661.html
Sent from the France mailing list archive at Nabble.com.

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


Re: [OSM-talk-fr] Comment bien tagguer les cabinets médicaux ?

2017-05-12 Par sujet sly (sylvain letuffe)
Salut,


cquest wrote
> Les médecins ou avocats (et quelques autres professions), sont réglementés
> et n'ont pas la possibilité de faire de publicité.

Pour savoir si c'est autorisé, le mieux c'est de s'en référer aux organismes
qui édictent les règles pour ces professions réglementées.
Pour les médecins, le Conseil national de l'Ordre des médecins semble le bon
endroit pour chercher.
Article 80 :
https://www.conseil-national.medecin.fr/article/article-80-libelle-des-annuaires-304
**
Les seules indications qu'un médecin est autorisé à faire figurer dans les
annuaires à usage du public, quel qu'en soit le support, sont :

1°) ses nom, prénoms, adresse professionnelle, numéros de téléphone et de
télécopie, jours et heures de consultations ;
2°) sa situation vis-à-vis des organismes d'assurance-maladie ;
3°) la qualification qui lui aura été reconnue conformément au règlement de
qualification, les diplômes d'études spécialisées complémentaires et les
capacités dont il est titulaire.
**

De ce que je comprend, c'est autorisé. Avec son nom et son prénom.


cquest wrote
> OSM n'étant pas un annuaire

Je crois donc que la question est principalement là :
OSM peut-il et a-t-il vocation à devenir un annuaire ?
J'ai envie de dire qu'avec tous les magasins référencé avec
contact:phone/email/adresse/website/... et rangé par catégories (tag) c'est
déjà le cas dans les faits (y'a qu'a se rappeler des pros qui commencent à
remplir la base de ça !).
Est-ce bien, je ne sais pas.
D'un coté OSM ajoute la localisation, c'est là sa force. D'un autre, oui, ça
existe déjà ailleurs (en libre pour les médecins disait christian), et ça va
être dur de maintenir à jour. 

Perso, ça ne me choque pas de voir OSM devenir un annuaire géolocalisé en
plus d'une base géo (qui donc dit avec certitude que osm n'ai pas/ne devrait
pas être un annuaire ?). 
Maintenant si dans le cas des professions de santé, c'est pas à jour, c'est
mieux et libre ailleurs, peut-être faut il écrire quelque part et donner la
source. Mais ça ne justifie, il ne me semble pas, de crier haro sur ceux qui
en font la saisie. OSM, ce me semble, ça a toujours été : si tu en vois
l'intérêt et que l'outil le permet, saisie le !

Corollaire : je m'opposerais (pas la discussion) aux actions de ceux qui,
décidant que ça ne doit pas y être, le supprime de la base pendant que
d'autres le mettent.





-
-- 
sly, contact direct : sylvain /a\ letuffe o r g
http://wiki.openstreetmap.org/wiki/User:Sletuffe
--
View this message in context: 
http://gis.19327.n8.nabble.com/Comment-bien-tagguer-les-cabinets-medicaux-tp5896325p5896659.html
Sent from the France mailing list archive at Nabble.com.

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


Re: [OSM-talk-fr] Sly démissionne du Data Working Group (DWG)

2017-02-02 Par sujet sly (sylvain letuffe)
Vincent de Château-Thierry-2 wrote
> Et pour aiguiller les postulants, est-ce que tu saurais quantifier le
> temps consacré à cette gestion, par semaine ou mois, d'après ton
> expérience ?

Difficile de répondre tant cela peut varier selon le degré d'implication, si
je prends mon cas sur la fin, je ne n'y passais peut être plus que 30
minutes par semaine à lire les plaintes pour voir si cela concernait la
France, mais c'était parce que je ne pouvais/voulais plus trop m'impliquer
et qu'en réalité ça devenait finalement contre productif car les autres du
groupes ne savait plus si j'allais ou non m'occuper de tel ou tel ticket.
Je dirais donc que 1h par semaine est un minimum pour se tenir au courant de
comment son traités les autres cas par les autres membres (le but étant
d'avoir une réponse assez cohérente entre membres pour un type de problème
donné)
et sans doute 1 à 2h de plus à y consacrer pour discuter, expliquer,
diplomatiser, argumenter avec le contributeur dont un autre se plains.
Car autant les effacements violents de type vandalisme pur sont assez simple
à détecter et discuter autant parfois certains edits sont "border line" et
la discussion peu durer avant de trouver un accord.


J'ajoute qu'avoir une bonne connaissance d'osm en général, savoir faire des
revert mais surtout savoir discuter, expliquer, tempérer et garder son calme
en toutes situations (surtout quand le mec ne veut rien entendre et
t'insulte avec véhémence !)  sont nécessaires



-
-- 
sly, contact direct : sylvain /a\ letuffe o r g
http://wiki.openstreetmap.org/wiki/User:Sletuffe
--
View this message in context: 
http://gis.19327.n8.nabble.com/Sly-demissionne-du-Data-Working-Group-DWG-tp5890423p5890430.html
Sent from the France mailing list archive at Nabble.com.

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


[OSM-talk-fr] Sly démissionne du Data Working Group (DWG)

2017-02-02 Par sujet sly (sylvain letuffe)
Bonjour à la liste talk-fr que je ne fréquente que sporadiquement,

En novembre 2012 : 
https://lists.openstreetmap.org/pipermail/talk-fr/2012-November/051204.html
je devenais membre du DWG (
https://wiki.openstreetmap.org/wiki/Data_working_group )
L'objectif était d'avoir une représentation française au sein de ce groupe
car il y avait eu quelques petites tentions à l'époque concernant l'import
du cadastre et que leur petite équipe à l'époque avait déjà pas mal de
remontée de problèmes à gérer et le cas des français leur rajoutait du
travail sans leur en retirer.

Je viens de démissionner de ce groupe principalement parce que je n'ai plus
assez de temps à y consacrer et je tenais à en informer la communauté fr sur
la liste puisque c'est là que le débat avait eu lieu pour présenter un
membre de notre communauté pour "faire le lien".

En mini compte rendu, tout c'est bien passé durant ces 4 ans et le nombre de
cas à problème remontés pour la france a bien diminué, ce qui n'est hélas
pas le cas des autres régions du monde. De sorte que ma présence "pour gérer
les cas en France" fût de moindre importance au fil du temps.
J'en profite donc pour indique que le DWG est toujours à l'écoute de
candidatures pour aider à traiterdes cas de vandalisme, guerre d'éditions et
médiation partout dans le monde et que si l'un d'entre vous souhaites avoir
des précisions sur son fonctionnement, par exemple avant d'envoyer sa
candidature pour filer un coup de main, il peut m'en demander plus sur ce
fil de discussion ou en privé.

--
sly
sylvain à letuffe.org








-
-- 
sly, contact direct : sylvain /a\ letuffe o r g
http://wiki.openstreetmap.org/wiki/User:Sletuffe
--
View this message in context: 
http://gis.19327.n8.nabble.com/Sly-demissionne-du-Data-Working-Group-DWG-tp5890423.html
Sent from the France mailing list archive at Nabble.com.

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


Re: [OSM-talk-fr] Itinéraires et balisages FFRP et Club Vosgien

2017-01-22 Par sujet sly (sylvain letuffe)
David Marchal wrote
> Afin de ne pas faire les choses dans mon coin, je pensais faire un
> brouillon de courrier que je publierai sur Github, afin de vous permettre
> à tous d’y proposer des modifications, 

Puis-je suggérer le wiki.openstreetmap.org ? cela permettra à plus de monde
à mon avis d'y participer (pas besoin de compte github qui fait d'ailleurs
un peu "tech") pour ceux ayant déjà un compte sur le wiki et non sur github.

Je retrouve d'ailleurs la page :
https://wiki.openstreetmap.org/wiki/Ffrp-lettre-ouverte
que j'avais créée en 2012 et qui ressemble pas mal à l'idée que tu as (et
qui résumait jusqu'en ~2013 ou nous en étions, les liens, les tentatives,
les non réponses, etc.)
Peut-être peut on partir de cette page pour lister toutes les initiatives et
faire un lien vers la lettre que tu vas écrire ?

Je soutiens évidement à donf l'initiative et m'impliquerait volontiers pour
relecture et participation sous toute formes.

Si Christian a en entretient la semaine prochaine, ça ne coûte rien
d'attendre 7 jours de plus pour lui demander ce que ça à donner et entendre
un "rien n'a avancé depuis 10 ans" ;-)
Je donne l'impression d'être mauvaise langue mais j'ai une sensation de déjà
vu, en 2012 quand on a voulu écrire une lettre, on a entendu du : "à mais on
va avoir un rdv avec eux, ça a de grande chance d'avancer" et puis ça à
parlé de tout mais les personnes de la FFRP ont systématiquement botté en
touche ce genre de demandent dans un plus pur style "noyade de poisson"

En clair, je soutiens encore plus ton initiative et ne pas se laisser
intoxiquer par des "attendez, on va en discuter en commité machin qui aura
lieu dans 3 mois"




-
-- 
sly, contact direct : sylvain /a\ letuffe o r g
http://wiki.openstreetmap.org/wiki/User:Sletuffe
--
View this message in context: 
http://gis.19327.n8.nabble.com/Itineraires-et-balisages-FFRP-et-Club-Vosgien-tp5889754p5889783.html
Sent from the France mailing list archive at Nabble.com.

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


Re: [OSM-talk-fr] problème avec http://api.openstreetmap.fr/oapi/

2016-07-02 Par sujet sly (sylvain letuffe)
Jean-Marc Liotier wrote
> Hier après-midi le retard de réplication est reparti à la hausse... Un 
> incident ?

On dirait bien. Le processus des mise à jour semble avoir planté mais je
n'ai pas d'info sur la cause. Je l'ai relancé et ça semble reparti. Mais si
ça se reproduit souvent ça va être galère...


Jean-Marc Liotier wrote
> La seule anomalie évidente sur les graphiques est l'envolée du nombre de 
> threads: 
> http://munin.openstreetmap.fr/osm11.free.org/osm103.openstreetmap.fr/threads.html

Et le nombre d'appels a cette api (les 2 sont sans doute liés). 

Un logiciel pour smartphone :
https://play.google.com/store/apps/details?id=com.pluscubed.velociraptor&hl=fr
semble utiliser api.openstreetmap.fr pour sa détection de radar, et
visiblement, c'est très utilisé car ça fait un nombre assez impressionnant
d'appels.
Je ne sais pas si c'est lié ou pas au problème de mise à jour, mais c'est
clairement trop agressif comme usage, en plus j'avais déjà eu le cas par le
passé pour le même soft. Bon, je tente à nouveau de bannir ce genre de
requêtes.


Jean-Marc Liotier wrote
> Sinon, en temps normal, quel est le goulet d'étranglement de la 
> réplication ?

Je n'ai pas fais de tests assez poussés pour le savoir. Il se pourrait que
ça soit le CPU, mais je n'ai pas de certitudes.





-
-- 
sly, contact direct : sylvain /a\ letuffe o r g
http://wiki.openstreetmap.org/wiki/User:Sletuffe
--
View this message in context: 
http://gis.19327.n5.nabble.com/probleme-avec-http-api-openstreetmap-fr-oapi-tp5876348p5877087.html
Sent from the France mailing list archive at Nabble.com.

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


Re: [OSM-talk-fr] problème avec http://api.openstreetmap.fr/oapi/

2016-06-29 Par sujet sly (sylvain letuffe)
Jean-Marc Liotier wrote
> Ca concerne aussi https://api.openstreetmap.fr/api ?

En effet, même base sous-jaccente.


Jean-Marc Liotier wrote
> Elles ne sont plus rafraîchies ?

Elles ne sont plus synchro, mais les mises à jour sont en cours :
http://munin.openstreetmap.fr/osm11.free.org/osm103.openstreetmap.fr/osm_replication_lag_api.html

Cette base devrait à nouveau être à jours d'ici 2/3 jours



-
-- 
sly, contact direct : sylvain /a\ letuffe o r g
http://wiki.openstreetmap.org/wiki/User:Sletuffe
--
View this message in context: 
http://gis.19327.n5.nabble.com/probleme-avec-http-api-openstreetmap-fr-oapi-tp5876348p5876792.html
Sent from the France mailing list archive at Nabble.com.

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


Re: [OSM-talk-fr] problème avec http://api.openstreetmap.fr/oapi/

2016-06-26 Par sujet sly (sylvain letuffe)
Jérôme Amagat wrote
> il me semble qu'il y a un problème avec l'overpass api français. je
> n'arrive pas a avoir les données complète avec out meta il manque version,
> timestamp ... comme un out body.

Je confirme. Une erreur lors de l'import de la semaine dernière, je relance
l'import avec les options meta.

ps: je ne suis pas assez souvent cette liste, pour l'overpass fr, ça gagne
du temps de décrire le problème sur 
http://trac.openstreetmap.fr/newticket?component=api-fr si possible
Ou sur http://wiki.openstreetmap.org/wiki/Talk:Servers/api.openstreetmap.fr




-
-- 
sly, contact direct : sylvain /a\ letuffe o r g
http://wiki.openstreetmap.org/wiki/User:Sletuffe
--
View this message in context: 
http://gis.19327.n5.nabble.com/probleme-avec-http-api-openstreetmap-fr-oapi-tp5876348p5876505.html
Sent from the France mailing list archive at Nabble.com.

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


Re: [OSM-talk-fr] Gros problème qualité de la part d'un contributeur

2016-06-26 Par sujet sly (sylvain letuffe)
Eric Sibert wrote
>> Je n'ai pas eu de réponses de Sylvain pour l'instant.
> 
> Essaie aussi d'envoyer un message à l'adresse générique du DWG en 
> expliquant que ce gars est en train d'endommager sérieusement l'existant 
> (et ne répond pas aux sollicitations).

Tout à fait, si c'est pressant car le contributeur continue à faire des
modifications et n'a pas marqué de pause, il y a urgence et plus on
intervient vite et qu'on discute et moins il sera dur de réparer. Donc un
mail à d...@osmfondation.org et si je suis dispo (ou pas !) quelqu'un
prendra en charge plus rapidement.
Si c'est moins pressant, pas de problème de me prévenir en direct mais à la
limite, pour ne pas se poser de question de qui prévenir, c'est plus simple
d'envoyer à l'email du dwg. D'autres parlent également français, et la gêne
reste mineure si c'est moi qui prend en charge.

Donc, pour le cas qui nous occupe, au DWG nous sommes très tolérant aux
erreurs et en général, ça ne suffit pas à 
ce que l'on bloque, mais sitôt que l'utilisateur ne répond pas (quelle que
soit la raison, problème technique, d'email pas à jour ou de non volonté de
répondre) et continue ses actions sans discuter avec les remarques faites,
là, ça 
justifie de bloquer pour qu'il prenne le temps d'une pause et surtout, qu'il
explique pourquoi il fait ça et s'il s'en rend compte. Ainsi, ça permet de
discuter, et d'analyser plus tranquillement le problème.

Donc hop :
https://www.openstreetmap.org/user_blocks/975
Ou j'invite le contributeur à nous rejoindre dans la discussion pour voir ce
que l'on peut faire.




-
-- 
sly, contact direct : sylvain /a\ letuffe o r g
http://wiki.openstreetmap.org/wiki/User:Sletuffe
--
View this message in context: 
http://gis.19327.n5.nabble.com/Gros-probleme-qualite-de-la-part-d-un-contributeur-tp5876450p5876496.html
Sent from the France mailing list archive at Nabble.com.

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


Re: [OSM-talk-fr] http://api.openstreetmap.fr/oapi hors service

2016-04-20 Par sujet sly (sylvain letuffe)
Bonjour,


mga_geo wrote
> Après quelques messages d'erreur, je n'ai plus de réponse, problème
> matériel ?

Pour plus de chance d'obtenir une réponse de ma part, les problèmes sur
l'Overpass api "france" sont à ouvrir sur le trackeur de bug :
https://trac.openstreetmap.fr/newticket
en choisissant le composant "api-fr"




-
-- 
sly, contact direct : sylvain /a\ letuffe o r g
http://wiki.openstreetmap.org/wiki/User:Sletuffe
--
View this message in context: 
http://gis.19327.n5.nabble.com/http-api-openstreetmap-fr-oapi-hors-service-tp5872102p5872196.html
Sent from the France mailing list archive at Nabble.com.

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


Re: [OSM-talk-fr] Remise en place de taginfo et live + Extinction de oapi-fr

2016-02-09 Par sujet sly (sylvain letuffe)
Jocelyn Jaubert wrote
> Là, je ne vois pas vraiment le souci. Ça reste de l'ascii standard, donc
> ça
> devrait passer avec cet encoding CP-1252 aussi.
> 
> Je ne sais pas trop comment forcer les pages d'index automatiquement
> générées
> par Apache en UTF-8. Une idée ?

Voilà qui est réparé. J'avais renommé le dossier et j'avais oublié de mettre
à jour dans la config la partie qui indique :
AddDefaultCharset utf-8





-
-- 
sly, contact direct : sylvain /a\ letuffe o r g
http://wiki.openstreetmap.org/wiki/User:Sletuffe
--
View this message in context: 
http://gis.19327.n5.nabble.com/Remise-en-place-de-taginfo-et-live-Extinction-de-oapi-fr-tp5867054p5867156.html
Sent from the France mailing list archive at Nabble.com.

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


Re: [OSM-talk-fr] Trouver le bati manquant

2016-01-10 Par sujet sly (sylvain letuffe)
Profitant de toutes ces bonnes infos, j'ai complété du mieux de ce que j'en
sais la page du wiki qui concerne l'import des bâtiments depuis le cadastre
en indiquant quelques méthodes pour gagner du temps et lister les méthodes
existantes :
http://wiki.openstreetmap.org/wiki/WikiProject_France/Cadastre/Import_semi-automatique_des_bâtiments

(4.4 Méthodes pour aider à la fusion avec l'existant / mise à jour cadastre)


StephaneP wrote
> L'une d'elles concerne le bati intégré dans Osm, et permet de facilement 
> retrouver ce qui manque en la superposant à la couche TMS du cadastre 





-
-- 
sly, contact direct : sylvain /a\ letuffe o r g
http://wiki.openstreetmap.org/wiki/User:Sletuffe
--
View this message in context: 
http://gis.19327.n5.nabble.com/Trouver-le-bati-manquant-tp5863259p5864581.html
Sent from the France mailing list archive at Nabble.com.

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


Re: [OSM-talk-fr] waterway=riverbank ou natural=water ?

2015-07-07 Par sujet sly (sylvain letuffe)
Salut,

"Erreur de tag" n'est qu'une question de point de vue ;-)

Je suis personnellement favorable au natural=water pour toutes les surfaces.


> Le mardi 7 juillet 2015, 06:49:51 Tony Emery a écrit :
> Bonjour à tous,
> 
> Lors du dernier Décryptageo, plusieurs visiteurs m'ont fait remarquer, à
> juste titre, qu'il manquait sur mon plan le tracé du Rhône.
> 
> De retour en Provence, je tente alors de recharger les données OSM dans ma
> Base de Données et, oh surprise, le Rhône n'y est toujours pas. Sauf qu'il
> n'a pas disparût d'OSM...
> 
> Donc, je regarde de plus prêt et m'aperçoit que :
> - tous les tronçons et les polygones décrivant le Rhône sont bien dans une
> relation "Rhône"
> - mais ces tronçons ont tous perdus leurs tags (sauf la source) :
> http://www.openstreetmap.org/way/231665961
> <http://www.openstreetmap.org/way/231665961>
> - que le tag de la relation "Rhône" qui le décrit comme étant un fleuve
> n'est pas waterway=riverbank mais natural=water :
> http://www.openstreetmap.org/relation/660056
> http://www.openstreetmap.org/relation/660056
> <http://www.openstreetmap.org/relation/660056>
> 
> Or, dans le wiki, il est bien indiqué qu'il ne faut pas ajouter pas
> natural=water au chemin, car cela concerne les lacs et les étendues d'eau
> sans courant.
> 
> Est ce qu'il y a eu un changement de stratégie ou ne faudrait-il pas
> corriger ces erreurs ?
> 
> 
> 
> 
> -
> Tony EMERY
> Administrateur OpenStreetMap.fr
> Mandataire Grand Sud-Est
> Géomaticien & chef de projets
> --
> View this message in context:
> http://gis.19327.n5.nabble.com/waterway-riverbank-ou-natural-water-tp584964
> 9.html Sent from the France mailing list archive at Nabble.com.
> 
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr

-- 
sly (sylvain letuffe)
http://wiki.openstreetmap.org/wiki/User:Sletuffe

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


Re: [OSM-talk-fr] Question Overpass Turbo

2015-05-04 Par sujet sly (sylvain letuffe)
Le lundi 4 mai 2015 20:55:22, Augustin Doury a écrit :
> A voir d'ici quelques jours, si quelqu'un a une explication, top.
> Bonne soirée

Pour information, l'explication en rapide ici (en anglais): 
http://wiki.openstreetmap.org/wiki/Overpass_API/status 
et en détail là : (en anglais):
https://github.com/drolbr/Overpass-API/issues/210

En rapide, aucune des modifications survenues entre 
2015-04-30 12:43  et 2015-04-30 13:36 UTC
ne sont présentes dans la base Overpass de http://overpass-api.de

Un nouveau serveur est prévu et donc l'admin attend le remplacement de 
l'actuel par le nouveau, ce qui corrigera le problème.

L'instance sur http://api.openstreetmap.fr/oapi/
a été corrigée par mes soins la nuit dernière et devrait contenir ce que 
l'autre n'a pas.

-- 
sly (sylvain letuffe)
http://wiki.openstreetmap.org/wiki/User:Sletuffe

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


Re: [OSM-talk-fr] Forum Nable

2015-04-20 Par sujet sly (sylvain letuffe)
Quand le produit est gratuit, c'est que le produit... c'est vous !

Le gros avantage d'une mailing liste, c'est que ça peut se suivre par email 
;-)

Et sinon, y'a les très sexy archives maintenues par osm :
https://lists.openstreetmap.org/pipermail/talk-fr/

On lundi 20 avril 2015, Blueberry wrote:
> Bonjour,
> 
> Je suis régulièrement les échanges de la mailing list FR via le "nabble"
> [1]. Depuis quelques temps, j’étais surpris par des fenêtres popup
> bizarres. Une fois le plugin Ghostery [2] activé dans Firefox, il affiche
> carrément 28 "mouchards" actifs sur la page (voir rapport ci dessous) !
> Beaucoup plus que tous les sites commerciaux (20mn n'en a que 6 par
> exemple). Dommage d’être si fortement pisté.
> 
> Eric [Blueberry]
> 
> Analyse Ghostery : Détecté 28 mouchards sur gis.19327.n5.nabble.com
>   AMP Platform
>   Publicité
>   AppNexus
>   Publicité
>   Audience Science
>   Balises
>   BlueKai
>   Balises
>   BrightRoll
>   Publicité, Video Player, Analytics
>   Chango
>   Balises
>   Cross Pixel Media
>   Balises, Segment Data, Analytics
>   Datalogix
>   Publicité
>   DataXu
>   Publicité
>   DoubleClick
>   Publicité
>   Dstillery
>   Publicité
>   Facebook Exchange (FBX)
>   Publicité
>   Google Adsense
>   Publicité
>   Google Analytics
>   Analytique, Analytics
>   Gravatar
>   Widgets
>   LiveRamp
>   Balises, E-mail Analytics, Segment Data
>   Lotame
>   Balises, Analytics, Lead Management
>   Media Innovation Group
>   Analytique
>   MediaMath
>   Publicité
>   Neustar AdAdvisor
>   Balises, Lead Management
>   Quantcast
>   Publicité
>   Right Media
>   Publicité
>   Simpli.fi
>   Publicité, Segment Data, Behavior Tracking
>   TradeDesk
>   Publicité
>   TubeMogul
>   Analytique, Video Player
>   Turn Inc.
>   Publicité, Affiliate Marketing, Lead Management
>   Videology
>   Balises, Video Player
>   Yahoo Analytics
>   Analytique
> 
> [1] http://gis.19327.n5.nabble.com/France-f5380434.html
> [2] https://addons.mozilla.org/fr/firefox/addon/ghostery/
> 
> 
> 
> 
> --
> View this message in context:
> http://gis.19327.n5.nabble.com/Forum-Nable-tp5841220.html Sent from the
> France mailing list archive at Nabble.com.
> 
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr


-- 
sly, direct contact : sylv...@letuffe.org
http://wiki.openstreetmap.org/wiki/User:Sletuffe

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


Re: [OSM-talk-fr] FFRandonnée ? de quoi rire encore un moment (jaune ?)

2015-03-25 Par sujet sly (sylvain letuffe)
J'ai l'impression de refaire le débat tous les ans...

Je racouricisais certes, mais on parle ici du droit d'auteur de la FFRP sur 
l'oeuvre de l'esprit qu'est l'intinéraire "GR"
Et si la FFRP ne nous donne pas son accord de reproduire dans osm, c'est donc 
qu'on a pas le droit.

C'est pas parce que le photographe publie sur son blog une photo en oubliant 
d'indiquer "copyright machin truc" en bas que hop, ça en devient une licence 
libre.


Le mercredi 25 mars 2015 12:50:27, Jean-Marc Liotier a écrit :
> On 25/03/2015 12:27, sly (sylvain letuffe) wrote:
> > "Ce qui n'est pas expréssément autorisé est interdit" dit la loi.
> 
> Nan, en droit Français tout ce qui n'est pas formellement interdit est
> autorisé.
> 
> 
> ___________
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr

-- 
sly (sylvain letuffe)
http://wiki.openstreetmap.org/wiki/User:Sletuffe

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


Re: [OSM-talk-fr] FFRandonnée ? de quoi rire encore un moment (jaune ?)

2015-03-25 Par sujet sly (sylvain letuffe)
Le mercredi 25 mars 2015 09:02:27, Vincent Pottier a écrit :
> "Qui ne dit rien consent." dit le proverbe.

"Ce qui n'est pas expréssément autorisé est interdit" dit la loi.

> Peut-être faudrait-il faire, sur le wiki, une page plus ou moins
> officielle rappelant des démarches (avec mention des contacts, des
> mails...) 

+1
Ok pour grouper les efforts entrepris et à entreprendre dans une même zone 
plus aisée à consulter que des archives de listes éparpillées sur 5 ans


-- 
sly (sylvain letuffe)
http://wiki.openstreetmap.org/wiki/User:Sletuffe

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


Re: [OSM-talk-fr] FFRandonnée − de quoi rire encore un moment (jaune ?)

2015-03-24 Par sujet sly (sylvain letuffe)
On mardi 24 mars 2015, Eric Marsden wrote:

>   On peut imaginer mobiliser les randonneurs 

(...)

>   Mais il me semble qu'il manque pour cela un
>   site web 

Un site web, pourquoi pas, mais dans un premier temps, il manque avant tout 
des motivés qui ont du temps à passer pour faire bouger les choses. 
Dans un premier temps on pourrait lister les gens près à s'investir, puis 
lister tous les contacts qui ont été pris avec la FFRP (ou ces clubs, ou ces 
membres de clubs), les idées pour sensibiliser qui ont réussi, les exemples 
d'avantages à avoir les GR dans osm tels que tu viens de les lister.

>   Je suis motivé pour participer à un groupe qui se lancerai là-dedans,
>   s'il y a des intéressés.

J'en suis. 
J'avais commis en 2012:
http://wiki.openstreetmap.org/wiki/Draft:ffrp-lettre-ouverte
Mais n'avais pas réussi à fédérer un groupe de "rentre un peu dedans"

Je suggère que le wiki d'osm.org fasse office de première zone de re-
groupement, un "wikiprojet" par exemple ?
Et que l'on y groupe tout ce qui tourne autour du thème "Libération des GR par 
la FFRP"
Que pensez vous d'un truc comme ça (nom à décider ensemble?) :
http://wiki.openstreetmap.org/wiki/WikiProject_France/Chemins_de_petite_et_grande_randonn%C3%A9e_%28GR_PR%29_dans_Openstreetmap

Les motivés pourraient alors suivre les initiatives en "suivant la page wiki" 
on pourrait faire pareil avec un sujet sur le forum

-- 
sly, direct contact : sylv...@letuffe.org
http://wiki.openstreetmap.org/wiki/User:Sletuffe

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


Re: [OSM-talk-fr] [propostition] Changement massif natural=rock vers bare_rock pour les surfaces ?

2015-02-28 Par sujet sly (sylvain letuffe)
Le vendredi 27 février 2015 15:18:04, JB a écrit :
> Et comme peu de réponses/d'intérêt (ça doit être moins sexy que les
> Fantoirs ou les débits de bornes incendie, j'approuve, j'encourage, (et
> je ne m'opposerais pas à ce que tu ailles plus loin, mais là, en tous
> cas, je ne vois pas qui ne serait pas d'accord).

Il y a quand même eu ta remarque pertinente sur les contributeurs (dont toi 
;-) ) qui aurait pu tagguer des rochers de taille moyenne en natural=rock de 
manière volontaire et assumée.

Ne voulant donc pas avancer trop vite, je ne viens de m'occuper que de ceux 
issus de l'import CLC de 2009 ayant 
CLC:code=332 + natural=rock

En temps et en heure, si d'ici là tout n'a pas été re-tagguer un par un, il 
sera toujours temps de s'occuper des ~1200 restant.

Le fait qu'a partir de maintenant, la moitié sera affichée sur le rendu par 
défaut d'osm.org devrait inciter les gens (interssés!) à se pencher sur la 
question


> JB.
> 
> Le 27.02.2015 11:47, sly (sylvain letuffe) a écrit :
> > N'ayant pas eu beaucoup de réponse, je me permets une relance, pour une
> > version réduite :
> > 
> > J'ai 1083 ways et relation avec avec :
> > natural=rock
> > et
> > source="Union européenne - SOeS, CORINE Land Cover, 2006."
> > 
> > Je propose de m'en tenir à la conversion uniquement de ceux-là en
> > natural=bare_rock

-- 
sly (sylvain letuffe)
http://wiki.openstreetmap.org/wiki/User:Sletuffe

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


Re: [OSM-talk-fr] [propostition] Changement massif natural=rock vers bare_rock pour les surfaces ?

2015-02-28 Par sujet sly (sylvain letuffe)
Le vendredi 27 février 2015 12:57:13, Jérôme Seigneuret a écrit :
> Si tu veux faire mieux, base toi sur le *CLC:code=332 *
> C'est la base de l'import et si quelqu'un a changé la source entre temps il
> est peu probable qu'il ait changé le code.

Je viens d'utiliser ton idée, ça ne change toutefois pas grand chose, j'ai 
juste pu récupérer 3 objets de plus dont la source avait été changée pour 
inclure "bing + CLC"



-- 
sly (sylvain letuffe)
http://wiki.openstreetmap.org/wiki/User:Sletuffe

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


Re: [OSM-talk-fr] [propostition] Changement massif natural=rock vers bare_rock pour les surfaces ?

2015-02-27 Par sujet sly (sylvain letuffe)
N'ayant pas eu beaucoup de réponse, je me permets une relance, pour une 
version réduite :

J'ai 1083 ways et relation avec avec :
natural=rock 
et
source="Union européenne - SOeS, CORINE Land Cover, 2006."

Je propose de m'en tenir à la conversion uniquement de ceux-là en 
natural=bare_rock

-- 
sly, direct contact : sylv...@letuffe.org
http://wiki.openstreetmap.org/wiki/User:Sletuffe

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


Re: [OSM-talk-fr] [propostition] Changement massif natural=rock vers bare_rock pour les surfaces ?

2015-02-17 Par sujet sly (sylvain letuffe)
Hello,

On lundi 16 février 2015, JB wrote:
> Par contre, en tant que contributeur sur les thématiques rando/nature, je ne
> sais plus si j'aurais taggué quelques gros rochers en surfacique. 

Ça ne serait pas non plus tragique. Au contraire, ça les ferait (enfin !) 
apparaître sur le rendu par défaut d'osm.org (pas pour le rendu tout ça)

natural=bare_rock est prévu pour les surfaces,  il n'y a pas de contre-
indication de taille à les convertir de natural=rock vers natural=bare_rock.

Mais je suis d'accord, il vaut avancer prudemment.


> Du coup, est-ce que tu as fait quelques stats sur les objets envisagés :
>  - source avec quelque chose qui ressemble à CLC

J'ai 1083 réponses avec :
source="Union européenne - SOeS, CORINE Land Cover, 2006."
Ceux-là, ça me semble sécure des les convertir.

 
>  - surface de l'objet

Et 1176 "autres" donc le fichier est trouvable ici :
http://sly.letuffe.org/echange/natural-rock-non-CLC.osm

Un "sondage aléatoire" à l'aide de bing, m'indique que la majorité de ce qui 
se trouve en montagne est issue d'un mimétisme et devrait maintenant être des 
natural=bare_rock si on en croit le wiki. Tout ce qui est de "grosse surface" 
pareil, même en bord de mer.
Pour les petites surfaces (je sais pas, disons moins de 20m de plus grande 
longeur) y'en a encore plein qui semble être des surfaces de roches qui 
pourrait tout à fait se taguer natural=bare_rock
Ensuite, à moins de 5 mètres, je distingue plus grand chose, c'est peut-être 
des cailloux amovibles (avec grue !) qui serait mieux en natural=stone.

Je trouve au passage quelques trucs comme ça :
https://www.openstreetmap.org/way/200436053
qui n'aurait, à mon avis, ni du être rock ni bare_rock, ça n'a rien de 
naturel, ce sont des brises lames (contre la houle)
man_made=breakwater aurait suffit, avec éventuellement, pour les adorateurs du 
coupage de cheveux :
breakwater_material=rock

 
> Pour le deuxième point, je pense que si la distribution descend bas,
> peut-être que les cas à moins d'une/quelques centaines de mètres carrés
> pourraient avoir une validation ou invalidation manuelle.

ça me semble une très bonne approximation (du genre 100m2). Charge a temps de 
régler les cas plus petits qui ne s'afficherons nulle part

ça me va comme démarche.



> JB.
> 
> Le 14.02.2015 17:03, sly (sylvain letuffe) a écrit :
> > Hello,
> > 
> > En 2009 nous avions commis ça :
> > https://wiki.openstreetmap.org/wiki/WikiProject_France/Corine_Land_Cover/
> > Nomenclature [1]
> > 
> > Avec tout particulièrement :
> > natural=rock
> > "Roches nues
> > Éboulis, falaises, rochers, affleurements."
> > 
> > Nous avions également commis l'indélicatesse, à l'époque, de ne pas
> > documenter ce tag pour cet usage à un endroit bien en vu et en anglais.
> > D'autres l'on alors utilisé uniquement pour des rochers isolés trouvés en
> > mer qui émergent, puis d'autres pour la partie visible des rochers
> > isolés, sur terre ayant été déplacés. Au début sous forme de point, puis
> > de surface. Et toujours sans que personne ne décrive ce qui était
> > entendu par "natural=rock"
> > 
> > De ce méli-mélo est né la proposition natural=bare_rock
> > https://wiki.openstreetmap.org/wiki/Tag:natural%3Dbare_rock [2]
> > pour indique ce que nous avions indiqué par natural=rock
> > 
> > et
> > https://wiki.openstreetmap.org/wiki/Tag:natural%3Drock [3]
> > une sorte de truc batard entre natural=bare_rock et natural=stone
> > 
> > Je ne suis personnellement pas satisfait de comment ça s'est passé,
> > natural=rock pour les surfaces, c'était très bien, les autres n'avaient
> > qu'a prendre exemple sur nous !
> > Au lieu de ça, a été créée natural=rock, une proposition batarde (qui a
> > été votée malgré tout) et qui ressemble à s'y méprendre à
> > natural=bare_rock mais pour les "petites surface" et les noeuds.
> > 
> > Quoi qu'il en soit, les stats indiquent qu'on a perdu, et nos
> > natural=rock ne s'affichent plus et ne sont pas facilement exploités.
> > Je propose l'abdication, et pour éviter d'ajouter encore plus en
> > confusion aux nouveaux contributeurs en France qui hésitent entre entre
> > suivre le wiki et faire comme c'est fait juste à coté, je propose, de
> > retagguer tous les natural=rock en natural=bare_rock (sauf si présent
> > sur un noeud)
> > 
> > Cela concernera :
> > 2 292 way
> > et 51 Relations multipolygons
> > http://taginfo.openstreetmap.fr/tags/natural=rock [4]
> > 
> > Méthode : Téléchargement pa

Re: [OSM-talk-fr] Vie et mort des magasins

2015-02-16 Par sujet sly (sylvain letuffe)
On lundi 16 février 2015, Christian Quest wrote:

> En plus une entreprise (personne morale) peut avoir de multiples
> établissements... l'un peut ouvrir, fermer, mais l'entreprise existe
> toujours...

Et un gérant peut vendre son restaurant, mais par simplicité, le repreneur 
décide d'en changer le nom sans en changer la raison sociale.

Et là, aucune trace officielle.

Et je dis pas ça dans le vent !
http://www.societe.com/societe/la-corne-de-brume-424378552.html
Etablie à CHAMBERY (73000), 27 PLACE MONGE, l'entreprise LA CORNE DE BRUME est 
active depuis 15 ans.
"La corne de brume" vendait des crèpes jusqu'en 2009 je crois puis a changé 
d'enseigne pour devenir vendeur de pizza:
http://www.linternaute.com/restaurant/restaurant/27555/chez-anna-maria.shtml

Alors oui, toutes les sources seront les bienvenues pour réduire l'usure des 
semelles, mais ça n'empêchera pas d'avoir une stratégie plus organisée.

Là, j'invente, mais des idées, j'en ai plein :
- listing de tous les resto de France dont l'objet n'a pas été retouché depuis 
plus de 3 ans
- récupération dans une bbox la liste précédente, calcul par le voyageur de 
commerce du chemin optimal pour les visiter tous
- de retour sous JOSM avec les notes prises, modif blanche sur tous les objet 
pour mettre à jour la date, qui veut dire : a été contrôlé.

- site qui liste les resto sur une carte grâce à osm, disposant d'une case 
"n'existe plus" qui ouvre une note par l'API

- logiciel de googlefight qui alerte quand la requête "fermé + " 
sur google donne plus de 10 réponses ;-)


-- 
sly, direct contact : sylv...@letuffe.org
http://wiki.openstreetmap.org/wiki/User:Sletuffe

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


[OSM-talk-fr] [propostition] Changement massif natural=rock vers bare_rock pour les surfaces ?

2015-02-14 Par sujet sly (sylvain letuffe)
Hello,

En 2009 nous avions commis ça :
https://wiki.openstreetmap.org/wiki/WikiProject_France/Corine_Land_Cover/Nomenclature

Avec tout particulièrement :
natural=rock
"Roches nues
Éboulis, falaises, rochers, affleurements."

Nous avions également commis l'indélicatesse, à l'époque, de ne pas documenter 
ce tag pour cet usage à un endroit bien en vu et en anglais.
D'autres l'on alors utilisé uniquement pour des rochers isolés trouvés en mer 
qui émergent, puis d'autres pour la partie visible des rochers isolés, sur 
terre ayant été déplacés. Au début sous forme de point, puis de surface.
Et toujours sans que personne ne décrive ce qui était entendu par 
"natural=rock"

De ce méli-mélo est né la proposition natural=bare_rock
https://wiki.openstreetmap.org/wiki/Tag:natural%3Dbare_rock
pour indique ce que nous avions indiqué par natural=rock

et 
https://wiki.openstreetmap.org/wiki/Tag:natural%3Drock
une sorte de truc batard entre natural=bare_rock et natural=stone


Je ne suis personnellement pas satisfait de comment ça s'est passé, 
natural=rock pour les surfaces, c'était très bien, les autres n'avaient qu'a 
prendre exemple sur nous !
Au lieu de ça, a été créée natural=rock, une proposition batarde (qui a été 
votée malgré tout) et qui ressemble à s'y méprendre à natural=bare_rock mais 
pour les "petites surface" et les noeuds.

Quoi qu'il en soit, les stats indiquent qu'on a perdu, et nos natural=rock ne 
s'affichent plus et ne sont pas facilement exploités. 
Je propose l'abdication, et pour éviter d'ajouter encore plus en confusion aux 
nouveaux contributeurs en France qui hésitent entre entre suivre le wiki et 
faire comme c'est fait juste à coté, je propose, de retagguer tous les 
natural=rock en natural=bare_rock (sauf si présent sur un noeud)

Cela concernera :
2 292 way
et 51 Relations multipolygons
http://taginfo.openstreetmap.fr/tags/natural=rock


Méthode : Téléchargement par l'Overass (en plusieurs fois si besoin) sur la 
france métropolitaine d'abord avec comme conditions :
* être un way ou une relation
* avoir les tags natural=rock


Ensuite remplacer par natural=bare_rock, et upload.

ps: je ne souhaite pas limiter aux way en version 1 car :
- les retouches de géométries depuis 5 ans les ont fait passer en vx
- d'autre contributeurs on pu en ajouter pa mimétisme
- le risque de confusion avec l'usage rééllement voulu de natural=rock (A 
notable rock or group of rocks, with at least one of them firmly attached to 
the underlying bedrock. ) me semble sans danger car c'est pareil ou presque 
que bare_rock : "For areas of solid visible rock. "

Opinions/contre-indications ?


-- 
sly (sylvain letuffe)
http://wiki.openstreetmap.org/wiki/User:Sletuffe

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


Re: [OSM-talk-fr] Base de données pour le développement

2015-02-12 Par sujet sly (sylvain letuffe)
pré-scriptum: je me demande si on ne serait pas mieux sur la liste dev-fr :
https://lists.openstreetmap.org/listinfo/dev-fr
pour ce genre de sujet.

On jeudi 12 février 2015, Vincent Frison wrote:
> Le problème c'est que osm2pgsql plante dès que j'importe un fichier OSM
> contenant des éléments provenant de l'API de test (erreur de segmentation
> et strace ne donne pas d'infos supplémentaires très utiles).

Tu peux indiquer la sortie standard de ton osm2pgsql ?


> J'ai par exemple téléchargé depuis JOSM les quelques bâtiments présents
> dans l'API de test qui sont juste en dessous la Gare de Lyon (tours Gamma
> et Natixis), bâtiment que j'avais uploadé il y a quelques jours. Mais
> osm2pgsql ne veut pas digérer le fichier généré alors qu'évidemment ça
> passe très bien si c'est un fichier OSM de la même zone mais exporté depuis
> le vrai serveur. 

Je viens de tenter exactement ce que tu indiques et je n'ai eu aucun problème.
Ma méthode :
JOSM -> F12 -> http://master.apis.dev.openstreetmap.org/api
Télécharger tout Paris (donc garde de Lyon)
Calques -> bouton droit -> enregistrer sous test.osm

Puis commande :
cat /tmp/test.osm /home/ressource-for-osm/osm2pgsql/osm2pgsql --create -p test 
--unlogged -C 1000 --number-processes=3 -p test -m -G -s -S ./osm2pgsql-
choosen.style -d gis -r libxml2 /dev/stdin

Début de mon fichier test.osm :


  


> Il faut donc croire que les bâtiments que j'ai uploadé sur
> l'API de test ne sont pas complètement valides.. mais c'est assez étonnant
> puisque j'ai bien réussi à les uploader.
> 
> Pour info j'utilisais une veille version d'osm2pgsql puisque c'était celle
> de Debian Wheezy (0.80). J'ai donc compilé non sans mal la version Git
> (0.87) mais le problème est exactement le même.
> 
> J'essayerai de refaire des tests de ce soir notamment avec les fichiers du
> cadastre.. ou avec un fichier contenant juste un seul bâtiment pour essayer
> de comprendre où est le problème.
> 
> 
> 
> Le 11 février 2015 08:27, Christian Quest  a écrit
> 
> >  Euh... en appelant l'API ?
> > 
> > Pour un test un 'map' sur une petite zone que tu aura préchargé en
> > bâtiment comme je l'avais indiqué devrait aller, non ?
> > 
> > 
> > http://wiki.openstreetmap.org/wiki/API_v0.6#Retrieving_map_data_by_boundi
> > ng_box:_GET_.2Fapi.2F0.6.2Fmap
> > 
> > Ce que je ferai (encore plus simple):
> > - récup des bâtiments d'un arrondissement sur cadastre.openstreetmap.fr
> > - ouverture dans JOSM, envoi des bâtiments sur l'API de test
> > - après upload, enregistrement dans un fichier .osm (donc tu as les ID
> > attribuées par l'API de test)
> > - import dans postgres avec osm2pgsql de ce .osm
> > - test de ton script sur l'API de test
> > 
> > Le 10/02/2015 22:42, Vincent Frison a écrit :
> >  Le 10 février 2015 21:46, Christian Quest  a
> > 
> > écrit :
> >>  Il sufit de charger dans ton postgres de test non pas la base OSM
> >> 
> >> normale, mais une récupération des données sur l'API de test... là tu
> >> aura tout synchro pour tes tests.
> >> 
> >> Une fois que tout est ok, tu recharge les vraies données OSM et tu
> >> relance ton script.
> >> 
> >  Merci Christian.. mais question sans doute un peu bête: comment je fais
> > 
> > pour récupérer les données de l'API de test ?
> > 
> > 
> > 
> > ___
> > Talk-fr mailing
> > listTalk-fr@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/ta
> > lk-fr
> > 
> > 
> > --
> > Christian Quest - OpenStreetMap France
> > 
> > 
> > ___
> > Talk-fr mailing list
> > Talk-fr@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-fr


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

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


Re: [OSM-talk-fr] OSM hors ligne

2015-02-04 Par sujet sly (sylvain letuffe)
Le mardi 3 février 2015 11:37:49, Pierre Knobel a écrit :

> Un rendu à la volée à partir des données d'OSMAnd serait effectivement
> une bonne solution. En additionnant toutes les tailles sur la page
> http://download.osmand.net/list.php on arrive à seulement 31Go. Reste
> à trouver un moteur de rendu qui digère les fichier OBF et  fonctionne
> sous Windows ou Linux. Ou un émulateur Android.

Pas forcément qui gère ce format obf, il y a plein de soft qui ont leur 
propre format de stockage en vectoriel, le gros du boulot... c'est de les 
essayer !

https://help.openstreetmap.org/questions/12806/linux-desktop-viewer-like-osmand-for-android
-- 
sly (sylvain letuffe)
http://wiki.openstreetmap.org/wiki/User:Sletuffe

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


Re: [OSM-talk-fr] OSM hors ligne

2015-02-03 Par sujet sly (sylvain letuffe)
Le dimanche 1 février 2015 18:04:19, Pierre Knobel a écrit :
> Mais là il ne s'agit pas de contribuer, juste d'avoir accès à des
> services cartographiques pour économiser les accès web à GoogleMaps et
> OSM, 

ça manque encore de précisions il me semble, tu as besoin de quoi par 
"services cartographiques" ?


> histoire de pouvoir continuer à explorer le monde et planifier
> les prochaines vacances même quand internet nous lâche au boulot.
(...)
> mais on n'a pas encore
> de bonne solution pour la problématique "Je suis dans la brousse avec
> mon ordinateur portable, j'aimerais bien savoir à quoi ressemble Tokyo
> ou Reykjavik".

Planifier ses vacances, explorer le monde, voir à quoi ressemble la rue machin 
à Tokyo, trouver les points de vues d'une coline de la réunion, ce genre de 
besoin peuvent être répondue par une appli qui stocke les données en vectoriel 
et te fait le rendu à la vollée.

osmand sur android me vient en tête, beaucoup s'en servent pour du routage, 
mais vu tout ce qu'il affiche, moi je m'en sers pour chercher des idées de 
rando quand je suis dans le TGV et ça le fait bien
Il doit y en avoir d'autres, plus ordi frendly



-- 
sly (sylvain letuffe)
http://wiki.openstreetmap.org/wiki/User:Sletuffe

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


Re: [OSM-talk-fr] Visualisation par un média national avec des données OSM

2015-01-19 Par sujet sly (sylvain letuffe)
On lundi 19 janvier 2015, JB wrote:
> Le 19/01/2015 18:52, Eric Debeau a écrit :
> > http://www.lequipe.fr/Cyclisme-sur-route/Actualite/Anatomie-du-peloto
> > n/529127
> 
> « Désolé, la page que vous cherchez n’existe pas ou plus. »
> Il faut un abonnement, ou quelque chose ?
> JB.

Comme quoi, il vaut souvent mieux faire un copier/coller ;-)

http://www.lequipe.fr/Cyclisme-sur-route/Actualites/Anatomie-du-peloton/529127
un "s" à actualités

-- 
sly, direct contact : sylv...@letuffe.org
http://wiki.openstreetmap.org/wiki/User:Sletuffe

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


Re: [OSM-talk-fr] "Mechanical Edit" : le mal ( était : peut-il guérir le mal ?)

2015-01-19 Par sujet sly (sylvain letuffe)
On dimanche 18 janvier 2015, Art Penteur wrote:
>- Écrire un bot qui tente de faire une correction automatique.
(...)
> Vos avis ?

J'interviens ici à la limite du HS concernant ton titre :
"Mechanical Edit" : le mal (...)

Frédéric a à mon avis bien répondu à la problématique spécifique des noms des 
bureaux de postes: il faut prévenir, informer, et reverter le cas précis que 
tu as mentionné.

A la question sous-jaccente que je crois lire : les "Mechanical Edit" sont ils 
toujours le mal, peut-on les utiliser pour corriger un autre mal, ou même, 
peut on les utiliser pour "faire le bien", j'ai envie d'intervenir :
Plusieurs savent combien ce sujet est "tendu", certaines communautés d'osm 
comme nos voisins anglais comptent dans leurs rangs de farouches défenseurs 
d'un interdit quasi-religieux anti-"Mechanical Edit". Selon ces personnes, on 
devrait tout faire à sueur de souris et contrôler point par point et tag par 
tag, car sinon, des erreurs seront commises et c'est mal de toucher aux 
affaires des autres.
A l'opposé, on trouvera des contributeurs qui pensent que tout ça se régule 
très bien tout seul et qu'a coup d'édit war, la vérité fini toujours par 
éclater (les historiques des objets aussi !).

Pour ma part, je pense que les "Mechanical Edit" ont tout à fait leur place 
dans osm, et s'il est devenu impossible d'en faire à l'échelle mondial car la 
police veille, ce que je ne considère pas comme un mal car c'est un bon garde 
fou, j'aimerais les voir utilisé plus souvent à l'échelle française en 
considérant que bien fait (et bien discuté) c'est un très bon outil pour une 
homogénéisation efficace et la correction d'erreurs triviales.
Pour cela, il faudrait leur rendre quelques lettres de noblesse (ne pas les 
stigmatiser comme un "mal" pour commencer) et ne pas pendre trop vite ceux qui 
voudraient avant tout améliorer la qualité de la base.
Par le passé, en france, certains se souviendront de douloureuses mise en 
majuscules dont le processus avait pu déraper légèrement, mais j'en retire, 
qu'au final, on a eu un sacré coup de balais à cette époque.
Depuis, c'est presque devenu un tabou d'en proposer, et j'en suis triste.

Je répond donc à ce qui était peut-être ta question sous-jaccente, selon moi, 
ça aurait pu être bien de mass corriger le nom des bureaux de poste, même avec 
quelques mauvaises corrections si, par exemple, le revert avait été tenté trop 
tard et aurait conduit à plein d'autres pertes d'info que de tenter 
maladroitement de revenir en arrière.

Les "Mechanical Edit" c'est pas le mal, proposez en, j'y suis favorable de 
principe.


-- 
sly, direct contact : sylv...@letuffe.org
http://wiki.openstreetmap.org/wiki/User:Sletuffe

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


Re: [OSM-talk-fr] Services d'OSM-FR plus accessibles suite à panne

2015-01-15 Par sujet sly (sylvain letuffe)
> > - oapi-fr.openstreetmap.fr 
> Peux-tu lui coller un alias plus parlant (...) ? 

Ha ben non ! Quand ça devient trop explicite, les gens ne lisent plus la doc, 
et après se plaignent à moi qu'ils n'ont pas lu la doc.


Voire carrément se servent de cet Overpass API pour faire des modifs en masse 
et invoquent après s'être fait attrapé par la police que la documentation 
était placardée dans le fond d'un classeur fermé à clé, coincé dans des 
lavabos désaffectés avec sur la porte la mention : Gare au léopard.


Non, oapi-fr c'est bien, c'est court et mystérieux ça donne envie de se 
renseigner et ça rappel par le "fr" que ça ne concerne que la métropole.
De plus, avoir trop d'alias pointant au même endroit, ça ne fait que brouiller 
les pistes du débugging.

-- 
sly, direct contact : sylv...@letuffe.org
http://wiki.openstreetmap.org/wiki/User:Sletuffe

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


Re: [OSM-talk-fr] "touching inner rings" détecté par OSM Inspector

2015-01-15 Par sujet sly (sylvain letuffe)
On jeudi 15 janvier 2015, Romain MEHUT wrote:
> c'est à dire qu'il utilise un segment de landuse pour l'attribuer dans deux
> relations définissant les landuses contigus. C'est compliqué les choses là
> où ce n'est pas nécessaire...

J'ai peur que l'on ne puisse pas trancher le "c'est compliquer les choses", 
c'est affaire de goûts, d'outils et d'habitudes.
A titre personnel, j'enrage quand je dois découdre puis re-coudre des 
polygones de landuse qui se superposent sur des centaines de noeuds, j'ai 
l'impression de devoir tout coudre 2 fois ou parfois de devoir cliquer comme 
un parkinsonien car les outils de duplication/fusion me perdent.
J'imagine que pour toi, c'est l'inverse ;-)

Bref, je préfère la solution du multi-polygon (sans touching inners ou 
outers), sans doute car j'ai morflé longtemps sur les limites 
admininistratives et que je me suis habitué. Le bosquet d'arbre de 7 noeuds ne 
suffira pas à me motiver pour sortir les relations mais au delà de 50 noeuds 
ou des 6 morceaux de frontière, oui.

Toutefois, je n'entreprend pas un djiad pour forcer les autres. Passer au 
multi-polygon dans ce seul but, je ne le cautionne pas, en effet, c'est 
autorisé :

> http://wiki.openstreetmap.org/wiki/FR:Relation:multipolygon#Anneaux_interne
> s_adjacents

Par contre, quand je me met en tête de refaire tout une zone, je commence par 
supprimer corine et je refais tout en MP

> J'aimerai avoir votre point de vue avant de poursuivre la discussion avec
> ce contributeur.

Il ne devrait pas insister car il n'apporte rien à ce qui est, et OSM 
Inspector devrait être prévenu que son "détecteur d'erreur qui ne dit pas son 
nom" contrevient à ce que dit le wiki, et incite au djiad (ce qui, nous le 
savons, est puni par la loi)



-- 
sly, direct contact : sylv...@letuffe.org
http://wiki.openstreetmap.org/wiki/User:Sletuffe

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


Re: [OSM-talk-fr] Services d'OSM-FR plus accessibles suite à panne

2015-01-15 Par sujet sly (sylvain letuffe)
On mercredi 14 janvier 2015, François Lacombe wrote:
> Autant pour moi, je pensais que la mise à jour de l'overpass-API sur les
> .fr nécessitait l'installation d'un ssd pour que cela fonctionne.

Pour être précis, il n'y a pas de "nécessité", toutefois, si on veut pouvoir 
servir plus de requêtes, et surtout, plus rapidement, oui, il serait bien d'y 
passer, et c'est prévu.
L'upgrade de la version d'OAPI permettant d'avoir accès à l'historique serait 
souhaitable aussi, mais renforcerait l'attrait de la version fr, donc des 
nouveaux utilisateurs, donc des ralentissements, donc la nécessité d'un SSD 
(tout boucle !) donc c'est en grande partie pour ça que je n'ai pas bougé de 
ce coté là.

A noter que le serveur qui a perdu un disque dur est celui qui gère l'oapi ne 
couvrant que la France, celle couvrant le monde n'est pas impacté car se 
trouve sur un autre serveur.
Ses besoins sont bien moindre évidement, et je pourrais passer celle là, au 
moins, à la nouvelle version d'oapi. Mais ça me consommerait un peu plus de 
temps de gérer, simultanément, 2 versions différentes.
Comme je suis un garçon raisonnable, j'attend sagement Noël ;-)


> 
> Christian avait du me dire ça en septembre ou octobre je ne me souviens
> plus.
> 
> Sinon bien joué, efficace comme d'hab ! :)
> Merci à vous
> 
> *François Lacombe*
> 
> fl dot infosreseaux At gmail dot com
> www.infos-reseaux.com
> @InfosReseaux 
> 
> Le 14 janvier 2015 20:18, Jocelyn Jaubert  a
> 
> écrit :
> > Le 14/01/2015 17:12, François Lacombe a écrit :
> > > Bon courage pour cet aléas !
> > > 
> > > Les SSD avaient-ils déjà été installés sur cette machine ?
> > 
> > Cette machine n'avait pas de SSD de prévu.
> > 
> > Pour le moment, on a juste installé un SSD sur osm13, la machine qui
> > héberge
> > les tuiles de tile.openstreetmap.fr. Ça a permis de bien débloquer la
> > machine, qui est bien plus efficace qu'avant.
> > 
> > Une machine et un SSD ont aussi été achetés avec les dons, mais pas
> > encore installés.
> > 
> > 
> > --
> > Jocelyn
> > 
> > 
> > ___
> > Talk-fr mailing list
> > Talk-fr@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-fr


-- 
sly, direct contact : sylv...@letuffe.org
http://wiki.openstreetmap.org/wiki/User:Sletuffe

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


Re: [OSM-talk-fr] Tagguer les Départements français et admin_level=6

2015-01-15 Par sujet sly (sylvain letuffe)
Vous semblez vous moquer de l'idée de manière bien légère. 
Moi je dis, et pourquoi pas ?

Cela offre l'avantage de maintenir l'idée de hiérarchie (contrairement à un 
border_type=collectivite_francaise). De pouvoir intercaler autant de nouveau 
niveau que l'on veut par la suite.
Et de par exemple choisir pour la nouvelle calédonie de ne pas avoir de niveau 
6 et 4 mais d'avoir un niveau 6.1 et 4.1. Ainsi, on aurait :
2 -> france
4.1 -> N. calédonie
6.1 -> Province Sud
8 -> Communes

La Province Sud n'est donc pas un département au même titre que ceux de 
métropole, mais s'intercalle quand même bien entre commune et N. Calédonie
L'ajout sur le wiki français de l'explication 6.1 = Provinces de nouvelle 
calédonie exprime alors ce statu particulier, permettant de les récupérer sans 
ambiguité.

6.2 pour "le Grand Lyon" ?


On mercredi 14 janvier 2015, you wrote:
> Mouarf très bonne idée tiens ! ;-)
> 
> Nicolas
> 
> > Que comme le sujet revient régulièrement, on finira par utiliser des
> > admin_level=5.5 ?
> > Ok, je signe pas…
> 
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
> 
> 
> 
> 
> ___
> If you reply to this email, your message will be added to the discussion
> below:
> http://gis.19327.n5.nabble.com/Tagguer-les-Departements-francais-et-admin-
> level-6-tp5829994p5830006.html
> 
> To unsubscribe from Tagguer les Départements français et admin_level=6,
> visit
> http://gis.19327.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_
> by_code&node=5829994&code=bGlzdGUyQGxldHVmZmUub3JnfDU4Mjk5OTR8MjA3MDY3NzIwM
> A==


-- 
sly, direct contact : sylv...@letuffe.org
http://wiki.openstreetmap.org/wiki/User:Sletuffe




-
-- 
sly, contact direct : sylvain /a\ letuffe o r g
http://wiki.openstreetmap.org/wiki/User:Sletuffe
--
View this message in context: 
http://gis.19327.n5.nabble.com/Re-Tagguer-les-Departements-francais-et-admin-level-6-tp5830106.html
Sent from the France mailing list archive at Nabble.com.

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


Re: [OSM-talk-fr] Tagguer les Départements français et admin_level=6

2015-01-14 Par sujet sly (sylvain letuffe)
Le mercredi 14 janvier 2015 17:45:15, vous avez écrit :
> C'est potentiellement
> inexploitable, source de confusion aussi bien pour le contributeur que
> pour le consommateur. 

C'est tout particulièrement au consommateur que je pense. Si quelqu'un vient 
vers moi et me dit : "ok, j'ai importé les données de l'UE dans ma base, 
comment est la requête pour sortir les géométries des départements français ?"

Et bien en france, les départements c'est admin_level=6 +  
boundary=administrative mais pas border=religious et pas non plus 
administrative=metropole ni non plus administrative=province. 
Et quand il/elle aura fait ses 28 requêtes avec 5 conditions chacune qu'il 
aura incorporé dans son soft lui permettant de modeler l'UE administrative à 
sa convenance, il deviendra délicat de lui expliquer que tous les 3 mois il 
doit ajouter telle condition car notre modèle n'est pas super stable.
(Ok, de toute façon, avec les policiens europééns, il devra quand même 
modifier son truc car les départements français vont sauter)

Mon exemple est fictif, il est l'extension de mon cas où je fourni un export 
en shapefile des départements et régions françaises.



> Mais... je crains qu'on aie un peu de mal à tagguer
> vraiment différemment aussi bien Lyon que la Nouvelle-Calédonie. Donc je
> verrais bien le maintien des tags actuels (boundary et admin_level) sans
> changer leurs valeurs, mais à la condition qu'on ajoute, comme le suggère
> Philippe, un tag qui raffine le sens, afin de pouvoir les distinguer,
> autrement que par leur ID de relation ou par la valeur de leur tag name.
> Je n'ai pas cherché bien loin, mais il existe par exemple le tag
> 'administrative', joyeux fourre-tout pour l'instant :
> http://taginfo.openstreetmap.org/keys/administrative#values
> qu'on pourrait utiliser, par exemple pour Lyon :
> boundary=administrative
> admin_level=6
> administrative=metropole
> et en NC :
> boundary=administrative
> admin_level=6
> administrative=province
> 
> Je donne ça comme exemple, pas pour dire que ça doit être ce tag ni cette
> valeur, le fond de la question étant de pouvoir manipuler ces données sans
> confusion possible.
> 
> vincent
> 
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
> 
> 
> 
> 
> ___
> If you reply to this email, your message will be added to the discussion
> below:
> http://gis.19327.n5.nabble.com/Tagguer-les-Departements-francais-et-admin-
> level-6-tp5829994p5830012.html
> 
> To unsubscribe from Tagguer les Départements français et admin_level=6,
> visit
> http://gis.19327.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_
> by_code&node=5829994&code=bGlzdGUyQGxldHVmZmUub3JnfDU4Mjk5OTR8MjA3MDY3NzIwM
> A==

-- 
sly (sylvain letuffe)
http://wiki.openstreetmap.org/wiki/User:Sletuffe




-
-- 
sly, contact direct : sylvain /a\ letuffe o r g
http://wiki.openstreetmap.org/wiki/User:Sletuffe
--
View this message in context: 
http://gis.19327.n5.nabble.com/Re-Tagguer-les-Departements-francais-et-admin-level-6-tp5830021.html
Sent from the France mailing list archive at Nabble.com.

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


[OSM-talk-fr] Tagguer les Départements français et admin_level=6

2015-01-14 Par sujet sly (sylvain letuffe)
Bonjour,

Je me pose la question du bien fondé de tagguer ces choses là ainsi :
http://www.openstreetmap.org/relation/379252 
et 
http://www.openstreetmap.org/relation/3222337

Moi et RedFox ne sommes pas d'accord sur ce point et nous cherchons des avis
complémentaires pour trancher. La question que je pose étant : admin_level=6
+ boundary=administrative à l'intérieur de la France devrait-il dénoter
autre chose que des départements français ?

L'autre qui, de mon point de vue, rejoint la même question est une question
qu'on se pose avec Otourly, ce tagging doit il être fait ainsi :
http://www.openstreetmap.org/relation/1663048


De la lecture pour se faire un opinion :
http://fr.wikipedia.org/wiki/Liste_des_d%C3%A9partements_fran%C3%A7ais
http://wiki.openstreetmap.org/wiki/Admin_level
http://fr.wikipedia.org/wiki/Nouvelle-Cal%C3%A9donie

--
sly




-
-- 
sly, contact direct : sylvain /a\ letuffe o r g
http://wiki.openstreetmap.org/wiki/User:Sletuffe
--
View this message in context: 
http://gis.19327.n5.nabble.com/Tagguer-les-Departements-francais-et-admin-level-6-tp5829994.html
Sent from the France mailing list archive at Nabble.com.

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


Re: [OSM-talk-fr] Changements massif sur les noms génériques de shop et amenity

2014-12-24 Par sujet sly (sylvain letuffe)
Tyndare wrote
> On parlais récemment de changements massifs non discutés.
> Personnellement je ne suis pas d'accord avec ce genre de changements:

Je n'ai pas d'avis sur le fond de ce changement. 

Mais je suis contre le fait de le faire sans en parler à personne *avant*.
Je suis donc contre ce changeset. Il n'est pas aussi évident que corriger
une faute de frappe du genre :
hihgway en highway

Le faire sans en parler à personne c'est un ensemble de risques qu'il faut
éviter de prendre :
- si finalement ça ne plaît pas à tous, on (et bien trop souvent pas celui
qui a fait chercher/replacer) doit faire des pieds et des mains pour
l'annuler, surtout s'il est constaté tardivement
- laisser faire un changement sans discussion même qui plaît à presque tous
laisse un "mauvais précédent" sur la méthode de faire.
En effet, discuter avec les autres, c'est long et parfois chiant, plusieurs
sont alors tenté de faire sans rien dire. Si on opte pas pour une réponse
cohérente (exemple: interdire pour tous et annuler dans tous* les cas si
aucune discussion n'a eu lieu) alors j'ai peur, et je le constate déjà (en
partie à cause de (turbo) overpass hélas) que cela va augmenter et les
"petites" (genre de 100 à 5000 objets) éditions automatiques vont passer
sous tous les radars et on risque de perdre des infos.

* : à définir ce qui se cache derrière "tous"



-
-- 
sly, contact direct : sylvain /a\ letuffe o r g
http://wiki.openstreetmap.org/wiki/User:Sletuffe
--
View this message in context: 
http://gis.19327.n5.nabble.com/Changements-massif-sur-les-noms-generiques-de-shop-et-amenity-tp5828133p5828177.html
Sent from the France mailing list archive at Nabble.com.

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


Re: [OSM-talk-fr] OSM.org dev/sys admins ( était : Besoin d'aide pour faire avancer Switch2OSM en français)

2014-12-08 Par sujet sly (sylvain letuffe)
On lundi 8 décembre 2014, you wrote:
> Je ne suis pas sûr d'avoir été clair sur ce point

Je crois avoir compris : tu as un compte sur le wordpress mais dès qu'il 
s'agit de toucher un template, un css ou quoi que ce soit de plus profond par 
ftp ou sftp, c'est non, ou plutôt tu obtiens la réponse "je vais le faire" 
mais c'est pas fait.

> Pour faire suite à tes propositions
>> 1) Demande un compte sur www.openstreetmap.fr et mets y ta traduction de
>> S2O 
> La traduction est déjà sur toutes les pages de Switch2osm officielle:
> quelle est l'utilité de ton point de vue?

Régler ton problème de menu et de css par l'espoir d'obtenir plus facilement 
des admin osm-fr soit de l'aide, soit un accès plus complet, soit d'enlever 
une complexité supplémentaire de la gestion de la langue.

> Dans un premier temps, je vais encore insister sur Switch2osm. Pourquoi?

Je comprends tout à fait tes raisons, ce serait bien évidement la meilleure 
solution. Mais si c'est systématiquement un chemin de croix pour obtenir la 
moindre modif, il faut soit demander un accès plus complet... soit dire stop 
et forker.

> 3) Colle ta traduction sur le wiki.osm.org
> Je suppose que c'est pour pouvoir éditer de manière collaborative. 

Entre autre, mais c'était surtout pour avoir un meilleur contrôle sur des 
liens inter-menus. Mais j'avoue que c'était uniquement mon option 3) Le wiki 
est déjà un terrible fourre-tout où on ne retrouverait rien, une recherche 
"tuiles" perdrait n'importe qui, c'est d'ailleurs ce qu'a dû se dire richard 
en créant switch2osm !

> Sylvain, un avis sur mon retour? Tu pense vraiment que je dois déjà "lâcher
> le fonctionnement officiel"?

Je suis terriblement pessimiste de nature, et encore plus dans ce cas !
J'ai vu de bonnes volontés avec temps et motivation finir par "lâcher le 
morceau" par démotivation provoquée par le "ça n'avance pas"
Là où, peut-être, cette énergie aurait pû être consommée plus tôt sur "je fais 
dans mon coin en autonome"

-- 
sly, direct contact : sylv...@letuffe.org
http://wiki.openstreetmap.org/wiki/User:Sletuffe




-
-- 
sly, contact direct : sylvain /a\ letuffe o r g
http://wiki.openstreetmap.org/wiki/User:Sletuffe
--
View this message in context: 
http://gis.19327.n5.nabble.com/Re-OSM-org-dev-sys-admins-etait-Besoin-d-aide-pour-faire-avancer-Switch2OSM-en-francais-tp5826632.html
Sent from the France mailing list archive at Nabble.com.

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


Re: [OSM-talk-fr] OSM.org dev/sys admins (était : Besoin d'aide pour faire avancer Switch2OSM en français)

2014-12-07 Par sujet sly (sylvain letuffe)
Tant pis si je fais ma langue de pute, mais à un moment il faut bien se
rendre compte qu'il y a un problème, et réussir à dire  qu'il existe sera
déjà un grand pas en avant avant de trouver des solutions pour le surmonter.


ThomasG wrote
> Mon contact technique est l'un de ses admin mais je préfère éviter d'être
> nomitatif. 
> (...)
> J'aimerais que ça avance et je commence à perdre patience...
> Des avis, des conseils pour cela?

Oui : laisser tomber l'idée que l'on peut confier, à l'heure actuelle et
pour sans doute encore un certain temps, à la fondation et ses admins des
outils ou documentation autre que le coeur qui fait fonctionner le système
(site, api, éditeurs, base et rendu par défaut)

Je saisi l'occasion car nous parlons de switch2OSM, mais cela fait plusieurs
fois que je constate le problème pour d'autres cas (que je juge plus
important encore) alors ça ne m'étonne absolument pas pas que ta traduction
de switch2OSM soit délaissée.
Notez qu'il ne s'agit pas d'un reproche concernant la non disponiblité du
temps de qui que ce soit mais d'un constat qui doit nous amener à penser
autrement les "outils périphériques d'osm". C'est d'ailleurs peut-être une
bonne chose au final que de ne pas trop en demander à la fondation (et ses
admins) pour : 1) leur laisser plus de temps pour ce qui compte "le plus" et
2) Mettre moins de pouvoir entre leur main en laissant des projet
périphérique émerger.
Si j'ai un seul truc à reprocher aux admins (aller, c'est pas cher :
particulièrement un certain T. ;-)) c'est de ne pas juste accepter ce fait
et ne pas arriver à le dire publiquement plus clairement. (et d'en arriver à
des propositions simples pour par exemple recruter plus d'aide et simplifier
le ticket d'entrée pour ces "aides").
Richard n'aurait peut-être pas transféré switch2OSM.org à la fondation, et
ça ira au final peut-être mieux.

Pour en revenir à ton sujet, avec des propositions : 
1) Demande un compte sur www.openstreetmap.fr et mets y ta traduction de S2O
2) Réserves/réservons un passeraOSM.org et hébergerons le sur un site de
l'asso fr
3) Colle ta traduction sur le wiki.osm.org






-
-- 
sly, contact direct : sylvain /a\ letuffe o r g
http://wiki.openstreetmap.org/wiki/User:Sletuffe
--
View this message in context: 
http://gis.19327.n5.nabble.com/Besoin-d-aide-pour-faire-avancer-Switch2OSM-en-francais-tp5826485p5826531.html
Sent from the France mailing list archive at Nabble.com.

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


Re: [OSM-talk-fr] Modèle numérique de terrain (MNT) de la Nasa en pas de 30m, bientôt pour tous le monde

2014-11-30 Par sujet sly (sylvain letuffe)
Voilà une bonne nouvelle, ça va mériter quelques tests !
Tout d'abord, j'ai un peu peiné à les trouver, tu confirmes que c'est bien
ça :
http://e4ftl01.cr.usgs.gov/SRTM/SRTMGL1.003/2000.02.11/
?
au niveau taille ça semble correspondre puisque chaque tuille de 1°x1° prend
9 fois plus de place que le SRTM d'avant. Mais sait-on jamais, j'ai trouvé
ça un peu au pif en fouillant leur dépot http ;-)


Yves wrote
> Par contre, sur les zones de relief, ces 
> nouvelles données SRTM sont impressionnantes !!

A mon éternelle habitude de râleur français, je ne dirais pas
"impressionnantes", pour tout dire, je suis même un brin déçu par rapport à
ASTER. 
Dans les vallées alpines, on a beaucoup moins de cet horrible bruit qu'on a
avec aster, là, vraiment, que du bon.

Par contre, dès qu'on s'approche des falaises montagneuses, c'est toujours
pas ça. J'ai l'impression que le problème reste le même qu'avec les 90m de
résolution : le nombre important de trous (nuages j'imagine) qui ont été
comblés par des algos rapiéçant des morceaux de données de ci de là, mais ça
fait pas très réél :

Ici les coubes de niveau tous les 10m sur la même zone de montagne (Massif
Chartreuse en Isère (38) là ou y'a plein de falaises) entre aster et SRTM
GL1 :
http://sly.letuffe.org/echange/

Faudrait vraiment pouvoir prendre le meilleur des deux !

--
sly



-
-- 
sly, contact direct : sylvain /a\ letuffe o r g
http://wiki.openstreetmap.org/wiki/User:Sletuffe
--
View this message in context: 
http://gis.19327.n5.nabble.com/Modele-numerique-de-terrain-MNT-de-la-Nasa-en-pas-de-30m-bientot-pour-tous-le-monde-tp5818323p5825904.html
Sent from the France mailing list archive at Nabble.com.

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


Re: [OSM-talk-fr] Outils pour mise à jour du bâti ?

2014-11-26 Par sujet sly (sylvain letuffe)
althio wrote
> Je récapitule par ordre de préférence approximatif :
> ** removed:*building=* (déjà utlisé, un peu)

Après ce que j'ai lu, vu, et entendu, voilà donc celle que je préfère et que
je compte utiliser et que je viens de documenter :
http://wiki.openstreetmap.org/wiki/Key:removed

demolished ne me plaît finalement pas car le nom limite son usage aux
éléments non naturels (une forêt qui a brulée n'irait pas bien comme
"demolished", pas plus qu'un lac asséché)

Et si quelqu'un tient absolument à indiquer que ça a été détruit (je me
demande bien si l'usage a sa place dans osm ?) un removed:building=church +
demolished=yes peut faire l'affaire.





-
-- 
sly, contact direct : sylvain /a\ letuffe o r g
http://wiki.openstreetmap.org/wiki/User:Sletuffe
--
View this message in context: 
http://gis.19327.n5.nabble.com/Outils-pour-mise-a-jour-du-bati-tp5825219p5825452.html
Sent from the France mailing list archive at Nabble.com.

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


Re: [OSM-talk-fr] Outils pour mise à jour du bâti ?

2014-11-25 Par sujet sly (sylvain letuffe)
On mardi 25 novembre 2014, you wrote:
> ** no:*building=yes
> ** absent:*building=yes

Évidement, c'est quand j'ai fini d'écrire la page :
http://wiki.openstreetmap.org/wiki/Key:no

et que je commence à lister les usages qui y ressemblent que je tombe sur :
http://wiki.openstreetmap.org/wiki/Key:removed

qui est utilisé ~1000 fois et qui semble avoir très exactement le même but.

Multiplier les tags pour un même usage est évidement une mauvaise idée comme 
dit yves, je propose de tout fusionner dans ce qui existe déjà :
removed:

Même "demolished", a bien y réfléchir, le peu qu'on gagne à dire que ça a été 
détruit par rapport à "n'est plus" ne me semble pas justifier deux tags

-- 
sly, direct contact : sylv...@letuffe.org
http://wiki.openstreetmap.org/wiki/User:Sletuffe




-
-- 
sly, contact direct : sylvain /a\ letuffe o r g
http://wiki.openstreetmap.org/wiki/User:Sletuffe
--
View this message in context: 
http://gis.19327.n5.nabble.com/Outils-pour-mise-a-jour-du-bati-tp5825219p5825356.html
Sent from the France mailing list archive at Nabble.com.

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


Re: [OSM-talk-fr] Outils pour mise à jour du bâti ?

2014-11-25 Par sujet sly (sylvain letuffe)
On mardi 25 novembre 2014, you wrote:
> Avec les éléments de Comparison_of_life_cycle_concepts, il manque le
> (...) futur antérieur au conditionnel ascendant grammaire subjonctivo-
> foireuse):

Je vais laisser ça de coté pour l'instant, mon niveau linguistique 
n'atteignant pas le niveau requis, ainsi que la crainte d'un éparpillement 
certain qui nous attend si on commence à discuter du life_cycle_concepts.

Je vais me concentrer sur le problème à l'oeuvre ici: comment fait on pour 
réduire les chances qu'un importeur "(trop) rapide" n'ajoute et rajoute encore 
à chaque mise à jour un bâtiment toujours indiqué sur le cadastre, mais 
n'existant plus en réalité et ayant été supprimé par un contributeur terrain ?


> J'aime bien l'esprit de non_existing et je propose également :
> ** no:*building=yes

J'adore ! Efficace et simple à se souvenir. 
On ajoute donc "no:" devant les tags dont on sait qu'ils n'ont aucune réalité 
sur le terrain et dont l'objet a une très forte chance d'être ré-importé par 
un "armchair mapper"

En plus, cadeau bonux, il est déjà utilisé une petite centaine de fois.
http://taginfo.openstreetmap.org/search?q=no%3A

Il ne lui manquait plus qu'une page sur le wiki :
http://wiki.openstreetmap.org/wiki/Key:no
(commentaires bienvenus)

> Avec note:building="pas de bâtiment sur le terrain, erreur dans le
> cadastre, ne pas ré-importer ou retracer"

Tout à fait, la note reste vivement recommandée en plus. Bien que je préfère 
note=* car plus de chance d'être vue que note:building=*


-- 
sly, direct contact : sylv...@letuffe.org
http://wiki.openstreetmap.org/wiki/User:Sletuffe




-
-- 
sly, contact direct : sylvain /a\ letuffe o r g
http://wiki.openstreetmap.org/wiki/User:Sletuffe
--
View this message in context: 
http://gis.19327.n5.nabble.com/Outils-pour-mise-a-jour-du-bati-tp5825219p5825349.html
Sent from the France mailing list archive at Nabble.com.

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


Re: [OSM-talk-fr] Outils pour mise à jour du bâti ?

2014-11-24 Par sujet sly (sylvain letuffe)
On lundi 24 novembre 2014, you wrote:
> si la géométrie est suffisamment différents, on peut penser qu'il s'agit
> d'un nouveau bâtiment qui a remplacé l'ancien qui avait disparu.

Excellente idée.
+1 de ma part pour conserver la géométrie et ne changer que les tags 
nécessaires.


-- 
sly, direct contact : sylv...@letuffe.org
http://wiki.openstreetmap.org/wiki/User:Sletuffe




-
-- 
sly, contact direct : sylvain /a\ letuffe o r g
http://wiki.openstreetmap.org/wiki/User:Sletuffe
--
View this message in context: 
http://gis.19327.n5.nabble.com/Outils-pour-mise-a-jour-du-bati-tp5825219p5825260.html
Sent from the France mailing list archive at Nabble.com.

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


Re: [OSM-talk-fr] Outils pour mise à jour du bâti ?

2014-11-24 Par sujet sly (sylvain letuffe)
On lundi 24 novembre 2014, you wrote:

> Je ne retrouve pas ma source dans le wiki, mais je me souviens avoir lu
> qu’on laissait les objets n’existants plus pour éviter que quelqu’un le
> réimporte.

Voilà qui pourrait être intéressant si tu la retrouves, ça permettrait de 
comparer nos propositions à une autre qui aurait été faites pour d'autres pays 
histoire d'avoir une cohérence plus grande que franco-française.

Mais je soupçonne qu'elle ne fera guère l'unanimité, ni même la majorité, je 
maintiens que je vois régulièrement, sur les listes générales (talk/tagging) 
des gens qui sont contre tagguer ce qui n'existe plus.

En outre, voilà une page à laquelle beaucoup se réfèrent, et qui entre un peu 
en conflit avec les objets du passés :
http://wiki.openstreetmap.org/wiki/Verifiable

Mais bon, c'est pas grave, on est libre de tagguer ce que les autres ne 
veulent pas qu'on tag !
Trouvons juste, peut-être, un tag explicitement non terrain.

> Tu peux mettre error:building=* plus note=* ?

Ouais, un truc comme ça me semble pas mal.
Ainsi, on peut choisir :
error:building=yes 
ou, si on est sûr qu'il a existé :
demolished:building=yes

"Error" n'est peut-être pas assez explicite ?

option :
non_existing:building=yes + note
ou :
nobuilding=yes + note

autre option avec un seul tag :
note=noexist : blabla bla


Question suivante : la géométrie complète ou juste un noeud ou juste un 
segment en travers ?




-- 
sly, direct contact : sylv...@letuffe.org
http://wiki.openstreetmap.org/wiki/User:Sletuffe




-
-- 
sly, contact direct : sylvain /a\ letuffe o r g
http://wiki.openstreetmap.org/wiki/User:Sletuffe
--
View this message in context: 
http://gis.19327.n5.nabble.com/Outils-pour-mise-a-jour-du-bati-tp5825219p5825245.html
Sent from the France mailing list archive at Nabble.com.

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


Re: [OSM-talk-fr] Outils pour mise à jour du bâti ?

2014-11-24 Par sujet sly (sylvain letuffe)
Pieren wrote
> Avec cette méthode, est-ce qu'on ne risque pas de remettre dans OSM des
> bâtiments qui ont été supprimés/non importés auparavant parce qu'ils
> n'existent pas sur le terrain ? (plus fréquent qu'on ne le pense)

Je confirme, en milieu rural, je rencontre pas mal de cas d'import faisant
apparaître un bâtiment qui n'existe plus.

Quand je tombe sur ce cas, je garde la géométrie intacte et j'enlève le tag
building=yes, et j'ajoute un "note: ne pas ré-importer/retracer ce bâtiment,
il n'existe pas sur le terrain"

Je suis également peu satisfait par cette solution à laquelle il manque
l'homogénéité (je suis le seul à mettre ce texte pile poil)  et
informatiquement détectable (je ne suis même pas moi même stable dans le
temps, je change parfois le texte !).

J'accompagne avec plaisir cette discussion afin que nous trouvions une
méthode commune de gérer ça.

Je note comme options actuelles utilisées :
1- garder la géométrie, virer les tags et mettre un tag note
2- virer la géométrie et mettre un point avec un tag note au milieu de
l'ancienne géométrie
3- garder la géométrie, virer les tags, remplacer et mettre un tag note +
building=no
4- garder la géométrie, virer les tags, mettre un tag building:destroyed=yes

Et comme je suis difficile, aucune ne me plait
1) pas détectable par un programme sans un risque d'ambiguité avec truc
n'ayant pas de rapport avec un bâtiment

2) idem 1) + dans le cas de bâtiment collés, la détection de collision
point/bâtiment nécessite un point par bâtiment collé ou un calcul de
proximité augmentant les faux négatif

3) risque de mauvaise interprétation par les usagers qui feraient un
building=* => bâtiment générique

4) peu utilisé, taginfo : 45 cas. Et détruit sous entend que le cas "n'a
jamais existé" n'est pas possible. Ce format suit bien les formats disused:
abandonned: mais va à l'encontre d'une règle OSM qui est qu'on ne
cartographie pas ce qui n'est pas, ou n'est plus, or ces autres tag qui
décrivent le cycle de vie d'un objet
http://wiki.openstreetmap.org/wiki/Comparison_of_life_cycle_concepts sont
limité à ce qui est (ou au pire, à ce qui reste)

Mon coeur balance entre 3) et 4) mais je me demande si on pourrait pas
utiliser 5) ?

--
sly



-
-- 
sly, contact direct : sylvain /a\ letuffe o r g
http://wiki.openstreetmap.org/wiki/User:Sletuffe
--
View this message in context: 
http://gis.19327.n5.nabble.com/Outils-pour-mise-a-jour-du-bati-tp5825219p5825239.html
Sent from the France mailing list archive at Nabble.com.

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


Re: [OSM-talk-fr] "Poubelle nucléaire de Bure"

2014-11-06 Par sujet sly (sylvain letuffe)
Re,

J'ai pris contact avec l'utilisateur en tant que membre du DWG 
( http://wiki.openstreetmap.org/wiki/DWG )

Merci de m'indiquer (ici ou en privé) si cet utilisateur persiste.


On jeudi 6 novembre 2014, JB wrote:
> On avait pas un groupe GA pour ça ? « suivre et aider à la résolution
> des conflits d'édition », « gestion vandalisme ».
> https://lists.openstreetmap.org/pipermail/talk-fr/2012-October/049559.html
> http://listes.openstreetmap.fr/wws/info/ga
> JB.
> 
> Le 06/11/2014 09:42, Otourly Wiki a écrit :
> > Y'a le polygone à coté aussi...
> > Florian
> > 
> > 
> > Le Jeudi 6 novembre 2014 8h52, Romain MEHUT  a
> > écrit :
> > 
> > 
> > Le 5 novembre 2014 23:41, Pierre-Yves Berrard
> > mailto:pierre.yves.berr...@gmail.com>>
> > 
> > a écrit :
> > C'était valeureux de ta part, Rom1 !
> > http://www.openstreetmap.org/way/144337590/history
> > 
> > Bon ben, DWG ?
> > 
> > Qui s'y colle et comment?
> > 
> > Romain
> > 
> > ___
> > 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


-- 
sly, direct contact : sylv...@letuffe.org
http://wiki.openstreetmap.org/wiki/User:Sletuffe

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


Re: [OSM-talk-fr] [ga] Re: "Poubelle nucléaire de Bure"

2014-11-06 Par sujet sly (sylvain letuffe)
Bonjour,

Merci à JB d'avoir transmis sur la liste GA, je m'en occupe et je vous tiens 
au courant.


On jeudi 6 novembre 2014, JB wrote:
> On avait pas un groupe GA pour ça ? « suivre et aider à la résolution
> des conflits d'édition », « gestion vandalisme ».
> https://lists.openstreetmap.org/pipermail/talk-fr/2012-October/049559.html
> http://listes.openstreetmap.fr/wws/info/ga
> JB.
> 
> Le 06/11/2014 09:42, Otourly Wiki a écrit :
> > Y'a le polygone à coté aussi...
> > Florian
> > 
> > 
> > Le Jeudi 6 novembre 2014 8h52, Romain MEHUT  a
> > écrit :
> > 
> > 
> > Le 5 novembre 2014 23:41, Pierre-Yves Berrard
> > mailto:pierre.yves.berr...@gmail.com>>
> > 
> > a écrit :
> > C'était valeureux de ta part, Rom1 !
> > http://www.openstreetmap.org/way/144337590/history
> > 
> > Bon ben, DWG ?
> > 
> > Qui s'y colle et comment?
> > 
> > Romain
> > 
> > ___
> > 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


-- 
sly, direct contact : sylv...@letuffe.org
http://wiki.openstreetmap.org/wiki/User:Sletuffe

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


Re: [OSM-talk-fr] Site openstreetmap.fr en carafe

2014-08-10 Par sujet sly (sylvain letuffe)
Le dimanche 10 août 2014 20:48:04, George Kaplan a écrit :
> Bonjour,
> 
> 
> J'ai une erreur HTTP 403 sur les domaines www.openstreetmap.fr et
> openstreetmap.fr. Une opération en cours ?


Exact. Un soucis que l'on espère pas trop grâve, le temps d'investigation et 
d'une mise à jour et ça devrait revenir.



-- 
sly (sylvain letuffe)
http://wiki.openstreetmap.org/wiki/User:Sletuffe

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


Re: [OSM-talk-fr] Revoir l'extraction des adresses du cadastre ( était [import lieux-dits (avec fixme)])

2014-08-02 Par sujet sly (sylvain letuffe)
Le samedi 2 août 2014 16:15:12, V de Chateau-Thierry a écrit :
> j'enlèverais carrément le tag place plutôt que vide car JOSM
> le prend comme tel, et on a donc le risque de remplir la base avec une
> valeur 'vide' malheureuse. 

Ce qui a l'avantage de le faire s'afficher tous les outils QA du qui le 
supporte donc de repérer l'import indélicat et sur le validateur JOSM (réduire 
les chances que l'upload soit fait). 

> Sachant que un point avec juste un name=* sans
> autre tag n'a aucune chance d'être utilisé ni représenté sur les rendus,
> ça donne une motivation pour explicitement en rajouter un.

Le rendu d'osm.org ne devrait rien afficher si place est vide :

https://github.com/gravitystorm/openstreetmap-
carto/blob/master/project.mml#L1163

-- 
sly (sylvain letuffe)
http://wiki.openstreetmap.org/wiki/User:Sletuffe

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


Re: [OSM-talk-fr] Revoir l'extraction des adresses du cadastre ( était [import lieux-dits (avec fixme)])

2014-08-02 Par sujet sly (sylvain letuffe)
Le samedi 2 août 2014 15:13:48, Tyndare a écrit :
> Je fais une proposition de nouveau format pour le fichier des noms de
> lieux-dits générés depuis le cadastre, voir un exemple ici:
> http://dl.free.fr/bOdG4FdS9

Note : dl.free.fr n'aime pas les bloqueurs de pubs, à désactiver si on veut le 
fichier.

> Les différences par rapport à avant:
> - fichier zip à part
> - tag place="" laissé vide
> - plus de fixme
> - fichiers nommés "lieux-dits*.osm" au lieu de "QUARTIERS*.osm"
> - LISEZ-MOI.txt

Je trouve ça très bien.

On pourrait relancer la question du tag source sur les objets plutôt que le 
changeset, mais je dévierais hors sujet, ce qui mériterait un nouveau sujet.

> - nouveau fichier limites_lieux-dits_-_NE_PAS_ENVOYER_SUR_OSM.osm qui
> contient juste des limites (un multipolygon par lieu-dit), je pense
> que c'est utile pour évaluer le nombre de maisons et donc remplir le
> tag place correctement (enfin pour ceux qui arrivent à comprendre le
> tag place...)

Miam... ça me semble avoir plus de potentiel que ça, quand je vois un "bois", 
ça me semble tout à fait adapté à du surfacique.
Je pousserais même à dire que de nombreux villages pourraient (aussi) être 
uploadé en surfacique.
Le risque étant qu'il se trouvera bien un gus pour nous uploader ce fichier 
sans retouche malgré l'énorme "NE_PAS_ENVOYER_SUR_OSM"
Ajout d'un tag "bidon" dans le but de plus facilement repérer les upload 
sauvages de ce fichier ?




> J'attends vos commentaires avant de potentiellement rendre ça dispo
> sur cadastre.openstreetmap.fr
> 
> Le 29 juillet 2014 13:38, Pieren  a écrit :
> > 2014-07-29 9:18 GMT+02:00 Christian Quest :
> >> Ce n'est pas tant le problème du tag fixme généré automatiquement, en
> >> fait il est bien pratique pour repérer/retrouver les imports fait en
> >> aveugle. Le véritable problème est bien l'envoi tel quel de données
> >> brutes qui ont besoin d'être revues et améliorées au préalable et qui
> >> ne l'on pas été.
> > 
> > Je pense qu'il faudrait recontacter les auteurs de ces fixme et leur
> > demander ce qu'ils comptent faire. Sans réponse après quelques jours :
> > revert. S'ils disent qu'ils n'ont pas le temps ou laissent le job a
> > d'autres : revert. En fait, ne garder que ceux qui s'engagent à
> > nettoyer leur(s) commune(s) dans un délai raisonnable.
> > Au delà des cas déjà présents, je ne voie pas d'inconvénient à
> > remettre en ligne ce genre d'extractions avec des fixme à condition de
> > bien avertir les gens qu'ils doivent nettoyer les fixme avant upload
> > et de mieux surveiller leur apparition éventuelle dans la base (avec
> > un revert plus rapide si les gens ne respectent pas la procédure)
> 
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr

-- 
sly (sylvain letuffe)
http://wiki.openstreetmap.org/wiki/User:Sletuffe

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


Re: [OSM-talk-fr] Travaux à Overpass API

2014-04-16 Par sujet sly (sylvain letuffe)
Le mercredi 16 avril 2014 08:58:02, Roland Olbricht a écrit :
> Bonjour,
> 
> http://overpass-api.de est rétabli.

Merci !

Je vais faire quelques tests pour voir comment se comporte overpass avec un 
disque SSD et quelle vitesse ont peut obtenir sur des récupérations de 
relations recursives...


-- 
sly (sylvain letuffe)
http://wiki.openstreetmap.org/wiki/User:Sletuffe

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


Re: [OSM-talk-fr] Suppression de landuse CLC - erratum

2014-04-03 Par sujet sly (sylvain letuffe)
On jeudi 3 avril 2014, sly (sylvain letuffe) wrote:
> il n'a pas continué les suppressions suite à ma réponse et celle de
> christian

erratum : "suite aux réponses de pieren, sylvain M. et moi" (histoire de vexer 
personne et ne pas impliquer christian ;-p )

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

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


Re: [OSM-talk-fr] Suppression de landuse CLC

2014-04-03 Par sujet sly (sylvain letuffe)
On jeudi 3 avril 2014, Pieren wrote:
> Mais il faudrait vraiment que quelqu'un (ou quelques uns) contacte le DWG
> pour mettre le hola à ce délire. 

Il est préférable, il me semble, de prendre contact en privé avec un 
contributeur que l'on juge indélicat lui demandant de cesser, si possible avec 
quelques exemples du problème et voir avec lui (surtout s'il a les compétences 
de paul) comment il serait possible de réaliser un revert total ou partiel de 
ses éditions.
Si, et seulement si cela n'avançait pas dans la direction souhaité par les 
deux parties, alors là, oui, en effet, solliciter l'aide du DWG.
Le faire sans discussion avec paul, c'est à mon avis une bonne méthode pour en 
énerver plusieurs...


> pnorman a la main très lourde et facile pour effacer ces landuse sous
> prétexte qu'ils sont issus de CLC malgré la discussion sur la liste import@

Le "malgré" me semble mal placé puisque il n'a pas continué les suppressions 
suite à ma réponse et celle de christian sur la liste dont tu parles.

Je lis ici quelques positions très catégoriques "vandalisme" "n'écoute pas" 
"inutile" alors qu'il me semble qu'il ne faut pas jeter le bébé avec l'eau du 
bain. Oui il a dérapé sur certains polygones, mais il a aussi (il me semble) 
fait beaucoup de couture de multipolygon et de comparaison avec bing qui me 
semble en partie bénéfiques.

Je peux me tromper, mais ça sent un peu la vengeance "parce que c'est lui"
Bien que de son coté, il n'a pas été malin non plus de venir provoquer les 
farouches gaulois sur leurs terres.

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

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


Re: [OSM-talk-fr] API OSM et BBOX

2014-04-01 Par sujet sly (sylvain letuffe)
On mardi 1 avril 2014, Pieren wrote:
> 2014-04-01 15:28 GMT+02:00 Mides :
> > Les données "erronées" sont remontées lors d'un appel API concernant la
> > région Centre : area[name="Centre"][admin_level=4].
> 
> Héhé... on peut facilement comprendre que d'autres régions du monde
> ont une région de niveau administratif "4" qui s'appelle aussi
> "Centre" ;-)

On dirait que c'est exactement ça :
http://www.openstreetmap.org/relation/2746031

Je ne pense donc pas que l'on puisse parler de données "erronées", au mieux de 
requête non conforme au souhait ;-)

> 2014-04-01 15:28 GMT+02:00 Mides :
> Par contre, comment peut on régler ce souci ?

autre option, utiliser oapi-fr.openstreetmap.fr :
https://wiki.openstreetmap.org/wiki/FR:Servers/api.openstreetmap.fr#Pour_la_France_seulement

Qui, du fait qu'elle ne couvre que la france, ne sortira que la région centre 
de france.

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

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


Re: [OSM-talk-fr] Apparition de "fixme=a verifier et associer a la bonne rue" non manuels

2014-03-06 Par sujet sly (sylvain letuffe)
On jeudi 6 mars 2014, Pieren wrote:
> 2014-03-06 10:16 GMT+01:00 sly (sylvain letuffe) :
> > date dernier ajout : 2014-03-02T19:09:43Z
> 
> J'en ai aussi trouvé des "récents" mais c'était des versions '2' dont
> la version '1' tombait sur la même période...

J'aurais dû donner des id :
http://www.openstreetmap.org/node/2698419295
http://www.openstreetmap.org/node/2698419298
http://www.openstreetmap.org/node/2698419299

ça aurait répondu à la question : "a-t-il pensé à ne prendre que les noeuds en 
version 1", dont la réponse est : oui.

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

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


Re: [OSM-talk-fr] Apparition de "fixme=a verifier et associer a la bonne rue" non manuels

2014-03-06 Par sujet sly (sylvain letuffe)
On mercredi 5 mars 2014, DH wrote:
> L'outil d'import des adresses du cadastre est architecturé et documenté 
> de telle manière qu'il devrait (should) être considéré comme une 
> contribution manuelle. 

Certainement pas par moi. Peu importe qu'on utilise ou pas le mot "manuel" je 
refuse de considérer que c'est exactement pareil que quelqu'un qui a tracé les 
12 numéros d'une rue après avoir pris en photo les plaques.
Le potentiel de nuisance est décuplé par le volume
La surveillance, les conseils, et, hélas, l'intransigeance sont, selon moi, 
encore plus de mise.

> Il s'agit encore de re-re-re-dire que les outils ne font pas tout. 

Certes, mais ça ne semble pas suffire, c'est pour ça que je pense qu'il faut 
faire attention, en amont, par ceux "qui ont le savoir technique" encore plus.

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

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


Re: [OSM-talk-fr] Apparition de "fixme=a verifier et associer a la bonne rue" non manuels

2014-03-06 Par sujet sly (sylvain letuffe)
On mercredi 5 mars 2014, sly (sylvain letuffe) wrote:
> On mercredi 5 mars 2014, Pieren wrote:
> > Pour l'instant, ça se passe dans 5 villes différentes:
> (...)
> 
> Merci pour cette recherche. Désolé de ne pas l'avoir fait moi même...

Si on ne peut plus se fier à pieren maintenant, où va-t-on moi je vous 
demande !

J'ai refais un peu de stats moins "doigt mouillé" donc :
4360 occurence de fixme=a verifier et associer a la bonne rue
date première appartition du tag : 2014-01-03T14:22:00Z
date dernier ajout : 2014-03-02T19:09:43Z

Donc, la source ne semble pas "tarie"

Dans 19 changesets par 4 utilisateurs
yoko99
jfnif
papyrus048_Intégration_cadastre
David Crochet

Dont le "score" de chacun est :
   3656 user="yoko99"
501 user="jfnif"
201 user="David Crochet"
  2 user="papyrus048_Intégration_cadastre"

Je n'arrive pas à trouver de tag pour ton 5ème utilisateur :
joedal-osm   http://www.openstreetmap.org/node/2610926572

J'ai "sondé aléatoirement" et les 19 changesets ne contiennent pas que 
l'import, ils ont été mélangés à d'autres modifications.

Ce qui rend le revert éventuel bien compliqué avec gros risque de perte. Le 
plus simple que j'envisage de faire (après avoir contacté) c'est de remplacer 
simplement tous les fixme=x par fixme:import:adresse=x

avec page rapide dans le wiki.

objections ?


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

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


Re: [OSM-talk-fr] Apparition de "fixme=a verifier et associer a la bonne rue" non manuels

2014-03-05 Par sujet sly (sylvain letuffe)
On mercredi 5 mars 2014, Tyndare wrote:

> Si on renomme le fixme, il n'y a plus rien de visuel dans JOSM qui
> permette et encouragerais de corriger les données avant envoie.

A defaut d'une option dans JOSM pour afficher ces fixme:xy avec un "F" orange 
;-) 
il y a déjà la recherche.

De plus, un tag genre "a_retirer_avant_import_et_après_correction=yes" permet 
aussi de trouver les "oublieurs"


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

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


Re: [OSM-talk-fr] Apparition de "fixme=a verifier et associer a la bonne rue" non manuels

2014-03-05 Par sujet sly (sylvain letuffe)
On mercredi 5 mars 2014, Tyndare wrote:
> mais qu'est-ce qui est utilisé habituellement pour les données générées par
> des outils ?

Je ne crois pas qu'il y ait de consensus à ce propos, alors autant en inventer 
un genre fixme:import:adresses=y/z/t qui soit spécifique à ce type ou à cet 
import.

J'ai bien conscience que le but du fixme c'est de faire apparaître le petit 
"f" rouge dans JOSM, dans les alertes osmoses et dans les outils qui mettrons 
en avant ces choses à corriger.
Mais ça se mort la queue, car, si, par exemple, il devenait consensuel 
d'utiliser fixme pour tout type de corrections à faire, et qu'on autorise la 
masse des post-import, alors ce tag perdrait de l'intérêt (en tout cas à mon 
sens) et j'en proposerais alors un autre, style "fixme2=*" pour les choses à 
réparer uniquement déclarées manuellement et on peut imaginer que les outils 
suivraient (en tout cas ceux que je gère) car ce sont (peut-être) ce type 
d'erreur qu'ils veulent mettre en avant.

C'est donc à mon avis dans l'autre sens qu'il faut traiter le cas :
inventer le tag, puis l'utiliser, puis proposer des outils pour les repérer.



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

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


Re: [OSM-talk-fr] Apparition de "fixme=a verifier et associer a la bonne rue" non manuels

2014-03-05 Par sujet sly (sylvain letuffe)
On mercredi 5 mars 2014, Christophe Merlet wrote:

> Ce fixme a t'il vraiment un intérêt ici alors qu'il suffit de rechercher
> les noeuds addr:housenumber sans addr:street ou n'appartenant pas à une
> relation associatedstreet.

D'après un des exemples trouvés par pieren, ça appartient bien à une relation, 
mais ça dit "vérifier si c'est la bonne"
donc oui, on peut comprendre le sens (que je ne conteste pas) de ce fixme  
mais ce qui, moi, me déplaît c'est de mettre ça dans un tag qui est utilisé 
habituellement pour des déclaration manuelles

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

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


Re: [OSM-talk-fr] Apparition de "fixme=a verifier et associer a la bonne rue" non manuels

2014-03-05 Par sujet sly (sylvain letuffe)
On mercredi 5 mars 2014, Pieren wrote:
> Pour l'instant, ça se passe dans 5 villes différentes:
(...)

Merci pour cette recherche. Désolé de ne pas l'avoir fait moi même...

> Pour tous, ça s'est fait il y a deux mois.

On peut donc supposer que "la source" s'est tarie et que le problème est donc 
isolé à 5 cas, donc moins grave.

Au choix, on peut :
- ne rien faire, et ça fait 4000 fixme qui moisirons
(perso, m'en fiche, c'est pas dans un coin ou j'ai des raisons d'aller !)
- contacter ces 5 utilisateurs et leur proposer[1] :
* qu'ils corrigent les fixmes eux
ou
* faire un revert sur le(s) changesets concernés

[1] je veux bien m'en charger si cette action fait l'unanimité

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

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


[OSM-talk-fr] Apparition de "fixme=a verifier et associer a la bonne rue" non manuels

2014-03-05 Par sujet sly (sylvain letuffe)
Bonjour,

Je constate que depuis peu de nouvelles valeurs au tag fixme 
sont entrés en "quantité non négligeable" :
http://taginfo.openstreetmap.fr/keys/?key=fixme#values

La première annonce qui en parle semble avoir été sur cette 
liste même, visible ici :
http://gis.19327.n5.nabble.com/Service-addr-housenumber-et-doublon-d-information-automatisation-td5791623.html

J'avais indiqué alors :
*
Qu'éventuellement un tag comme fixme=* serve temporairement afin de faire le 
nettoyage qui doit être fait *avant* l'import, pourquoi pas. Mais je suis 
contre un 
usage de fixme=* automatique qui va encombrer la base car cela noie les autres 
fixme : tout le monde n'a pas nécessairement envie de se voir "fortement 
incité" a 
corriger les imports mal fichus des autres.
Et, comme il s'en trouvera toujours un pour cliquer sur "envoyer" sans 
controler, 
je suggère l'usage d'un autre tag. Idéalement un tag qui indiquerait a JOSM de 
refuser l'upload tant qu'il en reste un, ou sinon, au pire, un autre au format
unique et différenciable comme :

fixme:import-adresses=batiment le plus proche a 10m, au dessus de la limite de 
3m
-- 
sly
*

Et j'ai bien l'impression que c'est ce qu'il est en train de se passer.

Je réitère donc ma demande pour trouver une autre solution à ces fixme.
Perso, je les utilises sur mon gps comme point terrain à vérifier, et ça ne 
m'intéresse pas
de le voir se remplir de fixme non manuels

Je comprends que "c'est principalement la faute de celui qui importe mal" mais 
dans les faits
ben, ça fait comme résultat que ça perturbe un tag au delà de ceux qui sont 
concernés
par les adresses.

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

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


Re: [OSM-talk-fr] Service addr:housenumber et doublon d'information - automatisation

2014-01-04 Par sujet sly (sylvain letuffe)



>> - mettre des fixme partout ailleurs.
>>
>
>Personnellement, la façon dont je procède pour importer les données,
>c'est
>d'utiliser le tag fixme pour identifier les éléments que je n'ai pas
>encore
>analysés/intégrés correctement

Qu'éventuellement un tag comme fixme=* serve temporairement afin de faire le 
nettoyage qui doit être fait *avant* l'import, pourquoi pas. Mais je suis 
contre un usage de fixme=* automatique qui va encombrer la base car cela noie 
les autres fixme : tout le monde n'a pas nécessairement envie de se voir 
"fortement incité" a corriger les imports mal fichus des autres.
Et, comme il s'en trouvera toujours un pour cliquer sur "envoyer" sans 
controler, je suggère l'usage d'un autre tag. Idéalement un tag qui indiquerait 
a JOSM de refuser l'upload tant qu'il en reste un, ou sinon, au pire, un autre 
au format unique et différenciable comme : 

fixme:import-adresses=batiment le plus proche a 10m, au dessus de la limite de 
3m
-- 
sly

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


Re: [OSM-talk-fr] Comcom Maker

2013-12-27 Par sujet sly (sylvain letuffe)
Le vendredi 27 décembre 2013 17:14:11, Philippe Verdy a écrit :
> S'il ne peut pas tenir la charge à cause de défauts matériels
> (refroidissement, alimentation, câblage ou connecteurs défectueux, mauvais
> contacts, défaut de montage, problèmes de barrettes mémoire, bogues de
> firmwares ou de BIOS, problème de mise à jour de l'hyperviseur, etc.)

C'est en effet un problème lié en partie à ce que tu décris (mais pas tout à 
la fois heureusement) en fait, cette machine dispose d'une carte mère assez 
ancienne et à cause de vibrations anormales dans la super structure du 
bâtiment (peut-être liées, à des micro vibration du sous sol de la plaque 
eurasiatique et une expert en tecktonik des plaques doit nous le confirmer)

En bref, quoi qu'il en soit, régulièrement, des puces de cette carte mère 
perdent le contact avec les pistes et le contrôleur disque devient devient 
inaccessible partiellement au driver SATA de linux qui passe alors en mode 
dégradé voir carrément c'est la panique dans le kernel. La dernière fois une 
puce à carrément sautée (comme certaines puces d'ailleurs) alors forcément !

Ce qu'on fait c'est donc des rotations des câbles sur ceux qui marchent 
encore, et c'est assez pénible car au final on se retrouve avec plein de 
nœuds.


> Je ne connais pas les lieux de ce datacenter Free, mais certains que j'ai
> visités (chez Level3 ou les systèmes boursiers/bancaires, ou les systèmes de
> l'armée par exemple) sont très stricts sur les conditions d'accès aux salles

Plus encore que tu ne l'imagine ! Jocelyn est parti il y a 5 jours maintenant 
pour faire des nœuds avec les câbles, et on est toujours sans nouvelles de 
lui. On suppose qu'il avait oublié sa pièce d'identité et qu'il est maintenant 
séquestré dans le datacenter par l'équipe de sécurité. Vraiment, ils ne 
rigolent pas là bas. On espère le revoir en un seul morceau sans quoi, je ne 
sais pas ce que l'on va dire à sa famille.

Peut-être que pour 2014, certains prendrons de bonnes résolutions, eux le 
relâcher et d'autres ce qui doit être fait.



-- 
sly (sylvain letuffe)
http://wiki.openstreetmap.org/wiki/User:Sletuffe

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


Re: [OSM-talk-fr] Comcom Maker

2013-12-27 Par sujet sly (sylvain letuffe)
Le vendredi 27 décembre 2013 11:56:37, Frédéric Rodrigo a écrit :
> Non, le serveur (osm7) n'est toujours pas en état pour recevoir la base
> osm2pgsql france dont a besoin comcom maker. Le problème est matériel.

A ce propos d'ailleurs, osm7 est certes toujours dans un état douteux, mais on 
a maintenant à disposition deux bases osm2pgsql monde presque pas loin d'être 
en redondance l'une de l'autre. Et vu les monstres que c'est, avec du ssd, la 
perf sera de toute façon plus importante que ce que pourrait faire osm7

N'est-il alors pas plus judicieux d'interroger ces bases plutôt qu'une france 
only ?
En poussant un peu le raisonnement, est-il pertinent de remettre en route une 
base osm2pgsql france ?

De mon coté, pour donner un exemple, j'ai remis en service tout ce que je 
gérais et qui utilisait la base france pour n'utiliser qu'une base monde.
Base monde accessible directement par le réseau, ce qui est aussi simple ou 
presque, et finalement plus souple car en cas de maintenance sur une des deux 
base, la bascule vers l'autre se fait en changeant juste l'adresse de 
pointage, voire sans, si on utilise "osm2pgsql-monde.openstreetmap.fr"



-- 
sly (sylvain letuffe)
http://wiki.openstreetmap.org/wiki/User:Sletuffe

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


Re: [OSM-talk-fr] way des limites administratives

2013-12-27 Par sujet sly (sylvain letuffe)
Le vendredi 27 décembre 2013 10:53:31, Christophe Merlet a écrit :
> On complète avec boundary=administrative + admin_level=[0-10] sur les
> limites administratives terrestres et on supprime border_type (mapnik ne
> s'en sert pas entre autres)
> 
> Les natural=coastline sans aucun boundary.
> 
> Au passage, on supprime les name lorsque le way n'est que boundary ?
> Vos avis ?

Mon avis est le suivant : ne faisons rien d'automatique, voire, ne faisons 
rien, tout court, dans la base osm, mais documentons une pratique comme 
"suggérée" sur le wiki.

Voici mon raisonnement :
En partant de l'hypothèse selon laquelle les tags boundary=x admin_level=y 
name=z border_type=a contiennent une information qui a intérêt à être présente 
sur les relations (factorisation, moins de risque d'incohérences) et non sur 
les ways de frontières.
Alors, faire des efforts pour rendre homogène et utilisable une donnée sur les 
ways va inciter tous les concepteur de logiciel à utiliser (par "simplicité") 
l'information se trouvant sur les ways plutôt que reconstruire les relations 
et utiliser leur information.
Puis, par la chaine cyclique de la poule et de l'oeuf, les mappeurs vont 
devoir maintenir à jour ces informations et donc y passer du temps parce que 
"le logiciel bidule utilise le tag is_in, alors pas le choix, je suis obligé 
de le mettre partout"*
N'incitant alors pas les sus-cité à améliorer leurs logiciels. On ne sait pas 
au final qui aura commencé, mais on sera tous à devoir gérer des incohérences 
d'un modèle mal fichu.

Alors ne faisons rien, et suggérons, sur les pages wiki appropriées, comme :
http://wiki.openstreetmap.org/wiki/Boundaries
et autre
des phrases du style :
"Si vous avez bien renseigné les informations sur les relations, les ways de 
frontières peuvent tout à fait rester sans aucun tag puisque cette information 
est contenu dans les relations, certains contributeurs mettaient un 
boundary=administrative pour que certains éditeurs osm puissent représenter 
avec la bonne couleur le chemin et ainsi plus facilement savoir à quoi il 
servait, mais cette pratique à moins de raison d'être puisque les éditeurs 
modernes (josm) savent maintenant tirer partie de cette information dans la 
relation et cela nous évitant un travail fastidieux qui consiste à répéter ce 
qui se trouve dans la relation [En savoir plus]"




* toute ressemblance avec un cas avéré de serait que fortuit, je donne juste 
un exemple "choc"


-- 
sly (sylvain letuffe)
http://wiki.openstreetmap.org/wiki/User:Sletuffe

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


Re: [OSM-talk-fr] Harmoniser les codes postaux -> postal_code=*

2013-12-22 Par sujet sly (sylvain letuffe)
Le dimanche 22 décembre 2013 15:01:17, Vincent de Château-Thierry a écrit :

> > Je suis d'avis d'utiliser partout addr:postcode
> > Il y a un schéma relativement complet concernant l’adressage, utilisons
> > -le.
> 
> +1

+1

-- 
sly (sylvain letuffe)
http://wiki.openstreetmap.org/wiki/User:Sletuffe

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


Re: [OSM-talk-fr] Convertir les données de type polygones en noeud (gpx, csv, osm) ( était : umap problème de =?iso-8859-1?q?_requ=EAte?=)

2013-12-15 Par sujet sly (sylvain letuffe)
Le samedi 14 décembre 2013 22:50:41, Vincent Pottier a écrit :
> Ça peut se faire ?

fait.

ps: ayant dérivé HS plutôt pas mal, je me permet de migrer sur dev-fr pour 
plus de détails

-- 
sly (sylvain letuffe)
http://wiki.openstreetmap.org/wiki/User:Sletuffe

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


Re: [OSM-talk-fr] umap problème de requête

2013-12-14 Par sujet sly (sylvain letuffe)
Le samedi 14 décembre 2013 12:19:14, Christian Quest a écrit :
 
> Ce qui manque c'est un "out node" qui sortirait un noeud artificiels
> correspondant au centroid de la géométrie d'un way ou des objets
> appartenant à une relation.

L'Overpass API n'a pas ça, et je ne suis pas sûr que, conceptuellement, ça 
soit son rôle, ça serait comme demander du géoJSON à postgis * ou une page 
html à un serveur de base de donnée !

Mais osmconvert dispose de cette option --all-to-nodes : 
http://wiki.openstreetmap.org/wiki/Osmconvert#Dispose_of_Ways_and_Relations_and_Convert_them_to_Nodes
qui converti ways et relations en un noeud d'id bidon avec report des tags

en gros, un petit wrapper entre l'api et l'outil d'affichage et hop ça le 
fait. Mais... c'est pas ce que j'aurais déjà fait là ?
http://wiki.openstreetmap.org/wiki/FR:Servers/api.openstreetmap.fr#Export_avec_simplification_des_ways.2Frelations_en_noeuds_.28en_test.29
https://github.com/osm-fr/osm2node

ha si ;-)

Et rajouter la syntaxe oapi en GET doit se faire sans trop de difficultés



* oui, je sais, et ça m'étonne toujours

-- 
sly (sylvain letuffe)
http://wiki.openstreetmap.org/wiki/User:Sletuffe

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


Re: [OSM-talk-fr] Metadonnées sur celles d'OSM et comment informer les autres contributeurs ?

2013-12-12 Par sujet sly (sylvain letuffe)
Le jeudi 12 décembre 2013 11:10:26, Pieren a écrit :
> La seule solution actuellement
> supportée par tous les outils : c'est mettre un way virtuel avec une
> note : "cet objet n'existe plus depuis 1/1/2013", par exemple.

J'avoue le faire parfois, mais là, c'est vraiment vraiment pas élégant...

Si l'objet n'est pas trop étendu, un simple noeud à l'avantage d'être moins 
envahissant


> Je pense que la seule solution qui marche est de rajouter ces
> informations, même générales, directement sur tous les objets
> concernés. 

beurk...
C'est peut-être bien celle qui a le plus de chance d'être lue mais à long 
terme, ces "traces" vont traîner encore plus car elles sont nombreuses.

> Par exemple, iD affiche bien les tags "note" mais pas les
> "fixme". 

Arghhh, tu m'en apprend une là. Si les éditeurs les "cachent sous le tapis" 
exprès, là, on perd tout l'intérêt de prévenir les autres par ce moyen. On a 
pas fini de faire et défaire et refaire.
Cacher une méthode discutable, pourquoi pas, mais seulement si on est en 
mesure de proposer un équivalent.
C'est peut-être juste un bug/oubli, dès que je trouve un quad core pour lancer 
iD et constater le problème de visu j'ouvrirais un ticket.


-- 
sly (sylvain letuffe)
http://wiki.openstreetmap.org/wiki/User:Sletuffe

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


Re: [OSM-talk-fr] Mettre en place un script d'extraction des données de transports en commun sur OpenStreetMap.fr ?

2013-12-11 Par sujet sly (sylvain letuffe)
Le mercredi 11 décembre 2013 22:35:08, Thomas Gratier a écrit :
> Salut,

hello,

> Il y a les scripts sh qui vont bien. Vous pensez qu'il serait opportun de
> mettre un script qui fait des extractions régulières sur un serveur Fr un
> peu comme les extractions des communes françaises?

Pourquoi pas.

-- 
sly (sylvain letuffe)
http://wiki.openstreetmap.org/wiki/User:Sletuffe

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


Re: [OSM-talk-fr] Metadonnées sur celles d'OSM et comment informer les autres contributeurs ?

2013-12-11 Par sujet sly (sylvain letuffe)
Le mercredi 11 décembre 2013 21:48:53, Ista Pouss a écrit :
> Autant que je puisse comprendre ta proposition, il me semble qu'il serait
> mieux de faire une traçabilité des éditions ; 

Peut-être en effet. S'il s'avère que chaque remarque concernant la qualité 
d'un objet s'accompagne d'une édition alors pourquoi pas. Mais je les vois 
plus comme un complément.
"attention le tracé est décalé car bing décalé" "ma trace gps était pourri, 
voici tout ce que j'ai pu faire pour placer ce chemin" vont super bien avec 
les tags du changeset quand on vient de le tracer et il n'est plus besoin 
d'indiquer ça en rapport à un objet.
Toutefois, on peut voir certains cas ou ça peut être : "je suis passé par ce 
chemin x et je n'ai vraiment pas vu ce chemin qui part à gauche, ces mes yeux 
ou quelqu'un confirme ?"
Là, on a pas trop d'édition à part la remarque elle même portée sur le chemin.
Ce fixme a une validité jusqu'a ce qu'une note vienne le convertir :
"si si, c'est bien tes yeux, il est dernière le panneau blanc"


Note: L'accessibilité à la traçabilité des éditions est réclamée depuis 
longtemps, les tags de changeset sont là pour ça, la structure est prête, mais 
les appels permettant aux éditeurs de faire une synthèse de tout ce qui est 
arrivé à un objet n'est pas encore bien là : dans la vie d'un objet en version 
10, si à la version 3 je suis intervenu avec un changeset disposant de 
comment="editition géométrique totalement refaite avec une trace gps car bing 
à la ramasse"
je peux être sûr, en l'état actuel, que le prochain qui passe dans le coin n'a 
presque aucune chance de voir mon commentaire et va refaire la géométrie 
mordiou !
avec une note sur l'objet, c'est pas le mieux placé, mais je pense avoir plus 
de chance d'être lu.


> C'est déjà pas mal fait : par le commentaire, ou par la page wiki d'un
> projet d'édition, etc. 

"pas mal fait" disons qu'on a les outils pour le stocker, on a juste pas les 
outils pour le consulter ;-)

> Dans le cas d'une page wiki, il faudrait mettre dans
> la base osm le lien vers cette page (la seule métadonnée, finalement).

Clairement une bonne idée, espérons juste que la page wiki ne change pas de 
nom mais c'est l'idée. Je suis adepte de ça, et devinez où j'y colle ?
http://www.openstreetmap.org/relation/446829
et oui, tags de l'objet, car si je le mets dans url=* du changeset, c'est hors 
vue (et pas modifiable)


> Les méta-données, c'est un truc d'informaticien ; 

Celui qui a exprimé un besoin ne semblait pas être un informaticien, j'ai peut 
être mal joué en utilisant ce mot mais je voulais dire "où est-ce que je mets 
une info que j'ai qui concerne telle info de cet objet"



-- 
sly (sylvain letuffe)
http://wiki.openstreetmap.org/wiki/User:Sletuffe

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


Re: [OSM-talk-fr] Metadonnées sur celles d'OSM et comment informer les autres contributeurs ?

2013-12-11 Par sujet sly (sylvain letuffe)
Le mercredi 11 décembre 2013 21:26:43, Stéphane Péneau a écrit :

> > * les outils d'analyse des données vont devoir recourir, par des critères
> > géographique de proximité, à une autre base de donnée séparée.
> 
> Je ne vois pas pourquoi ces outils devraient piocher dans cette base
> séparée, ils n'en ont pas besoin pour faire leurs analyses, et ces infos
> leurs sont inutiles.

Je n'ai peut-être pas été clair quand j'ai dis "les outils" mais je parlais 
des outils capable de traiter l'info que tu veux justement rentrer.

On refait : il est question de savoir où mettre l'info "cette frontière de 
commune est décalée car la planche du cadastre l'est" et comment l'exploiter.

Si tu la mets dans une base x indépendante de la base osm, l'outil qui doit 
analyser (au sens large : classer, afficher, rendre disponible) cette info 
aura besoin d'accéder à cette base x, obligé.
Et comme il doit faire le rapprochement avec la frontière dont il est 
question, il lui faut un accès à la base osm aussi.


> Je ne comprends pas. En quoi une "note" formée d'un polygone avec pour
> info "Attention cadastre complètement décalée, Bing 2013 est ok" a
> besoin d'avoir un lien avec une donnée en particulier.

là non, mais je ne parlais pas de ce cas, j'avais coupé mon argumentation en 
deux temps :
* quand l'info se rapporte à un seul objet
* quand l'info se rapporte à un secteur

 
> J'ai en tête l'exemple de 5 ou 6 communes voisines dont le cadastre
> raster est décalé, et une frontière départementale avec. Je le mets où
> le fixme ? Si je décide d'un emplacement, je suis sur à 99% que sur une
> zone aussi vaste, il ne sera jamais vu par la personne qui pourrait en
> avoir besoin.

Tout à fait d'accord. Comme dis dans un autre mail, la technique du fixme qui 
pendouille à un point pour parler d'une zone est très merdique. (vu que tu 
sors des chiffres tiré du chapeau, moi aussi ;-) ) Mais en choisissant d'en 
faire une note à la place, tu as 99.5% de chance qu'elle ne soit jamais vu 
cumulé à 50% de chance qu'elle soit fermée "n'est pas un problème sur la 
carte"
La question reste donc ouverte, ou mettre cette info sur la zone ?
Comme disait ailleurs un stéphane, "si j'étais dictateur d'osm, ça serait 
comme ça"
Mais je ne le suis pas, je ne sait pour l'instant qu'en faire de cette info, 
donc je choisi le 1% de chance qu'elle soit lue ;-) (ou tant pis, je n'en fais 
rien le plus souvent et c'est perdu)


> > au niveau mondial si on veut espérer que ça puisse être utilisé ailleurs
> > que dans notre coin et donc devenir du temps jeté à la poubelle.
> 
> Tu crois vraiment ? Pourtant Osmose n'existait il y a encore peu de
> temps que sur le territoire français.

Tu as en partie raison, mais ton exemple n'est pas terrible. osmose ne dispose 
pas (à confirmer) de source de donnée propre (à part les faux positifs)
La principale donnée d'osmose, c'est la base osm elle même et des données 
tierces. Donc à comparer avec une base de méta donnée originale (au sens 
"source d'info" du terme) que tu veux constuire, c'est difficile de comparer.
Je propose plutôt de comparer à openstreetbugs, c'est devenu quoi le contenu 
de ça au fait ?

> Dans ce cas, il faut que ces notes ou fixme soient beaucoup, beaucoup,
> beaucoup plus visibles. Qu'on puisse les classifier et les filtrer.

La poule et l'oeuf, si c'est mal utilisé, peu utilisé, mal classé, peu d'outil 
en profiterons, c'est donc par là qu'il faut commencer.
cqfd ?

une tentative ?
http://wiki.openstreetmap.org/wiki/FR:Servers/layers.openstreetmap.fr#fixme.2Fnotes_overlay



-- 
sly (sylvain letuffe)
http://wiki.openstreetmap.org/wiki/User:Sletuffe

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


Re: [OSM-talk-fr] Metadonnées sur celles d'OSM et comment informer les autres contributeurs ?

2013-12-11 Par sujet sly (sylvain letuffe)
On mercredi 11 décembre 2013, V de Chateau-Thierry wrote:
> En ce sens, je suis plutôt réticent à l'idée que ces informations soient
> stockées dans OSM (cf. la suggestion de sly). 

ça dépend de ce que tu entends par "stockées dans osm", mais moi, je suis 
plutôt pour.
Stocker cette info dans une base annexe, de la communauté tartampion fr, ça va 
pas attirer les foules et il faudra des lustres pour que ça soit accessible 
dans les éditeurs.

J'accorde toutefois qu'un noeud sans existence physique avec un 
fixme="attention, arrêtez de corriger mes routes dans le coin, bing n'est PAS 
bien callé. STOP armchair mapping, go out and map !"

N'est pas super élégant, mais c'est le moins pire que je vois aujourd'hui, qui 
va lire le wiki qui contiendrait cette info ? qui va lire les notes de la page 
d'accueil osm.org (ou qui a le plugin kivabien) ? 
Mon avis changera bien entendu sitôt qu'un chouette remplaçant viendra mettre 
son nez par là.


> Les divergences que je vois par rapport aux Notes telles qu'on les connaît :

+1
Et j'ajoute : pas de possibilité de ranger les notes (je suis en train de 
bosser sur le bâti, j'ai pas envie d'avoir les notes qui disent "ici un cani-
chiotte à mapper" mélangées aux infos, mauvais calage)

Pas d'export possible pour faire des analyses, afficher ça dans mon garmin, 
etc.

Bref, je pense juste que le besoin n'est pas le même, les deux ont leurs sens. 
Mais s'en inspirer, pourquoi pas, mais là, maintenant, ben, c'est yaka.

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

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


Re: [OSM-talk-fr] Metadonnées sur celles d'OSM et comment informer les autres contributeurs ?

2013-12-11 Par sujet sly (sylvain letuffe)
On mercredi 11 décembre 2013, Christian Quest wrote:
> Et pourquoi ne pas avoir un simple node avec un note=* ou un fixme=* ?
> 
> Je l'ai déjà fait à quelques endroits et je ne vois pas quel problème ça
> pose.

Un simple noeud me semble en effet une option (même si ça pendouille dans le 
vide et qu'il faut bien voir le petit "f" sous josm et penser à le lire), pour 
que ça soit mieux, il faudrait que des outils suivent. (le f de josm est 
vraiment petit, et noir !, le note, lui, n'est pas visible)

A l'opposer d'autres on choisi de le mettre sur chaque objet :
http://www.openstreetmap.org/way/248861868

C'est pas que ça soit fondamentalement incorrect, en effet, pour chaque 
bâtiment dans ce cas il faudrait repasser plus tard, mais alors tout outil qui 
affiche les notes deviens juste inutilisable dans le secteur car ça va remplir 
l'écran.

Ici encore, une évolution avec un rangement par catégories informatiquement 
identifiable peu être un plus.


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

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


[OSM-talk-fr] Metadonnées sur celles d'OSM et comment informer les autres contributeurs ?

2013-12-11 Par sujet sly (sylvain letuffe)
(je split ce sujet, ça va partir en HS en rapport au thème initial et ça 
déborde selon moi de la simple question des qualité des limites de communes)

On mercredi 11 décembre 2013, Stéphane Péneau wrote:
> Que peut-on remonter comme informations pertinentes :
> - Le cadastre qui est décalé sur une commune, ou une zone de la commune
> - Des zones n'appartenant à personne, ou à plusieurs communes à la fois
> - L'imagerie X qui est décalée
> - D'autres cas auxquels je ne pense pas

Oulla, tu vas bien plus loin que je ne l'imaginais avec ton exemple d'avant. 
Cela va au delà d'une limite en particulier vu que tu abordes la question 
d'imagerie et même "d'autres cas auxquels tu ne penses pas ;-)"

Je ne sais pas si on trouvera un système unique pour tout et si on y arrive 
pour tous les cas, rien n'empêche d'exploiter plusieurs outils.
 
> Si l'usage des tags "note", "fixme", ou "comment" pourrait 
> éventuellement être utilisés dans certains cas, ils souffrent d'un gros 
> inconvénient : Ils sont attachés à un élément de la base Osm.

En effet. Et si les notes, ou tout remplacement sur le même principe pourrait 
régler en partie ce cas. Le cas d'une frontière à "commenter" va être détachée 
de sa note qui "pendouillera dans le vide"
exemples : 
* les outils d'analyse des données vont devoir recourir, par des critères 
géographique de proximité, à une autre base de donnée séparée.
* Les éditeurs rawedit, josm, merkatoor, vespucci, iD et autres vont devoir 
être adaptés pour aller piocher dans cette nouvelle base et permettre de la 
remplir pour les besoins qui ne sont pas le "ça marche pas"

Autant dire que les chances sont minces de voir tous ces outils converger et 
être capable de garder le lien vers la données dont il est question

Je défend donc l'idée (je radote ?), mais pas dans tous les cas, de placer les 
métadonnées à coté des données, dans la même base et au plus possible éditable 
avec les mêmes méthodes que les données elles même.

En clair, je défend l'idée des notes et fixme et leur copains (faute de 
mieux*) afin de montrer à "ceux d'en haut" que les notes ne peuvent à elles 
seules tout régler, et donc de faire progresser les outils dans ce sens pour 
mieux les exploiter.


> - Si le cadastre est décalé, j'ajoute cette information sur quoi ? Les 
> rues ? Le bâti ? Le chef-lieu ? Partout ?

Partout, surtout pas, ça serait "spammer les objets" et faire s'éffondrer 
l'utilité du système.
Soit un point isolé avec seulement un fixme=truc décallé
ou les notes, là, pourquoi pas

> Osmose, Layer, Tile, ou autres, savent mettre en avant des informations 
> qu'on leur a données, mais ici le problème est de savoir comment et où 
> stocker ces informations qui viennent des contributeurs.

Les notes, pourquoi pas, mais pas sous cette forme (manque de catégorie, pas 
d'export pour l'instant). Dans l'état actuel, tenter de les utiliser 
correctement pour ton besoin dans les outils que tu cites est difficile ou 
alors, ça va juste les afficher tel un marqueur et ça, c'est déjà fait sur 
osm.org, on arrivera rien à apporter de plus.

> Voici ce que j'imaginais :
Oui, c'est possible.
Mais je ne m'y risquerais pas tant les chances sont fortes que tout le monde 
s'en foute. Il faut d'abord l'envisager avec d'autres communautés que la fr, 
au niveau mondial si on veut espérer que ça puisse être utilisé ailleurs que 
dans notre coin et donc devenir du temps jeté à la poubelle.

L'avantage du système des notes et fixme & co, c'est que c'est une manière de 
faire le forcing, c'est déjà utilisable, déjà possible de saisir et c'est déjà 
possible d'utiliser.
Lorsque cette méthode détournée sera utilisée en masse, il ne sera plus 
possible qu'on me réponde (on me l'a dit) "personne n'en veut"
A partir de là, on aura une base réelle pour discuter du besoin avec du 
contenu.
Contenu qu'il sera alors possible de déplacer vers le nouveau système.

Oui, quelque part, je milite sous la forme "grève des notes, occupation de la 
rue avec des fixme ;-)".


 
> Par contre, je suis bien incapable de mettre en place tout ça.
> 
> Tu disais :
> 
> >C'est quand même bête de voir cette recherche poussée et pertinente perdue
> >dans la masse des "ça marche pas" non ?
> 
> C'est avant tout parce que je trouve dommage de perdre toutes ces 
> informations que j'ai lancé le sujet. Durant les 7 mois intensifs de 
> tracage de limites communales, des cas bizarres, des erreurs, des 
> éléments intéressants, on en a rencontré pas mal. On en a parfois 
> discuté sur le module de chat de Mapcraft, mais en l'état, ces infos ne 
> sont même pas mélangées dans la masse des "ça marche pas", elles sont 
> tout simplement perdues.
> 
> StephaneP
> 
> 
> > En effet ;-) (En tout cas pour moi)
> > Ce n'est pas que ça ne m'intéresse pas, mais je trouve que tu n'as pas 
donné
> > assez de cas réels d'utilisation, de quelle forme ça pourrait prendre ni 
si tu
> > es prêt à coder quelque chose pour la mise en place et/ou si tu as fais le
> > tour de ce qui 

Re: [OSM-talk-fr] Controle qualité des limites administratives.

2013-12-11 Par sujet sly (sylvain letuffe)
Le mercredi 11 décembre 2013 10:23:37, Stéphane Péneau a écrit :
> Hello Mister "Notes",

note : je suis assez plutôt pas mal d'accord avec M. notes

> J'ai l'impression que mon idée ne déchaine pas les foules.

En effet ;-) (En tout cas pour moi)
Ce n'est pas que ça ne m'intéresse pas, mais je trouve que tu n'as pas donné 
assez de cas réels d'utilisation, de quelle forme ça pourrait prendre ni si tu 
es prêt à coder quelque chose pour la mise en place et/ou si tu as fais le 
tour de ce qui existait pour lister :
- osmose plugin x : fonction ressemble mais manque bidule
- sur layers.openstreetmap.fr : l'idée y est mais ne traite pas x, donc pas 
adapté au cas y
- ...

En bref, ça ressemblait un peu trop à un truc vague genre "hé ho, quelqu'un 
peut me faire un outil pour ce qui vient de me passer par l'esprit, je lui 
dirais ensuite si c'était une bonne idée"
note: je ne dis pas que c'est ce que tu as dis, mais je te dis ce que j'y ai 
lu.
Le fait que tu ré-insiste plusieurs fois peut éventuellement cacher de 
l'energie enfermée, alors je tâte le terrain pour la libérer ;-)


> > En attendant, est-ce qu'on peut imaginer reprendre le système des 
> > notes ajoutées sur la carte générale, mais pour signaler un problème 
> > qui ne peut être résolu par nous même ?

Perso, j'aime pas. Pour la remarque qui a déjà été faite sur les catégories 
qu'il n'y a pas et parce que les notes ont une autre cible (l'anonyme de 
passage qui aime bien dire "ça marche pas" en 3 clic)
Or, des infos détaillées et précises genre "le no-man's land communal entre 
ces deux communes a pour cause une erreur de recopie du PV d'assemblé de 1973 
.blabla ayant conduit à une incohérence toujours non réglée à ce jour 
(2014) qu'il faudrait trancher en reprenant les archives papier à récupérer à 
la préfecture de x"

C'est quand même bête de voir cette recherche poussée et pertinente perdue 
dans la masse des "ça marche pas" non ?
De plus, avec un certain formalisme que seul des contributeurs pourront 
exploiter au mieux, je pense que les notes, pour ce besoin, sont à laisser de 
coté.

> > Des notes qui ne seraient pas visibles sur la carte osm.org mais sur 
> > Osmose, ou tile.openstreetmap.fr ou autre, et visibles dans Josm à 
> > l'aide d'une version locale du plugin "Notes".

40 lignes de baratin plus tard, je défend l'idée des méta-data au sein même de 
la base osm.
De la même façon que chaque article wikipedia dispose de sa talk page juste à 
coté, dans la même interface web et éditable avec les mêmes outils, je défend 
l'idée des tag de "donnée sur la données" (metadonnées) sous forme de tags.

Lesquels ? quel format ? pour quel(s) cas ? comment les utiliser ?
ces questions restent en suspend et le wiki donne des tas de pistes mais sans 
page fédératrice :

On la commence :
http://wiki.openstreetmap.org/wiki/Osm_Metadata
?

http://wiki.openstreetmap.org/wiki/Fixme
http://wiki.openstreetmap.org/wiki/Key:note
http://wiki.openstreetmap.org/wiki/Internal_quality
http://wiki.openstreetmap.org/wiki/Proposed_features/Noname

et tant d'autre qu'il faudrait lister et répertorier.


-- 
sly (sylvain letuffe)
http://wiki.openstreetmap.org/wiki/User:Sletuffe

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


Re: [OSM-talk-fr] Dans "name", le nom de commune au COG ou le "terrain" ?

2013-12-09 Par sujet sly (sylvain letuffe)
On lundi 9 décembre 2013, Christophe Merlet wrote:
> Plutôt que de mettre des notes à rallonge, utiliser official_name et
> ref:INSEE suffit à auto-documenter le fait que la personne s'est posé la
> question du choix du nom.

Mon but n'était bien évidement pas uniquement de "documenter le fait que je me 
sois posé la question" mais d'en documenter la réponse, les conclusions et les 
éléments de la réflexion pour que la prochaine fois qu'une personne édite ce 
noeud, elle puisse avoir le maximum d'information sur les causes qui ont mené 
à certains choix voir engager une discussion.
Un peu comme si les notes étaient la "talk" page d'une page du wiki

Je trouve les "notes à rallonge" une des techniques les plus performante qu'il 
soit compte tenu des outils que nous avons pour tenir informé les autres 
contributeurs. Et j'encourage fortement tout le monde à suivre mon exemple, 
car je trouve qu'il n'y a rien de plus pénible ne se retrouver devant des tags 
étonnants ou contradictoires sans aucune explications.

> Le validate:incoherence_nom_insee n'est pas un peu lourdingue ?

"lourdingue" n'est pas un mot de mon dictionnaire, peux-tu expliciter ce que 
tu veux dire par là, voire suggérer une alternative qui pourrait remplir la 
même fonction que celle que je recherche et que j'ai documentée ici :
https://wiki.openstreetmap.org/wiki/Proposed_features/Internal_quality
?

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

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


Re: [OSM-talk-fr] Dans "name", le nom de commune au COG ou le "terrain" ?

2013-12-09 Par sujet sly (sylvain letuffe)
On lundi 9 décembre 2013, PierreV wrote:
> Si j'ai bien compris votre proposition de mettre le nom "terrain" sur le
> noeud "place" 

Pour conclure le cas particulier pris en exemple au début de ce fil de 
discussion, c'est ce que je viens de choisir :
http://www.openstreetmap.org/node/924622799

> J'avais déja soulevé ce cas particulier sur la ML qui préférais
> "globalement" que le nom "principal après fusion" soit changé sur le noeud
> ayant gardé le "cœur administratif" 

ha bon ? Et bien si sondage il y a à nouveau, je donne ma voix "contre".
La règle "c'est le terrain qui prime" me semble tout à fait applicable et 
adapté à ces cas. Si le panneau indique
Triffouilli les oies
(commune de triffouilli les renards)
J'indique et je défend comme idée, celle de mettre name="Triffouilli les oies" 
sur le noeud place.


Mais je suis bien sûr prêt à en débattre avec les opposants pour qui "la 
cartographie des citoyens pour les citoyens" semble plus être :
"la cartographie des instances administratives embourbées dans leurs 
procédures pour une partie des citoyens"

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

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


Re: [OSM-talk-fr] Test export communes

2013-12-08 Par sujet sly (sylvain letuffe)
Le dimanche 08 décembre 2013 20:22:46, JB a écrit :
> Vite, des données au point, s'il vous plait. 

Vite ? b... quel vilain mot dans un contexte de bénévolat.


M'enfin à voir si ce truc là convient/compense ou complète :

http://export.openstreetmap.fr/contours-administratifs/communes/

http://trac.openstreetmap.fr/newticket?component=suivi/export%20admin

-- 
sly (sylvain letuffe)
http://wiki.openstreetmap.org/wiki/User:Sletuffe

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


Re: [OSM-talk-fr] Hors sujet (Re: Controle qualité des limites administratives.)

2013-12-06 Par sujet sly (sylvain letuffe)
On vendredi 6 décembre 2013, sly (sylvain letuffe) wrote:
> (Bon, à part du wikimedia à tour de bras)

p'tain, mais c'est pas possible, ce boulet est absolument partout :
http://fr.wikipedia.org/w/index.php?title=Enclave&diff=83938752&oldid=83589032

Il va nous refaire osm et wikipedia à sa sauce à lui !

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

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


[OSM-talk-fr] Hors sujet (Re: Controle qualité des limites administratives.)

2013-12-06 Par sujet sly (sylvain letuffe)
On vendredi 6 décembre 2013, David Crochet wrote:
> Certes, il se peut que certains dictionnaires n'explicitent pas ce 
> terme, mais ce n'est pas un néologisme non plus.

Moi, je crois bien que si, et même un anglicisme.

> https://fr.wiktionary.org/wiki/exclave

Bon, ok, voilà le seul dictionnaire à parler d'exclave, mais bon, c'est 
wiktionary hein. Quand le mot n'est pas dans le larousse, ni dans le dico de 
l'académy française, ni sur wordreference, on est en droit de se demander si 
c'est bien un mot français ;-)

J'aime pas trop le principe google fight en général :
mais là : https://www.google.com/search?q=exclave
on voit que c'est un peu pauvre en résultat.
(Bon, à part du wikimedia à tour de bras)



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

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


Re: [OSM-talk-fr] Controle qualité des limites administratives.

2013-12-06 Par sujet sly (sylvain letuffe)
On vendredi 6 décembre 2013, Frédéric Rodrigo wrote:
> Question de vocabulaire, il s'agit d'exclaves, aucune des parties n'est
> complètement enclavé dans une autre commune.

Alors s'il est question de vocabulaire : le mot exclave n'existe pas en 
français. On parle de "territoires non connectés formant une commune (ou truc 
du genre)" 

-- 
sly
qui suis-je : http://sly.letuffe.org
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] Dans "name", le nom de commune au COG ou le "terrain" ?

2013-12-06 Par sujet sly (sylvain letuffe)
On vendredi 6 décembre 2013, Nicolas Dumoulin wrote:

> On avait déjà parlé d'ailleurs des communes dont le chef-lieu sur le terrain 
> n'a pas exactement le même nom (au delà de l'orthographe) que la commune.
> Il y en a au moins une d'après wikipedia :

Dans nos montagnes, rempli de micro-village, ce cas se présente aussi, il a 
fallu être pragmatique et éviter les communes de 30 habitants, mais comme on 
haï son voisin, on va quand même pas choisir "son" nom !
D'où la naissance d'un nom ex-nihilo (ou presque) du nom de la commune.
http://fr.wikipedia.org/wiki/Les_Déserts
Le chef lieu s'appel "la combe"
http://fr.wikipedia.org/wiki/Sainte-Marie-du-Mont_(Isère)
"Les près"

Mais dans ces cas, les habitants ne nient pas l'existence de ce nom pour la 
commune ou de cet orthographe, et le terrain indique bien (entre ( ) ) le nom 
de la commune.
Celui dont je parle au début, le terrain et les gens du terrain s'accorde à 
dire "il y a une erreur dans le COG"
Et à ceux qui gère le "COG" de répondre : "il y a erreur dans les gens" vu que 
c'est nous qui somme les "officiels"


-- 
sly
qui suis-je : http://sly.letuffe.org
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] Dans "name", le nom de commune au COG ou le "terrain" ?

2013-12-06 Par sujet sly (sylvain letuffe)
On vendredi 6 décembre 2013, Eric Sibert wrote:
> J'aurais tendance à mettre le nom officiel sur la relation et le nom  
> du terrain sur le nœud place=*.

Cette idée me plaît pas mal, surtout que pieren ne l'aime pas ;-)

Pour qu'elle me plaise totalement, il faudrait que le nom d'une commune ne 
soit jamais indiqué sur le terrain, sans quoi, c'est la règle "du terrain" 
selon osm qui doit primer.

Alors si les habitants écrivent "champlaurent" si les panneaux d'entrée 
d'aglomération* écrivent "champlaurent" ok, c'est le terrain, mais le terrain 
du noeud "village"

Le terrain pour le nom de la frontière de commune n'existant pas (à confirmer 
? des bornes routières, par exemple, indiquent-t-elle le com de commune ?), on 
pourrait alors mettre dans la relation de commune le nom du COG

* entre temps, streeview est passé par là et on voit que le panneau d'entrée 
d'aglo est lui aussi sans tiret : 
http://sly.letuffe.org/osm/champlaurent-panneau-entree.jpeg

Mais aglo n'étant pas commune, rien n'empêcherait qu'il soit différent.

> Après, c'est quoi le nom officiel? 
"Administration publique : Qui émane du gouvernement, qui est déclaré par 
lui."

pour official_name, ça me semble clair, c'est la version du COG ou, du mois, 
lorsqu'il sera à jour.

La question portait sur la clé "name"
-- 
sly
qui suis-je : http://sly.letuffe.org
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] Nouvelle fonction "Add a note" sur osm.org

2013-04-24 Par sujet sly (sylvain letuffe)
Le mercredi 24 avril 2013 12:48:46, Pieren a écrit :
> Depuis peu, il est possible de cliquer sur "Add a note" 
(...)
> Vous en pensez quoi ?

Désolé, c'est en anglais (google translate), mon message de novembre dernier 
concernant notes :

http://lists.openstreetmap.org/pipermail/dev/2012-November/026232.html
-- 
sly (sylvain letuffe)

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


  1   2   3   4   5   6   7   8   9   10   >