Hi,<div><br></div><div>Ok. Good to know. I could solve this by multiplying my numbers by 1000 in the rasters before importing, then dividing them by 1000 when they are in the database.</div><div>Maybe that is a solution...</div>
<div><br></div><div>Thanks Jorge.</div><div><br></div><div>Andreas<br><br><div class="gmail_quote">2011/3/14 Jorge Arévalo <span dir="ltr"><<a href="mailto:jorge.arevalo@deimos-space.com">jorge.arevalo@deimos-space.com</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div><div></div><div class="h5">On Mon, Mar 14, 2011 at 3:53 PM, Andreas Forř Tollefsen<br>
<<a href="mailto:andreasft@gmail.com">andreasft@gmail.com</a>> wrote:<br>
> Hi. Again.<br>
> I have been working on some raster data in PostGIS lately.<br>
> However, i have some issues with the raster values become integer after<br>
> importing the sql to postgis.<br>
> For instance this procedure:<br>
> C:\prio_grid\source\gpw>c:\python26\python<br>
> c:\prio_grid\script\raster2pgsql.py -<br>
> r c:\prio_grid\source\gpw\lrc30p90\glp90ag30\w001001.adf -t gpw90 -s 4326 -o<br>
> gpw<br>
> 90.sql -I -M<br>
> Then to database:<br>
> C:\prio_grid\source\gpw>psql -h 192.168.1.55 -d priogrid -f gpw90.sql<br>
> Querying this data:<br>
> SELECT gpw90.gid, ((gpw90.gpw90val).val) AS gpw90<br>
> INTO popgrid<br>
> FROM (SELECT priogrid_land.gid, ST_Intersection(gpw90.rast,<br>
> priogrid_land.centroid) AS gpw90val FROM gpw90, priogrid_land WHERE<br>
> ST_Intersects(priogrid_land.centroid, gpw90.rast)) AS gpw90<br>
> WHERE gpw90.gid = 139303<br>
> GROUP BY gid,((gpw90.gpw90val))<br>
> ;<br>
> Gives:<br>
> gid; gpw90<br>
> 139303;39849<br>
> The value in the original raster is:<br>
> 39849.2<br>
> Question is then. How can i ensure that raster remain decimal and not<br>
> integer after this import and query process?<br>
> Thanks.<br>
> Andreas<br>
</div></div>> _______________________________________________<br>
> postgis-users mailing list<br>
> <a href="mailto:postgis-users@postgis.refractions.net">postgis-users@postgis.refractions.net</a><br>
> <a href="http://postgis.refractions.net/mailman/listinfo/postgis-users" target="_blank">http://postgis.refractions.net/mailman/listinfo/postgis-users</a><br>
><br>
><br>
<br>
Hi Andreas,<br>
<br>
This is a known bug (<a href="http://trac.osgeo.org/postgis/ticket/650" target="_blank">http://trac.osgeo.org/postgis/ticket/650</a>). A<br>
polygonize algorithm provided by GDAL library is used in intersection<br>
function, and this algorithm truncates float values to signed 32 bits<br>
integers. We should solve this, but we don't know when. I'm really<br>
sorry.<br>
<br>
Best regards,<br>
<font color="#888888"><br>
--<br>
Jorge Arévalo<br>
Internet & Mobilty Division, DEIMOS<br>
<a href="mailto:jorge.arevalo@deimos-space.com">jorge.arevalo@deimos-space.com</a><br>
<a href="http://es.linkedin.com/in/jorgearevalo80" target="_blank">http://es.linkedin.com/in/jorgearevalo80</a><br>
<a href="http://mobility.grupodeimos.com/" target="_blank">http://mobility.grupodeimos.com/</a><br>
<a href="http://gis4free.wordpress.com" target="_blank">http://gis4free.wordpress.com</a><br>
<a href="http://geohash.org/ezjqgrgzz0g" target="_blank">http://geohash.org/ezjqgrgzz0g</a><br>
</font></blockquote></div><br></div>