Re: [OSM-talk-fr] Règle Osmose pour tag brand:wikipedia

2020-10-24 Par sujet Philippe Verdy 
Sauf que NSI spécialise ses conseils par pays (le code pays est bien
visible dans ses filtres)
Donc le bogue est plutôt dans Osmose (pas dans NSI), qui oublie de chercher
avec le filtre pays approprié au lieu, **avant** d'aller faire un repli
vers les attributs internationaux.

De toute façon les tags wikipedia sont dépréciés et inutiles si on a un tag
wikidata (où on trouvera les liens des diverses éditions de wikipedia,
sahcnat aussi que les codes "langue" de wikipedia ne sont pas vraiment des
codes langue (au sens de BCP47) mais des alias locaux propre au système de
codes interwiki.

Wikimedia peut avoir des codes différents, non standards, persistant
uniquement parce que ce sont des labels de noms de sous-domaines ou des
codes internes de noms de base de données dont tout le monde se fout, ou
fusionnés là où BCP47 est bien plus strict et plus précis sur les règles de
repli et les codes valides: mais c'est très long (ça fait des années que ça
dure comme des bogues signalés mais dont la correction est sans cesse
repoussée) pour qui Wikimedia fasse les correction nécessaires (à la limite
le plus facile a juste été de créer des "alias" sur les noms de domaines
(CNAME ou redirections) en deux temps (d'abord du code standard vers
l'ancien code, puis dans le sens inverse), ensuite il faut des années pour
mettre à jour les nombreux modèles ou modules, réviser des données
d'internationalisation au sein même de Mediawiki ou de son installation
locale, informer les communautés, tester, tester encore, vérifier que le
renommage peut aussi être fait dans translatewiki.net, que les outils
d'export/import de TWN vers MediaWiki puis de déploiement dans Wikipedia ou
les autres projets fonctionnent avec les nouveaux codes, puis prévoir la
transition des noms de domaine canoniques, vérifier que les redirections
fonctionnent, puis enfin la mettre en oeuvre, patienter des mois pour que
les sites web externes (notamment les moteurs de recherche) se mettent à
jour, puis commencer à prévoir le démantèlement du support par redirection
de l'ancien code (s'il est en conflit avec un autre usage nécessaire),
nettoyer Wikidata... La dernière phase (qui nécessite un arrêt du wiki) est
le renommage de la base de données, qui elle aussi se fait en plusieurs
étapes.
Renommer un wiki de Wikimedia n'est pas simple du tout (même pour les
petits wikis) !

Du côté d'OSM c'est plus simple: éviter de référencer wikipedia et mettre
wikidata à la place et laisser Wikidata gérer ces liens sur sa base.

Donc pour les "brands" cela n'a plus d'importance et on élimine des tas de
redondances pas utiles dans OSM qui nécessitent des constantes corrections
(surtout en plus que Wikipedia n'est pas forcément précis: chaque édition
peut décider ou non de fusionner plusieurs sujets dans un même article,
avec plusieurs sections, et Wikidata ne sait pas encore gérer correctement
les liens vers les sections d'article pour la désambiguisation et les
fusions ou scissions faites dans une édition linguistique de Wikipédia ne
sont pas pertinentes pour les autres, ni non plus pour d'autres projets
liés comme Commons ou Wikivoyage.

Si vous avez des problèmes avec des liens Wikipédia (comme ceux qui
persistent à changer l'édition linguistique "pertinente" sans tenir compte
de la langue locale appropriée, qui est aussi en elle-même un sujet de
conflit dans les régions multilingues comme la Catalogne ou le Pays basque
en Espagne, ou encore la Corse, ou les langues co-officielles en Belgique,
en Suisse ou au Canada) et ne trouvez pas d'élément Wikidata associé à un
article pertinent, le lieux est de créer cet élément Wikidata manquant, le
lier correctement à l'article Wikipédia le plus approprié et éventuellement
chercher dans d'autres éditions ou d'autre projets comme Commons,
Wikivoyage, Wikinews (voire le Wiktionnaire pour certains toponymes
connus). Et ensuite éliminer tous les tags wikipedia et les remplacer par
un tag wikidata unique vers l'élément Wikidata que vous avez créé.



Le sam. 24 oct. 2020 à 22:17,  a écrit :

> Bonjour, les suggestions d'Osmose sont des suggestions.
>
> Ici le suggestion-index est une belle c... : wikidata est neutre.
>
> Le "bon" article Wikipédia est usuellement celui du pays où est la filiale.
>
> Je remets régulièrement des fr:Système U alors que iD suggère de
> modifier en en:Système U.
>
> C'est crétin : c'est une entreprise française exerçant en France.
> L'article en anglais est évidemment plus pauvre.
>
> Donc la bonne page c'est par défaut la page dans la langue par défaut du
> pays.
>
> Jean-Yvon
>
> Le 24/10/2020 à 21:55, Romain MEHUT - romain.me...@mailo.com a écrit :
> > Bonsoir,
> >
> > Dans ce changeset https://www.openstreetmap.org/changeset/92924630
> > j'ai demandé pourquoi la valeur au tag brand:wikipedia n'était pas la
> > déclinaison française. La réponse est que c'est une suggestion d'Osmose.
> >
> > Ne priorise-t-on pas la valeur fr (s'agissant du territoire français
> > bien sûr) ?
> >
> > Merci pour vos

Re: [OSM-talk-fr] Règle Osmose pour tag brand:wikipedia

2020-10-24 Par sujet osm . sanspourriel 

Bonjour, les suggestions d'Osmose sont des suggestions.

Ici le suggestion-index est une belle c... : wikidata est neutre.

Le "bon" article Wikipédia est usuellement celui du pays où est la filiale.

Je remets régulièrement des fr:Système U alors que iD suggère de
modifier en en:Système U.

C'est crétin : c'est une entreprise française exerçant en France.
L'article en anglais est évidemment plus pauvre.

Donc la bonne page c'est par défaut la page dans la langue par défaut du
pays.

Jean-Yvon

Le 24/10/2020 à 21:55, Romain MEHUT - romain.me...@mailo.com a écrit :

Bonsoir,

Dans ce changeset https://www.openstreetmap.org/changeset/92924630
j'ai demandé pourquoi la valeur au tag brand:wikipedia n'était pas la
déclinaison française. La réponse est que c'est une suggestion d'Osmose.

Ne priorise-t-on pas la valeur fr (s'agissant du territoire français
bien sûr) ?

Merci pour vos éclairages.

Romain




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



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

Re: [OSM-talk-fr] Règle Osmose pour tag brand:wikipedia

2020-10-24 Par sujet Frédéric Rodrigo 

Bonsoir,

Ça utilise les données de NSI.
Après ça n'a pas d'importance codé données, par définition les pages 
Wikipédia sont sont équivalente.
Mais je suis d'accord avoir le lien vers la page française facilité les 
choses coté réutilisation, mais ce n'est pas dans NSI.


https://nsi.guide/

Frédéric.


Le 24/10/2020 à 21:55, Romain MEHUT a écrit :

Bonsoir,

Dans ce changeset https://www.openstreetmap.org/changeset/92924630 
j'ai demandé pourquoi la valeur au tag brand:wikipedia n'était pas la 
déclinaison française. La réponse est que c'est une suggestion d'Osmose.


Ne priorise-t-on pas la valeur fr (s'agissant du territoire français 
bien sûr) ?


Merci pour vos éclairages.

Romain




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




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

[OSM-talk-fr] Règle Osmose pour tag brand:wikipedia

2020-10-24 Par sujet Romain MEHUT 

Bonsoir,

Dans ce changeset https://www.openstreetmap.org/changeset/92924630 j'ai 
demandé pourquoi la valeur au tag brand:wikipedia n'était pas la 
déclinaison française. La réponse est que c'est une suggestion d'Osmose.


Ne priorise-t-on pas la valeur fr (s'agissant du territoire français 
bien sûr) ?


Merci pour vos éclairages.

Romain




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

Re: [OSM-talk-fr] Nouveau rendu osm.fr

2020-10-24 Par sujet Philippe Verdy 
Personnellement je suis plus en faveur du rendu bitmap des surfaces
colorées de fond (avec un dégradé progressivement plus pâle pour les
faibles niveaux de zoom afin de masquer un peu mieux les détails locaux):
une seul rendu pour tout le fond en fait, sans aucun palissement, le
palissement est fait par un "alpha blending selon le niveau de zoom, du
coup une seule couche bitmap à calculer pour tout et la possibilité alors
de recalculer dynamiquement et facilement les niveaux de zoom plus faible.
C'est bien plus efficace et bien plus joli visuellement et plus rapide pour
tout le monde, le remplissage de polygones complexes est une opération très
couteuse en CPU qui marchera assez mal pour les mobiles si on veut
préserver leur autonomie).

On peut aussi faire une composition alpha-blending pour le rendu en
l'ombrage de la topographie d'altitude (mais pas pour les lignes d'iso)

En revanche ça ne marche mal pour les éléments linéaires (l'épaisseur des
traits doit changer, et on doit masquer plus de choses en dézoomant sinon
on superpose trop de choses), et pas du tout pour les éléments icônes et
textes posées encore par dessus : ces deux parties sont destinés à un rendu
vectoriel, y compris les lignes d'iso de topographie d'altitude).

Et pour les textes, bien séparer les textes localisables afin d'avoir une
sélection possible de la langue et un basculement facile: ce sera la couche
supérieure au dessus de la couche vectorielle des traits et des icônes (les
icônes sont aussi en format vectoriel afin de pouvoir tenir compte de la
résolution réelle pour les écrans HiDPI, mais elles ne posent pas de
problème car leur rendu bitmap pour la composition est facilement mise en
cache local pour économiser de la ressource locale de rendu, de la même
façon que se fait *déjà* le rendu bitmap des polices de textes dans tous
les moteurs de rendu de texte, ce ne sera donc pas répétitif et coûteux en
batterie.

La composition (blending) des couches est une opération de base de toutes
les cartes graphiques modernes (y compris tous les appareils mobiles) et
sinon c'est très optimisé au niveau de l'OS ou du navigateur pour un rendu
CPU (pour bureaux ou serveurs qui de toute façon sont aujourd'hui bien plus
rapides et pas trop limités en capacité de batterie), mais elle demande un
peu plus de mémoire: ce n'est aujourd'hui un problème que pour les
appareils mobiles très bon marchés ou anciens avec un vieil OS, ou un
affichage assez basique (mais ils sont aussi des tailles d'écran et
résolutions plus limitées, avec aussi une moins grande profondeur binaire
des couches colorimétriques, et c'est ce qui limite en pratique la mémoire
nécessaire).






Le sam. 24 oct. 2020 à 19:21, Yves P.  a écrit :

> Concernant les rendus spécialisés, François avait démarré une version
> vectorielle du rendu CyclOSM (limité aux infrastructures uniquement),
> cf. https://2metz.fr/blog/cyclosm-vector-tiles/.
>
>
>
> Pourrait-on capitaliser dessus ?
>
>
> Je viens de voir un rendu vélo Polonais
>  (bitmap).
>
> En modifiant seulement le style, il doit être possible de réutiliser les
> tuiles CyclOSM vectorielles.
>
> __
> 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: [OSM-talk-fr] Nouveau rendu osm.fr

2020-10-24 Par sujet Yves P. 
> Concernant les rendus spécialisés, François avait démarré une version
> vectorielle du rendu CyclOSM (limité aux infrastructures uniquement),
> cf. https://2metz.fr/blog/cyclosm-vector-tiles/ 
> .


> Pourrait-on capitaliser dessus ?

Je viens de voir un rendu vélo Polonais 
 (bitmap).

En modifiant seulement le style, il doit être possible de réutiliser les tuiles 
CyclOSM vectorielles.

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

Re: [OSM-talk-fr] Nouveau rendu osm.fr

2020-10-24 Par sujet Yves P. 
> Non, mon idée est de gardée une base commune à périmètre identique de ce que 
> ça fait déjà, pour garder ça léger et réutilisable.
+1

Exemple d'affichage sur 2 sites web différents :

++--++
| Couche ferroviaire | Couche Cyclo | Couche point d'eau |
++--++
|   Couche "fond de plan" (OpenMapTiles) |
++

 ++
 | Couche point d'eau |
+++
| Couche ferroviaire |Couche Cyclo|
+++
|  Couche "fond de plan" (OpenMapTiles)   |
+-+


> Mais d'avoir des layers de données que l'on peut rajouter et combiner. J'en 
> ai fait deux en ce sens, les arbres (1 layer) et l'infra vélo (2 layers).

ça pourrait donner ça :
+-+
|   Couche Arbres |
+-+
|   Couche  Cyclo |
+-+
|  Couche "fond de plan" (OpenMapTiles)   |
+-+

> 
> 
>> Concernant les rendus spécialisés, François avait démarré une version
>> vectorielle du rendu CyclOSM (limité aux infrastructures uniquement),
>> cf. https://2metz.fr/blog/cyclosm-vector-tiles/. Pourrait-on capitaliser
>> dessus ?
> 
> J'ai javais vu ça et le tien, le mien étant plutôt une expérience, mais je 
> trouve le résultat plutôt pas trop mal et je m'en sert moi même.

Plutôt que de faire une couche de tuiles par "POI", on pourrait avec les points 
d'eau inclus dans la couche cyclo.

Les points d'eau sont déjà dans la couche OpenMapTile 

Je viens de voir ça avec CyclOSM vector : cliquer sur l'icône carte en haut à 
droite. Tous les objets sont afficher et une bulle affiche les attributs

https://cyclosm.2metz.fr/static/index.html#19.11/48.8548288/2.3455783
https://projetdumois.fr/projects/2020-09_aed/map#map=19.11/48.8548288/2.3455783
https://www.openstreetmap.org/node/494251394


La couche OpenMapTile indique son nom, son type drinking_water, il manque 
essentiellement l'id OSM… et les autres tags (photos)

Il existe aussi un (plusieurs ?) serveurs de tuiles qui combine plusieurs 
couches à la volée.

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

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

2020-10-24 Par sujet Philippe Verdy 
Le risque me semble bien plus élevé pour la Fondation OSM que pour la
Fondation Mozilla, qui n'a pas à supporter les mêmes frais
d'infrastructure, et a un nombre de soutiens bien plus élevés, aussi bien
au plan financier mondialement, que par le fait que les suites Firefox sont
souvent les seules aussi installées sur les serveurs et stations de travail
Linux, notamment les environnement de bureau virtualisés hébergés dans les
clouds des entreprises, qui donc acceptent aussi de maintenir une
contribution leur apportant aussi un support direct ou via un prestataire.
La Fondation OSM en revanche non seulement a des frais d'infra importants,
mais aussi se met à dépenser sans compter, en croyant que le tapis sur
lequel elle est encore confortablement installé pourra se reconstituer
aussi vite qu'il est dépensé. Il a fallu moins d'un an pour anéantir les
efforts des 10 ans.
Et pourtant la Fondation OSM ne finance pas un projet important pour elle:
la consolidation de son infrastructure pour bâtir un vrai CDN, et sinon
consolider la base de données. Elle en fait trop sur les éditeurs, et tente
maintenant d'opacifier ses prises de décisions et même ses justifications.
elle renforce le rôle dominant ed certains personnes dont la neutralité est
de moins en moins évidente.


Le sam. 24 oct. 2020 à 10:37, Jean-Marc Liotier  a écrit :

> 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.
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

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

2020-10-24 Par sujet 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