Re: [OSM-talk-fr] Problème sur l'outil cadastre

2017-06-28 Par sujet Tyndare 

Le 28/06/2017 à 14:31, Antoine Riche a écrit :
> J'ai peut-être raté une info, mais l'outil
> http://cadastre.openstreetmap.fr/ ne fonctionne plus. La génération
> du  bâti produit les erreurs suivantes, cela suggère un problème dans
> la génération des PDFs :
>
> Teléchargement des PDFs de la commune IL143 : REZE (44400)
> Découpe la bbox en 6 * 4 [24 pdfs]
> terminate called after throwing an instance of 'PoDoFo::PdfError'
>what():  ePdfError_NoPdfFile
> IL143-0-0.pdf

Effectivement, les pdf téléchargés contiennent seulement le message:

Un problème de sécurité est survenu. Nous ne pouvons
satisfaire à votre requête.

Il a du y avoir des changements sur le site cadastre.gouv.fr,
je n'ai pas trop le temps pour l'instant de regarder ça.

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Mise à jour suspendue sur rendu HOT...

2017-06-28 Par sujet Philippe Verdy 
Je ne pense pas en effet que la fragmentation des fichiers sur SSD est un
problème. En fait toute écriture sur SSD se fait en recyclant de nouveaux
secteurs déjà "trimmés."

Cependant pour trimmer les secterurs c'est un peu plus lent qu'une écriture
normale mais c'est une opération nécessaire avant de pouvoir les réécrire.
De fait un SSD ne trimme pas les secteurs tout seul et ne le fait qu'à la
demande de l'OS. Si le SSD devient très plein, les anciens secteurs qui ont
été réécris sont marqués comem "dirty" (à trimmer) avant de pouvoir être à
nouveau disponibles pour l'écriture. Quand le SSD se remplit, les trims
sont de plus en plus fréquents et sur un nombre moins élevé de secteurs :
si on se contente de toujours écrire sur ces derniers secterus libres, ils
vont vite dépasser leur nombre d'écriture maxi et produire des erreurs (ils
sont ineffaçables et les nouveaux secteurs doivent être alloués parmi les
autres secteurs trimmés). Pour égaliser la durée de vie moyenne des
secteurs, une petite table statistique interne découpe le SSD en "bandes"
et les bandes sont recyclés régulièrement (par l'OS) en réécrivant les
secteurs occupés (sans réellement les modifier) afin de déplacer
progressivement le pool de secteurs trimmés sur toute la surface. C'est un
processus cyclique, l'OS indique au SSD quand il est opportun de recycler
des secteurs trop souvent trimmés (donc réécrits aussi trop souvent) pour y
mettre à la place des données stables encore stockées dans des secteurs
moins souvent écrits. Le SSD possède en plsu un petit pool de secteurs de
secours qui servira en cas de trop plein mais qui doivent être vite libéré.
Ce pool libre sert avant tout pour permettre la récupération en cas de
coupure d'alimentation ou plantage du système afin d'assurer l'intégrité:
il doit pouvoir stocker les données non encore écrites qui sont dans le
petit antémémoire cache (constitué non pas de mémoire flash mais de RAM
plus classique et plus rapide ne nécessitant aucun trim)

Bref les performances commencent à se dégrader au delà des 60%
d'occupation, certains SSD affichant des performances en écriture déjà deux
fois moins élevée quand ils sont seulement à moitié plein. Un SSD ne
devrait jamais être utilisé au delà des deux tiers de la capacité maximale,
sinon même les données stables sont exposées à des risques et les
performances se dégradent vite. Bref il faut faire le ménage si on veut de
bonnes performances en écriture. En revanche en lecture cela n'a
normalement pas d'influence sur les performances: un SSD protégé en
écriture aura une excellente durée de vie, mais là aussi la mémoire flash
doit de temps en temps être raffraichie: les secteurs en lecture seule se
recyclent donc aussi. Le firmware des SSD s'en occupe très lentement quand
il n'est pas occupé à faire autre chose.

L'autre problème des SSD est qu'ils n'ont pas seulement des secteurs de
données mais aussi des secteurs de "tags" qui permettent de stocker
l'indirection des secteurs virtuels (vus pas les système de fichier de
l'OS) en secteurs physiques. Cette indirection se fait par bloc minimal de
4Ko là où les secteurs logiques font seulement 0,5Ko pour les OS et les
protocoles ATA/PATA/SATA/SCSI et l'adressage LBA en général. Le but étant
réduire la place nécessaire pour la mémoire de tags, contituée aussi de
secteurs de mémoire Flash et qui doit elle aussi être recyclée (mais avec
un algorithme complètement différent sans placement "aléatoire" comme les
secteurs de données). Les algos utilisés pour la mémoire de tags varient
selon les constructeurs et firmwares de SSD. La mémoire de tags peut aussi
avoir (et en général elle en a) elle aussi un cache de RAM volatile: comme
les tags sont les données du SSD les plus souvent accédées, ce cache doit
être très rapide, c'est souvent des registres CMOS, mais là aussi il faut
une réserve d'énergie pour assurer l'intégrité. Parfois des secteurs flash
commenceront à avoir des problèmes sur certains bits et pas d'autres, ils
ont tous un contrôle de parité/CRC poru détecter ces erreurs, et c'est vrai
aussi de la mémoire de tags. Certains SSD utilise pour les tags (le même
pool de secteurs mémoire Flash, mais évitent la fin de vie prématurée en
mettant un cache volatile important en face: c'est un cache en écriture
différée, il peut être plus gros que le cache d'écriture des données, par
exemple 64Mo pour les tags contre seulement 4Mo pour les données, notamment
sur les très gros SSD les plus chers dont le cache couteux de données ne
monte pas autant en capacité que le cache des tags).

On trouve aussi des SSHD, couplant un gros HDD (fiable) à un petit SSD
frontal mais sans recyclage: ce SSD au cours du temps voit sa capacité
diminuer, le cache SSD est un peu moins performant au fil du temps, et peut
aussi avoir un cache de RAM volatile rapide. Sa mémoire de tags (pour
associer les numéros de secteurs du disque dur à une page de cache SSD est
moins critique. Mais cela apporte de la fiabilité aux HDD en réduisant les

[OSM-talk-fr] Jungle Bus dans 56kast

2017-06-28 Par sujet Baptiste Mille-Mathias 
Bonjour,

L'émission 56Kast du 15 juin dernier parle en grande partie du projet
Jungle Bus et d'OpenstreetMap, avec comme invité Florian Lainez
co-fondateur du projet Jungle Bus.
http://www.liberation.fr/futurs/2017/06/15/56kast-110-jungle-bus-pour-liberer-les-plans-de-transports_1574071

Amicalement
-- 
Les gens heureux ne sont pas pressés
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Problème sur l'outil cadastre

2017-06-28 Par sujet Antoine Riche 
J'ai peut-être raté une info, mais l'outil 
http://cadastre.openstreetmap.fr/ ne fonctionne plus. La génération du 
bâti produit les erreurs suivantes, cela suggère un problème dans la 
génération des PDFs :


Teléchargement des PDFs de la commune IL143 : REZE (44400)
Découpe la bbox en 6 * 4 [24 pdfs]
terminate called after throwing an instance of 'PoDoFo::PdfError'
  what():  ePdfError_NoPdfFile
IL143-0-0.pdf
terminate called after throwing an instance of 'PoDoFo::PdfError'
  what():  ePdfError_NoPdfFile
IL143-0-1.pdf
terminate called after throwing an instance of 'PoDoFo::PdfError'
  what():  ePdfError_NoPdfFile
IL143-0-2.pdf

Antoine.



---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel 
antivirus Avast.
https://www.avast.com/antivirus
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Meetup Open Transport à Paris 05/07

2017-06-28 Par sujet djakk djakk 
Je viens ! :)

Le 27 juin 2017 à 15:21, Florian LAINEZ  a écrit :

>
> Le 27 juin 2017 à 12:29, Jo  a écrit :
>
>> Venir à Paris ne sera pas possible pour moi. Y a-t-il moyen de suivre en
>> ligne?
>
>
> Il n'est malheureusement pas prévu de retransmission, désolé.
>
> --
>
> *Florian Lainez*
> @overflorian 
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] donnée osmose non maj ?

2017-06-28 Par sujet marc marc 
Bonjour,

Osmose a l'air de ne plus recevoir les maj des modif faite sur osm.
Exemple https://osmose.openstreetmap.fr/fr/error/12540701000
qui dit que le bâtiment est en building=industrial
et propose en autre building=warehouse, modification faite y a 25 jours.
J'avais ce jour là changé le status en corrigé mais après quelques 
jours, elle réapparaît.
idem pour d'autres erreurs comme par exemple 
https://osmose.openstreetmap.fr/fr/error/12540838769

Cette fois, j'ai volontairement laissé ces erreurs ouverte en pensant 
que cela aiderait à comprendre le problème.

Cordialement,
Marc
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr