PostGIS et PostgreSQL

Le
JKB
Bonjour à tous,

Je poste par ici parce que certains d'entre vous ont peut-être été
confrontés au même problème (et parce que j'attends toujours le
retour de ma demande d'inscription à la ML de postgis ! :-( ).

J'ai installé un serveur PostGIS sur un NetBSD (SS20, deux
HyperSPARC's à 200 MHz, 512 Mo) pour tester des petits trucs
(mes serveurs principaux moulinent la cartographie de l'Europe
depuis bientôt trois semaines).

J'ai donc compilé tout ce qu'il fallait et j'obtiens un beau :

routing=# SELECT postgis_full_version();
postgis_full_version
-
POSTGIS="1.3.2" GEOS="3.0.0-CAPI-1.4.1" PROJ="Rel. 4.6.0, 21 Dec 2007"
USE_STATS
(1 ligne)

routing=#

Jusque là, pas de problème. J'ai extrait une zone de test de la
cartographie française (code postal 68420 pour fixer les idées).

En lançant

routing=# select gid as id, source::int4, target::int4,
length::double precision as cost, x1, y1, x2, y2,
reverse_length::double precision as reverse_cost
from streets_68420_edges;

J'obtiens un superbe :

id | source | target | cost | x1 |
y1
| x2 | y2 | reverse_cost
+--+--+++--
-+++
1079 | 764 | 779 | 109.686681754038 | 969849.586821899 |
2345504.24865032
| 969806.599052771 | 2345403.48040423 | 1000000
1080 | 780 | 773 | 607.435743080355 | 970604.636317757 |
2346511.36335418
| 970238.275730862 | 2346026.8822662 | 1000000
1081 | 775 | 780 | 39.976601088304 | 970630.361971694 |
2346541.96269018
| 970604.636317757 | 2346511.36335418 | 1000000
1082 | 781 | 777 | 3.65446540479074 | 971151.360931931 |
2348559.48045324
| 971150.083293361 | 2348556.05660203 | 1000000
1083 | 738 | 782 | 411.932839033992 | 971748.1370478 |
2350459.33251054
| 971641.722518148 | 2350134.99871133 | 1000000
1084 | 343 | 783 | 20.6248235939301 | 970792.411606632 |
2346674.7932154
| 970773.332040068 | 2346669.12764817 | 1000000
1085 | 783 | 342 | 19.2936006502604 | 970773.332040068 |
2346669.12764817
| 970767.010298853 | 2346650.89913715 | 1000000
1086 | 345 | 776 | 255.466975944347 | 970914.14883827 |
2346959.95615396
| 970775.99828827 | 2346745.06594634 | 1000000
1087 | 468 | 394 | 173.488620002482 | 968258.483014486 |
2345264.67806913


Je vous fais grâce des 1116 lignes suivantes. Parfait, j'arrive avec
une moulinette awk à afficher ma cartographie dans gnuplot. J'essaye
maintenant de calculer un itinéraire par :

routing=# select step from shortest_path_astar(
'select gid as id, source::int4, target::int4,
length::double precision as cost, x1, y1, x2, y2,
reverse_length::double precision as reverse_cost
from streets_68420_edges', 138, 255, false, true);
step

138
137
551
550
144
143
419
418
107
417
416
106
105
446
753


Parfait, ça fonctionne. Sauf que cela fonctionne une fois sur je ne
sais pas combien. Je peux aussi obtenir :

routing=# select step from shortest_path_astar(
'select gid as id, source::int4, target::int4,
length::double precision as cost, x1, y1, x2, y2,
reverse_length::double precision as reverse_cost
from streets_68420_edges', 138, 255, false, true);
la connexion au serveur a ?t? coup?e ? l'improviste
Le serveur s'est peut-?tre arr?t? anormalement
avant ou durant le traitement de la requ?te.
La connexion au serveur a ?t? perdue. Tentative de r?initialisation :
Echec.
!>

avec dans les logs du serveur :

LOG: server process (PID 23868) was terminated by signal 11
LOG: terminating any other active server processes
LOG: all server processes terminated; reinitializing
LOG: database system was interrupted at 2008-02-25 19:45:08 CET
LOG: checkpoint record is at 2/2FD028C8
LOG: redo record is at 2/2FD028C8; undo record is at 0/0; shutdown TRUE
LOG: next transaction ID: 0/12848; next OID: 34432
LOG: next MultiXactId: 1; next MultiXactOffset: 0
LOG: database system was not properly shut down; automatic recovery in
progress
LOG: record with zero length at 2/2FD02918
LOG: redo is not required
FATAL: the database system is starting up
LOG: database system is ready

Le postgresql est un 8.2. Je ne sais pas où chercher d'autant que si
la requête aboutit une première fois, je peux relancer un certain
nombre de fois (grand) la requête sans plantage jusqu'à ce que je
referme gsql et le relance

Une idée, parce que je commence à désespérer Je précise que la
santé du serveur en question (même s'il est ancien) est parfaite.

Cordialement,

JKB
--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
JKB
Le #1118854
Le 25-02-2008, à propos de
PostGIS et PostgreSQL,

Bon, on avance. Le problème est dans pgrouting :
la ligne suivante

tuple = heap_formtuple(tuple_desc, values, nulls);

plante aléatoirement, mais je ne vois pas pourquoi... Le calcul se
fait bien, c'est la transformation des données qui plante...

JKB

--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
JKB
Le #1124666
Le 25-02-2008, à propos de
Re: PostGIS et PostgreSQL,
JKB écrivait dans fr.comp.os.unix :
Le 25-02-2008, à propos de
PostGIS et PostgreSQL,

Bon, on avance. Le problème est dans pgrouting :
la ligne suivante

tuple = heap_formtuple(tuple_desc, values, nulls);

plante aléatoirement, mais je ne vois pas pourquoi... Le calcul se
fait bien, c'est la transformation des données qui plante...


On a même trouvé ce matin en dépouillant les cores ;-) L'interface
de PostGIS est comment dire ? quelque peu mouvante...

JKB

--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.

Emmanuel Florac
Le #1130013
Le Tue, 26 Feb 2008 12:13:14 +0000, JKB a écrit :

On a même trouvé ce matin en dépouillant les cores ;-) L'interface de
PostGIS est comment dire ? quelque peu mouvante...


Je crains que tu ne sois un peu seul face à un support disons minimal de
PG sur NetBSD :) Je connais des gens au BRGM et à l'IGN qui utilisent
postGIS (sous Linux), mais je ne les ai jamais entendu parler de ce genre
de problèmes...

--
Le livre, comme livre, appartient à l'auteur, mais comme pensée, il
appartient - le mot n'est pas trop vaste - au genre humain. Toutes les
intelligences y ont droit. Si l'un des deux droits, le droit de
l'écrivain et le droit de l'esprit humain, devait être sacrifié, ce
serait, certes, le droit de l'écrivain, car l'intérêt public est notre
préoccupation unique, et tous, je le déclare, doivent passer avant nous.
Victor Hugo.

JKB
Le #1137746
Le 26-02-2008, à propos de
Re: PostGIS et PostgreSQL,
Emmanuel Florac écrivait dans fr.comp.os.unix :
Le Tue, 26 Feb 2008 12:13:14 +0000, JKB a écrit :

On a même trouvé ce matin en dépouillant les cores ;-) L'interface de
PostGIS est comment dire ? quelque peu mouvante...


Je crains que tu ne sois un peu seul face à un support disons minimal de
PG sur NetBSD :) Je connais des gens au BRGM et à l'IGN qui utilisent
postGIS (sous Linux), mais je ne les ai jamais entendu parler de ce genre
de problèmes...


En fait, ce n'est pas PostGIS qui coince, mais pgRouting parce que
l'interface des fonctions de PostGIS change plus vite que son ombre
(donc il faut se palucher de nouvelles interfaces).

JKB

--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.


Publicité
Poster une réponse
Anonyme