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)]

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 

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) lis...@letuffe.org 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 vincent.fri...@gmail.com 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

-- 
sly (sylvain letuffe)
http

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 vincent.fri...@gmail.com 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 vincent.fri...@gmail.com 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)]

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 :
?xml version='1.0' encoding='UTF-8'?
osm version='0.6' upload='true' generator='JOSM'
  bounds minlat='48.8268704' minlon='2.316227' maxlat='48.8773608' 
maxlon='2.4180222' origin='OpenStreetMap server' /


 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 cqu...@openstreetmap.fr 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 cqu...@openstreetmap.fr 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 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] [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 cqu...@openstreetmap.fr
  À : dev-fr@openstreetmap.org  Discussions développeur OSM en français
 dev-fr@openstreetmap.org 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 rodol...@quiedeville.org 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 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 

?xml version=1.0 encoding=UTF-8?  

 
osm license=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   


 bound box=-90,-180,90,180 origin=http://www.openstreetmap.org/api/0.6/   

 
 changeset id=1 created_at=2005-04-09T19:54:13Z 
closed_at=2005-04-09T20:54:39Z open=false user=Steve uid=1 
min_lat=51.5288506 min_lon=-0.1465242 max_lat=51.5288620 
max_lon=-0.1464925 num_changes=2/
 changeset id=2 created_at=2005-04-17T14:45:48Z 
closed_at=2005-04-17T15:51:14Z open=false user=nickw uid=94 
min_lat=51.0025063 min_lon=-1.0052705 max_lat=51.0047760 
max_lon=-0.9943439 num_changes=11/
 changeset id=3 created_at=2005-04-17T19:32:55Z 
closed_at=2005-04-17T20:33:51Z open=false user=nickw uid=94 
min_lat=51.5326805 min_lon=-0.1566335 max_lat=51.5333176 
max_lon=-0.1541054 num_changes=7/
 changeset id=4 created_at=2005-04-18T15:12:25Z 
closed_at=2005-04-18T16:12:45Z open=false user=sxpert uid=143 
min_lat=51.5248871 min_lon=-0.1485492 max_lat=51.5289383 
max_lon=-0.1413791 num_changes=5/
 changeset id=5 created_at=2005-04-19T22:06:51Z 
closed_at=2005-04-19T23:10:02Z open=false user=nickw uid=94 
min_lat=51.5266800 min_lon=-0.1418076 max_lat=51.5291901 
max_lon=-0.1411505 num_changes=3/
 changeset id=6 created_at=2005-04-24T15:42:15Z 
closed_at=2005-04-24T16:45:46Z open=false min_lat=51.5261841 
min_lon=-0.1550623 max_lat=51.5300598 max_lon=-0.1453212 
num_changes=10/
 changeset id=7 created_at=2005-04-26T09:28:29Z 
closed_at=2005-04-26T10:28:29Z open=false user=Steve uid=1 
min_lat=51.5264130 min_lon=-0.1539768 max_lat=51.5264130 
max_lon=-0.1539768 num_changes=1/


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] 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] 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] 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 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] 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] 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 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) lis...@letuffe.org 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, Ab_fab wrote:
 hierhttp://suivi.openstreetmap.fr/longeur-cours-eau-france/comparaison-
 sandre.htmllaisse
 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 pier...@gmail.com 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=5lat=48.08543lon=12.71091layers=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] [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] 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] 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] 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] 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] 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] 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 cqu...@openstreetmap.fr
 À : Discussions développeur OSM en français dev-fr@openstreetmap.org 
 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 gamma@gmail.com 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 fred.rodr...@gmail.com a 
écrit :
 
 
 
 
 
 
 Le 29 novembre 2013 10:19, Ab_fab gamma@gmail.com 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] 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

[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] 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] 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)
 
 query type=node
 area-query ref=3600106558/
 /query
 print mode=meta/

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
union
  area-query ref=3600106558/
  recurse type=node-relation into=rels/
  recurse type=node-way/
  recurse type=way-relation/
/union
print mode=meta/

J'ai trouvé cette variante :
union
  area-query ref=3600106558/
recurse type=up/
recurse type=down/
/union
print mode=meta/

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] 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] 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

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)]

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

[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] 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 http://trac.openstreetmap.fr/ticket/210,

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)]

(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 cqu...@openstreetmap.fr 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] [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=!closedcomponent=api-fr
-- 
sly (sylvain letuffe)

___
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 +units=m +nadgrids=@null +wktext 

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.

presque hs
 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
/presque hs

 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

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] [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 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, 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, 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 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] 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=newstatus=assignedstatus=reopenedcomponent=nominatimorder=iddesc=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
 olivierbenneg...@gmail.com 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'
 
  searchresults timestamp=Thu, 13 Dec 12 15:07:46 +0100 attribution=Data 
©
  OpenStreetMap contributors, ODbL 1.0.
  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=xmlexclude_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,211642accept-language=fr,fr-fr;q=0.8,en-us;q=0.5,en;q=0.3viewbox=4.88%2C45.79%2C4.89%2C45.77q=139+avenue+roger+salengro+villeurbanne;place
  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 place_id=230349 osm_type=way osm_id=5079011
  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
  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
  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 place_id=211643 osm_type=way osm_id=186871478
  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//searchresults
 
  Exemple de la même adresse avec code postale au format xml: '139 avenue
  roger salengro 69100 villeurbanne'
 
  searchresults timestamp=Thu, 13 Dec 12 15:08:40 +0100 attribution=Data 
©
  OpenStreetMap contributors, ODbL 1.0.
  http://www.openstreetmap.org/copyright; querystring=139 avenue roger
  salengro 69100 villeurbanne polygon=false
  
more_url=http://10.133.110.51/search?format=xmlexclude_place_ids=accept-language=fr,fr-fr;q=0.8,en-us;q=0.5,en;q=0.3viewbox=4.88%2C45.79%2C4.89%2C45.77q=139+avenue+roger+salengro+69100+villeurbanne;
  /searchresults
 
  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 

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] 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 clement.ste...@diwi.org 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

[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)]

 +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)]

 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)]

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:21:31, Arnaud Vandecasteele a écrit :
 Salut Jean-Claude,
 
 Tu avais raison.

Et je pense aussi qu'il a même encore un peu plus raison que ça !

 Cela commenc à s'améliorer.
 Ma console était initiallement en
 LANG=fr_FR
 LANGUAGE=fr_FR

ça, ce ne sont pas les paramètres de ta console, mais ceux des locales du 
shell distant (ou local d'ailleurs).

Tu as encore un autre endroit où se gère l'affichage de ce que tu vois.

Ton poste client est sous linux ? sous windows ? 
Tu lances une session ssh ? par putty ? par un shell local ?

C'est par là qu'il faut creuser à mon avis.
putty dispose d'un réglage, si tu utilises konsole, pareil, pour le terminal 
de gnome, je ne sais pas. Donc ça va dépendre de ton cas

-- 
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

Re: [OSM-dev-fr] Travailler sur des imports partiels

[sly (sylvain letuffe)]

On mercredi 4 juillet 2012, Philippe DAVID wrote:
 Ok merci,
 il me reste à trouver 1To :)

Suite à la remarque de pieren, je viens de re-vérifier la taille sur disque 
avec la fonction SQL : pg_total_relation_size de la base monde (format 
osm2pgsql) à laquelle j'ai accès et je trouve 318 Go

On dirait donc que mon estimation était foireuse (il y avait d'autres tables 
en fait)

En effet donc, sur deux SSD de 256Go ça doit tenir avec marge

-- 
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] Travailler sur des imports partiels

[sly (sylvain letuffe)]

On jeudi 5 juillet 2012, Philippe DAVID wrote:
 Donc sans les tables nominatim (placex, etc..) c'est ça ?

C'est le décompte des tables+indexes correspondants :
planet_osm_(line/nodes/point/polygon/rels/roads/ways)

N'ayant jamais essayé nominatim, je suis bien en peine de donner ce que 
rajoute, ou retranche un import prévu nominatim, j'aurais donc tendance à 
écouter le wiki, sauf que la remarque de pieren indiquant que 512Go de SSD 
suffisent (sur le serveur poldi) semble en contradiction avec le wiki de 
nominatim.
L'explication peut peut être provenir de l'existence de tables temporaires 
durant l'import ? 

-- 
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] Travailler sur des imports partiels

[sly (sylvain letuffe)]

 Une base osm2pgsql en mode gazetter est plus petite qu'une base dite
 osm2pgsql. Mais je ne sais pas dire quel est le rapport entre les
 deux.

D'après le mail de F. Ramm, ça ne semble plus être le cas, c'est à dire que la 
base nécessaire à un nominatim récent, c'est à dire une version forké du 
osm2pgsql utilisé avec mapnik, semble avoir maintenant une taille plus 
importante.


-- 
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] xapiviewer

[sly (sylvain letuffe)]

 Merci pour les détails. Je viens de tester les autres, et le .de reste le
 plus  
 réactif que le .ru et le .fr. Donc tant que ça marche, je reste comme ça :-)

C'est très intéressant ce que tu nous dis là (désolé je squate la 
conversation)
alors que l'instance sur le .de est une machine largement moins puissante que 
les 2 autres, tu le trouves plus rapide !
Je crois savoir que l'instance du .de dispose de la toute dernière version 
d'overpass, alors que les 2 autres sont un peu à la traîne (en tout cas pour 
le .fr j'en suis sûr)

ça augure donc de meilleures performances sur la nouvelle version, je vais 
peut-être faire l'effort d'y passer pour celle de api.openstreetmap.fr

Merci pour ce rapport d'information !

-- 
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] Notion des routes payantes dans un flux JSON

[sly (sylvain letuffe)]

On mercredi 4 juillet 2012, Philippe Verdy wrote:
 pasaccordés non lus de
 façon cohérente pour servire de guide

Merci philippe, de me faire autant rire


 , et en mélangeant aussi des 
 affirmations (non délimitées), jusqu'au point où on ne savait pas ce
 qu'il voulait faire et où était sa question. C'était un gros mélange
 de mots où on ne savait pas ce qu'il demandait.

En remplaçant dans ta phrase demandait par disait et me voilà à nouveau 
mort de rire car ça me fait tout de suite penser à quelqu'un qu'on à 
l'habitude de lire sur cette liste. Et ben qu'est-ce qu'on rigole sur ces 
listes !

Ce sujet a dévié vers ce que j'appelerais du b2b

-- 
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] Travailler sur des imports partiels

[sly (sylvain letuffe)]

 Ce dont j'avais peur c'est que le
 problème que j'ai rencontré sur le dump d'une région puisse aussi arriver
 à l'échelle d'un pays. D'après ce que dit le readme de geofabrik dans
 clipbounds, c'est la même méthode utilisée donc ça pourrait aussi arriver.
 Et d'ailleurs c'est arrivé comme disait Frédéric.

Le mieux serait peut-être de re-vérifier, beaucoup ont fait remonter 
l'information à geofabrik et je sais que le polygone utilisé pour découper la 
france a pas mal été changé ces dernières années et peut-être que maintenant, 
si tu télécharges le fichier france.osm tu aura toute la france (métropolitaine 
en tout cas)

 
 Pour résumer, si je souhaite:
 - avoir un nominatim de plusieurs pays
 - avoir toutes les données, quitte à déborder
 - appliquer des diff updates
 
 Est-ce que je peux faire ça pour les pays en questions seulement ? 
 ou c'est
 trop compliqué et il vaut mieux travailler direct sur le monde entier ?

Si tu veux appliquer les diff updates, ça change pas mal de chose car c'est 
l'opération qui nécessite le plus de ressources serveur (i/o principalement).

En clair, si tu as besoin des diffs, il te faut une grosse bécanne, et parti de 
là, importer le monde ne te prendra que 2 jours au max, donc j'ai envie de 
dire, importe le monde directement.

Seul cas : tu utilises des disques de trop petite taille pour contenir une 
base monde et là il va falloir ruser. (Si ton projet et professionnel, essayes 
plutôt de convaincre de te faire payer des gros disques, tu y gagnera 
plusieurs journées qui auraient couté plus que les disques ;-) )



-- 
sly (sylvain letuffe)

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

Re: [OSM-dev-fr] Travailler sur des imports partiels

[sly (sylvain letuffe)]

Le mercredi 04 juillet 2012 22:37:10, Philippe DAVID a écrit :
 Oui alors l'idée c'était de voir si ça pouvait tenir sur des SSD?

Tu as deviné ;-)

Ou plutôt, si les finances consacrées à ce projet permettrait d'acheter le(s) 
ssd qui ferait tenir tout ça.

 Je cite la page Nominatim/Install:
 For a full planet install you will need a minimum of 600GB of hard disk
 space (as of January 2012)

La base monde au format osm2pgsql (pas celui de nominatim qui semble avoir 
divergé un peu) que j'ai sous la main fait ~1To pour donner un ordre d'idée

 On a 12-core machine with 32GB RAM and standard SATA disks, the initial
 import (osm2pgsql) takes around 20 hours and the indexing process another
 250 hours. Only, 8 parallel threads were used for this setup because I/O
 speed was the limiting factor.

whaou 250 heures ! Je ne sais pas quels sont les indexes qu'il prépare pour 
nominatim et ce qu'ils ont de particulier, mais sur la version osm2pgsql 
prévu pour le rendu c'est ~15h d'import et ~15h d'indexation, mais bref, vu 
que ça n'est à faire qu'une fois... (enfin faut bien avoir testé avant sinon 
c'est reparti pour 10j)

 600GB c'est la taille de la db dans postgresql à la fin à votre avis ?
oui

 Sinon sur du SATA ça veut dire 10 jours à monopoliser les disques si je
 comprends bien.
oui (enfin les CPU ne sont pas au repos non plus hein !)

-- 
sly (sylvain letuffe)

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

Re: [OSM-dev-fr] 10 bonnes raisons de passer sous Postgresql 9.1 ?

[sly (sylvain letuffe)]

 pourrais-tu publier ta
 configuration sur la page sus-citée afin que toute la communauté en
 bénéficie ?

Je serais moi aussi très intéressé par une publication de la part de philippe 
d'un protocol experimental précis et des résultats d'une importation avec 
osm2pgsql afin de donner un peu de concret à ses dirs (comparaison RAID/SSD) 
qui semblent pour l'instant juste sortis du chapeau de la légende urbaine et 
du bruit de couloir...

Si cela confirme que les SSD n'apportent rien quand on y met les données de la 
base postgresql crée par osm2pgsql, je re-considérerais certains choix que 
j'ai fais, mais pour l'instant, je vais m'en tenir à mes propres benchmarks 
que j'ai publié sur le wiki, faute de concret dans ce qu'annonce philippe.

-- 
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] Les petits défauts du cache/proxy d'api.openstreetmap.fr

[sly (sylvain letuffe)]

 Cette vision me paraît un peu angéliste, il ne sera jamais possible 
 d'obliger tous les contributeurs français à utiliser l'api osm.fr. 

Je ne pense pas que ce soit ce que christian suggérait, ou alors j'ai mal 
compris.

 Autant avoir des caches sur les tuiles afin de soulager les serveurs de 
 rendus me parait une bonne idée

On en revient à un vieux débat, mais je pense toujors que ça ne sert pas à 
grand chose un cache de tuile qui sont sur osm.org, de nouveaux serveurs de 
tuiles, en revanche, ça oui.

-- 
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] Les petits défauts du cache/proxy d'api.openstreetmap.fr

[sly (sylvain letuffe)]

 Je me permets une proposition pour cette API, pourquoi ne pas la limiter
 au mode lecture seule afin de contourner les soucis de synchro et la
 dédier à des usages de consultations intensifs ? 

Ben parce que l'on ne pourrait plus s'en servir dans JOSM ou merkator qui est 
plus ou moins son seul avantage, vu que pour de la lecture seule, je 
recommande vraiment d'utiliser xapi ou overpass API (qui tourne sur le même 
serveur) et qui fournissent des appels en lecture seule plus riches.

Certes, des gens ont tout de même codé des programmes utilisant l'api 0.6, et 
là, cette api fr peut aussi leur servir, mais je leur suggère plutôt, si 
possible, de migrer vers xapi (dont la syntaxe est similaire)

Donc le but de l'api fr, c'est bien d'accélerer les opérations d'édition dans 
leur phase téléchargement de donnée.
Une autre solution existe, c'est le plugin pour JOSM qui utilise xapi pour 
récupérer les données, et l'api officielle pour écrire les données, mais ce 
plugin est pour l'instant encore limité au seul appel map qui télécharge 
dans une bbox, mais il marche déjà bien (et on peu lui brancher la xapi 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] 10 bonnes raisons de passer sous Postgresql 9.1 ?

[sly (sylvain letuffe)]

Le lundi 18 juin 2012 23:35:34, Lapinos03 a écrit :
 Avé !
 
 Je suis toujours sous pqsql 8.4.11.
 Je me demandais si ça valait vraiment la peine de passer sous la
 dernière version... (vu le temps que ça va prendre de réinstaller la
 base complètement)
 
 Quelqu'un a-t-il 10 bonnes raisons de me convaincre ?

La réponse 0 est : ça dépend
(ben ouais, tu dis pas pour quoi faire)
Je vais donc supposer un usage avec un schéma osm2pgsql pour du rendu

Je me lance pour 10 raisons (en binaire) :

1 : tu n'as rien à y gagner sinon ça te manquerait déjà
10 : tu va perdre plusieurs heures à gérer une ré-importation et comprendre 
que les modules ne s'activent plus de la même façon


-- 
sly (sylvain letuffe)

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

Re: [OSM-dev-fr] Complexité algorithmique Problème insoluble de géométrie

[sly (sylvain letuffe)]

Le mardi 8 mai 2012 16:56:37, Pieren a écrit :
 2012/5/8 sly (sylvain letuffe) li...@letuffe.org:
  (une mini contrainte pourrait par exemple être que le point commun ne
  puisse être qu'au début ou à la fin d'un chemin du MP, ainsi, la
  recherche sera moins longue que passer en revu l'intégratilté des points
  et voir s'il sont membre d'un autre chemin)
 
 Curieux. Je pensais à une contrainte inverse. Si le way s'arrête au
 point d'intersection, la détemrination de la forme du polygone est
 imprévisible.

J'ai griffonné sur papier un bon moment, mais je n'ai pas trouvé de cas où cela 
était imprévisible. Tu en vois un ?

Par contre, j'ai imaginé, que si le point de contact se situait au milieu d'un 
way, cela obligerait à parcourir tout les autres point afin de cherche à 
quel(s) autre ways il appartient et voir si plusieurs construction sont 
possibles

-- 
sly (sylvain letuffe)

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

Re: [OSM-dev-fr] Complexité algorithmique Problème insoluble de géométrie

[sly (sylvain letuffe)]

Le mardi 8 mai 2012 17:19:13, Pieren a écrit :
 (imagine 4 ways, 2 par croissant)

En effet, c'est le premier cas bien tordu auquel j'ai pensé (cf ci-joint), et 
je me suis demandé comment deviner que la zone d'intersection de tes deux 
cercles allait pouvoir être considérée comme en dehors alors que tout son 
contour est dans la relation avec un role outer

la réponse est que si l'algo considère cette intersection comme un anneau de 
du MP, alors l'autre anneau qui fait le tour va contenir ce premier anneau, ce 
qui est interdit par la définition MP de l'OGC (un anneau extérieur ne peut 
être contenu dans un autre anneau extérieur, il est alors automatiquement 
considéré comme trou)

 
 Comment savoir si c'est un polygone avec un trou ou deux polygones
 (multipolygone) avec des points commun ?

heu...
c'est pareil non ?

J'accorde qu'on peut y voir 2 représentations OGC, mais finalement c'est la 
même figure (même surface, même périmètre, même forme)
non ?

-- 
sly (sylvain letuffe)


demo3.osm
Description: XML document
___
dev-fr mailing list
dev-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev-fr

Re: [OSM-dev-fr] SOS openstreetmap.fr HS

[sly (sylvain letuffe)]

Le mardi 8 mai 2012 15:56:31, Christian Quest a écrit :
 forum, adherents et trac pointent maintenant vers osm101 au lieu d'osm4

Le forum est à nouveau opérationnel.
Je n'ai pas remarqué de perte de message ou autre, donc j'imagine que les 
sauvegardes étaient assez fraiches.

Beau travail des réparateurs !

Si je peux aider faites moi signe, bien que si j'ai lu correctement, le 
problème qui reste ce sont les listes et là j'y connais rien
-- 
sly (sylvain letuffe)

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

Re: [OSM-dev-fr] [tech] génération de tuiles sur serveur privé

[sly (sylvain letuffe)]

On vendredi 4 mai 2012, David Gros wrote:
 merci pour cette réponse rapide.
 
 Le generate-image.py donne les contours mais aucune données de la base.

generate-image.py est un peu archaïque et ne te parlera pas beaucoup en cas 
d'erreur, je te recommande d'utiliser nik2img.py
http://code.google.com/p/mapnik-utils/wiki/Nik2Img

Voici ma commande de test pour générer la ville de chambéry, à toi d'adapter
./nik2img.py -m style.xml -i png -o image.png -s 1000,1000 -e 
5.9,45.55,5.95,45.59

Ensuite, deuxième étape si ça ne t'aide toujours pas, regarder les logs de 
postgres

 Par contre je viens de vérifier, la génération ce fait correctement, avec
 les données, pour des zooms élevés 16-18. Mais du coup il me reste le
 problème pour les zooms plus faibles 10-16. Est ce que la génération des
 tuiles doit s'effectuer différemment ou manque t-il des informations dans
 la base de données ?

C'est peut être nouveau, mais de mon temps, c'était les même données 
vectorielles utilisées quel que soit le zoom (c'est juste que à zoom faible 
de nombreux éléments n'était pas récupérés pour ne pas alourdir)

 J'en profite pour demander une estimation de la configuration matérielle
 (RAM, taille disque dur, processeur, ...) qu'il faudrait pour un serveur
 avec la carte de la France ?

ça dépend
nombre de visiteurs ? base de donnée à jour ou pas ? quel style pour afficher 
quoi ?


-- 
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] Osm2pgsql schema : renverser planet_osm_rels

[sly (sylvain letuffe)]

J'ai peur que ma réponse puisse tomber tout à fait à coté de la plaque, mais 
histoire que tu te sentes soutenu dans ton problème ;-)



Perso, j'ai un peu peur de cette condition :

  WHERE
  b.osm_id = ANY(planet_osm_rels.parts);

Non pas que je vois une meilleure idée, mais j'ai peur que ça n'utilise aucun 
index et que ça oblige postgresql à la résoudre en séquenciel, et séquenciel, 
ça peut vouloir dire beaucoup


 Celà prend énormément de temps (au moins  1heure), alors que dans ma
 base des pistes de ski je n'ai que 3319 relations et 67235 ways.
 
 Celà ne me semble pas si complexe ??

ça peut faire 3319 * 67235 boucles (sachant que planet_osm_rels.parts c'est 
déjà un tableau à parcourir !)

Tu peux tenter la même requete mais avec un EXPLAIN devant ?
genre :
explain select * from bidule;

ça te donnera le plan de résolution de ta requête (nombre de boucles, 
indexes utilisés, etc.)


-- 
sly (sylvain letuffe)

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

Re: [OSM-dev-fr] Utilisation des diffs pendant la phase de passage à ODBL

[sly (sylvain letuffe)]

Le mardi 10 avril 2012 21:50:13, Jocelyn Jaubert a écrit :
 C'est relancé, et la base osmosis d'osm7 est en train de se mettre à
 jour :)

Idem pour la base osm2pgsql de osm7, merci à toi d'avoir adapté les diffs 
spécial france.

-- 
sly (sylvain letuffe)

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

Re: [OSM-dev-fr] utilisation psql et fichier sql

[sly (sylvain letuffe)]

On lundi 19 mars 2012, didier2020 wrote:

 j'ai enregistré la requete dans un fichier mais quand j'utilise
 psql -d osm -U didier -f monfichier.sql
 j'ai un message erreur : erreur de syntaxe sur ou près de « SELECT »

Tu peux nous faire passer ton fichier monfichier.sql ? 
Peut-être a-t-il été éditer avec un éditeur de texte foireux 

-- 
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] Générer des fichiers SVG par script...

[sly (sylvain letuffe)]

Le lundi 5 mars 2012 17:45:01, Christian Quest a écrit :
 Les solutions de type OSMarender, Mapnik ne sont malheureusement pas
 adaptées pour une réutilisation graphique.

C'est ce que j'avais fais il y a quelques années avec mapnik+cairo pour sortir 
du svg.
L'avantage, ou l'inconvénient (je ne saurais dire) c'est que je pouvais 
appliquer des styles plus dynamiquement (remplissage, bordure, texte, etc.)

Si tu veux te faire une idée, j'avais généré ça :
http://beta.letuffe.org/ressources/cartes/

J'avais aussi les régions et départements il me semble mais je ne sais plus où 
j'ai mis ça.

L'avantage pour moi d'utiliser mapnik c'est que je l'utilisais déjà pour 
générer des bitmap, j'avais donc juste un paramètre à changer pour avoir du 
svg, mais en effet, vu la solution simple que tu semble avoir trouvé, ça semble 
plus rapide

-- 
sly (sylvain letuffe)

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

Re: [OSM-dev-fr] Question noob postgis

[sly (sylvain letuffe)]

Le mercredi 22 février 2012 21:54:48, yvecai a écrit :
 J'ai pris la grande décision de me frotter un peu à postgis, 

Tu ne le regrettera pas !

 mais j'ai
 un peu de mal en sql, alors c'est l'occasion d'animer un peu cette liste.

Ouais ! ça motivera peut-être certains (dont moi ;-) ) à se bouger et à venir 
ici plutôt que d'encombrer talk-fr

 Dans une base 'osm2pgsql', je recherche les relations qui partagent un
 bout de chemin avec, disons la relation 1347356.
 Je n'arrive pas à comprendre comment faire fonctionner les fonctions de
 comparaison.
 
 SELECT a.osm_id, b.osm_id
 FROM planet_osm_line a, planet_osm_line b
 WHERE ST_overlaps(a.way,select b.way where osm_id=-1347356);
 
 ERREUR:  erreur de syntaxe sur ou près de « select »
 LIGNE 3 : WHERE ST_overlaps(a.way,select b.way where osm_id=-1347356);
 
 
 Quelqu'un pour me mettre le pied à l'étrier?

Attention, je ne me veux ni condescendant, ni exaspérant, ni malpoli, c'est 
juste pour adapter mes réponses à ton niveau actuel :

Tu as déjà pratiqué SQL dans un contexte non GIS ou pas encore ?


 WHERE ST_overlaps(a.way,select b.way where osm_id=-1347356);
tu ne peux avoir 2 where la bonne syntaxe, si on remet les ( ) au bon 
endroit est :
where ST_overlaps(a.way,select b.way) and (osm_id=-1347356);


Au delà de la syntaxe que je viens de corriger, il faut maintenant voir si 
chaque champ est bien défini et bien unique
si tu re-tentes ta requête, il devrait te dire osm_id est ambigue car il ne 
sait pas de quel table tu veux a ou b

Donc :

where ST_overlaps(a.way,select b.way) and (b.osm_id=-1347356);

Je sais plus pourquoi, mais je crois que j'utiliserais st_intersects plutôt 
que st_overlaps


Et au cas où tu ne connaisses pas, la bible :
http://www.postgis.org/docs/reference.html


-- 
sly (sylvain letuffe)

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

Re: [OSM-dev-fr] Comparaison cours d'eau OSM/Sandre

[sly (sylvain letuffe)]

On jeudi 16 février 2012, Ab_fab wrote:
 Je ne sais pas trop non plus pour quelles raisons il est jugé nécessaire de
 garder ces anciennes références.

Alors virons les ;-)
et mettons à jour convenablement la base de référence du sandre si eux ne le 
font pas ;-)

 Peut-on virer les lignes suivantes du tableau de suivi ?
(...)

hop, je te laisse regarder le résultat de demain et me dire si tu vois 
toujours un soucis.

 
 *** tentative d'explication ***
 
 J'ai l'impression que le SANDRE référence sous un code unique l'ensemble
 des bras secondaires de gros cours d'eau. Tous les cas se situent dans le
 bassin Loire-Bretagne, soit dit en passant.
(...)
 Pour le cas de la loire, les longueurs dans la base SANDRE sont :
  : 1003.1 km
 0001 :  530.9 km

Si le sandre enregistre de manière séparé les bras, cela peut reposer la 
question du modèle que nous avons choisi pour osm et savoir si on doit ou non 
se rapprocher du sandre pour la modélisation des bras.

Mon avis étant que si le sandre dispose d'une ref spécifique pour certains 
bras, ça me semblerait logique de les tagguer avec cette réf, ce, dans une 
logique de cohérence, mais ce point peut-être débattu.


-- 
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