Re: [OSM-talk-fr] Altitude des panneaux

[Yves P.]

> MNT = Modèle Numérique de Terrain (donc le sol)
> 
> MNS = Modèle Numérique de Surface (donc canopée, haut des bâtiments, etc)
> 
> Un LIDAR brut, c'est plutôt un MNS, mais il peut avoir été retravaillé pour 
> obtenir un MNT... tout comme on a les photos aériennes brutes et 
> ortho-rectifiées même si c'est pas tout à fait le même process.
> 
Merci pour les précisions :)

J'ai découvert le terme MNS au détour du SOTM 2020 sans vraiment comprendre sa 
signification :D

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

Re: [OSM-talk-fr] Segmentation des maisons

[Florian_G]

Hello,

Le 23/07/2020 à 15:48, Stéphane Péneau a écrit :
> Perso je ne recommande pas la fusion de ces éléments, on perd des
> informations qui seront intéressantes lorsque quelqu'un voudra faire
> de la 3d.

+1 !

> Cas n°1 : J'ai du temps et du courage :
>
> Je dessine un polygone qui fait le tour complet de la maison, avec
> pour tag building=house
> Les anciens polygone deviennent des building:part=yes/house/etc...
>
C'est exactement comme ça que je procède, en m'aidant des orthophotos
également. Si j'ai envie et que je le voie, je donne des précisions sur
la toiture (roof:shape, etc.).

++



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

Re: [OSM-talk-fr] Segmentation des maisons

[Francois Gouget]

On Thu, 23 Jul 2020, André Maroneze wrote:
[...]
> En tout cas, merci pour vos avis. Vu l'absence de consensus sur le sujet,
> je vais réfléchir sur le fait de les fusionner ou non. S'il y a un site qui
> permet de voir le rendu 3D, mis à jour relativement souvent, dites-le-moi
> s'il vous plaît pour que je puisse voir ce que ça donne les bâtiments
> partiellement remplis, pour avoir une meilleure idée des impacts possibles
> des fusions.

En voici deux :
https://demo.f4map.com/#lat=48.8603923=2.2917640=17

Il y a aussi osmbuildings dont le rendu est moins bon (au moins sur 
cette zone):
https://osmbuildings.org/?lat=48.85907=2.29312=16.4=30

Vu les différences de rendu, cela renforce la règle du "ne pas tagger 
pour le rendu". D'autant que ces deux sites ou d'autres vont 
probablement continuer d'évoluer.


-- 
Francois Gouget   http://fgouget.free.fr/
Before you criticize someone, walk a mile in his shoes.
   That way, if he gets angry, he'll be a mile away - and barefoot.___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Segmentation des maisons

[Christian Quest]

Le 23/07/2020 à 23:07, André Maroneze a écrit :
Je suis d'accord dans l'ensemble, mais je crains que cela ne soit plus 
nuisant à des activités comme StreetComplete (vu que, dans le quartier 
où je mappe, il y n'y a aucune information sur les bâtiments, à part 
les données importées il y a des années).


Moi-même je me sens démotivé de les compléter via StreetComplete, car 
il reste toujours de petits morceaux de bâtiments qui engendrent des 
quêtes peu utiles, et on finit par répéter les mêmes informations et 
se fatiguer.


En fait, c'était en voyant le rendu 3D de la région sur un site 
d'immobilier que je me suis demandé pourquoi les maisons n'étaient que 
des cubes blancs, et que je me suis rendu compte que toute cette 
information manquait.


Je me disais surtout que, pour le rendu 3D, ces parties de maison sans 
mur (les parties en jaune clair dans le Cadastre correspondent en fait 
à des polygones avec wall=no) seraient gênantes, car si on met par 
exemple un roof:shape=gabled, chaque morceau engendrait un petit toit 
"gabled" en soi, non ? En tout cas, dans les quelques maisons que j'ai 
pu voir en vrai, la forme du toit et les parties "wall=no" n'étaient 
pas corrélées.


Enfin, sur JOSM, le plugin contourmerge semble faire ce que je 
voudrais : en sélectionnant 2 ou 3 polygones collés, il les fusionne, 
et après il suffit de corriger les tags, si besoin (par exemple, 
enlever le "wall=no").


En tout cas, merci pour vos avis. Vu l'absence de consensus sur le 
sujet, je vais réfléchir sur le fait de les fusionner ou non. S'il y a 
un site qui permet de voir le rendu 3D, mis à jour relativement 
souvent, dites-le-moi s'il vous plaît pour que je puisse voir ce que 
ça donne les bâtiments partiellement remplis, pour avoir une meilleure 
idée des impacts possibles des fusions.


Il me semble qu'il y a un bon consensus sur:

- ne fusionner QUE ce qui est découpé à cause d'une parcelle

- ne pas fusionner les parties additionnelles en wall=no avec le bâti 
principal


Il m'arrive parfois de découper un polygone de bâti qui englobe maison 
et garage, pour indiquer building=house sur l'un et building=garage sur 
l'autre.



Le quête StreetComplete ne doit pas guider la modélisation dans OSM. 
Celle-ci me semble partir d'un postulat faux en cherchant à associer une 
adresse à chaque polygone building=*


Pour le rendu en 3D, c'est une toute autre paire de manche, cela prend 
du temps de passer en revue les bâtiments un à un pour des indications 
minimales comme le type de toit.


Mais avant d'attaquer la 3D, a-t-on toujours une majorité de 
building=yes ou bien a-t-on déjà précisé 
house/appartment/garage/shed/etc... ?


StreetComplete pour ce type de contribution n'est peut être pas ce qu'il 
y a de plus efficient.


Pour JOSM, pas besoin de plugin pour fusionner 2 polygones, Shift-J 
(join) le fait (et un coup de shift-Y après permet d'éliminer les noeuds 
devenus inutiles). Je ne vois pas dans quel cas contourmerge serait 
utile pour le bâti (il n'est même pas installé chez moi).


--
Christian Quest - OpenStreetMap France


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

Re: [OSM-talk-fr] Segmentation des maisons

[André Maroneze]

> Perso je ne recommande pas la fusion de ces éléments, on perd des
informations qui seront intéressantes lorsque quelqu'un voudra faire de la
3d.

Je suis d'accord dans l'ensemble, mais je crains que cela ne soit plus
nuisant à des activités comme StreetComplete (vu que, dans le quartier où
je mappe, il y n'y a aucune information sur les bâtiments, à part les
données importées il y a des années).

Moi-même je me sens démotivé de les compléter via StreetComplete, car il
reste toujours de petits morceaux de bâtiments qui engendrent des quêtes
peu utiles, et on finit par répéter les mêmes informations et se fatiguer.

En fait, c'était en voyant le rendu 3D de la région sur un site
d'immobilier que je me suis demandé pourquoi les maisons n'étaient que des
cubes blancs, et que je me suis rendu compte que toute cette information
manquait.

Je me disais surtout que, pour le rendu 3D, ces parties de maison sans mur
(les parties en jaune clair dans le Cadastre correspondent en fait à des
polygones avec wall=no) seraient gênantes, car si on met par exemple un
roof:shape=gabled, chaque morceau engendrait un petit toit "gabled" en soi,
non ? En tout cas, dans les quelques maisons que j'ai pu voir en vrai, la
forme du toit et les parties "wall=no" n'étaient pas corrélées.

Enfin, sur JOSM, le plugin contourmerge semble faire ce que je voudrais :
en sélectionnant 2 ou 3 polygones collés, il les fusionne, et après il
suffit de corriger les tags, si besoin (par exemple, enlever le "wall=no").

En tout cas, merci pour vos avis. Vu l'absence de consensus sur le sujet,
je vais réfléchir sur le fait de les fusionner ou non. S'il y a un site qui
permet de voir le rendu 3D, mis à jour relativement souvent, dites-le-moi
s'il vous plaît pour que je puisse voir ce que ça donne les bâtiments
partiellement remplis, pour avoir une meilleure idée des impacts possibles
des fusions.


On Thu, Jul 23, 2020 at 3:50 PM Stéphane Péneau 
wrote:

> Le 23/07/2020 à 13:24, André Maroneze a écrit :
>
>
> Je ne vois pas l'intérêt de conserver ces segmentations ; puis-je donc les
> fusionner via JOSM ou un autre outil ?
>
>
> Perso je ne recommande pas la fusion de ces éléments, on perd des
> informations qui seront intéressantes lorsque quelqu'un voudra faire de la
> 3d.
>
> Cas n°1 : J'ai du temps et du courage :
>
> Je dessine un polygone qui fait le tour complet de la maison, avec pour
> tag building=house
> Les anciens polygone deviennent des building:part=yes/house/etc...
>
>
> Cas n°2 : Je n'ai pas le courage
>
> Je laisse comme c'est
>
>
> Stf
> ___
> 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] ref et ref:FR

[François Lacombe]

Merci à vous pour le nettoyage !

François

Le mar. 21 juil. 2020 à 08:42, Topographe Fou  a
écrit :

> Bonjour,
>
> Suis pour supprimer la colonne, il y a bien souvent dans les autres déjà
> des liens vers les annuaires officiels en ligne qui vont bien.
>
> Merci pour le toilettage.
>
> LeTopographeFou
> *De:* lenny.li...@orange.fr
> *Envoyé:* 20 juillet 2020 7:26 PM
> *À:* talk-fr@openstreetmap.org
> *Répondre à:* talk-fr@openstreetmap.org
> *Objet:* Re: [OSM-talk-fr] ref et ref:FR
>
>
> Le 20/07/2020 à 00:39, Yves P. a écrit :
>
> Je propose de supprimer la colonne Tag2Link, ce greffon n'étant plus utilisé.
>
> le greffon n'est plus nécessaire, car il a été intégré dans JOSM (
> https://josm.openstreetmap.de/wiki/Fr%3AHelp/Action/Tag2Link) n'en
> connaissant pas l'utilisation je n'ai pas d'avis, vous me confirmez que la
> colonne n'est plus nécessaire ?
>
> leni
>
>
> __
> Yves
>
>
>
>
> ___
> Talk-fr mailing 
> listTalk-fr@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-fr
>
> ___
> 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] Segmentation des maisons

[DH]

Le 23/07/2020 à 15:48, Stéphane Péneau a écrit :

Le 23/07/2020 à 13:24, André Maroneze a écrit :


Je ne vois pas l'intérêt de conserver ces segmentations ; puis-je 
donc les fusionner via JOSM ou un autre outil ?



Perso je ne recommande pas la fusion de ces éléments, on perd des 
informations qui seront intéressantes lorsque quelqu'un voudra faire 
de la 3d.



+1
Je suis étonné que personne n'ai mentionné l'orthophoto comme source 
complémentaire, soit directement dans l'outil avec JOSM soit en source 
complémentaire (Géoportail ou autre portail géographique régional). 
L'intérêt de la contribution OSM, aujourdhui, est de pouvoir confronter 
plusieurs sources de données complémentaires : aucune ne sera parfaite 
ou bonne seule, mais la compilation à travers l'analyse du contributeur 
(pas forcément sur le ou connaisseur  du terrain) est une vraie 
plus-value pour le projet, celle qui coûte le plus cher.


Il ne faut pas oublier que, sur la France, la base s'est construite au 
fur et à mesure avec une connaissance, des sources, des outils qui n'ont 
cessé d'évoluer vers plus de précisions, de détails, d'actualité.
Il ne faut pas hésiter, en conséquence, à re-labourer des terrains 
laissés trop longtemps en friche (c'est pas pareil en agriculture, hein)


PS : je ne crois pas (encore) aux outils ni d'aide à l'import, ni de 
conflation. Le sujet est trop complexe. Peut-être un jour


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

Re: [OSM-talk-fr] Osmose dans l'actuelle version de l'éditeur en ligne iD

[Frédéric Rodrigo]

Le 23/07/2020 à 18:23, Vincent Bergeot a écrit :

C'est déployé.

En mode édition, vous tapez F et vous sélectionnez Signalements Osmose.

Exemple de signalement :

Intersection entre la voirie et une petite surface d’eau


Description

Two features overlap with no shared node to indicate a physical 
connection or tagging to indicate a vertical separation.



Éléments

  * Avenue de Brindos
  * Ruisseau de la Palive


Guides de correction

Move a feature if it's in the wrong place. Connect the features if 
appropriate or update the tags if not.



Erreurs fréquentes

A feature may be missing a tag e.g. |tunnel=*|, |bridge=*|, 
|covered=*| or consider |layer=*| on the buidling where a road or 
railway enters a structure. Warning, information sources can be 
contradictory in time or with spatial offset.


Cela va donner envie de traduire mais je ne sais pas-plus où c'est ?



La doc est maintenant également à traduire sur transifex, comme le 
logiciel :


http://osmose.openstreetmap.fr/fr/translation

Ça tombe bien, il reste encore un peu de travail sur la traduction 
française. Depuis que la doc est aussi sur tranfisex, plus aucune langue 
n'est complète.


Frédéric.



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

Re: [OSM-talk-fr] Osmose dans l'actuelle version de l'éditeur en ligne iD

[Yves P.]

> Cela va donner envie de traduire mais je ne sais pas-plus où c'est ?
c'est dans osmose-backend/po/fr.po 


Les traductions se font avec Transifex :
https://www.transifex.com/openstreetmap-france/osmose/translate/#fr/backend/24681878

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

Re: [OSM-talk-fr] Altitude des panneaux

[Eric SIBERT]

Le 23/07/2020 à 11:20, Jacques Lavignotte a écrit :

Pour de la précision en GPS il faut aller vers :

https://fr.wikipedia.org/wiki/GPS_diff%C3%A9rentiel


D'ailleurs, à ce propos, je suis en train de faire des essais avec un 
récepteur GNSS différentiel. J'ai voulu faire des mesures sur ce type de 
panneaux, celui-là par exemple:


https://www.mapillary.com/map/im/fuqR2umra-1VDkJKYfG9dQ

J'ai voulu poser l'antenne en haut du poteau pour une meilleure 
réception. Eh bien, ils sont hauts ces poteaux. Vous prenez où 
l'altitude? En bas ou en haut?


Mes 0,02 €.

Eric

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

Re: [OSM-talk-fr] liste des orthophotos france (cquest)

[Christian Quest]

Le 23/07/2020 à 15:58, Cyrille37 OSM a écrit :

Hello

Christian, cette umap est-elle à jour ?
https://umap.openstreetmap.fr/en/map/ortho-photos-opendata-openortho_278682 



Pour s'en servir de référence lors de demande de mise à dispo 
d'orthophoto. 


Non, c'est pas à jour ni complet. Le but de cette carte est plutôt de 
montrer la qualité des orthos quand on rentre arrive à 10cm et mieux.


La liste à jour est sur le wiki: 
https://wiki.openstreetmap.org/wiki/FR:Serveurs/wms.openstreetmap.fr


--
Christian Quest - OpenStreetMap France


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

Re: [OSM-talk-fr] Osmose dans l'actuelle version de l'éditeur en ligne iD

[Vincent Bergeot]

C'est déployé.

En mode édition, vous tapez F et vous sélectionnez Signalements Osmose.

Exemple de signalement :

Intersection entre la voirie et une petite surface d’eau


   Description

Two features overlap with no shared node to indicate a physical 
connection or tagging to indicate a vertical separation.



   Éléments

 * Avenue de Brindos
 * Ruisseau de la Palive


   Guides de correction

Move a feature if it's in the wrong place. Connect the features if 
appropriate or update the tags if not.



   Erreurs fréquentes

A feature may be missing a tag e.g. |tunnel=*|, |bridge=*|, |covered=*| 
or consider |layer=*| on the buidling where a road or railway enters a 
structure. Warning, information sources can be contradictory in time or 
with spatial offset.


Cela va donner envie de traduire mais je ne sais pas-plus où c'est ?


--
Vincent Bergeot

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

Re: [OSM-talk-fr] Segmentation des maisons

[pepilepi...@ovh.fr]

Le 23/07/2020 à 13:45, Cyrille37 OSM a écrit :
> Bonjour,
>
> Le 23/07/2020 à 13:24, André Maroneze a écrit :
>> Par contre, pour la re-segmentation des maisons, est-ce que c'est la
>> bonne approche de la faire moi-même ? Est-ce qu'un futur import du
>> Cadastre risque de défaire tous mes changements, par exemple, ou il y
>> a une perte d'information en fusionnant les polygones ?
>
> Il n'y a pas d'import automatique du Cadastre, il ne faut surtout pas.
>

+1

J'en ai vus dans le passé, ça faisait du dégat.


>> Je ne vois pas l'intérêt de conserver ces segmentations ; puis-je
>> donc les fusionner via JOSM ou un autre outil ?
>
> Il n'y a pas intérêt à la conserver quand elle n'indique pas des
> éléments différents.
>
> Par contre je n'ai pas d'outil facilitant la tâche (j'aimerai bien :-))
>
> Cyrille37.
>
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr


-- 


Si ma réponse n'a pas résolu ton problème, c'est que tu n'as pas posé la
bonne question.

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

Re: [OSM-talk-fr] Comment qualifier un Chaussidou

[Stéphane Péneau]

Le 23/07/2020 à 17:42, Nicolas Dumoulin a écrit :

Salut :-)

Je me demande comment qualifier un chaussidou, aussi appelé "Chaussée 
à Voie Centrale Banalisée" (CVCB) décrite ici par exemple : 
https://www.cc37.org/chaussee-a-voie-centrale-banalisee-chaucidou/


Une recherche de "chaussidou" sur taginfo ne me renvoie rien à part 
des mentions en attribut "note". Ça me semblerait intéressant de 
qualifier ce genre d'aménagement pour être plus précis et permettre 
une vue générale de la présence de cet aménagement.


Ça ne semble bien sûr pas opportun d'utiliser un highway=* spécifique 
ni d'omettre les tags "cycleway=*" mais d'ajouter un complément genre 
highway:chaussidou=yes ou bien zone:chaussidou=yes. Pour rappel, ce 
type d'aménagement n'est pas spécifiquement Français, donc pas de "FR:".


Qu'en pensez-vous ?

P.S. : Ça faisait longtemps que je n'étais pas passé sur cette liste, 
j'espère que vous allez bien. En tout cas, je constate qu'OSM continue 
à se faire sa place, quelle réjouissance pour un projet libre. 
Portez-vous bien.



Salut Nicolas !

Tu auras ta réponse ici : 
https://wiki.openstreetmap.org/wiki/FR:Bicycle#Bandes_cyclables


C'est le cas L3


Stf


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

Re: [OSM-talk-fr] Comment qualifier un Chaussidou

[PanierAvide]

Bonjour,

Voir ici, le cas L3 : 
https://wiki.openstreetmap.org/wiki/FR:Bicycle#Bandes_cyclables


Les tags : highway=* + cycleway=lane + lanes=1 + oneway=no

Cordialement,

Adrien P.

Le 23/07/2020 à 17:42, Nicolas Dumoulin a écrit :

Salut :-)

Je me demande comment qualifier un chaussidou, aussi appelé "Chaussée 
à Voie Centrale Banalisée" (CVCB) décrite ici par exemple : 
https://www.cc37.org/chaussee-a-voie-centrale-banalisee-chaucidou/


Une recherche de "chaussidou" sur taginfo ne me renvoie rien à part 
des mentions en attribut "note". Ça me semblerait intéressant de 
qualifier ce genre d'aménagement pour être plus précis et permettre 
une vue générale de la présence de cet aménagement.


Ça ne semble bien sûr pas opportun d'utiliser un highway=* spécifique 
ni d'omettre les tags "cycleway=*" mais d'ajouter un complément genre 
highway:chaussidou=yes ou bien zone:chaussidou=yes. Pour rappel, ce 
type d'aménagement n'est pas spécifiquement Français, donc pas de "FR:".


Qu'en pensez-vous ?

P.S. : Ça faisait longtemps que je n'étais pas passé sur cette liste, 
j'espère que vous allez bien. En tout cas, je constate qu'OSM continue 
à se faire sa place, quelle réjouissance pour un projet libre. 
Portez-vous bien.




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

[OSM-talk-fr] Comment qualifier un Chaussidou

[Nicolas Dumoulin]

Salut :-)

Je me demande comment qualifier un chaussidou, aussi appelé "Chaussée à 
Voie Centrale Banalisée" (CVCB) décrite ici par exemple : 
https://www.cc37.org/chaussee-a-voie-centrale-banalisee-chaucidou/


Une recherche de "chaussidou" sur taginfo ne me renvoie rien à part des 
mentions en attribut "note". Ça me semblerait intéressant de qualifier 
ce genre d'aménagement pour être plus précis et permettre une vue 
générale de la présence de cet aménagement.


Ça ne semble bien sûr pas opportun d'utiliser un highway=* spécifique ni 
d'omettre les tags "cycleway=*" mais d'ajouter un complément genre 
highway:chaussidou=yes ou bien zone:chaussidou=yes. Pour rappel, ce type 
d'aménagement n'est pas spécifiquement Français, donc pas de "FR:".


Qu'en pensez-vous ?

P.S. : Ça faisait longtemps que je n'étais pas passé sur cette liste, 
j'espère que vous allez bien. En tout cas, je constate qu'OSM continue à 
se faire sa place, quelle réjouissance pour un projet libre. Portez-vous 
bien.


--
Nicolas Dumoulin


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

Re: [OSM-talk-fr] BANO : erreur claire d'adrresse

[Vincent de Château-Thierry]

Bonjour,

> De: "osm sanspourriel" 
> 
> Pour ce point c'est assez facile (vdct ou Christian Quest me
> corrigeront
> si besoin).
> 
> La BANO tient compte des données OSM donc tu corriges dans OSM.

Oui BANO privilégie les données OSM donc pour améliorer BANO en effet, le plus 
simple et à portée de nous tou.te.s c'est de saisir ce qu'on estime être la 
bonne version, directement dans OSM.

Concernant la màj FANTOIR, BANO est à jour de Fantoir Avril 2020, dernier 
millésime dispo à 
https://www.data.gouv.fr/fr/datasets/fichier-fantoir-des-voies-et-lieux-dits/. 

Pour le sujet de l'inclusion de la BAN dans BANO c'est prévu mais pas encore 
réalisé. Ce sera aussi le pré-requis à la remise en marche du rendu carto BANO, 
ça remplacera les données Cadastre et ancienne BAN. 

vincent

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

[OSM-talk-fr] liste des orthophotos france (cquest)

[Cyrille37 OSM]

Hello

Christian, cette umap est-elle à jour ?
https://umap.openstreetmap.fr/en/map/ortho-photos-opendata-openortho_278682

Pour s'en servir de référence lors de demande de mise à dispo d'orthophoto.

Cyrille37.


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

Re: [OSM-talk-fr] Segmentation des maisons

[Stéphane Péneau]

Le 23/07/2020 à 13:24, André Maroneze a écrit :


Je ne vois pas l'intérêt de conserver ces segmentations ; puis-je donc 
les fusionner via JOSM ou un autre outil ?



Perso je ne recommande pas la fusion de ces éléments, on perd des 
informations qui seront intéressantes lorsque quelqu'un voudra faire de 
la 3d.


Cas n°1 : J'ai du temps et du courage :

Je dessine un polygone qui fait le tour complet de la maison, avec pour 
tag building=house

Les anciens polygone deviennent des building:part=yes/house/etc...


Cas n°2 : Je n'ai pas le courage

Je laisse comme c'est


Stf

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

Re: [OSM-talk-fr] BANO : erreur claire d'adrresse

[osm . sanspourriel]

Pour ce point c'est assez facile (vdct ou Christian Quest me corrigeront
si besoin).

La BANO tient compte des données OSM donc tu corriges dans OSM.

Jean-Yvon

Le 23/07/2020 à 15:17, Denis Chenu - courr...@shnoulle.net a écrit :

Bonjour,

Que faire quand il y a clairement une erreur d'adresse/relation sur le
BANO ?
Je prend l'exemple des 3 points "Allée de Belfort" (595120545B)



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

[OSM-talk-fr] BANO : erreur claire d'adrresse

[Denis Chenu]

Bonjour,

Grace aux conseils de Jean-Yvon, je me suis mis à l'ajout des adresses
sur Roubaix via Fantoir (dev.cadastre.openstreetmap.fr/fantoir) .

Que faire quand il y a clairement une erreur d'adresse/relation sur le
BANO ?
Je prend l'exemple des 3 points "Allée de Belfort" (595120545B)
Qui sont clairement Boulevard de Belfort


Sur Roubaix encore : je vois beaucoup de différences entre la BAN (via
guichet-adresse.ign.fr) et le BANO .
La BAN peut être incorporé au BANO si je ne me trompe puisque sous
licence ouverte.
Mais la BAN est plus à jour et de meilleure qualité sur les points les
plus modernes.

Quel procédure pour demander une mise à jour de fantoir ? Je peux aider ?
Je dois rapporter sur github ?

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

Re: [OSM-talk-fr] Altitude des panneaux

[Christian Quest]

Le 23/07/2020 à 11:20, Jacques Lavignotte a écrit :



Le 23/07/2020 à 09:44, Cyrille37 OSM a écrit :
En même temps, 20 mètres sur l'altitude c'est difficile de savoir qui 
a raison. Pas sûr que nos petits GPS et le MNT OpenTopoMap soient 
aussi précis question altitude ...


Un GPS tout seul c'est +/- 3m en x/y et c'est nul en y. Par construction.



Tu es un peu radical là ;)

L'erreur en Z est généralement double de celle en X/Y... ce qui est pas mal.

J'ai par contre un doute sur l'usage des grilles de transformation par 
les GPS. Les modèles actuels le font peut être mais quand j'ai commencé 
à jouer avec ces petites bêtes, ce n'était pas le cas.




Les GPS « de randonnées » on un altimètre barométrique. Faut étalonner.

Pour de la précision en GPS il faut aller vers :

https://fr.wikipedia.org/wiki/GPS_diff%C3%A9rentiel


Et le RTK...

https://medium.com/@cq94/rtklib-le-gps-haute-pr%C3%A9cision-abordable-138995258098

--
Christian Quest - OpenStreetMap France


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

Re: [OSM-talk-fr] Altitude des panneaux

[Christian Quest]

Le 23/07/2020 à 14:55, Yves P. a écrit :


Ce qui est gravé tu le mets dans inscription pas dans indication.


Oui pour une inscription gravée d'une stèle, d'un monument commémoratif…

Pour un panneau PDIPR, je met ça dans name (ou si c'est un chiffre, 
dans ref).


Pour le moment je ne saisi pas les autres "informations" : ni les 
directions, ni les distances ou les durées inscrits sur les "flèches 
directionnelles".
J'archive des photos et parfois je les publies dans Wikimedia ou dans 
Mapillary.


Yves, "vraie" mesure dans ele, "vraie inscription fausse" dans 
inscription,


Encore une fois, j'applique ici la règle "le terrain fait foi" car le 
nom et l'altitude font office d' "amère" et sont rendu sur les cartes.


Mais en théorie, il faudrait faire comme tu le précises.


dans note tu mets "incohérence de l'altitude" et peut-être ta source 
pour ele.


oui, note="altitude mesurée 1700m cf. http://source; ou le 
contraire note="altitude erronée inscrite 1650m"


Mais comme dit Eric, pas sûr que ta mesure ou la mesure du MNT soient 
meilleures que celles du panneau.



+1

Et quand le MNT est généré à partir d'un LIDAR, la surface dans une 
forêt représente le sol ou la canopée ?



MNT = Modèle Numérique de Terrain (donc le sol)

MNS = Modèle Numérique de Surface (donc canopée, haut des bâtiments, etc)

Un LIDAR brut, c'est plutôt un MNS, mais il peut avoir été retravaillé 
pour obtenir un MNT... tout comme on a les photos aériennes brutes et 
ortho-rectifiées même si c'est pas tout à fait le même process.



Sur les données STRM de la NASA, on a un MNS, car on distingue très bien 
le plateau des forêts... et même le pic de la Tour Eiffel !


Les courbes de niveau qu'on produit souvent avec ces données sont donc à 
prendre avec des pincettes ;)



--
Christian Quest - OpenStreetMap France

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

Re: [OSM-talk-fr] Altitude des panneaux

[Yves P.]

> Ce qui est gravé tu le mets dans inscription pas dans indication.
> 
Oui pour une inscription gravée d'une stèle, d'un monument commémoratif…

Pour un panneau PDIPR, je met ça dans name (ou si c'est un chiffre, dans ref).

Pour le moment je ne saisi pas les autres "informations" : ni les directions, 
ni les distances ou les durées inscrits sur les "flèches directionnelles".
J'archive des photos et parfois je les publies dans Wikimedia ou dans Mapillary.
> Yves, "vraie" mesure dans ele, "vraie inscription fausse" dans inscription,
> 
Encore une fois, j'applique ici la règle "le terrain fait foi" car le nom et 
l'altitude font office d' "amère" et sont rendu sur les cartes.

Mais en théorie, il faudrait faire comme tu le précises.
> dans note tu mets "incohérence de l'altitude" et peut-être ta source pour 
> ele. 
> 
oui, note="altitude mesurée 1700m cf. http://source; ou le contraire 
note="altitude erronée inscrite 1650m"
> Mais comme dit Eric, pas sûr que ta mesure ou la mesure du MNT soient 
> meilleures que celles du panneau.
> 
+1

Et quand le MNT est généré à partir d'un LIDAR, la surface dans une forêt 
représente le sol ou la canopée ?

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

Re: [OSM-talk-fr] Segmentation des maisons

[Yves P.]

> Par contre, pour la re-segmentation des maisons, est-ce que c'est la bonne 
> approche de la faire moi-même ?
Je simplifie manuellement les bâtiments quand ils ont été découpés par les 
parcelles cadastrales.

> Est-ce qu'un futur import du Cadastre risque de défaire tous mes changements, 
> par exemple, ou il y a une perte d'information en fusionnant les polygones ?
Je fais des mises à jour manuelles.

> Par contre je n'ai pas d'outil facilitant la tâche (j'aimerai bien :-))
> 
Il existe le greffon conflation 
 pour JOSM  et 
peut-être https://cadastre.damsy.net  mais je ne 
les maitrise pas.

> 
> Voici un exemple concret : on voit ceci sur openstreetmap.org 
>  :
> Les maisons 11, 9, 7 et 5 sont segmentées à cause de l'import du Cadastre (le 
> "jaune clair" semble indiquer des terrasses et parties non "fermées" de la 
> maison) :
Sur la 11, je ne fusionnerait que les 2 morceaux de "terrasse".

Globalement, faut-il distinguer les parties "sans mur" du reste ?
Les différentes "parcelles" d'un immeuble ?

Non, car ça complique la mise à jour, le rendu est parfois bizarre ou moins 
lisible, et ça oblige parfois à faire un multi-polygone si on veut taguer tout 
le bâtiment (par exemple une école et ses préaux).

Oui, car parfois ça permet de situer les entrées (par exemple une salle 
communale avec une partie couverte)

Exemple de bizarrerie : le toit d'un préau 
 d'école 
est au niveau de la place. Le monument aux mort 
 est 
installé dessus.
Un contributeur précédent avait fait un multi polygone pensant que le monument 
était un "trou" dans le préau.

Ceci n'est donc pas à simplifier "automatiquement" : on peut éventuellement 
enlever l'attribut building=yes au monument.


Les 3 bâtiments 
 de l'autre 
côté de la route de la pépinière sont-ils un seul et même immeuble, 2 ou 3 
immeubles accolés ??
La vue de la rue  montre que c'est une 
grange et une villa, avec probablement un garage en sous sol entre les 2.

Dans le doute, souvent je m'abstient de tout fusionner.
Comme l'a rappelé Christian, il y a tellement à faire avant ;)

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

Re: [OSM-talk-fr] Altitude des panneaux

[osm . sanspourriel]

Le 23/07/2020 à 10:01, Yves P. - yves.prat...@gmail.com a écrit :

mais une élévation au dessus du géoïde 


Sur les courbes du SHOM j'ai vu que la différence pouvait approcher les
50 m et effectivement constaté en bord de mer où la mi-marée est un bon
repère. Ce qui confirme les dires de Christian lus après avoir écrit
cette phrase.

Le 23/07/2020 à 10:01, Yves P. - yves.prat...@gmail.com a écrit :

je mets dans "name" ce qui est écrit sur la bague verte en haut et qui
identifie le panneau.

Il faut le mettre dans "indication" ?


Ce qui est gravé tu le mets dans inscription pas dans indication.

Yves, "vraie" mesure dans ele, "vraie inscription fausse" dans
inscription, dans note tu mets "incohérence de l'altitude" et peut-être
ta source pour ele.

Mais comme dit Eric, pas sûr que ta mesure ou la mesure du MNT soient
meilleures que celles du panneau.

Dans HebdOSM on a vu passer un lien vers un article sur les MNT et MNS :
il n'est pas rare que le le terrain calculé conserve une part du bâti
entrainant une sous-estimation du risque de subduction.

On voit passer des isolignes "10 m" en mer.

1 m d'erreur en montagne ce n'est pas grave. 1 m dans un port ça peut
vouloir dire détruit.

Le 23/07/2020 à 11:20, Jacques Lavignotte - jacq...@lavignotte.org a écrit :


Un GPS tout seul c'est ± 3m en x/y et c'est nul en y. Par construction.


Pas nul, médiocre. Et surtout on veut des distances et dénivelés en
relatifs.

Le 23/07/2020 à 11:25, Eric SIBERT - courr...@eric.sibert.fr a écrit :

L'altitude, c'est la hauteur au-dessus du géoïde. Le géoïde, c'est le
niveau moyen de la mer (ou son extrapolation quand il n'y a pas de
mer). Le géoïde, c'est une surface physique unique. Après, sa
détermination peut être difficile. A quelques subtilités et erreurs de
calcul près l'altitude doit être la même, qu'on vienne de France ou
d'Italie.


Presque : l'altitude en France est calculée par rapport au niveau moyen
de la mer à Marseille. Même à Brest.

Oui à "quelques subtilités et erreurs de calcul près l'altitude" du
niveau moyen de la mer à Brest est de 0.

Le 23/07/2020 à 12:22, David Crochet - david.croc...@free.fr a écrit :

Le 23/07/2020 à 10:46, Christian Quest a écrit :

Les deux


Oui, mais on a plus de précision sur X et Y que Z, car sur X et Y,
j'aurais probablement plus de satellites proche de l'horizon qui me
permettront de corriger les erreurs que sur Z, car sur Z, j'ai la
Terre qui me cache la moitié des satellites sur cet axe


Non, que ce soit pour X, Y ou Z ce sont les mêmes satellites qui sont
visibles.

Jean-Yvon


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

Re: [OSM-talk-fr] Segmentation des maisons

[Cyrille37 OSM]

Bonjour,

Le 23/07/2020 à 13:24, André Maroneze a écrit :
Par contre, pour la re-segmentation des maisons, est-ce que c'est la 
bonne approche de la faire moi-même ? Est-ce qu'un futur import du 
Cadastre risque de défaire tous mes changements, par exemple, ou il y 
a une perte d'information en fusionnant les polygones ?


Il n'y a pas d'import automatique du Cadastre, il ne faut surtout pas.

Je ne vois pas l'intérêt de conserver ces segmentations ; puis-je donc 
les fusionner via JOSM ou un autre outil ?


Il n'y a pas intérêt à la conserver quand elle n'indique pas des 
éléments différents.


Par contre je n'ai pas d'outil facilitant la tâche (j'aimerai bien :-))

Cyrille37.


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

Re: [OSM-talk-fr] Segmentation des maisons

[André Maroneze]

D'accord, je retiens vos commentaires, en désactivant les quêtes liées aux
numéros de rue.

Par contre, pour la re-segmentation des maisons, est-ce que c'est la bonne
approche de la faire moi-même ? Est-ce qu'un futur import du Cadastre
risque de défaire tous mes changements, par exemple, ou il y a une perte
d'information en fusionnant les polygones ?

Voici un exemple concret : on voit ceci sur openstreetmap.org :

[image: osm.png]
Les maisons 11, 9, 7 et 5 sont segmentées à cause de l'import du Cadastre
(le "jaune clair" semble indiquer des terrasses et parties non "fermées" de
la maison) :
[image: cadastre.png]

Et sur StreetComplete, ça donne une quête par "morceau" :
[image: street-complete.png]
Je ne vois pas l'intérêt de conserver ces segmentations ; puis-je donc les
fusionner via JOSM ou un autre outil ?
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Altitude des panneaux

[Yves P.]

>> Cette valeur est très mauvaise si les satellites utilisés sont proche de la 
>> verticale, bien meilleure si les satellites sont proche de l'horizon.
> 
> Cela ne serait pas plutôt l'inverse ?
Tout à fait, merci de la correction :)

Voir Geometric dilution of precision 
, 
http://www.fdf-sarl.ch/le-gps-comment-ca-marche.html et 
https://cgeosbe.weebly.com/gnss.html

Une bonne précision verticale (VDOP la plus faible possible) donne une mauvaise 
précision horizontale (HDOP) et inversement (cf. triangle 
http://www.fdf-sarl.ch/_media/img/medium/gps-dop-values.png)

__
Yves


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

Re: [OSM-talk-fr] Altitude des panneaux

[David Crochet]

Bonjour

Le 23/07/2020 à 10:46, Christian Quest a écrit :
Les deux 


Oui, mais on a plus de précision sur X et Y que Z, car sur X et Y, 
j'aurais probablement plus de satellites proche de l'horizon qui me 
permettront de corriger les erreurs que sur Z, car sur Z, j'ai la Terre 
qui me cache la moitié des satellites sur cet axe


Cordialement

--

David Crochet


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

Re: [OSM-talk-fr] Altitude des panneaux

[Eric SIBERT]

L'altitude, c'est la hauteur au-dessus du géoïde. Le géoïde, c'est le 
niveau moyen de la mer (ou son extrapolation quand il n'y a pas de mer). 
Le géoïde, c'est une surface physique unique. Après, sa détermination 
peut être difficile. A quelques subtilités et erreurs de calcul près 
l'altitude doit être la même, qu'on vienne de France ou d'Italie.


Par ailleurs, comme déjà indiqué, il y a des grilles qui permettent de 
passer de l'ellipsoïde au géoïde. Les récepteurs GPS commencent par 
calculer une hauteur sur l'ellipsoïde. Ensuite ils utilisent une grille 
interne pour convertir en altitude et c'est généralement ce qu'ils nous 
affichent. Malheureusement, j'ai déjà vu une plage à 10 m d'altitude les 
quelques jours que j'ai passé à côté. La grille devait être 
insuffisante.


Enfin, on a des GPS avec capteur barométrique (mon Etrex 30). Ils 
passent leur temps à recaler le baromètre sur le GPS, ce qui ne résout 
pas le problème de grille mais permet de lisser les altitudes.


Pour revenir aux panneaux de rando, pour le moment, je ne mets que ce 
qui est sur le panneau même quand j'ai des doutes, parce que je ne suis 
pas sûr d'être meilleur.


Eric


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

Re: [OSM-talk-fr] Altitude des panneaux

[Jacques Lavignotte]

Le 23/07/2020 à 09:44, Cyrille37 OSM a écrit :
En même temps, 20 mètres sur l'altitude c'est difficile de savoir qui a 
raison. Pas sûr que nos petits GPS et le MNT OpenTopoMap soient aussi 
précis question altitude ...


Un GPS tout seul c'est +/- 3m en x/y et c'est nul en y. Par construction.

Les GPS « de randonnées » on un altimètre barométrique. Faut étalonner.

Pour de la précision en GPS il faut aller vers :

https://fr.wikipedia.org/wiki/GPS_diff%C3%A9rentiel

J.


--
GnuPg : 156520BBC8F5B1E3 Because privacy matters.
« Quand est-ce qu'on mange ? » AD (c) (tm)

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

Re: [OSM-talk-fr] Altitude des panneaux

[Christian Quest]

Le 23/07/2020 à 10:08, David Crochet a écrit :

Bonjour

Le 23/07/2020 à 10:01, Yves P. a écrit :
Cette valeur est très mauvaise si les satellites utilisés sont proche 
de la verticale, bien meilleure si les satellites sont proche de 
l'horizon.


Cela ne serait pas plutôt l'inverse ?



Les deux ;)

Il en faut plusieurs répartis dans tout le ciel pour avoir le meilleur 
calcul.



Par contre, une altitude GPS sur l'ellipsoïde est décalée par rapport à 
nos altitudes officielles par rapport au niveau de la mer à Marseille... 
et ce décalage varie en plus sur tout le territoire.


Les grilles pour passer de l'un à l'autre se trouvent ici: 
https://geodesie.ign.fr/index.php?page=grilles


Le plus facile pour connaître localement la différence, c'est de 
consulter la fiche d'une borne géodésique proche, par exemple: 
https://geodesie.ign.fr/fiches/pdf/7405607.pdf


Et là on a 2286m sur l'ellipsoïde (quasiment la même à quelques mm de 
celle du GPS), et 2233m "officiels niveau mer en France"... et oui, 53m 
de différence !



Les courbes de niveau calculées à partir des modèles de surface mondiaux 
(NASADEM, STRM, ASTER, etc) sont à une altitude ellipsoïde.


Les altitudes sur les panneaux sont "locales" et pour le Mont-Blanc, il 
est même possible qu'un panneau français et italien côté à côte aient 
une belle différence ;)



--
Christian Quest - OpenStreetMap France


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

Re: [OSM-talk-fr] Altitude des panneaux

[David Crochet]

Bonjour

Le 23/07/2020 à 10:01, Yves P. a écrit :
Cette valeur est très mauvaise si les satellites utilisés sont proche 
de la verticale, bien meilleure si les satellites sont proche de 
l'horizon.


Cela ne serait pas plutôt l'inverse ?

Cordialement

--
David Crochet


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

Re: [OSM-talk-fr] Altitude des panneaux

[Yves P.]

> En même temps, 20 mètres sur l'altitude c'est difficile de savoir qui a 
> raison. Pas sûr que nos petits GPS et le MNT OpenTopoMap soient aussi précis 
> question altitude …
D'autant plus q'un GPS ne "mesure" pas une altitude, mais une élévation au 
dessus du géoïde 
Cette valeur est très mauvaise si les satellites utilisés sont proche de la 
verticale, bien meilleure si les satellites sont proche de l'horizon.

> Ah tiens ça me fait dire que j'ai peut-être faux sur l'attribut name.
non, tout est parfait 
> 
> Comme on voit sur https://www.openstreetmap.org/node/3874089567 
> 
> 
> je mets dans "name" ce qui est écrit sur la bague verte en haut et qui 
> identifie le panneau.
> 
> Il faut le mettre dans "indication" ?
Surtout pas, ni Nominatim, ni les moteurs de rendu ne pourront l'utiliser.

Pour en revenir à l'altitude sur le panneau, c'est approximatif. J'ai trouvé 2 
panneaux identiques sur un parking mais avec un dénivelé entre les 2 de 
plusieurs mètres.
Même si c'est erroné, je pense qu'il faut laisser l'erreur car ça sert de 
repère et de référence dans les descriptions d'itinéraires.
Et il faut signaler l'erreur avec la clé note=*

Si l'erreur est flagrante, demander au gestionnaire de corriger le panneau ?
__
Yves


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

Re: [OSM-talk-fr] Altitude des panneaux

[Cyrille37 OSM]

Salut,

Le 23/07/2020 à 09:39, Christian Quest a écrit :

Le 23/07/2020 à 08:59, Arnaud Champollion a écrit :

Bonjour,

Une question sur l'attribut "ele".

Sur un panneau de randonnée PDIPR 
https://www.openstreetmap.org/node/3874089567 , il est écrit :


"altitude : 650m"

Je pense qu'il y a erreur, c'est plutôt 630m, à la fois par cohérence 
avec le panneau précédent à 610m et aussi en vérifiant les courbes de 
niveau avec le fond raster OpenTopoMap.


Alors le terrain prime, mais quel terrain :

--> l'indication sur le panneau ou l'altitude réelle ?

Merci de vos avis. 



Le terrain prime... dans une certaine limite ;)

Quand il s'agit d'une indication, ce n'est pas "le terrain".

Un panneau obsolète par exemple, ne devrait pas être repris au nom de 
cette règle.


Là, si sur le terrain tu peux constater voir mesurer les 630m, ça 
prime sur une indication erronée sur un panneau.


En même temps, 20 mètres sur l'altitude c'est difficile de savoir qui a 
raison. Pas sûr que nos petits GPS et le MNT OpenTopoMap soient aussi 
précis question altitude ...


Cyrille37.



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

Re: [OSM-talk-fr] Altitude des panneaux

[Arnaud Champollion]

Le 23/07/2020 à 09:34, Florian LAINEZ a écrit :

Par exemple : inscription=Col de la Vanoise. Altitude : 650m


Ah tiens ça me fait dire que j'ai peut-être faux sur l'attribut name.

Comme on voit sur https://www.openstreetmap.org/node/3874089567

je mets dans "name" ce qui est écrit sur la bague verte en haut et qui 
identifie le panneau.


Il faut le mettre dans "indication" ?



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

Re: [OSM-talk-fr] Altitude des panneaux

[Christian Quest]

Le 23/07/2020 à 08:59, Arnaud Champollion a écrit :

Bonjour,

Une question sur l'attribut "ele".

Sur un panneau de randonnée PDIPR 
https://www.openstreetmap.org/node/3874089567 , il est écrit :


"altitude : 650m"

Je pense qu'il y a erreur, c'est plutôt 630m, à la fois par cohérence 
avec le panneau précédent à 610m et aussi en vérifiant les courbes de 
niveau avec le fond raster OpenTopoMap.


Alors le terrain prime, mais quel terrain :

--> l'indication sur le panneau ou l'altitude réelle ?

Merci de vos avis. 



Le terrain prime... dans une certaine limite ;)

Quand il s'agit d'une indication, ce n'est pas "le terrain".

Un panneau obsolète par exemple, ne devrait pas être repris au nom de 
cette règle.


Là, si sur le terrain tu peux constater voir mesurer les 630m, ça prime 
sur une indication erronée sur un panneau.



Même cas avec les noms de rues mal orthographiés... on peut conserver 
l'info du mauvais nom, mais c'est le nom sans faute qu'on doit mettre 
dans OSM car on cherche à monter en qualité pas à recopier des erreurs 
manifestes.



--
Christian Quest - OpenStreetMap France


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

Re: [OSM-talk-fr] Altitude des panneaux

[Florian LAINEZ]

Salut Arnaud,
J'ai déjà eu ce problème en faisant le tour du mont blanc. Perso j'ai
indiqué avec ele l'altitude de mon GPS de rando (pas celle du smartphone !)
si elle était assez éloignée de celle indiquée sur le panneau. Dans la
majorité des cas c'était néanmoins la même. Puis je rajoutais  "altitude :
650m" dans le tag "inscription".
Par exemple : inscription=Col de la Vanoise. Altitude : 650m

Si l'altitude du GPS et du panneau était assez proche (moins de 20m de
diff), je mettait ça sur le dos de l'arrondi et des limites de précision du
GPS et inscrivait l'altitude indiquée sur le panneau dans ele.

Le jeu. 23 juil. 2020 à 08:59, Arnaud Champollion <
arnaud.champoll...@linux-alpes.org> a écrit :

> Bonjour,
>
> Une question sur l'attribut "ele".
>
> Sur un panneau de randonnée PDIPR
> https://www.openstreetmap.org/node/3874089567 , il est écrit :
>
> "altitude : 650m"
>
> Je pense qu'il y a erreur, c'est plutôt 630m, à la fois par cohérence
> avec le panneau précédent à 610m et aussi en vérifiant les courbes de
> niveau avec le fond raster OpenTopoMap.
>
> Alors le terrain prime, mais quel terrain :
>
> --> l'indication sur le panneau ou l'altitude réelle ?
>
> Merci de vos avis.
>
> Arnaud
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>


-- 

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

Re: [OSM-talk-fr] Segmentation des maisons

[Christian Quest]

Le 23/07/2020 à 08:20, Yves P. a écrit :

Est-ce que la meilleure approche est bien de fusionner ces petits polygones 
pour n'en faire qu'un ? Sinon, StreetComplete demande par exemple de donner un 
numéro de rue à une partie de maison, ou alors il faut répondre 3 fois aux 
mêmes questions (type de maison, nombre d'étages, forme du toit, etc).

La bonne approche pour moi est de mettre le n° de rue sur un noeud, et sauf 
exception, jamais sur les polygones.

Je trouve que la quête StreetComplete sur les n° de maison est inadaptée, du 
moins pour la France.


Je plussoie pour l'adresse, plutôt en ponctuel que sur le bâti.


Pour les bâtiments segmentés, ceux-ci le sont le plus souvent à cause 
des limites de parcelles dans le cadastre. Un bâtiment à cheval sur 
plusieurs parcelles figure dans les plans cadastraux sous la forme de 
plusieurs polygones et comme c'est ceux-ci qu'on récupère on a cette 
segmentation cadastrale.


Adresses / bâtiments / parcelles... trois objets différents avec des 
relations N/N pour chaque, voilà pourquoi l'adresse doit plus 
logiquement être portée par un objet dédié et pas dépendre d'un autre 
(bâti).


--
Christian Quest - OpenStreetMap France


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

Re: [OSM-talk-fr] SPAM, Re: Objet temporairement absent

[Arnaud Champollion]

Le 19/07/2020 à 14:35, Gaël Simon a écrit :

Bonjour, tu peux remplacer amenity par disused:amenity avec un commentaire 
indiquant le caractère temporaire
Bonne journée


OK merci, j'ai aussi ajouté un fixme pour penser à surveiller la 
réouverture.


Arnaud

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

[OSM-talk-fr] Altitude des panneaux

[Arnaud Champollion]

Bonjour,

Une question sur l'attribut "ele".

Sur un panneau de randonnée PDIPR 
https://www.openstreetmap.org/node/3874089567 , il est écrit :


"altitude : 650m"

Je pense qu'il y a erreur, c'est plutôt 630m, à la fois par cohérence 
avec le panneau précédent à 610m et aussi en vérifiant les courbes de 
niveau avec le fond raster OpenTopoMap.


Alors le terrain prime, mais quel terrain :

--> l'indication sur le panneau ou l'altitude réelle ?

Merci de vos avis.

Arnaud

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

Re: [OSM-talk-fr] Segmentation des maisons

[Yves P.]

> Est-ce que la meilleure approche est bien de fusionner ces petits polygones 
> pour n'en faire qu'un ? Sinon, StreetComplete demande par exemple de donner 
> un numéro de rue à une partie de maison, ou alors il faut répondre 3 fois aux 
> mêmes questions (type de maison, nombre d'étages, forme du toit, etc).
La bonne approche pour moi est de mettre le n° de rue sur un noeud, et sauf 
exception, jamais sur les polygones.

Je trouve que la quête StreetComplete sur les n° de maison est inadaptée, du 
moins pour la France.

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

[OSM-talk-fr] Segmentation des maisons

[André Maroneze]

Bonjour,

En utilisant StreetComplete, je me rends compte que la plupart des maisons
dans ma ville a été segmentée en plusieurs polygones, sans doute à cause de
petites différences d'hauteur entre les parties de la maison, et du fait
que ces sous-divisions proviennent du Cadastre.

Il y a également quelques cas de maisons non divisées.

Est-ce que la meilleure approche est bien de fusionner ces petits polygones
pour n'en faire qu'un ? Sinon, StreetComplete demande par exemple de donner
un numéro de rue à une partie de maison, ou alors il faut répondre 3 fois
aux mêmes questions (type de maison, nombre d'étages, forme du toit, etc).

Et si c'est la bonne approche, est-ce que JOSM a un outil pour faciliter ça
?
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr