OSGeo Planet

Blog 2 Engenheiros: Como criar seu primeiro plugin para QGIS usando Python e Qt Designer? Parte II

OSGeo Planet - Tue, 2018-07-24 06:01

Na postagem anterior, aprendemos a criar a base de arquivos para criarmos nosso plugin no QGIS. Nesta postagem, daremos continuidade nele e vamos salvar o arquivo shapefile criado (pois no código anterior, ele era temporário).

Além disso, iremos extrair, a partir do ponto criado, em qual parte de um determinado shapefile o ponto se localiza (por exemplo, em qual zoneamento da cidade o ponto se encontra).

Como salvar um shapefile no PyQGIS

Para salvar o shapefile criado, vamos acrescentar um campo no Qt Designer para que o usuário possa identificar o local onde o shape será salvo e em seguida vamos modificar o código Python para que ele armazene corretamente esse dado.

No Qt Design, iremos adicionar:

  • Um item “Label” com um texto mostrando para o usuário que o campo ao lado deve ser utilizado para colocar o endereço onde o shapefile será salvo;
  • Um item “Line Edit”, o qual irá mostrar o endereço escolhido; e
  • Um item “Push Button”, no qual o usuário irá clicar e uma janela que possibilitará navegar no Windows e selecionar o caminho para salvar o shapefile.

Após adicionar estes itens, iremos renomear (no Object Inspector) o Line Edit para “caminho”. O resultado é apresentado na figura abaixo.

Botão para guardar o caminho do shapefile.Botão para guardar o caminho do shapefile.

Agora que já adicionamos a interface gráfica, vamos modificar o código python para que o nosso sistema funcione.

Antes da função “def run(self)”, vamos criar uma função para ser executada quando o usuário clica no botão “…” ao lado do nosso “Line Edit”. O código para ser utilizado é apresentado abaixo:

## Função para obter o caminho onde será salvo o shapefile def selecionar_saida(self): arquivoCaminho = QFileDialog.getSaveFileName(self.dlg, "Salvar o arquivo em: ", "", "*.shp") self.dlg.caminho.setText(arquivoCaminho)

Agora, precisamos indicar por meio de python, que esta função será chamada quando apertarmos o botão “…”.

A função initGui é um bom local para adicionar conexões entre os botões e as ações executadas quando estes são pressionados (Germán Carrillo no GIS StackExchange).

Para isso, vamos até o topo do código python na função initGui e iremos inserir as seguintes linhas de código, onde a primeira linha limpa o campo (caso este já tenha sido preenchido) e o segundo indica que a função “selecionar_saida” deverá ser chamada quando ele for clicado.

## Esse código deverá ser inserido dentro de def initGui(self). self.dlg.caminho.clear() self.dlg.pushButton.clicked.connect(self.selecionar_saida)

Note que ainda precisamos modificar o código apresentado na postagem anterior para que este receba como variável o endereço onde salvamos o shapefile.

Apresentamos abaixo o código da postagem anterior mais o código adicionado nesta postagem (o qual é iniciado com duas hashtags ##). Lembrando que este código foi inserido dentro da função def run(self) (e dentro de if result:).

# Variáveis que recebem as coordenadas fornecidas pelo usuário (e projeção) longX = self.dlg.longTextIn.text() latY = self.dlg.latTextIn.text() projecao = self.dlg.projEPSG.text() ## Variável com o caminho salvo localSalvo = self.dlg.caminho.text() # Cria um shapefile de ponto a partir das coordenadas fornecidas # Definindo a geometria do shapefile camada = QgsVectorLayer('Point?crs=epsg:'+projecao, 'point' , 'memory') # Define o provedor os pontos fornecidos prov = camada.dataProvider() prov.addAttributes([QgsField("Nome", QVariant.String)]) ## Fornece atributos ao nosso ponto ponto = QgsPoint(float(longX),float(latY)) # Adiciona uma nova feição para a geometria feat = QgsFeature() feat.setGeometry(QgsGeometry.fromPoint(ponto)) feat.setAttributes(["Ponto B2E"]) ## Linha adicionada para fornecer atributo ao ponto prov.addFeatures([feat]) # Atualiza a camada camada.updateExtents() camada.updateFields() ## Atualiza os campos adicionados # Adiciona a camada ao QGIS QgsMapLayerRegistry.instance().addMapLayers([camada]) ## Salva a camada na variável localSalvo QgsVectorFileWriter.writeAsVectorFormat(camada, localSalvo, "utf_8_encode", camada.crs(), "ESRI Shapefile") pnt_layer = QgsVectorLayer(localSalvo, "Ponto B2E", "ogr")

Desta forma, conseguimos criar um shapefile e salvá-lo no nosso computador. Agora vamos criar uma função para estabelecer uma área de interesse e verificar se nosso ponto esta ou não dentro dela.

Lembre-se de adicionar, no topo do código python, junto com com os outros códigos do tipo from … import …, a seguinte linha “from PyQt4.QtCore import *”.

Intersecção de Ponto e Polígonos no PyQGIS

Agora, iremos criar um campo no nosso plugin onde o usuário irá marcar qual é a área de interesse (ou shapefile) que este deseja avaliar. Em outras palavras, vamos responder a seguinte pergunta: em qual zoneamento/bacia hidrográfica/região o ponto criado está inserido?

Para este tutorial, iremos utilizar dois shapefiles, um deles contendo os limites das bacias hidrográficas do município do Rio de Janeiro e outro com as regiões de planejamento do mesmo município.

Cabe lembrar que para executar a intersecção, os shapefiles envolvidos devem estar no mesmo sistema de coordenadas.

Os dois shapefiles indicados estão em um sistema de coordenadas antigo (SAD69) e no nosso tutorial, reprojetamos os shapefiles para SIRGAS 2000 UTM Zone 23S (ESPG: 31983).

Após realizar o download dos shapefiles, no Qt Designer, iremos adicionar dois Check Box, os quais indicarão para o usuário qual camada será avaliada, conforme a caixa esta marcada ou não.

Um dos checkbox será para o limite das bacias hidrográficas e outro para o limite das regiões de planejamento. O nome de cada um deles no Object Inspector é checkBoxRH e checkBoxRP, respectivamente.

Check Box adicionados no Qt Designer.Check Box adicionado no Qt Designer e seu respectivo nome no Object Inspector.

Agora que já temos nossas caixas para marcar a área de interesse, vamos adicionar o código que irá realizar a intersecção entre o ponto adicionado pelo usuário e a área selecionada.

O código seguinte deve ser inserido abaixo do código que apresentamos anteriormente, e em caso de dúvida, o código esta comentado, de forma a esclarecer as funções utilizadas.

## [....] Continuação do código anterior. ## Salva a camada na variável localSalvo QgsVectorFileWriter.writeAsVectorFormat(camada, localSalvo, "utf_8_encode", camada.crs(), "ESRI Shapefile") pnt_layer = QgsVectorLayer(localSalvo, "Ponto B2E", "ogr") ## Variáveis para a interseções pnt_selection = [] bh_selection = [] rp_selection = [] ## Condições para os checkboxs criados (Avaliação da Bacia Hidrográfica e da Região de Planejamento) ## Primeira condição para avaliar se o ponto cai em alguma bacia hidrográfica if self.dlg.checkBoxBH.isChecked(): bh_rioPath = "C:/Users/ferna/Desktop/municipiosRJ/bacia_hidroRJ_SIRGAS.shp" # Não esqueça de corrigir esse caminho no seu computador bh_rioLayer = QgsVectorLayer(bh_rioPath, "BH RJ", "ogr") for w in pnt_layer.getFeatures(): for s in bh_rioLayer.getFeatures(): if s.geometry().intersects(w.geometry()): ## Número dois foi usado pois o nome da bacia esta na terceira coluna (python começa a contar do zero) bh_selection.append(s.attributes()[2]) pnt_selection.append(w.attributes()[0]) break print pnt_selection[0] + " esta na " + bh_selection[0] elif not self.dlg.checkBoxBH.isChecked(): print u"O item Bacias Hidrográficas não foi selecionado." ## Segunda condição para avaliar se o ponto cai em alguma região de planejamento if self.dlg.checkBoxRP.isChecked(): rp_rioPath = "C:/Users/ferna/Desktop/municipiosRJ/limite_RP_SIRGAS.shp" # Não esqueça de corrigir esse caminho no seu computador rp_rioLayer = QgsVectorLayer(rp_rioPath, "RP RJ", "ogr") for w in pnt_layer.getFeatures(): for s in rp_rioLayer.getFeatures(): if s.geometry().intersects(w.geometry()): ## Número três foi usado pois o nome da região esta na quarta coluna (python começa a contar do zero) rp_selection.append(s.attributes()[3]) pnt_selection.append(w.attributes()[0]) break print pnt_selection[0] + u" esta na região de " + rp_selection[0] elif not self.dlg.checkBoxRP.isChecked(): print u"O item Região de Planejamento não foi selecionado."

Note que as rotinas (loops) para a avaliação da intersecção são semelhantes e terminam com break, de forma a realizar o loop apenas uma vez.

Você pode acessar ele clicando em Plugins > Python Controle, ou pelo atalho Ctrl + Alt + P.

O comando print do python irá exibir as mensagens que inserimos nesta linha, sendo que quando executamos o plugin no QGIS, essas mensagens serão exibidas no terminal python dele.

Plugin desenvolvido rodando e mensagens no terminal python.Plugin desenvolvido rodando e mensagens no terminal python.

O código que apresentamos irá funcionar corretamente se o usuário inserir pontos dentro das áreas de interesse, caso um ponto fora seja fornecido, um erro será gerado.

Então, como podemos evitar esse erro e só mostrar uma mensagem avisando o usuário que o ponto não esta dentro dos limites?

Tratando erros dentro do Python

Nesta situação, utilizaremos um bloco de código do tipo “try: …. except: ….”, onde o código que pode apresentar erro é inserido depois de try (tentar) e caso algum erro aconteça, o que o programa deve fazer é colocado depois de except.

Desta forma, no nosso código, onde havia somente “print pnt_selection[0] + ” esta na ” + bh_selection[0]”, substitua pelo código abaixo, sendo que o erro levantado, caso o ponto caia fora da área de interesse é do tipo IndexError.

try: print pnt_selection[0] + " esta na " + bh_selection[0] except IndexError: print u"O ponto fornecido esta fora da área de interesse!!"

E chegamos ao fim da segunda parte do nosso tutorial de como criar um plugin no QGIS utilizando Qt Designer e Python. Você pode conferir o código completo deste tutorial clicando aqui >> ponto_exatoB2E (Obs.: Abra o arquivo de texto no NotePad++ para que a indentação fique correta).

Em breve, iremos postar a terceira parte. E caso você tenha alguma dúvida, deixe ela nos comentários que responderemos assim que possível.

Referências consultadas: Ujaval Gandhi - QGIS Tutorials and Tips: https://www.qgistutorials.com/en/docs/building_a_python_plugin.html Python: How to List Polygon Intersections in QGIS: https://gifguide2code.com/2017/04/16/python-how-to-code-a-list-of-polygon-intersections-in-qgis/
Categories: OSGeo Planet

GeoTools Team: GeoTools 19.2 released

OSGeo Planet - Mon, 2018-07-23 23:57
The GeoTools team is pleased to announce the release of GeoTools 19.2: geotools-19.2-bin.zip geotools-19.2-doc.zip geotools-19.2-userguide.zip geotools-19.2-project.zip maven repository This release is the current stable release and as such users and downstream projects should consider moving from older releases to this one. This release is made in conjunction with GeoServer 2.13.2 and
Categories: OSGeo Planet

Fernando Quadro: State Of the Map – LATAM

OSGeo Planet - Fri, 2018-07-20 04:17

Prezados leitores,

Acontece esse ano a quarta edição do State Of The Map (SOTM) LATAM que será realizado na cidade de Buenos Aires, Argentina, nos dias 24 e 25 de setembro de 2018 no Centro Metropolitano de Diseño.

Este ano o evento vai contar com mais de 200 participantes de diferentes origens: local, nacional, regional e internacional.

Além disso, o evento agregará diferentes comunidades tecnológicas para além das relacionadas aos Sistema de Informação Geográfica, assim como contará com a presença de instituições públicas, privadas, acadêmicas e organizações sociais.

A mesma se realizará na mesma semana do Abrelatam (26/9) e do IODC (27 e 28/9) portanto, trata-se de uma ótima oportunidade para presenciar vários eventos internacionais.

Para mais informações e apresentar propostas de palestras, visite a página https://state.osmlatam.org/pt/ ou entrar em contato pelo e-mail: info@osmlatam.org

Categories: OSGeo Planet

Free and Open Source GIS Ramblings: Movement data in GIS #15: writing a PL/pgSQL stop detection function for PostGIS trajectories

OSGeo Planet - Thu, 2018-07-19 21:31

Do you sometimes start writing an SQL query and around at line 50 you get the feeling that it might be getting out of hand? If so, it might be useful to start breaking it down into smaller chunks and wrap those up into custom functions. Never done that? Don’t despair! There’s an excellent PL/pgSQL tutorial on postgresqltutorial.com to get you started.

To get an idea of the basic structure of a PL/pgSQL function and to proof that PostGIS datatypes work just fine in this context, here’s a basic function that takes a trajectory geometry and outputs its duration, i.e. the difference between its last and first timestamp:

CREATE OR REPLACE FUNCTION AG_Duration(traj geometry) RETURNS numeric LANGUAGE 'plpgsql' AS $BODY$ BEGIN RETURN ST_M(ST_EndPoint(traj))-ST_M(ST_StartPoint(traj)); END; $BODY$;

My end goal for this exercise was to implement a function that takes a trajectory and outputs the stops along this trajectory. Commonly, a stop is defined as a long stay within an area with a small radius. This leads us to the following definition:

CREATE OR REPLACE FUNCTION AG_DetectStops( traj geometry, max_size numeric, min_duration numeric) RETURNS TABLE(sequence integer, geom geometry) -- implementation follows here!

Note how this function uses RETURNS TABLE to enable it to return all the stops that it finds. To add a line to the output table, we need to assign values to the sequence and geom variables and then use RETURN NEXT.

Another reason to use PL/pgSQL is that it enables us to write loops. And loops I wanted for my stop detection function! Specifically, I wanted to go through all the points in the trajectory:

FOR pt IN SELECT (ST_DumpPoints(traj)).geom LOOP -- here comes the magic! END LOOP;

Eventually the function should go through the trajectory and identify all segments that stay within an area with max_size diameter for at least min_duration time. To test for the area size, we can use:

IF ST_MaxDistance(segment,pt) <= max_size THEN is_stop := true;

Putting everything together, my current implementation looks like this:

CREATE OR REPLACE FUNCTION AG_DetectStops( traj geometry, max_size numeric, min_duration numeric) RETURNS TABLE(sequence integer, geom geometry) LANGUAGE 'plpgsql' AS $BODY$ DECLARE pt geometry; segment geometry; is_stop boolean; previously_stopped boolean; stop_sequence integer; p1 geometry; BEGIN segment := NULL; sequence := 0; is_stop := false; previously_stopped := false; p1 := NULL; FOR pt IN SELECT (ST_DumpPoints(traj)).geom LOOP IF segment IS NULL AND p1 IS NULL THEN p1 := pt; ELSIF segment IS NULL THEN segment := ST_MakeLine(p1,pt); p1 := NULL; IF ST_Length(segment) <= max_size THEN is_stop := true; END IF; ELSE segment := ST_AddPoint(segment,pt); -- if we're in a stop, we want to grow the segment, otherwise we remove points to the specified min_duration IF NOT is_stop THEN WHILE ST_NPoints(segment) > 2 AND AG_Duration(ST_RemovePoint(segment,0)) >= min_duration LOOP segment := ST_RemovePoint(segment,0); END LOOP; END IF; -- a stop is identified if the segment stays within a circle of diameter = max_size IF ST_Length(segment) <= max_size THEN is_stop := true; ELSIF ST_Distance(ST_StartPoint(segment),pt) > max_size THEN is_stop := false; ELSIF ST_MaxDistance(segment,pt) <= max_size THEN is_stop := true; ELSE is_stop := false; END IF; -- if we found the end of a stop, we need to check if it lasted long enough IF NOT is_stop AND previously_stopped THEN IF ST_M(ST_PointN(segment,ST_NPoints(segment)-1))-ST_M(ST_StartPoint(segment)) >= min_duration THEN geom := ST_RemovePoint(segment,ST_NPoints(segment)-1); RETURN NEXT; sequence := sequence + 1; segment := NULL; p1 := pt; END IF; END IF; END IF; previously_stopped := is_stop; END LOOP; IF previously_stopped AND AG_Duration(segment) >= min_duration THEN geom := segment; RETURN NEXT; END IF; END; $BODY$;

While this function is not really short, it’s so much more readable than my previous attempts of doing this in pure SQL. Some of the lines for determining is_stop are not strictly necessary but they do speed up processing.

Performance still isn’t quite where I’d like it to be. I suspect that all the adding and removing points from linestring geometries is not ideal. In general, it’s quicker to find shorter stops in smaller areas than longer stop in bigger areas.

Let’s test! 

Looking for a testing framework for PL/pgSQL, I found plpgunit on Github. While I did not end up using it, I did use its examples for inspiration to write a couple of tests, e.g.

CREATE OR REPLACE FUNCTION test.stop_at_beginning() RETURNS void LANGUAGE 'plpgsql' AS $BODY$ DECLARE t0 integer; n0 integer; BEGIN WITH temp AS ( SELECT AG_DetectStops( ST_GeometryFromText('LinestringM(0 0 0, 0 0 1, 0.1 0.1 2, 2 2 3)'), 1,1) stop ) SELECT ST_M(ST_StartPoint((stop).geom)), ST_NPoints((stop).geom) FROM temp INTO t0, n0; IF t0 = 0 AND n0 = 3 THEN RAISE INFO 'PASSED - Stop at the beginning of the trajectory'; ELSE RAISE INFO 'FAILED - Stop at the beginning of the trajectory'; END IF; END; $BODY$;

Basically, each test is yet another PL/pgSQL function that doesn’t return anything (i.e. returns void) but outputs messages about the status of the test. Here I made heavy use of the PERFORM statement which executes the provided function but discards the results:

Categories: OSGeo Planet

Fernando Quadro: Palestra: Big Data aplicado a Gestão Ambiental

OSGeo Planet - Thu, 2018-07-19 07:02

Prezados Leitores,

Na próxima segunda-feira, dia 23 de Julho, estarei ministrando a palestra intitulada: “Big Data aplicado a Gestão Ambiental” a convite do Anderson Medeiros no Congresso Brasileiro de Geotecnologias para o Meio Ambiente.

Ele será um evento 100% Online. Serão mais de 20 palestras realizadas entre os dias 23 e 27 de julho de 2018.

Cliquem aqui para se inscrever: https://lnkd.in/drM_tV4

Categories: OSGeo Planet

GIS for Thought: Stanley Cup Champions Since 1915

OSGeo Planet - Wed, 2018-07-18 14:38

Stanley Cup Champions Since 1915:

Average Location of Stanley Cup Champions Since 1915:

The average locations were created using a window function in PostgreSQL. We can utilise the geography type to take into account the curvature of the earth and make the calculation on a spheroid.

So for the average location of the last five years:

select id, ST_Centroid(st_collect(geom) over (ORDER BY id ROWS BETWEEN 4 PRECEDING AND CURRENT ROW)::geography, True)::geometry as five_year_cent from nhl.winner_1915

Categories: OSGeo Planet

gvSIG Team: 10as Jornadas de Latinoamérica y Caribe de gvSIG: “Plataformas y Usuarios para la resolución de problemas”

OSGeo Planet - Tue, 2018-07-17 15:45

El 23 de agosto de 2018 se celebrarán las 10as Jornadas de Latinoamérica y Caribe de gvSIG en Santa María (Rio Grande do Sul – Brasil) bajo el lema “Plataformas y Usuarios para la resolución de problemas”, un nuevo encuentro para el intercambio de experiencias en el uso y desarrollo de gvSIG englobado en la Semana Geomática de la UFSM.

Ya está abierto el periodo para el envío de propuestas para comunicaciones para las Jornadas. Desde hoy pueden enviarse las propuestas a la dirección de correo electrónico artigojornadagvsig2018@gmail.com. Toda la información sobre las normas para la presentación de comunicaciones puede consultarse en el apartado de Comunicaciones de la web. El periodo de recepción de resúmenes finalizará el próximo 10 de agosto.

El periodo de inscripción a las mismas se abrirá el próximo día 25 de julio. La inscripción será gratuita.

¡Esperamos vuestras propuestas!

Categories: OSGeo Planet

Blog 2 Engenheiros: Como criar seu primeiro plugin para QGIS usando Python e Qt Designer? Parte I

OSGeo Planet - Tue, 2018-07-17 06:50

A automatização de tarefas auxilia enormemente vários profissionais. Já mostramos como a programação pode ajudar ao executar tarefas rotineiras em apenas algumas linhas de código (Veja a postagem sobre python clicando aqui).

Agora, vamos supor que você precise desenvolver uma interface gráfica para essa automatização, pois somente as linhas de programação não são suficiente. Para resolver este problema, vamos utilizar o Qt Designer.

Como vamos criar um plugin para o QGIS 2.18, lembre-se que este software já vem instalado junto com ele.

O que é o Qt Designer?

Em primeiro lugar, é importante definirmos o que é Qt.

O Qt é um programa multi-plataforma para desenvolvimento de interfaces gráficas para softwares. Desta forma, o Qt Designer é o programa que reúne todas essas ferramentas para nos auxiliar a desenvolver nosso plugin.

Interface gráfica do programa Qt Designer.Interface gráfica do programa Qt Designer.

É interessante notar que softwares como QGIS, Google Earth e VLC Media Player foram desenvolvidos utilizando o Qt.

Primeiros passos para criar um plugin no QGIS

Obviamente, você terá que ter instalado o QGIS, o qual irá trazer junto, o Qt Designer, basta procurar no seu menu iniciar por “Qt” e você irá localizar esse programa.

É interessante também que você tenha um bom editor de textos. Normalmente, quando trabalhamos com programação, você irá encontrar a recomendação de uso do NotePad++, o qual também recomendamos o uso (clique aqui para baixá-lo).

Agora, vamos instalar alguns plugins que irão nos ajudar a criar um plugin no QGIS, quem indica o uso desses plugins é o Ujaval Gandhi no QGIS Tutorials and Tips – o qual indica que sejam instalados os seguintes plugins:

  • Plugin Builder: Este plugin cria todos os arquivos necessários para o desenvolvimento de novos plugins.
  • Plugin Reloader: Facilita na atualização das alterações do seu plugin. Sem ele, você terá que ficar reiniciando o QGIS para que as suas alterações sejam apresentadas.

Para instalar esses plugins, dentro do QGIS, vá em Plugins > Gerenciar e Instalar Plugins (Complementos) e procure pelos nomes citados acima (lembrando que para o Plugin Reloader aparecer, você precisará ativar a opção “Mostrar Plugins Experimentais” na mesma janela, na aba Opções).

Onde ativar os plugins experimentais no QGIS.Onde ativar os plugins experimentais no QGIS. Criando os arquivos necessários

Agora vamos começar a criar os arquivos que são necessários para desenvolver nosso plugin de QGIS.

Com o QGIS aberto (neste tutorial, estamos usando a versão 2.18), vá em plugins e acesse o Plugin Builder. Assim que a janela do Plugin Builder abrir, ela vai solicitar para você algumas informações relacionada ao nosso plugin:

  • Class Name: Indica o nome da classe do python com o código do nosso plugin (também será o nome da pasta contendo todos os dados do nosso plugin);
  • Plugin Name: Nome que irá aparecer no gerenciador de plugins do QGIS;
    Description: Descrição do nosso plugin;
  • Module Name: Este será o nome do arquivo principal de python;
  • Text for the menu item: Texto que os usuários irão utilizar para buscar o plugin;
  • Author/Company: Nome do autor ou da empresa desenvolvedora;
  • Email Address: Email para contato;
  • Menu: Indica em qual categoria nosso plugin irá ser encaixado no menu do QGIS.

Não esqueça de marcar a caixa indicando que o plugin é experimental.

Acrescentando dados ao Plugin Builder para nosso Plugin.Acrescentando dados ao Plugin Builder para nosso Plugin.

Logo em seguida, ao clicar em Próximo (Next), será solicitado uma descrição mais detalhada do plugin. No nosso caso, iremos criar um plugin que irá receber as coordenadas fornecidas pelo usuário e irá criar um shapefile.

Não esqueça de marcar a caixa “Flag the plugin as experimental”.

Na última janela, você irá definir a pasta que será criado os arquivos do plugin, em seguida, clique em “Generate”. Para facilitar o processo de criação, já vamos salvar o plugin na pasta de plugins do QGIS, a qual localiza-se em “C:\Usuários\Nome do Usuário\.qgis2\python\plugins”.

Lembre-se que em “Nome do Usuário” irá aparecer o nome do usuário do seu computador.

Se tudo ocorrer corretamente, uma janela irá abrir confirmando a criação dos arquivos

Compilando os arquivos gerados

Antes de podermos utilizar nosso plugin, precisamos compilar os arquivos que acabamos de gerar. Para este procedimento, iremos utilizar o programa OSGeo4W Shell, o qual já vem instalado com o QGIS 2.18 – Busque por ele no seu menu iniciar ou na pasta do QGIS.

Terminal OSGeo4W com os comandos executados nesta postagem.Terminal OSGeo4W com os comandos executados nesta postagem.

Para compilar os arquivos criados, basta utilizarmos o comando “cd” para navegarmos até a pasta onde o plugin esta salvo e em seguida, utilizar os comandos “pyrcc4” para compilar os arquivos.

Esse procedimento irá converter o arquivo resources.qrc, para o formato python (.py) (BritishSteel em GIS StackExchange).

Copie e cole os códigos abaixo no OSGeo4W Shell, realizando as devidas substituições na pasta onde esta salvo o seu plugin e no nome dos arquivos (caso você tenha utilizado um nome diferente do nosso).

cd C:\Users\ferna\.qgis2\python\plugins\pontoExato\ pyrcc4 -o resources.py resources.qrc

Após esse procedimento, reinicie o QGIS e o plugin irá aparecer na sua tela conforme a figura abaixo.

Plugin Vazio no QGIS.Plugin Vazio no QGIS.

Note que agora sim, poderemos trabalhar na interface do nosso plugin no Qt Designer.

Trabalhando com Python e Qt Designer

Pelo menu iniciar, vá até a pasta do QGIS 2.18 e clique em “Qt Designer with QGIS 2.18.11 custom widgets”. Quando o programa abrir, uma janela será aberta solicitando se você quer abrir um arquivo novo ou abrir um existente – Clique em “Open” e procure pelo arquivo .ui na pasta do nosso plugin.

Arquivo a ser aberto no Qt Design.Como abrir um arquivo a ser aberto no Qt Design.

Na janela esquerda (widget box) do Qt Designer, há várias opções para você complementar seu plugin. Aqui, vamos inserir textos (para indicar ao usuário como ele deve inserir as coordenadas) e um campo para receber essas coordenadas.

  • Texto: Procure no Widget Box por Display Widgets, em seguida, arraste para o nosso plugin o item Label (três vezes, uma para o campo longitude e outro para a latitude e o último para o número do sistema de projeção);
  • Campos para Coordenadas: No Widget Box, busque por Input Widgets e adicione três Line Edit ao nosso plugin, para que o usuário insira as coordenadas e a projeção.

Lembre-se de trocar os nomes de cada botão e caixa de texto no Object Inpector do Qt Designer, pois é a partir desses nomes que nós vamos vincular as ações no código Python.

Neste exemplo, a caixa de texto com a longitude é chamada de longTextIn, latitude é chamada de latTextIn, e a do número do sistema de projeção, projEPSG.

Aparência e nomes dos objetos criados no Qt Designer.Aparência e nomes dos objetos criados no Qt Designer.

Após criar essa interface, vamos inserir alguns códigos em python no arquivo pontoExato.py (que encontra-se na pasta do nosso plugin) utilizando o NotePad++ para dizer ao computador como iremos manipular os dados fornecidos pelo usuário.

Primeiro, adicione QFileDialog à lista de importações no começo do arquivo (o resultado é o seguinte: “from PyQt4.QtGui import QAction, QIcon, QFileDialog”) e o qgis.core também (“from qgis.core import *”).

from PyQt4.QtCore import QSettings, QTranslator, qVersion, QCoreApplication from PyQt4.QtGui import QAction, QIcon, QFileDialog # Adicione o QFileDialog aqui. from qgis.core import * # Acrescente essa linha de código. # Initialize Qt resources from file resources.py import resources # Import the code for the dialog from ponto_exato_dialog import pontoExatoDialog import os.path

Em seguida, vá até o final do código e procure pela função run (“def run(self)”), onde dentro da condição “if result:”, você terá que inserir o seguinte código:

# Variáveis que recebem as coordenadas fornecidas pelo usuário (e projeção) longX = self.dlg.longTextIn.text() latY = self.dlg.latTextIn.text() projecao = self.dlg.projEPSG.text() # Definindo a geometria do shapefile camada = QgsVectorLayer('Point?crs=epsg:'+projecao, 'point' , 'memory') # Define o provedor os pontos fornecidos prov = camada.dataProvider() ponto = QgsPoint(float(longX),float(latY)) # Adiciona uma nova feição para a geometria feat = QgsFeature() feat.setGeometry(QgsGeometry.fromPoint(ponto)) prov.addFeatures([feat]) # Atualiza a camada camada.updateExtents() # Adiciona a camada ao QGIS QgsMapLayerRegistry.instance().addMapLayers([camada])

Ao adicionar esse código, salve o arquivo .py e abra o QGIS.

Com este novo plugin, você poderá adicionar pontos em locais específicos da sua área de estudo, lembrando sempre de conferir qual é o tipo de coordenada (geográfica decimal ou projetada) e qual é o datum dele.

Acompanhe o Blog 2 Engenheiros que em breve estaremos lançando a segunda parte deste tutorial, onde iremos incrementar as funcionalidades deste plugin.

Caso você tenha alguma dúvida ou ideia para melhorar este plugin, deixe ela nos comentários.

Referências consultadas: “How To” In QGIS: https://howtoinqgis.wordpress.com/2016/10/23/how-to-create-a-memory-layer-from-the-python-console/ QGIS Plugin Builder: http://g-sherman.github.io/Qgis-Plugin-Builder/ StackOverFlow - QGIS: add polygon by inputting coordinates: https://stackoverflow.com/questions/43674650/qgis-add-polygon-by-inputting-coordinates Ujaval Gandhi - QGIS Tutorials and Tips: https://www.qgistutorials.com/en/docs/building_a_python_plugin.html
Categories: OSGeo Planet

OTB Team: OTB at FOSS4G Europe 2018

OSGeo Planet - Mon, 2018-07-16 07:08
Hi all, I will be at FOSS4G Europe in Guimaraes, with a “What’s new” talk on Tuesday 16th at 15:35, and a workshop to learn how to use OTB from python on Friday 20th at 9:30 (I think there are still seats available for the workshop). I would be delighted to meet you there! See […]
Categories: OSGeo Planet

CARTO Inside Blog: Announcing CARTO.js v4.1

OSGeo Planet - Fri, 2018-07-13 10:00

It’s been three months since CARTO.js v4 reached the stable release state. Since then, we’ve been receiving very good feedback and researching what our customers are using the library for. Today, it’s my honor to introduce CARTO.js v4.1!

Focus on easier development

Our goal with the next milestone of CARTO.js is to help developers with the most common struggles we’ve seen so far. We’re introducing:

  • Buffer map changes: we take care of map changes so you don’t run into limit bottlenecks.
  • Source filters: an easier way to filter sources of data so you don’t have to maintain a heavy structure for filtering.
  • Histogram range: now you can ask a certain range to a histogram to focus on the data you find more interesting.
Buffering map changes

With CARTO.js v4, we introduced a shift on the way of creating applications with our library. Instead of an out-of-the-box solution, we provide now simpler building blocks that you can structure on top of your applications. That change is super powerful. You are now not restricted by what our solution provides. You can leverage your knowledge of Leaflet or Google Maps and use CARTO.js as another piece to answer your needs.

But with great power comes great responsability. CARTO.js map changes being programmatic means that now we can provoke changes in the map at the speed of light. We’ve seen applications making changes to lots of dataviews and layers at the same time, hitting our Engine platform limits. The solution was to structure better the application with those limits in mind. Until now.

In CARTO.js v4.1 we’re freeing developers from changing the code to avoid running into performance problems. Now we buffer your changes and apply them once they’re all finished. You don’t have to worry about that anymore. And the best part is that’s transparent. We do it under the hood so no changes in your code are needed to get advantage of it.

Source filtering

Another pain point we’ve seen during the last months is related to source filtering. The way you can filter your data (through a widget, through code… ) forced you to maintain a structure to build SQL sentences taking that filter into account. Not a big deal with one filter. A cumbersome task when combining lots of filters.

In CARTO.js v4.1 we’re introducing two source filters: the category filter and the range filter.

Category filter

One of the most common filtering actions in a map is to show some information that belongs to certain categories. With the category filter now you can tell a source to show only the data that has certain values in a column. Indeed, you can apply a broad criteria: in, not in, equal, not equal, like, similar to… Reference.

As an example, imagine you want to show apartment rental prices only in certaing districts. With the new category filter is as easy as:

const source = new carto.source.Dataset('apartments'); const districtFilter = new carto.filter.Category('district_group', { in: ['Diamond District', 'Tudor City', 'Little Brazil'] }); source.addFilter(districtFilter);

If you change your mind later, just set other values and the source will react to the new filter criteria.

districtFilter.set('in', ['Kips Bay', 'Gramercy Park', 'Flatiron District']);

More info in Category filter Developers reference.

Category Filter Range filter

The other common filtering action is to restrict the numeric information to certain values. It’s the operation made when selecting a range in a histogram, for instance.

As an example, imagine you want to show only locations with a rental price between 3K$ and 4K$. With the new range filter is as easy as:

const source = new carto.source.Dataset('apartments'); const priceFilter = new carto.filter.Range('price', { between: { min: 3000, max: 4000 } });

Of course, you can alter the filter afterwards.

priceFilter.setFilters({ between: { min: 4000, max: 5000 } });

More info in Range filter Developers reference.

Range Filter Combining filters

The real power comes when using several filters at the same time. As you can see in the examples documentation you can apply a filter as complex as you want and not worry about a single line of SQL code.

For instance, you could combine the two filters above (district and filter) with another one that only selects those apartments that rents the entire home or those who has recent reviews.

const filtersCombination = new carto.filter.AND([ neighbourhoodFilter, priceFilter, new carto.filter.OR([ entireHomeFilter, reviewsInLastYearFilter ]) ]);

We encourage you to take a look on the developers portal to learn about this great enhancement. Examples

Combined Filters Custom histogram range

In CARTO.js v4, we added dataviews, objects able to extract data from a dataset in predefined ways. One of them is the histogram dataview, used to represent the distribution of numerical data.

Until CARTO.js v4.1, the histogram operated on the whole range of the selected column. That is, if you wanted to get the histogram of the column price, the histogram showed the data from the minimum value in the whole dataset to the maximum one. Although this is very convenient and it’s the most likely way to use it, there are some cases where you want to focus on a particular range of the histogram. The typical example is a column where most of the data falls into one bin and the rest of them are empty because of the existence of outliers. In this case, the histogram doesn’t tell you the right insights and, probably, you want to ask for the data in the most populated bin.

In CARTO.js v4.1 the histogram dataview now provides two extra parameters: start and end.

const histogramDataview = new carto.dataview.Histogram( source, 'price', { bins: 5, start: 40, end: 60 } );

This dataview will return a histogram whose range goes from 40$ to 50$, instead of the whole price range.

We can’t wait to see your incredible location intelligence apps using these new features!!

Happy mapping!

Categories: OSGeo Planet

Fernando Quadro: Curso de GeoServer em Agosto

OSGeo Planet - Fri, 2018-07-13 06:57

Caros leitores,

Quero convidá-los a participarem do Curso Online de GeoServer que estarei ministrando pela GEOCURSOS. O objetivo do curso é que você aprenda a disponibilizar, compartilhar e editar dados geográficos na internet com o GeoServer.

No curso serão abordados tópicos como: configuração de dados, criação de estilo com SLD, padrões OGC, interface administrativa (web), visualização cartográfica com OpenLayers, REST API, Segurança, entre outros.

O curso ocorrerá entre os dias 21 e 30 de agosto (terças, quartas e quintas) das 20:00 as 22:00 (horário de Brasília).

Aqueles que poderem divulgar para seus contatos, agradeço. Quem quiser saber mais informações sobre o curso, pode obtê-las no site do curso (http://www.geocursos.com.br/geoserver), twitter (http://twitter.com/geo_cursos) e pelo facebook (http://www.facebook.com/geocursosbr).

Categories: OSGeo Planet

Jackie Ng: Introducing: New experimental bindings for the MapGuide API

OSGeo Planet - Tue, 2018-07-10 16:34
I haven't been quiet on the MapGuide front. I've just been deeply entrenched in my lab conducting an important experiment whose results are finally coming into fruition that I am back here to make this exciting announcement.

That experiment was: Can we generate bindings for the MapGuide API using a vanilla version of SWIG? Yes we can!

Background

This is an important question that we needed an answer for and we wanted that answer to be "Yes". 

We currently provide bindings for the MapGuide API in:
  • Java
  • PHP 5.x
  • .net (full framework)
However, we currently use an ancient and heavily modified version of SWIG, whose unclear audit trail of modifications and changes means that being able to support newer versions of PHP (ie. PHP 7.x) or variants of .net like .net Core is nigh-impossible, which puts us in a bit of a pickle because:
  • PHP 5.6 (our current bundled version of PHP) will be end-of-life on December 2018. Bundling and targeting an EOL version of PHP is not a good look. To bundle the current version of PHP (7.x) we need to be able to generate a compatible PHP extension for it. We can't do that with current internal copy of SWIG as the zend extension APIs have massively breaking changes from PHP5 to PHP7.
  • .net Core is where the action is at in the .net space, and not having a presence in this space diminishes our story of being able to build MapGuide applications in .net because as time goes on, that definition of ".net" will assume to mean both the (windows-only) full framework and (cross-platform) .net core.
  • We may want to add support for additional programming languages in the future. Can't do it with our super-modified copy of SWIG again because of the unclear history of changes made to this tool.
Given these factors, and the untenable situation we currently find ourselves in technology-wise, we needed to explore the possibility of generating the bindings using a vanilla (un-modified) version of SWIG. If we're going to go vanilla, we want the latest and greatest, which supports generating bindings for PHP7, and can support .net core with the right amount of SWIG typemap elbow-grease, so all the more motivation to get this working!

What we now have

2 months since the decision to embark on this journey, the mission to get functional MapGuide bindings using vanilla SWIG has been a success! We now have the following bindings for the MapGuide API:
  • A Java binding modeled on the non-crufty official Java binding. Requires Java 7 or higher.
  • A (currently windows-only) PHP extension for PHP 7.1
  • A netstandard2.0-compatible binding for .net that works on both .net Core and full framework and is also cross-platform for platforms where both .net Core and official MapGuide binary packages are available for. For Linux, that means this .net binding works in Ubuntu 14.04 64-bit (where .net Core also has packages available). The nuget package for this binding is fully self-contained and includes the necessary native dependencies (both 32 and 64-bit) needed for the .net library to work. For .net full framework, it includes an MSBuild .targets file to ensure all the required native dependencies are copied out to your application's output directory.
Where to get it

You can grab the bits from the releases page of the mapguide-api-bindings GitHub repo.

For .net, you will have to setup a local package source and drop the nuget package there in order to consume in your library/application.

You will need MapGuide Open Source 3.1.1 installed as this is the only version of MapGuide I am generating these bindings for and testing against. Please observe the current supported platform matrix to see what combinations of technology stacks work with this new set of bindings. Please also observe the respective notes on the .net, PHP and Java bindings to observe what changes and adjustments you need to make in your MapGuide application should you want to try out these bindings.

Sample applications (to make sure this stuff works)

As proof that these bindings work, here's a sample asp.net core application using the new MapGuide .net binding. As a testament to what targeting .net Core gives us, you could bypass building the sample application from source and perhaps give the self-contained package a go. Thanks to the powerful publishing capabilities provided by the dotnet CLI, we can publish a self-contained .net core application with zero external dependencies. In the case of this sample application, you can download the zip, extract it to a windows or Ubuntu 14.04 64-bit machine with a standard MapGuide Open Source 3.1.1 install, run the MvcCoreSample executable within, go to http://localhost:5000 and your MapGuide application is up and running!




For Java and PHP, I'm still cooking up some sample applications in the same vein as the asp.net core one (ie. Porting across the MapGuide Developer's Guide samples), but for now the only verification that these bindings work is that our current binding test suite run to completion (with some failures, but these failures are known failures that are also present in our current bindings).

Where to from here?

I intend for the mapguide-api-bindings project to serve as an incubation area where we can iron out any show-stopping problems before planning for the eventual inclusion into MapGuide proper and supplementing (and in the case of PHP, replacing) our current bindings because eventually, we have to. We cannot keep bundling and targeting PHP 5.x forever. We need to be able to target newer versions of these programming languages, and maybe in some cases new programming languages.

mapguide-api-bindings project repo
asp.net core sample application repo
Categories: OSGeo Planet

GeoSolutions: Vote for our SaveMyBike Project, help us win RegioStars 2018 competition!

OSGeo Planet - Tue, 2018-07-10 14:06

SMB Sample

Dear Reader, we are glad to inform you that our R&D project SaveMyBike has been selected by the European Commission as one of the 21 finalists for the "REGIOSTARS AWARDS 2018" for Category 2 “Achieving sustainability through low carbon emissions”.

The main target of the project is to simplify the way we refer to the soft mobility, to make it convenient, immediate, a certainty in everyday life; we want to make soft mobility a pleasant habit and not a further difficulty. Our aim is to relief cities from the oppression of cars, to rediscover the serenity of alternative transport modes, to take on city traffic nodes and to release them once and for all. Sustainable mobility challenges are epochal, but we could begin from small gestures, from everyday life, to reach the target.

The voting process is open until October 7th, therefore we kindly ask you to support us by accessing this page and by voting for the project. We hope you will help us win this competition!

In a future post we are going to discuss about the technical infrastructure that is powering the project.

The GeoSolutions Team,

320x100_eng
Categories: OSGeo Planet

Free and Open Source GIS Ramblings: Movement data in GIS #14: updates from GI_Forum 2018

OSGeo Planet - Mon, 2018-07-09 18:54

Last week, I traveled to Salzburg to attend the 30th AGIT conference and co-located English-speaking GI_Forum. Like in previous year, there were a lot of mobility and transportation research related presentations. Here are my personal highlights:

This year’s keynotes touched on a wide range of issues, from Sandeep Singhal (Google Cloud Storage) who – when I asked about the big table queries he showed – stated that they are not using a spatial index but are rather brute-forcing their way through massive data sets, to Laxmi Ramasubramanian @nycplanner (Hunter College City University of New York) who cautioned against tech arrogance and tendency to ignore expertise from other fields such as urban planning:

Next up: Sandeep Singhal Director, @Google Cloud Storage #GIForum2018 pic.twitter.com/fiRL9TUNpr

— Anita Graser (@underdarkGIS) July 4, 2018

One issue that Laxmi particularly highlighted was the fact that many local communities are fighting excessive traffic caused by apps like Waze that suggest shortcuts through residential neighborhoods. Just because we can do something with (mobility) data, doesn’t necessarily mean that we should!

L. Ramasubramanian on public participation #PPGIS its potential impacts & education and policy challenges at #giforum2018: https://t.co/M7RXyGeXPG pic.twitter.com/NKumhvuHuJ

— Anita Graser (@underdarkGIS) July 5, 2018

Not limited to mobility but very focused on open source, Jochen Albrecht (Hunter College City University of New York) invited the audience to join his quest for a spatial decision support system based on FOSS only at bit.ly/FiltersAndWeights and https://github.com/geojochen/fosssdss

#giforum2018 keynote by J. Albrecht on #opensource spatial decision support systems: with call to action at https://t.co/cdCJa3VaDV pic.twitter.com/QezE3KRHQA

— Anita Graser (@underdarkGIS) July 5, 2018

The session Spatial Perspectives on Healthy Mobility featured multiple interesting contributions, particularly by Michelle P. Fillekes who presented a framework of mobility indicators to assess daily mobility of study participants. It considers both spatial and temporal aspects of movement, as well as the movement context:

Figure from Michelle Pasquale Fillekes, Eleftheria Giannouli, Wiebren Zijlstra, Robert Weibel. Towards a Framework for Assessing Daily Mobility using GPS Data. DOI: 10.1553/giscience2018_01_s177 (under cc-by-nd)

It was also good to see that topics we’ve been working on in the past (popularity routing in this case) continue to be relevant and have been picked up in the German-speaking part of the conference:

3 years after #popularity #routing by @mstraubVIE & @underdarkGIS (https://t.co/TDZD53tfs0) v. klingspor presents an analogy for motorbikes at #AGIT30. pic.twitter.com/PTia5phWVH

— gicycle (@gicycle_) July 6, 2018

Of course, I also presented some new work of my own, specifically my research into PostGIS trajectory datatypes which I’ve partially covered in a previous post on this blog and which is now published in Graser, A. (2018) Evaluating Spatio-temporal Data Models for Trajectories in PostGIS Databases. GI_Forum ‒ Journal of Geographic Information Science, 1-2018, 16-33. DOI: 10.1553/giscience2018_01_s16.

My introduction to GeoMesa talk failed to turn up any fellow Austrian GeoMesa users. So I’ll keep on looking and spreading the word. The most common question – and certainly no easy one at that – is how to determine the point where it becomes worth it to advance from regular databases to big data systems. It’s not just about the size of the data but also about how it is intended to be used. And of course, if you are one of those db admin whizzes who manages a distributed PostGIS setup in their sleep, you might be able to push the boundaries pretty far. On the other hand, if you already have some experience with the Hadoop ecosystem, getting started with tools like GeoMesa shouldn’t be too huge a step either. But that’s a topic for another day!

Since AGIT&GI_Forum are quite a big event with over 1,000 participants, it was not limited to movement data topics. You can find the first installment of English papers in GI_Forum 2018, Volume 1. As I understand it, there will be a second volume with more papers later this year.

This post is part of a series. Read more about movement data in GIS.

Categories: OSGeo Planet

Equipo Geotux: Grupo de Usuarios QGIS Colombia: Invitación a Asamblea General

OSGeo Planet - Sat, 2018-07-07 02:50

Si eres usuari@ o desarrollador@ de QGIS y estás en Colombia, ¡estás cordialmente invitad@ a hacer parte del Grupo de Usuarios QGIS Colombia!

Para oficializar la creación del grupo haremos una Asamblea General el sábado 28 de Julio de 9am a 11am en la Universidad Nacional, Bogotá. Más detalles a continuación.

 

 

¿Quién puede participar en el Grupo?

Puedes asistir a la asamblea y hacer parte del Grupo de Usuarios QGIS Colombia si estás interesad@ en QGIS en cualquier forma. No necesitas ser un@ expert@ :D

 

¿Dónde y cuándo?

La asamblea se llevará a cabo el sábado 28 de Julio de 2018 de 9am a 11am en la Universidad Nacional, sede Bogotá (salón por confirmar). Debes realizar una preinscripción aquí (eso nos dará una idea de cuántas personas asistirán) y te contactaremos directamente cuando tengamos confirmado el salón.

 

¿Y si no estoy en Bogotá?

Si no te encuentras en Bogotá pero quieres participar en el grupo, ¡contáctanos! Podemos organizar grupos regionales para que te reúnas con otras personas de tu región y eventualmente podemos asistir a un evento en tu región.

 

Sobre el grupo

Los grupos de usuarios QGIS son creados para difundir el proyecto y aprender sobre el mismo junto a otros usuarios. En Latinoamérica ya existen grupos similares en Brasil, Perú y México; a nivel mundial existen cerca de 25 grupos. Se trata de asociaciones legalmente constituidas (según las condiciones locales para ello), en Colombia estamos constituyendo una asociación sin ánimo de lucro. El Grupo de Usuarios QGIS Colombia será inscrito al proyecto QGIS, obteniendo con ello el derecho a un voto en las decisiones del proyecto.

Puedes consultar los estatutos del Grupo de Usuarios QGIS Colombia en http://downloads.tuxfamily.org/tuxgis/geodescargas/Estatutos_Grupo_Usuarios_QGIS_Colombia_v20180706.pdf Allí encontrarás más información sobre los objetivos y conformación del grupo, incluyendo los tipos de membresías anuales que se manejarán.

 

Agenda de la…


Read more...
Categories: OSGeo Planet

Andrea Antonello: Geopaparazzi 5.6.1 is out

OSGeo Planet - Thu, 2018-07-05 09:52
Usually when I have time to make bugfixes I also make a release after that. Last time I did fixes I then got caught in the work crossfire and forgot to. I didn't notice, since on my devices I have the most advanced testing devel version.

Yesterday Silvia asked me why the fix she asked for wasn't there yet! :-)
So I noticed. Well, I added a couple of more fixes to the closed list and here we go.

This is mostly a bugfix release, with a few minor usability enhancements that recently a very advanced geopaparazzi user started to report. I am not able to catch up with all his reports, but some of them are in.

Here we go:
Enhancements
  • better feedback about form name and positioning mode (GPS or Map Center) in actionbar
  • all exports now follow all the same pattern. They are exported in the geopaparazzi/export folder and their name is made if the project name + type + timestamp of export
  • project PDF export now has the possibility to export only a selected portion of notes
  • activate button for profiles is now on the main cardview
  • better proportion of forms in portrait mode
  • tile sources icon is now always visible in actionbar
  • dashboard enhancements: visualize number of notes and logs, open notes list on long tap
  • save button in forms now a floating action button to remind user to save
Fixes
  • the force locale didn't have English to allow a user to go back to default
  • fixes on profiles not being visible in landscape mode
  • fix for last background map used not reloaded on app restart
  • fix for crash on pushing back button in form notes
  • fix for crash on issue empty sql query in advanced view
  • fix for issue with saving forms with empty fields
  • avoid data loss in form notes when user exists with back button. Now the user is warned.

 And of course, language updates.

 Enjoy!
Categories: OSGeo Planet

Andrea Antonello: Geopaparazzi Survey Server

OSGeo Planet - Tue, 2018-07-03 15:19
Would you believe it? Only a month ago I was showing the Geopaparazzi Profiles Server developed by the guys at GeoAnalytic and now I am here again to write about the Geopaparazzi Survey Server (GSS).

What does Survey Server even mean? :-)

Well, while the Profile concept is a sophisticated way to handle survey data, background data, forms, spatialite databases and their way of synchronization, the GSS si something much smaller. But in our opinion it reflects the workflow of many, many surveyors and groups of surveyors.




The Geopaparazzi Survey Server (GSS) is a web application that allows geopaparazzi users to synchronize their project data with a central server.

Its companion is an Android app named Geopaparazzi Survey Server Sync (GSSS) available on google play. The app can connect to geopaparazzi projects and synchronize the data contained using the unique device ID to upload the data to the server.

Any device that connects to the server with its ID, will be accepted and if not available, the new id is automatically inserted in the central db.

So this is not about spatialite datasets, but only about geopaparazzi project files, that can contain notes, complex form notes, GPS logs and images.

The server applicationThe server application is packaged as a docker images and can be installed in the blink of an eye ( well, if your connection is fast). Once you install it, you get a nice and simple web application with a login


a dashboard, a mapview with the possibility to load/unload the data of your surveyors, zoom to it and check information of your notes, gps logs and images:

The surveyors' device that connects to the server is inserted in the surveyors list, if it is not registered already. There a human readable name can be assigned and some basic contact:

The mobile appThe mobile app has been done for android. FYI, we are also working on a desktop version app. There are several reasons for which we decided to go with an external app instead of adding this to geopaparazzi itself. The most important thing is that several cloud synchronization applications are getting born around geopaparazzi these days. We will probably have to let these ideas mature and then at some point it will be possible to converge on the best methodology.
But right now I find it more respectful to have an external app that uses its own way to collect the data from the geopaparazzi projects and send them to the server instance.
So let's have a short look at the Geopaparazzi Survey Server Sync, GSSS :-)
Well, it is a simple simple app with the possibility to load geopaparazzi projects. In it you can see what data are available for upload, i.e. dirty data:


Since the app uses the device id as surveyor id, some simple configurations need to be done:


Once the project file is loaded, the device id is ensured and the server url is inserted... well, just push the upload button! On successful upload the list of notes will be empty and your survey can go on using geopaparazzi.
Installation and trainingA complete installation and quickstart guide is available here. Check it out to see all features available.
If you want to get a small training first hand from the developers, we will be giving a workshop about geopaparazzi and GSS at the following locations in the near future:
We would also be very happy to be involved with this stack in projects in developing countries, where data collection and centralization is necessary.If you are interested, please reach out to us.





Categories: OSGeo Planet

gvSIG Team: New plugins to select and count duplicate values in gvSIG

OSGeo Planet - Tue, 2018-07-03 10:31

Two new plugins have been published for the management of duplicate values ​​in a field of the attribute table of a vector layer.

The first plugin is an improvement of the already existing duplicate selection tool, where all the elements with duplicate values ​​were selected in a field of the table. With the new functionality the first one won’t be selected now. With this the user has both options available.

Keep in mind that in 2.4 version both tools are in two different menus (Selection and Table) and in two different buttons at toolbar, but from 2.4.1 they will be unified in the Selection menu, and in a drop-down button of the toolbar.

The second plugin allows us to count different values in a field of the attribute table. This new tool is added as a geoprocess in the Toolbox, and selecting the table and the field, we would obtain a new table (available in Project Manager-> Table) with the different values ​​of the selected field, and the number of times that each one is repeated.

To install both plugins we must access to the Add-ons Manager (Tools menu) and search “duplic” term, where they will appear. We will have to mark them and after being installed we must restart gvSIG.

At this video you can watch how these tools work:

Categories: OSGeo Planet

gvSIG Team: Nuevos plugins para selección y conteo de valores duplicados en gvSIG

OSGeo Planet - Tue, 2018-07-03 10:02

Se han publicado dos nuevos plugins para la gestión de valores duplicados en un campo de la tabla de atributos de una capa vectorial.

El primero sería una mejora del ya existente de selección de duplicados, donde se seleccionaban todos los elementos con valores duplicados en un campo de la tabla. Con la nueva funcionalidad ahora nos dejaría el primero de ellos sin seleccionar. Con ello el usuario tiene ambas opciones disponibles.

Hay que tener en cuenta que en la versión 2.4 ambas herramientas se encuentran en dos menús diferentes (Selección y Tabla) y en dos botones diferentes, pero a partir de la 2.4.1 se unificarán en el menú Selección, y en un botón de la barra de herramientas con un desplegable.

El segundo plugin es el de conteo de valores en un campo de la tabla de atributos. Esta nueva herramienta se añade como un geoproceso más en la Caja de herramientas, y con él, seleccionando la tabla y el campo deseados, obtendríamos una nueva tabla (disponible en el Gestor de proyectos->Tabla) con los distintos valores del campo seleccionado, y el número de veces que se repite cada uno.

Para instalar dichas extensiones se debe entrar en el Administrador de complementos (menú Herramientas), y buscar el término “duplic”, donde nos aparecerán los dos paquetes, que se deben marcar y se descargarán. Tras instalarlos se debe reiniciar gvSIG.

En este vídeo podéis ver cómo funcionan ambas herramientas:

Categories: OSGeo Planet
Syndicate content