Re: [OSM-talk] Please SWITCH to Mailman 3 & hyperkitty

[Jean-Marc Liotier]

On 12/14/20 8:13 PM, ipswichmap...@tutanota.com wrote:

> A bigger problem is that the UI for list owners is horrid.

Ok. What alternative solutions do you propose?


From Tom's answer, you might gather that there are higher priorities 
that absorb administrative resources - so unless you can offer a hand, 
I'm afraid that things will remain as they are for now.





--

14 Dec 2020, 19:07 by t...@compton.nu:

That's just the instructions on how to migrate the data
and it doesn't cover anything related to actually installing
and configuring all the components of mailman 3 from a
quick look which is a big issue given that it's not packaged
and it's a not a single tool like mailman 2 but rather is
a collection of separate components.

Given that we're already looking at other things there is
no point in spending several months and many man hours on
attempting a migration to something that we have to install
from source and then try and keep up to date without any
upstream packages.

You're right that the UI tries to be a web forum but from
personal experience I can say that it fails - it's probably
a better UI as a simple archiver but it's no use as a way
of reading lists day to day. The only thing that's ever
got close to that is Discourse.

A bigger problem is that the UI for list owners is horrid.

Tom

On 14/12/2020 18:58, ipswichmap...@tutanota.com wrote:

Python's mailing lists use mailman 3:

https://www.python.org/community/lists/


What is the problem with the UI ? It seems far, far more
useable than pipermail and hyperkitty feels like a forum.

If upgrading isn't possible, well then I guess bad luck. The
mailman focs doesn't make it look that hard (is it skipping
over OSM server specific steps that make the process harder?)

https://docs.mailman3.org/en/latest/migration.html


Thanks,
IpswichMapper
-- 




14 Dec 2020, 18:45 by t...@compton.nu:

It's not going to happen.

Virtually nobody uses mailman 3 with the exception of Fedora
and I know from using it there that the UI is a disaster.

Also it's not packaged for Ubuntu and it's far more complicated to
deploy than what we have.

Don't think of mailman 3 as an upgrade - it's basically a
totally different product.

There is talk of a change, but it won't be to mailman 3.

Tom

On 14/12/2020 18:42, ipswichmap...@tutanota.com wrote:

Okay thanks, I'll contact him on github. I don't havd mailman
administration experience, or that much coding experience for
that matter. I was just suprised that we are stuck with 10+
years old cluttered pipermail when hyperkitty is actually useable.

-- 



14 Dec 2020, 18:37 by j...@liotier.org:

From looking at the Mailman Chef cookbook at
https://github.com/openstreetmap/chef/tree/master/cookbooks/mailman
,
Tom Hughes is the person you should ask. If you have mailman
administration experience, maybe you could make it happen.


On 12/14/20 7:18 PM, ipswichmapper--- via talk wrote:


I was wondering if all the lists on
https://lists.openstreetmap.org

could be switched to Mailman 3 and hyperkitty (the newest
archiver).

Currently, pipermail is used to archive, and its UI is
*unusable*.
Comparatevely, hyperkitty is a lot more like a forum.

From my experience, the mailing lists are *far more active*
than
the forum, so it would be good to have it searchable & more
accessible (the only downside to this is newer users might
use the
mailing list now. I don't think this is a downside, but I
understand why others would think so).

Also, Mailman 3 still gets updates, while *mailman2 is on
maintainance mode and won't recieve feature updates.*

I strongly recommend that the mailing lists are upgraded to
mailman3 with hyperkitty: this will make the mailing lists
so, so
much more useable.




-- Tom Hughes (t...@compton.nu)
http://compton.nu/



-- 
Tom Hughes (t...@compton.nu)

http://compton.nu/


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

Re: [OSM-talk] Please SWITCH to Mailman 3 & hyperkitty

[Jean-Marc Liotier]

From looking at the Mailman Chef cookbook at 
https://github.com/openstreetmap/chef/tree/master/cookbooks/mailman, Tom 
Hughes is the person you should ask. If you have mailman administration 
experience, maybe you could make it happen.



On 12/14/20 7:18 PM, ipswichmapper--- via talk wrote:


I was wondering if all the lists on https://lists.openstreetmap.org 
could be switched to Mailman 3 and hyperkitty (the newest archiver).


Currently, pipermail is used to archive, and its UI is *unusable*. 
Comparatevely, hyperkitty is a lot more like a forum.


From my experience, the mailing lists are *far more active* than the 
forum, so it would be good to have it searchable & more accessible 
(the only downside to this is newer users might use the mailing list 
now. I don't think this is a downside, but I understand why others 
would think so).


Also, Mailman 3 still gets updates, while *mailman2 is on maintainance 
mode and won't recieve feature updates.*


I strongly recommend that the mailing lists are upgraded to mailman3 
with hyperkitty: this will make the mailing lists so, so much more 
useable.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk-fr] Open Street Misogynie ? inclusif ?

[Jean-Marc Liotier]

On 12/11/20 4:14 PM, FR via Talk-fr wrote:
Il y a quand même une phrase qui m’a fait tiquer dans ce fil : "une 
femme qui s'en plaint sera étiquetée emmerdeuse féministe". Cher ami 
quels clichés ! (c'est bien connu dans les cours d'écoles les filles 
ce sont que des pisseuses). Les femmes et les féministes (garçons et 
filles) ne sont pas dans le registre de la plainte mais plutôt dans 
celui revendication du droit à l'égalité. En dans ce contexte se faire 
traiter d’emmerdeuse c’est plutôt compliment. 


Ce cliché (je suis l'auteur de la phrase, plus haut dans le thread) a 
malheureusement toujours cours. Je suis représentant du personnel... 
Entre représentants du personnel, être traité d'emmerdeur est une forme 
compliment - mais vu de la direction nettement moins. La même chanson ne 
fera pas vibrer les deux publics de la même manière. Aller au carton 
avec la direction sous les encouragements des collègues du syndicat est 
une gloire coûteuse - et surtout vaine lorsqu'on est minoritaire. Mon 
propos n'est pas de juger la légitimité de la revendication mais d'en 
considérer la stratégie.



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

Re: [OSM-talk-fr] Open Street Misogynie ?

[Jean-Marc Liotier]

On 12/10/20 2:55 PM, Baptiste Lemoine - Cipher Bliss wrote:

Aucune ne le fera - et pour cause: une femme qui s'en plaint sera étiquetée 
emmerdeuse féministe. Ça fait partie du problème.

sauf si personne n'est là pour dire que le féminisme emmerde la communauté OSM, 
voire - syons fous - que c'est un combat qui est soutenu officiellement et que 
nous ne tolérerons pas les comportements qui iraient à l'encontre de cela.


Le silence des détracteurs n'empêche pas l'ostracisme - c'est la 
situation courante en entreprise. Les plus hardies se réfugient derrière 
un mandat syndical et s'auto-placardisent au passage, les autres 
finissent par partir et seules restent quelques spécimen avec des 
piquants et quelques autres renfermées dans leur résignation.


Le soutien officiel explicite est un bon début - c'est même la condition 
de tout autre progrès. Dans le milieu de l'informatique, on entend 
encore des blagues misogynes ou homophobes - pour se sentir légitime à 
en faire remarque à leur auteur, même un homme a besoin de d'appui, 
surtout lorsque l'auteur lui est hiérarchiquement supérieur.



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

Re: [OSM-talk-fr] Open Street Misogynie ?

[Jean-Marc Liotier]

On 12/10/20 2:07 PM, Baptiste Lemoine - Cipher Bliss wrote:

J'ai hâte qu'une femme donne son avis sur la mysoginie dans la communauté OSM.


Aucune ne le fera - et pour cause: une femme qui s'en plaint sera 
étiquetée emmerdeuse féministe. Ça fait partie du problème.




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

Re: [OSM-talk-fr] Open Street Misogynie ?

[Jean-Marc Liotier]

On 12/10/20 12:35 PM, Christian Quest wrote:
Depuis hier, il y a des échanges assez rudes sur la misogynie qui 
régnerait dans la communauté OSM ("systemic behavior").


Je crois que la campagne électorale n'est pas étrangère à la relance de 
ce débat par nos amis Américains dans la nébuleuse autour de HOT et à la 
manière exaltée dont il est présenté: je soupçonne qu'il s'agit d'une 
manœuvre consciemment destinée à presser le leadership plutôt Européen 
d'Openstreetmap en s'appuyant sur le réseau international autour de HOT, 
dont les intérêts ne sont pas tout à fait alignés avec ceux 
d'Openstreetmap en tant que projet de logiciel libre.


Ce n'est pas la première fois que le sujet est posé et c'est normal 
que la question se pose quand on voit la répartition hommes/femmes au 
sein du projet, quel que soit le niveau où l'on regarde.


Le problème dépasse Openstreetmap. Dans l'industrie logicielle et dans 
les télécommunications j'ai toujours eu la chance d'avoir des employeurs 
s'efforçant de recruter des femmes, mais c'est toujours un effort 
conscient car la situation par défaut est 90% masculine. Notre société 
se prive des contributions de celles qu'elle ne parvient pas à inclure. 
C'est un problème profond, d'ordre culturel - je n'ai pas de recette 
immédiate pour le résoudre, mais j'estime que nous devons faire un 
effort conscient pour en comprendre les ressorts et les traiter... Mais 
pas de manière caricaturale.




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

Re: [OSM-talk] Call to Take Action and Confront Systemic Offensive Behavior in the OSM Community

[Jean-Marc Liotier]

Considering the reaction - especially strong in the USA, and the fact 
that I'm a candidate to the Board of the Openstreetmap Foundation, I 
suppose I have to make a statement of my position.


In preamble, I condemn the use of sexual assault metaphor - that has no 
place anywhere.


In understand that the form of assertiveness traditional in mailing 
lists and forums can be off-putting. I may be part of that problem 
because, even as I dislike aggressive tones, I take dealing with them as 
a cost of doing business. That may be part of why different communities 
have fostered their own communications channels - I can't stand a 
Facebook thread, a pile of Slack channels or Discord noise for a minute 
but I'm happy that each village decorates his pub in his own taste. 
There is more to Openstreetmap than the @openstreetmap.org mailing 
lists... I would even bet that their population is considerably smaller 
nowadays than the communities that have flourished elsewhere. Users have 
mitigated the problem with their feet - compounding the trend of younger 
ones not even considering mailing lists as an appropriate channel at 
all. Do my white hair show yet ?


On the other hand, let's not take fragmentation as an excuse for failing 
to consider improvement potential. A couple of years ago, in a diary 
Heather Leson posted Public Lab's code of conduct 
(https://publiclab.org/conduct). My first reaction at the concept was to 
consider it infantilizing - can't we all exercise common sense ? It took 
me a while to connect that to my old intercultural management courses at 
ESSCA: when people from different cultures interact, there is no common 
sense pre-existing - it must be built. It follows that, while clumsy, 
starting with explicit norms may be an an effective way to bootstrap 
common sense among an highly diverse population. So count me in !


That said, I do not understand how a community where the barrier to 
entry is as low as editing a node can be perceived as gatekeeping. I 
never asked for anyone's permission to do anything in Openstreetmap - I 
just tried things, sometimes in hilariously wrong ways... The do-ocracy 
isn't a myth, everything really is up to us. And none of that requires 
any specific genital configuration. So, the explanation for the male 
majority in the visible Openstreetmap community has to lie elsewhere.


As I failed to answer the "What will you do to encourage more women 
leaders in OSM working groups and governance?" official question (it was 
an involuntary oversight, but I don't expect anyone to believe me), as a 
lazy pupil I'll copy my neighbor's excellent answer - Roland Olbricht 
put it better than I could have:


"As a first step, we should be bluntly honest: We as OSM have no idea 
what is actually keeping people from candidating for positions. Or 
electing them: all elected candidates last year were male despite at 
least on female candidate. Or contributing in general.


Honestly again, I consider the lack of diversity primarily as a missed 
opportunity of growth and resilience. There are probably many people out 
there who both can and want to engage with OSM, even if rather as a mean 
than an end. Our community probably could triple if we get those people 
involved and excited.


Various things have been tried, but we have not seen any significant 
progress, even after years. Again, we don't know whether we are doing 
not enough of the initiatives or simply not the right things. It is time 
to compare to other similar organizations and settings that attract 
minorities better, and to scrutinize whether we can learn from them. The 
gender ratio of math students in Germany has been eased to be almost 
balanced, many years after it was discovered that school teachers 
actively and massively talked down girl's math competences. In that 
case, the true origin of the problem has been entirely outside the 
institution where the problem has been observed"


Put it on account of my male-biased point of view if you will, but I 
believe there are obstacle to participation more significant than 
gender. Local communities overcome the language barrier by producing 
documentation in their own idiom - but the software's world alignment on 
English remains a strong barrier. In every African country I have 
visited, the cost of Internet access keeps many willing souls from 
taking part in Openstreetmap. Leisure time is luxury - many of my 
African friends do not understand why I spend time on pursuits that do 
not improve my income. So barriers to entry do exist - but they may not 
be those that produce the most outrage in our circles. So I support that 
statement from the call to action: "Diversity and Inclusion special 
committee should actively work to consult, analyze and understand the 
structural limitations of under-represented people to participate".


Finally, writing one's name in signature of a text that evolves after 
you have signed it feels foolish to me - but then again, 

[Talk-africa] Pump tagging proposal

[Jean-Marc Liotier]

A tagging proposal for pumps is under vote at 
https://wiki.openstreetmap.org/wiki/Proposed_features/Pumping_proposal


The proposed tagging scheme allows fine detail for pump technology and 
operation.


Among other purposes, it might be useful in the African context for 
borehole water pumps, for example.


Please have a look and vote - or just comment in this thread about 
whether you might have uses for finer descriptions of pumps.



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

Re: [OSM-talk-fr] addok et demo.addok.xyz : géocodage avec données OSM

[Jean-Marc Liotier]

On 11/24/20 6:22 PM, Frédéric Rodrigo wrote:
Ce n'est pas aussi facile que ça pour faire une emprise mondiale. Il 
est nécessaire d'écrire des adaptateurs pour chaque langue ou pays 
pour traiter les particularités.


Je découvre donc:

- La phonemicization: 
https://github.com/addok/addok-fr/blob/master/addok_fr/utils.py


- Les particularités Françaises: 
https://github.com/addok/addok-france/blob/master/addok_france/utils.py


On comprend vite qu'il sera compliqué d'accepter une recherche sans 
connaître dans quel zone administrative et linguistique elle s'inscrit...



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

Re: [OSM-talk-fr] addok et demo.addok.xyz : géocodage avec données OSM

[Jean-Marc Liotier]

On 11/23/20 10:32 PM, Christian Quest wrote:
L'index redis occupe dans les 16Go de RAM, la base sqlite 2Go, elle 
aussi en RAM pour un max de perfs.
Pour la France seulement... Ca apporte d'un coup tous ce dont l'absence 
frustre dans Nominatim - mais c'est un sérieux investissement en 
matériel pour une emprise mondiale... Même problème que la mise à 
disposition de tuiles: vitrine indispensable mais qui risque d'être 
considéré comme un service public.


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

Re: [OSM-talk-fr] addok et demo.addok.xyz : géocodage avec données OSM

[Jean-Marc Liotier]

On 11/23/20 7:17 PM, leni wrote:

Le 23/11/2020 à 09:55, Cyrille37 OSM via Talk-fr a écrit :

Le 22/11/2020 à 20:02, Christian Quest a écrit :
https://demo.addok.xyz/ où vous pouvez tester l’auto-complétion avec 
préférence géographique centrée sur la carte.


Wouah !!

Ça dépote! Et tolérant o fotes d'ortogafe. J'adore :-)
+1, sans les accents, sans apostrophes, sans les articles, centré à 
l'autre bout de la France et il trouve instantanément : j'adopte


Impressionnant. C'est gourmand ?



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

Re: [OSM-talk-fr] Élection Fondation OSM

[Jean-Marc Liotier]

J'en profite pour signaler ma candidature - à ceux que j'ai déjà 
rencontré aux SOTM, SOTM-FR et autres rencontres locales, et à ceux que 
je n'ai pas encore eu la chance de croiser. La semaine prochaine je 
posterai mes réponses aux questions officielles posées par l'OSMF aux 
candidats - si par la suite vous souhaitez rebondir dessus en Français, 
je serai ravi de converser ici !



On 11/19/20 12:57 PM, Vincent Bergeot wrote:

Bonjour,

la liste officielle des questions posées aux candidats est finalisée 
depuis hier en anglais 
(https://wiki.openstreetmap.org/wiki/Talk:Foundation/AGM20/Election_to_Board).


Il y a 7 candidats pour 3 sièges si j'ai tout compris.

Voici la liste des candidats comportant les liens vers leur compte OSM 
et wiki : 
https://wiki.openstreetmap.org/wiki/Foundation/AGM20/Election_to_Board#List


à vos analyses (ne cherchez pas les femmes, il n'y en a pas) !




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

Re: [OSM-talk] Maps.me comments and OSM notes [Was: Your experience in reaching out to Maps.me users ?]

[Jean-Marc Liotier]

Now I understand the occurrence of Maps.me POI simultaneously with a 
redundant note. This is even worse than I imagined.


I searched the Maps.me issues tracker for "is:issue comment note" and 
found nothing reporting that behaviour.





On 11/12/20 6:15 PM, Brian M. Sperlongano wrote:
Huh. Yes, that's exactly what it did. Certainly not the behavior I'd 
expect.


On Thu, Nov 12, 2020, 11:58 AM Michał Brzozowski > wrote:


Hi Brian, the comment was probably made into an OSM Note. Check
Notes on that OSM user page.

czw., 12 lis 2020, 17:56 użytkownik Brian M. Sperlongano
mailto:zelonew...@gmail.com>> napisał:

I downloaded and made a test edit (adding an address to a
local POI) with maps.me  just now to
understand how it works.  It does at least make you log in to
OSM.  I entered in a comment on the change, however, I note
that maps.me  overwrote my user-entered
comment with a generic comment in the changeset.



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

[OSM-talk] Your experience in reaching out to Maps.me users ?

[Jean-Marc Liotier]

A contributor blankets Bamako with office=government nodes named in all 
caps - a sad situation, especially considering how much effort he puts 
into wrongly tagging valid POI (details, in French: 
https://lists.openstreetmap.org/pipermail/talk-ml/2020-November/000254.html). 
Changeset comment and Openstreetmap messages do not elicit answers from 
him.


Is it just me or are Maps.me Openstreetmap contributors unaware of 
Openstreetmap messages ? Does anyone here have seen Maps.me 
Openstreetmap contributors answer to Openstreetmap messages ?


I opened a Maps.me wishlist issue requesting Maps.me to notify their 
contributing users of pending Openstreetmap mail - the way JOSM does it: 
https://github.com/mapsme/omim/issues/13951



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

Re: [OSM-talk-fr] OSMF 2020 entre inquiétude et déception

[Jean-Marc Liotier]

Le "Is responsible for allocating $$ to diverse worthwhile software 
projects with grants and microgrants" de 
https://wiki.osmfoundation.org/wiki/Mission_Statement me gène également 
beaucoup. Je vois la Fondation comme arbitre de conflits et garant 
ultime de la license - or on sent le glissement vers ce qui pourrait 
finir par ressembler à la Mozilla Foundation - une course en avant dans 
toutes les directions en même temps plutôt que la dalle stable sur 
laquelle repose tout le reste.




On 10/22/20 10:03 PM, severin.menard via Talk-fr wrote:

Bonjour,

Pour info, pour celles et ceux qui ne seraient pas membres de l'OSMF, 
j'ai publié cet article sur sa liste de discussion : 
https://lists.openstreetmap.org/pipermail/osmf-talk/2020-October/007294.html
et également sur mon journal OSM : 
https://www.openstreetmap.org/user/SeverinGeo/diary


Les retours (positifs ou négatifs) sont toujours bienvenus.



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

Re: [OSM-talk] mspray stealth organized mapping

[Jean-Marc Liotier]

(answer cc: to talk...@openstreetmap.org and talk@openstreetmap.org)

Thanks for taking care of our feedback. In Senegal and Mali, 
Openstreetmap has a long history of low quality buildings produced in 
massive quantities by humanitarian actors. Cleaning up after them is 
considerable work, which is never handled by the responsible parties.


Please ensure that your project is registered at 
https://wiki.openstreetmap.org/wiki/Organised_Editing/Activities and has 
its own page, as mandated bu the Organised Editing Guidelines.


You may also want to reconsider the workflow: the existence of 
superposed almost-duplicate buildings shows that the existing data may 
not be correctly taken into account or even downloaded beforehand.


Also, you mention "We will work on the wrongfully mapped/tagged 
buildings when we start validating what has been mapped so far" and that 
is part of the problem: do not let contributors upload a changeset if 
the JOSM validator shows errors or warnings - especially about obvious 
errors such as superposition. Separating production from quality 
assurance is certain to produce low quality: quality as an afterthought 
is ineffectual - quality must be integral to the process.


To drive that point home, I recommend letting your mappers spend a few 
hours fixing errors on Osmose (osmose.openstreetmap.fr). Osmose patrols 
will let them understand the sort of problems we face after them and 
maybe the quality of their work will increase, if they are not driven by 
quantitative metrics...



On 5/22/20 7:55 PM, J@mesN wrote:

>
> @mesN has sent you a message through OpenStreetMap with the subject 
Re: mspray stealth organized mapping:

> J@mesN
>
> Hi Jean_Marc,
>
> Thanks for reaching out. Yes, these users are part of one of our 
malaria mapping teams who started enumerating in Senegal this week. 
There are 6 mSpray enumerators (4,8,13,15,16,17). We are only mapping 
what we perceive to be residential structures after getting local 
context from our in-country partners to inform this. Sincere apologies 
if this has caused a problem. We will work on the wrongfully 
mapped/tagged buildings when we start validating what has been mapped so 
far.

>
> Our lead GIS officer is currently on leave so he will post the 
activity on the wiki page when he returns on Tuesday next week (26th May).


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

Re: [OSM-talk] mspray stealth organized mapping

[Jean-Marc Liotier]

On 5/22/20 10:52 AM, Jean-Marc Liotier wrote:


I just noticed a serie of mspray[numerical suffix] (mspray16 
<https://www.openstreetmap.org/user/mspray16>, mspray15 
<https://www.openstreetmap.org/user/mspray15>, mspray13 
<https://www.openstreetmap.org/user/mspray13> and mspray4 
<https://www.openstreetmap.org/user/mspray4> for example) are are 
mapping many buildings in Senegal, some of which of dubious quality. 
This looks like organized mapping but I do not see any description of 
it in https://wiki.openstreetmap.org/wiki/Organised_Editing/Activities


I attempted contact today, I am awaiting an answer - I'll keep this 
list informed.


I suspect if may be part of the mSpray malaria spraying project.


I just received this answer:

On 5/22/20 7:55 PM, J@mesN wrote:
>
> Hi Jean_Marc,
>
> Thanks for reaching out. Yes, these users are part of one of our 
malaria mapping teams who started enumerating in Senegal this week. 
There are 6 mSpray enumerators (4,8,13,15,16,17). We are only mapping 
what we perceive to be residential structures after getting local 
context from our in-country partners to inform this. Sincere apologies 
if this has caused a problem. We will work on the wrongfully 
mapped/tagged buildings when we start validating what has been mapped so 
far.

>
> Our lead GIS officer is currently on leave so he will post the 
activity on the wiki page when he returns on Tuesday next week (26th May).


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

Re: [OSM-talk] mspray stealth organized mapping

[Jean-Marc Liotier]

On 5/22/20 4:58 PM, Andy Townsend wrote:

On 22/05/2020 14:45, Jean-Marc Liotier wrote:

On 5/22/20 1:23 PM, Frederik Ramm wrote:

the "mspray" accounts were blocked in July 2019 for problematic edits
and failing to document properly


The "problematic edits" part is still current - this changeset of 
mine for example is mostly about deleting buildings from mspray16: 
https://www.openstreetmap.org/changeset/85452208



This is a new mapper as of just over a week ago:
https://www.openstreetmap.org/user/mspray16


"New" - like all those other users who just happen to be named msprayXX 
and produce the same slop:https://taginfo.openstreetmap.org/keys/mapper 
<https://taginfo.openstreetmap.org/keys/mapper>



No-one has left any changeset discussion comments


The spaghetti factories rarely answer any - better aim for the head.


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

Re: [OSM-talk] mspray stealth organized mapping

[Jean-Marc Liotier]

On 5/22/20 12:48 PM, Mikel Maron wrote:
Does possibly look like organized editing. No need to invoke intention 
— if this was “stealth” that means they are intentionally trying to 
hide. More likely case is they simply aren’t aware of the guidelines.
In the case of individual errant mappers, I give benefit of doubt 
aplenty and don't take ignorance as misconduct - negligence is entirely 
forgivable. In the case of a corporation capable of harnessing many 
employees to an Openstreetmap tasks and thus proving that it is well 
aware of Openstreetmap, foregoing the Organized editing Guidelines that 
have been in place since 2018 is negligent to the point of gross misconduct.


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

Re: [OSM-talk] mspray stealth organized mapping

[Jean-Marc Liotier]

On 5/22/20 1:23 PM, Frederik Ramm wrote:

the "mspray" accounts were blocked in July 2019 for problematic edits
and failing to document properly


The "problematic edits" part is still current - this changeset of mine 
for example is mostly about deleting buildings from mspray16: 
https://www.openstreetmap.org/changeset/85452208




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

[OSM-talk] mspray stealth organized mapping

[Jean-Marc Liotier]

I just noticed a serie of mspray[numerical suffix] (mspray16 
, mspray15 
, mspray13 
 and mspray4 
 for example) are are 
mapping many buildings in Senegal, some of which of dubious quality. 
This looks like organized mapping but I do not see any description of it 
in https://wiki.openstreetmap.org/wiki/Organised_Editing/Activities


I attempted contact today, I am awaiting an answer - I'll keep this list 
informed.


I suspect if may be part of the mSpray malaria spraying project.

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

Re: [OSM-talk] Quality and the Openstreetmap value chain

[Jean-Marc Liotier]

On 5/12/20 3:50 PM, Colin Smale wrote:
The role I expect of the data consumers is to articulate how they 
would like to view the data (including what attributes they are 
expecting), and not to dictate how that data is stored/represented 
internally. Cartography, geography, statistics etc are very different 
skills to data modelling and database design.


Indeed, technical implementations take functional requirements into 
account but have many other inputs and a different class of actors. 
Consumers, tell us what you want - not how to do it ! Same as any 
software project...



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

Re: [Talk-africa] [Trufi Association] Translation of bus route mapping documentation

[Jean-Marc Liotier]

On 5/12/20 10:40 PM, Sören Reinecke via Talk-africa wrote:

I am Sören Reinecke from Trufi Association. We help communities in developing 
countries to organize their public transport (pt) e.g. we work with the 
community from Accra, Ghana. Aside from providing the pt navigation app and the 
infrastructure behind it (e.g. OTP server etc.) we also show mappers how to add 
bus routes to OpenStreetMap ( 
https://mapping-bus-routes.readthedocs.io/en/master/ ).

My question is: Does your community need a translation into French? If yes, I 
would set up the translation infrastructure and invite the onces wanting to do 
the translation work.


Hello Sören. talk-africa@openstreetmap.org is English language only but, 
in French-speaking West Africa, the Openstreetmap contributors use 
French almost exclusively in their Openstreetmap practice. French 
translation proves valuable in including them.


cc: Nathalie Sidibe, from Openstreetmap Mali, who is fluent in English 
but very aware of how much French translations are required in her local 
community - she can give you the local perspective.




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

Re: [OSM-talk] Quality and the Openstreetmap value chain

[Jean-Marc Liotier]

On 5/12/20 2:52 PM, Colin Smale wrote:
As you and many others frequently remind us: OSM is first and foremost 
about the data and not any specific use-case or rendering thereof.
Yes - but a data model is not a neutral representation of reality: it is 
a projection through a use-case, mapping reality to a construct fit for 
specific purposes. In the relational database world, we cannot produce a 
satisfactory schema without knowledge of what sort of queries are 
intended. Flattening the highly dimensional reality into any data model 
involves such choices. Closer to the daily preoccupations of 
Openstreetmap, even lists of attribute values are reductionist and 
finding the appropriate tradeoff cannot be achieved isolatedly: it 
requires input from those who will deal with the consequences of the 
choices - the data-consuming users.


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

[OSM-talk] Quality and the Openstreetmap value chain

[Jean-Marc Liotier]

On 5/12/20 11:42 AM, Richard Fairhurst wrote:

I love the fact that we are now 50 messages into discussing, for the second
time, a change that would be made ostensibly for the benefit of data
consumers, and yet no one has asked any actual data consumers.


Yes. Users are the ultimate measure of quality, yet they are most often 
absent from our discussions. Our history explains why: in the beginning, 
we had a blank map, which we set upon filling with whatever we could, to 
get the stone soup started. There were no consumers at all - so 
naturally our universe was supply-side entirely: the availability of 
data inspired usage, which came second. Nowadays, Openstreetmap is used 
- let's take advantage of that to improve ! Looking at the world and 
thinking about how we should model it should be done with an 
understanding of how users want it. This is difficult when we have few 
users around and very little feedback from downstream. So, if one has 
opportunities to bring that to our knowledge, please do: it is valuable 
information to the Openstreetmap project, information without which we 
cannot allocate our efforts optimally.



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

[OSM-talk-fr] Lac souterrain suspect à Neuilly-Sur-Seine

[Jean-Marc Liotier]

Je tombe sur un lac souterrain à Neuilly-sur-Seine, devant le 106 Avenue 
du Roule: https://i.imgur.com/qH2z8L1.png 
https://www.openstreetmap.org/way/468906502 - je n'en avais jamais 
entendu parler, je n'en trouve aucune trace ailleurs, l'auteur 
Openstreetmap, D2boot83 a une seul contribution - celle là, et il ne 
répond pas... Je suis tenté de supprimer. C'est un truc de Pokemon ou un 
spéléologue des beaux quartiers peut confirmer le lac ?



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

Re: [OSM-talk-fr] Interruption Images Maxar

[Jean-Marc Liotier]

On 12/20/19 9:33 AM, Vincent Bergeot wrote:
je ne sais pas quand et pour combien de temps mais interruption prévue 
des images Maxar 
(https://www.openstreetmap.org/user/@kevin_bullock/diary/391652)


Elles sont déjà interrompues, depuis hier soir. Pour l'Afrique de 
l'Ouest, je me suis rabattu sur ESRI World - un petit peu plus ancien 
mais de bonne qualité optique et généralement mieux que Bing.


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

Re: [OSM-talk] [Tagging] Specific tag for Satellite Dishes

[Jean-Marc Liotier]

On Mon, July 29, 2019 7:03 am, Enock Seth Nyamador wrote:
> I am looking for specific tags for Satellite Dish [1]. I haven't found
> anything near so far. May be am missing something, else it doesn't exist
> and might be useful to propose and come handy in some cases.

Prior discussion about that:
http://gis.19327.n8.nabble.com/quot-satellit-quot-td5934448.html -
inconclusive because there is no consensus about granularity

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

Re: [OSM-talk-fr] Camera 360

[Jean-Marc Liotier]

On Wed, July 10, 2019 8:21 pm, Francois Gouget wrote:
>
> des photos qui ont des timestamps différents (et une
> précision sub-seconde) mais exactement les mêmes
> coordonnées GPS.
>
> L'application Mapillary me fournit aussi un fichier GPX
> qui lui aussi contient des points consécutifs avec des
> timestamps différents mais exactement les mêmes
> coordonnées GPS.
>
> C'est là que je fait l'interpolation avec une version
> modifiée des scripts mapillary_tools

Donc Mapillary a tout ce qu'il faut pour interpoler correctement les
positions des photos entre deux relevés GPS... Il me semble qu'il devrait
le faire directement, non ?

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

Re: [OSM-talk] Map of Population Density vs. OpenStreetMap density

[Jean-Marc Liotier]

On Fri, July 5, 2019 2:40 pm, Christoph Hormann wrote:
>
> One warning:  All global population data sets that exist are rough
> estimates with usually significant systematic biases and errors.  For
> example in Switzerland the data set you used sees high population
> density in mountain areas with no basis in reality.

Same in rural Senegal. Low-resolution population data I guess.


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

Re: [OSM-talk] Mali

[Jean-Marc Liotier]

On 2019-06-30 19:12, john whelan wrote:
> The first major concern is  "Working for a mapping project with Apple." 
the concern here is paid mappers and the quality of their work.

To be fair to the Apple-paid guys, one of them did a beautiful job with
waterways. I haven't looked at other contributions, but that one is very
good quality.

> The second is there are a fair number of imports of varying quality. 
Most schools I suspect are fairly accurate but it would be nice to tie
the node to a building or an area.

It would be nice but it requires survey, so it will not be done at any
useful rate, for lack of locals. We talked about the Mali schools before -
the UNICEF import is a sad dead-end.

> I think there is sufficient infrastructure in Africa three days for
local mappers.  Smartphones are becoming more common and so is an
Internet connection albeit driven by social media.

Even residential connexions are billed by volume and mobile data is a
scarce commodity - it remains a sufficient obstacle to filter out anyone
who is not highly motivated. Part of the draw of mapathons is the free
wi-fi that too many participants use for many other purposes beside some
mapping.
> My impression is there would be an economic advantage, larger cities
already have street names.  Could someone do a PhD in the subject which
might well mean a bit more government.  My personal view is some things
are best done by governments.  Highways for example.

Of course the government has the street names - locked away in some dead
GIS. They'll publish them after they see that Openstreetmap has a more
complete set !

> Interestingly some of the changesets are tagged "untangling the
spaghetti" and I have sympathy with that mapper.

Thanks - at least someone reads my changeset comments...





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

Re: [OSM-talk] Terminate Facebook rights under ODbL

[Jean-Marc Liotier]

On 6/10/19 10:02 AM, Mateusz Konieczny wrote:

10 Jun 2019, 01:10 by j...@liotier.org:

This negotiation belongs to the OSMF.

Negotiation? Rather DMCA takedown notice. There is
no reason at all for negotiation.


Even if the goal is full conformance to strictest interpretation of the 
Openstreetmap terms, how & when the infringer will move towards it 
necessitates a dialog - which has all the attributes of a negotiation. 
Deter first, then talk.


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

Re: [OSM-talk] Terminate Facebook rights under ODbL

[Jean-Marc Liotier]

On 6/10/19 5:28 PM, Eugene Alvin Villar wrote:
On Mon, Jun 10, 2019 at 4:47 PM Yves > wrote:


I think a small '(c)OSM' for small screen web or app could be
suggested as OK, what do you think?


Why not revive this dormant proposal for a small attribution logo that 
was proposed 6 years 
ago:https://wiki.openstreetmap.org/wiki/RFC_Attribution_Mark 

I have always wondered why it did not get more attention... But I'm not 
the target audience. So, do we have feedback from web designers - the 
population who this proposal aims to convince to attribute properly ?
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Terminate Facebook rights under ODbL

[Jean-Marc Liotier]

On 6/10/19 12:10 AM, Christoph Hormann wrote:

No one should underestimage the amount of pressure the OSM community
could put [..] if all active OSM
contributors would

* cease using Facebook [..]


A drop in the ocean.

This negotiation belongs to the OSMF.


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

Re: [OSM-talk] HOT and the OSMF

[Jean-Marc Liotier]

On 3/26/19 8:31 PM, john whelan wrote:
Apparently I'm the mapper who is the 4th in Mali and currently I do 
not map for HOT.

HOT does not have a monopoly in Mali.


Yes - rural Mali in Openstreetmap owes a lot to you. I'm the one who is 
first on that list (I'm more a urban mapping sort or person), I'm not 
HOT and neither is the second (someone on an Apple project - he did nice 
work on the riverbanks). The three of us represent two thirds of all map 
changes in Mali in the last two months.


Anyway, we are foreigners.

The locals on the other hand, a very large portion or which (among the 
top 20 people alone, I estimate 7 people, reaching around 19% of all 
changes, mostly buildings ) are socially connected to 
Nathalie Sidibé, who sits on the HOT board. The #Hotosm tagged and 
tasking-manager coordinated changes are only the visible part. 
Francophonie-connected people have led some significant efforts in the 
past, but HOT's comparatively large budget goes a long way in those 
parts - in terms of social reach.




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

Re: [OSM-talk] HOT and the OSMF

[Jean-Marc Liotier]

In some countries (Mali for example), HOT is by far the institution with 
the most notoriety related to Openstreetmap - and it is often the only 
one. There, Openstreetmap appears to be a humanitarian mapping project 
under supervision and sponsorship of HOT. The confusion is real and the 
least the OSMF could do to start clearing it is to make sure that the 
domains are separate. http://hot.openstreetmap.org must not point to a 
HOT domain.



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

Re: [OSM-talk-fr] Quartiers à Paris

[Jean-Marc Liotier]

On Thu, March 14, 2019 3:52 pm, Romain MEHUT wrote:
> althio wrote
>
>> 1. un truc compliqué et administratif
>> Relation: type=boundary [..]
>>
>> 2. un truc simple et humain
>> Point: place=suburb|* + name=* [..]
>
> quel est l'intérêt d'avoir à la fois une relation
> et un noeud pour définir ce que j'interprète
> comme étant la même chose ?

Aucune idée concernant la Goutte d'Or, mais je regardais aujourd'hui la
relation Sénégal (https://www.openstreetmap.org/relation/192775) et elle
comporte le noeud https://www.openstreetmap.org/node/432425075 dont dont
j'ai appris de
https://wiki.openstreetmap.org/wiki/Relation:boundary#Relation_members que
le rôle est "label" permet de positionner arbitrairement la légende d'une
surface biscornue (le Sénégal étant concave avec la Gambie incrustée en
plein milieu)... Donc il existe des cas où tel nœud est légitime, même si
c'est entièrement pour le rendu.

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

Re: [OSM-talk] General OSM Talk

[Jean-Marc Liotier]

On Mon, March 11, 2019 9:23 am, Frederik Ramm wrote:
>
> I have the impression that something that has been going on quietly,
> without much fanfare, is how many mappers now participate in quality
> assessment as part of their daily routine. The tool landscape is
> scattered - you have the old(er) cohort of general QA tools like Osmose,
> OSM Inspector, and even Keepright is still around, but you also have a
> newer generation including OsmCha and "OSM Suspects" and other more
> niche applications, and quite a few people are actually using these

Years ago I started using WhoDidIt to patrol my area of interest as part
of my gardening routine, but it was not what it was designed for: great
for visualizing where activity occurs but clunky for patrolling. OSMCHA
bridged that gap - it gives me real-time monitoring with integrated
tooling to detect bad changesets and engage (especially new mappers) with
changesets comments (though whether they respond is another matter)...
Catching them early before problems accrue beats having to deal with
accumulated errors later.


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

Re: [OSM-talk] Bot edits on the OSM wiki

[Jean-Marc Liotier]

On 2/25/19 10:37 AM, Christoph Hormann wrote:

There are several ethical concerns that motivate me here - the one that
is easiest to understand is probably that allowing bots would create a
two class system within the OSM community on the wiki - those who are
able to develop and run bots would form a ruling class while the rest
would be subject to this rule whether they agree with it or not. [..]


If that is an essential concern for you, I have bad news about the 
Openstreetmap database...


Robots are not sovereign entities: they are puppets to humans and 
therefore bound to human rules, to which supplementary restrictions are 
added to compensate for their large-scale effect. Therefore, the authors 
of automation have greater power to realize their vision - but they 
remain under political control... Works pretty fine for our map, doesn't 
it ?



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

Re: [OSM-talk-fr] BAN(O): accompagnement des communes

[Jean-Marc Liotier]

On 2/24/19 5:53 PM, marc marc wrote:

Le 24.02.19 à 13:31, deuzeffe a écrit :

Je viens de lire la spécification du format d'échange, pas très simple

Le plus simple pour une mini structure n'est-il de
les mettre dans osm, ce qui les injectera dans bano ?
Si quelqu'un veux un autre format, il peux convertir depuis bano.


Travailler directement dans Openstreetmap est simple et résout d'un coup 
tout un tas de problématiques de format et d'outillage... Mais ne 
négligeons pas le saut conceptuel que cette option exige des 
gestionnaires, de "je concocte mon petit fichier à moi que j'accepte 
ensuite d'exposer au monde" à "je saute dans la piscine avec tous ces 
gens avec qui je vais devoir parler"... On passe d'une logique de 
contrôle et publication à une logique de coopération - de la donnée 
ouverte au libre, alors qu'une majorité de décideurs commencent juste à 
aller vers l'ouverture des données.




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

Re: [OSM-talk-fr] carte OSM sur Facebook

[Jean-Marc Liotier]

On Wed, February 13, 2019 9:57 am, Jozeph via Talk-fr wrote:
> [..]
> Pour une carte électronique OSM navigable, le crédit ne devrait-il
> apparaître dans le coin de la carte dès la page d'accueil ?

D'après l'OSMF, oui:
https://wiki.osmfoundation.org/wiki/Licence/Licence_and_Legal_FAQ#How_should_I_attribute_you.3F

Mais nous devons tenir compte de la surface relative de la carte et de
l'attribution: il me paraît illégitime d'exiger une attribution occupant
plus de 5% (ordre de grandeur arbitraire qui me vient à l'esprit) de la
carte - un critère de proportionnalité. Donc pour une petite carte
incrustée dans une page, avoir le détail de l'attribution derrière une
icône "©" me paraît acceptable - surtout si la carte affiche plusieurs
couches, chacune avec un copyright différent. Par contre pour une carte en
plein écran, le "© OpenStreetMap contributors" complet est proportionné et
donc incontournable.

Pendant qu'on y est, je découvre l'icône "By OSM" affichée à
https://osmlab.github.io/attribution-mark/copyright/ - je la trouve
efficace et suffisamment mignonne pour ne pas heurter un concepteur
graphique soucieux de ne pas déparer sa création.


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

Re: [OSM-talk-fr] Sensibiliser à OpenStreetMap - Dépliant OSM France

[Jean-Marc Liotier]

On Thu, February 7, 2019 11:46 am, Julien Lepiller wrote:
>
> Si on en est là, moi je traduis « tag » par « attribut » et « way »
> par « chemin » ;)

C'est ce que j'utilise toujours lorsque je parle d'Openstreetmap en
Français: un attribut, formé d'une clé et de sa valeur.

Je ne devrais pas ?


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

Re: [OSM-talk-fr] Sensibiliser à OpenStreetMap - Dépliant OSM France

[Jean-Marc Liotier]

On 2019-02-07 15:11, marc marc wrote:
>
> est-ce que way ne devrait-il pas être traduit par trait ou ligne ?

Polyligne (ouverte) ou polygone (fermé)

> de même avec node, au lieu de nœud (qui en français sous-entend qu'il y
> a un lien entre plusieurs chose), le mot point me semble plus adapté.

Dans mes vieux souvenirs de noviciat, le mot "noeud" pour ce qui était
pour moi un point semblait une complication gratuite. Donc, pour un
document de vulgarisation, le mot "point" est à mon avis mieux adapté.

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

Re: [OSM-talk-fr] Et OSM la dedans !

[Jean-Marc Liotier]

On Wed, January 16, 2019 11:44 am, Vincent Bergeot wrote:
> https://nothing2hide.org/fr/2019/01/16/il-ny-a-aucun-probleme-ni-avec-facebook-ni-avec-google,
je fais le lien avec OSM, cet attrait pour et les
> financements par certaines entreprises. Par exemple pour le sotm 2018 à
> Milan : https://2018.stateofthemap.org/ où l'on retrouve facebook, bing,
> ... en sponsors gold :)

Du point de vue du libre, peut-on considérer des organismes tels que
Facebook ou Microsoft comme des personnes morales cohérentes ? Il me
semble qu'il s'agit plutôt de conglomérats dont nous pouvons distinguer
chaque branche en fonction de sa position concurrentielle: en position
dominante, ils sont toxiques - mais en infériorité ils sont capables de
coopérer. Nous connaissons tous la toxicité de Facebook et Microsoft dans
leurs domaines de domination respectifs, mais en matière de cartographie
ce sont des nains face à leur principal concurrent et leurs intérêts sont
donc naturellement alignés avec ceux du principal projet libre... Jusqu'à
qu'ils deviennent éventuellement dominants et décident qu'il n'ont plus
besoin de coopérer - c'est le cycle naturel des industries technologiques
et Openstreetmap doit en être conscient pour rester ouvert afin de
profiter des coopérations possibles tout en restant vigilant de
l'évolution concurrentielle.


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

Re: [OSM-talk] Quality (was: The point on the OSM Response to the DR Congo Nord Kivu Ebola outbreak)

[Jean-Marc Liotier]

On 12/12/18 2:16 AM, Ralph Aytoun wrote:


I am also concerned about the quality of the mapping that is tying up 
projects because it takes up so much validation time. [..]


This perception is (don't take it personally - I answer your message but 
I'm not singling you out) a symptom of a widespread problem: quality 
perceived as a separate activity, an extra cost tacked on the actual 
productive work.


Considering the quality assurance process as a distinct set of 
activities has the very unfortunate effect of creating an unnecessary 
conflict with production.


So:
- Start with a clearly defined objective quality goal, just adequate for 
the planned purpose of the data
- Teach contributors that not meeting this goal is worse than doing 
nothing: negative value
- Monitor contributions in real time, to catch deviations before they 
snowball... I love Bjoern's idea, though OSMCHA works for me

- Reiterate !

Quality is the essence of the whole activity, not a distinct step.

Yes, it spoils the fun for new contributors thrilled to start mapping 
away and see their gamified metrics take off spectacularly in a rain of 
digital achievement awards. But it also helps them make sense of what 
they are doing instead of launching them on an open ended trip with a 
hazy purpose - and what is better than to find meaning in a task ?


Normative leadership may feel incompatible with a flat collaborative 
forum such as Openstreetmap, but it makes sense within a directed 
project with a declared purpose, to which contributors voluntarily 
participate. If they trust the project leadership enough to join as 
contributors, they may expect the normative guidance and even be 
disappointed not to feel it from the leadership.


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

Re: [OSM-talk-fr] Osmose - Délai

[Jean-Marc Liotier]

On Mon, October 22, 2018 6:46 pm, Adrien André wrote:
>
> à quoi correspond la valeur "Délai" affichée sur l'interface web
> d'Osmose ?

Délai entre le dernier changeset analysé par Osmose et le dernier
changeset de la base de données Openstreetmap.


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

Re: [OSM-talk-fr] [Tagging-fr] Vote ouvert pour la carto des réseaux télécoms

[Jean-Marc Liotier]

On 10/15/18 6:01 PM, François Lacombe wrote:
Ceci dit, en donnant assez de visibilité à nos activités, peut-être 
que les opérateurs seront motivés et comprendront le sens de tout ça, 
à suivre !


On peut toujours rêver...

Ceci dit, je suppose que la mention de GraceTHD dans ta présentation 
n'est pas innocente: s'il y a un espoir, il est du côté des 
collectivités locales, dont les intérêts ont des chances de finir par 
s'aligner sur un fonctionnement collaboratif.


J'imagine bien, pour les échanges inter-opérateurs, l'intérêt politique 
des collectivités locales d'avoir comme *_codeext un objet commun, 
neutre à tous points de vue et géré collectivement, au lieu d'utiliser 
les identifiants internes de $opérateur1, $opérateur2. Peut-être un 
montage analogue à la BAN ?



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

Re: [OSM-talk] [HOT] [OSM-dev] Tool update from HOT: MapCampaigner

[Jean-Marc Liotier]

On Mon, October 8, 2018 1:02 am, Harry Wood wrote:
>
>> Jean-Marc Liotier  wrote:
>> If one needs number to report back to donors, then integrate this
>> sort of thing with the task manager - and explain to donors how
>> erroneous data is sharply negative value
>
> I think this little "number to report back to donors" comment does betray
> a belief I've heard expressed quite often in the wider OSM community, that
> humanitarian mappers are allowing OpenStreetMap to be co-opted by large
> aid organisations [..]

In West Africa (the region where I have direct Openstreetmap experience
and personal engagement with individuals), most organized mapping projects
(rarely the largest contributions in terms of volume of data, but the most
productive ones in terms of enrolling new contributors and weaving
community connections) have at least some financial backing from
organizations, not necessarily large ones. The training cadre spans the
whole spectrum from pure volunteers to professionalized - and those are
accountable to their backers, who expect a bit of reporting, which
includes some measure of quantification. There is nothing wrong with that
perfectly normal requirement but, as any manager knows, the temptation is
strong to fulfil it using the easily available metrics.

Balancing the key performance indicators mix to better align objectives
with Openstreetmap's goals looks like a workable avenue of progress to me
- to everyone's benefit, but that requires conviction about the
complementary merits of quality vs. quantity and consensus about relevant
metrics. Completeness measurements such as MapCampaigner's most certainly
have a role to play, but my perception from wading in West African
changesets is that not producing erroneous data is a higher priority. That
conclusion may of course not apply to other regions I have no experience
with.


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

Re: [OSM-talk] [HOT] [OSM-dev] Tool update from HOT: MapCampaigner

[Jean-Marc Liotier]

On Mon, October 1, 2018 9:56 am, Nate Smith wrote:
>
> If you have some ideas on additional quality metrics we could add, that
> would be great as this tool is just getting started. I would definitely
> like to include more ways we can think about what quality data means
> during field mapping.

We can imagine all sorts of tools but they won't matter as long as some
circles remain in the mindset that sowing the seeds is the end of the
process and the subsequent gardening doesn't matter.

Instead of feeding newbies into task manager operations, show them a few
specific classes of easy errors (such as Osmose's "overlapping buildings",
"building intersects with highway" or "crossing highways") and let them
clean up a zone. Only then let them add buildings - with enhanced quality
awareness. No new tool needed - only a different focus.

If one needs number to report back to donors, then integrate this sort of
thing with the task manager - and explain to donors how erroneous data is
sharply negative value, that an error corrected is even better value than
a new datum and that for their money to have actually usable impact it
needs some share to be allocated to quality control.


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

Re: [OSM-talk] [HOT] Tool update from HOT: MapCampaigner

[Jean-Marc Liotier]

On Mon, October 1, 2018 7:57 am, Frederik Ramm wrote:
>
> On 01.10.2018 03:28, Nate Smith wrote:
>> Last week we released a new version
>> of a data quality monitoring tool
>
> I would like to recommend that you don't use the term "quality
> monitoring tool" for this since you're measuring quantity not quality.
> At best, I'd call it a tool that monitors "richness" or "completeness".
[..]

And let's underline that Frederik's remark is not semantic nitpicking in a
vacuum: in the context of HOT's campaigns the quality vs. quantity issue
has quite a track record.

Integrating within the task manager the tracking of the quantity of Osmose
defects would go some way towards addressing the monitoring of actual
quality. Tying a selection of Osmose errors categories to the "validation"
step would help make it an actual validation rather than a formal
rubberstamp - doesn't even need to be mandatory, it just needs to be made
visible. Actual quality assurance tools are just there within arm's
reach...

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

Re: [OSM-talk] finding settlements where the highways do connect across the settlement

[Jean-Marc Liotier]

On Wed, July 4, 2018 6:12 pm, john whelan wrote:
> I'm using JOSM and find unconnected highways is useful but in Africa I'm
> seeing a number of settlements that have highways entering on both sides
> but nothing connecting them which poses problems for routing software.
>
> Any suggestions ?

Connect them !

Seriously, even if you don't feel like detailing their path across the
settlement, road network connectivity is worth the urban imprecision... In
the beginning of Openstreetmap, major ways coming into major cities would
just meet in the middle !

Playing with routers such as OSRM is a way I have sometimes stumbled upon
such cases of disconnection.


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

Re: [OSM-talk] [HOT] Why the HOT obsession with low quality buildings in Africa ?

[Jean-Marc Liotier]

On Wed, July 4, 2018 1:47 pm, Oleksiy Muzalyev wrote:
> Sometimes I myself cannot recognize on a satellite image what kind of
> building it is, - a warehouse, a cowshed, a factory, etc., or how many
> levels it has got. I have to look at its shadow, surroundings, roof
> surface, to make a guess.

Imagery interpretation is artful indeed - it takes practice to train the
eye, but then recognizing features from elusive hints, such as a tall
structure from its shadow, becomes reflex.

This is an area where having travelled in the target area helps a lot -
with nothing but the imagery I can with near-certainty recognize most
Senegalese schools... But I'm entirely lost trying to do the same in
neighbouring Guinea !


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

Re: [OSM-talk] [HOT] Why the HOT obsession with low quality buildings in Africa ?

[Jean-Marc Liotier]

On Tue, July 3, 2018 7:20 pm, john whelan wrote:
> I think my concern is more about the 'then a miracle occurs' in the
> project plan to clean up the buildings.

Yes because, among other reasons:
- For most people, verifying is not as gratifying as creating
- Correcting entirely incorrect geometries is many ways more work than
re-creating them from scratch

I am not concerned about the most egregious cases: cars & trucks modelled
as buildings, duplicates & superposed, rubbish heaps and vague shadows as
building=yes, buildings found in old imagery... Those I delete with no
hesitation.

I am not concerned either about minor simplifications or errors such as
the shape being traced on the roof of the building rather than its base -
those I let them be and correcting them capitalizes on a good foundation.

I am concerned about the cases where a building does exist in reality, the
shape is less than ten meters from its position, some of the shape
overlaps the building's position on the imagery and some of the shape
resembles some of the building. In those cases, there is some value in the
record: approximate position and area of the building. But there is also
the liability of having introduced a low-quality object in the database.

I am convinced that the immense majority of those buildings will never be
corrected. In ten years, we can expect massive campaigns of automated
image recognition to produce new building layers - but even then the
extensive conflation will be an horribly tedious job.

Meanwhile, for areas with reliable imagery, I can imagine Maproulette
jobs: something in the spirit of "Does this building at least partially
overlap one in the imagery and does it approximately resemble the one in
the imagery ?". Those jobs could be designed at national or regional
levels - under control of the local communities. They could be a way of
systematic quality control. But maybe I'm horribly deluded about how many
people would volunteer for such a mind-numbing task. Also, looking at
buildings one at a time is very inefficient compared to panning through an
area on JOSM - but then again, JOSM-enabled contributors that might be
motivated for this are not exactly in plentiful supply either.

And that does not even answer the question: what to do with the
"low-quality  shape but actually exists" cases ? I am at a loss to answer
that.

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

Re: [OSM-talk] [HOT] Why the HOT obsession with low quality buildings in Africa ?

[Jean-Marc Liotier]

On Tue, July 3, 2018 3:56 pm, mohamet lamine Ndiaye wrote:
> I am Mohamet Lamine Ndiaye [..]

Nangadef, I'm happy to hear from you - it has been a long time !

> [..] I think this is the umpteenth time we talk about it

Yes, this is a pet issue of mine - I hope that one day I'll understand why
you all seem to put so much time and energy into those buildings that I'm
not happy about... But hopefully they make other people happy !

> [..] However, it should be noted that in terms of the quality of the
> images and the density of the mapping areas, the contributors find it
> difficult to distinguish the actual boundaries of the Buildings

Yes - and distinguishing between building parts and the whole buildings is
a challenge for even the keenest eye.

> [..] Nevertheless, this does not preclude the use of these data in
> large-scale and highly resilient projects for the populations.

Do you have examples of use of that data ? That would help me understand
the benefits of mapping buildings even if they are approximate.

> [..] Other things, you should know that there are neighborhoods that do
> not benefit from subdivision and non-harmonized architecture of some lots
> do not promote aesthetics.

Indeed, the less orthogonal parts of town are a great challenge. Odette
(who is currently doing an internship at my company) told me about her
experience updating the cadastre in Ngor - it was a nightmare and they had
excellent drone imagery... So for an Openstreetmap contributor with only
orbital imagery it is simply impossible to do right - which is why I
wonder: instead of that herculean effort, why not settle for a simpler
model that provides the same data at a granularity closer to what our
resources let us record with adequate quality ?

> [..] What is important for me is that we have to start with something
> and although these data are of inferior quality, they respond to
> operational needs on the ground in case of disaster

A landuse=residential with residential=* (currently values of
residential=* are mostly "rural" and "urban" but a finer-grained
nomenclature could be designed such as "sparse single family", "dense
single family", "sparse urban", "dense urban") would provide approximate
population impact calculations at a fraction of the effort and without the
side effect of producing low quality buildings. Of course, buildings offer
much better precision - but only if they are actually precise: if a
building is mapped as two rectangles and the two sheds in the courtyard
are also mapped as generic buildings, is the result less precise than the
surfacic approximation ?

Sure, quite a few contributors do excellent work - but there is currently
not enough of them available to perform the huge task with high precision
everywhere.

> if we have data released by the cadastre

If you ever get your hands on that, I will be mightily impressed by your
advocacy work... So far I failed at getting even a simple list of street
references so I find difficult to imagine the day when Senegalese and
Malian government agencies will release cadastre and geodesic network. I'm
glad that you remain optimist... And after all, before French contributors
got their hands on IGN orthophotography and vector cadastre, many of us
(including me) didn't think it was possible - and then it happened thanks
to the efforts of the optimists and stubborn among us !


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

Re: [OSM-talk] [HOT] Why the HOT obsession with low quality buildings in Africa ?

[Jean-Marc Liotier]

On Tue, July 3, 2018 10:46 am, Rupert Allan wrote:
>
> [..] 'some data being better than no data' [..]

Yes but, in that case, landuse combined with density and/or building type
attributes do the job more cheaply and with none of the low quality
stigma. But, of course, there may be other reasons for insisting on
building shapes.

> Building materials and standards are used to map [..]
> A simple look at OSM metrics of, say, thousands of
> grass rooves amongst tin rooves in a fire, or hundreds of mud
> walls instead of concrete in an immanent flood, really helps.
> At this point, this data directly impacts
> and/or saves thousands of lives.
>
> That's my obsession.
>
> *Rupert Allan*
> Country Manager - Uganda

While building=hut is a useful distinction that is widely recorded in
relevant locations
(https://taginfo.openstreetmap.org/tags/building=hut#map, the
building=material you seem to refer to is actually not very popular
outside of Europe
(https://taginfo.openstreetmap.org/keys/building%3Amaterial#map) - in your
country it only appears 693 times (http://overpass-turbo.eu/s/A2C)

Most of the buildings I seen in Senegal and Mali are building=yes with no
other attribute... So, for now at least, this is not a question of
building materials.


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

Re: [OSM-talk] Why the HOT obsession with low quality buildings in Africa ?

[Jean-Marc Liotier]

On Mon, July 2, 2018 1:26 pm, Robert Banick wrote:
> Many humanitarian groups use buildings as a rough proxy for population

Yes, I have had that explanation from multiple sources involved in
humanitarian uses of Openstreetmap: from that they can calculate, for
example, the impact a a flood.

I believe that it is an awfully expensive way to gather that data.

A landuse=residential with a density qualifier may do the trick cheaply
with the addition of a density qualifier attribute: single family houses,
sparse multi-tenant buildings, dense multi-tenant buildings... This is
actually the data model used by the government of Senegal at their
national level with a street-level granularity.

If one wants to go further and count the number of dwelling units, then a
node is sufficient (maybe along with an attribute to discriminate single
or multi-tenancy)

Shapes are of course good for many other uses but, if the actual user
requirement that data is gathered for is a population density map, then
they are a waste of resources. I'm pretty sure that contributors are
happier if their efforts are directed at profitable purposes.

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

Re: [OSM-talk] [HOT] Why the HOT obsession with low quality buildings in Africa ?

[Jean-Marc Liotier]

On Mon, July 2, 2018 11:55 am, AMEGAYIBO Kokou ELolo wrote:
>
> The majority of these tasks were created in training workshops on
> OpenStreetMap in Bamako, quality control work is done afterwards by the
> local community normally. I share your points of view, but for training
> workshops it is our best method to channel, control the work of the
> newbies and also familiarize them with the use of the Tasking Manager.
> I am open to any contribution who can help us improving our approach.

I understand the difficulty of getting large numbers of new contributors
started with Openstreetmap - mistakes are normal and must be accepted as a
cost of growing the project. Nevertheless, I think that there are ways to
keep that cost lower.

First, and most important, I believe that quality control should not be
relegated to "done afterwards" - especially with less proficient
contributors who are most likely to make mistakes, and especially if they
are enthusiastic (it pains me to see incredible dedication in go to
waste). Quality control must be an integral part of the contribution and
that must be drilled into new contributors as early as possible. Insist on
using the JOSM Validator, have the users look at their own contributions
on Osmose... Show them how to be more responsible of their own work ! Or
course, having experienced users supervise is valuable but they are a
scarce resource and most importantly they risk infantilizing less
experienced contributors. Most of my own contributions start with looking
at Osmose, seeing a bunch of errors and I start editing there... Quality
control is a core skill for everyone, at every level of proficiency.

Second, have users. Creating data costs, maintaining it costs... Why are
we doing it ? We are doing it for users. How do we judge quality ? I am as
fond of the map as an aesthetic object as anyone here but we all agree
that we want to put our efforts to good uses - so we judge quality by the
fitness of the product for a particular use. If the data has no users, it
is dead data.  For example, as a user, I am a walker and a cyclist - I
enjoy buildings on the map as landmarks to help me navigate... That is my
personal way of judging quality - but other users may have other ways: to
some users the purpose of having buildings in Openstreetmap may just be
"there is a building here and its shape is not that important" - and maybe
those users are the majority, who knows ? So, as a producer of data, be
aware of how the data is used - that is the key to rational quality
control. That remains true if you just chose the buildings as a new
contributor training object.

Third, make sure that the most recent imagery of decent quality is used.
For the specific case of Bamako and at the current time, ESRI World is
better than Bing: https://i.imgur.com/w6YBG70.jpg - of course, this is
subject to change over time. In understand that, for lack of available
properly surveyed geodesic reference points, large numbers of users
working with multiple sources of imagery generates its own challenges (I
found that particularly frustrating in Dakar's suburbs).

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

Re: [OSM-talk] [HOT] Why the HOT obsession with low quality buildings in Africa ?

[Jean-Marc Liotier]

On Mon, July 2, 2018 2:59 pm, Vao Matua wrote:
> When you say "low quality" buildings, do you mean the quality of the
> polygon data or are you judging someone's home to be of low value?

The tracing of course - mud shacks and posh villas are all equal before
Openstreetmap contributors !


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

[OSM-talk] Why the HOT obsession with low quality buildings in Africa ?

[Jean-Marc Liotier]

Active in Senegal and Mali, I have noticed that changesets tagged with
tasking-manager HOT projects produce very large numbers of buildings.
Those buildings appear to be of very low quality. I wonder: who uses
this data ?

If it is only necessary to assess that people live there, then a
landuse=residential is sufficient

If it is necessary to count the number of dwelling units to infer
population, then a node is sufficient (maybe along with an attribute to
discriminate single or multi-tenancy)

If the geometry is actually necessary, then I wonder if anyone is
satisfied with those semi-random shapes that, with some optimism, may be
identified as being in the vicinity of actual buildings (most of the
time)

Enthusiastic contributors expend an awful lot of effort in flooding the
map with low-quality buildings. I have seen ruins, building parts,
walls, vague shadows on the ground, rubbish heaps, market stalls, cars
and trucks all tagged as buildings - and I'll charitably keep from
commenting on the geometric quality of those that attempt to map actual
buildings (and I'll leave aside the issue of HOT leads requiring the use
of outdated imagery such as Bing instead of ESRI World in Bamako). Is it
the most useful way to channel the energy of inexperienced contributors
?

I often find myself wishing that HOT leads introduce them to
Openstreetmap through Osmose quality control rather than by churning out
buildings like demented stonemasons trying to reach their weekly quota
of gamified task-managing !

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

Re: [OSM-talk-fr] Vinci Autoroutes et l'attribution à OpenStreetmap

[Jean-Marc Liotier]

On Tue, 10 Apr 2018 15:18:17 +0200
Rpnpif  wrote:
> 
> Il manque la mention "et les contributeurs" mais bon

D'après
https://wiki.openstreetmap.org/wiki/Legal_FAQ#3a._I_would_like_to_use_OpenStreetMap_maps._How_should_I_credit_you.3F
cette mention est optionnelle:

"Because OpenStreetMap is its contributors, you may omit the word
'contributors' if space is limited"

Sur un écran de mobile, où chaque centimètre carré compte,
l'attribution "© Openstreetmap" fera donc parfaitement l'affaire, même
si la mention complète est recommandée dans d'autres contextes.

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

Re: [OSM-talk-fr] Vinci Autoroutes et l'attribution à OpenStreetmap

[Jean-Marc Liotier]

On Tue, 10 Apr 2018 15:18:17 +0200
Rpnpif  wrote:
>
> Il manque la mention "et les contributeurs" mais bon

Je n'ai jamais compris le sens de cette mention - il me semble que
"Openstreetmap" représente ses contributeurs... Il y a probablement une
subtilité que je n'ai pas saisi. Quelqu'un sait l'expliquer ?

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

Re: [OSM-talk-fr] Complétude des réseaux électriques en pays de Savoie

[Jean-Marc Liotier]

On Fri, 1 Dec 2017 12:45:35 +0100
François Lacombe  wrote:
> 
> D'après l'opendata Enedis disponible sur leur site, OSM atteint la
> longueur des lignes aériennes 20 000 volt à 1km près (3263km pour
> OSM). Élément de repérage et d'attention obligatoire pour certaines
> pratiques sportives en extérieur si il en est. [..]

Le repérage pour la navigation à vue est mon intérêt pour les lignes à
haute tension dans Openstreetmap - mais je sais que tes efforts en la
matière vont bien plus loin... Connais tu des utilisateurs du niveau de
détails auquel tu pousse la modélisation ?

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

Re: [OSM-talk] How to map alleys in African cities?

[Jean-Marc Liotier]

On Tue, 14 Nov 2017 21:26:02 + (UTC)
Pierre Béland  wrote:
>
> I we follow the Highway Tag Africa wiki page I initiated in 2013,
> narrow highways should be evaluaed on the type of traffic possible -
> highway= residential in residential areas if at least passable by 4
> wheels- highway=path if only motorcycles, bicyles and foot traffic is
> possible. https://wiki.openstreetmap.org/wiki/Highway_Tag_Africa

I second Pierre's reference to the Highway Tag Africa. Residential
streets mapped as highway=service an all too common error in African
cities.

Same problem here as for highway=living_street - a conversation we had
a year ago:
https://lists.openstreetmap.org/pipermail/talk/2016-December/thread.html#77191

Mappers from more developed countries expect a residential street to
look like their idea of a residential street - for example the lack
of sidewalks confuses them... But it is a residential road nevertheless.

I'm partial to always using surface=* but maybe sidewalk=no will also
help make confused residential mappers happier with tagging a six-meter
wide sandy residential street with no sidewalk as
highway=residential... (I just wrote that and realize I wrote almost
the same thing last year... I'm getting old
https://lists.openstreetmap.org/pipermail/talk/2016-December/077195.html)

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

Re: [OSM-talk-fr] Prise de contact

[Jean-Marc Liotier]

On Tue, 3 Oct 2017 14:15:52 +0100
Mahamat Laouane  wrote:
>
> Nous sommes ravi d'être parmi vous et nous contribuons depuis le
> Tchad(Afrique). Cependant on a quelques préoccupations. On vient en
> effet de mettre sur pieds l'association locale et nous cherchons une
> légitimité globale. Que faire ?

Parlez-en sur  - vous y trouverez
des contributeurs de plusieurs autres pays voisins, dont certain ont
parcouru un long chemin dans l'animation de structures Openstreetmap
locales.

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

Re: [OSM-talk] Fixing wiki* -> brand:wiki*

[Jean-Marc Liotier]

On Wed, 27 Sep 2017 15:59:34 +0200
Frederik Ramm  wrote:
>
> "amenity:wikidata=Q123456" on something that is, say, an ice cream
> parlour because Q123456 is the generic Wikidata category for ice
> cream parlours

I thought wikidata tags were for unique objets, which usage I believe
is welcome... If they are applied to categories then it is something
else entirely.

I would agree that the matching of a generic Openstreetmap tag to a
Wikidata identifier is Wikidata's business... But then maybe a
Wikidata-centric view of the model will consider it is Openstreetmap's
business...

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

Re: [OSM-talk-fr] Contribution arbres remarquables du Bas-Rhin

[Jean-Marc Liotier]

On Tue, 26 Sep 2017 10:44:10 +0200 (CEST)
Vincent de Château-Thierry  wrote:
>
> > De: "PIERRE Sylvain" 
> > 
> > Cet inventaire comporte un volet géographique visible ici :
> > http://sigweb.bas-rhin.fr/arbrem/ , plus de 250 arbres étant
> > recensés à ce jour. Notre collectivité souhaiterai pouvoir « pousser
> > » ces arbres dans OSM.  
> 
> Compte tenu du volume de données, relativement modeste, il n'y a
> peut-être pas lieu de trop phosphorer sur un "import" [..]

Certes, mais... Il y a cinq ans, mon ambition était d'utiliser le cas
des arbres remarquables, peu nombreux, pour rôder le processus de
synchronisation avant de l'appliquer aux arbres d'alignements et autres
arbres des Hauts-de-Seine considérablement plus nombreux - beaucoup trop
pour une gestion manuelle.

Si le cas des 250 arbres est isolé, alors la génération à sens unique
de XML JOSM et son injection après revue humaine est parfaitement
satisfaisante - et tant pis pour les nouvelles versions du fichier des
arbres remarquables du Bas Rhin: la mise à jour aura lieu manuellement.

Si d'autres sources similaires pourraient être exploitées, alors on
peut réfléchir à de l'outillage.

Bon, j'admet un gros biais personnel en faveur de l'industrialisation
lourde et parfois prématurée - mort aux tâches manuelles sans valeur
ajoutée... Même parfois lorsque les automatismes coûtent plus cher que
la prestation humaine - mais c'est tellement plus satisfaisant...

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

Re: [OSM-talk-fr] Contribution arbres remarquables du Bas-Rhin

[Jean-Marc Liotier]

Also sprach PIERRE Sylvain [Mon, Sep 25, 2017 at 02:39:19PM +] :
> 
> Le département du Bas-Rhin a initié depuis 5 ans un inventaire des arbres 
> remarquables.
> Cet inventaire comporte un volet géographique visible ici :
> http://sigweb.bas-rhin.fr/arbrem/, plus de 250 arbres étant recensés à ce
> jour.
> 
> Notre collectivité souhaiterai pouvoir « pousser » ces arbres dans OSM.

Il y a bien longtemps, émerveillé par les arbres que les Hauts-de-Seine
mettaient à disposition librement, j'avais commencé à étudier un
import/synchronisation avec Openstreetmap. J'ai lâchement abandonné en cours de
route, pataugeant dans un machin XML-relationnel trop ambitieux que je tairai
donc pudiquement... Mais mon étude de l'étiquetage envisagé pourrait
éventuellement participer à votre inspiration:
https://wiki.openstreetmap.org/wiki/WikiProject_France/Open_Data_Hauts-de-Seine_Arbres


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

Re: [OSM-talk-fr] comment cartographier un marais ?

[Jean-Marc Liotier]

On Thu, 7 Sep 2017 18:07:38 +0200
Adrien Grellier  wrote:
>
> Pour les canaux, il faudrait indiquer un sens de circulation de l'eau
> (waterway=stream)… En l’occurrence, c'est tout plat, l'eau ne court
> pas comme dans une rivière ! Comment doit-on procéder dans le cas
> présent ?

https://lists.openstreetmap.org/pipermail/tagging/2017-September/033403.html
propose flow_direction=both.

https://taginfo.openstreetmap.org/keys/flow_direction#values - peu
utilisé mais me semble approprié.

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

Re: [OSM-talk-fr] traduction shop=boutique shop=fashion

[Jean-Marc Liotier]

On Fri, 1 Sep 2017 12:03:50 +
marc marc  wrote:
>
> Perso n'a un avis sur la traduction ?

J'affiche insolemment mon absence d'avis: pour moi ce sont tous des
shop=clothes. Pourquoi le positionnement marketing devrait-il être
reflété dans une étiquette de premier niveau alors qu'il ne l'est pas
pour la plupart des types de POI ? shop=car s'applique à tous alors que
les canaux de distribution de véhicules automobiles sont d'une diversité
tout aussi extrême.

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

Re: [OSM-talk] Beach routing

[Jean-Marc Liotier]

On Tue, 29 Aug 2017 13:36:49 +0200
Oleksiy Muzalyev <oleksiy.muzal...@bluewin.ch> wrote:

> On 8/29/2017 12:50 PM, Jean-Marc Liotier wrote:
> > ...
> > I fail to imagine a beach that is not walkable.
> > ...  
> 
> In France, yes. [..] In other parts there are still beaches which
> could belong to a company, an organization, to a private person, and
> there is no access there due to a fence or a barrier [..]

Indeed I had forgotten that French littoral law is exceptionaly
protective of the commons - by law one can walk along the entire French
coast unhindered, except of course by physical features such as cliffs.

But this is no different than highway modeling in Openstreetmap: by
default the highway is accessible and access=* may specify exceptions
to that - access=* can apply to natural=beach just as well as all the
other Openstreetmap objects it already applies to.

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

[OSM-talk] Beach routing

[Jean-Marc Liotier]

Last week-end I went hiking along the coast from Honfleur to
Trouville-sur-Mer. As I wondered what distance I walked, I turned to
Openstreetmap routers... And did not find my answer: beaches are not
considered as highways.

I thought about adding paths to beach sections that I consider
walkable... But, while some of those beaches have an identifiable path
along their length, for the most part this would be tagging for the
router.

I fail to imagine a beach that is not walkable. So, should the routers
use natural=beach the same way as highway=path+surface=(sand|gravel|*) ?

The question of routing across natural=beach brings back the past debate
about highway=pedestrian+area=yes - most routers do not route over
areas.

I just dug this thread, which goes along the same lines as my reflexions
(https://lists.openstreetmap.org/pipermail/talk-us/2014-July/013280.html)
but does no definitely concludes either.

My conclusion is that I should open wishlist entries for my favorite
routers... Is it a good idea ?

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

Re: [OSM-talk-fr] Champs phone : futur projet du mois ?

[Jean-Marc Liotier]

On Mon, 28 Aug 2017 23:00:57 +
marc marc  wrote:
>
> Le 28. 08. 17 à 23:06, Romain MEHUT a écrit :
>  > je vois souvent les numéros avec des espaces...  
> cela dépend de la norme. y a des espaces, des tirets ou rien.
> norme en partie dépassée puis que beaucoup de pays n'ont plus
> de code région vu la portabilité des numéros à l'échelle d'un pays.
> De toute façon les séparateurs sont non significatif et virés
> lors de la composition du numéro.
> [..]

Stockons \+\d+ et laissons à la couche de présentation le privilège de
formater à sa fantaisie.

Pour ma part c'est Z ABPQ MCDU, mais je conçois que cette affirmation
identitaire de dinosaure des télécoms n'est pas du goût de tout le
monde...

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

Re: [OSM-talk-fr] Création de la liste OSM tagging-fr - communication - fragmentation

[Jean-Marc Liotier]

On Tue, 22 Aug 2017 14:21:00 +
marc marc  wrote:
>
> pour rebondir sur ton exemple, 16 ml locales, quasi + que d'actif.
> un paquet n'a pas eu de message cette année, une partie est à 1/mois
> n'est-on pas allez trop loin ? 5 ne serraient-ils pas suffisant ?

Une partie de ces listes sont en pratique plutôt des canaux de diffusion
d'annonces et non des lieux de discussion - la spécificité nationale
est donc peut-être importante, malgré l'apparence d'insignifiance.
J'ignore si les abonnés en sont satisfaits.

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

Re: [OSM-talk-fr] Création de la liste OSM tagging-fr

[Jean-Marc Liotier]

On 2017-08-20 00:12, marc marc wrote:
> C'est en soi une très bonne idée que de fédérer la francophonie.
>
> Mais quand je vois que pour la discussion de certains tag, on n'est
> parfois pas nombreux à en discuter sur talk-fr, je me demande si diviser
> avec une ml supplémentaire n'est pas contre productif,

Vues les premières réactions, la fragmentation des canaux est un
problème auquel nous devrons prêter une attention accrue.

D'un autre côté, la fragmentation des canaux et également une réponse au
problème de la fragmentation des publics: la langue est une dimension
culturelle, mais pas la seule - l'affinité pour une technologie de
communication ou une autre est aussi une dimension culturelle.

Côté langue, je peux témoigner vu mes échanges notamment Ouest-Africains
qu'il existe un public de contributeurs tout à fait savants de
géographie mais pour qui l'anglais est un obstacle majeur - il me semble
donc que l'opportunité de discussions en Français est une offre
intéressante. Peut-être que talk-fr pourrait être ce lieu - ou peut-être
qu'il est trop connoté "France" pour la Francophonie non-Française.

Côté technique, le débat me semble moins clair mais je crois deviner un
positionnement possible: les listes de diffusions ont tendance à fédérer
des contributeurs technophiles expérimentés - la barrière de
l'inscription et de la gestion des messages n'est pas franchie
spontanément par les contributeurs moins engagés. Donc, on peut
s'attendre a avoir rapidement un petit groupe d'experts prêts à discuter
tout sujet qui émergera dans leur boite aux lettres. Mais il y a aussi
des contributeurs demandeurs de clarifications, que nous rencontrons
parfois sur les listes Francophones nationales (talk-sn, talk-ml etc.),
en messages directs dans la messagerie Openstreetmap ou dans les
changeset discussions - avoir un guichet garni d'experts responsifs vers
lequel les orienter me semble être réponse potentiellement pertinente au
besoin de traiter des problématiques émergentes sur lesquelles butent
des contributeurs locaux mais auxquelles les experts en question n'ont
pas été confronté faute d'un terrain les suscitant - reste à savoir si
le choix d'une liste de diffusion leur conviendra.

En tout cas je participerai à tagging-fr  et nous verrons bien si
quelque chose émerge.

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

Re: [OSM-talk-fr] Uploader ensemble de waypoints d'un fichier GPX ?

[Jean-Marc Liotier]

On Fri, 11 Aug 2017 07:47:25 -0500 (CDT)
Shohreh  wrote:
>
> Par contre, même dans une petite ville, ça fait déjà trop de données,
> et OSM m'oblige à zoomer et ne récupérer qu'une sous-partie : "Bad
> Request: The OSM server 'api.openstreetmap.org' reported a bad
> request. The area you tried to download is too big or your request
> was too large. Either request a smaller area or use an export file
> provided by the OSM community."

http://api.openstreetmap.fr/api offre en lecture seule le même service
que http://api.openstreetmap.org/api mais avec beaucoup moins de
limitations - tu peux récupérer d'un coup de grandes régions. Il m'est
d'ailleurs très utile pour charger une agglomération entière dans JOSM,
lancer le JOSM Validator sur l'ensemble et traiter le tout sans se
sentir ralenti par les chargements intempestifs - je suis désolé qu'il
soit actuellement en panne... Et ce ne sera donc pas ta solution du
jour.

Cf. https://wiki.openstreetmap.org/wiki/FR:Serveurs/api.openstreetmap.fr
pour plus de détails.

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

Re: [OSM-talk-fr] Uploader ensemble de waypoints d'un fichier GPX ?

[Jean-Marc Liotier]

On Fri, 11 Aug 2017 06:49:45 -0500 (CDT)
Shohreh  wrote:
> [..]
> Là, JOSM dit : "You are about to upload data from the layer
> "Mylayer.osm". Sending data from this layer is STRONGLY DISCOURAGED."
> 
> À quelle étape me suis-je trompé?

Aucune... Les importations ont fait tellement de mal que, sauf preuve
irréfutable de leur innocence et de la diligence la plus zélée du
contributeur, elles sont "STRONGLY DISCOURAGED".

Ta méthode inclue bien l'étape de vérification humaine des données
importées, qui ne sont donc plus importées mais intégrées:
différence subtile mais qui pour Openstreetmap marque la frontière entre
l'inacceptable et l'acceptable.

Fort de cette sagesse, tu peux passer outre l'avertissement de JOSM.

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

Re: [OSM-talk-fr] Uploader ensemble de waypoints d'un fichier GPX ?

[Jean-Marc Liotier]

On Thu, 10 Aug 2017 07:44:12 -0500 (CDT)
Shohreh  wrote:
> 
> J'ai utilisé un GPS Garmin pour marquer un ensemble de waypoints
> homogènes, c.a.d. qu'ils représentent tous le même type d'objet.
> 
> Comment faire ensuite pour 1) ajouter un tag à chacun puis 2)
> uploader tout ça d'un coup dans OSM?

Un glissé-déplacé de l'icône du fichier dans JOSM en fera une couche
GPX dont le menu contextuel proposera "Convert to data
layer" ("Convertir en calque de données"). Tu pourras alors éditer
cette couche puis, lorsque tu en seras satisfait, aller dans le menu
contextuel choisir "Merge" ("Fusionner") qui, comme son nom l'indique,
fusionnera ton import avec la couche de ton choix - tu choisiras
probablement les données Openstreetmap de la zone que tu mettras ainsi
à jour.

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

Re: [OSM-talk] Revisiting traffic control and traffic calming

[Jean-Marc Liotier]

On Sun, 7 May 2017 01:57:54 -0500
Paul Johnson  wrote:

> I think it's time that we seriously reconsider how stop signs, yield
> signs and traffic calming devices are handled in all but the most
> simple (all approaches to the affected node apply) cases. [..] I'm
> thinking it's time to start mapping this similar to how we handle
> enforcement and turn restrictions, ie, with relations, for all but
> the simplest of cases, especially since the whole forward/backward
> direction=* thing is nonapplicable to nodes by design.

Do you have in mind something like
https://wiki.openstreetmap.org/wiki/Relation:enforcement ?

From the points of view of edition and data modeling, I believe that it
is the way forward.

From the point of view of data consumers, it requires grokking
relations - which is currently not common. Would that be a reason not
to choose that method ?

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

Re: [OSM-talk-fr] Marché public données OSM

[Jean-Marc Liotier]

On Tue, 28 Mar 2017 07:43:05 +
"HELFER Denis (SNCF RESEAU / SIEGE SNCF RESEAU / DT GE APPUI
PERFORMANCE)"  wrote:
>
> Extrait du DCE :
> 
> 3.2 MODERER LES CONTRIBUTIONS EXTERNES
> De plus, la diversité de la qualité des contributeurs entraîne une
> information renseignée parfois inexacte ou incomplète. La volonté du
> STIF est de mandater un prestataire en charge de modérer les données
> renseignées sur OSM par des contributeurs externes.
> 
> Maintien de la qualité des données au sein d’OSM, c’est pas
> suffisant ?

Les clients expriment généralement le besoin d'avoir quelqu'un sur qui
taper en cas de problème et par conséquent ils désignent leur
prestataire comme responsable des données. Le prestataire a tout
intérêt à améliorer la qualité en amont, au sein d'Openstreetmap - mais
du point de vue du client Openstreetmap n'existe pas et le prestataire
est l'unique fournisseur de données dont il est réputé contrôler la
qualité.

En pratique et dans l'état actuel d'Openstreetmap j'imagine mal le
client pénaliser le prestataire pour une boite aux lettres manquante ou
un défaut de capitalisation dans le nom d'un restaurant... J'imagine que
la clause a plutôt pour but de s'assurer que le planet béni par le
prestataire ne contient pas un highway=primary gonadomorphe recouvrant
la région.

Je serai le prestataire, je demanderai quand même de définir un petit
peu plus précisément les indicateurs de qualité retenus pour mesurer
l'exécution du contrat.

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

Re: [OSM-talk] A tool for picking up settlements tagged as a single building?

[Jean-Marc Liotier]

On Sat, 25 Mar 2017 13:25:35 -0400
john whelan  wrote:
>
> It's something I've noticed in Africa so its probably not putting new
> mappers through a month's training first but many villages have been
> mapped but tagged as a single building with building=yes.
> 
> They aren't grouped together but rural Africa doesn't have that many
> large foot print buildings so it should be possible to pick them out
> based on location and size.

And by the way, if you wonder why a bunch of buildings are tagged as
building=yes when that tag is meant for single buildings, I received a
possible answer from Senegalese contributors: some have been taught to
tag built-up areas and found that building=yes looks like a good choice
to do that. The source of that teaching of a need to map built-up areas
seems to be non-Openstreetmap cartography courses.

And while we're at it, the next most frequent building tagging mistake:
outlining the building on orbital imagery at roof level instead of base
level... Explaining that pictures are not always taken from the
vertical usually drives the point home.

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

Re: [OSM-talk] Responding to vandalism

[Jean-Marc Liotier]

On Thu, 16 Mar 2017 07:48:10 -0700
Clifford Snow  wrote:
>
> a bot running on slack and IRC that picks up new users from the
> changeset feed. Sure it would be nice of someone could develop
> a similar bot to watch for new users

Use the excellent
http://resultmaps.neis-one.org/newestosmcreatefeed.php and feed the RSS
into whatever you use for notifying.

Users who have invested into a number of Openstreetmap contributions
seldom spend their karma into vandalism, so my experience is that
patrolling contributions by new users catches most deliberate mayhem.

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

Re: [OSM-talk-fr] Durcissement des règles d'Osmose

[Jean-Marc Liotier]

Oups, Frédéric avait déjà répondu hier soir... J'ai répondu avant que
mon client de messagerie ai récupéré son message...

Bref - suivez https://twitter.com/osmose_qa !

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

Re: [OSM-talk-fr] Durcissement des règles d'Osmose

[Jean-Marc Liotier]

On Mon, 13 Mar 2017 17:50:36 +0100
GarenKreiz  wrote:
> 
> Depuis aujourd'hui, Osmose me sort une palanquée de nouveaux
> signalements sur des modifications très anciennes. Il s'agit de l'item
> 1170 classe 4 "Should be polygon, part of multipolygon or not having
> area tag". Pourtant les chemins en question sont bien fermés (cf
> http://www.openstreetmap.org/way/146315318 ).

"My bad. A bug in last update raises hundred of million of non issues.
Code fixed. But have to wait for updates. Most affected item hide"
https://twitter.com/osmose_qa/status/841386036529909762

Translation: une petite erreur déjà corrigée a néanmoins eu le temps de
générer quelques centaines de millions de signalements erronés...

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

Re: [OSM-talk-fr] josm : utiliser une image aérienne

[Jean-Marc Liotier]

On Thu, 16 Feb 2017 09:04:26 +0100
Hélène PETIT  wrote:
>
> je n'ai pas trouvé comment mettre dans un calque de josm une image 
> jpeg, non géoréférencée ; il s'agit du plan d'un tout petit
> lotissement pas encore au cadastre, mais en construction presque
> finie.

Si tu as le moindre doute sur la rectitude de l'image (par exemple s'il
s'agit d'une photo aérienne pas tout à fait verticale ou d'un plan pris
en photo pas tout à fait en face) tu peux la traiter avec 
http://mapwarper.net qui te fournira en sortie non seulement une image
rectifiée mais aussi un WMS de cette dernière, ce qui est plus léger à
manipuler par JOSM qu'une image locale en un seul bloc.

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

Re: [OSM-talk] Quality in rural areas (Was: [Analytics] February 15, 2017 Research Showcase)

[Jean-Marc Liotier]

On Tue, 14 Feb 2017 21:03:32 -0800
Pine W  wrote:
>
> We find that in Wikipedia (as well as > OpenStreetMap), peer-produced
> content about rural areas is of systematically lower quality

Node density, adjusted for population density, 2014:
https://i.imgur.com/hBNEGNT.png (found at
https://news.ycombinator.com/item?id=7958598) - I would love to see
that updated. Variance seems higher in low population area. Would edit
density or tag density be better indicators than node density ?

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

Re: [OSM-talk-fr] Réparer un carnage

[Jean-Marc Liotier]

On Mon, 30 Jan 2017 17:57:46 +0100
Philippe Verdy  wrote:
>
> Une conférence STOM Africa devrait arriver cette année (apparemment
> prévu en Angola, après plusieurs candidatures en Afrique centrale et
> Tunisie), et je pense qu'il serait nécessaire d'y impliquer des
> groupes de formation au moins pour les animateurs de projets qui y
> seront présents, et qu'on a sinon des relais locaux via d'autres
> assos internationales qui ont fait appel à HOT pour la cartographie
> d'urgence.

HOT sait très bien ce qu'on pense de leur (absence d') assurance
qualité. Les outils et les pratiques de l'assurance qualité sont connus
de la plupart des formateurs et organisateurs. Le problème est de
sevrer la communication institutionnelle de HOT & consorts de sa
dépendance à la vantardise quantitative, nettement plus spectaculaire
que la correction d'erreur. Quand leur "task manager" ne permettra pas
de marquer une zone "validée" lorsqu'elle contient plus d'une certaine
quantité de certaines classes d'erreur Osmose, alors on pourra
commencer à croire à une volonté qualitative.

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

Re: [OSM-talk-fr] La jungle de Calais

[Jean-Marc Liotier]

On Fri, 27 Jan 2017 09:53:11 +0100 (CET)
g...@laposte.net wrote:
>
> A mon avis ce serait bien dommage de supprimer, cela a une valeur
> historique

Le Planet complet contient l'intégralité des contributions depuis
l'origine - ont peut donc en extraire l'état d'Openstreetmap à
n'importe quel instant passé. On imagine volontiers un service analogue
à "OSM then & now"
(http://mvexel.github.io/thenandnow/#15/50.9717/1.8951) de Martijn van
Exel avec le choix de deux dates arbitraires... Mais je suppute qu'il
consommerait une quantité déraisonnable de ressources. Quoi qu'il en
soit, la question de la suppression de ce qui n'existe plus ne se pose
pas: Openstreetmap montre ce qui est observable, tout ce qui est
observable et rien que ce qui est observable - et si des
versions anciennes contiennent des données intéressantes à titre
historique, elles ne sont pas perdues.

Ceci dit, même si un jour le site est un jour soigneusement nivelé et
bétonné, il me semble qu'il y a matière à ce que persiste un lieu-dit
"La Jungle" pendant un bon bout de temps.

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

Re: [OSM-talk-fr] BD Ortho en source de changeset

[Jean-Marc Liotier]

On Fri, 27 Jan 2017 08:19:50 +0100
Stéphane Péneau  wrote:
> 
> L'Ign nous avait demandé d'indiquer BD Ortho IGN 2016 sur nos
> changesets lorsqu'on utilisait leurs images aériennes.
> 
> On change en BD Ortho IGN 2017 ?

Pourquoi expliciter la date de la source alors qu'elle est
implicitement celle du changeset ?

Évidemment, pour les objets du changeset dont la source lui est
notablement antérieure - il est nécessaire d'étiqueter l'objet... Mais
dans le cas courante je ne vois pas l'intérêt de le faire.

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

Re: [OSM-talk-fr] autolib

[Jean-Marc Liotier]

On Mon, 23 Jan 2017 20:23:44 +0100
Ralf Treinen  wrote:

> un utilisateur a en masse basculé toutes les stations autolib de
> car_rental en car_sharing [1]. Or, j'avais retenu de la discussion
> en 2014 [2] qu'il s'agit plutot d'un car_rental. Est-ce qu'il y a 
> un changement du l'avis concernant cette question ?

Autolib est bien de la location de voiture (non au sharewashing !) mais
on peut imaginer que des utilisateurs d'Openstreetmap s'interrogent sur
la manière de différencier une borne et ses places d'une agence de
location de voitures "traditionnelle".

Alors, en plus d'amenity=car_rental, car_rental=shop ? automated=yes ?
Juste un début de brainstorm, mais il y a peut-être bien matière à
définir une étiquette discriminant les types d'établissement.

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

Re: [OSM-talk-fr] Centrales électriques

[Jean-Marc Liotier]

On Tue, 17 Jan 2017 03:45:38 +0100
Jérôme Amagat  wrote:
>
> http://perso.numericable.fr/olyon

"Centrales électriques dans le monde d'après" - j'adore !

Bon, ma fenêtre était juste à la bonne taille pour que le
"Openstreetmap.org" passe à la ligne suivante... Un espace insécable
préviendrait peut-être cet incident.

N'empêche, "le monde d'après" ça fait rêver...

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

Re: [OSM-talk] Data Quality

[Jean-Marc Liotier]

On Fri, 30 Dec 2016 18:30:06 -0500
john whelan  wrote:
>
> In HOT in theory new users work is validated.
> In practise its only when a tile is completed
> and even then most tiles aren't checked.

Thank you... I'm sincerly glad you recognize this issue in HOT
contributions: from my window (mostly Senegal and a bit of Mali) I have
a rather dim view of data quality in changesets with a HOT hashtag. I
don't take that upon novice contributors, in part because I don't want
to kill their enthusiasm and in part because they don't know what they
are doing - so I feel that increased emphasis on data quality would be
a most responsible course of action for HOT.

From what I have witnessed, there seems to be a quantitative emphasis
in reporting about HOT projects (kilometers of roads, number of
buildings). While that makes for impressive presentations, it may be a
misleading metric: the usefulness of data may have more to do with its
quality rather than its quantity. Coming from an enterprise background,
I know the difficulty of weaning oneself from the addictiveness of
spectacular metrics, but I also know how much they hurt the bottom line.

I have made quality assurance and the use of quality assurance tools
such as http://osmose.openstreetmap.fr or the JOSM validator a core part
of my message to budding advanced contributors - but of course such
intimidating tools cannot be pushed to novice contributors.
Nevertheless, there is no reason to restrict quality assurance from
those who need it most, though it might require changes in both tools
and processes.

For example, might the validation status of a Tasking Manager tile be
tied to the number of errors in it ? That would require integration of
something like Osmose to the Tasking Manager, with a short validation
delay unlike the daily batch basis of typical Osmose operation... But
that is the sort of change that would make quality assurance a
first-class citizen of HOT contributions.

Also I wonder if, sometimes, it would be wiser to refrain from
collecting data that will certainly have very low quality and
questionable usefulness - buildings come to mind and I feel that using
polygons with landuse tags would often be more cost-effective than them.

In any case, and not just about HOT, I welcome a debate on how to embed
quality assurance in the contribution process of the most novice
contributors.

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

Re: [OSM-talk] Mozambique's living streets

[Jean-Marc Liotier]

Legal definition vs."duck typing" - there is a bit of both in 
Openstreetmap tagging... But because "living street" has a precise legal 
definition in Europe, involved mappers chose not to confuse the issue by 
using a different one.


Then there was the question of differentiating large residential streets 
from minor ones... Some bright spark took initiative by tagging a large 
part of Dakar's residential streets as highway=service - that has been 
universally perceived as a very bad idea.


I mostly just highway=residential with a surface=* tag but now that you 
remind me of those discussion, I'm thinking that a key differentiator is 
the presence of a sidewalk. What about:


highway=residential
surface=ground
sidewalk=no

Doesn't that feel like Africa already ?

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

Re: [OSM-talk] Mozambique's living streets

[Jean-Marc Liotier]

On 12/10/2016 08:47 PM, john whelan wrote:
I just did a search on part of Mozambique and came across more than 
500 highway=living_street.


I always understood them to be a European concept highway with signs 
on the street and a very low max speed.  I wouldn't have expected to 
see so many clustered together in Mozambique.


Idle curiosity are they a legal entity in Mozambique and other parts 
of Africa?


A while ago 
(https://lists.openstreetmap.org/pipermail/talk-fr/2013-August/061580.html) 
I started a thread about usage of highway=living_street in Africa. The 
resulting consensus was that, while unpaved residential streets in 
Africa are living streets in practice, they are not legally classified 
that way - and therefore the correct tagging is highway=residential... 
But participants in the thread were mostly experienced with 
French-speaking Africa - so I cannot rule out the existence of a living 
street legal classification in other locales.


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

[OSM-talk-fr] Laboratoire d'Analyses Médicales

[Jean-Marc Liotier]

Ce n'est pas première fois que je cherche à étiqueter un laboratoire
d'analyses médicales et je ne suis pas le seul à ramer:
http://taginfo.openstreetmap.org/search?q=analyses+m%C3%A9dicales#values
- le moins qu'on puisse dire est que la standardisation est encore
loin... 
name=Laboratoire d'Analyses Médicales est à peu près la seule constante.


Parmi la grande variété d'étiquetages pratiqués là où il semble qu'on a
affaire à un laboratoire d'analyses médicales, j'ai noté celles qui me
paraissent offrir le meilleur potentiel 

amenity=medical_lab : très rare et apparemment plutôt Montpelliérain
(http://taginfo.openstreetmap.org/tags/amenity=medical_lab#overview). A
mon avis, il a contre lui de ne pas s'inscrire dans le fourre-tout
"amenity" plutôt qu'un espace de nommage médical. Dommage: il a pour lui
la simplicité. 

health_facility:type=laboratory est un petit peu plus répandu et il est
mentionné par la proposition Healthcare 2.0
(https://wiki.openstreetmap.org/wiki/Proposed_features/Healthcare_2.0/Examples#Medical_laboratory)
[1]. Je me demande pourquoi health_facility:type=laboratory alors que
health_facility=laboratory aurait parfaitement fonctionné. Quoiqu'il en
soit, même si je n'aime pas le ":type" superflu, combiné à un
amenity=doctors ou à un office=medical il me semble adapté. Je l'ai vu
combiné avec office=medical_laboratory mais ça me semble redondant et
j'aime bien l'idée de se raccrocher à une étiquette répandue telle que
amenity=doctors ou office=medical. Réflexion faire, amenity=doctors est
préférable car le laboratoire d'analyse médicales tel que nous le
connaissons repose sur la direction d'au moins un docteur en médecine. 

amenity=doctors + healthcare:speciality=laboratory : rarissime (deux
occurrences...) mais intéressant, notamment parce qu'il s'insère dans
des pratiques existantes
(http://taginfo.openstreetmap.org/keys/healthcare%3Aspeciality#values)
[2] par exemple healthcare:speciality=radiology dont les 220 occurrences
se combinent généralement avec amenity=doctors. 

healthcare=laboratory : 70 ocurrences
(http://taginfo.openstreetmap.org/tags/healthcare=laboratory#overview).
[3]Serait acceptable, combiné à amenity=doctors. 

Bon, il me semble au moins plutôt évident que amenity=doctors s'impose
comme étiquette principale. Reste à déterminer l'étiquette secondaire...
Les candidats présentables me semblent être: 

healthcare=laboratory 

healthcare:speciality=laboratory 

health_facility:type=laboratory 

Qu'en pensez vous ? 

Bon, j'aurais du écrire ceci en langue Angloise pour poster sur
tagging@osm mais comme j'étais parti de "Laboratoire d'Analyses
Médicales" j'ai continué sur ma lancée... Donc une discussion en
Français pour une fois...

  

Links:
--
[1]
https://wiki.openstreetmap.org/wiki/Proposed_features/Healthcare_2.0/Examples#Medical_laboratory
[2] http://taginfo.openstreetmap.org/keys/healthcare%3Aspeciality#values
[3] http://taginfo.openstreetmap.org/tags/healthcare=laboratory#overview___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk] (Warning) Check Email For Your Name

[Jean-Marc Liotier]

On 07/05/2016 08:48 AM, Hans De Kryger wrote:


you're the owner of any of these email accounts, your account may have 
been compromised.


I came across suspicions emails that were "supposedly" from these 
email accounts.



https://en.wikipedia.org/wiki/Joe_job

"A joe job is a spamming technique that sends out unsolicited e-mails 
using spoofed sender data. Early joe jobs aimed at tarnishing the 
reputation of the apparent sender or inducing the recipients to take 
action against them (see also e-mail spoofing), but they are now 
typically used by commercial spammers to conceal the true origin of 
their messages"


Most probably spammers who have been harvesting mailing lists in bulk.

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

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

[Jean-Marc Liotier]

On 06/29/2016 09:38 PM, sly (sylvain letuffe) wrote:

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

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


Hier après-midi le retard de réplication est reparti à la hausse... Un 
incident ?


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


Sinon, en temps normal, quel est le goulet d'étranglement de la 
réplication ?



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

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

[Jean-Marc Liotier]

On 2016-06-26 15:57, sly (sylvain letuffe) wrote:

> je relance l'import avec les options meta.

Ca concerne aussi https://api.openstreetmap.fr/api ? Il m'avais semblé
que ce service avait un problème analogue à la même période et
maintenant ses données datent apparemment de peu après que tu ais
relancé l'import ? Elles ne sont plus rafraîchies ?___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Pourquoi railway aurait un privilège ?

[Jean-Marc Liotier]

On 05/07/2016 11:16 AM, David Crochet wrote:

Le 07/05/2016 11:05, Jérôme Seigneuret a écrit :

*railway=destroyed* plus de voie mais il y a eu une


Et quand il n'y a rien de rien, que même sous les pavés et le goudron 
on retrouve probablement directement la terre, pas un rail, pas un 
traverse, (ou peut être  une vis ou un morceau de bois), keutchi, 
nada, rien.


... Mais sur le terrain on distingue clairement une emprise ferroviaire 
avec son cheminement à niveau - et on peut donc l'enregistrer dans 
Openstreetmap.


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

Re: [OSM-talk-fr] Intégration de données issues de Voies Navigables de France

[Jean-Marc Liotier]

On 2016-05-02 15:45, Romain MEHUT wrote:

> Le contributeur http://www.openstreetmap.org/user/malcolmh intègre depuis peu 
> des données liées à la navigation fluviale. Je lui ai demandé quelle était sa 
> source. Il m'a répondu "The data was extracted from 
> http://www.vnf.fr/ecdis/data/Moselle.zip"En lisant cette page 
> http://www.vnf.fr/ecdis/ je doute que cela soit compatible avec la licence 
> ODbL.

Un administrateur pour supprimer ce post des archives de la mailing list
? Il est en infraction avec les conditions d'utilisation sus-mentionnées
: "Toute création d'un lien hypertexte d'un site internet vers le site
de VNF devra faire l'objet d'une autorisation expresse de Voies
navigables de France" - et ma réponse aussi du même coup... 

Plus sérieusement, VNF s'y réserve explicitement tous les droits
concernant toutes données publiées... C'est on ne peut plus clair. 
  ___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] R25, Maperitive et orientation d'objets

[Jean-Marc Liotier]

On 25/04/2016 00:46, Philippe Verdy wrote:
Si on veut faire une carte ayant ces types d'ajustements spécifiques, 
il faut une base de données complémentaire, spécifique au rendu à 
faire, hors OSM (c'est ce que fait MapQuest pour placer plus 
judicieusement certains libellés importants ou les sélectionner selon 
des critères qu'ils considèrent plus pertinents, notamment pour les 
faibles niveaux de zoom, afin de les placer en priorité avant tout le 
reste issu d'OSM et qui sera placé de façon automatisée s'il reste de 
la place).


Intéressante cette manière de maintenir les ajustements spécifiques... 
C'est mieux que le post-traitement manuel à chaque nouvelle publication 
- j'imagine une table avec des identifiants d'objets OSM et pour chacun 
d'entre eux une orientation et une position... Il y a de la 
documentation publique décrivant l'outillage de Mapquest ?



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