Re: [OSM-talk-fr] Ouverture portail Open Data du Grand Nancy

[Romain MEHUT]

Le 25 août 2013 13:06, Romain MEHUT  a écrit :

> Le 24 août 2013 22:37, Christian Quest  a écrit :
>
> Bon, côté licence, c'est feu vert, mais maintenant il faut regarder la
>> qualité de ces données et ne pas s'enthousiasmer par avance vu les
>> expériences passées mais j'ai un bon présentiment vu la liste des jeux de
>> données.
>>
>> Romain, tu as déjà regardé la qualité ?
>>
>
> Non je n'ai pas encore eu le temps.
>

J'ai regardé quelques points adresse par rapport à ceux que j'avais relevés
sur le terrain et la position colle bien. Reste tout de même à bien placer
le point sur le polygone du bâti surtout en centre ville.

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

Re: [OSM-talk-fr] Ouverture portail Open Data du Grand Nancy

[Romain MEHUT]

Le 25 août 2013 17:40, DH  a écrit :

>
> Merci pour cette bonne nouvelle Romain.
> Pour donner un exemple de la qualité de l'image :
> http://dhelfer.free.fr/gare%**20de%20Nancy.png(ortho
>  à 7,5 cm)
>

C'est chouette! J'attends avec impatience que l'on puisse disposer d'un
flux WMS pour JOSM.


> Du coup, il y a du boulot ; j'vais y faire un tour virtuel ce soir...
> Un souhait particulier pour l'attribution de source ? ©Communauté Urbaine
> du Grand Nancy 2012 ?
>

Oui j'y ai pensé également car rien n'est indiqué sur le portail. Il existe
une convention dans ce cas de figure? On pourrait aussi simplement choisir
"Grand Nancy 2012"?

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

Re: [OSM-talk-fr] Ouverture portail Open Data du Grand Nancy

[Ista Pouss]

Le 26 août 2013 09:57, Romain MEHUT  a écrit :

>
>
> Oui j'y ai pensé également car rien n'est indiqué sur le portail. Il
> existe une convention dans ce cas de figure? On pourrait aussi simplement
> choisir "Grand Nancy 2012"?
>
>
Au niveau du sourcage, peut être serait-il intéressant d'être beaucoup plus
précis que ça, comme j'imagine qu'il sera importé par un logiciel, et que
ça prendra pas beaucoup plus de temps, que d'inclure la provenance précise
dans la base grand nancy.

Je veux dire, souvent qu'une donnée vient d'un table précise, et comporte à
l'origine un id dans cette table. Par exemple (j'imagine)  une hypothétique
liste de bancs publics, sera, je suppose, dans une table de bancs publics,
avec chacun un id dans cette table. En ce cas je suggèrerais de mettre
"Grand Nancy 2012 (si c'est ça qui est retenu) [nom de la table dans grand
nancy opendata] [id du banc dans la table opendata]".

À moins, bien sûr, que l'on ne décide de mettre ces infos dans des
propriétés, mais je ne suis pas sûr que ce soit judicieux, car le nom de la
table opendata n'est quand même pas une donnée géographique librement
observable sur le terrain, à moins, bien sûr, que les gens de Nancy se
soient organisés pour ça.

Une telle démarche permettra plus facilement une coordination entre OSM et
les données open data à l'avenir, me semble-t-il sauf erreur.

Cordialement.


-- 
Les dérives de rue :
La municipalité de Saint-Étienne applaudit le théâtre emporté par le
vent

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

Re: [OSM-talk-fr] Ouverture portail Open Data du Grand Nancy

[V de Chateau-Thierry]

Bonjour,

> De : "Ista Pouss" 
> Au niveau du sourcage, peut être serait-il intéressant d'être beaucoup plus
> précis que ça, comme j'imagine qu'il sera importé par un logiciel, et que
> ça prendra pas beaucoup plus de temps, que d'inclure la provenance précise
> dans la base grand nancy.
> 
> Je veux dire, souvent qu'une donnée vient d'un table précise, et comporte à
> l'origine un id dans cette table. Par exemple (j'imagine) une hypothétique
> liste de bancs publics, sera, je suppose, dans une table de bancs publics,
> avec chacun un id dans cette table. En ce cas je suggèrerais de mettre
> "Grand Nancy 2012 (si c'est ça qui est retenu) [nom de la table dans grand
> nancy opendata] [id du banc dans la table opendata]".

L'usage jusque là est plutôt de renseigner un tag source générique, à l'échelle 
du 
producteur (ici : source="Grand Nancy 2012" ou approchant) et d'ajouter un tag 
ref,
avec un espace de nommage spécifique, pour les identifiants lus dans la source, 
au
niveau de la donnée élémentaire. Quelque chose comme :
ref:GrandNancy=[id du banc dans la table opendata]

vincent

Une messagerie gratuite, garantie à vie et des services en plus, ça vous tente ?
Je crée ma boîte mail www.laposte.net

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

Re: [OSM-talk-fr] Ouverture portail Open Data du Grand Nancy

[Christian Quest]

Le 26 août 2013 10:15, Ista Pouss  a écrit :

> Le 26 août 2013 09:57, Romain MEHUT  a écrit :
>
>>
>>
>> Oui j'y ai pensé également car rien n'est indiqué sur le portail. Il
>> existe une convention dans ce cas de figure? On pourrait aussi simplement
>> choisir "Grand Nancy 2012"?
>>
>>
> Au niveau du sourcage, peut être serait-il intéressant d'être beaucoup
> plus précis que ça, comme j'imagine qu'il sera importé par un logiciel, et
> que ça prendra pas beaucoup plus de temps, que d'inclure la provenance
> précise dans la base grand nancy.
>
> Je veux dire, souvent qu'une donnée vient d'un table précise, et comporte
> à l'origine un id dans cette table. Par exemple (j'imagine)  une
> hypothétique liste de bancs publics, sera, je suppose, dans une table de
> bancs publics, avec chacun un id dans cette table. En ce cas je suggèrerais
> de mettre "Grand Nancy 2012 (si c'est ça qui est retenu) [nom de la table
> dans grand nancy opendata] [id du banc dans la table opendata]".
>
> À moins, bien sûr, que l'on ne décide de mettre ces infos dans des
> propriétés, mais je ne suis pas sûr que ce soit judicieux, car le nom de la
> table opendata n'est quand même pas une donnée géographique librement
> observable sur le terrain, à moins, bien sûr, que les gens de Nancy se
> soient organisés pour ça.
>
> Une telle démarche permettra plus facilement une coordination entre OSM et
> les données open data à l'avenir, me semble-t-il sauf erreur.
>
> Cordialement.
>
>

Il vaut mieux être précis dans le sourçage, car un même type d'info peut se
retrouver dans plusieurs dataset.
Exemple: les emplacement de stationnement PMR.

Ils se trouvent dans un fichier séparé, de qualité visiblement moyenne, et
dans un second jeu de données qui semble plus complet, plus précis au
niveau position (comparé au bâti du cadastre et à l'ortho bing), mais plus
ancien (2008). Ca montre au passage une fois de plus, tout le boulot fait
en doublon dans les administrations...

Donc... il y a surtout du boulot de tri à faire dans toutes ces données,
pour identifier les plus pertinentes, etc, etc...

-- 
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] Piscines - était : Re: Circuits vélotourisme en Vaucluse

[Guilhem Bonnefille]

Bonjour,


Le 21 août 2013 22:51, Yves Pratter  a écrit :

> En représentant leisure/amenity=swimming_pool, sans restriction d'accès
> (no/private), voilà ce que ça donne :
> http://osm107.openstreetmap.fr/jbtopo/piscines.PNG sur le nord-est
> d'Orange… Y'a du travail de nettoyage.
>
> Effectivement, on se croirait en pleine mer :-D
>
> Je ne suis pas convaincu par la présence du tag sport=swimming pour
> indiquer l'accessibilité au public…
>
> Non, il sert à indiquer — entre-autres à OpenSeaMap — qu'on y pratique la
> natation.
> La piscine du "Loft", bien que privée avait d'autres usages ;-)
>
> Pour les piscines découvertes pour villageois en vacances, ce tag ne se
> justifie pas toujours. Alors qu'un access=*, lui…
>
> Oui, dans tout ces exemples, il faut un access=private
>
>
>
Je ne suis pas l'actualité des tags de très prés, ni même je ne contribue
pas vraiment à leur élaboration. Par contre, en prenant un peu de recul,
l'idée de mettre un tag "access=private" sur les piscines "privées" est
surprenant.

Pour un chemin ou une route, préciser que l'une d'entre elle est "privée"
parait tout à fait naturel. Mais pour une piscine, ça me semble moins
naturel. En effet, dans ma région (sud, soleil, toussa), les piscines
"privées" sont légion, contrairement aux piscines publiques. Par exemple,
dans mon environnement proche, il doit y avoir 50% des maisons qui ont leur
piscine et pas la moindre piscine publique dans le village (qui dépasse les
3000 habitants). Du coup, ne serait-ce que d'un point de vue pratique, il
me semblerait plus logique que la notion "d'accès" sur une piscine soit
inversée : par défaut "private" et public seulement si précisé.

Dans le même ordre d'idée, depuis l'import du bâti, c'est plein de
"building=yes" sans autre précision et pourtant cela ne fait pas de ces
bâtiments des bâtiments publics que l'on peut visiter à loisir. Du coup,
est-il vraiment nécessaire de systématiquement préciser la nature d'un
accès ? Qui plus est, en suivant ma logique, ce n'est pas tant l'accès à la
piscine qui est privée, mais l'accès à toute la propriété. Du coup, il
faudrait systématiquement représenter les lots pour y faire porter cette
indication d'accès.

Une autre réflexion porte sur l'utilité de préciser les piscines privées.
On m'a dit un jour que les pompiers sont susceptibles d'apprécier cette
information. Mais ce qui leur importe, c'est de savoir qu'il y a de l'eau,
pas de savoir qu'on peut se baigner dedans. Peut-être que cette information
présente un intérêt pour des personnes souhaitant faire des statistiques,
ou je ne sais qu'elle étude. Peut-être aussi que cela fait un repère visuel
depuis les hauteurs (le ciel ?).


Bref, en conclusion, il me semble important de ne surtout pas représenter
tous les leisure=swimming_pool, qui doivent servir à représenter simplement
des bassins, mais plutôt sport=swimming comme précisé plus avant dans les
échanges de mails.


Mais bon, encore une fois, je ne suis pas très impliqué dans les décisions
qui tournent autour des tags et de leurs logiques ou homogénéités.
-- 
Guilhem BONNEFILLE
-=- JID: gu...@im.apinc.org MSN: guilhem_bonnefi...@hotmail.com
-=- mailto:guilhem.bonnefi...@gmail.com
-=- http://nathguil.free.fr/
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Après le dessous des cartes (sur Arte), voici le dessus des cartes (sur France Inter)

[Christian Quest]

C'était ce matin dans l'émission "Service Public" de France Inter, qu'on
peut ré-écouter sur
http://www.franceinter.fr/emission-service-public-gps-le-dessus-des-cartesà
partir de 3'50"

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

[OSM-talk-fr] Prochaine réunion des contributeurs à OpenStreetMap de la région de Marseille le lundi 2 / 09 / 2013 // 20h00 à La Bo@te.

[Olivier Griffet]

*Bonjour à toutes et à tous.
*
*

Je rappel que les contributeurs d' OpenStreetMap de la région de Marseille
se réunissent le lundi 2 septembre 2013,

à partir de 20h00 à La Bo@te ( dates suivantes en fin de message ).

*
*

Pour ceux qui compterais participez à la réunion et qui viennent pour la
première fois,

nous avons pour habitude que chacun(e) amène quelque chose à boire et/ou à
grignoter.

*
*Pour confirmer votre présence éventuel, vous pouvez répondre à ce message,
merci.


- Lien du plan de l'accès à La Bo@te :
http://www.openstreetmap.org/?lat=43.29213&lon=5.3730645&zoom=18&layers=M&mlat=43.29210&mlon=5.37297


- Lien de la page du Wiki d' Openstreetmap sur les réunions de Marseille :

http://wiki.openstreetmap.org/wiki/Marseille/R%C3%A9unions_2013


- Archives de l'année 2012 :

http://wiki.openstreetmap.org/wiki/Marseille/R%C3%A9unions_2012




Nota : Calendrier des réunions suivantes pour 2013, même lieu, même horaire.

*
*
*
*
- lundi 7 octobre 2013.
*
*
- lundi 4 novembre 2013.
*
*
- lundi 2 décembre 2013.
*
***


À bientôt...


Amicales salutations.**
**
Olivier Griffet 

| Contributeur OpenStreetMap =>
http://www.openstreetmap.org/user/olivier_griffet_83660_carnoules  |

| Habitant de 
83660-
Carnoules  - Var | Adhérent de GULLIVAR et ToulonuX |

Utilisateur de GNU/LINUX > de **(X)Ubuntu 12.04 [  XFCE ] ; Lives USB >>
ASRI.EDU.300 ; Etc...

Site web de GULLIVAR : http://gullivar.org/

Site web de ToulonuX : http://toulonux.tuxfamily.org/
*
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Après le dessous des cartes (sur Arte), voici le dessus des cartes (sur France Inter)

[Pierre Knobel]

En dehors de la phrase "tout le monde peut y participer", la description du
projet vers 26'30'' ne donne pas une idée très précise du projet. La dame
dit même qu'il n'y a aucune uniformisation de l'information, donc je me
demande bien pourquoi on se fatigue à discuter des bonnes pratiques sur
cette liste de diffusion.


2013/8/26 Christian Quest 

> C'était ce matin dans l'émission "Service Public" de France Inter, qu'on
> peut ré-écouter sur
> http://www.franceinter.fr/emission-service-public-gps-le-dessus-des-cartesà 
> partir de 3'50"
>
> --
> 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] Bâtiment non rendu

[Damouns]

Bonjour, j'ai un bâtiment :

http://www.openstreetmap.org/browse/way/32635153

qui n'est rendu ni sur Osm.org :

http://www.openstreetmap.org/#map=19/45.19088/5.72839

ni sur tile.openstreetmap.fr :

http://tile.openstreetmap.fr/?zoom=19&lat=45.19088&lon=5.72839

Quelqu'un aurait un diagnostic de ce qui se passe ?

Merci !

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

Re: [OSM-talk-fr] Bâtiment non rendu

[Christophe Merlet]

Le 26/08/2013 15:55, Damouns a écrit :

Bonjour, j'ai un bâtiment :

http://www.openstreetmap.org/browse/way/32635153

qui n'est rendu ni sur Osm.org :

http://www.openstreetmap.org/#map=19/45.19088/5.72839

ni sur tile.openstreetmap.fr  :

http://tile.openstreetmap.fr/?zoom=19&lat=45.19088&lon=5.72839

Quelqu'un aurait un diagnostic de ce qui se passe ?



Sue le rendu palois il apparait qu'à une époque, c'était un 
multipolygone creux (voir pièce jointe si elle passe sur la liste).
Il a perdu son chemin intérieur. Et depuis, même sur le serveur palois, 
quelque soit le style, le bâtiment n'est plus rendu après recalcul.


Je n'ai aucune explication, le bâtiment semble correct.

A par le supprimer et le redessiner complètement, je n'ai aucune suggestion.


Librement,
--
Christophe Merlet (RedFox)
<>___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Bâtiment non rendu

[Christian Quest]

J'ai fait une modif neutre (juste un changement de version de l'objet) et
il est apparu sur le rendu osm.org

Ca ressemble à une désynchro d'objet... ça arrive parfois, sûrement un bug
d'osm2pgsql si un multipolygone disparait, le polygone outer n'est pas
recréé ou un truc du genre.


Le 26 août 2013 16:31, Christophe Merlet  a écrit :

> Le 26/08/2013 15:55, Damouns a écrit :
>
>> Bonjour, j'ai un bâtiment :
>>
>> http://www.openstreetmap.org/**browse/way/32635153
>>
>> qui n'est rendu ni sur Osm.org :
>>
>> http://www.openstreetmap.org/#**map=19/45.19088/5.72839
>>
>> ni sur tile.openstreetmap.fr  :
>>
>>
>> http://tile.openstreetmap.fr/?**zoom=19&lat=45.19088&lon=5.**72839
>>
>> Quelqu'un aurait un diagnostic de ce qui se passe ?
>>
>>
> Sue le rendu palois il apparait qu'à une époque, c'était un multipolygone
> creux (voir pièce jointe si elle passe sur la liste).
> Il a perdu son chemin intérieur. Et depuis, même sur le serveur palois,
> quelque soit le style, le bâtiment n'est plus rendu après recalcul.
>
> Je n'ai aucune explication, le bâtiment semble correct.
>
> A par le supprimer et le redessiner complètement, je n'ai aucune
> suggestion.
>
>
> 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] live.openstreetmap.fr c'est parti !

[Stéphane Péneau]

C'est normal que live.openstreetmap.fr soit toujours H.S. ?

Stf

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

Re: [OSM-talk-fr] live.openstreetmap.fr c'est parti !

[Christian Quest]

Il tourne sur osm7... qui est HS...


Le 26 août 2013 16:42, Stéphane Péneau  a écrit
:

> C'est normal que live.openstreetmap.fr soit toujours H.S. ?
>
> Stf
>
>
> __**_
> 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

[OSM-talk-fr] Comparaison OSM/Route500

[Christian Quest]

Je viens de terminer un bout de script pour générer département par
département une liste des routes présentes dans OSM et dans le Route500 de
l'IGN.

Donc pour chaque département ça sort la liste des 'ref' et les km présents
dans OSM et le Route500, le tout sous forme de fichier CSV (en attendant
une interface un peu plus sexy).

http://osm13.openstreetmap.fr/~cquest/routes/

Extrait du README:
Les kilométrage sont calculés en projection Lambert 93 (EPSG:2154).
La date de modification de chaque fichier CSV indique quand le calcul a été
fait, les données OSM pouvant avoir en général tout au plus 5mn de retard
de mise à jour.

ATTENTION: Les tronçons sont découpés à la limite du département présente
dans OSM, ceci peut créer de petites erreurs de calcul à la frontière du
département.
Les kilométrage du Route500 sont généralement inférieurs à ceux d'OSM pour
une route complète de part la simplification géométrique du Route500.
Tous les type de highway=* sont pris en compte sans distinction (cf la
requête SQL).

-- 
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] Comparaison OSM/Route500

[Art Penteur]

Merci, mais tu comptes l'utiliser comment ?
Sachant qu'il y a un certain nombre de cas où il est très difficile de
savoir qui a raison sur la numérotation, suite à des renumérotations et des
documents pas toujours très clairs ni accessibles, le terrain et/ou
route500 en retard...
Il va falloir éviter les traitements trop automatiques.
Quelques "raster eggs" :
Dans le 25, on a une D89 qui fait 0km chez OSM et chez IGN : comment
est-elle arrivée là ?
Idem dans le 12 pour la D907B.
Et on retrouve une toute petite N9 à la fois dans le 12 et le 25, chez IGN ?

Art.
Le 26 août 2013 19:47, "Christian Quest"  a écrit :

> Je viens de terminer un bout de script pour générer département par
> département une liste des routes présentes dans OSM et dans le Route500 de
> l'IGN.
>
> Donc pour chaque département ça sort la liste des 'ref' et les km présents
> dans OSM et le Route500, le tout sous forme de fichier CSV (en attendant
> une interface un peu plus sexy).
>
> http://osm13.openstreetmap.fr/~cquest/routes/
>
> Extrait du README:
> Les kilométrage sont calculés en projection Lambert 93 (EPSG:2154).
> La date de modification de chaque fichier CSV indique quand le calcul a
> été fait, les données OSM pouvant avoir en général tout au plus 5mn de
> retard de mise à jour.
>
> ATTENTION: Les tronçons sont découpés à la limite du département présente
> dans OSM, ceci peut créer de petites erreurs de calcul à la frontière du
> département.
> Les kilométrage du Route500 sont généralement inférieurs à ceux d'OSM pour
> une route complète de part la simplification géométrique du Route500.
> Tous les type de highway=* sont pris en compte sans distinction (cf la
> requête SQL).
>
> --
> 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] Comparaison OSM/Route500

[Jean-Claude Repetto]

On 26/08/2013 19:45, Christian Quest wrote:

Je viens de terminer un bout de script pour générer département par
département une liste des routes présentes dans OSM et dans le Route500
de l'IGN.


Très intéressant ! Ce script sera-t-il lancé régulièrement ? Cela 
permettrait de suivre l'avancée des travaux, surtout si plusieurs 
contributeurs travaillent sur le même département.


Pour le 06, il manque les routes métropolitaines, ce qui fausse le résultat.
Peux-tu modifier ta requête :
HAVING SUBSTRING(ref,1,1) IN ('A','N','D')
en
HAVING SUBSTRING(ref,1,1) IN ('A','N','D','M') ?

La requête fait aussi apparaître les pistes DFCI (par exemple DFCILD 86 
A 2.4), mais ce n'est pas très gênant, il suffit de ne pas en tenir compte.


Jean-Claude


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

Re: [OSM-talk-fr] Comparaison OSM/Route500

[Christian Quest]

Le 26 août 2013 20:52, Jean-Claude Repetto  a écrit :

> On 26/08/2013 19:45, Christian Quest wrote:
>
>> Je viens de terminer un bout de script pour générer département par
>> département une liste des routes présentes dans OSM et dans le Route500
>> de l'IGN.
>>
>
> Très intéressant ! Ce script sera-t-il lancé régulièrement ? Cela
> permettrait de suivre l'avancée des travaux, surtout si plusieurs
> contributeurs travaillent sur le même département.
>
>
Oui, je pense quotidiennement.



> Pour le 06, il manque les routes métropolitaines, ce qui fausse le
> résultat.
> Peux-tu modifier ta requête :
> HAVING SUBSTRING(ref,1,1) IN ('A','N','D')
> en
> HAVING SUBSTRING(ref,1,1) IN ('A','N','D','M') ?
>
>
Déjà ajouté pour le 06... même si ces routes "M" n'existent pas
officiellement ;)



> La requête fait aussi apparaître les pistes DFCI (par exemple DFCILD 86 A
> 2.4), mais ce n'est pas très gênant, il suffit de ne pas en tenir compte.



Oui, j'ai vu ça. Ca vient du fait que je prends toutes les highway=* sans
distinction (cf README).


-- 
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] Comparaison OSM/Route500

[Tetsuo Shima]

Visiblement la requête tient compte des espaces - D155 différent de D 155 -
et de la casse pour comparer les références de voie, ça complique le
traitement des résultats avec tout un tas de faux positif. Je pense qu'il
serait préférable de traiter D 155 b identique a D155B par exemple, ca
évite d'avoir a traiter séparément les deux "erreurs" remontées.


Le 26 août 2013 19:45, Christian Quest  a écrit :

> Je viens de terminer un bout de script pour générer département par
> département une liste des routes présentes dans OSM et dans le Route500 de
> l'IGN.
>
> Donc pour chaque département ça sort la liste des 'ref' et les km présents
> dans OSM et le Route500, le tout sous forme de fichier CSV (en attendant
> une interface un peu plus sexy).
>
> http://osm13.openstreetmap.fr/~cquest/routes/
>
> Extrait du README:
> Les kilométrage sont calculés en projection Lambert 93 (EPSG:2154).
> La date de modification de chaque fichier CSV indique quand le calcul a
> été fait, les données OSM pouvant avoir en général tout au plus 5mn de
> retard de mise à jour.
>
> ATTENTION: Les tronçons sont découpés à la limite du département présente
> dans OSM, ceci peut créer de petites erreurs de calcul à la frontière du
> département.
> Les kilométrage du Route500 sont généralement inférieurs à ceux d'OSM pour
> une route complète de part la simplification géométrique du Route500.
> Tous les type de highway=* sont pris en compte sans distinction (cf la
> requête SQL).
>
> --
> 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] Appel aux Troyens

[Tony Emery]

Déjà, ce serait bien de virer les "quartier de". C'est comme si on mettait
"Ville de Troyes" dans le tag "name".

Il me semble aussi que c'est une erreur de rendu et c'est vrai que c'est un
problème. Il faudrait :
- que les étiquettes à des échelles différentes selon son niveau ;
- qu'il y ait une priorité dans l'affichage.



-
Tony EMERY
Administrateur OpenStreetMap.fr
Mandataire Grand Sud-Est
Géomaticien & chef de projets
--
View this message in context: 
http://gis.19327.n5.nabble.com/Appel-aux-Troyens-tp5774848p5775071.html
Sent from the France mailing list archive at Nabble.com.

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

Re: [OSM-talk-fr] Comparaison OSM/Route500

[Christian Quest]

La requête (qui se trouve dans le README) élimine les espaces et met tout
en minuscule. Donc D 155b et D155B sont (sauf erreur) regroupé en D155B.
C'est le boulot du REGEXP_REPLACE(UPPER(r.ref),' ','')

Le but ici n'est pas de vérifier si les ref=* sont bien écrits dans OSM,
c'est plus du domaine d'osmose que de ces listings de suivi.

Dans quel département as-tu trouvé un "D 155b" dans les fichiers générés ?



Le 27 août 2013 01:54, Tetsuo Shima  a écrit :

> Visiblement la requête tient compte des espaces - D155 différent de D 155
> - et de la casse pour comparer les références de voie, ça complique le
> traitement des résultats avec tout un tas de faux positif. Je pense qu'il
> serait préférable de traiter D 155 b identique a D155B par exemple, ca
> évite d'avoir a traiter séparément les deux "erreurs" remontées.
>
>
> Le 26 août 2013 19:45, Christian Quest  a écrit :
>
>> Je viens de terminer un bout de script pour générer département par
>> département une liste des routes présentes dans OSM et dans le Route500 de
>> l'IGN.
>>
>> Donc pour chaque département ça sort la liste des 'ref' et les km
>> présents dans OSM et le Route500, le tout sous forme de fichier CSV (en
>> attendant une interface un peu plus sexy).
>>
>> http://osm13.openstreetmap.fr/~cquest/routes/
>>
>> Extrait du README:
>> Les kilométrage sont calculés en projection Lambert 93 (EPSG:2154).
>> La date de modification de chaque fichier CSV indique quand le calcul a
>> été fait, les données OSM pouvant avoir en général tout au plus 5mn de
>> retard de mise à jour.
>>
>> ATTENTION: Les tronçons sont découpés à la limite du département présente
>> dans OSM, ceci peut créer de petites erreurs de calcul à la frontière du
>> département.
>> Les kilométrage du Route500 sont généralement inférieurs à ceux d'OSM
>> pour une route complète de part la simplification géométrique du Route500.
>> Tous les type de highway=* sont pris en compte sans distinction (cf la
>> requête SQL).
>>
>> --
>> 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
>
>


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