Unless there's something I'm not understanding, it seems there is a highly
visible bug in OGRGeometryTypeToName() in GDAL 1.9.2. Namely, it says that
all 3D types are 2D, and 2D types are 3D. See ogrgeometry.cpp:
bool b25D = wkbFlatten(eType) != eType;
switch( wkbFlatten(eType) )
{
I needed to build GDAL on WIndows again this evening, so I grabbed the
latest gdal192.zip.
For years (like, 12 years) I have tried maintaining GDAL MSVC project files,
but that isn't a fun task.
So instead, I figured I'd give the makefile.vc a try.
It does not appear to be in a state that's
, e.g. what are
valid arguments to SetVertCS which can produce a valid result when
transforming from geocentric?
-Ben
-Original Message-
From: Rodolfo Bonnin [mailto:rodolfobon...@suremptec.com.ar]
Sent: Tuesday, August 23, 2011 6:12 AM
To: Ben Discoe
Subject: Re: [gdal-dev] Geocentric
-
From: Even Rouault [mailto:even.roua...@mines-paris.org]
Sent: Tuesday, August 23, 2011 11:33 AM
To: gdal-dev@lists.osgeo.org
Cc: Ben Discoe; 'Rodolfo Bonnin'
Subject: Re: [gdal-dev] Geocentric Coordinate System Support
Le mardi 23 août 2011 19:28:49, Ben Discoe a écrit :
My
Hi folks,
The issues of geocentric CS and vertical CS are distinct, but they are related
in an important way: Geocentric coordinates are not very useful to the GIS
world unless they can be converted to orthometric (sea level) heights, which
involves a vertical CS.
Currently, the
Frank et al.,
I am testing the Geocentric support; in particular, the ability to transform
from Geocentric to a SRS with a vertical datum.
Since Geocentric was committed in March, and GDAL 1.8.1 was released in
July, i thought that 1.8.1 might contain the Geocentric support. But, it
does not
I'd add that wildfire simulation and visualization has been done on a Open
stack, such as:
Application for planning assistance suppression forest fires based on free
software.
2008, in Spanish.
http://dugi-doc.udg.edu/bitstream/10256/1182/1/VicedoLinares_Art.pdf
gvSIG, PostGIS, VTP (GDAL,
James,
In this case, it may be simpler, easier and more efficient to simply call
the NetCDF library directly, rather than going through GDAL. Your
particular file sounds like a 3D dataset, which is stretching the bounds of
what GDAL is designed to handle, namely rasters.
The NetCDF API is
4.8.0 on
there is support.. when we haven't reached that version yet.
-Ben
-Original Message-
From: Even Rouault [mailto:even.roua...@mines-paris.org]
Sent: Wednesday, August 17, 2011 11:13 AM
To: gdal-dev@lists.osgeo.org
Le mercredi 17 aot 2011 03:24:58, Ben Discoe a crit
It is true that geocentric XYZ coordinates are not very useful, without being
able to convert them to coordinate with orthometric (geoid) (sea level)
height.
Frank implemented 'preliminary' support for this, which i am preparing to test
now. Before expecting it to work in GDAL/OGR, i thought
I tried building GDAL 1.7.3 this evening and found that it did not support the
new libpng 1.5.0.
I also looked at the archive for GDAL 1.8.0 RC2, and it seems to have the same
code in question.
The changes are small, just a few like this:
VSIFFlushL( (png_FILE_p)
11 matches
Mail list logo
