[postgis-users] problem with dumppoints and srid

2013-11-25 Thread franco base
Hi List I have this geometry id;geom 1;"010520BB0B01000102007700329C245839223741D15CE77F823753417377C82E30223741D7188C3E8437534180BF88072722374106737AE784375341C26ED9F31C223741B546821E85375341336F19E50D2237411EA3BF63823753419128AED2B6213741B85A499D6637534151D26103B321374125B7E3

[postgis-users] Postgis raster : jfif? jp2?

2013-11-25 Thread laurent
Dear all, I would like import a world raster DEM in my postgis db. I would like use raster2pgsql. When i try to convert the jp2 file or jfif file to the .sql, i have an error message saying "Unable to read raster". When i type: raster2pgsql -G , the jpeg jfif seems to be in the list. Why i have

Re: [postgis-users] Postgis raster : jfif? jp2?

2013-11-25 Thread Mateusz Loskot
On 25 November 2013 14:22, laurent wrote: > When i type: raster2pgsql -G , the jpeg jfif seems to be in the list. Why i > have this error message? Except tiff, what raster format can be imported > into postgis db? Read the docs, Luke! "loads GDAL supported raster formats" [1] and "-G Print th

Re: [postgis-users] Postgis raster : jfif? jp2?

2013-11-25 Thread Pierre Racine
Laurent, The list of available drivers is dependent on your installation. Normally if you can gdalinfo a raster, raster2psgql should be able to load it. So the first thing is: Does gdalinfo works fine? If not then you should refer to the gdal list. I yes then it might be a raster2pgsql problem

Re: [postgis-users] Postgis raster : jfif? jp2?

2013-11-25 Thread Mateusz Loskot
I overlooked Laurent's tried the -G option indeed. I apologise, my bad. Yes, gdalinfo should help to figure out what's wrong. Peraps multiple GDAL libs in the env? M On 25 November 2013 14:55, Pierre Racine wrote: > Laurent, > > The list of available drivers is dependent on your installation.

Re: [postgis-users] problem with dumppoints and srid

2013-11-25 Thread Sandro Santilli
On Mon, Nov 25, 2013 at 02:52:37PM +0100, franco base wrote: > Infact : > ST_srid(geom) give 3003 > ST_srid ((ST_DumpPoints(geom)).geom) ---give 0 Sounds like a bug. Could you please file it on http://trac.osgeo.org/postgis ? Account is created here: http://www.osgeo.org/osgeo_userid/ Than

Re: [postgis-users] Odd st_buffer behaviour

2013-11-25 Thread James David Smith
Apologies. I think I've just answered this myself. It's the 'endcap=flat join=round' bit isn't it. It's not doing what I am expecting it to do. Though I'm not quite sure how to fix it yet. On 25 November 2013 17:04, James David Smith wrote: > Hi there, > > Some code to illustrate my problem: > >

Re: [postgis-users] Odd st_buffer behaviour

2013-11-25 Thread Rémi Cura
Does offset curve gives the same result? (seems lile offsetting both side have same behavior) Maybe you can try several buffers with increasing size? (default appears wau before 1000) Also, can you try to simplify your line : each coordinates uses 15 digits, surely you don't need all of this ! (

Re: [postgis-users] Odd st_buffer behaviour

2013-11-25 Thread Rémi Cura
You could use the default ending (which is well defined), then split the resulting with the line like endcap=flat (easy to build, translate endpoint by radius and -radius in normal direction) I still fail to understand why you would need this kind of ending. Cheers, Rémi C 2013/11/25 Rémi Cura

Re: [postgis-users] Odd st_buffer behaviour

2013-11-25 Thread James David Smith
Hi Remi/all, I realise I'm digressing slightly from the point, but this seems related. This seems strange to me: I check the geometry type of a table of what I think are linestrings (roads): ukroads=# SELECT COUNT(*), geometrytype(geom) FROM ukrds GROUP BY geometrytype(geom); 395356 | LINESTRING

Re: [postgis-users] Odd st_buffer behaviour

2013-11-25 Thread Stephen Woodbridge
This is because lines shaped like say an Omega character, will create an island inside the character at a certain offset and this can not be represented as a simple polygon. Well maybe it can but the algorithm probably does not try to reduce them to their most simple features. While the lines m

Re: [postgis-users] Odd st_buffer behaviour

2013-11-25 Thread James David Smith
Steve, Thanks, you are of course right. I hadn't thought of that. Makes sense. James On 25 November 2013 17:58, Stephen Woodbridge wrote: > This is because lines shaped like say an Omega character, will create an > island inside the character at a certain offset and this can not be > represente

Re: [postgis-users] problem with dumppoints and srid

2013-11-25 Thread Paragon Corporation
This bug is already fixed in PostGIS 2.1.1 Details in this ticket. http://trac.osgeo.org/postgis/ticket/2433 Hope that helps, Regina http://www.postgis.us http://postgis.net -Original Message- From: postgis-users-boun...@lists.osgeo.org [mailto:postgis-users-boun...@lists.osgeo.org] O

Re: [postgis-users] problem with dumppoints and srid

2013-11-25 Thread Sandro Santilli
On Mon, Nov 25, 2013 at 06:02:18PM -0500, Paragon Corporation wrote: > This bug is already fixed in PostGIS 2.1.1 > > Details in this ticket. > > http://trac.osgeo.org/postgis/ticket/2433 That ticket mentions a problem with ST_ConcaveHull, not ST_DumpPoints ? Also no trace of ST_DumpPoints in t