Le portail francophone de la géomatique

A super! J'avoue que je m'étais demandé comment il traitait la requête avec le limit plutot qu'avec un where.
J'avais pas eu trop le temps de regarder ça depuis mon premier message mais du coup je teste avec un && comme ça :

select * from cadastralparcels_parcellaire_express_parcelle p
 where p.the_geom && (select st_transform(st_buffer(geom, -170),4326)  from projet where id = 103)

Mais je recupère une erreur 504...
J'ai essayer avec un st_envelope et ::box2D mais j'ai eu la meme chose. la zone en question fait environ 1km²

et même chose :

ERROR:  [1] HTTP error code : 504 

SQL state: XX000

Je vais essayer plus petit...

C'est possible que mon ip soit temporairement "blacklistée" suite à une requete lourde?

Je viens de tester avec cette requête et ca passe:

create table localtestparc as
select *
from testparc
where the_geom && 'BOX(1.443463 43.591762, 1.446831 43.593707)'::box2d;
-- [2023-09-27 12:25:00] 108 rows affected in 3 s 893 ms

testparc est la foreign table définie sur la layer 'CADASTRALPARCELS.PARCELLAIRE_EXPRESS:parcelle', wfs url:  'WFS:https://wxs.ign.fr/parcellaire/geoportail/wfs?SERVICE=WFS&VERSION=2.0.0&REQUEST=GetCapabilities'

Nicolas

Juste pour me donner une petite idée : combien de temps elle prend la requete que j'essaie (celle que vous avez doné en exemple?)

Et:
[2023-09-27 18:52:20] 138,768 rows affected in 13 m 35 s 303 ms
pour la bbox: 'BOX(1.3626 43.5362, 1.524 43.6712)'::box2d

Nico

Bon alors j'ai testé quelque truc... et je trouve le comportement de la machine très bizarre.

Par exemple j'ai tenté de faire ça :

IMPORT FOREIGN SCHEMA ogr_all
FROM SERVER fdw_ogr_ign_parc
INTO test_wfs
OPTIONS (
    -- mettre le nom des tables en minuscule et sans caractères bizares
    launder_table_names 'true',
    -- mettre le nom des champs en minuscule
    launder_column_names 'true'
)

Aucun problème, donc j'en déduis que le message passe bien entre mon serveur et celui de l'ign. Je récupere les 17 table étrangeres et tout semble bien aller.
Parce contre toujours impossible de requeter. Si je lance le petit extent (celui de 3 secondes), alors ça mouline pendant.... pas mal de temps. et au final je fini avec une erreur 504.

Parmi les pistes que j'ai pour l'instant :
- J'ai sur ce serveur : Vmap, Geoserver, et postgis. J'ai mis le mois dernier un certif SSL avec un nom de domaine qui pointe dessus.
Est-ce que ça peut avoir une influence? J'aurai dit que non car le serveur communique bien avec celui de l'ign, (A moins qu'il s'agisse de deux ports/protocoles différents?)
- mon ip est associé à un chargement de toutes les parcelles du flux depuis 1 semaine . Ou est blacklisté.

Je continue mes recherches mais j'avoue ne pas trop savoir vers quoi regarder.

Bonjour

Chez moi:

[2023-09-29 11:24:54] 49 rows affected in 3 s 459 ms


Nicolas

bonjour à tous, bon alors j'ai testé pas mal de chose sans grande réussite pour essayer d'expliquer le pourquoi ça n'avance pas.

Du coup j'en suis arrivé à ogr2ogr shp fws.

L'idée est de voir si l'import d'une petite partie de la base fonctionne.
Je cherche donc à lancer ça :

ogr2ogr "/home/user/a.shp" "WFS:https://wxs.ign.fr/parcellaire/geoportail/wfs?SERVICE=WFS&REQUEST=GetFeature&VERSION=2.0.0&TYPENAMES=CADASTRALPARCELS.PARCELLAIRE_EXPRESS:parcelle&STARTINDEX=0&COUNT=1000000&SRSNAME=EPSG:4326&BBOX=1.443463,43.591762,1.446831,43.593707"

Mais il va systématiquement chercher toutes les couches dans l'ordre du flux, comme si mon &TYPENAMES n'était pas pris en compte. Vous sauriez comment trouvé la requete ogr2 précise qui est lancée par l'extension postgis_fdw? ça me faciliterai la tache afin de voir ce qui se passe exactement et découvrir d'où vient cette fameuse lenteur...

Dernière modification par alextaz44 (Mon 09 October 2023 16:31)

Bon j'ai finalement réussi je crois à utiliser ogr2ogr pour télécharger une couche mais pour la couche ign ça me fais des truc bizarre, il fini toujours par vouloir télécharger toutes les couches du flux les une après les autres.

Et du coup j'avais une question pour les gens qui connaissent bien le truc : l'extension ogr_fdw elle s'appui sur sa propre librairie ogr/gdal ou elle utilise la sienne?
Je demande ça car je viens de voir que ma version gdal est assez ancienne :

gdalinfo --version
GDAL 2.4.0, released 2018/12/14

Ca pourrait jouer sur la lenteur du truc vous pensez? Je peux réinstaller une version de gdal sans "dommages". Il semble que sur debian on ne peux pas faire un simple update de gdal, il faut le reinstaller par dessus.

Sous debian, vous pouvez facilement tester la version que vous voulez de GDAL (notamment la plus récente, avec TOUS les formats compilés) en passant par une image Docker: https://github.com/OSGeo/gdal/pkgs/container/gdal

Nicolas