Re: [OSM-talk-fr] OSM - Michelin

[thevenon . julien]

> De: "Nicolas Dumoulin" 

> Excellent !
> Je n'ai pas encore tout lu, mais un grand merci pour tous les détails (dont 
> l'aventure avec le chien ;-) )

Vraiment tres interessant !
Merci pour les explications

Julien

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

Re: [OSM-talk-fr] OSM - Michelin

[Romain MEHUT]

Le 7 juin 2013 09:31,  a écrit :

> > De: "Nicolas Dumoulin" 
>
> > Excellent !
> > Je n'ai pas encore tout lu, mais un grand merci pour tous les détails
> (dont
> > l'aventure avec le chien ;-) )
>
> Vraiment tres interessant !
> Merci pour les explications
>

Oui à diffuser largement!
Merci.

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

Re: [OSM-talk-fr] rendu osm-fr et réserves naturelles

[Yves Pratter]

Le 6 juin 2013 à 10:49, Christian Quest  a écrit :Passer de NR à RN me semble le plus simple et efficace en attendantéventuellement mieux…Je trouve que ça rend vraiment la carte illisible…Trop d'info tue l'info ?Je pense qu'il ne faut rien mettre (ou alors une teinte un peu différente).D'autant plus qu'il est assez facile de faire apparaitre des infos au-dessus du fond de carte, tels que le contour de la réserve.L'IGN ne modifie pas sa texture. Seul un libellé "Réserve naturelle" est affichée par dessus la zone. --Yves___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Présentation de TileMill au FROG2013... vos avis

[Christian Quest]

Je termine des slides pour une présentation de TileMill au FROG2013..

suggestions bienvenues ;)

https://docs.google.com/presentation/d/14JqpUsXytpR12L9vSvuZc8jvLYzDKYmYXOdVwvZ1mK8/edit?usp=sharing

-- 
Christian Quest - OpenStreetMap France
Un nouveau serveur pour OSM... http://donate.osm.org/server2013/

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

Re: [OSM-talk-fr] rendu osm-fr et réserves naturelles

[Christian Quest]

Des RN, mais moins denses... ça doit aller mieux non ?


Le 7 juin 2013 10:38, Yves Pratter  a écrit :

>
> Le 6 juin 2013 à 10:49, Christian Quest  a écrit
> :
>
> Passer de NR à RN me semble le plus simple et efficace en attendant
> éventuellement mieux…
>
> Je trouve que ça rend vraiment la carte illisible…
> Trop d'info tue l'info ?
>
> 
>
> Je pense qu'il ne faut rien mettre (ou alors une teinte un peu différente).
> D'autant plus qu'il est assez facile de faire apparaitre des infos
> au-dessus du fond de carte, tels que le contour de la réserve.
>
>
> L'IGN ne modifie pas sa texture. Seul un libellé "Réserve naturelle" est
> affichée par dessus la zone.
>  
> 
>
> --
> Yves
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>
>


-- 
Christian Quest - OpenStreetMap France
Un nouveau serveur pour OSM... http://donate.osm.org/server2013/
<><>___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] rendu osm-fr et réserves naturelles

[Yohan Boniface]

Et un "Réserve naturelle" le long de son contour, comme tu as fait pour 
les limites administratives?



On 06/07/2013 10:42 AM, Christian Quest wrote:

Des RN, mais moins denses... ça doit aller mieux non ?


Le 7 juin 2013 10:38, Yves Pratter mailto:yves.prat...@laposte.net>> a écrit :


Le 6 juin 2013 à 10:49, Christian Quest mailto:cqu...@openstreetmap.fr>> a écrit :


Passer de NR à RN me semble le plus simple et efficace en attendant
éventuellement mieux…

Je trouve que ça rend vraiment la carte illisible…
Trop d'info tue l'info ?



Je pense qu'il ne faut rien mettre (ou alors une teinte un peu
différente).
D'autant plus qu'il est assez facile de faire apparaitre des infos
au-dessus du fond de carte, tels que le contour de la réserve.


L'IGN ne modifie pas sa texture. Seul un libellé "Réserve naturelle"
est affichée par dessus la zone.



--
Yves

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




--
Christian Quest - OpenStreetMap France
Un nouveau serveur pour OSM... http://donate.osm.org/server2013/


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




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

[OSM-talk-fr] OSM - Michelin

[bobo]

Vraiment intéressant à lire ce retour d'expérience.
Ça apporte pas mal de billes pour comprendre comment peut fonctionner un
projet de ce type.
En partageant les difficultés rencontrées, on est pas dans l'idée de
faire l'apologie osm et je trouve ça honnête
et cela fait bien avancer le débat. /pi, une touche de storytelling, ça
fait toujours du bien /

Aussi, je me suis dis que lors de la production de documents de ce type,
renseigner le nombre de personnes ayant contribué à osm sur la zone au
jour de l'extraction peut être intéressant. Ca met en relief l'aspect
participative, je ne sais pas si vous en avez parlé.

Voilà

Bonne journée
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Présentation de TileMill au FROG2013... vos avis

[Francescu GAROBY]

Salut,
Belle présentation !
J'ai cependant relevé quelques coquilles (en gras, la correction à
apporter) :

* slide 2 : Un éditeur interactif de feuille*s* de style
* slide 3 : *É*diteur CartoCSS
* slide 4 : Lisibilité et maintenance améliorée*s*
* slide 7 : TileMill *s*'appuie sur Mapnik :
* slide 15 : l'adapter aux usages et à la culture hexagona*ux* (la culture
et les usages sont hexagonaux, non ?)
* partout : une espace insécable avant deux-points

Francescu


Le 7 juin 2013 10:40, Christian Quest  a écrit :

> Je termine des slides pour une présentation de TileMill au FROG2013..
>
> suggestions bienvenues ;)
>
>
> https://docs.google.com/presentation/d/14JqpUsXytpR12L9vSvuZc8jvLYzDKYmYXOdVwvZ1mK8/edit?usp=sharing
>
> --
> Christian Quest - OpenStreetMap France
> Un nouveau serveur pour OSM... http://donate.osm.org/server2013/
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>



-- 
Cordialement,
Francescu GAROBY
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] rendu osm-fr et réserves naturelles

[Yves Pratter]

> Des RN, mais moins denses... ça doit aller mieux non ?
Ok, mais alors nettement moins dense, avec une teinte plus transparente, et 
disposé si possible en quinconce pour donner un aspect moins "mécanique".
Faire un essai avec un angle un peu différent au texte de la texture ??

Il n'y a pas des graphistes / designers sur cette liste ?

De plus il faudrait les écrire en bleu pour les zones d'eau.
Ok pour le vert pour les zones Verdy ;-)


--
Yves___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Présentation de TileMill au FROG2013... vos avis

[Bruno Cortial]

Le 7 juin 2013 10:40, Christian Quest  a écrit :

> Je termine des slides pour une présentation de TileMill au FROG2013..
>
> suggestions bienvenues ;)
>

Bonjour
Sympa !
Peut-être ajouter des précisions sur les possibilités des Mbtiles et
UTFGrid, parce que Tilemill ne fait pas que du rendu.
http://www.mapbox.com/demo/visiblemap/

Et dans des trucs "avancés, les opérations de filtrage et de composition de
couche, mais c'est finalement bien montré dans les exemples.

Et enfin évoquer le futur, à savoir tilemill/mapnik sans base de données
locale, avec des serveurs de tuiles vecteurs thématiques distribuant les
données. Nul doute que cela va ouvrir encore plus l'usage de l'outil à tous
les allergiques à osm2pgsql.
https://github.com/mapbox/mapnik-vector-tile
http://openstreetmap.us/~migurski/vector-datasource



A+
Bruno
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Présentation de TileMill au FROG2013... vos avis

[Yves Pratter]

Je découvre la Visite guidée du rendu OSM :-)
http://u.osmfr.org/fr/m/4/

Un petit hic, les liens pointent toujours sur la Gare de Lyon — un problème de 
copier/coller ;-) ?.
Heureusement en faisant un zoom arrière, j'arrive à comprendre la logique.

Merci.

PS: est-ce prévu à terme de mettre les logos des opérateurs des autres pays ?
(au moins pour les pays francophones : CFF en suisse…)

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

[OSM-talk-fr] 29 juin Carto-Party au Parc Borely (Marseille )

[Jean-Marie Dubosc]

* Dans le cadre de la semaine européenne de l’open
data,
nous(les contributeurs OSM de la région marseillaise) vous proposons de
participer à une carto-partie OSM au parc Borely afin de vous initier à OSM
(relever des données et les saisir pour les partager).
la journée se déroulera en deux parties : relevé sur le terrain au Parc
Borely à partir de 10h, ponctuée d’un pique-nique dans le parc à 13h, puis
à partir de 15h, saisie des données à La Boate près du Vieux Port.*

Le jour : le samedi 29 juin à 10h
Sur inscription (gratuite) limité à 25 participants
Le lieu : Parc Borely
l’objectif pour les participants: apprendre à faire un relevé
d’informations géographiques sur le terrain puis les ajouter dans OSM (Open
Street Map) afin de les partager.
Nous contribuerons ainsi à mieux cartographier les chemins et les routes du
parc et notamment la partie Serre et Jardin Botanique. Nous pourrons aussi
noter quelques arbres remarquables et quelques point d’intérêts .
Matériel : nous vous fournirons le matériel nécessaire (walking papers et
crayons).
Pique-nique prévue sur place à partir de 13h (amenez votre pique-nique)
Le rendez-vous est fixé à 10h le 29 juin à l’entrée principale du parc
Borely
10h00 – 17h30

*Saisie des données et restitution*

A La Boate à partir de 15h
Au frais, à l’abri du soleil,  vous serez  initiés à la saisie
d’informations dans OSM  et pourrez visualiser vos apports sur la carte
publique d’OSM.

Le nombre de participants est limité à 25 personnes. C’est gratuit,
inscrivez vous !
*Inscription* 

plan accès au parc Borely 

plan d’accès à La Boate 
 Twitter hashtag: #odwm 
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Proposition de projet du mois (gares SNCF)

[Christophe Merlet]

Bonjour,


Pour un prochain projet du mois je propose d'intégrer toutes les gares 
et haltes ferroviaires de la SNCF voire un peu plus.


Je me suis aperçu que dans ma région ces données étaient incomplètes 
alors que toutes les infos sont disponibles dans wikipedia et sur le 
site de la SNCF. De plus les gares existantes dans OSM sont 
incomplètement tagués.



Quelques rappels :
Une gare (railway=station) est un arrêt ferroviaire ayant un bâtiment 
avec guichet et horaires d'ouverture.
Une halte (railway=halt) est un arrêt ferroviaire simple sans 
surveillance ni personnel.


Le site http://www.ter-sncf.com/ recense toutes les gares et haltes 
ferroviaires ainsi que les arrêts routiers.

Wikipedia parait aussi être assez exhaustif sur le recensement des arrêts.

Voici différents exemples de bonnes pratiques...

Gare de Saint-Jean-de-Luz - Ciboure
http://www.openstreetmap.org/browse/node/860594526

name = Saint-Jean-de-Luz - Ciboure
name:eu = Donibane Lohizune - Ziburu
official_name = St-Jean-de-Luz-Ciboure
operator = SNCF
railway = station
uic_ref = 8767712
website = 
http://www.ter-sncf.com/Region/aquitaine/gare/St-Jean-de-Luz-Ciboure.aspx

wheelchair = yes
wikipedia = fr:Gare de Saint-Jean-de-Luz - Ciboure


Halte de Halsou-Larressore
http://www.openstreetmap.org/browse/node/2334905961

name = Halsou-Larressore
name:eu = Haltsu-Larresoro
operator = SNCF
railway = halt
website = 
http://www.ter-sncf.com/Region/aquitaine/gare/Halsou-Larressore.aspx

wikipedia = fr:Gare de Halsou - Larressore


Halte de Lescar (plus du tout exploité par la SNCF)
http://www.openstreetmap.org/browse/node/619232892

name = Lescar
railway = halt


Ces nœuds devraient être placés sur le railway le plus proche de la gare 
(il me semble). Le bâtiment de la gare pouvant simplement être tagué


building = yes ou building=train_station
name = Gare

Christian Quest a rajouté sur certains nœuds les balises official_name 
et uic_ref. Je ne sais pas où il les a trouvé...
operator=SNCF permet d'afficher le logo de la SNCF sur les gares dans le 
rendu osm.fr et permet de distinguer un arrêt en cours d'exploitation 
d'un autre où il ne reste que des infrastructures plus ou moins à l'abandon.



L'ajout des gares et haltes permettra de valider la bonne continuité du 
réseau ferroviaires dans OSM.



Vos avis ?


Librement,
--
Christophe Merlet (RedFox)

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

Re: [OSM-talk-fr] Proposition de projet du mois (gares SNCF)

[Nicolas Dumoulin]

Le vendredi 7 juin 2013 12:28:33 Christophe Merlet a écrit :
> Bonjour,
> 
> 
> Pour un prochain projet du mois je propose d'intégrer toutes les gares
> et haltes ferroviaires de la SNCF voire un peu plus.

Et on n'avait pas un outil genre integration d'opendata en ligne pour ça ?

-- 
Nicolas Dumoulin
http://wiki.openstreetmap.org/wiki/User:NicolasDumoulin

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

Re: [OSM-talk-fr] rendu osm-fr et réserves naturelles

[Philippe Verdy]

TL;DR (intéresse ceux qui travaillent sur un rendu) Plusieurs points :

=== 1. maillage pour les "RN" ===

Avec une disposition à mailles carrées orientées à 30 ou 60 degrés on a
encore des textures régulières disposables en pavés rectangulaires. c'est
souvent un angle pratique pour éviter cet aspect trop mécanique.

== 2. Polices de caractères ==

Autre reproche à faire dans le rendu fr : déjà les polices sont toutes
petites, mais en plus les libellés sont pour la plupart en italique. C'est
très peu lisible à la résolution utilisée, même avec un rendu anticrénelage
du texte, utilisant des pixels à niveau de transparence variable. Pour nos
yeux, ce serait bien de soit éviter les italiques (qui ont tendance à
condenser horizontalement les textes), soit agrandir un peu les libellés
qui sont pratiquement tous trop petits.

Ne réserver les italiques que pour les lieux-dits, ou les régions peu
géolocalisées (qui devraient s'afficher avec des lettres assez grandes mais
transparentes et plus dans des polices plus grasses), pas pour les libellés
de points. Pour les fleuves et rivières, les libellés en italique marchent
bien car on peut zoomer pour les voir en plus grand et sinon ils
disparaissent.

Mais pour les noms de communes (niveau 8), même si ils sont dans des
polices de taille variable en fonction du type (capitale/chef-lieu
administratif ou population ou classification
place=city/town/village/hamlet/locality, c'est le rendu qui adapte les
tailles), ce serait bien d'éviter les italiques totalement. Et n'utiliser
les italiques que pour le niveau 9 ou plus.

== 3. Densification des toponymes visibles et autoadaptation selon le zoom
==

Enfin il faudrait faire quelque chose pour densifier le nombre de libellés
de communes visibles dans les faibles niveaux de zoom. L'idée est de faire
une sélection de tous les libellés et classer ces noms dans une liste de
priorité à plusieurs critères :
- le premier niveau de tri de cette liste plus important est le niveau
administratif dont la commune est le chef-lieu/la capitale.
- le deuxième niveau est la classification
(city/tow/village/hamlet/locality)
- le troisième, optionnel, est la population indiquée

Ensuite le rendu affiche les libellés dans l'ordre de la liste, en les
sautant si cela génère des recouvrements ou si un critère de densité
maximal est atteint. Pour éviter des recouvrements, le rendu calcule des
bounding box pour chacun et les combine en vérifiant que le libellé suivant
ne vient pas empiéter dedans (l'algo pourra parfois chercher à les abréger
en cas de besoin pour les faire tenir s'ils y a des collisions en utilisant
le libellé non abrégé, comme il sait le faire pour des termes communs comme
"Rue" => "R.", "Boulevard" => "Bd").

Selon le niveau de zoom, ces libellés doivent aussi n'apparaître que le
long de la frontière (si la surface incluse dans la frontière est assez
grande, sinon uniquement au "centre" de la zone (qui est soit la position
du membre "label" de la relation, sinon la position de son membre
"admin_centre", si c'est un noeud, soit le centroïde calculé de son membre
"admin_centre" si c'est une surface (ce cas ne semble pas arriver encore en
France mais existe dans d'autre pays), sinon le centroïde calculé de la
surface. Selon la méthode ou l'autre (le long de la frontière ou uniquement
centré dans la zone), les tailles de polices doivent être adaptées (le cas
du rendu centré autorise le libellé à déborder largement de sa zone,
d'autant plus si le libellé est "important", c'est-à-dire mieux classé dans
la liste triée précédente, car il aura une police plus grande qu'un libellé
le long d'une frontière, qui doit malgré tout rester lisible aussi avec une
taille minimale suffisante).

Mais Mapnik permet-il d'inclure un tel algorithme (qui fonctionne pas à pas
et non de façon globale sur une liste d'objets présélectionnés et rendus en
totalité) ? En SQL on peut générer le tri (avec une requête certes
compliquée à faire pour aller chercher les infos sur les statuts de
chef-lieu/capitale car l'info est à chercher dans d'autres objets; au pire
si le premier niveau est difficile à calculer on peut en SQL le supprimer,
mais ce ne sera pas idéal), mais Mapnik peut-il sélectivement "sauter"
certains éléments de cette liste triée?

En attendant je me désespère de voir les cartes à faible niveaux de zoom
aussi vides d'informations utiles, particulièrement en France ou dans les
pays avec de larges espaces ruraux (c'est moins un problème pour
l'Allemagne, la Belgique ou le Royaume-Uni, ou même l'Espagne, qui sont
moins concernés que la France, le Canada, et bon nombre de pays africains).

L'algo (très sommaire, je ne code pas pour Mapnik) que je propose est
suffisamment adaptatif pour pouvoir avoir une densité suffisante mais pas
excessive, permettant de garder des cartes utilisables à tous les niveaux
de zoom, et pour rester aussi consistant (Un libellé visible au niveau de
zoom N le sera aux niveaux N+1, N+2, etc... au moins sur les frontières
s'il d

[OSM-talk-fr] Améliorations de ID

[Arnaud Vandecasteele]

Salut à tous,

N'en déplaise a Philippe qui voyait en l'absence d'outils pour gérer les 
relations dans ID la fin de celles-ci, une MAJ intégrant ce type d'objet 
sera prochainement disponible.
Source: 
http://www.mapbox.com/blog/tuning-openstreetmap-editing-id-editor-1-1/


Au-delà de ca, l'accent a été mis sur les performances et sur 
l'amélioration de l'interface.


Vous pouvez d'ores et déjà essayer cette future version ici:
http://openstreetmap.us/iD/release/#background=Bing&map=20.00/-77.02271/38.90085

Arnaud

--

Arnaud Vandecasteele
SIG - WebMapping - Spatial Ontology - GeoCollaboration

Web Site
http://geotribu.net/

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

Re: [OSM-talk-fr] Proposition de projet du mois (gares SNCF)

[Philippe Verdy]

Si... en même c'est signalé sur Osmose. Il n'y a pas grand chose à faire en
fait, le plus gros est déjà importé.

Un projet serait plutôt de réviser les listes d'objets à intégrer déjà
signalés par Osmose, en se répartissant les régions à faire, pour tous les
POIs importants de repérage (gares, églises et lieux de culte, châteaux
d'eau, émetteurs télécom/TV, musées, poste, police / gendarmerie, offices
de tourisme, parkings fermés très souvent fléchés en ville, services
sociaux comme les CCAS ou accueils de la sécu ou des alloc familiales,
centres Pôle Emploi, stations de péage)

Note : pour les émetteurs, on a des données sur l'Agence nationale des
fréquences, mais nombreux sont difficiles à repérer (notamment les antennes
de téléphonie, et les émetteurs privés installés sur les toits et pas
toujours sur un pylone facilement repérable).

On pourrait toutefois vérifier sur le site de la TNT que les émetteurs TV
sont tous là (très souvent les sites sont aussi porteurs d'autres antennes
de télécommunication, privées ou pour les GSM et les radios FM). Le site de
l'ANF servira pour compléter les antennes des radios FM (mais plus
difficile pour les radios de l'autoroute car les pylones sont peu visibles,
pas très haut, et ont une portée très limitée et fortement directionnelle
en isofréquence, souvent à moins d'1km de l'autoroute on ne les capte plus
du fait déjà de leur puissance faible mais aussi aux interférences entre
eux, liées à leur mode d'émission en isofréquence).

Autre projet : localiser les campings et hôtels (eux aussi souvent fléchés
sur le terrain, ce sont des repères importants même si on n'y va pas). Mais
là difficile car on n'a apparemment pas de base publique, et pas question
d'utiliser les pages jaunes. Toutefois ils sont les premiers à vouloir se
géolocaliser
**eux-même** dans OSM, quitte à ce que ce soit leur fournisseur de site web
qui le fasse pour eux (de la même façon qu'ils cherchent à se référencer
dans divers sites et annuaires), mais pour nous on doit faire un contrôle
qualité de ces imports qui arrivent de façon dispersée et isolée mais
constante de diverses sources.

De même pour les supermarchés et hyper, on est à peu près complet (hormis
changement de dénomination récent), mais pas au point pour les supérettes
en ville (qui reviennent car les hypers en périphérie connaissent un net
recul), ni pour les points de livraison "drive" qui eux aussi s'installent
un peu partout et plus nécessairement en périphérie des villes, et qui
n'ont pas besoin de surfaces aussi importantes de parkings.


Le 7 juin 2013 12:39, Nicolas Dumoulin <
nicolas_openstreetmap@dumoulin63.net> a écrit :

> Le vendredi 7 juin 2013 12:28:33 Christophe Merlet a écrit :
> > Bonjour,
> >
> >
> > Pour un prochain projet du mois je propose d'intégrer toutes les gares
> > et haltes ferroviaires de la SNCF voire un peu plus.
>
> Et on n'avait pas un outil genre integration d'opendata en ligne pour ça ?
>
> --
> Nicolas Dumoulin
> http://wiki.openstreetmap.org/wiki/User:NicolasDumoulin
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Améliorations de ID

[Philippe Verdy]

"M'en déplaise" ? Non. Cela aurait du figurer avant d'annoncer au grand
public que iD n"tait plus en beta.

Mais pour l'instant cela reste encore une bêta qu'on ne peut pas
recommander puisque la mises à jour dont tu parles n'existe pas encore.


Le 7 juin 2013 12:58, Arnaud Vandecasteele  a écrit :

>  Salut à tous,
>
> N'en déplaise a Philippe qui voyait en l'absence d'outils pour gérer les
> relations dans ID la fin de celles-ci, une MAJ intégrant ce type d'objet
> sera prochainement disponible.
> Source:
> http://www.mapbox.com/blog/tuning-openstreetmap-editing-id-editor-1-1/
>
> Au-delà de ca, l'accent a été mis sur les performances et sur
> l'amélioration de l'interface.
>
> Vous pouvez d'ores et déjà essayer cette future version ici:
>
> http://openstreetmap.us/iD/release/#background=Bing&map=20.00/-77.02271/38.90085
>
> Arnaud
>
> --
> 
> Arnaud Vandecasteele
> SIG - WebMapping - Spatial Ontology - GeoCollaboration
>
> Web Sitehttp://geotribu.net/
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Proposition de projet du mois (gares SNCF)

[Nicolas Dumoulin]

Le vendredi 7 juin 2013 13:17:10 Philippe Verdy a écrit :
> Si... en même c'est signalé sur Osmose. Il n'y a pas grand chose à faire en
> fait, le plus gros est déjà importé.

Ok, apparemment, il s'agit de l'erreur 8050
http://osmose.openstreetmap.fr/fr/errors/?country=france&item=8050
Et, effectivement, c'est vide.

Mais alors, je crois que Christophe parlait de compléter les étiquettes de ces 
nœuds.

-- 
Nicolas Dumoulin
http://wiki.openstreetmap.org/wiki/User:NicolasDumoulin

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

Re: [OSM-talk-fr] Proposition de projet du mois (gares SNCF)

[Christophe Merlet]

Le 07/06/2013 13:32, Nicolas Dumoulin a écrit :

Le vendredi 7 juin 2013 13:17:10 Philippe Verdy a écrit :

Si... en même c'est signalé sur Osmose. Il n'y a pas grand chose à faire en
fait, le plus gros est déjà importé.


Ok, apparemment, il s'agit de l'erreur 8050
http://osmose.openstreetmap.fr/fr/errors/?country=france&item=8050
Et, effectivement, c'est vide.

Mais alors, je crois que Christophe parlait de compléter les étiquettes de ces
nœuds.



J'ignore quel est la source de données de ce test, mais elle doit être 
incomplète vu le nombre de gares et haltes que j'ai rajouté et/ou 
requalifié dans mon département... et je n'ai pas fini.



Librement,
--
Christophe Merlet (RedFox)

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

Re: [OSM-talk-fr] Proposition de projet du mois (gares SNCF)

[Frédéric Rodrigo]

Le 07/06/2013 13:45, Christophe Merlet a écrit :

Le 07/06/2013 13:32, Nicolas Dumoulin a écrit :

Le vendredi 7 juin 2013 13:17:10 Philippe Verdy a écrit :

Si... en même c'est signalé sur Osmose. Il n'y a pas grand chose à
faire en
fait, le plus gros est déjà importé.


Ok, apparemment, il s'agit de l'erreur 8050
http://osmose.openstreetmap.fr/fr/errors/?country=france&item=8050
Et, effectivement, c'est vide.

Mais alors, je crois que Christophe parlait de compléter les
étiquettes de ces
nœuds.



J'ignore quel est la source de données de ce test, mais elle doit être
incomplète vu le nombre de gares et haltes que j'ai rajouté et/ou
requalifié dans mon département... et je n'ai pas fini.


Ce n'est pas une analyse activé dans le fronted d'Osmose, bien qu'elle 
soit mise à jour. Je ne me souvient plus de la raison.


On peut tout de me afficher les résultats en activant le mode dev :

http://osmose.openstreetmap.fr/fr/errors/?source=1344&useDevItem=true

http://osmose.openstreetmap.fr/fr/map/?source=1344&useDevItem=true&level=3

Frédéric.


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

Re: [OSM-talk-fr] Améliorations de ID

[Arnaud Vandecasteele]

Philippe,


On 13-06-07 08:49 AM, Philippe Verdy wrote:
"M'en déplaise" ? Non. Cela aurait du figurer avant d'annoncer au 
grand public que iD n"tait plus en beta.


Décidément, tu ne changeras pas, on va dire que cela met un peu de 
piment sur la liste !




Mais pour l'instant cela reste encore une bêta qu'on ne peut pas 
recommander puisque la mises à jour dont tu parles n'existe pas encore.


D'où l'utilisation du "sera prochainement disponible".
Trop fort cette capacité que tu as pour détourner et arranger à ta sauce !


Quoi qu'il en soit, y'a des évolutions et elles sont positives.
C'est ce qu'il est important de retenir.


A.


--

Arnaud Vandecasteele
SIG - WebMapping - Spatial Ontology - GeoCollaboration

Web Site
http://geotribu.net/


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

Re: [OSM-talk-fr] Proposition de projet du mois (gares SNCF)

[Christophe Merlet]

Le 07/06/2013 13:17, Philippe Verdy a écrit :

Si... en même c'est signalé sur Osmose. Il n'y a pas grand chose à faire
en fait, le plus gros est déjà importé.

Un projet serait plutôt de réviser les listes d'objets à intégrer déjà
signalés par Osmose, en se répartissant les régions à faire, pour tous
les POIs importants de repérage (gares, églises et lieux de culte,
châteaux d'eau, émetteurs télécom/TV, musées, poste, police /
gendarmerie, offices de tourisme, parkings fermés très souvent fléchés
en ville, services sociaux comme les CCAS ou accueils de la sécu ou des
alloc familiales, centres Pôle Emploi, stations de péage)

Note : pour les émetteurs, on a des données sur l'Agence nationale des
fréquences, mais nombreux sont difficiles à repérer (notamment les
antennes de téléphonie, et les émetteurs privés installés sur les toits
et pas toujours sur un pylone facilement repérable).

On pourrait toutefois vérifier sur le site de la TNT que les émetteurs
TV sont tous là (très souvent les sites sont aussi porteurs d'autres
antennes de télécommunication, privées ou pour les GSM et les radios
FM). Le site de l'ANF servira pour compléter les antennes des radios FM
(mais plus difficile pour les radios de l'autoroute car les pylones sont
peu visibles, pas très haut, et ont une portée très limitée et fortement
directionnelle en isofréquence, souvent à moins d'1km de l'autoroute on
ne les capte plus du fait déjà de leur puissance faible mais aussi aux
interférences entre eux, liées à leur mode d'émission en isofréquence).

Autre projet : localiser les campings et hôtels (eux aussi souvent
fléchés sur le terrain, ce sont des repères importants même si on n'y va
pas). Mais là difficile car on n'a apparemment pas de base publique, et
pas question d'utiliser les pages jaunes. Toutefois ils sont les
premiers à vouloir se géolocaliser
**eux-même** dans OSM, quitte à ce que ce soit leur fournisseur de site
web qui le fasse pour eux (de la même façon qu'ils cherchent à se
référencer dans divers sites et annuaires), mais pour nous on doit faire
un contrôle qualité de ces imports qui arrivent de façon dispersée et
isolée mais constante de diverses sources.

De même pour les supermarchés et hyper, on est à peu près complet
(hormis changement de dénomination récent), mais pas au point pour les
supérettes en ville (qui reviennent car les hypers en périphérie
connaissent un net recul), ni pour les points de livraison "drive" qui
eux aussi s'installent un peu partout et plus nécessairement en
périphérie des villes, et qui n'ont pas besoin de surfaces aussi
importantes de parkings.



Merci pour ce superbe hors sujet.

Tu es juste en train de dire qu'il faut compléter OSM :/


Librement,
--
Christophe Merlet (RedFox)

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

Re: [OSM-talk-fr] Proposition de projet du mois (gares SNCF)

[Philippe Verdy]

Je crois que le projet du mois c'est de terminer les frontières de
communes, compléter les cantons et EPCI manquants, les référencer avec
Wikipédia (dans les deux sens, car l'ancienne recommandation de Wikipédia
qui disait que la géolocalisation des cantons sur Wikipédia n'était pas
utile ne s'applique plus, même si on doit s'attendre à une division par
deux du nombre de cantons dans les mois qui viennent avant les élections de
2014, il me semble qu'on devrait réfléchir sur le fait de garder ou pas les
anciens cantons pendant encore quelques temps en plus des nouveaux qui vont
apparaître pour les remplacer à terme, car le premier changement ne
concernera que les élections, c'est à dire les circonscriptions électorales
pour les départementales et leurs regroupements pour les futures
législatives, mais pas les cantons administratifs et judiciaires).

Tant qu'on n'a pas vu les nouveaux textes, les cantons ont encore une
existence administrative (qui va encore durer). Car j'en ai assez devoir
dire que les cantons ne sont PAS que des circonscriptions électorales pour
les élections des conseillers généraux (déjà ils ne sont plus entièrement
utilisés comme brique de base pour les législatives qui leur préfèrent
souvent la commune, mais pas toujours dans certaines villes).

A ce sujet j'aimerais qu'enfin on commence à se pencher sur la carte
judiciaire (basée aussi sur les cantons, mais aujourd'hui regroupés sans
tenir compte des découpages de communes, sauf dans les très grandes
villes), avec des boundary=judiciary.



Le 7 juin 2013 13:32, Nicolas Dumoulin <
nicolas_openstreetmap@dumoulin63.net> a écrit :

> Le vendredi 7 juin 2013 13:17:10 Philippe Verdy a écrit :
> > Si... en même c'est signalé sur Osmose. Il n'y a pas grand chose à faire
> en
> > fait, le plus gros est déjà importé.
>
> Ok, apparemment, il s'agit de l'erreur 8050
> http://osmose.openstreetmap.fr/fr/errors/?country=france&item=8050
> Et, effectivement, c'est vide.
>
> Mais alors, je crois que Christophe parlait de compléter les étiquettes de
> ces
> nœuds.
>
> --
> Nicolas Dumoulin
> http://wiki.openstreetmap.org/wiki/User:NicolasDumoulin
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Proposition de projet du mois (gares SNCF)

[Philippe Verdy]

Tu dis qu'OSM est hors sujet 


Le 7 juin 2013 13:50, Christophe Merlet  a écrit :

> Le 07/06/2013 13:17, Philippe Verdy a écrit :
>
>  Si... en même c'est signalé sur Osmose. Il n'y a pas grand chose à faire
>> en fait, le plus gros est déjà importé.
>>
>> Un projet serait plutôt de réviser les listes d'objets à intégrer déjà
>> signalés par Osmose, en se répartissant les régions à faire, pour tous
>> les POIs importants de repérage (gares, églises et lieux de culte,
>> châteaux d'eau, émetteurs télécom/TV, musées, poste, police /
>> gendarmerie, offices de tourisme, parkings fermés très souvent fléchés
>> en ville, services sociaux comme les CCAS ou accueils de la sécu ou des
>> alloc familiales, centres Pôle Emploi, stations de péage)
>>
>> Note : pour les émetteurs, on a des données sur l'Agence nationale des
>> fréquences, mais nombreux sont difficiles à repérer (notamment les
>> antennes de téléphonie, et les émetteurs privés installés sur les toits
>> et pas toujours sur un pylone facilement repérable).
>>
>> On pourrait toutefois vérifier sur le site de la TNT que les émetteurs
>> TV sont tous là (très souvent les sites sont aussi porteurs d'autres
>> antennes de télécommunication, privées ou pour les GSM et les radios
>> FM). Le site de l'ANF servira pour compléter les antennes des radios FM
>> (mais plus difficile pour les radios de l'autoroute car les pylones sont
>> peu visibles, pas très haut, et ont une portée très limitée et fortement
>> directionnelle en isofréquence, souvent à moins d'1km de l'autoroute on
>> ne les capte plus du fait déjà de leur puissance faible mais aussi aux
>> interférences entre eux, liées à leur mode d'émission en isofréquence).
>>
>> Autre projet : localiser les campings et hôtels (eux aussi souvent
>> fléchés sur le terrain, ce sont des repères importants même si on n'y va
>> pas). Mais là difficile car on n'a apparemment pas de base publique, et
>> pas question d'utiliser les pages jaunes. Toutefois ils sont les
>> premiers à vouloir se géolocaliser
>> **eux-même** dans OSM, quitte à ce que ce soit leur fournisseur de site
>> web qui le fasse pour eux (de la même façon qu'ils cherchent à se
>> référencer dans divers sites et annuaires), mais pour nous on doit faire
>> un contrôle qualité de ces imports qui arrivent de façon dispersée et
>> isolée mais constante de diverses sources.
>>
>> De même pour les supermarchés et hyper, on est à peu près complet
>> (hormis changement de dénomination récent), mais pas au point pour les
>> supérettes en ville (qui reviennent car les hypers en périphérie
>> connaissent un net recul), ni pour les points de livraison "drive" qui
>> eux aussi s'installent un peu partout et plus nécessairement en
>> périphérie des villes, et qui n'ont pas besoin de surfaces aussi
>> importantes de parkings.
>>
>>
> Merci pour ce superbe hors sujet.
>
> Tu es juste en train de dire qu'il faut compléter OSM :/
>
>
>
> Librement,
> --
> Christophe Merlet (RedFox)
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Améliorations de ID

[Philippe Verdy]

C'est toi qui arrange les choses. "Disponible prochainement" veut bel et
bien dire "pas encore disponible" car il y a des problèmes à régler, et des
changements encore attendus qu'on ne vas pas vouloir réexpliquer plusieurs
fois différemment aux débutants (ce quoi les rebuter dès le début si on
leur dit vite deux choses contradictoires).

Je maintiens que iD n'est pas encore prêt pour les débutants et qu'on doit
le réserver encore à des utilisateurs un peu plus expérimentés qui ont
conscience des problèmes possibles,et donc éviteront d'effacer des données
dont ils ne voient pas l'intêrêt puisque iD ne le signale pas actuellement.


Le 7 juin 2013 13:49, Arnaud Vandecasteele  a écrit :

> Philippe,
>
>
>
> On 13-06-07 08:49 AM, Philippe Verdy wrote:
>
>> "M'en déplaise" ? Non. Cela aurait du figurer avant d'annoncer au grand
>> public que iD n"tait plus en beta.
>>
>
> Décidément, tu ne changeras pas, on va dire que cela met un peu de piment
> sur la liste !
>
>
>
>> Mais pour l'instant cela reste encore une bêta qu'on ne peut pas
>> recommander puisque la mises à jour dont tu parles n'existe pas encore.
>>
>
> D'où l'utilisation du "sera prochainement disponible".
> Trop fort cette capacité que tu as pour détourner et arranger à ta sauce !
>
>
> Quoi qu'il en soit, y'a des évolutions et elles sont positives.
> C'est ce qu'il est important de retenir.
>
>
> A.
>
>
>
> --
> --**--**
> Arnaud Vandecasteele
> SIG - WebMapping - Spatial Ontology - GeoCollaboration
>
> Web Site
> http://geotribu.net/
>
>
> __**_
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.**org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Proposition de projet du mois (gares SNCF)

[Christophe Merlet]

Le 07/06/2013 13:49, Frédéric Rodrigo a écrit :

Le 07/06/2013 13:45, Christophe Merlet a écrit :

Le 07/06/2013 13:32, Nicolas Dumoulin a écrit :

Le vendredi 7 juin 2013 13:17:10 Philippe Verdy a écrit :

Si... en même c'est signalé sur Osmose. Il n'y a pas grand chose à
faire en
fait, le plus gros est déjà importé.


Ok, apparemment, il s'agit de l'erreur 8050
http://osmose.openstreetmap.fr/fr/errors/?country=france&item=8050
Et, effectivement, c'est vide.

Mais alors, je crois que Christophe parlait de compléter les
étiquettes de ces
nœuds.



J'ignore quel est la source de données de ce test, mais elle doit être
incomplète vu le nombre de gares et haltes que j'ai rajouté et/ou
requalifié dans mon département... et je n'ai pas fini.


Ce n'est pas une analyse activé dans le fronted d'Osmose, bien qu'elle
soit mise à jour. Je ne me souvient plus de la raison.

On peut tout de me afficher les résultats en activant le mode dev :

http://osmose.openstreetmap.fr/fr/errors/?source=1344&useDevItem=true

http://osmose.openstreetmap.fr/fr/map/?source=1344&useDevItem=true&level=3



Merci.
Il y a donc plus de 8000 erreurs à corriger a priori.

Attention à une intégration aveugle. Il faut distinguer manuellement les 
railway=station et les railway=halt depuis le site de la sncf et/ou 
wikipedia (et sa connaissance du terrain).



Librement,
--
Christophe Merlet (RedFox)

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

Re: [OSM-talk-fr] Améliorations de ID

[Léo SERRE]

Salut,

Hors sujet, je vais parler *performances*.

Je partage l'avis du fait qu'iD n'est pas encore prêt, pour une autre 
raison performance (même si la bêta est prometteuse).


Y a t'il un éditeur fluide et puissant ?
J'ai une machine récente de bas de gamme (Intel Pentium P6200 et 2Go de 
RAM), enfin pas si bas je trouve...
La solution jOSM me pompe 600+ Mo de RAM après 15min d'utilisation, 
faute à Java.
iD est pas performant (faute à JavaScript, faudrait se pencher sur 
asm.js), ce qui fait que j'ai un affichage lent du aux calculs intenses.

Poltach, c'est du Flash, trop limité...

J'utilise donc jOSM mais je suis imposé de fermer mon Firefox à chaque fois.

Une suggestion ?

Léo

--
Léo SERRE
  06.18.62.32.05
  leo-serre.legtux.org

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

Re: [OSM-talk-fr] Améliorations de ID

[Arnaud Vandecasteele]

On 13-06-07 09:26 AM, Philippe Verdy wrote:
C'est toi qui arrange les choses. "Disponible prochainement" veut bel 
et bien dire "pas encore disponible" car il y a des problèmes à 
régler, et des changements encore attendus qu'on ne vas pas vouloir 
réexpliquer plusieurs fois différemment aux débutants (ce quoi les 
rebuter dès le début si on leur dit vite deux choses contradictoires).


Comme d'hab, tu extrapoles et tu parles de choses que tu ne maîtrises pas.
On ne sait pas comment ca va évoluer et si ca se trouve cela sera un 
outil parfait pour les débutants.
Apprend à être un peu patient et on verra le moment venu comment 
s'arranger avec les différentes évolutions.
La critique est toujours facile, mais au final c'est en faisant qu'on 
avance !


A.

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

Re: [OSM-talk-fr] Proposition de projet du mois (gares SNCF)

[Frédéric Rodrigo]

Le 07/06/2013 13:58, Christophe Merlet a écrit :

Le 07/06/2013 13:49, Frédéric Rodrigo a écrit :

Le 07/06/2013 13:45, Christophe Merlet a écrit :

Le 07/06/2013 13:32, Nicolas Dumoulin a écrit :

Le vendredi 7 juin 2013 13:17:10 Philippe Verdy a écrit :

Si... en même c'est signalé sur Osmose. Il n'y a pas grand chose à
faire en
fait, le plus gros est déjà importé.


Ok, apparemment, il s'agit de l'erreur 8050
http://osmose.openstreetmap.fr/fr/errors/?country=france&item=8050
Et, effectivement, c'est vide.

Mais alors, je crois que Christophe parlait de compléter les
étiquettes de ces
nœuds.



J'ignore quel est la source de données de ce test, mais elle doit être
incomplète vu le nombre de gares et haltes que j'ai rajouté et/ou
requalifié dans mon département... et je n'ai pas fini.


Ce n'est pas une analyse activé dans le fronted d'Osmose, bien qu'elle
soit mise à jour. Je ne me souvient plus de la raison.

On peut tout de me afficher les résultats en activant le mode dev :

http://osmose.openstreetmap.fr/fr/errors/?source=1344&useDevItem=true

http://osmose.openstreetmap.fr/fr/map/?source=1344&useDevItem=true&level=3




Merci.
Il y a donc plus de 8000 erreurs à corriger a priori.

Attention à une intégration aveugle. Il faut distinguer manuellement les
railway=station et les railway=halt depuis le site de la sncf et/ou
wikipedia (et sa connaissance du terrain).



Attention ! Ce n'est pas une analyse active, a NE PAS UTILISER en l'état.

Les uic_ref=581009 proposées on l'air invalide

Les donnés viennent de là :
http://www.data.gouv.fr/donnees/view/Liste-des-gares-de-voyageurs-du-RFN-avec-coordonn%C3%A9es-30383099

Frédéric.


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

[OSM-talk-fr] Comment tagguer un centre d'accueil de Sécurité Sociale (était Proposition de projet du mois (gares SNCF))

[olivier delaune]

Bonjour, question en passant après avoir lu la prose de Verdy_p

 

Comment taggue-t'on correctement les centres de sécurité sociale ? Pour les 
CCAS, j'ai cru comprendre qu'un amenity=social_centre fonctionne plutôt bien 
mais vu que c'est assez différent d'un centre de sécu, j'imagine qu'on doit 
utiliser un tag différent. La question est également valable pour les autres 
centres mentionnés par Verdy (caisse d'allocations familliales, Pole Emploi, 
...)

 

Merci d'avance

Olivier

 

> 
> Un projet serait plutôt de réviser les listes d'objets à intégrer déjà
> signalés par Osmose, en se répartissant les régions à faire, pour tous les
> POIs importants de repérage (gares, églises et lieux de culte, châteaux
> d'eau, émetteurs télécom/TV, musées, poste, police / gendarmerie, offices
> de tourisme, parkings fermés très souvent fléchés en ville, services
> sociaux comme les CCAS ou accueils de la sécu ou des alloc familiales,
> centres Pôle Emploi, stations de péage)___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Proposition de projet du mois (gares SNCF)

[Ab_fab]

Les gares / haltes cumulent le plus souvent plusieurs erreurs reportées par
Osmose.
Le compteur devrait donc tourner assez vite

Et dans la foulée, entre deux gares, on peut se charger des passages à
niveau
http://osmose.openstreetmap.fr/fr/map/?item=8060

Ce sont des erreurs faciles à corriger (ou bien souvent à marquer en faux
positif quand la voie ferrée n'existe plus)


Le 7 juin 2013 13:58, Christophe Merlet  a écrit :

> Le 07/06/2013 13:49, Frédéric Rodrigo a écrit :
>
>  Le 07/06/2013 13:45, Christophe Merlet a écrit :
>>
>>> Le 07/06/2013 13:32, Nicolas Dumoulin a écrit :
>>>
 Le vendredi 7 juin 2013 13:17:10 Philippe Verdy a écrit :

> Si... en même c'est signalé sur Osmose. Il n'y a pas grand chose à
> faire en
> fait, le plus gros est déjà importé.
>

 Ok, apparemment, il s'agit de l'erreur 8050
 http://osmose.openstreetmap.**fr/fr/errors/?country=france&**item=8050
 Et, effectivement, c'est vide.

 Mais alors, je crois que Christophe parlait de compléter les
 étiquettes de ces
 nœuds.

>>>
>>>
>>> J'ignore quel est la source de données de ce test, mais elle doit être
>>> incomplète vu le nombre de gares et haltes que j'ai rajouté et/ou
>>> requalifié dans mon département... et je n'ai pas fini.
>>>
>>
>> Ce n'est pas une analyse activé dans le fronted d'Osmose, bien qu'elle
>> soit mise à jour. Je ne me souvient plus de la raison.
>>
>> On peut tout de me afficher les résultats en activant le mode dev :
>>
>> http://osmose.openstreetmap.**fr/fr/errors/?source=1344&**useDevItem=true
>>
>> http://osmose.openstreetmap.**fr/fr/map/?source=1344&**
>> useDevItem=true&level=3
>>
>
>
> Merci.
> Il y a donc plus de 8000 erreurs à corriger a priori.
>
> Attention à une intégration aveugle. Il faut distinguer manuellement les
> railway=station et les railway=halt depuis le site de la sncf et/ou
> wikipedia (et sa connaissance du terrain).
>
>
>
> Librement,
> --
> Christophe Merlet (RedFox)
>
> __**_
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.**org/listinfo/talk-fr
>



-- 
ab_fab 
"Il n'y a pas de pas perdus", Nadja
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Améliorations de ID

[Christophe Merlet]

Le 07/06/2013 14:03, Léo SERRE a écrit :

Salut,

Hors sujet, je vais parler *performances*.

Je partage l'avis du fait qu'iD n'est pas encore prêt, pour une autre
raison performance (même si la bêta est prometteuse).

Y a t'il un éditeur fluide et puissant ?
J'ai une machine récente de bas de gamme (Intel Pentium P6200 et 2Go de
RAM), enfin pas si bas je trouve…
La solution jOSM me pompe 600+ Mo de RAM après 15min d'utilisation,
faute à Java.
iD est pas performant (faute à JavaScript, faudrait se pencher sur
asm.js), ce qui fait que j'ai un affichage lent du aux calculs intenses.
Poltach, c'est du Flash, trop limité…

J'utilise donc jOSM mais je suis imposé de fermer mon Firefox à chaque fois.

Une suggestion ?


essaie merkator http://merkaartor.be/

C'est un editeur en C++ qui devrait être plus performant. Mais comme je 
ne l'utilise pas, je ne peux pas t'en dire plus.



Librement,
--
Christophe Merlet (RedFox)

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

Re: [OSM-talk-fr] Comment tagguer un centre d'accueil de Sécurité Sociale (était Proposition de projet du mois (gares SNCF))

[Frédéric Rodrigo]

Le 07/06/2013 14:05, olivier delaune a écrit :

Bonjour, question en passant après avoir lu la prose de Verdy_p

Comment taggue-t'on correctement les centres de sécurité sociale ? Pour
les CCAS, j'ai cru comprendre qu'un amenity=social_centre fonctionne
plutôt bien mais vu que c'est assez différent d'un centre de sécu,
j'imagine qu'on doit utiliser un tag différent. La question est
également valable pour les autres centres mentionnés par Verdy (caisse
d'allocations familliales, Pole Emploi, ...)

Merci d'avance

Olivier

 >
 > Un projet serait plutôt de réviser les listes d'objets à intégrer
déjà
 > signalés par Osmose, en se répartissant les régions à faire, pour
tous les
 > POIs importants de repérage (gares, églises et lieux de culte,
châteaux
 > d'eau, émetteurs télécom/TV, musées, poste, police / gendarmerie,
offices
 > de tourisme, parkings fermés très souvent fléchés en ville, services
 > sociaux comme les CCAS ou accueils de la sécu ou des alloc
familiales,
 > centres Pôle Emploi, stations de péage)


Au passage il y a aussi une nouvelle analyse Osmose pour ça :

http://osmose.openstreetmap.fr/fr/map/?item=8110

Le mapping de tag utilisé :
1, "mairie", {"amenity": "townhall"}, {"amenity": "townhall"})
2, "gendarmerie", {"amenity": "police"}, {"amenity": "police", 
"police:FR": "gendarmerie"})
3, "commissariat_police", {"amenity": "police"}, {"amenity": "police", 
"police:FR": "police"})

4, "epic", {"office": "administrative"}, {"office": "administrative"})
5, "pole_emploi", {"office": "employment_agency"}, {"office": 
"employment_agency"})
6, ["ta", "ti", "tribunal_commerce", "tgi", "te", "cour_appel"], 
{"amenity": "courthouse"}, {"amenity": "courthouse"})
7, ["maison_centrale", "maison_arret", "centre_penitentiaire", 
"centre_detention", "csl"], {"amenity": "prison"}, {"amenity": "prison"})
8, ["prefecture", "sous_pref"], {"office": "government"}, {"office": 
"government"})

9, ["cg", "cr"], {"office": "administrative"}, {"office": "administrative"})

Ça viens de Service-Public.fr

Frédéric.
--
Vous en avez rêvé, Osmose la fait.


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

Re: [OSM-talk-fr] Améliorations de ID

[Philippe Verdy]

Je parle de choses que je ne maîtrise pas ? Je parle de mots parfaitement
compréhensibles. "Disponible prochainement" est clair et ne souffre aucune
interprétation. JE ne dis p


Le 7 juin 2013 14:01, Arnaud Vandecasteele  a écrit :

>
> On 13-06-07 09:26 AM, Philippe Verdy wrote:
>
>> C'est toi qui arrange les choses. "Disponible prochainement" veut bel et
>> bien dire "pas encore disponible" car il y a des problèmes à régler, et des
>> changements encore attendus qu'on ne vas pas vouloir réexpliquer plusieurs
>> fois différemment aux débutants (ce quoi les rebuter dès le début si on
>> leur dit vite deux choses contradictoires).
>>
>
> Comme d'hab, tu extrapoles et tu parles de choses que tu ne maîtrises pas.
> On ne sait pas comment ca va évoluer et si ca se trouve cela sera un outil
> parfait pour les débutants.
> Apprend à être un peu patient et on verra le moment venu comment
> s'arranger avec les différentes évolutions.
> La critique est toujours facile, mais au final c'est en faisant qu'on
> avance !
>
> A.
>
>
> __**_
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.**org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Améliorations de ID

[Philippe Verdy]

De plus je n'ai pas du tout "critiqué" comme tu le prétend le projet iD.
Bref il n'y a que toi qui extrapole les termes, et qui ne sait pas calmer
ton impatience.


Le 7 juin 2013 14:01, Arnaud Vandecasteele  a écrit :

>
> On 13-06-07 09:26 AM, Philippe Verdy wrote:
>
>> C'est toi qui arrange les choses. "Disponible prochainement" veut bel et
>> bien dire "pas encore disponible" car il y a des problèmes à régler, et des
>> changements encore attendus qu'on ne vas pas vouloir réexpliquer plusieurs
>> fois différemment aux débutants (ce quoi les rebuter dès le début si on
>> leur dit vite deux choses contradictoires).
>>
>
> Comme d'hab, tu extrapoles et tu parles de choses que tu ne maîtrises pas.
> On ne sait pas comment ca va évoluer et si ca se trouve cela sera un outil
> parfait pour les débutants.
> Apprend à être un peu patient et on verra le moment venu comment
> s'arranger avec les différentes évolutions.
> La critique est toujours facile, mais au final c'est en faisant qu'on
> avance !
>
> A.
>
>
> __**_
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.**org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Améliorations de ID

[Ab_fab]

iD a encore des soucis avec Firefox
cf. note du blog citée par Arnaud :
http://www.mapbox.com/blog/tuning-openstreetmap-editing-id-editor-1-1/

As-tu tenté ta chance avec Chrome / Chromium ?

Dans quelles conditions utilises-tu JOSM ?
avec l'imagerie Bing ? Avec le cadastre ?
Mon ordi personnel est un netbook qui se fait un peu vieux, et pour ces
deux éditeurs je n'ai pas de souci particulier


Le 7 juin 2013 14:03, Léo SERRE  a écrit :

>  Salut,
>
> Hors sujet, je vais parler *performances*.
>
> Je partage l'avis du fait qu'iD n'est pas encore prêt, pour une autre
> raison performance (même si la bêta est prometteuse).
>
> Y a t'il un éditeur fluide et puissant ?
> J'ai une machine récente de bas de gamme (Intel Pentium P6200 et 2Go de
> RAM), enfin pas si bas je trouve…
> La solution jOSM me pompe 600+ Mo de RAM après 15min d'utilisation, faute
> à Java.
> iD est pas performant (faute à JavaScript, faudrait se pencher sur
> asm.js), ce qui fait que j'ai un affichage lent du aux calculs intenses.
> Poltach, c'est du Flash, trop limité…
>
> J'utilise donc jOSM mais je suis imposé de fermer mon Firefox à chaque
> fois.
>
> Une suggestion ?
>
> Léo
>
> --
> Léo SERRE
>   06.18.62.32.05
>   leo-serre.legtux.org
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>
>


-- 
ab_fab 
"Il n'y a pas de pas perdus", Nadja
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Améliorations de ID

[Léo SERRE]

Je suis plutôt du type pro Firefox, alors désolé, je vais attendre qu'iD 
arrive.


J'utilise jOSM principalement pour corriger des erreurs osmose 
(récupérées via XAPI), le cadastre et les photos aériennes Bing/Toulouse...

Enfin, je ne suis pas un expert mais je m'éclate un peu avec les plug-ins.

iD est vraiment mauvais au niveau performances, jOSM c'est mieux (quand 
il est le seul allumé), je teste Merkaartor là.


Merci ;)

On 2013-06-07 13:22, Ab_fab wrote:

iD a encore des soucis avec Firefox
cf. note du blog citée par Arnaud : 
http://www.mapbox.com/blog/tuning-openstreetmap-editing-id-editor-1-1/


As-tu tenté ta chance avec Chrome / Chromium ?

Dans quelles conditions utilises-tu JOSM ?
avec l'imagerie Bing ? Avec le cadastre ?
Mon ordi personnel est un netbook qui se fait un peu vieux, et pour 
ces deux éditeurs je n'ai pas de souci particulier



Le 7 juin 2013 14:03, Léo SERRE > a écrit :


Salut,

Hors sujet, je vais parler *performances*.

Je partage l'avis du fait qu'iD n'est pas encore prêt, pour une
autre raison performance (même si la bêta est prometteuse).

Y a t'il un éditeur fluide et puissant ?
J'ai une machine récente de bas de gamme (Intel Pentium P6200 et
2Go de RAM), enfin pas si bas je trouve...
La solution jOSM me pompe 600+ Mo de RAM après 15min
d'utilisation, faute à Java.
iD est pas performant (faute à JavaScript, faudrait se pencher sur
asm.js), ce qui fait que j'ai un affichage lent du aux calculs
intenses.
Poltach, c'est du Flash, trop limité...

J'utilise donc jOSM mais je suis imposé de fermer mon Firefox à
chaque fois.

Une suggestion ?

Léo

-- 
Léo SERRE

   06.18.62.32.05
   leo-serre.legtux.org  


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




--
ab_fab 
"Il n'y a pas de pas perdus", Nadja


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


--
Léo SERRE
  06.18.62.32.05
  leo-serre.legtux.org

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

Re: [OSM-talk-fr] Comment tagguer un centre d'accueil de Sécurité Sociale (était Proposition de projet du mois (gares SNCF))

[Ab_fab]

Attends Frédéric,

Ta liste est pas finie :
http://wiki.openstreetmap.org/wiki/FR:Key:social_facility

Et puis quelques perceptions pour financer tout ça :-)
amenity=public_building + office=tax + operator=DGFiP




Le 7 juin 2013 14:20, Frédéric Rodrigo  a écrit :

> Le 07/06/2013 14:05, olivier delaune a écrit :
>
>  Bonjour, question en passant après avoir lu la prose de Verdy_p
>>
>> Comment taggue-t'on correctement les centres de sécurité sociale ? Pour
>> les CCAS, j'ai cru comprendre qu'un amenity=social_centre fonctionne
>> plutôt bien mais vu que c'est assez différent d'un centre de sécu,
>> j'imagine qu'on doit utiliser un tag différent. La question est
>> également valable pour les autres centres mentionnés par Verdy (caisse
>> d'allocations familliales, Pole Emploi, ...)
>>
>> Merci d'avance
>>
>> Olivier
>>
>>  >
>>  > Un projet serait plutôt de réviser les listes d'objets à intégrer
>> déjà
>>  > signalés par Osmose, en se répartissant les régions à faire, pour
>> tous les
>>  > POIs importants de repérage (gares, églises et lieux de culte,
>> châteaux
>>  > d'eau, émetteurs télécom/TV, musées, poste, police / gendarmerie,
>> offices
>>  > de tourisme, parkings fermés très souvent fléchés en ville,
>> services
>>  > sociaux comme les CCAS ou accueils de la sécu ou des alloc
>> familiales,
>>  > centres Pôle Emploi, stations de péage)
>>
>
> Au passage il y a aussi une nouvelle analyse Osmose pour ça :
>
> http://osmose.openstreetmap.**fr/fr/map/?item=8110
>
> Le mapping de tag utilisé :
> 1, "mairie", {"amenity": "townhall"}, {"amenity": "townhall"})
> 2, "gendarmerie", {"amenity": "police"}, {"amenity": "police",
> "police:FR": "gendarmerie"})
> 3, "commissariat_police", {"amenity": "police"}, {"amenity": "police",
> "police:FR": "police"})
> 4, "epic", {"office": "administrative"}, {"office": "administrative"})
> 5, "pole_emploi", {"office": "employment_agency"}, {"office":
> "employment_agency"})
> 6, ["ta", "ti", "tribunal_commerce", "tgi", "te", "cour_appel"],
> {"amenity": "courthouse"}, {"amenity": "courthouse"})
> 7, ["maison_centrale", "maison_arret", "centre_penitentiaire",
> "centre_detention", "csl"], {"amenity": "prison"}, {"amenity": "prison"})
> 8, ["prefecture", "sous_pref"], {"office": "government"}, {"office":
> "government"})
> 9, ["cg", "cr"], {"office": "administrative"}, {"office":
> "administrative"})
>
> Ça viens de Service-Public.fr
>
> Frédéric.
> --
> Vous en avez rêvé, Osmose la fait.
>
>
> __**_
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.**org/listinfo/talk-fr
>



-- 
ab_fab 
"Il n'y a pas de pas perdus", Nadja
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Comment tagguer un centre d'accueil de Sécurité Sociale (était Proposition de projet du mois (gares SNCF))

[Philippe Verdy]

La CAF c'est aussi la Sécurité sociale, même si ce sont des prestations
ouvertes selon des droits différents.
Noter que la Sécu c'est un système comprenant diverses caisses et régimes,
ce n'est pas un organisme unique. Les accueils sont différents pour
certains régimes, ou peuvent être regroupés au même lieu, mais pas toujours
(et quand c'est au même liu ce n'est pas non plus le même personnel
habilité à traiter les dossiers confidentiels, celui qui s'occupe du régime
de santé ne s'occupe pas de celui des retraites, ou des prestations RSA, et
n'a pas non plus accès au dossier médical qui n'est consultable que par les
médecins contrôleurs ; ceux qui s'occupent des recettes ne traitent pas les
prestations aux assurés, les données sont séparées pour préserver le secret
médical ou les données fiscales des assurés que l'employeur n'a pas à
connaitre).



Le 7 juin 2013 14:05, olivier delaune  a écrit :

> Bonjour, question en passant après avoir lu la prose de Verdy_p
>
>
>
> Comment taggue-t'on correctement les centres de sécurité sociale ? Pour
> les CCAS, j'ai cru comprendre qu'un amenity=social_centre fonctionne plutôt
> bien mais vu que c'est assez différent d'un centre de sécu, j'imagine qu'on
> doit utiliser un tag différent. La question est également valable pour les
> autres centres mentionnés par Verdy (caisse d'allocations familliales, Pole
> Emploi, ...)
>
>
>
> Merci d'avance
>
> Olivier
>
>
>
> >
> > Un projet serait plutôt de réviser les listes d'objets à intégrer déjà
> > signalés par Osmose, en se répartissant les régions à faire, pour tous
> les
> > POIs importants de repérage (gares, églises et lieux de culte, châteaux
> > d'eau, émetteurs télécom/TV, musées, poste, police / gendarmerie, offices
> > de tourisme, parkings fermés très souvent fléchés en ville, services
> > sociaux comme les CCAS ou accueils de la sécu ou des alloc familiales,
> > centres Pôle Emploi, stations de péage)
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Comment tagguer un centre d'accueil de Sécurité Sociale (était Proposition de projet du mois (gares SNCF))

[Philippe Verdy]

Le 7 juin 2013 14:20, Frédéric Rodrigo  a écrit :

> Le mapping de tag utilisé :
> 3, "commissariat_police", {"amenity": "police"}, {"amenity": "police",
> "police:FR": "police"})
>

Pas assez précis !  Il manque les distinctions entre police municipale
(chargée du stationnement par exemple) et la police nationale. Et tous les
établissements de police ou gendarmerie n'ont pas d'accueil direct pour le
public.
On peut aussi rajouter les services spécialisés (la DST par exemple, qui
n'est pas un "commissariat" mais a un accueil public dans les villes
préfectures; ou les brigades financières).
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Améliorations de ID

[Ab_fab]

Est-ce que tu charges en totalité de vastes zones avec XAPI ?
Si oui, est-ce vraiment nécessaire ?

Il y a un plugin osmose pour JOSM qui existe mais qui est resté assez
confidentiel.
Il permet d'aller rapidement là où sont les erreurs et de limiter au
maximum la quantité de données déchargées du serveur

Sans parler de la fonction JOSM fix dans les infobulles osmose, qui charge
le minimum JOSM


Le 7 juin 2013 14:27, Léo SERRE  a écrit :

>  Je suis plutôt du type pro Firefox, alors désolé, je vais attendre qu'iD
> arrive.
>
> J'utilise jOSM principalement pour corriger des erreurs osmose (récupérées
> via XAPI), le cadastre et les photos aériennes Bing/Toulouse…
> Enfin, je ne suis pas un expert mais je m'éclate un peu avec les plug-ins.
>
> iD est vraiment mauvais au niveau performances, jOSM c'est mieux (quand il
> est le seul allumé), je teste Merkaartor là.
>
> Merci ;)
>
>
> On 2013-06-07 13:22, Ab_fab wrote:
>
> iD a encore des soucis avec Firefox
> cf. note du blog citée par Arnaud :
> http://www.mapbox.com/blog/tuning-openstreetmap-editing-id-editor-1-1/
>
> As-tu tenté ta chance avec Chrome / Chromium ?
>
>  Dans quelles conditions utilises-tu JOSM ?
> avec l'imagerie Bing ? Avec le cadastre ?
> Mon ordi personnel est un netbook qui se fait un peu vieux, et pour ces
> deux éditeurs je n'ai pas de souci particulier
>
>
> Le 7 juin 2013 14:03, Léo SERRE  a écrit :
>
>>  Salut,
>>
>> Hors sujet, je vais parler *performances*.
>>
>> Je partage l'avis du fait qu'iD n'est pas encore prêt, pour une autre
>> raison performance (même si la bêta est prometteuse).
>>
>> Y a t'il un éditeur fluide et puissant ?
>> J'ai une machine récente de bas de gamme (Intel Pentium P6200 et 2Go de
>> RAM), enfin pas si bas je trouve…
>> La solution jOSM me pompe 600+ Mo de RAM après 15min d'utilisation, faute
>> à Java.
>> iD est pas performant (faute à JavaScript, faudrait se pencher sur
>> asm.js), ce qui fait que j'ai un affichage lent du aux calculs intenses.
>> Poltach, c'est du Flash, trop limité…
>>
>> J'utilise donc jOSM mais je suis imposé de fermer mon Firefox à chaque
>> fois.
>>
>> Une suggestion ?
>>
>> Léo
>>
>> --
>> Léo SERRE
>>   06.18.62.32.05
>>   leo-serre.legtux.org
>>
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/talk-fr
>>
>>
>
>
>  --
> ab_fab 
> "Il n'y a pas de pas perdus", Nadja
>
>
> ___
> Talk-fr mailing 
> listTalk-fr@openstreetmap.orghttp://lists.openstreetmap.org/listinfo/talk-fr
>
>
> --
> Léo SERRE
>   06.18.62.32.05
>   leo-serre.legtux.org
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>
>


-- 
ab_fab 
"Il n'y a pas de pas perdus", Nadja
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Améliorations de ID

[Léo SERRE]

On s'écarte mais ma méthode :

 * Trouver une erreur, déterminer une méthode pour la récupérer,
 * Lancer la requête via overpass-turbo.eu (sur la région Midi-Pyrénées
   au maximum)
 * Ouvrir le résultat dans jOSM
 * Sélectionner les objets (via la recherche)
 * Via le plug-in magique Totolist, corriger les erreurs,
 * Envoyer le tout.

Je pense que c'est la méthode à utiliser vu la simplicité, mais je me 
trompe peut-être.
Note, Les réponse des requêtes sont longues parfois (dépend de la zone) 
mais il y a toujours peu de données (une 100aine de points)


Léo


On 2013-06-07 13:33, Ab_fab wrote:

Est-ce que tu charges en totalité de vastes zones avec XAPI ?
Si oui, est-ce vraiment nécessaire ?

Il y a un plugin osmose pour JOSM qui existe mais qui est resté assez 
confidentiel.
Il permet d'aller rapidement là où sont les erreurs et de limiter au 
maximum la quantité de données déchargées du serveur


Sans parler de la fonction JOSM fix dans les infobulles osmose, qui 
charge le minimum JOSM



Le 7 juin 2013 14:27, Léo SERRE > a écrit :


Je suis plutôt du type pro Firefox, alors désolé, je vais attendre
qu'iD arrive.

J'utilise jOSM principalement pour corriger des erreurs osmose
(récupérées via XAPI), le cadastre et les photos aériennes
Bing/Toulouse...
Enfin, je ne suis pas un expert mais je m'éclate un peu avec les
plug-ins.

iD est vraiment mauvais au niveau performances, jOSM c'est mieux
(quand il est le seul allumé), je teste Merkaartor là.

Merci ;)


On 2013-06-07 13:22, Ab_fab wrote:

iD a encore des soucis avec Firefox
cf. note du blog citée par Arnaud :
http://www.mapbox.com/blog/tuning-openstreetmap-editing-id-editor-1-1/

As-tu tenté ta chance avec Chrome / Chromium ?

Dans quelles conditions utilises-tu JOSM ?
avec l'imagerie Bing ? Avec le cadastre ?
Mon ordi personnel est un netbook qui se fait un peu vieux, et
pour ces deux éditeurs je n'ai pas de souci particulier


Le 7 juin 2013 14:03, Léo SERRE mailto:leo-se...@legtux.org>> a écrit :

Salut,

Hors sujet, je vais parler *performances*.

Je partage l'avis du fait qu'iD n'est pas encore prêt, pour
une autre raison performance (même si la bêta est prometteuse).

Y a t'il un éditeur fluide et puissant ?
J'ai une machine récente de bas de gamme (Intel Pentium P6200
et 2Go de RAM), enfin pas si bas je trouve...
La solution jOSM me pompe 600+ Mo de RAM après 15min
d'utilisation, faute à Java.
iD est pas performant (faute à JavaScript, faudrait se
pencher sur asm.js), ce qui fait que j'ai un affichage lent
du aux calculs intenses.
Poltach, c'est du Flash, trop limité...

J'utilise donc jOSM mais je suis imposé de fermer mon Firefox
à chaque fois.

Une suggestion ?

Léo

-- 
Léo SERRE

   06.18.62.32.05
   leo-serre.legtux.org  


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




-- 
ab_fab 

"Il n'y a pas de pas perdus", Nadja


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


-- 
Léo SERRE

   06.18.62.32.05
   leo-serre.legtux.org  


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




--
ab_fab 
"Il n'y a pas de pas perdus", Nadja


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


--
Léo SERRE
  06.18.62.32.05
  leo-serre.legtux.org

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

Re: [OSM-talk-fr] Proposition de projet du mois (gares SNCF)

[Philippe Verdy]

Dans la même foulée, a-t-on une analyse de la continuité des lignes
ferroviaires ? Car c'est souvent le souk quand on regarde de prêt, des tas
de voies se terminent en cul de sac dans OSM parce qu'on ne'en a tracé
qu'une seul ou qu'on a oublié de les interconnecter (et les interconnexions
sont souvent très éloignées de la géométrie observable.

Dès qu'on s'approche des villes avec des zones de garage et de frêt c'est
carrément bordélique. Mais ça demandera plus que le projet du mois car il
est difficile de savoir si les voies sont encore en service ou juste laissé
en l'état, ou bien partiellement démontée (parfois même par des voleurs de
métaux, mais pas remplacées pour autant faute de client utilisateur). Il
semble que RFF prenne les devants maintenant et démonte les voies et câbles
inutilisés pour éviter de se les faire piller et faire quelques économies
par la revente de ces métaux ou leur remisage pour l'entretien d'autres
voies actives.



Le 7 juin 2013 14:08, Ab_fab  a écrit :

> Les gares / haltes cumulent le plus souvent plusieurs erreurs reportées
> par Osmose.
> Le compteur devrait donc tourner assez vite
>
> Et dans la foulée, entre deux gares, on peut se charger des passages à
> niveau
> http://osmose.openstreetmap.fr/fr/map/?item=8060
>
> Ce sont des erreurs faciles à corriger (ou bien souvent à marquer en faux
> positif quand la voie ferrée n'existe plus)
>
>
> Le 7 juin 2013 13:58, Christophe Merlet  a écrit
> :
>
> Le 07/06/2013 13:49, Frédéric Rodrigo a écrit :
>>
>>  Le 07/06/2013 13:45, Christophe Merlet a écrit :
>>>
 Le 07/06/2013 13:32, Nicolas Dumoulin a écrit :

> Le vendredi 7 juin 2013 13:17:10 Philippe Verdy a écrit :
>
>> Si... en même c'est signalé sur Osmose. Il n'y a pas grand chose à
>> faire en
>> fait, le plus gros est déjà importé.
>>
>
> Ok, apparemment, il s'agit de l'erreur 8050
> http://osmose.openstreetmap.**fr/fr/errors/?country=france&**item=8050
> Et, effectivement, c'est vide.
>
> Mais alors, je crois que Christophe parlait de compléter les
> étiquettes de ces
> nœuds.
>


 J'ignore quel est la source de données de ce test, mais elle doit être
 incomplète vu le nombre de gares et haltes que j'ai rajouté et/ou
 requalifié dans mon département... et je n'ai pas fini.

>>>
>>> Ce n'est pas une analyse activé dans le fronted d'Osmose, bien qu'elle
>>> soit mise à jour. Je ne me souvient plus de la raison.
>>>
>>> On peut tout de me afficher les résultats en activant le mode dev :
>>>
>>> http://osmose.openstreetmap.**fr/fr/errors/?source=1344&**
>>> useDevItem=true
>>>
>>> http://osmose.openstreetmap.**fr/fr/map/?source=1344&**
>>> useDevItem=true&level=3
>>>
>>
>>
>> Merci.
>> Il y a donc plus de 8000 erreurs à corriger a priori.
>>
>> Attention à une intégration aveugle. Il faut distinguer manuellement les
>> railway=station et les railway=halt depuis le site de la sncf et/ou
>> wikipedia (et sa connaissance du terrain).
>>
>>
>>
>> Librement,
>> --
>> Christophe Merlet (RedFox)
>>
>> __**_
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> http://lists.openstreetmap.**org/listinfo/talk-fr
>>
>
>
>
> --
> ab_fab 
> "Il n'y a pas de pas perdus", Nadja
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Proposition de projet du mois (gares SNCF)

[Yves Pratter]

Le 7 juin 2013 à 14:04, Frédéric Rodrigo  a écrit :

> Les donnés viennent de là :
> http://www.data.gouv.fr/donnees/view/Liste-des-gares-de-voyageurs-du-RFN-avec-coordonn%C3%A9es-30383099

Je n'ai pas vu de code UIC là-dedans.

Par contre ils se trouvent ici (pour les gares voyageurs en France) :
DRR_2014_-_Annexe_7_3_liste_des_gares_voy.pdf

--
Yves___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Présentation d'un petit nouveau / Production d'une carte avec un rendu spécifique

[Carfil Cem]

Bonjour à toutes et à tous,

 

Tout d'abord, je me présente, je m'appelle Cem CARFIL, je suis DSI dans la 
commune de Dammarie-Les-Lys en Seine et Marne et j'utilise régulièrement OSM 
depuis pratiquement 2 ans.

Nous disposons de matériel de relevé sur le terrain (j'avais fais l'acquisition 
il y a 2 ans d'un GPS Hemisphere CRESCENT A100 avec le PDA Nautiz X7 et une 
solution logicielle Digiterra) mais également de solutions plus traditionnelles 
comme le Tibook (un Classmate semi-durci avec 3G et GPS intégré) le tout 
embarqués dans le véhicule atelier de la DSI (support pour poser et utiliser le 
portable par le passager ou le conducteur, alimentation des équipements...).

J'utilise pour ma part à titre pro et perso QGIS que j'ai déployé sur quelques 
postes en mairie (BET/Urbanisme) pour des besoins de consultation de données 
IGN (données INSPIRE)  et internes (réseaux ville + orthophoto).

Ces utilisateurs ont pu découvrir l'utilisation d'OSM lors d'une initiation à 
Potlach dans le cadre de la mise à jour des voiries de la commune, ils ont pu 
constater l'efficacité et la facilité d'utilisation de l'outil.

 

La notion de SIG est en plein bouillonnement dans l'esprit de certains 
utilisateurs qui y voient un gain de temps et d'efficacité. L'aspect 
contributif d'OSM a également été l'objet d'une découverte avec plein de 
question (« y'a des gens qui font çà gratuitement ? ... c'est un travail de 
dingue  Et si qqun supprime des voiries de la ville ? .). 

 

Nous avons avec mes techniciens effectués des mises à jour de nombreuses 
voiries dans le cadre du Plan de Rénovation Urbaine afin de coller à la réalité 
du terrain, les plans Google et consort n'étant pas à jour sur le centre ville.

J'ai pu édité un plan de ville pour la communication avec l'outil MapOSMatic 
dont le rendu ne correspond pas exactement aux attentes. Je me suis lancé dans 
l'aventure avec TileMill avec des résultats variables (estétiquement parlant 
j'entend, n'étant pas doué pour les chartes graphiques !).

Je me demandais s'il n'était pas possible d'avoir un équivalent de MapOSMatic 
mais avec un rendu qui supprimerait certaines couches inutiles tout en gardant 
le principe de la carte de ville traditionnelle (index des 
rues/quadrillage/...) ?

J'ai tenté avec QGIS mais pour le coup je n'ai pas l'aspect Com qui va bien...

 

Je pense que certains ont dû être confrontés à ce genre de demande venant de 
leur service com ? Auriez-vous des idées à me suggérer ?

 

D'avance merci.

 

 

Cem CARFIL

Directeur des Systèmes d'Information

 

Mairie de DAMMARIE LES LYS

Direction des Systèmes d'Information

 

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

Re: [OSM-talk-fr] Présentation de TileMill au FROG2013... vos avis

[Christian Quest]

Pour certains logos incontournables, pourquoi pas, mais on a déjà eu
une longue discussion à ce sujet... et il faut faire ces choix avec
prudence.


Le 7 juin 2013 12:05, Yves Pratter  a écrit :
> Je découvre la Visite guidée du rendu OSM :-)
> http://u.osmfr.org/fr/m/4/
>
> Un petit hic, les liens pointent toujours sur la Gare de Lyon — un problème
> de copier/coller ;-) ?.
> Heureusement en faisant un zoom arrière, j'arrive à comprendre la logique.
>
> Merci.
>
> PS: est-ce prévu à terme de mettre les logos des opérateurs des autres pays
> ?
> (au moins pour les pays francophones : CFF en suisse…)
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>



-- 
Christian Quest - OpenStreetMap France
Un nouveau serveur pour OSM... http://donate.osm.org/server2013/

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

Re: [OSM-talk-fr] Présentation d'un petit nouveau / Production d'une carte avec un rendu spécifique

[Ab_fab]

Tu peux consulter le dépot de ocitysmap, qui est au coeur du rendu de
MapOSMatic :
http://git.savannah.gnu.org/cgit/maposmatic/ocitysmap.git/tree/

Le fichier install me semble bien documenté.
Si tu arrives à générer le plan avec les feuilles de style intégrées, tu
pourras probablement faire la même démarche avec une feuille de style que
tu auras préparée aux petits oignons.

Peut être pas des plus faciles, mais comme tu t'intéresses à une zone
restreinte, ça peut se tenter :-)



Le 7 juin 2013 14:51, Carfil Cem  a
écrit :

> Bonjour à toutes et à tous,
>
> ** **
>
> Tout d’abord, je me présente, je m’appelle Cem CARFIL, je suis DSI dans la
> commune de Dammarie-Les-Lys en Seine et Marne et j’utilise régulièrement
> OSM depuis pratiquement 2 ans.
>
> Nous disposons de matériel de relevé sur le terrain (j’avais fais
> l’acquisition il y a 2 ans d’un GPS Hemisphere CRESCENT A100 avec le PDA
> Nautiz X7 et une solution logicielle Digiterra) mais également de solutions
> plus traditionnelles comme le Tibook (un Classmate semi-durci avec 3G et
> GPS intégré) le tout embarqués dans le véhicule atelier de la DSI
> (support pour poser et utiliser le portable par le passager ou le
> conducteur, alimentation des équipements…).
>
> J’utilise pour ma part à titre pro et perso QGIS que j’ai déployé sur
> quelques postes en mairie (BET/Urbanisme) pour des besoins de consultation
> de données IGN (données INSPIRE)  et internes (réseaux ville + orthophoto
> ).
>
> Ces utilisateurs ont pu découvrir l’utilisation d’OSM lors d’une
> initiation à Potlach dans le cadre de la mise à jour des voiries de la
> commune, ils ont pu constater l’efficacité et la facilité d’utilisation de
> l’outil.
>
> ** **
>
> La notion de SIG est en plein bouillonnement dans l’esprit de certains
> utilisateurs qui y voient un gain de temps et d’efficacité. L’aspect
> contributif d’OSM a également été l’objet d’une découverte avec plein de
> question (« y’a des gens qui font çà gratuitement ? … c’est un travail de
> dingue …. Et si qqun supprime des voiries de la ville ? …..). 
>
> ** **
>
> Nous avons avec mes techniciens effectués des mises à jour de nombreuses
> voiries dans le cadre du Plan de Rénovation Urbaine afin de coller à la
> réalité du terrain, les plans Google et consort n’étant pas à jour sur le
> centre ville.
>
> J’ai pu édité un plan de ville pour la communication avec l’outil
> MapOSMatic dont le rendu ne correspond pas exactement aux attentes. Je me
> suis lancé dans l’aventure avec TileMill avec des résultats variables
> (estétiquement parlant j’entend, n’étant pas doué pour les chartes
> graphiques !).
>
> Je me demandais s’il n’était pas possible d’avoir un équivalent de
> MapOSMatic mais avec un rendu qui supprimerait certaines couches inutiles
> tout en gardant le principe de la carte de ville traditionnelle (index des
> rues/quadrillage/…) ?
>
> J’ai tenté avec QGIS mais pour le coup je n’ai pas l’aspect Com qui va
> bien…
>
> ** **
>
> Je pense que certains ont dû être confrontés à ce genre de demande venant
> de leur service com ? Auriez-vous des idées à me suggérer ?
>
> ** **
>
> D’avance merci.
>
> ** **
>
> ** **
>
> Cem CARFIL
>
> Directeur des Systèmes d’Information
>
> ** **
>
> Mairie de DAMMARIE LES LYS
>
> Direction des Systèmes d’Information
>
> ** **
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>
>


-- 
ab_fab 
"Il n'y a pas de pas perdus", Nadja
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Proposition de projet du mois (gares SNCF)

[Marc SIBERT]

Bonjour,

Je n'ai repris tous tes exemples, mais le comportement que tu décris est...
normal !
C'est un peu tiré par les cheveux mais c'est lié au fonctionnement de
l'outil Nominatim.

Si tu cherches une gare, c'est un lieu qui *a* un nom : lyon part-dieu et
qui *est* une gare (en. station)
essaie : [station] Lyon
Part-Dieu

Il est vrai que le mot "gare" pourrait être traité, malheureusement le
terme actif est "gare ferroviaire"
Voilà : 
Gare
ferroviaire de lyon
part-dieu

Quand au fait que le point "station" se trouve sur les voies, j'imagine que
ça été fait pour faire du routage de train et pas de voiture. C'est bien le
bâtiment de la gare que tu cherches à rejoindre (building = station, name =
gare de ballancourt), pas l'arrêt (railway = station, name = ballancourt).
Il faut être précis dans la définition des éléments déclarés dans la carte
à défaut d'être précis dans la requête.

Mes 0.02 €

A+



Le 7 juin 2013 15:31, Yves Pratter  a écrit :

>
> Le 7 juin 2013 à 12:28, Christophe Merlet  a
> écrit :
>
> Ces nœuds devraient être placés sur le railway le plus proche de la gare
> (il me semble).
>
> Je trouve le résultat bizarre…
>
>- visuellement : ce n'est pas très lisible. Pour les arrêts, on dirait
>même qu'il y a quelque chose sur la voie ;-D
>
>
>
>- pratiquement : je peux aller aussi à la gare… en voiture.
>J'espère que le logiciel de guidage va me "déposer" à l'entrée de la
>gare, pas sur les voies.
>Voir ci-dessous exemples de recherches de gares peu fructueux.
>
>
> Il me semble que le logo devrait être sur le bâtiment principal de la gare
> — là où se trouve le libellé gare.
> Ça me semble valable pour les petites gares :
>
>
> 
>
> Le nom gare pourrait être "masqué" mais saisi pour permettre des
> recherches via nominatim ?
> En utilisant par exemple l'étiquette *alt_name *ou *short_name. *À moins
> qu'il s'agisse "juste" d'un paramétrage de Mapnik pour la France.
> (Voir ça avec les cartographiques aguéris).
>
> Tient à Annecy, il n'y a même pas le nom gare : la recherche "gare 
> annecy" tombe
> au mauvais endroit :-(
>
> 
> "gare Chambéry"  indique
> un arrêt de bus "loin" de la gare en zoom 20 !! :-(
>
> "gare lyon"  c'est pire !!
> "gare sncf lyon"  guère
> mieux !
>
> Il faut explicitement chercher "gare lyon 
> part-dieu"
>  ou "gare lyon 
> perruche"
> .
> Quand à "gare brotteaux lyon" 
> (désaffectée),
> on tombe sur des bornes Vélov !!
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>
>


-- 
Marc Sibert
m...@sibert.fr
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] rendu osm-fr et réserves naturelles

[Christian Quest]

Le 7 juin 2013 12:52, Philippe Verdy  a écrit :
> === 1. maillage pour les "RN" ===
>
> Avec une disposition à mailles carrées orientées à 30 ou 60 degrés on a
> encore des textures régulières disposables en pavés rectangulaires. c'est
> souvent un angle pratique pour éviter cet aspect trop mécanique.
>

Par exemple comme ça ?

http://cl.ly/image/2s000O3W3Z0B

RN au lien de NR, plus espacé et en quinconce, pourtour plus épais et
en pointillé...

C'est quand même plus "light" que
http://tile.openstreetmap.fr/?zoom=13&lat=47.2844&lon=-2.4595&layers=B0F

-- 
Christian Quest - OpenStreetMap France
Un nouveau serveur pour OSM... http://donate.osm.org/server2013/

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

Re: [OSM-talk-fr] Proposition de projet du mois (gares SNCF)

[Yves Pratter]

Le 7 juin 2013 à 16:06, Marc SIBERT  a écrit :

> Si tu cherches une gare, c'est un lieu qui *a* un nom : lyon part-dieu et qui 
> *est* une gare (en. station)
> essaie : [station] Lyon Part-Dieu
> 
En bon débutant, je ne connaissais pas cette syntaxe. Je ne là trouve pas dans 
la doc http://wiki.openstreetmap.org/wiki/FR:Nominatim
Tu peux m'éclairer ?

Merci,

PS: je ne vois pas gare dans la liste 
http://wiki.openstreetmap.org/wiki/Nominatim/Special_Phrases alors qu'il y a 
Bahnhof: (railway=station)

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

Re: [OSM-talk-fr] rendu osm-fr et réserves naturelles

[Philippe Verdy]

OK la disposition en triangles plutôt qu'en carré convient bien. c'est
assez léger et ne cache plus trop de détails. On voit encore assez de "RN"
pour savoir où on est.


Le 7 juin 2013 16:09, Christian Quest  a écrit :

> Le 7 juin 2013 12:52, Philippe Verdy  a écrit :
> > === 1. maillage pour les "RN" ===
> >
> > Avec une disposition à mailles carrées orientées à 30 ou 60 degrés on a
> > encore des textures régulières disposables en pavés rectangulaires. c'est
> > souvent un angle pratique pour éviter cet aspect trop mécanique.
> >
>
> Par exemple comme ça ?
>
> http://cl.ly/image/2s000O3W3Z0B
>
> RN au lien de NR, plus espacé et en quinconce, pourtour plus épais et
> en pointillé...
>
> C'est quand même plus "light" que
>
> http://tile.openstreetmap.fr/?zoom=13&lat=47.2844&lon=-2.4595&layers=B0F
>
> --
> Christian Quest - OpenStreetMap France
> Un nouveau serveur pour OSM... http://donate.osm.org/server2013/
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] rendu osm-fr et réserves naturelles

[Yves Pratter]

> Par exemple comme ça ?
> http://cl.ly/image/2s000O3W3Z0B
Ah oui, c'est effectivement plus sobre :-)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] rendu osm-fr et réserves naturelles

[Philippe Verdy]

Réflexion faite je pense que les pointillés ici sont de trop et qu'on
verrais bien malgré tout une ligne verte épaisse de bordure, même si elle
est semi-transparente. On peut le rendre assez discrète en rendant le bord
avec une ligne fine moins transparente, en la traçant par dessus une autre
ligne plus épaisse également semi-transparente (pour créer un effet d'ombre
verte qui s'atténue vers le centre de la zone, mais est plus contrasté sur
le bord le plus externe).

Ceci permettrait même alors d'éviter de remplir la zone avec une texture
quelconque (donc suppression même du "RN") grâce à ce pourtour ombré épais
mais atténué progressivement vers l'intérieur. tout dépend alors de la
complexité du calcul des buffers multiples (problème de performance à voir
selon le nombre de polygones à créer pour les lignes vertes épaisses de
contour et de transparence croissante vers l'intérieur)



2013/6/7 Yves Pratter 

> > Par exemple comme ça ?
> > http://cl.ly/image/2s000O3W3Z0B
> Ah oui, c'est effectivement plus sobre :-)
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] rendu osm-fr et réserves naturelles

[JB]

 

Mouaif, je vais encore faire mon rabat-joie, en fin de discussion,
en plus… 

Pour moi, RN en vert n'évoque pas grand chose, à part pour me
dire que ça doit pas être une route nationale. 

Et avec ça, j'ai pas
grand chose à proposer, en plus. Voilà comment c'est géré dans R25…
faute de mieux… Pour de la carte web, je pense que j'essayerais plutôt
un hachurage diagonal vert. 

JB. 

Le 07.06.2013 16:34, Philippe Verdy
a écrit : 

> OK la disposition en triangles plutôt qu'en carré convient
bien. c'est assez léger et ne cache plus trop de détails. On voit encore
assez de "RN" pour savoir où on est. 
> 
> Le 7 juin 2013 16:09,
Christian Quest  a écrit :
> 
>> Le 7 juin 2013
12:52, Philippe Verdy  a écrit :
>> 
>>> === 1.
maillage pour les "RN" ===
>> >
>> > Avec une disposition à mailles
carrées orientées à 30 ou 60 degrés on a
>> > encore des textures
régulières disposables en pavés rectangulaires. c'est
>> > souvent un
angle pratique pour éviter cet aspect trop mécanique.
>> >
>> 
>> Par
exemple comme ça ?
>> 
>> http://cl.ly/image/2s000O3W3Z0B [1]
>> 
>> RN
au lien de NR, plus espacé et en quinconce, pourtour plus épais et
>> en
pointillé...
>> 
>> C'est quand même plus "light" que
>>
http://tile.openstreetmap.fr/?zoom=13&lat=47.2844&lon=-2.4595&layers=B0F
[2]
>> 
>> --
>> Christian Quest - OpenStreetMap France
>> Un nouveau
serveur pour OSM... http://donate.osm.org/server2013/ [3]
> 
>
___
> Talk-fr mailing list
>
Talk-fr@openstreetmap.org
>
http://lists.openstreetmap.org/listinfo/talk-fr [4]




Links:
--
[1] http://cl.ly/image/2s000O3W3Z0B
[2]
http://tile.openstreetmap.fr/?zoom=13&lat=47.2844&lon=-2.4595&layers=B0F
[3]
http://donate.osm.org/server2013/
[4]
http://lists.openstreetmap.org/listinfo/talk-fr
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] rendu osm-fr et réserves naturelles

[Christian Quest]

Le problème c'est dans quelle couche traiter la frontière.
Elle risque d'être masquée par pas mal de routes, d'où na nécessité de
la texture des "RN".

Un double trait (épais puis fin) ne pose pas de problème de perf de
calcul si il s'appuie sur le polygone d'origine de la réserver.
Pour un effet dégradé vers l'intérieur, ça doit être possible en
utilisant une texture pour le trait... à tester.

Par contre, ce qui manque c'est le nom de la réserve...

Le 7 juin 2013 16:45, Philippe Verdy  a écrit :
> Réflexion faite je pense que les pointillés ici sont de trop et qu'on
> verrais bien malgré tout une ligne verte épaisse de bordure, même si elle
> est semi-transparente. On peut le rendre assez discrète en rendant le bord
> avec une ligne fine moins transparente, en la traçant par dessus une autre
> ligne plus épaisse également semi-transparente (pour créer un effet d'ombre
> verte qui s'atténue vers le centre de la zone, mais est plus contrasté sur
> le bord le plus externe).
>
> Ceci permettrait même alors d'éviter de remplir la zone avec une texture
> quelconque (donc suppression même du "RN") grâce à ce pourtour ombré épais
> mais atténué progressivement vers l'intérieur. tout dépend alors de la
> complexité du calcul des buffers multiples (problème de performance à voir
> selon le nombre de polygones à créer pour les lignes vertes épaisses de
> contour et de transparence croissante vers l'intérieur)
>
>
>
> 2013/6/7 Yves Pratter 
>>
>> > Par exemple comme ça ?
>> > http://cl.ly/image/2s000O3W3Z0B
>> Ah oui, c'est effectivement plus sobre :-)
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/talk-fr
>
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>



-- 
Christian Quest - OpenStreetMap France
Un nouveau serveur pour OSM... http://donate.osm.org/server2013/

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

Re: [OSM-talk-fr] rendu osm-fr et réserves naturelles

[Philippe Verdy]

Je n'aime pas trop les hachures, on va retomber dans le même cas où cela
cache top de détails.

Les réserves naturelles sont souvent assez grandes pour que l'on n'ait
besoin que de bien voir leur contour.

C'est pour ça que je penche plutôt vers une contour vert continu
semi-transparent, mais assez épais pour qu'ont le voit, pas trop pour ne
pas remplir toute la zone, et utilisant un effet d'ombrage.

Même les petits points du texturage actuel sont de trop (mais s'il ne
restait qu'eux ça passerait peut-être). A mon avis les frontières suffisent.

Le libellé ajouté au milieu de la zone devra être aussi en vert de la même
couleur que la bordure, il remplacera totalement les "NR" de la texture
actuelle.

Attention aussi aux libellés qui apparaissent et disparaissent de façon
aléatoire (exemple aux îles Glénan, sud du Finistère, pour une toute petite
réserve naturelle au milieu d'une petite île, dont le long libellé apparait
à un niveau de zoom et disparait ensuite, mais recouvre en fain de compte
tout l'archipel et même au delà, nous privant du nom de l'archipel lui-même
ou des îles principales). Le nom de la réserve n'apparait plus ensuite du
tout quand on a zoomé sur la bonne île, bref on ne sait pas où est
réellement cette réserve biologique (créée pour protéger une plante).




Le 7 juin 2013 16:51, JB  a écrit :

> **
>
> Mouaif, je vais encore faire mon rabat-joie, en fin de discussion, en plus…
>
> Pour moi, RN en vert n'évoque pas grand chose, à part pour me dire que ça
> doit pas être une route nationale.
>
> Et avec ça, j'ai pas grand chose à proposer, en plus. Voilà comment c'est
> géré dans R25… faute de mieux… Pour de la carte web, je pense que
> j'essayerais plutôt un hachurage diagonal vert.
>
> JB.
>
> Le 07.06.2013 16:34, Philippe Verdy a écrit :
>
> OK la disposition en triangles plutôt qu'en carré convient bien. c'est
> assez léger et ne cache plus trop de détails. On voit encore assez de "RN"
> pour savoir où on est.
>
>
> Le 7 juin 2013 16:09, Christian Quest  a écrit :
>
>> Le 7 juin 2013 12:52, Philippe Verdy  a écrit :
>> > === 1. maillage pour les "RN" ===
>> >
>> > Avec une disposition à mailles carrées orientées à 30 ou 60 degrés on a
>> > encore des textures régulières disposables en pavés rectangulaires.
>> c'est
>> > souvent un angle pratique pour éviter cet aspect trop mécanique.
>> >
>>
>> Par exemple comme ça ?
>>
>> http://cl.ly/image/2s000O3W3Z0B
>>
>> RN au lien de NR, plus espacé et en quinconce, pourtour plus épais et
>> en pointillé...
>>
>> C'est quand même plus "light" que
>>
>> http://tile.openstreetmap.fr/?zoom=13&lat=47.2844&lon=-2.4595&layers=B0F
>>
>> --
>> Christian Quest - OpenStreetMap France
>> Un nouveau serveur pour OSM... http://donate.osm.org/server2013/
>>
>
> ___
> Talk-fr mailing 
> listTalk-fr@openstreetmap.orghttp://lists.openstreetmap.org/listinfo/talk-fr
>
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] rendu osm-fr et réserves naturelles

[Philippe Verdy]

Une texture pour le trait ? Les textures n'ont pas d'orientation, ou plutôt
cette orientation est figée.
Tracer deux ou trois traits semi-transparents superposés de taille
croissante vers l'intérieur du polygone demande deux ou trois calculs de
buffers mais ça se fait déjà pour tracer les routes (même si elles ne sont
pas semi-transparentes, la couleur n'a pas d'influence sur les performances
ou la complexité du calcul.
Combien de buffers ? Tout dépend de la précision qu'on veut obtenir pour
l'effet d'ombrage (comment est fait l'ombrage blanc des libellés ?)



Le 7 juin 2013 16:57, Christian Quest  a écrit :

> Le problème c'est dans quelle couche traiter la frontière.
> Elle risque d'être masquée par pas mal de routes, d'où na nécessité de
> la texture des "RN".
>
> Un double trait (épais puis fin) ne pose pas de problème de perf de
> calcul si il s'appuie sur le polygone d'origine de la réserver.
> Pour un effet dégradé vers l'intérieur, ça doit être possible en
> utilisant une texture pour le trait... à tester.
>
> Par contre, ce qui manque c'est le nom de la réserve...
>
> Le 7 juin 2013 16:45, Philippe Verdy  a écrit :
> > Réflexion faite je pense que les pointillés ici sont de trop et qu'on
> > verrais bien malgré tout une ligne verte épaisse de bordure, même si elle
> > est semi-transparente. On peut le rendre assez discrète en rendant le
> bord
> > avec une ligne fine moins transparente, en la traçant par dessus une
> autre
> > ligne plus épaisse également semi-transparente (pour créer un effet
> d'ombre
> > verte qui s'atténue vers le centre de la zone, mais est plus contrasté
> sur
> > le bord le plus externe).
> >
> > Ceci permettrait même alors d'éviter de remplir la zone avec une texture
> > quelconque (donc suppression même du "RN") grâce à ce pourtour ombré
> épais
> > mais atténué progressivement vers l'intérieur. tout dépend alors de la
> > complexité du calcul des buffers multiples (problème de performance à
> voir
> > selon le nombre de polygones à créer pour les lignes vertes épaisses de
> > contour et de transparence croissante vers l'intérieur)
> >
> >
> >
> > 2013/6/7 Yves Pratter 
> >>
> >> > Par exemple comme ça ?
> >> > http://cl.ly/image/2s000O3W3Z0B
> >> Ah oui, c'est effectivement plus sobre :-)
> >> ___
> >> Talk-fr mailing list
> >> Talk-fr@openstreetmap.org
> >> http://lists.openstreetmap.org/listinfo/talk-fr
> >
> >
> >
> > ___
> > Talk-fr mailing list
> > Talk-fr@openstreetmap.org
> > http://lists.openstreetmap.org/listinfo/talk-fr
> >
>
>
>
> --
> Christian Quest - OpenStreetMap France
> Un nouveau serveur pour OSM... http://donate.osm.org/server2013/
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] rendu osm-fr et réserves naturelles

[djo_man]

  
  
bonjour,

Je profite de ce fil pour parler du rendu proposé que l'on voit bien
dans l'exemple
il s'agit des marais salants qui sont presque toujours en zone NR
car très souvent en zone RAMSAR

Christian tu propose donc qu'à un certain niveau de zone de rendre
les salines (landuse=salt_pond) comme des natural=mud
(soit dit en passant le landuse=salt_pond est le seul landuse qui
n'a pas rendu sur mapnik)

Je trouverais plus judicieux qu'ils soient rendu comme les bassins.
finalement ce qu'ils sont.
comme là: 
http://tile.openstreetmap.fr/?zoom=14&lat=47.39542&lon=-2.48194&layers=B0

En ce qui concerne le calage à 60° des RN : super, mais il est bien
difficile de diserner le périmètre maintenant qu'ils sont moins
nombreux
le rendu 2u propose une surface legerement verte au zoom 14 sur
l'ensemble du périmètre de la réserve. c'est plus parlant pour
comprendre tout de suite que
nous sommes dans la reserve mais gacherait à de plus fort zoom les
couleurs des landuses

oserais-je demander un degradé de vert à transparent sur le
périmètre sur une épaisseur de 100m environ ?

djoman
(le fou qui a recopié les marais salants depuis bing)


  


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

[OSM-talk-fr] Oups : rendu des bunkers

[Yves Pratter]

Bonsoir,

J'ai utilisé les tags military=bunker et bunker_type=pillbox à la place de 
building = yes pour un bunker.
Mais celui-ci disparait  !!

Je vois après coup que bunker_type=pillbox ne serait valable que pour la 
meurtrière et pas l'ensemble du bunker, ce qui ne colle pas avec la doc de 
military=bunker 

Comment faut-il cartographier ça ?

Merci,


http://www.openstreetmap.org/browse/way/185422534
http://www.openstreetmap.org/?lat=47.034969&lon=6.565509&zoom=18&layers=M

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

Re: [OSM-talk-fr] Comment tagguer un centre d'accueil de Sécurité Sociale

[Olivier Delaune]

Justement dans cette liste, je ne trouve aps de mention de centre de sécurité 
sociale (accueil CPAM par exemple) ni de centre d'accueil CAF. Ai-je mal 
regardé ?

Le vendredi 7 juin 2013 15:28:00 Ab_fab  a écrit :> 
> Attends Frédéric,
> 
> Ta liste est pas finie :
> http://wiki.openstreetmap.org/wiki/FR:Key:social_facility
> 
> Et puis quelques perceptions pour financer tout ça :-)
> amenity=public_building + office=tax + operator=DGFiP
> 
> Le 7 juin 2013 14:20, Frédéric Rodrigo  a écrit :
> > Le 07/06/2013 14:05, olivier delaune a écrit :
> >  Bonjour, question en passant après avoir lu la prose de Verdy_p
> >  
> >> Comment taggue-t'on correctement les centres de sécurité sociale ? Pour
> >> les CCAS, j'ai cru comprendre qu'un amenity=social_centre fonctionne
> >> plutôt bien mais vu que c'est assez différent d'un centre de sécu,
> >> j'imagine qu'on doit utiliser un tag différent. La question est
> >> également valable pour les autres centres mentionnés par Verdy (caisse
> >> d'allocations familliales, Pole Emploi, ...)
> >> 
> >> Merci d'avance
> >> 
> >> Olivier
> >> 
> >>  > Un projet serait plutôt de réviser les listes d'objets à intégrer
> >> 
> >> déjà
> >> 
> >>  > signalés par Osmose, en se répartissant les régions à faire, pour
> >> 
> >> tous les
> >> 
> >>  > POIs importants de repérage (gares, églises et lieux de culte,
> >> 
> >> châteaux
> >> 
> >>  > d'eau, émetteurs télécom/TV, musées, poste, police / gendarmerie,
> >> 
> >> offices
> >> 
> >>  > de tourisme, parkings fermés très souvent fléchés en ville,
> >> 
> >> services
> >> 
> >>  > sociaux comme les CCAS ou accueils de la sécu ou des alloc
> >> 
> >> familiales,
> >> 
> >>  > centres Pôle Emploi, stations de péage)
> > 
> > Au passage il y a aussi une nouvelle analyse Osmose pour ça :
> > 
> > http://osmose.openstreetmap.**fr/fr/map/?item=8110<http://osmose.openstree
> > tmap.fr/fr/map/?item=8110>
> > 
> > Le mapping de tag utilisé :
> > 1, "mairie", {"amenity": "townhall"}, {"amenity": "townhall"})
> > 2, "gendarmerie", {"amenity": "police"}, {"amenity": "police",
> > "police:FR": "gendarmerie"})
> > 3, "commissariat_police", {"amenity": "police"}, {"amenity": "police",
> > "police:FR": "police"})
> > 4, "epic", {"office": "administrative"}, {"office": "administrative"})
> > 5, "pole_emploi", {"office": "employment_agency"}, {"office":
> > "employment_agency"})
> > 6, ["ta", "ti", "tribunal_commerce", "tgi", "te", "cour_appel"],
> > {"amenity": "courthouse"}, {"amenity": "courthouse"})
> > 7, ["maison_centrale", "maison_arret", "centre_penitentiaire",
> > "centre_detention", "csl"], {"amenity": "prison"}, {"amenity": "prison"})
> > 8, ["prefecture", "sous_pref"], {"office": "government"}, {"office":
> > "government"})
> > 9, ["cg", "cr"], {"office": "administrative"}, {"office":
> > "administrative"})
> > 
> > Ça viens de Service-Public.fr
> > 
> > Frédéric.
> > --
> > Vous en avez rêvé, Osmose la fait.
> > 
> > 
> > __**_
> > Talk-fr mailing list
> > Talk-fr@openstreetmap.org
> > http://lists.openstreetmap.**org/listinfo/talk-fr<http://lists.openstreetm
> > ap.org/listinfo/talk-fr>
> > 
> > 
> > 
> > 
> > Bonjour, question en passant après avoir lu la prose de Verdy_p
> > 
> > 
> > 
> > Comment taggue-t'on correctement les centres de sécurité sociale ? Pour
> > les CCAS, j'ai cru comprendre qu'un amenity=social_centre fonctionne
> > plutôt
> > bien mais vu que c'est assez différent d'un centre de sécu, j'imagine
> > qu'on
&g

Re: [OSM-talk-fr] Comment tagguer un centre d'accueil de Sécurité Sociale

[Frédéric Rodrigo]

Ces informations sont en plus disponible dans Service-public.fr. Mais je 
ne les ai pas proposé à l'intégration... justement car je ne sais 
vraiment pas quel tags utiliser.


La liste de ce qui est disponible :

http://www.service-public.fr/info/docs/liste-type-organisme.pdf

Frédéric.

Le 08/06/2013 17:48, Olivier Delaune a écrit :

Justement dans cette liste, je ne trouve aps de mention de centre de sécurité
sociale (accueil CPAM par exemple) ni de centre d'accueil CAF. Ai-je mal
regardé ?

Le vendredi 7 juin 2013 15:28:00 Ab_fab  a écrit :>

Attends Frédéric,

Ta liste est pas finie :
http://wiki.openstreetmap.org/wiki/FR:Key:social_facility

Et puis quelques perceptions pour financer tout ça :-)
amenity=public_building + office=tax + operator=DGFiP

Le 7 juin 2013 14:20, Frédéric Rodrigo  a écrit :

Le 07/06/2013 14:05, olivier delaune a écrit :
  Bonjour, question en passant après avoir lu la prose de Verdy_p


Comment taggue-t'on correctement les centres de sécurité sociale ? Pour
les CCAS, j'ai cru comprendre qu'un amenity=social_centre fonctionne
plutôt bien mais vu que c'est assez différent d'un centre de sécu,
j'imagine qu'on doit utiliser un tag différent. La question est
également valable pour les autres centres mentionnés par Verdy (caisse
d'allocations familliales, Pole Emploi, ...)

Merci d'avance

Olivier

  > Un projet serait plutôt de réviser les listes d'objets à intégrer

 déjà

  > signalés par Osmose, en se répartissant les régions à faire, pour

 tous les

  > POIs importants de repérage (gares, églises et lieux de culte,

 châteaux

  > d'eau, émetteurs télécom/TV, musées, poste, police / gendarmerie,

 offices

  > de tourisme, parkings fermés très souvent fléchés en ville,

services

  > sociaux comme les CCAS ou accueils de la sécu ou des alloc

 familiales,

  > centres Pôle Emploi, stations de péage)


Au passage il y a aussi une nouvelle analyse Osmose pour ça :

http://osmose.openstreetmap.**fr/fr/map/?item=8110

Le mapping de tag utilisé :
1, "mairie", {"amenity": "townhall"}, {"amenity": "townhall"})
2, "gendarmerie", {"amenity": "police"}, {"amenity": "police",
"police:FR": "gendarmerie"})
3, "commissariat_police", {"amenity": "police"}, {"amenity": "police",
"police:FR": "police"})
4, "epic", {"office": "administrative"}, {"office": "administrative"})
5, "pole_emploi", {"office": "employment_agency"}, {"office":
"employment_agency"})
6, ["ta", "ti", "tribunal_commerce", "tgi", "te", "cour_appel"],
{"amenity": "courthouse"}, {"amenity": "courthouse"})
7, ["maison_centrale", "maison_arret", "centre_penitentiaire",
"centre_detention", "csl"], {"amenity": "prison"}, {"amenity": "prison"})
8, ["prefecture", "sous_pref"], {"office": "government"}, {"office":
"government"})
9, ["cg", "cr"], {"office": "administrative"}, {"office":
"administrative"})



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

Re: [OSM-talk-fr] Proposition de projet du mois (gares SNCF)

[Frédéric Rodrigo]

Le 07/06/2013 14:49, Yves Pratter a écrit :


Le 7 juin 2013 à 14:04, Frédéric Rodrigo mailto:fred.rodr...@gmail.com>> a écrit :


Les donnés viennent de là :
http://www.data.gouv.fr/donnees/view/Liste-des-gares-de-voyageurs-du-RFN-avec-coordonn%C3%A9es-30383099


Je n'ai pas vu de code UIC là-dedans.

Par contre ils se trouvent ici (pour les gares voyageurs en France) :
DRR_2014_-_Annexe_7_3_liste_des_gares_voy.pdf



Ok, mais c'est utilisable ? Question de licence.

Je peux aussi modifier l'analyse osmose pour ne pas tenir compte de ref.

Frédéric.


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

Re: [OSM-talk-fr] rendu osm-fr et réserves naturelles

[Philippe Verdy]

Pourquoi 100 mètres ? Ce sera pas assez aux niveaux de zoom faibles, et
trop aux niveaux de zoom fort. A mon avis un rendu en bordure épaisse de
taille fixe (en pixels rendus) sera bien meilleur. Cette bordure ne cachera
partiellement des détails internes que pour les faibles niveaux de zoom où
de toute façon on ne voit pas grand chose de l'intérieur.

Une bordure épaisse verte dégradée 5-10 pixels suffira (cette bordure
devrait être semi-transparente partout, de 75% environ sur le bord (sauf le
plus fin liseré externe à 100%, d'un demi-pixel de large et qui pourrait
utiliser un vert plus sombre, le même que pour le libellé central) à 0% à
l'intérieur


Le 7 juin 2013 17:12, djo_man  a écrit :

>  bonjour,
>
> Je profite de ce fil pour parler du rendu proposé que l'on voit bien dans
> l'exemple
> il s'agit des marais salants qui sont presque toujours en zone NR car très
> souvent en zone RAMSAR
>
> Christian tu propose donc qu'à un certain niveau de zone de rendre les
> salines (landuse=salt_pond) comme des natural=mud
> (soit dit en passant le landuse=salt_pond est le seul landuse qui n'a pas
> rendu sur mapnik)
>
> Je trouverais plus judicieux qu'ils soient rendu comme les bassins.
> finalement ce qu'ils sont.
> comme là:
>
> http://tile.openstreetmap.fr/?zoom=14&lat=47.39542&lon=-2.48194&layers=B0
>
> En ce qui concerne le calage à 60° des RN : super, mais il est bien
> difficile de diserner le périmètre maintenant qu'ils sont moins nombreux
> le rendu 2u propose une surface legerement verte au zoom 14 sur l'ensemble
> du périmètre de la réserve. c'est plus parlant pour comprendre tout de
> suite que
> nous sommes dans la reserve mais gacherait à de plus fort zoom les
> couleurs des landuses
>
> oserais-je demander un degradé de vert à transparent sur le périmètre sur
> une épaisseur de 100m environ ?
>
> djoman
> (le fou qui a recopié les marais salants depuis bing)
>
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Proposition de projet du mois (gares SNCF)

[Christian Quest]

Les données de data.gouv.fr d'origine RFF ne sont pas bien bonnes.

Je suis reparti des données du GTFS de la SNCF TER pour celles que
j'ai intégré sur le quart nord-est.

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

Re: [OSM-talk-fr] Proposition de projet du mois (gares SNCF)

[Christian Quest]

Oublié le lien... http://test.data-sncf.com/index.php/ter.html

Celles d'Intercité sont en principe déjà toutes intégrées.

Et il y a aussi ça maintenant:
http://test.data-sncf.com/index.php/gares-connexions.html


Les uic_ref commencent par 87 pour la SNCF... attention, il y a
quelques gares hors de l'hexagone.

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

Re: [OSM-talk-fr] rendu osm-fr et réserves naturelles

[Christian Quest]

Le 7 juin 2013 17:06, Philippe Verdy  a écrit :
> Une texture pour le trait ? Les textures n'ont pas d'orientation, ou plutôt
> cette orientation est figée.

C'est comme ça que sont tracés les falaises.

Exemple: https://github.com/mapnik/mapnik/wiki/LinePatternSymbolizer

> Tracer deux ou trois traits semi-transparents superposés de taille
> croissante vers l'intérieur du polygone demande deux ou trois calculs de
> buffers mais ça se fait déjà pour tracer les routes (même si elles ne sont
> pas semi-transparentes, la couleur n'a pas d'influence sur les performances
> ou la complexité du calcul.

Et bien non... les routes ne sont pas tracées comme ça.
On a un premier trait épais, puis un second un peu plus fin... et
magie... ça fait une fine bordure.

> Combien de buffers ? Tout dépend de la précision qu'on veut obtenir pour
> l'effet d'ombrage (comment est fait l'ombrage blanc des libellés ?)
>

Les calculs de buffers sont long. J'en utilise un pour décaler les
noms sur les limites administratives, et c'est pas neutre du tout.

-- 
Christian Quest - OpenStreetMap France
Un nouveau serveur pour OSM... http://donate.osm.org/server2013/

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

Re: [OSM-talk-fr] Rendu des (grandes) gares Re: Proposition de projet du mois (gares SNCF)

[Philippe Verdy]

Déjà les quais ne devraient pas s'afficher "Voies X-Y" mais "Quai X-Y". Le
train entre en gare "Voie X" mais pas sur un quai, et on ne circule pas
prendre son train sur une voie mais sur un quai même s'il porte des numéros
similaires (le numéro de voie indique seulement le côté du quai, au cas où
les deux côtés ont des trains en gare pour ne pas se tromper de train, et
il y a des panneaux distinctifs de chaque côté du quai)...
Mais dans bien des gares les quais indiquent plutôt les numéros de voies
que les numéros de quais (cela facilite les annonces vocales et affichages
de trains au départ).
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] rendu osm-fr et réserves naturelles

[Philippe Verdy]

Ah oui ? Comment crois-tu qu'on trace des traits épais ? Ou même n'importe
quel trait d'ailleurs.

Le logiciel calcule des "buffers" puis les remplit. Même si cela ne se fait
pas dans la requête SQL (qui elle calcule des buffers en taille
géolocalisée et non dans la taille du rendu final ; la différence c'est le
système de coordonnées : le SQL travaille dans le système géographique,
alors que le rendu des lignes travaille dans le système après projection).

C'est nécessaire de faire comme ça pour obtenir des tracés lissés (cela
nécessite de calculuer non pas des positions de pixel mais des taux de
couverture des pixels carrés par la surface limitée par le buffer interne ;
d'nacienne méthodes utilisait un rendu suréchantillonné mais c'était trop
coûteux en mémoire, pas assez précis pour avoir plus de 4 niveaux de
transparence pour l'anticrénelage, et c'est plus efficace ce calculer des
taux de couverture pour en déduire un niveau de transparence à appliquer
pour le rendu de la couleur effective des pixels qui dès lors peut avoir un
lissage bien meilleur jusqu'à 256 niveaux ; visuellement le rendu est bien
meilleur sans nécessiter aucun suréchantillonnage, et en calculant
directement chaque pixel une seule fois).



Le 7 juin 2013 18:15, Christian Quest  a écrit :

> Le 7 juin 2013 17:06, Philippe Verdy  a écrit :
> > Une texture pour le trait ? Les textures n'ont pas d'orientation, ou
> plutôt
> > cette orientation est figée.
>
> C'est comme ça que sont tracés les falaises.
>
> Exemple: https://github.com/mapnik/mapnik/wiki/LinePatternSymbolizer
>
> > Tracer deux ou trois traits semi-transparents superposés de taille
> > croissante vers l'intérieur du polygone demande deux ou trois calculs de
> > buffers mais ça se fait déjà pour tracer les routes (même si elles ne
> sont
> > pas semi-transparentes, la couleur n'a pas d'influence sur les
> performances
> > ou la complexité du calcul.
>
> Et bien non... les routes ne sont pas tracées comme ça.
> On a un premier trait épais, puis un second un peu plus fin... et
> magie... ça fait une fine bordure.
>
> > Combien de buffers ? Tout dépend de la précision qu'on veut obtenir pour
> > l'effet d'ombrage (comment est fait l'ombrage blanc des libellés ?)
> >
>
> Les calculs de buffers sont long. J'en utilise un pour décaler les
> noms sur les limites administratives, et c'est pas neutre du tout.
>
> --
> Christian Quest - OpenStreetMap France
> Un nouveau serveur pour OSM... http://donate.osm.org/server2013/
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Oups : rendu des bunkers

[Pierre Knobel]

Bonsoir,

J'en ai ajouté quelques-uns avec les mêmes tags que toi, plus un tag
historic=ruins (les miens datent de la seconde guerre mondiale), et
effectivement ils n'apparaissent pas sur le rendu standard. Par contre ils
apparaissent bien sur la carte de mon GPS
Garmin.

Au fait, qu'est-ce que vous utiliseriez comme tag pour préciser
l'appartenance du bunker à la ligne Maginot ? Pour l'instant je me contente
de name="Bunker de la ligne Maginot".

2013/6/7 Yves Pratter 

> Bonsoir,
>
> J'ai utilisé les tags 
> military=bunker
>  et *bunker_type=pillbox* à la place de *building = yes* pour un bunker.
> Mais celui-ci disparait  !!
>
> Je vois après coup que 
> bunker_type=pillbox
> * *ne serait valable que pour la meurtrière et pas l'ensemble du bunker,
> ce qui ne colle pas avec la doc de 
> military=bunker
>
>
> Comment faut-il cartographier ça ?
>
> Merci,
>
>
> http://www.openstreetmap.org/browse/way/185422534
> http://www.openstreetmap.org/?lat=47.034969&lon=6.565509&zoom=18&layers=M
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] rendu osm-fr et réserves naturelles

[Christian Quest]

Ca avance, avec un line-pattern: http://cl.ly/image/34341i2r2J0z

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

Re: [OSM-talk-fr] rendu osm-fr et réserves naturelles

[Philippe Verdy]

A ce sujet une lecture instructive!
http://perso.telecom-paristech.fr/~concolat/SuperPathSVGOpen.pdf

(concerne autant la modélisation géographique que le rendu final en SVG
après projection).

On trouve tout un tas de techniques explosées sur la façon d'accélerer le
rendu vectoriel des lignes et polygones. En gros aujourd'hui on ne trace
plus les lignes avec les vieux algorithmes de Bresenham simples (on ne veut
plus des effets de crénelage) mais on remplit des surfaces polygonales, en
convertissant tout trait en polygone à remplir.

Les algos d erendus actuels sont pris en charge par le matériel de toute
carte graphique actuelle et sont une extension de Bresenham où on ne
calcule plus seulement les positions mais aussi les de façon incrémentale
la couverture de chaque pixel, d'après la géométrie du polygone (deux
traits de réference et non plus un seul). Seuls les rendus logiciels
utilisent encore le superéchantillonnage simple (de type FSAA 2x2, qui peut
utiliser le Bresenham simple à un trait, mais ça coûte cher en mémoire sans
donner un résultat formidable visuellement).

Tous les moteurs SVG savent utiliser le rendu matériel.



Le 7 juin 2013 18:26, Philippe Verdy  a écrit :

> Ah oui ? Comment crois-tu qu'on trace des traits épais ? Ou même n'importe
> quel trait d'ailleurs.
>
> Le logiciel calcule des "buffers" puis les remplit. Même si cela ne se
> fait pas dans la requête SQL (qui elle calcule des buffers en taille
> géolocalisée et non dans la taille du rendu final ; la différence c'est le
> système de coordonnées : le SQL travaille dans le système géographique,
> alors que le rendu des lignes travaille dans le système après projection).
>
> C'est nécessaire de faire comme ça pour obtenir des tracés lissés (cela
> nécessite de calculuer non pas des positions de pixel mais des taux de
> couverture des pixels carrés par la surface limitée par le buffer interne ;
> d'nacienne méthodes utilisait un rendu suréchantillonné mais c'était trop
> coûteux en mémoire, pas assez précis pour avoir plus de 4 niveaux de
> transparence pour l'anticrénelage, et c'est plus efficace ce calculer des
> taux de couverture pour en déduire un niveau de transparence à appliquer
> pour le rendu de la couleur effective des pixels qui dès lors peut avoir un
> lissage bien meilleur jusqu'à 256 niveaux ; visuellement le rendu est bien
> meilleur sans nécessiter aucun suréchantillonnage, et en calculant
> directement chaque pixel une seule fois).
>
>
>
> Le 7 juin 2013 18:15, Christian Quest  a écrit :
>
> Le 7 juin 2013 17:06, Philippe Verdy  a écrit :
>> > Une texture pour le trait ? Les textures n'ont pas d'orientation, ou
>> plutôt
>> > cette orientation est figée.
>>
>> C'est comme ça que sont tracés les falaises.
>>
>> Exemple: https://github.com/mapnik/mapnik/wiki/LinePatternSymbolizer
>>
>> > Tracer deux ou trois traits semi-transparents superposés de taille
>> > croissante vers l'intérieur du polygone demande deux ou trois calculs de
>> > buffers mais ça se fait déjà pour tracer les routes (même si elles ne
>> sont
>> > pas semi-transparentes, la couleur n'a pas d'influence sur les
>> performances
>> > ou la complexité du calcul.
>>
>> Et bien non... les routes ne sont pas tracées comme ça.
>> On a un premier trait épais, puis un second un peu plus fin... et
>> magie... ça fait une fine bordure.
>>
>> > Combien de buffers ? Tout dépend de la précision qu'on veut obtenir pour
>> > l'effet d'ombrage (comment est fait l'ombrage blanc des libellés ?)
>> >
>>
>> Les calculs de buffers sont long. J'en utilise un pour décaler les
>> noms sur les limites administratives, et c'est pas neutre du tout.
>>
>> --
>> Christian Quest - OpenStreetMap France
>> Un nouveau serveur pour OSM... http://donate.osm.org/server2013/
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/talk-fr
>>
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Rendu des (grandes) gares Re: Proposition de projet du mois (gares SNCF)

[Christian Quest]

Le 7 juin 2013 18:16, Philippe Verdy  a écrit :
> Déjà les quais ne devraient pas s'afficher "Voies X-Y" mais "Quai X-Y". Le
> train entre en gare "Voie X" mais pas sur un quai, et on ne circule pas
> prendre son train sur une voie mais sur un quai même s'il porte des numéros
> similaires (le numéro de voie indique seulement le côté du quai, au cas où
> les deux côtés ont des trains en gare pour ne pas se tromper de train, et il
> y a des panneaux distinctifs de chaque côté du quai)...
> Mais dans bien des gares les quais indiquent plutôt les numéros de voies que
> les numéros de quais (cela facilite les annonces vocales et affichages de
> trains au départ).
>

Oui, un quai est un quai, et une voie une voie, mais la douce voix
féminine de la SNCF dit "train machin chouette voie X" et pas "quai
X".
Si mes souvenirs ferroviaires récents sont bons la signalétique
indique aussi "Voie / Voies"...

Je serait tenté d'utiliser des ref=* plutôt que des name=* car "Quai
X" ou" Voie X" n'est pas un nom, mais une description ;)

-- 
Christian Quest - OpenStreetMap France
Un nouveau serveur pour OSM... http://donate.osm.org/server2013/

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

Re: [OSM-talk-fr] Rendu des (grandes) gares Re: Proposition de projet du mois (gares SNCF)

[Philippe Verdy]

A mon avis nommer les quais n'est pas utile, en France on annonce les voies
des trains. Dans les gares les numéros de quais disparaissent en affichant
directement les numéros des voies (le même panneau affiche "Voie 2" et
juste à coté "Voie 3" plutôt même que "Voies 2-3").
Anciennement c'était les quais qui étaient numérotés, et il fallait
préciser le côté pour avoir la voie (Voie 2A d'un côté, Voir 2B de l'autre
sur le quai numéro 2)... Combien de voyageurs se sont trompés de train !




Le 7 juin 2013 18:43, Christian Quest  a écrit :

> Le 7 juin 2013 18:16, Philippe Verdy  a écrit :
> > Déjà les quais ne devraient pas s'afficher "Voies X-Y" mais "Quai X-Y".
> Le
> > train entre en gare "Voie X" mais pas sur un quai, et on ne circule pas
> > prendre son train sur une voie mais sur un quai même s'il porte des
> numéros
> > similaires (le numéro de voie indique seulement le côté du quai, au cas
> où
> > les deux côtés ont des trains en gare pour ne pas se tromper de train,
> et il
> > y a des panneaux distinctifs de chaque côté du quai)...
> > Mais dans bien des gares les quais indiquent plutôt les numéros de voies
> que
> > les numéros de quais (cela facilite les annonces vocales et affichages de
> > trains au départ).
> >
>
> Oui, un quai est un quai, et une voie une voie, mais la douce voix
> féminine de la SNCF dit "train machin chouette voie X" et pas "quai
> X".
> Si mes souvenirs ferroviaires récents sont bons la signalétique
> indique aussi "Voie / Voies"...
>
> Je serait tenté d'utiliser des ref=* plutôt que des name=* car "Quai
> X" ou" Voie X" n'est pas un nom, mais une description ;)
>
> --
> Christian Quest - OpenStreetMap France
> Un nouveau serveur pour OSM... http://donate.osm.org/server2013/
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] rendu osm-fr et réserves naturelles

[Christian Quest]

Le 7 juin 2013 18:40, Philippe Verdy  a écrit :
> Tous les moteurs SVG savent utiliser le rendu matériel.
>

Vu qu'on a une carte graphique de folie sur osm13 (vous imaginez...
"Integrated Matrox® G200, 8MB shared video memory") j'ai un très gros
doute sur le rendu matériel qui y serait fait...

Je poserai la question à Jean-Claude à l'occasion (et oui, je le connais).

-- 
Christian Quest - OpenStreetMap France
Un nouveau serveur pour OSM... http://donate.osm.org/server2013/

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

Re: [OSM-talk-fr] rendu osm-fr et réserves naturelles

[Philippe Verdy]

C'est quoi le moteur graphique ? Qt ? Même une carte graphique modeste
dispose d'une accélération pour le remplissage de polygones, même si'l n'y
a pas de nombreux "cores" parallèles.

Maintenant il faut voir ce qui est dessus, si la carte ne prend en charge
que le rendu FSAA, c'est du Bresenham simple et non du remplissage par
suivi de listes triées de bordures, mais Qt fournit un support pour ce tri
qui permet ensuite le remplissage matériel sans avoir à dessiner les pixels
de contour un par un par logiciel pour autant.
Les dernières cartes qui n'avaient pas ce support de suivi de contours
datent de 2006, il n'y en a plus aucune sur le marché qui ne sache pas au
moins remplir un triangle avec rendu antialias des pixels de bordure en
utilisant une colorimétrie interne RGBA (où les 4 composantes sont
multipliées par un facteur alpha correspondant au tau de couverture d'un
pixel, et où les coordonnées de pixels sont remplacées par des coordonnées
de sous-pixels  avec au moins 3 bits pour les fractions horizontales et
verticales).

Maintenant sur les serveurs aussi on a des cartes graphiques multicoeurs,
car ces cartes sont aussi des instruments de calcul utilisables pour plein
de choses et pas que le graphisme, avec d'importantes possibilités de
programmation parallèle. Des moteurs de bases de donnes les utilisent pour
le tri par exemple, des noyaux système peuvent les utiliser pour
l'ordonnancement des tâches et événements, ou la gestion de la mémoire et
des files I/O.
Le parallélisme devient une réalité qui se glisse même depuis plusieurs
années dans les CPU standards avec des instructions nouvelles. Et de plus
en plus on utilise les cartes graphiques pour autre chose que le seul
graphisme, ces cartes sont multiusage en traitement du signal, compression
de données, etc. Le tout est servi par des pilotes sui se branchent sur des
bibliothèques standards et one ne se rend même plus compte que la carte
graphie accélérée est utilisée par des API de base.




Le 7 juin 2013 18:53, Christian Quest  a écrit :

> Le 7 juin 2013 18:40, Philippe Verdy  a écrit :
> > Tous les moteurs SVG savent utiliser le rendu matériel.
> >
>
> Vu qu'on a une carte graphique de folie sur osm13 (vous imaginez...
> "Integrated Matrox® G200, 8MB shared video memory") j'ai un très gros
> doute sur le rendu matériel qui y serait fait...
>
> Je poserai la question à Jean-Claude à l'occasion (et oui, je le connais).
>
> --
> Christian Quest - OpenStreetMap France
> Un nouveau serveur pour OSM... http://donate.osm.org/server2013/
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] rendu osm-fr et réserves naturelles

[Philippe Verdy]

Une description de cette G200:
http://www.hardware.fr/articles/35-1/matrox-millenium-g200.html

Bref il y avait déjà un rendu 3D matériel, et le remplissage de triangles
au moins.


Le 7 juin 2013 18:53, Christian Quest  a écrit :

> Le 7 juin 2013 18:40, Philippe Verdy  a écrit :
> > Tous les moteurs SVG savent utiliser le rendu matériel.
> >
>
> Vu qu'on a une carte graphique de folie sur osm13 (vous imaginez...
> "Integrated Matrox® G200, 8MB shared video memory") j'ai un très gros
> doute sur le rendu matériel qui y serait fait...
>
> Je poserai la question à Jean-Claude à l'occasion (et oui, je le connais).
>
> --
> Christian Quest - OpenStreetMap France
> Un nouveau serveur pour OSM... http://donate.osm.org/server2013/
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Comment tagguer un centre d'accueil de Sécurité Sociale (était Proposition de projet du mois (gares SNCF))

[Pieren]

2013/6/7 Frédéric Rodrigo :

> 2, "gendarmerie", {"amenity": "police"}, {"amenity": "police", "police:FR":
> "gendarmerie"})

"police:FR=gendarmerie" ? ça a été discuté et approuvé quelque part ?
documenté dans le wiki ?

De plus, je tombe sur un exemple: "name=Brigade de proximité de
gendarmerie d'Haroué". Pourquoi pas mettre ça dans "official_name" et
laisser simplement "name=Gendarmerie Nationale". Si je devais chercher
une gendarmerie dans l'annuaire téléphonique, j'irais voir sous la
lettre 'G', pas sous la lettre 'B', naif que je suis.

Pieren

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

Re: [OSM-talk-fr] Comment tagguer un centre d'accueil de Sécurité Sociale (était Proposition de projet du mois (gares SNCF))

[Philippe Verdy]

La gendarmerie reste un service de police, même si elle est militaire.
Différents services de police, avec des personnels civils ou militaires,
existent dans le monde, mais le terme générique en anglais reste "police".

Maintenant on peut vouloir effectivement classer les types de service de
police selon les pays, mais à mon avis ce n'est pas une clé "police:FR=*"
qu'il faut mais "police:type=*" dont la valeur pourrait alors être
dépendante du pays : "FR:municipale", "FR:commissariat" (police nationale),
"FR:gendarmerie", "FR:DST", "GB:horseguard", "US:sheriff", "US:FBI",
"US:MP", etc.



Le 7 juin 2013 19:45, Pieren  a écrit :

> 2013/6/7 Frédéric Rodrigo :
>
> > 2, "gendarmerie", {"amenity": "police"}, {"amenity": "police",
> "police:FR":
> > "gendarmerie"})
>
> "police:FR=gendarmerie" ? ça a été discuté et approuvé quelque part ?
> documenté dans le wiki ?
>
> De plus, je tombe sur un exemple: "name=Brigade de proximité de
> gendarmerie d'Haroué". Pourquoi pas mettre ça dans "official_name" et
> laisser simplement "name=Gendarmerie Nationale". Si je devais chercher
> une gendarmerie dans l'annuaire téléphonique, j'irais voir sous la
> lettre 'G', pas sous la lettre 'B', naif que je suis.
>
> Pieren
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Proposition de projet du mois (gares SNCF)

[Christophe Merlet]

Le 07/06/2013 14:49, Yves Pratter a écrit :


Le 7 juin 2013 à 14:04, Frédéric Rodrigo mailto:fred.rodr...@gmail.com>> a écrit :


Les donnés viennent de là :
http://www.data.gouv.fr/donnees/view/Liste-des-gares-de-voyageurs-du-RFN-avec-coordonn%C3%A9es-30383099


Je n'ai pas vu de code UIC là-dedans.

Par contre ils se trouvent ici (pour les gares voyageurs en France) :
DRR_2014_-_Annexe_7_3_liste_des_gares_voy.pdf



Ce document est pas mal...

Je l'ai comparé avec cet autre document :
http://test.data-sncf.com/index.php/gares-connexions.html

Les UIC correspondent pour le 64, par contre il y a quelques différences 
mineures dans le nom des gares...


Je propose aussi de remplacer les balises uic_ref par des ref:UIC ça me 
parait plus cohérent avec les autres balises ref... Il y en a 4615 dans 
la base pour 3410 valeurs distincts.

http://taginfo.openstreetmap.fr/keys/uic_ref


Librement,
--
Christophe Merlet (RedFox)

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

Re: [OSM-talk-fr] Rendu des (grandes) gares Re: Proposition de projet du mois (gares SNCF)

[Eric SIBERT]

Le 07/06/2013 18:04, Christian Quest a écrit :

Ces voies sont très visibles car elles n'ont aucun tag service=* qui
permettrait d'indiquer qu'elles ne sont pas principales.
Données à compléter...


Franchement, à Lyon Part-Dieu, sur le terrain, j'ai du mal à distinguer 
les voies de service des voies principales.




Ca me semble par contre normal d'avoir le nom de la gare... bien que
celui-ci avec son "Gare SNCF" soit un peu à rallonge. "Lyon Part-Dieu"
devrait suffire, c'est d'ailleurs le nom de l'arrêt... "Gare SNCF"
n'étant qu'une description et pas un nom.


Surtout, quand on est sur les quais, les classiques panneaux noirs avec 
écriture blanche affichent "Lyon Part-Dieu". Par contre, sur la façade 
d'entrée : "Gare de Lyon Part-Dieu".


Eric


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

Re: [OSM-talk-fr] Comment tagguer un centre d'accueil de Sécurité Sociale (était Proposition de projet du mois (gares SNCF))

[Christian Quest]

Plutôt que de créer des clés ou valeur exotiques, on ne pourrait pas
utiliser operator=* pour faire le distinguo ?

operator=Gendarmerie
operator=Police Nationale
operator=Ville de Trifouilli

-- 
Christian Quest - OpenStreetMap France
Un nouveau serveur pour OSM... http://donate.osm.org/server2013/

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

Re: [OSM-talk-fr] Proposition de projet du mois (gares SNCF)

[Christian Quest]

uic_ref était déjà utilisé, on en trouvera donc hors de France... à ne
pas changer "comme ça" donc.

Attention avec les N° UIC, ils sont à 7 chiffres + parfois un 8ème qui
est une clé de contrôle (je n'ai pas regardé de quel type, possible
que ça soit un code de Luhn) et une même gare peut avoir plusieurs
N°UIC.


Pour les noms des gares, c'est tout un bazar... les noms d'usage et
les noms internes à RFF et/ou la SNCF sont parfois différents (pareil
avec des données RATP, rare qu'il y ait une totale cohérence dans les
différents jeux de données).

Exemple: Gare du Nord -> Paris Nord

J'ai gardé le nom d'origine SNCF dans official_name pour cette raison.
Il m'a servit sur certaines haltes à indiquer un nom qui n'était pas
présent dans OSM.

-- 
Christian Quest - OpenStreetMap France
Un nouveau serveur pour OSM... http://donate.osm.org/server2013/

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

Re: [OSM-talk-fr] Rendu des (grandes) gares Re: Proposition de projet du mois (gares SNCF)

[Christian Quest]

Le 7 juin 2013 21:38, Eric SIBERT  a écrit :
> Le 07/06/2013 18:04, Christian Quest a écrit :
>
>> Ces voies sont très visibles car elles n'ont aucun tag service=* qui
>> permettrait d'indiquer qu'elles ne sont pas principales.
>> Données à compléter...
>
>
> Franchement, à Lyon Part-Dieu, sur le terrain, j'ai du mal à distinguer les
> voies de service des voies principales.
>
>
>

Je m'en doute, je l'ai un peu pratiquée... mais en général il y a une
voie "plus principale" que les autres, celle où les trains qui ne font
que passer passent (ils doivent être rare dans cette gare là).


>> Ca me semble par contre normal d'avoir le nom de la gare... bien que
>> celui-ci avec son "Gare SNCF" soit un peu à rallonge. "Lyon Part-Dieu"
>> devrait suffire, c'est d'ailleurs le nom de l'arrêt... "Gare SNCF"
>> n'étant qu'une description et pas un nom.
>
>
> Surtout, quand on est sur les quais, les classiques panneaux noirs avec
> écriture blanche affichent "Lyon Part-Dieu". Par contre, sur la façade
> d'entrée : "Gare de Lyon Part-Dieu".
>

C'est logique, si si !

Les panneaux noirs, tu parle bien de ceux sur les quai ?
Là tu sais que tu es dans une gare... mais dehors... y'a écrit "gare"
pour être sûr que ce qui se cache derrière les murs est une gare ;)
CQFD !

-- 
Christian Quest - OpenStreetMap France
Un nouveau serveur pour OSM... http://donate.osm.org/server2013/

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

Re: [OSM-talk-fr] Comment tagguer un centre d'accueil de Sécurité Sociale (était Proposition de projet du mois (gares SNCF))

[Philippe Verdy]

Effectivement, si.

Mais on a encore le champ name=* (mais qui peut être trop précis et
mentionner le nom (assez souvent abrégé car les noms sont souvent à
rallonge) d'un service du même "operator", par exemple pour la police
nationale en France: "DCRI", "Brigade financière", "Brigade des mineurs",
"DST", "SRPJ", "GIPN", "Commissariat du XIIIe", "BAC" etc. (si les
abréviations ne plaisent pas dans "name=*", on peut encore les mettre dans
"short_name=*".


Le 7 juin 2013 22:20, Christian Quest  a écrit :

> Plutôt que de créer des clés ou valeur exotiques, on ne pourrait pas
> utiliser operator=* pour faire le distinguo ?
>
> operator=Gendarmerie
> operator=Police Nationale
> operator=Ville de Trifouilli
>
> --
> Christian Quest - OpenStreetMap France
> Un nouveau serveur pour OSM... http://donate.osm.org/server2013/
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Améliorations de ID

[Nicolas Dumoulin]

Le vendredi 7 juin 2013 13:03:20 Léo SERRE a écrit :
> La solution jOSM me pompe 600+ Mo de RAM après 15min d'utilisation,
> faute à Java.

Oulà, tu vas un peu vite pour crier sur Java ;-)
Je dirai que JOSM prend la RAM que tu lui donnes.
Tu dois pouvoir modifier la taille du cache (WMS, pavés images, …) pour qu'il 
soit moins gourmand.
Parce que bon, Java tout seul ne s'amuse pas à remplir la RAM.

Si tu vas dans l'onglet "Paramètres avancés" des préférences, tu lances une 
recherche sur "cache" et tu devrais avoir des pistes à confirmer dans la doc 
qui cite par exemple cache.wmsplugin.maxsize.

-- 
Nicolas Dumoulin
http://wiki.openstreetmap.org/wiki/User:NicolasDumoulin

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

[OSM-talk-fr] Découpages des académies...

[Christian Quest]

Le découpage des académies ? Ca vous inspire ?

boundary=* ?

En attendant, j'ai eu besoin de créer celle de Versailles qui n'est
qu'en multipolygone sans rien d'autre...

-- 
Christian Quest - OpenStreetMap France
Un nouveau serveur pour OSM... http://donate.osm.org/server2013/

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

Re: [OSM-talk-fr] Rendu des (grandes) gares Re: Proposition de projet du mois (gares SNCF)

[Nicolas Dumoulin]

Le vendredi 7 juin 2013 18:50:03 Philippe Verdy a écrit :
> A mon avis nommer les quais n'est pas utile, en France on annonce les voies
> des trains. 
> 
> > Le 7 juin 2013 18:16, Philippe Verdy  a écrit :
> > > Déjà les quais ne devraient pas s'afficher "Voies X-Y" mais "Quai X-Y".

Ha mais OK, il y a deux Philippe Verdy en fait ;-P

-- 
Nicolas Dumoulin
http://wiki.openstreetmap.org/wiki/User:NicolasDumoulin

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

Re: [OSM-talk-fr] Découpages des académies...

[Francescu GAROBY]

Tu parles des académies de l'Éducation Nationale, c'est bien ça ?
Je proposerais bien boundary=educative, éventuellement couplé à un
admin_level (mais pour quel usage ?), pour rester cohérent avec les
boundary=administrative et les boundary=religious

Francescu


Le 7 juin 2013 22:59, Christian Quest  a écrit :

> Le découpage des académies ? Ca vous inspire ?
>
> boundary=* ?
>
> En attendant, j'ai eu besoin de créer celle de Versailles qui n'est
> qu'en multipolygone sans rien d'autre...
>
> --
> Christian Quest - OpenStreetMap France
> Un nouveau serveur pour OSM... http://donate.osm.org/server2013/
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>



-- 
Cordialement,
Francescu GAROBY
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Proposition de projet du mois (gares SNCF)

[Christophe Merlet]

Le 07/06/2013 22:26, Christian Quest a écrit :

uic_ref était déjà utilisé, on en trouvera donc hors de France... à ne
pas changer "comme ça" donc.

Attention avec les N° UIC, ils sont à 7 chiffres + parfois un 8ème qui
est une clé de contrôle (je n'ai pas regardé de quel type, possible
que ça soit un code de Luhn) et une même gare peut avoir plusieurs
N°UIC.


Dans les documents cités précédemment les UIC fournit par RFF n'ont que 
6 chiffres... Il ne correspondent pas non plus que uic_ref que tu as 
entré dans OSM. les UIC fournit par RFF ne serait donc pas les bonnes 
références ?


Librement,
--
Christophe Merlet (RedFox)

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

Re: [OSM-talk-fr] OSM - Michelin

[Vincent de Château-Thierry]

Bonsoir,

Le 07/06/2013 10:46, bobo a écrit :

Vraiment intéressant à lire ce retour d'expérience.
Ça apporte pas mal de billes pour comprendre comment peut fonctionner un
projet de ce type.
En partageant les difficultés rencontrées, on est pas dans l'idée de
faire l’apologie osm et je trouve ça honnête
et cela fait bien avancer le débat. /pi, une touche de storytelling, ça
fait toujours du bien /


merci pour vos retours !


Aussi, je me suis dis que lors de la production de documents de ce type,
renseigner le nombre de personnes ayant contribué à osm sur la zone au
jour de l'extraction peut être intéressant. Ca met en relief l'aspect
participative, je ne sais pas si vous en avez parlé.


C'est un point auquel je n'avais pas pensé, mais j'aime bien l'idée :-)

vincent

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

Re: [OSM-talk-fr] Découpages des académies...

[Vincent de Château-Thierry]

Le 07/06/2013 23:07, Francescu GAROBY a écrit :

Tu parles des académies de l'Éducation Nationale, c'est bien ça ?
Je proposerais bien boundary=educative, éventuellement couplé à un
admin_level (mais pour quel usage ?), pour rester cohérent avec les
boundary=administrative et les boundary=religious


Le 7 juin 2013 22:59, Christian Quest mailto:cqu...@openstreetmap.fr>> a écrit :

Le découpage des académies ? Ca vous inspire ?

boundary=* ?

En attendant, j'ai eu besoin de créer celle de Versailles qui n'est
qu'en multipolygone sans rien d'autre...



De ce que je comprends du découpage [1], on n'a pas forcément une 
imbrication de zones, et si c'est confirmé (par ceux qui savent mieux 
que moi) alors pourquoi s'embêter avec un tag de type "level" ?


vincent

[1] : http://fr.wikipedia.org/wiki/Acad%C3%A9mie_(%C3%A9ducation)

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

Re: [OSM-talk-fr] Améliorations de ID

[Philippe Verdy]

Là aussi je te rejoins car JOSM réellement utilise **beaucoup** moins de
mémoire que l'application iD dans un navigateur web.
Certains j'aime pas JOSM à cause de Java et n'en veulent pas pour la
navigation web, pourtant il suffit de ne pas utiliser la verson 32 bits de
Java mais n'installer que la version 64 bits pour JOSM, le navigateur
utilisant Java en 32 bits (sauf si vous utiliser IE en mode 64 bits, ce qui
n'est pas le mode par défaut).

Franchement je tiens des semaines avec JOSM chargé, en même temps qu'un
navigateur Chrome avec presque toujours 7 ou 8 onglets ouverts (qui pompe
lui aussi alors plusieurs gigaoctets en RAM, là où JOSM chargé avec 3
feuilles OSM de plusieurs dizaines de méga en XML prends un peu moins d'1
Go de RAM par la VM Java intégrale : jamais pourtant on ne peut charger
autant de données dans un éditeur web comme iD ou Potlatch, ça rame
énormement plus).

Allez naviguer sur Facebook avec du Flash partout, vous dépassez vite
plusieurs Gigaoctets avec peu de chose utile pourtant.



Le 7 juin 2013 22:57, Nicolas Dumoulin <
nicolas_openstreetmap@dumoulin63.net> a écrit :

> Le vendredi 7 juin 2013 13:03:20 Léo SERRE a écrit :
> > La solution jOSM me pompe 600+ Mo de RAM après 15min d'utilisation,
> > faute à Java.
>
> Oulà, tu vas un peu vite pour crier sur Java ;-)
> Je dirai que JOSM prend la RAM que tu lui donnes.
> Tu dois pouvoir modifier la taille du cache (WMS, pavés images, …) pour
> qu'il
> soit moins gourmand.
> Parce que bon, Java tout seul ne s'amuse pas à remplir la RAM.
>
> Si tu vas dans l'onglet "Paramètres avancés" des préférences, tu lances une
> recherche sur "cache" et tu devrais avoir des pistes à confirmer dans la
> doc
> qui cite par exemple cache.wmsplugin.maxsize.
>
> --
> Nicolas Dumoulin
> http://wiki.openstreetmap.org/wiki/User:NicolasDumoulin
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Proposition de projet du mois (gares SNCF)

[Christian Quest]

Oups.. je voulais dire 6+1 et pas 7+1

Le 7 juin 2013 23:18, Christophe Merlet  a écrit :
> Le 07/06/2013 22:26, Christian Quest a écrit :
>
>> uic_ref était déjà utilisé, on en trouvera donc hors de France... à ne
>> pas changer "comme ça" donc.
>>
>> Attention avec les N° UIC, ils sont à 7 chiffres + parfois un 8ème qui
>> est une clé de contrôle (je n'ai pas regardé de quel type, possible
>> que ça soit un code de Luhn) et une même gare peut avoir plusieurs
>> N°UIC.
>
>
> Dans les documents cités précédemment les UIC fournit par RFF n'ont que 6
> chiffres... Il ne correspondent pas non plus que uic_ref que tu as entré
> dans OSM. les UIC fournit par RFF ne serait donc pas les bonnes références ?
>
>
> Librement,
> --
> Christophe Merlet (RedFox)
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr



-- 
Christian Quest - OpenStreetMap France
Un nouveau serveur pour OSM... http://donate.osm.org/server2013/

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

Re: [OSM-talk-fr] Découpages des académies...

[Christian Quest]

admin_level vaut pour boundary=administrative, on a vu l'effet pervers
de l'utiliser ailleurs (Nominatim qui ressort les diocèses par
exemple).

Si il est utile, un boundary:level serait plus cohérent, non ?

Par contre un petit tag pour indiquer la zone A/B/C de vacances y
aurait bien sa place...


Le 7 juin 2013 23:42, Vincent de Château-Thierry  a écrit :
>
>
> Le 07/06/2013 23:07, Francescu GAROBY a écrit :
>>
>> Tu parles des académies de l'Éducation Nationale, c'est bien ça ?
>> Je proposerais bien boundary=educative, éventuellement couplé à un
>> admin_level (mais pour quel usage ?), pour rester cohérent avec les
>> boundary=administrative et les boundary=religious
>>
>>
>> Le 7 juin 2013 22:59, Christian Quest > > a écrit :
>>
>>
>> Le découpage des académies ? Ca vous inspire ?
>>
>> boundary=* ?
>>
>> En attendant, j'ai eu besoin de créer celle de Versailles qui n'est
>> qu'en multipolygone sans rien d'autre...
>>
>
> De ce que je comprends du découpage [1], on n'a pas forcément une
> imbrication de zones, et si c'est confirmé (par ceux qui savent mieux que
> moi) alors pourquoi s'embêter avec un tag de type "level" ?
>
> vincent
>
> [1] : http://fr.wikipedia.org/wiki/Acad%C3%A9mie_(%C3%A9ducation)
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr



-- 
Christian Quest - OpenStreetMap France
Un nouveau serveur pour OSM... http://donate.osm.org/server2013/

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