On Sun, 20 May 2012 12:43:59 +0200, Antonio Falciano wrote:
><i> grazie per averci fatto notare la cosa.
</i>><i> A mio modesto avviso, e' una cialtroneria questa. La definizione
</i>><i> rigorosa di EPSG:3003-4 non prevede l'uso dei parametri +towgs84
</i>>
Concordo pienamente.
Questa cosa e' un gran casino.
Ora un utente non sa piu' se e che parametri impostare.
Oltretutto come viene confermato a questo thread,
[http://lists.maptools.org/pipermail/proj/2009-March/004480.html](http://lists.maptools.org/pipermail/proj/2009-March/004480.html)
la ProJ , per definizione, non applica mai una trasformazione towgs.
Andrea Peri
Il 20/05/2012 19:55, Andrea Peri ha scritto:
la ProJ , per definizione, non applica mai una trasformazione towgs.
potete per cortesia segnalare la cosa come ticket di proj?
gia' che ci siamo, non sarebbe male introdurre i codici (extra EPSG, >40000) per le
varie correzioni +towgs, cosi' abbiamo sia il dato buono che quello piu' utilizzabile.
grazie.
--
Paolo Cavallini - Faunalia
www.faunalia.eu
Full contact details at www.faunalia.eu/pc
L’hosting a disposizione per il mio sito web supporta anche database PostgresSQL.
L’assistenza mi ha risposto che volendo potrebbero loro stessi aggiungere PostGIS al server.
La mia necessità sarebbe quella di pubblicare dati vettoriali sul web sfruttando openlayers.
Cosa dovrebbe supportare il server per fare ciò?
Vito borneo
Il 21/05/2012 10:09, Vito Borneo ha scritto:
L'hosting a disposizione per il mio sito web supporta anche database PostgresSQL.
L'assistenza mi ha risposto che volendo potrebbero loro stessi aggiungere PostGIS al
server.
Disponibilita' non comune, complimenti.
La mia necessità sarebbe quella di pubblicare dati vettoriali sul web sfruttando
openlayers.
Cosa dovrebbe supportare il server per fare ciò?
Niente di speciale, mi pare.
Saluti.
--
Paolo Cavallini - Faunalia
www.faunalia.eu
Full contact details at www.faunalia.eu/pc
Quindi non devo chiedere aggiunta di nient’altro, tipo Mapfish o Geoserver?
Vito
Da: Paolo Cavallini cavallini@faunalia.it
A: gfoss@lists.gfoss.it
Inviato: Lunedì 21 Maggio 2012 10:09
Oggetto: Re: [Gfoss] Consiglio PostgresSQL + Postgis + …
Il 21/05/2012 10:09, Vito Borneo ha scritto:
L’hosting a disposizione per il mio sito web supporta anche database PostgresSQL.
L’assistenza mi ha risposto che volendo potrebbero loro stessi aggiungere PostGIS al
server.
Disponibilita’ non comune, complimenti.
La mia necessità sarebbe quella di pubblicare dati vettoriali sul web sfruttando
openlayers.
Cosa dovrebbe supportare il server per fare ciò?
Niente di speciale, mi pare.
Saluti.
–
Paolo Cavallini - Faunalia
www.faunalia.eu
Full contact details at www.faunalia.eu/pc
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e’ una lista di discussione pubblica aperta a tutti.
Non inviate messaggi commerciali.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell’Associazione GFOSS.it.
584 iscritti al 7.4.2012
per pubblicare dati vettoriali di postgis con openlayers ti manca un componente che esponga i dati in formato raster (applicando una vestizione) oppure in vettoriale, sempre che siano pochi elementi.
componenti tipo mapserver o geoserver o degree, comunque strumenti lato server.
saluti,
francesco
Il giorno 21 maggio 2012 10:09, Vito Borneo <vitoborneo@yahoo.it> ha scritto:
L’hosting a disposizione per il mio sito web supporta anche database PostgresSQL.
L’assistenza mi ha risposto che volendo potrebbero loro stessi aggiungere PostGIS al server.
La mia necessità sarebbe quella di pubblicare dati vettoriali sul web sfruttando openlayers.
Cosa dovrebbe supportare il server per fare ciò?
Vito borneo
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e’ una lista di discussione pubblica aperta a tutti.
Non inviate messaggi commerciali.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell’Associazione GFOSS.it.
584 iscritti al 7.4.2012
Il 21/05/2012 10:33, francesco marucci ha scritto:
per pubblicare dati vettoriali di postgis con openlayers ti manca un componente che
esponga i dati in formato raster (applicando una vestizione) oppure in vettoriale,
sempre che siano pochi elementi.
componenti tipo mapserver o geoserver o degree, comunque strumenti lato server.
ah, beh, certo, scusa ma lo davo per scontato.
considera che c'e' anche QGIS Server, sia WMS che WFS.
Saluti.
--
Paolo Cavallini - Faunalia
www.faunalia.eu
Full contact details at www.faunalia.eu/pc
2012/5/21 francesco marucci <francesco.marucci@gmail.com>:
per pubblicare dati vettoriali di postgis con openlayers ti manca un
componente che esponga i dati in formato raster (applicando una vestizione)
oppure in vettoriale, sempre che siano pochi elementi.
componenti tipo mapserver o geoserver o degree, comunque strumenti lato
server.
C'e' peraltro una vasta casistica di esposizione di dati vettoriali
via web in cui un map server potrebbe non essere necessario.
Penso soprattutto a web application location based con feature
geografiche rappresentate da elementi puntuali.
Ad esempio si puo' alimentare un layer vettoriale di OpenLayers
direttamente da PostGIS usando fomati quali GeoJson/GeoRSS/GML/KML.
A tal fine si possono usare framework quali il citato MapFish o
GeoDjango, che sono il piu' delle volte facilmente installabili
dall'utente sul web server senza ricorrere all'assistenza.
ciao
p
--
Paolo Corti
Geospatial software developer
web: http://www.paolocorti.net
twitter: @capooti
skype: capooti
Infatti, volevo pubblicare qualcosa di più complesso rispetto ad un xml, kml che è possibile
inserire direttamente in un database mysql
https://developers.google.com/kml/articles/phpmysqlkml?hl=nl
Vito
Da: Paolo Corti pcorti@gmail.com
A: francesco marucci francesco.marucci@gmail.com
Cc: “gfoss@lists.gfoss.it” gfoss@lists.gfoss.it
Inviato: Lunedì 21 Maggio 2012 11:04
Oggetto: Re: [Gfoss] Consiglio PostgresSQL + Postgis + …
2012/5/21 francesco marucci <francesco.marucci@gmail.com>:
per pubblicare dati vettoriali di postgis con openlayers ti manca un
componente che esponga i dati in formato raster (applicando una vestizione)
oppure in vettoriale, sempre che siano pochi elementi.
componenti tipo mapserver o geoserver o degree, comunque strumenti lato
server.
C’e’ peraltro una vasta casistica di esposizione di dati vettoriali
via web in cui un map server potrebbe non essere necessario.
Penso soprattutto a web application location based con feature
geografiche rappresentate da elementi puntuali.
Ad esempio si puo’ alimentare un layer vettoriale di OpenLayers
direttamente da PostGIS usando fomati quali GeoJson/GeoRSS/GML/KML.
A tal fine si possono usare framework quali il citato MapFish o
GeoDjango, che sono il piu’ delle volte facilmente installabili
dall’utente sul web server senza ricorrere all’assistenza.
ciao
p
–
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.
Non inviate messaggi commerciali.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell’Associazione GFOSS.it.
584 iscritti al 7.4.2012
QGIS server sarebbe davvero l’ideale, soprattutto perchè conoscendo Qgis desktop,
si tratterebbe solo di copiare il file di progetto sul server…
vito
Da: Paolo Cavallini cavallini@faunalia.it
A: gfoss@lists.gfoss.it
Inviato: Lunedì 21 Maggio 2012 10:33
Oggetto: Re: [Gfoss] Consiglio PostgresSQL + Postgis + …
Il 21/05/2012 10:33, francesco marucci ha scritto:
per pubblicare dati vettoriali di postgis con openlayers ti manca un componente che
esponga i dati in formato raster (applicando una vestizione) oppure in vettoriale,
sempre che siano pochi elementi.
componenti tipo mapserver o geoserver o degree, comunque strumenti lato server.
ah, beh, certo, scusa ma lo davo per scontato.
considera che c’e’ anche QGIS Server, sia WMS che WFS.
Saluti.
–
Paolo Cavallini - Faunalia
www.faunalia.eu
Full contact details at www.faunalia.eu/pc
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e’ una lista di discussione pubblica aperta a tutti.
Non inviate messaggi commerciali.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell’Associazione GFOSS.it.
584 iscritti al 7.4.2012
Giusto qualche noiosissimo dettaglio tecnico preliminare, visto che
si tratta di aspetti sicuramente poco noti, per quanto assolutamente
critici:
a) tutte le operazioni di conversione tra diversi SRS (riproiezione)
dipendono dalle Proj4, e quindi in ultima analisi dal file delle
definizioni EPSG che accompagna ciascuna release delle Proj4
b) la catena delle dipendenze che si dirama dal file delle definizioni
EPSG e' molto articolata: GDAL, GeoTiff, Proj4, QGIS, PostGIS,
SpatiaLite etc etc; tutti dipendono dalle EPSG in un modo o nell'altro.
per evitare risultati incongruenti, e' auspicabile che tutti i vari
progetti seguano regole comuni assolutamente consistenti.
c) anche se e' del tutto controintuitivo, il file delle definizioni
EPSG non nasce affatto dalle Proj4; al contrario, le Proj4 sono
semplicemente il punto di arrivo finale del percorso. vedi:
http://svn.osgeo.org/metacrs/geotiff/trunk/libgeotiff/csv/README
d) in pratica una nuova versione del file EPSG nasce sempre in GDAL
- poi passa alle GeoTiff
- finalmente arriva alle Proj4
- ed infine tocca le varie PostGIS, SpatiaLite, QIS etc etc
---------
visto che si tratta di aspetti delicati al massimo, che tagliano
trasversalmente tutti i progetti e che interessano intere nazioni
(p.es. nel caso del Gauss-Boaga tutta l'Italia), sarebbe auspicabile
che qualsiasi eventuale modifica venisse unanimemente condivisa
dall'intera community nazionale, previo adeguato confronto e
discussione.
propongo quindi di chiudere qua questo thread, aprendone un altro
finalizzato alla discussione sulle modifiche/patch/ticket da sottoporre
ai maintainers di GDAL (visto che e' li il vero punto di partenza).
ciao Sandro
--
Il messaggio e' stato analizzato alla ricerca di virus o
contenuti pericolosi da MailScanner, ed e'
risultato non infetto.
Il 21/05/2012 11:27, Vito Borneo ha scritto:
QGIS server sarebbe davvero l'ideale, soprattutto perchè conoscendo Qgis desktop,
si tratterebbe solo di copiare il file di progetto sul server...
infatti: e con il plugin di 3liz, puoi fare tutto in automatico.
saluti.
--
Paolo Cavallini - Faunalia
www.faunalia.eu
Full contact details at www.faunalia.eu/pc
On Mon, May 21, 2012 at 09:53:04AM +0200, Paolo Cavallini wrote:
Il 20/05/2012 19:55, Andrea Peri ha scritto:
> la ProJ , per definizione, non applica mai una trasformazione towgs.
potete per cortesia segnalare la cosa come ticket di proj?
gia' che ci siamo, non sarebbe male introdurre i codici (extra EPSG, >40000) per le
varie correzioni +towgs, cosi' abbiamo sia il dato buono che quello piu' utilizzabile.
grazie.
Sfortunatamente non è l'unico pasticcio introdotto in 4.8, ragion per cui è
opportuno evitarne in toto l'impiego.
--
Francesco P. Lovergine
On Mon, 21 May 2012 13:21:18 +0200, Francesco P. Lovergine wrote:
Sfortunatamente non è l'unico pasticcio introdotto in 4.8, ragion per cui è
opportuno evitarne in toto l'impiego.
Ciao Frakie,
potresti dettagliare ?
quali altre criticita' ti risultano con la Proj 4.8 ?
grazie Sandro
--
Il messaggio e' stato analizzato alla ricerca di virus o
contenuti pericolosi da MailScanner, ed e'
risultato non infetto.
On Mon, May 21, 2012 at 01:25:17PM +0200, a.furieri@lqt.it wrote:
On Mon, 21 May 2012 13:21:18 +0200, Francesco P. Lovergine wrote:
>Sfortunatamente non è l'unico pasticcio introdotto in 4.8, ragion
>per cui è
>opportuno evitarne in toto l'impiego.
>Ciao Frakie,
potresti dettagliare ?
quali altre criticita' ti risultano con la Proj 4.8 ?grazie Sandro
Pensavo fosse ormai ampiamente noto, quoto per esempio hamish_b in
un recente scambio con lui in merito:
pps- AFAIK proj 1.8.0's epsg file makes a big problem for GRASS,
QGIS, and others as it has removed all the +datum= terms and
replaced them with +towgs84= coefficients. Default transform
terms are nice, but mandating that everyone use that specific
set of terms with no way out (since the datum name was removed)
is a bit of a disaster! at least for us in New Zealand where
we have a lot of distortion and the NTv2 datum transform grid
is very important. This is still unresolved, and so I have been
happy to see that proj 1.8.0 has not yet entered sid, as it
will cause bad problems for us (NZ,GRASS) once it does.
(Users of the Potsdam, OSGB36, and NAD27 etc. datums are affected
too..)
Quindi il casino sembra un po' più esteso della sola zona italiana...
Tra parentesi, si potrebbe pensare che ci siano gli estremi per una
violazione di licenza dei dati EPSG, che al punto 2 recita:
---
All data pertinent to a specific coordinate reference system MUST be copied
without modification and all related pages/records must be included;
---
Ergo a meno di non chiarire a chiare lettere che quei codici NON sono codici
EPSG, la 4.8 chiaramente non è distribuibile. Ovviamente AFAIK (and IANAL).
--
Francesco P. Lovergine
Il 21/05/2012 13:36, Francesco P. Lovergine ha scritto:
Pensavo fosse ormai ampiamente noto, quoto per esempio hamish_b in
immagino che ci siano gia' tickets aperti in proposito, giusto?
saluti.
--
Paolo Cavallini - Faunalia
www.faunalia.eu
Full contact details at www.faunalia.eu/pc
Il 21/05/2012 13:37, Paolo Cavallini ha scritto:
Il 21/05/2012 13:36, Francesco P. Lovergine ha scritto:
Pensavo fosse ormai ampiamente noto, quoto per esempio hamish_b in
immagino che ci siano gia' tickets aperti in proposito, giusto?
in ogni caso, dato che i parametri sono molto comodi, la strada giusta pare quella di
integrare gli EPSG con altre proiezioni ad hoc, per le quali ci sono codici riservati
(>40000).
dico bene?
saluti.
--
Paolo Cavallini - Faunalia
www.faunalia.eu
Full contact details at www.faunalia.eu/pc
On Mon, 21 May 2012 13:36:02 +0200, Francesco P. Lovergine wrote:
Pensavo fosse ormai ampiamente noto, quoto per esempio hamish_b in
un recente scambio con lui in merito:pps- AFAIK proj 1.8.0's epsg file makes a big problem for GRASS,
QGIS, and others as it has removed all the +datum= terms and
replaced them with +towgs84= coefficients.
ora finalmente mi e' assolutamente chiaro perche' ho dovuto rimettere
pesantemente le mani su un paio di funzioni SpatiaLite con la 4.8.
avevo capito che il problema era nel fatto che la definizione della
4326 WGS84 era cambiata all'improvviso [1], ma non avevo focalizzato
che il casino era cosi' ampio e generalizzato. 
[1]
4.7 4326: +proj=longlat +ellps=WGS84 +datum=WGS84 +no_defs
4.8 4326: +proj=longlat +datum=WGS84 +no_defs
Ergo a meno di non chiarire a chiare lettere che quei codici NON sono codici
EPSG, la 4.8 chiaramente non è distribuibile. Ovviamente AFAIK (and IANAL).
concordo pienamente: e' una roba completamente diversa, che con EPSG
ormai c'entra pochino ... e mi paiono molto fondate anche le tue
perplessita' legali.
personalmente direi che e' veramente una bruttissima regression;
il sw libero ha sempre goduto (giustamente) ottima fama proprio
perche' e' sempre stato assolutamente rigoroso nel rispetto maniacale
degli standard.
N.B.: non sottovalutiamo il problema; stiamo seriamente rischiando
che *tutte* le prossime versioni di GDAL, GeoTIFF, PostGIS, splite etc
utilizzino delle definizioni geodetiche quanto meno dubbie ...
e stiamo rischiando l'effetto babele, se ciascun progetto si muovera'
per proprio conto in autonomia e senza un chiaro coordinamento.
direi che l'unica soluzione sensata parrebbe rilasciare rapidamente
una Proj 4.8.1 che ripristini una totale conformita' con EPSG
ciao Sandro
--
Il messaggio e' stato analizzato alla ricerca di virus o
contenuti pericolosi da MailScanner, ed e'
risultato non infetto.
On Mon, May 21, 2012 at 01:40:02PM +0200, Paolo Cavallini wrote:
Il 21/05/2012 13:37, Paolo Cavallini ha scritto:
> Il 21/05/2012 13:36, Francesco P. Lovergine ha scritto:
>
>> Pensavo fosse ormai ampiamente noto, quoto per esempio hamish_b in
>
> immagino che ci siano gia' tickets aperti in proposito, giusto?in ogni caso, dato che i parametri sono molto comodi, la strada giusta pare quella di
integrare gli EPSG con altre proiezioni ad hoc, per le quali ci sono codici riservati
(>40000).
dico bene?
saluti.
Si, solo che i codici custom non sono standard e a quel punto chiunque può
adottare la convenzione che gli pare. Si arriva dritti dritti all'approccio
alla ESRI. Non solo secondo me non è il massimo, ma va in direzione opposta
a quello che andrebbe fatto in un mondo perfetto.
--
Francesco P. Lovergine
Il 21/05/2012 14:05, Francesco P. Lovergine ha scritto:
Si, solo che i codici custom non sono standard e a quel punto chiunque può
adottare la convenzione che gli pare. Si arriva dritti dritti all'approccio
alla ESRI. Non solo secondo me non è il massimo, ma va in direzione opposta
a quello che andrebbe fatto in un mondo perfetto.
capisco, ma non dare i parametri di correzione e' comunque un danno per gli utenti;
alternative?
saluti.
--
Paolo Cavallini - Faunalia
www.faunalia.eu
Full contact details at www.faunalia.eu/pc