2352 shaares
17 results
tagged
SIG
Différentes façons d'extraire les ridges d'une carte d'altitude avec GRASS
Trouver des lignes de crêtes
Approche géniale.
Une réponse super-claire à une question que je me posais depuis longtemps. Quelle erreur max peut-on attendre sur une mesure de distance si l'on considère la terre comme une sphère. Réponse, assez peu étonnante : 22km (ce qui correspond à la différence entre le rayon à l'équateur et celui au pôle). Le gars fait une superbe carto des erreurs de distance à partir d'un point localisé en Camargue, et on peut voir que l'erreur monte vite. De la Camargue en Russie, ça peut faire déjà 5km de différence. Mais, en termes d'erreur relative, ça ne dépassera jamais 0.5% de la distance réelle.
Une série de blogs sur l'utilisation de PostGIS pour l'analyse de mouvements. Via Mathieu.
Intéressant : un article sur RQGIS qui montre les possibilités du package. Pas mal du tout...
Oh la belle ressource intéressante sur spatialite! J'ai le sentiment que celle-ci va me servir!
YEEEES. J'ai réussi cette étape-ci... En suivant à la lettre ces instructions, ça marche.
Edit: non, ça marche pas en fait. J'arrive bien à avoir ECW parmi les drivers dispo, mais impossible d'importer ce foutu ecw de merde avec. Erreur mémoire, mauvaise allocation.
Bon, je continue à chercher...
Edit 2: j'ai recompilé en remplaçant le so 64 bits par le 32, même souci... Je vais essayer avec une autre version du SDK...
Edit 3: Hexagon geospatial ne laisse pas le choix de la version du sdk. Tu prends celle qu'on te donne et tu la fermes (au passage, tu nous laisses ton nom, ton prénom, ton numéro de téléphone, ton adresse, etc.).
Le monde du propriétaire, j'adore.
Edit 4: Essai de recompiler complètement une version récente de gdal (2.1.3) en suivant les instructions ici: https://trac.osgeo.org/gdal/wiki/ECW
Après suppression de ma version précédente (1.11). La compilation plante à cause de l'ECW après une demi-heure de compilation. Recherche sur internet, je tombe sur ça: http://osgeo-org.1560.x6.nabble.com/gdal-dev-gdal-2-1-ecw-5-2-1-td5299048.html
J'essaie la compilation avec les flags indiqués, rien à faire, la compilation plante encore à cause de cette saloperie de merde de chiotte d'ECW de mes couilles.
Et pour info, même problème avec une version plus ancienne de gdal quand on la recompile (1.11)
Edit 5: j'essaie une approche différente: je vais compiler une version ancienne du SDK, et recompiler gdal avec cette version. Je récupère la version ici:
https://github.com/cga-harvard/cga-worldmap/wiki/How-to-enable-ECW-support-in-GeoServer
Je compile ça, je l'installe, et je recompile gdal avec --with-ecw=/usr/lib
Edit 6: PUTAIN ÇA MARCHE TOUJOURS PAS!!!! J'ai essayé les deux versions de gdal, rien à faire. Ça compile, ça me liste ecw dans les drivers, mais putain ça veut pas me sortir un gdalinfo qui marche! On a toujours ce putain d'erreur d'allocation mémoire.
Dernier essai, j'essaie d'appliquer les patchs aux sources listés ici, et je recommence:
https://github.com/cga-harvard/cga-worldmap/wiki/How-to-enable-ECW-support-in-GeoServer
Edit 7: PUTAIN ÇA MARCHE!!!!! La vache, j'y ai passé la journée, mais j'ai RÉUSSI!!!!
Je synthétise: on récupère une ancienne version du SDK (version 3), on récupère et on applique les patchs des bugs (pour éviter les erreurs d'allocation mémoire), on la compile et on l'installe. Ensuite, on récupère les sources de gdal -- version 1.11, je garantis pas que ça marchera avec une version plus récente -- on compile ces sources (en indiquant l'adresse de la lib ECW lors du ./configure, puis après classique make), et on installe, et ça marche. Attention, il ne faut pas passer par l'étape "sudo gdal-ecw-build /usr/local" décrite ici: https://github.com/cga-harvard/cga-worldmap/wiki/How-to-enable-ECW-support-in-GeoServer (à part ça, ce lien est le plus proche de ce qui peut marcher).
Et on termine en recompilant le package raster et rgdal sous R pour pouvoir utiliser ça.
YEEEEEEEEEEEEEEEEEEEEEEESSSSSSS!!!!
Putain je commençais à plus y croire.
Edit 8: Euh, par contre, quand on recompile rgdal, on ne peut plus utiliser les versions de qgis et grass présentes dans les dépots: il faut complètement recompiler ces logiciels depuis les sources. C'est pas compliqué, mais c'est chiant. Donc si je synthétise, pour pouvoir importer l'ECW avec gdal, il faut récupérer la lib ECW version 3 (ancienne version sinon ça marche pas), compiler cette lib et l'installer, récupérer les sources de gdal en les compiler en indiquant la localisation de cette lib, et récupérer les sources et compiler tous les SIG qui s'appuient sur gdal.
Donc tous les SIG (qgis et grass), puisque gdal est central. Et, bien sûr, les packages R associés. Moralité, pour pouvoir utiliser ce format de merde, il faut réinstaller TOUT le système.
Je l'ai fait, mais ce que je pense du monde du logiciel propriétaire est assez clair je pense...
Edit: non, ça marche pas en fait. J'arrive bien à avoir ECW parmi les drivers dispo, mais impossible d'importer ce foutu ecw de merde avec. Erreur mémoire, mauvaise allocation.
Bon, je continue à chercher...
Edit 2: j'ai recompilé en remplaçant le so 64 bits par le 32, même souci... Je vais essayer avec une autre version du SDK...
Edit 3: Hexagon geospatial ne laisse pas le choix de la version du sdk. Tu prends celle qu'on te donne et tu la fermes (au passage, tu nous laisses ton nom, ton prénom, ton numéro de téléphone, ton adresse, etc.).
Le monde du propriétaire, j'adore.
Edit 4: Essai de recompiler complètement une version récente de gdal (2.1.3) en suivant les instructions ici: https://trac.osgeo.org/gdal/wiki/ECW
Après suppression de ma version précédente (1.11). La compilation plante à cause de l'ECW après une demi-heure de compilation. Recherche sur internet, je tombe sur ça: http://osgeo-org.1560.x6.nabble.com/gdal-dev-gdal-2-1-ecw-5-2-1-td5299048.html
J'essaie la compilation avec les flags indiqués, rien à faire, la compilation plante encore à cause de cette saloperie de merde de chiotte d'ECW de mes couilles.
Et pour info, même problème avec une version plus ancienne de gdal quand on la recompile (1.11)
Edit 5: j'essaie une approche différente: je vais compiler une version ancienne du SDK, et recompiler gdal avec cette version. Je récupère la version ici:
https://github.com/cga-harvard/cga-worldmap/wiki/How-to-enable-ECW-support-in-GeoServer
Je compile ça, je l'installe, et je recompile gdal avec --with-ecw=/usr/lib
Edit 6: PUTAIN ÇA MARCHE TOUJOURS PAS!!!! J'ai essayé les deux versions de gdal, rien à faire. Ça compile, ça me liste ecw dans les drivers, mais putain ça veut pas me sortir un gdalinfo qui marche! On a toujours ce putain d'erreur d'allocation mémoire.
Dernier essai, j'essaie d'appliquer les patchs aux sources listés ici, et je recommence:
https://github.com/cga-harvard/cga-worldmap/wiki/How-to-enable-ECW-support-in-GeoServer
Edit 7: PUTAIN ÇA MARCHE!!!!! La vache, j'y ai passé la journée, mais j'ai RÉUSSI!!!!
Je synthétise: on récupère une ancienne version du SDK (version 3), on récupère et on applique les patchs des bugs (pour éviter les erreurs d'allocation mémoire), on la compile et on l'installe. Ensuite, on récupère les sources de gdal -- version 1.11, je garantis pas que ça marchera avec une version plus récente -- on compile ces sources (en indiquant l'adresse de la lib ECW lors du ./configure, puis après classique make), et on installe, et ça marche. Attention, il ne faut pas passer par l'étape "sudo gdal-ecw-build /usr/local" décrite ici: https://github.com/cga-harvard/cga-worldmap/wiki/How-to-enable-ECW-support-in-GeoServer (à part ça, ce lien est le plus proche de ce qui peut marcher).
Et on termine en recompilant le package raster et rgdal sous R pour pouvoir utiliser ça.
YEEEEEEEEEEEEEEEEEEEEEEESSSSSSS!!!!
Putain je commençais à plus y croire.
Edit 8: Euh, par contre, quand on recompile rgdal, on ne peut plus utiliser les versions de qgis et grass présentes dans les dépots: il faut complètement recompiler ces logiciels depuis les sources. C'est pas compliqué, mais c'est chiant. Donc si je synthétise, pour pouvoir importer l'ECW avec gdal, il faut récupérer la lib ECW version 3 (ancienne version sinon ça marche pas), compiler cette lib et l'installer, récupérer les sources de gdal en les compiler en indiquant la localisation de cette lib, et récupérer les sources et compiler tous les SIG qui s'appuient sur gdal.
Donc tous les SIG (qgis et grass), puisque gdal est central. Et, bien sûr, les packages R associés. Moralité, pour pouvoir utiliser ce format de merde, il faut réinstaller TOUT le système.
Je l'ai fait, mais ce que je pense du monde du logiciel propriétaire est assez clair je pense...
En conclusion: l'ECW est un format de merde. Peut-être que ça permet une compression impressionnante, mais des données publiques dans des formats fermés, c'est vraiment la merde.
Je HAIS l'ECW. Je vais quand même pas devoir réinstaller tout mon système juste pour pouvoir lire ces putains d'ECW de merde?
Je hais ce format.
Je HAIS l'ECW. Je vais quand même pas devoir réinstaller tout mon système juste pour pouvoir lire ces putains d'ECW de merde?
Je hais ce format.
Construction du support ECW pour GDAL. Je garde sous le coude
Edit: marche pas.
Edit: marche pas.
De l'usage des index spatiaux pour accélérer les opérations spatiales avec spatialite. Spatialite, je découvre je découvre...
Et j'adopte!
Et j'adopte!
Je m'étais jamais posé la question: pourquoi fixer des false easting et false northing dans les systèmes de coordonnées: pour éviter d'avoir des coordonnées négatives
Source d'info utile sur toute l'info géographique "officielle". Ya un flux rss, me suis abonné.
Plein de données SIG pour la conservation
Bon, j'ai besoin de projeter des données en Méditerranée. Je stocke ici ce que j'ai pu trouver. La projection la plus utilisée pour la méditerranée (vue sur plein de sites internet, nations unies, FAO, etc.) semble être la projection "Lambert azimuthal equal area", décrite à la page suivante:
http://www.remotesensing.org/geotiff/proj_list/lambert_azimuthal_equal_area.html
Cette projection nécessite de définir la projection du point "central" sur la zone que l'on cherche à étudier. Dans une étude sur les impacts humains sur les écosystèmes marins (http://journals.plos.org/plosone/article?id=10.1371/journal.pone.0079889), Micheli et al, financés par le NCEAS, utilisent la projection suivante (Chaîne proj4 à utiliser dans R):
"+proj=laea +lat_0=38 +lon_0=18 +x_0=0 +y_0=0 +datum=WGS84 +units=m +no_defs +ellps=WGS84 +towgs84=0,0,0"
Source:
https://www.nceas.ucsb.edu/globalmarine/mediterranean
Un tour sur google maps indique que le point central est bien au milieu de la méditerranée (flèche verte):
http://huit.re/zw10DUVc
Edit: La projection recommandée pour l'Europe pour *l'analyse statistique et la représentation* (cf. ici: http://eusoils.jrc.ec.europa.eu/Projects/Alpsis/Docs/ref_grid_sh_proc_draft.pdf) est la même projection (utilisant l'ETRS89 comme datum, mais en pratique, la différence avec le wgs84 est négligeable, de l'ordre d'un demi-mètre, cf. ici: http://www.killetsoft.de/t_1009_e.htm). Le point central est ici 52°N et 10°E (voir page 29 du doc pdf précédent), ce qui donne une proj4string suivante:
"+proj=laea +lat_0=52 +lon_0=10 +x_0=0 +y_0=0 +datum=WGS84 +units=m +no_defs +ellps=WGS84 +towgs84=0,0,0"
http://www.remotesensing.org/geotiff/proj_list/lambert_azimuthal_equal_area.html
Cette projection nécessite de définir la projection du point "central" sur la zone que l'on cherche à étudier. Dans une étude sur les impacts humains sur les écosystèmes marins (http://journals.plos.org/plosone/article?id=10.1371/journal.pone.0079889), Micheli et al, financés par le NCEAS, utilisent la projection suivante (Chaîne proj4 à utiliser dans R):
"+proj=laea +lat_0=38 +lon_0=18 +x_0=0 +y_0=0 +datum=WGS84 +units=m +no_defs +ellps=WGS84 +towgs84=0,0,0"
Source:
https://www.nceas.ucsb.edu/globalmarine/mediterranean
Un tour sur google maps indique que le point central est bien au milieu de la méditerranée (flèche verte):
http://huit.re/zw10DUVc
Edit: La projection recommandée pour l'Europe pour *l'analyse statistique et la représentation* (cf. ici: http://eusoils.jrc.ec.europa.eu/Projects/Alpsis/Docs/ref_grid_sh_proc_draft.pdf) est la même projection (utilisant l'ETRS89 comme datum, mais en pratique, la différence avec le wgs84 est négligeable, de l'ordre d'un demi-mètre, cf. ici: http://www.killetsoft.de/t_1009_e.htm). Le point central est ici 52°N et 10°E (voir page 29 du doc pdf précédent), ce qui donne une proj4string suivante:
"+proj=laea +lat_0=52 +lon_0=10 +x_0=0 +y_0=0 +datum=WGS84 +units=m +no_defs +ellps=WGS84 +towgs84=0,0,0"
un site.
Comment importer un de ces foutus MDB arcgis dans un format ouvert