Re: [gdal-dev] using gdalwarp with a new projection in proj.4
Even wrote: I see that this projection was only introduced in PROJ 4.8.0, so check your PROJ.4 version. Markus is using Rev 2375 of the proj.4 upstream SVN with the scaling patch for HEALPix/rHEALPix applied from thishttp://trac.osgeo.org/proj/ticket/219 patch. Thank you for your help! -- Michael Speth Research Systems Developer Landcare Research Please consider the environment before printing this email Warning: This electronic message together with any attachments is confidential. If you receive it in error: (i) you must not read, use, disclose, copy or retain it; (ii) please contact the sender immediately by reply email and then delete the emails. The views expressed in this email may not be those of Landcare Research New Zealand Limited. http://www.landcareresearch.co.nz ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] gtiff with internal mask
Please ignore previous email... should be a note to self... -Mensagem original- De: Duarte Carreira Enviada: sexta-feira, 19 de Julho de 2013 12:27 Para: 'Even Rouault' Cc: 'gdal-dev@lists.osgeo.org' Assunto: RE: [gdal-dev] gtiff with internal mask Ok, para conseguir construir as pirâmides temos de ter a máscara separada e não incluída no próprio tiff. Para isso basta alterar o 3º passo que cria efectivamente o tiff a partir do vrt, removendo a opção de criar a máscara interna, ficando assim: gdal_translate -co alpha=no -co photometric=ycbcr -co interleave=pixel -co tiled=yes -co compress=jpeg testmask_uncomp.vrt test_finalmask.tif Isto basta para que seja criado um tif rgb e um ficheiro .msk separados. *** Para criar um rgb+iv num só tiff, com máscara! *** Alterar o mosaico vrt criado no 2º passo, que já inclui a máscara, e criar uma banda Gray com origem no mosaico vrt dos infravermelhos. Depois é só converter mas usando as opções: -co alpha=no -co photometric=rgb e talvez -co interleave=band (para não dar erro). Não podemos usar ycbcr porque só dá para 3 bandas e nós temos 4. DC -Mensagem original- De: Duarte Carreira Enviada: quinta-feira, 18 de Julho de 2013 13:01 Para: 'Even Rouault' Cc: 'gdal-dev@lists.osgeo.org' Assunto: RE: [gdal-dev] gtiff with internal mask So... now I 've got issues building the overviews. Gdaladdo loses the transparency so I get to see black areas where I was supposed to see nothing. When I zoom in black disappears. Any known way to overcome this? Thanks, Duarte -Mensagem original- De: Duarte Carreira Enviada: quarta-feira, 17 de Julho de 2013 19:41 Para: 'Even Rouault' Cc: gdal-dev@lists.osgeo.org Assunto: RE: [gdal-dev] gtiff with internal mask Well, you're right... I messed up recreating the footsteps... So, cleaning up: 1) create a rgba vrt using gdalwarp to cut the original mosaic with a shapefile gdalwarp -multi -wm 480 --config GDAL_CACHEMAX 312 -co alpha=yes -dstalpha -cutline shapes\index_diss.shp -of vrt originalmosaic.vrt test_rgba_uncomp.vrt 2) create a masked uncompressed vrt using gdal_translate (because I couldn't compress right away, with errors of missing StripOffsets field) gdal_translate -b 1 -b 2 -b 3 -mask 4 -co alpha=no -co photometric=rgb -co interleave=pixel -co tiled=yes --config GDAL_TIFF_INTERNAL_MASK YES -of vrt test_rgba_uncomp.vrt testmask_uncomp.vrt 3) create final masked compressed tiff using gdal_translate gdal_translate -co alpha=no -co photometric=ycbcr -co interleave=pixel -co tiled=yes -co compress=jpeg --config GDAL_TIFF_INTERNAL_MASK YES testmask_uncomp.vrt test_finalmask.tif The power of VRT amazes me! Also regarding sizes: I still got the same ratio of 8x smaller. To use this in QGIS you still have to create a rgba vrt: 4) gdal_translate -of VRT -b 1 -b 2 -b 3 -b mask test_finalmask.tif test_finalmask_qgis.vrt (couldn't get the 4ª band to be recognized as an alpha band though) So I think now it's correct... I am going to apply this to a real-case mosaic and report back... Duarte -Mensagem original- De: Even Rouault [mailto:even.roua...@mines-paris.org] Enviada: quarta-feira, 17 de Julho de 2013 13:45 Para: Duarte Carreira Cc: gdal-dev@lists.osgeo.org Assunto: Re: [gdal-dev] gtiff with internal mask Le mercredi 17 juillet 2013 14:23:29, Duarte Carreira a écrit : Hi Even. Thanks so much for your tip! It works. I did have to specify I did not want an alpha band when cutting with the shapefile: gdalwarp -multi -wm 480 --config GDAL_CACHEMAX 256 -co photometric=ycbcr -co compress=jpeg -co alpha=no --config GDAL_TIFF_INTERNAL_MASK YES -cutline shapes\index_diss.shp vrtini.vrt testmask.tif Hum, what I don't understand is how the above will produce a mask band in the output file... Does gdalinfo on testmask.tif show something like : Band 1 Block= Type=Byte, ColorInterp=Red Mask Flags: PER_DATASET Band 2 Block= Type=Byte, ColorInterp=Green Mask Flags: PER_DATASET Band 3 Block=... Type=Byte, ColorInterp=Blue Mask Flags: PER_DATASET I think you would need to do the above in 2 steps: 1) gdalwarp to an uncompressed RGBA TIFF 2) gdal_translate to turn the RGBA into a YCbCr JPEG-compressed GTiff + mask band Seems arcgis recognizes the masked tiff, but is much much slower displaying than using a normal alpha band. Perhaps adding -co TILED=YES will help ? (random guess) QGIS does need the vrt trick but then is as fast as usual. Also, the size is must smaller when using an internal mask: from a 219MB rgba,band interleaved,jpegd image to a 27MB ycbcr,pixel interleaved,jpegd masked tiff (8x smaller). Unless I missed something... Not completely surprising although more important than I would have expected. YCbCr compression usually gives a 2x to 3x compression bonus, and due to the usual nature of mask bands, the 1bit deflate compression of the mask band will give better results (both visually and in size) that the 8bit
Re: [gdal-dev] gtiff with internal mask
Ok, para conseguir construir as pirâmides temos de ter a máscara separada e não incluída no próprio tiff. Para isso basta alterar o 3º passo que cria efectivamente o tiff a partir do vrt, removendo a opção de criar a máscara interna, ficando assim: gdal_translate -co alpha=no -co photometric=ycbcr -co interleave=pixel -co tiled=yes -co compress=jpeg testmask_uncomp.vrt test_finalmask.tif Isto basta para que seja criado um tif rgb e um ficheiro .msk separados. *** Para criar um rgb+iv num só tiff, com máscara! *** Alterar o mosaico vrt criado no 2º passo, que já inclui a máscara, e criar uma banda Gray com origem no mosaico vrt dos infravermelhos. Depois é só converter mas usando as opções: -co alpha=no -co photometric=rgb e talvez -co interleave=band (para não dar erro). Não podemos usar ycbcr porque só dá para 3 bandas e nós temos 4. DC -Mensagem original- De: Duarte Carreira Enviada: quinta-feira, 18 de Julho de 2013 13:01 Para: 'Even Rouault' Cc: 'gdal-dev@lists.osgeo.org' Assunto: RE: [gdal-dev] gtiff with internal mask So... now I 've got issues building the overviews. Gdaladdo loses the transparency so I get to see black areas where I was supposed to see nothing. When I zoom in black disappears. Any known way to overcome this? Thanks, Duarte -Mensagem original- De: Duarte Carreira Enviada: quarta-feira, 17 de Julho de 2013 19:41 Para: 'Even Rouault' Cc: gdal-dev@lists.osgeo.org Assunto: RE: [gdal-dev] gtiff with internal mask Well, you're right... I messed up recreating the footsteps... So, cleaning up: 1) create a rgba vrt using gdalwarp to cut the original mosaic with a shapefile gdalwarp -multi -wm 480 --config GDAL_CACHEMAX 312 -co alpha=yes -dstalpha -cutline shapes\index_diss.shp -of vrt originalmosaic.vrt test_rgba_uncomp.vrt 2) create a masked uncompressed vrt using gdal_translate (because I couldn't compress right away, with errors of missing StripOffsets field) gdal_translate -b 1 -b 2 -b 3 -mask 4 -co alpha=no -co photometric=rgb -co interleave=pixel -co tiled=yes --config GDAL_TIFF_INTERNAL_MASK YES -of vrt test_rgba_uncomp.vrt testmask_uncomp.vrt 3) create final masked compressed tiff using gdal_translate gdal_translate -co alpha=no -co photometric=ycbcr -co interleave=pixel -co tiled=yes -co compress=jpeg --config GDAL_TIFF_INTERNAL_MASK YES testmask_uncomp.vrt test_finalmask.tif The power of VRT amazes me! Also regarding sizes: I still got the same ratio of 8x smaller. To use this in QGIS you still have to create a rgba vrt: 4) gdal_translate -of VRT -b 1 -b 2 -b 3 -b mask test_finalmask.tif test_finalmask_qgis.vrt (couldn't get the 4ª band to be recognized as an alpha band though) So I think now it's correct... I am going to apply this to a real-case mosaic and report back... Duarte -Mensagem original- De: Even Rouault [mailto:even.roua...@mines-paris.org] Enviada: quarta-feira, 17 de Julho de 2013 13:45 Para: Duarte Carreira Cc: gdal-dev@lists.osgeo.org Assunto: Re: [gdal-dev] gtiff with internal mask Le mercredi 17 juillet 2013 14:23:29, Duarte Carreira a écrit : Hi Even. Thanks so much for your tip! It works. I did have to specify I did not want an alpha band when cutting with the shapefile: gdalwarp -multi -wm 480 --config GDAL_CACHEMAX 256 -co photometric=ycbcr -co compress=jpeg -co alpha=no --config GDAL_TIFF_INTERNAL_MASK YES -cutline shapes\index_diss.shp vrtini.vrt testmask.tif Hum, what I don't understand is how the above will produce a mask band in the output file... Does gdalinfo on testmask.tif show something like : Band 1 Block= Type=Byte, ColorInterp=Red Mask Flags: PER_DATASET Band 2 Block= Type=Byte, ColorInterp=Green Mask Flags: PER_DATASET Band 3 Block=... Type=Byte, ColorInterp=Blue Mask Flags: PER_DATASET I think you would need to do the above in 2 steps: 1) gdalwarp to an uncompressed RGBA TIFF 2) gdal_translate to turn the RGBA into a YCbCr JPEG-compressed GTiff + mask band Seems arcgis recognizes the masked tiff, but is much much slower displaying than using a normal alpha band. Perhaps adding -co TILED=YES will help ? (random guess) QGIS does need the vrt trick but then is as fast as usual. Also, the size is must smaller when using an internal mask: from a 219MB rgba,band interleaved,jpegd image to a 27MB ycbcr,pixel interleaved,jpegd masked tiff (8x smaller). Unless I missed something... Not completely surprising although more important than I would have expected. YCbCr compression usually gives a 2x to 3x compression bonus, and due to the usual nature of mask bands, the 1bit deflate compression of the mask band will give better results (both visually and in size) that the 8bit JPEG compression of the alpha band. Thanks again! Duarte -Mensagem original- De: Even Rouault [mailto:even.roua...@mines-paris.org] Enviada: terça-feira, 16 de Julho de 2013 18:58 Para: gdal-dev@lists.osgeo.org Cc: Duarte Carreira
Re: [gdal-dev] Dissolve shapefile using GDAL/OGR
I'm getting the same ST_Union error as Benicio but I know I have Spatialite (v.3.0.1-2), SQLite (3.7.10-2), and Geos (3.3.8-1) from my OSGeo4W install on Win7. I also tried using the GUnion function, which appears to have been replaced by ST_Union at 3.0.0. In fact, none of the spatial operator functions http://www.gaia-gis.it/spatialite-3.0.0-BETA/spatialite-sql-3.0.0.html#p14 ) appear to work. This is the first time I've tried implementing anything other than a format conversion or a simple select query using ogr. Could anyone suggest an ogr2ogr command to me that would test whether it's a Spatialite/Geos installation problem or simply a bug? Thanks, Dan Strobridge + ogr2ogr -append test6.shp poly.gmt --debug on -dialect sqlite -sql select ST_Union(Geometry),zone from poly GROUP BY zone OGR: OGROpen(poly.gmt/035FC9C0) succeeded as GMT. Shape: DBF Codepage = LDID/87 for test6.shp Shape: Treating as encoding 'ISO-8859-1'. OGR: OGROpen(test6.shp/03615808) succeeded as ESRI Shapefile. ERROR 1: Undefined function 'ST_Union' used. -- View this message in context: http://osgeo-org.1560.x6.nabble.com/gdal-dev-Dissolve-shapefile-using-GDAL-OGR-tp5036930p5067633.html Sent from the GDAL - Dev mailing list archive at Nabble.com. ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] [BULK] Re: Dissolve shapefile using GDAL/OGR
Thanks Evan. I will try the workaround and use it until GDAL 1.10 has been
incorporated into OSGeo4W.
Since you’ve brought up the OSGeo4W installer… mine says my gdal library is
current (1.9.2-2) bu when I launch the shell I see the following, which
suggests an older version is actually getting loaded. You don’t happen to know
how to resolve this, do you?
OSGEO4W home is C:\OSGeo4W\
-={ OSGeo4W Shell Commands }=-
find: unable to access .exe: The system cannot find the file specified.
find: unable to access .bat: The system cannot find the file specified.
GDAL 1.7.3, released 2010/11/10
Thanks so much,
Dan
From: Even Rouault [via OSGeo.org]
[mailto:ml-node+s1560n5067676...@n6.nabble.com]
Sent: Friday, July 19, 2013 2:01 PM
To: Strobridge, Daniel M.
Subject: [BULK] Re: Dissolve shapefile using GDAL/OGR
Le vendredi 19 juillet 2013 17:23:24, Dan Strobridge a écrit :
I'm getting the same ST_Union error as Benicio but I know I have Spatialite
(v.3.0.1-2), SQLite (3.7.10-2), and Geos (3.3.8-1) from my OSGeo4W install
on Win7. I also tried using the GUnion function, which appears to have
been replaced by ST_Union at 3.0.0. In fact, none of the spatial
operator functions
http://www.gaia-gis.it/spatialite-3.0.0-BETA/spatialite-sql-3.0.0.html#p14
) appear to work.
This is the first time I've tried implementing anything other than a format
conversion or a simple select query using ogr. Could anyone suggest an
ogr2ogr command to me that would test whether it's a Spatialite/Geos
installation problem or simply a bug?
Dan,
If http://trac.osgeo.org/osgeo4w/wiki/pkg-gdal is up-to-date, the current
version of GDAL in OSGeo4W would be GDAL 1.9.X. The SQLite dialect is a new
function of GDAL 1.10 ...
A workaround is to translate your shapefile into a temporary spatialite DB, and
then do the conversion to GMT with the SQL query.
Best regards,
Even
--
Geospatial professional services
http://even.rouault.free.fr/services.html
___
gdal-dev mailing list
[hidden email]/user/SendEmail.jtp?type=nodenode=5067676i=0
http://lists.osgeo.org/mailman/listinfo/gdal-dev
If you reply to this email, your message will be added to the discussion below:
http://osgeo-org.1560.x6.nabble.com/gdal-dev-Dissolve-shapefile-using-GDAL-OGR-tp5036930p5067676.html
To unsubscribe from [gdal-dev] Dissolve shapefile using GDAL/OGR, click
herehttp://osgeo-org.1560.x6.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_codenode=5036930code=ZGFuLnN0cm9icmlkZ2VAd2VzdG9uc29sdXRpb25zLmNvbXw1MDM2OTMwfDIwMDMxMDQ3Mjk=.
NAMLhttp://osgeo-org.1560.x6.nabble.com/template/NamlServlet.jtp?macro=macro_viewerid=instant_html%21nabble%3Aemail.namlbase=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespacebreadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml
CONFIDENTIALITY: This email and attachments may contain information which is
confidential and proprietary. Disclosure or use of any such confidential or
proprietary information without the written permission of Weston Solutions,
Inc. is strictly prohibited. If you received this email in error, please
notify the sender by return e-mail and delete this email from your system.
Thank you.
--
View this message in context:
http://osgeo-org.1560.x6.nabble.com/gdal-dev-Dissolve-shapefile-using-GDAL-OGR-tp5036930p5067681.html
Sent from the GDAL - Dev mailing list archive at Nabble.com.___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Dissolve shapefile using GDAL/OGR
Le vendredi 19 juillet 2013 17:23:24, Dan Strobridge a écrit : I'm getting the same ST_Union error as Benicio but I know I have Spatialite (v.3.0.1-2), SQLite (3.7.10-2), and Geos (3.3.8-1) from my OSGeo4W install on Win7. I also tried using the GUnion function, which appears to have been replaced by ST_Union at 3.0.0. In fact, none of the spatial operator functions http://www.gaia-gis.it/spatialite-3.0.0-BETA/spatialite-sql-3.0.0.html#p14 ) appear to work. This is the first time I've tried implementing anything other than a format conversion or a simple select query using ogr. Could anyone suggest an ogr2ogr command to me that would test whether it's a Spatialite/Geos installation problem or simply a bug? Dan, If http://trac.osgeo.org/osgeo4w/wiki/pkg-gdal is up-to-date, the current version of GDAL in OSGeo4W would be GDAL 1.9.X. The SQLite dialect is a new function of GDAL 1.10 ... A workaround is to translate your shapefile into a temporary spatialite DB, and then do the conversion to GMT with the SQL query. Best regards, Even -- Geospatial professional services http://even.rouault.free.fr/services.html ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] A new ogr driver
Le vendredi 19 juillet 2013 03:31:12, Xian Chen a écrit : Hi all, I'm planning to submit a new driver for accessing Walk files, a geospatial data format developed by Walkinfo Tech. mainly for land surveying, evaluation, planning, checking and data analysis in China. Walkinfo Tech. is a China-based company founded since 1999, origignally focused on land surveying software research and development. Currently we have our own geographic information platform WalkGIS, as well as scores of GIS desktop, mobile products based on it, including WalkISurvey, WalkISurface, WalkCheck, WalkFu and so on. The company is also the largest strategic partner with Esri ArcGIS in China. The WalkGIS applications use GDAL/OGR as part of its base libaries. The purpose of developing the Walk driver on GDAL/OGR is to allow other GIS products such as ArcGIS to access our data more easily and conveniently. The driver I am working on is already able to get the information such as layers, features, geometries, and spatial references from Walk files. Can I get the permission to submit it to GDAL project and share it with other GDAL developers? Hi Xian, First, you should check with your employer that you can legally contribute code to the GDAL/OGR project and submit it under the GDAL MIT/X licence. Check the Legal section of http://trac.osgeo.org/gdal/wiki/rfc3_commiters . If this is the case, send an email to this mailing list where you will confirm it. I also suggest that you read the developer guidelines at http://trac.osgeo.org/gdal/wiki/rfc8_devguide and check that your code conforms to (most of) them. For OGR driver, I would also recommend that you test the driver with the test_ogrsf utility (not compiled by default, but in a custom build, you can cd apps, and then make test_ogrsf / nmake /f makefile.vc test_ogrsf.exe) on sample files in your data format. This will run a few consistency test to check assumptions that an OGR driver should met. Then, you can attach an archive with the code to a Trac ticket ( http://trac.osgeo.org/gdal/newticket ), so that it can be reviewed. Best regards, Even -- Geospatial professional services http://even.rouault.free.fr/services.html ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
