Re: [OSM-talk-fr] Affichage d'un name suivant le rendu

[Philippe Verdy]

Le mar. 8 sept. 2020 à 09:24, Christian Quest  a
écrit :

> Le 07/09/2020 à 10:53, osm.sanspourr...@spamgourmet.com a écrit :
> > Salut,
> >
> > Le 07/09/2020 à 10:45, Denis Chenu via Talk-fr -
> > talk-fr@openstreetmap.org a écrit :
> >> Aucune raison de faire les 2.
> >
> > Si, certains systèmes ne traitent qu'un et donc les utilisateurs
> > débutants ajoutent l'autre.
> >
> La plus mauvaise raison selon moi.
>
> Le wiki est clair, pas de double objet, un POI est prioritairement
> surfacique sauf si le wiki indique pour le tag en question qu'il n'est
> que ponctuel... donc si les outils ne savent pas gérer ça, c'est à eux
> d'évoluer.
>

Donc tu te fais une remarque à toi-même concernant le rendu carto français
(celui par défaut sur openstreetmap.fr).


> Quand on met les 2, ça pénalise les outils qui suivent les règles à des
> traitements supplémentaires de dédoublonnage... merci !
>

La "pénalisation" est déjà en place et minime (et même possible puisque
Osmose sait le détecter et je ne pense pas que ça lui demande tant de
travail que ça.


> Il y a aussi le cas des places avec Nominatim et le rendu osm-fr (mais
> > là j'ai indiqué un contournement possible).
>
> Quel problème sur les place=* et le rendu FR ?  Il manque la prise en
> compte des polygones ?
>

Justement c'est bien ça, cette "règle" n'est  pas appliquée; pour s'éviter
d'avoir à gérer des doublons, il ne charge qu'une partie des données
valides et oublient les autres.
Si l'outil DOIT charger à la fois les points et les polygones pour les
mêmes tags, forcément il va devoir détecter et gérer les pseudo-"doublons"
proprement. C'est un phase de validation au même titre que le travail de
préparation et d'intégration dans les contributions d'OSM.

Et il y a des tas de raisons pour lesquelles même ces "doublons" sont
involontaires, notamment:
- des tas de noeuds non trouvés à la position attendue pour une recherche,
qui font qu'ils sont réajoutés
- le cas du serveur de données OSM qui ne charge pas tout (exemple très
régulièrment avec iD il manque des données ou on se retrouve avec une carte
totalement vide, le serveur a tronqué les données retournées (sans produire
aucune erreur, les erreurs qu'on voit dans la console sont essentiellement
celles de chargement des tuiles du fond de carte, des erreurs "mixed
content" sur certains fonds de carte (notamment les tuiles OrthoBD); l'API
de chargement de données n'est pas si stable que ça et les navigateurs ont
également renforcé récemment leur sécurité pour bloquer toute sorte de
choses silencieusement (et accélérer le reste du rendu sans épuiser les
ressources du poste client).
- la plupart des erreurs ne produisent aucun message dans le journal de la
console, des gestionnaires d'exception internes à l'appli les capture pour
ne pas planter l'appli, mais oublient de signaler ne serait-ce que sur la
console (que seuls les utilisateurs avancés vont consulter car la plupart
ne comprennent rien à ce qui y est affiché s'ils ne sont pas "développeurs
web".

Je parlais d'ID mais on a le même problème aussi dans JOSM (où là aussi
tout n'est pas chargé, et c'est même pas un bogue mais "par design"
pusique c'est conçu pour que ce soit l'utilisateur qui demande lui-même les
données) du fait ds limites du serveur OSM.org (divers "quotas"
d'utilisation appliqués silencieusement).

Tout n'est pas parfait, et je ne vois pas comment un rendu conforme peut
valablement se passer de charger les deux types d'objets et éviter une
phase de validation/dédoublonnage pour avoir un rendu correct (et s'il fait
un rendu incorrect, forcément les utilisateurs qui ne voient rien seront
tentés de rajouter à nouveau ce qui parait manquer).

Si le rendu ne fait les choses qu'à moitié, on reporte les problèmes et là
encore c'est fait silencieusement. Et pas la peine de renvoyer alors les
utilisateurs à une "faute" de leur part alors que ce qu'ils font est
parfaitement conforme à ce qui est documenté et ce qu'ils voient (dans les
limites qui lui sont imposées par les outils utilisés). Les "politiques"
d'OSM sont avant tout et en premier lieu à faire appliquer aux outils avant
d'incriminer les utilisateurs qui font du mieux qu'ils peuvent pour la
plupart.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Affichage d'un name suivant le rendu

[Christian Quest]

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

Salut,

Le 07/09/2020 à 10:45, Denis Chenu via Talk-fr -
talk-fr@openstreetmap.org a écrit :

Aucune raison de faire les 2.


Si, certains systèmes ne traitent qu'un et donc les utilisateurs
débutants ajoutent l'autre.


La plus mauvaise raison selon moi.

Le wiki est clair, pas de double objet, un POI est prioritairement 
surfacique sauf si le wiki indique pour le tag en question qu'il n'est 
que ponctuel... donc si les outils ne savent pas gérer ça, c'est à eux 
d'évoluer.


Quand on met les 2, ça pénalise les outils qui suivent les règles à des 
traitements supplémentaires de dédoublonnage... merci !




Il y a aussi le cas des places avec Nominatim et le rendu osm-fr (mais
là j'ai indiqué un contournement possible).


Quel problème sur les place=* et le rendu FR ?  Il manque la prise en 
compte des polygones ?





Donc plusieurs raisons, mais pas de bonnes raisons !

Et là le rôle des utilisateurs expérimentés c'est de proposer des
solutions pour que ce genre de cas ne se présente plus. 



Plus la règle est respectée, plus les outils devront s'adapter... et 
cette règle existe depuis 2009 et n'a jamais été remise en question à ce 
que je sache.


--
Christian Quest - OpenStreetMap France


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

Re: [OSM-talk-fr] Affichage d'un name suivant le rendu

[Philippe Verdy]

C'est justement pour ça que j'ai utilisé le terme "pragmatique" puisque les
outils eux font chacun ce qu'ils veulent (de façon inhomogène) et aucun
n'évolue.
Le "doublon" qui pourrait être vu par certains outils n'en est pas un pour
la plupart (et dans aucun rendu carto actuel). Ceux qui les détecte ne sont
que les outils QA (comm Osmose) qui propose arbitrairement d'un
supprimer un (et les utilisateurs ensuite suppriment celui qu'ils veulent,
donc bel et bien en "taguant pour le rendu" d'un seul même si ça casse les
autres).
Ces doublons en fait ne coûtent rien, car les outils savent déjà les
détecter (ils peuvent donc filtrer tout seul dans la quasi-totalité des
cas: aucune modif n'est donc nécessaire et ce n'est donc pas une "erreur",
mais juste une alerte demandant de vérifier des cas éventuels de mauvaises
attributions, pas de supprimer ce qui est correct mais jugé à tord comme
"superflu" et qui ne coute quasiment rien dans la base).

Où est le "double travail"? Nulle part. En revanche les suppressions
hâtives coutent bien plus en terme de travail (les utilsiateurs ne voient
plus rien, ils vont rajouter à nouveau des POI à leur façon (avec les
autres tags et de nouvelles erreurs), ça n'en finira jamais.

Tant que les rendus utiliseront leurs propres règles sans s'en préoccuper,
l'analyse QA a beau signaler ce qu'elle veut, elle ne résoud rien, elle ne
fait qu'ajouter des signalements totalement inutiles sans solution et qui
ajoutent du travail ou qui viennent noyer les autres résultats plus
importants. D'ailleurs le niveau indiqué dans Osmose (si on parle de lui)
n'a aucune gravité, aucun caractère d'urgence puisque les rendus ne se
pressent pas (des mois ou des années) pour corriger leurs analyses et se
mettre d'accord entre eux.

Cela ne sert à rien de signaler comme de prétendues "erreurs" ce qui n'en
est pas et n'a fait l'objet d'aucun consensus réel.


Le lun. 7 sept. 2020 à 10:54,  a écrit :

> Salut,
>
> Le 07/09/2020 à 10:45, Denis Chenu via Talk-fr -
> talk-fr@openstreetmap.org a écrit :
> > Aucune raison de faire les 2.
>
> Si, certains systèmes ne traitent qu'un et donc les utilisateurs
> débutants ajoutent l'autre.
>
> Il y a aussi le cas des places avec Nominatim et le rendu osm-fr (mais
> là j'ai indiqué un contournement possible).
>
> Donc plusieurs raisons, mais pas de bonnes raisons !
>
> Et là le rôle des utilisateurs expérimentés c'est de proposer des
> solutions pour que ce genre de cas ne se présente plus.
>
> Jean-Yvon
>
>
>
> ___
> 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] Affichage d'un name suivant le rendu

[osm . sanspourriel]

Salut,

Le 07/09/2020 à 10:45, Denis Chenu via Talk-fr -
talk-fr@openstreetmap.org a écrit :

Aucune raison de faire les 2.


Si, certains systèmes ne traitent qu'un et donc les utilisateurs
débutants ajoutent l'autre.

Il y a aussi le cas des places avec Nominatim et le rendu osm-fr (mais
là j'ai indiqué un contournement possible).

Donc plusieurs raisons, mais pas de bonnes raisons !

Et là le rôle des utilisateurs expérimentés c'est de proposer des
solutions pour que ce genre de cas ne se présente plus.

Jean-Yvon



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

Re: [OSM-talk-fr] Affichage d'un name suivant le rendu

[Denis Chenu via Talk-fr]

Bonjour,

Je ne vois aucun intérêt à des règles non suivie ou suivie
partiellement. La seule solution est de suivre les règles quand elles
sont claires et précises (comme c'est le cas ici).

Si l'utilisateur 1 ajoute les points alors que la surface existe.
Un utilisateur ancien ou nouveau qui modifiera la même zone supprimera
ce pints en trop qui ne correspond pas à la règle clair.

Cela fait 2 travail inutile …
Si les règles doivent être changée : c'est faisable, mais cela doit être
un accord total et un correspondre à un processus de décision.

En tant qu'utilisateur depuis peu : je tente de suivre les règles, par
exemple su school : si je connais l'école ou son emprise est claire : je
créé la zone, mais sinon : je ne fait que 1 point. Aucune raison de
faire les 2.

Si chacun suit ses propres règles : la carte n'avancera pas …

Denis


Le 05/09/2020 à 18:00, Philippe Verdy a écrit :
> Osmose signale non pas des "erreurs" mais des choses sur lesquelles on
> doit porter attention. Il propose, n'impose pas, et surtout il FAUT
> faire le travail d'intégration.
>
> Sinon ce n'est pas Osmose mais un bot qui ferait le travail : Osmose
> impose l'intelligence humaine. Et ces propositions ne sont pas
> toujours pertinentes (la quasi totalité des "règles" sont génériques,
> et la cartographie est bourrée d'exceptions partout.
>
> Non je ne me conduirai pas comme un robot (c'est totalement contraire
> à l'esprit d'OSM, les bots sont soumis à des règles très strictes et
> se font régulièrement bloquer ou annuler même s'ils ont été approuvés).
>
> Je pense que tu n'as pas compris ce qu'était un outil de "veille
> qualité" (QA) sur OSM.
>
> Non je ne "bricole" AUCUNE règle, c'est plutôt toi qui veut les
> appliquer de façon impérative (alors que justement il n'y a aucune
> règle impérative (et pour des raisons de performance, un outil ne peut
> pas tout regarder et tout savoir).
>
> Bref ton message est un peu trop anticollaboratif. Ca n'ôte rien à
> l'utilité d'Osmose. Ni le fait que la "règle internationale" n'en est
> en fait justement pas une sur ce sujet. Ce ne sont que de bonnes
> pratiques conseillées. Ici on a deux pratiques conseillées et imposer
> une solution au détriment des autres tout aussi valides (et déjà
> déployées sans en tenir compte) c'est justement ce que j'appelle
> taguer pour le rendu (ici un rendu théorique qui n'existe même pas et
> donc n'a AUCUN consensus actuel qui puisse être démontré).
>
>
>
>
> Le sam. 5 sept. 2020 à 17:43, Christian Quest  > a écrit :
>
>
>>> De: "Philippe Verdy"  
>>> Ben non justement, ce n'est pas "taguer" pour le rendu car les deux
>>> méthodes sont indiquées comme valides et approuvées. Certes il y a
>>> des bogues dans le rendu puisque suivant les cas c'est l'une ou
>>> l'autre méthode qui est visible; mais si on voit les deux c'est
>>> moins grave que ne rien voir du tout.
>
>
> C'est tellement "valide et approuvé" que JOSM signale une erreur
> et osmose a une analyse pour ça aussi...
>
>
> Le 04/09/2020 à 18:19, Vincent de Château-Thierry a écrit :
>
>>  
>> Les 2 méthodes sont valides et approuvées, je suis d'accord. Mais elles 
>> sont mutuellement exclusives : si on en choisit une pour un objet du 
>> terrain, alors il ne faut pas utiliser l'autre pour le même objet. Toujours 
>> le "one feature, one element".
>>  
>
>
> Et oui, l'article
> https://wiki.openstreetmap.org/wiki/One_feature,_one_OSM_element
> est clair à ce sujet pour qui prends la peine de le (re)lire.
>
> "A feature whose position is known, but whose shape is either
> unknown or irrelevant, should appear as a point
>  object with appropriate
> tags."
>
> Donc on met un nœud quand on ne connaît pas l'emprise ou que ça
> n'a pas de sens (ex: une borne kilométrique). L'emprise est donc
> bien considérée comme préférée, le nœud une version dégradée et en
> aucun cas on met les deux en même temps.
>
>
> Pour la partie "bonnes pratiques locales", elles devraient se
> limiter à trancher quand plusieurs façons de faire cohabitent et
> sont acceptées internationalement. Pour moi, une règle ou bonne
> pratique locale devrait être le résultat d'un consensus local qui
> n'a pas pu être obtenu internationalement, mais elles ne devraient
> jamais enfreindre une règle internationale.
>
> Bricoler ses propres règles, les adapter n'est vraiment pas un
> service à rendre à OSM et aux réutilisateurs des données.
>
>
> -- 
> Christian Quest - OpenStreetMap France
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> 

Re: [OSM-talk-fr] Affichage d'un name suivant le rendu

[osm . sanspourriel]

Le 05/09/2020 à 18:00, Philippe Verdy - ver...@gmail.com a écrit :


Osmose signale non pas des "erreurs" mais des choses sur lesquelles on
doit porter attention. Il propose, n'impose pas, et surtout il FAUT
faire le travail d'intégration.


Quand Christian dit qu'une erreur systématique est systématiquement
reportée, de deux choses l'une : soit la règle n'a pas de sens et doit
être changée soit elle s'applique, aux faux positifs près.

Par rapport à la remarque de Christian je parlais des "vrais" POI (Point
of Interest).
Typiquement pour un parking c'est du zonal ou exclusif du ponctuel.
Ponctuel=relatif à un point .

 * /L’électron est une particule *ponctuelle*, à la différence du proton./

Quand je parlais de relation, c'est uniquement quand les deux ont un
sens. Et ça respecte l'unicité. Je pense particulièrement aux place= (le
zonage est utilisé par Nominatim par contre la carte standard affiche
des doublons si on ne travaille pas avec des relations).

Pour les parkings c'est différent, avoir du ponctuel là où on a du
surfacique n'a aucun intérêt (d'ailleurs la définition des allées en
précisant avec le modèle du stationnement le long des voies
parking:lane:*=* pourrait suffire : avoir un petit bout non exploité
n'apporte pas grand chose : ça ferait un modèle intermédiaire).

Pour la difficulté d'exploiter les relations lors du rendu : pourquoi ne
pas utiliser une étape d'analyse des données : si tu veux afficher les
parkings en ponctuel tu prends le centre et tu qualifies son importante
en fonction du nombre de place ou à défaut de sa surface.

Pour les rues dans une associatedStreet tu peux fabriquer une rue
composée des éléments jointifs sur laquelle tu mets le nom et
fictive=yes et tu mets un noname=yes sur les membres street.

Ensuite tu affiches les rues normalement avec les noms le cas échéant et
tu finis par les rues fictives dont tu n'affiches que le nom.

Ça doit permettre d'éviter de répéter le nom de la rue tous les 20 m.

Jean-Yvon

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

Re: [OSM-talk-fr] Affichage d'un name suivant le rendu

[Philippe Verdy]

Osmose signale non pas des "erreurs" mais des choses sur lesquelles on doit
porter attention. Il propose, n'impose pas, et surtout il FAUT faire le
travail d'intégration.

Sinon ce n'est pas Osmose mais un bot qui ferait le travail : Osmose impose
l'intelligence humaine. Et ces propositions ne sont pas toujours
pertinentes (la quasi totalité des "règles" sont génériques, et la
cartographie est bourrée d'exceptions partout.

Non je ne me conduirai pas comme un robot (c'est totalement contraire à
l'esprit d'OSM, les bots sont soumis à des règles très strictes et se font
régulièrement bloquer ou annuler même s'ils ont été approuvés).

Je pense que tu n'as pas compris ce qu'était un outil de "veille qualité"
(QA) sur OSM.

Non je ne "bricole" AUCUNE règle, c'est plutôt toi qui veut les appliquer
de façon impérative (alors que justement il n'y a aucune règle impérative
(et pour des raisons de performance, un outil ne peut pas tout regarder et
tout savoir).

Bref ton message est un peu trop anticollaboratif. Ca n'ôte rien à
l'utilité d'Osmose. Ni le fait que la "règle internationale" n'en est en
fait justement pas une sur ce sujet. Ce ne sont que de bonnes pratiques
conseillées. Ici on a deux pratiques conseillées et imposer une solution au
détriment des autres tout aussi valides (et déjà déployées sans en tenir
compte) c'est justement ce que j'appelle taguer pour le rendu (ici un rendu
théorique qui n'existe même pas et donc n'a AUCUN consensus actuel qui
puisse être démontré).




Le sam. 5 sept. 2020 à 17:43, Christian Quest  a
écrit :

>
> De: "Philippe Verdy"  
>
> Ben non justement, ce n'est pas "taguer" pour le rendu car les deux
> méthodes sont indiquées comme valides et approuvées. Certes il y a
> des bogues dans le rendu puisque suivant les cas c'est l'une ou
> l'autre méthode qui est visible; mais si on voit les deux c'est
> moins grave que ne rien voir du tout.
>
>
> C'est tellement "valide et approuvé" que JOSM signale une erreur et osmose
> a une analyse pour ça aussi...
>
>
> Le 04/09/2020 à 18:19, Vincent de Château-Thierry a écrit :
>
>
> Les 2 méthodes sont valides et approuvées, je suis d'accord. Mais elles sont 
> mutuellement exclusives : si on en choisit une pour un objet du terrain, 
> alors il ne faut pas utiliser l'autre pour le même objet. Toujours le "one 
> feature, one element".
>
>
>
> Et oui, l'article
> https://wiki.openstreetmap.org/wiki/One_feature,_one_OSM_element est
> clair à ce sujet pour qui prends la peine de le (re)lire.
>
> "A feature whose position is known, but whose shape is either unknown or
> irrelevant, should appear as a point
>  object with appropriate tags."
>
> Donc on met un nœud quand on ne connaît pas l'emprise ou que ça n'a pas de
> sens (ex: une borne kilométrique). L'emprise est donc bien considérée comme
> préférée, le nœud une version dégradée et en aucun cas on met les deux en
> même temps.
>
>
> Pour la partie "bonnes pratiques locales", elles devraient se limiter à
> trancher quand plusieurs façons de faire cohabitent et sont acceptées
> internationalement. Pour moi, une règle ou bonne pratique locale devrait
> être le résultat d'un consensus local qui n'a pas pu être obtenu
> internationalement, mais elles ne devraient jamais enfreindre une règle
> internationale.
>
> Bricoler ses propres règles, les adapter n'est vraiment pas un service à
> rendre à OSM et aux réutilisateurs des données.
>
>
> --
> Christian Quest - OpenStreetMap France
>
> ___
> 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] Affichage d'un name suivant le rendu

[Christian Quest]

De: "Philippe Verdy" 
Ben non justement, ce n'est pas "taguer" pour le rendu car les deux
méthodes sont indiquées comme valides et approuvées. Certes il y a
des bogues dans le rendu puisque suivant les cas c'est l'une ou
l'autre méthode qui est visible; mais si on voit les deux c'est
moins grave que ne rien voir du tout.



C'est tellement "valide et approuvé" que JOSM signale une erreur et 
osmose a une analyse pour ça aussi...



Le 04/09/2020 à 18:19, Vincent de Château-Thierry a écrit :

  
Les 2 méthodes sont valides et approuvées, je suis d'accord. Mais elles sont mutuellement exclusives : si on en choisit une pour un objet du terrain, alors il ne faut pas utiliser l'autre pour le même objet. Toujours le "one feature, one element".
  



Et oui, l'article 
https://wiki.openstreetmap.org/wiki/One_feature,_one_OSM_element est 
clair à ce sujet pour qui prends la peine de le (re)lire.


"A feature whose position is known, but whose shape is either unknown or 
irrelevant, should appear as a point 
 object with appropriate tags."


Donc on met un nœud quand on ne connaît pas l'emprise ou que ça n'a pas 
de sens (ex: une borne kilométrique). L'emprise est donc bien considérée 
comme préférée, le nœud une version dégradée et en aucun cas on met les 
deux en même temps.



Pour la partie "bonnes pratiques locales", elles devraient se limiter à 
trancher quand plusieurs façons de faire cohabitent et sont acceptées 
internationalement. Pour moi, une règle ou bonne pratique locale devrait 
être le résultat d'un consensus local qui n'a pas pu être obtenu 
internationalement, mais elles ne devraient jamais enfreindre une règle 
internationale.


Bricoler ses propres règles, les adapter n'est vraiment pas un service à 
rendre à OSM et aux réutilisateurs des données.



--
Christian Quest - OpenStreetMap France

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

Re: [OSM-talk-fr] Affichage d'un name suivant le rendu

[Philippe Verdy]

Ca c'est jsute le point de vue théorique. Rien à voir avec le pragmatisme
qui consiste à s'adapter à ce qu'on peut et sait faire en attendant de
développer mieux.

Ton problème de comptage est un point de vue théorique uniquement qui
oublie de prendre en compte le fait que tu peux parfaitement (et
facilement en plus!) identifier les doublons. C'est une réponse de celui
qui a juste pas envie, pas le courage de le faire. Pourtant c'est facile à
documenter, et utile dans un *long* processus de transition où on n'aura
jamais tout en même temps et tout de suite: c'est illusoire de croire
qu'OSM sera complet, sinon c'est que le monde entier est mort (et n'a donc
plus besoin d'OSM et n'a plus non plus aucun contributeur)!

On en reparlera quand le monde ne sera plus peuplé que de robots et que
l'espèce humaine aura disparu. Personne ne le souhaite ici et en fait on ne
le verra jamais sur OSM, OSM sera mort bien avant ça.

Être pragmatique c'est juste savoir minimiser l'impact en terme de
conséquences, et ici les conséquences sont théoriques (pour un esprit trop
borné à ne pas vouloir voir le reste et qui voudrait se comporter comme un
robot). Mais un humain n'est pas induit en erreur, et on peut parfaitement
apprendre à un robot à se comporter correctement, il faut juste lui dire et
le faire travailler un peu plus, à peine plus en fait car c'est facile à
trouver dans la base).


Le ven. 4 sept. 2020 à 18:20, Vincent de Château-Thierry 
a écrit :

>
> > De: "Philippe Verdy" 
>
> > Ben non justement, ce n'est pas "taguer" pour le rendu car les deux
> > méthodes sont indiquées comme valides et approuvées. Certes il y a
> > des bogues dans le rendu puisque suivant les cas c'est l'une ou
> > l'autre méthode qui est visible; mais si on voit les deux c'est
> > moins grave que ne rien voir du tout.
>
> Les 2 méthodes sont valides et approuvées, je suis d'accord. Mais elles
> sont mutuellement exclusives : si on en choisit une pour un objet du
> terrain, alors il ne faut pas utiliser l'autre pour le même objet. Toujours
> le "one feature, one element".
>
> > Et même hors du rendu (par exemple pour les recherches) cela n'a pas
> > de conséquence: on trouve deux objets pratiquement au même endroit.
>
> Il y a au moins une conséquence : 2 objets pour la même réalité terrain,
> ça fausse les statistiques. Avec un polygone "parking" incluant un point
> "parking" la réponse à la simple question "combien y a t-il de parkings
> dans la commune ?" devient compliquée, alors qu'elle devrait être
> simplement la somme des noeuds "parking" et des polygones "parking" si on
> respecte le principe du "one feature, one element".
>
> vincent
>
> ___
> 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] Affichage d'un name suivant le rendu

[Vincent de Château-Thierry]

> De: "Philippe Verdy" 

> Ben non justement, ce n'est pas "taguer" pour le rendu car les deux
> méthodes sont indiquées comme valides et approuvées. Certes il y a
> des bogues dans le rendu puisque suivant les cas c'est l'une ou
> l'autre méthode qui est visible; mais si on voit les deux c'est
> moins grave que ne rien voir du tout.
 
Les 2 méthodes sont valides et approuvées, je suis d'accord. Mais elles sont 
mutuellement exclusives : si on en choisit une pour un objet du terrain, alors 
il ne faut pas utiliser l'autre pour le même objet. Toujours le "one feature, 
one element".
 
> Et même hors du rendu (par exemple pour les recherches) cela n'a pas
> de conséquence: on trouve deux objets pratiquement au même endroit.

Il y a au moins une conséquence : 2 objets pour la même réalité terrain, ça 
fausse les statistiques. Avec un polygone "parking" incluant un point "parking" 
la réponse à la simple question "combien y a t-il de parkings dans la commune 
?" devient compliquée, alors qu'elle devrait être simplement la somme des 
noeuds "parking" et des polygones "parking" si on respecte le principe du "one 
feature, one element".

vincent

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

Re: [OSM-talk-fr] Affichage d'un name suivant le rendu

[Arnaud Champollion]

Le 30/08/2020 à 21:20, osm.sanspourr...@spamgourmet.com a écrit :
Si par contre tu parles d'objets de nature surfacique telles qu'un 
parking ou un jardin, on est d'accord.


Pour une école je ne sais : tu mets ça sur le landuse ?



Pour une école, je fais un polygone avec amenity=school sur l'emprise de 
l'établissement avec ses bâtiments et surfaces extérieures, par exemple 
https://www.openstreetmap.org/way/483979733







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

Re: [OSM-talk-fr] Affichage d'un name suivant le rendu

[Philippe Verdy]

Et noter que le "POI" ne désignent pas la cartographie physique, ils sont
juste des points au centre d'une aire (de taille non spécifiée) qui n'est
pas délimitée nécessairement par un objet physique (un seul batiment,
plusieurs, des services annexes rattachés, y compris leurs boites aux
lettres qui peuvent être ailleurs, et qui ne couvrent pas non plus leur
aire d'influence ou de chalandise et ne dit souvent rien de leur importance
relative vis à vis de leur environnement économique ou social)

Hors on ne peut pas taguer comme un POI tous les objets physiques et les
découper ou regroupe ne fait souvent pas de sens non plus car on n'est pas
capable de faire une réelle délimitation: c'est pour ça qu'on les réduit à
un seule noeud assez souvent. Pourtant ils peuvent être bien plus grands et
avoir eux-même une structure interne plus fine (exemple: une école ou une
zone hospitalière avec divers services, et même pas mal de zones
commerciales: l'usage des lieux n'est pas forcément unique non plus et on
ne peut pas séparer géographiquement ces services qui pourtant y sont
situés et se recouvrent partiellement, que ce soit territorialement ou dans
le temps).

On ne peut donc pas déprécier une méthode plutôt qu'une autre.
Malheureusement, traiter les points et les polygones/surfaces, c'est très
différent dans les rendus. Et pour créer des filtres efficaces, ce n'est
pas facile car on ne les verra pas toujours simultanément dans toute
sélection d'objets depuis la base (au plan purement géométrique, les points
sont trop petits ils peuvent être oubliés, les surfaces sinon ne sont
qu'indicatives le plus souvent et parfois trop grande relativement à
l'importance d'autres objets voisins ou qui y sont inclus: on ne peut pas
figer ces règles de filtrage dans les rendus, donc autant permettre cette
flexibilité: c'est aux rendus qui voient les deux types d'objets de mieux
gérer les filtres au cas où il voient des doublons, et ils n'en voient pas
toujours puisqu'ils ne sélectionnent pas tous la même chose).

Enfin les POI tagués comme simple noeud n'ont toujours indication d'une
taille relative (au moins un rayon), et leur "importance" relative par
rapport au reste ne peut pas non plus être décrétée par le système de
tagging, sinon on aurait partout le même carte unique dans tous les rendus,
les mêmes filtres appliqués à tous les niveaux de zopom, et trop de détail
visibles pour tous les usages qui n'en ont pourtant pas besoin: ce qu'on
ferait serit de recréer une carte "à la Google" avec ses critères imposés
ou téléguidés par des choix externes (ou des politiques commerciales selon
les intérêts des autres et pas du visiteur réutilisateur; OSM serait
beauoup moins riche).

Le ven. 4 sept. 2020 à 17:25, Philippe Verdy  a écrit :

> Ben non justement, ce n'est pas "taguer" pour le rendu car les deux
> méthodes sont indiquées comme valides et approuvées. Certes il y a des
> bogues dans le rendu puisque suivant les cas c'est l'une ou l'autre méthode
> qui est visible; mais si on voit les deux c'est moins grave que ne rien
> voir du tout.
>
> Et même hors du rendu (par exemple pour les recherches) cela n'a pas de
> conséquence: on trouve deux objets pratiquement au même endroit.
>
> C'est similaire à d'autres objets où on tague les deux (y compris les
> "labels" qui ont été utilisés et sont encore approuvés dans les relations
> boundary même si on n'en a plus besoin pour les rendus les plus courants ni
> pour les recherches pour les outils classiques comme Nominatim. Ce qui doit
> être changé (ou corrigé) c'est ce que doivent faire les rendus au cas où
> ils trouvent les deux objets (de type différents) au même endroit et la
> façon dont ils gèrent les priorités d'affichage (car de toute façon ils
> font toujours des choix, ils ont tous des filtres et ce sont ces filtres
> qui sont à régler pour eux-mêmes, même si les autres rendus en ont encore
> besoin puisqu'ils ne "voient" qu'une partie des objets).
>
> Rien à voir donc avec "taguer pour le rendu", qui ne désigne que la façon
> de **détourner** des tags prévus pour désigner tout autre chose a fin de
> forcer un affichage. Ce n'est pas du tout le cas ici: les deux
> méthodes sont approuvées. Et il n'a pas été décidé d'en déprécier l'une
> pour l'autre.
>
>
> Le ven. 4 sept. 2020 à 17:01, Vincent de Château-Thierry 
> a écrit :
>
>> Bonjour,
>>
>> > De: "Philippe Verdy" 
>>
>> > Ce rappel était inutile. Ce sont deux objets de nature différente
>> > même s'ils ont le même nom mais pas la même fonction. Et ce
>> > "doublon" n'est pas gênant: si on crée une surface délimitée par un
>> > polygone, ce n'est pas un noeud de plus qui change la donne en terme
>> > de volumétrie et il n'y a pas d'ambiguité réelle.
>>
>> Dans ton précédent mail tu dis : "un point parking trouvé dans une
>> surface parking" donc on parle bien de 2 objets décrivant la même réalité
>> sur le terrain. Leur nature géométrique est différente mais ce sont bien
>> des doublons sémantiques, chose qu'on cherche à 

Re: [OSM-talk-fr] Affichage d'un name suivant le rendu

[Philippe Verdy]

Ben non justement, ce n'est pas "taguer" pour le rendu car les deux
méthodes sont indiquées comme valides et approuvées. Certes il y a des
bogues dans le rendu puisque suivant les cas c'est l'une ou l'autre méthode
qui est visible; mais si on voit les deux c'est moins grave que ne rien
voir du tout.

Et même hors du rendu (par exemple pour les recherches) cela n'a pas de
conséquence: on trouve deux objets pratiquement au même endroit.

C'est similaire à d'autres objets où on tague les deux (y compris les
"labels" qui ont été utilisés et sont encore approuvés dans les relations
boundary même si on n'en a plus besoin pour les rendus les plus courants ni
pour les recherches pour les outils classiques comme Nominatim. Ce qui doit
être changé (ou corrigé) c'est ce que doivent faire les rendus au cas où
ils trouvent les deux objets (de type différents) au même endroit et la
façon dont ils gèrent les priorités d'affichage (car de toute façon ils
font toujours des choix, ils ont tous des filtres et ce sont ces filtres
qui sont à régler pour eux-mêmes, même si les autres rendus en ont encore
besoin puisqu'ils ne "voient" qu'une partie des objets).

Rien à voir donc avec "taguer pour le rendu", qui ne désigne que la façon
de **détourner** des tags prévus pour désigner tout autre chose a fin de
forcer un affichage. Ce n'est pas du tout le cas ici: les deux
méthodes sont approuvées. Et il n'a pas été décidé d'en déprécier l'une
pour l'autre.


Le ven. 4 sept. 2020 à 17:01, Vincent de Château-Thierry 
a écrit :

> Bonjour,
>
> > De: "Philippe Verdy" 
>
> > Ce rappel était inutile. Ce sont deux objets de nature différente
> > même s'ils ont le même nom mais pas la même fonction. Et ce
> > "doublon" n'est pas gênant: si on crée une surface délimitée par un
> > polygone, ce n'est pas un noeud de plus qui change la donne en terme
> > de volumétrie et il n'y a pas d'ambiguité réelle.
>
> Dans ton précédent mail tu dis : "un point parking trouvé dans une surface
> parking" donc on parle bien de 2 objets décrivant la même réalité sur le
> terrain. Leur nature géométrique est différente mais ce sont bien des
> doublons sémantiques, chose qu'on cherche à éviter, cf le lien indiqué par
> Christian.
>
> > Et j'avais indiqué "de façon pragmatique". On sait qu'on a des
> > limites et qu'elles ne vont pas se régler tout de suite. Je préfère
> > nettement avoir deux objets (de nature différents mais positionnés
> > presque au même endroit, cela n'induit personne en erreur) que de
> > n'en voir aucun de façon aléatoire ou ne pas le trouver si on
> > cherche avec les outils qu'on a actuellement (en attendant qu'ils
> > soient corrigés).
>
> Le fait de "voir ou pas" les objets est de la responsabilité du logiciel
> qui les affiche, ça n'est pas au contenu lui-même de palier les limites des
> chartes graphiques. Sinon ça revient à tagguer pour le rendu.
>
> vincent
>
> ___
> 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] Affichage d'un name suivant le rendu

[Vincent de Château-Thierry]

Bonjour,

> De: "Philippe Verdy" 
 
> Ce rappel était inutile. Ce sont deux objets de nature différente
> même s'ils ont le même nom mais pas la même fonction. Et ce
> "doublon" n'est pas gênant: si on crée une surface délimitée par un
> polygone, ce n'est pas un noeud de plus qui change la donne en terme
> de volumétrie et il n'y a pas d'ambiguité réelle.

Dans ton précédent mail tu dis : "un point parking trouvé dans une surface 
parking" donc on parle bien de 2 objets décrivant la même réalité sur le 
terrain. Leur nature géométrique est différente mais ce sont bien des doublons 
sémantiques, chose qu'on cherche à éviter, cf le lien indiqué par Christian.

> Et j'avais indiqué "de façon pragmatique". On sait qu'on a des
> limites et qu'elles ne vont pas se régler tout de suite. Je préfère
> nettement avoir deux objets (de nature différents mais positionnés
> presque au même endroit, cela n'induit personne en erreur) que de
> n'en voir aucun de façon aléatoire ou ne pas le trouver si on
> cherche avec les outils qu'on a actuellement (en attendant qu'ils
> soient corrigés).

Le fait de "voir ou pas" les objets est de la responsabilité du logiciel qui 
les affiche, ça n'est pas au contenu lui-même de palier les limites des chartes 
graphiques. Sinon ça revient à tagguer pour le rendu.

vincent

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

Re: [OSM-talk-fr] Affichage d'un name suivant le rendu

[Philippe Verdy]

Le ven. 4 sept. 2020 à 09:38, Christian Quest  a
écrit :

> Le 01/09/2020 à 22:50, Philippe Verdy a écrit :
> > De façon pragmatique on peut admettre d'avoir simplement les deux (un
> > noeud et une surface)
>
> C'est une très mauvaise pratique, car cela crée 2 objets dans la base
> pour un seul sur le terrain.
>
> Petit rappel :
> https://wiki.openstreetmap.org/wiki/One_feature,_one_OSM_element


Ce rappel était inutile. Ce sont deux objets de nature différente même
s'ils ont le même nom mais pas la même fonction. Et ce "doublon" n'est pas
gênant: si on crée une surface délimitée par un polygone, ce n'est pas un
noeud de plus qui change la donne en terme de volumétrie et il n'y a pas
d'ambiguité réelle.

Et j'avais indiqué "de façon pragmatique". On sait qu'on a des limites et
qu'elles ne vont pas se régler tout de suite. Je préfère nettement avoir
deux objets (de nature différents mais positionnés presque au même endroit,
cela n'induit personne en erreur) que de n'en voir aucun de façon aléatoire
ou ne pas le trouver si on cherche avec les outils qu'on a actuellement (en
attendant qu'ils soient corrigés).

Si la correction a lieu il sera toujours très facile plus tard de nettoyer
ces quelques "doublons", faciles à trouver en plus.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Affichage d'un name suivant le rendu

[Christian Quest]

Le 01/09/2020 à 22:50, Philippe Verdy a écrit :
De façon pragmatique on peut admettre d'avoir simplement les deux (un 
noeud et une surface)


C'est une très mauvaise pratique, car cela crée 2 objets dans la base 
pour un seul sur le terrain.


Petit rappel : 
https://wiki.openstreetmap.org/wiki/One_feature,_one_OSM_element



En revanche il peut être utile de conserver certains tags spécifiques 
(pas tous) comme la délimitation des places réservées aux handicapés, 
ou les parkings 2 roues sans avoir besoin d'afficher leur nom en 
doublon visible.


amenity=parking_space pour indiquer les places (en ponctuel ou 
surfacique), à ne pas confondre avec amenity=parking qui décrit 
l'ensemble du parking.



--
Christian Quest - OpenStreetMap France


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

Re: [OSM-talk-fr] Affichage d'un name suivant le rendu

[Philippe Verdy]

De façon pragmatique on peut admettre d'avoir simplement les deux (un noeud
et une surface), sans aucune relation, et faire en sorte que cela ne
s'affiche pas deux fois (un point parking trouvé dans une surface parking
peut être éliminé, peu importe si tous les autres tags dont le nom ne sont
pas identiques, on n'affichera qu'un seul nom (peut importe lequel même si
ça diverge un peu), en fusionnant "intelligemment" les tags trouvés (si
nécessaire on peut faire un log d'erreurs pour signaler les valeurs en
conflit même si on n'en retient qu'une arbirtrairement sur le rendu).

En revanche il peut être utile de conserver certains tags spécifiques (pas
tous) comme la délimitation des places réservées aux handicapés, ou les
parkings 2 roues sans avoir besoin d'afficher leur nom en doublon visible.

Dans tous les cas, pas besoin de label ni de relation.

Attention dans certains cas il y a des places réservées de façon
privées dans les parkings public (exemples: places réservées au personnel
porteurs d'une carte spécial, ou places protégées par une barrière ou un
plot levant (à clé ou télécommandé).En principe on devrait délimiter ces
places avec une autre surface séparée indiquant leur caractère privé. mais
si cela ne concerne qu'un ou deux emplacements, il y a un tag particulier
pour ces emplacements individuels placés dans un parking plus grand.

De même pour les aires de stationnement pour camions, bus et véhicules
longs ou à remorque (qui ne leur sont pas forcément réservés mais ces
véhicules ne peuvent pas se garer dans les plus petits emplacements). Ce
cas se présente notamment sur les aires d'autoroutes. Il peut arriver que
les emplacements pour véhicules de tourisme soient pleins et qu'il aillent
s'aligner plus loin sur les aires pour véhicule longs, mais en principe on
devrait éviter de laisser libre les emplacements longs partiellement
occupés, afin de laisser de la place pour les autres véhicules longs (comme
ces places sont souvent plus éloignées des points de service, naturellement
les véhicules remplissent d'abord les emplacements les plus proches et se
regroupent). Cela pose rarement des problèmes. Si c'est un stationnement
pour le repos, il y a des emplacements mieux adaptés que ces grandes places
souvent trop lumineuses et sans craindre de se faire déranger par des
camions ou des cars...



Le mar. 1 sept. 2020 à 09:58, Christian Quest  a
écrit :

> Le 30/08/2020 à 21:20, osm.sanspourr...@spamgourmet.com a écrit :
>
> Le 30/08/2020 à 09:46, Christian Quest - cqu...@openstreetmap.fr a écrit :
>
> Bien souvent dans mes contributions, je remet des POI en surfacique alors
> qu'ils ne sont que ponctuels, la première étape consistant souvent à migrer
> un tag sur un bâtiment entier, mais la seconde, quand on le peut, consiste
> à délimiter plus largement l'emprise de tel ou tel POI. Cas typique: les
> écoles !
>
> J'allais dire ouille.
>
> Car les *points* d'intérêt  ne sont pas des *surfaces* par définition.
>
> Tout dépend de la définition... point d'intérêt ou ponctuel d'intérêt ;)
>
> Attention aussi à la traduction simpliste qu'on a fait de POI, non ?
>
> Réduire un POI à un unique point est quand même une façon minimaliste de
> décrire un lieu rarement ponctuel sur le terrain. J'ai toujours considéré
> qu'un ponctuel c'était bien pour apporter une info minimale, mais qu'une
> surface apporte bien plus d'infos (où commence le POI, où s'arrête-t-il,
> est-il étendu ou pas, etc).
>
>
> Si par contre tu parles d'objets de nature surfacique telles qu'un parking
> ou un jardin, on est d'accord.
>
> Pour une école je ne sais : tu mets ça sur le landuse ?
>
> Oui, plutôt, quand on peut déterminer l'emprise sinon où mettre le
> ponctuel à part de façon arbitraire ?
>
>
> Ceci dit souvent quand le PI est surfacique des cartographes (avec
> StreetComplete et autres GoMap) l'ajoutent en ponctuel car leur appli ne
> montre que les PI ponctuels :-(.
>
> Faire un rendu ponctuel peut se comprendre, un parking aura un "P" vers le
> centroid, éventuellement son emprise aura un style surfacique en plus. Le
> nom doit être placé quelque part, il est donc ponctuel lui aussi mais
> déterminé à partir de l'emprise.
>
>
> La seule solution propre compatible avec les deux mais lourdingue pour les
> petits objets c'est de faire une relation type=boundary avec le nœud comme
> label et le contour en outer comme ici
> .
>
> Bof bof bof... que de complexité pour un usage quasi nul des rôles label,
> d'autant plus que remonter dans les relations est un exercice délicat pour
> les moteurs de rendu.
>
> Dans ce cas précis, je ne trouve pas que la position pour ce label soit
> bien choisie. Elle est trop proche de la route, donc collision avec le nom
> de celle-ci (identique d'ailleurs).
>
> --
> Christian Quest - OpenStreetMap France
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> 

Re: [OSM-talk-fr] Affichage d'un name suivant le rendu

[Christian Quest]

Le 30/08/2020 à 21:20, osm.sanspourr...@spamgourmet.com a écrit :

Le 30/08/2020 à 09:46, Christian Quest - cqu...@openstreetmap.fr a écrit :
Bien souvent dans mes contributions, je remet des POI en surfacique 
alors qu'ils ne sont que ponctuels, la première étape consistant 
souvent à migrer un tag sur un bâtiment entier, mais la seconde, 
quand on le peut, consiste à délimiter plus largement l'emprise de 
tel ou tel POI. Cas typique: les écoles !


J'allais dire ouille.

Car les *points* d'intérêt  ne sont pas des *surfaces* par définition.


Tout dépend de la définition... point d'intérêt ou ponctuel d'intérêt ;)

Attention aussi à la traduction simpliste qu'on a fait de POI, non ?

Réduire un POI à un unique point est quand même une façon minimaliste de 
décrire un lieu rarement ponctuel sur le terrain. J'ai toujours 
considéré qu'un ponctuel c'était bien pour apporter une info minimale, 
mais qu'une surface apporte bien plus d'infos (où commence le POI, où 
s'arrête-t-il, est-il étendu ou pas, etc).



Si par contre tu parles d'objets de nature surfacique telles qu'un 
parking ou un jardin, on est d'accord.


Pour une école je ne sais : tu mets ça sur le landuse ?

Oui, plutôt, quand on peut déterminer l'emprise sinon où mettre le 
ponctuel à part de façon arbitraire ?



Ceci dit souvent quand le PI est surfacique des cartographes (avec 
StreetComplete et autres GoMap) l'ajoutent en ponctuel car leur appli 
ne montre que les PI ponctuels :-(.


Faire un rendu ponctuel peut se comprendre, un parking aura un "P" vers 
le centroid, éventuellement son emprise aura un style surfacique en 
plus. Le nom doit être placé quelque part, il est donc ponctuel lui 
aussi mais déterminé à partir de l'emprise.



La seule solution propre compatible avec les deux mais lourdingue pour 
les petits objets c'est de faire une relation type=boundary avec le 
nœud comme label et le contour en outer comme ici 
.


Bof bof bof... que de complexité pour un usage quasi nul des rôles 
label, d'autant plus que remonter dans les relations est un exercice 
délicat pour les moteurs de rendu.


Dans ce cas précis, je ne trouve pas que la position pour ce label soit 
bien choisie. Elle est trop proche de la route, donc collision avec le 
nom de celle-ci (identique d'ailleurs).



--
Christian Quest - OpenStreetMap France

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

Re: [OSM-talk-fr] Affichage d'un name suivant le rendu

[deuzeffe]

Bonjour,

Merci à tous ceux qui ont pris la peine de répondre à la question posée 
de façon argumentée, explicative et dans le thème.


Le 30/08/2020 à 09:46, Christian Quest a écrit :

Le 30/08/2020 à 08:29, Arnaud Champollion a écrit :
Sinon, est-ce qu'ajouter un short_name=Jardin J. d’Albret (en 
abréviant le prénom) peut permettre aux rendus qui l'utilisent de le 
substituer en cas de manque de place ? 


J'ai rajouté un short_name : ça ne change rien.

Aux zooms élevé, 'est bien à cause de la fontaine située quasiment au 
centroid du jardin que le nom ne trouve pas sa place.


C’est donc bien un problème d'encombrement stérique. Pas grave, au moins 
j'ai ma réponse :)


Et pas la peine de torturer les feuilles de style s'il y a de gros 
risque d'effet de bord...


En revanche, je suis persuadée avoir rencontré/vu le même problème il y 
a quelques semaines mais inversé (le jardin avec fontaine avait son nom 
et pas l'autre). Je cherche donc s'il y a "quelque part" un outil de 
rendu à la "OSM Then and Now" mais en précisant la date de Now (chez P. 
Neis, peut-être ? Pas encore regardé).


--
deuzeffe, qui sait enfin pourquoi ça pas marche ^^


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

Re: [OSM-talk-fr] Affichage d'un name suivant le rendu

[osm . sanspourriel]

Le 30/08/2020 à 09:46, Christian Quest - cqu...@openstreetmap.fr a écrit :

Bien souvent dans mes contributions, je remet des POI en surfacique
alors qu'ils ne sont que ponctuels, la première étape consistant
souvent à migrer un tag sur un bâtiment entier, mais la seconde, quand
on le peut, consiste à délimiter plus largement l'emprise de tel ou
tel POI. Cas typique: les écoles !


J'allais dire ouille.

Car les *points* d'intérêt  ne sont pas des *surfaces* par définition.

Si par contre tu parles d'objets de nature surfacique telles qu'un
parking ou un jardin, on est d'accord.

Pour une école je ne sais : tu mets ça sur le landuse ?

Ceci dit souvent quand le PI est surfacique des cartographes (avec
StreetComplete et autres GoMap) l'ajoutent en ponctuel car leur appli ne
montre que les PI ponctuels :-(.

La seule solution propre compatible avec les deux mais lourdingue pour
les petits objets c'est de faire une relation type=boundary avec le nœud
comme label et le contour en outer comme ici
.

Jean-Yvon

Jean-Yvon

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

Re: [OSM-talk-fr] Affichage d'un name suivant le rendu

[Philippe Verdy]

Il y a un effet de bord quand on passe du POI (noeud) au surfacique
(batiment). Sur le rendu OSM standard cela fait très souvent disparaitre le
nom et l"icone (même si le bâtiment a tous les tags nécessaires en plus du
building=*).

J'ai vu le cas de deux bâtiments mitoyens, l'un avec un seul service, tagué
en surfacique sur le batiment, l'autre non tagué sur son batiment similaire
car il y avait deux POIs dessus; résultat: disparition du nom dur le
premier batiment (à tous les niveaux de zoom, même quand il y a
largement la place), mais les deux noeuds sur le bâtiment voisins affichés
avec leur nom et leur icône.

Mais si on passe au rendu OSM.fr, on constate exactement l"inverse !

Bref les choix faits dans l'OSMcarto d'OSM.org et ceux faits dans le rendu
OMSfr sont incompatibles: on ne peut pas taguer pour les deux, donc on
tague forcément pour un. Mais étant donné les mauvaises performances
(serveur trop limité en ressources) de la carto OSMfr, beaucoup font le
choix de garder la solution qui marche avec le rendu OSM.org.

Et là on ne parle que des rendus en tuiles bitmap. Les rendus vectoriels (y
compris les exports pour appareils navigateurs GPS) s'en sortent mieux,
même si au final c'est pas aussi joli car le rendu vectoriel est limité par
la capacité des navigateurs web actuels notamment sur mobiles, et ils
fontrent beaucoup plus de choses (mais il serait temps d'étendre cela et
songer à déprécier à l'avenir les tuiles bitmaps, qui sont difficilement
navigables/orientables et leur mise à jour est lente et très coûteuse (d'où
de sérieux problèmes de "scalability" pour pouvoir offrir des carte à plein
de monde, sauf en hébergeant ce service chez Mapbox).

Même Wikimedia a du mal à générer et servir correctement les tuiles qu'il
fabrique pour ses wikis: nombre de cartes affichent trop de tuiles grises
qui mettent un temps fou à s'afficher ou parfois ne s'affichent jamais,
même sans aller bien loin au niveau des zooms avant.

Les rendus vectoriels fonctionnent bien aujourd'hui (en témoigne les rendus
pour navigateurs GPS embarqués, ou les jeux comme Microsoft Flight
Simulator car même s'ils filtrent les éléments à afficher ils ajoutent pas
mal de choses pour enrichir le visuel, mais on peut voir aussi un
rendu vectoriel fonctionnel et pas aussi "filtrant" chez Mapbox aussi sans
subir les choix éditoriaux du concepteur du jeu poru ce qu'ils décident de
rendre visibles; si les jeux utilisent maintenant OSM, c'est parce que
c'est une carte riche en diversité et que cela sert de base plus naturelle
que les cartes générées par des algos artificiels qui ont le défaut de
reproduire trop souvent les mêmes patterns un peu partout, OSM a l'avantage
de la diversité et de l'unicité, même si on peut ensuite enrichir avec des
données générées ou en utilisant des extraits cartographiques à certains
endroits comme base de modification et "combiner" des zones sans reproduire
les patterns, le jeu gagne beaucoup en intérêt car il y a plus de choses à
découvrir et l'expérience se renouvelle constamment, ce qui évite l'ennui,
les tactiques toutes faites connues des joueurs plus expérimentés, et plus
d'équité entre joueurs).

Le dim. 30 août 2020 à 09:47, Christian Quest  a
écrit :

> Le 30/08/2020 à 08:29, Arnaud Champollion a écrit :
> > Le 29/08/2020 à 20:13, osm.sanspourr...@spamgourmet.com a écrit :
> >> Donc les rendus affichant les fontaines n'ont pas la place d'afficher le
> >> nom (en fait à un certain niveau de zoom en ne centrant pas ce serait
> >> possible). Les autres si.
> >
> > Ou alors il faudrait que le rendu décale le nom là où c'est possible.
> > Dans le cas présent, au zoom 19 et peut-être 18, un humain saurait le
> > décaler au sud de la fontaine, quitte à manger sur les chemins.
> >
> > J'imagine que c'est autre chose de traduire ça en algorithme pour un
> > rendu.
> >
> > Sinon, est-ce qu'ajouter un short_name=Jardin J. d’Albret (en
> > abréviant le prénom) peut permettre aux rendus qui l'utilisent de le
> > substituer en cas de manque de place ?
>
>
> Aux zooms élevé, 'est bien à cause de la fontaine située quasiment au
> centroid du jardin que le nom ne trouve pas sa place.
>
> Pour le zoom 17, il pourrait tenir, mais le nom du parking est sûrement
> placé avant (les amenity=* placés en priorité).
>
> Décaler les objets est possible, il y a un mécanisme dans mapnik qui le
> permet, mais cela a des effets de bord... au bord des tuiles. Le
> décalage pouvant se faire sur une tuile à cause d'un objet déjà placé,
> mais pas sur la voisine, l'objet étant trop loin pour être pris en
> compte comme déjà placé.
>
> C'est TRES compliqué de générer de façon purement algorithmique un rendu
> auto-adaptatif. mapnik a des mécanismes limités à ce niveau.
> (https://carto.com/developers/styling/cartocss/#text-placements-string).
>
> Dans le chantier toujours en cours sur la feuille de style, j'utilise de
> plus en plus la taille des objets pour décider d'afficher leur nom et
> ajuster la taille du texte. 

Re: [OSM-talk-fr] Affichage d'un name suivant le rendu

[Christian Quest]

Le 30/08/2020 à 08:29, Arnaud Champollion a écrit :

Le 29/08/2020 à 20:13, osm.sanspourr...@spamgourmet.com a écrit :

Donc les rendus affichant les fontaines n'ont pas la place d'afficher le
nom (en fait à un certain niveau de zoom en ne centrant pas ce serait
possible). Les autres si.


Ou alors il faudrait que le rendu décale le nom là où c'est possible.
Dans le cas présent, au zoom 19 et peut-être 18, un humain saurait le 
décaler au sud de la fontaine, quitte à manger sur les chemins.


J'imagine que c'est autre chose de traduire ça en algorithme pour un 
rendu.


Sinon, est-ce qu'ajouter un short_name=Jardin J. d’Albret (en 
abréviant le prénom) peut permettre aux rendus qui l'utilisent de le 
substituer en cas de manque de place ? 



Aux zooms élevé, 'est bien à cause de la fontaine située quasiment au 
centroid du jardin que le nom ne trouve pas sa place.


Pour le zoom 17, il pourrait tenir, mais le nom du parking est sûrement 
placé avant (les amenity=* placés en priorité).


Décaler les objets est possible, il y a un mécanisme dans mapnik qui le 
permet, mais cela a des effets de bord... au bord des tuiles. Le 
décalage pouvant se faire sur une tuile à cause d'un objet déjà placé, 
mais pas sur la voisine, l'objet étant trop loin pour être pris en 
compte comme déjà placé.


C'est TRES compliqué de générer de façon purement algorithmique un rendu 
auto-adaptatif. mapnik a des mécanismes limités à ce niveau. 
(https://carto.com/developers/styling/cartocss/#text-placements-string).


Dans le chantier toujours en cours sur la feuille de style, j'utilise de 
plus en plus la taille des objets pour décider d'afficher leur nom et 
ajuster la taille du texte. Postgresql calcule ainsi approximativement 
la surface en pixels de l'objet pour faciliter la prise en compte par la 
feuille de style. Cela permet aussi de simplifier la feuille de style 
car je faisais cela avant avec des tests en fonction du niveau de zoom 
et de la taille 'brute' des polygones.



Pour répondre à deuzeffe... oui osmfr-cartoss est un fork de 
openstreetmap-carto, mais un fork qui date de 2012 et qui largement 
divergé depuis.


Les fontaines ne sont pas rendues sur les autres styles, ou alors à des 
zoom plus élevés ou avec des priorités différentes.



Plus globalement, devrait-on prioriser le mapping des POI en surfacique, 
qu'on peut ordonner par surface contrairement à ceux ponctuels pour 
lesquels il est difficile de déterminer leur importante relative sur une 
carte ? Je pense que oui. Cela permettrait ici d'avoir le nom du jardin 
en zoom 17 avant celui du parking, mais en zoom 18 et suivant, l’icône 
de la fontaine viendrait reprendre sa place (les icônes sont placées 
avant les noms car elles prennent moins de place).


Bien souvent dans mes contributions, je remet des POI en surfacique 
alors qu'ils ne sont que ponctuels, la première étape consistant souvent 
à migrer un tag sur un bâtiment entier, mais la seconde, quand on le 
peut, consiste à délimiter plus largement l'emprise de tel ou tel POI. 
Cas typique: les écoles !


--
Christian Quest - OpenStreetMap France


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

Re: [OSM-talk-fr] Affichage d'un name suivant le rendu

[Arnaud Champollion]

Le 29/08/2020 à 20:13, osm.sanspourr...@spamgourmet.com a écrit :

Donc les rendus affichant les fontaines n'ont pas la place d'afficher le
nom (en fait à un certain niveau de zoom en ne centrant pas ce serait
possible). Les autres si.


Ou alors il faudrait que le rendu décale le nom là où c'est possible.
Dans le cas présent, au zoom 19 et peut-être 18, un humain saurait le 
décaler au sud de la fontaine, quitte à manger sur les chemins.


J'imagine que c'est autre chose de traduire ça en algorithme pour un rendu.

Sinon, est-ce qu'ajouter un short_name=Jardin J. d’Albret (en abréviant 
le prénom) peut permettre aux rendus qui l'utilisent de le substituer en 
cas de manque de place ?


Arnaud

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

Re: [OSM-talk-fr] Affichage d'un name suivant le rendu

[Philippe Verdy]

Les "landuse=flowerbed" (parterres de fleur, avec une icône de fleur sur
pied et deux feuilles) ne s'affichent pas davantage, ils sont pourtant dans
les presets d'iD.

On en trouve en quantité au pied des bâtiments, dans les giratoires, le
long de rues pour séparer le trottoir ou une bande cyclable, et dans les
parcs et jardins publics.

Si on tague juste pour le rendu on va mettre du "landuse=grass" (surface
d'herbe entretenue), à ne pas confondre avec les "prairies" ou
"'landuse=meadow" (où l'herbage est irrégulier, non tondu avec souvent
divers arbrisseaux ou buissons, des traces de passages d'animaux d'élevage
ou d'engins agricoles et souvent entouré de haies et d'arbres) et pourtant
ce n'est pas la même chose, mais là on aurait un vert saturé (plus clair
toutefois que le vert des bois et forêts).

En revanche les jardins collectifs (dits "familiaux") sont rendus :
"landuse=allotments" (icone d'arrosoir dans iD, rendu en ocre-vert avec un
semis de points).

iD possède même la notion de "parcelle de jardin familiaux" (icône avec une
pousse de plante dans un bac) avec "allotments=plot" (non rendu
apparemment, devrait faire partie d'un "landuse=allotment" qui est déjà
rendu) : pas vraiment des parcelles au sens cadastral car les jardins
familiaux sont dans un ensemble de parcelles cadastrales d'une
collectivité, qui les réalloue en unités bien plus petites et qui peuvent
changer d'une année à l'autre.


Le sam. 29 août 2020 à 19:24, deuzeffe  a écrit :

> Bonjour,
>
> Suivant le rendu consulté, des noms de leisure=garden s'affichent ou pas.
>
> Exemple :
> - soient les deux polygones suivants : 1/
> https://www.openstreetmap.org/way/67527 et 2/
> https://www.openstreetmap.org/way/294951535
> - au nom près, les attributs sont les mêmes (mêmes couples champ/valeur)
> - le nom de 1/ s'affiche mais pas celui de 2/ sur le rendu standard
> https://www.openstreetmap.org/#map=19/45.79721/1.14039 ou le rendu
> osm-fr en dev
>
> https://umap.openstreetmap.fr/fr/map/rendu-fr-en-developpement_483858#19/45.79725/1.14056
> (osmfr-cartocss étant, vu son nom un fork de Mapnik-cartoCSS, ça parait
> logique ?) ;
> - les deux noms s’affichent sur le rendu cyclable standard
> https://www.openstreetmap.org/#map=19/45.79721/1.14039=C et le
> rendu HOT (qui patine un peu, au passage)
> https://www.openstreetmap.org/#map=19/45.79731/1.14025=H
>
>
> Si un ou une wizard voulait bien m'expliquer ces différences de
> comportement : ordre des couches, encombrement stérique des noms,
> "cékomssa", explication toute bête, autres, je l'en remercie d'avance.
>
> --
> deuzeffe, qui aime bien comprendre pourquoi ça pas marche.
>
> ___
> 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] Affichage d'un name suivant le rendu

[osm . sanspourriel]

Le 29/08/2020 à 19:24, deuzeffe - opensm@deuzeffe.org a écrit :

i un ou une wizard voulait bien m'expliquer ces différences de
comportement : ordre des couches, encombrement stérique des noms,
"cékomssa", explication toute bête, autres, je l'en remercie d'avance.


Dans le second cas il y a une fontaine, or les icônes font partie de
l'encombrement stérique, il n'y a pas que les noms.

Donc les rendus affichant les fontaines n'ont pas la place d'afficher le
nom (en fait à un certain niveau de zoom en ne centrant pas ce serait
possible). Les autres si.

Mandrake le Magicien



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

[OSM-talk-fr] Affichage d'un name suivant le rendu

[deuzeffe]

Bonjour,

Suivant le rendu consulté, des noms de leisure=garden s'affichent ou pas.

Exemple :
- soient les deux polygones suivants : 1/ 
https://www.openstreetmap.org/way/67527 et 2/ 
https://www.openstreetmap.org/way/294951535

- au nom près, les attributs sont les mêmes (mêmes couples champ/valeur)
- le nom de 1/ s'affiche mais pas celui de 2/ sur le rendu standard 
https://www.openstreetmap.org/#map=19/45.79721/1.14039 ou le rendu 
osm-fr en dev 
https://umap.openstreetmap.fr/fr/map/rendu-fr-en-developpement_483858#19/45.79725/1.14056 
(osmfr-cartocss étant, vu son nom un fork de Mapnik-cartoCSS, ça parait 
logique ?) ;
- les deux noms s’affichent sur le rendu cyclable standard 
https://www.openstreetmap.org/#map=19/45.79721/1.14039=C et le 
rendu HOT (qui patine un peu, au passage) 
https://www.openstreetmap.org/#map=19/45.79731/1.14025=H



Si un ou une wizard voulait bien m'expliquer ces différences de 
comportement : ordre des couches, encombrement stérique des noms, 
"cékomssa", explication toute bête, autres, je l'en remercie d'avance.


--
deuzeffe, qui aime bien comprendre pourquoi ça pas marche.

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