Re: [OSM-talk-fr] conflit de précision de données a cause d'une clé

2018-02-20 Par sujet djakk djakk 
Moi je dirai qu’on met cycleway='track' quand on a pas le temps d’être
précis.

djakk

Le mar. 20 févr. 2018 à 20:14, Francescu GAROBY  a
écrit :

> En l'occurrence, je vois qu'il a notamment fusionné la piste cyclable qui
> longe le Cours Montalivet avec ce dernier. C'est une erreur ! Il y a une
> rangée d'arbres, sur un parterre large de 2m, qui sépare ces 2 axes.
> Il faut lui dire d'arrêter ça.
>
> Francescu
>
> Le 20 février 2018 à 20:12, marc marc  a écrit
> :
>
>> Le 20. 02. 18 à 19:58, David Crochet a écrit :
>> > Cette clé "cycleway=track", bien que correct, définit moins que la piste
>> > décrite elle-même puisqu'en étant séparé de la voie routière, on peut
>> > définir sa matière de surface ainsi.
>>
>> non, il n'y a pas de différente entre les 2 pour les tags.
>> on peux tout aussi bien décrire tous les caractéristiques avec 2 chemins
>> qu'avec un seul en utilisant les namespaces comme cycleway:surface=*
>> la différence n'est pas là.
>>
>> > Bref, il est partisan de cette clé associé à la voie routière, je suis
>> > partisan de l'autre façon et de le décrire de façon indépendante.
>>
>> c'est un problème sans fin, on en a parlé longuement il y a moins de 2
>> mois ici même.
>> dans osm, la convention est supposé de ne séparer un way en 2 que
>> lorsqu'il y a un obstacle entre les 2 qui empche de passer de l'un
>> à l'autre.
>> c'est capital pour le routing et c'est la seule façon qui fonctionne
>> correctement pour le routing. (=il n'y a pour le moment aucune
>> proposition qui a aboutie pour dire que 2 way séparé sont "sans obstacle
>> entre eux)
>>
>> maintenant d'autres ont envie de gagner qlq cm dans la localisation de
>> la piste cyclable ou du trottoir et ont font 2 way séparés.
>> cette amélioration du rendu se fait selon moi au détriment du routing.
>> donc on dégrade l'un pour améliorer l'autre.
>>
>> Je pense que la seule solution est qu'un partisan de ce schéma travaille
>> pour faire une proposition qui résolve les problèmes de routing qu'elle
>> provoque. car ces propals sont au points mort.
>>
>> Cordialement,
>> Marc
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>
>
>
> --
> Francescu
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] conflit de précision de données a cause d'une clé

2018-02-20 Par sujet Francescu GAROBY 
En l'occurrence, je vois qu'il a notamment fusionné la piste cyclable qui
longe le Cours Montalivet avec ce dernier. C'est une erreur ! Il y a une
rangée d'arbres, sur un parterre large de 2m, qui sépare ces 2 axes.
Il faut lui dire d'arrêter ça.

Francescu

Le 20 février 2018 à 20:12, marc marc  a écrit :

> Le 20. 02. 18 à 19:58, David Crochet a écrit :
> > Cette clé "cycleway=track", bien que correct, définit moins que la piste
> > décrite elle-même puisqu'en étant séparé de la voie routière, on peut
> > définir sa matière de surface ainsi.
>
> non, il n'y a pas de différente entre les 2 pour les tags.
> on peux tout aussi bien décrire tous les caractéristiques avec 2 chemins
> qu'avec un seul en utilisant les namespaces comme cycleway:surface=*
> la différence n'est pas là.
>
> > Bref, il est partisan de cette clé associé à la voie routière, je suis
> > partisan de l'autre façon et de le décrire de façon indépendante.
>
> c'est un problème sans fin, on en a parlé longuement il y a moins de 2
> mois ici même.
> dans osm, la convention est supposé de ne séparer un way en 2 que
> lorsqu'il y a un obstacle entre les 2 qui empche de passer de l'un
> à l'autre.
> c'est capital pour le routing et c'est la seule façon qui fonctionne
> correctement pour le routing. (=il n'y a pour le moment aucune
> proposition qui a aboutie pour dire que 2 way séparé sont "sans obstacle
> entre eux)
>
> maintenant d'autres ont envie de gagner qlq cm dans la localisation de
> la piste cyclable ou du trottoir et ont font 2 way séparés.
> cette amélioration du rendu se fait selon moi au détriment du routing.
> donc on dégrade l'un pour améliorer l'autre.
>
> Je pense que la seule solution est qu'un partisan de ce schéma travaille
> pour faire une proposition qui résolve les problèmes de routing qu'elle
> provoque. car ces propals sont au points mort.
>
> Cordialement,
> Marc
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>



-- 
Francescu
___
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é

2018-02-20 Par sujet marc marc 
Le 20. 02. 18 à 19:58, David Crochet a écrit :
> Cette clé "cycleway=track", bien que correct, définit moins que la piste 
> décrite elle-même puisqu'en étant séparé de la voie routière, on peut 
> définir sa matière de surface ainsi.

non, il n'y a pas de différente entre les 2 pour les tags.
on peux tout aussi bien décrire tous les caractéristiques avec 2 chemins 
qu'avec un seul en utilisant les namespaces comme cycleway:surface=*
la différence n'est pas là.

> Bref, il est partisan de cette clé associé à la voie routière, je suis 
> partisan de l'autre façon et de le décrire de façon indépendante.

c'est un problème sans fin, on en a parlé longuement il y a moins de 2 
mois ici même.
dans osm, la convention est supposé de ne séparer un way en 2 que 
lorsqu'il y a un obstacle entre les 2 qui empche de passer de l'un
à l'autre.
c'est capital pour le routing et c'est la seule façon qui fonctionne 
correctement pour le routing. (=il n'y a pour le moment aucune 
proposition qui a aboutie pour dire que 2 way séparé sont "sans obstacle 
entre eux)

maintenant d'autres ont envie de gagner qlq cm dans la localisation de 
la piste cyclable ou du trottoir et ont font 2 way séparés.
cette amélioration du rendu se fait selon moi au détriment du routing.
donc on dégrade l'un pour améliorer l'autre.

Je pense que la seule solution est qu'un partisan de ce schéma travaille 
pour faire une proposition qui résolve les problèmes de routing qu'elle 
provoque. car ces propals sont au points mort.

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

[OSM-talk-fr] conflit de précision de données a cause d'une clé

2018-02-20 Par sujet David Crochet 

Bonjour

Je suis en conflit d'édition, ou plutot de précision de données.

En effet, un contributeur retire les pistes cyclables pour les intégrer 
aux voies routières adjacentes. Ceci en utilisant un clé qui est en fait 
la source du conflit "cycleway=track"


https://www.openstreetmap.org/changeset/56522407

https://www.openstreetmap.org/changeset/56528558

https://www.openstreetmap.org/changeset/56524173.

Cette clé "cycleway=track", bien que correct, définit moins que la piste 
décrite elle-même puisqu'en étant séparé de la voie routière, on peut 
définir sa matière de surface ainsi.


Bref, il est partisan de cette clé associé à la voie routière, je suis 
partisan de l'autre façon et de le décrire de façon indépendante.


Qu'en pensez-vous ?

Cordialement

--
David Crochet


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

Re: [OSM-talk-fr] *** BULK *** Re: Une alternative à Pakku ?

2018-02-20 Par sujet Stéphane Péneau 

Personne n'a contacté la personne qui s'occupait de ce service ?
https://twitter.com/TFarneau


Le 15/02/2018 à 09:07, Vincent Bergeot a écrit :

Le 15/02/2018 à 07:35, Christian Quest a écrit :
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...


j'ai creusé un peu aussi, d'autant plus dommage car :

http://www.modernisation.gouv.fr/salle-de-presse/communiques-de-presse/concours-dataconnexions-6-palmares
"Impact économique et scientifique
« Pakku.io », par Pakku
Basé sur un algorithme, Pakku génère des jeux de données géographiques 
dans divers formats, basés sur les bases de données OpenStreetMap et 
sous licence ODbL 1.0. Ainsi, il est possible de créer des sets comme 
« Bars en Ain », « Aéroports en Loire-Atlantique » en quelques 
secondes, dans les formats les plus utilisés (xml, json, geojson, 
bientôt shp ...). Ces sets sont ensuite classés et distribués sur 
Pakku.io, via une interface simple d’utilisation. Chaque set dispose 
d’un aperçu et est bien documenté, pour que l’utilisateur sache 
immédiatement si les données sont intéressantes pour lui ou non. En un 
mot, Pakku est là pour encourager l’utilisation de l’open-data en vous 
simplifiant la vie.


Orange, Ambition Toulouse Métropole, Digital Place s’associent au 
lauréat de cette catégorie en lui apportant pour l’année 2016 :


    Orange fournira une station Netatmo et un coaching Innovation à 
Paris ou en visio, avec la possibilité d’assister aux sessions de 
formation de l’Orange Fab France.
    Ambition Toulouse Métropole permettra au lauréat de participer à 
des workshops techniques, c'est-à-dire 1 ou 2 séances de travail avec 
des ingénieurs d’ERDF pour étudier la faisabilité et faire progresser 
le projet.
    Digital Place accompagnera à l'étude de faisabilité du projet, et 
donnera accès aux ateliers adhérents Bigdata."


et une recherche sur le whois montre que le nom pakku.io est disponible !

Quelqu'un connaît ces 2 personnes : 
https://www.data.gouv.fr/fr/organizations/pakku/#members


à plus











Le 14 février 2018 à 15:00, Vincent Bergeot > 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]
*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/



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 mailto: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
 et Twitter





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


-- 
Vincent Bergeot



___
Talk-fr mailing list
Talk-fr@opens

Re: [OSM-talk-fr] Itinéraires et balisages randonnée

2018-02-20 Par sujet David Marchal 
Pas l’intention de reverser ? Ouais, ça m’aurait étonné… Et tant pis si ça 
favoriserait la randonnée, ce qui est exactement leur but déclaré, pourtant.


Pour le balisage, je pensais à la propriété intellectuelle : le balisage FFRP, 
même fait par des tiers, reste propriété intellectuelle de la FFRP, ce qui 
induit un risque juridique pour ceux qui les représenteraient en partant des 
données OSM sur ces itinéraires.

Un truc qui m’étonne, en passant : ce sont des associations d’utilité publique, 
et elles ont le droit de nous interdire de publier leur travail pour en 
faciliter l’usage ? Quelle est l’utilité publique de cette pratique ? Certes, 
ils pensent éviter une diminution de revenus, mais serait-ce vraiment le cas ? 
Un truc qui pourrait aider à les convaincre, ce serait des témoignages d’autres 
associations de randonneurs qui ont laissé leurs itinéraires être publiés sur 
OSM sans conséquences négatives pour eux ; il n’y en avait pas au Bénélux dans 
ce cas là ? Une demande de témoignage de leur part pourrait être très utile à 
l’avenir.

Cordialement.

De : Jean-Claude Repetto 
Envoyé : lundi 19 février 2018 17:40
À : Discussions sur OSM en français
Cc : David Marchal
Objet : Re: [OSM-talk-fr] Itinéraires et balisages randonnée

J'ai discuté avec un président départemental de la FFRP lors de
l'annonce de leur "projet numérique", en juillet 2013. Leur but était de
valoriser le travail de leurs bénévoles afin de compenser la baisse des
subventions aux associations (par exemple en éditant plus de
topo-guides). Donc ils n'ont aucune intention de reverser ce travail à
une base de données libre comme OSM.

Dans le 06, le balisage des PR est fait par le département. Donc je ne
pense pas que la FFRP en soit propriétaire.

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

Re: [OSM-talk-fr] Une alternative à Pakku ?

2018-02-20 Par sujet Nicolas Moyroud 

Bonjour à tous,

J'avais développé il y a 2-3 ans un code d'extraction de données 
thématiques depuis OSM. L'idée était de générer des couches SIG dans 
différents formats (Shape, GPX, KML, GeoJSON) à partir de la définition 
de jeu de tags OSM. Les fichiers générés étaient déposés sur un FTP. Le 
tout était codé en bash en utilisant les fichiers geofabrik, osmosis, 
gdal/ogr et postgis et tournait sur un serveur Linux/Debian. Les 
extractions étaient réalisées une fois par semaine grâce à une tâche 
cron et uniquement sur le territoire de l'ex-région 
Languedoc-Roussillon. Il faudrait tester mais je pense qu'on pourrait 
sans trop de mal le faire tourner sur toutes les régions françaises. Le 
code n'était pas trop optimisé (et pas très propre non plus...) et les 
régions ont un peu grossi depuis les fusions mais il faudrait voir ce 
que ça donne. Ça ne fonctionne plus car mon organisme a verrouillé les 
accès externes sur plusieurs serveurs dont celui sur lequel j'avais tout 
mis en place...


Si l'asso OSM-France a un serveur Linux qui peut faire l'affaire et me 
donne un accès root, je peux essayer d'y mettre en place mon bousin pour 
voir. On pourrait y monter un service de mise à disposition de données 
thématiques à destination des géomaticiens.


Nicolas

Le 14/02/2018 à 10:17, REBOUX Maël a écrit :


Bonjour,

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 ?




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