Le portail francophone de la géomatique

Bonsoir,

Avez-vous regardé les droits des fichiers rasters et répertoires:
le message d'erreur est clair: raster2pgsql ne voit pas le fichier raster en question.
Est-ce que GDAL arrive a lire ces rasters ?

Je ne suis pas sur de comprendre ce que vous voulez produire en sortie. Les 17k rasters couvrent la meme zone ou ils représentent une mosaique et vous voulez les 17000 valeurs sous chaque pixel ?
Si c'est juste calculer des valeurs en chaque pixel des raster, vous irez plus vite avec GDAL directement (ou GRASS aussi, mais je connais moins).

Un petit exemple serait le bienvenu

Nicolas

Bonjour,

Perso, je resterai avec un format raster pour cela, qui gère les séries temporelles (ou Lidar/pointcloud), avec un array de 17000 valeurs par pixels
(si vous faites ca sous pg, créez une colonne de type array[int] contenant les 17000 valeurs par pixel plutot que 17000 colonnes ! ca sera inutilisable sinon.)

Je vois que GRASS a un module pour les séries temporelles: https://grasswiki.osgeo.org/wiki/Tempor … processing

Quelles sont l'extension et la résolution des rasters ? (combien de pixels au final ?)

Nicolas

Merci pour ces précisions.

Sans demander trop de détail sur l'appli, le fait que ce soit une appli web ne veut pas dire que seule des données venant de pg peuvent etre traitées

On peut imaginer un service web qui renvoie les valeurs correspondant à un pixel ou un ensemble de pixels envoyés par le client apres avoir lancé une commande gdal ou grass pour avoir la synthese des valeurs aux points demandés.

Sur une base PG, la volumétrie finale serait de 460 477 500 de points dans la table, ce qui n'est pas choquant: un serveur bien dimensionné sait très bien gérer ce volume. Une colonne de type array[float] de 17000 valeurs serait aussi gérable il me semble (et indexable)
D'autres structures plus complexes peuvent etre envisagées, comme du jsonb qui permet de gérer plusieurs attributs pour un meme point. (compressé et indexable aussi).

Une autre solution que je vois est de passer par pointCloud (https://github.com/pgpointcloud/pointcloud) et son extension spatiale: ca m'a l'air tout indiqué pour ce genre de données. Vous pourrez faire des requêtes spatiales comme avec des données géo classiques.
L'avantage que j'y vois est la scalabilité: cette extension est faite pour gérer des milliards ou centaines de milliards de points portant chacun potentiellement des centaines d'information.

Nicolas

Disons que mon objectif c'est d'avoir pour une zone données une moyenne pour chaque attribut (un instant t), un tableau simple au finale, pour l'affichage d'une courbe sur notre interface web. L'utilisateur spécifie la zone, les statistiques sur celle-ci se font au sein du serveur, et lui retourne les résultat sous forme de courbe. J'ai peur qu'en utilisant GDAL ou GRASS, et du coup en traitant du raster, la requête prenne trop de temps et fasse fuir nos utilisateurs. C'est pour ça que je vois plutôt cette information en vecteur.
Du coup on s'est entendu avec le dev web de ma boîte pour que je lui créé une fonction SQL avec comme paramètre les informations permettant de définir la zone à résumé et ressort un JSON que lui récupère pour générer sa courbe.

Je vais essayer de créer le maillage de point avec l'attribut array au sein de GRASS et importé cette donnée au sein de ma base, vu que GRASS ne peux exporter vers une base de données que du vecteur (si je ne me trompe pas)

Pour ce qui est des versions (merci pour la requête ) voilà  le retour :
POSTGIS="2.2.1 r14555"
GEOS="3.5.1-CAPI-1.9.1 r4246"
PROJ="Rel. 4.9.2, 08 September 2015"
GDAL="GDAL 1.11.3, released 2015/09/16"
LIBXML="2.9.3"
LIBJSON="0.11.99" RASTER