[Gfoss] ISTAT Cell Data

2023-04-16 Per discussione Massimiliano Moraca via Gfoss
Ciao lista :)
Qualche giorno fa ho pubblicato il package Python istatcelldata con cui è
possibile ottenere facilmente i dati censuari ISTAT relativi agli ultimi
tre censimenti completi della popolazione.

Di seguito il link alla documentazione:

https://maxdragonheart.github.io/istatcelldata/

Spero di fare cosa gradita condividendolo.

Il package ha tra funzioni principali che sono spiegate nei tutorial che
seguono:
- Download e normalizzazione
https://github.com/MaxDragonheart/istatcelldata/blob/main/notebooks/tutorial/a_download.ipynb
- Preprocessamento
https://github.com/MaxDragonheart/istatcelldata/blob/main/notebooks/tutorial/b_preprocessamento.ipynb
- Generazione di un GeoPackage per anno censuario
https://github.com/MaxDragonheart/istatcelldata/blob/main/notebooks/tutorial/c_processamento.ipynb

Indicazioni e consigli sono ben accetti. È il primo package che pubblico ed
è probabile che ci siano cose da migliorare. Le tre funzionalità precedente
indicate sono però testate e pian piano cercherò di implementare nuove
funzionalità.

Alla prossima
___
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni 
dell'Associazione GFOSS.it.
764 iscritti al 23/08/2019

Re: [Gfoss] Il WFS del GPN genera GML errati?

2022-02-01 Per discussione Massimiliano Moraca
Mi conforta il fatto che il problema non compare solo a me :)
Grazie per le indicazioni, appena posso darò un occhiata a fiona

*ing.Massimiliano Moraca*
*Analisi, progettazione e sviluppo di soluzioni GIS e WebGIS*
*P.IVA*: 08700081212
*CELL*: 333 59 49 583 (*lun - ven 9.00 - 18.00*)
*WEB*: www.massimilianomoraca.it 
* Attività svolta ai sensi della Legge 4 del 14 gennaio 2013, art.1*


Il giorno mar 1 feb 2022 alle ore 16:01 Maurizio Napolitano 
ha scritto:

> Ho dato un'occhiata.
> Secondo me il problema è in fiona ( = le librerie con cui geopandas
> legge i formati di dati).
> Salvando la response del wfs su file system si ottiene un GML.
> GML che apri con QGIS, ma che non apri con fiona (e di conseguenza con
> geopandas).
> Lo stesso GML però lo apri via python usando il binding alle GDAL/OGR
> Pertanto mi viene da suggerirti di usare i binding python di ogr per
> leggere dal WFS, salvare nel formato che vuoi e ricaricare in
> geopandas.
> Nel frattempo vedere se su fiona hanno risolto il bug.
>
> --
> --
> Le informazioni contenute nella presente comunicazione sono di natura
> privata e come tali sono da considerarsi riservate ed indirizzate
> esclusivamente ai destinatari indicati e per le finalità strettamente
> legate al relativo contenuto. Se avete ricevuto questo messaggio per
> errore, vi preghiamo di eliminarlo e di inviare una comunicazione
> all’indirizzo e-mail del mittente.
>
> --
> The information transmitted is
> intended only for the person or entity to which it is addressed and may
> contain confidential and/or privileged material. If you received this in
> error, please contact the sender and delete the material.
>
___
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni 
dell'Associazione GFOSS.it.
764 iscritti al 23/08/2019

Re: [Gfoss] Il WFS del GPN genera GML errati?

2022-02-01 Per discussione Massimiliano Moraca
Ti ringrazio per la risposta Maurizio,
il problema è che non riesco proprio a leggere con Geopandas quel dato.

wfs_service = WebFeatureService(url="
> http://wms.pcn.minambiente.it/ogc?map=/ms_ogc/wfs/Alluvioni_Estensione.map;,
> version="1.1.0")
> response = wfs_service.getfeature(typename="ITH2018_Estensione_HPH")
> gdf = gpd.read_file(response)
> print(gpd)


Seguendo le indicazioni al link, dopo aver passato il *response* a
Geopandas usi Shapely per invertire gli assi, ma l'errore(
*UnsupportedGeometryTypeError*) mi compare proprio quando passo il
*response* a Geopandas.

*ing.Massimiliano Moraca*
*Analisi, progettazione e sviluppo di soluzioni GIS e WebGIS*
*P.IVA*: 08700081212
*CELL*: 333 59 49 583 (*lun - ven 9.00 - 18.00*)
*WEB*: www.massimilianomoraca.it 
* Attività svolta ai sensi della Legge 4 del 14 gennaio 2013, art.1*


Il giorno mar 1 feb 2022 alle ore 13:59 Maurizio Napolitano 
ha scritto:

> Devi invertire gli assi: è un problema legato alla versione del protocollo.
> Risolvi la questione con shapely
> Ad esempio puoi usare questa funzione sulla colonna della geometria
> del tuo geodataframe
>
> def swapxy(geometry):
>   geometry = shapely.ops.transform(lambda x, y: (y, x),geometry)
>   return geometry
>
> Qui trovi dove una spiegazione molto base per gli studenti del mio corso
>
> https://napo.github.io/geospatial_course_unitn/lessons/03-retrieving_data_from_sdi#wfs
>
> --
> --
> Le informazioni contenute nella presente comunicazione sono di natura
> privata e come tali sono da considerarsi riservate ed indirizzate
> esclusivamente ai destinatari indicati e per le finalità strettamente
> legate al relativo contenuto. Se avete ricevuto questo messaggio per
> errore, vi preghiamo di eliminarlo e di inviare una comunicazione
> all’indirizzo e-mail del mittente.
>
> --
> The information transmitted is
> intended only for the person or entity to which it is addressed and may
> contain confidential and/or privileged material. If you received this in
> error, please contact the sender and delete the material.
>
___
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni 
dell'Associazione GFOSS.it.
764 iscritti al 23/08/2019

[Gfoss] Il WFS del GPN genera GML errati?

2022-02-01 Per discussione Massimiliano Moraca
Salve a tutti,
avendo necessità di scaricare alcuni dati dal GPN ho sviluppato un processo
in Python apposito usando OWSLib e GeoPandas.

L'url da cui voglio scaricare i dati è questa: '
http://wms.pcn.minambiente.it/ogc?map=/ms_ogc/wfs/Alluvioni_Estensione.map'
che corrisponde a questo dato: *Alluvioni - Estensione dell'area allagabile
(PGRA 2021)*.

import geopandas as gpd
> from owslib.wfs import WebFeatureService


wfs_service = WebFeatureService(url="
> http://wms.pcn.minambiente.it/ogc?map=/ms_ogc/wfs/Alluvioni_Estensione.map;,
> version="1.1.0")
> response = wfs_service.getfeature(typename="ITH2018_Estensione_HPH")
> gml = open('wfs_data.gml', 'wb')
> gml.write(bytes(response.read()))
> gml.close()


Riesco a scaricare un GML senza problemi, ma i primi dubbi li ho aprendo il
file con QGIS perchè i dati risultano ruotati e traslati rispetto a ciò che
vedo consultando direttamente il WFS con QGIS stesso.

Provando ad aprire il file con GeoPandas '*gdf =
gpd.read_file('wfs_data.gml', driver='GML', layer='ITH2018_Estensione_HPH')*'
ottengo il seguente errore:

/home/max/.cache/pypoetry/virtualenvs/drakonotebook-Mbf4coiv-py3.8/lib/python3.8/site-packages/geopandas/io/file.py:238:
> in _read_file columns = list(features.schema["properties"])
> /home/max/.cache/pypoetry/virtualenvs/drakonotebook-Mbf4coiv-py3.8/lib/python3.8/site-packages/fiona/collection.py:208:
> in schema self._schema = self.session.get_schema() fiona/ogrext.pyx:719: in
> fiona.ogrext.Session.get_schema ???


??? E fiona.errors.UnsupportedGeometryTypeError: 10


fiona/_geometry.pyx:81: UnsupportedGeometryTypeError


Con il dubbio di aver sbagliato qualcosa ho usato un layer dal mio
Geoserver:

wfs_service = WebFeatureService(url="
> https://geoserver.massimilianomoraca.me/geoserver/MassimilianoMoraca/wfs;,
> version="2.0.0")
> response =
> wfs_service.getfeature(typename="MassimilianoMoraca:attentionpoints")


Il risultato è che vedo correttamente posizionato il GML aperto con QGIS e
non ho problemi con GeoPandas.

Secondo voi da cosa può dipendere il problema? Mi è sfuggito qualcosa? E'
un problema del GPN?


*ing.Massimiliano Moraca*
*Analisi, progettazione e sviluppo di soluzioni GIS e WebGIS*
*P.IVA*: 08700081212
*CELL*: 333 59 49 583 (*lun - ven 9.00 - 18.00*)
*WEB*: www.massimilianomoraca.it 
* Attività svolta ai sensi della Legge 4 del 14 gennaio 2013, art.1*
___
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni 
dell'Associazione GFOSS.it.
764 iscritti al 23/08/2019

Re: [Gfoss] creare geopackage con python

2021-07-12 Per discussione Massimiliano Moraca
Ciao, come giustamente ti è stato suggerito passa a python 3 e per la
costruzione del geopackage potresti usare Geopandas.

Il lun 12 lug 2021, 16:52 Luca Delucchi  ha scritto:

> On Mon, 12 Jul 2021 at 12:51, pierluigi de rosa
>  wrote:
> >
> > Buongiorno lista,
> >
>
> Ciao Pierluigi,
>
> > forse una domanda leggermente OT.
> >
> > Dovrei scrivere un piccolo codice python (in python 2.7) che crea un
> > geopackage in un sito con geogjando.
>
> ti conviene tanto aggiornare a python3 perchè non è più supportato da
> circa un anno
>
> > Ho quindi tutte le feature corrette ma come posso creare un geopakage e
> > popolarlo con qualche elemento?
> > Qualcuno sa suggerirmi qualche riga di codice da prendere spunto?
>
> con le librerie python di ogr dovresti riuscire abbastanza bene.
> https://pcjericks.github.io/py-gdalogr-cookbook/
>
> > Grazie ancora
> > Pierluigi
> >
>
> --
> ciao
> Luca
>
> www.lucadelu.org
> ___
> Gfoss@lists.gfoss.it
> http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
> Questa e' una lista di discussione pubblica aperta a tutti.
> I messaggi di questa lista non hanno relazione diretta con le posizioni
> dell'Associazione GFOSS.it.
> 764 iscritti al 23/08/2019
___
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni 
dell'Associazione GFOSS.it.
764 iscritti al 23/08/2019

Re: [Gfoss] Dati LIDAR ministero dell'ambiente

2021-05-07 Per discussione Massimiliano Moraca
Ci sono novità in merito?

-
Consulente GIS,  Formatore, Blogger e Ciclista Urbano
email: i...@massimilianomoraca.it
cell: 333 5949583 (lun-ven, 9.00-18.00)
website: massimilianomoraca.it
--
Sent from: 
http://gfoss-geographic-free-and-open-source-software-italian-mailing.3056002.n2.nabble.com/
___
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni 
dell'Associazione GFOSS.it.
764 iscritti al 23/08/2019

[Gfoss] DirectOpenLayers

2021-01-03 Per discussione Massimiliano Moraca
Dietro suggerimento di Andrea Borruso ho provveduto a creare le pagine di
esempio per le mappe basate su DirectOpenLayers[1]. In più ho inserito una
nuova funzionalità, lo zoom al caricamento della mappa su una risorsa
vettoriale predefinita.


Chiunque volesse contribuire è il benvenuto.


[1] https://github.com/MaxDragonheart/DirectOpenLayers



*ing.Massimiliano Moraca*
*Analisi, progettazione e sviluppo di soluzioni GIS e WebGIS*
*P.IVA*: 08700081212
*CELL*: 333 59 49 583 (*lun - ven 9.00 - 18.00*)
*WEB*: www.massimilianomoraca.it
* Attività svolta ai sensi della Legge 4 del 14 gennaio 2013, art.1*
___
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni 
dell'Associazione GFOSS.it.
764 iscritti al 23/08/2019

Re: [Gfoss] Avviare un progettp OS

2020-12-30 Per discussione Massimiliano Moraca
Devi installarla con `npm install ol` ma poi non devi importare nulla
perchè ho inserito gli import che usa la libreria attualmente già nel .js
di DirectOpenLayers [1]

---
[1]
https://github.com/MaxDragonheart/DirectOpenLayers/blob/main/src/directopenlayers.js


*ing.Massimiliano Moraca*
*Analisi, progettazione e sviluppo di soluzioni GIS e WebGIS*
*P.IVA*: 08700081212
*CELL*: 333 59 49 583 (*lun - ven 9.00 - 18.00*)
*WEB*: www.massimilianomoraca.it
* Attività svolta ai sensi della Legge 4 del 14 gennaio 2013, art.1*


Il giorno mer 30 dic 2020 alle ore 18:23 Andrea Peri 
ha scritto:

> Richiede la libreria openlayer o la ha già incorporata ?
>
> A.
>
>
> Il mer 30 dic 2020, 16:15 Massimiliano Moraca 
> ha scritto:
>
>> Buonasera e buon Natale passato a tutti.
>> Come promesso ho pubblicato il mio primo repository su GitHub.
>> Il progetto si chiama DirectOpenLayers[1] ed è una piccola libreria
>> JavaScript che ho sviluppato in questi mesi e che mi è tornata utile per
>> velocizzarmi nella creazione di nuove webmap.
>>
>> Spero sia utile non solo a me e spero di non aver fatto errori con la
>> licenza.
>> Chiunque volesse dare un contributo è il benvenuto.
>>
>> Buona fine e buon principio d'anno!
>>
>> -
>> [1] https://github.com/MaxDragonheart/DirectOpenLayers
>>
>> *ing.Massimiliano Moraca*
>> *Analisi, progettazione e sviluppo di soluzioni GIS e WebGIS*
>> *P.IVA*: 08700081212
>> *CELL*: 333 59 49 583 (*lun - ven 9.00 - 18.00*)
>> *WEB*: www.massimilianomoraca.it
>> * Attività svolta ai sensi della Legge 4 del 14 gennaio 2013, art.1*
>>
>>
>> Il giorno ven 11 dic 2020 alle ore 09:33 Massimiliano Moraca <
>> i...@massimilianomoraca.it> ha scritto:
>>
>> > Grazie a tutti per le indicazioni!
>> > Nel caso specifico di OpenLayers credo che dovrò adottare la loro stessa
>> > licenza che è la 2-Clause BSD
>> > <https://opensource.org/licenses/BSD-2-Clause>. Comunque approfondirò
>> il
>> > discorso licenze nel periodo natalizio che sarò più libero.
>> >
>> > *ing.Massimiliano Moraca*
>> > *Analisi, progettazione e sviluppo di soluzioni GIS e WebGIS*
>> > *P.IVA*: 08700081212
>> > *CELL*: 333 59 49 583 (*lun - ven 9.00 - 18.00*)
>> > *WEB*: www.massimilianomoraca.it
>> > * Attività svolta ai sensi della Legge 4 del 14 gennaio 2013, art.1*
>> >
>> >
>> > Il giorno gio 10 dic 2020 alle ore 12:50 Stefano Campus <
>> skam...@gmail.com>
>> > ha scritto:
>> >
>> >> Mi permetto di intervenire sulle licenze.
>> >> Per prima cosa bisogna verificare se il codice ha delle dipendenze e in
>> >> quale maniera le dipendenze sono invocate (carico librerie solo quando
>> >> serve e poi le scarico, oppure caricate dall':inizio, oppure SAAS).
>> >> Già in caso di dipendenza devi vedere la licenza di queste librerie.
>> >>
>> >> Se non hai questi problemi puoi tu decidere il grado di libertà che
>> >> intendi
>> >> fare ai tuoi utenti.
>> >> La GLP è virale quindi tutto deve essere ricondiviso  con la stessa
>> >> licenza.
>> >>
>> >> La 1LGPL è in genere applicata al software che deve essere utilizzato
>> in
>> >> altri software.
>> >>
>> >> Licenza Pubblica Generica normale. Questa licenza viene usata per
>> >> determinate librerie in modo da permettere il collegamento di tali
>> >> librerie
>> >> a programmi non liberi.
>> >>
>> >> Quando un programma è collegato con una libreria, sia staticamente sia
>> >> usando una libreria condivisa, legalmente parlando la combinazione dei
>> due
>> >> elementi è un lavoro combinato, un derivato della libreria originale.
>> >> Perciò la normale Licenza Pubblica Generica permette tale collegamento
>> >> solo
>> >> se l'intera combinazione risulta conforme ai propri criteri di libertà
>> .
>> >> La
>> >> Licenza Pubblica Generica Attenuata consente criteri più permissivi per
>> >> collegare altro codice alla libreria. (
>> >>
>> >>
>> https://it.m.wikisource.org/wiki/Licenza_Pubblica_Generica_Attenuata_(LGPL)_del_progetto_GNU
>> >> )
>> >>
>> >> Come vedi non si può dire così subito "uso questa licenza".
>> >>
>> >> Puoi però già indirizzarti verso le licenze copyleft oppure no in
>> funzione
>> >> della tua "sensibilità" e verific

Re: [Gfoss] Avviare un progettp OS

2020-12-30 Per discussione Massimiliano Moraca
Buonasera e buon Natale passato a tutti.
Come promesso ho pubblicato il mio primo repository su GitHub.
Il progetto si chiama DirectOpenLayers[1] ed è una piccola libreria
JavaScript che ho sviluppato in questi mesi e che mi è tornata utile per
velocizzarmi nella creazione di nuove webmap.

Spero sia utile non solo a me e spero di non aver fatto errori con la
licenza.
Chiunque volesse dare un contributo è il benvenuto.

Buona fine e buon principio d'anno!

-
[1] https://github.com/MaxDragonheart/DirectOpenLayers

*ing.Massimiliano Moraca*
*Analisi, progettazione e sviluppo di soluzioni GIS e WebGIS*
*P.IVA*: 08700081212
*CELL*: 333 59 49 583 (*lun - ven 9.00 - 18.00*)
*WEB*: www.massimilianomoraca.it
* Attività svolta ai sensi della Legge 4 del 14 gennaio 2013, art.1*


Il giorno ven 11 dic 2020 alle ore 09:33 Massimiliano Moraca <
i...@massimilianomoraca.it> ha scritto:

> Grazie a tutti per le indicazioni!
> Nel caso specifico di OpenLayers credo che dovrò adottare la loro stessa
> licenza che è la 2-Clause BSD
> <https://opensource.org/licenses/BSD-2-Clause>. Comunque approfondirò il
> discorso licenze nel periodo natalizio che sarò più libero.
>
> *ing.Massimiliano Moraca*
> *Analisi, progettazione e sviluppo di soluzioni GIS e WebGIS*
> *P.IVA*: 08700081212
> *CELL*: 333 59 49 583 (*lun - ven 9.00 - 18.00*)
> *WEB*: www.massimilianomoraca.it
> * Attività svolta ai sensi della Legge 4 del 14 gennaio 2013, art.1*
>
>
> Il giorno gio 10 dic 2020 alle ore 12:50 Stefano Campus 
> ha scritto:
>
>> Mi permetto di intervenire sulle licenze.
>> Per prima cosa bisogna verificare se il codice ha delle dipendenze e in
>> quale maniera le dipendenze sono invocate (carico librerie solo quando
>> serve e poi le scarico, oppure caricate dall':inizio, oppure SAAS).
>> Già in caso di dipendenza devi vedere la licenza di queste librerie.
>>
>> Se non hai questi problemi puoi tu decidere il grado di libertà che
>> intendi
>> fare ai tuoi utenti.
>> La GLP è virale quindi tutto deve essere ricondiviso  con la stessa
>> licenza.
>>
>> La 1LGPL è in genere applicata al software che deve essere utilizzato in
>> altri software.
>>
>> Licenza Pubblica Generica normale. Questa licenza viene usata per
>> determinate librerie in modo da permettere il collegamento di tali
>> librerie
>> a programmi non liberi.
>>
>> Quando un programma è collegato con una libreria, sia staticamente sia
>> usando una libreria condivisa, legalmente parlando la combinazione dei due
>> elementi è un lavoro combinato, un derivato della libreria originale.
>> Perciò la normale Licenza Pubblica Generica permette tale collegamento
>> solo
>> se l'intera combinazione risulta conforme ai propri criteri di libertà .
>> La
>> Licenza Pubblica Generica Attenuata consente criteri più permissivi per
>> collegare altro codice alla libreria. (
>>
>> https://it.m.wikisource.org/wiki/Licenza_Pubblica_Generica_Attenuata_(LGPL)_del_progetto_GNU
>> )
>>
>> Come vedi non si può dire così subito "uso questa licenza".
>>
>> Puoi però già indirizzarti verso le licenze copyleft oppure no in funzione
>> della tua "sensibilità" e verificare poi quale meglio si adatta.
>>
>> Non trascurerei le licenze europee della famiglia delle EUPL che tengono
>> conto anche delle peculiarità europee diverse dal contesto statunitense.
>>
>> s.
>>
>> Il gio 10 dic 2020, 12:29 Luca Delucchi  ha
>> scritto:
>>
>> > On Thu, 10 Dec 2020 at 09:03, Massimiliano Moraca
>> >  wrote:
>> > >
>> > > Buongiorno a tutti,
>> >
>> > Ciao,
>> >
>> > > stavo pensando da un po' di avviare un progetto OS ed in particolare
>> > vorrei
>> > > condividere un wrapper di OpenLayers che ho sviluppato e che mi ha
>> > > consentito di ridurre di molto le righe di codice utili a costruire
>> una
>> > > webmap.
>> > >
>> > > I miei dubbi su come fare una cosa del genere sono tanti e
>> probabilmente
>> > > derivano dal fatto che sono un ingegnere per l'ambiente ed il
>> territorio
>> > > prestato al mondo dello sviluppo(ma solo GIS), per cui magari
>> potrebbero
>> > > sembrarvi delle banalità i miei dubbi.
>> > >
>> > > Ho un account su GitHub, quindi userei questo strumento per
>> diffondere il
>> > > progetto.
>> >
>> > direi proprio di si
>> >
>> > > 1. esistono linee guida per la diffusione di un progetto OS?
>> >
>> > per la diffusione no, più pubblici

Re: [Gfoss] Avviare un progettp OS

2020-12-11 Per discussione Massimiliano Moraca
Grazie a tutti per le indicazioni!
Nel caso specifico di OpenLayers credo che dovrò adottare la loro stessa
licenza che è la 2-Clause BSD <https://opensource.org/licenses/BSD-2-Clause>.
Comunque approfondirò il discorso licenze nel periodo natalizio che sarò
più libero.

*ing.Massimiliano Moraca*
*Analisi, progettazione e sviluppo di soluzioni GIS e WebGIS*
*P.IVA*: 08700081212
*CELL*: 333 59 49 583 (*lun - ven 9.00 - 18.00*)
*WEB*: www.massimilianomoraca.it
* Attività svolta ai sensi della Legge 4 del 14 gennaio 2013, art.1*


Il giorno gio 10 dic 2020 alle ore 12:50 Stefano Campus 
ha scritto:

> Mi permetto di intervenire sulle licenze.
> Per prima cosa bisogna verificare se il codice ha delle dipendenze e in
> quale maniera le dipendenze sono invocate (carico librerie solo quando
> serve e poi le scarico, oppure caricate dall':inizio, oppure SAAS).
> Già in caso di dipendenza devi vedere la licenza di queste librerie.
>
> Se non hai questi problemi puoi tu decidere il grado di libertà che intendi
> fare ai tuoi utenti.
> La GLP è virale quindi tutto deve essere ricondiviso  con la stessa
> licenza.
>
> La 1LGPL è in genere applicata al software che deve essere utilizzato in
> altri software.
>
> Licenza Pubblica Generica normale. Questa licenza viene usata per
> determinate librerie in modo da permettere il collegamento di tali librerie
> a programmi non liberi.
>
> Quando un programma è collegato con una libreria, sia staticamente sia
> usando una libreria condivisa, legalmente parlando la combinazione dei due
> elementi è un lavoro combinato, un derivato della libreria originale.
> Perciò la normale Licenza Pubblica Generica permette tale collegamento solo
> se l'intera combinazione risulta conforme ai propri criteri di libertà . La
> Licenza Pubblica Generica Attenuata consente criteri più permissivi per
> collegare altro codice alla libreria. (
>
> https://it.m.wikisource.org/wiki/Licenza_Pubblica_Generica_Attenuata_(LGPL)_del_progetto_GNU
> )
>
> Come vedi non si può dire così subito "uso questa licenza".
>
> Puoi però già indirizzarti verso le licenze copyleft oppure no in funzione
> della tua "sensibilità" e verificare poi quale meglio si adatta.
>
> Non trascurerei le licenze europee della famiglia delle EUPL che tengono
> conto anche delle peculiarità europee diverse dal contesto statunitense.
>
> s.
>
> Il gio 10 dic 2020, 12:29 Luca Delucchi  ha scritto:
>
> > On Thu, 10 Dec 2020 at 09:03, Massimiliano Moraca
> >  wrote:
> > >
> > > Buongiorno a tutti,
> >
> > Ciao,
> >
> > > stavo pensando da un po' di avviare un progetto OS ed in particolare
> > vorrei
> > > condividere un wrapper di OpenLayers che ho sviluppato e che mi ha
> > > consentito di ridurre di molto le righe di codice utili a costruire una
> > > webmap.
> > >
> > > I miei dubbi su come fare una cosa del genere sono tanti e
> probabilmente
> > > derivano dal fatto che sono un ingegnere per l'ambiente ed il
> territorio
> > > prestato al mondo dello sviluppo(ma solo GIS), per cui magari
> potrebbero
> > > sembrarvi delle banalità i miei dubbi.
> > >
> > > Ho un account su GitHub, quindi userei questo strumento per diffondere
> il
> > > progetto.
> >
> > direi proprio di si
> >
> > > 1. esistono linee guida per la diffusione di un progetto OS?
> >
> > per la diffusione no, più pubblicità gli fai più sarà diffuso,
> > presentarlo a convegni è altrettanto utile
> >
> > > 2. questione licenze: avete indicazioni particolari?
> >
> > io scegliere tra una di queste
> >
> > Apache License, 2.0
> > New BSD license
> > GNU General Public License (GPL version 3)
> > GNU Library or "Lesser" General Public License (LGPL version 3)
> > MIT license
> > Mozilla Public License (MPL)
> >
> >
> > > 3. se qualcuno domani volesse contribuire allo sviluppo io dovrei fare
> > > qualcosa per permetterglielo o è tutto automatizzato una volta che
> > imposto
> > > il progetto come *Pubblico*?
> > >
> >
> > se il progetto diventa grande è meglio definire delle regole, per ora
> > penso che chiunque contribuisca con delle issue e pull request
> > dovrebbe essere accettato
> >
> > --
> > ciao
> > Luca
> >
> > www.lucadelu.org
> > ___
> > Gfoss@lists.gfoss.it
> > http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
> > Questa e' una lista di discussione pubblica aperta a tutti.
> > I messaggi di questa lista non hanno relazione dir

[Gfoss] Avviare un progettp OS

2020-12-10 Per discussione Massimiliano Moraca
Buongiorno a tutti,
stavo pensando da un po' di avviare un progetto OS ed in particolare vorrei
condividere un wrapper di OpenLayers che ho sviluppato e che mi ha
consentito di ridurre di molto le righe di codice utili a costruire una
webmap.

I miei dubbi su come fare una cosa del genere sono tanti e probabilmente
derivano dal fatto che sono un ingegnere per l'ambiente ed il territorio
prestato al mondo dello sviluppo(ma solo GIS), per cui magari potrebbero
sembrarvi delle banalità i miei dubbi.

Ho un account su GitHub, quindi userei questo strumento per diffondere il
progetto.
1. esistono linee guida per la diffusione di un progetto OS?
2. questione licenze: avete indicazioni particolari?
3. se qualcuno domani volesse contribuire allo sviluppo io dovrei fare
qualcosa per permetterglielo o è tutto automatizzato una volta che imposto
il progetto come *Pubblico*?




*ing.Massimiliano Moraca*
*Analisi, progettazione e sviluppo di soluzioni GIS e WebGIS*
*P.IVA*: 08700081212
*CELL*: 333 59 49 583 (*lun - ven 9.00 - 18.00*)
*WEB*: www.massimilianomoraca.it
* Attività svolta ai sensi della Legge 4 del 14 gennaio 2013, art.1*
___
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni 
dell'Associazione GFOSS.it.
764 iscritti al 23/08/2019

Re: [Gfoss] [GEOSERVER] Autenticazione tramite REST

2020-10-21 Per discussione Massimiliano Moraca
Pardon ho inserito le credenziali in maniera errata in Insomnia.
La sfida resta generare stili dinamici...

*ing.Massimiliano Moraca*
*Analisi, progettazione e sviluppo di soluzioni GIS e WebGIS*
*P.IVA*: 08700081212
*CELL*: 333 59 49 583 (*lun - ven 9.00 - 18.00*)
*WEB*: www.massimilianomoraca.it
* Attività svolta ai sensi della Legge 4 del 14 gennaio 2013, art.1*


Il giorno mer 21 ott 2020 alle ore 14:07 Massimiliano Moraca <
i...@massimilianomoraca.it> ha scritto:

> Salve a tutti,
> mi è stato detto che usando le REST di GeoServer 2.17 posso creare stili
> dinamici per i raster. Faccio prima una piccola precisazione.
>
> Ho molti grid che rappresentano la temperatura di varie aree. Vista l'alta
> variabilità del dato temperatura non posso settare una coloramp unica per
> tutti, come per un indice tipo NDVI. Per cui quello che vorrei ottenere è
> usare una scala di colore fissa per tutti(es. Magma da QGIS) con i valori
> di
> ogni range di temperatura "liberi" nel senso che, in base al minimo e
> massimo preso dal raster si generano 10 intervalli uguali.
>
> Mi è stato detto che con  SLD REST Service
> <
> https://docs.geoserver.org/stable/en/user/extensions/sldservice/index.html>
>
> posso ottenere ciò.
>
> Non ho mai usato un servizio REST, mi hanno consigliato di usare  Insomnia
> <https://insomnia.rest/>   per fare dei test ma mi sono scontrato subito
> con
> problemi di autenticazione con la richiesta del  Manifests
> <https://docs.geoserver.org/stable/en/api/#1.0.0/manifests.yaml>  (sto
> consultando il manuale di  GeoServer
> <https://docs.geoserver.org/maintain/en/user/rest/index.html#rest>   per i
> servizi REST).
>
> Questo è il cURL che ho estratto da Insomnia con la mia richiesta:
>
> > curl --request GET \
> >   --url
> > '
> https://gis.massimilianomoraca.it/geoserver/rest/about/manifest?username=usr=pwd
> '
> > \
> >   --cookie JSESSIONID=
>
> Con questo GeoServer mi risponde con *STATUS 401*.
>
> Come posso eseguire l'autenticazione usando i servizi REST?
>
> Loggandomi prevetivamente da browser nella mia istanza di GeoServer ed
> incollando il link
> `https://gis.massimilianomoraca.it/geoserver/rest/about/manifest`
> <https://gis.massimilianomoraca.it/geoserver/rest/about/manifest> nel
> browser riesco ovviamente a vedere la lista dei plugin installati.
>
> -
> Consulente GIS,  Formatore, Blogger e Ciclista Urbano
> email: i...@massimilianomoraca.it
> cell: 333 5949583 (lun-ven, 9.00-18.00)
> website: massimilianomoraca.it
> --
> Sent from:
> http://gfoss-geographic-free-and-open-source-software-italian-mailing.3056002.n2.nabble.com/
> ___
> Gfoss@lists.gfoss.it
> http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
> Questa e' una lista di discussione pubblica aperta a tutti.
> I messaggi di questa lista non hanno relazione diretta con le posizioni
> dell'Associazione GFOSS.it.
> 764 iscritti al 23/08/2019
___
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni 
dell'Associazione GFOSS.it.
764 iscritti al 23/08/2019

[Gfoss] [GEOSERVER] Autenticazione tramite REST

2020-10-21 Per discussione Massimiliano Moraca
Salve a tutti,
mi è stato detto che usando le REST di GeoServer 2.17 posso creare stili
dinamici per i raster. Faccio prima una piccola precisazione.

Ho molti grid che rappresentano la temperatura di varie aree. Vista l'alta
variabilità del dato temperatura non posso settare una coloramp unica per
tutti, come per un indice tipo NDVI. Per cui quello che vorrei ottenere è
usare una scala di colore fissa per tutti(es. Magma da QGIS) con i valori di
ogni range di temperatura "liberi" nel senso che, in base al minimo e
massimo preso dal raster si generano 10 intervalli uguali.

Mi è stato detto che con  SLD REST Service
  
posso ottenere ciò.

Non ho mai usato un servizio REST, mi hanno consigliato di usare  Insomnia
   per fare dei test ma mi sono scontrato subito con
problemi di autenticazione con la richiesta del  Manifests
  (sto
consultando il manuale di  GeoServer
   per i
servizi REST).

Questo è il cURL che ho estratto da Insomnia con la mia richiesta:

> curl --request GET \
>   --url
> 'https://gis.massimilianomoraca.it/geoserver/rest/about/manifest?username=usr=pwd'
> \
>   --cookie JSESSIONID=

Con questo GeoServer mi risponde con *STATUS 401*.

Come posso eseguire l'autenticazione usando i servizi REST?

Loggandomi prevetivamente da browser nella mia istanza di GeoServer ed
incollando il link
`https://gis.massimilianomoraca.it/geoserver/rest/about/manifest` nel
browser riesco ovviamente a vedere la lista dei plugin installati.

-
Consulente GIS,  Formatore, Blogger e Ciclista Urbano
email: i...@massimilianomoraca.it
cell: 333 5949583 (lun-ven, 9.00-18.00)
website: massimilianomoraca.it
--
Sent from: 
http://gfoss-geographic-free-and-open-source-software-italian-mailing.3056002.n2.nabble.com/
___
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni 
dell'Associazione GFOSS.it.
764 iscritti al 23/08/2019

Re: [Gfoss] Problemi ad installare QGIS su ubuntu 20.04

2020-10-05 Per discussione Massimiliano Moraca
Ciao, prova a seguire questo mio tutorial
https://youtu.be/Cg0WeneoMqY

Il lun 5 ott 2020, 10:02 Luca Manganelli 
ha scritto:

> Ciao a tutti,
>
> sto cercando di capire come mai QGIS non viene installato su ubuntu 20.04.
>
> Il repository è questo (da sources.list):
>
> deb https://qgis.org/ubuntu-ltr focal main
>
> e provo ad installare qgis (versione LTR):
>
> luca@hp800:~$ sudo apt install qgis
> Lettura elenco dei pacchetti... Fatto
> Generazione albero delle dipendenze
> Lettura informazioni sullo stato... Fatto
> Starting pkgProblemResolver with broken count: 2
> Starting 2 pkgProblemResolver with broken count: 2
> Investigating (0) qgis:amd64 < none -> 1:3.10.10+32focal @rc puN Ib >
> Broken qgis:amd64 Dipende on qgis-providers:amd64 < none |
> 1:3.10.10+32focal @un uH > (= 1:3.10.10+32focal)
>   Considering qgis-providers:amd64 0 as a solution to qgis:amd64 1
>   Re-Instated qgis-providers-common:amd64
> Reinst Failed early because of qtbase-abi-5-12-8:amd64
> Investigating (0) python3-qgis:amd64 < none -> 1:3.10.10+32focal @un uN Ib
> >
> Broken python3-qgis:amd64 Dipende on qgis-providers:amd64 < none |
> 1:3.10.10+32focal @un uH > (= 1:3.10.10+32focal)
>   Considering qgis-providers:amd64 0 as a solution to python3-qgis:amd64 0
>   Holding Back python3-qgis:amd64 rather than change qgis-providers:amd64
> Investigating (1) qgis:amd64 < none -> 1:3.10.10+32focal @rc puN Ib >
> Broken qgis:amd64 Dipende on python3-qgis:amd64 < none | 1:3.10.10+32focal
> @un uH > (= 1:3.10.10+32focal)
>   Considering python3-qgis:amd64 0 as a solution to qgis:amd64 1
> Reinst Failed because of qgis-providers:amd64
> Broken qgis:amd64 Dipende on qgis-providers:amd64 < none |
> 1:3.10.10+32focal @un uH > (= 1:3.10.10+32focal)
>   Considering qgis-providers:amd64 0 as a solution to qgis:amd64 1
> Done
> Alcuni pacchetti non possono essere installati. Questo può voler dire
> che è stata richiesta una situazione impossibile oppure, se si sta
> usando una distribuzione in sviluppo, che alcuni pacchetti richiesti
> non sono ancora stati creati o sono stati rimossi da Incoming.
> Le seguenti informazioni possono aiutare a risolvere la situazione:
>
> I seguenti pacchetti hanno dipendenze non soddisfatte:
>  qgis : Dipende: python3-qgis (= 1:3.10.10+32focal) ma non sta per essere
> installato
> Dipende: qgis-providers (= 1:3.10.10+32focal) ma non sta per essere
> installato
> E: Impossibile correggere i problemi, ci sono pacchetti danneggiati
> bloccati.
>
>
> qualcuno mi può dare una dritta?
> ___
> Gfoss@lists.gfoss.it
> http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
> Questa e' una lista di discussione pubblica aperta a tutti.
> I messaggi di questa lista non hanno relazione diretta con le posizioni
> dell'Associazione GFOSS.it.
> 764 iscritti al 23/08/2019
___
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni 
dell'Associazione GFOSS.it.
764 iscritti al 23/08/2019

Re: [Gfoss] Messa in produzione di Geoserver

2020-08-02 Per discussione Massimiliano Moraca
Come non detto, ho incontrato un ulteriore problema...
https://gis.stackexchange.com/questions/370337/use-nginx-with-tomcat-to-put-geoserver-under-https

-
Consulente GIS,  Formatore, Blogger e Ciclista Urbano
email: i...@massimilianomoraca.it
cell: 333 5949583 (lun-ven, 9.00-18.00)
website: massimilianomoraca.it
--
Sent from: 
http://gfoss-geographic-free-and-open-source-software-italian-mailing.3056002.n2.nabble.com/
___
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni 
dell'Associazione GFOSS.it.
764 iscritti al 23/08/2019

Re: [Gfoss] Messa in produzione di Geoserver

2020-08-02 Per discussione Massimiliano Moraca
Se a qualcuno interessa  qui
  
c'è la procedura di messa in produzione completa.

Alla prossima

-
Consulente GIS,  Formatore, Blogger e Ciclista Urbano
email: i...@massimilianomoraca.it
cell: 333 5949583 (lun-ven, 9.00-18.00)
website: massimilianomoraca.it
--
Sent from: 
http://gfoss-geographic-free-and-open-source-software-italian-mailing.3056002.n2.nabble.com/
___
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni 
dell'Associazione GFOSS.it.
764 iscritti al 23/08/2019

Re: [Gfoss] Cambiare la data directory di GeoServer

2020-07-20 Per discussione Massimiliano Moraca
Ho ricevuto supporto  qui

  



-
Consulente GIS,  Formatore, Blogger e Ciclista Urbano
email: i...@massimilianomoraca.it
cell: 333 5949583 (lun-ven, 9.00-18.00)
website: massimilianomoraca.it
--
Sent from: 
http://gfoss-geographic-free-and-open-source-software-italian-mailing.3056002.n2.nabble.com/
___
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni 
dell'Associazione GFOSS.it.
764 iscritti al 23/08/2019

Re: [Gfoss] Messa in produzione di Geoserver

2020-07-14 Per discussione Massimiliano Moraca
Ciao Roberto, grazie per la risposta.
Ho fatto un test rapido e non ho riscontrato problemi di prestazioni, magari
verifico appena posso stressando il server.

Se la procedura credi sia buona la passo nel mio repository su Github così è
accessibile a tutti

-
Consulente GIS,  Formatore, Blogger e Ciclista Urbano
email: i...@massimilianomoraca.it
cell: 333 5949583 (lun-ven, 9.00-18.00)
website: massimilianomoraca.it
--
Sent from: 
http://gfoss-geographic-free-and-open-source-software-italian-mailing.3056002.n2.nabble.com/
___
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni 
dell'Associazione GFOSS.it.
764 iscritti al 23/08/2019

Re: [Gfoss] Messa in produzione di Geoserver

2020-07-12 Per discussione Massimiliano Moraca
Spulciando in rete e mettendo insieme varie procedure ho usato e testato la
procedura che segue per installare GeoServer su un server Ubuntu 20.04.
Funziona. Se ci sono criticità quali sono secondo voi?

## 1. Installare Java JDK sul server

apt install openjdk-8-jdk
  
## 2. Creazione dell'utente 

useradd -r tomcat9
mkdir /usr/local/tomcat9
  
## 3. Download dell'ultima versione di Tomcat9

wget
http://mirror.nohup.it/apache/tomcat/tomcat-9/v9.0.37/bin/apache-tomcat-9.0.37.tar.gz
-O apache-tomcat-9.0.37.tar.gz
  
In caso di errori verificare al link che segue quale è l'ultima versione
disponibile e sostituirla con quella al link precedente
http://mirror.nohup.it/apache/tomcat/tomcat-9/

## 4. Scompattare l'archivio

tar zxvf apache-tomcat-9.0.*.tar.gz --strip-component=1 -C
/usr/local/tomcat9
  
## 5. Assegnare i filte di Tomcat9 all'utente precedentemente creato

chown -R tomcat9:tomcat9 /usr/local/tomcat9

## 6. Impostare l'avvio automatico di Tomcat9
Accedere a tomcat9.service

nano /etc/systemd/system/tomcat9.service

Incollare il testo che segue:

[Unit]
 Description=Apache Tomcat Server
 After=syslog.target network.target

 [Service]
 Type=forking
 User=tomcat9
 Group=tomcat9

 Environment=CATALINA_PID=/usr/local/tomcat9/temp/tomcat.pid
 Environment=CATALINA_HOME=/usr/local/tomcat9
 Environment=CATALINA_BASE=/usr/local/tomcat9

 ExecStart=/usr/local/tomcat9/bin/catalina.sh start
 ExecStop=/usr/local/tomcat9/bin/catalina.sh stop

 RestartSec=10
 Restart=always

 [Install]
 WantedBy=multi-user.target

Ricaricare la lista dei servizi gestiti da systemd

systemctl daemon-reload

Abilitare l'avvio automatico di Tomcat9

systemctl enable tomcat9.service

Ora è possibile avviare Tomcat9 con il comando che segue

systemctl start tomcat9.service

## 7. Aggiungere l'IP del server

nano /usr/local/tomcat9/conf/server.xml

Modificare le seguenti righe:




Aggiungendo l'IP:



   
Fermare Tomcat9

systemctl stop tomcat9.service

Riavviare Tomcat9

systemctl start tomcat9.service

Ora è possibile accedere a Tomcat9 dall'indirizzo IP inserito, ad esempio
192.245.123.87:8080

## 8. Download di GeoServer 2.17.1 e decompressione del pacchetto

mkdir Downloads 
cd /Downloads
wget
http://sourceforge.net/projects/geoserver/files/GeoServer/2.17.1/geoserver-2.17.1-war.zip
apt install unzip
unzip geoserver-2.17.1-war.zip

## 9. Spostare GeoServer in Tomcat9

mv geoserver.war /usr/local/tomcat9/webapps/

## 10. Riavviare Tomcat9 ed accedere a GeoServer

systemctl stop tomcat9.service
systemctl start tomcat9.service

Accedere a GeoServer dall'IP del server precedentemente impostato. Es:
192.245.123.87:8080/geoserver


-
Consulente GIS,  Formatore, Blogger e Ciclista Urbano
email: i...@massimilianomoraca.it
cell: 333 5949583 (lun-ven, 9.00-18.00)
website: massimilianomoraca.it
--
Sent from: 
http://gfoss-geographic-free-and-open-source-software-italian-mailing.3056002.n2.nabble.com/
___
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni 
dell'Associazione GFOSS.it.
764 iscritti al 23/08/2019

[Gfoss] Messa in produzione di Geoserver

2020-07-08 Per discussione Massimiliano Moraca
Buongiorno a tutti,
che voi sappiate è ancora valido " Mastering Geoserver
 
" al giorno d'oggi per la messa in produzione di Geoserver? E' stato
pubblicato il 2014.

Sapete consigliarmi qualcosa di alternativo?

-
Consulente GIS,  Formatore, Blogger e Ciclista Urbano
email: i...@massimilianomoraca.it
cell: 333 5949583 (lun-ven, 9.00-18.00)
website: massimilianomoraca.it
--
Sent from: 
http://gfoss-geographic-free-and-open-source-software-italian-mailing.3056002.n2.nabble.com/
___
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni 
dell'Associazione GFOSS.it.
764 iscritti al 23/08/2019

Re: [Gfoss] Spatial Adjustment

2020-05-05 Per discussione Massimiliano Moraca
A me è capitato in passato di usare VectorBlender ma sono anni che non lo
uso più. Non sapevo che non fosse supportato dalla 3 ma credo che lui, o
uno strumento simile, sia fondamentale. Girano ancora troppi CAD senza
georeferenziazione per esempio

*ing.Massimiliano Moraca*
*Analisi, progettazione e sviluppo di soluzioni GIS e WebGIS*
*P.IVA*: 08700081212
*CELL*: 333 59 49 583 (*lun - ven 9.00 - 18.00*)
*WEB*: www.massimilianomoraca.it
* Attività svolta ai sensi della Legge 4 del 14 gennaio 2013, art.1*


Il giorno mar 5 mag 2020 alle ore 12:03 ludovico.frate <
frateludov...@gmail.com> ha scritto:

> Ciao,
> stavo riflettendo sulla necessità di avere uno strumento integrato in QGIS,
> simile allo Spatial Adjustment di ArcGis. Nella versione 2.x esistevano
> almeno 3 plug-in che permettevano alcune delle trasformazioni (ad esempio
> di
> tipo affine), ma nel passaggio alla versione 3.X è rimasto solo
> VectorBender
> che pare essere non più supportato.
> Facendo una ricerca sulle Issues di QGIS, ho trovato un solo topic a
> riguardo che risale al 2014.
>
> https://github.com/qgis/QGIS/issues/18702
>
> Ci sono i margini per chiedere un'implementazione? magari anche con una
> campagna di raccolta fondi.
>
>
> --
> Sent from:
> http://gfoss-geographic-free-and-open-source-software-italian-mailing.3056002.n2.nabble.com/
> ___
> Gfoss@lists.gfoss.it
> http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
> Questa e' una lista di discussione pubblica aperta a tutti.
> I messaggi di questa lista non hanno relazione diretta con le posizioni
> dell'Associazione GFOSS.it.
> 764 iscritti al 23/08/2019
___
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni 
dell'Associazione GFOSS.it.
764 iscritti al 23/08/2019

[Gfoss] Uso di gdal2tiles

2020-04-28 Per discussione Massimiliano Moraca
Buongiorno a tutti!
Sto usando gdal2tiles nella versione 2.2.3 e mi trovo di fronte a due
problemi.

*PROBLEMA 1*
Ho creato uno script in python che usa gdal2tiles:

> options = {
> 'zoom': (12, 18),
> 'resume': True,
> 'verbose': True,
> }
> print('Setup datas acquired!\n')
>
> gdal2tiles.generate_tiles('input_raster', 'output_path', **options)

ma quando avvio lo script vedo questo errore:

> Traceback (most recent call last): File "create_tiles.py", line 39, in
> gdal2tiles.generate_tiles(input_raster, output_path, **options)
> AttributeError: module 'gdal2tiles' has no attribute 'generate_tiles'


Lo script gira in Anaconda3 e l'esempio l'ho preso da qui[1](versione di
gdal2tiles 0.1.6)

*PROBLEMA 2*
Non riuscendo a trovare una soluzione ho avviato QGIS 3.10 e mi sono
copiato la riga di codice di gdal2tiles da Processing Toolbox che ho
inserito nel terminale di Ubuntu 18.04(*poi dovrò comunque passare la
stringa in un apposito .py*):

> gdal2tiles.py -v -z 12-18 -w openlayers sources/rasters/Tm_C.tif
> processed_data/generated-tiles/

Il processo è andato a buon fine ma il raster è stato degradato tantissimo,
ad occhio sembra che la dimensione dei pixel sia raddoppiata.
Qui[2] ci sono i settaggi principali per gdal2tiles.

Mi viene il dubbio che sia un problema di compatibillità tra le versione.
Se effettuo l'upgrade dalla versione di GDAL che attualmente uso, la 2.2.3
all'ultima, che attualmente è la 3.0.4, rischio di generare problemi di
compatibilità per QGIS?


[1] https://pypi.org/project/gdal2tiles/
[2] https://gdal.org/programs/gdal2tiles.html

*ing.Massimiliano Moraca*
*Analisi, progettazione e sviluppo di soluzioni GIS e WebGIS*
*P.IVA*: 08700081212
*CELL*: 333 59 49 583 (*lun - ven 9.00 - 18.00*)
*WEB*: www.massimilianomoraca.it
* Attività svolta ai sensi della Legge 4 del 14 gennaio 2013, art.1*
___
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni 
dell'Associazione GFOSS.it.
764 iscritti al 23/08/2019

Re: [Gfoss] Riproiezione di un raster

2020-03-17 Per discussione Massimiliano Moraca
Ludovico l'area ha una estensione di 4-5kmq

Andrea il processo in se deve avvenire in automatico attraverso script in
Python, mi confronterò con lo sviluppatore per verificare se è possibile
inserire questi step nel codice. Grazie per l'indicazione

*ing.Massimiliano Moraca*
*Analisi, progettazione e sviluppo di soluzioni GIS e WebGIS*
*P.IVA*: 08700081212
*CELL*: 333 59 49 583 (*lun - ven 9.00 - 18.00*)
*WEB*: www.massimilianomoraca.it
* Attività svolta ai sensi della Legge 4 del 14 gennaio 2013, art.1*


Il giorno mar 17 mar 2020 alle ore 12:53 andrea pacifici 
ha scritto:

> Ciao Massimiliano,
>
> immagino avrai avuto i tuoi motivi a fare tutto per via vettoriale, ma se
> volessi fare tutta la procedura via raster potresti fare così:
> 1) riclassificare il raster (nei tre range X Y e Z del tuo esempio)
> tramite r.reclass (o direttamente con il calcolatore raster di Qgis, se
> preferisci)
> 2) usare r.report per avere per ogni classe numero di pixel, superficie in
> mq o percentuale di copertura.
> Sono due soli passaggi, semplici e veloci
>
> Se ti serve aiuto scrivimi pure.
> Andrea
> 
> Dott. Geol. Andrea Pacifici, Ph.D.
> Via Altogradi n° 1,
> 55100 Lucca (Lu)
> Tel. 0583-082026
> Cell. 328-0991808
> web: www.geoitt.it
> e-mail: pacif...@gmail.com
>
>
> Il giorno mar 17 mar 2020 alle ore 09:52 Massimiliano Moraca <
> i...@massimilianomoraca.it> ha scritto:
>
>> Buongiorno a tutti, scrivo per esporvi alcuni dubbi che mi sono venuti
>> relativamente alla riproiezione di un raster. In ufficio, per alcuni
>> indici
>> di vegetazione, abbiamo la necessità di visualizzare in un diagramma a
>> barre
>> quanta superficie del raster in esame rientra in un certo range di valori.
>> Mi spiego meglio: posti tre range x, y e z, vogliamo sapere quanti pixel
>> rientrano in ognuno dei range e quale è la superficie totale di ognuno dei
>> range. Ad esempio: nel range x rientrano 20 pixel, la dimensione di ogni
>> pixel è 10x10 metri, quindi la superficie totale di x è 10x10x20=2000mq
>>
>> Mettendo da parte i perchè, si è scelto di lavorare in questo modo:
>> 1 - vettorializzazione del raster dell'indice di vegetazione
>> 2 - calcolo della superficie di ogni poligono del vettore(ogni poligono
>> corrisponderà al singolo pixel del raster al punto 1)
>> 3 - raggruppamento delle ricorrenze dei pixel secondo i range e sommatoria
>> delle aree
>>
>> Il dato di partenza è in 4326 con dimensione del singolo pixel pari a
>> 0.000112148462163201668 x 0.000112148462163201668
>>
>> Uno sviluppatore si sta occupando di creare il flusso di lavoro in python,
>> io con QGIS ho fatto una verifica sui suoi risultati partendo da uno degli
>> indici calcolati.
>>
>> Usando /Polygonize(raster to vector)/ ho ottenuto un vettore con una
>> colonna
>> DN che contiene il valore di indice per ogni poligono. Ho a questo punto
>> aggiunto una colonna che ho chiamato area_mq con cui tramite field
>> calculator ho calcolato la superficie di ogni poligono: *area( transform(
>> $geometry, 'EPSG:4326', 'EPSG:3857'))*. Il risultato è pari a circa 206 mq
>> per ogni pixel.
>>
>> Lo sviluppatore usando rasterio ha riproiettato il raster in 3857 e si è
>> poi
>> calcolato l'estensione di ogni pixel che gli risulta pari a circa 175 mq
>> con
>> pixel di dimensioni 13.26663473960738138 x 13.26663473960738138 m.
>>
>> Per capire il perchè di queste differenze ho esportato il mio raster in
>> 3857(Export -> Save as..) trovandomi con pixel di dimensioni
>> 12.48430981132078799 x 16.5115487603316744 e quindi la superficie di ogni
>> pixel è circa 206 mq. Mi trovo con il risultato che mi sono calcolato in
>> precedenza ma non con il risultato dello sviluppatore.
>>
>> Secondo test: ho usato /Warp/ per riproiettare il raster e mi trovo con le
>> dimensioni in pixel dello sviluppatore.
>>
>> Ora, posto che ho sempre riproiettato un raster nello stesso modo con cui
>> si
>> riproietta un vettore non avendo mai riscontrato problemi di
>> riposizionamento vorrei capire il perchè di quello che sembra essere un
>> mio
>> errore metodologico.
>>
>> -
>> Consulente GIS,  Formatore, Blogger e Ciclista Urbano
>> email: i...@massimilianomoraca.it
>> cell: 333 5949583 (lun-ven, 9.00-18.00)
>> website: massimilianomoraca.it
>> --
>> Sent from:
>> http://gfoss-geographic-free-and-open-source-software-italian-mailing.3056002.n2.nabble.com/
>> ___
>> Gfoss@lists.gfoss.it
>> http://lists.gfoss.it/cgi-bin/mailman/listinf

Re: [Gfoss] Riproiezione di un raster

2020-03-17 Per discussione Massimiliano Moraca
Ha usato nearest come me

-
Consulente GIS,  Formatore, Blogger e Ciclista Urbano
email: i...@massimilianomoraca.it
cell: 333 5949583 (lun-ven, 9.00-18.00)
website: massimilianomoraca.it
--
Sent from: 
http://gfoss-geographic-free-and-open-source-software-italian-mailing.3056002.n2.nabble.com/
___
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni 
dell'Associazione GFOSS.it.
764 iscritti al 23/08/2019

[Gfoss] Riproiezione di un raster

2020-03-17 Per discussione Massimiliano Moraca
Buongiorno a tutti, scrivo per esporvi alcuni dubbi che mi sono venuti
relativamente alla riproiezione di un raster. In ufficio, per alcuni indici
di vegetazione, abbiamo la necessità di visualizzare in un diagramma a barre
quanta superficie del raster in esame rientra in un certo range di valori.
Mi spiego meglio: posti tre range x, y e z, vogliamo sapere quanti pixel
rientrano in ognuno dei range e quale è la superficie totale di ognuno dei
range. Ad esempio: nel range x rientrano 20 pixel, la dimensione di ogni
pixel è 10x10 metri, quindi la superficie totale di x è 10x10x20=2000mq

Mettendo da parte i perchè, si è scelto di lavorare in questo modo:
1 - vettorializzazione del raster dell'indice di vegetazione
2 - calcolo della superficie di ogni poligono del vettore(ogni poligono
corrisponderà al singolo pixel del raster al punto 1)
3 - raggruppamento delle ricorrenze dei pixel secondo i range e sommatoria
delle aree

Il dato di partenza è in 4326 con dimensione del singolo pixel pari a
0.000112148462163201668 x 0.000112148462163201668

Uno sviluppatore si sta occupando di creare il flusso di lavoro in python,
io con QGIS ho fatto una verifica sui suoi risultati partendo da uno degli
indici calcolati.

Usando /Polygonize(raster to vector)/ ho ottenuto un vettore con una colonna
DN che contiene il valore di indice per ogni poligono. Ho a questo punto
aggiunto una colonna che ho chiamato area_mq con cui tramite field
calculator ho calcolato la superficie di ogni poligono: *area( transform(
$geometry, 'EPSG:4326', 'EPSG:3857'))*. Il risultato è pari a circa 206 mq
per ogni pixel.

Lo sviluppatore usando rasterio ha riproiettato il raster in 3857 e si è poi
calcolato l'estensione di ogni pixel che gli risulta pari a circa 175 mq con
pixel di dimensioni 13.26663473960738138 x 13.26663473960738138 m.

Per capire il perchè di queste differenze ho esportato il mio raster in
3857(Export -> Save as..) trovandomi con pixel di dimensioni
12.48430981132078799 x 16.5115487603316744 e quindi la superficie di ogni
pixel è circa 206 mq. Mi trovo con il risultato che mi sono calcolato in
precedenza ma non con il risultato dello sviluppatore.

Secondo test: ho usato /Warp/ per riproiettare il raster e mi trovo con le
dimensioni in pixel dello sviluppatore. 

Ora, posto che ho sempre riproiettato un raster nello stesso modo con cui si
riproietta un vettore non avendo mai riscontrato problemi di
riposizionamento vorrei capire il perchè di quello che sembra essere un mio
errore metodologico.

-
Consulente GIS,  Formatore, Blogger e Ciclista Urbano
email: i...@massimilianomoraca.it
cell: 333 5949583 (lun-ven, 9.00-18.00)
website: massimilianomoraca.it
--
Sent from: 
http://gfoss-geographic-free-and-open-source-software-italian-mailing.3056002.n2.nabble.com/
___
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni 
dell'Associazione GFOSS.it.
764 iscritti al 23/08/2019

Re: [Gfoss] Visualizzare il valore del pixel con OpenLayers

2020-02-28 Per discussione Massimiliano Moraca
Grazie, lunedì al rientro in ufficio farò dei test

*ing.Massimiliano Moraca*
*Analisi, progettazione e sviluppo di soluzioni GIS e WebGIS*
*P.IVA*: 08700081212
*CELL*: 333 59 49 583 (*lun - ven 9.00 - 18.00*)
*WEB*: www.massimilianomoraca.it
* Attività svolta ai sensi della Legge 4 del 14 gennaio 2013, art.1*


Il giorno gio 27 feb 2020 alle ore 23:40 Luca Delucchi 
ha scritto:

> On Thu, 27 Feb 2020 at 19:29, Massimiliano Moraca
>  wrote:
> >
> > Non è un wms ma un .tif
> > Comunque appena possibile provo e ti dico, grazie
> >
>
> se non passi da WMS l'unica soluzione che conosco (ma non ho mai
> usato) è geotiff.js
> sembra molto potente...
> https://geotiffjs.github.io/
>
> > *ing.Massimiliano Moraca*
> >
>
> --
> ciao
> Luca
>
> www.lucadelu.org
>
___
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni 
dell'Associazione GFOSS.it.
764 iscritti al 23/08/2019

Re: [Gfoss] Visualizzare il valore del pixel con OpenLayers

2020-02-27 Per discussione Massimiliano Moraca
Non è un wms ma un .tif
Comunque appena possibile provo e ti dico, grazie

*ing.Massimiliano Moraca*
*Analisi, progettazione e sviluppo di soluzioni GIS e WebGIS*
*P.IVA*: 08700081212
*CELL*: 333 59 49 583 (*lun - ven 9.00 - 18.00*)
*WEB*: www.massimilianomoraca.it
* Attività svolta ai sensi della Legge 4 del 14 gennaio 2013, art.1*


Il giorno gio 27 feb 2020 alle ore 19:22 Amedeo Fadini 
ha scritto:

> Uhm se è un WMS puoi provare a caricare un popup con il con la chiamata
> getfeatureinfo...
>
> Parti dal javascript che genera qgis3web
>
> amefad
>
> Il Gio 27 Feb 2020, 19:02 Massimiliano Moraca 
> ha scritto:
>
>> Salve a tutti,
>> in un progetto con OpenLayers ho la necessità di visualizzare, al
>> passaggio
>> del mouse, i valori dei pixel di un raster.
>> Mi è stato detto che è possibile ma non sono riuscito a trovare riscontri,
>> magari cerco male.
>> A voi risulta possibile?
>>
>>
>> *ing.Massimiliano Moraca*
>> *Analisi, progettazione e sviluppo di soluzioni GIS e WebGIS*
>> *P.IVA*: 08700081212
>> *CELL*: 333 59 49 583 (*lun - ven 9.00 - 18.00*)
>> *WEB*: www.massimilianomoraca.it
>> * Attività svolta ai sensi della Legge 4 del 14 gennaio 2013, art.1*
>> ___
>> Gfoss@lists.gfoss.it
>> http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
>> Questa e' una lista di discussione pubblica aperta a tutti.
>> I messaggi di questa lista non hanno relazione diretta con le posizioni
>> dell'Associazione GFOSS.it.
>> 764 iscritti al 23/08/2019
>
>
___
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni 
dell'Associazione GFOSS.it.
764 iscritti al 23/08/2019

[Gfoss] Visualizzare il valore del pixel con OpenLayers

2020-02-27 Per discussione Massimiliano Moraca
Salve a tutti,
in un progetto con OpenLayers ho la necessità di visualizzare, al passaggio
del mouse, i valori dei pixel di un raster.
Mi è stato detto che è possibile ma non sono riuscito a trovare riscontri,
magari cerco male.
A voi risulta possibile?


*ing.Massimiliano Moraca*
*Analisi, progettazione e sviluppo di soluzioni GIS e WebGIS*
*P.IVA*: 08700081212
*CELL*: 333 59 49 583 (*lun - ven 9.00 - 18.00*)
*WEB*: www.massimilianomoraca.it
* Attività svolta ai sensi della Legge 4 del 14 gennaio 2013, art.1*
___
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni 
dell'Associazione GFOSS.it.
764 iscritti al 23/08/2019

Re: [Gfoss] QGIS held broken packages

2020-02-04 Per discussione Massimiliano Moraca
Si, infatti controllando i repository c'era un macello tale che ho dovuto
formattare.

Tutto comunque è nato da questa disavventura con gdal2tiles[1]. Ho provato
ad usarlo sia con venv che con conda ma nonostante fosse tra i package di
GDAL presenti sul PC, continuavo ad avere il messaggio che gdal2tiles era
mancante.

Prima della risposta che mi è arrivata su GIS.stackexchange sono riuscito a
risolvere installando globalmente anche gdal2tiles nonostante già fosse
presente GDAL, ed aggiornando l'ambiente di sviluppo Anaconda 3 con
l'ultima versione di conda nonostante avessi appena creato l'ambiente.
Scrivo nonostante perché mi sarei aspettato di avere già l'ultima versione
visto che oggi ho installato Anaconda 3.

Forse tutto ciò mi sembra strano perché non sono ferratissimo lato sviluppo.



[1] https://
gis.stackexchange.com/questions/349544/install-gdal2tiles-inside-conda-environment/349556#349556

Il mar 4 feb 2020, 14:51 Roberto Marzocchi  ha
scritto:

> Controlla i repository.
>
> Quello di Ubuntu o Ubuntu-ltr non necessitano più del repository ubuntugis.
>
> In passato mi è successa una roba simile ma ripulendo i repository ho
> sistemato la faccenda.
>
> R
>
>
>
>
> Eng. Roberto Marzocchi, PhD
> GIS Project Coordinator
> Gter srl (Unige spin-off)
> Via Ruffini 9R - 16128 GenovaP.IVA/CF 01998770992
> ph: 010-0899150 - mob: 349-8786575
> E-mail: roberto.marzoc...@gter.itwww.gter.it
>
> --
> Gter socialwww.twitter.com/Gteronline - 
> www.facebook.com/Gteronlinewww.linkedin.com/company/gter-srl-innovazione-in-geomatica-gnss-e-gis
>
> -
> Please consider the environment before printing this email!
>
>
>
>  On mar, 04 feb 2020 09:27:59 +0100 * i...@massimilianomoraca.it
>  * wrote 
>
> Buongiorno a tutti,
> ieri ho provato ad usare gdal2tiles in ufficio sul mio pc con Ubuntu 18.04
> ma nonostante avessi già installato GDAL, una volta creato l'ambiente di
> sviluppo per Python con venv, continuavo a leggere da terminale che
> libreria era assente.
> Un mio collega si è offerto di aiutarmi e lì è successo il macello. Ha
> disinstallato brutalmente GDAL che si è portato appresso anche QGIS;
> *sources.list* non è stato toccato. A Napoli si dice "Và p'aiut e truov
> sgarrup"(chiedi aiuto e ti ritrovi un danno).
> Ho necessità di reinstallare QGIS ma tutte le volte che ci provo con `sudo
> apt-get install qgis qgis-plugin-grass` ottengo questo:
>
> Some packages could not be installed. This may mean that you have
> > requested an impossible situation or if you are using the unstable
> > distribution that some required packages have not yet been created
> > or been moved out of Incoming.
> > The following information may help to resolve the situation:
> > The following packages have unmet dependencies:
> > python3-qgis : Depends: libqgis-analysis3.4.15 but it is not going to be
> > installed
> > qgis : Depends: gdal-abi-2-2-3
> > Depends: libqgis-analysis3.4.15 but it is not going to be installed
> > Depends: libqgis-app3.4.15 but it is not going to be installed
> > qgis-plugin-grass : Depends: grass740
> > Depends: libqgis-app3.4.15 but it is not going to be
> > installed
> > E: Unable to correct problems, you have held broken packages.
>
>
> Mi sembra chiaro che alcuni pacchetti mancano ma prima di procedere al
> ripristino manuale di ogni singolo pacchetto avete consigli da darmi su
> metodi più veloci?
>
>
>
> *ing.Massimiliano Moraca*
> *Analisi, progettazione e sviluppo di soluzioni GIS e WebGIS*
> *P.IVA*: 08700081212
> *CELL*: 333 59 49 583 (*lun - ven 9.00 - 18.00*)
> *WEB*: www.massimilianomoraca.it
> * Attività svolta ai sensi della Legge 4 del 14 gennaio 2013, art.1*
> ___
> Gfoss@lists.gfoss.it
> http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
> Questa e' una lista di discussione pubblica aperta a tutti.
> I messaggi di questa lista non hanno relazione diretta con le posizioni
> dell'Associazione GFOSS.it.
> 764 iscritti al 23/08/2019
>
>
>
___
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni 
dell'Associazione GFOSS.it.
764 iscritti al 23/08/2019

[Gfoss] QGIS held broken packages

2020-02-04 Per discussione Massimiliano Moraca
Buongiorno a tutti,
ieri ho provato ad usare gdal2tiles in ufficio sul mio pc con Ubuntu 18.04
ma nonostante avessi già installato GDAL, una volta creato l'ambiente di
sviluppo per Python con venv, continuavo a leggere da terminale che
libreria era assente.
Un mio collega si è offerto di aiutarmi e lì è successo il macello. Ha
disinstallato brutalmente GDAL che si è portato appresso anche QGIS;
*sources.list* non è stato toccato. A Napoli si dice "Và p'aiut e truov
sgarrup"(chiedi aiuto e ti ritrovi un danno).
Ho necessità di reinstallare QGIS ma tutte le volte che ci provo con `sudo
apt-get install qgis qgis-plugin-grass` ottengo questo:

Some packages could not be installed. This may mean that you have
> requested an impossible situation or if you are using the unstable
> distribution that some required packages have not yet been created
> or been moved out of Incoming.
> The following information may help to resolve the situation:
> The following packages have unmet dependencies:
>  python3-qgis : Depends: libqgis-analysis3.4.15 but it is not going to be
> installed
>  qgis : Depends: gdal-abi-2-2-3
> Depends: libqgis-analysis3.4.15 but it is not going to be installed
> Depends: libqgis-app3.4.15 but it is not going to be installed
>  qgis-plugin-grass : Depends: grass740
>  Depends: libqgis-app3.4.15 but it is not going to be
> installed
> E: Unable to correct problems, you have held broken packages.


Mi sembra chiaro che alcuni pacchetti mancano ma prima di procedere al
ripristino manuale di ogni singolo pacchetto avete consigli da darmi su
metodi più veloci?



*ing.Massimiliano Moraca*
*Analisi, progettazione e sviluppo di soluzioni GIS e WebGIS*
*P.IVA*: 08700081212
*CELL*: 333 59 49 583 (*lun - ven 9.00 - 18.00*)
*WEB*: www.massimilianomoraca.it
* Attività svolta ai sensi della Legge 4 del 14 gennaio 2013, art.1*
___
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni 
dell'Associazione GFOSS.it.
764 iscritti al 23/08/2019

Re: [Gfoss] Automatizzare l'intersezione con un TRIGGER

2019-12-29 Per discussione Massimiliano Moraca
Si avevi ragione Sandro, mancava l'INSERT INTO.
Mi sono fatto trarre in inganno dal CREATE TRIGGER che puntava su
intersection_output, credevo che bastasse quello.
Ricapitolando quindi serve l'INSERT INTO ed il CREATE TRIGGER deve puntare
al vettore che scatena l'evento, buffer nel mio caso.
Grazie mille e buona domenica

*ing.Massimiliano Moraca*
*Analisi, progettazione e sviluppo di soluzioni GIS e WebGIS*
*P.IVA*: 08700081212
*CELL*: 333 59 49 583 (*lun - ven 9.00 - 18.00*)
*WEB*: www.massimilianomoraca.it
* Attività svolta ai sensi della Legge 4 del 14 gennaio 2013, art.1*


Il giorno sab 28 dic 2019 alle ore 18:44  ha scritto:

> On Sat, 28 Dec 2019 18:19:02 +0100, Massimiliano Moraca wrote:
> > sostituendo con buffer ottengo questo
> > messaggio di errore nel momento in cui voglio salvare il poligono
> > creato:
> >
> >> Could not commit changes to layer buffer
> >> Errors: ERROR: 1 feature(s) not added.
> >>
> >> Provider errors:
> >> PostGIS error while adding features: ERRORE: la query non ha una
> >> destinazione per i dati restituiti
> >> HINT: Se vuoi scartare i risultati di una SELECT, utilizza PERFORM.
> >> CONTEXT: funzione PL/pgSQL intersection_function() riga 3 a
> >> istruzione SQL
> >
>
> Massimiliano,
>
> sempre premettendo che io conosco bene i Triggers di SQLite e molto
> poco quelli di PostgreSQL (e paiono sostanzialmente diversi).
>
> ragionando a fil di logica l'errore dovrebbe nascere dal fatto che
> tu nel tuo trigger-body in effetti ti limiti a fare una SELECT, ma
> non specifichi mai da nessuna parte che quei valori ottenuti dalla
> SELECT poi li vuoi inserire nella tavola di output.
> verosimilmente quello che ti serve e' definire uno statement SQL
> piu' o meno di questo tenore:
>
> INSERT INTO intersection_output (idb, idp, geom)
> SELECT a.idb, b.idp, ST_Intersection(a.geom, b.geom)
> FROM . etc etc ...
>
> ===
> hint:
> un trigger non e' altro che un normalissimo statement SQL
> (piu' o meno complesso) che scatta automaticamente tutte le
> volte che si realizza un determinato evento.
> di per se non ha nulla di "magico", tutte le azioni che
> intendi fare te le devi definire tu una per una.
>
> ciao Sandro
>
___
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni 
dell'Associazione GFOSS.it.
764 iscritti al 23/08/2019

Re: [Gfoss] Automatizzare l'intersezione con un TRIGGER

2019-12-28 Per discussione Massimiliano Moraca
Ora che mi ci fai ragionare effettivamente il target della INSERT è
sbagliato ma non dovrebbe essere nemmeno polygons che sono "statici" ma
buffer visto che traccio io i poligoni in buffer.
Comunque sostituendo polygons continuo ad ottenere una tabella vuota in
intersection_output mentre sostituendo con buffer ottengo questo messaggio
di errore nel momento in cui voglio salvare il poligono creato:

> Could not commit changes to layer buffer
> Errors: ERROR: 1 feature(s) not added.
>
> Provider errors:
> PostGIS error while adding features: ERRORE: la query non ha una
> destinazione per i dati restituiti
> HINT: Se vuoi scartare i risultati di una SELECT, utilizza PERFORM.
> CONTEXT: funzione PL/pgSQL intersection_function() riga 3 a istruzione SQL



*ing.Massimiliano Moraca*
*Analisi, progettazione e sviluppo di soluzioni GIS e WebGIS*
*P.IVA*: 08700081212
*CELL*: 333 59 49 583 (*lun - ven 9.00 - 18.00*)
*WEB*: www.massimilianomoraca.it
* Attività svolta ai sensi della Legge 4 del 14 gennaio 2013, art.1*


Il giorno sab 28 dic 2019 alle ore 17:45  ha scritto:

> Massimiliano,
>
> premetto che non ho nessuna familiarita' con i Triggers di PostreSQL,
> ma conosco molto bene quelli di SQLite.
>
> CREATE TRIGGER make_intersection AFTER INSERT ON intersection_output
>
> con la clausola AFTER INSERT di cui sopra tu stai chiedendo a Postgres
> di attivare il tuo trigger ogni volta che viene inserita una nuova
> riga nella tavola "intersection_output"
> ma da tutta la spiegazione precedente io ho capito che questa (come
> del resto dice il nome) e' appunto la tavola di output destinata a
> collezionare le intersezioni.
> sembra che tu le tue INSERT con QGIS le fai invece su "polygons",
> e di conseguenza quel trigger non scattera' mai.
>
> almeno a lume di naso quel trigger va definito come:
>
> CREATE TRIGGER make_intersection AFTER INSERT ON polygons
>
> ciao Sandro
>
>
> On Sat, 28 Dec 2019 17:21:17 +0100, Massimiliano Moraca wrote:
> > Salve a tutti, sto dedicando questi giorni a familiarizzare con i
> > TRIGGER
> > in PostGIS prendendo spunto da questa[1] guida. Sono riuscito a
> > creare
> > automaticamente un buffer a partire dall'editing di un vettore
> > lineare e
> > quello che voglio fare ora è eseguire un *intersection* tra i buffer
> > e
> > alcuni poligoni. Ho quindi due tabelle principali: *buffer* e
> > *polygons*;
> > l'output dell'intersezione deve confluire in una tabella in cui
> > verranno
> > riportati anche gli id dei poligoni da cui è scaturita
> > l'intersezione(idb
> > per buffer e idp per polygons). La tabella in cui confluiranno questi
> > dati
> > l'ho chiamata *intersection_output*.
> >
> > Ho scritto quindi questo TRIGGER:
> >
> >> CREATE OR REPLACE FUNCTION intersection_function() RETURNS trigger
> >> AS
> >> $BODY$
> >> BEGIN
> >> SELECT
> >> a.idb,
> >> b.idp,
> >> ST_Intersection(a.geom, b.geom) as geom
> >> FROM
> >> buffer AS a,
> >> polygons AS b
> >> WHERE ST_Intersects(a.geom, b.geom);
> >> RETURN NEW;
> >> END;
> >> $BODY$
> >> LANGUAGE 'plpgsql';
> >> CREATE TRIGGER make_intersection
> >> AFTER INSERT ON intersection_output
> >> FOR EACH ROW EXECUTE PROCEDURE intersection_function();
> >
> >
> > Mi aspetto quindi che ogni volta che creo un poligono, ad esempio con
> > QGIS,
> > nella tabella *buffer*, esso venga intersecato con il o i poligoni,
> > presenti in *polygons*, che vengono coperti dall'area di buffer ed il
> > risultato di questa intersezione deve essere scritto in
> > *intersection_output*.
> >
> > Il problema che riscontro è che la tabella delle intersezioni resta
> > sempre
> > vuota nonostante sia le geometrie di buffer che di polygons siano in
> > 4326.
> >
> > Sicuramente sbaglio io qualcosa ma non mi è chiaro dove.
> >
> >
> > 
> > [1]
> > http://www.postgresqltutorial.com/creating-first-trigger-postgresql/
> >
> > *ing.Massimiliano Moraca*
> > *Analisi, progettazione e sviluppo di soluzioni GIS e WebGIS*
> > *P.IVA*: 08700081212
> > *CELL*: 333 59 49 583 (*lun - ven 9.00 - 18.00*)
> > *WEB*: www.massimilianomoraca.it
> > * Attività svolta ai sensi della Legge 4 del 14 gennaio 2013, art.1*
> > ___
> > Gfoss@lists.gfoss.it
> > http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
> > Questa e' una lista di discussione pubblica aperta a tutti.
> > I messaggi di questa lista non hanno relazione diretta con le
&

[Gfoss] Automatizzare l'intersezione con un TRIGGER

2019-12-28 Per discussione Massimiliano Moraca
Salve a tutti, sto dedicando questi giorni a familiarizzare con i TRIGGER
in PostGIS prendendo spunto da questa[1] guida. Sono riuscito a creare
automaticamente un buffer a partire dall'editing di un vettore lineare e
quello che voglio fare ora è eseguire un *intersection* tra i buffer e
alcuni poligoni. Ho quindi due tabelle principali: *buffer* e *polygons*;
l'output dell'intersezione deve confluire in una tabella in cui verranno
riportati anche gli id dei poligoni da cui è scaturita l'intersezione(idb
per buffer e idp per polygons). La tabella in cui confluiranno questi dati
l'ho chiamata *intersection_output*.

Ho scritto quindi questo TRIGGER:

> CREATE OR REPLACE FUNCTION intersection_function() RETURNS trigger AS
> $BODY$
> BEGIN
> SELECT
> a.idb,
> b.idp,
> ST_Intersection(a.geom, b.geom) as geom
> FROM
> buffer AS a,
> polygons AS b
> WHERE ST_Intersects(a.geom, b.geom);
> RETURN NEW;
> END;
> $BODY$
> LANGUAGE 'plpgsql';
> CREATE TRIGGER make_intersection
> AFTER INSERT ON intersection_output
> FOR EACH ROW EXECUTE PROCEDURE intersection_function();


Mi aspetto quindi che ogni volta che creo un poligono, ad esempio con QGIS,
nella tabella *buffer*, esso venga intersecato con il o i poligoni,
presenti in *polygons*, che vengono coperti dall'area di buffer ed il
risultato di questa intersezione deve essere scritto in
*intersection_output*.

Il problema che riscontro è che la tabella delle intersezioni resta sempre
vuota nonostante sia le geometrie di buffer che di polygons siano in 4326.

Sicuramente sbaglio io qualcosa ma non mi è chiaro dove.



[1] http://www.postgresqltutorial.com/creating-first-trigger-postgresql/

*ing.Massimiliano Moraca*
*Analisi, progettazione e sviluppo di soluzioni GIS e WebGIS*
*P.IVA*: 08700081212
*CELL*: 333 59 49 583 (*lun - ven 9.00 - 18.00*)
*WEB*: www.massimilianomoraca.it
* Attività svolta ai sensi della Legge 4 del 14 gennaio 2013, art.1*
___
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni 
dell'Associazione GFOSS.it.
764 iscritti al 23/08/2019

Re: [Gfoss] Confronto calcolo di aree tra QGIS e POSTGIS con TRIGGER

2019-12-27 Per discussione Massimiliano Moraca
Si, in effetti impostando 32633 al posto di 3857 il risultato cambia di
molto anche se non è comunque identico. Mi trovo un 0.692005 da PostGIS e
0.692478 da QGIS.
So che 3857 non andrebbe usato per il calcolo delle aree(in generale non
andrebbe usato) ma essendo un test con in un DB di test era il primo EPSG
che mi è venuto in mente e l'ho usato. Certo non mi aspettavo errori così
madornali! Fortuna che era un test!

*ing.Massimiliano Moraca*
*Analisi, progettazione e sviluppo di soluzioni GIS e WebGIS*
*P.IVA*: 08700081212
*CELL*: 333 59 49 583 (*lun - ven 9.00 - 18.00*)
*WEB*: www.massimilianomoraca.it
* Attività svolta ai sensi della Legge 4 del 14 gennaio 2013, art.1*


Il giorno ven 27 dic 2019 alle ore 16:32 Roberto Marzocchi <
roberto.marzoc...@gter.it> ha scritto:

> Per prima cosa ti sconsiglio di fare calcoli su aree usando il 3857 che ha
> delle deformazioni che fanno spavento.. In passato ho fatto delle prove su
> una griglia 80mx80m e un lato mi risultava di 110m
>
> Dalle proprietà del progetto di QGIS puoi vedere quale ellissoide usa per
> fare il calcolo delle aree e tendenzialmente QGIS è in gradi di fare il
> calcolo di lunghezze e aree sull'ellissoide (volendo puoi dirgli anche di
> fare misure planimetriche ma usando 3857 come dicevo sopra lo ritengo
> pericoloso.
>
> PostGIS da quello che si legge sul manuale [1] fa calcoli solo
> planimetrici usando il SRID che trova.
>
> Per verificare tutto ciò prova a settare anche QGIS in quel modo (misure
> planimetriche) e il dato dovrebbe essere simile (ma attento perchè le
> misure dovrebbero risultare simili, ma sono entrambe fortemente sbagliate!!)
>
> In sintesi differenze ci saranno sempre con i 2 metodi ma almeno cambiando
> CRS dei dati dovresti ridurre gli errori.
> R
>
> [1] https://postgis.net/docs/ST_Area.html
>
> Eng. Roberto Marzocchi, PhD
> GIS Project Coordinator
> Gter srl (Unige spin-off)
> Via Ruffini 9R - 16128 GenovaP.IVA/CF 01998770992
> ph: 010-0899150 - mob: 349-8786575
> E-mail: roberto.marzoc...@gter.itwww.gter.it
>
> --
> Gter socialwww.twitter.com/Gteronline - 
> www.facebook.com/Gteronlinewww.linkedin.com/company/gter-srl-innovazione-in-geomatica-gnss-e-gis
>
> -
> Please consider the environment before printing this email!
>
>
>
>
>  Attivato Fri, 27 Dec 2019 15:56:23 +0100 *Umberto Minora
> >* ha scritto ----
>
> solo un'ipotesi, ma in QGIS il progetto è impostato sul sistema di
> riferimento del dato ovvero 3857?
>
> Il 27/dic/2019 15:48 Massimiliano Moraca  ha
> scritto:
> >
> > Salve a tutti e buon Natale passato.
> > Sto sperimentando i TRIGGER usando PostGIS ed ho creato un semplice
> vettore
> > poligonale in cui è presente una colonna area che deve riempirsi
> > automaticamente dopo la creazione del poligono. L'area deve essere in
> > ettari.
> >
> > Ho quindi creato il mio vettore:
> >
> > > CREATE TABLE buffer
> > > (
> > > id INTEGER PRIMARY KEY,
> > > area_ha DECIMAL
> > > );
> > > SELECT AddGeometryColumn(
> > > 'buffer',
> > > 'geom',
> > > 3857,
> > > 'POLYGON',
> > > 2
> > > );
> >
> > Ed i TRIGGER associati:
> >
> > > CREATE FUNCTION areabuffer_trigger_function() RETURNS trigger AS $$
> > > BEGIN
> > >  NEW.area_ha = ST_AREA(NEW.geom)/1;
> > >  RETURN NEW;
> > > END;
> > > $$ language plpgsql;
> > >
> > > CREATE TRIGGER areabuffer_trigger
> > >  BEFORE INSERT OR UPDATE
> > >  ON buffer
> > >  FOR EACH ROW
> > >  EXECUTE PROCEDURE areabuffer_trigger_function();
> >
> > Creando il poligono o i poligoni in QGIS e salvando l'editing, il campo
> > *area_ha* viene effettivamente riempito con un valore. Come test ho
> creato
> > un field virtuale nel calcolatore di campi usando la funzione
> `*$area/1*`
> > ma noto che i valori di area calcolati in QGIS sono diversi da quelli che
> > calcola PostGIS usando il TRIGGER.
> > Ad esempo il poligono 1 ha un valore di area da TRIGGER pari a 36,6917
> > mentre il corrispettivo da QGIS è 20,9879.
> >
> > Come mai?
> >
> > *ing.Massimiliano Moraca*
> > *Analisi, progettazione e sviluppo di soluzioni GIS e WebGIS*
> > *P.IVA*: 08700081212
> > *CELL*: 333 59 49 583 (*lun - ven 9.00 - 18.00*)
> > *WEB*: www.massimilianomoraca.it
> > * Attività svolta ai sensi della Legge 4 del 14 gennaio 2013, art.1*
> > ___
> > Gfoss@lists.gfoss.it
> > http:/

Re: [Gfoss] Confronto calcolo di aree tra QGIS e POSTGIS con TRIGGER

2019-12-27 Per discussione Massimiliano Moraca
Visto che era un test con un solo layer l'ho caricato direttamente in QGIS
e lui ha settato il SR del progetto in 3857. Comunque ho appena creato un
progetto di test presettando il SR in 3857 ed anche in questo caso il
calcolo dell'area è diverso dal risultato di PostGIS.

La versione di QGIS in uso è la 3.4 mentre PostgreSQL/PostGIS è in versione
12.1/3.0

*ing.Massimiliano Moraca*
*Analisi, progettazione e sviluppo di soluzioni GIS e WebGIS*
*P.IVA*: 08700081212
*CELL*: 333 59 49 583 (*lun - ven 9.00 - 18.00*)
*WEB*: www.massimilianomoraca.it
* Attività svolta ai sensi della Legge 4 del 14 gennaio 2013, art.1*


Il giorno ven 27 dic 2019 alle ore 15:56 Umberto Minora <
umbertofili...@tiscali.it> ha scritto:

> solo un'ipotesi, ma in QGIS il progetto è impostato sul sistema di
> riferimento del dato ovvero 3857?
>
> Il 27/dic/2019 15:48 Massimiliano Moraca  ha
> scritto:
> >
> > Salve a tutti e buon Natale passato.
> > Sto sperimentando i TRIGGER usando PostGIS ed ho creato un semplice
> vettore
> > poligonale in cui è presente una colonna area che deve riempirsi
> > automaticamente dopo la creazione del poligono. L'area deve essere in
> > ettari.
> >
> > Ho quindi creato il mio vettore:
> >
> > > CREATE TABLE buffer
> > > (
> > > id INTEGER PRIMARY KEY,
> > > area_ha DECIMAL
> > > );
> > > SELECT AddGeometryColumn(
> > > 'buffer',
> > > 'geom',
> > > 3857,
> > > 'POLYGON',
> > > 2
> > > );
> >
> > Ed i TRIGGER associati:
> >
> > > CREATE FUNCTION areabuffer_trigger_function() RETURNS trigger AS $$
> > > BEGIN
> > >  NEW.area_ha = ST_AREA(NEW.geom)/1;
> > >  RETURN NEW;
> > > END;
> > > $$ language plpgsql;
> > >
> > > CREATE TRIGGER areabuffer_trigger
> > >  BEFORE INSERT OR UPDATE
> > >  ON buffer
> > >  FOR EACH ROW
> > >  EXECUTE PROCEDURE areabuffer_trigger_function();
> >
> > Creando il poligono o i poligoni in QGIS e salvando l'editing, il campo
> > *area_ha* viene effettivamente riempito con un valore. Come test ho
> creato
> > un field virtuale nel calcolatore di campi usando la funzione
> `*$area/1*`
> > ma noto che i valori di area calcolati in QGIS sono diversi da quelli che
> > calcola PostGIS usando il TRIGGER.
> > Ad esempo il poligono 1 ha un valore di area da TRIGGER pari a 36,6917
> > mentre il corrispettivo da QGIS è 20,9879.
> >
> > Come mai?
> >
> > *ing.Massimiliano Moraca*
> > *Analisi, progettazione e sviluppo di soluzioni GIS e WebGIS*
> > *P.IVA*: 08700081212
> > *CELL*: 333 59 49 583 (*lun - ven 9.00 - 18.00*)
> > *WEB*: www.massimilianomoraca.it
> > * Attività svolta ai sensi della Legge 4 del 14 gennaio 2013, art.1*
> > ___
> > Gfoss@lists.gfoss.it
> > http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
> > Questa e' una lista di discussione pubblica aperta a tutti.
> > I messaggi di questa lista non hanno relazione diretta con le posizioni
> dell'Associazione GFOSS.it.
> > 764 iscritti al 23/08/2019
___
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni 
dell'Associazione GFOSS.it.
764 iscritti al 23/08/2019

[Gfoss] Confronto calcolo di aree tra QGIS e POSTGIS con TRIGGER

2019-12-27 Per discussione Massimiliano Moraca
Salve a tutti e buon Natale passato.
Sto sperimentando i TRIGGER usando PostGIS ed ho creato un semplice vettore
poligonale in cui è presente una colonna area che deve riempirsi
automaticamente dopo la creazione del poligono. L'area deve essere in
ettari.

Ho quindi creato il mio vettore:

> CREATE TABLE buffer
> (
> id INTEGER PRIMARY KEY,
> area_ha DECIMAL
> );
> SELECT AddGeometryColumn(
> 'buffer',
> 'geom',
> 3857,
> 'POLYGON',
> 2
> );


Ed i TRIGGER associati:

> CREATE FUNCTION areabuffer_trigger_function() RETURNS trigger AS $$
> BEGIN
>  NEW.area_ha = ST_AREA(NEW.geom)/1;
>  RETURN NEW;
> END;
> $$ language plpgsql;
>
> CREATE TRIGGER areabuffer_trigger
>  BEFORE INSERT OR UPDATE
>  ON buffer
>  FOR EACH ROW
>  EXECUTE PROCEDURE areabuffer_trigger_function();


Creando il poligono o i poligoni in QGIS e salvando l'editing, il campo
*area_ha* viene effettivamente riempito con un valore. Come test ho creato
un field virtuale nel calcolatore di campi usando la funzione `*$area/1*`
ma noto che i valori di area calcolati in QGIS sono diversi da quelli che
calcola PostGIS usando il TRIGGER.
Ad esempo il poligono 1 ha un valore di area da TRIGGER pari a 36,6917
mentre il corrispettivo da QGIS è 20,9879.

Come mai?

*ing.Massimiliano Moraca*
*Analisi, progettazione e sviluppo di soluzioni GIS e WebGIS*
*P.IVA*: 08700081212
*CELL*: 333 59 49 583 (*lun - ven 9.00 - 18.00*)
*WEB*: www.massimilianomoraca.it
* Attività svolta ai sensi della Legge 4 del 14 gennaio 2013, art.1*
___
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni 
dell'Associazione GFOSS.it.
764 iscritti al 23/08/2019

Re: [Gfoss] Scegliere il SR di un progetto a scala globale

2019-11-30 Per discussione Massimiliano Moraca
Grazie mille Enrico, approfondirò a breve

Il sab 30 nov 2019, 10:39 Enrico Ferreguti  ha scritto:

> Quando definisci il campo geometria in geodjango con srid="EPSG:4326"
> dovresti settare il flag geography a True:
> https://docs.djangoproject.com/en/2.2/ref/contrib/gis/model-api/#geography
> in questo modo il calcolo delle distanze terrà conto della curvatura
> terrestre e sarà espresso in metri, al contrario del campo geometria
> semplice che esprimerà le distanze in gradi.
> Se ho capito bene il tuo problema questo accorgimento dovrebbe essere
> risolutivo.
>
> Il giorno sab 30 nov 2019 alle ore 10:11 Massimiliano Moraca <
> i...@massimilianomoraca.it> ha scritto:
>
>> Scusare il refuso su copia ed incolla errato
>>
>> > di
>> > rendering sarà MapBox che accetta.
>>
>>
>> *ing.Massimiliano Moraca*
>> *Analisi, progettazione e sviluppo di soluzioni GIS e WebGIS*
>> *P.IVA*: 08700081212
>> *CELL*: 333 59 49 583 (*lun - ven 9.00 - 18.00*)
>> *WEB*: www.massimilianomoraca.it
>> * Attività svolta ai sensi della Legge 4 del 14 gennaio 2013, art.1*
>>
>>
>> Il giorno sab 30 nov 2019 alle ore 09:56 Massimiliano Moraca <
>> i...@massimilianomoraca.it> ha scritto:
>>
>> > Buongiorno a tutti, vi scrivo per avere un consiglio.
>> > Sono stato coinvolto in un progetto mirato allo sviluppo di una
>> piattaforma
>> > WebGIS per l'analisi di dati satellitari in cui devono essere presenti
>> > anche
>> > tool di misurazione di distanze e buffer in metri/km; il "motore" di
>> > rendering sarà MapBox che accetta.
>> >
>> > MapBox lavora solo con EPSG 3857[1] e dal 2016 ad oggi[2] gli
>> sviluppatori
>> > di questa libreria non sembrano intenzionati a cambiare lo status quo
>> > perchè
>> > è una libreria pensata per la renderizzazione del dato cartografico e
>> non
>> > per le analisi.
>> >
>> > Io sono abituato ad usare OpenLayers su progetti a scala "locale" in cui
>> > per
>> > forza di cose si usa il sistema di riferimento locale e sicuramente non
>> il
>> > 3857.
>> >
>> > La mia strategia per aggirare il problema del SR è quella di lavorare in
>> > 4326 convertendo tramite uno script in python le distanze di buffer,
>> > inserite dall'utente in metri, in gradi in modo che quando MapBox fa la
>> sua
>> > riproiezione in 3857 non ho deformazioni e tra l'altro non avrei
>> problemi
>> > di
>> > luoghi di provenienza dei dati essendo il 4326 globale.
>> >
>> > Voi che strategia usereste?
>> >
>> > Il progetto in questione usa GeoDjango e PostGIS.
>> >
>> >
>> > -
>> > [1] https://docs.mapbox.com/help/glossary/projection/
>> > [2] https://github.com/mapbox/mapbox-gl-js/issues/3184
>> >
>> > -
>> > Consulente GIS,  Formatore, Blogger e Ciclista Urbano
>> > email: i...@massimilianomoraca.it
>> > cell: 333 5949583 (lun-ven, 9.00-18.00)
>> > website: massimilianomoraca.it
>> > --
>> > Sent from:
>> >
>> http://gfoss-geographic-free-and-open-source-software-italian-mailing.3056002.n2.nabble.com/
>> > ___
>> > Gfoss@lists.gfoss.it
>> > http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
>> > Questa e' una lista di discussione pubblica aperta a tutti.
>> > I messaggi di questa lista non hanno relazione diretta con le posizioni
>> > dell'Associazione GFOSS.it.
>> > 764 iscritti al 23/08/2019
>> ___
>> Gfoss@lists.gfoss.it
>> http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
>> Questa e' una lista di discussione pubblica aperta a tutti.
>> I messaggi di questa lista non hanno relazione diretta con le posizioni
>> dell'Associazione GFOSS.it.
>> 764 iscritti al 23/08/2019
>
>
___
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni 
dell'Associazione GFOSS.it.
764 iscritti al 23/08/2019

Re: [Gfoss] Scegliere il SR di un progetto a scala globale

2019-11-30 Per discussione Massimiliano Moraca
Scusare il refuso su copia ed incolla errato

> di
> rendering sarà MapBox che accetta.


*ing.Massimiliano Moraca*
*Analisi, progettazione e sviluppo di soluzioni GIS e WebGIS*
*P.IVA*: 08700081212
*CELL*: 333 59 49 583 (*lun - ven 9.00 - 18.00*)
*WEB*: www.massimilianomoraca.it
* Attività svolta ai sensi della Legge 4 del 14 gennaio 2013, art.1*


Il giorno sab 30 nov 2019 alle ore 09:56 Massimiliano Moraca <
i...@massimilianomoraca.it> ha scritto:

> Buongiorno a tutti, vi scrivo per avere un consiglio.
> Sono stato coinvolto in un progetto mirato allo sviluppo di una piattaforma
> WebGIS per l'analisi di dati satellitari in cui devono essere presenti
> anche
> tool di misurazione di distanze e buffer in metri/km; il "motore" di
> rendering sarà MapBox che accetta.
>
> MapBox lavora solo con EPSG 3857[1] e dal 2016 ad oggi[2] gli sviluppatori
> di questa libreria non sembrano intenzionati a cambiare lo status quo
> perchè
> è una libreria pensata per la renderizzazione del dato cartografico e non
> per le analisi.
>
> Io sono abituato ad usare OpenLayers su progetti a scala "locale" in cui
> per
> forza di cose si usa il sistema di riferimento locale e sicuramente non il
> 3857.
>
> La mia strategia per aggirare il problema del SR è quella di lavorare in
> 4326 convertendo tramite uno script in python le distanze di buffer,
> inserite dall'utente in metri, in gradi in modo che quando MapBox fa la sua
> riproiezione in 3857 non ho deformazioni e tra l'altro non avrei problemi
> di
> luoghi di provenienza dei dati essendo il 4326 globale.
>
> Voi che strategia usereste?
>
> Il progetto in questione usa GeoDjango e PostGIS.
>
>
> -
> [1] https://docs.mapbox.com/help/glossary/projection/
> [2] https://github.com/mapbox/mapbox-gl-js/issues/3184
>
> -
> Consulente GIS,  Formatore, Blogger e Ciclista Urbano
> email: i...@massimilianomoraca.it
> cell: 333 5949583 (lun-ven, 9.00-18.00)
> website: massimilianomoraca.it
> --
> Sent from:
> http://gfoss-geographic-free-and-open-source-software-italian-mailing.3056002.n2.nabble.com/
> ___
> Gfoss@lists.gfoss.it
> http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
> Questa e' una lista di discussione pubblica aperta a tutti.
> I messaggi di questa lista non hanno relazione diretta con le posizioni
> dell'Associazione GFOSS.it.
> 764 iscritti al 23/08/2019
___
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni 
dell'Associazione GFOSS.it.
764 iscritti al 23/08/2019

[Gfoss] Scegliere il SR di un progetto a scala globale

2019-11-30 Per discussione Massimiliano Moraca
Buongiorno a tutti, vi scrivo per avere un consiglio.
Sono stato coinvolto in un progetto mirato allo sviluppo di una piattaforma
WebGIS per l'analisi di dati satellitari in cui devono essere presenti anche
tool di misurazione di distanze e buffer in metri/km; il "motore" di
rendering sarà MapBox che accetta.

MapBox lavora solo con EPSG 3857[1] e dal 2016 ad oggi[2] gli sviluppatori
di questa libreria non sembrano intenzionati a cambiare lo status quo perchè
è una libreria pensata per la renderizzazione del dato cartografico e non
per le analisi.

Io sono abituato ad usare OpenLayers su progetti a scala "locale" in cui per
forza di cose si usa il sistema di riferimento locale e sicuramente non il
3857.

La mia strategia per aggirare il problema del SR è quella di lavorare in
4326 convertendo tramite uno script in python le distanze di buffer,
inserite dall'utente in metri, in gradi in modo che quando MapBox fa la sua
riproiezione in 3857 non ho deformazioni e tra l'altro non avrei problemi di
luoghi di provenienza dei dati essendo il 4326 globale.

Voi che strategia usereste?

Il progetto in questione usa GeoDjango e PostGIS.


-
[1] https://docs.mapbox.com/help/glossary/projection/
[2] https://github.com/mapbox/mapbox-gl-js/issues/3184

-
Consulente GIS,  Formatore, Blogger e Ciclista Urbano
email: i...@massimilianomoraca.it
cell: 333 5949583 (lun-ven, 9.00-18.00)
website: massimilianomoraca.it
--
Sent from: 
http://gfoss-geographic-free-and-open-source-software-italian-mailing.3056002.n2.nabble.com/
___
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni 
dell'Associazione GFOSS.it.
764 iscritti al 23/08/2019

Re: [Gfoss] Cambiare SR a tutti i vettori di un progetto QGIS provenienti da PostGIS

2019-11-10 Per discussione Massimiliano Moraca
Amedeo ha funzionato anche sui dati "buoni".
Grazie ancora :)

*ing.Massimiliano Moraca*
*Analisi, progettazione e sviluppo di soluzioni GIS e WebGIS*
*P.IVA*: 08700081212
*CELL*: 333 59 49 583 (*lun - ven 9.00 - 18.00*)
*WEB*: www.massimilianomoraca.it
* Attività svolta ai sensi della Legge 4 del 14 gennaio 2013, art.1*


Il giorno dom 10 nov 2019 alle ore 12:09 Massimiliano Moraca <
i...@massimilianomoraca.it> ha scritto:

> Amedeo grazie per la risposta. Scusa il ritardo nel risponderti ma sono
> stato impegnato.
> Il tuo metodo sembra funzionare, dico sembra perchè l'ho usato su un
> progetto di test ed effettivamente aggiungendo una nuova colonna geometrica
> e modificando il .qgs ho ottenuto ciò che volevo.
> Devo applicare questo metodo ai miei progetti che ho e che sono connessi
> allo stesso db e teoricamente non dovrei avere nemmeno problemi con i
> layout di stampa contenuti nei singoli progetti.
>
> *ing.Massimiliano Moraca*
> *Analisi, progettazione e sviluppo di soluzioni GIS e WebGIS*
> *P.IVA*: 08700081212
> *CELL*: 333 59 49 583 (*lun - ven 9.00 - 18.00*)
> *WEB*: www.massimilianomoraca.it
> * Attività svolta ai sensi della Legge 4 del 14 gennaio 2013, art.1*
>
>
> Il giorno mar 5 nov 2019 alle ore 08:00 Amedeo Fadini 
> ha scritto:
>
>> Ciao Massimiliano,
>> uno dei vantaggi di lavorare con Postgis è che per cascuna tabella puoi
>> avere più colonne geometriche, quindi a rigore non devi cambiare SR alla
>> *Tabella* ma alla *colonna* e alle singole geometrie.
>> Così  a occhio se non ti trovi nella mia situazione (dove 5 Mln di
>> geometrie generano problemi di spazio) ti suggerirei di *aggiungere* una
>> nuova colonna con nuovo SR
>>
>> A questo punto nei progetti QGIS puo semplicemente cambiare la data
>> source (mi pare che nelle versioni attuali si possa fare per tutti i layer
>> selezionati) impostando la nuova colonna.
>>
>> Ad ogni modo dovrebbe essere possibile decomprimere il qgz in qgs e a
>> quel punto puoi modificare l'XML
>>
>> Nel file qgs per i layer postgis trovi una riga simile a questa
>>
>> dbname='pdm_governance' host=localhost port=5432
>> sslmode=disable key='id' srid=3035 type=MultiPolygon
>> checkPrimaryKeyUnicity='0' table="public"."Governance1 Abruzzo_dB" (geom)
>> sql=
>>
>> prova a modificare il codice delle srid e il nome della colonna
>> geometrica tra parentesi
>>
>> Amedeo
>>
>>
>>
>>
>> Il giorno lun 4 nov 2019 alle ore 18:30 Massimiliano Moraca <
>> i...@massimilianomoraca.it> ha scritto:
>>
>>> Salve a tutti,
>>> ho la necessità di riproiettare in EPSG 2154 tutte le tabelle di un DB in
>>> PostGIS. Per farlo seguirei questa procedura[1] che tra l'altro mi pare
>>> di
>>> aver già usato nel recente passato.
>>>
>>> Il punto è che ho tre progetti QGIS 3.4 collegati a questo database, con
>>> un
>>> centinaio di layout di stampa, ed effettuando la riproiezione ho
>>> verificato
>>> che l'SRID dei vettori in legenda non viene aggiornato.
>>>
>>> L'aggiornamento l'avevo già eseguito mesi fa, non ricordo quando,
>>> riscontrando lo stesso problema ma poi ho messo da parte il tutto finchè
>>> non mi è servito di nuovo(oggi).
>>>
>>> La mia domanda è: c'è un modo per modificare il .qgz in moda da
>>> sostituire
>>> il vecchio sistema di riferimento dei singoli vettori del progetto con il
>>> nuovo?
>>>
>>> Cambiare semplicemente l'SR al progetto e salvare il tutto non funziona.
>>>
>>> 
>>> [1] https://postgis.net/2013/08/30/tip_ST_Set_or_Transform/
>>>
>>> *ing.Massimiliano Moraca*
>>> *Analisi, progettazione e sviluppo di soluzioni GIS e WebGIS*
>>> *P.IVA*: 08700081212
>>> *CELL*: 333 59 49 583 (*lun - ven 9.00 - 18.00*)
>>> *WEB*: www.massimilianomoraca.it
>>> * Attività svolta ai sensi della Legge 4 del 14 gennaio 2013, art.1*
>>> ___
>>> Gfoss@lists.gfoss.it
>>> http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
>>> Questa e' una lista di discussione pubblica aperta a tutti.
>>> I messaggi di questa lista non hanno relazione diretta con le posizioni
>>> dell'Associazione GFOSS.it.
>>> 764 iscritti al 23/08/2019
>>
>>
___
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni 
dell'Associazione GFOSS.it.
764 iscritti al 23/08/2019

Re: [Gfoss] Cambiare SR a tutti i vettori di un progetto QGIS provenienti da PostGIS

2019-11-10 Per discussione Massimiliano Moraca
Amedeo grazie per la risposta. Scusa il ritardo nel risponderti ma sono
stato impegnato.
Il tuo metodo sembra funzionare, dico sembra perchè l'ho usato su un
progetto di test ed effettivamente aggiungendo una nuova colonna geometrica
e modificando il .qgs ho ottenuto ciò che volevo.
Devo applicare questo metodo ai miei progetti che ho e che sono connessi
allo stesso db e teoricamente non dovrei avere nemmeno problemi con i
layout di stampa contenuti nei singoli progetti.

*ing.Massimiliano Moraca*
*Analisi, progettazione e sviluppo di soluzioni GIS e WebGIS*
*P.IVA*: 08700081212
*CELL*: 333 59 49 583 (*lun - ven 9.00 - 18.00*)
*WEB*: www.massimilianomoraca.it
* Attività svolta ai sensi della Legge 4 del 14 gennaio 2013, art.1*


Il giorno mar 5 nov 2019 alle ore 08:00 Amedeo Fadini  ha
scritto:

> Ciao Massimiliano,
> uno dei vantaggi di lavorare con Postgis è che per cascuna tabella puoi
> avere più colonne geometriche, quindi a rigore non devi cambiare SR alla
> *Tabella* ma alla *colonna* e alle singole geometrie.
> Così  a occhio se non ti trovi nella mia situazione (dove 5 Mln di
> geometrie generano problemi di spazio) ti suggerirei di *aggiungere* una
> nuova colonna con nuovo SR
>
> A questo punto nei progetti QGIS puo semplicemente cambiare la data source
> (mi pare che nelle versioni attuali si possa fare per tutti i layer
> selezionati) impostando la nuova colonna.
>
> Ad ogni modo dovrebbe essere possibile decomprimere il qgz in qgs e a quel
> punto puoi modificare l'XML
>
> Nel file qgs per i layer postgis trovi una riga simile a questa
>
> dbname='pdm_governance' host=localhost port=5432
> sslmode=disable key='id' srid=3035 type=MultiPolygon
> checkPrimaryKeyUnicity='0' table="public"."Governance1 Abruzzo_dB" (geom)
> sql=
>
> prova a modificare il codice delle srid e il nome della colonna geometrica
> tra parentesi
>
> Amedeo
>
>
>
>
> Il giorno lun 4 nov 2019 alle ore 18:30 Massimiliano Moraca <
> i...@massimilianomoraca.it> ha scritto:
>
>> Salve a tutti,
>> ho la necessità di riproiettare in EPSG 2154 tutte le tabelle di un DB in
>> PostGIS. Per farlo seguirei questa procedura[1] che tra l'altro mi pare di
>> aver già usato nel recente passato.
>>
>> Il punto è che ho tre progetti QGIS 3.4 collegati a questo database, con
>> un
>> centinaio di layout di stampa, ed effettuando la riproiezione ho
>> verificato
>> che l'SRID dei vettori in legenda non viene aggiornato.
>>
>> L'aggiornamento l'avevo già eseguito mesi fa, non ricordo quando,
>> riscontrando lo stesso problema ma poi ho messo da parte il tutto finchè
>> non mi è servito di nuovo(oggi).
>>
>> La mia domanda è: c'è un modo per modificare il .qgz in moda da sostituire
>> il vecchio sistema di riferimento dei singoli vettori del progetto con il
>> nuovo?
>>
>> Cambiare semplicemente l'SR al progetto e salvare il tutto non funziona.
>>
>> 
>> [1] https://postgis.net/2013/08/30/tip_ST_Set_or_Transform/
>>
>> *ing.Massimiliano Moraca*
>> *Analisi, progettazione e sviluppo di soluzioni GIS e WebGIS*
>> *P.IVA*: 08700081212
>> *CELL*: 333 59 49 583 (*lun - ven 9.00 - 18.00*)
>> *WEB*: www.massimilianomoraca.it
>> * Attività svolta ai sensi della Legge 4 del 14 gennaio 2013, art.1*
>> ___
>> Gfoss@lists.gfoss.it
>> http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
>> Questa e' una lista di discussione pubblica aperta a tutti.
>> I messaggi di questa lista non hanno relazione diretta con le posizioni
>> dell'Associazione GFOSS.it.
>> 764 iscritti al 23/08/2019
>
>
___
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni 
dell'Associazione GFOSS.it.
764 iscritti al 23/08/2019

[Gfoss] Cambiare SR a tutti i vettori di un progetto QGIS provenienti da PostGIS

2019-11-04 Per discussione Massimiliano Moraca
Salve a tutti,
ho la necessità di riproiettare in EPSG 2154 tutte le tabelle di un DB in
PostGIS. Per farlo seguirei questa procedura[1] che tra l'altro mi pare di
aver già usato nel recente passato.

Il punto è che ho tre progetti QGIS 3.4 collegati a questo database, con un
centinaio di layout di stampa, ed effettuando la riproiezione ho verificato
che l'SRID dei vettori in legenda non viene aggiornato.

L'aggiornamento l'avevo già eseguito mesi fa, non ricordo quando,
riscontrando lo stesso problema ma poi ho messo da parte il tutto finchè
non mi è servito di nuovo(oggi).

La mia domanda è: c'è un modo per modificare il .qgz in moda da sostituire
il vecchio sistema di riferimento dei singoli vettori del progetto con il
nuovo?

Cambiare semplicemente l'SR al progetto e salvare il tutto non funziona.


[1] https://postgis.net/2013/08/30/tip_ST_Set_or_Transform/

*ing.Massimiliano Moraca*
*Analisi, progettazione e sviluppo di soluzioni GIS e WebGIS*
*P.IVA*: 08700081212
*CELL*: 333 59 49 583 (*lun - ven 9.00 - 18.00*)
*WEB*: www.massimilianomoraca.it
* Attività svolta ai sensi della Legge 4 del 14 gennaio 2013, art.1*
___
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni 
dell'Associazione GFOSS.it.
764 iscritti al 23/08/2019

[Gfoss] Buffer con Turf renderizzato in MapBox

2019-10-31 Per discussione Massimiliano Moraca
Salve a tutti, mi trovo di fronte a questo problema/dilemma e non so come
comportarmi. Voglio generare un buffer a distanza prestabilita intorno ad
alcuni punti usando le librerie di spatial analysis Turf.js[1] e
renderizzare il tutto con MapBox.
Leggendo la documentazione ufficiale di Turf e di MapBox(che usa comunque
Turf per lo spatial analysis) mi sono trovato di fronte a tre diverse
versioni di questa semplice procedura ma solo una di esse funziona:

map.on('load', function() {

/// Esempio dal sito Turf.js | https://turfjs.org/docs/#buffer
console.log('- Usando l\'
esempio preso dal sito Turf.js voglio leggere il punto, generare un
buffer e renderizzare entrambi
\n\n')
/ START
var point = turf.point([-90.548630, 14.616599]);
console.log('Ho letto le coordinate del punto')

var buffered = turf.buffer(point, 500, {units: 'miles'});
console.log('Con le coordinate del punto ho generato il buffer')
/ FINE



/// Esempio 1 dal sito MapBox |
https://docs.mapbox.com/help/how-mapbox-works/geospatial-analysis/
console.log('- Usando l\'
esempio1 preso dal sito MapBox voglio leggere il punto, generare un
buffer e renderizzare entrambi
\n\n')
/ START
var point = {
  type: 'Feature',
  geometry: {
type: 'Point',
coordinates: [0, 0]
  },
  properties: {
name: 'Null Island'
  }
};
console.log('Ho letto le coordinate del punto')

var buffered = turf.buffer(point, 200, { unit: 'miles' });
console.log('Con le coordinate del punto ho generato il buffer')
/ FINE




/// Esempio 2 dal sito MapBox creato visualizzando il codice sorgente
della mappa |
https://docs.mapbox.com/help/demos/turf-intro/nullisland.html
console.log('- Usando l\'
esempio2 preso dal sito MapBox voglio leggere il punto, generare un
buffer e renderizzare entrambi
\n\n')
/ START
var point = {
  'type': 'Feature',
  'geometry': {
'type': 'Point',
'coordinates': [0, 0]
  },
  'properties': {
'name': 'Null Island'
  }
};
console.log('Ho letto le coordinate del punto')

var buffered = turf.buffer(point, 200, 'miles');
console.log('Con le coordinate del punto ho generato il buffer')
/ FINE



// Aggiunta dell'url del vettore sorgente
map.addSource('point_source', {
  type: 'geojson',
  data: point,
});
console.log('Ho associato al punto la geometria')

// Renderizzazione del vettore sorgente
map.addLayer({
'id': 'tower',
'type': 'circle',
'source': 'point_source',
  paint: {
'circle-color': '#f30',
'circle-radius': 3,
'circle-stroke-width': 1,
'circle-stroke-color': '#fff'
  }
});
console.log('Ed infine l\'ho renderizzato\n\n')

// Renderizzazione del buffer
map.addLayer({
  'id': 'buffer',
  'type': 'fill',
  'source': {
  'type': 'geojson',
  'data': buffered
  },
  'layout': {
  // 'line-join': 'round',
  // 'line-cap': 'round'
  },
  'paint': {
  'fill-color': '#fff',
  'fill-opacity': 0.50,
  'fill-outline-color': '#f30'
  }
  });
  console.log('Ora ho renderizzato il buffer\n\n\n\n')

console.log('Stai vedendo il progetto completamente renderizzato con l\'
aggiunta dei vettori che hai richiesto')
  });


Se volete fare un test commentate due esempi per volta. Sia che si usa
"*Esempio
dal sito Turf.j"* che "*Esempio 1 dal sito MapBox",* si avrà lo stesso
errore in console:

> Uncaught Error: Invalid unit
> at Object.e.exports.distanceToDegrees (turf.min.js:16)
> at Object.e.exports [as buffer] (turf.min.js:1)
> at r. ((index):53)
> at r.St.fire (evented.js:115)
> at r._render (map.js:1976)
> at map.js:2047

Mentre se si usa l'ultimo esempio il buffer viene renderizzato
correttamente e tutto va come deve andare. Per renderizzare la mappa di
sfondo su cui andare ad inserire il tutto ho usato le indicazioni base di
MapBox[2]  e sia MapBox che Turf sono in CDN ed il tutto gira in Django.
Non utilizzo Node.js per il progetto su cui sto lavorando, non so usarlo e
non mi pare sia un obbligo nè per Turf nè per MapBox.

Il mio problema/dilemma sta in questo: è sbagliato il codice di esempio sul
sito delle librerie(può mai essere?) o sono io che sbaglio qualcosa?


[1] https://turfjs.org/
[2] https://docs.mapbox.com/mapbox-gl-js/overview/#quickstart

*ing.Massimiliano Moraca*
*Analisi, progettazione e sviluppo di soluzioni GIS e WebGIS*
*P.IVA*: 08700081212
*CELL*: 333 59 49 583 (*lun - ven 9.00 - 18.00*)
*WEB*: www.massimilianomoraca.it
* Attività svolta ai sensi della Legge 4 del 14 gennaio 2013, art.1*
___
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' 

Re: [Gfoss] Librerie/Framework per renderizzazione e spatial analysis

2019-10-28 Per discussione Massimiliano Moraca
Grazie :)

Il giorno lun 28 ott 2019 alle ore 14:02 Luca Delucchi 
ha scritto:

> > In questa ricerca mi sono imbattuto nelle librerie Turf[1] che sembrano
> > ottime per lo spatial analysis ma non mi è chiaro se sono o meno ad
> > appannaggio del solo MapBox. Avete esperienze in merito?
>
> no è un libreria javascript che è possibile utilizzare essendo
> rilasciata con licenza MIT
>
> --
> ciao
> Luca
>
> www.lucadelu.org
> ___
> Gfoss@lists.gfoss.it
> http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
> Questa e' una lista di discussione pubblica aperta a tutti.
> I messaggi di questa lista non hanno relazione diretta con le posizioni
> dell'Associazione GFOSS.it.
> 764 iscritti al 23/08/2019
___
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni 
dell'Associazione GFOSS.it.
764 iscritti al 23/08/2019

Re: [Gfoss] Aggiunere la geolocalizzazione dell'utente in un form di GeoDjango

2019-10-01 Per discussione Massimiliano Moraca
L'errore è sparito ma adesso dopo la geolocalizzazione dell'utente il form
viene automaticamente inviato vuoto.
Se qualcuno sa darmi una spiegazione qui[1] c'è la domanda aggiornata su
Stack
-
[1]
https://stackoverflow.com/questions/58063527/the-form-is-sent-automatically-after-the-geolocation

Il giorno mar 1 ott 2019 alle ore 12:11 Massimiliano Moraca <
massimilianomor...@gmail.com> ha scritto:

> Purtroppo ancora non sono riuscito a risolvere questo errore
>
> -
> Ingegnere, consulente GIS e ciclista urbano
> --
> Sent from:
> http://gfoss-geographic-free-and-open-source-software-italian-mailing.3056002.n2.nabble.com/
> ___
> Gfoss@lists.gfoss.it
> http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
> Questa e' una lista di discussione pubblica aperta a tutti.
> I messaggi di questa lista non hanno relazione diretta con le posizioni
> dell'Associazione GFOSS.it.
> 764 iscritti al 23/08/2019
___
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni 
dell'Associazione GFOSS.it.
764 iscritti al 23/08/2019

Re: [Gfoss] Aggiunere la geolocalizzazione dell'utente in un form di GeoDjango

2019-10-01 Per discussione Massimiliano Moraca
Purtroppo ancora non sono riuscito a risolvere questo errore

-
Ingegnere, consulente GIS e ciclista urbano
--
Sent from: 
http://gfoss-geographic-free-and-open-source-software-italian-mailing.3056002.n2.nabble.com/
___
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni 
dell'Associazione GFOSS.it.
764 iscritti al 23/08/2019

Re: [Gfoss] Mappatura discariche illegali

2019-10-01 Per discussione Massimiliano Moraca
Il progetto è stato messo online poco fa, è in fase di rodaggio,
segnalatemi bug e problemi di qualunque tipo.
Grazie

Scusate il doppio post...

Il giorno mar 1 ott 2019 alle ore 10:16 Massimiliano Moraca <
massimilianomor...@gmail.com> ha scritto:

> Buongiorno a tutti,
> ho avviato un mio progetto di mappatura delle discariche illegali, mi
> farebbe piacere se un contributo alla mappatura venisse anche da questa
> community. A questo indirizzo trovate il link[1]
>
> Il progetto sposa la filosofia del crowdmapping ed i contenuti mappati è
> possibile trovarli a questo link[2], è un geojson. Mi rendo contro che non
> è semplicissimo il riuso in questo modo ma con il tempo ho intenzione di
> creare delle API per consentire una semplice condivisione e riutilizzo del
> dato.
>
> Si accettano consigli e critiche costruttive.
> 
> [1] https://gealogos.com/geomonitor/illegal-dump-map/
> [2] https://gealogos.com/geojson/illegal-dump/
>
___
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni 
dell'Associazione GFOSS.it.
764 iscritti al 23/08/2019

[Gfoss] Mappatura discariche illegali

2019-10-01 Per discussione Massimiliano Moraca
Buongiorno a tutti,
ho avviato un mio progetto di mappatura delle discariche illegali, mi
farebbe piacere se un contributo alla mappatura venisse anche da questa
community. A questo indirizzo trovate il link[1]

Il progetto sposa la filosofia del crowdmapping ed i contenuti mappati è
possibile trovarli a questo link[2], è un geojson. Mi rendo contro che non
è semplicissimo il riuso in questo modo ma con il tempo ho intenzione di
creare delle API per consentire una semplice condivisione e riutilizzo del
dato.

Si accettano consigli e critiche costruttive.

[1] https://gealogos.com/geomonitor/illegal-dump-map/
[2] https://gealogos.com/geojson/illegal-dump/
___
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni 
dell'Associazione GFOSS.it.
764 iscritti al 23/08/2019

Re: [Gfoss] Aggiunere la geolocalizzazione dell'utente in un form di GeoDjango

2019-09-24 Per discussione Massimiliano Moraca
Usando la console l'errore fa riferimento a questa riga che sta subito
sotto var = geolocation:
>
> projection: map.getView().getProjection(),


Il giorno mar 24 set 2019 alle ore 11:01 Massimiliano Moraca <
massimilianomor...@gmail.com> ha scritto:

> Ciao Amedeo, grazie per la risposta.
> Quel punto interrogativo c'è anche nel codice della mappa che mi funziona,
> il codice proviene da lì, la uso come muletto per i test.
>
> Il giorno mar 24 set 2019 alle ore 10:43 Amedeo Fadini 
> ha scritto:
>
>> Ciao in questa riga
>>
>> positionFeature.setGeometry(pos ?
>>
>> è capitato un punto di domanda alieno, verifica che non ci sia anche nel
>> codice effettivo.
>>
>> Il codice javascript lo dovresti mettere nel template in maniera che esca
>> una pagine html valida, per quanto ne so in javascript è sempre questione
>> di tempi, dovrsti fare in modo che quando creai il nuovo vettore l'oggetto
>> mappa sia già creato.
>>
>> Ad ogni modo da console dovresti trovare degli errori che ti guidano
>> sulla strada giusta
>>
>> Amefad
>>
>> Il giorno mar 24 set 2019 alle ore 08:39 Massimiliano Moraca <
>> massimilianomor...@gmail.com> ha scritto:
>>
>>> Buongiorno a tutti,
>>> sto provando a fare quanto in oggetto ma ho difficoltà a capire dove
>>> inserire lo script per farlo. Lo script che voglio usare è già
>>> correttamente in uso su altre mie mappe ma sono mappe che non prevedono
>>> l'aggiunta di oggetti da parte dell'utente.
>>> Qui[1] ho inserito quello che ho fatto; in pratica ho creato un mio
>>> widget
>>> sulla base di OpenLayersWidget modificando sia il template che il
>>> JavaScript. Il widget customizzato funziona. Successivamente ho deciso di
>>> inserire sia lo script per il geocoder che quello per la
>>> geolocalizzazione
>>> dell'utente in modo da facilitarlo nell'aggiunta dell'oggetto. Il
>>> geocoder
>>> funziona ma quello che non riesco a far funzionare è la geolocalizzazione
>>> dell'utente.
>>> In pratica non riesco a capire dove inserire il codice per far funzionare
>>> correttamente la gelocalizzazione. A livello di JavaScript non è che sia
>>> così ferrato...
>>>
>>> Per le altre mappe ho creato un bottone che compare su mappa; l'utente ci
>>> clicca su e viene geolocalizzato:
>>>
>>> > 
>>> >   
>>> > 
>>> >   
>>> > 
>>>
>>>
>>> il tutto avviene usando questo script:
>>>
>>> > var geolocation = new ol.Geolocation({
>>> >   projection: map.getView().getProjection(),
>>> >   tracking: false,
>>> >   trackingOptions: {
>>> > enableHighAccuracy: true,
>>> > maximumAge: 5000
>>> >   }
>>> > });
>>> >   var button = document.getElementById('geolocateme');
>>> >   var handleGetPosition = function(e) {
>>> >   var trackingwasalreadyon = geolocation.getTracking();
>>> >   if(trackingwasalreadyon){
>>> >   geolocation.setTracking(false);
>>> >   } else
>>> >   { geolocation.setTracking(true); getPosition();
>>> >   }
>>> >   };
>>> >   button.addEventListener('click', handleGetPosition, false);
>>> >   button.addEventListener('touchstart', handleGetPosition,
>>> false);
>>> > function getPosition() {
>>> > var positionFeature = new ol.Feature();
>>> > positionFeature.setStyle(new ol.style.Style({
>>> >   image: new ol.style.Circle({
>>> > radius: 6,
>>> > fill: new ol.style.Fill({
>>> >   color: '#fa'
>>> > }),
>>> > stroke: new ol.style.Stroke({
>>> >   color: '#fff',
>>> >   width: 2
>>> > }),
>>> >   }),
>>> > }));
>>> > geolocation.on('change:position', function() {
>>> >   var pos = geolocation.getPosition();
>>> >   positionFeature.setGeometry(pos ?
>>> >   new ol.geom.Point(pos) : null);
>>> >   view.setCenter

Re: [Gfoss] Aggiunere la geolocalizzazione dell'utente in un form di GeoDjango

2019-09-24 Per discussione Massimiliano Moraca
Ciao Amedeo, grazie per la risposta.
Quel punto interrogativo c'è anche nel codice della mappa che mi funziona,
il codice proviene da lì, la uso come muletto per i test.

Il giorno mar 24 set 2019 alle ore 10:43 Amedeo Fadini 
ha scritto:

> Ciao in questa riga
>
> positionFeature.setGeometry(pos ?
>
> è capitato un punto di domanda alieno, verifica che non ci sia anche nel
> codice effettivo.
>
> Il codice javascript lo dovresti mettere nel template in maniera che esca
> una pagine html valida, per quanto ne so in javascript è sempre questione
> di tempi, dovrsti fare in modo che quando creai il nuovo vettore l'oggetto
> mappa sia già creato.
>
> Ad ogni modo da console dovresti trovare degli errori che ti guidano sulla
> strada giusta
>
> Amefad
>
> Il giorno mar 24 set 2019 alle ore 08:39 Massimiliano Moraca <
> massimilianomor...@gmail.com> ha scritto:
>
>> Buongiorno a tutti,
>> sto provando a fare quanto in oggetto ma ho difficoltà a capire dove
>> inserire lo script per farlo. Lo script che voglio usare è già
>> correttamente in uso su altre mie mappe ma sono mappe che non prevedono
>> l'aggiunta di oggetti da parte dell'utente.
>> Qui[1] ho inserito quello che ho fatto; in pratica ho creato un mio widget
>> sulla base di OpenLayersWidget modificando sia il template che il
>> JavaScript. Il widget customizzato funziona. Successivamente ho deciso di
>> inserire sia lo script per il geocoder che quello per la geolocalizzazione
>> dell'utente in modo da facilitarlo nell'aggiunta dell'oggetto. Il geocoder
>> funziona ma quello che non riesco a far funzionare è la geolocalizzazione
>> dell'utente.
>> In pratica non riesco a capire dove inserire il codice per far funzionare
>> correttamente la gelocalizzazione. A livello di JavaScript non è che sia
>> così ferrato...
>>
>> Per le altre mappe ho creato un bottone che compare su mappa; l'utente ci
>> clicca su e viene geolocalizzato:
>>
>> > 
>> >   
>> > 
>> >   
>> > 
>>
>>
>> il tutto avviene usando questo script:
>>
>> > var geolocation = new ol.Geolocation({
>> >   projection: map.getView().getProjection(),
>> >   tracking: false,
>> >   trackingOptions: {
>> > enableHighAccuracy: true,
>> > maximumAge: 5000
>> >   }
>> > });
>> >   var button = document.getElementById('geolocateme');
>> >   var handleGetPosition = function(e) {
>> >   var trackingwasalreadyon = geolocation.getTracking();
>> >   if(trackingwasalreadyon){
>> >   geolocation.setTracking(false);
>> >   } else
>> >   { geolocation.setTracking(true); getPosition();
>> >   }
>> >   };
>> >   button.addEventListener('click', handleGetPosition, false);
>> >   button.addEventListener('touchstart', handleGetPosition,
>> false);
>> > function getPosition() {
>> > var positionFeature = new ol.Feature();
>> > positionFeature.setStyle(new ol.style.Style({
>> >   image: new ol.style.Circle({
>> > radius: 6,
>> > fill: new ol.style.Fill({
>> >   color: '#fa'
>> > }),
>> > stroke: new ol.style.Stroke({
>> >   color: '#fff',
>> >   width: 2
>> > }),
>> >   }),
>> > }));
>> > geolocation.on('change:position', function() {
>> >   var pos = geolocation.getPosition();
>> >   positionFeature.setGeometry(pos ?
>> >   new ol.geom.Point(pos) : null);
>> >   view.setCenter(pos);
>> >   view.setZoom(12);
>> > });
>> > new ol.layer.Vector({
>> >   map: map,
>> >   source: new ol.source.Vector({
>> > features: [
>> >   positionFeature,
>> > ]
>> >   })
>> > });
>> > };
>>
>>
>> E questo è quello che sto provando ad implementare nel form. Qualcuno qui
>> ha esperienza in questo?
>>
>>
>>
>> -
>> [1]
>>
>> https://stackoverflow.com/questions/58063527/how-to-add-geolocation-to-a-geodjango-form
>> ___
>> Gfoss@lists.gfoss.it
>> http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
>> Questa e' una lista di discussione pubblica aperta a tutti.
>> I messaggi di questa lista non hanno relazione diretta con le posizioni
>> dell'Associazione GFOSS.it.
>> 764 iscritti al 23/08/2019
>
>
___
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni 
dell'Associazione GFOSS.it.
764 iscritti al 23/08/2019

[Gfoss] Aggiunere la geolocalizzazione dell'utente in un form di GeoDjango

2019-09-24 Per discussione Massimiliano Moraca
Buongiorno a tutti,
sto provando a fare quanto in oggetto ma ho difficoltà a capire dove
inserire lo script per farlo. Lo script che voglio usare è già
correttamente in uso su altre mie mappe ma sono mappe che non prevedono
l'aggiunta di oggetti da parte dell'utente.
Qui[1] ho inserito quello che ho fatto; in pratica ho creato un mio widget
sulla base di OpenLayersWidget modificando sia il template che il
JavaScript. Il widget customizzato funziona. Successivamente ho deciso di
inserire sia lo script per il geocoder che quello per la geolocalizzazione
dell'utente in modo da facilitarlo nell'aggiunta dell'oggetto. Il geocoder
funziona ma quello che non riesco a far funzionare è la geolocalizzazione
dell'utente.
In pratica non riesco a capire dove inserire il codice per far funzionare
correttamente la gelocalizzazione. A livello di JavaScript non è che sia
così ferrato...

Per le altre mappe ho creato un bottone che compare su mappa; l'utente ci
clicca su e viene geolocalizzato:

> 
>   
> 
>   
> 


il tutto avviene usando questo script:

> var geolocation = new ol.Geolocation({
>   projection: map.getView().getProjection(),
>   tracking: false,
>   trackingOptions: {
> enableHighAccuracy: true,
> maximumAge: 5000
>   }
> });
>   var button = document.getElementById('geolocateme');
>   var handleGetPosition = function(e) {
>   var trackingwasalreadyon = geolocation.getTracking();
>   if(trackingwasalreadyon){
>   geolocation.setTracking(false);
>   } else
>   { geolocation.setTracking(true); getPosition();
>   }
>   };
>   button.addEventListener('click', handleGetPosition, false);
>   button.addEventListener('touchstart', handleGetPosition, false);
> function getPosition() {
> var positionFeature = new ol.Feature();
> positionFeature.setStyle(new ol.style.Style({
>   image: new ol.style.Circle({
> radius: 6,
> fill: new ol.style.Fill({
>   color: '#fa'
> }),
> stroke: new ol.style.Stroke({
>   color: '#fff',
>   width: 2
> }),
>   }),
> }));
> geolocation.on('change:position', function() {
>   var pos = geolocation.getPosition();
>   positionFeature.setGeometry(pos ?
>   new ol.geom.Point(pos) : null);
>   view.setCenter(pos);
>   view.setZoom(12);
> });
> new ol.layer.Vector({
>   map: map,
>   source: new ol.source.Vector({
> features: [
>   positionFeature,
> ]
>   })
> });
> };


E questo è quello che sto provando ad implementare nel form. Qualcuno qui
ha esperienza in questo?



-
[1]
https://stackoverflow.com/questions/58063527/how-to-add-geolocation-to-a-geodjango-form
___
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni 
dell'Associazione GFOSS.it.
764 iscritti al 23/08/2019

Re: [Gfoss] Geoportale nazionale la sospensione dei servizi WMS prelude alla chiusura?

2019-08-28 Per discussione Massimiliano Moraca
Mi sa proprio che stanno migrando a tecnologia proprietaria. Se fosse così
non so quanto avrebbe senso inviare una mail di sollecito. Certo è che al
Ministero potrebbero farci sapere come dobbiamo muoverci. Il layer delle
scuole è da metà Luglio che non riesco a scaricarlo ed ora lo "vedo" qui


Il giorno mer 28 ago 2019 alle ore 17:45 Amedeo Fadini 
ha scritto:

> Ciao  a tutti, come ha fatto notare in vari canali Andrea Borruso i servizi
> WMS del geoportale nazionale sono chiusi tutto ad un tratto senza un avviso
>
> Andando a ravanare tra le chiamate del visualizzatore si scopre che il
> server storico con i servizi WMS, probabilmente basato su software Open UMN
> Mapserver che rispndeva all'host
> http://wms.pcn.minambiente.it/
>  non è più raggiungibile (se era la stessa macchina del 2009 avrebbe anche
> ragione...)
> Invece i tile delle ortofoto vengono caricati da un server ArcCoso
> http://www.pcn.minambiente.it/arcgis/rest/services/
>
> Non so se chi lavora nelle regioni ha già avuto conttti con la direzione
> territorio /difesa del suolo che dovrebeb mantenere i geoportali del
> ministero, ma siccome ho visto accadere più volte che servizi di questo
> tipo vengono privati di risorse perché si ritiene che "non interessino a
> nessuno" penso sia importante come utenti sollecitare il ripristino dei
> servizi scrivendo più volte all'ìindirizzo di contatto
> p...@minambiente.it
>
> Che ne pensate?
>
> Amefad
> ___
> Gfoss@lists.gfoss.it
> http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
> Questa e' una lista di discussione pubblica aperta a tutti.
> I messaggi di questa lista non hanno relazione diretta con le posizioni
> dell'Associazione GFOSS.it.
> 764 iscritti al 23/08/2019
___
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni 
dell'Associazione GFOSS.it.
764 iscritti al 23/08/2019

Re: [Gfoss] Form di immissione dati per GeoDjango restituisce un errore di integrità

2019-07-26 Per discussione Massimiliano Moraca
Si, lo so, ma l'ho cancellato solo perchè il mio era un errore ridicolo.
Provvedo comunque a riattivare la domanda

Il giorno ven 26 lug 2019 alle ore 11:10  ha
scritto:

> Solo un consiglio:
> nel sito gis.stackexchange solitamente è buona prassi non cancellare una
> domanda quando si è trovata la soluzione, ma lasciarla o eventualmente
> inserire la risposta a se stessi e accettarla.
> In questo modo in futuro, tu o altri con lo stesso dubbio potranno avere
> chance di trovare la soluzione.
>
> -Messaggio originale-
> Da: Gfoss  Per conto di Massimiliano Moraca
> Inviato: venerdì 26 luglio 2019 10:56
> A: pierluigi de rosa 
> Cc: GFOSS.it 
> Oggetto: Re: [Gfoss] Form di immissione dati per GeoDjango restituisce un
> errore di integrità
>
> Ho trovato l'errore!
> Me lo hai fatto notare tu indirettamente.
> Ho chiamanto point il field del form che nel modello ho chiamato geom. In
> realtà anche nel modello si chiamava point fino a qualche giorno fa ma per
> avere in PostGIS un nome di campo più familiare per me(geom) l'ho
> rinominato geom e nel frattempo ho fatto altre modifiche al codice.
> Sistemato questo errore posso aggiungere i punti usando il form che ho
> sviluppato. Ho scritto un form così perchè piano piano voglio
> personalizzarlo ed anche perchè per me è più leggibile. Ho iniziato un anno
> fa a studiare Python e Django partendo da conoscenze quasi zero di
> programmazione e per questo alcune cose banali ancora mi sfuggono, come nel
> caso dell'errore nel form.
>
> Grazie :)
>
> Il giorno ven 26 lug 2019 alle ore 10:45 pierluigi de rosa <
> pierluigi.der...@gmail.com> ha scritto:
>
> > Il form dovrebbe bastare che tu lo faccia del tipo class
> > AddPointForm(forms.ModelForm):
> > class Meta:
> > model = AddPoint
> > fields = ('name', 'geom')
> > widgets = {'geom': OSMWidget(
> > attrs={
> > 'map_width': 800,
> > 'map_height': 250,
> > 'default_lat': 0,
> >     'default_lon': 0,
> > 'default_zoom': 2,
> > }
> > )} Pierluigi
> >
> > Il giorno ven 26 lug 2019 alle ore 10:30 Massimiliano Moraca <
> > massimilianomor...@gmail.com> ha scritto:
> >
> >> Ciao Pierluigi, grazie per l'indicazione. Ho fatto le correzioni che
> >> mi hai indicato(non mi era chiaro che geodjango eredita comunque
> >> modelli e form da django) ma continuo ad avere lo stesso errore:
> >>
> >>> IntegrityError at /map/create/add-points/ null value in column
> >>> "geom" violates not-null constraint
> >>> DETAIL: Failing row contains (4, Punto aggiunto dal form, null).
> >>
> >>
> >> Il giorno ven 26 lug 2019 alle ore 10:09 pierluigi de rosa <
> >> pierluigi.der...@gmail.com> ha scritto:
> >>
> >>> Ho letto velocemente il tuo codice ma riscontro un errore, Io uso
> >>> poco django 2.2 e più spesso 1.11 per questioni personali però nei
> >>> modelli devi importare solo quello da django.contrib.gis e non anche
> >>> django.contrib ovvero il models dovrebbe essere:
> >>>
> >>>  from django.contrib.gis.db import models
> >>>
> >>>
> >>>  class AddPoint(models.Model):
> >>>  name = models.CharField(max_length=100)
> >>>  geom = geomodels.PointField()
> >>>
> >>>  def __str__(self):
> >>>  return self.name
> >>>
> >>> stessa cosa per i form ovvero devi importare:
> >>> from django.contrib.gis import forms e poi devi usare solo forms
> >>>
> >>> il resto del codice non l'ho visto ma questo errore penso sia
> >>> rilevante
> >>>
> >>> Pierluigi De Rosa
> >>>
> >>> Il giorno ven 26 lug 2019 alle ore 08:32 Massimiliano Moraca <
> >>> massimilianomor...@gmail.com> ha scritto:
> >>>
> >>>> Buongiorno a tutti,
> >>>> spero che tra voi ci sia chi può darmi una mano GeoDjango visto che
> >>>> sono oramai diversi giorni che sono arenato sul problema che descrivo
> qui[1].
> >>>>
> >>>> In pratica sto provando a sviluppare una piccola applicazione che
> >>>> consente di posizionare un punto su una mappa dandogli un nome. Da
> >>>> pannello di amministrazione di Django riesco a farlo senza
> >>>> problemi, visualizzando il punto sulla mappa. ma l'ostacolo ce l'

Re: [Gfoss] Form di immissione dati per GeoDjango restituisce un errore di integrità

2019-07-26 Per discussione Massimiliano Moraca
Ho trovato l'errore!
Me lo hai fatto notare tu indirettamente.
Ho chiamanto point il field del form che nel modello ho chiamato geom. In
realtà anche nel modello si chiamava point fino a qualche giorno fa ma per
avere in PostGIS un nome di campo più familiare per me(geom) l'ho
rinominato geom e nel frattempo ho fatto altre modifiche al codice.
Sistemato questo errore posso aggiungere i punti usando il form che ho
sviluppato. Ho scritto un form così perchè piano piano voglio
personalizzarlo ed anche perchè per me è più leggibile. Ho iniziato un anno
fa a studiare Python e Django partendo da conoscenze quasi zero di
programmazione e per questo alcune cose banali ancora mi sfuggono, come nel
caso dell'errore nel form.

Grazie :)

Il giorno ven 26 lug 2019 alle ore 10:45 pierluigi de rosa <
pierluigi.der...@gmail.com> ha scritto:

> Il form dovrebbe bastare che tu lo faccia del tipo
> class AddPointForm(forms.ModelForm):
> class Meta:
> model = AddPoint
> fields = ('name', 'geom')
> widgets = {'geom': OSMWidget(
> attrs={
> 'map_width': 800,
> 'map_height': 250,
> 'default_lat': 0,
> 'default_lon': 0,
> 'default_zoom': 2,
> }
> )} Pierluigi
>
> Il giorno ven 26 lug 2019 alle ore 10:30 Massimiliano Moraca <
> massimilianomor...@gmail.com> ha scritto:
>
>> Ciao Pierluigi, grazie per l'indicazione. Ho fatto le correzioni che mi
>> hai indicato(non mi era chiaro che geodjango eredita comunque modelli e
>> form da django) ma continuo ad avere lo stesso errore:
>>
>>> IntegrityError at /map/create/add-points/
>>> null value in column "geom" violates not-null constraint
>>> DETAIL: Failing row contains (4, Punto aggiunto dal form, null).
>>
>>
>> Il giorno ven 26 lug 2019 alle ore 10:09 pierluigi de rosa <
>> pierluigi.der...@gmail.com> ha scritto:
>>
>>> Ho letto velocemente il tuo codice ma riscontro un errore,
>>> Io uso poco django 2.2 e più spesso 1.11 per questioni personali però
>>> nei modelli devi importare solo quello da django.contrib.gis e non anche
>>> django.contrib ovvero il models dovrebbe essere:
>>>
>>>  from django.contrib.gis.db import models
>>>
>>>
>>>  class AddPoint(models.Model):
>>>  name = models.CharField(max_length=100)
>>>  geom = geomodels.PointField()
>>>
>>>  def __str__(self):
>>>  return self.name
>>>
>>> stessa cosa per i form ovvero devi importare:
>>> from django.contrib.gis import forms
>>> e poi devi usare solo forms
>>>
>>> il resto del codice non l'ho visto ma questo errore penso sia rilevante
>>>
>>> Pierluigi De Rosa
>>>
>>> Il giorno ven 26 lug 2019 alle ore 08:32 Massimiliano Moraca <
>>> massimilianomor...@gmail.com> ha scritto:
>>>
>>>> Buongiorno a tutti,
>>>> spero che tra voi ci sia chi può darmi una mano GeoDjango visto che sono
>>>> oramai diversi giorni che sono arenato sul problema che descrivo qui[1].
>>>>
>>>> In pratica sto provando a sviluppare una piccola applicazione che
>>>> consente
>>>> di posizionare un punto su una mappa dandogli un nome. Da pannello di
>>>> amministrazione di Django riesco a farlo senza problemi, visualizzando
>>>> il
>>>> punto sulla mappa. ma l'ostacolo ce l'ho con il form che ho sviluppato e
>>>> che andrà a sostituire l'immissione da pannello di amministrazione di
>>>> default.
>>>>
>>>> Ogni qualvolta uso il form infatti, una volta posizionato il punto sulla
>>>> mappa, se do l'ok alla pubblicazione ho un errore di integrità. In
>>>> pratica
>>>> dei due dati che passo al form (nome del punto e coordinate) le
>>>> coordinate
>>>> sono NULL; questo dato non viene passato e quindi viene fuori l'errore
>>>> perchè nella tabelle PostGIS associata non è previsto il valore NULL
>>>> per le
>>>> geometrie(giustamente).
>>>>
>>>> *models.py*
>>>>
>>>> > from django.contrib.gis.db import models as geomodels
>>>> > from django.db import models
>>>> >
>>>> > class AddPoint(models.Model):
>>>> > name = models.CharField(max_length=100)
>>>> > geom = geomodels.PointField()
>>>> >
>>>> > def __str__(self):
>>&g

Re: [Gfoss] Form di immissione dati per GeoDjango restituisce un errore di integrità

2019-07-26 Per discussione Massimiliano Moraca
Ciao Pierluigi, grazie per l'indicazione. Ho fatto le correzioni che mi hai
indicato(non mi era chiaro che geodjango eredita comunque modelli e form da
django) ma continuo ad avere lo stesso errore:

> IntegrityError at /map/create/add-points/
> null value in column "geom" violates not-null constraint
> DETAIL: Failing row contains (4, Punto aggiunto dal form, null).


Il giorno ven 26 lug 2019 alle ore 10:09 pierluigi de rosa <
pierluigi.der...@gmail.com> ha scritto:

> Ho letto velocemente il tuo codice ma riscontro un errore,
> Io uso poco django 2.2 e più spesso 1.11 per questioni personali però nei
> modelli devi importare solo quello da django.contrib.gis e non anche
> django.contrib ovvero il models dovrebbe essere:
>
>  from django.contrib.gis.db import models
>
>
>  class AddPoint(models.Model):
>  name = models.CharField(max_length=100)
>  geom = geomodels.PointField()
>
>  def __str__(self):
>  return self.name
>
> stessa cosa per i form ovvero devi importare:
> from django.contrib.gis import forms
> e poi devi usare solo forms
>
> il resto del codice non l'ho visto ma questo errore penso sia rilevante
>
> Pierluigi De Rosa
>
> Il giorno ven 26 lug 2019 alle ore 08:32 Massimiliano Moraca <
> massimilianomor...@gmail.com> ha scritto:
>
>> Buongiorno a tutti,
>> spero che tra voi ci sia chi può darmi una mano GeoDjango visto che sono
>> oramai diversi giorni che sono arenato sul problema che descrivo qui[1].
>>
>> In pratica sto provando a sviluppare una piccola applicazione che consente
>> di posizionare un punto su una mappa dandogli un nome. Da pannello di
>> amministrazione di Django riesco a farlo senza problemi, visualizzando il
>> punto sulla mappa. ma l'ostacolo ce l'ho con il form che ho sviluppato e
>> che andrà a sostituire l'immissione da pannello di amministrazione di
>> default.
>>
>> Ogni qualvolta uso il form infatti, una volta posizionato il punto sulla
>> mappa, se do l'ok alla pubblicazione ho un errore di integrità. In pratica
>> dei due dati che passo al form (nome del punto e coordinate) le coordinate
>> sono NULL; questo dato non viene passato e quindi viene fuori l'errore
>> perchè nella tabelle PostGIS associata non è previsto il valore NULL per
>> le
>> geometrie(giustamente).
>>
>> *models.py*
>>
>> > from django.contrib.gis.db import models as geomodels
>> > from django.db import models
>> >
>> > class AddPoint(models.Model):
>> > name = models.CharField(max_length=100)
>> > geom = geomodels.PointField()
>> >
>> > def __str__(self):
>> > return self.name
>>
>>
>> *forms.py*
>>
>> > from django import forms
>> > from django.contrib.gis import forms
>> >
>> > from .models import AddPoint
>> >
>> > class AddPointForm(forms.ModelForm):
>> > name = forms.CharField(
>> > max_length=100,
>> > widget=forms.TextInput(
>> > attrs={
>> > "type": "text",
>> > "class": "form-control form-control-lg",
>> > }
>> > ),
>> > )
>> > point = forms.PointField(
>> > widget=forms.OSMWidget(
>> > attrs={
>> > 'map_width': 800,
>> > 'map_height': 250,
>> > 'default_lat': 0,
>> > 'default_lon': 0,
>> > 'default_zoom': 2,
>> > }
>> > ),
>> > )
>> >
>> > class Meta:
>> > model = AddPoint
>> > fields = [
>> > 'name',
>> > 'point',
>> > ]
>>
>>
>> *views.py*
>>
>> > def addPointOnMap(request):
>> > if request.method == "POST":
>> > geoform = AddPointForm(request.POST or None)
>> > if geoform.is_valid():
>> > new_point = geoform.save()
>> > return redirect('add_points_map')
>> > else:
>> > geoform = AddPointForm()
>> > context = {
>> > 'geoform': geoform,
>> > }
>> > templa

[Gfoss] Form di immissione dati per GeoDjango restituisce un errore di integrità

2019-07-26 Per discussione Massimiliano Moraca
Buongiorno a tutti,
spero che tra voi ci sia chi può darmi una mano GeoDjango visto che sono
oramai diversi giorni che sono arenato sul problema che descrivo qui[1].

In pratica sto provando a sviluppare una piccola applicazione che consente
di posizionare un punto su una mappa dandogli un nome. Da pannello di
amministrazione di Django riesco a farlo senza problemi, visualizzando il
punto sulla mappa. ma l'ostacolo ce l'ho con il form che ho sviluppato e
che andrà a sostituire l'immissione da pannello di amministrazione di
default.

Ogni qualvolta uso il form infatti, una volta posizionato il punto sulla
mappa, se do l'ok alla pubblicazione ho un errore di integrità. In pratica
dei due dati che passo al form (nome del punto e coordinate) le coordinate
sono NULL; questo dato non viene passato e quindi viene fuori l'errore
perchè nella tabelle PostGIS associata non è previsto il valore NULL per le
geometrie(giustamente).

*models.py*

> from django.contrib.gis.db import models as geomodels
> from django.db import models
>
> class AddPoint(models.Model):
> name = models.CharField(max_length=100)
> geom = geomodels.PointField()
>
> def __str__(self):
> return self.name


*forms.py*

> from django import forms
> from django.contrib.gis import forms
>
> from .models import AddPoint
>
> class AddPointForm(forms.ModelForm):
> name = forms.CharField(
> max_length=100,
> widget=forms.TextInput(
> attrs={
> "type": "text",
> "class": "form-control form-control-lg",
> }
> ),
> )
> point = forms.PointField(
> widget=forms.OSMWidget(
> attrs={
> 'map_width': 800,
> 'map_height': 250,
> 'default_lat': 0,
> 'default_lon': 0,
> 'default_zoom': 2,
> }
> ),
> )
>
> class Meta:
> model = AddPoint
> fields = [
> 'name',
> 'point',
> ]


*views.py*

> def addPointOnMap(request):
> if request.method == "POST":
> geoform = AddPointForm(request.POST or None)
> if geoform.is_valid():
> new_point = geoform.save()
> return redirect('add_points_map')
> else:
> geoform = AddPointForm()
> context = {
> 'geoform': geoform,
> }
> template = 'maps/editing/add_point.html'
> return render(request, template, context)


Questo è il codice che ho prodotto. Come vedete è una banalissima
applicazione ma a quanto pare non riesco a farla funzionare.
Uso Django 2.2, il DB che uso è PostgreSQL 11 con PostGIS 2.5

--
[1]
https://gis.stackexchange.com/questions/329992/form-returns-integrityerror
___
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni 
dell'Associazione GFOSS.it.
796 iscritti al 28/12/2017

Re: [Gfoss] Miglior soluzione server cloud

2019-07-15 Per discussione Massimiliano Moraca
Ciao Walter e grazie per la risposta
Massimo o Massimilano, siamo lì! ;)

Concordo con la tua descrizione di Digital Ocean, ho spostato il mio sito e
quello di un altro mio progetto da GoDaddy a DO lo scorso dicembre proprio
perchè trovo che siamo molto chiaro e trasparente anche in fatturazione.
Ero indirizzato su PostGIS ma nel dubbio ho preferito chiedere e visto
quello che mi dici credo che alla fine opterò per la soluzione da 40$



Il giorno lun 15 lug 2019 alle ore 08:46 Walter Lorenzetti <
lorenze...@gis3w.it> ha scritto:

> Scusa.. Massimiliano :)
>
> W
>
> Il 15/07/19 08:39, Walter Lorenzetti ha scritto:
> > Buongiorno Massimo,
> >
> > noi a Gis3W utilizziamo DO con piacere :).
> >
> > E' intuitivo e chiaro sia dal punto di vista dell'utilizzo che della
> > fatturazione.
> >
> > Ci troviamo molto bene.
> >
> > Sto provando in questi giorni una istanza come la tua da 20$ per una
> > istallazione django su Postgis,  per un gruppo ridotto di utenti 5/6.
> >
> > Tutto dipende da cosa il tuo applicativo deve fare, se ha bisogno di
> > processare dati e in particolare dati geo forse meglio aumentare il
> > numero dei processori, ma se è una app di consultazione dati.. non
> > penso ci siano problemi in termini di prestazioni.
> >
> > Per quanto riguarda il db, di solito SQlite non lo si usa in
> > produzione soprattutto per il fatto che SQlite è perfetto per
> > l'accesso mono utente, quando si parla possibili accessi in
> > contemporanea forse meglio Postgis.
> >
> > Secondo me un fattore discriminante è se la tua app deve consentire
> > l'inserimento di dati da parte dell'utente finale, in questo caso io
> > ti consiglierei PostGis per andare sul sicuro.
> >
> > W
> >
> > Il 14/07/19 11:35, Massimiliano Moraca ha scritto:
> >> Buongiorno e buona domenica a tutti.
> >> Tra le soluzioni di Digital Ocean
> >> <
> https://u11462016.ct.sendgrid.net/wf/click?upn=XweYNmU4rQHiUA3FlY-2F92uzniA-2FAL-2Fe2vJN-2FiTaD-2Fo1BDrjKSO77birEGlQc7iUyOgRvE1EAEDQEmIklfD7NlKHpkQpIAXOX7dS6IwUU5MpmAzbM9QylK7RRwyLLinf1D3jCdqd9AjRI3uG4VJjhXRNVj-2FvfmC0nZSA9rIOONIs-2F4dFxO9MeGq4kDSo9o-2FLBCEYD6Ev4RevakRIpjL2-2BGYWpSiBd7FVIpvPAGhxRcSCuRP27wOWDpvD-2F9TqFEuYTM3mXTzAV1deSX5MFBQksAKrizpVlS7u6KjU9TnDaQ-2F4XS0IgAFyi0tMK-2Bur4u6Vn-2B4XJGxnRcqJBwSGan1-2FdaCMFl-2BRYthmudisKQL6tI5cnCGNEFGUv8jVYYDFwahcOkevEc71PvhEN-2FLsVmMfxJTLaNbcSgo68Ji9LAQ0Tq6wliK0bWvgDjlER1rxwkMYj9lrMdGjmmBXwJBmBguxmMqZmchwaD0gyZ1CzezaFT1eGLiVu7xJhIucuKWsrm-2BjR_KQEy3r4qRb4cGLBo4LIQNCSyrhgEDg4TMQQd8f7sxCkUbgEF-2BwcmeTFosgtag9tfVSs8TcJPIaCfX4GHdh4xrgD24zlkWXKi3-2FGz1ySQh6TqNswddd7AwSZUUPo3Tlm8NYoaXCBY13PaHnw1XLB7BFz4L3JWbwdB-2FWWY7c4A4L3TAq0c5X7qLTjHa7BG-2BRwrvfr5eOt3vLQC4gSOTmum9K6F3p8B6hw3cpYPoBSxQGQ-3D
> >
> >> quale scegliereste per un progetto web basato su geodjango e che prevede
> >> l'accesso in contemporanea di una ventina di persone intente a
> >> posizionare
> >> marker su una mappa?
> >>
> >> Io sarei orientato su una Droplet con Ubuntu da 20$ al mese; è una
> >> soluzione da 4GB di RAM, 2CPU, 80GB SSD e 1TB di transfer.
> >>
> >> Come db mi consigliate SQLite o PostGIS?
> >>
> >> Ho già un account su Digital Ocean, mi ci trovo bene e preferisco usare
> >> questo servizio
> >> ___
> >> Gfoss@lists.gfoss.it
> >>
> https://u11462016.ct.sendgrid.net/wf/click?upn=XweYNmU4rQHiUA3FlY-2F92uzniA-2FAL-2Fe2vJN-2FiTaD-2Fo1BDrjKSO77birEGlQc7iUyRfLGy0SVo-2Bfk6N02pxTI9bc3E-2BDoJPnumFfnq4UmOkPxWABWVl4WaZ-2FffK0EYFqQFJz-2Fc7VeatpI-2BAdaskeAEG4-2BwGfyUbxLnIwkAZZ7i5Av-2FLc5iNWNFJ-2FaMkgbgLtepVRIiO-2BiabpjwL6vry0k-2BhzPzzt6BbRFe-2FrEwNNR41KABJ-2F7NEJzAQv9A8R1HHbkNLXKeSfjCRjEXpanZQSWgmI7P4pMSkQm9JR6TbulupCMFdy6cmfTLzFO7cb1mbs6d1QTNCK205Jha34Gs76DnYGBSczhqrzxJSDaKP9JTzAe9SK031TDGqJkmNVdDoaeZoRcHwYavLbaGiy12l06-2B-2FnorWtHpoB-2FD1-2BgowUHN9Rp-2FGV-2BIg-2FsR9O5vZ21dZ4eKLrJEVbBl4D3WsSONE-2B7-2FJDiSF3xMlbIae-2FKrwDR763f5efoR0GklbKlCfL5Q7Oa6Jlg-2BguEMLxKml7SctefaA-3D-3D_KQEy3r4qRb4cGLBo4LIQNCSyrhgEDg4TMQQd8f7sxCkUbgEF-2BwcmeTFosgtag9tf1ssyjxvi3DU7s-2F8TK6dDwSSsMM32HWX5MiHmUOSDWsO-2F556J16ynu3bKWN-2B1vT-2FWwbo0EkxhVFtIibKGhQ9SKhj8JVytNcg-2FvteAoo0pwcz5BAULElxrSGKMVxuntxQAmRlHj0wLM1HFf00xezzv1peT9iNVKBOruqVzefcyirg-3D
> >>
> >> Questa e' una lista di discussione pubblica aperta a tutti.
> >> I messaggi di questa lista non hanno relazione diretta con le
> >> posizioni dell'Associazione GFOSS.it.
> >> 796 iscritti al 28/12/2017
> --
>
> Walter Lorenzetti phD
> email: lorenze...@gis3w.it
> skype: aiki74
> twitter:w_lorenzetti <
> https://u11462016.ct.sendgrid.net/wf/click?upn=XweYNmU4rQHiUA3FlY-2F92tXtwVpBLC-2BdX

[Gfoss] Miglior soluzione server cloud

2019-07-14 Per discussione Massimiliano Moraca
Buongiorno e buona domenica a tutti.
Tra le soluzioni di Digital Ocean 
quale scegliereste per un progetto web basato su geodjango e che prevede
l'accesso in contemporanea di una ventina di persone intente a posizionare
marker su una mappa?

Io sarei orientato su una Droplet con Ubuntu da 20$ al mese; è una
soluzione da 4GB di RAM, 2CPU, 80GB SSD e 1TB di transfer.

Come db mi consigliate SQLite o PostGIS?

Ho già un account su Digital Ocean, mi ci trovo bene e preferisco usare
questo servizio
___
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni 
dell'Associazione GFOSS.it.
796 iscritti al 28/12/2017

Re: [Gfoss] Proj e GDAL

2019-06-12 Per discussione Massimiliano Moraca
Grazie per i preziosi consigli Sandro.

Vedo che effettivamente ci vuole molto tempo per terminare il make, proprio
come indicato nella procedura sul sito di GeoDjango. Mi sa che solo un
caffè non basta per occupare l'attesa

Il giorno mer 12 giu 2019 alle ore 16:49  ha scritto:

> On Wed, 12 Jun 2019 16:41:39 +0200, Massimiliano Moraca wrote:
> > Noto che l'errore che compivo era scrivere _./configure
> > --with-proj4=/usr/local_ anzicchè _./configure
> > --with-proj=/usr/local _
> >
>
> sugggerimento: e' una caratteristica standard di tutti gli
> script ./configure; se tu chiami
>
> ./configure --help
>
> ti uscira' fuori un paginone bello lungo con tutte le
> possibili opzioni supportate da quello specifico script.
> merita sempre leggersele con estrama attenzione, perche'
> spesso la soluzione di molti problemi di configurazione
> apparentemente insolubili e' nascosta proprio li dentro.
>
> consiglio ancora piu' utile: se ci fai caso ogni volta
> che fai girare ./configure ti genera un file che si
> chiama config.log, e che ti spiega per filo e per segno
> tutto quello che e' stato fatto, inclusi eventuali
> errori. anche questo e' fondamentale per capire dove
> eventualmente si impiglia.
>
> ciao Sandro
>
___
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni 
dell'Associazione GFOSS.it.
796 iscritti al 28/12/2017

Re: [Gfoss] Proj e GDAL

2019-06-12 Per discussione Massimiliano Moraca
Noto che l'errore che compivo era scrivere *./configure
--with-proj4=/usr/local* anzicchè *./configure --with-proj=/usr/local *

Ora ho dato *make* e sto aspettando che termini.

Grazie come sempre Alessandro

Il giorno mer 12 giu 2019 alle ore 16:28  ha scritto:

> On Wed, 12 Jun 2019 16:03:53 +0200, Massimiliano Moraca wrote:
> > Ho rieseguito il processo di installazione delle proj6 per sicurezza
> > ma
> > dopo *./configure* mi ritrovo sempre lo stesso messaggio di errore di
> > cui
> > sopra
> >
>
> ma ora stai chiamando ./configure "liscio" (senza argomenti)
> oppure gli stai passando anche la direttiva che lo punta sulla
> libreria custom ?
>
> ./configure --with-proj=/usr/local
>
> se hai fatto tutto secondo le regole e continua a non funzionare
> non ci rimane che ricorrerre alle variabili d'ambiente del gcc,
> che in genere risolvono tutti i conflitti quando ci sono piu'
> versioni della medesima libreria:
>
> export "CPPFLAGS=-I/usr/local/include"
> export "LDFLAGS=-L/usr/local/lib"
> ./configure --with-proj=/usr/local
>
> microspiegazione: la prima export forza gcc a cercare gli
> headers per prima cosa dentro ad /usr/local/include
> la seconda forza il linker a cercare le librerie dentro
> ad /usr/local/lib con la massima priorita'; solo se non
> le trova continuera' poi a cercarle tra i system packages.
>
> ciao Sandro
> ___
> Gfoss@lists.gfoss.it
> http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
> Questa e' una lista di discussione pubblica aperta a tutti.
> I messaggi di questa lista non hanno relazione diretta con le posizioni
> dell'Associazione GFOSS.it.
> 796 iscritti al 28/12/2017
___
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni 
dell'Associazione GFOSS.it.
796 iscritti al 28/12/2017

Re: [Gfoss] Proj e GDAL

2019-06-12 Per discussione Massimiliano Moraca
Ho rieseguito il processo di installazione delle proj6 per sicurezza ma
dopo *./configure* mi ritrovo sempre lo stesso messaggio di errore di cui
sopra

Il giorno mer 12 giu 2019 alle ore 15:35 Massimiliano Moraca <
massimilianomor...@gmail.com> ha scritto:

> Alessandro da terminale riesco a vedere che in usr/local/lib c'è questo:
> /(base) maxdragonheart@Drako-U:/usr/local/lib$ ls
> libgeos-3.7.2.so  libgeos_c.so libgeos.so  libproj.so.15
> python3.6
> libgeos.a libgeos_c.so.1   libproj.a   libproj.so.15.1.0
> libgeos_c.a   libgeos_c.so.1.11.2  libproj.la  pkgconfig
> libgeos_c.la  libgeos.la   libproj.so  python2.7
> /
> Mentre in usr/local/include c'è questo:
> /(base) maxdragonheart@Drako-U:/usr/local/include$ ls
> geodesic.h  geos.h  proj_api.h   proj.h
> geosorg_proj4_PJ.h  proj_constants.h proj_symbol_rename.h
> geos_c.hprojproj_experimental.h/
>
> Vedo che ci sono dei file che fanno riferimento a proj, sono quelli
> corretti?
>
> -
> Ingegnere, consulente GIS e ciclista urbano
> --
> Sent from:
> http://gfoss-geographic-free-and-open-source-software-italian-mailing.3056002.n2.nabble.com/
> ___
> Gfoss@lists.gfoss.it
> http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
> Questa e' una lista di discussione pubblica aperta a tutti.
> I messaggi di questa lista non hanno relazione diretta con le posizioni
> dell'Associazione GFOSS.it.
> 796 iscritti al 28/12/2017
___
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni 
dell'Associazione GFOSS.it.
796 iscritti al 28/12/2017

Re: [Gfoss] Proj e GDAL

2019-06-12 Per discussione Massimiliano Moraca
Alessandro da terminale riesco a vedere che in usr/local/lib c'è questo:
/(base) maxdragonheart@Drako-U:/usr/local/lib$ ls
libgeos-3.7.2.so  libgeos_c.so libgeos.so  libproj.so.15 
python3.6
libgeos.a libgeos_c.so.1   libproj.a   libproj.so.15.1.0
libgeos_c.a   libgeos_c.so.1.11.2  libproj.la  pkgconfig
libgeos_c.la  libgeos.la   libproj.so  python2.7
/
Mentre in usr/local/include c'è questo:
/(base) maxdragonheart@Drako-U:/usr/local/include$ ls
geodesic.h  geos.h  proj_api.h   proj.h
geosorg_proj4_PJ.h  proj_constants.h proj_symbol_rename.h
geos_c.hprojproj_experimental.h/

Vedo che ci sono dei file che fanno riferimento a proj, sono quelli
corretti?

-
Ingegnere, consulente GIS e ciclista urbano
--
Sent from: 
http://gfoss-geographic-free-and-open-source-software-italian-mailing.3056002.n2.nabble.com/
___
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni 
dell'Associazione GFOSS.it.
796 iscritti al 28/12/2017

[Gfoss] Proj e GDAL

2019-06-12 Per discussione Massimiliano Moraca
Sempre ai fini della corretta installazione di  GeoDjango

 
, sto riscontrando difficoltà con l'installazione di GDAL.

In particolare mi viene restituito questo messaggio di errore dopo aver
digitato *./configure*:

/checking for PROJ >= 6 library... checking for proj_create_from_wkt in
-lproj... no
checking for internal_proj_create_from_wkt in -lproj... no
checking for internal_proj_create_from_wkt in -linternalproj... no
configure: error: PROJ 6 symbols not found/

Qui
 
 
ho trovato quella che credevo essere la soluzione ma non è così.

Come potrei uscire da questo stallo? 

Sono su Ubuntu 18.04 e qui c'è la guida ufficiale alla configurazione di 
GeoDjango
  

-
Ingegnere, consulente GIS e ciclista urbano
--
Sent from: 
http://gfoss-geographic-free-and-open-source-software-italian-mailing.3056002.n2.nabble.com/
___
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni 
dell'Associazione GFOSS.it.
796 iscritti al 28/12/2017

Re: [Gfoss] Installazione manuale librerie proj su Ubuntu 18.04

2019-06-12 Per discussione Massimiliano Moraca
Grazie Alessandro, in realtà sono incappato in due problemi. Uno è quello che
mi hai indicato con le librerie libsqlite3-dev mentre l'altro è che, non
venendo dal mondo DEV, non ero al corrente del fatto che 3.7 è settima
release della terza versione mentre 3.27 è quindi la ventisettesima release
della terza. Per cui effettivamente 3.27 >= di 3.7. Per come ragionavo io
3.7 è più grande di 3.27 ma il valore reale, per il mio modo di ragionare da
non sviluppatore(ancora), sarebbe 3.07. Ho acquisito questa informazione!

Ho seguito le tue indicazioni e l'installazione è andata a buon fine, grazie
di nuovo

-
Ingegnere, consulente GIS e ciclista urbano
--
Sent from: 
http://gfoss-geographic-free-and-open-source-software-italian-mailing.3056002.n2.nabble.com/
___
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni 
dell'Associazione GFOSS.it.
796 iscritti al 28/12/2017

Re: [Gfoss] Circonferenze circoscritte ai poligoni con PostGIS

2019-04-30 Per discussione Massimiliano Moraca
Il motivo per cui volevo ottenere le circonferenze di cui sopra era quello di
ottenere poi i quadrati che contengono le circonferenze.

Ho scritto in proposito un tutorial sul mio blog, se interessa è  qui
  

:)

-
Ingegnere, consulente GIS e ciclista urbano
--
Sent from: 
http://gfoss-geographic-free-and-open-source-software-italian-mailing.3056002.n2.nabble.com/
___
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni 
dell'Associazione GFOSS.it.
796 iscritti al 28/12/2017

Re: [Gfoss] Circonferenze circoscritte ai poligoni con PostGIS

2019-04-30 Per discussione Massimiliano Moraca
Si, vi confermo che era quello che cercavo.
Scusate il disturbo, fare ricerche a tarda sera fa perdere lucidità

-
Ingegnere, consulente GIS e ciclista urbano
--
Sent from: 
http://gfoss-geographic-free-and-open-source-software-italian-mailing.3056002.n2.nabble.com/
___
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni 
dell'Associazione GFOSS.it.
796 iscritti al 28/12/2017

Re: [Gfoss] Circonferenze circoscritte ai poligoni con PostGIS

2019-04-29 Per discussione Massimiliano Moraca
Forse ho  trovato la soluzione
  , domani vi faccio
sapere.

Se nel frattempo a qualcuno viene in mente altro, scriva pure :)

-
Ingegnere, consulente GIS e ciclista urbano
--
Sent from: 
http://gfoss-geographic-free-and-open-source-software-italian-mailing.3056002.n2.nabble.com/
___
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni 
dell'Associazione GFOSS.it.
796 iscritti al 28/12/2017

[Gfoss] Circonferenze circoscritte ai poligoni con PostGIS

2019-04-29 Per discussione Massimiliano Moraca
Buonasera a tutti
Ho un piccolo quesito su PostGIS: dati N poligoni irregolari è possibile
definire la circonferenza che contiene ogni singolo poligono?

Prendendo come esempio le regioni italiane, è possibile ottenere 20
circonferenze, una per ogni Regione?



-
Ingegnere, consulente GIS e ciclista urbano
--
Sent from: 
http://gfoss-geographic-free-and-open-source-software-italian-mailing.3056002.n2.nabble.com/
___
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni 
dell'Associazione GFOSS.it.
796 iscritti al 28/12/2017

Re: [Gfoss] Altezze edifici piccoli borghi

2019-03-29 Per discussione Massimiliano Moraca
Nino per SNAP prova a dare un'occhiata alla discussione che ho aperto sul
forum dell'ESA[0], nel primo post ci sono i referimenti da cui ho studiato
per approcciarmi all'interferometria. Come leggerai nella discussione, pare
che SNAP abbia alcuni bug proprio nella parte SAR. Io per ora ci ho
rinunciato ma magari tu sei più fortunato di me



[0]
https://forum.step.esa.int/t/apply-orbit-file-error-no-orbit-file-found/14400

Il giorno ven 29 mar 2019 alle ore 14:14 nformica  ha
scritto:

> Ciao Max,
>
> grazie per i suggerimenti, comunque utili, anche se come ha detto Marco una
> risoluzione di 10 metri non va bene per le info che dovrei rilevare;
> l'ideale sarebbe una risoluzione di 2 mt.
>
> E' anche vero che potrei acquistare delle tile high resolution (ammesso che
> le trovo per le zone che devo coprire), ma i comuni sono una 20ina, non so
> quanto dovrei spendere !?
>
> Ho letto poi di alcuni algoritmi che ti permettono di calcolare, con buona
> approx, l'altezza di una casa sfruttando l'ombra che risulta proiettata
> nelle immagini satellitari, conoscendo l'azimuth solare; ma onestamente non
> sono quanto può essere una strada percorribile per centinaia di edifici !!
>
> In ogni caso, anche solo per testarlo, vorrei provare ad usare il tool
> SNAP
> (che non conosco) per capire se in futuro può essermi utile.
>
> Cari saluti
> Nino
>
> --
> Sent from:
> http://gfoss-geographic-free-and-open-source-software-italian-mailing.3056002.n2.nabble.com/
> ___
> Gfoss@lists.gfoss.it
> http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
> Questa e' una lista di discussione pubblica aperta a tutti.
> I messaggi di questa lista non hanno relazione diretta con le posizioni
> dell'Associazione GFOSS.it.
> 796 iscritti al 28/12/2017
___
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni 
dell'Associazione GFOSS.it.
796 iscritti al 28/12/2017

Re: [Gfoss] Altezze edifici piccoli borghi

2019-03-29 Per discussione Massimiliano Moraca
Si lo so, l'esempio dei Sentinel-1 era per rispondere alla richiesta di
Nino sulla possibilità di estrarre dati altimetrici da quelli satellitari.
In base al budget potrebbe acquistare tile a risoluzione spaziale minore e
sicuramente più indicata per il suo scopo.

Il giorno ven 29 mar 2019 alle ore 12:08 Marco Guiducci <
marco.guidu...@regione.toscana.it> ha scritto:

>
>
> Il 29/03/2019 10:02, Massimiliano Moraca ha scritto:
> > Ciao Nino,
> > con i dati SAR è possibile rilevare questo tipo di informazioni. I
> > Sentinel-1 sono utilizzabili gratuitamente ed hanno una risoluzione tra
> > 20-10m. Il processo di estrazione del DSM da SAR è abbastanza laborioso
> ma
> > si dovrebbe ottenere un dato utile. Uso il condizionale perché ho
> provato a
> > lavorare con SNAP, il tool ESA, per diversi giorni ma senza risultato
> causa
> > bug.
> >
>
> a mio parere con un dato di risoluzione di 10 o 20 m, soprattutto nei
> piccoli borghi (strade strette, corpi di fabbrica adiacenti ma piccoli
> in superficie e di differente altezza in gronda, insomma frequenza alta)
> ci si fa poco.
> marco
>
> --
> Marco Guiducci - 055 4383194
> SITA - Sistema informativo territoriale e ambientale
> Regione Toscana - Via di Novoli 26 - 50127 Firenze
>
> ___
> Gfoss@lists.gfoss.it
> http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
> Questa e' una lista di discussione pubblica aperta a tutti.
> I messaggi di questa lista non hanno relazione diretta con le posizioni
> dell'Associazione GFOSS.it.
> 796 iscritti al 28/12/2017
___
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni 
dell'Associazione GFOSS.it.
796 iscritti al 28/12/2017

Re: [Gfoss] Altezze edifici piccoli borghi

2019-03-29 Per discussione Massimiliano Moraca
Ciao Nino,
con i dati SAR è possibile rilevare questo tipo di informazioni. I
Sentinel-1 sono utilizzabili gratuitamente ed hanno una risoluzione tra
20-10m. Il processo di estrazione del DSM da SAR è abbastanza laborioso ma
si dovrebbe ottenere un dato utile. Uso il condizionale perché ho provato a
lavorare con SNAP, il tool ESA, per diversi giorni ma senza risultato causa
bug.

Mi hanno consigliato ENVI ma è fuori budget nel mio caso.

Il ven 29 mar 2019, 09:26 nformica  ha scritto:

> Salve,
>
> in mancanza di DTM, o meglio DSM, esiste un qualche modo per rilevare
> altezze di case ed edifici partendo da immagini satellitari ?
> Mi riferisco soprattutto ad edificati di piccoli paesi e borghi per i quali
> anche su OSM non si trova nulla.
> Tempo fa avevo sentito parlare di un modo che riusciva a determinare queste
> altezze con buona approssimazione, partendo dalle ombre che si vedono sul
> Google satellite.
>
> Avete qualche suggerimento ?
>
> Nino Formica
>
> --
> Sent from:
> http://gfoss-geographic-free-and-open-source-software-italian-mailing.3056002.n2.nabble.com/
> ___
> Gfoss@lists.gfoss.it
> http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
> Questa e' una lista di discussione pubblica aperta a tutti.
> I messaggi di questa lista non hanno relazione diretta con le posizioni
> dell'Associazione GFOSS.it.
> 796 iscritti al 28/12/2017
___
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni 
dell'Associazione GFOSS.it.
796 iscritti al 28/12/2017

Re: [Gfoss] Multipart feature in PostGIS

2019-02-22 Per discussione Massimiliano Moraca
AGGIORNAMENTO

Ho creato, dopo aver trovato e bonificato una invalid geometry, una copia
del vettore con 

CREATE TABLE zonizzazione_v6 AS SELECT * FROM zonizzazione_v5 ORDER BY fid

La copia è, non ho capito perchè, di tipo polygon anzicchè essere
multipolygon come l'originale. Facendo un check topologico sulla copia non
ho più multipart geometry come l'originale ma sono venuti fuori 2 invalid
geometry oltre i soliti micro overlap. 

Come è possibile che la copia di un vettore senza invalid geometry abbia
invalid geometry?

-
Ingegnere, consulente GIS e ciclista urbano
--
Sent from: 
http://gfoss-geographic-free-and-open-source-software-italian-mailing.3056002.n2.nabble.com/
___
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni 
dell'Associazione GFOSS.it.
796 iscritti al 28/12/2017

Re: [Gfoss] Multipart feature in PostGIS

2019-02-22 Per discussione Massimiliano Moraca
Questi dati hanno più fonti, alcuni sono presi tal quale come quelli della
CTR ma essendo in 3D li ho convertiti in 2D con ST_Force2D, altri durante i
processi di creazione(che non ho seguito io) mi sono tornati affetti da
overlap e invalid geometry.

Effettuate le correzioni topologiche varie in PostGIS, uno dei vettori ho
riscontrato che aveva ancora problemi di overlap ma sono micro overlap che,
come ho scritto prima, non riesco a vedere e quindi non riesco a correggere
a mano(ho corretto a mano anche gli altri overlap). Ovviamente gli errori
di questo vettore sono stati importati nel vettore della zonizzazione. Su
quello poi ho iniziato a fare alcune modifiche ed ogni tanto, per
abitudine, faccio sempre un check delle topologia da QGIS. A parte i micro
overlap tutto andava bene, poi ho inserito il check sul multipart e ho
avuto la sorpresa.

Ho fatto la verifica che mi hai indicato. Ho usato "Multipart to
Singlepart", ho salvato l'output sia in shapefile che in geopackage e
rifatto il check. Da premettere che l'output del multi to single l'ho
sempre esportato direttamente come geopackage o inviato a PostGIS senza
fare il chech. Stavolta ho fatto il check e il vettore salvato come
shapefile aveva di nuovo tutti i poligoni segnalati come multipart mentre
il geopackage no; entrambi continuano ad avere i 10 micro overlap(e ci sta
non avendo fatto nulla per risolverli). Comunque mi aspettavo che lo
shapefile desse problemi che il geopackage non da, è per questo che oramai
sto usando solo lui quando posso.

Il giorno ven 22 feb 2019 alle ore 14:03 Andrea Peri 
ha scritto:

> Ma se li mantenevi su postgis e facevi il check da qgis li avevi comunque
> i microoverlap ?
> E se li esporti in shp e fai il check ?
>
> Te lo chiedo perche da quello che scrivi ne ricavo l impressione che l
> importazione in gpk ricalibri i vertici su una griglia. Solo questo mi
> spiegherebbe quello che descrivi.
> Ovviamente ammettendo che hai realmente rimosso i microoverlap.
>
>
> Il ven 22 feb 2019, 12:01 Massimiliano Moraca <
> massimilianomor...@gmail.com> ha scritto:
>
>> Salve a tutti, sto lavorando alla correzione di un vettore poligonale
>> relativo alla zonizzazione di un territorio comunale. Sono partito da vari
>> shapefile che ho importato in PostGIS. Tutti i poligoni, una volta
>> corretti
>> topologicamente, sono poi confluiti nel vettore della zonizzazione su cui
>> sto lavorando.
>>
>> Facendo un check sulla topologia da QGIS 3 è risultato che il vettore in
>> questione è totalmente composto da multipart feature ed ha una decina di
>> micro overlap che non riesco a correggere perché non li vedo.
>>
>> Ho quindi usato "multipart to singlepart" da QGIS e ho salvato il
>> risultato
>> in geopackage. Fatta la verifica su quest'ultimo non ho più multipart ma
>> solo quella decina di micro overlap.
>>
>> Importando il geopackage in PostGIS tramite ogr e facendo di nuovo il
>> check, ho riscontrato di nuovo il problema iniziale. Vi è mai capitata una
>> cosa del genere? Come avete risolto(vale anche per i micro overlap)?
>> ___
>> Gfoss@lists.gfoss.it
>> http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
>> Questa e' una lista di discussione pubblica aperta a tutti.
>> I messaggi di questa lista non hanno relazione diretta con le posizioni
>> dell'Associazione GFOSS.it.
>> 796 iscritti al 28/12/2017
>
>
___
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni 
dell'Associazione GFOSS.it.
796 iscritti al 28/12/2017

[Gfoss] Multipart feature in PostGIS

2019-02-22 Per discussione Massimiliano Moraca
Salve a tutti, sto lavorando alla correzione di un vettore poligonale
relativo alla zonizzazione di un territorio comunale. Sono partito da vari
shapefile che ho importato in PostGIS. Tutti i poligoni, una volta corretti
topologicamente, sono poi confluiti nel vettore della zonizzazione su cui
sto lavorando.

Facendo un check sulla topologia da QGIS 3 è risultato che il vettore in
questione è totalmente composto da multipart feature ed ha una decina di
micro overlap che non riesco a correggere perché non li vedo.

Ho quindi usato "multipart to singlepart" da QGIS e ho salvato il risultato
in geopackage. Fatta la verifica su quest'ultimo non ho più multipart ma
solo quella decina di micro overlap.

Importando il geopackage in PostGIS tramite ogr e facendo di nuovo il
check, ho riscontrato di nuovo il problema iniziale. Vi è mai capitata una
cosa del genere? Come avete risolto(vale anche per i micro overlap)?
___
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni 
dell'Associazione GFOSS.it.
796 iscritti al 28/12/2017

Re: [Gfoss] possibile posizione junior per appassionato gis a Trento

2018-12-10 Per discussione Massimiliano Moraca
Qualche dato in più non sarebbe male e renderebbe la ricerca più agevole.

Tipo di prestazione lavorativa(P.IVA, contratto determinato, etc)?
Compenso previsto?
Possibilità di svolgimento dell'attività da remoto?
Età?
Laurea?

Il giorno lun 10 dic 2018 alle ore 13:28 Maurizio Napolitano 
ha scritto:

> Ciao
> vi scrivo su richiesta di un amico che mi sta chiedendo se conosco una
> persona junior appassionata di gis da coinvolgere in un progetto di 10
> mesi a Trento.
> Il lavoro da fare è quello di raccolta, organizzazione, armonizzazione
> di dati 3D da distribuire via servizi online.
> Richiesta conoscenza su sistema gis opensource, gradita invece la
> capacità di fare script python.
> Se vi viene in mente qualcosa, date pure il mio indirizzo email :)
>
> Bye
>
> --
> --
> Le informazioni contenute nella presente comunicazione sono di natura
> privata e come tali sono da considerarsi riservate ed indirizzate
> esclusivamente ai destinatari indicati e per le finalità strettamente
> legate al relativo contenuto. Se avete ricevuto questo messaggio per
> errore, vi preghiamo di eliminarlo e di inviare una comunicazione
> all’indirizzo e-mail del mittente.
>
> --
> The information transmitted is
> intended only for the person or entity to which it is addressed and may
> contain confidential and/or privileged material. If you received this in
> error, please contact the sender and delete the material.
> ___
> Gfoss@lists.gfoss.it
> http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
> Questa e' una lista di discussione pubblica aperta a tutti.
> I messaggi di questa lista non hanno relazione diretta con le posizioni
> dell'Associazione GFOSS.it.
> 796 iscritti al 28/12/2017
___
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni 
dell'Associazione GFOSS.it.
796 iscritti al 28/12/2017

Re: [Gfoss] Confronto tra vettori per individuare le differenze

2018-12-05 Per discussione Massimiliano Moraca
No questo non l'ho fatto e potrebbe essere una strategia migliore in
effetti, anche perchè potrei concatenare una serie di query per fare un
aggiornamento automatico.

Il giorno mer 5 dic 2018 alle ore 13:15 Andrea Peri 
ha scritto:

> Non conosco le potenzialità di qgis su questo fronte. Hai fatto la
> difference tra geometrie e verifichi se il risultato è vuoto ?
>
> Il giorno mer 5 dic 2018, 12:56 Massimiliano Moraca <
> massimilianomor...@gmail.com> ha scritto:
>
>> La soluzione che ho adottato, è una Spatial Query con QGIS 2.18 per
>> evidenziare le geometrie variate, che poi sostituisco con copia ed incolla
>> in PostGIS ma sempre da QGIS.
>> E' un po' macchinosa come procedura ma alla fine è funzionale e mi evita
>> di
>> dover caricare un vettore fantoccio in PostGIS da eliminare ad operazioni
>> finite.
>> A naso penso che se creassi un trigger in PostGIS potrei automatizzare la
>> cosa, ma a dire la verità ancora non mi sono mai cimentato nei trigger.
>>
>> Il giorno mer 28 nov 2018 alle ore 10:52 Luca Delucchi <
>> lucadel...@gmail.com>
>> ha scritto:
>>
>> >
>> >
>> > Il giorno sab 24 nov 2018, 19:44 Massimiliano Moraca <
>> > massimilianomor...@gmail.com> ha scritto:
>> >
>> >> Salve a tutti, oggi vi scoccio per la seconda volta :)
>> >>
>> >> Devo confrontare un vettore lineare con un altro per verificarne le
>> >> differenze. In realtà i due vettori sono la copia dello stesso vettore
>> >> solo
>> >> che quello "principale"(*A*) risiede in un database PostGIS mentre
>> quello
>> >> "secondario"(*B*) è in un database SpatiaLite. *B* era usato come base
>> >> cartografica per l'editing di poligoni, questi poligoni poi vengono
>> >> aggiunti
>> >> al database PostGIS. Si è reso purtroppo necessaria l'editazione anche
>> di
>> >> *B* in parte con l'aggiunta di nuove linee in parte modificando linee
>> già
>> >> esistenti.
>> >>
>> >> E' possibile andare ad aggiornare in maniera automatica *A* con *B*
>> senza
>> >> dovermi mettere a verificare una per una le linee? Per le linee
>> aggiunte
>> >> sono facilitato nel lavoro grazie al fatto che mancano alcuni
>> attributi,
>> >> per
>> >> quelle invece modificate non so come muovermi.
>> >>
>> >
>> > L'idea che mi viene in mente è che dovresti avere un id univoco e poi
>> > confrontare le geometrie degli stessi id.
>> > Puoi farti uno scriptino nel linguaggio che preferisci.
>> >
>> > Ciao
>> > Luca
>> >
>> ___
>> Gfoss@lists.gfoss.it
>> http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
>> Questa e' una lista di discussione pubblica aperta a tutti.
>> I messaggi di questa lista non hanno relazione diretta con le posizioni
>> dell'Associazione GFOSS.it.
>> 796 iscritti al 28/12/2017
>
>
___
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni 
dell'Associazione GFOSS.it.
796 iscritti al 28/12/2017

Re: [Gfoss] qgis e geonode

2018-12-04 Per discussione Massimiliano Moraca
Grazie per le preziose informazioni Amedeo

Il giorno mar 4 dic 2018, 10:05 Amedeo Fadini  ha scritto:

> Per l'interazione QGIS Desktop - geonode io ho sempre gestito i dati in un
> DB di postgresql separato, poi creavo i layer in Geoserver e infine li
> pubblicavo in geonode con il comando
> geonode updatelayers (oppure django-admin a seconda della installazione)
>
> Gli stili sld li gestisco in geoserver o in geonode.
>
> Per una infrastruttura comunale direi che è la cosa più semplice: gli
> utenti accedono direttamente ai dati e li modificano secondo i loro
> permessi e l'admin gestisce la pubblicazione. Unico inconveniente spesso lo
> stile SLD esportato da QGIS andava rimaneggiato a mano, ma credo che con la
> 2.8 sia migliorata la compatiilità.
>
> NB: il comando updatelayers va lanciato con lo user www-data e consiglio di
> impostare un superuser a sé stante per distinguer i layer creati in
> automatico (che avranno come proprietario questo utente)
>
> Il giorno mar 4 dic 2018 alle ore 07:46 Massimiliano Moraca <
> massimilianomor...@gmail.com> ha scritto:
>
> > Grazie mille
> >
> > Il giorno lun 26 nov 2018 alle ore 17:35 Paolo Corti 
> ha
> > scritto:
> >
> > > On Thu, Nov 22, 2018 at 6:10 AM Massimiliano Moraca
> > >  wrote:
> > > >
> > > > Buongiorno e scusate se mi intrometto andando un po' OT ma vorrei
> > capirci
> > > > di più.
> > > > Sono interessato a GeoNode, pur non avendoci ancora avuto a che fare,
> > > > perchè vorrei proporlo ad una amministrazione comunale, dando la
> > > > possibilità ai tecnici comunali di interfacciarsi al DB per
> aggiornarlo
> > > > usando QGIS.
> > > > Allo stato attuale è una cosa fattibile o ci sono problemi che
> > > impediscono
> > > > l'aggiornamento con QGIS, e più in generale, l'uso  di GeoNode come
> > > > possibile WebGIS?
> > > >
> > >
> > > Ciao Massimiliano
> > >
> > > GeoNode di default usa come OGC engine GeoServer. E' possibile usare
> > > QGIS Server al posto di GeoServer, ma io non ho mai provato questa
> > > configurazione . Nel caso ti interessi specificatamente questa
> > > configurazione ti raccomanderei di scrivere in lista geonode users:
> > > https://lists.osgeo.org/cgi-bin/mailman/listinfo/geonode-users
> > >
> > > Di sicuro puoi pero', anche usando GeoNode con GeoServer, sfruttare
> > > QGIS Desktop per effettuare modifiche ai dati (editing vettori e
> > > stili).
> > > Nel primo caso - editing feature vettoriali - puoi creare in QGIS una
> > > connessione WFS e editare i dati utilizzando l'endpoint WSF-T messo a
> > > disposizione da GeoServer - piu' facile a farsi che a dirsi, e' tutto
> > > trasparente all'utente in QGIS. Quando crei la connessione ricordati
> > > di accedere con un utente che abbia i dovuti permessi ("change data
> > > for this layer").
> > > Nel secondo caso - editing stili - puoi cambiare lo stile usando QGIS
> > > e poi fare l'upload dell'SLD dalla pagina del layer in GeoNode.
> > >
> > > cordiali saluti
> > > Paolo
> > >
> > > --
> > > Paolo Corti
> > > Geospatial software developer
> > > web: http://www.paolocorti.net
> > > twitter: @capooti
> > > skype: capooti
> > >
> > ___
> > Gfoss@lists.gfoss.it
> > http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
> > Questa e' una lista di discussione pubblica aperta a tutti.
> > I messaggi di questa lista non hanno relazione diretta con le posizioni
> > dell'Associazione GFOSS.it.
> > 796 iscritti al 28/12/2017
> ___
> Gfoss@lists.gfoss.it
> http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
> Questa e' una lista di discussione pubblica aperta a tutti.
> I messaggi di questa lista non hanno relazione diretta con le posizioni
> dell'Associazione GFOSS.it.
> 796 iscritti al 28/12/2017
___
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni 
dell'Associazione GFOSS.it.
796 iscritti al 28/12/2017

Re: [Gfoss] Confronto tra vettori per individuare le differenze

2018-12-03 Per discussione Massimiliano Moraca
La soluzione che ho adottato, è una Spatial Query con QGIS 2.18 per
evidenziare le geometrie variate, che poi sostituisco con copia ed incolla
in PostGIS ma sempre da QGIS.
E' un po' macchinosa come procedura ma alla fine è funzionale e mi evita di
dover caricare un vettore fantoccio in PostGIS da eliminare ad operazioni
finite.
A naso penso che se creassi un trigger in PostGIS potrei automatizzare la
cosa, ma a dire la verità ancora non mi sono mai cimentato nei trigger.

Il giorno mer 28 nov 2018 alle ore 10:52 Luca Delucchi 
ha scritto:

>
>
> Il giorno sab 24 nov 2018, 19:44 Massimiliano Moraca <
> massimilianomor...@gmail.com> ha scritto:
>
>> Salve a tutti, oggi vi scoccio per la seconda volta :)
>>
>> Devo confrontare un vettore lineare con un altro per verificarne le
>> differenze. In realtà i due vettori sono la copia dello stesso vettore
>> solo
>> che quello "principale"(*A*) risiede in un database PostGIS mentre quello
>> "secondario"(*B*) è in un database SpatiaLite. *B* era usato come base
>> cartografica per l'editing di poligoni, questi poligoni poi vengono
>> aggiunti
>> al database PostGIS. Si è reso purtroppo necessaria l'editazione anche di
>> *B* in parte con l'aggiunta di nuove linee in parte modificando linee già
>> esistenti.
>>
>> E' possibile andare ad aggiornare in maniera automatica *A* con *B* senza
>> dovermi mettere a verificare una per una le linee? Per le linee aggiunte
>> sono facilitato nel lavoro grazie al fatto che mancano alcuni attributi,
>> per
>> quelle invece modificate non so come muovermi.
>>
>
> L'idea che mi viene in mente è che dovresti avere un id univoco e poi
> confrontare le geometrie degli stessi id.
> Puoi farti uno scriptino nel linguaggio che preferisci.
>
> Ciao
> Luca
>
___
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni 
dell'Associazione GFOSS.it.
796 iscritti al 28/12/2017

Re: [Gfoss] qgis e geonode

2018-12-03 Per discussione Massimiliano Moraca
Grazie mille

Il giorno lun 26 nov 2018 alle ore 17:35 Paolo Corti  ha
scritto:

> On Thu, Nov 22, 2018 at 6:10 AM Massimiliano Moraca
>  wrote:
> >
> > Buongiorno e scusate se mi intrometto andando un po' OT ma vorrei capirci
> > di più.
> > Sono interessato a GeoNode, pur non avendoci ancora avuto a che fare,
> > perchè vorrei proporlo ad una amministrazione comunale, dando la
> > possibilità ai tecnici comunali di interfacciarsi al DB per aggiornarlo
> > usando QGIS.
> > Allo stato attuale è una cosa fattibile o ci sono problemi che
> impediscono
> > l'aggiornamento con QGIS, e più in generale, l'uso  di GeoNode come
> > possibile WebGIS?
> >
>
> Ciao Massimiliano
>
> GeoNode di default usa come OGC engine GeoServer. E' possibile usare
> QGIS Server al posto di GeoServer, ma io non ho mai provato questa
> configurazione . Nel caso ti interessi specificatamente questa
> configurazione ti raccomanderei di scrivere in lista geonode users:
> https://lists.osgeo.org/cgi-bin/mailman/listinfo/geonode-users
>
> Di sicuro puoi pero', anche usando GeoNode con GeoServer, sfruttare
> QGIS Desktop per effettuare modifiche ai dati (editing vettori e
> stili).
> Nel primo caso - editing feature vettoriali - puoi creare in QGIS una
> connessione WFS e editare i dati utilizzando l'endpoint WSF-T messo a
> disposizione da GeoServer - piu' facile a farsi che a dirsi, e' tutto
> trasparente all'utente in QGIS. Quando crei la connessione ricordati
> di accedere con un utente che abbia i dovuti permessi ("change data
> for this layer").
> Nel secondo caso - editing stili - puoi cambiare lo stile usando QGIS
> e poi fare l'upload dell'SLD dalla pagina del layer in GeoNode.
>
> cordiali saluti
> Paolo
>
> --
> Paolo Corti
> Geospatial software developer
> web: http://www.paolocorti.net
> twitter: @capooti
> skype: capooti
>
___
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni 
dell'Associazione GFOSS.it.
796 iscritti al 28/12/2017

[Gfoss] Confronto tra vettori per individuare le differenze

2018-11-24 Per discussione Massimiliano Moraca
Salve a tutti, oggi vi scoccio per la seconda volta :)

Devo confrontare un vettore lineare con un altro per verificarne le
differenze. In realtà i due vettori sono la copia dello stesso vettore solo
che quello "principale"(*A*) risiede in un database PostGIS mentre quello
"secondario"(*B*) è in un database SpatiaLite. *B* era usato come base
cartografica per l'editing di poligoni, questi poligoni poi vengono aggiunti
al database PostGIS. Si è reso purtroppo necessaria l'editazione anche di
*B* in parte con l'aggiunta di nuove linee in parte modificando linee già
esistenti.

E' possibile andare ad aggiornare in maniera automatica *A* con *B* senza
dovermi mettere a verificare una per una le linee? Per le linee aggiunte
sono facilitato nel lavoro grazie al fatto che mancano alcuni attributi, per
quelle invece modificate non so come muovermi.

-
Ingegnere, consulente GIS e ciclista urbano
--
Sent from: 
http://gfoss-geographic-free-and-open-source-software-italian-mailing.3056002.n2.nabble.com/
___
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni 
dell'Associazione GFOSS.it.
796 iscritti al 28/12/2017

Re: [Gfoss] ERROR: out of memory for query result

2018-11-24 Per discussione Massimiliano Moraca
Azz un bel po' di roba...me la leggo con calma.
Grazie

Il giorno sab 24 nov 2018 alle ore 12:56  ha scritto:

> On Sat, 24 Nov 2018 12:46:39 +0100, Massimiliano Moraca wrote:
> > Ciao Sandro, avevo editato il primo post con una indicazione che
> > avevo
> > dimenticato, la ricopio qui:
> >
> > _EDIT: uso PostgreSQL 10 ed ho settato, in postgresql.conf,
> > shared_buffers a 2560MB  _
> >
> > Mi ero letto la documentazione e proprio per questo ho aumentato
> > l'uso
> > della RAM ma il risultato è invariato
> >
>
> Massimiliano,
>
> temo che aggiustare solo "shared_buffers" non basti affatto, presumo
> che dovresti arrangiare anche "work_mem", e forse anche altri tra
> i molti parametri che influenzano le allocazioni di RAM.
>
> prova a leggerti questo:
> https://wiki.postgresql.org/wiki/Tuning_Your_PostgreSQL_Server
>
> ciao Sandro
>
>
> > Il giorno sab 24 nov 2018 alle ore 12:31  ha scritto:
> >
> >> On Sat, 24 Nov 2018 03:56:21 -0700 (MST), Massimiliano Moraca wrote:
> >> > Salve a tutti!
> >> > Sto provando a fare un left join con PostGIS tra un vettore di
> >> linee
> >> > con
> >> > poco meno di 2.5milioni di elementi ed una tabella con circa
> >> 4mila
> >> > elementi.
> >> >
> >> > Questa è la sintassi che sto usando:
> >> >
> >> > /SELECT
> >> >   a.geom,
> >> >   a.fid,
> >> >   a.id [1],
> >> >   a.nom,
> >> >   b.width_cat,
> >> >   b.importance
> >> > FROM
> >> >   france_rivers_bdtopo_hydrographie as a
> >> > LEFT JOIN principal_rivers_nogeom as b ON a.nom =
> >> b.toponyme_lower;/
> >> >
> >> > Dopo un po' di minuti di attesa, pgAdmin 4 mi da l'errore in
> >> oggetto.
> >> >
> >> > Ho un pc con CPU i7-4970k, 16GB di RAM DDR3, un SSD da 120GB con
> >> 20GB
> >> > liberi; ho monitorato tramite "Gestione attività" di Windows 10
> >> l'uso
> >> > della
> >> > RAM e non ha mai sforato i 10GB nei test che ho effettuato.
> >> >
> >> > Come è possibile che ho quell'errore secondo voi?
> >> >
> >>
> >> Massimiliano,
> >>
> >> PostgreSQL ha una gestione molto sofisticata della RAM, e tutto
> >> quanto
> >> dipende fortemente da come hai impostato i files della
> >> configurazione.
> >> di norma la configurazione standard che viene installata
> >> automaticamente
> >> e' molto conservativa e fortemente prudenziale; va bene per piccole
> >> macchine poco potenti e con dotazioni molto limitate, mentre tende
> >> a sfruttare poco e male le macchine con dotazioni piu' generose.
> >>
> >> in soldoni, il fatto che tu abbia installato 16GB di RAM non
> >> implica automaticamente il fatto che PostgreSQL la sfruttera'
> >> tutta quanta: si fermera' alle soglie indicate dalla configurazione
> >> corrente, che verosimilmente saranno molto piu' sparagnine.
> >>
> >> prova a leggerti la doc di Postgres per capire meglio come
> >> funziona il file postgresql.conf
> >>
> >> https://www.postgresql.org/docs/9.4/runtime-config-resource.html
> >> [2]
> >>
> >> ciao Sandro
> >> ___
> >> Gfoss@lists.gfoss.it [3]
> >> http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss [4]
> >> Questa e' una lista di discussione pubblica aperta a tutti.
> >> I messaggi di questa lista non hanno relazione diretta con le
> >> posizioni dell'Associazione GFOSS.it.
> >> 796 iscritti al 28/12/2017
> >
> >
> > Links:
> > --
> > [1] http://a.id
> > [2] https://www.postgresql.org/docs/9.4/runtime-config-resource.html
> > [3] mailto:Gfoss@lists.gfoss.it
> > [4] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
> > [5] mailto:a.furi...@lqt.it
>
>
___
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni 
dell'Associazione GFOSS.it.
796 iscritti al 28/12/2017

Re: [Gfoss] ERROR: out of memory for query result

2018-11-24 Per discussione Massimiliano Moraca
Ciao Sandro, avevo editato il primo post con una indicazione che avevo
dimenticato, la ricopio qui:

*EDIT: uso PostgreSQL 10 ed ho settato, in postgresql.conf, shared_buffers
a 2560MB  *

Mi ero letto la documentazione e proprio per questo ho aumentato l'uso
della RAM ma il risultato è invariato

Il giorno sab 24 nov 2018 alle ore 12:31  ha scritto:

> On Sat, 24 Nov 2018 03:56:21 -0700 (MST), Massimiliano Moraca wrote:
> > Salve a tutti!
> > Sto provando a fare un left join con PostGIS tra un vettore di linee
> > con
> > poco meno di 2.5milioni di elementi ed una tabella con circa 4mila
> > elementi.
> >
> > Questa è la sintassi che sto usando:
> >
> > /SELECT
> >   a.geom,
> >   a.fid,
> >   a.id,
> >   a.nom,
> >   b.width_cat,
> >   b.importance
> > FROM
> >   france_rivers_bdtopo_hydrographie as a
> > LEFT JOIN principal_rivers_nogeom as b ON a.nom = b.toponyme_lower;/
> >
> > Dopo un po' di minuti di attesa, pgAdmin 4 mi da l'errore in oggetto.
> >
> > Ho un pc con CPU i7-4970k, 16GB di RAM DDR3, un SSD da 120GB con 20GB
> > liberi; ho monitorato tramite "Gestione attività" di Windows 10 l'uso
> > della
> > RAM e non ha mai sforato i 10GB nei test che ho effettuato.
> >
> > Come è possibile che ho quell'errore secondo voi?
> >
>
> Massimiliano,
>
> PostgreSQL ha una gestione molto sofisticata della RAM, e tutto quanto
> dipende fortemente da come hai impostato i files della configurazione.
> di norma la configurazione standard che viene installata
> automaticamente
> e' molto conservativa e fortemente prudenziale; va bene per piccole
> macchine poco potenti e con dotazioni molto limitate, mentre tende
> a sfruttare poco e male le macchine con dotazioni piu' generose.
>
> in soldoni, il fatto che tu abbia installato 16GB di RAM non
> implica automaticamente il fatto che PostgreSQL la sfruttera'
> tutta quanta: si fermera' alle soglie indicate dalla configurazione
> corrente, che verosimilmente saranno molto piu' sparagnine.
>
> prova a leggerti la doc di Postgres per capire meglio come
> funziona il file postgresql.conf
>
> https://www.postgresql.org/docs/9.4/runtime-config-resource.html
>
> ciao Sandro
> ___
> Gfoss@lists.gfoss.it
> http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
> Questa e' una lista di discussione pubblica aperta a tutti.
> I messaggi di questa lista non hanno relazione diretta con le posizioni
> dell'Associazione GFOSS.it.
> 796 iscritti al 28/12/2017
___
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni 
dell'Associazione GFOSS.it.
796 iscritti al 28/12/2017

[Gfoss] ERROR: out of memory for query result

2018-11-24 Per discussione Massimiliano Moraca
Salve a tutti!
Sto provando a fare un left join con PostGIS tra un vettore di linee con
poco meno di 2.5milioni di elementi ed una tabella con circa 4mila elementi.

Questa è la sintassi che sto usando:

/SELECT
a.geom,
a.fid,
a.id,
a.nom,
b.width_cat,
b.importance
FROM 
france_rivers_bdtopo_hydrographie as a
LEFT JOIN principal_rivers_nogeom as b ON a.nom = b.toponyme_lower;/

Dopo un po' di minuti di attesa, pgAdmin 4 mi da l'errore in oggetto.

Ho un pc con CPU i7-4970k, 16GB di RAM DDR3, un SSD da 120GB con 20GB
liberi; ho monitorato tramite "Gestione attività" di Windows 10 l'uso della
RAM e non ha mai sforato i 10GB nei test che ho effettuato.

Come è possibile che ho quell'errore secondo voi?

-
Ingegnere, consulente GIS e ciclista urbano
--
Sent from: 
http://gfoss-geographic-free-and-open-source-software-italian-mailing.3056002.n2.nabble.com/
___
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni 
dell'Associazione GFOSS.it.
796 iscritti al 28/12/2017

Re: [Gfoss] qgis e geonode

2018-11-22 Per discussione Massimiliano Moraca
Buongiorno e scusate se mi intrometto andando un po' OT ma vorrei capirci
di più.
Sono interessato a GeoNode, pur non avendoci ancora avuto a che fare,
perchè vorrei proporlo ad una amministrazione comunale, dando la
possibilità ai tecnici comunali di interfacciarsi al DB per aggiornarlo
usando QGIS.
Allo stato attuale è una cosa fattibile o ci sono problemi che impediscono
l'aggiornamento con QGIS, e più in generale, l'uso  di GeoNode come
possibile WebGIS?

Il giorno gio 22 nov 2018 alle ore 10:05 Enzo Cocca  ha
scritto:

> Grazie alessandro, ma nella versione di qgis3.0 sembrava che funzionasse...
>
> Il giorno gio 22 nov 2018 alle ore 08:39 Alessandro Pasotti <
> apaso...@gmail.com> ha scritto:
>
> >
> >
> > On Thu, Nov 22, 2018 at 8:06 AM Enzo Cocca  wrote:
> >
> >> salve, non riesco a far funzionare geonode in qgis, mi da sempre
> >> connessione fallita. Sono sparite anche le credenziali rispetto all
> >> versione 3.0. Qualcuno di voi ci lavora con geonode e qgis?
> >>
> >> E
> >>
> >>
> > Apri una pagina travagliata...
> >
> > https://github.com/qgis/QGIS/pull/5634#discussion-diff-150991808R23
> >
> > Per farla breve non supporta nessuna autenticazione: ma prima mostrava la
> > possibilità di inserire le credenziali senza che fosse implementato nulla
> > lato codice dando l'illusione che fosse supportato, adesso  almeno non le
> > mostra.
> >
> > Se interessa la storia (così ti fai anche un'idea della qualità del
> > codice):
> >
> > Il primo revert massiccio della storia di QGIS:
> > https://github.com/qgis/QGIS/pull/4816#issuecomment-320528379
> > e poi
> > https://github.com/qgis/QGIS/pull/5153
> >
> >
> > --
> > Alessandro Pasotti
> > w3:   www.itopen.it
> >
>
>
> --
> Enzo Cocca PhD
> in "Science and Technology for Archaeology and Cultural Heritage"
> mail: enzo@gmail.com
> cell: +393495087014
> ___
> Gfoss@lists.gfoss.it
> http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
> Questa e' una lista di discussione pubblica aperta a tutti.
> I messaggi di questa lista non hanno relazione diretta con le posizioni
> dell'Associazione GFOSS.it.
> 796 iscritti al 28/12/2017
___
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni 
dell'Associazione GFOSS.it.
796 iscritti al 28/12/2017

Re: [Gfoss] File progetto QGIS

2018-11-04 Per discussione Massimiliano Moraca
Grazie

Il giorno sab 3 nov 2018 alle ore 23:01 pigreco 
ha scritto:

> Massimiliano Moraca wrote
> > Grazie Salvatò, mi indicheresti la Mailing List di QGIS?
>
> eccola
> https://lists.osgeo.org/mailman/listinfo/qgis-it-user
>
> saluti
>
> -
> https://pigrecoinfinito.wordpress.com/
> --
> Sent from:
> http://gfoss-geographic-free-and-open-source-software-italian-mailing.3056002.n2.nabble.com/
> ___
> Gfoss@lists.gfoss.it
> http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
> Questa e' una lista di discussione pubblica aperta a tutti.
> I messaggi di questa lista non hanno relazione diretta con le posizioni
> dell'Associazione GFOSS.it.
> 796 iscritti al 28/12/2017
___
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni 
dell'Associazione GFOSS.it.
796 iscritti al 28/12/2017

Re: [Gfoss] File progetto QGIS

2018-11-03 Per discussione Massimiliano Moraca
Grazie Salvatò, mi indicheresti la Mailing List di QGIS?

Il giorno sab 3 nov 2018 alle ore 18:43 pigreco 
ha scritto:

> Massimiliano Moraca wrote
> > Salve a tutti!
> > Con l'uscita della nuova LTR e l'adozione ufficiale del nuovo formato
> > .qgz,
> > letto solo dalla 3.4 e non dalla 2.18, stavo ragionando se fosse il caso
> o
> > meno di convertire alcuni miei progetti più importanti al nuovo formato.
> > Questi progetti sono realizzati con la 2.18 e la conversione
> comporterebbe
> > la conversione/importazione anche dei vari layout di stampa.
> >
> > Secondo voi mi conviene? Potrei riscontrare incompatibilità nei tematismi
> > e
> > nei layout di stampa se faccio un semplice "Save as"?
> >
> > Alla faccenda della conversione associo anche un problema che ho
> > riscontrato
> > già da un po'.
> >
> > Ho un progetto molto importante e particolare che quando finirà vedrà
> > mappati 320 villaggi francesi. La particolarità sta nel fatto che non
> > posso
> > usare l'Atlas perchè ogni villaggio deve per forza essere impaginato a
> > mano
> > perchè, per tutta una serie di lunghissimi motivi che non vi sto a
> > spiegare,
> > non può essere centrato in automatico; ad esempio spesse volte l'area di
> > interesse rispetto all'area di stampa è molto decentrata e deve essere
> > necessariamente così per non perdere particolari ed importanti
> riferimenti
> > esterni al focus. A questo si aggiunge che in funzione dell'estensione
> > dell'area focus ho almeno tre formati di stampa da A0 ad A2...
> >
> > Fatta questa premessa vengo al problema. Già ora che siamo ad una 50ina
> di
> > villaggi sono costretto a creare almeno un paio di file progetto che si
> > differenziano tra loro solo per i layout di stampa perchè l'avvio del
> > progetto ha dei tempi davvero biblici. In un primo momento pensavo
> > dipendesse dal db PostGIS su cui si poggia il progetto ma ho notato che
> > non
> > è così perchè riducendo i layout di stampa i tempi di apertura si
> riducono
> > pesantemente. Ho un progetto con quattro layout e gli stessissimi layer
> > degli altri e si apre in pochissimo tempo...secondi.
> >
> > Secondo voi esiste un modo per alleggerire il caricamento di un progetto
> > con
> > molto layout?
> > Prevedo che alla fine avrò almeno 20 file progetto che avranno gli stessi
> > dati da gestire e che si differenzieranno solo per i layout di stampa.
> > Metti
> > caso che per un qualche motivo un solo vettore deve essere sostituito o
> > inserito, non solo sarò costretto ad aggiornare uno per uno tutti e venti
> > i
> > progetti ma anche tutti e 320 layout di stampa.mi viene l'ansia solo
> a
> > pensarci! Avete consigli?
>
> Ciao Massimiliano,
> esiste una ML dedicata solo a QGIS, qui potrebbero non rispondere alcune
> persone.
>
> il formato .qgz è nato nella 3.0 anche se usato opzionalmente; è diventano
> il nuovo formato dalla 3.2 in poi.
>
> L'aggiornamento dei file di progetto verso le nuove versione è caldamente
> suggerito dagli sviluppatori  e non dovrebbe accadere nulla per un salto di
> una versione, nel tuo caso si parla di un salto da 2.18 a 3.4, cioè un
> salto
> triplo: se hai usato tematizzazioni particolari e layout particolari
> potresti avere delle brutte sorprese, anche perché il compositore di stampe
> è stato totalmente riscritto nella 3.x.
>
> Per quanto riguarda il tuo progetto in QGIS 2.18:
> se devi completare il lavoro senza la necessità di usare le nuove feature
> delle nuove versioni, ti consiglierei di proseguire utilizzando la 2.18; la
> 2.18 non sarà più supportata da gen 2019, ma questo non significa che non
> funzionerà più. Quindi puoi completare il tuo progetto utilizzando sempre
> la
> 2.18.
>
> Per quanto riguarda il tempo di apertura di QGIS con layout grossi, è un
> problema noto.
>
> saluti
>
> -
> https://pigrecoinfinito.wordpress.com/
> --
> Sent from:
> http://gfoss-geographic-free-and-open-source-software-italian-mailing.3056002.n2.nabble.com/
> ___
> Gfoss@lists.gfoss.it
> http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
> Questa e' una lista di discussione pubblica aperta a tutti.
> I messaggi di questa lista non hanno relazione diretta con le posizioni
> dell'Associazione GFOSS.it.
> 796 iscritti al 28/12/2017
___
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni 
dell'Associazione GFOSS.it.
796 iscritti al 28/12/2017

Re: [Gfoss] File progetto QGIS

2018-11-03 Per discussione Massimiliano Moraca
Io e le mie domande da un milione di euro 

-
Ingegnere, consulente GIS e ciclista urbano
--
Sent from: 
http://gfoss-geographic-free-and-open-source-software-italian-mailing.3056002.n2.nabble.com/
___
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni 
dell'Associazione GFOSS.it.
796 iscritti al 28/12/2017

Re: [Gfoss] File progetto QGIS

2018-11-02 Per discussione Massimiliano Moraca
Eh eh pure hai ragione ma sono abituato a prevenire :P

Hai consigli per la questione dei layout?

Il giorno ven 2 nov 2018 alle ore 22:41 Marco Spaziani <
spaziani.ma...@gmail.com> ha scritto:

> Leggendo qui
> https://www.qgis.org/it/site/getinvolved/development/roadmap.html
> a me sembra che la mitica LTR 2.18 sarà viva e lotterà insieme a noi
> ancora per qualche mese, fino al 22 febbraio 2019, quando passerà il
> testimone alla 3.4 ...quindi il tuo "problema", per quanto fondato, al
> momento è rimandato ...perchè preoccuparci oggi dei problemi di domani?
> ..." ...*Non affannatevi dunque per il domani, perché il domani avrà già
> le sue inquietudini. A ciascun giorno basta la sua pena.*" Matteo,
> 6,25-34 ...   ;-)   ...e di   ...stò a scherzà!   ;-)
>
> Il giorno ven 2 nov 2018 alle ore 18:32 Massimiliano Moraca <
> massimilianomor...@gmail.com> ha scritto:
>
>> Salve a tutti!
>> Con l'uscita della nuova LTR e l'adozione ufficiale del nuovo formato
>> .qgz,
>> letto solo dalla 3.4 e non dalla 2.18, stavo ragionando se fosse il caso o
>> meno di convertire alcuni miei progetti più importanti al nuovo formato.
>> Questi progetti sono realizzati con la 2.18 e la conversione comporterebbe
>> la conversione/importazione anche dei vari layout di stampa.
>>
>> Secondo voi mi conviene? Potrei riscontrare incompatibilità nei tematismi
>> e
>> nei layout di stampa se faccio un semplice "Save as"?
>>
>> Alla faccenda della conversione associo anche un problema che ho
>> riscontrato
>> già da un po'.
>>
>> Ho un progetto molto importante e particolare che quando finirà vedrà
>> mappati 320 villaggi francesi. La particolarità sta nel fatto che non
>> posso
>> usare l'Atlas perchè ogni villaggio deve per forza essere impaginato a
>> mano
>> perchè, per tutta una serie di lunghissimi motivi che non vi sto a
>> spiegare,
>> non può essere centrato in automatico; ad esempio spesse volte l'area di
>> interesse rispetto all'area di stampa è molto decentrata e deve essere
>> necessariamente così per non perdere particolari ed importanti riferimenti
>> esterni al focus. A questo si aggiunge che in funzione dell'estensione
>> dell'area focus ho almeno tre formati di stampa da A0 ad A2...
>>
>> Fatta questa premessa vengo al problema. Già ora che siamo ad una 50ina di
>> villaggi sono costretto a creare almeno un paio di file progetto che si
>> differenziano tra loro solo per i layout di stampa perchè l'avvio del
>> progetto ha dei tempi davvero biblici. In un primo momento pensavo
>> dipendesse dal db PostGIS su cui si poggia il progetto ma ho notato che
>> non
>> è così perchè riducendo i layout di stampa i tempi di apertura si riducono
>> pesantemente. Ho un progetto con quattro layout e gli stessissimi layer
>> degli altri e si apre in pochissimo tempo...secondi.
>>
>> Secondo voi esiste un modo per alleggerire il caricamento di un progetto
>> con
>> molto layout?
>> Prevedo che alla fine avrò almeno 20 file progetto che avranno gli stessi
>> dati da gestire e che si differenzieranno solo per i layout di stampa.
>> Metti
>> caso che per un qualche motivo un solo vettore deve essere sostituito o
>> inserito, non solo sarò costretto ad aggiornare uno per uno tutti e venti
>> i
>> progetti ma anche tutti e 320 layout di stampa.mi viene l'ansia solo a
>> pensarci! Avete consigli?
>>
>> -
>> Ingegnere, consulente GIS e ciclista urbano
>> --
>> Sent from:
>> http://gfoss-geographic-free-and-open-source-software-italian-mailing.3056002.n2.nabble.com/
>> ___
>> Gfoss@lists.gfoss.it
>> http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
>> Questa e' una lista di discussione pubblica aperta a tutti.
>> I messaggi di questa lista non hanno relazione diretta con le posizioni
>> dell'Associazione GFOSS.it.
>> 796 iscritti al 28/12/2017
>
>
___
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni 
dell'Associazione GFOSS.it.
796 iscritti al 28/12/2017

[Gfoss] File progetto QGIS

2018-11-02 Per discussione Massimiliano Moraca
Salve a tutti!
Con l'uscita della nuova LTR e l'adozione ufficiale del nuovo formato .qgz,
letto solo dalla 3.4 e non dalla 2.18, stavo ragionando se fosse il caso o
meno di convertire alcuni miei progetti più importanti al nuovo formato.
Questi progetti sono realizzati con la 2.18 e la conversione comporterebbe
la conversione/importazione anche dei vari layout di stampa. 

Secondo voi mi conviene? Potrei riscontrare incompatibilità nei tematismi e
nei layout di stampa se faccio un semplice "Save as"?

Alla faccenda della conversione associo anche un problema che ho riscontrato
già da un po'.

Ho un progetto molto importante e particolare che quando finirà vedrà
mappati 320 villaggi francesi. La particolarità sta nel fatto che non posso
usare l'Atlas perchè ogni villaggio deve per forza essere impaginato a mano
perchè, per tutta una serie di lunghissimi motivi che non vi sto a spiegare,
non può essere centrato in automatico; ad esempio spesse volte l'area di
interesse rispetto all'area di stampa è molto decentrata e deve essere
necessariamente così per non perdere particolari ed importanti riferimenti
esterni al focus. A questo si aggiunge che in funzione dell'estensione
dell'area focus ho almeno tre formati di stampa da A0 ad A2...

Fatta questa premessa vengo al problema. Già ora che siamo ad una 50ina di
villaggi sono costretto a creare almeno un paio di file progetto che si
differenziano tra loro solo per i layout di stampa perchè l'avvio del
progetto ha dei tempi davvero biblici. In un primo momento pensavo
dipendesse dal db PostGIS su cui si poggia il progetto ma ho notato che non
è così perchè riducendo i layout di stampa i tempi di apertura si riducono
pesantemente. Ho un progetto con quattro layout e gli stessissimi layer
degli altri e si apre in pochissimo tempo...secondi.

Secondo voi esiste un modo per alleggerire il caricamento di un progetto con
molto layout?
Prevedo che alla fine avrò almeno 20 file progetto che avranno gli stessi
dati da gestire e che si differenzieranno solo per i layout di stampa. Metti
caso che per un qualche motivo un solo vettore deve essere sostituito o
inserito, non solo sarò costretto ad aggiornare uno per uno tutti e venti i
progetti ma anche tutti e 320 layout di stampa.mi viene l'ansia solo a
pensarci! Avete consigli?

-
Ingegnere, consulente GIS e ciclista urbano
--
Sent from: 
http://gfoss-geographic-free-and-open-source-software-italian-mailing.3056002.n2.nabble.com/
___
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni 
dell'Associazione GFOSS.it.
796 iscritti al 28/12/2017

Re: [Gfoss] Centroidi di poligoni concavi

2018-11-02 Per discussione Massimiliano Moraca
Ragazzi ecco lo scopo della mia richiesta di stamattina[0]. Dovevo fare uno
spatial join preciso e nel mio caso il solo ST_Centroid non andava bene. Ne
ho approfittato e anche grazie alle vostre indicazioni ho fatto un piccolo
video al volo. Spero sia gradito ed utile.

PS: siete nei credits :)


[0] https://youtu.be/7g4kMoEySH8

-
Ingegnere, consulente GIS e ciclista urbano
--
Sent from: 
http://gfoss-geographic-free-and-open-source-software-italian-mailing.3056002.n2.nabble.com/
___
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni 
dell'Associazione GFOSS.it.
796 iscritti al 28/12/2017

Re: [Gfoss] Centroidi di poligoni concavi

2018-11-02 Per discussione Massimiliano Moraca
Grazie per la precisazione :)

Il giorno ven 2 nov 2018 alle ore 13:38 Ivano  ha
scritto:

> Ciao,
> non è una ricentratura,
>
> ST_PointOnSurface()e ST_Centroid() sono di genere punti diversi, anche su
> poligoni convessi.
>
> Ivano
>
> --
> Sent from:
> http://gfoss-geographic-free-and-open-source-software-italian-mailing.3056002.n2.nabble.com/
> ___
> Gfoss@lists.gfoss.it
> http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
> Questa e' una lista di discussione pubblica aperta a tutti.
> I messaggi di questa lista non hanno relazione diretta con le posizioni
> dell'Associazione GFOSS.it.
> 796 iscritti al 28/12/2017
___
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni 
dell'Associazione GFOSS.it.
796 iscritti al 28/12/2017

Re: [Gfoss] Centroidi di poligoni concavi

2018-11-02 Per discussione Massimiliano Moraca
Grazie mille a tutti, alla fine ho usato ST_PointOnSurface ed ho notato che
vengono ricentrati anche i centroidi che cadono dentro il poligono e
generati da ST_Centroid.

Nell'immagine che vedete i punti verdi sono quelli posizionati da
ST_PointOnSurface  mentre i blu sono quelli di ST_Centroid.


 

-
Ingegnere, consulente GIS e ciclista urbano
--
Sent from: 
http://gfoss-geographic-free-and-open-source-software-italian-mailing.3056002.n2.nabble.com/
___
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni 
dell'Associazione GFOSS.it.
796 iscritti al 28/12/2017

Re: [Gfoss] Centroidi di poligoni concavi

2018-11-02 Per discussione Massimiliano Moraca
Come così?

 point_on_surface( ST_Centroid( $geometry ) )

Non torno al pc prima di qualche ora e non posso quindi verificare...

Il giorno ven 2 nov 2018 alle ore 09:18 Marco Spaziani <
spaziani.ma...@gmail.com> ha scritto:

> Prova con calcolatore di campi usando la funzione:
>  point_on_surface(  $geometry )
>
> Il giorno ven 2 nov 2018 alle ore 08:55 Massimiliano Moraca <
> massimilianomor...@gmail.com> ha scritto:
>
>> Buongiorno a tutti!
>>
>> Devo generare con PostGIS i centroidi di alcuni poligoni, una parte di
>> essi
>> sono estremamente concavi per cui il centroide ricade all'esterno del
>> poligono "padre". Con QGIS risolvo la questione con il plugin
>> realcentroids
>> ma volendo fare questo in PostGIS la sola funzione ST_Centroid non basta.
>>
>> Mi sapete dire se è possibile forzarla a generare il punto all'interno del
>> poligono padre?
>> Se ci sono altre alternative proponete pure :)
>>
>> -
>> Ingegnere, consulente GIS e ciclista urbano
>> --
>> Sent from:
>> http://gfoss-geographic-free-and-open-source-software-italian-mailing.3056002.n2.nabble.com/
>> ___
>> Gfoss@lists.gfoss.it
>> http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
>> Questa e' una lista di discussione pubblica aperta a tutti.
>> I messaggi di questa lista non hanno relazione diretta con le posizioni
>> dell'Associazione GFOSS.it.
>> 796 iscritti al 28/12/2017
>
>
___
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni 
dell'Associazione GFOSS.it.
796 iscritti al 28/12/2017

[Gfoss] Centroidi di poligoni concavi

2018-11-02 Per discussione Massimiliano Moraca
Buongiorno a tutti!

Devo generare con PostGIS i centroidi di alcuni poligoni, una parte di essi
sono estremamente concavi per cui il centroide ricade all'esterno del
poligono "padre". Con QGIS risolvo la questione con il plugin realcentroids
ma volendo fare questo in PostGIS la sola funzione ST_Centroid non basta.

Mi sapete dire se è possibile forzarla a generare il punto all'interno del
poligono padre?
Se ci sono altre alternative proponete pure :)

-
Ingegnere, consulente GIS e ciclista urbano
--
Sent from: 
http://gfoss-geographic-free-and-open-source-software-italian-mailing.3056002.n2.nabble.com/
___
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni 
dell'Associazione GFOSS.it.
796 iscritti al 28/12/2017

[Gfoss] Rete dei sottoservizi: quadro normativo

2018-10-10 Per discussione Massimiliano Moraca
Predendo spunto da un bando a cui ho partecipato, spero di fare cosa gradita
con il quadro normativo per la rete dei sottoservizi.

Qui l'articolo
  

Come ho scritto nell'articolo, se ho dimenticato qualcosa segnalatemelo

-
Ingegnere, consulente GIS e ciclista urbano
--
Sent from: 
http://gfoss-geographic-free-and-open-source-software-italian-mailing.3056002.n2.nabble.com/
___
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni 
dell'Associazione GFOSS.it.
796 iscritti al 28/12/2017

Re: [Gfoss] Un ottimo motivo per imparare a usare dati copernicus/sentinel...

2018-09-20 Per discussione Massimiliano Moraca
Forse sono andato un po' off topic ma quello che intendevo dire in quella
newsletter ruota intorno al fatto che, purtroppo, non è per nulla scontato
che non si possano usare dati Google. Te lo dico per esperienza personale.
Tantissimi tecnici in Italia per le loro relazioni usano dati proprietari
come quelli di Google Maps o Bing.
Con la nuova normativa sul copyright probabilmente ci saranno molti più
controlli ed il nesso con la sentenza del TAR del Lazio personalmente ce lo
vedo. L'assunto della sentenza del TAR è la stessa faccia della medaglia
dell'uso, in violazione delle licenze, dei dati cartografici di Google Inc.
e Microsoft.
In Italia è purtroppo ampiamente diffuso questo malcostume.



Il giorno gio 20 set 2018 alle ore 17:12 stefano campus 
ha scritto:

> perdonami massimiliano, ma non capisco che cosa c'entri la nuova normativa
> con le immagini di google.
> è ben evidente che non potevi utilizzare gli sfondi di google maps ad uso
> commerciale cioè a dire, vendere servizi basati su quella fonte
> informativa.
> era già così da prima: che cosa cambia ora?
>
> s.
>
> --
> Sent from:
> http://gfoss-geographic-free-and-open-source-software-italian-mailing.3056002.n2.nabble.com/
> ___
> Gfoss@lists.gfoss.it
> http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
> Questa e' una lista di discussione pubblica aperta a tutti.
> I messaggi di questa lista non hanno relazione diretta con le posizioni
> dell'Associazione GFOSS.it.
> 796 iscritti al 28/12/2017
___
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni 
dell'Associazione GFOSS.it.
796 iscritti al 28/12/2017

Re: [Gfoss] Un ottimo motivo per imparare a usare dati copernicus/sentinel...

2018-09-20 Per discussione Massimiliano Moraca
Dei servizi Google ne parlavo proprio la scorsa settimana in una mia
newsletter agli iscritti del mio blog in funzione della nuova direttiva sul
copyright.
Vi copio qui il testo che magari può essere utile alla discussione:

La direttiva sul copyright
> 
>  è
> stata approvata ed ora parte la negoziazione tra gli Stati membri. 
> *Personalmente
> la ritengo un'autogoal ed un primo passo verso il blocco della diffusione
> della conoscenza in maniera equa e democratica che, nel bene e nel male, ha
> permesso internet in questi anni; spero quindi che in fase di negoziazione
> salti.*
>
> Se dovesse passare definitivamente, i risvolti negativi sarebbero tanti
> anche per il quotidiano e soprattutto per noi professionisti.
>
> *Mi aspetto infatti da parte di Google, Microsoft, Facebook e gli altri
> colossi mondiali, che adottino un cambiamento di rotta sull'atteggiamento
> fin'ora molto permissivo sull'uso dei loro servizi. *
> Ad esempio è comune in campo cartografico, ma più in generale in campo
> architettonico/ingegneristico, vedere progetti presentati con l'utilizzo di
> immagini prese da Google Maps, Google Earth
>  o Bing
>  Maps
> .
>
> *In pochi sanno che non è possibile fare un uso commerciale di quelle
> immagini poichè se ne viola la licenza, quindi il copyright.* Le policy
> di utilizzo di quei dati sono ben in vista ma molto spesso si fa finta di
> non vederle. Quelle immagini si possono usare fintanto che non escono dal
> pc/smartphone/tablet che le ha copiate.
>
> Come dicevo, fin'ora, questi grandi colossi mondiali non hanno dato tanto
> peso all'uso in violazione del copyright che spesso viene fatto dei loro
> dati. Con questa direttiva mi aspetto un irrigidimento da parte loro e
> quindi chi ancora usa i loro dati non rispettando la licenza d'uso farebbe
> bene a fare ancora più attenzione. *Le immagini satellitari ed i modelli
> 3D hanno un costo, queste aziende investono per produrre quei dati, quindi
> è giusto che ti chiedano un congruo compenso o agiscano per vie legali
> verso coloro che non rispettano il copyright.*
>
> Devi sapere che ci sono piattaforme satellitari pubbliche e private che
> vendono a caro prezzo kmq di immagini telerilevate con risoluzione spaziale
> anche al di sotto dei 50cm, come quelle di Bing per esempio. L'utilizzo di
> questo tipo di dati ha un costo e non sono affatto economiche.
>
> Guardando il listino di uno dei concessionari per le piattaforme
> World-View ,
> ipotizziamo di avere bisogno di immagini satellitari RGB(*la classica
> immagine satellitare alla Google Maps per intenderci*), recenti, di un
> certo territorio che ha una estensione di 50 kmq.
> Il servizio di distribuzione di immagini telerilevate prevede il pagamento
> di una quota di 27.50$ al kmq per un'area di estensione minima pari a 100
> kmq. Quindi i costi sarebbero pari a 2750$, quasi 2400€ al cambio corrente.


Saluti

Il giorno gio 20 set 2018 alle ore 15:57 Roberto Marzocchi <
roberto.marzoc...@gter.it> ha scritto:

> Il problema non banale è che la massima risoluzione di sentinel arriva al
> massimo a ~ 10 m. Dopodichè esistono dati satellitari a pagamento con
> risoluzioni molto più alte R Eng. Roberto Marzocchi, PhD
> GIS Project Coordinator
> Gter srl (Unige spin-off)
> Piazza De Marini 3/61 - 16123 Genova
> P.IVA/CF 01998770992
> ph: 010-8694830 - mob: 349-8786575
> E-mail: roberto.marzoc...@gter.it
> skype: roberto.marzocchi84
> www.gter.it
>
> --
> Gter social
> www.twitter.com/Gteronline - www.facebook.com/Gteronline -
> https://plus.google.com/+GterIt/posts
> www.linkedin.com/company/gter-srl-innovazione-in-geomatica-gnss-e-gis
>
> -
> Please consider the environment before printing this email!  On gio,
> 20 set 2018 10:28:46 +0200 Amedeo Fadini  wrote  Eh
> grazie Marica mi è scappato il msg prima di ncoolare il link
> http://www.regione.veneto.it/web/ambiente-e-territorio/news-urbjus Amefad
> Il giorno gio 20 set 2018 alle ore 10:19 Marica Landini <
> bu...@ferrara.linux.it> ha scritto: > Puoi mettere un collegamento alla:
> articolo? > Grazie. > Saluti, > Marica > > Il gio 20 set 2018, 10:10 Amedeo
> Fadini  ha scritto: > >> ...litigare con gli enti
> locali! >> Un aritcolo della rassegna giuridica di Regione Veneto ricorda
> che le foto >> di google earth non sono probatorie dello stato dei luoghi
> per la >> giustizia >> amministrativa >> >> Amefad >>
> ___ >> Gfoss@lists.gfoss.it
> >> http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss >> Questa e' una
> lista di discussione pubblica aperta a tutti. >> 

Re: [Gfoss] Manager di database multi piattaforma e multi formato

2018-09-05 Per discussione Massimiliano Moraca
Dietro consiglio di Amedeo Fadini l'ho provato e lo trovo molto utile

Il giorno mer 5 set 2018 alle ore 20:26 Amedeo Fadini  ha
scritto:

> L'ho provato è molto utile perché aiuta anche a creare lo scehma del DB a
> partire da un db esistente...
>
> Amefad
>
> Il giorno mer 5 set 2018 alle ore 20:09 stefano campus 
> ha scritto:
>
> > ciao a tutt@,
> > condivido la segnalazione di questo gestore di database multi
> piattaforma e
> > multi formato:
> > MySQL, PostgreSQL, MariaDB, SQLite, Oracle, DB2, SQL Server, Sybase, MS
> > Access, Teradata, Firebird, Derby, ecc.
> >
> > rilasciato con licenza apache
> >
> > https://dbeaver.io/
> >
> > s.
> >
> > --
> > Sent from:
> >
> http://gfoss-geographic-free-and-open-source-software-italian-mailing.3056002.n2.nabble.com/
> > ___
> > Gfoss@lists.gfoss.it
> > http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
> > Questa e' una lista di discussione pubblica aperta a tutti.
> > I messaggi di questa lista non hanno relazione diretta con le posizioni
> > dell'Associazione GFOSS.it.
> > 796 iscritti al 28/12/2017
> ___
> Gfoss@lists.gfoss.it
> http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
> Questa e' una lista di discussione pubblica aperta a tutti.
> I messaggi di questa lista non hanno relazione diretta con le posizioni
> dell'Associazione GFOSS.it.
> 796 iscritti al 28/12/2017
___
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni 
dell'Associazione GFOSS.it.
796 iscritti al 28/12/2017

Re: [Gfoss] test

2018-09-05 Per discussione Massimiliano Moraca
Ora funziona

Il giorno mer 5 set 2018 alle ore 20:09 pigreco 
ha scritto:

> prova prova
> ho letto in giro che la lista non funziona
>
> saluti
>
> -
> https://pigrecoinfinito.wordpress.com/
> --
> Sent from:
> http://gfoss-geographic-free-and-open-source-software-italian-mailing.3056002.n2.nabble.com/
> ___
> Gfoss@lists.gfoss.it
> http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
> Questa e' una lista di discussione pubblica aperta a tutti.
> I messaggi di questa lista non hanno relazione diretta con le posizioni
> dell'Associazione GFOSS.it.
> 796 iscritti al 28/12/2017
___
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni 
dell'Associazione GFOSS.it.
796 iscritti al 28/12/2017

[Gfoss] DB geografico della rete dei sottoservizi

2018-09-05 Per discussione Massimiliano Moraca
Buonasera a tutti,
un paio di anni fa scrissi un articolo[0] su questo tema. A distanza di un
paio di anni sono cambiate le normative inerenti al tema rispetto a quelle
che ho menzionato nell'articolo?

Se si mi indichereste quali?

__
[0] http://massimilianomoraca.it/blog/rete-dei-sottoservizi-un-gis/

-
Ingegnere, consulente GIS e ciclista urbano
--
Sent from: 
http://gfoss-geographic-free-and-open-source-software-italian-mailing.3056002.n2.nabble.com/
___
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni 
dell'Associazione GFOSS.it.
796 iscritti al 28/12/2017

  1   2   3   >