Message posté par : preliator
----------------------------------------
Bonjour,
Je dispose d'une table répertoriant l'ensemble des parcelles cadastrales de la France. Une des colonnes de la table (nommée "dep") renseigne sur le numéro de département dans lequel se situe chaque parcelle.
Je voudrais exporter cette table au format .sql, mais en plusieurs blocs. L'idée, c'est d'avoir autant de fichier .sql qui y a de modalité dans "dep", et chaque fichier comporterait l'ensemble des parcelles contenues dans le département qui lui est associé.
L'objectif, c'est simplement de ne pas avoir à restaurer les dizaines de millions de parcelles de la table systématiquement, mais de choisir juste le département dont j'ai besoin.
J'ai commencé à regarder du côté de psql ou pg_dump, sans parvenir à trouver une solution. Est-il possible de faire cela ?
Merci.
----------------------------------------
Le message est situé https://georezo.net/forum/viewtopic.php?pid=338873#p338873
Pour y répondre : geobd(a)ml.georezo.net ou reply de votre messagerie
Pour vous désabonner connectez-vous sur le forum puis Profil / Abonnement
--
Association GeoRezo - le portail géomatique
https://georezo.net
Message posté par : Léandre Béron
----------------------------------------
Bonjour,
Je souhaiterais à l'aide d'un trigger, lors d'une suppression d'un objet linéaire, supprimer également tous les objets d'une table de correspondance où une clé étrangère donne sur mon objet linéaire.
an_voie : des noms de voie.
an_section_voie : Table de correspondance entre mes linéaires et une ou plusieurs voie associée.
(Un linéaire peut en effet avoir une ou plusieurs voie liée, une association N,N dans un MCD)
geo_section_voie : Mes linéaires
A la suppression d'un linéaire de voie, je dois également supprimer tous les objets dans la table an_section_voie qui ont une valeur de mon ID de geo_section_voie.
En faisant un AFTER DELETE, je n'arrive pas à récupérer mon ID de mon linéaire.
En faisant un BEFORE DELETE, je n'ai pas non plus réussi...
Voilà mon code ci-dessous.
Ne vous préoccuper pas de la première partie, qui recalcule la longueur de la voie suite à une suppression d'objets dans la table de correspondance.
-----------------
Citation :
CREATE FUNCTION rva.delete_calcul_longueur_voie() RETURNS trigger AS $BODY$
DECLARE
v_long_delete real;
v_id_delete integer;
begin
IF (TG_TABLE_NAME = 'an_section_voie') THEN
SELECT longueur FROM rva.an_voie WHERE id_voie = OLD.id_voie INTO v_long_delete;
-- on recalcul la longueur avec le OLD.idvoie
v_id_delete := OLD.id_voie; -- on récupère ancien id_voie associé
v_long_delete := v_long_delete - (SELECT sum(st_length(s.geom)) FROM rva.geo_section_voie s, rva.an_section_voie sv
WHERE sv.id_sectvoi = OLD.id_sectvoi AND s.id_section = sv.id_section);
IF v_long_delete IS null THEN -- si null on met 0 (nécessaire car le null emporte sur le 0 sur l'opération v_long_old au dessus)
v_long_delete := 0;
END IF;
UPDATE rva.an_voie SET longueur = v_long_delete WHERE id_voie = v_id_delete;
END IF;
-- marche pas ça...
IF (TG_TABLE_NAME = 'geo_section_voie') THEN
DELETE FROM rva.an_section_voie WHERE id_section = OLD.id_section;
END IF;
return NEW;
end;
$BODY$ LANGUAGE plpgsql;
-----------------
Et les triggers associés à cette fonction :
-----------------
Citation :
CREATE TRIGGER tr_calc_voies3 BEFORE DELETE ON rva.an_section_voie
FOR EACH ROW EXECUTE PROCEDURE rva.delete_calcul_longueur_voie();
-- lui ne marche pas..
CREATE TRIGGER tr_calc_voies4 BEFORE DELETE ON rva.geo_section_voie
FOR EACH ROW EXECUTE PROCEDURE rva.delete_calcul_longueur_voie();
-----------------
Visiblement un besoin simple, que je n'arrive pas à faire....
Egalement, si je supprime les objets dans cette table de correpondance, est-ce que ma première partie de ma fonction trigger va se réaliser (sachant que pour chaque suppression d'objets dans la table an_section_voie, je lance cette procédure) ?
En espérant avoir été compréhensible dans ma demande :)
Merci d'avance
Léandre
----------------------------------------
Le message est situé https://georezo.net/forum/viewtopic.php?pid=338629#p338629
Pour y répondre : geobd(a)ml.georezo.net ou reply de votre messagerie
Pour vous désabonner connectez-vous sur le forum puis Profil / Abonnement
--
Association GeoRezo - le portail géomatique
https://georezo.net
Message posté par : Tomapinfo (numerobisco04(a)hotmail.fr)
----------------------------------------
Bonjour,
J'essaye de reproduire un trigger qui fonctionne bien dans PostgreSQL/Postgis dans Oracle.
Le trigger remonte des informations lors de la saisie ou de la modification.
-----------------
Code :
CREATE OR REPLACE FUNCTION x.champs_auto()
RETURNS trigger AS
$BODY$BEGIN
NEW.num_insee = x.communes.num_insee FROM x.communes WHERE st_intersects(NEW.geom, x.communes.geom);
RETURN NEW;
END$BODY$
LANGUAGE plpgsql VOLATILE
COST 100;
-----------------
Mais dans Oracle, l'ecriture n'est pas identique et au mieux j'ai réussi à faire ça.
-----------------
Code :
CREATE OR REPLACE TRIGGER "DBO"."Cps_auto_I" BEFORE INSERT --
ON Y --
FOR EACH ROW --
declare INSEE VARCHAR2(20) DEFAULT '';
Begin --
Select b.NUM_INSEE into INSEE from ua b WHERE SDO_RELATE(:NEW.GEOMETRIE,b.GEOMETRIE,'mask=INSIDE') = 'TRUE' and b.SOUS_TYPE = 'COMMUNES';
:NEW.NUM_INSEE := INSEE ;
;
End;
-----------------
Mais j'obtiens cette erreur alors que j'ai bien un index sur les 2 tables.
-----------------
Citation :
Erreur SQL : ORA-13226: interface non prise en charge sans index spatial
-----------------
Je penses donc que l'objet n'est pas encore enregistré et donc pas dans l'Index.
Car le select seul fonctionne bien.
Au vue de ce message je me demande s'il y est vraiment possible de faire se genre de requête dans un trigger ?
Si cela est possible avez-vous une idée pour le corriger ?
Merci par avance.
----------------------------------------
Le message est situé https://georezo.net/forum/viewtopic.php?pid=335958#p335958
Pour y répondre : geobd(a)ml.georezo.net ou reply de votre messagerie
Pour vous désabonner connectez-vous sur le forum puis Profil / Abonnement
--
Association GeoRezo - le portail géomatique
https://georezo.net
Message posté par : preliator
----------------------------------------
Bonjour,
Je suis étudiant en Master géomatique, et j'aimerais avoir accès aux fichiers fonciers MAJIC anonymisés dans le cadre d'un travail en lien avec la formation. Est-ce que je suis en droit d'obtenir cette donnée gratuitement ?
Merci.
----------------------------------------
Le message est situé https://georezo.net/forum/viewtopic.php?pid=338575#p338575
Pour y répondre : geobd(a)ml.georezo.net ou reply de votre messagerie
Pour vous désabonner connectez-vous sur le forum puis Profil / Abonnement
--
Association GeoRezo - le portail géomatique
https://georezo.net
Message posté par : preliator
----------------------------------------
Bonjour,
Jusqu'à présent, je stockais mes bases de données dans un SSD (Sabrent 1TB), qui est aussi mon disque C. Au fil du temps, mes BDD prenaient trop de place, et j'ai aujourd'hui décidé de les stocker dans un disque dur interne (Seagate BarraCuda 4 To, SATA 6 Gbit/s 5400 tr/min).
Concernant les requêtes, j'ai l'impression d'avoir un temps d'exécution similaire pour les petites tables (< 2 millions d'entrées). En revanche, le temps double pour les plus grosses (> 15 millions d'entrées), et j'ai mis une dizaine d'heure à les importer dans Postgre.
Est-ce que passer du SSD au disque dur inclue forcément une baisse de performance dans les requêtes ? Quels types de SSD utilise t-on le plus souvent pour optimiser le stockage et les requêtes ?
Merci.
----------------------------------------
Le message est situé https://georezo.net/forum/viewtopic.php?pid=338569#p338569
Pour y répondre : geobd(a)ml.georezo.net ou reply de votre messagerie
Pour vous désabonner connectez-vous sur le forum puis Profil / Abonnement
--
Association GeoRezo - le portail géomatique
https://georezo.net
Message posté par : Pegasus555 (archiinfo2011(a)gmail.com)
----------------------------------------
Bonjour,
Je travaille actuellement sur la plateforme open source GAMA. J'utilise une BD créée sur PostgreSQL et le code contient des requêtes géographiques utilisant PostGIS intégrés dans un algorithme génétique (plus précisement pour évaluer les individus)
J'ai exécuté le même code (avec les mêmes paramètres) sur deux machines :
Machine 1 : un I5 2eme génération 2.7 GHz (2 coeurs) / 4 Go de RAM / disque dur HDD/ windows 7 32 bits
Machine 2 : I7 7eme 2.9 GHz (avec turbo Boost 3.5GHz) / 24 Go de RAM / SSD / Win 10 64 bits
Je n'arrive pas a expliquer une chose : bien que la 2eme machine est plus puissante, le temps d'exécution est le même sur les deux machines et parfois la 2eme machine est plus lente.
J'ai bien modifié les paramètres de PostgreSQL (https://public.dalibo.com/exports/formation/manuels/formations/perf1/perf1.…) selon ma machine mais rien n'y change.
Du coté de la plateforme, idem, j'ai modifié les paramètres qu'il fallait.
Avez vous une idée d'où vient le problème ?
----------------------------------------
Le message est situé https://georezo.net/forum/viewtopic.php?pid=338524#p338524
Pour y répondre : geobd(a)ml.georezo.net ou reply de votre messagerie
Pour vous désabonner connectez-vous sur le forum puis Profil / Abonnement
--
Association GeoRezo - le portail géomatique
https://georezo.net
Message posté par : Nicolas Ribot
----------------------------------------
Bonjour,
Ca dépend du format: si ce sont des dumps SQL, oui on doit pouvoir tout mettre dans un seul fichier, mais pourquoi ?
en ligne de commande, la restauration de 4 fichiers SQL est rapide:
-----------------
Code :
psql -d database -U user -f fichier.sql
-----------------
(si les fichiers sont au format PG Dump, il faut utiliser l'outil pg_restore)
Nicolas
----------------------------------------
Le message est situé https://georezo.net/forum/viewtopic.php?pid=338433#p338433
Pour y répondre : geobd(a)ml.georezo.net ou reply de votre messagerie
Pour vous désabonner connectez-vous sur le forum puis Profil / Abonnement
--
Association GeoRezo - le portail géomatique
https://georezo.net
Message posté par : Seydi Aliou Tall
----------------------------------------
Bonjour
Je suis nouveau sur postgres
Je dispose de quatre fichiers de sauvegardes
Je voulais faire une restauration sur pgadmin 3
Je demandais à savoir s'il est possible d'en faire un seul fichier et le restaurer?
Merci
----------------------------------------
Le message est situé https://georezo.net/forum/viewtopic.php?pid=338412#p338412
Pour y répondre : geobd(a)ml.georezo.net ou reply de votre messagerie
Pour vous désabonner connectez-vous sur le forum puis Profil / Abonnement
--
Association GeoRezo - le portail géomatique
https://georezo.net
Message posté par : hadri45
----------------------------------------
Bonjour,
Je dois réaliser des croisements de couches forestières afin d'enrichir la base de données des Forêts officielle. Pour cette opération, le mieux est d'utiliser la fonction Union d'ArcGIS mais j'ai l'obligation de réaliser cela sous Postgres/PostGIS. Pour se faire, j'ai donc vu qu'il fallait réaliser cela en 2 étapes avec d'abord l'intersection pour les deux couches qui s'intersectent puis avec INSERT INTO, récupérer celle qui ne s'intersecte pas avec le ST_DIFFERENCE.
Voici le code où je dois réaliser deux croisements tout en gardant les attributs (code_psg,code_onf et tfv) pour des analyses complémentaires.
Ce code me donne le bon résultat mais vu que je dois réaliser ce traitement pour la France entière il me faut l'optimiser le plus possible sachant que sur un département cela prend plus de 2h30 alors que sur ArcGIS le traitement prend 4 minutes.
-----------------
Code :
-- TABLE DU CROISEMENT PRO / PSG
DROP TABLE IF EXISTS surface_unitaire_01.propsg_01;
-- 1. Intersection
CREATE TABLE surface_unitaire_01.propsg_01 AS
SELECT o.code_onf, p.code AS code_psg, ST_SetSRID((ST_Dump(ST_Intersection(o.geom, p.geom))).geom, 932006) AS geom
FROM surface_unitaire_01.pro_2018_simple_01 o
INNER JOIN surface_unitaire_01.psg_2018_simple_01 p ON (o.geom && p.geom AND ST_Intersects(o.geom, p.geom));
-- Nettoyage des géométries invalides
DELETE FROM surface_unitaire_01.propsg_01 WHERE ST_GeometryType(geom) != 'ST_Polygon';
CREATE INDEX sp_idx_propsg_01_geom ON surface_unitaire_01.propsg_01 USING GIST (geom);
ANALYZE surface_unitaire_01.propsg_01;
-- 2. Différences PRO - PSG et PSG - PRO
CREATE TEMP TABLE pro_union AS
SELECT code_onf, ST_Union(geom) AS geom
FROM surface_unitaire_01.propsg_01
GROUP BY code_onf;
CREATE INDEX sp_idx_pro_union_geom ON pro_union USING GIST (geom);
ANALYZE pro_union;
CREATE TEMP TABLE psg_union AS
SELECT code_psg, ST_Union(geom) AS geom
FROM surface_unitaire_01.propsg_01
GROUP BY code_psg;
CREATE INDEX sp_idx_psg_union_geom ON psg_union USING GIST (geom);
ANALYZE psg_union;
DROP INDEX surface_unitaire_01.sp_idx_propsg_01_geom;
INSERT INTO surface_unitaire_01.propsg_01
SELECT o.code_onf, NULL::VARCHAR(3) AS code_psg, (ST_Dump(ST_Difference(o.geom, ST_SetSRID(COALESCE(t1.geom, 'GEOMETRYCOLLECTION EMPTY'::GEOMETRY), 932006)))).geom AS geom
FROM surface_unitaire_01.pro_2018_simple_01 o
LEFT JOIN pro_union t1 ON o.code_onf = t1.code_onf
UNION
SELECT NULL::VARCHAR(3) AS code_onf, p.code AS code_psg, (ST_Dump(ST_Difference(p.geom, ST_SetSRID(COALESCE(t2.geom, 'GEOMETRYCOLLECTION EMPTY'::GEOMETRY), 932006)))).geom AS geom
FROM surface_unitaire_01.psg_2018_simple_01 p
LEFT JOIN psg_union t2 ON p.code = t2.code_psg;
-- Nettoyage des géométries invalides
SELECT DISTINCT ST_GeometryType(geom) FROM surface_unitaire_01.propsg_01;
SELECT DISTINCT ST_SRID(geom) FROM surface_unitaire_01.propsg_01;
SELECT COUNT(*) FROM surface_unitaire_01.propsg_01 WHERE NOT ST_IsValid(geom);
DELETE FROM surface_unitaire_01.propsg_01 WHERE ST_GeometryType(geom) != 'ST_Polygon';
CREATE INDEX sp_idx_propsg_01_geom ON surface_unitaire_01.propsg_01 USING GIST (geom);
ANALYZE surface_unitaire_01.propsg_01;
DROP TABLE pro_union;
DROP TABLE psg_union;
-- contrôles de surfaces
SELECT 'couche onf' AS origine, code_onf, SUM(ST_Area(geom)) AS surface_total
FROM surface_unitaire_01.pro_2018_simple_01
GROUP BY origine, code_onf
UNION
SELECT 'croisement' AS origine, code_onf, SUM(ST_Area(geom)) AS surface_total
FROM surface_unitaire_01.propsg_01
GROUP BY origine, code_onf
ORDER BY code_onf, origine;
SELECT 'couche psg' AS origine, code AS code_psg, SUM(ST_Area(geom)) AS surface_total
FROM surface_unitaire_01.psg_2018_simple_01
GROUP BY origine, code_psg
UNION
SELECT 'croisement' AS origine, code_psg, SUM(ST_Area(geom)) AS surface_total
FROM surface_unitaire_01.propsg_01
GROUP BY origine, code_psg
ORDER BY code_psg, origine;
SELECT DISTINCT st_geometrytype(geom)
FROM surface_unitaire_01.bd_foret_01_simple
SELECT id_foret, ST_NPoints(geom), ST_MemSize(geom)
FROM surface_unitaire_01.bd_foret_01_simple
ORDER BY ST_NPoints DESC;
SELECT COUNT(*), COUNT(*) FILTER (WHERE ST_MemSize(geom) > 8192)
FROM surface_unitaire_01.bd_foret_01_simple;
CREATE TABLE surface_unitaire_01.bd_foret_01_simple_sub AS
SELECT id_foret, tfv, ST_SubDivide(geom) AS geom
FROM surface_unitaire_01.bd_foret_01_simple;
CREATE INDEX idx_foret_geom_sub_01 ON surface_unitaire_01.bd_foret_01_simple_sub USING GIST (geom);
CREATE TABLE surface_unitaire_01.propsg_01_sub
AS SELECT ST_SUBDIVIDE(geom) as geom, code_onf,code_psg
FROM surface_unitaire_01.propsg_01
-- TABLE DU CROISEMENT BD_FORET / PRO_PSG
DROP TABLE IF EXISTS surface_unitaire_01.final_cedric_01;
-- 1. Intersection
CREATE TABLE surface_unitaire_01.final_cedric_01 AS
SELECT p.code_onf, p.code_psg, b.tfv, ST_SetSRID((ST_Dump(ST_Intersection(ST_Buffer(p.geom, 0.0000001), b.geom))).geom, 932006) AS geom
FROM surface_unitaire_01.propsg_01 p
INNER JOIN surface_unitaire_01.bd_foret_01_simple_sub b ON (p.geom && b.geom AND ST_Intersects(p.geom, b.geom));
-- Nettoyage des géométries invalides
SELECT DISTINCT ST_GeometryType(geom) FROM surface_unitaire_01.final_cedric_01;
DELETE FROM surface_unitaire_01.final_cedric_01 WHERE ST_GeometryType(geom) != 'ST_Polygon';
CREATE INDEX sp_idx_final_cedric_01_geom ON surface_unitaire_01.final_cedric_01 USING GIST (geom);
ANALYZE surface_unitaire_01.final_cedric_01;
-- 2. Différences BD_FORET - PRO_PSG et PRO_PSG - BD_FORET
DROP TABLE IF EXISTS pro_psg;
CREATE TEMP TABLE pro_psg AS
SELECT code_onf, code_psg,geom
FROM surface_unitaire_01.final_cedric_01;
CREATE INDEX sp_idx_pro_psg_geom ON pro_psg USING GIST (geom);
ANALYZE pro_psg;
DROP TABLE IF EXISTS tfv;
CREATE TEMP TABLE tfv AS
SELECT tfv, geom
FROM surface_unitaire_01.final_cedric_01;
CREATE INDEX sp_idx_tfv_geom ON tfv USING GIST (geom);
ANALYZE tfv;
DROP INDEX surface_unitaire_01.sp_idx_final_cedric_01_geom;
INSERT INTO surface_unitaire_01.final_cedric_01
SELECT p.code_onf, p.code_psg, NULL::VARCHAR(10) AS tfv, (ST_Dump(ST_Difference(p.geom, ST_SetSRID(COALESCE(t1.geom, 'GEOMETRYCOLLECTION EMPTY'::GEOMETRY), 932006)))).geom AS geom
FROM surface_unitaire_01.propsg_01_sub p
LEFT JOIN pro_psg as t1 ON p.code_onf = t1.code_onf AND p.code_psg = t1.code_psg
UNION
SELECT NULL::VARCHAR(3) AS code_onf, NULL::VARCHAR(3) AS code_psg, t.tfv, (ST_Dump(ST_Difference(t.geom, ST_SetSRID(COALESCE(t2.geom, 'GEOMETRYCOLLECTION EMPTY'::GEOMETRY), 932006)))).geom AS geom
FROM surface_unitaire_01.bd_foret_01_simple_sub t
LEFT JOIN tfv t2 ON t.tfv = t2.tfv;
CREATE INDEX sp_idx_final_cedric_01_geom ON surface_unitaire_01.final_cedric_01 USING GIST (geom);
ANALYZE surface_unitaire_01.propsg_01;
DROP TABLE pro_psg_union;
DROP TABLE IF EXISTS tfv_union;
DROP TABLE tfv;
-----------------
J'ai donc essayé de subdiviser ce qui accélère les temps de traitements mais le plus gros problème reste le dernier ST_DIFFERENCE entre la bd_foret et pro_psg qui est toujours aussi long malgré cette subdivision et ne permet pas de valider le code. J'ai également essayé de transformer les géométries en tuile (MapVector Tile) avec ST_ASMVTGeom mais cela est encore plus long. J'ai également essayé de faire sans le ST_UNION ou ST_COLLECT mais cela ne change pas beaucoup le temps de traitement.
Ma couche principale est de l'ordre de plus de 25000 entités et les autres couches à croiser sont autour de 2000.
Pour la configuration, je suis sous PostgreSQL 12 et PostGIS 3.0.
Auriez-vous donc une idée afin d'optimiser le traitement ?
Merci,
----------------------------------------
Le message est situé https://georezo.net/forum/viewtopic.php?pid=335210#p335210
Pour y répondre : geobd(a)ml.georezo.net ou reply de votre messagerie
Pour vous désabonner connectez-vous sur le forum puis Profil / Abonnement
--
Association GeoRezo - le portail géomatique
https://georezo.net
Message posté par : Nicolas Ribot
----------------------------------------
Bonsoir,
PG en tant que tel n'est pas outillé pour accéder à des URL, des API.
Mais il supporte de nombreux langages qui permettent ces accès, à travers des fonctions écrites dans ces langages.
Une solution classique est de développer un serveur d'application (java, javascript, python, php, ...) qui fait les accès à l'API et le lien vers PG/Pgis pour stocker ou manipuler les données.
Je préfère souvent une solution intégrée à PG, soit à travers une fonction qui réalise les accès, soit à travers un FDW (foreign data wrapper). Je vous laisse regarder le FDW Unicorn, par ex, qui permet en python de développer une interface entre le service et PG, permettant d'accèder à l'API à travers du sql (select * from foreign_table_qui_appelle_lapi).
Ca se met en place assez facilement et convient bien si ces appels à l'API doivent etre nombreux et/ou fréquents.
Il existe aussi des FDW génériques qui savent "taper" sur une API ou un web service avec un peu de conf.
Avec une fonction, c'est encore plus simple: vous développez la fonction (par ex en python, langage vraiment pratique pour manipuler les données et disposant de nombreuses API) qui appelle l'API et traite les données.
Voici un exemple de fonction permettant de géocoder des adresses dans PG. Elle se base sur le geocodeur en ligne BANO, prend une requete SQL formatée avec certaines colonnes (rue, num, ville, cp, ...), transmet ces données à l'API du geocodeur, récupère les données (format CSV), les convertit en JSON et les renvoie à PG.
La concision du code Python pour faire tout cela (ca doit pouvoir etre bien plus concis: je suis nul en python...) est remarquable je trouve.
(le code execute la requête passée en param, formate le tout en CSV (en mémoire), puis envoie ce CSV sur l'URL du geocodeur.
Le résultat (CSV) est converti en JSON et renvoyé par la fonction: on peut alors convertir les info JSON en geométries postgis.)
-----------------
Code :
create or replace function geocode_add(query text)
RETURNS setof jsonb as
$$
import csv
import io
from collections import OrderedDict
import requests
import json
with io.BytesIO(b"") as stream:
writer = csv.writer(stream, delimiter=',', quotechar='"', quoting=csv.QUOTE_MINIMAL)
writer.writerow(["ids", "voie", "ville", "cp"])
for row in plpy.cursor(query):
# writes row in csv to csv stream
# Write CSV Header, If you dont need that, remove this line
writer.writerow([row['ids'], row['voie'], row['ville'], row['cp']])
requests_session = requests.Session()
kwargs = {
'data': OrderedDict([
('columns', ['voie', 'ville', 'cp']),
('postcode', 'cp')
]),
'method': 'post',
'files': OrderedDict([
('data', ('addpg.csv',stream.getvalue()))
]),
'stream': True,
'url': 'https://api-adresse.data.gouv.fr/search/csv/'
}
response = requests_session.request(**kwargs)
for row in csv.DictReader(response.text.encode('utf-8').splitlines()):
yield json.dumps(row)
$$ language plpythonu VOLATILE;
-----------------
Elle s'utilise comme cela:
-----------------
Code :
select * from geocode_add('select array_agg(s.id) as ids, voie, ville, cp from table_adresse');
-----------------
Nicolas
----------------------------------------
Le message est situé https://georezo.net/forum/viewtopic.php?pid=337775#p337775
Pour y répondre : geobd(a)ml.georezo.net ou reply de votre messagerie
Pour vous désabonner connectez-vous sur le forum puis Profil / Abonnement
--
Association GeoRezo - le portail géomatique
https://georezo.net