Re: [OSM-talk-fr] Relation pour les lignes de bus et les directions

[Vincent Pottier]

On 04/11/2010 19:24, rldhont wrote:


En fait il est prévu d'indiqué dans le rôle des chemins d'une relation 
de type route si les véhicules circules dnas les 2 sens, dans le sens 
du chemin ou dans le sens inverse du chemin. Il est donc tout à fait 
possible quand on connait l'ordre du parcours des arrêts de savoir 
quel chemin est emprunté dans quel sens.


Mon point de vue est qu'en fait plus il y a de relation plus il est 
difficile de maintenir l'information. J'ai pus constaté avec 
OSMTransport qu'il était facile de troué un parcours en m'étant à jour 
des chemins, donc la maintenance devient de plsu en plus compliqué si 
on doit corrigé autant de relation qu'il y a de sens de circulation et 
de terminus.


Je pense donc qu'une relation par ligne de bus est suffisante!

Mon point de vue, c'est que je gère mieux une relation par sens de bus 
avec ordonnancement des portions, des arrêts. C'est une question de style.
Pour porter leur sac, certains préfèrent des bretelles, d'autres des 
poignées. C'est une question de style.


Pour du rendu 3liz, une relation par ligne suffit.
Mais pour générer du GTFS (1) ou du sketch-route (2), une relation par 
sens est nécessaire. C'est d'ailleurs le schéma qui se répand.


(1) 
http://code.google.com/intl/fr/transit/spec/transit_feed_specification.html


(2) http://78.46.81.38/public_transport.html
http://78.46.81.38/api/sketch-line?network=Ginko&ref=27&correspondences=100
http://78.46.81.38/api/sketch-route?154149
http://78.46.81.38/api/sketch-route?532894
http://78.46.81.38/api/sketch-route?537910
http://78.46.81.38/api/sketch-route?539097
--
FrViPofm
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Relation pour les lignes de bus et les directions

[J.-Lys]

Pour ma part, j'en suis arrivé à penser que, mise à part la localisation des
arrêts, l'information "Transports en commun" est trop volatile pour être
intégrée "en dur" dans la base de données. 
Professionnellement, m'occupant de l'informatique dans la société de TC de
Maubeuge, j'ai eu à me pencher sur ce problème : la notion de ligne est par
nature assez fluctuante (surtout pour les bus qui n'ont pas à suivre les
rails...). Une même ligne n'a pas forcément le même tracé selon les périodes
de l'année, de la semaine, voire de la journée. Vouloir décrire l'ensemble
de ces variantes dans des relations peut vite devenir extrêmement compliqué
et la maintenance  un cauchemar chronophage (car même les tracés de lignes
évoluent). Je le sais, je l'ai fait :
http://3liz.fr/public/osmtransport/index.php?country=France&location=Val%20de%20Sambre
 
http://www.xn--pnvkarte-m4a.de/?zoom=12&lat=50.24912&lon=3.93809&layers=BT 

Le format de données open source GTFS (General Transit Feed Specification)
est, somme toute, assez efficace : les lignes (routes) y sont constituées de
voyages (trips) qui suivent un tracé (shape) et qui appartiennent à des
services ; ces services sont actifs ou pas selon un calendrier fonctionnant
par périodes (calendar) et/ou par exceptions (calendar_dates). 
Je l'ai fait aussi pour Google Transit :
http://www.google.com/maps?ie=UTF8&saddr=2+rue+du+gazometre+maubeuge&daddr=hypermarch%E9+auchan+louvroil%2C+Louvroil%2C+France&hl=fr&f=d&dirflg=r&ttype=dep&date=04%2F11%2F2010&time=18%3A56
 

- Un logiciel (GO_sync pour "GTFS-OSM Synchronization") est en cours de
développement (University of South Florida) et permet dores et déjà de
comparer/modifier/uploader les données GTFS et OSM. 
- Quand on dit que les données TC de Rennes vont être en accès libre, c'est
au format GTFS qu'elles le seront. 

Alors la solution n'est-elle pas GTFS, à condition que les Autorités
Organisatrices de Transport libèrent les données ?

J. Lys

-- 
View this message in context: 
http://gis.638310.n2.nabble.com/Relation-pour-les-lignes-de-bus-et-les-directions-tp5703433p5707135.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] "cadget" mis à jour

[Denis]

Le 04/11/2010 21:14, Olivier Croquette a écrit :

On 4 nov. 2010, at 20:36, Denis wrote:
   

Pourtant, il y a ci-joint un log d'erreur ; le Lucid Lynx miaule.
 

C'est ImageMagick qui plante. D'après le log, tu utilises la version 6.5.7 qui 
date d'un an.
Tu peux essayer avec une version plus récente ? J'utilise la 6.6.4 ici, qui 
fonctionne dans ce cas. La dernière est la 6.6.5.

   
scroneugneu, moi qui pensais avoir une distrib uptodate. Ca sent la 
compil à plein nez.
Franchement, je croyais que l'informatique linuxienne avait fait  des 
progrès depuis mes dernières compil de noyau.

Ca fait un bail que j'ai arrêté de trouver cela amusant ou instructif.
A suivre...

Par ailleurs, le support de proxy serait un plus.
 

OK, c'est fait ! Il faut utiliser la variable d'environnement "http_proxy".
J'en ai profité pour mettre la version officielle sur le serveur SVN :
http://svn.openstreetmap.org/applications/utils/cadastre-france/cadget
   


merci, je vais tester cela... asap

Denis

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

Re: [OSM-talk-fr] Support de presentation pour les elus locaux

[Olivier Croquette]

On 4 nov. 2010, at 10:51, Philippe Pary wrote:
>> Tu ajouterais quoi comme info ? Comment les utiliser ? Le but n'est que de 
>> donner un aperçu des possibilités. Pour aller plus loin, je considère qu'il 
>> faut consulter la documentation de l'outil en question.
> 
> Sur GéoVélo, une diapo pour « montrer », puis une lisant les
> fonctionnalités (calcul d'itinéraire, possibilité de choisir entre temps
> et sécurité)

C'est toujours bien d'avoir plus d'infos sur support, mais alors dans la 
section "Pour aller plus loin". Les quelques applications citées dans 3 ont 
pour but de montrer le potentiel d'OSM en général, pas d'aller dans le détail. 
Avec les question, j'en ai déjà eu pour 2h à présenter ce qu'il y a.

> Pour MapOSMatic, idem. Montrer, puis expliquer  : fonctionnement à la
> demande, index des rues, possibilité de ne travailler que sur un
> quartier …

Idem, ça va dans "Pour aller plus loin". Cette présentation est une 
introduction à destination des élus des petites communes, il ne faut pas les 
assommer...

> D'ailleurs dans la section « modifier », je mettrai un « comment
> contribuer ? » en mettant des points comme :
> — faire relire la carte de votre commune pour trouver les erreurs et les
> corriger //  travailler avec des associations locales pour créer la
> carte de la commune
> — donner un annuaire des commerçants locaux pour qu'on puisse les
> intégrer dans OSM
> — indiquer les parkings, pistes cyclables, signalisations routières etc.

"Comment modifier", c'est trop tôt pour un premier contact. Mais je suis 
d'accord que dans la partie centrale de la présentation il manque une partie 
"Comment nous aider" (nous=les contributeurs actuels d'OSM) avec ces points.

> Dès qu'il y a l'ODP, je peux me charger de tout ça
> 
> D'ailleurs, j'ai retrouvé un vieux courrier adressé à ma mairie :
> http://osm.cleo-carto.org/ftp/Courrier%20Willems.pdf (ça remonte à avant
> le projet Cléo, aujourd'hui je serai un peu plus commercial dans mon
> courrier :-))

C'est la même démarche. Tu as eu des retours sur cette lettre ?

> J'ai ouvert un pad (éditeur de texte collaboratif) pour faire un
> courrier général sur base de ce document : 
> http://osm.cleo-carto.org:9000/1

Il faudrait merger avec :
http://wiki.openstreetmap.org/wiki/Lettre_aux_%C3%A9lus


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

Re: [OSM-talk-fr] "cadget" mis à jour

[Olivier Croquette]

On 4 nov. 2010, at 20:36, Denis wrote:
> Pourtant, il y a ci-joint un log d'erreur ; le Lucid Lynx miaule.

C'est ImageMagick qui plante. D'après le log, tu utilises la version 6.5.7 qui 
date d'un an.
Tu peux essayer avec une version plus récente ? J'utilise la 6.6.4 ici, qui 
fonctionne dans ce cas. La dernière est la 6.6.5.

> Par ailleurs, le support de proxy serait un plus.

OK, c'est fait ! Il faut utiliser la variable d'environnement "http_proxy".
J'en ai profité pour mettre la version officielle sur le serveur SVN :
http://svn.openstreetmap.org/applications/utils/cadastre-france/cadget


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

Re: [OSM-talk-fr] "cadget" mis à jour

[Denis]

Le 04/11/2010 17:53, Croquette Olivier a écrit :

Le script "cadget" pour récupérer des feuilles raster entières du cadastre a 
été mis à jour. Les nouveautés sont les suivantes :
   Ajout de l'option -transparence pour faciliter le travail de superposition 
(dans JOSM)
   Les bords inutiles (blancs) sont désormais supprimés
   Sans l'option -transparence, la sortie PNG est désormais en couleurs 
indexées pour alléger les fichiers
   Les tuiles sont désormais téléchargées dans un sous-repertoire
   Corrigé: erreur à propos de make_path avec de vieilles versions des 
librairies
   


Bravo pour cet outil dont j'ai très envie de me servir.
Pourtant, il y a ci-joint un log d'erreur ; le Lucid Lynx miaule.
Par ailleurs, le support de proxy serait un plus.

Denis, en stand by

discussion en privé si nécessaire (je ne suis pas abonné à dev)
de...@machine:~/Bureau/OSM$ uname -a
Linux machine 2.6.32-25-generic #45-Ubuntu SMP Sat Oct 16 19:52:42 UTC 2010 x86_64 GNU/Linux

de...@machine:~/Bureau/OSM$ perl cadget.pl --ville KILSTETT --departement 67
/home/denis/Bureau/OSM...
/home/denis/Bureau/OSM/tuiles...
Création de /home/denis/Bureau/OSM/tuiles...
Initialisation de la navigation et création du cookie...
Activation de la commune...
Récupération de la liste des feuilles...
Récupération de 20 feuille(s)...
  Activation de la feuille QB237101 (1/20)...
Récupération de la tuile   1 sur   1 pour la feuille QB237101 (Bbox: 00,-01915,013750,008710)
  Collage des tuiles pour créer la feuille "QB237101" dans "067-KILSTETT-QB237101-0.08-feuille.png"...
*** glibc detected *** convert: free(): invalid next size (normal): 0x015fd450 ***
=== Backtrace: =
/lib/libc.so.6(+0x775b6)[0x7fe5001165b6]
/lib/libc.so.6(+0x7cce4)[0x7fe50011bce4]
/lib/libc.so.6(__libc_memalign+0xc2)[0x7fe50011c6a2]
/lib/libc.so.6(posix_memalign+0x39)[0x7fe50011c8f9]
/usr/lib/libMagickCore.so.2(AcquireAlignedMemory+0x30)[0x7fe500cc97d0]
/usr/lib/libMagickCore.so.2(AllocateSemaphoreInfo+0x22)[0x7fe500d07372]
/usr/lib/libMagickCore.so.2(GetExceptionInfo+0x2b)[0x7fe500c9a8ab]
/usr/lib/libMagickCore.so.2(AcquireExceptionInfo+0x1f)[0x7fe500c9b19f]
/usr/lib/libMagickCore.so.2(GetLocaleMessage+0x75)[0x7fe500cc3655]
/usr/lib/libMagickCore.so.2(GetLocaleExceptionMessage+0x61)[0x7fe500c9a4e1]
/usr/lib/libMagickCore.so.2(ThrowMagickExceptionList+0x87)[0x7fe500c9ae27]
/usr/lib/libMagickCore.so.2(ThrowMagickException+0x89)[0x7fe500c9b049]
/usr/lib/ImageMagick-6.5.7/modules-Q16/coders/png.so(+0x771e)[0x7fe4fd4f771e]
/lib/libpng12.so.0(png_error+0x46)[0x7fe4fd2e58a6]
/lib/libpng12.so.0(png_set_PLTE+0x7c)[0x7fe4fd2d057c]
/usr/lib/ImageMagick-6.5.7/modules-Q16/coders/png.so(+0x14b52)[0x7fe4fd504b52]
/usr/lib/ImageMagick-6.5.7/modules-Q16/coders/png.so(+0x1629e)[0x7fe4fd50629e]
/usr/lib/libMagickCore.so.2(WriteImage+0x2a0)[0x7fe500c3c570]
/usr/lib/libMagickCore.so.2(WriteImages+0x16b)[0x7fe500c3cc9b]
/usr/lib/libMagickWand.so.2(ConvertImageCommand+0x2a0b)[0x7fe5008ff69b]
/usr/lib/libMagickWand.so.2(MagickCommandGenesis+0x1c3)[0x7fe500990883]
convert[0x4009f5]
/lib/libc.so.6(__libc_start_main+0xfd)[0x7fe5000bdc4d]
convert[0x4008d9]
=== Memory map: 
0040-00401000 r-xp  08:01 9044155/usr/bin/convert
0060-00601000 r--p  08:01 9044155/usr/bin/convert
00601000-00602000 rw-p 1000 08:01 9044155/usr/bin/convert
01593000-016ff000 rw-p  00:00 0  [heap]
7fe4f7de9000-7fe4f7dff000 r-xp  08:01 3145807/lib/libgcc_s.so.1
7fe4f7dff000-7fe4f7ffe000 ---p 00016000 08:01 3145807/lib/libgcc_s.so.1
7fe4f7ffe000-7fe4f7fff000 r--p 00015000 08:01 3145807/lib/libgcc_s.so.1
7fe4f7fff000-7fe4f800 rw-p 00016000 08:01 3145807/lib/libgcc_s.so.1
7fe4f800-7fe4f8021000 rw-p  00:00 0 
7fe4f8021000-7fe4fc00 ---p  00:00 0 
7fe4fc0db000-7fe4fc0dc000 ---p  00:00 0 
7fe4fc0dc000-7fe4fc8dc000 rw-p  00:00 0 
7fe4fc95d000-7fe4fd248000 rw-p  00:00 0 
7fe4fd2c9000-7fe4fd2ee000 r-xp  08:01 3145877/lib/libpng12.so.0.42.0
7fe4fd2ee000-7fe4fd4ee000 ---p 00025000 08:01 3145877/lib/libpng12.so.0.42.0
7fe4fd4ee000-7fe4fd4ef000 r--p 00025000 08:01 3145877/lib/libpng12.so.0.42.0
7fe4fd4ef000-7fe4fd4f rw-p 00026000 08:01 3145877/lib/libpng12.so.0.42.0
7fe4fd4f-7fe4fd50c000 r-xp  08:01 9047986/usr/lib/ImageMagick-6.5.7/modules-Q16/coders/png.so
7fe4fd50c000-7fe4fd70b000 ---p 0001c000 08:01 9047986/usr/lib/ImageMagick-6.5.7/modules-Q16/coders/png.so
7fe4fd70b000-7fe4fd70c000 r--p 0001b000 08:01 9047986/usr/lib/ImageMagick-6.5.7/modules-Q16/coders/png.so
7fe4fd70c000-7fe4fd70d000 rw-p 0001c000 08:01 9047986   

Re: [OSM-talk-fr] Relation pour les lignes de bus et les directions

[rldhont]

Le 04/11/2010 12:58, Pieren a écrit :

2010/11/4 rldhont mailto:rldh...@gmail.com>>

Bonjour,

En tant qu'auteur d'OSMTransport, je ne pense pas qu'il soit utile
de créer une relation par sens de circulation et de les regrouper
dans une relation ligne elle même faisant partie d'une relation
réseau, etc...


Pourrais-tu en dire plus ? Sans avoir suivi le sujet en détail, je 
pensais que la solution des deux relations était le plus simple 
lorsque le trajet de la ligne était différent suivant le sens de 
circulation.


En fait il est prévu d'indiqué dans le rôle des chemins d'une relation 
de type route si les véhicules circules dnas les 2 sens, dans le sens du 
chemin ou dans le sens inverse du chemin. Il est donc tout à fait 
possible quand on connait l'ordre du parcours des arrêts de savoir quel 
chemin est emprunté dans quel sens.


Mon point de vue est qu'en fait plus il y a de relation plus il est 
difficile de maintenir l'information. J'ai pus constaté avec 
OSMTransport qu'il était facile de troué un parcours en m'étant à jour 
des chemins, donc la maintenance devient de plsu en plus compliqué si on 
doit corrigé autant de relation qu'il y a de sens de circulation et de 
terminus.


Je pense donc qu'une relation par ligne de bus est suffisante!




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] JOSM, Mapnik Osmarender et les Relations

[Pierre Quenee]

Le 04/11/2010 18:08, talk-fr-requ...@openstreetmap.org a écrit :

Sauf erreur, l'idée c'est que la forme en 8 est interdite par la norme, un
format GIS de type "multipolygon" (le vrai de l'OGC, c'est à dire plusieurs
polygones) ne doivent n'y s'intersecter, ni se toucher.

Pour la suite, j'avoue n'avoir pas compris, et un dessin valant mieux qu'un
long discours voilà comment je ferais pour ton n=2 :

http://osm.org/go/APa2ibC

Est-ce que c'est ça que tu voulais dire ?

Donc je me suis planté dans le cas d'une jonction par point, mais pas 
dans le cas d'une jonction par segment dans le cadre d'une relation 
unique (voir relation 1255566 même zone).

Mais ca n'a pas d'importance et je suggère cette conclusion:

Toute tentative volontaire ou involontaire de rejoindre des surfaces 
disjointes par un point ou un segment n'est pas conforme au standard de 
l'OGC, ne conduit pas nécessairement à des avertissements en phase 
d'édition, et peut se traduire par des différences de rendus entre les 
divers moteurs appliqués à la base de donnée.


tiré de la page wiki que je suis en train de traduire (user:PhQ discussions)


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

Re: [OSM-talk-fr] Relation pour les lignes de bus et les directions

[Jean-Francois Nifenecker]

Le 04/11/2010 12:58, Pieren a écrit :


la solution des deux relations était le plus simple lorsque
le trajet de la ligne était différent suivant le sens de circulation.


Ne serait-il pas utile/préférable de prévoir systématiquement une 
relation pour chaque sens de circulation ?


--
Jean-Francois Nifenecker, Bordeaux


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

[OSM-talk-fr] "cadget" mis à jour

[Croquette Olivier]

Le script "cadget" pour récupérer des feuilles raster entières du cadastre a 
été mis à jour. Les nouveautés sont les suivantes :
  Ajout de l'option -transparence pour faciliter le travail de superposition 
(dans JOSM)
  Les bords inutiles (blancs) sont désormais supprimés
  Sans l'option -transparence, la sortie PNG est désormais en couleurs indexées 
pour alléger les fichiers
  Les tuiles sont désormais téléchargées dans un sous-repertoire
  Corrigé: erreur à propos de make_path avec de vieilles versions des librairies

Voir aussi :
http://wiki.openstreetmap.org/wiki/WikiProject_Cadastre_Fran%C3%A7ais/cadget

Comme d'hab, les commentaires et critiques sont les bienvenus.
 
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Support de presentation pour les elus locaux

[Olivier Croquette]

On 4 nov. 2010, at 13:11, Pieren wrote:
> Pour des gros fichiers comme les présentations, il vaut mieux utiliser le 
> dépôt SVN d'osm qui abrite déjà un certain nombre de documents de ce genre et 
> non le wiki:
> http://svn.openstreetmap.org/misc/

OK, merci pour le tuyau, je demande un compte. Ça me permettra aussi d'y mettre 
"cadget".

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

Re: [OSM-talk-fr] JOSM, Mapnik Osmarender et les Relations

[Pierre Quenee]

   /Relation: Forêt sectionale des Besseyres (1175211)
   >  La réalité administrative est telle que c'est bien des points (borne
   >  cadastrale) qui constituent la liaison entre les différentes parties 
de la
   >  forêt !
   /

   /Deux manières d'aborder le problème :/
   /-1 Soit il est logique et obligatoire pour représenter la
   réalité de faire un /
   /polygone qui se croise lui même en un point unique et il faut
   alors amender /
   /la relation multipolygone en autorisant ce cas puis corriger
   map...@osm.org /
   /qui disposera alors d'un bug/
   /-2 Soit ce n'est pas logique et il faut alors modéliser la
   réalité autrement /
   /(créer un couloir de forêt ou créer un couloir de non-forêt)/

   /Pour ma part, c'est 2 qui me semble préférable, je n'arrive pas
   à imaginer, ce /
   /cas dans la réalité pour une forêt. En revanche, pour une
   frontière /
   /administrative, qui est une vue de l'esprit, cela devrait être
   possible./

Précisément, dans notre belle Auvergne au système forestier un peu 
particulier, il n'y a pas beaucoup de différence entre une frontière 
administrative et les limites d'une foret bénéficiant du Régime Forestier.
Administrativement, c'est une liste de parcelle cadastrale appartenant à 
un même propriétaire (un sous-ensemble de la commune appelé section - 
regroupant les habitants ayant-droits de hameau(x) voisin(s). Donc, le 
cas de figure redouté existe bel et bien, car la représentation 
cadastrale est une vue de l'esprit à caractère fiscal .. dont il arrive 
parfois qu'elle se rapproche de la réalité de terrain.
Dans le cas de figure présent, c'est une entité en trois sections 
jointives, ce qui est assez peu fréquent, voire unique, mais je ne l'ai 
pas inventé.
Bref, pour me mettre en conformité avec l'OGC (dont j'ai connu des 
lectures plus simples - en fait j'ai rien capté d'utile à me mettre sous 
la dent),  je propose un raisonnement par l'absurde, concernant au moins 
les trois zones jointives  par un segment dans la même relation.
Supposons qu'on puisse coder ce type de structure avec n éléments 
fermés, distincts et jointif par un coté. (n variant de 2 à plus, 
puisque le cas n=1 est le cas de base licite.
Considérons le cas particulier n= 2. Il n'existe pas avec JOSM de moyen 
de coder ce genre de structure avec deux zones partageant un même 
segment. Expérimentalement on obtiendra toujours une seule zone fermée 
(sans le segment commun) ou une liste de segments reliés non fermés et 
le segment commun) .
Donc, et même s'il existe des moyens de contourner le codage, le contre 
exemple fait tomber la proposition et donc il n'est pas licite de coder 
ce genre de structure.



Ceci dit, la page FR:Relation:multipolygon est loin d'être à jour, et je 
vais peut être aller faire un peu de traduction la-dedans


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

Re: [OSM-talk-fr] Support de presentation pour les elus locaux

[Pieren]

2010/11/4 Olivier Croquette 

>
> J'ai mon propre hébergement aussi, mais je voulais éviter de disperser
> l'information sur plusieurs serveurs pour les raisons de disponibilité,
> tracabilité...
> D'ailleurs, en ce qui concerne le Wiki, le problème suivant et la taille
> maximale pour un upload :
> http://trac.openstreetmap.org/ticket/3324
>
> Quel est l'adresse de ton serveur au fait ?
>
>
Pour des gros fichiers comme les présentations, il vaut mieux utiliser le
dépôt SVN d'osm qui abrite déjà un certain nombre de documents de ce genre
et non le wiki:
http://svn.openstreetmap.org/misc/

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

Re: [OSM-talk-fr] Relation pour les lignes de bus et les directions

[Pieren]

2010/11/4 rldhont 

>  Bonjour,
>
> En tant qu'auteur d'OSMTransport, je ne pense pas qu'il soit utile de créer
> une relation par sens de circulation et de les regrouper dans une relation
> ligne elle même faisant partie d'une relation réseau, etc...
>
>
Pourrais-tu en dire plus ? Sans avoir suivi le sujet en détail, je pensais
que la solution des deux relations était le plus simple lorsque le trajet de
la ligne était différent suivant le sens de circulation.

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

Re: [OSM-talk-fr] Support de presentation pour les elus locaux

[Philippe Pary]

Le jeudi 04 novembre 2010 à 10:24 +0100, Olivier Croquette a écrit :
> On 4 nov. 2010, at 10:11, Philippe Pary wrote:
> > C'est facile de critiquer, je sais, mais je trouve que trop de temps est
> > passé sur la technique et trop peu sur « en quoi ça peut m'aider ? »
> 
> Merci pour le retour !
> Attention, ce n'est qu'un support, rien n'empêche de passer plus de temps sur 
> un sujet ou un autre.
> Mais tu entends quoi par "la technique" ?

La présentation du serveur OpenStreetMap. La diapo d'articulation suffit
amplement. Dès lors les « rendus » peuvent être présentés comme des
exemples d'utilisation

> 
> > Par exemple, MapOSMatic mériterait bien 2-3 diapos, tout comme GéoVélo
> 
> Tu ajouterais quoi comme info ? Comment les utiliser ? Le but n'est que de 
> donner un aperçu des possibilités. Pour aller plus loin, je considère qu'il 
> faut consulter la documentation de l'outil en question.

Sur GéoVélo, une diapo pour « montrer », puis une lisant les
fonctionnalités (calcul d'itinéraire, possibilité de choisir entre temps
et sécurité)
Pour MapOSMatic, idem. Montrer, puis expliquer  : fonctionnement à la
demande, index des rues, possibilité de ne travailler que sur un
quartier …

D'ailleurs dans la section « modifier », je mettrai un « comment
contribuer ? » en mettant des points comme :
— faire relire la carte de votre commune pour trouver les erreurs et les
corriger //  travailler avec des associations locales pour créer la
carte de la commune
— donner un annuaire des commerçants locaux pour qu'on puisse les
intégrer dans OSM
— indiquer les parkings, pistes cyclables, signalisations routières etc.

Dès qu'il y a l'ODP, je peux me charger de tout ça

D'ailleurs, j'ai retrouvé un vieux courrier adressé à ma mairie :
http://osm.cleo-carto.org/ftp/Courrier%20Willems.pdf (ça remonte à avant
le projet Cléo, aujourd'hui je serai un peu plus commercial dans mon
courrier :-))

J'ai ouvert un pad (éditeur de texte collaboratif) pour faire un
courrier général sur base de ce document : 
http://osm.cleo-carto.org:9000/1

Philippe
PS: plus généralement, je peux ouvrir des pads « à la demande » et les
rendre privés si besoin. N'hésitez pas à me demander. Les pads, j'aime
bien ça !


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

Re: [OSM-talk-fr] JOSM, Mapnik Osmarender et les Relations

[Pierre Quenee]

>  http://www.openstreetmap.org/?lat=46.4004&lon=0.9715&zoom=14&layers=M
>  L'intéressant de la chose, c'est le comportement bogué, dans des
>  circonstances très spéciales, de Mapnik versus Osma surtout que

J'imagine que tu parles de 2 polygônes forêt du centre qui ne sont pas
dessinés ?

Oui, alors qu'ils sont bien représenté ( rempli) dans Osmarender


>  l'édition dans JOSM avec validateur est considérée comme correcte

Selon moi, ça ne l'est pas, par exemple le point en commun ne devrait pas
être, on appel ça les "touching rings" et même au niveau donnée ça me semble
incorrect. Soit la jonction entre les forêts existe, soit elle n'existe pas,
mais ça me paraît bizarre de considérer une connexion de taille nulle (un
point)

Ca ne l'est pas (comme je le dis dans mon introduction) exemple du haut ... 
Validator rale, mais ca  passe !

Dans le deuxième cas, j'ai splitté les ways, donc il n'y a plus de bouclage du 
chemin sur lui même, Validator aime, et mapnik a des rendu bizarre et en tout 
cas non conforme à ce que la base représente  (définition d'un bug ?)

dans le troisième cas (avant modif) le même tracé est réordonné en trois sous ensemble 
fermant avec des sommets non jointifs pour "leurrer" l'éditeur de relations de 
JOSM, enfin par leurrer je considère que c'est une syntaxe à priori correcte que j'impose 
à l'éditeur.
Alors, bien sur, il y a la solution d'isoler réllement le troisième triangle 
(correction appliquée dans l'exemple) mais avec le risque de créer des micro 
couloir difficile à détecter ultérieurement.
C'est d'ailleurs la solution que j'ai appliqué sur l'object réel qui m'a fait 
prendre conscience du problème:
Relation: Forêt sectionale des Besseyres (1175211)
La réalité administrative est telle que c'est bien des points (borne 
cadastrale) qui constituent la liaison entre les différentes parties de la 
forêt !

http://www.openstreetmap.org/?lat=45.5177&lon=3.6554&zoom=14&layers=M

En ce qui concerne l'exemple du bas, c'est le cas bien embarrassant des zones 
ferroviaires ou riverbank traitées en forme de relations ou il faut des ways 
qui se superposent (validateur n'aime pas) ou introduire des discontinuités 
pour permettre le rendu ! Topologiquement parlant, j'ai l'impression qu'il 
s'agit du même problème dans l'analyse et le traitement des graphes 



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

Re: [OSM-talk-fr] Support de presentation pour les elus locaux

[Nicolas Moyroud]

J'ai mon propre hébergement aussi, mais je voulais éviter de disperser l'information sur plusieurs serveurs pour les raisons de disponibilité, tracabilité... 
D'ailleurs, en ce qui concerne le Wiki, le problème suivant et la taille maximale pour un upload :

http://trac.openstreetmap.org/ticket/3324
  
Ah ok j'avais pas compris ça comme ça :-) 
Adresse de mon site : http://nmoyroud.teledetection.fr  Les supports OSM 
sont dans "Téléchargements > OpenStreetMap".



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

Re: [OSM-talk-fr] Support de presentation pour les elus locaux

[Olivier Croquette]

On 4 nov. 2010, at 10:11, Philippe Pary wrote:
> C'est facile de critiquer, je sais, mais je trouve que trop de temps est
> passé sur la technique et trop peu sur « en quoi ça peut m'aider ? »

Merci pour le retour !
Attention, ce n'est qu'un support, rien n'empêche de passer plus de temps sur 
un sujet ou un autre.
Mais tu entends quoi par "la technique" ?

> Par exemple, MapOSMatic mériterait bien 2-3 diapos, tout comme GéoVélo

Tu ajouterais quoi comme info ? Comment les utiliser ? Le but n'est que de 
donner un aperçu des possibilités. Pour aller plus loin, je considère qu'il 
faut consulter la documentation de l'outil en question.



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

Re: [OSM-talk-fr] Support de presentation pour les elus locaux

[Philippe Pary]

Le mercredi 03 novembre 2010 à 23:11 +0100, Olivier Croquette a écrit :
> On 23 oct. 2010, at 19:48, Croquette Olivier wrote:
> 
> > J'ai commencé à documenter les points qui me viennent à l'esprit sur le 
> > Wiki :
> > http://wiki.openstreetmap.org/wiki/WikiProject_France/Pr%C3%A9sentation_pour_les_%C3%A9lus
> > N'hésitez pas à compléter.
> > 
> > Par contre, pour la présentation finale, je compte faire ça avec 
> > OpenOffice, donc sur le Wiki et/ou en travail collaboratif ça va être plus 
> > dur.
> 
> Merci à tous ceux qui ont participé en mettant des idées sur la page.
> J'ai fini mon support la semaine dernière et présenté cela à un maire. 
> D'après le dialogue qui s'est mélangé à la présentation, je pense que 
> celle-ci était clair et qu'OSM a de l'avenir pour la commune, même si ça peut 
> mettre du temps avant de décoller.
> 
> J'ai mis le support en ligne sur la page :
> http://wiki.openstreetmap.org/wiki/WikiProject_France/Pr%C3%A9sentation_pour_les_%C3%A9lus



C'est facile de critiquer, je sais, mais je trouve que trop de temps est
passé sur la technique et trop peu sur « en quoi ça peut m'aider ? »

Par exemple, MapOSMatic mériterait bien 2-3 diapos, tout comme GéoVélo

Philippe


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

Re: [OSM-talk-fr] Support de presentation pour les elus locaux

[Olivier Croquette]

On 4 nov. 2010, at 09:48, Nicolas Moyroud wrote:

> Bonjour Olivier,

Salut !

> En attendant que le support du format odp soit ajouté sur le wiki, si tu le 
> souhaites je peux héberger ta présentation sur mon site. J'y ai déjà mis des 
> présentations et supports d'ateliers que j'ai fait sur OSM.
> D'ailleurs ça me fait penser qu'il faudra aussi que je les mette sur le 
> wiki...

J'ai mon propre hébergement aussi, mais je voulais éviter de disperser 
l'information sur plusieurs serveurs pour les raisons de disponibilité, 
tracabilité... 
D'ailleurs, en ce qui concerne le Wiki, le problème suivant et la taille 
maximale pour un upload :
http://trac.openstreetmap.org/ticket/3324

Quel est l'adresse de ton serveur au fait ?


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

Re: [OSM-talk-fr] Support de presentation pour les elus locaux

[Nicolas Moyroud]

Bonjour Olivier,

En attendant que le support du format odp soit ajouté sur le wiki, si tu 
le souhaites je peux héberger ta présentation sur mon site. J'y ai déjà 
mis des présentations et supports d'ateliers que j'ai fait sur OSM.
D'ailleurs ça me fait penser qu'il faudra aussi que je les mette sur le 
wiki...


Nicolas


Olivier Croquette a écrit :

J'ai mis le support en ligne sur la page :
http://wiki.openstreetmap.org/wiki/WikiProject_France/Pr%C3%A9sentation_pour_les_%C3%A9lus
  



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

Re: [OSM-talk-fr] Relation pour les lignes de bus et les directions

[Olivier Boudet]

Bonjour,

Merci pour vos réponses.

2010/11/4 Vincent Pottier 

> On 03/11/2010 23:16, Olivier Boudet wrote:
>
>> Bonjour,
>>
>> Je vois actuellement que la plupart (voire toutes) des lignes de bus de
>> Rennes sont dans OSM. En revanche, il y a une seule relation type=route pour
>> les deux sens de circulation du bus.
>> Ceci n'est pas utilisable pour du routing, puisque le bus ne prend pas
>> forcément la même route dans les deux sens. Exemple ici :
>> http://3liz.fr/public/osmtransport/index.php?country=France&location=Rennes<
>> http://3liz.fr/public/osmtransport/index.php?country=France&location=Rennes>
>> (ne regardez que la ligne 1). On se retrouve avec une relation qui fait une
>> boucle et qu'il est impossible d'ordonner.
>>
>>
>> J'avais donc en tête de modifier ces relations comme ceci :
>> - Créer une deuxième relation de chaque ligne, pour avoir une relation
>> unique par sens de circulation du bus
>>
> Et les regrouper dans une relation type 'line'
> Un exemple avec 4 routes (terminus différents)
> http://www.openstreetmap.org/browse/relation/538126
>
>
Cette solution me semble bien.


>  - Ajouter un tag direction="Chêne Germain" ou direction="Saint-Jacques"
>> (pour l'exemple de la ligne 1 de Rennes) en fonction du sens de circulation
>> - Splitter les rond-points pour ajouter uniquement les parties nécessaires
>> dans chaque route (pour distinguer quand un bus fait un 3/4 de tour de
>> rond-point)
>>
> Inutile. Un logiciel de routage bien fait sait trouver la portion de
> rond-point utilisée à partir du sens de circulation, du point d'entrée et du
> point de sortie.
> Après, le rendu... C'est une autre histoire. Mais on ne mappe pas pour le
> rendu ;-)
>
> Effectivement, cela me dérangeait aussi de découper les ronds-points. En
regardant l'exemple montré par Etienne, il ne me semble pas du tout gênant
de laisser les ronds-points complets et des les inclure entièrement dans la
relation. Comme vous l'avez dit, au logiciel de routage de se débrouiller
avec ces informations.

 - Ordonner les chemins de chaque relation pour avoir une route bien définie
>>
>> Mon problème dans cette idée était surtout le fait de splitter les
>> rond-points, mais une discussion (courte) sur talk semble aller dans ce sens
>> : http://www.mail-archive.com/t...@openstreetmap.org/msg12676.html
>>
>> Cela vous semble t-il correct, et utile ?
>> Olivier
>>
>
>
> ___
> 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] Relation pour les lignes de bus et les directions

[rldhont]

Bonjour,

En tant qu'auteur d'OSMTransport, je ne pense pas qu'il soit utile de 
créer une relation par sens de circulation et de les regrouper dans une 
relation ligne elle même faisant partie d'une relation réseau, etc...


Je pense en fait que tout ce qui est description complète de l'igne de 
transport en commun doivent être externaliser. Les relations de type 
route dans OSM servant de base au travail de description des lignes de 
transport en commun.


René-Luc D'Hont
3Liz

Le 03/11/2010 23:16, Olivier Boudet a écrit :

Bonjour,

Je vois actuellement que la plupart (voire toutes) des lignes de bus 
de Rennes sont dans OSM. En revanche, il y a une seule relation 
type=route pour les deux sens de circulation du bus.
Ceci n'est pas utilisable pour du routing, puisque le bus ne prend pas 
forcément la même route dans les deux sens. Exemple ici : 
http://3liz.fr/public/osmtransport/index.php?country=France&location=Rennes 
 
(ne regardez que la ligne 1). On se retrouve avec une relation qui 
fait une boucle et qu'il est impossible d'ordonner.


J'avais donc en tête de modifier ces relations comme ceci :
- Créer une deuxième relation de chaque ligne, pour avoir une relation 
unique par sens de circulation du bus
- Ajouter un tag direction="Chêne Germain" ou 
direction="Saint-Jacques" (pour l'exemple de la ligne 1 de Rennes) en 
fonction du sens de circulation
- Splitter les rond-points pour ajouter uniquement les parties 
nécessaires dans chaque route (pour distinguer quand un bus fait un 
3/4 de tour de rond-point)
- Ordonner les chemins de chaque relation pour avoir une route bien 
définie


Mon problème dans cette idée était surtout le fait de splitter les 
rond-points, mais une discussion (courte) sur talk semble aller dans 
ce sens : http://www.mail-archive.com/t...@openstreetmap.org/msg12676.html


Cela vous semble t-il correct, et utile ?
Olivier


___
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] styles qualitystreetmap.org - Serv eur de tuiles français

[Pierre Mauduit]

Hello,

>  
> Bien entendu, tout ça à vue de nez, le doigt mouillé et par grand
> vent...
> 
;-)

Juste pour info, on en est - avec notre visibilité actuelle - autour de
4 à 5 Go de transfert mensuel sur maps.qualitystreetmap.org ; (5.8 Go
pour septembre, 4.06 Go pour octobre).

-- 
Pierre



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