Re: [OSM-talk-fr] Rappel: appel à commentaires pou r relation:type=route_instruction
Histoire de ne pas parler en l'air, voici la vue aérienne de la jonction en question. Ça part d'en haut à gauche pour aller en bas à droite (de l'A15 vers la N315 et l'A86) http://maps.google.fr/maps?f=qsource=s_qhl=frq=A86,+Ile-de-Francesll=47.15984,2.988281sspn=14.972555,46.582031ie=UTF8cd=1geocode=Fbse6gIdgokhAAsplit=0ll=48.940233,2.293718spn=0.007061,0.022745t=hz=16 Le 4 févr. 09 à 08:18, murphy2712.nospam a écrit : au sein du segment C le nombre de files change. C'est que ton segment est mal découpé ! La jonction entre CDE doit être faite au milieu entre le début et la fin des pointillés. C'est à dire ? Je suis censé cartographier sans respecter la configuration réelle des routes ? et aussi du fait que dans le deuxième exemple, les panneaux de directions sont sur la partie à 4 voies et nécessite donc de donner des instructions depuis une partie qui ne se scinde que plus tard si tu suis la mortorway. Tout à fait, le moteur de routage peut très bien prendre la décision, 400m avant l'embranchement d'indiquer placer vous sur la file centrale/droite/gauche Oui mais une fois encore, comment devine-t-il où se trouve les panneaux pour donner l'information à temps ? C'est pourtant bien ce que font tous les logiciels de navigation, et même Navit qui tourne sur des cartes OSM. La distance d'annonce est fonction de la vitesse. Et l'annonce est souvent faite plusieurs fois, du genre dans 2 kilomètres..., dans 500m, tourner à droite (et là il y a une petite marge d'avance tout de même). S'il y a des changements rapprochés il suffit de l'intégrer à l'annonce d'avant : dans 500m tourner à droite, puis serrez à gauche. Je suis bien d'accord que le guidage se fait à l'avance et en fonction de la vitesse, le problème est que dans le cas qui nous intéresse, la configuration physique diffère de la configuration perçue/logique. Si tu vois un meilleur moyen d'exprimer cette information je suis preneur. Je ne dis pas que je le fais bien mais à l'heure actuelle il n'y a pas de moyen d'exprimer cette différence. Yann___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Achat tracker GPS
Merci pour les conseils sur les trackers! Je viens de commander un i-Blue 757 Pro Solar, pour le chip mtk et pour l'autonomie avec la cellule solaire. Je verrai... Steven disait : As-tu regardé du côté des mtr ? Je n'ai pas trouvé ça. Que c'est ? Gerhard --- Merci, Steven, des conseils pour l'OS. Tu as raison, l'idéal serait d'avoir un seul OS qui fait tout. Mais plusieurs de mes outils de travail n'existent pas en version Linux, j'ai besoin de XP et d'OSX. Pour simplifier la vie, je vise donc un nouveau mac, lequel fait les deux. tache 3d ? Rendu de scènes 3d avec Vue Infinite, reparti sur plusieurs ordinateurs. Renderfarm ils appellent ça. Je fait tout pareil... en graphique ou en console, mains dans le dos et yeux bandés s'il le faut. Chapeau, et tant mieux pour toi ! J'avais fait un essai avec Linux sur PC, mais je veux simplifier ma chaîne de travail, pas ajouter un troisième OS. Tu ne peux t'en prendre qu'à toi même si tu as des OS bancales ;) Oui, et j'en pleure dans mon casque, ou suis furax, selon... Gerhard --- Le 3 févr. 09 à 02:46, Steven Le Roux a écrit : 2009/2/3 g.d g...@wanadoo.fr: Ouaipch, nous macs sommes mal lotis ... ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Rappel: appel à commentaires pour relation:type=route_instruction
2009/2/4 Yann Coupin y...@coupin.net Histoire de ne pas parler en l'air, voici la vue aérienne de la jonction en question. Ça part d'en haut à gauche pour aller en bas à droite (de l'A15 vers la N315 et l'A86) http://maps.google.fr/maps?f=qsource=s_qhl=frq=A86,+Ile-de-Francesll=47.15984,2.988281sspn=14.972555,46.582031ie=UTF8cd=1geocode=Fbse6gIdgokhAAsplit=0ll=48.940233,2.293718spn=0.007061,0.022745t=hz=16 Le 4 févr. 09 à 08:18, murphy2712.nospam a écrit : au sein du segment C le nombre de files change. C'est que ton segment est mal découpé ! La jonction entre CDE doit être faite au milieu entre le début et la fin des pointillés. C'est à dire ? Je suis censé cartographier sans respecter la configuration réelle des routes ? Justement si, mais ce n'est pas ce qui est fait. La jonction doit être faite là où a lieu la séparation des voies. Si au sein du segment C le nombre de voies change alors il faut le scinder en 2 pour définir le changement du nombre de voies, c'est comme cela qu'on fait pour tout autre attribut qui n'est pas présent tout le long d'une voie. et aussi du fait que dans le deuxième exemple, les panneaux de directions sont sur la partie à 4 voies et nécessite donc de donner des instructions depuis une partie qui ne se scinde que plus tard si tu suis la mortorway. Tout à fait, le moteur de routage peut très bien prendre la décision, 400m avant l'embranchement d'indiquer placer vous sur la file centrale/droite/gauche Oui mais une fois encore, comment devine-t-il où se trouve les panneaux pour donner l'information à temps ? C'est pourtant bien ce que font tous les logiciels de navigation, et même Navit qui tourne sur des cartes OSM. La distance d'annonce est fonction de la vitesse. Et l'annonce est souvent faite plusieurs fois, du genre dans 2 kilomètres..., dans 500m, tourner à droite (et là il y a une petite marge d'avance tout de même). S'il y a des changements rapprochés il suffit de l'intégrer à l'annonce d'avant : dans 500m tourner à droite, puis serrez à gauche. Je suis bien d'accord que le guidage se fait à l'avance et en fonction de la vitesse, le problème est que dans le cas qui nous intéresse, la configuration physique diffère de la configuration perçue/logique. Si tu vois un meilleur moyen d'exprimer cette information je suis preneur. Je ne dis pas que je le fais bien mais à l'heure actuelle il n'y a pas de moyen d'exprimer cette différence. Scinder c en 2 pour ajouter l'information du changement de nombre de voies. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Rappel: appel à commentaires pour relation:type=route_instruction
Hello ! Merci de ta réponse ;-) Bref c'est excellent ;-) Normalement la couleur devrais être déduite du type de route de destination, quoi que... Par contre je me demande si dans l'exemple c (http://wiki.openstreetmap.org/wiki/Proposed_features/Relation:type%3Droute_instruction#Example_c) il ne faut pas ajourer le segment C comme via (comme c'est la cas dans les restrictions - http://wiki.openstreetmap.org/wiki/Relation:restriction#Members), je ne sais pas ci dans certain cas les logiciels de routage en auraient besoin ? CU Stéph 2009/2/3 Yann Coupin y...@coupin.net: Le 3 févr. 09 à 20:14, Stéphane Brunner a écrit : Pour moi c'est une très bonne base, j'ai juste pas compris a quoi servent les tags : to_n_directional_sign, to_n_phonetic_direction, to_n_phonetic_direction_format. Premièrement le n de chaque tag doit être remplacé par le numéro qui a été assigné à la highway de destination. On a donc plusieurs membres de la relation, la highway de provenance (from), et les highway de destination (to_1, to_2, to_3...) On a donc de 0 à 3 tags (puisque tous les tags qui nous concernent sont tous facultatifs) rattachés à chaque highway de destination. Par exemple to_1_directional pour l'attribut directional de la highway nº1 ou to_2_phonetic_direction pour l'attribut phonetic_direction de la highway nº2 Concernant maintenant le contenu de chaque attribut si c'est uniquement ça qui n'était pas clair. to_n_directional_sign: cet attribut est censé reprendre le texte des panneaux de direction, en général le nom de villes ou de lieux marquants to_n_phonetic_direction: est censé contenir le nom de la direction principale sous forme phonétique. Cette valeur n'a pas vocation a être affichée mais est présente pour les moteurs de synthèse vocale. Elle peut être exprimée au choix du cartographe soit en utilisant l'alphabet API (IPA en anglais), voir http://fr.wikipedia.org/wiki/Alphabet_phon%C3%A9tique_international ou en utilisant l'alphabet X-SAMPA, voir http://fr.wikipedia.org/wiki/X-SAMPA to_n_phonetic_direction_format: est là pour dire quel alphabet a été utilisé pour exprimer la représentation phonétique et peut contenir soit IPA soit X-SAMPA Par contre je trouverais bien de mettre le texte présent sur le panneau voire ça couleur, cela permettrai de faire de joli plan de route comme viamichelin. C'est une bonne idée mais je me demandais au départ si ça n'aurait pas dû être mis au niveau national. Après réflexion il y a tellement de types de panneaux que je me demande si leur couleur ne devrait pas en effet être stockée pour chaque panneau. Après reste la question du format. Doit on stocker uniquement deux codes couleurs, une pour le texte, une autre pour le fond. Dans quel format ? Pourquoi pas plutôt un bout de CSS ? À charge pour les logiciels de guidage de parser cette valeur du mieux qu'ils peuvent. Ou alors juste un nom de style avec une liste à étendre au sein du wiki. La discussion continue... Yann ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Stéphane Brunner mail : stephane.brun...@gmail.com messageries instantanées : stephane.brun...@gmail.com (http://talk.google.com) -- Non aux brevets logiciels http://stopsoftwarepatents.eu/banner/601000605319/ssp-468-96.gif http://stopsoftwarepatents.eu/601000605319 -- http://www.ubuntu-fr.org - Distribution Linux http://fr.wikipedia.org - Encyclopédie communautaire http://mozilla-europe.org - Navigateur internet / Client de messagerie http://framasoft.net - Annuaire de logiciel libre (gratuit) http://jeuxlibres.net - Jeux Libres (gratuit) http://openstreetmap.org - Cartographie libre (en développement) -- Il existe 10 sortes de personnes : celles qui connaissent le binaire, et les autres. -- Si un jour on te reproche que ton travail n'est pas un travail de professionnel, dis toi que : Des amateurs ont construit l'arche de Noé, et des professionnels le Titanic. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Rappel: appel à commentaires po ur relation:type=route_instruction
Scinder c en 2 pour ajouter l'information du changement de nombre de voies. Voilà comment il me semble que je ferais : http://slyserv.dyndns.org/osm/sorties.png 3 cas quand le conducteur vient du segment A : 1) Le conducteur veut aller en B le logiciel de navigation calcul qu'entre A et B il y a 2 files de moins. Il en déduit qu'il faut se trouver sur la 1ère ou 2ème à gauche (car en france on roule à droite) et que les deux autres vont partir 2) le conducteur veut aller en D Entre A et B 2 files continues, il propose alors de les éviter et propose de se retrouver soit sur la 1ère ou 2ème à droite avant la jonction J1 Il calcul un peu à l'avance et détermine que de C à D une seule file continue sur D, il proposera donc : Avant J1 restez sur la file de droite, après J1 mais avant J2 passer sur la fil de gauche. ( avec un peu de calcul à l'avance, il doit pouvoir déterminer qu'il fallait, dès le départ, rester sur la 2ème file de droite ) 3) le conducteur veut aller en E même raisonnement, mais après J1 et avant J2 il proposera de rester sur la file de droite Après, pour l'histoire des panneaux, ma foi, c'est un élément de terrain qu'on peut tagguer, on peu imaginer donc définir un POI que l'on place sur le way, qui aurait comme attribu ce qu'on veut (une couleur, un texte,...) le logiciel de navigation pourrait en ternir compte pour donner une directive 100m avant le panneau qui conforte alors le conducteur dans le choix de son GPS. On peut raffiner en donnant : highway=sign // c'est un panneau way_direction=yes // il est lisible dans le sens du chemin text:3=Chambéry 20 km \n Grenoble 80 km \n Valence 150 km // voici son texte sur la file n°3 bgcolor:3=blue textcolor:3=white text:2=Sortie n°18 Crolles 2000m // sur la 2 bgcolor:2=white textcolor:2=black text:1=Aire du grésivaudan 500m // sur la 1 bgcolor:1=blue textcolor:1=white Y'a moyen de faire une jolie usine, mais on va l'avoir notre mappy ;-) -- sly Sylvain Letuffe sylv...@letuffe.org qui suis-je : http://slyserv.dyndns.org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Robot MS BOT V1.3
Aurelien Jacobs a écrit : A part ça, quelques suggestion pour la prochaine version: 1ere = 1ère 2eme = 2ème '1ère' s'écrit '1re' et '2ème' s'écrit '2e'. L'idéal serait de mettre 're' et 'e' en exposant. Pour 'e', il existe le 'caractère' Unicode 1D49 ; pour 're', ça risque de poser un peu plus de problème. -- Emmanuel ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Rappel: appel à commentaires pou r relation:type=route_instruction
http://www.coupin.net/vrac/sorties.png Un petit dessin vaut mieux qu'un long discours ;-) j'y cogite Mais je me suis basé sur ton lien ici : http://slyserv.dyndns.org/osm/aerienne.jpg et c'est ce que j'ai tracé, mais bon, ok supposons ce nouveau cas. -- sly Sylvain Letuffe sylv...@letuffe.org qui suis-je : http://slyserv.dyndns.org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Robot MS BOT V1.3
2009/2/4 emmanuel emmanuel...@laposte.net: Aurelien Jacobs a écrit : A part ça, quelques suggestion pour la prochaine version: 1ere = 1ère 2eme = 2ème '1ère' s'écrit '1re' et '2ème' s'écrit '2e'. Grrr... Je pensais que le bot s'en tiendrait au minimum, c-à-d aux majuscules des premières lettres et les fautes vraiment évidentes. Avec ça et l'histoire des espaces, tirets, etc, on s'éloigne de plus en plus de ce que je vois sur les plaques de rues - et là, je ne suis plus d'accord. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Robot MS BOT V1.3
En même temps, ce ne sont que des suggestions... Si on n'est pas d'accord, il n'y a pas d'obligation de mettre ça en place. -- Marc On Wed, 4 Feb 2009 14:11:42 +0100, Pieren pier...@gmail.com wrote: 2009/2/4 emmanuel emmanuel...@laposte.net: Aurelien Jacobs a écrit : A part ça, quelques suggestion pour la prochaine version: 1ere = 1ère 2eme = 2ème '1ère' s'écrit '1re' et '2ème' s'écrit '2e'. Grrr... Je pensais que le bot s'en tiendrait au minimum, c-à-d aux majuscules des premières lettres et les fautes vraiment évidentes. Avec ça et l'histoire des espaces, tirets, etc, on s'éloigne de plus en plus de ce que je vois sur les plaques de rues - et là, je ne suis plus d'accord. 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] Rappel: appel à commentaires pou r relation:type=route_instruction
Le 4 févr. 09 à 13:08, sly (sylvain letuffe) a écrit : http://www.coupin.net/vrac/sorties.png Un petit dessin vaut mieux qu'un long discours ;-) j'y cogite Mais je me suis basé sur ton lien ici : http://slyserv.dyndns.org/osm/aerienne.jpg et c'est ce que j'ai tracé, mais bon, ok supposons ce nouveau cas. Sacré google, toujours prêt à faire une blague ! Ma carte était centrée ici au départ : http://maps.google.fr/maps?f=qsource=s_qhl=frgeocode=q=ie=UTF8t=kll=48.940698,2.292205spn=0.00334,0.010171z=17 Si en plus j'envoie pas les bonnes infos, on va pas y arriver... Yann ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Robot MS BOT V1.3
Pieren a écrit : Grrr... Je pensais que le bot s'en tiendrait au minimum, c-à-d aux majuscules des premières lettres et les fautes vraiment évidentes. Avec ça et l'histoire des espaces, tirets, etc, on s'éloigne de plus en plus de ce que je vois sur les plaques de rues - et là, je ne suis plus d'accord. Je pense qu'il ne s'agit pas seulement de recopier ce qui inscrit sur les plaques des rues. Dans ce cas, à certains endroits d'OSM, on verrait 'Clemenceau' et à d'autres 'Clémenceau' ; à certains endroits, on verrait 2ème, et à d'autres 2e. Ce qui compte avant tout, c'est la cohérence. Il faut se tenir à une seule façon d'écrire, et si possible, la façon correcte. Après tout, si quelqu'un a commis une faute d'orthographe (évidente) sur une plaque ou un panneau, notre rôle n'est pas de la reproduire mais plutôt de la corriger (à condition d'être sûr qu'il s'agit bien d'une faute). De toute façon, il est illusoire de reproduire exactement ce qui se trouve sur le terrain ; par exemple, j'ai déjà vu dans une rue une plaque 'Rue du Saule' et juste en tournant la tête 'Chemin du Saule'. Et tout ça dans la même rue... -- Emmanuel ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Rappel: appel à commentaires pou r relation:type=route_instruction
Je situe mal l'enjeu, pardon. La séparation du highway (à n ways) en plusieurs tracés distincts devrait être au début du trait continu blanc, voire à hauteur du panneau qui indique. A partir de là, un nav' devrait pouvoir faire son travail. Pour moi, les deux premiers croquis de la page seraient à taguer différemment. Dans le cas de gauche, un node pour la sortie suffit et la 2 voies continue, là ou dans le croquis de droite, la 3-voies s'est rétrécie en une 2-voies (probablement déjà bien à gauche, en dehors du dessin), et qu'au même node (de rétrécissement) commence une nouvelle voie, d'abord parallèle, qui ensuite prend une autre direction. Qu'on mette dans la bdd les choses qui sont, physiquement, ok. Mais des infos de choix d'itinéraires dans la bdd, je vois mal. Si avec une carte correcte, et la vitesse que calcule le gps, un nav' serait dans l'impossibilité topologique (math) d'avertir à temps, et par une combinaison appropriée, il faudrait revoir la (science de la) topologie de fond en comble. C'est au nav', de calculer. Si le conducteur prend la voie de gauche tout de suite, ou s'il traverse le trait blanc continu, il s'est gouré, tant pis pour lui, ne lui reste qu'à poser son téléphone et de jeter un coup d'oeil sur son gps nav' qui visuellement indique la piste à suivre. Vocal et visuel font un ensemble. Du guidage purement vocal sans visuel ne marche pas. Déjà aux rond-points, quand ça dit prenez la deuxième sortie à droite : S'ils ont intercalé une residential pour un lotissement qui n'est pas encore sur la carte, ou s'il y a des amorces prévisionnelles qui partent dans des champs, on est mal partis, là où sur le visuel on voit, qu'en réalité ça simplement continue tout droit, et ferme-la, la vocale. -- Qu'éventuellement, pour aider aux nav's, on mette des longueurs de tronçons de transition entre voies (tag à créer), ça irait encore, et quand plusieurs tronçons de transition partagent un même node, que le nav' commence à causer autrement, en phrases concatenées. -- Mais il me semble qu'un nav, en fonction de la vitesse et des distances devrait être capable de discriminer des situations de bifurcations rapprochées, sans qu'on mette des artifices dans la bdd. Ce n'est pas aux cartographes, de prévenir une éventuelle étourderie de l'utilisateur, soit-ce un humain, ou un logiciel nav'. Séparer. -- La question est là, il faudra y répondre, oui, mais je crains que l'approche par relations dans la bdd ne soit pas adéquate. On n'y est pour rien, nous, si parfois ils mettent les bifurcations tellement proches, qu'à 130 ça se chevauche. Pardon, si je n'aurais pas compris la question. Amicalement Gerhard --- Il me semble, que si on menait cette relation proposée de façon conséquente, à la fin on aurait dans la bdd une relation pour chaque itinéraire possible entre tous lieux, de Péta-aux-Chnoks à T'as-Mal-où-les Bains, et une autre pour le chemin inverse :-( Une méta-carte en sus. Comment entretenir et mettre à jour ça, de façon cohérente, si quelque chose change ? Nous ne sommes que quelques milliers de bénévoles :-( --- Le 4 févr. 09 à 13:15, Yann Coupin a écrit : Le 4 févr. 09 à 13:08, sly (sylvain letuffe) a écrit : http://www.coupin.net/vrac/sorties.png Un petit dessin vaut mieux qu'un long discours ;-) j'y cogite Mais je me suis basé sur ton lien ici : http://slyserv.dyndns.org/osm/aerienne.jpg et c'est ce que j'ai tracé, mais bon, ok supposons ce nouveau cas. Sacré google, toujours prêt à faire une blague ! Ma carte était centrée ici au départ : http://maps.google.fr/maps? f=qsource=s_qhl=frgeocode=q=ie=UTF8t=kll=48.940698,2.292205spn =0.00334,0.010171z=17 Si en plus j'envoie pas les bonnes infos, on va pas y arriver... Yann ___ 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] Robot MS BOT V1.3
Le 4 févr. 09 à 17:23, emmanuel a écrit : ai déjà vu dans une rue une plaque 'Rue du Saule' et juste en tournant la tête 'Chemin du Saule'. Et tout ça dans la même rue... Et alors ? (bel exemple...) Faut mettre les deux dans osm. C'est la réalité, qui a raison. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Rappel: appel à commentaires pou r relation:type=route_instruction
Le 4 févr. 09 à 12:27, sly (sylvain letuffe) a écrit : Scinder c en 2 pour ajouter l'information du changement de nombre de voies. Voilà comment il me semble que je ferais : http://slyserv.dyndns.org/osm/sorties.png Raté ! ;) Si c'était si simple on aurait pas besoin de la relation. Je la refais avec le bon nombre de voies. Corrections au bic vert ;) http://www.coupin.net/vrac/sorties.png 3 cas quand le conducteur vient du segment A : 1) Le conducteur veut aller en B le logiciel de navigation calcul qu'entre A et B il y a 2 files de moins. Il en déduit qu'il faut se trouver sur la 1ère ou 2ème à gauche (car en france on roule à droite) et que les deux autres vont partir 2) le conducteur veut aller en D Entre A et B 2 files continues, il propose alors de les éviter et propose de se retrouver soit sur la 1ère ou 2ème à droite avant la jonction J1 Il calcul un peu à l'avance et détermine que de C à D une seule file continue sur D, il proposera donc : Avant J1 restez sur la file de droite, après J1 mais avant J2 passer sur la fil de gauche. ( avec un peu de calcul à l'avance, il doit pouvoir déterminer qu'il fallait, dès le départ, rester sur la 2ème file de droite ) 3) le conducteur veut aller en E même raisonnement, mais après J1 et avant J2 il proposera de rester sur la file de droite Ça c'est la théorie... En pratique, c'est pas ça, cf l'image. Après, pour l'histoire des panneaux, ma foi, c'est un élément de terrain qu'on peut tagguer, on peu imaginer donc définir un POI que l'on place sur le way, qui aurait comme attribu ce qu'on veut (une couleur, un texte,...) le logiciel de navigation pourrait en ternir compte pour donner une directive 100m avant le panneau qui conforte alors le conducteur dans le choix de son GPS. On peut raffiner en donnant : highway=sign // c'est un panneau way_direction=yes // il est lisible dans le sens du chemin text:3=Chambéry 20 km \n Grenoble 80 km \n Valence 150 km // voici son texte sur la file n°3 bgcolor:3=blue textcolor:3=white text:2=Sortie n°18 Crolles 2000m // sur la 2 bgcolor:2=white textcolor:2=black text:1=Aire du grésivaudan 500m // sur la 1 bgcolor:1=blue textcolor:1=white Y'a moyen de faire une jolie usine, mais on va l'avoir notre mappy ;-) J'aime bien les namespace. Je suis tiède sur les noms de couleurs, ou alors à prendre la liste de couleurs de la spec CSS, par exemple, histoire d'avoir une liste un peu conséquente et également mettre une liste de noms de couleurs conseillées pour chaque pays dans la page de specs histoire d'éviter les variations chromatiques d'un cartographe à un autre. Je suis assez contre mettre la distance en dur par contre. Ça devrait être calculé... Yann ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Robot MS BOT V1.3
Le 04/02/2009 17:42, Renaud Martinet a écrit : Clair qu'OSM est sensé décrire la réalité, pas ce que les contributeurs pensent être OK. Et les panneaux sont censés représenter la réalité vraie ? Il y a des erreurs sur les panneaux. On a pas à les mettre dans OSM. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Robot MS BOT V1.3
Thomas je faisais référence aux corrections qui peuvent parfois être hasardeuses. Y'a aussi des panneaux qui ont des noms de rue avec des orthographes peu communes (comme Grand' Rue cité plus haut), je vois pas au nom de quoi on déciderait que c'est pas le vrai nom... De toute façon au bout du compte chacun fait ce qu'il veut. Renaud. 2009/2/4 Yann Coupin y...@coupin.net: Le 4 févr. 09 à 17:42, Renaud Martinet a écrit : Clair qu'OSM est sensé décrire la réalité, pas ce que les contributeurs pensent être OK. Je sais que ce que je vais dire a la couleur d'un troll et l'odeur d'un troll, mais ça n'en est pas un... Je me pose la question (et ceci est à mettre en relation avec la discussion sur ma feature proposal) de savoir si le rôle d'OSM est de décrire la réalité. J'explique. La réalité d'un rond-point c'est une route généralement circulaire avec plusieurs intersections. Pourtant dans OSM on rajoute bien l'info comme quoi la perception de la route pour les humains est un rond-point. Est-on toujours dans la réalité ou dans la perception ? Je me suis tapé un peu de specs GDF hier (GDF - http://en.wikipedia.org/wiki/Geographic_Data_Files) . Et pour qui regarde, il est clair que les gens qui bossent là dessus on prit le parti de séparer géométrie et perception. On peut bien sûr se dire que chez OSM on a pas grandi avec les œillères des vieux cartographes et qu'on est plus malins, mais je pense quand même qu'on peut apprendre quelque chose en regardant comment font les pros (le GDF est un standard ISO). Yann ___ 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] Robot MS BOT V1.3
Marc SIBERT a écrit : En même temps, si je trouve un conseil municipal assez pervers pour nommer une rue Rue du Grand Ru, sachant que c'est imprononçable et qu'un ru, par définition est une petite rivière... on leur fera couper la tête ! J'ai supprimé la règle de l'apostrophe + espace. -- Marc Bonsoir, Il y en aura toujours un pour être assez vicieux pour nous faire un coup pendable de ce genre. Pour troll Petite rue du Grand Ru ;) Amitiés -- Yannick VOYEAUD http://www.voyeaud.org Créateur CimGenWeb: http://www.francegenweb.org/cimgenweb/ Actes En Vrac: http://www.francegenweb/actes/ Cercle Généalogique (EGE-PTT): http://www.cercle-genealogique.fr Inconnu de Saulcy: http://www.lced.org Antoine Payet de la Réunion: http://payet.voyeaud.org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Robot MS BOT V1.3
Yannick a écrit : Marc SIBERT a écrit : En même temps, si je trouve un conseil municipal assez pervers pour nommer une rue Rue du Grand Ru, sachant que c'est imprononçable et qu'un ru, par définition est une petite rivière... on leur fera couper la tête ! J'ai supprimé la règle de l'apostrophe + espace. -- Marc Bonsoir, Il y en aura toujours un pour être assez vicieux pour nous faire un coup pendable de ce genre. Pour troll Petite rue du Grand Ru ;) Amitiés P'tit' Rue du Grand Ru -- Marc No virus found in this outgoing message. Checked by AVG - http://www.avg.com Version: 8.0.176 / Virus Database: 270.10.17/1933 - Release Date: 03/02/2009 17:48 ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] [MS BOT V1.3] Début des tes ts de la V1.3
Bonsoir, Une page qui fait un point sir l'accentuation des capitales, avec un exemple de nom de [r|R]ue : http://j.poitou.free.fr/pro/html/typ/cap-accents.html Art. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Robot MS BOT V1.3
On Wednesday 04 February 2009 20:55:27 Marc SIBERT wrote: Ok ! J'ai compris vos messages. Je me démerde autrement. Z'avez remarqué aujourd'hui pas de disclaimer Merci Par contre il reste toujours le message de AVG :) -- Vincent MEURISSE ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [MS BOT V1.3] Début des test s de la V1.3
Encore moi... Il me semble avoir compris que le robot souhaite changer les janvier en Janvier. Si j'ai bien compris, je pense que c'est une erreur. En français, les noms de jour et de mois ne prennent pas de majuscule : « mardi 25 janvier » (Jacques André – Petites leçons de typographie, http://jacques-andre.fr/faqtypo/lessons.pdf, page 18). Ceci dit, bravo et merci pour ce robot de normalisation. Art. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] riverbank
Bonsoir, Est ce que quelqu'un spécialiste des rivières (ou non) peut regarder pourquoi les iles (correspondant à des écluses) sur le lien suivant ne sont que de l'eau (il y en a plusieurs). http://www.informationfreeway.org/?lat=47.845304583546934lon=-0.19318154982545982zoom=14layers=BF000F PS : il faut regarder tout le bout de rivière car j'ai presque tout fait donc l'erreur peut venir de n'importe où mais je comprend pas. Nota : c'est peut être un pb de rendu mais j'ai fait des demandes de maj sur ifw et ça ne change pas -- Etienne ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [MS BOT V1.3] Début des test s de la V1.3
On Wed, Feb 4, 2009 at 10:17 PM, arp enteur art.pent...@gmail.com wrote: Encore moi... Il me semble avoir compris que le robot souhaite changer les janvier en Janvier. Si j'ai bien compris, je pense que c'est une erreur. En français, les noms de jour et de mois ne prennent pas de majuscule : « mardi 25 janvier » (Jacques André – Petites leçons de typographie, http://jacques-andre.fr/faqtypo/lessons.pdf, page 18). Ceci dit, bravo et merci pour ce robot de normalisation. Art. Salut Art.penteur, Il ne faut confondre règles générales de typographie et règles qui s'appliquent à la toponymie (pourquoi faire simple quand on peut faire compliqué ..). Tous les noms communs et noms propres doivent prendre une majuscule. Voir les liens déjà donnés ici sur la commission nationale de toponymie ainsi que certains rapports de la commission toponymie de l'IGN qui fait référence. Mais il y a des exceptions, etc... Je n'ai pas noté de différence de traitement pour les mois de l'année (http://www.ign.fr/adminV3/display/000/526/725/5267258.pdf) Ceci dit, l'article que tu pointes est très intéressant et montre que même chez les typographes, les règles sont aussi très fluctuantes suivant l'endroit et l'époque où elles se sont appliquées.. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] riverbank
On Wed, Feb 4, 2009 at 11:22 PM, Etienne Chové ch...@crans.org wrote: Bonsoir, Est ce que quelqu'un spécialiste des rivières (ou non) peut regarder pourquoi les iles (correspondant à des écluses) sur le lien suivant ne sont que de l'eau (il y en a plusieurs). Salut Etienne, amha, ça vient du fait que tu as une relation multipolygon pour plusieurs polygones. Ton découpage de la rivière est bon mais il faut que tu fasses une relation par section de rivière (un seul outer) et une relation uniquement aux endroits où il y a des îlots. Mais comme là, il y a plein de inner's et de outer's, les logiciels de rendu risquent de pédaler dans la semoule. En principe, tu ne devrais avoir qu'un seul way en outer (voir http://wiki.openstreetmap.org/wiki/Relation:multipolygon). Il est bien prévu que la relation multipolygon supporte plus-tard plusieurs polygones dans une relation (suivant la proposition de F. Rahm pour pouvoir remplacer la relation boundary) mais je ne crois pas que ce soit déjà le cas aujourd'hui. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Nouvelle version du plugin JOSM cadastre-fr (13546) (0.9)
Bonsoir, La nouvelle version 13546 (0.9) du plugin cadastre-fr apporte les changements suivants: - avec l'aide de Frederic Rodrigo et de son script dont j'ai pu m'inspirer, il est maintenant possible d'importer en un clic la limite administrative extérieure d'une commune. Un way est créé et le nombre de noeuds est réduit grâce à l'algorithme SimplifyWay copié d'un autre plugin (utilsPlugin). La position de la vue principale n'a pas d'importance. Il faut juste avoir le bon calque WMS activé. Il faut ensuite taguer puis sectionner/fusionner les ways aux bordures voisines manuellement mais c'est déjà un travail fastidieux en moins. - le problème du tag source=cadastre... activé dans le menu mais qu'on ne veut pas ajouter (clic no à la question) n'empêche plus le transfert des données comme auparavant. Prochaine étape: - l'import des building sur la vue en cours (le faire sur toute la commune en une fois ne semble pas possible, la vue d'ensemble présentant les bâtiments de manière incomplète - à étudier) Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Nouvelle version du plugin JOSM cadastre-fr (13546) (0.9)
Oups, 'faut que je vois ça... J'étais juste en train de tracer la limite de mon patelin, d'après moults importations depuis le cadastre, ce qui a poussé josm dans les orties... (C'est où, qu'on donne plus de mem à josm, sur un mac OSX ? 64 mégas, c'est un peu faiblard, quand on a des gigs) Gerhard Le 5 févr. 09 à 01:19, Pieren a écrit : Bonsoir, La nouvelle version 13546 (0.9) du plugin cadastre-fr apporte les changements suivants: - avec l'aide de Frederic Rodrigo et de son script dont j'ai pu m'inspirer, il est maintenant possible d'importer en un clic la limite administrative extérieure d'une commune. Un way est créé et le nombre de noeuds est réduit grâce à l'algorithme SimplifyWay copié d'un autre plugin (utilsPlugin). La position de la vue principale n'a pas d'importance. Il faut juste avoir le bon calque WMS activé. Il faut ensuite taguer puis sectionner/fusionner les ways aux bordures voisines manuellement mais c'est déjà un travail fastidieux en moins. - le problème du tag source=cadastre... activé dans le menu mais qu'on ne veut pas ajouter (clic no à la question) n'empêche plus le transfert des données comme auparavant. Prochaine étape: - l'import des building sur la vue en cours (le faire sur toute la commune en une fois ne semble pas possible, la vue d'ensemble présentant les bâtiments de manière incomplète - à étudier) 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] Nouvelle version du plugin JOSM cadastre-fr (13546) (0.9)
Sur Mac, je sais pas. Pour Windows, un p'tit batch de ce genre marche bien (vu sur le Wiki) : C:\WINDOWS\system32\java.exe -jar -Xmx512M C:\JOSM\josm.jar Antoine g.d a écrit : Oups, 'faut que je vois ça... J'étais juste en train de tracer la limite de mon patelin, d'après moults importations depuis le cadastre, ce qui a poussé josm dans les orties... (C'est où, qu'on donne plus de mem à josm, sur un mac OSX ? 64 mégas, c'est un peu faiblard, quand on a des gigs) Gerhard Le 5 févr. 09 à 01:19, Pieren a écrit : Bonsoir, La nouvelle version 13546 (0.9) du plugin cadastre-fr apporte les changements suivants: - avec l'aide de Frederic Rodrigo et de son script dont j'ai pu m'inspirer, il est maintenant possible d'importer en un clic la limite administrative extérieure d'une commune. Un way est créé et le nombre de noeuds est réduit grâce à l'algorithme SimplifyWay copié d'un autre plugin (utilsPlugin). La position de la vue principale n'a pas d'importance. Il faut juste avoir le bon calque WMS activé. Il faut ensuite taguer puis sectionner/fusionner les ways aux bordures voisines manuellement mais c'est déjà un travail fastidieux en moins. - le problème du tag source=cadastre... activé dans le menu mais qu'on ne veut pas ajouter (clic no à la question) n'empêche plus le transfert des données comme auparavant. Prochaine étape: - l'import des building sur la vue en cours (le faire sur toute la commune en une fois ne semble pas possible, la vue d'ensemble présentant les bâtiments de manière incomplète - à étudier) 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 ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Nouvelle version du plugin JOSM cadastre-fr (13546) (0.9)
Mr Pieren, je proteste quant à la release de ce plugin. En effet, chaque matin, il m'était appréciable de mapper une petite ville du coté de chez moi et d'admirer mon travail après 15 à 20 bonnes minutes de click click intempestif. C'était sans compter sur votre acharnement pour mon petit plaisir quotidien. Plus de syndrome du canal carpien, plus de raideur dans le cou, non Monsieur ! Aujourd'hui je trouve une machine capable de me remplacer en 1 clic de souris. Certes il me reste quelques 'c' et 'm' à presser sur le clavier mais la joie de boucler une ville n'est plus la même sans ce travail de click que j'effectuais auparavant. Ma vie est déjà peu rempli, si en plus des personnes s'acharnent à me remplacer par des machines, on se demande où va le monde. C'était un message du CCC, le Comité Contre le Cadastre (pas la peine de dire que c'est du 2nd degré et que c'est un bonheur sans nom, tout le monde avait compris :)) Yann Bonsoir, La nouvelle version 13546 (0.9) du plugin cadastre-fr apporte les changements suivants: - avec l'aide de Frederic Rodrigo et de son script dont j'ai pu m'inspirer, il est maintenant possible d'importer en un clic la limite administrative extérieure d'une commune. Un way est créé et le nombre de noeuds est réduit grâce à l'algorithme SimplifyWay copié d'un autre plugin (utilsPlugin). La position de la vue principale n'a pas d'importance. Il faut juste avoir le bon calque WMS activé. Il faut ensuite taguer puis sectionner/fusionner les ways aux bordures voisines manuellement mais c'est déjà un travail fastidieux en moins. - le problème du tag source=cadastre... activé dans le menu mais qu'on ne veut pas ajouter (clic no à la question) n'empêche plus le transfert des données comme auparavant. Prochaine étape: - l'import des building sur la vue en cours (le faire sur toute la commune en une fois ne semble pas possible, la vue d'ensemble présentant les bâtiments de manière incomplète - à étudier) 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] Nouvelle version du plugin JOSM cadastre-fr (13546) (0.9)
D'ailleurs Antoine devrait se plaindre d'ici quelques instants car on se demande ce qu'il va bien pouvoir faire au boulot maintenant :) Yann Bonsoir, La nouvelle version 13546 (0.9) du plugin cadastre-fr apporte les changements suivants: - avec l'aide de Frederic Rodrigo et de son script dont j'ai pu m'inspirer, il est maintenant possible d'importer en un clic la limite administrative extérieure d'une commune. Un way est créé et le nombre de noeuds est réduit grâce à l'algorithme SimplifyWay copié d'un autre plugin (utilsPlugin). La position de la vue principale n'a pas d'importance. Il faut juste avoir le bon calque WMS activé. Il faut ensuite taguer puis sectionner/fusionner les ways aux bordures voisines manuellement mais c'est déjà un travail fastidieux en moins. - le problème du tag source=cadastre... activé dans le menu mais qu'on ne veut pas ajouter (clic no à la question) n'empêche plus le transfert des données comme auparavant. Prochaine étape: - l'import des building sur la vue en cours (le faire sur toute la commune en une fois ne semble pas possible, la vue d'ensemble présentant les bâtiments de manière incomplète - à étudier) 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] Nouvelle version du plugin JOSM cadastre-fr (13546) (0.9)
Yann SLADEK a écrit : Mr Pieren, je proteste quant à la release de ce plugin. En effet, chaque matin, il m'était appréciable de mapper une petite ville du coté de chez moi et d'admirer mon travail après 15 à 20 bonnes minutes de click click intempestif. C'était sans compter sur votre acharnement pour mon petit plaisir quotidien. Plus de syndrome du canal carpien, plus de raideur dans le cou, non Monsieur ! Aujourd'hui je trouve une machine capable de me remplacer en 1 clic de souris. Certes il me reste quelques 'c' et 'm' à presser sur le clavier mais la joie de boucler une ville n'est plus la même sans ce travail de click que j'effectuais auparavant. Ma vie est déjà peu rempli, si en plus des personnes s'acharnent à me remplacer par des machines, on se demande où va le monde. C'était un message du CCC, le Comité Contre le Cadastre Sinon, il te reste les centaines de milliers de feuilles non vectorielles ;-) Denis PS : Bravo Pieren, j'ai hâte de tester ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Nouvelle version du plugin JOSM cadastre-fr (13546) (0.9)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 /me applaudit des 2 mains ! /me regrette encore le bug sur l'affichage en blanc au lieu de noir ;) /me se demande si il faut bien (obligatoire ?) utiliser lambert zone comme système ? Bonne journée Pieren a écrit : Bonsoir, La nouvelle version 13546 (0.9) du plugin cadastre-fr apporte les changements suivants: - avec l'aide de Frederic Rodrigo et de son script dont j'ai pu m'inspirer, il est maintenant possible d'importer en un clic la limite administrative extérieure d'une commune. Un way est créé et le nombre de noeuds est réduit grâce à l'algorithme SimplifyWay copié d'un autre plugin (utilsPlugin). La position de la vue principale n'a pas d'importance. Il faut juste avoir le bon calque WMS activé. Il faut ensuite taguer puis sectionner/fusionner les ways aux bordures voisines manuellement mais c'est déjà un travail fastidieux en moins. - le problème du tag source=cadastre... activé dans le menu mais qu'on ne veut pas ajouter (clic no à la question) n'empêche plus le transfert des données comme auparavant. Prochaine étape: - l'import des building sur la vue en cours (le faire sur toute la commune en une fois ne semble pas possible, la vue d'ensemble présentant les bâtiments de manière incomplète - à étudier) Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr - -- Patrice Vetsel ubu...@kagou.fr Aka/Alias Kagou https://launchpad.net/people/vetsel-patrice gpg key: 0x15c094db -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkmKj9oACgkQAGLykBXAlNvViACfcLt8UQpDcNBp5ITCujch3RHN 6TkAnjHzxp8NqzXd/8aLef7Xynj2boek =3XsR -END PGP SIGNATURE- ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
