Le 29 novembre 2012 00:24, Jo winfi...@gmail.com a écrit :
J'utilise également le tag route_ref, car il est facile à remplir quand on
est sur place et il aide à faire un contrôle de qualité.
J'utilise aussi le tag route_ref pour noter lors de relevé sur le terrain
les lignes qui passent par
Nommer un landuse me semble la moins mauvaise solution si j'ai bien compris
le besoin (une résidence).
Pour une résidence, un landuse=residential + name=*
Même principe pour une zone industrielle, zone commerciale, etc.
Les relations c'est bien mais il ne faut pas en abuser... si l'on peut
Rester simple pour le plus grand nombre ne veut pas dire qu'ils *doivent*
saisir les bons caractères sémantiques (le tiret cadratin est sémantique,
et PAS typographique, il sépare deux entités complètement différentes et
non liées, il résoud des ambiguités dans le cas où un des noms séparés de
la
La pseudo-règle typographique que tu propose n'est qu'une heuristique, elle
s'avère fausse dans de trop nombreux cas. Ne parle pas de typographie quand
tu ne sais pas ce que c'est et que tu généralise beaucoup trop vite ce qui
te semble simple dans ton petit monde. Ton point de vue simple est
On 28 nov. 2012, at 19:20, Pieren pier...@gmail.com wrote:
Si on veut distinguer deux entités, on peut aussi bien
mettre des espaces avant et après le tiret pour lever toute ambiguité
(Maisons-Alfort - Stade est assez clair).
Ce compromis me semble tout à fait acceptable car il résout à la
Roland à déjà mentionné qu'il serait très content si quelqu'un étend le
plugin public_transport sur la liste josm-dev.
L'avantage supplémentaire est que l'on peut utiliser les autres classes
disponibles en JOSM pour travailler avec les données OSM, ce qui devrait
rendre le travail plus facile.
Oui mais la question n'est pas celle des zones résidentielles ou
commerciales ou industrielles : elles incluent par définition tout ce qui
est dedans (même s'il y a des bois, jardins, constructions, routes, cours
d'eau, voies ferrées, parkings...).
Ce n'est pas le cas des autres landuse=* (et
Salut,
Le 29 novembre 2012 00:24, Jo winfi...@gmail.com a écrit :
J'étais en train de commencer le développement de quelque chose de
comparable. En outre de détecter des erreurs, moi j'envisageais de faire
une détection automatiques d'arrêts. Pour cela je voulais répérer tous les
arrêts dans
Pas pour Paris - Bruxelles - Brussels... Le tiret n'a pas le même sens,
il n'y a pas 3 entités mais 2 :
Est-ce 'Paris - Bruxelles et Brussels, ou bien Paris et Bruxelles -
Brussels.
Faut-il alors écrire Bruxelles / Brussels pour avoir Paris - Bruxelles /
Brussels et est-ce moins ambigu ?
Faut-il
Ah, la question qui tue, et que je craignais de voir arriver ! :-)
Petite histoire :
Lorsque je me suis lancé dans ce projet, c'est parce que je déclarais les
lignes de bus Twisto, dans l'agglomération caennaise. Le nombre de lignes
augmentant, j'ai vite réalisé à quel point ça allait devenir
Bof, est-ce qu'un néophyte de la typo aura plus tendance à écrire «
Maisons-Alfort - Stade » que « Maisons-Alfort--Stade » ou «
Maisons-Alfort-Stade » ? Il ne comprendra pas plus la différence entre «
Maisons-Alfort - Stade » et « Maisons-Alfort-Stade » qu'entre «
Maisons-Alfort - Stade » et «
Il ne faut peut-être pas forcément l'ajouter à ce plugin. Peut-être c'est
mieux de l'ajouter aux tests du validateur? Si ce que tu envisages c'est
simplement un contrôle de qualité (comme c'est conçu maintenant) c'est
l'endroit indiqué.
Si tu l'envisages comme 'assistant' pour améliorer/créer les
On 29 nov. 2012, at 09:56, JB jb...@mailoo.org wrote:
Bof, est-ce qu'un néophyte de la typo aura plus tendance à écrire «
Maisons-Alfort - Stade » que « Maisons-Alfort—Stade » ou «
Maisons-Alfort-Stade » ? Il ne comprendra pas plus la différence entre «
Maisons-Alfort - Stade » et «
On 29 nov. 2012, at 09:47, Philippe Verdy verd...@wanadoo.fr wrote:
Pas pour Paris - Bruxelles - Brussels... Le tiret n'a pas le même sens, il
n'y a pas 3 entités mais 2 :
Est-ce 'Paris - Bruxelles et Brussels, ou bien Paris et Bruxelles -
Brussels.
Faut-il alors écrire Bruxelles /
Je n’ai pas l’habitude de rentrer dans des sujets chauds aussi tôt dans la
conversation… Mais comme je me sens un peu visé par le sujet — en effet,
j’utilise la typographie française aussi précisément que je peux — je me
permets d’intervenir en faveur du cadratin.
Et je ne vois pas le problème à
Oui cela pourrait être une bonne façon d'entrer les données dans la base,
le / serait alors un séparateur de liste et - représenterait l'union.
Ensuite libre au moteur de rendu d'afficher ça de la bonne manière.
Attention, le caractère « / » a sa propre signification. Et pour les
On Thu, 29 Nov 2012 11:09:38 +0100
Mikaël Cordon mikael.cor...@gmail.com wrote:
Je n’ai pas l’habitude de rentrer dans des sujets chauds aussi tôt dans la
conversation… Mais comme je me sens un peu visé par le sujet — en effet,
j’utilise la typographie française aussi précisément que je peux —
On 29 nov. 2012, at 11:15, Mikaël Cordon mikael.cor...@gmail.com wrote:
Oui cela pourrait être une bonne façon d'entrer les données dans la base, le
/ serait alors un séparateur de liste et - représenterait l'union.
Ensuite libre au moteur de rendu d'afficher ça de la bonne manière.
@Vladimir : je suis d’accord que mon exemple n’était pas le plus réfléchi,
il est limite puisqu’effectivement les abréviations ne sont pas souhaitées.
Ceci dit, il y a beaucoup de choses non souhaitées dans la base OSM :).
Surtout ce que je voulais soulever, c’est que les caractères ont une
On 29/11/2012 11:09, Mikaël Cordon wrote:
Je n’ai pas l’habitude de rentrer dans des sujets chauds aussi tôt
dans la conversation…
Pourquoi se priver d'alimenter une si jolie polémique ?
[..] D’autre part, on a souvent entendu à propos de la base OSM
qu’elle doit être, d’une part uniforme,
2012/11/29 Jean-Marc Liotier j...@liotier.org:
Pour name le problème est différent : nous devons concilier la raison locale
avec la compatibilité mondiale par le plus petit dénominateur commun. C'est
à mon avis là que se situe le débat.
+1
N'adopter les pratiques locales dans le global que
On 29/11/2012 11:40, Mikaël Cordon wrote:
Surtout ce que je voulais soulever, c’est que les caractères ont une
signification bien établie ; et qu’il est dommage et risqué quant à en
changer le sens localement. Pourquoi ne pas utiliser directement le
bon caractère ?
Il y a presque vingt ans,
On 29/11/2012 11:59, Jean-Marc Liotier wrote:
L'ère de l'ignorance de la diversité linguistique a durablement
formaté une génération à choisir l’appauvrissement au nom de la
compatibilité, canalisée en cela par les outils qui ont formé nos
habitudes. Il est plus que temps de ré-apprendre et de
Je suis entièrement d’accord du point de la séparation donnée/rendu.
Le but du jeu c’est de pouvoir comprendre la donnée de façon univoque !
On sait que tant que ce seront des humains qui saisiront des données dans
la base, il y aura des erreurs. Et les erreurs sont d’autant plus
nombreuses
Ce qui se complique encore quand les toponymes ***officiels*** espagnols
utilisent le / pour séparer les noms ***co-officiels*** issus de
plusieurs langues, ces deux langues ***devant*** toujours être citées
ensembles et dans l'ordre indiqué sans qu'on puisse en supprimer un ! C'est
alors le même
Le problème est le même : le name=* est, tout comme le name:fr=* un nom
destiné à être lu par des humains, il a une langue (parfois plusieurs dans
le même nom quand elles sont co-officielles). On ne peut pas deviner cette
langue ici et ce peut tout autant être le français. Ce qu'on ne peut pas
+1000.
D'autant plus qu'aujourd'hui il n'y a plus aucun problème technique lié
aussi bien à leur rendu qu'à leur exploitation par des outils automatiques
qui *peuvent* simplifier à la volée quand ils le souhaitent mais *pas*
rétablir une précision perdue ou oubliée (là il n'y a qu'un humain qui
Je serai bref.
Il serait intéressant de partir plutôt un débat sur l'utilisation intensive de
mots anglais, de développer les logiciels uniquement en anglais et leur donner
des noms anglais. Soudain les français veulent passer inaperçus. C'est Paris
qui rêve d'être New-York ou San-Francisco.
Drôle de position quand même les américains ont compris l'intérêt de
l'Unicode et le soutiennent maintenant massivement (au point même d'avoir
réussi à l'imposer même à la Chine qui voulait GB18030 à la place mais ne
l'a imposé en plus d'Unicode que chez elle). Les américains d'ailleurs ne
parlent
Le message suivant de yaga37:
##
Bonjour,
J'aimerais savoir si je peux utiliser pour un site cette petite application et
si c'est possible de la lancer à partir d'une autre ville que Paris
http://lizpoi.3liz.com/demo/index.php/lizpoi/map/?tree_id=1
Merci
a été
Le message suivant de JP Guido:
##
Bonjour,
J’ai découvert OSM grâce au conseil de développement du nouveau PNR de
pré-alpes d’azur Lors d’une réunion à La Penne.
Je me suis mis au travail dans mon village : ajout de sentiers, escaliers,
routes restaurants etc. …
J’ai un problème avec
On 29 nov. 2012, at 12:45, Philippe Verdy verd...@wanadoo.fr wrote:
Ce qui se complique encore quand les toponymes ***officiels*** espagnols
utilisent le / pour séparer les noms ***co-officiels*** issus de plusieurs
langues, ces deux langues ***devant*** toujours être citées ensembles et
Bonjour,
Supprimer les tirets, et même le reste des caractères, des limites
territoriales ne me dérange pas, pour la simple raison que les
enchevêtrements de niveaux rendent trop compliqué la possibilité d'un
nommage clair. (Comment nommer un bout de frontière de niveaux 2, 4, 6 et 8
à la fois
On 29 nov. 2012, at 15:30, JB jb...@mailoo.org wrote:
Le 29.11.2012 15:13, Vladimir Vyskocil a écrit :
Il faut également prendre en compte tous les outils de recherche qui vont
faire comment pour se dépatouiller avec des données formatés avec des
demi-espaces insécables ou je ne sais
Se dépatouiller avec des bizarreries… On se demande ce qui est bizarre ou
ce qui est normal.
Il faut savoir que certaines (un certain nombre) implémentations de la
reconnaissance de motifs par expressions régulières dans le monde UTF-8 (en
perl, php, extension SQL et sûrement d’autres langages)
2012/11/29 Mikaël Cordon mikael.cor...@gmail.com:
Et j’insiste sur le fait qu’il serait une erreur d’imposer l’utilisation de
ces fameux caractères, puisque tout le monde ne les connaissent pas, et ne
peuvent les saisir !
Mais dès lors qu’ils enrichissent les données et qu’ils peuvent être
Non on ne veut pas 2 noms séparés, c'est un seul et même nom contenant deux
éléments.
Et les moteurs de recherche n'ont strictement aucun problème avec ces
caractères qui ne sont pas des curiosités françaises mais présents par
défaut dans de nombreux protocoles, supportés par des encodages
Parce que ces fichiers RATP sont anciens et ont été développés en un temps
où on ne prenait même pas garde de préserver les accents sur les majuscules.
Et ce n'est pas non plus parce que certains ne savent pas taper un É ou un
œ qu'on ne va s'interdire d'en mettre, et encore moins les remplacer
And the winner is
OSMtransport, 1er pour la catégorie accessibilité.
http://openstreetmap.fr/3liz-osmtransport
--
Christian Quest - OpenStreetMap France -
http://openstreetmap.fr/u/cquesthttp://openstreetmap.fr/u/christian-quest
___
Talk-fr
J'ai vu sur cette news http://openstreetmap.fr/3liz-osmtransport que 3liz
avait été primé pour son démonstrateur : bravo a vous !
Je suis allé voir sur le site et il est dit que le résultat définitif sera
demain, on anticipe sur la délibération ? ^^
Christian par contre il manque l'URL dans la
Je viens de voir l'annonce au moment même où est arrivé ton mail
Florian. :-)
Félicitations à 3LIZ, vous le méritez plus que bien !
Nicolas
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr
Je viens de voir qu'il y avait un petite erreur dans l'adresse du lien
données brutes sur la page d'accueil du site openstreetmap.fr
http://dev.www.openstreetmap.fr/donnees-brutes
devrait être
http://www.openstreetmap.fr/donnees-brutes
Nicolas
___
Je sais que les données eau ont été retirées des exports vectoriels
cadastre et je trouve ça très bien qu'on ne puisse pas accéder
directement à ces données. Il y en a qui faisait vraiment n'importe quoi
avec ça... Mais j'aimerai savoir quelle est la procédure à suivre pour
pouvoir demander
Oui, moi aussi ça me manque, aussi bien pour les piscines que pour les
rivières et les plans d'eau.
J'adaptais les tags mais au moins ça évitait de les tracer.
Le 29 novembre 2012 18:31, Nicolas Moyroud nmoyr...@free.fr a écrit :
Je sais que les données eau ont été retirées des exports
Envoyé de mon iPad
Le 29 nov. 2012 à 16:57, Philippe Verdy verd...@wanadoo.fr a écrit :
Non on ne veut pas 2 noms séparés, c'est un seul et même nom contenant deux
éléments.
Oui c'est ce que j'ai dit un nom multi-valué que le moteur de rendu pourra
très bien afficher nom1 – nom2 par
On jeudi 29 novembre 2012, Cavok wrote:
Oui, moi aussi ça me manque
Le 29 novembre 2012 18:31, Nicolas Moyroud nmoyr...@free.fr a écrit :
Mais j'aimerai savoir quelle est la procédure à suivre pour pouvoir
demander ces données.
Ces données ne sont pas dispo, mais tout peut changer.
Comme
Le temps-réel n'est pas encore dans la culture de l'IGN ;)
En direct depuis la remise des prix: un tweet avec photo, un article sur le
site OSM-FR, une news sur la page FaceBook... j'ai même des vidéos que je
vais partager si elles ne sont pas trop affreuses. On avait (heureusement)
du wifi sur
Merci ! Corrigé
Le 29 novembre 2012 17:46, Nicolas Moyroud nmoyr...@free.fr a écrit :
Je viens de voir qu'il y avait un petite erreur dans l'adresse du lien
données brutes sur la page d'accueil du site openstreetmap.fr
Felicitation 3liz !
Vous le meritez bien, les gens a qui je montre OSMTransport trouvent souvent le
concept tres sympa :-)
Julien
De : Florian LAINEZ winner...@free.fr
À : Discussions sur OSM en français talk-fr@openstreetmap.org
Envoyé le : Jeudi 29
Le 29 novembre 2012 19:25, Vladimir Vyskocil
vladimir.vysko...@gmail.coma écrit :
Le 29 nov. 2012 à 16:57, Philippe Verdy verd...@wanadoo.fr a écrit :
Non on ne veut pas 2 noms séparés, c'est un seul et même nom contenant
deux éléments.
Oui c'est ce que j'ai dit un nom multi-valué que le
A priori on devrait avoir Saint-Médard-sur-Ille aussi, bizarrement pas
associé avec Rennes Carte ou Verte quand les communautés de communes se
touchent (Le site de Rennes pourtant mentionne les autres cartes des autres
communautés d'Ille-et-Vilaine).
Rien à voir avec Besançon (qui ne marche pas
Bruxelles est en plus bien mieux desservi et sera aussi apprécié des
Anglais qui ont des choses à montrer.
C'est un bon nœud TGV et reste pratique aussi pour ceux de la Fondation
Wikimedia qui viendraient des USA. Sinon pour les Français comme pour les
Anglais c'est l'avion, et ce n'est pas le
L outil a travaille sur les diffs France du 26 Novembre 2012 14h38 jusqu
a maintenant ( soit quasiment 3 jours )et il en ressort le rapport
attache en piece jointe dont voici un petit resume :
environ 130 modifications effectuees par 5 utilisateurs :
olcomm_ild_inr, botdidier2020, kritic, Eric S,
Bonjour,
Le 28/11/2012 18:29, te...@free.fr a écrit :
Champs-Élysées — Clemenceau (avenue des Champs-Élysées, place Clemenceau)
si je suis d'accord sur le principe, il reste possible aux tenants de la
simplicité (et ça aussi c'est bien, mangez-en) d'utiliser des tirets
simples
Le 28/11/2012 15:47, partir-en-vtt a écrit :
Ils sont dynamiques ces hauts saônois !
Oui. Ils ont la (haute-)patate !
--
Jean-Francois Nifenecker, Bordeaux
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
bravo à l'équipe de 3Liz !
Le 29 novembre 2012 20:02, THEVENON Julien julien_theve...@yahoo.fr a
écrit :
Felicitation 3liz !
Vous le meritez bien, les gens a qui je montre OSMTransport trouvent
souvent le concept tres sympa :-)
Julien
--
*De :* Florian
Bonjour,
BrunoC wrote
Sinon faudrait internationaliser l'interface ;-)
Chiche ! Maintenant il y a un fichier de traductions à éditer:
https://gitorious.org/nomino/nomino/blobs/gettext/locale/fr_FR.utf8/LC_MESSAGES/default.po
L'outil Poedit peut aider pour cela.
--
View this message in
À la demande générale, j'ai uploadé une version de mon appli, sous la forme
d'un fichier
.jarhttps://github.com/windu2b/OSM_checkTransportRelations/downloads
Francescu
Le 29 novembre 2012 10:12, Jo winfi...@gmail.com a écrit :
Il ne faut peut-être pas forcément l'ajouter à ce plugin.
Le 30 novembre 2012 02:04, Francescu GAROBY windu...@gmail.com a écrit :
À la demande générale, j'ai uploadé une version de mon appli, sous la
forme d'un fichier
.jarhttps://github.com/windu2b/OSM_checkTransportRelations/downloads
C'est beaucoup mieux ! Mais...
/home/herve java -jar
Heuuu... du XML au milieu des champs name ??? Franchement non (même si le
shéma OSM peut être exporté en XML, ce n'est définitivement pas la seule
option. Voire du XML natif importé dans une base OpenGIS et supposer que
les moteurs de rendus ou d'analyse devront en plus réanalyser du XML n'est
pas
Même pour un export de données OSM en XML cela ne marche pas comme tu le
crois, cela donnera un truc du genre:
tag key=name value=nom1 lt;tiretQuadratin id=quot;58901:AI97quot;
class=quot;onTiretQuadratinquot; lang=quot;FR-frquot;/gt; nom2 /
au lieu de:
tag key=name value=nom1 – nom2 /
Heu... Philippe, je voulais surtout plaisanter avec cette histoire de tiret
quadratin en XML, je m'excuse que ça n'ait pas été clair. C'était par
rapport au flot de messages sur ce sujet, fort intéressant d'ailleurs, mais
l'énormité des discussions pour un simple caractère me semblait propice à
Salut,
Merci tout d'abord de bien vouloir tester.
Pour la relation que tu as testée, c'est une 'route_master' : elles ne sont
pas encore prises en compte, mais c'est
prévuhttps://github.com/windu2b/OSM_checkTransportRelations/issues/3!
:-)
Si tu veux un numéro de relation à tester, sur la page
Je goûte particulièrement cet humour, surtout quand il sert mes arguments
(en faveur de la logique de la hache).
Montre l'avion, l'imbécile regarde le doigt !
Ps : je laisse volontairement le message original
--
Marc Sibert
m...@sibert.fr
Le 30 nov. 2012 08:15, Ista Pouss ista...@gmail.com a
64 matches
Mail list logo
