Depuis quelques temps, j’utilise les VRT et je constate de très grosses lenteurs dans le traitement - plusieurs limites, limite freezing.
Pour préciser le type de traitement, je croise deux couches de données, l’une de 35000 lignes et l’autre de 1000 environ en générant des géométries (lignes sur la base de 2 points).
Suis-je le seul à constater de telles lenteurs ? D’autres retours sur le sujet ?
Je travaille sur Ubuntu avec la 3.12. J’avais les mêmes impressions avec la 3.10 et avant.
Depuis quelques temps, j’utilise les VRT et je constate de très grosses lenteurs dans le traitement - plusieurs limites, limite freezing.
Pour préciser le type de traitement, je croise deux couches de données, l’une de 35000 lignes et l’autre de 1000 environ en générant des géométries (lignes sur la base de 2 points).
Suis-je le seul à constater de telles lenteurs ? D’autres retours sur le sujet ?
Je travaille sur Ubuntu avec la 3.12. J’avais les mêmes impressions avec la 3.10 et avant.
SELECT CODGEO, LIBGEO, DCLT, L_DCLT, NBFLUX_C16_ACTOCC15P, make_line(a.geometry, b.geometry) FROM flux LEFT JOIN CHEF_LIEU a ON flux.CODGEO = a.INSEE_COM LEFT JOIN CHEF_LIEU b ON flux.DCLT = b.INSEE_COM WHERE a.INSEE_COM != b.INSEE_COM
Depuis quelques temps, j’utilise les VRT et je constate de très grosses lenteurs dans le traitement - plusieurs limites, limite freezing.
Pour préciser le type de traitement, je croise deux couches de données, l’une de 35000 lignes et l’autre de 1000 environ en générant des géométries (lignes sur la base de 2 points).
Suis-je le seul à constater de telles lenteurs ? D’autres retours sur le sujet ?
Je travaille sur Ubuntu avec la 3.12. J’avais les mêmes impressions avec la 3.10 et avant.
OK, et ben sans connaitre tes sources de données, mais la première piste est que tu dois manquer d’indexation sur le code commune , et donc tu relis les sources de données à chaque fois.
C’est quoi comme donnée?
ça pourrait s’envoyer dans une base de données?
Est-ce que la même requête en couche virtuelle via DB manager va plus vite?
SELECT CODGEO, LIBGEO, DCLT, L_DCLT, NBFLUX_C16_ACTOCC15P, make_line(a.geometry, b.geometry) FROM flux LEFT JOIN CHEF_LIEU a ON flux.CODGEO = a.INSEE_COM LEFT JOIN CHEF_LIEU b ON flux.DCLT = b.INSEE_COM WHERE a.INSEE_COM != b.INSEE_COM
Depuis quelques temps, j’utilise les VRT et je constate de très grosses lenteurs dans le traitement - plusieurs limites, limite freezing.
Pour préciser le type de traitement, je croise deux couches de données, l’une de 35000 lignes et l’autre de 1000 environ en générant des géométries (lignes sur la base de 2 points).
Suis-je le seul à constater de telles lenteurs ? D’autres retours sur le sujet ?
Je travaille sur Ubuntu avec la 3.12. J’avais les mêmes impressions avec la 3.10 et avant.
Le problème me semble assez distinct mais pointe peut-être la faiblesse du format (?) - voir aussi la doc.
Régis, je travaille sur la base admin-express (chef lieu) et une bdd CSV issue de l’INSEE. Ca pourrait partir en BDD mais alors, je ne sais pas si je gagnerai du temps au final.
OK, et ben sans connaitre tes sources de données, mais la première piste est que tu dois manquer d’indexation sur le code commune , et donc tu relis les sources de données à chaque fois.
C’est quoi comme donnée?
ça pourrait s’envoyer dans une base de données?
Est-ce que la même requête en couche virtuelle via DB manager va plus vite?
SELECT CODGEO, LIBGEO, DCLT, L_DCLT, NBFLUX_C16_ACTOCC15P, make_line(a.geometry, b.geometry) FROM flux LEFT JOIN CHEF_LIEU a ON flux.CODGEO = a.INSEE_COM LEFT JOIN CHEF_LIEU b ON flux.DCLT = b.INSEE_COM WHERE a.INSEE_COM != b.INSEE_COM
Depuis quelques temps, j’utilise les VRT et je constate de très grosses lenteurs dans le traitement - plusieurs limites, limite freezing.
Pour préciser le type de traitement, je croise deux couches de données, l’une de 35000 lignes et l’autre de 1000 environ en générant des géométries (lignes sur la base de 2 points).
Suis-je le seul à constater de telles lenteurs ? D’autres retours sur le sujet ?
Je travaille sur Ubuntu avec la 3.12. J’avais les mêmes impressions avec la 3.10 et avant.
Le problème me semble assez distinct mais pointe peut-être la faiblesse du format (?) - voir aussi la doc.
Régis, je travaille sur la base admin-express (chef lieu) et une bdd CSV issue de l’INSEE. Ca pourrait partir en BDD mais alors, je ne sais pas si je gagnerai du temps au final.
OK, et ben sans connaitre tes sources de données, mais la première piste est que tu dois manquer d’indexation sur le code commune , et donc tu relis les sources de données à chaque fois.
C’est quoi comme donnée?
ça pourrait s’envoyer dans une base de données?
Est-ce que la même requête en couche virtuelle via DB manager va plus vite?
SELECT CODGEO, LIBGEO, DCLT, L_DCLT, NBFLUX_C16_ACTOCC15P, make_line(a.geometry, b.geometry) FROM flux LEFT JOIN CHEF_LIEU a ON flux.CODGEO = a.INSEE_COM LEFT JOIN CHEF_LIEU b ON flux.DCLT = b.INSEE_COM WHERE a.INSEE_COM != b.INSEE_COM
Depuis quelques temps, j’utilise les VRT et je constate de très grosses lenteurs dans le traitement - plusieurs limites, limite freezing.
Pour préciser le type de traitement, je croise deux couches de données, l’une de 35000 lignes et l’autre de 1000 environ en générant des géométries (lignes sur la base de 2 points).
Suis-je le seul à constater de telles lenteurs ? D’autres retours sur le sujet ?
Je travaille sur Ubuntu avec la 3.12. J’avais les mêmes impressions avec la 3.10 et avant.
Le problème me semble assez distinct mais pointe peut-être la faiblesse du format (?) - voir aussi la doc.
Régis, je travaille sur la base admin-express (chef lieu) et une bdd CSV issue de l’INSEE. Ca pourrait partir en BDD mais alors, je ne sais pas si je gagnerai du temps au final.
OK, et ben sans connaitre tes sources de données, mais la première piste est que tu dois manquer d’indexation sur le code commune , et donc tu relis les sources de données à chaque fois.
C’est quoi comme donnée?
ça pourrait s’envoyer dans une base de données?
Est-ce que la même requête en couche virtuelle via DB manager va plus vite?
SELECT CODGEO, LIBGEO, DCLT, L_DCLT, NBFLUX_C16_ACTOCC15P, make_line(a.geometry, b.geometry) FROM flux LEFT JOIN CHEF_LIEU a ON flux.CODGEO = a.INSEE_COM LEFT JOIN CHEF_LIEU b ON flux.DCLT = b.INSEE_COM WHERE a.INSEE_COM != b.INSEE_COM
Depuis quelques temps, j’utilise les VRT et je constate de très grosses lenteurs dans le traitement - plusieurs limites, limite freezing.
Pour préciser le type de traitement, je croise deux couches de données, l’une de 35000 lignes et l’autre de 1000 environ en générant des géométries (lignes sur la base de 2 points).
Suis-je le seul à constater de telles lenteurs ? D’autres retours sur le sujet ?
Je travaille sur Ubuntu avec la 3.12. J’avais les mêmes impressions avec la 3.10 et avant.
L’opération en elle même est bien plus rapide mais avec la préparation avant, pas sûr que je gagne du temps.
J’ai testé aussi directement via gdal/ogr (en ligne de commande). Là aussi, c’est très long - même après avoir créé un index (ogrinfo -sql “CREATE SPATIAL INDEX ON monshapefile” ./monshapefile.shp). Je ne sais pas si Even consulte la liste, je serai curieux d’avoir son retour là dessus.
Le problème me semble assez distinct mais pointe peut-être la faiblesse du format (?) - voir aussi la doc.
Régis, je travaille sur la base admin-express (chef lieu) et une bdd CSV issue de l’INSEE. Ca pourrait partir en BDD mais alors, je ne sais pas si je gagnerai du temps au final.
OK, et ben sans connaitre tes sources de données, mais la première piste est que tu dois manquer d’indexation sur le code commune , et donc tu relis les sources de données à chaque fois.
C’est quoi comme donnée?
ça pourrait s’envoyer dans une base de données?
Est-ce que la même requête en couche virtuelle via DB manager va plus vite?
SELECT CODGEO, LIBGEO, DCLT, L_DCLT, NBFLUX_C16_ACTOCC15P, make_line(a.geometry, b.geometry) FROM flux LEFT JOIN CHEF_LIEU a ON flux.CODGEO = a.INSEE_COM LEFT JOIN CHEF_LIEU b ON flux.DCLT = b.INSEE_COM WHERE a.INSEE_COM != b.INSEE_COM
Depuis quelques temps, j’utilise les VRT et je constate de très grosses lenteurs dans le traitement - plusieurs limites, limite freezing.
Pour préciser le type de traitement, je croise deux couches de données, l’une de 35000 lignes et l’autre de 1000 environ en générant des géométries (lignes sur la base de 2 points).
Suis-je le seul à constater de telles lenteurs ? D’autres retours sur le sujet ?
Je travaille sur Ubuntu avec la 3.12. J’avais les mêmes impressions avec la 3.10 et avant.
L’opération en elle même est bien plus rapide mais avec la préparation avant, pas sûr que je gagne du temps.
J’ai testé aussi directement via gdal/ogr (en ligne de commande). Là aussi, c’est très long - même après avoir créé un index (ogrinfo -sql “CREATE SPATIAL INDEX ON monshapefile” ./monshapefile.shp). Je ne sais pas si Even consulte la liste, je serai curieux d’avoir son retour là dessus.
Le problème me semble assez distinct mais pointe peut-être la faiblesse du format (?) - voir aussi la doc.
Régis, je travaille sur la base admin-express (chef lieu) et une bdd CSV issue de l’INSEE. Ca pourrait partir en BDD mais alors, je ne sais pas si je gagnerai du temps au final.
OK, et ben sans connaitre tes sources de données, mais la première piste est que tu dois manquer d’indexation sur le code commune , et donc tu relis les sources de données à chaque fois.
C’est quoi comme donnée?
ça pourrait s’envoyer dans une base de données?
Est-ce que la même requête en couche virtuelle via DB manager va plus vite?
SELECT CODGEO, LIBGEO, DCLT, L_DCLT, NBFLUX_C16_ACTOCC15P, make_line(a.geometry, b.geometry) FROM flux LEFT JOIN CHEF_LIEU a ON flux.CODGEO = a.INSEE_COM LEFT JOIN CHEF_LIEU b ON flux.DCLT = b.INSEE_COM WHERE a.INSEE_COM != b.INSEE_COM
Depuis quelques temps, j’utilise les VRT et je constate de très grosses lenteurs dans le traitement - plusieurs limites, limite freezing.
Pour préciser le type de traitement, je croise deux couches de données, l’une de 35000 lignes et l’autre de 1000 environ en générant des géométries (lignes sur la base de 2 points).
Suis-je le seul à constater de telles lenteurs ? D’autres retours sur le sujet ?
Je travaille sur Ubuntu avec la 3.12. J’avais les mêmes impressions avec la 3.10 et avant.
J’ai essayé également. La doc me semble un peu ambiguë sur ce point. Par ailleurs, la création de l’index ne renvoie rien si ce n’est “using driver `ESRI Shapefile’ successful.” et est instantanée … Ça me semble suspect.
L’opération en elle même est bien plus rapide mais avec la préparation avant, pas sûr que je gagne du temps.
J’ai testé aussi directement via gdal/ogr (en ligne de commande). Là aussi, c’est très long - même après avoir créé un index (ogrinfo -sql “CREATE SPATIAL INDEX ON monshapefile” ./monshapefile.shp). Je ne sais pas si Even consulte la liste, je serai curieux d’avoir son retour là dessus.
Le problème me semble assez distinct mais pointe peut-être la faiblesse du format (?) - voir aussi la doc.
Régis, je travaille sur la base admin-express (chef lieu) et une bdd CSV issue de l’INSEE. Ca pourrait partir en BDD mais alors, je ne sais pas si je gagnerai du temps au final.
OK, et ben sans connaitre tes sources de données, mais la première piste est que tu dois manquer d’indexation sur le code commune , et donc tu relis les sources de données à chaque fois.
C’est quoi comme donnée?
ça pourrait s’envoyer dans une base de données?
Est-ce que la même requête en couche virtuelle via DB manager va plus vite?
SELECT CODGEO, LIBGEO, DCLT, L_DCLT, NBFLUX_C16_ACTOCC15P, make_line(a.geometry, b.geometry) FROM flux LEFT JOIN CHEF_LIEU a ON flux.CODGEO = a.INSEE_COM LEFT JOIN CHEF_LIEU b ON flux.DCLT = b.INSEE_COM WHERE a.INSEE_COM != b.INSEE_COM
Depuis quelques temps, j’utilise les VRT et je constate de très grosses lenteurs dans le traitement - plusieurs limites, limite freezing.
Pour préciser le type de traitement, je croise deux couches de données, l’une de 35000 lignes et l’autre de 1000 environ en générant des géométries (lignes sur la base de 2 points).
Suis-je le seul à constater de telles lenteurs ? D’autres retours sur le sujet ?
Je travaille sur Ubuntu avec la 3.12. J’avais les mêmes impressions avec la 3.10 et avant.
J’ai essayé également. La doc me semble un peu ambiguë sur ce point. Par ailleurs, la création de l’index ne renvoie rien si ce n’est “using driver `ESRI Shapefile’ successful.” et est instantanée … Ça me semble suspect.
L’opération en elle même est bien plus rapide mais avec la préparation avant, pas sûr que je gagne du temps.
J’ai testé aussi directement via gdal/ogr (en ligne de commande). Là aussi, c’est très long - même après avoir créé un index (ogrinfo -sql “CREATE SPATIAL INDEX ON monshapefile” ./monshapefile.shp). Je ne sais pas si Even consulte la liste, je serai curieux d’avoir son retour là dessus.
Le problème me semble assez distinct mais pointe peut-être la faiblesse du format (?) - voir aussi la doc.
Régis, je travaille sur la base admin-express (chef lieu) et une bdd CSV issue de l’INSEE. Ca pourrait partir en BDD mais alors, je ne sais pas si je gagnerai du temps au final.
OK, et ben sans connaitre tes sources de données, mais la première piste est que tu dois manquer d’indexation sur le code commune , et donc tu relis les sources de données à chaque fois.
C’est quoi comme donnée?
ça pourrait s’envoyer dans une base de données?
Est-ce que la même requête en couche virtuelle via DB manager va plus vite?
SELECT CODGEO, LIBGEO, DCLT, L_DCLT, NBFLUX_C16_ACTOCC15P, make_line(a.geometry, b.geometry) FROM flux LEFT JOIN CHEF_LIEU a ON flux.CODGEO = a.INSEE_COM LEFT JOIN CHEF_LIEU b ON flux.DCLT = b.INSEE_COM WHERE a.INSEE_COM != b.INSEE_COM
Depuis quelques temps, j’utilise les VRT et je constate de très grosses lenteurs dans le traitement - plusieurs limites, limite freezing.
Pour préciser le type de traitement, je croise deux couches de données, l’une de 35000 lignes et l’autre de 1000 environ en générant des géométries (lignes sur la base de 2 points).
Suis-je le seul à constater de telles lenteurs ? D’autres retours sur le sujet ?
Je travaille sur Ubuntu avec la 3.12. J’avais les mêmes impressions avec la 3.10 et avant.
