Re: [gdal-dev] NLCD images and north

2013-12-09 Thread David Strip 
I downloaded some NLCD test data (roughly Washington DC, for what it's
worth) using the NationalMap viewer and I see the apparent rotation, but
actually it's not rotated. I suspect you are seeing the same phenomenon.
Your download includes, among other files, a .tif file with the image,
and a .tfw file that defines the "world" in terms of the projection
defined in the .prj file. In my  experiment the .tfw file shows no
rotation (entries 2 and 3 are equal to 0). However, the projection is an
Albers Equal Area projection, so the image boundaries don't align to the
tif boundaries. If you open your file in something like qgis and set the
projection to the appropriate UTM zone or similar projection, you'll
probably get what you're expecting - a north-south rectangle containing
your data. At least that's what happened when I tried it. (And of course
that's what it should be according the .tfw file)
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] NLCD images and north

2013-12-09 Thread Jo Meder 
Hi,

I have a land cover raster from NLCD via the USGS National Map. The actual data 
is rotated something like 15º inside the raster. Using the API where would I 
start to rotate it to north up? I am presuming that the data isn't north up 
already, for example the Y axis of the raster doesn't actually represent north 
relative to the features in the image, but I may be wrong! When I overlay it on 
imported DEM data it definitely seems to be rotated. The corner coordinates of 
the data are also rotated.

Sorry for this rather vague question but I'd appreciate any starting points.

Regards,

Jo Meder


___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] JPEG2000 read performance with OpenJPEG

2013-12-09 Thread Jo Meder 
Hi,

I'm using GDAL 1.10.1 and OpenJPEG on OS X, to read JPEG 2000 orthophotos from 
the USGS National Map. The performance seems really, really poor. I'm using 
GDALRasterBand::RasterIO() to read a scanline at a time. It's been running 
about 10 minutes now without reading one scan line. At the moment I have 
disabled threads in GDAL but it was very slow with threads as well.

I have tried gdal_translate to convert the image to a GeoTIFF and that is very 
slow but does write the file out in 5 minutes or so. The image is 5540 x 7630.

Would it be worth reading the image in blocks? I would just try it but it will 
take some rearranging of code so I thought I would ask if anyone has 
experienced this same performance problem and had any insights on a solution.

Thanks,

Jo Meder


___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Vector geospatial data format for massive quantities of (poly)lines

2013-12-09 Thread Phil Scadden 
There is also the Contouring WPS in geoserver. Beyond that I would look 
at storage in PostGIS.


Notice: This email and any attachments are confidential.
If received in error please destroy and immediately notify us.
Do not copy or disclose the contents.

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Vector geospatial data format for massive quantities of (poly)lines

2013-12-09 Thread Jukka Rahkonen 
Chris Hanson  alphapixel.com> writes:

> 
> 
>   An application my client is pursuing involves generating and displaying
linework (contours) for state-sized areas. These will be (among other
things) displayed via Geoserver.
> 
> 
> 
> 
>   We are able to generate the contour data with gdal, but the output is
now exceeding the 2GB format limit of Shapefiles.
> 
>   I'm wondering if anyone has any recommendations for a format or other
strategy for handling large data like this? I think in the end we may end up
breaking it up into tiles, but figured I'd ask first.

Hi,

Spatialite is flexible and fast and quite easy to create at least up to 10
GB db file size. However, Java and native Spatialite binaries are tricky to
put to play together. The Spatialite community module is probably easy to
install
http://docs.geoserver.org/latest/en/user/community/spatialite/index.html but
it seems to use Spatialite version 2.4.0 while the current one is 4.1.0 and
I wouldn't recommend that.

However, Paul Ramsey is working on GeoPackage driver for GDAL and Boundless
is building a GeoPackage community module for Geoserver so perhaps the
answer is OGC GeoPackage, the shapefile of the hopefully near future.

-Jukka Rahkonen- 

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] Vector geospatial data format for massive quantities of (poly)lines

2013-12-09 Thread Chris Hanson 
  An application my client is pursuing involves generating and displaying
linework (contours) for state-sized areas. These will be (among other
things) displayed via Geoserver.

  We are able to generate the contour data with gdal, but the output is now
exceeding the 2GB format limit of Shapefiles.

  I'm wondering if anyone has any recommendations for a format or other
strategy for handling large data like this? I think in the end we may end
up breaking it up into tiles, but figured I'd ask first.

-- 
Chris 'Xenon' Hanson, omo sanza lettere. xe...@alphapixel.com
http://www.alphapixel.com/
Training • Consulting • Contracting
3D • Scene Graphs (Open Scene Graph/OSG) • OpenGL 2 • OpenGL 3 • OpenGL 4 •
GLSL • OpenGL ES 1 • OpenGL ES 2 • OpenCL
Digital Imaging • GIS • GPS • osgEarth • Terrain • Telemetry • Cryptography
• Digital Audio • LIDAR • Kinect • Embedded • Mobile • iPhone/iPad/iOS •
Android
@alphapixel  facebook.com/alphapixel (775)
623-PIXL [7495]
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Adding driver in run time

2013-12-09 Thread Even Rouault 
Le dimanche 08 décembre 2013 17:31:43, Victor Fine a écrit :
> Hello,
> 
> I'm trying to write a driver , inside my program that uses GDAL (C++).
> 
> After the call to GDALAllRegister(); I call GDALRegister_MYDEM(),
> which is much like in the example in
> http://www.gdal.org/gdal_drivertut.html
> 
> After that, I try to call GDALOpen on some file and the breakpoint in
> the .. *MYDEMDataset::Open(...) function is not even hit.
> (And , of course, I get a message that this is not a recognized format).
> 
> It seems that I have some beginners mistake here - why does GDAL
> ignores my driver?

If the application compiles, links and runs, nothing immediately strikes me as 
a potential error, but perhaps you could enumerate all the registered drivers 
and check if yours is listed ?

for(i=0;ihttp://even.rouault.free.fr/services.html
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Default GeoTransform for MEM driver

2013-12-09 Thread Even Rouault 
Le lundi 09 décembre 2013 18:08:19, Ivan Lucena a écrit :
> The other problem with that documentation is the return code. CE_Failue
> means that the driver does not support it and/or that the dataset doesn't
> have it.

The current behaviour of the MEM driver doesn't particularly shock me. It 
seems OK to return CE_Failure if SetGeoTransform() hasn't been explicitely 
called to define it. And as far as the default geotransform, it is a matter of 
taste. [ 0, 1, 0, 0, 0, 1] would be indeed a bit more classical for a 
ungeoreferenced image, but one can consider that if GetGeoTransform() returns 
CE_Failure, the returned geotransform is to be ignored.

To answere Tim's initial question {0, 1, 0, 0, 0, -1} is a north-up image :  
(0,0) is the coordinate of the upper left of the top left pixel, and y values 
are decreasing with image rows.

Even

-- 
Geospatial professional services
http://even.rouault.free.fr/services.html
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Default GeoTransform for MEM driver

2013-12-09 Thread Ivan Lucena 
The other problem with that documentation is the return code. CE_Failue means 
that the driver does not support it and/or that the dataset doesn't have it. 

From: tke...@utexas.edu
Date: Mon, 9 Dec 2013 10:55:34 -0600
To: jukka.rahko...@mmmtike.fi
CC: gdal-dev@lists.osgeo.org
Subject: Re: [gdal-dev] Default GeoTransform for MEM driver

Right. Thanks for checking into it.
I guess I was thrown by 
http://www.gdal.org/classGDALDataset.html#af9593cc241e7d140f5f3c4798a43a668


which gives the default as {0, 1, 0, 0, 0, +1}.
Is there a library wide convention on this? I can update the docs if so. (I 
assume its a simple pull and send a diff type setup.)


THK

On Sun, Dec 8, 2013 at 11:27 PM, Jukka Rahkonen  
wrote:


Tim Keitt  gmail.com> writes:





>

> I notice that the "MEM" driver returns {0, 1, 0, 0, 0, -1} by default. Is

this a bug or do some formats flip the vertical axis? If so, what is the

convention for detecting and handling "south up" formats in code?



I guess that anchor point is at the top left corner and therefore the north

coordinate is decreasing step by step when you walk downwards. Document

http://www.gdal.org/gdal_tutorial.html supports my thoughts.



-Jukka Rahkonen-







___

gdal-dev mailing list

gdal-dev@lists.osgeo.org

http://lists.osgeo.org/mailman/listinfo/gdal-dev



-- 
http://www.keittlab.org/


___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
  ___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Default GeoTransform for MEM driver

2013-12-09 Thread Tim Keitt 
Right. Thanks for checking into it.

I guess I was thrown by
http://www.gdal.org/classGDALDataset.html#af9593cc241e7d140f5f3c4798a43a668

which gives the default as {0, 1, 0, 0, 0, +1}.

Is there a library wide convention on this? I can update the docs if so. (I
assume its a simple pull and send a diff type setup.)

THK


On Sun, Dec 8, 2013 at 11:27 PM, Jukka Rahkonen
wrote:

> Tim Keitt  gmail.com> writes:
>
> >
> > I notice that the "MEM" driver returns {0, 1, 0, 0, 0, -1} by default. Is
> this a bug or do some formats flip the vertical axis? If so, what is the
> convention for detecting and handling "south up" formats in code?
>
> I guess that anchor point is at the top left corner and therefore the north
> coordinate is decreasing step by step when you walk downwards. Document
> http://www.gdal.org/gdal_tutorial.html supports my thoughts.
>
> -Jukka Rahkonen-
>
>
>
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>



-- 
http://www.keittlab.org/
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Adding driver in run time

2013-12-09 Thread Volker Wichmann 

On 12/08/2013 05:31 PM, Victor Fine wrote:

Hello,

I'm trying to write a driver , inside my program that uses GDAL (C++).

After the call to GDALAllRegister(); I call GDALRegister_MYDEM(),
which is much like in the example in
http://www.gdal.org/gdal_drivertut.html

After that, I try to call GDALOpen on some file and the breakpoint in
the .. *MYDEMDataset::Open(...) function is not even hit.
(And , of course, I get a message that this is not a recognized format).

It seems that I have some beginners mistake here - why does GDAL
ignores my driver?

Regards,
Victor.


Hi Victor,

did you add your driver to the GDAL tree (i.e. in 
gdal/gcore/gdal_frmts.h and frmts/gdalallregister.cpp) like described in 
the tutorial you mention?


Volker


___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev



___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev