Le portail francophone de la géomatique

Feeds

10384 items (3 unread) in 53 feeds

Dans la presse

• Décryptagéo, l'information géographique
• Cybergeo
• Revue Internationale de Géomatique (RIG)
• SIGMAG & SIGTV.FR - Un autre regard sur la géomatique
• Mappemonde

Du côté des éditeurs

• Imagerie Géospatiale
• Toute l’actualité des Geoservices de l'IGN
• arcOrama, un blog sur les SIG, ceux d ESRI en particulier
• arcOpole - Actualités du Programme
• Géoclip, le générateur d'observatoires cartographiques
• Blog GEOCONCEPT FR

Toile géomatique francophone (3 unread)

• Géoblogs (GeoRezo.net)
• Geotribu (1 unread)
• Les cafés géographiques
• UrbaLine (le blog d'Aline sur l'urba, la géomatique, et l'habitat)
• Séries temporelles (CESBIO)
• Datafoncier, données pour les territoires (Cerema)
• Cartes et figures du monde
• SIGEA: actualités des SIG pour l'enseignement agricole
• Data and GIS tips
• Neogeo Technologies
• ReLucBlog
• L'Atelier de Cartographie
• My Geomatic
• archeomatic (le blog d'un archéologue à l’INRAP)
• Cartographies numériques (2 unread)
• Veille cartographie
• Makina Corpus
• Oslandia
• Camptocamp
• Carnet (neo)cartographique
• Le blog de Geomatys
• GEOMATIQUE
• Geomatick
• CartONG (actualités)

Géomatique anglophone

• Planet Geospatial - http://planetgs.com
• Google Maps Mania
• All Points Blog
• Directions Media - Podcasts
• Navx
• James Fee GIS Blog
• Open Geospatial Consortium (OGC)
• Planet OSGeo

Blogs GeoRezo.net

• Parcell'air
• Le coin de l'open-source géospatial
• INSPIRE by clouds
• Les GéoBlogs
• Infobulle
• Le blog SIG & URBA
• Blog Interopérabilité & GéoInformation

• 26 February 2019
• 20:00

  Mapping Countries by Similarity

  sur Google Maps Mania
  The Grand Prize winner in the World Data Visualization Prize 2019 was an interactive visualization which groups the world's countries using artificial intelligence. This interactive visualization, created by Interacta, shows the connections and similarities between different countries based on a number of different factors. The Country t-SNE map rearranges the countries of the world so that
• 18:14

  Detroit Foreclosures on Street View

  sur Google Maps Mania
  One in three homes in Detroit has been foreclosed in the last 15 years. The result of all those lost homes is physically evident on the city's streets. It is also very evident when exploring the city on Google Maps Street View. GooBing Detroit uses the historical imagery function in Google Maps Street View to show how Detroit has changed over the years. By juxtaposing Street View images of the

• 18:01

  gvSIG Team: Camino a gvSIG 2.5: Nuevo geoproceso, Rejilla por densidad de puntos

  sur Planet OSGeo

  Hablamos en el post anterior sobre una serie de geoprocesos relacionados con la criminología realizados junto a la Universidad Jaume I (UJI). Puedes ver el vídeo de la ponencia aquí. Estos geoprocesos pueden utilizarse en diferentes campos, no ligado en exclusiva a la criminología.

  Le toca el turno al geoproceso de Rejilla por densidad de puntos. El objetivo principal de este geoproceso es el de realizar de una forma rápida y eficiente un conteo de puntos contenidos en una rejilla que también crea el geoproceso. En el caso planteado, delitos, pero se puede aplicar a muchas otra cosas. Esto permite visualizar de forma rápida cómo se distribuyen los eventos cuando  hay una capa con una gran acumulación de ellos en unas mismas zonas.

  

  Delitos en Nueva York (150.000 entidades)

  Los parámetros de entrada son una capa de puntos y una expresión (opcional) que serviría de filtrado para ejecutar el geoproceso. Por ejemplo, podríamos aplicar un filtro por tipología de delito.

  Las opciones hacen referencia a:

  • Distancia de rejilla: A la distancia del lado de cada cuadrado o hexágono. En relación con las medidas de la Vista.
  • Tipo de rejilla: Puede  ser cuadricular o hexagonal. Y en hexagonal dos tipos: Vertical o horizontal.
  • Añadir rejillas vacías: No añadir rejilla en las zonas donde no hay elementos puntuales, o sea, donde su conteo es cero.

  

  Es importante seleccionar correctamente en la pestaña de Región de análisis cual va a ser la extensión de la rejilla.

  El resultado del geoproceso sobre la capa de la imagen inicial devuelve una rejilla con una tabla de atributos a la que podemos aplicarle una leyenda por intervalo de valores.

  

  Aquí un resultado sobre toda la capa de delitos con otra distancia más pequeña y de tipo rejilla vertical.

  

  Aquí aplicando un filtro sobre un distrito.

  

  En la tabla de atributos se puede ver el conteo total de puntos dentro de cada rejilla, el total de puntos implicados en el cálculo inicial antes del filtrado, y el porcentaje de esos puntos respecto al total.

  Además, hemos aprovechado durante el desarrollo de este geoproceso en hacer mejoras y depurar gvSIG para soportar capas con mayor número de registros. Una de estas pruebas para este geoproceso se realizo con una capa con más de 6.7millones de registros y más de 10 campos.

  Ya puedes descargarte y probar el nuevo geoproceso de Rejilla por densidad de puntos en la nueva candidata a versión final . Puedes descargarlos de Herramientas -> Administrador de complementos y buscar por el geoproceso “Geoprocess: Point density grid”. Una vez instalado, aparecerá junto a los geoprocesos dentro del apartado de “Scripting – Análisis de datos – Rejilla por densidad de puntos”.

  Si encuentras cualquier fallo o recomendación te animamos a escribirnos a las Listas de correo de gvSIG.

• 16:26

  GEOSYSTEMS France partenaire Geodata Diffusion sur le SIMA

  sur Imagerie Géospatiale
  @GEOSYSTEMS_FR partenaire @Reseau_Orpheon sur le #SIMA Stand 4K39 avec #FOUILLES3D le kit pour géoréférencer vos réseaux en tranchée ouverte par le seul passage d'un opérateur du chantier ! pic.twitter.com/tcTvjncGZs — GEOSYSTEMS France (@GEOSYSTEMS_FR) 26 février 2019

• 11:30

  Fernando Quadro: Introdução ao Leaflet – Parte 1

  sur Planet OSGeo

  Prezados leitores,

  Os próximos 13 posts, serão dedicados a uma introdução ao framework Leaflet. Estarei começando do zero e cada postagem no blog será adicionado um pouco mais ao projeto. As postagens provavelmente não serão publicadas todos os dias.

  Parte 1 – Configurando um Mapa Simples

  Para começar, vamos criar um modelo, copiado diretamente dos documentos do Leaflet:

  <!DOCTYPE html>
  <head>
    <link rel="stylesheet" href="https://unpkg.com/leaflet@1.4.0/dist/leaflet.css"
    crossorigin=""/>  
    <script src="https://unpkg.com/leaflet@1.4.0/dist/leaflet.js"
    crossorigin=""></script>
    <style>
        #mapDIV{
            height: 700px;
            width: 700px;
            border: solid 1px black;
        }
  </style>
  </head>
  <body>
      <div id='mapDIV'>i</div>
  </body>
  </html>
  

  Também criamos um div para manter o id do mapa (mapDIV) na seção head, e adicionamos um estilo para definir o tamanho do mapa quando exibido no navegador. Este HTML irá “carregar” o Leaflet, mas você não verá nada. Precisamos adicionar um script que crie o mapa.

  <script>
        var map = L.map(document.getElementById('mapDIV'), {
        center: [-20.1438, -44.1301],
        zoom: 15
        });
        var basemap = L.tileLayer('http://{s}.tile.osm.org/{z}/{x}/{y}.png', {
            });
            basemap.addTo(map);
  </script>
  

  Este pequeno script, colocado depois da mapDiv, faz o seguinte:

  • Adiciona um objeto de mapa
  • Centraliza em uma latitude/longitude
  • Define o nível de zoom
  • Adiciona o mapa base do OpenStreetMap

  Se nós carregarmos o arquivo em nosso navegador, nós veremos isto:

  

  Este mapa é centrado na localização do desastre de Brumadinho que ocorreu no dia 25 de janeiro de 2019. Vamos movê-lo em um post posterior.

  Esse é o nosso primeiro post. A atribuição é importante e vamos adicioná-la ao mapa, junto com outras novidades no próximo post.

  Aqui está o arquivo HTML completo:

  <!DOCTYPE html>
  <head>
    <link rel="stylesheet" href="https://unpkg.com/leaflet@1.4.0/dist/leaflet.css"
    crossorigin=""/>  
    <script src="https://unpkg.com/leaflet@1.4.0/dist/leaflet.js"
    crossorigin=""></script>
    <style>
        #mapDIV{
            height: 700px;
            width: 700px;
            border: solid 1px black;
        }
  </style>
  </head>
  <body>
      <div id='mapDIV'>i</div>
  <script>
        var map = L.map(document.getElementById('mapDIV'), {
        center: [-20.1438, -44.1301],
        zoom: 15
        });
        var basemap = L.tileLayer('http://{s}.tile.osm.org/{z}/{x}/{y}.png', {
            });
            basemap.addTo(map);
  </script>
  </body>
  </html>
  

• 11:20

  A Journey Through Famine in India

  sur Google Maps Mania
  "All this day our noses were infested and our bodyes almost infected with a most noysome smell, which after search, wee found to come from a great pitt, wherein were throwne 30 or 40 persons, men, weomen and children, old and younge confuseldy tumbled in together without order or Coveringe" - 1630, Peter Munday, Itinerarium Mundii In 1631 around 3 million people died of starvation & disease in

• 1:28

  Martin Davis: Better/Faster ST_PointOnSurface for PostGIS

  sur Planet OSGeo
  And now for the final chapter in the saga of improving InteriorPoint / PointOnSurface.  For those who missed the first two episodes, the series began with a new approach for the venerable JTS Geometry.interiorPoint() for polygons algorithm.  Episode 2 travelled deep into the wilds of C++ with a port to GEOS.  The series finale shows how this results in greatly improved performance of PostGIS ST_PointOnSurface.
  
  The BC Voting Area dataset is a convenient test case, since it has lots of large polygons (shown here with interior points computed).
  The query is about as simple as it gets:
  
     select ST_PointOnSurface(geom) from ebc.voting_area;
  
  Here's the query timings comparison, using the improved GEOS code and the previous implementation:
  
  

  Data size	Time	Time OLD	Improvement	Time ST_Centroid
  5,658 polygons (2,171,676 vertices)	341 ms	4,613 ms	x 13	369 ms

  
  As expected, there is a dramatic improvement in performance.  The improved ST_PointOnSurface runs 13 times faster than the old code.  And it's now as fast as ST_Centroid.  It's also more robust and tolerant of invalid input (although this test doesn't show it).
  
  This should show up in PostGIS in the fall release (PostGIS 3 / GEOS 3.8).
  
  On to the next improvement... (and also gotta update the docs and the tutorial!)