from:"Pierre Béland"

Pawel,

could you give us a permalink to an area where we will see some activity 
reported?


 
Pierre 




 De : Paweł Paprota ppa...@fastmail.fm
À : talk@openstreetmap.org 
Envoyé le : Lundi 15 octobre 2012 12h17
Objet : Re: [OSM-talk] Activity Stream (a.k.a. social OSM) - demo instance
 
When you zoom in to a small area there is indeed no activities in many
places - there is only ~8000 activities in the database at this point,
replication is still in progress.

As for the translation - I have added an English one but for some reason
it is not being picked up in Javascript, so it's a bug. But for now I
would propose to ignore the details and focus on the concept, such as
for example:

* Is presentation as a separate tab and on the user page useful?
* Do you think commenting on activities would be a useful feature?

Paweł

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


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

Re: [OSM-talk] Activity Stream (a.k.a. social OSM) - demo instance

Pavel,

I tried with two navigators, both with french defined as user language.  They 
both showthe following error / warning message in the Activity side window :
[missing fr.site.sidebar.activities translation]

The Chrome navigator shows normally the Activity list in english.

The Firefox 16.0.1 navigator do not provide the Activity list and indicate : 
Error: data is undefined. 

 
Pierre 




 De : Paweł Paprota ppa...@fastmail.fm
À : Pierre Béland infosbelas-...@yahoo.fr; talk@openstreetmap.org 
talk@openstreetmap.org 
Envoyé le : Lundi 15 octobre 2012 13h17
Objet : Re: [OSM-talk] Activity Stream (a.k.a. social OSM) - demo instance
 
Sure, this is the whole Poland:

http://suncobalt.dyndns.org:8081/?lat=51.61lon=22.44zoom=7layers=M

BTW, the activities are not reloaded automatically (and the Reload
button doesn't work - I will fix that in a minute) right now so when you
change the bounding box you need to click Activity tab again - maybe
that's why you couldn't find activities anywhere?

Paweł


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

[OSM-talk] Monitoring activities : visual tools for data mining into history of objects

Various Activity Monitoring tools such as Whodidtit provide the list of recent 
changesets in an area. But nothing to visualize on the map. The only solution I 
know to visualize is to revert a Changeset in JOSM. This way, it reconstruct 
and show the objects of the Changeset.


To efficiently monitor the mapping of an area, it would be more powerfull if it 
was possible to compare on the map the Changeset objects or a particular object 
(ie. Bbefore and After states). 


Some History comparison tools show the history in a table where you can select 
two versions of the history.  This could be adapted to show the objects on two 
contiguous maps or two layers.

Deleted objects are particularly neglected. If it was possible to visualize 
rapidly what the object looked like before erasing it, this would greatly 
facililtate the monitoring of an area.

As a monitoring tool, the comparison of two maps would effectively complete 
History comparison tables that already exist.

Pierre 






 De : Dave F. dave...@madasafish.com
À : talk@openstreetmap.org 
Envoyé le : Lundi 15 octobre 2012 14h39
Objet : Re: [OSM-talk] Fw:  Fun: Collect your favourite mappers
 
On 15/10/2012 15:52, Richard Weait wrote:
 I'd love to make printed collector sets...

Wouldn't it be better if you spent your time mapping?

There seems to be a hell of a lot of ancillary stuff going on around OSM. 
Maybe a 'Back to Basics' push might not go amiss.

Dave F.


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


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

[OSM-talk-fr] Suivi des modifications : Comment visualiser simplement les objets modifiés ou détruits

Chai-pâ ce que vous penseriez d'un Sujet du lundi matin pour réchauffer les 
méninges.

Les contributeurs du nord de L'Ontario, au Canada, on repéré une zone où 
quelqu'un s'est amusé à créer une ville imaginaire. Facile à repérer et 
effacer. Mais lorsque ce loustic ou un contributeur inexpérimenté ou distrait 
efface plutôt une zone?

whodidit[1] ou des outils similaires nous permettent de repérer rapidement les 
zones où des modifications ont été effectuées.  Par contre, de là, il est 
difficile de visualiser ce qui a été fait.  À partir des changesets, il reste 
difficile de repérer si des dommages ont été effectués à une zone.


Avec whodidit, par exemple, je peux toujours télécharger la zone dans JOSM et 
faire une recherche sur le code usager.

Pour les objets effacés, par contre, c'est le néant. Il serait utile de pouvoir 
visualiser rapidement un objet effacé pour voir s'il était pertinent ou non de 
l'effacer.

Je suis tombé sur un changeset où un nouveau contributeur a effacé plusieurs 
objets. Il a effacé une limite administrative, un club nautique etc. Mais 
lorsque nous faisons le suivi d'une zone, il n'est pas évident de repérer 
rapidement ces infos.  


Une solution intéressante serait d'ajouter la possibilité de visualiser les 
objets effacés dans un changeset particulier. À ma connaissance ceci n'existe 
pas.

À partir de la liste des objets ajoutés, modifiés, effacés, un lien pourrait 
rediriger vers une carte OSM où cet objet est superposé.

Qu'en pensez-vous?


Pierre 

[1] http://zverik.osm.rambler.ru/whodidit/
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Suivi des modifications : Comment visualiser simplement les objets modifiés ou détruits

Il serait intéressant d'adapter le concept de Data Mining où l'on peut cliquer 
sur un objet pour obtenir de l'info plus détaillée. Dans le Data Mining on peut 
aller, par exemple, de pays, à région, à ville, etc.

Dans le cas qui nous intéresse, il serait possible de visualiser simultanément 
tous les objets d'un Changeset sur une carte, incluant ceux effacés qui 
pourraient être grisés. Puis de là, on devrait pouvoir comparer  avec une carte 
montrant l'état précédent dans l'historique. Cela se fait déjà sous forme de 
tableau pour les attributs et les nodes. Il s'agirait d'adapter ou ajouter la 
possibilité de visualiser sur carte.

Comme outil de suivi, la comparaison de deux cartes serait beaucoup plus 
efficace que de comparer deux tables listant les nodes.

Et lacune particulière, quand un objet est effacé, il est souvent difficile de 
juste savoir ce qu'il représentait auparavant.

Ceci permettrait de repérer beaucoup plus rapidement les grosses gaffes et 
d'annuler la modification ou corriger.

 
Pierre 




 De : Stéphane Péneau stephane.pen...@wanadoo.fr
À : Pierre Béland infosbelas-...@yahoo.fr; Discussions sur OSM en français 
talk-fr@openstreetmap.org 
Envoyé le : Lundi 15 octobre 2012 15h25
Objet : Re: [OSM-talk-fr] Suivi des modifications : Comment visualiser 
simplement les objets modifiés ou détruits
 
Je peste régulièrement contre l'impossibilité de voir vraiment ce qu'a 
apporté un changeset, donc oui, je pense qu'il y a beaucoup à faire de ce côté 
là.

Il manque :
- sur openstreetmap.org, un résumé du changeset comme on l'a sur whodidit avec 
les nodes/ways/relation créés/modifiés/supprimés.

- Des infos plus pertinentes sur l'historique des id, un peu à la manière de 
Potlatch (création, déplacement de node, ajout de node, way coupé, way étendu, 
way joint, etc.)

- Sur osm ou dans josm, une visualisation graphique de avant/après sur une 
période, un changeset ou, à défaut, sur un id en particulier.

a suivre





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

Re: [OSM-talk-fr] Boites aux lettres concentrées au même endroit

2012-10-13 Per discussione Pierre Béland

J'ai peut-être mal interprété le propos de Romain. 

Il s'agit effectivement de boites à lettre résidentielles. Depuis une vingtaine 
d'années, la poste a été privatisée et on n'assure plus la livraison à la 
porte. On a plutôt conçu des îlots comme le montre l'image sur le lien que j'ai 
donné précédemment : 
http://wiki.openstreetmap.org/wiki/Canadian_tagging_guidelines


Pierre 




 De : Philippe Verdy verd...@wanadoo.fr
À : Pierre Béland infosbelas-...@yahoo.fr; Discussions sur OSM en français 
talk-fr@openstreetmap.org 
Envoyé le : Samedi 13 octobre 2012 13h18
Objet : Re: [OSM-talk-fr] Boites aux lettres concentrées au même endroit
 
Je pense qu'il parle des boîtes à lettres des résidents. C'est très
courant en fait de voir toutes les boîtes d'un groupe de maisons ou
d'immeubles réunies près du point d'entrée d'une résidence privée, ou
bien en bas d'un chemin public d'accès mais interdit aux véhicules non
résidentiels, et non pas à l'emplacement de chaque propriété (on
trouve alors les boites pour un ensemble de numéros de la même rue,
voire de plusieurs rues, ce qui fait que l'emplacement des boîtes à
lettre privées n'est pas situé à l'adresse de la propriété mais plus
loin).

Le cas se trouve également à l'entrée de petits lotissements, quand
cette entrée se fait par une impasse (c'est plus pratique pour la
distribution du courrier et cela limite la circulation de service dans
cette impasse résidentielle peu pratique), ou encore uniquement par un
chemin piéton/vélo circulant entre les résidences, là encore quand
l'accès des véhicules est restreint aux seuls résidents (et parfois
bloqué par une barrière ou plots sur la chaussée que seuls les
résidents peuvent ouvrir).

Parfois ce groupe de boites à lettres privées inclut aussi une boîte
pour poster le courrier (bien distinguée par la couleur et le
marquage), relevée en même temps que lors de la dépose du courrier par
le facteur dans les boîtes à lettres privées.

En principe on ne cartographie pas les boîtes à lettres privées (on
indique les numéros des rues ou routes en bordure de propriété au
point d'accès privé spécifiquement) ; mais on cartographie les boites
publiques pour le courrier au départ (dont l'usage n'est pas réservé
qu'aux seuls résidents locaux).

Le 13 octobre 2012 19:00, Pierre Béland infosbelas-...@yahoo.fr a écrit :
 voir le guide canadien (en anglais) avec exemple pour ce type de boite
 postale groupée
 http://wiki.openstreetmap.org/wiki/Canadian_tagging_guidelines

 Nous utilisons les tags amenity: post_box  et   type: cmb
 Je ne sais pas si c'est utilisé ailleurs.

 Pierre

 
 De : Romain MEHUT romain.me...@gmail.com
 À : Discussions sur OSM en français talk-fr@openstreetmap.org
 Envoyé le : Samedi 13 octobre 2012 12h54
 Objet : [OSM-talk-fr] Boites aux lettres concentrées au même endroit

 Bonjour,

 Avez-vous déjà rencontré cette situation où, dans une rue, des boites aux
 lettres sont concentrées au même endroit?

 Si oui quel est le tag approprié?

 Merci.

 Romain

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



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



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

Re: [OSM-talk-fr] Tournage d'un reportage-magazine pour France 3 Nord-Est

2012-10-12 Per discussione Pierre Béland

Romain,

Il y a la carte OSM, et il y a aussi tout le non visible derrière. Avec OSM, il 
y a plusieurs exemples qui montrent comment le web bouleverse les solidarités. 

Nous avons bien sûr de nombreux exemples au niveau local. Au cas ou la 
discussion déborde, voici quelques exemples au niveau international.

OSM, c'est aussi une communauté internationale de développeurs OpenSource, de 
producteurs de données libres, d'intervenants locaux se servant de la 
cartographie comme moyen de prise de conscience, participation aux décisions 
par les communautés locales. Divers groupes de travail, discutent sur internet, 
développent des outils, assurent la gestion de ce grand projet.

Et le groupe Humanitarian OpenStreetMap Team (HOT), orienté vers l'humanitaire, 
agit lors de catastrophes ou pour supporter des communautés locales dans des 
zones à risque.

Exemples
- des développeurs, des mappeurs, des outils de communication, édition etc,
- projet local Kibera dans un des plus grands bidonvilles au monde 
http://mapkibera.org/  http://www.kibera.org.uk/Facts.html
- la cartographie lors de catastrophes - actions qui ont reçu un coup 
d'accélérateur avec le tremblement de terre à Port-au-Prince en janvier 2010- 
le projet des volontaires européens en Afrique ( EUROSHA)
 

Pierre 




 De : Romain MEHUT romain.me...@gmail.com
À : Discussions sur OSM en français talk-fr@openstreetmap.org 
Envoyé le : Vendredi 12 octobre 2012 9h03
Objet : [OSM-talk-fr] Tournage d'un reportage-magazine pour France 3 Nord-Est
 

Bonjour,

J'ai été contacté par une journaliste de France Télévision pour le tournage la 
semaine prochaine d'un reportage-magazine pour France 3 Nord-est sur le thème 
des nouvelles solidarités.

La responsable du programme lui demande de réfléchir en particulier à Linux, 
les logiciels libres... avec les questions Quelles sont les nouvelles 
pratiques solidaires liées au numérique ? Le web est-il en train de 
révolutionner la solidarité?

Pour ma part, je participerai pour présenter OSM. Le tournage devrait 
consister en une interview et une démo (de la BDD et peut être en extérieur).

Pour faire le lien avec le thème du reportage, le projet OSM peut être vu 
comme un réseau social où les citoyens peuvent contributeur à constituer une 
BDD qui profite à tous. Pour illustrer, j'ai en tête l'accessibilité pour les 
personnes handicapées.

Vous avez d'autres idées à faire passer?

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


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

Re: [OSM-talk-fr] Imbrication des noms dans les résultats de recherche

2012-10-11 Per discussione Pierre Béland

Ista,

Vois le résultat retourné lorsque nous faisons une recherche nominatim.
http://nominatim.openstreetmap.org/details.php?place_id=18296209

Ce que je comprends du fonctionnnement de Nominatim, c'est que lorsu'il 
rencontre un tag place (ici place=suburb pour Technopole), il calcule une 
circonférence autour de ce point et relie ces rues à cette place.

Idéalement, il faudrait définir une relation de type boundary plutôt qu'une 
simple node avec le tag place.

À moins que quelqu'un connaisse une solution plus élégante.
 

Pierre 




 De : Ista Pouss ista...@gmail.com
À : Discussions sur OSM en français talk-fr@openstreetmap.org 
Envoyé le : Jeudi 11 octobre 2012 10h00
Objet : [OSM-talk-fr] Imbrication des noms dans les résultats de recherche
 

Bonjour,

Si avec osm je fais une recherche de n'importe quel nom sur saint etienne, 
j'obtiens quasi toujours le nom, Technopole, Saint Etienne, Loire, 
Rhônes-Alpes, le code postal, France.

Par exemple, si je demande Place Dorian, Saint Etienne, Nominatim me renvoie 
Place Dorian, Technopôle, Saint-Étienne, Loire, Rhône-Alpes, 42270, France 
(http://osm.org/go/0ApD~eLB1--).

Mais une telle organisation est fausse pour Technopole, étonnante pour 
42270.

Technopole est une zone industrielle à Saint Etienne, bien située par osm 
(http://osm.org/go/0ApMFEL0). Comment se fait-il qu'elle englobe toutes les 
rues de la ville ?

Et pour le 42270, moi j'aurais vu quelque chose comme ...Place Dorian, 42270, 
Saint Etienne, Loire... Le 42270 désignant une zone postale (je crois) dans 
st etienne, elle devrait venir entre la rue et la ville, et non entre la 
région et le pays.

Qu'en pensez-vous ?


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


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

Re: [OSM-talk-fr] Imbrication des noms dans les résultats de recherche

2012-10-11 Per discussione Pierre Béland

Ista,

Est-ce que le Technopole est un simple établissement plutôt qu'un quartier 
complet?  Si c'est un simple établissement, il est inapproprié d'uliser le tag 
place pour le rendu.


 
Pierre 




 De : Ista Pouss ista...@gmail.com
À : Discussions sur OSM en français talk-fr@openstreetmap.org 
Envoyé le : Jeudi 11 octobre 2012 10h00
Objet : [OSM-talk-fr] Imbrication des noms dans les résultats de recherche
 

Bonjour,

Si avec osm je fais une recherche de n'importe quel nom sur saint etienne, 
j'obtiens quasi toujours le nom, Technopole, Saint Etienne, Loire, 
Rhônes-Alpes, le code postal, France.

Par exemple, si je demande Place Dorian, Saint Etienne, Nominatim me renvoie 
Place Dorian, Technopôle, Saint-Étienne, Loire, Rhône-Alpes, 42270, France 
(http://osm.org/go/0ApD~eLB1--).

Mais une telle organisation est fausse pour Technopole, étonnante pour 
42270.

Technopole est une zone industrielle à Saint Etienne, bien située par osm 
(http://osm.org/go/0ApMFEL0). Comment se fait-il qu'elle englobe toutes les 
rues de la ville ?

Et pour le 42270, moi j'aurais vu quelque chose comme ...Place Dorian, 42270, 
Saint Etienne, Loire... Le 42270 désignant une zone postale (je crois) dans 
st etienne, elle devrait venir entre la rue et la ville, et non entre la 
région et le pays.

Qu'en pensez-vous ?


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


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

Re: [OSM-talk-fr] Imbrication des noms dans les résultats de recherche

2012-10-11 Per discussione Pierre Béland

ll serait donc possible, si c'est une zone industrielle, de créer une relation 
boundary qui en délimite les contours. De cette façon, ça règlerait les 
problèmes avec Nominatim pour Saint-Étienne.
 

Pierre 




 De : Ista Pouss ista...@gmail.com
À : Discussions sur OSM en français talk-fr@openstreetmap.org 
Envoyé le : Jeudi 11 octobre 2012 13h11
Objet : Re: [OSM-talk-fr] Imbrication des noms dans les résultats de recherche
 

Le 11 octobre 2012 16:32, Pieren pier...@gmail.com a écrit :


Comme ce technopole ne fait pas partie de la liste des quartiers de
st-etienne (http://fr.wikipedia.org/wiki/Quartiers_de_Saint-%C3%89tienne),
il faudrait changer le tag. Idéalement tracer un polygone avec
landuse+name.



Pourtant l'usage du tag dans ce cas correspond assez bien à la description  du 
wiki (http://wiki.openstreetmap.org/wiki/Tag:place%3Dsuburb).

J'ai l'impression qu'en fait il n'y a aucun quartier d'indiqué à St Etienne, à 
part celui là (qui n'est, à ma connaissance, qu'une sorte de zone 
industrielle) (sans penser à médire). C'est peut être pour ça que nominatim 
raccorde tout à ce quartier ?

Je vais mettre dans ma liste de todo rajouter les quartiers de st etienne. 
Merci.


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


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

Re: [Talk-ca] canvec fixme - Place type may not be valid

2012-10-10 Per discussione Pierre Béland

Andrew,

I cc to Nicolas Gariepy from NRCan. Nicolas should be able to indicate what 
NRCan want us to validate when they put these fixme on Canvec files. It is 
probably to validate if this locality exist or not.


For example, looking at one of the canvec edits you did recently, I see Fishers 
Glen locality (node=1873510264) at the end of Fishers Glen rd, near Fishers 
Creek. 
Pierre 




 De : Andrew Allison andrew.alli...@teksavvy.com
À : talk-ca talk-ca@openstreetmap.org 
Envoyé le : Mercredi 10 octobre 2012 12h58
Objet : [Talk-ca] canvec fixme - Place type may not be valid
 
Hello:

       I'm currently importing canvec data in south western Ontario.

        My question is, canvec data has fixmes for
        place = locality      Place type may not be valid
        track sport type unknown. 

        Should I just go ahead and delete these fixme, as I don't think
they are really fixme's?

        Andrew

        aka PurpleMustang, CanvecImports.

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


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

Re: [OSM-talk-fr] Tuteurs pour volontaires européens ?

2012-10-10 Per discussione Pierre Béland

Je suis aussi disponible.

 
Pierre 




 De : Marc SIBERT m...@sibert.fr
À : Discussions sur OSM en français talk-fr@openstreetmap.org 
Cc : Severin Menard severin.men...@hotosm.org; nicolas chavent 
nicolas.chav...@hotosm.org 
Envoyé le : Mercredi 10 octobre 2012 5h14
Objet : Re: [OSM-talk-fr] Tuteurs pour volontaires européens ?
 

Bonjour,

Je up le sujet et j'en profite pour répondre positivement à cette demande de 
support à distance.
Par contre, et sauf erreur, je n'ai pas vu de présentation de volontaire sur 
le forum.

A+

Marc


Le 4 octobre 2012 18:32, Christian Quest cqu...@openstreetmap.fr a écrit :

Demain se termine la formation EUROSHA de volontaires européens à
laquelle je participe depuis le début de la semaine.

De quoi s'agit-il ?

Un vingtaine de volontaires ont suivit une formation de 3 semaines
avant de partir dans différents pays d'Afrique (Burundi, Kenya, Tchad
et Centrafrique) dans les semaines qui vont venir pour y faire de la
cartographie à visée humanitaire sur OpenStreetMap.

La formation OpenStreetMap s'est déroulée sur 4 jours (seulement) et a
été très dense car elle couvrait: la présentation du projet avec le
concept de licence libre de logiciels libres, de crowdsourcing, puis
un aperçu des outils de contributions de l'imagerie aérienne, de la
préparation d'une collecte sur le terrain, une cartopartie avec
relevés par GPS, logger, walking papers et photos géotaguées, puis
saisie dans JOSM, puis les outils de contrôle de qualité, les outils
de coordination (OSM Task Manager d'HOT), et on va attaquer la partie
exploitation des données.

Vous imaginez bien que tout ça en 4 jours c'est un peu lourd à
digérer... et qu'il va falloir consolider tout ça.

Ils partent en mission dans les semaines à venir, et vont donc
rapidement avoir à mettre les mains dans le cambouis et besoin d'être
aidés.

Je propose donc à ceux qui le souhaite et qui se sentent capable de
prendre par la main des débutants d'avoir un rôle de tuteur et j'ai
invité les volontaires francophones à venir sur
http://forum.openstreetmap.fr/ pour se présenter pour qu'un tuteur
puisse les suivre.

Dans un premier temps, il s'agit essentiellement d'aider à prendre en
main JOSM et de gagner en efficacité ainsi que de suivre les tracés de
routes et de bâtiments faits sur les images bing dans leur zone de
déploiement.
Les règles de tagging seront à voir dans un deuxième temps, et elles
sont un peu spécifiques à l'humanitaires et parfois différentes par
rapport à nos habitudes.

Plus d'infos:
- http://hot.openstreetmap.org/projects/eurosha_0
- http://wiki.openstreetmap.org/wiki/Humanitarian_OSM_Team/Tutorships

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



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


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

Re: [OSM-talk-fr] Contrôle qualité des axes routiers

Fabien,

j'ai testé ce calque small components.C'est en effet très efficace pour 
repérer les problèmes de routage.   Le calque permet de repérer rapidement les 
zones à problème. 

J'ai rapidement repéré deux chemins connectés à un polygone leisure=park plutôt 
qu'au chemin le croisant.  Dans un cas, le polygone se superposait aux chemins, 
et les masquaient. 

Pour un contributeur moins expérimenté ou un distrait, il est vite fait de 
sélectionner le polygone plutôt que le chemin.

À ma connaissance, il n'existe pas dans JOSM une feuille de style Routing 
MapCSS ou une règle de validation qui signale de tels problèmes. Ce serait des 
ajout intéressants pour repérer à la source ces problèmes



Pierre 




 De : Ab_fab gamma@gmail.com
À : Discussions sur OSM en français talk-fr@openstreetmap.org 
Envoyé le : Mardi 9 octobre 2012 5h00
Objet : Re: [OSM-talk-fr] Contrôle qualité des axes routiers
 

Quelques nouvelles en provenance d'OSRM, pour le contrôle qualité des 
itinéraires :
http://lists.openstreetmap.org/pipermail/dev/2012-October/025716.html

Ce que je comprends, c'est que cela met en évidence des voies desquelles on 
peut entrer, mais d'où on ne peut pas sortir, à cause de mauvaises connexions 
avec le reste du réseau routier.


Les infos peuvent être consultées sur un calque small components du site 
osrm, ou bien sur osm inspector (qui proposait déjà l'analyse des fins de ways 
très proches mais non connectées à d'autres éléments de voirie)


Le 1 octobre 2012 23:11, Vincent de Chateau-Thierry v...@laposte.net a écrit 
:


Le 01/10/2012 18:24, Ab_fab a écrit :

Ça peut être une bonne occasion de voir le détail de ce schéma.
Et s'il est interessant les références des noeuds pourraient y être
indiquées, c'est sûr.

Le 1 oct. 2012 18:19, Christian Quest cqu...@openstreetmap.fr

mailto:cqu...@openstreetmap.fr a écrit :


    Il faudrait aussi regarder la proposition des jonctions routières
    complexes qui a été présentée au SOTM à Tokyo.
    L'idée est d'avoir une relation pour décrire un noeud routier, ce qui
    permet aux algos de routage (et de rendu) de mieux fonctionner. C'est
    sur ces noeuds routiers qu'il faudrait peut être mettre les infos
    DATEX.

    A lire ici:
    
http://wiki.openstreetmap.org/wiki/Proposed_features/Junction#Complex_junction_relation


Pour revenir à ta question initial Ab_fab*, je suis aussi partant pour 
contribuer sur le sujet. En revancheje coince sur la motivation contrôle 
qualité que tu associes : pour moi il y a d'un coté le référentiel TMC qu'on 
peut vouloir intégrer à OSM si on estime que ça apporte de la valeur à la 
base, et de l'autre le besoin de faire du contrôle-qualité sur le graphe OSM.
Pour ce second point pris seul, je préfère dépenser du temps à constituer des 
matrices origine-destination et à lancer des batteries d'itinéraires via 
OSRM, pour ensuite détecter les changements dans les durées et/ou les 
kilométrages, et par suite analyser les causes du changement, voire détecter 
des cassures dans le graphe. Je pense qu'on aura des résultats plus rapides 
et des diagnostics plus simples à partager que ceux basés sur le TMC. Sans 
compter que le rythme d'intégration d'un tel référentiel risque d'être 
modeste, et engage derrière une maintenance à chaque nouvelle version des 
tables de localisants.
Donc partant, si on pense que ça servira à autre chose que du 
contrôle-qualité :-)

vincent

* pas facile de gober en une soirée les 100 messages du jour sur talk-fr :-)


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




-- 
ab_fab
Il n'y a pas de pas perdus

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


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

Re: [OSM-talk-fr] Chef-lieu de commune...

Éric,

La solution la plus simple et la plus efficace pour les recherches Nominatim 
serait sans doute d'importer les données de limites administratives.

Sur le portail web de COD-OCHA, on liste des fichiers de limites 
administratives pour Madagascar.
voir http://cod.humanitarianresponse.info/country-region/madagascar

La licence OCHA n'est pas à ma connaissance compatible avec la licence OdbL de 
OSM. Par contre il est indiqué que ces données proviennent 

du BNGRC.

Je te suggère de contacterMamy Razakanaivo,Secrétaire Exécutif de la Cellule de 
Prévention et Gestion des Urgencesà la primature (CPGU) dont je t'ai déjà donné 
les coordonnées.

 
Pierre 




 De : Eric SIBERT courr...@eric.sibert.fr
À : Discussions sur OSM en français talk-fr@openstreetmap.org 
Envoyé le : Mardi 9 octobre 2012 17h34
Objet : [OSM-talk-fr] Chef-lieu de commune...
 
Bonsoir,

Je cherche un moyen d'indiquer quel village est le chef-lieu d'une commune.


Facile!!!


J'ai oublié de préciser que c'était pour Madagascar. À Madagascar, il n'y a 
aucune relation boundary=administrative.

Je vous explique l'idée sous-jacente. Madagascar comporte environ 1500 
communes réunies en 112 districts eux-mêmes réunis en 22 régions. Je voudrais 
essayer de localiser les chef-lieux de ces communes.

Je pense que c'est possible en croisant les données entre un recensement 
(http://www.ilo.cornell.edu/ilo/datafr.html), GeoNames et Bing. Le principe 
serait de partir d'un nom dans le recensement, de chercher dans GeoNames les 
coordonnées approximatives et de trouver réellement la ville ou le village 
dans Bing quand la haute résolution est disponible.

Premier écueil, orthographe fausse dans le recensement ou dans GeoNames. Une 
recherche sur internet avec le district aussi fourni dans le recensement peut 
aider à s'en sortir. Second écueil, il y a beaucoup d'homonymes sur les noms 
de lieu. D'un point de vue administratif, il y a des suffixes ajoutés aux noms 
de communes homonymes pour les distinguer (Nord, Sud, Est, Ouest, Centre...). 
En pratique, GeoNames peut retourner beaucoup de réponses. Le district 
d'appartenance peut aider à trouver la bonne réponse. Le dernier point, c'est 
qu'il faut disposer de Bing en haute résolution à l'endroit voulut.

Je cherche à organiser tout ça en particulier pour avoir des outils de suivi 
de l'avancement. Par exemple un tableau avec pour chaque district, le nombre 
de communes attendu et le nombre trouvé dans OSM. Et aussi indiquer les 
chef-lieux de district et de région.

Vous proposez quoi comme modèle de données?

Éric

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


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

Re: [OSM-talk-fr] Membre du rôle outer du mauvais type

Stéphane, 

Tes explications sont trop succintes pour que l'on puisse repérer où tu as 
rencontré ce problème.

Les trois liens suivants montrent des portions de la rivièere où les contours 
sont décrits à l'aide du tag waterway=riverbank. Dans chacun,  le fleuve 
s'entrecroise avec la limite entre les deux pays.

http://nominatim.openstreetmap.org/details.php?place_id=27760175

http://nominatim.openstreetmap.org/details.php?place_id=34915823

http://nominatim.openstreetmap.org/details.php?place_id=35383549

Je vois également un chemin qui trace le centre de la rivière, croisant aussi 
la limite entre les deux pays. 
http://nominatim.openstreetmap.org/details.php?place_id=54579525



Pierre 




 De : Stéphane MARTIN st3ph.mar...@laposte.net
À : talk-fr@openstreetmap.org 
Envoyé le : Mardi 9 octobre 2012 17h48
Objet : [OSM-talk-fr] Membre du rôle outer du mauvais type
 
Salut,

Message du plugin de validation de Josm quand on édite du côté du fleuve 
Oyapock  (Guyane-Brésil) :

Avertissements
Membre du rôle outer du mauvais type - Problème de vérification de rôle (1)
2 relations: France: Régions d'outre-mer - Eaux territoriales

Évidemment je n'y comprends rien !

Est-ce seulement un avertissement parce que les membres de la relation sont 
incomplets eu égard aux données téléchargées dans Josm ?

@+

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


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

Re: [OSM-talk-fr] Membre du rôle outer du mauvais type

Stéphane,

J'ai effectué quelques modifications avec JOSM sans problème.  Le validateur 
n'a donné aucun message d'erreur. Je ne vois donc pas le problème que tu as 
rencontré.

Tout ce que je peux te dire, c'est de faire attention à ne pas toucher aux 
limites administratives lors de l'édition. Assures-toi de ne pas cliquer sur 
ces chemins pour y connecter d'autre information. De cette façon, je pense que 
tu ne devrais pas avoir de problème.


 
Pierre 




 De : Stéphane MARTIN st3ph.mar...@laposte.net
À : talk-fr@openstreetmap.org 
Envoyé le : Mardi 9 octobre 2012 18h59
Objet : Re: [OSM-talk-fr] Membre du rôle outer du mauvais type
 
Le 09/10/2012 19:44, Pierre Béland a écrit :
 Stéphane,

 Tes explications sont trop succintes pour que l'on puisse repérer où tu as 
 rencontré ce problème.

 Les trois liens suivants montrent des portions de la rivièere où les 
 contours sont décrits à l'aide du tag waterway=riverbank. Dans chacun,  le 
 fleuve s'entrecroise avec la limite entre les deux pays.

 http://nominatim.openstreetmap.org/details.php?place_id=27760175

 http://nominatim.openstreetmap.org/details.php?place_id=34915823

 http://nominatim.openstreetmap.org/details.php?place_id=35383549

 Je vois également un chemin qui trace le centre de la rivière, croisant 
 aussi la limite entre les deux pays.
 http://nominatim.openstreetmap.org/details.php?place_id=54579525



 Pierre



 
 De : Stéphane MARTIN st3ph.mar...@laposte.net
 À : talk-fr@openstreetmap.org
 Envoyé le : Mardi 9 octobre 2012 17h48
 Objet : [OSM-talk-fr] Membre du rôle outer du mauvais type

 Salut,

 Message du plugin de validation de Josm quand on édite du côté du fleuve 
 Oyapock  (Guyane-Brésil) :

 Avertissements
 Membre du rôle outer du mauvais type - Problème de vérification de rôle (1)
 2 relations: France: Régions d'outre-mer - Eaux territoriales

 Évidemment je n'y comprends rien !

 Est-ce seulement un avertissement parce que les membres de la relation sont 
 incomplets eu égard aux données téléchargées dans Josm ?

Bon alors j'ouvre dans Josm cette zone : 
http://www.openstreetmap.org/?lat=3.72825lon=-51.94465zoom=15layers=M

Je clique sur Valider du plugin de validation et dans la fenêtre 
Résultats de validation j'ai le message cité précédemment.

@+

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


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

[OSM-talk-fr] Mission de trois semaines en Indonésie avec HOT - Formation technique OSM

Avis aux intéressés. Kate Chapman de Humanitarian OpenStreetMap Team (HOT) 
recherche des volontaires pour une mission de trois semaines en Indonésie au 
mois de novembre.

 
Pierre 


- Mail transféré -
De : Kate Chapman k...@maploser.com
À : hot h...@openstreetmap.org 
Envoyé le : Mardi 9 octobre 2012 20h43
Objet : Re: [HOT] 3 Week Position in Indonesia - OSM Tech Trainer
 
Hi All,

Just a reminder that I'm still looking for a tech trainer to come out
to Jakarta. Great opportunity to see what HOT is doing in Indonesia
and help us out.

Best,

-Kate

On Wed, Oct 3, 2012 at 12:23 PM, Kate Chapman k...@maploser.com wrote:
 Hi All,

 As you may know there is a team of 8 OpenStreetMap trainers in
 Indonesia right now. This team leads workshops and provides technical
 support around OpenStreetMap use for disaster risk reduction around
 the country. The secondary component is continued training to become
 an increasingly experienced team of OpenStreetMap contributors.

 So far much of this training is coming from just a few of us. To
 expose everyone to different tech skills, different teaching styles,
 and to mix things up we'd like to have a another person join us for 3
 weeks in November. There are a variety of skills we are interested in
 and suggestions are also welcome.

 So far ideas are:

 General programming in Python, especially with QGIS
 SQL Queries/PostGIS
 Setting up WMS Servers
 TileMill
 Web Server Configuration
 Sharing maps on WordPress/Drupal/other web tools
 Advanced QGIS Topics
 Processing of Imagery with open source tools
 Git

 For more information look here on HOT's website:
 http://hot.openstreetmap.org/get_involved/openstreetmap_technical_trainer
 and if you have questions ideas feel free to contact me.

 Best,

 -Kate

___
HOT mailing list
h...@openstreetmap.org
http://lists.openstreetmap.org/listinfo/hot


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

[Talk-ht] Lac de Bélance : la nationale 1 noyée

Au sud de Bélance, je vois l'apparition sur la carte OSM d'un grand lac.
voir http://www.openstreetmap.org/?way=48565469
L'imagerie Bing montre des champs inondés pour une bonne partie.

J'invite les contributeurs connaissant cette zone à réviser cette information.

Cordialement,

Pierre Béland

 
Pierre 
___
Talk-ht mailing list
Talk-ht@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ht
Notez! Vous pouvez utiliser Google Translate (http://translate.google.com) pour 
traduire les messages.

Re: [Talk-ca] Import des limites administratives, municipalités du Québec

2012-10-05 Per discussione Pierre Béland

Hi Frank,

I wanted first to stop imports of boundaries. Otherwise
it will be a nightmare. I will contact individually each person who
imported data in the Québec area and invite them to stop imports and
participate to the discussion.

Like in the Netherlands, I think
that it is important to centralize import of the boundary data to assure
some homogeneitiy and the possibility to revise easily. Presently,
some limits are made differently from one place to the other (ways +
boundary relation) vs (one way that make all the contour of the city).
Various sources are used wich make the boundaries to overlap. Some
limits are incompleted.

The OSMOSIS tool from the OSM France community is very usefull to see problems
with incomplete boundary relations.
See

http://osmose.openstreetmap.fr/map/?zoom=7lat=44.38955lon=-75.57996layers=B00FF0FFTFFFTitem=1010,1040,1100,1150,1160,1170,3170,4090,6010,6050,6060level=1,2,3
By the way, this shows incomplete boundary relations for many areas in Canada
an USA.

But
it does not show hidden boundaries under the blanket where only ways
are used like in Brossard and Laprairie. The polygon for Laprairie is
complete but a Nominatim search for Laprairie will give no result.
http://www.openstreetmap.org/browse/way/24790856
http://www.openstreetmap.org/browse/way/20014468

This
type of work is determinant for Nominatim searches. This dramatically
increase the usability of OSM data if done properly. The best would
probably be that each province community takes care of doing the job and
eventually update. Also, I dont think that the limits should be placed
in individual Canvec files. It would be better to
produce files for each province.

I will contact RNCAN and ask
about status of the data and their plans about this. Until now, Québec
data was available. If necessary, I will also contact people working
for the Québec government.
Pierre

De : Frank Steggink stegg...@steggink.org
À : talk-ca@openstreetmap.org
Envoyé le : Vendredi 5 octobre 2012 2h19
Objet : Re: [Talk-ca] Import des limites administratives, municipalités du
Québec

Hi Pierre,

If I recall correctly, Daniel once mentioned that the municipality boundaries
were to become part of Canvec. I don't know when that would eventually happen,
but he or someone from NRCan might confirm that. Or someone who has
connections in the Quebec government might attempt to persuade them to attach
a better license to the boundaries which have currently opened up.

As for removing the incorrect data: did you try to contact the users already,
and how did they respond? I see no problem if the data is clearly wrong,
and/or when the users cannot provide clear sources. Boundaries aren't
something you can see on the ground (except for a few individual markers). On
the other hand, if both conditions are satisfied (quality and source), then
you can't just delete existing boundaries, without discussing it with the
contributing users first. This would only be the case on the Isle of Montreal,
if I understand correctly.

As for centralizing the import: in the Netherlands we have centralized it as
well. This is giving good results, since it is clear where the
responsibilities are. Generally once a year the boundaries are updated,
because adjustments being made are becoming in effect usually on January 1st.

Regards,

Frank

Quoting Pierre Béland infosbelas-...@yahoo.fr:

Les données de limites administratives sont déterminantes pour assurer une
recherche par nom de rue et municipalité dans OSM. Dans ce contexte,
plusieurs contributeurs du Québec ont commençé à importer des données de
limites administratives pour les municipalités, dans les régions de Québec,
Îles-de-la-Madeleine, Montréal, Rive-sud, Saint-Jean-sur-Richelieu et
Labelle. De façon générale, les sources de données ne sont pas indiquées,
et il y a parfois des chevauchements (exemple entre Laprairie et
Saint-Jean-sur-Richelieu.

En faisant une recherche sur les chemins et relation de limites
administratives déjà saisis, j'ai constaté que plusieurs limites étaient
incomplètes et donc inopérantes. J'ai ainsi réparé les limites de plusieurs
municipalités sur l'Île de Montréal. Les villes de banlieu et Montréal
s'affichent maintenant correctement et il est possible de faire une
recherche à partir d'un nom de rue. Sur la Rive-sud, des limites saisies par
des contributeurs pour Brossard et Laprairie sont actuellement incomplètes
et inopérantes.

Dans l'ensemble on se retrouve avec des données disparates dont ont ne
connait pas toujours la provenance. Ces données se chevauchent, sont de
formes différentes, ce qui rendra de plus en plus difficile à assembler ce
puzzle si on poursuit dans cette direction.

Au cours des deux dernières semaines, j'ai corrigé plusieurs relations
définissant les limites de municipalités du côté de Labelle et à Montréal.
Et j'ai pu

Re: [OSM-talk-fr] Récupérer les contours de tous les pays - API OpenstreetMap

2012-10-05 Per discussione Pierre Béland

Mathieu,

Voici une façon simple utilisant Nominatim et JOSM.

1. Recherche Nominatim
http://nominatim.openstreetmap.org/
tu indiques Paris, France  (pour Tokyo, Japon, il ne semble pas y avoir de 
relation de limite administrative).

tu sélectionne le lien avec (admin) (details)
tu clique sur (details) et tu récupère le no. de relation contenant les limites 
administratives. Pour Paris, id=71525
 
Tu récupère ensuite dans JOSM.
Fichier / Télécharger un objet. Tu sélectionne relation et indique le no. de 
relation.

Tu peux répéter l'opération pour d'autre lieux.

Tu pourras ensuite sauvegarder le fichier
 OSM.



 
Pierre 




 De : Mathieu Rajerison mathieu.rajeri...@gmail.com
À : Discussions sur OSM en français talk-fr@openstreetmap.org 
Envoyé le : Vendredi 5 octobre 2012 7h11
Objet : Re: [OSM-talk-fr] Récupérer les contours de tous les pays - API 
OpenstreetMap
 

Ok, je vous remercie pour toutes ces réponses!

J'ai essayé sur Tokyo mais je n'obtiens rien de probant..Faut-il que j'écrive 
Tokyo en japonais? ;) Comment être sûr de bien avoir orthographié le nom de la 
ville?

http://www.overpass-api.de/api/xapi?*[name=Tokyo]
me donne des nodes et des ways mais aucune way ne concerne une limite 
administrative..


Le 5 octobre 2012 12:40, Pieren pier...@gmail.com a écrit :

2012/10/5 sly (sylvain letuffe) li...@letuffe.org:


 Sinon, comme le propose Marc à coté, avec OverpassAPI et son langage plus
 complet on doit pouvoir faire ça en un coup

A noter que toutes ces opérations ne sont utiles que si tu veux
automatiser. Et aussi que le admin_level=8 n'est pas universel. Si ça
reste, comme il dit, pour quelques grandes villes mondiales, on peut
aussi bien récupérer les id des relations directement avec un éditeur
avant de récupérer les données avec le
.../api/0.6/relation/relation_id/full

Pieren


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


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


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

[OSM-talk-fr] Delta du haut-niger Mali, problème avec tag landuse=farmland

Le delta du Haut-Niger au Mali contient de vastes zones qui sont inondées à 
chaque année à la période des pluies. Ces zones inondables sont en grande 
partie des fermes. J'ai cartographié la zone entre Bourem et Gao avec succès 
sauf une petite zone près de Taboye où les zones inondables ne s'affichent pas 
correctement.

Pour représenter les contours du fleuve, j'ai créé des relations multipolygone, 
waterway=riverbank avecdes rôles outer pour les contours externes et des rôles 
inner pour les îles. Le tout s'affiche correctement.


Pour représenter les fermes en zone inondable, j'ai utilisé lesdeux tags 
suivants : landuse=farmland et flood_prone=yes. Je me suis également assuré que 
dans les polygones représentant les îles, la terre soit toujours à gauche du 
chemin.


Les zones inondables apparaissent en rosé avec la couche OSM-Mapnik.  
Cependant,  pour la relation 2069385, plusieurs îles ne s'affichent pas 
correctement. Quelqu'un peut-il m'aider à identifier le problème avec ces îles? 
Y-a-t-il un outil qui pourrait aider à identifier de tels problèmes?

relation avec zones farmland non reconnues voir 
http://www.openstreetmap.org/?relation=2069385
autres relations à proximité
http://www.openstreetmap.org/?relation=2069384
http://www.openstreetmap.org/?relation=2312915
 
Pierre ___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Petite question overpassAPI

Ce qui serait bien pour les copains hors France, ce serait d'utiliser une 
relation pour définir la zone à analyser. 

On pourrait par exemple définir France, Mali, Québec, etc.À ma connaissance, il 
n'est pas encore possible de le faire.

 
Pierre 




 De : sly (sylvain letuffe) li...@letuffe.org
À : Discussions sur OSM en français talk-fr@openstreetmap.org 
Envoyé le : Jeudi 4 octobre 2012 10h16
Objet : Re: [OSM-talk-fr] Petite question overpassAPI
 
On jeudi 4 octobre 2012, Nicolas Moyroud wrote:
  Bonjour,
  
  Je voudrais poser une petite question sur un truc qui m'échappe à propos de
  requêtes avec la overpassAPI. Quand je veux lancer une requête sur un type
  d'objets sur une grande zone (on va dire la France entière), je précise la
  bbox. Sauf que quand je fais ça la requête est très très longue et souvent
  me jette avant la fin. Par contre, si je lance la même requête sans la
  bbox, alors ça marche sans problème et ça va beaucoup plus vite.    

Je vais d'abord répondre : tiens tiens, es-tu sûr ? style, peux tu indiquer 
les deux requêtes que tu fais pour voir ?

Ensuite je vais répondre, oui, il se peut (ou du moins il me semble me 
souvenir avoir eu le cas) que lorsque la bbox est énorme style taille de la 
france, ça soit pire à traiter que si elle n'est pas là du tout.

Si nous sommes plusieurs à en avoir besoin, je vais alors peut-être installer 
une base overpass uniquement sur la France, cela devrait faciliter plein de 
requêtes sur la france


  Du coup, je me dis que je n'ai pas tout à fait bien compris à quoi sert
  cette bbox. 

Peut-être juste qu'elle marche bien quand elle est petite (et en effet, en 
dessous de 1° de coté, ça marche plutôt bien)

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

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


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

Re: [OSM-talk-fr] Petite question overpassAPI

Sylvain,

Effectivement, l'Api me retourne un message indiquant que seuls les nodes sont 
traitées.


Ce serait donc intéressant de pouvoir traiter de grandes relations type pays et 
de pouvoir spécifier autre chose que des nodes.

 
Pierre 




 De : sly (sylvain letuffe) li...@letuffe.org
À : Discussions sur OSM en français talk-fr@openstreetmap.org 
Envoyé le : Jeudi 4 octobre 2012 11h18
Objet : Re: [OSM-talk-fr] Petite question overpassAPI
 
On jeudi 4 octobre 2012, Pierre Béland wrote:
 Ce qui serait bien pour les copains hors France, ce serait d'utiliser une
 relation pour définir la zone à analyser.  

En effet, mais c'est pas super simple en l'état des outils.

 On pourrait par exemple définir France, Mali, Québec, etc.À ma connaissance,
 il n'est pas encore possible de le faire. 

Il existe un petit quelque chose quand même :
ça :
http://api.openstreetmap.fr/#section.data_structures
avec exemple là :
https://help.openstreetmap.org/questions/15748/extract-statistics-for-a-city

Toutefois, ça ne marche que pour les noeuds et je ne suis pas sûr que ça 
marche super bien pour des relations géantes de type taille d'un pays


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

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


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

Re: [OSM-talk-fr] Delta du haut-niger Mali, problème avec tag landuse=farmland

De façon à illustrer plus succintement le problème présenté plus tôt, voici 
deux îles sur le fleuve Niger qui sont définies dans OSM avec 
les mêmes attributs mais ont un rendu différent dans Mapnik. 


Les deux îles sont inclues dans une relation riverbank, toutes deux avec un 
rôle inner. Le contour du fleuve et les îles sont affichés correctement. Par 
contre, Mapnik ne reconnait l'attribut landuse=farmland que pour une des deux 
îles (zone rosée). Ce même problème se pose pour plusieurs îles faisant parti 
de cette relation. Si j'utilise le style Mapnik dans JOSM, ces îles s'affichent 
correctement.


Les deux chemins décrivant les îles ont les attributs (ie. flood_prone = yes 
landuse = farmland) :http://www.openstreetmap.org/browse/way/168321975
http://www.openstreetmap.org/browse/way/168369481


Dans la relation 2069385, ces deux polygones ont le rôle inner.
La relation contient les attributs suivants : 
type = multipolygon 
waterway = riverbank 
Rendu Mapnik pour la relation : http://www.openstreetmap.org/?relation=2069385


D'où peut venir le problème? Quelques pistes de solution?


 
Pierre 




 De : Pierre Béland infosbelas-...@yahoo.fr
À : Discussions sur OSM en français talk-fr@openstreetmap.org 
Envoyé le : Jeudi 4 octobre 2012 10h50
Objet : [OSM-talk-fr] Delta du haut-niger Mali, problème avec tag 
landuse=farmland
 

Le delta du Haut-Niger au Mali contient de vastes zones qui sont inondées à 
chaque année à la période des pluies. Ces zones inondables sont en grande 
partie des fermes. J'ai cartographié la zone entre Bourem et Gao avec succès 
sauf une petite zone près de Taboye où les zones inondables ne s'affichent pas 
correctement.

Pour représenter les contours du fleuve, j'ai créé des relations 
multipolygone, waterway=riverbank avecdes rôles outer pour les contours 
externes et des rôles inner pour les îles. Le tout s'affiche correctement.



Pour représenter les fermes en zone inondable, j'ai utilisé lesdeux tags 
suivants : landuse=farmland et flood_prone=yes. Je me suis également assuré 
que dans les polygones représentant les îles, la terre soit toujours à gauche 
du chemin.



Les zones inondables apparaissent en rosé avec la couche OSM-Mapnik.  
Cependant,  pour la relation 2069385, plusieurs îles ne s'affichent pas 
correctement. Quelqu'un peut-il m'aider à identifier le problème avec ces 
îles? 
Y-a-t-il un outil qui pourrait aider à identifier de tels problèmes?


relation avec zones farmland non reconnues voir 
http://www.openstreetmap.org/?relation=2069385
autres relations à proximité
http://www.openstreetmap.org/?relation=2069384
http://www.openstreetmap.org/?relation=2312915
 
Pierre 



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


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

Re: [OSM-talk-fr] Delta du haut-niger Mali, problème avec tag landuse=farmland

Marc,

Le style Mapnik fonctionne correctement dans JOSM. Par contre, non avec 
certaines îles dans cette relation. Il y a plusieurs relations avec des 
caractéristiques similaires le long du Niger et qui fonctionnent correctement.

Je ne comprend pas pourquoi le problème proviendrait de l'assemblage contenu 
dans la relation. Celle-ci contient des membres avec des rôles outer et inner 
définissant et le contour et les zones à exclure. Ceci est rendu correctement. 

Ensuite il y a une série de polygones, les îles avec un tag landuse=farmland + 
flood_prone=yes. Et c'est là que le problème apparait, puisque ce ne sont pas 
toutes les zones qui sont reconnues et affichées avec zone rosée.

Est-il effectivement possible que le problème soit causé par le rendu Mapnik?  


 
Pierre 




 De : Marc o...@framboisier.fr
À : talk-fr@openstreetmap.org 
Envoyé le : Jeudi 4 octobre 2012 15h15
Objet : Re: [OSM-talk-fr] Delta du haut-niger Mali, problème avec tag 
landuse=farmland
 

Jolie dentelle!!!
J'ai regarder, et je n'ai pas vu d'écart des les tags et la
  géométrie me semble correcte... Mapnik ne comprend pas ce que tu
  veux faire ?

Le 04/10/2012 20:26, Pierre Béland a écrit :

De façon à illustrer plus succintement le problème présenté plus tôt, voici 
deux îles sur le fleuve Niger qui sont définies dans OSM avec les mêmes 
attributs mais ont un rendu différent dans Mapnik. 
 


Les deux îles sont inclues dans une relation riverbank, toutes deux avec un 
rôle inner. Le contour du fleuve et les îles sont affichés correctement. Par 
contre, Mapnik ne reconnait l'attribut landuse=farmland que pour une des deux 
îles (zone rosée). Ce même problème se pose pour plusieurs îles faisant parti 
de cette relation. Si j'utilise le style Mapnik dans JOSM, ces îles 
s'affichent correctement.



Les deux chemins décrivant les îles ont les attributs (ie. flood_prone = yes 
landuse = farmland) :http://www.openstreetmap.org/browse/way/168321975
http://www.openstreetmap.org/browse/way/168369481



Dans la relation 2069385, ces deux polygones ont le rôle inner.
La relation contient les attributs suivants : 
type = multipolygon 
waterway = riverbank 
Rendu Mapnik pour la relation : http://www.openstreetmap.org/?relation=2069385


D'où peut venir le problème? Quelques pistes de solution?


 
 





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

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


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

Re: [OSM-talk-fr] Delta du haut-niger Mali, problème avec tag landuse=farmland

Extraordinaire Pieren

Quelques coups de serpes ici et là, et ça a commencé a régler le problème. Je 
vais donner encore quelques coups et voir à nouveau le résultat.  

Espérons que je ne ferai couler aucune île.


 
Pierre 




 De : Pieren pier...@gmail.com
À : Pierre Béland infosbelas-...@yahoo.fr; Discussions sur OSM en français 
talk-fr@openstreetmap.org 
Envoyé le : Jeudi 4 octobre 2012 16h38
Objet : Re: [OSM-talk-fr] Delta du haut-niger Mali, problème avec tag 
landuse=farmland
 

2012/10/4 Pierre Béland infosbelas-...@yahoo.fr

 
Je ne comprend pas pourquoi le problème proviendrait de l'assemblage contenu 
dans la relation. Celle-ci contient des membres avec des rôles outer et inner 
définissant et le contour et les zones à exclure. Ceci est rendu correctement. 



Si c'est un bug mapnik ou oms2pgsql, tu n'as qu'à inverser l'ordre des deux 
îles dans la relation et légèrement modifier leur géométrie pour relancer le 
rendu et voir si le problème s'est déplacé.

Pieren



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

Re: [OSM-talk-fr] Contributeur hyperactif mais pas très précis

2012-10-03 Per discussione Pierre Béland

Le lien Documentation sur la page OpenStreetMap.org nous amène à 
http://wiki.openstreetmap.org/wiki/Main_Page puis la version française 
http://wiki.openstreetmap.org/wiki/FR:Main_Page.

La page d'introduction à OSM en anglais est plus synthétique que celle en 
français.  On y retrouve de brève description avec un renvoi à une page 
secondaire.
Je propose de restructurer la page française de la même façon.

Aussi, les nouveaux contributeurs ne retrouvent pas facilement de l'info 
pertinente pour eux. Après la section Les projets francophones, nous pourrions 
ajouter une section Support aux nouveaux contributeurs (Personnes à contacter, 
liste de diffusion où vous pouvez discuter avec les autres contributeurs).  On 
pourrait y donner des noms de contacts par pays / région.  On pourrait aussi 
spécifier que OSM est un projet collaboratif, que la communauté des 
contributeurs met en place divers moyens pour assurer la qualité. Dans ce cadre 
vous pourrez être contactés pour discuter de modifications que vous avez 
apportés. Le tout se fait dans un esprit de collaboration. Lorsque les membres 
ne peuvent s'entendre sur les modifications à apporter, ils viennent simplement 
discuter sur les listes de diffusion avec les autres membres de la communauté 
OSM.

Cette même information pourrait être reprise sur les wiki nationaux / par 
région.

Pierre 





 De : sly (sylvain letuffe) li...@letuffe.org
À : Discussions sur OSM en français talk-fr@openstreetmap.org 
Envoyé le : Mercredi 3 octobre 2012 10h09
Objet : Re: [OSM-talk-fr] Contributeur hyperactif mais pas très précis
 
 Mais alors comment faire ?

Voilà la bonne question que ce fil aura le mérité d'avoir lancé !

J'ai retenu du débat plusieurs idées qui me semblent bonnes :
- écrire des règles (non coercitives et coercitives) de bonne pratiques 
qu'elles soit en complément des règles internationales, ou, recommandées pour 
la france car un peu locales.
Une sorte de : vous cartographiez en france ? voici quelques bons tuyaux à 
lire pour être en cohérence avec la communauté française
Que l'on puisse pointer à ceux qui font des trucs en désaccord avec ces règles

- créer un groupe d'intervention : surveillance/accompagnement/gestion 
vandalismes|conflits/diplomatie
(disposant par exemple de contributeurs chevronnés inscrits à une liste 
dédiée)
auquel on puisse soumettre ses trouvailles de untel il fait rien qu'a tracer à 
la hâche à travers les bâtiments et il n'a pas répondu à mon message, que 
faire ?

 Lorsque j'ai lançé ce sujet, c'est justement parce que je ne savais pas 
 trop comment réagir.
Tu as bien fais.
J'ai juste dis ça ne me semble pas adapté de le faire ici, désolé si je n'ai 
pas été clair et que j'ai moi même paru inquisiteur, mais je sous-entendais 
aussi qu'il n'y a aucun endroit pour faire ça pour l'instant et que je 
trouverais bien qu'on réfléchisse à une alternative.


 Est-ce que je fixais le curseur qualité trop haut ?
Rien à dire de ce coté, il y avait quelque chose à dire et il fallait le dire 
sans quoi ça allait empirer, je m'interroge sur comment faire au mieux (si 
mieux il y a)

 J'avais besoin d'avis extérieur avant de réagir. C'est ça aussi un 
 travail collaboratif, non ?

Oui, mais il y a sur cette liste des gens bien chauds qui, (mais je ne cite 
personne, c'est juste pour foutre la merde ;-)) ) semblent dégainer 
rapidement une part de leur frustration, pour, sans doute, avoir eux aussi 
constaté qu'un contributeur avait amoindrie la qualité de leur travail dans 
d'autres lieux et d'autres circonstances.
Je ne critique pas le fond, je ressens parfois la même chose, mais je cherche 
une solution pour réduire les lynchages publics

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

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


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

Re: [OSM-talk-fr] route forestière: unclassified ou track/tracktype=grade1 ?

2012-10-02 Per discussione Pierre Béland

Christian, 

À chaque pays sa réalité.  Le nord du Québec est plus grand que la France et 
moins de 50 000 personnes y habitent.  On y retrouve de longues routes 
forestières dans tous les sens du terme si je peux dire.  Ces longues routes 
sans bithume et pleines d'ornières ne sont pas très adaptées pour les 
voitures.  Elles servent au transport de bois, aux mines, aux centrales 
hydro-électriques, etc. Le lien ci-dessous montre une route accessible 
uniquement à partir de l'aéroport de du site Poste-Montagnais de la société 
d'électricité Hydro-Québec. Ce poste de transport d'électricité est à 160km au 
nord de Sept-Îles. Près de 1 000km plus loin se trouve le principal marché du 
Québec où est acheminée cette électricité. Tu veux taguer les pilones? Il y a 
souvent 3 lignes en parallèle.

voir www.openstreetmap.org/?way=183886475

Pour l'instant je vais me contenter de classifier highway=unclassified.
 

Pierre 




 De : Christian Rogel christian.ro...@club-internet.fr
À : Discussions sur OSM en français talk-fr@openstreetmap.org 
Envoyé le : Mardi 2 octobre 2012 11h52
Objet : Re: [OSM-talk-fr] route forestière:  unclassified ou 
track/tracktype=grade1 ?
 



Le 2 oct. 2012 à 08:10, jb...@mailoo.org a écrit :

track = chemin privé ? 
Je suis le seul à tiquer ? Privé va être déterminé par access=*, pas par 
track, il me semble ? 
Le wiki parle de chemin de type agricole, forestier. 
http://wiki.openstreetmap.org/wiki/Tag:highway%3Dtrack
JBEnfin, je vois que ma petite provocation au débat marche.


Mon interrogation est, en fait, la suivante :
Nous transposons un système au moins  anglais-gallois (pour l'Ecosse, je n'ai 
pas vérifié) dans lequel il devrait
y avoir toutes les voies publiques, car l'axe public/privé est une donnée 
forte pour un cartographe, puisque
des usages différenciés s'ensuivent.


Or, cette donnée de propriété qui est à la base des highways supérieurs 
semblent s'effacer brusquement,
lorsqu'il manque un peu de goudron.


Il y a d'ailleurs des chemins communaux qui ont des revêtements mixtes  
goudron ou macadam (pierres 
compactées) et ornières de terre.Bref, est-il juste de hiérarchiser les 
chemins communaux par leur aspect plutôt que par leur statut?
Je vous rappelle qu'ils ont tous la même référence commençant par C nn.



C'est pourquoi, il m'aurait semblé cohérent que  l'access ne concerne les 
chemins privés (private/permissive),
les chemins publics l'étant par défaut (droit constitutionnel d'aller et 
venir).


Pour ce qui est de ma pratique, j'ai commencé avec track, puis j'ai mis 
récemment des chemins ruraux non
revêtus en unclassified, surtout s'il sont en pays calcaire où on peut faire 
des compactés d'aspect  quasiment 
naturel et presque sans entretien.


Sinon, à quoi sert unpaved (non revêtu)? Avez-vous des exemples?


Comme je l'ai dit, pour la route forestière, comme elle n'est pas publique au 
sens du réseau routier A/N/D/M/C, 
elle ne peut, en aucun cas, être unclassified, même si elle appartiennent 
aux Domaines, via l'ONF, car, il s'agit 
alors du domaine privé de l'Etat.


Christian Rogel




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


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

[OSM-talk] Re : Community Edit Monitoring vs Worldwide BOT Coverage in Changesets

2012-10-01 Per discussione Pierre Béland



Thanks Ilya.
 Pierre 




 De : Ilya Zverev zve...@textual.ru
À : Talk talk@openstreetmap.org 
Envoyé le : Lundi 1 octobre 2012 1h28
Objet : [OSM-talk] Community Edit Monitoring vs Worldwide BOT Coverage in 
Changesets
 
Pierre Béland wrote:
 The changesets listed were reduced by half when providing the url 
 http://www.openstreetmap.org/browse/changesets?bbox=-73.6318%2C45.409%2C-73.444%2C45.4946
  with http://positron96.appspot.com/osmfilter.html.

 This solution would effectively eliminate an important amount of changesets 
 from the History Report if it was adopted.


 Therefore, this solution does not cover all the situations. When a 
worldwide changeset covers partly a local area, it is quite uneasy to 
detect wich objects were modified in this local area. Especially 
when the changeset  affects
 hundreds of objects.

Try 
http://zverik.osm.rambler.ru/whodidit/scripts/rss.php?bbox=-73.6318%2C45.409%2C-73.444%2C45.4946___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

[OSM-talk] Community Edit Monitoring vs Worldwide BOT Coverage in Changesets

2012-09-30 Per discussione Pierre Béland

The Changeset Display for an area (ie. History tab of OpenStreetMap.org) 
shows all the changesets covering a local area. In this display, we often see 
Worldwide 
BOT Changesets even if there is no modifications made to the area,. RSS feeds 
are producing false alerts, and it is uneasy to find if any changes are made to 
the local area. We sometimes have to go to hundreds of modifications in the 
Changeset to verify if the local area is affected.


This Worldwide coverage in Changesets limits our capacity to simply monitor 
changes to the map and OSM  conributors have often complain about this.


Automated Edits code of conduct [1] and Mechanical Edit Policy [2] wiki pages 
do not talk about restricting Worldwide BOT Coverage in one Changeset.  
Searching the discussion lists, I cannot find discussion / propositions to 
establish rules that limit the coverage.


I then propose to add a a rule for Automated / Mechanical Edits so that an 
individual Changeset do not cover a large area. It could be for example a rule 
that says no more than a 500km x 500km.


Pierre 

[1] http://wiki.openstreetmap.org/wiki/Automated_Edits_code_of_conduct
[2] http://wiki.openstreetmap.org/wiki/Mechanical_Edit_Policy___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Community Edit Monitoring vs Worldwide BOT Coverage in Changesets

2012-09-30 Per discussione Pierre Béland

Thanks Pavel

The changesets listed were reduced by half when providing the url 
http://www.openstreetmap.org/browse/changesets?bbox=-73.6318%2C45.409%2C-73.444%2C45.4946
 with http://positron96.appspot.com/osmfilter.html.

This solution would effectively eliminate an important amount of changesets 
from the History Report if it was adopted.


Therefore, this solution does not cover all the situations. When a worldwide 
changeset covers partly a local area, it is quite uneasy to detect wich objects 
were modified in this local area. Especially when the changeset  affects 
hundreds of objects. 

If changesets were limited to one country (or nearby countries when crossing 
borders), there would be even less changesets reported in a local area. 
Changesets would also contain less objects. 

Both revising the History Report and establishing rule to restrict the coverage 
area of changesets would facilitate monitoring in a local area. 
 
Pierre 




 De : Pavel Melnikov positro...@gmail.com
À : Pierre Béland infosbelas-...@yahoo.fr 
Cc : talk talk@openstreetmap.org 
Envoyé le : Dimanche 30 septembre 2012 12h29
Objet : Re: [OSM-talk] Community Edit Monitoring vs Worldwide BOT Coverage in 
Changesets
 

Hello Pierre.



I think the better way to solve this problem is to make history page show 
changesets that actually affect the area in question, not changesets thatonly 
cover area. There are some works in this direction, the most recent seems to 
be http://zverik.osm.rambler.ru/whodidit/ . There was OWL which is now down, 
but is promised to be back. 

Also, there is an automated filter for RSS history feeds: 
http://positron96.appspot.com/osmfilter.html - the service can filter out 
large changesets from rss feed, and give you with filtered feed.

Hope it helps.



Pavel


On Sun, Sep 30, 2012 at 9:26 PM, Pierre Béland infosbelas-...@yahoo.fr wrote:

The Changeset Display for an area (ie. History tab of OpenStreetMap.org) 
shows all the changesets covering a local area. In this display, we often see 
Worldwide 
BOT Changesets even if there is no modifications made to the area,. RSS feeds 
are producing false alerts, and it is uneasy to find if any changes are made to 
the local area. We sometimes have to go to hundreds of modifications in the 
Changeset to verify if the local area is affected.



This Worldwide coverage in Changesets limits our capacity to simply monitor 
changes to the map and OSM  conributors have often complain about this.


Automated Edits code of conduct [1] and Mechanical Edit Policy [2] wiki pages 
do not talk about restricting Worldwide BOT Coverage in one Changeset.  
Searching the discussion lists, I cannot find discussion / propositions to 
establish rules that limit the coverage.


I then propose to add a a rule for Automated / Mechanical Edits so that an 
individual Changeset do not cover a large area. It could be for example a 
rule that says no more than a 500km x 500km.



Pierre 

[1] http://wiki.openstreetmap.org/wiki/Automated_Edits_code_of_conduct
[2] http://wiki.openstreetmap.org/wiki/Mechanical_Edit_Policy
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk




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

Re: [OSM-talk-fr] [OSM-talf-fr] Magazine Geo - septembre

2012-09-28 Per discussione Pierre Béland

J'ai aussi lu l'article. L'objectif est surtout de présenter les groupes de 
développeurs africains.

Je
 n'ai vu qu'une seule mention de OSM à la fin de l'article. Ça ne montre
 pas le travail fait par OSM, ni l'écosystème où développeurs 
Open-Source, contributeurs OSM, le monde de l'Open-Data en général, 
travaillent ensemble et sans frontières. Mais bon, c'est un autre sujet.

 
Pierre 




 De : Ab_fab gamma@gmail.com
À : Discussions sur OSM en français talk-fr@openstreetmap.org 
Envoyé le : Vendredi 28 septembre 2012 12h02
Objet : [OSM-talk-fr] [OSM-talf-fr] Magazine Geo - septembre
 

Bonjour,


J'ai lu le numéro de septembre de Geo (consacré en grande partie à l'Afrique) :
http://www.geo.fr/en-kiosque/magazine-geo-special-afrique-septembre-2012-105805 


et quelle n'y fut pas ma surprise d'y trouver un article d'une dizaine de 
pages citant Map Kibera, Ushaidi, OpenStreetMap et aux initiatives Open Source.


J'apporte le magazine au pub ce soir, pour ceux que cela intéresse. 
Je viens de scanner l'article, je le déposerai en ligne sous peu.


-- 
ab_fab
Il n'y a pas de pas perdus

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


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

Re: [OSM-talk-fr] maj présentation layers

2012-09-22 Per discussione Pierre Béland

J'ai utilisé pour identifier / valider les limites administratives existantes 
dans la région de Montréal.

Très utile.


http://layers.openstreetmap.fr/?zoom=9lat=45.43377lon=-73.71779layers=B00FFFTF

 Pierre 





 De : Jocelyn Jaubert jocelyn.jaub...@gmail.com
À : talk-fr@openstreetmap.org 
Envoyé le : Samedi 22 septembre 2012 8h55
Objet : Re: [OSM-talk-fr] maj présentation layers
 
Le 22 septembre 2012, PierreV a écrit :
 Bonjour,
 
 Utilisateur du layers voirie/cadastre depuis pas mal de temps pour
 déterminer les communes a mapper je ne retrouve pas l'ancien
 service? certes il y a un calque activable, mais chez moi il
 n'affiche que les nom des communes mais pas de couleur... :(

Le service est normalement en route, sur http://layers.openstreetmap.fr

Est-ce que tu peux donner un Permalink de l'endroit qui ne marche pas
correctement ?


Merci,
Jocelyn

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


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

Re: [OSM-talk] Import guidelines proposal update

2012-09-20  Frederik Ramm


 However, every once in a while DWG gets a complaint about a particular 
user making lots of edits that are questionable.
 Not outright vandalism 
or edit warring, but something exotic enough to make other mappers in 
the area uneasy.
 The other mappers watch the user in question but it is 
hard to watch him because all his changeset comments are just small 
fixes. 

 The other mappers try to contact the user but he never replies.

 In
 cases like this, I have occasionally told the mapper in question that 
OSM is a teamwork project, and that he must be a teamplayer
 and 
communicate with his peers, else we cannot use his work even if it is 
good. I have occasionally had to put a block on people like
 that in 
order to get them to reply at all.

This is not only a question of guidelines. And the DWG  role is more of last 
intervention when the community was not able to discuss with mappers and 
correct the situation.

The DWG work would be facilitated if communications were developped with local 
communities and first contacts made by these local communities. 


This would also contribute to develop more experienced and responsible mappers. 
To my point of view, it is essential to favorize development of local 
communities, to empower these communities with tools adapted to them.
 
Pierre 




 De : Frederik Ramm frede...@remote.org
À : talk@openstreetmap.org 
Envoyé le : Vendredi 21 septembre 2012 9h40
Objet : Re: [OSM-talk] Import guidelines proposal update
 
Hi,

On 09/21/12 14:12, sly (sylvain letuffe) wrote:
 No problems, let's discuss. But while we do talk about a future rule, the
 previous one should (I mean must) still apply until the new one is ready to
 replace it.

This is not about one rule. This is about the whole question of rules and 
authority.

 No need to say what was the previous rule right ?

You mean the previous rule as in yesterday? Half a year ago? Two years ago? Or 
back when we had nodes and segments in our data model ;)

The current situation is that DWG does their job as they see fit and defines 
rules they think are necessary.

For example: We do not have a rule in OSM that says you must use a changeset 
comment, and we don't have a rule that says you must reply when other 
mappers send you messages. It's good style to do it but there's no rule that 
you *must*.

Creating rules for these situations would be awkward - it would raise all 
kinds of questions like what exactly counts as a reply and so on. And it 
would also sound like contributing to OSM was a major problem because there 
are so many rules.

So we don't have any.

However, every once in a while DWG gets a complaint about a particular user 
making lots of edits that are questionable. Not outright vandalism or edit 
warring, but something exotic enough to make other mappers in the area uneasy. 
The other mappers watch the user in question but it is hard to watch him 
because all his changeset comments are just small fixes. The other mappers 
try to contact the user but he never replies.

In cases like this, I have occasionally told the mapper in question that OSM 
is a teamwork project, and that he must be a teamplayer and communicate with 
his peers, else we cannot use his work even if it is good. I have occasionally 
had to put a block on people like that in order to get them to reply at all.

Now there's no written rule for this. If the guy started a thread on the talk 
list about where is it written that you need to respond to emails? I 
would not even be able to point to a wiki page - it's simply something that we 
take for granted.

The separate account rule is just such a rule, that DWG has created to do 
their job. I will not continue discussing this: As long as DWG have to clean 
up the mess they will make the rules governing imports and mechanical edits. 
Exceptions from the rules can be negotiated with DWG in advance if someone 
thinks they really need one.

I say as long as... because the subsidiarity I mentioned in my post is a 
real possibility; if the French community has a couple of willing and capable 
people maybe we could experiment with setting up a sub-DWG responsible for 
France only. Maybe we should just try it out and see if it improves the 
situation.

Bye
Frederik

-- Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09 E008°23'33

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


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

Re: [OSM-talk] Improved coastline view in OSM Inspector

2010-09-21 Jochen Topf
  I have just added a change to the OSM Inspector which now shows even more
  potential coastline errors in the new Questionable category.

Jochen, it is a nice addition. 


Looking at the map, I see all of America coastline being tagged with Invalid 
geometry. 


Invalid geometry definition : Invalid for some unspecified reasons. This is 
never supposed to happen and must be fixed.

This definition is ambiguous to me. Do you mean that we should not see this 
error or that we have to fix something.


Other then that, with such a long coastline, it is difficult to detect where 
the error is.

Pierre 




 De : Jochen Topf joc...@remote.org
À : talk@openstreetmap.org 
Envoyé le : Vendredi 21 septembre 2012 14h52
Objet : [OSM-talk] Improved coastline view in OSM Inspector
 
I have just added a change to the OSM Inspector which now shows even more
potential coastline errors in the new Questionable category.  Questionable
shows coastline rings with possible problems. There are several different kinds
of problems that are shown in this way: a) Coastline rings that touch other
coastline rings in a single point. Those should probably be fixed. b) Coastline
rings having the wrong direction. Those should be fixed. c) Smaller water areas
inside a continent. Those should probably be changed to use natural=water or
similar tags. Use your judgement in all these cases! 

See http://tools.geofabrik.de/osmi/?view=coastline

Jochen
-- 
Jochen Topf  joc...@remote.org  http://www.remote.org/jochen/  +49-721-388298

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


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

Re: [OSM-talk] Improved coastline view in OSM Inspector

2012-09-21 Jochen Topf 


pb Invalid geometry definition : Invalid for some unspecified reasons. This 
is never supposed to happen and must be fixed.
pb This definition is ambiguous to me. Do you mean that we should not see 
this error or that we have to fix something.

 
 This is described a bit better on the wiki page for this view at
 http://wiki.openstreetmap.org/wiki/OSM_Inspector/Views/Coastline

 I changed the short message to be a bit more helpful:
 Geometry is invalid for some unspecified reason. Fix all other errors shown
 and this should go away.

Jochen, looking more deeply without showing lines, I found that the problem 
arises north of Long Island New-York where we see Intersection nodes. In fact, 
i see two coaslines polygons crossing one over the other.
Thanks a lot for this.


Pierre 




 De : Jochen Topf joc...@remote.org
À : Pierre Béland infosbelas-...@yahoo.fr 
Cc : talk@openstreetmap.org talk@openstreetmap.org 
Envoyé le : Vendredi 21 septembre 2012 16h00
Objet : Re: [OSM-talk] Improved coastline view in OSM Inspector
 
On Fri, Sep 21, 2012 at 08:50:03PM +0100, Pierre Béland wrote:
 2010-09-21 Jochen Topf
   I have just added a change to the OSM Inspector which now shows even more
   potential coastline errors in the new Questionable category.
 
 Jochen, it is a nice addition. 
 
 
 Looking at the map, I see all of America coastline being tagged with Invalid 
 geometry. 
 
 
 Invalid geometry definition : Invalid for some unspecified reasons. This is 
 never supposed to happen and must be fixed.
 
 This definition is ambiguous to me. Do you mean that we should not see this 
 error or that we have to fix something.
 
 
 Other then that, with such a long coastline, it is difficult to detect where 
 the error is.

This is described a bit better on the wiki page for this view at
http://wiki.openstreetmap.org/wiki/OSM_Inspector/Views/Coastline

I changed the short message to be a bit more helpful:
Geometry is invalid for some unspecified reason. Fix all other errors shown
and this should go away.

Jochen
-- 
Jochen Topf  joc...@remote.org  http://www.remote.org/jochen/  +49-721-388298


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

Re: [OSM-talk] Import guidelines proposal update

2012-09-21 Lester Caine

What I have been asking is how we can manage on-going imports of a 
dataset that is being updated regularly. This is probably on 'off-line' 
function, and could well be managed by the 'local chapter' on their own 
computers. This is the 'process' I'm looking to be developed, so that 
the raw import data is held in a format that later imports can be 
compared against, and only differences then get further procession. 
Breaking this process down into provinces, and importing the 
pre-processed RAW data via an import account gives us a clean base which
 mappers can then work against and improve the data ... and changes to 
the 'imported' data would then be mirrored back to the staging process. 
Seeing that an element is version 1 by the import user immediately tells
 you that it may need additional local information adding ( we need to 
be able to see who last edited an object! ). Where the import HAS nice 
unique object identifiers things are a lot easier, but raw vector data 
like the French import, and I think the Spanish data you are talking 
about CAN still be 'diffed' against earlier imports, and result in 
perhaps new data that can simply be imported, or perhaps an overlay that
 identifies conflicts that need a human eye. Isn't it better to spend 
time working out a GOOD way of using the data going forward rather than 
having to manually merge the whole lot again in a couple of years time 
... and every couple of years.


In Canada, Natural Ressources Canada, the national mapping agency is 
collaborating with OSM, producing OSM import files from is topographic database 
Canvec. The OSM collaborators are following a procedure to carefully integrate 
this data into OSM. 

NRCan compared recently Osm and Canvec data for planning road network update 
field work for Canvec. They also provided this helpful information to the OSM  
community with detected differences. 
see http://lists.openstreetmap.org/pipermail/talk-ca/2012-July/004934.html


I think that this shows that even without an unique ID, it is possible to 
develop monitoring tools of imports.  The fixme attribute is used to monitor 
differences between the two databases. The Fixme Highlight Warnings style, in 
JOSM,  offers the possibility to monitor database discrepancies.
 

Pierre 




 De : Lester Caine les...@lsces.co.uk
À : OSM talk@openstreetmap.org 
Envoyé le : Vendredi 21 septembre 2012 17h33
Objet : Re: [OSM-talk] Import guidelines proposal update
 
andrzej zaborowski wrote:
 Well, this time a
 single import account has been registered per province with a single
 person coordinating the (potential) imports in each province.  The
 assignments have been documented on the wiki.  This is better but the
 account names are still not directly linked with real people, and the
 division by provinces is artificial because the data was supposed to
 be uploaded by users only for the areas they know personally, which
 may be on village level for example.

To my eyes that provides a perfect base to work from, but if you have not been 
following the thread ...

What I have been asking is how we can manage on-going imports of a dataset 
that is being updated regularly. This is probably on 'off-line' function, and 
could well be managed by the 'local chapter' on their own computers. This is 
the 'process' I'm looking to be developed, so that the raw import data is held 
in a format that later imports can be compared against, and only differences 
then get further procession. Breaking this process down into provinces, and 
importing the pre-processed RAW data via an import account gives us a clean 
base which mappers can then work against and improve the data ... and changes 
to the 'imported' data would then be mirrored back to the staging process. 
Seeing that an element is version 1 by the import user immediately tells you 
that it may need additional local information adding ( we need to be able to 
see who last edited an object! ). Where the import HAS nice unique object 
identifiers things are a lot easier, but raw
 vector data like the French import, and I think the Spanish data you are 
talking about CAN still be 'diffed' against earlier imports, and result in 
perhaps new data that can simply be imported, or perhaps an overlay that 
identifies conflicts that need a human eye. Isn't it better to spend time 
working out a GOOD way of using the data going forward rather than having to 
manually merge the whole lot again in a couple of years time ... and every 
couple of years.

-- Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

___
talk mailing list
talk@openstreetmap.org

Re: [OSM-talk-fr] Rencontre OSM parisienne de septembre


Cahors et Madiran, je connais bien. Mais , Pacherenc, je vais devoir l'ajouter 
à mon dictionnaire de dégustation.
 
Pierre 




 De : Hélène PETIT h...@free.fr
À : Discussions sur OSM en français talk-fr@openstreetmap.org 
Envoyé le : Vendredi 21 septembre 2012 15h25
Objet : Re: [OSM-talk-fr] Rencontre OSM parisienne de septembre
 
Le 19/09/2012 14:17, Christian Quest a écrit :
 Est-ce que le vendredi 28 vous va ?

Je serai probablement à Paris le 28 ; vous accepteriez une pièce rajoutée ? 
Cahors, Pacherenc ou Madiran ?

Hélène


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


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

Re: [OSM-talk] [Imports] Import guidelines proposal update


On Thu, Sep 20, 2012 at 9:34 AM, Lester Caine les...@lsces.co.uk wrote:

Check the list of arguments presented here for the mandatory separate account:

1. it's easier to separate from normal contributions
2. it's more effecient for sourcing
3. it's easier to identify the source if we change the license. We
faced that issue in the past for ODbl transition
Lester 

Is a separate account is the better and only way to have some metadata 
documenting imports? I don't think so.There are various ways to document 
imports. 


There were discussions on the Import listin 2009. Andy Allan opinion was that 
metadata like attribution should be on the Changeset and not 
on the geo feature. Other like Pieren suggested that it is sometime necessary 
to give attribution on the geo feature. Andy Allen also stated that using a 
dedicated account was 
something he less bothered about.

When uploading to the OSM database, I think that the Changeset comment field 
can be used to both give attribution and indicate that it is bulk edit. This 
will be simple and as efficient. It will be easier to manage for both the 
contributor, the local chapter and the DWG.
 
Pierre ___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] [Imports] Import guidelines proposal update


De : 2012-09-20 Lester Caine lester at lsces.co.uk
 Pieren - please stop banging on about this - we know that the current process 
is flawed but it WAS
 put in place when problems arose in the Canadian 
imports, and it IS current practice. If one 'local group'
 is treated as a 'special case' then we will get into a cycle of 'me to' so 
 please lets 
not got there.
 
Lester

I am a canadian contributor since jan 2010 and follow the Talk-Ca list. I dont 
remember a lot of discussions about this since then. Just some people 
expressing that they dont like imports by principle and prefer having fun 
mapping from gps traces.

How much problems? How much discussions? Any consensus? Where and when?


Pierre 




 De : Lester Caine les...@lsces.co.uk
À : OSM Talk talk@openstreetmap.org 
Envoyé le : Jeudi 20 septembre 2012 7h05
Objet : Re: [OSM-talk] [Imports] Import guidelines proposal update
 
Pieren wrote:
 Check the list of arguments presented here for the mandatory separate 
 account:

Pieren - please stop banging on about this - we know that the current process 
is flawed but it WAS put in place when problems arose in the Canadian imports, 
and it IS current practice. If one 'local group' is treated as a 'special 
case' then we will get into a cycle of 'me to' so please lets not got there.

In your particular case, there are arguments either way, and it may be 
appropriate for someone to say sorry, I don't know that anybody has 
particularly done anything wrong - on either side! - it is just a matter of 
miss-understanding what people are saying? On both sides?

Lets move all this energy into fixing the process and getting a robust 
mechanism moving forward!

-- Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

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


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

Re: [OSM-talk] [Imports] Import guidelines proposal update



2012-09-20 Lester Caine lester at lsces.co.uk
 Comment fields are not documented as well as they should be and the 
'problem' that instigated this thread is to my view of what's
 on line a 
very good example of why there WAS a problem. Correctly flagging 
information is essential and we do perhaps need
 a little more 
'automatic' actions. I can see that the French data is perhaps not 
suited to a 'single import' which is then the problem,
 since multiple 
imports already processed in some way are just as much a problem? Lets 
try and make the 'initial' import as clean
 as possible even if that has 
to be to a staging area from which packets can be taken and manually 
processed. Identification can 
 then be married back to the raw data in a 
location where anybody can see it?

Do you mean that documenting well the comment field would be a satisfactory 
solution?
 
Pierre ___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] [Imports] Import guidelines proposal update


2012-09-20 Lester Caine wrote

 Alright insisting on a 'new account' may be wrong, but identifying the 
'import source' somewhere is not unreasonable?
 We do have the problem of the 'language' used to inform other users and some 
 English translations on some of the
   cadastre import stuff would help?

 I will add that
 I am very much opposed to any suggestion that the database should be 
'carved up' and managed
 by different local groups. The DWG is not ideal, and as far as I am aware 
 would welcome some additional help from
 wherever. But that is the ideal level to oversee the whole picture and 
in the end arbitrate when groups disagree
 amongst themselves. How many 
'border disputes' will we have if we go down that path?

I will speak for the Québec community only. Management in a large organization 
cannot be made centralized only and with a few rules. When we say management, 
we are talking about following mapping and contributors, informing, teaching, 
organizing social events.  


In Canada, we have the Talk-ca discussion  list were most of the discussion is 
in english. And often, there are no tools for monitoriging at regional or local 
level.

I am a HOT member. Our work brings us in many countries were we try to develop 
local communities. We have to adapt to a multitude of cultures not to talk 
about computer literacy and language problems.

The Knight Foundation 575,000$ award should help to adapt Openstreetmap 
infrastructure to the organization. I see two interesting text written by Kate 
Chapman and Mikel Maron of HOT that give good clues.
Kate Chapman, 
http://www.maploser.com/2012/03/29/all-i-want-for-openstreetmap-is-simple/

Mikel Maron  All I want fo OpenStreetMap ... Is Social and Attention 
http://brainoff.com/weblog/2012/03/30/1773

 

Pierre ___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk-fr] Abuse of authority: account blocks related to French cadastre imports

Pieren

Au Québec nous avons un contexte particulier. Nous partageons des imports tels 
que Canvec avec la communauté anglophone des autres provinces, très 
majoritaire. Les discussions sur Talk-Ca se font principalement en anglais et 
ce ne sont pas tous les contributeurs québécois qui peuvent discuter facilement 
en anglais. Sur la liste Talk-Ca, un peu les mêmes personnes qui s'expriment 
sur la liste Talk ont critiqué les imports Canvec avec des arguments du genre 
que c'est tellement plus le Fun de travailler à partir de traces GPS. On se 
demande bien quels sont les objectifs que nous avons lorsque nous développons 
la carte OSM.

Jusqu'à maintenant, la communauté OSM du Québec est peu importante et peu 
structurée. Peu d'événements sont organisés.  Je constate malheureusement que 
les communautés locales sont percues ou négativement ou comme fourmis, ou comme 
quantité négligeable. Et que dire de l'insensibilité par rapport à une 
organisation internationale et multiculturelle.

Je tiens à souligner les efforts faits par la communauté des contributeurs de 
France, les outils développés, la gestion que vous mettez en place.  Espérons 
que les outils que vous développez pourrons servir à d'autres communautés.


Pierre 




 De : Pieren pier...@gmail.com
À : Discussions sur OSM en français talk-fr@openstreetmap.org 
Envoyé le : Jeudi 20 septembre 2012 9h14
Objet : Re: [OSM-talk-fr] Abuse of authority: account blocks related to French 
cadastre imports
 
2012/9/20 Tenshu ten...@gmail.com:

 Est ce que le projet OSM va bien ?
 On parle sérieusement de proscrire les imports ?
 C'est évident que le bâti est tellement plus marrant à détourer à la main
 (je sais je l'ai fait) !

Je devrais plutôt dire que ces personnes militent pour la fin des
imports. Ils savent aussi qu'ils ne sont pas suffisament nombreux pour
pouvoir imposer leur point de vue mais ils le sont à des postes
stratégiques.
Leurs arguments principaux sont : s'il y a trop de données externes,
cela empêche la mise en place d'une communauté de contributeurs
locaux, seule à même de maintenir les données à jour. Ou encore il y
aura moins de nouveaux contributeurs si la carte est déjà relativement
complète. Ou bien certains imports sont de trop mauvaise qualité et
hors de contrôle (on pense en particulier à l'import TIGER aux USA)
et la licence OSM peut changer et devenir incompatible avec celle des
données importées.
Il y a eu un débat public lors d'un précédent SOTM, la vidéo doit
encore être disponible quelque part.

Pieren

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


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

Re: [OSM-talk-fr] Abuse of authority: account blocks related to French cadastre imports

Merci Sylvain,

Je vais regarder le tout de plus près.


 
Pierre 




 De : sly (sylvain letuffe) li...@letuffe.org
À : Discussions sur OSM en français talk-fr@openstreetmap.org 
Envoyé le : Jeudi 20 septembre 2012 11h29
Objet : Re: [OSM-talk-fr] Abuse of authority: account blocks related to French 
cadastre imports
 
Salut pierre !
Et bienvenu sur la liste francophone (si si, francophone ! bien qu'évidement, 
on y cause quand même pas mal de la France)

 Je tiens à souligner les efforts faits par la communauté des contributeurs
 de France, les outils développés, la gestion que vous mettez en place. 
 Espérons que les outils que vous développez pourrons servir à d'autres
 communautés.  

C'est largement le cas, et je ne crois pas que quelqu'un se soit élevé contre 
l'utilisation de nos outils par d'autres communautés bien au contraire (sauf 
bien sûr si cela augmente tellement l'utilisation de nos serveurs que ceux-ci 
se mettent à saturer, mais on en est loin)

J'en veux pour preuve que :
Nous proposons des extraits, minute par minute pour le quebec :
http://download.openstreetmap.fr/replication/north-america/canada/
Mais aussi pour plein d'endroit du monde :
http://download.openstreetmap.fr/replication/

Et que tout ça :
http://wiki.openstreetmap.org/wiki/FR:Servers
n'est pas restreint à la france.
Nous avons d'ailleurs 3 bases différentes de données mondiales, copie de la 
base officielle que chacun peut utiliser
et plein d'outils qui gravitent autour.
Certains ne fonctionnent que sur la France, mais je pense que sur demande 
et/ou un peu d'aide, on invite tout le monde à les étendre

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

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


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

Re: [OSM-talk] Import guidelines OSMF/DWG governance

2012-09-18 Lester Caine


 Having to clean up some of the mess made by imports that were not as 
well sanitised as they should have been, personally I get irritated at 
any 'import' is loaded. 
 
Lester,

I have often seen such arguments agains imports. In Canada also, there are 
contributors talking agains Canvec imports and saying we should have more fun 
tracing from GPS.

We have to analyze the problems more seriously and find solutions to them. A 
great work is done in Canada importing Canvec data. And like in France, I dont 
think that this is creating a lot of problems. Experienced mappers are doing a 
great job.

But we have to be carefull at new mappers, monitoring work done, contact them.  
Has it was seen before, many mappers do not follow the distribution list.  It 
is not easy to follow mapping in an area, know the mappers contributing, and 
eventually contact them.  I suggest it would be more usefull to build tools to 
monitor local mapping and let local mappers monitor the work done in their area.

An international organization like OSM should not make the same mistakes has 
large organizations centralizing everything, adapting rigid rules.



Pierre 




 De : Lester Caine les...@lsces.co.uk
À : OSM talk@openstreetmap.org 
Envoyé le : Mardi 18 septembre 2012 10h24
Objet : Re: [OSM-talk] Import guidelines  OSMF/DWG governance
 
Pieren wrote:
 DWG does also not usually require people to use a separete import account if
 they are doing small imports (even though the policy does not mention an
 exception for small imports). This, however, was orders of magnitude above
 small.

 What is the difference between one small import well done by 100 users
 and 100 small imports well done by 1 user ? Excepted that this crazy
 man should be congratulated by all of us ?

Having to clean up some of the mess made by imports that were not as well 
sanitised as they should have been, personally I get irritated at any 'import' 
is loaded. At least though a small account that results in problem data can be 
managed. When we have thousands of change sets to work through it becomes a 
lot more difficult. The current 'import' process is not ideal and we do need 
some improvements. Ring fencing 'import' processes in their own accounts was 
one attempt but still not ideal. DWG are doing the best they can in mediating 
problems and do need a better 'footprint' of international coverage, but if 
nobody will step up to the plate, then we simply have to accept the job they 
are currently doing. And I find they are doing a thankless task more than 
acceptably.

Now if there is a substantial set of data available which we are allowed to 
import then that data should be available ... as an overlay or some other way 
... such as the OS data is available as overlays we can trace from. This way 
we can cross check imported data, and fix things that the original importer 
got wrong. Importing from third party mass data without an easy path to cross 
check against the original data is I think the problem here? I believe the 
original intention was that the 'raw data' would be identified by the separate 
user account, and then merges from that can easily be identified to the user 
actually making the changes. That perhaps is not obvious these days?

We need to cooperate and agree the best way of doing things, but we do still 
have a way to go to get systems that work world wide.

-- Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk



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


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

[OSM-talk] Re : Import guidelines OSMF/DWG governance

 2012-09-8 Frederik Ramm frederik at remote.org 
 DWG does not usually block people without talking to them first, unless
 they are in the process of breaking things.

Frederik,

Governance and role of local communities should be looked in a context of 
multinational, multicultural organization. OSM has to adapt to this reality.

I was surprised to see the long list of users blocked without the local 
community be involved in the process 
(http://www.openstreetmap.org/user_blocks/). Spoken language and cultural 
aspects are important elements to consider.

The local community should have the responsability to first contact a mapper. 
The DWG role should be reserved for more serious matters.
 
The Québec community is not important and I would like to see it progress.  
There are political and linguistic tensions in many countries. If a non-english 
speaking contributor receives an email, with more or less agressives 
expressions about his mapping, that is very
 improductive for our organization. 

The role of the local community should be looked more carefully and OSMF 
working groups should be more transparent.

How often the DWG group has communicate with the local communities to let them 
know what this group is doing? 

Pierre ___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Import guidelines OSMF/DWG governance

2012-09-18 Simon Poole si...@poole.ch

 The question of (for example of an operational problem) communication to
 active mappers is a technical problem that we will have to address
 at 
one point in time. Either by assuring that the e-mail address remains 
valid or by other technical means. However that is not the issue in 
question,
 simply the fact that we have a large number of imports that 
are badly documented or not at all, should not have been imported in he 
first place
 (incompatible with CC-bs-SA or/and ODbL) and so on.


 The French cadastre imports are, as you know, a rather controversial subject. 
 In my opinion it is a dataset that doesn't actually increase 
the
 usefulness of the OSM dataset for most users (building outlines 
without addresses just don't really help with anything) and distracts 
beginner
 mappers from actually mapping (1st time mappers are recommend 
to immediately start importing insted of going outside). Further more,
 like essentially all imports, the external dataset is not about to go 
away, so there is no reason to prioritize this import over adding useful stuff.

Simon, this discussion was started to discuss about governance. We only see 
examples of problematic imports. But the question we should look at is how we 
can better tune or multinational / multicultural organization to adress these 
problems.  The respective roles of local communities and the DWG group have to 
be defined. We should also give tools to the local communities to monitor 
mapping, contact mappers, be able to exchange.  And we should not only think of 
national groups. You sometime have groups at regional or municipal levels. 



 BUT the import guidelines do not contain a provision that
 the data imported actually has to be useful and if the French community
 wants to spend (waste?) 

 immense amount of time on this, nobody is going to stop it as long as it 
 doesn't severely impact operations and/or use 
of OSM data.


Lets think more positively about bout national / local communities and give 
them the capacity to do a better job.  Large organization have this tendancy of 
centralizing everything and adopt simple rules. But the experience has showed 
that this does not work.  


There are more then 500,000 contributors. How many do you think know about the 
DWG group and follow his guidelines?

 
Pierre ___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Import guidelines OSMF/DWG governance

2012-09-18 Lester Caine lester at lsces.co.uk
 Pierre - I'm not arguing against imports. Only unmanaged ones and ones 
we do not have easy access to the source data.
 As I understand it you 
can view the canvec data, but is it available as an overlay in an 
editor? That is the part of the jigsaw
 that I'd like to see handled 
better, so we can compare data against the existing map prior to any 
import, and are ABLE
 to analyze just what of the data can be imported 
directly and what needs to be merged in some way? Certainly a large 
section
 of the OS data is only useful as reference material and any 
import is only going to obliterate more accurate data, so having it
 available as an overlay works well.

Lester - The National ressources department is collaborating and produce OSM 
files from his topographic data. The community has established guidelines. In 
general, contributors edit this file into JOSM, comparing with what already 
exists.  It is not an easy job.  But these contributors have made fantastic 
efforts.  We see too ofteen dogmatic declarations against imports without any 
nuance.

What we need as an organization is to establish governance practices that are 
efficient.  I am jealous of all the tools developped by the France community. 
The Talk-fr is very active and they are doing a great job. If you are not 
convinced, just look at the map of France. 


And about governance,  if this community cannot manage his contributors, who 
can?  We continually have new mappers, some working more or less intensively. 
We should adapt or organization to this Wikipedia like structure and try to 
better structure local communities.
 
Pierre ___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Import guidelines OSMF/DWG governance


On Tue, Sep 18, 2012 at 5:42 PM, Simon Poole si...@poole.ch wrote:

 The French cadastre imports are, as you know, a rather controversial
 subject. In my opinion it is a dataset that doesn't actually increase the
 usefulness of the OSM dataset for most users (building outlines without
 addresses just don't really help with anything) and distracts beginner
 mappers from actually mapping (1st time mappers are recommend to immediately
 start importing insted of going outside). Further more, like essentially all
 imports, the external dataset is not about to go away, so there is no reason
 to prioritize this import over adding useful stuff.


Simon, I dont know if you think that Canada Canvec data is controversial. Just 
look at the map at the border of Canada / US.
http://www.openstreetmap.org/?lat=45.003lon=-72.233zoom=9layers=M

Up north you see the effect of canvec imports.  I know this area and these 
imports seems to me of high quality. What do you think of mapping details in 
the Vermont state, just south of the border?

Is it possible to discuss about governance wich is the subject of this thread?

 Pierre 
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Import guidelines OSMF/DWG governance


 Pierre And about governance,  if this community cannot manage his 
 contributors, who
 can?  We continually have new mappers, some working more or less 
 intensively. We
 should adapt or organization to this Wikipedia like structure and try to 
 better
 structure local communities.
 I
 certainly agree with the statement, but would strongly lobby against 
the 'wikipedia' approach to solving the problem.
 New mappers NEED to be 
directed to proper guidance on how to provide new data, and I have 
proposed in the past that 

 new data is ring fenced until a more 
established mapper can review it, much like we have in hg and git code 
management.
 At the very least a 'Do you wish to save this to the main 
database' warning would be appropriate at times until a new account
 has 
established some 'kama' in the data submitted? Importing data from third party 
sources should be something that does require
 'kama' in 
understanding what one is doing and oversight by others should be added 
before some automatic processes are applied to the main database.

 Some better involvement of local groups would be useful here I think?

Lester we both agree that a Wikipedia approach is not satisfactory.  In France, 
and I think in UK and Germany too, there are strong local chapters. The 
discussions on Talk-fr list and the tools such as Osmosis and Cadastre imports, 
the various projects of this community all show how this community is take this 
job seriously.
To develop dynamic local communities, that monitor and correct data, contact 
contributors, meet more frequently, we have to empower these communities.  This 
would move away from a Wikipedia  model. The DWG group acting as a watch dog is 
not enough to build a better map.


Pierre 
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Import guidelines OSMF/DWG governance


2012-09-18 Frederik Ramm frederik at remote.org

 I am sure there are many users in France doing exactly that - a careful,
 small-scale, high-quality data integration.
 Most of them are probably 
way below the OSMF radar.

 But if the work of one person surpasses
 the million-object mark then is that still a small-scale import?
  How 
much time does it take to review carefully a million objects? Is it 
possible that a simple JOSM
  did not report anything obvious takes the 
place of the careful review? I am pretty sure that above a
  certain 
number, a proper quality review is simply not possible, and it is there 
that imports start.

Frederic, many national chapters are doing a great job and we have to count on 
them to organize the mapping community and let it progress.The governance 
question we should adress is respective responsabilities of local chapters and 
the DWG group.  And obviously, it is quite difficult to have the OSMF groups 
accept adressing this problem.

 
Pierre 




 De : Frederik Ramm frederik at remote.org
À : talk@openstreetmap.org 
Envoyé le : Mardi 18 septembre 2012 15h38
Objet : Re: [OSM-talk] Import guidelines  OSMF/DWG governance
 
Hi,

On 18.09.2012 20:34, Lucas Nussbaum wrote:
 So you are blocking one user because other users working on similar
 stuff (cadastre integration) did not work correctly?

The user was not blocked because others did not work correctly.

He was blocked - for 24 hours - because he did not adhere to the import 
policy, was asked to comply, and chose to ignore that.

 Can you point to such issues caused by the user that was actually
 blocked?

Doing this would only deviate into a discussion about whether or not certain 
data is good.

I continuously read the argument that cadastre imports were not imports per se 
because it is a careful, small-scale, manual integration and not an import.

I am sure there are many users in France doing exactly that - a careful, 
small-scale, high-quality data integration. Most of them are probably way 
below the OSMF radar.

But if the work of one person surpasses the million-object mark then is that 
still a small-scale import? How much time does it take to review carefully a 
million objects? Is it possible that a simple JOSM did not report anything 
obvious takes the place of the careful review? I am pretty sure that above a 
certain number, a proper quality review is simply not possible, and it is 
there that imports start.

Bye
Frederik

-- Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09 E008°23'33

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


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

Re: [OSM-talk] Import guidelines OSMF/DWG governance