Re: [OSM-talk-fr] Vue satellite sur Osm ?

[Vincent Frison]

Le 23 mai 2018 à 18:23, Christian Quest  a écrit :

> Tu ne confonds pas avec la BD Ortho à 5m ? http://professionnels.ign.fr/b
> dortho-5m
>
> Jamais entendu parlé d'une ouverture de la BDOrtho à 50cm.
>
> Pour l'orthohr, elle est de plus en plus financée par les collectivité
> locales et par l'Europe et une des conditions est qu'au final elle soit en
> opendata (LO).
> On a ainsi une cinquantaine de départements dispo, et ça alimente la BD
> Ortho... qui globalement n'est pas ouverte, mais que nous pouvons utiliser
> pour compléter OSM depuis que nous avons signé une convention avec l'IGN
> lors du SOTM-FR à Clermont en 2016.
>

Donc la subtilité serait que la partie de la BD ORTHO qui a été libérée est
uniquement celle qui provient de la BD ORTHO HR et qui doit forcément être
mise en open data car financée par les collectivité locales et par
l'Europe. Par contre ils seraient encore réticent à libérer la partie qui a
été produite par leurs soins...

Bon ceci dit ça fait quand même un paquet de départements déjà dispo à 50
cm !

Vivement que l'on ait en open data toute la BD ORTHO HR en résolution
maximale, quand on regarde Paris sur le Geoportail (j'imagine que c'est les
données à 5 cm de 2017 dont tu parles) c'est vraiment impressionnant...
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Vue satellite sur Osm ?

[Vincent Frison]

Je n'ai pas testé mais sur cette page on parle bien d'orthophotos libérés
avec une résolution de 50 cm:
http://professionnels.ign.fr/bdortho-50cm-par-departements#tab-3




Le 23 mai 2018 à 18:23, Christian Quest <cqu...@openstreetmap.fr> a écrit :

> Tu ne confonds pas avec la BD Ortho à 5m ? http://professionnels.ign.fr/
> bdortho-5m
>
> Jamais entendu parlé d'une ouverture de la BDOrtho à 50cm.
>
> Pour l'orthohr, elle est de plus en plus financée par les collectivité
> locales et par l'Europe et une des conditions est qu'au final elle soit en
> opendata (LO).
> On a ainsi une cinquantaine de départements dispo, et ça alimente la BD
> Ortho... qui globalement n'est pas ouverte, mais que nous pouvons utiliser
> pour compléter OSM depuis que nous avons signé une convention avec l'IGN
> lors du SOTM-FR à Clermont en 2016.
>
> La BD Ortho a une résolution (et fraicheur) variable en fonction des
> départements. Sur Paris on est à 5cm et ça sembler dater de 2017  :)
>
>
>
> Le 23 mai 2018 à 17:56, Vincent Frison <vincent.fri...@gmail.com> a écrit
> :
>
>> Le 21 mai 2018 à 22:36, Vincent Privat <vincent.pri...@gmail.com> a
>> écrit :
>>
>>> petit hors sujet, mais si la licence GéoBretagne est compatible OSM, une
>>> âme charitable pour corriger https://josm.openstreetmap.de/ticket/16061
>>> en modifiant https://josm.openstreetmap.de/wiki/Maps/France ?
>>>
>>> Le 21 mai 2018 à 22:24, Maël REBOUX <o...@breizhpositive.bzh> a écrit :
>>>
>>>> Bonjour,
>>>>
>>>> Je me posais la question récemment pour la carte en breton.
>>>> Car vu que l’ortho régionale (B4 en tout cas…) est 100% libre, je ne
>>>> vois pas ce qui interdirait de disposer d’un service de tuiles avec un
>>>> style mixte (fond photo aérienne + routes dessus) ou d’une application
>>>> carto qui mixerait le service de tuiles ortho de GéoBretagne et un service
>>>> OSM.
>>>>
>>>> Ce qui me semble être le frein pour qqch sur France entière ce sont les
>>>> différentes sources / licences.
>>>> On est d’accord ?
>>>>
>>>
>> J'ai pas tout suivi mais l'IGN est en train de libérer les données de la
>> BD ORTHO dont la résolution est seulement de 50 cm. Espérons que la BD
>> ORTHO HR, qui elle a une résolution de 20 cm, le soit bientôt également !
>>
>> Après le fait que les données de la BD ORTHO soient libres est une bonne
>> chose, une très bonne chose même, mais ça veut pas dire que l'IGN va offrir
>> un accès illimité à ses serveurs de tuiles ! J'imagine donc que l'idée
>> serait plutôt de récupérer les données une fois qu'elles seront bien dans
>> la bonne licence et de les servir via son propre serveur de tuile, ce que
>> pourrait peut-être faire OSM FR à terme. Par contre je doute que ça soit
>> un jour possible sur le serveur osm.org qui est plutôt une vitrine des
>> données d'OSM (et uniquement elles) comme cela a été dit.
>>
>> En attendant il y a l'excellent https://en.mapy.cz où on a différentes
>> couches OSM plutôt réussies avec la possibilité d'avoir des orthophotos
>> (Bing, donc plutôt meilleur que le BD ORTHO non HR) et plein d'autre choses
>> (photos, 3D, etc. c'est assez impressionnant). Pour moi c'est actuellement
>> le meilleur site/carte basé sur OSM et ce vers quoi il faut aller...
>>
>> ++ Vincent
>>
>>
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>>
>
>
> --
> Christian Quest - OpenStreetMap France
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Vue satellite sur Osm ?

[Vincent Frison]

Le 21 mai 2018 à 22:36, Vincent Privat  a écrit :

> petit hors sujet, mais si la licence GéoBretagne est compatible OSM, une
> âme charitable pour corriger https://josm.openstreetmap.de/ticket/16061
> en modifiant https://josm.openstreetmap.de/wiki/Maps/France ?
>
> Le 21 mai 2018 à 22:24, Maël REBOUX  a écrit :
>
>> Bonjour,
>>
>> Je me posais la question récemment pour la carte en breton.
>> Car vu que l’ortho régionale (B4 en tout cas…) est 100% libre, je ne vois
>> pas ce qui interdirait de disposer d’un service de tuiles avec un style
>> mixte (fond photo aérienne + routes dessus) ou d’une application carto qui
>> mixerait le service de tuiles ortho de GéoBretagne et un service OSM.
>>
>> Ce qui me semble être le frein pour qqch sur France entière ce sont les
>> différentes sources / licences.
>> On est d’accord ?
>>
>
J'ai pas tout suivi mais l'IGN est en train de libérer les données de la BD
ORTHO dont la résolution est seulement de 50 cm. Espérons que la BD ORTHO
HR, qui elle a une résolution de 20 cm, le soit bientôt également !

Après le fait que les données de la BD ORTHO soient libres est une bonne
chose, une très bonne chose même, mais ça veut pas dire que l'IGN va offrir
un accès illimité à ses serveurs de tuiles ! J'imagine donc que l'idée
serait plutôt de récupérer les données une fois qu'elles seront bien dans
la bonne licence et de les servir via son propre serveur de tuile, ce que
pourrait peut-être faire OSM FR à terme. Par contre je doute que ça soit un
jour possible sur le serveur osm.org qui est plutôt une vitrine des données
d'OSM (et uniquement elles) comme cela a été dit.

En attendant il y a l'excellent https://en.mapy.cz où on a différentes
couches OSM plutôt réussies avec la possibilité d'avoir des orthophotos
(Bing, donc plutôt meilleur que le BD ORTHO non HR) et plein d'autre choses
(photos, 3D, etc. c'est assez impressionnant). Pour moi c'est actuellement
le meilleur site/carte basé sur OSM et ce vers quoi il faut aller...

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

Re: [OSM-talk-fr] office et craft dans le rendu FR...

[Vincent Frison]

Super que les crafts et offices soient enfin affichés ! Cela faisait
longtemps que je suivais le ticket sur GitHub mais j'avais l'impression
qu'ils ne se sortiraient jamais de leur débats sur les icônes et couleurs.

Super aussi que ça soit également le cas sur rendu FR, il ne manque plus
que le relief ;)

Le 25 avril 2018 à 14:40, Christian Quest  a écrit
:

> Les POI office=* ont été ajouté il y a peu dans le rendu OSM.
>
> J'ai fait de même sur le rendu FR, et étendu aux craft=*
>
> Autre petit plus... shop/office/craft=vacant ont une marque différenciée
> (légèrement transparente au centre, bord opaque).
>
> C'est déployé, les zoom 19/20 on été effacés du cache primaire, vous les
> verrez donc plus rapidement. Le reste (zoom 17-18) deviendra visible au fur
> et à mesure des mises à jour des metatuiles...
>
> Exemple: http://tile.openstreetmap.fr/~cquest/leaflet/l.html#19/48.
> 80387/2.48566
>
> --
> 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] Désabonnement de la liste

[Vincent Frison]

Hello,

Merci à tous pour vos réponses détaillées. Le sujet est loin d'être simple,
comme souvent avec les problèmes de mails.

Pour commencer j'ai déjà rajouté l'adresse de la liste dans mes contacts,
on verra si ça améliore les choses, mais sinon je réfléchis sérieusement à
changer de messagerie (pourquoi pas vers la future de Qwant).

++ Vincent


Le 24 avril 2018 à 12:19, marc marc  a écrit :

> il faut 3 conditions simultanées pour que le problème se produise :
> - des emails "entrant" (= des personnes qui écrivent avec un FROM)
> venant d'un domaine ayant un DKIM/DMARC qui impose le rejet des emails
> modifés (par exemple yahoo).
> Sur talk-be je ne me souviens pas avoir vu un email "from yahoo"
> récement, le problème ne peux donc pas se produire sur talk-be.
> ET
> - une config de ml qui casse ce DKIM (j'ignore si talk-be une config
> différence de talk-fr, le plus facile serrait d'écrire un email depuis
> yahoo vers talk-be).
> ET
> - un destinataire chez un fournisseur sans nuance (ex gmail).
>
> pour les conditions 1 et 3, il n'est pas impossible que leur nombre
> influence aussi pour atteindre le seuil jugé "trop" par gmail.
>
> et en plus il y a d'autres différences entre talk-be et talk-fr.
> le dernier email de yahoo vers talk-fr a été envoyé depuis nabble
> ce qui casse aussi le spf
> cela augmente encore le risque de froisser G tout en étant obscur.
>
> bref j'arrête ici de débuger un ansispam propriétaire...
> ce n'est pas une solution...
> les seules choses améliorable sont :
> - la config de la liste si quelqu'un est admin de la liste et/ou veux
> faire un ticket infra osm.org sur github
> - la part de responsabilité des utilisateurs concernés quand au choix
> d'un fournisseur fermé ou ouvert, y compris dans les scores antispam.
>
> Le 24. 04. 18 à 10:28, osm.sanspourr...@spamgourmet.com a écrit :
> > Peut-être que les paramètres des autres listes ont été ajustés comme
> suggéré par ailleurs et pas cette liste-ci.
> >
> > Jean-Yvon
> >
> >
> >> Gesendet: Dienstag, 24. April 2018 um 07:26 Uhr
> >> Von: "Marc Gemis - marc.ge...@gmail.com"
> >> Mais la seule liste d'OpenStreetMap qui donne des problème c'est
> >> talk-fr. Pas de problèmes avec talk, talk-be, talk-gb, tagging,
> >> talk-au ...
> >>
> >> m.
> >
> >
> > ___
> > 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

[OSM-talk-fr] Désabonnement de la liste

[Vincent Frison]

Hello,

Je me fais régulièrement "bannir" de la liste avec le message suivant:






*Votre abonnement à la liste Talk-fr a été désactivé suite à dueto
excessive bounces The last bounce received from you was dated18-Apr-2018.
Vous ne recevrez plus de messages en provenance de cetteliste tant que vous
n'aurez pas ré-activé votre abonnement. Vousrecevrez encore 3 rappels comme
celui-ci avant que votre abonnement nesoit supprimé..*

Quelqu'un saurait à quoi cela correspond et surtout comment faire pour que
ça s'arrête ?

A priori je ne fais rien de spécial et j'utilise une adresse Gmail on peut
plus classique..

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

Re: [OSM-talk-fr] Un nouveau 'concurrent' ?

[Vincent Frison]

Le 16 avril 2018 à 11:39, Cédric Frayssinet  a écrit
:

>
> Merci Noémie pour ces précisions !
>
> Qwant étant un moteur de recherche, est-il prévu également d'améliorer le
> moteur actuel d'OpenStreetMap qui est pour moi le point faible autant sur
> OpenStreetMap.org que sur OsmAnd. En effet, une seule petite lettre en
> défaut et on n'obtient aucun résultat :( C'est une des grosses forces de
> GMaps pour le coup...
>
> Sur Mastodon, on m'a dit que ce serait chouette de se rapprocher de cette
> interface : https://en.mapy.cz/ et moi je rajoute celle-ci :
> https://maps.mapcat.com/
>

Je trouve Mapy.cz impressionnant, pour moi c'est peut-être la meilleure
webmap basée sur OSM ! Elle a quasiment tout, il manque juste la
possibilité de voir l'ensemble des données comme sur osm.org (par ex.
certains commerces ou restaurant ne sont pas visibles, même avec la carte
"touriste"). Bref merci pour le lien...

Pour revenir au sujet j'ai vraiment hâte de voir ce que Qwant va nous
proposer, c'est pas tous les jours qu'une "grosse" boite fait une solution
cartographique pour le grand public basée sur OSM...

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

Re: [OSM-talk-fr] Rendu avec relief sur osm.org

[Vincent Frison]

Le 6 janvier 2018 à 21:38, Vincent Frison <vincent.fri...@gmail.com> a
écrit :

> Le 6 janvier 2018 à 19:36, Christian Quest <cqu...@openstreetmap.fr> a
> écrit :
>
>> J'ai sorti du congélateur ce que j'avais fait l'hiver dernier sur
>> l'ombrage...
>>
>> STRMv3 est complet, j'avais calculé l'ombrage transparent, par contre
>> certaines dalles de 10° x 10° étaient trop volumineuses et avaient dépassé
>> les 2Go d'où un ombrage incomplet.
>>
>> Je regarde pour corriger ça, sinon 95% du boulot est fait.
>>
>> Pour info, l'image totale fait 1299600 x 414000 pixels, soit 538
>> milliards de pixels ;)
>> Le dossier avec les tuiles finales et leurs overview pèse 133Go... tout
>> le dossier du projet fait presque 600Go.
>>
>
> C'est impressionnant !
>
> Mais ce qui l'est encore plus c'est que tu nous sortes ça de ton
> congélateur :)
>

Salut Christian,

Y aurait-il eu des avancées sur ce chantier ?

Il parait que c'est dangereux de remettre les choses plusieurs fois au
congélateur...

Sinon on est d'accord que lorsque tu parlais de SRTMv3 c'était le SRTM 1"
(résolution de ~30 mètres) et non pas le SRTM 3" (résolution de 90 mètres) ?

Bon c'est sûrement le cas puisque tu parlais d'une image globale ayant
1299600 pixels en largeur, ce qui fait bien du 30 mètres par pixel...

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

Re: [OSM-talk-fr] Import des hauteurs de bâtiment depuis la BD TOPO

[Vincent Frison]

C'est effectivement décevant de la part de l'IGN. Après je me dis que les
mentalités vont forcément changer de leur côté, et puis n'oublions pas
qu'il y a la volonté qui a l'air assez claire de la part de l'Etat pour
ouvrir toutes ces données.

Ma demande portera uniquement sur les hauteurs de bâtiments, voir carrément
sur toute la partie BATI de la BD TOPO ce qui leur évitera d'extraire une
partie des données.

Mais oui j'ai peu d'espoir que ma demande aboutisse, mais bon qui ne tente
rien n'a rien, et surtout on ne risque pas grand chose


Le 7 avril 2018 à 14:22, Christian Quest <cqu...@openstreetmap.fr> a écrit :

> Quand je vois ce qu'il est advenu des démandes passées, je n'ai pas
> tellement d'espoir.
>
> Exemple récent:
>
> Florian avait demandé un export de la liste des bornes géodésiques pour
> les mettre à jour dans OSM.
> Ces données, n'ont jamais été vendues, et ne font pas parties de celles
> pour lesquelles une redevance peut être perçue. Aucun problème donc en
> principe pour y avoir accès et les réutiliser.
>
> La réponse de l'IGN a été: "c'est disponible sous forme de PDF,
> servez-vous c'est sous Licence Ouverte"... ce qui bien sûr ne correspondait
> pas à notre demande et nécessitait de télécharger des dizaines de milliers
> de PDF pour ensuite en extraire les infos utiles.
>
> C'est ce qu'on avait fait il y a quelques années et qui avait provoqué un
> blocage, d'où une demande d'un accès plus direct à un export de la base qui
> sert à produire ces PDF.
>
> Réponse négative... donc j'ai rescrappé les PDF (et republié le jeu de
> données extrait sur data.gouv.fr)... depuis mon IP perso est blacklistée
> par l'IGN sur une bonne partie de ses serveurs.
>
>
> J'imagine mal l'IGN exporter juste la hauteur des bâtiments, et encore
> moins donner un accès complet à la BD Topo... tu peux toujours demander,
> je ne voudrais pas te décourager !
>
> Le 6 avril 2018 à 22:19, Vincent Frison <vincent.fri...@gmail.com> a
> écrit :
>
>> Le 6 avril 2018 à 13:45, Christian Quest <cqu...@openstreetmap.fr> a
>> écrit :
>>
>>>
>>> Je sais que ton TOC est la hauteur des bâtiments, mais je pense que se
>>> limiter à cette seule info pour faire un import est très en dessous des
>>> enjeux possibles.
>>>
>>
>> Certes, mais cela pourrait quand même être un bon début et ça ne
>> bloquerait en rien des futures échanges, j'aurais même tendance à penser
>> l'inverse...
>>
>> Bref je te cache pas que si rien ne bouge le 4 mai j'aimerais bien
>> tenter le coup, sauf si tu avais une objection bien sûr, mais à vrai
>> dire je ne vois pas trop ce que pourrait être gênant dans le fait de demander
>> d'autorisation (en tant que simple contributeur et non d'OSM France). Au
>> pire j'aurais un refus, ou aucun retour...
>>
>> Ou sinon je peux aussi aller consulter un spécialiste pour essayer de
>> soigner mon TOC !
>>
>> Sinon ok le coup de la mission de service public (et même de l'utilité
>> publique) c'est pas si rose que ça, dommage...
>>
>>
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>>
>
>
> --
> Christian Quest - OpenStreetMap France
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Import des hauteurs de bâtiment depuis la BD TOPO

[Vincent Frison]

Le 6 avril 2018 à 13:45, Christian Quest  a écrit :

>
> Je sais que ton TOC est la hauteur des bâtiments, mais je pense que se
> limiter à cette seule info pour faire un import est très en dessous des
> enjeux possibles.
>

Certes, mais cela pourrait quand même être un bon début et ça ne bloquerait
en rien des futures échanges, j'aurais même tendance à penser l'inverse...

Bref je te cache pas que si rien ne bouge le 4 mai j'aimerais bien tenter
le coup, sauf si tu avais une objection bien sûr, mais à vrai dire je ne
vois pas trop ce que pourrait être gênant dans le fait de demander
d'autorisation (en tant que simple contributeur et non d'OSM France). Au
pire j'aurais un refus, ou aucun retour...

Ou sinon je peux aussi aller consulter un spécialiste pour essayer de
soigner mon TOC !

Sinon ok le coup de la mission de service public (et même de l'utilité
publique) c'est pas si rose que ça, dommage...
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Import des hauteurs de bâtiment depuis la BD TOPO

[Vincent Frison]

Salut Christian,

Merci pour ces précisions, mes réponses plus bas.

Le 5 avril 2018 à 00:43, Christian Quest  a écrit :

> C'est un peu plus compliqué que ça...
>
> Cette licence ne s'applique que pour des usages de mission de service
> public, de recherche, d'enseignement, ou de démonstration et évaluation
> (sur des échantillons).
>
> Pour un ré-utilisateur lambda, ces données restent payantes...
>

Mais on n'est pas des ré-utilisateurs lambda ! :)

Ne pourrait-on pas faire passer le projet OSM pour une mission de service
public (ce qui ne semble pas être délirant) ? :)


> car l'IGN, Météo France et le SHOM sont les 3 opérateurs restants qui
> peuvent encore percevoir des redevances de réutilisations, donc vendre des
> données... parce que "la couverture des coûts liés à cette activité
> principale est assurée à moins de 75 % par des recettes fiscales, des
> dotations ou des subventions."
>
> Un de ces jours il faudra vérifier ces 75% (calculés sur 3 ans) et aussi
> si les tarifs de ces redevances ne sont pas exagérés, car la Loi les
> limite: "Le produit total du montant de cette redevance, évalué sur une
> période comptable appropriée, ne dépasse pas le montant total des coûts
> liés à la collecte, à la production, à la mise à la disposition du public
> ou à la diffusion de leurs informations publiques."
>

Je suis pas sûr de bien comprendre: dans le modèle actuelle jusqu'à 75% des
recettes de l'IGN seraient des subventions / dotations de l'état et les 25%
restant résulteraient de la vente de leur produits / services ? Ou alors
c'est l'inverse ?


> Bref... ça m'étonnerai que le 5 mai on entre dans une nouvelle ère sur ces
> seuls bases légales.
> Pour qu'il y ait un vrai changement, il faut un choix politique assumé (y
> compris en interne).
>

Si ça ne bouge pas au 5 mai je serais quand même pour tenter quelque chose,
c'est à dire  demander une autorisation spéciale pour OSM, on ne risque pas
grand chose, et si en plus ça ne concerne qu'une petite partie de la BD
TOPO (en l'occurrence les hauteurs de bâtiments) ça sera sans doute plus
facilement acceptable, qu'en penses tu ?

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

Re: [OSM-talk-fr] Import des hauteurs de bâtiment depuis la BD TOPO

[Vincent Frison]

En fait d'après cette page <https://www.data.gouv.fr/fr/licences> l'IGN a
visiblement obtenu l'an passé une dérogation pour continuer à utiliser leur
licence actuelle pour la BD TOPO (entre autres) jusqu'au 4 mai 2018. Mais
peut-être qu'à partir de ce moment là ils seront obligés d'utiliser une
licence ouverte !

*La « licence d’utilisation à titre gratuit
<http://professionnels.ign.fr/doc/licence_gratuite.pdf> » de l’institut
national géographique et forestier (IGN) est homologuée par la décision
d'homologation
<https://www.data.gouv.fr/static/gouvfr/licences/homologation-licences-2017-05-05.pdf>
du
5 mai 2017 pour le périmètre des données géographiques BD ORTHO®, BD TOPO®,
BD PARCELLAIRE®, BD ADRESSE® et RGE ALTI®  jusqu'au 4 mai 2018.*

Et au pire, même s'ils arrivent encore à repousser encore la date,
peut-être qu'on pourrait effectivement leur demander une autorisation
spéciale pour OSM (au moins pour les hauteurs de bâtiments).

++ Vincent.


Le 4 avril 2018 à 11:14, Vincent Frison <vincent.fri...@gmail.com> a écrit :

> Hello,
>
> Il semblerait que les choses doivent bientôt changer du côté de l'IGN et
> qu'ils vont devoir à (court?) terme devoir libérer leur données. Cela
> pourrait être fantastique pour OSM notamment pour leur BD TOPO. Quelqu'un
> aurait des infos plus précises à ce sujet ?
>
> Dans le passé j'avais fait des scripts
> <https://github.com/vince-from-nice/osmaxil> pour importer les hauteurs
> de bâtiments à partir de diverses sources de données (notamment des
> combinaisons de MNT et MNS). C'était bien mais c'était assez laborieux et
> surtout ça ne concernait que quelques grandes villes (je l'avais fait que
> pour Paris, Nice et Montpellier).
>
> Mais là avec  cette BD TOPO on aurait tout le travail déjà fait (et bien
> fait j'espère).. et sur l'ensemble du pays !!!
>
> Clairement si l'IGN passe ce jeu de données en Licence Ouverte ou ODbL
> (comme cela est préconisé par l'Etat) j'aimerais bien réutiliser mes
> scripts pour faire l'import dans OSM. Je parle uniquement des hauteurs de
> bâtiment, mais il y aura certainement un paquet d'autres choses à
> récupérer...
>
> ++ Vincent.
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Import des hauteurs de bâtiment depuis la BD TOPO

[Vincent Frison]

Hello,

Il semblerait que les choses doivent bientôt changer du côté de l'IGN et
qu'ils vont devoir à (court?) terme devoir libérer leur données. Cela
pourrait être fantastique pour OSM notamment pour leur BD TOPO. Quelqu'un
aurait des infos plus précises à ce sujet ?

Dans le passé j'avais fait des scripts
 pour importer les hauteurs de
bâtiments à partir de diverses sources de données (notamment des
combinaisons de MNT et MNS). C'était bien mais c'était assez laborieux et
surtout ça ne concernait que quelques grandes villes (je l'avais fait que
pour Paris, Nice et Montpellier).

Mais là avec  cette BD TOPO on aurait tout le travail déjà fait (et bien
fait j'espère).. et sur l'ensemble du pays !!!

Clairement si l'IGN passe ce jeu de données en Licence Ouverte ou ODbL
(comme cela est préconisé par l'Etat) j'aimerais bien réutiliser mes
scripts pour faire l'import dans OSM. Je parle uniquement des hauteurs de
bâtiment, mais il y aura certainement un paquet d'autres choses à
récupérer...

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

Re: [OSM-talk-fr] Rendu avec relief sur osm.fr

[Vincent Frison]

Le 19 janvier 2018 à 21:54, Christian Quest  a
écrit :

> Mon week-end dernier a été occupé par un autre sujet... because nouveau
> jouet : https://www.thingiverse.com/thing:2760677
>

Mais en voila du joli relief, magnifique ombrage et courbes de niveau, ça
fait envie ! :)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Rendu avec relief sur osm.fr

[Vincent Frison]

Bonjour Christian,

Aurais tu par hasard des nouvelles sur l'avancement du rendu FR avec du
relief ? Encore des soucis avec des tuiles d'ombrage dont la taille est
supérieure à 2 Gb ?

Merci, Vincent.

Le 8 janvier 2018 à 10:43, Vincent Frison <vincent.fri...@gmail.com> a
écrit :

> Le 8 janvier 2018 à 02:50, Christian Quest <cqu...@openstreetmap.fr> a
> écrit :
>
>> Voici un aperçu: https://framapic.org/gallery#2z7RctD1z97y/HuaZj7vuLg
>> X3.png,iWtM0YZeqpgE/s1HWupUrNzCp.png
>>
>> J'ai juste mis les limites des communes pour se repérer. Premier exemple
>> à un zoom moyen (environ 8), second à la résolution native, sur Paris...
>>
>
> Effectivement sur le second on voit bien que c'est la résolution native
> (environ 30 mètres) !
>
>
>> On y distingue une surface granuleuse à cause des bâtiments. Vous avez
>> l'ombre de la Tour Eiffel, les tours de la Défense... toute la différence
>> entre un MNT et MNS.
>>
>
> En fait j'imagine qu'à la base il n'y a uniquement des MNS qui sont
> ensuite convertis après traitement en MNT (mais c'est jamais parfait, même
> pour SRTM) ?
>
> D'ailleurs je me demande bien comment ils font concrètement pour
> transformer un MNS en MNT, ça ressemble un peu de la magie. Est ce qu'ils
> se basent sur des orthophotos (genre pixel vert = végétation) ou sur des
> données de land cover (pour savoir si on est  en ville par ex) afin de
> savoir où et comment il faut retirer de la hauteur/élévation ?
>
> Bon j'avoue que c'est un peu hors sujet mais c'est tellement passionant ;)
>
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Liste des outils d'OSM FR

[Vincent Frison]

Merci pour l'info, je peux pas voir les 2 messages archivés (c'est réservé
aux membres inscrits sur la liste CA) mais je suis bien content de savoir
qu'une nouvelle version du site est dans les tuyaux.

J'ai rajouté mes 2 suggestions au sujet du menu sur le doc partagé (
https://annuel.framapad.org/p/openstreetmap.fr).
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Liste des outils d'OSM FR

[Vincent Frison]

Le 7 janvier 2018 à 22:14, sly (sylvain letuffe) <lis...@letuffe.org> a
écrit :

> Vincent Frison wrote
> >> Tu ne connais pas http://openstreetmap.fr/outils
> >
> > Ba voila c'est exactement la page que j'imaginais !
>
> Le problème c'est que sa dernière mise à jour date de 2013 et que plusieurs
> outils ne sont plus opérationnels depuis.
> Au final, la plus à jour, et que toute personne avec un compte sur le wiki
> d'osm.org peut aider à compléter/corriger c'est là :
> https://wiki.openstreetmap.org/wiki/FR:Serveurs_OpenStreetMa
> p_France#Liste_des_services_web_sur_le_domaine_openstreetmap.fr


Effectivement, mais à ce moment là on pourrait avoir un lien depuis le menu
du site osm.fr vers cette page du wiki.

De plus un lien "Carte" vers tile.openstreetmap.fr qui serait bien
visible pourrait être sympa aussi. Même si OSM n'est pas juste une carte
(comme cela est rappelé sur la homepage) c'est quand même un truc assez
important la carte d'OSM, surtout si elle est en version française...
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Rendu avec relief sur osm.fr

[Vincent Frison]

Le 8 janvier 2018 à 02:50, Christian Quest  a
écrit :

> Voici un aperçu: https://framapic.org/gallery#2z7RctD1z97y/
> HuaZj7vuLgX3.png,iWtM0YZeqpgE/s1HWupUrNzCp.png
>
> J'ai juste mis les limites des communes pour se repérer. Premier exemple à
> un zoom moyen (environ 8), second à la résolution native, sur Paris...
>

Effectivement sur le second on voit bien que c'est la résolution native
(environ 30 mètres) !


> On y distingue une surface granuleuse à cause des bâtiments. Vous avez
> l'ombre de la Tour Eiffel, les tours de la Défense... toute la différence
> entre un MNT et MNS.
>

En fait j'imagine qu'à la base il n'y a uniquement des MNS qui sont ensuite
convertis après traitement en MNT (mais c'est jamais parfait, même pour
SRTM) ?

D'ailleurs je me demande bien comment ils font concrètement pour
transformer un MNS en MNT, ça ressemble un peu de la magie. Est ce qu'ils
se basent sur des orthophotos (genre pixel vert = végétation) ou sur des
données de land cover (pour savoir si on est  en ville par ex) afin de
savoir où et comment il faut retirer de la hauteur/élévation ?

Bon j'avoue que c'est un peu hors sujet mais c'est tellement passionant ;)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Rendu avec relief sur osm.fr

[Vincent Frison]

Le 6 janvier 2018 à 21:46, Vincent Frison <vincent.fri...@gmail.com> a
écrit :

> Le 6 janvier 2018 à 19:36, Christian Quest <cqu...@openstreetmap.fr> a
> écrit :
>
>> J'ai sorti du congélateur ce que j'avais fait l'hiver dernier sur
>> l'ombrage...
>>
>> STRMv3 est complet, j'avais calculé l'ombrage transparent, par contre
>> certaines dalles de 10° x 10° étaient trop volumineuses et avaient dépassé
>> les 2Go d'où un ombrage incomplet.
>>
>> Je regarde pour corriger ça, sinon 95% du boulot est fait.
>>
>> Pour info, l'image totale fait 1299600 x 414000 pixels, soit 538
>> milliards de pixels ;)
>> Le dossier avec les tuiles finales et leurs overview pèse 133Go... tout
>> le dossier du projet fait presque 600Go.
>>
>
Depuis le début je pensais que la moulinette qui convertissait le DEM en
raster d'ombrage était exécuté à la demande (avec un cache bien sûr) mais
en fait tu aurais donc déjà pré-calculé l'ensemble de la Terre ?

Et cette image de 538 milliards de pixels ne concernait que l'ombrage, il
devrait y avoir une image de taille équivalente pour les courbes de niveau
? Je n'ose même pas imaginer tout ce que ce qui traîne au fond de ton
cellier ;)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Liste des outils d'OSM FR

[Vincent Frison]

Suite à une ancienne discussion:

Plus globalement je trouve qu'il manque une page (voir un menu) listant
>> tous les super projets fait par OSM FR: osmose, les outils pour BANO ou le
>> cadastre, le serveur de tuile pour ne citer que ceux que je connais...
>>
>
> Tu ne connais pas http://openstreetmap.fr/outils
>

Ba voila c'est exactement la page que j'imaginais !

Mais je trouve ça dommage qu'elle soit aussi difficilement accessible. Le
seul lien que j'ai trouvé, avec difficulté, est tout en bas de la page
Association.

Ne pourrait on pas avoir un lien "Outils" ou "Services" carrément
dans le menu ?
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Rendu avec relief sur osm.fr

[Vincent Frison]

Le 6 janvier 2018 à 19:36, Christian Quest  a
écrit :

> J'ai sorti du congélateur ce que j'avais fait l'hiver dernier sur
> l'ombrage...
>
> STRMv3 est complet, j'avais calculé l'ombrage transparent, par contre
> certaines dalles de 10° x 10° étaient trop volumineuses et avaient dépassé
> les 2Go d'où un ombrage incomplet.
>
> Je regarde pour corriger ça, sinon 95% du boulot est fait.
>
> Pour info, l'image totale fait 1299600 x 414000 pixels, soit 538 milliards
> de pixels ;)
> Le dossier avec les tuiles finales et leurs overview pèse 133Go... tout le
> dossier du projet fait presque 600Go.
>

Je recréé un nouveau fil de discussion avec un sujet mieux adapté ;)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Rendu avec relief sur osm.org

[Vincent Frison]

Le 6 janvier 2018 à 19:36, Christian Quest  a
écrit :

> J'ai sorti du congélateur ce que j'avais fait l'hiver dernier sur
> l'ombrage...
>
> STRMv3 est complet, j'avais calculé l'ombrage transparent, par contre
> certaines dalles de 10° x 10° étaient trop volumineuses et avaient dépassé
> les 2Go d'où un ombrage incomplet.
>
> Je regarde pour corriger ça, sinon 95% du boulot est fait.
>
> Pour info, l'image totale fait 1299600 x 414000 pixels, soit 538 milliards
> de pixels ;)
> Le dossier avec les tuiles finales et leurs overview pèse 133Go... tout le
> dossier du projet fait presque 600Go.
>

C'est impressionnant !

Mais ce qui l'est encore plus c'est que tu nous sortes ça de ton
congélateur :)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Rendu avec relief sur osm.org

[Vincent Frison]

Le 5 janvier 2018 à 20:21, Christian Quest  a
écrit :

> Pour moi c'est à éviter car ça fait dépendre ton rendu d'un service tiers
> dont on ne contrôle pas la disponibilité.
>
> Si les tuiles externes d'ombrage ou de courbe de niveau ne sont pas
> dispo... on fait quoi ?
>
> Un serveur de tuile doit fonctionner en autonomie. Sur un client, c'est
> différent, tu peux mixer les tuiles si tu veux, vu que de toute façon tu
> dépends en général de tuiles tierces.
>
> Je digresse un peu... le recours bien facile aux services et données tiers
> c'est "pratique", mais casse gueule aussi.
> Les très nombreux utilisateurs des fonds mapquest en ont fait les frais...
> ceux qui utilisent les services de mapzen vont le découvrir à la fin de
> mois (mapzen plie boutique).
>
> Comme les médocs, les API c'est bien, en abuser ça craint ;)
>

Surtout si elles sont périmées :)

D'un point de vue purement serveur c'est vrai qu'il faut éviter de dépendre
des services extérieures, et si OSM FR était capable de fournir ça tout
seul ça serait vraiment génial !

Mais d'un point de vue client ça serait quand même bien sympa d'avoir un
layer supplémentaire pour le relief sur http://tiles.openstreetmap.fr :)

En fait y a déjà l'option Hillshshade (@openskimap.org) sauf que là aucun
des couches overlays fonctionnent...

D'ailleurs c'est dommage que cette page ne soit pas facilement accessible
depuis www.openstreetmap.fr, mais peut-être est ce un choix volontaire ?

Plus globalement je trouve qu'il manque une page (voir un menu) listant
tous les super projets fait par OSM FR: osmose, les outils pour BANO ou le
cadastre, le serveur de tuile pour ne citer que ceux que je connais...
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Rendu avec relief sur osm.org

[Vincent Frison]

Merci Christian pour ces précisions.

Donc l'idée c'est est d'avoir un MNT en local et une moulinette permettant
de le convertir à la volée en jolis tuiles rasters avec transparence, puis
bien configurer mapnik pour qu'il les utilise.

Mais là ça serait donc une solution propre, et du coup un peu complexe...

Par curiosité, n'y aurait il pas une solution beaucoup plus simple (mais
surement moins propre) consistant à réutiliser un serveur de tuiles
(d'ombrage ou de courbes de niveaux) et l'ajouter en transparence sur les
tuiles existantes ?

J'ai l'impression que c'est vraiment ce que fait http://opensnowmap.org
lorsqu'on utilise la rendu OSM standard comme background car si on se
déplace rapidement on voit d'abord les tuiles OSM standard puis le
relief qui se rajoute après (il y a un petit décalage de quelques
millisecondes). Par contre si on laisse le background par défaut SnowMap,
là il n'y a aucun décalage ce qui laisse supposer que c'est la solution
propre: il a intégré le relief directement dans son rendu et il n'y a donc
qu'un seul layer... ça se tient à peu près ce que je dis ? :)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Rendu avec relief sur osm.org

[Vincent Frison]

Le 5 janvier 2018 à 12:13, Christian Quest  a
écrit :

> C'est quelque chose que j'avais exploré pour le rendu FR... avec les
> courbes de niveau.
>
> Exemple: https://cl.ly/3u0J2p423J3M
>
Très joli !

> Pour un rendu vraiment propre, il faut appliquer l'ombrage en 2 fois, afin
> de ne pas trop ombrer certains objets comme les routes.
>
> Il y a de l'ombrage sur certaines zones du rendu HOT, sur les zones où
> l'usage est essentiellement lié à une crise et où le relief est un élément
> très important. Comme c'est quand même lourd à gérer, ça n'a pas été
> généralisé, mais on peut s'y remettre...
>
Avec plaisir, et d'ailleurs j'aimerais bien aider si possible...

Déjà comprendre le principe du hillshade: sur la ticket github énoncé plus
haut le gars proposait de récupérer le hillshade depuis NaturalEarth
.
Mais cela voudrait dire qu'on aurait des tuiles de relief qui seraient
certes déjà pré-calculés mais avec une résolution très limitée puisque leur
meilleur dataset est un gros TIFF de 21,600 x 10,800 pixels, ce qui fait
une résolution de l'ordre de ~2000 mètres.

J'imagine que la vraie solution est plutôt d'avoir les données brutes (DEM)
en provenance de SRTM1 ou ASTER GDEM dont la résolution native est de
l'ordre de 30 mètres et qu'elles soit ensuite transformées à la volée (avec
gdal par ex?) en raster hillshade ?

Ou l'idée est plutôt de réutiliser un service gratuit de tuiles de relief
comme http://c.tiles.wmflabs.org/hillshading par ex ? J'ai du mal à croire
que tous les autres services de tuiles OSM ayant du relief gênèrent eux
même le relief pour les intégrer directement leur layer...
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Rendu avec relief sur osm.org

[Vincent Frison]

Effectivement je peux comprend l'idée: sur osm.org il ne faudrait afficher
uniquement des données en provenance de la DB d'OSM.

Mais en fait l'argument d'une source données externe ne tient pas vraiment
puisqu'il y a déjà du hillshade sur le layer "carte cyclable" d'osm.org !

L'avantage du relief est tellement important sur une carte, c'est dommage
pour nous qui sommes des utilisateurs convaincus d'OSM, mais ça l'est
encore plus pour des non initiés qui découvrent OSM bien souvent depuis
osm.org qui du coup joue aussi le rôle de vitrine. Dans ce sens là je
trouve ça dommage de se priver du relief qui permet de mettre en valeur les
données d'OSM.



Le 5 janvier 2018 à 02:10, Jérôme Amagat  a écrit :

> Je pense que le truc principal qui fait qu'il n'y a pas de rendu du relief
> sur osm.org c'est que les données de relief ne sont pas dans la base de
> donnée osm.
> sur osm.org, on présente le maximum de données de la base openstreetmap
> mais pas d'autre chose.
> Après tout le monde peux utiliser les données openstreetmap mélangées à
> d'autres données par exemple le relief ( aux licences près)
> je suis d'accord que le relief apporte un plus sur une carte mais je ne
> pense pas qu'il ait sa place sur openstreetmap.org et il faut donc aller
> voir ailleurs pour voir le relief
>
>
>
> ___
> 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] Rendu avec relief sur osm.org

[Vincent Frison]

@althio: Merci pour le lien ! J'ai rajouté mon petit commentaire mais sans
trop d'espoir puisque le ticket a déjà été clôturé :(

@Jo: Oui le rendu sur hikebikemap.org est pas mal mais perso je préfère
opentopomap.org pour un zoom < 9 et opensnowmap.org pour un zoom > 9.


Le 3 janvier 2018 à 14:59, althio <althio.fo...@gmail.com> a écrit :

> Non tu n'es pas le seul, il suffit d'aller voir la question sur :
> https://github.com/gravitystorm/openstreetmap-carto/issues/2931
>
> -- althio
>
>
> 2017-12-28 15:10 GMT+01:00 Vincent Frison <vincent.fri...@gmail.com>:
> > Hello,
> >
> > Je sais pas si je suis le seul mais pour moi les cartes affichant le
> relief,
> > c'est à dire avec hillshade et/ou courbes de niveaux, sont bien plus
> jolies
> > que celles sont relief. Je dirais même qu'en plus d'être plus jolies
> elles
> > sont beaucoup plus claires car elles permettent de se repérer plus
> > facilement avec le relief.
> >
> > Le souci c'est que le rendu par défaut de osm.org n'a pas le relief et
> je
> > trouve ça plus que dommage.
> >
> > Il y a des sites proposant des rendus avec reliefs qui sont magnifiques
> > comme par ex. http://opentopomap.org ou http://opensnowmap.org. Le
> problème
> > c'est qu'ils n'ont pas la rapidité d'osm.org, ni toutes ses
> fonctionnalités
> > (principalement celle qui permet de chercher les objets afin de voir tous
> > les détails).
> >
> > Certes il y a le layer "carte cyclable" d'osm.org mais malheureusement
> le
> > relief est assez mal rendu et puis surtout il est vraiment orienté pour
> les
> > vélos en masquant la plupart des informations pour mettre en valeur
> celles
> > utiles aux cyclistes.
> >
> > J'ai l'impression que ça ne serait pas un énorme travail de rajouter le
> > relief sur le rendu par défaut d'osm.org. L'idée serait d'avoir une
> option
> > pour afficher le hillshade et les courbes de niveaux. c'est à dire 2
> petites
> > checkboxes en plus de celles existantes (permettant d'afficher les notes
> de
> > carte, etc.).
> >
> > Sur le site http://opensnowmap.org en allant dans les settings on peut
> > afficher le rendu standard d'OSM au lieu de celui d'OpenSnow.  J'ai
> > l'impression que c'est juste un layer supplémentaire (avec hillshade et
> > courbes de niveaux) qui s'affiche en plus de celui du rendu standard..
> mais
> > qui du coup n'a plus rien à voir avec le rendu classique, pour moi la
> valeur
> > ajoutée est vraiment énorme !
> >
> > Suis je le seul à qui ça manque ?
> >
> > Et à qui devrais  je demander cette évolution ? Sur un mailing list
> > particulière ou directement en créant une issue ici:
> > https://github.com/gravitystorm/openstreetmap-carto ?
> >
> > Merci, Vincent.
> >
> >
> > ___
> > 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] Rendu avec relief sur osm.org

[Vincent Frison]

Le 3 janvier 2018 à 11:03, Vincent Frison <vincent.fri...@gmail.com> a
écrit :

> Bon visiblement l'absence de relief sur openstreetmap.org ne gêne pas
> grand monde mis à part moi :)
>
> Sinon je me rend compte que sur tile.openstreetmap.fr il y a une petite
> option pour afficher les hillshades d'openpistemap.org mais
> malheureusement ça ne marche pas. C'est sans doute lié au fait que le site
> openpistemap.org est lui même down ?
>

En fait j'ai l'impression que c'est l'ensemble des overlays qui déconnent
sur tile.openstreetmap.fr.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Rendu avec relief sur osm.org

[Vincent Frison]

Bon visiblement l'absence de relief sur openstreetmap.org ne gêne pas grand
monde mis à part moi :)

Sinon je me rend compte que sur tile.openstreetmap.fr il y a une petite
option pour afficher les hillshades d'openpistemap.org mais malheureusement
ça ne marche pas. C'est sans doute lié au fait que le site openpistemap.org
est lui même down ?


Le 28 décembre 2017 à 15:10, Vincent Frison <vincent.fri...@gmail.com> a
écrit :

> Hello,
>
> Je sais pas si je suis le seul mais pour moi les cartes affichant le
> relief, c'est à dire avec hillshade et/ou courbes de niveaux, sont bien
> plus jolies que celles sont relief. Je dirais même qu'en plus d'être plus
> jolies elles sont beaucoup plus claires car elles permettent de se repérer
> plus facilement avec le relief.
>
> Le souci c'est que le rendu par défaut de osm.org n'a pas le relief et je
> trouve ça plus que dommage.
>
> Il y a des sites proposant des rendus avec reliefs qui sont magnifiques
> comme par ex. http://opentopomap.org ou http://opensnowmap.org. Le
> problème c'est qu'ils n'ont pas la rapidité d'osm.org, ni toutes ses
> fonctionnalités (principalement celle qui permet de chercher les objets
> afin de voir tous les détails).
>
> Certes il y a le layer "carte cyclable" d'osm.org mais malheureusement le
> relief est assez mal rendu et puis surtout il est vraiment orienté pour les
> vélos en masquant la plupart des informations pour mettre en valeur celles
> utiles aux cyclistes.
>
> J'ai l'impression que ça ne serait pas un énorme travail de rajouter le
> relief sur le rendu par défaut d'osm.org. L'idée serait d'avoir une
> option pour afficher le hillshade et les courbes de niveaux. c'est à dire 2
> petites checkboxes en plus de celles existantes (permettant d'afficher les
> notes de carte, etc.).
>
> Sur le site http://opensnowmap.org en allant dans les settings on peut
> afficher le rendu standard d'OSM au lieu de celui d'OpenSnow.  J'ai
> l'impression que c'est juste un layer supplémentaire (avec hillshade et
> courbes de niveaux) qui s'affiche en plus de celui du rendu standard.. mais
> qui du coup n'a plus rien à voir avec le rendu classique, pour moi la
> valeur ajoutée est vraiment énorme !
>
> Suis je le seul à qui ça manque ?
>
> Et à qui devrais  je demander cette évolution ? Sur un mailing list
> particulière ou directement en créant une issue ici: https://github.com/
> gravitystorm/openstreetmap-carto ?
>
> Merci, Vincent.
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] réflexion sur l'ia appliqué aux cartes

[Vincent Frison]

Article très intéressant !

Comme l'auteur je me demande quelle est la relation entre la technique leur
permettant d'avoir des modèles full 3D des villes lorsqu'on est en mode
satellite/3D et celle leur permettant d'avoir des empreintes de bâtiments
extrêmement précises (+ infos de hauteur visiblement) lorsqu'on en mode
carte / par défaut.

Mais dans le 1er cas c'est clairement fait avec de la photogrammétrie alors
que dans le 2e cas l'auteur laisse penser que les algos de Google se
seraient basés des images ariennes standards... ce qui me semble peu
probable. A mon avis ils font d'abord de la photogrammétrie, et une fois
qu'ils ont leur modèle 3D ils peuvent (re)dessiner les bâtiments pour le
mode carte / par défaut.


Le 25 décembre 2017 à 15:32,  a écrit :

> Autant l'exemple de Christian est bon (on peut détecter non seulement la
> forme mais aussi l'encombrement - un toit plat incliné vers le sud est
> idéal mais s'il est occupé par des cheminées et autres antennes, il est
> moins utilisable pour du solaire), autant l'exemple de Google alourdit la
> carte.
>
> Déjà nos empreintes de bâtiments sont la moitié de la base.
>
> Dans l'article de Google ils disent que ça permet de reconnaître plus
> facilement un bâtiment. Exact. Sauf qu'il ne faut le faire que pour les
> bâtiments remarquables et mettre en avant les traits remarquables.
>
> J'entends pour de la cartographie. Par exemple quand Google détecte une
> parabole sur un bâtiment, c'est utile si ça permet de le repérer parmi 10
> bâtiments identiques, sinon c'est sans intérêt pour la quasi totalité des
> utilisateurs et apportera plus un bruit de fond (aussi un aspect réaliste
> pour une simulation 3D).
>
> De même on trace les routes, on ne les dessine pas (avoir la largeur de la
> route n'est pas inutile, par contre le détail importe peu et peu nuire à la
> lisibilité : un bon livre d'ornithologie dessine des caractéristiques de
> l'oiseau et ne donne pas une photo de l'animal).
>
> Bon, super, avec de l'IA je fais un programme qui ajoute surface=aslphat
> sur des routes en fonction de la couleur et hop, plein de bitcoins sur mon
> compte.
>
> Donc IA oui, mais à bon escient.
>
>
> /\
>
>   /__\
>
> /\
>
>   /__\
>
> /\
>
>|_|
>
> Ceci n'est pas un sapin ;-)
>
> Jean-Yvon
>
> Le 24/12/2017 à 10:15, François Lacombe - fl.infosrese...@gmail.com a
> écrit :
>
> Bonjour
>
> Je partage également votre avis, les techniques d'apprentissage
> permettraient aussi de détecter les biais dans l'utilisation des tags.
> Surtout signaler à l'utilisateur que certaines combinaisons sont peu
> utilisées en proportion à l'utilisation des clés concernées donc
> probablement erronées  (building + man_made=street_cabinet par ex)
>
> Ca permettrait de faciliter le travail de developpelent d'osmose
>
> My 2 cents
>
> François
>
> Le 23 déc. 2017 1:15 PM, "Martin Noblecourt"  a
> écrit :
>
>> Tout à fait d'accord avec Christian !
>>
>> Les initiatives se multiplient de télédétection automatique, l'enjeu va
>> être une intégration harmonieuse avec la base de données et la culture OSM
>> existante, donc forcément avec une intervention humaine pour
>> contrôler/harmoniser.
>>
>> Côté CartONG on a plusieurs petites expérimentations dans les tuyaux
>> (pré-reconnaissance automatique des zones résidentielles avant validation
>> humaine notamment), si des gens sont intéressés pour aider nos bénévoles là
>> dessus, n'hésitez pas à me contacter ;-)
>>
>> Joyeux Noël à tous !
>>
>> Martin
>>
>> On 23/12/2017 13:00, talk-fr-requ...@openstreetmap.org wrote:
>>
>> Subject:
>> Re: [OSM-talk-fr] réflexion sur l'ia appliqué aux cartes
>>
>> From:
>> Christian Quest  
>>
>> Date:
>> 23/12/2017 12:49
>>
>> To:
>> Discussions sur OSM en français 
>> 
>> Je suis persuadé qu'on ira de plus en plus dans cette direction.
>> OpenSolarMap a permis d'apprendre dans ce domaine, ce sont des technique de
>> plus en plus accessibles et il serait dommage de s'en priver.
>>
>> Comme toujours, il faut bien voir ce que ça apporte et les limites.
>> Si on prend le GPS, il a permis à OSM de décoller, mais ce n'est pas pour
>> cela qu'on utilise les traces GPS brutes pour tracer les routes et chemins.
>>
>> Ce sont des outils qui servent à simplifier et automatiser ce qui peut
>> l'être sans perte de qualité par rapport à du travail de fourmis humaines.
>>
>>
>> Le 23 décembre 2017 à 12:41, marc marc  a
>> écrit :
>>
>>> Bonjour,
>>>
>>> Petite article intéressant (même si un peu long)
>>> https://www.justinobeirne.com/google-maps-moat
>>> l’intéressant pour osm n'est pas la comparaison apple <> google mais
>>> l'utilisation de l'ia.
>>> pendant qu'on fait dessine à la main le contour des batiments dans
>>> certains pays, le computer vision le fait en masse.
>>> Il y a aussi un 

[OSM-talk-fr] Rendu avec relief sur osm.org

[Vincent Frison]

Hello,

Je sais pas si je suis le seul mais pour moi les cartes affichant le
relief, c'est à dire avec hillshade et/ou courbes de niveaux, sont bien
plus jolies que celles sont relief. Je dirais même qu'en plus d'être plus
jolies elles sont beaucoup plus claires car elles permettent de se repérer
plus facilement avec le relief.

Le souci c'est que le rendu par défaut de osm.org n'a pas le relief et je
trouve ça plus que dommage.

Il y a des sites proposant des rendus avec reliefs qui sont magnifiques
comme par ex. http://opentopomap.org ou http://opensnowmap.org. Le problème
c'est qu'ils n'ont pas la rapidité d'osm.org, ni toutes ses fonctionnalités
(principalement celle qui permet de chercher les objets afin de voir tous
les détails).

Certes il y a le layer "carte cyclable" d'osm.org mais malheureusement le
relief est assez mal rendu et puis surtout il est vraiment orienté pour les
vélos en masquant la plupart des informations pour mettre en valeur celles
utiles aux cyclistes.

J'ai l'impression que ça ne serait pas un énorme travail de rajouter le
relief sur le rendu par défaut d'osm.org. L'idée serait d'avoir une option
pour afficher le hillshade et les courbes de niveaux. c'est à dire 2
petites checkboxes en plus de celles existantes (permettant d'afficher les
notes de carte, etc.).

Sur le site http://opensnowmap.org en allant dans les settings on peut
afficher le rendu standard d'OSM au lieu de celui d'OpenSnow.  J'ai
l'impression que c'est juste un layer supplémentaire (avec hillshade et
courbes de niveaux) qui s'affiche en plus de celui du rendu standard.. mais
qui du coup n'a plus rien à voir avec le rendu classique, pour moi la
valeur ajoutée est vraiment énorme !

Suis je le seul à qui ça manque ?

Et à qui devrais  je demander cette évolution ? Sur un mailing list
particulière ou directement en créant une issue ici:
https://github.com/gravitystorm/openstreetmap-carto ?

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

Re: [OSM-talk-fr] [osm-grenoble] Importation des arbres municipaux de Grenoble

[Vincent Frison]

Le 24 novembre 2017 à 09:50, Vincent Frison <vincent.fri...@gmail.com> a
écrit :

> Le 20 novembre 2017 à 08:12, Christian Quest <cqu...@openstreetmap.fr> a
> écrit :
>
>> Vu que ce sujet n'a démarré qu'il n'y a que 4 jours, je ne vois pas
>> l'urgence à faire l'upload. Il me semble préférable d'avoir encore quelques
>> retours et se donner une semaine entre une proposition d'import, les
>> premiers fichiers à vérifier et l'upload final n'est pas exagéré. Tout le
>> monde n'est pas en mode "chat" sur talk-fr ;)
>>
>
>> Pour le reste ça me semble ok.
>>
>
> Hello,
>
> Bon je vais donc faire l'import ce soir si j'ai le temps, sinon demain.
>

Et voila c'est fait ! :)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] [osm-grenoble] Importation des arbres municipaux de Grenoble

[Vincent Frison]

Le 20 novembre 2017 à 08:12, Christian Quest  a
écrit :

> Vu que ce sujet n'a démarré qu'il n'y a que 4 jours, je ne vois pas
> l'urgence à faire l'upload. Il me semble préférable d'avoir encore quelques
> retours et se donner une semaine entre une proposition d'import, les
> premiers fichiers à vérifier et l'upload final n'est pas exagéré. Tout le
> monde n'est pas en mode "chat" sur talk-fr ;)
>

> Pour le reste ça me semble ok.
>

Hello,

Bon je vais donc faire l'import ce soir si j'ai le temps, sinon demain.

Pour le coup du tag référence j'ai l'impression que le débat peut être sans
fin mais au final je vais le garder car il a été demandé, et même si
personnellement je n'y vois pas un grand intérêt à la garder j'y vois un
intérêt encore moins grand à le retirer.

Pour la source, si l'import est fait avec un compte dédié tel que "Import
> Grenoble trees" (ce qui est demandé dans les Import Guidelines), ça
> complète très bien un unique tag source sur le changeset.
>

En fait j'ai l'habitude d'utiliser un compte dédié pour tous mes imports
(VinceBot) mais par contre je n'ai pas un compte dédié pour chaque import.
Il y a d'ailleurs eu une discussion récemment sur la liste import et
visiblement il est convenable d'avoir un unique compte dédié pour plusieurs
imports

Mais sinon oui je mettrai évidemment les différents tags sources (ainsi que
website et comment) sur le changeset et non pas sur chacun des éléments.

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

Re: [OSM-talk-fr] Stats serveurs de tuiles OSM-FR...

[Vincent Frison]

Effectivement c'est sexy !

Je suis étonné de voir que sur 38 TB seulement 15 viendrait de la France...


Le 20 novembre 2017 à 13:38, sly (sylvain letuffe)  a
écrit :

> Il est très sexy ce goaccess, mais si on gratte, il manque quand même
> quelques trucs bien utiles (c'est p'tet un truc qui s'active) :
>
> Dans les referers il annonce "www.free.fr" en 14ème place mais fouiller
> tout
> leur site pour trouver à quelle page ils s'en servent, c'est pas aisé !
> ( Referrers URLs: If the host in question accessed the site via another
> resource, or was linked/diverted to you from another host, the URL they
> were
> referred from will be provided in this panel. See `--ignore-panel` in your
> configuration file to enable it. (disabled by default) )
>
> Y'a un truc pour changer la période d'analyse ?
> Là on a 31/Dec/2016 — 20/Nov/2017
> Mais si je veux savoir comment a évolué la provenance des internautes entre
> décembre 2016 et décembre 2017 ?
>
>
>
>
>
>
> -
> --
> sly, contact direct : sylvain /a\ letuffe o r g
> http://wiki.openstreetmap.org/wiki/User:Sletuffe
> --
> Sent from: http://gis.19327.n8.nabble.com/France-f5380434.html
>
> ___
> 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] [osm-grenoble] Importation des arbres municipaux de Grenoble

[Vincent Frison]

Ok pour virer le tag genus (si species est présent) et pour attendre la fin
de la semaine avant de faire l'import...
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] [osm-grenoble] Importation des arbres municipaux de Grenoble

[Vincent Frison]

Le 19 novembre 2017 à 20:26, marc marc  a écrit :

> En résumé, je mettrais sur le changeset :
> source=data.metropolegrenoble.fr ou Metropole Grenoble
> source:date=2017
> website=lien vers la page wiki de l'import
> source:website=http://data.metropolegrenoble.fr/ckan/dataset
> /les-arbres-de-grenoble


Je suis ok sauf pour le dernier je préfère mettre que le DNS du site, les
liens précis ne sont pas forcément stables dans le temps...

Sinon Jérôme pas de souci puisque vous pourriez y trouver une utilité j'ai
rajouté ce tag de référence (avec ref:FR:Grenoble:trees comme clé).

Voici du coup une nouvelle version avec également la suppression du tag
source pour les updates: https://files.fm/u/ks2288qb

Si pas d'objection je ferai l'upload demain soir ! :)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Importation des arbres municipaux de Grenoble

[Vincent Frison]

Le 18 novembre 2017 à 18:03, marc marc  a écrit :

> Peux-tu isoler le cas où plusieurs arbres sont dans ton rayon
> de sécurité de 5m ?

est-ce que ce sont des espèces différentes ou identique ?
>

Oui ces cas sont isolés mais actuellement l'algo ne regarde que la
distance. C'est vrai qu'il pourrait aussi prendre en compte le genre/espèce
même si dans la majorité des cas les arbres existants n'ont pas ces
attributs malheureusement. Mais c'est une idée intéressante pour une
évolution future.

Sinon je me rend compte que j'avais mis 3 mètres comme rayon de
correspondance alors que j'avais mis 5 mètres pour Nice. Clairement autant
élargir à 5 mètres car de toute façon ça sera toujours l'arbre le plus
proche qui sera mis à jour mais au moins ça permet de "récupérer" un peu
plus d'arbres placés un peu trop grossièrement.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Importation des arbres municipaux de Grenoble

[Vincent Frison]

Merci beaucoup pour vos retours !

Au final je vais donc ne pas rajouter de tag ref et je vais toujours
renseigner genus ET species (s'il y a une valeur bien sûr).

J'ai corrigé le coup des espèces/genres qui pouvaient ne pas avoir de
valeur ainsi que le problème de l'UTF-8 (une nouvelle version est
disponible ici: https://files.fm/u/ct7mm6dk).

@Paul: à vrai dire vu le faible nombre d'arbres "non makable" je comptais
les ignorer complètement et donc ne rien faire avec... mais n'hésites
surtout pas à utiliser le fichier si tu te sens de supprimer ou corriger
des bâtiments qui seraient inexacts !





Le 18 novembre 2017 à 18:03, marc marc  a écrit :

> Peux-tu isoler le cas où plusieurs arbres sont dans ton rayon
> de sécurité de 5m ?
> est-ce que ce sont des espèces différentes ou identique ?
>
> > - est ce que cela vaut la peine de rajouter un tag ref:FR:Grenoble:trees
> > jour je n'en aurais pas vraiment besoin).
> Si tu n'en as besoin pour un prochain import, alors c'est probablement
> inutile de l'ajouter.
> la seule utilité que je vois serrait de pouvoir remonter à Grenoble un
> éventuel problème de localisation d'un arbre ou abattage.
> Mais les arbres ont-il la ref sur eux ? sinon c'est même pas sur qu'un
> déplacement d'un noeud osm correspond toujours au même arbre
>
> > - pour le tag genus/species: dans leur fichier JSON il y a 2 champs
> > séparés, par ex: "GENRE_BOTA":"Platanus","ESPECE":"acerifolia". Pour
> > remplir le tag genus je prend la valeur du champ GENRE_BOTA mais pour le
> > tag species je concatène
> > la valeur des 2 champs. Du coup ça vaut quand même la peine que je mette
> > le tag genus (sachant qu'il est déjà "inclus" dans le champ species) ?
>
> Genus donnant la catégorie globale, je trouve que c'est pratique
> de  l'ajouter même quand on connaît l'espèce précise.
> Mais en voyant la différence d'occurence entre les 2, certains pensent
> le contraire.
>
> > dois je annoncer à chaque fois mes importations
>
> Selon moi, une annonce par type d'import me semble suffisant quitte à
> annoncer que l'import concernera d'autres villes française et mettre à
> jour la page wiki au fur et à mesure des différentes villes.
> Il peux aussi être utile d'ajouter un tag website sur le changeset
> vers la page de l'import.
>
> > très faible nombre d'imports annoncés.
>
> nombreux ne sont en effet pas annoncés.
> j'en croise des problématiques tous les mois :(
> je trouve cela domage car discuter d'un import est un moyen pratique
> d'éviter les éventuels problèmes de qualité.
>
> ___
> 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] Importation des arbres municipaux de Grenoble

[Vincent Frison]

Merci Sly pour ton retour.

Bien vu pour l'erreur d'encodage UTF-8 !

Sinon 2 petites questions:

- est ce que cela vaut la peine de rajouter un tag ref:FR:Grenoble:trees
avec comme valeur une référence interne (utilisée dans le fichier JSON) ?
J'avais cru comprendre que c'était une bonne pratique mais que finalement
c'était pas souhaitable. Personnellement je pense pas que ça soit super
utile (par ex. si je devais refaire un import pour mise à jour je n'en
aurais pas vraiment besoin).

- pour le tag genus/species: dans leur fichier JSON il y a 2 champs
séparés, par ex: "GENRE_BOTA":"Platanus","ESPECE":"acerifolia". Pour
remplir le tag genus je prend la valeur du champ GENRE_BOTA mais pour le
tag species je concatène
la valeur des 2 champs. Du coup ça vaut quand même la peine que je mette le
tag genus (sachant qu'il est déjà "inclus" dans le champ species) ?

Enfin pour respecter la procédure j'ai commencé à créer une page wiki mais
dois je annoncer à chaque fois mes importations sur
impo...@openstreetmap.org ? En fait cela ne me dérange pas mais ce qui
m'étonne c'est de voir le très faible nombre d'imports annoncés. Sur le
catalogue <https://wiki.openstreetmap.org/wiki/Import/Catalogue> on peut
voir que sur les 3 derniers mois il n'y a eu que 3 imports et ce sont les
miens ! Cela voudrait dire que pas mal d'imports se font "à la douce" ?

Merci, Vincent.




Le 17 novembre 2017 à 22:06, sly (sylvain letuffe) <lis...@letuffe.org> a
écrit :

> Vincent Frison wrote
> > Le voici donc, valide pendant un mois: https://files.fm/u/shq299cz
>
> J'ai fais de nombreux sondages aléatoires à l'aide des photos aériennes
> récentes et ça à l'air de la bonne qualité, très cohérent avec l'existant,
> et sans doublons trouvés.
> Je ne passe toutefois pas assez souvent sur Grenoble pour tenter une vérif
> "in situ".
>
> L'algo a donc l'air de bien bosser en plus d'une donnée source de bonne
> qualité, c'est tout bon !
>
> Note: Il semble qu'un double encodage UTF-8 se soit glissé dans
> l'incorporation des genus/species
> Fichier genfile-for-creation.osm ligne 1670 par exemple :
>
> 
>
>
>
>
>
>
>
> -
> --
> sly, contact direct : sylvain /a\ letuffe o r g
> http://wiki.openstreetmap.org/wiki/User:Sletuffe
> --
> Sent from: http://gis.19327.n8.nabble.com/France-f5380434.html
>
> ___
> 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] Importation des arbres municipaux de Grenoble

[Vincent Frison]

Le 17 novembre 2017 à 00:14, sly (sylvain letuffe)  a
écrit :

> Si tu as déjà fait l'outil, ça serait bien de fournir si c'est possible le
> fichier osm résultant, plusieurs personnes, et surtout ceux de grenoble
> pourront ainsi faire un sondage sur quelques arbres et juger de la qualité
> du fichier d'origine et du process.
>

J'ai déjà envoyé en privé tout le XML à des personnes mais effectivement le
mieux est que je fournisse un lien public.

Le voici donc, valide pendant un mois: https://files.fm/u/shq299cz

J'ai grand grand peur que des arbres puissent atterrir dans un bâtiment
> privé, sur une route, dans une fontaine, etc.

Et je sais qu'il est tentant de dire : c'est les autres qui ont mal
> positionné leur fontaine/batiment/etc. mais osm n'est pas une base ou on
> empile des datas opensource, la cohérence relative des éléments les uns par
> rapport aux autres me semble préférable en étant décalé de 5m qu'un arbre
> sur un toit.
> Ou alors, la tâche d'importation est manuelle, un par un et s'occupe de
> vérifier qui à tort qui a raison et consiste à recaller les éléments
> autour.
>

Pour la superposition avec des bâtiments c'est pas possible puisque je fais
une vérification (pour les fontaine non plus si celles ci sont faites avec
un building).
Pour les routes je n'ai pas remarqué de superpositions jusqu'à présent mais
je vais y prêter attention...

Pour les tree_rows j'avoue qu'ils ne sont pas pris en compte, enfin sauf
s'ils sont composés d'arbres qui existent également individuellement
(auquel cas ils pourront être fusionnés avec les nouveaux arbres). C'est en
tout cas une très bonne remarque et je vais voir si je peux les prendre en
compte dans mon algo même si effectivement là dans le cas de Grenoble je
vais pouvoir les gérer manuellement vu leur faible nombre (une petite
vingtaine).

PS: merci Julien d'avoir mis en copie l'adresse du groupe local de
Grenoble, j'aurais du y penser...
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Importation des arbres municipaux de Grenoble

[Vincent Frison]

Le 16 novembre 2017 à 23:47, marc marc <marc_marc_...@hotmail.com> a écrit :

> Le 16. 11. 17 à 23:23, Vincent Frison a écrit :
>
> > l'année de plantation.  > Malheureusement je ne vois rien de tel sur le
> wiki...
>
> J'en ai vu beaucoup avec start_date que je trouves cohérent.
> L'arbre a commencé à exister quand on l'a planté.
> J'en ai vu quelques un en plantation:FR=date (cela semble être un import
> non discuté) que j'ai sur ma liste de "à harmoniser"
>

Ok à défaut de mieux je vais donc utiliser start_date, merci pour l'info.


> > dans un rayon de 3 mètres: s'il y en a pas il créé un nouvel arbre et
> sinon il met à jour
> > l'arbre (le plus proche s'il y en a plusieurs)
>
> S'il y a plusieurs arbres dans ton rayon de sécurité,
> je pense qu'il serrait prudent dans un premier temps de ne pas
> les modifier... parce que ce n'est pas sur que le plus proche correspond.
> Sauf évidement s'ils sont tous identique



> Pour info voici quelques stats:
>
> Aurais-tu une liste de tout les clefs crées et un exemple de valeur
> pour chacun d'elle ?
> et/ou faire un import réel limité à un ou quelques arbres pour regarder
> à toute petite échelle le premier import avant l'import complet ?
>

Le mieux c'est carrément que je t'envoies un zip de seulement 500 Kb qui
contient tout (l'ensemble des arbres nouveaux et ceux à modifier).


> C'est le premier import d'arbres de ton outil ou il y en a eu avant ?
>

J'avais déjà fait un import d'arbres sur Nice il y a 2 ans:
https://wiki.openstreetmap.org/wiki/Nice,_France/Trees_Import

Le script est dispo ici:
https://github.com/vince-from-nice/osmaxil/blob/master/src/main/java/org/openstreetmap/osmaxil/flow/VegetationMakerFlow.java

La différence c'est qu'il y a des champs en plus mais sinon le process est
le même..

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

[OSM-talk-fr] Importation des arbres municipaux de Grenoble

[Vincent Frison]

Hello,

Je projette d'importer les arbres municipaux de Grenoble disponibles en
ODbL sur le portail open date le ville:
http://data.metropolegrenoble.fr/ckan/dataset/les-arbres-de-grenoble

Contrairement aux données de la ville de Nice il n'y a pas que la
localisation mais aussi le genre/espèce et l'année de plantation. Pour
cette dernière info pensez vous qu'il est possible de rajouter un tag ?
Malheureusement je ne vois rien de tel sur le wiki...

Mon script regarde si des arbres existent déjà dans un rayon de 3 mètres:
s'il y en a pas il créé un nouvel arbre et sinon il met à jour l'arbre (le
plus proche s'il y en a plusieurs) en modifiant la position et en ajoutant
les tags d'espèces/genre (sauf s'il existe déjà une valeur). Il y a
également une vérification pour éviter d'importer un arbre à l'intérieur
d'un bâtiment.

Pour info voici quelques stats:
2017-11-16 22:52:02  INFO === Loading statistics ===
2017-11-16 22:52:02  INFO Total of parsed imports: 30850
2017-11-16 22:52:02  INFO Total of filtered out imports: 62
2017-11-16 22:52:02  INFO Total of loaded imports: 30788
2017-11-16 22:52:02  INFO === Processing statistics ===
2017-11-16 22:52:02  INFO Total of makable imports: 30737
2017-11-16 22:52:02  INFO Total of non makable imports: 51
2017-11-16 22:52:02  INFO Matching area radius: 3.0
2017-11-16 22:52:02  INFO Matching closest only: true
2017-11-16 22:52:02  INFO Total of created trees: 24211
2017-11-16 22:52:02  INFO Total of updated trees: 6526
2017-11-16 22:52:02  INFO Total of created or updated trees: 30737
2017-11-16 22:52:02  INFO Total of multi matching trees: 558
2017-11-16 22:52:02  INFO Job has been executed in 535 seconds
2017-11-16 22:52:03  INFO === Closing OSM XML service ===
2017-11-16 22:52:03  INFO Total of writing successes: 3
2017-11-16 22:52:03  INFO Total of writing failures: 0
2017-11-16 22:52:03  INFO === Closing OSM API service ===
2017-11-16 22:52:03  INFO Total of read operations: success=6748 failure=0
2017-11-16 22:52:03  INFO Total of write operations: success=0 failure=0
2017-11-16 22:52:03  INFO Total of changeset operations: open=0 close=0

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

Re: [OSM-talk-fr] Une application pour visualiser le cadastre

[Vincent Frison]

Le 13 novembre 2017 à 10:16, albanm  a écrit :

> Bonjour,
>
> Je suis co-fondateur de Koumoul et c'est moi qui ai travaillé sur cette
> carte, nous sommes tombés sur ce fil de discussion et je vais en profiter
> pour éclaircir quelques petites choses.
>
> Sur cette carte nous avons fourni un travail d'intégration et d'exposition
> Web, nous n'avons fait aucun travail de fond sur la donnée.
>

En tout cas joli travail, la carte est vraiment agréable à utiliser pour
voir le cadastre..

Sinon je sais toujours pas comment vous avez fait pour vectoriser les
bâtiments sur l'ensemble des communes mais n'y aurait il pas moyen d'en
récupérer un peu dans OSM ? ;)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Une application pour visualiser le cadastre

[Vincent Frison]

Excellent !

Mais je suis surpris de voir qu'il y a sur leur carte les bâtiments même
sur des communes pour lesquelles il n'y en a pas dans OSM, par ex. les
Adrets de l'Esterel dans le Var pour laquelle le cadastre n'a pas encore
été vectorisé. Comment ont ils fait  ?



Le 10 novembre 2017 à 15:58, Christian Rogel <
christian.ro...@club-internet.fr> a écrit :

> Une start-up, Koumoul (nuage/cloud en breton) veut créer des applications
> pour faciliter l’utilisation de l’open data.
> A titre d’exemple, elle propose gratuitement une expérimentation avec le
> cadastre : https://koumoul.com/s/cadastre/ .
> Ça devrait nous rendre service.
>
> Christian R.
>
> ___
> 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] Importation des hauteurs de bâtiments sur Montpellier

[Vincent Frison]

Je confirme que tout a l'air bon maintenant.

Le nombre final de bâtiments mis à jour est 55 605.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

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

[Vincent Frison]

Pour info j'ai corrigé le problème.

J'ai d'abord essayé de faire des reverts sur quelques changesets mais
malheureusement ils étaient tous déjà dirty alors que l'import avait été
fait moins de 24h avant...

Finalement j'ai préféré refaire un petit programme pour retirer le tag
height sur les buildings pour lesquels la valeur du MNT était de 0, soit
5172 éléments. C'est donc cohérent avec ce que je pouvais voir dans les
logs de l'import.

Normalement tout est bon mais je referai des vérifications (pour l'instant
le cache de F4Map n'est pas à jour).

++ Vincent


Le 5 novembre 2017 à 10:07, Christian Quest <cqu...@openstreetmap.fr> a
écrit :

> N'importe qui peut faire un revert... il n'y a que la "redaction" qu'un
> admin peut faire, c'est à dire faire disparaitre aussi une info au niveau
> des historiques.
>
> 
> Vincent... il faut que tu sache corriger toi même un import ou une édition
> automatisée si besoin.
> C'est le minimum à connaitre avant de s'engager dans ce genre de choses,
> sinon tu te fera taper sur les doigts (à juste titre).
> 
>
> Pour l'ODbL, c'est effectivement un peu ridicule et participe de la
> politique anti-import de certains.
>
> Ceci dit, les collectivités françaises qui ont opté pour l'ODbL, devraient
> en principe revoir ce choix, car il n'est pas forcément bien légal... (cf
> mes slides du dernier SOTM "ODbL... oui mais").
>
>
> Le 4 novembre 2017 à 23:29, Vincent Frison <vincent.fri...@gmail.com> a
> écrit :
>
>> Le 4 novembre 2017 à 23:06, marc marc <marc_marc_...@hotmail.com> a
>> écrit :
>>
>>> Tu peux pas identifier les bâtiments où mmt = 0 ?
>>>
>>
>> Si si tout est dans les logs...
>>
>>
>>> Sinon y a le revert plugin
>>>
>>
>> Ah super je vais regarder ça, en fait je pensais que c'était un truc
>> réservé aux admins...
>>
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>>
>
>
> --
> Christian Quest - OpenStreetMap France
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

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

[Vincent Frison]

Le 4 novembre 2017 à 23:06, marc marc  a écrit :

> Tu peux pas identifier les bâtiments où mmt = 0 ?
>

Si si tout est dans les logs...


> Sinon y a le revert plugin
>

Ah super je vais regarder ça, en fait je pensais que c'était un truc
réservé aux admins...
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

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

[Vincent Frison]

Un truc a visiblement merdé car sur certaines zones qui sont hors des
limites de la commune le MNT fournit la valeur 0 au lieu de -. Je ne
comprend vraiment pas pourquoi puisque le TIFF avait bien été découpé avec
les limites de la communes, résultat visible ici .

Malheureusement j'avais mis [0..1000] mètres comme valeurs possibles. Oui
carrément 0 car certaines zones sont vraiment au niveau de la mer.. sauf
que ça n'arrive seulement dans des communes limitrophes, c'était donc un
peu bête de ma part et j'aurais du mettre 10 mètres comme valeur minimale
pour le commune de Montpellier en elle-même...

Du coup il y a 5172 bâtiments qui ont été mis à jour et qui le devrait pas,
les valeurs sont tout simplement fausses.

Je ne pense que ça soit facilement corrigeable avec JOSM ni même avec
OverpassAPI (la valeur du tag height étant une string et pas entier je vois
pas comment on peut faire une condition sur la hauteur).

Serait il possible de faire un revert pour que je puisse ensuite refaire
l'import avec le bon setting ?

En espérant que ça ne soit pas trop fastidieux sachant qu'il y a 61
changesets en tout...

Merci, Vincent.








Le 4 novembre 2017 à 21:29, Vincent Frison <vincent.fri...@gmail.com> a
écrit :

> Hello,
>
> J'ai fait l'import la nuit dernière et 60 777 bâtiments ont été mis à jour
> avec leur hauteur.
>
> Pour info il y a eu 2 difficultés pour cet import:
>
> - Le DTM et le DSM qui n'étaient pas dans des bons formats à l'origine
> mais ça s'est résolu avec les outils de GDAL / OGR (merci à Christian pour
> son aide sur le forum)
>
> - Je ne pensais pas du tout avoir des soucis en important ces données
> puisqu'elles étaient sous licence ODbL mais suite à la discussion sur la
> liste import cela pourrait théoriquement poser problème dans le cas (très
> improbable j'imagine) où OSM déciderait de changer vers une licence non
> compatible avec ODbL (cf. le Contributor Terms). En même temps cela
> voudrait dire qu'on devrait se restreindre à importer uniquement des
> données en domaine publique ou CC0 ce qui me parait bien trop restrictif...
> en sachant qu'en plus il y a déjà eu des tonnes d'imports en ODbL ou en
> d'autres licences (qui n'étaient ni DP ni CC0) !
>
> ++ Vincent.
>
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

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

[Vincent Frison]

Hello,

J'ai fait l'import la nuit dernière et 60 777 bâtiments ont été mis à jour
avec leur hauteur.

Pour info il y a eu 2 difficultés pour cet import:

- Le DTM et le DSM qui n'étaient pas dans des bons formats à l'origine mais
ça s'est résolu avec les outils de GDAL / OGR (merci à Christian pour son
aide sur le forum)

- Je ne pensais pas du tout avoir des soucis en important ces données
puisqu'elles étaient sous licence ODbL mais suite à la discussion sur la
liste import cela pourrait théoriquement poser problème dans le cas (très
improbable j'imagine) où OSM déciderait de changer vers une licence non
compatible avec ODbL (cf. le Contributor Terms). En même temps cela
voudrait dire qu'on devrait se restreindre à importer uniquement des
données en domaine publique ou CC0 ce qui me parait bien trop restrictif...
en sachant qu'en plus il y a déjà eu des tonnes d'imports en ODbL ou en
d'autres licences (qui n'étaient ni DP ni CC0) !

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

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

[Vincent Frison]

Hello Marc,

Le 30 octobre 2017 à 10:34, marc marc  a écrit :

> Bonjour Vincent,
>
> merci pour cette énergie.
>

Merci ;)


> As-tu mis en place une "protection" pour ne pas modifier l'objet si la
> valeur obtenue est hors-limite raisonnable ? si oui quelle valeur ?
>

Oui il y a des garde fous configurables.

Pour l'import de Montpellier j'ai mis comme valeur min/max 0 et 1000 mètres
pour le MNT, et pareil pour le MNS.

Pour le MNT il faut savoir que j'ai du le "découper" avec les limites de la
communes car seules les valeurs à l'intérieur de celles ci sont fiables et
précises => à l'extérieur de la commune toutes les valeurs sont à -9 et
donc exclues lors de l'import.


> Sur le principe, feu vert pour moi pour l'import.
>
> Je me posais des question à propos des formes de toit et étages.
>
> Au vu des explications précédentes, je pensais que ton algorithme
> n'allait retenir que les bâtiments aux toits plats vu que ce sont les
> seuls dont la hauteur est "stable" sur sa surface.
> Mais quand je vois que tu trouves une valeur pour 59346 bâtiments (si
> j'ai bien compris) sur 110180, mon raisonnement est visiblement erroné.
> est-ce que c'est à cause de la fourchette de tolérance que tu arrives à
> mettre une valeur aussi sur les toits en pente ?
> Penses-tu qu'une opération (séparée) permettrait de les toits plats
> en fonction de l'écart moyen des hauteurs ? j'imagine que
> la tranche 90-100% serrait une bonne candidate.
>

Effectivement mon script essaye de tout prendre, sans considérer la pente
du toit. Le problème c'est qu'on a quasiment jamais l'information sur le
toit...

Je reprend mon message posté sur le fil de discussion pour Nice:

*D'après le wiki le tag height pour les buildings est censé indiquer le
point le plus haut du bâtiment mais à l'exclusion des structures rajoutées
comme par ex. les mats ou antennes. Mon script est censé gérer ça, en tout
cas il gère plutôt bien par exemple les petits locales techniques qui sont
très fréquents sur les immeubles. Pour simplifier si la hauteur max est de
Z mètres je vérifie si au moins 30% de l'ensemble des points "matchant"
l'immeuble sont à moins de 2 mètres de Z. Si c'est le cas c'est bon sinon
j'essaye un mètre en dessous; et ainsi de suite jusqu'à trouver une bonne
valeur. Du coup si une antenne est posée sur le toit d'un immeuble sa
hauteur de ne sera pas prise en compte.*

Pour info j'ai changé ce paramètre de "tolérance": il état à 2 mètre pour
Nice mais là je me suis permis de le mettre à 0.5 mètre pour Montpellier
car les données sont vraiment très précises.


> Est-il aussi envisageable d'extraire le nombre de niveau pour les
> bâtiments de taille modeste ? genre un bâtiment à toit plat qui fait
> entre 2m et 3m n'a qu'un niveau. entre 4m et 5m = 2 niveau.
> Ou est-ce que la précision rend cela trop limite ?
>

Oui je pourrai aussi rajouter le nombre d'étages sur tous les bâtiments (et
pas que sur les petits) mais j'y vois 2 raisons défavorables:
- ça serait forcément une approximation plus ou moins grosse (la hauteur
des étages pouvant fortement varier d'un bâtiment à un autre)
- il n'y aurait pas un gros intérêt sachant que le tag de hauteur est plus
précis (par ex. pour les rendus 3D, ce qui est mon objectif final, cela
n'apportait rien)


> Par curiosité, à quoi correspond les 14 read failure ?
>

Certainement des bâtiments qui ont été effacés *après* la création du dump
de la DB d'OSM (que j'ai récupéré sur geofabrik.de il y a environ un mois).

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

[OSM-talk-fr] Importation des hauteurs de bâtiments sur Montpellier

[Vincent Frison]

Hello,

Après Nice (et Paris) je projette d'importer la hauteur des bâtiments de la
commune de Montpellier en me basant sur un MNT (modèle numérique de
terrain) et MNS (modèle numérique de surface) disponibles directement en
ODbL sur le portail Open Data de Montpellier Mediterranée Métropole:
http://data.montpellier3m.fr.

J'ai créé la page Wiki standard pour les imports:
https://wiki.openstreetmap.org/wiki/Montpellier,_France/Buildings_Heights_Import

Tout comme pour Nice la précision est très bonne, de l'ordre du mètre. De
ce que j'ai pu tester je dirais que c'est encore meilleur que Nice. Si
certains sont intéressés pour tester je peux fournir des fichiers XML (un
ZIP de l'ensemble de la commune pèse 20 MB environ). Sinon je compte faire
l'import dans les prochains jours...

Pour info voici quelques statistiques de l'import (qui ne touche pas à la
DB d'OSM pour l'instant):

=== Loading statistics ===
Total of targeted elements (ie. which are inside filtering areas): 110180
=== Processing statistics ===
Total of matched elements (ie. which have at least one matching imports):
95914
Total of matching imports: 42547442
Average of matching imports by element: 443
Repartitions of elements by matching scores:
 - score between 0% and 10% : 50470 (45%) elements
 - score between 10% and 20% : 170 (0%) elements
 - score between 20% and 30% : 159 (0%) elements
 - score between 30% and 40% : 10111 (9%) elements
 - score between 40% and 50% : 9050 (8%) elements
 - score between 50% and 60% :  (6%) elements
 - score between 60% and 70% : 6522 (5%) elements
 - score between 70% and 80% : 5197 (4%) elements
 - score between 80% and 90% : 4653 (4%) elements
 - score between 90% and 100% : 17182 (15%) elements
Minimum matching score is: 0.3
Total of updatable elements: 59381
Specific stats of the plugin:
 - Out of range DTM values: 32777
 - Out of range DSM values: 0
Specific settings of the plugin:
 - Shrink radius is: 1
 - Minimum matching point is: 4
 - Computing distance is: 20
 - Tolerance delta is: 0.5
=== Closing OSM XML service ===
Total of writing successes: 59346
Total of writing failures: 0
=== Closing OSM API service ===
Total of read operations: success=59367 failure=14
Total of write operations: success=0 failure=0
Total of changeset operations: open=0 close=0
Job has been executed in 11029 seconds

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

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 <romain.me...@gmail.com> 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 <vincent.fri...@gmail.com> a
> écrit :
>
>> Le 6 octobre 2017 à 18:37, marc marc <marc_marc_...@hotmail.com> 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] Importation des hauteurs de bâtiments sur Nice

[Vincent Frison]

Le 6 octobre 2017 à 18:37, marc marc <marc_marc_...@hotmail.com> 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

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

[Vincent Frison]

Le 2 octobre 2017 à 23:25, marc marc  a écrit :

> Ceci dit, cela me semblerait utile de détecter l'anomalie au moment de
> l'import : si l'une des 2 valeurs manque ou est en dehors d'une certaine
> fourchette de valeur (idem pour la différence), considérer cela comme
> une erreur et ne pas modifier ce batiment automatiquement.
>

Oui bien sûr je ne me ferai plus avoir au prochain import ! ;)

Enfin si nouvel import il y a car 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).

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

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

[Vincent Frison]

Le 27 septembre 2017 à 23:25, Philippe Verdy  a écrit :

> Un problème entre Cantaron et Falicon, le MNT ne semble pas correct (plat
> là où il y a des montagnes) du coup, on a des tas de "tours":
>

Pour info j'ai corrigé cette zone, merci pour le report.

A priori c'était la seule zone qui posait problème...

J'ai fait la correction manuellement mais savez vous si avec l'Overpass API
j'aurais pu faire une petite requête remontant tous les bâtiments dont la
hauteur est supérieur à X mètres ? Le problème c'est que les tags ne sont
que des champs textes et j'ai pas l'impression qu'on puisse utiliser des
opérateurs genre inférieur ou supérieur sur les tags. Mais bon je connais
pas vraiment l'API...
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

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

[Vincent Frison]

Quand je parle de résolution de 5 mètres c'est la résolution horizontale
(on dit plutôt planaire je crois), mais la résolution verticale elle est
meilleure, je crois qu'ils (les gens du portail open data) m'avaient dis
que c'était inférieur à un mètre...

D'après le wiki le tag height pour les buildings est censé indiquer le
point le plus haut du bâtiment mais à l'exclusion des structures rajoutées
comme par ex. les mats ou antennes. Mon script est censé gérer ça, en tout
cas il gère plutôt bien par exemple les petits locales techniques qui sont
très fréquents sur les immeubles. Pour simplifier si la hauteur max est de
Z mètres je vérifie si au moins 30% de l'ensemble des points "matchant"
l'immeuble sont à moins de 2 mètres de Z. Si c'est le cas c'est bon sinon
j'essaye un mètre en dessous; et ainsi de suite jusqu'à trouver une bonne
valeur. Du coup si une antenne est posée sur le toit d'un immeuble sa
hauteur de ne sera pas prise en compte.


Le 28 septembre 2017 à 15:48, Philippe Verdy <verd...@wanadoo.fr> a écrit :

> Ca rassure un peu, quoique 5 mètres c'est encore beaucoup pour représenter
> les hauteurs de bâtiments, c'est +/- 2 étages quand même ! A ce prix là, on
> peut e demander si ce ne serait pas plus pertinent de baser le calcul sur
> le nombre d'étages renseignés (en gros 2,5m par étage pour les bâtiments
> résidentiels, 3 mètres pour les bâtiments commerciaux, 5 mètres pour les
> centres commerciaux et bâtiments industriels, les églises c'est encore
> autre chose!).
>
> D'autant plus que "height=*" sur un bâtiment n'indique pas quel point est
> mesuré: hauteur maximale habitable ou le faite de la toiture, ou le plus
> haut point sur une cage d'ascenseur posée en haut d'un toit plat, avec ou
> sans la hauteur d'un mât d'antennes qui peut également être posé au dessus
> du bâtiment comme un simple noeud avec sa propre hauteur supplémentaire.
>
> Le 28 septembre 2017 à 15:33, Vincent Frison <vincent.fri...@gmail.com> a
> écrit :
>
>> Je trouve ça pas si mal, en tout cas sur Nice les collines et les
>> Pré-Alpes niçoise sont assez bien rendues, regarde l'image que j'ai inséré
>> dans la page Wiki de mon import: https://wiki.openstree
>> tmap.org/wiki/Nice,_France/Buildings_Heights_Import
>>
>> Après c'est sur que ça n'a rien à avoir avec des MNT locaux qui ont des
>> bien meilleures résolutions. Par exemple pour mon import j'ai utilisé le
>> MNT du portail open data de Nice et là sa résolution est de 5 mètres.. le
>> rendu n'a évidement rien à voir !!
>>
>> PS: je viens de voir ton dernier message: le MNT utilisé par mon import
>> (résolution de 5 mètre) n'a rien à voir avec le MNT utilisé pour le rendu
>> F4map (résolution de 90 mètres) ! ;)
>>
>> Le 28 septembre 2017 à 15:23, Philippe Verdy <verd...@wanadoo.fr> a
>> écrit :
>>
>>> De plus cette option ne semble pas donner un relief très réaliste, il
>>> est beaucoup trop aplati. J'aurais plutôt vu une glissière entre 0% et 100%
>>> de relief ou au moins 3 options (0%, environ 30% ici, et 100%) pour des
>>> villes de montagne, et la visibilité correcte (exemple Grenoble, Gap)
>>> Le MNT ne semble pas non plus complet, on a des tas de régions sans
>>> aucun relief.
>>>
>>> Le 28 septembre 2017 à 15:18, Philippe Verdy <verd...@wanadoo.fr> a
>>> écrit :
>>>
>>>> il fallait la voir cette option, alors que la case "3D" tout en haut à
>>>> droite est évidente. Merci pour mentionner, l'interface graphique pourrait
>>>> être épurée pour les options, cela n'a rien à voir avec les recherches...
>>>>
>>>> Le 28 septembre 2017 à 15:11, Vincent Frison <vincent.fri...@gmail.com>
>>>> a écrit :
>>>>
>>>>> Si si il y a une option pour cela: à coté de la zone de recherche clic
>>>>> sur l'icone > options graphique > ground elevation !
>>>>>
>>>>> Dommage qu'elle ne soit pas activée par défaut...
>>>>>
>>>>> Le 28 septembre 2017 à 15:00, Philippe Verdy <verd...@wanadoo.fr> a
>>>>> écrit :
>>>>>
>>>>>> Dommage quand même que F4map ne dispose pas du MNT pour afficher
>>>>>> correctement le relief ! Il pose tous les bâtiments sur un terrain plat !
>>>>>>
>>>>>> Le 28 septembre 2017 à 09:33, Vincent Frison <
>>>>>> vincent.fri...@gmail.com> a écrit :
>>>>>>
>>>>>>> Oui on m'a déjà signalé hier soir qu'il y avait un souci sur cette
>>>>>>> zone: le bug vient du fait que le MNT n'avait pas de val

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

[Vincent Frison]

Je trouve ça pas si mal, en tout cas sur Nice les collines et les Pré-Alpes
niçoise sont assez bien rendues, regarde l'image que j'ai inséré dans la
page Wiki de mon import: https://wiki.openstreetmap.org/wiki/Nice,_
France/Buildings_Heights_Import

Après c'est sur que ça n'a rien à avoir avec des MNT locaux qui ont des
bien meilleures résolutions. Par exemple pour mon import j'ai utilisé le
MNT du portail open data de Nice et là sa résolution est de 5 mètres.. le
rendu n'a évidement rien à voir !!

PS: je viens de voir ton dernier message: le MNT utilisé par mon import
(résolution de 5 mètre) n'a rien à voir avec le MNT utilisé pour le rendu
F4map (résolution de 90 mètres) ! ;)

Le 28 septembre 2017 à 15:23, Philippe Verdy <verd...@wanadoo.fr> a écrit :

> De plus cette option ne semble pas donner un relief très réaliste, il est
> beaucoup trop aplati. J'aurais plutôt vu une glissière entre 0% et 100% de
> relief ou au moins 3 options (0%, environ 30% ici, et 100%) pour des villes
> de montagne, et la visibilité correcte (exemple Grenoble, Gap)
> Le MNT ne semble pas non plus complet, on a des tas de régions sans aucun
> relief.
>
> Le 28 septembre 2017 à 15:18, Philippe Verdy <verd...@wanadoo.fr> a écrit
> :
>
>> il fallait la voir cette option, alors que la case "3D" tout en haut à
>> droite est évidente. Merci pour mentionner, l'interface graphique pourrait
>> être épurée pour les options, cela n'a rien à voir avec les recherches...
>>
>> Le 28 septembre 2017 à 15:11, Vincent Frison <vincent.fri...@gmail.com>
>> a écrit :
>>
>>> Si si il y a une option pour cela: à coté de la zone de recherche clic
>>> sur l'icone > options graphique > ground elevation !
>>>
>>> Dommage qu'elle ne soit pas activée par défaut...
>>>
>>> Le 28 septembre 2017 à 15:00, Philippe Verdy <verd...@wanadoo.fr> a
>>> écrit :
>>>
>>>> Dommage quand même que F4map ne dispose pas du MNT pour afficher
>>>> correctement le relief ! Il pose tous les bâtiments sur un terrain plat !
>>>>
>>>> Le 28 septembre 2017 à 09:33, Vincent Frison <vincent.fri...@gmail.com>
>>>> a écrit :
>>>>
>>>>> Oui on m'a déjà signalé hier soir qu'il y avait un souci sur cette
>>>>> zone: le bug vient du fait que le MNT n'avait pas de valeurs à cet endroit
>>>>> alors que le MNS lui en avait. Du coup la hauteur du bâtiment est égale à
>>>>> son élévation. J'ai déjà commencé à corriger...
>>>>>
>>>>> Merci, Vincent.
>>>>>
>>>>> Le 27 septembre 2017 à 23:25, Philippe Verdy <verd...@wanadoo.fr> a
>>>>> écrit :
>>>>>
>>>>>> Un problème entre Cantaron et Falicon, le MNT ne semble pas correct
>>>>>> (plat là où il y a des montagnes) du coup, on a des tas de "tours":
>>>>>>
>>>>>> http://demo.f4map.com/#lat=43.7604708=7.3021714=16;
>>>>>> camera.theta=27.399
>>>>>>
>>>>>>
>>>>>> Le 27 septembre 2017 à 18:01, Vincent Frison <
>>>>>> vincent.fri...@gmail.com> a écrit :
>>>>>>
>>>>>>> Hello,
>>>>>>>
>>>>>>> L'import a été fait: 52310 bâtiments ont été mis à jour avec leur
>>>>>>> hauteur.
>>>>>>>
>>>>>>> Plus de détails sur cette page Wiki
>>>>>>> <https://wiki.openstreetmap.org/wiki/Nice,_France/Buildings_Heights_Import>
>>>>>>> .
>>>>>>>
>>>>>>> ++ Vincent.
>>>>>>>
>>>>>>> Le 18 septembre 2017 à 17:57, Vincent Frison <
>>>>>>> vincent.fri...@gmail.com> a écrit :
>>>>>>>
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>> Je projette d'importer dans OSM la hauteur des bâtiments de la
>>>>>>>> ville de Nice, un peu comme je l'avais fait il y a 2 ans pour Paris:
>>>>>>>> http://wiki.openstreetmap.org/wiki/Paris,_France/Buildings_H
>>>>>>>> eights_Import
>>>>>>>>
>>>>>>>> Ici les données viennent du MNT (modèle numérique de terrain) et
>>>>>>>> MNS (modèle numérique de surface) disponible sur le portail Open Data 
>>>>>>>> de la
>>>>>>>> métropole Nice Cô

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

[Vincent Frison]

Par contre c'est un MNT assez basique, à priori c'est celui de la NASA
(SRTM) qui est libre et avec une une résolution de ~30 mètres (1'' d'arc)
aux USA et ~90 mètres (3'' d'arc) sur le reste du globe.

Depuis peu la NASA a rendu publique une nouvelle version qui couvre
l'ensemble du globe avec une résolution de ~30 mètres mais je doute qu'elle
soit utilisée dans F4map.

Le 28 septembre 2017 à 15:18, Philippe Verdy <verd...@wanadoo.fr> a écrit :

> il fallait la voir cette option, alors que la case "3D" tout en haut à
> droite est évidente. Merci pour mentionner, l'interface graphique pourrait
> être épurée pour les options, cela n'a rien à voir avec les recherches...
>
> Le 28 septembre 2017 à 15:11, Vincent Frison <vincent.fri...@gmail.com> a
> écrit :
>
>> Si si il y a une option pour cela: à coté de la zone de recherche clic
>> sur l'icone > options graphique > ground elevation !
>>
>> Dommage qu'elle ne soit pas activée par défaut...
>>
>> Le 28 septembre 2017 à 15:00, Philippe Verdy <verd...@wanadoo.fr> a
>> écrit :
>>
>>> Dommage quand même que F4map ne dispose pas du MNT pour afficher
>>> correctement le relief ! Il pose tous les bâtiments sur un terrain plat !
>>>
>>> Le 28 septembre 2017 à 09:33, Vincent Frison <vincent.fri...@gmail.com>
>>> a écrit :
>>>
>>>> Oui on m'a déjà signalé hier soir qu'il y avait un souci sur cette
>>>> zone: le bug vient du fait que le MNT n'avait pas de valeurs à cet endroit
>>>> alors que le MNS lui en avait. Du coup la hauteur du bâtiment est égale à
>>>> son élévation. J'ai déjà commencé à corriger...
>>>>
>>>> Merci, Vincent.
>>>>
>>>> Le 27 septembre 2017 à 23:25, Philippe Verdy <verd...@wanadoo.fr> a
>>>> écrit :
>>>>
>>>>> Un problème entre Cantaron et Falicon, le MNT ne semble pas correct
>>>>> (plat là où il y a des montagnes) du coup, on a des tas de "tours":
>>>>>
>>>>> http://demo.f4map.com/#lat=43.7604708=7.3021714=16;
>>>>> camera.theta=27.399
>>>>>
>>>>>
>>>>> Le 27 septembre 2017 à 18:01, Vincent Frison <vincent.fri...@gmail.com
>>>>> > a écrit :
>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> L'import a été fait: 52310 bâtiments ont été mis à jour avec leur
>>>>>> hauteur.
>>>>>>
>>>>>> Plus de détails sur cette page Wiki
>>>>>> <https://wiki.openstreetmap.org/wiki/Nice,_France/Buildings_Heights_Import>
>>>>>> .
>>>>>>
>>>>>> ++ Vincent.
>>>>>>
>>>>>> Le 18 septembre 2017 à 17:57, Vincent Frison <
>>>>>> vincent.fri...@gmail.com> a écrit :
>>>>>>
>>>>>>> Hello,
>>>>>>>
>>>>>>> Je projette d'importer dans OSM la hauteur des bâtiments de la ville
>>>>>>> de Nice, un peu comme je l'avais fait il y a 2 ans pour Paris:
>>>>>>> http://wiki.openstreetmap.org/wiki/Paris,_France/Buildings_H
>>>>>>> eights_Import
>>>>>>>
>>>>>>> Ici les données viennent du MNT (modèle numérique de terrain) et MNS
>>>>>>> (modèle numérique de surface) disponible sur le portail Open Data de la
>>>>>>> métropole Nice Côte d'Azur: http://opendata.niceco
>>>>>>> tedazur.org/data/dataset/modele-numerique-de-terrain-de-nice
>>>>>>> -cote-d-azur
>>>>>>>
>>>>>>> En fait j'ai déjà lancé un sujet sur le forum:
>>>>>>> http://forum.openstreetmap.fr/viewtopic.php?f=5=6373
>>>>>>>
>>>>>>> Mais comme je n'ai pas trop eu de retour je poste ici car il y a
>>>>>>> visiblement bien plus de trafic (dommage c'est sympa un forum).
>>>>>>>
>>>>>>> De ce que j'ai pu voir mes hauteurs calculées sont suffisamment
>>>>>>> précises mais je ne suis pas contre un petit retour avant de faire 
>>>>>>> l'import
>>>>>>> (2 fichiers d'exemple sont attachés dans mon dernier message du forum).
>>>>>>> Sinon je compte je faire l'import dès que j'aurai un peu de temps...
>>>>>>>
>>>>>>> Merci, Vincent.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> ___
>>>>>> 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] Importation des hauteurs de bâtiments sur Nice

[Vincent Frison]

Si si il y a une option pour cela: à coté de la zone de recherche clic sur
l'icone > options graphique > ground elevation !

Dommage qu'elle ne soit pas activée par défaut...

Le 28 septembre 2017 à 15:00, Philippe Verdy <verd...@wanadoo.fr> a écrit :

> Dommage quand même que F4map ne dispose pas du MNT pour afficher
> correctement le relief ! Il pose tous les bâtiments sur un terrain plat !
>
> Le 28 septembre 2017 à 09:33, Vincent Frison <vincent.fri...@gmail.com> a
> écrit :
>
>> Oui on m'a déjà signalé hier soir qu'il y avait un souci sur cette zone:
>> le bug vient du fait que le MNT n'avait pas de valeurs à cet endroit alors
>> que le MNS lui en avait. Du coup la hauteur du bâtiment est égale à son
>> élévation. J'ai déjà commencé à corriger...
>>
>> Merci, Vincent.
>>
>> Le 27 septembre 2017 à 23:25, Philippe Verdy <verd...@wanadoo.fr> a
>> écrit :
>>
>>> Un problème entre Cantaron et Falicon, le MNT ne semble pas correct
>>> (plat là où il y a des montagnes) du coup, on a des tas de "tours":
>>>
>>> http://demo.f4map.com/#lat=43.7604708=7.3021714=16;
>>> camera.theta=27.399
>>>
>>>
>>> Le 27 septembre 2017 à 18:01, Vincent Frison <vincent.fri...@gmail.com>
>>> a écrit :
>>>
>>>> Hello,
>>>>
>>>> L'import a été fait: 52310 bâtiments ont été mis à jour avec leur
>>>> hauteur.
>>>>
>>>> Plus de détails sur cette page Wiki
>>>> <https://wiki.openstreetmap.org/wiki/Nice,_France/Buildings_Heights_Import>
>>>> .
>>>>
>>>> ++ Vincent.
>>>>
>>>> Le 18 septembre 2017 à 17:57, Vincent Frison <vincent.fri...@gmail.com>
>>>> a écrit :
>>>>
>>>>> Hello,
>>>>>
>>>>> Je projette d'importer dans OSM la hauteur des bâtiments de la ville
>>>>> de Nice, un peu comme je l'avais fait il y a 2 ans pour Paris:
>>>>> http://wiki.openstreetmap.org/wiki/Paris,_France/Buildings_H
>>>>> eights_Import
>>>>>
>>>>> Ici les données viennent du MNT (modèle numérique de terrain) et MNS
>>>>> (modèle numérique de surface) disponible sur le portail Open Data de la
>>>>> métropole Nice Côte d'Azur: http://opendata.niceco
>>>>> tedazur.org/data/dataset/modele-numerique-de-terrain-de-nice
>>>>> -cote-d-azur
>>>>>
>>>>> En fait j'ai déjà lancé un sujet sur le forum: http://forum.openstreet
>>>>> map.fr/viewtopic.php?f=5=6373
>>>>>
>>>>> Mais comme je n'ai pas trop eu de retour je poste ici car il y a
>>>>> visiblement bien plus de trafic (dommage c'est sympa un forum).
>>>>>
>>>>> De ce que j'ai pu voir mes hauteurs calculées sont suffisamment
>>>>> précises mais je ne suis pas contre un petit retour avant de faire 
>>>>> l'import
>>>>> (2 fichiers d'exemple sont attachés dans mon dernier message du forum).
>>>>> Sinon je compte je faire l'import dès que j'aurai un peu de temps...
>>>>>
>>>>> Merci, Vincent.
>>>>>
>>>>>
>>>>>
>>>>
>>>> ___
>>>> 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] Importation des hauteurs de bâtiments sur Nice

[Vincent Frison]

Oui on m'a déjà signalé hier soir qu'il y avait un souci sur cette zone: le
bug vient du fait que le MNT n'avait pas de valeurs à cet endroit alors que
le MNS lui en avait. Du coup la hauteur du bâtiment est égale à son
élévation. J'ai déjà commencé à corriger...

Merci, Vincent.

Le 27 septembre 2017 à 23:25, Philippe Verdy <verd...@wanadoo.fr> a écrit :

> Un problème entre Cantaron et Falicon, le MNT ne semble pas correct (plat
> là où il y a des montagnes) du coup, on a des tas de "tours":
>
> http://demo.f4map.com/#lat=43.7604708=7.3021714=16;
> camera.theta=27.399
>
>
> Le 27 septembre 2017 à 18:01, Vincent Frison <vincent.fri...@gmail.com> a
> écrit :
>
>> Hello,
>>
>> L'import a été fait: 52310 bâtiments ont été mis à jour avec leur hauteur.
>>
>> Plus de détails sur cette page Wiki
>> <https://wiki.openstreetmap.org/wiki/Nice,_France/Buildings_Heights_Import>
>> .
>>
>> ++ Vincent.
>>
>> Le 18 septembre 2017 à 17:57, Vincent Frison <vincent.fri...@gmail.com>
>> a écrit :
>>
>>> Hello,
>>>
>>> Je projette d'importer dans OSM la hauteur des bâtiments de la ville de
>>> Nice, un peu comme je l'avais fait il y a 2 ans pour Paris:
>>> http://wiki.openstreetmap.org/wiki/Paris,_France/Buildings_H
>>> eights_Import
>>>
>>> Ici les données viennent du MNT (modèle numérique de terrain) et MNS
>>> (modèle numérique de surface) disponible sur le portail Open Data de la
>>> métropole Nice Côte d'Azur: http://opendata.niceco
>>> tedazur.org/data/dataset/modele-numerique-de-terrain-de-nice-cote-d-azur
>>>
>>> En fait j'ai déjà lancé un sujet sur le forum: http://forum.openstreet
>>> map.fr/viewtopic.php?f=5=6373
>>>
>>> Mais comme je n'ai pas trop eu de retour je poste ici car il y a
>>> visiblement bien plus de trafic (dommage c'est sympa un forum).
>>>
>>> De ce que j'ai pu voir mes hauteurs calculées sont suffisamment précises
>>> mais je ne suis pas contre un petit retour avant de faire l'import (2
>>> fichiers d'exemple sont attachés dans mon dernier message du forum). Sinon
>>> je compte je faire l'import dès que j'aurai un peu de temps...
>>>
>>> Merci, Vincent.
>>>
>>>
>>>
>>
>> ___
>> 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] Importation des hauteurs de bâtiments sur Nice

[Vincent Frison]

Hello,

L'import a été fait: 52310 bâtiments ont été mis à jour avec leur hauteur.

Plus de détails sur cette page Wiki
<https://wiki.openstreetmap.org/wiki/Nice,_France/Buildings_Heights_Import>.

++ Vincent.

Le 18 septembre 2017 à 17:57, Vincent Frison <vincent.fri...@gmail.com> a
écrit :

> Hello,
>
> Je projette d'importer dans OSM la hauteur des bâtiments de la ville de
> Nice, un peu comme je l'avais fait il y a 2 ans pour Paris:
> http://wiki.openstreetmap.org/wiki/Paris,_France/Buildings_Heights_Import
>
> Ici les données viennent du MNT (modèle numérique de terrain) et MNS
> (modèle numérique de surface) disponible sur le portail Open Data de la
> métropole Nice Côte d'Azur: http://opendata.nicecotedazur.org/data/
> dataset/modele-numerique-de-terrain-de-nice-cote-d-azur
>
> En fait j'ai déjà lancé un sujet sur le forum: http://forum.
> openstreetmap.fr/viewtopic.php?f=5=6373
>
> Mais comme je n'ai pas trop eu de retour je poste ici car il y a
> visiblement bien plus de trafic (dommage c'est sympa un forum).
>
> De ce que j'ai pu voir mes hauteurs calculées sont suffisamment précises
> mais je ne suis pas contre un petit retour avant de faire l'import (2
> fichiers d'exemple sont attachés dans mon dernier message du forum). Sinon
> je compte je faire l'import dès que j'aurai un peu de temps...
>
> Merci, Vincent.
>
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Contribution arbres remarquables du Bas-Rhin

[Vincent Frison]

Le 26 septembre 2017 à 12:09, Jean-Marc Liotier  a écrit :

> On Tue, 26 Sep 2017 10:44:10 +0200 (CEST)
> Vincent de Château-Thierry  wrote:
> >
> > > De: "PIERRE Sylvain" 
> > >
> > > Cet inventaire comporte un volet géographique visible ici :
> > > http://sigweb.bas-rhin.fr/arbrem/ , plus de 250 arbres étant
> > > recensés à ce jour. Notre collectivité souhaiterai pouvoir « pousser
> > > » ces arbres dans OSM.
> >
> > Compte tenu du volume de données, relativement modeste, il n'y a
> > peut-être pas lieu de trop phosphorer sur un "import" [..]
>
> Certes, mais... Il y a cinq ans, mon ambition était d'utiliser le cas
> des arbres remarquables, peu nombreux, pour rôder le processus de
> synchronisation avant de l'appliquer aux arbres d'alignements et autres
> arbres des Hauts-de-Seine considérablement plus nombreux - beaucoup trop
> pour une gestion manuelle.
>

Hello,

Il y a 2 ans j'avais fait un script pour importer les arbres de la ville de
la Nice (environ 30 000 arbres). Si vous botte je pourrais l'adapter avec
plaisir pour d'autres imports, il est prévu pour...

D'ailleurs c'est marrant car à l'époque un certain Pierre m'avait contacté
pour savoir s'il pouvait pas utiliser mon script pour importer les arbres
des Hauts-de-Seine justement ! Mais de ce qu'il me disait il avait un gros
doute sur la précision des positions des arbres et en fait on avait pas
creusé plus que cela...

La valeur ajoutée est bien plus grande s'il y a plus que la simple
localisation des arbres, ce qui n'était malheureusement pas le cas pour
Nice. Le top c'est d'avoir le type / genre de l'arbre ce qui est
certainement le cas pour les arbres du Bas-Rhin et des Hauts-de-Seine (au
vu de ta page wiki de Jean-Marc).

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

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

[Vincent Frison]

Hello,

Je projette d'importer dans OSM la hauteur des bâtiments de la ville de
Nice, un peu comme je l'avais fait il y a 2 ans pour Paris:
http://wiki.openstreetmap.org/wiki/Paris,_France/Buildings_Heights_Import

Ici les données viennent du MNT (modèle numérique de terrain) et MNS
(modèle numérique de surface) disponible sur le portail Open Data de la
métropole Nice Côte d'Azur:
http://opendata.nicecotedazur.org/data/dataset/modele-numerique-de-terrain-de-nice-cote-d-azur

En fait j'ai déjà lancé un sujet sur le forum:
http://forum.openstreetmap.fr/viewtopic.php?f=5=6373

Mais comme je n'ai pas trop eu de retour je poste ici car il y a
visiblement bien plus de trafic (dommage c'est sympa un forum).

De ce que j'ai pu voir mes hauteurs calculées sont suffisamment précises
mais je ne suis pas contre un petit retour avant de faire l'import (2
fichiers d'exemple sont attachés dans mon dernier message du forum). Sinon
je compte je faire l'import dès que j'aurai un peu de temps...

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

Re: [OSM-talk-fr] Suppression d'éléments dupliqués

[Vincent Frison]

Super, merci Marc !

Je savais pas qu'on pouvait exporter directement depuis Turbo Overpass vers
JOSM, c'est bien pratique...

Et effectivement pas besoin de récupérer uniquement les arbres dupliqués
(la requête fait énormément ramer Overpass), autant récupérer TOUS les
arbres (dupliqués ou non) puis laisser JOSM faire le ménage.

PS: pour les arbres qui ont le tag type=conifer (ou palm) ce sont des
arbres existants qui avaient déjà ce tag obsolète, je vais essayer d'en
corriger à la main..


Le 8 août 2015 08:25, Marc SIBERT m...@sibert.fr a écrit :

 Désolé, c'est tellement facile que je n'ai pas pu résister. C'est corrigé.
 Une requete Turbo Overpass en utilisant le wisard natural=tree in Nice
 puis un export sous josm. Passage du validator, réparation (automatique)
 des erreurs (1000 effectivement) et upload.

 Note : josm me dit que type=conifer est obsolète ; je dis ça, je dis
 rien...

 A+

 Marc Sibert
 m...@sibert.fr

 Le 7 août 2015 23:38, sebastien.bugzi...@gmail.com 
 sebastien.bugzi...@gmail.com a écrit :

 Salut

 Il me semble que josm permet de corriger les noeuds confondus. Il suffit
 d'importer la zone, puis de faire une validation. Il devrait détecter les
 noeuds dupliqués. Et tu as juste à cliquer sur réparer pour qu'il corrige
 le problème. Puis renvoyer évidemment.

 Sébastien


 On 07/08/2015 23:06, Vincent Frison wrote:

 Hello,

 J'ai fait l'import des arbres municipaux de Nice: l'import pour modifier
 les éléments existants s'est bien passé (835 éléments) mais manque de bol
 il y a eu un problème (réseau à priori) pour l'import des nouveaux arbres
 (29 411 éléments). JOSM a arrêté l'upload en plein milieu du transfert avec
 un message ressemblant à premature end of file :(

 En tentant d'uploader à nouveau JOSM a pu finir l'upload, visiblement
 sans souci.. sauf qu'en regardant de plus près le changeset (
 https://www.openstreetmap.org/changeset/33108671) on peut voir qu'il y a
 eu 30 411 éléments, soit 1000 de plus que prévu ! Or j'avais justement
 configuré JOSM pour faire des blocs de 1000 requêtes, il est donc à peu
 près clair que suite à un problème réseau JOSM a cru qu'un bloc n'avait pas
 été uploadé alors qu'en fait si.. et du coup il a uploadé à nouveau ce bloc
 en créant 1000 doublons.

 J'ai pas mal galéré avec Overpass pour trouver ces élément dupliqués,
 j'en ai retrouvé environ 200 pour l'instant. En fait j'ai trouvé sur le net
 une requête qui marche bien mais elle prend un temps fou, impossible de la
 faire sur l'ensemble de Nice (à priori c'est un bug d'Overpass). Sinon il y
 a aussi le site keepright.at qui permet d'afficher les doublons mais
 leur données ne sont pas encore à jour. Peut-être qu'Osmose pourrait
 m'aider ?

 Bon ceci dit même avec la liste exhaustive des éléments dupliqués il
 resterait quand même le boulot d'effacement à faire. Je pourrais faire un
 petit script pour cela mais peut-etre que dans mon cas la solution la plus
 efficace et surtout la plus simple serait de simplement faire un revert
 pour pouvoir ensuite refaire l'import proprement (en partant du principe
 que je n'aurais plus de problème réseau) ?

 Après je suis pas sûr de bien comprendre ce que fait un revert, dans mon
 cas les nouveaux arbres créés seront supprimés, mais quelque part ils
 existeront toujours dans l'historique ? L'idéal serait de vraiment annuler
 comme si rien ne s'était passé mais je sais pas si c'est possible...

 Merci pour votre aide, Vincent.





 ___
 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


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

Re: [OSM-talk-fr] Suppression d'éléments dupliqués

[Vincent Frison]

Ah ils viennent justement de mettre à jour, en tout cas là c'est basé sur
les donnée d'hier ! Et je peux effectivement voir certain arbres dupliqués
(multiple nodes on the same spot), et qu'ils sont malheureusement
disséminés sur plusieurs zones différentes...

Du coup je pense que dans mon cas la solution la plus simple (et efficace)
serait de faire purement et simplement un revert, puis de relancer l'upload
proprement (je n'imagine même pas avoir un nouveau problème réseau lors de
l'upload, on ne peut pas tromper 1000 fois la même personne...).

Quelqu'un pourrait il faire le revert sur le changeset 33108671 svp ? Mais
peut-être que je peux le faire moi même comme un grand ?

Merci, Vincent.


Le 7 août 2015 23:16, David Crochet david.croc...@free.fr a écrit :

 Bonjour

 Le 07/08/2015 23:06, Vincent Frison a écrit :

 Sinon il y a aussi le site keepright.at http://keepright.at qui permet
 d'afficher les doublons mais leur données ne sont pas encore à jour.


 Tous les 15 jours a priori. Mais sinon on peut laissé l'outil faire la
 recherche, surtout que les doublon vont être des points superposés

 Cordialement

 --
 David Crochet

 ___
 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

[OSM-talk-fr] Suppression d'éléments dupliqués

[Vincent Frison]

Hello,

J'ai fait l'import des arbres municipaux de Nice: l'import pour modifier
les éléments existants s'est bien passé (835 éléments) mais manque de bol
il y a eu un problème (réseau à priori) pour l'import des nouveaux arbres
(29 411 éléments). JOSM a arrêté l'upload en plein milieu du transfert avec
un message ressemblant à premature end of file :(

En tentant d'uploader à nouveau JOSM a pu finir l'upload, visiblement sans
souci.. sauf qu'en regardant de plus près le changeset (
https://www.openstreetmap.org/changeset/33108671) on peut voir qu'il y a eu
30 411 éléments, soit 1000 de plus que prévu ! Or j'avais justement
configuré JOSM pour faire des blocs de 1000 requêtes, il est donc à peu
près clair que suite à un problème réseau JOSM a cru qu'un bloc n'avait pas
été uploadé alors qu'en fait si.. et du coup il a uploadé à nouveau ce bloc
en créant 1000 doublons.

J'ai pas mal galéré avec Overpass pour trouver ces élément dupliqués, j'en
ai retrouvé environ 200 pour l'instant. En fait j'ai trouvé sur le net une
requête qui marche bien mais elle prend un temps fou, impossible de la
faire sur l'ensemble de Nice (à priori c'est un bug d'Overpass). Sinon il y
a aussi le site keepright.at qui permet d'afficher les doublons mais leur
données ne sont pas encore à jour. Peut-être qu'Osmose pourrait m'aider ?

Bon ceci dit même avec la liste exhaustive des éléments dupliqués il
resterait quand même le boulot d'effacement à faire. Je pourrais faire un
petit script pour cela mais peut-etre que dans mon cas la solution la plus
efficace et surtout la plus simple serait de simplement faire un revert
pour pouvoir ensuite refaire l'import proprement (en partant du principe
que je n'aurais plus de problème réseau) ?

Après je suis pas sûr de bien comprendre ce que fait un revert, dans mon
cas les nouveaux arbres créés seront supprimés, mais quelque part ils
existeront toujours dans l'historique ? L'idéal serait de vraiment annuler
comme si rien ne s'était passé mais je sais pas si c'est possible...

Merci pour votre aide, Vincent.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Importation des arbres municipaux sur Nice

[Vincent Frison]

Effectivement les positions des arbres sont plutôt bonnes et d'ailleurs mon
import (que je n'ai pas encore appliqué !!) ne va les déplacer que sur
quelques centimètres (1 mètre max).

Ceci dit j'ai pas bien compris ce qui vous gêne actuellement car pour moi
les arbres tout comme les routes (les 2 axes du boulevard + la voie de
service au milieu) sont déjà assez bien placés...

Le 3 août 2015 15:47, Jérôme Seigneuret jseigneuret-...@yahoo.fr a écrit :

 J'allais dire là même chose.
 La données à plutôt l'air de bonne qualité. Plus que celle du réseau. Je
 vais retoucher le réseau routier en conséquence.

 Le 3 août 2015 11:49, Vladimir Vyskocil vladimir.vysko...@gmail.com a
 écrit :

 Bon à y regarder de plus prêt on dirait que ce sont les routes qui ont
 été malmenées dans ce coin et que les arbres sont plutôt aux bons
 emplacements !

 On 03 Aug 2015, at 11:45, Vladimir Vyskocil vladimir.vysko...@gmail.com
 wrote:

 C’est dangereux de rouler sur le Boulevard René Cassin par exemple ;-)


 http://www.openstreetmap.org/?mlat=43.66954mlon=7.21884#map=19/43.66954/7.21884

 Je suppose que ce sont des arbres d’un import précédent ?

 Vlad.

 On 01 Aug 2015, at 19:02, Vincent Frison vincent.fri...@gmail.com
 wrote:

 Alors j'ai rajouté la petite vérification pour savoir si l'arbre importé
 est à l'intérieur d'un bâtiment ou pas. Cela permet donc d'avoir un fichier
 à part avec les arbres posant problème.

 Voici les dernières stats:
 Total of makable imports: 30246
 Total of non makable imports: 275
 Matching area radius: 5.0
 Total of created trees: 29430
 Total of updated trees: 816
 Total of created or updated trees: 30246
 Total of multi matching trees: 306

 Il y a donc 275 arbres posant problème qu'on peut en gros diviser en 2
 catégories:
 - les arbres qui sont collés à un bâtiment mais qui se retrouvent à
 l'intérieur comme c'est le cas pour la basilique Notre Dame (difficile de
 dire qui a raison ou tort). Il y en a environ une bonne quarantaine comme
 ça...
 - les arbres qui sont à l'intérieur d'un bâtiment parce que celui ci est
 mal fait dans OSM (ex: bibliothèque bien plus grande que la réalité et qui
 englobe son parc, ou bâtiment d'école simplifié ne laisse plus de place à
 sa cour interne, etc.).

 C'est du coup un bon test pour voir des corrections à faire (une sorte de
 mini osmose ;p), je conserve donc ce fichier pour faire certaines
 corrections plus tard et pouvoir ensuite importer certains arbres
 normalement, merci Jérôme pour l'idée.

 En attendant je compte bien uploader les 30 246 autres arbres qui sont
 hors bâtiments.. sauf si évidemment vous me dites que cela entraînera
 forcement un revert et mon bannissement du forum sur les 3 prochaines
 générations..




 Le 31 juillet 2015 00:00, Vincent Frison vincent.fri...@gmail.com a
 écrit :

 Le 30 juillet 2015 23:24, Jérôme Seigneuret jseigneuret-...@yahoo.fr
 a écrit :

 Oui pour empêcher l'import mais on n'est pas à 15 cm sur le placement
 des bâtiments aussi donc qui a raison?

 Il faudrait genre un pré-filtre. Si tu fais ça sous JOSM il doit bien
 être possible de faire comme sous n'importe quel SIG un tag intermédiaire
 note=FIXME et tu n'intègres que ceux sans alerte. Les autres c'est à mettre
 dans un fichier *.osm et à retoucher au fur et à mesure pour faire
 l'intégration en semi-auto par exemple par type d'alerte.

 C'est plus simple et au moins il n'y a plus d’ambiguïté.


 Le plus simple c'est encore d'ignorer purement et simplement tous les
 éléments posant problème.

 Mais je trouve que c'est une bonne idée de garder ces éléments dans un
 fichier à part.. histoire de ne rien lâcher ! ;p

 Je ferai ça ce WE..


 ___
 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


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

Re: [OSM-talk-fr] Importation des arbres municipaux sur Nice

[Vincent Frison]

Alors j'ai rajouté la petite vérification pour savoir si l'arbre importé
est à l'intérieur d'un bâtiment ou pas. Cela permet donc d'avoir un fichier
à part avec les arbres posant problème.

Voici les dernières stats:
Total of makable imports: 30246
Total of non makable imports: 275
Matching area radius: 5.0
Total of created trees: 29430
Total of updated trees: 816
Total of created or updated trees: 30246
Total of multi matching trees: 306

Il y a donc 275 arbres posant problème qu'on peut en gros diviser en 2
catégories:
- les arbres qui sont collés à un bâtiment mais qui se retrouvent à
l'intérieur comme c'est le cas pour la basilique Notre Dame (difficile de
dire qui a raison ou tort). Il y en a environ une bonne quarantaine comme
ça...
- les arbres qui sont à l'intérieur d'un bâtiment parce que celui ci est
mal fait dans OSM (ex: bibliothèque bien plus grande que la réalité et qui
englobe son parc, ou bâtiment d'école simplifié ne laisse plus de place à
sa cour interne, etc.).

C'est du coup un bon test pour voir des corrections à faire (une sorte de
mini osmose ;p), je conserve donc ce fichier pour faire certaines
corrections plus tard et pouvoir ensuite importer certains arbres
normalement, merci Jérôme pour l'idée.

En attendant je compte bien uploader les 30 246 autres arbres qui sont hors
bâtiments.. sauf si évidemment vous me dites que cela entraînera forcement
un revert et mon bannissement du forum sur les 3 prochaines générations..




Le 31 juillet 2015 00:00, Vincent Frison vincent.fri...@gmail.com a écrit
:

 Le 30 juillet 2015 23:24, Jérôme Seigneuret jseigneuret-...@yahoo.fr a
 écrit :

 Oui pour empêcher l'import mais on n'est pas à 15 cm sur le placement des
 bâtiments aussi donc qui a raison?

 Il faudrait genre un pré-filtre. Si tu fais ça sous JOSM il doit bien
 être possible de faire comme sous n'importe quel SIG un tag intermédiaire
 note=FIXME et tu n'intègres que ceux sans alerte. Les autres c'est à mettre
 dans un fichier *.osm et à retoucher au fur et à mesure pour faire
 l'intégration en semi-auto par exemple par type d'alerte.

 C'est plus simple et au moins il n'y a plus d’ambiguïté.


 Le plus simple c'est encore d'ignorer purement et simplement tous les
 éléments posant problème.

 Mais je trouve que c'est une bonne idée de garder ces éléments dans un
 fichier à part.. histoire de ne rien lâcher ! ;p

 Je ferai ça ce WE..


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

Re: [OSM-talk-fr] SeFaireConnaitre :(

[Vincent Frison]

Le 30 juillet 2015 23:02, osm.sanspourr...@spamgourmet.com a écrit :

 Vincent, tu vois ce genre d'import sans communauté (plus exactement en
 comptant sur la communauté pour corriger), ça fait mal, mais toi ce n'est
 pas dans un but malsain, ce n'est pas parasiter bien au contraire.


Euh oui merci de ne pas m'associer à ce genre de personnage ;)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Importation des arbres municipaux sur Nice

[Vincent Frison]

Le 30 juillet 2015 09:29, Christian Quest cqu...@openstreetmap.fr a écrit
:

 On a un arbre dans la basilique Notre-Dame, des arbres à moins d'1m de
 certaines highway (non pedestrian). Des problèmes de calage ? De quel
 côté OSM ou opendata ?

Place Masséna, il y a des différences avec Bing (qui date de 2012)... de
 nouveaux arbres y ont été plantés ou alors ils sont si petit qu'on ne
 les distingue pas sur l'ortho (ni sur Google Street View en septembre
 2014) ?

J'ai donc un doute sur la qualité des données en opendata. Sont-elles
 bien à jour ?

 Les algo de rapprochement semblent corrects, mais ne peuvent pas faire
 de miracle.


C'est pas toujours évident à dire qui est en cause, par exemple pour la
basilique cet élément correspond bien à un palmier réel collé à l'extérieur
de l'église et ça se joue à quelques dizaines de centimètres. Mais ce que
je vais faire c'est rajouter un filtre pour empêcher l'import d'un arbre
localisé à l'intérieur d'élément ayant le tag building (ou autre chose?),
c'est un truc j'aurais du penser dès le début.

Il faut savoir que beaucoup d'axes dans Nice ont été refait ces dernières
années et le mobilier urbain aussi forcément. Masséna a été en
travaux jusqu'à récemment mais à priori les positions sont bonnes de ce que
je vois, en tout cas d'après eux elles sont bonnes et à jour (je les ai
questionné sur cette zone). StreetView fait un joli mix avec des prises de
multiples époques mais justement je trouve que celles de 2014 correspondent
pas mal (en sachant qu'ils ont encore rajouté des arbres depuis). Mais j'y
irai faire un tour pour voir ça de plus près. Ceci dit ce genre de zone
n'est clairement pas l'endroit le mieux pour l'import (il y a une grosse
densité de végétaux et en plus souvent de petite taille) et sur ces zones
là je pourrais effectivement supprimer les arbres importés et utiliser du
tag landuse à la place, à voir...

Globalement je trouve quand même le positionnement vraiment bon, sur des
gros axes ensoleillés on peut voir que tout match parfaitement sous Bing.

J'ai aussi remarqué une belle bizarrerie avec quelques arbres qui étaient
sur l'emprunte du futur stade Allianz Arena, alors en travaux sous Bing
mais qui a été fini depuis. Je leur ai notifié et ils m'ont répondu que les
matricules de ces arbres correspondaient effectivement à des anciens arbres
mais qu'ils ne les réaffecterait que lorsque les travaux pour le tram
seront finis, faudra donc que je les supprime à la main..

Sinon ils n'ont apparemment pas d'informations sur la hauteur des arbres
(car trop variable d'après eux, ce qui n'est pas faux mais bon..) et je les
ai relancé encore une fois sur la possibilité d'avoir le type, c'est juste
pas possible qu'ils ne l'aient pas !
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Importation des arbres municipaux sur Nice

[Vincent Frison]

Le 30 juillet 2015 23:24, Jérôme Seigneuret jseigneuret-...@yahoo.fr a
écrit :

 Oui pour empêcher l'import mais on n'est pas à 15 cm sur le placement des
 bâtiments aussi donc qui a raison?

 Il faudrait genre un pré-filtre. Si tu fais ça sous JOSM il doit bien être
 possible de faire comme sous n'importe quel SIG un tag intermédiaire
 note=FIXME et tu n'intègres que ceux sans alerte. Les autres c'est à mettre
 dans un fichier *.osm et à retoucher au fur et à mesure pour faire
 l'intégration en semi-auto par exemple par type d'alerte.

 C'est plus simple et au moins il n'y a plus d’ambiguïté.


Le plus simple c'est encore d'ignorer purement et simplement tous les
éléments posant problème.

Mais je trouve que c'est une bonne idée de garder ces éléments dans un
fichier à part.. histoire de ne rien lâcher ! ;p

Je ferai ça ce WE..
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] aides à la consolidation de données

[Vincent Frison]

Bien vu Jérôme ! Par contre si cela ne vous dérange je préfère qu'on garde
la discussions sur les arbres de Nice dans son sujet dédié...

Sinon désolé Jean-Yvon mais je n'adhère toujours pas à ta théorie de
l'arbre synthétique: si une personne est assez motivé pour aller rajouter
le type ou la hauteur sur l'arbre qui est juste en face de chez lui, le
fait que l'arbre a été créé par VinceBot ou par Tartanfion ne va pas
changer grand chose (même si c'est un fouineur et qu'il se rend compte que
ça provient d'un import auto) !

C'est la même chose si tu veux rajouter un magasin ou la hauteur sur un
bâtiment existant, j'ai du mal à croire que les gens soient bloqués parce
que le bâtiment ait été importé du cadastre (où là c'est encore plus
explicite puisque visible directement dans le tag source).

Donc pour moi, tout le monde peut éditer n'importe quel élément et que
celui ci provienne d'un contribution manuelle ou auto n'a absolument aucune
importance..


Le 28 juillet 2015 00:50, Jérôme Seigneuret jseigneuret-...@yahoo.fr a
écrit :

 Sûrement, mais pas en OData.

 Le 28 juillet 2015 00:13, Yves Pratter yves.prat...@laposte.net a écrit
 :

  S'il peut voir avec une société d'horticulture (je ne sais s'il y a de
 telles assos sur Nice), peut-être qu'avec les données il va trouver des
 gens qui vont enrichir la donnée. Avant ou après import.

 Je suis étonné que les services municipaux ne disposent pas d'autres
 données.
 Sur Lyon, ils disposent, entre - autres, de l'espèce. Sur leur SIG ils
 colorent les arbres en fonction de cet attribut pour voir visuellement si
 un secteur est plus sensibles aux parasites...

 --
 Yves

 ___
 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] Importation des arbres municipaux sur Nice

[Vincent Frison]

J'ai reçu une réponse de la part du service, je rappelle que je leur avais
posé la question pour savoir s'il prévoyait à terme de rajouter d'autres
infos que la position comme le type ou la hauteur.

La réponse, qui tien en une ligne et qui est assez surprenante (je me
permet de la c/c ici puisque rien de privé ou sensible):
La base de données intègre de multiples critères qui servent à gérer le
patrimoine arboré de la ville de Nice. Ces critères ne sont pas partagés ou
disponibles sur les plateformes informatiques publiques et n’ont pas
vocation à l’être.

Donc il semblerait bien que ces infos existent dans leurs bases sauf qu'ils
n'ont pas prévu de les intégrer dans leur jeu de données ouvertes :(

Je leur ai demandé s'il y avait une raison particulière pour cela...
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Importation des arbres municipaux sur Nice

[Vincent Frison]

Bonjour Vlad,

Content de voir un local rejoindre la discussion :)

- quid de la maintenance a long terme car le sujet ne semble pas passionner
 beaucoup de monde


Ce sujet a déjà été évoqué, je m'occuperai de la maintenance et à priori
sur plus long terme que les arbres rajoutés manuellement (pour info une
grosse partie de ceux qui ont été déjà rajouté manuellement sur Nice n'ont
plus leur père car il a quitté la région).


 - le rendu OSM “standard” n’est pas bon a mon avis, c’est trop chargé, on
 dirait que la carte a chopé la varicelle ;-)

- je comprend l’intérêt que cela peut avoir pour certains domaine
 d’activité d’avoir ces données mais pour la grande majorité je ne vois pas…


Moi j'y vois un intérêt visuel indéniable mais que tu dois pouvoir dénier
puisque tu trouves que ça ressemble à de la varicelle ! ;p
Perso je ne vois pas du tout ce côté là, au contraire.. et surtout il me
tarde de voir le rendu avec F4map !

- cela dilue et cache l’information sur les arbres “remarquables” qui eux
 méritent apparaître sur le rendu généraliste


Il n'y a que sur la Prom' où je peux imaginer ce genre de problème car il y
a effectivement des arbres existants correspondants à des très grands
palmier qui sont à côté de petits arbres de moins de 3 mètres. Mais j'ai
justement prévu de refaire un travail manuel pour mettre un peu de tag
heigt sur cette zone..

- quand j’importe les données OSM pour la France entière dans mon logiciel
 utilisant libosmscout qui compile tout ça dans une base binaire de 4.5Go
 (avec les lignes de niveau à intervalle de 10m) je dois filtrer les arbres
 car sinon l’import explose à cause d’une trop forte concentration d’un même
 type de noeud (les arbres) dans certaines zones !


Oui bon là c'est pas trop de la faute de mon import ;p
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Importation des arbres municipaux sur Nice

[Vincent Frison]

Le 27 juillet 2015 22:46, Christian Quest cqu...@openstreetmap.fr a écrit
:

  Le 27/07/2015 01:01, osm.sanspourr...@spamgourmet.com a écrit :

 Mais c'est l'arbre qui cache la forêt : je vois que des rues de Nice n'ont
 pas de nom (http://www.openstreetmap.org/way/156776064). Il semble
 pourtant y avoir des habitants, il y a même des numéros sur les bâtiments (
 http://tile.openstreetmap.fr/~cquest/leaflet/bano.html#19/43.71235/7.27541).
 Alors un nom de rue, de résidence ?


 Non, pas de numéros sur les bâtiments dans OSM... ils seraient en vert sur
 le rendu BANO.
 Ce qui est en bleu c'est le cadastre (avec rapprochement OSM), en jaune
 c'est l'opendata et en gris la BAN.

 Oui des noms de rues manquent encore sur Nice... et bien qu'il n'y ait pas
 de priorité à mapper tel ou tel type d'info avant une autre, c'est quand
 même symptomatique d'une zone avec une communauté pas très active surtout
 par rapport à la densité de population.

 Si je veux aller à Nice, la carte me sert avant tout à trouver les rues.
 Les arbres, ça vient après, seulement après.

 PSS donne des infos pertinentes sur des lieux remarquables, comme
 http://structurae.net/.
 Relier ces données à OSM me semble bien plus intéressant, pertinent.

 La notion de valeur ajoutée me semble très importante.

 Bien sûr les arbres importés ne vont pas décourager une communauté locale,
 mais importer ces données sans se mettre en relation avec cette communauté
 ne va pas dans le bon sens pour la développer.


Je suis bien d'accord mais à vrai dire c'est un peu ce que je pensais faire
en créant ce thread au titre plutôt évocateur. Malheureusement pas beaucoup
de niçois se sont manifestés...

En tout cas j'ai essayé de contacter les 3 contributeurs qui avaient déjà
rajoutés des arbres sur Nice:
- un seul m'a répondu pour l'instant et il n'est plus sur la région (tiens
ça me rappelle mon exemple, qui va maintenant s'occuper des arbres qu'il a
créé ? :p)
- un autre ne m'a pas répondu mais au vu de ses contributions il n'est plus
sur la région non plus  !
- l'autre par contre est encore dans les parages, j'ai donc encore un peu
d'espoir de pas être tout à fait seul

Après c'est sûr que c'est pas les seuls (j'essayerai d'autres contributeurs
récemment actifs) mais ça montre qu'effectivement il n'y a pas une énorme
activité sur la région, ce qui est effectivement surprenant vu la densité
de population..

OSM est aussi un projet très social... il faut un petit peu de temps pour
 intégrer aussi cet aspect.

Il m'a fallu du temps pour prendre du recul avec la technique et pour
 comprendre cette dimension... je ne pense pas être le seul. Relire nos
 premières interventions sur talk-fr est assez instructif de ce point de vue
 !


Personnellement ça m'a semblé assez clair dès le début et c'est d'ailleurs
pour ça que je n'ai pas hésité dès le début à communiquer et demander de
l'aide sur mes imports..


 Il y a plein de dev à faire, mais surtout pour mettre à disposition des
 non-dev des outils de plus en plus pratiques, ergonomiques, rapides,
 efficaces pour viser le meilleur rapport temps passé/valeur ajoutée et
 utilisables par le public le plus large.


C'est sur que c'est primordiale, je trouve d'ailleurs que l'éditeur iD est
assez génial de ce point de vue là..

Bon en tout cas ça ne résout pas vraiment mon problème pour savoir si je
peux ou pas envoyer mon import sur le serveur.. en tant que chef tu ne
pourrais pas me donner un autorisation spéciale (si possible sans clause NC
;p) ?

En tout cas si certains sont intéressés ils peuvent voir le XML généré
ainsi que les logs par ici http://up.lbzh.fr/uploads/55b6aaf971201.zip (dispo
pendant 48h).
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Importation des arbres municipaux sur Nice

[Vincent Frison]

Le 27 juillet 2015 00:58, Vincent de Château-Thierry v...@laposte.net a
écrit :


 Le 27/07/2015 00:08, Vincent Frison a écrit :

  Je commence juste à me rendre compte (je suis un nouveau de 6 mois hein)
 à quel point les imports auto sont mal vues par ici. Je savais bien que
 ça pouvait être sensible (ils en parlent même sur la page import du
 wiki) mais pour être franc je ne m'attendais pas du tout à une telle
 levée de boucliers pour cet import d'arbres.. si peu risqué à mon sens !


 Ça n'est pas pour rien qu'on met un point d'honneur en France à parler
 d'intégration et non d'import. Intégration signifie que le contributeur
 (humain) a toujours le dernier mot avant d'envoyer les données au serveur,
 et que le travail de combinaison avec l'existant lui incombe, bien plus
 qu'à un robot-algo.


Mais en fait c'est un peu le cas puisque les contributions existantes sont
conservées et en plus ça passe par la case JOSM pour vérifier le contenu
avant l'import. Mon programme peut en effet se synchroniser avec OSM soit
directement en faisant des requêtes vers l'API soit en générant du XML pour
JOSM. Dans ce dernier cas là on est donc plus dans l'import
semi-automatique et que totalement automatique...

J'ai bien conscience que la problématique de la maintenance est
 évidemment primordiale mais personnellement je ne suis vraiment pas sûr
 qu'une donnée rentrée manuellement soit forcément plus viable, sur le
 long terme, qu'une entrée rentrée automatiquement, surtout pour ce type
 de donnée.Pour revenir par exemple au cas où je rentre manuellement un
 arbre de mon quartier puis je déménage, je risque fortement de ne plus
 jamais le mettre à jour. Alors que je pourrais continuer à rejouer tous
 les 6 mois et sans effort via mon script pour utiliser la dernière mise
 à jour de l'opendata de Nice indiquant le très peu probable abattage de
 l'arbre.


 Ce qui veut dire une confiance totale en la source Open Data. Ça a déjà
 été rappelé dans ce fil (et dans bien d'autres avant) : une source Open
 Data doit être croisée à autre chose et pas prise comme telle, seule. D'où
 souvent le verdict du terrain pour valider la qualité.


J'ai passé pas mal d'heures à vérifier ces données et franchement tout à
l'air bon même si je n'ai pas vérifié l'intégralité des 30 000 arbres
individuellement.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Importation des arbres municipaux sur Nice

[Vincent Frison]

Le 27 juillet 2015 01:01, osm.sanspourr...@spamgourmet.com a écrit :

  L'import se résume à peu de valeur ajoutée, ce n'est pas comparable à PSS.
 Ici tu veux ajouter un nœud par arbre (nouveau).
 Pas de taille, pas d'âge, pas d'espèce, etc...

 Donc suffisant pour la municipalité pour savoir quoi arroser. C'est le
 problème de l'usage.
 Ajouter une info globalement pauvre même si pertinente sur un point, c'est
 bien *s**'il* est probable que les gens la complètent.
 Si c'est une graine que tu peux faire germer c'est bien, si c'est un sapin
 de Noël synthétique, ça nuit aux données alentour !


Je comprends pas, pourquoi pas un arbre rajouté par mon import serait un
sapin synthétique nuisible comparé à un arbre rajouté manuellement ?

Actuellement la donnée ne concerne que la position, si on avait eu le type
et la hauteur ça aurait été génial mais c'est pas le cas. Mais à partir du
moment où ça correspond à la position d'un arbre réel c'est une info qui a
le droit d'être rentrée dans OSM au même titre que position d'un arbre
rentrée manuellement. Je rappelle que la majorité des arbres rentrés
manuellement n'ont justement que la position et rien d'autres.


 Si je veux aller à Nice, la carte me sert avant tout à trouver les rues.
 Les arbres, ça vient après, seulement après.


Je suis bien d'accord que c'est dommage qu'il manque des infos sur Nice
mais pour autant est ce une raison pour refuser l'ajout d'éléments moins
prioritaires ?
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Importation des arbres municipaux sur Nice

[Vincent Frison]

Alors pour répondre à la question de Jérôme sur la gestion des conflits:

Avant je ne considérais que l'arbre existant le plus proche de l'arbre
importé. Mais comme je disais dans un post précédent: la gestion des multi
matching trees (ie. les arbres existants qui sont dans le rayon de
plusieurs arbres importés) est très basique puisque je met à jour l'élément
avec les valeurs du 1er arbre importé tout simplement (pour les autres
éléments importés je créé donc un nouvel élément).

Comme tu l'as remarqué Jérôme il y a aucun tag taxon ou genus sur
l'ensemble des arbres existants de Nice, ce qui est une mauvaise chose dans
l'absolu... mais plutôt une bonne chose pour mon import ! :p

Ceci dit on était pas à l'abri de cas problématiques, imaginons 2 arbres
importés I1, I2 et 3 arbres existants E1, E2, E3 (et que le rayon est de
5m).
I12mE1
I13mE2
I21mE1
I24mE3
Avant si je tombais d'abord sur I1 j'utilisais E1 pour le mettre à jour et
laissait E2 tel quel. Sauf que I2 est encore plus proche de E1, il devrait
être donc être mis à jour pour I2 et c'est E2 qui devrait être mis à jour
pour I1.

C'est maintenant le cas car je conserve pour chaque arbre existant
l'arbre importé le plus proche.
- si l'arbre importé n'est pas le meilleur candidat (ie. il y a un autre
arbre importé qui est plus proche de l'arbre existant), j'essaye avec les
autres arbres existants qui étaient dans son rayon (et s'il n'y a plus
d'autres arbres existants alors il faudra créer un nouvel élément)
- si l'arbre importé est le meilleur candidat, je peux alors
utiliser l'arbre existant pour le mettre à jour. Mais je dois alors
relancer tout le processus pour l'ancien meilleur arbre importé qui à son
tour pourrait éventuellement faire des changements (fonction récursive).

Bon c'est pas évident d'expliquer tout ça par mail mais vous pouvez voir
les sources ici:
https://github.com/vince-from-nice/osmaxil/blob/master/src/main/java/org/openstreetmap/osmaxil/plugin/maker/NiceTreeMaker.java

Il faut que je fasse plus de vérifications mais ça a l'air de bien
fonctionner.

De plus, comme je suis sûr d'associer l'arbre existant avec l'arbre importé
le plus proche, je peux me permettre d'augmenter le rayon (là j'ai mis 5
mètres).

D'ailleurs je peux attacher le résultat sur la mailing list (environ 500KB)
?

PS: outch j'avais pas vu tous les mails qui s'était accumulés depuis que
j'ai commencé mon mail hier soir ! Je vais essayer d'y répondre un peu plus
tard...
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Importation des arbres municipaux sur Nice

[Vincent Frison]

Je comprends aisément votre méfiance sur les imports automatiques, surtout
si ceux ci sont mal faits, ou faits à partir de mauvaises données. Sauf que
là je ne pense pas que ça soit le cas car les données importées
correspondant bien à la réalité. La précision n'est évidemment pas
parfaite, tout comme celles des arbres existants d'ailleurs, mais je
pense qu'elle est largement suffisante pour des arbres. Et je pense pas
faire ça mal, en tout cas je ne fais pas ça comme un sagouin tout seul dans
mon cave: j'essaye de communiquer autant que possible et j'essaye de
prendre en compte vos remarques bien souvent constructives.

Par contre j'ai plus de mal à adhérer à l'idée que les imports automatiques
déshumaniseraient OSM. Bon déjà je serais le premier partant pour aller
boire un verre avec des contributeurs locaux pour parler architecture et
botanique :) Mais surtout, à partir du moment où évidemment les données
sont correctes, je ne vois pas en quoi ça gêne: un import a le mérite de
rajouter avec peu d'effort (enfin quoique) beaucoup de données qui seraient
généralement beaucoup trop fastidieuses à rentrer manuellement. Alors qu'il
y a tellement de chose à rajouter dans OSM... c'est pas comme si je volais
du travail à des contributeurs humains ! De plus je rappelle que je
conserve les contributions existantes au lieu de les supprimer comme
initialement.

Pour revenir à l'exemple US que je ne connais pas du tout, j'avoue avoir du
mal à croire que ça soit simplement à cause de l'import auto de TIGER qu'il
y ait aussi peu de contributeurs. Sauf si l'import a été mal fait mais à ce
moment là c'est un autre problème. En fait j'aurais même tendance à penser
l'inverse: il est plus facile de motiver des contributeurs à travailler sur
une carte déjà bien remplie plutôt que sur une carte quasiment vide, où à
peu près tout reste à faire.. mais bon là on rentre dans la psychologie.

Donc voilà, à mon sens je ne vois que des côtés positifs à partir du moment
où l'import automatique est bien fait. Et encore une fois rien n'empêche de
pas retravailler manuellement des données importées automatiquement.

Rajouter les tags height / taxon / etc. sur les 30 000 les arbres
municipaux de Nice représenterait un sacré travail manuel. Je serais tout à
fait partant pour le faire avec du monde mais il faut aussi être réaliste,
les forces vives sur la région niçoise ont l'air assez minces. J'ai en tout
cas contacté les 2 personnes qui ont déjà rajouté des arbres sur Nice,
s'ils me répondent j'essayerai de voir s'elles sont motivées mais si au
final on est que 3 ou 4 ça serait titanesque de faire l'ensemble des
arbres. Disons qu'on pourrait au moins faire la Prom' (pour ceux qui ne
connaissent pas c'est la route en bord de mer de Nice). Par contre je
verrais plutôt ça en rajoutant les tags directement dans OSM depuis son
téléphone plutôt que de les noter sur une carte imprimée pour après les
faire intégrer dans l'OD de Nice (s'ils le veulent bien !) pour après les
réimporter dans OSM... à ce moment autant considérer que LA référence c'est
OSM ! ;p






Le 26 juillet 2015 14:44, Vincent Frison vincent.fri...@gmail.com a écrit
:

 Alors pour répondre à la question de Jérôme sur la gestion des conflits:

 Avant je ne considérais que l'arbre existant le plus proche de l'arbre
 importé. Mais comme je disais dans un post précédent: la gestion des
 multi matching trees (ie. les arbres existants qui sont dans le rayon de
 plusieurs arbres importés) est très basique puisque je met à jour l'élément
 avec les valeurs du 1er arbre importé tout simplement (pour les autres
 éléments importés je créé donc un nouvel élément).

 Comme tu l'as remarqué Jérôme il y a aucun tag taxon ou genus sur
 l'ensemble des arbres existants de Nice, ce qui est une mauvaise chose dans
 l'absolu... mais plutôt une bonne chose pour mon import ! :p

 Ceci dit on était pas à l'abri de cas problématiques, imaginons 2 arbres
 importés I1, I2 et 3 arbres existants E1, E2, E3 (et que le rayon est de
 5m).
 I12mE1
 I13mE2
 I21mE1
 I24mE3
 Avant si je tombais d'abord sur I1 j'utilisais E1 pour le mettre à jour et
 laissait E2 tel quel. Sauf que I2 est encore plus proche de E1, il devrait
 être donc être mis à jour pour I2 et c'est E2 qui devrait être mis à jour
 pour I1.

 C'est maintenant le cas car je conserve pour chaque arbre existant
 l'arbre importé le plus proche.
 - si l'arbre importé n'est pas le meilleur candidat (ie. il y a un autre
 arbre importé qui est plus proche de l'arbre existant), j'essaye avec les
 autres arbres existants qui étaient dans son rayon (et s'il n'y a plus
 d'autres arbres existants alors il faudra créer un nouvel élément)
 - si l'arbre importé est le meilleur candidat, je peux alors
 utiliser l'arbre existant pour le mettre à jour. Mais je dois alors
 relancer tout le processus pour l'ancien meilleur arbre importé qui à son
 tour pourrait éventuellement faire des changements (fonction récursive).

 Bon c'est pas évident d'expliquer tout ça par

Re: [OSM-talk-fr] Importation des arbres municipaux sur Nice

[Vincent Frison]

Le 26 juillet 2015 19:51, JB jb...@mailoo.org a écrit :

  Quelques réponses décousues :

 Le 26/07/2015 15:47, Vincent Frison a écrit :

 Par contre j'ai plus de mal à adhérer à l'idée que les imports
 automatiques déshumaniseraient OSM. Bon déjà je serais le premier partant
 pour aller boire un verre avec des contributeurs locaux pour parler
 architecture et botanique :)

 Vas-y, lance une invitation. Je pense qu'on ne le fait pas assez. En rase
 campagne, c'est pas forcément évident, mais en ville…


On va y aller tranquille, j'ai déjà envoyé des mails à 2 personnes.. et je
pars bientôt en vacances ! :)

 Mais surtout, à partir du moment où évidemment les données sont correctes,
 je ne vois pas en quoi ça gêne: un import a le mérite de rajouter avec peu
 d'effort (enfin quoique) beaucoup de données qui seraient généralement
 beaucoup trop fastidieuses à rentrer manuellement.

 … d'où la demande de leur entretien. Si ça n'intéresse pas grand monde de
 les mapper, qui va en plus les entretenir ? Dans 10, 20 ans, à quoi
 ressemblera la base de données ?


Oui mais bon à ce moment là on ne peut plus rien rajouter ! Si je rajoute
(manuellement) un arbre dans mon quartier et que dans 20 ans je ne suis
plus dans la région qui va mettre à jour mon arbre ?

 Pour revenir à l'exemple US que je ne connais pas du tout, j'avoue avoir
 du mal à croire que ça soit simplement à cause de l'import auto de TIGER
 qu'il y ait aussi peu de contributeurs. Sauf si l'import a été mal fait
 mais à ce moment là c'est un autre problème. En fait j'aurais même tendance
 à penser l'inverse: il est plus facile de motiver des contributeurs à
 travailler sur une carte déjà bien remplie plutôt que sur une carte
 quasiment vide, où à peu près tout reste à faire.. mais bon là on rentre
 dans la psychologie.

 Quelle était ta première contribution ? Dans les ateliers de découverte,
 l'accroche des participants est classiquement : il manque ma rue, le nom de
 ma rue, la boite aux lettres à coté de chez moi, mon boulanger. Une fois ça
 ajouté, ils sont pris dans le jeu et continuent. Tu leurs donnes une carte
 visuellement « complète », ils ne voient pas quoi faire. Alors, si l'import
 Tiger a été fait avant d'avoir une base de contributeurs locaux, celle-ci
 est beaucoup plus difficile à construire à postériori. Et puis, je ne veux
 pas tourner en rond, mais tu préfères contribuer sur de la nouvelle donnée,
 ou corriger l'existant, voire reprendre l'existant quand celui-ci est
 foireux ?

  Donc voilà, à mon sens je ne vois que des côtés positifs à partir du
 moment où l'import automatique est bien fait. Et encore une fois rien
 n'empêche de pas retravailler manuellement des données importées
 automatiquement.

 Même question. Qui préfère retravailler de la mauvaise donnée que d'en
 entrer de la nouvelle ?


Oui mais bon là t'es en train de partir sur le postulat que j'insère des
mauvaises données...

Je ne connais pas le langage Java, mais processMultiMatchingTree
 n'est-il pas une emplâtre sur une jambe de bois ? Un petit tri par distance
 à l'existant, pour intégrer d'abord les plus proches ?


Ah ba te remercie pour la jambe de bois ! ;p Le souci c'est que le tri doit
se faire à plusieurs niveaux.. mais il y a sans doute y avoir plus simple
ou plus efficace, même si la performance n'est pas du tout un problème
puisque l'import prend déjà très peu de temps (environ 3 minutes). Ceci
toute pull request est évidemment la bienvenue..


 Mais surtout, aussi beau que tu fasses l'algorithme, s'il y a plusieurs
 MatchingTree avec des distances à moins de 5m avec des distances à peu près
 équivalentes (un arbre à 2.5m, un autre à 3m), pour moi, c'est plutôt un
 signe que ces cas devraient être gérés à la main…


C'est un cas extrêmement rare qui pourrait éventuellement poser problème
mais à condition que les 2 arbres soient différents. Mais il faut rappeler
qu'aucun arbre existant sur Nice n'a de tag taxon / height / etc. Il y a
juste ceux de la Prom' ont le type=palm (qui sera gardé).
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Importation des arbres municipaux sur Nice

[Vincent Frison]

Le 26 juillet 2015 19:59, Emilie Laffray emilie.laff...@gmail.com a écrit
:


 Petite anecdote. Il fut même considéré a un moment d'effacer les données
 TIGER existantes afin de recréer une toile blanche. Chose qui au final ne
 s'est pas fait du faire de la difficulté de séparer ce qui avait été
 retouché (mais base sur TIGER) et ce qui ne l'avait pas été.


Bon d'accord l'import TIGER a visiblement été très négatif pour la
naissance de la communauté US.. mais pour revenir concrètement (et plus
modestement) à mon import d'arbres sur Nice, vous pensez sincèrement que ça
aurait un impact négatif sur la communauté niçoise d'OSM ?

Personnellement je ne le pense pas.. je dirais même que la communauté
niçoise s'intéressant aux arbres, passerait de 2 à 3 personnes, ce qui
ferait tout de même un gain de 50% ! ;p
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Importation des arbres municipaux sur Nice

[Vincent Frison]

Le 26 juillet 2015 22:26, Vincent de Château-Thierry v...@laposte.net a
écrit :


 Le 26/07/2015 21:30, Vincent Frison a écrit :
  Bon d'accord l'import TIGER a visiblement été très négatif pour la
  naissance de la communauté US.. mais pour revenir concrètement (et
  plus modestement) à mon import d'arbres sur Nice, vous pensez
  sincèrement que ça aurait un impact négatif sur la communauté niçoise 
 d'OSM ?

 Oui, tant que cette communauté n'aura pas dit le contraire.
 Ce qui est pointé depuis hier, c'est notamment le caractère intimidant de
 données importées, et le fait que la maintenance est une tâche beaucoup
 plus ingrate que la création de données. D'où l'importance de pouvoir
 s'approprier ce qui est fait, et le meilleur moyen reste encore d'avoir eu
 l'opportunité de le faire soi-même. Avec un import, difficile de se sentir
 concerné, affecté, par les données. C'est plutôt le découragement qui
 prévaut.

 J'aurais un discours plus modulé si on avait dans le cadre de ce fil un
 echo de contributeurs locaux, qui diraient en substance : c'est bon, que
 l'import soit fait, on s'occupe de la suite. Mais pour l'instant je
 n'entends rien.


Il est effectivement assez peu probable qu'une task force niçoise
envahissent le forum pour me venir en secours, à priori elle aurait déjà
fait vu le titre du sujet !

Je commence juste à me rendre compte (je suis un nouveau de 6 mois hein) à
quel point les imports auto sont mal vues par ici. Je savais bien que ça
pouvait être sensible (ils en parlent même sur la page import du wiki) mais
pour être franc je ne m'attendais pas du tout à une telle levée de
boucliers pour cet import d'arbres.. si peu risqué à mon sens !

J'ai bien conscience que la problématique de la maintenance est évidemment
primordiale mais personnellement je ne suis vraiment pas sûr qu'une donnée
rentrée manuellement soit forcément plus viable, sur le long terme, qu'une
entrée rentrée automatiquement, surtout pour ce type de donnée. Pour
revenir par exemple au cas où je rentre manuellement un arbre de mon
quartier puis je déménage, je risque fortement de ne plus jamais le mettre
à jour. Alors que je pourrais continuer à rejouer tous les 6 mois et sans
effort via mon script pour utiliser la dernière mise à jour de l'opendata
de Nice indiquant le très peu probable abattage de l'arbre.

Je me permet quand même de rappeler que mon import insère des arbres qui
sont actuellement bien réels, tout.en respectant les données déjà insérés
par environ.. 3 contributeurs différents depuis le tout début d'OSM ! Il
faut peut-être admettre le fait que c'est pas un sujet qui passionne les
foules et le fait que l'on puisse se l'approprier ou pas un arbre en le
créant ne va pas changer grand chose. Avec un peu de pragmatisme on imagine
sans peine que sans import automatique il n'y aura jamais de bonne
couvertures du parc niçois avant un bon petit siècle..

Bref j'aurais vraiment du mal admettre que l'on m'interdisse cet import
(après la déception de celui pour PSS ça serait dur) même si je ne fera
évidemment rien si c'était le cas.. par contre ça serait bien de me le dire
clairement et si possible rapidement parce que mine de rien le dev est
bientôt fini.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Intégration des données de PSS dans OSM

[Vincent Frison]

Effectivement ce tag pourrait leur faire plaisir mais je doute que ça soit
suffisant pour leur faire abandonner leur clause NC.

De toute les manière je vais un peu attendre un ou deux mois avant de
revenir vers eux pour voir si leur position a changé..

Le 25 juillet 2015 16:59, osm.sanspourr...@spamgourmet.com a écrit :

  Je vois un tag qui pourrait leur faire plaisir :
   attribution http://wiki.openstreetmap.org/wiki/Key:attribution  *User
 defined*  [image: Nœud]
 http://wiki.openstreetmap.org/wiki/FR:%C3%89l%C3%A9ments#N.C5.93ud_.28node.29
  [image:
 Chemin]
 http://wiki.openstreetmap.org/wiki/FR:%C3%89l%C3%A9ments#Chemin_.28way.29 
 [image:
 Zone]
 http://wiki.openstreetmap.org/wiki/FR:%C3%89l%C3%A9ments#Area_.28closed_way.29
  [image:
 Relation]
 http://wiki.openstreetmap.org/wiki/FR:%C3%89l%C3%A9ments#Relation
 Attribution au créateur si requise.
 Mais le principe de l'ODbl est et reste : libre d'utilisation en citant.

 Jean-Yvon

 ___
 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] Importation des arbres municipaux sur Nice

[Vincent Frison]

Le 25 juillet 2015 18:53, Vincent Pottier vpott...@gmail.com a écrit :

 Si le programme, qui détecte la présence d'un arbre à 2 m, pouvait
 modifier le point existant plutôt que de le remplacer, ce serait top.
 Merci pour ceux qui ont œuvré à OSM.


Mais c'est le cas ! J'ai justement changé le programme pour qu'il mette à
jour les arbres existants à moins de X mètres au lieu de les supprimer..
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Importation des arbres municipaux sur Nice

[Vincent Frison]

Au fait le portail OpenData de Nice utilise la Licence Ouverte (
http://www.etalab.gouv.fr/licence-ouverte-open-licence), on est bien
d'accord que c'est bien compatible avec l'ODbL ? A priori oui mais c'est
juste pour être sûr ;)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Importation des arbres municipaux sur Nice

[Vincent Frison]

Le 25 juillet 2015 16:45, osm.sanspourr...@spamgourmet.com a écrit :

  De plus si une administration a un SIG donnant ces informations et les
 proposant à l'import, on peut supposer que soit ils comptent sur les
 contributeurs pour leur signaler les problèmes soit ils vont vouloir que
 l'import soit fait régulièrement.
 Sinon ça ne fait pas très sérieux.
 Vincent, tu peux peut-être voir avec eux pour que leur base et OSM restent
 cohérents.


A vrai dire je n'ai plus de nouvelles d'eux depuis quelque temps, la
personne avec qui j'étais en contact est surement en vacance.

Selon le wiki http://wiki.openstreetmap.org/wiki/FR:Tag:natural%3Dtree :
 natural=tree :
 Arbre important seul ou en groupes.
 453 298 en France.

 Si tu ne sais pas, ne vaut-il pas mieux mettre pour les nouvelles entrées :
   natural http://wiki.openstreetmap.org/wiki/FR:Key:natural  wood
 http://wiki.openstreetmap.org/wiki/Tag:natural%3Dwood  [image: Nœud]
 http://wiki.openstreetmap.org/wiki/FR:%C3%89l%C3%A9ments#N.C5.93ud_.28node.29
  [image:
 Zone]
 http://wiki.openstreetmap.org/wiki/FR:%C3%89l%C3%A9ments#Area_.28closed_way.29
 Bois.  360 en France


J'avoue ne pas très bien comprendre, apparemment ce natural=wook est
vraiment fait pour les forêts ou bois, mais dans le cadre d'import d'arbres
municipaux ça n'a pas trop de sens.. enfin cela pourrait éventuellement en
avoir pour deux ou trois gros parcs dans Nice mais perso je préfère les
implémenter en rajoutant des éléments avec natural=tree. En plus de ça mon
programme ne sait pas faire cela actuellement, il faudrait détecter des
zones a forte concentration et c'est pas si simple. Ceci dit si c'est
vraiment gênant rien n'empêchera de le faire manuellement après l'import
(cad supprimer les arbres importés et rajouter une zone avec natural=wood).


 Par contre quand je vois proposer de mettre une taille par défaut, ça me
 semble aller contre l'usage : quand on n'a pas d'info, on ne l'invente pas.
 Tu peux peut-être ajouter un fixme pour discriminer ceux qui n'ont pas été
 vérifiés sur le terrain, ou fixme et une hauteur arbitraire.
 Il me semble plus efficace d'essayer de récupérer plus d'information
 (j'imagine que la municipalité sait ce qui est planté).
 Ou une note (pour que les cartographes aillent compléter).


Oui j'avoue que cela me gênait aussi..  du coup j'essayerai de faire des
mises à jour manuelles sur les arbres de la Prom' pour réduire la taille
des petits arbres.

Le rendu est donc conforme à la description (arbre important, pas arbre et
 encore moins arbuste).
 Donc soit il s'agit d'un arbre soit il s'agit d'un arbuste.


J'ai pas trop compris.. il ne faudrait pas importer des arbres dans OSM si
ceux ci sont petits ?

Si tu veux ajouter une estimation de largeur :
 est_width http://wiki.openstreetmap.org/wiki/FR:Key:est_width=*.
 Alors est_height si tu y tiens ?


Ah je ne savais pas que ce tag est_height existait.. mais est il vraiment
pris en charge par les moteurs de rendu (F4map) ? Parce qu'il n'a pas l'air
super officiel puisqu'il n'existe pas sur le wiki (contrairement au tag
est_width) mais je vais essayer.

Doit on mettre operator avec le service technique de Nice ?


Ah je sais pas, mais ça me parait une bonne idée... en mettant
Municipality of Nice comme valeur ?
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Script osmaxil - Suivi du bâti

[Vincent Frison]

Bonjour Stéphane,

Je suis justement en train de travailler dessus, enfin je vais y revenir
dès que j'en aurais fini l'import des arbres niçois.

Pour info le programme peut maintenant créer des bâtiments (et surtout
leurs sous-bâtiments) à partir des données OpenData de Paris. Et
franchement le rendu 3D est vraiment sympa, on arrive à bien reconnaître
les immeubles, rues et quartiers !

La partie la plus technique (qui est loin d'être finie) consiste à bien
gérer les effacements des anciens bâtiments.. ainsi que la conservation des
nodes adresses. Je vous reparlerai de tout ça très bientôt car il me
faudra clairement de l'aide..

Et pour revenir à ta question la réponse est oui à priori.. sauf que sur
Paris autant travailler avec OpenDataParis plutôt qu'avec le cadastre.. le
1er à une résolution 4 fois supérieures et surtout on peut avoir la
hauteur (approximative) sur CHACUN des sous-bâtiments.




Le 24 juillet 2015 14:13, Stéphane Péneau stephane.pen...@wanadoo.fr a
écrit :

 Bonjour Vincent,

 Dis-moi, ton script, est-ce qu'il ne pourrait pas aussi être utilisé pour
 comparer un fichier osm comprenant le bâti issu du cadastre, à ce qui est
 présent dans Osm ?
 Je sais que pour le moment il ne permet pas de créer de nouveaux objets,
 mais s'il permet dans un premier temps de créer une visualisation des zones
 où il manque des bâtiments, je crois que ça pourrait rendre pas mal de
 services.

 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] Importation des arbres municipaux sur Nice

[Vincent Frison]

Le 24 juillet 2015 14:44, JB jb...@mailoo.org a écrit :

 Sans vouloir trop m'avancer, je pense que Christian demandait : « Qui va
 s'occuper de l'entretien des données arbres à Nice ? ». C'est beau (ou pas)
 de les importer, mais quid de leur évolution dans 2, 5, 15 ans ? Est-ce que
 les mappeurs locaux sont ok pour s'en charger ? Est-ce que tu es prêt à
 t'en charger ?


Oui je suis ok pour m'en occuper (j'habite la région pour info), y compris
dans 15 ans si je suis toujours vivant...
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Importation des arbres municipaux sur Nice

[Vincent Frison]

Effectivement je vais plutôt modifier les éléments existants plutôt que de
les supprimer, c'est une meilleure manière de procéder, en tout cas moins
agressive.

Je ferai aussi quelques tests en variant le rayon, je vous tiendrai au
courant des résultats...
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Importation des arbres municipaux sur Nice

[Vincent Frison]

Le 21 juillet 2015 22:00, Vincent Frison vincent.fri...@gmail.com a écrit
:

 Je ferai aussi quelques tests en variant le rayon, je vous tiendrai au
 courant des résultats...


Avec un rayon de 2 mètres :
Total of created trees: 29947
Total of updated trees: 574
Total of multi matching trees: 28

Avec un rayon de 5 mètres :
Total of created trees: 29767
Total of updated trees: 754
Total of multi matching trees: 281

Maintenant je met à jour les éléments existants au lieu de les effacer.

La mise à jour consiste à mettre la même position (la même que l'arbre
importé) et de rajouter un tag ref:FR:Nice:trees=* avec l'identifiant de
leur jeu de données.

Par contre la gestion des multi matching trees (ie. les arbres existant
qui matchent plus qu'un seul arbre importé) est très basique puisque je met
à jour l'élément avec les valeurs du 1er arbre importé tout
simplement (pour les autres éléments importés je créé donc un nouvel
élément). Mais bon, avec un rayon de 2 mètres ça ne concerne moins
d'1/1000e des arbres.. et surtout je rappelle qu'en plus on parle de
décalages inférieurs à 2 mètres donc bon je pense que c'est tolérable. Et
du coup je pense qu'il faut garder un rayon faible comme 2 mètres.

Au niveau des 1188 arbres visibles sur Overpass il faut voir que:
- certains arbres municipaux ne sont pas référencés
- certains arbres existants ne sont pas des arbres municipaux
- certains arbres existants peuvent être municipaux (et référencés) mais
éventuellement trop mal positionnés (et dans ce cas là je pourrai pas faire
grand chose)
Mais effectivement je vais devoir creuser un peu pour mieux comprendre  ;)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Importation des arbres municipaux sur Nice

[Vincent Frison]

Hello

Je compte importer dans OSM l'ensemble des arbres municipaux de Nice, merci
au portail OpenData de l'agglomération de Côte d'Azur. Ici c'est du vrai
open data, je ne devrais donc pas avoir la même frustration qu'avec
l'import des immeubles de PSS ;)

Ils viennent de mettre à jour leur fichier qui contient maintenant plus de
30 000 arbres : http://opendata.nicecotedazur.org/data/dataset?q=arbres

En plus de créer les nouveaux arbres mon programme vérifie également la
présence d'arbres existants afin de les effacer. Actuellement j'ai mis un
rayon de 2 mètres donc pour chaque arbre importé, je regarde les arbres
existants qui sont à moins de 2 mètres. Pour l'instant je n'efface que
l'arbre plus proche de l'arbre importé (je pourrais également supprimer
tous les arbres qui sont à moins de x mètres mais en fait ça ne change pas
grand chose car s'il y a plusieurs arbres existants qui sont très proches à
priori il y aura également plusieurs arbres importés qui seront très
proches donc au final même en ne supprimant que l'arbre existant le plus
proche tous les arbres existants seront bien effacés, ce que j'ai pu
vérifier par mes tests).

Concrètement sur les ~30 000 arbres importés il y a ~540 arbres existants à
supprimer.

Ce qui est dommage c'est que le fichier n'indique pas le type des arbres et
c'est d'autant plus dommage que les arbres existants ont parfois un tag
type=*. Par ex. les arbres existants le long de la Promenade des Anglais
sont marqué comme palmier (type=palm). Malheureusement je serai obligé de
remettre le type à la main une fois l'import exécuté. Mon programme
pourrait éventuellement récupérer le type des arbres existants mais bon ça
ne marcherait que sur une toute petite partie des arbres importés...

D'ailleurs j'ai un peu de mal à comprendre la bonne manière d'indiquer le
type car sur la page Wiki du tag natural=tree (
http://wiki.openstreetmap.org/wiki/Tag:natural%3Dtree) il est marqué que le
tag type=* est obsolète et qu'il faut plutôt utilisé le tag leaf_type=*.
Sauf que ce dernier n'est censé prendre que les valeurs suivantes :
broadleaved / needleleaved / mixed / leafless. De plus sous JSOM si on met
type=palm ça affiche bien l'arbre avec une image de palmier mais ça ne le
fait pas si j'essaye avec genus|species=palm|palmtree. Bref c'est pas très
clair...

Voila si vous avez des conseils ou suggestions n'hésitez surtout pas..

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

Re: [OSM-talk-fr] Intégration des données de PSS dans OSM

[Vincent Frison]

Merci Jean-Yvon et Jérôme pour vos retour, avec vos arguments et avec
l'aide de Christian, notre vénérable président, je vais essayer de les
convaincre d'abandonner cette satanée clause NC !
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Intégration des données de PSS dans OSM

[Vincent Frison]

Le 18 juillet 2015 15:29, Christian Quest cqu...@openstreetmap.fr a écrit
:

  Il est clair que la licence actuelle de PSS n'est pas compatible avec une
 intégration de toute ou partie de ces données dans OSM.

 A chaque fois qu'on parle d'import ou autre, il faut TOUJOURS s'occuper de
 la partie légale avant de s'attaquer à la technique. ça évite de perdre du
 temps pour se retrouver coincer au final. Il me semble que ce point a été
 soulevé relativement tôt à propos de PSS.


Oui c'est vrai mais le temps n'a pas été complètement perdu parce que mon
programme m'a ensuite permis de faire l'import des immeubles parisiens
(avec pas mal de modifications tout de même) à partir des données libres
disponibles data.paris.fr. Je suis d'ailleurs en train de le faire
fortement évoluer pour pouvoir faire des suppression/ajouts d'immeubles et
sous-immeubles (toujours pour l'open data de Paris), je vous en reparlerai
dans un autre thread.

Autre chose non évaluée... d'où viennent les données de localisation de PSS
 ? C'est sur un fond Google ou par géocodage que les lat/lon ont été
 déterminés ? Dans ce cas, PSS ne peut pas les utiliser ailleurs que sur
 Google Maps et OSM ne peut pas non plus les réutiliser...


Hmm c'est un autre point qui pourrait être bloquant effectivement, je vais
leur rappeler.. ceci dit c'est pas du tout sûr car pour un nombre important
d'immeuble les coordonnées correspondent très mal avec les immeubles
visibles sous la vue satellite de GMaps (et d'où le fait que mon import ne
pouvait importer que 31k immeubles sur les 43k€ présents dans leur export).

Il y a une différence de philosophie importante entre PSS et OSM. Le choix
 d'une licence CC-by-NC-ND très peu libre et ouverte par rapport à l'ODbL
 qui limite très peu les usages mais pousse à contribuer.

 Malheureusement ce n'est pas la première fois qu'on ne peut faire
 converger un projet de ce type avec OSM sauf à faire comprendre aux
 contributeurs de ce projet qu'ils font un petit peu fausse route... par
 exemple en utilisant GMaps d'un côté et donc en autorisant Google à faire
 ce qu'ils veulent des données PSS (y compris un usage commercial) et de
 l'autre à ne pas trouver un moyen de collaborer avec OSM...

 Faire naitre une vraie réflexion côté PSS est à mon avis la meilleure
 suite.


J'espère qu'on l'a fait, maintenant il n'y a plus qu'a attendre...
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Intégration des données de PSS dans OSM

[Vincent Frison]

Le 28 mai 2015 23:13, Vincent Frison vincent.fri...@gmail.com a écrit :

 Sinon ça serait bien chouette s'ils pouvaient également nous rajouter dans
 leur export un ou deux champs supplémentaires, comme par exemple le nom ou
 l'année de construction mais bon c'est déjà assez classe qu'ils nous
 autorisent déjà utiliser la hauteur malgré leur vilaine licence BY-NC-ND.


Alors finalement ils nous donnent également le nom des bâtiments dans leur
export :)

C'est une donnée généralement bien utile sauf dans le cas où il n'y a pas
vraiment de nom du bâtiment et dans ce cas là ils ont simplement remplis le
nom avec l'adresse (évidemment pour ces fausses adresses je ne rajouterai
pas de tag name=*).

Par contre ils veulent rajouter cette clause empêchant une utilisation
commerciale. Voici actuellement l'autorisation qu'ils sont prêts à signer :

*Nous soussignons Boris Foucaud, cofondateur et administrateur de
PSS-archi.eu et de sa base de données d’immeubles en licence BY-NC-ND,
concédons à OSMF, d’une manière exceptionnelle et perpétuelle, une licence
internationale, non exclusive et non soumise aux droits patrimoniaux
d’auteur, aux droits des auteurs de bases de données ou à tout autre droit,
relatif aux éléments du Contenu mentionnés ci-dessous, quel que soit le
support. La concession porte sur un droit d’utilisation de données hors
utilisation commerciale du Contenu, ainsi que sur le droit de
sous-licencier des contributions à des tiers ou sous-traitants hors
exploitation commerciale. Le présent contrat devient caduque en cas
d’utilisation commerciale des données.*

*Les éléments de Contenus mis à disposition sont les suivants :*

*·Nom d’immeubles*

*·Coordonnées d’immeubles*

*·Hauteur d’immeubles*

*·Lien vers leur fiche PSS*

*Nous acceptons qu’OSMF cite PSS-archi.eu, par le biais de la page web
http://wiki.openstreetmap.org/wiki/Attributionhttp://wiki.openstreetmap.org/wiki/Attribution
http://wiki.openstreetmap.org/wiki/Attribution.*

*fait à Boulogne-Billancourt, le 16/07/2015, en deux exemplaires*


Pensez vous qu'on puisse faire quelque chose avec cette autorisation ? J'ai
l'impression que non puisque cette clause anti-commerciale rentrerait en
conflit direct avec la licence ODbL :(

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

Re: [OSM-talk-fr] Intégration des données de PSS dans OSM

[Vincent Frison]

Vu le temps que j'ai passé (le développement de l'import + la négociation)
j'aimerais si possible ne pas arriver à cette conclusion ;)

Si vous me confirmez qu'avec ce type d'autorisation on ne peut absolument
rien faire il va falloir essayer de les convaincre de retirer cette clause
anti-commerciale.

En fait le souci pour le staff de PSS c'est qu'ils trouveraient ça
complètement anormal que des sociétés puissent faire de l'argent sur le
travail de leur contributeurs bénévoles (alors que personnellement je suis
persuadé que 99% de leurs contributeurs serait ravis de voir leur travail
incorporé dans OSM).

Voilà où j'en suis, si quelqu'un a déjà fait ce genre de négociations ou à
des conseils à me donner ça m'intéresse...


Le 16 juillet 2015 20:36, Jérôme Seigneuret jseigneuret-...@yahoo.fr a
écrit :

 Donc en clair ça sert à rien ;-)

 Le 16 juillet 2015 16:02, Vincent Frison vincent.fri...@gmail.com a
 écrit :

 Le 28 mai 2015 23:13, Vincent Frison vincent.fri...@gmail.com a écrit :

 Sinon ça serait bien chouette s'ils pouvaient également nous rajouter
 dans leur export un ou deux champs supplémentaires, comme par exemple le
 nom ou l'année de construction mais bon c'est déjà assez classe qu'ils nous
 autorisent déjà utiliser la hauteur malgré leur vilaine licence BY-NC-ND.


 Alors finalement ils nous donnent également le nom des bâtiments dans
 leur export :)

 C'est une donnée généralement bien utile sauf dans le cas où il n'y a pas
 vraiment de nom du bâtiment et dans ce cas là ils ont simplement remplis le
 nom avec l'adresse (évidemment pour ces fausses adresses je ne rajouterai
 pas de tag name=*).

 Par contre ils veulent rajouter cette clause empêchant une utilisation
 commerciale. Voici actuellement l'autorisation qu'ils sont prêts à signer :

 *Nous soussignons Boris Foucaud, cofondateur et administrateur de
 PSS-archi.eu et de sa base de données d’immeubles en licence BY-NC-ND,
 concédons à OSMF, d’une manière exceptionnelle et perpétuelle, une licence
 internationale, non exclusive et non soumise aux droits patrimoniaux
 d’auteur, aux droits des auteurs de bases de données ou à tout autre droit,
 relatif aux éléments du Contenu mentionnés ci-dessous, quel que soit le
 support. La concession porte sur un droit d’utilisation de données hors
 utilisation commerciale du Contenu, ainsi que sur le droit de
 sous-licencier des contributions à des tiers ou sous-traitants hors
 exploitation commerciale. Le présent contrat devient caduque en cas
 d’utilisation commerciale des données.*

 *Les éléments de Contenus mis à disposition sont les suivants :*

 *·Nom d’immeubles*

 *·Coordonnées d’immeubles*

 *·Hauteur d’immeubles*

 *·Lien vers leur fiche PSS*

 *Nous acceptons qu’OSMF cite PSS-archi.eu, par le biais de la page web
 http://wiki.openstreetmap.org/wiki/Attributionhttp://wiki.openstreetmap.org/wiki/Attribution
 http://wiki.openstreetmap.org/wiki/Attribution.*

 *fait à Boulogne-Billancourt, le 16/07/2015, en deux exemplaires*


 Pensez vous qu'on puisse faire quelque chose avec cette autorisation ?
 J'ai l'impression que non puisque cette clause anti-commerciale rentrerait
 en conflit direct avec la licence ODbL :(

 ++ Vincent

 ___
 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] Intégration des données de PSS dans OSM

[Vincent Frison]

Le 1 mai 2015 21:14, Vincent Frison vincent.fri...@gmail.com a écrit :

 Merci pour vos réponses, notamment Philippe pour ton mail très instructif.

 Et donc s'il faut résumer cette licence BY-NC-ND empêche toute extraction
de donnée vers OSM, c'est vraiment dommage.

 Je vais quand même essayer de leur demander si une autorisation spéciale
pour OSM serait envisageable, sait on jamais...

Bon à priori ça devrait pouvoir se faire, ils m'ont même donné un export de
leur base en XML ! :)

L'export contient :
- la hauteur de l'immeuble
- l'URL vers la fiche de l'immeuble sur leur site
- et évidemment les coordonnées

Le fichier contient 43 188 bâtiments et non pas 47 636 comme indiqué sur
leur site car ils ont déjà filtré les bâtiments qui sont en projet ou
détruit (ça tombe bien car ils ne nous intéressent pas).

Maintenant il faudrait que je leur fournisse un document autorisant
explicitement l'import de ces données dans OSM puis qu'ils le signent. Si
quelqu'un a un modèle je suis preneur...

J'ai fait tourner mon programme sur cet export et voici quelques
statistiques :
Total of loaded imports: 43188
Total of matched imports: 33059
Number of matched elements: 31789
Number of updatable elements: 31756
Number of updated elements: 0
Repartition by matching scores:
- score between 0% and 10% : 972 (3%) elements = 0 updated (970 were
updatable)
- score between 10% and 20% : 0 (0%) elements = 0 updated (0 were
updatable)
- score between 20% and 30% : 0 (0%) elements = 0 updated (0 were
updatable)
- score between 30% and 40% : 0 (0%) elements = 0 updated (0 were
updatable)
- score between 40% and 50% : 0 (0%) elements = 0 updated (0 were
updatable)
- score between 50% and 60% : 0 (0%) elements = 0 updated (0 were
updatable)
- score between 60% and 70% : 0 (0%) elements = 0 updated (0 were
updatable)
- score between 70% and 80% : 0 (0%) elements = 0 updated (0 were
updatable)
- score between 80% and 90% : 0 (0%) elements = 0 updated (0 were
updatable)
- score between 90% and 100% : 30817 (96%) elements = 0 updated (30786
were updatable)

Quelques remarques :
- sur les 43 188 buildings PSS seulement 33059 correspondent à au moins un
bâtiment OSM = environ 1 buildings PSS sont écartés (soit parce qu'ils
ont des coordonnées placées légèrement à côté du bâtiment soit parce que le
bâtiment n'existe tout simplement pas dans OSM)
- cela fait que 31789 buildings OSM correspondent avec au moins un building
PSS :
  * 972 correspondent à plus d'un seul building PSS et dans ce cas là je
préfère mettre un score global à 0% (et donc ne rien faire) car ça veut
dire que le découpage de ces bâtiments OSM n'est pas assez précis.
  * 30817 correspondent qu'à un seul building PSS et parmi ceux ci 30786
sont updatables, les autres ne le sont pas car ils avaient déjà un tag
height.

Il faut bien comprendre que le souci comparé à mon import des bâtiments
parisiens c'est qu'ici on a pas la surface des buildings, or je me basais
justement sur celle ci pour calculer les scores de correspondance. Du coup
un building PSS dont ses coordonnées sont à l'intérieur d'un building OSM a
forcément un score de correspondance à 1.0 (ie. le score max). Par contre
s'il y en a plus qu'un seul building PSS qui matche un building OSM
(environ 3% des cas) alors je met le score global du building OSM à 0%
afin de ne rien faire. Cela évitera pas mal de situations problématiques
mais pas le cas où un building OSM correspond dans la réalité à plusieurs
buildings de hauteur différente. C'est surtout vrai pour Paris mais ça peut
aussi arriver hors de Paris même si c'est de manière beaucoup plus
marginale de ce que j'ai vu. Mais ce que je pourrais éventuellement faire
c'est avoir une bounding box d'exclusion afin de ne pas toucher à Paris et
sa petite couronne. Ou sinon j'ai vu sur leur site que certains buildings
avaient une surface de terrain. S'ils pouvaient la rajouter export je
pourrais calculer des scores comme je le faisais pour l'import sur Paris.
Sauf que cette notion de surface de terrain ne correspond pas forcément à
l'empreinte du bâtiment (par ex. pour les résidences avec plusieurs
immeubles ça peut être la surface totale de la résidence) et en plus cette
info n'est pas présente à chaque fois. Au final il y aurait donc beaucoup
moins que 30k buildings updatables mais au moins ça serait plus sûr, bref
c'est à creuser...

Sinon ça serait bien chouette s'ils pouvaient également nous rajouter dans
leur export un ou deux champs supplémentaires, comme par exemple le nom ou
l'année de construction mais bon c'est déjà assez classe qu'ils nous
autorisent déjà utiliser la hauteur malgré leur vilaine licence BY-NC-ND.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Intégration des données de PSS dans OSM

[Vincent Frison]

Merci pour vos réponses, notamment Philippe pour ton mail très instructif.

Et donc s'il faut résumer cette licence BY-NC-ND empêche toute extraction
de donnée vers OSM, c'est vraiment dommage.

Je vais quand même essayer de leur demander si une autorisation spéciale
pour OSM serait envisageable, sait on jamais...





Le 28 avril 2015 07:37, Jean-Christophe Becquet j...@apitux.com a écrit :

 Le 27/04/2015 13:17, Vincent Frison a écrit :

 De ce que j'ai compris ce qui les gêne dans la licence OSM c'est que les
 données peuvent être réutilisées dans des projets commerciaux.
 Apparemment il vont bientôt rendre disponible leurs données sous la
 licence BY-NC-ND (https://creativecommons.org/licenses/by-nc-nd/2.0/fr/).


 Bonjour,

 Peut-être utiliser l'argumentaire Libérez vos créations pour essayer de
 les faire changer d'avis ?
 http://www.apitux.org/index.php?2008/05/03/232-liberez-vos-creations

 Des explications sur les licences Creative Commons et des infos pour aller
 plus loin sur :
 http://www.apitux.org/index.php?2005/09/11/11-les-licences-creative-commons

 Bonne continuation

 Librement

 JCB
 --
 Des formats ouverts pour des données libres

 http://www.apitux.org/index.php?2006/07/09/107-des-formats-ouverts-pour-des-donnees-libres

 ==APITUX : le choix du logiciel libre==

 APITUX - Jean-Christophe Becquet
 BP 32 - 04001 Digne-les-Bains Cedex
 06 25 86 07 92 - j...@apitux.com - http://www.apitux.com/
 SIRET : 452 887 441 00031 - APE : 6202A

 ===


 ___
 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

[OSM-talk-fr] Intégration des données de PSS dans OSM

[Vincent Frison]

Bonjour,

J'en avais déjà parlé il y a quelques temps sur cette liste mais depuis ça
a un peu avancé. Pour rappel le site PSS (http://www.pss-archi.eu) fournit
une base de données avec plus de 47 000 immeubles répartis sur toute la
France.

Mon idée était de récupérer au minimum les infos de hauteur des immeubles
(nombre d'étages ou hauteur réelle) afin de mettre à jour les bâtiments
existants dans OSM, comme j'ai déjà pu le faire très récemment avec la base
open data de Paris (49 000 immeubles mis à jour, soit plus de la moitié des
immeubles parisiens).

De ce que j'ai compris ce qui les gêne dans la licence OSM c'est que les
données peuvent être réutilisées dans des projets commerciaux. Apparemment
il vont bientôt rendre disponible leurs données sous la licence BY-NC-ND (
https://creativecommons.org/licenses/by-nc-nd/2.0/fr/).

Comme je ne suis pas du tout un expert sur ces questions juridiques je vous
requiert de l'aide pour savoir que ce qu'on pourrait tirer de cette belle
source de données. Mais peut-être rien du tout à cause des restrictions de
cette licence...

Merci d'avance pour votre aide, Vincent.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Hauteur et nombre d'étages des bâtiments

[Vincent Frison]

Le 22 avril 2015 18:34, David Crochet david.croc...@free.fr a écrit :

 Bonjour

 Le 22/04/2015 14:32, Vincent Frison a écrit :

 Pour info j'ai créé sur le Wiki une page dédiée à cette import :
 http://wiki.openstreetmap.org/wiki/Paris,_France/Buildings_Heights_Import
 J'ai aussi rajouté un petit paragraphe dans la page dédié à Paris :

 http://wiki.openstreetmap.org/wiki/Paris#Buildings_heights_.28source.3Ddata.paris.fr.29


 Peut-être une annonce sur le OSM-Weekly anglophone et francophone ?


Pourquoi pas :)

J'ai laissé un message ici : http://www.weeklyosm.eu/fr/contact
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Hauteur et nombre d'étages des bâtiments

[Vincent Frison]

Effectivement on peut avoir des buildings:parts qui peuvent dépasser. Mais
je lancerai bientôt un nouveau sujet du discussion pour éclaircir tout ça
et parler plus globalement de ce qu'on pourrait faire pour avoir un
meilleur découpage des bâtiments que celui existant.

En attendant j'ai donc lancé mon programme d'import sur le serveur live
(avec un score minimal de 80%) et voici quelques statistiques qui
correspondent à celles que j'avais déjà envoyés :

Total of loaded ODP imports: 352293
Total of matched ODP imports: 293527

Total of matched OSM buildings: 86723
Total of updated OSM buildings: 49004

Donc voila un peu plus de la moitié des immeubles parisiens ont donc
maintenant leur nombre d'étage réel :)

Le souci c'est que ça a surtout bien marché pour les petits immeubles, pour
les gros immeubles ça ne pouvait bien marcher à cause du découpage. A
voir donc ce que l'on pourrait faire pour améliorer ceci...

Pour info j'ai créé sur le Wiki une page dédiée à cette import :
http://wiki.openstreetmap.org/wiki/Paris,_France/Buildings_Heights_Import
J'ai aussi rajouté un petit paragraphe dans la page dédié à Paris :
http://wiki.openstreetmap.org/wiki/Paris#Buildings_heights_.28source.3Ddata.paris.fr.29

Sinon je pensais également relancer les gars de PSS pour essayer d'avoir
leur accord. Je rappelle que c'est une base de données de plus de 40 000
immeubles répartis sur toute la France. Mais sans parler des problèmes de
licence c'est pas sûr que ça soit jouable techniquement car dans leur BD il
n'y a pas les formes des immeubles mais juste leurs coordonnées
(correspondant au centre des immeubles). Je ne pourrai donc plus calculer
des matching scores basés sur les surfaces comme c'était le cas avec
OpenDataParis.

Le 18 avril 2015 16:05, Philippe Verdy verd...@wanadoo.fr a écrit :



 Le 18 avril 2015 14:26, Vincent Frison vincent.fri...@gmail.com a écrit
 :

 L'idée de Vincent est intéressante, en effet pour les buildings pour
 lesquels la correspondance serait trop faible je pourrais générer un
 fichier XML proposant des ajouts d'éléments building:parts. Ces fichiers
 seraient ensuite à merger manuellement avec les bâtiments existants.

 Cela ne sera pas super simple, parmi les nombreuses difficultés il faudra
 notamment régler un léger décalage de quelques mètres entre les bâtiments
 ODP et ceux existant dans OSM (et visiblement ce décalage est variable). Or
 le building OSM, qui ferait office de building principal est censé
 englober parfaitement les différents éléments building:part si j'ai bien
 compris.


 Pas forcément, que fais tu des batiments dont la partie supérieure passe
 au dessus de la chaussée: au sol il y a plusieurs parties, mais aux étages
 le polygone est plus grand, puis ensuite peut avoir à nouveau des étages
 plus petits.

 Chose courante également, le long de la rue il y a souvent un passage
 couvert par le bâtiment situé dessus (et ce ne sont pas seulement des
 balcons: la partie intérieure en rez de chaussée fait partie de la voirie
 publique pour former son trottoir, ou une partie essentielle, couverte par
 le bâtiment en surplomb (et il n'y a pas non plus forcément de poteaux de
 soutien posé entre ce trottoir couvert et la partie découverte de la rue,
 car le surplomb a son plancher suspendu au dessus et ne repose pas sur son
 extrémité mais sur des porteurs à l'intérieur).


 D'ailleurs ça me parait plus logique si le building englobant est une
 relation plutôt qu'un way mais d'après la page Wiki (
 http://wiki.openstreetmap.org/wiki/Key:building:part) ça peut être une
 relation OU un way.


 Avec une relation effectivement, on peut regrouper les différentes parties
 car ce regroupement n'est pas simple dès que ce n'est plus une simple tour
 ou pyarmide, dont la base a le plus large périmètre.

 ___
 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