Re: [OSM-talk-fr] Problème de représentation avec des parcelles forestières

[Topographe Fou]

  Probablement parce que comme l'explique le Wiki un multipolygon est par défaut une aire (contrairement à boundary qui est une frontière, quelque chose de linéaire) et que si un tag manque au niveau de la relation il va le chercher au niveau des membres (là je suis d'accord avec toi : ce n'est pas normal et pousse à la surinterpretation). Il donne même un exemple en Allemagne ou des mp ont été massivement utilisés au lieu de boundary. Un multipolygon est conçu comme une manière de définir une aire mais en utilisant plusieurs ways au lieu de une.Donc comme le rendu ne reconnaît pas cette manière de tagger un parcelle, il adopte son comportement par défaut qui est "c'est une aire" et "je cherche les tags d'abord dans la relation,  sinon dans les membres". Avec une boundary il ne dessine pas d'aire donc le glitche ne se produit pas. Est-ce une magouille ou un " taguer pour le rendu" ? Je ne sais pas trop encore... Si tu rajoute un tag landuse=forest à un mp de type parcel, on devrait logiquement arriver au même résultat et cela ne me paraît pas sémantiquement faux aussi.Résultat un multipolygon avec que des membres highway est donc vu comme un highway. Contrairement à ce que j'ai pu dire je ne pense plus qu'il y ai bug mais reste persuadé qu'il y a une erreur de conception (à savoir la remontée de tags qui pousse à une mauvaise pratique).Cordialement LeTopographeFouDe: verd...@wanadoo.frEnvoyé: 7 décembre 2016 1:30 AMÀ: talk-fr@openstreetmap.orgRépondre à: verd...@wanadoo.fr; talk-fr@openstreetmap.orgObjet: Re: [OSM-talk-fr] Problème de représentation avec des parcelles forestières  Je ne vois pas en quoi ce changement de "multipolygon" en "boundary" devrait avoir un impact sur l'interprétation et la "remontée" des tags des ways membres vers les relations qui les référence.Cela reste un bogue de la conversion OSM en pgsql, qui ne tient pas compte des critères nécessaires (tags identiques dans tous les ways membres ayant un rôle "outer" ou vide, ce qui n'était pas le cas des "name=*").En revanche remonter les "highway=*" vers la relation (peu importe que ce soit une "boundary" ou un "multipolygon") est problématique, dans les faits tous les "highway=*" sont linéaires (exceptions faite des "highway=pedestrian" et à condition qu'ils soient tagués avec "area=yes", ce qui n'était pas du tout le cas ici, car par défaut les "highway=*" sont soit linéaires, soit des noeuds isolés pour des passages piétons, priorités, stops...).Il reste donc bien une anomalie de osm2pgsql ici, et je ne vois pas pourquoi osm2pgsql devrait se demander ce que sont ces "multipolygon", d'autant plus qu'ils ont déjà des tags nécessaires, qu'ils soient tagués comme "multipolygon", boundary", ou encore comme "landuse", "natural" (qui n'ont eux rien non plus à voir avec les "highway=*")Le 6 décembre 2016 à 23:38, LeTopographeFou  a écrit :
  

  
  

  J'ai basculé ces "type=multipolygon" en
"type=boundary"... et tout rentre dans l'ordre comme je l'avais
imaginé dans mon précédent message qui n'a visiblement pas été
lu ;)
  Bonjour et merveilleux !! Je n'avais pas compris le sous-entendu.
  Merci.


  En terme de logique de tagging je verrai
plutôt quelque chose comme:
type=boundary (il s'agit d'une frontière qui découpe un ensemble
plus grand)
boundary=forest (frontière forestière)
forest=section (il s'agit d'une section)

Mais ça mérite discussion sur le wiki plutôt que d'y aller à
l'arrache... [...]
  
  Tout là fait d'accord (sans rentrer dans la discussion ici :
  j'aime bien ta proposition, elle est plus proche de l'existant et
  donc plus naturelle que la proposition Section).
Pour info il se trouve que j'ai eu un échange de mail avec
  l'auteur de la proposition Section cet été (à propos d'un
  cimetière que je visitais/cartographiais à l'époque) et il m'a dit
  qu'il n'avait pas eu le courage pour animer sa proposition
  jusqu'au bout. Il m'a encouragé à la retravailler voir à faire une
  contre-proposition, car il reste persuadé du besoin initial
  (parcelles forestières, sections dans un cimetière...).


  
Mais ça mérite discussion sur le wiki plutôt que d'y aller
  à l'arrache... surtout que l'import des données est pas génial
  non plus car les données d'origine ne sont pas forcément bien
  calées...
  

Exemple: http://umap.openstreetmap.fr/en/map/test-rendu-osmfr_99740#18/48.53494/1.97682
  Alors là c'est drôle car pendant que tu chang

Re: [OSM-talk-fr] Problème de représentation avec des parcelles forestières

[david . crochet]

Bonjour

- Mail original -
De: "Topographe Fou" 

Résultat un multipolygon avec que des membres highway est donc vu comme un 
highway. Contrairement à ce que j'ai pu dire je ne pense plus qu'il y ai bug 
mais reste persuadé qu'il y a une erreur de conception (à savoir la remontée de 
tags qui pousse à une mauvaise pratique). 

- Mail original -

L'une des erreurs qui sera résolu par la suite (dans 1, 10 ou 100 ans) sera de 
séparer la surface "aire boisé" du chemin puisqu'entre les deux il y a de forte 
chance d'avoir autre choses (bande herbacé, rigole d'évacuation d'eau, etc). Et 
là la relation sera inutile puisque on aura dessiné l'emprise boisée 
distinctement du/des chemins l'entourant.

Cordialement

-- 
David Crochet



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

Re: [OSM-talk-fr] Problème de représentation avec des parcelles forestières

[Christian Quest]

Le 07/12/2016 à 10:06, Topographe Fou a écrit :

Probablement parce que comme l'explique le Wiki un multipolygon est 
par défaut une aire (contrairement à boundary qui est une frontière, 
quelque chose de linéaire) et que si un tag manque au niveau de la 
relation il va le chercher au niveau des membres (là je suis d'accord 
avec toi : ce n'est pas normal et pousse à la surinterpretation). Il 
donne même un exemple en Allemagne ou des mp ont été massivement 
utilisés au lieu de boundary. Un multipolygon est conçu comme une 
manière de définir une aire mais en utilisant plusieurs ways au lieu 
de une.


Donc comme le rendu ne reconnaît pas cette manière de tagger un 
parcelle, il adopte son comportement par défaut qui est "c'est une 
aire" et "je cherche les tags d'abord dans la relation,  sinon dans 
les membres". Avec une boundary il ne dessine pas d'aire donc le 
glitche ne se produit pas. Est-ce une magouille ou un " taguer pour le 
rendu" ? Je ne sais pas trop encore... Si tu rajoute un tag 
landuse=forest à un mp de type parcel, on devrait logiquement arriver 
au même résultat et cela ne me paraît pas sémantiquement faux aussi.


Résultat un multipolygon avec que des membres highway est donc vu 
comme un highway. Contrairement à ce que j'ai pu dire je ne pense plus 
qu'il y ai bug mais reste persuadé qu'il y a une erreur de conception 
(à savoir la remontée de tags qui pousse à une mauvaise pratique).


Cordialement

LeTopographeFou


frontière ou surface, ça arrive dans la même table postgres via osm2pgsql...

Ensuite, le rendu se mélange forcément les pinceaux car les données dans 
la base osm2pgsql sont incohérentes mais le rendu peut soit remplir les 
surfaces des (multi)polygones soit ne tracer que leurs frontières... ce 
n'est qu'une question de feuille de style.


Le souci provient à l'origine de l'euristique d'osm2pgsql qui lorsqu'on 
utilise un type=multipolygon qui ne fait que décrire le type de 
géométrie sans décrire à quoi elle correspond va chercher à la compléter 
par l'information sémantique.


Cette euristique n'est pas parfaite... et donc il vaut mieux indiquer 
qu'on décrit bien la frontière d'une section (comme on décrit la 
frontière d'une commune) avec un type=boundary et du coup osm2pgsql ne 
cherche par à découvrir par lui même la sémantique estimant qu'elle est 
déjà décrite dans la relation.


On peut voir ça comme un bug d'osm2pgsql, mais le code ne peut pas 
toujours deviner l'intention du contributeur... il est préférable 
d'expliciter le type et en plus ça me parait cohérent en terme de tags.


--
Christian Quest - OpenStreetMap France

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

Re: [OSM-talk-fr] intégration des référentiels STIF

[Noémie Lehuby]

Bonjour,

Je ne suis pas favorable à l'utilisation d'Osmose pour intégrer les 
codes des points d'arrêts, du moins pour le moment. Je pense que ça 
risque d'induire des erreurs chiantes à redresser par la suite.
Déjà parce qu'on ne va pas forcément avoir une relation 1 1 entre les 
deux référentiels.

Voir par exemple ce cas :
https://framapic.org/xhAIOVchGrbR/GusjVGKbAd0L.png
(bleu STIF, rose OSM)
les données OSM sont conformes au terrain : il y a en effet uniquement 
deux arrêts de bus
les données du STIF ont une qualité honorable, mais présentent un couple 
d'arrêt pour chaque transporteur qui s'arrête à cet endroit


Et à part pour les cas simples (par exemple un arrêt bien isolé), je ne 
vois pas trop comment on peut déterminer quel est l'arrêt qui matche 
côté STIF sans s'aider des lignes qui y passent.
Une intégration en s'appuyant sur la base des données transport globales 
(GTFS par exemple) est en effet à mon avis beaucoup plus pertinente.
Par exemple sur ce cas-là, ça me semble loin d'être évident de voir quel 
arrêt OSM correspond à quel(s) arrêt(s) STIF.

https://framapic.org/k9Pz6OezPUAu/WKoTWeaYyLSm.png
(vert STIF, rose OSM)


Bref, vous voulez pas qu'on commence par les lignes / relations 
route_master, et qu'ensuite on voit comment on peut redescendre sur les 
relations route, puis les relations stop_area et les noeuds  
public_transport = platform?


Noémie


Date: Wed, 7 Dec 2016 02:05:13 +0100
From: Jérôme Amagat 
To: Discussions sur OSM en français  
Subject: Re: [OSM-talk-fr] intégration des référentiels STIF
Message-ID:

Content-Type: text/plain; charset="utf-8"

pour le STIF dans le GTFS le "ref" des arrêts dans tous les fichier 
sauf 1

c'est un stop_id différent du ZDEr_ID_REF_A mais il y a quand même un
fichier pour passer du
ZDEr_ID_REF_A au stop_id


Le 6 décembre 2016 à 22:20, Florian LAINEZ  a écrit 
:



Si OSMOSE se met à manger du GTFS c'est certain que ça permettrai de
passer à une autre échelle.
Fred tu comptes l'implémenter du coup ?
Comment comptes-tu gérer l'évolution des données sources dans le temps 
?
Autant avec un jeu de données statiques tu peux valider/ignorer un 
POI,

autant si les données évoluent il faut être certain de disposer d'un
identifiant pérenne.

Fred en attendant peut-être vaut-il déjà intégrer les données 
statiques du

STIF comme première étape.
Merci



Le 6 décembre 2016 à 20:44, Frédéric Rodrigo  
a

écrit :


Le 06/12/2016 à 19:13, Florian LAINEZ a écrit :



Le 6 décembre 2016 à 13:45, Christian Quest mailto:cqu...@openstreetmap.fr>> a écrit :

J'ai regardé dans mon quartier desservi par la RATP... c'est
"correct" à 50m près.

J'en ai à peu près le même souvenir. J'ai checké une belle quantité
d'arrêts autour de gares Transilien cet été, j'en ai trouvé certains 
sur

les quais de gares ... d'autres très bien placés.

Le STIF agrégeant des données provenant d'une multitude de
sociétés de transport, la qualité géométrique n'est sûrement pas
homogène

exactement.

Fred tu peux considérer le champs ZDEr_ID_REF_A comme notre 
ref:FR:STIF,

merci

Au passage je vous signale cette issues sur osmose-backend:


https://github.com/osm-fr/osmose-backend/issues/163

qui propose de faire la même chose à un niveau industriel.




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





--

*Florian Lainez*
@overflorian <http://twitter.com/overflorian>

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



-- section suivante --
Une pièce jointe HTML a été nettoyée...
URL:
<http://lists.openstreetmap.org/pipermail/talk-fr/attachments/20161207/8488f152/attachment-0001.html>

--

Message: 2
Date: Wed, 7 Dec 2016 07:26:20 +0100
From: Christian Quest 
To: Discussions sur OSM en français  
Subject: Re: [OSM-talk-fr] intégration des référentiels STIF
Message-ID:

Content-Type: text/plain; charset="utf-8"

Il faut SI POSSIBLE se baser sur l'id qu'on peut voir sur le terrain... 
et

des id "STIF" j'en ai déjà vu sur des réseaux non RATP.

Le 7 décembre 2016 à 02:05, Jérôme Amagat  a 
écrit

:

pour le STIF dans le GTFS le "ref" des arrêts dans tous les fichier 
sauf 1

c'est un stop_id différent du ZDEr_ID_REF_A mais il y a quand même un
fichier pour passer du
ZDEr_ID_REF_A au stop_id


Le 6 décembre 2016 à 22:20, Florian LAINEZ  a écrit 
:



Si OSMOSE se met à manger du GTFS c'est certain que ça permettrai de
passer à une autre échelle.
Fred tu comptes l'implémenter du coup ?
Comment comptes-tu gérer l'évolution des données sources dans le 
temps 

Re: [OSM-talk-fr] Problème de représentation avec des parcelles forestières

[Ch. Rogel]

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

Re: [OSM-talk-fr] intégration des référentiels STIF

[Florian LAINEZ]

Très intéressante démonstration Noémie.
Du coup peut-être en effet devrions-nous attendre de pouvoir exploiter le
GTFS avant de se lancer dans l'intégration des données STIF ...
Fred tu penses que ça pourrait passer sur la liste au père-noël ? ;)

Le 7 décembre 2016 à 11:15, Noémie Lehuby  a
écrit :

> Bref, vous voulez pas qu'on commence par les lignes / relations
> route_master, et qu'ensuite on voit comment on peut redescendre sur les
> relations route, puis les relations stop_area et les noeuds
> public_transport = platform?

pourquoi pas mais on fait comment ? Il me semble qu'il nous manque pour
l'instant un outil pour faire le boulot efficacement, *n'est-il pas* ?

-- 

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

Re: [OSM-talk-fr] intégration des référentiels STIF

[Jérôme Amagat]

Le 7 décembre 2016 à 20:48, Florian LAINEZ  a écrit :

> Très intéressante démonstration Noémie.
> Du coup peut-être en effet devrions-nous attendre de pouvoir exploiter le
> GTFS avant de se lancer dans l'intégration des données STIF ...
> Fred tu penses que ça pourrait passer sur la liste au père-noël ? ;)
>
> Le 7 décembre 2016 à 11:15, Noémie Lehuby 
> a écrit :
>
>> Bref, vous voulez pas qu'on commence par les lignes / relations
>> route_master, et qu'ensuite on voit comment on peut redescendre sur les
>> relations route, puis les relations stop_area et les noeuds
>> public_transport = platform?
>
> pourquoi pas mais on fait comment ? Il me semble qu'il nous manque pour
> l'instant un outil pour faire le boulot efficacement, *n'est-il pas* ?
>
> Dans osm on peut pas créer des relations sans rien mettre dedans (enfin ça
doit être possible mais la relation est tout de suite perdu) il faut une
géométrie à lui accrocher. Seul les node ont des coordonnées si une
relation n'est pas lié de près ou de loin à un node elle est nulle part.
Les relations route master sont reliés qu'a d'autres relations les
relations route qui elles sont relié aux arrêts et aux routes entre les
arrêts.
ces route entre les arrêts je vois pas comment ça pourrait être fait
autrement qu'"à la main par des gens"
les arrêts, on a des données avec des coordonnées pas trop mal c'est pour
intégré ce genre de données qu'osmose est utile.
après si on a les arrêts avec les bonnes "ref" dans osm, un "outil" peut
créer les relation (route ou route master) ou vérifier quels sont justes
avec les donnée GTFS ou d'autres données.
Mais dans l'autre sens je vois pas comment.

Par contre, ce qui est possible et utile c'est se mettre d'accord sur les
tags à mettre dans les relations d’après les données qu'on a (quel ref,
quel name ...) pour avoir des données dans osm homogènes. pareil sur la
façon de créer les relations stop_area. Mais les créer sans rien mettre
dedans à part des tags c'est pas possible ?

Autre chose qui peut être fait avant d’intégré les arrêts ( c'est une chose
qui pourrait compliquer aussi le travail d'un "outil créant les relations"
) c'est voir comment modifié , rajouté quel tag sur les relations
représentant les lignes de bus qui en existe déjà.
Des type=route_master il n'y en a pas beaucoup !? (ou alors je cherche pas
comme il faut) : http://overpass-turbo.eu/s/kvI
des type=route route=bus il y en as beaucoup :
http://overpass-turbo.eu/s/kvJ



> --
>
> *Florian Lainez*
> @overflorian 
>
> ___
> 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