un shell local ?
C'est par là qu'il faut creuser à mon avis.
putty dispose d'un réglage, si tu utilises konsole, pareil, pour le terminal
de gnome, je ne sais pas. Donc ça va dépendre de ton cas
--
sly (sylvain letuffe)
_
> Une base osm2pgsql en mode gazetter est plus petite qu'une base dite
> osm2pgsql. Mais je ne sais pas dire quel est le rapport entre les
> deux.
D'après le mail de F. Ramm, ça ne semble plus être le cas, c'est à dire que la
base nécessaire à un nominatim récent, c'est à dire une version forké d
On jeudi 5 juillet 2012, Philippe DAVID wrote:
> Donc sans les tables nominatim (placex, etc..) c'est ça ?
C'est le décompte des tables+indexes correspondants :
planet_osm_(line/nodes/point/polygon/rels/roads/ways)
N'ayant jamais essayé nominatim, je suis bien en peine de donner ce que
rajoute,
On mercredi 4 juillet 2012, Philippe DAVID wrote:
> Ok merci,
> il me reste à trouver 1To :)
Suite à la remarque de pieren, je viens de re-vérifier la taille sur disque
avec la fonction SQL : pg_total_relation_size de la base monde (format
osm2pgsql) à laquelle j'ai accès et je trouve 318 Go
On
enfin faut bien avoir testé avant sinon
c'est reparti pour 10j)
> 600GB c'est la taille de la db dans postgresql à la fin à votre avis ?
oui
> Sinon sur du SATA ça veut dire 10 jours à monopoliser les disques si je
> comprends bien.
oui (enfin les CPU ne sont pas au repos non
de et là il va falloir ruser. (Si ton projet et professionnel, essayes
plutôt de convaincre de te faire payer des gros disques, tu y gagnera
plusieurs journées qui auraient couté plus que les disques ;-) )
--
sly (sylvain letuffe)
___
dev-fr mailing list
dev-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev-fr
rne que la france.
Je dis "était" car le serveur qui s'occupait de ce boulot est planté et n'est
pas dispo pour l'instant.
Si cette partie t'intéresse, c'est jocelyn qui peut te renseigner car c'est
lui qui a fait tout le boulot
--
sly (sylvain letuffe)
___
dev-fr mailing list
dev-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev-fr
On mercredi 4 juillet 2012, Philippe Verdy wrote:
> pasaccordés non lus de
> façon cohérente pour servire de guide
Merci philippe, de me faire autant rire
> , et en mélangeant aussi des
> affirmations (non délimitées), jusqu'au point où on ne savait pas ce
> qu'il voulait faire et où était sa q
> Merci pour les détails. Je viens de tester les autres, et le .de reste le
> plus
> réactif que le .ru et le .fr. Donc tant que ça marche, je reste comme ça :-)
C'est très intéressant ce que tu nous dis là (désolé je squate la
conversation)
alors que l'instance sur le .de est une machine large
> Je me permets une proposition pour cette API, pourquoi ne pas la limiter
> au mode lecture seule afin de contourner les soucis de synchro et la
> dédier à des usages de consultations intensifs ?
Ben parce que l'on ne pourrait plus s'en servir dans JOSM ou merkator qui est
plus ou moins son seu
> Cette vision me paraît un peu angéliste, il ne sera jamais possible
> d'obliger tous les contributeurs français à utiliser l'api osm.fr.
Je ne pense pas que ce soit ce que christian suggérait, ou alors j'ai mal
compris.
> Autant avoir des caches sur les tuiles afin de soulager les serveurs d
> pourrais-tu publier ta
> configuration sur la page sus-citée afin que toute la communauté en
> bénéficie ?
Je serais moi aussi très intéressé par une publication de la part de philippe
d'un protocol experimental précis et des résultats d'une importation avec
osm2pgsql afin de donner un peu de
t; Je pense qu'une fois ces deux petits défauts on pourrait proposer à la
> fondation de généraliser son usage dans chaque pays pour décharger les
> serveurs de l'Imperial College.
Pourquoi pas, mais j'ai cru comprendre que tout le monde ne trouvait pas
forcém
On vendredi 22 juin 2012, Lapinos03 wrote:
> Merci pour vos réponses.
>
> En fait, je me demandais surtout si PGSQL v9.1 serait plus rapide que
> v8.4 dans le processus de mise à jour d'une base via osm2pgsql, et lors
> du rendu mapnik.
J'ai rien remarqué de notable, il vaut mieux mettre des di
it déjà
10 : tu va perdre plusieurs heures à gérer une ré-importation et comprendre
que les modules ne s'activent plus de la même façon
--
sly (sylvain letuffe)
___
dev-fr mailing list
dev-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev-fr
Beau travail des réparateurs !
Si je peux aider faites moi signe, bien que si j'ai lu correctement, le
problème qui reste ce sont les listes et là j'y connais rien
--
sly (sylvain letuffe)
___
dev-fr mailing list
dev-fr@openstreetmap.org
ht
lément MP OGC et n'avoir ainsi pas de redondance
des tags
> Ca peut ne pas être un problème, je ne sais pas (pour du rendu, non,
> mais pour des stats ?).
C'est sûr que pour des stats, un algo mal fait va nous répondre qu'il y a 15
France dans le monde ;-)
?
J'accorde qu'on peut y voir 2 représentations OGC, mais finalement c'est la
même figure (même surface, même périmètre, même forme)
non ?
--
sly (sylvain letuffe)
demo3.osm
Description: XML document
___
dev-fr mailing list
dev-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev-fr
Le mardi 8 mai 2012 16:56:37, Pieren a écrit :
> 2012/5/8 sly (sylvain letuffe) :
> > (une mini contrainte pourrait par exemple être que le point commun ne
> > puisse être qu'au début ou à la fin d'un chemin du MP, ainsi, la
> > recherche sera moins longue que pa
ur de
relation arrive toujours à reconstruire les anneaux
> ne produit pas des résultats cohérents selon ces critères : certaines
> représentations passent OSM d'autres non
Tu peux m'en montrer une ou JOSM se trompe ?
--
sly (sylvain letuffe)
___
dev-fr mailing list
dev-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev-fr
lle du TSP
mais bien inférieure, tout en étant plus complexe que l'aglo actuellement
rencontré dans osm2pgsql ou, peut-être, osm2gis.
--
sly (sylvain letuffe)
___
dev-fr mailing list
dev-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev-fr
On vendredi 4 mai 2012, David Gros wrote:
> merci pour cette réponse rapide.
>
> Le generate-image.py donne les contours mais aucune données de la base.
generate-image.py est un peu archaïque et ne te parlera pas beaucoup en cas
d'erreur, je te recommande d'utiliser nik2img.py
http://code.google
ps: A noter que tu n'es pas sur la bonne liste de diffusion, car [tech] est
plutôt dédiée aux serveurs de l'association osm-fr
Pour ce genre de question je recommande
dev-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev-fr
On vendredi 4 mai 2012, david.gros...@gmail.com wrote:
ra le "plan de résolution" de ta requête (nombre de boucles,
indexes utilisés, etc.)
--
sly (sylvain letuffe)
___
dev-fr mailing list
dev-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev-fr
Le mardi 10 avril 2012 21:50:13, Jocelyn Jaubert a écrit :
> C'est relancé, et la base osmosis d'osm7 est en train de se mettre à
> jour :)
Idem pour la base osm2pgsql de osm7, merci à toi d'avoir adapté les diffs
spécial france.
--
On mardi 10 avril 2012, kimaidou wrote:
> Bonjour,
>
> Une petite traduction "rapide" d'un passage du lien précédent, pour ceux
> qui préfèrent le français :
>
> Q: Est-ce qu'après avoir appliqué tous les diffs dans une base de données
> osm2pgsql, elle ne contiendra que des données ODBL ?
Pour
esoin de ré-import, il faut juste manuellement changer la source
des diffs et le n° de séquence deux fois
--
sly (sylvain letuffe)
___
dev-fr mailing list
dev-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev-fr
salut,
(je bascule sur dev-fr)
> Sur le todo... repasser automatiquement en proxy en lecture si on a un
> décalage de plus de X minutes sur les diff... sauf si l'API UK est
> injoignable ;)
>
> C'est un filet de sécurité qui serait bien utile.
J'ai noté ça dans un fichier a_faire.txt :
- éviter
On lundi 19 mars 2012, didier2020 wrote:
> j'ai enregistré la requete dans un fichier mais quand j'utilise
> psql -d osm -U didier -f monfichier.sql
> j'ai un message erreur : erreur de syntaxe sur ou près de « SELECT »
Tu peux nous faire passer ton fichier monfichier.sql ?
Peut-être a-t-il été
mble mais je ne sais plus où
j'ai mis ça.
L'avantage pour moi d'utiliser mapnik c'est que je l'utilisais déjà pour
générer des bitmap, j'avais donc juste un paramètre à changer pour avoir du
svg, mais en effet, vu la solution simple que t
donnée (si tu n'as pas mis toute la
france !) avec :
SELECT ST_IsValidReason(way),osm_id
FROM
planet_osm_polygon
WHERE
building = 'yes' AND
st_isvalid(way)='f'
--
sly (sylvain letuffe)
___
dev-fr mailing l
On mardi 28 février 2012, Christian Quest wrote:
> Tu ne peux pas faire une règle qui redirige tout par défaut sauf ce
> que tu gère ? ;)
Les deux sont possibles, mais ayant prévu de rajouter d'autres appels comme
/api-dev pour la version de test
/api-ways pour celle qui retourne les ways interse
On mardi 28 février 2012, Christian Quest wrote:
> Ca serait bien que cette redirection soit aussi présente sur
> api.openstreetmap.fr car JOSM nous renvoie vers
> http://api.openstreetmap.fr/user/cquest et on a un beau 404.
Dans un premier temps je ne vais pas ré-écrire ces pages pour pouvoir rép
> Je préfère de loin la mise en évidence via un outil tiers que par un Fixme
> enregistré dans la base.
Juste pour dire que je suis d'accord.
De manière général, je suis contre les bots qui ajoutent des fixme dans la
base pour plusieurs raisons :
- celle que tu cites : si un bot sait où ajouter
envoyée ?
Vous êtes plusieurs à me l'avoir demandé, alors voilà qui est fait... pour
faire plaisir à JOSM.
Me signaler si cela introduit un bug que je n'aurais pas repéré
--
sly (sylvain letuffe)
___
dev-fr mailing list
dev-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev-fr
e j'utiliserais st_intersects plutôt
que st_overlaps
Et au cas où tu ne connaisses pas, la bible :
http://www.postgis.org/docs/reference.html
--
sly (sylvain letuffe)
___
dev-fr mailing list
dev-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev-fr
On jeudi 16 février 2012, Ab_fab wrote:
> Je ne sais pas trop non plus pour quelles raisons il est jugé nécessaire de
> garder ces anciennes références.
Alors virons les ;-)
et mettons à jour convenablement la base de référence du sandre si eux ne le
font pas ;-)
> Peut-on virer les lignes suiva
On jeudi 16 février 2012, Ab_fab wrote:
> Comptabiliser quand la clef "ref:sandre" *OU* la clef "old_ref:sandre"
> colle avec ce que l'on trouve sur le site
Merci de me rafraîchir la mémoire, quel est l'intérêt de conserver dans OSM
l'ancienne référence sandre ?
--
sly
qui suis-je : http://sly
On jeudi 16 février 2012, Frédéric Rodrigo wrote:
> L'outil de Sly n'utilise volontairement pas les relations. Un des buts
> de l'outil devait être de démontrer que l'on a pas besoin de
> relations. On m'a juste pas le même point de vue avec Sly ;)
Tu confonds avec un autre outil je crois.
Celui-c
yo,
On jeudi 16 février 2012, Christian Quest wrote:
> A propos de http://suivi.openstreetmap.fr/cours-eau/comparaison-sandre.html
> Les role=side_stream ne semblent pas mis de côté.
> Est-il possible de ne comptabiliser que les membres n'ayant aucune
> rôle ou le rôle main_stream ?
En réponse ra
On mardi 7 février 2012, Bruno Cortial wrote:
> Salut,
> Il y a quelques temps, j'avais proposé 2 scripts python pour améliorer les
> fichiers Cléo.
> http://lists.openstreetmap.org/pipermail/talk-fr/2011-August/035156.html
Je te propose de passer sur la liste dev-fr histoire de ne pas remplir plu
On mercredi 25 janvier 2012, Jocelyn Jaubert wrote:
> Le 25 janvier 2012, sly (sylvain letuffe) a écrit :
> > La liste des relations qui sont transformées en géométries est
> > hard-codée dans output-pgsql.c, et sont les suivantes :
> > type=multipolygon/boundary/road (et j
> Hum, je ne comprends pas tout au format de la base osm2pgsql
> (j'utilise l'instance de osm7)...
Si tu ne comprends pas tout, c'est que tu as tout compris ;-)
> Mais je n'arrive pas à trouver 90341 dans planet_osm_line ou
> planet_osm_polygon, que ce soit en positif ou négatif. Est-ce que c'es
Voilà que je me mets à parler tout seul maintenant.
Si tu as besoin d'aide, de courage, d'une bière ou d'un fichier osm d'exemple
fictif incluant une relation pyramidale, je peu aider !
--
sly (sylvain letuffe)
___
dev-fr
Le mardi 24 janvier 2012 23:21:38, sly (sylvain letuffe) a écrit :
> Mais je me suis creusé la tête pour le faire en
> SQL pour l'instant sans résultat.
Mais je suis quand même en train de me demander si j'ai bien cherché
convenablement :
http://www.postgis.org/docs/ST_MakePol
7;osmosis, qui
> indique tous les nodes/ways/relations modifiés lors de la dernière mise
> à jour.
il y a un champ dans les tables planet_osm_(rels/nodes/ways) qui s'appel
pending=t/f
je ne sais pas si c'est ça que tu cherches
--
sly (sylvain letuffe)
___
dev-fr mailing list
dev-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev-fr
Je me permet de migrer vers dev-fr, je sens que ça va partir en sucette
> Déjà, si c'est en C, ça m'intéresse bien plus que le java d'osmosis :)
Non, pas possible ;-) tu, tu, tu... voudrais mettre ton nez dans osm2pgsql ?
malheureux, tu n'en peux déjà plus de mes bugs reports, mais je vais te
h
> Si tu as l'ID d'un élément manquant, on peut très facilement remonter
> au diff qui aurait du générer cet élément - j'ai gardé tous les diffs
> depuis le début.
Bien noté.
J'ai tenté de remonter le fil de la construction du polygone pour la relation
en question mais des modifications manuelle
à l'air d'être assez
isolé, voir de venir d'ailleurs.
Si ce n'est que sur mon serveur, en utilisant les diffs "officiels" ne n'ai pas
rencontré le problème
--
sly (sylvain letuffe)
___
dev-fr mailing list
dev-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev-fr
s utile.
On pourrait par exemple rêver d'un attributs à tes delete qui indique s'ils
sont où non dans le polygone de découpe, que je pourrais par exemple
(ex)filtrer avec osmosis mais que d'autre pourraient simplement ignorer
Mais bon, ça me semble beaucoup de bruit pour pas grand
e delete me semble curieux
Dans tes .osc, les delete ne sont pas groupés, contrairement à ceux de planet,
peut-être une explication à la taille ?
--
sly (sylvain letuffe)
___
dev-fr mailing list
dev-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev-fr
osm2pgsql sur osm7 avec ces hour diff
J'en ai lancé à la main, tout semble fonctionner correctement. Attendons les
rapports de bugs ;-)
--
sly (sylvain letuffe)
___
dev-fr mailing list
dev-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev-fr
Salut,
> un rendu tango ...
Moi c'est plutôt salsa, et ça rend bien aussi ;-)
késako ?
> Question renderd en pointe je plafone à 15 tuiles (tous les zoom
> confondu) par min.
15/minute c'est quand même plutôt faible je trouve, y'a peut-être bien un
problème quelque part.
Moi qui utilise u
> mod_tile fait ça pas mal :-)
(...)
> c'est là mon problème, j'ai 2 disques SATA2 en raid 0 et je ne peux pas
> les changer pour du SSD ...
J'ai bien l'impression que je n'ai rien a t'apprendre ;-) et que ton installe
est sans doute bien mieux que ce que je fais moi même !
Tu as quelques stats
On vendredi 9 décembre 2011, Thomas Clavier wrote:
> autovacuum = on
> J'ai testé à off et c'est pas mieux ... donc autant choisir la
> simplicité :-)
Tout pareil, je l'ai repassé à "on" sans noter de ralentissement flagrant
(mais je n'ai pas non plus lancé de bench)
> > fsync = off
> > synchro
non rendu/non
listé/non trouvé et après je remontais la piste pour voir à quel moment le
truc avait pû être perdu et à quelle étape.
Je propose de procéder ainsi ;-)
--
sly (sylvain letuffe)
___
dev-fr mailing list
dev-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev-fr
si le seek sur disque magnétique pour aller chercher 3 octets
ne devient pas limitant.
(peut-être que la cache disque d'un noyau linux peut te sauver les meubles)
--
sly (sylvain letuffe)
___
dev-fr mailing list
dev-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev-fr
> > autovacuum = off
> D'où vient ce autovacuum = off ?
> C'est déconseillé dans les documentations récentes de postgresql.
> Qu'est-ce-qui le justifie ?
Justification : pour aller encore plus vite
Contraintes : l'espace disque augmente encore plus vite que la taille OSM à
cause des "trous" dans
On vendredi 2 décembre 2011, Thomas Clavier wrote:
> Jocelyn, sly, ya moyen d'avoir vos astuces de tunning postgres ?
> http://osm.tcweb.org en aurais bien besoins :-)
Puis-je proposer de continuer la discussion sur la liste dev-fr (en copie) ?
Un bon tutoriel :
http://weait.com/content/build-yo
> > $ du -h /chemin_des_base_postgres ?
> Excellente idée ! Mais justement :
>
> /chemin_des_base_postgres ?
Fichtre !
Tu ne sais pas où sont rangé sur ton disque le gros paquet de donnée ? ;-)
Chez moi, la configuration de postgres est là :
/etc/postgresql/8.4/main/postgresql.conf
et dedans
On vendredi 25 novembre 2011, Vincent Pottier wrote:
> Bon j'avais oublié une table et non des moindres :
> 27 142 Mo
et si tu fais simplement un :
$ du -h /chemin_des_base_postgres ?
--
sly
qui suis-je : http://sly.letuffe.org
email perso : sylvain chez letuffe un point org
_
> Chez moi, d'après les stats trouvées dans pgAdmin, l'import France pèse
> à peu près 20 GO.
Ha ? c'est moins que moi ça.
Tu utilises le mode --slim ou pas ?
--
sly
qui suis-je : http://sly.letuffe.org
email perso : sylvain chez letuffe un point org
__
On vendredi 25 novembre 2011, didier2020 wrote:
> bonjour a tous,
>
> juste une petite question:
> je voudrais tester/apprendre l'utilisation des base de données postgres
> avec osm. Quel est la taille minimum requise pour un extract france ( ou
> europe)
( parenthèse :
Comme je le disais en priv
(J'ai dû me merdé quelque part, dans mes inscriptions ou autre)
Voilà donc la copie de mon mail lancé sur dev-fr
> Quant à çà:
> http://c.tile.cartosm.eu/tile/isohypse/15/16895/11787.png, d'ou ça peut
> bien venir? Est-ce que le dernier pixel est répété en bord de tuile SRTM?
J'ai le même type
(Merci d'avoir transmis sur dev-fr, c'est bien plus adapté ici)
> > Test case :
> > http://analyser.openstreetmap.fr/cgi-bin/index.py?relation=1781467
> >
>
> C'est la pseudo-intersection que tu voudrais qu'elle soit détectée ?
Exact, j'ai pas réussi à la décrire avec des mots mais en gros, le
On mercredi 7 septembre 2011, Aurélien FILEZ wrote:
> Est-ce que tu as un moyen de savoir si ce qui est généré est exacte et
> précis ?
J'ai mais il faut que je bidouille un peu...
> Auquel cas j'ouvre une repository sur googlecode qu'on puisse
> travailler à plusieurs dessus ? Car ça me semble
On mercredi 7 septembre 2011, Aurélien FILEZ wrote:
> Voici les sources : http://kinju59.free.fr/polygons/sources.zip
>
> Si quelqu'un pouvait les porter sous Linux, avec un MakeFile etc. (tout en
> gardant la compatibilité avec Windows) ça serait cool.
Ok merci, je verrais si j'arrive à le compi
On mardi 6 septembre 2011, Aurélien FILEZ wrote:
> Merci beaucoup.
>
> Finalement je me suis bricolé un truc à l'arrach' car j'avais besoin des
> multipolygons sous format WKT et sous forme de polygon file, d'une relation
> quelconque (normal ou super)
>
> Le résultat est ici : http://kinju59.fre
eront :
France (côte méditerranéenne de l'espagne à monaco)
et
France (côte méditerranéenne de monaco à l'Italie)
ou
2) on accepte que cette relation ne forme pas qu'une seule ligne brisée mais 2
PS: comme ce questionnement n'est pas uniquement technique, j
On vendredi 2 septembre 2011, Aurélien FILEZ wrote:
> Hi !
>
> Est-ce que c'est pareil pour les relations simples ?
C'est vrai quel que soit le type d'élément membres d'une relation (noeud, way
ou relation)
L'API osm les restituant dans l'ordre dans lequel ils ont été envoyés mais ne
réalisan
On vendredi 2 septembre 2011, Aurélien FILEZ wrote:
> Y a-t-il une notion d'ordre à respecter ou c'est normal ce genre de cas ?
C'est normal, une relation n'a pas l'obligation d'avoir ses membres ordonnés.
C'est cependant plus pratique pour les cartographe quand c'est le cas pour
repérer des "cas
> J'ai essayé les deux scripts pour créer le polygon de la France et :
(...)
Je ne les ais pas encore utilisé, mais sachant qu'ils ont été plus ou moins
écrit dans ce but, je suis surpris que ça ne marche pas.
Est-ce que ce n'est pas tout simplement car la france actuellement, ne forme
pas un p
> Ah tiens, j'en apprends tous les jours sur les fichiers présents sur
> osm1.crans.org :)
>
> J'utilise de mon côté un autre script, que j'ai mis temporairement là:
> http://osm1.crans.org/~jocelyn/
Ah tiens, j'en découvre moi aussi !
J'en rêvais d'un comme ça, capable de sortir du svg, du gpx,
> Il paraît que vous avez un outils permettant de créer un polygon à partir de
> super-relations comme c'est le cas pour les bordures françaises..
>
> Comment s'appelle cet outils ?
A priori, mais j'avais testé une vielle version il y a 2 ans de ça, cet outil
devrait faire l'affaire :
http://osm
> SELECT Y(ST_AsText(ST_Transform(way, 4326))),
> X(ST_AsText(ST_Transform(way, 4326))),
> Distance(way, (SELECT way FROM planet_osm_point WHERE
osm_id=582505865))::int,
> amenity || ' ' || name, 'icon.png', '16,16', '0,0'
> FROM planet_osm_point P WHERE (amenity ILIKE 'res%' OR amenity ILIKE
> '
Yo,
> Si je ne m'abuse, les données source viennent directement de la base
> OSM, et donc des editions des contributeurs sur la ligne de côte.
Aux dernières nouvelles, c'est en effet ça.
> Si je comprends bien, le fait de découper les formes complexes et
> étendues en polygones plus petits perme
> > Avec une telle contrainte c'est mort car je ne vois aucune solution toute
> > faite.
>
> Ah... ben je croyais que c'était pas si original comme problème.
Nouvelle piste, maperitive semble avoir bien évolué et semble pouvoir utiliser
des gpx comme source de donnée :
http://maperitive.net/doc
> Est-il possible de
> faire le même genre de chose avec des BD beaucoup plus simple à
> déployer telle que sqlite (spatialite je crois) ?
Mapnik sait en effet gérer une base spatialite :
http://trac.mapnik.org/wiki/SQLite
--
sly
qui suis-je : http://sly.letuffe.org
Salut,
> En fait, je crois avoir compris que ce sont des traces relatives à des
> chemins forestiers, d'où ma suggestion d'enrichir OSM. A partir de ces
> données, j'imagine qu'il calcule des itinéraires.
Ha ? et viking est capable de faire ça sur des données gpx qui sont, par
essence, non topol
On mardi 24 mai 2011, Guilhem Bonnefille wrote:
> Bonjour,
>
> J'ai une question un peu Hors-Sujet, aussi j'espère que vous ne m'en
> voudrez pas trop.
Je recommande le transfert de cette discussion vers dev-fr@openstreetmap.org
(que j'ai mis en copie) où elle sera toujours un peu HS, mais moins
> Attention au risque de confusion, dans la codification EPSG,
> l'identifiant du système de coordonnées WGS84 est le 4326, pas le 4020.
Fichtre, j'ai copié collé en provenance de mon bout de code, peut-être que
finalement j'exporte mal depuis le début ;-(
j'ai corrigé avec la projection 4326,
On mercredi 2 mars 2011, yvecai wrote:
> C'est quoi ton expérience avec Aster?
Le site de la NASA pour la récupération de ces données est le plus mal foutu
qu'il m'ait été donné de voir, juste derrière le portail de orange.fr
> Je me suis inscrit hier pour
> télécharger quelques 'capsules', j'a
On mercredi 2 mars 2011, yvecai wrote:
> Ouh là, on sait pourquoi elle est noire, celle-ci! Là aussi, les données
> d'altitudes ne sont pas disponibles dans la base SRTM. Celle-ci comporte
> des trous par endroit. Je sortirais un message d'erreur plus explicite.
De ce coté là, ASTER est plus in
On mercredi 2 mars 2011, Marc Sibert wrote:
> Si la solution est dans osm2pgsql,
"une" solution existe en effet dans osm2pgsql et une table est construite qui
contient ce que tu cherches.
Mais tu n'as pas tout à fait dis ce que tu voulais :
tu veux arriver à le faire toi même ou tu veux juste
(Pour ceux qui sont motivés, on peut aussi continuer à parler du format pbf
sur la liste dev-fr)
> Il est prevu de proposer a terme un fichier planete en PBF en addition du
> fichier xml compressee. Toutefois, si le traitement du fichier est plus
> rapide, osm2pgsql en mode slim reste quasiment i
> Celà dit, c'est beaucoup plus génant en superposition sur la slippy map
> très claire que sur ton rendu 'hiking' très coloré.
> Yves
C'est moins gênant, mais ma méthode apporte elle aussi son lot de problèmes.
Je suis par exemple très insatisfait de la visiblité des forêts, champs,
zones res
101 - 186 sur 186 matches
Mail list logo
