News aggregator

GeoTools Team: Copyright Headers in Source Code Files

OSGeo Planet - 2 hours 10 min ago

OSGeo has now received legal advice on copyright headers in source code files. This advice is summarised here for the benefit of all projects:
  • Copyright headers in source code files are not required to enforce copyright.
  • Works still under copyright when the Berne Convention was adopted (1992 in the United States) are protected under this convention.
  • Works created after the Berne Convention was adopted are also protected.
  • There is no need to include a copyright header for a source code file created or modified after the Berne Convention was adopted. A modified source code file is a new work.
  • Source code files created before the adoption of the Berne Convention and not modified since its adoption should include a copyright header with the dates of creation and modification. These dates support the assertion that these files are covered by the Berne Convention.
  • Both individual source code files and the project source as a whole are copyrighted works.
Even though its earliest publication was in 1996, the GeoTools project still requires a copyright header in source code files; these should be seen as informative, and are not required to enforce copyright. See GeoTools Header Policy Updated for details.
An informative header that names the project, links to to project page, and references the licence is informative, and while not legally binding, might deter some infringers (at least they were warned file-by-file that the code is open source).

Note that the author of this blog post is not a lawyer and this post has not been reviewed by a lawyer. This post should not be construed as legal advice.

Categories: OSGeo Planet

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

OSGeo Planet - 3 hours 51 min ago

Esta série de posts que inicia hoje descreverá como usar o GeoGig juntamente com outros pacotes de software para gerenciamento de dados espaciais, mostrando um fluxo de trabalho típico.

Esta introdução se concentra principalmente no GeoGig e pressupõe o conhecimento em nível de usuário de todas as outras aplicações. Para obter mais informações sobre eles, consulte a documentação correspondente de cada programa.

Vamos iniciar com uma definição do que é o GeoGig:

GeoGig é uma ferramenta de código aberto que inspira-se no Git, mas adapta seus conceitos fundamentais para lidar com o controle de versão distribuído de dados geoespaciais.

Resumindo… com o GeoGig os usuários são capazes de importar dados geoespaciais (atualmente Shapefiles, PostGIS ou SpatiaLite) para um repositório onde todas as alterações realizada nos dados são rastreadas. Estas mudanças podem ser visualizados em um histórico, revertidos para versões mais antigas, ramificadas, mescladas (merges), e enviada para repositórios remotos.

Agora que já sabemos o que é GeoGig é importante você saber que todo conjunto de dados de amostra que serão utilizados nos próximos posts são baseados em dados do OpenStreetMap. Você pode baixá-lo como um arquivo zip e descompactá-lo em uma pasta de sua escolha.

Para este tutorial é necessário estar instalado em seu computador os seguintes sistemas:

  • GeoGig
  • GeoServer com a extensão GeoGig
  • PostGIS (incluindo shp2pgsql)
  • QGIS 2.0

O GeoServer e PostGIS são instalados como parte de OpenGeo Suite. Este tutorial assume que você está usando o OpenGeo Suíte.

Para instalar GeoGig, é necessário ter o Java JDK 8 (de preferência) instalado em sua máquina. Após verificado isso, você deve baixar o GeoGig e descompactá-lo em uma pasta de sua preferência (C:\Program Files\GeoGig ou /opt/geogig). É importante ressaltar que esse mesmo arquivo que você baixou pode ser utilizado tanto no Windows, Linux ou Mac.

Para finalizar a instalação do GeoGig você deve adicionar o diretório bin na variável de ambiente PATH. Quando terminar, você deve ser capaz de executar o geogig –help no prompt de comando.

Além do GeoGig você precisa ter GeoServer instalada em seu sistema, com uma versão maior ou igual a 2.3.x.

Se você estiver usando OpenGeo Suite, o GeoServer já deve estar instalado em seu sistema, mas ele não contém a extensão GeoGig. Desta forma, você pode ignorar a instalação do GeoServer, mas você deve instalar a extensão GeoGig como descrito acima.

Como no caso do GeoServer, se você tiver instalado o OpenGeo Suite, já deve ter PostGIS, incluindo o shp2pgsql utilidade, instalado. Caso contrário terá de instalá-lo.

Por último, você deve instalar o QGIS 2.0, você pode baixá-lo no próprio site QGIS. Além dele, você deve baixar o plugin OpenGeo Explorer, que será utilizado neste tutorial. As instruções de instalação podem ser encontradas no site do plugin.

No próximo post iremos configurar o GeoGig com o PostGIS. Não perca!

Posts RelacionadosZemanta
Categories: OSGeo Planet

Jo Cook: Don't be Afraid to Commit

OSGeo Planet - 4 hours 30 min ago

Back in June, which seems a long time ago now, we (OSGeo:UK) ran a mini FOSS4G event at the Ordnance Survey offices in Southampton, UK. It was a big success, well attended, and everyone seemed to enjoy themselves, which is always nice. This is not a post about the event, per se (perhaps in retrospect going straight on to another event the week after was a bad idea). Others have posted about this, and there’s always the #foss4guk hashtag on twitter if you’re interested. However, along with chairing the event, I foolishly decided to run a workshop around a topic that had been taking shape in my mind for a while- namely how to get new users of open source software to a point where they are comfortable contributing to the packages they use, as well as simply using them.

I began this workshop looking at my own perspective. I’m no more than an arm-chair coder at best (Python and SQL are fine but the rest requires some serious googling and sucking up to colleagues). I can, however, find and report bugs, and contribute to documentation, and that’s my way of giving back. This may not require an in depth knowledge of java or C++, and all the additional skills they require but there’s still a barrier to entry- namely navigating online repositories such as GitHub, and producing useful bug reports. Helping with documentation involves learning about ReadTheDocs and ReStructured Text, and proper bug reporting, where you try and isolate the cause of the problem requires virtualisation of some kind. Suddenly you’re looking at a fairly large toolkit, before you start with bug fixes and other code contributions!

Then, a few months ago some colleagues went to PyCon UK and came back with stories of the wonderous Don’t be afraid to commit workshops, so I decided to come up with something vaguely similar, but focused more on GitHub and bug reporting, and less on Python. I also included an adapted version of the wonderful How to Report a Bug site, but again focusing on open source geospatial projects. You can find my workshop attempt on GitHub at http://archaeogeek.github.io/foss4gukdontbeafraid/.

Some thoughts for those considering running something similar…

In retrospect it was incredibly ambitious to try and get through all the above in 2 hours- it was only possible by setting some fairly strict workshop prerequisites, which most people actually took note of. Given that this was a “Bring your own device” conference, I ran the Git sections using the command line tools rather than any of the graphical user interfaces. Although there was some resistance to this, it was the only sane approach because I had people using Windows, Mac, Linux and an Android tablet in the class! The bit that actually caused the most trouble was setting the default text editor for Git to use. If I was running the class again I would probably omit this section and use the short-hand method of adding commit messages at the command line instead.

It’s also really hard to manage a shared repository for people to use for trying out pull requests- I had a simple text file (generated using the superb hipster ipsum site to generate it), but that caused all sorts of conflicts when multiple people issued pull requests all at the same time. There are alternative approaches to this (countless online, interactive git tutorials) but they weren’t the approach I wanted to use in this workshop. If I’d had more time to prepare I would have come up with a more complex file, perhaps with some specific errors in it, that people could fix without conflicting with each other.

Finally, we barely had time to look at ReStructured Text, or virtualisation, and it probably wasn’t worth even trying to cover them in the same workshop!

Having said all that, I know of at least one workshop attendee who has used his new GitHub skills to good effect, and was recently seen contributing to some documentation, so that’s a start. It would be good if there were more workshops of this kind at open source conferences, not necessarily based on mine, but feel free to borrow/improve it if you like!

Categories: OSGeo Planet

GeoTools Team: GeoTools Header Policy Updated

OSGeo Planet - 16 hours 17 min ago
GeoTools Developers Guide on source code conventions has been updated with a new policy on file headers (exciting I know).

GeoTools will now focus on filling in headers with the current year on initial file creation ... and that is it.
/*
* GeoTools - The Open Source Java GIS Toolkit
* http://geotools.org
*
* (C) 2016, Open Source Geospatial Foundation (OSGeo)
*
* This library is free software; you can redistribute it and/or
* modify it under the terms of the GNU Lesser General Public
* License as published by the Free Software Foundation;
* version 2.1 of the License.
*
* This library is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
* Lesser General Public License for more details.
*/Previously, we asked contributors to update the headers each time they modified a file, resulting in a date range at the top of each file. While not technically difficult, this was a constant chore for committers and caused friction and delays reviewing pull requests. We trust that the new policy will ease the pull request submission and review process.

We have approached the OSGeo Board and gotten approval to bounce this change off legal counsel. It is hoped that other OSGeo projects can benefit from being more relaxed.

Thanks to Justin for writing up the change proposal and steering this conversation on the mailing list.
Categories: OSGeo Planet

GIScussions: Child Poverty in London

OSGeo Planet - 21 hours 45 min ago

The advantages of wealth and the burdern of poverty.

This is another post about making maps from OpenData. I am trying to learn more geeky stuff rather than my usual blathering about the map and data business, things open and stuff, so I am playing with PostGIS, QGIS, taking some tentative steps into CSS and JavaScript and generally having lots of fun. But hey, you can burn a lot of time wrangling data and making maps.

A week ago I saw this tweet

Mapping how poverty in London changed from 2008 to 2013 ••• pic.twitter.com/Xr4mxzWUZy

— Barry Quirk (@BarryQuirk1) July 18, 2016

I couldn’t get any sense of what change had taken place or how the 2 maps compared, so I replied

@BarryQuirk1 @JeniT why not make 1 map showing changes rather than 2? This representation doesn’t work

— (((Steven Feldman))) (@StevenFeldman) July 19, 2016

Then I thought to myself, why don’t I try to make a more useful map? What follows is a summary of what I did, what worked, what didn’t. Hopefully it will be useful to someone and possibly a better map maker may even come up with a better way of doing this.

Data

I couldn’t find the CASE UMBR data set that Barry had used. That was probably a good thing as Lower Super Output Areas (even just for London) is quite a large data set.

But thanks to The London DataStore it wasn’t hard to find some data on poverty in London. I downloaded:

  1. Children in Poverty, Borough and Ward (xls)
  2. Statistical GIS Boundary Files for London (shp)

There are 2 sets of boundary files because at some stage the boundaries changed (this was a source of confusion, data wrangling and I’m not sure if I have got it completely right!)

Data munging

The starting point was to have a look at the data

  • There is a tab for each year (plus one for metadata)
  • The ward classifications changed in 2008 and then there seem to have been some further changes in boundaries after 2011. I decided that I would focus on the changes in Child Poverty for under 16 year olds between 2008 and 2013.
  • There is some regional and borough data at the top of each tab which I deleted (and saved as a separate spreadsheet, just in case)
  • I deleted the columns that I didn’t need
  • I cleaned up the header row and created shorter field names

Sounds easy? Yes, but QGIS doesn’t handle spreadsheet imports as elegantly as one might hope

Categories: OSGeo Planet

GeoServer Team: Online GeoServer Bug Stomp – July 2016 Results

OSGeo Planet - Tue, 2016-07-26 19:42

cropped-geoserver_icon.png

Dear Readers,

A few words to report on the results of the Online GeoServer Bug Stomp that took place on the 22nd of July 2016.

The goal, as indicated, was to look at GeoServer and GeoServer JIRA and clean old, useless reports as well as to fix as many bugs as possible within the day of the sprint. Well, the results are not bad, as the image below shows.

download

Numbers are as follow:

  • Improvements closed 103 (9 fixed – remainder failed to attract budget/interest after quite some time)
  • Bugs closed 35 (25 fixed – followed by 6 won’t fix, 3 cannot reproduce, 1 not a bug )
  • New Feature 14 (2 fixed – with 12 not a bug)
  • Task 9 (2 fixed – with 7 not a bug)
  • Wish 2 (not a bug)
  • Subtask 1
  • TOTAL 164

You can check the live report here:

  • Thanks to everybody who participated (a list of the participating people can be found in this spreadsheet).
  • As noted above many new features/improvements/wishes were quite old and had failed to attract budget/volunteers
  • The not-a-bug category is used for ideas or conversations which are best taken to the developers or users list for discussion
  • Not shown is the review of incoming issues to see which issues are ready to be worked on, or held back for further clarification before they can be reproduced.

If you did not participate this month don’t worry, we are going to have this event again on August 27-28th as part of the foss4g post-sprint. Remember, we want to make this event a periodic gathering so keep following this blog for news.

Happy GeoServer to everybody!

Categories: OSGeo Planet

gvSIG Team: Presencia de gvSIG en eventos durante el próximo trimestre (Agosto-Octubre 2016)

OSGeo Planet - Tue, 2016-07-26 12:44

El próximo trimestre van a ser varios los eventos bien centrados en gvSIG o en los que gvSIG estará presente. Para todos aquellos que nos siguen y estén interesados, os dejamos una relación de estas actividades:

Agosto

Septiembre

  • 3as Jornadas gvSIG México
    • Fechas: del 7 al 9.
    • Lugar: Ciudad de México (México).
    • Actividades: El programa se publicará en breve, pero ya os podemos adelantar que habrá un buen número de talleres de todo tipo -para usuarios y desarrolladores- y decenas de ponencias.
    • Más información: http://www.gvsig.com/es/eventos/jornadas-mexico/2016
  • 5as Jornadas gvSIG Brasil
  • Geostat 2016
    • Fechas: del 18 al 24
    • Lugar: Albacete (España).
    • Actividades: Taller/curso de gvSIG aplicado a estadística.
    • Más información: http://geostat-course.org/2016
  • Inspire Conference 2016
  • JIIDE 2016
    • Fechas: del 27 al 30.
    • Lugar: Barcelona (España).
    • Actividades: 6 ponencias principalmente relacionadas con proyectos de Infraestructuras de Datos Espaciales en los que se ha aplicado gvSIG Online. También se hablará de las novedades de la versión 2.3 de gvSIG Desktop.
    • Más información: http://www.jiide.org/

Octubre

  • 8as Jornadas de Latinoamérica y el Caribe de gvSIG
  • III Congreso Internacional de Ingenieria Topográfica, Agrimensura, Ambiental, Catastro, Geodesia y Geomática.
    • Fechas: del 26 al 29.
    • Lugar: Puno (Perú).
    • Actividades: a definir (probablemente ponencias y taller de gvSIG Desktop)
    • Más información: Web todavía no disponible.
  • TOPCART 2016
    • Fechas: del 26 al 30.
    • Lugar: Toledo (España)
    • Actividades: 6 ponencias en los que hablaremos sobre proyectos y tecnologías como gvSIG Online, gvSIG Roads, gvSIG Desktop.
    • Más información: http://topcart2016.com/

Filed under: events, spanish
Categories: OSGeo Planet

Fernando Quadro: Análise e visualização de dados LiDAR – Parte 6

OSGeo Planet - Tue, 2016-07-26 12:37

Agora que temos dados de elevação e altura em nossos edifícios podemos fazer um indicador ainda mais atraente visualmente.

1. Na guia “Dados”, clique no botão “Atualizar tipo de recurso”, para que GeoServer esteja ciente dos novos atributos z e z_diff.

gs_reloadft

2. Dentro do diretório de dados, localize a pasta workspaces/opengeo/lidar/buildings

3. Criar um arquivo de texto com o nome height.ftl no diretório mencionado acima com o conteúdo: ${height.value}

4. É isso aí! Agora abra a camada KML no Google Earth e dê zoom até se aproximar dos edifícios para ver o resultado.

5. http://localhost:8080/geoserver/wms/kml?layers=opengeo:buildings&mode=refresh&kmscore=50&format_options=lookatbbox:bbox=-122.8808,42.3311,-122.8806,42.3313

ge_buildings

Se você explorar a visualização em 3D dos edifícios por um tempo, você pode se deparar com alguns bairros ímpares, como este.

ge_buildings_trees1

Se você perceber na imagem acima 3 edifícios parecem um pouco fora do lugar nesta área residencial, e a torre no quintal? Algo está errado.

O que estamos vendo é o efeito das árvores nos dados LIDAR. Os pulsos de laser estão refletindo em volta das árvores, bem como nas casas fazendo com que a altitude média de pontos dentro dos polígonos das edificações sejam artificialmente infladas.

Como podemos corrigir isso?

Os dados LIDAR refletidos das árvores irá gerar mais de uma reflexão de retorno para cada pulso de saída, e quanto mais longe a reflexão, maior o tempo de retorno da luz. Ao invés de gerar nossas alturas dos edifícios como a média de todos os pontos LIDAR, queremos a média apenas os últimos retornos para cada pulso; os retornos que são os mais profundos.

Uma solução simples é dar peso aos retornos, de modo que em áreas de tipos de retorno mistos os retornos mais profundas têm mais peso. Podemos fazer isso ser substituindo a nossa função AVG no cálculo LIDAR com uma média ponderada:

-- numerator
Sum(CASE WHEN PC_Get(pts,'ReturnNumber') = 1
THEN PC_Get(pts, 'z')
WHEN PC_Get(pts,'ReturnNumber') = 2
THEN 10*PC_Get(pts, 'z')
ELSE 100*PC_Get(pts, 'z') END) /
-- denominator
Sum(CASE WHEN PC_Get(pts,'ReturnNumber') = 1
THEN 1
WHEN PC_Get(pts,'ReturnNumber') = 2
THEN 10
ELSE 100 END) AS z

Agora estamos prontos para voltar a executar o nosso cálculo de elevação e nosso cálculo de altura para ver o efeito sobre a saída do final KML.

-- Update into the buildings Z column
UPDATE buildings SET z = elevs.z
FROM (
-- For every building, all intersecting patches
WITH patches AS (
SELECT
buildings.gid AS buildings_gid,
medford.id AS medford_id,
medford.pa AS pa
FROM medford
JOIN buildings
ON PC_Intersects(pa, geom)
),
-- Explode those patches into points, remembering
-- which building they were associated with
pa_pts AS (
SELECT buildings_gid, PC_Explode(pa) AS pts FROM patches
)
-- Use the building associations to efficiently
-- spatially test the points against the building footprints
-- Summarize per building
SELECT
buildings_gid,
-- Use a weighted average that heavily favors
-- multi-return pulses
Sum(CASE WHEN PC_Get(pts,'ReturnNumber') = 1
THEN PC_Get(pts, 'z')
WHEN PC_Get(pts,'ReturnNumber') = 2
THEN 10*PC_Get(pts, 'z')
ELSE 100*PC_Get(pts, 'z') END) /
Sum(CASE WHEN PC_Get(pts,'ReturnNumber') = 1
THEN 1
WHEN PC_Get(pts,'ReturnNumber') = 2
THEN 10
ELSE 100 END) AS z
FROM pa_pts
JOIN buildings
ON buildings.gid = buildings_gid
WHERE ST_Intersects(buildings.geom, pts::geometry)
-- Only use the last returns in this calculation
AND PC_Get(pts,'ReturnNumber') = PC_Get(pts,'NumberOfReturns')
GROUP BY buildings_gid
) AS elevs
-- Join calculated elevations to original buildings table
WHERE elevs.buildings_gid = gid;

-- Update the building heights by subtracting elevation of
-- the nearest street from the elevation of the building
UPDATE buildings SET height = heights.height
FROM (
WITH candidates AS (
SELECT
b.gid AS building_gid,
s.gid AS street_gid,
s.z AS streets_z,
b.z as buildings_z
FROM buildings b, streets s
WHERE ST_DWithin(b.geom, s.geom, 0.001)
ORDER BY
building_gid,
ST_Distance(b.geom, s.geom)
)
SELECT DISTINCT ON (building_gid)
building_gid, street_gid,
buildings_z - streets_z AS height
FROM candidates
) AS heights
WHERE heights.building_gid = buildings.gid;

Agora temos uma nova visualização para os edifícios em 3D. Você pode verificar que a torre está a metade do tamanho, e as edificações foram reduzidas em muitos andares.

ge_buildings_trees2

Este tutorial é uma tradução e adaptação livre do artigo “Analyzing and Visualizing LIDAR” publicado no site da Boundless.

Fonte: Boundless

Posts RelacionadosZemanta
Categories: OSGeo Planet

GeoSolutions: Developer’s Corner: dynamic raster palettes and other spatiotemporal extensions for GeoServer

OSGeo Planet - Mon, 2016-07-25 14:23

redblue-editor

Dear Reader,

today we would like to introduce a new community module that we have been working on: ncWMS like extensions to perform easy dynamic mapping over raster data.

The first change introduced by the extension is the ability to easily add dynamic color palettes that will be applied on single banded raster data based on their statistics, but with the ability to control range and palette application from request parameters too. For example, let's say we want to create a simple red to blue progression, with the ncWMS extension installed we can simply create a new style, choose the "dynamic palette" format, and enumerate the two colors:

redblue-editor Then, let's make sure the layer band configuration has a range consistent with the data, in this case, a very narrow one:

Selezione_006

Finally, we can make a simple request that will use the dynamic palette against the configured range:

countries_flexpart1

You can also try dynamically on this link: http://cloudsdi.geo-solutions.it/geoserver/wms?STYLES=,redblue&LAYERS=countries,flexpart&FORMAT=image%2Fpng8&SERVICE=WMS&VERSION=1.1.1&REQUEST=GetMap&SRS=EPSG%3A4326&BBOX=-137,15,-110,42&WIDTH=600&HEIGHT=600

The dynamics of the data appears to favor the low values, it's possible to enhance the high portion by using a logarithmic palette instead, by adding "&logscale=true" to the request, this way: http://cloudsdi.geo-solutions.it/geoserver/wms?STYLES=,redblue&LAYERS=countries,flexpart&FORMAT=image%2Fpng8&SERVICE=WMS&VERSION=1.1.1&REQUEST=GetMap&SRS=EPSG%3A4326&BBOX=-137,15,-110,42&WIDTH=600&HEIGHT=600&logscale=true

countries_flexpart2

It's also possible to concentrate on a specific range using the "&colorscalerange=0.00001,0.0002", as follows: http://cloudsdi.geo-solutions.it/geoserver/wms?STYLES=,redblue&LAYERS=countries,flexpart&FORMAT=image%2Fpng8&SERVICE=WMS&VERSION=1.1.1&REQUEST=GetMap&SRS=EPSG%3A4326&BBOX=-137,20,-110,42&WIDTH=600&HEIGHT=500&colorscalerange=0.00001,0.0002

countries_flexpart3

Finally, one can generated an animation providing a time or elevation range, asking for the GIF format, and adding the "&animation=true" (here, with a different, more complex palette): http://cloudsdi.geo-solutions.it/geoserver/wms?STYLES=,x-Sst&LAYERS=countries,flexpart&FORMAT=image%2Fgif&SERVICE=WMS&VERSION=1.1.1&REQUEST=GetMap&SRS=EPSG%3A4326&BBOX=-137,20,-110,42&WIDTH=600&HEIGHT=500&time=2016-02-01/2016-03-01&animation=true&format_options=gif_loop_continuosly:true;gif_frames_delay:200

countries_flexpart

The official documentation provides more insight into these new features, while the module can be already downloaded as part of the GeoServer 2.10.x nightly builds (it's a development series):

If you want to know more about how we can help your organization, don't hesitate and get in touch with us! Make sure to check our Enterprise Services Offer which has been used to complete the work described in this post.

The GeoSolutions Team,

Geosolutions
Categories: OSGeo Planet

Fernando Quadro: Análise e visualização de dados LiDAR – Parte 5

OSGeo Planet - Mon, 2016-07-25 10:30

Para o nosso exemplo de hoje vamos dar um zoom e encontrar um edifício para analisar (se você aumenta o zoom, os edifícios se tornam clicáveis).

building_81719

Podemos ver que o edifício #81719 (identificador da chave primária do banco de dados) tem um número limitado de atributos, incluindo uma elevação de 1.446,43! Nossos dados LIDAR variam cerca de 450 metros, de modo que a elevação nos edifícios é provavelmente medida em pés.

Como podemos calcular a elevação para o edifício #81719 utilizando a tabela LIDAR? Veja como a lógica funciona visualmente:

1. Comece com o edifício.

pc_analysis_1

2. Localize todos os patches que se cruzam naquele edifício.

pc_analysis_2

3. Transforme essas manchas em pontos individuais.

pc_analysis_3

4. Filtre esses pontos usando o contorno do edifício.

pc_analysis_4

5. Finalmente a média dos pontos de elevações dará um valor para o edifício.

Veja o procedimento acima em SQL:

-- We run a set of subqueries sequentially using
-- the "with" keyword
WITH
-- Get the one building we are interested in
building AS (
  SELECT geom FROM buildings
  WHERE buildings.gid = 81719
),
-- All the patches that intersect that building
patches AS (
  SELECT pa FROM medford
  JOIN building ON PC_Intersects(pa, geom)
),
-- All the points in that patch
pa_pts AS (
  SELECT PC_Explode(pa) AS pts FROM patches
),
-- All the points in our one building
building_pts AS (
  SELECT pts FROM pa_pts JOIN building
  ON ST_Intersects(geom, pts::geometry)
)
-- Summarize those points by elevation
SELECT
  Avg(PC_Get(pts, 'z')) AS lidar_meters
FROM building_pts;

O resultado do SQL é 441.075 metros, que em pés é 1447.1, quase exatamente o mesmo valor do arquivo de edifícios, 1.446,43!

Ok! Porém podemos acrescentar a elevação a partir da nossa imagem LIDAR para todos os nossos edifícios? Sim, mas vai demorar algum tempo de processamento. Primeiro vamos adicionar uma coluna para aceitar o valor, e então executar uma atualização na nossa tabela do banco de dados.

-- Add column for our calculate Z value
ALTER TABLE buildings ADD COLUMN z real;
-- Update into the column
UPDATE buildings SET z = elevs.z
FROM (
  -- For every building, all intersecting patches
  WITH patches AS (
    SELECT
      buildings.gid AS buildings_gid,
      medford.id AS medford_id,
      medford.pa AS pa
    FROM medford
    JOIN buildings
    ON PC_Intersects(pa, geom)
  ),
  -- Explode those patches into points, remembering
  -- which building they were associated with
  pa_pts AS (
    SELECT buildings_gid, PC_Explode(pa) AS pts FROM patches
  )
  -- Use the building associations to efficiently
  -- spatially test the points against the building footprints
  -- Summarize per building
  SELECT
    buildings_gid,
    Avg(PC_Get(pts, 'z')) AS z
  FROM pa_pts
  JOIN buildings
  ON buildings.gid = buildings_gid
  WHERE ST_Intersects(buildings.geom, pts::geometry)
  GROUP BY buildings_gid
) AS elevs
-- Join calculated elevations to original buildings table
WHERE elevs.buildings_gid = gid;

Nossa tabela está atualizada! Confira as elevações originais e calculadas (temos que converter a coluna z de metros para pés para compará-la com a coluna elevação):

SELECT z AS z_m, z*3.28084 AS z_ft, elevation AS elevation_ft
FROM buildings;

Os valores estão bem próximos, veja:

   z_m | z_ft | elevation_ft 
--------- + ------------------ + --------------- 
 438,128 | 1.437,42663560303 | 1434.43000000 
 433,556 | 1.422,4291678418 | 1413.63200000 
 435,489 | 1.428,76987573853 | 1406.25400000 
 439,244 | 1.441,09014682129 | 1422.58200000 
 433,738 | 1.423,02460105347 | 1416.93600000 
 429,648 | 1.409,60687857788 | 1403.92400000 
 437,264 | 1.434,59264585083 | 1425.84000000 
 430,607 | 1.412,75115040894 | 1404.03675300

Vamos colocar a diferença de elevação (em metros) na tabela, veja como:

-- Add column for our calculated height
ALTER TABLE buildings ADD COLUMN height real;
-- Update the building heights by subtracting elevation of
-- the nearest street from the elevation of the building
UPDATE buildings SET height = heights.height
FROM (
  WITH candidates AS (
    SELECT
      b.gid AS building_gid,
      s.gid AS street_gid,
      s.z AS streets_z,
      b.z as buildings_z
    FROM buildings b, streets s
    WHERE ST_DWithin(b.geom, s.geom, 0.001)
    ORDER BY
      building_gid,
      ST_Distance(b.geom, s.geom)
  )
  SELECT DISTINCT ON (building_gid)
    building_gid, street_gid,
    buildings_z - streets_z AS height
  FROM candidates
) AS heights
WHERE heights.building_gid = buildings.gid;

No próximo post, finalizaremos nossa série de posts sobre LiDAR, não perca!

Posts RelacionadosZemanta
Categories: OSGeo Planet

Free and Open Source GIS Ramblings: OSM turn restriction QA with QGIS

OSGeo Planet - Sat, 2016-07-23 16:10

Wrong navigation instructions can be annoying and sometimes even dangerous, but they happen. No dataset is free of errors. That’s why it’s important to assess the quality of datasets. One specific use case I previously presented at FOSS4G 2013 is the quality assessment of turn restrictions in OSM, which influence vehicle routing results.

The main idea is to compare OSM to another data source. For this example, I used turn restriction data from the City of Toronto. Of the more than 70,000 features in this dataset, I extracted a sample of about 500 turn restrictions around Ryerson University, which I had the pleasure of visiting in 2014.

As you can see from the following screenshot, OSM and the city’s dataset agree on 420 of 504 restrictions (83%), while 36 cases (7%) are in clear disagreement. The remaining cases require further visual inspection.

toronto_turns_overview

The following two examples show one case where the turn restriction is modelled in both datasets (on the left) and one case where OSM does not agree with the city data (on the right).
In the first case, the turn restriction (short green arrow) tells us that cars are not allowed to turn right at this location. An OSM-based router (here I used OpenRouteService.org) therefore finds a route (blue dashed arrow) which avoids the forbidden turn. In the second case, the router does not avoid the forbidden turn. We have to conclude that one of the two datasets is wrong.

turn restriction in both datasets missing restriction in OSM?

If you want to learn more about the methodology, please check Graser, A., Straub, M., & Dragaschnig, M. (2014). Towards an open source analysis toolbox for street network comparison: indicators, tools and results of a comparison of OSM and the official Austrian reference graph. Transactions in GIS, 18(4), 510-526. doi:10.1111/tgis.12061.

Interestingly, the disagreement in the second example has been fixed by a recent edit (only 14 hours ago). We can see this in the OSM way history, which reveals that the line direction has been switched, but this change hasn’t made it into the routing databases yet:

now before

This leads to the funny situation that the oneway is correctly displayed on the map but seemingly ignored by the routers:

toronto_okeefe_osrm

To evaluate the results of the automatic analysis, I wrote a QGIS script, which allows me to step through the results and visually compare turn restrictions and routing results. It provides a function called next() which updates a project variable called myvar. This project variable controls which features (i.e. turn restriction and associated route) are rendered. Finally, the script zooms to the route feature:

def next(): f = features.next() id = f['TURN_ID'] print "Going to %s" % (id) QgsExpressionContextUtils.setProjectVariable('myvar',id) iface.mapCanvas().zoomToFeatureExtent(f.geometry().boundingBox()) if iface.mapCanvas().scale() < 500: iface.mapCanvas().zoomScale(500) layer = iface.activeLayer() features = layer.getFeatures() next()

You can see it in action here:

I’d love to see this as an interactive web map where users can have a look at all results, compare with other routing services – or ideally the real world – and finally fix OSM where necessary.

This work has been in the making for a while. I’d like to thank the team of OpenRouteService.org who’s routing service I used (and who recently added support for North America) as well as my colleagues at Ryerson University in Toronto, who pointed me towards Toronto’s open data.


Categories: OSGeo Planet

MapProxy: New MapProxy 1.9.0 release

OSGeo Planet - Fri, 2016-07-22 19:00

We are pleased to announce the release of MapProxy 1.9.0. It contains a lot of major and minor improvements.

The latest release is available at: https://pypi.python.org/pypi/MapProxy

To upgrade within your virtualenv:

$ pip install --upgrade --no-deps MapProxy

Updated documentation is available at: https://mapproxy.org/docs/1.9.0/

Support for ArcGIS REST services

You can now directly integrate ArcGIS services without the need to enable WMS support.

See: https://mapproxy.org/docs/1.9.0/sources.html#arcgis-label

Band merging

The new band merge feature allows you to create false-color or grayscale images on the fly, by selecting different sources for each (color) band.

See https://mapproxy.org/docs/1.9.0/configuration.html#band-merging and https://mapproxy.org/docs/1.9.0/configuration_examples.html#create-grayscale-images

Other fixes and changes

There are many more changes and improvements. For a complete list of see: http://github.com/mapproxy/mapproxy/blob/1.9.0/CHANGES.txt

Categories: OSGeo Planet

QGIS Blog: QGIS 2.16 ‘Nødebo’ is released!

OSGeo Planet - Fri, 2016-07-22 14:41

We’re happy to announce the release of QGIS 2.16.0 ‘Nødebo’. The University of Copenhagen’s Department of Geoscience and Natural Resource Management Forest and Landscape College in Nødebo were hosts to the First International QGIS conference and developer meeting in May 2015. For all of us who are not fluent in Danish, Lene Fischer has prepared the following video teaching us how to pronounce the release name:

QGIS 2.16 is not designated as a Long Term Release (LTR). Users wishing to have a version of QGIS which does not change and receives bug fixes for at least 1 year are invited to use the current LTR release 2.14.
If you are upgrading from QGIS 2.14 you will find a great many new features in this release.
Whenever new features are added to software they introduce the possibility of new bugs – if you encounter any problems with this release, please file a ticket on the QGIS Bug Tracker.

We would like to thank the developers, documenters, testers and all the many folks out there who volunteer their time and effort (or fund people to do so). From the QGIS community we hope you enjoy this release! If you wish to donate time, money or otherwise get involved in making QGIS more awesome, please wander along to qgis.org and lend a hand!

QGIS is supported by donors and sponsors. A current list of donors who have made financial contributions large and small to the project can be seen on our donors list. If you would like to become and official project sponsor, please visit our sponsorship page for details. Sponsoring QGIS helps us to fund our six monthly developer meetings, maintain project infrastructure and fund bug fixing efforts.

QGIS is Free software and you are under no obligation to pay anything to use it – in fact we want to encourage people far and wide to use it regardless of what your financial or social status is – we believe empowering people with spatial decision making tools will result in a better society for all of humanity. If you are able to support QGIS, you can donate here.


Categories: OSGeo Planet

Fernando Quadro: Fontes de dados geográficos gratuitos

OSGeo Planet - Fri, 2016-07-22 10:30

Quem trabalha com Geotecnologia sabe a dificuldade de encontrar dados geográficos. Apesar da INDE estar em “pleno funcionamento”, ainda estamos engatinhando nesse sentido. Temos poucos portais que disponibilizam informações geográfica se comparado ao tamanho do nosso país.

O LabGIS, após uma vasta pesquisa, compilou uma extensa base de 587 links com dados geográficos gratuitos para consulta e download. Essa base está agora aberta ao público, podendo ser acessada por qualquer pessoa.

Caso você conheça alguma fonte de dados que não consta nesta listagem você pode informá-los por meio desse link, ajudando assim a aumentar essa base pública e disponível a toda a comunidade.

Fonte: Sistema LabGIS

Posts RelacionadosZemanta
Categories: OSGeo Planet

Jackie Ng: React-ing to the need for a modern MapGuide viewer (Part 2): The baseline

OSGeo Planet - Thu, 2016-07-21 14:17
I've decided that cataloging my adventure in developing this viewer is enough to warrant its own blog mini-series. So here's part 2 of my adventure. I have no idea how many parts this will take :)

So to continue where we left off, we had a basic map viewer component built on the main pillars of
And it is all written in glorious TypeScript. I've mentioned once on a previous post that writing web frontend code in a language with static typing and a compilation phase (gasp!), with a clean and simple-to-understand component model offered by React is just heavenly! If I could go back in time, I'd have written the Fusion framework in TypeScript, but sadly it didn't exist around 2008 (when Fusion made its debut in MapGuide) and my involvement in the MapGuide project was nowhere near the level it is now.
So before I continue, I should also probably mention what I aim to achieve with this viewer:
  • It will be built on modern, best-of-breed web front-end technologies (React, OpenLayers 3, etc)
  • I will not be shackled with the burden of supporting legacy browsers. This viewer will demand a modern web browser. If one has to use Internet Explorer, it must be IE11
  • It will require MapGuide Open Source 3.0 as the minimal version as this viewer will leverage capabilities present in this particular version onwards.
  • It will at least have some level of feature parity with the AJAX/Fusion viewer offerings, that is to say:
    • It will have a Legend component for toggling layer visibility and comprehending layer symbology/thematics.
    • It will have a Task Pane component that functions as a generic container for content and/or contextual UI
    • It will have a Map Selection component for easy viewing of selected features
    • It will include a stock set of commands, with extension points for developers to add their own.
    • It will have opt-in integration with external base layers (OpenStreetMap, etc), provided your Map Definition meets the requirements (ie. It is in EPSG:3857/WGS84.PseudoMercator).
    • I will not at this time consider any kind of integration with Google Maps as their APIs are not only a constantly moving target, but a TOS minefield I just do not want to wander in at this point in time.
    • I do hope to allow for some level of free-form component layout (ala. templates) so one is not tied to a layout I choose by default.
So with that being said, for this post I want to focus on the last major bullet point: Getting to parity with our current viewer offerings.

So let's introduce our new Legend component.


Implementing this component wasn't difficult, I mainly copypasta'd most of the presentation logic from the existing feature-complete legend used in my various mapguide-rest sample applications.

The difference here is that because this is now a React component, there is zero jQuery or DOM manipulation. Instead, we are just render Group/Layer child components for each layer and group we encounter in our runtime map. It is all pure UI as a function of props and state, and letting React's virtual DOM figure out how to actually update the DOM in the most efficient manner. What this means is that our component model cleanly matches how our layers and groups are conceptually structured.


As for the other components, I'm still working on them (currently focused on the Task Pane) so we'll leave that for another post. But visually speaking, when you put these 3 items together:


It's already starting to look like our existing AJAX viewer!

And before I close out this post, In terms of our current JS bundle size, here's the results of the current weigh-in (using our current Fusion production bundle for comparison).



We've got plenty of breathing room.
Categories: OSGeo Planet

Fernando Quadro: Problema na internacionalização do GeoServer

OSGeo Planet - Thu, 2016-07-21 10:30

A partir da versão 2.8.3 foi adicionado ao GeoServer o idioma português (pt-BR), porém, ao que tudo indica ele foi criado a partir da versão em espanhol e disponibilizado sem que a tradução estivesse completa, ou seja, existem termos em português, espanhol e alguns até em inglês.

Se você está passando por esse problema, saiba que é possível retirar esses arquivos da sua versão do GeoServer e fazer com que ela volte a exibir as informações em inglês.

Para isso, basta seguir o passo-a-passo abaixo:

1. Renomeie o arquivo geoserver.war para geoserver.zip
2. Entre na pasta WEB-INF\lib
3. Encontre o arquivo gs-web-core-X.X.X.jar e renomei-o para .zip
4. Procure o arquivo de properties (GeoServerApplication_pt_BR.properties).
5. Exclua o arquivo
6. Renomeie o arquivo gs-web-core-X.X.X.zip para gs-web-core-X.X.X.jar
6.1. Repita os passos 3, 4, 5 e 6 para os arquivos:

  • gs-web-demo-X.X.X.jar
  • gs-web-sec-core-X.X.X.jar
  • gs-web-gwc-X.X.X
  • gs-web-wcs-X.X.X.jar
  • gs-web-wfs-X.X.X.jar
  • gs-web-wms-X.X.X.jar

7. Renomeie o arquivo geoserver.zip para geoserver.war.
8. Agora está pronto, basta subir sua aplicação e verificar se está tudo em inglês novamente.

Caso esteja utilizando a versão binária, executável (Windows) ou DMG (Mac), desconsidere os passos 1 e 7, e lembre-se que onde está indicado X.X.X você deve substituir pelo número da versão do GeoServer que você está utilizando no momento.

Qualquer problema, não deixe de comentar nesse post.

Posts RelacionadosZemanta
Categories: OSGeo Planet

Free and Open Source GIS Ramblings: One “add” button to rule them all

OSGeo Planet - Wed, 2016-07-20 19:46

Reducing the number of “Add layer” buttons in the QGIS GUI is a commonly voiced wish. Multiple approaches have been discussed but no decision has been made so far. One idea is to use the existing browser functionality to replace the “Add layer” dialogs. Others are envisioning completely novel approaches.

Since the topic came up again today on Twitter, I decided to implement a quick & dirty version of a unified Add layer button. This way, I can comfortably reduce my Layer toolbar to three buttons using Settings | Customization …

layerToolBar

customization

I pretty much just kept the “Create new layer” button and the “Add delimited text layer” button because, as far as I know, there is no way to call the dialog from the browser. (Instead, CSVs are opened with OGR, which doesn’t have nearly as many nice features.)

And here it is in action:

(I recommend to undock the Browser panel to get the dialog-like behavior that you see in the video.)

To install the plugin: download it and unzip it into your QGIS plugin folder, then activate it in the plugin manager.

I would love to hear what you think about this UX experiment.


Categories: OSGeo Planet

gvSIG Team: “Introduction to gvSIG” free online workshops

OSGeo Planet - Wed, 2016-07-20 11:20

The gvSIG Association is now pleased to inform the “Introduction to gvSIG” summer webinars at the beginning of August.

Summer has arrived in a lot of places around the world. This is a good time to learn to use gvSIG, the open source GIS.

Do you want to create a thematic map with gvSIG or a new vector layer with your parcel, a road…? You can do it now at these open and free webinars.

There will be two webinars, that will last about 30 minutes:

At the first webinar we’ll see how to manage a gvSIG project. We’ll create new views with cartography, and we’ll apply symbology and labelling. We’ll introduce the reference systems, and finally we will create a thematic map to be printed or exported to a PDF file.

At the second webinar, we’ll show how to create a new vector layer, where we’ll digitalize several elements. We also will see the gvSIG toolbox, where we can find all the geoprocesses. We will apply one of them. We finally will see how the 3D extension works.

Registration for the “Getting started with gvSIG” webinar

Registration for the “Vector editing, 3D view and other gvSIG tools” webinar

We expect your participation!


Filed under: community, english, events, gvSIG Desktop, training Tagged: introduction to gvSIG, webinar
Categories: OSGeo Planet
Syndicate content