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
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
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
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à
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
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
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
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
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
> 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
>
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
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
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
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
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
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 :
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
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
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
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,
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
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
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
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
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
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
26 matches
Mail list logo
