On Fri, Nov 14, 2008 at 04:06:24PM -0800, Gregor Mosheh wrote:
> What possibilities exist for WMS-C support in GDAL?
>
> Specifically, we're looking for a mechanism to consume WMS-C via
> MapServer using PHP/MapScript.
>
> Any ideas at all?
The WMS driver documentation shows consuming a WMS-C s
What possibilities exist for WMS-C support in GDAL?
Specifically, we're looking for a mechanism to consume WMS-C via
MapServer using PHP/MapScript.
Any ideas at all?
--
Gregor Mosheh / Greg AllensworthBS, A+, Network+, Security+, Server+
System Administrator, Lead Programmer
HostGIS devel
Even,
I compiled the beta and now it works. Thanks!
For the record, I'm using the GNU tools.
Chris
On Fri, Nov 14, 2008 at 1:25 PM, Even Rouault
<[EMAIL PROTECTED]>wrote:
> Chris,
>
> I'd bet too that you are hitting a problem with unaligned access on Sparc
> architecture when dereferencing s
The datum change isn't sufficient, as they are using different coordinate
systems. They actually have to have the same SRS, otherwise gdal_rasterize
will see 2 very different ranges of coordinates (meter vs latlong).
PROJCS["OSGB 1936 / British National Grid",
GEOGCS["OSGB 1936",
DATU
Is it possible to install the proj-datumgrid-1.4 files in FWTools?
Thanks,
Roger
--
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Thanks for the help everyone, I'll summarise when I get it all working ;-)
Jamie Adams <[EMAIL PROTECTED]> wrote:
>
> Are your files in the same projection? I know gshhs is projected in wgs84
> by default, and I see your raster is in British National Grid.
To what extent do they need to be in t
Ed,
Looking at your gdalwarp call, it seems that you've omitted the
projection parameters. Based on your description of the projection, I
would expect a gdalwarp call such as the following:
gdalwarp -s_srs "+proj=lcc +lat_1=33 +lat_2=45 +lat_0=40 +lon_0=-97
+a=637 +b=637 +x_0=0 +y_0
Chris,
I'd bet too that you are hitting a problem with unaligned access on Sparc
architecture when dereferencing some pointers that is present in the
TIFFWriteDirectorySec function of the internal libtiff in GDAL 1.5.X
(I don't think that the compiler used would make any difference.)
This prob
> int sceneWidth = (int)(nXSize * maxWidth / (double)maxWidthAtL0 + 0.99);
> int sceneHeight = (int)(nYSize * maxHeight / (double)maxHeightAtL0 + 0.99);
Ouch, you shouldn't be doing rounding like that. Use the getDimsAtMag()
function to get the exact width/height you need and all will be well.
Chris Garrard wrote:
Hi,
I've compiled GDAL 1.5.3 on Solaris 10, using internal support for tiff
and gtiff. When I try to create a new GTiff using gdal_translate, it
fails with "OBus Error". That's all the information I get.
The problem is only with writing GTiffs, not reading them. I can
edfialk wrote:
Hello, I'm fairly new to reprojection and my experience with gdal is limited,
so I'll do my best to keep up. I have tried searching through a number of
messages without finding anything quite like my problem.
I've been completely unsuccessful trying to reproject a netcdf file for
Hi,
I've compiled GDAL 1.5.3 on Solaris 10, using internal support for tiff and
gtiff. When I try to create a new GTiff using gdal_translate, it fails with
"OBus Error". That's all the information I get.
The problem is only with writing GTiffs, not reading them. I can convert a
tiff to another
Stephen Woodbridge wrote:
Frank,
Here is what I get from the debug output. I'm a little surprised it is
trying to extract from zoom 1 instead of zoom 0. I didn't think I was
scaling this but maybe some rounding is causing that.
...
GDAL: GDALDriver::Create(GTiff,out.tif,6029,6029,3,Byte,0x86
Stephen Woodbridge wrote:
Jukka Rahkonen wrote:
>> Hi,
>>
>> There is absolutely something basically wrong. For that little files
>> conversion
>> to GeoTIFF should take perhaps 5 minutes. Try skipping more drivers and see
>> how
>> Kakadu driver performs. If you want to know how fast i
Frank Warmerdam wrote:
Stephen Woodbridge wrote:
Frank,
If someone can generate a patch the prints this stuff out, I'll have
our guys build a version with the patch and I'll run it against one of
the cases that fails.
There wouldn't happen to be a hidden debug option that might already
pri
On Fri, Nov 14, 2008 at 6:06 PM, edfialk <[EMAIL PROTECTED]> wrote:
>
> Hello, I'm fairly new to reprojection and my experience with gdal is limited,
> so I'll do my best to keep up. I have tried searching through a number of
> messages without finding anything quite like my problem.
>
> I've been
Hello, I'm fairly new to reprojection and my experience with gdal is limited,
so I'll do my best to keep up. I have tried searching through a number of
messages without finding anything quite like my problem.
I've been completely unsuccessful trying to reproject a netcdf file for some
time now a
Jukka Rahkonen wrote:
Stephen Woodbridge swoodbridge.com> writes:
PPS. I don't understand your point where you seem to suggest that
converting
to tiff first is slower than other mechanisms. Are you suggesting it takes
2-3 hours to convert a 500MB jpeg2000 image to GeoTIFF? Perhaps you nee
Stephen Woodbridge wrote:
Frank,
If someone can generate a patch the prints this stuff out, I'll have our
guys build a version with the patch and I'll run it against one of the
cases that fails.
There wouldn't happen to be a hidden debug option that might already
print this out?
Thank you
Hello,
Some informations about our driver :
- It uses existing OGR GML driver to parse WFS server message and knows only gml 1.0 answer, so you must specified
answer in gml 1.0 in your requests to the server. It should not be difficult to add zipped gml, but for another format
(such as shape) i
Hi Frank,
I could find out that this bug was due to an older version of GDAL, v1.4.2 and
probably bindings to older version of libtiff and so.
On another configuration with GDAL 1.5.1, the problem is not any more
encountered.
Best regards,
Matthieu
On Thursday 13 November 2008 18:13:17 you wr
Hi Frank,
Thanks for your response.
I made the error of mixing one gdal_utility question and a Python-GDAL binding
question.
The problem I am encountering with gdal_translate and gdalinfo with these very
little files only happens when I am working on very small images. Else, it is
working well
22 matches
Mail list logo
