Le blog de Jean David TECHER, un Réunionnais à Saint-Priest/Lyon

Aller au contenu | Aller au menu | Aller à la recherche


< 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 >

lundi 18 décembre 2006

Générer un fichier kml pour Google Earth à partir de PostGIS, concernant la réunification des tronçons de la RN113 dans le Gard

Objectif

Bon ce soir je me suis lancé le défi de pouvoir enfin afficher la portion de la RN113 qui traverse le Gard (département n° 30) dans GoogleEarth.

1 - Ce qui ne marche pas!

Je dispose pour celà de la table des tronçons! Donc pour connaître la route en question il me suffit de faire

dde30=#  SELECT id_1,id_2,route,geometrytype(the_geom),numgeometries(the_geom) FROM route_dep30 WHERE route='n113' LIMIT 10;
   id_1    | id_2 | route |  geometrytype   | numgeometries
-----------+------+-------+-----------------+---------------
 300005729 |  204 | n113  | MULTILINESTRING |             1
 300005730 |  205 | n113  | MULTILINESTRING |             1
 300005775 |  208 | n113  | MULTILINESTRING |             1
 300005786 |  210 | n113  | MULTILINESTRING |             1
 300005787 |  211 | n113  | MULTILINESTRING |             1
 300005816 |  212 | n113  | MULTILINESTRING |             1
 300005823 |  213 | n113  | MULTILINESTRING |             1
 300005840 |  215 | n113  | MULTILINESTRING |             1
 300005853 |  216 | n113  | MULTILINESTRING |             1
 300005876 |  217 | n113  | MULTILINESTRING |             1
(10 lignes)

Donc fier de moi comme Djay (la semaine dernière) m'avait appris une fonction de PostGIS que je ne connaissais pas linemerge qui simplifie par exemple un MULTLINESTRING contenant uniquement un simple LINESTRING en un simple LINESTRING, je me dis ben c'est gagné!

Ben non ......!

En effet,cette table contient des MULTILINESTRINGS dont le nombre de LINESTRINGS est bien > 1 comme le prouve cette requête

dde30=#  SELECT distinct route,geometrytype(the_geom),numgeometries(the_geom) FROM route_dep30 WHERE route='n113';
 route |  geometrytype   | numgeometries
-------+-----------------+---------------
 n113  | MULTILINESTRING |             1
 n113  | MULTILINESTRING |             2
 n113  | MULTILINESTRING |             4
(3 lignes)

Le nouveau switch -S de shp2pgsql qui permet de convertir un MULTI en simple ojet spatial le confirme aussi:

postgres@jenna-edgy:~$ shp2pgsql -DIdS route_dep30.shp route_dep30|iconv -f LATIN1 -t UTF-8|psql dde30
Shapefile type: Arc
Postgis type: LINESTRING[2]
We have a MultiLineString with 2 parts, can't use -S switch! <-------- ICI !!!
... ...

Au premier abord j'avais cru comprendre que linemerge() transformait un MULTILINESTRING en un LINESTRING. En fait non, erreur de ma part, suite à une explication avec Djay. Cette fonction fait bien plus que celà. Voyons donc quelques exemples:

La fonction linestring()

Exemple 1 avec deux lLINESTRING contigües mise en relation par le POINT(5 5)

testgis=# select astext(linemerge(geometryfromtext('MULTILINESTRING((0 0,5 5),(5 5,6 10))',-1)));
          astext
--------------------------
 LINESTRING(0 0,5 5,6 10)
(1 ligne)

No soucy!

Exemple 2 deux LINESTRING discontigües

testgis=# select astext(linemerge(geometryfromtext('MULTILINESTRING((0 0,5 5),(5 4,6 10))',-1)));
                astext
---------------------------------------
 MULTILINESTRING((0 0,5 5),(5 4,6 10))
(1 ligne)

Donc aucun souci! Après mettre entretenu avec Djay, j'ai finalement compris comme il me le suggérait que si on voulait travailler unqiuement avec la fonction linermerge, il faudrait faire une analyse des données: trouver les MULTILINESTRING qui ne sotn aps convertis en simple LINESTRING, les ouvrir dans le MULTILINESTRING correspondant, scinder etc...Mais mon but ici est de parvenir à faire ça en une seule requête! Donc j'ai laissé tombé pour linemerge! Apparement ce sont avec mes données que je dosi faire!

Première conclusion: linemerge() ----------> tu sors ............!

Deuxième conclusion: shp2pgsql ----------> tu sors ............!

2 - Ce qui marche!

Après une heure de recherche intensive sur la documentation de PostGIS, et sur la mailing-list, j'ai trouvé la solution ze dump() function!

En pré-requis comme gdal 1.3.2 avec ogr2ogr ne permet pas de faire de sortie en fichier kml, il faut commencer par télécharger les sources de gdal 1.4.0 beta 1 à http://www.gdal.org/dl/ puis

wget http://www.gdal.org/dl/gdal140beta1.zip
unzip gdal140beta1.zip
cd gdal-1.4.0beta1
 CC=gcc-3.4 CXX=g++-3.4 ./configure --prefix=/opt/gdal-1.4.0 --with-geos --with-static-proj4=/usr/local/--without-python
make
make install

NB: Ici j'ai tout installé dans le répertoire /opt/gdal-1.4.0

Puis on fait pour générer le fichier RN113.kml

/opt/gdal-1.4.0/bin/ogr2ogr -f KML /root/RN113.kml PG:'host=192.168.0.1 dbname=dde30 user=postgres' -sql \
"SELECT (dump).geom FROM (SELECTt dump(transform(the_geom,4326)) FROM route_dep30 WHERE route='n113') AS foo"

Et on matte tout ça dans Google Earth


PostGIS ---> KML: Portion de la RN113 (réunifié à partir de ses tronçons) traversant le Gard depuis Google Earth

dimanche 17 décembre 2006

Un samedi après-midi à faire les courses

Bon samedi je me suis levé à 11h30...J'ai petit-déjeuné, ensuite j'ai pris une douche! En suite, nous sommes allés faire les courses! Purée! J'ai regardé...On a décollé de la maison vers 13h00, retour vers 18h00 soit 5h00 de courses :

  • Leader Price de Castelnau (bouffe pour le chat, trucs pour la cuisine;
  • un café chez une connaissance de Catherine;
  • courses à HYPER U du Crès: ménage, etc....;
  • course à la pharmacie

J'aurais pas pensé que nous aurions pris autant de temps . Du coup nous avions prévu d'inviter une amie à venir à la maison pour prendre un café. On a reporté ça à dimanche.

En arrivant à la maison j'étais mort ! Je me suis fait un casse-dalle (pain+salade+jambon), je me suis reposé et ensuite (re)mangé puis j'ai traîné sur Internet jusqu'à 4h30 du mat. J'ai tchatté avec un ubunteros de montpellier vers 4h00. Un gars bien sympa, voulant connaître un peu les méandres des bases de données. Aujourd'hui je me lève frais comme un poisson sur un marché de poissons. Comme un dimanche quoi !

jeudi 14 décembre 2006

Formation sur Lyon

Ahé après 4 jours passés à Lyon, avec Djay nous revenons d'une formation passé à la ville de Lyon. La formation était excellente et le contact avec les gens bien intéressant! Les sujets que nous avons abordé étaient tellement vaste que nous avons du tranché pour choisir nos sujets que nous voulions proposés concernant l'optimisation de PostgreSQL et de PostGIS.

Le choix des index (en PostgreSQL) et celui d'exercice (en PostGIS) s'est avéré payant! Les gens étaient bien motivés par le choix des sujets et près à nous poser tellement de question...

Mais mon séjour du côté visite de la ville de Lyon - côté culinaire - a aussi était une belle réussite! A notre premier soir, nous avons galéré poru trouver un taxi là où nous étions et finalement on en a trouvé un! Et ben sur les trois soirs que nous avons passé là-basn, on a pris abonnement chez lui! Il nous a donné de bonnes adresses surtout dans le Vieux Lyon:

  • lundi soir: restaurant indien, un vrai délice, authentique, pas modelé pour attirer la clientèle française (j'entends par là que la cuisine n'a pas été faite de manière à à s'adapter aux attentes de al gastronomie française...)...Je me suis régalé ;
  • mardi soir: restaurant "Notre maison", un délice, belle décoration, le patron est bien sympathique, c'était une vrai salada lyonnaise que j'ai dégusté, de la rosette, avec un plat avec du porc trempé dans une sauce emrobé de carottes.
  • mercredi soir: ah je me souviens plus du nom du resto mais c'était bien!

Voilà jeudi soir retour à la maison! Le plus dur quand même ça a été le froid sur Lyon! Brahhhh! Faisait bien plus froid qu'à Montpellier! Mais bon ce soir je suis rentré tranquil chez moi avec ma petite famille même si Cat' est malade!

dimanche 10 décembre 2006

Migrer une base encodée en LATIN9 vers une autre machine avec nouvel encodage en UTF8

Bon une méthode un peu barbare pour transférer mais ca marche!

 pg_dump -Civo -E UTF8 [base_a_migrer] |sed -e "s:LATIN9:UTF8:g"|psql -U [utilisateur] -h [hotedistant] [basequelconque]

avec comme rappel

  • -C: pour dire de créer la base;
  • -i: pour ne pas tenir compte du versioning entre les versions client/serveur;
  • -v: pour avoir le mode verbeux (important on ne sait jamais);
  • -o: pour demander le support des OID;
  • -E UTF8: pour lui demander de spécifier SET client_encoding = 'UTF-8';.