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] Munitely updated regional osm2pgsql database

[sly (sylvain letuffe)]

On mercredi 2 juillet 2014, Ilya Zverev wrote:
 and since diffs are only available for the whole planet

FYI, that isn't true anymore :
http://wiki.openstreetmap.org/wiki/Planet.osm/diffs#Regionally_limited_diffs
Geofabrik is providing daily diffs for any subregion you can imagine
and french association provides minute diffs for several countries, and the 
list can be increased on case by cases along with a real need.

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

Re: [OSM-dev] Munitely updated regional osm2pgsql database

[sly (sylvain letuffe)]

On jeudi 3 juillet 2014, Ilya Zverev wrote:
 If, with comments above, this
 script is still not the best way to have regional minutely updates,
 please point me to an alternative.

I wasn't saying that what you did is or isn't the best way (best beeing 
relative to a need) to have regional diffs, I was just pointing out, for you, 
or for anyone with a need of subregional diffs who might not know, that 
there exists those 2 alternatives I pointed out.

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

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] Notes DB dumps

[sly (sylvain letuffe)]

On mardi 18 février 2014, JB wrote:
 Hello,

Hello,

 If not, where can the note DB be bulk-downloaded for the planet or by 
 country/bbox/poly?

A quick search led me to :
https://github.com/iandees/planet-notes-dump

Which mean than Ian work(ed|s) on such a project, I guess it isn't operational 
yet as a service but maybe he will explain if he needs help with it ?
 
-- 
sly
qui suis-je : http://sly.letuffe.org
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

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] Problem with XAPI and ref based search

[sly (sylvain letuffe)]

Le vendredi 29 novembre 2013 13:41:48, Grégory Bataille a écrit :
 hello everybody,
 
 I have been trying to use OSM data for a while. basically, first, I'd like
 to get the admin boundaries of France.

Do you want to construct a geometry in the end ?
if the answer is yes, we have a more specific WKT or shp geometry construction 
tool located at :
http://polygones.openstreetmap.fr (down at the moment)
supporting generic type=boundary/multipolygon construction into a MULTIPOLYGON 
from a relation made of ways or relation members 
(you have to imput a relation id for it to work)


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

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

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

[sly (sylvain letuffe)]

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

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

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

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


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

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

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

[sly (sylvain letuffe)]

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

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

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

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

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

Re: [OSM-dev] HTTPS on Nominatim

[sly (sylvain letuffe)]

Le mercredi 13 novembre 2013 18:56:53, François Lacombe a écrit :
 Hi,

Hi,
 
 I've got some issues to use it on a https webpage displaying Leaflet
 GeoSearch plugin since all well known browsers are blocking http content on
 https websites.

(...)

 Many thank for any tip.

You could set up a http proxy local to your hosting. 

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

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

[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] Tile server

[sly (sylvain letuffe)]

On vendredi 21 juin 2013, Lynn W. Deffenbaugh (Mr) wrote:
 18GB for the planet and my postgresql database is about 260GB after 
 importing the planet into it.  Add space for rendered tiles, and it's 
 pretty demanding.
 
 If you've only got a single magnetic spindle for the 500GB, you might 
 find it hard to keep up with the updates.  I ended up migrating from a 3 
 spindle magnetic RAID to a pair of SSDs, one for the rendering tables 
 and the other for the import tables.  I'm looking into which tables to 
 put on which to try to make both busy instead of just one when rendering.

You should consider a RAID0 array at OS level, that should help improve speed 
while still beeing simple software side.


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

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

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

[sly (sylvain letuffe)]

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

Ok, merci pour l'info.

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

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

~8Go de non partagé* !

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

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

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

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

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

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

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


-- 
sly (sylvain letuffe)

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

Re: [OSM-dev] xapi site?

[sly (sylvain letuffe)]

Le jeudi 30 mai 2013 20:27:43, Tac Tacelosky a écrit :
 As our
 streetview software moves closer to being demonstrable, I'd like to
 not use the live API as much.

You are currently quering the 0.6 API at api.openstreetmap.org ? If yes, you 
can easily alleviate the load until you have a working alternative with xapi 
or overpass API by replacing api.openstreetmap.org by api.openstreetmap.fr

http://wiki.openstreetmap.org/wiki/Servers/api.openstreetmap.fr


-- 
sly (sylvain letuffe)

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

Re: [OSM-dev] xapi site?

[sly (sylvain letuffe)]

Le jeudi 30 mai 2013 23:33:29, Tac Tacelosky a écrit :

 I've read and re-read the api docs at
 http://wiki.openstreetmap.org/wiki/API_v0.6, and XAPI and wherever
 else I could find, and hadn't seen any references to this site.  

I guess I'll have to improve my advertising skills ;-) 
The server it runs on still has power left and is meant to be used by whoever 
needs it.

I might not have pushed too much on advertising at first since I wanted to 
give it time to correct bugs, but after 1.5 years, I consider it quite 
reliable (Well, apart from software updates requiring database re-import, but 
my todo list contains an automatic fail-over function I've been delaying a bit 
too much...)

 originally I was getting all the data within the
 bounding box of the segment, using the Overpass API.  But that meant
 the data was always cached

I'm unsure about what cache you are talking about, but the 3 public Overpass 
API instances I know about 
(http://wiki.openstreetmap.org/wiki/Overpass_API#Introduction) are behaving 
just about the same about cache and are constantly minutely updated, so if you 
keep receiving the same data even after an update in the bbox I feel that even 
using the fr instance won't change your problem...


-- 
sly (sylvain letuffe)

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

Re: [OSM-dev] announcing a new mailinglist tile-serving

[sly (sylvain letuffe)]

On jeudi 28 mars 2013, Simone Cortesi wrote:
 On Thu, Mar 28, 2013 at 5:52 PM, Kai Krueger kakrue...@gmail.com wrote:
  Renderd can do that just fine as well. Currently there is a hard coded
 limit
  of 10 in the source code of renderd, but that would be easy enough to
  change.
 
 can you point me at some docs about this? About rendering two different
 tilesets.

No one is willing to move that discussion to the new born tile-serving list ?

Here follow my sample config file for renderd.conf with the first 3 styles 
configured in (we move the hard coded limit to 100 and are happily serving 25 
different tile sets based on the same osm2pgsql schema database.

The problem, if any, is more at the expiry of tiles depending on your expire 
strategy

[renderd]
stats_file=/var/run/renderd/renderd.stats
socketname=/var/run/renderd/renderd.sock
num_threads=8

#Merci de garder cette ligne, mais si ça ne marche pas pour renderd car je 
m'en sers ailleurs pour trouver le chemin des tuiles -- sly
tile_dir=/var/lib/mod_tile/ ; DOES NOT WORK YET

[mapnik]
plugins_dir=/usr/lib/mapnik/input
font_dir=/usr/share/fonts/truetype/
font_dir_recurse=true

[noname]
URI=/noname/
XML=/data/project/layers.openstreetmap.fr/mapnik-styles/noname.xml
HOST=layers.openstreetmap.fr

[nooneway]
URI=/nooneway/
XML=/data/project/layers.openstreetmap.fr/mapnik-styles/nooneway.xml
HOST=layers.openstreetmap.fr

[noref]
URI=/noref/
XML=/data/project/layers.openstreetmap.fr/mapnik-styles/noref.xml
HOST=layers.openstreetmap.fr



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

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

[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] Call for A Proper Area Datatype for OSM

[sly (sylvain letuffe)]

Le dimanche 10 février 2013 21:31:28, Jochen Topf a écrit :

 Actually the transition is the easy part. 

I am uneasy with your use of the work easy ! What will be the harder part !

Just add support in every editors, most data consumer tools and export/api 
side, update the api so you don't download all coastlines at once, run a 
script for converting while keeping history intact, still allowing reverts is 
what you would call easy ? I admire your enthusiasm ;-)

Maybe I would call it the maybe easier part ;-)

Still, your blog entry is a really good introduction to problems anticipation, 
I just find it really optimistic, and I would bet that the discussion part 
about what model to choose would be, if not faster, at least much less risky 
for the contributors discovering their version of software X suddenly broke 
without warning...


-- 
sly (sylvain letuffe)

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

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

[OSM-dev] Planet file date unclear at planet.osm.org

[sly (sylvain letuffe)]

Hi,

For those who use the planet from planet.osm.org and apply diffs afterward, 
pay attention to the generation date of the planet.

Here :
http://planet.osm.org/planet/

It says latest with a file generation date of 05-Jan-2013 05:08 but it isn't 
exactly clear when is the latest object in that file (or if there is, I'm not 
aware of the trick)

To check the date of the latest object (beside parsing the whole file) you can 
go to  http://planet.osm.org/planet/2013/ and check the file's name date, then 
take some margin *before* to take your diff import sequence number.

ps: on a side note, I heard there was ongoing work to provide a file's 
timestamp in the pbf file itselft, is that operationnal ? or planned to be ?

-- 
sly (sylvain letuffe)

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

Re: [OSM-dev] Planet file date unclear at planet.osm.org

[sly (sylvain letuffe)]

Le vendredi 11 janvier 2013 14:57:59, Toby Murray a écrit :

 But the osm.bz2 file has the timestamp that you need inside of it in
 the second line. No need to parse the whole file.
 
 bzcat planet-130102.osm.bz2 | head -n 2
 ?xml version=1.0 encoding=UTF-8?
 osm version=0.6 [license, etc]  timestamp=2013-01-02T01:10:14Z

That is indeed a very usefull trick to know.
Thanks.
I'll update http://wiki.openstreetmap.org/wiki/Planet


-- 
sly (sylvain letuffe)

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

Re: [OSM-dev] Planet file date unclear at planet.osm.org

[sly (sylvain letuffe)]

Le vendredi 11 janvier 2013 15:33:10, Peter Körner a écrit :
 Am 11.01.2013 15:17, schrieb sly (sylvain letuffe):
  bzcat planet-130102.osm.bz2 | head -n 2
 
 Or without downloading the whole file:
 
 curl http://planet.openstreetmap.org/planet/planet-latest.osm.bz2 |
 bzcat | head -n 2

Sure ;-)

Don't worry... I wasn't going to download 25GB of data to get 20 usefull bytes 
;-)

I wasn't clear by using the word trick, the shell trick itself is known to 
me, what wasn't, is the fact this information was there, waiting for me to 
just read it.

Some (many ?) other osm file provider don't actually provide that information 
and I haven't bothered to look at every .osm file around.



-- 
sly (sylvain letuffe)

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

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

Re: [OSM-dev] production site disk use question

[sly (sylvain letuffe)]

Le lundi 31 décembre 2012 18:25:28, Jeff Meyer a écrit :
 Are there any rules of thumb about Postgres disk requirements when
 importing osm data?

Here is a table referencing disk size use by different osm database schema :
http://wiki.openstreetmap.org/wiki/FR:Servers/Comparatif_des_formats_de_base_de_donn%C3%A9es#Comparatif

osmosis schema takes 500Go of disk space for the planet file of 2012-09-15
-- 
sly (sylvain letuffe)

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

[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] How to make osm2pgsql quiet?

[sly (sylvain letuffe)]

On mercredi 19 décembre 2012, Svavar Kjarrval wrote:
 Hi.

Hi,
 I also tried to stick '
 /dev/null' and ' /dev/null 21' at the end of the osm2pgsql command
 within the shellscript with no effect.

This works for me, I suggest you check again for syntax errors, 
And try :
* * * * * /path/to/osm2pgqsl -blabla  /dev/null 2 /dev/null
or
* * * * * /path/to/wrapper-script.sh  /dev/null 2 /dev/null

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

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

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] osm2pgsql multipolygon with several outer ways - postgis MULTI?

[sly (sylvain letuffe)]

Le mercredi 21 novembre 2012 12:26:09, Per Eric Rosén a écrit :
 Hi!
 
 Can osm2pgsql import multipolygons with several outer ways to a single
 postgis multipolygon? 
(...)
 Is this the way it's supposed to be?
 I'm fine if that's the case, just good to know.

Are you using the osm2pgsql -G switch ?

-- 
sly (sylvain letuffe)

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

Re: [OSM-dev] Status of the Mapnik stylesheets

[sly (sylvain letuffe)]

Le mercredi 14 novembre 2012 17:34:17, Eugene Alvin Villar a écrit :
 Actually we do, and that's the data layer. Unfortunately, I think there's a
 perception that the data layer doesn't provide the gratification that
 mappers want. Or maybe we just need to highlight this layer more.

IMHO Your forgot an important feature mappers want :
Have I done a mistake or not ?

Even if we keep on telling them : don't map for the renderer (in the new 
sense it has become) they still want to know if what they've done is correct 
(correct in a non so obvious sense where answers is it in the wiki It's 
always correct because you can tag how you want are not what they expect)

+the data layers isn't available as a JOSM slippy map selector (and the plugin 
download as you pan and zoom isn't as functional because it can hardly work 
on low zooms)

-- 
sly (sylvain letuffe)

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

Re: [OSM-dev] Status of the Mapnik stylesheets

[sly (sylvain letuffe)]

Le mardi 13 novembre 2012 23:25:44, Paweł Paprota a écrit :
 On 11/13/2012 11:13 PM, Derick Rethans wrote:
  I would rather see as much useful things rendered that make sense for
  *mappers*. Pretty tiles should also be made, but as far as I know, the
  default style that is on openstreetmap.org is for *us* - the people who
  add data.
 
 Well, that's the usual question about what is osm.org supposed to be.

I share Derick's view, but maybe what we need is someone to just do it and 
split the problem in two maps.

http://wiki.openstreetmap.org/wiki/Contributors_functionalities_wishlist#Backgound_map_with_the_most_possible_objects
-- 
sly (sylvain letuffe)

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

Re: [OSM-dev] 404 from Apache2/mod_tile

[sly (sylvain letuffe)]

I would like the server to answer in these 3 seconds, but with
the tiles and HTTP 200 and not with an 404.

I tried several settings, such as

ModTileRequestTimeout 500
ModTileMissingRequestTimeout 500
ModTileMaxLoadMissing 50

but still the same 404. Is there a possibility for find out why
mod_tile return a 404, which timeout it runs into?

I'm using mod_tile from not so long ago and all those values
are taken into account fine.
To troubleshoot, check your are using the notice log severity and logs go to 
error.log (but I'm unsure if you'll get what you want)
next thing might code hacking/debuging...

ps:just in case : did your stop and then start apache ?
-- 
sly
-- 
sly
-- 
sly___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev

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] Minutely changeset feed

[sly (sylvain letuffe)]

Hi,

Le mercredi 07 novembre 2012 17:15:10, Matt Amos a écrit :
(...)

Is there any plan to provide something like augmented changeset diff ?
(ie : diffs with the content of the changeset in osmchange format when closed 
in addition to the changeset itself )

-- 
sly (sylvain letuffe)

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

Re: [OSM-dev] making osm2pgsql import relations?

[sly (sylvain letuffe)]

Le mercredi 07 novembre 2012 21:34:47, Ákos Maróy a écrit :

 Is there a simple way to have osm2pgsql import relations described in an
 OSM XML file?

Yes : To do nothing special.

Which mean, there is a problem somewhere.
Can you provide your osm2pgsql command line, style file and a simple xml test 
case to show the problem ?

-- 
sly (sylvain letuffe)

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

Re: [OSM-dev] making osm2pgsql import relations?

[sly (sylvain letuffe)]

Le mercredi 07 novembre 2012 21:59:26, Ákos Maróy a écrit :
 sure, here is the style file:
 
 http://code.google.com/p/openaviationmap/source/browse/trunk/rendering/oam.
 style

looks good
 
 the OSM XML file can be downloaded from here:
 http://files.openaviationmap.org/dump.osm

osm2pgsql only uses it's multipolygon building ability when relations have a 
tag type with value multipolygon or boundary (unless patched)

relation n°25 for exemple hasn't. However, I'm unsure if it should or shound't 
end in the _rels table anyway.
But in the end, you won't have it in _polygon wich mean you probably won't get 
what you want : the geometry


 this is the command line I use for the import:
 
 osm2pgsql -d oam --bbox 16,45,23,49 -s -C 2048 --hstore-all -K -v -G -v
 -m -S oam.style dump.osm

Looks good (beside one extra -v)

-- 
sly (sylvain letuffe)

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

Re: [OSM-dev] making osm2pgsql import relations?

[sly (sylvain letuffe)]

Le mercredi 07 novembre 2012 22:20:31, Ákos Maróy a écrit :
 it hasn't on purpose. the relations I use are not used to stitch
 together polygons. they are relations in the traditional sense: they
 collect various data about the same thing

You mean categories ? ;-)

 , in this case, an airport. the
 related data is a range of lines (runways), points (navigation aids) and
 other stuff, like the 'airport reference point', etc.

Well, then, osm2pgsql might not be your best option. You might end having 
other problems than just get the relation in _rels
(like connecting the relation to it's members SQL in queries)

 see above, the geometries are imported fine, 

Yes, but not the one linked to the relation, but to it's ways members (check 
the osm_id)

 I do have the points and
 the lines imported that are related to these airports. what I don't
 have, but would want to have, is the relation itself in PostGIS

I ran a test and I can confirm as well that without type tag, the relation 
isn't imported into _rels
However, whatever the value is like type=toto is enough so that the relation 
makes it's way to the _rels table, but not to the _polygon table.



-- 
sly (sylvain letuffe)

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

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

[sly (sylvain letuffe)]

Le jeudi 18 octobre 2012 22:41:26, Alex Barth a écrit :
 On Oct 12, 2012, at 1:14 PM, Michal Migurski m...@teczno.com wrote:
  * Create a new map style intended to be the default face of OSM, but
  leave the current OSM.orgMapnik style as-is. It works beautifully as an
  editor's basemap due to the dense inclusion of all data. Keep it, but
  add a new one that's for non-editors to look at.
 
 I wonder how good the current Mapnik style is for editors.

By mapnik I asume you are refering to the standard map at osm.org
IMHO : it is not good enough for editing purpose.
see 
http://wiki.openstreetmap.org/wiki/Contributors_functionalities_wishlist#Backgound_map_with_the_most_possible_objects

 the problem is that the Mapnik style completely ignores `surface=unpaved` 
 making a significant dirt road really not look how it should on the map.

Arguably, the standard map might or might not show that information if we see 
it as a general purpose map.
But as an editing purpose map like, it would be a great addition. But 
several other features also would :
place=isolated_dwelling
sac_scale=*
or
trail_visibility=*
comes to by mind, but it could be extended to any approved feature in the wiki 
or at least any approved with a certain threshold of uses.



-- 
sly (sylvain letuffe)

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

Re: [OSM-dev] OSM Wishlist (community wishlist built experimentation)

[sly (sylvain letuffe)]

On jeudi 18 octobre 2012, Paweł Paprota wrote:
 It's great that you are driving this. One potential use of such list 
 would be defining the Top Ten Tasks list. 
A list with that name allready exists, therefore I don't want to say that this 
list would define the TTT
However, any admin is of course welcome to feed a part of the TTT with idea 
from that new list.
Hi Pawel,

 * From my experience form of presentation matters when trying to explain 
 complex things to people. Right now there is a lenghty first paragraph, 
 there is no Table of Contents. 

I do admit the first paragraph is huge, but it serves the purpose of scaring 
away un-serious people.
And I find the wiki Table of content format problematic in such case, see :
http://wiki.openstreetmap.org/wiki/API_v0.7
You first read At this point, we're brainstorming new/changing features for 
API version 0.7.
and then you jump to real ideas, forgeting to read the Brainstorming 
importante part.
But why not trying after all, that shouldn't be a big deal.

 Of course there is always the question if we really care about people 
 who have so short attention span that they can't get through a large 
 chunk of text but that's another discussion...

That the people I want to contribute ;-)
 
 * Similar to above point - page title. I would suggest something that 
 rolls off the tongue 
Does a page named TTT has better audience than one named CFW ?
I don't know, and don't really care as long as the title express what it is, 
but if someone finds a title fullfeeling both objectiv, I'll be glad to 
change !

 Perhaps something like Community wishlist or 
 similar?
I've been thinking about that, and, well, why not. The 1st sentence should 
clear the fact it is not about distributing T-Shirts to mappers

 Ironically, none other than the Top Ten Tasks list has a good example of 
 this, see template:
 
 http://wiki.openstreetmap.org/wiki/Template:TopTenTask

Complex..., I don't want to attract wiki experts but contributors.
 
 I would think about making similar template but more community-focused 
 so no technology list but something more useful to non-developers.

Unless if you come with something nice ? (I'm a wiki noob and hate spending 
time to understand complex templates items)

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

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

Re: [OSM-dev] OSM Wishlist (community wishlist built experimentation)

[sly (sylvain letuffe)]

On jeudi 18 octobre 2012, Kai Krueger wrote:
 I would suggest putting it on help.openstreetmap.org rather than on the 
 wiki. 

For sure, a wiki for voting purpose is to be classified as one of the worst 
tool to do it, but it was easy to copy the first wishes from the same syntax.

Using help even if better suited as a tool, would be a terrible abuse of the 
help.openstreetmap.org instance.

And in the end, we need a bit of freedom to modify things all around without 
pain about users rights.

I'll switch if that goes out of control

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

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

Re: [OSM-dev] OSM Wishlist (community wishlist built experimentation)

[sly (sylvain letuffe)]

Le mardi 16 octobre 2012 14:29:08, Paweł Paprota a écrit :
 I think this would be A LOT of work and probably not for only one person
 but I for one would love to see end-users more involved during
 development phase - testing, feedback, incremental improvements and all
 that.
 
 So the question for me is - who would be interested in doing such
 work...

I do, but as you said, alone isn't gone be an easy task, that's why I'll soon 
be proposing this on talk, with the hope to get the help of everyone. I have 
just no ideas if something usefull could get out of this, if that won't just 
turn to chaos, but I guess I'll have to try to find out.

As a starting point, I have cleaned-up 
http://wiki.openstreetmap.org/wiki/API_v0.7 into what I consider ideas for 
development ranging from good to improvable with a good idea behind.
I've also turned it into less technical and, hopefully, understandable to long 
standing non-dev mappers.

However, it is not limited anymore to what people think should go into the 
next API 0.7 version (I think it's even worse when you ask non-techies people 
to find a solution themself) but to something gathering ideas of wishes they 
find usefull for their work as mappers, what they miss more while editing (may 
it be external tools, websites, software or, of course API improvements).

here it is, self-explained :
http://wiki.openstreetmap.org/wiki/Contributors_functionalities_wishlist

If anyone here wants to give feedbacks before it goes to talk, please do.

-- 
sly (sylvain letuffe)

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

Re: [OSM-dev] multipolygon relation and non-closed ways

[sly (sylvain letuffe)]

hi,

 Perhaps a useless idea from my side. I would also like to hire you for an
 hour or two for quick reading some other OGC specifications for me.

I'm far from an expert for that ;-)
Perhaps you mean that the OSM wiki page I've created should be made more 
explicit for developers (or another page more technically oriented) about 
this OGC simple feature standard ?
 
 I tried ST_MakeValid and it seems to be able to convert also the two
 touching inner ring case into a valid simple feature
(...)
 GEOMETRYCOLLECTION(POLYGON((-139 420,71 418,59 273,-156 272,-139
 420),(-46 312,-5 314,-4 371,-46 370,-89 370,-92 313,-46
 312)),LINESTRING(-46 312,-46 370))

The fact that you end with a GEOMETRYCOLLECTION (with a LINESTRING) and not a 
MULTIPOLYGON after ST_MakeValid express the fact that the touching inner case 
isn't valid for OGC. But it has always been accepted as the OSM exception to 
the standard, because it would be more complex for mappers to do it in 
compliance with OGC standard.

 Perhaps examples B and F could also contain at least two ways? If there is
 only one way, why to make a multipolygon relation at all? 

You are right, both B and F (and 3 and 5) could and should be tagged as a 
simple closed way without relation at all. But my polygon(s) validity page 
could also be extended to non-relation polygons as well.
3 and 5, even if tagged without relation should (that's my opinion) still be 
considered invalid geometries.

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

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

Re: [OSM-dev] multipolygon relation and non-closed ways

[sly (sylvain letuffe)]

 And something else: Somebody recently started a collection of mp testcases
 and put it in a github repository. I forgot where that was but maybe
 somebody 
 can dig that up and join in that work.

That would be interesting to include this to my wiki page to display real 
example cases in the .osm format for developers.
Any clues where we can find those mp testcases ?


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

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

Re: [OSM-dev] OSM Wishlist

[sly (sylvain letuffe)]

On vendredi 12 octobre 2012, Tom MacWright wrote:
 Hey all (or, well, those subscribed to dev@ - my flamewar shields are at
 50% so I'm not risking an email to talk),

This only is my opinion, but wishlists shouldn't be reduced to those 
subscribed to dev@
Maybe start on dev, but I think a wiki page should better be suited for a 
summary of the ~3/5 tasks to focus on.

 What do you want to see happen with OSM's software this year? 
So many things on my side that I don't see how we can decide this on a mailing 
list in one thread.
Better list, then short list, then vote (or kind of) and focus on few tasks.

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

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