Re: [OSM-talk-fr] schéma des addr

2018-01-18 Par sujet Ralf Treinen
Bonsoir,

On Tue, Jan 16, 2018 at 11:43:52PM +, marc marc wrote:

> Donc ma proposition : en cas de nœud-adresse avec une adresse pour un 
> bâtiment, ne pourrait-on pas associer l'adresse au bâtiment soit on 
> mettant le nœud sur le contour ou dans le bâtiment (ou via une relation
> si quelqu'un est motivé pour porter une proposition).

un collegue m'a rappelé il y a quelque temps un très bon principe (si
vous m'excusez l'anglais) :

  simple things should be simple, complicated things should be possible

Une relation (associatedAddress ?) qui associe une adresse à plusieurs
éléments (terrain, des bâtiments, des entrées, des commerces, ...)
me semble assez générale pour couvrir tous les cas que je peux
imaginer. C'est évidement lourd, personne n'a envie de créer
une relation par bâtiment. C'est pourquoi il faut aussi une solution
simple pour la grande majorité des cas qui est : un bâtiment - une
adresse. La solution de Marc de situer dans de tels cas simples l'adresse
au point d'entrée du bâtiment me semble très bien. 

-Ralf.

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


Re: [OSM-talk-fr] schéma des addr

2018-01-16 Par sujet marc marc
Bonjour,

J'ai volontairement mis l'histoire du contact: de côté pour me 
concentrer d'abord sur les adresses des bâtiments/parcelles.

Le 05. 01. 18 à 14:04, Christian Quest a écrit :

> Les deux schémas utilisé pour modéliser les adresses sont largement 
> utilisables, que ce soit avec les relations ou sans.
> ça n'est pas du 1 vers 1.

Je suis bien d'accord avec toi que le relation numéro-bâtiment est x-y 
et non pas 1-1 (même si cela couvre l'écrasante majorité des cas).
Mais justement, trop souvent, ce lien entre l'adresse et ce à quoi elle 
se rapporte est absent dans osm alors qu'il est souvent trivial si tu es 
sur le terrain. cet absence de lien fait qu'il est impossible aux 
applications de détecter que l'adresse est déjà encodée dans osm et cela 
conduit par conséquent à des doublons.

Je prend le cas d'un bâtiment et d'une adresse représenté par un nœud.
dans sa version la plus simple où il y a une relation 1-1 (ce bâtiment 
n'a qu'une adresse et cette adresse ne concerne que ce bâtiment).

- si tu met l'adresse hors du bâtiment, tu n'as aucun lien entre les 2.
Tu (et les applications) en sont réduite à deviner comment les associer.
On voit bien par de nombreux exemples le problème de ce système.
On finit par bouger les nœuds pour "guider la devinette"
Qu-est-ce que cela apporte de garder ce nœud hors du bâtiment ?
Cette une vrai question :-) Je suis ouvert à l'argumentation.
Si cela apporte quelque chose, ne faudrait-il une relation style 
"related" ou "associatedAddr" pour définir un lien ?

- si tu met l'adresse en bordure du bâtiment ou dans le bâtiment,
la relation est implicite.
un outil informatique peux alors donner avec certitude l'adresse du 
bâtiment ou te dire quels bâtiments n'ont pas d'adresse définie.
Exemple d'application (très lent en ce moment)
https://qa.poole.ch/?zoom=18&lat=48.83926&lon=2.35185&layers=FTTFB0
même en environnement ultra dense comme Paris, cela montre bien les 
endroits où un bâtiment a une adresse certaine (vert) ou pas (rouge).
le square Adanson est assez représentatif du problème actuel.
au nord, il y a une association, pas au sud.
L'outil donne aussi un indice de bâtiments fractionnés qui gagnerait à 
utiliser des building:part mais çà c'est un autre débat.

Donc ma proposition : en cas de nœud-adresse avec une adresse pour un 
bâtiment, ne pourrait-on pas associer l'adresse au bâtiment soit on 
mettant le nœud sur le contour ou dans le bâtiment (ou via une relation
si quelqu'un est motivé pour porter une proposition).

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


Re: [OSM-talk-fr] schéma des addr

2018-01-05 Par sujet Axelos
Le 05/01/2018 à 14:04, Christian Quest a écrit :
> Peut être devrions nous mieux expliciter tout ça sur le wiki pour bien
> faire comprendre la logique des adresses, ce qu'elles sont et ne sont pas,
> etc.


En effet, ce serait vraiment une très bonne idée, car c'est vraiment
très complexe à comprendre l'ensemble. Comme l'a écrit Marc, il n'y a
pas d'explication de l'usage de contact:* au lieu de addr:* pour les
POI. C'est quasi impossible de comprendre sans demander sur cette liste,
forum, etc. (d’où le sujet qui revient souvent).

D'ailleurs JOSM ne propose ce type de balise pour les POI, et j'imagine
que les éditeurs en ligne non plus.

À plus.

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


Re: [OSM-talk-fr] schéma des addr

2018-01-05 Par sujet Philippe Verdy
Pourquoi ne pas utiliser la localisation du nœud venant du cadastre (quand
il y est indiqué) ou d'un SIG open data local? C'est un bon compromis,
souvent déjà en bordure de parcelle, et pas lié aux exigences de la poste
pour le placement des boites aux lettres souvent déplacées loin du lieu et
regroupées en zones rurale parfois sur une autre rue/route.

Ce nœud en revanche ne doit pas être sur la surface de la voirie publique,
on est d'accord. Le placement normal c'est sur l'intersection entre la voie
d'accès menant de la voirie publique à la porte du bâtiment (ou son parking
privé) et limite entre la parcelle privée et la voirie publique. Il n'y a
pas obligation que ce soit sur le bâtiment, ce peut être au niveau d'un
portail, d'une clôture. C'est le placement le plus pratique. Il n'y a qu'en
milieu urbain dense (quand les bâtiments bordent les trottoirs que le
placement le long du mur du bâtiment (faisant office de limite de parcelle)
est approprié et il est préférable de placer le nœud là qu'au milieu du
bâtiment qui peut avoir plusieurs façades exposées à différentes voiries
(et parfois deux adresses ou plus pour le même bâtiment même s'il n'y a
qu'un seul accès: dans ce cas on les réparti au plus proche si on peut les
distinguer, sinon on indique un groupe de numéros comme "10-12" si on ne
peut plus les distinguer parce que le bâtiment actuel a remplacé deux
anciens à accès séparés)

Note: on a bien des cas avec des bâtiments ayant plusieurs adresses sur des
rues différentes et pour le même accès, pour le courrier un seul est
utilisé mais certaines adresses postales mentionnent les deux simultanément
(mais le cadastre fait encore les distinctions). Et pas seulement en France
!

(le Royaume-Uni recense des tonnes de cas compliqués, mais en international
on a des cas encore plus "tordus" sur les adresses, comme au Japon
(structure complètement différente) ou au Nicaragua (l'adresse est une
forme abrégée d'itinéraire à suivre et de distances, depuis un point de
référence qui parfois n'existe plus, ainsi que des directions vers des
objets invisibles depuis le point de départ comme le nom d'une forêt ou
d'un lac où on ne passera même pas et qui ne figure même pas sur les cartes
car c'est aussi un ancien nom, ainsi qu'un vocabulaire particulier pour les
directions à suivre, et même des unités de mesure spécifiques pour les
distances ou temps de parcours à pied alors que le cheminement à pied n'est
plus le même, des couleurs de murs qui ont pu changer, d'anciens arbres,
fontaines, ou monuments notables disparus  !) ; et encore plus compliqué en
Afrique centrale ou en Afghanistan (repérage incluant des descriptions
physiques, des noms de personnes ou de métiers qui ont pu aussi
disparaitre...) mais là il n'y a aucun formalisme pour codifier ça de façon
homogène (et cela nécessite une connaissance personnelle locale et de la
diplomatie avec les habitants pour demander le chemin à suivre et trouver
les bonnes personnes qui connaissent : un vrai jeu de piste !)

Cela arrive suite à des travaux d'aménagement ou opérations immobilières,
où plusieurs anciennes propriétés fusionnent en copropriété (voire une
propriété unique) pour partager des parties communes (garages/caves,
jardin/cour, local poubelle, locaux de services pour le chauffage ou les
réseaux, gardiennage), ou créer une partie privée sur une partie des
plusieurs bâtiments jointifs (aménagements de commerces ou bureaux) ou
mieux sécuriser leurs accès et faciliter la navigation intérieure
(escaliers dans un bâtiment, mais ascenseur dans le voisin, issues de
secours accessibles des deux cotés, et ouverture de passages entre
bâtiments dans les étages, mais une seule porte commune conservée et
regroupement des boites à lettres sur un seul palier commun, l'autre ancien
palier pouvant redevenir privatif, suppression d'anciens escaliers peu
pratiques pour gagner de la place habitable dans un des bâtiments et en
confort pour tous les occupants).

Le 5 janvier 2018 à 13:15, marc marc  a écrit :

> Le 04. 01. 18 à 23:53, osm.sanspourr...@spamgourmet.com a écrit :
> > une personne a vire le addr:housenumber parce que trop près de la
> > voirie.
> > http://www.openstreetmap.org/changeset/35942339
>
> le problème est plus large que cela.
> ce qu'on peux lui reprocher :
> ses modifs sont incohérente avec le reste de la rue.
> s'il voulait migrer le nœud addr au profit du bâtiment, il fallait le
> faire au complet = supprimer totalement ce nœud et remplacer le noeud
> par le bâtiment dans la relation assosciatedStreet
> Et idéalement faire toute la rue en une fois pour garder une micro
> cohérence toute symbolique et absurde que cela soie dans ce cas.
>
> L'autre problème, c'est qu'en mettant le nœud quelque part en bordure de
> la parcelle, on confie au hasard le lien entre une adresse et un bâtiment.
> Si on veux tager le fait que c'est la parcelle qui a une adresse et non
> le bâtiment, soyons cohérent de taguer la parcelle (ce qui est hors de
> portée du contribute

Re: [OSM-talk-fr] schéma des addr

2018-01-05 Par sujet Christian Quest
Marc, tu te trompe sur plusieurs points.

contact:* est documenté et l'était bien avant qu'on en parle ici. Il s'agit
bien d'indiquer pour un POI le moyen de le contacter, pas que via son
adresse. Séparer la définition de l'adresse et celle du POI est assez
logique.

Les deux schémas utilisé pour modéliser les adresses sont largement
utilisables, que ce soit avec les relations ou sans.

On peut tout à fait relancer la discussion, mais comme les éléments de
départs n'ont pas changé, je ne vois pas pourquoi on arriverait à une autre
conclusion.


Il ne faut pas tout mélanger. Là, le départ c'est une anomalie signalée à
juste titre par osmose (si j'ai bien suivi) avec des modifications faites à
moitié.


Les adresses ça semble simple, mais en même temps c'est complexe, ce que
j'ai découvert en bossant ces dernières années sur le sujet. Pour beaucoup
de monde il y a confusion entre adresse et bâtiment (d'où cette tendance à
mettre des adresses sur les polygones de bâtiments) alors que non, ça n'est
pas du 1 vers 1.

J'ai encore dû expliquer à un dev ce matin qui réalisait un écran de saisie
d'adresse sur une borne que non, les codes postaux ne correspondent pas à
une commune... qu'il y a environ 6000 codes postaux et plus de 35000
communes (CQFD).

Peut être devrions nous mieux expliciter tout ça sur le wiki pour bien
faire comprendre la logique des adresses, ce qu'elles sont et ne sont pas,
etc.



Le 5 janvier 2018 à 13:15, marc marc  a écrit :

> Le 04. 01. 18 à 23:53, osm.sanspourr...@spamgourmet.com a écrit :
> > une personne a vire le addr:housenumber parce que trop près de la
> > voirie.
> > http://www.openstreetmap.org/changeset/35942339
>
> le problème est plus large que cela.
> ce qu'on peux lui reprocher :
> ses modifs sont incohérente avec le reste de la rue.
> s'il voulait migrer le nœud addr au profit du bâtiment, il fallait le
> faire au complet = supprimer totalement ce nœud et remplacer le noeud
> par le bâtiment dans la relation assosciatedStreet
> Et idéalement faire toute la rue en une fois pour garder une micro
> cohérence toute symbolique et absurde que cela soie dans ce cas.
>
> L'autre problème, c'est qu'en mettant le nœud quelque part en bordure de
> la parcelle, on confie au hasard le lien entre une adresse et un bâtiment.
> Si on veux tager le fait que c'est la parcelle qui a une adresse et non
> le bâtiment, soyons cohérent de taguer la parcelle (ce qui est hors de
> portée du contributeur moyen).
> Mais un tag de nœud mis positionné sans règle précise, c'est la foire.
> Dans ton lien, il est par exemple impossible de savoir avec certitude
> l'adresse du bâtiment au sud de la rue du Muguet
> https://www.openstreetmap.org/node/2045090782#map=19/48.37680/-4.57899
> peut-être
> 
> est-ce le 27 à moins que le bâtiment de gauche aie 3 adresses
> et que celui du bas n'ai pas encore d'adresse renseignée.
> peut-être même que c'est le 19 Route de Trénen avec une allée privée non
> renseigne. bref, faut prendre une vue satellite pour essayer de deviner
> l'adresse
> La solution de rapprocher le nœud du bâtiment revient implicitement à
> dire qu'on considère qu'il y a un lien entre l'adresse et le bâtiment
> tout en étant incohérent dans le fait de ne pas tager ce lien.
>
> Par conséquent, il ne faut pas s'étonner que des contributeurs finissent
> par ajouter les adresses sur les bâtiments lorsque ceux-ci n'ont qu'une
> adresse ou sur les portes d'entrée.
> Et on a le même problème avec ceux qui placent les poi à l'entrée de la
> parcelle (vu hier le cas hier d'un nœud en bord de route pour désigner
> la présence d'une chambre d'hôte dans un bâtiment des environs)
> aucun lien avec le bâtiment ni son adresse.. donc les gens finissent
> par encoder l'adresse une 3ieme fois.
> certains pensent que ce problème s'évite en utilisant une xieme
> spécificité franco-francaise des contact:addr documenté nulle part et
> donc utilisé par aucune app.
>
> Perso je suis triste de voir toutes ces infos inutilisable dans une
> appli simplement par manque de schéma cohérent.
> J'avais proposé qu'on s'attaque l'an passé à ce dossier difficile
> mais pour le moment, la seule chose sur laquelle on est d'accord,
> c'est le fait qu'on n'est pas d'accord.
> peut-être pourrait-on faire un pas en voyant s'il y a au moins un accord
> pour ouvrir ce chantier, chacun pourrait dire les problèmes pratique
> qu'il rencontre et comment sa façon de tager permet de résoudre ou pas
> ces problèmes.
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>



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


[OSM-talk-fr] schéma des addr

2018-01-05 Par sujet marc marc
Le 04. 01. 18 à 23:53, osm.sanspourr...@spamgourmet.com a écrit :
> une personne a vire le addr:housenumber parce que trop près de la 
> voirie.
> http://www.openstreetmap.org/changeset/35942339

le problème est plus large que cela.
ce qu'on peux lui reprocher :
ses modifs sont incohérente avec le reste de la rue.
s'il voulait migrer le nœud addr au profit du bâtiment, il fallait le 
faire au complet = supprimer totalement ce nœud et remplacer le noeud 
par le bâtiment dans la relation assosciatedStreet
Et idéalement faire toute la rue en une fois pour garder une micro 
cohérence toute symbolique et absurde que cela soie dans ce cas.

L'autre problème, c'est qu'en mettant le nœud quelque part en bordure de 
la parcelle, on confie au hasard le lien entre une adresse et un bâtiment.
Si on veux tager le fait que c'est la parcelle qui a une adresse et non 
le bâtiment, soyons cohérent de taguer la parcelle (ce qui est hors de 
portée du contributeur moyen).
Mais un tag de nœud mis positionné sans règle précise, c'est la foire.
Dans ton lien, il est par exemple impossible de savoir avec certitude 
l'adresse du bâtiment au sud de la rue du Muguet
https://www.openstreetmap.org/node/2045090782#map=19/48.37680/-4.57899
peut-être est-ce le 27 à moins que le bâtiment de gauche aie 3 adresses 
et que celui du bas n'ai pas encore d'adresse renseignée.
peut-être même que c'est le 19 Route de Trénen avec une allée privée non 
renseigne. bref, faut prendre une vue satellite pour essayer de deviner 
l'adresse
La solution de rapprocher le nœud du bâtiment revient implicitement à 
dire qu'on considère qu'il y a un lien entre l'adresse et le bâtiment 
tout en étant incohérent dans le fait de ne pas tager ce lien.

Par conséquent, il ne faut pas s'étonner que des contributeurs finissent 
par ajouter les adresses sur les bâtiments lorsque ceux-ci n'ont qu'une 
adresse ou sur les portes d'entrée.
Et on a le même problème avec ceux qui placent les poi à l'entrée de la 
parcelle (vu hier le cas hier d'un nœud en bord de route pour désigner 
la présence d'une chambre d'hôte dans un bâtiment des environs)
aucun lien avec le bâtiment ni son adresse.. donc les gens finissent
par encoder l'adresse une 3ieme fois.
certains pensent que ce problème s'évite en utilisant une xieme 
spécificité franco-francaise des contact:addr documenté nulle part et 
donc utilisé par aucune app.

Perso je suis triste de voir toutes ces infos inutilisable dans une 
appli simplement par manque de schéma cohérent.
J'avais proposé qu'on s'attaque l'an passé à ce dossier difficile
mais pour le moment, la seule chose sur laquelle on est d'accord,
c'est le fait qu'on n'est pas d'accord.
peut-être pourrait-on faire un pas en voyant s'il y a au moins un accord 
pour ouvrir ce chantier, chacun pourrait dire les problèmes pratique 
qu'il rencontre et comment sa façon de tager permet de résoudre ou pas 
ces problèmes.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr