Le 05. 01. 18 à 18:09, pepilepi...@ovh.fr a écrit :
>> je relance le message car je pense que ce serrait utile d'aider ceux qui
>> se posent des questions sur leur contribution.
>> je retourne régulièrement voir ce qu'ils ont fait après mon message,
>> ceux qui continue à être actif ont
Pour moi c'est à éviter car ça fait dépendre ton rendu d'un service tiers
dont on ne contrôle pas la disponibilité.
Si les tuiles externes d'ombrage ou de courbe de niveau ne sont pas
dispo... on fait quoi ?
Un serveur de tuile doit fonctionner en autonomie. Sur un client, c'est
différent, tu
Le 04/01/2018 à 18:33, marc marc a
écrit :
Bonjour,
je relance le message car je pense que ce serrait utile d'aider ceux qui
se posent des questions sur leur contribution.
je retourne régulièrement voir ce qu'ils ont fait après mon message,
ceux qui continue à
Merci Christian pour ces précisions.
Donc l'idée c'est est d'avoir un MNT en local et une moulinette permettant
de le convertir à la volée en jolis tuiles rasters avec transparence, puis
bien configurer mapnik pour qu'il les utilise.
Mais là ça serait donc une solution propre, et du coup un peu
Le 30/12/2017 à 13:17, marc marc - marc_marc_...@hotmail.com a écrit :
> Bonjour,
>
> Le 30. 12. 17 à 13:01, Rodrigo Vivar a écrit :
>> - 5 395 "maxspeed:type"
>> - 63 480 "source:maxspeed"
>> wiki dit "maxspeed:type" en GB et "source:maxspeed" reste du monde
>> Regardant des "maxspeed:type"
Le 5 janvier 2018 à 20:21, Christian Quest a
écrit :
> Pour moi c'est à éviter car ça fait dépendre ton rendu d'un service tiers
> dont on ne contrôle pas la disponibilité.
>
> Si les tuiles externes d'ombrage ou de courbe de niveau ne sont pas
> dispo... on fait quoi ?
Le 05/01/2018 à 18:59, Vincent Frison a écrit :
Donc l'idée c'est est d'avoir un MNT en local et une moulinette
permettant de le convertir à la volée en jolis tuiles rasters avec
transparence, puis bien configurer mapnik pour qu'il les utilise.
C'est ce que fait le site
Le 05. 01. 18 à 20:43, Rodrigo Vivar a écrit :
> Le 30/12/2017 à 13:17, marc marc - marc_marc_...@hotmail.com a écrit :
> > Le 30. 12. 17 à 13:01, Rodrigo Vivar a écrit :
> > source:maxspeed est une aberration historique (cela entre en conflit
> > avec source:maxspeed=survey ou opendata ou
Le 4 janvier 2018 à 17:34, marc marc a écrit :
> Le 04. 01. 18 à 15:00, Philippe Verdy a écrit :
>
> Une première étape utile serrait donc d'avoir cette version partiellement
> intégrée à jour.
Certainement pas ! OSM ne fonctionne pas avec des imports même à jour
Il y a déjà de bons sites pour expliquer les règles compliquées des
adresses et surtout pour liste des fausses règles contredites par la
réalité.
Cela a été fait en anglais d'abord car on a presque tous les cas compliqués
au Royaume-Uni et toutes les exceptions. Un de ces auteurs est a été
Le 5 janvier 2018 à 20:43, Rodrigo Vivar a écrit :
> Le 30/12/2017 à 13:17, marc marc - marc_marc_...@hotmail.com a écrit :
> > Bonjour,
> >
> > Le 30. 12. 17 à 13:01, Rodrigo Vivar a écrit :
> >> - 5 395 "maxspeed:type"
> >> - 63 480 "source:maxspeed"
> >> wiki dit
Est-ce qu'il y a une solution pour obtenir un flux rss de ces changesets
sur une bounding box ?
Stf
Le 05/01/2018 à 18:19, marc marc a écrit :
Le 05. 01. 18 à 18:09, pepilepi...@ovh.fr a écrit :
je relance le message car je pense que ce serrait utile d'aider ceux qui
se posent des questions
Bonjour,
Pour info JOSM émet une alerte de validation si source:maxspeed n'est pas
saisi depuis peu de temps (je ne suis pas aller identifier la version) et
je ne pense pas que ce soit pour saisir : survey,knowledge,databaseXXX
Pour le moment je mets source:maxspeed et zone:maxspeed mais pas
Salut Donat,
Nous avons déjà essayé sans succès.
Le problème principal vient de la licence encore trop restrictive de l'IGN
et/ou du système mis en place pour respecter cette licence.
Pour plus de détails, il faut plonger dans l'historique des discussions
(principalement en anglais) :
Bonjour,
Le 4 janvier 2018 à 23:59, Philippe Verdy a écrit :
> IPv6 en ADSL chez Orange n'utilise pas de routage IPv6 natif
> (contrairement à la fibre) mais une encapsulation d'une tunnel IPv6 sur
> IPv4 et il semble que cela limite la taille des "MTU" aussi bien en TCP
>
- si ton adresse IPv6 Orange est en "2001::*" tu passes par un tunnel sur
IPv4, ce n'est pas natif (et oui, il y a une réduction de la MTU et
quelques problèmes liés à la fragmentation des paquets et la difficulté
pour les clients locaux à détecter la fragmentation)
- si ton adresse IPv6 Orange
Le 5 janvier 2018 à 11:19, François Lacombe a
écrit :
> Bonjour,
>
> Le 4 janvier 2018 à 23:59, Philippe Verdy a écrit :
>
>> IPv6 en ADSL chez Orange n'utilise pas de routage IPv6 natif
>> (contrairement à la fibre) mais une encapsulation d'une
Effectivement je peux comprend l'idée: sur osm.org il ne faudrait afficher
uniquement des données en provenance de la DB d'OSM.
Mais en fait l'argument d'une source données externe ne tient pas vraiment
puisqu'il y a déjà du hillshade sur le layer "carte cyclable" d'osm.org !
L'avantage du
Le 04. 01. 18 à 23:53, osm.sanspourr...@spamgourmet.com a écrit :
> une personne a vire le addr:housenumber parce que trop près de la
> voirie.
> http://www.openstreetmap.org/changeset/35942339
le problème est plus large que cela.
ce qu'on peux lui reprocher :
ses modifs sont incohérente avec le
C'est quelque chose que j'avais exploré pour le rendu FR... avec les
courbes de niveau.
Exemple: https://cl.ly/3u0J2p423J3M
Pour un rendu vraiment propre, il faut appliquer l'ombrage en 2 fois,
afin de ne pas trop ombrer certains objets comme les routes.
Il y a de l'ombrage sur certaines
Bizarre car chez moi ça marche sur la fibre Orange.
Le 5 janvier 2018 à 11:19, François Lacombe a
écrit :
> Bonjour,
>
> Le 4 janvier 2018 à 23:59, Philippe Verdy a écrit :
>
>> IPv6 en ADSL chez Orange n'utilise pas de routage IPv6 natif
>>
Marc, tu te trompe sur plusieurs points.
contact:* est documenté et l'était bien avant qu'on en parle ici. Il s'agit
bien d'indiquer pour un POI le moyen de le contacter, pas que via son
adresse. Séparer la définition de l'adresse et celle du POI est assez
logique.
Les deux schémas utilisé pour
Le 05/01/2018 à 14:04, Christian Quest a écrit :
> Peut être devrions nous mieux expliciter tout ça sur le wiki pour bien
> faire comprendre la logique des adresses, ce qu'elles sont et ne sont pas,
> etc.
En effet, ce serait vraiment une très bonne idée, car c'est vraiment
très complexe à
Il me semble que l'auteur de StreetComplete (application Android de
collecte et contribution) aurait besoin d'information sur les
pratiques "adresses" en France... de manière à décider si son
application devrait ou ne devrait pas proposer des modifications
concernant les adresses en France.
Voir
Pourquoi ne pas utiliser la localisation du nœud venant du cadastre (quand
il y est indiqué) ou d'un SIG open data local? C'est un bon compromis,
souvent déjà en bordure de parcelle, et pas lié aux exigences de la poste
pour le placement des boites aux lettres souvent déplacées loin du lieu et
Le 05/01/2018 à 15:53, Vincent Frison a écrit :
Le 5 janvier 2018 à 12:13, Christian Quest > a écrit :
C'est quelque chose que j'avais exploré pour le rendu FR... avec
les courbes de niveau.
Exemple:
Bonjour
Le 04/01/2018 à 20:02, Vincent Privat a écrit :
Le workaround pour ce problème est de positionner à "false" la
propriété "prefer.ipv6" dans les options avancées de JOSM.
je confirme que cela fonctionne, merci beaucoup !!!
Bonne journée
Vincent
Le 5 janvier 2018 à 12:13, Christian Quest a
écrit :
> C'est quelque chose que j'avais exploré pour le rendu FR... avec les
> courbes de niveau.
>
> Exemple: https://cl.ly/3u0J2p423J3M
>
Très joli !
> Pour un rendu vraiment propre, il faut appliquer l'ombrage en 2 fois,
On n'a pas fait comme ça du tout pour les communes ou les cantons :
l'automatisme est en fait plus que douteux pour ce genre de projet sachant
qu'on a des imprécisions évidentes et un gros travail de conflation à faire
pour recoller à l'existant. Alors non je n'ai jamais parlé d'import mais
bien
29 matches
Mail list logo