[gdal-dev] problem on function OGR_FD_GetName
Hi list, I reinstalled my OS (Ubuntu10.04) recently and now the OGR_FD_GetName function results in layername with point,Line,Area,Meta,but I believe this function could get a layer's object name but not its geometry type. I'm not sure the problem exist in environment variable or not and, if so, what are they? Best regards Randy ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Re: ESRI file geodatabase support
Another way to achieve interoperability is via a DBMS for which there is an SDE implementation, although this may not be appropriate for Matt Wilkie's requirements. It may not be always as easy as with shapefiles but it does not have the limitations. Having said that, in our Oracle environment I do have a problem getting SDE to recognise some spatial datasets created with GDAL but have yet to prove what is happening to cause this and so cannot point a finger of blame in any direction ... Best wishes, Peter Duarte Carreira wrote: Matt, the only reason I have seen presented for some reluctance in pushing spatialite as a de facto standard following shapefile's success, is not having a foothold in the closed source sector. That's the only thing ESRI's fgdb could potentially offer, since the extra data types supported will not be available outside ESRI's software (Terrain, Topology, Networks, etc.). (As for interoperability with ESRI, its users can always export to shapefile. Ofcourse I would prefer to directly read fgdb data but if not possible it's ok too.) So the question is: is it true that for a new universal spatial format to be born it has to have at least read support in the closed source world? Duarte -Mensagem original- De: Matt Wilkie [mailto:map...@gmail.com] Enviada: terça-feira, 15 de Junho de 2010 22:52 Para: gdal-dev@lists.osgeo.org Assunto: [gdal-dev] Re: ESRI file geodatabase support I think discussing a shapefile successor, or even perhaps a code sprint, is a very good topic for FOSS4G. This same thread that we're weaving now is/has happened on a number mailing lists and usually generated dozens of responses each time. The interest is clear. From my vantage the germinating seed crystal could be spatialite, but there seems to be some general reluctance to jump on board. I'm ignorant of the reasons for that, perhaps that will come out at FOSS4G; wish I could be there! Ivan: I personally welcome and will use a gdal/ogr that uses the currently installed arcgis libraries however for the health of the industry I'd like to see unencumbered access. Thanks for letting me know at least part of my ramblings are of interest cheers, -matt -- View this message in context: http://osgeo-org.1803224.n2.nabble.com/gdal-dev-ESRI-file-geodatabase-support-tp5159756p5183957.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 -- Peter J Halls, GIS Advisor, University of York Telephone: 01904 433806 Fax: 01904 433740 Snail mail: Computing Service, University of York, Heslington, York YO10 5DD This message has the status of a private and personal communication ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] problem on function OGR_FD_GetName
Hi Chaitanya, Thanks for your quick response! I use this function in parse a s57 file(*.000). In this format file,I think the layer-name in OGR should be like this: berths,bridge,canals... which to some extend,is as same as a feature-name. But now I'm not sure whether I understand this concept right or not? In my application,OGR_FD_GetName()returns: DSID Point Line Area Meta I'd like to know whether this function works fine or not? If yes, how should I get a feature's name? Thanks a lot! Best regards, Randy OGR_FD_GetName() returns the name of the feature definition set during it's creation. It doesn't have to be unique and doesn't represent the object type or geometry type. It is not affected by any environment variables. On Thu, Jun 17, 2010 at 11:53 AM, randyqiu randyqi...@hotmail.com wrote: Hi list, I reinstalled my OS (Ubuntu10.04) recently and now the OGR_FD_GetName function results in layername with point,Line,Area,Meta,but I believe this function could get a layer's object name but not its geometry type. I'm not sure the problem exist in environment variable or not and, if so, what are they? Best regards Randy ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev -- Best regards, Chaitanya kumar CH. /tʃaɪθənjə/ /kʊmɑr/ +91-9494447584 17.2416N 80.1426E ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] problem on function OGR_FD_GetName
Randy, I do not use s57 data, however I have written a number of programs which use OGR_FD_GetName ... and it has always returned the feature name, if set, or null for me. Feature, as opposed to Layer, names seem quite uncommon, however; although I generally set feature names when creating data objects, I have rarely encountered them on input from other sources. I have never investigated whether this is a failure in OGR to transmit the name or whether my presumption that there was no name to transmit is correct. I'm not sure how much that helps, Peter randyqiu wrote: Hi Chaitanya, Thanks for your quick response! I use this function in parse a s57 file(*.000). In this format file,I think the layer-name in OGR should be like this: berths,bridge,canals... which to some extend,is as same as a feature-name. But now I'm not sure whether I understand this concept right or not? In my application,OGR_FD_GetName()returns: DSID Point Line Area Meta I'd like to know whether this function works fine or not? If yes, how should I get a feature's name? Thanks a lot! Best regards, Randy OGR_FD_GetName() returns the name of the feature definition set during it's creation. It doesn't have to be unique and doesn't represent the object type or geometry type. It is not affected by any environment variables. On Thu, Jun 17, 2010 at 11:53 AM, randyqiu randyqi...@hotmail.com wrote: Hi list, I reinstalled my OS (Ubuntu10.04) recently and now the OGR_FD_GetName function results in layername with point,Line,Area,Meta,but I believe this function could get a layer's object name but not its geometry type. I'm not sure the problem exist in environment variable or not and, if so, what are they? Best regards Randy ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev -- Best regards, Chaitanya kumar CH. /tʃaɪθənjə/ /kʊmɑr/ +91-9494447584 17.2416N 80.1426E ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev -- Peter J Halls, GIS Advisor, University of York Telephone: 01904 433806 Fax: 01904 433740 Snail mail: Computing Service, University of York, Heslington, York YO10 5DD This message has the status of a private and personal communication ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] problem on function OGR_FD_GetName
Randy, I think you need to fiddle with the preprocessor definition S57_BUILTIN_CLASSES during compilation. ( http://trac.osgeo.org/gdal/browser/trunk/gdal/ogr/ogrsf_frmts/s57/s57classregistrar.cpp ). I didn't work with S-57 format, so I don't know any more than you. On Thu, Jun 17, 2010 at 1:51 PM, randy randyqi...@hotmail.com wrote: Hi Peter, Thanks for your response! I do not use s57 data, however I have written a number of programs which use OGR_FD_GetName ... and it has always returned the feature name, if set, or null for me. Feature, as opposed to Layer, names seem quite uncommon, however; although I generally set feature names when creating data objects, I have rarely encountered them on input from other sources. I have never investigated whether this is a failure in OGR to transmit the name or whether my presumption that there was no name to transmit is correct. My problem is a little odd. In my Ubuntu9.04 OS,my application works well, however, in my new 10.04 LTS OS, I rebuilt GDAL and my application,then it refused to work. So in my last e-mail,I asked Chaitanya whether the environment variable did anything bad. I'm not sure how much that helps, Yes,I appreciate anything you said above including experience,suggestion... Best regards, Randy ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev -- Best regards, Chaitanya kumar CH. /tʃaɪθənjə/ /kʊmɑr/ +91-9494447584 17.2416N 80.1426E ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Re: Transparent PNG with color table (palette)
I have implemented in C++ an example of color table applied to a band, taking as reference the python script reported in this thread: Ludwig wrote: colorTable = gdal.ColorTable() greentransparent = (0, 255, 0, 0) blue = (0,0, 255,255) colorTable.SetColorEntry(0, greentransparent) colorTable.SetColorEntry(1, blue) b = image.GetRasterBand(1) b.SetRasterColorTable(colorTable) My code: // Create a color table for the Air Quality output image GDALColorTable *colorTable = new GDALColorTable(); GDALColorEntry black, green, yellow, orange, red, lightRed; // Setting RGB colors for 6 classes black.c1= 0;black.c2= 0;black.c3= 0; black.c4= 0; green.c1= 0;green.c2 = 255;green.c3= 0; green.c4= 0; yellow.c1 = 255; yellow.c2 = 255;yellow.c3 = 0; yellow.c4 = 0; orange.c1 = 255; orange.c2 = 150;orange.c3 = 0; orange.c4 = 0; red.c1 = 255; red.c2 = 0;red.c3 = 0; red.c4 = 0; lightRed.c1 = 150; lightRed.c2 = 0;lightRed.c3 = 0; lightRed.c4 = 0; // Link every color to a pixel value colorTable-SetColorEntry(0, black); colorTable-SetColorEntry(1, green); colorTable-SetColorEntry(2, yellow); colorTable-SetColorEntry(3, orange); colorTable-SetColorEntry(4, red); colorTable-SetColorEntry(5, lightRed); // Apply the table to the band myOutBand-SetColorTable(colorTable); // Delete the GDALColorTable object delete colorTable; I hope this could be helpful for someone. -- View this message in context: http://osgeo-org.1803224.n2.nabble.com/Transparent-PNG-with-color-table-palette-tp2030306p5190147.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
[gdal-dev] Re: Warp info...
I saw that this thread is quite old...it is anything changed with the last version of GDAL? Is the triangulation not implemented yet? Thanks in advance. -- View this message in context: http://osgeo-org.1803224.n2.nabble.com/Warp-info-tp2031316p5190183.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
[gdal-dev] Problems in setting PixelFunctionType and SourceTransferType in VRTDerivedRasterBand
This is a problem which regards all the gdal versions and is about the Python
GDAL bindings.
It seems to be impossible to setup PixelFunctionType and SourceTransferType
in VRTDerivedRasterBand from Python Gdal.
This is an example using IPython:
In [20]: vrtdriver = gdal.GetDriverByName('VRT')
In [21]: vrtdset = vrtdriver.Create('vrtdset.vrt', 1000, 1000, 0)
In [22]: vrtdset.AddBand(gdal.GetDataTypeByName('Float32'),
options=['subClass=VRTDerivedRasterBand', 'PixelFunctionType=phase',
'SourceTransferType=CFloat64'])
Out[22]: 0
In[23]: vrtdset.FlushCache()
Once these commands are run, the output file vrtdataset.vrt does not contain
the element PixelFunctionType in its VRTDerivedRasterBand :
VRTDataset rasterXSize=1000 rasterYSize=1000
VRTRasterBand dataType=Float32 band=1
subClass=VRTDerivedRasterBand/
/VRTDataset
On the contrary we would expect this result:
VRTDataset rasterXSize=1000 rasterYSize=1000
VRTRasterBand dataType=Float32 band=1
subClass=VRTDerivedRasterBand
PixelFunctionTypephase/PixelFunctionType
SourceTransferTypeCFloat64/SourceTransferType
/VRTRasterBand
/VRTDataset
Of course we have omitted the part concerning the Source Dataset.
--
View this message in context:
http://osgeo-org.1803224.n2.nabble.com/Problems-in-setting-PixelFunctionType-and-SourceTransferType-in-VRTDerivedRasterBand-tp5190363p5190363.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
[gdal-dev] gda2tiles.py tile dimesions
Hi, it is possible to set the tile's dimension in gdal2tiles.py? ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] GDAL compiler GDAL utility use
Hi Peter, Thank you so so much for your response! I still believe there is something wrong with my GDAL compiling or environment variable. I use ogrinfo(one of GDAL/OGR utilities) in GDAL on my Linux Windows OS, the result is the same(wrong): -Ogrinfo -ro -al -q US5TX51M.000 |more ERROR 1:Invalid index :-1 ERROR 1:Invalid index :-1 ERROR 1:Invalid index :-1 ERROR 1:Invalid index :-1 //...a lot as the same as above Layer name: DSID ... Layer name:Point . Layer name:Line .. While the ogrinfo in FWTools ,the result is as follows: Layer name: DSID ... Layer name: ACHARE ... Layer name: BCNLAT ... Then, I'd like to know what else I should do when I build GDAL in a default way: cd ./configure ./make ./sudo make install What I do else until now is just set GDAL_DATA environment variable and OGR_S57_OPTIONS. And I use GDAL1.7.2 release version. Best regards, Randy -Original Message- From: Peter J Halls [mailto:p.ha...@york.ac.uk] Sent: Thursday, June 17, 2010 4:54 PM To: randy Subject: [!! SPAM] Re: [gdal-dev] problem on function OGR_FD_GetName Randy, I've not worked with your platforms but, extrapolating from my Solaris(Sparc) environment ... GDAL uses Environment Variables as an alternative to the configure script parameter list. I'm old fashioned here and prefer the parameter list, as I find it easier to debug. Having said that, these control things like the compiler to use and the additional libraries to configure: I do not think any of these are likely to affect the way OGR_FD_GetName works. Are you using the same hardware environment with different operating systems? Has Configure correctly determined the hardware environment? You can work through Config.status and Config.log to check this - if the two GDAL environments are supposed to be the same, can you diff these as a quick way of finding any differences? There are also a few Environment Variables involved at runtime eg PATH, LD_LIBRARY_PATH, ORACLE_HOME, TNS_ADMIN, and so on. The last two control the Oracle interface; the first two affect loading a program at runtime. If any of these are wrong, I would not expect execution to start or get as far as you have. On that basis, I think it unlikely that you have an Environment variable problem. I presume that you are reading the same file on each platform? The 'new' results you are reporting look to me as though the data definition is being reported instead of the feature name: could it be that you are effectively reading alternate lines? Do you have a problem prior to calling OGR_FD_GetName that may be reading the next entry in the dataset to fulfil the input request and thus giving the impression of the incorrect feature name? This could come back to the GDAL Configure results, prior to building GDAL. [Did you transfer the GDAL source directory from one platform to the other? If so, did you run a 'make clean' before building GDAL on the second, problematic platform? It is possible for bits of an old configuration to 'linger' if the clean is not run ...] Hoping there is something there that helps, Best wishes, Peter --- ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
RE: [gdal-dev] Proper parameters for GDALBeginAsyncReader() for RGB images
Thanks Frank! It made a lot of sense. My last comment concerning this function is how would you be able to Acquire a smaller image size of a larger image using GDALBeginAsyncReader() for RGB images? I can get it to work for Grayscale, but using the same parameters for RGB gives me an AccessViolation Error. Example: Example not exact: Assume: ImageWidth = 800 ImageHeight = 400 BufferXSize = 150 BufferYSize = 150 colorScheme = 3 (For RGB) Bandmap[0] = 1, Bandmap[1] = 2, Bandmap[2] = 3 BYTE* JPIP_Buffer = (BYTE*)CLPMalloc(BufferXSize * BufferYSize * colorScheme) Call to function: GDALBeginAsyncReader(fileDataset, 0, 0, //Start at top-left position ImageWidth, ImageHeight,//Note, I am requesting whole image. JPIP_Buffer, BufferXSize, BufferYSize, GDT_Byte, colorScheme, Bandmap, 0, 0, 0, 0); Under the hood, how does the function take the original image size and scale it down to fit Into the a size much smaller than original? For some reason, when I do this for RGB color Images, it gives a AccessViolation error when it calls GDALARGetNextUpdatedRegion(). However, For Grayscale images, it works fine. What would you think might be the problem? Thanks, Robert -Original Message- From: fwarmer...@gmail.com [mailto:fwarmer...@gmail.com] On Behalf Of Frank Warmerdam Sent: Wednesday, June 16, 2010 10:05 To: Zermeno, Robert J CIV NAVAIR, 472100D Cc: gdal-dev@lists.osgeo.org Subject: Re: [gdal-dev] Proper parameters for GDALBeginAsyncReader() for RGB images On Wed, Jun 16, 2010 at 12:51 PM, Zermeno, Robert J CIV NAVAIR, 472100D robert.zerm...@navy.mil wrote: Do I call GDALBeginAsyncReader() three times like RasterIO? One call for Red, one for Blue, and Green? Robert, The AsyncReader API allows reading multiple bands in one pass, much like the RasterIO call on the GDALDataset. Am I correct so far? For the Length of Buffer where I want to place the bytes, Should I have the parameter as (xSize * GDALGetRasterCount(fileDataset) ) This is correct, On to GDALBeginAsyncReader(fileDataset, 0, 0, //Start at top-left position BufferXSize, BufferYSize, JPIP_Buffer, BufferXSize * colorScheme, BufferYSize, GDT_Byte, colorScheme, Bandmap, 0, 0, 0, 0); I think the problem is your passing of BufferXSize * colorScheme. That arguments should be the number of pixels in X, but not taking in account the number of bands. How is the image data stored in JPIP_Buffer. Whould it be: 1.rgbrgbrgbrgb 2. 3.bgrbgrbgrbgr By default (if all zero for the interleaving options) the image will be returned in band sequential form. So option '2' above. Best regards, -- ---+ ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent smime.p7s Description: S/MIME cryptographic signature ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Re: GDAL compiler GDAL utility use
Hi Peter, Thank you very much! With your help,I fixed this problem! The reason is that my GDAL_DATA environment variable is not true. I set it first by the GDAL FAQ(http://trac.osgeo.org/gdal/wiki/FAQInstallationAndBuilding#HowtosetGDAL_DATAvariable) which tells me :$ export GDAL_DATA=/usr/local/share/gdal/data but I find in my default installing path,there is not data folder and all the dates is in its parent directory:/usr/local/share/gdal. So I reset my GDAL_DATA environment variable,and it works well now.I forgot my this variable value in my last Ubuntu9.04 OS,it was a long time ago.And I think the GDAL FAQ How to set GDAL_DATA variable? should change its answer. Thank you,Peter,again! Best regards, Randy Aha ... ERROR 1:Invalid index :-1 ERROR 1:Invalid index :-1 ERROR 1:Invalid index :-1 ERROR 1:Invalid index :-1 I think this is where the key to your problem lies. This message, I believe, implies that the input structure does not match that expected by the driver, such that it is failing to extract key control information. The best way to get at the meaning of this is to locate where in the s57 driver this error is generated - it may be in more than one location, however. Given the condition(s) pertaining to the error, you should be able to deduce the underlying problem. It is possible to turn the internal debug on with a switch to ogrinfo / ogr2ogr: that may help. Does *any* of the output look plausible? Can you read the file successfully elsewhere - I've assumed you can? One possibility relates back to configure: has this identified the byte order correctly? I do not think these errors are going to relate to runtime environment variables, but it is possible for environment variables to override parameters to configure - I often forget to unset ORACLE_HOME, for example, which wreaks havoc with accessing the include files and then wonder why it refuses to include the Oracle driver. I do not know quite how this operates in Windows - I use Cygwin for my GDAL work there and have to be as careful as on Solaris. Best wishes, Peter //...a lot as the same as above Layer name: DSID ... Layer name:Point . Layer name:Line .. While the ogrinfo in FWTools ,the result is as follows: Layer name: DSID ... Layer name: ACHARE ... Layer name: BCNLAT ... Then, I'd like to know what else I should do when I build GDAL in a default way: cd ./configure ./make ./sudo make install What I do else until now is just set GDAL_DATA environment variable and OGR_S57_OPTIONS. And I use GDAL1.7.2 release version. Best regards, Randy -Original Message- From: Peter J Halls [mailto:p.ha...@york.ac.uk] Sent: Thursday, June 17, 2010 4:54 PM To: randy Subject: [!! SPAM] Re: [gdal-dev] problem on function OGR_FD_GetName Randy, I've not worked with your platforms but, extrapolating from my Solaris(Sparc) environment ... GDAL uses Environment Variables as an alternative to the configure script parameter list. I'm old fashioned here and prefer the parameter list, as I find it easier to debug. Having said that, these control things like the compiler to use and the additional libraries to configure: I do not think any of these are likely to affect the way OGR_FD_GetName works. Are you using the same hardware environment with different operating systems? Has Configure correctly determined the hardware environment? You can work through Config.status and Config.log to check this - if the two GDAL environments are supposed to be the same, can you diff these as a quick way of finding any differences? There are also a few Environment Variables involved at runtime eg PATH, LD_LIBRARY_PATH, ORACLE_HOME, TNS_ADMIN, and so on. The last two control the Oracle interface; the first two affect loading a program at runtime. If any of these are wrong, I would not expect execution to start or get as far as you have. On that basis, I think it unlikely that you have an Environment variable problem. I presume that you are reading the same file on each platform? The 'new' results you are reporting look to me as though the data definition is being reported instead of the feature name: could it be that you are effectively reading alternate lines? Do you have a problem prior to calling OGR_FD_GetName that may be reading the next entry in the dataset to fulfil the input request and thus giving the impression of the incorrect feature name? This could come back to the GDAL Configure results, prior to building GDAL. [Did you transfer the GDAL source directory from one platform to the other? If so, did you run a 'make clean' before building GDAL on the second, problematic platform? It is possible for bits of an old configuration to
Re: [gdal-dev] Proper parameters for GDALBeginAsyncReader() for RGB images
On Thu, Jun 17, 2010 at 11:03 AM, Zermeno, Robert J CIV NAVAIR, 472100D robert.zerm...@navy.mil wrote: GDALBeginAsyncReader(fileDataset, 0, 0, //Start at top-left position ImageWidth, ImageHeight, //Note, I am requesting whole image. JPIP_Buffer, BufferXSize, BufferYSize, GDT_Byte, colorScheme, Bandmap, 0, 0, 0, 0); Under the hood, how does the function take the original image size and scale it down to fit Into the a size much smaller than original? For some reason, when I do this for RGB color Images, it gives a AccessViolation error when it calls GDALARGetNextUpdatedRegion(). However, For Grayscale images, it works fine. What would you think might be the problem? Robert, Your call parameters seem fine. I do not understand why you are having problems. If you are unable to get it to work, feel free to file a ticket with a small compilable code example demonstrating the problem, and setup to access a public server or data source. You asked how does the function take the original image and scale it down to fit in a much smaller image. I'm not sure if you are looking for internal details or just whether you are requesting this properly from the outside. If you need details about the internals I can try to provide. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] GDAL Speed Optimization
Frank, I have increased the cache as you suggested using GDALSetCacheMax and it produced a performance gain. Thanks. I think I can improve more acting on the virtual datataset that I use to adapt the image to the paper size. I have to look into the tms driver in order to understand how it download the tiles to compose the final image. Stefano On Fri, Jun 11, 2010 at 6:17 PM, Frank Warmerdam warmer...@pobox.comwrote: Stefano Moratto wrote: Frank, The source images are a sequence of tiles from openstreetmaps. Every tiles has a fixed size (256 x 256) and the area they covers depends from the zoom level. It is explained very well in http://www.maptiler.org/google-maps-coordinates-tile-bounds-projection. I use interpolation (via a virtual dataset) because my window size and the paper size are not a multiple of 256 x 256. I use reprojection because I've to mix this raster datasource with a vector datasource that has a different projection. Reprojecting my vector data to openstreet projection do not affect the performance. So I think the key factor is the resizing ( I use bilinear interpolation) and the size of the bitmap that may cause paging. ... Can you suggest some other parameters? Stefano, Sorry, I wasn't able to learn much more skimming the code and referenced web page. Have you tried the cache size setting I suggested? Best regards, ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdamhttp://pobox.com/%7Ewarmerdam and watch the world go round - Rush| Geospatial Programmer for Rent -- Dr.Eng. Stefano Moratto stefano.mora...@gmail.com stefano.mora...@csiat.it http://www.csiat.it - Traffic Optimization Software ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Re: ESRI file geodatabase support
Matt's chicken-and-egg point seems dead-on. Except that Jack Dangermond abhors a vacuum and ESRI has been focused on higher-order issues than file formats. They are trying to provide topological constraints in the database (or file) and things like geometric networks (which are really just a set of topologically consistent linear features). The good ol' Shapefile doesn't even come close to cutting the mustard. ArcSDE imposes these on other RDBMS. The Personal Geodatabases did it in MDBs. And the File Geodatabase does it without dependency on Microsoft Jet. Another way to look at the open spec issue (which echoes ESRIs sentiment) is that it's rather easy to screw up topology constraints. As Peter mentioned, SDE sometimes doesn't like Oracle tables created by GDAL. The format of the tables may be fine - but the topological relations may not be right. I'm betting ESRI created File Geodatabase mainly to get away from the Personal Geodatabase because it was too easy to muck with the MDB in Access and screw up the higher order relationships. File Geodatabases, like Shapefiles and Personal Geodatabases, are intended as a means to exchange data. You export your data from ArcSDE into one of these formats and give it to someone to use. Shapefiles are stripped of topology. Personal Geodatabases only really work on platforms Microsoft supports. File Geodatabases are the next logical step. SpatialLite seems like a really strong contender. How do we get ESRI to play along? -=--=---===---=--=-=--=---==---=--=-=- Eric B. WolfNew! 720-334-7734 USGS Geographer Center of Excellence in GIScience PhD Student CU-Boulder - Geography GPG Public Key: http://www.h4h.net/ebwolf.public.key.txt On Thu, Jun 17, 2010 at 1:21 AM, Peter J Halls p.ha...@york.ac.uk wrote: Another way to achieve interoperability is via a DBMS for which there is an SDE implementation, although this may not be appropriate for Matt Wilkie's requirements. It may not be always as easy as with shapefiles but it does not have the limitations. Having said that, in our Oracle environment I do have a problem getting SDE to recognise some spatial datasets created with GDAL but have yet to prove what is happening to cause this and so cannot point a finger of blame in any direction ... Best wishes, Peter Duarte Carreira wrote: Matt, the only reason I have seen presented for some reluctance in pushing spatialite as a de facto standard following shapefile's success, is not having a foothold in the closed source sector. That's the only thing ESRI's fgdb could potentially offer, since the extra data types supported will not be available outside ESRI's software (Terrain, Topology, Networks, etc.). (As for interoperability with ESRI, its users can always export to shapefile. Ofcourse I would prefer to directly read fgdb data but if not possible it's ok too.) So the question is: is it true that for a new universal spatial format to be born it has to have at least read support in the closed source world? Duarte -Mensagem original- De: Matt Wilkie [mailto:map...@gmail.com] Enviada: terça-feira, 15 de Junho de 2010 22:52 Para: gdal-dev@lists.osgeo.org Assunto: [gdal-dev] Re: ESRI file geodatabase support I think discussing a shapefile successor, or even perhaps a code sprint, is a very good topic for FOSS4G. This same thread that we're weaving now is/has happened on a number mailing lists and usually generated dozens of responses each time. The interest is clear. From my vantage the germinating seed crystal could be spatialite, but there seems to be some general reluctance to jump on board. I'm ignorant of the reasons for that, perhaps that will come out at FOSS4G; wish I could be there! Ivan: I personally welcome and will use a gdal/ogr that uses the currently installed arcgis libraries however for the health of the industry I'd like to see unencumbered access. Thanks for letting me know at least part of my ramblings are of interest cheers, -matt -- View this message in context: http://osgeo-org.1803224.n2.nabble.com/gdal-dev-ESRI-file-geodatabase-support-tp5159756p5183957.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 -- Peter J Halls, GIS Advisor, University of York Telephone: 01904 433806 Fax: 01904 433740 Snail mail: Computing Service, University of York, Heslington, York YO10 5DD This message has the status of a private and personal communication ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Problem with pixel/line coordinates
Hi, I use next code to translate real coordinates (lat/lon) to the pixel/line coordinates def mapToPixel( mX, mY, geoTransform ): if geoTransform[ 2 ] + geoTransform[ 4 ] == 0: pX = ( mX - geoTransform[ 0 ] ) / geoTransform[ 1 ] pY = ( mY - geoTransform[ 3 ] ) / geoTransform[ 5 ] else: pX, pY = applyGeoTransform( mX, mY, invertGeoTransform( geoTransform ) ) return int( pX + 0.5 ), int( pY + 0.5 ) def pixelToMap( pX, pY, geoTransform ): mX, mY = applyGeoTransform( pX, pY, geoTransform ) return mX, mY def applyGeoTransform( inX, inY, geoTransform ): outX = geoTransform[ 0 ] + inX * geoTransform[ 1 ] + inY * geoTransform[ 2 ] outY = geoTransform[ 3 ] + inX * geoTransform[ 4 ] + inY * geoTransform[ 5 ] return outX, outY def invertGeoTransform( geoTransform ): det = geoTransform[ 1 ] * geoTransform[ 5 ] - geoTransform[ 2 ] * geoTransform[ 4 ] if abs( det ) 0.001: return invDet = 1.0 / det # compute adjoint and divide by determinate outGeoTransform = [ 0, 0, 0, 0, 0, 0 ] outGeoTransform[ 1 ] = geoTransform[ 5 ] * invDet outGeoTransform[ 4 ] = -geoTransform[ 4 ] * invDet outGeoTransform[ 2 ] = -geoTransform[ 2 ] * invDet outGeoTransfrom[ 5 ] = geoTransform[ 1 ] * invDet outGeoTransform[ 0 ] = ( geoTransform[ 2 ] * geoTransform[ 3 ] - geoTransform[ 0 ] * geoTransform[ 5 ] ) * invDet outGeoTransform[ 3 ] = ( -geoTransform[ 1 ] * geoTransform[ 3 ] + geoTransform[ 0 ] * geoTransform[ 4 ] ) * invDet return outGeoTransform When I test it on large raster (in AIG/Arc/Info Binary Grid format) I get next problem: raster value in some points reported by script is differ from value reported by Info tool in QGIS and/or ArcGIS. But for another points reported raster value is correct. As I understand, when point is near pixel border, MapToPixel function return wrong result - row and column of neighbour pixel. For example, if point is near right side of the pixel I get column and row for right neighbour pixel not for pixel I need. Same problem when point is near top side of pixel, I get colunm and row for top neighbour pixel. Is it possible to get correct result for all points? May be there is a mistake in code. Any help and suggestions are welcome. I can upload sample data if necessary but they are large (~330 Mb) I'm use GDAL 1.6.3 with Python 2.5.2 under Linux. Thanks! -- Alexander Bruy ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Problem with pixel/line coordinates
On Thu, Jun 17, 2010 at 1:40 PM, Alexander Bruy alexander.b...@gmail.com wrote: Hi, I use next code to translate real coordinates (lat/lon) to the pixel/line coordinates def mapToPixel( mX, mY, geoTransform ): if geoTransform[ 2 ] + geoTransform[ 4 ] == 0: pX = ( mX - geoTransform[ 0 ] ) / geoTransform[ 1 ] pY = ( mY - geoTransform[ 3 ] ) / geoTransform[ 5 ] else: pX, pY = applyGeoTransform( mX, mY, invertGeoTransform( geoTransform ) ) return int( pX + 0.5 ), int( pY + 0.5 ) Alexander, I believe the addition of 0.5 in the above is incorrect. In the simple, non-rotated case, all values from geoTransform[0] to geoTransform[0] + geoTransform[1] would be on the 1st pixel (ie. pX = 0). As you have coded it, when you are half way across the pixel you are switching into the next one. Keep in mind that (geoTransform[0],geoTransform[3]) is the top left corner of the top left pixel - not the center. def pixelToMap( pX, pY, geoTransform ): mX, mY = applyGeoTransform( pX, pY, geoTransform ) return mX, mY Conversely, here if pX and pY are coming in as integer rather than floating point values, then you will likely want to add half a pixel before transforming so that you get the geoeferenced location of the center of the pixel rather than the upper left corner. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] How to represent multi-dimensional array
Hi folks, I have a dataset that is a 4-dimensional array of values: time,x,y,z We're currently using netcdf to store it, which is well suited to this kind of data. However, we also need to get it into a GIS (Arc in this case), and I'm trying to find a good way to do that. Both Arc and gdalinfo do strange things if I simply point them at the netcdf file. GDAL seems to (arbitrarily?) see it as a 9064 band data set, so it is taking particular slice (I think I'm getting a bunch of (time, z) 2-d bands. Anyway, I suspect that if I re-arrange the axis in the netcdf file, I might get something more reasonable, but my question is: What is a good format to ex[press this to a GIS system? I'm imaging multiple files, maybe geo-tiff, but how to I express time and elevation in a way that is natural to GIS? thanks for your thoughts, -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/ORR(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception chris.bar...@noaa.gov ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
RE: [gdal-dev] Re: ESRI file geodatabase support
Well, if SpatiaLite offers some proper benefits and disseminates through all of the FOSS world, then it may get a strong enough push even for ESRI to pick it up. It happened before... (kml?) If SL would: 1) Be as fast as shapefile in production settings, desktop and webgis 2) Offer SQL support, spatial and otherwise, also through desktop tools like QGIS 3) Allow editing while serving (even if for 1 editor only) 4) Better support in QGIS than for shapefile (take advantage of Spatial SQL, all other functionality) 5) Same for MapServer, GeoServer, gvSIG, et al. 6) Allow easy managing of rasters inside the .db file, through QGIS 7) ??more ideas/requests?? Then it would be a very, very good contender... and the ball would be kicked to the other side. And it seems we're already there for some of the listed features. Duarte De: Eric Wolf [mailto:ebw...@gmail.com] Enviada: quinta-feira, 17 de Junho de 2010 17:33 Para: Peter J Halls Cc: gdal-dev@lists.osgeo.org; Matt Wilkie Assunto: Re: [gdal-dev] Re: ESRI file geodatabase support Matt's chicken-and-egg point seems dead-on. Except that Jack Dangermond abhors a vacuum and ESRI has been focused on higher-order issues than file formats. They are trying to provide topological constraints in the database (or file) and things like geometric networks (which are really just a set of topologically consistent linear features). The good ol' Shapefile doesn't even come close to cutting the mustard. ArcSDE imposes these on other RDBMS. The Personal Geodatabases did it in MDBs. And the File Geodatabase does it without dependency on Microsoft Jet. Another way to look at the open spec issue (which echoes ESRIs sentiment) is that it's rather easy to screw up topology constraints. As Peter mentioned, SDE sometimes doesn't like Oracle tables created by GDAL. The format of the tables may be fine - but the topological relations may not be right. I'm betting ESRI created File Geodatabase mainly to get away from the Personal Geodatabase because it was too easy to muck with the MDB in Access and screw up the higher order relationships. File Geodatabases, like Shapefiles and Personal Geodatabases, are intended as a means to exchange data. You export your data from ArcSDE into one of these formats and give it to someone to use. Shapefiles are stripped of topology. Personal Geodatabases only really work on platforms Microsoft supports. File Geodatabases are the next logical step. SpatialLite seems like a really strong contender. How do we get ESRI to play along? -=--=---===---=--=-=--=---==---=--=-=- Eric B. WolfNew! 720-334-7734 USGS Geographer Center of Excellence in GIScience PhD Student CU-Boulder - Geography GPG Public Key: http://www.h4h.net/ebwolf.public.key.txt On Thu, Jun 17, 2010 at 1:21 AM, Peter J Halls p.ha...@york.ac.ukmailto:p.ha...@york.ac.uk wrote: Another way to achieve interoperability is via a DBMS for which there is an SDE implementation, although this may not be appropriate for Matt Wilkie's requirements. It may not be always as easy as with shapefiles but it does not have the limitations. Having said that, in our Oracle environment I do have a problem getting SDE to recognise some spatial datasets created with GDAL but have yet to prove what is happening to cause this and so cannot point a finger of blame in any direction ... Best wishes, Peter Duarte Carreira wrote: Matt, the only reason I have seen presented for some reluctance in pushing spatialite as a de facto standard following shapefile's success, is not having a foothold in the closed source sector. That's the only thing ESRI's fgdb could potentially offer, since the extra data types supported will not be available outside ESRI's software (Terrain, Topology, Networks, etc.). (As for interoperability with ESRI, its users can always export to shapefile. Ofcourse I would prefer to directly read fgdb data but if not possible it's ok too.) So the question is: is it true that for a new universal spatial format to be born it has to have at least read support in the closed source world? Duarte -Mensagem original- De: Matt Wilkie [mailto:map...@gmail.commailto:map...@gmail.com] Enviada: terça-feira, 15 de Junho de 2010 22:52 Para: gdal-dev@lists.osgeo.orgmailto:gdal-dev@lists.osgeo.org Assunto: [gdal-dev] Re: ESRI file geodatabase support I think discussing a shapefile successor, or even perhaps a code sprint, is a very good topic for FOSS4G. This same thread that we're weaving now is/has happened on a number mailing lists and usually generated dozens of responses each time. The interest is clear. From my vantage the germinating seed crystal could be spatialite, but there seems to be some general reluctance to jump on board. I'm ignorant of the reasons for that, perhaps that will come out at FOSS4G; wish I could be there! Ivan: I personally welcome and will use a gdal/ogr that
RE: [gdal-dev] Re: ESRI file geodatabase support
From: Duarte Carreira dcarre...@edia.pt Subject: RE: [gdal-dev] Re: ESRI file geodatabase support To: Eric Wolf ebw...@gmail.com, Peter J Halls p.ha...@york.ac.uk Cc: gdal-dev@lists.osgeo.org gdal-dev@lists.osgeo.org, Matt Wilkie map...@gmail.com Well, if SpatiaLite offers some proper benefits and disseminates through all of the FOSS world, then it may get a strong enough push even for ESRI to pick it up. It happened before... (kml?) If SL would: 1) Be as fast as shapefile in production settings, desktop and webgis 2) Offer SQL support, spatial and otherwise, also through desktop tools like QGIS 3) Allow editing while serving (even if for 1 editor only) 4) Better support in QGIS than for shapefile (take advantage of Spatial SQL, all other functionality) 5) Same for MapServer, GeoServer, gvSIG, et al. 6) Allow easy managing of rasters inside the .db file, through QGIS 7) ??more ideas/requests?? Then it would be a very, very good contender... and the ball would be kicked to the other side. And it seems we're already there for some of the listed features. Duarte Or even better, instead of waiting and complaining, we could just write a GeoDatabase OGR (ESRI) Workspace ourselves. There are already examples of working ones out there http://svn.obtusesoft.com/core/trunk/ So instead of hoping and pleading for support, someone should just sit down and write it. I started one at one point (C++), got side tracked with other things. If anyone is interested in that source code, I would be happy to share that too. - Ragi ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] How to represent multi-dimensional array
I don't think there is a GIS that does this in a natural way - all you can do is read in multiple slices. If the order of your axes really is time, x, y, z then you will have y.n * z.n (time, x) slices (as bands) when read by GDAL - NetCDF will tend to store dimensions in reverse order to the natural one, and I think GDAL reverses that - but you can tell by the dimension and number of your bands, and the named metadata on the GDAL bands. Later versions of ArcGIS allow time-sliced arrays I think, so you could store several of these. NetCDF cannot store multi-attribute arrays (it will store several same-size, same-metadata arrays for that purpose), so one thing you could do is allow the GIS to to store several multi-band arrays (an array for each T, a band for each Z) - but you need to wear the inconsistency of mixing attributes with dimensions. Manifold reads in multiple rasters and I presume ArcGIS does too. Eonfusion will do its best to read the array in its natural state, but it is interpreted through GDAL and the dimensions reconstructed from the band metadata, but it's not a traditional GIS in any sense. R can read NetCDF natively or with GDAL (RNetCDF, ncdf, rgdal packages) and convert to the Spatial classes, but these are limited to multi-band 2D arrays. Cheers, Mike. On Fri, Jun 18, 2010 at 5:15 AM, Christopher Barker chris.bar...@noaa.gov wrote: Hi folks, I have a dataset that is a 4-dimensional array of values: time,x,y,z We're currently using netcdf to store it, which is well suited to this kind of data. However, we also need to get it into a GIS (Arc in this case), and I'm trying to find a good way to do that. Both Arc and gdalinfo do strange things if I simply point them at the netcdf file. GDAL seems to (arbitrarily?) see it as a 9064 band data set, so it is taking particular slice (I think I'm getting a bunch of (time, z) 2-d bands. Anyway, I suspect that if I re-arrange the axis in the netcdf file, I might get something more reasonable, but my question is: What is a good format to ex[press this to a GIS system? I'm imaging multiple files, maybe geo-tiff, but how to I express time and elevation in a way that is natural to GIS? thanks for your thoughts, -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/ORR (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception chris.bar...@noaa.gov ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] How to represent multi-dimensional array
Don't know if this is what you are looking for but if those netCDF files are of a similar type that one can get from the poet site (http://poet.jpl.nasa.gov/), Mirone has a tool called Aquamoto (a tool original developed to show time stamps of a tsunami propagation models) that loads those files and show their content interactively with the help of a slider. Joaquim Hi folks, I have a dataset that is a 4-dimensional array of values: time,x,y,z We're currently using netcdf to store it, which is well suited to this kind of data. However, we also need to get it into a GIS (Arc in this case), and I'm trying to find a good way to do that. Both Arc and gdalinfo do strange things if I simply point them at the netcdf file. GDAL seems to (arbitrarily?) see it as a 9064 band data set, so it is taking particular slice (I think I'm getting a bunch of (time, z) 2-d bands. Anyway, I suspect that if I re-arrange the axis in the netcdf file, I might get something more reasonable, but my question is: What is a good format to ex[press this to a GIS system? I'm imaging multiple files, maybe geo-tiff, but how to I express time and elevation in a way that is natural to GIS? thanks for your thoughts, -Chris ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] How to represent multi-dimensional array
Chris, Christopher Barker wrote: Hi folks, I have a dataset that is a 4-dimensional array of values: time,x,y,z We're currently using netcdf to store it, which is well suited to this kind of data. However, we also need to get it into a GIS (Arc in this case), and I'm trying to find a good way to do that. Both Arc and gdalinfo do strange things if I simply point them at the netcdf file. GDAL seems to (arbitrarily?) see it as a 9064 band data set, so it is taking particular slice (I think I'm getting a bunch of (time, z) 2-d bands. You might take a look a Idrisi (www.clarklabs.org). It imports netCDF using a GUI where you can choose the orders of the dimensions to read from. There is a set of tools to perform time series analysis. Anyway, I suspect that if I re-arrange the axis in the netcdf file, I might get something more reasonable, but my question is: What is a good format to ex[press this to a GIS system? I'm imaging multiple files, maybe geo-tiff, but how to I express time and elevation in a way that is natural to GIS? You might be forced to use multiple files just because that is how generally image processing tools work better. Then you could write scripts to loop trough the bands files with those tools. Although some operations on the time dimension could work much faster in a multi-band, pixel interleaving storage mode. Like you said, netCDF are well suited for that kind of processing. I am afraid that the tools are not, yet. thanks for your thoughts, -Chris Regards, Ivan ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
