Re: [OSM-talk-fr] Nouvelles bornes Trilib'

[Florian LAINEZ]

Le 21 décembre 2016 à 23:13,  a écrit :

> Fin du monologue ;-).


Enfin quelqu'un qui a pitié de moi ! Merci.
Très bonne suggestion, j'ai changé pour brand=Trilib'

Je me suis baladé hier et je vais terminer la collecte intégrale
aujourd'hui. C'est ici : https://www.cartes.xyz/t/fcd984-Bornes_Trilib#

-- 

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

Re: [OSM-talk-fr] Données du STIF sur Osmose

[Ralf Treinen]

Bonjour,

On Thu, Dec 22, 2016 at 09:25:58PM +0100, Noémie Lehuby wrote:

> Et malgré ça, j'avais quand même un peu plus d'un cas sur 6 où l'arrêt
> opendata le plus proche n'était pas le bon mais celui de l'autre côté de la
> route.

je rencontre les mêmes difficultés, et aussi une confusion entre les 
arrêts différents de lignes de bus différentes, et portant le même
nom. On peut demeler les derniers facilement grace au fichier 
liste-arrets-lignes-tc-idf.csv, mais je me demande comment trouver une
information fiable sur le sens de la ligne qui dessert un arrêt de bus
(le problème évoqué par Noémie). Par exemple, pour l'arrêt "Bibliothèque
Rue Mann" de la ligne RATP 62, je trouve

$ grep RATP liste-arrets-lignes-tc-idf.csv | grep ';62;' | grep
'BIBLIOTHEQUE RUE MANN'
RATP;100100062:62;62;62;3;StopPoint:59:3887745;BIBLIOTHEQUE RUE
MANN;48.829293;2.378153;24009;C01098;48.829293, 2.378153
RATP;100100062:62;62;62;3;StopPoint:59:3887746;BIBLIOTHEQUE RUE
MANN;48.828817;2.378112;24013;C01098;48.828817, 2.378112

et la seule différence exploitable que je vois entre les deux est que
le premier est un plus au nord, et doit donc être celui du sens
est->ouest de la ligne. Est-ce qu'il y un autre moyen ?

-Ralf.

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

Re: [OSM-talk-fr] Données du STIF sur Osmose

[Christian Quest]

Le terrain... y'a que ça qui tranchera au final de toute façon car entre
les arrêts présents dans OSM parfois provenant de vues aériennes plus à
jour (les arrêts de bus sont faciles à déplacer) et les données opendata
pas bien précises, on ajoute facilement une info inexacte.

Ce jeu de donnée est utile pour détecter des arrêts manquants, mais rentrer
plus dans le détail sans vérifier sur place me semble malheureusement un
peu trop optimiste.

A mon avis il faut revoir cette proposition d'intégration dans osmose ou
alors la laisser en "dev" pour tester le temps d'affiner ça.



Le 23 décembre 2016 à 09:26, Ralf Treinen  a écrit :

> Bonjour,
>
> On Thu, Dec 22, 2016 at 09:25:58PM +0100, Noémie Lehuby wrote:
>
> > Et malgré ça, j'avais quand même un peu plus d'un cas sur 6 où l'arrêt
> > opendata le plus proche n'était pas le bon mais celui de l'autre côté de
> la
> > route.
>
> je rencontre les mêmes difficultés, et aussi une confusion entre les
> arrêts différents de lignes de bus différentes, et portant le même
> nom. On peut demeler les derniers facilement grace au fichier
> liste-arrets-lignes-tc-idf.csv, mais je me demande comment trouver une
> information fiable sur le sens de la ligne qui dessert un arrêt de bus
> (le problème évoqué par Noémie). Par exemple, pour l'arrêt "Bibliothèque
> Rue Mann" de la ligne RATP 62, je trouve
>
> $ grep RATP liste-arrets-lignes-tc-idf.csv | grep ';62;' | grep
> 'BIBLIOTHEQUE RUE MANN'
> RATP;100100062:62;62;62;3;StopPoint:59:3887745;BIBLIOTHEQUE RUE
> MANN;48.829293;2.378153;24009;C01098;48.829293, 2.378153
> RATP;100100062:62;62;62;3;StopPoint:59:3887746;BIBLIOTHEQUE RUE
> MANN;48.828817;2.378112;24013;C01098;48.828817, 2.378112
>
> et la seule différence exploitable que je vois entre les deux est que
> le premier est un plus au nord, et doit donc être celui du sens
> est->ouest de la ligne. Est-ce qu'il y un autre moyen ?
>
> -Ralf.
>
> ___
> 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] Données du STIF sur Osmose

[Frédéric Rodrigo]

J'ai le même sentiment.
Ok je désactive. Ça sera effectif dans quelques jours.

Frédéric.


Le 23/12/2016 à 09:26, Ralf Treinen a écrit :

Bonjour,

On Thu, Dec 22, 2016 at 09:25:58PM +0100, Noémie Lehuby wrote:


Et malgré ça, j'avais quand même un peu plus d'un cas sur 6 où l'arrêt
opendata le plus proche n'était pas le bon mais celui de l'autre côté de la
route.

je rencontre les mêmes difficultés, et aussi une confusion entre les
arrêts différents de lignes de bus différentes, et portant le même
nom. On peut demeler les derniers facilement grace au fichier
liste-arrets-lignes-tc-idf.csv, mais je me demande comment trouver une
information fiable sur le sens de la ligne qui dessert un arrêt de bus
(le problème évoqué par Noémie). Par exemple, pour l'arrêt "Bibliothèque
Rue Mann" de la ligne RATP 62, je trouve

$ grep RATP liste-arrets-lignes-tc-idf.csv | grep ';62;' | grep
'BIBLIOTHEQUE RUE MANN'
RATP;100100062:62;62;62;3;StopPoint:59:3887745;BIBLIOTHEQUE RUE
MANN;48.829293;2.378153;24009;C01098;48.829293, 2.378153
RATP;100100062:62;62;62;3;StopPoint:59:3887746;BIBLIOTHEQUE RUE
MANN;48.828817;2.378112;24013;C01098;48.828817, 2.378112

et la seule différence exploitable que je vois entre les deux est que
le premier est un plus au nord, et doit donc être celui du sens
est->ouest de la ligne. Est-ce qu'il y un autre moyen ?

-Ralf.

___
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] Nouvelles bornes Trilib'

[Stéphane Péneau]

Je m'incruste aussi :-)

Au fait, tu mets
recycling:glass=yes
mais je pense que c'est plutôt
recycling:glass_bottles=yes

Bonne balade !

Stf




Le 23/12/2016 à 09:20, Florian LAINEZ a écrit :


Le 21 décembre 2016 à 23:13, > a écrit :


Fin du monologue ;-).


Enfin quelqu'un qui a pitié de moi ! Merci.
Très bonne suggestion, j'ai changé pour brand=Trilib'

Je me suis baladé hier et je vais terminer la collecte intégrale 
aujourd'hui. C'est ici : 
https://www.cartes.xyz/t/fcd984-Bornes_Trilib# 



--

*Florian Lainez*

@overflorian 


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



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

[OSM-talk-fr] problème sur serveur(s) wms.openstreetmap.fr ?

[Blake Girardot]

Bonjour

Le serveur d'image wms.openstreetmap.fr ne fonctionne pas.
J'utilise les URLs de JOSM.
Erreur 502 pour toutes les tuiles.
J'ai testé toutes les images de wms.openstreetmap.fr et elles
renvoient toutes 502 erreurs. D'autres personnes rapportent le même
problème.

Merci,
Blake

-- 

Blake Girardot
OSM Wiki - https://wiki.openstreetmap.org/wiki/User:Bgirardot
HOTOSM Member - https://hotosm.org/users/blake_girardot
skype: jblakegirardot

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

Re: [OSM-talk-fr] problème sur serveur(s) wms.openstreetmap.fr ?

[Jean-Guilhem Cailton]

Le 23/12/2016 à 13:06, Blake Girardot a écrit :
> Bonjour
>
> Le serveur d'image wms.openstreetmap.fr ne fonctionne pas.
> J'utilise les URLs de JOSM.
> Erreur 502 pour toutes les tuiles.
> J'ai testé toutes les images de wms.openstreetmap.fr et elles
> renvoient toutes 502 erreurs. D'autres personnes rapportent le même
> problème.
>
> Merci,
> Blake
>

Bonjour Blake,

Christian a déjà répondu à une question sur le même sujet la semaine
dernière :
https://lists.openstreetmap.org/pipermail/talk-fr/2016-December/082886.html

Courtoisement,

Jean-Guilhem

-- 
"Corruption is the abuse of entrusted power for private gain."
Transparency International
https://www.transparency.org/whatwedo/publication/preventing_corruption_in_humanitarian_operations
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] problème sur serveur(s) wms.openstreetmap.fr ?

[Blake Girardot]

Merci beaucoup Jean-Guilhem.

Mon google recherche dans la liste des archives n'a pas trouvé ce
message, je m'excuse pour la peine.

Cheers,
Blake

2016-12-23 14:14 GMT+01:00 Jean-Guilhem Cailton :
> Le 23/12/2016 à 13:06, Blake Girardot a écrit :
>
> Bonjour
>
> Le serveur d'image wms.openstreetmap.fr ne fonctionne pas.
> J'utilise les URLs de JOSM.
> Erreur 502 pour toutes les tuiles.
> J'ai testé toutes les images de wms.openstreetmap.fr et elles
> renvoient toutes 502 erreurs. D'autres personnes rapportent le même
> problème.
>
> Merci,
> Blake
>
>
> Bonjour Blake,
>
> Christian a déjà répondu à une question sur le même sujet la semaine
> dernière :
> https://lists.openstreetmap.org/pipermail/talk-fr/2016-December/082886.html
>
> Courtoisement,
>
> Jean-Guilhem
>
> --
> "Corruption is the abuse of entrusted power for private gain." Transparency
> International
> https://www.transparency.org/whatwedo/publication/preventing_corruption_in_humanitarian_operations
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>



-- 

Blake Girardot
OSM Wiki - https://wiki.openstreetmap.org/wiki/User:Bgirardot
HOTOSM Member - https://hotosm.org/users/blake_girardot
skype: jblakegirardot
Live OSM Mapper-Support channel - https://hotosm-slack.herokuapp.com/
Next best OSM support - https://help.openstreetmap.org/
BE A PART OF HOT'S MICRO GRANTS: https://donate.hotosm.org/

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

Re: [OSM-talk-fr] Données du STIF sur Osmose

[Noémie Lehuby]

Bonjour,

Ralf, pour faire ce que tu dis, il faut remettre les arrêts dans le 
contexte du reste de l'offre de transport.
Là, tu mappes sur l'arrêt Bibliothèque Ruen Mann desservie par la ligne 
62 en direction Porte de Saint-Cloud.
Pour mettre le bon code STIF, il faut trouver, dans l'offre opendata, ce 
même arrêt desservi par cette même ligne dans cette même direction. Là, 
tu seras sûr que c'est le bon, même si sa géoloc est mauvaise.
En l'occurrence, le code que tu as choisi est le bon : 
https://ref-lignes-stif.5apps.com/stop.html?osm_stop_id=2562278276


Aujourd'hui, en important les codes STIF des lignes, on peut déjà 
retrouver la ligne 62 facilement et sans la confondre avec l'autre ligne 
62 d'île-de-France ...
Du coup, rien qu'en affichant l'information des parcours desservis par 
tes différents arrêts opendata candidats, tu peux sans ambiguité 
déterminer lequel est le bon.


C'est justement ce sur quoi je travaille actuellement. Voici à quoi ça 
ressemble pour le moment :

https://lut.im/Cqs7y6PmVc/hP5nLJMuRHotCSdC.png
https://lut.im/N4Yq13DrS8/vZNqCkpcYt3zo3J2.png

Bonnes fêtes

Noémie


Date: Fri, 23 Dec 2016 09:26:14 +0100
From: Ralf Treinen 
To: Discussions sur OSM en français  
Subject: Re: [OSM-talk-fr] Données du STIF sur Osmose
Message-ID: <20161223082614.5z2fbl7zsfuub...@seneca.home.org>
Content-Type: text/plain; charset=iso-8859-1

Bonjour,

On Thu, Dec 22, 2016 at 09:25:58PM +0100, Noémie Lehuby wrote:


Et malgré ça, j'avais quand même un peu plus d'un cas sur 6 où l'arrêt
opendata le plus proche n'était pas le bon mais celui de l'autre côté 
de la

route.


je rencontre les mêmes difficultés, et aussi une confusion entre les
arrêts différents de lignes de bus différentes, et portant le même
nom. On peut demeler les derniers facilement grace au fichier
liste-arrets-lignes-tc-idf.csv, mais je me demande comment trouver une
information fiable sur le sens de la ligne qui dessert un arrêt de bus
(le problème évoqué par Noémie). Par exemple, pour l'arrêt 
"Bibliothèque

Rue Mann" de la ligne RATP 62, je trouve

$ grep RATP liste-arrets-lignes-tc-idf.csv | grep ';62;' | grep
'BIBLIOTHEQUE RUE MANN'
RATP;100100062:62;62;62;3;StopPoint:59:3887745;BIBLIOTHEQUE RUE
MANN;48.829293;2.378153;24009;C01098;48.829293, 2.378153
RATP;100100062:62;62;62;3;StopPoint:59:3887746;BIBLIOTHEQUE RUE
MANN;48.828817;2.378112;24013;C01098;48.828817, 2.378112

et la seule différence exploitable que je vois entre les deux est que
le premier est un plus au nord, et doit donc être celui du sens
est->ouest de la ligne. Est-ce qu'il y un autre moyen ?

-Ralf.


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

Re: [OSM-talk-fr] Rendu FR, bientôt en version 2017 !

[Christian Quest]

Les derniers changements:
- les entrance=* ne sont rendus si ce sont des entrées de bâtiment ou si ce
ne sont pas des entrées de pièce... avec de la bidouille dans la requête
pour retrouver cette info !

- les lignes des terrains de sport: plus de rendu si il ne s'agit pas d'un
leisure=pitch, et rendu possible de plusieurs sports (mais un peu fouilli
au final... à voir)

- les shop=* en souterrain sont estompés, prise en compte du tag
location=underground en plus de level<0

Et grosse refonte de fond du projet avec passage du format json au yaml
plus lisible (et maintenable)... qui ne devrait pas avoir d'incidence sur
le rendu sauf bug de conversion !

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

Re: [OSM-talk-fr] Rendu FR, bientôt en version 2017 !

[Tony EMERY]

N'oublies pas le rendu des terrains de motoball...

Le 23 déc. 2016 16:24, "Christian Quest"  a écrit :

> Les derniers changements:
> - les entrance=* ne sont rendus si ce sont des entrées de bâtiment ou si
> ce ne sont pas des entrées de pièce... avec de la bidouille dans la requête
> pour retrouver cette info !
>
> - les lignes des terrains de sport: plus de rendu si il ne s'agit pas d'un
> leisure=pitch, et rendu possible de plusieurs sports (mais un peu fouilli
> au final... à voir)
>
> - les shop=* en souterrain sont estompés, prise en compte du tag
> location=underground en plus de level<0
>
> Et grosse refonte de fond du projet avec passage du format json au yaml
> plus lisible (et maintenable)... qui ne devrait pas avoir d'incidence sur
> le rendu sauf bug de conversion !
>
> --
> 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

[OSM-talk-fr] opendata siren

[Julien Lepiller]

Bonjour,

aujourd'hui on m'a envoyé ce lien :
http://www.sirene.fr/sirene/public/static/contenu-fichiers, en rapport
avec celui-ci :
https://www.etalab.gouv.fr/louverture-du-repertoire-sirene-par-linsee-au-1er-janvier-2017-une-avancee-majeure-pour-lopen-data.

La base sirene sera disponible en opendata à partir de janvier
prochain. Elle contient les informations que possède l'INSEE sur les
entreprises françaises et les services publics. On pourrait imaginer
s'en servir pour améliorer les données concernant ces établissements. On
trouve dans ces données le nom et l'adresse de l'établissement (on peut
espérer que leurs adresses ne soient pas toutes des CEDEX), ce qui
pourrait par exemple être intégré à osmose pour proposer des
entreprises manquantes.

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

Re: [OSM-talk-fr] Rendu FR, bientôt en version 2017 !

[Stéphane Péneau]

Je vois que le nom des communes fusionnées est visible, même s'il n'y a 
pas de node place dans la relation. Super !
Par contre, on ne voit ce nom qu'à partir du zoom 14, bien après les  
"place" de la commune en question.

Est-ce qu'il ne serait pas mieux que ça soit visible avant ?

exemple : (il faut zoomer d'un cran pour voir "Montréverd")
http://umap.openstreetmap.fr/fr/map/preview-rendu-fr-2017_99740#13/46.8993/-1.4205

Stf


Le 23/12/2016 à 16:46, Tony EMERY a écrit :

N'oublies pas le rendu des terrains de motoball...

Le 23 déc. 2016 16:24, "Christian Quest" > a écrit :


Les derniers changements:
- les entrance=* ne sont rendus si ce sont des entrées de bâtiment
ou si ce ne sont pas des entrées de pièce... avec de la bidouille
dans la requête pour retrouver cette info !

- les lignes des terrains de sport: plus de rendu si il ne s'agit
pas d'un leisure=pitch, et rendu possible de plusieurs sports
(mais un peu fouilli au final... à voir)

- les shop=* en souterrain sont estompés, prise en compte du tag
location=underground en plus de level<0

Et grosse refonte de fond du projet avec passage du format json au
yaml plus lisible (et maintenable)... qui ne devrait pas avoir
d'incidence sur le rendu sauf bug de conversion !

-- 
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

Re: [OSM-talk-fr] Rendu FR, bientôt en version 2017 !

[Stéphane Péneau]

Petit détail supplémentaire, les communes fusionnées qui ont un node 
place virtuel, sont elles, visibles beaucoup plus tôt, comme la bien 
connue Chaume en Retz :

http://umap.openstreetmap.fr/fr/map/preview-rendu-fr-2017_99740#11/47.0898/-1.8406
Mais je ne dirais rien sur les tags portés par le node...

Exemple plus simple, Montholon, est visible depuis le niveau de zoom 11 :
http://umap.openstreetmap.fr/fr/map/preview-rendu-fr-2017_99740#11/47.8883/3.3889

Mais peut-être que c'est lié au nombre d'éléments à afficher.

Stf

Le 23/12/2016 à 17:15, Stéphane Péneau a écrit :
Je vois que le nom des communes fusionnées est visible, même s'il n'y 
a pas de node place dans la relation. Super !
Par contre, on ne voit ce nom qu'à partir du zoom 14, bien après les  
"place" de la commune en question.

Est-ce qu'il ne serait pas mieux que ça soit visible avant ?

exemple : (il faut zoomer d'un cran pour voir "Montréverd")
http://umap.openstreetmap.fr/fr/map/preview-rendu-fr-2017_99740#13/46.8993/-1.4205

Stf


Le 23/12/2016 à 16:46, Tony EMERY a écrit :

N'oublies pas le rendu des terrains de motoball...

Le 23 déc. 2016 16:24, "Christian Quest" > a écrit :


Les derniers changements:
- les entrance=* ne sont rendus si ce sont des entrées de
bâtiment ou si ce ne sont pas des entrées de pièce... avec de la
bidouille dans la requête pour retrouver cette info !

- les lignes des terrains de sport: plus de rendu si il ne s'agit
pas d'un leisure=pitch, et rendu possible de plusieurs sports
(mais un peu fouilli au final... à voir)

- les shop=* en souterrain sont estompés, prise en compte du tag
location=underground en plus de level<0

Et grosse refonte de fond du projet avec passage du format json
au yaml plus lisible (et maintenable)... qui ne devrait pas avoir
d'incidence sur le rendu sauf bug de conversion !

-- 
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



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

Re: [OSM-talk-fr] Rendu FR, bientôt en version 2017 !

[Philippe Verdy]

Au même endroit si on dézoome, on tombe sur l'Hebergement, dont le
placement semble vraiment trop à l'ouest sans que ce soit justifié.

Pourquoi par défaut les libellés ne sont pas centrés sur la commune mais
affiché à l'ouest (alignement à gauche) ou à l'est alors même qu'il n'y a
aps de collision en le plaçant au centre ? Cela donne un emplacement
contre-intuitif. A moins qu'il y ait des collisions à éviter, le centrage
devrait être l'option par défaut, avec un décalage possible vers l'ouest ou
l'est (ou un peu vers le nord ou le sud) tout en gardant le rectangle
occupé par le libellé si-possible à une position contenant le point central.

Si le libellé est accompagne d'une icone en revanche (un cercle, un disque,
une étoile...) ce libellé devrait être aussi placé de préférence au nord ou
au sud de cette icone (pour éviter autant que possible de la couvrir, mais
ce n'est pas une obligation: si le placement à l'ouest ou à l'est de
l'icone provoque et décentrage trop distant, il est possible malgré tout de
recentrer le libellé même si cela recouvre l'icone, s'il faut faire de la
place pour un libellé voisin.

Un bon moyen serait de procéder en deux passes: dans une première passe les
libellés sont calculés avec une taille correspondant à leur version non
abrégée générant le rectangle le plus grand on enregistre ensuite son point
central préférentiel (qui pourra être ensuite décalé pour le maintenir dans
son rectangle de définition. Si un libellé ultérieur a besoin de place, il
peut décaler le centre des libellés voisins pour qu'il reste dans leur
rectangle de définition, puis ce rectangle de définition est réduit pour
qu'il n'aille plus recouvrir la place prise par un autre libellé voisin
(noter que les icônes sont placées en premier pour occuper leur place)
chaque libellé a donc un rectangle préférentiel de placement qui de proche
en proche va se réduire. Si on manque encore de place, un libellé peut
ensuite être converti en version abrégée, en utilisant les "short-name" si
disponibles, puis les abréviations courantes de termes connus comme
"Saint(e)", "Général", "Avenue", "Boulevard" si cela permet de réduire leur
taille (tout en faisant que ce libellé ne sorte pas de leur actuel
rectangle de définition, doinc en faisant attention à conserver des sauts
de lignes suffisants).

Le tracé des libellés ne se fait que dans une seconde passe après les avoir
tous placés (là où il n'y a pas de collisions possibles dans la tuile
courante ou dans une tuile limitrophe où ce libellé serait partiellement
tracé: la zone, de calcul de placement des libellés est donc plus large que
la tuile que l'on est en train de tracer, mais ce n'est pas nouveau et ne
concerne pas que les libellés mais aussi le tracé des routes du fait de
leur largeur, ou des icônes de tout type qui peuvent être elles aussi à
cheval sur des limites de tuiles: les requêtes à la base doivent inclure
une marge plus grande autour de la tuile à tracer pour être certain d'avoir
tous les objets, y compris ceux qui pourraient être décalés de leur
position centrale idéale, ce décalage étant plus grand pour les libellés
que pour les icônes ou routes qui ont un placement fixe).

Autre chose à voir: les libellés non horizontaux qui suivent les noms de
fleuves ou les frontières (voire les noms de chaines de montagne si on veut
les voir ou les noms de petites mers): leur placement dynamique (le long
d'un chemin) est nettement plus compliqué car il se fait dans un polygone
calculé par un buffer autour du chemin dont on doit trouver des zones non
occupées par d'autres libellés... pour les noms de chaines de montagnes (ou
glaciers, parcs naturels...) toutefois une solution est de les afficher en
grand caractères mais semi-transparents et gras, qui peuvent alors entrer
en superposition avec les autres zones de remplissage ou les libellés et
icônes tracés par dessus; le système pourrait servir aussi à libeller les
grandes régions ou les pays en fonction de leur superficie relativement à
celle de la tuile à l'échelle de rendu donnée). Ce système de libellés
semi-transparents (en arrière-plan des autres libellés pourrait autant
servir à placer des noms de quartiers sur des échelles montrant les rues
d'une ville. Mais la question de lisibilité de ces libellés
semi-transparents dépend des choix de couleurs et tailles et graisse de
police utilisées: si la police est trop grande de tels libellés ne doivent
plus être utilisés et au passe aux libellés tracés en petits caractères le
long des frontières ou le long du chemin central d'un cours d'eau.

Le placement des libellés est encore non optimal et devrait faire l'objet
de recherches avec de meilleurs heuristiques (sans compter que pour des
libellés jugés "importants", s'il n'est pas possible de les afficher à
cause de collisions, il reste la solution des libellés "fléchés" pour leur
trouver une autre place sortant de leur cadre de définition initia, exemple
pour placer Monaco à côté de Nice, Nice étant beaucoup plus gros, mai

Re: [OSM-talk-fr] opendata siren

[Philippe Verdy]

Déjà évoqué ici depuis des semaines... Mais la qualité des adresses pose
problème, de même que leur pertinence:
- SIRENE possède des tas d'entrées pour des entreprises qui n'existent plus
ou qui n'existent que sur le papier.
- avec une adresse légale qui n'est pas celle de leur fond de commerce,
mais une adresse de contact (ou d'un gérant ou celle d'un cabinet de
gestion), ou localisées uniquement à leur société mère complètement
ailleurs. Uen société peut être enregistrée légalement n'importe où dans
l'UE, avec uniquement une unique adresse fiscale en France, même si ses
établissements sont répartis sur tout le territoire.

Si on parle du SIREN (entité légale) ce ne sera pas pertinent
géographiquement. Si on parle du SIRET (les établissements) là c'est plus
pertinent géographiquement, mais un même établissement peut aussi avoir des
locaux différents et regrouper tout à une seule adresse alros qu'il y aura
deux commerces distincts (cas courant: deux boutiques de la même enseigne
dans la même ville, avec le même gérant, dont parfois des boutiques
fantômes qui n'existent que pour leur devanture mais sans aucune activité.
On en trouve des tonnes dans les sociétés de service, ou chez les
"dépanneurs" à domicile qui font croire à leur présence dans un quartier
avec juste des pas de porte complètement vides et quelqu'un qui ne fait que
passer de temps en temps relever le courrier, les locaux étant complètement
vides, parfois même sans aucun téléphone). Essayez le localiser des
"garages" par exemple, ou vous trouverez des tas d'adresses fantômes. Idem
pour des tas de SARL et filiales ad hoc dans les SSII (dont les employés
peuvent avoir des contrats mentionnant des noms de société différents de
ceux pour laquelle ils travaillent ensembles avec leurs collègues tous les
jours): ces sociétés existent pour des raisons d'optimisation fiscale ou
pour répondre à des besoins liés à des contrats avec d'autres sociétés, ou
parce que certains contrats exigent des certifications de compétence pour
certains employés, ou parce qu'il y a des engagements budgétaires et
juridiques qui ne doivent pas engager la société mère toute entière, ou
pour des raisons d'optimisation de contrats d'assurance, ou encore pour des
raisons de statuts sociaux différents (employés dont les contrats obéissent
à d'autres conventions collectives, des contrats qu'il n'est pas simple de
modifier sans surcoût)

Bref le SIRENE est un fourre-tout qui sera très difficile à rendre
pertinent géographiquement, sans vérification sur le terrain pour voir s'il
y a une existence réelle. De plus les noms des entreprises sont les noms
légaux et presque jamais les enseignes (allez faire un achat dans un
boutique quelconque le nom légal que vous voyez sur la facture ou la
facturette du ticket de paiement carte bancaire est souvent très différent,
et parfois même quand il y a une adresse indiquée ce n'est pas celle du
lieu de vente!) Faites un achat sur Internet même sur le site désigné comme
"France", et vous serez facturé selon le mode de paiement utilisé par une
société ou une autre, pas forcément en France (et parfois avec une autre
TVA que la TVA française).

Bref cette base SIRENE demandera beaucoup de tri (et je pense même que si
cette base s'est finalement "ouverte", c'est parce que même l'Etat (ou les
tribunaux de commerce) n'y comprend plus rien lui-même et qu'il cherche des
moyens de la corréler avec d'autres choses, en permettant à des applis
tierces de développer des moyens de recherche et croisement d'informations.


Le 23 décembre 2016 à 17:10, Julien Lepiller  a écrit :

> Bonjour,
>
> aujourd'hui on m'a envoyé ce lien :
> http://www.sirene.fr/sirene/public/static/contenu-fichiers, en rapport
> avec celui-ci :
> https://www.etalab.gouv.fr/louverture-du-repertoire-
> sirene-par-linsee-au-1er-janvier-2017-une-avancee-majeure-pour-lopen-data.
>
> La base sirene sera disponible en opendata à partir de janvier
> prochain. Elle contient les informations que possède l'INSEE sur les
> entreprises françaises et les services publics. On pourrait imaginer
> s'en servir pour améliorer les données concernant ces établissements. On
> trouve dans ces données le nom et l'adresse de l'établissement (on peut
> espérer que leurs adresses ne soient pas toutes des CEDEX), ce qui
> pourrait par exemple être intégré à osmose pour proposer des
> entreprises manquantes.
>
> ___
> 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] Données du STIF sur Osmose

[Ralf Treinen]

Christian, Noémie, merci pour vos réponses. Je me suis peut-être un peu
mal exprimé. Dans mon cas, j'avais bien identifié les deux arrêts sur le
terrain, mon problème était seulement de savoir quel arrêt sur le terrain
correspond à quel numéro STIF, vu que la géolocalisation dans le fichier
opendata est parfois pas très fiable.

-Ralf.


On Fri, Dec 23, 2016 at 10:52:35AM +0100, Christian Quest wrote:
> Le terrain... y'a que ça qui tranchera au final de toute façon car entre les
> arrêts présents dans OSM parfois provenant de vues aériennes plus à jour (les
> arrêts de bus sont faciles à déplacer) et les données opendata pas bien
> précises, on ajoute facilement une info inexacte.
> 
> Ce jeu de donnée est utile pour détecter des arrêts manquants, mais rentrer
> plus dans le détail sans vérifier sur place me semble malheureusement un peu
> trop optimiste.
> 
> A mon avis il faut revoir cette proposition d'intégration dans osmose ou alors
> la laisser en "dev" pour tester le temps d'affiner ça.
> 
> 
> 
> Le 23 décembre 2016 à 09:26, Ralf Treinen  a écrit :
> 
> Bonjour,
>
> On Thu, Dec 22, 2016 at 09:25:58PM +0100, Noémie Lehuby wrote:
> 
> > Et malgré ça, j'avais quand même un peu plus d'un cas sur 6 où l'arrêt
> > opendata le plus proche n'était pas le bon mais celui de l'autre côté de
> la
> > route.
> 
> je rencontre les mêmes difficultés, et aussi une confusion entre les
> arrêts différents de lignes de bus différentes, et portant le même
> nom. On peut demeler les derniers facilement grace au fichier
> liste-arrets-lignes-tc-idf.csv, mais je me demande comment trouver une
> information fiable sur le sens de la ligne qui dessert un arrêt de bus
> (le problème évoqué par Noémie). Par exemple, pour l'arrêt "Bibliothèque
> Rue Mann" de la ligne RATP 62, je trouve
> 
> $ grep RATP liste-arrets-lignes-tc-idf.csv | grep ';62;' | grep
> 'BIBLIOTHEQUE RUE MANN'
> RATP;100100062:62;62;62;3;StopPoint:59:3887745;BIBLIOTHEQUE RUE
> MANN;48.829293;2.378153;24009;C01098;48.829293, 2.378153
> RATP;100100062:62;62;62;3;StopPoint:59:3887746;BIBLIOTHEQUE RUE
> MANN;48.828817;2.378112;24013;C01098;48.828817, 2.378112
> 
> et la seule différence exploitable que je vois entre les deux est que
> le premier est un plus au nord, et doit donc être celui du sens
> est->ouest de la ligne. Est-ce qu'il y un autre moyen ?
>
> -Ralf.
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
> 
> 
> 
> 
> --
> Christian Quest - OpenStreetMap France

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


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

Re: [OSM-talk-fr] Rendu FR, bientôt en version 2017 !

[Christian Quest]

Pour les track/gradeX, j'ai repris les mêmes pointillés que sur le rendu
international... dans la prochaine livraison...

Le 22 décembre 2016 à 15:40, JB  a écrit :

> Salut Christian,
> Sacré boulot que tu fais là !
> Par contre, en zone rurale (mon dada), le rendu international a bien
> avancé, mais pas repris sur le rendu FR. Notamment l'avancée principale :
> la réorganisation des tirets selon le tracktype serait très bienvenue, la
> progression actuelle étant incohérente pour le tracktype=grade4. (Sinon, le
> boulot fait sur les path/footway est intéressant aussi)
> Voilà voilà, n'hésite pas à différencier encore un peu plus les locality
> des autres lieu-dits (j'aurais mis un coup de font-stretch ou son
> équivalent s'il existe sur mapnik sur les locality, par exemple).
> JB.
>
> Le 21/12/2016 à 19:45, Christian Quest a écrit :
>
> Je profite des congés pour avancer sur le rendu FR...
>
> La liste des commit s'allonge et donne une idée des changements:
> https://github.com/cquest/osmfr-cartocss/commits/master
>
> Après avoir passé pas mal de temps sur les optimisations pour accélrer le
> rendu là où c'était le plus urgent, je suis de retour sur le côté graphique.
>
> Une grosse nouveauté: l'estompage des objets "indoor" qui devrait alléger
> les abords de certaines gares ;) Pour ça, le rendu considère tout objet
> avec un level=* négatif comme indoor.
>
> Les "shield" sur les routes sont mieux répartis. Pour cela, la requête SQL
> regroupe les différents tronçons ayant le même highway+ref car vu qu'on
> tronçonne de plus en plus il faut en passer par là !
>
> Résultat visible sur http://umap.openstreetmap.fr/fr/map/test-rendu-osmfr_
> 99740#6/47.376/2.186
>
> Le pré-calcul des tuiles est en cours donc tout n'est pas encore dispo et
> peut nécessiter un délais de génération...
>
>
> --
> Christian Quest - OpenStreetMap France
>
>
> ___
> 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] Rendu FR, bientôt en version 2017 !

[Gautier Pelloux-Prayer]

Serait-il possible d'ajouter le rendu des pistes de course : course 
équestre (leisure=horse_racing) ou piste d'athlétisme et de course à 
pied (sport=athletics et sport=running), etc. ?
Actuellement elles ne sont pas representées (par ex ici : 
http://umap.openstreetmap.fr/fr/map/preview-rendu-fr-2017_99740#19/45.17942/5.75833 
).



Le ven. 23 déc. 2016 à 20:23, Christian Quest 
 a écrit :
Pour les track/gradeX, j'ai repris les mêmes pointillés que sur le 
rendu international... dans la prochaine livraison...


Le 22 décembre 2016 à 15:40, JB  a écrit :

Salut Christian,
Sacré boulot que tu fais là !
Par contre, en zone rurale (mon dada), le rendu international a bien 
avancé, mais pas repris sur le rendu FR. Notamment l'avancée 
principale : la réorganisation des tirets selon le tracktype serait 
très bienvenue, la progression actuelle étant incohérente pour le 
tracktype=grade4. (Sinon, le boulot fait sur les path/footway est 
intéressant aussi)
Voilà voilà, n'hésite pas à différencier encore un peu plus les 
locality des autres lieu-dits (j'aurais mis un coup de font-stretch 
ou son équivalent s'il existe sur mapnik sur les locality, par 
exemple).

JB.

Le 21/12/2016 à 19:45, Christian Quest a écrit :

Je profite des congés pour avancer sur le rendu FR...

La liste des commit s'allonge et donne une idée des changements: 
https://github.com/cquest/osmfr-cartocss/commits/master


Après avoir passé pas mal de temps sur les optimisations pour 
accélrer le rendu là où c'était le plus urgent, je suis de 
retour sur le côté graphique.


Une grosse nouveauté: l'estompage des objets "indoor" qui devrait 
alléger les abords de certaines gares ;) Pour ça, le rendu 
considère tout objet avec un level=* négatif comme indoor.


Les "shield" sur les routes sont mieux répartis. Pour cela, la 
requête SQL regroupe les différents tronçons ayant le même 
highway+ref car vu qu'on tronçonne de plus en plus il faut en 
passer par là !


Résultat visible sur 
http://umap.openstreetmap.fr/fr/map/test-rendu-osmfr_99740#6/47.376/2.186


Le pré-calcul des tuiles est en cours donc tout n'est pas encore 
dispo et peut nécessiter un délais de génération...



--
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

hebdoOSM Nº 335 13/12/2016-19/12/2016

[weeklyteam]

Bonjour,

Le résumé hebdomadaire n° 335 de l'actualité OpenStreetMap vient de paraître en 
français. Un condensé à retrouver à:

http://www.weeklyosm.eu/fr/archives/8494/

Bonne lecture!

hebdoOSM?
Qui?: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
Où?: 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] opendata siren

[Christian Quest]

Tu as un exemple d'intégration sur les pharmacies, que j'ai rapidement fait
pendant le hackathon "opensirene":
http://osmose.openstreetmap.fr/fr/map/#item=7170&class=99

La première étape consiste à géocoder le mieux possible cette base... ce
qui m'a pris quelques jours pour préparer ce hackathon. C'est pas parfait,
mais franchement exploitable.

Ensuite il faudra faire attention à la temporalité... la diffusion de
SIRENE sera quotidienne (difficile de faire mieux !).
Une entreprise inscrite sera donc visible en principe le lendemain dans la
base, mais son activité sur le terrain pourra ne démarrer que plus tard.
On a le problème inverse des établissements dont l'activité a cessé, mais
qui n'ont pas encore été retirés de SIRENE... et là ça peut prendre un
certain temps.
Dernier point, les adresses correspondent en principe au lieu d'activité,
mais ce n'est pas toujours contrôlé ou mis à jour... donc on peut avoir une
localisation qui ne correspond par à un vrai "POI" au sens OSM.

Il faut aussi bien faire le tri car il n'y a pas que des entreprises, on
trouve aussi des associations et des activités de type profession libérale,
auto-entrepreneur.

Malgré ces limites, c'est une source formidable à utiliser avec un peu de
recul car tout intégrer dans OSM n'est pas forcément bien utile... surtout
que les données seront accessibles à tout le monde.

Je compte remettre en route mon "etat commune" pour indiquer l'écart entre
OSM et entre autre SIRENE pour suggérer des pistes d'améliorations dans OSM
mais vu à la maille d'une commune.


Le 23 décembre 2016 à 17:10, Julien Lepiller  a écrit :

> Bonjour,
>
> aujourd'hui on m'a envoyé ce lien :
> http://www.sirene.fr/sirene/public/static/contenu-fichiers, en rapport
> avec celui-ci :
> https://www.etalab.gouv.fr/louverture-du-repertoire-
> sirene-par-linsee-au-1er-janvier-2017-une-avancee-majeure-pour-lopen-data.
>
> La base sirene sera disponible en opendata à partir de janvier
> prochain. Elle contient les informations que possède l'INSEE sur les
> entreprises françaises et les services publics. On pourrait imaginer
> s'en servir pour améliorer les données concernant ces établissements. On
> trouve dans ces données le nom et l'adresse de l'établissement (on peut
> espérer que leurs adresses ne soient pas toutes des CEDEX), ce qui
> pourrait par exemple être intégré à osmose pour proposer des
> entreprises manquantes.
>
> ___
> 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