segunda-feira, 20 de maio de 2019

SpatiaLite no Android

Gosto muito do SpatiaLite.

Basta referir o seguinte episódio que se passou há meia-dúzia de anos: 

Normalmente sempre que preciso de configurar o GeoServer ligado a uma BD Espacial, por regra o PostGIS, utilizo primeiro o SpatiaLite de forma a obter mais rapidamente um Produto Viável Mínimo. Deixando de parte outras considerações que me levem a fazer isso, a verdade é que enviei para produção um Produto Final ligado a SpatiaLite, sem ter voltado a ligar a PostGIS. Ou seja, a imagem levava o PostGIS só para enfeitar!

Como dos requesitos constava a possibilidade de utilização simultânea por, até, 10 utilizadores, e como nunca houve feedback, positivo ou negativo, presume-se que nem deram por ela.

Last edit wins model
 
Tratando-se de SQLite, existem obviamente situações onde faz mais sentidos ser utilizado, o que não quer dizer que não possa ser utilizado também em situações onde faça aparentemente menos sentido, por exemplo server-side database.

As permissões de utilizador dependem apenas das permissões de acesso ao ficheiro.


Adiante,

Do FAQ da página do GeoPackage (um FAQ já recorrente neste blog):

What is the relationship between GeoPackage and SpatiaLite?

SpatiaLite was a major influence on the vector portions of GeoPackage but after extensive discussions, the working group chose to diverge from the SpatiaLite format in a few subtle ways. SpatiaLite now supports GeoPackage as of version 4.2.0. 

Ou seja, a componente vectorial do GeoPackage foi fortemente inspirada pelo SpatiaLite, mas o SpatiaLite é que teve de se adaptar ao standard OGC e a passar a suportar GeoPackage.

What were the reasons to go with SQLite, when OGC has invested heavily in PostGIS? 

OGC has not invested in PostGIS, rather PostGIS implements OGC standards. PostGIS is just like any other RDBMS implementation of the Simple Features spec. The primary use case for designing GeoPackage was mobile device use, and that's why SQLite was chosen as a platform. In this case OGC as an organization is specifying a technology. This is unusual for OGC and the decision was not made lightly, but practicality and ease of implementation won out over standards purity. And we are happy to say we have yet to get any negative feedback on this decision -- probably because SQLite is considered more like a library than a standalone application.  

Ou seja, o GeoPackage foi desenhado principalmente a pensar na utilização em dispositivos móveis. E é por isso que o SQLite foi escolhido.

...e como o SpatiaLite também é SQLite, e também suporta GeoPackage, e anda cá há mais tempo...


Da página original do SpatiaLite encontramos duas ligações relacionadas com implementações para Android:
- A referente à versão 4.3. a qual está agora na umbrela do projecto geopaparazzi (fica para outras núpcias!);
- E a 3.0.1 (de 2012) que ficou onde estava! Tem Wiki.

A versão 3.0.1 pode ser descarregada do Wiki. De onde podem ser reaproveitadas as diferentes abi (armeabi,..), 32 bits apenas, que se encontram na pasta libs. As bindings em Java encontram-se como de costume na pasta src.

O projecto encontra-se também arquivado no Google Code.

No separador de Downloads é possível descarregar o apk do Spatialite-Android, app que já não se encontra publicada na PlayStore. Mas que funciona perfeitamente em Android 8.0.0 - Oreo. 


Selecionando "Map View" temos o ficheiro SpatiaLite de exemplo sobreposto, mas não visível, ao Google Maps para Android,

Clicando sobre qualquer região de Itália fica realçada a respectiva região,


















   


quinta-feira, 16 de maio de 2019

Smartphones e Tablets: não tem rigorosamente nada a ver!

Esqueçam o título. Esqueçam o título. Esqueçam o título.

É só uma afirmação leviana proferida por paraquedistas que caem na arena Android oriundos do ecosistema IOS, normalmente com uma atitude know-it-all ! E muito provavelmente até têm Android a correr na Smart TV, e nunca repararam.

Por acaso em 2012 comprei um tablet que corria Android 4.0.3 - Ice Cream Sandwich, e que tinha uma saída HDMI. Está bem que nunca a utilizei, mas ficou patente, as potencialidades do Android enquanto sistema operativo não apenas de "telemóveis" mas mais abragente. E estava o AIDE a sair da fase beta.

Diga-se de passagem que só tenho feito root a dispositivos por desporto, voltando logo a fazer unroot. Ao contrário dos utilizadores "avançados" do IOS que vivem obcecados com o Jailbreak... mesmo que nunca o façam.

Uma QA do FAQ do Geopackage (afinal é um post geo!):

How are GeoPackage files shared between apps on iOS and Android devices? 
 
On the iPhone, the security issues of the device cause a lot of problems for cross-app file sharing. Inherently, the device does not want applications to share data except in very narrowly defined ways. So data sharing between apps is not feasible at this time. 

E não só. No IOS a situação é tão caricata que se tentar descarregar no navegador um ficheiro que não tenha um formato conhecido, muito provavelmente nem vou conseguir. 

No Android pelo contrário o acesso ao sistema de ficheiro é transparente. Sempre foi.

E a integração de APIs em função do tipo de dispositivos ficou completa com o Ice Cream Sandwich (2011) . O Honeycomb 3.x só para tablets ficou por aí. Antes disso, no tempo do Android 2.X até havia apps em duplicado publicadas na Store: a app A e a app A (tablet). Lembram-se?

...O tablet Kindle Fire de 6 polegadas provavelmente o tablet mais vendido nem aparece nas estatísticas por estas só contabilizarem tablets com 7 ou mais polegadas. 

Tablets de 6 polegadas, smartphones também de 6 polegadas: do ponto de vista de desenvolvimento é rigorosamente a mesma coisa. Desde o ICS 4.0 (2011). Para não falar de notebooks que correm Android.  






GISWATER: paciente zero por cá

Plugin do GISWATER no GitHub:

Com o projecto da Quinta do Lago, que julgo ser pioneiro em Portugal, ou se não foi, pelo menos foi o primeiro a ser divulgado de forma consistente na comunidade SIG, ficando provado ser perfeitamente exequível ter uma solução de distribuição de água em baixa, assente em software de código aberto.


Como, não há muito tempo, dei por endpoints ArcGIS/rest/services no domínio da InfraQuinta, é um bom indicador de que soluções híbridas não são uma quimera!

http://naviamapsws.infraquinta.pt/arcgis/rest/services/Navia

Soluções híbridas (fechado bem integrado com aberto) devem ser incentivadas. Mas não impostas ao cliente como: "este software desktop de 15k integra muito bem com PostGIS"!!. 


O SIG de fato e gravata tem futuro?

Aqui, por SIG de fato e gravata estou-me a referir aquele conceito em que, por exemplo, um político vai receber um prémio de excelência pelo seu belo SIG (já passou a barreira dos 100k, já dá direito a prémio).

Estou-me a referir aquele conceito em que os encontros/seminários de utilizadores estavam pejados de empty suits. Cheguei a ver no YouTube o presidente do munícipio onde moro num desses eventos.

Estou-me a refererir, por exemplo, quando andaram a vender geo-portais em Flex (quando o Flex já estava descontinuado). Quando andaram a configurar serviços de  mapas-base em WGS-84 (quando também já estavam descontinuados), e o natural seria configurar em Web-Mercator.  

Reparem que isto não tem nada a ver com qualquer quezília prorietário vs open-source. 

O que não falta por aí são empresas "semi-públicas" (se os accionistas são autarquias acho que a adjectivação está correcta) especialistas em "fechar" open-source (às vezes ainda sai mais caro do que o proprietário).

E depois acontecem situações como a "gestão de ocorrências" que passam completamente ao lado dos players tradicionais. Podera. Com projectos a serem arrematados por menos de 5k.

Ou como os software para sistemas de abastecimento de água em baixa com financiamento limitado a 30k (despesas com IVA não elegíveis), comparticipados a 85%. Sai mais barato que uma fotocopiadora!

E como tal vão ligar tanto aquilo como a uma fotocopiadora. Dos projectos que já completaram o prazo de "garantia" de 3 anos, quantos é que foram para a recarga? Dos realizados em 2015, 2016? Pois.

A imposição de um limite de 30.000 Euros evitou que houvesse exageros, tendo até o efeito de obrigar empresas que utilizam software proprietário a baixar os preços, para poderem sequer ir a jogo.

Note-se que quem baixou preços numa lógica de angariação de clientes com vista à manutenção de relações comerciais de longo prazo, desconhece um pouco a forma como funcionam, e às vezes acabam, projectos que existem exclusivamente por terem sido co-financiados.

Por exemplo, o software só poder ser utilizado para o fim para o qual há financiamento, neste caso, eficiência energética - Controlo e Redução de Perdas nos Sistemas de Distribuição e Adução de Água. Até poderiam instalar lá o PDM que certamente a Gestão Urbanística não iria utilizar o computador do Serviço de Águas.


A natureza one shot dos projectos

Enfim, desde que a Gatewit foi corrida das plataformas de contratação pública em 2016, o mercado está muito mais agilizado. Dantes, quase que era preciso ter um departamento inteiro de prevenção, só para poder ir a jogo.
     


GeoPredial: um bom exemplo


Eu nem sabia que havia este projecto da Câmara dos Solicitadores . Agora é Ordem.

Mas como fartava-me de receber referrels provenientes de mail.solicitador.net no geomatica.no.sapo.pt, calculei que os solicitadores gostassem de mapas. E fui ver. 

E realmente na BASE tinham, e têm lá muita informação. É até um exemplo de boas práticas, por terem , por exemplo, em 2013, uma descrição pormenorizada do objecto do contrato:

Desenvolvimento ao sistema informático de apoio ao projeto Geopredial

1. Configurar servidor de ortofotos em AIX da Câmara, com as seguintes sub-componentes
i. Instalar e configurar GeoServer;
ii. Instalar e configurar GeoWebCache;
iii. Instalar e configurar Postgres + PostGIS;
iv. Instalar e configurar GeoExplorer.
2. Apoiar no processo de carregamento pela GeoJustiça de ortofotos, desenvolvendo ferramentas de carregamento em quantidade, se necessário.
3. Substituir a utilização, na plataforma actual, do uso das bibliotecas de manipulação/visualização de dados GIS no browser de Google Maps, reprogramando a interacção sobre o mapa utilizando OpenLayers.
4. Configurar a nova biblioteca OpenLayers para aceder ao novo servidor GeoServer.
5. Configurar servidor aplicacional em AIX, com Apache/PHP, GIT.
6. Reprogramar interfaces de base-de-dados da aplicação para que interajam com o motor de base-de-dados Informix.
7. Migração de dados de Argivai de MySQL para Informix.
8. Implementar fluxo de interfaces/etapas associadas a pagamento e integração com os respectivos webservices da Câmara.
9. Implementar fluxo de interfaces/etapas associadas a emissão de facturas e integração com os respectivos webservices da Câmara.
10. Configurar e implementar notificações por e-mail utilizando o servidor de e-mail da Câmara.
11. Analisar resultados práticos e necessidades de alterações aos fluxos decorrentes do piloto realizado em Argivai.
12. Aplicação da nova imagem institucional do projecto GeoPredial (logotipo, cores, fontes, etc.)
13. Produzir novo manual de utilização.



Interessante. Em 2013, provavelmente, utilizaria a mesma combinação GeoServer/PostGIS/GeoExplorer.








 



 




E as empresas que?

Então, e as empresas que mudaram a sede fiscal para a província por causa dos fundos comunitários?
Em Lisboa (LVT) só co-financiavam a 45%, e havia muita competição. Assim foram receber 55%.

Se tivessem feito uma página em inglês, ou ido a uns congressos/feiras no estrangeiro, já entrava na componente "internacionalização".

Empresa X, que toda a gente sabe que é de Lisboa (escritório a funcionar diariamente), com sede fiscal no 2° direito, de um prédio habitacional em Évora, ou a empresa Y, em Castelo Branco.

Só que não é a fundo perdido. Tem que ser reembolsado: gastas agora, pagas depois. Pode ser um tiro no pé.

..para não falar da startup (acho que agora é tudo startup) das roulotes que vendem hambúrgueres de alheira, ou de carne de porco preto! Esses pormenores passam-me um pouco ao lado!

Lembrei-me não sei porquê do Smart Client e do ArcGIS Silverlight

Lembrei-me agora, não sei porquê, do Smart Client, que nas brochuras da Intergraph em inglês aparecia sempre descrito como a solução ideal para a democratização do acesso à informação geográfica dentro das organizações!! Impressionante!


IS YOUR GEOGRAPHIC
INFORMATION SYSTEM
(GIS) GRIDLOCKED IN A
DEPARTMENT? LIMITED
TO POWER USERS?
LOCKED AWAY? 

Aquilo utiliza(va) Java Web Start (JNLP). É no browser, mas não é! Foi a solução encontrada pela Oracle (Sun, na altura) para se livrar da má fama dos Applets. Entrentanto a Oracle deixou de distribuir Java Web Start com o Java 11 (2018). Já tinha sido descontinuado no Java 9 (2017).

... e no entanto, o Smart Client 2018 continua a utilizar Java Web Start.

Faz-me lembrar a aposta da ESRI no ArcGIS API for Silverlight, o qual foi retirado de circulação em 2016. A ESRI tinha um excelente visualizador em Javascipt (2009?), o qual descontinuou, para ir dar uma volta pelo Flex (também retirado em 2016) e pelo Silverlight. Depois voltou em força ao Javascript.

Para não falar do ArcGIS Web ADF. Desapareceu do mapa sem deixar rasto.

E, para não falar na carta aberta que o Steve Jobs escreveu em 2010 a explicar porque é que o ecosistema iStuff nunca suportaria Flash.

 

Não são só os "parceiros" locais que têm que agradar à casa-mãe. Os grandes também têm "parceiros" para agradar, neste caso, Oracle e Microsoft, respectivamente.