Le 28 juillet 2015 00:39:02 CEST, JB a écrit :
>La station Luxembourg, si ma mémoire est bonne, n'accueille que du RER
>?
>En tant que non-parisien, j'aurais du mal à comprendre pourquoi elle
>n'aurait pas son subway_entrance à elle, son entrée n'est pas bien
>différente des autres stations du
ssi précisé que si ça peut être utile on peut ajouter mais à part
(dans le sens moins visible car moins pertinent) les données.
Ton name:equals_default=, c'est ce que je dis dans "Bien-sûr un champ de
bits suffit pour dire indiquer dans une tuile vectorielle les noms
identiques au nom lo
Le 26/07/2015 22:33, osm.sanspourr...@spamgourmet.com a écrit :
Je n'ai jamais dit de ne pas garder les tags qui sont différents.
name:br=Pariz, on garde !
Je dis juste que
name:de=Paris (qui existe actuellement dans la base) n'a pas grand intérêt.
Comme je crois l'avoir déjà dit, ton système m
t abandonne le
projet lie a la complexité du système. C'est plus complique que de
rajouter des points d’intérêts.
* L'autre solution est un rendu purement vectoriel comme le projet de
Google en WebGL ce qui est généralement horriblement lent.
Bref, il ne faut pas s'attendre a ce
Bien trouvé pour cet article du Dauphiné, qui confirme le placement de
la station météo dans la zone contestée. Peut-être y a-t-il eu des
discussions informelles avec la France, mais l'article de l'ARPA Valle
d'Aosta
(http://www.arpa.vda.it/index.php?option=com_flexicontent&view=items&id=2320:2
re, la zone devrait
être intégrée du côté italien.
Moi je dis ça, mais je ne dis rien...
Le 24 juil. 2015 à 18:55, Thierry Bézecourt a écrit :
Des Italiens viennent d'installer une station météo au sommet, "sul versante
italiano della montagna"
(http://www.adnkronos.com/soste
1) Oui, et les valeurs multiples pour le champ "name" sont recommandées par
http://wiki.openstreetmap.org/wiki/Multilingual_names#Shared_boundary_features
"Always add name:code=* for each involved language, and for
compatibility with older rendering engines, also set name=* to both
names, separ
En fait, c'est encore plus complexe. D'après l'IGN
(http://geoportail.fr/url/7FcKIT), une partie de la zone contestée, au
sud de la crête reliant le Mont Blanc et le Mont Blanc de Courmayeur,
est une enclave de Saint-Gervais-les-Bains et non une partie de Chamonix...
cf. aussi https://fr.wikip
Des Italiens viennent d'installer une station météo au sommet, "sul
versante italiano della montagna"
(http://www.adnkronos.com/sostenibilita/world-in-progress/2015/07/21/clima-installata-sul-monte-bianco-stazione-meteo-piu-alta-europa_vLuRsXdg0AjMFy7TFfXLBM.html).
Elle a été ajoutée sur OSM auj
Très bien. Le résultat de la discussion méritera tout de même d'être mis
quelque part sur le wiki, car c'est l'endroit le plus visible pour la
plupart des contributeurs.
Et ce serait bien de signaler le lancement de cette discussion sur
talk-it (ce que peut sans doute faire celui qui l'a lancé
Tout à fait d'accord avec la suggestion de porter la discussion sur le
wiki. Les listes de diffusion ont peu de mémoire et sont difficiles d'accès.
Les pages de discussion du wiki sont l'une des grandes forces de
Wikipédia, car on peut y voir de manière organisée les discussions qui
ont eu lie
Le 18/07/2015 00:39, Eric Sibert a écrit :
OSM a une position officielle (
http://wiki.osmfoundation.org/wiki/Policies_and_other_Documents ) que
l'on peut résumer ainsi : l'envahisseur a toujours raison. [...]
Ici, il semble que la France occupe le sommet en pratique. [...]
Je ne suis pas no
OSM a une position officielle (
http://wiki.osmfoundation.org/wiki/Policies_and_other_Documents ) que
l'on peut résumer ainsi : l'envahisseur a toujours raison. Ou, en termes
plus OSM-corrects : on cartographie en fonction du terrain, donc on
attribue le territoire au pays occupant.
Ici, il s
Oui, et on pourrait même supprimer carrément la bounding box car la
condition sur la relation limite les résultats de manière équivalente
(d'ailleurs la ligne C est, sauf erreur, entièrement en Île-de-France).
De plus, il me semble que le tilde (présente dans le lien sur Overpass)
ralentit la
ça n'est pas à la portée du premier venu... Exemple
(indice : c'est de l'anglais) :
| "@Up@n stri:t m{p s bIlt baI @ k@"mju:nIti @v m{p "drA:p@rz D@t
k@n"trIbju:t @nd meIn"teIn "deIt@ @"baUt r@Udz | treIlz | "k{feIz |
"reIlweI "
1. FONIPA{"alphabet phonétique international"}
2. FONUPA{"alphabet phonétique ouralique"}
name:fonipa est valable pour une traduction international
name:fr-fonipa pour la France en respect à laRFC 5646
<https://tools.ietf.org/html/rfc5646>
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
1, Otourly Wiki a écrit :
Ou qu'il n'y a tout simplement pas de données à afficher ;)
Florian
Le Vendredi 12 juin 2015 16h26, Thierry Bézecourt a
écrit :
Excellent outil (j'ai essayé la version PC) !
Cela m'a incité à commencer le premier mapping indoor en Corée (pard
Excellent outil (j'ai essayé la version PC) !
Cela m'a incité à commencer le premier mapping indoor en Corée (pardon,
hors sujet sur cette liste...) et ça fonctionne de manière impeccable.
J'ai parfois un message du genre "There is no available data in this
area" ou "An error occurred during
Le 26/05/2015 05:39, Pierre-Yves Berrard a écrit :
Ça fonctionne avec &accept-language=fr dans l'adresse.
Intrigant (peut-être un problème de données derrière quand même).
C'est sans doute une question à poser sur le forum développeurs de
Mapquest, afin de pouvoir corriger les données d'OpenS
20 matches
Mail list logo
