[gdal-dev] Fast Pixel Access

[David Baker (Geoscience)]

Dev's,

I have a set of 55,501 bil files in a single directory.  They are DEMS data 
that cover the US in 7.5 minute tiles.  I would like to randomly access 
elevations at a given lat/lon's from the whole dataset.  I created a vrt file 
from the directory of bil files, and have been able to access the elevation at 
a given lat/lon using gdallocationinfo, but because of the size of the dataset, 
this operation is somewhat slow.  Can the vrt be indexed? Or, is there a 
faster, better way to access the pixels?  I would first like to do this with 
the utilities before diving into code (C#).  The files are regularly named base 
on their location within a 1 arc-second grid.

Thanks,
David

David M. Baker
Senior Advisor - Geoscience Technology
Chesapeake Energy Corporation
david.m.ba...@chk.com




This email (and attachments if any) is intended only for the use of the 
individual or entity to which it is addressed, and may contain information that 
is confidential or privileged and exempt from disclosure under applicable law. 
If the reader of this email is not the intended recipient, or the employee or 
agent responsible for delivering this message to the intended recipient, you 
are hereby notified that any dissemination, distribution or copying of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify the sender immediately by return email and destroy all 
copies of the email (and attachments if any).
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Fast Pixel Access

[David Baker (Geoscience)]

Evan,

I am not sure how to profile as I do not have access to the code to profile.  I 
did do a timing test...

vrt file = 22,970 KB
bil file = 35,180 KB * 55,501

I piped five locations from the loc.txt file:
-96.0 36.0
-98.0 37.0
-100.0 38.0
-99.0 39.0
-101.0 35.0

gdallocationinfo -valonly -geoloc intermap.vrt < loc.txt
189.84185791015625.5 sec
384.85745239257822.6 sec
762.01593017578122.9 sec
550.71911621093823.6 sec
883.63702392578122.9 sec

Note: I used a lap timer on my iPhone to capture the split times as the results 
appeared in the console window.  Does this give any insight?

David

-Original Message-
From: gdal-dev-boun...@lists.osgeo.org 
[mailto:gdal-dev-boun...@lists.osgeo.org] On Behalf Of Even Rouault
Sent: Saturday, February 01, 2014 1:28 AM
To: Brian Case
Cc: gdal-dev@lists.osgeo.org
Subject: Re: [gdal-dev] Fast Pixel Access

Le samedi 01 février 2014 00:23:13, Brian Case a écrit :
> evenr
>
>
> what about the use of a tileindex?

You really mean a tileindex as produced by gdaltindex ? Well, that's not
exactly the same beast as a VRT, but yes if it was recognized as a GDAL
dataset then you could potentially save the cost of XML parsing. One could
imagine that the VRT driver would accept a tileindex as an altenate connection
string.

Anyway it would be interesting to first profile where the time is spent in David
use case. If it's in the XML parsing, then I can't see what could be easily
improved in that area. If it's the intersection, then there's potential for
improvement.

> seems an intersection with a set of
> polys first would be quick


>
> brian
>
> On Fri, 2014-01-31 at 19:30 +0100, Even Rouault wrote:
> > Le vendredi 31 janvier 2014 17:15:53, David Baker (Geoscience) a écrit :
> > > Dev's,
> > >
> > > I have a set of 55,501 bil files in a single directory.  They are DEMS
> > > data that cover the US in 7.5 minute tiles.  I would like to randomly
> > > access elevations at a given lat/lon's from the whole dataset.  I
> > > created a vrt file from the directory of bil files, and have been able
> > > to access the elevation at a given lat/lon using gdallocationinfo, but
> > > because of the size of the dataset, this operation is somewhat slow.
> > > Can the vrt be indexed?
> >
> > No, it isn't currently, although I think it could be improved to have a
> > in- memory index with moderate effort.
> >
> > But are you sure the slowness is due to the lack of index ? 55,000 is a
> > big number, but not that big. Maybe the slowness just comes from the
> > opening time (XML parsing) of such a big VRT. That would need to be
> > profiled to be sure where the bottleneck is.
> >
> > > Or, is there a faster, better way to access the pixels?  I would
> > > first like to do this with the utilities before diving into code (C#).
> > > The files are regularly named base on their location within a 1
> > > arc-second grid.
> > >
> > > Thanks,
> > > David
> > >
> > > David M. Baker
> > > Senior Advisor - Geoscience Technology
> > > Chesapeake Energy Corporation
> > > david.m.ba...@chk.com<mailto:david.m.ba...@chk.com>
> > >
> > >
> > > 
> > >
> > > This email (and attachments if any) is intended only for the use of the
> > > individual or entity to which it is addressed, and may contain
> > > information that is confidential or privileged and exempt from
> > > disclosure under applicable law. If the reader of this email is not
> > > the intended recipient, or the employee or agent responsible for
> > > delivering this message to the intended recipient, you are hereby
> > > notified that any dissemination, distribution or copying of this
> > > communication is strictly prohibited. If you have received this
> > > communication in error, please notify the sender immediately by return
> > > email and destroy all copies of the email (and attachments if any).

--
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



This email (and attachments if any) is intended only for the use of the 
individual or entity to which it is addressed, and may contain information that 
is confidential or privileged and exempt from disclosure under applicable law. 
If the reader of this email is not the intended recipient, or the employee or 
agent responsible for delivering this message to the intended recipient, you 
are hereby notified that any dissemination, distribution or copying of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify the sender immediately by return email and destroy all 
copies of the email (and attachments if any).
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Fast Pixel Access

[David Baker (Geoscience)]

Jukka,

Jukka wrote:
>I was experimenting with something like a "GIS service without a GIS server)
>and I have some examples online but...

I am looking to do as you have, a RESTful service to query the elevation at a 
given location.  This will be used to in a DQM process as well as a geologic 
application that needs the elevation of a proposed wellsite for data mining.  
In both cases, 1000's if not tens of 1000's of calls will be made so 
performance is an issue.

David


-Original Message-
From: gdal-dev-boun...@lists.osgeo.org 
[mailto:gdal-dev-boun...@lists.osgeo.org] On Behalf Of Jukka Rahkonen
Sent: Saturday, February 01, 2014 7:09 AM
To: gdal-dev@lists.osgeo.org
Subject: Re: [gdal-dev] Fast Pixel Access

David Baker (Geoscience  chk.com> writes:

>
>
>
> Dev’s,
>
> I have a set of 55,501 bil files in a single directory.  They are DEMS
data that cover the US in 7.5 minute tiles.  I would like to randomly access
elevations at a given lat/lon’s from the whole dataset.  I created a vrt
file from the directory
>  of bil files, and have been able to access the elevation at a given
lat/lon using gdallocationinfo, but because of the size of the dataset, this
operation is somewhat slow.  Can the vrt be indexed? Or, is there a faster,
better way to access the pixels?  I
>  would first like to do this with the utilities before diving into code
(C#).  The files are regularly named base on their location within a 1
arc-second grid.

I was experimenting with something like a "GIS service without a GIS server)
and I have some examples online but because of http connection the speed
comparison does not make sense.

Vrt combining biomass data from 13 single band tif files
gdallocationinfo
/vsicurl/http://latuviitta.kapsi.fi/data/metla/puuston_tilavuus.vrt -geoloc
 389559 6677412

DEM of Finland with 10x10 m grid through vrt
gdallocationinfo /vsicurl/http://latuviitta.kapsi.fi/data/dem10m/dem_10m.vrt
-geoloc  389559 6677412

The same from a single BigTIFF
gdallocationinfo /vsicurl/http://latuviitta.kapsi.fi/data/dem10m/dem_10m.tif
-geoloc  389559 6677412

Feel free to download the originals if you want, they are all made from open
data. Just mention the National Land Survey of Finland, 2013 for the DEM and
Finnish Forest Reserch Institute, 2013 for the biomass data if you publish
data somewhere. The DEM datasets are about 10 GB each (Bigtiff + the
original small ones).

My tiffs have tiles but for this usage where only the value of a single
pixel is interesting striped tiffs could be as fast to read than tiled
tiffs. A trial would tell everything

-Jukka Rahkonen-


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



This email (and attachments if any) is intended only for the use of the 
individual or entity to which it is addressed, and may contain information that 
is confidential or privileged and exempt from disclosure under applicable law. 
If the reader of this email is not the intended recipient, or the employee or 
agent responsible for delivering this message to the intended recipient, you 
are hereby notified that any dissemination, distribution or copying of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify the sender immediately by return email and destroy all 
copies of the email (and attachments if any).
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Fast Pixel Access

[David Baker (Geoscience)]

Norman,

Yes it does...  At first I am looking to see if I can do this "off the shelf" 
with just the tools in the GDAL/ORG toolset.  Are you thinking of using OGR to 
do the spatial query with the spatialite db?  Would a .qix indexed tile index 
shapefile work?

David


From: Norman Vine [mailto:n...@cape.com]
Sent: Saturday, February 01, 2014 8:23 AM
To: David Baker (Geoscience)
Cc: gdal-dev
Subject: Re: [gdal-dev] Fast Pixel Access

This is an application that is just screaming for a spatial index

For starters you could build a spatialite db of the individual file extents
that returned the filename to pass to gdallocationinfo

On Feb 1, 2014, at 9:14 AM, "David Baker (Geoscience)" 
mailto:david.m.ba...@chk.com>> wrote:


Jukka,

Jukka wrote:

I was experimenting with something like a "GIS service without a GIS server)
and I have some examples online but...

I am looking to do as you have, a RESTful service to query the elevation at a 
given location.  This will be used to in a DQM process as well as a geologic 
application that needs the elevation of a proposed wellsite for data mining.  
In both cases, 1000's if not tens of 1000's of calls will be made so 
performance is an issue.

David


-Original Message-
From: gdal-dev-boun...@lists.osgeo.org<mailto:gdal-dev-boun...@lists.osgeo.org> 
[mailto:gdal-dev-boun...@lists.osgeo.org<mailto:dev-boun...@lists.osgeo.org>] 
On Behalf Of Jukka Rahkonen
Sent: Saturday, February 01, 2014 7:09 AM
To: gdal-dev@lists.osgeo.org<mailto:gdal-dev@lists.osgeo.org>
Subject: Re: [gdal-dev] Fast Pixel Access

David Baker (Geoscience  chk.com<http://chk.com>> writes:





Dev's,

I have a set of 55,501 bil files in a single directory.  They are DEMS
data that cover the US in 7.5 minute tiles.  I would like to randomly access
elevations at a given lat/lon's from the whole dataset.  I created a vrt
file from the directory

of bil files, and have been able to access the elevation at a given
lat/lon using gdallocationinfo, but because of the size of the dataset, this
operation is somewhat slow.  Can the vrt be indexed? Or, is there a faster,
better way to access the pixels?  I

would first like to do this with the utilities before diving into code
(C#).  The files are regularly named base on their location within a 1
arc-second grid.

I was experimenting with something like a "GIS service without a GIS server)
and I have some examples online but because of http connection the speed
comparison does not make sense.

Vrt combining biomass data from 13 single band tif files
gdallocationinfo
/vsicurl/http://latuviitta.kapsi.fi/data/metla/puuston_tilavuus.vrt -geoloc
389559 6677412

DEM of Finland with 10x10 m grid through vrt
gdallocationinfo /vsicurl/http://latuviitta.kapsi.fi/data/dem10m/dem_10m.vrt
-geoloc  389559 6677412

The same from a single BigTIFF
gdallocationinfo /vsicurl/http://latuviitta.kapsi.fi/data/dem10m/dem_10m.tif
-geoloc  389559 6677412

Feel free to download the originals if you want, they are all made from open
data. Just mention the National Land Survey of Finland, 2013 for the DEM and
Finnish Forest Reserch Institute, 2013 for the biomass data if you publish
data somewhere. The DEM datasets are about 10 GB each (Bigtiff + the
original small ones).

My tiffs have tiles but for this usage where only the value of a single
pixel is interesting striped tiffs could be as fast to read than tiled
tiffs. A trial would tell everything

-Jukka Rahkonen-


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



This email (and attachments if any) is intended only for the use of the 
individual or entity to which it is addressed, and may contain information that 
is confidential or privileged and exempt from disclosure under applicable law. 
If the reader of this email is not the intended recipient, or the employee or 
agent responsible for delivering this message to the intended recipient, you 
are hereby notified that any dissemination, distribution or copying of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify the sender immediately by return email and destroy all 
copies of the email (and attachments if any).
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org<mailto:gdal-dev@lists.osgeo.org>
http://lists.osgeo.org/mailman/listinfo/gdal-dev




This email (and attachments if any) is intended only for the use of the 
individual or entity to which it is addressed, and may contain information that 
is confidential or privileged and exempt from disclosure under applicable law. 
If the reader of this email is not the intended recipient, or the employee or 
agent responsible for del

Re: [gdal-dev] Fast Pixel Access

[David Baker (Geoscience)]

Dan,

I had not heard of the KEA format and it looks promising, accept the need to 
compile.  I am hoping to this with out-of-the-box GDAL.  I also did not see a 
license statement.  GDAL does support HDF5 (another format I am not familiar 
with), but it looks like the limit is 2GB for the built in driver.  My dataset 
is also covers the US with 55,501 x 7.5 minutes tiles at 0.15012 arc second 
resolution (~5m), a total size 2,289,001 x 756,001 pixels, 1.8T.  Creating a 
single dataset from the tiles can be done, but in our environment, is not cheap.

David

-Original Message-
From: gdal-dev-boun...@lists.osgeo.org 
[mailto:gdal-dev-boun...@lists.osgeo.org] On Behalf Of Daniel Clewley
Sent: Saturday, February 01, 2014 1:45 PM
To: gdal-dev@lists.osgeo.org
Subject: Re: [gdal-dev] Fast Pixel Access

Hi David,

Following on from the VRT / Bigtiff comparison Jukka posted. Have you 
considered storing the data as a single KEA format file, which is based on HDF5?

I have the National Elevation Dataset for the US, which comprises 3,605 1 x 1 
degree tiles at 1 arc sec resolution. I first created a VRT then used 
gdal_translate to convert to a KEA file. Total size is 421,212 x 252,012 
pixels, 77 GB. I also built overviews for a fast display (this took a long time 
and I don't think is needed for your case).

I've just tried using gdallocationinfo on the file to get pixel information and 
it takes < 0.5s to get the pixel value back.

The KEA library and GDAL driver source are available from:

https://bitbucket.org/chchrsc/kealib/

and the format is described in:

Peter Bunting, Sam Gillingham, The KEA image file format, Computers & 
Geosciences, Volume 57, August 2013, Pages 54-58, ISSN 0098-3004, 
http://dx.doi.org/10.1016/j.cageo.2013.03.025.

If you don't mind having one massive file (in addition to the individual tiles, 
which could be archived), this might work for your use case.

Thanks,

Dan

>
> Message: 10
> Date: Fri, 31 Jan 2014 16:15:53 +
> From: "David Baker (Geoscience)" 
> To: "'gdal-dev@lists.osgeo.org'" 
> Subject: [gdal-dev] Fast Pixel Access
> Message-ID:
>   <2a18a4344312134b937df938d992264a0508f...@okcexhprd122.chkenergy.net>
> Content-Type: text/plain; charset="us-ascii"
>
> Dev's,
>
> I have a set of 55,501 bil files in a single directory.  They are DEMS data 
> that cover the US in 7.5 minute tiles.  I would like to randomly access 
> elevations at a given lat/lon's from the whole dataset.  I created a vrt file 
> from the directory of bil files, and have been able to access the elevation 
> at a given lat/lon using gdallocationinfo, but because of the size of the 
> dataset, this operation is somewhat slow.  Can the vrt be indexed? Or, is 
> there a faster, better way to access the pixels?  I would first like to do 
> this with the utilities before diving into code (C#).  The files are 
> regularly named base on their location within a 1 arc-second grid.
>
> Thanks,
> David
>
> David M. Baker
> Senior Advisor - Geoscience Technology
> Chesapeake Energy Corporation
> david.m.ba...@chk.com<mailto:david.m.ba...@chk.com>
>
>
>

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



This email (and attachments if any) is intended only for the use of the 
individual or entity to which it is addressed, and may contain information that 
is confidential or privileged and exempt from disclosure under applicable law. 
If the reader of this email is not the intended recipient, or the employee or 
agent responsible for delivering this message to the intended recipient, you 
are hereby notified that any dissemination, distribution or copying of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify the sender immediately by return email and destroy all 
copies of the email (and attachments if any).
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Fast Pixel Access

[David Baker (Geoscience)]

Jukka,

No matter the endpoint the user uses to access the data, behind the scenes, 
there must be fast pixel access, correct?  Or are you saying that at WFS would 
do it quickly out of the box?

David

-Original Message-
From: gdal-dev-boun...@lists.osgeo.org 
[mailto:gdal-dev-boun...@lists.osgeo.org] On Behalf Of Rahkonen Jukka (Tike)
Sent: Monday, February 03, 2014 11:37 AM
To: gdal-dev@lists.osgeo.org
Subject: Re: [gdal-dev] Fast Pixel Access

Hi,

Perhaps, but in this game the rule was not to have any GIS servers. Myself I 
would rather consider WFS. It could send heights from single points but also a 
profile along a line or all values within a polygon.

-Jukka-

Brian Case [r...@winkey.org] wrote:

> -Jukka

> tileindex, mapserver, and the gdal wms driver



> On Mon, 2014-02-03 at 17:20 +, Jukka Rahkonen wrote:
>> Luke Roth  gmail.com> writes:
>
> >
>> > Another thing that might speed up access is setting the config
>> option GDAL_DISABLE_READDIR_ON_OPEN = TRUE, either as an environment
>> variable or on the command line.  That should help with GDAL reading the
>> directory each time it opens a dataset.  I have an application which reads
>> one value from each of a large number of datasets and setting this option
>> made it run about 3 times faster.
>
>
> Hi,
>
> You are right. This config option makes GDAL to skip the reading of the
> remote directory and saves a lot of bandwidth:
>
> VRT case:
> Bytes Received:  4 244 509 (of which the vrt file: 4 192 577)
> Sequence (clock) duration:00:00:09.9996000
> Was:
> Bytes Received:  6 459 443
> Sequence (clock) duration:00:00:37.813
>
> BigTIFF case:
> Bytes Received:  2 158 917
> Sequence (clock) duration:00:00:04.4368000
> Was:
> Bytes Received:  4 374 137
> Sequence (clock) duration:00:00:30.9192000
>
>
> Conclusion:
> Both options are unsuitable for serious use while amusing to play with.
> Reading the BigTIFF tile offset index (or whatever it is) seems to mean
> about 2 MB of compultory payload traffic. Reading the VRT file means in this
> example 4 MB of payload. If this sort of net access to a large directory of
> raster files should be important for someone there should be a way to find
> the right raster file and righ data range in that file with minimum amount
> of bytes. Perhaps some kind of rtree indexed vrt file? First aid might be to
> keep the vrt file on the client side.
>
> -Jukka Rahkonen-
>
>
> ___
> 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



This email (and attachments if any) is intended only for the use of the 
individual or entity to which it is addressed, and may contain information that 
is confidential or privileged and exempt from disclosure under applicable law. 
If the reader of this email is not the intended recipient, or the employee or 
agent responsible for delivering this message to the intended recipient, you 
are hereby notified that any dissemination, distribution or copying of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify the sender immediately by return email and destroy all 
copies of the email (and attachments if any).
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Fast Pixel Access

[David Baker (Geoscience)]

Luke,

Thank you for this suggestion.  This too the access times from 15-20 seconds 
down to 1 to 3 seconds.  The majority of the time seems to be spent on the 
initial read of the vrt as subsequent piped locations after the first are 
returned sub-second.  For my current application, this should be okay.

David


From: gdal-dev-boun...@lists.osgeo.org 
[mailto:gdal-dev-boun...@lists.osgeo.org] On Behalf Of Luke Roth
Sent: Monday, February 03, 2014 8:11 AM
To: Jukka Rahkonen
Cc: gdal-dev@lists.osgeo.org
Subject: Re: [gdal-dev] Fast Pixel Access

Another thing that might speed up access is setting the config option 
GDAL_DISABLE_READDIR_ON_OPEN = TRUE, either as an environment variable or on 
the command line.  That should help with GDAL reading the directory each time 
it opens a dataset.  I have an application which reads one value from each of a 
large number of datasets and setting this option made it run about 3 times 
faster.
Luke
On Sun, Feb 2, 2014 at 2:12 PM, Jukka Rahkonen 
mailto:jukka.rahko...@mmmtike.fi>> wrote:
Hi,

I made a few tests and here comes my conclusions. Hypothesis is that someone
wants to make a DEM query service which is using gdallocationinfo for
queries and DEM data is to be accessed as files from a standard web site. I
compared three alternatives:
1) There are thousands of DEM files on the server and they are combined
together with a VRT file.
2) There is only one DEM file as BigTIFF.
3) DEM is split into tiles into x/y/z tile directory structure like in
Google maps or OpenStreetMap tiles.

My test data covers Finland with 10 m grid size and as deflate compressed
tiffs they make about 10 GB together.

Before going on, keep in mind that the speed needs indexes. The better
index, the less unnecessary data to read. In case 1) the first level index
is the VRT file. The second level index, if it exists, is in the headers of
the real DEM files. It may be possible to jump to a correct offset from the
beginning of the DEM data and read only a part of the file.  In case 2) the
index is in the internal TIFF directory. If the BigTIFF is tiled the access
to tiles should be rather effectice. And finally in case 3) the index is
built into directory structure and tiling schema that is used for saving the
tiles. The schema is no well known that tile map service clients can
directly ask for a certain file name if they know the coordinates and scale.

Conclusions:

1)
- The whole VRT file must be readed. Caching the vrt file would make next
requests faster.
- For some reason gdallocationinfo wants to get the directory list of the
directory where the vrt file is. This is slow and generates lots of traffic
if the thousands of DEM files are in the same directory. Probably it would
be faster to have them in another dierectory.

2)
- BigTIFF route is more straight forward but gdallocationinfo needs still to
do many big range reads.
- Also in this case gdallocationinfo reads the target file directory. It
would be good to keep this directory small. Don't do like I did with having
in the directory the BigTIFF DEM file that was the only file needed, but
also the vrt and thousands of original DEMs from the previuos test -> but at
least this is a know this issue now and know how to avoid it. In my case
reading the directory made 2.2 MB of web traffic and all or most for wain.

3)
- I used OpenStreetMap tile service as the test data for the third test. In
this case gdallocationinfo knows exactly which tile to request and it is
making only one request. It also seems to cache some tiles on the client
side which means that queries for close locations may hit the cached tile
and be very fast.

Summary statistics:

1) Gdallocationinfo makes 6 requests and reads 6.4 MB of data
2) Gdallocationinfo makes 8 requests and reads 4.3 MB of data
3) Gdallocationinfo makes 1 requests and reads 10 kB of data

Requests I used are these:

1)
gdallocationinfo /vsicurl/http://latuviitta.kapsi.fi/data/
dem10m/dem_10m.vrt -geoloc  389559 6677412
2)
gdallocationinfo /vsicurl/http://latuviitta.kapsi.fi/data/
dem10m/dem_10m.tif -geoloc  389559 6677412
3)
gdallocationinfo  frmt_wms_openstreetmap_tms.xml -geoloc  389559 6677412

I know that the queried place in 3) is not the same because SRIDs of data
differ nor does OSM return 16-bit DEM heights but 3-band RGB values instead
but it does not matter here, the idea is what is important.

My conclusion is that you should cut your DEM into tiles with for example
gdal2tiles or MapTiler and the resuld could actually be quit speedy and
perhaps using 126x126 tiles could make it still a bit faster. Hope that they
can create tiles as 16-bit tiffs.

 I am sure that these results are not scientifically sound but I am also
sure that the difference between 6.4 MB/4.3 MB/10 kB is something to think
about especially if you dream about a mobile service.

I placed the requests which gdallocationinfo made during these tests into
http://latuviitta.org/documents/gdallocationinfo_requests.txt

-Jukka Rahko

Re: [gdal-dev] Fast Pixel Access

[David Baker (Geoscience)]

Klokan,

This looks like it could work.  This would be accessed with the GDAL_WCS 
driver?  If so, I see that there it requires Curl, and I have a Curl directory 
in my install, but I get an error when I try and access the data.

David

David M. Baker
Senior Advisor - Geoscience Technology
Chesapeake Energy Corporation
405-935-3715 office
405-496-5373 cell
david.m.ba...@chk.com<mailto:david.m.ba...@chk.com>

From: klo...@gmail.com [mailto:klo...@gmail.com] On Behalf Of Klokan Petr Pridal
Sent: Monday, February 03, 2014 1:38 PM
To: David Baker (Geoscience)
Cc: Rahkonen Jukka (Tike); gdal-dev@lists.osgeo.org
Subject: Re: [gdal-dev] Fast Pixel Access

Hi Jukka, David and others,

We were rendering in the past the elevation data into Mercator tiles with 
http://www.maptiler.com/, the follower of my GDAL2Tiles.py script - for 
extremely fast pixel access to the elevation values at given geographic 
location - without a need for server software for hosting such data. We made 
the tiles for CGIAR 90m DEM for whole world.

In fact the raw elevation was mapped into RGB space for this purpose. Decoding 
on the client side is then very easy and you have precise elevation values for 
the whole near area preloaded.

You may need to do something similar if you want to implement very fast client 
side hill-shading in web browser canvas (similar to 
http://dev.klokantech.com/klokan/hillshading/), or dynamic elevation profile 
drawn while moving the mouse over a map, and many other tasks with data loaded 
in the client directly.

The visualisation of the tiles is possible also in 3D, see: 
http://vimeo.com/29605292
For WebGL there are now more efficient ways (direct binary data structures 
instead of images).

See:
http://dev.klokantech.com/srtm/srtm_decode.html
http://www.klokantech.com/labs/dem-color-encoding/
http://dev.klokantech.com/srtm/googlemaps.html

There is a source code of the GDAL utility for encoding elevation data into RGB 
available online:
https://github.com/webglearth/gdaldem_web
but you may not need it, if direct reading via JavaScript in the web browser is 
not required for your application.

Regards,

Klokan Petr Pridal

On Mon, Feb 3, 2014 at 7:48 PM, David Baker (Geoscience) 
mailto:david.m.ba...@chk.com>> wrote:
Jukka,

No matter the endpoint the user uses to access the data, behind the scenes, 
there must be fast pixel access, correct?  Or are you saying that at WFS would 
do it quickly out of the box?

David

-Original Message-
From: gdal-dev-boun...@lists.osgeo.org<mailto:gdal-dev-boun...@lists.osgeo.org> 
[mailto:gdal-dev-boun...@lists.osgeo.org<mailto:gdal-dev-boun...@lists.osgeo.org>]
 On Behalf Of Rahkonen Jukka (Tike)
Sent: Monday, February 03, 2014 11:37 AM
To: gdal-dev@lists.osgeo.org<mailto:gdal-dev@lists.osgeo.org>
Subject: Re: [gdal-dev] Fast Pixel Access
Hi,

Perhaps, but in this game the rule was not to have any GIS servers. Myself I 
would rather consider WFS. It could send heights from single points but also a 
profile along a line or all values within a polygon.

-Jukka-

Brian Case [r...@winkey.org<mailto:r...@winkey.org>] wrote:

> -Jukka

> tileindex, mapserver, and the gdal wms driver



> On Mon, 2014-02-03 at 17:20 +, Jukka Rahkonen wrote:
>> Luke Roth  gmail.com<http://gmail.com>> writes:
>
> >
>> > Another thing that might speed up access is setting the config
>> option GDAL_DISABLE_READDIR_ON_OPEN = TRUE, either as an environment
>> variable or on the command line.  That should help with GDAL reading the
>> directory each time it opens a dataset.  I have an application which reads
>> one value from each of a large number of datasets and setting this option
>> made it run about 3 times faster.
>
>
> Hi,
>
> You are right. This config option makes GDAL to skip the reading of the
> remote directory and saves a lot of bandwidth:
>
> VRT case:
> Bytes Received:  4 244 509 (of which the vrt file: 4 192 577)
> Sequence (clock) duration:00:00:09.9996000
> Was:
> Bytes Received:  6 459 443
> Sequence (clock) duration:00:00:37.813
>
> BigTIFF case:
> Bytes Received:  2 158 917
> Sequence (clock) duration:00:00:04.4368000
> Was:
> Bytes Received:  4 374 137
> Sequence (clock) duration:00:00:30.9192000
>
>
> Conclusion:
> Both options are unsuitable for serious use while amusing to play with.
> Reading the BigTIFF tile offset index (or whatever it is) seems to mean
> about 2 MB of compultory payload traffic. Reading the VRT file means in this
> example 4 MB of payload. If this sort of net access to a large directory of
> raster files should be important for someone there should be a way to find
> the right raster file and righ data range in that file with minimum amount
> of bytes. Perhaps some kind of rtree indexed vrt file? First aid might be to
> ke

Re: [gdal-dev] Fast Pixel Access

[David Baker (Geoscience)]

Even,

No not an i386...  A Dell Precision T3500 w/Intel W3680 @ 3.33GHhz 6x2 cores 
with 12.0GB.  Thought the data is on the network, not local, with 1Gbps access. 
 The GDAL_DISABLE_READDIR_ON_OPEN = TRUE did significantly increase the speed.  
Does the BIL driver read the whole file into memory first?  Might a direct read 
be faster?

And Even, please excuse my ignorance, but what is "gdb?"  I really would like 
to do the profiling.

David

-Original Message-
From: Even Rouault [mailto:even.roua...@mines-paris.org]
Sent: Sunday, February 09, 2014 6:36 AM
To: David Baker (Geoscience)
Cc: 'Brian Case'; 'gdal-dev@lists.osgeo.org'
Subject: Re: [gdal-dev] Fast Pixel Access

Le samedi 01 février 2014 15:04:46, David Baker (Geoscience) a écrit :
> Evan,
>
> I am not sure how to profile as I do not have access to the code to
> profile.  I did do a timing test...
>
> vrt file = 22,970 KB
> bil file = 35,180 KB * 55,501
>
> I piped five locations from the loc.txt file:
> -96.0 36.0
> -98.0 37.0
> -100.0 38.0
> -99.0 39.0
> -101.0 35.0
>
> gdallocationinfo -valonly -geoloc intermap.vrt < loc.txt
> 189.84185791015625.5 sec
> 384.85745239257822.6 sec
> 762.01593017578122.9 sec
> 550.71911621093823.6 sec
> 883.63702392578122.9 sec
>
> Note: I used a lap timer on my iPhone to capture the split times as the
> results appeared in the console window.  Does this give any insight?

Woo I agree that's utterly slow ! When you mentionned slow I thought it was
more in the order of 0.1 second ! We can already exclude the parsing time of
the VRT since you do that in the same gdallocationinfo session and that there
will be just one parsing.
And I can't believe that the intersection test for 55 000 rectangles takes ~
20 seconds, unless you have an old i386 at 5 MHz ;-)
My usual way of profiling stuff that is slow in the order of more than one
second is to run under gdb, break with Ctrl+C, display the stack trace,
continue the run, break again, display the stack trace, etc.. If you end up
breaking in the same function, then you've found the bottleneck.

I see now that in that thread GDAL_DISABLE_READDIR_ON_OPEN = TRUE was
suggested and seems to improve things significantly. Perhaps we should try to
cache the result of the initial readdir so it can benefits to later attempts,
but I haven't checked how easily that could be miplemented. Or perhaps we
should just change the default value of GDAL_DISABLE_READDIR_ON_OPEN since it
causes problem from time to time.
But generally filesystems don't behave very well when there are a lot of files
in the same directory. You'd better organizing your tiles in subdirectories.
But still 1 to 3 seconds sounds a bit slow to me. Would be cool if you could
try the above suggestion to identify where the time is spent.

Even

>
> David
>
> -Original Message-
> From: gdal-dev-boun...@lists.osgeo.org
> [mailto:gdal-dev-boun...@lists.osgeo.org] On Behalf Of Even Rouault Sent:
> Saturday, February 01, 2014 1:28 AM
> To: Brian Case
> Cc: gdal-dev@lists.osgeo.org
> Subject: Re: [gdal-dev] Fast Pixel Access
>
> Le samedi 01 février 2014 00:23:13, Brian Case a écrit :
> > evenr
> >
> >
> > what about the use of a tileindex?
>
> You really mean a tileindex as produced by gdaltindex ? Well, that's not
> exactly the same beast as a VRT, but yes if it was recognized as a GDAL
> dataset then you could potentially save the cost of XML parsing. One could
> imagine that the VRT driver would accept a tileindex as an altenate
> connection string.
>
> Anyway it would be interesting to first profile where the time is spent in
> David use case. If it's in the XML parsing, then I can't see what could be
> easily improved in that area. If it's the intersection, then there's
> potential for improvement.
>
> > seems an intersection with a set of
> > polys first would be quick
> >
> >
> >
> > brian
> >
> > On Fri, 2014-01-31 at 19:30 +0100, Even Rouault wrote:
> > > Le vendredi 31 janvier 2014 17:15:53, David Baker (Geoscience) a écrit :
> > > > Dev's,
> > > >
> > > > I have a set of 55,501 bil files in a single directory.  They are
> > > > DEMS data that cover the US in 7.5 minute tiles.  I would like to
> > > > randomly access elevations at a given lat/lon's from the whole
> > > > dataset.  I created a vrt file from the directory of bil files, and
> > > > have been able to access the elevation at a given lat/lon using
> > > > gdallocationinfo, but because of the size of the dataset, this
> > > > operation is somewhat slow. Can the vrt be indexed?
&g

Re: [gdal-dev] Fast Pixel Access

[David Baker (Geoscience)]

Evan.  I am on Windows and only have the binaries installed.

David

-Original Message-
From: Even Rouault [mailto:even.roua...@mines-paris.org]
Sent: Monday, February 10, 2014 8:54 AM
To: David Baker (Geoscience)
Cc: 'Even Rouault'; 'Brian Case'; 'gdal-dev@lists.osgeo.org'
Subject: RE: [gdal-dev] Fast Pixel Access

Selon "David Baker (Geoscience)" :

> Even,
>
> No not an i386...  A Dell Precision T3500 w/Intel W3680 @ 3.33GHhz 6x2 cores
> with 12.0GB.  Thought the data is on the network, not local, with 1Gbps
> access.  The GDAL_DISABLE_READDIR_ON_OPEN = TRUE did significantly increase
> the speed.  Does the BIL driver read the whole file into memory first?  Might
> a direct read be faster?

No the BIL driver will just read the line where the pixel is.

>
> And Even, please excuse my ignorance, but what is "gdb?"  I really would like
> to do the profiling.

gdb is the GNU debugger ( https://www.gnu.org/software/gdb/ ) . Assuming you use
Linux (likely available on MacOSX too). You should be able to install it with
the usual package management system of the distribution : apt-get install gdb,
yum install gdb, ... . Otherwise on Windows, I'm far less familiar with the
debugging tools.

gdb --args gdallocationinfo -valonly -geoloc intermap.vrt

Then type "run"
Type a coordinate "-96.0 36.0"
ctrl+c to suspend execution
"bt" to display the stack trace
"c" to resume execution

>
> David
>
> -----Original Message-
> From: Even Rouault [mailto:even.roua...@mines-paris.org]
> Sent: Sunday, February 09, 2014 6:36 AM
> To: David Baker (Geoscience)
> Cc: 'Brian Case'; 'gdal-dev@lists.osgeo.org'
> Subject: Re: [gdal-dev] Fast Pixel Access
>
> Le samedi 01 février 2014 15:04:46, David Baker (Geoscience) a écrit :
> > Evan,
> >
> > I am not sure how to profile as I do not have access to the code to
> > profile.  I did do a timing test...
> >
> > vrt file = 22,970 KB
> > bil file = 35,180 KB * 55,501
> >
> > I piped five locations from the loc.txt file:
> > -96.0 36.0
> > -98.0 37.0
> > -100.0 38.0
> > -99.0 39.0
> > -101.0 35.0
> >
> > gdallocationinfo -valonly -geoloc intermap.vrt < loc.txt
> > 189.84185791015625.5 sec
> > 384.85745239257822.6 sec
> > 762.01593017578122.9 sec
> > 550.71911621093823.6 sec
> > 883.63702392578122.9 sec
> >
> > Note: I used a lap timer on my iPhone to capture the split times as the
> > results appeared in the console window.  Does this give any insight?
>
> Woo I agree that's utterly slow ! When you mentionned slow I thought it was
> more in the order of 0.1 second ! We can already exclude the parsing time of
> the VRT since you do that in the same gdallocationinfo session and that there
> will be just one parsing.
> And I can't believe that the intersection test for 55 000 rectangles takes ~
> 20 seconds, unless you have an old i386 at 5 MHz ;-)
> My usual way of profiling stuff that is slow in the order of more than one
> second is to run under gdb, break with Ctrl+C, display the stack trace,
> continue the run, break again, display the stack trace, etc.. If you end up
> breaking in the same function, then you've found the bottleneck.
>
> I see now that in that thread GDAL_DISABLE_READDIR_ON_OPEN = TRUE was
> suggested and seems to improve things significantly. Perhaps we should try to
> cache the result of the initial readdir so it can benefits to later attempts,
> but I haven't checked how easily that could be miplemented. Or perhaps we
> should just change the default value of GDAL_DISABLE_READDIR_ON_OPEN since it
> causes problem from time to time.
> But generally filesystems don't behave very well when there are a lot of
> files
> in the same directory. You'd better organizing your tiles in subdirectories.
> But still 1 to 3 seconds sounds a bit slow to me. Would be cool if you could
> try the above suggestion to identify where the time is spent.
>
> Even
>
> >
> > David
> >
> > -Original Message-
> > From: gdal-dev-boun...@lists.osgeo.org
> > [mailto:gdal-dev-boun...@lists.osgeo.org] On Behalf Of Even Rouault Sent:
> > Saturday, February 01, 2014 1:28 AM
> > To: Brian Case
> > Cc: gdal-dev@lists.osgeo.org
> > Subject: Re: [gdal-dev] Fast Pixel Access
> >
> > Le samedi 01 février 2014 00:23:13, Brian Case a écrit :
> > > evenr
> > >
> > >
> > > what about the use of a tileindex?
> >
> > You really mean a tileindex as produced by gdaltindex ? Well, that's not
> > exact

Re: [gdal-dev] Is it possible?

[David Baker (Geoscience)]

Peter,

I can think of a few reasons, one for example, I have a geologic map that has 
only USGS quads for position reference.  I also have a shapefile that has 
county outlines and another that has the PLSS land survey townships and section 
lines.  I need a GeoTiff because one of the applications I use only will read a 
GeoTiff, so I want to "burn" the vector shapefile data into my raster GeoTiff 
image, so I can find the location of the outcrop I mapped, relative to section 
and township I was mapping in.

David

David M. Baker
Senior Geological Advisor
Chesapeake Energy Corporation
405-935-3715 office
405-496-5373 cell
david.m.ba...@chk.com

-Original Message-
From: gdal-dev-boun...@lists.osgeo.org 
[mailto:gdal-dev-boun...@lists.osgeo.org] On Behalf Of Peter Halls
Sent: Monday, June 08, 2015 9:30 AM
To: Ronquillo, Edgar Nahum; gdal dev
Subject: Re: [gdal-dev] Is it possible?

Why would you want to map a Shapefile into a Geotiff file?  They are
two fundamentally different types of spatial object.  Shapefiles are
exclusively vector in nature, whilst Geotiffs are exclusively raster.
I suggest reading a text, such as Burrough and McDonnell, Principles
of Geographical Information Systems, published by Oxford University
Press, gaining an understanding of the different properties and how to
exploit them.  Then you will be able to choose a data format
appropriate to your purposes.

Peter.

On 8 June 2015 at 15:10, Ronquillo, Edgar Nahum  wrote:
> Hello Gdal users,
> I have a question. I have been working here for quite a while on how to map
> a shapefile into a GeoTiff image. First of all, is this possible with Gdal?
> Right now I am able to map a shapefile using Basemap, which it isn't Gdal of
> course. However, I would like to map this same shapefile into Geotiff file
> that I already have instead of doing it in a big Map like I am doing now. I
> have been looking around and can't find an example of this being done. If
> this is not possible with Gdal, do any of you know any available libraries
> that would do this for me? probably with some examples?
>
> Any help would be greatly appreciated.
>
> Thank you
>
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev



--

Peter J Halls, PhD Student, Post-war Reconstruction and Development Unit (PRDU)
 Department of Politics, University of York

Snail mail: PRDU, Derwent College, University of York,
Heslington, York YO10 5DD
This message has the status of a private and personal communication

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



This email (and attachments if any) is intended only for the use of the 
individual or entity to which it is addressed, and may contain information that 
is confidential or privileged and exempt from disclosure under applicable law. 
If the reader of this email is not the intended recipient, or the employee or 
agent responsible for delivering this message to the intended recipient, you 
are hereby notified that any dissemination, distribution or copying of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify the sender immediately by return email and destroy all 
copies of the email (and attachments if any).
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] C# OGR Modify Shapefile

[David Baker (Geoscience)]

All,

Using the C# dll's that come in Frank's FWTools, is it possible to add, delete 
and modify records in a Shapefile, or do I need to create a new Shapefile with 
the changes?

Thanks,
David

David M. Baker
Senior Geologist - Chief Technology Advisor
Chesapeake Energy Corporation
405-935-3715 office
405-496-5373 cell
david.m.ba...@chk.com



This email (and attachments if any) is intended only for the use of the 
individual or entity to which it is addressed, and may contain information that 
is privileged, confidential and exempt from disclosure under applicable law. If 
the reader of this email is not the intended recipient, or the employee or 
agent responsible for delivering this message to the intended recipient, you 
are hereby notified that any dissemination, distribution or copying of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify the sender immediately by return email and destroy all 
copies of the email (and attachments if any).
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] C# OGR Modify Shapefile

[David Baker (Geoscience)]

Frank. Thanks for the info.

David Baker
Sent from my iPhone

On Aug 8, 2011, at 7:07 PM, "Frank Warmerdam"  wrote:

> David,
>
> With the latest GDAL/OGR you can add fields to an
> existing shapefile, add records and delete records.  I'm
> not certain if all those capabilities were available in the
> last FWTools build or not.
>
> I will note that deleted shapes aren't completely deleted
> until you repack the file.  There should be some details
> on repacking on the driver page.
>
> Best regards,
>
>
> On Mon, Aug 8, 2011 at 4:44 PM, David Baker (Geoscience)
>  wrote:
>> All,
>>
>>
>>
>> Using the C# dll’s that come in Frank’s FWTools, is it possible to add,
>> delete and modify records in a Shapefile, or do I need to create a new
>> Shapefile with the changes?
>>
>>
>>
>> Thanks,
>>
>> David
>>
>>
>>
>> David M. Baker
>>
>> Senior Geologist - Chief Technology Advisor
>>
>> Chesapeake Energy Corporation
>>
>> 405-935-3715 office
>>
>> 405-496-5373 cell
>>
>> david.m.ba...@chk.com
>>
>>
>>
>> 
>> This email (and attachments if any) is intended only for the use of the
>> individual or entity to which it is addressed, and may contain information
>> that is privileged, confidential and exempt from disclosure under applicable
>> law. If the reader of this email is not the intended recipient, or the
>> employee or agent responsible for delivering this message to the intended
>> recipient, you are hereby notified that any dissemination, distribution or
>> copying of this communication is strictly prohibited. If you have received
>> this communication in error, please notify the sender immediately by return
>> email and destroy all copies of the email (and attachments if any).
>>
>> ___
>> gdal-dev mailing list
>> gdal-dev@lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>>
>
>
>
> --
> ---+--
> I set the clouds in motion - turn up   | Frank Warmerdam, warmer...@pobox.com
> light and sound - activate the windows | http://pobox.com/~warmerdam
> and watch the world go round - Rush| Geospatial Software Developer

This email (and attachments if any) is intended only for the use of the 
individual or entity to which it is addressed, and may contain information that 
is privileged, confidential and exempt from disclosure under applicable law.  
If the reader of this email is not the intended recipient, or the employee or 
agent responsible for delivering this message to the intended recipient, you 
are hereby notified that any dissemination, distribution or copying of this 
communication is strictly prohibited.  If you have received this communication 
in error, please notify the sender immediately by return email and destroy all 
copies of the email (and attachments if any).
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] Missing EPSG Codes and importFromUrl

[David Baker (Geoscience)]

All,

Working in C#...  I have need for EPSG:4418. Per http://www.epsg-registry.org/ 
this is the code for "ProjectedCRS [NAD27 / BLM 18N (ftUS)]".  This code does 
not seem to be in the GDAL/OGR/Prog4 database in FWTools2.4.7.  Executing the 
line:

var i = src.ImportFromEPSG(4418);

This call returns an error indicating the code is invalid.  I also searched the 
/data directory for this projection but was not able to find it.  So my next 
move was to try:

var i = 
src.ImportFromUrl(@"http://www.epsg-registry.org/export.htm?gml=urn:ogc:def:crs:EPSG::4410";);

This did not work either.

So my general question is, for missing CRS's how does one retrieve the 
projection information from the web?

Thanks in Advance,
David

David M. Baker
Senior Advisor - Geoscience Technology
Chesapeake Energy Corporation
405-935-3715 office
405-496-5373 cell
david.m.ba...@chk.com




This email (and attachments if any) is intended only for the use of the 
individual or entity to which it is addressed, and may contain information that 
is privileged, confidential and exempt from disclosure under applicable law. If 
the reader of this email is not the intended recipient, or the employee or 
agent responsible for delivering this message to the intended recipient, you 
are hereby notified that any dissemination, distribution or copying of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify the sender immediately by return email and destroy all 
copies of the email (and attachments if any).
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

RE: [gdal-dev] Missing EPSG Codes and importFromUrl

[David Baker (Geoscience)]

Andy,

Great reference!  Thanks for the info.  But, when I execute the line:

var i = 
src.ImportFromUrl(@"http://georepository.com/search/by-name/?query=4418";);

I get an error 6 of 6.  This gets back to my second question, can, and if so, 
how does one call on a URL to get the parameter info ?

Thanks,
David

From: gdal-dev-boun...@lists.osgeo.org 
[mailto:gdal-dev-boun...@lists.osgeo.org] On Behalf Of Andy Cheetham
Sent: Friday, February 03, 2012 1:45 AM
To: gdal-dev@lists.osgeo.org
Subject: Re: [gdal-dev] Missing EPSG Codes and importFromUrl


You could try our website the GeoRepository.com

It will provide you with all the details of the CRS in question

http://georepository.com/search/by-name/?query=4418

Hope this helps

Andy Cheetham
On 2 Feb 2012 23:33, "David Baker (Geoscience)" 
mailto:david.m.ba...@chk.com>> wrote:
All,

Working in C#...  I have need for EPSG:4418. Per http://www.epsg-registry.org/ 
this is the code for "ProjectedCRS [NAD27 / BLM 18N (ftUS)]".  This code does 
not seem to be in the GDAL/OGR/Prog4 database in FWTools2.4.7.  Executing the 
line:

var i = src.ImportFromEPSG(4418);

This call returns an error indicating the code is invalid.  I also searched the 
/data directory for this projection but was not able to find it.  So my next 
move was to try:

var i = 
src.ImportFromUrl(@"http://www.epsg-registry.org/export.htm?gml=urn:ogc:def:crs:EPSG::4410";);

This did not work either.

So my general question is, for missing CRS's how does one retrieve the 
projection information from the web?

Thanks in Advance,
David

David M. Baker
Senior Advisor - Geoscience Technology
Chesapeake Energy Corporation
405-935-3715 office
405-496-5373 cell
david.m.ba...@chk.com<mailto:david.m.ba...@chk.com>




This email (and attachments if any) is intended only for the use of the 
individual or entity to which it is addressed, and may contain information that 
is privileged, confidential and exempt from disclosure under applicable law. If 
the reader of this email is not the intended recipient, or the employee or 
agent responsible for delivering this message to the intended recipient, you 
are hereby notified that any dissemination, distribution or copying of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify the sender immediately by return email and destroy all 
copies of the email (and attachments if any).

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



This email (and attachments if any) is intended only for the use of the 
individual or entity to which it is addressed, and may contain information that 
is privileged, confidential and exempt from disclosure under applicable law. If 
the reader of this email is not the intended recipient, or the employee or 
agent responsible for delivering this message to the intended recipient, you 
are hereby notified that any dissemination, distribution or copying of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify the sender immediately by return email and destroy all 
copies of the email (and attachments if any).
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

RE: [gdal-dev] Missing EPSG Codes and importFromUrl

[David Baker (Geoscience)]

Howard,

Thank you for your advice.  For what I need now, I will most likely try your 
python approach.  Do you know if there are any plans for GDAL/OGR to be able to 
work with the epsg-registry.org is the official store of the EPSG data.  It 
would be great if we could pass a url and osr would traverse the site getting 
all the needed data.

David
-Original Message-
From: Howard Butler [mailto:hobu@gmail.com]
Sent: Friday, February 03, 2012 8:09 AM
To: David Baker (Geoscience)
Cc: 'Andy Cheetham'; gdal-dev@lists.osgeo.org
Subject: Re: [gdal-dev] Missing EPSG Codes and importFromUrl

Caveats about importFromUrl:

* It only can consume http://, not https://
* It adds Accept: application/x-ogcwkt to the headers, and so the server can 
respond with that data
* It simply fetches the data from the URL and hands it off to SetFromUserInput, 
which is OSR's swiss army knife of SRS consumption.

Neither epsg-registry.org nor georepository.com return a simple text string of 
OGC WKT [1], and so there is no way for SetFromUserInput to be able to consume 
the data once cUrl fetches it.  You either need to find a URL on these websites 
that returns (plain) data that SetFromUserInput can ultimately consume, or 
modify these websites to respond to the Accept: header and return data 
accordingly.

[1] http://spatialreference.org/ref/epsg/4326/ogcwkt/

As far as EPSG:4418 is concerned, spatialreference.org doesn't have it, though 
it appears to just be NAD 27 UTM 10N with feet instead of meters for the units. 
You should be able to craft this by modifying things directly using the OSR 
module of the SWIG bindings.  The reason why 4418 isn't in spatialreference.org 
is most likely because it is pretty new, and spatialreference.org hasn't been 
updated with a new EPSG database in a while.

Here's some Python that might demonstrate how to get what you want...

> href = osr.SpatialReference()
> href.ImportFromEPSG(26710)  # Import the NAD27 UTM variant, and then we'll 
> change the units
> href.SetTargetLinearUnits("PROJCS", "U.S. Foot",  0.3048006096012)
> href.SetAuthority("UNIT", "EPSG", 9003)

Howard


On Feb 3, 2012, at 6:19 AM, David Baker (Geoscience) wrote:

> Andy,
>
> Great reference!  Thanks for the info.  But, when I execute the line:
>
> var i = 
> src.ImportFromUrl(@"http://georepository.com/search/by-name/?query=4418";);
>
> I get an error 6 of 6.  This gets back to my second question, can, and if so, 
> how does one call on a URL to get the parameter info ?
>
> Thanks,
> David
>
> From: gdal-dev-boun...@lists.osgeo.org 
> [mailto:gdal-dev-boun...@lists.osgeo.org] On Behalf Of Andy Cheetham
> Sent: Friday, February 03, 2012 1:45 AM
> To: gdal-dev@lists.osgeo.org
> Subject: Re: [gdal-dev] Missing EPSG Codes and importFromUrl
>
> You could try our website the GeoRepository.com
>
> It will provide you with all the details of the CRS in question
>
> http://georepository.com/search/by-name/?query=4418
>
> Hope this helps
>
> Andy Cheetham
>
> On 2 Feb 2012 23:33, "David Baker (Geoscience)"  wrote:
> All,
>
> Working in C#...  I have need for EPSG:4418. Per 
> http://www.epsg-registry.org/ this is the code for "ProjectedCRS [NAD27 / BLM 
> 18N (ftUS)]".  This code does not seem to be in the GDAL/OGR/Prog4 database 
> in FWTools2.4.7.  Executing the line:
>
> var i = src.ImportFromEPSG(4418);
>
> This call returns an error indicating the code is invalid.  I also searched 
> the /data directory for this projection but was not able to find it.  So my 
> next move was to try:
>
> var i = 
> src.ImportFromUrl(@"http://www.epsg-registry.org/export.htm?gml=urn:ogc:def:crs:EPSG::4410";);
>
> This did not work either.
>
> So my general question is, for missing CRS's how does one retrieve the 
> projection information from the web?
>
> Thanks in Advance,
> David
>
> David M. Baker
> Senior Advisor - Geoscience Technology
> Chesapeake Energy Corporation
> 405-935-3715 office
> 405-496-5373 cell
> david.m.ba...@chk.com
>
>
>
> This email (and attachments if any) is intended only for the use of the 
> individual or entity to which it is addressed, and may contain information 
> that is privileged, confidential and exempt from disclosure under applicable 
> law. If the reader of this email is not the intended recipient, or the 
> employee or agent responsible for delivering this message to the intended 
> recipient, you are hereby notified that any dissemination, distribution or 
> copying of this communication is strictly prohibited. If you have received 
> this communication in error, please notify the sender immediately by return 
> email and destroy all copies of 

[gdal-dev] OgrInfo ShapeFile Extents Report

[David Baker (Geoscience)]

List,

Does OgrInfo report the actual extents of the geometries in a ShapeFile or just 
the extents reported in the header of the ShapeFile?

Thanks,
David

David M. Baker
Senior Geologist - Chief Technology Advisor
Chesapeake Energy Corporation
405-935-3715 office
405-496-5373 cell
david.m.ba...@chk.com



This email (and attachments if any) is intended only for the use of the 
individual or entity to which it is addressed, and may contain information that 
is privileged, confidential and exempt from disclosure under applicable law. If 
the reader of this email is not the intended recipient, or the employee or 
agent responsible for delivering this message to the intended recipient, you 
are hereby notified that any dissemination, distribution or copying of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify the sender immediately by return email and destroy all 
copies of the email (and attachments if any).
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

RE: [gdal-dev] OgrInfo ShapeFile Extents Report

[David Baker (Geoscience)]

Frank,

Thanks...  Is there a method in org that scans all geometries or will I have to 
iterate through myself?

David

David M. Baker
Senior Geologist - Chief Technology Advisor
Chesapeake Energy Corporation
405-935-3715 office
405-496-5373 cell
david.m.ba...@chk.com


-Original Message-
From: Frank Warmerdam [mailto:warmer...@pobox.com]
Sent: Monday, March 08, 2010 6:51 PM
To: David Baker (Geoscience)
Cc: 'gdal-dev@lists.osgeo.org'
Subject: Re: [gdal-dev] OgrInfo ShapeFile Extents Report

David Baker (Geoscience) wrote:
> List,
>
>
>
> Does OgrInfo report the actual extents of the geometries in a ShapeFile
> or just the extents reported in the header of the ShapeFile?

David,

GetExtent() is optimized by the shapefile driver to report the extents
from the file header rather than scanning the data as most drivers do.

Best regards,
--
---+--
I set the clouds in motion - turn up   | Frank Warmerdam, warmer...@pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush| Geospatial Programmer for Rent


This email (and attachments if any) is intended only for the use of the 
individual or entity to which it is addressed, and may contain information that 
is privileged, confidential and exempt from disclosure under applicable law.  
If the reader of this email is not the intended recipient, or the employee or 
agent responsible for delivering this message to the intended recipient, you 
are hereby notified that any dissemination, distribution or copying of this 
communication is strictly prohibited.  If you have received this communication 
in error, please notify the sender immediately by return email and destroy all 
copies of the email (and attachments if any).
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] OgrInfo ShapeFile Extents Report

[David Baker (Geoscience)]

Thanks for the info Frank.

David Baker @ CHK
Sent from my iPhone

On Mar 8, 2010, at 7:24 PM, "Frank Warmerdam" 
wrote:

> David Baker (Geoscience) wrote:
>> Frank,
>>
>> Thanks...  Is there a method in org that scans all geometries or
>> will I have to iterate through myself?
>
> David,
>
> I think you would have to do this yourself.  You can see the default
> implementation at:
>
> http://trac.osgeo.org/gdal/browser/trunk/gdal/ogr/ogrsf_frmts/generic/ogrlayer.cpp#L189
>
> Best regards,
> --
> ---
> +--
> I set the clouds in motion - turn up   | Frank Warmerdam, warmer...@pobox.com
> light and sound - activate the windows | http://pobox.com/~warmerdam
> and watch the world go round - Rush| Geospatial Programmer for
> Rent
>

This email (and attachments if any) is intended only for the use of the 
individual or entity to which it is addressed, and may contain information that 
is privileged, confidential and exempt from disclosure under applicable law.  
If the reader of this email is not the intended recipient, or the employee or 
agent responsible for delivering this message to the intended recipient, you 
are hereby notified that any dissemination, distribution or copying of this 
communication is strictly prohibited.  If you have received this communication 
in error, please notify the sender immediately by return email and destroy all 
copies of the email (and attachments if any).
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] Geodetic Problem

[David Baker (Geoscience)]

Frank and the List,

I have a geodetic problem I hope GDAL/OGR can solve.

The setup:

I have two radio towers each the same height and at the same elevation being 
10,000 meters apart.  I know the latitude and longitude of the first tower and 
those coordinates reference WGS84 (though they could be any geographic CRS, 
NAD27, NAD83, etc.).  I also now the baring to the second from the first 
measured from true north at the first tower.

The problem:

Given the above information and using the prebuilt tools, GDAL/OGR utilities, 
what workflow would one use to calculate the latitude and longitude of the 
second tower?

The hints I have gotten so far say to use a conformal projection (UTM maybe?) 
centered at the first point with a scale factor of 1, a local projection.  
Calculate the Cartesian offsets from the first point to the second based on the 
azimuth of the given baring.  Using the baring calculate the x and y offsets to 
the second point and use offsets to find the x and y of the second point in the 
local coordinate system.  Then, reproject the x and y of the second point to 
the latitude and longitude in the CRS of the first points latitude and 
longitude.  If this is correct, I guess the question is, what would the proj4 
parameters be for such a local projections.

Thanks,
David

David M. Baker
Senior Geologist - Chief Technology Advisor
Chesapeake Energy Corporation
405-935-3715 office
405-496-5373 cell
david.m.ba...@chk.com



This email (and attachments if any) is intended only for the use of the 
individual or entity to which it is addressed, and may contain information that 
is privileged, confidential and exempt from disclosure under applicable law. If 
the reader of this email is not the intended recipient, or the employee or 
agent responsible for delivering this message to the intended recipient, you 
are hereby notified that any dissemination, distribution or copying of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify the sender immediately by return email and destroy all 
copies of the email (and attachments if any).
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

RE: [gdal-dev] Geodetic Problem

[David Baker (Geoscience)]

Frank,

Thanks for the references...  I will look them over.  I am correct that the c# 
binding will not have access to the Geod calc's?

David

David M. Baker
Senior Geologist - Chief Technology Advisor
Chesapeake Energy Corporation
405-935-3715 office
405-496-5373 cell
david.m.ba...@chk.com


-Original Message-
From: Frank Warmerdam [mailto:warmer...@pobox.com]
Sent: Tuesday, March 16, 2010 4:13 PM
To: David Baker (Geoscience)
Cc: 'gdal-dev@lists.osgeo.org'
Subject: Re: [gdal-dev] Geodetic Problem

David Baker (Geoscience) wrote:
> Frank and the List,
>
>
>
> I have a geodetic problem I hope GDAL/OGR can solve.
>
>
>
> The setup:
>
>
>
> I have two radio towers each the same height and at the same elevation
> being 10,000 meters apart.  I know the latitude and longitude of the
> first tower and those coordinates reference WGS84 (though they could be
> any geographic CRS, NAD27, NAD83, etc.).  I also now the baring to the
> second from the first measured from true north at the first tower.
>
>
>
> The problem:
>
>
>
> Given the above information and using the prebuilt tools, GDAL/OGR
> utilities, what workflow would one use to calculate the latitude and
> longitude of the second tower?
>
>
>
> The hints I have gotten so far say to use a conformal projection (UTM
> maybe?) centered at the first point with a scale factor of 1, a local
> projection.  Calculate the Cartesian offsets from the first point to the
> second based on the azimuth of the given baring.  Using the baring
> calculate the x and y offsets to the second point and use offsets to
> find the x and y of the second point in the local coordinate system.
> Then, reproject the x and y of the second point to the latitude and
> longitude in the CRS of the first points latitude and longitude.  If
> this is correct, I guess the question is, what would the proj4
> parameters be for such a local projections.

David,

The above will give a pretty good approximation, degrading as the
distance increases.  However, the proper way to do this is using
great circle operations.  The PROJ.4 "geod" program can do this:

   http://trac.osgeo.org/proj/wiki/man_geod

There is more information on geodesic operations at:

   http://trac.osgeo.org/proj/wiki/GeodesicCalculations

Best regards,
--
---+--
I set the clouds in motion - turn up   | Frank Warmerdam, warmer...@pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush| Geospatial Programmer for Rent


This email (and attachments if any) is intended only for the use of the 
individual or entity to which it is addressed, and may contain information that 
is privileged, confidential and exempt from disclosure under applicable law.  
If the reader of this email is not the intended recipient, or the employee or 
agent responsible for delivering this message to the intended recipient, you 
are hereby notified that any dissemination, distribution or copying of this 
communication is strictly prohibited.  If you have received this communication 
in error, please notify the sender immediately by return email and destroy all 
copies of the email (and attachments if any).
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

RE: [gdal-dev] Geodetic Problem

[David Baker (Geoscience)]

Aron,

Thanks for the info...

David

David M. Baker
Senior Geologist - Chief Technology Advisor
Chesapeake Energy Corporation
405-935-3715 office
405-496-5373 cell
david.m.ba...@chk.com


-Original Message-
From: Aron Rubin [mailto:aronru...@gmail.com]
Sent: Tuesday, March 16, 2010 4:14 PM
To: David Baker (Geoscience)
Cc: gdal-dev@lists.osgeo.org
Subject: Re: [gdal-dev] Geodetic Problem

On 3/16/10, David Baker (Geoscience)  wrote:
> Frank and the List,
>
> I have a geodetic problem I hope GDAL/OGR can solve.
>

I have not seen the direct or inverse gedesic routines in either Proj
or OGR. SimGear provides an implementation here
<http://cvs.simgear.org/viewvc/source/simgear/math/SGGeodesy.cxx?root=SimGear&view=markup>
(function _geo_direct_wgs_84) and you could use OSRGetSemiMajor
OSRGetInvFlattening OSRGetSemiMinor for the "a", "rf", and "b"
variables respectively to use other ellipsoids assigned in OGR. Proj
wiki has notes here
<http://trac.osgeo.org/proj/wiki/GeodesicCalculations> which notes a
fortran implementation <http://www.ngs.noaa.gov/PC_PROD/Inv_Fwd/>.

Aron

--
Aron Rubin
Handy Husband & Daddy Jungle Gym & Senior Engineer

This email (and attachments if any) is intended only for the use of the 
individual or entity to which it is addressed, and may contain information that 
is privileged, confidential and exempt from disclosure under applicable law.  
If the reader of this email is not the intended recipient, or the employee or 
agent responsible for delivering this message to the intended recipient, you 
are hereby notified that any dissemination, distribution or copying of this 
communication is strictly prohibited.  If you have received this communication 
in error, please notify the sender immediately by return email and destroy all 
copies of the email (and attachments if any).
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

RE: [gdal-dev] Geodetic Problem

[David Baker (Geoscience)]

Jean-Claude,

I have looked at that and not being a c++ guys did not really know how to 
recompile geographiclib into a dll that I could then pinvoke into C#.  I did 
find 
http://www.gavaghan.org/blog/free-source-code/geodesy-library-vincentys-formula/
 that looks like it will do the trick.

The application I am working on takes deviation survey station readings 
(wellbore measured depth from the wells surface location, wellbore inclination 
from vertical and wellbore azimuth from true or grid north) recorded in 
horizontal wellbores, and using a minimum curvature calculation calculates the 
x, y and z (x and y are relative to the azimuth reference and z is true 
vertical depth) offsets of each survey station along the wellbore path.  I need 
to calculate the latitude and longitude of each of these points.

Thanks for the reference.

David

David M. Baker
Senior Geologist - Chief Technology Advisor
Chesapeake Energy Corporation
405-935-3715 office
405-496-5373 cell
david.m.ba...@chk.com

-Original Message-
From: Jean-Claude REPETTO [mailto:jrepe...@free.fr]
Sent: Wednesday, March 17, 2010 11:45 AM
To: David Baker (Geoscience)
Cc: 'gdal-dev@lists.osgeo.org'
Subject: Re: [gdal-dev] Geodetic Problem

David Baker (Geoscience) a écrit :
>
> Given the above information and using the prebuilt tools, GDAL/OGR
> utilities, what workflow would one use to calculate the latitude and
> longitude of the second tower?
>

Hello David,

Maybe the "geod" utility from the GeographicLib can solve your problem :
<http://geographiclib.sourceforge.net/html/utilities.html#geod>

Jean-Claude

This email (and attachments if any) is intended only for the use of the 
individual or entity to which it is addressed, and may contain information that 
is privileged, confidential and exempt from disclosure under applicable law.  
If the reader of this email is not the intended recipient, or the employee or 
agent responsible for delivering this message to the intended recipient, you 
are hereby notified that any dissemination, distribution or copying of this 
communication is strictly prohibited.  If you have received this communication 
in error, please notify the sender immediately by return email and destroy all 
copies of the email (and attachments if any).
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] GXF -- Grid eXchange File to AAIGrid -- Arc/Info ASCII Grid No Value Issue

[David Baker (Geoscience)]

All,

Using OpenEV from FWTools version 2.4.7 to convert the GXF file found at 
http://pubs.usgs.gov/of/2000/ofr-00-0042/data/ from the GXF format to AAIGrid 
format I have found an issue.  In the GXF file the #DUMMY value/string is -1e32 
and this is the same value/string found in the data portion of the GXF file.  
After conversion in the AAIGrid file, the NODATA line reads

NODATA_value -1.0001e+032

but the value -1.000331813535e+032 is found in the data portion of the 
AAIGrid file where the value -1.0001e+032 should be found.  As 
OpenEV uses GDAL/OGR to do the conversion I have posted this issue here.

Thanks,

David M. Baker
Senior Geologist - Chief Technology Advisor
Chesapeake Energy Corporation
405-935-3715 office
405-496-5373 cell
david.m.ba...@chk.com



This email (and attachments if any) is intended only for the use of the 
individual or entity to which it is addressed, and may contain information that 
is privileged, confidential and exempt from disclosure under applicable law. If 
the reader of this email is not the intended recipient, or the employee or 
agent responsible for delivering this message to the intended recipient, you 
are hereby notified that any dissemination, distribution or copying of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify the sender immediately by return email and destroy all 
copies of the email (and attachments if any).
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

RE: [gdal-dev] zmap format

[David Baker (Geoscience)]

Nikolaos,

The ZMapPlus is an old format used to store gridded data in an ASCII line 
format for transport and storage.  It is Landmark Corp. format that many of the 
Landmark products, including GeoGraphix, use for data exchange.  Because it has 
been around for a while, many industry (Oil and Gas Exploration) applications 
read and write the format.

It is for gridded data. The format can also support point and polygon data, but 
only one data type is allowed in each file.  There are a specific set of header 
rows that define how the data is written in the file.

If the first character is a "!" the line is a comment.
The header section is starts with the first line that has an "@" symbol.  The 
data starts on the first line after the last "@" symbol, and there may only be 
two.  Header fields are comma delimited.

On the same line as the first "@" there are three fields.  The first is user 
defined but many times is just "GRID FILE", the second, for a grid file, must 
be "GRID", the third is an integer that indicates the number of grid nodes per 
physical line.

After the file description line are three more header lines that must exist for 
a grid file.

The first of these three lines has five fields.  The first field is the field 
width of each grid node as stored in the data section below the last "@".  The 
second field is the missing or null data value as it will be found in the data 
section.  The third field is a user defined text value used to indicate a 
missing or null value.  The text value is used if field two is blank.  If field 
two is defined, then the third field is left blank.  The forth field indicates 
the number of decimal places to use if no decimal point is found in the data 
nodes.  (Historical note: when disk and tape space was at a premium, this field 
made it possible to save some space in the file by not having to store a "." 
for each data node.)  If the data values are written to the file with decimals, 
this value is ignored.  The fifth field indicates the starting column of the 
first grid node on each line in the data section of the file.

The second of the three lines has six fields.  The first field is the number of 
rows in the grid.  The second field is the number of columns in the grid.  The 
third is the minimum grid X node value.  The forth is the maximum grid X node 
value.  The fifth is the minimum grid Y node value.  The sixth is the maximum 
grid Y node value.  The last four fields define the bounding box of the grid, 
and implies, for example, the lower left corner of the of the grid is the lower 
left corner of the lower left node in the grid.  The projection and or datum of 
the bounding box value is not defined.

The third of the three lines is always "0,0, 0.0, 0.0".

After the last header line, there is a single line with a single "@", the line 
after which is the first line of data in the data section of the file.  The 
data section has fixed field widths each field being a single grid node, and is 
generally right justified.  There will be no more nodes on any physical line 
than that defined in third field of the first header line.  A data field may or 
may not have a decimal point.  If none is found, it is implied, and the decimal 
places are as defined in the second header line in the forth field.

The grid nodes in the data section are stored in column major order.  That is 
the first column of data is written first, starting at the upper left corner of 
the grid.  For example, if the grid has 7 rows and three columns, and the 
number of nodes per line is 4, the first line of the data section will have 4 
nodes, the first four grid nodes going down from the upper left.  The second 
line will have three nodes, the last three nodes of the first column.  Then the 
next column is written, four nodes then three.  Then the last column is written 
in the same pattern.

Here is an example of a 6 row x 4 column ZMapPlus grid file:



!
! File created by DMBTools2.GridFileFormats.ZmapPlusFile
!
@GRID FILE, GRID, 4
20, -.000, , 7, 1
6, 4, 0, 200, 0, 300
0.0, 0.0, 0.0
@
   -.000   -.000   3.000  32.000
  88.000  13.000
   -.000  20.000   8.000  42.000
  75.000   5.000
   5.000 100.000  35.000  50.000
  27.000   1.000
   2.000  36.000  10.000   6.000
   9.000   -.000



I hope this helps and maybe someday we can see it as a supported format in 
GDAL/OGR.

David M. Baker
Senior Geologist - Chief Technology Advisor
Chesapeake Energy Corporation
405-935-3715 office
405-496-5373 cell
david.m.ba...@chk.com

-Original Message-
From: gdal-dev-boun...@lists.osgeo.org 
[mailto:gdal-dev-boun...@lists.osgeo.org] On Behalf Of Even Rouault
Sent: Monday, June 27, 2011 12:34 PM
T