[postgis-users] [Announce] New GISVM PostGIS and Geoserver releases available!
Dear PosGIS user, I'm pleased to announce the just released new versions of GISVM Geoserver and PostGIS. For more information please visit: http://www.gisvm.com WHAT'S NEW: - New StartUp Screen = IP and Login Information - New GISVM = Latest versions of the software - New OS = Ubuntu 16.04 LTS 64bit! - New Disk = Logical Volume Management (LVM) New StartUp Screen = IP and Login Information GISVM startup terminal screen shows automatic IP network address, default password and URL information, for your convenience! New GISVM = Latest versions of the included software GISVM has been updated with the latest software available versions. Including the fantastic new version of Webmin 1.880 The new PostgreSQL 10 release The new Tomcat 8 release Apache 2 has been replaced by the ultrafast NGINX 1.13.8 reverse proxy web server New OS = Ubuntu 16.04 LTS 64bit! GISVM has been upgraded from the previous Ubuntu Server LTS 14.04 32bit to the latest Long Time Support :Ubuntu Server LTS 16.04 64 bit https://wiki.ubuntu.com/XenialXerus/ReleaseNotes New Disk = Logical Volume Management (LVM) GISVM disks and partition use Logical Volume Management, for much more advanced and flexible than the traditional method, that allows easier partition resizing, moving, creating and snapshot. https://wiki.ubuntu.com/Lvm Best regards, Ricardo Pinho ___ postgis-users mailing list postgis-users@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/postgis-users
[postgis-users] Status and plans regarding circular arcs support?
Hi, is there any document outlining the current status of arc support in PostGIS? In particular, a list of functions that can those that work off the native curves, and those that linear-ization instead (eventually, those that do not work at all against curvilinear geometries)? Maybe (and I might be dreaming here :-) ) with some indication of whether they will be improvements in that regard? Cheers Andrea == GeoServer Professional Services from the experts! Visit http://goo.gl/it488V for more information. == Ing. Andrea Aime @geowolf Technical Lead GeoSolutions S.A.S. Via di Montramito 3/A 55054 Massarosa (LU) phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339 8844549 http://www.geo-solutions.it http://twitter.com/geosolutions_it AVVERTENZE AI SENSI DEL D.Lgs. 196/2003 Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il loro utilizzo è consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora riceviate questo messaggio senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso, divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità diverse, costituisce comportamento contrario ai principi dettati dal D.Lgs. 196/2003. The information in this message and/or attachments, is intended solely for the attention and use of the named addressee(s) and may be confidential or proprietary in nature or covered by the provisions of privacy act (Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection Code).Any use not in accord with its purpose, any disclosure, reproduction, copying, distribution, or either dissemination, either whole or partial, is strictly forbidden except previous formal approval of the named addressee(s). If you are not the intended recipient, please contact immediately the sender by telephone, fax or e-mail and delete the information in this message that has been received in error. The sender does not give any warranty or accept liability as the content, accuracy or completeness of sent messages and accepts no responsibility for changes made after they were sent or for other risks which arise as a result of e-mail transmission, viruses, etc. ___ postgis-users mailing list postgis-users@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/postgis-users
Re: [postgis-users] Aggregating rasters by adding and other confusions
Hi,
I did some tests to try to figure this out and it seems like most of
the confusion was due to integer mathematics (though I am not sure that
the current behavior is the "correct" behavior). First, I created some
test rasters:
CREATE TEMP TABLE test_rasters ASSELECT 1 AS rid, ST_SetValues(
ST_AddBand( ST_MakeEmptyRaster(2, 2, 0, 0, 1, -1, 0, 0, 0),
1, '8BUI', 0), 1, 1, 1, ARRAY[[1,2],
[0,0]]::double precision[][] ) AS rastUNIONSELECT 2 AS rid,
ST_SetValues( ST_AddBand( ST_MakeEmptyRaster(2, 2, 0, 0,
1, -1, 0, 0, 0),1, '8BUI', 0), 1, 1, 1,
ARRAY[[1,0], [3,0]]::double precision[][] ) AS rastUNIONSELECT 3
AS rid, ST_SetValues( ST_AddBand( ST_MakeEmptyRaster(2,
2, 0, 0, 1, -1, 0, 0, 0), 1, '8BUI', 0),
1, 1, 1, ARRAY[[0,0], [3,0]]::double precision[][] ) AS rast;
This leads to the following rasters:
# SELECT rid, ST_DumpValues(rast) FROM test_rasters; rid
|st_dumpvalues-+- 3 |
(1,"{{0,0},{3,0}}") 1 | (1,"{{1,2},{0,0}}") 2 |
(1,"{{1,0},{3,0}}")(3 rows)
Then I did the following calculations on those rasters:
# SELECT ST_DumpValues(ST_Union(rast,1,'COUNT')) FROM
test_rasters;st_dumpvalues-
(1,"{{3,3},{3,3}}")
# SELECT ST_DumpValues(ST_Union(rast,1,'SUM')) FROM
test_rasters; st_dumpvalues --
-- (1,"{{2,2},{6,NULL}}")(1 row)
# SELECT ST_DumpValues(ST_Union(rast,1,'MEAN')) FROM
test_rasters; st_dumpvalues --
-- (1,"{{1,1},{2,NULL}}")(1 row)
# SELECT
ST_DumpValues(ST_MapAlgebra(ST_Union(rast,1,'SUM'),'8BUI','[rast] /
3')) FROM test_rasters; st_dumpvalues --
-- (1,"{{1,1},{2,NULL}}")(1 row)
# SELECT
ST_DumpValues(ST_MapAlgebra(ST_Union(rast,1,'SUM'),'64BF','[rast] /
3')) FROM
test_rasters; st_dumpvalues
-
--- (1,"{{0.667,0.667},{2,NULL}}")(1 row)
So ST_Union is counting the zero values, but when it calculates the
MEAN, it does integer mathematics that leads to unexpected results.
Whereas ST_MapAlgebra allows you to select the output raster pixel
type, ST_Union does not, so I don't think there is a good work around
for this. Is there a way to "cast" a raster from one pixel type to
another? I imagine that with appropriate calls to ST_DumpValues and
ST_SetValues one could make it happen.
One could argue whether or not the current behavior is correct. Based
on my experience with the standard avg() aggregate function, I expected
ST_Union to select an output pixel type that is appropriate for the
calculation being carried out, i.e., that it would output a '32BF' or
'64BF' raster as integer means are a bit unusual. Perhaps ST_Union
should have an output pixel type argument or by default return '64BF'?
On a related note, I noticed that ST_SetBandNoDataValue has somewhat
unexpected behavior when you set the no data value to something that is
outside the range of the pixel type, basically setting the no data
value to the max or min of the data range:
# SELECT (ST_BandMetadata(ST_SetBandNoDataValue(rast,1,-
99))).nodatavalue,#ST_DumpValues(ST_SetBandNoDataValue(rast,1,-
99)) AS values# FROM test_rasters WHERE rid=1; nodatavalue
| values -+
--- 0 | (1,"{{1,2},{NULL,NULL}}")(1 row)
# SELECT
(ST_BandMetadata(ST_SetBandNoDataValue(rast,1,99))).nodatavalue,#
ST_DumpValues(ST_SetBandNoDataValue(rast,1,99)) AS values# FROM
test_rasters WHERE rid=1; nodatavalue | values---
--+- 99 | (1,"{{1,2},{0,0}}")(1 row)
# SELECT
(ST_BandMetadata(ST_SetBandNoDataValue(rast,1,999))).nodatavalue,#
ST_DumpValues(ST_SetBandNoDataValue(rast,1,999)) AS values# FROM
test_rasters WHERE rid=1; nodatavalue | values---
--+- 255 | (1,"{{1,2},{0,0}}")(1 row)
I would have expected it to return an error when the demanded no data
value was outside the range. Should this behavior be changed?
Thanks,David
---
On Sat, 2018-03-10 at 12:00 -0800, postgis-users-requ...@lists.osgeo.or
g wrote:
> Message: 1
> Date: Fri, 9 Mar 2018 23:22:56 -0500
> From: "Regina Obe"
> To: "'PostGIS Users Discussion'"
> Subject: Re: [postgis-users] Aggregating rasters by adding and other
> confusions
> Message-ID: <000301d3b827$77f497b0$67ddc710$@pcorp.us>
> Content-Type: text/plain; charset="utf-8"
>
> David,
>
>
>
> I took a cursory glance at the union code we have in place.
>
> What it seems to do is two passes
>
>
>
> 1 pass does an ST_Union using 'COUNT' (so in your case you'd get
> numbers between 0 and 3, 0 being no rasters considered having any
> data)
>
> 2nd pass does an
