Re: [OSM-talk-fr] Osmose: Intégration de panneaux depuis Mapillary
Le peu que j'ai regardé me semble perfectible... 1) des détections d'objets erronée de mapillary, exemples: - des croisillons pris pour des panneaux de rond-point: http://osmose.openstreetmap.fr/fr/error/18327337729 - un numéro de ligne de bus (80) pris pour une limitation de vitesse - limite de hauteur inexistante: http://osmose.openstreetmap.fr/fr/error/18327336524 2) des objets détectés très loin dans l'image mais géoréférencé à l'emplacement de l'image (au moins 50m de distance)... étonnant car des images plus proches montrent aussi ce panneau Si une info sur la taille du panneau dans l'image est dispo (où sa position et donc la distance à la photo), je pense qu'il faudrait cherche à en tirer parti... 3) des rapprochements non faits par osmose, exemple: http://osmose.openstreetmap.fr/fr/error/18327336651 : le max_height est bien à proximité, sur l'emprise du parking Des maxspeed=30 non détectés sur les passages protégés (le tag n'est pas sur le way, mais sur le noeud du passage protégé). Perfectible, mais prometteur ! Le 20 juin 2018 à 13:26, Frédéric Rodrigo a écrit : > Bonjour, > > Un nouveau type d'intégration de données est disponible dans Osmose. > > Il s’agit d'utiliser les panneaux détectés dans les photo Mapillary pour > les comparer aux tags dans OSM et détecter quand un panneau n'a pas > d'application sur les voies. On chercher les tags des effets du panneau et > pas le cartographie du panneau lui même. > > C'est pour l’instant disponible à titre expérimental sur l'Île-de-France, > mais c'est possible de le généralisé. > > Pour l'instant le plus gros problème connu sont les panneaux qui ne > prennent pas effet sur place (restriction dans 1km) ou partiellement > (limite pour les poids lourds). > > http://osmose.openstreetmap.fr/fr/map/#zoom=10=49.1201; > lon=2.363=8300=1%2C2%2C3 > > Je suis preneur de vos retours. > > Frédéric. > > > > ___ > 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
Re: [OSM-talk-fr] Base nationale des limitations de vitesse... Retard annoncé.
Les primary de l'Yonne ont toutes leur lanes=* + lanes:forward/backward
quand nécessaire ainsi que des turn:lanes... :)
Bilan: utile à renseigner sur les grands axes car sur les secondary je n'ai
pas trouvé de cas de 3 voies hors agglo.
Voilà la requête overpass que j'ai utilisé pour sortir les way à compléter :
[out:xml][timeout:300];
// on cherche dans cette zone
{{geocodeArea:Ain}}->.searchArea;
// uniquement les primary sans tag lanes=*
way["highway"="primary"][lanes!~'.*'](area.searchArea)->.ways;
// sortie des way
.ways out meta;
// sortie des noeuds les composant
.ways >; out meta;
// sortie des relations dont elles sont membre (pour ne pas les casser à
l'édition quand on les coupe)
rel(bw.ways); out meta;
Le 17 juin 2018 à 17:18, a écrit :
> Le 17/06/2018 à 10:29, Rpnpif - rpn...@trob.eu a écrit :
>
> Bonjour,
>
> Le 17 juin 2018, Christian Quest a écrit :
>
>
> Le passage à 80km/h ne s'applique donc pas sur les routes comportant au
> moins 3 voies... j'ai bien fait d'ajouter des lanes=*
> lanes:forward/lanes:backward sur les primary/secondary ces derniers temps !
>
> Pour le côté deux voies seulement, 80 km/h dans l'autre sens (sauf
> séparateur central).
> Jean-Yvon
>
>
> ___
> 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
Re: [OSM-talk-fr] Base nationale des limitations de vitesse... Retard annoncé.
Le passage à 80km/h ne s'applique donc pas sur les routes comportant au moins 3 voies... j'ai bien fait d'ajouter des lanes=* lanes:forward/lanes:backward sur les primary/secondary ces derniers temps ! ça va quand même être un beau bazar car la signalisation ne correspondra pas au code de la route avant un certain temps... Le 17 juin 2018 à 08:40, Axelos a écrit : > Le texte a été publié, applicable à partir du premier juillet 2018. > > https://www.legifrance.gouv.fr/affichTexte.do?cidTexte= > JORFTEXT37076517 > > On notera qu'il n'y a aucune référence aux "réseaux secondaires". Cette > ambiguïté que j'avais soulignée dans un ancien message que je ne > retrouve pas, n'est plus. > > Axel. > > ___ > 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
Re: [OSM-talk-fr] Maps.me et autres contributions grand public
Le 14 juin 2018 à 07:13, Cyrille37 OSM a écrit : > Bonjour, > > Avec les applications grand public comme Maps.me il va falloir si faire au > manque de précision et aux doublons, c'est inévitable. Soit il faut une > formation préalable et interdire la contribution à ce genre d'outil, soit > les contributeurs "avancés" développent des techniques et outils pour > passer derrière les contributions "grand public". > > Perso, je suis pour la contribution grand public mais les outils comme > Maps.me qui ne devrait créer que des notes et pas directement des données. > Voire ne permettre des contributions directes que si tu as plus de NN changesets à ton actif et pas tous avec l'appli utilisée ;) -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Blocage de contributeur
Après deux jours et pas d'amélioration... j'ai fait les corrections, on ne va pas laisser la base se pourrir petit à petit ainsi. Nouveau blocage plus long ? Un blocage par IP est-il possible (si c'est la même IP qui est utilisée) ? Le 13 juin 2018 à 15:37, Thomas Ruchin a écrit : > Salut John, > > Tu es vraiment en contact avec RB94 > <https://www.openstreetmap.org/user/RB94> ? Parce que notre ami continue > ses modification douteuses (il confond généralement nom et descriptions), > n'a strictement rien corrigé de ses anciennes contributions et ne répond > pas lorsqu'un changeset est commenté ? > Pour rappel, les données notamment transports sont très utilisées par des > applications extérieures, donc cela cause un dommage certain au sérieux et > à la fiabilité d'OSM. > > Franchement, on attend vraiment qu'il ait pollué toute la base pour agir ? > Pour ce genre de contributeur, il faudrait proposer 6 mois de pratique > dans un bac à sable... > > [Marc marc, avant de demander plus d'éléments, je t'invite à faire par > toi même un tour détaillé dans les contributions de RB94 ;)] > > Thomas > > Le lun. 11 juin 2018 à 19:44, Johnparis a écrit : > >> RB94 m'a repondu par l'affirmative. >> >> Merci de ne pas le bloquer pour le moment. Nous allons commencer par ses >> changements les plus recents. >> >> >> >> >> >> >> 2018-06-11 19:36 GMT+02:00 : >> >>> Comme dit par Christian, on a été nombreux à lui tendre la main. >>> En réponse un doigt d'honneur. >>> >>> Par exemple (anecdotique) je lui demandais de mieux préciser dans les >>> changeset ce qu'il faisait. >>> >>> Maintenant le commentaire systématique c'est "J'ai fait quelque >>> modifications bien précisés". >>> >>> Donc oui Johnparis, bon comportement de ta part mais sans vouloir te >>> décevoir, tu n'es pas le premier à essayer. >>> > tu as un exemple d'objet oü le revert précédent a oublié d'annuler un >>> des modifs incorrecte ? >>> Guillaume avait posté toute une liste sur la liste : >>> https://etherpad.net/p/revertparis >>> >>> Guillaume, alors que tu as bloqué RB94, il recommence sans tenir compte. >>> https://www.openstreetmap.org/user/RB94/blocks >>> Du coup je propose un blocage plus long et par IP. >>> >>> Donat, la procédure c'est essayer de faire changer la pratique en >>> commentant des changeset et en désespoir de cause de contacter >>> d...@osmfoundation.org (ici aussi Guillaume car il a plusieurs qualités >>> : inscrit sur cette liste, francophone, membre du DWG et il a aussi annulé >>> des modifs de RB et bloqué au nom du DGW, ce qui fait beaucoup pour un seul >>> homme et c'est tant mieux !). >>> >>> Jean-Yvon >>> >>> Message transféré >>> Sujet : blocking RB94 >>> Date : Tue, 5 Jun 2018 16:49:44 +0200 >>> Pour : d...@osmfoundation.org >>> Copie à : Thomas Ruchin , >>> Guillaume Rischard , >>> Noémie Lehuby >>> >>> Rayan Belhir is now using a third account, modifying wildly station >>> names as he has done before. >>> >>> More efficient methods (ID-address, editor, locale...) may be needed! >>> >>> Thanks in advance. >>> >>> Jean-Yvon >>> >>> >>> >>> >>> Le 11/06/2018 à 15:59, Christian Quest - cqu...@openstreetmap.fr a >>> écrit : >>> >>> Il me semble que nous avons été nombreux à le joindre en tendant la main. >>> >>> Quand un contributeur persiste, s'ouvre une second puis un troisième >>> compte pour continuer à contribuer malgré les blocages du DWG, on peut >>> difficilement parler de bonne foi. >>> >>> Ce genre de situation est bien regrettable, heureusement que ça n'arrive >>> pas souvent. >>> >>> Le 11/06/2018 à 14:14, Johnparis a écrit : >>> >>> Je lui ai écris, en offrant de revoir ses contributions et montrer les >>> reglements, des listes de diffusion, etc. On verra. Je pense qu'il essaie >>> en bonne foi d'ameliorer l'OSM, mais en vain. >>> >>> 2018-06-11 11:59 GMT+02:00 Donat ROBAUX : >>> >>>> Bonjour, >>>> >>>> Je viens de lui envoyer un com de changeset bien senti! >>>> Je ne connais pas les procédures du DWG, mais il serait bon que le >>>> blocage soit définitif non pas sur son compte mais sur son adresse ip, >>>> histoire qu'on entende plus parler de lui.
Re: [OSM-talk-fr] Blocage de contributeur
Il me semble que nous avons été nombreux à le joindre en tendant la main.
Quand un contributeur persiste, s'ouvre une second puis un troisième
compte pour continuer à contribuer malgré les blocages du DWG, on peut
difficilement parler de bonne foi.
Ce genre de situation est bien regrettable, heureusement que ça n'arrive
pas souvent.
Le 11/06/2018 à 14:14, Johnparis a écrit :
Je lui ai écris, en offrant de revoir ses contributions et montrer les
reglements, des listes de diffusion, etc. On verra. Je pense qu'il
essaie en bonne foi d'ameliorer l'OSM, mais en vain.
2018-06-11 11:59 GMT+02:00 Donat ROBAUX <mailto:dona...@gmail.com>>:
Bonjour,
Je viens de lui envoyer un com de changeset bien senti!
Je ne connais pas les procédures du DWG, mais il serait bon que le
blocage soit définitif non pas sur son compte mais sur son adresse
ip, histoire qu'on entende plus parler de lui.
Vos avis?
Donat
-- Forwarded message --
From: Thomas Ruchin mailto:truchi...@gmail.com>>
To: talk-fr@openstreetmap.org
<mailto:talk-fr@openstreetmap.org>, Guillaume Rischard
mailto:openstreet...@stereo.lu>>
Cc:
Bcc:
Date: Mon, 11 Jun 2018 11:29:40 +0200
Subject: Re: [OSM-talk-fr] Blocage de contributeur
Bonjour,
Il continue :
https://www.openstreetmap.org/user/RB94
<https://www.openstreetmap.org/user/RB94>.
Exemple : https://www.openstreetmap.org/node/2799009880
<https://www.openstreetmap.org/node/2799009880>
Par ailleurs, le problème sur ses modifications des semaines
passées est que malgré le passage de plusieurs contributeurs
chevronnées (Christian, Donat, Noémie, Jean-Yvon,
Guillaume,...) certains jeux de données sont encore pollués
par des éléments qui ne correspondent pas aux règles OSM. Par
exemple, dans les nommages de voies ferrées ou dans les
schémas de relations de transport.
Que fait on ?
Thomas
Le mer. 6 juin 2018 à 00:28, Johnparis mailto:ok...@johnfreed.com>> a écrit :
Verifié, j'espère.
2018-06-05 19:21 GMT+02:00 Guillaume Rischard
mailto:openstreet...@stereo.lu>>:
Bonjour,
Est-ce que la communauté locale peut vérifier ces
objets que je n’ai pas pu annuler?
https://etherpad.net/p/revertparis
<https://etherpad.net/p/revertparis>
J’ai en tout cas bloqué RB94.
Guillaume, pour le Data Working Group
On 5 Jun 2018, at 16:03, Thomas Ruchin
mailto:truchi...@gmail.com>> wrote:
Bonjour
Notre nouvel ami s'appelle RB94
<https://www.openstreetmap.org/user/RB94>
Merci par avance pour l'action du DWG
Thomas
Le 28 mai 2018 à 21:44, Jérôme Seigneuret
mailto:jerome.seigneu...@gmail.com>> a écrit :
J'ai bien envie de te dire que les deux sont liés
surtout dans ce cas vu que c'est un contributeur
via plusieurs comptes qui vandalise des données ;-)
Le 28 mai 2018 à 20:22,
mailto:osm.sanspourr...@spamgourmet.com>> a écrit :
OSMCha :
https://osmcha.mapbox.com/filters?aoi=88f846df-d53b-4305-b91a-eb8b06d5c304
<https://osmcha.mapbox.com/filters?aoi=88f846df-d53b-4305-b91a-eb8b06d5c304>
Là on s'intéresse au contributeur, pas au
contenu mais on peut ajouter des filtres sur
le contenu.
Le 28/05/2018 à 12:36, Christian Quest -
cqu...@openstreetmap.fr
<mailto:cqu...@openstreetmap.fr> a écrit :
Overpass...
[out:xml][timeout:60];
// gather results
(
// query part for: “railway=station”
node["railway"="station"][name~'RATP']({{bbox}});
way["railway"="station"][name~'RATP']({{bbox}});
node["public_transport"="stop_position"][name~'RATP']({{bbox}});
way["public_transport"="stop_position"][name~'RATP']({{bbox}});
);
// print results
out meta;>;out meta;
Je viens de refaire un peu de nettoyage,
certaines stations / arrêts étaient encore
Re: [OSM-talk-fr] Données personnelles, professionnels de, santé et plaques en domaine public
Le 07/06/2018 à 14:10, Guillaume Adrets a écrit : Merci à tous pour vos contributions précieuses. Si je synthétise ce qui s'est dit au printemps 2017 et sur cette dernière discussion je vois les éléments suivants : *1. Légalement a-t-on en France le droit d'intégrer les nom, prénom, téléphone, mail de professionels libéraux dans OSM si ces éléments sont présents sur une plaque dans l'espace public / si ils ne sont pas présents ?* La réponse n'est pas clairement établie, chacun d'entre vous a des positions qui peuvent se justifier, la logique des déclarations CNIL est aujourd'hui obsolète avec le RGPD. Je propose donc d'envoyer au titre de l'Adrets une demande de conseil à la CNIL pour trancher, si l'association OSM France ou certains d'entre vous veulent se joindre à moi pour constituer cette demande c'est avec plaisir, merci de me contacter en direct sur mon mail. Mouais... boite de pandore en vue On a toujours considéré que la base étant gérée en Angleterre, la CNIL n'était pas le bon interlocuteur. *2. Y-a-t-il un cas spécifique de certaines professions réglementées comme les médecins liée à une interdiction de publicité qui impliquerait des dispositions spécifiques dans OSM ?* Là aussi la réponse n'est pas complètement claire. Je propose là encore de demander un avis à la CNIL (cf ci-dessus) / l'Ordre des médecins des départements avec lesquels nous Adrets travaillons (probablement a minima 04 et 73). Cette question ne concerne pas la CNIL, mais bien l'ordre des médecins. *3. Y-a-t-il un intérêt à intégrer ces éléments dans OSM ? A savoir notamment OSM a-t-il vocation à devenir un annuaire ?* Cela a été soulevé dans la discussion de 2017 par Christian Quest. Pour moi OSM est aujourd'hui une formidable base de données libre et transverse sur le champ des services de manière générale. Si quelqu'un a connaissance d'une base libre, équivalente et à jour sur les services de santé (l'annuaire Ameli ou celui de l'ordre des médecins n'étant pas en opendata, FINESS référence les établissements de santé mais pas les professionnels eux-mêmes), mais plus largement sur la question des services incluant notamment les commerces et autres, je suis preneur! Donc pour moi OSM a bien le potentiel pour devenir la base de données source d'annuaires locaux géolocalisés (cf. prototype d'annuaire allant taper directement dans OSM via Overpass http://cartosante.xsalto.com/directory.php) et est complètement adapté pour proposer une démarche intégrale à un petit territoire pour qu'il soit en capacité de renseigner lui-même les services présents, faire contribuer la population et disposer d'outils de rendu cartographiques certes mais aussi sous forme d'annuaire. L'annuaire AMELI est en opendata depuis avril dernier: https://www.data.gouv.fr/fr/datasets/annuaire-sante-de-la-cnam/ Donc de mon point de vue, globalement si on cherche un médecin bien précis, c'est à cet annuaire voire aux pages jaunes qu'il faut s'adresser... il y a de fortes chances qu'OSM restera incomplet et pas forcément aussi à jour que ces annuaires. Dans un domaine comme le médical où une notion d'urgence vitale peut entrer en jeu, une source officielle de données reste quand même préférable (sauf si elle est vraiment très mauvaise bien entendu et qu'on peut faire nettement mieux). Là où à mon avis OSM est utile, c'est pour trouver un médecin proche, par la géographie et pas par son nom (que personnellement je ne met pas dans OSM pour cette raison et pour être CNIL-compatible)... et lier nos amenity=doctor avec un ref=* d'AMELI doit permettre aussi de vérifier qu'on est à peu près synchro. -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Décalage de données OSM
Le 7 juin 2018 à 11:21, Pierre Jarnet a écrit : > Merci pour la réponse, > > C'est ce que je me disais pour le cadastre, étant donné que les > constructions les plus récentes colle parfaitement avec l'ortho IGN mais > les anciennes pas du tout… > Fadrait-il que je décale toutes les données OSM pour coller à l'ortho > IGN alors ? > C'est effectivement plutôt ça qu'il faut faire en général et surtout quand les traces GPS confirme que l'ortho est correcte. En zone montagneuse (pas vraiment le cas en Bretagne), l'ortho peut être moins bonne... ça se vérifie avec les traces GPS. -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [sotmfr] Open Traffic
Est-ce que des données historiques sur les incidents passés serait utiles ? J'ai pas mal d'archive dans OpenEventDatabase... et plus encore, scrappé, mais pas intégré à la base. Ce ne serait que statistique, mais sûrement utile pour définir un profil moyen par tronçon. Le 4 juin 2018 à 22:19, Frédéric Rodrigo a écrit : > Bonsoir, > > Lors du SotM-FR de ce weekend j'ai voulu lancer un échange sur le manque > de données trafic libres et comment ou pourrait essayer d'y remédier avec > le projet Open Traffic. > > https://www.slideshare.net/FredericRodrigo/open-traffic > > https://twitter.com/fre2d/status/1003551946823946241 > > Le constant est qu'aujourd'hui les données de trafic sont aux mains de > quelques acteurs privés et que les collectivités diffusent peu ou mal ces > informations. En France on ne trouve que Paris et Bordeaux Métropole qui > font de l'OpenData. Ils utilisent des capteurs statiques et donc uniquement > sur les grands axes. > > L'idée serait donc de tous participer, individuellement, en tant > qu'entreprise ou collectivité avec des moyens et des méthodes diverses à > collecter de l’information pour l'agréger et produire de l'information > trafic libre. > > Il existe déjà une solution technique pour ça, c'est Open Traffic > > http://opentraffic.io/ > > https://github.com/opentraffic/otv2-platform > > Les échanges qui ont eut lieu ont montré clairement une attente et un > intérêt pour un tel projet. > > Une liste de diffusion a donc été créée pour rassembler du mon sur le > sujet : > > https://listes.openstreetmap.fr/wws/info/opentraffic > > > Frédéric. > > > > ___ > 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
Re: [OSM-talk-fr] Ce que vous avez manqué au SOTM-FR...
Les différents canaux de communication sont en effet plus ou moins geek ! Je les classe comme ça: - irc - mailing-list (utilisable via Nabble... et donc proche d'un forum) - forum (phpBB) - facebook (et oui, il y a aussi une page facebook, mais très très calme) On a clairement des publics différents sur chacun et des usages différents. C'est complémentaire. On avait un temps envisagé une solution comme Discourse, pour remplacer phpBB et permettre un usage plutôt bien fait par mail... Le 4 juin 2018 à 18:47, marc marc a écrit : > Le 04. 06. 18 à 18:05, deuzeffe a écrit : > > Le 04/06/2018 à 17:54, Noémie Lehuby a écrit : > >> Le 2018-06-04 13:49, deuzeffe a écrit : > >>> Sur https://next.openstreetmap.fr/contribuer/ ont disparu ML et canal > >>> IRC : c'est volontaire ? > >> > >> c'est une réécriture from scratch donc on ne peut pas vraiment dire > >> que la disparition de canaux de communication soit volontaire. > >> Mais le site est plutôt pensé pour le débutant qui ne connait pas > >> encore OSM. Est-ce que la ML et IRC sont vraiment adaptés pour ce type > >> d'utilisateurs ? > > > > La ML, peut-être pas (mais c'est dommage de la passer sous silence). > > je crois que c'est vraiment une question de préférence personnelle. > certains préfèrent une interface web, certain l'interface de leur client > email habituel. > > dans un monde idéal l'interface web et l'interface mail devraient > pointer vers un endroit commun (il me semble qu'on avait parlé il y a > plusieurs mois d'avoir une interface comme nabble qui permet cette > convergence) > > > En revanche, le canal IRC, oui, il y a des débutants en OSM > > je crois à nouveau que c'est 2 besoins très différents. > l'irc pour une communication "instantanée" (même si on fait aussi de > l'asynchrone vu nos emplois du temps respectif :) > où parfois la réponse prend moins de temps à écrire que la réponse. > tandis que le forum ou la ml convient à mes yeux + pour une question > nécessitant + de temps à poser et à répondre. > > PS : le catcha du forum *** tellement que j'ai jamais pu m'y inscrire. > ___ > 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
[OSM-talk-fr] Ce que vous avez manqué au SOTM-FR...
Un petit fil de discussion pour partager à compléter par tous ! - la preview de la prochaine version du site web: https://next.openstreetmap.fr - une instance peertube pour (auto)héberger nos vidéos: https://peertube.openstreetmap.fr avec les vidéos du SOTMFR 2018 déjà disponibles ! et bien entendu tout l'immatériel... les contacts, les discussions, l'ambiance, les projets qu'on lance, les rêves... -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Article sur "Le Monde.fr"
Nous sommes donc complices d'un projet présenté comme généreux qui ne vise qu'à faire bosser des milliers de gens gratuitement ! C'est d'une bêtise consternante (en considérant une bien mauvaise information de ce commentateur) ou d'une malveillance répugnante. Ce commentaire me rappelle ce qu'on pouvait lire fin 2014 sur le blog de la section CGT de l'IGN: "la frontière entre la liberté du collaboratif et l’ultralibéralisme est ténue": https://cgtgeo.wordpress.com/2014/09/25/la-base-adresse-de-lign-en-danger/ PS: je ne ferai aucun commentaire sur l'étonnant choix cartographique de ce blog... Le 4 juin 2018 à 09:47, a écrit : > > > - Mail original - > De: "Cyrille DERORY" > Objet: [OSM-talk-fr] Article sur "Le Monde.fr" > > > https://www.lemonde.fr/chronique-des-communs/article/ > 2018/06/01/hausse-des-tarifs-de-google-maps-on-a-plus-que- > jamais-besoin-d-alternatives-libres_5307968_5049504.html > > D ailleurs si quelqu un qui a un compte sur le monde pouvait enfoncer le > clou sur "Christian Quest ennemi de l IGN et OSM=Uber fait travailler les > gens gratuitement" en precisant par exemple que l IGN c est paye par nos > impots et qu on doit quand meme payer pour utiliser les donnees se serait > cool > > Julien > > ___ > 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
Re: [OSM-talk-fr] Oubli de mention OSM...
Premier signalement le 3 avril... j'ai relancé par mail sur le formulaire de contact. Le 28 mai 2018 à 13:52, HELFER Denis (SNCF RESEAU / SIEGE SNCF RESEAU / DT GE APPUI PERFORMANCE) <denis.hel...@reseau.sncf.fr> a écrit : > Et ça, c’est pire encore : https://lannuaire.service- > public.fr/grand-est/ardennes/mairie-08338-01 > > Pourtant signalé il y a près de 15 jours ….. > > > > Pauvres de nous si on doit surveiller même les sites institutionnels > > > > *De :* Christian Quest [mailto:cqu...@openstreetmap.fr] > *Envoyé :* lundi 28 mai 2018 12:40 > *À :* Discussions sur OSM en français <talk-fr@openstreetmap.org> > *Objet :* Re: [OSM-talk-fr] Oubli de mention OSM... > > > > Voilà: https://twitter.com/cq94/status/1001050318669479937 > > > > Le 28 mai 2018 à 11:47, Cédric Frayssinet <lis...@frayssinet.org> a écrit > : > > sur le site en vogue du moment : http://statistique.parcoursup.fr/ > > Si quelqu'un peut le signaler... > > Merci, Cédric > > > ___ > Talk-fr mailing list > Talk-fr@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-fr > > > > > -- > > Christian Quest - OpenStreetMap France > > --- > Ce message et toutes les pièces jointes sont établis à l'intention > exclusive de ses destinataires et sont confidentiels. L'intégrité de ce > message n'étant pas assurée sur Internet, la SNCF ne peut être tenue > responsable des altérations qui pourraient se produire sur son contenu. > Toute publication, utilisation, reproduction, ou diffusion, même partielle, > non autorisée préalablement par la SNCF, est strictement interdite. Si vous > n'êtes pas le destinataire de ce message, merci d'en avertir immédiatement > l'expéditeur et de le détruire. > --- > This message and any attachments are intended solely for the addressees > and are confidential. SNCF may not be held responsible for their contents > whose accuracy and completeness cannot be guaranteed over the Internet. > Unauthorized use, disclosure, distribution, copying, or any part thereof is > strictly prohibited. If you are not the intended recipient of this message, > please notify the sender immediately and delete it. > > ___ > 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
Re: [OSM-talk-fr] Oubli de mention OSM...
Voilà: https://twitter.com/cq94/status/1001050318669479937 Le 28 mai 2018 à 11:47, Cédric Frayssinet <lis...@frayssinet.org> a écrit : > sur le site en vogue du moment : http://statistique.parcoursup.fr/ > > Si quelqu'un peut le signaler... > > Merci, Cédric > > ___ > 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
Re: [OSM-talk-fr] Blocage de contributeur
Overpass...
[out:xml][timeout:60];
// gather results
(
// query part for: “railway=station”
node["railway"="station"][name~'RATP']({{bbox}});
way["railway"="station"][name~'RATP']({{bbox}});
node["public_transport"="stop_position"][name~'RATP']({{bbox}});
way["public_transport"="stop_position"][name~'RATP']({{bbox}});
);
// print results
out meta;>;out meta;
Je viens de refaire un peu de nettoyage, certaines stations / arrêts
étaient encore incorrects.
Le 28 mai 2018 à 11:26, Jean-Claude Repetto <jrepe...@free.fr> a écrit :
> Le 28/05/2018 à 10:35, Jérôme Seigneuret a écrit :
> > Bonjour,
> > On n'a pas la possibilité de faire des surveillance sur des zones ou des
> > objets pour voir si des modifications ont été établies.
> > Il me semble que l'on peut faire ça sous JOSM.
> >
> > Si le problème est localisé et vu ton implication Guillaume, ça vaudrait
> > le coût que tu puisses faire ce contrôle qualité sur ton territoire. Ce
> > que tu fais déjà en mode graphique depuis la carte.
> >
> > A+ Bonne Journée
> >
>
> Il y a l'outil SODA, développé par Julien Thévenon, qui permet de faire ça:
> http://thevenon.julien.free.fr/soda/presentations/Soda_
> SOTM-Fr_2013_02_24.pdf
>
> Jean-Claude
>
>
> ___
> 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
Re: [OSM-talk-fr] Vue satellite sur Osm ?
Le 23 mai 2018 à 22:24, Vincent Frison <vincent.fri...@gmail.com> a écrit : > 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/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... > > Oui, c'est subtil, de l'opendata... contraint ;) Quand on regarde les nouvelles données ouvertes par l'IGN ces derniers temps, c'est uniquement ça. La couche hydro de la BD Topo c'est aussi grâce à l'Europe. Bon ceci dit ça fait quand même un paquet de départements déjà dispo à 50 > cm ! > Ou mieux que 50cm... l'ortho HR ;) En fait la BD Ortho c'est un nivellement par le bas à 50cm... pour qu'il y ait un traitement égal de tout le territoire. 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... > > Je sais que le 94 est en cours de prise de vue si c'est pas déjà fait et que ça sera ouvert aussi. Possible que toute la petit couronne soit en 5cm grâce au Grand Paris. -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Vue satellite sur Osm ?
Oui, c'est la version "BD Ortho" à 50 cm issue de l'orthohr qui est peut aller à 20 voire 10cm ou plus cofinancée par les collectivité et/ou l'Europe et ça ne couvre que la moitié des départements et qui est ici: http://professionnels.ign.fr/orthohr-par-departements#tab-3 Le 23 mai 2018 à 18:42, Vincent Frison <vincent.fri...@gmail.com> a écrit : > 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/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. >> >> 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 > > -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Vue satellite sur Osm ?
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
Re: [OSM-talk-fr] OSM : afficher noms en alphabet latin ?
Quelques pistes postgres pour gérer la translitération... http://blog.gegg.us/2013/09/ et https://github.com/forrest79/PgSQL-TransliterateUTF8ToAscii Le premier permet de détecter quelles sont les names:xx en latin... chose qui me manquait pour le rendu FR. Le second permet de ne faire la translitération que pour les noms où l'on a aucune version en alphabet latin dans les données OSM. Ceci permettrait d'améliorer au moins le rendu FR. Le 22/05/2018 à 14:39, osm.sanspourr...@spamgourmet.com a écrit : Allez, 10 secondes et hop on retrouve le lien sur le Wiki : https://wiki.openstreetmap.org/wiki/Names#Avoid_transliteration N.B. : Christian, avec Terressa on peut avoir à la fois un rendu chiadé Mapnik/CartoCSS par exemple pour faire un rendu muet côté serveur et des tuiles MVT pour passer les noms. N. B. 2 : comme certains icônes sont assez nationaux (culturels) comme le Bretzel allemand remplacé par la miche de pain française pour indiquer une boulangerie, il faudrait peut-être aussi ne pas rendre d'icônes sur la carte muette mais donner juste en MVT des points géolocalisés avec attributs pour rendre les POI... ou a minima des lignes pour les routes et les grandes surfaces - les surfaces qui sont importanes, pas les GMS. N.B. 3 : si on prend une seule base, si on veut les données d'un style mapnik en mvt il suffit avec Tessera/TileLive de passer de mapnik: au protocole mvt:. Avoir les deux (au choix donc) c'est donc une ligne de configuration de plus côté serveur... et de l'huile de coude côté client. N.B. 4 : si tu ne veux pas passer les infos dans toutes les langues mais seulement dans les langues intéressantes, tu vas aussi avoir le droit de faire un feuille de style par langue en MVT (mais vu le nombre d'endroits nommés avec seulement name, la surcharge doit être faible, <10 %). Jean-Yvon *Gesendet:* Dienstag, 22. Mai 2018 um 05:29 Uhr *Von:* "osm.sanspourr...@spamgourmet.com" <osm.sanspourriel.8736e6a903.osm.sanspourriel#talk-fr@openstreetmap.org> *An:* talk-fr@openstreetmap.org *Betreff:* Re: [OSM-talk-fr] OSM : afficher noms en alphabet latin ? C'est ce que fais le rendu allemand par translittération s'il n'y a pas de version allemande. Dit de mémoire, je n'ai pas le PC sur lequel j'avais vu les scripts postgres qui font ça. Jean-Yvon > Gesendet: Montag, 21. Mai 2018 um 22:01 Uhr > Von: "Shohreh - codecompl...@free.fr" <osm.sanspourriel.84e4aea303.codecomplete#talk-fr@openstreetmap.org> > An: talk-fr@openstreetmap.org > Betreff: [OSM-talk-fr] OSM : afficher noms en alphabet latin ? > > Bonjour, > > Pour les pays qui utilisent un autre système d'écriture, y a-t-il un moyen > qu'OSM affiche également les noms en alphabet latin ? > > https://postimg.cc/image/ry6hpyxs7/ > > Merci. > > > > -- > 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 ___ 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
Re: [OSM-talk-fr] OSM : afficher noms en alphabet latin ?
Pas hyper simple en raster... il faut faire plein de rendus différents avec les noms éventuellement avec un fond neutre + les libellés par dessus. En vectoriel c'est nettement plus simple. 2018-05-21 22:33 GMT+02:00 Vincent Privat <vincent.pri...@gmail.com>: > Aucune idée, je ne faisais que remonter les infos dont j'avais > connaissance :) > > Le 21 mai 2018 à 22:29, Shohreh <codecompl...@free.fr> a écrit : > >> Vincent Privat wrote >> > C'est dans le "top ten tasks", ya des infos par ici: >> > https://wiki.openstreetmap.org/wiki/Top_Ten_Tasks#Localized_ >> map_rendering >> >> Merci. C'est très difficile à faire ? >> >> >> >> -- >> 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 > > -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] OSM : afficher noms en alphabet latin ?
Le rendu FR affichera un nom en français partout où il le peut... https://demo.addok.xyz/#6/23.795/40.518 2018-05-21 22:01 GMT+02:00 Shohreh <codecompl...@free.fr>: > Bonjour, > > Pour les pays qui utilisent un autre système d'écriture, y a-t-il un moyen > qu'OSM affiche également les noms en alphabet latin ? > > https://postimg.cc/image/ry6hpyxs7/ > > Merci. > > > > -- > 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 > -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Rendu osmfr en retard > 24h
Par endroit peut être... il y a des caches entre toi et le serveur de rendu, mais je viens de regarder des modifs faites il y a moins de 24h, et elles sont bien visibles :) 2018-05-21 16:07 GMT+02:00 Cyrille37 OSM <cyrille+talk...@giquello.fr>: > Hello > > Avez-vous remarqué que le rendu osmfr sur http://tile.openstreetmap.fr a > plus de 24h de retard ? > > Merci > Cyrille37. > > > ___ > 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
Re: [OSM-talk-fr] sauvegarde des photos versées sur Mapillary
Le 19 mai 2018 à 00:34, marc marc <marc_marc_...@hotmail.com> a écrit : > techniquement faire une sauvegarde en ligne disponible pour récolter > toutes les images de France, c'est assez facile. > yaka acheter X disque 2 To et permettre un transfert scp ou autre. > le seul point bloquant c'est le coût. > acheter les disques et payer la redevance mensuelle éventuelle pour un > serveur ou avoir la place dans une baie qui-va-bien > > je me demande combien de gens sont intéressés et surtout le volume des > photos et le financement que les personnes sont prêtes à y consacrer. > > Justement... ce n'est pas à chacun, individuellement de faire cet effort, mais plutôt l'organiser collectivement. Si, dans un premier temps, on est juste dans une logique d'archivage... on remplit un disque, puis on le range (pas besoin qu'il soit accessible en permanence tant que le service est assuré par X ou Y), et on le remplace par un nouveau disque à remplir... Pour la source des photos, je pensais la semaine passé à la puissance > que cela apporterait d'avoir un smartphone sur chaque bus ou sur chaque > Autolib (avec un bout de code qui coupe l'enregistrement en dessous de x > km/h histoire d'éviter de capturer des espaces privés) > > Chaque camion de ramassage d'ordures... là tu as presque tout et avec une fréquence assez inégalable ;) Le vrai problème est l'utilisation. > Si le 2ieme but est de vouloir faire un mappilary souverain > pour paraphraser Christian, se pose tout de suite le problème législatif > (flouter les personnes et infos personnelles, gérer les faux positifs et > les oublis et là c'est l'horreur) > Et la montée en compétence (par exemple sur opencv) est nécessaire pour rester à terme indépendants... Pour démarrer, archiver les images me semble un préalable pour avoir la matière première sur laquelle travailler. Un chouette sujet à approfondir autour d'un verre dans 2 semaines ;) -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Quand Géoportail/IGN fait un "tuto" pour la mesure des parcelles cadastrales...
Toute la différence entre de la com et un vrai service utile... là c'est clairement juste de la com avec un exemple fort mal choisit. Sans même parler des choix de Facebook et Youtube ;) Le 17 mai 2018 à 19:55, PierreV <belett...@hotmail.fr> a écrit : > c'est vraiment navrant de voir que l'IGN est "à la ramasse" pour certains > de > ses outils... et en plus ils en ont fier! Tellement qu'ils en font un > tutoriel vidéo (et sans son bien sur...) : > https://www.facebook.com/geoportail/videos/10157347533053709/?hc_ref= > ARRnXrzSQDhwjyC46Bs6hmwWyZjLdqqfZrGsmmTjiUsdMUwLxcmvvfONXfAo > v9RgA5w=nf > ou sur youtube : https://www.youtube.com/watch?v=rbl2sF7zugk > > alors qu'il existe un projet qui utilise les données opensource et qui > donne > la même chose bien plus précisément et surtout en un seul clic au lieu > d'une > méthode en 20 clics sur Géoportail : > https://koumoul.com/s/cadastre/ > -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Cache des tuiles de la carte OSM.org pour la France
Il n'y en a jamais eu plus à a connaissance, il se trouve à Lyon chez Resopole, là où on a aussi le cache pour les tuiles FR et HOT... ce qui d'ailleurs n'est pas une super idée en terme de redondance. Le 17 mai 2018 à 19:36, Cyrille37 OSM <cyrille+talk...@giquello.fr> a écrit : > Hello, > > Je n’avais pas regardé depuis longtemps, mais le nombre de cache de tuiles > OSM.org a terriblement réduit, il semble qu'il n'y en ai plus que 1 pour la > France. > > https://dns.openstreetmap.org/tile.openstreetmap.org.html > > Cyrille37. > > > ___ > 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
Re: [OSM-talk-fr] sauvegarde des photos versées sur Mapillary
Pareil... j'ai conservé une très grande partie des photos envoyées vers Mapillary. Nous pouvons tous récupérer les originaux envoyés à Mapillary, ce n'est pas super simple, mais c'est faisable... écrire un petit script pour automatiser ça ne serait pas idiot surtout si ce script versait ces photos dans une archive commune. commons ne me semble pas franchement très adapté, un stockage plus dédié serait bienvenu et un sacré projet. C'est marrant car j'ai reparlé de ça autour de moi il y a très peu de temps... hier et aujourd'hui ! La question se pose pour certains services publics qui utilisent plus ou moins Google Street View alors que Mapillary ou OpenStreetCam sont encore très loin en terme de couverture. Je pense qu'il y a un peu plus de monde mûr pour lancer un tel projet dans notre hexagone pour être un peu plus souverain sur cette thématique. Le 17 mai 2018 à 19:09, Francois Gouget <fgou...@free.fr> a écrit : > On Thu, 17 May 2018, Cyrille37 OSM wrote: > > > Bonjour, > > > > Juste une question de pérennité, sans aucune paranoïa : quid du > > patrimoine versé sur Mapillary si l'entreprise venait à avoir des > > problèmes ? Ne serait-il pas intéressant de trouver un partenariat pour > > avoir une sauvegarde des photos versées ? > > OSM France ou commons.wikimedia.org ou ONU ou UNESCO ou ... ? > > Je garde une copie de mes photos au cas où mais c'est évidemment pas une > solution globale. > > Plus qu'une solution de sauvegarde mon but serait d'envoyer ces photos > sur OpenStreetCam un jour : je n'ai pas de raison de privilégier un > acteur par rapport à un autre. Mais ce n'est pas particulièrement simple > et je n'ai pas encore eu le temps de me pencher sérieusement sur le > problème. Pour l'instant ma priorité c'est les photos 360. > > Néamoins, uploader les photos sur les deux services serait un premier > pas vers plus de pérennité. > > > -- > Francois Gouget <fgou...@free.fr> http://fgouget.free.fr/ >Un western sans indien c'est comme une police sans serif. > -- John Wayne > ___ > 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
Re: [OSM-talk-fr] Mise à jour des tuiles : bug ?
Il y a plusieurs niveaux de caches (un sur le serveur de rendu... et ils sont 3, un sur les caches régionaux) et ils ne sont pas forcément tous 100% synchro. Difficile d'être à jour et partout à jour en même temps... avec des données qui elles aussi changent sans arrêt ;) Le 15/05/2018 à 11:13, marc marc a écrit : Le 15. 05. 18 à 09:48, Sylvain M a écrit : Je remarque depuis quelques semaines un comportement étrange du rafraichissement des tuiles OSM. J'ai fait quelques modifs hier, et après avoir patienté un peu, rafraichi la page, vidé mon cache, ..., parfois les tuiles étaient mises à jour, puis elle revenaient à leur précédent état... il y a une saturation et un problème : - la saturation de la fille d'attente des tuiles fait qu'une modif faite ou une demande de /dirty est dans la grande majorité des cas ignorée parce qu'il n'y a plus de place dans la fille d'attente. par conséquent il est difficile d'obtenir une maj d'une tuile, hormis en fin de soirée/nuit. le conseil totalement peu pratique est de tester après 22h pour le rendu osm.org ou de tester le rendu osm-fr qui est cependant - étoffé. - le problème : il semble y avoir une instabilité dans la répartition géographique des requête de rendu ce qui fait d'une demande de maj d'une tuile est parfois faite sur un autre serveur que celui qui est utilisé pour t'envoyer les tuiles elle-même. du coup à un moment t'as une tuile à jour et + tard tu as la version précédente provenant d'un autre serveur de rendu. J'ai cependant pas encore réussit à capturer les infos pour en faire un ticket :( Cordialement, Marc ___ 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
Re: [OSM-talk-fr] Fwd: Alerte Google : openstreetmap
Oups... et voilà une suite: https://medium.com/@cq94/tarifs-google-maps-pour-les-nuls-d47c1833c242 Le 11 mai 2018 à 23:30, <osm.sanspourr...@spamgourmet.com> a écrit : > En plus il ne dit pas qui on est. > > Mais c'est presque mieux, les gens un peu curieux vont chercher qui se > cache derrière OSM France. > > Alors Christian, on fait défiler jusqu'à l'article intéressant sans > récupérer la nouvelle adresse de base ? ;-) > > Ceci dit, j'ai eu l'occasion de faire "involontairement" une switch2osm > party chez un client. Sans parler du prix. J'ai juste montré que nôtre jeu > de données était plus complet que le leur et qu'ils pouvaient compléter le > nôtre avec le leur. > > En l'occurrence plus d'aérodromes, avec les différentes références, > langues, etc. > > Il fallait presque les calmer ;-). > > Jean-Yvon > > Le 11/05/2018 à 10:53, Noémie Lehuby - noemie.leh...@zaclys.net a écrit : > > Je pense que le bon lien est le suivant ;) > > https://www.lemondeinformatique.fr/actualites/lire-google-fait- > exploser-les-tarifs-des-api-de-maps-71697.html > > > -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Fwd: Alerte Google : openstreetmap
Le Monde Informatique parle (un peu) d'OSM ;) https://www.lemondeinformatique.fr/actualites/lire-kubernetes-des-containers-plus-isoles-des-apps-natives-mieux-gerees-71650.html -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Communauté OSM en Tunisie...
J'ai été contacté par data4tunisia pour alimenté ce portail opendata citoyen avec plus de données OpenStreetMap. Exemple: https://www.data4tunisia.org/fr/datasets/decoupage-administratif-de-la-tunisie-par-secteur-imada/ Je n'ai vraiment de contact avec la communauté tunisienne... quelqu'un sait si il y a un petit noyau bien actif à contacter ? -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Test de peertube... archives vidéos SOTM
Je teste actuellement peertube, une alternative libre, ouverte, en p2p et décentralisée aux plateformes de diffusion de vidéo comme Youtube ou Dailymotion. J'ai uploadé quelques archives vidéo d'OSM, c'est ici: https://peertube.amicale.net/videos/search?search=sotm -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] office et craft dans le rendu FR...
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
Re: [OSM-talk-fr] Paris Soirée de Contribution au Libre
Présent (en principe) ! Sur Issy les données avaient déjà été intégrées, j'ai refait une passe il y a peu. Si on reste sur cette thématique, il faudrait regarder les autres jeux de données dispo sur data.gouv.fr et évaluer leur "intégrabilité" ;) https://www.data.gouv.fr/fr/search/?q=d%C3%A9fibrillateurs Il y a plus d'une vingtaine de jeux de données disponibles... Le 24/04/2018 à 10:49, Nicolas Bétheuil a écrit : Hey, kiki viendra ? https://www.agendadulibre.org/events/16717 Je pense bosser sur les défibrillateurs de France & Navarre A partir de https://www.data.gouv.fr/fr/search/?q=defibrillateur Christian a déjà couvert Paris https://twitter.com/cq94/status/988451160272011265 J'ai ajouté Issy ce matin là https://www.mapcontrib.xyz/t/7f46aa-Defibrillateur Voir ce qu'on peut faire dessus Des avis ? ___ 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
[OSM-talk-fr] OSM sur France 3 Occitanie (en occitan)
C'est ici, premier sujet: https://france3-regions.francetvinfo.fr/occitanie/emissions/jt-local-1920-edicion-occitana -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] osmose conflit entre tag
amenity + landuse c'est ça qu'osmose n'aime pas à ce qu'il me semble. landuse + barrier, c'est assez courant, quand le landuse est délimité par une clôture (cas typique: le cimetière entouré de murs) Le 20 avril 2018 à 05:36, JB <jb...@mailoo.org> a écrit : > Je dirais : une déchèterie ou un landuse, c'est une surface. Une barrière, > un linéaire. > Mélanger les deux dans le même objet, c'est le bordel. > Après, je ne sais pas si Osmose réfléchit comme ça ou non. > JB. > > > Le 19/04/2018 à 23:12, marc marc a écrit : > >> Le 19. 04. 18 à 20:31, Marc M. a écrit : >> >>> Le 19. 04. 18 à 19:33, Philippe Verdy a écrit : >>> >>>> Pourquoi Osmose prétend un conflit avec ces tags >>>> amenity= recycling >>>> barrier= fence >>>> landuse= industrial >>>> >>> sans lien vers le rapport osmose, j'imagine que c'est parce >>> qu'il faut un objet une fonction, par conséquent >>> un objet : la barrière >>> un autre objet : la déchetterie >>> >> j'ai vérifié une déchetterie sans barrière, >> ma supposition est erronée, même soucis. >> http://www.openstreetmap.org/way/524665913 >> https://osmose.openstreetmap.fr/fr/map/#zoom=18=47.31775 >> =3.005758=1%2C2%2C3=T >> >> je ne suis pas convaincu qu'une déchetterie (un espace de collecte) >> est une industrie (un endroit qui modifie des matières) >> mais j'imagine que le problème se pose peut-être aussi avec une valeur >> de landuse plus adapté (auquel je n'ai pas réfléchi) >> Perso je virerais landuse=industrial :) >> ___ >> 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 > -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Liens vers communauté FR sur iD...
Ma PR a été commitée... donc les liens devraient prochainement être visibles dans iD, par contre ils sont en anglais et à traduire dans transifex. Un volontaire ? Le 18 avril 2018 à 14:52, PanierAvide <panierav...@riseup.net> a écrit : > Je pensais surtout aux liens vers les pages web, mais effectivement ça > dépend de ce que l'on entend par canal de communication. > > Adrien. > > > Le 18/04/2018 à 14:47, Christian Quest a écrit : > > Il me semble que ce qui est visé, ce sont les canaux de communication en > ligne et cette carte agrège plutôt les réunion physiques locales. > > Ce sont les mailing list locales qu'il faudrait ajouter ou les sections > locales de forum.openstreetmap.fr et avoir à chaque fois une géométrie > correspondante. > > Manque aussi les DOM, car la géométrie que j'ai utilisé c'est le polygone > de geofabrik pour la métropole. A améliorer donc, mais au moins on a un > début et de quoi itérer... :) > > > > Le 18/04/2018 à 09:32, PanierAvide a écrit : > > Bonjour, > > Pour éviter les doublons d'infos, on ne peut pas se baser sur la carte des > groupes locaux ? > http://umap.openstreetmap.fr/fr/map/groupes-locaux- > openstreetmap_152488#6/46.392/1.714 > > Cordialement, > > Adrien. > > Le 18/04/2018 à 09:26, Christian Quest a écrit : > > La dernière version d'iD (ou la prochaine) peut afficher des liens vers > les canaux de communication de la communauté OSM après la sauvegarde de ses > contributions. > > Ces liens dépendent de la zone où l'on a contribué et sont donc bien > adapté pour pousser les nouveaux contributeurs à se mettre en contact avec > le reste de la communauté locale. > > J'ai ajouté les liens vers les canaux d'OSM France sur le dépôt github : > > https://github.com/osmlab/osm-community-index/pull/83 > > Il est possible de descendre à un niveau encore plus local... > > Il faut quelques fichiers json: > - un geojson qui définit la zone géographique > - un json pour définir chaque lien (mailinglist, forum, twitter, etc) > > Les libellés sont à mettre en anglais... pour la traduction, je pense que > c'est dans le transiflex d'iD (pas super pratique de séparer, mais bon). > > -- > Christian Quest - OpenStreetMap France > > > ___ > Talk-fr mailing > listTalk-fr@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-fr > > > -- > PanierAvide > Géomaticien & développeur > > > > ___ > Talk-fr mailing > listTalk-fr@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-fr > > > -- > Christian Quest - OpenStreetMap France > > > > ___ > Talk-fr mailing > listTalk-fr@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-fr > > > -- > PanierAvide > Géomaticien & développeur > > > ___ > 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
Re: [OSM-talk-fr] Liens vers communauté FR sur iD...
Il me semble que ce qui est visé, ce sont les canaux de communication en ligne et cette carte agrège plutôt les réunion physiques locales. Ce sont les mailing list locales qu'il faudrait ajouter ou les sections locales de forum.openstreetmap.fr et avoir à chaque fois une géométrie correspondante. Manque aussi les DOM, car la géométrie que j'ai utilisé c'est le polygone de geofabrik pour la métropole. A améliorer donc, mais au moins on a un début et de quoi itérer... :) Le 18/04/2018 à 09:32, PanierAvide a écrit : Bonjour, Pour éviter les doublons d'infos, on ne peut pas se baser sur la carte des groupes locaux ? http://umap.openstreetmap.fr/fr/map/groupes-locaux-openstreetmap_152488#6/46.392/1.714 Cordialement, Adrien. Le 18/04/2018 à 09:26, Christian Quest a écrit : La dernière version d'iD (ou la prochaine) peut afficher des liens vers les canaux de communication de la communauté OSM après la sauvegarde de ses contributions. Ces liens dépendent de la zone où l'on a contribué et sont donc bien adapté pour pousser les nouveaux contributeurs à se mettre en contact avec le reste de la communauté locale. J'ai ajouté les liens vers les canaux d'OSM France sur le dépôt github : https://github.com/osmlab/osm-community-index/pull/83 Il est possible de descendre à un niveau encore plus local... Il faut quelques fichiers json: - un geojson qui définit la zone géographique - un json pour définir chaque lien (mailinglist, forum, twitter, etc) Les libellés sont à mettre en anglais... pour la traduction, je pense que c'est dans le transiflex d'iD (pas super pratique de séparer, mais bon). -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- PanierAvide Géomaticien & développeur ___ 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
[OSM-talk-fr] Liens vers communauté FR sur iD...
La dernière version d'iD (ou la prochaine) peut afficher des liens vers les canaux de communication de la communauté OSM après la sauvegarde de ses contributions. Ces liens dépendent de la zone où l'on a contribué et sont donc bien adapté pour pousser les nouveaux contributeurs à se mettre en contact avec le reste de la communauté locale. J'ai ajouté les liens vers les canaux d'OSM France sur le dépôt github : https://github.com/osmlab/osm-community-index/pull/83 Il est possible de descendre à un niveau encore plus local... Il faut quelques fichiers json: - un geojson qui définit la zone géographique - un json pour définir chaque lien (mailinglist, forum, twitter, etc) Les libellés sont à mettre en anglais... pour la traduction, je pense que c'est dans le transiflex d'iD (pas super pratique de séparer, mais bon). -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import station essence (NavAds)
sans plomb e10 remplace le sans plomb normal. >> >> Tu as raison la suppression de tags n'est pas géré (mais ça >> pourrait, aide bienvenue). >> >> Il y a des stations service qui ont changé de ref dans la >> la base de donnée source (je sais pas pourquoi) et des >> stations qui ont cessés d'exister et osmose ne propose pas >> de supprimer les ref qui ne représente plus des stations >> en fonctionnement. >> >> Osmose, sait le faire, mais ça n'a pas été activé pour les >> stations. >> La ref:FR:prix-carburants vous parait suffisamment stable et >> "importante" pour que ça le soit ? >> Ça signalera les stations sans la ref, ou avec une ref inconnue. >> >> >> Le problème c'est que toutes les stations service ne sont pas dans >> cette base . il me semble qu'il y a une obligation d'y être à >> partir d'un certain volume de vente. Donc les petites stations >> n'ont pas de ref dans la base source. >> >> >> Autre chose sur le fonctionnement d'osmose, la source qui >> est ajouté aujourd'hui a une date qui est le 30/08/2017 >> est ce que les données ajoutées sont celles de la base à >> cette date? >> >> Oui. Il y a justement déjà une mise à jour dans les tuyaux, ça >> va arriver. >> Pour cette analyse la mise à jour automatique des données >> n'est pas supporté (à coder, aide bienvenue). >> >> >> Frédéric. >> >> >> >> > > ___ > 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
Re: [OSM-talk-fr] Import station essence (NavAds)
Les données des stations issues de la base des prix des carburant c'est de la donnée chaude... mise à jour plusieurs fois par jour donc très fraîche. Il manque toutefois certaines infos comme la marque (brand) Navads c'est de la donnée froide... elle peut servir à compléter certains attributs si on est sûr de leur pertinence. brad est un bon candidat, opening_hours n'avait pas l'air pertinent (ou alors pour un shop=* associé). osmose vs import... c'est vraiment deux philosophies qui s'opposent... du fait main ou de la machine. Pourquoi ne pas plutôt utiliser les données navads via osmose sur la France avec un mix des données issues des prix des carburants ? Quand je vois 15% d'erreur sur les données vérifiées, je pense qu'on ne devrait rien envisager d'automatique avec ces données qui ont besoin d'un sérieux contrôle humain avant d'arriver dans OSM. Le 12 avril 2018 à 01:24, marc marc <marc_marc_...@hotmail.com> a écrit : > Histoire d'aider Stéphane, > voici le résumé des dernières nouvelles de la mailing imports > NB: la première partie n'est PAS mon avis, c'est ce que Ilya dit. > La maj de Ilya a été faite AVANT la publication des avis > france/allemagne, c'est donc logique qu'il n'en a pas encore tenu compte. > En fin de message une proposition pour avancer :) > > début du résumé mailing imports : > > stats du jeux précédent : création de 1.5k et maj 4.7k en France > > les tags modifiées sont uniquement "brand", "phone", "opening_hours" et > "addr:postcode" "ref:navads" > > le tag opening_hours n'est plus écrasé s'il est déjà présent dans osm. > uniquement ajouté si absent > > vu qu'il a eu vent avant publication du rejet actuel des communautés > française et allemande, il a divisé l'import en 5 http://audit.osmz.ru/ > > Les allemands ont aussi trouvées des problèmes de qualités : > - stations fantômes > - tag d'heure d'ouverture incorrecte > - contre l'ajout des addr:postcode > - problème de précision dans la localisation ~100m > - 15% d'erreur sur les données vérifiées > > la dernière version proposée > https://lists.openstreetmap.org/pipermail/imports/2018-March/005475.html > les données > http://audit.osmz.ru/ > l'avis de la communauté allemande > https://lists.openstreetmap.org/pipermail/imports/2018-April/005481.html > > fin du résumé de la mailing imports, début de mon avis :) > > on a beaucoup parlé qu'on avait une meilleur source d'info dispo pour la > France mais quand on regarde l'état avec osmose, on a 3000 éléments en > attente > http://osmose.openstreetmap.fr/fr/errors/?item=8200%2C8201%2C8202 > Du coup, si on pense que cette source est de meilleur qualité, ne > devrait-on pas l'utiliser activement pour faire : > - une édition de masse ou manuelle pour 314 maj > - essayer de qualifier les 606 intégrations proposées > - voir si les 2262 nouvelles stations proposées ont un sens (entre autre > je me souviens que pour un bureau de poste, osmose ne tenait pas compte > des objets effacés et proposait donc de les recréer.) > si ce processus abouti, on pourrait alors proposer un import de ces > stations et voir ce qui reste dans l'import NavAds. > Peut être plus grand chose que NavAds ne propose que 1500 nouvelles > stations contre 2262 via Osmose. > Evidement cela nécessite des bras constructifs :) > ___ > 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
Re: [OSM-talk-fr] BANO : date de la BAN
Ah oui, ça c'est assez courant. L'adresse n'ayant pas été trouvée dans les données du cadastre par l'IGN, elle est positionnée soit par interpolation, soit au milieu du tronçon de voie, soit bien pire. Le 10 avril 2018 à 22:10, deuzeffe <opensm@deuzeffe.org> a écrit : > Bon, j'ai retrouvé les numéros manquants (point gris) quelques (beaucoup) > dizaines de mètres plus loin : les coordonnées géographiques données par la > BAN pour ces numéros ne sont pas en adéquation avec le terrain :( > > Désolée pour le dérangement. > -- > deuzeffe - qui a vraiment besoin de changer ses carreaux > > > Le 10/04/2018 à 19:49, deuzeffe a écrit : > >> Le 10/04/2018 à 19:37, Christian Quest a écrit : >> >>> Elles datent un peu en effet... février 2017 si je ne me trompe pas. >>> >> >> C'est ce qui m'embête un peu, non pas que la BAN soit de 2017, mais que >> de vieilles adresses ne s'y retrouvent point. Bon, c'est pas grave, j'ai >> mon fichier .csv sous les yeux. >> >> Par contre... les adresses ajoutées dans OSM ne vont pas dans la BAN, car >>> la BAN étant diffusée sous d'autres licences que l'ODbL, il n'est pas >>> possible d'inclure les adresses provenant d'OSM. >>> >> >> Tout à fait, j'avions bien compris, même si on la trouve sous 2 licences. >> >> Elle se retrouvent par contre dans BANO. >>> >> >> Yep. >> >> >>> Le 09/04/2018 à 23:23, deuzeffe a écrit : >>> >>>> (c'est encore moi) >>>> >>>> Bonsoir, >>>> >>>> Je viens de m'entraîner à numéroter une très vieille rue, avec de >>>> vieilles maisons habitées (et numérotées) depuis longtemps (pas un >>>> lotissement à peine éclos comme les pissenlits de saison). Sources : >>>> survey, cadastre et BAN (du 8/4/18). >>>> >>>> La relation est là : https://www.openstreetmap.org/ >>>> relation/8194667#map=18/45.79804/1.14605 (j'ai positionné au >>>> bâtiment...) >>>> >>>> Une dernière vérification sur http://tile.openstreetmap.fr/~ >>>> cquest/leaflet/bano.html#20/45.79768/1.14457 >>>> >>>> Et oh, surprise ! des adresses bien *présentes* dans le fichier BAN >>>> tout frais n'ont pas leur numéro/point gris (enfin, une les a, et >>>> complètement décalé :///). >>>> >>>> D'où ma question : quel est l'âge (la date ?) du fichier BAN utilisé >>>> pour le rendu BANO ? Même si la màj de BANO ne suit peut-être pas le rythme >>>> effréné de la màj de BAN, les adresses que j'ai tagguées existent depuis >>>> assez longtemps pour être dans la BAN. Ou alors, y a un autre problème >>>> quelque part :( >>>> >>>> Merci pour les réponses, quelles qu'elles soient. >>>> >>> >>> >> ___ >> 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 > -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] BANO : date de la BAN
Elles datent un peu en effet... février 2017 si je ne me trompe pas. Par contre... les adresses ajoutées dans OSM ne vont pas dans la BAN, car la BAN étant diffusées sous d'autres licences que l'ODbL, il n'est pas possible d'inclure les adresses provenant d'OSM. Elle se retrouvent par contre dans BANO. Le 09/04/2018 à 23:23, deuzeffe a écrit : (c'est encore moi) Bonsoir, Je viens de m'entraîner à numéroter une très vieille rue, avec de vieilles maisons habitées (et numérotées) depuis longtemps (pas un lotissement à peine éclos comme les pissenlits de saison). Sources : survey, cadastre et BAN (du 8/4/18). La relation est là : https://www.openstreetmap.org/relation/8194667#map=18/45.79804/1.14605 (j'ai positionné au bâtiment...) Une dernière vérification sur http://tile.openstreetmap.fr/~cquest/leaflet/bano.html#20/45.79768/1.14457 Et oh, surprise ! des adresses bien *présentes* dans le fichier BAN tout frais n'ont pas leur numéro/point gris (enfin, une les a, et complètement décalé :///). D'où ma question : quel est l'âge (la date ?) du fichier BAN utilisé pour le rendu BANO ? Même si la màj de BANO ne suit peut-être pas le rythme effréné de la màj de BAN, les adresses que j'ai tagguées existent depuis assez longtemps pour être dans la BAN. Ou alors, y a un autre problème quelque part :( Merci pour les réponses, quelles qu'elles soient. -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Vinci Autoroutes et l'attribution à OpenStreetmap
A l'époque de la CC-by-SA le copyright était détenu par chaque contributeur sur ses contributions... donc la mention "contributors" étaient tout à fait cohérente. Depuis le passage en ODbL, c'est la fondation qui détient le copyright de la base prise comme un tout... ce n'est plus indispensable, mais ce crédit mentionnant les contributeurs c'est une belle façon de les remercier. Le 10/04/2018 à 16:15, marc marc a écrit : Le 10. 04. 18 à 16:00, Jean-Marc Liotier a écrit : On Tue, 10 Apr 2018 15:18:17 +0200 Rpnpif <rpn...@trob.eu> wrote: Il manque la mention "et les contributeurs" mais bon Je n'ai jamais compris le sens de cette mention - il me semble que "Openstreetmap" représente ses contributeurs... Il y a probablement une subtilité que je n'ai pas saisi. Quelqu'un sait l'expliquer ? j'ai toujours perçu cela comme une sorte de reconnaissance de "l'association osm" envers ces contributeurs. cad que l'infra osm (les serveurs et logiciels) n'aurait pas de grande valeur sans le travail de titan des contributeurs. Une sorte de "merci à vous" en bas de chaque carte :) Juridiquement faudrait voir à qui appartient un changeset. Si il appartient tjs au contributeur, c'est là la différence entre l'asso osm et les contributeurs dans l'utilisation des données. ___ 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
Re: [OSM-talk-fr] article sur un point de vue d'un dev sur l'usage d'OSM
C'est malheureusement un mécanisme assez bricolé... J'avais aussi imaginé un système basé sur les geohash + quelques tags "majeurs" permettant de retrouver un objet d'un type donné dans une zone donnée. En fouillant sur talk-fr on doit pouvoir retomber dessus ;) Exemple: amenity=cafe@geohash Il faut un peu de flou, mais pas trop ou alors un flou variable... tant sur le côté sémantique que géo. cle_secondaire=valeur_secondaire+cle_primaire=valeur_primaire@geohash_plus_ou_moins_long Un mécanisme complet devrait permettre de passer d'un objet existant à cet id "stable" et pas que l'inverse. Le 09/04/2018 à 18:20, marc marc a écrit : Bonjour Jean-Christophe Becquet, Le 09. 04. 18 à 18:04, Jean-Christophe Becquet a écrit : Le 09/04/2018 15:33, marc marc a écrit : - les id non stable dans osm : problème résolu depuis longtemps, cfr overpass stable id. Pourrais-tu expliquer en 2 mots de quoi il s'agit ou donner un lien vers une ressource qui parle de ce overpass stable id ? Cela consiste à utiliser un id qui est un index vers un ensemble de caractéristique "stable" peu importe les id dans osm. cela utilise une requête overpass avec les critères choisis. exemple fictif : un way actuellement nommé "rue de la gare" à "Paris 1er arrondissement" entre le nœud a et le nœud b. tu peux avoir un id stable qui pointerait toujours vers "rue de la gare" à "Paris 1er arrondissement". si quelqu'un coupe le way en 2 et change le nom d'un des 2 morceaux, l'id stable pointera vers le morceau qui a gardé le nom. si quelqu'un coupe le way et change le maspeed d'un des 2 morceaux, l'id stable pointera vers les 2 morceaux puisqu'il ont gardé le nom. si quelqu'un fait une modif tordu de déplacer ce way en chine, l'id stable ne retournera plus rien. tu peux aussi avoir un id stable qui représente la rue entre le point a et le point b (exemple pour l'utiliser dans un itinéraire) Si ce way osm est coupé en 2 et l'id stable pointera vers les 2 morceaux Autre exemple fictif : un poi pourrait avoir un id stable si tu considères l'emplacement du magasin (cela pointera vers le nouveau "locataire" en cas de changement") ou tu peux avoir un id stable vers "la succursale de Paris de quel enseigne", qui résisterait aux déménagements et aussi aux améliorations tagé comme un noeud -> tagé comme une surface. plus d'info : https://wiki.openstreetmap.org/wiki/Overpass_API/Permanent_ID Cordialement, Marc ___ 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
Re: [OSM-talk-fr] article sur un point de vue d'un dev sur l'usage d'OSM
J'ai posté quelques réponses sur mastodon... https://mastodon.qowala.org/@KillianKemps/99824814902871590 1) ne pas confondre outils (périphériques au projet OSM) et le coeur du projet c'est à dire une base de données collaborative Ok, leaflet et ses plugins ne correspondent pas forcément à 100% à vos besoins... mais ils sont ouvert, améliorables ! En tant que développeur, on peut aussi participer à leur amélioration, les PR sont les bienvenues ! 2) la qualité des données... Oui, c'est hétérogène et lié à l'activité des contributeurs (bénévoles, faut-il le rappeler). Certains POI peuvent être très détaillés, d'autres moins et beaucoup manquent carrément. Votre site/appli, permet de compléter ces données (dans OSM) ? Oui... super, cela fait de nouvelles contributions qui vont améliorer l'ensemble. Non... c'est bien dommage ! Occasion manquée de reverser dans le pot commun. 3) les identifiants ne sont pas stables Effectivement mais ils ne changent pas si souvent que ça non plus. On peut donc les conserver, ainsi que d'autres infos... le nom la position géographique (plus fiable que l'adresse). On retrouvera par proximité les nouveaux objets. Autre piste... compléter les données OSM avec un identifiant plus stable... par exemple le code SIRET de l'établissement (issu de la base SIRENE opendata) ref:FR:SIRET=* 4) "Je ne suis pas un spécialiste d'OpenStreetMap car je ne l'ai utilisé que quelques fois en tant que développeur" Une posture de "consommateur" en quelque sorte... non ? " j'ai le sentiment qu'en effet il faudrait faire un grand travail de fond sur le projet afin d'améliorer la qualité des données, d'améliorer la qualité des outils et de faciliter leur utilisation." Tu es le bienvenu pour faire avancer le projet dans cette direction ! Le 09/04/2018 à 13:43, Nicolas Bétheuil a écrit : Bonjour, Ce n'est pas pour déclencher ici une polémique ou un troll velu mais plus pour partager un point de vue, au cas où cette article n'est pas remonté dans votre veille https://www.killiankemps.fr/fr/blog/faut-il-un-nouveau-openstreetmap ___ 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
Re: [OSM-talk-fr] BANO : aide pour légende
Le 8 avril 2018 à 11:05, deuzeffe <opensm@deuzeffe.org> a écrit : > Vu ! Mais j'ai quand même l'impression qu'on perd des alertes :( > > En principe les alertes pertinentes sont bien là... sauf erreur. > Autre question : > > - « légende des points turquoise = voies sans adresses numérotées » si > j'ai bien suivi, puisque j'en retrouve dans cette catégorie dans > cadastre/fantoir ; > > - Or, sur le terrain (et même sur la couche BANO), ces voies sont bien > numérotée (numéro gris <- BAN) ; > > - Donc, ma question, de quelle base et avec quel code/flag/tag provient > l'info. « voie non numérotée » ? > > Ces points turquoise indiquent les voies pour lesquelles on n'a pas trouvé de numéro dans BANO mais qu'on a bien la voie dans OSM (d'où la localisation de ce point). Cela ne veut pas dire qu'il n'y en a pas sur le terrain ni dans la BAN (gris). C'est potentiellement un indicateur de nombreux numéros manquants... donc intéressant de la ajouter dans OSM. -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] BANO : aide pour légende
J'ai finalement quand même modifié la requête afin de ne pas signaler les voies pour lesquelles un nom similaire est trouvé entre BANO et BAN, mais pour lesquelles le rapprochement FANTOIR n'a pas été fait côté BAN. Moins de gris pointillé et de rouge pointillé du coup, ce qui allège pas mal de rendu par endroit comme dans l'exemple de deuzeffe... Le 7 avril 2018 à 22:48, Christian Quest <cqu...@openstreetmap.fr> a écrit : > Il y a sûrement des cas où ces signalements sont utile, comme tu > l'indiques sur des adresses toutes fraiches. Donc je laisse, mais il va > falloir compléter le wiki ;) > > Il n'est pas toujours évident en effet d'être à jour de partout entre le > COG, FANTOIR, les adresses où chacun avance à son rythme. Le millésimage > est un sérieux problème et je pense qu'on n'est pas top à jour partout côté > BANO. > > La Poste met à jour vraiment en continu et diffuse chaque mois une > nouvelle version de ses données. > Le cadastre remonte les infos locales une à deux fois par an en national > si j'ai bien compris. > Du coup à la sortie du tuyau on ne peut pas dire que l'un va plus vit que > l'autre. > Pour la BAN en plus, on a l'IGN entre les deux qui jusqu'à présent > attendait les données du cadastre (reçues annuellement) pour déterminer des > positions géographiques aux nouvelles adresses reçues de La Poste (sans > info géo). > > > Le 7 avril 2018 à 19:51, Christian Rogel <christian.ro...@club-internet.fr > > a écrit : > >> >> >> > Le 7 avr. 2018 à 19:38, Christian Quest <cqu...@openstreetmap.fr> a >> écrit : >> > >> > Ces tracés pointillés gris ne sont pas pertinents... ils indiquent les >> adresses de la BAN pour lesquelles un code FANTOIR de voie n'a pas été >> retrouvé. >> > >> > Je vais les retirer du rendu car ils ne sont pas utiles pour les >> contributions OSM et BANO, je ne sais même plus pourquoi je les avais >> ajouté... du debug qui est resté ;) >> >> Pourtant, ils permettent quelquefois de voir les retards du cdastre par >> rapport aux décisions nouvelles des communes, généralements dans les zones >> les plus rurales. >> Je soupçonnais que la Poste pouvait doubler le cadastre. Qu’en est-il ? >> >> >> Christian R. >> >> >> ___ >> Talk-fr mailing list >> Talk-fr@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/talk-fr >> > > > > -- > Christian Quest - OpenStreetMap France > -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] BANO : aide pour légende
Il y a sûrement des cas où ces signalements sont utile, comme tu l'indiques sur des adresses toutes fraiches. Donc je laisse, mais il va falloir compléter le wiki ;) Il n'est pas toujours évident en effet d'être à jour de partout entre le COG, FANTOIR, les adresses où chacun avance à son rythme. Le millésimage est un sérieux problème et je pense qu'on n'est pas top à jour partout côté BANO. La Poste met à jour vraiment en continu et diffuse chaque mois une nouvelle version de ses données. Le cadastre remonte les infos locales une à deux fois par an en national si j'ai bien compris. Du coup à la sortie du tuyau on ne peut pas dire que l'un va plus vit que l'autre. Pour la BAN en plus, on a l'IGN entre les deux qui jusqu'à présent attendait les données du cadastre (reçues annuellement) pour déterminer des positions géographiques aux nouvelles adresses reçues de La Poste (sans info géo). Le 7 avril 2018 à 19:51, Christian Rogel <christian.ro...@club-internet.fr> a écrit : > > > > Le 7 avr. 2018 à 19:38, Christian Quest <cqu...@openstreetmap.fr> a > écrit : > > > > Ces tracés pointillés gris ne sont pas pertinents... ils indiquent les > adresses de la BAN pour lesquelles un code FANTOIR de voie n'a pas été > retrouvé. > > > > Je vais les retirer du rendu car ils ne sont pas utiles pour les > contributions OSM et BANO, je ne sais même plus pourquoi je les avais > ajouté... du debug qui est resté ;) > > Pourtant, ils permettent quelquefois de voir les retards du cdastre par > rapport aux décisions nouvelles des communes, généralements dans les zones > les plus rurales. > Je soupçonnais que la Poste pouvait doubler le cadastre. Qu’en est-il ? > > > Christian R. > > > ___ > 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
Re: [OSM-talk-fr] BANO : aide pour légende
Ces tracés pointillés gris ne sont pas pertinents... ils indiquent les adresses de la BAN pour lesquelles un code FANTOIR de voie n'a pas été retrouvé. Je vais les retirer du rendu car ils ne sont pas utiles pour les contributions OSM et BANO, je ne sais même plus pourquoi je les avais ajouté... du debug qui est resté ;) Au moins mon enquête m'aura permis de remettre au propre mon installation de kosmtik :) Le 7 avril 2018 à 18:20, Christian Quest <cqu...@openstreetmap.fr> a écrit : > L'éléphant est peut être dans un autre salon... bug dans la requête qui > sert à générer le rendu. > > Ce rendu n'est pas parfait, c'est une aide pour détecter des trucs qui > manquent... mais si on se met comme objectif de faire disparaître tout ce > qui ressemble à une anomalie, on se trompe de cible ;) > > Bon.. va falloir que je jette un oeil. > > > Le 7 avril 2018 à 17:34, deuzeffe <opensm@deuzeffe.org> a écrit : > >> Bonjour, >> >> Soit, dans BANO une rue notée en gris et entourée de pointillés gris (par >> exemple la rue des Bouvreuils ici : http://tile.openstreetmap.fr/~ >> cquest/leaflet/bano.html#18/45.79054/1.12574 ) >> >> D'après la légende de BANO, « en pointillé et nommées en gris et italique >> : ensembles d'adresses sur des voies de la BAN n'ayant pas pu être >> rapprochées de FANTOIR, ni dans OSM » >> >> Or cette rue : >> - est OK dans la BAN ; >> - est OK dans FANTOIR (et rapprochée) ; >> - est OK dans OSM (et rapprochée avec FANTOIR, donc) ; >> - est cadastrée correctement (voie au bon endroit avec la bonne graphie). >> >> Quel éléphant dans le salon (ou la rue) m'empêche de voir pour quelle >> incohérence elle apparaît en gris/pointillé gris ? >> >> -- >> deuzeffe - qui risque de devoir changer ses besicles. >> >> _______ >> Talk-fr mailing list >> Talk-fr@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/talk-fr >> > > > > -- > Christian Quest - OpenStreetMap France > -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] BANO : aide pour légende
L'éléphant est peut être dans un autre salon... bug dans la requête qui sert à générer le rendu. Ce rendu n'est pas parfait, c'est une aide pour détecter des trucs qui manquent... mais si on se met comme objectif de faire disparaître tout ce qui ressemble à une anomalie, on se trompe de cible ;) Bon.. va falloir que je jette un oeil. Le 7 avril 2018 à 17:34, deuzeffe <opensm@deuzeffe.org> a écrit : > Bonjour, > > Soit, dans BANO une rue notée en gris et entourée de pointillés gris (par > exemple la rue des Bouvreuils ici : http://tile.openstreetmap.fr/~ > cquest/leaflet/bano.html#18/45.79054/1.12574 ) > > D'après la légende de BANO, « en pointillé et nommées en gris et italique > : ensembles d'adresses sur des voies de la BAN n'ayant pas pu être > rapprochées de FANTOIR, ni dans OSM » > > Or cette rue : > - est OK dans la BAN ; > - est OK dans FANTOIR (et rapprochée) ; > - est OK dans OSM (et rapprochée avec FANTOIR, donc) ; > - est cadastrée correctement (voie au bon endroit avec la bonne graphie). > > Quel éléphant dans le salon (ou la rue) m'empêche de voir pour quelle > incohérence elle apparaît en gris/pointillé gris ? > > -- > deuzeffe - qui risque de devoir changer ses besicles. > > ___ > 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
Re: [OSM-talk-fr] Import des hauteurs de bâtiment depuis la BD TOPO
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
Re: [OSM-talk-fr] Import des hauteurs de bâtiment depuis la BD TOPO
Le 5 avril 2018 à 15:37, Vincent Frison <vincent.fri...@gmail.com> a écrit : > Salut Christian, > > Merci pour ces précisions, mes réponses plus bas. > > Le 5 avril 2018 à 00:43, Christian Quest <cqu...@openstreetmap.fr> 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) ? :) > > On en a déjà une... toute petite... nous sommes chargé de la diffusion de la version ODbL de la BAN par la convention signée en 2015, et la BAN est passée au statut de service public de la données ;) C'est marginal bien sûr. Etre chargé d'un mission de service public, ou d'une délégation de service public ça apporte forcément des contraintes et pas que des avantages et je pense qu'on en est bien loin. Par contre, nous oeuvrons dans l'intérêt général et pourrions être "reconnus d'utilité publique". Là aussi ça apporte des avantages et aussi des contraintes. > 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 ? > Oui, c'est ça, 25% de recettes propres provenant des redevances... j'ai quand même un gros doute sur ce niveau de ventes, mais comme les comptes de l'IGN sont illisibles (la Cours des Comptes s'en était plaint en 2013) ça va pas être facile à vérifier. > >> 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 ? > > 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. Ce que je cherche depuis des années c'est de moyen de véritablement établir une collaboration avec l'IGN pour pouvoir contribuer dans les deux sens... et pour l'instant ça coince malheureusement toujours quelque part. -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Et si on fabriquait notre récepteur/logger GPS ?
Les capteurs supplémentaires peuvent servir, mais même une puce GPS sans capteur annexe pourra faire de l'extrapolation et du lissage... les Garmin des années 2005 faisaient déjà ça. C'est pour ça que les données NMEA supplémentaires (nombre de sat, DOP, etc) permettent de savoir si le calcul se base bien sur les signaux reçus et pas sur de l'extrapolation. Avec des accéléromètres, l'extrapolation peut être améliorée, car on a au moins des infos complémentaires pour le calcul. Donc le mieux pour une position précise ce sont (de mon point de vue): 1) des signaux nombreux et de qualité (DOP faible)... et une correction différentielle (RTK) 2) des signaux nombreux et de qualité (DOP faible) 3) peu de signaux mais compensés correctement lorsqu'on est en mouvement et pour de courte durées par des accéléromètres 4) peu de signaux et rien de plus... donc DOP élevée 5) peu de signaux et une extrapolation trompeuse... donc DOP plus vraiment fiable Le 4 avril 2018 à 21:55, Stéphane Péneau <stephane.pen...@wanadoo.fr> a écrit : > Pour la trace jaune, j'ai découvert en remontant les informations, que le > récepteur de cette tablette Nexus 9 semble intégrer des capteurs > supplémentaires, accéléromètre, gyroscope, etc... Je me demande à quoi ça > ressemblerait s'ils n'étaient pas là. > https://www.broadcom.com/products/wireless/gnss-gps-socs/bcm4752 > > > Plus généralement, et de ce que j'ai compris, c'est donc à prendre avec > des pincettes, tous les récepteurs font du filtrage. Le navspark a un mode > automatique, un mode voiture, piéton, etc.. > > En tout cas, lorsqu’avec un récepteur me fournissant du RAW je tente un > calcul dans RTKLIB en mode "single", ce n'est pas beau à voir. > > Oui, le DOP indique bien que la réception est mauvaise pendant le passage > sous le tunnel : > http://www.stemani.fr/public/gnss/gnss5.JPG > > Stf > > > > Le 04/04/2018 à 12:40, Christian Quest a écrit : > > La jaune est typique d'un GPS "routier", qui fait de l'overshooting dans > les virages... c'est à dire qui tient compte des déplacements précédents > pour "lisser". > C'est un phénomène qui ne date pas d'hier, il y a plus de 10 ans, ça me > posait des problèmes pour les contrôles de vols dans les compétitions de > parapente ! > > Exemple: http://umap.openstreetmap.fr/fr/map/comparaison-recepteurs-gnss_ > 208577#19/47.13163/-1.50767 > > Sur le rond point le vert ne déborde pas, par contre, le passage sous > l'autoroute n'est pas lissé comme le jaune (et tant mieux, si on a le DOP > indiqué). > > Pour moi c'est le vert qui s'en sort le mieux, correspond à des mesures > réelles et pas extra/inter-polées... tout le bénef d'un GPS dédié et où ces > extrapolation peuvent être en principe désactivées (ou plutôt activées à la > demande et pas l'inverse). > > > > Le 3 avril 2018 à 18:41, Stéphane Péneau <stephane.pen...@wanadoo.fr> a > écrit : > >> Hello, >> >> Alors, qui était qui dans ce test ? >> >> Je rappelle les protagonistes : >> - Smartphone Sony Xperia Ray >> - Smartphone HTC One mini >> - Tablette Nexus 9 >> - Tablette Nvidia Tablet Shield K1 >> - Navspark GL. >> >> Et les résultats : >> http://umap.openstreetmap.fr/fr/map/comparaison-recepteurs-gnss_208577 >> >> On peut facilement éliminer la trace bleue (Xperia Ray), la orange (HTC >> One mini), ainsi que la rouge (Nvidia Shield). >> Il nous reste la trace verte et la trace jaune. >> >> Je le rappelais, ce n'est pas vraiment la position absolue qui comptait >> dans ce test, mais la façon dont les traces se décalaient en cas >> d'obstacles alors que le déplacement reste rectiligne. Une antenne sur le >> toit est censée mieux capter les signaux des satellites, et pouvoir plus >> facilement discriminer les signaux ayant subi un rebond. >> Voici quelques pistes où les traces vertes restent parallèles alors que >> les jaunes dérivent : >> http://www.stemani.fr/public/gnss/gnss1.jpg >> http://www.stemani.fr/public/gnss/gnss2.jpg >> http://www.stemani.fr/public/gnss/gnss3.jpg >> C'est encore plus flagrant sur cette dernière capture : >> http://www.stemani.fr/public/gnss/gnss4.jpg >> >> La trace jaune est la tablette Nexus 9, et la verte est bien le récepteur >> Navspark GL avec l'antenne sur le toit. >> >> Si quelqu'un souhaite regarder de plus près, par exemple dans Josm, les >> voici : >> http://www.stemani.fr/public/gnss/test_gnss.zip >> >> Stéphane >> >> >> >> >> >> Le 28/03/2018 à 00:59, Stéphane Péneau a écrit : >> >>> Le 28/03/2018 à 00:10, Francois Gouget a écrit : >>> >>>> J'aurais ten
Re: [OSM-talk-fr] Import des hauteurs de bâtiment depuis la BD TOPO
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... 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." 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). Le 4 avril 2018 à 17:40, Vincent Frison <vincent.fri...@gmail.com> a écrit : > 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. > > -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Et si on fabriquait notre récepteur/logger GPS ?
La jaune est typique d'un GPS "routier", qui fait de l'overshooting dans les virages... c'est à dire qui tient compte des déplacements précédents pour "lisser". C'est un phénomène qui ne date pas d'hier, il y a plus de 10 ans, ça me posait des problèmes pour les contrôles de vols dans les compétitions de parapente ! Exemple: http://umap.openstreetmap.fr/fr/map/comparaison-recepteurs-gnss_208577#19/47.13163/-1.50767 Sur le rond point le vert ne déborde pas, par contre, le passage sous l'autoroute n'est pas lissé comme le jaune (et tant mieux, si on a le DOP indiqué). Pour moi c'est le vert qui s'en sort le mieux, correspond à des mesures réelles et pas extra/inter-polées... tout le bénef d'un GPS dédié et où ces extrapolation peuvent être en principe désactivées (ou plutôt activées à la demande et pas l'inverse). Le 3 avril 2018 à 18:41, Stéphane Péneau <stephane.pen...@wanadoo.fr> a écrit : > Hello, > > Alors, qui était qui dans ce test ? > > Je rappelle les protagonistes : > - Smartphone Sony Xperia Ray > - Smartphone HTC One mini > - Tablette Nexus 9 > - Tablette Nvidia Tablet Shield K1 > - Navspark GL. > > Et les résultats : > http://umap.openstreetmap.fr/fr/map/comparaison-recepteurs-gnss_208577 > > On peut facilement éliminer la trace bleue (Xperia Ray), la orange (HTC > One mini), ainsi que la rouge (Nvidia Shield). > Il nous reste la trace verte et la trace jaune. > > Je le rappelais, ce n'est pas vraiment la position absolue qui comptait > dans ce test, mais la façon dont les traces se décalaient en cas > d'obstacles alors que le déplacement reste rectiligne. Une antenne sur le > toit est censée mieux capter les signaux des satellites, et pouvoir plus > facilement discriminer les signaux ayant subi un rebond. > Voici quelques pistes où les traces vertes restent parallèles alors que > les jaunes dérivent : > http://www.stemani.fr/public/gnss/gnss1.jpg > http://www.stemani.fr/public/gnss/gnss2.jpg > http://www.stemani.fr/public/gnss/gnss3.jpg > C'est encore plus flagrant sur cette dernière capture : > http://www.stemani.fr/public/gnss/gnss4.jpg > > La trace jaune est la tablette Nexus 9, et la verte est bien le récepteur > Navspark GL avec l'antenne sur le toit. > > Si quelqu'un souhaite regarder de plus près, par exemple dans Josm, les > voici : > http://www.stemani.fr/public/gnss/test_gnss.zip > > Stéphane > > > > > > Le 28/03/2018 à 00:59, Stéphane Péneau a écrit : > >> Le 28/03/2018 à 00:10, Francois Gouget a écrit : >> >>> J'aurais tendance à dire qu'il n'y en a pas un pour rattraper les >>> autres. Mais peut-être ai-je raté les points importants ? >>> >> Normalement, si tu décoches au fur et à mesure les traces qui te semble >> les moins bonnes pour qu'elles ne perturbent plus l'affichage, tu devrais >> trouver assez facilement celle qui vient de l'antenne sur le toit. >> J'avoue qu'avoir quelques niveaux de zooms supplémentaires, ça aide, mais >> umap semble limité sur ce point. >> >> Je donnerai la réponse dans quelques jours. >> >> ___ >> 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 > -- Christian Quest - OpenStreetMap France ___ 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
L'opendata pour la BD Topo, on n'y est pas encore... mais c'est une piste de plus en plus sérieuse. 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 > > -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] ODbL toujours inaccessible
OSM n'a pas rejeté la CC-by-SA 4.0, elle n'existait pas à l'époque... on était en 2.0 ;) Je pense que des copie du texte de la licence on doit en trouver quand même facilement... Exemple: https://spdx.org/licenses/ODbL-1.0.html Le 31/03/2018 à 22:51, Alain VASSAULT a écrit : N'est ce pas à l'OSMF de le faire afin de couvrir tous les chapitre locaux? Cela devrait rentrer dans le champs de compétences du groupe qui défend les intérêt d'OSM lié à la dite licence non? (Désolé je ne me rappelle pas le nom du dis groupe) Le 31 mars 2018 22:36:49 GMT+02:00, Philippe Verdy <verd...@wanadoo.fr> a écrit : Déjà signalé ici, et sur les points de contact de la Fondation Open Knowlege sur les réseaux sociaux. On n'a toujours pas accès à la licence ODbL (ni aux autres licences libres publiées par elle). Il est grand temps d'héberger une copie approuvée de la licence ODbL-1.0 sur les serveurs OSM puisque l'OKN semble avoir fermé le site et ne plus soutenir elle-même ces licences (et milite maintenant en faveur de la CC-BY-SA-4.0 qu'OSM a rejetée !). La situation est intenable et met en péril tout le projet qu'on ne peut plus valablement protéger avec une licence accessible et lisible par tout le monde. ___ 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
Re: [OSM-talk-fr] Import données pour mise à jour musées, bibliothèques, cinémas théâtres
Pour ce genre de manip je fais ça avec JOSM et le plugin todolist (ou conflation, mais plus compliqué)... 1) ouvrir les données à intégrer 2) les adapter pour avoir les bons tags correspondants dans OSM 3) sélectionner l'ensemble des objets et les ajouter dans la "todolist" 4) les passer en revue un à un, en chargeant les données OSM sur la zone et en fusionnant avec l'existant si nécessaire. Bien sûr, ça prend du temps, mais ça permet d'avoir un résultat de qualité. Todolist permet vraiment de se simplifier le boulot et de ne rien oublier. Il y a bien sûr la solution basées sur osmose, mais il faut voir la volumétrie pour décider si ça vaut le coup. L'intérêt est peut être dans les mises à jour futures... Le 29/03/2018 à 09:44, VAN OOST Jérôme a écrit : Bonjour à tous, Nous avons une base de données avec les horaires d’ouvertures des musées, cinémas/théâtres et bibliothèques de l’ensemble du territoire de la MEL (Métropole Européenne de Lille – 90 communes). Débutants sur OSM nous cherchons un moyen de faire une mise à jour à partir de ces bases sans créer des doublons sur ce qui existe déjà mais si possible sans avoir à tout entrer manuellement. Quelle est la bonne manière pour procéder à cela ? Merci de votre aide Bonne journée Jérôme ___ 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
Re: [OSM-talk-fr] Import station essence
En gros la conclusion c'est quoi ? Communauté FR opposée à cet import ? ok pour moi ;) On a des données plus propre dans la base des prix des carburants. Le 27 mars 2018 à 22:01, Stéphane Péneau <stephane.pen...@wanadoo.fr> a écrit : > Il n'y a plus de remarque ? J'envoie la réponse ? > > Stf > > > Le 26/03/2018 à 14:58, Stéphane Péneau a écrit : > >> Pour ma part, j'ai trouvé plusieurs stations-service manquantes que ce >> jeu de données pourrait ajouter. >> Donc non, je ne pense pas qu'il faut tout jeter, ni lui tomber dessus en >> hurlant que son truc, "c'est d'la merde". >> >> J'espère qu'on peut être un peu plus constructif. On a tous à y gagner. >> >> Stf >> >> Le 26/03/2018 à 14:33, deuzeffe a écrit : >> >>> Le 26/03/2018 à 13:47, marc marc a écrit : >>> >>>> La source est Navads. >>>> >>> >>> Et « We have the full permission to add all of these to OpenStreetMap: >>> that's the very reason we were contacted. » (from >>> https://wiki.openstreetmap.org/wiki/Navads_Imports#Source) semble >>> suffisant ? Quid de telles données une fois qu'elles font partie d'OSM, >>> avec une telle (absence de) licence (clairement pas identifiée) ? >>> >>> -- >>> deuzeffe - qui s'instruit >>> >>> >>> >>> ___ >>> 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 > -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Et si on fabriquait notre récepteur/logger GPS ?
Pour ma part, j'ai testé un M8T pour faire du RTK, connecté à une simple raspberry pi et une batterie. Aucun hardware spécifique à développer ni électronique. Un script se lance au boot de la raspberry et enregistre le signal dans un fichier sur la carte SD que je récupère ensuite comme trace GPS mais aussi pour faire du post-traitement RTK. Au total ça ne dépasse pas 150€ et c'est évolutif. Il serait possible d'activer une connexion bluetooth / wifi (intégrés sur la Pi Zero W). GPS: http://www.csgshop.com/product.php?id_product=258 (M8T donc avec RTK, moins cher sans) Raspberry: https://www.kubii.fr/fr/pi-zero-w/2077-kit-pi-zero-w-3272496009509.html et une power bank... pour quelques dizaines d'euros en fonction de la capacité souhaitée. Manque plus que de packager tout ça... et pour une petite série, je ferai bien chauffer mon imprimante 3D ;) On peut rajouter une LED multicolore pour indiquer l'état. Proto pour SOTM Bordeaux ? Le 23/03/2018 à 14:58, Dominique Rousseau a écrit : Le Fri, Mar 23, 2018 at 09:53:03AM +0100, René-Luc Dhont [rldh...@gmail.com] a écrit: Bonjour, Est-ce que ce projet aurait un lien avec le projet Centipède de Julien Ancelin ? https://github.com/jancelin/centipede https://centipede.sig.inra.fr/websig/lizmap/www/ https://jancelin.github.io/centipede/#/ Pas directement, je dirais. De ce que je comprens du projet centipede, il s'agit de deployer des bases fixes permettant de faire de la correction RTK, donc de fournir un signal, plutot que le recevoir. -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Mission sur les données géographiques souveraines...
Je voyais plus une discussion ouverte, ici même, qu'un formulaire pour répondre au questionnaire. Il me semble plus important de faire passer nos valeurs et quelques idées pour faire avancer le schmilblick que de répondre à un questionnaire qui, de mon point de vue, nous enferme dans une certaine logique à laquelle j'adhère assez peu. En effet, la lettre de mission parle, il me semble, avant tout de souveraineté... donc d'indépendance et moi je lis un peu "GAFA" en filigrane, alors que le questionnaire est par contre très centré sur l'IGN (13 questions sur 19). Le 21 mars 2018 à 18:10, Vincent Privat <vincent.pri...@gmail.com> a écrit : > Cool la démarche :) > Pour le changement de nom des mailing lists, l'asso avait utilisé un outil > que j'avais trouvé assez pratique. > Est-ce que vous pensez que ça serait une bonne idée de l'utiliser pour ce > sondage, ou bien on fait juste un thread par mail ? > Vincent > > Le 21 mars 2018 à 15:51, Christian Quest <cqu...@openstreetmap.fr> a > écrit : > >> OSM France a été sollicitée pour répondre à un questionnaire et >> participer à une audition dans le cadre de la mission sur les données >> géographiques souveraines confiée à la députée Valéria FAURE-MUNTIAN. >> >> J'ouvre donc ce fil de discussion afin d'avoir un retour plus large que >> notre seul CA. La date d'audition n'est pas fixée, mais il faudrait faire >> un premier retour assez rapidement en répondant là où c'est possible et >> opportun à ce questionnaire. >> >> Vous trouverez la trame du questionnaire sur: >> >> https://framadrop.org/r/GnauQTFnJo#PHbfHYpdRkh3ihKKasBqS+gQ3 >> SzaVa+WqlaALSPlNDk= >> >> ainsi que sa lettre de mission: >> >> https://framadrop.org/r/gWuzQ5CdQz#M4L91etXcHICbQP2SzahXXO2L >> K5pfs68TETV9R+oQ/I= >> >> Go ! (je cite Vincent) >> >> -- >> 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 > > -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] De BD Carthage à BD TOPO Hydrographie ?
C'est l'objectif de ces couches transparentes... et ça évite aussi de l'import un peu olé olé ;) Le 19/03/2018 à 17:18, Rpnpif a écrit : Le 19 mars 2018, marc marc a écrit : Le 19. 03. 18 à 10:13, Rpnpif a écrit : Le 17 mars 2018, deuzeffe a écrit : Mmmhhh ??? On peut utiliser QGis pour mettre à jour JOSM qui mettra à jour osm ? C'est plus intéressant que JOSM seul ? Oui puisque chez moi JOSM est trop lent et bloque avec autant de données. Bien sûr, le but est de sélectionner une petite zone (communale au plus). Mais je vais peut-être me rabattre sur la couche rapatriée sur Id. Il ne faut pas télécharger la France entière. Josm rame à cause de la quantité démesurée de données. A noter que josm permet lui aussi d'afficher BD Carthage comme une couche limité à la zone visible de ton écran au lieu de tous le pays. c'est dans menu imagerie, BD Carthage :) Mais c'est 2 choses assez différente. l'un sont les données pour intégrer un à un les rivières. l'autre est de l'affichage pour des retouches ponctuelles Oui et finalement, je vais me rabattre vers Id et ponctuellement vers la sous-couche dans JOSM comme tu l'indiques. Merci. -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] estimation du nombre de place de parking
Et quand le parking est un polygone, on peut aussi estimer à la louche sa capacité à partir de sa surface en prenant exemple sur ceux où c'est renseigné. Une place de parking doit faire en général dans les 6m x 2.5m (15m2), avec disons 6 m2 de voirie pour la desservir... ça donne une approximation. Le 10/03/2018 à 20:53, osm.sanspourr...@spamgourmet.com a écrit : Non seulement c'est préférable mais en plus ça permet de laisser un nombre dans capacity ce qui est toujours plus facile pour les applis. Mettre un texte c'est prendre le risque de virer la données pour les applis attendant un nombre et obliger à analyser le texte pour traduire ~, tilde qui ne doit dire environ qu'aux informaticiens et aux scientifiques. 2 centimes de plus. Jean-Yvon Le 10/03/2018 à 18:49, marc marc - marc_marc_...@hotmail.com a écrit : Par conséquent je me demande si capacity=nombre + source:capacity=estimated ne serrait pas préférable. ___ 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
Re: [OSM-talk-fr] De BD Carthage à BD TOPO Hydrographie ?
Tes voeux ont déjà été exaucés ! Sur le rendu Carthage, la couche Hydro de la BD Topo est visible en mauve. Le tracé est mieux définit comparé à la BD Carthage, par contre les attributs sont bien moins nombreux. J'ai aussi ajouté les altitudes en extrémité de tronçons. Le 10/03/2018 à 11:13, deuzeffe a écrit : Bonjour, Contexte : j'essaie de mettre à jour les infos de https://wiki.openstreetmap.org/wiki/FR:Sources_de_donn%C3%A9es_potentielles/France Si j'ai bien tout compris, la BD TOPO Hydrographie remplace la BD Carthage (dont la convention ONEMA-IGN est caduque en 2018, en plus). Cette « nouvelle » BD est en licence ouverte 1.0 et présentée ici : http://professionnels.ign.fr/bdtopo-hydrographie Est-ce que c'est possible, techniquement et légalement, qu'à court/moyen terme elle remplace le calque BD Carthage tout récemment intégré à iD (pardon Marc-Marc :p) Merci pour les réponses, quelles qu'elles soient. -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Orthophotos Guadeloupe et Martinique de 2017... à 20cm :)
L'occasion de donner un coup de main à distance à Hand ! Caribe Wave 2018 c'est le 15 mars... donc nous avons moins de 10 jours pour mettre à jour OSM à partir de cette ortho récente ;) Le 5 mars 2018 à 10:36, Christian Quest <cqu...@openstreetmap.fr> a écrit : > Les orthophotos à 20cm de 2017 des deux départements sont disponibles en > opendata (Licence Ouverte) mais pas encore intégrées à la BD Ortho. > > J'ai récupéré ça et mis en place un petit serveur WMS de test (avec QGis > server 3.0): > > http://wms.cquest.org/?service=WMS=GetCapabilities > > Source: "ORTHOHR 2017" > > -- > Christian Quest - OpenStreetMap France > -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Orthophotos Guadeloupe et Martinique de 2017... à 20cm :)
Les orthophotos à 20cm de 2017 des deux départements sont disponibles en opendata (Licence Ouverte) mais pas encore intégrées à la BD Ortho. J'ai récupéré ça et mis en place un petit serveur WMS de test (avec QGis server 3.0): http://wms.cquest.org/?service=WMS=GetCapabilities Source: "ORTHOHR 2017" -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Chantier nouvel université sorbonne nation : licence ?
C'est un établissement public, donc informations publiques, logiquement c'est Licence Ouverte. Par contre, si c'est en chantier... un bon gros polygone landuse=construction semble suffisant pour l'instant, non ? Le 3 mars 2018 à 09:11, Vincent Bergeot <vinc...@bergeot.org> a écrit : > Bonjour, > > la licence est odbl. > > Je ne retrouve pas la trace mais j'ai souvenir de lettres pdf stockée sur > le wiki avec des mentions type : > >- si c'est seulement pour OSM, alors "la mise à disposition de ces >données est autorisée pour la réutilisation et l'intégration dans la base >de donnée OpenStreetMap sous licence OdbL. >- si c'est général, alors le plus simple c'est : ces données sont mis >à disposition sous la licence OdbL" > > Importance de s'assurer que l'expéditeur de la lettre est bien le > propriétaire des données. > > PS : je ne suis pas juriste :) > > Bonne journée > > > > Le 02/03/2018 à 17:33, Nicolas Bétheuil a écrit : > > J'ai trouvé dans la FAQ > https://wiki.openstreetmap.org/wiki/FR:Questions_fr%C3% > A9quentes_l%C3%A9gales#2b._Une_organisation_X_met_.C3.A0_ > disposition_des_donn.C3.A9es_en_t.C3.A9l.C3.A9chargement_ > libre_sous_une_licence_L._Puis-je_les_utiliser_dans_OSM_.3F > > un accord sur support électronique suffit ou je fais envoyer un support > papier à une adresse du bureau OSM ? > > Le 2 mars 2018 à 13:45, Nicolas Bétheuil <nbethe...@free.fr> a écrit : > >> Bonjour, >> >> Quel licence demander pour pouvoir intégrer les bâtiments de la future >> université (déjà sortie de terre) ? >> Des mentions particulières OSM ? >> >> https://chantier-nation-sorbonne-nouvelle.com/ >> >> Merci >> > > > > ___ > Talk-fr mailing > listTalk-fr@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-fr > > > -- > Vincent Bergeot > > > ___ > 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
Re: [OSM-talk-fr] Osmose pour l'OpenData
Le RPG est un très gros jeu de données et qui décrit quelque chose de très changeant: les cultures subventionnées. Je ne pense pas qu'on puisse l'intégrer manuellement avec son niveau de détail, et encore moins le mettre à jour. Marcussacapuce en avait intégré un millésime dans l'Essone. Par contre, en faisant une version simplifiée, il permet grosso-modo de savoir où des landuse=farmland ne sont pas à jour, car ceci change moins souvent que le type de culture. Rien que ça déjà me semble un bon morceau à digérer qui pourrait aider à mettre à jour nos polygones de landuse de Corine Land Cover, jeu de données aussi a été mis à jour depuis l'import massif que nous avons fait. Si osmose est bien adapté à l'intégration de données ponctuelles, sur du surfacique on ne va pas pouvoir aller beaucoup plus loin que signaler que ça ne colle pas... reste ensuite toutes les manipulations sur les polygones et multi-polygones qu'on sait ne pas être évidentes pour tout le monde. L'idéal serait d'avoir un outil qui facilite ces mises à jour en prémâchant les changements et de le lier à osmose. Pour clore sur le RPG (mais c'est valable pour tout l'opendata)... ceux qui ont besoin de ces données y ont déjà accès ! Je pense qu'il faut se concentrer sur des données à fort potentiel au sein d'OSM (c'est à dire les plus attendues) et ne pas trop s'éparpiller car "qui trop embrasse mal étreint". Le 2 mars 2018 à 10:41, Magalie Dartus <mag.dar...@gmail.com> a écrit : > Pour l'agriculture par exemple il y a le RPG (Registre parcellaire > graphique), donnée ouverte par l'IGN (licence OL/LO): > http://professionnels.ign.fr/rpg > Certes cette données concerne la France mais vu que cela est lié à la PAC > (Politique Agricole Commune) il est probable de trouver la même chose pour > tous les pays européens. > > Je fais quelques recherches pour trouver d'autres données... à suivre > > -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Zones géographiques informelles
Le 24 février 2018 à 01:30, Jérôme Amagat <jerome.ama...@gmail.com> a écrit : > > > Le 23 février 2018 à 22:13, marc marc <marc_marc_...@hotmail.com> a écrit > : > >> Le 23. 02. 18 à 14:55, Jérôme Amagat a écrit : >> > comment ont fait pour différencier par exemple les Alpes et un de ses >> > massifs? >> >> name=Les Alpes <> name=le nom du massif ? :) >> > > Je parler bien sur de comment l'afficher sur un rendu ou comment s'en > servir d'une façon ou d'une autre si ce n'est qu'un node. (c'est pareil > avec le node name=Paris et name="un petit hameau" avec le nom on voit la > différence mais ça suffit pas) > Un node seul pourrait être suffisant, ce n'est pas le name=* qui va permettre au règles du rendu de décider de l'afficher ou pas, ce sont les autres tags. Pour Paris, ce sont des tags comme capital=* admin_level=*, mais aussi le nombre de tags ou d'autres critères qui peuvent servir à prioriser. Ceci dit, un polygone fournit quand même bien plus d'information (surface, mais pourquoi pas orientation générale), et permet comme ça a été indiqué de chercher des objets à l'intérieur ou à proximité de cette zone même si ses contours sont flous. Besoin de multipolygon ? Ils sont nécessaires si les way de contour dépassent 2000 noeuds (limite d'un way), mais avec autant de noeuds on est assez peu "flou" où si on a des trous ou discontinuité... Ils sont utiles (mais pas indispensables) si il y a une continuité topologique entre zones floues contigues ou si ils s'appuient sur des way existants (par exemple des frontières de limite de communes, mais on devient du coup là encore très peu "flou"). Dans les autres cas, c'est compliquer inutilement la modélisation pour rien (attention à la relationite). -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] JOSM transfert des nœuds et pas des chemins
Le 23 février 2018 à 22:35, marc marc <marc_marc_...@hotmail.com> a écrit : > Bonjour, > > Le 23. 02. 18 à 12:31, Christian Quest a écrit : > > JOSM n'est pas limité à 1 noeuds. Un changeset est limité à 5 > > objets et JOSM sait gérer ça (mon upload record c'est 400.000 objets). > > La limite du changeset a été baissé de 50k à 10k l'an passé > https://wiki.openstreetmap.org/w/index.php?title=API_v0. > 6=next=1431627 > $ wget -q -O - https://api.openstreetmap.org/api/capabilities > > josm sait gérer les multiples changeset mais il a aussi un mode > qui n’envoie qu'un changeset, c'est peut-être cela qui s'est passé. > > Oups, j'avais pas vu ça... ça montre bien à quel point c'est transparent ;) -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] JOSM transfert des nœuds et pas des chemins
JOSM n'est pas limité à 1 noeuds. Un changeset est limité à 5 objets et JOSM sait gérer ça (mon upload record c'est 400.000 objets). Le problème n'est pas technique, mais plus sur le principe. Il y a des règles à respecter pour importer des données dans OSM: - légales (on commence par vérifier la compatibilité des licences, je pense qu'il n'y a pas de souci ici) - collaboratives: on documente et on discute de l'import avec les contributeurs locaux... pour vérifier le bien fondé de celui-ci, travailler en semble à traiter les défauts, incohérences, conflits, etc - techniques: on fait des tests, on valide la méthode, là encore pas tout seul dans son coin, avant de se lancer... Il serait préférable que tu prépares quelques cours d'eau et mette les fichiers .osm correspondants en partage pour validation avant d'uploader quoi que ce soit, surtout vue la première manip. Le 23 février 2018 à 11:26, Rpnpif <rpn...@trob.eu> a écrit : > Le 22 février 2018, osm.sanspourr...@spamgourmet.com a écrit : > > > Le 22/02/2018 à 17:15, marc marc - marc_marc_...@hotmail.com a écrit : > > > > > Bonjour, > > > > > > Le 22. 02. 18 à 16:48, Rpnpif a écrit : > > >> Je suis novice dans JOSM. > > >> https://www.openstreetmap.org/changeset/56579562 > > >> Qu'en pensez-vous ? > > > J'annule et on repart de 0 ? :-) > > > > > > Cordialement, > > > Marc > > Je suis d'accord avec Marc, notamment la dernière proposition. > > Faire un import massif avec un outil que l'on ne connaît pas, faut être > > un peu gonflé ;-). > > J'ai pris un point au hasard > > https://www.openstreetmap.org/node/5429129253#map=17/47.67817/-0.94895 > > Je vois que c'est à proximité immédiate de La Verzée. > > Sur le site indiqué c'est un point de La Verzée. > > Donc deux possibilités : > > - l'info est meilleure > > - l'info est moins bonne (décalée ou pire). > > > > Dans le second cas la solution est simple ;-) > > Dans le premier il faut importer le bout de ruisseau et remplacer le > > bout équivalent existant (pour ne pas perdre les attributs). > > Ce n'est pas une opération triviale : il faut bien connaître JOSM et OSM. > > Donc à ne pas faire seule, cherche quelqu'un du côté de chez toi ou tu > > sauvegarde les modifications localement et tu demandes à quelqu'un sur > > la liste par exemple de vérifier. > > Bonjour, > > J'avais pris mes précautions et vérifier chaque nœud. > Quelques points étaient en doublon parce que mieux placés. J'ai effacé > dans JOSM tous ceux qui me semblaient apporter moins d'infos que ceux > qui existaient déjà. Sauf peut-être un ou deux ponts qui m'auraient > peut-être échappés sur La Verzée, je n'ai pas touché à cette rivière (ni > aux autres waterway=river) qui me semblaient bien tracée dans > l'ensemble. J'aurais ensuite revérifié et affiné directement sur la > carte en ligne. J'ai laissé des tracés d'origine qui me semblaient plus > précis sur la carte en ligne. > > Le but était d'abord et avant tout de placer les ruisseaux manquants. > Mais aucun way n'a été tranféré. J'ai encore le fichier d'origine qui > a été construit à l'aide d'un fichier SHP issu de la source qui est > fiable et relativement précise car vérifié progressivement sur le > terrain par les techniciens fonctionnaires. Il y des aspects légaux en > terme d'agriculture par exemple, derrière leur démarche. > > J'ai bien noté ce que recommande Marc Marc à propos de l'attribut > sources. Mais dans ce cas où doit-on mettre le source dans JOSM ? > Je ne savais pas que JOSM était limité à 1 nœuds (où trouve t-on > cette valeur ?). J'avais pourtant choisi une zone qui me semblait très > limitée par rapport à l'objectif. Il faudra que je le fasse à l'avenir > par tranche plus fine. > > > J'annule et on repart de 0 ? :-) > C'est-à-dire ? > > Puis-je refaire un essai avec un seul ruisseau ? > > Cordialement. > -- > Alain Rpnpif > > ___ > 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
Re: [OSM-talk-fr] Editer source d'un changeset existant
Il ne me semble pas... rien de prévu pour modifier les changesets et leurs tags Le 21 février 2018 à 14:18, François Lacombe <fl.infosrese...@gmail.com> a écrit : > Bonjour > > Hier soir je me suis fait prendre au piège de l'attribut source dans JOSM, > que je laisse défini à IGN BdOrtho + année > > Sauf que ce changeset est en Suisse et que la BD Ortho ils ne connaissent > pas. > https://www.openstreetmap.org/changeset/56534961 > > Est-ce possible d'éditer l'attribut source après coup pour ne pas laisser > cette erreur perdurer ? > Si non, serait-ce une fonctionnalité à prévoir ? Au moins pour ses propre > changesets > > > Bonne après-midi > > François > > ___ > 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
Re: [OSM-talk-fr] conflit de précision de données a cause d'une clé
Tagguer pour le rendu ou le routable n'est pas proscrit... c'est "mal tagguer" pour le rendu ou le routage qui l'est, c'est à dire utiliser des tags inadaptés, juste pour que ça ressorte sur le rendu ou pour modifier le routage ;) Ceci est juste une précision pour éviter les lectures au premier degré... Le 21 février 2018 à 13:46, Axelos <axe...@broman.fr> a écrit : > Le 21/02/2018 à 13:22, djakk djakk a écrit : > > Au fait, je remarque qu’on ne taggue pas pour le rendu, par contre on > > taggue pour le calcul d’itineraire :) > > > En effet c'est une perversion, promis j’arrête. Cependant j'ai de la > chance ça correspond avec les pratiques actuelles de balisage pour ce cas > :) > > ___ > 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
[OSM-talk-fr] wms.openstreetmap.fr était DOWN
J'ai remis en route ce service qui était down depuis quelques temps. Le disque du serveur a quelques problèmes ce qui oblige à intervenir en cas de redémarrage du serveur. J'ai commencé à migrer tout ça pour remplacer le disque et tout mettre à niveau. -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] conflit de précision de données a cause d'une clé
Des photos, des photos, il n'y a que ça pour se rendre compte de la situation. Si il y a un obstacle, on sépare les way, sinon, c'est un tag de plus sur le way unique. Qu'est-ce qu'on obstacle ? Pour moi tout ce qui oblige à faire un choix de passer "à gauche ou à droite" (donc routage) est un obstacle. Une bande réservée au stationnement est aussi pour moi un obstacle vu qu'on va devoir choisir par où passer. Sinon question toute bête concernant ce conflit d"édition... vous avez échangé quelques messages ? En expliquant bien on arrive souvent à converger... Le 21 février 2018 à 09:01, Axelos <axe...@broman.fr> a écrit : > Coucou, > > Le mieux pour te donner un avis, serait de nous mettre à disposition > quelques photos :) > > Concernant la réponse de Marc, de mémoire il considère que des > stationnements longitudinales qui séparent la chaussée principale pour > les automobilistes et piste cyclable ne constituent pas une séparation > physique et donc ne nécessite pas de créer deux chemins. > Mon avis sur ce type de situation est totalement à l’opposé :) > > La question serait plutôt que considère-t-on comme étant un obstacle ? > > Axel. > -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [Overpass] Tag universel pour tous commerces ?
Une rue n'est pas forcément décrite par une relation associatedStreet et ne décrit de toute façon par une "area" au sens overpass, c'est à dire une frontière délimitant un territoire. Il faudrait plutôt chercher le linéaire de la rue dans la commune, et chercher les noeuds (et way) à proximité. Je ne sais pas si on peut faire ça avec overpass. Le 19/02/2018 à 16:32, Shohreh a écrit : J'ai essayé ça, mais… "This map intentionally left blank. (received empty dataset)" :-/ = [out:json][timeout:25]; // 123 = relation de la rue cf. Nominatim rel(123);map_to_area -> .searchArea; ( node[shop](area.searchArea); node[office](area.searchArea); node[amenity](area.searchArea); ); out body; ; out skel qt; = Pourtant, j'ai déjà utilisé ce genre de requête par le passé. Une idée? -- 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 -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [Overpass] Tag universel pour tous commerces ?
Il n'y a pas de tag universel car la définition de "commerce" est un peu à géométrie variable. Veux-tu, par exemple, aussi inclure les cordonniers (craft=*), assureurs (office=*), marchands de journaux, etc ? Si on oublie OSM et qu'on regarde la base SIRENE et les codes activité (APE), c'est pareil... on a plsieurs grandes catégories à regrouper ou pas selon son usage. Je ne sais pas ce que tu veux faire de ces infos, mais si ce n'est pas purement lié ) OSM, regarde aussi la base SIRENE, en opendata depuis un an et géocodée chaque mois ;) Le 16 février 2018 à 00:26, Shohreh <codecompl...@free.fr> a écrit : > Bonjour, > > J'ai besoin d'envoyer un requête à OverpassTurbo pour récupérer tous les > commerces dans une rue. > > Existe-t-il un tag universel qui permettrait de ne pas avoir à lancer > plusieurs requêtes et fusionner les données? > > shop=* > amenity=restaurant > amenity=café > etc. > > Merci. > > > > -- > 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 > -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] *** BULK *** Re: Une alternative à Pakku ?
J'ai cherché "pakku" sur github, trouvé plein de chose, mais rien en rapport :( Un peu dommage ces projets qui s'appuient sur de l'open et qui ne sont pas si open... Le 14 février 2018 à 15:00, Vincent Bergeot <vinc...@bergeot.org> a écrit : > Le 14/02/2018 à 12:42, REBOUX Maël a écrit : > > Oui : le GROS avantage de Pakku c’était des données thématisées et prêtes > à l’emploi. > > Les outils BBIKE et donc Overpass on les connaît mais c’est déjà un niveau > « expert » et il y a des contraintes sur la taille des extractions. > > > oui je suis d'accord, l'interface de pakku avait l'avantage de sa > simplicité et de son ergonomie. > Est-ce qu'il existe des traces du travail qu'ils ont effectués, github ou > autres ? > > bonne journée > > > > > > > > C’était pour renvoyer qqn vers des données thématiques justement. > > > > Dommage pour Pakku alors. > > Merci pour vos réponses. > > > > > > *De :* Vincent Bergeot [mailto:vinc...@bergeot.org <vinc...@bergeot.org>] > *Envoyé :* mercredi 14 février 2018 10:29 > *À :* talk-fr@openstreetmap.org > *Objet :* *** BULK *** Re: [OSM-talk-fr] Une alternative à Pakku ? > > > > Le 14/02/2018 à 10:25, Corentin a écrit : > > Bonjour, > > Le site BBBbike permet des export dans différents formats en sélectionnant > une zone sur la carte. > > Voici le lien : https://extract.bbbike.org/ <https://extract.bbbike.org/> > > > idem que mon autre mail, c'est super bbike mais pakk.io c'est bien > géolocalisées et thématiques : https://www.data.gouv.fr/fr/ > reuses/pakku-io-lopen-data-geolocalise-pour-tous/ > > > > > > > > > > > Le 14 février 2018 à 10:22, Axelos <axe...@broman.fr> a écrit : > > Bonjour, > > > Le 14/02/2018 à 10:17, REBOUX Maël a écrit : > > Le site http://pakku.io/ qui permettait de télécharger des données OSM > pré-pakagées n'existe malheureusement plus. > > > > Existe-t-il une ou des alternatives ? > > > Je ne connaissais pas ce service, mais http://download.geofabrik.de/ > devrait pouvoir répondre à la demande. > > Cordialement, Axel. > > ___ > Talk-fr mailing list > Talk-fr@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-fr > > > > > -- > > -- > > Corentin LEMAITRE > > Consultant mobilité durable et urbanisme > > Présent sur LinkedIn <https://fr.linkedin.com/in/corentinlemaitre> et > Twitter <https://twitter.com/CorentinVelo> > > > > > ___ > > Talk-fr mailing list > > Talk-fr@openstreetmap.org > > https://lists.openstreetmap.org/listinfo/talk-fr > > > > -- > > Vincent Bergeot > > > > ___ > Talk-fr mailing > listTalk-fr@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-fr > > > -- > Vincent Bergeot > > > ___ > 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
Re: [OSM-talk-fr] Alternative à Umap pour intégrer couches dynamiques?
uMap peut afficher n'mporte quelle source dynamiquement, si elle fournit ses données dans un des formats géré par uMap (dont le geojson). Ceci n'est pas du tout limité à overpass, je l'utilise beaucoup pour afficher des données provenant d'OpenEventDatabase, et ces données sont dynamiques par nature vu que ce sont des événements. Exemples: - http://umap.openstreetmap.fr/fr/map/info-traffic-en-cours-5-dernieres-minutes-via-open_85813 - http://umap.openstreetmap.fr/fr/map/les-collectes-mobiles-de-don-du-sang-pour-aujourdh_95270 - http://umap.openstreetmap.fr/fr/map/carte-vigilance-meteo-via-openeventdatabase_84165 - http://umap.openstreetmap.fr/fr/map/observations-meteo-des-aeroportsaerodromes-metar-v_95779 - http://umap.openstreetmap.fr/fr/map/prevision-du-niveau-de-pollution-du-jour-via-opene_96136 Il faut faire attention aux réglages, il est par exemple souvent nécessaire d'activer la fonction proxy d'uMap. Une carte uMap peut aussi afficher les données d'une couche d'une autre uMap (vu qu'elles sont disponible en geojson), mais elle ne les fusionnera pas dans une couche unique et on perdra la mise en forme des objets. Le 5 février 2018 à 02:11, Shohreh <codecompl...@free.fr> a écrit : > Bonjour, > > Actuellement, différentes associations utilisent Umap chacune de son côté > pour créer des cartes. > > Problème : sauf erreur, Umap ne permet pas de créer des couches (layers) > dynamiques, c.a.d. avec un lien vers une couche d'une autre carte Umap. La > seule possibilité dynamique est d'interroger OSM via une requête Overpass. > > Y a-t-il une solution avec Umap, ou un autre outil qui permette ce genre de > chose? Ou faut-il imposer que toutes les associations travaillent sur une > seule et même carte Umap, chacune utilisant des couches différentes? > > Merci. > > > > -- > 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 > -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] positionnement des adresses et ménage
C'est reparti pour un tour... en oubliant un peu que: - une parcelle peut contenir plusieurs bâtiments (ou aucun), un bâtiment peut être à cheval sur plusieurs parcelles. - une parcelle peut être accessible par plusieurs adresses (ou aucune), une même adresse peut servir à plusieurs parcelles. - un bâtiment peut être accessible par plusieurs adresses (ou aucune) et une même adresse peut désservir plusieurs bâtiments. Voilà ce qui m'a amené à la conclusion après pas mal d'années à creuser ce sujet* que vouloir faire un lien 1/1 entre adresse et bâtiment était une fausse bonne idée. Dans beaucoup de cas ça va, mais on ne peut malheureusement pas généraliser ce lien. Je vois qu'en plus Marc ajoute en plus la notion d'adresse postale... qui est encore un autre sujet par rapport à l'adresse "administrative". Je ne sais pas quelle différence vous voyez entre les deux (il y en a, histoire de CP, de BP, TSA, Cédex et Cidex, etc), pour ma part, c'est un autre sujet qu'on peut ouvrir mais si on mélange on n'est pas sorti de l'auberge car sans ça le sujet est déjà suffisament compliqué. Je regrette aussi la forme... un long message c'est un gros risque de TL;DR (ce que j'ai fait, désolé). On essaye déjà de voir ce sur quoi on a un consensus avant de passer à l'étape suivante ? La première question à se poser à mon avis c'est "à quoi sert une adresse"... histoire que les réponses apportées dans notre façon de les modéliser puisse répondre à des besoins bien identifiés... et pour la suite il faudra penser "KISS" pour les contributeurs. * j'ai passé ma journée d'hier et une bonne partie d'aujourd'hui à tenter de géolocaliser la base des permis de construire mise en opendata hier. Comme les adresses sont très moches dans ce fichier (ça peut s'expliquer aussi par le fait qu'aucune adresse n'a été attribuée au moment du permis de construire, qu'elle le sera peut être plus tard), il faut remonter aux numéros de parcelles pour refaire un lien géographique... Ah oui, le ou les bâtiments arriveront eux aussi plus tard... peut être avant ou après l'attribution d'une adresse par le maire ;) Base au fort potentiel pour OSM... car on peut identifier assez tôt des changement à prévoir sur le terrain à l'aide de ces données, qui malheureusement ne sont disponibles que pour les personnes morales déposant des permis de construire (because CNIL chatouilleuse). -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Fwd: [OSM-Science] Openstreetmap background in scientific paper
La notion de produced work est valable dans le cadre de l'ODbL, donc vis à vis des données. En tout cas, il est faux de dire "OpenStreetMap derived products should be released under a CC-BY-SA licence" Si je fais un rendu des données OSM sous licence ODbL, je fais un produced work, je peux le mettre dans n'importe quelle licence car on n'est plus dans le cadre d'une database. Donc oui, c'est la licence choisie pour le rendu qui importe si c'est ça sur quoi tu t'appuie dans ta publication. Si il est en CC-by-SA, ça coince effectivement... sauf si on considère que ce n'est qu'une citation (car ce n'est pas une copie complète du rendu qui couvre sûrement le monde entier sur de multiples zoom). De quel rendu s'agit-il ? Il est aussi possible de demander à son auteur de faire jouer cette possibilité de citation. Il y a quand même beaucoup de publication qui ne se sont pas embarrassée de ce genre de chose, et côté OSM, on est plutôt très content de voir des cartes OSM dans des publications scientifiques ! Le 24/01/2018 à 15:56, Vincent Bergeot a écrit : Bonjour, occasion de diffuser l'info concernant cette nouvelle liste de discussion (scie...@openstreetmap.org : https://lists.openstreetmap.org/listinfo/science) Et avoir votre avis ? J'ai tendance à penser que cela dépend de la licence sur le rendu du fond qu'ils ont utilisé ? Message transféré Sujet : [OSM-Science] Openstreetmap background in scientific paper Dear all, I hope this my first question is pertinent to this new OSM list... We have recently submitted a scientific paper to an open access journal. One figure has an OpenStreetMap background, correctly attributed. One reviewer has argued that that figure can't be included in the paper because OpenStreetMap derived products should be released under a CC-BY-SA licence, while the paper will be released with a CC-BY licence. My point is to consider a figure with OSM background as a Produced work (https://wiki.osmfoundation.org/wiki/Licence/Community_Guidelines/Produced_Work_-_Guideline) and so not bounded to the SA condition. What are your experiences and suggestions with this (or similar) issue? -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] D281 en Loire-Atlantique
Pour le côté officiel ou non d'un nom on a official_name=* qui est là pour clairement indiquer si besoin qu'un nom est officiel (et différent de celui visible sur le terrain). alt_name=* est bien un nom alternatif à name=* et ne me semble pas utilisable si name=* n'est pas renseigné. Si cette route n'a pas de nom officiel, il me semble donc logique d'avoir name=Route des Chicanes Si elle a un nom officiel, le mettre en name=* at alt_name=Route des Chicanes On pourra du coup au moins retrouver cette route en la cherchant pas son nom même non officiel. Pour le côté accessible il me semble que c'est acces=* qui doit indiquer les restrictions d'accès, le highway=abandonned fait totalement disparaitre cette route vu que c'est un tag déprécié et peu utilisé donc non géré par les rendus ou calculs d'itinéraires. Merci à Stéphane pour son message (et ses contributions !) -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] positionnement des adresses et ménage
Le 23 janvier 2018 à 07:28, François Lacombe <fl.infosrese...@gmail.com> a écrit : > Il n'y a pas que le routage, pour du dénombrement et de l'inventaire ça a > aussi un sens de connaitre le lien adresse/bâtiment. > Pour la fibre, tous les bâtiments ont un identifiant... et ce n'est qu'un > exemple. > Ce qui n'existe pas, c'est le partage et la mise en commun, sinon aucun > doute que ce sont deja des choses qui ont été faites au moins 6 ou 10 fois. > Le problème c'est qu'il n'y a aucun identifiant unique (et stable) qui fasse référence... sujet pas très éloigné du problème des adresses où là il y a eu une prise de conscience, mais sur les bâtiments ça commence à faire surface. On en reparlera sûrement dans un avenir plus ou mois proche. -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] positionnement des adresses et ménage
Le 22/01/2018 à 12:48, marc marc a écrit : en résumé pour ceux qui ne lisent pas tout : il y a 2 visions pour le position des nœuds : le position pour le routing et celle pour le lien avec un bâtiment. la question est donc : pourrait-on enfin UNE méthode qui satisfasse les DEUX besoins : quel est l'adresse d'un bâtiment ET comment s'y rendre. C'est indispensable si on veux harmoniser. Le 22. 01. 18 à 11:32, Cyrille37 OSM a écrit : Le résumé de Christian pourrait être déposé délicatement, mais très visiblement, sur le wiki.openstreetmap.org ? L’existence d'une relation x-y entre les adresses et les bâtiments est déjà écrit sur la page wiki des adresses. Je veux bien me charger de mieux rédiger les arguments de ceux qui tagent pour le routing et de ceux qui tager pour le lien avec les bâtiments. J'étais visiblement pas assez clair... vouloir faire le lien avec le bâtiment est une fausse bonne idée. Cependant, j'aurais aimé naïvement que les partisans de la position en bord de parcelle prennent en compte le revers de la médaille : l'absence de lien entre le(s) bâtiment(s) et leur(s) adresse(s). Cela aurait permit de mettre en place une solution qui résout les 2 problèmes au lieu d'avoir 2 version qui ne résolvent que la moitié du problème. Je comprend d'autant moins qu'avec un (maigre) millier d'adresses à mon actif, ce que je propose n'a cependant rencontré aucun cas qui ne fonctionne pas. et pourtant je pense avoir croisé tous les cas. Faut pas s'attendre à voir une solution unique adoptée si elle casse ce que l'autre solution apporte. Dire que les autres ont tord ne suffit pas si on ne propose pas en même temps une solution globale aux 2 faces de la même pièce. C'est parce que la pièce à 3 faces... et même pas deux: adresses, parcelles, bâtiments. On ne peut pas résoudre les 2 (ni 3) d'un coup sans modéliser chaque type d'info à part. En voulant mélanger, on ne décrit ni l'un ni l'autre correctement. Pour rappel ma solution simple : Le lien addr-bâtiment pourrait se faire au choix : - soit en positionnant le nœud sur ou dans le contour du bâtiment (comme cela se fait déjà pour les maisons mitoyennes en zone urbaine dense... parfois ce n'est qu'une question de cm pour avoir ce lien !) Tu veux parler des maisons sur rues, avec la façade en bord de parcelle ? Elle ne sont pas forcément mitoyennes... et le point d'accès au domaine privé, n'est pas forcément sur la façade du bâtiment. - ou de l'aire concernée (comme cela se fait déjà souvent pour les écoles) En bord d'aire ? Au point d'accès donc entre domaine public et privé... on y revient ;) - soit en travaillant sur une relation style associatedAddr. Le routage est fait avec les routes (donc si on a un problème de routing pour se rendre à un bâtiment, on trace la route de déserte manquante). ___ Je ne comprends pas ce besoin qui me semble purement théorique. Pour le routage, on rentre quoi comme info ? Une adresse... et une adresse n'est pas un identifiant de bâtiment (chose qui n'existe pas vraiment actuellement). -- Christian Quest - OpenStreetMap France ___ 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
Ce problème est réglé, c'est la reprojection qu'il faut que je regarde un peu mieux. Mon week-end dernier a été occupé par un autre sujet... because nouveau jouet : https://www.thingiverse.com/thing:2760677 Le 19 janvier 2018 à 11:31, Vincent Frison <vincent.fri...@gmail.com> a écrit : > 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 > > -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] positionnement des adresses et ménage
tionne et >> d'éviter ainsi que les utilisateur encode des doublons lorsque le nœud >> se situe hors du bâtiment qui la concerne. >> Parce que pour le moment, aucune application ne donne l'adresse d'un >> bâtiment qui a un nœud adresse à x mètres. Nominatim se contente de >> déplacer ta demande au nœud le plus proche... qui est juste... ou pas. >> ___ >> 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 > -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Challenge ? Si on dégommait du rose ?
Le 13/01/2018 à 18:00, althio a écrit : Pour le millésime ou la date de prise de vue des imageries : - Bing donne la date en metadata, accessible dans iD "Vintage" et JOSM "capture date" - BDOrtho, la date est disponible ici : http://umap.openstreetmap.fr/fr/map/date-heure-des-prises-de-vues-aeriennes-de-la-bd-o_160764 Il faudrait que je mette ça à jour ;) Encore un truc pour la tout doux liste... -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Challenge ? Si on dégommait du rose ?
Le 13/01/2018 à 10:43, erwan salomon a écrit : je tombe sur pas mal de « nouveaux » quartier (donc plein de maisons à rajouter en plus) sur le cadastre (2015) mais rien de visible en orthophoto IGN dans certains cas je ne rajoute pas du coup si je vois des traces de construction je pars sur l’idée que depuis les photos ça a été construit En général, si les bâtiments sont sur le cadastre c'est qu'ils sont taxés, dont terminés. Dans ce cas, je les intègre et je met les voies en highway=residential (ou autre) Si par contre, on n'a pas les bâtiments sur le cadastre, je reste en highway=construction L'ortho est une confirmation pour la géométrie, on voit parfois les tracés en chantier pour les voies et les fondations de quelques bâtiments. mais s’il n’y a rien et pas de maisons au cadastre je me dis que le projet immobilier n’est peut-être pas encore en travaux je constate qu’il y a pas mal de chemin plus ou moins repérable (couloir d’herbes folles entre les parcelles) qui sont nommées dans le cadastres aussi, pas sûr qu’elles soit très praticables du coup un certain nombre de résolutions ne pourront se faire qu’en se rendant sur place Et oui, au final, le terrain, y'a que ça de vrai... mais parfois un peu loin ;) au rythme actuel on semble parti sur 6-9 mois de dégommage de violet … vous avez une source sous JOSM pour obtenir un cadastre plus récent que 2015 ? (j’utilise tes.cadastre.openstreetmap.fr mais ça semble bloqué à 2015) La couche cadastre est en principe à jour environ à 1 an près. pareil pour les photos aérienne ça tourne au mieux vers 2013 (Esri souvent un peu plus récent que IGN) Très variable d'un département à l'autre. La BD Ortho est mise à jour par tiers, et est publiée environ un an après la prise de vue, donc ça fait de 1 à 4 ans de décalage. Pour la résolution la plus élevée, on a parfois une prise de vue plus ancienne (c'est le cas actuellement sur le 89, mais sûrement aussi ailleurs). -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] changement possible de maxspeed en france au 1er juillet
Il faudra voir le décret lorsqu'il sera publié... là on est encore au stade "annonce". Le 11 janvier 2018 à 23:38, marc marc <marc_marc_...@hotmail.com> a écrit : > Le 11. 01. 18 à 22:53, osm.sanspourr...@spamgourmet.com a écrit : > > Quel maxspeed:type pour le type 80 "campagne" et le 90 voies séparées ? > c'est quoi exactement (mais en ultra résumé) la règle à venir ? > ___ > 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
Re: [OSM-talk-fr] Challenge ? Si on dégommait du rose ?
Panne du SSD d'osm13 (fin octobre) où je fais tourner la majorité de mes analyses. Certaines ne sont pas encore de retour, mais aucune en rapport avec l'issue. Le 8 janvier 2018 à 19:02, marc marc <marc_marc_...@hotmail.com> a écrit : > c'est quoi la panne en question ? > cela explique les autres analyses qui ne sont pas purgée ? > https://github.com/osm-fr/osmose-backend/issues/260 > > Le 08. 01. 18 à 17:51, Christian Quest a écrit : > > Il s'agit d'une autre analyse... et elle n'est pas à jour car pas encore > > remise en route depuis la panne du serveur en octobre dernier. > > > > Un truc de plus sur la tout doux liste :) > > > > Le 8 janvier 2018 à 14:16, Julien Lepiller a écrit : > > > > Voilà un faux positif (qui s'étend à toute la route) : > > > > https://osmose.openstreetmap.fr/fr/error/14087114258 > ___ > 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
Re: [OSM-talk-fr] Challenge ? Si on dégommait du rose ?
Il s'agit d'une autre analyse... et elle n'est pas à jour car pas encore remise en route depuis la panne du serveur en octobre dernier. Un truc de plus sur la tout doux liste :) Le 8 janvier 2018 à 14:16, Julien Lepiller <o...@lepiller.eu> a écrit : > Le 2018-01-08 09:33, erwan salomon a écrit : > >> Très bien cette analyse en effet >> pour le moment sur de l’urbain déjà bien à jour aucun faux positif >> des nouveau lotissement (enfin sur le cadastre de 2015 quand même) et >> des petits oublis >> je m’occupe de Lorient-Morbihan et je poursuivrais en m’éloignant >> progressivement >> par contre y’a du taff >> et quite à repérer des zone mal cartographié j’en profite pour faire >> du propre sur les voies, sinon on perd un bon repère >> du coup ça rallonge encore >> aller on dégomme du violet >> >> erwan [glyo] >> > > Voilà un faux positif (qui s'étend à toute la route) : > > https://osmose.openstreetmap.fr/fr/error/14087114258 > > L'erreur indique qu'il manque la référence D 197, mais elle y est depuis > plus d'un mois. > > >> Le 6 janv. 2018 à 15:29, Christian Quest <cqu...@openstreetmap.fr> a >>> écrit : >>> >>> Un petit bilan après une bonne dizaine de jours... >>> >>> L'analyse comparant la voirie du cadastre avec OSM est fort intéressante >>> ! >>> >>> En zone urbaine, elle permet de détecter de petites impasses, des >>> chemins, de nouveaux lotissements, etc. >>> En zone plus rurale, elle est aussi intéressante même si elle remonte >>> des chemins où le cadastre à prolongé le noms des rues, je pense souvent à >>> tort. >>> >>> Je vous la recommande donc après plus d'une semaine d'usage régulier, >>> elle ne m'a pas fait perdre de temps et trouvé des manques difficiles à >>> détecter sans être sur le terrain. >>> >>> http://osmose.openstreetmap.fr/fr/errors/?source=14708= >>> 7170=13 <http://osmose.openstreetmap.f >>> r/fr/errors/?source=14708=7170=13> >>> <http://osmose.openstreetmap.fr/fr/errors/?source=14708 >>> m=7170=13> >>> Les principaux défauts sur les rond-points et places sont résolus... il >>> n'y a que les grands rond-points tronçonnés (beurk) qui peuvent ne pas être >>> détectés. >>> >>> -- >>> 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 >> > > ___ > 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
Re: [OSM-talk-fr] Rendu avec relief sur osm.fr
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... 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. Sur certaines forêts, on distingue aussi comme une marche. Le 7 janvier 2018 à 21:52, Christian Quest <cqu...@openstreetmap.fr> a écrit : > Le calcul est trop long pour être fait à la demande, et comme le MNT ne > change pas, on peut calculer la couche d'ombrage une fois pour toute, même > si ça prends quelques jours, pas pire que l'import d'une base OSM monde > pour du rendu :) > > Pour les courbes de niveau c'est différent. On calcule les données > vectorielles à partir du MNT et on les stock en base, avec un index > géographique. Elle seront ajoutées lors du rendu global, ou bien on peut > faire un rendu de ces seules courbes de niveau. > > J'ai quelques machines et disques... il vaut mieux ne pas faire le > décompte ;) > > > > Le 7 janvier 2018 à 21:01, Vincent Frison <vincent.fri...@gmail.com> a > écrit : > >> 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 >> >> > > > -- > Christian Quest - OpenStreetMap France > -- Christian Quest - OpenStreetMap France ___ 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
Le calcul est trop long pour être fait à la demande, et comme le MNT ne change pas, on peut calculer la couche d'ombrage une fois pour toute, même si ça prends quelques jours, pas pire que l'import d'une base OSM monde pour du rendu :) Pour les courbes de niveau c'est différent. On calcule les données vectorielles à partir du MNT et on les stock en base, avec un index géographique. Elle seront ajoutées lors du rendu global, ou bien on peut faire un rendu de ces seules courbes de niveau. J'ai quelques machines et disques... il vaut mieux ne pas faire le décompte ;) Le 7 janvier 2018 à 21:01, Vincent Frison <vincent.fri...@gmail.com> a écrit : > 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 > > -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Modification de couverture du sol du côté de Pau
Avec des données chargées partiellement via overpass, l'éditeur (JOSM) ne peut pas savoir à quelles relations ces objets appartiennent sauf à aller interroger l'API OSM ou sauf si on avait intégré les relations parent dans la requête pour tous les objets retournés... bref, un gros bazar. C'est pour ça qu'il faut revenir à un principe simple: pas d'édition de géométrie si on n'a pas chargé les données de la zone... les hachures c'est pas pour rien qu'elles sont là dans JOSM. Est-ce que JOSM pourrait aller plus loin dans ses contrôles pour empêcher ce genre d'édition ? Fort probable. Le 7 janvier 2018 à 12:43, <osm.sanspourr...@spamgourmet.com> a écrit : > > ARGH. > > > > Ne JAMAIS faire des éditions modifiant les géométries si on n'a pas > chargé > > intégralement les données de la zone. > > > > C'est une règle de base qu'il faudrait répéter et répéter. > C'est surtout un avertissement que les éditeurs devraient gérer, style sur > tentative de modifier une géométrie utilisée par une relation, vérifier que > la relation est entièrement chargée ou proposer de la charger. Et > n'accepter de modifier que dans ce cas ou après confirmation de > l'utilisateur qu'il sait ce qu'il fait. > Jean-Yvon > > > ___ > 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
Re: [OSM-talk-fr] Modification de couverture du sol du côté de Pau
Le 7 janvier 2018 à 02:12, marc marc <marc_marc_...@hotmail.com> a écrit : > Il y a en permanence un nombre important de polygone ouvert. > 319 en France en ce moment > https://osmose.openstreetmap.fr/fr/errors/?country=france*=1040 > Depuis 2 semaines je passe un peu de temps à en corriger. > La seule cause récente trouvée dans ceux dont j'ai trouvé l'origine > précise vient contre tout attente vient d'utilisateur sous josm. > Il suffit de télécharger une relation via overpass (au hasard une ligne > de bus). de couper un chemin qui la compose (au hasard découpe > conflictuel pour le rendu d'un rond-point) pour se retrouver avec une > cassure dans les autres relations qui utilisent ces chemins. > ARGH. Ne JAMAIS faire des éditions modifiant les géométries si on n'a pas chargé intégralement les données de la zone. C'est une règle de base qu'il faudrait répéter et répéter. Pas de problème si c'est juste pour modifier des attributs. -- Christian Quest - OpenStreetMap France ___ 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
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. -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] OSM embarque dans l'IRIS 320
Usage privé, rendu public c'est vrai avec ce reportage, mais ce n'est pas l'objectif initial ;) Le 6 janvier 2018 à 18:05, François Lacombe <fl.infosrese...@gmail.com> a écrit : > Pour info, peut-être que cela avait déjà été constaté > https://twitter.com/InfosReseaux/status/949685820289638400 > > Le train en question semble être unique en Europe, en assurant ses > tournées d'inspection en s'insérant dans le trafic à grande vitesse. > > Je n'ai pas voulu mentionner que je ne voyais pas d'attributions sur les > captures, peut-être est-ce mentionné dans la page "about" des softs. > > François > > ___ > 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
Re: [OSM-talk-fr] Modification de couverture du sol du côté de Pau
J'ai refermé ce multipolygone... Le 6 janvier 2018 à 16:29, JB <jb...@mailoo.org> a écrit : > Bonjour, > Le fait que le way n'ait pas de tag est normal. Les tags sont portés par > la relation : http://www.openstreetmap.org/relation/276616 > Cette relation n'est pas fermée : les membres outer ne forment pas de > boucle. Du coup, elle est impossible à rendre. > J'aurais bien montré ça, mais il semblerait que l'analyseur ne fonctionne > pas : http://api.openstreetmap.fr/analyse/cgi-bin/index.py > Je n'ai pas réparé pour que tu puisses regarder. Un coup de JOSM et de la > motivation si nécessaire, et ça peut repartir. > JB. > > > Le 06/01/2018 à 15:53, orhygine a écrit : > > Salut à tous, > > Je constate du côté de Pau une modification au niveau de la couverture du > sol dans cette zone : > > https://www.openstreetmap.org/#map=13/43.3570/-0.3401 > > Entre les zoom 12 et 13, la couleur de couverture du sol passe de beige à > gris. Il semblerait qu'une modification ait eu lieu, non encore répercutée > sur tous les niveaux de zoom. > > Cela pourrait venir d'une modification intervenue sur le way 41766403 : > > https://aleung.github.io/osm-visual-history/#/way/41766403 > > A la modification 41, des tags ont été supprimés mais cela commence à > dater... > > Les multipolygones CLC étant une science à part entière, un expert du > domaine peut-il donner son avis ? > > Salutations. > > -- > Christophe aka orhygine | http://orhyginal.free.fr | > > > ___ > 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 > > -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Challenge ? Si on dégommait du rose ?
Un petit bilan après une bonne dizaine de jours... L'analyse comparant la voirie du cadastre avec OSM est fort intéressante ! En zone urbaine, elle permet de détecter de petites impasses, des chemins, de nouveaux lotissements, etc. En zone plus rurale, elle est aussi intéressante même si elle remonte des chemins où le cadastre à prolongé le noms des rues, je pense souvent à tort. Je vous la recommande donc après plus d'une semaine d'usage régulier, elle ne m'a pas fait perdre de temps et trouvé des manques difficiles à détecter sans être sur le terrain. http://osmose.openstreetmap.fr/fr/errors/?source=14708=7170=13 <http://osmose.openstreetmap.fr/fr/errors/?source=14708=7170=13> Les principaux défauts sur les rond-points et places sont résolus... il n'y a que les grands rond-points tronçonnés (beurk) qui peuvent ne pas être détectés. -- Christian Quest - OpenStreetMap France ___ 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
Le 5 janvier 2018 à 21:52, Vincent Frison <vincent.fri...@gmail.com> a écrit : > > > Le 5 janvier 2018 à 20:21, Christian Quest <cqu...@openstreetmap.fr> 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... > > Ok, on va avancer pas à pas alors... plutôt que de vouloir le truc parfait dès le début ;) Le truc parfait c'est l'ombrage et les courbes de niveau directement intégrées dans les tuiles de fond de carte. On peut démarrer avec 2 overlay: - courbes de niveau - ombrage voire... une couche ombrage+courbes de niveau Ensuite on intégrera dans les tuiles > 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 ? > > tile.openstreetmap.fr était avant tout destiné à visualiser les tuiles FR, et puis on a rajouter des trucs dessus... mais on n'a jamais repensé le tout (et surtout eu la dispo pour ça, parce que des idées ça manque pas). > 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 -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
