Re: [OSM-talk-fr] Importation des hauteurs de bâtiments sur Nice

[Vincent Frison]

@Fédérico: cool, Lyon le propose aussi il me semble, et il devrait y avoir
moyen de récupérer assez facilement une hauteur max..

@Romain: chouette la liste s'allonge pour les MNT !

Quand j'aurai le temps j'essayerai de contacter ces fournisseurs pour voir
lesquels pourraient fournir également un MNS en plus de leur MNT.

Merci, Vincent.


Le 7 octobre 2017 à 21:51, Romain MEHUT  a écrit :

> Bonjour,
>
> Je rajoute Nancy cf. http://opendata.grandnancy.eu/
> jeux-de-donnees/detail-dune-fiche-de-donnees/?tx_
> icsoddatastore_pi1%5Bpage%5D=1_icsoddatastore_pi1%
> 5Bcategories%5D%5B0%5D=45_icsoddatastore_pi1%
> 5Bcategories%5D%5B1%5D=42_icsoddatastore_pi1%5Buid%5D=
> 115_icsoddatastore_pi1%5BreturnID%5D=447
>
> Romain
>
> Le 6 octobre 2017 à 23:42, Vincent Frison  a
> écrit :
>
>> Le 6 octobre 2017 à 18:37, marc marc  a écrit
>> :
>>
>>> Le 04. 10. 17 à 21:19, Vincent Frison a écrit :
>>> > malheureusement il n'y a pas beaucoup
>>> > de villes en France où je peux trouver en open data le MNT et le MNS
>>> > (avec une bonne résolution en plus).
>>>
>>> est-ce parce qu'ils n'ont pas de moyen de rendre la donnée facilement
>>> accessible ou simplement parce qu'elle n'est pas opendata ?
>>>
>>
>> De ce que j'ai pu voir voici les villes qui proposent actuellement du MNT
>> (ou des courbes de niveaux) en open data:
>> - Nice
>> - Montpellier
>> - Lyon
>> - Lille
>> - Bordeaux
>> - Poitiers
>> - Clermont
>> - Genève
>>
>> Mais apparemment aucune ville ne propose directement des MNS mis à part
>> Genève et Montpellier (Christian vient d'ailleurs de m'aider sur le forum
>> pour convertir le MNT de cette dernière: http://forum.openstreetmap.fr/
>> viewtopic.php?f=5=6585).
>>
>> Ceci dit pour Nice je leur ai envoyé un mail pour obtenir le MNS (qui
>> leur a permis de construire leur MNT j'imagine), peut-être ça pourrait
>> aussi marcher avec les autres villes qui proposent déjà un MNT. En tout cas
>> ça ne coûte pas grand chose de demander...
>>
>>
>> ___
>> 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
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] GeoCodage et uMap

[Cédric Frayssinet]

Bonjour,

Je mets ici la solution trouvée à ma problématique. J'ai réussi à faire
ma carte uMap de tous les établissements scolaires de mon académie en
utilisant la méthode que j'ai décrite sur ce journal :
http://www.openstreetmap.org/user/C%C3%A9dric%20F/diary/42458

Bonne fin de week-end,

Cédric

Le 29/09/2017 à 23:58, Cédric Frayssinet a écrit :
>
> Le 29/09/2017 à 23:24, Christian Quest a écrit :
>> Si tu as juste le nom de l'établissement et la commune, c'est
>> chaud... pas de code UAI d'établissement (il est dans l'adresse email
>> générique des établissements) ?
>
> Si, je peux l'avoir effectivement, j'ai vu qu'il était dans les tags
> des établissements scolaires. Disons que là, çà me fait retravailler
> le fichier.
>
> Avec le moteur http://photon.komoot.de/ çà semblait bien fonctionner
> avec simplement le nom et la commune, c'est pourquoi j'étais parti sur
> cette idée...
>
> Et avec l'UAI, quelle serait la technique ?
>
> Merci pour ton aide,
>
> Cédric
>
>
>>
>>
>>
>> -- 
>> Christian Quest - OpenStreetMap France
>>
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>
>
> -- 
> En cure de désintoxication  de
> Google ! Client d'Enercoop
> , l'énergie militante
>
> Également sur Mastodon : @bristow...@framapiaf.org
> 
>
> Promouvoir et soutenir le logiciel libre 
>
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr


-- 
En cure de désintoxication  de
Google ! Client d'Enercoop
, l'énergie militante

Également sur Mastodon : @bristow...@framapiaf.org


Promouvoir et soutenir le logiciel libre 

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

Re: [OSM-talk-fr] les dates de terrain survey:date, de test fonctionnel, d'import, de source source:date

[marc marc]

Bonjour,

N'ayant reçu aucun objection, j'ai harmonisé  l'échelle de la France
source_date et date:source en faveur du tag majoritaire source:date
date:survey en faveur du tag majoritaire survey:date

Pour bien faire, il reste à faire :
- faire la même chose ailleurs (je lancerai la discussion sous peu de 
l'autre côté de la frontière, voir au niveau mondial si motivé)
- relancer la proposition sur les tests fonctionnel operational_status
- essayer de raffiner ceux dont le sens exact est inconnu (lastcheck, 
check_date)

Le 29. 09. 17 à 17:32, Marc M. a écrit :
> Bonjour,
> 
> Vu que l'inventaire semble complet,je propose de fusionner :
> source_date et date:source en faveur du tag majoritaire source:date
> date:survey en faveur du tag majoritaire survey:date
> 
> ok ? objection ?
> 
> Cordialement,
> Marc
> 
> Le 12. 09. 17 à 14:01, Marc M. a écrit :
>> @tous : il ne manque aucun besoin avec ces 3 type survey <> 
>> fonctionnel <> source externe ?
>>
>> @Christian l'outil est prometteur.
>> C'est un bon exemple d'interface simple même si quelques détails 
>> serraient utile (valider une porte d'entrée, pas sur de l'utilité).
>> Je vais e tester un peu plus pour proposer des améliorations.
>>
>> @Violaine
>> que veux-tu dire par mixer ? ce serrait au contraire plus clair si on 
>> fait 3 catégories bien distincte comparé par exemple au tag check_date 
>> où il est impossible de savoir qu'est-ce qui a été précisément vérifié 
>> (la position, l’existence, le fonctionnel)
>> Exemple fictif : les bornes incendies d'une commune
>> Lors de l'import on précise sur le changeset source=lacommune 
>> source:date=2015/01/01
>> Si quelqu'un voit la borne sur le terrain et veux préciser la date,
>> il peux rajouter survey:date=2017/09/12 (sinon on suppose que c'est
>> une date proche de la modif, pas besoin de raffiner cela à l’extrême)
>> Si un technicien teste la borne comme fonctionnelle, on peux encoder 
>> cette information avec operational_status=operating 
>> operational_status:date=2017/09/12
>>
>> Pour l'étendue de la vérification, c'est justement le reproche que je 
>> fais à check_date. on ne sait pas si cela signifie que l'objet a été
>> vu sur le terrain, ou si l'objet a été comparé avec une liste opendata
>> ou s'il s'agit d'un test fonctionnel.
>> Je pense aussi que cela n'a de sens que sur des objets assez précis
>> que pour déduire que la vérification est complète.
>> On peux dire qu'on a vu un arrêt de bus ou testé une borne.
>> Prétendre la même chose sur un hôpital me semble délicat.
>> Etait-ce son existence ? son nom ? tout ces tags ?
>> Rien n’empêche de préciser capacity:bed:date par exemple
>> Peut-être faudrait-il préciser qu'un survey:date par exemple concerne 
>> tous les tags d'un objet. mais quid des infos provenant d'un import 
>> mais qui sont invérifiable sur le terrain (par exemple le diamètre du 
>> tuyau d'alimentation d'une borne lorsque l'info n'est pas sur la 
>> plaque) ?
>> Je n'ai pas de solution pour améliorer le sens.
>> Dupliquer tout les tags avec une date me semble impossible en pratique
>> vu la difficulté qu'il y a avec des schémas beaucoup plus simple.
>>
>> Le 11. 09. 17 à 21:21, Christian Quest a écrit :
>>> La webapp geocropping rend ce process de mise à jour d'une date de 
>>> contrôle sur terrain très simple et pas technique du tout.
>>>
>>> A voir ici: https://geocropping.xsalto.com/
>>>
>>> Le 11 septembre 2017 à 18:33, Violaine Doutreleau a écrit :
>>>
>>>     Bonjour Marc,
>>>
>>>     Pour moi la difficulté c'est qu'il ne faudrait pas mixer la source
>>>     d'une information (je suis ok pour  ajouter une info de date en
>>>     fonction de la source de données), par le check_date ou
>>>     operational_status:date, qui relève plutôt de la validation de
>>>     données. J'entends : la donnée est déjà créée, je repasse x jours
>>>     après sa création pour dire qu'elle est toujours valide. Healthsites
>>>     prévoit de faire ça sur la thématique santé... Par contre j'aime
>>>     beaucoup l'idée car on pourrait imaginer de la demande de validation
>>>     de données si le check_date est trop éloigné de la date du jour aux
>>>     utilisateurs de gps... Et ça pourrait donner un sacré coup de 
>>> pouce ...
>>>
>>>     Par contre j'ai le sentiment que ce n'est pas vraiment la place de
>>>     la validation, mais d'une base extérieure? Dailleurs ça risque
>>>     d'être trop tech pour des utilisateurs lambdas d'OSM, et pourtant
>>>     des informations faciles à donner par n'importe qui.
>>>
>>>     Sinon, une autre difficulté que je trouve c'est qu'il faudrait quasi
>>>     autant de check_date, que de tags, ou alors définir les éléments que
>>>     l'on souhaite vérifier. Non? Par exemple pour les centre de santés,
>>>     c'est pas évident de tout contrôler d'un coup si on est un
>>>     utilisateur lambda  (pas aussi simple de donner le nombre de staffs
>>>     par exemple)
>>>
>>>     Juste mes réflexions...
>>>
>>>     A bientôt,
>>>
>>>     V
>>>
>>>
>>>