Autre problème avec cette analyse osmose: on avait utilisé jusque
maintenant ref=* et pas ref:FR:LaPoste...
- le rapprochement fait pas osmose ne semble pas se faire (ou alors la
tolérance de distance est insuffisante).
- les formulaires de JOSM prennent en compte ref=*
- on va avoir un mix entre l
question bête
vous avez pris en compte que le mode de projection varie en fonction des points
enregistrés ?
bon j'y connais pas grand chose alors je ne sais pas quelle influence ça a
mais une grosse partie du fichier utilise ESPG :2154
puis ont trouve quelques EPSG :2975 et EPSG :102113
Le 25 ju
Le 27/06/2015 09:49, Christian Quest a écrit :
Autre problème avec cette analyse osmose: on avait utilisé jusque
maintenant ref=* et pas ref:FR:LaPoste...
- le rapprochement fait pas osmose ne semble pas se faire (ou alors la
tolérance de distance est insuffisante).
- les formulaires de JOSM pren
Les latitudes, longitudes sont également présentes. Mais pour l'instant
l'analyse ne tourne que sur le serveur qui traite la France métropolitaine.
Le 27/06/2015 10:26, erwan salomon a écrit :
question bête
vous avez pris en compte que le mode de projection varie en fonction des
points enregist
Le 26/06/2015 19:39, Jérôme Seigneuret a écrit :
En effet, j'ai trouvé ça dans la partie /general ponctuation/ de la
table utf-8
Voici les codes
Unicode Caractère UTF-8 encodage HTML name
U+2160
Ⅰ 226133160 Ⅰ ROMAN NUMERAL ONE
U+2161 Ⅱ 226133161
Salut,
Tous les caractères affichés dans la table marche en copier/coller si tu
veux. Tu peux copier le tableau et le mettre sous open-office par exemple
pour l'avoir en local (hors connexion) et copier/coller les chiffres que tu
souhaites utiliser.
Ce sont les vrai chiffres romain et non des let
De l'un côté ça me plaît, car maintenant c'est clair sans ambiguïtés que ce
ne sont pas des lettres. De l'autre côté ça signifie que chaque client
doit réinterpréter chaque fois de nouveau pour déterminer la valeur. Un tag
supplémentaire pourrait remédier cela.
On Jun 27, 2015 3:01 PM, "Jérôme Sei
J'ai fait l'essaie. J'ai mis un chiffre romain dans le nom d'une petite
rue. Je vais voir ce que ça donne en terme de rendu, de recherche du nom
de la rue et de guidage. Je vous tiens au courant.
Eric
___
Talk-fr mailing list
Talk-fr@openstreetmap.or
Le mieux est parfois l'ennemi du bien.Les chiffres créent des problèmes
d'ambiguïté ? Une succession de lettres est elle un mot ou un nombre ?
A priori c'est un mot.
Essayez d'écrire "Jean XXIII" et "Henri IV" ou encore "Louis XIV" sur une
feuille de papier libre.
Examinez ensuite si la graphie
Bonjour,
En ce qui concerne les chiffres romains, je vois mal comment une
détection automatisée pourrait fonctionner. Quelle expression régulière
pourra-t-elle deviner que "George V" utilise un chiffre romain mais pas
"Avenue D" (à Manhattan), "Quai C" ou "Escalier I" ?
Exemple : cette requ
Le rendu "QA" qui permet de visualiser les zones où il manque
potentiellement des routes et des bâtiments en comparant données OSM et
données carroyées de l'INSEE ne se mettait plus à jour correctement depuis
quelques temps.
Je viens (enfin) de corriger ça, et les premiers niveaux de zooms (6 à 11
Bonjour,
(attention c'est long)
Le 27/06/2015 13:53, Frédéric Rodrigo a écrit :
Le 27/06/2015 09:49, Christian Quest a écrit :
Je ne vois non pas trop l'intérêt non plus du addr:postcode sur la boite
aux lettres.
Ça ne peut pas faire de mal.
Ça n'est pas parce que c'est fourni dans la sou
Le 27/06/2015 17:37, Vincent de Château-Thierry a écrit :
Bonjour,
(attention c'est long)
Le 27/06/2015 13:53, Frédéric Rodrigo a écrit :
Le 27/06/2015 09:49, Christian Quest a écrit :
Je ne vois non pas trop l'intérêt non plus du addr:postcode sur la boite
aux lettres.
Ça ne peut pas fair
Le 27/06/2015 17:54, Frédéric Rodrigo a écrit :
Je trouve que tu fait à l'intégration le même procès que à l'import.
L'intégration n'a de sens que si entre le clic de souris et la chaise il
y un cerveau, je suis d'accord. Mais c'est justement pour cela que l'on
passe par une intégration et non
@Thierry : Tu as résumé le fond du problème.
Je n'ai pas encore traité du X-SAMPA mais j'ai plus l'impression que c'est
un parallèle ASCII de l'IPA Unicode
d'ailleurs il y a des types phonétiques qui sont dans X-SAMPA et qui ne
sont pas dans l'IPA
J'ai pas encore trouvé une seule valeur utilisant
je pense qu'en résonnant comme ça, il faut supprimé pas mal des intégration
possible dans osmose. exemple, les pharmacies, les stations services, même
les écoles, c'est pas toujours facile de savoir ce que c'est su la photo
aérienne (parce que c'est bien ça le problème, que la photo aérienne ne
nou
Non tu te plantes deux fois. car la RFC que tu cites qui n'est qu'elle
version et une partie de BCP 47, fait référence a son enregistrement comme
variante dans un label de langue.
"Fonapi" ne peut donc pas être utilisé seul et pas en tant que premier
sous-label d'un label de langue. Un peu DD rech
Pour info
Il y a une valeur avec *fonetic*
https://taginfo.openstreetmap.org/search?q=fonetic
Un peu plus avec *phonetic*
https://taginfo.openstreetmap.org/search?q=phonetic
;-)
Le 27 juin 2015 18:19, Jérôme Seigneuret a écrit
:
> @Thierry : Tu as résumé le fond du problème.
>
> Je n'ai pas
Bref aucune erreur dans waikipedua c'est bien toi qui te plantes même en
allant a la source que tu n'as pas lue ou pas comprise...
Le 27 juin 2015 18:22, "Jérôme Seigneuret" a
écrit :
> @Thierry : Tu as résumé le fond du problème.
>
> Je n'ai pas encore traité du X-SAMPA mais j'ai plus l'impressi
A noter dans vos agendas !
La 3e Opération Libre, après Brocas en 2013 et Gérardmer en 2014, aura
lieu à Chéméré en Loire-Atlantique, du 25 au 27 septembre 2015. Elle est
organisée par l'association Libertic et le Conseil Général de
Loire-Atlantique. L'association OpenStreetMap France sera pré
En France on parle français(Une seule langue officielle) dans tout les cas
donc fr ou fr_FR comme français de France. Le problème n'est pas là.
Bref c'est pas une mauvaise interprétation est c'est utilisé comme tel dans
les API et dans le système Android (système sur lequel est installé OsmAnd)
J
On notera également que Mapillary continue a jouer le jeu en publiant un
article sur son blog :
http://blog.mapillary.com/update/2015/06/25/josm-mapillary.html
Le 24/06/2015 14:10, Stéphane Péneau a écrit :
Hello tous !
Pour ceux qui ne sont pas au courant, un plugin pour afficher les
photos
Le 27 juin 2015 19:15, Jérôme Seigneuret a écrit
:
> En France on parle français(Une seule langue officielle) dans tout les cas
> donc fr ou fr_FR comme français de France. Le problème n'est pas là.
>
Le problème est que tu restreint le tag seulement à la France alors qu'il
est dans le monde enti
Le 27 juin 2015 19:15, Jérôme Seigneuret a écrit
:
> Bref c'est pas une mauvaise interprétation est c'est utilisé comme tel
> dans les API et dans le système Android (système sur lequel est installé
> OsmAnd)
>
Android utilise les tags BCP47 standards, sauf pour la nomination interne
des fichier
Cet exemple d application je l aurais bien vu a base de donnees OSM. Je pense
que la FFRP a du faire du micro-mapping pour recenser les
obstacleshttps://fr.news.yahoo.com/gps-guider-aveugles-randonn%C3%A9e-143514508.html
___
Talk-fr mailing list
Talk-fr
Le 27/06/2015 18:24, Jérôme Amagat a écrit :
je pense qu'en résonnant comme ça, il faut supprimé pas mal des
intégration possible dans osmose. exemple, les pharmacies, les stations
services, même les écoles, c'est pas toujours facile de savoir ce que
c'est su la photo aérienne (parce que c'est b
Le 28/06/2015 01:19, Jérôme Seigneuret a écrit :
J'ai pas encore trouvé une seule valeur utilisant le tag name:fr-fonapi
et le fameux codage BCP47
Bien sûr, parce qu'OpenStreetMap utilise des tags aux noms simples et
compréhensibles. Personne n'utilisera des balises aux noms aussi abscons
qu
Le 28 juin 2015 00:58, Thierry Bézecourt a écrit :
> Le 28/06/2015 01:19, Jérôme Seigneuret a écrit :
>
>>
>> J'ai pas encore trouvé une seule valeur utilisant le tag name:fr-fonapi
>> et le fameux codage BCP47
>>
>
> Bien sûr, parce qu'OpenStreetMap utilise des tags aux noms simples et
> compréh
Merci pour ces explications détaillées qui m'aident à mieux comprendre
BCP47.
Mais l'un des problèmes que rencontre Wikipédia actuellement, c'est que
le code wiki est devenu trop compliqué, au point apparemment de rebuter
de nombreux utilisateurs. Donc ils ont développé un éditeur visuel, qui
oui mais en comparant:
name:fr-fonipa
et
name:phonetic:fr
lequel est le plus "simple" d'après toi ?
Et demandera le moins de travail spécifiqure pour gérer les exceptions aux
règles BCP47 qui sont déjà implémentées dans des bibliothèques partagées et
qui ne demandent pas dêtre maintenaues sép
30 matches
Mail list logo
