Re: [gdal-dev] Unable to create OGRSpatialReference
Frank, I've been working a little bit with your ideas. The target is to realize towgs84 parameters automatically. Of course it doesn't work many times because all the procedures I use fail and/or because my code is wrong. I don't know, but maybe you can find it useful. I use Embarcadero (former Borland) IDE, so you'll find non-standard things RRCS is a class derived from OGRSpatialReference. Best regards. Jose -- View this message in context: http://osgeo-org.1560.n6.nabble.com/Unable-to-create-OGRSpatialReference-tp5009903p5010161.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] Unable to create OGRSpatialReference
Frank, Thanks you for your expert answer. It opens for me two or three new ways to look for the /lost/ parameter. My interest is not only in SHP, but your ideas might solve part of my problem. As for what you say I'm up with fixing this with your support (ie. testing, prompting) I am at your command to test what it takes, but I think my solutions that are not suitable for be incorporated into a library like GDAL. However, if I walk into something you'll see in the forum. I hope your new job at Google makes you as happy as a job can do. Thank you again. P.S. You are guaranteed a great paella if you come to Madrid. -- View this message in context: http://osgeo-org.1560.n6.nabble.com/Unable-to-create-OGRSpatialReference-tp5009903p5010047.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] Problem using image bands
Hello!
I have a problem reading an ECW image. I want to read the image using only
the first band. So I use:
int bmap[3] = {1,1,1};
GDALImage-RasterIO(
GF_Read,
x, // int nXOff,
y, // int nYOff,
dx, // int nXSize,
dy, // int nXSize,
buffer, // void* pData,
xBufSize, // int nBufXSize,
yBufSize, // int nBufYSize,
GDT_Byte, // GDALDataType eBufType,
3, // int nBandCount,
bmap, // int* panBandMap,
3, // int nPixelSpace,
xBufSize * 3, // int nLineSpace,
1 // int nBandSpace
);
This is working well with some ECW images (they show as grayscale) but it
does not with another, big ECW. It shows in full RGB color, exactly the same
as if I had written int bmap[3] = {1,2,3};
Any idea?
Thanks in advance!
--
View this message in context:
http://osgeo-org.1560.n6.nabble.com/Problem-using-image-bands-tp5009873.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] Problem using image bands
Ouch! Thank you very much, Even. I should have asked sooner, instead of going to bed at 5 in the morning... :-) Yes, I have to read into a RGB buffer, but your solution would increase a lot the loading time for other images that are working well. I have read this: http://trac.osgeo.org/gdal/changeset/25107. So, do you recommend me to change the code in ecwdataset.cpp and rebuild the library? Thanks again! -- View this message in context: http://osgeo-org.1560.n6.nabble.com/Problem-using-image-bands-tp5009873p5009877.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] Problem using image bands
Ouch!
Thank you very much, Even. I should have asked sooner, instead of going to bed
at 5 in the morning... :-)
Yes, I have to read into a RGB buffer, but your solution would increase a lot
the loading time for other images that are working well.
I have read this: http://trac.osgeo.org/gdal/changeset/25107. So, do you
recommend me to change the code in ecwdataset.cpp and rebuild the library?
Thanks again!
José Antonio Carmena Flores
De: Even Rouault [via OSGeo.org] ml-node+s1560n5009874...@n6.nabble.com
Para: jcurru jcu...@yahoo.es
Enviado: Viernes 19 de octubre de 2012 14:42
Asunto: Re: Problem using image bands
Selon jcurru [hidden email]:
Hello!
I have a problem reading an ECW image. I want to read the image using only
the first band. So I use:
int bmap[3] = {1,1,1};
GDALImage-RasterIO(
GF_Read,
x, // int nXOff,
y, // int nYOff,
dx, // int nXSize,
dy, // int nXSize,
buffer, // void* pData,
xBufSize, // int nBufXSize,
yBufSize, // int nBufYSize,
GDT_Byte, // GDALDataType eBufType,
3, // int nBandCount,
bmap, // int* panBandMap,
3, // int nPixelSpace,
xBufSize * 3, // int nLineSpace,
1 // int nBandSpace
);
This is working well with some ECW images (they show as grayscale) but it
does not with another, big ECW. It shows in full RGB color, exactly the same
as if I had written int bmap[3] = {1,2,3};
I suppose you are using the 3.3 version of the ECW SDK ? Then, it is a known
issue in the SDK itself. See http://trac.osgeo.org/gdal/ticket/4234 . A work
around has been committed in the GDAL 2.0dev version just a few days ago.
For currently released GDAL versions, if you only want to read one band, you
could just use RasterIO() on the band object, instead of the whole dataset. If
you need to read it into a RGB buffer, you just need to keep the pixel space
and
line space you've used in the above call, and after calling RasterIO() on the
band, do a loop to copy each buffer[3*i] value into buffer[3*i+1] and
buffer[3*i+2]
Any idea?
Thanks in advance!
--
View this message in context:
http://osgeo-org.1560.n6.nabble.com/Problem-using-image-bands-tp5009873.html
Sent from the GDAL - Dev mailing list archive at Nabble.com.
___
gdal-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/gdal-dev
___
gdal-dev mailing list
[hidden email]
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.n6.nabble.com/Problem-using-image-bands-tp5009873p5009874.html
To unsubscribe from Problem using image bands, click here.
NAML
--
View this message in context:
http://osgeo-org.1560.n6.nabble.com/Problem-using-image-bands-tp5009873p5009885.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] Unable to create OGRSpatialReference
Thank you again, Even. Well, I've taken a look at the documentation you mention, but no answers there, just an explanation about wgsto84 parameters and a proposal for extending the geotiff standard in order to embed the famous parameter. I guess that if you don't say oh man, didn' you know this famous trick...? is because the trick does not exist. So, before I continue wasting your time, would you be so kind to answer this two questions? (yes/no will be enough) 1) Do I need the towgs84 parameters to properly do transformations between coordinate systems using proj4? 2) The only way to obtain that parameter is by using the epsg file, and therefore I MUST know the EPSG? Thak you! -- View this message in context: http://osgeo-org.1560.n6.nabble.com/Unable-to-create-OGRSpatialReference-tp5009903p5009950.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] Unable to create OGRSpatialReference
Frank, First of all let me tell you thanks for your work. Thanks is not enough but my poor english would put me in troubles if I tried to say something more complicated. And thank you very much for your answer. Getting help from you from the other side of the ocean (I live in Madrid, Spain) is a honor. I am not an expert in GIS, but despite of it I am writting a big GIS application. My colleages are supposed to be, but they have been unable to give me a solution to this subject, so, please, be so kind to tell me if this is ok: Ignoring the towgs84 parameters has proved to give bad results when transforming coordinate systems using proj4, even working with standard systems like ETRS89 (used in Spain) or ED50. Giving the correct towgs84 parameter the errors dissapeared completely. Therefore, I decided to write a descendant from OGRSpatialReference whose constructors throw exceptions if the towgs84 parameter cannot be found. For example, there's a constructor that receives an OGRSpatialReference pointer as argument (obtained, for example, from a shapefile, a tif, a LAS file, etc using GDAL). My class builds the underlying OGRSpatialReference with that pointer and then tries to obtain the towgs84 parameter. Somethimes it is present in the OGRSpatialReference object, most doesn't. Then I try to use the epsg. file if I can figure out the EPSG number. If everything fails then the constructor throws and the program asks for an EPSG to the user. And this is a pity because almost all the information I need is supplied by GDAL. The program is worst because it's not able to find out the famous parameter. You say: If you want to handle a datum shift properly and you don't know how the datum of your coordinate system relates to WGS84 then you are essentially out of luck. The problem is that my application should work with any projection. I cannot make assumptions or make a list of supported projections. My aim is to be able to get the towgs84 parameter whatever coordinate system the input files are projected into. I often use other programs to display geospatial information, for example Global Mapper. It realizes coordinate systems from (for example) shapefiles without EPSG, and applies transformations correctly. What am I missing? Sorry for my long message, but I've been overwhelmed with this problem for two years, and having you across the line gives me a hope. I'm sure there's a solution because many systems work fine. So thank you again. Sincerely yours, Jose Antonio. -- View this message in context: http://osgeo-org.1560.n6.nabble.com/Unable-to-create-OGRSpatialReference-tp5009903p5009971.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] Learning GDAL
Hi. I'm new to GDAL, but supposed to have some experience in C++. I'm trying to use GDAL in my project because CxImage, the image library I was using so far, is not able to deal with big images. After several days fighting against my compiler I could finally build gdal.lib (I'm using Builder C++, supposed not to be supported by GDAL). Now I'd like to start working with GDAL, but I can't find a start point. My first aim is to build a pyramid of tiles in a special format (no GeoTiff or ECW tiles, for example, but one I have designed to work with OpenGL). I'd like to be able to load arbitrary tiles from a tiff image (and then convert them to my format), but the only think I have found is that I have to work with bands. Well, I guess a band is something like a channel (R, G, B, Alpha...) but what I need are RGB tiles. As you can see, I'm slightly lost. So, could anybody tell me the way to learn about GDAL? I've been googling around but I can't find anything. Thanks a lot for your help! -- View this message in context: http://n2.nabble.com/Learning-GDAL-tp4939613p4939613.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] Compiling in Embarcadero's CBuilder
Hello. I'm trying to build gdal with Embarcadero's CBuilder++ 2010 (former Borland C++ Builder). I get this error in rasterio.cpp: [BCC32 Error] rasterio.cpp(869): E2335 Overloaded 'void CopyWordfloat(const float,float )' ambiguous in this context Full parser context rasterio.cpp(854): decision to instantiate: void void GDALCopyWordsComplexTfloat,float(const float * const,int,float * const,int,int) --- Resetting parser context for instantiation... rasterio.cpp(854): parsing: void void GDALCopyWordsComplexTfloat,float(const float * const,int,float * const,int,int) Can anybody help me? Thanks in advance -- View this message in context: http://n2.nabble.com/Compiling-in-Embarcadero-s-CBuilder-tp4930084p4930084.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: Compiling in Embarcadero's CBuilder
Thanks for your answer, Philippe. I could make rasterio.cpp compile by making the following change (line 38): // For now, work around MSVC++ 6.0's broken template support. If this value // is not defined, the old GDALCopyWords implementation is used. #define USE_NEW_COPYWORDS 1 #endif #undef USE_NEW_COPYWORDS // changed I guess gdal will use some kind of former strategie to copy bytes. I hope this will generate valid code. But you are telling me to file a ticket on GDAL's trac (http://trac.osgeo.org/gdal) and assign it to me (pvachon). Due to my poor english and lack of experience in this forum, I unfortunately don't know what you mean. Would you be so kind to explain it to me? Thanks again. -- View this message in context: http://n2.nabble.com/Compiling-in-Embarcadero-s-CBuilder-tp4930084p4933551.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
