I'm evaluating the new kmlsuperoverlay driver in trunk and have been unable
to get nodata values to show up as transparent in the output. Are there
format specific creation options I should be using?
- Jamie
___
gdal-dev mailing list
gdal-dev@lists.osge
Le lundi 11 octobre 2010 14:55:27, Timmie a écrit :
> Hello,
> is there a possibility to read sdc files [1] with gdal/ogr?
No
>
> If not, do you know any library that provides access to such data?
No, there's perhaps one though, but the link you've provided makes me be
pessimistic about that u
Sagar,
don't load the .so directly. Let gdal.jar do the dirty work for you !
Use the import org.gdal.XXX imports and then gdal.AllRegister() or
ogr.RegisterAll() instead.
See the examples in
http://trac.osgeo.org/gdal/browser/trunk/gdal/swig/java/apps
Le jeudi 07 octobre 2010 11:03:36, sagar_
Sebastian E. Ovide gmail.com> writes:
>
>
> yes, updating the metadata worked.
>
> Is there anyway to do it through ogr2ogr ?
>
> We are trying to replace shp2do with ogr2ogr as shp2do requires multiple steps
(create do, import it and then create the index by hand)... and for what I've
seen
Antonio,
I don't know much about the pre-built binaries for win32 except for what's
talked about here http://trac.osgeo.org/gdal/wiki/DownloadingGdalBinaries.
However, you might want to see what version of GDAL FwTools2.4.7
(http://fwtools.maptools.org/) is using for win32 binaries.
Sorry, i do
Hi Even,
actually, I was a bit too fast... I had no equiped 1.6.1 version, so I
"guessed" the result, from an output of one of the scripts I have.
Now that you told me, I reaccessed an old configuration to test it really, and
indeed it does not work, BUT :
when I have one image with several lay
Hi Frank and Even,
Thanks for your replies.
From what I can see, it is not related to the aux.xml files, because this
still works after deletion.
I must add that I have the same problem when working on .pix images, so it is
probably not driver specific... it may be specific to the SWIG or to pyt
Selon Matthieu Rigal :
Matthieu,
I can reproduce in trunk too. I'm not aware that this issue was known. I'm even
a bit surprised this has worked before as the SetDescription() method in
GDALPamRasterBand doesn't seem to have been ever overloaded, so a bit of
investigation is necessary.
In 1.6.x
Matthieu Rigal wrote:
Hi folks,
Currently running GDAL 1.7.1, I noticed a regression towards the 1.6.x branch
which I could not find in the tickets.
Teh GetDescription() always seems to return empty strings, except for just
created file and just setted description...
Here is a description
Hi folks,
Currently running GDAL 1.7.1, I noticed a regression towards the 1.6.x branch
which I could not find in the tickets.
Teh GetDescription() always seems to return empty strings, except for just
created file and just setted description...
Here is a description of the bug, I don't think
Hello,
is there a possibility to read sdc files [1] with gdal/ogr?
If not, do you know any library that provides access to such data?
Best regards,
Timmie
[1]: http://en.wikipedia.org/wiki/Smart_Data_Compression
___
gdal-dev mailing list
gdal-dev@list
Hi all,
I would like that every time a I use gdalwarp for some EPSG codes [1]
transformation it would use by default the nadgrids [2] (for Portugal and
Spain) that I have under the folder '/usr/share/proj/'.
For that purpose in PostGIS I needed to add
'+nadgrids=nadgrid_file_name.gsb' at the end
yes, updating the metadata worked.
Is there anyway to do it through ogr2ogr ?
We are trying to replace shp2do with ogr2ogr as shp2do requires multiple
steps (create do, import it and then create the index by hand)... and for
what I've seen with PostGIS, ogr2ogr is a single line operation How
I mean, you have points in your shape(s) too close to each other.
When you are importing them, oracle "interprets" them as the same point
(ORA-13356) or overlapping ones (ORA-13349).
ways to escape
- "simplify" your shapes - delete adjacent points (too close ones)
- change your metadata for the lay
you mean before importing the shapes ?
On Mon, Oct 11, 2010 at 10:39 AM, Michael Shishcu wrote:
> Also, this can be caused by too big tolerance of your coordinates, check
> this in your metadata
> regards, michael
>
> On 11 October 2010 12:28, Sebastian E. Ovide wrote:
>
>> Hi All,
>>
>> Importi
Also, this can be caused by too big tolerance of your coordinates, check
this in your metadata
regards, michael
On 11 October 2010 12:28, Sebastian E. Ovide wrote:
> Hi All,
>
> Importing shapes into Oracle I'm getting not valid geometrie: ORA-13349 and
> ORA-13356.
>
> No problem importing the
Hi Sebastian
did you verify geometries ? there is a tool in esri arcmap that
validates and fixes geometries, I kind of had the same problem but I
applied correction through arcMap , and it worked.
regards.
Imran
On Mon, Oct 11, 2010 at 2:28 PM, Sebastian E. Ovide
wrote:
> Hi All,
> Importing sh
Hi All,
Importing shapes into Oracle I'm getting not valid geometrie: ORA-13349 and
ORA-13356.
No problem importing the same shapes into PostGIS.
any ideas ?
--
Sebastian E. Ovide
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.
Hi Greg,
Il giorno Sun, 10 Oct 2010 18:04:32 -0700 (PDT)
gregcorradini ha scritto:
>
> Hey Hannes,
> I think most of your questions can be answered here
> http://trac.osgeo.org/gdal/wiki/GdalOgrInPython. Have you seen this?
> It covers how to install the Python bindings for GDAL 1.7.x and
> Pyt
19 matches
Mail list logo
