Re: [OSM-talk-fr] Mapillary : Orientation

2017-07-07 Thread rainerU
Am 05.07.2017 um 16:30 schrieb Eric Sibert:
> - L'appli Mapillary enregistre la position des photos avec une mauvaise 
> qualité
Précision : Mapillary enregistre la position que fournit le module GPS du
téléphone ets qui est souvent de mauvaise qualité par rapport à un appareil GPS
dédié.

> - Mapillary déduit l'orientation des photos à partir du mouvement du GPS. 
> C'est
> correct quand on est en déplacement mais c'est mauvais quand on est à l'arrêt 
> au
> feu
Mon ancien smartphone avait un compas et Mapillary utilisait bien l'orientation
fourni par celui-ci (c'était au mois d'avril 2017). Si aujourd’hui ce n'est plus
le cas ce serait une régression dans l'appli Mapillary et il faut le signaler
sur le forum ou sur github [1].

> Je fais comment pour envoyer à Mapillary des photos bien localisées et bien
> orientées aussi bien en mouvement qu'à l'arrêt?
Les différentes options on déjà été données dans ce fil. J'utilise Josm et les
greffons photo_geotagging et photoadjust. Je charge les photos et la trace GPX
du Garmin dans JOSM, je corrèle les photos avec la trace GPX, j'ajuste la
position si nécessaire et j’enregistre les photos avec la position corrigé.
Ensuite je télécharge les photos avec le script /upload_with_preprocessing.py
qui permet aussi d'ajouter l'orientation déduite du mouvement. On peut aussi
télécharger dans le navigateur par le site de Mapillary. Dans ce cas, il faut
ajuster l'orientation une fois les photos sont publiés.


[1] https://github.com/mapillary/mapillary_issues


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


[OSM-talk-fr] Orthophotographies en erreur ?

2017-07-07 Thread Romain MEHUT
Bonjour,

Je n'ai plus accès aux orthophotographies hébergées par OSM-FR. J'ai le
message "Erreur: Problem loading tile". C'est pareil chez vous ?

Merci.

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


Re: [OSM-talk-fr] Mapillary Forum

2017-07-07 Thread rainerU
C'est peut-être lié à ça :

https://forum.mapillary.com/t/important-forum-disturbances-and-losses-7-july-2017/1045



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


Re: [OSM-talk-fr] Mapillary Forum

2017-07-07 Thread THEVENON Julien

De : rainerU 
À : talk-fr@openstreetmap.org 
Envoyé le : Vendredi 7 juillet 2017 12h49
Objet : Re: [OSM-talk-fr] Mapillary Forum


> C'est peut-être lié à ça :

> https://forum.mapillary.com/t/important-forum-disturbances-and-losses-7-july-2017/1045


Oui ca semble correspondre, j ai recu le meme mail par Mapillary

Julien

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


[OSM-talk-fr] quid erreur BANO ?

2017-07-07 Thread cyrille+talk-fr

Salut

Il y a une erreur sur le rendu BANO. De quelle source provient cette 
erreur ?


le "2 Rue du Docteur Bretonneau, Tours" qui est hors de la rue, dans 
l'université rue des Tanneurs.


Sur la carte: 
http://tile.openstreetmap.fr/~cquest/leaflet/bano.html#18/47.39547/0.68348


copie d'écran : https://framapic.org/L2jxw2zETaVn/klKKM35rIQcE.png

Merci de vos lumières

Cyrille.

--

  Cyrille Giquello - 06 32 33 02 18 - cyri...@giquello.fr - 37000 Tours

 (¯`·._.·[   Coopérateur @ Artefacts - http://artefacts.coop   ]·._.·´¯)
ø¤º°`°º¤ø,¸¸,ø¤º°`°º¤ø,¸¸,ø¤º°`°º¤ø,¸¸,ø¤º°`°º¤ø¸¸,ø¤º°`°º¤ø¸¸,ø¤º°`°º¤ø


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


Re: [OSM-talk-fr] Questions de tagging pour des objets en lien avec les services de secours

2017-07-07 Thread Eric Brosselin - Osm

Bonjour,


Quelques exemples d'utilisation ici :
https://www.openstreetmap.org/node/4547027386




Merci de me citer


_Pour information_ :
J'ai un jour (je ne sais plus comment) récupéré sur le site de la DREAL 
une partie des marqueurs de crues de la Loire (depuis Tours je crois)
En les chargeant dans JOSM je me suis aperçu que la géolocalisation 
n'était pas super précise
Il y avait environ 4 à 6m de décalage avec la position réelle. C'est un 
facteur auquel il faut penser.




Le 06/07/2017 à 10:57, Thibaud B a écrit :
Concernant les repère de crues il y a déjà un tag documenté dans le 
wiki ça peut être une bonne base :


https://wiki.openstreetmap.org/wiki/FR:Tag:historic%3Dhighwater_mark



Il y a également quelqu'un qui a crée ce tag  "Flood mark" >>> 
http://wiki.openstreetmap.org/wiki/Key:flood_mark

Les utilisations (261) sont uniquement en Pologne
et apparemment c'est la suite de ce tag "High water mark" >>> 
http://wiki.openstreetmap.org/wiki/Key:high_water_mark

20 utilisations seulement !

Il suggère aussi de mettre des tags «connexes» comme historic=memorial , ...


Certains SDIS posent maintenant des plaques officielles et normalisées 
qu'il serait à mon avis intéressant d'ajouter

dans OSM.
Il y a une base officielle à laquelle on peut contribuer  >>> 
https://www.reperesdecrues.developpement-durable.gouv.fr

Ils utilisent OpenStreetMap comme fond de carte


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


Re: [OSM-talk-fr] Questions de tagging pour des objets en lien avec les services de secours

2017-07-07 Thread JB
Avec un peu de retard à l'allumage, j'aurais quand même voulu signaler 
man_made=monitoring_station + monitoring:water_level, qui me semble 
beaucoup plus adapté que le historic=high_water_mark qui est plus 
orienté historic/tourism.

https://wiki.openstreetmap.org/wiki/Key:monitoring:water_level
Ensuite, je plussoie tout-à-fait Nicolas sur le fait qu'on peut 
difficilement demander un filtrage fin pour une première utilisation. En 
première utilisation, on va filtrer amenity=fire_station, sans regarder 
les autres tag (seasonal et autres). Pour cette raison, je pense aussi 
que réutiliser amenity=fire_station sur ce qui n'en est pas vraiment une 
(à ce que j'ai compris) n'est pas une bonne idée.
(Est-ce qu'on taggue amenity=restaurant sur une cantine scolaire ? Si 
oui, est-ce vraiment une bonne idée ?).

JB.

Le 07/07/2017 à 19:26, Eric Brosselin - Osm a écrit :

Bonjour,


Quelques exemples d'utilisation ici :
https://www.openstreetmap.org/node/4547027386




Merci de me citer


_Pour information_ :
J'ai un jour (je ne sais plus comment) récupéré sur le site de la 
DREAL une partie des marqueurs de crues de la Loire (depuis Tours  je 
crois)
En les chargeant dans JOSM je me suis aperçu que la géolocalisation 
n'était pas super précise
Il y avait environ 4 à 6m de décalage avec la position réelle. C'est 
un facteur auquel il faut penser.




Le 06/07/2017 à 10:57, Thibaud B a écrit :
Concernant les repère de crues il y a déjà un tag documenté dans le 
wiki ça peut être une bonne base :


https://wiki.openstreetmap.org/wiki/FR:Tag:historic%3Dhighwater_mark



Il y a également quelqu'un qui a crée ce tag  "Flood mark" >>> 
http://wiki.openstreetmap.org/wiki/Key:flood_mark

Les utilisations (261) sont uniquement en Pologne
et apparemment c'est la suite de ce tag "High water mark" >>> 
http://wiki.openstreetmap.org/wiki/Key:high_water_mark

20 utilisations seulement !

Il suggère aussi de mettre des tags «connexes» comme historic=memorial 
, ...



Certains SDIS posent maintenant des plaques officielles et 
normalisées qu'il serait à mon avis intéressant d'ajouter

dans OSM.
Il y a une base officielle à laquelle on peut contribuer >>> 
https://www.reperesdecrues.developpement-durable.gouv.fr

Ils utilisent OpenStreetMap comme fond de carte




___
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] Orthophotographies en erreur ?

2017-07-07 Thread Christian Quest
Problème actuellement sur ce service à cause du disque dur qui a 
quelques problèmes de secteurs défectueux.


Je suis en train de remettre ça au propre...


Le 07/07/2017 à 11:14, Romain MEHUT a écrit :

Bonjour,

Je n'ai plus accès aux orthophotographies hébergées par OSM-FR. J'ai 
le message "Erreur: Problem loading tile". C'est pareil chez vous ?


Merci.

Romain



--
Christian Quest - OpenStreetMap France


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


Re: [OSM-talk-fr] quid erreur BANO ?

2017-07-07 Thread Christian Quest

Le 07/07/2017 à 16:27, cyrille+talk...@giquello.fr a écrit :

Salut

Il y a une erreur sur le rendu BANO. De quelle source provient cette 
erreur ?




rouge = cadastre non rapproché d'OSM


le "2 Rue du Docteur Bretonneau, Tours" qui est hors de la rue, dans 
l'université rue des Tanneurs.


Sur la carte: 
http://tile.openstreetmap.fr/~cquest/leaflet/bano.html#18/47.39547/0.68348


copie d'écran : https://framapic.org/L2jxw2zETaVn/klKKM35rIQcE.png

Merci de vos lumières



Comme quoi le cadastre n'est pas parfait sur les adresses !

--
Christian Quest - OpenStreetMap France


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


Re: [OSM-talk-fr] Questions de tagging pour des objets en lien avec les services de secours

2017-07-07 Thread Eric Brosselin - Osm

Le 07/07/2017 à 19:58, JB a écrit :
Avec un peu de retard à l'allumage, j'aurais quand même voulu signaler 
man_made=monitoring_station + monitoring:water_level, qui me semble 
beaucoup plus adapté que le historic=high_water_mark qui est plus 
orienté historic/tourism.

https://wiki.openstreetmap.org/wiki/Key:monitoring:water_level


Ah non je ne pense pas ce n'est pas la même chose qu'un repère de crue.

Les *monitoring stations* (bien regarder la clé générale >>> 
https://wiki.openstreetmap.org/wiki/FR:Tag:man_made%3Dmonitoring_station 
) sont des stations de mesure qui affichent (critère "display")  et / ou 
enregistrent (critère "recording") des informations  dans différents 
secteurs de surveillance.
_Exemples_ :  niveau des eaux, activité sismique, météo, trafic routier, 
niveau des radiations,  et même activité météoritique !


La demande originelle portait sur les repères (marqueurs) de crues avec 
les hauteurs d'eau.
Donc oui c'est «historique» à partir du moment où on a un "souvenir" de 
la crue qui prend la forme d'une plaque  (désormais officielle) avec une 
hauteur et une date.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] Questions de tagging pour des objets en lien avec les services de secours

2017-07-07 Thread marc marc
Le 07. 07. 17 à 19:58, JB a écrit :
> réutiliser amenity=fire_station sur ce qui n'en est pas vraiment une 
> (à ce que j'ai compris) n'est pas une bonne idée.
je suis d'accord avec toi sur ce point.
j'avais cru comprendre que c'était une caserne minimaliste "construite" 
pour les " mois d'été puis redémontrée.
si ce n'est pas une caserne, fire_station n'est pas le bon tag
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] Questions de tagging pour des objets en lien avec les services de secours

2017-07-07 Thread JB
Oups. Il y a des vendredis soir où je ferais mieux d'aller dormir au 
lieu d'écrire…


Le 07/07/2017 à 20:19, Eric Brosselin - Osm a écrit :

Le 07/07/2017 à 19:58, JB a écrit :
Avec un peu de retard à l'allumage, j'aurais quand même voulu 
signaler man_made=monitoring_station + monitoring:water_level, qui me 
semble beaucoup plus adapté que le historic=high_water_mark qui est 
plus orienté historic/tourism.

https://wiki.openstreetmap.org/wiki/Key:monitoring:water_level


Ah non je ne pense pas ce n'est pas la même chose qu'un repère de crue.

Les *monitoring stations* (bien regarder la clé générale >>> 
https://wiki.openstreetmap.org/wiki/FR:Tag:man_made%3Dmonitoring_station 
) sont des stations de mesure qui affichent (critère "display") et / 
ou enregistrent (critère "recording") des informations  dans 
différents secteurs de surveillance.
_Exemples_ :  niveau des eaux, activité sismique, météo, trafic 
routier, niveau des radiations,  et même activité météoritique !


La demande originelle portait sur les repères (marqueurs) de crues 
avec les hauteurs d'eau.
Donc oui c'est «historique» à partir du moment où on a un "souvenir" 
de la crue qui prend la forme d'une plaque  (désormais officielle) 
avec une hauteur et une date.





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


Re: [OSM-talk-fr] Mapillary : Orientation

2017-07-07 Thread Eric SIBERT

- Mapillary déduit l'orientation des photos à partir du mouvement du GPS. C'est
correct quand on est en déplacement mais c'est mauvais quand on est à l'arrêt au
feu

Mon ancien smartphone avait un compas et Mapillary utilisait bien l'orientation
fourni par celui-ci (c'était au mois d'avril 2017). 


En fait, il y a un truc que je ne comprends pas.

Aujourd'hui, j'ai fait une séquence en visant perpendiculairement à mon 
déplacement, à droite*:


https://www.mapillary.com/map/im/FASZg6rAv-znbXGsYOQX_g

Quand je regarde l'image et surtout les flèches au sol indiquant le 
déplacement, c'est bon. Elles sont bien perpendiculaire à la direction 
de visée.


Par contre, sur la carte, les cônes indiquant la direction de prise de 
vue ne sont pas bons. Ils sont dans le sens de déplacement. Idem si je 
vais dans josm.


Ma conclusion est qu'il y a une incohérence chez Mapillary en ligne. 
Vous êtes d'accord???


Eric



* smartphone avec compas et dernière version de Mapillary pour Android. 
Téléversement direct depuis le smartphone.


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


Re: [OSM-talk-fr] Orthophotographies en erreur ?

2017-07-07 Thread Philippe Verdy
Les secteurs défectueux sur un RAID ça finit assez vite par faire mal
(d'autant plus que bon nombre de contrôleurs RAID ont assigné une taille de
table limitée pour les réallouer ailleurs et on a peu de contrôle sur la
quantité de secteurs à garder en réserve). On a plus de facilité avec un
RAID logiciel (même si c'est un peu moins performant) car ils peuvent mieux
maitriser chacun des disques indépendemmant, et on a plus de solutions pour
remonter une partition ailleurs.

Si tu es en RAID5, assez vite c'est tout le volume qui va tomber en entier
avec des corruptions en cascade non réparables (en RAID6 on a encore le
temps d'intervenir: avec un disque en panne, le RAID6 se comporte pendant
sa mise hors service comme du RAID5, un peu moins performant quand même car
on n'a pas la parallélisation en miroir des deux disques de "spare"; mais
peu de controleurs font du RAID6, et le RAID6 coute cher sur des SSD et ne
fonctionne qu'avec de bons controleurs un nombre suffisant assez de ports;
sur bien des cartres mères on est limité à 6 ports SATA, dont un SSD
système, un DVDROM amorçable, il reste 4 ports donc un RAID6 uniquement sur
4 disques).

Il existe des alternatives réseau au RAID sur ports SATA, mais là encore
c'est plus cher (et souvent pas supporté pour booter la machine, sauf une
machine virtuelle, mais on reporte le problème au boot de l'OS hyperviseur
qui cependant devrait être assez basique et ne pas avoir besoin de gros
volume ni besoin réellement d'être en RAID: on a plus vite fait de
réinitialiser un disque unique amorçable sur un petit SSD avec une image OS
standard et juste les quelques données pour reconnecter oui énumérer les
machines virtuelles: ces données de configuration peu nombreuses sont
faciles à remettre depuis un minuscule fichier backup, qui peut aussi être
préintégré à l'image de base de l'OS hyperviseur sous forme d'un petit
script shell consultant une ressource réseau pour la récupérer: ce type de
solution est de toute façon à préparer à l'avance pour prévenir d'autres
incidents majeurs sur un OS, tel qu'une infection par un trou de sécurité
non détecté ou un bogue logiciel... ou un des nombreux "backdoors" que la
NSA a glissé dans les hyperviseurs connus ou dans les firmwares matériels
pour passer outre les sécurités logicielles des OS même virtualisés ou des
hyperviseurs, ou dans les drivers propriétaires pour différents OS).

Tout ça sur un serveur nu ça coûte cher en matériel (on a souvent peu de
choix en terme de compatiblité), alors qu'on a des solutions virtualisés
hébergées sur des grappes de serveurs à très haute redondance mais
supportant beaucoup de machines virtuelles avec des disques nombreux. Les
solutions "RAID-like" pour les hyperviseurs de ces serveurs ont bien plus
de facilités, mais là encore le "ticket d'entrée" est cher ne serait-ce que
pour avoir des images disque iSCSI sur un réseau fibré très rapide (où il
faut aussi des switches rapides et chers permettant de commuter des
contrôleurs et assurer la redondance et reconfigurations à chaud sans
arrêter les applications et services).



Le 7 juillet 2017 à 20:11, Christian Quest  a
écrit :

> Problème actuellement sur ce service à cause du disque dur qui a quelques
> problèmes de secteurs défectueux.
>
> Je suis en train de remettre ça au propre...
>
>
>
> Le 07/07/2017 à 11:14, Romain MEHUT a écrit :
>
>> Bonjour,
>>
>> Je n'ai plus accès aux orthophotographies hébergées par OSM-FR. J'ai le
>> message "Erreur: Problem loading tile". C'est pareil chez vous ?
>>
>> Merci.
>>
>> Romain
>>
>
>
> --
> Christian Quest - OpenStreetMap France
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] Questions de tagging pour des objets en lien avec les services de secours

2017-07-07 Thread osm . sanspourriel

Le 07/07/2017 à 20:31, marc marc - marc_marc_...@hotmail.com a écrit :


Le 07. 07. 17 à 19:58, JB a écrit :

réutiliser amenity=fire_station sur ce qui n'en est pas vraiment une
(à ce que j'ai compris) n'est pas une bonne idée.

je suis d'accord avec toi sur ce point.
j'avais cru comprendre que c'était une caserne minimaliste "construite"
pour les " mois d'été puis redémontrée.
si ce n'est pas une caserne, fire_station n'est pas le bon tag
___
Tu dis que c'est une caserne minimaliste mais si ce n'est pas une 
caserne ce n'est pas le bon tag.
Si la bonne définition c'est "caserne minimaliste" c'est donc une 
caserne à décrire comme telle mais à qualifier par un autre attribut 
style importance, category... à définir ou réutiliser.

category=minor?
Une cantine scolaire, tu ne dis pas pas que c'est un restaurant, mais ce 
que c'est une cantine et tu précises scolaire.


Si par contre tu dis que c'est un camp de fortune avec un parking pour 
les véhicules de pompiers, OK pour un attribut  complètement différent


Si on ne laisse que les fondations permanent=no et seasonal=yes.
Si on laisse le bâtiment vide simplement seasonal=yes.

JB, c'est peut-être moi en parlant d'échelles de mesures (en précisant 
que ce n'était pas la même chose) qui t'ai induit en erreur. Souvent les 
marques historiques ne sont pas très loin des points de mesure. Sinon 
comme qui dirait il y a un problème.


Jean-Yvon

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


Re: [OSM-talk-fr] Plusieurs données libres qui pourraient améliorer osm

2017-07-07 Thread Jérôme Amagat
Le 6 juillet 2017 à 16:34, François Lacombe  a
écrit :

> Bonjour Jérôme,
>
>
> Le 6 juillet 2017 à 02:40, Jérôme Amagat  a
> écrit :
>
>> - Données sur les installations radioélectriques de plus de 5 watts (
>> https://www.data.gouv.fr/fr/datasets/donnees-sur-les-install
>> ations-radioelectriques-de-plus-de-5-watts-1/ )
>>
>> il y a déjà eu une discussion en rapport avec cette donnée sur cette
>> liste, et il n’y a pas les tags pour tout intégrer à osm mais une chose
>> pourrait être intégrer c’est les supports des « antennes »
>>
>> ces supports sont classé dans différentes catégories :
>> Sémaphore;Phare;Château d'eau - réservoir;Immeuble;Local
>> technique;Mât;Intérieur galerie;Intérieur sous-terrain;Tunnel;Mât béton;Mât
>> métallique;Pylône;Bâtiment;Monument historique;Monument religieux;Pylône
>> autoportant;Pylône autostable;Pylône haubané;Pylône treillis;Pylône
>> tubulaire;Silo;Ouvrage d'art (pont, viaduc);Tour hertzienne;Dalle en
>> béton;Support non décrit;Fût;Tour de contrôle;Contre-poids au
>> sol;Contre-poids sur shelter;Support DEFENSE;pylône arbre;Ouvrage de
>> signalisation (portique routier, panneau routier, panneau
>> publicitaire);Balise ou bouée
>>
>> Je pense surtout aux pylônes, tour hertzienne et mat qui pourrait être
>> ajouté avec les tag man_made=tower ou man_made=communications_tower.
>>
>
> +1
> On peut également compléter les tags operator=*, height=* et par
> conséquent ref:FR:ANFR avec ces fichiers pour les supports de type pylônes,
> mats...
> S'agissant de données ponctuelles, osmose est approprié pour faire la
> conflation
>


fichier SUP_SUPPORT.txt
il peut y avoir plusieurs lignes par support, un même id par support SUP_ID
c'estgeolocalisé.
NAT_ID : Identifiant de la nature du support. Le libellé se trouve dans la
table de référence SUP_NATURE. permet d'obtenir le tag man_made=
SUP_NM_HAUT : hauteur du support.height=
TPO_ID : Identifiant du propriétaire du support. Le libellé se trouve dans
la table de référence SUP_PROPRIETAIRE. owner= ?

fichier SUP_STATION.txt
ADM_ID : Identifiant de l’exploitant de l’installation. Le libellé se
trouve dans la table de référence SUP_EXPLOITANT. operator=
DEM_NM_COMSIS : numéro d'identification de l’installation sur Cartoradio.
ref:FR:Cartoradio= ?

D’après ce qui est écrit au bas de cette page
https://www.data.gouv.fr/fr/datasets/donnees-sur-les-installations-radioelectriques-de-plus-de-5-watts-1/
dans les discutions la seul ref perenne c’est le numéro d'identification de
l’installation sur Cartoradio

Je vois une solution simple pour intégration via osmose :
juste avec le fichier SUP_SUPPORT.txt
pour chaque SUP_ID (donc pour chaque support) proposition d’intégration de
man_made=tower et tower:type=communication avec height= la valeur de
SUP_NM_HAUT (en remplaçant les virgules par des points). et cela quand
NAT_ID correspond à Pylône autostable, Pylône haubané, Pylône tubulaire,
Tour hertzienne, Mât , Mât béton, Mât métallique.

On peut aussi différencier plusieurs cas pour les differents tags :
man_made=communications_tower
man_made=tower et tower:type=communication
man_made=mast et tower:type=communication

Sinon pour faire plus compliqué et intégrer plus d‘info, il faut je pense
sortir les infos des différents fichiers pour pouvoir l'utiliser avec
osmose sachant que sur un support il peut y avoir plusieurs station et donc
plusieurs numéros d'identification de l’installation sur Cartoradio. et
quelques stations peuvent être sur plusieurs supports (je pense proche).
Donc il faudrait un ref:FR:Cartoradio= avec parfois plusieurs valeurs
séparer par des ";" et une valeur peut ce retrouver sur plusieurs support
donc sur plusieurs éléments dans osm
(operator= aussi aurait plusieurs valeurs séparer par des ";" )
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] Plusieurs données libres qui pourraient améliorer osm

2017-07-07 Thread Jérôme Amagat
Le 6 juillet 2017 à 10:33, Christian Quest  a
écrit :

> Le 6 juillet 2017 à 02:40, Jérôme Amagat  a
> écrit :
>
>> plusieurs choses trouvées sur data.gouv.fr :
>>
>> - BD TOPO® Hydrographie de l’IGN
>> (http://www.data.gouv.fr/fr/datasets/bd-topo-r-hydrographie/ ;
>> http://professionnels.ign.fr/bdtopo-hydrographie)
>> Il y a la France métropolitaine les départements d’outre mer et plusieurs
>> territoires d’outre mer.
>>
>>
> Je compte l'ajouter ou l'utiliser en remplacement de la BD Carthage sur le
> rendu hydro... pour mémoire il ressemble à ça:
> http://tile.openstreetmap.fr/?zoom=12&lat=49.43376&lon=0.
> 26065&layers=B00FT
>
>
> - FINESS (Extraction du Fichier des établissements) (
>> http://www.data.gouv.fr/fr/datasets/finess-extraction-du-fic
>> hier-des-etablissements/ )
>>
>> Avec les bonne correspondances entre catégorie finess et tag osm ces
>> données pourraient être intégrable avec osmose.
>>
>>
>
>
Il n'est pas déjà exploité par osmose ?
>

je crois pas.
Il y a des pharmacies qui sont intégrable avec osmose mais ça ne viens pas
de cette base de donnée.
dans finess il y a les pharmacies, les hôpitaux, les maisons de retraites
...

>
>
>
>> - Données sur les installations radioélectriques de plus de 5 watts (
>> https://www.data.gouv.fr/fr/datasets/donnees-sur-les-install
>> ations-radioelectriques-de-plus-de-5-watts-1/ )
>>
>> il y a déjà eu une discussion en rapport avec cette donnée sur cette
>> liste, et il n’y a pas les tags pour tout intégrer à osm mais une chose
>> pourrait être intégrer c’est les supports des « antennes »
>>
>> ces supports sont classé dans différentes catégories :
>> Sémaphore;Phare;Château d'eau - réservoir;Immeuble;Local
>> technique;Mât;Intérieur galerie;Intérieur sous-terrain;Tunnel;Mât béton;Mât
>> métallique;Pylône;Bâtiment;Monument historique;Monument religieux;Pylône
>> autoportant;Pylône autostable;Pylône haubané;Pylône treillis;Pylône
>> tubulaire;Silo;Ouvrage d'art (pont, viaduc);Tour hertzienne;Dalle en
>> béton;Support non décrit;Fût;Tour de contrôle;Contre-poids au
>> sol;Contre-poids sur shelter;Support DEFENSE;pylône arbre;Ouvrage de
>> signalisation (portique routier, panneau routier, panneau
>> publicitaire);Balise ou bouée
>>
>> Je pense surtout aux pylônes, tour hertzienne et mat qui pourrait être
>> ajouté avec les tag man_made=tower ou man_made=communications_tower.
>>
>>
>> - Répertoire SIRENE (http://www.data.gouv.fr/fr/da
>> tasets/base-sirene-des-entreprises-et-de-leurs-etablissement
>> s-siren-siret/)
>>
>> Il y a eu des annonces de son arrivé imminente sur cette liste mais rien
>> depuis sont arrivé pour s’en servir pour osm :)
>>
>> (Je dit ça parce que je ne l’avais pas vu la 1ere fois : Christian nous a
>> parler d’une base géolocalisé, de base sur la page
>> http://www.data.gouv.fr/fr/datasets/base-sirene-des-entrepri
>> ses-et-de-leurs-etablissements-siren-siret/ ça ne l’ai pas, il faut
>> aller en bas de la page dans les ressources communautaires pour trouver ce
>> qu’a fait christian ça mène là : http://212.47.238.202/geo_sirene/last/
>> et ont peut avoir les données sur un département ou une commune.)
>>
>> Je comprend bien que c’est compliqué à intégrer facilement dans osm mais
>> il me semble que pour certains codes APE, la correspondance avec un tag osm
>> est facile et donc, lorsque la géolocalisation est à l’adresse exacte,
>> osmose pourrait permettre l’intégration de l’établissement.
>>
>>
>
> On a parlé de SIRENE lors de l'atelier "tsunami opendata".
>
> Il y a sûrement un outil plus dédié et grand public à penser pour tirer
> parti au mieux de ces infos, voir pour intégration avec des outils comme
> geocropping que je teste depuis peu et me semble une bonne piste. Lorsqu'un
> commerce a changé, interroger SIRENE permettrait de proposer les nouvelles
> infos et de simplement les confirmer si c'est ok.
>
>
>
>> (Je parle beaucoup d’osmose, je ne cherche pas a dire à d’autre, fait ci
>> fait ca c’est pour discuter de quels éléments sont intégrables et si c’est
>> pertinent de le faire avec osmose. Après le codage pour osmose je pourrais
>> essayer quelque chose mais je garantis rien sur le résultat :) )
>>
>>
> J'avais testé une petite utilisation de SIRENE via osmose, juste pour les
> pharmacies.
>
> c’était il me semble que sur un département ?

ça pourrait être généraliser sur la France et utiliser pour d'autres
éléments. exemple :
47.11F  Hypermarchés  shop=supermarket
47.22Z  Commerce de détail de viandes et de produits à base de viande en
magasin spécialisé shop=butcher
55.10Z  Hôtels et hébergement similaire tourism=hotel
et d'autres

La géolocalisation me semble bonne quand elle trouve ville, rue et numéro
exacte dans la rue. lorsque la géolocalisation donne un point sans le
numéro de rue c'est beaucoup plus aléatoire.
Donc pourquoi pas se limiter aux cas avec numéro de rue dans les données
SIRENE avec ce numéro trouvé par ton travail de géolocalisation.
___
Talk-fr m

Re: [OSM-talk-fr] Mapillary : Orientation

2017-07-07 Thread Stéphane Péneau
Les flèches en surimpression sont déduites des analyses faites sur les 
photos;

C'est pour cette raison que ça ne correspond pas.

Dans le cas présent, le tag de direction présent dans les photos n'est 
pas bon.


Stf


En fait, il y a un truc que je ne comprends pas.

Aujourd'hui, j'ai fait une séquence en visant perpendiculairement à 
mon déplacement, à droite*:


https://www.mapillary.com/map/im/FASZg6rAv-znbXGsYOQX_g

Quand je regarde l'image et surtout les flèches au sol indiquant le 
déplacement, c'est bon. Elles sont bien perpendiculaire à la direction 
de visée.


Par contre, sur la carte, les cônes indiquant la direction de prise de 
vue ne sont pas bons. Ils sont dans le sens de déplacement. Idem si je 
vais dans josm.


Ma conclusion est qu'il y a une incohérence chez Mapillary en ligne. 
Vous êtes d'accord???




Eric



* smartphone avec compas et dernière version de Mapillary pour 
Android. Téléversement direct depuis le smartphone.


___
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