Re: [OSM-talk-fr] rendu OSM-FR identique au rendu OSM ?

2018-07-18 Par sujet Christian Quest
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 des nombreuses mises à jour récentes !



Le 18/07/2018 à 13:56, Eric Brosselin - Osm a écrit :

Le 18/07/2018 à 00:31, Christian Quest a écrit :
C'est bien normale et on n'a rien à cacher, même nos pétouilles et 
cagades :)


Il me semble qu'il y a un problème avec les terrains de sports ;-)

Voir >>> https://framapic.org/nBQk6DArfag4/PopHrAb631dc.jpg



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


--
Christian Quest - OpenStreetMap France

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


Re: [OSM-talk-fr] rendu OSM-FR identique au rendu OSM ?

2018-07-18 Par sujet Eric Brosselin - Osm

Le 18/07/2018 à 00:31, Christian Quest a écrit :
C'est bien normale et on n'a rien à cacher, même nos pétouilles et 
cagades :)


Il me semble qu'il y a un problème avec les terrains de sports ;-)

Voir >>> https://framapic.org/nBQk6DArfag4/PopHrAb631dc.jpg

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


Re: [OSM-talk-fr] rendu OSM-FR identique au rendu OSM ?

2018-07-17 Par sujet Christian Quest
C'est bien normale et on n'a rien à cacher, même nos pétouilles et cagades
:)

Le serveur rattrape son retard de mise à jour de tuiles, donc pas mal
chargé, mais ça devrait se stabiliser au fur et à mesure des jours à venir.

J'ai fait de nombreuses mises à jour, tout est "au propre" (OS, postgres,
stack renderd/mod-tile) et les problème de performances qu'on rencontrait
devraient être nettement réduits.


Le 17 juillet 2018 à 21:10, Adrien Grellier  a écrit :

> Bonjour,
>
> Merci pour vos réponses, c'est vraiment appréciable d'avoir une telle
> transparence, qui permet de mieux comprendre les choses :-)
>
> Bon courage pour la suite
>
> Adrien
>
> Le 17/07/2018 à 16:43, Christian Quest a écrit :
>
> Le 17 juillet 2018 à 13:27,  a écrit :
>
>>
>> L'import s'est terminé au bout de 52153s, soit un peu moins de 15h.
>> Maintenant les updates, quelques index à rajouter et on relance l'usine à
>> tuiles !
>>
>> On appelle ça une briquetterie, pas vrai ? ;-)
>>
>>
> Une tuilerie, non ?  -> https://fr.wikipedia.org/wiki/Tuilerie
>
> Pour les updates, osm2pgsql va environ 40 à 60 fois plus vite que le temps
> réel pour la mise à jour des données.
> 1 jour d'update, prend dans les 30 minutes. Quand on fait des updates à
> 5mn, ça prends quelques secondes et vu le fonctionnement d'imposm3 je doute
> qu'il puisse tenir ce rythme, il est par contre bien adapté à une mise à
> jour quotidienne.
>
>
> --
> Christian Quest - OpenStreetMap France
>
>
> ___
> Talk-fr mailing 
> listTalk-fr@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-fr
>
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>


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


Re: [OSM-talk-fr] rendu OSM-FR identique au rendu OSM ?

2018-07-17 Par sujet Adrien Grellier
Bonjour,

Merci pour vos réponses, c'est vraiment appréciable d'avoir une telle
transparence, qui permet de mieux comprendre les choses :-)

Bon courage pour la suite

Adrien


Le 17/07/2018 à 16:43, Christian Quest a écrit :
> Le 17 juillet 2018 à 13:27,  > a écrit :
>
>
>> L'import s'est terminé au bout de 52153s, soit un peu moins de
>> 15h. Maintenant les updates, quelques index à rajouter et on
>> relance l'usine à tuiles !
> On appelle ça une briquetterie, pas vrai ? ;-)
>
>
> Une tuilerie, non ?  -> https://fr.wikipedia.org/wiki/Tuilerie
>
> Pour les updates, osm2pgsql va environ 40 à 60 fois plus vite que le
> temps réel pour la mise à jour des données.
> 1 jour d'update, prend dans les 30 minutes. Quand on fait des updates
> à 5mn, ça prends quelques secondes et vu le fonctionnement d'imposm3
> je doute qu'il puisse tenir ce rythme, il est par contre bien adapté à
> une mise à jour quotidienne.
>
>
> -- 
> Christian Quest - OpenStreetMap France
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr



signature.asc
Description: OpenPGP digital signature
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] rendu OSM-FR identique au rendu OSM ?

2018-07-17 Par sujet Christian Quest
Le 17 juillet 2018 à 13:27,  a écrit :

>
> L'import s'est terminé au bout de 52153s, soit un peu moins de 15h.
> Maintenant les updates, quelques index à rajouter et on relance l'usine à
> tuiles !
>
> On appelle ça une briquetterie, pas vrai ? ;-)
>
>
Une tuilerie, non ?  -> https://fr.wikipedia.org/wiki/Tuilerie

Pour les updates, osm2pgsql va environ 40 à 60 fois plus vite que le temps
réel pour la mise à jour des données.
1 jour d'update, prend dans les 30 minutes. Quand on fait des updates à
5mn, ça prends quelques secondes et vu le fonctionnement d'imposm3 je doute
qu'il puisse tenir ce rythme, il est par contre bien adapté à une mise à
jour quotidienne.


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


Re: [OSM-talk-fr] rendu OSM-FR identique au rendu OSM ?

2018-07-17 Par sujet osm . sanspourriel



Le 17/07/2018 à 08:07, Christian Quest - cqu...@openstreetmap.fr a écrit :
Imposm3 est effectivement plus rapide mais produit un schéma de base 
postgresql qui est totalement différent de celui d'osm2pgsql utilisé 
par nos styles.
C'est bien ce que je pensais mais comme certaines fois tu nous fais des 
miracles.
Une ré-écriture des styles est au programme pour basculer sur un 
schéma OpenMapTiles, ce qui permettrait à partir de la même base de 
générer des tuiles images ET vectorielles.

Avec TileServer GL je suppose. J'ai testé et suis assez content.
Je ne sais pas non plus ce que donne imposm3 en mises à jour très 
régulières (5mn dans notre cas).

Là pas d'expérience de mon côté (du leur pas forcément non plus).
Mon expérience : des imports complet occasionnels (pour pouvoir être en 
intranet pur).
J'étais sur du Tessera (basé sur tilelive) et je l'ai utilisé pour 
produire de la tuile pbf au schéma OpenMapTiles pour tester des styles 
MapBox GL spécifiques (inspirés de styles OpenMapTiles).
Un peu galère la config pour être complètement autonome (polices par 
exemple, reverse proxy, etc...) mais ça tombe en marche.

Et le résultat fort sympa en terme de vitesse.
Par contre pour l'import de données autres, je conseille vivement de 
convertir les shapafile et autres en mbtiles. Oui un import en base est 
aussi possible et sans doute judicieux mais pas dans mon cas.

GDAL en 2.3.0 lève pas mal de restrictions observées.

Un autre intérêt c'est bien sûr la facilité pour le multilinguisme.
Bon ce message aurait plus eu sa place sur la liste technique, vous 
pouvez le faire suivre.


Jean-Yvon


L'import s'est terminé au bout de 52153s, soit un peu moins de 15h. 
Maintenant les updates, quelques index à rajouter et on relance 
l'usine à tuiles !

On appelle ça une briquetterie, pas vrai ? ;-)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] rendu OSM-FR identique au rendu OSM ?

2018-07-16 Par sujet Christian Quest
Imposm3 est effectivement plus rapide mais produit un schéma de base
postgresql qui est totalement différent de celui d'osm2pgsql utilisé par
nos styles.

Une ré-écriture des styles est au programme pour basculer sur un schéma
OpenMapTiles, ce qui permettrait à partir de la même base de générer des
tuiles images ET vectorielles.

Je ne sais pas non plus ce que donne imposm3 en mises à jour très
régulières (5mn dans notre cas).


L'import s'est terminé au bout de 52153s, soit un peu moins de 15h.
Maintenant les updates, quelques index à rajouter et on relance l'usine à
tuiles !


Le 17 juillet 2018 à 06:14,  a écrit :

> Le 17/07/2018 à 00:10, Christian Quest - cqu...@openstreetmap.fr a écrit :
>
> et il m'a fallu le week-end pour comprendre :(
>
> Oui mais en 1 minute tu nous a passé une information immédiatement
> compréhensible.
> Ceci dit, une version incompatible n'aurait pas dû avoir un numéro
> ordinaire, il y aurait dû y avoir un saut.
>
> P.S. : tu ne peux pas utiliser imposm3 pour ton import ? Ce serait plus
> rapide.
> Jean-Yvon
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>


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


Re: [OSM-talk-fr] rendu OSM-FR identique au rendu OSM ?

2018-07-16 Par sujet osm . sanspourriel

Le 17/07/2018 à 00:10, Christian Quest - cqu...@openstreetmap.fr a écrit :


et il m'a fallu le week-end pour comprendre :(
Oui mais en 1 minute tu nous a passé une information immédiatement 
compréhensible.
Ceci dit, une version incompatible n'aurait pas dû avoir un numéro 
ordinaire, il y aurait dû y avoir un saut.


P.S. : tu ne peux pas utiliser imposm3 pour ton import ? Ce serait plus 
rapide.

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


Re: [OSM-talk-fr] rendu OSM-FR identique au rendu OSM ?

2018-07-16 Par sujet Christian Quest
Version courte:

La base postgresql qui sert au rendu FR est en cours de ré-import... et les
requêtes sont temporairement redirigées vers le rendu standard en attendant
que tout revienne dans l'ordre (mieux que des 404).

Version longue complémentaire:

J'ai eu la mauvaise idée de mettre à jour l'outil osm2pgsql qui sert à
transformer les données OSM xml ou pbf en base postgresql/postgis... sans
lire en détail le changelog des mise à jour intermédiaires (de 0.92 à 0.96
sans lire celui de la 0.94).
Or, la version 0.94 a modifié le stockage des coordonnées des nodes dans un
fichier temporaire "flatnodes" permettant les mises à jour.
Avant la 0.94 elles étaient stockées en coordonnées projetées (donc web
mercator dans notre cas), et depuis la 0.94 ce sont les coordonnées non
projetée (WGS84) qui sont utilisée.
Malheureusement à l'upgrade, aucune alerte et pas de mise à jour du fichier
existant... et donc les géométries des objets modifiés étaient délirantes,
les mise à jour prenaient un temp fou, le nombre de tuiles impactés par le
moindre changement de géométrie d'un petit objet était énorme et il m'a
fallu le week-end pour comprendre :(

Impossible de revenir en arrière et de corriger, donc le plus simple est un
ré-import complet de la base ce qui prends pas loin de 24h, mais ce qui
permet aussi de la compacter au passage.
Demain tout devrait rentrer dans l'ordre, enfin j'espère !


Le 16 juillet 2018 à 21:27, Adrien Grellier  a écrit :

> Bonjour,
>
> Le rendu OSM-FR est désormais identique au rendu classique
> d'OpenStreetMap, sans les traductions française notamment :
>
> https://tile.openstreetmap.fr/
>
> Je suppose une erreur de config… :-)
>
> Bonne soirée
>
> Adrien
>
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>


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