Re: [OSM-dev-fr] Map au format OSM

[sly (sylvain letuffe)]

Salut,

Le jeudi 27 septembre 2018, 21:56:40 CEST handy emmanuel a écrit :
> Je me permets de vous contacter car Je voulais savoir comment transformer
> une map d'unformat X en un format osm (OpenStrreetMap)?

Cette question étant très général, je répond de même :
Pour convertir d'un format de carte en format xml/osm il faut un logiciel de 
conversion.
Et à la question "quel logiciel ?" la réponse est : ça dépend du format X.

> Par exemple, a cote de chez moi y a un circuit auto, J'ai la map du circuit
> en un nformat RND et Je voudrais rendre mettre cette map au format OSM . 

Là, il faut prendre son bâton de pèlerin et partir à la pêche aux infos :
Quel est ce format RND, est-il librement décrit, existe-il des convertisseurs, 
celui qui l'a inventé/développé fourni-t-il des filtres de conversion, etc.

Perso, ce format ne me dit rien du tout. Et google qui sait tout ne semble pas 
avoir trouvé de page qui en parle. On peut en savoir plus sur ce format ? ça 
s'ouvre avec quoi ? Peut-on avoir un fichier de démo ?

> Ca pourrait servir a toute al communaute OpenStreetMap

Et enfin, même si tu arrivais à faire ta conversion, il faudrait se demander : 
dans quel cas ça peut servir à la communauté. En général, c'est pour compléter 
la carte existante et là, se posent de nouvelles questions :
- Copier cette carte est-il autorisé ? La licence est-elle compatible ?
Mais aussi,
- y'a-t-il chevauchement avec des éléments déjà renseignés
- se rapprocher des contributeurs locaux pour fusionner avec l'existant

En premier, il faudrait donc analyser de quel volume on parle, toutes ses 
gesticulations valent-t-elle mieux que de tracer le circuit auto par dessus les 
photos satellite ?


-- 
sly, direct contact : sylv...@letuffe.org
http://wiki.openstreetmap.org/wiki/User:Sletuffe

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

Re: [OSM-dev-fr] Interroger api06 avec OverPass

[sly (sylvain letuffe)]

On lundi 3 octobre 2016, Guillaume AMAT wrote:
> Mais même si on fait fi de la « propreté » de la méthode, dans certains
> cas c'est vraiment pas pratique...

Si vraiment t'as du super courage (de solides compétences linux) et que dans 
ton cas c'est vraiment vraiment pas pratique tu peux :
- ajouter des données dans api06.dev.openstreetmap.org dans un secteur défini
- les télécharger régulièrement par un appel de type bbox
- les ré-importer dans une base overpass locale

et ainsi avoir 2 bases synchro

-- 
sly, direct contact : sylv...@letuffe.org
http://wiki.openstreetmap.org/wiki/User:Sletuffe

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

Re: [OSM-dev-fr] Interroger api06 avec OverPass

[sly (sylvain letuffe)]

Yo,

Le dimanche 2 octobre 2016, 15:39:23 Guillaume AMAT a écrit :
> J'aimerais utiliser api06 pour le développement/les tests de MapContrib.

On est d'accord tu parles bien de : http://api06.dev.openstreetmap.org ?

> : Comment dire à OverPass de me retourner les données d'api06 au lieu de 
> l'instance de prod ? 

Ça n'est pas prévu.

> Ou plutôt, y'a-t-il une instance OverPass branchée
> sur api06 ?

Et non, pas que je sache.

Et je ne devrais surtout pas suggérer ça mais c'est ce que j'ai fais et c'est 
de loin le plus simple :
tu utilises l'api de prod, l'overpass de prod et tu te trouves un petit coin 
discret, tout petit, quelque part sur la banquise, tu ne fais pas de gros 
objets, et tu effaces après tes tests.
On te chope, tu t'excuses, dis que c'est pour la bonne cause et argumente que 
l'api de dev est bien jolie mais comme elle ne permet pas l'export régulier, 
tu n'as pas pu installer une overpass avec les données contenues.

Si vous ou l'un de vos collaborateurs étiez pris en flag, je nierais avoir eu 
connaissance de vos agissements.




-- 
sly (sylvain letuffe)


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

Re: [OSM-dev-fr] "Pages jaunes" à partir d'OSM

[sly (sylvain letuffe)]

Le jeudi 10 mars 2016, 09:59:21 Julien Fastré a écrit :

> Concernant l'adage "on ne cartographie pas comme un annuaire": je ne
> l'ai jamais entendu... 

Pas plus. 
Et ces pages : 
http://wiki.openstreetmap.org/wiki/Key:contact 
http://wiki.openstreetmap.org/wiki/Key:phone
http://wiki.openstreetmap.org/wiki/Key:website
Et les stats taginfo qui s'y rapporte me semble indiquer qu'il y a un fort 
intérêt pour l'enregistrement de cette information.
Je ne connais pas de projet d'annuaire libre "avancé" donc j'ai envie de 
demander en quoi osm ne pourrait pas le faire, la géolocalisation en plus ?

> J'ai également pensé à overpass api

Car, en effet, elle répond à tes demandes. Il ne reste plus qu'a faire un 
frontend qui fasse les requêtes et l'overpass API peut faire le moteur.

> , mais j'ai peur de la latence. 

Moi aussi, et je la remarque dans mon projet. un premier test pourrait être 
d'importer dans la base overpass une version simplifié d'osm (retirer limites 
admin, routes, chemin de fer, forêt, etc.) et voir si ça n'irait pas plus 
vite.
Je me demande si tout recoder de zéro est bien la bonne méthode.
Bon, avec une base postgres/schéma osm2pgsql sous-jaccente on doit pouvoir 
faire un truc mais c'est un peu de boulot quand même.


> Je me
> suis demandé si en filtrant les fichiers .osm à l'entrée avec osmosis,
> on ne pourrait pas avoir une base de donnée plus petite et une réponse
> plus rapide. Déjà testé ?

Bon, ça m'apprendra à lire les mails jusqu'au bout, donc ouais, c'est 
exactement ce que j'ai en tête mais je n'ai pas pris le temps de tester.


> Voilà. Si on est plusieurs, on serait ravi de discuter du projet et
> d'avancer ensemble.

o/

-- 
sly (sylvain letuffe)
http://wiki.openstreetmap.org/wiki/User:Sletuffe

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

Re: [OSM-dev-fr] "Pages jaunes" à partir d'OSM

[sly (sylvain letuffe)]

Bonsoir,

Le mercredi 9 mars 2016, 21:09:02 Julien Fastré a écrit :
> L'idée: avoir au moins une API qui puisse être interrogée par d'autres
> applications.
> 
> Avez-vous déjà eu vent de telles applications ?

Tu n'as pas trop détaillé ce que ferait cette api ?
Par bbox ? (overpass api ?)
Par nom ? (nominatim api ?)
Par thème ?

Donc oui ça existe déjà en partie, mais peut-être pas tel que tu en conçois 
une utilisation spécifique.

> Est-ce que vous avez déjà eu vent de tels projets / besoins ?

Qui font quoi ? par exemple montrer tous les hôtels d'une ville sur une carte 
avec adresses, numéro de téléphone, site internet ?
je pense qu'il y en a pas mal oui, et je serais moi aussi potentiellement 
consommateur d'un tel service.
Pour l'instant, je le fais avec l'overpass API mais c'est un chouille lent car 
elle est très générique

-- 
sly (sylvain letuffe)
http://wiki.openstreetmap.org/wiki/User:Sletuffe

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

Re: [OSM-dev-fr] notification de modifs

[sly (sylvain letuffe)]

Plutôt que "conçu" disons "dimensionné"
Les serveurs qui font tourner l'api et le site web sont administré pour donner 
la priorité a ceux qui vont modifier les données.
Donc tout usage qui pourrait ralentir ceux qui éditent prend le risque d'être 
banni.
(Bloquage par IP ou user agent) :
http://wiki.openstreetmap.org/wiki/API_usage_policy

Tant que le volume passe sous les radars personne ne dira rien, mais dès que 
ton projet commencera à décoller ça serait bête d'avoir a faire une update 
urgente parce que ça ne marche plus.

Le 7 mars 2016 08:14:29 CET, "clem...@igonet.fr"  a écrit :
>Merci Christian pour tes remarques.
>
>"Pas conçues pour ça"? Pourquoi pas?
>
>Je dois faire des choix dans mes priorités pour que le projet Open
>Earth View avance.
>
>À ce propos, ton aide serait plus que bienvenue pour monter une base
>locale à jour avec API de recup de données XML où json. À défaut, tu
>aurais un lien vers une doc de mise en oeuvre pratique?
>
>   En attendant un système de cache me semblait assez approprié...
>
>Clément.
>
>
>Le 6 mars 2016 23:02:02 UTC+01:00, Christian Quest
> a écrit :
>>Les appels à l'API ne sont franchement pas conçus pour ça... tant en
>>terme
>>de fonctionnalité que de volumétrie.
>>
>>Il faudrait vraiment repenser ton outil pour qu'il soit plus
>>indépendant,
>>c'est à dire monter une base locale que tu met à jour avec les diff et
>>tu
>>tape dans cette base locale pour générer tes données 3D.
>>
>>
>>Le 6 mars 2016 à 22:46, clem...@igonet.fr  a écrit
>:
>>
>>> Je ne genere pas de xml, je le recupere sur l'api web d'osm. c'est
>>pour
>>> eviter d'abuser de ce service que je voudrais mettre un cache un
>>munimum
>>> "intelligent".
>>>
>>> Pour info, ce que renvoie le génèrateur de données d'OpenEarthView
>>(nom du
>>> projet), c'est les donnees transformées: geojson, json x3d, json
>pour
>>> three.js, etc...
>>>
>>> Clément.
>>>
>>>
>>> Le 6 mars 2016 12:49:15 UTC+01:00, Christian Quest <
>>> cqu...@openstreetmap.fr> a écrit :

 Ces diffs ne contiennent pas toutes les informations pour savoir où
>>des
 changements ont été faits.

 Par exemple, si un way est modifié, mais aucun de ses noeuds ne l'a
>>été,
 tu n'aura que la nouvelle version du way, ses tags, les id des
>>noeuds qui
 le porte, mais pas leur coordonnées...

 Pareil pour une relation, si les way ou noeuds membres ne sont pas
 modifiés, ils ne sont pas dans le diff.


 En fait c'est pas trivial du tout comme problème si on veut le
>>traiter
 proprement... osm2pgsql génère la liste des tuiles impactées lors
>>des mises
 à jour par les diffs. Il est assez intelligent pour ne sortir que
>>les
 tuiles du périmètre de certaines grandes relations (par exemple les
 frontières d'un pays) plutôt que tout ce qu'il contient.

 Comment génères-tu tes XML ? à partir de quoi ?



 Le 6 mars 2016 à 07:36, clem...@igonet.fr  a
>>écrit :

> ok, il me manquait ça:
> http://wiki.openstreetmap.org/wiki/Planet.osm/diffs
> je ne cherchais pas avec les bons mots clés (commit, trigger,
>>update,
> etc...).
>
> Merci
>
> Clément
>
> Le 6 mars 2016 00:24:57 UTC+01:00, THEVENON Julien <
> julien_theve...@yahoo.fr> a écrit :
>>
>> Salut,
>>
>> Il y a des diffs qui sont publiees toutes les minutes,toutes les
>>heures et tous les jours.
>> En regardant les coordonnees des mofis tu devrais trouver ce que
>>tu cherches.
>>
>> Julien
>> --
>>
>> En date de : Sam 5.3.16, clem...@igonet.fr  a
>>écrit :
>>
>>  Objet: [OSM-dev-fr]  notification de modifs
>>  À: "Discussions développeur OSM en français"
>>
>>  Date: Samedi 5 mars 2016, 21h49
>>
>>  Bonjour,
>>
>> Je mets en place
>>  un service en ligne de conversion de données osm xml vers
>>  des tuiles au formats 3D pour le web.
>>
>> Pour optimiser ce système, je
>>  souhaiterais mettre en place un cache des données
>> déjà
>>  traitées.
>>
>> Et
>>  pour rafraichir ce cache au besoin, je souhaiterais avoir
>>  connaissance des tuiles à mettre à jour.
>>
>> Ma question:
>>  existe-il un
>> service en ligne ou un quelconque moyen
>>  d'être alerté périodiquement (1min, 5min... ou 1h) de
>>  tous les secteurs géographiques mis à jours?
>>
>>  Clément.
>>
>>
>>
>>
>>  Le 3
>>  mars 2016 17:07:48 UTC+01:00, Jocelyn Jaubert
>>
>>  a écrit :
>>
>>> Bonjour,
>>>
>>> Le 02/03/2016 00:59,
>>>
>>  Laurent Combe a écrit :
>>
>>>  si

>>>  j'écris sur la liste dev c'est qu'il y a quand
>>  même un petit souci
>>
>>>  technique
  la page ne fonctionne pas si

>>>  j'essaye d'accéder directement à la
>>
>>> source
>>>
  xml située

>>>  sur le domai

Re: [OSM-dev-fr] Optimization base postgis pour tuiles mapnik

[sly (sylvain letuffe)]

On mardi 19 janvier 2016, Marc Ducobu wrote:
> J'utilise render_list pour précalculer les tuiles. Est-ce la bonne
> méthode ? 

Oui

> Est-ce que ça vaut le coût de générer les tuiles de 12 à 15 ?

Oui car ça sera plus fluide d'utilisation pour tes utilisateurs qui n'auront 
pas à attendre trop leur chargement, mais le zoom 15 va te prendre des plombes 
de temps sur l'europe !
Mais zoom 12,13 je répond oui sans trop d'hésitation, 14 à tester, et 15 ça va 
être long.
Se posant alors la question de la ré-génération. Qu'as tu prévu quand OSM sera 
mis à jour ?

> Pour le SSD je me suis planté... J'ai sous-estimé l'avantage du SSD. Y a
> t il une stratégie à privilégier quand on n'a pas le SSD ?

Oui, rendre le serveur à OVH et en reprendre un avec SSD (ça te coûtera 50 
euros soit un mois, à mon avis, ça les vaut) si tu as bien sauvegarder toutes 
tes configs, tu ne devrais pas en avoir pour long de refaire


> 
> On 18/01/16 11:22, Christian Quest wrote:
> > Pour info, sur tile.openstreetmap.fr 
> > plusieurs styles sont générés et les principaux sont le style HOT et le
> > style FR.
> > 
> > Pour ces deux styles, les tuiles des zooms 1 à 11 sont précalculés et
> > mis à jour une fois par semaine seulement. Certaines metatiles peuvent
> > prendre 30mn à être calculées (2 en zoom 9 centrées sur
> > France/Allemagne).
> > 
> > Autre chose... pourquoi un serveur avec 8To de disques rotatifs ?
> > j'aurai plutôt pris un EG32 avec 2x480Go de SSD pour juste 5 euros de
> > plus. Pour ce type d'usage, le SSD apporte un énorme gain de perf.
> > 
> > 
> > Le 16 janvier 2016 à 19:19, Frédéric Rodrigo  > 
> > > a écrit :
> > Ça prend du temps c'est normal.
> > La réponse est : il faut utiliser un cache.
> > 
> > Ces tuiles sont très couteuse à calculer et contienne peu souvent
> > des mises à jour visible.
> > Ce qui se pratique même est de les précalculer pour ne pas que
> > l'utilisateur ai à attendre.
> > 
> > Le 15/01/2016 16:03, Marc Ducobu a écrit :
> > Bonjour,
> > 
> > La couverture de la DB est européenne.
> > 
> > Je cherche à installer un serveur de tuiles sur l'europe. Le
> > serveur utilisé est un EG-32 d'ovh (
> > 
> >   - CPU : Intel Xeon E5-1620v2 4c/8t 3,7 GHz/3,9 GHz
> >   - RAM : 32 Go DDR3 ECC 1600 MHz
> >   - Disques : 2x 4 To SATA3
> > 
> > (https://www.ovh.com/fr/serveurs_dedies/infra/2014-EG-32.xml)).
> > Tout est
> > installé mais il y a un problème : à un niveau de zoom haut, les
> > tuiles
> > mettent du temps à être générées. Et donc, lors d'un zoom, il
> > faut pas
> > mal de temps pour que les tuiles soient affichées.
> > 
> > Du coup j'ai essayé de configurer la base postgresql afin
> > d'optimiser
> > son temps de réponse.
> > 
> > Pour l'instant les variables que j'ai changées sont :
> > effective_cache_size = 24GB
> > wal_buffers  = 16MB # avant 4MB
> > random_page_cost = 3 # avant 4
> > fsync = off # avant on
> > synchronous_commit = off # avant on
> > maintenance_work_mem 4096 # avant 64MB
> > work_mem =  500MB # avant 4MB
> > 
> > (dans ce que j'ai lu ils parlent de modifier checkpoint_segment =
> > à 1600. Comme celui actuel est de 3, ça me semble bcp et du coup
> > j'hésite.)
> > 
> > Ces changements n'ont pas amélioré le temps de génération des
> > tuiles.
> > 
> > Que pensez-vous de ces paramètres ? Aussi j'aimerai bien utiliser
> > un outil afin de tester la manière dont réagit la génération de
> > tuiles en
> > fonction des paramètres. Avez-vous un outil / une méthode à
> > conseiller ?
> > 
> > Merci bcp.
> > 
> > Marc
> > 
> > ___
> > dev-fr mailing list
> > dev-fr@openstreetmap.org 
> > https://lists.openstreetmap.org/listinfo/dev-fr
> > 
> > ___
> > dev-fr mailing list
> > dev-fr@openstreetmap.org 
> > https://lists.openstreetmap.org/listinfo/dev-fr


-- 
sly, direct contact : sylv...@letuffe.org
http://wiki.openstreetmap.org/wiki/User:Sletuffe
___
dev-fr mailing list
dev-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev-fr

Re: [OSM-dev-fr] Optimization base postgis pour tuiles mapnik

[sly (sylvain letuffe)]

On vendredi 15 janvier 2016, Marc Ducobu wrote:
> Que pensez-vous de ces paramètres ? 

J'ai appris que la gesticulation avec les paramètres de postgres dans ce cas 
d'utilisation était soit futile soit fournissait un gain dérisoire à coté du 
temps passé. Je fais tourner mon serveur de tuile actuellement avec les 
paramètres par défaut de debian !

Il est donc préférable d'investir ton temps ailleurs avec, comme mes collègues 
l'ont indiqué :
- pré-génération des zoom faibles (render_list est un outil fourni avec 
renderd qui te permet de spécifier zoom et bbox de la pré-génération)
- du SSD, vraiment du SSD, encore du SSD et toujours du SSD

Le gain en vitesse sera vraiment important, bien plus que trifouiller des 
paramètres de postgres, et tout particulièrement important, oserais-je dire 
nécessaire (j'ai aussi une base europe sur disques rotatifs et je crois 
qu'importer 10 minutes de diffs prenait un truc genre 8 minutes, autant dire 
que les disques ne font plus que ça) si tu veux maintenir ta base de données à 
jour avec les osm diffs

> Aussi j'aimerai bien utiliser un
> outil afin de tester la manière dont réagit la génération de tuiles en
> fonction des paramètres. Avez-vous un outil / une méthode à conseiller ?

nik2img ou le render_list pré-cité. Le plus dur étant de vider les myriades de 
couches de cache qui font que si tu lances 2 fois de suite une même génération 
tu peux gagner max de temps sans rien avoir changé


-- 
sly, direct contact : sylv...@letuffe.org
http://wiki.openstreetmap.org/wiki/User:Sletuffe
___
dev-fr mailing list
dev-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev-fr

Re: [OSM-dev-fr] Way splitté en base

[sly (sylvain letuffe)]

>> Est-ce que ça dit quelquechose à quelqu'un ? 

Oui. C'est dans pg-output.c (si ça existe toujours) que le code du split est.

Mon soupçon est
>qu'osm2pgsql
>> splitte les longs ways, plus ou moins arbitrairement 

C'est pile poil ça. La valeur est en dur dans le code.
-- 
sly

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

Re: [OSM-dev-fr] Chargement de toute la France dans PostGIS

[sly (sylvain letuffe)]

Le samedi 16 mai 2015 14:09:01, Vincent Frison a écrit :
> Merci pour vos retours..
> 
> Sly pourquoi ne mettre qu'un seul processs ? 

J'ignore si c'est toujours le cas, mais il fût un temps, quand on choisissait 
multiple processus avec osm2pgsql, il consommait plus de mémoire sur la partie 
création des polygones de relation.
Comme de toute façon, ta ressource limitante sera, de très loin, le disque 
très lent de ton portable (sauf ssd ?). Il faut laisser au maximum possible de 
mémoire au kernel linux pour qu'il puisse mettre le plus de chose en cache RAM 
possible. Et accessoirement fermer le plus grand nombre d'autres applications 
possible.

Mais si tu as le courage, tu peux tenter avec 4 puis 1 processus. Ça nous 
permettra de savoir ce qui est le plus rentable dans un config avec mémoire 
limitée.


> Je crois que mon processeur
> est un double cœur mais concrètement ça en fait 4 (à cause de
> l'hyperthreading?), en tout je "vois" 4 processeurs en faisant un "cat
> /proc/cpuinfo".
> 
> Sinon ok je me suis rajouté 12 GB de swap et je vais refaire une tentative
> cette nuit en mettant la cache à seulement 1GB car effectivement ce
> paramètre ne concerne que la cache et il faut bien garder un peu de mémoire
> pour le reste...
> 
> Le 16 mai 2015 13:31, sly (sylvain letuffe)  a écrit :
> > J'importe l'europe sur une machine avec 16go et 4 disques raid rotatifs
> > en 5jours. Je pense que ca devrait le faire pour ta config sur la france
> > uniquement avec de la patience.
> > 
> > Pour 8go de ram, ce qui est peu n'active pas autant de cache avec -C
> > sinon il n'en reste pas assez pour les autres traitements.
> > Selon moi :
> > --slim obligé
> > -C 800
> > --number-process=1
> > Et ajoute au moins 4 voir 8go de swap
> > 
> > Et arme toi de patience. Vu ta config, je tablerais sur 72h voir plus
> > Sinon, importe sur une autre machine et dump puis restore
> > 
> > Le 15 mai 2015 23:50:12 CEST, Vincent Frison  a
> > 
> > écrit :
> > >Hello,
> > >
> > >J'aimerais avoir un peu de retour d'expérience si certains parmi vous
> > >se
> > >sont déjà amusé à charger l'ensemble de la France dans une base
> > >PostGIS.
> > >
> > >En sachant que dans mon cas ça serait un vieux laptop avec Corei5@2,4
> > >GHz
> > >et simplement 8 GB de RAM. Peut-être que je rêve en couleur avec une
> > >configuration aussi limitée, en tout cas c'est pas grave si ça prend
> > >plusieurs jours à charger...
> > >
> > >J'ai donc essayé de charger le fichier PBF, 3 GB tout de même, mais
> > >pour
> > >l'instant c'est un échec.
> > >
> > >J'ai d'abord essayé sans l'option --slim mais ça a crashé au bout de
> > >plus
> > >de 24h (je n'ai plus le message d'erreur exact malheureusement).
> > >
> > >Ma dernière tentative avec plus de cache (osmpgsql -s -c -C 5000
> > >--number-processes=3) n'a pas vraiment planté mais ça a quand même
> > >joliment
> > >foiré puisque je me retrouve qu'avec 160k ways au lieu des 48M
> > >visiblement
> > >prévus.
> > >
> > >Voici les logs:
> > >
> > >Using projection SRS 900913 (Spherical Mercator)
> > >[...]
> > >Using built-in tag processing pipeline
> > >Allocating memory for dense node cache
> > >Allocating dense node cache in one big chunk
> > >Allocating memory for sparse node cache
> > >Sharing dense sparse
> > >Node-cache: cache=5000MB, maxblocks=64*8192, allocation method=11
> > >Mid: pgsql, scale=100 cache=5000
> > >Setting up table: planet_osm_nodes
> > >
> > >Reading in file:
> > >/home/turman/Temporary/GeoData/OSM/france-latest.osm.pbf
> > >Processing: Node(328394k 132.7k/s) Way(48772k 38.71k/s) Relation(382850
> > >24.75/s)  parse time: 19203s
> > >
> > >Node stats: total(328394512), max(3511063881) in 2475s
> > >Way stats: total(48772758), max(344356113) in 1260s
> > >Relation stats: total(382854), max(5126005) in 15469s
> > >Committing transaction for planet_osm_point
> > >Committing transaction for planet_osm_line
> > >Committing transaction for planet_osm_polygon
> > >Committing transaction for planet_osm_roads
> > >
> > >Going over pending ways...
> > >pending_ways failed: out of memory for query result
> > >(7)
> > >Error occurred, cleaning up
> > >
> > >A

Re: [OSM-dev-fr] Chargement de toute la France dans PostGIS

[sly (sylvain letuffe)]

J'importe l'europe sur une machine avec 16go et 4 disques raid rotatifs en 
5jours. Je pense que ca devrait le faire pour ta config sur la france 
uniquement avec de la patience.

Pour 8go de ram, ce qui est peu n'active pas autant de cache avec -C sinon il 
n'en reste pas assez pour les autres traitements.
Selon moi :
--slim obligé
-C 800 
--number-process=1
Et ajoute au moins 4 voir 8go de swap

Et arme toi de patience. Vu ta config, je tablerais sur 72h voir plus
Sinon, importe sur une autre machine et dump puis restore

Le 15 mai 2015 23:50:12 CEST, Vincent Frison  a écrit 
:
>Hello,
>
>J'aimerais avoir un peu de retour d'expérience si certains parmi vous
>se
>sont déjà amusé à charger l'ensemble de la France dans une base
>PostGIS.
>
>En sachant que dans mon cas ça serait un vieux laptop avec Corei5@2,4
>GHz
>et simplement 8 GB de RAM. Peut-être que je rêve en couleur avec une
>configuration aussi limitée, en tout cas c'est pas grave si ça prend
>plusieurs jours à charger...
>
>J'ai donc essayé de charger le fichier PBF, 3 GB tout de même, mais
>pour
>l'instant c'est un échec.
>
>J'ai d'abord essayé sans l'option --slim mais ça a crashé au bout de
>plus
>de 24h (je n'ai plus le message d'erreur exact malheureusement).
>
>Ma dernière tentative avec plus de cache (osmpgsql -s -c -C 5000
>--number-processes=3) n'a pas vraiment planté mais ça a quand même
>joliment
>foiré puisque je me retrouve qu'avec 160k ways au lieu des 48M
>visiblement
>prévus.
>
>Voici les logs:
>
>Using projection SRS 900913 (Spherical Mercator)
>[...]
>Using built-in tag processing pipeline
>Allocating memory for dense node cache
>Allocating dense node cache in one big chunk
>Allocating memory for sparse node cache
>Sharing dense sparse
>Node-cache: cache=5000MB, maxblocks=64*8192, allocation method=11
>Mid: pgsql, scale=100 cache=5000
>Setting up table: planet_osm_nodes
>
>Reading in file:
>/home/turman/Temporary/GeoData/OSM/france-latest.osm.pbf
>Processing: Node(328394k 132.7k/s) Way(48772k 38.71k/s) Relation(382850
>24.75/s)  parse time: 19203s
>
>Node stats: total(328394512), max(3511063881) in 2475s
>Way stats: total(48772758), max(344356113) in 1260s
>Relation stats: total(382854), max(5126005) in 15469s
>Committing transaction for planet_osm_point
>Committing transaction for planet_osm_line
>Committing transaction for planet_osm_polygon
>Committing transaction for planet_osm_roads
>
>Going over pending ways...
>pending_ways failed: out of memory for query result
>(7)
>Error occurred, cleaning up
>
>Au vu du message d'erreur, dois je augmenter la taille du cache ?
>Malheureusement je suis déjà pas très loin de ma limite physique, mais
>je
>pourrais me créer un swap.. swap que je n'ai pas actuellement, d'où
>peut-être mes problèmes d'ailleurs !
>
>Bref si vous avez des conseils ou des bonnes options je suis preneur.
>
>Merci, Vincent.
>
>PS: j'utilisais avant une version bien à jour d'osm2pgsql compilée
>depuis
>Git mais depuis ma mise à jour vers Debian 8 j'ai des soucis de
>compilation, du coup j'utilise la version packagée dans Jessie cad SVN
>version 0.86.0 (64bit id space).
>
>
>
>
>___
>dev-fr mailing list
>dev-fr@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/dev-fr

-- 
sly

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

Re: [OSM-dev-fr] Osm2pgsql et les multipolygones

[sly (sylvain letuffe)]

Le 19 mars 2015 23:12:44 CET, Vincent Frison  a écrit 
:
>existence de la table planet_osm_rels,
>avec elle j'ai donc le ou les IDs des membres "outer" de la relation ce
>qui
>suffit amplement à mon bonheur. 

ton bonheur risque d'etre limité :
Trifouiller les tables slim n'est pas souvent fait pour.
De plus outer n'est un role pas tout le temps renseigné (parfois vide)
-- 
sly

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

Re: [OSM-dev-fr] Osm2pgsql et les multipolygones

[sly (sylvain letuffe)]

hello,
On jeudi 19 mars 2015, Vincent Frison wrote:
> Sur le wiki (http://wiki.openstreetmap.org/wiki/Osm2pgsql/schema) il est
> indiqué :

Cette page est approximative et n'a pas été créée pas des développeurs de 
l'outil, elle présente quelques imprécisions voire erreurs et doit être prise 
avec prudence.
 
> For polygons which are members in one or more relations, multiple rows will
> be created:

Ce passage est imprécis. Ce n'est vrai que si le polygone membre de la 
relation a des tags qui sont listés dans le fichier de style. A l'extrême, si 
tu as donc un batiment avec un trou, et que le trou est représenter par un way 
fermé, sans aucun tag, il ne finira pas seul dans la table polygone. Il n'y 
sera que comme "trou" du bâtiment représenté par la relation.

> Dans mon cas j'aimerais bien pouvoir récupérer l'ID du way ayant le rôle
> "outer". 

Je devine que tu essayes de faire une magouille pour combler un autre problème 
;-)
Si tu veux le bâtiment, ne prend pas le trou qui n'est pas un bâtiment car 
c'est un trou ;-) Dis plutôt à ton appli ce qu'est un trou !

Mais à chacun son workflow, je ferais ça en postgis directement avec 
ST_ExteriorRing
http://www.postgis.org/docs/ST_ExteriorRing.html

-- 
sly, direct contact : sylv...@letuffe.org
http://wiki.openstreetmap.org/wiki/User:Sletuffe

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

Re: [OSM-dev-fr] [OSM-talk-fr] Base de données pour le développement

[sly (sylvain letuffe)]

Le samedi 21 février 2015 13:55:58, Vincent Frison a écrit :
> Le serveur api06.dev.openstreetmap.org est tombé depuis hier (minimum), ça
> arrive souvent ?

Je ne m'en sers que rarement, je ne saurais dire

-- 
sly (sylvain letuffe)
http://wiki.openstreetmap.org/wiki/User:Sletuffe

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

Re: [OSM-dev-fr] [OSM-talk-fr] Base de données pour le développement

[sly (sylvain letuffe)]

On jeudi 12 février 2015, Vincent Frison wrote:

> osm2pgsql SVN version 0.87.2-dev (64bit id space)
(...)
> Reading in file: /home/turman/Workspace/JOSM/testing.osm
> Erreur de segmentation

Je viens de passer à la toute dernière version d'osm2pgsql (qui indique comme 
toi osm2pgsql SVN version 0.87.2-dev (64bit id space))

et tout se passe bien.

> Et si je ne mets quelques nodes dans le XML ça marche.. du coup ça me fait
> penser à un bug de osm2pgsql mais sly je veux bien que tu m'envoie ton XML
> de Paris.. ou que je t'envoie le mien :)

Ok, je propose de faire l'échange, ça nous dira si ça vient plutôt du fichier, 
ou du osm2pgsql
Celui sur lequel je teste :
http://sly.letuffe.org/echange/test-paris-sur-dev-serveur.osm

-- 
sly
qui suis-je : http://sly.letuffe.org

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

Re: [OSM-dev-fr] [OSM-talk-fr] Base de données pour le développement

[sly (sylvain letuffe)]

pré-scriptum: je me demande si on ne serait pas mieux sur la liste dev-fr :
https://lists.openstreetmap.org/listinfo/dev-fr
pour ce genre de sujet.

On jeudi 12 février 2015, Vincent Frison wrote:
> Le problème c'est que osm2pgsql plante dès que j'importe un fichier OSM
> contenant des éléments provenant de l'API de test (erreur de segmentation
> et strace ne donne pas d'infos supplémentaires très utiles).

Tu peux indiquer la sortie standard de ton osm2pgsql ?


> J'ai par exemple téléchargé depuis JOSM les quelques bâtiments présents
> dans l'API de test qui sont juste en dessous la Gare de Lyon (tours Gamma
> et Natixis), bâtiment que j'avais uploadé il y a quelques jours. Mais
> osm2pgsql ne veut pas digérer le fichier généré alors qu'évidemment ça
> passe très bien si c'est un fichier OSM de la même zone mais exporté depuis
> le vrai serveur. 

Je viens de tenter exactement ce que tu indiques et je n'ai eu aucun problème.
Ma méthode :
JOSM -> F12 -> http://master.apis.dev.openstreetmap.org/api
Télécharger tout Paris (donc garde de Lyon)
Calques -> bouton droit -> enregistrer sous test.osm

Puis commande :
cat /tmp/test.osm /home/ressource-for-osm/osm2pgsql/osm2pgsql --create -p test 
--unlogged -C 1000 --number-processes=3 -p test -m -G -s -S ./osm2pgsql-
choosen.style -d gis -r libxml2 /dev/stdin

Début de mon fichier test.osm :


  


> Il faut donc croire que les bâtiments que j'ai uploadé sur
> l'API de test ne sont pas complètement valides.. mais c'est assez étonnant
> puisque j'ai bien réussi à les uploader.
> 
> Pour info j'utilisais une veille version d'osm2pgsql puisque c'était celle
> de Debian Wheezy (0.80). J'ai donc compilé non sans mal la version Git
> (0.87) mais le problème est exactement le même.
> 
> J'essayerai de refaire des tests de ce soir notamment avec les fichiers du
> cadastre.. ou avec un fichier contenant juste un seul bâtiment pour essayer
> de comprendre où est le problème.
> 
> 
> 
> Le 11 février 2015 08:27, Christian Quest  a écrit
> 
> >  Euh... en appelant l'API ?
> > 
> > Pour un test un 'map' sur une petite zone que tu aura préchargé en
> > bâtiment comme je l'avais indiqué devrait aller, non ?
> > 
> > 
> > http://wiki.openstreetmap.org/wiki/API_v0.6#Retrieving_map_data_by_boundi
> > ng_box:_GET_.2Fapi.2F0.6.2Fmap
> > 
> > Ce que je ferai (encore plus simple):
> > - récup des bâtiments d'un arrondissement sur cadastre.openstreetmap.fr
> > - ouverture dans JOSM, envoi des bâtiments sur l'API de test
> > - après upload, enregistrement dans un fichier .osm (donc tu as les ID
> > attribuées par l'API de test)
> > - import dans postgres avec osm2pgsql de ce .osm
> > - test de ton script sur l'API de test
> > 
> > Le 10/02/2015 22:42, Vincent Frison a écrit :
> >  Le 10 février 2015 21:46, Christian Quest  a
> > 
> > écrit :
> >>  Il sufit de charger dans ton postgres de test non pas la base OSM
> >> 
> >> normale, mais une récupération des données sur l'API de test... là tu
> >> aura tout synchro pour tes tests.
> >> 
> >> Une fois que tout est ok, tu recharge les vraies données OSM et tu
> >> relance ton script.
> >> 
> >  Merci Christian.. mais question sans doute un peu bête: comment je fais
> > 
> > pour récupérer les données de l'API de test ?
> > 
> > 
> > 
> > ___
> > Talk-fr mailing
> > listTalk-fr@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/ta
> > lk-fr
> > 
> > 
> > --
> > Christian Quest - OpenStreetMap France
> > 
> > 
> > ___
> > Talk-fr mailing list
> > talk...@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-fr


-- 
sly
qui suis-je : http://sly.letuffe.org

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

Re: [OSM-dev-fr] [tech] Downloads changesets

[sly (sylvain letuffe)]

Le dimanche 18 janvier 2015 18:24:59, sly (sylvain letuffe) a écrit :
> Le samedi 17 janvier 2015 18:57:10, Rodolphe Quiedeville a écrit :
> > >> Je travaille sur une projet où j'ai besoin d'avoir l'intégralité des
> > >> changesets depuis 2012,
> 
> Si tu as en effet besoin des tags des changesets, alors comme dit
> christian, tu as le dump des changeset. Que tu devra alors relier, par
> l'id au dump de l'historique.

Erratum partiel : je peux me tromper car un fichier de 60Go n'est pas simple 
à manipuler, mais j'ai l'impression qu'il contient également tous les 
changesets 
depuis le numéro 1 (sans les changements hein !) mais avec dater d'ouverture, 
qui, 
fermeture, date, etc. et, je crois bien (à vérifier tout de même c'est la plus 
une 
supposition qu'une certitude), les tags (quand ils ont commencé à exister)

$ wget -q http://planet.osm.org/planet/full-history/history-latest.osm.bz2 -O - 
| bunzip2 | head -n 10 

  

 
http://opendatacommons.org/licenses/odbl/1-0/"; 
copyright="OpenStreetMap and contributors" version="0.6" 
generator="planet-dump-ng 1.0.0" 
attribution="http://www.openstreetmap.org/copyright"; 
timestamp="2015-01-12T02:00:00Z">   


 http://www.openstreetmap.org/api/0.6"/>   

     
 
 
 
 
 
 
 


hs: J'apprend avec étonnement un champs "nombre de changements par changeset" + 
bbox qui pourrait donner 
de bonnes infos de stats.


-- 
sly (sylvain letuffe)
http://wiki.openstreetmap.org/wiki/User:Sletuffe

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

Re: [OSM-dev-fr] [tech] Downloads changesets

[sly (sylvain letuffe)]

Le dimanche 18 janvier 2015 17:53:25, Pierre Béland a écrit :
> Sur la page http://planet.osm.org/ on parle aussi d'obtenir uniquement les
> métadonnées des changesets. 
(..)
> Quelqu'un sait où retrouver cette info? Pierre

Il me semble que c'est exactement le lien que christian vient de donner



> 
>   De : Christian Quest 
>  À : "dev-fr@openstreetmap.org >> Discussions développeur OSM en français"
>  Envoyé le : Dimanche 18 janvier 2015 11h19
>  Objet : Re: [OSM-dev-fr] [tech] Downloads changesets
> 
> Tu a besoin de quoi au juste ?Les infos sur les changesets ou ce qu'ils
> contiennent ?
> 
> Il y a un dump des
> changesets: http://planet.openstreetmap.org/planet/changesets-latest.osm.b
> z2
> 
> 
> 
> Le 17 janvier 2015 18:57, Rodolphe Quiedeville  a
> écrit :
> 
> Merci pour a suggestion Sylvain, j'ai effectivement mal orientée celle-ci,
> c'est plus du dev qu'un point technique, je reroute ma question sur dev.
> 
> Merci pour ta réponse au passage Frédéric
> 
> On 01/17/2015 01:10 PM, sly (sylvain letuffe) wrote:
> 
> J'en profite pour suggéré que cette question trouverait, je pense, plus sa
> place mais également plus de personne pour y répondre sur la liste dev-fr
> 
> 
> Le samedi 17 janvier 2015 11:46:29, Rodolphe Quiedeville a écrit :
> 
> Bonjour,
> 
> Je travaille sur une projet où j'ai besoin d'avoir l'intégralité des
> changesets depuis 2012, pour le moment je récupère les nouveaux
> changesets au fil de l'eau en utilisant les minutely diff associé à
> l'api 0.6. Mais avant de requetter l'API pour récupérer les 28 millions
> que me manque je me demandais si ils n'existaient pas quelques parts.
> Que ce soit dans un fichiers, un lot de fichiers ou une base quelconque,
> merci pour vos tuyaux.
> 
> Bon WE

-- 
sly (sylvain letuffe)
http://wiki.openstreetmap.org/wiki/User:Sletuffe

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

Re: [OSM-dev-fr] [tech] Downloads changesets

[sly (sylvain letuffe)]

Le samedi 17 janvier 2015 18:57:10, Rodolphe Quiedeville a écrit :

> >> Je travaille sur une projet où j'ai besoin d'avoir l'intégralité des
> >> changesets depuis 2012, 

Si tu as en effet besoin des tags des changesets, alors comme dit christian, 
tu as le dump des changeset. Que tu devra alors relier, par l'id au dump de 
l'historique.

> >> pour le moment je récupère les nouveaux
> >> changesets au fil de l'eau en utilisant les minutely diff associé à
> >> l'api 0.6. 

Ces minutes diffs ne contiennent pas les tags du changeset, donc si tu peux 
t'en passer, alors tu n'a pas besoin de coupler ça avec le dump des changeset, 
et comme le propose fred, télécharger les "full history dumps" devient à mon 
avis la solution la plus efficace, à condition que ton parseur soit ré-écrit 
pour traiter ces fichiers.


> >> Mais avant de requetter l'API pour récupérer les 28 millions


Ho oui, très mauvaise idée ! tu en as pour un bout de temps, sans compter les 
admins qui ne verraient pas ça d'un bon oeil !

> >> que me manque je me demandais si ils n'existaient pas quelques parts.
> >> Que ce soit dans un fichiers, un lot de fichiers ou une base quelconque,
> >> merci pour vos tuyaux.
> >> 
> >> Bon WE

-- 
sly (sylvain letuffe)
http://wiki.openstreetmap.org/wiki/User:Sletuffe

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

Re: [OSM-dev-fr] requete sql

[sly (sylvain letuffe)]

On jeudi 11 décembre 2014, didier2020 wrote:
> une troncon de route n'a pas de comptage/temps,
> mettre a jour ce troncon en prenant comme modele les données du troncon
> en amont/précédent avec un coef d'ajustement lié aux caractéristiques
> des 2 troncon.

Et si tu est présenté avec 3 tronçons consécutifs (t1,t2,t3) dont tu ignores 
le temps, tu fais quoi pour t2 ?
Tu calculs t1 d'abord et tu repasses ton algo pour trouver t2 ?
Et si tu as 30 tronçons consécutifs ? une boucle ?
gestion des valeurs invalides ? vitesse max : -5 ou 0 ou 250 ?

Y'a un moment où SQL ne suffit plus, ma philosophie de développement+sgbd :
Dès que je suis tenté de mettre un if, c'est qu'il ne faut plus faire ça en 
SQL ;-) 

-- 
sly
qui suis-je : http://sly.letuffe.org

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

Re: [OSM-dev-fr] Différences entre taginfo-fr et oapi-fr

[sly (sylvain letuffe)]

Ha, et j'oubliais une question, mais cette fois de fond, "que veut-on que ces 
outils contiennent ?"

Selon l'usage on peut vouloir 
1) "tous les ways/relation ayant un noeud en france et tant pis si ça déborde"
ou 
2) "uniquement les ways/relations n'ayant aucun noeud en dehors de france" et 
tant pis s'il en "manque"

Dans le cas de statistiques, 1) me semble préférable ; dans le cas où l'on 
veut faire une modification générale à la france sans toucher (ni énerver) nos 
voisins 2) me semble plus "conservatif", peut-être préférable.
Ce qui, même si ça n'a pas été voulu, tombe alors plutôt bien ;-)


ps: 4ème hypothèse technique, oapi-fr utilise des minutes diff, taginfo-fr un 
full import chaque nuit, le découpage des diffs peut éventuellement ne pas 
utiliser un algo identique que le full-export.

-- 
sly
qui suis-je : http://sly.letuffe.org

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

Re: [OSM-dev-fr] Différences entre taginfo-fr et oapi-fr

[sly (sylvain letuffe)]

(avec toutes ces listes, on se perd, je transfert le sujet sur dev-fr car ça 
me semble tourner à du assez technique donc un peu HS pour talk-fr, et comme 
françois semble aussi inscrit sur dev-fr, ça devrait aller)

Premièrement, quelques faits :


On mardi 25 février 2014, Christian Quest wrote:
> Il faudrait que taginfo-fr s'appuie non pas sur les extrait/diff de
> geofabrik, mais ceux d'osm-fr...

geofabrik ne propose que des daily diffs, et d'après ce que je vois dans le 
code, taginfo-fr se base sur les extraits france de 
http://download.openstreetmap.fr/extracts/europe/france.osm.pbf
donc, comme l'oapi-fr
Jusqu'ici, ça part bien.

> >>> taginfo-fr tient-il compte des DOM-TOM (oapi-fr non) ?

Utilisant la même source qui ne les contient pas, les DOM-TOM ne sont ni dans 
taginfo ni dans oapi-fr

Alors ? qu'est-ce qui se passe ?

Et bien... bonne question ;-)

françois : est-ce que les 2 éléments que tu trouves sur taginfo-fr tu arrives 
à les retrouver ? est-ce que par hasard tu les aurais pas "corrigé" mais c'est 
juste que taginfo-fr n'est pas encore à jour (oapi se met à jour en temps réél 
et taginfo-fr, chaque nuit) ?

Autre hypothèse, taginfo parle de frontières :
"geodistribution": {
"left": -5.46,
"bottom": 41.23,
"right": 9.80,
"top": 51.22
}

est-ce que ça oublie une ile française dans un coin ?

Dernière hypothèse, dans le cas d'un way qui aurait une partie de ces noeuds 
hors de france, taginfo l'inclus dans sa base, alors que opai-fr non, car il 
est incomplet ?

-- 
sly
qui suis-je : http://sly.letuffe.org

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

Re: [OSM-dev-fr] Overpass API et Talend

[sly (sylvain letuffe)]

On lundi 24 février 2014, Eric Pommereau wrote:
> Bonjour,

Hello,

> Quelqu'un a déjà testé le traitement d'une requête overpass API dans l'ETL
> Talend ?
> Deux composant OsmWayInput / OsmNodesInput le permettent 

Je préfère le dire tout de suite, j'ai rien compris à ces trois phrases, je 
connais pourtant assez bien l'API 0.6 et l'Overpass API, mais le fait 
d'introduire des éléments sur un logiciel dont on a jamais entendu parlé sur 
cette liste n'aide pas à la compréhension de ta question et donc augmente 
encore la difficulté à y répondre.

Habituellement, dans un cas comme ça, je ne répond pas (vu que je ne sais 
pas/ne comprends pas) mais comme je n'avais rien compris non plus à ton 
précédent message sur les "Contours de communes et arrondissements PLM" alors 
que c'est aussi un sujet que je comprend bien dans osm, je me dis que peut-
être tu devrais simplifier la formulation de ton problème, sachant que la 
thématique à l'air intéressante.


Revenons à ce cas concret, je ne sais pas non plus ce qu'est "ETL talend", 
mais si c'est un "truc" qui appel des données osm par une API il faut voir à 
quel point il peut être paramétré et customisé (as-tu accès au code ? es-tu 
développeur de l'outil ? quelles options peuvent être touchées ?)

Si tu ne peux pas toucher le code, pas choisir le "end point" de l'api appelé, 
alors c'est vite vu, tu ne pourra pas faire grand chose...

> mais sur l'api,

Sais-tu quelle est l'api appelée ? est-ce l'api 0.6 de 
http://api.openstreetmap.org/api/0.6/ ?
une xapi ?


> non sur overpass. Quelle est la différence entre les deux ? 

Elles peuvent sortir exactement le même type de contenu (des noeuds, ways et 
relation en provenance d'osm au format .osm) mais n'ont pas du tout les mêmes 
méthodes d'appel :
http://wiki.openstreetmap.org/wiki/Api06
http://wiki.openstreetmap.org/wiki/Overpass_API

En outre, l'api 0.6 fourni sur http://api.openstreetmap.org a pour objectif 
d'être utilisé principalement pour l'édition des données et non pour la 
consommation des données.
Une utilisation importante pourrait amener à un bannissement.

> Et existe-t-il
> un moyen de faire correspondre les sorties 

ça veut dire quoi ? si c'est pour avoir le même format en sortie, voir la 
réponse de frédéric et l'option "meta"

-- 
sly
qui suis-je : http://sly.letuffe.org
___
dev-fr mailing list
dev-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev-fr

Re: [OSM-dev-fr] Service de pré-intégration d'adresses

[sly (sylvain letuffe)]

On mardi 18 février 2014, Tyndare wrote:
> Merci aussi à toi Sylvain pour le site web du cadastre dont on a
> effectivement repris sans scrupules la page web.

Plus ou moins rien sur ce site n'est de moi, je n'en fais que la maintenance.
 
> Si on décide de rendre le service accessible au plus grand nombre, il
> faudra qu'on discute si c'est souhaitable et envisageable de rendre les
> deux services (Quadastre2OSM et adresses) accessibles ensemble depuis la
> page web principale, avec par exemple un «radio button» pour choisir entre
> les deux.

Séparé, ou regroupé, pour moi, ça ne pose aucun problème, c'est comme ça vous 
arrange (surtout qu'étant une quiche en html/css, c'est vous qu'y aller y 
faire !)

> Le problème de la génération d'adresse c'est (qu'en plus d'être moins
> stable) elle est beaucoup plus lente, il faudrait donc à mon avis garder un
> retour à l'utilisateur sur l'avancée de l'opération.
> 
> Pour trac, si on peut garder le même composant ça me vas très bien,
> J'ai aussi créé un compte trac: tyndare

J'ai trouvé une combine pour que le lien qui dit "j'ai trouvé un bug" pointe 
directement vers trac en mettant vdct en auteur, ça m'évitera de faire le 
routeur de ticket.
Je vous laisse vous les ré-échanger


-- 
sly
qui suis-je : http://sly.letuffe.org
___
dev-fr mailing list
dev-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev-fr

Re: [OSM-dev-fr] Service de pré-intégration d'adresses

[sly (sylvain letuffe)]

On lundi 17 février 2014, Vincent de Château-Thierry wrote:
> Merci à Jocelyn et Christian pour leur support et la mise à disposition 
> d'une infrastructure d'OSM-Fr, qui héberge le service.

En reprenant la page d'accueil de http://cadastre.openstreetmap.fr, vous avez 
également repris le lien permettant l'ouverture d'un ticket sur trac, dont un 
premier a d'ailleurs été ouvert :
http://trac.openstreetmap.fr/ticket/483

Si vous ne souhaitez pas utiliser trac, je vous suggère de retirer le lien.
Si par contre vous le souhaitez, je peux définir un "composant" sur trac rien 
que pour cet outil si vous préférez.
Ou alors, on peut partager le même composant, je n'y vois pas d'inconvénients, 
mais si l'un de vous (ou les deux) pouvait créer ou me donner son compte sur 
trac.openstreetmap.fr, je pourrais alors vous "ré-attribuer" les tickets.

-- 
sly
qui suis-je : http://sly.letuffe.org
___
dev-fr mailing list
dev-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev-fr

Re: [OSM-dev-fr] Fichier comparaison cours d'eau

[sly (sylvain letuffe)]

On lundi 17 février 2014, Sylvain Maillard wrote:
> Salut,

hello,

> les "trous" dont tu parles, c'est tous le bas de la liste des cours d'eau
> qui aparaissent en 0% ?

Et qui sont véritablement dans osm.
Il en existe qui ne sont pas dans osm et eux, c'est normal qu'ils soient 
listés à 0%, mais il y en a plein qui ne devraient pas être à 0%.

Je viens de tenter une opération, on va voir ce soir si le calcul arrive à 
combler quelques trous...

> il y a sans doute quelques améliorations qui pourraient être faites:

Ça ! Les idées d'améliorations ne manquent pas, mais je vais déjà tenter de le 
faire marcher tout court, et ça sera déjà pas mal.
Bien sûr, si quelqu'un voit en cet outil un bon potentiel et a envie de 
rajouter des fonctions, c'est avec plaisir !

> - on a 156% du Rhône, mais parce que la relation osm part de la source du
> Rhône en suisse. Est-ce qu'il serait possible de ne pas prendre en compte
> les tronçons hors de france ? (même chose pour le Rhin: 690% !)
> 
> 
> 
> Sylvain
> 
> 
> 
> 
> Le 17 février 2014 15:05, sly (sylvain letuffe)  a
> écrit :
> 
> >  On jeudi 6 février 2014, sly (sylvain letuffe) wrote:
> >
> >
> >
> > > ps: je vais sans doute faire un ré-import total de la base, et à partir
> > de
> >
> > > là,
> >
> > > il faudra ouvrir l'oeil afin de voir à partir de quand ça déconne, sur
> > quel
> >
> > > rivière et voir si une édition en particulier aurait pu être le
> > déclencheur.
> >
> > > Je remettrais un mail pour dire quand c'est fait et si c'est fait.
> >
> >
> >
> > J'ai donc ré-importé toute la base, et un calcul a été refait hier soir
> > (un autre devrait survenir ce soir 19h00)
> >
> >
> >
> > Le résultat n'est pas glorieux :
> >
> >
> > http://suivi.openstreetmap.fr/longeur-cours-eau-france/comparaison-
sandre.html
> >
> >
> >
> > C'est pas autant troué que la dernière fois, mais ça l'est déjà quand même
> >
> > (par exemple "Le Lot", mais bien d'autre encore)
> >
> >
> >
> > Mais j'ai mal géré mon histoire, j'ai relancé les mises à jour tout de
> > suite après l'import, ce qui fait que je n'ai pas laissé le temps de voir
> > si le problème était déjà là à la fin de l'import, où s'il était lié au
> > mise à jour ultérieures.
> >
> > Coté des limites administratives, qui manquaient, elles aussi en nombre
> > dans cette base, tout semble s'être réparé :
> >
> > http://suivi.openstreetmap.fr/communes/communes.csv.txt
> >
> >
> >
> >
> >
> >
> >
> > --
> >
> > sly
> >
> > qui suis-je : http://sly.letuffe.org
> >
> >
> >
> > ___
> > dev-fr mailing list
> > dev-fr@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/dev-fr
> >
> >
> 


-- 
sly
qui suis-je : http://sly.letuffe.org
___
dev-fr mailing list
dev-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev-fr

Re: [OSM-dev-fr] Fichier comparaison cours d'eau

[sly (sylvain letuffe)]

On jeudi 6 février 2014, sly (sylvain letuffe) wrote:

> ps: je vais sans doute faire un ré-import total de la base, et à partir de
> là, 
> il faudra ouvrir l'oeil afin de voir à partir de quand ça déconne, sur quel 
> rivière et voir si une édition en particulier aurait pu être le déclencheur.
> Je remettrais un mail pour dire quand c'est fait et si c'est fait.

J'ai donc ré-importé toute la base, et un calcul a été refait hier soir (un 
autre devrait survenir ce soir 19h00)

Le résultat n'est pas glorieux :
http://suivi.openstreetmap.fr/longeur-cours-eau-france/comparaison-sandre.html

C'est pas autant troué que la dernière fois, mais ça l'est déjà quand même
(par exemple "Le Lot", mais bien d'autre encore)

Mais j'ai mal géré mon histoire, j'ai relancé les mises à jour tout de suite 
après l'import, ce qui fait que je n'ai pas laissé le temps de voir si le 
problème était déjà là à la fin de l'import, où s'il était lié au mise à jour 
ultérieures.
Coté des limites administratives, qui manquaient, elles aussi en nombre dans 
cette base, tout semble s'être réparé :
http://suivi.openstreetmap.fr/communes/communes.csv.txt



-- 
sly
qui suis-je : http://sly.letuffe.org
___
dev-fr mailing list
dev-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev-fr

Re: [OSM-dev-fr] Fichier comparaison cours d'eau

[sly (sylvain letuffe)]

On jeudi 6 février 2014, Ab_fab wrote:
> hier sandre.html>laisse
> penser à des défauts pour la Loire et la Meuse.
> Est-ce qu'il y a eu une intervention sur la base concernée ?

Pas de ma part en tout cas, et en effet, c'est assez étrange, mais ça 
ressemble à une perte d'info à nouveau pour ces 2 fleuve/rivière


> J'ai le souvenir que Jocelyn avait fait des imports individuels de cours
> d'eau. Donc c'est pas la première fois que cela est nécessaire.
> Je peux me tromper, mais je crois que quand OSM7 a été relancé à l'automne,
> c'était avec une base neuve mais sans les ajustements de schéma concernant
> les cours d'eau. Est-ce que c'est à cette occasion que cela part du mauvais
> pied ?

Oui, c'est pas impossible que ça puisse avoir un lien, nous n'utilisons plus 
tout à fait la même méthode qu'avant pour construire les relations 
type=waterway
Bien que les tests semblaient bon, il est possible que la procédure de mise à 
jour déconne et soit la cause de la disparition progressive de cette liste.

Je vais en causer avec jocelyn pour voir s'il a une idée.

ps: je vais sans doute faire un ré-import total de la base, et à partir de là, 
il faudra ouvrir l'oeil afin de voir à partir de quand ça déconne, sur quel 
rivière et voir si une édition en particulier aurait pu être le déclencheur.
Je remettrais un mail pour dire quand c'est fait et si c'est fait.

-- 
sly
qui suis-je : http://sly.letuffe.org

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

Re: [OSM-dev-fr] Fichier comparaison cours d'eau

[sly (sylvain letuffe)]

Le mercredi 5 février 2014 10:20:03, Sylvain Maillard a écrit :
> c'est quelle version de la BDCarthage qui est utilisée pour la comparaison
> ?

Et bien je ne me rappel plus précisément où j'ai récupéré ça, je peux juste 
dire que ça a environ 2ans et il me semble, mais sans certitudes, que c'était 
dispo sur le site du sandre.

Quoi qu'il en soit, la longeur des cours d'eau n'ayant pas vraiment changé en 
2 ans, je suppose que la fraicheur de ma source n'est pas la priorité sur 
laquelle je dois travailler, mais plutôt tenter de voir pourquoi des données 
disparaissent de la copie de la base.

Si vraiment je constate trop de numéro de référence sandre qui ont changée, je 
m'occuperais alors de comparer avec une source plus récente (mais ça oblige de 
regarder comment elle est faite, l'importer, la vérifier, enfin bref, un peu 
de boulot quoi)


-- 
sly (sylvain letuffe)
http://wiki.openstreetmap.org/wiki/User:Sletuffe

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

Re: [OSM-dev-fr] Fichier comparaison cours d'eau

[sly (sylvain letuffe)]

On mardi 4 février 2014, Ab_fab wrote:
> Bonjour,

Hello,

> J'ai fait une passe sur le rapport généré chaque jour pour comparer les
> longueurs entre la base Sandre et OSM [1].

Na de diou, quel rapport de bug complet et travaillé !
J'ai pas trop le choix là, il va falloir que je regarde ;-)

>1.
Il faudrait voir si une autre source plus récente en provenance du sandre 
pourrait 
nous servir de base, et donc, améliorer la détection...

>2. Incohérence entre le nom dans OSM et celui de la base Sandre

Cela ne devrait pas entrer en ligne de compte, la comparaison est faite 
entre un fichier (ancien) en provenance du sandre uniquement sur la base 
de la référence sandre :
https://github.com/osm-fr/suivi-export/blob/master/longeur-cours-eau-france/suivi-cours-eau.php#L143
 
>5. RAS
>La relation est-elle dans la base servant à générer le rapport ?

J'ai bien l'impression que plusieurs fois ce n'est pas le cas.

J'ai testé avec "le Clain" (ref = L2--0160)
osm=> select name from planet_osm_line where hstore(tags)->'ref:sandre' = 
'L2--0160';
 name 
--
(0 ligne)

Avec la Vilaine (J---006A) c'est bon par exemple

En clair, il y a un problème de "fuite" dans l'import
Pour le clain, je viens de tenter un ré-import seulement pour cette relation et 
ça s'importe correctement.
Donc... c'est pas les données ou en tout cas pas que.
Mais le processus de mise à jour ou osm2pgsql qui fait qu'a partir d'un 
événement que je nommerais "x" par convention et aussi car j'ignore de quoi il 
s'agit la géométrie de la 
relation est jetée à la poubelle.

J'ai suivi les fils dans tous les sens et je ne parviens pas à qualifier "x" ni 
par une date ni par une autre caractéristique.
Je peux juste dire que la base d'osm13 n'est pas touchée par ce problème.
Je peux dire qu'aucune des géométries qui compose chaque chemin du Clain n'est 
présente dans la base d'osm105
La demande de reconstruction par un pending='t' de la géométrie de tous les 
ways n'y change rien

La piste la plus probable serait qu'il manque des noeud dans la base locale (le 
fichier flat-nodes) mais je ne sais 
pas comment l'interroger pour confirmer cela.

La seule chose que je vois est donc une ré-importation complète de la base
-- 
sly
qui suis-je : http://sly.letuffe.org

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

Re: [OSM-dev-fr] Serveur de tuiles pour le rendu humanitaire

[sly (sylvain letuffe)]

On jeudi 16 janvier 2014, Christian Quest wrote:
> Le 16 janvier 2014 11:20, Pieren  a écrit :
> 
> > Il faudrait effectivement internationaliser cette tuile
(...)
> Tout à fait... 

Vous en pensez quoi ?
http://a.layers.openstreetmap.fr/images/404.png

(un peu vite fait, mais en attendant qu'un artiste nous fasse un chouette 
truc, ça a l'avantage d'être en anglais)

> et mettre en place aussi des caches pour soulager l'unique
> serveur qui est derrière ce rendu (et qui ne fait pas que ça).

Un cache ? Est-ce vraiment le débit le problème ?
Je n'ai pas l'impression :
http://munin.openstreetmap.fr/free.org/osm13.openstreetmap.fr/if_eth0.html

Je n'ai pas étudié la question en profondeur, mais ça me semble plus une 
histoire de charge io/cpu
Ça serait plus une répartition de charge à faire avec osm105 par exemple pour 
soulager la charge à 15 de moyenne actuellement sur osm13


-- 
sly
qui suis-je : http://sly.letuffe.org

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

Re: [OSM-dev-fr] Ombrage et relief...

[sly (sylvain letuffe)]

Le dimanche 12 janvier 2014 18:51:59, yvecai a écrit :
> C'est bon, mod_tile était compilé en 'png256'. Ca marche nickel maintenant.

P'tain,

a 10mn prêt je donnais la réponse !

Pour info, la liste "tile-serving" est intéressante pour suivre la chaine de 
rendue :
osm2pgsql / mod_tile / renderd / mapnik

Par exemple, le message du 8 janvier :
https://lists.openstreetmap.org/pipermail/tile-serving/2014-January/000788.html

"Rendering meta tiles with mod_tile/renderd always made my hillshade look ugly. 
This results in the 8 bit PNGs, which Mapnik doesn't rasterize as nice as 
imagemagick does"

Et un quick hack dont je ne retrouve plus le lien, mais je pense que c'est 
exactement ce que tu as fais :
changer "png256" en "png" dans le code de renderd


-- 
sly (sylvain letuffe)
http://wiki.openstreetmap.org/wiki/User:Sletuffe

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

Re: [OSM-dev-fr] Shapé les admin_level=boundary

[sly (sylvain letuffe)]

On lundi 16 décembre 2013, Rodolphe Quiédeville wrote:
> Bonjour,
yo,

> voir une méthode à implémenter.
(...)
> mais il me faudrait les
> limites nationales des pays européens désormais.

osm forcément ? parce que ça risque bien de ne pas être une partie de plaisir, 
Il te faudra peut-être gérer les :
http://fr.wikipedia.org/wiki/Région_ultrapériphérique (européennes)
Et le fait que l'on trouve dans la base surtout les limites avec eaux 
territoriales 

Mais en gros, tu dois pouvoir obtenir ça :
http://layers.openstreetmap.fr/?zoom=5&lat=48.08543&lon=12.71091&layers=000B0FFFTFF
(tiens, y'a pas d'ukraine)

avec :
une base osm2pgsql à disposition couvrant l'europe ou plus
une requête SQL qui va bien 
(genre : select geometrie from polygones where admin_level=2 and geometrie is 
in 'europe' )
l'utilitaire pgsql2shp
et ça devrait te sortir un shapefile se rapprochant de ta demande


-- 
sly
qui suis-je : http://sly.letuffe.org

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

Re: [OSM-dev-fr] Simplifier nos limites admin...

[sly (sylvain letuffe)]

Le dimanche 15 décembre 2013 21:03:56, Christian Quest a écrit :
> La seule chose absolument pas gérées ce sont des polygones en 8.
> J'en ai identifié 2 et en reprenant le cadastre, le 8 n'avait pas lieu
> d'être.

Attention à ne pas céder à la tentation du "je corrige les données pour 
compenser un manque dans mon algo ;-)"

Le multipolygon en 8 est valide au sens OGC (j'avais écrits ce récapitulatif 
avec exemple des cas courant :
http://wiki.openstreetmap.org/wiki/Relation:multipolygon/validity )

Il y a cependant plus de chance que ça soit une erreur de saisie que de la 
vrai donnée en "8"


-- 
sly (sylvain letuffe)
http://wiki.openstreetmap.org/wiki/User:Sletuffe

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

Re: [OSM-dev-fr] [OSM-talk-fr] Convertir les données de type polygones en noeud (gpx, csv, osm) ( était : umap problème de =?iso-8859-1?q?_requ=EAte?=)

[sly (sylvain letuffe)]

Le samedi 14 décembre 2013 22:50:41, Vincent Pottier a écrit :
> Ça peut se faire ?

ça peut, et je m'ennuyais ce matin, alors c'est fait ;-)

Le wrapper cité ici supporte également la syntaxe overpass API
http://wiki.openstreetmap.org/wiki/Servers/api.openstreetmap.fr#Simplified_exports_where_ways.2Fnodes_are_simplified_to_GPX_or_OSM_waypoint.2Fnode_.28test.29

(je note d'ailleurs que pour pas bien plus cher, on pourrait même avoir la 
sortie au format csv dont parlait un autre fil de discussion)

-- 
sly (sylvain letuffe)
http://wiki.openstreetmap.org/wiki/User:Sletuffe

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

Re: [OSM-dev-fr] Trouver des objets ne possédant pas certains tags

[sly (sylvain letuffe)]

Le jeudi 05 décembre 2013 22:51:12, François Lacombe a écrit :
> Bonsoir,

Bonsoir,

> Je souhaite savoir si dans le modèle de données retenu par OSM il est
> possible de retrouver des objets ne possédant pas certains tags.

A supposer donc que ça soit théorique comme questionnement.

C'est pas clair pour moi tout ça, de quel "modèle retenu par OSM" tu parles ?
Celui des noeuds/ways/relation avec des tags ?

Le modèle ne me semble pas empêcher ta demande, charge à celui qui veut le 
faire de trouver le bon format de stockage et le bon algo.

Je dois pas bien comprendre la question...

> Je cherche actuellement à mettre au point une requête SQL qui retrouve des
> enregistrements qui ne possèdent pas certaines clés.

Là, c'est du concret ? ou on est toujours dans les nuages du théorique ?
Si tu veux te fixer sur l'utilisation de SQL (juste avant tu disais "avec 
overpass par exemple, mais overpass n'utilise pas SQL) il te reste à trouver 
un schéma (structure de base de donnée le permettant)
 
Le schéma tout fait tout prêt avec convertisseur .osm -> sql de osm2pgsql te 
permet un truc genre :
"select * from planet_osm_line where highway is NULL"

ça te sort tous les chemins qui n'ont pas de tag highway


-- 
sly (sylvain letuffe)
http://wiki.openstreetmap.org/wiki/User:Sletuffe

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

Re: [OSM-dev-fr] compression des flux osm ( était Extraction thématique ( était Verification du routage))

[sly (sylvain letuffe)]

On lundi 2 décembre 2013, Pierre Béland wrote:
> Je pense à plusieurs contextes où la bande passante cause problème. Pensons,
> par exemple, aux divers pays africains. Un fichier bzip réduirait de façon
> très significative la bande passante utilisée pour transférer le fichier.

Pour transférer le fichier osm ?
On compare gzip avec bzip2 ici ? La différence me semble pas être qualifiable 
de "très significative"

Donc, le plus probable est que tu n'est pas fais attention à la phrase de 
christian :
"mais le transfert sur le réseau est gzippé à ce qu'il me semble"
Est c'est le cas en effet, de manière transparente, pour tout navigateur de 
moins de 10ans (en afrique ils ont encore ie5 ?) sur les service d'overpass 
api sur les serveurs fr

Et c'est aussi dispo sur curl et wget à condition d'activer ce qui aurait dû, 
à mon avis, être par défaut (la fameuse option --compress dont il était 
question)

Donc, à 3 (?) % près, la BP sera assez bien optimisée pour envoyer du xml, 
sauf usage inoptimisé de wget/curl


> Pierre 
> 
> 
> 
> 
>  De : Christian Quest 
> À : Discussions développeur OSM en français  
> Envoyé le : Lundi 2 décembre 2013 15h23
> Objet : Re: [OSM-dev-fr]  Extraction thématique (était Verification du 
routage)
>  
> 
> 
> Tu récupère un truc lourd, mais le transfert sur le réseau est gzippé à ce 
qu'il me semble, donc au moins ça ne bouffe pas de la bande passante pour 
rien.
> 
> 
> 
> Le 2 décembre 2013 11:47, Ab_fab  a écrit :
> 
> Bonjour,
> > 
> >J'ai effectivement pu télécharger l'ensemble des waterways par le serveur 
France Overpass-API.
> >400 MO de données .osm non compressées en retour.
> > 
> >J'aurais bien aimé qu'il y ait une option pour obtenir directement un 
fichier compressé (osm.bz2 ou pbf), mais je ne pense pas qu'Overpass API le 
propose.
> >
> >Le 29 novembre 2013 11:26, Frédéric Rodrigo  a 
écrit :
> >
> >
> >>
> >>
> >>
> >>
> >>Le 29 novembre 2013 10:19, Ab_fab  a écrit : 
> >>
> >>
> >>Pour le cas des cours d'eau, l'approche suivante est sympa (*), mais 
nécessite de définir manuellement des points (nodes)clef en début de bassin 
versant de chaque fleuve.
> >>>https://github.com/skaringa/rivers
> >>> 
> >>>Sur ce thème des vérifications de tous ordres, est-ce qu'avoir 
régulièrement une extraction (pbf par ex.) du réseau ferré, de l'hydrographie 
serait utile et pas trop contraignante matériellement pour faciliter le 
travail de ceux qui veulent se pencher sur la question ?
> >>> 
> >>>Je sais que l'on peut le faire en partant d'un extrait Geofabrik et 
filtrer soit-même, mais ça alourdit sensiblement l'opération
> >>
> >>
> >>A mon avis il vaut mieux utiliser l'overpass pour ça.
> >>A titre de comparaison je fait des extractions de tous les transports en 
commun et c'est pas si long que ça a extraire.
> >>
> >> 
> >>--
> >>>(*) en plus des outils de suivi existants
> >>>- http://suivi.openstreetmap.fr/cours-eau/comparaison-sandre.html (à la 
sly)
> >>>- http://suivi.openstreetmap.fr/cours-eau/suivi-affluents.html (à la 
fred)
> >>Il faudrait le remettre en place sur osm7
> >>
> >> 
> >>- http://marani.claude.free.fr/courdo (à la Arno / Claude)
> >>>
> >>>
> >>
> >>___
> >>dev-fr mailing list
> >>dev-fr@openstreetmap.org
> >>https://lists.openstreetmap.org/listinfo/dev-fr
> >>
> >>
> >
> >
> >-- 
> >
> >ab_fab
> >"Il n'y a pas de pas perdus", Nadja
> >___
> >dev-fr mailing list
> >dev-fr@openstreetmap.org
> >https://lists.openstreetmap.org/listinfo/dev-fr
> >
> >
> 
> 
> -- 
> Christian Quest - OpenStreetMap France
> Un nouveau serveur pour OSM... http://donate.osm.org/server2013/
> 
> ___
> dev-fr mailing list
> dev-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/dev-fr


-- 
sly
qui suis-je : http://sly.letuffe.org

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

Re: [OSM-dev-fr] Maintenance serveurs free (osm11/12/13) le lundi 2 décembre

[sly (sylvain letuffe)]

On lundi 2 décembre 2013, Christian Quest wrote:
> C'est un 512Go que j'ai installé sur osm12. Ca risque d'être juste pour y
> mettre une base monde osm2pgsql + l'overpass

C'est même sûr que ça ne va pas tenir.

> On va voir une fois layers migré sur le SSD comment la machine se comporte
> par ailleurs, ok ?

C'est toi qui parlais déjà d'un 2ème ssd, alors vu que t'anticipes, j'anticipe 
aussi (d'ailleurs, on n'est pas encore noël et le ssd y est déjà !)

-- 
sly
qui suis-je : http://sly.letuffe.org

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

Re: [OSM-dev-fr] Maintenance serveurs free (osm11/12/13) le lundi 2 décembre

[sly (sylvain letuffe)]

On lundi 2 décembre 2013, Christian Quest wrote:
> Petit complément hardware:
> 
> Il est possible d'installer 2 cartes Velocity avec SSD dans chaque serveur
> R610 vu qu'elles sont courtes.

C'est ici là liste au père Noël ?

> Les perfs seraient bien sûr supérieures avec 2 SSD en stripping qu'un seul
> SSD.

Le service d'api overpass qui tourne sur une VM d'osm12 (osm103) est devenu de 
plus en plus poussif au fur et à mesure que la base a augmentée de taille et 
que (je soupçonne) le cache RAM est devenu de plus en plus solicité par 
d'autres logiciel des autres VMs et ajouté que je compte activer le support 
des requêtes de type "area" de l'overpass (ce qui consomme toujours plus 
d'i/o)

De ce fait, et selon débat de son utilité relative aux autres outils, 
j'aimerais bien une petite place SSD pour les 190Go actuel de cet outil.

-- 
sly
qui suis-je : http://sly.letuffe.org

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

Re: [OSM-dev-fr] Extraction thématique ( était Verification du routage)

[sly (sylvain letuffe)]

Le lundi 02 décembre 2013 11:47:01, Ab_fab a écrit :
> Bonjour,

hello,

> J'aurais bien aimé qu'il y ait une option pour obtenir directement un
> fichier compressé (osm.bz2 ou pbf), mais je ne pense pas qu'Overpass API le
> propose.

L'overpass API ne le propose pas en effet, mais ça pourrait se faire par 
un "wrapper" coté serveur.

Toutefois, je ne sais pas si la demande serait importante car ceux qui 
utilisent 
un clicodrome style overpassturbo vont télécharger de petits fichier donc pas 
de gros 
besoin d'économie de place sur le disque. Et ceux qui vont récupérer de gros 
fichiers (plus de 100Mo) et qui sont capable d'écrire des requêtes OAPI à la 
main 
ont plus de chance d'utiliser des outils coté client un peu plus poussé, et 
donc 
ça peut se faire coté client :
curl --compress "http://oapi-fr.openstreetmap.fr/oapi/interpreter?data=blabal"; 
| bzip2 > pouf.osm.bz2

Et coté client, on peut s'éclater sans limite sans avoir à écrire des milliers 
de wrapper coté serveur avec the super unix pipe "|" :
curl (...) | osmconvert
curl (...) | bzip2
curl (...) | gzip
curl (...) | osm2pgsql /dev/stdin
curl (...) | osmosis



ésserpmoc àjéd tiaté xulf el euq tnemetsuj tiasicérp éuqidni ia'j euq lruc 
noitpo'l euq 
srola tnemegrahcélét ed spmet ed relap em av iuq nu a ne'y euq eirap ej
-- 
sly (sylvain letuffe)
http://wiki.openstreetmap.org/wiki/User:Sletuffe

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

Re: [OSM-dev-fr] Verification du routage

[sly (sylvain letuffe)]

On vendredi 29 novembre 2013, Ab_fab wrote:
> Sur ce thème des vérifications de tous ordres, est-ce qu'avoir
> régulièrement une extraction (pbf par ex.) du réseau ferré, de
> l'hydrographie serait utile et pas trop contraignante matériellement pour
> faciliter le travail de ceux qui veulent se pencher sur la question ?

Je sais pas si ça répond, mais pour l'hydrographie, y'a(vait) ça :
http://export.openstreetmap.fr/cours-eau/cours-eau/

C'est cassé là maintenant, mais ça se reconstuit à partir d'une base de schéma 
osm2pgsql en export shp
Il doit y avoir ensuite des outils de vérif qui peuvent dire est-ce qu'il y a 
des noeuds qui ne se touche pas, des segments isolés.

Bien sûr, un truc ad-hoc serait sans doute préférable


-- 
sly
qui suis-je : http://sly.letuffe.org

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

Re: [OSM-dev-fr] Reconnaissance debutante de debutants

[sly (sylvain letuffe)]

> Un petit peu surpris d'apprendre qu'une telle chose n'existe pas, je me
> suis dit que ça pouvait être dans mes cordes et je me suis mis aux
> opérations.

J'ignore qui le gère et comment il fonctionne, mais sur le channel IRC #osm-fr 
il y a un "robot" qui envoi un message indiquant que tel ou tel contributeur 
vient de commencer à cartographier telle ou telle zone en france.

Donc un tel outil semble déjà exister.
Ça vaut peut-être le coup de rapprocher au moins les deux développeurs de ses 
outils ;-)

-- 
sly (sylvain letuffe)
http://wiki.openstreetmap.org/wiki/User:Sletuffe

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

Re: [OSM-dev-fr] Outil d'analyse en ligne de super-relation ?

[sly (sylvain letuffe)]

Le samedi 02 novembre 2013 18:01:07, Jocelyn Jaubert a écrit :
> Je pense que tu parles de ce site, qui est en rade actuellement:
> 
> http://osm8.openstreetmap.fr/~osmbin/analyse-relation-open.py?11980
> 
> Tant que osm8 sera en panne, ça ne marchera malheureusement pas. :(

Pile poil, c'était bien ça !
un outil qui utilise la base osmbin j'imagine, y'a aucune urgence de mon coté, 
ça attendra tranquillement la remise en service.

Je le note sur le wiki pour s'en souvenir...

-- 
sly (sylvain letuffe)
pour me contacter / to contact me : sylvain(A)letuffe(.)org

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

[OSM-dev-fr] Outil d'analyse en ligne de super-relation ?

[sly (sylvain letuffe)]

Bonjour,

En reconstruisant la relation pour la France (avec dom/tom et autres îles 
lointaines) : http://www.openstreetmap.org/browse/relation/11980
avec l'outil de jocelyn (que je remercie) : http://polygons.openstreetmap.fr 

Je découvre avec plaisir qu'elle est bien entretenue (contrairement à ce que 
de mauvaises langues voudraient nous faire croire ;-p ) et qu'elle est 
exploitable directement.

Je suis toutefois tombé sur une erreur de self-intersection que j'aurais aimé 
corrigé directement dans les données plutôt qu'a posteriori mais ma méthode 
est bien trop archaïque pour trouver "où"

Je sais qu'il existe :
https://github.com/jocelynj/osm/blob/master/tools/mega-relation-analyser.py
mais je crois avoir lu quelque part, mais ne me souvient plus où, que cet 
outil (ou un autre ?) tournait en ligne quelque part, ce qui m'éviterais de 
sortir des pythonneries et l'utiliser en clic-clic direct.

ps: il ne s'agit pas de http://analyser.openstreetmap.fr qui est un excellent 
outil mais ne gère pas la cascade de relation


-- 
sly (sylvain letuffe)
pour me contacter / to contact me : sylvain(A)letuffe(.)org

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

Re: [OSM-dev-fr] Extraction de tous les éléments contenus à l'intérieur d'une relation avec l'overpassAPI

[sly (sylvain letuffe)]

Le jeudi 17 octobre 2013 01:19:31, sly (sylvain letuffe) a écrit :

> Donc, j'ai ça a porté de main, et ça marche :
> (ça récupère tous les noeuds qui sont dans la relation d'id 106558)
> 
> 
> 
> 
> 

J'ai vu que tu avais demandé "noeuds" ET "way", alors après, faut jouer avec 
les "recurse" car ma version ne donne que les noeuds

avec ça tu as tous les ways et relation qui ont au moins un noeuds ou un des 
ways ayant un noeud dans la surface demandée, mais sans que soit fourni non 
plus tous les autres noeuds ou autres membres qui composent ces ways et 
relations

  
  
  
  



J'ai trouvé cette variante :

  





qui, va te récupérer tout way ou relation avec tous ses membres et noeuds, 
dont un noeuds touche ta surface. (J'ai testé la précédente, et vu qu'un big 
type=road passait par là, je me retrouve avec des machins à des centaines de 
km de là)

-- 
sly (sylvain letuffe)
pour me contacter / to contact me : sylvain(A)letuffe(.)org

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

Re: [OSM-dev-fr] Extraction de tous les éléments contenus à l'intérieur d'une relation avec l'overpassAPI

[sly (sylvain letuffe)]

Le jeudi 17 octobre 2013 01:00:40, Nicolas Moyroud a écrit :
> Bonsoir,

ou même nuit,

> Avec l'overpassAPI je sais qu'il est possible de faire une extraction
> des nodes et ways contenus à l'intérieur d'une relation (au sens
> géographique pas les membres de la relation). Il me semble qu'il y a une
> histoire de clause area avec l'id de la relation auquel on doit ajouter
> 36, mais je n'arrive plus à trouver dans la doc de l'overpass
> comment faire. Quelqu'un pourrait-il me rafraîchir la mémoire ?
> Merci.

Quelle coïncidence, juste au moment ou je viens de terminer mon installation 
des requêtes area dans l'overpass ne couvrant que la france !

Donc, j'ai ça a porté de main, et ça marche :
(ça récupère tous les noeuds qui sont dans la relation d'id 106558)






Ce que je pige pas (et pourtant je me suis pas mal battu pour le trouver) 
c'est que la doc qui explique cette combine magique
"An area based on a relation has the id of the relation plus 3,600,000,000."

n'est pas documenté sur le wiki d'overpass ni sur http://overpass-api.de/
(p'tet qu'il faut que quelqu'un se lance et écrire ce bout de donc fort utile)


Mais avant, sur la vielle doc, elle était expliquée, alors disons profitons de 
la copie que j'ai faite ici :
http://oapi-fr.openstreetmap.fr/#section.area_query

+ ab_fab qui l'explique aussi sur le forum :

http://forum.openstreetmap.fr/viewtopic.php?f=3&t=806


ps: 2 bonnes réponses en 12h, avec réponse by night, je vais gagner une bière 
moi !

-- 
sly (sylvain letuffe)
pour me contacter / to contact me : sylvain(A)letuffe(.)org

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

Re: [OSM-dev-fr] Déterminer la BBOX d'un fichier OSM

[sly (sylvain letuffe)]

On mercredi 16 octobre 2013, Nicolas Moyroud wrote:
> Bonjour à tous,
> 
> Quelqu'un connaîtrait-il un outil simple pour déterminer la bbox d'un 
> fichier OSM ? 

Hello,

je n'ai pas essayé cette option, mais avec le couteau suisse d'osm, ça semble 
possible :
http://wiki.openstreetmap.org/wiki/Osmconvert#Retrieving_Statistical_Data

-- 
sly, DWG member since 11/2012
Coordinateur du groupe [ga]
http://wiki.openstreetmap.org/wiki/User:Sletuffe

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

Re: [OSM-dev-fr] Ne garder que les noeuds qui sont résultat de requête dans un xml OSM

[sly (sylvain letuffe)]

(tentative de déplacement vers dev-fr)

Le lundi 07 octobre 2013 19:13:50, vous avez écrit :

> La question principale portait en fait sur la manière la plus efficace de
> filtrer un document xml OSM pour ne garder que les objets résultat d'une
> requête overpass, sans les noeuds uniquement présents dans des ways (ou
> relations).
> Je suis obligé de rapatrier les noeuds support des ways résultat de la
> requête si je veux en faire quelque chose, je ne veux néanmoins pas qu'ils
> soient considéré comme des résultat de la requête eux-aussi.
> 
> J'espère être compris... ça me semble pas très intelligible :)

Je crois avoir compris, et je ferais 2 requêtes comme le propose christian 
avec recoupage géométrie/objets voulu par osm_id (une pour avoir les 
géométries, une pour les objets sans leur noeuds/membres)

Sinon, je sens que tu vas t'en voir pour coder ça, surtout si tu comptes être 
générique, car, comme je ne connais pas d'option à l'overpass qui renvoi le 
xml avec l'attribut "this_is_the_object_with_the_tags_you_really_want=yes"
ben tu vas être obligé de tous les passer en revu pour voir si tes critères 
initiaux sont bien respectés.
Alors bon, si tu n'as qu'une requête unique avec 3 if, ça ira, mais si tu dois 
être générique avec toute requête overpass, bonjour la galère

virer les noeuds/ways sans tags ne sera pas suffisant
virer tous les noeuds d'un ways avec les tags que tu veux peut te virer des 
noeuds qui avait aussi les tags que tu veux

ps: je pense qu'on est un peu hors sujet avec le thème de la liste talk-fr, et 
je suggère de passer sur dev-fr@openstreetmap.org car le sujet est bien 
technique
-- 
sly (sylvain letuffe)
pour me contacter / to contact me : sylvain(A)letuffe(.)org

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

Re: [OSM-dev-fr] Script overpass-api

[sly (sylvain letuffe)]

On vendredi 6 septembre 2013, V de Chateau-Thierry wrote:
> Possible que le service auquel tu penses soit celui-ci :
> http://www.osm974.re/osm2gis/

Je pensais en effet à ça, mais mon cerveau a dû mélanger des choses car je ne 
vois pas sur cet outil de possibilité de forcer un "where tourism=camp_site" 
ou option équivalente.

Donc en effet, tant par la possibilité limité d'extraction en "couverture" que 
par cette impossibilité de choisir des tags, cela ne fait pas de cet outil le 
bon candidat pour le besoin exprimé.

Sinon, si c'est du "one-shot" l'asso osm-fr dispose de 2 bases à jour avec du 
osm2pgsql, en offrant une bière à un des admin, y'a moyen de se faire servir le 
shapefile qui va bien ;-)

-- 
sly, DWG member since 11/2012
Coordinateur du groupe [ga]
http://wiki.openstreetmap.org/wiki/User:Sletuffe

___
dev-fr mailing list
dev-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev-fr

Re: [OSM-dev-fr] Script overpass-api

[sly (sylvain letuffe)]

On vendredi 6 septembre 2013, Rodolphe Quiédeville wrote:
> Bonjour à tous,

yo,

> J'ai besoin d'extraire des données pour une zone assez vaste (europe
> élargie) mais pour un nombre de tag faible, cela donne en résultant à
> peu prés 50k nodes. Pour le moment je chargeais ma base depuis l'export
> europe/pbf avec un style pour osm2pgsql trés réduit. C'est loin d'être
> optimum alors je me tourne vers l'overpass-api mais il paraît impossible
> de faire une requête sur une zone si vaste, j'ai toujours des retours
> d'erreurs.

Il y a un an environ, j'avais eu besoin de quasiment la même chose :
camping / hôtels / superettes d'europe

Résultats identiques, trop gros, passait pas.

Avec exactement la même réflexion que toi (trop dommage de charger 80Go de base 
de donnée pour au final ne garder que 80ko) j'ai codé un bidule en php pour 
découper en multiple requêtes (je sais plus pourquoi mais j'ai choisi XAPI) 
afin de récupérer tout ça et l'insérer dans une base locale.

Mais hélas, mon besoin différait un peu du tient en cela que mon découpage 
n'avait pas besoin de respecter un dallage régulier mais suivait un découpage 
en polygones arbitraires présents dans une autre base de donnée.

Et que le code s'occupait également de plonger ça dans une base de donnée 
MySQL locale (je n'utilisais pas osm2pgsql à l'époque)

En clair, j'ai peur que ça ne t'aide pas des masses car c'est une grosse usine 
à gaz par rapport à ton besoin qui semble simple, sauf si ton but est toi 
aussi d'insérer dans une base locale 

Mais je te laisse juge :

https://github.com/sletuffe/www.refuges.info/blob/dev/modeles/fonctions_osm.php#L157

> Alors j'ai découpé mes fetch par zone de quelques degrès et
> je réassemble après.
> 
> La question est donc existe-t'il un script qui permette de faire ce
> découpage directement et récupère l'ensemble des données, j'ai fait un
> vilain script shell mais avant de passer du temps à peaufiner je cherche
> à voir si je ne réinvente pas la roue.

Pas que je connaisse. 
En autre option, ça n'existerait pas un service d'extraits non pas 
géographiques, mais thématiques ?

Il me semblait que quelqu'un fournissait un service basé sur une base 
osm2pgsql dont on pouvait extraire, en shapefile, un extrait basé sur des 
requêtes

Y'a des chances que ça marche mieux vu que dernière c'est ce bon vieux 
postgresql, mais j'ai complètement oublié le nom de l'outil et son adresse


-- 
sly, DWG member since 11/2012
Coordinateur du groupe [ga]
http://wiki.openstreetmap.org/wiki/User:Sletuffe

___
dev-fr mailing list
dev-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev-fr

Re: [OSM-dev-fr] cadastre.openstreetmap.fr cassé - ça à l'air plus grâve que d'habitude

[sly (sylvain letuffe)]

On jeudi 18 juillet 2013, didier2020 wrote:
> bonjour,
> 
> j'ai envoyé un mail a Mr Qadastre car l'epaisseur des traits sur le site
> cadastre.gouv.fr a changé  (passé de 18 a 17.86 ...)
> ce qui empechait la generation des delimitations de commune

Merci à toi d'avoir repéré ce qui avant changé sur le cadastre !

Pour une correction aussi simple, je l'a fais directement moi, mis en ligne et 
sur le dépot d'export cadastre


-- 
sly, DWG member since 11/2012
Coordinateur du groupe [ga]
http://wiki.openstreetmap.org/wiki/User:Sletuffe

___
dev-fr mailing list
dev-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev-fr

Re: [OSM-dev-fr] cadastre.openstreetmap.fr cassé - ça à l'air plus grâve que d'habitude

[sly (sylvain letuffe)]

Le mercredi 10 juillet 2013 22:41:20, Pierre a écrit :

> Hello
> 
> Je n'ai plus trop le temps de suivre activement les MLs, quand c'est comme
> ça envoyez moi un mail en direct ou un jab (Vincent de Chateau-Thierry a
> bien fait de me contacter), je tenterai toujours de fixer asap…

Merci beaucoup. L'information pour te contacter à été noté dans le README du 
"frontend" (cadastre.openstreetmap.fr) à qadastre2osm

je le saurais pour la prochaine fois et pourrais alors te contacter 
directement.

ps: patch testé, appliqué, mis à jour et opérationnel sur  
cadastre.openstreetmap.fr
Des quelques tests que j'ai pû faire, ça semble marcher.

-- 
sly (sylvain letuffe)

___
dev-fr mailing list
dev-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev-fr

Re: [OSM-dev-fr] cadastre.openstreetmap.fr cassé - ça à l'air plus grâve que d'habitude

[sly (sylvain letuffe)]

A noter ce message (que je viens de lire un instant trop tard) :
http://lists.openstreetmap.org/pipermail/talk-fr/2013-July/060766.html

et dont je ne sais s'il peut y avoir un lien ou pas

-- 
sly (sylvain letuffe)

___
dev-fr mailing list
dev-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev-fr

[OSM-dev-fr] cadastre.openstreetmap.fr cassé - ça à l'air plus grâve que d'habitude

[sly (sylvain letuffe)]

Bonjour,

http://trac.openstreetmap.fr/ticket/403

Mes compétences en c++ / framework qt sont trop faible pour que je puisse 
débugger éfficacement ce problème.

Je jette donc une bouteille à la mer pour qui voudrait bien jeter un coup 
d'oeil.

Le code de l'outil cadastre+copie de Qadastre2OSM :
https://github.com/osm-fr/export-cadastre

l'upstream Qadastre2OSM :
http://gitorious.org/qadastre/qadastre2osm

-- 
sly (sylvain letuffe)

___
dev-fr mailing list
dev-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev-fr

Re: [OSM-dev-fr] Partage de DEM

[sly (sylvain letuffe)]

On mardi 2 juillet 2013, Jean-Claude Repetto wrote:
> Le 02/07/2013 14:29, Christian Quest a écrit :
> > En DEM, on peut récupérer celui du CRAIG (à 5m) et de PACA... de quoi
> > démarrer ;)
> 
> Pourras-tu l'uploader quelque part, comme tu l'as fait pour l'ortho 06 ?
> Ça m'intéresse beaucoup pour le calcul des dénivelés de mes randos !
> 
> Ce que je crains un peu, si on utilise Aster ou SRTM sur certaines 
> zones, et des données d'une autre provenance sur d'autres zones, c'est 
> d'avoir des décalages de niveau aux frontières. Qu'en pensez-vous ?

J'ai peur qu'il soit encore plus difficile de mixer des DEM dont les 
résolution sont différentes que de gérer les question de bordures


-- 
sly, DWG member since 11/2012
Coordinateur du groupe [ga]
http://wiki.openstreetmap.org/wiki/User:Sletuffe

___
dev-fr mailing list
dev-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev-fr

Re: [OSM-dev-fr] Paratage de DEM ( était Héberger le rendu HOT?)

[sly (sylvain letuffe)]

On mardi 2 juillet 2013, Christian Quest wrote:
> En DEM, on peut récupérer celui du CRAIG (à 5m) et de PACA... de quoi
> démarrer ;)

On devrait refaire le tour de la question demain soir sur IRC dans la 
discussion "DEM" mais pour info, j'ai téléchargé l'échantillon pointé par  
Jean-Claude concernant un bout de PACA, j'en ai extrait les courbes de 
niveaux, j'ai joué aux ombres chinoises, j'ai lissé, j'ai trituré, j'ai 
comparé à ASTER et y'a pas à tergiverser, c'est vraiment d'la bonne (Mais 
c'est aussi du lourd en taille !)

A noter que je ne connais pas le coin, ma comparaison souffre donc d'un manque 
de connaissance locale puisque je n'ai pu comparer que "sur plan"


-- 
sly, DWG member since 11/2012
Coordinateur du groupe [ga]
http://wiki.openstreetmap.org/wiki/User:Sletuffe

___
dev-fr mailing list
dev-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev-fr

Re: [OSM-dev-fr] Paratage de DEM ( était Héberger le rendu HOT?)

[sly (sylvain letuffe)]

On vendredi 28 juin 2013, Christian Quest wrote:
> Vous pensez que ça vaudrait le coup de récupérer des DEM locaux ?

Je dirais délicat de répondre :
En terme de résultat final que l'on peut attendre pour l'utilisateur, ça me 
semble évident que ça serait génial. Même si ça fait un patchwork de zones 
très bien représentées et d'autres plus grossières, je pense que ça serait un 
réél plus.

Mais je vois poindre un travail de titan qui consiste à uniformiser les 
formats, faire les demandes, fusionner tout çà en un tout utilisable, casse 
tête des licences, etc.
Je dirais dur d'estimer le travail nécessaire, même si ça pourrait sans doute 
faire des heureux bien au delà d'osm !

> On doit pouvoir récupérer celui de PACA et de l'Auvergne pour
> commencer... deux coins où il y a du relief.

Tu dis ça car tu sais qu'un tel jeu de donnée est déjà accessible ? y'aurait 
un échantillon dispo quelque part pour déjà tenter de juger de son intérêt 
qualitatif ?


-- 
sly, DWG member since 11/2012
Coordinateur du groupe [ga]
http://wiki.openstreetmap.org/wiki/User:Sletuffe

___
dev-fr mailing list
dev-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev-fr

Re: [OSM-dev-fr] Paratage de DEM ( était Héberger le rendu HOT?)

[sly (sylvain letuffe)]

Je transferts sur dev-fr histoire d'avoir plus d'avis

On jeudi 27 juin 2013, Yohan Boniface wrote:

> Côté calque hillshade, mon idée générale pour l'instant c'est d'utiliser 
> un .vrt qui référence les tif moulinés, apparemment c'est ce qui se fait.

Je ne travail pas sur le monde mais juste sur l'europe (780°²) et j'ai opté 
pour un seul et unique fichier tif (9Go)

N'ayant pas trop fait d'essais avec la solution d'un vrt et d'une grosse 
arborescence, je ne saurais dire si c'est mieux ou moins bien. Si ce n'est 
sans doute que ma technique ajoute une monstre opération à base de 
gdal_merge.py pour produire un fichier titan.

> En théorie, je devrais aussi il me semble pouvoir faire un 
> .vrt, mais pour l'instant j'échoue avec succès ;)

J'ai opté pour la technique qui consiste à mettre les isohypses dans la base 
postgresql :
http://wiki.openstreetmap.org/wiki/Contours

Encore une fois, je ne saurais dire si c'est mieux ou moins bien qu'un 
stockage+accès en shp 


Message complet :
On jeudi 27 juin 2013, Yohan Boniface wrote:
> En parlant de DEM, je suis en train de réfléchir à comment scaler le DEM 
> pour le rendu HOT, et j'ai encore pas mal d'interrogations sur la 
> meilleure stratégie.
> 
> Voici en gros l'état de ma réflexion, si y a des avis, je suis preneur.
> 
> D'abord un petit peu de contexte: je bosse sur un projet TileMill [1], 
> donc en Carto.
> Côté visualisations DEM, je me suis arrêté sur deux calques:
> - un calque hillshade avec une source à 80° d'altitude
> - un calque lignes de contour à 25m
> 
> Pour l'instant, j'ai tout fait à partir d'une dalle CGIAR à 90m de 5x5 
> disponible sur leur site [2]. Donc c'est facile, j'ai un seul petit 
> fichier à gérer par calque, et chaque traitement prend 10 secondes.
> 
> Mais bien sûr dans l'idée de passer ce rendu en worldwide, ça va pas 
> être aussi simple.
> 
> Côté calque hillshade, mon idée générale pour l'instant c'est d'utiliser 
> un .vrt qui référence les tif moulinés, apparemment c'est ce qui se fait.
> Par contre, je sais pas quelle est le ratio optimal nombre de 
> tifs/taille de ces tifs. Y a 820 dalles 90m sur le serveur du CGIAR. 820 
> fichiers me semble *à vue de nez* pas super optimal.
> D'un autre côté, MapBox semble dire qu'ils ont constaté que des dalles 
> entre 4096x4096 et 16384x16384 donnaient les meilleurs résultats [3], et 
> les dalles de CGIAR font 6000 x 6000. Donc une option est de les merger 
> par groupe de 4 ou 6.
> 
> Côté lignes de contour, j'étais parti pour merger les shp dans un gros 
> shp, mais pour l'instant ogr2ogr ne veut pas de mes shp lignes de 
> contour. En théorie, je devrais aussi il me semble pouvoir faire un 
> .vrt, mais pour l'instant j'échoue avec succès ;)
> 
> Voilà l'état de mes réflexions. J'en suis à me dire que je vais 
> commencer par service le style sans les DEM, ou avec les DEMs seulement 
> dans les endroits stratégiques pour HOT, en ajoutant au fur et à mesure 
> ce qu'on me demande. Pour monter petit à petit en charge, et bien 
> prendre le temps de voir les intérêts des différentes options.
> 
> Si vous avez des tuyaux, des expériences, des retours, je suis preneur. :)
> 
> Je vais sûrement pinguer les anglois sur serving-tiles@ quand j'aurai 
> les idées un peu plus claires.
> 
> En attendant je continue à lire la littérature des Internets sur le sujet!
> 
> Yohan
> 
> [1] https://github.com/hotosm/HDM-CartoCSS
> [2] http://srtm.csi.cgiar.org/SELECTION/inputCoord.asp
> [3] 



-- 
sly, DWG member since 11/2012
Coordinateur du groupe [ga]
http://wiki.openstreetmap.org/wiki/User:Sletuffe

___
dev-fr mailing list
dev-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev-fr

Re: [OSM-dev-fr] mod_tile/renderd qui plante ?

[sly (sylvain letuffe)]

Le jeudi 13 juin 2013 19:10:34, Christian Quest a écrit :
> On a eu un problème, pas totalement résolu, mais qui n'avait pas du
> tout ces symptômes.
> 
> renderd plantait car on tentait de lancer trop de rendus en parallèle.
> Ce n'était pas un problème de RAM bouffée.

Ok, merci pour l'info.

En même temps, ça m'a amené à aller voir tourner le renderd de osm13 histoire 
de voir combien de RAM il consomme :
Le fourbe :
  PID USER  PR  NI  VIRT  RES  SHR S %CPU %MEMTIME+  COMMAND

  
10265 www-data  20   0 10.7g 8.2g  91m S0 13.1 168:12.06 renderd

~8Go de non partagé* !

ça va que la bécanne dispose de 64Go mais lui faire bouffer du slim fast ne 
serait pas un mal

La même sur osm108 :
  PID USER  PR  NI  VIRT  RES  SHR S %CPU %MEMTIME+  COMMAND

  
32287 osm2pgsq  20   0 2907m 400m 9284 S 0  1.2   1:53.29 renderd   

  
400Mo de non partagé*, c'est pas la même.

* Enfin, c'est comme ça que j'interpète les valeurs de top

ça me donne du grain à moudre pour me rendre compte que c'est peut être 
"normal"

Ce qui condamne à brève échéance ma capacité à utiliser un renderd récent sur 
ma bécane, et va peut-être m'inciter à quémander des ressources à 
l'association ;-)


-- 
sly (sylvain letuffe)

___
dev-fr mailing list
dev-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev-fr

Re: [OSM-dev-fr] mod_tile/renderd qui plante ?

[sly (sylvain letuffe)]

On jeudi 13 juin 2013, Pieren wrote:
> 2013/6/13 sly (sylvain letuffe) :
> 
> > Je crois me souvenir que quelqu'un avait expérimenté des crash à 
répétition de
> > renderd ?
> 
> Peut-être que tu fais référence à ce fil de discussion:
> 
http://gis.19327.n5.nabble.com/mod-tile-causes-segfault-on-debian-7-0-td5762187.html

J'ai vu ça passé en effet ce sujet, mais ça ne correspond pas trop à mes 
symptômes.
Je n'ai aucun segfault de mod_tile, ni de renderd, c'est juste que renderd me 
mange les 8Go dont je dispose, tout swap et sature, donc ça fini par un kill 
de renderd.

Alors soit j'ai vraiment juste pas assez de RAM pour une nouvelle 
fonctionnalité top moumoutte qui aurait besoin de 8Go, soit j'ai déclenché un 
bug pas forcément facile à reproduire.

Il me semble que c'était suite à la mise en place du rendu osm-fr par 
chistian, ou jocelyn peut être ?
Peut-être par pas email sur une des listes, mais sur IRC ?



> Problème corrigé dans mod_tile le 22 mai:
> https://github.com/openstreetmap/mod_tile/commits/master
> 
> Ton code source est bien ultérieur à cette date ?

C'est le contenu de git datant d'avant hier, donc toute dernière bleeding edge 
version.

Je pense procéder par dicotomie pour voir quelque version entre celle de 
février et celle de maintenant créé le bug, mais ça risque d'être bien galère 
vu qu'il faut attendre plusieurs heures dans mon cas pour constater le bug 
(ou faut que je tente de simuler des demande de génération de tuiles en masse 
pour produire le cas)



-- 
sly, DWG member since 11/2012
Coordinateur du groupe [ga]
http://wiki.openstreetmap.org/wiki/User:Sletuffe

___
dev-fr mailing list
dev-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev-fr

[OSM-dev-fr] mod_tile/renderd qui plante ?

[sly (sylvain letuffe)]

Pour les experts en mod_tile et renderd qui se sont battu sur les mutiples 
rendu au sein de l'asso osm-fr :

Je crois me souvenir que quelqu'un avait expérimenté des crash à répétition de 
renderd ?

Si je demande ça, c'est que je viens de mettre à jour le serveur de mon rendu 
rando en debian wheezy (+conversion mapnik 2, dernier mod_tile/renderd, +tout 
le reste)

Et patatra, il part en live au bout de 2 heures de fonctionnement, consomme 
alors toute la RAM qu'il peut trouver pour finir par un oom kill kernel
j'ai laissé le render_config.h par défaut, et j'ai juste un seul rendu de 
configuré, rien d'extraordinaire de ce coté là.

Je suis revenu sur une version datant du 2 février 2012, fichier xml 
identique, et tout roule depuis 48h sans problèmes.

Je voudrais faire un rapport de bug, mais pour l'instant il est un peu léger :
"renderd plante au bout de 2h" et j'aimerais savoir comment vous avez réglé ça 
de votre coté (et si mes souvenirs que quelqu'un de cette liste en avait 
parlé sont bons) ?


-- 
sly
qui suis-je : http://sly.letuffe.org
-- 
sly, DWG member since 11/2012
Coordinateur du groupe [ga]
http://wiki.openstreetmap.org/wiki/User:Sletuffe

___
dev-fr mailing list
dev-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev-fr

[OSM-dev-fr] [info] liste pour ceux qui jouent avec des serveurs de tuiles

[sly (sylvain letuffe)]

Des fois que ça permette de regrouper nos combines, j'ai vu que cette liste 
venait d'être créée :
http://lists.openstreetmap.org/listinfo/tile-serving

ps: ça fait peut-être un peu doublons avec dev, mais en même temps c'est un 
peu plus spécifique

-- 
sly (sylvain letuffe)

___
dev-fr mailing list
dev-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev-fr

Re: [OSM-dev-fr] osm2psql, problème de fichier.

[sly (sylvain letuffe)]

On jeudi 21 mars 2013, Vincent Pottier wrote:

> $ ./france.osm2sql.sh
(...)
> Reading in file: /home/vincent/tmp/france-latest.osm.pbf
> Unable to open /home/vincent/tmp/france-latest.osm.pbf
> Error occurred, cleaning up
> 
> Ça roule pour corse-latest.osm.pbf, comme pour bz2.
> Je teste avec france-130319.osm.pbf pour voir s'il n'y a pas un problème 
> de saut de version de fichier durant le téléchargement. (pourtant le md5 
> était bon)

Je tenterais quand même, même si tu as déjà dû vérifier 10 fois de creuser le 
message ci-avant :
Unable to open /home/vincent/tmp/france-latest.osm.pbf
qui m'a l'air relativement explicite.

Dans la foulée de ton ./france.osm2sql.sh (sans changer de dossier, ni 
d'utilisateur, ni de quoi que ce soit tenter un  :
$ ls -l /home/vincent/tmp/france-latest.osm.pbf
$ file /home/vincent/tmp/france-latest.osm.pbf

Vérifier des choses simples :
- Le fichier est il bien là ?
- sous ce nom là ? (un - un espace, un point ?)
- ton script change-t-il d'utilisateur et si oui, celui-ci a il accès au 
fichier (pas juste "oui c'est bon y'a 777" mais passer dans cet utilisateur 
et tenter une lecture partielle de ce fichier genre 
cat /home/vincent/tmp/france-latest.osm.pbf > /dev/null  (puis ctrl+c) )


-- 
sly, DWG member since 11/2012
Coordinateur du groupe [ga]
http://wiki.openstreetmap.org/wiki/User:Sletuffe

___
dev-fr mailing list
dev-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev-fr

Re: [OSM-dev-fr] [OSM-talk-fr] osm2psql, problème de fichier.

[sly (sylvain letuffe)]

On mercredi 20 mars 2013, Vincent Pottier wrote:
> Merci pour vos conseils.

Je suggère de passer sur la liste dev-fr (en copie de ce mail)

peux-tu renvoyer :
$ osm2pgsql -h

et le full log de ta tentative d'import
Peux tu tenter avec un fichier .osm.bz2 tout petit (genre corse.osm.bz2) ?


-- 
sly, DWG member since 11/2012
Coordinateur du groupe [ga]
http://wiki.openstreetmap.org/wiki/User:Sletuffe

___
dev-fr mailing list
dev-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev-fr

Re: [OSM-dev-fr] Problème de création de diff avec Osmosis

[sly (sylvain letuffe)]

Le samedi 09 mars 2013 21:55:32, Samir NOIR a écrit :


> Utiliser un seul schéma qui supporte toutes les opérations nécessaires ne
> simplifierait il pas les choses ? Pour chaque outil utilisé par
> OpenStreetmap (le serveur de tiles, l'outil de géocodage, l'API, ...) il
> faut une base de donnée différentes, ce qui est plus compliquer à gérer et
> cela prend plus de place.
> 
> Cela est lié à une problématique technique ou pour une toute autre raison ?

À mon avis, c'est avant tout parce que personne ne l'a fait.

Ceux qui avaient besoin d'un rendu, ont d'abord répondu à leur besoin, ceux 
qui voulaient une API, le leur, etc.

En choisissant des schémas simples, il est plus facile et rapide d'arriver à 
un résultat (un programme fonctionnel) que si on devait penser toutes les 
utilisations à l'avance.

En outre, le "schéma à tout faire" ne pourrait le faire qu'au prix d'une 
certaine redondance quand même (voir mail de yves) et sans doute, d'une 
complexité accrue et donc plus difficile à utiliser.

-- 
sly (sylvain letuffe)

___
dev-fr mailing list
dev-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev-fr

Re: [OSM-dev-fr] [layers]nouveaux overlays pour les religions

[sly (sylvain letuffe)]

On lundi 21 janvier 2013, Francescu GAROBY wrote:
> Bonjour,

Salut,

> J'ai ouvert ce matin un ticket ,

vu ;-)

> Mais, étant moi-même développeur, je me demandais s'il ne serait pas
> possible que je m'y attelle moi-même. Savez-vous où se situe le code
> sélectionnant les relations à traiter et générant les cartes ?

ha ben ça alors, j'ai rédigé ma réponse sur le ticket sans voir la tienne, que 
je recopie ici :
ça pouvait pas tomber mieux ;-)

*
Je n'ai plus trop la motivation pour m'en occuper (je suis sur autre chose) et 
je ne suis même plus convaincu qu'il s'agit de la bonne manière de faire 
(d'avoir un rendu par chose que l'on veut représenter)

Mais si quelqu'un veut mettre la main à la pâte, j'ai tout publié sur github :
https://github.com/osm-fr/layers-mapnik-styles
*

-- 
sly, DWG member since 11/2012
Coordinateur du groupe [ga]
http://wiki.openstreetmap.org/wiki/User:Sletuffe

___
dev-fr mailing list
dev-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev-fr

Re: [OSM-dev-fr] [OSM-talk-fr] problème overpass-api et area-query sur une relation

[sly (sylvain letuffe)]

Le vendredi 04 janvier 2013 15:26:56, Cyrille Giquello a écrit :
> > Pour changer ça, il faudrait un peu de lobbying auprès du concepteur de
> > l'Overpass-API.
> 
> En fait la sélection des éléments pouvant servir de polygone "area"
> n'est pas dans le code source mais juste dans une requête exécutée
> régulièrement en tâche de fond 

Tout à fait exact. le code est prêt y'a plus qu'a me lobbyer.
Je l'eu volontier fais depuis longtemps si cela n'entraînait pas une 
dégradation sensible de toutes les autres requêtes.
Et comme l'un des but de cette overpass est de servir un outil permettant 
d'éditer les données OSM avec JOSM de manière plus rapide qu'avec l'api 
officielle (et aussi pour la libérer) je rechigne un peu à le faire sur 
api.openstreetmap.fr

P'tetre sur oapi-fr.openstreetmap.fr (France only)...

> Du coup, le lobbying, c'est auprès de Sly et de l'asso OSM-Fr qu'il
> faut le faire ;-)
> - Pour que Sly installe cette requête en tâche de fond.
> - Pour que l'Overpass-API soit sur une machine hyper-puissance
> ;-)
> 

C'est ça ;-) Et qui veut m'épauler est le bienvenu. Ce service est loin d'être 
super méga stable, j'ai des dizaine de tests dans la tête, mais n'ai pas le 
temps de les concrétiser, tout juste à peine de temps de les noter ! :
http://trac.openstreetmap.fr/query?status=!closed&component=api-fr
-- 
sly (sylvain letuffe)

___
dev-fr mailing list
dev-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev-fr

Re: [OSM-dev-fr] [OSM-talk-fr] problème overpass-api et area-query sur une relation

[sly (sylvain letuffe)]

(Je bascule sur dev-fr, talk-fr est déjà très largement sur-chargée, et ce fil 
de discussion me semble assez technique)

Le vendredi 04 janvier 2013 15:41:59, Cyrille Giquello a écrit :
> Le 4 janvier 2013 15:33, Christian Quest  a écrit :
> > Je ne sais pas si c'est cette requête pour maintenir les area à jour
> > qui est lourde où si ce sont celles les utilisant ensuite sur
> > l'overpass...
> 
> C'est surtout leur génération qui est lourde, me semble-t-il.

C'est en effet leur génération qui est lourde, je n'ai pas encore regardé en 
détail comment ça fonctionne, mais ça fout un CPU à 100% en permanence et ça 
bouffe du disque.

Alors que personne ne savait que j'avais glissé en test les calculs des areas 
sur oapi-fr.openstreetmap.fr la machine perdait terriblement en rapidité pour 
les autres requêtes.
Roland ma conseillé de lui attribué une priorité plus faible (nice) mais ça ne 
résout que le problème CPU, pas le problème i/o
Je vais faire des tests avec ionice, mais le coeur du problème restant bien 
évidement que ça ne devrait pas bouffer à ce point.


> > C'est vrai aussi qu'à un moment passer à postgis offre un autre champ
> > de possibilités, il faudrait ajouter un moyen de requêter postgis via
> > HTTP pour une exploitation dans les slippymaps.

Tiens, ça me rappel un conseil que j'ai donné récemment sur [tech] ;-)

> Ça risque d'être encore plus chaud : très facile de saturer le serveur
> puisque l'on pourrait tout lui demander tout le temps.

Oui mais ça ressemble au même problème avec l'overpass. Si on veut le faire, à 
nous de trouver une méthode permettant de terminer les requêtes trop longues 
et d'avoir une règle d'utilisation et des restrictions. 

 
> L'overpass-API c'est super bien:
> - un type de requêtes largement suffisant
oui

> - une construction des données optimisées pour le type de requête
Oui, sauf les areas ;-)

> - un service qui tient la route
Oui bon ça, ça se discute ;-) mais les choses s'améliorent

 
> L'option de limite des requête sur un polygone est vraiment super,
> même si limitée à un type de données. Et en plus ce filtrage est
> négociable ;-)

Ou alors, mais ça devient délicat, se goupiller un couplage 
postGIS(osm2pgsql)/overpass(ou osmbin) pour obtenir le meilleur des deux 
mondes.

Mais c'est de loin plus facile à dire qu'a faire.


-- 
sly (sylvain letuffe)

___
dev-fr mailing list
dev-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev-fr

Re: [OSM-dev-fr] Styles Mapnik gérés par CartoCSS - question existentielle

[sly (sylvain letuffe)]

On vendredi 21 décembre 2012, Christian Quest wrote:
> CartoCSS génère des XML, tu pourra repartir de ceux-ci, non ?
> Ils ne seront sûrement pas aussi clean qu'écrits directement, mais ce
> n'est pas une impasse.

Un 1/2 point pour toi. J'imagine que oui, on peut toujours repartir de ça, 
mais j'attends de faire quelque tests de "compilation", je suppose que tout 
va être déplier, et dé-normalisé, donc pour repartir de ça ! c'est comme 
reprendre un fichier html généré par dreamweaver ;-)




-- 
sly, DWG member since 11/2012
Coordinateur du groupe [ga]
http://wiki.openstreetmap.org/wiki/User:Sletuffe

___
dev-fr mailing list
dev-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev-fr

Re: [OSM-dev-fr] Styles Mapnik gérés par CartoCSS - question existentielle

[sly (sylvain letuffe)]

On vendredi 21 décembre 2012, Pieren wrote:
> qui a totalement disqualifié cet outil pour Andy Allan (celui qui a créé le
> style cyclemap et lancé la convertion du style osm vers cartoCSS).

Certes, disqualifié également donc. 
Sauf que si je ne m'abuse :
https://github.com/mapnik/Cascadenik/blob/master/AUTHORS.txt
http://wiki.openstreetmap.org/wiki/Cascadenik
On retrouve dans les auteurs des gens connus de cartoCSS maintenant (de chez 
mapbox par exemple)
qui ont choisi, que plutôt de reprendre cascadenik, de "forker" en quelque 
sorte et refaire autre chose. Ma crainte est donc :
même gens + même fonctionnalités + même société => même fin tragique

Mon avis sera très différent si le support de cartoCSS était intégré à mapnik, 
là, ça aurait une autre crédibilité pour la pérénité.

> Tu parles de carto ?
> https://npmjs.org/package/carto
> http://wiki.openstreetmap.org/wiki/Carto
yes
 
> Il y a quand même des avantages comme l'utilisation de variables (une
> seule définition de la couleur de l'eau par exemple).

C'est pas tant les avantages d'une approche CSS qui m'inquiètes (d'ailleurs 
c'est bien pour ça que j'hésite car c'est super génial)
Les variables sont possibles en xml également par le système d'entité, mais la 
force en +, c'est le cascading de style : un highway=secondary de zoom 14 
hérite des propriétés du highway, du secondary, et du zoom 14 et ça factorise 
donc énormément.


> Mouais. Je crois avoir lu la même chose à chaque fois qu'un nouveau
> format est sorti (xml, json, etc). Difficile de dire à l'avance si ça
> marchera ou pas.

Je ne me souviens pas avoir entendu grommeler à propos de html puis xml, 
avant, c'était soit des formats protégés, binaires et mal supportés ou des 
formats largement trop basiques comme csv

xml s'est rapidement imposé un peu partout car il comblait un manque terrible 
et son approche généraliste permet une grande ré-utilisation et dispose d'un 
important support applicatif de ce fait.
json, ça apporte quoi par rapport à ça ? A part des allergiques aux balises 
qui préfère les { } ?
(note que j'aurais dis exactement la même chose de xml s'il était venu après 
json)
Je la cite souvent en ce moment : http://xkcd.com/927/ mais c'est pas prêt 
d'être obsolète


> Il y a aussi, c'est sûr, des effets de mode. Mais un critère important
> selon moi est que le style principal d'osm.org basculera tôt ou tard
> vers cartoCSS, que celui-ci a une équipe derrière, celle de mapbox,
> qui est aussi celle qui continue de supporter mapnik. Donc cartoCSS,
> tilemill, mapnik, c'est une chaîne qui se tient ensemble (et qui est
> open-source) et qui va continuer de s'améliorer dans les prochains
> temps.

Puisses-tu dire vrai, 2 avis contre mon doute, je me jette dans la fosse aux 
lions...


-- 
sly, DWG member since 11/2012
Coordinateur du groupe [ga]
http://wiki.openstreetmap.org/wiki/User:Sletuffe

___
dev-fr mailing list
dev-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev-fr

[OSM-dev-fr] Styles Mapnik gérés par CartoCSS - question existentielle

[sly (sylvain letuffe)]

Bonjour,

Résumé rapide : Je suis en train de mettre en oeuvre sur les serveurs de 
l'association osm-france un nouveau style de rendu sur la terre dont la cible 
est le contributeur openstreetmap pour qu'il puisse voir : 
- tout ou presque ce qu'il y a dans la base (tout objet dont les tags sont 
acceptés sur le wiki)
- rapidement ses propre modifs
- créé collaborativement si quelqu'un veut m'aider

Son petit nom :
2u : acronyme de "Ugly and Usefull"
(J'aurais aimé l'appelé 4u, mais je n'ai pas trouvé les 2 u qui me manque)

Voilà pour le background, maintenant je me pose la question de la technologie 
à utiliser.
Le moteur de rendu sera mapnik, et la base : osm2pgsql. Plutôt que de partir 
de rien, je préfère reprendre le style existant sur osm.org (ou un autre, 
tant qu'il est déjà bien avancé)

Je me suis donc naturellement tourné vers : 
https://github.com/gravitystorm/openstreetmap-carto

Une reprise des styles actuels de osm.org qui sont au format xml vers le 
format CartoCSS
La pub est alléchante :
- quasi identique à l'actuel sur osm.org
- joli format plus facile à écrire proche du CSS
- moins de redondance dans le style
- une interface graphique clic-clic pour faire ses modifs
- un générateur simple pour passer de cartoCSS à xml (dont mapnik a toujours 
besoin)

Que demande le peuple ? un enfant s'en servirait dirait presque la pub, idéal 
donc pour se partager le travail sans être informaticien et que de temps 
gagné !
J'ai donc sauté dans la fosse (aux lions) de cette alléchante perspective, 
mais voilà que la réalité semble rattraper quelque peu la fiction, et mes 4 
heures à étudier la question et tester la solution dans tous les sens m'ont 
amené à douté de mon choix.

J'en appel donc à ceux qui l'utilise, ceux qui utilisent autre chose, ceux qui 
sont restés au bon vieux format xml d'avant, vous en pensez quoi ?

J'ai aussi sans doute du rater plein de trucs, et si vous avez un conseil, je 
suis preneur, voilà mon pessimiste résumé  :

_gain de temps_
* Je connais déjà pas mal le format xml et ça m'obligerais à apprendre un 
nouveau format
* Le style osm.org "à l'ancienne" en fichier xml a tout de même bien évolué en 
4 ans, et les fichiers sont maintenant séparés par thème, la redondance est 
pas mal évitée par les xml entities et quelques tests m'ont montrés que 
c'était tout à fait possible de continuer à travailler directement sur eux

_fiabilité_
* Le style xml est ancien, éprouvé, et bien testé

_pérennité_
* Ça, la pub ne le dit pas, mais cartoCSS ne permet pas toute la richesse du 
format xml (il ne manque pas grand chose toutefois)
* lorsque mapnik évolue, il faut que cartoCSS suive, sinon, on ne peut pas 
profiter des nouvelles fonctionnalités
* Si cartoCSS est abandonné, je suis bloqué

_facilité d'utilisation_
* Finalement, un enfant ne s'en servirait peut-être pas, le truc qui passe de 
cartoCSS à xml est un obscure (pour moi) bidule en Node.js dont je n'ai pas 
réussi à trouver de paquet debian et bourré de dépendances
(ma philosophie à 2 francs CFA : quand pas de paquet debian maintenu, méfiance 
accrue)
* Le truc clic-clic qu'il est trop beau est bien gentil, mais il faut quand 
même monter une base postgresql+osm2pgsql donc pour le "accès à tout le 
monde" c'est pas non plus la panacée
* Le TileMill (le truc clic-clic) ne tourne que sur Ubuntu, et pas sur toutes 
les versions, et avec un installateur louche qui va chercher des trucs et des 
bidules un peu partout qui ne sont pas des les repos de la distrib, ce qui 
amène à ne plus pouvoir, ou plus difficilement, traiter le style sur le 
serveur directement

Bref de chez bref, ça fait, il me semble, un sacré potentiel à emmerde, pour 
finalement gagner quoi ? un peu de confort à écrire des styles.

Le format du fichier .mml est symptomatique d'un mode de pensé, selon moi 
tordu, des développeurs hypes et modernes qui adorent toucher toutes les 
technos du moment et délaisseront le projet dans 3 ans par manque d'intérêt.

C'est au format JSON, le but est de rendre plus lisible le même fichier en xml 
de mapnik, j'ai lu les deux [1] et [2], et je ne vois pas en quoi le json 
(technologie que j'exècre par sa volonté de supplanter xml sans rien apporter 
de probant) apporte quelque chose de vraiment incroyable, par contre, ce que 
je vois bien, c'est que ça fait un nouveau format incompatible et une 
nouvelle sur-couche qu'il faudra ré-écrire en xml si on change d'avis.

A votre avis ? Je suis tenté aussi par MapCSS et Caskadenik qui me semblent se 
situer à mi-chemin.

[1]
"Layer": [
{
  "geometry": "polygon",
  "extent": [
-179.9692067183,
-85.051,
179.9692067183,
83.6693329998
  ],
  "id": "world",
  "class": "",
  "Datasource": {
"file": 
"/usr/local/share/mapnik/shape-resources/world_boundaries/shoreline_300.shp"
  },
  "srs-name": "900913",
  "srs": "+proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0 +x_0=0.0 
+y_0=0.0 +k=1.0 +

Re: [OSM-dev-fr] [OSM-talk-fr] Tr : [OSM-talk] New OpenStreetMap tile server

[sly (sylvain letuffe)]

On mercredi 19 décembre 2012, Jocelyn Jaubert wrote:

> Du coup, il y a des chances qu'un rendu par pays soit très facile à mettre
> en place sur une machine "de base". Ça pourrait être le genre de truc à
> tester sur les blades de cquest, avec genre un pays par blade :)

En tout cas, un pays comme le vatican, même mon smartphone pourrait ;-)
Donc, ça dépend, mais si quelqu'un me donne un jouet, je veux bien tester.
(Après avoir joué avec la machine free sur world wide)

> On pourrait s'amuser à faire un http://x.y.z.duchmol/, mais là, c'est le DNS
> qui va prendre cher...

Pas con, mais là, c'est au niveau DNS que tu es obligé d'ajouter ton code de 
décision de zone ! 
Arf, ça sent pas le truc propre, mais je suis sûr que ça existe en python ;-)
Sinon, les DNS cache sur la route, ben, je sais pas comment ils vont ré-agir
 mais quelque chose me dit qu'ils ne vont pas apprécier le domaine duchmol...

> Il reste le souci soulevé par Philippe V., que ca ne permet pas de réduire
> la bande passante

Laquelle ? la sienne ?

Bien sûr que si ça aide au problème de BP, mais il faut se rappeler que tout 
est relatif, la BP de qui ? et où ?
Si le but est de réduire celle de l'impérial collège, alors hop, c'est tout 
bon.
Si on parle de la BP du monde au total, ben là, de toute façon, on y peut 
rien.
Si on parle de celle du "dispatcher" dont je parle, y'a qu'a en mettre 10 
ou...

> La solution d'un proxy n'est pas vraiment envisageable, à moins qu'il ne
> fasse des 301 HTTP Redirect 

Voilà ;-)

> sur les bons serveurs. (je ne sais pas si c'est possible)

si si, seul défaut, par rapport à ton option "DNS level" c'est qu'on se tape 
un aller retour pour rien vers le dispatcher, mais m'est avis que 50ms c'est 
pas ça qui posera tant de problème.


-- 
sly, DWG member since 11/2012
Coordinateur du groupe [ga]
http://wiki.openstreetmap.org/wiki/User:Sletuffe

___
dev-fr mailing list
dev-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev-fr

Re: [OSM-dev-fr] [OSM-talk-fr] Tr : [OSM-talk] New OpenStreetMap tile server

[sly (sylvain letuffe)]

On mercredi 19 décembre 2012, Jocelyn Jaubert wrote:
> Je me demandais: est-ce que avoir un serveur de rendu dédié à une région
> spéciale (genre la France) serait une solution envisageable ?

Jocelyn, tu penses à tout ;-)

Je pense que ça peut se creuser, y'a de l'idée et j'ai même commencé à mettre 
sur papier quelques idées, mais j'ai peur que ça soit un peu délicat et pas 
super robuste (en tout cas avec mes bidouilles à deux balles que j'ai en 
tête), il faut que je chercher voir si squid, ou apache peut nous faire ça en 
mode proxy.

De prim abord, je pense que la puissance nécessaire à faire un rendu sur la 
terre, bien que pas vraiment possible avec mon smartphone, n'est pas non plus 
impossible. Je prouverais (dès que cquest c'est occupé de ma VM au lieu de 
jouer avec des kernels :-p ) , que c'est possible avec les serveurs que la 
fondation free a eu le bon goût de nous fournir.
(j'ai peur de découvrir toutefois qu'un SSD aurait vraiment été bien, auquel 
cas je ferais mon malin à dire "J'l'avais dis" :-p)

Et cette croyance actuelle que j'ai m'incite à ne pas m'éparpiller à coller 
des bouts des ficelles entre eux mais partir sur une "vrai" solution, avec 
une babasse qui dépotte

> En gros, l'idée serait d'avoir un serveur de rendu par région, qui ne
> contiendrait qu'un petit terrain, et sur les zoom élevés. Ça devrait
> permettre 
> de diminuer grandement la taille de la machine nécessaire, en la mettant là
> où 
> c'est le plus nécessaire. Avec les diffs locaux, ça pourrait être possible.

Oui, je le crois tout à fait réaliste en terme de puissance, moins en terme de 
réalisation.
Pour info, je continue à faire un rendu europe à jour real time avec des vieux 
style mal optimisés sur un 4-coeur + 8GO de RAM sans SSD, donc oui, j'y crois 
et ce, en grande partie grâce à ce que tu as développé pour les europe diffs)

En quoi j'ai peur de la réalisation ? 
le protocole utilisé est TMS, on l'appel comme ça :
http://duchmol/zoom/x/y.png

Et, hélas pas, ainsi : http://zone-[bbox max].duchmol/zoom/x/y.png
Ou il aurait été bien plus facile de préparer un cluster géographique réparti 
ou chaque serveur annonce quelle bbox il peut couvrir et le client openlayers 
supportant ce faux TMS se charge d'interroger le bon serveur de la bonne zone

En clair avec le vrai TMS, on tombe sur un seul serveur, et lui ne sait pas 
encore s'il peut ou non servir la requête, l'idée que j'ai est donc un proxy 
(non cache) intelligent que je préfère nommer "le dispatcher"

Son rôle et de transmettre la demande au bon serveur qui gère la bonne zone, 
il doit :
- maintenir une liste des serveurs ordonnés de zone et la zone qu'ils couvrent
- faire le calcul, à partir d'une URL TMS afin de déterminer dans quelle zone 
elle se trouve
- Proxier/ou rediriger par un HTTP 301 la demande de l'internaute vers le 
serveur le plus adapté

Bigre, rien qu'a l'écrire, je me dis que ça n'est pas si compliqué que ça et 
que ça pourrait largement trop bien le faire.
(cadeaux bonux, mise en cache des zoom 0 à 9 les plus souvent demandés)


-- 
sly, DWG member since 11/2012
Coordinateur du groupe [ga]
http://wiki.openstreetmap.org/wiki/User:Sletuffe

___
dev-fr mailing list
dev-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev-fr

Re: [OSM-dev-fr] [OSM-talk-fr] Tr : [OSM-talk] New OpenStreetMap tile server

[sly (sylvain letuffe)]

On mercredi 19 décembre 2012, Christian Quest wrote:
> Pour les impatients, il y a une autre approche pour "voir" ses modifs:
> l'onglet export.

Voilà un des exemples comportementaux de dommages collatéraux à craindre et 
qu'il faut surtout éviter de divulguer ;-)



> D'ailleurs... quel est le serveur qui génère ces rendus en export ? Yevaud ?

Quasi sûr que oui, l'onglet export en devient donc délicat, il est 
potentiellement consommateur de "mauvaise" bande passante mais surtout de 
charge, et ça, c'est serré sur yevaud. D'ici que la frustration des tuiles 
pas à jour amène à la création d'un outil qui appel ça directement, il n'y a 
qu'un pas, pas qui ne plaira pas aux admins.


-- 
sly, DWG member since 11/2012
Coordinateur du groupe [ga]
http://wiki.openstreetmap.org/wiki/User:Sletuffe

___
dev-fr mailing list
dev-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev-fr

Re: [OSM-dev-fr] [OSM-talk-fr] Tr : [OSM-talk] New OpenStreetMap tile server

[sly (sylvain letuffe)]

On mardi 18 décembre 2012, Eric Marsden wrote:
>   L'intérêt d'un serveur distinct de celui à Londres pour les
>   utilisateurs français me semble discutable. Depuis ma connexion Free
>   au domicile à Toulouse, je suis à 63 ms (16 hops) de
>   uppa-vl10-gi0-3-0-0-pau-rtr-011.noc.renater.fr, alors que je suis à 52
>   ms (15 hops) de me-rach.net.ic.ac.uk. 

Ouais bon ;-) 10ms de ping est sans aucune espèce d'importance à mon avis au 
regard des autres latences amont (internaute -> cache -> cache -> serveur de 
tuile (génération)* -> cache -> cache -> internaute

* étant l'étape clef sur laquelle il faut se concentrer pour ne pas avoir à la 
faire il me semble.




-- 
sly, DWG member since 11/2012
Coordinateur du groupe [ga]
http://wiki.openstreetmap.org/wiki/User:Sletuffe

___
dev-fr mailing list
dev-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev-fr

Re: [OSM-dev-fr] [OSM-talk-fr] Tr : [OSM-talk] New OpenStreetMap tile server

[sly (sylvain letuffe)]

On mercredi 19 décembre 2012, Christophe Merlet wrote:

Je vois dans les grandes lignes que l'on partage les mêmes idées, bien, 
yapukafaucon

> Yevaud est le générateur de tuiles. Il est effectivement tout seul pour
> effectuer cette tache. Par contre il ne fait pas partie du réseau
> GeoDNS, c'est Orm qui distribue la majorité des tuiles à la planète.

Je m'en serais douté, yevaud étant saturé ou presque d'accès disque, il leur 
fallait trouver toutes les solutions bouche trou à disposition et celle là 
semblait la plus simple et la plus rapide.
Le problème, c'est que ça n'arrange rien du problème de BP puisque orm est 
chez impérial
http://munin.openstreetmap.org/openstreetmap/orm.openstreetmap/if_eth0.html

Je peux me tromper, mais j'aurais mené un test avec comme choix du cache_peer 
un des autres serveurs externes à impérial si le but est la reduction de la 
bande passante.
Ayant lui-même yevaud comme cache_peer.
Ainsi seul 2 cache ont yevaud comme cache_peer : orm et 
http://wiki.openstreetmap.org/wiki/Servers/gorynych
(juste un exemple, ça m'a l'air le plus adapté)


> Cependant, Yevaud est le cache_peer des Squid du GeoDNS.
(j'avais traduit orm directement)

Nonobstant mon avis sur les autres solutions de meilleur allois, ceci 
participe à mon avis à maintenir la BP élevée chez impérial car toutes les 
demandes de tuiles sauf les hits des caches du CDN font gonfler la BP
on pourrait les réduire en cascadant.
Un utilisateur géolocalisé à moscou, bien que moins enclins à télécharger des 
tuiles françaises, va quand même en télécharger, et tout ça serait 
économisable.
 
> OSM ne paye pas la bande passante et n'en a pas les moyens.

Je m'en doute, et j'avais lu le blog de Richard (je crois ?) d'il y a ~1an qui 
disait que des réflexions remontaient régulièrement pour lui dire qu'il 
fallait faire quelque chose et que ça ne pourrait pas continuer.

> Ce n'est pas une bonne idée de consommer 1 Gbs chez un sponsor avant de
> décider de décharger le trafic ailleurs.

Sauf si ce sponsor a dit "ok, no problème" lâchez vous !

> Dans le meilleur des cas, la bande passante vaut quand même 5€/mois le
> Mb/s...

Oui et non, ça dépend. cf OVH

> Je relativise le 80%.
> Il ne me semble pas aberrant de penser que les internautes français
> regarde en priorité les tuiles françaises, et de même pour chaque pays.

ça oui, tout à fait, mais je parlais des cas où, je crois, mais des stats 
pourraient le confirmer, en moyenne les tuiles de zoom 12/13 et + sont 
demandées en moyenne 1,2 fois (ou dans ce goût là) !  donc gain du cache 
médiocre et donc double peine pour le premier à les télécharger alors que ça 
ne servira que peu ensuite.

> Donc grosso modo, si chaque serveur squid dessert une superficie qui 
> arrive a tenir dans son cache, le ratio ne doit pas être trop mauvais.

Je ne pense pas, tu peux mettre tout le cache que tu veux, ça ne changera pas 
des masses, le problème vient des headers de cache control :
$ wget -S http://b.tile.openstreetmap.org/15/16945/11703.png
Résolution de b.tile.openstreetmap.org... 128.40.168.104
  Cache-Control: max-age=61964 <
$ wget -S http://c.tile.openstreetmap.org/17/67784/46815.png
Résolution de c.tile.openstreetmap.org... 128.40.168.104
  Cache-Control: max-age=438903 <- wha punaise quand même, ho le joli 
bordel en perspective

le cache ne pouvant garder la tuile de zoom 15 que ~17h, sa probabilité d'être 
redemandée dans l'interval est trop faible à mon avis.

> Je vais voir s'il est possible d'avoir des stats du cache squid (accès
> par pays et par FAI...).

Et par zoom, ça serait un bon truc pour éviter que je m'égare aux morilles et 
le vérifie in real.



-- 
sly, DWG member since 11/2012
Coordinateur du groupe [ga]
http://wiki.openstreetmap.org/wiki/User:Sletuffe

___
dev-fr mailing list
dev-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev-fr

Re: [OSM-dev-fr] [OSM-talk-fr] Tr : [OSM-talk] New OpenStreetMap tile server

[sly (sylvain letuffe)]

On mardi 18 décembre 2012, Christophe Merlet wrote:
> Je trouve que le ratio hit/miss n'est pas fantastique mais néanmoins
> suffisant pour décharger un peu le Master.

J'ai une question pour toi si tu es au courant du setup squid :
Un cache_peer est-il utilisé sur le serveur de pau ?
En clair : Le squid du serveur de pau est il configuré pour d'abord demander à 
un des autres proxy du CDN (méthode de cascade) ou au contraire en direct à 
orm ou yevaud ?

http://wiki.openstreetmap.org/wiki/Servers/orm
http://wiki.openstreetmap.org/wiki/Servers/yevaud

-- 
sly, DWG member since 11/2012
Coordinateur du groupe [ga]
http://wiki.openstreetmap.org/wiki/User:Sletuffe

___
dev-fr mailing list
dev-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev-fr

Re: [OSM-dev-fr] [OSM-talk-fr] Tr : [OSM-talk] New OpenStreetMap tile server

[sly (sylvain letuffe)]

On mardi 18 décembre 2012, Christophe Merlet wrote:
> bah si, on peut en discuter.

Je préfère donc continuer sur dev-fr

> Moi-même je ne suis pas totalement séduit par la solution actuelle
> (Cache Squid). 

Après analyse un peu plus poussée, des dizaines de graph munin passés en 
revue, je vais tempérer un peu mes doutes pour finalement dire quelque chose 
du genre :
"J'accorde que ça semble être devenu nécessaire et donc c'est une bonne chose 
pour l'OSMF de demander de nouveaux serveurs de cache compte tenu des choix 
actuels, mais j'émets des doutes sur la politique choisie envers le rendu 
standard (page d'accueil d'osm.org) et des choix techniques qui en découlent"

Il s'agit donc du couplage "choix et rôle de ce rendu" impliquant "certains 
choix techniques" que je trouve douteux pour leurs/nos choix d'avenir.

détails :

Le rôle de ce rendu standard me semble ambiguë, d'un coté, on a ceux qui 
voudraient que ça soit un outil pour aider les contributeurs et faire vitrine 
pour présenter "les données osm" et d'autres souhaiteraient peu ou prou que 
ça deviennent un remplaçant direct de google maps (en terme de disponibilité, 
mise à jour, beauté, rapidité et destiné au plus grand nombre)

La politique visant à monter un CDN tente de répondre à l'objectif deux, et 
implique des choix techniques qui me semblent incompatibles avec l'objectif 
1.
Et maintenir l'objectif 1 pénalise grandement la mise en oeuvre du CDN.

> Je trouve que le ratio hit/miss n'est pas fantastique mais néanmoins
> suffisant pour décharger un peu le Master.

Yevaud, le master actuel, me semble confronté à 3 problèmes :
- Charge trop élevée
- BP trop élevée
- Single point of failure

Bref généralités : A mon sens, un CDN de type "cache stupide" (se basant 
uniquement sur les headers d'expiration) est fait pour distribuer du contenu 
éminemment statique, de validité longue, et demandé avec comme base un gros 
ratio hit/miss pas pour diminuer une charge CPU mais une BP de l'ordre de 
1Gbit/s et plus.

On voit bien le résultat : [4] 40% de miss ! ça veut dire que dans 40% des 
cas, et, à mon avis, dans ~80% des cas sur zoom élevés (+11) on inclus 
latence, retard de fraîcheur dans les tuiles et donc pénalité pour objectif 
1) et juste un peu mieux pour l'objectif 2) partie BP
C'est à mon sens peu glorieux pour le nombre de serveur mis en jeu, temps de 
maintenance à y passer et risque de problèmes qui vont s'ajouter.

charge/failure : La mise en oeuvre technique choisie du CDN ne répond à mon 
sens pas du tout ou uniquement très peu au problème de charge car yevaud et 
le point central qui génère les tuiles, et dans ce processus, ça charge 
inquiétante [1] [2] ne me semble dû quasi-exclusivement qu'a la génération 
proprement dite, pas la distribution. Créer le CDN à base de cache n'aide en 
rien pour améliorer ça, et n'apporte pas non plus de solution de replie en 
cas de pépin sur Yevaud.

BP : ça ok, le CDN aide... un peu, mais pour ça, il faut, encore une fois, 
avoir une majorité de contenu statique et très régulièrement demandé, ce qui 
n'est le cas grosso modo que pour les tuiles de zoom faible mais pas ou très 
peu pour les zoom 11 et + qui sont la cause d'une grosse partie du trafic.
[3] montre que sur un an, l'ajout de 3 serveurs de cache n'a fait que 
compenser la croissance des visites de osm.org
Bilan le problème de BP n'a même pas été amélioré ! L'endroit où les coûts de 
BP sont problématique restent problématiques !
Ça ne veut pas dire que ça n'est pas utile, on a au moins réussi à stopper la 
croissance, c'est déjà un bon point, mais je pense qu'avec d'autres 
solutions, on aurait pû régler le problème, là, on va courir après la 
croissance et on va finir par être obligé de prendre des mesures à dommages 
collatéraux.


> Mais cette solution a plusieurs avantages. C'est facile à administrer à
> distance. ça ne nécessite pas de serveur puissant, juste de la RAM (en
> 9h, 18 Go de tuiles distinctes ont été demandées). 

Je te l'accorde, mais une mise en oeuvre/maintenance aisée (encore que 
j'attends sur le long terme) qui ne sert à pas grand chose n'est pas 
forcément plus profitable qu'une réflexion amont pour ré-attribuer objectifs, 
configs et donc ressources.

> Il semble que les sysadmins osm réfléchissent à d'autres solutions,
> genre des générateurs de tuiles autonomes. 

A mon avis, pour l'objectif 2) voire l'objectif 1) c'est LA solution a 
privilégiée, car cela réduirait tout : charge, manque de redondance, BP chez 
nos voisins anglais.
C'est certes plus difficile car ressources plus chères, mais ce serait à mon 
sens largement plus efficace.

> Pas sûr que les internautes y gagne avec cette solution.
Moi je pense que oui, et je fais le paris que tant que plus nous avançons vers 
la solution CDN, pire encore pour les internautes ça va être.

(Philippe V. dans un plaisant message de lucidité, à déjà pointé du doigts 
quelques problèmes pour l'objectif 1))
Mais connaissant bien les options de mod_tile, je cr

Re: [OSM-dev-fr] Nominatim - postcode

[sly (sylvain letuffe)]

On lundi 17 décembre 2012, Cyrille Giquello wrote:
> Bonjour Olivier,
> 
> Personne n'a répondu... Peut être lancer le sujet sur
> t...@openstreetmap.fr 

Cette liste n'est pas tout à fait faite pour ça et comme il n'y a pas 
d'instance de nominatim sur les serveurs de l'asso, ça n'arrangera pas le 
schmilblik.

> ou carrément sur talk...@openstreetmap.org. 

Un peu trop technique pour cette liste je pense.

Je suggère :
http://wiki.openstreetmap.org/wiki/Talk:Nominatim
Qui me semble le meilleur espoir d'obtenir de l'aide de l'équipe qui s'occupe 
de nominatim.

d...@openstreetmap.org est une autre option

et une 3ème :
https://trac.openstreetmap.org/query?status=new&status=assigned&status=reopened&component=nominatim&order=id&desc=1

En france, on est balèze, mais à un moment, ça fini quand même par dépasser 
nos connaissances/compétences ;-)

> En tout cas je suis intéressé par la réponse :-)



> Cyrille.
> 
> Le 13 décembre 2012 15:19, olivier Bennegent
>  a écrit :
> > Salut,
> >
> > J'ai installer nominatim-2.0.0 et j'ai insérer des données osm (extrait
> > Rhone-alpes.osm) dans ma base postgres 9.1 sous une Vmware Ubuntu 12.04.
> > Enfin arrivé à un résultat après quelque corrections de bugs, j'arrive 
donc
> > sur mon site nominatim en local et procède à quelque test de géocodage.
> >
> > Je m’aperçois vite qu'il ne comprends pas les codes postales car toutes
> > adresses saisies sans code postal (plus ou moins précise) me renvoie un
> > résultat plutôt satisfaisant et dés lors que je complète une adresse avec 
un
> > code postale, celui-ci est perdu...
> >
> > Exemple d'une adresse sans code postale au format xml: '139 avenue roger
> > salengro villeurbanne'
> >
> > http://www.openstreetmap.org/copyright"; querystring="139 avenue roger
> > salengro villeurbanne" polygon="false"
> > 
exclude_place_ids="241388,230347,230349,230350,630557,230355,206243,461690,230346,630556,241387,230345,211643,630554,540321,201776,443607,540322,461691,241588,630555,241587,202519,211642"
> > 
more_url="http://10.133.110.51/search?format=xml&exclude_place_ids=241388,230347,230349,230350,630557,230355,206243,461690,230346,630556,241387,230345,211643,630554,540321,201776,443607,540322,461691,241588,630555,241587,202519,211642&accept-language=fr,fr-fr;q=0.8,en-us;q=0.5,en;q=0.3&viewbox=4.88%2C45.79%2C4.89%2C45.77&q=139+avenue+roger+salengro+villeurbanne";> > place_id="241388" osm_type="way" osm_id="18507867" place_rank="26"
> > 
boundingbox="45.7809562683105,45.7810668945312,4.88439226150513,4.88446044921875"
> > lat="45.7809582" lon="4.8843923" display_name="Avenue Roger Salengro,
> > Croix-Luizet, Villeurbanne, Lyon, France" class="highway"
> > type="primary"/> > place_rank="26"
> > 
boundingbox="45.7825889587402,45.7828102111816,4.88966178894043,4.89033126831055"
> > lat="45.7827407" lon="4.8900619" display_name="Avenue Roger Salengro, 
Buers,
> > Villeurbanne, Lyon, France" class="highway" type="primary"/> > place_id="630557" osm_type="way" osm_id="186872197" place_rank="26"
> > 
boundingbox="45.7763710021973,45.7765007019043,4.87301254272461,4.87369203567505"
> > lat="45.7763849" lon="4.873076" display_name="Avenue Roger Salengro, La
> > Doua, Villeurbanne, Lyon, France" class="highway" type="primary"/> > place_id="230355" osm_type="way" osm_id="5079031" place_rank="26"
> > 
boundingbox="45.7741241455078,45.7760887145996,4.86810445785522,4.87120294570923"
> > lat="45.7752699" lon="4.8698822" display_name="Avenue Roger Salengro,
> > Charpennes, Villeurbanne, Lyon, France" class="highway"
> > type="primary"/> > place_rank="26"
> > 
boundingbox="45.7762641906738,45.776424407959,4.87211608886719,4.87307500839233"
> > lat="45.7764145" lon="4.8730073" display_name="Avenue Roger Salengro, La
> > Doua, Villeurbanne, Lyon, 69100, France" class="highway"
> > type="primary"/>
> >
> > Exemple de la même adresse avec code postale au format xml: '139 avenue
> > roger salengro 69100 villeurbanne'
> >
> > http://www.openstreetmap.org/copyright"; querystring="139 avenue roger
> > salengro 69100 villeurbanne" polygon="false"
> > 
more_url="http://10.133.110.51/search?format=xml&exclude_place_ids=&accept-language=fr,fr-fr;q=0.8,en-us;q=0.5,en;q=0.3&viewbox=4.88%2C45.79%2C4.89%2C45.77&q=139+avenue+roger+salengro+69100+villeurbanne";>
> > 
> >
> > Ma base comprends les tables gb_postcode (postcode GB) et us_postcode
> > (semblable) mais pas de tables qui pourraient contenir un ensemble de 
codes
> > postales pour la France.
> > Pour l'instant, je pense que mon erreur provient des tables 'word' et
> > 'search_name' avec le champ 'name_vector' mais encore rien de sur.
> >
> > Cette non compréhension des postcodes de la part du fichier search.php me
> > parait d'autant plus bizarre car lorsque je recherche le postcode associé 
à
> > mon adresse '139 avenue roger salengro' le champ est bien rempli par
> > '69100'...Il n'arrive donc pas à faire la correspondance mais après avoir
> > analysé 'search.php', je ne vois pas ce qui le bloque.
> >
>

Re: [OSM-dev-fr] Osm watch à la peine ?

[sly (sylvain letuffe)]

Le dimanche 16 décembre 2012 23:17:20, yvecai a écrit :
> Je n'ai plus rien sur le RSS "piste:type"="nordic"
> http://osm102.openstreetmap.fr/~zorglub/watch/ à des soucis ?

Pas mieux, je n'ai plus eu de remontées sur mes deux fils rss depuis plusieurs 
jours et ça semble louche...

-- 
sly (sylvain letuffe)

___
dev-fr mailing list
dev-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev-fr

Re: [OSM-dev-fr] Nouvelle interface web sur beta.osmose.openstreetmap.fr

[sly (sylvain letuffe)]

Le dimanche 02 décembre 2012 19:34:33, Frédéric Rodrigo a écrit :
> Le 01/12/2012 20:13, Pierre Béland a écrit :
> > Il serait intéressant d'ajouter, tout comme dans Layers, la couche de
> > chemins de limites administratives.
> 
> Je ne suis pas très fan de cette couche. Ce qui à mon avis doit définir
> une way comme limite administrative est son appartenance à une relation
> de limites administrative. Pour moi les tags sur les ways sont désuets.

Je suis d'accord avec cette analyse, layers l'avait eu un temps, avant que je 
ne l'enlève pendant 2 ans pour finalement la remettre récemment à la demande 
de pierre.

Pierre avait alors avancé un argument assez valable, bien qu'a double 
tranchant :
L'argument était de pouvoir repérer les chemins orphelins (n'appartenant pas à 
des relations administratives) ce qui, ma foi, est valable puisque ces outils 
ont pour but d'aider à repérer les erreurs
Toutefois, dans les cas où ils ne sont pas orphelins (majorité des cas), cela 
cautionne alors une utilisation très discuttable qui consiste à taguer tous 
les chemins avec des admin_level, cas pour lequel je suis d'accord avec ta 
réticence.

La solution que je cherche alors serait de n'afficher que les chemins ayant un 
boundary=administartive mais n'étant pas membre d'une relation valide, mais 
ça, je n'ai pas trouvé comment le faire simplement.



-- 
sly (sylvain letuffe)

___
dev-fr mailing list
dev-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev-fr

Re: [OSM-dev-fr] Importation données Nominatim

[sly (sylvain letuffe)]

Le mardi 27 novembre 2012 10:17:57, olivier Bennegent a écrit :
> Bonjour,
> 
> Je viens d'importer l'extrait rhone-alpes.osm dans ma base postgres avec
> postgreSQL 9.1 et postGIS 1.5.3-2 sous Ubuntu 12.04 avec l'outil osm2pgsql.
> J'ai installé Nominatim pour pouvoir faire du géocodage seulement je me
> demande si je n'aurais pas du faire l'importation après l'avoir installé.
> Cela posera t'il problème ?

Vérifies bien la documentation d'installation de nominatim, car il me semble 
qu'autrefois il utilisait la base osm2pgsql "classique" mais qu'a force de 
faire des nouveaux champs, nouvelles tables, ils ont fini par dupliquer 
osm2pgsql et en faire une version spéciale nominatim (et incompatible avec 
l'autre) qu'il te faut impérativement utiliser.

donc, si tu as d'abord installé osm2pgsql "tout seul" depuis 
http://wiki.openstreetmap.org/wiki/Osm2pgsql
alors à mon avis, c'est perdu et tu es bon pour refaire avec la procédure de 
nominatim


-- 
sly (sylvain letuffe)

___
dev-fr mailing list
dev-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev-fr

Re: [OSM-dev-fr] idées pour projet tutoré autour de l'admin de SIG

[sly (sylvain letuffe)]

On jeudi 15 novembre 2012, Pieren wrote:
> Ca existe déjà. Je chercherais les liens si on me demande seulement.

J'ai bien envie de te demander, car la dernière fois (1an) que j'ai cherché, 
ça n'était déjà plus à jour et les logiciels étaient anciens. (et sauf 
erreur, il n'y avait que la chaine 
osm2pgql->postgis->mapnik->renderd->mod_tile

Sans pour autant cracher dans la soupe, c'est déjà super, mais il n'y a pas 
overpass (xapi), nominatim ou une base osmosis qui sont quand même des 
pierres angulaires des outils actuels de l'écosystème osm

-- 
sly
qui suis-je : http://sly.letuffe.org
email perso : sylvain chez letuffe un point org

___
dev-fr mailing list
dev-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev-fr

Re: [OSM-dev-fr] idées pour projet tutoré autour de l'admin de SIG

[sly (sylvain letuffe)]

On jeudi 15 novembre 2012, Frédéric Rodrigo wrote:
> Il me semblerait également pertinent de faire produire aux étudiants une 
> image de VM vierge de donnée avec une documentation pour utiliser les 
> logiciels et y charger des données.

C'est vrai que ça serait pas mal, déjà pour eux car ça leur permettrait de 
mettre la main sur la virtualisation qui est un outil intéressant, et pour 
nous ensuite de pouvoir ré-utiliser facilement ce résultat.

-- 
sly
qui suis-je : http://sly.letuffe.org
email perso : sylvain chez letuffe un point org

___
dev-fr mailing list
dev-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev-fr

Re: [OSM-dev-fr] idées pour projet tutoré autour de l'admin de SIG

[sly (sylvain letuffe)]

(Pour infos pour les autres, voici ce que je lui avais transmis en privée 
suite à sa demande)

Le mercredi 14 novembre 2012 15:51:36, Lucas Nussbaum a écrit :
> Bonjour,

Salut lucas,

> J'enseigne principalement dans le cadre de la licence
> professionnelle ASRALL (Administration de systèmes, réseaux et applications
> à base de logiciels libres). 

Vous avez poussé la bonne porte ;-)
- openstreetmap et son écosystème libre ont de quoi occuper vos étudiants un 
petit moment pile poil dans la thème de votre licence.

> -->8
> Installation et configuration d'un système d'information géographique
> 
> Objectif: installer et configurer un miroir local (partiel)
> d'Openstreetmap, ainsi que plusieurs outils associés.
> - postgis + osmosis pour importer et tenir à jour les données
> - serveur web de carte (mapnik and co)
> - API overpass pour permettre de télécharger les données
> - possibilités d'extensions:
>   + installation d'outils de QA pour OSM (par exemple osmose)
>   + serveur de tiles custom
>   + visualisation combinée de données de différentes sources (cf
>     http://www.vttrack.fr/)
> -->8

Joli projet, ce n'est pas toutefois certains que ça remplisse les 200h. Ces 
outils sont très bien documentés et assez aboutis puisque déjà opérationnels.
Pour quelqu'un de bien habitué à Linux, faire ce que vous venez de lister se 
fait en ~50h à mon avis.
Après, tout dépend de leur niveau. S'ils découvrent ssh, bash, git, 
compilation, là, ça peut cette fois devenir juste ;-)

 
> Sylvain car j'ai cru comprendre que tu jouais un rôle
> central dans l'admin des serveurs d'openstreetmap.fr) 

On est au moins 5 à gérer l'architecture serveur/réseau/applis, mais je suis 
en charge des bases liées au rendu de carte + overpass


> pour savoir si vous
> pourriez me donner un coup de main occasionnel dans le cas où les
> étudiants se retrouveraient face à un mur. 

Je ne peux pas vraiment promettre, mais si quelqu'un avec des questions 
réfléchies vient les poser sur le forum:
http://forum.openstreetmap.fr
ou la liste de développement :
http://lists.openstreetmap.org/listinfo/dev-fr

J'aurais sans doute plaisir à y répondre, et pas que moi.


> Le projet tel que proposé ci-dessus vous semble-t-il réaliste ? 

Oui

> Voyez-vous d'autres directions vers lesquelles il serait intéressant de les
> emmener ?

Mon avis va être biaisé en direction de notre besoin (dans la communauté 
française) où imaginer que des gens vont passer 200h pour des trucs qui 
existent déjà, ne peuvent m'empêcher de dire "dommage".
Mais s'intégrer dans la communauté durant le projet, réaliser des choses qui 
seront utiles par la suite aurait le gros avantage de mettre du concret dans 
le projet. Et je suppose que la motivation général à aider, et la mienne en 
particuliers serait augmentée vu qu'on rentre dans le donnant-donnant.


> (mes idées d'extensions sont peut-être un peu trop "web" et pas assez
> "admin sys" pour cette licence pro)

La partie admin sys est une part importante d'un tel projet, mais si on 
s'arrêt à un serveur avec 3 bases de données fonctionnelle, on n'a toujours 
pas vu :
1) à quoi ça sert
2) si ça marche vraiment

C'est pour ça que souvent, l'extension touche à des thèmes un peu hors sujet 
de la licence que sont développement (même minimum) et design d'interface (en 
peu de html et un peu de javascript)


> A priori, vous n'avez pas grand chose à y gagner. Ce qu'on pourrait
> imaginer, c'est de demander aux étudiants de décrire précisément leur
> démarche sous la forme de Howtos qui seraient disponibles sur un wiki (ou
> d'améliorer les Howtos existants).

Utiliser et faire des rapports de bugs est déjà un gain, rédiger des docs est 
carrément super, mais fournir en fin de projet une machine virtuelle (ou, 
disons, la liste des opérations à faire, les fichiers de conf, et les quelques 
scripts créés histoire de pouvoir remettre en place la même chose serait 
génial !)

ps: je sais que c'est plus consommateur en temps, mais je vous suggère de 
représenter votre projet (copier/coller votre mail, ou me donner 
l'autorisation de le faire) sur la liste dev-fr :
http://lists.openstreetmap.org/listinfo/dev-fr

Vous aurez plus d'avis, et même si vous ne participer pas activement au débat, 
ça peut faire sortir un projet que nous pouvons construire, sur la base du 
votre et pour lequel vos étudiants auront beaucoup plus de chance d'être 
suivi/aider vu que ça irait dans notre intérêt aussi.

-- 
sly
qui suis-je : http://sly.letuffe.org
email perso : sylvain chez letuffe un point org

___
dev-fr mailing list
dev-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev-fr

Re: [OSM-dev-fr] BIS : Problème de validation et de diffusion des Messages à modérer de la liste local-marseille

[sly (sylvain letuffe)]

On jeudi 8 novembre 2012, Olivier Griffet wrote:
> *Bonjour à toutes et à tous.

Salut,

> Ci-dessous le message que j'ai envoyer hier 7 novembre 2012, et pour
> l'instant, sans réponse à ma demande.

Heu... ton mail date de hier soir 18:23, un peu de patience tout de même !

Pour augmenter tes chances de contacter la bonne personne, je te recommande la 
liste tech :
http://wiki.openstreetmap.org/wiki/WikiProject_France/OSM-FR/Groupes_de_travail/Technique
ou contacter la personne en charge :
http://wiki.openstreetmap.org/wiki/FR:Servers#Liste_des_adresses_sur_le_domaine_openstreetmap.fr

-- 
sly
qui suis-je : http://sly.letuffe.org
email perso : sylvain chez letuffe un point org

___
dev-fr mailing list
dev-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev-fr

Re: [OSM-dev-fr] Ma Premiere Petite Page OSM / Open Data

[sly (sylvain letuffe)]

Le jeudi 01 novembre 2012 22:01:21, Ista Pouss a écrit :
> Bonjour,

Bonsoir,

> c'est juste à titre expérimental.
> 
> http://www.diaam.com/odosm/305-Zones-de-circulation-apaisee.html

Et ben ça marche, c'est le principal non ?

Peut-être imaginer à l'avenir de n'avoir qu'une seule carte, où on afficherait 
pas exemple tout (si pas trop gros) ou un sélecteur pour choisir zone par zone 
ou données par données. Ça éviterait la multiplication du nombre de carte, ce 
qui pourrait devenir gênant à gérer quand tu aura 1000 trucs à afficher ;-)

 
> - Pour le rendu des cartes, j'ai utilisé leaflet... j'ai bon ?
Si tu parles bien du rendu de l'affichage des données en plus = celles en 
bleu, disons que seul le résultat compte non ? donc en effet, ça à l'air de le 
faire...
En autre choix tu as openlayers, mais ça doit plus ou moins revenir au même.


> ça fonctionne bien, mais la carte est très peu
> visible... y a-t-il des rendus de carte meilleurs sur portable, ou est-ce
> que j'ai loupé quelque chose ?

Rien à dire sur mon téléphone (android 2.3) ça s'affiche bien et c'est 
lisible.


> - Si je commence à comprendre comment on fait une lecture des données osm,
> c'est encore le brouillard total pour l'écriture. 

Tant mieux, ne précipite rien ;-) Il y a de grande chances que tenter 
d'importer tel quel sans retouche aucune ne soit pas une super idée.
Une intégration dans OSM de données extérieures, c'est sensible :
il ne faut pas créer de doublon, il ne faut tenir compte de l'existant, bref, 
c'est souvent préférable de gérer au cas par cas, quitte à avoir de l'aide en 
ouvrant les données déjà prêtes pour ne pas les re-tracer.


> Si, par exemple, je
> voulais écrire par logiciel ces données de zones apaisées dans osm,
> pourrais-je le faire directement depuis mon logiciel ? 
Oui

> Ferais-je mieux de
> passer par josm 
oui, à mon avis.


> et son interface de commande à distance ? 
pourquoi pas, c'est une solution.


> Ces zones
> apaisées devraient-elles être des "areas" ou des "relations" ?

les relations peuvent représenter des "areas", la question est donc plus :
Est il préférable que ces zones :
- soient rentrées sous forme de surfaces
- soient rentrées dans chaque chemin concernés

Et si le choix est "surface" :
- soit un seul chemin fermé (plus simple)
- soit une relation de plusieurs chemins (peut être utile par exemple si les 
données à importer on plus de chance d'avoir comme base des éléments du 
terrain comme des routes, des rivières, etc. qui pourrons alors être ré-
utilisés)

Mais d'autres questions sont aussi à se poser comme les tags à choisir, ou 
encore que faire à l'avenir :
- comment préparer l'éventualité de mise à jour
- comment surveiller que rien n'est supprimé par erreur 
- comment suivre l'état de l'importation (est-ce fini ? en reste-t-il à 
importer, si oui où ?)

-- 
sly (sylvain letuffe)

___
dev-fr mailing list
dev-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev-fr

Re: [OSM-dev-fr] osm-watch, outil de veille de changesets

[sly (sylvain letuffe)]

> Le 14 octobre 2012 11:31, Clément Stenac  a écrit :
> > Bonjour,
> > 
> > Comme j'en avais parlé il y a quelques temps, une toute première version
> > d'un outil de surveillance de changesets est prête:
> > 
> > http://osm102.openstreetmap.**fr/~zorglub/watch/<http://osm102.openstreet
> > map.fr/~zorglub/watch/>

Pour info, je lui ais créé une page dédiée sur le wiki :
http://wiki.openstreetmap.org/wiki/Osm-watch

j'ai repris son nom de ton dépot github


-- 
sly (sylvain letuffe)

___
dev-fr mailing list
dev-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev-fr

Re: [OSM-dev-fr] osm-watch, outil de veille de changesets

[sly (sylvain letuffe)]

On lundi 29 octobre 2012, Ab_fab wrote:
> On peut désormais voir le nom du contributeur pour chaque groupe de modif
> recensé par le flux RSS.
> Très pratique.
> 
> Merci Clément !

Et une option existe maintenant pour recevoir les alertes par emails (en plus 
ou à la place du flux rss)

c'est que cet outil commence à vraiment devenir pratique !

Bravo bis à clément.

Fan++

-- 
sly
qui suis-je : http://sly.letuffe.org
email perso : sylvain chez letuffe un point org

___
dev-fr mailing list
dev-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev-fr

Re: [OSM-dev-fr] Overpass: chercher POI dans une limite admin.

[sly (sylvain letuffe)]

On mercredi 10 octobre 2012, Christian Quest wrote:
> Donc...
> 
> http://api.openstreetmap.fr/oapi/interpreter?data=LAREQUETE
> 
> Pour les area-query, il y a une base MySQL qui vient compléter la base
> primaire d'après ce que j'ai lu/compris.

Ha ? beuh ? oulla...

Si c'est bien le cas, j'ai effectivement loupé quelque chose car je n'ai pas 
du tout géré quelle que base MySQL que ce soit...

Il me semblait pourtant que ça marchait avant, mais peut-être ma mémoire me 
fait-elle défaut.

Donc, pour l'instant, pas d'autres choix que d'utiliser 
http://overpass-api.de/api/interpreter

Je tenterais de creuser cette histoire quand je mettrais en place la 
base "france uniquement", car, avouons le, c'est bien pratique de pouvoir 
télécharger ce que contient par exemple une commune plutôt que la bbox 
toujours un peu trop... rectangulaire

-- 
sly
qui suis-je : http://sly.letuffe.org
email perso : sylvain chez letuffe un point org

___
dev-fr mailing list
dev-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev-fr

Re: [OSM-dev-fr] Overpass: chercher POI dans une limite admin.

[sly (sylvain letuffe)]

Le lundi 08 octobre 2012 22:23:10, Christian Quest a écrit :
> En "overpass QL", ça se résume à:
> 
> (area-query:367444);way(bn);(way._["tourism"];node(w););out
> meta;node(area-query:367444)["tourism"];out meta;
> 
> Par contre, je n'ai pas trouvé comment l'exécuter sur
> api.openstreetmap.fr...

Normalement c'est là :
http://api.openstreetmap.fr/query_form.html

Toutefois, j'ai l'impression que les requêtes contenant des "area-query" ne 
semblent pas être prises en compte.
Il est donc possible que j'ai oublié quelque chose lors de l'installation 
initiale


-- 
sly (sylvain letuffe)

___
dev-fr mailing list
dev-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev-fr

[OSM-dev-fr] Outils de surveillance sur la France des changement suspects et suivi de zones

[sly (sylvain letuffe)]

Bonjour,

Le débat d'a coté "changeset suspect ?" (sur talk-fr) me donne envie de 
relancer l'idée de la création d'un outil de surveillance (bon, c'est clair 
que plus qu'une idée, c'est surtout le faire qu'il faudrait).
Je me dis que le besoin est là, qu'on a les serveurs pour le faire tourner, 
mais qu'avant de me lancer tête baissée dans un truc trop gros pour n'aboutir 
à rien, j'aurais aimé faire un tour de table de ce qui existe déjà, de savoir 
si certains se sont lancé en privé dans ce type de projet et, pourquoi pas, 
monter une équipe pour arriver en phase 1 à un petit quelque chose qui puisse 
servir.

Je connais cette page :
http://wiki.openstreetmap.org/wiki/QA#Monitoring_Tools
Et grosso modo, ceux qui ressortent et sont réputés sont OWL et ITO world OSM 
Mapper.
Mais l'un est HS pour l'instant et l'autre dispose d'un flux RSS pour voir 
passer les changements d'une zone, mais la dernière fois que je me suis 
servi, c'est peu dur à utiliser car ça sort beaucoup de chose.

Il y aussi le "live editeur" de christian (un peu plus axés bing bling ;-) 
mais avec du potentiel)

Sauriez-vous le(s)quel(s) sont déjà utilisé par l'équipe du DWG pour 
surveiller les changeset douteux ?
En utilisez vous d'autres qui permettent de monitorer les changements sur des 
critères de type zone/dernier user/selon tag ou truc du genre ?

Si rien n'est probant, je pensais éventuellement commencer un prototype 
utilisant les 
http://wiki.openstreetmap.org/wiki/Overpass_API/Augmented_Diffs
(avec une installation sur la France uniquement)
Ces diffs permettent en effet d'avoir l'ancienne et la nouvelle version d'un 
objet ce qui peut déjà, sans base de donnée, permettre quelques analyses 
simples sur des suppressions massives, des objets touchés qui avait certains 
tags et ce genre de chose.

Je ne vise pas du tout refaire ce que fais déjà osmose parfaitement avec des 
analyses très performantes, rangées par catégories sur une état de la base à 
l'instant du lancement de l'analyse, mais plus un mécanisme de surveillance 
qui pourrait déclencher une alerte lorsqu'un changeset correspond à tels 
critères.

(Me relisant, je suis peut-être juste perché sur mon nuage du rêve alors que 
je ferais sans doute mieux de taper du code, mais sait-on jamais, je lance 
mon hameçon...)

-- 
sly
qui suis-je : http://sly.letuffe.org
email perso : sylvain chez letuffe un point org

___
dev-fr mailing list
dev-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev-fr

[OSM-dev-fr] Petit changement de comportement sur la XAPI présente sur http://api.openstreetmap.fr/xapi

[sly (sylvain letuffe)]

Bonjour,

Suite à une remarque sur la liste talk-fr indiquant que l'interface xapi 
présente sur le serveur http://api.openstreetmap.fr/ n'était pas tout à fait 
compatible avec la documentation décrite de XAPI sur le wiki ici : 
http://wiki.openstreetmap.org/wiki/Xapi

J'ai jugé bon de réaliser une amélioration permettant d'être le plus 
compatible possible avec la documentation.

Désormais, le fichier osm renvoyé par cette xapi renvoi les informations de
version, timestamp, changeset, uid et user (utile par exemple pour l'édition 
ensuite avec JOSM ou, comme il en a été fait le remaque, l'éditeur OSM de 
ArcGis)
alors que, par défaut, ces informations n'étaient pas renvoyées avant, ce qui 
n'est pas cohérent avec la documentation.

Toutefois, il y avait une raison à cela, c'est la performance. Qui dit plus 
d'information, dit une taille de fichier plus grosse, et plus long à 
envoyer/traiter/générer ce qui, dans le cas ou les informations 
supplémentaires ne sont pas utilisées, peut-être est un gain de temps 
appréciable.

J'ai donc mis en place une XAPI "bis" que j'ai appelée xapi-without-meta
dont l'appel ce fait là : http://api.openstreetmap.fr/xapi-without-meta
qui elle, par défaut, ne renvoi pas les informations citées ci-avant et qui 
est donc plus rapide.

Si vous êtes utilisateur de l'ancienne xapi fr et que vous n'êtes pas 
intéressé par les informations "meta" je vous recommande de changer l'url de 
vos programmes afin d'accélérer les choses. Bien que sans les changer, cela 
devrait continuer à marcher comme avant si votre programme est capable 
d'ignorer ces informations rajoutées.

Pour ceux qui en revanche avait besoin des informations "meta" cela ne devrait 
rien changer pour eux si ce n'est qu'il est maintenant superflu d'ajouter le 
prédicat [@meta] bien que le mettre quand même ne change rien.

-- 
sly
qui suis-je : http://sly.letuffe.org
email perso : sylvain chez letuffe un point org

___
dev-fr mailing list
dev-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev-fr

Re: [OSM-dev-fr] live.openstreetmap.fr besoin de test et retours avant annonce...

[sly (sylvain letuffe)]

> Vos remarques sont les bienvenues avant que l'on annonce l'existence
> de ce "live" (je prévois ça pour SOTM).

Toutes remarques ?
Alors je vais aller à l'opposé de toutes les éloges lues ici et là :
"Mais à quoi ce truc peut-il bien servir ?"
Dans la lignée de love-story, voici "osm-story", le site ou on peut suivre en 
live un autre contributeur qui ajoute un chiotte au guatemala ?

Je suis perplexe, ça va faire rire quelques minutes, et 3 jours après 
l'annonce le trafic sur le site sera de 0.
(ou alors c'est moi qui ne suis pas dans la mouvance du voyeurisme anonyme)

Ou alors, c'est une vitrine temporaire pour dire : regarder ce que l'on peut 
faire, pour l'instant ça ne sert à rien, mais l'avenir, c'est un flux rss qui 
vous prévient quand un contributeur touche des trucs dans votre coin.

bref, belle réalisation en tout cas, reste plus qu'a trouver à quoi ça sert et 
à qui...

-- 
sly
qui suis-je : http://sly.letuffe.org
email perso : sylvain chez letuffe un point org

___
dev-fr mailing list
dev-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev-fr

Re: [OSM-dev-fr] Réflexion autour des fichiers diff OSM

[sly (sylvain letuffe)]

On mardi 28 août 2012, Christian Quest wrote:
> SUPER !

c'est en effet une super nouvelle, ça ouvre la voie à des mises à jour plus 
rapides, des mises à jour de zones réduites.

> Y'a plus qu'à tester leur utilisation 

Pour ça, il va falloir coder un peu pour que les outils habituels en profitent

-- 
sly
qui suis-je : http://sly.letuffe.org
email perso : sylvain chez letuffe un point org

___
dev-fr mailing list
dev-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev-fr

Re: [OSM-dev-fr] Réflexion autour des fichiers diff OSM

[sly (sylvain letuffe)]

> J'ai vu cette possibilité en voulant installer une overpass API.
> Il me semble que cela consiste essentiellement à copier un snapshot des
> fichiers d'une overpass à une autre, non ? Il y a un mécanisme plus
> perfectionné que ça ?

Je viens de vérifier et en fait, ça consiste juste à ça en effet, toutefois, 
il y'a un appel prévu pour demander à l'overpass source de préparer ces 
fichiers (ce n'est pas fonctionnel par défaut sur une instance neuve, juste 
celle de http://overpass-api.de/) qui s'occupe alors d'en faire une copie, de 
les compresser et de les rendre disponible à un téléchargement.

C'est un peu "brut de script" comme on pourrait par exemple récupérer un dump 
SQL d'une base osm2pgsql pour la dupliquer plus rapidement.
Mais l'idée reste celle-ci : ne pas toujours repartir du fichier planet.osm
(et ça à aussi l'avantage d'exister)


-- 
sly
qui suis-je : http://sly.letuffe.org
email perso : sylvain chez letuffe un point org

___
dev-fr mailing list
dev-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev-fr

Re: [OSM-dev-fr] Réflexion autour des fichiers diff OSM

[sly (sylvain letuffe)]

On mercredi 8 août 2012, Christian Quest wrote:
> J'y ai aussi pensé, mais cela limite beaucoup plus le champs
> d'utilisation, c'est du pur osm2pgsql.

Pour avoir du grain à moudre et d'autres visions sur ce qui se fait, la 
dernière version de l'overpass API intègre un mécanisme proche de ce dont on 
parle, mais pas pour les diffs (uniquement pour l'import initial) :
http://wiki.openstreetmap.org/wiki/Overpass_API/versions

Son idée, pas idiote, est que toute instance de l'overpass API peut 
être "clonée" afin de re-construire une base à jour à l'identique.
Je ne connais pas les entrailles précisément, mais le résultat annoncé est de 
~4/8 heures pour un import de la base monde, là où, en partant d'un fichier 
planet.osm il faut ~20 heures

Cela permet donc une topologie en multi-pyramide où chaque nouvelle instance 
peut se greffer sur une existante et gagner du temps pour la construction 
initiale.
En revanche, ce mécanisme n'existe pas (encore) pour les diffs
Et à mon avis, c'est du super spécifique à ce format, je doute qu'il est voulu 
à la base un format générique

-- 
sly
qui suis-je : http://sly.letuffe.org
email perso : sylvain chez letuffe un point org

___
dev-fr mailing list
dev-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev-fr

Re: [OSM-dev-fr] Réflexion autour des fichiers diff OSM

[sly (sylvain letuffe)]

> +1: les diffs actuels ne sont pas à supprimer, mais à compléter d'où
> l'idée de parle d'updates et plus de diff.

Oui, pardon, j'avais bien compris que tu ne parlais pas de leur suppression, 
je me suis mal exprimé. La question que je me posais était plutôt "qui 
devrait être en charge de cette génération" et tu semblais (?) suggérer que 
la fondation OSM s'en charge. Bien que s'ils le proposaient, j'en serais 
ravis, je me demande s'ils n'ont pas déjà assez de boulot et que c'est 
quelque chose que quelqu'un d'autre (asso osm-fr par exemple) puisse prendre 
en charge.

Pour ce qui est de la suite, je pense que c'est la réalisation qu'il faudrait 
entamer, et plutôt que dans le vent, appliqué à un besoin réél. Mais là, 
j'entrevois pas mal de boulot...


-- 
sly
qui suis-je : http://sly.letuffe.org
email perso : sylvain chez letuffe un point org

___
dev-fr mailing list
dev-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev-fr

Re: [OSM-dev-fr] Réflexion autour des fichiers diff OSM

[sly (sylvain letuffe)]

Le mardi 07 août 2012 23:26:05, Christian Quest a écrit :
> Je vous propose une réflexion commune autour des fichiers diff d'OSM.

Intéressante réflexion.

> Cela fait déjà quelques temps que je pense que ceux-ci sont de moins
> en moins adaptés à l'usage qu'on 

Il faudrait définir ce "on" et ce "usage". D'après ce que je lis après, tu 
semble surtout penser à une base osm2pgsql qui est celle à ma connaissance qui 
reconstruit le plus de géométries (surtout quand elle s'occupe des relations).
Bien d'autres import vont soit créer des géométries d'une manière différente 
(osmosis ne construit rien à partir des relations, sauf erreur, et le 
constructeur de ways n'est qu'un plugin), soit ne pas s'intéresser à la 
majorité des géométries (overpass par exemple il me semble)

J'ai donc envie de penser de prim abord : laissons les diffs d'osm tels qu'ils 
sont pour être les plus générique possibles (format .osc) et, ensuite, 
pourquoi pas, mettre en oeuvre des services qui mange ces diffs pour les re-
cracher dans un format destiné à un besoin récurrent.

Jocelyn et ses diffs france (fait ?) faisait exactement ça, manger des diffs 
internationaux pour en resortir des diffs, certes toujours au même format .osc, 
mais localisés. Donc très utiles pour réduire la charge et maintenir une base 
à couverture géographique limitée.
(de souvenir, ces diffs prenaient ~20 fois moins de temps à manger pour une 
base osm2pgsql)

Une rêve que l'on pourrait avoir, si on se focalise par exemple sur le cas 
osm2pgsql qui est un monstre mangeur d'I/O et cycles CPU, serait par exemple 
un service de génération de fichier sql prévus pour une mise à jour de la base 
osm2pgsql qu'il n'y aurait plus qu'a appliquer au fûr et à mesure que le 
service les génères (gain d'I/O en lecture garanti !)



> en fait car le constat est pour moi
> le suivant: leur intégration pour maintenir une base à jour nécessite
> beaucoup de ressources car ceux-ci ne sont pas "auto-suffisants".

Exact, ce qui interdit d'ailleurs bon nombre d'analyses qui pourraient être 
faite "au fil de l'eau" rien qu'en analysant le diff (sans base et sans 
"y'avait 
quoi avant")

> Inconvénients:
> - ils seront plus volumineux, c'est vrai, mais là aussi je pense que
> le surcroit de bande passante restera plus économique que les
> ressources matérielles nécessaires actuellement à la simple mise à
> jour d'une base osmosis ou osm2pgsql. 

A vérifier, une modif d'un noeud sur la relation France et si tu veux 
transmettre sa géométrie ça va chercher dans les ~15Mo (format WKT)

J'y vois aussi un autre inconvénient : (rien n'est insurmontable) il faut 
arriver à être d'accord sur ce que doit être une géométrie si tu veux 
transmettre quelque chose d'assez générique pour tous les usages
un polygone de forêt qui ne ferme pas : quelle géométrie ?


-- 
sly (sylvain letuffe)

___
dev-fr mailing list
dev-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev-fr

Re: [OSM-dev-fr] Base de données encodage

[sly (sylvain letuffe)]

Le jeudi 19 juillet 2012 11:18:04, Mikaël Cordon a écrit :
> la console (shell, bash, ksh, etc…) elle-même qui exécute le
> client qui peut éventuellement être dans un codage différent et/ou
> effectuer des transcodages…

Attention à ne pas confondre shell et "console"
Ceux que tu cites: bash, ksh, sh, ... sont des shells
La console, c'est le logiciel ou même le matériel qui offre la visualisation de 
ce que fait le shell. Et lui aussi dispose d'une interpretation des caractères 
envoyés qu'il faut vérifier.

(konsole sous kde, gnome-terminal sous gnome, "terminal" sous OS X, minitel 
sur port série, "pseudo terminaux" linux ctrl+alt+F1->F9, etc.) 


-- 
sly (sylvain letuffe)

___
dev-fr mailing list
dev-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev-fr