Girish,
You might find some answer here:
http://grasswiki.osgeo.org/wiki/S-57_data
rgds,
Sylvain.
On Tuesday, March 11, 2014 4:22:39 PM, Girish Deshpande
wrote:
Hello,
>
>
>I am able to render s57 chart in my application using gdal, i am finding
>difficulty in filling the areas with
On 03/11/2014 02:06 AM, Jonathan Moules
wrote:
TIFF stores floating point values as IEEE754 floats.
Talking about significant
figures doesn't m
You email should be sent to the qgis-developer list (this is the gdal-dev
list), which I am forwarding this to.
On Tue, Mar 11, 2014 at 7:44 AM, Nicholas Duggan
wrote:
> Hi all,
>
> I'm trying to get my fix for the OSGB36 to WGS84 using Ordnance Surveys
> OSTN02 (NTv2) transformation into the QG
Selon Vincent Mora :
>
> On 11/03/2014 10:39, Even Rouault wrote:
> > If you want to test the compliance of your driver (the read part) with the
> > assumptions of the OGR API, you can go to the apps subdirectory of GDAL and
> > "make test_ogrsf", and then "test_ogrsf a_wasp_file".
> Thanks for th
On 11/03/2014 10:39, Even Rouault wrote:
If you want to test the compliance of your driver (the read part) with the
assumptions of the OGR API, you can go to the apps subdirectory of GDAL and
"make test_ogrsf", and then "test_ogrsf a_wasp_file".
Thanks for the tip.
It helped me fix some issues
Hi List,
I've created a GeoTIFF with GDAL. It works fine in QGIS and ArcMap, but
MapInfo refuses to load it, giving me a "Image file open error" message.
I've come across several problems and was wondering if anyone else had
experience with GDAL created files in MapInfo.
Problems:
1) MapInfo can'
Hi all,
I'm trying to get my fix for the OSGB36 to WGS84 using Ordnance Surveys OSTN02
(NTv2) transformation into the QGIS master. Nathan Woodrow recommended I bring
it up with you guys who might be able to implement it.
Essentially I've updated the QGIS srs.db and put the OSTN02_NTv2.gsb in t
Hi Even,
Thanks for the information.
> >
> > I tried the Float64 but the values are identical (16 significant figures)
> > even though the filesize is predictably larger.
> >
> > I guess I'll have to make do, but it does introduce the problem of False
> > Precision.
>
> Very few formats take into
>
> Hi Even,
> Thanks for the information. I don't pretend to understand the fine details
> of floats, but it does seem counter intuitive that a simple 2 or 3 decimal
> places can't be accurately represented.
Yes this is really counter intuitive. I've just tested with the Python console
that 50.59
Hi Vincent,
> The driver is now R/W.
ok I now realize that oErrorRegion.Intersect( oEnvelope ) is on the OGREnvelope
class and not OGRGeometry (in later case it is a boolean operation, hence my
erroneous note).
If you want to test the compliance of your driver (the read part) with the
assumption
The driver is now R/W.
Thanks for your comments (answer below).
On 09/03/2014 19:58, Even Rouault wrote:
Hi,
my quick review :
- ogrwaspdatasource.cpp :
* change author and copyright to yours
Done.
* why do you need #ifdef _WIN32
# include
#endif
Not needed indeed, removed.
* G
>
> TIFF stores floating point values as IEEE754 floats. Talking about
> significant
> figures doesn't make much sense. You could test using Float64 with the hope
> that 50.597 can be exactly represented as a Float64. Otherwise you'll have
> to
> do the rounding when reading back from TIFF.
>
Hi
12 matches
Mail list logo
