Re: [OSM-talk-fr] Chantiers d'été pour OSM-FR ;)

[Gad Jo]

Super Christian

Voici quelques retours

Selon leur orientation Le rendu des escaliers est étrange 
https://umap.openstreetmap.fr/fr/map/rendu-fr-en-developpement_483858#20/43.18428/3.00210

Le rendu des bâtit apparaît comme un gros monobloc. Il devient impossible de 
différencier les monuments, administration et tout autres bâti qui n'est pas 
une habitation 
https://umap.openstreetmap.fr/fr/map/rendu-fr-en-developpement_483858#19/43.18426/3.00377

Le nom Les Halles apparaît deux fois 
https://umap.openstreetmap.fr/fr/map/rendu-fr-en-developpement_483858#19/43.18133/3.00509

Facultatif : les caméras de surveillance n'apparaissent pas. À tester si ça 
'alourdi pas le rendu

Plus difficile La référence des route apparaît autant de fois qu'il y a de 
section entre giratoire comme sur le contournement D 6009a. Je sais que c'est 
très complexe mais l'afficher une seule fois ET dans l'axe de la voie serait 
parfait surtout pour la D 68 
https://umap.openstreetmap.fr/fr/map/rendu-fr-en-developpement_483858#13/43.1929/3.0236
Parfois c'est affiché de multiples fois et sur une grande section il n'y a plus 
d'information comme pour la D 6009 côté ouest et nord 
https://umap.openstreetmap.fr/fr/map/rendu-fr-en-developpement_483858#13/43.1922/2.9816



Le August 10, 2020 8:32:08 PM UTC, osm.sanspourr...@spamgourmet.com a écrit :
>Tu veux supprimer la crête et les autres îles.
>
>Avec le réchauffement climatique ça va se réparer tout seul :-(.
>
>Le 10/08/2020 à 18:48, Adrien via Talk-fr - talk-fr@openstreetmap.org a
>écrit :
>> Autre léger bug : la mer de Kara, au nord de la Russie, apparait,
>> disparait, puis réapparait en zoomant. Voici sa disparition :
>>
>>
>https://umap.openstreetmap.fr/fr/map/rendu-fr-en-developpement_483858#3/60.54/59.94
>>
>> Adrien
>>
>> Le 10/08/2020 à 18:41, Adrien a écrit :
>>> Bonjour,
>>>
>>> Merci pour ce rendu !!
>>>
>>> Par contre, la Méditerranée bien tard : à ce zoom, le Golfe du Lion
>ou
>>> la mer d'Alboran apparaissent bien, mais il faut zoomer encore pour
>>> avoir le nom « Méditerranée » :
>>>
>>>
>https://umap.openstreetmap.fr/fr/map/rendu-fr-en-developpement_483858#4/44.68/11.16
>>>
>>> Bonne journée
>>>
>>> Adrien
>>>
>>> Le 09/08/2020 à 23:18, Christian Quest a écrit :
 Le 05/08/2020 à 19:42, Jérôme Amagat a écrit :
>>> Les mers, baies et détroits (place=sea, natural=bay,
>>> natural=strait) en surfacique pourraient avoir leur nom qui
>>> apparaissent pour les mer et détroit et plus tôt lorsqu'ils sont
>>> très grands pour les baies qui sont déjà rendu.
>>> exemple : le golfe du lion
>>> https://www.openstreetmap.org/relation/9287303
>>>
>http://tile.openstreetmap.fr/?zoom=11=42.99137=4.17341=B
>>>
 Voilà les océans, mers, baies, détroits maintenant visibles sur le
 rendu FR :)

 L'occasion de découvrir le tag sqkm=* qui indique sur un objet
 ponctuel sa superficie approximative en km².

 Ceci permet de prioriser ces objets et c'est bien pratique !

 Tag documenté sur le wiki en 2016.


 Vous pouvez voir ce que ça donne (avec les améliorations
>précédentes)
 sur:


>https://umap.openstreetmap.fr/fr/map/rendu-fr-en-developpement_483858#2/0/0


 C'est un accès direct au rendu en cours de dev (chez moi, pas dispo
 H24 et recalculs non continus).


 L'occasion d'améliorer quelques name:fr !

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

-- 
Envoyé de mon appareil Android avec K-9 Mail. Veuillez excuser ma brièveté.___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-GB] OSMUK Instagram ideas

[Mateusz Konieczny via Talk-GB]

Maybe something showing how 
editing actually happens?

Either as short movie, animated gif
or as combination of some photos
in one image?
10 Aug 2020, 16:38 by jez.nichol...@gmail.com:

> Thanks for the ideas.
>
> Today's post is about Missing Maps London on Tues 1 September > 
> https://www.instagram.com/p/CDtkiAFH-sS/>  which I attended last week. I've 
> been going to see what goes on. Gave me a chance to try out the new RapiD 
> editor.
>
> I forgot to say that I want to be able to post once-a-day.
>
> I haven't considered replicating somewhere 'open' yet. Insta has a big reach, 
> but I see that Pixelfed is a similar concept.
>
>
> On Sun, Aug 9, 2020 at 2:42 PM Robert Skedgell <> r...@hubris.org.uk> > wrote:
>
>> On 09/08/2020 14:31, Jez Nicholson wrote:
>>  > I've been posting to the OSMUK
>>  > Instagram >> https://www.instagram.com/openstreetmapuk/>>  account 
>> recently.
>>  > We are currently focusing on potential new mappers, so i'm thinking
>>  > quirky and topical.
>>  > 
>>  > So,
>>  > 
>>  > a) Do you know of an interesting looking feature in the UK?
>>  > 
>>  > b) Do you know of something topical (and visual)?
>>  > 
>>  > c) After this thread has finished, how best could/would you get in
>>  > contact to tell me? Twitter? A thread on Loomio? Here?
>>  > 
>>  > Regards,
>>  >               Jez
>>  > 
>>  
>>  Some of the COVID-19 related highway changes, e.g. modal filters
>>  implemented with planters might be worth including. There's an obvious
>>  visual and routing impact in real life, as rendered by OSM Carto and for
>>  routing engines.
>>  
>>  -- 
>>  Robert Skedgell (rskedgell)
>>  
>>  
>>  ___
>>  Talk-GB mailing list
>>  >> Talk-GB@openstreetmap.org
>>  >> https://lists.openstreetmap.org/listinfo/talk-gb
>>___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [OSM-talk-fr] Chantiers d'été pour OSM-FR ;)

[osm . sanspourriel]

Tu veux supprimer la crête et les autres îles.

Avec le réchauffement climatique ça va se réparer tout seul :-(.

Le 10/08/2020 à 18:48, Adrien via Talk-fr - talk-fr@openstreetmap.org a
écrit :

Autre léger bug : la mer de Kara, au nord de la Russie, apparait,
disparait, puis réapparait en zoomant. Voici sa disparition :

https://umap.openstreetmap.fr/fr/map/rendu-fr-en-developpement_483858#3/60.54/59.94

Adrien

Le 10/08/2020 à 18:41, Adrien a écrit :

Bonjour,

Merci pour ce rendu !!

Par contre, la Méditerranée bien tard : à ce zoom, le Golfe du Lion ou
la mer d'Alboran apparaissent bien, mais il faut zoomer encore pour
avoir le nom « Méditerranée » :

https://umap.openstreetmap.fr/fr/map/rendu-fr-en-developpement_483858#4/44.68/11.16

Bonne journée

Adrien

Le 09/08/2020 à 23:18, Christian Quest a écrit :

Le 05/08/2020 à 19:42, Jérôme Amagat a écrit :

Les mers, baies et détroits (place=sea, natural=bay,
natural=strait) en surfacique pourraient avoir leur nom qui
apparaissent pour les mer et détroit et plus tôt lorsqu'ils sont
très grands pour les baies qui sont déjà rendu.
exemple : le golfe du lion
https://www.openstreetmap.org/relation/9287303
http://tile.openstreetmap.fr/?zoom=11=42.99137=4.17341=B


Voilà les océans, mers, baies, détroits maintenant visibles sur le
rendu FR :)

L'occasion de découvrir le tag sqkm=* qui indique sur un objet
ponctuel sa superficie approximative en km².

Ceci permet de prioriser ces objets et c'est bien pratique !

Tag documenté sur le wiki en 2016.


Vous pouvez voir ce que ça donne (avec les améliorations précédentes)
sur:

https://umap.openstreetmap.fr/fr/map/rendu-fr-en-developpement_483858#2/0/0


C'est un accès direct au rendu en cours de dev (chez moi, pas dispo
H24 et recalculs non continus).


L'occasion d'améliorer quelques name:fr !


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



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

[Talk-bf] Aidez à résoudre les problèmes routiers en Burkina Faso avec MapRoulette / Help fix road problems in Burkina Faso with MapRoulette

[Andrew Wiseman via Talk-bf]

Bonjour à tous,

Voici Andrew de l'équipe Apple Maps. Nous avons récemment utilisé notre outil 
d'analyse de données Atlas (https://github.com/osmlab/atlas 
) pour examiner quelques types de problèmes 
potentiels liés aux routes et au routage en Burkina Faso.

J'ai publié les résultats de ces contrôles sur MapRoulette, un outil qui vous 
permet de passer en revue les problèmes potentiels un par un et de les corriger 
ou d'indiquer qu'ils ne sont pas un problème. Je voulais vous faire savoir 
qu'ils sont disponibles au cas où d'autres voudraient essayer de réparer 
certains d'entre eux - je prévois également de les parcourir moi-même. 

Tous les défis sont dans ce projet, y compris des choses comme des routes qui 
se chevauchent, des routes qui ne sont pas connectées à d'autres routes, des 
routes qui traversent sans connexion et des problèmes similaires. 
https://maproulette.org/browse/projects/40660 

Dans MapRoulette, vous pouvez choisir une tâche aléatoire à corriger ou cliquer 
sur une tâche spécifique. Si vous souhaitez effectuer des tâches autour d'un 
certain emplacement, par exemple dans un endroit que vous connaissez, vous 
pouvez cliquer sur l'une d'elles dans la vue Carte, puis sur Tâche suivante: à 
proximité lorsque vous l'avez terminée.

Merci!
Andrew

///

Hello all,

This is Andrew from the Apple Maps team. We recently used our Atlas data 
analysis tool (https://github.com/osmlab/atlas 
) to look at a few types of potential issues 
related to roads and routing in Burkina Faso.

I've posted the results of those checks on MapRoulette, a tool that lets you go 
through potential issues one by one and either correct them or indicate they 
are not a problem. I wanted to let you know they are available in case others 
wanted to try fixing some of them — I also plan to go through some of them 
myself. 

All the challenges are in this project, including things like overlapping 
roads, roads that aren't connected to other roads, roads that cross without a 
connection, and similar issues. https://maproulette.org/browse/projects/40660

In MapRoulette you can either pick a random task to fix or click on a specific 
one. If you want to do tasks around a certain location, such as somewhere you 
are familiar with, you can click on one from the map view, and then click Next 
task: Nearby when you finish it.

Thanks!
Andrew



Andrew Wiseman |  Maps | iPhone: +1.202.270.4464 | andrew_wise...@apple.com 

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

Re: [OSM-talk-fr] Facebook achète Mapillary !

[Georges Dutreix via Talk-fr]

Ai-je tort de penser qu'il n'existe pas encore de moyen simple de récupérer les 
images stockées chez openStreetCam ?
J'aimerais bien les récupérer pour assurer leur futur 

10 août 2020 21:59:21 Gad Jo :

> Manque plus que le transferts OSC vers Mapillary pour que je passe à la 
> capture avec l'application OSC.
> 
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Chantiers d'été pour OSM-FR ;)

[Jérôme Amagat]

Le dim. 9 août 2020 à 23:18, Christian Quest  a
écrit :

> Le 05/08/2020 à 19:42, Jérôme Amagat a écrit :
> >>>
> >>> Les mers, baies et détroits (place=sea, natural=bay, natural=strait)
> >>> en surfacique pourraient avoir leur nom qui apparaissent pour les
> >>> mer et détroit et plus tôt lorsqu'ils sont très grands pour les
> >>> baies qui sont déjà rendu.
> >>> exemple : le golfe du lion
> >>> https://www.openstreetmap.org/relation/9287303
> >>>
> http://tile.openstreetmap.fr/?zoom=11=42.99137=4.17341=B
> >>>
> >>
>
> Voilà les océans, mers, baies, détroits maintenant visibles sur le rendu
> FR :)
>
>
> Très jolies toutes ces améliorations !
Par contre les grands lacs ont disparu à faible zoom
https://umap.openstreetmap.fr/fr/map/rendu-fr-en-developpement_483858#6/42.383/-80.607

Dans les zones où la forêt est decoupé en carré, il y a un effet
"quadrillage" pas très beau
https://umap.openstreetmap.fr/fr/map/rendu-fr-en-developpement_483858#9/-0.0316/-68.0836
Il y a aussi les aérodromes qui ne sont pas rendu aeroway=aerodrome
Les frontières qui n'apparaissent pas si elle n'ont pas de tag
boundary=administrative

Il y a un problème, non lié au rendu avec des landuse=landfill au nord de
la Russie. Des déchets nucléaires immergés ne font pas de la zone une
décharge...

Moi ça ne me gêne pas tous ces noms de villes et villages, (sauf en chine ,
trop de noms et de points noirs car trop de villes très peuplées, avec des
noms en anglais un peu plus long, il y en aura un peu moins). Par contre
les hameaux et quartiers, je les trouvent écrit trop petit, difficiles à
lire.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Facebook achète Mapillary !

[Gad Jo]

Depuis plusieurs semaine j'utilise un script permettant de faire une copie chez 
openstreetcam sans passer par ma connexion ADSL : 
https://osm.svimik.com/photosync/
Manque plus que le transferts OSC vers Mapillary pour que je passe à la capture 
avec l'application OSC.

D'un je n'ai pas les moyens physique et technique pour les stocker (Merci 
Christian pour ta proposition de backup) puis les redéployer ailleurs (pas de 
fibre).
Quitte à les récupérer autant que ça alimente un service déjà fonctionnel

Christian je reste intéressé par ta proposition de backup mais j'ai préféré le 
faire ailleurs pour que ça profite au plus grand nombre... Et l'espace n'étant 
pas extensible je préfère économiser les ressources fournies par un particulier 
pour solliciter de manière plus intensive celle d'une entreprise. Dès qu'un 
usage applicatif sera mise en place je serai de la partie.

Faite un essai sur https://osm.svimik.com/photosync/ pour vous faire une idée

Le August 10, 2020 9:08:52 AM UTC, Christian Quest  a 
écrit :
>Le 10/08/2020 à 10:31, Axel Listes a écrit :
>> Bonjour,
>>
>> Le 19/06/2020 à 12:25, Laurence P a écrit :
>>> Mapillary était un service très pratique, mais il n'est pas
>>> indispensable. Lors que j'ai effectué mes premières prises de vue,
>cela
>>> me posait déjà un cas de conscience : est ce que le monde doit être
>>> photographié sous ses moindre coutures ? / Stocker toutes ces photos
>>> c'est pas écolo / Aider une société qui va aider au développement
>des
>>> véhicules autonomes est-ce bien raisonnable ? ...
>> Pour les mêmes raisons, je voudrais moi aussi supprimer toutes mes
>> photos téléversées ces dernières années sur Mapillary.
>
>
>Tu as accepté de mettre ces photos sous licence CC, c'est irrévocable
>
>Il serait bon de ne pas perdre de vue les principes des licences libre.
>
>Demander à Mapillary de les supprimer, revient à les rendre 
>indisponibles pour tous, sauf pour eux (because licence irrévocable). 
>C'est donc contre-productif.
>
>
>> J'ai anticipé en les téléversant sur OpenStreetCam, que j'avais déjà
>> utilisé parallèlement au débit puis abandonné, car la plateforme
>> générait des erreurs.
>>
>> Aujourd'hui, je voudrais remplacer des sources mapillary=* par
>> OpenStreetCam dans la base de données OSM. Mais je ne trouve pas de
>doc
>> à ce sujet, j'ignore si les liens et références que donne OSC sont
>> pérennes ?
>>
>> Certain·e·s ont déjà réalisé des recherches à ce sujet ?
>>
>> https://wiki.openstreetmap.org/wiki/FR:Key:mapillary
>>
>> Axel.
>
>
>Tu peux récupérer tes photos en plein définition chez mapillary.
>
>Nous avons mis en place un petit service qui s'occupe de ça et en 
>conserve donc une copie d'archive.
>
>C'est ici (et il reste quelques To): 
>https://takeitout.cquest.org/mapillary_takeout
>
>Le problème étant surtoutqu'on n'est pas à l'abri d'un changement de 
>politique de Mapillary sur l'accès libre aux photos déposées depuis des
>
>années, c'est l'intérêt d'avoir une archive. OpenStreetCam n'est pas 
>plus fiable (racheté aussi par une société pas très culture OSM).
>
>
>Pour les tags, on a justement une discussion à ce sujet en ce moment en
>
>lien avec les DAE.
>
>Faudrait-il archiver les photos qui sont derrière les tags image=* ou 
>mapillary=* ?
>
>
>-- 
>Christian Quest - OpenStreetMap France
>
>
>___
>Talk-fr mailing list
>Talk-fr@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/talk-fr

-- 
Envoyé de mon appareil Android avec K-9 Mail. Veuillez excuser ma brièveté.___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Chantiers d'été pour OSM-FR ;)

[osm . sanspourriel]

Bonjour les remarques de Donat et de Philippe ne sont pas
contradictoires avec cet effort d'afficher les place plus correctement.

Là typiquement une modif ici pour vérifier que ça se passe bien puis un
CR/PR sur le style par défaut ça me va^^.

Le 10/08/2020 à 18:32, Christian Quest - cqu...@openstreetmap.fr a écrit :

depuis qu'on a retiré le population=* sur les noeuds place il n'est
plus possible de les prioriser et donc ça affiche des noms souvent peu
pertinents.


Tu veux dire que la priorisation par capital puis place suffit pas ?

Soit.

Mais lors de l'import tu ne peux faire "dégouliner" les populations des
relations administratives l'ayant en admin_centre pour les nœuds n'ayant
pas de capital en faisant attention de maximiser les valeurs.

Par exemple Vannes  (53352 hab) est une commune qui joue le rôle de
préfecture (capital=6). Tiens elle a gardé sa population.  Et a un
political_division !

M.. ,le Morbihan n'a pas de données de population agglomérée.

Donc tu récupères la population de Vannes. C'est déjà pas mal. Pareil
pour toutes les communes.

Et les place= sans données de population sont donc à afficher
(éventuellement) après s'il reste de la place.

Pour éviter de surcharger la carte on peut exiger un espace laissé libre
autour du texte. Ça devrait contenter un peu tout le monde (en zone
désertique comme peuplée).


En fait on n'a fait que supprimer les ref:INSEE sur les nœuds.

Et du coup on a laissé les populations de 2009, 2013... !

Pour les mers disparaissant : c'est une carte de terrien qui cache la
Méditerranée par la Crête ;-). Il n'y a pas possibilité de chercher une
place où mettre le texte dans le polygone ?

Pour les évolutions OSM FR, je rappelle que l'estran est mieux géré que
l'actuel désert sauf plages d'OSM canal défaut.

Jean-Yvon



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

Re: [OSM-talk-fr] Chantiers d'été pour OSM-FR ;)

[Adrien via Talk-fr]

Bonjour,

Merci pour ce rendu !!

Par contre, la Méditerranée bien tard : à ce zoom, le Golfe du Lion ou
la mer d'Alboran apparaissent bien, mais il faut zoomer encore pour
avoir le nom « Méditerranée » :

https://umap.openstreetmap.fr/fr/map/rendu-fr-en-developpement_483858#4/44.68/11.16

Bonne journée

Adrien

Le 09/08/2020 à 23:18, Christian Quest a écrit :
> Le 05/08/2020 à 19:42, Jérôme Amagat a écrit :

 Les mers, baies et détroits (place=sea, natural=bay,
 natural=strait) en surfacique pourraient avoir leur nom qui
 apparaissent pour les mer et détroit et plus tôt lorsqu'ils sont
 très grands pour les baies qui sont déjà rendu.
 exemple : le golfe du lion
 https://www.openstreetmap.org/relation/9287303
 http://tile.openstreetmap.fr/?zoom=11=42.99137=4.17341=B

>>>
>
> Voilà les océans, mers, baies, détroits maintenant visibles sur le
> rendu FR :)
>
> L'occasion de découvrir le tag sqkm=* qui indique sur un objet
> ponctuel sa superficie approximative en km².
>
> Ceci permet de prioriser ces objets et c'est bien pratique !
>
> Tag documenté sur le wiki en 2016.
>
>
> Vous pouvez voir ce que ça donne (avec les améliorations précédentes)
> sur:
>
> https://umap.openstreetmap.fr/fr/map/rendu-fr-en-developpement_483858#2/0/0
>
>
> C'est un accès direct au rendu en cours de dev (chez moi, pas dispo
> H24 et recalculs non continus).
>
>
> L'occasion d'améliorer quelques name:fr !
>

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

Re: [OSM-talk-fr] Whodidit ne fonctionne plus

[pepilepi...@ovh.fr]

Le 10/08/2020 à 16:35, Yves P. a écrit :
>> Whodidit est un outil qui permet de suivre les modifications des
>> utilisateurs Openstreetmap sur l'emprise géographique de son choix. 
> Il me semble que OSMcha permet de faire exactement ça.
> As-tu essayé ?
>
Y'a un mode d'emploi de cet OSMcha ? Parce que
https://wiki.openstreetmap.org/wiki/OSMCha est un peu... succint !
Notamment la possibilité comme sur whodidit de faire une recherche sur
une zone.

Merci, bonne soirée

Jean-Pierre


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


-- 


Si ma réponse n'a pas résolu ton problème, c'est que tu n'as pas posé la
bonne question.

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

Re: [OSM-talk-fr] Chantiers d'été pour OSM-FR ;)

[Adrien via Talk-fr]

Autre léger bug : la mer de Kara, au nord de la Russie, apparait,
disparait, puis réapparait en zoomant. Voici sa disparition :

https://umap.openstreetmap.fr/fr/map/rendu-fr-en-developpement_483858#3/60.54/59.94

Adrien

Le 10/08/2020 à 18:41, Adrien a écrit :
> Bonjour,
>
> Merci pour ce rendu !!
>
> Par contre, la Méditerranée bien tard : à ce zoom, le Golfe du Lion ou
> la mer d'Alboran apparaissent bien, mais il faut zoomer encore pour
> avoir le nom « Méditerranée » :
>
> https://umap.openstreetmap.fr/fr/map/rendu-fr-en-developpement_483858#4/44.68/11.16
>
> Bonne journée
>
> Adrien
>
> Le 09/08/2020 à 23:18, Christian Quest a écrit :
>> Le 05/08/2020 à 19:42, Jérôme Amagat a écrit :
> Les mers, baies et détroits (place=sea, natural=bay,
> natural=strait) en surfacique pourraient avoir leur nom qui
> apparaissent pour les mer et détroit et plus tôt lorsqu'ils sont
> très grands pour les baies qui sont déjà rendu.
> exemple : le golfe du lion
> https://www.openstreetmap.org/relation/9287303
> http://tile.openstreetmap.fr/?zoom=11=42.99137=4.17341=B
>
>> Voilà les océans, mers, baies, détroits maintenant visibles sur le
>> rendu FR :)
>>
>> L'occasion de découvrir le tag sqkm=* qui indique sur un objet
>> ponctuel sa superficie approximative en km².
>>
>> Ceci permet de prioriser ces objets et c'est bien pratique !
>>
>> Tag documenté sur le wiki en 2016.
>>
>>
>> Vous pouvez voir ce que ça donne (avec les améliorations précédentes)
>> sur:
>>
>> https://umap.openstreetmap.fr/fr/map/rendu-fr-en-developpement_483858#2/0/0
>>
>>
>> C'est un accès direct au rendu en cours de dev (chez moi, pas dispo
>> H24 et recalculs non continus).
>>
>>
>> L'occasion d'améliorer quelques name:fr !
>>

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

Re: [OSM-talk-fr] Chantiers d'été pour OSM-FR ;)

[Yves P.]

>
>  surtout que depuis
> qu'on a retiré le population=* sur les noeuds place il n'est plus
> possible de les prioriser

Wikidata devrait te donner ça :)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk] This needs to be voted upon. (was: Re: Separating all metadata from coordinates in OSM into a wikibase instance)

[Paul Johnson]

On Mon, Aug 10, 2020 at 1:03 AM Mateusz Konieczny via talk <
talk@openstreetmap.org> wrote:

> Before going to vote it would need to demonstrate some sort of clear
> benefit and
> consensus that it is reasonable.
>

For this, as well as my take on this
, is why I'm
also a hard no on this.  This is a solution looking for a problem that will
only create a bigger series of problems.  We already have bigger problems,
like making lanes=* actually pass on the ground verifiability in situations
where there's bicycle or motorcycle lanes.  Or killing ref=* on ways as a
method of describing road routes in favor of relations.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[Talk-de] Einladung OSMF-Stammtisch via Mumble am 13.08.

[Hanna Krüger]

Hallo zusammen,

der nächste OSMF-Stammtisch wird am Donnerstag, den 13.08. um 20:00 Uhr 
stattfinden. 
Sammelt eure Themenwünsche gerne im folgenden Pad: 
https://pads.ccc.de/M4a8gZ5Q5N
Der Link zum Mumble-Server ist wie üblich: podcast.openstreetmap.de

Ich freue mich auf euch.

Liebe Grüße
Hanna
 




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

Re: [OSM-talk-fr] Chantiers d'été pour OSM-FR ;)

[Christian Quest]

Le 10/08/2020 à 17:25, Donat ROBAUX a écrit :

Hello,

Pour une fois, je vais être d'accord avec Philippe ;)
Ce qui me pose le plus de pb ce sont les niveaux 8 à 10: trop d'infos, 
trop de contastre, on s'y perd un peu.
Je redonnerai un peu de lisibilité en mettant en avant les limites de 
départements et en limitant le nb de communes affichées, tout ca 
faisant qu'on ne ne sait plus trop où on est.
Je pense que la quasi totalité des communes ne doivent pas 
apparaître avant le Z11. Entre les 2 se limiter au chef-lieu de canton 
par exemple.

Sinon sur les Z8 à 11, diminuer le contraste du vert qui embolise tout.
J'imagine que si on arrive à faire déjà ca, ca devrait redonner un peu 
d'air à la carte.


Donat et mon avis de sémiologiste graphique à mes heures perdues



Les seuls chef-lieu de canton, ça va faire bien vide, mais je vais 
alléger les noms de communes qui sont trop denses, surtout que depuis 
qu'on a retiré le population=* sur les noeuds place il n'est plus 
possible de les prioriser et donc ça affiche des noms souvent peu 
pertinents.


Je compte revoir ça en reprenant les polygones liées aux boundary, mais 
en mettant moins de noms.


Cette règle de "remplissage" est aussi fort utile pour des zones très 
peu peuplées hors de France.


Exemple: 
https://mc.bbbike.org/mc/?lon=45.93171=24.068153=8=2=mapnik=osmfr



--
Christian Quest - OpenStreetMap France


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

Re: [OSM-talk-fr] Whodidit ne fonctionne plus

[Yves P.]

>
> Plus pratique Whodidit finalement

Je l'ai essayé pour retrouver des objets osm effacés, mais sans résultat.

Je n'ai pas retrouvé la procédure.
Vous la connaissez ?

, il me semble pourtant avoir bien
> configuré mon filtre OSMCha, mais apparaissent dans le listing des
> modifications des changements qui n'ont rien à voir avec la BBOX que
> j'ai sélectionné.
>

Osmcha sélectionne aussi les cs qui englobent ta zone de sélection.
Mais si les objets sont en dehors, tu n'a rien à observer.
Il devrait vérifier qu'il y a au moins un objet modifié dans ta zone de
surveillance.

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

Re: [OSM-talk-fr] Chantiers d'été pour OSM-FR ;)

[Donat ROBAUX]

Hello,

Pour une fois, je vais être d'accord avec Philippe ;)
Ce qui me pose le plus de pb ce sont les niveaux 8 à 10: trop d'infos, trop
de contastre, on s'y perd un peu.
Je redonnerai un peu de lisibilité en mettant en avant les limites de
départements et en limitant le nb de communes affichées, tout ca faisant
qu'on ne ne sait plus trop où on est.
Je pense que la quasi totalité des communes ne doivent pas apparaître avant
le Z11. Entre les 2 se limiter au chef-lieu de canton par exemple.
Sinon sur les Z8 à 11, diminuer le contraste du vert qui embolise tout.
J'imagine que si on arrive à faire déjà ca, ca devrait redonner un peu
d'air à la carte.

Donat et mon avis de sémiologiste graphique à mes heures perdues


>
> -- Forwarded message --
> From: Philippe Verdy 
> To: "Discussions sur OSM en français" 
> Cc:
> Bcc:
> Date: Mon, 10 Aug 2020 13:23:34 +0200
> Subject: Re: [OSM-talk-fr]  Chantiers d'été pour OSM-FR ;)
> Le modèle de couleurs est aussi à revoir: il est beaucoup top contrasté
> (surtout à faible niveau de zoom), et aujourd'hui je préfère la solution
> adoptée par le rendu Carto OSM.org qui réduit ce contraste à mesure qu'on
> dézoome, ce qui donne une carte bien plus lisible.
>
> Le rendu OSM.fr est aujourd'hui beaucoup trop "patchwork", très peu
> lisible et exploitable. Il a été bon et mailleurs que l'ancien rendu
> OSM.org mais est aujourd'hui dépassé (AMHA): ce qui compte c'est plus la
> quantité importante de données détaillées qu'on peut y trouver (surtout au
> niveau des points individuels avec les libellés et icônes) mais les
> textures et couleurs de remplissage sont à revoir pour plus de discrétion:
> plus les zones sont petites, moins on doit y voir du contraste. Ce rendu
> OSM.fr manque d'accessibilité et lisibilité, et plus en essayé
> d'ajouter des détails locaux, moins ces détails sont identifiables car le
> fond les rend difficilement lisibles (et cela réduit fortement la
> réutilisation).
>
> Je vois plus le rendu OSM.fr comme une démo qui a permis de montrer les
> faiblesses de l'ancien rendu CartoOSM.org, mais aujourd'hui il s'est
> largement amlélioré et a retenu le meilleur des différentes options
> proposées dans différents rendus.
>
> Peut-on revoir ça (c'est surtout du nettoyage à refaire sur les feuilles
> de style, indépendamment de ce qu'on veut afficher).
>
>
> Le lun. 10 août 2020 à 09:31, Jacques Lavignotte 
> a écrit :
>
>>
>>
>> Le 09/08/2020 à 23:18, Christian Quest a écrit :
>>
>> Pas mal, pas mal...
>>
>> > Voilà les océans, mers, baies, détroits maintenant visibles sur le
>> rendu
>> > FR :)
>>
>> Le golfe du Morbihan montre un corroyage curieux...
>>
>> J.
>>
>>
>> --
>> GnuPg : 156520BBC8F5B1E3 Because privacy matters.
>> « Quand est-ce qu'on mange ? » AD (c) (tm)
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>
>
>

Garanti
sans virus. www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [talk-cz] Brod na turistické a cyklotrase trase, za vyššího stavu neprůchozí - jak označit

[Jan Macura]

Ahoj

On Mon, 10 Aug 2020 at 16:59, majkaz  wrote:

> Včera jsem byla docela nemile překvapená zmizelou lávkou
>  přes
> Lužnici. Bohužel je tam zrovna vysoký stav vody, takže jsem zafungovala
> jako pionýr slepých uliček.
>

bridge=yes + seasonal=dry_season
 ? :D

H.
___
talk-cz mailing list
talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [OSM-talk-fr] Whodidit ne fonctionne plus

[David Delon]

Le 10/08/2020 à 17:09, osm.sanspourr...@spamgourmet.com a écrit :

Dis-tu ça par expérience ou par lecture du commentaire sur Github ?


Par expérience. En fait le flux RSS est cassé quand le nom d'un 
utilisateur possédant l'entité html "" apparaît dans le flux. Par 
exemple : 
https://validator.w3.org/feed/check.cgi?url=https%3A%2F%2Fresultmaps.neis-one.org%2Fosm-change-tiles-feed%3Fbbox%3D3.6301083092791857%2C43.7903676883%2C3.8829655175311393%2C43.828966489301855





Chez moi avec l'extension Feedbro sur FF, ça marche. Peut-être que ça me
marche pas sur la création de nouveaux flux.





Tu testes et tu complètes (ici et sur le ticket github
) ?


Fait.



Au fait non je ne connaissais pas (je connaissais les deux autres) :
l'écosystème est riche.


Plus pratique Whodidit finalement, il me semble pourtant avoir bien 
configuré mon filtre OSMCha, mais apparaissent dans le listing des 
modifications des changements qui n'ont rien à voir avec la BBOX que 
j'ai sélectionné.


David.


Jean-Yvon

Le 10/08/2020 à 16:26, David Delon - david.de...@clapas.net a écrit :

Je viens de voir, dans les commentaires Github, une alternative ici :
https://resultmaps.neis-one.org/osm-change-tiles, mais le flux RSS
produit n'est pas valide.



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



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

Re: [OSM-talk-fr] Whodidit ne fonctionne plus

[osm . sanspourriel]

Dis-tu ça par expérience ou par lecture du commentaire sur Github ?

Chez moi avec l'extension Feedbro sur FF, ça marche. Peut-être que ça me
marche pas sur la création de nouveaux flux.

Tu testes et tu complètes (ici et sur le ticket github
) ?

Au fait non je ne connaissais pas (je connaissais les deux autres) :
l'écosystème est riche.

Jean-Yvon

Le 10/08/2020 à 16:26, David Delon - david.de...@clapas.net a écrit :

Je viens de voir, dans les commentaires Github, une alternative ici :
https://resultmaps.neis-one.org/osm-change-tiles, mais le flux RSS
produit n'est pas valide.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[talk-cz] Brod na turistické a cyklotrase trase, za vyššího stavu neprůchozí - jak označit

[majkaz]

Ahoj všem.
 
Včera jsem byla docela nemile překvapená zmizelou lávkou 
 přes 
Lužnici. Bohužel je tam zrovna vysoký stav vody, takže jsem zafungovala jako pionýr 
slepých uliček.
 
Momentálně jsem z mapy most odstranila, cestu a relace přesměrovala brod 
vyznačený vedle. Je nějaké rozumné značení toho, že to ale bude pravděpodobně 
průchozí jen za sucha? Případně co s tou cyklotrasou (značená z Rakouska jako 
okruh), která tím v tomhle místě pro běžného cykloturistu skončí docela blbě?
 
Na KČT jsem to nahlásila, tak uvidíme jestli s tou jejich trasou budou dělat.
 
Majka
 
 

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

Re: [OSM-talk] Cyclofix project

[joost schouppe]

Hi Morten,

The site works without a database, so requires very little upkeep. The team
that worked on it is very enthusiastic about the project and at least four
of the five people who built this during Open Summer of Code are still
involved as volunteers. Our partners from the government also seem quite
enthused to keep using it on some of their websites, and friends at the
pro-cycle movement were also inspired. We are looking for ways to be able
to keep working on this in a more structural way, but for now I suspect our
enthusiasm will keep it afloat. The tool is now already in production for
two "official" projects.

For cyclofix, there's some things in my personal backlog:
- add all the layers here: https://cyclofix.osm.be/docs/using-data-map/
(now there's an example for "where to buy a bike", but all the layers
should be explained there)
- add more info to the public wiki - most of our thinking is described here
https://github.com/osmbe/cyclofix-website/issues/4 , and I have been
editing the wiki to make some things clearer. I also aim to extend this
page https://wiki.openstreetmap.org/wiki/Key:service:bicycle

With Pieter Fiers, we've also been thinking about creating a proposal for a
pub subtag, which could be used to refine cafe and pub with a certain
"style"; e.g. "an Irish pub" or a "cyclist oriented pub". For now we just
say "if it is a pub/cafe and has cycle services or a cycling club, it's a
cycle café"

I believe Pieter Vander Vennet also has some ideas on how to make the
overpass-queries behind the data more visible to end users, so the "real
OSM people" can easily get an idea of our choices.

We have tried to keep the entire Cyclofix project documented and easily
replicable (including "how to organise a cyclofix mapping party") on
https://cyclofix.osm.be/

If you want to be a little more closely involved: most of our team is
included in community (at) osm.be , and we've also created a Matrix
chatroom.

Best,
Joost

Op ma 10 aug. 2020 om 16:07 schreef Morten Lange via talk <
talk@openstreetmap.org>:

> Thanks for your hepful response (below).
> And sorry that I "re-sent"  my questions in a slightly different way.
>
> However, there were two new points.
> One question about the life expectancy of the current site
> and one suggestion or inspiration (By some possibly perceived as wishful
> thinking):
>
> I enjoyed testing your solution, and I would like to announce it to others
> to try.
> But I suppose continued operation of the current site is uncertain?
> That fact(?) holds me back a bit, except for "geeks"  and bicycle+map
> affectionados.
>
> Ideally The European Cyclists Federation or even UNEP or some other big
> organisation would offer to support operations of such a site, and cater
> for large traffic loads and continued development for, say, a 10 year
> period  :-)
> In the larger picture the costs would be quie low!
>
> --
> Regards / Kveðja / Kila la heri / Hilsen
> Morten Lange
>
>
> On Sunday, 9 August 2020, 16:25:52 CEST, Pieter Fiers 
> wrote:
>
>
> > Congratulations on a nice project and a useful one !
> > For a long time I have wished for a user-friendly bicycle repair
> specific map, including bicycle cafés.
>
> Thanks, us as well ;)
>
> >  What I miss in the Cyclofix project is an easy-to find definition of
> how you classify the nodes that are to be included in the different map
> "layers".
> > Which search is it that produces the bicycle cafés. (And what takes
> precedence if two or more criteria are fulfilled?)
>
> An excellent question, and something we want to improve in a future
> version (the discoverability and ease-of-use of the "layer" definitions).
>
> To answer the bicycle cafés question in the context of the current
> version:
> Take a look at
> https://github.com/pietervdvn/MapComplete/blob/master/Customizations/Layers/BikeCafes.ts#L23.
> That overpass filter/query can basically be written as: "a pub/bar/cafe
> with pub=cycling or any bicycle:service" (https://overpass-turbo.eu/s/WSU
> ).
>
> With regards to precedence, both POI's would be shown (not ideal). With
> the current definitions this might happen if there's an overlap on 
> shop=bicycle,
> amenity=pub/bar/cafe, amenity=bicycle_parking or amenity=
> bicycle_repair_station.
>
> > I agree with making a distinction between "pure" bicycle shops  and
> general sport shops that offer bicycles or  repair of bicycles.
>
> For "pure" bicycle shops we use shop=bicycle, for "other" shops (general
> sports equipment stores) we use shop=* + any bicycle:service:* tag.
>
> We're excited for the future and we're continuing work on making the
> project more user-friendly and approachable!
>
>
> Thanks for the kind words and with kind regards,
> Pieter Fiers
>
>
> On 05/08/2020 00:39, Morten Lange wrote:
>
> Congratulations on a nice project and a useful one !
>
> For a long time I have wished for a user-friendly bicycle repair specific
> map, including bicycle cafés.
>
> What I miss in the Cyclofix project is an 

Re: [OSM-talk-fr] Whodidit ne fonctionne plus

[Yves P.]

> Même s'il n'est pas aussi pratique que Whodidit qui fournissait un lien vers 
> OSMcha et Achavi, cela fera l'affaire, merci !
Il y a aussi des liens vers Achavi en cliquant sur un objet modifié.

Et pour le lien vers OSMcha, pas besoin, tu utilises déjà OSMcha ;)

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

Re: [OSM-talk-fr] Whodidit ne fonctionne plus

[David Delon]

J'avais essayé mais je n'avais pas vu qu'il pouvait générer un flux RSS. 
Même s'il n'est pas aussi pratique que Whodidit qui fournissait un lien 
vers OSMcha et Achavi, cela fera l'affaire, merci !


David.

Le 10/08/2020 à 16:35, Yves P. a écrit :

Whodidit est un outil qui permet de suivre les modifications des utilisateurs 
Openstreetmap sur l'emprise géographique de son choix.

Il me semble que OSMcha permet de faire exactement ça.
As-tu essayé ?

__
Yves


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



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

Re: [Talk-GB] OSMUK Instagram ideas

[Jez Nicholson]

Thanks for the ideas.

Today's post is about Missing Maps London on Tues 1 September
https://www.instagram.com/p/CDtkiAFH-sS/ which I attended last week. I've
been going to see what goes on. Gave me a chance to try out the new RapiD
editor.

I forgot to say that I want to be able to post once-a-day.

I haven't considered replicating somewhere 'open' yet. Insta has a big
reach, but I see that Pixelfed is a similar concept.


On Sun, Aug 9, 2020 at 2:42 PM Robert Skedgell  wrote:

> On 09/08/2020 14:31, Jez Nicholson wrote:
> > I've been posting to the OSMUK
> > Instagram https://www.instagram.com/openstreetmapuk/ account recently.
> > We are currently focusing on potential new mappers, so i'm thinking
> > quirky and topical.
> >
> > So,
> >
> > a) Do you know of an interesting looking feature in the UK?
> >
> > b) Do you know of something topical (and visual)?
> >
> > c) After this thread has finished, how best could/would you get in
> > contact to tell me? Twitter? A thread on Loomio? Here?
> >
> > Regards,
> >   Jez
> >
>
> Some of the COVID-19 related highway changes, e.g. modal filters
> implemented with planters might be worth including. There's an obvious
> visual and routing impact in real life, as rendered by OSM Carto and for
> routing engines.
>
> --
> Robert Skedgell (rskedgell)
>
>
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb
>
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [OSM-talk] Cyclofix project

[Morten Lange via talk]

Thanks for your hepful response (below).And sorry that I "re-sent"  my 
questions in a slightly different way.
However, there were two new points. 
One question about the life expectancy of the current site and one suggestion 
or inspiration (By some possibly perceived as wishful thinking): 
I enjoyed testing your solution, and I would like to announce it to others to 
try. 
But I suppose continued operation of the current site is uncertain?
That fact(?) holds me back a bit, except for "geeks"  and bicycle+map 
affectionados.   

Ideally The European Cyclists Federation or even UNEP or some other big 
organisation would offer to support operations of such a site, and cater for 
large traffic loads and continued development for, say, a 10 year period  :-)  
In the larger picture the costs would be quie low! 
-- Regards / Kveðja / Kila la heri / Hilsen Morten Lange 

On Sunday, 9 August 2020, 16:25:52 CEST, Pieter Fiers  
wrote:  
 
  > Congratulations on a nice project and a useful one ! > For a long time I 
have wished for a user-friendly bicycle repair specific map, including bicycle 
cafés.
 
  Thanks, us as well ;)
 
 >  What I miss in the Cyclofix project is an easy-to find definition of how 
 >you classify the nodes that are to be included in the different map "layers". 
 > Which search is it that produces the bicycle cafés. (And what takes 
 > precedence if two or more criteria are fulfilled?)
 
 An excellent question, and something we want to improve in a future version 
(the discoverability and ease-of-use of the "layer" definitions). 
 
 To answer the bicycle cafés question in the context of the current version: 
 Take a look at 
https://github.com/pietervdvn/MapComplete/blob/master/Customizations/Layers/BikeCafes.ts#L23.
 That overpass filter/query can basically be written as: "a pub/bar/cafe with 
pub=cycling or any bicycle:service" (https://overpass-turbo.eu/s/WSU).
 
 With regards to precedence, both POI's would be shown (not ideal). With the 
current definitions this might happen if there's an overlap on shop=bicycle, 
amenity=pub/bar/cafe, amenity=bicycle_parking or amenity=bicycle_repair_station.
 
 > I agree with making a distinction between "pure" bicycle shops  and general 
 > sport shops that offer bicycles or  repair of bicycles. 
 
 For "pure" bicycle shops we use shop=bicycle, for "other" shops (general 
sports equipment stores) we use shop=* + any bicycle:service:* tag.
 
 We're excited for the future and we're continuing work on making the project 
more user-friendly and approachable!
 
 
 Thanks for the kind words and with kind regards,
 Pieter Fiers
 
 
 On 05/08/2020 00:39, Morten Lange wrote:
  
 
 Congratulations on a nice project and a useful one ! 
  For a long time I have wished for a user-friendly bicycle repair specific 
map, including bicycle cafés. 
  What I miss in the Cyclofix project is an easy-to find definition of how you 
classify the nodes that are to be included in the differewnt map "layers".  
Which search is it that produces the bicycle cafés. (And what takes precedence 
if two or more criteria are fulfilled?) 
  I agree with making a distinction between "pure" bicycle shops  and general 
sport shops that offer bicycles or  repair of bicycles. 
 However, the way Cyclofix has decided to differentiate is not self-evident to 
me, after briefly checking your documentation. I must admit that I did not 
really consider looking at the source-code  ;-)  
   --  Regards / Kveðja / Kila la heri / Hilsen  Morten Lange
  
On Wednesday, 29 July 2020, 19:43:38 CEST, Pieter Fiers 
 wrote:  
  
 Dear OSM community,  
  My name is Pierre Barban. A team composed of three very motivated students, 
including myself, and lead by two active members of the OSMbe, have been 
mandated by the region of Brussels, Belgium, to create a map gathering all kind 
of data related to cycling. Without a doubt, OpenStreetMap was the perfect tool 
for us to create a powerful platform that would sustain over the years.  
  In the framework of month-long online code camp organized by the non-profit 
Open Knowledge Belgium, we have been able to establish the first version of the 
tool, organized a mapathon to collect data, and create a complete website to 
document the entire making process.  
  In accordance with the OSM core values, it would be very valuable for our 
project as well as our individual learning process to receive as many 
constructive comments from the community as possible. If you're interested in 
more details about the project, we will be giving an online presentation 
tomorrow July 30, 2020 at 1pm CEST. We will be available to directly discuss 
after the presentation to receive feedback in order to keep improving our 
project. Other related project from our program, Open Summer of Code, like the 
Bike Data Project - which aims to collect and share cyclist commute data in an 
opened way - will also be presented to you.   
  Please do not hesitate to 

Re: [OSM-talk-fr] Whodidit ne fonctionne plus

[Yves P.]

> Whodidit est un outil qui permet de suivre les modifications des utilisateurs 
> Openstreetmap sur l'emprise géographique de son choix. 
Il me semble que OSMcha permet de faire exactement ça.
As-tu essayé ?

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

[OSM-talk-fr] Whodidit ne fonctionne plus

[David Delon]

Bonjour à tous,

Whodidit est un outil qui permet de suivre les modifications des 
utilisateurs Openstreetmap sur l'emprise géographique de son choix. Très 
pratique pour assurer une veille sur sa commune par exemple. J'imagine 
que tout le monde connaît ici.


Depuis plus d'un mois, le flux RSS fourni par cette application ne 
fonctionne plus. Le développeur et hébergeur de l'application ne répond 
pas, voir https://github.com/simon04/whodidit/issues/47 .


Je viens de voir, dans les commentaires Github, une alternative ici : 
https://resultmaps.neis-one.org/osm-change-tiles, mais le flux RSS 
produit n'est pas valide.


Il n'y aurait pas moyen d'avoir une instance, sur un serveur 
openstreetmap fr, qui hébergerait Whodidit ? C'est vraiment un outil qui 
me semble indispensable pour le suivi de la qualité sur Openstreetmap 
(notamment pour repérer les nouveaux contributeurs). Sinon, comment 
faites-vous pour assurer ce genre de suivi ?



David Delon.

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

[OSM-talk-fr] hebdoOSM 524 | Financement de développement pour Nominatim par la foundation OSM

[Yves P.]

Bonjour,

Lu dans l'hebdo, une nouvelle qui devrait vous intéresser :

> https://weeklyosm.eu/fr/archives/13472 
> 
> Guillaume Rischard  a annoncé 
>  en 
> direct le financement de trois projets d’infrastructure : Nominatim, 
> osm2pgsql et Potlatch 2 par le CA de l’OSMF. 

Nominatim est le logiciel de géocodage qui alimente openstreetmap.org et de 
nombreuses autres applications et sites Web.
Sarah souhaite travailler sur openstreetmap.org  
pour 
terminer les efforts de localisation (améliorer le calcul d'adresse pour 
différents pays, sortie d'adresse localisée)
rendre le logiciel plus convivial (réduire le nombre de langages de 
programmation d'au moins deux, déplacer les projets annexes dans des dépôts 
séparés, réorganiser le code pour que Nominatim puisse devenir un package 
Ubuntu, docs, docs, docs)
La proposition complète se trouve sur 
https://wiki.osmfoundation.org/wiki/Nominatim_project_2020-07 


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

Re: [OSM-talk-fr] Chantiers d'été pour OSM-FR ;)

[Philippe Verdy]

Le modèle de couleurs est aussi à revoir: il est beaucoup top contrasté
(surtout à faible niveau de zoom), et aujourd'hui je préfère la solution
adoptée par le rendu Carto OSM.org qui réduit ce contraste à mesure qu'on
dézoome, ce qui donne une carte bien plus lisible.

Le rendu OSM.fr est aujourd'hui beaucoup trop "patchwork", très peu lisible
et exploitable. Il a été bon et mailleurs que l'ancien rendu OSM.org mais
est aujourd'hui dépassé (AMHA): ce qui compte c'est plus la quantité
importante de données détaillées qu'on peut y trouver (surtout au niveau
des points individuels avec les libellés et icônes) mais les textures et
couleurs de remplissage sont à revoir pour plus de discrétion: plus les
zones sont petites, moins on doit y voir du contraste. Ce rendu OSM.fr
manque d'accessibilité et lisibilité, et plus en essayé d'ajouter des
détails locaux, moins ces détails sont identifiables car le fond les rend
difficilement lisibles (et cela réduit fortement la réutilisation).

Je vois plus le rendu OSM.fr comme une démo qui a permis de montrer les
faiblesses de l'ancien rendu CartoOSM.org, mais aujourd'hui il s'est
largement amlélioré et a retenu le meilleur des différentes options
proposées dans différents rendus.

Peut-on revoir ça (c'est surtout du nettoyage à refaire sur les feuilles de
style, indépendamment de ce qu'on veut afficher).


Le lun. 10 août 2020 à 09:31, Jacques Lavignotte  a
écrit :

>
>
> Le 09/08/2020 à 23:18, Christian Quest a écrit :
>
> Pas mal, pas mal...
>
> > Voilà les océans, mers, baies, détroits maintenant visibles sur le rendu
> > FR :)
>
> Le golfe du Morbihan montre un corroyage curieux...
>
> J.
>
>
> --
> GnuPg : 156520BBC8F5B1E3 Because privacy matters.
> « Quand est-ce qu'on mange ? » AD (c) (tm)
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Facebook achète Mapillary !

[Philippe Verdy]

Le lun. 10 août 2020 à 11:09, Christian Quest  a
écrit :

> > Pour les mêmes raisons, je voudrais moi aussi supprimer toutes mes
> > photos téléversées ces dernières années sur Mapillary.
>
>
> Tu as accepté de mettre ces photos sous licence CC, c'est irrévocable
> Il serait bon de ne pas perdre de vue les principes des licences libre.
> Demander à Mapillary de les supprimer, revient à les rendre
> indisponibles pour tous, sauf pour eux (because licence irrévocable).
> C'est donc contre-productif.
>

Remarque très pertinente.
Maintenant si tu "supprimes" la publication sur Mapillary, en fait rien ne
te garantie qu'il ne conserveront pas et n'utiliseront pas les photos, et
ils auront encore le droit de les publier (mais évidemment ils ne pourront
le faire que sous la licence libre et en te citant comme auteur.

Bref ça ne sert à rien de "supprimer" les images sur Mapillary c'est
virtuel, ils feront ce qu'ils voudront avec, tout comme chacun ayant déjà
chargé tes photos. La seule chose à faire c'est de surveiller que ces
utilisations ne sont pas des appropriations propriétaires où Mapillary (ou
n'importe qui d'autre) s'attribuerait comme auteur ou réclamerait une autre
licence ou un droit d'usage.

C'est pour ça que je suis pour le fait de téléverser des photos sous
licences libres avec un filigrane indélébile indiquant l'auteur, la licence
et l'année de publication initiale sous forme d'un petit RDF
"stéganographié" dans l'image (en plus des tags directement lisibles) et
déchiffrable jusqu'à une réduction d'échelle ou tout flou gaussien ou
bruitage appliqué ou déformation modérée

[
En général les déformations suivent une courbe simple de changement
d'échelle sur une base triangulaire relativement lâche (surtout pour
l'ortho-rectification et le passage d'un vue en perspective à déformation
hyperbolique en vue parallélépipédique ; d'autres transformations comme la
vue en "oeil de poisson" pour produire les rendus à 360 degrés à partir de
clichés multiples. Mais ces courbes de déformation ont un impact limité sur
l'image qui peut être triangulée sur une surface suffisamment significative
et une réduction d'échelle d'un facteur jusqu'à 8 ou 16 n'efface pas la
pertinence de précision qui permet à la stéganographie de conserver les
données chiffrées mais invisibles dans l'image même si on ne la bruite pas
du tout car il y a déjà du bruit dans toute image uniquement du fait de la
précision limitée et de la quantification; ce bruit fiable pixel par pixel
devient exploitable pour coder un bit complet sur un groupe assez large de
pixels (par exemple 16x16 pixels, qui plus est en couleurs, sachant que
l’œil ne perçoit pas bien la colorimétrie mais mieux les contrastes de
luminosité).

Ces bits assemblés forment une chaîne qui peut contenir un code
autocorrecteur et plusieurs répétitions, et toute altération locale ou même
gommage par lissage gaussien ou par ajout de bruit aléatoire ne parvient
pas à effacer ces fragments car il y a toujours des effets de "seuil" dans
ce gommage, sauf en cas de réduction drastique de l'échelle (pour obtenir
une image toute petite, pas plus grande qu'une icône de fichier) où
finalement l'image n'a plus sa valeur initiale et sa pertinence pour une
licence et un auteur (surtout si c'est une vue de l'espace réel où il peut
y avoir de nombreuses autres photos "similaires" faites par plein
d'auteurs).

Si la chaine stéganographiée est courte, on peut l'appliquer à nouveau sur
différentes échelles de l'image et dans différentes rotations (par exemple
tous les 15 degrés dans l'intervalle de +/-45 degrés, ce qui est suffisant
pour pouvoir la déchiffrer sur des surface pas très grandes pour des
rotations ou déformations arbitraires avec 6 orientations, toutes les
autres étant de simples symétries triviales ayant les mêmes
caractéristiques de "bruit" et de quantification). Cette stéganogragpie va
créer une image "holographique" de la signature, surajoutée sur la
totalité de l'image et indiscernable de son bruit original.

La stéganographie est un moyen efface, on peut même prévenir Mapillary que
les conditions et licence, date et auteur sont stéganographiés de façon
difficilement altérable, et que ces images sont donc publiées en l'état et
que toute réutilisation devra donc respecter la licence indiquée en clair,
sans avoir à révéler les clés de déchiffrement de la stéganographie.
Je ne parle pas des techniques de "filigranes" visibles qui elles sont très
gênantes pour tout et ne sont pas de la stéganographie. La vraie
stéganographie n'altère pas la qualité de l'image mais exploite la
variabilité de son bruit naturel dans les photos numériques (c'est plus
compliqué pour les images générées par ordinateur ou le texte, sauf en ce
qui concerne les techniques de compression de données où il y a de la
variabilité exploitable, mais il suffirait de décompresser et
recompresser le contenu pour effacer la stéganographie; la parade c'est
d'inclure une signature numérique de sécurité du format compressé 

[Talk-dk] Rekorden er i hus og det er muligt at få en is endnu

[Soren Johannessen]

Hej alle sammen

Var du med til at sætte dansk daglig rekord i går med hele 85 OSM
frivillige? Men du nåede aldrig at få 50 kr til en is eller andet
køligt fra vores sponsorer Septima, OpenDenmark og mit firma.  Så er
det stadigvæk muligt og i dag er det også varmt  og det kunne måske
være rart med noget køligt.

Så hold jer endelig ikke tilbage med at skrive til soren.johannessen
Snabel a  gmail.com med dit Mobilpay nummer samt OSM
brugernavn, og jeg vil overføre pengene, så hurtigt som muligt. Først
til mølle princip.

Jeg lukker dette is  transfervinduet kl. 21.00 i aften, så skriv allerede nu.

Med venlig hilsen
Søren Johannessen

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

Re: [OSM-talk-fr] Chantiers d'été pour OSM-FR ;)

[osm . sanspourriel]

Le 10/08/2020 à 09:30, Jacques Lavignotte - jacq...@lavignotte.org a écrit :

Le golfe du Morbihan montre un corroyage curieux...

Tu parles de RN comme Réserve Naturelle ? Oui effectivement après les
sandales affichant RPR sur les plages...

https://umap.openstreetmap.fr/fr/map/rendu-fr-en-developpement_483858#15/47.5776/-2.8682

À coté la Baie de Quiberon bégaye.

https://umap.openstreetmap.fr/fr/map/rendu-fr-en-developpement_483858#14/47.5315/-3.0053

Pourtant elle n'est décrite qu'une fois :

https://www.openstreetmap.org/relation/9296969#map=11/47.5339/-2.9905

Jean-Yvon

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

[OSM-talk-fr] Reception et Security Desk — Projet du mois de septembre (en préparation) : défibrillateurs !

[Yves P.]

Bonjour,

> Le 5 août 2020 à 21:41, Julien Lepiller  a écrit :
> 
> Je ne comprends pas bien les attributs proposés (reception_desk,
> security_desk, surveillance), ça n'a pas l'air indiqué sur la page du
> wiki :).


Je ne vois pas leur intérêt : il s'agit d'info concernant l'établissement, pas 
le DAE en lui-même.

"Présence d'un poste de sécurité au sein du bâtiment"
"Présence de personnels dédiés pour l'accueil des personnes au sein du 
bâtiment"
Source : 
https://carto.atlasante.fr/IHM/cartes/infofactures/geodae/dgs-dae_standard_de_donnees_vf.pdf
 



De plus, on trouve des données cocasses : 
defibrillator:location="Accueil (poste de sécurité)"
reception_desk=no
security_desk=no
https://www.openstreetmap.org/node/2335405998 

__
Yves


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

Re: [OSM-talk-fr] Facebook achète Mapillary !

[Christian Quest]

Le 10/08/2020 à 10:31, Axel Listes a écrit :

Bonjour,

Le 19/06/2020 à 12:25, Laurence P a écrit :

Mapillary était un service très pratique, mais il n'est pas
indispensable. Lors que j'ai effectué mes premières prises de vue, cela
me posait déjà un cas de conscience : est ce que le monde doit être
photographié sous ses moindre coutures ? / Stocker toutes ces photos
c'est pas écolo / Aider une société qui va aider au développement des
véhicules autonomes est-ce bien raisonnable ? ...

Pour les mêmes raisons, je voudrais moi aussi supprimer toutes mes
photos téléversées ces dernières années sur Mapillary.



Tu as accepté de mettre ces photos sous licence CC, c'est irrévocable

Il serait bon de ne pas perdre de vue les principes des licences libre.

Demander à Mapillary de les supprimer, revient à les rendre 
indisponibles pour tous, sauf pour eux (because licence irrévocable). 
C'est donc contre-productif.




J'ai anticipé en les téléversant sur OpenStreetCam, que j'avais déjà
utilisé parallèlement au débit puis abandonné, car la plateforme
générait des erreurs.

Aujourd'hui, je voudrais remplacer des sources mapillary=* par
OpenStreetCam dans la base de données OSM. Mais je ne trouve pas de doc
à ce sujet, j'ignore si les liens et références que donne OSC sont
pérennes ?

Certain·e·s ont déjà réalisé des recherches à ce sujet ?

https://wiki.openstreetmap.org/wiki/FR:Key:mapillary

Axel.



Tu peux récupérer tes photos en plein définition chez mapillary.

Nous avons mis en place un petit service qui s'occupe de ça et en 
conserve donc une copie d'archive.


C'est ici (et il reste quelques To): 
https://takeitout.cquest.org/mapillary_takeout


Le problème étant surtoutqu'on n'est pas à l'abri d'un changement de 
politique de Mapillary sur l'accès libre aux photos déposées depuis des 
années, c'est l'intérêt d'avoir une archive. OpenStreetCam n'est pas 
plus fiable (racheté aussi par une société pas très culture OSM).



Pour les tags, on a justement une discussion à ce sujet en ce moment en 
lien avec les DAE.


Faudrait-il archiver les photos qui sont derrière les tags image=* ou 
mapillary=* ?



--
Christian Quest - OpenStreetMap France


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

Re: [OSM-talk-fr] Facebook achète Mapillary !

[Yves P.]

> Aujourd'hui, je voudrais remplacer des sources mapillary=* par
> OpenStreetCam dans la base de données OSM.
> 
> Certain·e·s ont déjà réalisé des recherches à ce sujet ?

Oui, il n'y a pas de tag OSC.

Après, virer les photos de Mapillary ne me semble ni urgent, ni nécessaire ;)
C'est la meilleure interface à ce jour avec des données ouvertes…
__
Yves
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Facebook achète Mapillary !

[Axel Listes]

Bonjour,

Le 19/06/2020 à 12:25, Laurence P a écrit :
> Mapillary était un service très pratique, mais il n'est pas
> indispensable. Lors que j'ai effectué mes premières prises de vue, cela
> me posait déjà un cas de conscience : est ce que le monde doit être
> photographié sous ses moindre coutures ? / Stocker toutes ces photos
> c'est pas écolo / Aider une société qui va aider au développement des
> véhicules autonomes est-ce bien raisonnable ? ...

Pour les mêmes raisons, je voudrais moi aussi supprimer toutes mes
photos téléversées ces dernières années sur Mapillary.

J'ai anticipé en les téléversant sur OpenStreetCam, que j'avais déjà
utilisé parallèlement au débit puis abandonné, car la plateforme
générait des erreurs.

Aujourd'hui, je voudrais remplacer des sources mapillary=* par
OpenStreetCam dans la base de données OSM. Mais je ne trouve pas de doc
à ce sujet, j'ignore si les liens et références que donne OSC sont
pérennes ?

Certain·e·s ont déjà réalisé des recherches à ce sujet ?

https://wiki.openstreetmap.org/wiki/FR:Key:mapillary

Axel.

-- 

"Un peuple prêt à sacrifier un peu de liberté pour un peu de sécurité ne
mérite ni l'une ni l'autre, et finit par perdre les deux."
Citation de Benjamin Franklin.

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

[OSM-talk-fr] Attribution manquante sur Inforoute

[Arnaud Champollion]

Bonjour,

Inforoute avait déjà été contacté en janvier, mais toujours aucune 
évolution.


J'ai relancé http://www.inforoute04.fr/  via le formulaire présent sur 
le site du Département, en leur suggérant de s'inspirer du modèle 
d'attribution de inforoute.hautes-alpes.f, et mis à jour la page du Wiki.


Bonne journée,

Arnaud




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

Re: [OSM-talk-fr] Chantiers d'été pour OSM-FR ;)

[Jacques Lavignotte]

Le 09/08/2020 à 23:18, Christian Quest a écrit :

Pas mal, pas mal...

Voilà les océans, mers, baies, détroits maintenant visibles sur le rendu 
FR :)


Le golfe du Morbihan montre un corroyage curieux...

J.


--
GnuPg : 156520BBC8F5B1E3 Because privacy matters.
« Quand est-ce qu'on mange ? » AD (c) (tm)

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

Re: [OSM-talk] This needs to be voted upon.

[Maarten Deen]

I also don't want to imply that a vote is imminent, just that this is 
such a big issue, it can not be decided by mere consensus on a 
mailinglist. Not everyone follows these discussions (not that everyone 
reads the wiki though, but again, this is a major thing).


Regards,
Maarten

On 2020-08-10 08:06, stevea wrote:

I didn't mean to convey or imply that a vote was impending, moreso
that I seriously disagree with the proposal as unneeded, unnecessary,
poorly explained as to its benefits, and (as was well described
before, though I paraphrase), "a ready-made answer for a non-problem."
 My apologies if anybody got the wrong impression that this was up for
a vote.  Rather, here and now it is being discussed, my "No" was
merely my opinion IF it went to a vote.  Better stated, I disagree
with the proposal, as I see no need for it, it is over-engineered, it
has no clear merit, it is confusing, it seems to be more trouble than
it is worth and I feel it would chase away novice volunteers as "too
complex."  The consensus, with the exception of the proposer, seems
100% in line with my opinions.  I do welcome more discussion, that's
why we type here.

SteveA

On Aug 9, 2020, at 11:01 PM, Mateusz Konieczny via talk 
 wrote:





Aug 10, 2020, 07:49 by md...@xs4all.nl:
On 2020-08-10 03:32, stevea wrote:
On Aug 9, 2020, at 5:29 AM, pangoSE  wrote:
The discussion below spawned the following idea of migrating the whole 
tags system instead.

(an over engineered proposal largely, as Frederick says and I agree
with, goosed by the "hype of linked data.")

I politely vote "No." I don't see the merit (again echoing
Frederick). While I'm only one person and one vote and perhaps a bit
more vocal than most, I feel it important to express the opinion of
"very strongly against."

I certainly hope that if this idea goes towards implementation that 
there will be a vote first. I also don't see the merits so my vote 
will also be no.
Before going to vote it would need to demonstrate some sort of clear 
benefit and

consensus that it is reasonable.

Vote can be gamed in many ways, and even if that proposal somehow 
would won a vote

it still would not improve it a tiny bit.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk


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

Re: [OSM-talk] This needs to be voted upon. (was: Re: Separating all metadata from coordinates in OSM into a wikibase instance)

[stevea]

Even better stated, if pangoSE is interested in a longer-term goal (and, it 
truly must be this if anything at all) of moving OSM towards becoming a "full 
member of the semantic web," fairly large things must happen.

1)  Linked data and "the semantic web" (which has been emerging since circa 
2001) must become more fully-formed itself.  It has been called "Web 3.0," but 
think about how well-defined even "Web 2.0" is today.  (There will be lots of 
answers here, but you see my point:  it's relatively early days for both).

2)  Much more than a "toss a poorly-formed and poorly-stated 'what for' against 
the wall on the Talk board" must happen first.  Inter-academic discussion, 
white papers, tracks at conferences, people with ideas who publish, synthesis 
of already-good-ideas-and-implementations in the semantic web with what OSM's 
longer-term goals, and much more.  This is an intermediate- to longer-term 
proposition, I'd say five to fifteen years.  (Happy Sweet 16, OSM).

3)  Drop-dead-easy-for-novices integration must be nearly seamless as these 
begin to integrate with existing workflows in OSM.  The chicken-and-egg thing 
going on right now is most people have never heard of Web 3.0 / the semantic 
web, know nothing about it, don't see it's (admittedly longer-term) benefits 
and so often have hostility or confusion about "why?"  This might have seemed 
my initial position, and isn't really true, so I now clarify.

4)  Real-life examples of how AI, neural networks, machine learning benefits of 
how linked data in a semantic web must be offered for people to see the 
benefits.  I don't mean pedagogical aids like teaching the basics of how triple 
statements, literals and URIs work (though, those are important early 
concepts), I mean "hey, that's a really neat and powerful exploitation of why 
we'd bother to link data."  The first examples might be geographical in nature 
to appear to OSM, they might not, but they should be sooner, rather than later, 
so people can more immediately realize benefits.

There:  I think I've tilled the soil a bit, and if pangoSE or somebody wants to 
plant seeds (again), I'd read #2 above and think much longer-term.  OSM could 
do this, but it's going to take more than a thread on Talk and a wad tossed 
against a wall.  And maybe a decade or two.

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

Re: [OSM-talk] Separating all metadata from coordinates in OSM into a wikibase instance (Was: Re: Roadmap for deprecation of name tags in OSM)

[Shawn K. Quinn]

On 8/9/20 07:29, pangoSE wrote:
> Of course this is also a big change which has to be considered carefully.
> 
> I believe linked data is the only sane way to go forward when it comes
> to metadata.
[...]

I think this adds a huge amount of complexity for a highly dubious
benefit. I'd also vote no and if this somehow came to pass anyway, I
feel so strongly about it that I'd consider starting a new project and
forking the current data model (a la FOSM around the time of the license
change).

-- 
Shawn K. Quinn 
http://www.rantroulette.com
http://www.skqrecordquest.com

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

[OSM-talk-fr] hebdoOSM Nº 524 : nouvel éditeur de POI

[Yves P.]

Bonjour,

Lu dans https://www.weeklyosm.eu/fr/archives/13472/ 
, un éditeur italien de POI : 
https://su.openstreetmap.it  

C'est un fork de OnOSM qui détail plus la saisie (covid-19, accessibilité, 
moyens de paiement…) et améliore son ergonomie.
Comme OnOSM, il n'édite pas directement OSM mais génère une note.

À traduire en français ?
__
Yves

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

Re: [OSM-talk] This needs to be voted upon. (was: Re: Separating all metadata from coordinates in OSM into a wikibase instance)

[stevea]

I didn't mean to convey or imply that a vote was impending, moreso that I 
seriously disagree with the proposal as unneeded, unnecessary, poorly explained 
as to its benefits, and (as was well described before, though I paraphrase), "a 
ready-made answer for a non-problem."  My apologies if anybody got the wrong 
impression that this was up for a vote.  Rather, here and now it is being 
discussed, my "No" was merely my opinion IF it went to a vote.  Better stated, 
I disagree with the proposal, as I see no need for it, it is over-engineered, 
it has no clear merit, it is confusing, it seems to be more trouble than it is 
worth and I feel it would chase away novice volunteers as "too complex."  The 
consensus, with the exception of the proposer, seems 100% in line with my 
opinions.  I do welcome more discussion, that's why we type here.

SteveA

> On Aug 9, 2020, at 11:01 PM, Mateusz Konieczny via talk 
>  wrote:
> 
> 
> 
> 
> Aug 10, 2020, 07:49 by md...@xs4all.nl:
> On 2020-08-10 03:32, stevea wrote:
> On Aug 9, 2020, at 5:29 AM, pangoSE  wrote:
> The discussion below spawned the following idea of migrating the whole tags 
> system instead.
> (an over engineered proposal largely, as Frederick says and I agree
> with, goosed by the "hype of linked data.")
> 
> I politely vote "No." I don't see the merit (again echoing
> Frederick). While I'm only one person and one vote and perhaps a bit
> more vocal than most, I feel it important to express the opinion of
> "very strongly against."
> 
> I certainly hope that if this idea goes towards implementation that there 
> will be a vote first. I also don't see the merits so my vote will also be no.
> Before going to vote it would need to demonstrate some sort of clear benefit 
> and
> consensus that it is reasonable.
> 
> Vote can be gamed in many ways, and even if that proposal somehow would won a 
> vote 
> it still would not improve it a tiny bit.
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk


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

Re: [OSM-talk] This needs to be voted upon. (was: Re: Separating all metadata from coordinates in OSM into a wikibase instance)

[Mateusz Konieczny via talk]

Aug 10, 2020, 07:49 by md...@xs4all.nl:

> On 2020-08-10 03:32, stevea wrote:
>
>> On Aug 9, 2020, at 5:29 AM, pangoSE  wrote:
>>
>>> The discussion below spawned the following idea of migrating the whole tags 
>>> system instead.
>>>
>> (an over engineered proposal largely, as Frederick says and I agree
>> with, goosed by the "hype of linked data.")
>>
>> I politely vote "No."  I don't see the merit (again echoing
>> Frederick).  While I'm only one person and one vote and perhaps a bit
>> more vocal than most, I feel it important to express the opinion of
>> "very strongly against."
>>
>
> I certainly hope that if this idea goes towards implementation that there 
> will be a vote first. I also don't see the merits so my vote will also be no.
>
Before going to vote it would need to demonstrate some sort of clear benefit and
consensus that it is reasonable.

Vote can be gamed in many ways, and even if that proposal somehow would won a 
vote 
it still would not improve it a tiny bit.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk