Hi,
On Thu, Aug 16, 2012 at 11:02 PM, Eli Adam wrote:
> > Band 1 Block=5000x1 Type=Int16, ColorInterp=Gray
> ...
> > Band 1 Block=1x1 Type=Float32, ColorInterp=Gray
> >
> > I can't see anything obvious why these two files can't be mosaiced..
> >
>
> It looks like one is 16 bit and the other
Benjamin maxsea.fr> writes:
> Thank to Even and Ari for theirs answers.
>
>
> // A copie from JTS InteriorPointArea Class (Java) for C#
> // See also : http://www.vividsolutions.com/jts/jtshome.htm
>
Perhaps it does not matter in this case but JTS home is nowadays at
http://tsusiatsoftwa
> Band 1 Block=5000x1 Type=Int16, ColorInterp=Gray
...
> Band 1 Block=1x1 Type=Float32, ColorInterp=Gray
>
> I can't see anything obvious why these two files can't be mosaiced..
>
It looks like one is 16 bit and the other 32. gdalbuildvrt probably
can't determine the type of output to create.
On Thu, Aug 16, 2012 at 5:24 PM, Nicolas Simon <
nicolas.si...@spw.wallonie.be> wrote:
> **
> Hello,
> The problem comes from the data type: Int16 for the first file,
> Float32 for the second file.
>
> Nicolas
>
>
> Thanks!
--
Dr. Margherita Di Leo
__
Hello,
The problem comes from the data type: Int16 for the first file, Float32 for
the second file.
Nicolas
-Message d'origine-
De : gdal-dev-boun...@lists.osgeo.org
[mailto:gdal-dev-boun...@lists.osgeo.org]De la part de Margherita Di Leo
Envoyé : jeudi 16 août 2012 17:15
À : Even R
On Thu, Aug 16, 2012 at 4:32 PM, Even Rouault
wrote:
> Selon Margherita Di Leo :
>
> > Hi All,
> >
> > On Mon, Jul 30, 2012 at 7:31 PM, Casper Børgesen (CABO) >wrote:
> >
> > > Hi!
> > >
> > > ** **
> > >
> > > I’m trying to create a VRT file from 4 GeoTIFFs using gdalbuildvrt.
> Three
> >
On 16 August 2012 16:03, Benjamin wrote:
> I had a look to JTS sources and write again the InteriorPointArea in C#.
> If someone want it I take it at the end of this email (and for others .NET
> users who google it).
http://code.google.com/p/nettopologysuite/source/browse/trunk/NetTopologySuite/A
Hi,
Even Rouault wrote
>
> To my knowledge there is no such method. If you don't have particular
> constraints on the point except that it must be at the interior of the
> polygon,
> you could take a random vertex of the boundary, compute the distance D to
> the
> next point, and then compute v
Selon Margherita Di Leo :
> Hi All,
>
> On Mon, Jul 30, 2012 at 7:31 PM, Casper Børgesen (CABO) wrote:
>
> > Hi!
> >
> > ** **
> >
> > Im trying to create a VRT file from 4 GeoTIFFs using gdalbuildvrt. Three
> > of the GeoTIFFs are created using OrthoVista and the last one created with
> >
Hi All,
On Mon, Jul 30, 2012 at 7:31 PM, Casper Børgesen (CABO) wrote:
> Hi!
>
> ** **
>
> I’m trying to create a VRT file from 4 GeoTIFFs using gdalbuildvrt. Three
> of the GeoTIFFs are created using OrthoVista and the last one created with
> an earlier version of the same program. When I
On Thu, Aug 16, 2012 at 8:53 AM, Evgeniy Borovenskiy
wrote:
> No, at the moment I use the variant in which the file '.tif' with the use of
> the driver GTiffDataset is created. And then through CreateCopy() JPEG2000 is
> created.
> I'd like to create a JPEG2000 file straigh away because the size
Selon Evgeniy Borovenskiy :
> No, at the moment I use the variant in which the file '.tif' with the use of
> the driver GTiffDataset is created. And then through CreateCopy() JPEG2000 is
> created.
> I'd like to create a JPEG2000 file straigh away because the size of images
> are very big and the
On 08/16/2012 03:09 PM, Even Rouault wrote:
Selon Benjamin :
> For example, with JTS (Java Topologie Suite) we can obtain an interior point
(0.5 2.5).
Do you know the name of the JTS method ? It might also exist in GEOS, the C++
port of JTS that GDAL relies on to do geometry related computation
Selon Benjamin :
> Hi,
>
> Is an OGR::Geometry method which compute an interior point exist ?
To my knowledge there is no such method. If you don't have particular
constraints on the point except that it must be at the interior of the polygon,
you could take a random vertex of the boundary, compu
No, at the moment I use the variant in which the file '.tif' with the use of
the driver GTiffDataset is created. And then through CreateCopy() JPEG2000 is
created.
I'd like to create a JPEG2000 file straigh away because the size of images are
very big and the intermediate file '.tif' can be more
Hi,
Is an OGR::Geometry method which compute an interior point exist ?
I have just found a Centroid() method but "The centroid is not necessarily
within the geometry".
So the centroid of:
POLYGON ((0 0,0 5, 5 5, 5 4, 1 4, 1 1, 5 1, 5 0, 0 0)) is near to (2 2.5),
it's within the polygon.
_
|
On 16 August 2012 12:11, Even Rouault wrote:
>
> By the way pDataset->~GDALDataset() is a weird syntax. I've never used that in
> any C++ code, so I am wondering if this completely destroys the object
The only and typical situation when destructor is called explicitly is when
object is allocated
On Thu, 16 Aug 2012, Even Rouault wrote:
The rgdal source is part C (for proj), part C++ for OGR/GDAL, but C++
written by C-minded people, so no new classes, but using C++ OGR/GDAL
classes, things like: pDataset->~GDALDataset();.
Ah ok, so rgdal uses the GDAL C++ API (when feasable, the use
Even Rouault wrote:
> Note: yesterday after your emails, I've revised substantially how escaping
> was done in the WFS driver, because there were cases where URL-escaping
> would have been needed (for example if you passed '&' or '%'), so now for
> 'ä', you should see 25-43-33-25-41-34 (but that
Selon Evgeniy Borovenskiy :
> The thing is when I try to save the buffer with an image that is being saved
> in the operative memory when my program is working and when the KAKADU's
> driver tries to create JPEG2000 for the file recording the driver isn't
> created. It's because there's no functio
> The rgdal source is part C (for proj), part C++ for OGR/GDAL, but C++
> written by C-minded people, so no new classes, but using C++ OGR/GDAL
> classes, things like: pDataset->~GDALDataset();.
Ah ok, so rgdal uses the GDAL C++ API (when feasable, the use of the C API is
encouraged to avoid ABI
The thing is when I try to save the buffer with an image that is being saved in
the operative memory when my program is working and when the KAKADU's driver
tries to create JPEG2000 for the file recording the driver isn't created. It's
because there's no function 'Create' in JP2KAKDataset. But t
Selon Jukka Rahkonen :
> I think this is my last question about WFS and URL-encoding this time.
>
> I had a look how the WFS requests look in hexadecimals.
>
> My TinyOWS and Mapserver WFS both accepts two ways to express letter "ä"
> inside
> ogc:Filter with http GET. First of those alternatives
On 2012/08/16 11:43, Vincent Schut wrote:
On 08/16/12 11:14, Zoltan Szecsei wrote:
But the software I want to use this tif-DEM in complains:
Error encountered while reading GeoTIFF file: Elevation data must
be specified as 32-bit floating point samples.
Hi Zoltan,
you can add "-ot Float32"
On 08/16/12 11:14, Zoltan Szecsei wrote:
Hi,
I've downloaded srtm_41_19 both in tiff and ASCII formats.
I reproject the tiif image such:
gdalwarp -t_srs '+proj=tmerc +lat_0=0 +lon_0=21 +k=1 +x_0=0 +y_0=0
+ellps=WGS84 +datum=WGS84 +units=m +no_defs' srtm_41_19.tif srtm_lo21.tif
and gdalinfo prod
On Thu, 16 Aug 2012, Even Rouault wrote:
Selon Roger Bivand :
gcore/gdal_version.h gives us the hard-wired compile-time version string.
GDALVersionInfo("--version") gives us the version known by the runtime. We
can
use GDALCheckVersion() to check that the two match (in rgdal/R). But is the
SVN
Hi,
I've downloaded srtm_41_19 both in tiff and ASCII formats.
I reproject the tiif image such:
gdalwarp -t_srs '+proj=tmerc +lat_0=0 +lon_0=21 +k=1 +x_0=0 +y_0=0
+ellps=WGS84 +datum=WGS84 +units=m +no_defs' srtm_41_19.tif srtm_lo21.tif
and gdalinfo produces realistic values.
But the software I
I think this is my last question about WFS and URL-encoding this time.
I had a look how the WFS requests look in hexadecimals.
My TinyOWS and Mapserver WFS both accepts two ways to express letter "ä" inside
ogc:Filter with http GET. First of those alternatives is an UTF-8 letter "ä" in
URL-encode
Selon Roger Bivand :
> gcore/gdal_version.h gives us the hard-wired compile-time version string.
> GDALVersionInfo("--version") gives us the version known by the runtime. We
> can
> use GDALCheckVersion() to check that the two match (in rgdal/R). But is the
> SVN
> revision number exposed in the s
gcore/gdal_version.h gives us the hard-wired compile-time version string.
GDALVersionInfo("--version") gives us the version known by the runtime. We can
use GDALCheckVersion() to check that the two match (in rgdal/R). But is the SVN
revision number exposed in the same way? A rgdal user on OpenSUSE
30 matches
Mail list logo
