Even,
re use case 1) below. One instance where the raw data format might be
required is where that encoding contains characters that are not present in an
output encoding and specific action is to be taken to render such characters in
a transmittable form in the output character set.
Best
Hi,
I like testing the capabilities of GDAL/OGR to export from a GML to a DXF.
I create a very simple file header.dxf and ask to OGR to export a test file
GML to dxf.
The file header.dxf I create has simply this 4 rows:
---
0
SECTION
2
HEADER
---
But when I start ogr2ogr it stop with an error re
Thanks alot. I'll try that.
Mateusz Loskot wrote:
> On 25/05/10 10:53, ben...@cs.its.ac.id wrote:
>> Hi, I tried to run the example in the tutorial. But I've got an
>> unhandled
>> exception at the GDALAllRegister(). This is the call stack:
>>
>> [...]
>> Oh yeah BTW I build GDAL from its source,
Nevermind, I just built gdal-1.6.3 from source with the Geo_DSDK which
is good enough for now. I need to move the sid files then I can start
working on them.
-Steve
Stephen Woodbridge wrote:
Hi all,
What is the best way to build gdal with MrSID support for CentOS 5?
How does one tell if it i
Alexander,
I'm cc'ing Gaige Paulsen as he proposed in
http://trac.osgeo.org/gdal/ticket/3403 a patch with a similar approach to
yours, that is to say provide a method at the OGRLayer level to return the
encoding.
The more I think to this issue the more I recognize that the "UTF-8 everywhere
i
Hi all,
What is the best way to build gdal with MrSID support for CentOS 5?
How does one tell if it is CentOS 5.2 or 5.3?
The package manager installed:
(1/6): gdal-devel-1.4.4-2.el5.rf.x86_64.rpm | 70 kB
(2/6): geos-3.1.0-1.el5.rf.x86_64.rpm| 265 kB
(3/6): uni
Hi,
GIS-Lab community has worked on this and here is our results.
We develop a patch which add two methods GetEncoding and SetEncoding.
At this time only GetEncoding for shapefiles is realised. With this
methods programmer can get encoding programmatically. Patch
uploaded to the bugtracker: http:/
Ivan,
This sounds very much like the classic problem with HDF and netCDF where the
formats are extremely flexible and allow data to be stored in a variety of
ways, but the data providers could not all agree on the same way of doing
it. Different providers adopted different conventions such as HDF-
Hello!
I'm using "gdal_translate" 1.7.1 to create a local png file, by WMS
protocol, from GeoServer 2.0.1.
The file created by WMS is ok. When I try to access the same content
by tiled WMS (WMS-C) the file generated is not quite right.
The difference is on the top right corner of the generated i
It look like pyHDF know more about the HDF SD dimensions than the other
software, including GDAL:
>>> from pyhdf.SD import *
>>> d = SD('D:\\tmp\\3B430501016.HDF')
>>> d.datasets()
{'precipitation': (('scan', 'longitude', 'latitude'), (1, 1440, 400), 5, 0),
'relativeError': (('scan', 'longitude'
this
Best regards,
Antonio
__ Information from ESET NOD32 Antivirus, version of virus signature
database 5144 (20100525) __
The message was checked by ESET NOD32 Antivirus.
http://www.eset.com
___
gdal-dev mailing list
gda
António Rocha wrote:
Hi
I'm trying to Warp a Landsat Geotiff band (in UTM coordinates) to a
specific set of coordinates for Portugal, using this command:
gdalwarp -t_srs "EPSG:3763" L71203033_0332601_B10.TIF B10.tif &>log.log
Not only the image size doesn't match, but pixel size was chang
Thanks, I'll go for LZW.
Just for clarity : 4 GB was the size of the smaller set that I used for the
tests. I expect the full LZW pyramid to be around 500 GB. The JPEG pyramid
is 125 GB.
--
View this message in context:
http://osgeo-org.1803224.n2.nabble.com/gdal-retile-and-nodata-tp5079895p509
Helge Morkemo wrote:
Have you made these changes after the 1.7.2 release?
I have tested some more.
The problem occurs when I use PHOTOMETRIC=YCBCR, not when I use =RGB.
I've tried setting INTERLEAVE=PIXEL too, but that didn't help (yes, I
know it's the default).
Anything else I can try?
Helg
Hmm, jpeg is not a lossless compression, LZW is lossless. It appears
that we have a problem beyond our scope. I never use jpeg and prefer
LZW or png. I would go with LZW, this is the safe way.
4 GB are not dramatically. I store my tiles/pyramids in a database
prepared for geoserver, there
On 25/05/10 10:53, ben...@cs.its.ac.id wrote:
Hi, I tried to run the example in the tutorial. But I've got an unhandled
exception at the GDALAllRegister(). This is the call stack:
[...]
Oh yeah BTW I build GDAL from its source, not the pre-compiled one. And I
use the vcproject that uses nmake.
Have you made these changes after the 1.7.2 release?
I have tested some more.
The problem occurs when I use PHOTOMETRIC=YCBCR, not when I use =RGB.
I've tried setting INTERLEAVE=PIXEL too, but that didn't help (yes, I know
it's the default).
Anything else I can try?
___
ed. No more will be
reported from now.
...60...70...80...90...
Segmentation fault
__ Information from ESET NOD32 Antivirus, version of virus signature
database 5143 (20100525) __
The message was checked by ESET NOD32 Antivirus.
http://www.eset.com
__
Hi, I tried to run the example in the tutorial. But I've got an unhandled
exception at the GDALAllRegister(). This is the call stack:
msvcr90d.dll!1024082a()
[Frames below may be incorrect and/or missing, no symbols loaded for
msvcr90d.dll]
msvcr90d.dll!102402e6()
m
On 05/20/2010 01:38 AM, Even Rouault wrote:
Hamish,
I've taken some time to experiment a bit with GRASS and GRASS behaviour is
correct of course, so sorry for the noise.
I've finally identified why gdaldem (and initially Matt's hillshade utility)
got it wrong. GRASS r.mapcalc atan(x,y) function
Back from week-end, sorry for interrupting the conversation.
I tried setting a -a_nodata 255 value before creating the pyramid, the
result is exactly the same as with black nodata or without a nodata value.
The nodata value of the original geotiffs is ignored.
> First an image is created, larg
Back from week-end, sorry for interrupting the conversation.
I tried setting a -a_nodata 255 value before creating the pyramid, the
result is exactly the same as with black nodata or without a nodata value.
The nodata value of the original geotiffs is ignored.
> First an image is created, larg
Back from week-end, sorry for interrupting the conversation.
I tried setting a -a_nodata 255 value before creating the pyramid, the
result is exactly the same as with black nodata or without a nodata value.
The nodata value of the original geotiffs is ignored.
> First an image is created, larg
23 matches
Mail list logo
