Bonjour,
Je l'ai signalé le 18 juillet dernier à Christian Quest (cf ci-dessous)
Le problème est apparu suite à la relance du serveur du rendu FR.
Oups... je regarde d'où ça vient, car les requêtes SQL n'ont pas
changé et la feuille de style non plus.
Sûrement un effet de bord inattendu
Bonjour
Le 10/08/2018 à 23:30, lenny.libre a écrit :
faut-il descendre de vélo pour suivre ce chemin, prendre la route ?
légalement oui
quels attributs mettre ?
cela redevient un traditionnel trottoir donc
highway=footway
footway=sidewalk
Cordalement
--
David Crochet
email séparé pour éviter la noyade avec les autres problèmes :)
ultra résumé pour ceux qui n'ont pas envie de tous lire :
- il y a des bugs en cours de résolution tant sur le rendu osm.org
que sur le rendu osm-fr
- faire un /dirty sur les zoom faible ne sert a rien car ignoré
- les zooms faible
Bonsoir,
Il y a une piste https://www.openstreetmap.org/way/229173276
en arrivant au sud, se trouve un panneau de type C114 indiquant la fin
d'une voie conseillée et réservée aux cyclistes
https://www.mapillary.com/map/im/B_fw7x1IdkUKD4J3IQaRyQ
La piste reprend au fond (dans la zone
Le 11. 08. 18 à 00:23, marc marc a écrit :
> les 2 serveurs ok : Yevaud et Vial
> les 2 serveurs affectés : Scorch et Rhaegal
arf cela concernait le bug osm2pgsql
et non la saturation des files des serveurs de rendu
___
Talk-fr mailing list
Le 10. 08. 18 à 10:58, Jérôme Seigneuret a écrit :
> https://b.tile.openstreetmap.org/18/135336/92001.png
> dernière modification 2018-08-10 10:43:09
> Satut de la tuile : Tile is Clean.
> La date du dernier rendu correspond à la date de modification.
> avec l'heure en UTC
> y a t-il un problème
> le serveur utilisé actuellement dépend de la position géographique
> principalement mais peux aussi changer en cas de surcharge,
> info vérifiable en temps réel avec
> https://tile.openstreetmap.org/cgi-bin/debug
> les 2 serveurs ok : Yevaud et Vial
> les 2 serveurs affectés : Scorch et Rhaegal
Il toutefois que la synchro des diffs est basée sur les dates rapportées
par https://tile.openstreetmap.org/cgi-bin/debug
Il n'est pas clairement précisé dans ce "debug" comment est calculée cette
date : est-ce une date "UTC" ou une date locale ? Sachant que les
déménagement d'un serveur de
Voir aussi cette page de doc de wget au sujet des "timestamps".
https://www.gnu.org/software/wget/manual/html_node/Time_002dStamping-Usage.html
Et la note concernant FTP:
https://www.gnu.org/software/wget/manual/html_node/FTP-Time_002dStamping-Internals.html#FTP-Time_002dStamping-Internals
Le
Une piste à propos de Wget (voir http://www.gnu.org/software/wget/) qui
indique :
"Uses local file timestamps to determine whether documents need to be
re-downloaded when mirroring"
Note: "wget" peut utiliser HTTP ou FTP, mais les serveurs FTP sont connus
pour ne pas afficher la date UTC mais
Le 09/08/2018 à 23:28, Philippe Verdy - verd...@wanadoo.fr a écrit :
les rendus d'OSM France ou Allemagne ou Mapquest ne sont pas impactés ici
Tu peux préciser ?
Que je regarde le serveur français :
http://a.tile.openstreetmap.fr/osmfr/12/2013/1429.png
ou allemand :
Bonjour
Les rendus des terrains de sport semblent incohérent (rotation de 90° ):
http://tile.openstreetmap.fr/?zoom=18=49.17863=-0.37182=B00FF
Cordialement
--
David Crochet
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
Salut,
Ca reprend ce que je disais sur mes modifications.
Carto DE pas de problème,
corto osm.fr pas de problème
carto .org: problème de mise à jour de tuile aléatoire et traitement sur
zone mal pris en charge pour les mises à jour > affichage des landuse
incohérent pareil pour les noms quels
Je me lance, je tente des pistes :
amenity=childcare
childcare:FR=accueil_enfants_parents
social_facility:for=parents
min_age=*
max_age=6
supervised=yes
… ?
-- althio
On Thu, Aug 9, 2018, 23:55 deuzeffe wrote:
> Bonsoir,
>
> Les LAEP (ou parfois LAPE) sont des structures (~ 1500 )
@djakk all object are area but that don't make sens use it in database
because data are an abstraction.
area is documented!
highway are in model linestring but in other context it is as an area so
highway area are forced with area=yes to map this object. there is no other
solution to set an
Je confirme et c'est partout. Et pas un problème de rafraîchissement ;
certainement un bogue dans la formule de calcul d'angle (ou un changement
inattendu dans une fonction mathématique utilisée)
http://tile.openstreetmap.fr/?zoom=17=48.11792=-1.64677=B00
Si c'était une inversion inattendue
Note: les zooms faibles sont raffraichis moins souvent à cause de la
quantité de calcul plus importante
Le ven. 10 août 2018 à 09:57, a écrit :
> Le 09/08/2018 à 23:28, Philippe Verdy - verd...@wanadoo.fr a écrit :
>
> les rendus d'OSM France ou Allemagne ou Mapquest ne sont pas impactés ici
>
Car le rendu des styles DE et FR ne sont pas ceux de la carto mapnik carto
que tu trouves sur openstreetmap.org Le problème de raffraichissement ne
vient pas des données mais de la manière de rafraichir et de recalculer les
tuiles pour "mapnik carto"
Si je me trompe pas les serveurs de rendu sont
highway=* with area=yes are already most often for highway=pedestrian, but
actually renderers already apply consistant representations whe nthese are
used for other types of highways: the typical use is the representation of
residential highways without exit: instead of a terminal node with a
19 matches
Mail list logo
