Hi List
I have this geometry
id;geom
1;"010520BB0B01000102007700329C245839223741D15CE77F823753417377C82E30223741D7188C3E8437534180BF88072722374106737AE784375341C26ED9F31C223741B546821E85375341336F19E50D2237411EA3BF63823753419128AED2B6213741B85A499D6637534151D26103B321374125B7E3
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
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
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
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.
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
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:
>
>
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 !
(
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
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
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
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
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
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
14 matches
Mail list logo